Fortran program that does not use OpenMP at all malfunctions when compiled with `-qopenmp'

jbenda · ‎10-06-2022

I have the following Fortran program:

program p

   ! ----------------------------------------------------- !

   implicit none

   type wrapped_array
      real, allocatable :: reals(:)
   end type wrapped_array

   type wrapped_wrapped_array
      type(wrapped_array), allocatable :: arrays(:)
   end type

   ! ----------------------------------------------------- !

   type(wrapped_wrapped_array)      :: package
   type(wrapped_array), allocatable :: arrays(:)
   
   ! ----------------------------------------------------- !

   call init(package)
   call obtain(package, arrays)

   print *, allocated(arrays)

contains

   ! ----------------------------------------------------- !

   subroutine init (this)

      type(wrapped_wrapped_array), intent(inout) :: this

      allocate (this % arrays(10))

   end subroutine init

   ! ----------------------------------------------------- !

   subroutine obtain (this, arrays)

      type(wrapped_wrapped_array), intent(in) :: this
      type(wrapped_array), allocatable :: arrays(:)

      if (allocated(arrays)) deallocate(arrays)
      
      allocate (arrays, source=this%arrays)

   end subroutine obtain

   ! ----------------------------------------------------- !

end program p

It allocates an allocatable array attribute within an instance of a derived type `wrapped_wrapped_array` and then attempts to retrieve the same attribute using sourced allocation. If the outcome is allocated, which is expected, the output is 'T'. I get such output when I compile the code with `ifort test.f90 -o test` or `ifx test.f90 -o test`.

However, when I include the OpenMP switch, i.e. `ifort -qopenmp test.f90 -o test` or `ifx -qopenmp test.f90 -o test`, then the output is 'F', indicating a compiler/runtime error.

When compiling with GNU Fortran 12.2, the code works both with and without `-fopenmp`.

My version of the oneAPI compilers is the following:

$ ifort --version
ifort (IFORT) 2021.7.0 20220726
$ ifx --version
ifx (IFORT) 2022.2.0 20220730

While the output from valgrind (version 3.19.0) is clean when not using `-qopenmp`, it produces the following notices when OpenMP flag is included:

==12879== Conditional jump or move depends on uninitialised value(s)
==12879==    at 0x405C1A: for_alloc_copy (in [...])
==12879==    by 0x4057E8: p_IP_obtain_ (test.f90:48)
==12879==    by 0x4052F2: MAIN__ (test.f90:23)
==12879==    by 0x4051EC: main (in [...])
==12879==  Uninitialised value was created by a stack allocation
==12879==    at 0x405524: p_IP_obtain_ (test.f90:41)

I suspect this to be the Intel compiler issue.

I was not able to simplify the reproducer code further.

jbenda · ‎10-10-2022

The code works correctly also with the earlier revision of the compiler suite:

$ ifort --version
ifort (IFORT) 2021.6.0 20220226
Copyright (C) 1985-2022 Intel Corporation.  All rights reserved.

$ ifx --version
ifx (IFORT) 2022.1.0 20220316
Copyright (C) 1985-2022 Intel Corporation. All rights reserved.

Ron_Green · ‎10-10-2022

This one is interesting - what OS and version are you using? Do you know what version of gnu and glibc is installed?

I do not see the failure you see. It may be an incompatible glibc on your system? That is what I am wondering. Are you using an older RHEL 7 or older Ubuntu? I can try an old RHEL 7 system here. Maybe that is the problem.

ifx repro_for_alloc_copy.f90 -o test -what -V
Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2022.2.0 Build 20220730
Copyright (C) 1985-2022 Intel Corporation. All rights reserved.

 Intel(R) Fortran 22.0-1775.03
GNU ld version 2.37-27.fc36
$ 
$ ./test
 T

uname -a
Linux foobar 5.17.6-300.fc36.x86_64 #1 SMP PREEMPT Mon May 9 15:47:11 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
$ gcc --version
gcc (GCC) 12.0.1 20220413 (Red Hat 12.0.1-0)
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Ron_Green · ‎10-10-2022

Ah, could not compile on RHEL 7.

But I tried Ubuntu 18.04 and I am now seeing the issue. Are you using Ubuntu? What version are you using?

 ifort -what -V -o test -qopenmp repro_for_alloc_copy.f90 
Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.7.0 Build 20220726_000000
Copyright (C) 1985-2022 Intel Corporation.  All rights reserved.

 Intel(R) Fortran 2021.7.0-1776
GNU ld (GNU Binutils for Ubuntu) 2.30
$ ./test
 F

jbenda · ‎10-10-2022

I use openSUSE Tumbleweed 20220929 and openSUSE Leap 15.4 (based on SUSE Linux Enterprise SP4). The affected compiler suite (2022.2) fails in the same way on both systems. For the former (unsupported) operating system, the output is

ifx -what -V -o test -qopenmp test.f90 
Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2022.2.0 Build 20220730
Copyright (C) 1985-2022 Intel Corporation. All rights reserved.

 Intel(R) Fortran 22.0-1775.03
GNU ld (GNU Binutils; openSUSE Tumbleweed) 2.39.0.20220810-1

As for the Leap 15.4 computer, I downgraded oneAPI to 2022.1 earlier today because of the present issue, so the requested output here now features the older (and working) suite:

ifx test.f90 -o test -what -V
Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2022.1.0 Build 20220316
Copyright (C) 1985-2022 Intel Corporation. All rights reserved.

 Intel(R) Fortran 22.0-1296
GNU ld (GNU Binutils; SUSE Linux Enterprise 15) 2.37.20211103-150100.7.37

Tumbleweed uses GLIBC 2.36, GNU Binutils 2.39 and GCC 12.2.

Leap 15.4 uses GLIBC 2.31, GNU Binutils 2.37 and GCC 7.5.

Ron_Green · ‎10-11-2022

I am seeing the problem with ifort on a number of OSes and versions. But I can't get IFX to fail - IFX always gives me T.

The only SUSE system I have is SUSE 12 SP1 but ifx works on it and give T

can you confirm that IFX gives you "F" failure?

jbenda · ‎10-11-2022

Yes, I tried again with the newest compiler available in the Zypper repository:

$ ifx -qopenmp -V -what test.f90 -o test
Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2022.2.0 Build 20220730
Copyright (C) 1985-2022 Intel Corporation. All rights reserved.

 Intel(R) Fortran 22.0-1775.03
GNU ld (GNU Binutils; SUSE Linux Enterprise 15) 2.37.20211103-150100.7.37

$ ldd ./test
        linux-vdso.so.1 (0x00007ffe79cca000)
        libimf.so => /opt/intel/oneapi/compiler/2022.2.0/linux/compiler/lib/intel64_lin/libimf.so (0x00007f67461e4000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f6745e99000)
        libiomp5.so => /opt/intel/oneapi/compiler/2022.2.0/linux/compiler/lib/intel64_lin/libiomp5.so (0x00007f6745a5a000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f6745837000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f6745442000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f6745229000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f6745025000)
        libintlc.so.5 => /opt/intel/oneapi/compiler/2022.2.0/linux/compiler/lib/intel64_lin/libintlc.so.5 (0x00007f674675b000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f67465dc000)
        librt.so.1 => /lib64/librt.so.1 (0x00007f6744e1c000)

$ ./test 
 F

$ valgrind ./test
(...)
==17408== Conditional jump or move depends on uninitialised value(s)
==17408==    at 0x404C5A: for_alloc_copy (in /dev/shm/test)
==17408==    by 0x40482F: p_IP_obtain_ (in /dev/shm/test)
==17408==    by 0x40457A: MAIN__ (in /dev/shm/test)
==17408==    by 0x40444C: main (in /dev/shm/test)
(...)

$ ldd --version
ldd (GNU libc) 2.31
Copyright © 2020 Free Software Foundation, Inc.
(...)

$ ld --version
GNU ld (GNU Binutils; SUSE Linux Enterprise 15) 2.37.20211103-150100.7.37
Copyright (C) 2021 Free Software Foundation, Inc.
(...)

Some additional observations:

$ ifx -qopenmp test.f90 -o test -debug full -check all -traceback
$ ./test 
forrtl: severe (408): fort: (33): Shape mismatch: The extent of dimension 1 of array ARRAYS is 0 and the corresponding extent of array THIS is 10

Image              PC                Routine            Line        Source             
test               0000000000404ACC  obtain                     48  test.f90
test               0000000000404553  p                          23  test.f90
test               000000000040444D  Unknown               Unknown  Unknown
libc-2.31.so       00007F2DCFBCE29D  __libc_start_main     Unknown  Unknown
test               000000000040437A  Unknown               Unknown  Unknown

Ron_Green · ‎11-02-2022

I have tested this with an early build of the next major IFORT and IFX releases, what will be compiler version 2023 due out late 2022 or early 2023. This version has a fix for this issue for both IFORT and IFX.

We put in some changes in how OMP treats structures with arrays of structures with array components like this. These changes went into the front end shared by ifort and ifx.

Understand that this fix is in v2023. It will NOT be in any patch release of 2022, so if we have a v2022.2.1 or v2022.3 update between now and the end of the year you will NOT see the fix in that patch or update release. You have to wait for v2023.0.

jbenda · ‎11-02-2022

This is great news, I will be looking forward to 2023.0. Thank you for the hard work.