Compiler test cases or how to test a compiler [closed]

Question

Compilers like all software, would also be prone to bugs, logical errors.

How does one validate the output generated by the compiler. Typically, my question is(are)

• How to validate that the machine code generated is correct?

• How to ensure that the machine code generated is according to the language specification.

• Does it make sense to just pick an open source project (in C if one is also writing a compiler in C) to just compile it through the "compiler". In that case also, how do judge that the compiler is behaving as expected.

• Are there any formal test cases (literature) provided by the language standards committee that a "language complying" compiler has to satisfy?

• What are the sure "give aways" that the problem in a program compiled by a compiler is a compiler bug and not a program bug.

  - Any examples where mainstream compilers get confused and compile the code wrong?

Links to any literature would be appreciated.

Answer 1

Good test suites for real languages are expensive to create and maintain. There's a reason that the Plum Hall test suite, which is industry standard for ANSI C, is so bloody expensive.

George Necula's translation validation is a brilliant idea but also quite expensive to implement.

The one thing that's cheap and easy is this: maintain a suite of regression tests, and every time you fix a bug in your compiler, put a suitable test into your regression suites. With compilers, it's unbelievable how easy it is to keep reintroducing the same bug over and over. Disciplined additions to your regression suite will prevent that, and they don't cost much.