From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) by sourceware.org (Postfix) with ESMTPS id 3BF2F3858D28 for ; Tue, 18 Jan 2022 08:31:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3BF2F3858D28 Received: by mail-ed1-x530.google.com with SMTP id 30so76167327edv.3 for ; Tue, 18 Jan 2022 00:31:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=itXfkK1Xp/wfXjzgfEAsjppAGkvgsoSQQKf1p5RkBJ0=; b=pIAoC8AxYM//qjD+ugxA5CEDSjt6P1pOOKCuuF++yPBcC1NE/W+q+mxWmJ3Il3NfIm U//wNoxSxbHCHKw2NJfCwLZ2wr/45A50Qi9mU04PkdPx425HECPreLS+ropvhjoqEaNs KUOKVP+BFxrPvcxowO7X79uHKKIImSmCqVZUxy4hbGSU+dmlTi+ENpcUaDUR6oSQ8jIt 00+iqwBhBiDu5Y5NA2vP5y7WbqwgJOMbum6atNNbRg+X4YWaeGygoNWTt5tb4S7JRKXH nmKkbHGa3qtRaeDeV6NNegeBfsHyIIW6cTsMWDsqs58YqeI8eAY97nMDggEx88+LgBxJ QCKg== X-Gm-Message-State: AOAM532ZKMNBti9cCESf2LiD09eW/T7XKEh+9bXep3lsh6C6R7mNp5VC 4WBb8idEWV4V5KjXvGKRavEB+nOqBWIqrqNdzFc= X-Google-Smtp-Source: ABdhPJzzt/G8sNp+qfo8tiQrnalMiwsYGU//ZJ/P2VkgBmRF7HarWGoh0tqD0K/ZjptDHz1QyA/6AjVMwHwFtbfF7AY= X-Received: by 2002:a50:fc16:: with SMTP id i22mr11569416edr.345.1642494691152; Tue, 18 Jan 2022 00:31:31 -0800 (PST) MIME-Version: 1.0 References: <832b1b3957a0243ca37378a774effe537642eed3.camel@gmail.com> <40fd9a2f078cd6e87fedbc5f1e77baf8445a7356.camel@gmail.com> <02f4b13397f1d77db433ffc0c9401a6e66fb706d.camel@gmail.com> <7ff97dbb30d440aeed9e338847af41dd55cd3ed9.camel@gmail.com> In-Reply-To: From: Richard Biener Date: Tue, 18 Jan 2022 09:31:19 +0100 Message-ID: Subject: Re: reordering of trapping operations and volatile To: Michael Matz Cc: Martin Uecker , "gcc@gcc.gnu.org" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.2 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: Tue, 18 Jan 2022 08:31:33 -0000 On Mon, Jan 17, 2022 at 3:11 PM Michael Matz via Gcc wrote: > > Hello, > > On Sat, 15 Jan 2022, Martin Uecker wrote: > > > > 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. > > But you seem to ignore whatever we say in this thread. There are now > multiple examples that demonstrate problems with your proposal as imagined > (for lack of a _concrete_ proposal with wording from you), problems that > don't involve volatile at all. They all stem from the fact that you order > UB with respect to all side effects (because you haven't said how you want > to avoid such total ordering with all side effects). > > As I said upthread: you need to define a concept of time at whose > granularity you want to limit the effects of UB, and the borders of each > time step can't simply be (all) the existing side effects. Then you need > to have wording of what it means for UB to occur within such time step, in > particular if multiple UB happens within one (for best results it should > simply be UB, not individual instances of different UBs). > > If you look at the C++ proposal (thanks Jonathan) I think you will find > that if you replace 'std::observable' with 'sequence point containing a > volatile access' that you basically end up with what you wanted. The > crucial point being that the time steps (epochs in that proposal) aren't > defined by all side effects but by a specific and explicit thing only (new > function in the proposal, volatile accesses in an alternative). > > FWIW: I think for a new language feature reusing volatile accesses as the > clock ticks are the worse choice: if you intend that feature to be used > for writing safer programs (a reasonable thing) I think being explicit and > at the same time null-overhead is better (i.e. a new internal > function/keyword/builtin, specified to have no effects except moving the > clock forward). volatile accesses obviously already exist and hence are > easier to integrate into the standard, but in a given new/safe program, > whenever you see a volatile access you would always need to ask 'is thise > for clock ticks, or is it a "real" volatile access for memmap IO'. I guess Martin want's to have accesses to volatiles handled the same as function calls where we do not know whether the function call will return or terminate the program normally. As if the volatile access could have a similar effect (it might actually reboot the machine or so - but of course that and anything else I can imagine would be far from "normal termination of the program"). That's technically possible to implement with a yet unknown amount of work. Btw, I'm not sure we all agree that (*) in the following program doesn't make it invoke UB and thus the compiler is not free to re-order the offending statement to before the exit (0) call. Thus UB is only "realized" if a stmt containing it is executed in the abstract machine. int main() { exit(0); 1 / 0; /// (*) } > > > Ciao, > Michael.