- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Ron,
I see that 2024.2 version looks to be available. Just wanted to confirm that the bug is fixed in that version before I download and install.
Thanks,
John
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@JohnDrohan I checked the status, and indeed, the issue is fixed in the 2024.2 release of the compiler.
![](/skins/images/7FC17B7B85029576C25F1E43CE255B51/responsive_peak/images/icon_anonymous_message.png)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page