Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28863 Discussions

OverFlow Exception after updating ifort version XE2011 to OneAPI2021.4

JohnBeshop
Beginner
2,115 Views

Dear All,

 

I am new on this forum and I am facing a problem so confusing for me that this is one of the last place to find help

I have Fortran program including different versions of Fortran syntax (77 and 90) using paralellized OMP technics for some parts of the program. The program is used through a dll, main functions are called from an another main program. Interfaces functions are not paralellized.

 

I updated make file options from Intel parallel studio XE2011 to OneAPI2021.4. Flags options for the first version were:

 

ifeq ($(TYPE_COMPIL), optim)
FCFLAGS = /O2 /Qopenmp /Qfpp /Qparallel /Qopenmp-link:static \
/debug:full /debug-parameters:all
else
FCFLAGS = /GS \
/check:format,arg_temp_created /debug:full \
/debug-parameters:all /traceback /fpe0 /CU \
/Qfpp /Qopenmp /Qopenmp-link:static
endif
DFLAGS = /assume:byterecl /convert:big_endian /Qsafe-cray-ptr \
/DCN_RSIZE=4 /DCN_ISIZE=4 /DARCH64 /real-size:32 /integer-size:32

 

Flags options for the OneAPI2021.4 version were:

ifeq ($(TYPE_COMPIL), optim)
FCFLAGS = /O1 /fp:precise /Qopenmp /fpp /Qparallel /debug:full \
/debug-parameters:all
else
FCFLAGS = /GS /fp:precise \
/check:format,arg_temp_created /debug:full \
/debug-parameters:all /traceback /fpe0 /CU \
/fpp /Qopenmp
endif
DFLAGS = /assume:byterecl /convert:big_endian /Qsafe-cray-ptr \
/DCN_RSIZE=4 /DCN_ISIZE=4 /DARCH64 /real-size:32 /integer-size:32

 

 

To sum up I switched from O2 to O1, add /fp:precise option remove /Qfpp and /Qopenmp-link:static. These two last flags are no more supported by OneAPI version.

Compilation is OK but during runing the program some random overflow exception occurs on one array named SIG . This array made of 400 values is sometime well initialized and some time not, even though initializing loop is applied each time.

 

OMP instruction are used before array is initialized as followed:

 

C$OMP PARALLEL DO PRIVATE(I1,I2,J,J1,J2,IAS,LA,LL,XIRR,SIG,DRO,REF,FON,
C$OMP1                    NBVOL,S,SS,JDIM,CRN7,JJ,II,CRN5,CRN4,K,IS1,
C$OMP1                    IS2,IS3,NPINT,PAR,CRN1,CRN2,CRN3,CRN6,CRN,I)
C$OMP2            COPYIN(XEMOY,IDPRES,IIRRAD, /CCRN/,/CRN0/,/CRNEUT/,
C$OMP2                    /PARCRN/,/REFBIB/)
C$OMP3            SCHEDULE(GUIDED)

 

I suspect modification about OMP technic, but I have no idea about how to handle this problem. Any idea or thinkfull suggestion would be very much appreciated, thank you very much.

For any further information feel free to ask me.

All the best

JohnB.

 

 

 

 

 

 

 

0 Kudos
1 Solution
Barbara_P_Intel
Employee
1,888 Views

The workaround is needed beginning with 2021.10.0. Applying the workaround to your code will ease your migration to ifx.

@JohnBeshop, do you know that ifort is deprecated and will be no longer be available at the end of 2024?

ifx is the new Intel Fortran Compiler. It's evolving fast so you'll want to use the latest release, 2024.0.0.

 

View solution in original post

0 Kudos
12 Replies
jimdempseyatthecove
Honored Contributor III
2,094 Views

If your parallel region contains a CALL to a subroutine (or function) that uses one or more of the common blocks listed on your COPYIN, then that(those) procedure(s) will reference the main thread's common blocks (not the thread team member's copy).

What I suggest doing is:

1) add DEFAULT(none) to the PARALLEL DO

2) replace COPYIN with FIRSTPRIVATE

3) remove the /CommonBlockNames/

Compile, to produce an error list of variables of the common blocks that are used in the parallel region.

4) For each variable, verify the listed variable is contained in a former listed common block and if so, add those variable names to the FIRSTPRIVATE list, if not listed in one of the former listed common blocks then this may be a data sharing problem with your code to be investigated.

 

Jim Dempsey

0 Kudos
JohnBeshop
Beginner
2,026 Views

I tried following lines, I am not sure if it's correct could you confirm ? Thank you !

 

