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?!

[Steven_L_Intel1]

These are already on our list - as is all of F2008. I doubt those library functions are related - those are for internal workings of the Fortran libraries. These intrinsics have to be recognized at compile-time and can be used in constant expressions. 

[FortranFan]

gfortran for the following code:

program p

   use, intrinsic :: iso_fortran_env, only : compiler_version, compiler_options

   print *, " program compiled with ", compiler_version(), " using ", compiler_options(), new_line("a")

   print *, " Hello World!"

   stop

end program p

  program compiled with GCC version .. using .. -g -Wall -std=f2008ts -fall-intrinsics ..

  Hello World!

..

[Steven_L_Intel1]

"version .."? 

[FortranFan]

The program does work ok and print the version number and all the compiler options correctly: I deliberately left out some of the details in both for privacy reasons (the version itself is actually a private build of the GCC trunk).

[Steven_L_Intel1]

Ok.

Here's a question for you - what would be your preference for how Intel Fortran identifies itself in COMPILER_VERSION? "ifort"? "Intel(R) Visual Fortran"? Something else? Anyone else feel free to chime in.

[FortranFan]

Steve Lionel (Intel) wrote:

Ok.

Here's a question for you - what would be your preference for how Intel Fortran identifies itself in COMPILER_VERSION? "ifort"? "Intel(R) Visual Fortran"? Something else? Anyone else feel free to chime in.

Very good question, Steve.

It'll be most useful if there is full consistency with what the user would notice in Visual Studio (or from the command line with the logo option) and what COMPILER_VERSION() returns.  This will eliminate a lot of confusion, I think.

I work mainly in Visual Studio and mostly use the x64 platform, so I notice the version information in the VS output window as well as the HTML build log as "Intel(R) Visual Fortran Compiler 16.0.0.049 [Intel(R) 64]" 

Now I see the command line option provides the longer text "Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 16.0.0.049 Beta Build 20150501".

Can all these be consolidated and the same output text appear in all such situations?

Thanks,

[Craig_Dedo]

Steve Lionel (Intel) wrote:

Ok.

Here's a question for you - what would be your preference for how Intel Fortran identifies itself in COMPILER_VERSION? "ifort"? "Intel(R) Visual Fortran"? Something else? Anyone else feel free to chime in.

FWIW, I would prefer something like, ""Intel(R) Visual Fortran Compiler 16.0.0.049 Build 20150618 [Intel(R) 64]".  To be completely useful, the compiler has to be identified as to what flavor of compiler it is and the version information has to include the build number.  Hope this helps.

[jimdempseyatthecove]

My choice would be for consistency. Use the line that Ifort uses to announce itself. Example:

Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 12.0.4.196 Build 20110427

While it is long, I do not think using "IVF" would be meaningful.

It may be appreciated to take the marketing/advertising plug out

Intel(R) Visual Fortran Intel(R) 64 Compiler XE x64, Version 12.0.4.196 Build 20110427

or

Intel(R) Visual Fortran x64, Version 12.0.4.196 Build 20110427

But after saying this, the "for applications running on Intel(R) 64" would be useful when cross-compiling.

Go with the full line.

Jim Dempsey

[John_Campbell]

From Jim's example above, "Intel(R) Visual Fortran x64, Version 12.0.4.196 Build 20110427" provides all the required information.

My experience of using these reports in gFortran shows more problems with designing the COMPILER_OPTIONS () report. There needs to be some rationalisation of the report by reporting non-default (selected) options first. My early attempt at storing this information in a character*256 string often omitted the options that were important, with many default options (that I did not select) being listed first.

If this report is being used to document variations between different .exe builds, there are many build options that could be included. For example with vector instructions, do we want supported instructions or selected instructions, both of which can be very long lists. This list could also extend to reporting selected .dll libraries.

Given the explosion in compiler options in ifort and especially gFortran and when combining the compile and link process in one command, this can be a very long string. What is the size limit of a command string in Windows 7 ?

John

[Steven_L_Intel1]

I think it would be infeasible and inappropriate to deliver anything other than the exact text from the command line. Going down the rabbit hole of displaying every nondefault option (and what is default can change from version to version) is not likely to be helpful in the long run. 

[John_Campbell]

Steve,

In the case of a gFortran command, the question could be which command, as these go through a scripting system.

Doesn't ifort have a similar process for compile and link ? 

I can certainly report that the compiler_options() result does have problems with other compilers.

John

[Steven_L_Intel1]

It would be the options on the ifort (or gfortran) command line. What happens after that is unimportant.

[FortranFan]

