@steakhal you some great experience with (strict) aliasing, could you chip in on this maybe? :)
I plan to split this patch up eventually, but here's where I'm standing right now:
- Correct the algorithm that by accident did this: GEN[B] = GEN[B] union (IN[B] - KILL[B]) instead of this: OUT[B] = GEN[B] union (IN[B] - KILL[B])
- Realize that llvm::SmallSet uses both operator== and operator<, and since for a reaching definition set I'd like to sort by VarDecl, but for the kill set that AND the CFGElementRef, give up on it and use std::set instead with two different comparators
- Collect all non-local variables and regard all function calls as definitions to them
- Collect parameter declarations as well, add them to GEN[entry block]
- Plenty more test cases
Sun, Jul 21
LGTM, thanks! Please mark inlines as done as you fix them. If you like the file description I proposed, I'm happy to commit this on your behalf (or you might as well apply for a commit access, since you have a track record of high quality patches already).
Sat, Jul 20
I guess getAs and castAs methods could join the party too. I'm evaluating plenty of results on LLVM, and those seem to be in the same problem category.
LLVM+Clang (A total of 207 reports changed)
Fri, Jul 19
Thu, Jul 18
Wed, Jul 17
Since we allow new kinds of SVals to be tracked it would be great to test this first on a larger corpus of projects just to see if there is a crash (due to an unhandled SVal type).
Rebase on top master. Putting this on the bottom of the patch stack because this really deserves it's own analysis. (Side note, I completely messed up like ~40 hrs worth of analysis because I didn't check which branches do I have stacked on top of each other, so this might take a while...)
I think you forgot to remove /* */ and clang formatting before uploading the patch.
Hmm, okay, so we convert -1 from the config file to UINT_MAX in the code, I like it!
Tue, Jul 16
Starting to look real good!
I think this looks reasonable to me, though I am still not certain if the relative path in the python script will work with both the svn in-tree directory layout as well as the git monorepo layout (which I'm far less familiar with).
Mon, Jul 15
Also, shouldn't we add this to the release notes? In general, it's be around time to sort it out (might do that myself before the new branch).
I don't see obvious red flags strictly regarding the analyzer!
Sun, Jul 14
I'd rather not abandon this patch, because it looks like a strict improvement over the lack of condition tracking, and it might as well still be an improvement over "zealous" condition tracking, as my counterexample is fairly artificial. It indicates that a slightly more sophisticated algorithm is necessary (i'm not sure if it's single-pass or even linear). But i'll be perfectly happy with simply adding it as a FIXME test.
Would you say it's good to go? :)
Fri, Jul 12
Hmmm, did this result in an assertion?
Thu, Jul 11
Wed, Jul 10
Np, please leave it in! :)
I guess any time we modify analyzer stuff, we may invite the main analyzer developers to the patch review as well.
Please know that I'm currently out of town, so it'll be a while before I can formally accept. Its on top of my list when I get home though! :^)
Just thinking aloud!
Tue, Jul 9
Mmm, no, not really; it seems that if i introduce a checker dependency, i also have to put the option onto the base checker, otherwise the checker name wouldn't match when i do getCheckerBooleanOption(getChecker<VirtualCallChecker>(), "PureOnly"). Which means that the option name will inevitably change. @Szelethus, do i understand this correctly?
Sat, Jul 6
I happen to have very recent analyses on a couple projects, I'll throw this in: LLVM+Clang+Clang-tools-extra. No findings on Xerces or Bitcoin.
Rebase after D64271 being abandoned.
You're right. If condition tracking only adds necessary information anyways, this shouldn't hurt that much anyways.
Fri, Jul 5
I'm slightly worried that we're fighting the symptoms rather than the root cause here: why were these values tracked that far in the first place when we already have no interest in tracking them at the end of the function?
Could you please elaborate? Which of the modified test cases (or any other) do you think falls under "being tracked too far" and why? Whenever the CFG where the value isn't linear, I think the information could be valuable, see the inline.
I.e., i suspect that your "mild tracking mode" would get rid of a lot of those automagically.
Since the followup patches test this roughly anyways, and the fact that the AST's lifetime ends right after the CFG's construction makes the remaining tests pretty much pointless, if I can't resolve this, I'll just remove the testfile.
@Szelethus This is causing problems on windows buildbots http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast - revert?