https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110477
--- Comment #8 from Peter Dimov ---
As I commented on the duplicate bug, I don't think this behavior is allowed by
https://eel.is/c++draft/lex.fcon#3.
"If the scaled value is not in the range of representable values for its type,
the program is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110477
Matthias Kretz (Vir) changed:
What|Removed |Added
CC||mkretz at gcc dot gnu.org
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110477
--- Comment #6 from Peter Dimov ---
I suppose this is unfixable because there's all sorts of code assuming that the
value of (long double)3.14 is 3.14L and not (long double)(double)3.14L.
I doubt that anyone sane expects this from (long double)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110477
--- Comment #5 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #4)
> double f = 2.1;
> assert( f == 2.1 ); // fails
Which is effectively the same as your example from PR 110476.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110477
--- Comment #4 from Jonathan Wakely ---
(In reply to Peter Dimov from comment #1)
> Looks like a duplicate of
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108742 and is fixed by casting
> the rhs to (float),
Yes, with -fexcess-precision=stand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110477
--- Comment #3 from Peter Dimov ---
That's true, but the normal expectation of anyone using
-fexcess-precision=standard would be for it to apply consistently everywhere
(that is, as if FLT_EVAL_METHOD is 0.)
Of course given that FLT_EVAL_METHOD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110477
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110477
--- Comment #1 from Peter Dimov ---
Looks like a duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108742
and is fixed by casting the rhs to (float), but any ordinary programmer would
be baffled.
For context, I encountered this regressi
