Cc: Al Viro <viro@...>, Harvey Harrison <harvey.harrison@...>, Thomas Gleixner <tglx@...>, H. Peter Anvin <hpa@...>, LKML <linux-kernel@...>, Pallipadi, Venkatesh <venkatesh.pallipadi@...>
Who said daily? More often can be better, but just before the pull
request is still better than nothing. And even some very basic and
stupid filtering can make the sparse output more feasible without losing
"too much" information (my stupid approach here can fail for example
when you remove an error of one class while introducing another one of
the same class).
Given the merge of x86.git that introduced this specific bug we have:
9e9abecf - "merge x86.git"
Now we can get:
$ git merge-base 9e9abecf^1 9e9abecf^2
4b119e21d0c66c22e8ca03df05d9de623d0eb50f
So you branched at 4b119e21... (your history is linear, that helps here)
To get the same information before the merge happened upstream, in your
local repo, you can do:
git merge-base for-linus origin/master
(or whatever your branches are called)
# So we get the old upstream version:
git checkout 4b119e21d0c
# setup config, whatever
make
make C=2 2>old-sparse
# Then the state of your tree right before the merge:
git checkout 9e9abecf^2
make
make C=2 2>new-sparse
# And now some stupid sorting and cleaning:
sort old-sparse | sed -e 's/^\([^:]*\):[^:]*:[^:]*:/\1:/' > old-sparsef
sort new-sparse | sed -e 's/^\([^:]*\):[^:]*:[^:]*:/\1:/' > new-sparsef
# How many old sparse warnings are gone now (approx.)?
$ diff old-sparsef new-sparsef | grep -c '^< [^ ]*:'
33
# And how many new do we have (approx.)?
$ diff old-sparsef new-sparsef | grep -c '^> [^ ]*:'
36
Depending on the order of the sed and sort commands, you get slightly
different output, due to code moving around or whatever, of course to
get that "mostly" right it takes more than the 5 minutes of thinking
that I spent on it.
In those cases in which there is more than 1 line per warning, the
output is obivously messed up here, so the actual number of real
warnings from sparse that are left is even lower than the number above
(26 for gone and new warnings in this case). And you can also only use
the filtered messages to navigate the original sparse log, because the
line numbers are stripped and the messed up ordering of multi-line
warnings, but well, shouldn't be too bad.
Slap another level of filtering on it that can ignore warnings that are
known to be bogus or in which you're simply not interested or whatever
and you're down to a pretty manageable set of warnings I guess.
Finally, yeah, I know, this approach is far from perfect, but in my
nobody-should-care-about-it opinion, it's better than nothing and it's
probably not too hard for you (or Thomas) to come up with a less stupid
filtering strategy, that's less error-prone than my hack.
Björn
--
