Messages in this thread | | | From | Nick Desaulniers <> | Date | Mon, 11 May 2020 13:18:15 -0700 | Subject | Re: [PATCH] x86: support i386 with Clang |
| |
On Mon, May 11, 2020 at 12:34 PM Brian Gerst <brgerst@gmail.com> wrote: > > On Mon, May 11, 2020 at 2:46 PM Nick Desaulniers > <ndesaulniers@google.com> wrote: > > > > On Mon, May 11, 2020 at 11:09 AM Brian Gerst <brgerst@gmail.com> wrote: > > > This looks like the same issue that we just discussed for bitops.h. > > > Add the "b" operand size modifier to force it to use the 8-bit > > > register names (and probably also needs the "w" modifier in the 16-bit > > > case). > > > > While it does feel familiar, it is slightly different. > > https://godbolt.org/z/Rme4Zg > > That case was both compilers validating the inline asm, yet generating > > assembly that the assembler would choke on. This case is validation > > in the front end failing. > > > long long ret; > > switch (sizeof(ret)) { > > case 1: > > asm ("movb $5, %0" : "=q" (ret)); > > break; > > case 8:; > > } > > So if the issue here is that the output variable type is long long, > what code is using a 64-bit percpu variable on a 32-bit kernel? Can > you give a specific file that fails to build with Clang? If Clang is > choking on it it may be silently miscompiling on GCC.
I'm not sure that's the case. Applying this patch, undoing the hunk in percpu_from_op() we get tons of errors. Looking at one:
kernel/events/core.c:8679:8: error: invalid output size for constraint '=q' ./include/linux/percpu-defs.h:446:2: note: expanded from macro '__this_cpu_read' raw_cpu_read(pcp); \ ^ ...
There's nothing wrong with this line, it's reading a percpu u64 into a local u64. The error comes from validating the inline asm in the dead branch. -- Thanks, ~Nick Desaulniers
| |