From mboxrd@z Thu Jan  1 00:00:00 1970
From: dewar@gnat.com
To: gdr@codesourcery.com, nick@ing-simmons.net
Cc: amylaar@redhat.com, aoliva@redhat.com, dewar@gnat.com, gcc@gcc.gnu.org, moshier@moshier.ne.mediaone.net, torvalds@transmeta.com, tprince@computer.org
Subject: Re: What is acceptable for -ffast-math? (Was: associative law in    combine)
Date: Fri, 03 Aug 2001 14:48:00 -0000
Message-id: <20010803214842.B9E9DF2B69@nile.gnat.com>
X-SW-Source: 2001-08/msg00191.html

Stephen says

> I'm writing agricultural simulations[1], and I'd be happy to get
> transformations enabled with -ffast-math that would be safe with real
> numbers, but not with floating point numbers.

Well that's at least a coherent position, but I am afraid that no one would
really accept this criterion. for example, this would allow replacing:

  (a*b) / (c*d)

by

  (a * b * 10.0**1000) / (c * d * 10.0**10000)

and introduce overflow where none was expected, and if you think such
a transformation is just obviously unreasonable consider:

   x := b * 10.0**1000;
   y := d * 10.0**1000;

   now compute (a*b) / (c*d)

and to improve efficiency transform this to (a*x)/(c*y), since x and y
happen to be available in registers

Now you might be inclined to say, OK, "transformations that would be safe
with real numbers providing they do not introduce overflow".

But you don't mean that, because many of the transformations we have
discussed introduce overflow in "marginal" cases, and now we are back in
undefined territory.