Solved: ifx OpenMP compilation segmentation fault - Page 2

jvo203 · ‎04-18-2023

The attached "fixed_array.f90" code compiles fine with gfortran and ifort but fails with the new ifx.

No problems with ifort:

chris@capricorn:/tmp> ifort -Ofast -qopenmp fixed_array.f90 -o fixed_array.o -c

A segmentation fault with ifx:

chris@capricorn:/tmp> ifx -Ofast -qopenmp fixed_array.f90 -o fixed_array.o -c
#0 0x0000000001fc5727 (/opt/intel/oneapi/compiler/2023.1.0/linux/bin-llvm/xfortcom+0x1fc5727)
#1 0x0000000001fc5850 (/opt/intel/oneapi/compiler/2023.1.0/linux/bin-llvm/xfortcom+0x1fc5850)
#2 0x00007f191b2bf420 __restore_rt (/lib64/libc.so.6+0x3e420)
#3 0x00000000039d23ae (/opt/intel/oneapi/compiler/2023.1.0/linux/bin-llvm/xfortcom+0x39d23ae)
#4 0x00000000039ce5f5 (/opt/intel/oneapi/compiler/2023.1.0/linux/bin-llvm/xfortcom+0x39ce5f5)
#5 0x00000000039a2473 (/opt/intel/oneapi/compiler/2023.1.0/linux/bin-llvm/xfortcom+0x39a2473)
#6 0x00000000039a22f3 (/opt/intel/oneapi/compiler/2023.1.0/linux/bin-llvm/xfortcom+0x39a22f3)
#7 0x0000000002e97add (/opt/intel/oneapi/compiler/2023.1.0/linux/bin-llvm/xfortcom+0x2e97add)
#8 0x00000000022ebeec (/opt/intel/oneapi/compiler/2023.1.0/linux/bin-llvm/xfortcom+0x22ebeec)
#9 0x0000000002e84fbd (/opt/intel/oneapi/compiler/2023.1.0/linux/bin-llvm/xfortcom+0x2e84fbd)
#10 0x00000000022f30b7 (/opt/intel/oneapi/compiler/2023.1.0/linux/bin-llvm/xfortcom+0x22f30b7)
#11 0x0000000002e8519d (/opt/intel/oneapi/compiler/2023.1.0/linux/bin-llvm/xfortcom+0x2e8519d)
#12 0x00000000022eaa8a (/opt/intel/oneapi/compiler/2023.1.0/linux/bin-llvm/xfortcom+0x22eaa8a)
#13 0x0000000001f08104 (/opt/intel/oneapi/compiler/2023.1.0/linux/bin-llvm/xfortcom+0x1f08104)
#14 0x0000000001f06b83 (/opt/intel/oneapi/compiler/2023.1.0/linux/bin-llvm/xfortcom+0x1f06b83)
#15 0x0000000001eb5859 (/opt/intel/oneapi/compiler/2023.1.0/linux/bin-llvm/xfortcom+0x1eb5859)
#16 0x00000000020797c5 (/opt/intel/oneapi/compiler/2023.1.0/linux/bin-llvm/xfortcom+0x20797c5)
#17 0x00007f191b2a8bb0 __libc_start_call_main (/lib64/libc.so.6+0x27bb0)
#18 0x00007f191b2a8c79 __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x27c79)
#19 0x0000000001cf1729 (/opt/intel/oneapi/compiler/2023.1.0/linux/bin-llvm/xfortcom+0x1cf1729)

fixed_array.f90: error #5633: **Internal compiler error: segmentation violation signal raised** Please report this error along with the circumstances in which it occurred in a Software Problem Report. Note: File and line given may not be explicit cause of this error.
compilation aborted for fixed_array.f90 (code 3)

It doesn't matter if "-qopenmp" or "-fopenmp" is used. The OpenMP comes into play in other source code files as part of a large mixed-source C / FORTRAN project.

The error goes away without the OpenMP flag:

chris@capricorn:/tmp> ifx -Ofast fixed_array.f90 -o fixed_array.o -c

The Intel CPU is "model name : Intel(R) Xeon(R) CPU E5-1620 v3 @ 3.50GHz", OS is 64-bit openSUSE Tumbleweed.

chris@capricorn:/tmp> uname -a
Linux capricorn 6.2.10-1-default #1 SMP PREEMPT_DYNAMIC Thu Apr 6 10:36:55 UTC 2023 (ba7816e) x86_64 x86_64 x86_64 GNU/Linux

Ron_Green · ‎04-20-2023

Bug ID is CMPLRLLVM-46969

Reproducer reduced to this:

subroutine to_fixed()

implicit none

integer(kind=4) :: i, j

! ICE needs DO CONCURRENT with Internal BLOCK and must be 2D

! Interesting, only 2D do concurrent causes ICE

! for 1D this does not ICE

! do concurrent(i=1:16) no ICE for this 1D case

!

do concurrent(j=1:16, i=1:16)

block

integer :: x1

end block

end do

end subroutine to_fixed

View solution in original post

Ron_Green · ‎08-07-2023

we're investigating this new reproducer.

Ron_Green · ‎08-10-2023

I opened a new bug a few days ago against intel_fixed_array.f90
CMPLRLLVM-50415

This is an interesting case. It reminds me of MKL calls within parallel regions. We allow control of MKL to be parallel (default) or serial via the -mkl option. Also, MKL has a rich set of env vars to control parallelism and threading levels on individual library families within MKL. This is specifically to control the nested parallelism wherein an MKL call is within an OMP PARALLEL region.

Perhaps we need to consider this model to control the nesting of parallelism with DO CONCURRENT. Perhaps with combinations of compiler options, env vars, and/or directives at the loop scope. I am talking to the team about this. but for the short term, let's see if we can get a fix for this blatant bug before we hit code freeze for the next version at the end of this month.

jvo203 · ‎08-10-2023

Thank you, that's great to hear. Nested parallelism is kind of like a Pandora's box.