From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) by sourceware.org (Postfix) with ESMTPS id 082153858D3C for ; Sun, 16 Jan 2022 12:37:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 082153858D3C Received: by mail-wm1-x32f.google.com with SMTP id n19-20020a7bc5d3000000b003466ef16375so17524509wmk.1 for ; Sun, 16 Jan 2022 04:37:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=4fT51gRhba7GpW+dCXRcP6NJsbUpvnCUxTJklmTKP+g=; b=oDwxGj5GdEs3vPs+oMvwK9AtgmEstp6ZBA9OrFO8L27dLMFQdQrHHAeLfTAlCmzU/2 +S6bTEe5tM5ozvmEz5xwG92Btn+n9pleDL27Tyl6vmPhV9wa1mgALp7E4p58jgLjqi9U gLRshgZDLy73FywcYf6xg1vbhdzM8JY0hasJnaLLz6K4fs6xPYvg2NrEE1XTIDS/qHqi kfP/+RCtedQZ7xt7xTViuKvo97yOZtnG3kV9A6wPrXwAzM2pI9lJ4iVOFCio9umu0Wpb NZgKRPvt4qf3uvXr8lyDRAQos9V/3sE/rL1DDHXtKus+k0PxUx1hl532q+uOs4K34q/f V1tA== X-Gm-Message-State: AOAM532YcpncJnUTE7q4dzgaxOvk/hqaYT4HIO1ymzZS1RUGsxCb/P6L zF1OKgkBZc4OiTJthDhTI0Q= X-Google-Smtp-Source: ABdhPJzJa515FTlSmdtDu0f+CjZyn2TNk+qg6kFWWWI2IGXNek5PotP+G4BFH2x6AqSl9WU7saiBbA== X-Received: by 2002:a1c:5405:: with SMTP id i5mr10273352wmb.34.1642336634858; Sun, 16 Jan 2022 04:37:14 -0800 (PST) Received: from 2a02-8388-e205-e880-569c-680a-c69b-a1ad.cable.dynamic.v6.surfer.at (2a02-8388-e205-e880-569c-680a-c69b-a1ad.cable.dynamic.v6.surfer.at. [2a02:8388:e205:e880:569c:680a:c69b:a1ad]) by smtp.gmail.com with ESMTPSA id c4sm5835095wma.1.2022.01.16.04.37.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 16 Jan 2022 04:37:14 -0800 (PST) Message-ID: <24ecea0e5014c50976aa99d87333bc9054ae8817.camel@gmail.com> Subject: Re: reordering of trapping operations and volatile From: Martin Uecker To: Paul Koning , Martin Sebor Cc: Michael Matz , GCC Development Date: Sun, 16 Jan 2022 13:37:13 +0100 In-Reply-To: <13B6017D-2A3D-4B45-A985-4A8269701178@comcast.net> References: <832b1b3957a0243ca37378a774effe537642eed3.camel@gmail.com> <40fd9a2f078cd6e87fedbc5f1e77baf8445a7356.camel@gmail.com> <02f4b13397f1d77db433ffc0c9401a6e66fb706d.camel@gmail.com> <09C9C641-02B2-4B83-B2C1-423DC573090B@comcast.net> <13B6017D-2A3D-4B45-A985-4A8269701178@comcast.net> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5-1.1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.7 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.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2022 12:37:18 -0000 Am Samstag, den 15.01.2022, 16:38 -0500 schrieb Paul Koning: > > On Jan 15, 2022, at 4:28 PM, Martin Sebor wrote: > > > > On 1/14/22 07:58, Paul Koning via Gcc wrote: > > > > On Jan 14, 2022, at 9:15 AM, Michael Matz via Gcc wrote: > > > > > > > > > ... > > > > But right now that's equivalent to making it observable, > > > > because we don't have any other terms than observable or > > > > undefined. As aluded to later you would have to > > > > introduce a new concept, something pseudo-observable, > > > > which you then started doing. So, see below. > > > I find it really hard to view this notion of doing work for UB with any favor. The way I see > > > it is that a program having UB is synonymous with "defective program" and for the compiler to > > > do extra work for these doesn't make much sense to me. > > > > This is also the official position of the C committee on record, > > but it's one that's now being challenged. "nonportable or erroneous" is the official position. > > > If the issue is specifically the handling of overflow traps, perhaps a better answer would be > > > to argue for language changes that manage such events explicitly rather than having them be > > > undefined behavior. Another (similar) option might be to choose a language in which this is > > > done. (Is Ada such a language? I don't remember.) > > > > A change to the language standard is only feasible if it doesn't > > overly constrain existing implementations. > > I was thinking that if a new feature is involved, rather than a new definition of behavior for > existing code, it wouldn't be a constraint on existing implementations (in the sense of "what the > compiler does for existing code written to the current rules"). In other words, suppose there was > a concept of "trapping operations" that could be enabled by some new mechanism in the program > text. If you use that, then you're asking the compiler to do more work and your code may get > slower or bigger. But if you don't, the existing rules apply and nothing bad happens (other than > that the compiler is somewhat larger and more complex due to the support for both cases). There are also different proposal for doing something like this, e.g. making certain undefined behaviour defined as trapping operations, either as a language variant or by default. But this is not my idea here, I want to limit the impact of UB on defective programs - accepting the reality that in the real world programs often have defects and any serious field of engineering needs to deal with this in a better way than to say "the ISO standard says no requirements - so you loose". Imagine an aurospace, biomedical, mechanical, or civil engineer saying: " It makes no sense to consider for the case where one part fails, this is then just then a defective airplane/CT scanner/car/bridge. Not worth spending extra resources on it, and a non-defective airplane might potentially be a little bit slower if we were to give you some guarantees in this failure case. First you need to show that this has no performance impact at all to anybody anywhere, then maybe we consider this." (When, at the same time there is quite substantial damage caused by defective C programs). I thought limiting the impact of UB on previous defined I/O would be a rather modest step towards more reliable software, considering that this is already the case for most I/O and it seems only some volatile accesses would need fixing (where I still do not see how this could affect performance anywhere where it actually matters). Martin