title: How can I get more accurate results from gcov?
body: <p>I'm experimenting with gcov using mingw gcc 4.4.0. I've been getting some interesting but strange results. A common pattern is something like this...</p>
  
  <pre><code>     5162:   66:  std::string::iterator i = l_Temp.begin ();
       5162:   67:  std::string::iterator j = l_Temp.end () - 1;
          -:   68:  char ch;
          -:   69:
      20564:   70:  while (i &lt; j)
          -:   71:  {
      10240:   72:    ch = *i; *i = *j; *j = ch; i++; j--;
          -:   73:  }
          -:   74:
      #####:   75:  return l_Temp;
          -:   76:}
  </code></pre>
  
  <p>How can that <code>return</code> not be exected at all, given that the loop just before clearly is both executing and exiting? I think I'm a victim of the return value optimisation here, given that this temporary variable is of type <code>std::string</code>.</p>
  
  <p>The trouble is, I'm already specifying <code>-O0</code> in the compiler options. These are the exact compiler flags I'm using...</p>
  
  <pre><code>-Wno-invalid-offsetof -g -O0 -fprofile-arcs -ftest-coverage
  </code></pre>
  
  <p>My best guess is that not all optimisations are disabled by <code>-O0</code> after all. I can start hunting down specific optimisation flags one by one as I notice problems, but this seems a strange thing to need to do.</p>
  
  <p>So - what flags <em>should</em> I be specifying in order to get sane coverage results from gcov?</p>
  
  <p><strong>EDIT</strong></p>
  
  <p>So far, I think I need the following additional flags...</p>
  
  <ul>
  <li>-fno-default-inline</li>
  <li>-fno-inline</li>
  </ul>
  
  <p>I'm not sure these are both needed, though I think they each disable a different specific type of inline.</p>
  
  <p>I haven't found any way to disable return value optimisations, though. This isn't a big problem, but it's a bit of an annoyance. When aiming for 100% coverage, some files that really do achieve 100% will be reported as less because of this issue. A grep can find the <code>#####</code> markers and show if they're for <code>return</code> statements, but you still need to do some visual inspection to check that the problem is purely an RVO.</p>