ifx 2025.3 build error with 2025.04

[mathomp4]

Describe the bug

I tried today to build FMS 2025.04 with ifx 2025.3 and got this:

[ 61%] Linking Fortran executable test_mpp_alltoall
ld.lld: error: relocation refers to a symbol in a discarded section: mpp_mod::mpp_byte_
>>> defined in libfms.a(mpp.F90.o)
>>> section group signature: mpp_mod_mp_mpp_byte_
>>> prevailing definition is in CMakeFiles/test_mpp_alltoall.dir/test_fms/mpp/test_mpp_alltoall.F90.o
>>> or the symbol in the prevailing group had STB_WEAK binding and the symbol in a non-prevailing group had STB_GLOBAL binding. Mixing groups with STB_WEAK and STB_GLOBAL binding signature is not supported
>>> referenced by ifxrddV1S.i90
>>>               mpp.F90.o:(mpp_mod::mpp_init_) in archive libfms.a
>>> referenced by ifxMVBfzj.i90
>>>               CMakeFiles/test_mpp_alltoall.dir/test_fms/mpp/test_mpp_alltoall.F90.o:(test_mpp_alltoall::test_mpp_alltoallw_real4_)
>>> referenced by ifxMVBfzj.i90
>>>               CMakeFiles/test_mpp_alltoall.dir/test_fms/mpp/test_mpp_alltoall.F90.o:(test_mpp_alltoall::test_mpp_alltoallw_real4_)
>>> referenced 14 more times
gmake[4]: *** [CMakeFiles/test_mpp_alltoall.dir/build.make:111: test_mpp_alltoall] Error 1
gmake[4]: Leaving directory '/gpfsm/dswdev/gmao_SIteam/Baselibs/ESMA-Baselibs-9.4.0/src/FMS/build'
gmake[3]: *** [CMakeFiles/Makefile2:4099: CMakeFiles/test_mpp_alltoall.dir/all] Error 2
gmake[3]: Leaving directory '/gpfsm/dswdev/gmao_SIteam/Baselibs/ESMA-Baselibs-9.4.0/src/FMS/build'
gmake[2]: *** [Makefile:146: all] Error 2
gmake[2]: Leaving directory '/gpfsm/dswdev/gmao_SIteam/Baselibs/ESMA-Baselibs-9.4.0/src/FMS/build'
make[1]: *** [GNUmakefile:1133: FMS.install] Error 2
make[1]: Leaving directory '/gpfsm/dswdev/gmao_SIteam/Baselibs/ESMA-Baselibs-9.4.0/src'

I'm going to cc @climbfuji as maybe he's seen this in his ifx travels?

To Reproduce

I am building FMS 2025.04 in ESMA-Baselibs and the CMake line is:

cmake -B build -S . -DCMAKE_INSTALL_PREFIX=$(prefix)/FMS \
  -DCMAKE_PREFIX_PATH=$(prefix) -DFPIC=ON -DCONSTANTS=GEOS \
  -DNetCDF_ROOT=$(prefix) -DNetCDF_INCLUDE_DIR=$(prefix)/include/netcdf

Expected behavior

Things to build.

System Environment
Describe the system environment, include:

• OS: SLES 15.4
• Compiler(s): Intel ifx 2025.3
• MPI: Intel MPI 2021.17
• netCDF Version: C: v4.9.2, Fortran: v4.6.1
• Configure options: -DFPIC=ON -DCONSTANTS=GEOS -DNetCDF_ROOT=$(prefix) -DNetCDF_INCLUDE_DIR=$(prefix)/include/netcdf

Additional context

I was able to build with ifort 2021.13 + IMPI 2021.13 and gfortran 15.2 + openmpi 4.1.6. So I'm thinking it is an ifx issue.

[climbfuji]

I've not seen this particular error before.

[mathomp4]

@climbfuji Thanks. I'd had hoped you might have the inside knowledge.

So, I decided to chat with Ye Olde ChatGPT and it wanted some nm output:

> nm -A CMakeFiles/test_mpp_alltoall.dir/test_fms/mpp/test_mpp_alltoall.F90.o | grep -i mpp_byte || true
CMakeFiles/test_mpp_alltoall.dir/test_fms/mpp/test_mpp_alltoall.F90.o:0000000000000000 V mpp_mod_mp_mpp_byte_

> nm -A libfms.a | grep -i mpp_byte | head
libfms.a:mpp.F90.o:0000000000000000 D mpp_mod_mp_mpp_byte_
libfms.a:mpp_domains.F90.o:                 U mpp_mod_mp_mpp_byte_

