[Bug c/53994] New: different result copying doubles(nan)

[Bug c/53994] New: different result copying doubles(nan)

[raul.baz at quest dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53994

             Bug #: 53994
           Summary: different result copying doubles(nan)
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: raul.baz@quest.com


Created attachment 27811
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27811
source code, just copy the numbers and does a memcmp over the results to check
its value

For the test I've used a structure with two unsigned char pointers. The
structure has 64 bits of length and it could have any value (memory addresses).

 If I cast to double and copy the value of the structure to a new varable
(double) if the contents of the structure is a nan the bit 51 is set to one.

 Attached a source file that copies two numbers:


  Number copied         Expected Result          result

0x7ff0000000000001      0x7ff0000000000001       0x7ff8000000000001   -- WRONG
0x7ff8000000000001      0x7ff8000000000001       0x7ff8000000000001   -- OK

 I know that these are nan and that probably they shouldn't be copied that way
but what may me think it's worng is the fact that these was not happening under
gcc 3.4.6.

 Thanks,

 Raul

[Bug c/53994] different result copying doubles(nan)

[schwab@linux-m68k.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53994

Andreas Schwab <schwab@linux-m68k.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID

--- Comment #1 from Andreas Schwab <schwab@linux-m68k.org> 2012-07-17 11:41:36 UTC ---
Bit 51 is the QNaN bit.  A SNaN will always be converted to a QNaN when used as
input by the FPU and the SNaN trap is disabled.