compiler version info and options

[zmi007]

The ISO_FORTRAN_ENV functions are still not implemented in ifort compiler. Especially this program doesn't compile with ifort.

program main
use ISO_FORTRAN_ENV
implicit none
write(*,*)" Compiler version: ",compiler_version()
write(*,*)" Compiler options: ",compiler_options()
end program

This info is extremely useful for some programs compiled and executed on different machines and clusters.

Is there any compatible solution for gfortran / ifort ?

[Steven_L_Intel1]

You are correct that Intel Fortran does not yet support those intrinsic module routines from Fortran 2008. We do have a predefined preprocessor macro __INTEL_COMPILER that has version information, though not at a fine level of detail. There is nothing similar for compiler options.

We expect to support these F2008 features in a future release, but not this year.

[Matt_Thompson]

Steve,

Any updates on the implemenation of the ISO_FORTRAN_ENV functions?

Also: Zombie thread reactivate!

Matt

[Steven_L_Intel1]

My 2012 answer still holds. It's on our list for future implementation.

[Matt_Thompson]

FYI to those who search on the web and find this thread, Intel 16.0.0.109 doesn't support these bits of F2008 yet:

(1265) $ ifort -V
Intel(R) Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 16.0.0.109 Build 20150815
Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.

(1266) $ ifort test.F90 
test.F90(12): error #6404: This name does not have a type, and must have an explicit type.   [COMPILER_VERSION]
write (OUTPUT_UNIT,*) 'compiler_version: ', compiler_version()
--------------------------------------------^
test.F90(13): error #6404: This name does not have a type, and must have an explicit type.   [COMPILER_OPTIONS]
write (OUTPUT_UNIT,*) 'compiler_options: ', compiler_options()
--------------------------------------------^
compilation aborted for test.F90 (code 1)

But we should be close, I'm guessing. PGI and gfortran seem to support it (with a delta of bug fixes probably needed).

[Kevin_D_Intel]

Related thread/discussion, https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/560114

[Matt_Thompson]

@Kevin Davis,

Thanks for the link. I guess I never venture over to the Windows forum. One question, do you happen to know (yet) what the "processor-dependent length" is for the ifort Linux processor? I'm always a bit...annoyed, let say, when the Standard just doesn't say "Thou shalt have a string of length 2048" or the like. I'm still not sure what's a good length for IOMSG that'll work with every compiler (I go with 256 and pray).

[Kevin_D_Intel]

No, sorry. There are no details at all in the internal tracking id for this feature.

256 seems reliable for IOMSG. Steve offered advice/guidance (about 100) here, https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/269637

[FortranFan]

thematt wrote:

.. Thanks for the link. I guess I never venture over to the Windows forum. One question, do you happen to know (yet) what the "processor-dependent length" is for the ifort Linux processor? I'm always a bit...annoyed, let say, when the Standard just doesn't say "Thou shalt have a string of length 2048" or the like. I'm still not sure what's a good length for IOMSG that'll work with every compiler (I go with 256 and pray).

@thematt,

I suggest you follow the Intel Fortran forum for Windows also, for a lot of Windows users like me strive to code in standard Fortran as much as possible and a lot of the issues (like the two missing functions in Intel Fortran from the standard intrinsic module) are common to both Windows and Linux users.

Secondly, I don't think you need to be concerned enough to "pray" re: string length for IOMSG in connection with different compilers; I'd expect the worst that might happen is some compilers may possibly have a more verbose message which might get then truncated if a coder were to specify a not-long-enough default-char-variable for IOMSG= specifier.  Note the standard says IOMSG=iomsg-variable shall be of scalar-default-char-variable and note what happens in Fortran when you have "character(len=2) :: s" and one codes "s = foo". 

Now the compilers I work with tend to have I/O messages shorter in length than 256, so it does seem like a good selection for the string length.  Regardless. your consumer should have no other adverse affect (no crash, etc.) in case the actual messages are longer, they simply may have to "figure out" the error from the truncated description; not that a big deal I'd argue given how the computer world in general and Linux/Windows OSes in particular dish out so many cryptic, jargon-filled mumbo-jumbo of messages to their users whenever something goes wrong and gets trapped.