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: patch to fix rtl documentation for new floating point comparisons


On Mon, 9 Feb 2015, Kenneth Zadeck wrote:

> > I don't think it's useful to have the trapping semantics unspecified for a
> > comparison operation like that.  So the question is what's most useful for
> > LTGT and LTGT_EXPR to do (presumably they should do the same thing).  Lots
> > of existing code in this area seems confused (for example, HONOR_SNANS
> > should be irrelevant to reversing an equality comparison, as reversing it
> > will change neither results nor exceptions raised, whether or not
> > signaling NaNs are involved).  But maybe more code treats LTGT as a
> > signaling operation than otherwise, in accordance with the original
> > intent, and so that's the most appropriate way to document it (with !UNEQ
> > being the representation of the corresponding quiet operation).
> section 7.12.14.4 in C99 seems pretty much to say that this is a quiet
> operation.

It says islessgreater is quiet.  It says nothing about the LTGT RTL 
operation or the LTGT_EXPR GIMPLE/GENERIC operation.  
__builtin_islessgreater is implemented using UNEQ_EXPR not LTGT_EXPR.

It may make sense to define LTGT as exactly !UNEQ, and so quiet, but the 
choice of definition is a matter of what's convenient for the 
implementation (and which choice you make determines which existing code 
in GCC should be considered incorrect).

Where back ends implement ltgt patterns, I don't know if they are 
consistently quiet or signaling.

-- 
Joseph S. Myers
joseph@codesourcery.com


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