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
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
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
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.
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050
Andrew Pinski changed:
What|Removed |Added
Resolution|INVALID |DUPLICATE
--- Comment #11 from Andrew
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.
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050
--- Comment #3 from Andrew Pinski ---
See PR 323 and other related bug reports.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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
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)
18 matches
Mail list logo
