[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKwvOdmXvC-E_9PSOZVQDDx_UCSadxhF4d9c7qpJPmeFLY_JEA@mail.gmail.com>
Date: Tue, 15 Feb 2022 11:10:28 -0800
From: Nick Desaulniers <ndesaulniers@...gle.com>
To: Naresh Kamboju <naresh.kamboju@...aro.org>
Cc: open list <linux-kernel@...r.kernel.org>, llvm@...ts.linux.dev,
Nathan Chancellor <nathan@...nel.org>
Subject: Re: arm64: clang-nightly: net/ipv4/tcp_input.c: clang: error: clang
frontend command failed with exit code 139
On Mon, Feb 14, 2022 at 7:35 AM Nathan Chancellor <nathan@...nel.org> wrote:
>
> Hi Naresh,
>
> On Mon, Feb 14, 2022 at 12:27:17PM +0530, Naresh Kamboju wrote:
> > On Linux mainline master branch with arm64 clang-nightly build failed
> > due to following errors and warnings.
> >
> > make --silent --keep-going --jobs=8
> > O=/home/tuxbuild/.cache/tuxmake/builds/current LLVM=1 LLVM_IAS=1
> > ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-
> > CROSS_COMPILE_COMPAT=arm-linux-gnueabihf- HOSTCC=clang CC=clang
Thanks for the report. Thanks Nathan for submitting reverts.
Naresh, as a heads up, the above command line can be simplified a
little bit (particularly for newer kernel branches)
LLVM_IAS=1 is implied by LLVM=1 as of v5.15-rc1 via
commit f12b034afeb3 ("scripts/Makefile.clang: default to LLVM_IAS=1").
CROSS_COMPILE is no longer necessary when building with LLVM=1 as of
v5.15-rc1 via:
commit 231ad7f409f1 ("Makefile: infer --target from ARCH for CC=clang")
There is no need for CROSS_COMPILE_COMPAT as of v5.16-rc1 via
commit 3e6f8d1fa184 ("arm64: vdso32: require CROSS_COMPILE_COMPAT for gcc+bfd")
when LLVM=1 is set.
HOSTCC and CC are implied by LLVM=1 as of
commit a0d1c951ef08 ("kbuild: support LLVM=1 to switch the default
tools to Clang/LLVM")
v5.7-rc1.
So the above make invocation could be trimmed down to simply:
$ make --silent --keep-going --jobs=8 \
O=/home/tuxbuild/.cache/tuxmake/builds/current LLVM=1
We might need to discuss further with tuxbuild folks, since I think a
few of those are set implicitly; I would prefer if they needed to be
set explicitly in order to properly test them being _unspecified_ in
our CI.
--
Thanks,
~Nick Desaulniers
Powered by blists - more mailing lists