[Bug middle-end/108742] New: Incorrect constant folding with (or exposed by) -fexcess-precision=standard

[Bug middle-end/108742] New: Incorrect constant folding with (or exposed by) -fexcess-precision=standard

[matz at gcc dot gnu.org]

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

            Bug ID: 108742
           Summary: Incorrect constant folding with (or exposed by)
                    -fexcess-precision=standard
           Product: gcc
           Version: 12.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: matz at gcc dot gnu.org
  Target Milestone: ---

This came from a discussion about a user wondering why g++ behaved different
between GCC 12 and GCC 13, regarding equality comparisons of floating point
values on x87, i.e. -m32, which ultimately was because GCC 13 activated
-fexcess-precision=standard with -std=c++17.  Now this is not in itself
surprising, but I think something is still wrong.  From commit
98e341130f87984af07c884fea773c0bb3cc8821 (adding this to c++17):

...
    The existing testcases tweaks were for cases on i686-linux where excess
    precision breaks those tests, e.g. if we have
      double d = 4.2;
      if (d == 4.2)
    then it does the expected thing only with -fexcess-precision=fast,
    because with -fexcess-precision=standard it is actually
      double d = 4.2;
      if ((long double) d == 4.2L)
    where 4.2L is different from 4.2.
...

And indeed a simple testcase about this (for C, but it demonstrates the same
thing): 
% cat float.c
#define bool _Bool
int main()
{
  double d = 4.2;

  bool eq1 = (long double)d == (long double)4.2;
  bool eq2 = (long double)d == 4.2L;
  bool eq3 = (long double)d == (long double)(double)4.2;

  __builtin_printf ("equal: %d/%d/%d\n", eq1, eq2, eq3);
  __builtin_printf ("1: %La\n", 4.2L);
  __builtin_printf ("2: %La\n", (long double)4.2);
  __builtin_printf ("3: %La\n", (long double)(double)4.2);

  return 0;
}
% gcc -m32 -O0 -fexcess-precision=fast -o fast float.c
% gcc -m32 -O0 -fexcess-precision=standard -o standard float.c
% ./fast
equal: 1/0/1
1: 0x8.666666666666666p-1
2: 0x8.6666666666668p-1
3: 0x8.6666666666668p-1
% ./standard
equal: 0/0/1
1: 0x8.666666666666666p-1
2: 0x8.666666666666666p-1
3: 0x8.6666666666668p-1


The bug I think exists is that also with =standard the first comparison
should yield 'true' and that irrespective of the excess-prec setting result (2)
should always be the same as (3).  As the comment for the commit correctly
says:
   (long double)4.2 != 4.2L
hence, even with -fexcess-precision=standard the former should _not_ be
const-folded into the latter, but rather into the exact long double value that
corresponds to (double)4.2.  Namely:

(gdb) p/x (long double)4.2
$1 = 0x40018666666666666800
(gdb) p/x (long double)4.2L
$2 = 0x40018666666666666666

The former is the correct long double value to use for the casted double
literal, not the latter.

IOW: it's fine that -fexcess-precision=standard tries to emulate the excess
precision on the hardware by doing all arithmetics in the larger type.  But
then
also the constants need to be folded exactly as the hardware would be doing.

In still other words: I think we have a bug in our constant folders and I don't
think it has anything directly to do with -fexcess-precision=standard, but is
merely exposed by it.  The wrong value is already present in 005t.original:

  __builtin_printf ((const char *) "1: %La\n",
4.19999999999999999982652765240231929055880755186080932617e+0);
  __builtin_printf ((const char *) "2: %La\n",
4.19999999999999999982652765240231929055880755186080932617e+0);
  __builtin_printf ((const char *) "3: %La\n",
4.20000000000000017763568394002504646778106689453125e+0);

[Bug middle-end/108742] Incorrect constant folding with (or exposed by) -fexcess-precision=standard

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marxin at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2023-02-09
     Ever confirmed|0                           |1

[Bug target/108742] Incorrect constant folding with (or exposed by) -fexcess-precision=standard

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org,
                   |                            |jsm28 at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I think the above works exactly as it should, CCing Joseph to confirm.

[Bug target/108742] Incorrect constant folding with (or exposed by) -fexcess-precision=standard

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Note, internally in standard excess precision, 4.2 seen by the lexer is
actually
EXCESS_PRECISION <double, 4.2L>, when it is assigned to a double variable or
cast
to double (i.e. in places where C/C++ require the excess precision to be
converted to the narrower one) it is rounded to double, but when used as (long
double)4.2 it is
the same as 4.2L and even (long double)d == (long double)4.2 should behave the
same
as (long double)d == 4.2 and d == 4.2.

[Bug target/108742] Incorrect constant folding with (or exposed by) -fexcess-precision=standard

