[PATCH 13/14] ARM: use .arch directives instead of assembler command line flags

[Nick Desaulniers]

On Tue, Sep 28, 2021 at 11:32 AM Arnd Bergmann <arnd at kernel.org> wrote:
>
> On Tue, Sep 28, 2021 at 7:10 PM Nick Desaulniers
> <ndesaulniers at google.com> wrote:
> >
> > On Tue, Sep 28, 2021 at 8:42 AM Arnd Bergmann <arnd at kernel.org> wrote:
> > >
> > > From: Nick Desaulniers <ndesaulniers at google.com>
> > >
> > > 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