https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102101
Martin Sebor <msebor at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks| |56456
Summary|Another spurious |spurious -Warray-bounds on
|-Warray-bounds |a virtual function call and
| |a derived class
Ever confirmed|0 |1
Keywords| |diagnostic
Last reconfirmed| |2021-08-27
Status|UNCONFIRMED |NEW
See Also| |https://gcc.gnu.org/bugzill
| |a/show_bug.cgi?id=101600
Component|c++ |middle-end
--- Comment #1 from Martin Sebor <msebor at gcc dot gnu.org> ---
The warning is working as designed in this case (as opposed to pr101600) but
the design has its shortcomings. It complains about the negative offset from
the D.25604.D.25576 subobject in this:
MEM[(struct FillHatchPrimitive2D *)_150].D.25604.D.25576
in the IL below. Only accesses within the bounds of each subobject are
considered valid. But here, the negative offset has to do with getting at the
virtual table in struct XInterface but that code is transformed into the
invalid-looking MEM_REF. I'm not sure how to handle this yet. It's in the
same class as the other "representational" problems where downstream warnings
assume the IL corresponds to the source and where prior transformations result
in something that's indistinguishable from a bug. The warnings also don't
understand C++ very well and that makes the "naive subobject logic" more
susceptible to false positives in these cases.
<L123>:
_150 = rtl_allocateMemory ();
FillHatchPrimitive2D::FillHatchPrimitive2D (_150);
<bb 106> [local count: 916872327]:
if (_150 != 0B)
goto <bb 109>; [70.00%]
else
goto <bb 107>; [30.00%]
<bb 107> [local count: 275061695]:
# iftmp.34_242 = PHI <0B(106)>
if (iftmp.34_242 != 0B)
goto <bb 110>; [70.00%]
else
goto <bb 108>; [30.00%]
<bb 108> [local count: 82518508]:
goto <bb 112>; [100.00%]
<bb 109> [local count: 641810632]:
iftmp.34_119 = &MEM[(struct FillHatchPrimitive2D *)_150].D.25604.D.25576;
<bb 110> [local count: 834353819]:
# iftmp.34_203 = PHI <iftmp.34_119(109), iftmp.34_242(107)>
_218 = &MEM[(struct PartialWeakComponentImplHelper *)iftmp.34_203 +
-8B].D.25575; <<< -Warray-bounds
WeakComponentImplHelperBase::acquire (_218);
<<< virtual call
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
[Bug 56456] [meta-bug] bogus/missing -Warray-bounds
