I wrote:
> Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
>> Do we care to do anything about this? Pick slightly different test data
>> perhaps?
> Picking different test data might be a good "fix". Alternatively, we
> could try to figure out where the discrepancy is arising and adjust
> the code --- but that might be a lot more work than it's worth.
I poked at this a bit more. I can reproduce the problem by using
-mfpmath=387 on dromedary's host (fairly old 32-bit macOS); although
I also get half a dozen *other* failures in the core regression tests,
mostly around detection of float overflow. So I'm not quite sure that
this is comparable. But at any rate, I tracked the core of the problem
to pg_hypot:
/* Determine the hypotenuse */
yx = y / x;
result = x * sqrt(1.0 + (yx * yx));
With -mfpmath=387, these calculations are done to more-than-64-bit
precision, yielding a different end result --- note in particular
that sqrt() is a hardware instruction on this platform, so it's
not rounding either.
I experimented with preventing that by using volatile intermediate
variables (cf comments in float.c); but it seemed like a mess,
and it would likely pessimize the code more than we want for other
platforms, and it's kind of hard to argue that deliberately sabotaging
the more-accurate computation is an improvement.
What I suggest doing is reducing extra_float_digits to -1 for this
specific test. Changing the contents of circle_tbl seems like it'd have
more consequences than we want, in particular there's no guarantee that
we'd not hit similar issues in other tests if they're given different
inputs.
regards, tom lane
