On 1/5/25 20:53, Jørgen Kvalsvik wrote:
On 1/5/25 20:25, Jan Hubicka wrote:
ALGORITHM
Since the numbers of paths grows so fast, we need a good
algorithm. The naive approach of generating all paths and discarding
redundancies (see reference_prime_paths in the diff) simply doesn't
complet
On 1/5/25 20:25, Jan Hubicka wrote:
ALGORITHM
Since the numbers of paths grows so fast, we need a good
algorithm. The naive approach of generating all paths and discarding
redundancies (see reference_prime_paths in the diff) simply doesn't
complete for even pretty simple functions with a few ten
On 1/5/25 18:23, Jan Hubicka wrote:
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, calls, and
condition coverage.
$ gcc --coverage -fpath-coverage hello.c -o
Ping.
On 12/2/24 11:49, Jørgen Kvalsvik wrote:
Ping.
On 11/21/24 20:14, Jørgen Kvalsvik wrote:
Ping.
On 11/12/24 09:56, Jørgen Kvalsvik wrote:
Ping.
On 10/30/24 13:55, Jørgen Kvalsvik wrote:
Ping.
On 10/21/24 15:21, Jørgen Kvalsvik wrote:
Ping.
On 10/10/24 10:08, Jørgen Kvalsvik wrote
Ping.
On 11/21/24 20:14, Jørgen Kvalsvik wrote:
Ping.
On 11/12/24 09:56, Jørgen Kvalsvik wrote:
Ping.
On 10/30/24 13:55, Jørgen Kvalsvik wrote:
Ping.
On 10/21/24 15:21, Jørgen Kvalsvik wrote:
Ping.
On 10/10/24 10:08, Jørgen Kvalsvik wrote:
Ping.
On 10/3/24 12:46, Jørgen Kvalsvik wrote
Ping.
On 11/12/24 09:56, Jørgen Kvalsvik wrote:
Ping.
On 10/30/24 13:55, Jørgen Kvalsvik wrote:
Ping.
On 10/21/24 15:21, Jørgen Kvalsvik wrote:
Ping.
On 10/10/24 10:08, Jørgen Kvalsvik wrote:
Ping.
On 10/3/24 12:46, Jørgen Kvalsvik wrote:
This is both a ping and a minor update. A few of
Ping.
On 10/30/24 13:55, Jørgen Kvalsvik wrote:
Ping.
On 10/21/24 15:21, Jørgen Kvalsvik wrote:
Ping.
On 10/10/24 10:08, Jørgen Kvalsvik wrote:
Ping.
On 10/3/24 12:46, Jørgen Kvalsvik wrote:
This is both a ping and a minor update. A few of the patches from the
previous set have been
Ping.
On 10/21/24 15:21, Jørgen Kvalsvik wrote:
Ping.
On 10/10/24 10:08, Jørgen Kvalsvik wrote:
Ping.
On 10/3/24 12:46, Jørgen Kvalsvik wrote:
This is both a ping and a minor update. A few of the patches from the
previous set have been merged, but the big feature still needs review.
Since
Ping.
On 10/10/24 10:08, Jørgen Kvalsvik wrote:
Ping.
On 10/3/24 12:46, Jørgen Kvalsvik wrote:
This is both a ping and a minor update. A few of the patches from the
previous set have been merged, but the big feature still needs review.
Since then it has been quiet, but there are two notable
Ping.
On 10/3/24 12:46, Jørgen Kvalsvik wrote:
This is both a ping and a minor update. A few of the patches from the
previous set have been merged, but the big feature still needs review.
Since then it has been quiet, but there are two notable changes:
1. The --prime-paths-{lines,source
objects.
Jørgen Kvalsvik (2):
gcov: branch, conds, calls in function summaries
Add prime path coverage to gcc/gcov
gcc/Makefile.in|6 +-
gcc/builtins.cc|2 +-
gcc/collect2.cc|5 +-
gcc/common.opt
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, calls, and
condition coverage.
$ gcc --coverage -fpath-coverage hello.c -o hello
$ ./hello
Before:
$ gcov -
On 8/23/24 09:41, Jan Hubicka wrote:
Since this is a pure compile test it makes sense to inform dejagnu of
it.
gcc/testsuite/ChangeLog:
* gcc.misc-tests/gcov-23.c: Use dg-compile, not gcc -c
OK,
Honza
Thanks,
Pushed.
---
gcc/testsuite/gcc.misc-tests/gcov-23.c | 3 ++-
1 file ch
On 8/23/24 09:39, Jan Hubicka wrote:
Hi,
1:4:int notmain(const char *entity)
-: == inlined from hello.h ==
1:6: if (s)
branch 0 taken 0 (fallthrough)
branch 1 taken 1
#:7:printf ("hello, %s!\n", s);
%:7-block 3
call0 never e
On 8/23/24 09:39, Jan Hubicka wrote:
Hi,
1:4:int notmain(const char *entity)
-: == inlined from hello.h ==
1:6: if (s)
branch 0 taken 0 (fallthrough)
branch 1 taken 1
#:7:printf ("hello, %s!\n", s);
%:7-block 3
call0 never e
Ping.
On 8/15/24 10:15, Jørgen Kvalsvik wrote:
Ping. Since the last patch I have fixed a few bugs in the path count
limit aborting, and a few minor rephrases in docs.
Jørgen Kvalsvik (4):
testsuite: Use dg-compile, not gcc -c
gcov: Cache source files
gcov: branch, conds, calls in
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, calls, and
condition coverage.
$ gcc --coverage -fpath-coverage hello.c -o hello
$ ./hello
Before:
$ gcov -
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 interact
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 interact
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, calls, and
condition coverage.
$ gcc --coverage -fpath-coverage hello.c -o hello
$ ./hello
Before:
$ gcov -
Since this is a pure compile test it makes sense to inform dejagnu of
it.
gcc/testsuite/ChangeLog:
* gcc.misc-tests/gcov-23.c: Use dg-compile, not gcc -c
---
gcc/testsuite/gcc.misc-tests/gcov-23.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.mis
Ping. Since the last patch I have fixed a few bugs in the path count
limit aborting, and a few minor rephrases in docs.
Jørgen Kvalsvik (4):
testsuite: Use dg-compile, not gcc -c
gcov: Cache source files
gcov: branch, conds, calls in function summaries
Add prime path coverage to gcc/gcov
y get stuck between checks.
3. Fixed some ICEs, mostly around setjmp.
4. Refactoring, comments.
5. Manual entries, --help.
Jørgen Kvalsvik (3):
gcov: Cache source files
gcov: Add branch, conds, calls in function summary
Add prime path coverage to gcc/gcov
gcc/Makefi
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 interact
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, calls, and
condition coverage.
$ gcc --coverage -fpath-coverage hello.c -o hello
$ ./hello
Before:
$ gcov -
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, calls, and
condition coverage.
$ gcc --coverage -fpath-coverage hello.c -o hello
$ ./hello
Before:
$ gcov -
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 interact
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, calls, and
condition coverage.
$ gcc --coverage -fpath-coverage hello.c -o hello
$ ./hello
Before:
$ gcov -
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 -t
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 sources.line
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 interact
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 to
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 interact
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
is
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
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655
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.
gc
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 b/gcc/do
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
hash_m
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.
gc
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
hash_m
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 (print_
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
+++ b/gcc/doc/g
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 b/
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 -t
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 a/gcc/d
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 -t
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 wh
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 the
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 is
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 don
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: A
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: A
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 perspective of
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.
P
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 the
(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 i
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 te
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 with
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&#
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 reasonabl
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 c
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
2 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 r
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 r
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: A
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
-Wco
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 be
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 hello
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 i
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 aviat
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 i
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 -fcondition-cove
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
-Wco
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 i
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
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:
* builti
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 (whi
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
ng 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
g
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 (whi
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 in
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 e
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 cand
---
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 th
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| == 2
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 no
1 - 100 of 162 matches
Mail list logo
