From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 937F13858C62; Wed, 25 Jan 2023 07:32:19 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 937F13858C62 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1674631939; bh=xxAeAQSV8l5PQeJS7CSMkHsKeEvc+HtK6+w0wWVTeCk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ELeaNbRgnyPV3QtV1SkiH5rYKTtG09GnBd7B+6LvHlMtTejgzDKvMEURX4oRWWZXR 5oHCC9a9PxZ3Ridp6Qb5WBZrabGOhcU4jklVZYx9zpcsh6WT70Oq1/WXzdPiPZiX5V 3BhQ0tfrYmBDFxUa5vxd0AQ+Eq4YhTrIl2Yz/PpE= From: "rguenther at suse dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/107952] tree-object-size: inconsistent size for flexible arrays nested in structs Date: Wed, 25 Jan 2023 07:32:18 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 13.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenther at suse dot de X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: siddhesh at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D107952 --- Comment #11 from rguenther at suse dot de --- On Tue, 24 Jan 2023, qing.zhao at oracle dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D107952 >=20 > --- Comment #10 from Qing Zhao --- > > --- Comment #9 from Richard Biener --- > >=20 > > GCC handles for example > >=20 > > struct A { char data[1]; }; > > struct B { int n; struct A a; }; > >=20 > > as if the a.data[] array is a flex-array. >=20 > Okay. Then the maximum size of __builtin_object_size for it should be -1, > right? I think so. > > It also handles > >=20 > > struct C { int n; struct A a; int x; }; > >=20 > > as if a.data[] can be up to 4 elements large (we allow an array to exte= nd > > flexibly to padding - but only if it is trailing). >=20 > A little confused here:=20=20 > when the structure with a trailing flexible-array member is a mid= dle > field of=20 > an outer structure, GCC extension will treat it as a flexible-arr= ay > too? But the > maximum size of this flexible-array will be bounded by the size o= f the > padding > of that field?=20 > Is the above understanding correct? That's correct - at least when using the get_ref_base_and_extent API. I see that when using array_ref_flexible_size_p it doesn't return true (but it's technically not _flexible_, we just treat it with a bound size that doesn't match the declared bound). > > I see that's not > > consistently handled though. > >=20 > > I think the [] syntax should follow the C standard as what testcases are > > accepted/rejected by the frontend and any extensions there should be > > documented >=20 > Agreed, usually where these extension should be documented? They are usually documented in doc/extend.texi > > (those are separate from what the former array_at_struct_end_p > > allowed semantically >=20 > So, your mean to leave such extension out of ?array_at_struct_end_p? (the > current ?array_ref_flexible_size_p?)? The first is handled by the function just fine, it's the second with the bound size that's not and that isn't a good fit there, though we do handle padding to the end of a declaration where we return true. > Handle them separately instead? I'm not sure how important it is to hande the middle array extending to padding, ISTR there was some real world code "miscompiled" when treating the array domain as written. Richard.=