[Bug target/71460] Copying structs can trap (on x86-32) due to SNaN to QNaN

[joseph at codesourcery dot com]

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

--- Comment #26 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Sat, 11 Jun 2016, ch3root at openwall dot com wrote:

> > C11 does not
> > consider sNaNs, and TS 18661 is explicitly stating otherwise for them.
> 
> You are talking about C11 + TS 18661 which is a different version of C. 

The semantics of C11 + TS 18661 are a refinement of those of C11 (with 
sNaNs in C11 being trap representations by virtue of not acting like any 
kind of value considered by C11, so a refinement of C11 semantics can 
apply any semantics it likes to them).

> Even TS 18661-1 acknowledges that it's incompatible with C11, e.g. 
> clause 12 reads: "[...] so that an implementation could not add 
> signaling NaN support as an extension without contradicting C11." Will 
> there be a new value for the -std option?

The option is -fsignaling-nans.  In future -std=c2x may imply 
-fno-fp-int-builtin-inexact if TS 18661-1 is integrated in C2x, but I 
expect -fsignaling-nans still to be needed if you want such values to 
behave in a particular consistent way.

> I'm not sure. It would be nice to have such a clear distinction between 
> values and representations but C is tricky. What is the value of a union 
> after memset? Suppose a value stored into an active member of a union 
> admits several representations, is taking inactive member of this union 
> (aka type-punning) is required to give the same result before and after 
> applying lvalue-to-rvalue conversion to the union?
> 
> Heck, even the example that started this PR is not that easy. If a 
> member of a structure has a trap representation what is the value of 
> this structure? Is copying of this structure required to preserve the 
> exact representation of this member? Can this trap representation be 
> changed to a non-trap one?

All these memory model issues would best be raised directly with WG14, 
possibly working together with the Cerberus people, not with individual 
implementations.

> So the idea is that gcc on x86-32 with feenableexcept(FE_INVALID) could 
> be made conforming with C11 + TS 18661? Is there anything there that 

As soon as you use feenableexcept you are completely outside the scope of 
any standards.

> allows to trap on a return from a function (when the result of the 
> function is not used)? C11, 6.8.6.4p3, talks about a conversion "as if 
> by assignment" only for a case of differing types and I don't see TS 
> 18661 patching this clause of C11.

The intent is clear, because C11 + Annex F semantics are meant to be a 
refinement of those of base C11 (Annex F being an optional extension to 
base C11), and from F.6 you can tell that such cases must be permitted to 
do a conversion to the same type, so it must be intended to allow such a 
conversion.  But I'll raise this for clarification in TS 18661 anyway.

> I mean bug 57484 is more important case than lone loads from volatiles. 

57484 is a closed C++ bug.  I think you mean 56831 as the substantive QoI 
bug for such cases.