[Bug target/52451] gcc w/i387 float generates fucom rather than fcom for floating point comparsons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52451 --- Comment #13 from joseph at codesourcery dot com --- On Fri, 6 Dec 2019, vgupta at synopsys dot com wrote: > However I'm curious that the test uses qNaN. What is the expected behavior for > sNaN. If you tweak the testcase slightly as follows: All the comparison operations raise exceptions for sNaN. See IEEE 754. "Invalid operation is the only exception that a comparison predicate can signal. All predicates signal the invalid operation exception on signaling NaN operands. The predicates named Quiet shall not signal any exception, unless an operand is a signaling NaN. The predicates named Signaling shall signal the invalid operation exception on quiet NaN operands.".
[Bug target/52451] gcc w/i387 float generates fucom rather than fcom for floating point comparsons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52451 --- Comment #12 from Vineet Gupta --- oops the ARC bug is (PR 92846) not (PR 92845)
[Bug target/52451] gcc w/i387 float generates fucom rather than fcom for floating point comparsons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52451
Vineet Gupta changed:
What|Removed |Added
CC||vgupta at synopsys dot com
--- Comment #11 from Vineet Gupta ---
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.
[Bug target/52451] gcc w/i387 float generates fucom rather than fcom for floating point comparsons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52451 --- Comment #10 from joseph at codesourcery dot com --- Please file a separate bug for hppa, just as we have separate bugs for the powerpc and s390 back end issues. Assuming hppa-hpux has working fenv.h, failure on hppa is probably a back-end issue.
[Bug target/52451] gcc w/i387 float generates fucom rather than fcom for floating point comparsons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52451 John David Anglin changed: What|Removed |Added CC||danglin at gcc dot gnu.org --- Comment #9 from John David Anglin --- Test fails on hppa*-*-hpux*.
[Bug target/52451] gcc w/i387 float generates fucom rather than fcom for floating point comparsons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52451 --- Comment #8 from Uroš Bizjak --- (In reply to seurer from comment #7) > Shouldn't the new test case have been marked XFAIL for powerpc64 and s390? > It fails on powerpc64 for sure. This is up to target maintainer. XFAIL will get the problem off the radar for the next 10 years or so ... OTOH, the fix should be the same as for x86 - relatively straightforward introduction of CCFPU mode with a helper function that selects between CCFP and CCFPU mode depending on comparison code.
[Bug target/52451] gcc w/i387 float generates fucom rather than fcom for floating point comparsons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52451 seurer at gcc dot gnu.org changed: What|Removed |Added CC||seurer at gcc dot gnu.org --- Comment #7 from seurer at gcc dot gnu.org --- Shouldn't the new test case have been marked XFAIL for powerpc64 and s390? It fails on powerpc64 for sure.
[Bug target/52451] gcc w/i387 float generates fucom rather than fcom for floating point comparsons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52451 Uroš Bizjak changed: What|Removed |Added Target||x86 Status|WAITING |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com Target Milestone|--- |8.0 --- Comment #6 from Uroš Bizjak --- Fixed on x86. For reference, the testcase will fail on powerpc (PR 58684) and s390 (PR 77918).
[Bug target/52451] gcc w/i387 float generates fucom rather than fcom for floating point comparsons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52451 --- Comment #5 from uros at gcc dot gnu.org --- Author: uros Date: Sun Oct 22 19:04:36 2017 New Revision: 253986 URL: https://gcc.gnu.org/viewcvs?rev=253986=gcc=rev Log: PR target/52451 * config/i386/i386.c (ix86_fp_compare_mode): Return CCFPmode for ordered inequality comparisons even with TARGET_IEEE_FP. testsuite/ChangeLog: PR target/52451 * gcc.dg/torture/pr52451.c: New test. Added: trunk/gcc/testsuite/gcc.dg/torture/pr52451.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug target/52451] gcc w/i387 float generates fucom rather than fcom for floating point comparsons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52451
Szabolcs Nagy nszabolcs at gmail dot com changed:
What|Removed |Added
CC||nszabolcs at gmail dot com
--- Comment #4 from Szabolcs Nagy nszabolcs at gmail dot com ---
this bug is still present in gcc-4.9 on i386 and x86_64 targets
and possibly others (clang is broken too but that's another story)
the ieee-754 and thus iso c99/c11 + annex f, requires that
==, != are quiet (never raise any exception)
, , =, = are signaling (raise invalid if an operand is nan)
eg. with
int f(float x, float y)
{
return x y;
}
int g(float x, float y)
{
return x == y;
}
on x87 (i386):
fcom* should be used for f (signaling)
fucom* should be used for g (quiet)
with sse2 (x86_64):
comis* should be used for f (signaling)
ucomis* should be used for g (quiet)
(on arm it is vcmpe.f32 vs vcmp.f32)
it is easy to check that gcc always emits quiet comparisions
and with -mno-ieee-fp it always emits signaling ones
(both of them are wrong)
-O2 -std=c99 on x86_64:
http://goo.gl/awmRGP
-O2 -std=c99 -mno-ieee-fp on x86_64:
http://goo.gl/9CHNjK
[Bug target/52451] gcc w/i387 float generates fucom rather than fcom for floating point comparsons
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52451 --- Comment #3 from Rich Felker bugdal at aerifal dot cx 2012-04-23 09:37:45 UTC --- Compiling with the -mno-ieee-fp option fixes this bug. It seems like the behavior of this option is reversed from the documentation; -mno-ieee-fp gives IEEE conformant comparisons (raising exception on unordered) and -mieee-fp gives non-conformant comparisons (silent on unordered)...
[Bug target/52451] gcc w/i387 float generates fucom rather than fcom for floating point comparsons
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52451 --- Comment #2 from Rich Felker bugdal at aerifal dot cx 2012-03-15 16:23:11 UTC --- Try foo(NAN,NAN) and then check for the INVALID exception. It's not set.
