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

2024-04-16 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050

--- Comment #18 from Andrew Pinski  ---
(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.

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

2024-04-16 Thread vincent-gcc at vinc17 dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050

--- Comment #17 from Vincent Lefèvre  ---
(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

2024-04-16 Thread vincent-gcc at vinc17 dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050

--- Comment #16 from Vincent Lefèvre  ---
(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

2024-04-16 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #15 from Jakub Jelinek  ---
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

2024-04-16 Thread vincent-gcc at vinc17 dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050

--- Comment #14 from Vincent Lefèvre  ---
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

2024-04-16 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050

--- Comment #13 from Jonathan Wakely  ---
-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

2024-04-16 Thread vincent-gcc at vinc17 dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050

Vincent Lefèvre  changed:

   What|Removed |Added

 CC||vincent-gcc at vinc17 dot net

--- Comment #12 from Vincent Lefèvre  ---
(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

2024-04-16 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|INVALID |DUPLICATE

--- Comment #11 from Andrew Pinski  ---
.

*** 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

2024-02-22 Thread sjh at schilling dot dk via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050

--- Comment #10 from Søren Jæger Hansen  ---
-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

2024-02-22 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050

--- Comment #9 from Jonathan Wakely  ---
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

2024-02-22 Thread sjh at schilling dot dk via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050

--- Comment #8 from Søren Jæger Hansen  ---
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

2024-02-22 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050

--- Comment #7 from Jonathan Wakely  ---
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

2024-02-22 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---
See explicitly pr 93112

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

2024-02-22 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050

--- Comment #5 from Andrew Pinski  ---
`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

2024-02-22 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050

--- Comment #3 from Andrew Pinski  ---
See PR 323 and other related bug reports.

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

2024-02-22 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Andrew Pinski  ---
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

2024-02-22 Thread sjames at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #4 from Sam James  ---
(and -mfpmath=sse works.)

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

2024-02-22 Thread sjh at schilling dot dk via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050

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