* [Bug middle-end/108742] Incorrect constant folding with (or exposed by) -fexcess-precision=standard
2023-02-09 15:50 [Bug middle-end/108742] New: Incorrect constant folding with (or exposed by) -fexcess-precision=standard matz at gcc dot gnu.org
@ 2023-02-09 15:56 ` marxin at gcc dot gnu.org
2023-02-09 16:06 ` [Bug target/108742] " jakub at gcc dot gnu.org
` (14 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: marxin at gcc dot gnu.org @ 2023-02-09 15:56 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug target/108742] Incorrect constant folding with (or exposed by) -fexcess-precision=standard
2023-02-09 15:50 [Bug middle-end/108742] New: Incorrect constant folding with (or exposed by) -fexcess-precision=standard matz at gcc dot gnu.org
2023-02-09 15:56 ` [Bug middle-end/108742] " marxin at gcc dot gnu.org
@ 2023-02-09 16:06 ` jakub at gcc dot gnu.org
2023-02-09 16:10 ` jakub at gcc dot gnu.org
` (13 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-02-09 16:06 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug target/108742] Incorrect constant folding with (or exposed by) -fexcess-precision=standard
2023-02-09 15:50 [Bug middle-end/108742] New: Incorrect constant folding with (or exposed by) -fexcess-precision=standard matz at gcc dot gnu.org
2023-02-09 15:56 ` [Bug middle-end/108742] " marxin at gcc dot gnu.org
2023-02-09 16:06 ` [Bug target/108742] " jakub at gcc dot gnu.org
@ 2023-02-09 16:10 ` jakub at gcc dot gnu.org
2023-02-09 16:19 ` matz at gcc dot gnu.org
` (12 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-02-09 16:10 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug target/108742] Incorrect constant folding with (or exposed by) -fexcess-precision=standard
2023-02-09 15:50 [Bug middle-end/108742] New: Incorrect constant folding with (or exposed by) -fexcess-precision=standard matz at gcc dot gnu.org
` (2 preceding siblings ...)
2023-02-09 16:10 ` jakub at gcc dot gnu.org
@ 2023-02-09 16:19 ` matz at gcc dot gnu.org
2023-02-09 16:25 ` jakub at gcc dot gnu.org
` (11 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: matz at gcc dot gnu.org @ 2023-02-09 16:19 UTC (permalink / raw)
To: gcc-bugs
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".
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug target/108742] Incorrect constant folding with (or exposed by) -fexcess-precision=standard
2023-02-09 15:50 [Bug middle-end/108742] New: Incorrect constant folding with (or exposed by) -fexcess-precision=standard matz at gcc dot gnu.org
` (3 preceding siblings ...)
2023-02-09 16:19 ` matz at gcc dot gnu.org
@ 2023-02-09 16:25 ` jakub at gcc dot gnu.org
2023-02-09 16:31 ` jakub at gcc dot gnu.org
` (10 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-02-09 16:25 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug target/108742] Incorrect constant folding with (or exposed by) -fexcess-precision=standard
2023-02-09 15:50 [Bug middle-end/108742] New: Incorrect constant folding with (or exposed by) -fexcess-precision=standard matz at gcc dot gnu.org
` (4 preceding siblings ...)
2023-02-09 16:25 ` jakub at gcc dot gnu.org
@ 2023-02-09 16:31 ` jakub at gcc dot gnu.org
2023-02-09 16:34 ` jakub at gcc dot gnu.org
` (9 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-02-09 16:31 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug target/108742] Incorrect constant folding with (or exposed by) -fexcess-precision=standard
2023-02-09 15:50 [Bug middle-end/108742] New: Incorrect constant folding with (or exposed by) -fexcess-precision=standard matz at gcc dot gnu.org
` (5 preceding siblings ...)
2023-02-09 16:31 ` jakub at gcc dot gnu.org
@ 2023-02-09 16:34 ` jakub at gcc dot gnu.org
2023-02-09 16:52 ` matz at gcc dot gnu.org
` (8 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-02-09 16:34 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug target/108742] Incorrect constant folding with (or exposed by) -fexcess-precision=standard
2023-02-09 15:50 [Bug middle-end/108742] New: Incorrect constant folding with (or exposed by) -fexcess-precision=standard matz at gcc dot gnu.org
` (6 preceding siblings ...)
2023-02-09 16:34 ` jakub at gcc dot gnu.org
@ 2023-02-09 16:52 ` matz at gcc dot gnu.org
2023-02-09 17:00 ` matz at gcc dot gnu.org
` (7 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: matz at gcc dot gnu.org @ 2023-02-09 16:52 UTC (permalink / raw)
To: gcc-bugs
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 .
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug target/108742] Incorrect constant folding with (or exposed by) -fexcess-precision=standard
2023-02-09 15:50 [Bug middle-end/108742] New: Incorrect constant folding with (or exposed by) -fexcess-precision=standard matz at gcc dot gnu.org
` (7 preceding siblings ...)
2023-02-09 16:52 ` matz at gcc dot gnu.org
@ 2023-02-09 17:00 ` matz at gcc dot gnu.org
2023-02-09 17:01 ` jakub at gcc dot gnu.org
` (6 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: matz at gcc dot gnu.org @ 2023-02-09 17:00 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug target/108742] Incorrect constant folding with (or exposed by) -fexcess-precision=standard
2023-02-09 15:50 [Bug middle-end/108742] New: Incorrect constant folding with (or exposed by) -fexcess-precision=standard matz at gcc dot gnu.org
` (8 preceding siblings ...)
2023-02-09 17:00 ` matz at gcc dot gnu.org
@ 2023-02-09 17:01 ` jakub at gcc dot gnu.org
2023-02-09 17:13 ` matz at gcc dot gnu.org
` (5 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-02-09 17:01 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug target/108742] Incorrect constant folding with (or exposed by) -fexcess-precision=standard
2023-02-09 15:50 [Bug middle-end/108742] New: Incorrect constant folding with (or exposed by) -fexcess-precision=standard matz at gcc dot gnu.org
` (9 preceding siblings ...)
2023-02-09 17:01 ` jakub at gcc dot gnu.org
@ 2023-02-09 17:13 ` matz at gcc dot gnu.org
2023-02-09 17:26 ` joseph at codesourcery dot com
` (4 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: matz at gcc dot gnu.org @ 2023-02-09 17:13 UTC (permalink / raw)
To: gcc-bugs
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 :-)
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug target/108742] Incorrect constant folding with (or exposed by) -fexcess-precision=standard
2023-02-09 15:50 [Bug middle-end/108742] New: Incorrect constant folding with (or exposed by) -fexcess-precision=standard matz at gcc dot gnu.org
` (10 preceding siblings ...)
2023-02-09 17:13 ` matz at gcc dot gnu.org
@ 2023-02-09 17:26 ` joseph at codesourcery dot com
2023-06-29 8:04 ` pinskia at gcc dot gnu.org
` (3 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: joseph at codesourcery dot com @ 2023-02-09 17:26 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug target/108742] Incorrect constant folding with (or exposed by) -fexcess-precision=standard
2023-02-09 15:50 [Bug middle-end/108742] New: Incorrect constant folding with (or exposed by) -fexcess-precision=standard matz at gcc dot gnu.org
` (11 preceding siblings ...)
2023-02-09 17:26 ` joseph at codesourcery dot com
@ 2023-06-29 8:04 ` pinskia at gcc dot gnu.org
2023-06-29 10:59 ` pdimov at gmail dot com
` (2 subsequent siblings)
15 siblings, 0 replies; 17+ 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=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. ***
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug target/108742] Incorrect constant folding with (or exposed by) -fexcess-precision=standard
2023-02-09 15:50 [Bug middle-end/108742] New: Incorrect constant folding with (or exposed by) -fexcess-precision=standard matz at gcc dot gnu.org
` (12 preceding siblings ...)
2023-06-29 8:04 ` pinskia at gcc dot gnu.org
@ 2023-06-29 10:59 ` pdimov at gmail dot com
2023-06-30 7:28 ` mkretz at gcc dot gnu.org
2023-06-30 7:36 ` jakub at gcc dot gnu.org
15 siblings, 0 replies; 17+ messages in thread
From: pdimov at gmail dot com @ 2023-06-29 10:59 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug target/108742] Incorrect constant folding with (or exposed by) -fexcess-precision=standard
2023-02-09 15:50 [Bug middle-end/108742] New: Incorrect constant folding with (or exposed by) -fexcess-precision=standard matz at gcc dot gnu.org
` (13 preceding siblings ...)
2023-06-29 10:59 ` pdimov at gmail dot com
@ 2023-06-30 7:28 ` mkretz at gcc dot gnu.org
2023-06-30 7:36 ` jakub at gcc dot gnu.org
15 siblings, 0 replies; 17+ messages in thread
From: mkretz at gcc dot gnu.org @ 2023-06-30 7:28 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug target/108742] Incorrect constant folding with (or exposed by) -fexcess-precision=standard
2023-02-09 15:50 [Bug middle-end/108742] New: Incorrect constant folding with (or exposed by) -fexcess-precision=standard matz at gcc dot gnu.org
` (14 preceding siblings ...)
2023-06-30 7:28 ` mkretz at gcc dot gnu.org
@ 2023-06-30 7:36 ` jakub at gcc dot gnu.org
15 siblings, 0 replies; 17+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-06-30 7:36 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 17+ messages in thread