On November 11, 2016 6:34:37 PM GMT+01:00, Martin Sebor <[email protected]>
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
>as one would expect, when the same variable is between -4 and 123
>it's represented by
>
> VR_ANTI_RANGE [128, -129]
>
>rather than the expected
>
> VR_ANTI_RANGE [124, -5]
>
>I'd like to know if this is a deliberate feature or a bug.
It must be a misinterpretation on your side. Or an implementation bug.
Richard.
If it's
>a feature, can and should it be relied on for all signed variables?
>Or if it need not always hold, under what conditions, if any, might
>it not hold?
>
>I'm also curious why get_range_info returns VR_ANTI_RANGE for signed
>variables with bounds of opposite signedness, and if it's something
>that can be relied on. I.e., does an anti-range always imply that
>the original variable (before being cast to an unsigned type as
>often happens) is signed and its lower bound is negative?
>
>I've gone through tree-ssa-vrp.[hc] to try to tease out answers to
>these questions from the code but it looks too involved for me to
>be confident that I haven't overlooked something.
>
>Thanks
>Martin
>
>PS I came across this while stepping through the code below in
>the determine_block_size function in builtins.c:
>
> void f (void *d, void *s, signed char n)
> {
> if (n < -4 || 123 < n) return;
> memcpy (d, s, n);
> }
>
>The function tries to estimate the likely maximum block size for
>the memcpy call and determines it to be 127 (i.e., SCHAR_MAX) in
>this case. When the if statement is changed to this:
>
> if (n < -4 || 122 < n) return;
>
>it determines the likely maximum size to be 122 as I would expect.
