From: Harvey Harrison <harvey.harrison@gmail.com>
To: David Miller <davem@davemloft.net>
Cc: alexey.zaytsev@gmail.com, linux-kernel@vger.kernel.org,
mingo@elte.hu, rostedt@goodmis.org
Subject: Re: [PATCH] Disable branch profiling macros when sparsed.
Date: Fri, 09 Jan 2009 23:18:26 -0800 [thread overview]
Message-ID: <1231571906.5714.30.camel@brick> (raw)
In-Reply-To: <20090109.221348.166902734.davem@davemloft.net>
On Fri, 2009-01-09 at 22:13 -0800, David Miller wrote:
> From: Alexey Zaytsev <alexey.zaytsev@gmail.com>
> Date: Sat, 10 Jan 2009 08:57:28 +0300
>
> > The macros produce lots of unneeded warnings when
> > recursive if(({ .. if() {..} ..})) {..} and such
> > are substituted. And there is no point in sparsing
> > them anyway. This is useful if someone decides to
> > sparse an allyesconfig kernel.
> >
> > Signed-off-by: Alexey Zaytsev <alexey.zaytsev@gmail.com>
>
> If even sparse can't handle these things, it's no surprise
> how many gcc bogus warning problems we've run into because
> of this hairy if() macro.
It's not that sparse can't handle it, the warning is valid,
_____r and ______f are shadowed when these get nested. It
gets even worse when interacting with likely/unlikely tracing
as that chose the same identifiers too. So there the noise
could be drastically reduced changing the different identifiers
for the if () and __branch_check macros, but nesting will always
warn.
I've just been setting this to no in my allyesconfig sparse
runs....just wait until kmemtrace gets to mainline, then it
gets really bad :(
Cheers,
Harvey
next prev parent reply other threads:[~2009-01-10 7:18 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-10 5:57 [PATCH] Disable branch profiling macros when sparsed Alexey Zaytsev
2009-01-10 6:13 ` David Miller
2009-01-10 7:18 ` Harvey Harrison [this message]
2009-01-10 9:35 ` Alexey Zaytsev
2009-01-10 21:33 ` Harvey Harrison
2009-01-10 23:04 ` Steven Rostedt
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=1231571906.5714.30.camel@brick \
--to=harvey.harrison@gmail.com \
--cc=alexey.zaytsev@gmail.com \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rostedt@goodmis.org \
/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.