Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
In-Reply-To: <CAA2zVHraWtmmW1yFvVH+kUbih5wxiDLuM=wArnQanrWN9NF=Xw@mail.gmail.com>
References: <20180404093007.GI4082@hirez.programming.kicks-ass.net>
 <20180404191724.GF87376@google.com> <CAK8P3a1VFWYBymd3AeG1DwW++tCGsP9+vw6t8XSGHby2jmQPqA@mail.gmail.com>
 <20180404205848.GG87376@google.com> <CAK8P3a2tf3v6seq=OeyBakZ1ZXYzzL=tY=aHvKYv-GtD7sWeTA@mail.gmail.com>
 <20180404214639.GH87376@google.com> <CA+55aFwp8vRmf5p09nbunp6DfO+YvvWLj=FsU8KSW0ZwF6u80w@mail.gmail.com>
 <20180404221744.GI87376@google.com> <CA+55aFz+RcyPOTs3WM-FcwoQtgaotcBVqswma7qZ-3O2Fv__9Q@mail.gmail.com>
 <20180404233111.GJ87376@google.com> <20180405072017.GN4043@hirez.programming.kicks-ass.net>
 <CAA2zVHraWtmmW1yFvVH+kUbih5wxiDLuM=wArnQanrWN9NF=Xw@mail.gmail.com>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu, 5 Apr 2018 11:06:35 -0700
Message-ID: <CA+55aFwrZU-VPa9HShikNDkvuOvFXtO2vw8sDeRRTCU_hV7dWA@mail.gmail.com>
Subject: Re: [GIT PULL] x86/build changes for v4.17
To:     James Y Knight <jyknight@google.com>
Cc:     Peter Zijlstra <peterz@infradead.org>,
        Matthias Kaehlcke <mka@chromium.org>,
        Arnd Bergmann <arnd@arndb.de>, Ingo Molnar <mingo@kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Andrew Morton <akpm@linux-foundation.org>,
        Chandler Carruth <chandlerc@google.com>,
        Stephen Hines <srhines@google.com>,
        Nick Desaulniers <ndesaulniers@google.com>,
        Kees Cook <keescook@google.com>,
        Guenter Roeck <groeck@chromium.org>,
        Greg Hackmann <ghackmann@google.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

()() ha

On Thu, Apr 5, 2018 at 10:46 AM, James Y Knight <jyknight@google.com> wrote:
>
> GCC, however, mixes up the concept of a C "constant expression" with the
> results of running optimization passes such as inlining for its
> definition/implementation of __builtin_constant_p. Clang does not, and quite
> likely will not ever, do that.

Nothing has ever said that "__builtin_constant_p(x)" means "is x an
integer constant expression".

So there is no mix-up - or rather, *you* are the one mixing things up.

The gcc documentation says:

   "You can use the built-in function __builtin_constant_p to
determine if a value is known to be constant at compile time [...]"

Note that this has *nothing* to do with the concept of C "integer
constant expressions".

Yes, integer constant expressions obviously have values that are known
to be constant at compile time. But *other* things have values that
are known to be constant at compile time too.

In fact, we went through a long and painful thing exactly because we
wanted to get that "is this an ICE" value, and it turns out that the
best way to get that value has nothing to do with any gcc builtin at
all, but looks like this:

  /* Glory to Martin Uecker <Martin.Uecker@med.uni-goettingen.de> *
  #define __is_constexpr(x) \
        (sizeof(int) == sizeof(*(8 ? ((void *)((long)(x) * 0l)) : (int *)8)))

which is actually impressively subtle, and almost entirely standard C
(the only real dependency is "sizeof(void)", and it not being the same
as "sizeof(int)").

So honestly, if your "__builtin_constant_p(x)" is just "is 'x' just a
C integer constant expression", then your __builtin_constant_p() is
not only not compatible with gcc, it isn't really even all that
useful. We can do it by hand without using a builtin at all.

So if any clang person thinks that it's gcc that is mixing up
concepts, you guys need to re-consider. It is simply not true - and
*should* not be true - that __builtin_constant_ps anything to do with
the "C integer constant expression".

It needs to go inside inline functions. That's how we use it, and we
often have reasons why it practically has to. Macro argument
evaluation rules (and lack of type handling) makes it too painful to
use macros everywhere.

And even when the __builtin_constant_p itself is in a macro, the macro
is then often used by inline functions, so..

                  Linus