From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailrelay.tugraz.at (mailrelay.tugraz.at [129.27.2.202]) by sourceware.org (Postfix) with ESMTPS id 5B3DF3858D37 for ; Mon, 23 Oct 2023 18:55:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5B3DF3858D37 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=tugraz.at Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tugraz.at ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 5B3DF3858D37 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=129.27.2.202 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698087337; cv=none; b=ZXRf7knAS6IMkawiFelHW7iziL+C2HcpcCIz2H0dV5UjgmKcKiowiOosW+ZsEGBQdeL55W9A1PSbdQq4pMccOA2TxB7cENQAHSmwjGo0Lct/GzpIjf34x6xVpFSTsOni3sHhljv2Yh4LnX1BEYIW+9g03eQgaMH9yHzHRHWMolE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698087337; c=relaxed/simple; bh=chXxXISyMJaCJ1rmqZiOhpPNC8MzYleXqymhqu61qbM=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=wCJOh81i6/fSoH0n5l8pwm2XOsE9Cq185L8kcoJaISl5nnkxkP8JZ19aos71Xu3X1Pzchfnxi85p4EWK722uC2dR8ZefrP0IRA6a1MNioVxf3/3AS5tLjI9q3yoHbXzJkPD1bs2Tcf5Lc5lBK1w1Q+sT1BPJ0h4M3xScUaiJ8OE= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from vra-173-176.tugraz.at (vra-173-176.tugraz.at [129.27.173.176]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4SDksb3TCTz1LM0K; Mon, 23 Oct 2023 20:55:31 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 mailrelay.tugraz.at 4SDksb3TCTz1LM0K DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1698087333; bh=fS6aJIRrlG1BJ2FCJe0ivcImqTnYmqlwb6aLMfBklxY=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=Ns2wKS/I76uphNlu7OvqHqbd1+lsXo9lUi49Z7giTQhwNsy1XHq1z7tJ9Z5vofa5x XLBVslAsWlM40Qu/JCihvicbR16cNG29m2uBDErVpCaCaTMftak36q+LcUtVKxUV/6 CMRW2d5HlGXUCea9KNowPi8+Jbmg+m4xVDT4N8jo= Message-ID: <62336c2385d4a8a6c9f1f137c416bc433660837d.camel@tugraz.at> Subject: Re: HELP: Will the reordering happen? Re: [V3][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896) From: Martin Uecker To: Siddhesh Poyarekar , Qing Zhao , Richard Biener , Joseph Myers Cc: Jakub Jelinek , gcc Patches , kees Cook , "isanbard@gmail.com" Date: Mon, 23 Oct 2023 20:55:31 +0200 In-Reply-To: <168fea24-844e-4d1a-9361-afb6332b4f11@gotplt.org> References: <9DDD0677-BFE7-4733-8C11-0FA8B3C25569@oracle.com> <283B5497-52BD-47D4-BC08-0982AB6740CA@oracle.com> <53e8ed5778d0e908d224d940ddc3d99575b83dd3.camel@tugraz.at> <168fea24-844e-4d1a-9361-afb6332b4f11@gotplt.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4-2 MIME-Version: 1.0 X-TUG-Backscatter-control: G/VXY7/6zeyuAY/PU2/0qw X-Spam-Scanner: SpamAssassin 3.003001 X-Spam-Score-relay: -1.9 X-Scanned-By: MIMEDefang 2.74 on 129.27.10.117 X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Am Montag, dem 23.10.2023 um 14:43 -0400 schrieb Siddhesh Poyarekar: > On 2023-10-23 14:06, Martin Uecker wrote: > > We should aim for a good integration with the BDOS pass, so > > that it can propagate the information further, e.g. the > > following should work: > >=20 > > struct { int L; char buf[] __counted_by(L) } x; > > x.L =3D N; > > x.buf =3D ...; > > char *p =3D &x->f; > > __bdos(p) -> N > >=20 > > So we need to be smart on how we provide the size > > information for x->f to the backend. > >=20 > > This would also be desirable for the language extension. >=20 > This is essentially why there need to be frontend rules constraining=20 > reordering and reachability semantics of x.L, thus restricting DSE and= =20 > reordering for it.=C2=A0 Yes, this too. > This is not really a __bdos/__bos question, because=20 > that bit is trivial; if the structure is visible, the value is simply=20 > x.L. This is also why adding a reference to x.L in __bos/__bdos is not= =20 > sufficient or even possible in, e.g. the above case you note. The value x.L may change in time. I would argue that it needs to be the value of x.L at the time where x.buf (not x->f, sorry)=C2=A0 is accessed. So the FE needs to evaluate x.L when x.buf is accessed and store the value somewhere where __bdos can find it later. In the type information would make sense. But I am not sure how to do this in the best way so that this=20 information is not removed later when not used explicitely before __bdos tries to look at it. Martin