From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) by sourceware.org (Postfix) with ESMTPS id AA50E38708CB; Wed, 4 Nov 2020 08:53:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org AA50E38708CB Received: by mail-qk1-x735.google.com with SMTP id i21so17661304qka.12; Wed, 04 Nov 2020 00:53:06 -0800 (PST) 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=P5MSo1usdQXmpwrZ5ZpVN3GIJz3l85ktzu73mv9Y7gQ=; b=oOv6G9xx4I2aSTDodXgr7X6c86k3QbAHwZZK75pGaN0tje46z0057PyVUdiToS5ZKm 158lYuHV/oOua0QWlKsyfW9q1Xp6Xra58yLwjD2SshWyVRFeeU2nnV8xlvOlKnETivIC 9UhiS2zzwSLWcuUsWlIPUWG3WvYC6WH3wslc3q/3NAeQ4qEJ7vghEVazm1RFES8UALng qErw8OpSJhvnDYZQ5TCQskKUYyd6NBU3kr1jkr1DnnzqO9jBDqv+YP3KRyCdU6wi5R9t R1gCcBs3yqRncnWS1tEYQkucDMMk6z9bGsAqiPMj34l7T4XOic0612SoxQ1a5ck362iF p7+A== X-Gm-Message-State: AOAM532W43HXZfm+bj8VoyWI6fDZAw71RlWVzy7/BnvpqTvGgniGUi2e tZoQ4dxwxDdrgpydydN4Hx+1JcP6Wd0qwWruZMU= X-Google-Smtp-Source: ABdhPJzdb49/usHw8j8rxglez8SSmDu9hJC8lhU1CqHtDq9yDzGqp9LNePywxEC2YaA7/rZBWLgvu7h5U4JrW0/DlrM= X-Received: by 2002:a05:620a:951:: with SMTP id w17mr19427756qkw.224.1604479986360; Wed, 04 Nov 2020 00:53:06 -0800 (PST) MIME-Version: 1.0 References: <20201029145934.GA2368280@redhat.com> <05082673-9d71-116e-2ad8-d86e8b96e87f@redhat.com> <20201103222525.GZ503596@redhat.com> <51c2aa0b-7a1c-8174-6492-fdee634ef8e0@redhat.com> In-Reply-To: <51c2aa0b-7a1c-8174-6492-fdee634ef8e0@redhat.com> From: Ville Voutilainen Date: Wed, 4 Nov 2020 10:52:55 +0200 Message-ID: Subject: Re: [committed] libstdc++: Allow Lemire's algorithm to be used in more cases To: Stephan Bergmann Cc: Jonathan Wakely , "libstdc++" , gcc-patches List Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3.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.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libstdc++@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libstdc++ mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 08:53:07 -0000 On Wed, 4 Nov 2020 at 10:46, Stephan Bergmann via Libstdc++ wrote: > To me it looks like it boils down to disagreement between g++ and > clang++ over > > > struct S { static constexpr int f() { return 0; } }; > > void f(S & s) { static_assert(s.f(), ""); } > > where I think Clang might be right in rejecting it based on [expr.const] > "An expression e is a core constant expression unless [...] an > id-expression that refers to a variable or data member of reference type > unless the reference has a preceding initialization [...]" There's more to it than that. It's a disagreement over [expr.ref]/1. For a static member call, gcc just plain doesn't evaluate the s in s.f(). But [expr.ref]/1 says it's evaluated, and since it's not a constant expression, clang rejects it, and gcc accepts it. That's why your fix works; it removes the use of the otherwise-mostly-ignored object expression for a call to a static member function. So, I think gcc is accepting-invalid here, and we should just apply the fix you suggested.