[Bug math/30220] New: String to double returns incorrectly rounded value for hexadecimal subnormal

[Bug math/30220] New: String to double returns incorrectly rounded value for hexadecimal subnormal

[michaelrj at google dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30220

            Bug ID: 30220
           Summary: String to double returns incorrectly rounded value for
                    hexadecimal subnormal
           Product: glibc
           Version: unspecified
            Status: UNCONFIRMED
          Severity: minor
          Priority: P2
         Component: math
          Assignee: unassigned at sourceware dot org
          Reporter: michaelrj at google dot com
  Target Milestone: ---

When evaluating the string "0x30000002222225p-1077" with atof or strtod in the
NEAREST rounding mode, the returned value is 0x0.6000000444444p-1022 when it
should be 0x0.6000000444445p-1022.

The easiest way to demonstrate this is by running the following line of code:
printf("%a\n%a\n", 0x30000002222225p-1077, atof("0x30000002222225p-1077"));

I discovered this bug with version 2.36, but it also occurs with a fresh
checkout (latest commit at time of writing is
e78c4c49831d0ca6253ff5ce5b956cdc4189c8a9).

When building glibc I used configure with the option
"--prefix=$HOME/glibc-install/", my triple is x86_64-linux-gnu
(host/build/target are the same), and I'm using gcc version 12.2.0.

I hope this is enough information to replicate my issue, thank you in advance.
--Michael

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug math/30220] String to double returns incorrectly rounded value for hexadecimal subnormal

[michaelrj at google dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30220

--- Comment #1 from Michael Jones <michaelrj at google dot com> ---
I've done a bit more testing and it seems that the issue is that when shifting
away bits for a (hexadecimal) subnormal result, only the lowest bit is checked.
If two bits will be shifted away, and only the second lowest bit is set, that
bit won't be detected and it may be rounded down incorrectly. Here's an updated
test case:

printf("%a\n%a\n\n%a\n%a\n",    
  0x0.7fffffffffffeap-1022, 
  atof("0x0.7fffffffffffeap-1022"),
  0x0.7fffffffffffe9p-1022, 
  atof("0x0.7fffffffffffe9p-1022")
  );

This gives the following result:

"
0x0.7ffffffffffffp-1022
0x0.7fffffffffffep-1022

0x0.7ffffffffffffp-1022
0x0.7ffffffffffffp-1022
"

As you can see, atof is mistakenly rounding the case ending in "ea" down
despite it being higher than the case ending in "e9".

Hope this helps.
--Michael

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug math/30220] String to double returns incorrectly rounded value for hexadecimal subnormal

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30220

--- Comment #2 from Sourceware Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Joseph Myers <jsm28@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=457622c2fa8f9f7435822d5287a437bc8be8090d

commit 457622c2fa8f9f7435822d5287a437bc8be8090d
Author: Joseph Myers <josmyers@redhat.com>
Date:   Tue Aug 27 12:41:02 2024 +0000

    Fix strtod subnormal rounding (bug 30220)

    As reported in bug 30220, the implementation of strtod-family
    functions has a bug in the following case: the input string would,
    with infinite exponent range, take one more bit to represent than is
    available in the normal precision of the return type; the value
    represented is in the subnormal range; and there are no nonzero bits
    in the value, below those that can be represented in subnormal
    precision, other than the least significant bit and possibly the
    0.5ulp bit.  In this case, round_and_return ends up discarding the
    least significant bit.

    Fix by saving that bit to merge into more_bits (it can't be merged in
    at the time it's computed, because more_bits mustn't include this bit
    in the case of after-rounding tininess detection checking if the
    result is still subnormal when rounded to normal precision, so merging
    this bit into more_bits needs to take place after that check).

    Tested for x86_64.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug math/30220] String to double returns incorrectly rounded value for hexadecimal subnormal

[jsm28 at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30220

Joseph Myers <jsm28 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |2.41
         Resolution|---                         |FIXED
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #3 from Joseph Myers <jsm28 at gcc dot gnu.org> ---
Fixed for 2.41.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug math/30220] String to double returns incorrectly rounded value for hexadecimal subnormal

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30220

--- Comment #4 from Sourceware Commits <cvs-commit at gcc dot gnu.org> ---
The release/2.40/master branch has been updated by Arjun Shankar
<arjun@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=d0c1792ad269566f877208ffda91c21dcd1a72e6

commit d0c1792ad269566f877208ffda91c21dcd1a72e6
Author: Joseph Myers <josmyers@redhat.com>
Date:   Tue Aug 27 12:41:02 2024 +0000

    Fix strtod subnormal rounding (bug 30220)

    As reported in bug 30220, the implementation of strtod-family
    functions has a bug in the following case: the input string would,
    with infinite exponent range, take one more bit to represent than is
    available in the normal precision of the return type; the value
    represented is in the subnormal range; and there are no nonzero bits
    in the value, below those that can be represented in subnormal
    precision, other than the least significant bit and possibly the
    0.5ulp bit.  In this case, round_and_return ends up discarding the
    least significant bit.

    Fix by saving that bit to merge into more_bits (it can't be merged in
    at the time it's computed, because more_bits mustn't include this bit
    in the case of after-rounding tininess detection checking if the
    result is still subnormal when rounded to normal precision, so merging
    this bit into more_bits needs to take place after that check).

    Tested for x86_64.

    (cherry picked from commit 457622c2fa8f9f7435822d5287a437bc8be8090d)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug math/30220] String to double returns incorrectly rounded value for hexadecimal subnormal

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30220

--- Comment #5 from Sourceware Commits <cvs-commit at gcc dot gnu.org> ---
The release/2.39/master branch has been updated by Arjun Shankar
<arjun@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=a7be595c67d12f1a442e3f6894d67e20c7724bed

commit a7be595c67d12f1a442e3f6894d67e20c7724bed
Author: Joseph Myers <josmyers@redhat.com>
Date:   Tue Aug 27 12:41:02 2024 +0000

    Fix strtod subnormal rounding (bug 30220)

    As reported in bug 30220, the implementation of strtod-family
    functions has a bug in the following case: the input string would,
    with infinite exponent range, take one more bit to represent than is
    available in the normal precision of the return type; the value
    represented is in the subnormal range; and there are no nonzero bits
    in the value, below those that can be represented in subnormal
    precision, other than the least significant bit and possibly the
    0.5ulp bit.  In this case, round_and_return ends up discarding the
    least significant bit.

    Fix by saving that bit to merge into more_bits (it can't be merged in
    at the time it's computed, because more_bits mustn't include this bit
    in the case of after-rounding tininess detection checking if the
    result is still subnormal when rounded to normal precision, so merging
    this bit into more_bits needs to take place after that check).

    Tested for x86_64.

    (cherry picked from commit 457622c2fa8f9f7435822d5287a437bc8be8090d)

-- 
You are receiving this mail because:
You are on the CC list for the bug.