Serious bug in /opt/intel/oneapi/compiler/2025.2/bin/ifx

frs · ‎08-01-2025

Hi,

After many years of smooth running with the combo icx & ifx (formerly icc & ifort) on a elaborate code used in the CERN and worldwide accelerator community called MAD-X, I suddenly face an insurmountable bug with the "2025.2" version of ifx. The error I am getting is:

************************************************************************************************

ifx -m64 -O3 -warn all -warn nounused -warn nointerfaces -c -mp1 -fp-model strict -heap-arrays 65536 -assume noold_unit_star -module build/Linux64_ifx -fexceptions -no-wrap-margin -D_STATIC -D_ICX -D_ICX -D_IFX -D_LINUX -D_ONLINE -D_USE
GC -DSTATIC=static -Ilibs/gc/gc-8.0.2/include src/madx_ptc_normal.f90 -o build/Linux64_ifx/madx_ptc_normal.o
src/madx_ptc_normal.f90(58): internal error: Please visit 'http://www.intel.com/software/products/support' for assistance.
if(universe.le.0.or.EXCEPTION.ne.0) then
^
src/madx_ptc_normal.f90(58): catastrophic error: Internal Compiler Error: Ref module: ffe_cl.c
compilation aborted for src/madx_ptc_normal.f90 (code 1)
make[1]: *** [make/compiler.rules:39: madx_ptc_normal.o] Error 1
make[1]: Leaving directory '/extra2/MAD-X-Github-SC-Harry_07.25'
make: *** [Makefile_lnx:78: madx-linux64-intel] Error 2
frank4[01.08.25-19:55:57]>which ifx
/opt/intel/oneapi/compiler/2025.2/bin/ifx

(I left the version check of "ifx at the end)

So it even knows that it is an "internal error". At this point I can only kindly ask you for your help to debug this internal error since it seems pointless to try to debug our code!

Additional info:

The make command is: make madx-linux64-intel OPENMP=yes SHOW=yes STATIC=yes

so OPENMP=yes and a statically executable STATIC=yes is the goal.

My questions:

1) What additional help for debugging could I offer: tarred up code with make instructions?

2) How can I revert to the "2025.1" versions of "ifx" and "icx"?

Many Thanks in advance!

Cheers, Frank

Ron_Green · ‎08-04-2025

Have you tried with -O0, and -O2 instead of O3?

Have you tried changing -fp-model strict with -fp-model precise or removing the fpmodel option all together?

Have you tried removing -fexceptions ?

As for reverting back to 2025.1. did you leave 2025.1 on your system and then installed 2025.2? Or did you remove 2025.1?

frs · ‎08-05-2025

Dear Ron,

Let me first thank you for your kind reply! I was expecting such actions attempts to overcome

the issue and thereby finding that it may an issue of optimization.

Unfortunately, neither of these changes to the compile flags had any effect each by themselves

nor a combination of all 3 of them! I am afraid there is a real bug somewhere that only shows it

ugly face in a medium complex code that has C and F routines.

I am not sure what I could do to help overcome this blockage! Please let me know!

Concerning the issue of how to best going back to 2025.1:

The 2025.1 code is still there, EG compiling via:

/opt/intel/oneapi/compiler/2025.1/bin/ifx -m64 -O3 -warn all -warn nounused -warn nointerfaces -c -mp1 -fp-model strict -heap-arrays 65536 -assume noold_unit_star -module build/Linux64_ifx -fexceptions -no-wrap
-margin -D_STATIC -D_ICX -D_ICX -D_IFX -D_LINUX -D_ONLINE -D_USEGC -DSTATIC=static -Ilibs/gc/gc-8.0.2/include src/madx_ptc_normal.f90 -o build/Linux64_ifx/madx_ptc_normal.o

works perfectly fine just the /opt/intel/oneapi/compiler/2025.2/bin/ifx fails

What I would need is a command that let's me switch painlessly. Of course, I am

