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

From: Jerome Forissier <jerome@forissier.org>
To: Tobias Klauser <tklauser@distanz.ch>
Cc: linux-riscv@lists.infradead.org, aou@eecs.berkeley.edu,
	palmer@dabbelt.com, paul.walmsley@sifive.com
Subject: Re: [PATCH RESEND] riscv: don't specify -mno-save-restore when building with clang
Date: Wed, 29 Jul 2020 11:43:59 +0200	[thread overview]
Message-ID: <fd5498de-85a5-c8a1-95f4-e714dd819038@forissier.org> (raw)
In-Reply-To: <d09a872d-3f6a-c849-a5c9-f3c859a49349@forissier.org>

On 7/29/20 11:36 AM, Jerome Forissier wrote:
> 
> 
> On 7/29/20 10:29 AM, Tobias Klauser wrote:
>> On 2020-07-29 at 10:08:11 +0200, Jerome Forissier <jerome@forissier.org> wrote:
>>>> On 2020-07-28 at 18:06:36 +0200, Tobias Klauser <tklauser@distanz.ch> wrote:
>>>>> On 2020-07-28 at 17:20:45 +0200, Palmer Dabbelt <palmer@dabbelt.com> wrote:
>>>>>> On Tue, 28 Jul 2020 06:12:52 PDT (-0700), tklauser@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@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.
> 
> OK, I was thinking perhaps cc-option should consider a warning as a hint
> that the option should not be used. But it is probably not a good idea
> after all (could easily break things).
> 
> However this makes me think the following could work (untested!):
> 
> -KBUILD_CFLAGS += -mno-save-restore
> +KBUILD_CFLAGS += $(call cc-option,-mno-save-restore -Werror)

Sorry, please ignore this nonsense. We don't want -Werror to stick in
KBUILD_CFLAGS obviously.

:-/

-- 
Jerome

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv