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

["Vincent Penquerc'h" <vincent at qubesoft dot com>]

> <<As long as the differences and gotchas between these two
> modes is well documented, I see little reason to dismiss
> -ffast-math on the grounds that it is less than perfect
> compared to the default behavior.
> >>
>
> No one is dismissing -ffast-math on any grounds, we are just
> discussing what
> it should allow. Clearly everyone has a limit on what is
> reasonable, we need

I was mostly referring to the following statement, which,
while true, is referring to the current -ffast-math behavior
as "broken", whereas it can be seen as "not perfect but still
acceptable" when optimizing:

> | Note that with the current -ffast-math on x86, for example, gcc will
> | already inline things like "sin()" etc using the x87 instruction
directly.
>
> I don't buy the argument
>
>   That is broken, then we should break this as well
>
> If GCC behaves incorrectly in some cases, the appropriate action to
> take is to make it behave correctly, -not- to break other parts.

Hence the second part of my post about different flags to tell
the compiler what is acceptable and what is not.

> The point I keep plugging is that there is no point in providing less
> accurate results unless you get some significant gain from the
> transformation.
> For example, providing true -mieee results is really expensive on
> the Alpha,
> so it is well worth compromising. Similarly, providing exact Java
> semantics
> on the x86 is very expensive so it is worth compromising.

Such flags would be well suited to cover different optimizations
with different architectures (as the -O flags already trigger
different optimizations depending on the architecture).

--
Lyrian