Re: clang fails on linux-next since commit 8bf705d13039

[Dmitry Vyukov <dvyukov@google.com>]

On Sun, May 6, 2018 at 12:48 PM, Sedat Dilek <sedat.dilek@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....@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.

Nick, will this also be fixed as part of asm constraint checking fix?