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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
