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 DA19B3858031; Wed,  1 Mar 2023 22:54:22 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DA19B3858031
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1677711262;
	bh=h5ORdar6HHo0IMbkF9qJzslcNReCR1nzbDVykzvinFM=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=FfwxVccYSuPh7lEOmT1waFsrUHR5ir4ViGtfDYbeEwjy8RK83H9fO9DRW6w99Uowc
	 KfGmWRqYPVfzUpRnXt42y/dvRFEd6MEVsaB3t+83/ykMu6VbZ+91ZkCEVq0d9kSUVd
	 6IvKA7KVVHQQXFdOMZePYnKBziO8LxhAsye4pkQM=
From: "qinzhao at gcc dot gnu.org" <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, 01 Mar 2023 22:54:22 +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: 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-108896-4-BkuyRAZTJN@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 #5 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #3)
> (In reply to Richard Biener from comment #2)
> > Iff only (GNU) C would accept the following ...
> >=20
> > struct foo {
> >     ...
> >     unsigned int count;
> >     ...
> >     int data[count];
> > };
>=20
> Well, that I think conflicts with the variable length structures GNU
> extension, where
> if the array size of a field isn't a constant expression, it is an
> expression evaluated at runtime once (SAVE_EXPR) to determine the field s=
ize.

VLA is only legal inside function scopes.=20
but this new extension will be legal at file scope.

will this fact be used to distinguish these two?

> Here we are talking about something similar to what Fortran wants with its
> deferred length arrays, essentially to have the size evaluated each time =
it
> is accessed.
> With the data[count] form even if it would be disambiguated the question =
is
> if we want to otherwise treat it like normal flexible array member e.g. f=
or
> sizeof etc. and only treat it specially for __bdos, or if it would affect
> say sizeof too.

the immediate purpose of this new extension is used for __bdos.
is there any benefit if it will affect sizeof()?

> I don't see how sizeof (struct foo) could be treated differently from
> flexible array member, because one doesn't have an object on which count =
can
> be evaluated, but perhaps
> struct foo f;
> f.count =3D 24;
> sizeof (f.data) could change.

what's the major purpose of enabling this?=