Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
FPGA community forums and blogs have moved to the Altera Community. Existing Intel Community members can sign in with their current credentials.
29317 Discussions

Compiler bug with fpp in 2024.2.1(2021.12.0) version

netphilou31
New Contributor III
1,579 Views

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,

0 Kudos
1 Solution
jimdempseyatthecove
Honored Contributor III
1,423 Views

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

View solution in original post

0 Kudos
15 Replies
netphilou31
New Contributor III
1,515 Views

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,

0 Kudos
jimdempseyatthecove
Honored Contributor III
1,424 Views

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

0 Kudos
JohnNichols
Valued Contributor III
1,382 Views

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

Could be wrong. 

0 Kudos
netphilou31
New Contributor III
1,199 Views

Hi John,

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

Best regards,

0 Kudos
netphilou31
New Contributor III
1,220 Views

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,

0 Kudos
netphilou31
New Contributor III
1,202 Views

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

0 Kudos
andrew_4619
Honored Contributor III
1,065 Views

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

Buf = 'How now brown &
       &cow'
0 Kudos
netphilou31
New Contributor III
1,041 Views

Hi Andrew,

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

Best regards,

0 Kudos
andrew_4619
Honored Contributor III
887 Views

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

0 Kudos
jimdempseyatthecove
Honored Contributor III
836 Views

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

0 Kudos
netphilou31
New Contributor III
786 Views

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,

0 Kudos
MarcGrodent
New Contributor I
341 Views

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.

0 Kudos
JohnNichols
Valued Contributor III
313 Views

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. 

0 Kudos
jimdempseyatthecove
Honored Contributor III
297 Views

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

0 Kudos
Steve_Lionel
Honored Contributor III
276 Views
0 Kudos
Reply