and then it said:

That nm output nails it.

In the test object you have:

V mpp_mod_mp_mpp_byte_

V = weak object (STB_WEAK) in a COMDAT/section-group kind of situation.

In libfms.a(mpp.F90.o) you have:

D mpp_mod_mp_mpp_byte_

D = strong global data (STB_GLOBAL).

So LLD is doing exactly what it said: it sees the same section-group signature twice, one weak and one global, and it refuses to mix them.

Why is the test object defining mpp_mod_mp_mpp_byte_ at all?

Because of this line in the test:

use mpp_mod, only : mpp_type_create, mpp_type, mpp_byte

In FMS, mpp_byte is almost certainly a module-level variable/parameter (or something that ends up as module data), and ifx 2025.3 is emitting a weak COMDAT definition of imported module data into the user object (your program object) instead of leaving it as an undefined reference. That’s a compiler codegen behavior/bug/interaction.

Gfortran typically leaves that as U in the user object. ifx here is creating a weak “copy” (V), and LLD then trips because the real definition in the archive is strong (D).

So you’re not crazy: your source is normal, but ifx+lld doesn’t like this pattern.

And so, as a test, I decided to comment out this line:

FMS/cmake/compiler_flags_IntelLLVM_Fortran.cmake

Line 10 in fbbe8f6

set(CMAKE_Fortran_LINK_FLAGS "-fuse-ld=lld")

which I guess will pull us back to GNU bfd as the linker.

I then built FMS with that line commented and all builds fine and if I run ctest, most tests pass:

94% tests passed, 6 tests failed out of 102
...
The following tests FAILED:
	 45 - test_collective_io (Failed)                       fms2_io
	 57 - test_global_arrays (Failed)                       mpp
	 64 - test_mpp_domains2 (Failed)                        mpp
	 74 - test_mpp_nesting (Failed)                         mpp
	 96 - test_sat_vapor_pres (Failed)                      sat_vapor_pres
	 98 - test_time_interp2 (Failed)                        time_interp

I'm not sure if the linker can cause the failures I was seeing.

---

Now, I guess I have a few questions (for @rem1776 or anyone else on the FMS team):

1. Do I need the test_ executables for a build of FMS? It looks like they are always built no matter what and I don't see any ENABLE_FMS_TESTS sort of CMake option¹.
2. Would you be amenable to a CMake option to twiddle the linker used? It looks like IntelLLVM_Fortran is the only place the linker is changed from default (IntelLLVM_C doesn't seem to force lld but maybe icx does that on its own?). Obviously for you it is working, but maybe a way for me to not use it a la:

option(USE_LLD_LINKER "Use the lld linker for ifx" ON)

Footnotes

1. I'm not against always having the tests around and built, but an option to say 'Nah, I'll wing it' might be okay to have since often I don't run the self tests when I build...Bad Matt² ↩

2. And I suppose if the autotools build can't disable these tests being built, neither should the CMake build. ↩

[rem1776]

Thanks for taking the time to report and look into this! I've done some testing with ifx 2025.3 but mainly using containers so its good to hear how it does on other systems.

Now, I guess I have a few questions (for @rem1776 or anyone else on the FMS team):

1. Do I need the test_ executables for a build of FMS? It looks like they are always built no matter what and I don't see any ENABLE_FMS_TESTS sort of CMake option1.

No we shouldn't need to build the executables every time, we can add an option to disable building the tests.

2. Would you be amenable to a CMake option to twiddle the linker used? It looks like IntelLLVM_Fortran is the only place the linker is changed from default (IntelLLVM_C doesn't seem to force lld but maybe icx does that on its own?). Obviously for you it is working, but maybe a way for me to not use it a la:

I think it was a mistake that it wasn't set for both, so maybe that is part of the problem. From my experience it seems to be system-dependent if the flag is needed to build, but I haven't run into issues using the lld flag (only hit errors when not using it). But yeah seems like an explicit option for that would be the best path forward.

I will open a new issue to add both of these to the cmake build. I'm going to keep this one open too for the test failures, they pass with older intel versions but can be a little finicky and fail from data comparisons.

[mathomp4]

Thanks, @rem1776

My guess is my system is the weirdo (ESMA-Baselibs has like 20 years of history hanging around) and it's a ... mess. Probably something like Spack will do things Right™ and might avoid all this. Soon we hope to move to Spack and then hopefully things get less idiosyncratic.