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 83F573858CDB for ; Wed, 25 Oct 2023 10:47:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 83F573858CDB 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 83F573858CDB 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=1698230855; cv=none; b=YqrcRQYlHtYJYO4xPtTa9B+f/sp/NXsMI+pW0KsAfImvHTe7lI1d7wY8rVSGrAN9yWDV0KOJO/0ZhsIO7C9GYNXP+dWJA+/6qzb7R4WoL+22FRDomIHSAiimedRiMFmBXbIz8nkTJpLdkFMVhZq3mCkPw6Un1RXKLAk2Pg3LjBY= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698230855; c=relaxed/simple; bh=y4o6AOWaD1QdEEpfun5CRM7grsZ4Q6BTJsh9ydSI9tQ=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=G9lNY8b0kh8xM1MTiML2Qo+ocMu5LF/lQClRCqZr6xy/nz5NENcSG3lzpbabQM53Y/zUVo2WRypKmeqH3JGlo14pLdh9hPAYzH1Hy9PfIesELpCF3cbdhBMUyCNnJ7yECLVMQxEkKKj/6N2v9HyMvVmSDQLXchdkP2/5rlzzH3M= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from fbmtpc21.tugraz.at (fbmtpc21.tugraz.at [129.27.144.40]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4SFlxZ0s5wz3whc; Wed, 25 Oct 2023 12:47:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1698230850; bh=KDWP6dI1GmULarszbo9oo2+aP9rJc3lAtezkBkPQX3c=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=bqGJxwNfyZS9DuGkhiTjs8dGyG79gHBNoKLGDya5ubgPoSPYhFOYdnVxSmMs7UaPN tjqAfUrjucdHoy+ecupm0M65NYB4SosA3qlBCod22YWjMHEHHMAjLabo/mKaptMq+Y ttrTnqgPR/KU8ywkDAeaRi9IQCQgc5sBTiWqZPc4= Message-ID: 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 , Richard Biener Cc: Qing Zhao , Joseph Myers , Jakub Jelinek , gcc Patches , kees Cook , isanbard@gmail.com Date: Wed, 25 Oct 2023 12:47:29 +0200 In-Reply-To: <1b0dcd0d-09e0-42ee-8c5f-1ce8fe241775@gotplt.org> References: <05d65224067ff72124d94b6b5274f14d013b64af.camel@tugraz.at> <9cdc6bc40cf1d0e701a69e6e37cdffa89a0db690.camel@tugraz.at> <1b0dcd0d-09e0-42ee-8c5f-1ce8fe241775@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.116 X-Spam-Status: No, score=-4.5 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 Mittwoch, dem 25.10.2023 um 06:25 -0400 schrieb Siddhesh Poyarekar: > On 2023-10-25 04:16, Martin Uecker wrote: > > Am Mittwoch, dem 25.10.2023 um 08:43 +0200 schrieb Richard Biener: > > >=20 > > > > Am 24.10.2023 um 22:38 schrieb Martin Uecker : > > > >=20 > > > > =EF=BB=BFAm Dienstag, dem 24.10.2023 um 20:30 +0000 schrieb Qing Zh= ao: > > > > > Hi, Sid, > > > > >=20 > > > > > Really appreciate for your example and detailed explanation. Very= helpful. > > > > > I think that this example is an excellent example to show (almost= ) all the issues we need to consider. > > > > >=20 > > > > > I slightly modified this example to make it to be compilable and = run-able, as following: > > > > > (but I still cannot make the incorrect reordering or DSE happenin= g, anyway, the potential reordering possibility is there=E2=80=A6) > > > > >=20 > > > > > 1 #include > > > > > 2 struct A > > > > > 3 { > > > > > 4 size_t size; > > > > > 5 char buf[] __attribute__((counted_by(size))); > > > > > 6 }; > > > > > 7 > > > > > 8 static size_t > > > > > 9 get_size_from (void *ptr) > > > > > 10 { > > > > > 11 return __builtin_dynamic_object_size (ptr, 1); > > > > > 12 } > > > > > 13 > > > > > 14 void > > > > > 15 foo (size_t sz) > > > > > 16 { > > > > > 17 struct A *obj =3D __builtin_malloc (sizeof(struct A) + sz * s= izeof(char)); > > > > > 18 obj->size =3D sz; > > > > > 19 obj->buf[0] =3D 2; > > > > > 20 __builtin_printf (=E2=80=9C%d\n", get_size_from (obj->buf)); > > > > > 21 return; > > > > > 22 } > > > > > 23 > > > > > 24 int main () > > > > > 25 { > > > > > 26 foo (20); > > > > > 27 return 0; > > > > > 28 } > > > > >=20 >=20 > >=20 > > > When it=E2=80=99s set I suppose. Turn > > >=20 > > > X.l =3D n; > > >=20 > > > Into > > >=20 > > > X.l =3D __builtin_with_size (x.buf, n); > >=20 > > It would turn > >=20 > > some_variable =3D (&) x.buf > >=20 > > into > >=20 > > some_variable =3D __builtin_with_size ( (&) x.buf. x.len) > >=20 > >=20 > > So the later access to x.buf and not the initialization > > of a member of the struct (which is too early). > >=20 >=20 > Hmm, so with Qing's example above, are you suggesting the transformation= =20 > be to foo like so: >=20 > 14 void > 15 foo (size_t sz) > 16 { > 16.5 void * _1; > 17 struct A *obj =3D __builtin_malloc (sizeof(struct A) + sz * sizeof(ch= ar)); > 18 obj->size =3D sz; > 19 obj->buf[0] =3D 2; > 19.5 _1 =3D __builtin_with_size (obj->buf, obj->size); > 20 __builtin_printf (=E2=80=9C%d\n", get_size_from (_1)); > 21 return; > 22 } >=20 > If yes then this could indeed work. I think I got thrown off by the=20 > reference to __bdos. Yes. I think it is important not to evaluate the size at the access to buf and not the allocation, because the point is to=C2=A0 recover it from the size member even when the compiler can't=C2=A0 see the original allocation. Evaluating at this point requires that the size is correctly set before the access to the FAM and the user has to make sure=C2=A0 this is the case. But to me this requirement would make sense. Semantically, it could a=C3=B6so make sense to evaluate the size at a later time. But then the reordering becomes problematic again. Also I think this would make this feature generally more useful. For example, it could work also for others pointers in the struct and not just for FAMs. In this case, the struct may already be freed when BDOS is called, so it might also not possible to access the size member at a later time. Martin >=20