Re: [PATCH] Remap __GLIBC_FLT_EVAL_METHOD to 0 if __FLT_EVAL_METHOD__ is -1

[Wilco Dijkstra <Wilco.Dijkstra@arm.com>]

Hi,

>> GCC isn't set that to -1, but clang/LLVM did, see
>> https://github.com/llvm/llvm-project/issues/60781 and
>> https://reviews.llvm.org/D121122
>
> Hmm, it turns -ffast-math into "-fslow-math" :(.

Yes that alone is a good reason to fix this!

> I agree that if __FLT_EVAL_METHOD__ is not 0, 1, or 2, and the target
> does not have native support for some "special" floating point types, we
> *should* make float_t float and double_t double.
>
> But doing so may blow up rolling-release distros: if a library uses
> float_t and double_t in the API and the distro maintainers rebuilt the
> library with a new Glibc, but (s)he has not rebuilt an application using
> the library yet, the application will just crash or produce "strange"
> results.  Maybe we'll need to issue an alert about this to the distro
> maintainers.

GCC never uses -1, so distros should be fine. We could backport the GLIBC fix.

It's not clear whether float_t/double_t are allowed on interfaces. On x86 GCC uses
2 by default but LLVM uses 0, and with Ofast x86 GCC uses 0 while LLVM uses -1
(which is mapped to 2 by GLIBC). With LLVM fixed it will be 0.

So it looks like a mess, but on x86 there is precedent for incompatible values
between compilers and optimization settings.

Cheers,
Wilco