- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I recently updated my Intel fortran and have significant runtime issues that previously were not a problem in Intel Fortran or gfortran.
The first issue is that sometimes DO CONCURRENT(I=1:10) with have an iteration with I=11, which raises an index error.
The second issue is when there is an ASSOCIATE construct within a DO CONCURRENT. When this occurs it fails to initialize the DO CONCURRENT index variable.
This is an example code that raises this error:
! This was not a problem with Intel(R) Visual Fortran Compiler 18.0.5.274 [Intel(R) 64] (Sets B=1)
! This error occurs with version 19.1.1.216 and 19.1.2.254
!
! This error occurs if you enable any one of the following Run-time Checks
! /check:uninit
! /check:bounds
! /check:stack
!
! Error seems to occur whenever there is two DO CONCURRENT loops and an ASSOCIATE construct.
!
! Also sometimes I get eratic behavior with multiple DO CONCCURENTS in a row.
!
! Note this compilation also raises the warning
! "Message remark #7712: This variable has not been used. [I] Main.f90 27 "
!
PROGRAM MAIN
IMPLICIT NONE
INTEGER, PARAMETER:: D1=5
INTEGER, DIMENSION(D1):: A,B
INTEGER:: I
!
A = 1
!
!First iteration has I=J=-858993460
! cmd prompt says: Run-Time Check Failure. The variable \'MAIN$I\' is being used in \'Main.f90(27,7)\' without being defined
DO CONCURRENT ( I = 1:D1 )
ASSOCIATE( PNT => A(I) )
B(I) = I
END ASSOCIATE
END DO
PAUSE
END PROGRAM
!
! Compiler Flags:
!
! /nologo
! /debug:full
! /Od
! /assume:nocc_omp
! /Qopenmp-offload-
! /Qdiag-error-limit:10
! /Qdiag-disable:6717
! /warn:declarations
! /warn:unused
! /warn:ignore_loc
! /warn:noalignments
! /warn:uncalled
! /warn:interfaces
! /fpe:0
! /fp:source
! /Qfp-stack-check
! /module:"C:\prog\obj\obj_x64_Debug\\"
! /object:"C:\prog\obj\obj_x64_Debug\\"
! /Fd"C:\prog\obj\obj_x64_Debug\vc150.pdb"
! /traceback
! /check:bounds
! /check:uninit
! /check:stack
! /libs:static
! /threads
! /dbglibs
! /c
My code has extensive use of DO CONCURRENT and ASSOCIATE for very large Derived Data Types, so refactoring to revert to a regular do is not an option.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Scott,
I have the same issue. We are currently migrating from IVF XE 2013 to XE 2020 (19.1.2.254) and I am getting the same runtime error (with the same behavior) when doing non regression tests. In my case it happens in a 32-bit dll, so it seems to be a general compiler problem. I previously tested the XE 2019 version of the compiler and I don't remember getting the problem. Fortunately, I don't have a lot of do concurrent constructs with nested associate statement. When I located the problem, I found weird to see these nested constructs (I did not write the code myself) so I assumed this kind of constructs were forbidden even if they worked in the past. I am also quite surprised that you get no answer from Intel or anyone else about this issue.
Best regards,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I've experience a non-DO CONCURRENT situation with ASSOCIATE that may be related. In my case it was related to performing the ASSOCIATE(AssociateVar=>xxx) within an OpenMP parallel region.
As best as I could diagnose there were two issues:
1) When the AssociateVar was not declared outside the scope of the parallel region
2) When the AssociateVar was declared with a different type and/or rank outside the scope of the parallel region
If possible, you may find a fix by declaring the associate variable (with same type and rank) outside the DO CONCURRENT to see if this affects correct code generation.
FWIW this may or may not not address the subscript out of bounds issue.
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The associate does work outside the DO CONCURRENT, the problem is within it with the 2020 compiler update.
I ended up having to downgrade my compiler back to the 2018 version (which has a ADVANCE="NO" compiler bug) which runs the code without a problem. I do not get the initialization error, the index has a value of 1 instead of undefined.
My problem is the code has complex data types that are looped through with ASSOCIATE construct to make the code easier to read.
For example, I would look across something like:
main%group(I)%sub(J)
which I would simplify to something like:
subJ => main%group(I)%sub(J)
The issue is that I and J are undefined when they are DO CONCURRENT loop indexes.
Unfortunately this code is about 500,000 lines and substantially uses DO CONCURRENT to take advantage of its multi-index looping and logical check
(for example DO CONCURRENT(I=1:N,J=1:M, CHECK(I,J)>0) )
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I had also issues with OpemMP and ASSOCIATE. An older thread give some more information here. -O3 was not a good idea in my case, -O2 worked so far. Maybe these two issues are linked?
Currently, I avoid using ASSOCIATE within an OpenMP region.
For DO CONCURRENT it might be easier to nail it down, because only the Fortran standard and not in addition the OpemMP standard has to be taken into account.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
It seems the reverse is also true. I just experienced a problem with a DO CONCURRENT inside an ASSOCIATE construct, itself part of a classical DO loop.
Here is an extract of my code:
if (PumparoundsCount /= 0) then
do I=1,PumparoundsCount
associate (pa => SetOfPumparounds(I))
N1 = pa%FromTray
N2 = pa%ToTray
N1M1 = N1 - 1
N1M1NC = N1M1*NC
XL(:) = 0.D0
YV(:) = 0.D0
do concurrent (J=1:NOCOMP, CMPD_INDEX(J) > 0)
XL(J) = PAR(JX+N1M1NC+CMPD_INDEX(J))
YV(J) = PAR(JY+N1M1NC+CMPD_INDEX(J))
end do
...
I had an access violation problem on the line where XL(J) is assigned, with the loop index, J, equal to 0!
Previously the assignement loop was done using a FORALL statement, which does not seem to show the problem.
I recently replaced the FORALL with a DO CONCURRENT because I remember reading an old post by Steve Lionel saying that a DO CONCURRENT is a FORALL done right (if I'm not wrong) ! So, I expected that a DO CONCURRENT was more effective than a FORALL (may be not in my case but who knows?).
Best regards,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Following on from this, I've found at least a couple of related issues in recent versions of the compiler:
1) DO CONCURRENT fails to copy a string from an array in XE2020U1; logged (and open) with Intel Support as issue 04643307.
2) It looks like the Intel Fortran compiler (18.0.3 and 19.0.5, at least) sometimes treats an associate-name as a shared variable in OpenMP loops. You can't specify an associate-name in a private clause, as it has no declaration. We found this in a regression in our code and worked around it by using local pointers instead. I never did get around to reporting this; probably because I think that cut down versions of the code weren't reproducing the problem.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Since our 2020 license is a shared one for our research center, I asked the server maintainer to submit a bug request on this issue. I am hopping he has done it and its in the que to get fixed.
For now I am stuck using my personal copy of 2018.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
RE: You can't specify an associate-name in a private clause, as it has no declaration.
A work around is to declare a like typed variable outside the parallel region. (It will be replaced with the ASSOCIATE)
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Same here, I switched most of my loops from FORALL to DO CONCURRENT from the same post (Also have read that in a number of other online references). I did not think about moving back to a FORALL (though most of the new code from the past two years was originally written with DO CONCURRENT, so I am not sure if they will work with FORALL)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I just wanted to bump this because it was never fixed.
I also have the same issue with the associate block outside of a do concurrent.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for nudge on this issue.
I just checked this using a preview version of ifx 2024.1.0. No errors using any of those /check compiler options. That release is planned to be available in 4-6 weeks.
FYI... /check:uninit with ifx is a no-op. With ifx 2024.1.0 a warning message is printed about that.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
That is awesome to hear. about ifx.
How about ifort, that was the compiler that also triggers the error.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ditto for ifort 2021.12.0. It runs ok.
You do realize that ifort is deprecated and will no longer be distributed by the end of 2024, right?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, but I will still continue using it for a while before I port code over. There are still runtime issues with ifx (going to submit it when I have some time) and it still does not run as fast as ifort for my projects.
Also, I think a lot of people are hoping that ifort will get another year of life out of it at the last minute
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
ifx 2024.1.0 was just released. I verified that the problems with DO CONCURRENT and ASSOCIATE are fixed.
Enjoy!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks!
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page