This is the mail archive of the
mailing list for the GCC project.
Re: [RFC] Fold floating-point comparisons
- From: Roger Sayle <roger at eyesopen dot com>
- To: Paolo Bonzini <bonzini at gnu dot org>
- Cc: gcc-patches at gcc dot gnu dot org, Richard Henderson <rth at redhat dot com>
- Date: Fri, 28 May 2004 08:05:09 -0600 (MDT)
- Subject: Re: [RFC] Fold floating-point comparisons
On Fri, 28 May 2004, Paolo Bonzini wrote:
> > This is the direct benefit to a programmer of writing internal
> > documentation. The person that writes the documentation gets to
> > define the semantics. In this case, we get to choose that LTGT
> > shouldn't trap :>
> Nope, rth as expected knew better than both of us! :-) I also thought
> that LTGT wouldn't trap.
This lack of RTL documentation and conflicting beliefs in behaviour
creates real problems. For example, the C99 standard requires that
isunordered, isgreater, isgreaterequal etc... explicitly don't trap.
However, rtlanal.c's may_trap_p reveals that at the RTL level all of
the corresponding RTL codes (UNORDERED, UNLE, UNLT etc..) are currently
implemented assuming that they do trap.
Documenting the intended behaviour of these RTL codes would resolve
where the bug lies. Either the C99 unordered comparisons can't be
implemented using these RTL codes, or on backends whose unordered
comparisons trap, those instructions can't be used to implement GCC's
corresponding RTL codes. At the very least ORDERED and UNORDERED
need to be documented/implemented as not trapping, otherwise we can't
even use the fallback implementations in dojump.c to implement the
C99-compliant comparisons, and instead we must always use libgcc