fpConstant Compiler Flag Issue / Question

[JohnDrohan]

I'm porting a large amount of code from Composer 2019 to OneAPI HPC Fortran, keeping the compiler at IFORT for now. There is a large amount of data assigned into arrays as part of this code.

Our legacy code has used the fpConstant flag for easily the past 2 decades. On OneAPI, I'm seeing different behavior, specifically with declaring negatively signed data in array statements. I've replicated the issue with this minimal code example:

program FPConstantBugDemo

implicit none

! Variables
real *8 testVar(100)

! Body of FPConstantBugDemo

testVar(1:8) = [0.0, 0.0, 2.0, 0.0, -50.0, 10.0, 0.0, 1.0]
testVar(1:8) = [0.0d0, 0.0d0, 2.0d0, 0.0d0, -50.0d0, 10.0d0, 0.0d0, 1.0d0]

end program FPConstantBugDemo

With fpConstant active, a watch on testVar shows the following after the first data assignment, see array location 5, it is not -50.0 as desired:

  Name Value Type

◢	testVar(1:8)	(1:8)	REAL(8)
	testVar(1)	0.000000000000000D+000	REAL(8)
	testVar(2)	0.000000000000000D+000	REAL(8)
	testVar(3)	2.00000000000000	REAL(8)
	testVar(4)	0.000000000000000D+000	REAL(8)
	testVar(5)	1.610406229544812D-314	REAL(8)
	testVar(6)	10.0000000000000	REAL(8)
	testVar(7)	0.000000000000000D+000	REAL(8)
	testVar(8)	1.00000000000000	REAL(8)

After the second data assignment statement, the 5th element is properly set:

  Name Value Type

	testVar(1)	0.000000000000000D+000	REAL(8)
	testVar(2)	0.000000000000000D+000	REAL(8)
	testVar(3)	2.00000000000000	REAL(8)
	testVar(4)	0.000000000000000D+000	REAL(8)
	testVar(5)	-50.0000000000000	REAL(8)
	testVar(6)	10.0000000000000	REAL(8)
	testVar(7)	0.000000000000000D+000	REAL(8)
	testVar(8)	1.00000000000000	REAL(8)

With the fpConsant compiler flag off, both data assignment statements work as intended. Is this a bug, or does my massive codebase need to be refactored. Turning off fpConstant flag or refactoring will be a large effort regardless.

Thanks for any insights.

[Barbara_P_Intel]

I'm moving this over to the Fortran Forum since it's solely a Fortran issue.

[Barbara_P_Intel]

Thank you for reporting this issue. I see that wrong answer using -fpconstant with both ifx and ifort with the current release, as well as, with a preview version of 2024.1. I filed a bug report, CMPLRLLVM-56716. We'll let you know when it's fixed.

Does this reproducer work with Composer 2019?

As a side bar, why not take the plunge with ifx? The code generators are different between the two, the front ends are shared. In the long run it just might save you some time. I used to port apps between different vendors' Fortran compiler. It can be quite entertaining!

[JohnDrohan]

Hi Barbara,

Thanks so much for the response.

The sample code provided works perfectly well in Composer 2019.

Eventually, yes, we'll have to migrate our code base to ifx. However, for now, we need to do an incremental upgrade to the latest IFORT product provided with OneAPI HPC Toolkit. Our code base is so massive, coupled with an extremely large set of regression test cases, that we need to make sure we keep backward compatibility with prior results.

Our code base has origins in VAX Fortran77, with subsequent migrations to Digital, then Compaq, and finally to several versions of Intel. I think that if we migrate over multiple compilers, it will be extremely troublesome to diagnose any changes in our regression test case results. I think that a "one step at a time" approach makes the most sense for our application.

John

[Ron_Green]

@JohnDrohan  @Barbara_P_Intel this is a regression in v2024.0.0 ifx (and ifort from that package.).  The ifort and ifx in v2023.2.0 works as expected, as do all older versions.  John, you could try 2023.2.0 package if you have access to Intel Registration Center.

We'll try to get a fix expedited. 

[Ron_Green]

@JohnDrohan we have a fix for this.  Unfortunately it missed getting into the soon-to-be-released 2024.1.0.  It will appear in the 2024.2.0 release due around end of June to early July.

Before then I have a workaround.  First, this bug occurs when:

-fpconstant is used

Array constructor

Array constructor starts with a literal constant

Array constructor has some literal constant(s) 

That first literal constant in the array constructor does not have a sign!  Yes, odd isn't it?

So the workaround for this constructor that causes the problem

testVar(1:8) = [0.0, -1.0, 2.0, -3.0, 4.0, -5.0, 7.0, -8.0]

can use a workaround to fix the error thusly

testVar(1:8) = [+0.0, -1.0, 2.0, -3.0, 4.0, -5.0, 7.0, -8.0]

or

testVar(1:8) = [-0.0, -1.0, 2.0, -3.0, 4.0, -5.0, 7.0, -8.0]

If you only have a handful of array constructors with literal constants that start with a literal constant without a sign, adding a sign will fix the problem for now.  We will have a fix for the underlying error in June/July

Ron

[JohnDrohan]

@Ron_Green - Thanks so much for the reply.

Our code base containing such array declarations is unfortunately quite large, but thankfully, we have plenty of margin with respect to the timing of this compiler upgrade. The June/July timeframe shouldn't be a problem for us, however, I'll review the option to use the work-around with the team to get consensus.

Appreciate the update!

John