This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Floating point comparison
Geoff Keating writes:
> > From: Ian Dall <ian@beware.dropbear.id.au>
> > Date: Tue, 3 Dec 2002 23:24:39 +1030
>
> > > The MI code is _not_ allowed to switch between GE and LT unless it
> > > knows that this is safe.
> >
> > So not for ieee float, right?
>
> Right. But, the point I was trying to make is that in your example,
> it didn't switch between GE and LT. Both branches are LT, it's just
> that one of them is reversed. It is your port that is interpreting a
> reversed LT branch as GE, which it shouldn't be doing.
The problem seems to be in jump.c: invert_exp_1(), which has the following
code:
reversed_code = reversed_comparison_code (comp, insn);
if (reversed_code != UNKNOWN)
{
validate_change (insn, &XEXP (x, 0),
gen_rtx_fmt_ee (reversed_code,
GET_MODE (comp), XEXP (comp, 0),
XEXP (comp, 1)),
1);
return;
}
tem = XEXP (x, 1);
validate_change (insn, &XEXP (x, 1), XEXP (x, 2), 1);
validate_change (insn, &XEXP (x, 2), tem, 1);
reversed_code gets set to UNKNOWN (correctly) but the last three
instructions above basically go ahead and make the transformation
anyway, although the changes aren't actually applied until
apply_change_group() sometime later. The name of validate_change() is
a bit misleading. Most of the validating is left until
apply_change_group(), which really only checks that the new
instruction pattern is recognized. It doesn't check modes of
comparison arguments etc.
Ports which always supply a valid reversed comparison code would not
exhibit this bug.
For this port, I think the last three instructions above, should
probably just be removed. This might cause a problem for ports which,
provided a blt but not bge. The alternate is to add code to test the
mode of the comparison arguments such as appears in
reversed_comparison_code_parts.
Another alternative would be to supply REVERSIBLE_CC_MODE and
REVERSE_CONDITION for this port. The problem is, for this particular
case, I don't think a reverse condition exists(*) which preserves ieee
behaviour, so the current behaviour would result.
* Actually this is not strictly true. This FPU traps on NaN's and the
correct behaviour must be emulated. I can change the emulator to
suuport gcc. Possibly I can implement the whole family of "unordered'
comparisons, if I know what they should do. I can't find any
documentation for them.
Ian