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 A2F4D3858C36; Wed, 25 Jan 2023 16:12:43 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A2F4D3858C36
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1674663163;
	bh=sl2SUvYwFl3++UbqaMf59dVxLofngmzcMqV6itfMbJ0=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=SAftCYsafwxvI0Ygot1HgNL8ve/tyXhKmHb77/bHhcRI8SNyarmCj+G5doCftsQAj
	 l5wtCRqCaXeeSX3VngixXwxBPLpZTBzxtWhK8RZnjmmt3zRcx+gxjI0DKHEoBDc4e5
	 52x2gL7sO8zYm6JW1BxO3fV0BlS9fQcEkk2VeWQU=
From: "siddhesh at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
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 16:12:43 +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: siddhesh at gcc dot gnu.org
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: <bug-107952-4-tvbxtn9JwL@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-107952-4@http.gcc.gnu.org/bugzilla/>
References: <bug-107952-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=3D107952

--- Comment #14 from Siddhesh Poyarekar <siddhesh at gcc dot gnu.org> ---
(In reply to Qing Zhao from comment #13)
> >=20
> > The first is handled by the function just fine,
>=20
> No, even the first case is not recognized by the current
> =E2=80=9Carray_ref_flexible_size_p=E2=80=9D, it=E2=80=99s not been identi=
fied as a flexible array
> right now.
> Shall we include this case into =E2=80=9Carray_ref_flexible_size_p=E2=80=
=9D?  (It=E2=80=99s a GCC
> extension).

In the first case, array_ref_flexible_size_p recognizes S2.flex.data as hav=
ing
flexible size.  The tests in my patch[1] for this bug checks for this.

However, array_ref_flexible_size_p does not recognize S2.flex as having
flexible size.  It might make sense to support that, i.e. any struct or uni=
on
with the last element as a flex array should be recognized as having flexib=
le
size.

[1] https://sourceware.org/pipermail/gcc-patches/2022-December/608912.html=