[Bug c++/114050] New: Inconsistency in double/float constant evaluation between 32 and 64 bit

[Bug c++/114050] New: Inconsistency in double/float constant evaluation between 32 and 64 bit

[sjh at schilling dot dk]

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

            Bug ID: 114050
           Summary: Inconsistency in double/float constant evaluation
                    between 32 and 64 bit
           Product: gcc
           Version: 13.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: sjh at schilling dot dk
  Target Milestone: ---

Created attachment 57491
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57491&action=edit
The test application

In GCC version 13 and later, we've found some inconsistency in the way the
compiler calculates double constants in our code. We originally discovered this
in a rounding unit test in our code, and have extracted the specific
inconsistency in attached double-test.cpp.

When compiling in default 64-bit mode on the x86 platform, we get the
consistent result of previous GCC versions (the output from the test code is
the same constant double value calculated in three different ways, and dumped
as hex as well):

g++ -std=c++23 -m64 -o double-test double-test.cpp
./double-test
Output:
GCC version: 13.2.0
a =    -5.42101e-20 ( 00 00 00 00 00 00 f0 bb )
b =    -5.42101e-20 ( 00 00 00 00 00 00 f0 bb )
c =    -5.42101e-20 ( 00 00 00 00 00 00 f0 bb )

However, compiling the same application in 32-bit mode yields a different
result:

g++ -std=c++23 -m32 -o double-test double-test.cpp
./double-test
Output:
GCC version: 13.2.0
a =    -4.06576e-20 ( 00 00 00 00 00 00 e8 bb )
b =               0 ( 00 00 00 00 00 00 00 00 )
c =    -4.06576e-20 ( 00 00 00 00 00 00 e8 bb )

If using gnu extensions as the selected standard, we're back to the old,
consistent behavior, also for 32 bits:

g++ -std=gnu++23 -m32 -o double-test double-test.cpp
./double-test
Output:
GCC version: 13.2.0
a =    -5.42101e-20 ( 00 00 00 00 00 00 f0 bb )
b =    -5.42101e-20 ( 00 00 00 00 00 00 f0 bb )
c =    -5.42101e-20 ( 00 00 00 00 00 00 f0 bb )

We have only seen the problem in 32 bit mode with one of the strict c++
standards selected (-std=c++*), not with gnu extensions (-std=gnu++*).

Testing various versions on the Compiler Explorer site, the problem seems to
occur as of version 13 of GCC.


g++ -v output:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/schilling/gcc-13.2.0/libexec/gcc/x86_64-pc-linux-gnu/13.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-13.2.0/configure
--prefix=/usr/local/schilling/gcc-13.2.0 --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++
--enable-multilib --disable-bootstrap --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.2.0 (GCC)

[Bug c++/114050] Inconsistency in double/float constant evaluation between 32 and 64 bit

[sjh at schilling dot dk]

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

--- Comment #1 from Søren Jæger Hansen <sjh at schilling dot dk> ---
Created attachment 57492
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57492&action=edit
Preprocessed output (gzipped to fit)

[Bug c++/114050] Inconsistency in double/float constant evaluation between 32 and 64 bit

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This is the expected behavior. Due to excessive precision for x87.

[Bug c++/114050] Inconsistency in double/float constant evaluation between 32 and 64 bit

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
See PR 323 and other related bug reports.

[Bug c++/114050] Inconsistency in double/float constant evaluation between 32 and 64 bit

[sjames at gcc dot gnu.org]

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

Sam James <sjames at gcc dot gnu.org> changed:

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

--- Comment #4 from Sam James <sjames at gcc dot gnu.org> ---
(and -mfpmath=sse works.)

[Bug c++/114050] Inconsistency in double/float constant evaluation between 32 and 64 bit

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
`0.0003 - 0.0001*3.0` with -std=c++23 is done all in long double and then
casted to double. Which is why b is 0 there.

[Bug c++/114050] Inconsistency in double/float constant evaluation between 32 and 64 bit

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=93112

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
See explicitly pr 93112

[Bug c++/114050] Inconsistency in double/float constant evaluation between 32 and 64 bit

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
And the first item at https://gcc.gnu.org/bugs/#nonbugs

[Bug c++/114050] Inconsistency in double/float constant evaluation between 32 and 64 bit

[sjh at schilling dot dk]

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

