Request to support Fortran 2008 inquiry functions of COMPILER_OPTIONS() and COMPILER_VERSION()

[FortranFan]

I'm wondering whether the inquiry functions of COMPILER_OPTIONS() and COMPILER_VERSION() introduced in Fortran 2008 as part of ISO_FORTRAN_ENV are low-hanging fruit that Intel can grab quickly and support soon in Intel Fortran.  gfortran already supports it.

I think they'll be very useful in our validation work process for all the codes with various versions of compilers; in addition, Intel may also find these very useful in the services it offers toward incident resolution via Intel Premier Support as well as the Fortran forums by allowing and encouraging the customer to make use of these functions.  Could it be that the introduction of Intel-specific FOR_IFPORT_VERSION and FOR_IFCORE_VERSION functions in 16.0 beta compiler implies Intel is already thinking along these lines?!

[JVanB]

Re: Quote #20: as Steve and I have discussed, in the general case linker options aren't going to be available because COMPILER_OPTIONS() is a constant expression, so it can be used to generate KIND numbers which have to be known to compile the program. It is not unusual for all program units to be compiled separately and later linked to form an executable or a *.dll. But the good news is that you don't need to allocate a buffer to capture COMPILER_OPTIONS() because f2008 syntax allows you to capture it in a named constant, the compiler figuring out the required len for you.

program command
   use ISO_FORTRAN_ENV
   implicit none
   character(*), parameter :: stuff = COMPILER_OPTIONS()
   logical, parameter :: is_double = index(stuff,'OMG') > 0
   integer, parameter :: rk = merge(kind(1.0d0),kind(1.0),is_double)
   real(rk) pi
   write(*,'(*(g0))') 'len(COMPILER_OPTIONS()) = ',len(stuff)
   write(*,'(*(g0))') 'COMPILER_OPTIONS() = ',stuff
   pi  = 4*atan(real(1,kind(pi)))
   write(*,'(*(g0))') 'kind(pi) = ',kind(pi)
   write(*,'(*(g0))') 'pi = ',pi
end program command

Now gfortran doesn't do what I would like here in that it doesn't include the preprocessor define in its COMPILER_OPTIONS() and consequently sets the kind of pi to be 4 rather than the expected 8:

C:\>gfortran -DOMG command.f90 -ocommand

C:\>command
len(COMPILER_OPTIONS()) = 26
COMPILER_OPTIONS() = -mtune=core2 -march=nocona
kind(pi) = 4
pi = 3.14159274

But capturing COMPILER_OPTIONS() in a named constant did work well.

[John_Campbell]

Repeat Offender,

Every time I see a gfortran compile command, I always find something I don't know !  what is -DOMG ?

If you try "gfortran command.f90 -march=native -o command.exe", you will get a lot more that 26 characters.

Trying to keep up to date with Intel architecture options is a struggle

Thanks for showing how long stuff has to be.

[mecej4]

John, that is just another instance of Repeat Offender living up to his name. The string "OMG" is a place-holder that he uses to set the value of the parameter is_double on line-5. The -DOMG option is accepted by gfortran as "define OMG", but the definition does nothing else that is significant. If this option is used, the value of is_double would be .TRUE., if Repeat Offender's wishes were respected; otherwise it is .FALSE.

Repeat Offender is illustrating how COMPILER_OPTIONS() can be used, and pointing out that preprocessor definitions are treated differently than other options because those are consumed by the preprocessor whereas the other options are passed to the compiler, the assembler and the linker (and possibly other tools).

[JVanB]

I hadn't seen mecej4's comment when I logged in, but he is correct that it's a preprocessor define. Look at https://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html for more info: -D is on the first page of the link. The trouble is that -cpp has to be in effect for the message to get passed via COMPILER_OPTIONS() in gfortran, but -cpp breaks Fortran programs. As seen in Quote #22, without -cpp, the message is lost, so we'll write a program requiring -cpp to compile and try again:

