All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Marek <mmarek@suse.cz>
To: Behan Webster <behanw@converseincode.com>
Cc: ak@linux.intel.com, yamada.m@jp.panasonic.com,
	hpa@linux.intel.com, linux-kernel@vger.kernel.org,
	sam@ravnborg.org, Mark Charlebois <charlebm@gmail.com>
Subject: Re: [PATCH] kbuild, LLVMLinux: Add -Werror to cc-option to support clang
Date: Thu, 25 Sep 2014 15:34:03 +0200	[thread overview]
Message-ID: <542419CB.3090902@suse.cz> (raw)
In-Reply-To: <5423128D.8070708@converseincode.com>

On 2014-09-24 20:50, Behan Webster wrote:
> On 09/24/14 05:07, Michal Marek wrote:
>> On 2014-09-23 21:28, behanw@converseincode.com wrote:
>>> From: Mark Charlebois <charlebm@gmail.com>
>>>
>>> Clang will warn about unknown warnings but will not return false
>> You mean unknown options, right?
> 2 kinds of options: flags and warnings. clang used to merely warn about 
> unused/unsupported flags/warnings. It now returns errors for unknown 
> flags, but not warnings (unless you specify -Werror).

Ah, unknown warning options. Now I understand.


> Getting clang to error on unused flags wasn't trivial (this change broke 
> a lot of builds apparently). Fortunately we weren't the only ones who 
> wanted it to behave like gcc in this case. I think it's going to be 
> *much* harder to do the same for warnings. The argument given by 
> supporters of the current situation is that if a warning isn't 
> supported, why break the build? *sigh*

I guess the reason to accept unknown warnings opentions is compatibility
with Makefiles with hardcoded gcc-isms. BTW, GCC at some point started
to ignore unknown -Wno-* options, for everyone's good of course. That's
why we ended up with the cc-disable-warning function. If -W* options for
clang need special care, then it might be a good idea to introduce
cc-warning with the conditional -Werror for clang. There are not that
many places where we add warnings, so the patch would be still short.
That way, the possible silent failure is limited only to warning options
with clang, which is not such a big deal.

Michal

  reply	other threads:[~2014-09-25 13:34 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-23 19:28 [PATCH] kbuild, LLVMLinux: Add -Werror to cc-option to support clang behanw
2014-09-24 12:07 ` Michal Marek
2014-09-24 18:50   ` Behan Webster
2014-09-25 13:34     ` Michal Marek [this message]
2014-09-26  0:48       ` Behan Webster
  -- strict thread matches above, loose matches on Subject: below --
2017-03-31 20:38 Arnd Bergmann
2017-03-31 23:59 ` Kees Cook
2017-04-02 21:46 ` Masahiro Yamada
2017-04-05 17:11   ` Masahiro Yamada
2017-04-11 19:38 ` Masahiro Yamada
2019-09-27  6:05 Ahmad Fatoum
2019-09-30 18:35 ` Sascha Hauer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=542419CB.3090902@suse.cz \
    --to=mmarek@suse.cz \
    --cc=ak@linux.intel.com \
    --cc=behanw@converseincode.com \
    --cc=charlebm@gmail.com \
    --cc=hpa@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sam@ravnborg.org \
    --cc=yamada.m@jp.panasonic.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.