Project Ortega BCM5719 LLVM https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1 2019-01-19T08:50:56+00:00 2019-01-19T08:50:56+00:00 Chandler Carruth chandlerc@gmail.com 2019-01-19T08:50:56+00:00 urn:sha1:2946cd701067404b99c39fb29dc9c74bd7193eb3 to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636 2019-01-18T00:08:56+00:00 Artem Dergachev artem.dergachev@gmail.com 2019-01-18T00:08:56+00:00 urn:sha1:2ed0e79bb8efc3d642e3d8212e17a160f5ebb499 SymbolReaper now realizes that our liveness analysis isn't sharp enough to discriminate between liveness of, say, variables and their fields. Surprisingly, this didn't quite work before: having a variable live only through Environment (eg., calling a C++ method on a local variable as the last action ever performed on that variable) would not keep the region value symbol of a field of that variable alive. It would have been broken in the opposite direction as well, but both Environment and RegionStore use the scanReachableSymbols mechanism for finding live symbols regions within their values, and due to that they accidentally end up marking the whole chain of super-regions as live when at least one sub-region is known to be live. It is now a direct responsibility of SymbolReaper to maintain this invariant, and a unit test was added in order to make sure it stays that way. Differential Revision: https://reviews.llvm.org/D56632 rdar://problem/46914108 llvm-svn: 351499 2018-11-30T03:27:50+00:00 Artem Dergachev artem.dergachev@gmail.com 2018-11-30T03:27:50+00:00 urn:sha1:bbc6d68297c8b0641eb8226dea7746a0d97ae33b It's an old bug that consists in stale references to symbols remaining in the GDM if they disappear from other program state sections as a result of any operation that isn't the actual dead symbol collection. The most common example here is: FILE *fp = fopen("myfile.txt", "w"); fp = 0; // leak of file descriptor In this example the leak were not detected previously because the symbol disappears from the public part of the program state due to evaluating the assignment. For that reason the checker never receives a notification that the symbol is dead, and never reports a leak. This patch not only causes leak false negatives, but also a number of other problems, including false positives on some checkers. What's worse, even though the program state contains a finite number of symbols, the set of symbols that dies is potentially infinite. This means that is impossible to compute the set of all dead symbols to pass off to the checkers for cleaning up their part of the GDM. No longer compute the dead set at all. Disallow iterating over dead symbols. Disallow querying if any symbols are dead. Remove the API for marking symbols as dead, as it is no longer necessary. Update checkers accordingly. Differential Revision: https://reviews.llvm.org/D18860 llvm-svn: 347953 2018-10-22T20:11:10+00:00 Artem Dergachev artem.dergachev@gmail.com 2018-10-22T20:11:10+00:00 urn:sha1:7e4edbdd1b4d2fa97478fc16be2efff4de9afdf9 llvm-svn: 344944 2018-09-15T02:34:45+00:00 George Karpenkov ekarpenkov@apple.com 2018-09-15T02:34:45+00:00 urn:sha1:64c431c90095995a6bad74c34ce03367f09e5fa4 skip pointers whenever redundant, use unique prefixes. Differential Revision: https://reviews.llvm.org/D52114 llvm-svn: 342316 2018-07-19T17:03:12+00:00 Mikhail R. Gadelha mikhail.ramalho@gmail.com 2018-07-19T17:03:12+00:00 urn:sha1:ddd4229cc402cc74c656501614f694c977f45519 Summary: This patch introduces a new member to SymExpr, which stores the symbol complexity, avoiding recalculating it every time computeComplexity() is called. Also, increase the complexity of conjured Symbols by one, so it's clear that it has a greater complexity than its underlying symbols. Reviewers: NoQ, george.karpenkov Reviewed By: NoQ, george.karpenkov Subscribers: xazax.hun, szepet, a.sidorin Differential Revision: https://reviews.llvm.org/D49232 llvm-svn: 337472 2018-06-27T01:51:55+00:00 George Karpenkov ekarpenkov@apple.com 2018-06-27T01:51:55+00:00 urn:sha1:dd18b11b8e0ad9e8ff7e2d1bc3ebdc3c690e97ed Differential Revision: https://reviews.llvm.org/D44756 llvm-svn: 335701 2018-03-06T00:47:41+00:00 Eugene Zelenko eugene.zelenko@gmail.com 2018-03-06T00:47:41+00:00 urn:sha1:b8b9af2ad46ff1ed901956c155c48c15cb585fa9 llvm-svn: 326757 2017-10-19T11:58:21+00:00 Gabor Horvath xazax.hun@gmail.com 2017-10-19T11:58:21+00:00 urn:sha1:d3a85702310f686e380b599fc3429b5bb51d69be Patch by: Adam Balogh! Differential Revision: https://reviews.llvm.org/D39048 llvm-svn: 316157 2016-12-05T20:30:11+00:00 Dominic Chen d.c.ddcc@gmail.com 2016-12-05T20:30:11+00:00 urn:sha1:0dd2306538e48c69bb41d2e3f81f25acedb18af6 Reviewers: NoQ, dcoughlin, zaks.anna Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D27365 llvm-svn: 288696