From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cross.elm.relay.mailchannels.net (cross.elm.relay.mailchannels.net [23.83.212.46]) by sourceware.org (Postfix) with ESMTPS id 6ABC03858C60 for ; Mon, 23 Oct 2023 13:23:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6ABC03858C60 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gotplt.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gotplt.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 6ABC03858C60 Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=23.83.212.46 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1698067390; cv=pass; b=tHSeu2ij8F2SElh/3byhuoJFRUy8u7M4xcA6eem0yVi1g8ZbuUDh03ewGk/sYhl4vGkO9KP2i3KBpQU0kuBxxHTvR0NNOHgNV1xXCzE3MVZD++iXVxFqGf4rUItXNVeXrnSRxHNU1w1gI5fiQbFjWF/eVB3+ML2psLRLbXAq16o= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1698067390; c=relaxed/simple; bh=/JMY41lxgPZkayGK1XHf955M2XuaGMwYkg6e+NYvwTg=; h=DKIM-Signature:Message-ID:Date:MIME-Version:To:From:Subject; b=Y5lm3PghqelwLPyJCLdrMXcNS8dP9RGe4mG1cdWInSJRlf5MupeYg7ibzF3buQKNHcvwHyMQu0+zSVw4tq55sVVbD6UGylBuyu/jvmJ8HSCvBmhpjxanw+aFaZDYwgegcdn33tJlJaxZMRCnhl2agKbGIpyp5rFSgbVKJfLYBu4= ARC-Authentication-Results: i=2; server2.sourceware.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 52DE1102951; Mon, 23 Oct 2023 13:23:07 +0000 (UTC) Received: from pdx1-sub0-mail-a202.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id B50B6102907; Mon, 23 Oct 2023 13:23:06 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1698067386; a=rsa-sha256; cv=none; b=f3IZYs/66OiicOTXWdN6o715b2/0eMipsFP03g+7mNEFxQL4XSukknBXDdpIXrObLBU4qg +UMil7VXb01WRe9iZSqMSkwJBCn5ctrbcg+0GMSZ1+AJjT9X27wU2CVVxR3UKBHpWUi6OR mlkNZYlB+N0KAw2EfzxzaBZqoYZJm1Yz5dXRuy3zq9seEES1KsTWYWZfcaiAJVMGaI4NPG BFpRsi1B9MkW8GCzkujQl3iGtMxtHyuy7XBsSEVu7yGt8FscDR1+uU+C9G6aMUzvk8B8BZ JVTbr08GF7h9GByC4d85pAF4vHY5tdF0mUi7ohsgr4UiG+rgUcILp7kaIccABg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1698067386; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=p8hzlWPIDl1triShjWs0a13A+pF4gd3F3rTbTjZeSzY=; b=6yuZfOwQo0EgfnAEjiHxOyI9NTILnTeay0d1Y6BISRdWsN5eL1qOup3lGqs7CafhSyA13I pYZpC9UQeUMRYq/QtjNz1UyKsvwO9Hb9HpWS4jVW9ztOBSTFMo72tSIyEeb87qp+9R6D5T 5+VEsSIdcsG8Q245p0H+IijUmuXRKqPkZeIZ0QxADyAw9PmDgELeqerAQaKt882WMsCb/d HIK8+T2ow7jKwu9mkqL4hcdG0K+MQfKaHmgf95sSQYrqZCoeprKjF0hO5N3RgHcb0J2t6K rBssm66P+pgGuBrsM+tEtyAZiz4ZUiDD6iqVsRPvyzsgoDGKa578D79aaJ/QQA== ARC-Authentication-Results: i=1; rspamd-6557c4b887-kz6pg; auth=pass smtp.auth=dreamhost smtp.mailfrom=siddhesh@gotplt.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|siddhesh@gotplt.org X-MailChannels-Auth-Id: dreamhost X-Chief-Decisive: 6292d03144b23e24_1698067387124_3930602443 X-MC-Loop-Signature: 1698067387124:1386981220 X-MC-Ingress-Time: 1698067387124 Received: from pdx1-sub0-mail-a202.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.123.152.107 (trex/6.9.2); Mon, 23 Oct 2023 13:23:07 +0000 Received: from [192.168.2.12] (bras-vprn-toroon4834w-lp130-02-142-113-138-136.dsl.bell.ca [142.113.138.136]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: siddhesh@gotplt.org) by pdx1-sub0-mail-a202.dreamhost.com (Postfix) with ESMTPSA id 4SDbV14dL4z4C; Mon, 23 Oct 2023 06:23:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gotplt.org; s=dreamhost; t=1698067386; bh=p8hzlWPIDl1triShjWs0a13A+pF4gd3F3rTbTjZeSzY=; h=Date:To:Cc:From:Subject:Content-Type:Content-Transfer-Encoding; b=XotcTG2TrMHqVFe5S82Po7blyi3NwdpVZlQVDZ8oQ8044TzGm2m+Ok8pSmCgPPwNY RztDAgcKujBKk+cJrtkC+efCKNd22+Ze2N58xN6Q82JifBfGXJTi+JNzQVIc5jOBIX HI8rx4MhsQEyCF/foR8cGRKGFKwpMHzLzqps6n5jKfWFIqp516I6FTm6LmtHnl2/1Z aMyzevrr0nQfeCfvy4fCEcz8WM1MlJurKnA23AdM04hNu+TJneDNskoHbxNg/KZjrH AzfajLi5O0UIxvvNA9InkVsJ4fFH/8piVmWxV6LFxF9Z/6N9+u4GOJ/NcuydD+AmH1 nu3ol+SjPIDhw== Message-ID: Date: Mon, 23 Oct 2023 09:23:04 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Content-Language: en-US To: Richard Biener Cc: Qing Zhao , Joseph Myers , Jakub Jelinek , gcc Patches , kees Cook , Martin Uecker , "isanbard@gmail.com" References: <22BDBC0E-1B28-46D0-BCA4-588F73B198E0@oracle.com> <46C61773-8C30-4A68-815A-E724A6A4DCEE@oracle.com> <2151D1F7-721B-4DDE-A2A1-B6FCA5F2783F@oracle.com> <3a6cb1b4-05da-e48c-4acc-a1cf3977c74d@gotplt.org> From: Siddhesh Poyarekar Subject: Re: HELP: Will the reordering happen? Re: [V3][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896) In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3031.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,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: On 2023-10-23 08:34, Richard Biener wrote: >>> 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. >> >> Maybe the trick then is to treat the size data as volatile? That ought >> to discourage reordering and also prevent elimination of the "dead" store? > > But we are an optimizing compiler, not a static analysis machine, so I > fail to see how this is a useful suggestion. Sorry I didn't meant to suggest doing this in the middle-end. > I think Martins suggestion to approach this as a language extension > is more useful and would make it easier to handle this? I think handling for this (e.g. treating any storage allocated for the size member in the struct as volatile to prevent reordering or elimination) would have to be implemented in the front-end, regardless of whether it is a language extension or as a gcc attribute. How would making it a language extension vs a gcc attribute make it different? Thanks, Sid