GCC — GNU Compiler Collection

Ричард Столлман написал первую версию в 1987 году как часть GNU-проекта — свободную альтернативу проприетарным компиляторам Unix того времени, когда даже базовые инструменты разработки часто были платными и закрытыми. Изначально GCC расшифровывался как GNU C Compiler, но по мере добавления фронтендов для других языков (Fortran в 1990-х, затем C++, Objective-C, Ada, Java, Go, D) название сменили на GNU Compiler Collection, сохранив аббревиатуру. Rust получил экспериментальный фронтенд gccrs относительно недавно — попытка дать Rust второй, независимый от LLVM компилятор.Richard Stallman wrote the first version in 1987 as part of the GNU project — a free alternative to the proprietary Unix compilers of the era, when even basic development tools were often paid and closed. GCC originally stood for GNU C Compiler, but as frontends for other languages were added (Fortran in the 1990s, then C++, Objective-C, Ada, Java, Go, D), the name was changed to GNU Compiler Collection, keeping the acronym. Rust recently got an experimental frontend, gccrs — an attempt to give Rust a second compiler independent of LLVM.

Значимый исторический эпизод — форк EGCS (1997): часть сообщества откололась от официального GCC из-за медленного темпа разработки под управлением FSF, EGCS развивался быстрее и в итоге был принят обратно как официальный GCC 2.95 (1999) — редкий пример форка, который «выиграл» и слился обратно с оригиналом.A significant historical episode is the EGCS fork (1997): part of the community split off from official GCC over the slow pace of development under FSF stewardship; EGCS moved faster and was eventually adopted back as official GCC 2.95 (1999) — a rare example of a fork that "won" and merged back into the original.

Команда g++ main.cpp -o main — не один процесс, а координатор (driver), запускающий цепочку отдельных программ. Понимание этой цепочки объясняет, что именно измеряют флаги вроде -### (напечатать команды, не выполняя их) и почему некоторые ошибки указывают на «внутренний» инструмент, а не на сам g++.The command g++ main.cpp -o main isn't a single process — it's a coordinator (the driver) that launches a chain of separate programs. Understanding this chain explains what flags like -### (print the commands without running them) actually show, and why some errors point at an "internal" tool rather than at g++ itself.

g++ -### main.cpp -o main 2>&1 | head -3
// печатает что-то вроде:// prints something like:
// /usr/libexec/gcc/x86_64-linux-gnu/13/cc1plus -quiet main.cpp -o /tmp/ccXXXXXX.s ...
// as /tmp/ccXXXXXX.s -o /tmp/ccYYYYYY.o
// /usr/libexec/gcc/x86_64-linux-gnu/13/collect2 ... /tmp/ccYYYYYY.o -lstdc++ -lc ...

cc1plus транслирует AST в GENERIC (языко-независимое дерево выражений, всё ещё довольно высокоуровневое), затем в GIMPLE — упрощённое трёхадресное представление (каждая инструкция — не более одной операции), над которым работает большинство скалярных и межпроцедурных оптимизаций (см. оптимизации). Финальный шаг — перевод в RTL (Register Transfer Language), уже близкое к машинным инструкциям представление, где работают планировщик команд (instruction scheduling) и распределение регистров (register allocation), специфичные для целевой архитектуры.cc1plus translates the AST into GENERIC (a language-independent expression tree, still fairly high-level), then into GIMPLE — a simplified three-address representation (each instruction is at most one operation), which is what most scalar and interprocedural optimizations operate on (see optimizations). The final step is lowering to RTL (Register Transfer Language), a representation already close to machine instructions, where instruction scheduling and register allocation — both target-architecture-specific — happen.

В отличие от LLVM IR у Clang, GIMPLE/RTL исторически не проектировались как стабильный, документированный публичный API — это одна из ключевых архитектурных причин, почему вокруг GCC не выросла такая же обширная экосистема сторонних инструментов, как вокруг LLVM.Unlike Clang's LLVM IR, GIMPLE/RTL were never historically designed as a stable, documented public API — this is one of the key architectural reasons why GCC never grew the same broad third-party tooling ecosystem that LLVM did.

