27 June 2025
Today Intel(R) Fortran version 2025.2.0 was released.
It is available for download from our product page HERE.
But instead of that download page, I would recommend that you download our Intel® Fortran Essentials package. The Essentials package contains the Fortran compile plus tools you probably want to go along with Fortran. The package contents:
Fortran developers with numeric workloads can use this bundle to compile, debug, and use the most popular performance libraries in the Intel oneAPI HPC Toolkit for Intel CPUs and GPUs.
Intel® Fortran Compiler
Intel Distribution for GDB
Intel MPI Library
oneMKL
Download the Fortran Essentials package HERE (look for “Intel® Fortran Essentials” on this downloads page)
The Release Notes are HERE.
Along with many fixes for customer reported bugs, the highlights for this release include:
New Fortran 2023 features in this release:
A data component whose type has a coarray potential subobject component may be an array.
Intrinsic function SELECTED_LOGICAL_KIND has been implemented.
New Features in this release:
The IEEE_SCALB (X, I) now permits the I argument to be of type real with the same kind type parameter as the X argument (Fortran 2018 interpretation)
Option assume inline_cloc causes the compiler to generate inline code for the C_LOC function from the intrinsic module procedure ISO_C_BINDING. The default is assume noinline_cloc, which treats C_LOC as a call to an external function.
New OpenMP features in this release:
OpenMP 6.0
The STRIPE loop transformation construct has been implemented.
The NOWAIT clause now has an optional do-not-synchronize logical argument.
Thanks for asking this question @hkvzjal. I never managed to debug in VScode and Windows. For debugging, I have to use VS integration but it is not as good as VS code.
As far as I know Intel is not contributing to VSCode + gdb-oneapi. But the team that does Integrations work is separate from us, works on all of oneAPI tools, and is based in India. That said, I have no idea.
I am not sure what you are asking. The values returned by SELECTED_LOGICAL_KIND(bits) are Fortran KIND numbers. Nothing to do with C. For C, c_bool is a kind. Do you want the value of that for the Intel compiler? Keep in mind that other vendors may use other values for the KINDs.
You can find these values in the compiler includes, specifically:
< compiler root path>/compiler/latest/opt/compiler/include/iso_c_binding.f90
Also in that directory is iso_fortran_env.f90
So you can see the parameters we use for KINDS. Again, other compilers may or may not use the same numbering.
In reviewing the documentation page I entered a change request. I do not like that the returns are given as simple integers. They should be documented as ISO_FORTRAN_ENV kinds, like this:
Returned KINDs from ISO_FORTRAN_ENV along with the corresponding integer values
i = SELECTED_LOGICAL_KIND(8) ! returns LOGICAL8 ( 1 )
i = SELECTED_LOGICAL_KIND(16) ! returns LOGICAL16 ( 2 )
i = SELECTED_LOGICAL_KIND(32) ! returns LOGICAL32 ( 4 )
i = SELECTED_LOGICAL_KIND(64) ! returns LOGICAL64 ( 8 )
I = SELECTED_LOGICAL_KIND(128) ! returns -1 because there is no logical kind
The SELECTED_LOGICAL_KIND() intrinsic allows selection only based on the number of bits, not on the convention(s) used by the processor for that number of bits. Common conventions used by various languges and compilers are 1) take the least significant bit only (1->T, 0->F) and ignore the rest, 2) use all bits (0->F, anything else->T), 3) use all bits (0->F, -1->T, with twos-complement convention, any other bit pattern is undefined or not allowed), 4) use all bits (0->F, 1->T, any other bit pattern is undefined or not allowed). I think C uses convention 2 and is consistent with the use of .true._c_bool and .false._c_bool from the iso_c_binding module. Perhaps more flexibility will be added to SELECTED_LOGICAL_KIND() in the future to allow selection and interconversion among the various possible conventions.
My GitHub actions pipeline fails because OPENMP_VERSION is not available anymore:
/home/runner/work/DAMASK/DAMASK/src/parallelization.f90(118): error #6404: This name does not have a type, and must have an explicit type. [OPENMP_VERSION]
print'(1x,a,i0)', 'OpenMP version: ',openmp_version
I can shed some insight into how the Intel compiler determines .TRUE. vs .FALSE. First, default behavior:
compiler default is to do lower bit set for TRUE, so ODD_FOR_TRUE and FALSE otherwise. Now you can change this behavior with a compatibility option ‘fpscomp’, for Fortran Power Station Compatibility. Look for ‘fpscomp[: | space[no]]logicals’ on this page in the dev guide. This can change the patterns for true and false to be compatible with old Compaq Visual Fortran: The literal constant .TRUE. has an integer value of -1, and the literal constant .FALSE. has an integer value of 0. This representation is used by Compaq Visual Fortran. The internal representation of LOGICAL values is not specified by the Fortran standard. Programs that use integer values in LOGICAL contexts, or that pass LOGICAL values to procedures written in other languages, are non-portable and may not execute correctly. Intel recommends that you avoid coding practices that depend on the internal representation of LOGICAL values.*
You can read the writeup in the Developer Guide and Reference link I provided above.
I am not sure where openmp_version is set in your application. It’s not set by ifx.
We do set predefined macro _OPENMP compatible with other compilers. But only if you compile with -qopenmp, otherwise it is not set.
It looks like this variable was indeed set in ifx 2024.0.0: Compiler Explorer
It’s included in the OpenMP 5.2 spec (and presumably also earlier versions), Section 18.1, pg. 348:
The default integer named constant openmp_version with a value yyyymm where yyyy and mm are the year and month designations of the version of the OpenMP Fortran API that the
implementation supports; this value matches that of the C preprocessor macro _OPENMP, when
a macro preprocessor is supported (see Section 3.3).
Edit: second version, testing if openmp_version matches _OPENMP (Compiler Explorer).
@ivanpribec and @MarDie thank you for explaining this to me. I was not aware of this as my primary focus is Fortran Language features and secondary on OMP. This then is a bug and I’ll get a bug report opened.
Interesting … seems the mod file is the problem. It is set correctly in omp_lib.h
compiler/latest/opt/compiler/include/omp_lib.h: parameter(openmp_version=202111)
and this works:
$ more ompversion2.f90
program openmpversion
include 'omp_lib.h'
print'(1x,a,i0)', 'OpenMP version: ',openmp_version
end program openmpversion
I’ve never heard of it, so I had to look it up: it looks like Microsoft Fortran Power Station was discontinued in 1997, over 28 years ago. It looks like it ran on Windows 95. Did a lot of people use it? Are there still a lot of codes written for it that have to be ported?
out of curiosity, how do we obtain