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.
