11

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。問題に気づいたら、特定の最適化フラグを 1 つずつ探し始めることができますが、これを行う必要があるのは奇妙に思えます。

では、gcov から適切なカバレッジ結果を得るには、どのフラグを指定する必要がありますか?

編集

これまでのところ、次の追加フラグが必要だと思います...

  • -fno-default-inline
  • -fno-インライン

これらの両方が必要かどうかはわかりませんが、それぞれが異なる特定のタイプのインラインを無効にしていると思います。

ただし、戻り値の最適化を無効にする方法は見つかりませんでした。これは大きな問題ではありませんが、少し面倒です。100% のカバレッジを目指している場合、実際には 100% を達成している一部のファイルは、この問題のために少ないと報告されます。#####grep はマーカーを見つけて、それらがreturnステートメント用かどうかを表示できますが、問題が純粋に RVO であることを確認するために、視覚的な検査を行う必要があります。

4

1 に答える 1

3

Matのコメントで示唆されているように、このオプションは-fno-elide-constructorsこの問題を修正します。

この回答は、このすでに古い質問を閉じるために投稿されました。マットが回答を投稿した場合、これを削除して、承認をそれに切り替えます。

于 2011-09-02T15:18:26.453 に答える