我正在使用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。
1条答案
按热度按时间pinkon5k1#
正如Mat的评论中所建议的,选项
-fno-elide-constructors
解决了这个问题。这个答案是为了让这个已经过时的问题结束而发布的。如果Mat发布了答案,我将删除这个并将接受切换到那个。