maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/CoverageMapping/macro-expressions.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

149 lines
6.0 KiB
C++
Raw Normal View History

[Coverage] Add empty line regions to SkippedRegions Differential Revision: https://reviews.llvm.org/D84988
2020-09-03 05:50:32 +08:00
// RUN: %clang_cc1 -mllvm -emptyline-comment-coverage=false -std=c++11 -fprofile-instrument=clang -fcoverage-mapping -dump-coverage-mapping -emit-llvm-only -main-file-name macro-expressions.cpp -w %s | FileCheck %s
InstrProf: Rewrite most of coverage mapping generation in a simpler way The coverage mapping generation code previously generated a large number of redundant coverage regions and then tried to merge similar ones back together. This then relied on some awkward heuristics to prevent combining of regions that were importantly different but happened to have the same count. The end result was inefficient and hard to follow. Now, we more carefully create the regions we actually want. This makes it much easier to create regions at precise locations as well as making the basic approach quite a bit easier to follow. There's still a fair bit of complexity here dealing with included code and macro expansions, but that's pretty hard to avoid without significantly reducing the quality of data we provide. I had to modify quite a few tests where the source ranges became more precise or the old ranges seemed to be wrong anyways, and I've added quite a few new tests since a large number of constructs didn't seem to be tested before. llvm-svn: 229748
2015-02-19 05:24:51 +08:00
#define EXPR(x) (x)
#define NEXPR(x) (!x)
#define DECL(T, x) T x
#define ASSIGN(x, y) x = y
#define LT(x, y) x < y
#define INC(x) ++x
#define ARR(T, x, y, z) (T[3]){x, y, z}
#define PRI_64_LENGTH_MODIFIER "ll"
#define PRIo64 PRI_64_LENGTH_MODIFIER "o"
#define PRIu64 PRI_64_LENGTH_MODIFIER "u"
[Coverage] Fix crash when handling certain macro expansions When handling 'if' statements, we crash if the condition and the consequent branch are spanned by a single macro expansion. The crash occurs because of a sanity 'reset' in popRegions(): if an expansion exactly spans an entire region, we set MostRecentLocation to the start of the expansion (its 'include location'). This ensures we don't handleFileExit() ourselves out of the expansion before we're done processing all of the regions within it. This is tested in test/CoverageMapping/macro-expressions.c. This causes a problem when an expansion spans both the condition and the consequent branch of an 'if' statement. MostRecentLocation is updated to the start of the 'if' statement in popRegions(), so the file for the expansion isn't exited by the time we're done handling the statement. We then crash with 'fatal: File exit not handled before popRegions'. The fix for this is to detect these kinds of expansions, and conservatively update MostRecentLocation to the end of expansion region containing the conditional. I've added tests to make sure we don't have the same problem with other kinds of statements. rdar://problem/23630316 Differential Revision: http://reviews.llvm.org/D16934 llvm-svn: 260129
2016-02-09 03:25:45 +08:00
#define STMT(s) s
void fn1() {
STMT(if (1));
STMT(while (1));
STMT(for (;;));
STMT(if) (1);
STMT(while) (1);
STMT(for) (;;);
if (1)
STMT(if (1)
STMT(if (1)));
if (1)
STMT(if (1)) 0;
if (1)
STMT(while (1)) 0;
if (1)
STMT(for (;;)) 0;
while (1)
STMT(if (1)) 0;
while (1)
STMT(while (1)) 0;
while (1)
STMT(for (;;)) 0;
for (;;)
STMT(if (1)) 0;
for (;;)
STMT(while (1)) 0;
for (;;)
STMT(for (;;)) 0;
}
void STMT(fn2()) {
}
void STMT(fn3)() {
}
InstrProf: Rewrite most of coverage mapping generation in a simpler way The coverage mapping generation code previously generated a large number of redundant coverage regions and then tried to merge similar ones back together. This then relied on some awkward heuristics to prevent combining of regions that were importantly different but happened to have the same count. The end result was inefficient and hard to follow. Now, we more carefully create the regions we actually want. This makes it much easier to create regions at precise locations as well as making the basic approach quite a bit easier to follow. There's still a fair bit of complexity here dealing with included code and macro expansions, but that's pretty hard to avoid without significantly reducing the quality of data we provide. I had to modify quite a few tests where the source ranges became more precise or the old ranges seemed to be wrong anyways, and I've added quite a few new tests since a large number of constructs didn't seem to be tested before. llvm-svn: 229748
2015-02-19 05:24:51 +08:00
// CHECK: foo
// CHECK-NEXT: File 0, [[@LINE+1]]:17 -> {{[0-9]+}}:2 = #0
void foo(int i) {
[Coverage] Emit gap region after conditions when macro is present.
2021-02-18 10:16:40 +08:00
// CHECK-NEXT: File 0, [[@LINE+3]]:7 -> [[@LINE+3]]:8 = #0
// CHECK: Gap,File 0, [[@LINE+2]]:9 -> [[@LINE+2]]:10 = #1
// CHECK-NEXT: File 0, [[@LINE+1]]:10 -> [[@LINE+1]]:12 = #1
InstrProf: Rewrite most of coverage mapping generation in a simpler way The coverage mapping generation code previously generated a large number of redundant coverage regions and then tried to merge similar ones back together. This then relied on some awkward heuristics to prevent combining of regions that were importantly different but happened to have the same count. The end result was inefficient and hard to follow. Now, we more carefully create the regions we actually want. This makes it much easier to create regions at precise locations as well as making the basic approach quite a bit easier to follow. There's still a fair bit of complexity here dealing with included code and macro expansions, but that's pretty hard to avoid without significantly reducing the quality of data we provide. I had to modify quite a few tests where the source ranges became more precise or the old ranges seemed to be wrong anyways, and I've added quite a few new tests since a large number of constructs didn't seem to be tested before. llvm-svn: 229748
2015-02-19 05:24:51 +08:00
if (0) {}
[Coverage] Emit gap region after conditions when macro is present.
2021-02-18 10:16:40 +08:00
// CHECK-NEXT: Expansion,File 0, [[@LINE+3]]:7 -> [[@LINE+3]]:11 = #0
// CHECK-NEXT: Gap,File 0, [[@LINE+2]]:15 -> [[@LINE+2]]:16 = #2
InstrProf: Rewrite most of coverage mapping generation in a simpler way The coverage mapping generation code previously generated a large number of redundant coverage regions and then tried to merge similar ones back together. This then relied on some awkward heuristics to prevent combining of regions that were importantly different but happened to have the same count. The end result was inefficient and hard to follow. Now, we more carefully create the regions we actually want. This makes it much easier to create regions at precise locations as well as making the basic approach quite a bit easier to follow. There's still a fair bit of complexity here dealing with included code and macro expansions, but that's pretty hard to avoid without significantly reducing the quality of data we provide. I had to modify quite a few tests where the source ranges became more precise or the old ranges seemed to be wrong anyways, and I've added quite a few new tests since a large number of constructs didn't seem to be tested before. llvm-svn: 229748
2015-02-19 05:24:51 +08:00
// CHECK-NEXT: File 0, [[@LINE+1]]:16 -> [[@LINE+1]]:18 = #2
if (EXPR(i)) {}
[Coverage] Emit gap region after conditions when macro is present.
2021-02-18 10:16:40 +08:00
// CHECK-NEXT: Expansion,File 0, [[@LINE+3]]:9 -> [[@LINE+3]]:14 = (#0 + #3)
// CHECK-NEXT: Gap,File 0, [[@LINE+2]]:19 -> [[@LINE+2]]:20 = #3
// CHECK-NEXT: File 0, [[@LINE+1]]:20 -> [[@LINE+1]]:22 = #3
InstrProf: Rewrite most of coverage mapping generation in a simpler way The coverage mapping generation code previously generated a large number of redundant coverage regions and then tried to merge similar ones back together. This then relied on some awkward heuristics to prevent combining of regions that were importantly different but happened to have the same count. The end result was inefficient and hard to follow. Now, we more carefully create the regions we actually want. This makes it much easier to create regions at precise locations as well as making the basic approach quite a bit easier to follow. There's still a fair bit of complexity here dealing with included code and macro expansions, but that's pretty hard to avoid without significantly reducing the quality of data we provide. I had to modify quite a few tests where the source ranges became more precise or the old ranges seemed to be wrong anyways, and I've added quite a few new tests since a large number of constructs didn't seem to be tested before. llvm-svn: 229748
2015-02-19 05:24:51 +08:00
for (;NEXPR(i);) {}
[Coverage] Emit gap region after conditions when macro is present.
2021-02-18 10:16:40 +08:00
// CHECK-NEXT: Expansion,File 0, [[@LINE+5]]:8 -> [[@LINE+5]]:14 = #0
// CHECK-NEXT: Expansion,File 0, [[@LINE+4]]:33 -> [[@LINE+4]]:35 = (#0 + #4)
// CHECK-NEXT: Expansion,File 0, [[@LINE+3]]:43 -> [[@LINE+3]]:46 = #4
// CHECK-NEXT: Gap,File 0, [[@LINE+2]]:50 -> [[@LINE+2]]:51 = #4
[Coverage] Emit gap areas in braces-optional statements (PR35387) 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-30 06:25:14 +08:00
// CHECK: File 0, [[@LINE+1]]:51 -> [[@LINE+1]]:53 = #4
InstrProf: Rewrite most of coverage mapping generation in a simpler way The coverage mapping generation code previously generated a large number of redundant coverage regions and then tried to merge similar ones back together. This then relied on some awkward heuristics to prevent combining of regions that were importantly different but happened to have the same count. The end result was inefficient and hard to follow. Now, we more carefully create the regions we actually want. This makes it much easier to create regions at precise locations as well as making the basic approach quite a bit easier to follow. There's still a fair bit of complexity here dealing with included code and macro expansions, but that's pretty hard to avoid without significantly reducing the quality of data we provide. I had to modify quite a few tests where the source ranges became more precise or the old ranges seemed to be wrong anyways, and I've added quite a few new tests since a large number of constructs didn't seem to be tested before. llvm-svn: 229748
2015-02-19 05:24:51 +08:00
for (ASSIGN(DECL(int, j), 0); LT(j, i); INC(j)) {}
// CHECK-NEXT: Expansion,File 0, [[@LINE+1]]:3 -> [[@LINE+1]]:9 = #0
ASSIGN(DECL(int, k), 0);
[Coverage] Emit gap region after conditions when macro is present.
2021-02-18 10:16:40 +08:00
// CHECK-NEXT: Expansion,File 0, [[@LINE+4]]:10 -> [[@LINE+4]]:12 = (#0 + #5)
// CHECK-NEXT: Gap,File 0, [[@LINE+3]]:19 -> [[@LINE+3]]:20 = #5
InstrProf: Rewrite most of coverage mapping generation in a simpler way The coverage mapping generation code previously generated a large number of redundant coverage regions and then tried to merge similar ones back together. This then relied on some awkward heuristics to prevent combining of regions that were importantly different but happened to have the same count. The end result was inefficient and hard to follow. Now, we more carefully create the regions we actually want. This makes it much easier to create regions at precise locations as well as making the basic approach quite a bit easier to follow. There's still a fair bit of complexity here dealing with included code and macro expansions, but that's pretty hard to avoid without significantly reducing the quality of data we provide. I had to modify quite a few tests where the source ranges became more precise or the old ranges seemed to be wrong anyways, and I've added quite a few new tests since a large number of constructs didn't seem to be tested before. llvm-svn: 229748
2015-02-19 05:24:51 +08:00
// CHECK-NEXT: File 0, [[@LINE+2]]:20 -> [[@LINE+2]]:31 = #5
// CHECK-NEXT: Expansion,File 0, [[@LINE+1]]:22 -> [[@LINE+1]]:25 = #5
while (LT(k, i)) { INC(k); }
// CHECK-NEXT: File 0, [[@LINE+2]]:6 -> [[@LINE+2]]:8 = (#0 + #6)
// CHECK-NEXT: Expansion,File 0, [[@LINE+1]]:16 -> [[@LINE+1]]:21 = (#0 + #6)
do {} while (NEXPR(i));
[Coverage] Emit gap region after conditions when macro is present.
2021-02-18 10:16:40 +08:00
// CHECK-NEXT: Expansion,File 0, [[@LINE+5]]:8 -> [[@LINE+5]]:12 = #0
// CHECK-NEXT: Branch,File 0, [[@LINE+4]]:21 -> [[@LINE+4]]:22 = #7, #0
// CHECK-NEXT: Expansion,File 0, [[@LINE+3]]:23 -> [[@LINE+3]]:26 = #0
// CHECK-NEXT: Gap,File 0, [[@LINE+2]]:41 -> [[@LINE+2]]:42 = #7
[Coverage] Emit gap areas in braces-optional statements (PR35387) 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-30 06:25:14 +08:00
// CHECK: File 0, [[@LINE+1]]:42 -> [[@LINE+1]]:44 = #7
InstrProf: Rewrite most of coverage mapping generation in a simpler way The coverage mapping generation code previously generated a large number of redundant coverage regions and then tried to merge similar ones back together. This then relied on some awkward heuristics to prevent combining of regions that were importantly different but happened to have the same count. The end result was inefficient and hard to follow. Now, we more carefully create the regions we actually want. This makes it much easier to create regions at precise locations as well as making the basic approach quite a bit easier to follow. There's still a fair bit of complexity here dealing with included code and macro expansions, but that's pretty hard to avoid without significantly reducing the quality of data we provide. I had to modify quite a few tests where the source ranges became more precise or the old ranges seemed to be wrong anyways, and I've added quite a few new tests since a large number of constructs didn't seem to be tested before. llvm-svn: 229748
2015-02-19 05:24:51 +08:00
for (DECL(int, j) : ARR(int, 1, 2, 3)) {}
[Coverage] Emit gap region after conditions when macro is present.
2021-02-18 10:16:40 +08:00
// CHECK-NEXT: File 0, [[@LINE+5]]:10 -> [[@LINE+5]]:11 = #0
// CHECK-NEXT: Branch,File 0, [[@LINE+4]]:10 -> [[@LINE+4]]:11 = #8, (#0 - #8)
// CHECK-NEXT: Gap,File 0, [[@LINE+3]]:13 -> [[@LINE+3]]:14 = #8
InstrProf: Fix coverage maps for conditional operators This fixes a crash when we're emitting coverage and a macro appears between two binary conditional operators, ie, "foo ?: MACRO ?: bar", and fixes the interaction of macros and conditional operators in general. llvm-svn: 235793
2015-04-25 07:37:57 +08:00
// CHECK-NEXT: Expansion,File 0, [[@LINE+2]]:14 -> [[@LINE+2]]:20 = #0
InstrProf: Rewrite most of coverage mapping generation in a simpler way The coverage mapping generation code previously generated a large number of redundant coverage regions and then tried to merge similar ones back together. This then relied on some awkward heuristics to prevent combining of regions that were importantly different but happened to have the same count. The end result was inefficient and hard to follow. Now, we more carefully create the regions we actually want. This makes it much easier to create regions at precise locations as well as making the basic approach quite a bit easier to follow. There's still a fair bit of complexity here dealing with included code and macro expansions, but that's pretty hard to avoid without significantly reducing the quality of data we provide. I had to modify quite a few tests where the source ranges became more precise or the old ranges seemed to be wrong anyways, and I've added quite a few new tests since a large number of constructs didn't seem to be tested before. llvm-svn: 229748
2015-02-19 05:24:51 +08:00
// CHECK-NEXT: Expansion,File 0, [[@LINE+1]]:23 -> [[@LINE+1]]:29 = #0
(void)(i ? PRIo64 : PRIu64);
InstrProf: Fix coverage maps for conditional operators This fixes a crash when we're emitting coverage and a macro appears between two binary conditional operators, ie, "foo ?: MACRO ?: bar", and fixes the interaction of macros and conditional operators in general. llvm-svn: 235793
2015-04-25 07:37:57 +08:00
[Coverage] Propogate counter to condition of conditional operator Clang usually propagates counter mapping region for conditions of `if`, `while`, `for`, etc from parent counter. We should do the same for condition of conditional operator. Differential Revision: https://reviews.llvm.org/D95918
2021-02-03 12:43:13 +08:00
// CHECK-NEXT: File 0, [[@LINE+6]]:10 -> [[@LINE+6]]:11 = #0
[Coverage] Emit a gap area after if conditions 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-11-09 10:33:38 +08:00
// CHECK: File 0, [[@LINE+5]]:14 -> [[@LINE+5]]:15 = #9
[Coverage] Propogate counter to condition of conditional operator Clang usually propagates counter mapping region for conditions of `if`, `while`, `for`, etc from parent counter. We should do the same for condition of conditional operator. Differential Revision: https://reviews.llvm.org/D95918
2021-02-03 12:43:13 +08:00
// CHECK-NEXT: File 0, [[@LINE+4]]:18 -> [[@LINE+4]]:33 = (#0 - #9)
// CHECK-NEXT: Expansion,File 0, [[@LINE+3]]:18 -> [[@LINE+3]]:22 = (#0 - #9)
[Coverage] Emit a gap area after if conditions 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-11-09 10:33:38 +08:00
// CHECK: File 0, [[@LINE+2]]:28 -> [[@LINE+2]]:29 = #10
InstrProf: Fix coverage maps for conditional operators This fixes a crash when we're emitting coverage and a macro appears between two binary conditional operators, ie, "foo ?: MACRO ?: bar", and fixes the interaction of macros and conditional operators in general. llvm-svn: 235793
2015-04-25 07:37:57 +08:00
// CHECK-NEXT: File 0, [[@LINE+1]]:32 -> [[@LINE+1]]:33 = ((#0 - #9) - #10)
(void)(i ? i : EXPR(i) ? i : 0);
[Coverage] Propogate counter to condition of conditional operator Clang usually propagates counter mapping region for conditions of `if`, `while`, `for`, etc from parent counter. We should do the same for condition of conditional operator. Differential Revision: https://reviews.llvm.org/D95918
2021-02-03 12:43:13 +08:00
// CHECK-NEXT: File 0, [[@LINE+5]]:10 -> [[@LINE+5]]:11 = #0
[Coverage] Add support for Branch Coverage in LLVM Source-Based Code Coverage This is an enhancement to LLVM Source-Based Code Coverage in clang to track how many times individual branch-generating conditions are taken (evaluate to TRUE) and not taken (evaluate to FALSE). Individual conditions may comprise larger boolean expressions using boolean logical operators. This functionality is very similar to what is supported by GCOV except that it is very closely anchored to the ASTs. Differential Revision: https://reviews.llvm.org/D84467
2020-12-29 01:20:48 +08:00
// CHECK-NEXT: Branch,File 0, [[@LINE+4]]:10 -> [[@LINE+4]]:11 = #11, (#0 - #11)
[Coverage] Propogate counter to condition of conditional operator Clang usually propagates counter mapping region for conditions of `if`, `while`, `for`, etc from parent counter. We should do the same for condition of conditional operator. Differential Revision: https://reviews.llvm.org/D95918
2021-02-03 12:43:13 +08:00
// CHECK-NEXT: File 0, [[@LINE+3]]:15 -> [[@LINE+3]]:27 = (#0 - #11)
// CHECK-NEXT: Expansion,File 0, [[@LINE+2]]:15 -> [[@LINE+2]]:19 = (#0 - #11)
InstrProf: Fix coverage maps for conditional operators This fixes a crash when we're emitting coverage and a macro appears between two binary conditional operators, ie, "foo ?: MACRO ?: bar", and fixes the interaction of macros and conditional operators in general. llvm-svn: 235793
2015-04-25 07:37:57 +08:00
// CHECK-NEXT: File 0, [[@LINE+1]]:26 -> [[@LINE+1]]:27 = ((#0 - #11) - #12)
(void)(i ?: EXPR(i) ?: 0);
InstrProf: Rewrite most of coverage mapping generation in a simpler way The coverage mapping generation code previously generated a large number of redundant coverage regions and then tried to merge similar ones back together. This then relied on some awkward heuristics to prevent combining of regions that were importantly different but happened to have the same count. The end result was inefficient and hard to follow. Now, we more carefully create the regions we actually want. This makes it much easier to create regions at precise locations as well as making the basic approach quite a bit easier to follow. There's still a fair bit of complexity here dealing with included code and macro expansions, but that's pretty hard to avoid without significantly reducing the quality of data we provide. I had to modify quite a few tests where the source ranges became more precise or the old ranges seemed to be wrong anyways, and I've added quite a few new tests since a large number of constructs didn't seem to be tested before. llvm-svn: 229748
2015-02-19 05:24:51 +08:00
}
// CHECK-NEXT: File {{[0-9]+}}, 3:17 -> 3:20 = #0
[Coverage] Add support for Branch Coverage in LLVM Source-Based Code Coverage This is an enhancement to LLVM Source-Based Code Coverage in clang to track how many times individual branch-generating conditions are taken (evaluate to TRUE) and not taken (evaluate to FALSE). Individual conditions may comprise larger boolean expressions using boolean logical operators. This functionality is very similar to what is supported by GCOV except that it is very closely anchored to the ASTs. Differential Revision: https://reviews.llvm.org/D84467
2020-12-29 01:20:48 +08:00
// CHECK-NEXT: Branch,File {{[0-9]+}}, 3:17 -> 3:20 = #2, (#0 - #2)
InstrProf: Rewrite most of coverage mapping generation in a simpler way The coverage mapping generation code previously generated a large number of redundant coverage regions and then tried to merge similar ones back together. This then relied on some awkward heuristics to prevent combining of regions that were importantly different but happened to have the same count. The end result was inefficient and hard to follow. Now, we more carefully create the regions we actually want. This makes it much easier to create regions at precise locations as well as making the basic approach quite a bit easier to follow. There's still a fair bit of complexity here dealing with included code and macro expansions, but that's pretty hard to avoid without significantly reducing the quality of data we provide. I had to modify quite a few tests where the source ranges became more precise or the old ranges seemed to be wrong anyways, and I've added quite a few new tests since a large number of constructs didn't seem to be tested before. llvm-svn: 229748
2015-02-19 05:24:51 +08:00
// CHECK-NEXT: File {{[0-9]+}}, 4:18 -> 4:22 = (#0 + #3)
[Coverage] Add support for Branch Coverage in LLVM Source-Based Code Coverage This is an enhancement to LLVM Source-Based Code Coverage in clang to track how many times individual branch-generating conditions are taken (evaluate to TRUE) and not taken (evaluate to FALSE). Individual conditions may comprise larger boolean expressions using boolean logical operators. This functionality is very similar to what is supported by GCOV except that it is very closely anchored to the ASTs. Differential Revision: https://reviews.llvm.org/D84467
2020-12-29 01:20:48 +08:00
// CHECK-NEXT: Branch,File {{[0-9]+}}, 4:18 -> 4:22 = #3, #0
InstrProf: Rewrite most of coverage mapping generation in a simpler way The coverage mapping generation code previously generated a large number of redundant coverage regions and then tried to merge similar ones back together. This then relied on some awkward heuristics to prevent combining of regions that were importantly different but happened to have the same count. The end result was inefficient and hard to follow. Now, we more carefully create the regions we actually want. This makes it much easier to create regions at precise locations as well as making the basic approach quite a bit easier to follow. There's still a fair bit of complexity here dealing with included code and macro expansions, but that's pretty hard to avoid without significantly reducing the quality of data we provide. I had to modify quite a few tests where the source ranges became more precise or the old ranges seemed to be wrong anyways, and I've added quite a few new tests since a large number of constructs didn't seem to be tested before. llvm-svn: 229748
2015-02-19 05:24:51 +08:00
// CHECK-NEXT: File {{[0-9]+}}, 6:22 -> 6:27 = #0
// CHECK-NEXT: File {{[0-9]+}}, 8:16 -> 8:19 = #4
// CHECK-NEXT: File {{[0-9]+}}, 7:18 -> 7:23 = (#0 + #4)
[Coverage] Add support for Branch Coverage in LLVM Source-Based Code Coverage This is an enhancement to LLVM Source-Based Code Coverage in clang to track how many times individual branch-generating conditions are taken (evaluate to TRUE) and not taken (evaluate to FALSE). Individual conditions may comprise larger boolean expressions using boolean logical operators. This functionality is very similar to what is supported by GCOV except that it is very closely anchored to the ASTs. Differential Revision: https://reviews.llvm.org/D84467
2020-12-29 01:20:48 +08:00
// CHECK-NEXT: Branch,File {{[0-9]+}}, 7:18 -> 7:23 = #4, #0
InstrProf: Rewrite most of coverage mapping generation in a simpler way The coverage mapping generation code previously generated a large number of redundant coverage regions and then tried to merge similar ones back together. This then relied on some awkward heuristics to prevent combining of regions that were importantly different but happened to have the same count. The end result was inefficient and hard to follow. Now, we more carefully create the regions we actually want. This makes it much easier to create regions at precise locations as well as making the basic approach quite a bit easier to follow. There's still a fair bit of complexity here dealing with included code and macro expansions, but that's pretty hard to avoid without significantly reducing the quality of data we provide. I had to modify quite a few tests where the source ranges became more precise or the old ranges seemed to be wrong anyways, and I've added quite a few new tests since a large number of constructs didn't seem to be tested before. llvm-svn: 229748
2015-02-19 05:24:51 +08:00
// CHECK-NEXT: File {{[0-9]+}}, 6:22 -> 6:27 = #0
// CHECK-NEXT: File {{[0-9]+}}, 8:16 -> 8:19 = #5
// CHECK-NEXT: File {{[0-9]+}}, 7:18 -> 7:23 = (#0 + #5)
[Coverage] Add support for Branch Coverage in LLVM Source-Based Code Coverage This is an enhancement to LLVM Source-Based Code Coverage in clang to track how many times individual branch-generating conditions are taken (evaluate to TRUE) and not taken (evaluate to FALSE). Individual conditions may comprise larger boolean expressions using boolean logical operators. This functionality is very similar to what is supported by GCOV except that it is very closely anchored to the ASTs. Differential Revision: https://reviews.llvm.org/D84467
2020-12-29 01:20:48 +08:00
// CHECK-NEXT: Branch,File {{[0-9]+}}, 7:18 -> 7:23 = #5, #0
InstrProf: Rewrite most of coverage mapping generation in a simpler way The coverage mapping generation code previously generated a large number of redundant coverage regions and then tried to merge similar ones back together. This then relied on some awkward heuristics to prevent combining of regions that were importantly different but happened to have the same count. The end result was inefficient and hard to follow. Now, we more carefully create the regions we actually want. This makes it much easier to create regions at precise locations as well as making the basic approach quite a bit easier to follow. There's still a fair bit of complexity here dealing with included code and macro expansions, but that's pretty hard to avoid without significantly reducing the quality of data we provide. I had to modify quite a few tests where the source ranges became more precise or the old ranges seemed to be wrong anyways, and I've added quite a few new tests since a large number of constructs didn't seem to be tested before. llvm-svn: 229748
2015-02-19 05:24:51 +08:00
// CHECK-NEXT: File {{[0-9]+}}, 4:18 -> 4:22 = (#0 + #6)
[Coverage] Add support for Branch Coverage in LLVM Source-Based Code Coverage This is an enhancement to LLVM Source-Based Code Coverage in clang to track how many times individual branch-generating conditions are taken (evaluate to TRUE) and not taken (evaluate to FALSE). Individual conditions may comprise larger boolean expressions using boolean logical operators. This functionality is very similar to what is supported by GCOV except that it is very closely anchored to the ASTs. Differential Revision: https://reviews.llvm.org/D84467
2020-12-29 01:20:48 +08:00
// CHECK-NEXT: Branch,File {{[0-9]+}}, 4:18 -> 4:22 = #6, #0
InstrProf: Rewrite most of coverage mapping generation in a simpler way The coverage mapping generation code previously generated a large number of redundant coverage regions and then tried to merge similar ones back together. This then relied on some awkward heuristics to prevent combining of regions that were importantly different but happened to have the same count. The end result was inefficient and hard to follow. Now, we more carefully create the regions we actually want. This makes it much easier to create regions at precise locations as well as making the basic approach quite a bit easier to follow. There's still a fair bit of complexity here dealing with included code and macro expansions, but that's pretty hard to avoid without significantly reducing the quality of data we provide. I had to modify quite a few tests where the source ranges became more precise or the old ranges seemed to be wrong anyways, and I've added quite a few new tests since a large number of constructs didn't seem to be tested before. llvm-svn: 229748
2015-02-19 05:24:51 +08:00
// CHECK-NEXT: File {{[0-9]+}}, 5:20 -> 5:23 = #0
// CHECK-NEXT: File {{[0-9]+}}, 9:25 -> 9:40 = #0
InstrProf: Fix coverage maps for conditional operators This fixes a crash when we're emitting coverage and a macro appears between two binary conditional operators, ie, "foo ?: MACRO ?: bar", and fixes the interaction of macros and conditional operators in general. llvm-svn: 235793
2015-04-25 07:37:57 +08:00
// CHECK-NEXT: File {{[0-9]+}}, 12:16 -> 12:42 = #0
InstrProf: Rewrite most of coverage mapping generation in a simpler way The coverage mapping generation code previously generated a large number of redundant coverage regions and then tried to merge similar ones back together. This then relied on some awkward heuristics to prevent combining of regions that were importantly different but happened to have the same count. The end result was inefficient and hard to follow. Now, we more carefully create the regions we actually want. This makes it much easier to create regions at precise locations as well as making the basic approach quite a bit easier to follow. There's still a fair bit of complexity here dealing with included code and macro expansions, but that's pretty hard to avoid without significantly reducing the quality of data we provide. I had to modify quite a few tests where the source ranges became more precise or the old ranges seemed to be wrong anyways, and I've added quite a few new tests since a large number of constructs didn't seem to be tested before. llvm-svn: 229748
2015-02-19 05:24:51 +08:00
// CHECK-NEXT: Expansion,File {{[0-9]+}}, 12:16 -> 12:38 = #8
// CHECK-NEXT: File {{[0-9]+}}, 12:38 -> 12:42 = #8
// CHECK-NEXT: File {{[0-9]+}}, 13:16 -> 13:42 = #0
// CHECK-NEXT: Expansion,File {{[0-9]+}}, 13:16 -> 13:38 = (#0 - #8)
// CHECK-NEXT: File {{[0-9]+}}, 13:38 -> 13:42 = (#0 - #8)
InstrProf: Fix coverage maps for conditional operators This fixes a crash when we're emitting coverage and a macro appears between two binary conditional operators, ie, "foo ?: MACRO ?: bar", and fixes the interaction of macros and conditional operators in general. llvm-svn: 235793
2015-04-25 07:37:57 +08:00
// CHECK-NEXT: File {{[0-9]+}}, 3:17 -> 3:20 = (#0 - #9)
[Coverage] Add support for Branch Coverage in LLVM Source-Based Code Coverage This is an enhancement to LLVM Source-Based Code Coverage in clang to track how many times individual branch-generating conditions are taken (evaluate to TRUE) and not taken (evaluate to FALSE). Individual conditions may comprise larger boolean expressions using boolean logical operators. This functionality is very similar to what is supported by GCOV except that it is very closely anchored to the ASTs. Differential Revision: https://reviews.llvm.org/D84467
2020-12-29 01:20:48 +08:00
// CHECK-NEXT: Branch,File {{[0-9]+}}, 3:17 -> 3:20 = #10, ((#0 - #9) - #10)
InstrProf: Fix coverage maps for conditional operators This fixes a crash when we're emitting coverage and a macro appears between two binary conditional operators, ie, "foo ?: MACRO ?: bar", and fixes the interaction of macros and conditional operators in general. llvm-svn: 235793
2015-04-25 07:37:57 +08:00
// CHECK-NEXT: File {{[0-9]+}}, 3:17 -> 3:20 = (#0 - #11)
[Coverage] Add support for Branch Coverage in LLVM Source-Based Code Coverage This is an enhancement to LLVM Source-Based Code Coverage in clang to track how many times individual branch-generating conditions are taken (evaluate to TRUE) and not taken (evaluate to FALSE). Individual conditions may comprise larger boolean expressions using boolean logical operators. This functionality is very similar to what is supported by GCOV except that it is very closely anchored to the ASTs. Differential Revision: https://reviews.llvm.org/D84467
2020-12-29 01:20:48 +08:00
// CHECK-NEXT: Branch,File {{[0-9]+}}, 3:17 -> 3:20 = #12, ((#0 - #11) - #12)
InstrProf: Rewrite most of coverage mapping generation in a simpler way The coverage mapping generation code previously generated a large number of redundant coverage regions and then tried to merge similar ones back together. This then relied on some awkward heuristics to prevent combining of regions that were importantly different but happened to have the same count. The end result was inefficient and hard to follow. Now, we more carefully create the regions we actually want. This makes it much easier to create regions at precise locations as well as making the basic approach quite a bit easier to follow. There's still a fair bit of complexity here dealing with included code and macro expansions, but that's pretty hard to avoid without significantly reducing the quality of data we provide. I had to modify quite a few tests where the source ranges became more precise or the old ranges seemed to be wrong anyways, and I've added quite a few new tests since a large number of constructs didn't seem to be tested before. llvm-svn: 229748
2015-02-19 05:24:51 +08:00
// CHECK-NEXT: File {{[0-9]+}}, 11:32 -> 11:36 = #8
// CHECK-NEXT: File {{[0-9]+}}, 11:32 -> 11:36 = (#0 - #8)
// CHECK-NOT: File {{[0-9]+}},
// CHECK: main
int main(int argc, const char *argv[]) {
foo(10);
}