On Sep 23, 2011, at 9:33 PM, David Blaikie wrote:
> Hi Ted,
>
> I tried -Wunreachable-code earlier today (Chandler had suggested it as a way
> to find/remove the dead code after llvm_unreachables I'd migrated yesterday)
> & it produced some very... interesting output. It did find the dead code
> after llvm_unreachable but it also found some other very strange cases. I was
> wondering what was up with that. Good to know it's WIP - any tips on the
> state of that? anywhere I'd be able to lend a hand?
Hi David,
The weirdest results I see from -Wunreachable-code tend to involve template
code. In templates, I've seen cases where a branch condition depends on a
template parameter, and at template instantiation the branch condition may
become a constant. This can cause some code to (correctly) be flagged as
unreachable for that particular instantiation of a template. This of course is
not an invariant for that template for *all* instantiations, so it's not a real
issue.
The solution I had in mind to fix this problem is to enhance the CFG. Instead
of just pruning CFG edges, for templates we could record when an edge was
pruned AND whether or not it was dependent on a template parameter. Most
analyses would continue to see the CFG as they do now, but specific analyses
(such as -Wunreachable-code) could do something a bit more clever and not treat
such code as unreachable.
>
> It wouldn't catch all the same cases ("case N: default: stuff" for example)
> but this solution isn't great either, it'll catch a variety of arcane cases
> that won't have trivial fixes.
Ah, interesting. -Wunreachable-code looks for finding unreachable basic
blocks, not looking at whether or not a label could never be used. Those are
different concepts.
> Chandler had mentioned the idea of this warning (well, something like it)
> yesterday but after I threw this together we were talking about it more &
> realized it'd be pretty tricky to get right with a nice multiline fixit that
> is very reliable (I get the impression that's what he's really interested in
> - really low (0?) false positive rate & accurate fixits - which would be
> awesome, but require a rather different fix)
I agree. A warning like this in the compiler needs close to a zero false
positive rate.
Cheers,
Ted
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
