- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This is great news, I will be looking forward to 2023.0. Thank you for the hard work.
![](/skins/images/D2683F18326913BBA0436CB7114DD569/responsive_peak/images/icon_anonymous_message.png)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page