--- Comment #8 from Søren Jæger Hansen <sjh at schilling dot dk> ---
I get all this, and thanks for quick processing. Still I think it's a bit odd
that -std=c++* and -std?=gnu++* gives different results, but I assume there's a
good reason for that.

We'll be using -std=gnu++23 for now and move to 64 bit later as a solution for
us.

[Bug c++/114050] Inconsistency in double/float constant evaluation between 32 and 64 bit

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> ---
See the first item at https://gcc.gnu.org/gcc-13/changes.html#cxx

[Bug c++/114050] Inconsistency in double/float constant evaluation between 32 and 64 bit

[sjh at schilling dot dk]

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

--- Comment #10 from Søren Jæger Hansen <sjh at schilling dot dk> ---
-fexcess-precision=fast it is for now then, thanks again for fast feedback.

[Bug c++/114050] Inconsistency in double/float constant evaluation between 32 and 64 bit

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|INVALID                     |DUPLICATE

--- Comment #11 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
.

*** This bug has been marked as a duplicate of bug 92875 ***

[Bug c++/114050] Inconsistency in double/float constant evaluation between 32 and 64 bit

[vincent-gcc at vinc17 dot net]

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

Vincent Lefèvre <vincent-gcc at vinc17 dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vincent-gcc at vinc17 dot net

--- Comment #12 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
(In reply to Søren Jæger Hansen from comment #10)
> -fexcess-precision=fast it is for now then, thanks again for fast feedback.

-fexcess-precision is unrelated. Its goal is to choose whether GCC conforms to
the standard, i.e. reduces the precision for assignments and casts (*only* in
these cases, thus constants are not concerned), or generates faster but
non-conforming code.

[Bug c++/114050] Inconsistency in double/float constant evaluation between 32 and 64 bit

[redi at gcc dot gnu.org]

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

--- Comment #13 from Jonathan Wakely <redi at gcc dot gnu.org> ---
-fexcess-precision does affect constants.

With -fexcess-precision=standard, assignments and casts discard excess
precision which may otherwise be present in arithmetic expressions and
constants. With -fexcess-precision=fast the excess precision might be retained
even after casts and assignments, or it might be discarded at other points.

But in both cases, a floating constant might have excess precision. Whether
that excess precision is discarded, and when it's discarded, is affected by
-fexcess-precision.

[Bug c++/114050] Inconsistency in double/float constant evaluation between 32 and 64 bit

[vincent-gcc at vinc17 dot net]

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

--- Comment #14 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
This bug is about "double/float constant evaluation" (and it has been marked as
a duplicate of a bug precisely on this subject), not about the rules that are
applied *after* this evaluation.

[Bug c++/114050] Inconsistency in double/float constant evaluation between 32 and 64 bit

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
There is no bug, the compiler implements what the standard says for the
FLT_EVAL_METHOD == 2 case.
If you want in that mode a constant guaranteed to be in double precision, you
need to explicitly cast the constant to double, otherwise it will have long
double precision with type of double and that extra precision is only rounded
to double precision on casts and assignments.

[Bug c++/114050] Inconsistency in double/float constant evaluation between 32 and 64 bit

[vincent-gcc at vinc17 dot net]

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

--- Comment #16 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
(In reply to Jakub Jelinek from comment #15)
> There is no bug, the compiler implements what the standard says for the
> FLT_EVAL_METHOD == 2 case.

I agree. I meant this *invalid* bug.

[Bug c++/114050] Inconsistency in double/float constant evaluation between 32 and 64 bit

[vincent-gcc at vinc17 dot net]

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

--- Comment #17 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
(In reply to Jonathan Wakely from comment #13)
> -fexcess-precision does affect constants.

Indeed, and this is a bug, as -fexcess-precision=fast was not meant to make
general programs less accurate (but to possibly keep more precision internally,
avoiding costly conversions, even in cases where this is forbidden). See bug
114746.

[Bug c++/114050] Inconsistency in double/float constant evaluation between 32 and 64 bit

[pinskia at gcc dot gnu.org]

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

--- Comment #18 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Vincent Lefèvre from comment #17)
> (In reply to Jonathan Wakely from comment #13)
> > -fexcess-precision does affect constants.
> 
> Indeed, and this is a bug, as -fexcess-precision=fast was not meant to make
> general programs less accurate (but to possibly keep more precision
> internally, avoiding costly conversions, even in cases where this is
> forbidden). See bug 114746.

No that is NOT true.