FLT_EVAL_METHOD vs fexcess-precision

FLT_EVAL_METHOD vs fexcess-precision

[Mathieu Malaterre]

Hi all,

I am reading a previous post from Pascal Cuoq(*), and it seems things
have changed quite a bit in GCC nowadays. I fail to understand how
FLT_EVAL_METHOD relates to fexcess-precision. Did I miss something?

---

Here is what I see on my Debian/sid/i386 system:

 % gcc -O2 -fexcess-precision=fast   m.c && ./a.out
float eps = 1.192093e-07
2

while:

 % gcc -O2 -fexcess-precision=standard   m.c && ./a.out
float eps = 1.084202e-19
2

with:

 % cat m.c
#include <stdio.h>
#include <float.h>

int main(void)
{
    float floatEps = 1;

    while (1 + floatEps / 2 != 1)
        floatEps /= 2;

    printf("float eps = %e\n", floatEps);
    printf("%d\n", FLT_EVAL_METHOD);
}

For reference:

 % gcc --version
gcc (Debian 13.2.0-2) 13.2.0

(*) https://stackoverflow.com/a/16064515/136285
-- 
Mathieu

Re: FLT_EVAL_METHOD vs fexcess-precision

[Jonathan Wakely]

On Fri, 1 Sept 2023 at 10:57, Mathieu Malaterre via Gcc-help
<gcc-help@gcc.gnu.org> wrote:
>
> Hi all,
>
> I am reading a previous post from Pascal Cuoq(*), and it seems things
> have changed quite a bit in GCC nowadays. I fail to understand how
> FLT_EVAL_METHOD relates to fexcess-precision. Did I miss something?

See https://gcc.gnu.org/gcc-13/changes.html#cxx

>
> ---
>
> Here is what I see on my Debian/sid/i386 system:
>
>  % gcc -O2 -fexcess-precision=fast   m.c && ./a.out
> float eps = 1.192093e-07
> 2
>
> while:
>
>  % gcc -O2 -fexcess-precision=standard   m.c && ./a.out
> float eps = 1.084202e-19
> 2
>
> with:
>
>  % cat m.c
> #include <stdio.h>
> #include <float.h>
>
> int main(void)
> {
>     float floatEps = 1;
>
>     while (1 + floatEps / 2 != 1)
>         floatEps /= 2;
>
>     printf("float eps = %e\n", floatEps);
>     printf("%d\n", FLT_EVAL_METHOD);
> }
>
> For reference:
>
>  % gcc --version
> gcc (Debian 13.2.0-2) 13.2.0
>
> (*) https://stackoverflow.com/a/16064515/136285
> --
> Mathieu

Re: FLT_EVAL_METHOD vs fexcess-precision

[Jonathan Wakely]

On Fri, 1 Sept 2023 at 11:14, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>
> On Fri, 1 Sept 2023 at 10:57, Mathieu Malaterre via Gcc-help
> <gcc-help@gcc.gnu.org> wrote:
> >
> > Hi all,
> >
> > I am reading a previous post from Pascal Cuoq(*), and it seems things
> > have changed quite a bit in GCC nowadays. I fail to understand how
> > FLT_EVAL_METHOD relates to fexcess-precision. Did I miss something?
>
> See https://gcc.gnu.org/gcc-13/changes.html#cxx

Oh but you're asking about C, which hasn't changed in a while.

I'm not sure what your question is then. FLT_EVAL_METHOD tells you
what precision is used for floating-point constants and arithmetic,
and -fexcess-precision says whether GCC strictly follows the
standard's rules about when those excess precision bits are used.

If FLT_EVAL_METHOD==2 then float and double constants are represented
in 80-bit long double format, and arithmetic operations are done in
80-bit long double format. To remove the excess precision and get a
32-bit float or 64-bit double you need to use an explicit cast to
float or double.

If FLT_EVAL_METHOD==0 then there are no excess precision bits, and so
-fexcess-precision makes no difference.

Does that answer the question?


>
> >
> > ---
> >
> > Here is what I see on my Debian/sid/i386 system:
> >
> >  % gcc -O2 -fexcess-precision=fast   m.c && ./a.out
> > float eps = 1.192093e-07
> > 2
> >
> > while:
> >
> >  % gcc -O2 -fexcess-precision=standard   m.c && ./a.out
> > float eps = 1.084202e-19
> > 2
> >
> > with:
> >
> >  % cat m.c
> > #include <stdio.h>
> > #include <float.h>
> >
> > int main(void)
> > {
> >     float floatEps = 1;
> >
> >     while (1 + floatEps / 2 != 1)
> >         floatEps /= 2;
> >
> >     printf("float eps = %e\n", floatEps);
> >     printf("%d\n", FLT_EVAL_METHOD);
> > }
> >
> > For reference:
> >
> >  % gcc --version
> > gcc (Debian 13.2.0-2) 13.2.0
> >
> > (*) https://stackoverflow.com/a/16064515/136285
> > --
> > Mathieu