[matz at gcc dot gnu.org]

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

--- Comment #3 from Michael Matz <matz at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #2)
> Note, internally in standard excess precision, 4.2 seen by the lexer is
> actually
> EXCESS_PRECISION <double, 4.2L>,

Then _that_ is the problem.  The literal "4.2" simply is not a long double
literal "4.2L".

> when it is assigned to a double variable or
> cast
> to double (i.e. in places where C/C++ require the excess precision to be
> converted to the narrower one) it is rounded to double,
> but when used as (long double)4.2 it is the same as 4.2L

I disagree.  As "4.2" is "(double)4.2" then therefore "(long double)4.2" should
be the same as "(long double)(double)4.2".

> and even (long double)d == (long double)4.2 should behave
> the same as (long double)d == 4.2 and d == 4.2.

On this we agree, all these expressions should behave the same.  But I say they
should _not_ behave the same as "(long double)d == 4.2L".

[Bug target/108742] Incorrect constant folding with (or exposed by) -fexcess-precision=standard

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
See https://gcc.gnu.org/legacy-ml/gcc-patches/2008-11/msg00105.html for
details.

[Bug target/108742] Incorrect constant folding with (or exposed by) -fexcess-precision=standard

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
https://eel.is/c++draft/cfloat.syn points to the C standard for FLT_EVAL_METHOD
(plus https://eel.is/c++draft/expr#pre-6 talks about excess precision too) and
e.g. C17
5.2.4.2.2/9):
"2 evaluate all operations and constants to the range and precision of the long
double type."

Note the " and constants" above.

