Ggc Handbook: Fill & Download for Free

Don’t confuse two things: a compiler having internally some kind of garbage collection machinery, and a compiler emitting code for your programs using some garbage collection.GCC has indeed some very basic (and IMNSHO quite poor) internal garbage collection machinery. It is documented in GNU Compiler Collection (GCC) Internals: Type Information section.Remember that for industrial strength C & C++ compilers (like both GCC & Clang), most of the compiler’s work is related to optimizations. C compilers not doing any strong optimizations exist (look into tinycc or nwcc as examples) and they can be quite simple programs of a few dozen thousands lines of source code (that is not the case for a C++11 compiler: the “parsing” & “template expansion” work of C++ is really difficult, so a tinyc++ is not realistic). It is because they are able to optimize well that both GCC and Clang are multi-million lines of code monsters. But “non-optimizing” compilers like tinycc, or nwcc, or even GCC or Clang started with the -O0 flag, emit very slow code (3x to 10x slower than what GCC or Clang are able to emit with -O3). So you usually ask GCC & Clang to optimize strongly your production code.Optimization is always done by transforming internal compiler representations (think even of basic optimization techniques like inlining, constant folding, loop unrolling); and most (but not all) optimization techniques do not depend upon the target language (or the source one).The GCC optimizations work happens a lot in its middle-end. My GCC MELT documentation webpage has a lot of references and slides explaining that. The Clang/LLVM optimizations happens a lot in the LLVM part.For GCC, its middle-end is organized into more than two hundred “optimization passes” (many of them doing some very specific things). And GCC contains a poor garbage collector which is only triggered between optimization passes (and generally not inside them). That poor GC (called GGC) is then able to ignore the local variables on the call stack (because, in the GCC pass manager, the call stack is almost empty). It works slightly faster than Boehm’s GC (and that is why Boehm’s GC has been tried in GCC but not adopted). Sometimes it is able to free memory, and its mark-&-sweep GC approach is able to deal with cyclic data (which is very common inside compilers).For Clang (which I don’t know much, so I could be very wrong) traditional C++ programming techniques are used: reference counting and weak pointers (and The Garbage Collection Handbook is explaining why that might be a poor approach for cyclic data). I suspect (but I don’t know) that for some kind of input source files, Clang might release memory only near the end of the compilation.All this is very different of the ability to e.g. compile your C or C++ code which would use garbage collection techniques. For that kind of thing, consider using Boehm’s garbage collector for C and C++ or Memory Pool System (or write your own GC). See also C++ standard library and Boehm garbage collector. Notice that latest C++ standards define some limited features related to GC like e.g. std::declare_reachable but there is no current C++ implementations providing these optional features in a non-trivial way (in other words, the C++ features related to GC are practically useless in your code).