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 029CD385B508; Wed,  8 Mar 2023 18:37:35 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 029CD385B508
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1678300656;
	bh=WE/kN8wwM3mJSlyKsus+dhMnL8Kp3lp3dYyo9BZ3gfA=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=PQX43UBHzExNowg9Jk3H2DvTxhg4wCxyFKgSG5v8bMMiQFA7P/czji7lhQW0KV56b
	 mWdF70VOb0/KCW25I8ZZ6bseivP83fKKoycXIQoIrtMxw6R322VowHzR5c49JYHzGO
	 uO4Q4LQVpheU/6Rn4aiqOygTyS1f//qEH0S7yAzo=
From: "muecker at gwdg dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/108896] provide "element_count" attribute to give more
 context to __builtin_dynamic_object_size() and -fsanitize=bounds
Date: Wed, 08 Mar 2023 18:37:35 +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: unknown
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: muecker at gwdg dot de
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-108896-4-91nGhTPCwg@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-108896-4@http.gcc.gnu.org/bugzilla/>
References: <bug-108896-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=3D108896

--- Comment #29 from Martin Uecker <muecker at gwdg dot de> ---
Am Mittwoch, dem 08.03.2023 um 17:13 +0000 schrieb qinzhao at gcc dot gnu.o=
rg:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D108896
>=20
> --- Comment #24 from qinzhao at gcc dot gnu.org ---
> (In reply to Martin Uecker from comment #15)
> >=20

...
>=20
> however, I think that both the new attribute and the new C syntax extensi=
on
> should support the similar user interface. We might need to decide on this
> first.

I think there are some fundamental differences: In one
case the size is encoded into the type and in the other
it is just an annotation that can be ignored.

>=20
> right now, the user interface we cannot agreed on is:
>=20
> whether we should support the following nested annotation (either with
> attribute or with the C syntax extension):
>=20
> struct object {
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0...
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0unsigned int items;
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0...
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0struct inner {
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0...
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0int flex[];
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0};
> } *ptr;
>=20
>=20
> My opinion is: No, we should not support this, it will make the implement=
ation
> much more complicated both for attribute and for C syntax extension.=20
>=20
> But I am not very sure on this yet.=20

I am fine with supporting it, but one needs to decide
on the semantics in the case where inner is not accessed
via the outer struct.
>=20
> Is the PLACEHOLDER_EXPR able to resolve this?

I don't know yet.=C2=A0

Martin


>=