Comment # 5 on bug 1030250 from Michael Matz

(In reply to Adam Majer from comment #4)
> > [  209s] FAIL: schmidt csphase=1 deriv2 i=102 (-1.42436215874661529e-16 observed vs -1.42460074537287091e-16 expected) [9186711]
> 
> The expected deviance is <1e-10 for relative error and this is closer to 1e-4
> 
> Since GSL didn't change its code, there must be some change in GCC floating
> point optimization?
> 
> Also, disabling optimization causes tests to fail in some other case :/
> 
> Michael, Richard, do you have any clues as to what changed in GCC that could
> result in this? There are no problems with any tests on x86_64. Disabling
> optimization causes failures in other tests due to error accumulation.

GCC 7 probably simply emits a bit different code from 6.3.1, less or more
spilling leading to different rounding behaviour from the x87 fp code that
is generated by default (internally it has excess precision, when stored
somewhere it get's rounded.  Storing for spilling purposes hence introduces
rounding, and not storing for spilling because better register allocation
leads to less rounding.  Typical problem in x87 code.).

That disabling optimization leads to testsuite errors as well indicates that
the algorithmic implementation in gsl isn't very good in taking floating point
arithmetic into account, or that the testcases aren't carefully made to avoid
catastrophic cancellation (i.e. that they use borderline numbers that lead to
to
cancellation somewhere).  An abs error of 1e-16 seems to support that, it's
very small, at around the border from normalized to unnormalized numbers for
the float datatype.  So there's always precision loss at that range, meaning
that
relative errors between two such numbers is larger than is normally computed
with methods that don't take finite fp precision into account.

So, the gsl testsuite pushes the limits of fp precision, and different code
generation can lead to slightly different results in intermediate calculations
for x87 code.

Either adding -mfpmath=sse or -ffloat-store would avoid the dependence on 
spilling code gen.  The former impacts performance less than the latter (using
the SSE unit, vs. always rounding after each computation), but the code then
only runs on CPUs having a SSE unit.  Fixing the testsuite would be better,
or perhaps simply disabling the testsuite on i586.