[Bug c++/110477] New: -fexcess-precision=standard not applied consistently

[Bug c++/110477] New: -fexcess-precision=standard not applied consistently

[pdimov at gmail dot com]

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

            Bug ID: 110477
           Summary: -fexcess-precision=standard not applied consistently
           Product: gcc
           Version: 13.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: pdimov at gmail dot com
  Target Milestone: ---

The following program

float f( float x, int y )
{
    return x + y;
}

int main()
{
    return f( 3.14f, 1 ) == 3.14f + 1;
}

returns different values with -std=c++XX (https://godbolt.org/z/8dK98ondM) and
-std=gnu++XX (https://godbolt.org/z/4Y4qfsKzM) under GCC 13/14 -m32, because
-fexcess-precision=standard is not consistently applied to both sides of the
comparison. Under -fexcess-precision=fast (and hence under previous GCC
versions), the comparison always succeeds because both sides use excess
precision (https://godbolt.org/z/dzdoxdnM9).

This is the runtime equivalent of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110476.

[Bug c++/110477] -fexcess-precision=standard not applied consistently

[pdimov at gmail dot com]

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.

[Bug c++/110477] -fexcess-precision=standard not applied consistently

[pinskia at gcc dot gnu.org]

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

[Bug c++/110477] -fexcess-precision=standard not applied consistently

[pdimov at gmail dot com]

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.

[Bug c++/110477] -fexcess-precision=standard not applied consistently

[redi at gcc dot gnu.org]

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.

[Bug c++/110477] -fexcess-precision=standard not applied consistently

[redi at gcc dot gnu.org]

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.

[Bug c++/110477] -fexcess-precision=standard not applied consistently

[pdimov at gmail dot com]

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.

[Bug c++/110477] -fexcess-precision=standard not applied consistently

[mkretz at gcc dot gnu.org]

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!

[Bug c++/110477] -fexcess-precision=standard not applied consistently

[pdimov at gmail dot com]

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.