Source-Changes-D archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: src/tests/lib/libc/locale



> Date: Wed, 29 Nov 2017 09:14:26 +0100
> From: Martin Husemann <martin%duskware.de@localhost>
> 
> (gdb) info float
>   R7: Valid   0xc00cc0e6b7318fc50481 -12345.67890000000079      
> =>R6: Valid   0xc00cc0e6b7318fc50800 -12345.67890000000079      
>   R5: Empty   0xc00cc0e6b7318fc50800
> [...]
> Control Word:        0x037f   IM DM ZM OM UM PM
>                        PC: Extended Precision (64-bits)
>                        RC: Round to nearest

Here R7 contains 0xc00cc0e6b7318fc50481, the value that strtod
returned, and R6 contains 0xc00cc0e6b7318fc50800, the value that was
stored in the program.  We switched in 6.99.26 from default 53-bit
precision to default 64-bit precision.

I tried running my program on netbsd-6.  It passed just fine.  I made
the following two changes:

1. replace double by long double
2. set the fp control word to 0x307f

With either one individually and -O0, it still passes.  With both of
them together and -O0, it fails and gives 0xc00cc0e6b7318fc50481 as
the answer from strtod.  With just (2) and -O2, it also fails and
gives 0xc00cc0e6b7318fc50481 as the answer from strtod.

This is starting to smell like a compiler bug in fp correctness...but
I'm out of time to diagnose it further.


Home | Main Index | Thread Index | Old Index