From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) by sourceware.org (Postfix) with ESMTPS id 895543858CDA for ; Mon, 23 Oct 2023 08:01:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 895543858CDA Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 895543858CDA Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::136 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698048067; cv=none; b=pMtLW3i5IUZNG2wk0/b1RUD1C8SnraPm7so/90zB2c4+g4p4w6n5lDooLx/ohhfDfvH/Hz7376ivYUxdrUwkvc+sbcewiRqLssYUgXqFkhapq3dPdJ0cvGr5iMWGvRR5yqjB9CKgHYTa3S4BfH1hCEA7s5VE2gwIHEISCn+T6Ow= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698048067; c=relaxed/simple; bh=KOYuHyrS2cHgTbzMLD2dxaUXflfC6pNy1O7GASeYXnw=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=laUO3jhL4pqTgTHrhup9FMV6NUon1gi3/rOZ5V5j9lJj4/i+6gQQQ4HDj0YbzrPK5NJTD0vyoKBQHapFwf+N2ECjgusJUg5fvHeqe8nR3SSTaPGIuq/bjgNO4bF0jVNz9c/Xe9PzZctiFvFhwBVRbhv1cWRgLXEyLCOqqgQkWv0= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-507962561adso4199489e87.0 for ; Mon, 23 Oct 2023 01:01:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698048063; x=1698652863; darn=gcc.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=7X34w+8V8/b5Jg5+pwQpkaJRWeMS8Gy8Hr+e07pU8z8=; b=c7YjC017+xHXxUFYC6Rz4d7EWzv9qCwsp9sad9IcOd7DJmTCXHbbWfIsM3JcUWs82W 2yEx4kn7CHO+56e9MewJ1S5LWxvQ6mxHXnrZ7Aev3mHyWmFukKXM/I7lAPNzjC62Y8jV 1DY9a6mKUbYw6s6FWgS/L+uVfBjBykQ6SEUlNIuHEYvU9VTQf/X6u9cXAPoZR8yDBva9 z87oVl1Xd2gl98iWSOIZvDQMfj9hGbe8eO2keqv9dtDK0LJhyt3Uj6t/zcSEf8yGNJhJ 2jI21A/g+e1YBGlA8aoePJHIkzyFRRtBfTzAymvwTw5V/X/PGYbZbprIgc1gUlDgYFZH 6BSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698048063; x=1698652863; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=7X34w+8V8/b5Jg5+pwQpkaJRWeMS8Gy8Hr+e07pU8z8=; b=reagVkuaspe+jTqKSP0xrdPThPBI7dpK0nTVqgJE6Ab8t0X0hzBNwhN2Bv308xDgBR 3UG/HMQkplWAC59niY7XOXwEbsDQFJuoY1whRRLBb3sgzaTPvL9zLIrJ/h6IvLt4GEsx EzWkNMYP5xRtaXl39HVwLtC3QcWrI2aaaP0bPmUOlXflj+9ZrUnPze01qS42z4CQm6TO amf1Uakl4hv4Z4PaNwysx9WnfcKQYgUtm50wC0xMsjUz+oDpucLeHe8qeUBMZlY+Y3Uc /BtsHK43+goQWgB/jrpR0yXNB9d9fTu9zSBCO9gMA9hOX/VW5rfrZnDL3Oyn43oXPfMU C3iw== X-Gm-Message-State: AOJu0YzFmD+MbWAkfG5wrsVEiVClIIAalaYv9g2CZ5onlf4UhyZTWByR +qD/KmLDyOOHxIHDcn6VlHmmcJQWACgGUX8/zB8= X-Google-Smtp-Source: AGHT+IFUr9EV56tIr/3RrQ9zRKIilATE80nwJWf5L7MIlvk6uB58JgQy4T0CLBhRapvB5VrDiRJsYiC8mVn5yr9VLkY= X-Received: by 2002:ac2:4c94:0:b0:500:7a23:720b with SMTP id d20-20020ac24c94000000b005007a23720bmr5837419lfl.55.1698048062759; Mon, 23 Oct 2023 01:01:02 -0700 (PDT) MIME-Version: 1.0 References: <22BDBC0E-1B28-46D0-BCA4-588F73B198E0@oracle.com> <46C61773-8C30-4A68-815A-E724A6A4DCEE@oracle.com> <2151D1F7-721B-4DDE-A2A1-B6FCA5F2783F@oracle.com> In-Reply-To: <2151D1F7-721B-4DDE-A2A1-B6FCA5F2783F@oracle.com> From: Richard Biener Date: Mon, 23 Oct 2023 09:57:58 +0200 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) To: Qing Zhao Cc: Siddhesh Poyarekar , Joseph Myers , Jakub Jelinek , gcc Patches , kees Cook , Martin Uecker , "isanbard@gmail.com" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,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: On Fri, Oct 20, 2023 at 10:41=E2=80=AFPM Qing Zhao w= rote: > > > > > On Oct 20, 2023, at 3:10 PM, Siddhesh Poyarekar w= rote: > > > > On 2023-10-20 14:38, Qing Zhao wrote: > >> How about the following: > >> Add one more parameter to __builtin_dynamic_object_size(), i.e > >> __builtin_dynamic_object_size (_1,1,array_annotated->foo)? > >> When we see the structure field has counted_by attribute. > > > > Or maybe add a barrier preventing any assignments to array_annotated->f= oo from being reordered below the __bdos call? Basically an __asm__ with ar= ray_annotated->foo in the clobber list ought to do it I think. > > Maybe just adding the array_annotated->foo to the use list of the call to= __builtin_dynamic_object_size should be enough? > > But I am not sure how to implement this in the TREE level, is there a USE= _LIST/CLOBBER_LIST for each call? Then I can just simply add the counted_b= y field =E2=80=9Carray_annotated->foo=E2=80=9D to the USE_LIST of the call = to __bdos? > > This might be the simplest solution? If the dynamic object size is derived of a field then I think you need to put the "load" of that memory location at the point (as argument) of the __bos call right at parsing time. I know that's awkward because you try to play tricks "discovering" that field only late, but that's not going to work. A related issue is that assignment to the field and storage allocation are not tied together - if there's no use of the size data we might remove the store of it as dead. Of course I guess __bos then behaves like sizeof (). Richard. > > Qing > > > > > It may not work for something like this though: > > > > static size_t > > get_size_of (void *ptr) > > { > > return __bdos (ptr, 1); > > } > > > > void > > foo (size_t sz) > > { > > array_annotated =3D __builtin_malloc (sz); > > array_annotated =3D sz; > > > > ... > > __builtin_printf ("%zu\n", get_size_of (array_annotated->foo)); > > ... > > } > > > > because the call to get_size_of () may not have been inlined that early= . > > > > The more fool-proof alternative may be to put a compile time barrier ri= ght below the assignment to array_annotated->foo; I reckon you could do tha= t early in the front end by marking the size identifier and then tracking a= ssignments to that identifier. That may have a slight runtime performance = overhead since it may prevent even legitimate reordering. I can't think of= another alternative at the moment... > > > > Sid >