https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678

--- Comment #34 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #33)
> (In reply to Stefan Vigerske from comment #32)
> > Is there any hope this could actually be improved?
> > Now, 10 years later, the FENV_ACCESS pragma seems to be implemented, but the
> > problem here seems to persist.
> 
> The pragma still has no effect (not sure if we would be allowed to diagnose
> that fact).

I don't remember ever seeing anything in the C or C++ standard that would
prevent from printing as many diagnostics as we want, even for perfectly valid
code. Most warnings would be illegal otherwise.

> Nobody stepped up with a poor-mans "solution" to the issue (not sure if there
> even exists one) and a complete solution is not even on a drawing board.

One approach could be producing IFN_PLUS instead of PLUS_EXPR, for
floating-point types inside a "pragma on" region (or everywhere with
-frounding-math), and expanding it using the barrier mentioned below by default
(maybe with a possibility for targets to override that expansion). But then it
is tempting to refine IFN_PLUS and have variants (an argument?) specifying the
rounding mode when known, specifying if we only care about rounding, only about
exceptions, or both, etc. We could also produce PLUS_EXPR and the barriers
directly from the front-end, but with IFN_PLUS we at least have a chance to
fold exact constant operations (say 2.+2.), and more with the refined version.

Most lacking, whatever the approach, is a volunteer motivated enough to work on
it ;-)

clang doesn't handle the pragma either (AFAIK there was a recent effort, but it
stalled). Intel and Microsoft supposedly handle it, but Microsoft only applies
it to scalars and not SIMD vectors. That's not a lot of support...

> Other people running into this issue live with inserting compiler-barriers
> like
> 
> __asm__("# %0" : "=r" (x) : "0" (x));
> 
> for hiding 'x' from the compiler across this point.

You need to make it volatile, or it might be moved across fesetround. Also, you
can refine the constraint, say "=gx" on x86_64 (or just "=x"), and a different
one on each platform. An operation is then: *lo = hide(hide(x)/hide(y));

Reply via email to