C$OMP PARALLEL DEFAULT(NONE)
C$OMP DO PRIVATE(I1,I2,J,J1,J2,IAS,LA,LL,XIRR,SIG,DRO,REF,FON,
C$OMP1                    NBVOL,S,SS,JDIM,CRN7,JJ,II,CRN5,CRN4,K,IS1,
C$OMP1                    IS2,IS3,NPINT,PAR,CRN1,CRN2,CRN3,CRN6,CRN,I)
C$OMP2            FIRSTPRIVATE(XEMOY,IDPRES,IIRRAD)
C$OMP3            SCHEDULE(GUIDED)
0 Kudos
jimdempseyatthecove
Honored Contributor III
2,017 Views

Yes.

Now when you compile, you will receive error reports of the use of references to the COMMON block variables made within the parallel region. You may also get error reports of other variables in the scope of the procedure reference in the parallel region. For the common block variables in error, add to the FIRSTPRIVE clause. If any procedure scoped variables reported as error, you will have to determine how it is to be used (private, shared, firstprivate).

 

Also it is important to make a build and run with all compile time checks (i.e. interfaces) and runtime checks (array bounds, uninitialized variables, etc...). After any resolutions, you can then remove the checks.

 

Jim Dempsey

0 Kudos
jimdempseyatthecove
Honored Contributor III
2,089 Views

Also, have you bult a Debug (OpenMP) configuration with all compile time and runtime diagnostics enabled? This will verify your interfaces, index out of bounds and some of the uninitialized variable accesses.

 

When you reach the point of modernizing your code, consider converting the common blocks into module user defined types:

! YourModuleNameHere.f90
module commons_mod
type CCRN_t
  real :: variableNameHere
  ...
end type CCRN_T
!$OMP threadprivate(CCRN)
type(CCRN_T) :: CCRN
... ! other types here
end module commons_mod

Then in your code where referencing those data add:

    use commons_mod

 

To reference the variables

     CCRN%variableNameHere

 

Whole word Find and Replace will make quick work of the edits.

 

Note, you can also threadprivate(/YourCommonBlockHere/), but that might introduce additional problems if your use of accessing the common blocks is not consistent.

 

Jim Dempsey

0 Kudos
JohnBeshop
Beginner
2,079 Views

Hi Jim,

 

Thanks a lot for your advice, I will try them and let you know how it works in few days. Any how it's not tell me why it seems to work with XE2011 but not with OneAPI2021.4.

Any how appreciate your help !

 

All the best

JohnB

0 Kudos
Steve_Lionel
Honored Contributor III
2,069 Views

Incorrect programs with undefined behavior may seem to "work", but then fail with a compiler or settings change. 

0 Kudos
JohnNichols
Valued Contributor III
2,023 Views

That was a real challenge when migrating from MS Fortran 3.13 to Powerstation, the changes nearly drove me crazy.

It is a much bigger problem with some of the modern languages such as C#. 

0 Kudos
Barbara_P_Intel
Employee
1,975 Views

There's this comment in the Fortran Release Notes about COMMON blocks and OpenMP data sharing clauses:

COMMON Block
Beginning with the Intel Fortran Compiler (ifx) version 2023.2.0 and the Intel Fortran Complier Classic (ifort) version 2021.10.0,
programs that declare a COMMON block, instead of individual COMMON block variables, in an OpenMP data sharing clause cause a runtime failure, i.e. segmentation fault or incorrect result. The workaround is to declare the individual COMMON block variables.

 

0 Kudos
JohnBeshop
Beginner
1,930 Views

Dear Barbara thank you for your help,

do you mean that for my version intel oneAPI 2021.4 the work around you proposed should work also ? Or do I have to use at least 2021.10.0 and apply this workaround ?

Thank you

0 Kudos
Barbara_P_Intel
Employee
1,889 Views

The workaround is needed beginning with 2021.10.0. Applying the workaround to your code will ease your migration to ifx.

@JohnBeshop, do you know that ifort is deprecated and will be no longer be available at the end of 2024?

ifx is the new Intel Fortran Compiler. It's evolving fast so you'll want to use the latest release, 2024.0.0.

 

0 Kudos
jimdempseyatthecove
Honored Contributor III
1,906 Views

Barbara,

What about the common block variables within /commonBlockName/ and

 

    !$omp threadprivate(/commonBlockName/)

 

Where the /commonBlockName/ is declared in a module and used elsewhere.

 

Jim Dempsey

0 Kudos
Lorri_M_Intel
Employee
1,893 Views

Hi Jim -

         THREADPRIVATE common blocks should be OK.

                            --Lorri

0 Kudos
Reply