Compiler bug with fpp in 2024.2.1(2021.12.0) version

[netphilou31]

Hi,

I found a strange behavior with the version 2024.2.1 (2021.12.0) version of the IFORT compiler. A Fortran module is getting some fpp errors, while there is no compilation directives in it! The module compiles fine with earlier versions. Based on the identified location of the so called errors, I discovered that the module uses array of integers initialized with hexadecimal values written as something like #AB16D4. The preprocessor says:

HashData.f90(393): #error: unknown fpp directive.

while the corresponding line is the line #2 below.

    integer(4) :: k(64) = [ #D76AA478, #E8C7B756, #242070DB, #C1BDCEEE, #F57C0FAF, #4787C62A, #A8304613, #FD469501, &
                            #698098D8, #8B44F7AF, #FFFF5BB1, #895CD7BE, #6B901122, #FD987193, #A679438E, #49B40821, &
                            #F61E2562, #C040B340, #265E5A51, #E9B6C7AA, #D62F105D, #02441453, #D8A1E681, #E7D3FBC8, &
                            #21E1CDE6, #C33707D6, #F4D50D87, #455A14ED, #A9E3E905, #FCEFA3F8, #676F02D9, #8D2A4C8A, &
                            #FFFA3942, #8771F681, #6D9D6122, #FDE5380C, #A4BEEA44, #4BDECFA9, #F6BB4B60, #BEBFBC70, &
                            #289B7EC6, #EAA127FA, #D4EF3085, #04881D05, #D9D4D039, #E6DB99E5, #1FA27CF8, #C4AC5665, &
                            #F4292244, #432AFF97, #AB9423A7, #FC93A039, #655B59C3, #8F0CCC92, #FFEFF47D, #85845DD1, &
                            #6FA87E4F, #FE2CE6E0, #A3014314, #4E0811A1, #F7537E82, #BD3AF235, #2AD7D2BB, #EB86D391 ]

I found that changing the way the hexadecimal constants are written, for example Z'698098D8' instead of #698098D8, solved the issue. The other strange thing is that Fortran modules generated using the Fortran module wizard contain a lot of hexadecimal constants written this way and thy compile fine.

Any idea? I can provide the source code if needed.

Best regards,

[netphilou31]

Additional information.

The problem seems relating to the declaration of the array k() over several lines with continuation marks '&', because if all the declaration is made on a single line, no fpp error is issued.

Best regards,

[jimdempseyatthecove · Accepted solution]

Alternate hack to try:

    integer(4) :: k(64) = [ #D76AA478, #E8C7B756, #242070DB, #C1BDCEEE, #F57C0FAF, #4787C62A, #A8304613, #FD469501, &
                          & #698098D8, #8B44F7AF, #FFFF5BB1, #895CD7BE, #6B901122, #FD987193, #A679438E, #49B40821, &
...

(add & to front of each continuation line)

Jim Dempsey

[JohnNichols]

Somewhere in Metcalf and Eddy I saw recently that the &..........................& is required for some objects, I think it included arrays.  

Could be wrong. 

[netphilou31]

Hi John,

Can you give me more information about "Metcalf and Eddy" you are refering to?

Best regards,

[netphilou31]

Hi Jim and John,

Thanks for the reply and advices. I never thought that using a pair of & was something authorized by the Fortran compiler.

Anyway this is clearly a bug since this type of declaration was working in previous versions. Anyway I browsed all my source code to change the declaration of hexadecimal constants with # by the standard form Z'**bleep**' which is, unfortunately, a bit less easy to read but works (I did not change the sources codes automatically generated by the Fortran Module Wizard since they comile fine).

Best regards,

[netphilou31]

Not sure why my original text Z'.....' was replaced by  Z'**bleep**'

[andrew_4619]

the main use & & is used when a string is split across lines.

Buf = 'How now brown &
       &cow'

[netphilou31]

Hi Andrew,

I didn't know that there was a need to use a pair of & for a string split across lines.

Best regards,

[andrew_4619]

There a need for the 2nd &  if you start the second line in column 1, but otherwise without it you get unwanted  spaces. 

[jimdempseyatthecove]

FWIW fpp directives (are supposed to) start with # in column 1.

Therefore, if the continuation line started in column 1, you would have an error.

The sample you showed in post 1 did not show the continuation line starting in column1 so was your error elsewhere or is fpp accepting:

<NewLine><WhiteSpace>#...

as an fpp directive?

Jim Dempsey

[netphilou31]

Hi Jim,

I don't know what happened with fpp, but what I'm sure is that there was no issue with all versions of oneAPI prior 2024.2 but maybe that's a new way of parsing fpp directives or simply a bug.

To be complete, the fpp phase was giving me additional errors (3) on other places without any continuation, so it was a bit confusing and hard to understand the real source of the problem.

I could have identified more easily the issue if fpp was clearly mentioning the #698098D8 declaration instead of saying … #error: unknown fpp directive!

Best regards,

[MarcGrodent]

I would like to come back on the use of BOZ (binary, octal, hexadecimal) constants in an array constructor. From what I see in Fortran 2018, the use of BOZ constants is not allowed in an array constructor; they are allowed only in data statements and as actual arguments in some intrinsic procedures (such as INT). It seems that the new standard (Fortran 2023) has introduced the possibility to have BOZ constants in an array constructor (with a type specification: either integer or real).

That being said, my comments are as follows:

• Specifying an hexadecimal constant with a '#' (#D76AA478) is non-standard and should be avoided. The initial code provided by @netphilou31 leads to the same error with the latest IFX version 2025.2.1: 'unknown fpp directive'.  Indeed, a new line starting with a '#' indicates a preprocessor directive and the compiler gets lost.  However, the solution proposed by @jimdempseyatthecove  (adding an ampersand at the start of each continuation line) works.
• As already pointed out by @netphilou31 , a better solution is to use BOZ constants in the array constructor. This is allowed by IFX which obviously has already integrated this Fortran 2023 feature. In this case, there is no need of ampersands at the start of the continuation lines: 

    integer :: k(64) = [ Z'D76AA478', Z'E8C7B756', Z'242070DB', Z'C1BDCEEE', Z'F57C0FAF', Z'4787C62A', Z'A8304613', Z'FD469501', &
                         Z'698098D8', Z'8B44F7AF', Z'FFFF5BB1', Z'895CD7BE', Z'6B901122', Z'FD987193', Z'A679438E', Z'49B40821', &
                         Z'F61E2562', Z'C040B340', Z'265E5A51', Z'E9B6C7AA', Z'D62F105D', Z'02441453', Z'D8A1E681', Z'E7D3FBC8', &
                         Z'21E1CDE6', Z'C33707D6', Z'F4D50D87', Z'455A14ED', Z'A9E3E905', Z'FCEFA3F8', Z'676F02D9', Z'8D2A4C8A', &
                         Z'FFFA3942', Z'8771F681', Z'6D9D6122', Z'FDE5380C', Z'A4BEEA44', Z'4BDECFA9', Z'F6BB4B60', Z'BEBFBC70', &
                         Z'289B7EC6', Z'EAA127FA', Z'D4EF3085', Z'04881D05', Z'D9D4D039', Z'E6DB99E5', Z'1FA27CF8', Z'C4AC5665', &
                         Z'F4292244', Z'432AFF97', Z'AB9423A7', Z'FC93A039', Z'655B59C3', Z'8F0CCC92', Z'FFEFF47D', Z'85845DD1', &
                         Z'6FA87E4F', Z'FE2CE6E0', Z'A3014314', Z'4E0811A1', Z'F7537E82', Z'BD3AF235', Z'2AD7D2BB', Z'EB86D391' ]    

•  I have also tried to compile with gfortran 14.2.0. First, the use of hexadecimal constants written with a '#' in the array constructor leads to a syntax error. Second, the use of a BOZ constant is still forbidden: "BOZ literal constant cannot appear in an array constructor". I don't know what the situation is with the last version of gfortran (15.1)... Therefore, the only solution is to use the INT intrinsic function for each element of the array (example restricted here to two elements):

    integer :: k(2) = [int(Z'D76AA478'), int(Z'E8C7B756')]

As a conclusion, I would recommend this last approach as it is perfectly portable.

[JohnNichols]

The Fortran book is Metcalf, Reid and Cohen, fortran 95/2003 explained. 

Light reading for Einstein, the rest of us struggle. 

Re the use of the verb comile in an earlier post, Comile is a conjugated form of the verb compile. Learn to conjugate compile.

You learn something in this forum everyday. 

As a conclusion, I would recommend this last approach as it is perfectly portable.

Thanks for the note. 

[jimdempseyatthecove]

>> it is perfectly portable.

As long as:

1) real and integer have the same number of bits

2) storage is little-endian

3) the bit fields are the same (1-sign bit, 8-exponent bits, 23-mantissa bits with hidden 1 in msb bit)

Jim Dempsey

[Steve_Lionel]

Some further reading: Doctor Fortran in "We're All BOZos on This Bus" - Doctor Fortran