[Bug gcov-profile/110561] gcov counts closing bracket in a function as executable, lowering coverage statistics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110561 --- Comment #5 from Carlos Galvez --- @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?
[Bug gcov-profile/110561] gcov counts closing bracket in a function as executable, lowering coverage statistics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110561
--- Comment #4 from Carlos Galvez ---
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
-:2:#include
-:3:
1:4:std::string joinPath(std::vector 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 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110561 --- Comment #3 from Carlos Galvez --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110561 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110561
Ivan Sorokin changed:
What|Removed |Added
CC||vanyacpp at gmail dot com
--- Comment #1 from Ivan Sorokin ---
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:
callnon_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
callnon_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.
