How can I get more accurate results from gcov?
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...
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 < j)
-: 71: {
10240: 72: ch = *i; *i = *j; *j = ch; i++; j--;
-: 73: }
-: 74:
#####: 75: return l_Temp;
-: 76:}
How can that return
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 std::string
.
The trouble is, I'm already specifying -O0
in the compiler options. These are the exact compiler flags I'm using...
-Wno-invalid-offsetof -g -O0 -fprofile-arcs -ftest-coverage
My best guess is that not all optimisations are disabled by -O0
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.
So - what flags should I be specifying in order to get sane c开发者_C百科overage results from gcov?
EDIT
So far, I think I need the following additional flags...
- -fno-default-inline
- -fno-inline
I'm not sure these are both needed, though I think they each disable a different specific type of inline.
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 #####
markers and show if they're for return
statements, but you still need to do some visual inspection to check that the problem is purely an RVO.
As suggested in the comment by Mat, the option -fno-elide-constructors
fixes this problem.
This answer was posted to get this already ancient question closed. If Mat posts an answer, I'll delete this and switch the accept to that.
精彩评论