Compiler correctness

From HandWiki
Revision as of 16:53, 8 February 2024 by Corlink (talk | contribs) (correction)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Short description: Branch of computer science

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.[citation needed] 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 compiled 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]

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" (in en). Journal of Automated Reasoning 43 (4): 363–446. doi:10.1007/s10817-009-9155-4. ISSN 0168-7433. 
  4. ↑ "CompCert - The CompCert C compiler". http://compcert.inria.fr/compcert-C.html. 
  5. ↑ "CakeML: A Verified Implementation of ML". https://cakeml.org/. 
  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. https://archive.org/details/retargetableccom00fras. , pp. 531–3.
  11. ↑ Mark W. Bailey; Jack W. Davidson (2003). "Automatic Detection and Diagnosis of Faults in Generated Code for Procedure Calls". IEEE Transactions on Software Engineering 29 (11): 1031–1042. doi:10.1109/tse.2003.1245304. http://big-oh.cs.hamilton.edu/~bailey/pubs/techreps/TR-2001-1.pdf. Retrieved 2009-03-24. , p. 1040.
  12. ↑ E.g., Christian Lindig (2005). "Random testing of C calling conventions". ACM. ISBN 1-59593-050-7. http://quest-tester.googlecode.com/svn/trunk/doc/lindig-aadebug-2005.pdf. Retrieved 2009-03-24. , and Eric Eide; John Regehr (2008). "Volatiles are miscompiled, and what to do about it". ACM. ISBN 978-1-60558-468-3. http://www.cs.utah.edu/~regehr/papers/emsoft08-preprint.pdf. Retrieved 2009-03-24. 
  13. ↑ Flash Sheridan (2007). "Practical Testing of a C99 Compiler Using Output Comparison". Software: Practice and Experience 37 (14): 1475–1488. doi:10.1002/spe.812. http://pobox.com/~flash/Practical_Testing_of_C99.pdf. Retrieved 2009-03-24.  Bibliography at "Compiler Testing Bibliography". http://pobox.com/~flash/compiler_testing_bibliography.html. .
  14. ↑ "Source of Fortran validation suite". http://www.itl.nist.gov/div897/ctg/fortran_form.htm. 
  15. ↑ "Source of Cobol validation suite". http://www.itl.nist.gov/div897/ctg/cobol_form.htm. 
  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. 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. 



Retrieved from "https://handwiki.org/wiki/index.php?title=Compiler_correctness&oldid=3429764"