-ffast-math in one package might infect all libraries in an environment with inaccurate FPU

[h-vetinari]

This blog post raises a number of concerning points, the prime one being:

when -ffast-math is enabled, the compiler will link in a constructor that sets the FTZ/DAZ flags whenever the library is loaded — even on shared libraries, which means that any application that loads that library will have its floating point behavior changed

This is made worse by -Ofast (it's gonna make my code faster, right?) turning on -ffast-math unconditionally (as in: -fno-fast-math has no effect).

I think we should consider stripping out those flags where they exist. The blog also mentions a few ways to analyse whether the shared objects are affected. Perhaps that's something for conda-build to do after verification?

Xref: llvm/llvm-project#57589, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522

[h-vetinari]

@mikemhenry mentioned on gitter (now matrix) that GCC 13 has a fix for this:

-Ofast, -ffast-math and -funsafe-math-optimizations will no longer add startup code to alter the floating-point environment when producing a shared object with -shared.

[mikemhenry]

💯

I think a good start would be to do a search across the feedstocks to see what packages are using dangerous optimizations + the -shared flag.

[bilderbuchi]

Could that gcc fix be a good reason to reignite efforts to package a current gcc in conda-forge on windows (#1044 I think)? I've read on the fortran lang forum that they also already felt that restriction (gcc 5!) when trying to modernise the fortran packages within python.

[h-vetinari]

That's a completely separate topic. GCC on linux (where it is our default compiler) is on 11 by default, and will be changed to 12 in the not too distant future.

Fortan on windows is a different topic, where people have been waiting for flang to materialise. There's a PR to make the change to a llvm 11 based classic flang, but that's been made dependent on some infrastructure work on the migrators that no-one has tackled yet. I'm trying to build the new llvm-internal flang but even that will run into the same issue afterwards.

[h-vetinari]

A small bit of good news on this: clang is deprecating -Ofast, and this should land for clang 19.