Repository navigation
DEBUG build doesn't disable optimization or enable runtime checks for ICON (Intel, [GNU]) #137
Description
Activity
- moved this to New features in TSMP2: Towards Stages/2026 support
on Aug 7, 2026 @s-poll I checked those flags you proposed from the Intel Fortran compiler guide:
-check bounds: Checks for array subscript and character substring expressions.-check uninit: Checks for uninitialized variables. (Linux only)-fpe0: Floating-point invalid, divide-by-zero, and overflow exceptions are enabled throughout the application when the main program is compiled with this value. If any such exceptions occur, execution is aborted. This option causes subnormal floating-point results to be set to zero. Underflow results will also be set to zero, unless you override this by explicitly specifying option-no-ftzor-fp-model precise(Linux*) or option/Qftz-or/fp:precise(Windows*).-init=snan: Determines whether the compiler initializes to signaling NaN all uninitialized variables of intrinsic type REAL or COMPLEX that are saved, local, automatic, or allocated variables.
All these flags pertain to program correctness; thus I think it makes more sense to add these flags on both
DEBUGandRELEASEbuilds. This can be done by updatingICON_FCFLAGS:Line 21 in 0a38c42
Then for
DEBUGconfiguration only-g O0needs to be added.I needed to remove `check uninit' flag on JURECA-DC
Here the reasoning by LLM:
On ifx 2024.2 (the LLVM-based Intel Fortran compiler used at JURECA default stage, as opposed to classic ifort), -check uninit is implemented via Clang's MemorySanitizer, not the old runtime-check mechanism. Passing it silently changes the link line: it pulls in for_main_msan.o, libclang_rt.msan, libifport_msan, libifcoremt_msan, etc., and wraps these (and neighboring libraries) in -Bstatic ... -Bdynamic toggles.
ICON's link line mixes:
static archives (OASIS3-MCT: libpsmile.MPI1, libmct, libmpeu, libscrip)
dynamic system libraries (HDF5, libxml2, MKL, libz.so, ...)
The -Bstatic/-Bdynamic toggles injected by the msan instrumentation leave the linker in static mode by the time it reaches libz.so, which has no static (.a) counterpart on this system so the link fails with attempted static link of dynamic object.This only breaks configure's minimal "does the Fortran compiler work" test (an empty program main / end linked against the full library set), so it looks like the compiler itself is broken, when actually it's this one debug flag interacting with the mixed static/dynamic library set.
Confirmed by reproducing the exact link command from config.log locally and bisecting the DEBUG-only flags one at a time -check uninit reproduces the failure; the link succeeds cleanly without it.
Confirmed by reproducing the exact link command from config.log locally and bisecting the DEBUG-only flags one at a time -check uninit reproduces the failure; the link succeeds cleanly without it.
Good catch; we've seen the same
DEBUGbuild issues in #72 and #48. I agree droppinguninitand fix the brokenDEBUGbuild flags separately.To build ICON-eCLM on JURECA the same issue with uninit is created at the eCLM build. By removing it was successfully (build and run). Should I also use this PR to remove the option form eCLM?
Reacted by Paul Rigor- linked a pull request that will close this issueEnable -O0 and runtime diagnostics in DEBUG build for ICON #138
on Aug 10, 2026 - moved this from New features to Housekeeping in TSMP2: Towards Stages/2026 support
on Aug 10, 2026 I just recognized that the changes needs to be done in the eCLM repo; thus could not be part or this PR. But I will also create a PR at the eCLM repo reference to here.
Problem
In
cmake/BuildICON.cmake, theDEBUGbranch only prepends-g:Under the Intel compilers (
ifort/ifx), the default optimization level is-O2, and since no-Oflag is ever specified in this branch,-gis added on top of the implicit-O2rather than replacing it. So a "DEBUG" build gives debug symbols but keeps full optimization, and enables none of Intel's runtime diagnostics (bounds checking, uninitialized-variable checks, floating-point exception trapping).Proposed change
Add to the
DEBUGbranch for the Intel/IntelLLVM case:so that
CMAKE_BUILD_TYPE=DEBUGactually disables optimization and turns on array-bounds checking, uninitialized-variable checking, floating-point exception trapping, and NaN-initialization of otherwise-uninitialized memory.Notes / caveats
DEBUGbuild type only (RELEASEis unaffected).-Oflag) is identical to explicit-O0(confirmed viagfortran -Q --help=optimizers), soDEBUG's bare-gprepend doesn't silently leave optimization on the way it does under Intel.-fcheck=bounds,-ffpe-trap,-finit-real=snan, or-finit-integer=...anywhere incmake/. The GNUFCFLAGShas warnings (-Wall,-Wconversion, …) and-fbacktracebut no runtime bounds/uninitialized/FPE checking. Worth adding the GNU equivalents (e.g.-fcheck=bounds -ffpe-trap=invalid,zero,overflow -finit-real=snan) to theDEBUGbranch alongside the Intel fix.