Am Freitag, dem 11.04.2025 um 10:42 -0400 schrieb Andrew MacLeod:
> On 4/11/25 10:27, Qing Zhao wrote:
> >
> > > On Apr 10, 2025, at 11:12, Martin Uecker <[email protected]> wrote:
> > >
> > > Am Donnerstag, dem 10.04.2025 um 10:55 -0400 schrieb Siddhesh Poyarekar:
> > > > On 2025-04-10 10:50, Andrew MacLeod wrote:
> > > > > Its not clear to me exactly what is being asked, but I think the
> > > > > suggestion is that pointer references are being replaced with a
> > > > > builtin
> > > > > function called .ACCESS_WITH_SIZE ? and I presume that builtin
> > > > > function has some parameters that give you relevant range information
> > > > > of
> > > > > some sort?
> > > > Added, not replaced, but yes, that's essentially it.
> > > >
> > > > > range-ops is setup to pull range information from builtin functions
> > > > > already in gimple-range-op.cc::
> > > > > gimple_range_op_handler::maybe_builtin_call (). We'd just need to
> > > > > write
> > > > > a handler for this new one. You can pull information from 2 operands
> > > > > under normal circumstances, but exceptions can be made. I'd need a
> > > > > description of what it looks like and how that translates to range
> > > > > info.
> > > > That's perfect! It's probably redundant for cases where we end up with
> > > > both .ACCESS_WITH_SIZE and a __bos/__bdos call, but I don't remember if
> > > > that's the only place where .ACCESS_WITH_SIZE is generated today. Qing,
> > > > could you please work with Andrew on this?
> > > BTW, what I would find very interesting is inserting such information
> > > at the points where arrays decay to pointer.
> > Is the following the example?
> >
> > 1 #include <stdio.h>
> > 2
> > 3 void foo (int arr[]) {
> > 4 // Inside the function, arr is treated as a pointer
> > 5 arr[6] = 10;
> > 6 }
> > 7
> > 8 int my_array[5] = {10, 20, 30, 40, 50};
> > 9
> > 10 int main() {
> > 11 my_array[6] = 6;
> > 12 int *ptr = my_array; // Array decays to pointer here
> > 13 ptr[7] = 7;
> > 14 foo (my_array);
> > 15 16 return 0;
> > 17 }
> >
> > When I use the latest gcc to compile the above with -Warray-bounds:
> >
> > []$ gcc -O2 -Warray-bounds t.c
> > t.c: In function ‘main’:
> > t.c:13:6: warning: array subscript 7 is outside array bounds of ‘int[5]’
> > [-Warray-bounds=]
> > 13 | ptr[7] = 7;
> > | ~~~^~~
> > t.c:8:5: note: at offset 28 into object ‘my_array’ of size 20
> > 8 | int my_array[5] = {10, 20, 30, 40, 50};
> > | ^~~~~~~~
> > In function ‘foo’,
> > inlined from ‘main’ at t.c:14:3:
> > t.c:5:10: warning: array subscript 6 is outside array bounds of ‘int[5]’
> > [-Warray-bounds=]
> > 5 | arr[6] = 10;
> > | ~~~~~~~^~~~
> > t.c: In function ‘main’:
> > t.c:8:5: note: at offset 24 into object ‘my_array’ of size 20
> > 8 | int my_array[5] = {10, 20, 30, 40, 50};
> > | ^~~~~~~~
> >
> > Looks like that even after the array decay to pointer, the bound
> > information is still carried
> > for the decayed pointer somehow (I guess that vrp did this?)
>
> No, the behaviour in these warnings is from something else. Although
> some range info from VRP is used, most of this is tracked by the
> pointer_query (pointer-query.cc) mechanism that was written a number of
> years ago before ranger was completed. It attempts to do its own custom
> tracking of pointers and what they point to and the size of things they
> access.
>
> There are issues with that code, and the goal is to replace it with
> rangers prange. Alas there is enhancement work to prange for that to
> happen as it doesnt currently track and points to info. That would then
> be followed by converting the warning code to then use ranger/VRP instead.
>
> Any any adjustments to ranger for this are unlikely to affect anything
> until that work is done, and I do not think anyone is equipped to
> attempt to update the existing pointer-query code.
>
> Unfortunately :-(
Examples I have in mind for the .ACCESS_WITH_SIZE are the
following two:
struct foo {
char arr[3];
int b;
};
void f(struct foo x)
{
char *ptr = x.arr;
ptr[4] = 10;
}
void g(char (*arr)[4])
{
char *ptr = *arr;
ptr[4] = 1;
}
Martin
