floating point comparison is incorrect

[GoogleCodeExporter]

If you compile the source code below with the sx-gcc compiler and execute
it, the function aborts:

{{

extern void abort (void);

int main()
{

  float a = 1.0;
  if (a + a == a) {
    abort ();
  }

  return 0;
}

}}

I have checked the assembler code that is generated from the source code 
above and it looks like the problem lies in the "bnef" instruction
(see the block below):

    fad@    $s36,$s35,$s35
    ldu $s35,272(,$s1)
    fcp@    $s35,$s36,$s35
    bnef@   $s35,.L4
    be> 0,.L2
.L4:
    lds $s35,.LC2   #movdi case3
    lea $s36,0
    sts $s36,-280(,$s2)
    lea $s34,-280(,$s2)
    or  $s33,0,$s35
    bsic    $s32,($s33)
.L2:
    or  $s35,0,(0)1
    or  $s123,0,$s35

We van see that the body of the "if" clause (i.e. the block which starts
with label ".L4") is executed if "a + a != a", which is the exact opposite
of the condition we specified in the "if" statement.

The same problem also occurs if we are using other comparison operators
(e.g. !=, >=, ...):

{{

int main()
{
  float a = 1.0;
  if (a != a) {
    abort ();
  }
}

}}

Original issue reported on code.google.com by nou...@gmail.com on 12 Nov 2008 at 1:26

[GoogleCodeExporter]

I think SX has inverted comparison results wrt. what gcc expects. I think erich 
fixed
this, but obviously just for integer comparisons, so he should be able to tell 
you
how to fix this in no time.

Original comment by jmoc...@gmail.com on 12 Nov 2008 at 1:33

[GoogleCodeExporter]

testcase gcc.c-torture/execute/builtins/complex-1.c fails due to this as well.

Original comment by jmoc...@gmail.com on 17 Nov 2008 at 9:47

[GoogleCodeExporter]

reversed conditionals for FP in sx.md. should work now with r125.

Original comment by jmoc...@gmail.com on 17 Nov 2008 at 10:00

• Changed state: Fixed

[GoogleCodeExporter]

Inverting the comparison wasn't quite the right fix, the problem was bad code in
sx.c. The comparison was generated properly, but the branching code (*code) 
could be
either EQ or NE, and nothing else. Should be fixed in svn r127. But needs to go
through the testloop to really see if there aren't any regressions.

Original comment by efo...@gmail.com on 17 Nov 2008 at 12:20