Messages in this thread | | | Date | Sun, 19 Sep 2021 20:43:19 -0700 | From | Nathan Chancellor <> | Subject | Re: x86_64: clang-10: <instantiation>:2:2: error: unknown use of instruction mnemonic without a size suffix |
| |
Hi Naresh,
On Mon, Sep 20, 2021 at 08:55:46AM +0530, Naresh Kamboju wrote: > [Please ignore this email if it is already reported ] > > Following build warnings/ errors noticed while building linux mainline > master branch > with clang-10 for x86_64 architecture. > But clang-11, clang-12 and clang-13 build pass. > > <instantiation>:2:2: error: unknown use of instruction mnemonic > without a size suffix > lsl %rax, %rax > ^ > <instantiation>:1:1: note: while in macro instantiation > LOAD_CPU_AND_NODE_SEG_LIMIT %rax > ^ > <instantiation>:2:2: note: while in macro instantiation > GET_PERCPU_BASE %rax > ^ > /builds/linux/arch/x86/entry/entry_64.S:887:2: note: while in macro > instantiation > SAVE_AND_SET_GSBASE scratch_reg=%rax save_reg=%rbx > ^ > make[3]: *** [/builds/linux/scripts/Makefile.build:379: > arch/x86/entry/entry_64.o] Error 1 > arch/x86/entry/entry_64_compat.o: warning: objtool: .entry.text+0x215: > can't find jump dest instruction at .entry.text+0x21a > make[3]: Target '__build' not remade because of errors. > make[2]: *** [/builds/linux/scripts/Makefile.build:540: arch/x86/entry] Error 2 > make[2]: Target '__build' not remade because of errors. > make[1]: *** [/builds/linux/Makefile:1868: arch/x86] Error 2
Thanks for the report. This is another case where the implicit switch to the integrated assembler exposed a previously fixed issue in LLVM:
https://github.com/ClangBuiltLinux/linux/issues/1079
This cannot be fixed in the LLVM 10 branch as it is no longer updated so if you want to keep testing with clang-10 for x86_64 on mainline, please add 'LLVM_IAS=0' to your make command like we did in our own CI.
As a quick aside, would you mind updating my email address in your system for reports to nathan@kernel.org? It will ensure it gets sent to the correct inbox so that I do not miss things, as I do not use my personal address for kernel development anymore.
Cheers, Nathan
| |