From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 83CE43858C78; Tue, 4 Apr 2023 16:33:28 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 83CE43858C78 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1680626008; bh=0MvVZ9GFdlt5ofrzbctMK3JRbkyP5smssMf6TyaLEwc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=s4CReQUpmmdxYmwWfB1rfXTRp+JeMdJePLC/Ig6pQMAABnAxQ5dpMr11lFz0tZLPV D6FhjqlfkjxTnEj6WnOzKn7Storalb6HVvqZ3VoErYzN6ZASPwzYX54tB/IwACBa/n D+vqRNvNmaX6Su2Xk5OHhepXSxx1sxrLenUtzdxQ= From: "muecker at gwdg dot de" 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: Tue, 04 Apr 2023 16:33:27 +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: 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=3D108896 --- Comment #38 from Martin Uecker --- Am Dienstag, dem 04.04.2023 um 15:07 +0000 schrieb qinzhao at gcc dot gnu.o= rg: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D108896 >=20 > --- Comment #37 from qinzhao at gcc dot gnu.org --- > (In reply to Martin Uecker from comment #36) >=20 > >=20 > > I considered pointers to arrays: > >=20 > > struct P { > > =C2=A0=C2=A0int n; > > =C2=A0=C2=A0char (*buf)[.n]; > > }; > >=20 >=20 > Okay.=20 > Then for the field "buf", it has a pointer type, the size of this field i= s a > compile-time constant. where in the IR do you put the ".n" (the size of t= he > array this pointer points to). That's the place I am trying to understand= from > your patch or from the IR dump of a working small testing case.=20 Try this: struct foo { int n; char (*buf)[.n]; }; void store(struct foo* p, int a, int b) { (*p->buf)[a] =3D b; } int main() { struct foo p =3D { 7, &(char[7]){ 0 } }; store(&p, 7, 1); } With UBSan, this should give this error: ex.c:8:52: runtime error: index 7 out of bounds for type 'char [*]' In the parser for '.n' I create a component ref with a placeholder expression inside it. But then later when creating a component ref for p->buf I replace all placeholder expressions in the *type* of p->buf with *p. So the type of p->buf has a .n as size expression somewwere and this=C2=A0 becomes p.n. So the middle-end never sees the placeholder, but only the size expression with the p.n in it. According to the comment in tree.def I thought the later (replacement) part happens automatically in the middle end, but this does not seem to be the case in this scenario, so I implemented it in the FE. > > the FAM case needs more work and I guess there are > > still many other problems with the patch. > >=20 > For the FAM case, since the field itself is an ARRAY type, then the ".n" = can be > naturally put to the SIZE of the type of the field. Yes, potentially. But a FAM has special semantics and the code for this detects this based on the missing size (I think). > Another thing I'd like to point out, for the original intention of this P= R, FAM > case is more important than the pointer to array case, I think. So, shoul= d we > focus on FAM first? I tried the other thing first, because it seemed simpler and could potentially serve as a basis for the FAM case. But I am not so sure anymore, because of the issue mentioned below. > >=20 > > The comments in > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D104970 > >=20 > > imply that the size information does not survive long enough > need to study this a little bit more. >=20 > > But the size expression is evaluated each time when the member is > > accessed.=20 > How to represent this in IR? This is done in the FE by putting the size in save_expr which and building the C_MAYBE_CONST_EXPR. >=20 > > Maybe the size expressions should be limited to very simple=20 > expressions without side effects. > agreed. but I think we might want to focus on FAM first. For the FAM case we should probably attach the attribute to the member and read it directly in the object size pass, similar how this is now done for the access attributes for parameters. I also thought that passing the information via the type would be better, but I am not sure how to do this at the moment. In any case, I am also just learning about a lot of things in the middle end, so if others with more experience have advice, you should better listen to them. Martin >=