* [Bug c++/110477] -fexcess-precision=standard not applied consistently
2023-06-29 7:28 [Bug c++/110477] New: -fexcess-precision=standard not applied consistently pdimov at gmail dot com
@ 2023-06-29 8:00 ` pdimov at gmail dot com
2023-06-29 8:04 ` pinskia at gcc dot gnu.org
` (6 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: pdimov at gmail dot com @ 2023-06-29 8:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110477
--- Comment #1 from Peter Dimov <pdimov at gmail dot com> ---
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 regression in the Boost.Variant2 test suite
when I added GCC 13 to CI.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c++/110477] -fexcess-precision=standard not applied consistently
2023-06-29 7:28 [Bug c++/110477] New: -fexcess-precision=standard not applied consistently pdimov at gmail dot com
2023-06-29 8:00 ` [Bug c++/110477] " pdimov at gmail dot com
@ 2023-06-29 8:04 ` pinskia at gcc dot gnu.org
2023-06-29 8:10 ` pdimov at gmail dot com
` (5 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-06-29 8:04 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110477
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |DUPLICATE
Status|UNCONFIRMED |RESOLVED
--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Well "any ordinary programmer would be baffled." There is a lot of counter
intuitive parts of c and c++ and just happens to be one of them .
*** This bug has been marked as a duplicate of bug 108742 ***
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c++/110477] -fexcess-precision=standard not applied consistently
2023-06-29 7:28 [Bug c++/110477] New: -fexcess-precision=standard not applied consistently pdimov at gmail dot com
2023-06-29 8:00 ` [Bug c++/110477] " pdimov at gmail dot com
2023-06-29 8:04 ` pinskia at gcc dot gnu.org
@ 2023-06-29 8:10 ` pdimov at gmail dot com
2023-06-29 8:31 ` redi at gcc dot gnu.org
` (4 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: pdimov at gmail dot com @ 2023-06-29 8:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110477
--- Comment #3 from Peter Dimov <pdimov at gmail dot com> ---
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 is in a header, so unaffected by -f
options, it's not clear what can be done here.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c++/110477] -fexcess-precision=standard not applied consistently
2023-06-29 7:28 [Bug c++/110477] New: -fexcess-precision=standard not applied consistently pdimov at gmail dot com
` (2 preceding siblings ...)
2023-06-29 8:10 ` pdimov at gmail dot com
@ 2023-06-29 8:31 ` redi at gcc dot gnu.org
2023-06-29 8:32 ` redi at gcc dot gnu.org
` (3 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: redi at gcc dot gnu.org @ 2023-06-29 8:31 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110477
--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(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=standard removal of excess precision only occurs
when assigning to an lvalue or with an explicit cast, not for the equality
comparison. An even simpler version is:
double f = 2.1;
assert( f == 2.1 ); // fails
The value f has no excess precision bits, but the literal 2.1 is evaluated as
an 80-bit float. The comparison promotes f to the type of the rhs, but it's
lost its excess precision, so we're effectively doing (double)2.1L == 2.1L and
that's false.
> but any ordinary programmer would be baffled.
Yes, very much so.
(In reply to Peter Dimov from comment #3)
> 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 is in a header, so unaffected by -f
> options, it's not clear what can be done here.
I think the rationale is that without -fexcess-precision=standard we do not
correctly respect FLT_EVAL_METHOD, so its value doesn't matter. With
-fexcess-precision=standard we do respect it ... with confusing consequences.
The solution is to kill i387 ;-)
-m32 -mfpmath=sse gives more sensible results.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c++/110477] -fexcess-precision=standard not applied consistently
2023-06-29 7:28 [Bug c++/110477] New: -fexcess-precision=standard not applied consistently pdimov at gmail dot com
` (3 preceding siblings ...)
2023-06-29 8:31 ` redi at gcc dot gnu.org
@ 2023-06-29 8:32 ` redi at gcc dot gnu.org
2023-06-29 8:44 ` pdimov at gmail dot com
` (2 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: redi at gcc dot gnu.org @ 2023-06-29 8:32 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110477
--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c++/110477] -fexcess-precision=standard not applied consistently
2023-06-29 7:28 [Bug c++/110477] New: -fexcess-precision=standard not applied consistently pdimov at gmail dot com
` (4 preceding siblings ...)
2023-06-29 8:32 ` redi at gcc dot gnu.org
@ 2023-06-29 8:44 ` pdimov at gmail dot com
2023-06-29 9:07 ` mkretz at gcc dot gnu.org
2023-06-29 11:00 ` pdimov at gmail dot com
7 siblings, 0 replies; 9+ messages in thread
From: pdimov at gmail dot com @ 2023-06-29 8:44 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110477
--- Comment #6 from Peter Dimov <pdimov at gmail dot com> ---
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)3.14F, but it's not
feasible to change one but not the other.
Bafflings will continue until morale improves.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c++/110477] -fexcess-precision=standard not applied consistently
2023-06-29 7:28 [Bug c++/110477] New: -fexcess-precision=standard not applied consistently pdimov at gmail dot com
` (5 preceding siblings ...)
2023-06-29 8:44 ` pdimov at gmail dot com
@ 2023-06-29 9:07 ` mkretz at gcc dot gnu.org
2023-06-29 11:00 ` pdimov at gmail dot com
7 siblings, 0 replies; 9+ messages in thread
From: mkretz at gcc dot gnu.org @ 2023-06-29 9:07 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110477
Matthias Kretz (Vir) <mkretz at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mkretz at gcc dot gnu.org
--- Comment #7 from Matthias Kretz (Vir) <mkretz at gcc dot gnu.org> ---
Nah, I don't think (long double)3.14 ever was a thing (before GCC 13). But I'm
very unhappy with the legacy weirdness GCC imports into C++ from C. Peter,
please write a paper to restore sanity. SG6 (at least its chair) will be happy
to receive it!
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c++/110477] -fexcess-precision=standard not applied consistently
2023-06-29 7:28 [Bug c++/110477] New: -fexcess-precision=standard not applied consistently pdimov at gmail dot com
` (6 preceding siblings ...)
2023-06-29 9:07 ` mkretz at gcc dot gnu.org
@ 2023-06-29 11:00 ` pdimov at gmail dot com
7 siblings, 0 replies; 9+ messages in thread
From: pdimov at gmail dot com @ 2023-06-29 11:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110477
--- Comment #8 from Peter Dimov <pdimov at gmail dot com> ---
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 ill-formed. Otherwise, the value of a floating-point-literal is
the scaled value if representable, else the larger or smaller representable
value nearest the scaled value, chosen in an implementation-defined manner."
I don't see any license here for the value of 3.14f to be 3.14L.
^ permalink raw reply [flat|nested] 9+ messages in thread