Re: clang: Powerpc: clang-nightly-maple_defconfig — FAIL

[Nathan Chancellor <nathan@kernel.org>]

On Wed, Jun 14, 2023 at 07:43:45PM +0530, Naresh Kamboju wrote:
> Hi Nathan,
> 
> On Tue, 13 Jun 2023 at 09:57, Naresh Kamboju <naresh.kamboju@linaro.org> wrote:
> >
> > Hi Nathan,
> >
> > On Tue, 13 Jun 2023 at 00:24, Nathan Chancellor <nathan@kernel.org> wrote:
> > >
> > > Hi Naresh,
> > >
> > > On Tue, Jun 13, 2023 at 12:10:30AM +0530, Naresh Kamboju wrote:
> > > > [Please ignore if it is already reported]
> > > >
> > > > Following two builds failed on stable-rc 6.1.34-rc1.
> > > >
> > > >   - Powerpc: clang-nightly-maple_defconfig — FAIL
> > > >   - Powerpc: clang-nightly-cell_defconfig — FAIL
> > > >
> 
> > > As always, thanks for the report. This is an LLVM regression/change in
> > > behavior caused by [1], which can break as-option and as-instr on
> > > releases prior to commit d5c8d6e0fa61 ("kbuild: Update assembler calls
> > > to use proper flags and language target"), as unsupported flags for the
> > > current target ('-x') may be present (KBUILD_CFLAGS is used for these
> > > tests instead of KBUILD_AFLAGS). Inside try-run, the macro behind
> > > as-instr and as-option, I see
> > >
> > >   clang-17: error: unsupported option '-mno-prefixed' for target 'powerpc64le-linux-gnu'
> > >   clang-17: error: unsupported option '-mno-pcrel' for target 'powerpc64le-linux-gnu'
> > >   clang-17: error: unsupported option '-mno-altivec' for target 'powerpc64le-linux-gnu'
> > >   clang-17: error: unsupported option '-mno-vsx' for target 'powerpc64le-linux-gnu'
> > >   clang-17: error: unsupported option '-mno-mma' for target 'powerpc64le-linux-gnu'
> > >   clang-17: error: unsupported option '-mno-spe' for target 'powerpc64le-linux-gnu'
> > >
> > > This has come up recently elsewhere in PowerPC, see
> > > commit 2b694fc96fe3 ("powerpc/boot: Disable power10 features after
> > > BOOTAFLAGS assignment"). While I think it is dubious that clang errors
> > > on these flags for the assembler target, this is already fixed on the
> > > Linux side by using KBUILD_AFLAGS for these make macros.
> > >
> > > I am preparing a series of d5c8d6e0fa61 and its dependencies for 6.1 but
> > > I want to do sufficient build testing first, which is currently running
> > > for me. Would you be able to point your matrix to [2] to make sure
> > > everything works properly with both GCC and LLVM? It is a work in
> > > progress as the second patch in the stack needs a proper commit message
> > > but it is the diff I expect to ship so that it all that matters.
> >
> > We'll start building [2] with GCC and LLVM by using tuxplans and
> > get back to you.
> 
> LKFT has been configured to run GCC and LLVM in total 205 builds
> and all the builds have passed on your tree / branch [2]. You can find
> the list of builds including kselftest, perf, rcutorture, kunit, kmemleak
> and many more combinations and architectures.
> 
> I request you to review the list of builds results and test results on
> projects page [3] [4]. I do not find any regressions compared with
> mainline master as sanity testing.

Thanks a lot for testing!

> Do you think LKFT should build your tree / branch often ?
> We are happy to test anytime.

No, this is an exceptional circumstance, not the norm. If I need wider
testing done in the future, I will keep you all in mind :)

> Thanks Daniel and Anders for your work.
> 
> build_names: that got tested and all have passed.
> 

<snip>

Great! I sent along the 6.1 backports now:

https://lore.kernel.org/20230612-6-1-asssembler-target-llvm-17-v1-0-75605d553401@kernel.org/

Thanks again for testing and the report, cheers!
Nathan