如何从 gcov 获得更准确的结果？
我正在使用 mingw gcc 4.4.0 尝试 gcov。我得到了一些有趣但奇怪的结果。常见的模式是这样的...
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:}
考虑到之前的循环显然正在执行和退出，那么 return 怎么可能根本不被执行呢？我认为我是这里返回值优化的受害者，因为这个临时变量的类型是 std::string。
问题是，我已经在编译器选项中指定了 -O0 。这些是我正在使用的确切编译器标志...
-Wno-invalid-offsetof -g -O0 -fprofile-arcs -ftest-coverage
我最好的猜测是，毕竟并非所有优化都被 -O0 禁用。当我发现问题时，我可以开始逐一寻找特定的优化标志，但这似乎是一件奇怪的事情。
那么 - 我应该指定哪些标志才能从 gcov 获得合理的覆盖结果？
编辑
到目前为止，我认为我需要以下附加标志...
- -fno-default-inline
- -fno-inline
我不确定这两个标志是否都需要，尽管我认为它们各自禁用了不同的标志特定类型的内联。
不过，我还没有找到任何方法来禁用返回值优化。这不是一个大问题，但有点令人烦恼。当目标是 100% 覆盖率时，一些真正达到 100% 的文件将因为这个问题而被报告为较少。 grep 可以找到 ##### 标记并显示它们是否用于 return 语句，但您仍然需要进行一些目视检查来检查问题是否存在纯粹是 RVO。
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 coverage 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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
正如 Mat 的评论中所建议的，选项
-fno-elide-constructors解决了这个问题。发布此答案是为了解决这个已经很古老的问题。如果 Mat 发表了答案，我会删除这个并将接受切换到那个。
As suggested in the comment by Mat, the option
-fno-elide-constructorsfixes 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.