[Bug target/52451] gcc w/i387 float generates fucom rather than fcom for floating point comparsons

[vgupta at synopsys dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52451

Vineet Gupta <vgupta at synopsys dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vgupta at synopsys dot com

--- Comment #11 from Vineet Gupta <vgupta at synopsys dot com> ---
ARC gcc backend suffers from this and I've created
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92845 and also a tentative fix
which passes gcc.dg/torture/pr52451.c 

However I'm curious that the test uses qNaN. What is the expected behavior for
sNaN. If you tweak the testcase  slightly as follows:

diff --git a/gcc/testsuite/gcc.dg/torture/pr52451.c
b/gcc/testsuite/gcc.dg/torture/pr52451.c

-  volatile TYPE nan##S = __builtin_nan##S ("");        \
+  volatile TYPE nan##S = __builtin_nans##S ("");       \

With that even on ARM (RPI3) it now fails for the "quite" C operations "==" and
"!=" and isless(),isgreater(),islessequal(),isgreaterequal().

Is that expected, OK ? I guess there's no easy to fix this unless hardware
supports the 3 varaints or glibc code has a way to clear exception in certain
cases.