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: <20180404191724.GF87376@google.com>
References: <20180402095033.nfzcrmxvpm46dhbl@gmail.com> <CA+55aFzV8L-uv9706ryJ2mP9VGBuzqFVPu1cgYY+sZAtDAroqg@mail.gmail.com>
 <20180403085904.GY4082@hirez.programming.kicks-ass.net> <20180403095118.rpf7tj577dppvx7d@gmail.com>
 <20180403180658.GE87376@google.com> <20180404093007.GI4082@hirez.programming.kicks-ass.net>
 <20180404191724.GF87376@google.com>
From:   Arnd Bergmann <arnd@arndb.de>
Date:   Wed, 4 Apr 2018 22:33:19 +0200
Message-ID: <CAK8P3a1VFWYBymd3AeG1DwW++tCGsP9+vw6t8XSGHby2jmQPqA@mail.gmail.com>
Subject: Re: [GIT PULL] x86/build changes for v4.17
To:     Matthias Kaehlcke <mka@chromium.org>
Cc:     Peter Zijlstra <peterz@infradead.org>,
        Ingo Molnar <mingo@kernel.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Andrew Morton <akpm@linux-foundation.org>,
        James Y Knight <jyknight@google.com>,
        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

On Wed, Apr 4, 2018 at 9:17 PM, Matthias Kaehlcke <mka@chromium.org> wrote:
> El Wed, Apr 04, 2018 at 11:30:07AM +0200 Peter Zijlstra ha dit:
>
>> On Tue, Apr 03, 2018 at 11:06:58AM -0700, Matthias Kaehlcke wrote:
>>
>> > Yes, Chrome OS R67 (currently dev, soon beta) will ship a kernel built
>> > with Clang for multiple x86 Chromebooks.
>>
>> But there are still _known_ miscompilations....
>
> Our compiler team is looking into this (missing option
> -fno-delete-null-pointer-checks)

Do you know if anyone is looking into __builtin_constant_p()
optimization as well? We have a lot of uses of this gcc feature
in the kernel, and if I remember correctly, clang implements
this by basically always returning false for the cases we
are interested in.

In most cases, this is used to implement a fast-path for a helper
function, so not doing it the same way as gcc just results in
slower execution, but I assume we also have code that behaves
differently on clang compared to gcc because of this.

        Arnd