r175425 - Disable dead stores checker for template instantations. Fixes <rdar://problem/13213575>.

Ted Kremenek kremenek at apple.com
Sun Feb 17 23:56:13 PST 2013

On Feb 17, 2013, at 11:25 PM, David Blaikie <dblaikie at gmail.com> wrote:

> On Sun, Feb 17, 2013 at 11:18 PM, Ted Kremenek <kremenek at apple.com> 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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130217/bf12aed4/attachment.html>

More information about the cfe-commits mailing list