From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 7C9643858CDA; Wed, 21 Jun 2023 19:40:53 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7C9643858CDA
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1687376453;
	bh=msBNAcqCvxQQk47xxYq5eri1zgBdG9fOKcSFDkMIRoE=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=RHKwVftEkKEtFXDZBqc0WBtbPAHdTSD0YPdTpz93r3vFWEUqPnq9uP7/98eFB1f5o
	 1m1C+NbD8u8pbJ/ylaS66pVgjsK07hemYpoNhrgOCrdv3tjN8gwebu1CFMiBirZSfy
	 /1OPSD2x5vSs9CQKIMxfsId8FRRJ3xX8PQwuq8Yo=
From: "qinzhao at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/101832] __builtin_object_size(P->M, 1) where
 M ends with a flex-array behaves like sizeof()
Date: Wed, 21 Jun 2023 19:40:52 +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: 12.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: qinzhao at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: qinzhao at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-101832-4-FrzIPceQUK@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-101832-4@http.gcc.gnu.org/bugzilla/>
References: <bug-101832-4@http.gcc.gnu.org/bugzilla/>
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: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D101832

--- Comment #11 from qinzhao at gcc dot gnu.org ---
> (In reply to Jakub Jelinek from comment #3)
> > This is intentional, if you embed an aggregate with flex array into ano=
ther
> > struct and ask not to cross the field boundaries (i.e. bos1), then the =
size
> > of that field is exactly what is the maximum size.
>=20
> As we discussed in PR 107952
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D107952):
>=20
> GCC extension accepts the following two cases:
>=20
> **Case 1:
>=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=20
>=20
> **Case 2:=20
>=20
> struct C { int n; struct A a; int x; };
>=20
> as if a.data[] can be up to 4 elements.=20
>=20
> So, what's you mean by "not to cross the field boundaries" is for the abo=
ve
> Case 2?=20
> For Case 1, we should treat A.data as flexible array, and then B.A as a
> structure that has flexible array, therefore B.A's size is flexible too.=
=20
>=20
> Is my understanding correct?


After discussion, the following patch to clarify the above two cases was
approved:
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/620122.html

with this clarification, the above case 1 is accepted as a GCC extension, b=
ut
case 2 will be deprecated. a warning option -Wflex-array-member-not-at-end =
is
provided to detect case 2 in the user code.=20

please see also PR77650.=