PING [PATCH] avoid -Warray-bounds checks for vtable assignments (PR 98266)

[Jason Merrill]

On 2/25/21 6:47 PM, Jeff Law wrote:
> 
> 
> On 2/23/21 2:52 PM, Jason Merrill wrote:
>>
>> I don't see how the issue here depends on the artificiality of the vptr;
> That's what I was trying to get at -- is DECL_ARTIFICIAL really a good
> way to detect these kinds of cases.  It sounds like it likely isn't, but
> it may also be the best we can do.  I'm not sure yet.
> 
> 
> 
> 
>> I'd expect to see the same problem with a data member.  The problem is
>> that a D base subobject is smaller than a complete D object, and in
>> this case the base subobject is allocated such that if it were a full
>> D object, it would overlap the end of E.  And we're checking the
>> MEM_REF as though accessing a full D object, so we get a warning.
>>
>> The general issue about the confusion between complete and as-base
>> types is PR 22488; I have various thoughts about a proper fix, but
>> there have always been higher-priority things to work on.
>>
>> One possible approach to this PR is that we don't need to check an
>> intermediate _REF; in
>>
>> MEM[(struct D *)&D.2651 + 24B]._vptr.D
>>
>> we aren't loading a whole D, we're only looking at the _vptr, which is
>> within the bounds of E.

> That raises a really interesting question.  What's the right bounds to
> use with these kinds of constructs.  Should we be looking at D's type
> (struct E) or struct D?  I'm not sure there's a one-size-fits-all answer
> here and I don't think we have any other context go help guide us.

struct E, definitely; the actual bounds of the struct D object are 
unknown here.  Unless, I suppose, we were to work harder to find the D 
FIELD_DECL in E that corresponds to this offset and get its DECL_SIZE, but:

We know the bounds of the E object, and we can determine that _vptr.D is 
within those bounds; that seems sufficient to decide not to warn.

Jason