OverFlow Exception after updating ifort version XE2011 to OneAPI2021.4

[JohnBeshop]

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.

[jimdempseyatthecove]

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

[JohnBeshop]

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)

[jimdempseyatthecove]

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

[jimdempseyatthecove]

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

[JohnBeshop]

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

[Steve_Lionel]

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

[JohnNichols]

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

[Barbara_P_Intel]

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.

[JohnBeshop]

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

[Barbara_P_Intel · Accepted solution]

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.

[jimdempseyatthecove]

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

[Lorri_M_Intel]

Hi Jim -

         THREADPRIVATE common blocks should be OK.

                            --Lorri