,
assembler and
linker. s. All
program trees are converted to a common abstract representation at the "middle end", allowing
code optimization and
binary code generation facilities to be shared by all languages. GCC's external interface follows
Unix conventions. Users invoke a language-specific driver program (gcc for C, g++ for C++, etc.), which interprets
command arguments, calls the actual compiler, runs the
assembler on the output, and then optionally runs the
linker to produce a complete
executable binary. Each of the language compilers is a separate program that reads source code and outputs
machine code. All have a common internal structure. A per-language front end
parses the source code in that language and produces an
abstract syntax tree ("tree" for short). These are, if necessary, converted to the middle end's input representation, called
GENERIC form; the middle end then gradually transforms the program towards its final form.
Compiler optimizations and
static code analysis techniques (such as FORTIFY_SOURCE, a compiler directive that attempts to discover some
buffer overflows) are applied to the code. These work on multiple representations, mostly the architecture-independent GIMPLE representation and the architecture-dependent
RTL representation. Finally,
machine code is produced using architecture-specific
pattern matching originally based on an algorithm of Jack Davidson and Chris Fraser. GCC was written primarily in
C except for parts of the
Ada front end. The distribution includes the standard libraries for Ada and
C++ whose code is mostly written in those languages. On some platforms, the distribution also includes a low-level runtime library,
libgcc, written in a combination of machine-independent C and processor-specific
machine code, designed primarily to handle arithmetic operations that the target processor cannot perform directly. GCC uses many additional tools in its build, many of which are installed by default by many Unix and Linux distributions (but which, normally, aren't present in Windows installations), including
Perl,
Flex,
Bison, and other common tools. In addition, it currently requires three additional libraries to be present in order to build:
GMP,
MPC, and
MPFR. In May 2010, the GCC steering committee decided to allow use of a
C++ compiler to compile GCC. The compiler was intended to be written mostly in C plus a subset of features from C++. In particular, this was decided so that GCC's developers could use the
destructors and
generics features of C++. In August 2012, the GCC steering committee announced that GCC now uses C++ as its implementation language. This means that to build GCC from sources, a C++ compiler is required that understands
ISO/IEC C++03 standard. On May 18, 2020, GCC moved away from
ISO/IEC C++03 standard to
ISO/IEC C++11 standard (i.e. needed to compile, bootstrap, the compiler itself; by default it however compiles later versions of C++).
Front ends ,
lexical analysis,
syntactic analysis (parsing) and semantic analysis. The goals of compiler front ends are to either accept or reject candidate programs according to the language grammar and semantics, identify errors and handle valid program representations to later compiler stages. This example shows the lexer and parser steps performed for a simple program written in
C. Each
front end uses a parser to produce the
abstract syntax tree of a given
source file. Due to the syntax tree abstraction, source files of any of the different supported languages can be processed by the same
back end. GCC started out using
LALR parsers generated with
Bison, but gradually switched to hand-written
recursive-descent parsers for C++ in 2004, and for C and Objective-C in 2006. As of 2021 all front ends use hand-written recursive-descent parsers. Until GCC 4.0, the tree representation of the program was not fully independent of the processor being targeted. The meaning of a tree was somewhat different for different language front ends, and front ends could provide their own tree codes. This was simplified with the introduction of GENERIC and GIMPLE, two new forms of language-independent trees that were introduced with the advent of GCC 4.0. GENERIC is more complex, based on the GCC 3.x Java front end's intermediate representation. GIMPLE is a simplified GENERIC, in which various constructs are
lowered to multiple GIMPLE instructions. The
C,
C++, and
Java front ends produce GENERIC directly in the front end. Other front ends instead have different intermediate representations after parsing and convert these to GENERIC. In either case, the so-called "gimplifier" then converts this more complex form into the simpler
SSA-based GIMPLE form that is the common language for a large number of language- and architecture-independent global (function scope) optimizations.
GENERIC and GIMPLE GENERIC is an
intermediate representation language used as a "middle end" while compiling source code into
executable binaries. A subset, called
GIMPLE, is targeted by all the front ends of GCC. The middle stage of GCC does all of the code analysis and
optimization, working independently of both the compiled language and the target architecture, starting from the GENERIC representation and expanding it to
register transfer language (RTL). The GENERIC representation contains only the subset of the imperative
programming constructs optimized by the middle end. In transforming the source code to GIMPLE, complex
expressions are split into a
three-address code using
temporary variables. This representation was inspired by the SIMPLE representation proposed in the McCAT compiler by Laurie J. Hendren for simplifying the analysis and
optimization of
imperative programs.
Optimization Optimization can occur during any phase of compilation; however, the bulk of optimizations are performed after the syntax and
semantic analysis of the front end and before the
code generation of the back end; thus a common, though somewhat self-contradictory, name for this part of the compiler is the "middle end." The exact set of GCC optimizations varies from release to release as it develops, but includes the standard algorithms, such as
loop optimization,
jump threading,
common subexpression elimination,
instruction scheduling, and so forth. The
RTL optimizations are of less importance with the addition of global SSA-based optimizations on
GIMPLE trees, as RTL optimizations have a much more limited scope, and have less high-level information. Some of these optimizations performed at this level include
dead-code elimination,
partial-redundancy elimination,
global value numbering,
sparse conditional constant propagation, and
scalar replacement of aggregates. Array dependence based optimizations such as
automatic vectorization and
automatic parallelization are also performed.
Profile-guided optimization is also possible.
C++ Standard Library (libstdc++) The GCC project includes an implementation of the
C++ Standard Library called libstdc++, licensed under the GPLv3 License with an exception to link non-GPL-compatible applications when sources are built with GCC. Since GCC Version 3, the C++ ABI is based on the ABI published by Intel for the Itanium C++ ABI.
Other features Some features of GCC include: ; Link-time optimization :
Link-time optimization optimizes across object file boundaries to directly improve the linked binary. Link-time optimization relies on an intermediate file containing the serialization of some
Gimple representation included in the object file. The file is generated alongside the object file during source compilation. Each source compilation generates a separate object file and link-time helper file. When the object files are linked, the compiler is executed again and uses the helper files to optimize code across the separately compiled object files. ; Plugins :
Plugins extend the GCC compiler directly. Plugins allow a stock compiler to be tailored to specific needs by external code loaded as plugins. For example, plugins can add, replace, or even remove middle-end passes operating on
Gimple representations. Several GCC plugins have already been published, notably: :* The Python plugin, which links against libpython, and allows one to invoke arbitrary Python scripts from inside the compiler. The aim is to allow GCC plugins to be written in Python. :* The MELT plugin provides a high-level
Lisp-like language to extend GCC. : The support of plugins was once a contentious issue in 2007. ; C++
transactional memory : The C++ language has an active proposal for transactional memory. It can be enabled in GCC 6 and newer when compiling with -fgnu-tm. ; Unicode identifiers : Although the C++ language requires support for non-ASCII
Unicode characters in
identifiers, the feature has only been supported since GCC 10. As with the existing handling of string literals, the source file is assumed to be encoded in
UTF-8. The feature is optional in C, but has been made available too since this change. ; C extensions : GNU C extends the C programming language with several non-standard-features, including
nested functions. == Architectures ==