On 2/8/21 2:56 PM, Martin Sebor wrote:
> On 2/8/21 12:59 PM, Jeff Law wrote:
>>
>>
>> On 1/19/21 5:56 PM, Martin Sebor via Gcc-patches wrote:
>>> Similar to the problem reported for -Wstringop-overflow in pr98266
>>> and already fixed, -Warray-bounds is also susceptible to false
>>> positives in assignments and copies involving virtual inheritance.
>>> Because the two warnings don't share code yet (hopefully in GCC 12)
>>> the attached patch adds its own workaround for this problem to
>>> gimple-array-bounds.cc, this one slightly more crude because of
>>> the limited insight the array bounds checking has into the checked
>>> expressions.
>>>
>>> Tested on x86_64-linux.
>>>
>>> Martin
>>>
>>> gcc-98266.diff
>>>
>>> PR middle-end/98266 - bogus array subscript is partly outside array
>>> bounds on virtual inheritance
>>>
>>> gcc/ChangeLog:
>>>
>>> PR middle-end/98266
>>> * gimple-array-bounds.cc
>>> (array_bounds_checker::check_array_bounds):
>>> Avoid checking references involving artificial members.
>>>
>>> gcc/testsuite/ChangeLog:
>>>
>>> PR middle-end/98266
>>> * g++.dg/warn/Warray-bounds-15.C: New test.
>> It seems to me that we've got the full statement at some point and thus
>> the full expression so at some point couldn't we detect when
>> TYPE_SIZE_UNIT!= DECL_SIZE_UNIT? Or should we be using TYPE_SIZE_UNIT
>> rather than DECL_SIZE_UNIT in gimple-array-bounds.cc
>>
>> Am I missing something?
>
> The expression we're looking at when the false positive is issued
> is the MEM_REF in the LHS of:
>
> MEM[(struct D *)&D.2652 + 24B]._vptr.D = &MEM <int (*) ()> [(void
> *)&_ZTC1E24_1D + 24B];
>
> TREE_TYPE(LHS) is D, DECL_SIZE_UNIT (D.2652) is 24, and
> TYPE_SIZE_UNIT(D) is also 24, so there's no discrepancy between
> DECL_SIZE and TYPE_SIZE.
So that seems like it's a different issue then, unrelated to 97595. Right?
Jeff
