On Feb 17, 2013, at 11:25 PM, David Blaikie <[email protected]> wrote:
> On Sun, Feb 17, 2013 at 11:18 PM, Ted Kremenek <[email protected]> wrote: > Author: kremenek > Date: Mon Feb 18 01:18:28 2013 > New Revision: 175425 > > URL: http://llvm.org/viewvc/llvm-project?rev=175425&view=rev > Log: > Disable dead stores checker for template instantations. Fixes > <rdar://problem/13213575>. > > Modified: > cfe/trunk/lib/StaticAnalyzer/Checkers/DeadStoresChecker.cpp > cfe/trunk/test/Analysis/dead-stores.cpp > > Modified: cfe/trunk/lib/StaticAnalyzer/Checkers/DeadStoresChecker.cpp > URL: > http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Checkers/DeadStoresChecker.cpp?rev=175425&r1=175424&r2=175425&view=diff > ============================================================================== > --- cfe/trunk/lib/StaticAnalyzer/Checkers/DeadStoresChecker.cpp (original) > +++ cfe/trunk/lib/StaticAnalyzer/Checkers/DeadStoresChecker.cpp Mon Feb 18 > 01:18:28 2013 > @@ -419,6 +419,15 @@ class DeadStoresChecker : public Checker > public: > void checkASTCodeBody(const Decl *D, AnalysisManager& mgr, > BugReporter &BR) const { > + > + // Don't do anything for template instantiations. > + // Proving that code in a template instantiation is "dead" > + // means proving that it is dead in all instantiations. > + // This same problem exists with -Wunreachable-code. > > I believe last time we spoke about this we agreed that correctness can be > attained by examining template patterns not specializations for unreachable > code. Your concern was one of performance that I never did get around to > providing numbers for (your concern was that examining all template patterns > might be too expensive) - I'm not sure if you have the same concern for the > Static Analyzer in this regard, or an easier way to verify the perf impact to > thins you care about here. > > (or perhaps the Static Analyzer already gets this right by examining template > patterns elsewhere?) > Hi David, You are correct. While it is true the analyzer has more "CPU time to burn" than a compiler warning, here was my thinking: (1) This warning should possibly be made one day into a compiler warning, where the same performance requirements for -Wunreachable-code apply. Thus until we feel comfortable with the solution we devised for -Wunreachable-code, it seems reasonable to wait on applying the same solution here. (2) This was designed to be an expedient solution, addressing a clear case of reducing false positives. This code has not been tested at all on analyzing template patterns, which was beyond the time I had to work on this right now. I still agree with you, however, that looking at template patterns may be the best long-term solution, but there are many details left to be figured out there. Cheers, Ted
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