running: "source /opt/intel/oneapi/setvars.sh" which automatically points to the latest and

in my case failing version. Could you help with that also avoiding a full de-installation of 2025.2

Thanks a lot for all your help!

Cheers, Frank

andrew_4619 · ‎08-06-2025

I can only speak for the windows install but I would assume the same rules apply. The setvars you use is the generic one that uses the latest installation but each installation has its own version of setvars the name is version specific. Have I look and you should find it.....

frs · ‎08-06-2025

Dear Andew,

Thanks for that and I will try to retrieve the 2025.1 setvars.

Now actually this discussion brought me indirectly to a temporary and dirty workaround that let's we compile and link my code:

1)

I simply compile that one failing routine with the older compiler:

/opt/intel/oneapi/compiler/2025.1/bin/ifx -m64 -O3 -warn all -warn nounused -warn nointerfaces -c -mp1 -fp-model strict -heap-arrays 65536 -assume noold_unit_star -module build/Linux64_ifx -fexceptions -no-wrap
-margin -D_STATIC -D_ICX -D_ICX -D_IFX -D_LINUX -D_ONLINE -D_USEGC -DSTATIC=static -Ilibs/gc/gc-8.0.2/include src/madx_ptc_normal.f90 -o build/Linux64_ifx/madx_ptc_normal.o

2)

Then simply continue with the same command that worked for all other routines which in my case is:

make madx-linux64-intel OPENMP=yes SHOW=yes STATIC=yes

Of course my Makefiles handle these parameters internally.

3)

It goes without saying that is by no means a solution to the problem! Please let me know if I can be of any help to fix this compiler bug!

a) Please note that it happens for the last routine to be compiled and then just the link command follows. Not sure if that helps?

b) I could send you the file that dies on the compile if it might help the code developer.

Thanks so far for all your help!

Frank

andrew_4619 · ‎08-06-2025

The object files will be fully compatible from the two compilers. Yes post the failing file and any dependencies such as includes. That will allow the problem to be triaged.

frs · ‎08-07-2025

Hi Andrew,

Thanks again for the prompt response! Yes, I was sure of the compatibility of the two compilers!

However it is still just a workaround.

Okay, I have found a quick way to show the error and all is in file below and I hope that 9.1 MB is not

too large!

As usual one untars with :

tar xvfz bug_testing.tgz

That creates the directory "bug_testing".

In there I run the command:

ifx -m64 -O3 -warn all -warn nounused -warn nointerfaces -c -mp1 -fp-model strict -heap-arrays 65536 -assume noold_unit_star -module build/Linux64_ifx -fexceptions -no-wrap -margin -D_STATIC -D_ICX -D_ICX -D_IF
X -D_LINUX -D_ONLINE -D_USEGC -DSTATIC=static -ILinux64_ifx/ madx_ptc_normal.f90 -o madx_ptc_normal.o

and get the announced error message:

madx_ptc_normal.f90(58): internal error: Please visit 'http://www.intel.com/software/products/support' for assistance.
if(universe.le.0.or.EXCEPTION.ne.0) then
^
madx_ptc_normal.f90(58): catastrophic error: Internal Compiler Error: Ref module: ffe_cl.c
compilation aborted for madx_ptc_normal.f90 (code 1)

When I run the working older and working compiler "2025.1" I get:

/opt/intel/oneapi/compiler/2025.1/bin/ifx -m64 -O3 -warn all -warn nounused -warn nointerfaces -c -mp1 -fp-model strict -heap-arrays 65536 -assume noold_unit_star -module build/Linux64_ifx -fexceptions -no-wrap
-margin -D_STATIC -D_ICX -D_ICX -D_IFX -D_LINUX -D_ONLINE -D_USEGC -DSTATIC=static -ILinux64_ifx/ madx_ptc_normal.f90 -o madx_ptc_normal.o
madx_ptc_normal.f90(68): warning #8889: Explicit interface or EXTERNAL declaration is required.   [GET_VALUE]
   no = get_value('ptc_normal ','no ')
