[Bug target/96373] SVE miscompilation on vectorized division loop, leading to FP exception

["matz at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #11 from Michael Matz <matz at gcc dot gnu.org> ---
(In reply to rguenther@suse.de from comment #9)
> How do we represent sNaNs with -fnon-call-exceptions?  That is,

I think we're currently simply buggy at various stages as soon as sNaNs are
involved _and_ STDC FENV_ACCESS is ON.

>  y_1 = x_2 + 1.;
> 
> may trap.  Does
> 
>  foo (x_2);
> 
> get transformed to
> 
>  tem_3 = x_2;
>  foo (tem_3);
> 
> and the SSA assignment now traps dependent on whether the call
> ABI requires pushing x_2 to a stack slot (which might trap)?

If copying a sNaN (to registers or memory) signals an invalid-op depends on the
CPU (and is implementation defined in ieee754).  And GCC doesn't necessarily
preserve such signals even on CPUs that do signal (if there are any), because
it could e.g. use integer stores to transfer the bit patterns.

> sNaNs are odd anyway I guess.

> But yes, a pure function can still trap (and also throw).
> 
> I think we don't have a good notion for trappingness of calls
> and I do expect inconsistencies here.

__builtin_sqrtf isn't an arbitrary call.  FP operations aren't arbitrary
expressions.

We don't really have the problem of generating calls to arbitrary
arguments out of the blue, not even with non-throwing calls.  I'm not sure if
we should mix this problem here with that more generic problem.

Btw, that we if-convert calls to builtinf_sqrt is indeed a bug without
special options giving a license for that.  But doing that for the original
testcase instead of the division would _not_ be a problem on SVE: the inactive
lanes are zeroed and that doesn't signal anything for square root.

(We could perhaps extend the meaning of -fno-math-errno to give this license,
i.e. guarantee that the user hasn't enabled stops for any FP exceptions; but
that might be too aggressive).