From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) by sourceware.org (Postfix) with ESMTPS id 5C8C0385781B for ; Thu, 13 Jan 2022 19:17:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5C8C0385781B Received: by mail-wr1-x436.google.com with SMTP id s1so11948354wra.6 for ; Thu, 13 Jan 2022 11:17:27 -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=BHMbkJNJq/SGnf+3Q0a88IcxRXrzjJZuI0n7vygP5nk=; b=pbNKJrHt0kPKwk3z55uzx4rkwUuJGCuEMog3wkw7F6Ho5vLoIxL3Q+P5rywta6oJ+Y QbeQMfELWuhuSGDeULM+4XipPeusUXpE/mzd3KTr+TbhhVZ/nFTExkok0rUYAwgiJSTD nJRtpMCj/K3Hc483erd5EdTzQv+gP5yHGejH1gomtxGnS+i1WDRz+pFBmEF4481ABe+2 AApUFxhud4R5y9rpPdIGaC2yOeVsSn/hYPhWZtJkeVK4Y1mZgXroEfcZdORAugkodVY4 vLF5vA8M4hlm2TVG61oPzf1zqqWSpEKeQzWkJEpP7QuA1wNbl7X7uwU+Kyadmxn2lB7v l2BA== X-Gm-Message-State: AOAM533D8PmVURs3pWoDrN54Urhm2SF5FmdGVXReL7FCHE64MNrIS36u rr2sXSAgmnElv9ScwUAAlGY= X-Google-Smtp-Source: ABdhPJzDFKQziXuhG3vAZ+M41LdLaidffW7dyJTgknMhh3yon27mq1xtE8cOy2eZtI0PpWaQOGbkvQ== X-Received: by 2002:a5d:4b87:: with SMTP id b7mr5176384wrt.327.1642101446189; Thu, 13 Jan 2022 11:17:26 -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 j11sm4661001wmq.23.2022.01.13.11.17.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 13 Jan 2022 11:17:25 -0800 (PST) Message-ID: Subject: Re: reordering of trapping operations and volatile From: Martin Uecker To: Michael Matz Cc: Richard Biener , "gcc@gcc.gnu.org" Date: Thu, 13 Jan 2022 20:17:24 +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: Thu, 13 Jan 2022 19:17:28 -0000 Am Donnerstag, den 13.01.2022, 16:45 +0000 schrieb Michael Matz: > Hello, > > On Tue, 11 Jan 2022, Martin Uecker via Gcc 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. The reason is that it makes it impossible to give any guarantees about partial executions of a program e.g. that a transaction completed or privileges were dropped or a log message went out to the log server), when there is the possibility that later there could be some UB in the program. Making UB observable would be even stronger. For example I do not mind a compiler sinking a division by zero across other observable behavior, which would not be possible if we consider the trap to be observable. > (which then directly implies an ordering > with respect to volatile accesses). Yes, it would, but "no time-travel" only implies some weaker constraints for UB and only if it actually traps or could affect observable behavior in other ways. For I/O using function calls these constraints are already fulfilled. > 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. > do, it's the nature of undefined behaviour > to be hard to define :) > > 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) Martin