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

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

[bugdal at aerifal dot cx]

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

             Bug #: 52451
           Summary: gcc w/i387 float generates fucom rather than fcom for
                    floating point comparsons
    Classification: Unclassified
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: bugdal@aerifal.cx


The C comparison operators (as opposed to the isgreater, etc. macros) are
specified to correspond to the IEEE "unordered-signaling predicates" which
raise the INVALID exception on comparisons involving a NaN (quiet or
signaling). However, gcc on x86 is generating the FUCOM opcode rather than
FCOM, which does not raise any exception unless it encounters a signaling NaN.

Apparently this is a regression since ancient versions of gcc, which correctly
generated FCOM.

This bug report is i387-specific; I have no idea if the same issue applies with
SSE math or non-x86-family cpu archs.

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

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2012-03-01
     Ever Confirmed|0                           |1

--- Comment #1 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-03-01 15:55:37 UTC ---
Please provide a testcase and specify the GCC version you are using.

Works for me with

int foo (double x, double y)
{
  return x < y;
}

and GCC 4.6.2.

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

[bugdal at aerifal dot cx]

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.

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

[bugdal at aerifal dot cx]

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

[nszabolcs at gmail dot com]

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