Segfault in OpenMP in classic 2021.8.0 20221119

[dab]

Hi: I built our production code with the latest version of the oneAPI classic Fortran compiler, version 2021.8.0 20221119.  There's a step where an array is allocated in a subroutine and then used in a subsequent subroutine. Both subroutines are in a single section of an OpenMP parallel sections block. This has worked OK for years, both in ifort and gfortran. Under 2021.8.0, however, under both linux and windows, the generated code passes the incorrect address to the second subroutine. This leads to a segmentation fault when the contents of the array are accessed.

I attached a short program which reproduces the issue. The expected output is something like

<address>
<address>
<address>

but with the latest ifort, I get

<address>
                0
<address>

The 0 means that the second subroutine got the wrong address (or possibly that the array descriptor passed to the subroutine was not correctly filled in by the allocation in the first subroutine).

I also attached a CMakeFile.txt file to set the compiler options, but they're essentially -qopenmp -fno-inline. -fno-inline forces compiling the subroutines separately. This is the case in our production code where the routines are all in separate files.

Thanks,
Allen

[Barbara_P_Intel]

Thank you for the nice reproducer!

I duplicated the problem with ifort 2021.8.0 and an internal compiler version.

Curiously, it works ok with ifx 2023.0.0.

With which version of ifort does this work for you?

[dab]

Hi Barbara:
This is version of ifort which is working (tested on windows):
Version 18.0.2.185 Build 20180210

Thanks,
Allen

[Barbara_P_Intel]

Wow! That compiler was built almost 5 years ago. I tested other older compilers and it looks like the answers changed beginning with ifort (IFORT) 19.0.0.117 20180804.

I see two workarounds using the latest compilers:

1. With ifort remove -fno-inline
2. Use ifx with -qopenmp -fno-inline

As a former benchmark engineer it's an old trick to improve performance by inlining subroutine and function calls. I'm curious as to why you use -fno-inline?

When evaluating new versions of compilers it's good practice to reevaluate the compiler options. There can be a number of useful changes by default.

[Barbara_P_Intel]

I filed a bug report, CMPLRIL0-35128.

[dab]

(Gah. All of this thread was in my junk folder!)

I was just using no-inline with my example code to simulate that, as in building our production code, the routines in the parallel section are all compiled from separate files. In my example, if I let it inline the code it works OK.

Thanks for your help!

[Barbara_P_Intel]

Clever way to simulate your application!

[jimdempseyatthecove]

A couple of comments:

Should the problemsome procedure be inlined, the interface is discoverable at compile time. Should the interface to this procedure not have been provided to the calling procedure (and procedure not inlined), then the older calling convention is taken. The older calling convention does not pass array descriptors, instead it passes the 1st element.

Look at your code to assure that an interface is provided (you can use -warn interfaces or /warn:interfaces)

Jim Dempsey

[Barbara_P_Intel]

Since this reproducer works ok with ifx and you have another workaround, I am closing this case. I encourage you to begin using ifx if you haven't already.

This is a link to the ifort to ifx Porting Guide.