[Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96919 Martin Liška changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot gnu.org
[Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96919 Martin Liška changed: What|Removed |Added Target Milestone|12.0|---
[Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96919
Martin Liška changed:
What|Removed |Added
Target Milestone|11.0|12.0
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot
gnu.org
--- Comment #15 from Martin Liška ---
(In reply to Bhavana Kilambi from comment #14)
> Hi Martin,
> This fix is for a customer who was facing this issue. Since I couldn't find
> a trivial fix for it, tried to handle it in a special case.
I see.
Anyway, there's some strangeness about line_info::blocks.
The following patch fixes your test-case but regresses on others:
diff --git a/gcc/gcov.c b/gcc/gcov.c
index 01ca52b215d..29c5e6bdc00 100644
--- a/gcc/gcov.c
+++ b/gcc/gcov.c
@@ -208,7 +208,7 @@ public:
/* Branches from blocks that end on this line. */
vector branches;
- /* blocks which start on this line. Used in all-blocks mode. */
+ /* Blocks which contain this line. */
vector blocks;
unsigned exists : 1;
@@ -1785,6 +1785,7 @@ read_graph_file (void)
else if (fn && tag == GCOV_TAG_ARCS)
{
unsigned src = gcov_read_unsigned ();
+ /* Mark ID of a source block. */
fn->blocks[src].id = src;
unsigned num_dests = GCOV_TAG_ARCS_NUM (length);
block_info *src_blk = >blocks[src];
@@ -1804,6 +1805,8 @@ read_graph_file (void)
arc = XCNEW (arc_info);
arc->dst = >blocks[dest];
+ /* Mark ID of target block, needed for EXIT_BB. */
+ fn->blocks[dest].id = dest;
arc->src = src_blk;
arc->count = 0;
@@ -2639,6 +2642,8 @@ add_line_counts (coverage_info *coverage, function_info
*fn)
line->has_unexecuted_block = 1;
}
line->count += block->count;
+ gcc_assert (!line->has_block (block));
+ line->blocks.push_back (block);
}
else
{
@@ -2659,6 +2664,8 @@ add_line_counts (coverage_info *coverage, function_info
*fn)
line->has_unexecuted_block = 1;
}
line->count += block->count;
+ gcc_assert (!line->has_block (block));
+ line->blocks.push_back (block);
}
}
@@ -2668,8 +2675,6 @@ add_line_counts (coverage_info *coverage, function_info
*fn)
/* Entry or exit block. */;
else if (line != NULL)
{
- line->blocks.push_back (block);
-
if (flag_branches)
{
arc_info *arc;
I'll return to in the next stage1 cycle.
[Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96919 --- Comment #14 from Bhavana Kilambi --- Hi Martin, This fix is for a customer who was facing this issue. Since I couldn't find a trivial fix for it, tried to handle it in a special case.
[Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96919 --- Comment #13 from Martin Liška --- > Hi Martin, My sincere apologies for the delay in replying and also for > uploading a faulty patch. I have attached another patch for this issue. It > is more of a tweak than a straight-forward approach to fixing the issue. > Kindly let me know if this is ok or if any modifications are required. > It has been tested for regressions on trunk and no failures have been found. Hello. I don't like the patch as it's a special case for one particular function. Is the issue really so problematic?
[Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96919 --- Comment #12 from Bhavana Kilambi --- Created attachment 49851 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49851=edit a tweak to fix the issue Hi Martin, My sincere apologies for the delay in replying and also for uploading a faulty patch. I have attached another patch for this issue. It is more of a tweak than a straight-forward approach to fixing the issue. Kindly let me know if this is ok or if any modifications are required. It has been tested for regressions on trunk and no failures have been found. Thanks
[Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96919 --- Comment #11 from Martin Liška --- (In reply to Bhavana Kilambi from comment #10) > Created attachment 49664 [details] > Removes the push_back() statement The suggested patch breaks most of the tests: $ make check -k RUNTESTFLAGS="gcov.exp" ... grep '^FAIL' ./gcc/testsuite/gcc/gcc.log ; grep '^FAIL' ./gcc/testsuite/g++/g++.log ; grep '^FAIL' gcc/testsuite/gfortran/gfortran.log FAIL: gcc.misc-tests/gcov-1.c line 14: is 22:should be 11 FAIL: gcc.misc-tests/gcov-1.c gcov: 1 failures in line counts, 0 in branch percentages, 0 in return percentages, 0 in intermediate format FAIL: gcc.misc-tests/gcov-10.c line 10: is 27:should be 11 FAIL: gcc.misc-tests/gcov-10.c gcov: 1 failures in line counts, 0 in branch percentages, 0 in return percentages, 0 in intermediate format FAIL: gcc.misc-tests/gcov-10b.c line 10: is 37:should be 11 FAIL: gcc.misc-tests/gcov-10b.c gcov: 1 failures in line counts, 0 in branch percentages, 0 in return percentages, 0 in intermediate format FAIL: gcc.misc-tests/gcov-11.c line 11: is 40:should be 10 FAIL: gcc.misc-tests/gcov-11.c line 18: is 32:should be 11 FAIL: gcc.misc-tests/gcov-11.c gcov: 2 failures in line counts, 0 in branch percentages, 0 in return percentages, 0 in intermediate format FAIL: gcc.misc-tests/gcov-12.c line 9: is 2:should be 1 FAIL: gcc.misc-tests/gcov-12.c gcov: 1 failures in line counts, 0 in branch percentages, 0 in return percentages, 0 in intermediate format FAIL: gcc.misc-tests/gcov-13.c line 3: is 2:should be 1 FAIL: gcc.misc-tests/gcov-13.c gcov: 1 failures in line counts, 0 in branch percentages, 0 in return percentages, 0 in intermediate format FAIL: gcc.misc-tests/gcov-15.c line 19: is 2:should be 1 FAIL: gcc.misc-tests/gcov-15.c gcov: 1 failures in line counts, 0 in branch percentages, 0 in return percentages, 0 in intermediate format FAIL: gcc.misc-tests/gcov-18.c line 22: is 3:should be 2 ...
[Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96919 --- Comment #10 from Bhavana Kilambi --- Created attachment 49664 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49664=edit Removes the push_back() statement
[Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96919 --- Comment #9 from Bhavana Kilambi --- Hi, The problem seems to be with the code in add_line_counts() function in gcov.c. Specifically with this statement - line->blocks.push_back (block); This line is present inside the line!= NULL condition while in gcc7 it is within the flag_all_blocks condition. Since all the lines in the function satisfy the condition of line != NULL, this push_back() function gets executed almost everytime. Also, looking at the way the tool is built, initially the relevant data structures would have already been created and in place in the process_file() and other functions while the generate_results() function (which in turn calls add_line_counts() function) is supposed to technically only read/traverse the appropriate data structures and update the coverage information. After removing the above line, the coverage for the testcase in this bug is 100% as required with the -a and -m flags. Also, tested the testcase mentioned in bug #79891. It also shows the expected coverage output. I have attached the patch in this bug. Output after the patch for the testcase specified in this bug : gcov main.cpp -a File 'hello.h' Lines executed:0.00% of 2 Creating 'hello.h.gcov' File 'main.cpp' Lines executed:100.00% of 4 Creating 'main.cpp.gcov' Lines executed:66.67% of 6
[Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96919
Bhavana Kilambi changed:
What|Removed |Added
CC||bhavana.kilambi@blackfigtec
||h.com
--- Comment #8 from Bhavana Kilambi
---
This issue is reproducible in the trunk GCC version as well.
Reverting the commit 6e49961ce47b8c554ff6081ef95a68a0616f0a93 helps in
mitigating the issue. Specifically, the problem seems to lie in the
add_line_counts() code changes in the gcov.c file as shown below :
GCC8.2 gcc/gcov.c:
...
...
2540 has_any_line = true;
2541
2542 if (!ix || ix + 1 == fn->blocks.size ())
2543 /* Entry or exit block. */;
2544 else if (line != NULL)
2545 {
2546 line->blocks.push_back (block);
2547
2548 if (flag_branches)
2549 {
2550 arc_info *arc;
2551
2552 for (arc = block->succ; arc; arc = arc->succ_next)
2553 line->branches.push_back (arc);
...
...
Changing this part of the code to the one in the GCC7.5 version like this -
GCC8.2 gcc/gcov.c modified :
...
...
2541 if (!ix || ix + 1 == fn->blocks.size ())
2542 /* Entry or exit block. */;
2543 else if (flag_branches)
2544 {
2545 arc_info *arc;
2546
2547 for (arc = block->succ; arc; arc = arc->succ_next)
2548 {
2549 line->branches.push_back (arc);
2550 if (coverage && !arc->is_unconditional)
2551 add_branch_counts (coverage, arc);
...
...
Helped in getting a full 100% coverage in GCC8.2.
The executed line counts are being correctly updated for the source files until
line 2544 (in the original gcov.c version) after which the condition else if
(line != NULL) and the pushback of the block onto the line seems to be changing
the executed line counts. The modified version above (in accordance with the
code in gcc7.5) is able to get the desired coverage of 100% for the testcase
mentioned in this issue.
[Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96919
--- Comment #7 from Martin Liška ---
(In reply to Libin Dang from comment #6)
> (In reply to Martin Liška from comment #2)
> > Using latest GCC release you can see what happens:
> >
> > $ g++ pr96919.cc --coverage && ./a.out && gcov a-pr96919.cc -t
> > hello
> > libgcov profiling
> > error:/home/marxin/Programming/testcases/a-pr96919.gcda:overwriting an
> > existing profile data with a different timestamp
> > -:0:Source:pr96919.cc
> > -:0:Graph:a-pr96919.gcno
> > -:0:Data:a-pr96919.gcda
> > -:0:Runs:1
> > -:1:class Base {
> > -:2:public:
> > -:3: Base() = default;
> >1*:4: virtual ~Base() = default;
> > --
> > _ZN4BaseD0Ev:
> > #:4: virtual ~Base() = default;
> > --
> > _ZN4BaseD2Ev:
> > 1:4: virtual ~Base() = default;
> > --
> > -:5: virtual void foo() = 0;
> > -:6:};
> > -:7:class Hello : public Base {
> > -:8:public:
> > -:9: Hello() = default;
> >1*: 10: ~Hello() = default;
> > --
> > _ZN5HelloD0Ev:
> > #: 10: ~Hello() = default;
> > --
> > _ZN5HelloD2Ev:
> > 1: 10: ~Hello() = default;
> > --
> > -: 11: void foo() override;
> > -: 12:};
> > -: 13:
> > -: 14:#include
> > -: 15:
> > -: 16:using namespace std;
> > -: 17:
> > 1: 18:void Hello::foo() {
> > 1: 19: cout << "hello" << endl;
> > 1: 20:}
> > -: 21:
> > 1: 22:int main(int argc, char* argv[]) {
> > #: 23: Hello hello;
> > 1: 24: hello.foo();
> > 1: 25: return 0;
> > -: 26:}
> >
> > So yes, it's a virtual destructor _ZN4BaseD0Ev that is not called.
> > And the not executed line:
> > #:4: Hello hello;
> >
> > corresponds to a basic block
> >
> >:
> > :
> > Hello::~Hello ();
> > resx 2
> >
> > which would be executed when the Hellow constructor fails.
>
> A strange thing about this test case:
>
> If I removed 'return 0;' at line 25, gcov will mark line 23 as executed.
>
>
> Tested with both gcov 8.3 and 10.2.
I can confirm that.
[Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96919
--- Comment #6 from Libin Dang ---
(In reply to Martin Liška from comment #2)
> Using latest GCC release you can see what happens:
>
> $ g++ pr96919.cc --coverage && ./a.out && gcov a-pr96919.cc -t
> hello
> libgcov profiling
> error:/home/marxin/Programming/testcases/a-pr96919.gcda:overwriting an
> existing profile data with a different timestamp
> -:0:Source:pr96919.cc
> -:0:Graph:a-pr96919.gcno
> -:0:Data:a-pr96919.gcda
> -:0:Runs:1
> -:1:class Base {
> -:2:public:
> -:3: Base() = default;
>1*:4: virtual ~Base() = default;
> --
> _ZN4BaseD0Ev:
> #:4: virtual ~Base() = default;
> --
> _ZN4BaseD2Ev:
> 1:4: virtual ~Base() = default;
> --
> -:5: virtual void foo() = 0;
> -:6:};
> -:7:class Hello : public Base {
> -:8:public:
> -:9: Hello() = default;
>1*: 10: ~Hello() = default;
> --
> _ZN5HelloD0Ev:
> #: 10: ~Hello() = default;
> --
> _ZN5HelloD2Ev:
> 1: 10: ~Hello() = default;
> --
> -: 11: void foo() override;
> -: 12:};
> -: 13:
> -: 14:#include
> -: 15:
> -: 16:using namespace std;
> -: 17:
> 1: 18:void Hello::foo() {
> 1: 19: cout << "hello" << endl;
> 1: 20:}
> -: 21:
> 1: 22:int main(int argc, char* argv[]) {
> #: 23: Hello hello;
> 1: 24: hello.foo();
> 1: 25: return 0;
> -: 26:}
>
> So yes, it's a virtual destructor _ZN4BaseD0Ev that is not called.
> And the not executed line:
> #:4: Hello hello;
>
> corresponds to a basic block
>
>:
> :
> Hello::~Hello ();
> resx 2
>
> which would be executed when the Hellow constructor fails.
A strange thing about this test case:
If I removed 'return 0;' at line 25, gcov will mark line 23 as executed.
Tested with both gcov 8.3 and 10.2.
[Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96919 Martin Liška changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #5 from Martin Liška --- I confirm it's a minor issue, but I don't see a trivial fix for it.
[Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96919 Martin Liška changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Target Milestone|--- |11.0 Status|NEW |ASSIGNED --- Comment #4 from Martin Liška --- > > So according to your analysis would you classify this issue as a bug? Or is > it an NBC change that was introduced? Hard to say as C++ language introduces quite some boilerplate code that is not explicitly written by a code author. We identify these blocks in JSON format as exceptional, let me try to ignore these when outputting '#'. > > /Filip
[Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96919
Filip Puđak changed:
What|Removed |Added
CC||filip.pudak at gmail dot com
--- Comment #3 from Filip Puđak ---
(In reply to Martin Liška from comment #2)
> Using latest GCC release you can see what happens:
>
> $ g++ pr96919.cc --coverage && ./a.out && gcov a-pr96919.cc -t
> hello
> libgcov profiling
> error:/home/marxin/Programming/testcases/a-pr96919.gcda:overwriting an
> existing profile data with a different timestamp
> -:0:Source:pr96919.cc
> -:0:Graph:a-pr96919.gcno
> -:0:Data:a-pr96919.gcda
> -:0:Runs:1
> -:1:class Base {
> -:2:public:
> -:3: Base() = default;
>1*:4: virtual ~Base() = default;
> --
> _ZN4BaseD0Ev:
> #:4: virtual ~Base() = default;
> --
> _ZN4BaseD2Ev:
> 1:4: virtual ~Base() = default;
> --
> -:5: virtual void foo() = 0;
> -:6:};
> -:7:class Hello : public Base {
> -:8:public:
> -:9: Hello() = default;
>1*: 10: ~Hello() = default;
> --
> _ZN5HelloD0Ev:
> #: 10: ~Hello() = default;
> --
> _ZN5HelloD2Ev:
> 1: 10: ~Hello() = default;
> --
> -: 11: void foo() override;
> -: 12:};
> -: 13:
> -: 14:#include
> -: 15:
> -: 16:using namespace std;
> -: 17:
> 1: 18:void Hello::foo() {
> 1: 19: cout << "hello" << endl;
> 1: 20:}
> -: 21:
> 1: 22:int main(int argc, char* argv[]) {
> #: 23: Hello hello;
> 1: 24: hello.foo();
> 1: 25: return 0;
> -: 26:}
>
> So yes, it's a virtual destructor _ZN4BaseD0Ev that is not called.
> And the not executed line:
> #:4: Hello hello;
>
> corresponds to a basic block
>
>:
> :
> Hello::~Hello ();
> resx 2
>
> which would be executed when the Hellow constructor fails.
Hi Martin,
So according to your analysis would you classify this issue as a bug? Or is it
an NBC change that was introduced?
/Filip
[Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96919
--- Comment #2 from Martin Liška ---
Using latest GCC release you can see what happens:
$ g++ pr96919.cc --coverage && ./a.out && gcov a-pr96919.cc -t
hello
libgcov profiling
error:/home/marxin/Programming/testcases/a-pr96919.gcda:overwriting an existing
profile data with a different timestamp
-:0:Source:pr96919.cc
-:0:Graph:a-pr96919.gcno
-:0:Data:a-pr96919.gcda
-:0:Runs:1
-:1:class Base {
-:2:public:
-:3: Base() = default;
1*:4: virtual ~Base() = default;
--
_ZN4BaseD0Ev:
#:4: virtual ~Base() = default;
--
_ZN4BaseD2Ev:
1:4: virtual ~Base() = default;
--
-:5: virtual void foo() = 0;
-:6:};
-:7:class Hello : public Base {
-:8:public:
-:9: Hello() = default;
1*: 10: ~Hello() = default;
--
_ZN5HelloD0Ev:
#: 10: ~Hello() = default;
--
_ZN5HelloD2Ev:
1: 10: ~Hello() = default;
--
-: 11: void foo() override;
-: 12:};
-: 13:
-: 14:#include
-: 15:
-: 16:using namespace std;
-: 17:
1: 18:void Hello::foo() {
1: 19: cout << "hello" << endl;
1: 20:}
-: 21:
1: 22:int main(int argc, char* argv[]) {
#: 23: Hello hello;
1: 24: hello.foo();
1: 25: return 0;
-: 26:}
So yes, it's a virtual destructor _ZN4BaseD0Ev that is not called.
And the not executed line:
#:4: Hello hello;
corresponds to a basic block
:
:
Hello::~Hello ();
resx 2
which would be executed when the Hellow constructor fails.
[Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96919 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-09-21 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Started with 6e49961ce47b8c554ff6081ef95a68a0616f0a93 where I made more precise mapping to lines.
