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

像所有软件一样的编译器也容易出错,逻辑错误.

如何验证编译器生成的输出.通常,我的问题是(是)

如何验证生成的机器代码是否正确？

如何确保生成的机器代码符合语言规范.

选择一个开源项目(在C中,如果还在C中编写编译器)只是通过"编译器"编译它是否有意义.在这种情况下,如何判断编译器的行为是否符合预期.

是否有语言标准委员会提供的"语言符合"编译器必须满足的正式测试用例(文献)？

什么是"赠送",编译器编译的程序中的问题是编译器错误而不是程序错误.

- 主流编译器混淆并编译代码错误的任何例子？

任何文献的链接将不胜感激.

用于实际语言的良好测试套件的创建和维护成本很高.还有一个原因是在梅花厅的测试套件,这是ANSI C行业标准,是如此血腥的昂贵.

George Necula的翻译验证是一个绝妙的想法,但实施起来也相当昂贵.

这是一件便宜又简单的事情:维护一套回归测试,每次修复编译器中的错误时,都要在回归套件中加入合适的测试.有了编译器,令人难以置信的是,一遍又一遍地重新引入相同的bug是多么容易.对您的回归套件进行有纪律的补充可以防止这种情况发生,并且它们不会花费太多.

那里有几个编译器测试套件.我们运用Plum Hall测试套件来运行C编译器.它由一组专门编写的C代码组成,用于测试语言标准.它验证编译器可以处理语言语法和语义.

通常的做法是创建一大组小程序,每个程序都演示编译器的一个方面.这些将包括编译的程序和不应编译的程序.一般情况下,不会检查后端出现的ASM,而是运行程序并检查输出.至于如何确保测试用例中没有错误:将它们缩小,如每个5-10行.

这些测试套件可能非常大,如数百到数千个测试(例如:D编程语言的过时测试套件),并且通常包括针对所报告的每个错误的一个或多个测试用例.