https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96373
--- Comment #11 from Michael Matz <matz at gcc dot gnu.org> --- (In reply to rguent...@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).
