From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) by sourceware.org (Postfix) with ESMTPS id 338803858D35 for ; Fri, 14 Jan 2022 15:46:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 338803858D35 Received: by mail-wm1-x331.google.com with SMTP id w26so6946484wmi.0 for ; Fri, 14 Jan 2022 07:46:08 -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=+mlXLc35Z8J2E42YB55kwP1Jen27+KDKCaihEIZobfs=; b=yPa5RfyItudR9va/p642T591RhOYLrTYayuSDlIIbIq/iG6uWOlQ2+e/Ai5eTv1bQL 7LYOXsBAwEWJ2+GfizQFim78EVKXcH481NXVnOPRDA277nvuIFNATnXte7rEDUKofYQJ bufduJ4CDTQ4ZE7N3sQ+pZhw/B0UUAFl0xwM46+alpb5sUW83Yy8QeF7WkD+CGs3Dp0z 7+iS3uy5XcCWLXYgKpUIpMIuUnfAVxhwLM0J9IGivkI7Epi6MhBsMjiuDmwdZh9u4McS ndi0p3T1xTnvSYR4S2Y3Poba+9193QPckmTvL0agSWxKcW/2M11ZnYPj7asBTx8HnQxZ WkyQ== X-Gm-Message-State: AOAM533MShSof/gCRUMmoDZVGwRV3n6/ovLlKXJFDm4o5EYm9nbA8lLe NQoEMzeNOeywgRcg7wCmyq4= X-Google-Smtp-Source: ABdhPJya6Bp5NsT/pp7+RcJrc5oB789dDkZqAC9cpJvr/d8TFhXYPlyWBTE26z9VDbwRDfxB+KUQrA== X-Received: by 2002:a05:600c:34d2:: with SMTP id d18mr8963918wmq.71.1642175167108; Fri, 14 Jan 2022 07:46:07 -0800 (PST) Received: from fbmtpc92.tugraz.at (fbmtpc92.tugraz.at. [129.27.144.111]) by smtp.gmail.com with ESMTPSA id c11sm12412629wmq.48.2022.01.14.07.46.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 14 Jan 2022 07:46:06 -0800 (PST) Message-ID: <58d8f916f96fc8f371c1f0a4db05b944d23ac10d.camel@gmail.com> Subject: Re: reordering of trapping operations and volatile From: Martin Uecker To: Michael Matz Cc: Richard Biener , "gcc@gcc.gnu.org" Date: Fri, 14 Jan 2022 16:46:05 +0100 In-Reply-To: References: <832b1b3957a0243ca37378a774effe537642eed3.camel@gmail.com> <40fd9a2f078cd6e87fedbc5f1e77baf8445a7356.camel@gmail.com> <02f4b13397f1d77db433ffc0c9401a6e66fb706d.camel@gmail.com> 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=-2.1 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: Fri, 14 Jan 2022 15:46:09 -0000 Am Freitag, den 14.01.2022, 14:15 +0000 schrieb Michael Matz: > Hello, > > On Thu, 13 Jan 2022, Martin Uecker wrote: ... > > > I think to define this > > > all rigorously seems futile (you need a new > > > category between observable and UB), so it comes > > > down to compiler QoI on a case by case basis. > > > > We would simply change UB to mean "arbitrary > > behavior at the point of time the erraneous > > construct is encountered at run-time" and > > not "the complete program is invalid all > > together". I see no problem in specifying this > > (even in a formally precise way) > > First you need to define "point in time", a concept which doesn't exist > yet in C. The obvious choice is of course observable behaviour in the > execution environment and its specified ordering from the abstract > machine, as clarified via sequence points. With that your "at the point > in time" becomes something like "after all side effects of previous > sequence point, but strictly before all side effects of next sequence > point". Yes, all observable side effects sequenced before the erroneous operation should be preserved. We also need to consider multi-threading (happens-before) But I do not think there is any need to discuss the precise wording now. > But doing that would have very far reaching consequences, as already > stated in this thread. We already agreed that UB already works like this relative to every function call. So why do you think this could have far reaching consequences when we also require this for volatile accesses - considering that volatile accesses are not nearly as common as function calls, and often already limit optimization? We had a lot of trouble even finding examples where compiler currently exhibit behavior that would need to change. > The above would basically make undefined behaviour > be reliably countable, and all implementations would need to produce the > same counts of UB. That in turn disables many code movement and > commonization transformations, e.g. this: > > int a = ..., b = ...; > int x = a + b; > int y = a + b; > > can't be transformed into "y = x = a + b" anymore, because the addition > _might_ overflow, and if it does you have two UBs originally but would > have one UB after. I know that you don't want to inhibit this or similar > transformations, but that would be the result of making UB countable, > which is the result of forcing UB to happen at specific points in time. > So, I continue to see problems in precisely specifying what you want, _but > not more_. Don't worry, I do not want to make UB observable or countable. Your example does not contain observable behavior, so would be unaffected. > I think all models in which you order the happening of UB with respect to > existing side effects (per abstract machine, so it includes modification > of objects!) have this same problem, it always becomes a side effect > itself (one where you don't specify what actually happens, but a side > effect nontheless) and hence becomes observable. I don't think so. The standard always only defines behavior. Here, would only guarantee that observable behavior before a specific time point stays defined. For this we do not make UB observable or countable because the statements we make is not about the UB, but about the defined behavior before. Martin