Triggering an ICE with ifx 2023.2 through 2025.2 and ifort 2023.2 #4666
Description
I'm hitting an ICE on ifx when building Fortran code which depends on AMReX. I've submitted a minimal reproducer to Intel, but I imagine you guys may want to write a workaround as well.
Here's my reproducer for AMReX in particular. This actually works just fine on AMReX 24.09, but triggers the ICE on 24.10 and newer.
I have a small module ice.f90:
module ice
implicit none
private
type, public :: foo
contains
procedure :: f
end type
contains
subroutine f(this, x)
use amrex_geometry_module, only: amrex_geometry
class(foo), intent(in) :: this
type(amrex_geometry), intent(in) :: x
end subroutine
end module iceAnd here is how I build amrex as well as that code:
cmake -S. -Bbuild \
-D BUILD_SHARED_LIBS=ON \
-D AMReX_FORTRAN=YES \
-D AMReX_FORTRAN_INTERFACES=YES \
-D CMAKE_INSTALL_PREFIX=install \
-D CMAKE_BUILD_TYPE=Release
cd build
make install
ifx -isystem ../install/include/ -c ice.f90 -o ice.oThis leads to the ICE:
#0 0x00000000033b7157 (/opt/intel/oneapi/compiler/2025.2/bin/compiler/xfortcom+0x33b7157)
#1 0x00000000033b7285 (/opt/intel/oneapi/compiler/2025.2/bin/compiler/xfortcom+0x33b7285)
#2 0x000072e6a803e540 (/usr/lib/libc.so.6+0x3e540)
#3 0x0000000003152e50 (/opt/intel/oneapi/compiler/2025.2/bin/compiler/xfortcom+0x3152e50)
#4 0x0000000003128080 (/opt/intel/oneapi/compiler/2025.2/bin/compiler/xfortcom+0x3128080)
#5 0x00000000031497ac (/opt/intel/oneapi/compiler/2025.2/bin/compiler/xfortcom+0x31497ac)
#6 0x0000000003127ec6 (/opt/intel/oneapi/compiler/2025.2/bin/compiler/xfortcom+0x3127ec6)
#7 0x00000000031576cf (/opt/intel/oneapi/compiler/2025.2/bin/compiler/xfortcom+0x31576cf)
#8 0x000000000314e752 (/opt/intel/oneapi/compiler/2025.2/bin/compiler/xfortcom+0x314e752)
#9 0x0000000003127c32 (/opt/intel/oneapi/compiler/2025.2/bin/compiler/xfortcom+0x3127c32)
#10 0x0000000003128080 (/opt/intel/oneapi/compiler/2025.2/bin/compiler/xfortcom+0x3128080)
#11 0x0000000003149655 (/opt/intel/oneapi/compiler/2025.2/bin/compiler/xfortcom+0x3149655)
#12 0x0000000003127ec6 (/opt/intel/oneapi/compiler/2025.2/bin/compiler/xfortcom+0x3127ec6)
#13 0x0000000003124625 (/opt/intel/oneapi/compiler/2025.2/bin/compiler/xfortcom+0x3124625)
#14 0x0000000003123971 (/opt/intel/oneapi/compiler/2025.2/bin/compiler/xfortcom+0x3123971)
#15 0x00000000031a7c9f (/opt/intel/oneapi/compiler/2025.2/bin/compiler/xfortcom+0x31a7c9f)
#16 0x000000000339d07d (/opt/intel/oneapi/compiler/2025.2/bin/compiler/xfortcom+0x339d07d)
#17 0x000000000329569f (/opt/intel/oneapi/compiler/2025.2/bin/compiler/xfortcom+0x329569f)
#18 0x0000000003476f7a (/opt/intel/oneapi/compiler/2025.2/bin/compiler/xfortcom+0x3476f7a)
#19 0x000072e6a8027675 (/usr/lib/libc.so.6+0x27675)
#20 0x000072e6a8027729 __libc_start_main (/usr/lib/libc.so.6+0x27729)
#21 0x00000000030d0bae (/opt/intel/oneapi/compiler/2025.2/bin/compiler/xfortcom+0x30d0bae)
ice.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 ice.f90 (code 3)
The main workaround for users is to either depend on older AMReX, or don't restrict with use ..., only:.
The simplest fix seems to be to just remove the seemingly no-op interface block for the destroy routine in amrex_geometry_module, but there may be more of this pattern I haven't run into yet. I'm working through building my code on a modified AMReX, and through other unrelated errors; will report if this is sufficient or if other changes are needed for ifx.