* FLT_EVAL_METHOD vs fexcess-precision
@ 2023-09-01 9:55 Mathieu Malaterre
2023-09-01 10:14 ` Jonathan Wakely
2023-09-01 10:28 ` Jonathan Wakely
0 siblings, 2 replies; 6+ messages in thread
From: Mathieu Malaterre @ 2023-09-01 9:55 UTC (permalink / raw)
To: gcc-help
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: FLT_EVAL_METHOD vs fexcess-precision
2023-09-01 9:55 FLT_EVAL_METHOD vs fexcess-precision Mathieu Malaterre
@ 2023-09-01 10:14 ` Jonathan Wakely
2023-09-01 10:19 ` Jonathan Wakely
2023-09-01 10:28 ` Jonathan Wakely
1 sibling, 1 reply; 6+ messages in thread
From: Jonathan Wakely @ 2023-09-01 10:14 UTC (permalink / raw)
To: Mathieu Malaterre; +Cc: gcc-help
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: FLT_EVAL_METHOD vs fexcess-precision
2023-09-01 10:14 ` Jonathan Wakely
@ 2023-09-01 10:19 ` Jonathan Wakely
0 siblings, 0 replies; 6+ messages in thread
From: Jonathan Wakely @ 2023-09-01 10:19 UTC (permalink / raw)
To: Mathieu Malaterre; +Cc: gcc-help
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: FLT_EVAL_METHOD vs fexcess-precision
2023-09-01 9:55 FLT_EVAL_METHOD vs fexcess-precision Mathieu Malaterre
2023-09-01 10:14 ` Jonathan Wakely
@ 2023-09-01 10:28 ` Jonathan Wakely
2023-09-01 12:02 ` Mathieu Malaterre
1 sibling, 1 reply; 6+ messages in thread
From: Jonathan Wakely @ 2023-09-01 10:28 UTC (permalink / raw)
To: Mathieu Malaterre; +Cc: gcc-help
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: FLT_EVAL_METHOD vs fexcess-precision
2023-09-01 10:28 ` Jonathan Wakely
@ 2023-09-01 12:02 ` Mathieu Malaterre
2023-09-01 12:19 ` Jonathan Wakely
0 siblings, 1 reply; 6+ messages in thread
From: Mathieu Malaterre @ 2023-09-01 12:02 UTC (permalink / raw)
To: Jonathan Wakely; +Cc: gcc-help
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: FLT_EVAL_METHOD vs fexcess-precision
2023-09-01 12:02 ` Mathieu Malaterre
@ 2023-09-01 12:19 ` Jonathan Wakely
0 siblings, 0 replies; 6+ messages in thread
From: Jonathan Wakely @ 2023-09-01 12:19 UTC (permalink / raw)
To: Mathieu Malaterre; +Cc: gcc-help
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-09-01 12:19 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-09-01 9:55 FLT_EVAL_METHOD vs fexcess-precision Mathieu Malaterre
2023-09-01 10:14 ` Jonathan Wakely
2023-09-01 10:19 ` Jonathan Wakely
2023-09-01 10:28 ` Jonathan Wakely
2023-09-01 12:02 ` Mathieu Malaterre
2023-09-01 12:19 ` Jonathan Wakely
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).