Set Intel Fortran ifort / ifx compiler flags to not aggressively optimize floating exception code checks

[rickgrubin-noaa]

Description

Per: FMS 2025.03 built with oneAPI@2025.{2,3}.1 ifx optimizes code to create a divide by zero error
#2041

For spack-stack@2.x / FMS@2025.3 (see configs/common/packages.yaml), ifx will optimize away a check for dividing by zero.

To Reproduce

See the reproducer code / FMS issue.

Expected behavior

ifort / ifx does not optimize away checks for division by zero.

System, compiler, code, ...

• All RDHPCS hosts
  • ifort@2023.x, @2024.x
  • ifx@2025.x

Additional context

This is not a bug with spack / spack-stack per se, noting it here for the sake of completeness.

Note: this also occurs with ifort@202{3,4}.x

[climbfuji]

Looks good to me

[AlexanderRichert-NOAA]

I forget whether the plan was to contribute this to upstream Spack? If so, the Spack devs may want to use flag_handler() instead, something like (I haven't tested the following; I just asked Gemini to refactor into flag_handler() approach):

def flag_handler(self, name, flags):
    if name == "fflags" and self.spec.satisfies("%oneapi@2023:"):
        flags.extend(["-fp-model=precise", "-fp-speculation=safe"])
    return (flags, None, None)

which has the benefit of incorporating the flags into the spec, I'm pretty sure. But if not then nevermind, and this PR looks reasonable.

[climbfuji]

This PR is for release/2.1; we have a separate PR for spack-packages upstream (spack#5312). It should be ok to merge this as-is, make changes as suggested or required by the spack-developers upstream, and then pull the upstream changes into our spack-stack-dev branch?

[AlexanderRichert-NOAA]

Yep good point, that sounds good.

[rickgrubin-noaa]

I forget whether the plan was to contribute this to upstream Spack? If so, the Spack devs may want to use flag_handler() instead, something like (I haven't tested the following; I just asked Gemini to refactor into flag_handler() approach):

def flag_handler(self, name, flags):
    if name == "fflags" and self.spec.satisfies("%oneapi@2023:"):
        flags.extend(["-fp-model=precise", "-fp-speculation=safe"])
    return (flags, None, None)

which has the benefit of incorporating the flags into the spec, I'm pretty sure. But if not then nevermind, and this PR looks reasonable.

I'll make sure that works and if so, modify the upstream PR. Thank you.

[rickgrubin-noaa]

I forget whether the plan was to contribute this to upstream Spack? If so, the Spack devs may want to use flag_handler() instead, something like (I haven't tested the following; I just asked Gemini to refactor into flag_handler() approach):

def flag_handler(self, name, flags):
    if name == "fflags" and self.spec.satisfies("%oneapi@2023:"):
        flags.extend(["-fp-model=precise", "-fp-speculation=safe"])
    return (flags, None, None)

which has the benefit of incorporating the flags into the spec, I'm pretty sure. But if not then nevermind, and this PR looks reasonable.

I'll make sure that works and if so, modify the upstream PR. Thank you.

Creating a flag_handler() function definitely injects the flags into the spec, but does not inject them into the config / build. A quick test -- create an env that builds just FMS without extending the cmake args list -- and running it against a reproducer results in a divide by zero error.

[AlexanderRichert-NOAA]

Thanks for testing it-- It may be an issue of which of the three "slots" the updated flags are getting returned to. In any case we can just merge this then wait for feedback from the Spack devs on the spack/spack-packages PR.