[PATCH RESEND] riscv: don't specify -mno-save-restore when building with clang

[Tobias Klauser]

On 2020-07-29 at 10:08:11 +0200, Jerome Forissier <jerome at forissier.org> wrote:
> > On 2020-07-28 at 18:06:36 +0200, Tobias Klauser <tklauser at distanz.ch> wrote:
> > > On 2020-07-28 at 17:20:45 +0200, Palmer Dabbelt <palmer at dabbelt.com> wrote:
> > > > On Tue, 28 Jul 2020 06:12:52 PDT (-0700), tklauser at distanz.ch wrote:
> > > > > Clang doesn't support -msave-restore and -mno-save-restore. This avoids
> > > > > the following message emitted by clang:
> > > > > 
> > > > >   '-save-restore' is not a recognized feature for this target (ignoring feature)
> > > > > 
> > > > > Signed-off-by: Tobias Klauser <tklauser at distanz.ch>
> > > > > ---
> > > > > Resent due to infradead.org mailing list issues.
> > > > > 
> > > > >  arch/riscv/Makefile | 2 ++
> > > > >  1 file changed, 2 insertions(+)
> > > > > 
> > > > > diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
> > > > > index fb6e37db836d..cd3720bc45e8 100644
> > > > > --- a/arch/riscv/Makefile
> > > > > +++ b/arch/riscv/Makefile
> > > > > @@ -44,7 +44,9 @@ riscv-march-$(CONFIG_RISCV_ISA_C)	:= $(riscv-march-y)c
> > > > >  KBUILD_CFLAGS += -march=$(subst fd,,$(riscv-march-y))
> > > > >  KBUILD_AFLAGS += -march=$(riscv-march-y)
> > > > > 
> > > > > +ifndef CONFIG_CC_IS_CLANG
> > > > >  KBUILD_CFLAGS += -mno-save-restore
> > > > > +endif
> > > > >  KBUILD_CFLAGS += -DCONFIG_PAGE_OFFSET=$(CONFIG_PAGE_OFFSET)
> > > > > 
> > > > >  ifeq ($(CONFIG_CMODEL_MEDLOW),y)
> > > > 
> > > > Thanks, this one didn't make it the first time.  Is there a reason we can't use
> > > > cc-option here?  IIRC that's what we use for the other compiler options that
> > > > may be unimplemented, and it has the advantage of avoiding encoding specific
> > > > compilers into the build system.
> > > 
> > > Thanks for the hint. I don't know how I could've overlooked cc-option.
> > > Will send a v2 using cc-option.
> > 
> > Looks like it's a bit more complicated:
> > 
> > Using just cc-option still leads to the warning being emitted, so I
> > think the CONFIG_CC_IS_CLANG check is still needed (checked using clang
> 
> Shouldnt cc-option be fixed instead? The warning effectively means the option
> is not supported, so why should cc-option pretend it is?

The problem is that clang somewhat handles the option, i.e. doesn't
treat it as an unknown option like others and thus doesn't exit with
non-zero, like it does for other options only available for gcc. This is
what cc-option relies on.

Like mentioned in the follow-up patch [1] clang 11 will handle
-m{no,}save-restore correctly, so we need to address that case as well
(which [1] does). Unfortunately, I currently see no other way than using
these ifeq's to fix this.

[1] https://lore.kernel.org/linux-riscv/20200729044428.32460-1-tklauser@distanz.ch/T/#u