This is the mail archive of the 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: VR_RANGE with inverted bounds

On October 7, 2016 8:03:34 PM GMT+02:00, Martin Sebor <> wrote:
>On 10/07/2016 11:15 AM, Richard Biener wrote:
>> On October 7, 2016 6:49:39 PM GMT+02:00, Martin Sebor
><> wrote:
>>> 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
>the problem.

Look at -fdump-tree-all-alias dumps, they show the present ranges.  See where they get introduced.



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