[Bug target/108742] Incorrect constant folding with (or exposed by) -fexcess-precision=standard

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Michael Matz from comment #3)
> (In reply to Jakub Jelinek from comment #2)
> > Note, internally in standard excess precision, 4.2 seen by the lexer is
> > actually
> > EXCESS_PRECISION <double, 4.2L>,
> 
> Then _that_ is the problem.  The literal "4.2" simply is not a long double
> literal "4.2L".

4.2 isn't 4.2L, because say typeof(4.2) is double, not long double as for
typeof(4.2L),
but with excess precision it has the same value, as mandated by the standards.

[Bug target/108742] Incorrect constant folding with (or exposed by) -fexcess-precision=standard

[matz at gcc dot gnu.org]

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

--- Comment #7 from Michael Matz <matz at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #5)
> https://eel.is/c++draft/cfloat.syn points to the C standard for
> FLT_EVAL_METHOD
> (plus https://eel.is/c++draft/expr#pre-6 talks about excess precision too)
> and e.g. C17
> 5.2.4.2.2/9):
> "2 evaluate all operations and constants to the range and precision of the
> long double type."
> 
> Note the " and constants" above.

Yes.  But that leaves unspecified exactly to what bit pattern the string "4.2"
should be converted to.  Both values used (0x8.666666666666666p-1 and
0x8.6666666666668p-1) are in "the range and precision of the long doubel type".

For that: 6.4.4.2 Floating constants (sorry, only c11 here, I hope wording to
same effect is still in c17):

4 An unsuffixed floating constant has type double. If suffixed by the letter f
  or F...

5  Floating constants are converted to internal format as if at
translation-time. ...

So, my interpretation is that unsuffixed "4.2" has to be the double constant
4.2 (in IEEE double aka 0x1.0cccccccccccdp+2), which is then, because of
FLT_EVAL_METHOD, evaluated to "range and precision of long double" leading
to 0x8.6666666666668p-1, not to 0x8.666666666666666p-1 .

[Bug target/108742] Incorrect constant folding with (or exposed by) -fexcess-precision=standard

[matz at gcc dot gnu.org]

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

--- Comment #8 from Michael Matz <matz at gcc dot gnu.org> ---
(In reply to Michael Matz from comment #7)
> So, my interpretation is that unsuffixed "4.2" has to be the double constant
> 4.2 (in IEEE double aka 0x1.0cccccccccccdp+2), which is then, because of
> FLT_EVAL_METHOD, evaluated to "range and precision of long double" leading
> to 0x8.6666666666668p-1, not to 0x8.666666666666666p-1 .

That is, I think that the real_from_string3 call in interpret_float should use
TYPE_MODE(type) plus conversion to const_type, not const_type plus conversion
to type (for over/underflow warnings).

[Bug target/108742] Incorrect constant folding with (or exposed by) -fexcess-precision=standard

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Michael Matz from comment #7)
> (In reply to Jakub Jelinek from comment #5)
> > https://eel.is/c++draft/cfloat.syn points to the C standard for
> > FLT_EVAL_METHOD
> > (plus https://eel.is/c++draft/expr#pre-6 talks about excess precision too)
> > and e.g. C17
> > 5.2.4.2.2/9):
> > "2 evaluate all operations and constants to the range and precision of the
> > long double type."
> > 
> > Note the " and constants" above.
> 
> Yes.  But that leaves unspecified exactly to what bit pattern the string
> "4.2" should be converted to.

It should be converted to the closest long double, which is
0x8.6666666666668p-1,
otherwise the constants wouldn't be evaluated to the range and precision of the
long double type, only to double type then extended to long double.  In that
case there
would be no point to mention the " and constants" above, only operations would
have excess precision, so double d; ... d = d + 4.2; would be d = (double)
((long double) d + (long double) (double) 4.2), while it actuall should be d =
(double) ((long double) d + 4.2L);

> 4 An unsuffixed floating constant has type double.

Sure, see the typeof above, 4.2 with FLT_EVAL_METHOD == 2 has typeof double,
but
value of 4.2L.  If you want 4.2 in double precision, you need (double) 4.2 or
(double) 4.2L or (double) 4.2f (all of them the same), or assign 4.2 to a
double object.

[Bug target/108742] Incorrect constant folding with (or exposed by) -fexcess-precision=standard

[matz at gcc dot gnu.org]

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

--- Comment #10 from Michael Matz <matz at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #9)
> (In reply to Michael Matz from comment #7)
> > (In reply to Jakub Jelinek from comment #5)
> > > https://eel.is/c++draft/cfloat.syn points to the C standard for
> > > FLT_EVAL_METHOD
> > > (plus https://eel.is/c++draft/expr#pre-6 talks about excess precision too)
> > > and e.g. C17
> > > 5.2.4.2.2/9):
> > > "2 evaluate all operations and constants to the range and precision of the
> > > long double type."
> > > 
> > > Note the " and constants" above.
> > 
> > Yes.  But that leaves unspecified exactly to what bit pattern the string
> > "4.2" should be converted to.
> 
> It should be converted to the closest long double, which is
> 0x8.6666666666668p-1,
> otherwise the constants wouldn't be evaluated to the range and precision of
> the long double type, only to double type then extended to long double.

Yes.

> In that case there
> would be no point to mention the " and constants" above, only operations
> would have excess precision, so double d; ... d = d + 4.2; would be d =
> (double) ((long double) d + (long double) (double) 4.2), while it actuall
> should be d = (double) ((long double) d + 4.2L);

As is clear by now, I disagree on that.  FLT_EVAL_METHOD is for dealing with
excess presicion hardware in a predictable way.  x87 loads double constants
into the 80bit regs trivially (with the value I want "(long double)4.2" to
have, not
4.2L), so that's what the frontend should do.  I think an argument that
involves that the standard otherwise "would have no point mentioning" something
is
slippery at best.

> Sure, see the typeof above, 4.2 with FLT_EVAL_METHOD == 2 has typeof double,
> but value of 4.2L.

I think we'll have to agree to disagree here and let Joseph have the say :-)

[Bug target/108742] Incorrect constant folding with (or exposed by) -fexcess-precision=standard

[joseph at codesourcery dot com]

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

--- Comment #11 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
As discussed, FLT_EVAL_METHOD applies to constants as well as to 
operations.  See the example in C17 F.8.5, for example; it shows

float y = 1.1e75f; // may raise exceptions

since 1.1e75f may be evaluated to a wider range and precision than those 
of float, in which case the conversion to the range and precision of float 
occurs at runtime (whereas if there is no excess range and precision for 
float, the constant is evaluated to positive infinity of type float at 
translation time).

[Bug target/108742] Incorrect constant folding with (or exposed by) -fexcess-precision=standard

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pdimov at gmail dot com

--- Comment #12 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 110477 has been marked as a duplicate of this bug. ***

[Bug target/108742] Incorrect constant folding with (or exposed by) -fexcess-precision=standard

[pdimov at gmail dot com]

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

--- Comment #13 from Peter Dimov <pdimov at gmail dot com> ---
I think that https://eel.is/c++draft/lex.fcon#3 disagrees.

"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.

[Bug target/108742] Incorrect constant folding with (or exposed by) -fexcess-precision=standard

[mkretz at gcc dot gnu.org]

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

Matthias Kretz (Vir) <mkretz at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mkretz at gcc dot gnu.org

--- Comment #14 from Matthias Kretz (Vir) <mkretz at gcc dot gnu.org> ---
It seems like the C++ standard doesn't allow excess precision of floating-point
literals. And it wouldn't allow (float)3.14f to be anything different than
3.14f either. See https://cplusplus.github.io/CWG/issues/2752.html

[Bug target/108742] Incorrect constant folding with (or exposed by) -fexcess-precision=standard

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |SUSPENDED

--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Suspending until the CWG is resolved.