[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 #15 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Thu, 9 Jun 2016, ch3root at openwall dot com wrote:

>  > For *scalar* assignment that would be fine because of TS 18661-1 saying
>  > "Whether C assignment (6.5.16) (and conversion as if by assignment) 
> to the
>  > same format is an IEC 60559 convertFormat or copy operation is
>  > implementation-defined, even if <fenv.h> defines the macro
>  > FE_SNANS_ALWAYS_SIGNAL (F.2.1).".  It's rather less clear for struct
>  > assignment.
> 
> How is it compatible with C11, 6.3p2: "Conversion of an operand value to 
> a compatible type causes no change to the value or the representation."? 
> Ha, even changing representation is prohibited.

That paragraph starts "Unless explicitly stated otherwise,".  C11 does not 
consider sNaNs, and TS 18661 is explicitly stating otherwise for them.

"or the representation" is clearly nonsensical here.  When something is 
converted it's an rvalue, and rvalues aren't associated with 
representations unless and until stored in an object; they are just 
members of the set of values of a type (and on assignment, 6.2.6.1#8 
applies).

> > Rather, it's OK for the loads
> > to raise an exception because assignment / argument passing etc. can be
> 
> I mean that "volatile double x; /* store sNaN to x */; x;" gives SIGFPE 
> currently. It doesn't look like (re)definitions of assignment etc. would 
> be applicable to this case.

That seems rather like an omission in the specification relating to excess 
range and precision, which should be considered like a conversion 
(convertFormat) to the relevant wider format.