https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71460
--- Comment #27 from Alexander Cherepanov <ch3root at openwall dot com> --- On 06/12/2016 01:09 AM, joseph at codesourcery 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). Ok, I see. It seems that it would be fine with C11 to consider sNaN and qNaN alternative representations of the same value when traps are off but it would be incompatible with TS 18661 so it's more convenient to consider sNaN a trap representation. This makes the question of traps irrelevant and makes it compatible with TS 18661. >> 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, What is the best way to do it? > possibly working together with the Cerberus people, not with individual > implementations. I'm afraid I don't quite understand their approach/aim and the choice of questions. OTOH one of the most useful to me results from the whole work was your reply to their questionnaire. Thank you for this! >> 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. Isn't feenableexcept what IEC 60559 describes in the clause 8.1: "Language standards should define, and require implementations to provide, means for the user to associate alternate exception handling attributes with blocks (see 4.1)."? Why it's not in TS 18661? Or you mean that a mode with traps for the invalid operation exception is not supported by gcc at all? Then this bug is mostly non-issue because IMHO the main problem is crashing and not the changes of representations of NaNs. >> 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. Yes, this is probably a simple case. I haven't seen F.6 before but it surprising doesn't change 6.8.6.4p3 much. I'm less sure about mere lvalue-to-rvalue conversion. Trapping at lvalue conversion makes impossible to apply isnan &co. to sNaNs even though "[...] these macros raise no floating-point exceptions, even if an argument is a signaling NaN." >> 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. No. 56831 is about passing sNaNs to functions as arguments. This conforms to TS 18661 and this could be fixed in gcc. The same for assignment. 57484 is about returning a value from a function. This is technically not conforming and this couldn't be fixed in gcc without breaking ABI. If a separate bug for C is required I can file one.