program command
   use ISO_FORTRAN_ENV
   implicit none
   character(*), parameter :: stuff = COMPILER_OPTIONS()
   logical, parameter :: is_double = index(stuff,'OMG') > 0
   integer, parameter :: rk = merge(kind(1.0d0),kind(1.0),is_double)
   real(rk) pi
   write(*,'(*(g0))') 'len(COMPILER_OPTIONS()) = ',len(stuff)
   write(*,'(*(g0))') 'COMPILER_OPTIONS() = ',stuff
   pi  = 4*atan(real(1,kind(pi)))
   write(*,'(*(g0))') 'kind(pi) = ',kind(pi)
   write(*,'(*(g0))') 'pi = ',pi
   write(*,'(*(g0))') 'OMG = ',OMG
end program command

C:\>gfortran -DOMG command.f90 -ocommand
command.f90:13.34:

   write(*,'(*(g0))') 'OMG = ',OMG
                                  1
Error: Symbol 'omg' at (1) has no IMPLICIT type

C:\>gfortran -DOMG -cpp command.f90 -ocommand

C:\>command
len(COMPILER_OPTIONS()) = 170
COMPILER_OPTIONS() = -cpp -iprefix C:/Program Files/mingw-w64/x86_64-4.9.2-win32
-seh-rt_v3-rev0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.2/ -U_REENTRANT -D
 OMG -mtune=core2 -march=nocona
kind(pi) = 8
pi = 3.1415926535897931
OMG = 1

As was documented, -DOMG defines the symbol OMG with value 1. Now, with -cpp in effect is_double gets the value .TRUE., whereas without -cpp the -DOMG preprocessor define is not listed among the COMPILER_OPTIONS() so is_double gets the value .FALSE.. My preferred behavior would be that even without -cpp it would be possible to see the -DOMG option was selected, even though it seems futile to the compiler. I think ifort will do this in its implementation because it has its own preprocessor with !DEC$ IF DEFINED(OMG). If, by that time, ifort doesn't implement assumed length character named constants, the sequence

integer, parameter :: COOPLE = len(COMPILER_OPTIONS())
character(COOPLE), parameter :: stuff = COMPILER_OPTIONS()

would define the named constant stuff as before. Or if you didn't need the result as a constant expression, you could declare an assumed-length allocatable character variable to store the result of COMPILER_OPTIONS(). Don't worry about not knowing the sizes of things in advance -- it's one of the big advantages of modern Fortran that we have dynamic memory available so we have the flexibility to absorb unknown sized objects in many different ways.

[FortranFan]

Repeat Offender wrote:

.. If, by that time, ifort doesn't implement assumed length character named constants, ..

Perhaps I'm missing something, I thought Intel Fortran does support assumed length named constants of character type and it has done so for a while now.

program p

   implicit none

   character(len=*), parameter :: fmt1 = "(3a,g0)"
   character(len=*), parameter :: str = char(ichar("a"))

   write(*,fmt=fmt1) " str = ", str, ", len(str) = ", len(str)

   stop

end program p

 str = a, len(str) = 1
Press any key to continue . . .

[JVanB]

Sorry, sometimes it's hard to keep track of what's in each compiler. I guess it was assumed size array constants that aren't implemented in ifort.

program P
   implicit none
   character, parameter :: X*(*) = 'First test'
   character, parameter :: Y(*) = ['S','e','c','o','n','d', &
      ' ','t','e','s','t']
   write(*,'(*(g0))') X
   write(*,'(*(g0))') Y
end program P

C:\>gfortran test1.f90 -otest1

C:\>test1
First test
Second test

C:\>ifort /nologo test1.f90
test1.f90(4): error #6364: The upper bound shall not be omitted in the last dime
nsion of a reference to an assumed size array.   
   character, parameter :: Y(*) = ['S','e','c','o','n','d', &
---------------------------^
test1.f90(7): error #6364: The upper bound shall not be omitted in the last dime
nsion of a reference to an assumed size array.   
   write(*,'(*(g0))') Y
----------------------^
compilation aborted for test1.f90 (code 1)

[FortranFan]

Repeat Offender wrote:

Sorry, sometimes it's hard to keep track of what's in each compiler. I guess it was assumed size array constants that aren't implemented in ifort. ..

Yes, it can be.  And yes, it will be nice to have assumed size array constants in Intel Fortran too, along with all the other "goodies" from the Fortran 2008 standard!

[Steven_L_Intel1]

Assumed-size PARAMETER arrays are in for 17.0. COMPILER_OPTIONS and COMPILER_VERSION are planned for the major release in the second half of 2017.

[FortranFan]

Thanks for the update Steve.