[Bug libstdc++/110145] New: 20_util/to_chars/double.cc fails for -m32 -fexcess-precision=standard

[Bug libstdc++/110145] New: 20_util/to_chars/double.cc fails for -m32 -fexcess-precision=standard

[redi at gcc dot gnu.org]

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

            Bug ID: 110145
           Summary: 20_util/to_chars/double.cc fails for -m32
                    -fexcess-precision=standard
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Keywords: testsuite-fail
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: redi at gcc dot gnu.org
                CC: ppalka at gcc dot gnu.org
  Target Milestone: ---

/home/jwakely/src/gcc/gcc/libstdc++-v3/testsuite/20_util/to_chars/double.cc:56968:
test01()::<lambda(const auto:1&)> [with auto:1 = double_to_chars_testcase
[1679]]: Assertion 'result.ec == errc{}' failed.
FAIL: 20_util/to_chars/double.cc execution test

Fails for this testcase:

    {1e126, chars_format::fixed,
"9999999999999999248677616189928820425446708698348384614392259722252941999757930266031634937628176537515300"
        "58413655532282839040"},

[Bug libstdc++/110145] 20_util/to_chars/double.cc fails for -m32 -fexcess-precision=standard

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Weird, the 1e126 constant shouldn't be with excess precision because it is
stored into a double field (using ctor).
So perhaps the to_chars implementation actually relying somewhere on excess
precision not happening?

[Bug libstdc++/110145] 20_util/to_chars/double.cc fails for -m32 -fexcess-precision=standard

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #1)
> Weird, the 1e126 constant shouldn't be with excess precision because it is
> stored into a double field (using ctor).

Yeah, I've fixed nearly all the other tests that fail with
-fexcess-precision=standard but this one confused me. I don't know what's
happening.

> So perhaps the to_chars implementation actually relying somewhere on excess
> precision not happening?

Given that all the implementation is inside libstdc++.so I don't see how it can
be affected by the options used to include the <charconv> header in the
testcase.

[Bug libstdc++/110145] 20_util/to_chars/double.cc fails for -m32 -fexcess-precision=standard

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I've tried
struct S {
  double value;
  constexpr S(double value) : value (value) {}
};

inline constexpr S s[] = { 1e126 };

int
main ()
{
  __builtin_printf ("%.32La %.32La\n", (long double) s[0].value, (long
double)(double)s[0].value);
  __builtin_printf ("%.32La %.32La\n", 1e126L, (long double)(double)1e126L);
  __builtin_printf ("%.32La\n", (long double) 1e126);
}
and that prints
0xb.d176620a502000000000000000000000p+415
0xb.d176620a502000000000000000000000p+415
0xb.d176620a501fc0000000000000000000p+415
0xb.d176620a502000000000000000000000p+415
0xb.d176620a501fc0000000000000000000p+415
with -m32 -fexcess-precision=standard, which matches my expectations.

[Bug libstdc++/110145] 20_util/to_chars/double.cc fails for -m32 -fexcess-precision=standard

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jsm28 at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Actually, even simple
double a = 1e126;

int
main ()
{
  __builtin_printf ("%.13a\n", a);
}
behaves differently in C between -m64 and -m32 -fexcess-precision=standard.
-m64 gives
0x1.7a2ecc414a03fp+418
while -m32 -fexcess-precision=standard gives
0x1.7a2ecc414a040p+418
Now, 1e126L is 0xb.d176620a501fc0000000000000p+415, which is that
0x1.7a2ecc414a03fp+418
exactly.  So wonder why we try to round that up.

[Bug libstdc++/110145] 20_util/to_chars/double.cc fails for -m32 -fexcess-precision=standard

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Now, putting a breakpoint on round_for_format, seems the constant is actually
0xb.d176620a501fbffb650e5a93bc3d89854bea8f289011b2bp+415 or so before rounding
aka
0x1.7a2ecc414a03f7ff6ca1cb527787b130a97d51e51202365p+418, and long double on
ia32 has
63 bits of precision, so it is correctly rounded to
0x1.7a2ecc414a03f800p+418L when rounding to long double.
And that rounded to double is 0x1.7a2ecc414a040p+418.
While rounding the original long number immediately to 52 bits of precision
yields
0x1.7a2ecc414a03f0p+418.