For COMPILER_OPTIONS(), I only expect to see the options I've specified, not the default ones in the compiler.  With Intel Fortran, as far as I can tell, the HTML build log provides only the user-specified options that go into the (effective) ifort command line; I'll be happy if the COMPILER_OPTIONS() were to list the same information.

Whether one uses a script or an IDE such as Visual Studio or Eclipse shouldn't matter, as Steve indicated.  Because they should all eventually lead to "ifort -c .." command for source compilation and it is what goes into the ifort command that I would like to see with COMPILER_OPTIONS(). 

[Steven_L_Intel1]

You can see ALL of the compiler options in effect if you generate a listing file.

The build log (from a VS project) will include options set by project properties. Some properties are default enabled in new projects but not if you just use ifort from the command line - for example, /warn:interface. COMPILER_OPTIONS should return what was specified on the ifort command line, whether you typed it in manually or it was generated by a build system.

On Linux and OS X there's a -sox option that inserts the command line into a "comment" section in the object. We used to have that on Windows until Microsoft removed support for it in the linker. Some customers didn't want this to show source file names (which it did as it just dumped the whole command line). I'm assuming that for COMPILER_OPTIONS it would be just that - not source file names.

[mecej4]

Steve Lionel (Intel) wrote:

COMPILER_OPTIONS should return what was specified on the ifort command line, whether you typed it in manually or it was generated by a build system.

I presume that "..generated by a build system" would include those options that are specified in ifort.cfg or the file to which the corresponding environment variable IFORTCFG points.

[Steven_L_Intel1]

Yes, I would assume that. But good of you to bring it up - I'll make a note of it.

[JVanB]

Does each source file get its own COMPILER_OPTIONS() when compiled with /c? I guess it has to because COMPILER_OPTIONS() is called out specifically as a specification inquiry so the string can be parsed to produce KIND numbers that are required to be known at compilation time. Thus I suppose that you can't store the result of COMPILER_OPTIONS() someplace and pass it around freely because program units compiled in other files might not see the same set of options. Also that seems to imply that you can't necessarily see the linker options.

[Steven_L_Intel1]

Each invocation of the compiler gets options. You're right that it's usable in constant expressions. It's certainly possible to pass the value around but you might be doing so to a program unit compiled with different options. Linker options are not included.

I'm tickled that the example given in the standard uses DEC Fortran for OpenVMS options ("/OPTIMIZE /FLOAT=IEEE").

[John_Campbell]

When using COMPILER_OPTIONS (), there is a variety of information that could be provided, including:
* non-default compiler options
* options specified in the command line which are actually default
* linking options, such as .obj files, .dll libraries, static libraries etc

With IDE builds, there can be many options selected so which ones should be reported? The command line can be very extensive in this case.

As the name could imply; it could be Compiler options not Link options, although Note 13.27 above could imply an even more extensive list.

I see the purpose of this routine is to provide a report, when running the .exe of how it was built and what are the "key" build features.

In my previous post, I was reporting that my experience of using COMPILER_OPTIONS () with gFortran was that it did not appear to provide the "key" information I needed in a concise form.
Gfortran first lists out all the vector instructions that are supported (not selected), which can be a very long list.
In some cases, indicating what vector instructions are supported could be very useful.
You need a large buffer to get to the relevant options, which in my case did not appear for the buffer*256 I provided. I'm not sure how long a buffer would be required. (*1024 or *2048 which become a challenge to read)

I think COMPILER_OPTIONS () may need some arguments to select what is requested, as the default is a bit of a disappointment.

John

[FortranFan]

John Campbell wrote:

.. COMPILER_OPTIONS () may need some arguments to select what is requested, as the default is a bit of a disappointment.  ..

Your comments would be good feedback to the gfortran folks as well as Fortran standards body.

However, re: some of the other comments in your latest post such as "non-default compiler options", "options specified in the command line which are actually default", "linking options", and "With IDE builds, there can be many options selected so which ones should be reported?", it appears to me Steve's comments in this thread have already addressed them, directly or indirectly.  What he has indicated appears perfectly acceptable to me as to how COMPILER_OPTIONS() would work in Intel Fortran. 

So when it comes to Intel Fortran, now that submodules (it seems it was a biggie in terms of effort) feature from Fortran 2008 standard has been implemented, it will be nice if the compiler team can quickly get to all the remaining aspects of the 2008 standard, with COMPILER_OPTIONS() being one such feature.  It'll be awesome to have Intel Fortran soon as a full feature Fortran 2008 compiler with more and more 2015 standard features being introduced as well - speed is of the essence!