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: Irix6 long doubles implemented wrong? (27_io/ostream_inserter_arith)


 > From: Alexandre Oliva <aoliva@redhat.com>
 > 
 > On Jan 30, 2003, "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> wrote:
 > 
 > >> From: Richard Henderson <rth@redhat.com>
 > >> > 
 > >> > unordtf2_libfunc
 > >> 
 > >> This one may be a problem.  We don't know what the actual
 > >> return values are for the comparison functions.  By rights
 > >> it ought to be a tri-state value off of EQ or NE.
 > 
 > > I'm not sure what you mean.  Are you saying that all the gcc
 > > comparison functions are tri-state (-1,0,1) or just the unord one?
 > 
 > There is L_compare_[sdt]f, that is tri-state, but none of the others
 > are, it's just that you sometimes can't distinguish unord from false
 > on the others, such as those of gofast.  If there's no equivalent to
 > the tri-state compare on IRIX, just set the corresponding entry in
 > optabs NULL, and GCC will find other ways to implement it, using eq,
 > ne, gt, ge, lt and le.

Sorry, I'm seeing something different.  First looking at fp-bit.c, all
of the comparison ops (e.g. _eq_f2) call __fpcmp_parts which returns a
tri-state value.  I.e. it's not just L_compare_[sdt]f.

Second, looking at prepare_float_lib_cmp in optabs.c if the optabs are
NULL, it'll only swap GE <-> LE and GT <-> LT in both directions.  So
if at least one or the other isn't defined how will it work?

Anyway, I just found FLOAT_LIB_COMPARE_RETURNS_BOOL in tm.texi which,
judging by the name, appears to be exactly what I need. :-)

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu


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