18 The compiler landscape — C compilers in active service

18.1 The big three — GCC, Clang/LLVM, MSVC

Today most desktop and server C runs on these three.

GCC (GNU Compiler Collection). A free-software compiler continuing since 1987, and the default of the Linux world. Its greatest strength is the sheer number of CPUs it can target — x86, Arm and RISC-V of course, but also embedded chips such as AVR, MSP430, SuperH and PowerPC, all in one lineage. It is why embedded vendors so often fill the inside of their own tools with gcc (chapter 97).

Clang/LLVM. A later arrival from the 2000s, built on LLVM, which was designed so that a compiler could be used as components. It made its name with friendly diagnostics, and today, thanks to that componentry, a whole ecosystem stands on it — the static analyser (clang-tidy), the formatter (clang-format), the autocompletion server for editors (clangd), and many vendors’ new compilers, all branched off LLVM. It is also the default compiler on macOS.

MSVC (Microsoft Visual C++). The standard tool of Windows. The name says C++ but it compiles C too; for a long time it was said to be incomplete even for C99, but in recent years it supports C11 and C17 and is moving towards C23. Its reason for existing is that it meshes best with the Windows API.

18.2 The compilers that sell performance — vendor compilers

Some compilers sell the promise that the same source will run faster on their own company’s CPU. You meet them mostly in large-scale computing (HPC) and on servers.

One current runs through the table — they all converged on LLVM. Maintaining a compiler of one’s own from scratch became too expensive, so taking the common parts (parsing the syntax, optimisation) from LLVM and attaching only a back end suited to one’s own chip became the standard approach. Intel’s classic icc stepping back and the LLVM-based icx taking its place is the most symbolic scene of that current.

18.3 Embedded — the doorway to the last chapter

Numerically, the largest branch of the world’s C compilers is the embedded side. Every company that makes chips has its own compiler, and where safety certification is at stake (automotive, aerospace, medical) there are specialist firms that sell that certification along with the tools. IAR, Arm’s Keil family, TI, Microchip, Renesas, Green Hills, Wind River — and the free-software SDCC for 8-bit chips. This terrain only makes sense together with the whole toolset (debug probes, on-chip debugging, static analysis), so it gets its own chapter at the end of the book (chapter 97).

18.4 An aside — Pelles C, the tidy alternative on Windows

If the names so far were “what is widely used”, this section is a little different. It holds no large share of the market, but its character is distinct enough to be worth introducing.

Pelles C is Windows-only freeware carried on single-handedly by Pelle Orinius of Sweden. Editor, compiler, assembler, linker, resource editor, debugger and even an installer builder come in one package, and one download is the whole setup. The name comes from its author’s.

Its standard support is notably diligent: the latest edition at the time of writing (14.50, July 2026) states support for C99, C11, C17 and C23. There have been periods in which it followed new standards faster than far larger tools.

Its lineage is interesting too. Pelles C did not appear from nowhere; it is a heavily reworked LCC (the small, portable teaching compiler of Fraser and Hanson). Wikipedia carries it not as an article of its own but as a section of “LCC (compiler)”, describing it there as a heavily modified LCC with C11, C17 and C23 support, amd64 support, optimisations such as inline expansion, and an IDE. Knowing this saves effort when hunting for material — searching Wikipedia for a “Pelles C” article finds nothing.

Downloads are at the official home pellesc.se, while questions and release announcements gather on a separate forum (forum.pellesc.de). The author answering there himself is a long-standing feature of the tool.

Gathering users’ assessments, they divide roughly like this.

18.4.1 Writing a Windows app in C

One more place for this tool is worth marking. It fits writing a desktop app against the Windows API (Win32) particularly well — the resource editor and the linker come in one package, and what comes out is a single executable with no runtime dependency.

“Why write a Windows app in C in this day and age?” is a fair question. Stated without exaggeration, the grounds are these.

18.4.2 What comes in the one package — the resource editor and dialog designer

