On 5/8/24 15:29, Richard Biener wrote:
On Fri, Mar 29, 2024 at 8:02 PM Jørgen Kvalsvik wrote:
This is a prototype for --include/--exclude flags, and I would like a
review of both the approach and architecture, and the implementation,
plus feedback on the feature itself. I did not update
On 30/04/2024 13:43, Jan Hubicka wrote:
The problem is testing. If gcc would re-number the basic blocks then
tests comparing hard-coded test paths would break, even though the path
coverage itself would be just fine (and presumably the change to the
basic block indices), which would add an
On 30/04/2024 13:43, Jan Hubicka wrote:
The problem is testing. If gcc would re-number the basic blocks then
tests comparing hard-coded test paths would break, even though the path
coverage itself would be just fine (and presumably the change to the
basic block indices), which would add an
On 30/04/2024 12:45, Richard Biener wrote:
On Tue, Apr 30, 2024 at 11:45 AM Jørgen Kvalsvik wrote:
Hi,
I am working on adding path coverage support to gcc/gcov and need to
develop a good testing strategy.
So far I can reasonably well report on the uncovered path as such:
paths covered 6
Hi,
I am working on adding path coverage support to gcc/gcov and need to
develop a good testing strategy.
So far I can reasonably well report on the uncovered path as such:
paths covered 6 of 17
path not covered: 2 8 3 4
path not covered: 2 8 3 5 6
path not covered: 2 8 3 5 7 10
...
where
Guard the longjmp to not infinitely loop. The longjmp (jump) function is
called unconditionally to make test flow simpler, but the jump
destination would return to a point in main that would call longjmp
again. The longjmp is really there to exercise the then-branch of
setjmp, to verify coverage
On 15/04/2024 13:18, Rainer Orth wrote:
Hi Jørgen,
the new gcc.misc-tests/gcov-22.c test loops on SPARC (both Solaris and
Linux). I've filed PR gcov-profile/114720 for this, but couldn't find
any bugzilla account of yours to Cc:
Rainer
Rainer,
Could you please try this patch? I
On 15/04/2024 10:53, Rainer Orth wrote:
Hi Jørgen,
On 04/04/2024 14:10, Jan Hubicka wrote:
gcc/ChangeLog:
* builtins.cc (expand_builtin_fork_or_exec): Check
condition_coverage_flag.
* collect2.cc (main): Add -fno-condition-coverage to OBSTACK.
* common.opt:
On 15/04/2024 10:53, Rainer Orth wrote:
Hi Jørgen,
On 04/04/2024 14:10, Jan Hubicka wrote:
gcc/ChangeLog:
* builtins.cc (expand_builtin_fork_or_exec): Check
condition_coverage_flag.
* collect2.cc (main): Add -fno-condition-coverage to OBSTACK.
* common.opt:
On 09/04/2024 13:43, Jørgen Kvalsvik wrote:
PR114601 shows that it is possible to reach the condition_uid lookup
without having also created the fn->cond_uids, through
compiler-generated conditionals. Consider all lookups on non-existing
maps misses, which they are from the perspect
PR114601 shows that it is possible to reach the condition_uid lookup
without having also created the fn->cond_uids, through
compiler-generated conditionals. Consider all lookups on non-existing
maps misses, which they are from the perspective of the source code, to
avoid the NULL access.
On 09/04/2024 09:40, Richard Biener wrote:
On Mon, 8 Apr 2024, Jørgen Kvalsvik wrote:
Generating the constants used for recording the edges taken for
condition coverage would trigger undefined behavior when an expression
had exactly 64 (== sizeof (1ULL)) conditions, as it would generate
(sizeof uint64_t), by slightly restructuring the loop generating
constants.
This passes check-gcc RUNTESTFLAGS=gcov.exp in my ubsan instrumented
build:
configure --enable-languages=c,c++ --enable-host-shared
--enable-checking=release --disable-multilib
--with-build-config=bootstrap-ubsan
Jørgen
Generating the constants used for recording the edges taken for
condition coverage would trigger undefined behavior when an expression
had exactly 64 (== sizeof (1ULL)) conditions, as it would generate the
constant for the next iteration at the end of the loop body, even if there
was never a next
Properly add the condition -> expression mapping of inlined gconds from
the caller into the callee map. This is a fix for PR114599 that works
beyond fixing the segfault, as the previous fixed copied references to
the source gconds, not the deep copied ones that end up in the calle
body.
The new
On 07/04/2024 08:26, Richard Biener wrote:
Am 06.04.2024 um 22:41 schrieb Jørgen Kvalsvik :
On 06/04/2024 13:15, Jørgen Kvalsvik wrote:
On 06/04/2024 07:50, Richard Biener wrote:
Am 05.04.2024 um 21:59 schrieb Jørgen Kvalsvik :
Hi,
I propose these fixes for the current issues
On 06/04/2024 13:15, Jørgen Kvalsvik wrote:
On 06/04/2024 07:50, Richard Biener wrote:
Am 05.04.2024 um 21:59 schrieb Jørgen Kvalsvik :
Hi,
I propose these fixes for the current issues with the condition
coverage.
Rainer, I propose to simply delete the test with __sigsetjmp. I don't
On 06/04/2024 07:50, Richard Biener wrote:
Am 05.04.2024 um 21:59 schrieb Jørgen Kvalsvik :
Hi,
I propose these fixes for the current issues with the condition
coverage.
Rainer, I propose to simply delete the test with __sigsetjmp. I don't
think it actually detects anything reasonable any
The __sigsetjmp test was added as a regression test, which an early
iteration of the MC/DC support caused an internal compiler error,
triggered by a code path which did not make it through to the final
revision. Since this test really only worked on linux and does not
serve a purpose any more it
When a function is tree-inlined, copy the condition -> expression mapping
from the inlined function into the caller, shifted so uids are not mixed
Tree inlining was always problematic under condition coverage - either
through a nullptr dereference (like in the test case), or through
quietly mixing
and trigger the error.
[1] https://gcc.gnu.org/pipermail/gcc-patches/2024-April/648785.html
Thanks,
Jørgen
Jørgen Kvalsvik (2):
Remove unecessary and broken MC/DC compile test
Copy condition->expr map when inlining [PR114599]
gcc/testsuite/gcc.misc-tests/gcov-19.c | 11 -
On 05/04/2024 16:05, H.J. Lu wrote:
On Fri, Apr 5, 2024 at 6:52 AM Richard Biener wrote:
Am 05.04.2024 um 15:46 schrieb H.J. Lu :
On Fri, Apr 5, 2024 at 1:21 AM Richard Biener wrote:
There's no default bitmap obstack during global CTORs, so allocate the
bitmap locally.
Bootstrap and
On 05/04/2024 16:05, H.J. Lu wrote:
On Fri, Apr 5, 2024 at 6:52 AM Richard Biener wrote:
Am 05.04.2024 um 15:46 schrieb H.J. Lu :
On Fri, Apr 5, 2024 at 1:21 AM Richard Biener wrote:
There's no default bitmap obstack during global CTORs, so allocate the
bitmap locally.
Bootstrap and
On 05/04/2024 15:00, Rainer Orth wrote:
Hi Jørgen,
On 04/04/2024 14:10, Jan Hubicka wrote:
gcc/ChangeLog:
* builtins.cc (expand_builtin_fork_or_exec): Check
condition_coverage_flag.
* collect2.cc (main): Add -fno-condition-coverage to OBSTACK.
* common.opt:
On 04/04/2024 14:10, Jan Hubicka wrote:
gcc/ChangeLog:
* builtins.cc (expand_builtin_fork_or_exec): Check
condition_coverage_flag.
* collect2.cc (main): Add -fno-condition-coverage to OBSTACK.
* common.opt: Add new options -fcondition-coverage and
This is a prototype for --include/--exclude flags, and I would like a
review of both the approach and architecture, and the implementation,
plus feedback on the feature itself. I did not update the manuals or
carefully extend --help, in case the interface itself needs some
revision before it can
The gcov function summaries only output the covered lines, not the
branches and calls. Since the function summaries is an opt-in it
probably makes sense to also include branch coverage. Simply adds the
branch- and call information to the function-summaries output.
$ gcc --coverage hello.c -o
This is a mostly straight port from the gcov-19.c tests from the C test
suite. The only notable differences from C to D are that D flips the
true/false outcomes for loop headers, and the D front end ties loop and
ternary conditions to slightly different locus.
The test for >64 conditions warning
On 22/02/2024 14:26, Jan Hubicka wrote:
Hello,
This patch adds support in gcc+gcov for modified condition/decision
coverage (MC/DC) with the -fcondition-coverage flag. MC/DC is a type of
test/code coverage and it is particularly important for safety-critical
applicaitons in industries like
This is a mostly straight port from the gcov-19.c tests from the C test
suite. The only notable differences from C to D are that D flips the
true/false outcomes for loop headers, and the D front end ties loop and
ternary conditions to slightly different locus.
The test for >64 conditions warning
On 31/12/2023 10:40, Jan Hubicka wrote:
This seems good. Profile-arcs is rarely used by itself - most of time it
is implied by -fprofile-generate and -ftest-coverage and since
condition coverage is more associated to the second, I guess
-fcondition-coverage is better name.
Since
On 29/12/2023 22:14, Jan Hubicka wrote:
gcc/ChangeLog:
* builtins.cc (expand_builtin_fork_or_exec): Check
condition_coverage_flag.
* collect2.cc (main): Add -fno-condition-coverage to OBSTACK.
* common.opt: Add new options -fcondition-coverage and
This is a mostly straight port from the gcov-19.c tests from the C test
suite. The only notable differences from C to D are that D flips the
true/false outcomes for loop headers, and the D front end ties loop and
ternary conditions to slightly different locus.
The test for >64 conditions warning
On 05/10/2023 22:39, Jørgen Kvalsvik wrote:
On 05/10/2023 21:59, Jan Hubicka wrote:
Like Wahlen et al this implementation records coverage in fixed-size
bitsets which gcov knows how to interpret. This is very fast, but
introduces a limit on the number of terms in a single boolean
expression
ntains a lot of small programs functions. Some of these
were designed by hand to test for specific behaviours and graph shapes,
and some are previously-failed test cases in other programs adapted into
the test suite.
Alternative author email: Jørgen Kvalsvik
gcc/ChangeLog:
* builtins.cc
On 05/10/2023 21:59, Jan Hubicka wrote:
Like Wahlen et al this implementation records coverage in fixed-size
bitsets which gcov knows how to interpret. This is very fast, but
introduces a limit on the number of terms in a single boolean
expression, the number of bits in a gcov_unsigned_type
On 05/10/2023 22:39, Jørgen Kvalsvik wrote:
On 05/10/2023 21:59, Jan Hubicka wrote:
Like Wahlen et al this implementation records coverage in fixed-size
bitsets which gcov knows how to interpret. This is very fast, but
introduces a limit on the number of terms in a single boolean
expression
g the outcome.
The test suite contains a lot of small programs functions. Some of these
were designed by hand to test for specific behaviours and graph shapes,
and some are previously-failed test cases in other programs adapted into
the test suite.
Alternative author email: Jørgen Kvalsvik
gcc/Ch
On 05/10/2023 21:59, Jan Hubicka wrote:
Like Wahlen et al this implementation records coverage in fixed-size
bitsets which gcov knows how to interpret. This is very fast, but
introduces a limit on the number of terms in a single boolean
expression, the number of bits in a gcov_unsigned_type
On 04/10/2023 21:39, Jørgen Kvalsvik wrote:
A check was missing for is-single when contracting, so if a
multi-successor node that was not a condition node (e.g. a switch) a
random edge would be picked and contracted into.
---
gcc/testsuite/gcc.misc-tests/gcov-23.c | 48
On 04/10/2023 21:39, Jørgen Kvalsvik wrote:
Depth first order is insufficient to process expressions in the right
order when there are setjmps in optimized builds. This would create
complex paths from the root past conditions and into the middle of
boolean expressions. Traversing the graph
Depth first order is insufficient to process expressions in the right
order when there are setjmps in optimized builds. This would create
complex paths from the root past conditions and into the middle of
boolean expressions. Traversing the graph in topological order restores
the expectation that
When there was no candidate set reduction phase this was not necessary,
as every neighbor's predecessor would always be in the reachable set.
Now that the graph cut is refined multiple times this may not hold,
which would lead to incorrect termination of the ancestors search when a
node in the
---
gcc/testsuite/g++.dg/gcov/gcov-18.C | 36 +++--
1 file changed, 24 insertions(+), 12 deletions(-)
diff --git a/gcc/testsuite/g++.dg/gcov/gcov-18.C
b/gcc/testsuite/g++.dg/gcov/gcov-18.C
index 310ed5297c0..b58f8450e44 100644
--- a/gcc/testsuite/g++.dg/gcov/gcov-18.C
Some expressions create CFGs isomorphic to those with multi-term
expressions, e.g. if (a) if (b) {} is equivalent to if (a && b) {}, and
there is no real recovery for this. The test is added to 1. document the
behaviour and 2. detect if the cfg generation changes in a way that
(correctly) splits
It always felt odd that the expression candidate set refinement were in
two more-or-less identical phases. It turns out that this is not
necessary and the neighborhood, ancestor filtering, update candidate set
steps can all be done inside a single loop, which terminates when
|NG| == |Outcomes| ==
Search for reachable conditions without limiting the search to the nodes
dominated by the left-most term in the expression. Right operands are
conceptually still always dominated by the left-most term, but in
arbitrary programs there may be complex edges that breaks this.
As it turns out, it is
The presence of gotos already makes this iffy, but it is already not
necessary as reducing by refining the G should cover it.
---
gcc/tree-profile.cc | 19 ---
1 file changed, 19 deletions(-)
diff --git a/gcc/tree-profile.cc b/gcc/tree-profile.cc
index f329be84ad2..d1d7265cd1c
When the coverage and branch profiling preprocessing happens it can
choose to split certain nodes with labels to accuractely track coverage.
These shapes were recongized, but this causes some expressions to be
counted wrong as this graph may be isomorphic with graphs that have not
been split, for
---
gcc/tree-profile.cc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/tree-profile.cc b/gcc/tree-profile.cc
index ce679130ca0..f329be84ad2 100644
--- a/gcc/tree-profile.cc
+++ b/gcc/tree-profile.cc
@@ -784,8 +784,8 @@ isolate_expression (conds_ctx , basic_block p,
From: Jørgen Kvalsvik
---
gcc/gcov.cc | 4
1 file changed, 4 insertions(+)
diff --git a/gcc/gcov.cc b/gcc/gcov.cc
index 95e0a11bc08..62eac76a971 100644
--- a/gcc/gcov.cc
+++ b/gcc/gcov.cc
@@ -3045,6 +3045,10 @@ accumulate_line_counts (source_info *src)
}
}
+/* Output information
A check was missing for is-single when contracting, so if a
multi-successor node that was not a condition node (e.g. a switch) a
random edge would be picked and contracted into.
---
gcc/testsuite/gcc.misc-tests/gcov-23.c | 48 ++
gcc/tree-profile.cc| 4
In complex control flow graphs where gotos and returns escape the inner
then-blocks and the right else-blocks are omitted, inner conditions
would erroneously be considered a part of the outer. By using the
observation that the neighborhood of a proper boolean expression should
always be the two
From: Jørgen Kvalsvik
---
gcc/gcov.cc | 2 ++
1 file changed, 2 insertions(+)
diff --git a/gcc/gcov.cc b/gcc/gcov.cc
index 35be97cf5ac..95e0a11bc08 100644
--- a/gcc/gcov.cc
+++ b/gcc/gcov.cc
@@ -2580,6 +2580,8 @@ add_branch_counts (coverage_info *coverage, const
arc_info *arc
This phase did not at all behave like advertised, which in turn lead to
ICEs for the new tests.
---
gcc/testsuite/gcc.misc-tests/gcov-19.c | 35 +++---
gcc/tree-profile.cc| 29 +++--
2 files changed, 54 insertions(+), 10 deletions(-)
diff
---
gcc/testsuite/gcc.misc-tests/gcov-22.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/gcc/testsuite/gcc.misc-tests/gcov-22.c
b/gcc/testsuite/gcc.misc-tests/gcov-22.c
index 28b7de66022..3737235d40e 100644
--- a/gcc/testsuite/gcc.misc-tests/gcov-22.c
+++
The search for the initial candidate set for a decision is a delicate
affair in complex CFGs with gotos (mostly from returns). Gotos and
returns in the then-block could create graphs where the goto/return edge
would also be searched for candidates for G, even though they can never
be a part of the
From: Jørgen Kvalsvik
---
gcc/gcov.cc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gcc/gcov.cc b/gcc/gcov.cc
index 274f2fc5d9f..35be97cf5ac 100644
--- a/gcc/gcov.cc
+++ b/gcc/gcov.cc
@@ -46,6 +46,7 @@ along with Gcov; see the file COPYING3. If not see
#include "
From: Jørgen Kvalsvik
This patch adds support in gcc+gcov for modified condition/decision
coverage (MC/DC) with the -fprofile-conditions flag. MC/DC is a type of
test/code coverage and it is particularly important in the avation and
automotive industries for safety-critical applications. MC/DC
From: Jørgen Kvalsvik
---
gcc/gcov-dump.cc | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/gcc/gcov-dump.cc b/gcc/gcov-dump.cc
index 65fa2d7b44b..d85fa98ddd5 100644
--- a/gcc/gcov-dump.cc
+++ b/gcc/gcov-dump.cc
@@ -394,14 +394,14 @@ tag_arcs (const char *filename
From: Jørgen Kvalsvik
---
gcc/gcov.cc | 5 +
1 file changed, 5 insertions(+)
diff --git a/gcc/gcov.cc b/gcc/gcov.cc
index 21a6da1a7fa..274f2fc5d9f 100644
--- a/gcc/gcov.cc
+++ b/gcc/gcov.cc
@@ -135,6 +135,8 @@ public:
vector lines;
};
+/* Describes a single conditional expression
From: Jørgen Kvalsvik
---
gcc/doc/gcov.texi | 3 ++-
gcc/doc/invoke.texi | 14 --
2 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/gcc/doc/gcov.texi b/gcc/doc/gcov.texi
index 10cfdcf24aa..f6db593a62a 100644
--- a/gcc/doc/gcov.texi
+++ b/gcc/doc/gcov.texi
@@ -175,7
From: Jørgen Kvalsvik
---
gcc/common.opt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gcc/common.opt b/gcc/common.opt
index 94b1b358585..cd769ad95e0 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -864,7 +864,8 @@ Warn in case a function ends earlier than it begins
This is an extended set of patches with both review feedback from the v4 set,
as well as a few serious bug fixes and improvements, plus test cases.
There has only been a small-ish adjustment to the algorithm itself, in
expression isolation step. Because of gotos this might need to run multiple
On 25/09/2023 19:51, Richard Biener wrote:
On Sun, Sep 24, 2023 at 3:09 PM Jørgen Kvalsvik wrote:
This is a request for feedback and a proof-of-concept, not something I
intend to merge as-is. It would be nice if gcc, maybe just under some
circumstances, always generated an else-block
This is a request for feedback and a proof-of-concept, not something I
intend to merge as-is. It would be nice if gcc, maybe just under some
circumstances, always generated an else-block for coverage purposes.
I am working on the MC/DC support by CFG analysis for a while
On 23/06/2023 19:28, Jan Hubicka wrote:
>>>
>>> gcc/ChangeLog:
>>>
>>> * builtins.cc (expand_builtin_fork_or_exec): Check
>>> profile_condition_flag.
>>> * collect2.cc (main): Add -fno-profile-conditions to OBSTACK.
>>> * common.opt: Add new options -fprofile-conditions and
>>>
On 13/06/2023 09:59, Jørgen Kvalsvik wrote:
> This patch adds support in gcc+gcov for modified condition/decision
> coverage (MC/DC) with the -fprofile-conditions flag. MC/DC is a type of
> test/code coverage and it is particularly important in the avation and
> automotive industrie
isons, and insert an extra instruction for recording the outcome.
The test suite contains a lot of small programs functions. Some of these
were designed by hand to test for specific behaviours and graph shapes,
and some are previously-failed test cases in other programs adapted into
the test suite.
On 11/04/2023 15:23, Jørgen Kvalsvik wrote:
> On 05/12/2022 10:40, Jørgen Kvalsvik wrote:
>> This patch adds support in gcc+gcov for modified condition/decision
>> coverage (MC/DC) with the -fprofile-conditions flag. MC/DC is a type of
>> test/code coverage and it is p
On 11/04/2023 15:23, Jørgen Kvalsvik wrote:
> On 05/12/2022 10:40, Jørgen Kvalsvik wrote:
>> This patch adds support in gcc+gcov for modified condition/decision
>> coverage (MC/DC) with the -fprofile-conditions flag. MC/DC is a type of
>> test/code coverage and it is p
On 05/12/2022 10:40, Jørgen Kvalsvik wrote:
> This patch adds support in gcc+gcov for modified condition/decision
> coverage (MC/DC) with the -fprofile-conditions flag. MC/DC is a type of
> test/code coverage and it is particularly important in the avation and
> automotive industrie
On 05/12/2022 10:40, Jørgen Kvalsvik wrote:
> This patch adds support in gcc+gcov for modified condition/decision
> coverage (MC/DC) with the -fprofile-conditions flag. MC/DC is a type of
> test/code coverage and it is particularly important in the avation and
> automotive industrie
On 05/12/2022 10:40, Jørgen Kvalsvik wrote:
> This patch adds support in gcc+gcov for modified condition/decision
> coverage (MC/DC) with the -fprofile-conditions flag. MC/DC is a type of
> test/code coverage and it is particularly important in the avation and
> automotive industrie
e test suite contains a lot of small programs functions. Some of these
were designed by hand to test for specific behaviours and graph shapes,
and some are previously-failed test cases in other programs adapted into
the test suite.
Alternative author email: Jørgen Kvalsvik
gcc/Chang
On 02/12/2022 00:05, Martin Liška wrote:
> On 11/11/22 06:21, Jørgen Kvalsvik wrote:
>> From: Jørgen Kvalsvik
>>
>> This patch adds support in gcc+gcov for modified condition/decision
>> coverage (MC/DC) with the -fprofile-conditions flag. MC/DC is a ty
From: Jørgen Kvalsvik
This patch adds support in gcc+gcov for modified condition/decision
coverage (MC/DC) with the -fprofile-conditions flag. MC/DC is a type of
test/code coverage and it is particularly important in the avation and
automotive industries for safety-critical applications. MC/DC
On 02/11/2022 07:16, Jørgen Kvalsvik wrote:
> On 25/10/2022 08:33, Jørgen Kvalsvik wrote:
>> On 12/10/2022 12:16, Jørgen Kvalsvik wrote:
>>> This patch adds support in gcc+gcov for modified condition/decision
>>> coverage (MC/DC) with the -fprofile-conditions flag. MC/DC
On 25/10/2022 08:33, Jørgen Kvalsvik wrote:
> On 12/10/2022 12:16, Jørgen Kvalsvik wrote:
>> This patch adds support in gcc+gcov for modified condition/decision
>> coverage (MC/DC) with the -fprofile-conditions flag. MC/DC is a type of
>> test/code coverage and it is p
On 12/10/2022 12:16, Jørgen Kvalsvik wrote:
> This patch adds support in gcc+gcov for modified condition/decision
> coverage (MC/DC) with the -fprofile-conditions flag. MC/DC is a type of
> test/code coverage and it is particularly important in the avation and
> automotive industrie
On 18/10/2022 02:17, Hans-Peter Nilsson wrote:
> On Wed, 12 Oct 2022, Jørgen Kvalsvik via Gcc-patches wrote:
>> This patch adds support in gcc+gcov for modified condition/decision
>> coverage (MC/DC) with the -fprofile-conditions flag.
>
> I'd love impr
On 13/10/2022 13:39, Richard Biener wrote:
> On Tue, Oct 11, 2022 at 2:43 PM Jørgen Kvalsvik
> wrote:
>>
>> The coverage support will under some conditions decide to split edges to
>> accurately report coverage. By running the test suite with/without this
>> edge s
ite contains a lot of small programs functions. Some of these
were designed by hand to test for specific behaviours and graph shapes,
and some are previously-failed test cases in other programs adapted into
the test suite.
Alternative author email: Jørgen Kvalsvik
gcc/ChangeLog:
* bu
On 11/10/2022 15:55, Michael Matz wrote:
> Hello,
>
> On Tue, 11 Oct 2022, Jørgen Kvalsvik via Gcc-patches wrote:
>
>> The coverage support will under some conditions decide to split edges to
>> accurately report coverage. By running the test suite with/without this
&
Add a test to catch regression in line counts for labels on top of
then/else blocks. Only the 'goto ' should contribute to the line
counter for the label, not the if.
gcc/testsuite/ChangeLog:
* gcc.misc-tests/gcov-4.c:
---
gcc/testsuite/gcc.misc-tests/gcov-4.c | 26
The coverage support will under some conditions decide to split edges to
accurately report coverage. By running the test suite with/without this
edge splitting a small diff shows up, addressed by this patch, which
should catch future regressions.
Removing the edge splitting:
$ diff --git
On 07/10/2022 13:45, Jørgen Kvalsvik wrote:
> On 07/10/2022 08:53, Richard Biener wrote:
>> On Thu, Oct 6, 2022 at 4:28 PM Jørgen Kvalsvik
>> wrote:
>>>
>>> On 06/10/2022 10:12, Richard Biener wrote:
>>>> On Wed, Oct 5, 2022 at 2:49 PM Martin Liška
On 07/10/2022 08:53, Richard Biener wrote:
> On Thu, Oct 6, 2022 at 4:28 PM Jørgen Kvalsvik
> wrote:
>>
>> On 06/10/2022 10:12, Richard Biener wrote:
>>> On Wed, Oct 5, 2022 at 2:49 PM Martin Liška wrote:
>>>>
>>>> On 10/5/22 14:04, Jørgen Kva
On 06/10/2022 10:12, Richard Biener wrote:
> On Wed, Oct 5, 2022 at 2:49 PM Martin Liška wrote:
>>
>> On 10/5/22 14:04, Jørgen Kvalsvik via Gcc-patches wrote:
>>> Edges with locus are candidates for splitting so that the edge with
>>> locus is the only edge
The coverage support will under some conditions decide to split edges to
accurately report coverage. By running the test suite with/without this
edge splitting a small diff shows up, addressed by this patch, which
should catch future regressions.
Removing the edge splitting:
diff --git
Edges with locus are candidates for splitting so that the edge with
locus is the only edge out of a basic block, except when the locuses
match. The test checks the last (non-debug) statement in a basic block,
but this causes an unnecessary split when the edge locus go to a block
which
difference for the condition profiling [1].
I compared the .gcov files for the gcc and g++ testsuites with and
without this patch and found no differences, and bootstrapped on
x86_64-linux.
[1] https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598165.html
Jørgen Kvalsvik (2):
gcov: test switch/break
On 9/8/22 12:30, Jørgen Kvalsvik wrote:
On 02/09/2022 14:22, Richard Biener wrote:
On Fri, Sep 2, 2022 at 11:50 AM Jørgen Kvalsvik wrote:
Hello,
I played some more with odd programs and the effect on control flow
graph construction (as a part of condition coverage support [1]) and
came
Gentle ping. Any idea if the edge split is still useful and/or how to
test for it?
Thanks,
Jørgen
On 08/09/2022 12:30, Jørgen Kvalsvik wrote:
On 02/09/2022 14:22, Richard Biener wrote:
On Fri, Sep 2, 2022 at 11:50 AM Jørgen Kvalsvik wrote:
Hello,
I played some more with odd programs
On 02/09/2022 14:22, Richard Biener wrote:
On Fri, Sep 2, 2022 at 11:50 AM Jørgen Kvalsvik wrote:
Hello,
I played some more with odd programs and the effect on control flow
graph construction (as a part of condition coverage support [1]) and
came across this:
int fn (int a, int b, int c
Hello,
I played some more with odd programs and the effect on control flow
graph construction (as a part of condition coverage support [1]) and
came across this:
int fn (int a, int b, int c) {
int x = 0;
if (a && b) {
if (c) {
goto a_;
} else {
.
(accumulate_line_counts): Similarly for files.
Co-Authored-By: Jørgen Kvalsvik
---
gcc/gcov.cc | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/gcc/gcov.cc b/gcc/gcov.cc
index 27be5ff0911..9cf1071166f 100644
--- a/gcc/gcov.cc
+++ b/gcc/gcov.cc
@@ -2694,6 +2694,13
.
(accumulate_line_counts): Similarly for files.
Co-Authored-By: Jørgen Kvalsvik
---
gcc/gcov.cc | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/gcc/gcov.cc b/gcc/gcov.cc
index 27be5ff0911..9cf1071166f 100644
--- a/gcc/gcov.cc
+++ b/gcc/gcov.cc
@@ -2694,6 +2694,13
On 04/08/2022 09:43, Sebastian Huber wrote:
> On 02/08/2022 09:58, Jørgen Kvalsvik wrote:
>> Based on this established terminology I can think of a few good candidates:
>>
>> condition outcomes covered n/m
>> outcomes covered n/m
>>
>> What do you think?
I have this program:
#include
template
T add (T x, T y) {
if (x > y)
return x + y;
else
return x;
}
template
T sub (T x, T y) {
if (x > y)
return x - y;
else
return x;
}
int main() {
int i1 = 10;
int i2 = 12;
double d1 = 10.0;
1 - 100 of 115 matches
Mail list logo
