Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Is there a Version Function?

ferrad01
Beginner
1,906 Views
We do our builds with Intel Fortran v10 and v11, and with various subbuilds as well. Is there a system function I can call to return the full version number of the compiler?
0 Kudos
1 Solution
Steven_L_Intel1
Employee
1,906 Views
Today, your resources for this are:

  • The __INTEL_COMPILER and __INTEL_COMPILER_BUILD_DATE preprocessor symbols (see documentation under Building Applications > Preprocessing > Using Predefined Processor Symbols
  • The /Qsox option which embeds in the object code full information about the compiler version and command options. This cannot be readily retrieved by the program, though.
Fortran 2008 (draft) defines a COMPILER_VERSION function in intrinsic module ISO_FORTRAN_ENV which would be just what you want, but we don't support that yet.

I would suggest that __INTEL_COMPILER is probably what you want today. It will let you distinguish 11.0 from 11.1, for example. You can use !DEC$ IF to test for this without enabling preprocessing.

View solution in original post

0 Kudos
13 Replies
jimdempseyatthecove
Honored Contributor III
1,906 Views

Why not declare a parameter dependent on the version?
0 Kudos
TimP
Honored Contributor III
1,906 Views

Why not declare a parameter dependent on the version?
We're assuming you're familiar with the "Predefined Preprocessor Symbols."
0 Kudos
jimdempseyatthecove
Honored Contributor III
1,906 Views

While you can use preprocessor symbols I was suggesting something simpler.

The user is in control of the build environments (i.e. selection of compiler).

While the user can use the FPP in the build using the predefined processor symbols toaugment code generation, they could alternately modify the solution/project files to provide their own numeric or logical value for build. This value is included in the Fortran generated portion of the solution (e.g. in COMMON or in a module) .AND. the variable will be visible by the non-Fortran components as well as Fortran built DLL where one DLL is to service different builds (F10 and F11). In the latter cases the FPP solution might not be sufficient.

Jim Dempsey
0 Kudos
ferrad01
Beginner
1,906 Views

Why not declare a parameter dependent on the version?
Then I would have to modify the build process to generate a (include) file. While this is simple if I am in charge of the build process (I'm not), it would be easier if there was a function call.
0 Kudos
ferrad01
Beginner
1,906 Views

While you can use preprocessor symbols I was suggesting something simpler.

The user is in control of the build environments (i.e. selection of compiler).

While the user can use the FPP in the build using the predefined processor symbols toaugment code generation, they could alternately modify the solution/project files to provide their own numeric or logical value for build. This value is included in the Fortran generated portion of the solution (e.g. in COMMON or in a module) .AND. the variable will be visible by the non-Fortran components as well as Fortran built DLL where one DLL is to service different builds (F10 and F11). In the latter cases the FPP solution might not be sufficient.

Jim Dempsey
I'm not in control of the build environments. We have one set of source files which is compiled using a multitude of compilers and versions. How can I create one file with the version?
0 Kudos
Steven_L_Intel1
Employee
1,907 Views
Today, your resources for this are:

  • The __INTEL_COMPILER and __INTEL_COMPILER_BUILD_DATE preprocessor symbols (see documentation under Building Applications > Preprocessing > Using Predefined Processor Symbols
  • The /Qsox option which embeds in the object code full information about the compiler version and command options. This cannot be readily retrieved by the program, though.
Fortran 2008 (draft) defines a COMPILER_VERSION function in intrinsic module ISO_FORTRAN_ENV which would be just what you want, but we don't support that yet.

I would suggest that __INTEL_COMPILER is probably what you want today. It will let you distinguish 11.0 from 11.1, for example. You can use !DEC$ IF to test for this without enabling preprocessing.
0 Kudos
jimdempseyatthecove
Honored Contributor III
1,906 Views

If you are in contol of the source files but not in control of the build environment (i.e. you distribute sources for the end-user to compile), then it is also likely that you are in control of the distribution of the MAKE files or Project/Solution files. In those you can probe the system (e.g. environment variables) and thus produce a "build" that is dependent on the build environment. See Steve's suggeston as to the compiler visible "macro".

Your choices then are:

1) produce different code based on environment/versions
2) produce same code but different global variable used for code path selection.

Method 1) may require all code to be compiled per environment
Method 2) permits libraries to be built once, then select the path at run time.

