We use it, but not because of Microsoft Fortran Power Station. We have an application where a C# main calls a Fortran DLL. We use standard-semantics (which sets fpscomp:logicals) to ensure logical values returned from Fortran are either 0 or 1.
1 Like
Thank you for your reply 
From iso_c_binding.f90 it is
INTEGER (KIND=4), PARAMETER :: C_BOOL = 1
Therefore SELECTED_LOGICAL_KIND(8) should be equivalent.
That was the first flavor of Fortran I ever used.
It’s not about porting from MS-FPS, but about Intel already having a setting that made logicals behave in a way required for C interoperability —so they reused it for -standard-semantics.
1 Like
This is a general complaint that I have with the documentation for almost all compilers regarding KIND values. The documentation and the code examples typically show the compiler-dependent integer literals, and when new fortran programmers look at those code examples, they tend to mimic that programming style. A better approach, as you say, would be to use the iso_fortran_env values instead.
1 Like
Yes but a lot of people still insist on doing REAL(8) etc instead of REAL(REAL64) because typing 5 extra characters is such a heavy burden to bear. I see REAL(4) and REAL(8) in modern Fortran reference books written by people who should know better. I also still see REAL*8 on occasion. As far as I know, only NAG uses something other than the word size of the variable as the KIND value.
2 Likes
Doesn’t SilverFrost use 1, 2, 3, … for KINDs?
1 Like
Wouldn’t know. Never used SilverFrost and the only Windows products I’ve used in the last 35 years were Word and Powerpoint on a Windows server that I logged into remotely from a LInux box.
I thought that 8-byte decimal floating point would eliminate that convention, but the solution so far instead is for fortran to not supporyt 8-byte decimal arithmetic. Also, there are two different popular 2-byte floating point formats, and I have hoped that fortran would support them both, but again so far, the solution to the dilemma has been for fortran to support neither (the NAG compiler supports just one of them). The Dec VAX hardware supported two different 8-byte floating point formats, but there was never a f90 compiler for the VAX, so programmers never really had the chance to use that feature back when fortran was still the dominant science, engineering, and math language. Since f90, fortran has had a significant advantage over other languages with its potential seamless support of multiple floating point formats, but so far that potential is unrealized.
I don’t use Windows either, but I remember that after trying out their ftn95 (like 20 years ago), I realized integer KINDs weren’t always 1, 2, 4, 8.
(back then, I had only used compilers aligned with DEC, and the only thing I knew about standards was that my compiler(s) supported forall, which was slower than a regular loop… but cooler 
).
The KIND-related enum still seems to be applicable to SilverFrost.
I’m also puzzled why more effort has not been given to supporting either decimal floating point or other FP formats given how important they are on GPUs etc to support AI and other things. Fortran should have been leading the move to use GPUs for scientific computing rather than following up from behind. I think there has been some work (I believe by the UTK MAGMA replacement for LAPACK) to use 16 bit precision with iterative refinement to do linear algebra on GPUs. Not sure how useful that is for say Finite Element calculations but at least it would be an option for some cases.
1 Like
Flang supports both 16-bit floating point types. In iso_fortran_env, kind real16 is 2 and bfloat16 is 3. I haven’t used them so I don’t know how complete the support is.
1 Like
Is there an update to the Microsoft Visual Studio validated versions? I didn’t see it in the release notes or Intel® Compilers Compatibility with Microsoft Visual Studio
I am interested in the supported minor releases for VS2022 17.12 LTSC and VS2022 17.14 (which for unknown reasons will not have an LTSC channel).
Yes, SilverFrost version 8.80.0 from 2021 gives 1 2 3 for
print*,kind(1.0), kind(1.0d0), kind(1)
Yet another reason for getting away from the byte-kind convention is for different types to have different associated kind values, even if they happen to have the same storage_size(). If that had been introduced as part of the standard in f90, then there would never be any problems related to things like 1_real32 being an integer rather than the intended real.