On Fri, 1 Sept 2023 at 13:02, Mathieu Malaterre <mathieu.malaterre@xxxxxxxxx> wrote: > > On Fri, Sep 1, 2023 at 12:29 PM Jonathan Wakely <jwakely.gcc@xxxxxxxxx> wrote: > > > > On Fri, 1 Sept 2023 at 10:57, Mathieu Malaterre via Gcc-help > > <gcc-help@xxxxxxxxxxx> 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
