From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 432AC383D80D; Wed, 25 May 2022 08:39:50 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 432AC383D80D From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/105726] spurious warning with -Warray-bounds Date: Wed, 25 May 2022 08:39:50 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 13.0 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2022 08:39:50 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D105726 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |msebor at gcc dot gnu.org --- Comment #2 from Richard Biener --- Oh, my - this is mightly complicated code. We get to void builtin_memref::set_base_and_offset (tree expr) { ... if (TREE_CODE (base) =3D=3D MEM_REF) { tree memrefoff =3D fold_convert (ptrdiff_type_node, TREE_OPERAND (bas= e, 1)); extend_offset_range (memrefoff); base =3D TREE_OPERAND (base, 0); if (refoff !=3D HOST_WIDE_INT_MIN && TREE_CODE (expr) =3D=3D COMPONENT_REF) { /* Bump up the offset of the referenced subobject to reflect the offset to the enclosing object. For example, so that in struct S { char a, b[3]; } s[2]; strcpy (s[1].b, "1234"); REFOFF is set to s[1].b - (char*)s. */ offset_int off =3D tree_to_shwi (memrefoff); refoff +=3D off; } which looks somewhat suspicious and then tree=20 builtin_memref::offset_out_of_bounds (int strict, offset_int ooboff[3]) con= st { ... /* When the referenced subobject is known, the end offset must be within its bounds. Otherwise there is nothing to do. */ if (strict && !decl_p && ref && refsize >=3D 0 && TREE_CODE (ref) =3D=3D COMPONENT_REF) { /* If REFOFF is negative, SIZE will become negative here. */ size =3D refoff + refsize; obj =3D ref; triggers with ref being a COMPONENT_REF to the array, refoff being 4 (from = the MEM_REF) and refsize =3D=3D 0. The idea is probably that the '4' is for the pointer adjustment (base is &aMessage here), but then the object shouldn't be 'ref'? But I'm confused by all the complexity and the abstraction and I'm sure starting to deleting code that confuses me will cause all sorts of regressions in the diagnostic parts of the testsuite. Martin - can you have a look here and maybe give directions? In particular how 'refoff' and 'offrange' depend (or if they stand on its own). I think that &ref - &base =3D=3D refoff? So for &MEM[(const struct array *)aMessage_1(D) + 4B]._M_elems having ref =3D MEM[(const struct array *)aMessage_1(D) + 4B]._M_elems, base =3D aMessage_1(D), refoff =3D 4 and offrange[] =3D {4, 4} looks OK. But then I'm confused as to why the diagnostic triggers. Maybe that's because refsize =3D=3D 0 which is a special case for "unknown"? That's because ref analysis does if (!integer_zerop (memrefoff)) /* A non-zero offset into an array of struct with flexible array members implies that the array is empty because there is no way to initialize such a member when it belongs to an array. This must be some sort of a bug. */ refsize =3D 0; on the MEM_REF path. But I don't understand how the comment applies here - there is no flexibel array member involved, in particular the MEM_REF doesn't offset an array it offsets struct X. So I'm inclined to simply kill the above ...?=