We show that the weak memory model introduced by the 2011 C and C++ standards does not permit many common source-tosource program transformations (such as expression linearisation and "roach motel" reorderings) that modern compilers perform and that are deemed to be correct. As such it cannot be used to define the semantics of intermediate languages of compilers, as, for instance, LLVM aimed to. We consider a number of possible local fixes, some strengthening and some weakening the model. We evaluate the proposed fixes by determining which program transformations are valid with respect to each of the patched models. We provide formal Coq proofs of their correctness or counterexamples as appropriate.
No abstract
Compilers sometimes generate correct sequential code but break the concurrency memory model of the programming language: these subtle compiler bugs are observable only when the miscompiled functions interact with concurrent contexts, making them particularly hard to detect. In this work we design a strategy to reduce the hard problem of hunting concurrency compiler bugs to differential testing of sequential code and build a tool that puts this strategy to work. Our first contribution is a theory of sound optimisations in the C11/C++11 memory model, covering most of the optimisations we have observed in real compilers and validating the claim that common compiler optimisations are sound in the C11/C++11 memory model. Our second contribution is to show how, building on this theory, concurrency compiler bugs can be identified by comparing the memory trace of compiled code against a reference memory trace for the source code. Our tool identified several mistaken write introductions and other unexpected behaviours in the latest release of the gcc compiler. Random testing for concurrency compiler bugsThe C and C++ languages were originally designed without concurrency support: threads were available via external libraries, yielding unexpected behaviours and misunderstandings between programmers and compiler writers.1 The recent revision of the C and C++ standards [6] does provide a precise semantics for threads (formalised in [4]): well-synchronised programs must exhibit only sequentially consistent behaviours, racy programs can have any behaviour, and an escape mechanism with a complex semantics, called low-level atomics, enables programmers to write highperformance but portable concurrent code. The resulting model 1 as an example, this recent discussion illustrates the mismatch and tensions between what Linux kernel developers expect from compilers and what gcc does: http://gcc.gnu.org/ml/gcc/2012-02/msg00005.html.Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. is intricate and the interactions with compiler optimisations are not entirely understood. Today's C and C++ compilers, whose optimisers were initially developed in absence of any well-defined memory model, are being extended to support the new concurrency standard. This is a hard task. Past research showed that all production-quality C compilers used to generate incorrect code for accessing volatile variables [10]: the memory model defined by the volatile modifier is trivial compared to the new C11/C++11 model. Correctly supporting the new memory model in today's compilers will be an error-prone enterprise, requiring significant development effort. It is thus vital to investigate techniques to...
International audienceCompilers sometimes generate correct sequential code but break the concurrency memory model of the programming language: these subtle compiler bugs are observable only when the miscompiled functions interact with concurrent contexts, making them particularly hard to detect. In this work we design a strategy to reduce the hard problem of hunting concurrency compiler bugs to differential testing of sequential code and build a tool that puts this strategy to work. Our first contribution is a theory of sound optimisations in the C11/C++11 memory model, covering most of the optimisations we have observed in real compilers and validating the claim that common compiler optimisations are sound in the C11/C++11 memory model. Our second contribution is to show how, building on this theory, concurrency compiler bugs can be identified by comparing the memory trace of compiled code against a reference memory trace for the source code. Our tool identified several mistaken write introductions and other unexpected behaviours in the latest release of the gcc compiler
We show that the weak memory model introduced by the 2011 C and C++ standards does not permit many common source-tosource program transformations (such as expression linearisation and "roach motel" reorderings) that modern compilers perform and that are deemed to be correct. As such it cannot be used to define the semantics of intermediate languages of compilers, as, for instance, LLVM aimed to. We consider a number of possible local fixes, some strengthening and some weakening the model. We evaluate the proposed fixes by determining which program transformations are valid with respect to each of the patched models. We provide formal Coq proofs of their correctness or counterexamples as appropriate.
scite is a Brooklyn-based organization that helps researchers better discover and understand research articles through Smart Citations–citations that display the context of the citation and describe whether the article provides supporting or contrasting evidence. scite is used by students and researchers from around the world and is funded in part by the National Science Foundation and the National Institute on Drug Abuse of the National Institutes of Health.
hi@scite.ai
10624 S. Eastern Ave., Ste. A-614
Henderson, NV 89052, USA
Copyright © 2024 scite LLC. All rights reserved.
Made with 💙 for researchers
Part of the Research Solutions Family.