Pushed.
Thanks,
Jørgen
On 7/16/24 09:49, Roger Sayle wrote:
Hi Jørgen,
Awesome. Very many thanks for the speedy fix.
Roger
--
-Original Message-
From: Jørgen Kvalsvik
Sent: 14 July 2024 20:46
To: gcc-patches@gcc.gnu.org
Cc: jeffreya...@gmail.com; ro...@nextmovesoftware.com; Jørgen
lmap was introduced in tcl 8.6, and while it was released in 2012, lmap
does not really make too much of a difference to warrant the friction on
consverative (and relevant) systems.
gcc/testsuite/ChangeLog:
* lib/gcov.exp: Use foreach for tcl <= 8.5.
---
gcc/testsuite/lib/gcov.exp | 28
Certainly, I can rewrite from lmap. I'll send a patch shortly.
On 7/14/24 16:27, Roger Sayle wrote:
I’m seeing (dejagnu) testsuite problems from this (recent) patch.
Running /home/roger/GCC/patchem/gcc/testsuite/gcc.misc-tests/gcov.exp ...
ERROR: (DejaGnu) proc "lmap key { snd } {
if
Add the --include and --exclude flags to gcov to control what functions
to report on. This is meant to make gcov more practical as an when
writing test suites or performing other coverage experiments, which
tends to focus on a few functions at the time. This really shines in
combination with the
Ensure that the function.end_line in the lines vector for the source
file, even if it is not explicitly touched by a basic block. This
ensures consistency with what you would expect. For example, this file
has sources[sum.cc].lines.size () == 23 and main.end_line == 2 without
adjusting
Cache the source files as they are read, rather than discarding them at
the end of output_lines (), and move the reading of the source file to
the new function slurp.
This patch does not really change anything other than moving the file
reading out of output_file, but set gcov up for more
On 7/10/24 23:59, Jeff Law wrote:
On 7/10/24 3:18 PM, Jørgen Kvalsvik wrote:
On 7/10/24 21:54, Jeff Law wrote:
On 7/10/24 1:30 PM, Jørgen Kvalsvik wrote:
Thanks you -- before I move forward, I would like some feedback on
adding this diff to the patch:
diff --git a/gcc/gcov.cc b/gcc
On 7/10/24 21:54, Jeff Law wrote:
On 7/10/24 1:30 PM, Jørgen Kvalsvik wrote:
Thanks you -- before I move forward, I would like some feedback on
adding this diff to the patch:
diff --git a/gcc/gcov.cc b/gcc/gcov.cc
index 9cdef19c461..055fa7e78ba 100644
--- a/gcc/gcov.cc
+++ b/gcc
On 7/10/24 01:50, Jeff Law wrote:
On 6/25/24 1:56 AM, Jørgen Kvalsvik wrote:
Add the --include and --exclude flags to gcov to control what functions
to report on. This is meant to make gcov more practical as an when
writing test suites or performing other coverage experiments, which
tends
Cache the source files as they are read, rather than discarding them at
the end of output_lines (), and move the reading of the source file to
the new function slurp.
This patch does not really change anything other than moving the file
reading out of output_file, but set gcov up for more
On 6/28/24 13:55, Richard Biener wrote:
On Fri, Jun 28, 2024 at 8:43 AM Jørgen Kvalsvik wrote:
Using auto_vec rather than vec for means the vectors are release
automatically upon return, to stop the leak. The problem seems is that
auto_vec is not really move-aware, only the specialization
Using auto_vec rather than vec for means the vectors are release
automatically upon return, to stop the leak. The problem seems is that
auto_vec is not really move-aware, only the specialization
is.
This is actually Jan's original suggestion
I think we need to revert this.
I got this email from linaro/gcc-regressions:
[Linaro-TCWG-CI] gcc-15-1649-g19f630e6ae8d: FAIL: 2 regressions on aarch64
regressions.sum:
=== gcc tests ===
Running gcc:gcc.misc-tests/gcov.exp ...
FAIL: gcc.misc-tests/gcov-23.c (internal compiler
On 6/25/24 12:25, Jan Hubicka wrote:
Without key terms like "masking" and "MC/DC" it is not at all obvious
what --conditions actually reports on, and there is no easy path for the
user to figure out. By at least including the two key terms MC/DC and
masking users have something to search for.
On 6/25/24 12:23, Jan Hubicka wrote:
gcc/ChangeLog:
* doc/gcov.texi: Add MC/DC section.
OK,
thanks!
Pushed.
Thanks,
Jørgen
Honza
---
gcc/doc/gcov.texi | 72 +++
1 file changed, 72 insertions(+)
diff --git a/gcc/doc/gcov.texi
On 6/25/24 12:23, Jan Hubicka wrote:
The value vec objects are destroyed on exit, but release still needs to
be called explicitly.
gcc/ChangeLog:
* tree-profile.cc (find_conditions): Release vectors before
return.
I wonder if you turn
hash_map, vec> exprs;
to
On 6/25/24 23:37, Jeff Law wrote:
On 6/25/24 2:04 AM, Jørgen Kvalsvik wrote:
Make gcov aware which edges are the true/false to more accurately
reconstruct the CFG. There are plenty of bits left in arc_info and it
opens up for richer reporting.
gcc/ChangeLog:
* gcov-io.h (GCOV_ARC_TRUE
On 6/25/24 12:25, Jan Hubicka wrote:
Without key terms like "masking" and "MC/DC" it is not at all obvious
what --conditions actually reports on, and there is no easy path for the
user to figure out. By at least including the two key terms MC/DC and
masking users have something to search for.
On 6/25/24 12:23, Jan Hubicka wrote:
The value vec objects are destroyed on exit, but release still needs to
be called explicitly.
gcc/ChangeLog:
* tree-profile.cc (find_conditions): Release vectors before
return.
I wonder if you turn
hash_map, vec> exprs;
to
These are the main highlights since v1:
1. The instrumentation phase has been reworked and tries to eliminate
redundant instructions. This has a massive impact on performance,
taking the compile time of tree.c from 13m30s-14m to ~2m30s on my
machine, and the resulting tree.o from ~50M to
Make gcov aware which edges are the true/false to more accurately
reconstruct the CFG. There are plenty of bits left in arc_info and it
opens up for richer reporting.
gcc/ChangeLog:
* gcov-io.h (GCOV_ARC_TRUE): New.
(GCOV_ARC_FALSE): New.
* gcov.cc (struct arc_info): Add
Without key terms like "masking" and "MC/DC" it is not at all obvious
what --conditions actually reports on, and there is no easy path for the
user to figure out. By at least including the two key terms MC/DC and
masking users have something to search for.
gcc/ChangeLog:
* gcov.cc
gcc/ChangeLog:
* doc/gcov.texi: Add MC/DC section.
---
gcc/doc/gcov.texi | 72 +++
1 file changed, 72 insertions(+)
diff --git a/gcc/doc/gcov.texi b/gcc/doc/gcov.texi
index dc79bccb8cf..a9221738cce 100644
--- a/gcc/doc/gcov.texi
+++
The value vec objects are destroyed on exit, but release still needs to
be called explicitly.
gcc/ChangeLog:
* tree-profile.cc (find_conditions): Release vectors before
return.
---
gcc/tree-profile.cc | 3 +++
1 file changed, 3 insertions(+)
diff --git a/gcc/tree-profile.cc
Add the --include and --exclude flags to gcov to control what functions
to report on. This is meant to make gcov more practical as an when
writing test suites or performing other coverage experiments, which
tends to focus on a few functions at the time. This really shines in
combination with the
Add a section with some examples on the --include and --exclude flags in
the gcov tutorial.
gcc/ChangeLog:
* doc/gcov.texi: Add tutorial on function filtering.
---
gcc/doc/gcov.texi | 86 +++
1 file changed, 86 insertions(+)
diff --git
Add the --include and --exclude flags to gcov to control what functions
to report on. This is meant to make gcov more practical as an when
writing test suites or performing other coverage experiments, which
tends to focus on a few functions at the time. This really shines in
combination with the
This patch adds prime path coverage to gcc/gcov. It is a bit rough in a few
places, but I think all the main components are there and ready for some
feedback while I keep working on the details. First a quick introduction to
path coverage, before I explain a bit on the pieces of the patch and on
Make gcov aware which edges are the true/false to more accurately
reconstruct the CFG. There are plenty of bits left in arc_info and it
opens up for richer reporting.
gcc/ChangeLog:
* gcov-io.h (GCOV_ARC_TRUE): New.
(GCOV_ARC_FALSE): New.
* gcov.cc (struct arc_info): Add
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
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
1 - 100 of 134 matches
Mail list logo