---------^
madx_ptc_normal.f90(89): warning #8889: Explicit interface or EXTERNAL declaration is required.   [GET_VALUE]
   icase = get_value('ptc_normal ','icase ')
------------^
madx_ptc_normal.f90(90): warning #8889: Explicit interface or EXTERNAL declaration is required.   [GET_VALUE]
   deltap0 = get_value('ptc_normal ','deltap ')

This is the expected result and will work in the compile & link procedure for the complete code.

I hope that will work for you to debug!

However there might be one hurdle I am working on the following Linux kernel:

uname -a
Linux frank4 6.13.12-200.fc41.x86_64 #1 SMP PREEMPT_DYNAMIC Sun Apr 20 15:52:43 UTC 2025 x86_64 GNU/Linux

Therefore, I do not know if the pre-compiled object files found in "Linux64_ifx"? will be understood

on your Linux implementation.

If you have trouble with that it will be a bit more complicated!

Cheers, Frank

JohnNichols · ‎08-09-2025

If you just update with each new release then they are stored in the directory and Intel uses a catch all latest to ensure they are not needing to reconfigure all the files each time.

But you have to update and not replace.

Ron_Green · ‎08-22-2025

Bug ID is CMPLRLLVM-69969

I reduced the source file with the ICE to the sample below. and this compilation string:

ifx -O0 -c -what -V -I./Linux64_ifx/ repro.f90

something in the convoluted type def of c_taylor maybe, or the host association of theRDTs in ptc_normal(). I don't have the sources but it would be nice if you can pull out the fully derived type definition for c_taylor.

At one point I thought I detected a USE dependence cycle but I think that was a false detection caused by some debug anomaly. I have sent this to the development team to further triage.

module madx_ptc_normal_module

  
contains

  SUBROUTINE ptc_normal()
    USE madx_ptc_intstate_module
    implicit none

    type(c_taylor)  :: theRDTs

  contains
  
     FUNCTION double_from_normal_t1()
       USE ptc_results
       implicit none
       real(8) double_from_normal

       real(8)  d_val1, d_val2
       complex(8) :: c_val

              c_val = theRDTs.sub.ind
              d_val = SQRT(d_val1**2 + d_val2**2)

     END FUNCTION double_from_normal_t1


  END subroutine ptc_normal

END MODULE madx_ptc_normal_module

frs · ‎08-24-2025

Dear Ron Green,

Thankd for making so much progress already!

For a short moment I had hoped that the problem might have been resolved

in yesterday's updates of "intel-oneapi" but in vain.

So here we go:

1) Attached will be

a full record of the "compile-link session" including the cheap work-around.

2) Then here about the source of "c_taylor",

which is the file "m_real_polymorph.f90" and

in the code directory structure it can be found at: "MAD-X/libs/ptc/src/"

in case you decide to pull down all code (see below). All other source code

is found at: "MAD-X/src/"

3) If that does not work out I have prepared a CERNBOX entry of

the minimum size of the MAD-X code of some 300 MB. If you can

swallow that I would need to give you read access, say via your Email address

until you will have pulled it down, and then:

- tar vfz MAD-X-bare.tgz

- cd MAD-X

- make madx-linux64-intel OPENMP=yes SHOW=yes STATIC=yes

- wait until you see the bug

- After changes work successfully it is good to reinitialize via "make cleanall"
and start again "make madx-linux64-intel OPENMP=yes SHOW=yes STATIC=yes"

Please let me know if you would like to get the full code or any other help from me.

Thanks so much already! Frank

frs · ‎08-24-2025

sorry it should read

- tar xvfz MAD-X-bare.tgz

Obvious but...

Ron_Green · ‎09-04-2025

@frs Is the version of MAD-X you are using from this github site? https://github.com/MethodicalAcceleratorDesign/MAD-X

or are you working off of a development branch or private branch?

I will send you my email in a private message.

ron