https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122662
Bug ID: 122662
Summary: gcc generates on x86-64 instruction ucomisd/ucomiss
for std::isnan triggering FE_INVALID
Product: gcc
Version: 15.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mohamed.selim at dxc dot com
Target Milestone: ---
gcc generates on x86-64/intel/nehalem the instruction ucomisd/ucomiss for
std::isnan which set FE_INVALID when encountering NaN.
The problem comes when the ucomisd/ucomiss instruction checks a signaling NAN
which in turn triggers float exception FE_INVALID.
> The COMISD instruction signals an invalid operation exception only if a
> source operand is either an SNaN or a QNaN.
https://www.felixcloutier.com/x86/ucomisd
Triggering FE_INVALID in some systems might raise the signal 'SIGFPE', and that
in turn is SOME problem in production/real time systems.
Since, clang is benefiting from its flag "-ffp-exception-behavior=strict", this
problem is totally avoidable on clang x86-64.
With "-ffp-exception-behavior=strict" clang ensures that all transformations
strictly preserve the floating point exception semantics of the original code.
Note: with gcc's experimental flag "-fsignaling-nans", the issues still
persists.
Sample from gcc trunk x86-64
.globl test::is_std_nan(double)
.type test::is_std_nan(double), @function
test::is_std_nan(double):
.LFB3085:
ucomisd xmm0, xmm0
setp al
ret
.LFE3085:
Fuller example that illustrates the problem with comparison to clang:
https://godbolt.org/z/cfhPG16Md
https://godbolt.org/z/7WxMa5a84
