How to see lowered c++ - c++

Question

I'm trying to improve my understanding of how C++ actually works. Is there a way to see how the compiler lowers my code into something simpler? For example, I'd like to see how all the copy constructors are called, how overloaded function calls have been resolved, all the template expansion and instantiation complete, etc. Right now I'm learning about how C++ compilers interpret my code through experimentation, but it'd be nice just to see a lowered form of my code, even if it is very ugly. I'm looking for something analogous to g++ -E, which shows the result of the preprocessor, but for C++.
Edit: I should have added that I'm not looking for a disassembler. There's a huge gulf between C++ source code and assembled code. Inside this gulf are complicated things like template meta-programming and all sorts of implicit calls to operator methods (assignments! casts! constructors! ...) as well as heavily overloaded functions with very complicated resolution rules, etc. I'm looking for tools to help me understand how my code is interpreted by the C++ compiler. Right now, the only thing I can do is try little experiments and piecemeal put together an understanding of what the compiler is doing. I'd like to see more detail on what's going on. It would help greatly, for example, in debugging template metaprogramming problems.

Answer 1

At the moment, I think that your best bet is Clang (you can try some simple code on the Try Out LLVM page).
When compiling C, C++ or Obj-C with Clang/LLVM, you may ask the compiler to emit the Intermediate Representation (LLVM IR) instead of going the full way to assembly/binary form.
The LLVM IR is a full specified language used internally by the compiler:
CLang lowers the C++ code to LLVM IR
LLVM optimizes the IR
A LLVM Backend (for example x86) produces the assembly from the IR
The IR is the last step before machine-specific code, so you don't have to learn specific assembly directives and you still get a very low-level representation of what's really going on under the hood.
You can get the IR both before and after optimizations, the latter being more representative of real code, but further away from what you origially wrote.
Example with a C program:
#include <stdio.h>
#include <stdlib.h>
static int factorial(int X) {
if (X == 0) return 1;
return X*factorial(X-1);
}
int main(int argc, char **argv) {
printf("%d\n", factorial(atoi(argv[1])));
}
Corresponding IR:
; ModuleID = '/tmp/webcompile/_10956_0.bc'
target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64"
target triple = "x86_64-unknown-linux-gnu"
#.str = private unnamed_addr constant [4 x i8] c"%d\0A\00"
define i32 #main(i32 %argc, i8** nocapture %argv) nounwind {
; <label>:0
%1 = getelementptr inbounds i8** %argv, i64 1
%2 = load i8** %1, align 8, !tbaa !0
%3 = tail call i64 #strtol(i8* nocapture %2, i8** null, i32 10) nounwind
%4 = trunc i64 %3 to i32
%5 = icmp eq i32 %4, 0
br i1 %5, label %factorial.exit, label %tailrecurse.i
tailrecurse.i: ; preds = %tailrecurse.i, %0
%indvar.i = phi i32 [ %indvar.next.i, %tailrecurse.i ], [ 0, %0 ]
%accumulator.tr1.i = phi i32 [ %6, %tailrecurse.i ], [ 1, %0 ]
%X.tr2.i = sub i32 %4, %indvar.i
%6 = mul nsw i32 %X.tr2.i, %accumulator.tr1.i
%indvar.next.i = add i32 %indvar.i, 1
%exitcond = icmp eq i32 %indvar.next.i, %4
br i1 %exitcond, label %factorial.exit, label %tailrecurse.i
factorial.exit: ; preds = %tailrecurse.i, %0
%accumulator.tr.lcssa.i = phi i32 [ 1, %0 ], [ %6, %tailrecurse.i ]
%7 = tail call i32 (i8*, ...)* #printf(i8* getelementptr inbounds ([4 x i8]* #.str, i64 0, i64 0), i32 %accumulator.tr.lcssa.i) nounwind
ret i32 0
}
declare i32 #printf(i8* nocapture, ...) nounwind
declare i64 #strtol(i8*, i8** nocapture, i32) nounwind
!0 = metadata !{metadata !"any pointer", metadata !1}
!1 = metadata !{metadata !"omnipotent char", metadata !2}
!2 = metadata !{metadata !"Simple C/C++ TBAA", null}
I personally find it relatively readable (it tries to preserve the variable names, somewhat, the function names are still there) once you get past the original discovery of the language.

Answer 2

The first C++ compiler was cfront, which was, as the name implies, a front-end for C; in theory, cfront's output is what you'd like to see. But cfront hasn't been available for many years; it was a commercial product, and the source is not available.
Modern C++ compilers don't use a C intermediary; if there's an intermediary at all, it's an internal compiler representation, not something you'd enjoy looking at! The -S option to g++ will spit out *.s files: assembly code, which includes just enough symbols that you could, in theory, follow it.

Answer 3

The very first (circa 1989) C++ compilers compiled C++ into C. But that's not been true for a very long time, very long time meaning I know of no widely available compiler than did things that way for the last 15 years. The best you are going to do is look at the assembly language output, which requires some amount of knowledge and analysis to understand.
The assembly level output of a C++ compiler is generally not called 'lowered'. It's called 'compiled'. I can understand how you might come by that terminology. Assembly is a lower-level language. But that's not the terminology everybody else uses and it will confuse people if you use it.
Most popular C++ compilers have an option somewhere that allows you to see the assembly level output. The Open Source g++ compiler has the -S option that does this. It will create a file that ends in .s. You can look through this file to see the resulting assembly language.
In order for the assembly language to more directly correspond to the C++ code I would recommend compiling with the -O0 option to turn off optimization. The results of optimization can result in assembly code that bears little or no obvious resemblance to the original C++ code. Though viewing that code can help you understand what the optimizer is doing.
Another problem is that the symbols (the names for functions and classes and things) in the assembly output will be what is called 'mangled'. This is because most assembly languages do not allow :: as part of the symbol name, and because C++ can also have the same names for different kinds of symbols. The compiler transforms the names of things in your C++ code into different names that will be valid in the assembly code.
For g++ this mangling can be undone with the c++filt program.
c++filt <myprogram.s >myprogram_demangled.s
This will help make the assembly file more readable.

Answer 4

First step you can preprocess it (It is the first step that the compiler actually do before compiling)
with cpp or g++ -E
Second step is to parse and translate it
with g++ -S
this link about the compilation process might interest you

Answer 5

You can run g++ (or any gcc front-end) with one or more of the -fdump-tree- flags (complete list), which will dump intermediate representations of the code from different compiler passes in an output format that looks similar to C. However, this output is usually quite hard to read, with lots of compiler-generated temporary variables and other artifacts of compilation. It's mainly intended for debugging the compiler itself, but for simple examples you might be able to infer what gcc is doing with your C++ code by studying the intermediate representation.

Answer 6

The Comeau C++ compiler generates C code. But you'll have to pay for it.

Answer 7

Instead of doing experimentation, you can use a debugger and see the flow of your code. This way you can easily see which constructors or overloaded functions actual mapping is happening.