El Thu, Mar 01, 2018 at 10:31:02AM +0000 Dave Martin ha dit: > On Thu, Mar 01, 2018 at 09:45:24AM +0000, Robin Murphy wrote: > > Hi Andrey, > > > > On 28/02/18 19:32, Andrey Konovalov wrote: > > >Hi Marc! > > > > > >I've tried to pull in new upstream commits and the kernel build > > >started failing for me with the following errors (see below). > > > > > >It seems that the reason is your commit "arm64: Add > > >ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support". It seems that Clang > > >doesn't like 32 bits registers being used in 64 bits build. > > > > I'd say this is really a bug in Clang. Architecturally, the register in > > AArch64 state is still named "r0"; "x0"/"w0" are assembler operands which > > additionally encode the size of the corresponding *access* to r0. > > > > I note that GCC's documentation on register variables[1] does just say "the > > name of the register", which implies this code is not incorrect. Given that > > Clang already likes to infer the operand size from the argument type in > > actual inline asms, it seems funny that its register allocator should care > > in this non-instruction context. > > +1 > > rN is perfectly reasonable here and has always been supported by GCC for > AArch64 AFAIK. > > (IMHO rN is preferable, because this separates the register allocation > specification from how that register is used to encode the data type -- > GCC has no choice about the latter, but using "w"/"x" gives the > misleading impression of control over this.) > > > >Would you mind sending a fix? > > > > That said, I guess it's a bug we might have to work around anyway. Oh well. > > It would be preferable to see evidence of the llvm community committing > to fix this before we consider merging a bodge into Linux for it. > > Although this one issue is easy-ish to work around, we're on a slippery > slope towards allowing the LLVM and GCC inline assemblers to diverge if > we don't push back on worthless incompatibilities.
For the record, a LLVM bug was opened to add support for the rN names in constraints: https://bugs.llvm.org/show_bug.cgi?id=36862 . I know Manoj intends to submit a fix once the scope has been clarified. I plan to send a kernel fix soon, unless someone beats me to it. Matthias