> On Nov 3, 2023, at 10:46 AM, Jakub Jelinek <ja...@redhat.com> wrote:
>
> On Fri, Nov 03, 2023 at 02:32:04PM +0000, Qing Zhao wrote:
>>> Why? It doesn't really matter. The options are
>>> A. p is at &s.b[2] associated with &s.a and int type (or size of int
>>> or whatever); .ACCESS_WITH_SIZE can't be pure,
>>
>> .ACCESS_WITH_SIZE will only load the size from its address, no any write to
>> memory.
>> It still can be PURE, right? (It will not be CONST anymore).
>
> No, it can't be pure. Because for the IL purposes, it needs to be treated
> as if it saves that address of the counter into some unnamed global variable
> somewhere.
Okay. I see.
>>
>>> but sure, for aliasing
>>> POV we can describe it with more detail that it doesn't modify anything
>>> in the pointed structure, just escapes the pointer;
>>
>> If we need to do this, where in the gcc code we need to add these details?
>
> I think ref_maybe_used_by_call_p_1/call_may_clobber_ref_p_1, but Richi is
> expert here.
Just checked these routines, looks like that some other non-pure internal
functions are handled here too.
For example,
case IFN_UBSAN_BOUNDS:
case IFN_UBSAN_VPTR:
case IFN_UBSAN_OBJECT_SIZE:
case IFN_UBSAN_PTR:
case IFN_ASAN_CHECK:
Looks like the correct place to adjust the new .ACCESS_WITH_SIZE.
>
>>> __bdos can stay
>>> leaf I believe;
>>
>> That’s good! (I thought now _bdos will call .ACCESS_WITH_SIZE?)
>
> No, it shouldn't call it obviously. If tree-object-size.cc discovery tracks
> something to a pointer initialized by .ACCESS_WITH_SIZE call, then it should
> I believe recurse on the first argument of that call (say if one has
> ptr_3 = malloc (sz_1);
> ptr_2 = .ACCESS_WITH_SIZE (ptr_3, &ptr_3[4], ...);
> then supposedly __bdos later on should e.g. for 0/1 modes take minimum from
> ptr_3 (the size actually allocated)) and the the counter.
Yes, this is the situation in my mind too.
I thought this might eliminate the LEAF feature from __bdos. -:) if not, that’s
good.
Qing
>
> Jakub
>
