On October 7, 2016 8:03:34 PM GMT+02:00, Martin Sebor <mse...@gmail.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 ><mse...@gmail.com> wrote: >>> While processing the (p += i) expression below to validate the >bounds >>> of the pointer in I call get_range_info for i (in >tree-object-size.c). >>> The function returns the following VR_RANGE: [2147483648, >-2147483649] >>> 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. Richard. >Martin
