Re: What is acceptable for -ffast-math? (Was: associative law in combine)

[Jan Hubicka <jh@suse.cz>]

> 
> This optimization is specifically permitted for appropriate data types
> by the Fortran standard, with the reservation that parentheses employed
> to prevent re-association must be observed.  As gcc is unable to
> distinguish between the expressions (a/b)/c and a/b/c, this optimization
> would violate the standard in the former case, so is undesirable for
> enabling under -ffast-math.
Our documentation of -ffast-math seems to be wondefully incomplette:

This option causes the preprocessor macro @code{__FAST_MATH__} to be defined.

This option should never be turned on by any @option{-O} option since
it can result in incorrect output for programs which depend on
an exact implementation of IEEE or ISO rules/specifications for
math functions.

But my understanding is, that -ffast-math allow compiler to do transformations
not strictly correct, but working in was majority of cases.  The
transofrmations mentioned above looks like good example of these.

I would like to keep them under -ffast-math for simple purpose, that users
tends to know about -ffast-math and use it, but don't know about possibly new
functions.  I believe that the typical usage of Joe user will be to try
"-ffast-math" and if don't work and he is really interested in the
perofrmance, he will try the suboptions.

GLIBC for instance does inlining of some math functions on -ffast-math that
gives inexact results.

I agree with idea of adding new options to control this feature, but as
options of -ffast-math, as the -funsafe-math-optimizations, -ftrapping-math
and -ferrno-math is currently implemented.
> 
> When Honza and I first discussed this, and also the transformation
> 
> for(i=0;i<n;++i)
>     a[i]=b[i]/c;
> 
> to
> 
> for(i=0;i<n;++i)
>     a[i]=b[i]*(1/c);
I've already implemented this transformation.
> 
> I mentioned that these would put too many risks in the -ffast-math
> category.  I would like to see -ffast-math permit only those
> optimizations outside of IEEE compliance which are generally expected
> (e.g. according to Fortran standard).
You do have experience with this options.  Do you know examples of programs
where it fails?

For instance we already do reassociation with -ffast-math
> 
> For gcc-3.1, I would like to see an additional switch to permit
> optimizations such as the ones on floating point division mentioned
> above.  I don't care about the name, but it should be more mnemonic than
> the ones used by commercial compilers; something like -ffast-div.
This sounds resonable name.  If no one complains, I will add it in the
sense mentioned above.

Honza