This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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
function calls.

Roger
--


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]