[Bug gcov-profile/68080] New: gcov returns negative counts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68080 Bug ID: 68080 Summary: gcov returns negative counts Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: Pidgeot18 at gmail dot com Target Milestone: --- Created attachment 36576 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36576=edit File to run (See also bug 67937 for bad things that happen when this occurs). I finally minimized a test case that causes negative counts to happen. If you name the attached file TestDeadlockDetector.cpp and run: rm -rf *.gcda && c++ --coverage -std=c++11 -pthread -Os TestDeadlockDetector.cpp && ./a.out && gcov -a -b -p TestDeadlockDetector.gcda && grep -- '-[0-9][0-9]*:' TestDeadlockDetector.cpp.gcov you should usually see ContentionNoDeadlock_thread have negative counts. The exact count changes from each run (and sometimes, it's not negative). The -Os is in the c++ command line is definitely required.
[Bug gcov-profile/68080] gcov returns negative counts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68080 --- Comment #1 from Joshua Cranmer --- For what it's worth: jcranmer@huitzilopochtli /tmp/gcov-dir $ c++ -v Using built-in specs. COLLECT_GCC=c++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 5.2.1-22' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 5.2.1 20151010 (Debian 5.2.1-22)
[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=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.
[Bug gcov-profile/67992] New: GCOV takes an absurdly long time to process a file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67992 Bug ID: 67992 Summary: GCOV takes an absurdly long time to process a file Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: Pidgeot18 at gmail dot com Target Milestone: --- Created attachment 36529 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36529=edit Simple file that exhibits the absurd slowdown. The loop processing code in gcov takes an absurdly long time to compile relatively small files. This comes most obviously into play if you have macro-heavy unrolled code (<https://dxr.mozilla.org/comm-central/source/mozilla/media/libjpeg/jchuff.c#562> is the case in mind here--it's so slow my scripts delete the file rather than wait to process that file). How slow is it? With the attached file: jcranmer@huitzilopochtli /tmp/gcov-bug $ gcc --coverage min.c jcranmer@huitzilopochtli /tmp/gcov-bug $ ./a.out jcranmer@huitzilopochtli /tmp/gcov-bug $ time gcov -a -b -p min.c.gcda File 'min.c' Lines executed:25.00% of 8 Branches executed:0.00% of 168 Taken at least once:0.00% of 168 No calls Creating 'min.c.gcov' real11m20.474s user11m21.476s sys 0m0.000s Some of the literature I've seen claims that the algorithm in use's runtime isn't O(N^3) (as gcov's comment claims) but actually O(k^N). By comparison, using Hawick's algorithm (see <http://complexity.massey.ac.nz/cstn/013/cstn-013.pdf>), it took just: jcranmer@huitzilopochtli /tmp/gcov-bug $ time ~/source/mozilla-tools/newcov/newcov min.c.gcda real0m0.113s user0m0.112s sys 0m0.000s
[Bug gcov-profile/67937] gcov gives wrong results when negative counts are involved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67937 --- Comment #4 from Joshua Cranmer --- (In reply to Richard Biener from comment #3) > Most interesting would be a C testcase that produces the CFG with the bogus > counters ;) Yeah, I know, but doing the minimization on a 5MLOC program takes time.
[Bug gcov-profile/67937] New: gcov gives wrong results when negative counts are involved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67937 Bug ID: 67937 Summary: gcov gives wrong results when negative counts are involved Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: Pidgeot18 at gmail dot com Target Milestone: --- This is hard to name correctly, since there's really a bigger bug here, and I'm focusing on the lesser bug because it's easier for me to build a minimized test case. First the explanation: for whatever reason, sometimes gcov produces counts with negative edges (that's a bug by itself). An minimized example of such a case will be attached to the bug. In this scenario, the graph looks like this: 1147 +-+ -42 /->|B|--\ +-+ +-+ +-+ />|A| V 1189 |D| \ | +-+ +-+ +-+ | | \->|C|--/ | \ 0 +-+ 1189/ \---/ 23 (This is a result of an optimized loop, I don't have the corresponding code on hand, sorry :-( ). In this scenario, the loop detection code finds the following loops: D -> A -> B -> C -> D: loop count = 23 D -> A -> B -> D: loop count = -42 D -> A -> C -> D: loop count = 0 A -> B -> C -> D -> A: loop count = 42 A -> B -> D -> A: loop count = 0 B -> C -> D -> A -> B: loop count = 0 C -> D -> A -> B -> C: loop count = 0 The last four loops are finding permutations of the three simple loops, which is wrong (of course, the fact that one edge has a count of -42 in the first place is wrong in the first place.
[Bug gcov-profile/67937] gcov gives wrong results when negative counts are involved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67937 --- Comment #2 from Joshua Cranmer --- Created attachment 36486 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36486=edit test-case.gcno And the corresponding .gcno file. The testcase was minimized by bisecting the original .gcda/.gcno files by dropping functions and seeing where my attempt to write a new implementation that matched gcov's output failed. The attempt (I did several!) that failed this time was using Boost graph library's hawick_circuits detector, which matched the input incorrectly since this is double-counting loop edges if one of them is negative.
[Bug gcov-profile/67937] gcov gives wrong results when negative counts are involved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67937 --- Comment #1 from Joshua Cranmer --- Created attachment 36485 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36485=edit test-case.gcda (It's a 4.7 test case, but the file format can still be read with trunk gcov the last I checked. Since the originating issue comes from "compile Firefox", I haven't tried preparing .gcda/.gcno files from newer gcc).
