From: Johannes Berg <johannes@sipsolutions.net>
To: Josh Triplett <josh@joshtriplett.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
Linux-Sparse <linux-sparse@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: gcc tickets for sparse attributes
Date: Fri, 17 Jan 2014 11:23:25 +0100 [thread overview]
Message-ID: <1389954205.10404.1.camel@jlt4.sipsolutions.net> (raw)
In-Reply-To: <20140117092223.GC577@leaf>
> > IMHO the context extension doesn't work well enough in sparse to
> > document and implement as is. It would be much better if it actually was
> > able to differentiate between contexts, rather than treating each one
> > the same.
>
> That would certainly be nice, but that's something actually much more
> easily done in GCC than in Sparse, given the types of information GCC
> already has available to implement features like alias analysis.
Right.
> In any case, the spec I wrote up assumes a distinction between contexts,
> but allows for an initial implementation like Sparse's that ignores the
> distinction.
Ok cool. :)
> > This would avoid the problem that locking one lock and
> > unlocking another (in the kernel's __acquire/ __release mechanism) could
> > still result in a warning.
>
> That would actually *not* produce a warning, though it should. In
> general, I *think* an implementation like Sparse's that ignores the
> distinction between locks should produce false negatives but not false
> positives.
Right, it doesn't report one now.
johannes
next prev parent reply other threads:[~2014-01-17 10:23 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-17 5:27 gcc tickets for sparse attributes H. Peter Anvin
2014-01-17 5:35 ` H. Peter Anvin
2014-01-17 8:33 ` Johannes Berg
2014-01-17 9:22 ` Josh Triplett
2014-01-17 10:23 ` Johannes Berg [this message]
2014-01-17 9:18 ` Josh Triplett
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=1389954205.10404.1.camel@jlt4.sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=hpa@zytor.com \
--cc=josh@joshtriplett.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sparse@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).