[Bug gcov-profile/110827] New: C++20 coroutines aren't being measured by gcov

[Bug gcov-profile/110827] New: C++20 coroutines aren't being measured by gcov

[mwd at md5i dot com]

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

            Bug ID: 110827
           Summary: C++20 coroutines aren't being measured by gcov
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: gcov-profile
          Assignee: unassigned at gcc dot gnu.org
          Reporter: mwd at md5i dot com
                CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 55648
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55648&action=edit
Simple bug exemplar

When compiling with `--coverage` and running a program that utilizes C++20
coroutines, the statements in the coroutines aren't measured by gcov.

Compile the attached file, `foo.cpp`, with:
`g++ -std=c++20 --coverage -O0 -ggdb3 -o foo foo.cpp`

Then run the resulting `foo`, followed by `gcov foo.cpp`.

The resulting output in `foo.cpp.gcov` does not include lines 28 or 29 of
`foo.cpp`, the contents of the coroutine `foo()`.  In my tests this happens
with any coroutine of any size, though functions called by a coroutine are
covered properly.

[Bug gcov-profile/110827] C++20 coroutines aren't being measured by gcov

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-07-27
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
                 CC|                            |iains at gcc dot gnu.org

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
I'm seeing all code properly instrumented.  The coverage I see is

        -:    1:#include <coroutine>
        -:    2:#include <iostream>
        -:    3:
        -:    4:struct task {
        -:    5:  struct promise {
        -:    6:    using handle_t = std::coroutine_handle<promise>;
        1:    7:    task get_return_object() {
        1:    8:      return task{handle_t::from_promise(*this)};
        -:    9:    }
        1:   10:    std::suspend_never initial_suspend() noexcept { return {};
}
        1:   11:    std::suspend_always final_suspend() noexcept { return {}; }
    #####:   12:    void unhandled_exception() { std::terminate(); }
        1:   13:    void return_void() noexcept {}
        -:   14:    friend task;
        -:   15:  };
        -:   16:  using promise_type = promise;
        1:   17:  task(promise_type::handle_t handle) : handle_{handle} {}
        1:   18:  ~task() {
        1:   19:    if (handle_) {
        1:   20:      handle_.destroy();
        -:   21:    }
        1:   22:  }
        -:   23: private:
        -:   24:  promise_type::handle_t handle_;
        -:   25:};
        -:   26:
        1:   27:task foo() {
        -:   28:  std::cout << "Running..." << std::endl;
        -:   29:  co_return;
        2:   30:}
        -:   31:
        1:   32:int main(int argc, char **argv) {
        1:   33:  foo();
        1:   34:  return 0;
        -:   35:}

I have no idea why for example line 28 isn't marked executed.

[Bug gcov-profile/110827] C++20 coroutines aren't being measured by gcov

[iains at gcc dot gnu.org]

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

--- Comment #2 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #1)
> I'm seeing all code properly instrumented.  The coverage I see is
<snip>
>         1:   27:task foo() {
>         -:   28:  std::cout << "Running..." << std::endl;
>         -:   29:  co_return;
>         2:   30:}
<snip>
> 
> I have no idea why for example line 28 isn't marked executed.

So we are recognising that the ramp function has run:
 foo () {
 .... compiler-generated code with no line numbers
 }

but execution of the the outlined body (which is the 'actor' function) is not,
apparently recorded.

The actor is essentially:

foo.actor()
 .. compiler-generated code no line numbers
 {
   std::cout << "Running..." << std::endl;
   co_return;
 }
 .. compiler-generated code no line numbers

co_return expands to some compiler-generated code too - so it's possible the
line numbers get confusing there - but the cout line ought to be
uncontroversial.

[Bug gcov-profile/110827] C++20 coroutines aren't being measured by gcov

[mwd at md5i dot com]

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

