Compiler correctness

In computing, compiler correctness is the branch of computer science that deals with trying to show that a compiler behaves according to its language specification. Techniques include developing the compiler using formal methods and using rigorous testing (often called compiler validation) on an existing compiler.

Formal verification

Two main formal verification approaches for establishing correctness of compilation are proving correctness of the compiler for all inputs and proving correctness of a compilation of a particular program (translation validation).

Compiler correctness for all input programs

Compiler validation with formal methods involves a long chain of formal, deductive logic.[1] However, since the tool to find the proof (theorem prover) is implemented in software and is complex, there is a high probability it will contain errors. One approach has been to use a tool that verifies the proof (a proof checker) which because it is much simpler than a proof-finder is less likely to contain errors.

A prominent example of this approach is CompCert, which is a formally verified optimizing compiler of a large subset of C99.[2][3][4]

Another verified compiler was developed in CakeML project [5], which establishes correctness of a substantial subset of Standard ML programming language using the HOL (proof assistant).

Another approach to obtain a formally correct compiler is to use semantics-directed compiler generation.[6]

Translation validation: compiler correctness on a given program

In contrast to attempting to prove that a compiler is correct for all valid input programs translation validation [7] aims to automatically establish that a given input program is compiled correctly. Proving correct compilation of a given program is potentially easier than proving a compiler correct for all programs, but still requires symbolic reasoning, because a fixed program may still work on arbitrarily large inputs and run for arbitrarily long amount of time. Translation validation can reuse an existing compiler implementation by generating, for a given compilation, a proof that the compilation was correct. Translation validation can be used even with a compiler that sometimes generates incorrect code, as long as this incorrect does not manifest itself for a given program. Depending on the input program the translation validation can fail (because the generated code is wrong or the translation validation technique is too weak to show correctness). However, if translation validation succeeds, then the compiler program is guaranteed to be correct for all inputs.

Testing

Testing represents a significant portion of the effort in shipping a compiler, but receives comparatively little coverage in the standard literature. The 1986 edition of Aho, Sethi, & Ullman has a single-page section on compiler testing, with no named examples.[8] The 2006 edition omits the section on testing, but does emphasize its importance: “Optimizing compilers are so difficult to get right that we dare say that no optimizing compiler is completely error-free! Thus, the most important objective in writing a compiler is that it is correct.”[9] Fraser & Hanson 1995 has a brief section on regression testing; source code is available.[10] Bailey & Davidson 2003 cover testing of procedure calls[11] A number of articles confirm that many released compilers have significant code-correctness bugs.[12] Sheridan 2007 is probably the most recent journal article on general compiler testing.[13] For most purposes, the largest body of information available on compiler testing are the Fortran[14] and Cobol[15] validation suites.

Further common techniques when testing compilers are fuzzing[16] (which generates random programs to try to find bugs in a compiler) and test case reduction (which tries to minimize a found test case to make it easier to understand).[17]

gollark: You can't even make macron.
gollark: Perhaps heavserver could propagate this way.
gollark: Yes, seems good. With slowmode.
gollark: <50KB is… probably fine.
gollark: If you want any graphs, just *ask* me to harvest arbitrary quantities of user data!

See also

References
  1. De Millo, R. A.; Lipton, R. J.; Perlis, A. J. (1979). "Social processes and proofs of theorems and programs". Communications of the ACM. 22 (5): 271–280. doi:10.1145/359104.359106.
  2. Leroy, X. (2006). "Formal Certification of a Compiler Back-End or: Programming a Compiler with a Proof Assistant". ACM SIGPLAN Notices. 41: 42–54. doi:10.1145/1111320.1111042.
  3. Leroy, Xavier (2009-12-01). "A Formally Verified Compiler Back-end". Journal of Automated Reasoning. 43 (4): 363–446. arXiv:0902.2137. doi:10.1007/s10817-009-9155-4. ISSN 0168-7433.
  4. "CompCert - The CompCert C compiler". compcert.inria.fr. Retrieved 2017-07-21.
  5. "CakeML: A Verified Implementation of ML".
  6. Stephan Diehl, Natural Semantics Directed Generation of Compilers and Abstract Machines,Formal Aspects of Computing, Vol. 12 (2), Springer Verlag, 2000. doi:10.1007/PL00003929
  7. Pnueli, Amir; Siegel, Michael; Singerman, Eli. Translation Validation. Tools and Algorithms for Construction and Analysis of Systems, 4th International Conference, TACAS '98.
  8. Compilers: Principles, Techniques and Tools, infra 1986, p. 731.
  9. ibid, 2006, p. 16.
  10. Christopher Fraser; David Hanson (1995). A Retargetable C compiler: Design and Implementation. Benjamin/Cummings Publishing. ISBN 978-0-8053-1670-4., pp. 531–3.
  11. Mark W. Bailey; Jack W. Davidson (2003). "Automatic Detection and Diagnosis of Faults in Generated Code for Procedure Calls" (PDF). IEEE Transactions on Software Engineering. 29 (11): 1031–1042. CiteSeerX 10.1.1.15.4829. doi:10.1109/tse.2003.1245304. Archived from the original (PDF) on 2003-04-28. Retrieved 2009-03-24., p. 1040.
  12. E.g., Christian Lindig (2005). "Random testing of C calling conventions" (PDF). Proceedings of the Sixth International Workshop on Automated Debugging. ACM. ISBN 1-59593-050-7. Archived from the original (PDF) on 2011-07-11. Retrieved 2009-03-24., and Eric Eide; John Regehr (2008). "Volatiles are miscompiled, and what to do about it" (PDF). Proceedings of the 7th ACM international conference on Embedded software. ACM. ISBN 978-1-60558-468-3. Retrieved 2009-03-24.
  13. Flash Sheridan (2007). "Practical Testing of a C99 Compiler Using Output Comparison" (PDF). Software: Practice and Experience. 37 (14): 1475–1488. doi:10.1002/spe.812. Retrieved 2009-03-24. Bibliography at http://pobox.com/~flash/compiler_testing_bibliography.html. Retrieved 2009-03-13. Missing or empty |title= (help).
  14. "Source of Fortran validation suite". Retrieved 2011-09-01.
  15. "Source of Cobol validation suite". Retrieved 2011-09-01.
  16. Chen, Yang; Groce, Alex; Zhang, Chaoqiang; Wong, Weng-Keen; Fern, Xiaoli; Eide, Eric; Regehr, John (2013). Taming Compiler Fuzzers. Proceedings of the 34th ACM SIGPLAN Conference on Programming Language Design and Implementation. PLDI '13. New York, NY, USA: ACM. pp. 197–208. CiteSeerX 10.1.1.308.5541. doi:10.1145/2491956.2462173. ISBN 9781450320146.
  17. Regehr, John; Chen, Yang; Cuoq, Pascal; Eide, Eric; Ellison, Chucky; Yang, Xuejun (2012). Test-case Reduction for C Compiler Bugs. Proceedings of the 33rd ACM SIGPLAN Conference on Programming Language Design and Implementation. PLDI '12. New York, NY, USA: ACM. pp. 335–346. doi:10.1145/2254064.2254104. ISBN 9781450312059.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.