PING [PATCH] avoid -Warray-bounds checks for vtable assignments (PR 98266)
Jason Merrill
jason@redhat.com
Fri Feb 26 03:56:22 GMT 2021
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
More information about the Gcc-patches
mailing list