* [Bug c/114746] With FLT_EVAL_METHOD = 2, -fexcess-precision=fast reduces the precision of floating-point constants
2024-04-16 17:51 [Bug c/114746] New: With FLT_EVAL_METHOD = 2, -fexcess-precision=fast reduces the precision of floating-point constants vincent-gcc at vinc17 dot net
@ 2024-04-17 23:18 ` vincent-gcc at vinc17 dot net
2024-04-17 23:23 ` [Bug c/114746] With FLT_EVAL_METHOD = 2, -fexcess-precision=fast reduces the precision of floating-point constants and floating-point constant expressions vincent-gcc at vinc17 dot net
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: vincent-gcc at vinc17 dot net @ 2024-04-17 23:18 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114746
--- Comment #1 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
There is the same issue with constant floating-point expressions.
Consider the following program given at
https://github.com/llvm/llvm-project/issues/89128
#include <float.h>
#include <stdio.h>
static double const_init = 1.0 + (DBL_EPSILON/2) + (DBL_EPSILON/2);
int main() {
double nonconst_init = 1.0;
nonconst_init = nonconst_init + (DBL_EPSILON/2) + (DBL_EPSILON/2);
printf("FLT_EVAL_METHOD = %d\n", FLT_EVAL_METHOD);
printf("const: %g\n", const_init - 1.0);
printf("nonconst: %g\n", (double)nonconst_init - 1.0);
}
With -m32 -mno-sse, one gets
FLT_EVAL_METHOD = 2
const: 0
nonconst: 2.22045e-16
instead of
FLT_EVAL_METHOD = 2
const: 2.22045e-16
nonconst: 2.22045e-16
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c/114746] With FLT_EVAL_METHOD = 2, -fexcess-precision=fast reduces the precision of floating-point constants and floating-point constant expressions
2024-04-16 17:51 [Bug c/114746] New: With FLT_EVAL_METHOD = 2, -fexcess-precision=fast reduces the precision of floating-point constants vincent-gcc at vinc17 dot net
2024-04-17 23:18 ` [Bug c/114746] " vincent-gcc at vinc17 dot net
@ 2024-04-17 23:23 ` vincent-gcc at vinc17 dot net
2024-04-19 16:50 ` jsm28 at gcc dot gnu.org
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: vincent-gcc at vinc17 dot net @ 2024-04-17 23:23 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114746
Vincent Lefèvre <vincent-gcc at vinc17 dot net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|With FLT_EVAL_METHOD = 2, |With FLT_EVAL_METHOD = 2,
|-fexcess-precision=fast |-fexcess-precision=fast
|reduces the precision of |reduces the precision of
|floating-point constants |floating-point constants
| |and floating-point constant
| |expressions
--- Comment #2 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
I've updated the bug title from "With FLT_EVAL_METHOD = 2,
-fexcess-precision=fast reduces the precision of floating-point constants" to
"With FLT_EVAL_METHOD = 2, -fexcess-precision=fast reduces the precision of
floating-point constants and floating-point constant expressions" (I don't
think that this deserves a separate bug).
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c/114746] With FLT_EVAL_METHOD = 2, -fexcess-precision=fast reduces the precision of floating-point constants and floating-point constant expressions
2024-04-16 17:51 [Bug c/114746] New: With FLT_EVAL_METHOD = 2, -fexcess-precision=fast reduces the precision of floating-point constants vincent-gcc at vinc17 dot net
2024-04-17 23:18 ` [Bug c/114746] " vincent-gcc at vinc17 dot net
2024-04-17 23:23 ` [Bug c/114746] With FLT_EVAL_METHOD = 2, -fexcess-precision=fast reduces the precision of floating-point constants and floating-point constant expressions vincent-gcc at vinc17 dot net
@ 2024-04-19 16:50 ` jsm28 at gcc dot gnu.org
2024-04-22 9:23 ` vincent-gcc at vinc17 dot net
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: jsm28 at gcc dot gnu.org @ 2024-04-19 16:50 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114746
--- Comment #3 from Joseph S. Myers <jsm28 at gcc dot gnu.org> ---
The actual effect of -fexcess-precision=fast is more like "outside the back
end, pretend excess precision doesn't exist, but the back end might use it
anyway" (complicated a bit by having genuine excess precision logic for
_Float16 still in operation when otherwise pretending excess precision doesn't
exist). Pretending excess precision doesn't exist includes not having its
effects on constants. Maybe that's confusing, but the effects of excess
precision on constants also confuse people, as do all forms of excess precision
for operations, so it's not clear that an alternative would be any better.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c/114746] With FLT_EVAL_METHOD = 2, -fexcess-precision=fast reduces the precision of floating-point constants and floating-point constant expressions
2024-04-16 17:51 [Bug c/114746] New: With FLT_EVAL_METHOD = 2, -fexcess-precision=fast reduces the precision of floating-point constants vincent-gcc at vinc17 dot net
` (2 preceding siblings ...)
2024-04-19 16:50 ` jsm28 at gcc dot gnu.org
@ 2024-04-22 9:23 ` vincent-gcc at vinc17 dot net
2024-04-22 12:35 ` jakub at gcc dot gnu.org
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: vincent-gcc at vinc17 dot net @ 2024-04-22 9:23 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114746
--- Comment #4 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
I actually find it more confusing the fact that constants are not evaluated in
extended precision while everything else is evaluated in extended precision.
The real solution to avoid confusion would be to change the behavior so that
FLT_EVAL_METHOD = 0 by default; if users see an effect on the performance
(which may not be the case for applications that do not use floating-point
types very much), they could still use an option to revert to FLT_EVAL_METHOD =
2 (if SSE is not available), in which case they should be aware of the
consequences and would no longer be confused by the results.
But in addition to the confusion, there is the accuracy issue with the current
behavior.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c/114746] With FLT_EVAL_METHOD = 2, -fexcess-precision=fast reduces the precision of floating-point constants and floating-point constant expressions
2024-04-16 17:51 [Bug c/114746] New: With FLT_EVAL_METHOD = 2, -fexcess-precision=fast reduces the precision of floating-point constants vincent-gcc at vinc17 dot net
` (3 preceding siblings ...)
2024-04-22 9:23 ` vincent-gcc at vinc17 dot net
@ 2024-04-22 12:35 ` jakub at gcc dot gnu.org
2024-04-22 21:50 ` vincent-gcc at vinc17 dot net
2024-05-01 23:37 ` vincent-gcc at vinc17 dot net
6 siblings, 0 replies; 8+ messages in thread
From: jakub at gcc dot gnu.org @ 2024-04-22 12:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114746
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
FLT_EVAL_METHOD = 0 is on some hw like the pre-SSE2 ia32 extremely expensive,
far more so than even the very expensive -ffloat-store. That is certainly not
a good default. Plus I'm afraid it would suffer from double rounding, unless
the floating point state is switched each time one needs to perform some
floating point instruction in a different precision.
-fexcess-precision=fast is the old GCC behavior, which certainly doesn't
evaluate everything in extended precision, any time anything needs to be
spilled from i?87 FPU to memory it is rounded back to the declared precision.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c/114746] With FLT_EVAL_METHOD = 2, -fexcess-precision=fast reduces the precision of floating-point constants and floating-point constant expressions
2024-04-16 17:51 [Bug c/114746] New: With FLT_EVAL_METHOD = 2, -fexcess-precision=fast reduces the precision of floating-point constants vincent-gcc at vinc17 dot net
` (4 preceding siblings ...)
2024-04-22 12:35 ` jakub at gcc dot gnu.org
@ 2024-04-22 21:50 ` vincent-gcc at vinc17 dot net
2024-05-01 23:37 ` vincent-gcc at vinc17 dot net
6 siblings, 0 replies; 8+ messages in thread
From: vincent-gcc at vinc17 dot net @ 2024-04-22 21:50 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114746
--- Comment #6 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
(In reply to Jakub Jelinek from comment #5)
> FLT_EVAL_METHOD = 0 is on some hw like the pre-SSE2 ia32 extremely
> expensive, far more so than even the very expensive -ffloat-store. That is
> certainly not a good default. Plus I'm afraid it would suffer from double
> rounding, unless the floating point state is switched each time one needs to
> perform some floating point instruction in a different precision.
I would think that in general, users would choose a FP type and stick to it.
However, there is the problem of libraries.
But I would be interested to know what would be the actual loss in practice,
for the use of such machines nowadays (if users want performance, there are
faster processors, with SSE2 support).
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c/114746] With FLT_EVAL_METHOD = 2, -fexcess-precision=fast reduces the precision of floating-point constants and floating-point constant expressions
2024-04-16 17:51 [Bug c/114746] New: With FLT_EVAL_METHOD = 2, -fexcess-precision=fast reduces the precision of floating-point constants vincent-gcc at vinc17 dot net
` (5 preceding siblings ...)
2024-04-22 21:50 ` vincent-gcc at vinc17 dot net
@ 2024-05-01 23:37 ` vincent-gcc at vinc17 dot net
6 siblings, 0 replies; 8+ messages in thread
From: vincent-gcc at vinc17 dot net @ 2024-05-01 23:37 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114746
--- Comment #7 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
BTW, in /usr/include/math.h from the GNU libc 2.37:
# define M_PI 3.14159265358979323846 /* pi */
i.e. M_PI is defined with 21 digits in base 10, which corresponds to about 70
digits in base 2, thus with the apparent intent to be accurate in extended
precision (64 digits).
^ permalink raw reply [flat|nested] 8+ messages in thread