[llvmlinux] clang fails on linux-next since commit 8bf705d13039

[Sedat Dilek]

On Sun, May 6, 2018 at 12:44 PM, Dmitry Vyukov <dvyukov at google.com> wrote:
> On Sun, May 6, 2018 at 12:41 PM,  <sedat.dilek at gmail.com> wrote:
>>
>>
>> Am Montag, 19. März 2018 18:29:04 UTC+1 schrieb Matthias Kaehlcke:
>>>
>>> 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 <lukas.... at gmail.com>
>>> > 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.
>>
>>
>> When forcing to build with '-O0' instead of default '-O2' I can see this...
>>
>>  ./include/asm-generic/atomic-instrumented.h:364:3: error: array size is
>> negative
>>                 BUILD_BUG_ON(sizeof(unsigned long) != 8);
>>                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> ./include/linux/build_bug.h:66:52: note: expanded from macro 'BUILD_BUG_ON'
>> #define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
>>                                                    ^~~~~~~~~~~~~~~~~~~
>
>
> With clang or gcc?

clang version 7 (svn330207) and binutils/ld 2.30.

- Sedat -