[Bug c/51656] New: C front end and strtold handle hexadecimal floating differently

[Bug c/51656] New: C front end and strtold handle hexadecimal floating differently

[exponent-bias at yandex dot ru]

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

             Bug #: 51656
           Summary: C front end and strtold handle hexadecimal floating
                    differently
    Classification: Unclassified
           Product: gcc
           Version: 4.4.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: exponent-bias@yandex.ru


Consider this program:

----
#include <stdlib.h>
#include <stdio.h>

long double f;

int main(void)
{
    f = 0x9.1a1c9420419a1a08p0L;
    printf("%.15La\n", f);

    f = strtold("0x9.1a1c9420419a1a08p0", NULL);
    printf("%.15La\n", f);

    return EXIT_SUCCESS;
}
----

That program prints:
0x9.1a1c9420419a1a0p+0
0x9.1a1c9420419a1a1p+0

Note the difference in the last mantissas' digits. I believe that difference
can be considered a bug by at least two reasons: 1) the "strtold()" function
seems to be rounding hexadecimals by rules that don't match neither of the
standard rounding mode (including the to-nearest mode for which it should
return 0x9.1a1c9420419a1a0p+0) and 2) that difference breaks user's
expectations in that these two ways of acquiring floating-point values should
behave identically under the same rounding mode.

Command-line options used:
gcc --float-store -g -O0 -o test test.c

Compiler version:
gcc-4.4.real (Ubuntu 4.4.3-4ubuntu5) 4.4.3

Host and target platforms:
32-bit x86 system

[Bug c/51656] C front end and strtold handle hexadecimal floating differently

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

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

--- Comment #1 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-12-23 09:14:28 UTC ---
This looks more like a glibc issue, so please file it at sourceware.org.
For me on a x86_64 host, i686 target system it does:

0x9.1a1c9420419a1a0p+0
-0xd.cbc6d7c00000000p+27

same on x86_64 target.  Huh ;)  glibc 2.9.