2
$\begingroup$

Suppose you need a c compiler. It would be preferable to write that compiler in a c-like language, given the complexity of a compiler of that degree. At best, the c compiler would be written in c, but that would require a c compiler to begin with. If a mistake is made in the making of one of the early iterations of compilers, it could propagate. How do compilers make sure that this doesn't happen? Obviously, no code is flawless, not even the processor is, but if you haven't somehow measured the stability, you don't even know if your compiler is stable. What assumptions are made and how is it justified? I would imagine it would be architecture-dependent too.

Edit: By stability, I mean that the code runs as intended.

Improve this question
$\endgroup$

4 Answers 4

Reset to default
1
$\begingroup$

The word that compiler writers use for this is "conformance". A compiler that correctly implements the language specification is conformant. There are companies who, as part of their business, sell conformance tests for various standards, including programming languages.

It's rare for errors to propagate through compiler generations by accident (although it has happened on purpose).

Improve this answer
$\endgroup$
4
$\begingroup$

It happens that compilers contain subtle errors. No blatant errors, because blatant errors would be detected and fixed.

A compiler that is itself compiled by a compiler with subtle errors will tend to have blatant errors. They will be easy to detect because they are so blatant. They will be hard to fix because these blatant errors will be produced by perfectly fine source code, so whoever wants to fix it will have a hard time finding the real problem.

The solution will be to make a compiler of sufficient quality that bugs are very rare, and extremely rare within the compiler. We also expect compiler bugs to affect very complicated code more, so the compiler writer should write code that is simple and follows common coding patterns.

Improve this answer
$\endgroup$
3
$\begingroup$

One answer is testing, testing, testing. E.g. GCC comes with an ever growing set of tests that are checked each time the compiler is built. Many compilers are required to pass the so-called triple test: Compile code for your compiler C using compiler A, giving C_1; compile C with C_1 giving C_2, compile C with C_2 giving C_3. Now C_2 and C_3 were compiled with C, and should be equal. If not, something fishy is going on.

Take a look at Regher's "Embedded in Academia" blog, he is one of the people working around the LLVM compiler tools, and regularly touches on the tools and techniques used to make the compiler better (or automate parts of it's building).

Improve this answer
$\endgroup$
1
$\begingroup$

In Computer Science this is covered by the use of T-Diagrams (or Tombstone Diagrams).

Example T Diagram

This explains how compilers are created for new languages and also how compilers can be ported from one platform to another. They also explain how flawed compilers can be fixed, but changing a compiler to fix a bug is much like changing a compiler to add a feature.

There are several sets of university class notes on this issue that Google reveals, which you could consult, but there is also a good question here (not a duplicate, but very useful):

Cross Compiler's T diagram

Improve this answer
$\endgroup$
1
  • $\begingroup$ Are these ever used in practice? And how would they help you ensure the correctness of a compiler? $\endgroup$
    – user20574
    Commented Jul 23, 2020 at 13:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.