GCC Bugzilla Bug 20815

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.