编译器测试用例或如何测试编译器

有几个编译器测试套件。我们使用 Plum Hall C编译器的测试套件。它由一大组专门编写的C代码组成,用于根据语言标准进行测试。它验证了编译器可以处理语言语法和语义。

真正语言的良好测试套件的创建和维护成本很高。有一个原因 the Plum Hall test suite 这是ANSI C的行业标准,非常昂贵。

George Necula translation validation 这是一个很好的想法,但实施起来也很昂贵。

一件既便宜又简单的事情是:维护一套回归测试,以及 每次在编译器中修复bug时,都要在回归套件中进行适当的测试。 .有了编译器,反复引入同一个bug是多么的容易,令人难以置信。对回归套件进行严格的添加可以防止这种情况发生,而且成本也不高。

一般的做法是创建一个大的小程序集,每个小程序都演示编译器的一个方面。这将包括编译的程序和不应该编译的程序。一般来说,从后端出来的ASM不会被检查,而是运行程序并检查其输出。至于如何确保测试用例中没有错误:使它们变小,就像在5-10行中一样。

这些测试套件可以非常大,例如在数百到数千个测试中(例如: an out of date test suite for the D programming language )并且通常包括一个或多个曾经报告过的每个错误的测试案例。

对于编译一个大型开源项目的想法:

您可以选择一个本身具有测试套件的项目。然后编译项目及其测试套件,看看测试是否通过。要验证这些结果,可以使用其他编译器编译项目和测试套件,然后再次运行测试。

Eiffel编译器是开放源码的,拥有大量的测试用例库和内部设计合同。

http://dev.eiffel.com

有一个 earlier question related to this for C 但归根结底是一个精心编写的编译器测试套件。

至于当编译器把代码搞错的时候,我在职业生涯中经常碰到这种情况,谢谢。随着时间的推移,事情发生的越来越少,但是 I found a bug in MS C++ compilers targeting CLI 本周。

GCC有一个相当大的测试套件( https://gcc.gnu.org/onlinedocs/gccint/Testsuites.html#Testsuites )它在SCM上提供: https://github.com/gcc-mirror/gcc/tree/master/gcc/testsuite