С версии GCC 4.5 (2010) компилятор можно расширять плагинами — динамическими библиотеками, загружаемыми через -fplugin=path/to/plugin.so, которые подключаются к внутренним callback-точкам (PLUGIN_FINISH_TYPE, PLUGIN_PRE_GENERICIZE и другие) и получают доступ к внутренним структурам данных GCC — GENERIC-дереву, GIMPLE, таблице типов. В отличие от LibTooling у Clang, API плагинов GCC гораздо менее стабилен между версиями (internals меняются без обязательства сохранять обратную совместимость) и требует линковки против внутренних заголовков самого GCC.Since GCC 4.5 (2010), the compiler can be extended with plugins — dynamic libraries loaded via -fplugin=path/to/plugin.so — that hook into internal callback points (PLUGIN_FINISH_TYPE, PLUGIN_PRE_GENERICIZE, and others) and get access to GCC's internal data structures — the GENERIC tree, GIMPLE, the type table. Unlike Clang's LibTooling, GCC's plugin API is far less stable across versions (internals change with no backward-compatibility guarantee) and requires linking against GCC's own internal headers.

Практическое применение: Linux-ядро использует собственные GCC-плагины (scripts/gcc-plugins/) для дополнительных проверок безопасности во время сборки (structleak — обнуление структур с потенциально чувствительными данными, latent_entropy — добавление источника энтропии в точки входа ядра), которые невозможно выразить обычными предупреждениями компилятора.A practical application: the Linux kernel uses its own GCC plugins (scripts/gcc-plugins/) for extra build-time security checks (structleak — zeroing structs that may hold sensitive data, latent_entropy — adding an entropy source at kernel entry points) that can't be expressed through ordinary compiler warnings.

GCC поддерживает основные санитайзеры LLVM-происхождения — реализации независимые от Clang, но интерфейс флагов совпадает, что позволяет переносить команды сборки между компиляторами почти без изменений.GCC supports the main LLVM-originated sanitizers — implementations independent from Clang's, but with a matching flag interface, which lets build commands carry over between the two compilers almost unchanged.

MemorySanitizer (обнаружение чтения неинициализированной памяти) в GCC отсутствует — единственный из основных санитайзеров LLVM-семейства, доступный только в Clang (см. профиль Clang), поскольку его реализация завязана на инструментацию, тесно интегрированную с внутренними проходами именно LLVM.MemorySanitizer (detecting reads of uninitialized memory) is absent from GCC — the one major sanitizer from the LLVM family available only in Clang (see the Clang profile), since its implementation depends on instrumentation tightly integrated with LLVM's own internal passes.

g++ -fsanitize=address,undefined -g -O1 main.cpp -o main
// -O1, а не -O0 — рекомендация самих санитайзеров: разумный компромисс
// между читаемостью стектрейса и реалистичной скоростью выполнения// -O1, not -O0 — the sanitizers' own recommendation: a reasonable trade-off
// between readable stack traces and realistic execution speed

Собственный синтаксис расширений языка, во многом позже принятый Clang для совместимости.GCC has its own extension syntax, much of it later adopted by Clang for compatibility.

void critical() __attribute__((always_inline));   // принудительный inline// force inlining
struct Packet { char a; int b; } __attribute__((packed)); // без выравнивания полей// no field padding
void fatal_error() __attribute__((noreturn));      // функция никогда не возвращается// function never returns

#define likely(x)   __builtin_expect(!!(x), 1)
if (likely(ptr != nullptr)) { /* ... */ }

#define max(a, b) ({ \
    __typeof__(a) _a = (a); \
    __typeof__(b) _b = (b); \
    _a > _b ? _a : _b; })

плюсы:pros: максимальное число поддерживаемых целевых архитектур из всех трёх (см. обзор других компиляторов и таргетов), зрелые backend-оптимизации, накопленные за десятилетия, стандарт де-факто для встраиваемых систем и ядра Linux, полностью свободная лицензия.the widest range of supported target architectures of all three (see the overview of other compilers and targets), mature backend optimizations accumulated over decades, the de-facto standard for embedded systems and the Linux kernel, a fully free license.

минусы:cons: исторически менее читаемая диагностика ошибок (хотя разрыв с Clang в последних версиях заметно сократился), внутренние API (GIMPLE/RTL, plugin-интерфейс) не рассчитаны на стабильное переиспользование сторонними инструментами, GPL создаёт трение для встраивания компилятора внутрь проприетарных продуктов, отсутствие MemorySanitizer.historically less readable error diagnostics (though the gap with Clang has narrowed considerably in recent versions), internal APIs (GIMPLE/RTL, the plugin interface) aren't designed for stable reuse by third-party tools, GPL creates friction for embedding the compiler inside proprietary products, no MemorySanitizer.

• GCC — Option Summary
• GCC — Instrumentation Options (sanitizers)
• GCC Internals — Plugins
• GCC Internals — GIMPLE