This is the mail archive of the
mailing list for the GCC project.
RE: What is acceptable for -ffast-math? (Was: associative law in combine)
- To: <dewar at gnat dot com>, <gcc at gcc dot gnu dot org>
- Subject: RE: What is acceptable for -ffast-math? (Was: associative law in combine)
- From: "Vincent Penquerc'h" <vincent at qubesoft dot com>
- Date: Wed, 1 Aug 2001 14:48:38 +0100
> <<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
> 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
> For example, providing true -mieee results is really expensive on
> the Alpha,
> so it is well worth compromising. Similarly, providing exact Java
> 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).