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: "Toon Moene" <toon at moene dot indiv dot nluug dot nl>, <dewar at gnat dot com>
- Subject: Re: What is acceptable for -ffast-math? (Was: associative law in combine)
- From: "Tim Prince" <tprince at computer dot org>
- Date: Tue, 31 Jul 2001 21:57:35 -0700
- Cc: <gdr at codesourcery dot com>, <torvalds at transmeta dot com>, <fjh at cs dot mu dot oz dot au>, <gcc at gcc dot gnu dot org>, <moshier at moshier dot ne dot mediaone dot net>
- References: <20010731142629.275BFF2B53@nile.gnat.com> <3B6737C4.806E4B06@moene.indiv.nluug.nl>
----- Original Message -----
From: "Toon Moene" <toon@moene.indiv.nluug.nl>
To: <dewar@gnat.com>
Cc: <gdr@codesourcery.com>; <torvalds@transmeta.com>; <fjh@cs.mu.oz.au>;
<gcc@gcc.gnu.org>; <moshier@moshier.ne.mediaone.net>;
<tprince@computer.org>
Sent: Tuesday, July 31, 2001 3:57 PM
Subject: Re: What is acceptable for -ffast-math? (Was: associative law
in combine)
> dewar@gnat.com wrote:
>
> > By the way, I said I would be shocked to find a Fortran compiler
that did
> > associative redistribution in the absence of parens. I am somewhat
surprised
> > that no one stepped forward with a counter-example, but I suspect in
fact that
> > there may not be any shocking Fortran implementations around.
>
> Well, that might be because we're on a public list and I, certainly,
am
> not going to name names of competitors. Granted, I do not have an
> actual proof of a Fortran compiler that substituted (a+b)*c for
a*b+a*c,
> but I have seen those that:
>
> 1. Included an option to ignore parentheses in the source program.
>
> 2. Included an option to use floating point induction variables, i.e.,
> change:
>
> DO I = 1, N
> A(I) = I * 0.1
> ENDDO
>
> into:
>
> T = 0.0
> DO I = 1, N
> T = T + 0.1
> A(I) = T
> ENDDO
>
The usual meaning of an option to permit floating point induction
variables would be to permit the usage which was covered by the f77
standard and later ruled out, not to introduce them where the source
code is written with integer induction variables. The Kuck KAP
pre-processors worked the other way, converting the second version into
the first, with documented options provided to prevent it. That
transformation was often desired to promote parallelizaton.
> In physics, the computational model in itself is often already a
> compromise - if I just confine myself to weather forecasting, which
I'm
> involved with now for about a decade:
>
> 1. Spherical Earth, rotating with constant angular velocity,
> 2. Ignoring compressibility of the air, assuming hydrostatic
equilibrium
> at all time.
> 3. Ignoring the vertical component of the Coriolis force,
> 4. Constant acceleration of gravity, independent of height.
>
> Now the compromises to make this actually *computable*:
>
> 1. Finite difference discretisation of the continuous equations,
> 2. Filters to damp numerical noise (both in space and time
dimensions),
> 3. Approximations to compute the compound effect of sub-grid scale
> physics (radiation, phase changes of water, etc.).
>
> Now let's look at the question above, again:
>
> "it did not bother [Cray] that 81.0/3.0 did not give exactly 27.0 on
> the CDC 6000 class machines."
>
Typical compilers for IA-64 are off frequently by 1 ULP on simple
division calculations at -O3, and on sqrt() at -O2. This is a normal
consequence of substituting a series of iterations without extra
precision for division. Some may consider this an excessive reversion
toward the Cray tradition.
>