* [Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor
2020-09-03 13:18 [Bug gcov-profile/96919] New: [GCOV] uncovered line of stack allocation while using virutal destructor youngseok.roh.de at gmail dot com
@ 2020-09-21 11:00 ` marxin at gcc dot gnu.org
2020-09-21 11:05 ` marxin at gcc dot gnu.org
` (15 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: marxin at gcc dot gnu.org @ 2020-09-21 11:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96919
Martin Liška <marxin at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2020-09-21
Ever confirmed|0 |1
--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
Started with 6e49961ce47b8c554ff6081ef95a68a0616f0a93 where I made more precise
mapping to lines.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor
2020-09-03 13:18 [Bug gcov-profile/96919] New: [GCOV] uncovered line of stack allocation while using virutal destructor youngseok.roh.de at gmail dot com
2020-09-21 11:00 ` [Bug gcov-profile/96919] " marxin at gcc dot gnu.org
@ 2020-09-21 11:05 ` marxin at gcc dot gnu.org
2020-09-28 13:19 ` filip.pudak at gmail dot com
` (14 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: marxin at gcc dot gnu.org @ 2020-09-21 11:05 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96919
--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
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 <iostream>
-: 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
<bb 5> :
<L3>:
Hello::~Hello (&hello);
resx 2
which would be executed when the Hellow constructor fails.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor
2020-09-03 13:18 [Bug gcov-profile/96919] New: [GCOV] uncovered line of stack allocation while using virutal destructor youngseok.roh.de at gmail dot com
2020-09-21 11:00 ` [Bug gcov-profile/96919] " marxin at gcc dot gnu.org
2020-09-21 11:05 ` marxin at gcc dot gnu.org
@ 2020-09-28 13:19 ` filip.pudak at gmail dot com
2020-09-29 7:48 ` marxin at gcc dot gnu.org
` (13 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: filip.pudak at gmail dot com @ 2020-09-28 13:19 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96919
Filip Puđak <filip.pudak at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |filip.pudak at gmail dot com
--- Comment #3 from Filip Puđak <filip.pudak at gmail dot com> ---
(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 <iostream>
> -: 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
>
> <bb 5> :
> <L3>:
> Hello::~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
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor
2020-09-03 13:18 [Bug gcov-profile/96919] New: [GCOV] uncovered line of stack allocation while using virutal destructor youngseok.roh.de at gmail dot com
` (2 preceding siblings ...)
2020-09-28 13:19 ` filip.pudak at gmail dot com
@ 2020-09-29 7:48 ` marxin at gcc dot gnu.org
2020-10-02 11:29 ` marxin at gcc dot gnu.org
` (12 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: marxin at gcc dot gnu.org @ 2020-09-29 7:48 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96919
Martin Liška <marxin at gcc dot gnu.org> 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 <marxin at gcc dot gnu.org> ---
>
> 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor
2020-09-03 13:18 [Bug gcov-profile/96919] New: [GCOV] uncovered line of stack allocation while using virutal destructor youngseok.roh.de at gmail dot com
` (3 preceding siblings ...)
2020-09-29 7:48 ` marxin at gcc dot gnu.org
@ 2020-10-02 11:29 ` marxin at gcc dot gnu.org
2020-10-26 7:13 ` libin.dang at gmail dot com
` (11 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: marxin at gcc dot gnu.org @ 2020-10-02 11:29 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96919
Martin Liška <marxin at gcc dot gnu.org> 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 <marxin at gcc dot gnu.org> ---
I confirm it's a minor issue, but I don't see a trivial fix for it.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor
2020-09-03 13:18 [Bug gcov-profile/96919] New: [GCOV] uncovered line of stack allocation while using virutal destructor youngseok.roh.de at gmail dot com
` (4 preceding siblings ...)
2020-10-02 11:29 ` marxin at gcc dot gnu.org
@ 2020-10-26 7:13 ` libin.dang at gmail dot com
2020-10-26 14:55 ` marxin at gcc dot gnu.org
` (10 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: libin.dang at gmail dot com @ 2020-10-26 7:13 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96919
--- Comment #6 from Libin Dang <libin.dang at gmail dot com> ---
(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 <iostream>
> -: 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
>
> <bb 5> :
> <L3>:
> Hello::~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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor
2020-09-03 13:18 [Bug gcov-profile/96919] New: [GCOV] uncovered line of stack allocation while using virutal destructor youngseok.roh.de at gmail dot com
` (5 preceding siblings ...)
2020-10-26 7:13 ` libin.dang at gmail dot com
@ 2020-10-26 14:55 ` marxin at gcc dot gnu.org
2020-11-17 15:06 ` bhavana.kilambi at blackfigtech dot com
` (9 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: marxin at gcc dot gnu.org @ 2020-10-26 14:55 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96919
--- Comment #7 from Martin Liška <marxin at gcc dot gnu.org> ---
(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 <iostream>
> > -: 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
> >
> > <bb 5> :
> > <L3>:
> > Hello::~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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor
2020-09-03 13:18 [Bug gcov-profile/96919] New: [GCOV] uncovered line of stack allocation while using virutal destructor youngseok.roh.de at gmail dot com
` (6 preceding siblings ...)
2020-10-26 14:55 ` marxin at gcc dot gnu.org
@ 2020-11-17 15:06 ` bhavana.kilambi at blackfigtech dot com
2020-12-02 17:08 ` bhavana.kilambi at blackfigtech dot com
` (8 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: bhavana.kilambi at blackfigtech dot com @ 2020-11-17 15:06 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96919
Bhavana Kilambi <bhavana.kilambi at blackfigtech dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bhavana.kilambi@blackfigtec
| |h.com
--- Comment #8 from Bhavana Kilambi <bhavana.kilambi at blackfigtech dot com> ---
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor
2020-09-03 13:18 [Bug gcov-profile/96919] New: [GCOV] uncovered line of stack allocation while using virutal destructor youngseok.roh.de at gmail dot com
` (7 preceding siblings ...)
2020-11-17 15:06 ` bhavana.kilambi at blackfigtech dot com
@ 2020-12-02 17:08 ` bhavana.kilambi at blackfigtech dot com
2020-12-02 17:10 ` bhavana.kilambi at blackfigtech dot com
` (7 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: bhavana.kilambi at blackfigtech dot com @ 2020-12-02 17:08 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96919
--- Comment #9 from Bhavana Kilambi <bhavana.kilambi at blackfigtech dot com> ---
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor
2020-09-03 13:18 [Bug gcov-profile/96919] New: [GCOV] uncovered line of stack allocation while using virutal destructor youngseok.roh.de at gmail dot com
` (8 preceding siblings ...)
2020-12-02 17:08 ` bhavana.kilambi at blackfigtech dot com
@ 2020-12-02 17:10 ` bhavana.kilambi at blackfigtech dot com
2020-12-03 10:01 ` marxin at gcc dot gnu.org
` (6 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: bhavana.kilambi at blackfigtech dot com @ 2020-12-02 17:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96919
--- Comment #10 from Bhavana Kilambi <bhavana.kilambi at blackfigtech dot com> ---
Created attachment 49664
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49664&action=edit
Removes the push_back() statement
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor
2020-09-03 13:18 [Bug gcov-profile/96919] New: [GCOV] uncovered line of stack allocation while using virutal destructor youngseok.roh.de at gmail dot com
` (9 preceding siblings ...)
2020-12-02 17:10 ` bhavana.kilambi at blackfigtech dot com
@ 2020-12-03 10:01 ` marxin at gcc dot gnu.org
2020-12-29 9:17 ` bhavana.kilambi at blackfigtech dot com
` (5 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: marxin at gcc dot gnu.org @ 2020-12-03 10:01 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96919
--- Comment #11 from Martin Liška <marxin at gcc dot gnu.org> ---
(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
...
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor
2020-09-03 13:18 [Bug gcov-profile/96919] New: [GCOV] uncovered line of stack allocation while using virutal destructor youngseok.roh.de at gmail dot com
` (10 preceding siblings ...)
2020-12-03 10:01 ` marxin at gcc dot gnu.org
@ 2020-12-29 9:17 ` bhavana.kilambi at blackfigtech dot com
2021-01-06 11:55 ` marxin at gcc dot gnu.org
` (4 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: bhavana.kilambi at blackfigtech dot com @ 2020-12-29 9:17 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96919
--- Comment #12 from Bhavana Kilambi <bhavana.kilambi at blackfigtech dot com> ---
Created attachment 49851
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49851&action=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
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor
2020-09-03 13:18 [Bug gcov-profile/96919] New: [GCOV] uncovered line of stack allocation while using virutal destructor youngseok.roh.de at gmail dot com
` (11 preceding siblings ...)
2020-12-29 9:17 ` bhavana.kilambi at blackfigtech dot com
@ 2021-01-06 11:55 ` marxin at gcc dot gnu.org
2021-01-06 13:55 ` bhavana.kilambi at blackfigtech dot com
` (3 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: marxin at gcc dot gnu.org @ 2021-01-06 11:55 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96919
--- Comment #13 from Martin Liška <marxin at gcc dot gnu.org> ---
> 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?
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor
2020-09-03 13:18 [Bug gcov-profile/96919] New: [GCOV] uncovered line of stack allocation while using virutal destructor youngseok.roh.de at gmail dot com
` (12 preceding siblings ...)
2021-01-06 11:55 ` marxin at gcc dot gnu.org
@ 2021-01-06 13:55 ` bhavana.kilambi at blackfigtech dot com
2021-01-07 13:27 ` marxin at gcc dot gnu.org
` (2 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: bhavana.kilambi at blackfigtech dot com @ 2021-01-06 13:55 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96919
--- Comment #14 from Bhavana Kilambi <bhavana.kilambi at blackfigtech dot com> ---
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor
2020-09-03 13:18 [Bug gcov-profile/96919] New: [GCOV] uncovered line of stack allocation while using virutal destructor youngseok.roh.de at gmail dot com
` (13 preceding siblings ...)
2021-01-06 13:55 ` bhavana.kilambi at blackfigtech dot com
@ 2021-01-07 13:27 ` marxin at gcc dot gnu.org
2022-04-21 9:29 ` marxin at gcc dot gnu.org
2023-04-03 9:04 ` marxin at gcc dot gnu.org
16 siblings, 0 replies; 18+ messages in thread
From: marxin at gcc dot gnu.org @ 2021-01-07 13:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96919
Martin Liška <marxin at gcc dot gnu.org> 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 <marxin at gcc dot gnu.org> ---
(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<arc_info *> branches;
- /* blocks which start on this line. Used in all-blocks mode. */
+ /* Blocks which contain this line. */
vector<block_info *> 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 = &fn->blocks[src];
@@ -1804,6 +1805,8 @@ read_graph_file (void)
arc = XCNEW (arc_info);
arc->dst = &fn->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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor
2020-09-03 13:18 [Bug gcov-profile/96919] New: [GCOV] uncovered line of stack allocation while using virutal destructor youngseok.roh.de at gmail dot com
` (14 preceding siblings ...)
2021-01-07 13:27 ` marxin at gcc dot gnu.org
@ 2022-04-21 9:29 ` marxin at gcc dot gnu.org
2023-04-03 9:04 ` marxin at gcc dot gnu.org
16 siblings, 0 replies; 18+ messages in thread
From: marxin at gcc dot gnu.org @ 2022-04-21 9:29 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96919
Martin Liška <marxin at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|12.0 |---
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor
2020-09-03 13:18 [Bug gcov-profile/96919] New: [GCOV] uncovered line of stack allocation while using virutal destructor youngseok.roh.de at gmail dot com
` (15 preceding siblings ...)
2022-04-21 9:29 ` marxin at gcc dot gnu.org
@ 2023-04-03 9:04 ` marxin at gcc dot gnu.org
16 siblings, 0 replies; 18+ messages in thread
From: marxin at gcc dot gnu.org @ 2023-04-03 9:04 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96919
Martin Liška <marxin at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |NEW
Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot gnu.org
^ permalink raw reply [flat|nested] 18+ messages in thread