numerology_1.out and float8-small-is-zero_1.out differ from their base files only in showing plain zero rather than minus zero for some results. I believe that in the wake of commit 6eb3eb577, we will print minus zero as such on all IEEE-float platforms (and non-IEEE floats are going to cause many more regression diffs than this, anyway). Hence we should be able to remove these and eliminate a bit of maintenance pain. Let's see if the buildfarm agrees. Discussion: https://postgr.es/m/29037.1539021687@sss.pgh.pa.us
Buildfarm results show that the modern POSIX rule that 1 ^ NaN = 1 is not honored on *BSD until relatively recently, and really old platforms don't believe that NaN ^ 0 = 1 either. (This is unsurprising, perhaps, since SUSv2 doesn't require either behavior.) In hopes of getting to platform independent behavior, let's deal with all the NaN-input cases explicitly in dpow(). Note that numeric_power() doesn't know either of these special cases. But since that behavior is platform-independent, I think it should be addressed separately, and probably not back-patched. Discussion: https://postgr.es/m/75DB81BEEA95B445AE6D576A0A5C9E936A73E741@BPXM05GP.gisp.nec.co.jp
Per spec, the result of power() should be NaN if either input is NaN. It appears that on some versions of Windows, the libc function does return NaN, but it also sets errno = EDOM, confusing our code that attempts to work around shortcomings of other platforms. Hence, add guard tests to avoid substituting a wrong result for the right one. It's been like this for a long time (and the odd behavior only appears in older MSVC releases, too) so back-patch to all supported branches. Dang Minh Huong, reviewed by David Rowley Discussion: https://postgr.es/m/75DB81BEEA95B445AE6D576A0A5C9E936A73E741@BPXM05GP.gisp.nec.co.jp
Print the actual value of each function result that's expected to be exact, rather than merely emitting a NULL if it's not right. Although we print these with extra_float_digits = 3, we should not trust that the platform will produce a result visibly different from the expected value if it's off only in the last place; hence, also include comparisons against the exact values as before. This is a bit bulkier and uglier than the previous printout, but it will provide more information and be easier to interpret if there's a test failure. Discussion: <18241.1461073100@sss.pgh.pa.us>
The buildfarm isn't very happy with the results of commit e1bd684a34c11139. To try to get the expected exact results everywhere: * Replace M_PI / 180 subexpressions with a precomputed constant, so that the compiler can't decide to rearrange that division with an adjacent operation. Hopefully this will fix failures to get exactly 0.5 from sind(30) and cosd(60). * Add scaling to ensure that tand(45) and cotd(45) give exactly 1; there was nothing particularly guaranteeing that before. * Replace minus zero by zero when tand() or cotd() would output that; many machines did so for tand(180) and cotd(270), but not all. We could alternatively deem both results valid, but that doesn't seem likely to be what users will want.
The implementations go to some lengths to deliver exact results for values where an exact result can be expected, such as sind(30) = 0.5 exactly. Dean Rasheed, reviewed by Michael Paquier
This reverts commit 500cf66d5522b39ddfdc26b309f8b5b0e385f42e. As was more or less expected, a small minority of platforms won't accept denormalized input even with the recent changes. It doesn't seem especially helpful to test this if we're going to have to provide an alternate expected-file to allow failure.
This was submitted with the previous patch, but I'm committing it separately to ease backing it out if these results prove too unportable. Marti Raudsepp, after a proposal by Jeroen Vermeulen
This wasn't important when we used diff's -w (--ignore-all-space) option to compare regression result files, but it is now. Per buildfarm member canary, which evidently has been offline since we did that in November, but came to life again today.