[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 #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.