| Message ID | CA+55aFxptOTqCR9b0o8sEKwzyQOU0rfKTptRY5s=j5R_X=UdUg@mail.gmail.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
On Thu, Jul 31, 2014 at 11:39 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > > but not in the "official" sparse tree, which hasn't seen any work > since January afaik. Ugh, I looked at the old "sparse/sparse.git" tree (and badly at that, it stopped updating in April, not January). It's "sparse/chrisl/sparse.git" these days. No wonder I didn't see any recent work. The sparse.wiki.kernel.org main page is the first google hit for "sparse git tree" and mentions that old git repo, not Chris' new one. That leaves just my last patch ("Fix scoping of extern") as being not in the sparse tree, and that's irrelevant for the union initializer thing. Chris, any particular reason why the url changed? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Jul 31, 2014 at 11:50:30AM -0700, Linus Torvalds wrote: > On Thu, Jul 31, 2014 at 11:39 AM, Linus Torvalds > <torvalds@linux-foundation.org> wrote: > > > > but not in the "official" sparse tree, which hasn't seen any work > > since January afaik. > > Ugh, I looked at the old "sparse/sparse.git" tree (and badly at that, > it stopped updating in April, not January). It's > "sparse/chrisl/sparse.git" these days. No wonder I didn't see any > recent work. > > The sparse.wiki.kernel.org main page is the first google hit for > "sparse git tree" and mentions that old git repo, not Chris' new one. > > That leaves just my last patch ("Fix scoping of extern") as being not > in the sparse tree, and that's irrelevant for the union initializer > thing. > > Chris, any particular reason why the url changed? I think Chris has been trying to use chrisl as a staging tree to let things cook a while, and then moving them over to the sparse tree. However, I think it'd make more sense to do that as a branch rather than a separate repo. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Jul 31, 2014 at 11:50 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > That leaves just my last patch ("Fix scoping of extern") as being not > in the sparse tree, and that's irrelevant for the union initializer > thing. I just apply that without the "FIXME" part. That two lines are from an incorrect fix for the external inline bug. I just remove it for now. Currently sparse will fail at the external inline test. I will fix that in a separate patch. Chris -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From c011597ff67765da5dacb472ddbd69dc4b51416d Mon Sep 17 00:00:00 2001 From: Linus Torvalds <torvalds@linux-foundation.org> Date: Tue, 1 Apr 2014 10:20:34 -0700 Subject: [PATCH 4/4] Fix scoping of extern symbols in block scope We'd only match them with other symbols marked 'extern', but really, we should match them with any top-level non-static symbol. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> --- symbol.c | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/symbol.c b/symbol.c index 4b91abd8021e..c5e4784734a8 100644 --- a/symbol.c +++ b/symbol.c @@ -576,11 +576,15 @@ void check_declaration(struct symbol *sym) sym->same_symbol = next; return; } - if (sym->ctype.modifiers & next->ctype.modifiers & MOD_EXTERN) { - if ((sym->ctype.modifiers ^ next->ctype.modifiers) & MOD_INLINE) - continue; - sym->same_symbol = next; - return; + /* Extern in block level matches a TOPLEVEL non-static symbol */ + if (sym->ctype.modifiers & MOD_EXTERN) { + if ((next->ctype.modifiers & (MOD_TOPLEVEL|MOD_STATIC)) == MOD_TOPLEVEL) { + /* FIXME? Differs in 'inline' only? Why does that matter? */ + if ((sym->ctype.modifiers ^ next->ctype.modifiers) & MOD_INLINE) + continue; + sym->same_symbol = next; + return; + } } if (!Wshadow || warned) -- 2.0.1.427.gc47372d