This is the mail archive of the
mailing list for the GCC project.
Re: VR_RANGE with inverted bounds
On October 7, 2016 8:03:34 PM GMT+02:00, Martin Sebor <email@example.com> wrote:
>On 10/07/2016 11:15 AM, Richard Biener wrote:
>> On October 7, 2016 6:49:39 PM GMT+02:00, Martin Sebor
>>> While processing the (p += i) expression below to validate the
>>> of the pointer in I call get_range_info for i (in
>>> The function returns the following VR_RANGE: [2147483648,
>>> rather than the expected [0, 1]. Is such a range to be expected or
>>> is it a bug?
>> This range is not valid (unless unsigned and you show it as signed).
>Thanks. I believe it's signed but even if it was unsigned it wouldn't
>be correct (correspond to the actual range of [0, 1]).
>I don't have a test case that makes this manifest with an unpatched
>compiler. There aren't too many places that call get_range_info
>and the range only appears to be wrong between the second and third
>runs of the object-size pass. After the third run the range is
>correct. (I can see this with the -Wformat-length warning when
>I pass the variable to sprintf and trigger a warning.)
>Unless you have a suggestion for how I might be able to reproduce
>it I'll go ahead and open a bug and include a minimum patch to show
Look at -fdump-tree-all-alias dumps, they show the present ranges. See where they get introduced.