A compiler suite for 32- and 64-bit Windows based on the GNU toolchain
What distinguishes TDM-GCC from other GCC distributions?
These are some of TDM-GCC's "quirks": just a few things you need
to know about TDM-GCC before diving in.
Static runtime linkage (libgcc & friends)
- TDM-GCC doesn't link your programs with the libgcc or libstdc++ runtime
DLLs by default.
- Other toolchains default to DLL runtime linkage in order to allow you to
throw exceptions among DLLs and EXEs.
- TDM-GCC lets you throw exceptions among DLLs and EXEs even with the static
- Your programs will not rely on any additional DLLs when compiling with
- TDM-GCC still includes DLL versions of the libgcc and libstdc++ runtimes,
which you can enable for your program with "-shared-libgcc" and
"-shared-libstdc++" if desired.
Different 64-bit DLL names
- The 64-bit runtime DLLs distributed with the TDM64 edition of TDM-GCC
have "_64" suffixes.
- This allows these DLLs to exist in the same directory as the 32-bit
- Your program can share a DLL search path between its 32- and 64-bit
"pthreads" emulation layer (POSIX threads
- GCC currently requires POSIX threads (pthreads) support on the target
system in order to implement C++11 concurrency features such as
- TDM-GCC includes a pthreads emulation layer for Microsoft Windows systems,
called "winpthreads". This lets you use std::thread and other C++11
concurrency features in your programs, out of the box.
- The "winpthreads" implementation used in TDM-GCC is compiled
statically, so you don't have to distribute additional DLLs with your programs
except by choice.
- However, it is patched to allow the threads it creates to cooperate among
DLLs and EXEs.
TDM64: 32-bit host, 64-bit or 32-bit targets
- The TDM64 edition is able to run on 32-bit and 64-bit systems,
because the compiler executables are all 32-bit.
- The TDM64 edition will build programs that are 64-bit by default, because
it functions as a "native x86_64-w64-mingw32" toolchain.
- The TDM64 edition is not a cross compiler except in the strictest sense of
the word. From a GNU configury standpoint, it is a native toolchain because
its HOST and TARGET systems are the same
- The TDM64 edition is a "bi-arch" toolchain, sometimes called
- That means it can also generate 32-bit programs if you want it to. You
just need to use the "-m32" flag both when you compile your source
code to object code, and when you link your object code into DLLs or
- You can't mix 32-bit object code and 64-bit object code, or you'll get
linker errors. These usually look like "undefined reference to ...",
or "architecture of input file ... is incompatible with ...".
- You can't use a 32-bit version of GDB to debug a 64-bit program. This is
why the version of GDB provided with the TDM64 edition is a 64-bit-only
program. You need to use a 32-bit version of GDB, such as the one provided
by the MinGW.org project, to debug 32-bit programs.
TDM32 exception unwinder formats (SJLJ vs DW2)
- The TDM32 edition of TDM-GCC comes in two different flavors with respect
to how it propagates exceptions in compiled programs.
- The default flavor uses a method called "SJLJ", which stands for
- SJLJ slows your program down somewhat - it adds some additional code to
every function you write to account for handling exceptions, and that code is
- However, SJLJ is able to interoperate to a certain extent with Windows'
system libraries and libraries generated by the Microsoft Visual C/C++
compiler. It can't catch MSVC-thrown exceptions, but it will allow you to
throw your own exceptions through other libraries, such as when you throw an
exception in a Windows API callback function and catch it in your WinMain
- The second flavor of the TDM32 edition uses a method called
"DW2", which stands for "Dwarf-2".
- DW2 is mostly faster than SJLJ. It doesn't add any additional code to your
functions, so during normal program execution (no exception being thrown)
there is no overhead.
- However, DW2 generates tables of data that are stored alongside your code
to help out when an exception is thrown. This means that your programs
will be larger than they would be using the SJLJ flavor.
- Finally, DW2 is actually slower than SJLJ when an exception is
thrown, because it has to perform additional calculations based on the stored
data to determine how to handle the exception.
- The default TDM32 flavor is SJLJ, due to its better compatibility.
- However, you can choose the DW2 flavor if you prefer, as long as you can
guarantee that you'll only need to propagate exceptions through code that is
compiled with the same compiler, or another DW2-enabled GCC toolchain.
- The DW2 flavor comes as a completely separate set of downloads. The
TDM-GCC installer won't let you install both the SJLJ flavor and the DW2
flavor in the same location. However, you can merge the two installations on
your own if you really want to, because the DW2 files either have
"-dw2" tacked onto their names, or are stored in subdirectories with
different names. There are a few duplicate files, which can safely be
overwritten and used with either flavor.
- If you need to, you can rename the compiler drivers in the DW2 flavor to
get rid of the "-dw2" portion, if you prefer the DW2 default or have
a separate build system that expects the default naming scheme.
TDM64 exception unwinder formats (SJLJ and 64-bit
- The TDM64 edition of TDM-GCC also has two different flavors of exception
- Which flavor is used depends on whether you create a 64-bit or a 32-bit
- 64-bit binaries use "SEH", which stands for "Structured
- This is the same type of exception handling that 64-bit programs generated
by Microsoft Visual C/C++ use.
- You still can't catch exceptions in TDM-GCC-compiled code that were thrown
by MSVC-compiled code, but you can safely throw exceptions through
MSVC-compiled code, such as Windows system libraries, and MSVC exceptions will
safely propagate through your code as well.
- If you create a 32-bit binary with the TDM64 edition, it will use SJLJ
exception handling. DW2 exception handling is not available in this