Re: [PATCH] kbuild, LLVMLinux: only use warnings when using clang

[Behan Webster <behanw@converseincode.com>]

On 07/30/14 06:04, Michal Marek wrote:
> On 2014-07-01 12:12, Borislav Petkov wrote:
>> On Mon, Jun 30, 2014 at 05:42:26PM -0700, behanw@converseincode.com wrote:
>>> From: Behan Webster <behanw@converseincode.com>
>>>
>>> Only consider clang warnings in Kbuild when using the clang compiler.
>>>
>>> Signed-off-by: Behan Webster <behanw@converseincode.com>
>>> ---
>>>   scripts/Makefile.extrawarn | 3 ++-
>>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/scripts/Makefile.extrawarn b/scripts/Makefile.extrawarn
>>> index 6564350..e350127 100644
>>> --- a/scripts/Makefile.extrawarn
>>> +++ b/scripts/Makefile.extrawarn
>>> @@ -26,7 +26,7 @@ warning-1 += $(call cc-option, -Wmissing-include-dirs)
>>>   warning-1 += $(call cc-option, -Wunused-but-set-variable)
>>>   warning-1 += $(call cc-disable-warning, missing-field-initializers)
>>>   
>>> -# Clang
>>> +ifeq ($(COMPILER),clang)
>>>   warning-1 += $(call cc-disable-warning, initializer-overrides)
>>>   warning-1 += $(call cc-disable-warning, unused-value)
>>>   warning-1 += $(call cc-disable-warning, format)
>>> @@ -35,6 +35,7 @@ warning-1 += $(call cc-disable-warning, sign-compare)
>>>   warning-1 += $(call cc-disable-warning, format-zero-length)
>>>   warning-1 += $(call cc-disable-warning, uninitialized)
>>>   warning-1 += $(call cc-option, -fcatch-undefined-behavior)
>>> +endif
>> Ok, just to make sure I understand that whole use case correctly:
>>
>> The disabling of those warnings is really intended for the case where
>> people build the kernel with "W=1" on the make cmdline *and* clang?
> Behan, Jan-Simon,
>
> can you explain why are those -Wno-... options needed in the W=1 case?
> The whole point of the W= option is to enable noisy warnings, so I don't
> quite get why you want to silence these.
Sorry for the delay.

That code is indeed not what was intended. It's more that these warnings 
should normally be disabled, and when W is set they should not be disabled.

Just putting the final touches on a patch which addresses this situation.

Behan

-- 
Behan Webster
behanw@converseincode.com