From: Michal Marek <mmarek@suse.cz>
To: 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: Wed, 24 Sep 2014 14:07:11 +0200 [thread overview]
Message-ID: <5422B3EF.4000800@suse.cz> (raw)
In-Reply-To: <1411500522-11480-1-git-send-email-behanw@converseincode.com>
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?
> unless -Werror is set. GCC will return false if an unknown
> warning is passed.
>
> Adding -Werror make both compiler behave the same.
Can you please limit it to the clang case? Add an internal variable that
either contains -Werror or nothing, depending on the compiler. What I
fear is that if we use -Werror unconditionally and the user (or some
automated build system) decides to add some silly option to KCFLAGS, we
will get silent failures in the cc-option tests. Of course, the same can
happen with clang, but there seems to be no way around it.
BTW, is there a chance that this would be fixed in some later clang
version? Accepting unknown commandline options is a rather unusual
behavior. How are all the ./configure scripts going to cope with it?
Thanks,
Michal
next prev parent reply other threads:[~2014-09-24 12:07 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 [this message]
2014-09-24 18:50 ` Behan Webster
2014-09-25 13:34 ` Michal Marek
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=5422B3EF.4000800@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.