This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: testcase for -ffast-math GE/LT swapping
- To: geoffk at cygnus dot com
- Subject: Re: testcase for -ffast-math GE/LT swapping
- From: Brad Lucier <lucier at math dot purdue dot edu>
- Date: Thu, 28 Dec 2000 19:39:58 -0500 (EST)
- Cc: lucier at math dot purdue dot edu (Brad Lucier), gcc-patches at gcc dot gnu dot org
Re: your testcase
===File gcc/gcc/testsuite/gcc.dg/20001228-1.c===
/* { dg-do compile } */
/* { dg-options "-ffast-math -O2" } */
typedef struct
{
float vs_data[75], vs_peak[75], vs_peak_speed[75];
int vs_refresh_delay;
int vs_doublesize;
} Vis;
void vis_timeout_func(Vis * vis)
{
if (vis->vs_peak[0] < 0.0)
vis->vs_peak[0] = 0.0;
}
I've spent some time in the past month looking at -ffast-math
and trying to figure out (and separate) what it's supposed to do.
Part of the compiler seems to think that -ffast-math implies that
there will not be any NaN's, infinities, gradual underflow, etc.,
in either arguments or results of floating-point expressions, and
generates code that makes this assumption. This seems to hold
even if IEEE math is enabled, either by default or by a compiler
flag.
So I don't believe that this is a valid test case for LT => GE
transformations in the compiler.
I also believe that -ffast-math should be replaced with a number
of other flags, namely
-f[no-]math-errno (exists, and is implied by -ffast-math)
-f[no-]trapping-fp (not used in compiler now)
-f[no-]unsafe-fp-optimizations (implied by -ffast-math)
I believe that this covers all the behaviors in the compiler
that are implied (in various places) by -ffast-math. And I
strongly believe that -ffast-math is not defined precisely
in any place in the sources or the documentation (although
some people seem to have a strong opinion about what it does).
Brad