https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121652
Bug ID: 121652
Summary: round builtin does not raise FE_INVALID for signaling
NaN
Product: gcc
Version: 15.2.1
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rsworktech at outlook dot com
CC: vineetg at gcc dot gnu.org
Target Milestone: ---
Host: riscv64-linux-gnu
Target: riscv64-linux-gnu
Build: riscv64-linux-gnu
The fix for 121534 causes another glibc test to fail:
$ math/test-nearbyint-except
PASS: float
FAIL: float sNaN
PASS: double
FAIL: double sNaN
PASS: long double
PASS: long double sNaN
The test that fails is
/* But it mustn't lose exceptions from sNaN arguments. */ \
if (SNAN_TESTS (FLOAT)) \
{ \
static volatile FLOAT snan = __builtin_nans ## SUFFIX (""); \
volatile FLOAT c __attribute__ ((unused)); \
feclearexcept (FE_ALL_EXCEPT); \
c = nearbyint ## SUFFIX (snan); \
if (fetestexcept (FE_INVALID) == FE_INVALID) \
puts ("PASS: " #FLOAT " sNaN"); \
else \
{ \
puts ("FAIL: " #FLOAT " sNaN"); \
result = 1; \
} \
} \
It appears that gcc's round built-in is used in the place of nearbyint in the
test.
The test expects nearbyint to raise an exception for signaling NaN but previous
fix(r16-3220-gf5696e9b1113b0a8e464cabb8cc26c871b1d9289) unconditionally saves
and restores the fflags thus losing the FE_INVALID exception for sNaN input.
That being said, I am not sure what's the expectation of round built-in.
If it should always save/restore fflags, then the built-in should not be
applied here.
If not, we need a special case for signaling NaN.
