The arc instrumentation code generated by -fprofile-arcs increments gcov counters in a manner which is not guaranteed to be atomic. As a result, if two or more cpus enter the same basic block at nearly the same time they can leave an incorrect arc count, which makes it impossible for gcov to solve that function's arc count graph later.
Within SGI, this is a significant limitation when doing kernel test coverage studies, as we have code that needs to be exercised over multiple processors. The same problem presumably affects people trying to do coverage studies on multithreaded programs in userspace. I've written a patch to solve this problem. It adds a new option, -fprofile-multithread, which changes the tree profiler code to use the recently-added __sync_add_and_fetch() builtin to update the counters. I've tested it on ia64 and i386; it generates the appropriate object code which runs and produces coverage results. Here's a diffstat: common.opt | 4 + doc/invoke.texi | 14 ++++- testsuite/gcc.misc-tests/gcov-12.c | 28 ++++++++++ tree-profile.c | 75 +++++++++++++++++++++++++++++ 4 files changed, 119 insertions(+), 2 deletions(-) Reading the documention at gcc.gnu.org, this looks "legally significant" so I'll need to have some paperwork done right? I assume a copyright assignment form and an employer disclaimer are the correct documents. Can someone start that process? Should I just attach the patch now? -- Summary: Need atomic increment of gcov counters for MP programs Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov/profile AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gnb at sgi dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28441