From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f200.google.com (mail-pf0-f200.google.com [209.85.192.200]) by kanga.kvack.org (Postfix) with ESMTP id 5D6726B000C for ; Mon, 19 Mar 2018 14:16:13 -0400 (EDT) Received: by mail-pf0-f200.google.com with SMTP id u68so10022679pfk.8 for ; Mon, 19 Mar 2018 11:16:13 -0700 (PDT) Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id e11sor166392pgr.121.2018.03.19.11.16.12 for (Google Transport Security); Mon, 19 Mar 2018 11:16:12 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20180319175457.GC37438@google.com> References: <20180319172902.GB37438@google.com> <20180319175457.GC37438@google.com> From: Dmitry Vyukov Date: Mon, 19 Mar 2018 19:15:50 +0100 Message-ID: Subject: Re: clang fails on linux-next since commit 8bf705d13039 Content-Type: text/plain; charset="UTF-8" Sender: owner-linux-mm@kvack.org List-ID: To: Matthias Kaehlcke Cc: Lukas Bulwahn , Nick Desaulniers , Greg Hackmann , Luis Lozano , Michael Davidson , Sami Tolvanen , Paul Lawrence , Ingo Molnar , Linux-MM , kasan-dev , llvmlinux@lists.linuxfoundation.org, sil2review@lists.osadl.org, Manoj Gupta , Stephen Hines On Mon, Mar 19, 2018 at 6:54 PM, Matthias Kaehlcke wrote: > El Mon, Mar 19, 2018 at 06:39:32PM +0100 Dmitry Vyukov ha dit: > >> On Mon, Mar 19, 2018 at 6:29 PM, Matthias Kaehlcke wrote: >> > El Mon, Mar 19, 2018 at 09:43:25AM +0300 Dmitry Vyukov ha dit: >> > >> >> On Sat, Mar 17, 2018 at 2:13 PM, Lukas Bulwahn wrote: >> >> > Hi Dmitry, hi Ingo, >> >> > >> >> > since commit 8bf705d13039 ("locking/atomic/x86: Switch atomic.h to use atomic-instrumented.h") >> >> > on linux-next (tested and bisected from tag next-20180316), compiling the >> >> > kernel with clang fails with: >> >> > >> >> > In file included from arch/x86/entry/vdso/vdso32/vclock_gettime.c:33: >> >> > In file included from arch/x86/entry/vdso/vdso32/../vclock_gettime.c:15: >> >> > In file included from ./arch/x86/include/asm/vgtod.h:6: >> >> > In file included from ./include/linux/clocksource.h:13: >> >> > In file included from ./include/linux/timex.h:56: >> >> > In file included from ./include/uapi/linux/timex.h:56: >> >> > In file included from ./include/linux/time.h:6: >> >> > In file included from ./include/linux/seqlock.h:36: >> >> > In file included from ./include/linux/spinlock.h:51: >> >> > In file included from ./include/linux/preempt.h:81: >> >> > In file included from ./arch/x86/include/asm/preempt.h:7: >> >> > In file included from ./include/linux/thread_info.h:38: >> >> > In file included from ./arch/x86/include/asm/thread_info.h:53: >> >> > In file included from ./arch/x86/include/asm/cpufeature.h:5: >> >> > In file included from ./arch/x86/include/asm/processor.h:21: >> >> > In file included from ./arch/x86/include/asm/msr.h:67: >> >> > In file included from ./arch/x86/include/asm/atomic.h:279: >> >> > ./include/asm-generic/atomic-instrumented.h:295:10: error: invalid output size for constraint '=a' >> >> > return arch_cmpxchg((u64 *)ptr, (u64)old, (u64)new); >> >> > ^ >> >> > ./arch/x86/include/asm/cmpxchg.h:149:2: note: expanded from macro 'arch_cmpxchg' >> >> > __cmpxchg(ptr, old, new, sizeof(*(ptr))) >> >> > ^ >> >> > ./arch/x86/include/asm/cmpxchg.h:134:2: note: expanded from macro '__cmpxchg' >> >> > __raw_cmpxchg((ptr), (old), (new), (size), LOCK_PREFIX) >> >> > ^ >> >> > ./arch/x86/include/asm/cmpxchg.h:95:17: note: expanded from macro '__raw_cmpxchg' >> >> > : "=a" (__ret), "+m" (*__ptr) \ >> >> > ^ >> >> > >> >> > (... and some more similar and closely related errors) >> >> >> >> >> >> Thanks for reporting, Lukas. >> >> >> >> +more people who are more aware of the current state of clang for kernel. >> >> >> >> Are there are known issues in '=a' constraint handling between gcc and >> >> clang? Is there a recommended way to resolve them? >> >> >> >> Also, Lukas what's your version of clang? Potentially there are some >> >> fixes for kernel in the very latest versions of clang. >> > >> > My impression is that the problem only occurs in code built for >> > 32-bit (like arch/x86/entry/vdso/vdso32/*), where the use of a 64-bit >> > address with a '=a' constraint is indeed invalid. I think the 'root >> > cause' is that clang parses unreachable code before it discards it: >> > >> > static __always_inline unsigned long >> > cmpxchg_local_size(volatile void *ptr, unsigned long old, unsigned long new, >> > int size) >> > { >> > ... >> > switch (size) { >> > ... >> > case 8: >> > BUILD_BUG_ON(sizeof(unsigned long) != 8); >> > return arch_cmpxchg_local((u64 *)ptr, (u64)old, (u64)new); >> > } >> > ... >> > } >> > >> > For 32-bit builds size is 4 and the code in the 'offending' branch is >> > unreachable, however clang still parses it. >> > >> > d135b8b5060e ("arm64: uaccess: suppress spurious clang warning") fixes >> > a similar issue. >> >> >> Thanks! >> >> Do I understand it correctly that this is being fixed in clang? > > Personally I am not aware of any development on that side, however I'm > not an LLVM dev. This looks like something that will hit us again and again if we don't fix this in clang.