Debug builds broken

[anton-seaice]

It looks like moving to oneapi has broken Debug builds

It looks like :

build_type=Release: oneapi 2025 and intel 2021.10.0 work
Debug: intel 2021.10.0 works - I only built this locally without spack and only including MOM6
Debug: oneapi 2025.0.4 fails

If fails in the final linking step with:

/bin/ld: cannot find -lm

However it finds m (the math library) fine with the Release build.

This runs shows the error clearest: #86 (comment) (and same failure with the cosima cmake)

[anton-seaice]

These are the typical build flag differences:

  set(CMAKE_Fortran_FLAGS_RELEASE "-O2 -debug minimal")
  set(CMAKE_Fortran_FLAGS_DEBUG "-O0 -g -check uninit -check bounds -check pointers -fpe0 -check noarg_temp_created")

[anton-seaice]

Building access3-share and mom6 with build_type=Release, and only using Debug for access3 / the final executable also fails with the same error.

[anton-seaice]

Release uses:

-O2 -debug minimal

Debug uses:

-O0 -g -check uninit -check bounds -check pointers -fpe0 -check noarg_temp_created

Debug builds fine without -check uninit

There are some notes about check uninit in the docs although nothing jumps out at me

[anton-seaice]

@manodeep says:

Here's a Intel forum post talking about such a linker problem with -check uninit. Specifically, this comment from an Intel employee says that the linker looks for the static library libm.a (rather than the usual shared library libm.so)
You could fix the build failure by removing the check for uninitialised memory following the advice in this comment. But then you lose that feature ...

[access-hive-bot]

This issue has been mentioned on ACCESS Hive Community Forum. There might be relevant details there:

https://forum.access-hive.org.au/t/setting-build-options-for-om3/4495/17

[dougiesquire]

Just noticed this in the FMS release notes:

INTEL: The -check uninit flag for the Intel Oneapi Fortran compiler (ifx) is unsupported due to a bug causing false positives when using external libraries. If using the -check all flag, -check all,nouninit should be used instead.

[MartinDix]

That false positive problem seems to have been fixed with 2025.0.4 (at least for my UM tests).

No linking problem with the UM, but not using cmake.

[anton-seaice]

No linking problem with the UM, but not using cmake.

Does the UM link to the m / math library ?

UM uses ar right? (Not llvm-ar ?)

[anton-seaice]

@manodeep - Do you know where libm is on Gadi? We might be able to ask NCI to compile libm.a ?

[MartinDix]

This is the normal build rather than a spack build. It uses ar rather than llvm-ar. Perhaps more importantly it links with mpif90

ar rs /jobfs/140996001.gadi-pbs/0HsV653IKv/libum-atmos.a o/um_shell_mod.o .....
mpif90 -obin/um-atmos.exe o/um_main.o -L/jobfs/140996001.gadi-pbs/0HsV653IKv -lum-atmos -lgcom -qopenmp -lnetcdff -lnetcdf -leccodes_f90 -leccodes -qopenmp -mcmodel=medium -shared-intel

[manodeep]

@anton-seaice As long as -flto is not being used (and it is not), using ar is fine.

The suggestion on the forum was to use -l:libm.so with the -check uninit flag. But as Dougie pointed out, the -check uninit flag can cause problems^ and might be best to avoid, at least for now.

edit: To be clearer, you will need to replace the -lm with -l:libm.so

---

^: The 2025.1 oneAPI docs say that -check all expands to -check all,nouninit

-check all now behaves as -check all -check nouninit. Setting -check uninit and
linking with libraries not built with this option, such as Intel® oneAPI Math Kernel Library
(oneMKL) or Intel® MPI Library, causes runtime failures. -check uninit is no longer set by
-check all

[MartinDix]

So it was the meaning of the option that changed rather than a fix to the behaviour :-(

[anton-seaice]

Since this was started, we've moved to oneapi@2025.2.0 and that has resolved the compiliation problem, e.g.:

#147 (comment)

However the code doesn't run.

So does using -check all instead of -check uninit -check bounds -check pointers make sense:

The 2025.1 oneAPI docs say that -check all expands to -check all,nouninit

@manodeep points out that we probably need to be clear on the purpose of the debug build first though.

[anton-seaice]

A possible proposal:

For

CMAKE_Fortran_FLAGS_DEBUG

Use

"-O0 -g3 -fpe0 -check noarg_temp_created" (No -check flags)

Debug builds should help users with additional debugging info and divide by zero errors. This should work with Linaro Forge. We'd apply to change to access3-share/mom6/cice/ww3/gtracers

(currently : "-O0 -g -check uninit -check bounds -check pointers -fpe0 -check noarg_temp_created" )

---

Developers could set in spack.yaml (document this in the config docs?) :

fflags = "-check all"

If needed ?

(Or we could add another CMAKE build type DEBUG_SANITIZE ?)

From @manodeep :

The check for uninitialised variables is a different setup entirely and should be used for identifying memoy leaks/uninitialised accesses etc; and typically should be done during the development process itself.

---

I think we just copied build flags from your work @micaeljtoliveira, does this change sound ok ? @dougiesquire - you might have a view too

(I'm happy to organise a meeting if thats better)