[Bug target/71460] Copying structs can trap (on x86-32) due to SNaN to QNaN

[ch3root at openwall dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71460

--- Comment #10 from Alexander Cherepanov <ch3root at openwall dot com> ---
On 2016-06-08 20:47, pinskia at gcc dot gnu.org wrote:
> --- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
> I think this is really a dup of bug 57484.  The problem is x87 related and
> there is not much to be done.

I don't think so.

I haven't looked into floating-point arithmetic in any details but, as a 
first approximation, I see the situation like this:
- sNaNs are not required by C11 (including by Annex F);
- mere load (e.g. from a volatile var) of a float or double sNaN traps 
on x86-32 when traps are enabled;
- this perfectly fits the description of trap representation.
So gcc de facto doesn't support sNaNs in this configuration and any its 
use is UB.

OTOH copying of structures doesn't invoke UB and is required not to 
trap. (At least if its address is taken:-)
(Not sure if this is contradicted by C11, 6.2.6.1p5: "If such a 
representation is produced by a side effect that modifies all or any 
part of the object by an lvalue expression that does not have character 
type, the behavior is undefined.50)". But the intention of DR 222 is 
quite clear.)

IOW this bug is not about wrong handling of sNaNs, it's about 
introducing sNaN-related problems where there were none. Like copying a 
partially initialized struct where one of unknown fields happened to 
have the double type and sNaN as representation.