--- Comment #3 from Michael Duggan <mwd at md5i dot com> ---
(In reply to Richard Biener from comment #1)
> I'm seeing all code properly instrumented.  The coverage I see is
> 
>         -:    1:#include <coroutine>
>         -:    2:#include <iostream>
>         -:    3:
>         -:    4:struct task {
>         -:    5:  struct promise {
>         -:    6:    using handle_t = std::coroutine_handle<promise>;
>         1:    7:    task get_return_object() {
>         1:    8:      return task{handle_t::from_promise(*this)};
>         -:    9:    }
>         1:   10:    std::suspend_never initial_suspend() noexcept { return
> {}; }
>         1:   11:    std::suspend_always final_suspend() noexcept { return
> {}; }
>     #####:   12:    void unhandled_exception() { std::terminate(); }
>         1:   13:    void return_void() noexcept {}
>         -:   14:    friend task;
>         -:   15:  };
>         -:   16:  using promise_type = promise;
>         1:   17:  task(promise_type::handle_t handle) : handle_{handle} {}
>         1:   18:  ~task() {
>         1:   19:    if (handle_) {
>         1:   20:      handle_.destroy();
>         -:   21:    }
>         1:   22:  }
>         -:   23: private:
>         -:   24:  promise_type::handle_t handle_;
>         -:   25:};
>         -:   26:
>         1:   27:task foo() {
>         -:   28:  std::cout << "Running..." << std::endl;
>         -:   29:  co_return;
>         2:   30:}
>         -:   31:
>         1:   32:int main(int argc, char **argv) {
>         1:   33:  foo();
>         1:   34:  return 0;
>         -:   35:}
> 
> I have no idea why for example line 28 isn't marked executed.

The point is that no matter what is put in the coroutine, foo, nothing within
the coroutine will ever be marked as having been run.

[Bug gcov-profile/110827] C++20 coroutines aren't being measured by gcov

[mwd at md5i dot com]

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

--- Comment #4 from Michael Duggan <mwd at md5i dot com> ---
I should be more explicit.  The `std::cout` line in the example is just a
placeholder for "does some work here," and this example is specifically the
simplest version of a coroutine I could come up with that would demonstrate the
problem.  When I initially encountered this problem, I was doing coverage
testing that included a coroutine that was over 70 lines long, includes lots of
loops and branching, and exited and re-entered multiple times via `co_yield`. 
I wanted to know if my test programs properly covered all of the branches.  It
is not enough to know how many times the coroutine itself is called.

[Bug gcov-profile/110827] C++20 coroutines aren't being measured by gcov

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Iain Sandoe from comment #2)
> (In reply to Richard Biener from comment #1)
> > I'm seeing all code properly instrumented.  The coverage I see is
> <snip>
> >         1:   27:task foo() {
> >         -:   28:  std::cout << "Running..." << std::endl;
> >         -:   29:  co_return;
> >         2:   30:}
> <snip>
> > 
> > I have no idea why for example line 28 isn't marked executed.
> 
> So we are recognising that the ramp function has run:
>  foo () {
>  .... compiler-generated code with no line numbers
>  }
> 
> but execution of the the outlined body (which is the 'actor' function) is
> not, apparently recorded.
> 
> The actor is essentially:
>  
> foo.actor()
>  .. compiler-generated code no line numbers
>  {
>    std::cout << "Running..." << std::endl;
>    co_return;
>  }
>  .. compiler-generated code no line numbers
> 
> co_return expands to some compiler-generated code too - so it's possible the
> line numbers get confusing there - but the cout line ought to be
> uncontroversial.

Hmm, OK.  I see both 'task foo' and _Z3fooPZ3foovE13_Z3foov.Frame.actor
printed as functions "foo" in the IL dump.  Maybe coverage is somehow
confused here.

Maybe coverage doesn't work with nested functions (or C++ lambda) either?

As said, there are edge counters present so it must be either a bug on
the receiving side (in gcov) or the data is not appropriately attributed.

[Bug gcov-profile/110827] C++20 coroutines aren't being measured by gcov

[iains at gcc dot gnu.org]

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

--- Comment #6 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #5)
> (In reply to Iain Sandoe from comment #2)
> > (In reply to Richard Biener from comment #1)
> > > I'm seeing all code properly instrumented.  The coverage I see is
> > <snip>
> > >         1:   27:task foo() {
> > >         -:   28:  std::cout << "Running..." << std::endl;
> > >         -:   29:  co_return;
> > >         2:   30:}
> > <snip>
> > > 
> > > I have no idea why for example line 28 isn't marked executed.
> > 
> > So we are recognising that the ramp function has run:
> >  foo () {
> >  .... compiler-generated code with no line numbers
> >  }
> > 
> > but execution of the the outlined body (which is the 'actor' function) is
> > not, apparently recorded.
> > 
> > The actor is essentially:
> >  
> > foo.actor()
> >  .. compiler-generated code no line numbers
> >  {
> >    std::cout << "Running..." << std::endl;
> >    co_return;
> >  }
> >  .. compiler-generated code no line numbers
> > 
> > co_return expands to some compiler-generated code too - so it's possible the
> > line numbers get confusing there - but the cout line ought to be
> > uncontroversial.
> 
> Hmm, OK.  I see both 'task foo' and _Z3fooPZ3foovE13_Z3foov.Frame.actor
> printed as functions "foo" in the IL dump.

We have to do that or debug and things like __PRETTY_FUNCTION__ get confused
(which led to other Pas).

>  Maybe coverage is somehow confused here.

Perhaps, I do not know much about how the coverage stuff is supposed to
operate.
coroutine 'helper' functions are marked as such in the function struct - so it
is possible to special-case them.

> Maybe coverage doesn't work with nested functions (or C++ lambda) either?

the coroutine helpers are not (formally) nested i.e. they do _not_ use the
nested.cc machinery or a STATIC_CHAIN. (actually, AFAIU lambdas are the same).

However, they are both probably 'artificial' and/or anonymous?

> As said, there are edge counters present so it must be either a bug on
> the receiving side (in gcov) or the data is not appropriately attributed.

The basic shape of the coroutine helper functions is 'normal' (other than 
being
artificial) - most of the work is already complete before gimplification - the
idea being that they should look as normal as possible to the middle end to
allow maximum opportunity for optimisation.

[Bug gcov-profile/110827] C++20 coroutines aren't being measured by gcov

[mwd at md5i dot com]

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

Michael Duggan <mwd at md5i dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #55648|0                           |1
        is obsolete|                            |

--- Comment #7 from Michael Duggan <mwd at md5i dot com> ---
Created attachment 55812
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55812&action=edit
Better example

This example has both a coroutine and a non-coroutine with the same contents. 
Rather than using cout, it calls an empty function that is designed to not be
optimized away.

[Bug gcov-profile/110827] C++20 coroutines aren't being measured by gcov

[mwd at md5i dot com]

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

--- Comment #8 from Michael Duggan <mwd at md5i dot com> ---
Using the better test case, I have determined that the coroutine _is_ being
instrumented with gcov counters.  When disassembled, the output contains the
following in the bar() actor function:

Dump of assembler code for function bar(_Z3barv.Frame *):
...
   0x00005555555567a3 <+527>:   mov    0x5286(%rip),%rax        #
0x55555555ba30 <__gcov0._Z3barPZ3barvE13_Z3barv.Frame.actor+112>
   0x00005555555567aa <+534>:   add    $0x1,%rax
   0x00005555555567ae <+538>:   mov    %rax,0x527b(%rip)        #
0x55555555ba30 <__gcov0._Z3barPZ3barvE13_Z3barv.Frame.actor+112>
=> 0x00005555555567b5 <+545>:   call   0x555555556359 <_Z5emptyv>
   0x00005555555567ba <+550>:   mov    0x5277(%rip),%rax        #
0x55555555ba38 <__gcov0._Z3barPZ3barvE13_Z3barv.Frame.actor+120>
   0x00005555555567c1 <+557>:   add    $0x1,%rax
   0x00005555555567c5 <+561>:   mov    %rax,0x526c(%rip)        #
0x55555555ba38 <__gcov0._Z3barPZ3barvE13_Z3barv.Frame.actor+120>
   0x00005555555567cc <+568>:   call   0x555555556359 <_Z5emptyv>
   0x00005555555567d1 <+573>:   mov    0x5268(%rip),%rax        #
0x55555555ba40 <__gcov0._Z3barPZ3barvE13_Z3barv.Frame.actor+128>
   0x00005555555567d8 <+580>:   add    $0x1,%rax
   0x00005555555567dc <+584>:   mov    %rax,0x525d(%rip)        #
0x55555555ba40 <__gcov0._Z3barPZ3barvE13_Z3barv.Frame.actor+128>
   0x00005555555567e3 <+591>:   call   0x555555556359 <_Z5emptyv>


Therefore, the problem probably lies in either in the mapping from the counters
to the line numbers or in gcov itself, possibly by missing the "actor" version
of bar in favor of the ramp function.

I'll note the following entries in the symbol table, from readelf:

    36: 0000000000007aa0    96 OBJECT  LOCAL  DEFAULT   27 __gcov0._Z3barv
    37: 0000000000002594   943 FUNC    LOCAL  DEFAULT   15
bar(bar()::_Z3barv.Frame*) [clone .actor]
    38: 0000000000002943    83 FUNC    LOCAL  DEFAULT   15
bar(bar()::_Z3barv.Frame*) [clone .destroy]
    39: 00000000000079c0   216 OBJECT  LOCAL  DEFAULT   27
__gcov0._Z3barPZ3barvE13_Z3barv.Frame.actor
    40: 00000000000079b0    16 OBJECT  LOCAL  DEFAULT   27
__gcov0._Z3barPZ3barvE13_Z3barv.Frame.destroy
   107: 00000000000023e2   434 FUNC    GLOBAL DEFAULT   15 bar()

[Bug gcov-profile/110827] C++20 coroutines aren't being measured by gcov

[mwd at md5i dot com]

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

--- Comment #9 from Michael Duggan <mwd at md5i dot com> ---
More data:
The coroutine actor is marked as artificial in
coro_build_actor_or_destroy_function.  As a result, it is completely ignored by
gcov.  In gcov's process_all_functions function, artificial functions are
removed from the set of functions to consider.  This may not be the only
problem, but this will definitely prevent things from working.

The marking is not incorrect.  The actor function is artificial.  But, unlike
most artificial functions, it is built using the body of an actual function. 
I'm not certain how that should be dealt with.

[Bug gcov-profile/110827] C++20 coroutines aren't being measured by gcov

[mwd at md5i dot com]

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

--- Comment #10 from Michael Duggan <mwd at md5i dot com> ---
To sum up what I have figured out, C++ transforms the coroutine "function" into
a trio of functions: a ramp function, an actor function, and a destruction
function.  The ramp function acts as the actual function (by name).  The actor
function contains the original body of the written function (with some
transformations), and thus contains the code associated with most of the lines
that need coverage information.

Since the actor function is generated artificially, it is marked as artificial.
 The gcov program explicitly ignores functions that are marked as artificial. 
Also, even if that were not the case, it looks to me like the line coverage
information for the actor function only includes the initial line of the
function.  This seems to be due to the way the artificial function gets
inserted into the list of functions of the program.

In order to solve this problem, we would need to at least the following: 
  Find a way to not ignore the actor function.  This would involve either not
marking it as artificial or by marking it in some other way that would be
recognized by gcov.
  Ensure that the actor function properly includes the line number information
from the original coroutine body.

Most of this work would probably need to be done in the c++ code (where the
coroutine transformation happens) rather than in the coverage code.  Should
this be reassigned to the c++ component?

[Bug gcov-profile/110827] C++20 coroutines aren't being measured by gcov

[iains at gcc dot gnu.org]

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

--- Comment #11 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Michael Duggan from comment #9)
> More data:
> The coroutine actor is marked as artificial in
> coro_build_actor_or_destroy_function.  As a result, it is completely ignored
> by gcov.  In gcov's process_all_functions function, artificial functions are
> removed from the set of functions to consider.  This may not be the only
> problem, but this will definitely prevent things from working.
> 
> The marking is not incorrect.  The actor function is artificial.  But,
> unlike most artificial functions, it is built using the body of an actual
> function.  I'm not certain how that should be dealt with.

right, so I wonder what happens:

1. if you temporarily patch the C++ FE to make the "actor" function
non-artificial (it is actually a combination of compiler-generated, artificial,
code and the outlined user's function body).

2. if we reorganised things to have a non-artificial outlined actor but have
that called via two 'shim' functions (one for resume() and one for destroy()) -
and have those two functions as artificial.

3. if an artificial function is inlined into a non-artificial one?
4. if a non-artificial function is inlined into an artificial one?

(I am not too familiar with how the coverage code interacts with other things)