https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94497
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target| |x86_64-*-* i?86-*-*
--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Hadrien Grasland from comment #5)
> Thanks for the clarifications! We could probably live with
> -fno-signed-zeros, but I think -ffinite-math-only would be too much as an
> application-wide flag, as I've spotted several occurences of the "do the
> computation, then check if the result is normal" pattern around...
>
> I tried to experiment with #pragma optimize as a finer-grained alternative
> to a global fast-math flag, which would probably be acceptable. But that
> seemed to have the side-effect of preventing inlining of the functions to
> which the attributes are applied into other functions that don't have it (I
> guess that attribute is implemented by splitting the code into multiple
> compilation units?), whereas in this part of the codebase we want all the
> inlining we can get...
Yeah, since the #pragma optimize works at a function level we cannot permit
inlining of functions with conflicting settings...
> So since I don't have the skills and time to work on GCC myself, I guess I
> will need to wait for now and see what you come up with.
There's also the possibility to use XMM intrinsics or simply fmin()/fmax()
(but the latter is only optimized for targets implementing fmin/fmax expanders
which unfortunately x86 doesn't).
