Project Ortega BCM5719 LLVM https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.0 2018-06-01T17:11:18+00:00 2018-06-01T17:11:18+00:00 Vedant Kumar vsk@apple.com 2018-06-01T17:11:18+00:00 urn:sha1:fd657bd4be4392c5c5d7c0040fbf7b4189b651a4 This should address a bot failure: http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/9994/ llvm-svn: 333775 2018-06-01T00:37:13+00:00 Vedant Kumar vsk@apple.com 2018-06-01T00:37:13+00:00 urn:sha1:d781d97ed45259809bc19d97a77fde508e2a036d A deferred region should end before the start of a label, and should not extend to the start of the label sub-statement. Fixes llvm.org/PR35867. llvm-svn: 333715 2018-05-30T23:35:44+00:00 Vedant Kumar vsk@apple.com 2018-05-30T23:35:44+00:00 urn:sha1:61763b65af94107b75ec5be8797b7a845c626930 Discard the last uncompleted deferred region in a decl, if one exists. This prevents lines at the end of a function containing only whitespace or closing braces from being marked as uncovered, if they follow a region terminator (return/break/etc). The previous behavior was to heuristically complete deferred regions at the end of a decl. In practice this ended up being too brittle for too little gain. Users would complain that there was no way to reach full code coverage because whitespace at the end of a function would be marked uncovered. rdar://40238228 Differential Revision: https://reviews.llvm.org/D46918 llvm-svn: 333609 2017-11-29T22:25:14+00:00 Vedant Kumar vsk@apple.com 2017-11-29T22:25:14+00:00 urn:sha1:fa8fa044ec46b94e64971efa8852df0d58114062 Emit a gap area starting after the r-paren location and ending at the start of the body for the braces-optional statements (for, for-each, while, etc). The count for the gap area equal to the body's count. This extends the fix in r317758. Fixes PR35387, rdar://35570345 Testing: stage2 coverage-enabled build of clang, check-clang llvm-svn: 319373 2017-11-09T02:33:39+00:00 Vedant Kumar vsk@apple.com 2017-11-09T02:33:39+00:00 urn:sha1:8046d22a36eeed2bf38d17006daf486acf520f7e The area immediately after a terminated region in the function top-level should have the same count as the label it precedes. This solves another problem with wrapped segments. Consider: 1| a: 2| return 0; 3| b: 4| return 1; Without a gap area starting after the first return, the wrapped segment from line 2 would make it look like line 3 is executed, when it's not. rdar://35373009 llvm-svn: 317759 2017-11-09T02:33:38+00:00 Vedant Kumar vsk@apple.com 2017-11-09T02:33:38+00:00 urn:sha1:2e8c87590546477736d6744edf8f5cf48bf1ef41 The area immediately after the closing right-paren of an if condition should have a count equal to the 'then' block's count. Use a gap region to set this count, so that region highlighting for the 'then' block remains precise. This solves a problem we have with wrapped segments. Consider: 1| if (false) 2| foo(); Without a gap area starting after the condition, the wrapped segment from line 1 would make it look like line 2 is executed, when it's not. rdar://35373009 llvm-svn: 317758 2017-09-08T18:44:56+00:00 Vedant Kumar vsk@apple.com 2017-09-08T18:44:56+00:00 urn:sha1:747b0e2905dc8a2b25d5ae97f5008efcd831795b The current coverage implementation doesn't handle region termination very precisely. Take for example an `if' statement with a `return': void f() { if (true) { return; // The `if' body's region is terminated here. } // This line gets the same coverage as the `if' condition. } If the function `f' is called, the line containing the comment will be marked as having executed once, which is not correct. The solution here is to create a deferred region after terminating a region. The deferred region is completed once the start location of the next statement is known, and is then pushed onto the region stack. In the cases where it's not possible to complete a deferred region, it can safely be dropped. Testing: lit test updates, a stage2 coverage-enabled build of clang This is a reapplication but there are no changes from the original commit. With D36813, the segment builder in llvm will be able to handle deferred regions correctly. llvm-svn: 312818 2017-08-05T00:34:10+00:00 Vedant Kumar vsk@apple.com 2017-08-05T00:34:10+00:00 urn:sha1:a7764adcbb3d6fa3f41d3af50d974d6502bf6981 This reverts commit r310010. I don't think there's anything wrong with this commit, but it's causing clang to generate output that llvm-cov doesn't do a good job with and the fix isn't immediately clear. See Eli's comment in D36250 for more context. I'm reverting the clang change so the coverage bot can revert back to producing sensible output, and to give myself some time to investigate what went wrong in llvm. llvm-svn: 310154 2017-08-04T00:29:20+00:00 Vedant Kumar vsk@apple.com 2017-08-04T00:29:20+00:00 urn:sha1:85e6dce1ebfc714b975a023e59054ab2bdc979bc The current coverage implementation doesn't handle region termination very precisely. Take for example an `if' statement with a `return': void f() { if (true) { return; // The `if' body's region is terminated here. } // This line gets the same coverage as the `if' condition. } If the function `f' is called, the line containing the comment will be marked as having executed once, which is not correct. The solution here is to create a deferred region after terminating a region. The deferred region is completed once the start location of the next statement is known, and is then pushed onto the region stack. In the cases where it's not possible to complete a deferred region, it can safely be dropped. Testing: lit test updates, a stage2 coverage-enabled build of clang llvm-svn: 310010 2016-02-04T18:39:09+00:00 Rong Xu xur@google.com 2016-02-04T18:39:09+00:00 urn:sha1:9837ef56b45486930a50f4c0b31c37d4f71be957 This patch changes cc1 option -fprofile-instr-generate to an enum option -fprofile-instrument={clang|none}. It also changes cc1 options -fprofile-instr-generate= to -fprofile-instrument-path=. The driver level option -fprofile-instr-generate and -fprofile-instr-generate= remain intact. This change will pave the way to integrate new PGO instrumentation in IR level. Review: http://reviews.llvm.org/D16730 llvm-svn: 259811