From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) by sourceware.org (Postfix) with ESMTPS id D25A63858D35 for ; Sat, 15 Jan 2022 18:49:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D25A63858D35 Received: by mail-wm1-x32a.google.com with SMTP id c2so6797157wml.1 for ; Sat, 15 Jan 2022 10:49:00 -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=kJwIoyBFD1Xq3H5JfJ31CUM+Yo2AWc3ht/Q+qjS9fQw=; b=nMcsnsQ71chE4fKC3FAEIx8XjNzHDL8vU1TnuY0E5GzwRGG6N44fIOARqK52jKmut6 V5lsELlw8DpV4vQjiaMmt3zVjdXNTaOJqwcM/oOBm+91PPAyeHvhSZLkpBmwZ/2VhG/+ WMgcep8Vv90hVQPEzNzl3gEzc0xdQi8DCCuRocAJqhJyMw5+fPgMMEGB80idhFvybqgm cZzJMQJMk1kM8JID2WKvpQ2x8elij8jgDoEAcOgW1Uimwe+zXi2VU2TbkChr0YJjOsPn BiNyMb/uZGaw71Ls1CGmcs8tgvKwd1/yiHI41INtg5KHosiaDzYw1ycMoR9wBeuM4SC8 DarA== X-Gm-Message-State: AOAM530oX3hqWZrL3jhgPBp+VgMtKwsrslRRVTGqehZS/Vz+324j22Ls DQd91k+M15vGNN0yJQjTh0M= X-Google-Smtp-Source: ABdhPJyCXvKY6uufRYnze/0crde2NkAoU94aacJi+NtZPwzAorCdAINbFYoyV95+c28+C5qbvmFDrw== X-Received: by 2002:a05:600c:354f:: with SMTP id i15mr1234618wmq.139.1642272539706; Sat, 15 Jan 2022 10:48:59 -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 f5sm8644291wmf.47.2022.01.15.10.48.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 15 Jan 2022 10:48:59 -0800 (PST) Message-ID: <7ff97dbb30d440aeed9e338847af41dd55cd3ed9.camel@gmail.com> Subject: Re: reordering of trapping operations and volatile From: Martin Uecker To: Jonathan Wakely Cc: Michael Matz , "gcc@gcc.gnu.org" Date: Sat, 15 Jan 2022 19:48:57 +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=-1.8 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: Sat, 15 Jan 2022 18:49:02 -0000 Am Samstag, den 15.01.2022, 16:33 +0000 schrieb Jonathan Wakely: > On Sat, 15 Jan 2022, 09:00 Martin Uecker, wrote: > > > Am Freitag, den 14.01.2022, 19:54 +0000 schrieb Jonathan Wakely: > > > On Fri, 14 Jan 2022, 14:17 Michael Matz via Gcc, > > wrote: > > > > Hello, > > > > > > > > On Thu, 13 Jan 2022, Martin Uecker wrote: > > > > > > > > > > > > Handling all volatile accesses in the very same way would be > > > > > > > > possible but quite some work I don't see much value in. > > > > > > > > > > > > > > I see some value. > > > > > > > > > > > > > > But an alternative could be to remove volatile > > > > > > > from the observable behavior in the standard > > > > > > > or make it implementation-defined whether it > > > > > > > is observable or not. > > > > > > > > > > > > But you are actually arguing for making UB be observable > > > > > > > > > > No, I am arguing for UB not to have the power > > > > > to go back in time and change previous defined > > > > > observable behavior. > > > > > > > > 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. > > > > > > > > > > That's > > > > > > much different from making volatile not be > > > > > > observable anymore (which obviously would > > > > > > be a bad idea), and is also much harder to > > > > > > > > > > I tend to agree that volatile should be > > > > > considered observable. But volatile is > > > > > a bit implementation-defined anyway, so this > > > > > would be a compromise so that implementations > > > > > do not have to make all the implied changes > > > > > if we revise the meaning of UB. > > > > > > > > Using volatile accesses for memory mapped IO is a much stronger > > use-case > > > > than your wish of using volatile accesses to block moving of UB as a > > > > debugging aid, and the former absolutely needs some guarantees, so I > > don't > > > > think it would be a compromise at all. Mkaing volatile not be > > observable > > > > would break the C language. > > > > > > > > > > Well, what you _actually_ want is an implied > > > > > > dependency between some UB and volatile accesses > > > > > > (and _only_ those, not e.g. with other UB), and the > > > > > > difficulty now is to define "some" and to create > > > > > > the dependency without making that specific UB > > > > > > to be properly observable. > > > > > > > > > > Yes, this is what I actually want. > > > > > > > > > > > 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". > > > > > > > > But doing that would have very far reaching consequences, as already > > > > stated in this thread. 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_. > > > > > > > > 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. > > > > > > > > > > The C++ committee is currently considering this paper: > > > > > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p1494r2.html > > > > > > I think this explicit barrier-like solution is better than trying to use > > > volatile accesses to achieve something similar. > > > > Can you explain why? To me a solution which would make > > it "just work" (and also fixes existing code) seems > > better than letting programmers jump through even > > more hoops, especially if only difficult corner > > cases are affected. > > > > Because it interferes with existing optimisations. An explicit checkpoint > has a clear meaning. Using every volatile access that way will hurt > performance of code that doesn't require that behaviour for correctness. This is why I would like to understand better what real use cases of performance sensitive code actually make use of volatile and are negatively affected. Then one could discuss the tradeoffs. Martin