double a = 1e126L;
double b = 1e126;

int
main ()
{
  __builtin_printf ("%.13a\n%.13a\n", a, b);
}

confirms this.
So, the issue is that with excess precision, we do double rounding of
constants, first
to long double and then to double, while without excess precision it is rounded
just once immediately to double.

[Bug libstdc++/110145] 20_util/to_chars/double.cc fails for -m32 -fexcess-precision=standard

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So perhaps just wrap that single test with #if FLT_EVAL_METHOD == 0 ||
FLT_EVAL_METHOD == 1 (to make sure double constants are evaluated to double
precision)?
Or use 0x1.7a2ecc414a03fp+418 instead of 1e126?  Or both (wrap the 1e126 test
with the
#if and add 0x1.7a2ecc414a03fp+418 after it?

[Bug libstdc++/110145] 20_util/to_chars/double.cc fails for -m32 -fexcess-precision=standard

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2023-06-07
             Status|UNCONFIRMED                 |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 55280
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55280&action=edit
gcc14-pr110145.patch

Untested fix.

[Bug libstdc++/110145] 20_util/to_chars/double.cc fails for -m32 -fexcess-precision=standard

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:88e7f1f7ee67462713a89104ae07e99b191d5e2c

commit r14-1619-g88e7f1f7ee67462713a89104ae07e99b191d5e2c
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Jun 7 19:27:35 2023 +0200

    libstdc++: Fix up 20_util/to_chars/double.cc test for excess precision
[PR110145]

    This test apparently contains 3 problematic floating point constants,
    1e126, 4.91e-6 and 5.547e-6.  These constants suffer from double rounding
    when -fexcess-precision=standard evaluates double constants in the
precision
    of Intel extended 80-bit long double.
    As written in the PR, e.g. the first one is
    0x1.7a2ecc414a03f7ff6ca1cb527787b130a97d51e51202365p+418
    in the precision of GCC's internal format, 80-bit long double has
    63-bit precision, so the above constant rounded to long double is
    0x1.7a2ecc414a03f800p+418L
    (the least significant bit in the 0 before p isn't there already).
    0x1.7a2ecc414a03f800p+418L rounded to IEEE double is
    0x1.7a2ecc414a040p+418.
    Now, if excess precision doesn't happen and we round the GCC's internal
    format number directly to double, it is
    0x1.7a2ecc414a03fp+418 and that is the number the test expects.
    One can see it on x86-64 (where excess precision to long double doesn't
    happen) where double(1e126L) != 1e126.
    The other two constants suffer from the same problem.

    The following patch tweaks the testcase, such that those problematic
    constants are used only if FLT_EVAL_METHOD is 0 or 1 (i.e. when we have
    guarantee the constants will be evaluated in double precision),
    plus adds corresponding tests with hexadecimal constants which don't
    suffer from this excess precision problem, they are exact in double
    and long double can hold all double values.

    2023-06-07  Jakub Jelinek  <jakub@redhat.com>

            PR libstdc++/110145
            * testsuite/20_util/to_chars/double.cc: Include <cfloat>.
            (double_to_chars_test_cases,
            double_scientific_precision_to_chars_test_cases_2,
            double_fixed_precision_to_chars_test_cases_2): #if out 1e126,
4.91e-6
            and 5.547e-6 tests if FLT_EVAL_METHOD is negative or larger than 1.
            Add unconditional tests with corresponding double constants
            0x1.7a2ecc414a03fp+418, 0x1.4981285e98e79p-18 and
            0x1.7440bbff418b9p-18.

[Bug libstdc++/110145] 20_util/to_chars/double.cc fails for -m32 -fexcess-precision=standard

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |13.2

[Bug libstdc++/110145] 20_util/to_chars/double.cc fails for -m32 -fexcess-precision=standard

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|13.2                        |13.3

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 13.2 is being released, retargeting bugs to GCC 13.3.

[Bug libstdc++/110145] 20_util/to_chars/double.cc fails for -m32 -fexcess-precision=standard

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|13.3                        |13.4

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 13.3 is being released, retargeting bugs to GCC 13.4.