Re: FLT_EVAL_METHOD vs fexcess-precision

[Jonathan Wakely]

On Fri, 1 Sept 2023 at 10:57, Mathieu Malaterre via Gcc-help
<gcc-help@gcc.gnu.org> wrote:
>
> Hi all,
>
> I am reading a previous post from Pascal Cuoq(*), and it seems things
> have changed quite a bit in GCC nowadays. I fail to understand how
> FLT_EVAL_METHOD relates to fexcess-precision. Did I miss something?
>
> ---
>
> Here is what I see on my Debian/sid/i386 system:

It looks to me like the difference is that you're using i386 (welcome,
time traveller!) where -mfpmath=i387 is the default, so
FLT_EVAL_METHOD=2. I think Pascal's SO answer uses x86_64, where the
default is -mfpmath=sse and so FLT_EVAL_METHOD=0, but changes to 2
when he uses -mfpmath=i387.

Re: FLT_EVAL_METHOD vs fexcess-precision

[Mathieu Malaterre]

On Fri, Sep 1, 2023 at 12:29 PM Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>
> On Fri, 1 Sept 2023 at 10:57, Mathieu Malaterre via Gcc-help
> <gcc-help@gcc.gnu.org> wrote:
> >
> > Hi all,
> >
> > I am reading a previous post from Pascal Cuoq(*), and it seems things
> > have changed quite a bit in GCC nowadays. I fail to understand how
> > FLT_EVAL_METHOD relates to fexcess-precision. Did I miss something?
> >
> > ---
> >
> > Here is what I see on my Debian/sid/i386 system:
>
> It looks to me like the difference is that you're using i386 (welcome,
> time traveller!)

You might remember me from such films as the powerpc, sparc64 or s390x ;)

> where -mfpmath=i387 is the default, so
> FLT_EVAL_METHOD=2. I think Pascal's SO answer uses x86_64, where the
> default is -mfpmath=sse and so FLT_EVAL_METHOD=0, but changes to 2
> when he uses -mfpmath=i387.

I (wrongly) assumed that there was a mapping in between
FLT_EVAL_METHOD and -fexcess-precision based on the eps value.

For context:

I have a math function (log1p impl) which fails with
-fexcess-precision=fast but works with -fexcess-precision=standard on
i386 ... however I see no difference in the #define(s):

% diff -u <(gcc -Wp,-dM -E -c -O2 -fexcess-precision=standard m.c)
<(gcc -Wp,-dM -E -c -O2 -fexcess-precision=fast m.c)

So I do not have any mechanism to detect invalid compilation flags
during build...

Thanks anyway for your kind help,
--
Mathieu

Re: FLT_EVAL_METHOD vs fexcess-precision

[Jonathan Wakely]

On Fri, 1 Sept 2023 at 13:02, Mathieu Malaterre
<mathieu.malaterre@gmail.com> wrote:
>
> On Fri, Sep 1, 2023 at 12:29 PM Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> >
> > On Fri, 1 Sept 2023 at 10:57, Mathieu Malaterre via Gcc-help
> > <gcc-help@gcc.gnu.org> wrote:
> > >
> > > Hi all,
> > >
> > > I am reading a previous post from Pascal Cuoq(*), and it seems things
> > > have changed quite a bit in GCC nowadays. I fail to understand how
> > > FLT_EVAL_METHOD relates to fexcess-precision. Did I miss something?
> > >
> > > ---
> > >
> > > Here is what I see on my Debian/sid/i386 system:
> >
> > It looks to me like the difference is that you're using i386 (welcome,
> > time traveller!)
>
> You might remember me from such films as the powerpc, sparc64 or s390x ;)
>
> > where -mfpmath=i387 is the default, so
> > FLT_EVAL_METHOD=2. I think Pascal's SO answer uses x86_64, where the
> > default is -mfpmath=sse and so FLT_EVAL_METHOD=0, but changes to 2
> > when he uses -mfpmath=i387.
>
> I (wrongly) assumed that there was a mapping in between
> FLT_EVAL_METHOD and -fexcess-precision based on the eps value.
>
> For context:
>
> I have a math function (log1p impl) which fails with
> -fexcess-precision=fast but works with -fexcess-precision=standard on
> i386 ... however I see no difference in the #define(s):

Right, the macro tells you what type is used for floating-point
constants and arithmetic, which is determined by the target CPU and
the -mfpmath option. The macro doesn't tell you whether GCC preserves
any excess precision as required by the rules of the standard or not,
which is what -fexcess-precision controls.


>
> % diff -u <(gcc -Wp,-dM -E -c -O2 -fexcess-precision=standard m.c)
> <(gcc -Wp,-dM -E -c -O2 -fexcess-precision=fast m.c)
>
> So I do not have any mechanism to detect invalid compilation flags
> during build...
>
> Thanks anyway for your kind help,
> --
> Mathieu