[Bug gcov-profile/96919] New: [GCOV] uncovered line of stack allocation while using virutal destructor

[Bug gcov-profile/96919] New: [GCOV] uncovered line of stack allocation while using virutal destructor

[youngseok.roh.de at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96919

            Bug ID: 96919
           Summary: [GCOV] uncovered line of stack allocation while using
                    virutal destructor
           Product: gcc
           Version: 8.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: gcov-profile
          Assignee: unassigned at gcc dot gnu.org
          Reporter: youngseok.roh.de at gmail dot com
                CC: marxin at gcc dot gnu.org
  Target Milestone: ---

I have different result since GCC8. It looks like connecting to the virtual
destructor.

<~ GCC 7.4.0>
$ cat main.cpp.gcov 
        -:    0:Source:main.cpp
        -:    0:Graph:main.gcno
        -:    0:Data:main.gcda
        -:    0:Runs:1
        -:    0:Programs:1
        -:    1:#include "hello.h"
        -:    2:
        1:    3:int main(int argc, char* argv[]) {
        2:    4:  Hello hello;
        1:    5:  hello.foo();
        1:    6:  return 0;
        -:    7:}
        -:    8:
<GCC 8.2.0 ~>
$ cat main.cpp.gcov 
        -:    0:Source:main.cpp
        -:    0:Graph:main.gcno
        -:    0:Data:main.gcda
        -:    0:Runs:1
        -:    0:Programs:1
        -:    1:#include "hello.h"
        -:    2:
        1:    3:int main(int argc, char* argv[]) {
    #####:    4:  Hello hello;
        1:    5:  hello.foo();
        1:    6:  return 0;
        -:    7:}
        -:    8:

Example code is here, and commands as well.
$ cat hello.h
class Base {
public:
  Base() = default;
  virtual ~Base() = default;
  virtual void foo() = 0;
};
class Hello : public Base {
public:
  Hello() = default;
  ~Hello() = default;
  void foo() override;
};

$ cat hello.cpp 
#include "hello.h"
#include <iostream>

using namespace std;

void Hello::foo() {
  cout << "hello" << endl;
}

$ cat main.cpp
#include "hello.h"

int main(int argc, char* argv[]) {
  Hello hello;
  hello.foo();
  return 0;
}

g++ -g -c --coverage -O0 -std=c++11 hello.cpp
g++ -g -c --coverage -O0 -std=c++11 main.cpp
g++ -o test hello.o main.o --coverage -O0

[Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor

[marxin at gcc dot gnu.org]

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.

[Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor

[marxin at gcc dot gnu.org]

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.

[Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor

[filip.pudak at gmail dot com]

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

[Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor

[marxin at gcc dot gnu.org]

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

[Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor

[marxin at gcc dot gnu.org]

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.

[Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor

[libin.dang at gmail dot com]

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.

[Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor

[marxin at gcc dot gnu.org]

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.

[Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor

[bhavana.kilambi at blackfigtech dot com]

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.

[Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor

[bhavana.kilambi at blackfigtech dot com]

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

[Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor

[bhavana.kilambi at blackfigtech dot com]

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

[Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor

[marxin at gcc dot gnu.org]

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
...

[Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor

[bhavana.kilambi at blackfigtech dot com]

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

[Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor

[marxin at gcc dot gnu.org]

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?

[Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor

[bhavana.kilambi at blackfigtech dot com]

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.

[Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor

[marxin at gcc dot gnu.org]

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.

[Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor

[marxin at gcc dot gnu.org]

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                        |---

[Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor

[marxin at gcc dot gnu.org]

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