On 2/8/21 3:26 PM, Jeff Law wrote:
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?
I think the underlying problem is the same. We're getting a size
that doesn't correspond to what's actually being accessed, and it
happens because of the virtual inheritance. In pr97595 Jason
suggested to use the decl/type size inequality to identify this
case but I think we could have just as well used DECL_ARTIFICIAL
instead. At least the test cases from pr97595 both pass with
this change.
Martin
Jeff