[PATCH] use zero as the lower bound for a signed-unsigned range (PR 79327)

Jakub Jelinek jakub@redhat.com
Tue Feb 14 13:57:00 GMT 2017


On Tue, Feb 14, 2017 at 08:18:13AM +0100, Jakub Jelinek wrote:
> On Mon, Feb 13, 2017 at 04:53:19PM -0700, Jeff Law wrote:
> > > dirtype is one of the standard {un,}signed {char,short,int,long,long long}
> > > types, all of them have 0 in their ranges.
> > > For VR_RANGE we almost always set res.knownrange to true:
> > >           /* Set KNOWNRANGE if the argument is in a known subrange
> > >              of the directive's type (KNOWNRANGE may be reset below).  */
> > >           res.knownrange
> > >             = (!tree_int_cst_equal (TYPE_MIN_VALUE (dirtype), argmin)
> > >                || !tree_int_cst_equal (TYPE_MAX_VALUE (dirtype), argmax));
> > > (the exception is in case that range clearly has to include zero),
> > > and reset it only if adjust_range_for_overflow returned true, which means
> > > it also set the range to TYPE_M{IN,AX}_VALUE (dirtype) and again
> > > includes zero.
> > > So IMNSHO likely_adjust in what you've committed is always true
> > > when you use it and thus just a useless computation and something to make
> > > the code harder to understand.
> > If KNOWNRANGE is false, then LIKELY_ADJUST will be true.  But I don't see
> > how we can determine anything for LIKELY_ADJUST if KNOWNRANGE is true.
> 
> We can't, but that doesn't matter, we only use it if KNOWNRANGE is false.
> The only user of LIKELY_ADJUST is:
>  
>   if (res.knownrange)
>     res.range.likely = res.range.max;
>   else
>     {
> // -- Here we know res.knownrage is false
>       res.range.likely = res.range.min;
>       if (likely_adjust && maybebase && base != 10)
> // -- and here is the only user of likely_adjust
>         {
>           if (res.range.min == 1)
>             res.range.likely += base == 8 ? 1 : 2;
>           else if (res.range.min == 2
>                    && base == 16
>                    && (dir.width[0] == 2 || dir.prec[0] == 2))
>             ++res.range.likely;
>         }
>     }

Another argument I had was that if maybebase and base != 10, then
if the range does not include zero (if it ever could be !res.knownrange
in that case), then res.range.min won't be 1 and for base 16 won't be
even 2, because all the values in the range will include the 0 or 0x prefixes.
The only controversion then would be if the range was [0, 0], then
bumping res.range.likely would not be appropriate.  But such range is
really res.knownrange and never anything else.

	Jakub



More information about the Gcc-patches mailing list