[Bug c/114746] With FLT_EVAL_METHOD = 2, -fexcess-precision=fast reduces the precision of floating-point constants and floating-point constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114746 --- Comment #7 from Vincent Lefèvre --- 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).
[Bug c/114746] With FLT_EVAL_METHOD = 2, -fexcess-precision=fast reduces the precision of floating-point constants and floating-point constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114746 --- Comment #6 from Vincent Lefèvre --- (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).
[Bug c/114746] With FLT_EVAL_METHOD = 2, -fexcess-precision=fast reduces the precision of floating-point constants and floating-point constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114746 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- 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.
[Bug c/114746] With FLT_EVAL_METHOD = 2, -fexcess-precision=fast reduces the precision of floating-point constants and floating-point constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114746 --- Comment #4 from Vincent Lefèvre --- 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.
[Bug c/114746] With FLT_EVAL_METHOD = 2, -fexcess-precision=fast reduces the precision of floating-point constants and floating-point constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114746 --- Comment #3 from Joseph S. Myers --- 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.
[Bug c/114746] With FLT_EVAL_METHOD = 2, -fexcess-precision=fast reduces the precision of floating-point constants and floating-point constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114746 Vincent Lefèvre 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 --- 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).
[Bug c/114746] With FLT_EVAL_METHOD = 2, -fexcess-precision=fast reduces the precision of floating-point constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114746
--- Comment #1 from Vincent Lefèvre ---
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
#include
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
