From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 13B7FC48BCD for ; Wed, 9 Jun 2021 17:32:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DCB9B613D3 for ; Wed, 9 Jun 2021 17:32:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230293AbhFIReZ (ORCPT ); Wed, 9 Jun 2021 13:34:25 -0400 Received: from mail-lj1-f182.google.com ([209.85.208.182]:39841 "EHLO mail-lj1-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229792AbhFIReZ (ORCPT ); Wed, 9 Jun 2021 13:34:25 -0400 Received: by mail-lj1-f182.google.com with SMTP id c11so871431ljd.6 for ; Wed, 09 Jun 2021 10:32:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0MqGGesoGQuVnrKk3vQolI1WP+Da/YReiXXu0+F/PoI=; b=oqrytQIghczJbaoOnbzSWOJS9CfMcjLc6HQWxzBmqdZkwma71siufdGQgIdRW/JXvf aQ3ZQl1ZJqsCjf2non1uW8mv9R3ZZakVZGUc6rnDKTP49pOI7yiMJkZ17lpteOR7W5Dk 0BwHWXG2hq4XKRcsmjqTqkbij0Db7HHOsbZyl/8CK3SKIsT4wLExXGcYUzFTrNOWQd2Z ATAPBdQQ7QUiQgT1RPAmrira+fA/LePyUxU5OebV2djq5Akg1bCRIQu/FREs/CUxO6s4 /xqfs/mpZU90BtBFalot+yiDh2ptEj6Qlc3StsLT1Ydf33hnjNPBmgzf+blADrY/8kcC x44A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0MqGGesoGQuVnrKk3vQolI1WP+Da/YReiXXu0+F/PoI=; b=ZwVvlhgQA+7jk1/G+Gg6MUkfE6obeUEDOlx6NalYoSO6ifgVqwvvW6/JRT8KBvexU2 GySUj9xdQCfoBvYk18RJ9obS0+c+uurIQKQDCciWV3nZlXcZ+1Nd0zc8JtcQy+IFgJfo RW5KIfbelBWdlMsunhlf1dOjlwLB6K+2kUrqaZ7cuLIqLLx6zpBbLPOr6NCEuIxiapKV qrmKEEpBhENe1x9x7L1mZOHhICRnDOKDPFK1xh+SVOa41wR7onFqpiBvOrhlj31SRmSg OW0dIoxON29o41SKD3H9Mkdq+ZiRNHYZAP4dnGUGLaUnZAfYc85O0Iv/SQ2YUoX2tKX8 AFqg== X-Gm-Message-State: AOAM532PV7raZorHFnabpXjxHMknWmj57gZAmAM52QzeuGx0NJMee/3M eN5wekvxaYP2Kj9sjP+y5gqghTdW/rGlVUow05MdtA== X-Google-Smtp-Source: ABdhPJzZP34kpS/OBBYpUc74IfvBrOBaQi8ta6LeCvRlqhhJBcG+k+md04w3oN828TXL0lj9FHnQWanfCb8lNJHvRjk= X-Received: by 2002:a2e:3c06:: with SMTP id j6mr708333lja.495.1623259884911; Wed, 09 Jun 2021 10:31:24 -0700 (PDT) MIME-Version: 1.0 References: <20210607152806.GS4397@paulmck-ThinkPad-P17-Gen-1> <20210608152851.GX18427@gate.crashing.org> <20210609153133.GF18427@gate.crashing.org> <20210609171419.GI18427@gate.crashing.org> In-Reply-To: <20210609171419.GI18427@gate.crashing.org> From: Nick Desaulniers Date: Wed, 9 Jun 2021 10:31:13 -0700 Message-ID: Subject: Re: [RFC] LKMM: Add volatile_if() To: Segher Boessenkool Cc: Marco Elver , Peter Zijlstra , "Paul E. McKenney" , Alexander Monakov , Linus Torvalds , Jakub Jelinek , Alan Stern , Will Deacon , Andrea Parri , Boqun Feng , Nick Piggin , David Howells , Jade Alglave , Luc Maranget , Akira Yokosawa , Linux Kernel Mailing List , linux-toolchains@vger.kernel.org, linux-arch Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-arch@vger.kernel.org On Wed, Jun 9, 2021 at 10:20 AM Segher Boessenkool wrote: > > On Wed, Jun 09, 2021 at 06:13:00PM +0200, Marco Elver wrote: > > On Wed, 9 Jun 2021 at 17:33, Segher Boessenkool > > wrote: > > [...] > > > > An alternative design would be to use a statement attribute to only > > > > enforce (C) ("__attribute__((mustcontrol))" ?). > > > > > > Statement attributes only exist for empty statements. It is unclear how > > > (and if!) we could support it for general statements. > > > > Statement attributes can apply to anything -- Clang has had them apply > > to non-empty statements for a while. > > First off, it is not GCC's problem if LLVM decides to use a GCC > extension in some non-compatible way. Reminds me of https://lore.kernel.org/lkml/CAHk-=whu19Du_rZ-zBtGsXAB-Qo7NtoJjQjd-Sa9OB5u1Cq_Zw@mail.gmail.com/ -- Thanks, ~Nick Desaulniers