This problem is present in at least gcc-3.4.[123], gcc-3.4-20050401, and gcc-4.0-20050305. I have not tested a later gcc-4.0 yet. Create a test file pgo.cc: #include <iostream> namespace { void func() { std::cout << "In func" << std::endl; } } int main() { func(); } Compile it, run it, and recompile it as follows: i686-unknown-linux-gnu-g++ -fprofile-generate -o pgo pgo.cc ./pgo i686-unknown-linux-gnu-g++ -fprofile-use -o pgo pgo.cc The -fprofile-use compilation fails with pgo.cc: In function 'void<unnamed>::func()': pgo.cc:6: error: coverage mismatch for function '_ZN35_GLOBAL__N_pgo.cc_00000000_8B40D3D54funcEv' while reading counter 'arcs'. pgo.cc:6: error: checksum is 5c057dbb instead of 3746c244 Commenting out the namespace makes the problem go away. This keeps me from building some real apps with profile-driven optimization, which may result in switching from gcc to icc for this app. Thanks to Simon Baldwin for finding such a nice little test case for this.
I hate unnamed namespaces since we have to encode some uniqueness and they are still extern because of C++ rules.
The easy work around is set -frandom-seed=somenumber for both the generate and use.
The only thing I can think of to fix this problem is figure out how to write/read the random seed out since right now it is defaults to be basing on time.
Aha. So this is a duplicate of bug 9393, in essence?
Oh, ok, it's not *quite* a dup of 9393, since you could save the seed in the output file from the first run.
What value should be passed for that option? Would the absolute pathnme of the source file do? In case other people out there have as much trouble reading TFM as I do, I should note that the gcc doc says "-frandom-seed=string ... The string should be different for every file you compile." Thus the suggestion in http://lists.freebsd.org/pipermail/freebsd-current/2004-November/042627.html of using the same string always for this option is probably a bad idea.
Or should the doc say also that the argument to -frandom-seed should be the same every time anyone compiles the same file? In that case, the relative path of the file within the project would be a better choice. So when compiling mozilla/main.c you would give -frandomSeed=mozilla/main.c right? Don't know how much this matters.
Subject: Re: [Bug gcov/profile/20815] -fprofile-use barfs with "coverage mismatch for function '...' while reading counter 'arcs'." coverage_checksum_string already knows a bit about ignoring random seed produced mess. It looks like this needs to be extended somehow to handle namespaces too... Honza > > > -- > What |Removed |Added > ---------------------------------------------------------------------------- > Component|middle-end |gcov/profile > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20815 > > ------- You are receiving this mail because: ------- > You are on the CC list for the bug, or are watching someone who is.
Subject: Re: [Bug gcov/profile/20815] -fprofile-use barfs with "coverage mismatch for function '...' while reading counter 'arcs'." > > ------- Additional Comments From hubicka at ucw dot cz 2005-05-18 22:22 ------- > Subject: Re: [Bug gcov/profile/20815] -fprofile-use barfs with "coverage mismatch for function '...' while reading counter 'arcs'." > > coverage_checksum_string already knows a bit about ignoring random seed > produced mess. It looks like this needs to be extended somehow to > handle namespaces too... This seems to solve the missmatch. Would it be possible to test it on bigger testcase and if it works distile a testcase that don't use file IO so it is more suitable for gcc regtesting? Index: coverage.c =================================================================== RCS file: /cvs/gcc/gcc/gcc/coverage.c,v retrieving revision 1.6.2.12.2.12 diff -c -3 -p -r1.6.2.12.2.12 coverage.c *** coverage.c 18 May 2005 07:37:31 -0000 1.6.2.12.2.12 --- coverage.c 18 May 2005 22:45:36 -0000 *************** coverage_checksum_string (unsigned chksu *** 471,505 **** as the checksums are used only for sanity checking. */ for (i = 0; string[i]; i++) { if (!strncmp (string + i, "_GLOBAL__", 9)) ! for (i = i + 9; string[i]; i++) ! if (string[i]=='_') ! { ! int y; ! unsigned seed; ! int scan; ! ! for (y = 1; y < 9; y++) ! if (!(string[i + y] >= '0' && string[i + y] <= '9') ! && !(string[i + y] >= 'A' && string[i + y] <= 'F')) ! break; ! if (y != 9 || string[i + 9] != '_') ! continue; ! for (y = 10; y < 18; y++) ! if (!(string[i + y] >= '0' && string[i + y] <= '9') ! && !(string[i + y] >= 'A' && string[i + y] <= 'F')) ! break; ! if (y != 18) ! continue; ! scan = sscanf (string + i + 10, "%X", &seed); ! gcc_assert (scan); ! if (seed != crc32_string (0, flag_random_seed)) ! continue; ! string = dup = xstrdup (string); ! for (y = 10; y < 18; y++) ! dup[i + y] = '0'; ! break; ! } break; } --- 471,511 ---- as the checksums are used only for sanity checking. */ for (i = 0; string[i]; i++) { + int offset = 0; + if (!strncmp (string + i, "_GLOBAL__N_", 11)) + offset = 11; if (!strncmp (string + i, "_GLOBAL__", 9)) ! offset = 9; ! ! /* C++ namespaces do have scheme: ! _GLOBAL__N_<filename>_<wrongmagicnumber>_<magicnumber>functionname ! since filename might contain extra underscores there seems ! to be no better chance then walk all possible offsets looking ! for magicnuber. */ ! if (offset) ! for (;string[offset]; offset++) ! for (i = i + offset; string[i]; i++) ! if (string[i]=='_') ! { ! int y; ! ! for (y = 1; y < 9; y++) ! if (!(string[i + y] >= '0' && string[i + y] <= '9') ! && !(string[i + y] >= 'A' && string[i + y] <= 'F')) ! break; ! if (y != 9 || string[i + 9] != '_') ! continue; ! for (y = 10; y < 18; y++) ! if (!(string[i + y] >= '0' && string[i + y] <= '9') ! && !(string[i + y] >= 'A' && string[i + y] <= 'F')) ! break; ! if (y != 18) ! continue; ! if (!dup) ! string = dup = xstrdup (string); ! for (y = 10; y < 18; y++) ! dup[i + y] = '0'; ! } break; }
Patch posted: http://gcc.gnu.org/ml/gcc-patches/2005-10/msg01691.html
I tested only simplified testcase, but the issue should be resolved pretty safely.
Subject: Bug 20815 Author: hubicka Date: Thu Apr 6 20:33:21 2006 New Revision: 112738 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112738 Log: PR profile/20815 PR profile/26399 * coverage.c (coverage_checksum_string): Reorganize loop to not read after buffer. * g++.dg/bprob/g++-bprob-2.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/bprob/g++-bprob-2.C Modified: trunk/gcc/ChangeLog trunk/gcc/coverage.c trunk/gcc/testsuite/ChangeLog
*** Bug 27738 has been marked as a duplicate of this bug. ***
I'm still getting this with gcc 4.2.2 ... can I re-open it?
(In reply to comment #14) > I'm still getting this with gcc 4.2.2 ... can I re-open it? > BTW, the test case is the Ruby interpreter.