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

--- Comment #20 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to jos...@codesourcery.com from comment #16)
> I don't think this bug is anything to do with -fsignaling-nans, for the 
> same reason as applies to bug 58416 and bug 71460.

The situation is hopeless from the beginning. Please consider this testcase:

--cut here--
#include <cpuid.h>
#include <fenv.h>

double
__attribute__((noinline,noipa))
foo (double a, double b, char c)
{
  return c ? a : b;
}

int main ()
{
  double a = __builtin_nans ("");
  double b = 42.0;

  feclearexcept (FE_INVALID);
  foo (a, b, 0);
  if (fetestexcept (FE_INVALID))
    __builtin_abort ();

  return 0;
}
--cut here--

$ gcc -O2 -m32 -march=i686 -lm fcmov.c
$ ./a.out 
Aborted (core dumped)
$ gcc -O2 -m32 -march=i386 -lm fcmov.c
$ ./a.out 
Aborted (core dumped)

Because the compiler generates:

foo:
        cmpb    $0, 20(%esp)
        fldl    12(%esp)
        fldl    4(%esp)
        fcmove  %st(1), %st
        fstp    %st(1)
        ret

in the former case and:

foo:
        fldl    4(%esp)
        fldl    12(%esp)
        cmpb    $0, 20(%esp)
        jne     .L4
        fstp    %st(1)
        jmp     .L2
.L4:
        fstp    %st(0)
.L2:
        ret

in the later.

Since the ABI specifies the operand size on the stack, the above code will
always trap.

Reply via email to