Note, Steve's method would have to be expanded due to users having non-Intel compilers.

Jim Dempsey
0 Kudos
ferrad01
Beginner
1,906 Views
Today, your resources for this are:

  • The __INTEL_COMPILER and __INTEL_COMPILER_BUILD_DATE preprocessor symbols (see documentation under Building Applications > Preprocessing > Using Predefined Processor Symbols
  • The /Qsox option which embeds in the object code full information about the compiler version and command options. This cannot be readily retrieved by the program, though.
Fortran 2008 (draft) defines a COMPILER_VERSION function in intrinsic module ISO_FORTRAN_ENV which would be just what you want, but we don't support that yet.

I would suggest that __INTEL_COMPILER is probably what you want today. It will let you distinguish 11.0 from 11.1, for example. You can use !DEC$ IF to test for this without enabling preprocessing.

Thanks Steve, we will try this solution first.
0 Kudos
ferrad01
Beginner
1,906 Views

If you are in contol of the source files but not in control of the build environment (i.e. you distribute sources for the end-user to compile), then it is also likely that you are in control of the distribution of the MAKE files or Project/Solution files. In those you can probe the system (e.g. environment variables) and thus produce a "build" that is dependent on the build environment. See Steve's suggeston as to the compiler visible "macro".

Your choices then are:

1) produce different code based on environment/versions
2) produce same code but different global variable used for code path selection.

Method 1) may require all code to be compiled per environment
Method 2) permits libraries to be built once, then select the path at run time.

Note, Steve's method would have to be expanded due to users having non-Intel compilers.

Jim Dempsey

Thanks for your replies, Jim. I am indeed in control of the SLN / VFPROJ files. I'm not sure how to probe the environment variables from these files though.
Adrian
0 Kudos
jimdempseyatthecove
Honored Contributor III
1,906 Views

In VS you use $(environmentVariableNameHere)
And in VS project Preprocessor Definitions you can define

FOO=$(environmentVariableNameHere)

Try it out first before you modify too much code.

Prior to the above working you will have to set the environment variable (or use one set by installation)

SET USE_IVF=IFORT_COMPILER90 (or IFORT_COMPILER11)

(set to C:Program FilesIntelCompilerFortran9.0 on my system)

Jim Dempsey
0 Kudos
ferrad01
Beginner
1,906 Views

In VS you use $(environmentVariableNameHere)
And in VS project Preprocessor Definitions you can define

FOO=$(environmentVariableNameHere)

Try it out first before you modify too much code.

Prior to the above working you will have to set the environment variable (or use one set by installation)

SET USE_IVF=IFORT_COMPILER90 (or IFORT_COMPILER11)

(set to C:Program FilesIntelCompilerFortran9.0 on my system)

Jim Dempsey

Yes, but this requires actually setting the environment variable on the build machine, and remembering to change it when the compiler is changed. This is outside my control.
0 Kudos
ferrad01
Beginner
1,906 Views
Today, your resources for this are:

  • The __INTEL_COMPILER and __INTEL_COMPILER_BUILD_DATE preprocessor symbols (see documentation under Building Applications > Preprocessing > Using Predefined Processor Symbols
  • The /Qsox option which embeds in the object code full information about the compiler version and command options. This cannot be readily retrieved by the program, though.
Fortran 2008 (draft) defines a COMPILER_VERSION function in intrinsic module ISO_FORTRAN_ENV which would be just what you want, but we don't support that yet.

I would suggest that __INTEL_COMPILER is probably what you want today. It will let you distinguish 11.0 from 11.1, for example. You can use !DEC$ IF to test for this without enabling preprocessing.


What is the format for __INTEL_COMPILER ? Is it always 4 digits? The Help files gives an example 1010, would this signify version 10.1 or 10.10 ?
0 Kudos
Steven_L_Intel1
Employee
1,906 Views
Quoting - ferrad01


What is the format for __INTEL_COMPILER ? Is it always 4 digits? The Help files gives an example 1010, would this signify version 10.1 or 10.10 ?

It is not always four digits, but the right two digits are always the .xx. So, for example, 9.1 would be 910. 1010 is 10.1. I guess we left it open to having a subsidiary digit.
0 Kudos
Reply