[Bug gcov-profile/67992] GCOV takes an absurdly long time to process a file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67992 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Martin Liška --- Fixed on trunk in r239169.
[Bug gcov-profile/67992] GCOV takes an absurdly long time to process a file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67992 --- Comment #7 from Jan Hubicka --- Joshua: gcov is seriously old tool. There is quite some need to handle profile in more generic matter (for autoFDO/LTO and other cases). So if you have more flexible implementation, it would make sense to replace it ;))
[Bug gcov-profile/67992] GCOV takes an absurdly long time to process a file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67992 Jan Hubicka changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-05-20 CC||hubicka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #6 from Jan Hubicka --- I will take a look. The algorithm choosing minimal spanning tree can be adjusted to make the solving algorithm converge faster. I will need to re-think the details. It is well over a decade.
[Bug gcov-profile/67992] GCOV takes an absurdly long time to process a file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67992
--- Comment #5 from Jakub Jelinek ---
Shorter testcase:
struct A
{
char a1, a2, a3, a4, a5, a6, a7, a8, a9;
char b1, b2, b3, b4, b5, b6, b7, b8, b9;
char c1, c2, c3, c4, c5;
};
struct A s;
int
main ()
{
if (__builtin_expect (s.a1 < 0 || s.a1 > 200 || s.a2 < 0 || s.a2 > 200
|| s.a3 < 0 || s.a3 > 200 || s.a4 < 0 || s.a4 > 200
|| s.a5 < 0 || s.a5 > 200 || s.a6 < 0 || s.a6 > 200
|| s.a7 < 0 || s.a7 > 200 || s.a8 < 0 || s.a8 > 200
|| s.a9 < 0 || s.a9 > 200 || s.b1 < 0 || s.b1 > 200
|| s.b2 < 0 || s.b2 > 200 || s.b3 < 0 || s.b3 > 200
|| s.b4 < 0 || s.b4 > 200 || s.b5 < 0 || s.b5 > 200
|| s.b6 < 0 || s.b6 > 200 || s.b7 < 0 || s.b7 > 200
|| s.b8 < 0 || s.b8 > 200 || s.b9 < 0 || s.b9 > 200
|| s.c1 < 0 || s.c1 > 200 || s.c2 < 0 || s.c2 > 200
|| s.c3 < 0 || s.c3 > 200 || s.c4 < 0 || s.c4 > 200
|| s.c5 < 0 || s.c5 > 200, 0))
__builtin_printf ("hello\n");
return 0;
}
[Bug gcov-profile/67992] GCOV takes an absurdly long time to process a file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67992 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- *** Bug 71046 has been marked as a duplicate of this bug. ***
[Bug gcov-profile/67992] GCOV takes an absurdly long time to process a file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67992 Jan Stancek changed: What|Removed |Added CC||jan.stancek at gmail dot com --- Comment #3 from Jan Stancek --- Created attachment 36992 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36992&action=edit reproducer based off linux kernel fs/xfs/libxfs/xfs_sb.c I came across this problem while running lcov on gcov enabled kernel. gcov is really struggling with xfs_sb.c - it takes up to _36 hours_ to complete on Intel Xeon CPUs. I narrowed it down to following condition: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/fs/xfs/libxfs/xfs_sb.c?h=v4.4-rc4#n229 And based on that I made the attached reproducer. To reproduce run: gcc -O2 -fprofile-arcs -ftest-coverage test1.c ./a.out gcov -b -c -d -a test1.gcda
[Bug gcov-profile/67992] GCOV takes an absurdly long time to process a file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67992 --- Comment #2 from Richard Biener --- I think there is a duplicate about gcov slowness for some sort of CFGs.
[Bug gcov-profile/67992] GCOV takes an absurdly long time to process a file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67992 --- Comment #1 from Joshua Cranmer --- Created attachment 36531 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36531&action=edit Implementation of Hawick's algorithm in C++ This is test code I wrote to figure out why I couldn't reproduce the output of gcov correctly (which eventually led me to discovering bug 67937). It's an ersatz variant of gcov (whose code is not included), except the latter half of processing was replaced with my own code. So there's a mixture of use of both gcov's arc_t, block_t, etc. structures with my own C++ classes Arc/Block/etc. I also ripped out the code that supported options I didn't need to use (I effectively only do gcov -a -b -p). The main code in question is getCycleCounts (on line 494) and the cycle detection code that comprises the prior 100 lines of code. The has_negate/rerunning findCycles trick is needed because of bug 67937. This roughly replaces the main Tiernan's algorithm loop of accumulate_line_counts (about line 2200 of gcov.c) (the rest of the function is more fully captured by LineInfo::computeCounts/CoverageMap::computeLineCounts). I'd do a patch myself, but, honestly, the C code of gcov is painful for me to follow, and I've never set myself up to do gcc development.
