Bug#706207: gcc-4.6, gcc-4.7: invalid optimization when doing double -> int math and conversion (on big endian archs(?))

[Gabriel Paubert <paubert@iram.es>]

	Hi Ondřej,

On Sat, Apr 27, 2013 at 06:11:06PM +0200, Ondřej Surý wrote:
> Thanks for the breakdown.
> 
> >>
> >> I would expect consistent results, even consistent *bad* results would be ok.
> >
> > Nope, FMA can change the rules of the game in subtle ways. An easy way
> > to check for problems is to recompile the code with -mno-fused-madd.
> 
> I understand the problem now more deeply, Bastian's comments helped
> and also thanks Mathias to pointing to PR323.

Actually PR323 is superficially similar, but very different behind
the scenes. At least you won't hit the case that f(x)!=f(y) when x==y,
which is what happens when you have excess precision which is not
eliminated before the comparison.

But FMA can cause other surprises, for example x=a*b+c*d. Will
the compiler evaluate it as x=fma(a,b,c*d) of x=fma(c,d,a*b)? 

In many cases this will give different results, and depending
on the problem at hand, one may be better than the other.

> 
> I still think this is crazy from programmers viewpoint, but I
> understand it's not gcc fault, and it cannot be fixed.

Well, -mno-fused-madd can fix it, but the first rule with floating point 
is to be extremely careful when precision is critical.

In your original case, the final code is probably better: you
now explicitly control when you convert to an integer and avoid 
the conversion of *y1 to double. 

Note that you might still find cases where the results differ between
machines with 53 bit mantissas and 64 mantissas (x87), because the latter
still implies double rounding.

	Gabriel