BUG: Don't signal FP exceptions in np.absolute

[jcowgill]

Fixes #8686

This PR centers around this piece of code in numpy/core/src/umath/loops.c.src:

UNARY_LOOP {
    const @type@ in1 = *(@type@ *)ip1;
    const @type@ tmp = in1 > 0 ? in1 : -in1;
    /* add 0 to clear -0.0 */
    *((@type@ *)op1) = tmp + 0;
}

If in1 is NaN, the C99 standard requires that the comparison in1 > 0 signals FE_INVALID, but the usual semantics for the absolute function are that no FP exceptions should be generated (eg compare to C fabs and Python abs). This was probably never noticed due to a bug in GCC x86 where all floating point comparisons do not signal exceptions, however Clang on x86 and GCC on other architectures (including ARM and MIPS) do signal an FP exception here.

Fix by rewriting the loop to use npy_fabs instead. Also fix a similar occurrence in simd.inc.src. The test_abs_neg_blocked is adjusted not to ignore FE_INVALID errors because now both absolute and negate should never produce any FP exceptions.

[juliantaylor]

This would have significant performance impact on non x86 as the function is not inlined.
Probably better to just use npy_clear_floatstatus at the end

[juliantaylor]

the change makes sense, but we compile with clang and windows compilers, how come we never saw this outside of mips?

[jcowgill]

This would have significant performance impact on non x86 as the function is not inlined.
Probably better to just use npy_clear_floatstatus at the end

Ah, I didn't check that - I was just testing with plan fabs which GCC does inline. It's frustrating because using fabs on MIPS is about 5x faster than the original code since fabs can be implemented with just one AND instruction.

the change makes sense, but we compile with clang and windows compilers, how come we never saw this outside of mips?

I can reproduce the bug on Clang x86. The test suite was ignoring FP exceptions before which may be why noone saw it.

[jcowgill]

Sorry for the delay - I've updated the PR to use npy_clear_floatstatus.

[juliantaylor]

thanks

[juliantaylor]

@charris while I haven't seen it myself it appears to cause warnings with clang, so it might be worthwhile to still put this into 1.12.1, should be regression safe.

[juliantaylor]

math functions are now inlined (gh-8754) so one could now use npy_fabs for better performance on some arches