コンパイラのテストケースまたはコンパイラのテスト方法
すべてのソフトウェアと同様に、コンパイラもバグや論理エラーが発生しやすくなります。
コンパイラによって生成された出力をどのように検証しますか。通常、私の質問は（です）
生成されたマシンコードが正しいことを検証する方法は？
生成されたマシンコードが言語仕様に従っていることを確認する方法。
オープンソースプロジェクト（Cでコンパイラを作成している場合はCで）を選択して、「コンパイラ」を介してコンパイルするのは理にかなっていますか。その場合も、コンパイラが期待どおりに動作しているとどのように判断しますか。
「言語準拠」コンパイラが満たさなければならない、言語標準委員会によって提供された正式なテストケース（文献）はありますか？
compilerによってコンパイルされたプログラムの問題がコンパイラのバグであり、プログラムのバグではないことを確実に「与える」ものは何ですか。
-主流のコンパイラが混乱してコードを間違ってコンパイルする例はありますか？
任意の文献へのリンクをいただければ幸いです。
そこにはいくつかのコンパイラテストスイートがあります。 Cコンパイラ用の Plum Hall テストスイートを使用して運が良かったです。これは、言語標準に対してテストするために特別に作成されたCコードの大規模なセットで構成されています。コンパイラが言語の構文とセマンティクスを処理できることを確認します。
実際の言語に適したテストスイートは、作成と保守に費用がかかります。 ANSI Cの業界標準である プラムホールテストスイート が非常に高価であるのには理由があります。
George Neculaの 翻訳検証 は素晴らしいアイデアですが、実装にはかなりの費用がかかります。
安価で簡単なことの1つは、これです。一連の回帰テストを維持し、コンパイラのバグを修正するたびに、適切なテストを回帰スイートに入れます。コンパイラを使用すると、同じバグを何度も何度も再導入し続けることがいかに簡単であるかは信じられないほどです。回帰スイートへの統制のとれた追加はそれを防ぎ、それほど費用はかかりません。
一般的な方法は、コンパイラの1つの側面をそれぞれ示す小さなプログラムの大規模なセットを作成することです。これらには、コンパイルするプログラムとコンパイルしないプログラムの両方が含まれます。一般に、バックエンドから出てくるASMはチェックされませんが、プログラムが実行され、出力がチェックされます。テストケースにバグがないことを確認する方法については、それぞれ5〜10行のように小さくします。
これらのテストスイートは、数百から数千のテストのように非常に大きくなる可能性があり（例： Dプログラミング言語の古いテストスイート ）、通常、これまでに報告されたすべてのバグに対して1つ以上のテストケースが含まれます。 。
大きなオープンソースプロジェクトをコンパイルするというアイデアの場合：
それ自体にテストスイートがあるプロジェクトを取ることができます。次に、プロジェクトとそのテストスイートをコンパイルし、テストに合格するかどうかを確認します。これらの結果を検証するには、プロジェクトとテストスイートを他のコンパイラでコンパイルし、テストを再実行します。
Eiffelコンパイラはオープンソースであり、テストケースと内部設計契約の広範なライブラリがあります。
Cのこれに関連する以前の質問 がありましたが、それは注意深く書かれたコンパイラテストスイートに帰着します。
コンパイラーがコードを間違えるときについては、私のプロとしてのキャリアの中で、それを何度もヒットしました。ありがとう。時間の経過とともに発生することはますます少なくなっていますが、 CLIを対象とするMS C++コンパイラにバグが見つかりました 今週。
GCCには非常に大きなテストスイートがあります（ https://gcc.gnu.org/onlinedocs/gccint/Testsuites.html#Testsuites ）。 SCMで利用できます： https://github.com/gcc-mirror/gcc/tree/master/gcc/testsuite