[Bug gcov-profile/110561] New: gcov counts closing bracket in a function as executable, lowering coverage statistics

[Bug gcov-profile/110561] New: gcov counts closing bracket in a function as executable, lowering coverage statistics

[carlosgalvezp at gmail dot com]

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

            Bug ID: 110561
           Summary: gcov counts closing bracket in a function as
                    executable, lowering coverage statistics
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: gcov-profile
          Assignee: unassigned at gcc dot gnu.org
          Reporter: carlosgalvezp at gmail dot com
                CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 55481
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55481&action=edit
Line 18 wrongly reported as lacking code coverage

Hi!

We are using GCC trunk on Ubuntu 22.04
(d08f2e4f74583e27002368989bba197f8eb7f6d2).

Consider the following code example:

#include <vector>
#include <string>

std::string joinPath(std::vector<std::string> const& path_parts)
{
    std::string path{};
    for (auto const& path_part : path_parts)
    {
        if (!path.empty())
        {
            path += "/";
        }

        path += path_part;
    }

    return path;
}

int main()
{
  std::vector<std::string> strings = {"foo", "bar"};
  joinPath(strings);
}

Following this process (taken from here:
https://medium.com/@xianpeng.shen/use-gcov-and-lcov-to-perform-code-coverage-testing-for-c-c-projects-c85708b91c78)
to compute coverage:

$ g++ main.cpp --coverage -o main
$ ./main
$ gcov main.cpp
$ lcov --capture --directory . --output-file coverage.info
$ genhtml coverage.info --output-directory out

Leads to a coverage report that says that line 18 is missing code coverage,
which is incorrect since it's just the closing bracket of the function (see
attached picture).

I can see that things go wrong already at the gcov output, so it's not a
rendering/LCOV issue:

$ cat main.cpp.gcov 
        -:    0:Source:main.cpp
        -:    0:Graph:main.gcno
        -:    0:Data:main.gcda
        -:    0:Runs:1
        -:    1:#include <vector>
        -:    2:#include <string>
        -:    3:
        1:    4:std::string joinPath(std::vector<std::string> const&
path_parts)
        -:    5:{
        1:    6:    std::string path{};
        3:    7:    for (auto const& path_part : path_parts)
        -:    8:    {
        2:    9:        if (!path.empty())
        -:   10:        {
        1:   11:            path += "/";
        -:   12:        }
        -:   13:
        2:   14:        path += path_part;
        -:   15:    }
        -:   16:
        1:   17:    return path;
    =====:   18:}
        -:   19:
        1:   20:int main()
        -:   21:{
        2:   22:  std::vector<std::string> strings = {"foo", "bar"};
        1:   23:  joinPath(strings);
        1:   24:}

This problem does not happen always, just on particular cases (I haven't been
able to establish a pattern).

Do you know what could be the problem? Thanks!

[Bug gcov-profile/110561] gcov counts closing bracket in a function as executable, lowering coverage statistics

[vanyacpp at gmail dot com]

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

Ivan Sorokin <vanyacpp at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vanyacpp at gmail dot com

--- Comment #1 from Ivan Sorokin <vanyacpp at gmail dot com> ---
Smaller reproducer:

struct non_trivial
{
    non_trivial();
    non_trivial(non_trivial const&);
    non_trivial& operator=(non_trivial const&);
    ~non_trivial();

    void escape();
};

non_trivial foobar()
{
    non_trivial result;
    result.escape();
    return result;
}

https://gcc.godbolt.org/z/s5fG6ezxd

Here is the code generated after escape() until the end of function:

.LEHB1:
        call    non_trivial::escape()
.LEHE1:
        .loc 1 15 12
        nop
        mov     rax, QWORD PTR __gcov0.foobar()[rip+24]
        add     rax, 1
        mov     QWORD PTR __gcov0.foobar()[rip+24], rax
        jmp     .L5                                         # unconditional
jump to function exit
.L4:
        mov     rbx, rax                                    # exceptional case
        mov     rax, QWORD PTR __gcov0.foobar()[rip+16]
        add     rax, 1
        mov     QWORD PTR __gcov0.foobar()[rip+16], rax
        .loc 1 16 1
        mov     rax, QWORD PTR [rbp-24]
        mov     rdi, rax
        call    non_trivial::~non_trivial() [complete object destructor]
        mov     rax, QWORD PTR __gcov0.foobar()[rip+32]     # increments the
counter for }
        add     rax, 1
        mov     QWORD PTR __gcov0.foobar()[rip+32], rax
        mov     rax, rbx
        mov     rdi, rax
.LEHB2:
        call    _Unwind_Resume
.LEHE2:
.L5:
        mov     rax, QWORD PTR [rbp-24]                    # doesn't increment
the counter for }
        mov     rbx, QWORD PTR [rbp-8]
        leave
        .cfi_def_cfa 7, 8
        ret
        .cfi_endproc

From what I understand the counter for } is incremented in the exceptional
codepath that is executed when an exception is thrown from escape(). Normal
codepath doesn't increment it.

This looks like a bug to me. The counter for } should be either incremented on
both codepaths or should not exist at all.

[Bug gcov-profile/110561] gcov counts closing bracket in a function as executable, lowering coverage statistics

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |DUPLICATE
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Dup of bug 12076

*** This bug has been marked as a duplicate of bug 12076 ***

[Bug gcov-profile/110561] gcov counts closing bracket in a function as executable, lowering coverage statistics

[carlosgalvezp at gmail dot com]

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

--- Comment #3 from Carlos Galvez <carlosgalvezp at gmail dot com> ---
I forgot to clarify that this bug is _not_ present on gcc 7.5.0 (from where we
are bumping), so I believe it's a regression in that regard. Do you still
believe it's a duplicate of the bug mentioned above?

[Bug gcov-profile/110561] gcov counts closing bracket in a function as executable, lowering coverage statistics

[carlosgalvezp at gmail dot com]

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

--- Comment #4 from Carlos Galvez <carlosgalvezp at gmail dot com> ---
To clarify, the .gcov file looks like this (correct) on GCC 7.5.0, which I
believe is newer than the duplicated bug mentioned here:

        -:    0:Source:main.cpp
        -:    0:Graph:main.gcno
        -:    0:Data:main.gcda
        -:    0:Runs:1
        -:    0:Programs:1
        -:    1:#include <vector>
        -:    2:#include <string>
        -:    3:
        1:    4:std::string joinPath(std::vector<std::string> const&
path_parts)
        -:    5:{
        1:    6:    std::string path{};
        3:    7:    for (auto const& path_part : path_parts)
        -:    8:    {
        2:    9:        if (!path.empty())
        -:   10:        {
        1:   11:            path += "/";
        -:   12:        }
        -:   13:
        2:   14:        path += path_part;
        -:   15:    }
        -:   16:
        1:   17:    return path;
        -:   18:}
        -:   19:
        1:   20:int main()
        -:   21:{
        2:   22:  std::vector<std::string> strings = {"foo", "bar"};
        1:   23:  joinPath(strings);
        1:   24:}

[Bug gcov-profile/110561] gcov counts closing bracket in a function as executable, lowering coverage statistics

[carlosgalvezp at gmail dot com]

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

--- Comment #5 from Carlos Galvez <carlosgalvezp at gmail dot com> ---
@Andrew Pinski ping in case you missed my last message. If this were a
duplicate but, wouldn't it also happen in GCC 7.5.0?