This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: What is acceptable for -ffast-math? (Was: associative law in combine)
- To: dewar at gnat dot com
- Subject: Re: What is acceptable for -ffast-math? (Was: associative law in combine)
- From: Toon Moene <toon at moene dot indiv dot nluug dot nl>
- Date: Mon, 30 Jul 2001 22:02:56 +0200
- CC: torvalds at transmeta dot com, gcc at gcc dot gnu dot org, moshier at moshier dot ne dot mediaone dot net, tprince at computer dot org
- Organization: Moene Computational Physics, Maartensdijk, The Netherlands
- References: <20010730130002.D7FEEF2B53@nile.gnat.com>
dewar@gnat.com wrote:
> <<It's sad that C99 doesn't seem to allow the Fortran kind of "you go and
> make the best you can of this expression unless I tell you otherwise".
> >>
> But if you look at real Fortran codes, they are full of parentheses to stop
> the compiler from messing around, and in fact most Fortran compilers do only
> very limited mucking even when no parens are present. I would be shocked
> to find a FOrtraqn compiler that changed
>
> a*c + b*c
>
> into
>
> (a+b)*c
>
> a totally diffrerent expression!
>
> I would have written the second expression if I had wanted that effect.
No, you should have written (a*c) + (b*c) if you wanted the first
expression *instead* of the second one - heck, you say so yourself, in
the above (... full of parentheses ...)
[ Note 7.24 in the Fortran 95 Standard ].
Of course this only works one way - the compiler is not free to change
(a+b)*c into (a*c)+(b*c), because of the parentheses in the first
expression.
[ And in another mail: ]
> It certainly would be interesting to hear from someone with extensive
> experience in writing numerical codes supporting Linus' position (I have
> that extensive experience, but for sure I do not support the position
> that a compiler should by default do completely different things from
> what it is told.
Well, I won't be so rash as to say that it should do that *by default*,
but there is a lot of fp code out there that's robust against small
differences in evaluation of floating point expressions. The reason for
this is very simple: The majority of physics processes that are modelled
on a computer can only be computed approximately *even if you used the
real "reals" for it*. Only very few fluid mechanics problems are
usefully "idealized" enough to allow analytic solutions - all others
have to be discretized one way or another (finite differences, finite
elements, spectral decomposition, vortex decomposition, etc.).
Once you allow that approximation, the fact that fp computations are not
"exact" is not very interesting (you still have to watch out for fatal
cancellation, but that's why you should use parentheses where
necessary).
That said, I do agree that I rather use something like -ffast-math to
indicate that I know what I'm doing, and I would be rather disappointed
if -ffast-math wouldn't honor parentheses [in the sense that I wouldn't
use that option anymore] :-)
--
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)