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] Fix extract_range_from_cond (PRtree-optimization/19060)


On Wed, 2005-01-05 at 13:56 -0500, Jakub Jelinek wrote:
> On Wed, Jan 05, 2005 at 11:49:45AM -0700, Jeffrey A Law wrote:
> > > value of the second extract_range_from_cond.  I haven't so far managed to
> > > write a testcase that would prove that it is wrong, but I certainly don't
> > > understand how that can be right.
> > 
> > 
> > It works right now because we never record any ranges which need to be
> > inverted.  Thus we "know" that the inverted flag will never be set by
> > the second call to extract_range_cond (for the same reason we can ignore
> > the return value from the second call to extract_range_cond).  It
> > wouldn't hurt to put in a couple asserts.
> 
> Ok.
> 
> > Your change as it stands means we could need the inverted bit on
> > stored ranges and thus I believe could introduce regressions.
> > 
> > We're probably best off doing two things:
> > 
> >   1. Fixing fold so that it handles x < TYPE_MIN_VALUE (TREE_TYPE (x))
> >      (I thought it did that already, so we need to figure out why it
> >       didn't trigger).
> > 
> >   2. For GT TYPE_MAX_VALUE, don't record anything.  Simliarly for
> >      LT TYPE_MIN_VALUE.
> 
> Ok, I'll handle 1. and 2. (plus add assert about dummy == 0).
Can you also assert that the return value is true? 

That would be greatly appreciated.  I'll cover the doc issues.
jeff



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