The real reason this tool suits Win32 work is the editors. The official site lists what is inside.

The dialog editor is what is usually meant by a GUI designer. You drag buttons and text boxes onto a window, the layout is saved as an .rc resource script, and the resource compiler puts it inside the executable. In code you bring the dialog up with DialogBox or CreateDialog and reach controls by their numeric IDs — the long-standing way of working in Win32.

What Microsoft recommends for new apps is not Win32 but the current stack (the Windows App SDK and WinUI 3) — let that be clear. But Windows’s UI stacks have been torn up and replaced several times, MFC → WinForms → WPF → UWP → WinUI, and each time the previous generation moved to the “maintained, but no longer recommended” shelf. What stood outside that churn is Win32, and for a small tool meant to last, that stability is itself the gain.

One thing has changed as well. The cost in the table’s first row — “the code is long” — no longer weighs as much, because boilerplate is exactly the kind of code today’s AI produces well. The shell that creates a window and runs a message loop looks the same everywhere, and there is less reason to memorise it. This book’s attitude holds here too, though: code you were handed still has to be readable before it can be fixed. Even if someone else writes the shell, what runs inside it — the message loop, handles, the lifetime of resources — is yours to know.

In short: it suits working on Windows, in pure C, lightly. Good for learning, for small Windows utilities, and for testing whether some new standard construct really works. Conversely, for code to be ported across platforms, or a project to sit on CMake and CI, the big three above are the fit.

18.5 Others, and the retired names

Small but alive — tcc (Tiny C Compiler) is a tiny compiler of a few hundred KiB, still used for compiling C source on the spot and running it immediately. Small compilers such as cproc and chibicc have value as “teaching material for compilers”. They are not the workhorses of practice.

Famous names no longer in service. When you meet these in old textbooks or web posts, read them with their era in mind.

The Dev-C++ with TDM-GCC combination in particular was used for years in schools and academies, so material about it is still plentiful. The problem is that the combination carries a compiler several versions behind — syntax from C11 onwards, and the C23 keywords (chapter 78), often do not work. If you are starting now, the two routes of chapter 17 (LLVM clang, or gcc from MSYS2) are what to take. A good share of the walls met while following an old textbook — “why does this syntax not work?” — are the age of the tool.

18.6 Where the official material lives

Compiler talk is tied to versions and options, which makes the habit of opening the primary source especially valuable. Here are the addresses that were live as this book was written (domains only — paths change, domains last).

Three things to add. First, the exact meaning of an option is only in that compiler’s manual — including what the warnings turned on in chapter 17 catch. Second, the release notes tell you which standard features arrived in which version — the quickest way to check the state of C23 support. Third, Wikipedia is good for history and lineage; for the basis of exact behaviour, use the official documentation.

One last word for the learner. Any of the compilers in active service in this chapter will do for study. This book’s examples use standard C only, so gcc, clang, MSVC and Pelles C all give the same results. Choose by what is to hand, what installs easily, what your school or workplace uses — what you learn does not change.

One thing, though, is not recommended. Dev-C++ is still widely used because it installs easily, but the compiler it carries is too old. Syntax from C11 onwards and the C23 keywords do not work, which makes it easy to hit the wall of “I wrote it as the book says, so why does it not work?” For the same reason it is better not to follow the Turbo C screens of old textbooks. If ease of installation is the appeal, the two routes of chapter 17 (a one-line LLVM clang install, or gcc from MSYS2) are easy enough — and they come with the newest standard and the checking tools.

The landscape of compilers is spread out. Its widest region — the compilers of embedded work and the tools beside them — only makes sense together with the whole toolset, so it gets its own chapter at the end of the book (chapter 97).

Part III is over. We read the first program (chapter 15), watched the relay that turns it into an executable (chapter 16), equipped the tools (chapter 17) and spread out the world’s landscape of compilers (chapter 18). From the next part the real study of the language begins — not a list of new syntax, but the goal of Part IV: reading one piece of chapter 15′s hello world completely.