I am attempting to compile the following on intel MacOS 10.14.6 with what I think is the latest version of the ifort intel compiler. $ cat cte.f90 use iso_fortran_env, only: compiler_options, compiler_version character(*), parameter :: compiled_by = compiler_version() character(*), parameter :: com…

[image] FortranFan: … I am thinking there might be another “out” for these two functions to appear in constant expressions that Intel Fortran and I have not discovered yet. This is what I will try to check when I have a bit more time. Confirmed this is a bug in Intel Fortran. A support reque…

[image] RonShepard: … This is almost identical to an example in Modern Fortran Explained … Edit: With respect to the inquiry re: a bug in Intel Fortran in the original post, please see this comment post further below in this thread. The operative word is “almost”: you have the answer in the …

[image] FortranFan: The operative word is “almost”: you have the answer in the error message, “This intrinsic function is invalid in constant expressions.” The standard is rather limiting when it comes to what is allows in constant expressions and the standard defined functions from the intrinsi…

[image] pcosta: Perhaps it is related to this bug ? It looks like that bug was fixed in the version of the compiler that I’m using. If it is a bug in the compiler, and not my code, then perhaps they are related bugs. On a related question, in that example the trim() function was used. I’ve b…

As I read the standard further, I’m now unsure. My take earlier was that the standard states, “The types and procedures defined in standard intrinsic modules are not themselves intrinsic.” And thus compiler_version and compiler_option functions are not themselves intrinsic. Then in the section on…

The standard says the length of the returned values are “processor dependent” so the trim() seems prudent even if all the current implementations return it trimmed (not that I know if they do or not). At least two compilers replace the function call with a fixed string value, which would avoid any …

Gfortran compiles the code correctly. However, I don’t know if that is an extension or, as MFE states, if that is consistent with f2008+.

The code also compiles with nagfor: $ nagfor -c cte.f90 NAG Fortran Compiler Release 7.1(Hanzomon) Build 7109 Warning: cte.f90, line 2: Unused PARAMETER COMPILED_BY Warning: cte.f90, line 3: Unused PARAMETER COMPILED_WITH [NAG Fortran Compiler normal termination, 2 warnings]

I found a workaround for the Intel bug on compiler_version and compiler_options: putting the function result into an allocatable character scalar because you don’t know in advance how long it will be. However an Intel oddity remains, as indicated in the comment lines at the beginning of my test pro…

Yes, the intel compiler functions work alright when the functions appear in executable statements. The bug is when they appear in initialization statements such as for character parameters. Regarding the newline, that is a feature of list-directed i/o. The compiler has great freedom to add spaces a…

Code or Compiler Error?

Help

pcosta August 30, 2022, 10:08pm 2

Perhaps it is related to this bug?

Topic		Replies	Views
IEEE Fortran module Help	4	581	January 15, 2023
User defined functions in constant expressions	5	1990	August 29, 2021
Intel Fortran 2023 Launch Announcements	31	4297	April 3, 2023
Fortran 2018 standard issue	9	1693	March 29, 2022
Constant expressions for bind(C) name Help	6	1184	June 2, 2021

Code or Compiler Error?

Related topics