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