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

[Gabriel Dos_Reis]

| > | > The one obvious case is (b*c) overflows and turns into Inf, at which
| > | > point the end result will be +-0 with the optimization.
| > | 
| > | If there is a difference, will you care to enlighten me?
| 
| > You're quoting just a tiny part of his rhetorics
| 
| Indeed, I failed to quote the other relevant part.  Linus wrote:

More accurately he wrote:

  The one obvious case is (b*c) overflows and turns into Inf, at which point
  the end result will be +-0 with the optimization. Now, in order for the
  original to _not_ have been close to zero, we're talking about 'a' being
  at the very limits of the number space. And remember that on x86 register
  arithmetic - regardless of precision setting - the exponent is 15 bits. So
  in order to get the overflow, AND to get a original value that wasn't zero
  (ie to get an error), 'a' would have had to be on the order of

	  2**(16383-64)

  which won't even _fit_ in a double anyway (the -64 is to take even
  denormals into account, but others have said that flush-to-zero would have
  been acceptable anyway by default). Did I mis-do my calculations.

Emphasis is not mine.  Please note, what he showed: That the
situation (i.e. a/b/c) couldn't have been well-formed in the first
place.  For x86, that may be true.  But that is a specific case. 

| > Now, in order for the original to _not_ have been close to zero,
| > we're talking about 'a' being at the very limits of the number
| > space.
| 
| It appears to me that 0.5 * DBL_MAX is indeed at the very limits of
| the number space.  So, I still fail to see the difference.

I don't consider 0.5 * DBL_MAX to be at the "very limits of the number
space".

| > He used the argument above to derive that for a/b/c not to yeild 0.0,
| > a should have been very very big, which can't happen in practice.
| 
| But he was explicitly talking about x86's extended precision when he
| made this argument.

Yes, he was talking about x86.  But again, when we started discussing
the transformation, there were no limitation to targets.  Again, I
exhibit the example to show that there are out there bunch of
processors where the stance "it won't matter " isn't true.  Now
if the transformation were to be restricted to x86, then that is a
different issue.

-- Gaby