https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71460
--- Comment #28 from joseph at codesourcery dot com <joseph at codesourcery dot com> --- On Thu, 16 Jun 2016, ch3root at openwall dot com wrote: > > All these memory model issues would best be raised directly with WG14, > > What is the best way to do it? If your National Body is willing to add you to the ISO Global Directory for WG14, then you can join the reflector for email discussions (I think it may no longer be possible to be on the reflector without being listed as a member of WG14 in the ISO Global Directory). It should be possible to submit an N-document as a non-member. See the instructions I gave at <https://gcc.gnu.org/ml/gcc-patches/2015-10/msg03046.html>. > > 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? No. See (draft) TS 18661-5 (out for ballot as SC22 N5112). Alternate exception handling is proposed to be provided through various pragmas. It might or might not be possible to implement those using signal handling and enabling traps on some architectures. > 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 What I mean is that using feenableexcept confuses the issue, when raising the "invalid" exception (that is, the flag) is sufficient evidence of a bug if the operation doing so is one that is not permitted to do so. > > 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. Return values are clearly a bug in the wording of the standard, given how Annex F envisages that conversion-to-same-type may occur on return.