[Bug c/114746] New: With FLT_EVAL_METHOD = 2, -fexcess-precision=fast reduces the precision of floating-point constants

[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]

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

            Bug ID: 114746
           Summary: With FLT_EVAL_METHOD = 2, -fexcess-precision=fast
                    reduces the precision of floating-point constants
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: vincent-gcc at vinc17 dot net
  Target Milestone: ---

-fexcess-precision was added to resolve bug 323, so that with
-fexcess-precision=standard, after an assignment or a cast, the value is
converted to its semantic type; this conversion makes the program slower, hence
-fexcess-precision=fast to have faster programs *without sacrificing their
accuracy* in average (except for programs that are based on such a conversion).
Said otherwise, the values may be kept with more precision than normally
expected.

Thus it is not expected that -fexcess-precision=fast reduces the precision of a
value.

However, with FLT_EVAL_METHOD = 2, -fexcess-precision=fast reduces the
precision of floating-point constants compared to what is specified by the
standard. This is a much worse issue.

Testcase:

#include <stdio.h>
#include <float.h>

int main (void)
{
  printf ("FLT_EVAL_METHOD = %d\n", FLT_EVAL_METHOD);
  printf ("%La\n%La\n", 1e-8L, (long double) 1e-8);
  printf ("%a\n%a\n", (double) 1e-8, (double) 1e-8f);
  return 0;
}

With GCC 14.0.1 20240330 (experimental) [master r14-9728-g6fc84f680d0] using
-m32 -fexcess-precision=fast, I get:

FLT_EVAL_METHOD = 2
0xa.bcc77118461cefdp-30
0xa.bcc77118461dp-30
0x1.5798ee2308c3ap-27
0x1.5798eep-27

instead of the expected output (e.g. by using -fexcess-precision=standard)

FLT_EVAL_METHOD = 2
0xa.bcc77118461cefdp-30
0xa.bcc77118461cefdp-30
0x1.5798ee2308c3ap-27
0x1.5798ee2308c3ap-27

[Bug c/114746] With FLT_EVAL_METHOD = 2, -fexcess-precision=fast reduces the precision of floating-point constants

[vincent-gcc at vinc17 dot net]

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

[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]

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

[Bug c/114746] With FLT_EVAL_METHOD = 2, -fexcess-precision=fast reduces the precision of floating-point constants and floating-point constant expressions

[jsm28 at gcc dot gnu.org]

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.

[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]

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.

[Bug c/114746] With FLT_EVAL_METHOD = 2, -fexcess-precision=fast reduces the precision of floating-point constants and floating-point constant expressions

[jakub at gcc dot gnu.org]

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.

[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]

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

[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]

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