Re: [PATCH 13/14] ARM: use .arch directives instead of assembler command line flags
From: Nick Desaulniers
Date: Wed Sep 29 2021 - 14:11:49 EST
On Tue, Sep 28, 2021 at 11:32 AM Arnd Bergmann <arnd@xxxxxxxxxx> wrote:
>
> On Tue, Sep 28, 2021 at 7:10 PM Nick Desaulniers
> <ndesaulniers@xxxxxxxxxx> wrote:
> >
> > On Tue, Sep 28, 2021 at 8:42 AM Arnd Bergmann <arnd@xxxxxxxxxx> wrote:
> > >
> > > From: Nick Desaulniers <ndesaulniers@xxxxxxxxxx>
> > >
> > > Similar to commit a6c30873ee4a ("ARM: 8989/1: use .fpu assembler
> > > directives instead of assembler arguments").
> > >
> > > GCC and GNU binutils support setting the "sub arch" via -march=,
> > > -Wa,-march, target function attribute, and .arch assembler directive.
> > >
> > > Clang's integrated assembler does not support -Wa,-march (and the logic
> > > to overrule one when multiple of the above are used), and this can
> > > cause annoying warnings such as:
> > >
> > > clang: warning: argument unused during compilation: '-march=armv6k' [-Wunused-command-line-argument]
> > > clang: warning: argument unused during compilation: '-march=armv6k' [-Wunused-command-line-argument]
> > > clang: warning: argument unused during compilation: '-march=armv6k' [-Wunused-command-line-argument]
> >
> > Note, the above lack of support was fixed in clang-13. That said, both
> > Clang and GCC defer to -Wa,-march when -march is also present, so
> > clang is still correct that -march is ignored. Thanks for resending;
> > this is still helpful for earlier releases of clang that we still
> > support.
>
> The -Wunused-command-line-argument warning also caused a build
> failure for me when building with 'make W=1', and I think there are
> cases where the flags from the command line are contradictory.
There's also -Werror now, which is hurting allmodconfig builds.
> Isn't the patch also needed for LTO? All I know is that with this
> applied it all builds, but without it I run into link failures.
We don't support LTO on 32b ARM, yet. I would be interested in
getting that support working.
> I can dig
> more into the specific failures, but overall I think this is the right
> thing to do anyway.
I agree. I was just adding additional context to the commit message
via my initial reply.
--
Thanks,
~Nick Desaulniers