anti-ranges of signed variables

[Martin Sebor]

On 11/11/2016 12:30 PM, Martin Sebor wrote:
> On 11/11/2016 12:12 PM, Andrew Pinski wrote:
>> On Fri, Nov 11, 2016 at 10:51 AM, Martin Sebor <msebor@gmail.com> wrote:
>>> On 11/11/2016 10:53 AM, Richard Biener wrote:
>>>>
>>>> On November 11, 2016 6:34:37 PM GMT+01:00, Martin Sebor
>>>> <msebor@gmail.com>
>>>> wrote:
>>>>>
>>>>> I noticed that variables of signed integer types that are constrained
>>>>> to a specific subrange of values of the type like so:
>>>>>
>>>>>      [-TYPE_MAX + N, N]
>>>>>
>>>>> are reported by get_range_info as the anti-range
>>>>>
>>>>>      [-TYPE_MAX, TYPE_MIN - 1]
>>>>>
>>>>> for all positive N of the type regardless of the variable's actual
>>>>> range.  Basically, such variables are treated the same as variables
>>>>> of the same type that have no range info associated with them at all
>>>>> (such as function arguments or global variables).
>>>>>
>>>>> For example, while a signed char variable between -1 and 126 is
>>>>> represented by
>>>>>
>>>>>      VR_ANTI_RANGE [127, -2]
>>>>
>>>>
>>>> ? I'd expect [-1, 126].  And certainly never range-min > range-max
>>>
>>>
>>> Okay.  With this code:
>>>
>>>   void f (void *d, const void *s, signed char i)
>>>   {
>>>     if (i < -1 || 126 < i) i = -1;
>>>     __builtin_memcpy (d, s, i);
>>>   }
>>>
>>> I see the following in the output of -fdump-tree-vrp:
>>>
>>>   prephitmp_11: ~[127, 18446744073709551614]
>>
>>
>> prephitmp_11 is an unsigned type as the last argument to memcpy is
>> size_t which is an unsigned type. We had this discussion in bugzilla
>> about this same thing when we were talking about pointer plus.
>
> Right.  But that wasn't my question (the reported range above
> correctly reflects the variable's range in the code).
>
> My question is: why is the range for i in
>
>   if (i < -3 || 124 < i) i = -1;
>
> the same as in
>
>   if (i < -4 || 123 < i) i = -1;
>
> In both cases it's represented as
>
>   prephitmp_12: ~[128, 18446744073709551487]
>
> which is unrelated to i's actual range.  This seems to be true
> for all signed types in the range [-TYPE_MAX + N, N].

There are still very few clients of get_range_info in GCC so it
took me some time to figure out how to demonstrate this effect
in a standalone test case with unmodified GCC.  It finally dawned
on me that I could use Aldy's -Walloca-larger-than to reproduce
it.  I raised bug 78327 with the details.

Martin