Skip to content
Switch branches/tags
Go to file
1 contributor

Users who have contributed to this file

              _/_                                      _\_
           __/__/  TDM-GCC Compiler Suite for Windows  \__\__
          | « « |            GCC 10 Series             | » » |
           ¯¯\¯¯\ 32-bit Edition       /¯¯/¯¯
              ¯\¯                                      ¯/¯

This edition of TDM-GCC is an unofficial replacement for the GCC binaries distributed by the project.

  • TDM-GCC isn't endorsed by or affiliated with the project.
  • Support for TDM-GCC is best-effort. If you encounter a bug in TDM-GCC, you won't get help from the maintainers unless the bug is also present in the official binaries.


If you encounter a problem while using a TDM-GCC build that isn't present in a previous MinGW or TDM release, please submit a helpful bug report at



Using the TDM/MinGW installer is highly recommended; it can automatically install TDM-GCC (or the official MinGW GCC) as well as all supplementary base system packages. The installer uses a standard wizard interface with reasonable defaults.


Do not install TDM-GCC packages on top of a previous GCC installation of any kind.

You will need to download and unpack a set of archives. A minimal base set of archives is required; there are also some additional components that are optional, adding support for additional programming languages or GCC features.

TDM-GCC provides a ZIP-compressed version and a TAR.XZ-compressed version of each archive. Use whichever is easiest.



Unpack all the archives to an empty directory. You may choose any path, though it is recommended that you avoid a path with any spaces in the folder names.

The mingwrt package also needs the file include/features.h. This file is typically generated by the mingw-get installer or the TDM-GCC installer, but you can create it yourself by copying its contents from the wsl-features-20190122-1-mingw32-cfg.tar.xz package inside the file var/lib/wsl/features.lua.

Finally, consider adding the bin subdirectory to your Windows PATH environment variable.



Starting from release 9.2.0, both editions of TDM-GCC come with a windows-default-manifest package. If you install it (which is recommended), it provides an automatically-added XML compatibility manifest to all executables. This internal manifest, mingw32/lib/default-manifest.o, is designed to signal to recent versions of Windows (8.1 and later) that the executable is compatible with all versions of Windows and doesn't need to be run in a compatibility environment for older versions.

If you provide your own manifest, it will override the default manifest.

The default manifest looks like this:


"<?xml version=""1.0"" encoding=""UTF-8"" standalone=""yes""?>\n"
"<assembly xmlns=""urn:schemas-microsoft-com:asm.v1"" manifestVersion=""1.0"">\n"
"  <trustInfo xmlns=""urn:schemas-microsoft-com:asm.v3"">\n"
"    <security>\n"
"      <requestedPrivileges>\n"
"        <requestedExecutionLevel level=""asInvoker""/>\n"
"      </requestedPrivileges>\n"
"    </security>\n"
"  </trustInfo>\n"
"  <compatibility xmlns=""urn:schemas-microsoft-com:compatibility.v1"">\n"
"    <application>\n"
"      <!--The ID below indicates application support for Windows Vista -->\n"
"      <supportedOS Id=""{e2011457-1546-43c5-a5fe-008deee3d3f0}""/>\n"
"      <!--The ID below indicates application support for Windows 7 -->\n"
"      <supportedOS Id=""{35138b9a-5d96-4fbd-8e2d-a2440225f93a}""/>\n"
"      <!--The ID below indicates application support for Windows 8 -->\n"
"      <supportedOS Id=""{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}""/>\n"
"      <!--The ID below indicates application support for Windows 8.1 -->\n"
"      <supportedOS Id=""{1f676c76-80e1-4239-95bb-83d0f6d0da78}""/> \n"
"      <!--The ID below indicates application support for Windows 10 -->\n"
"      <supportedOS Id=""{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}""/> \n"
"    </application>\n"
"  </compatibility>\n"

See for more details, and;a=tree for the upstream source, which is unmodified for TDM binaries.


The "gdb32" package is a slightly-modified build of GDB for 32-bit Windows that includes Python 3, enables libstdc++ Python pretty printing by default, and uses wrapper executables to allow 64-bit and 32-bit cooperation in the "bin" directory. For more details, see the separate README file (


For TDM-GCC 4.8.1 and later, a significant change has been introduced which allows you to use C++11 features such as std::thread that, in GCC, rely on the POSIX threading library, pthreads. TDM-GCC now includes a new pthreads compatibility layer called winpthreads instead of the old "pthreads-w32".

"winpthreads" is one of the libraries distributed by the MinGW-w64 project, and it allows GCC to be compiled with full pthreads compatibility, which is necessary to enable std::thread and other threading related functions in the C++ runtime.

Because of TDM-GCC's continuing goal of minimizing extra DLLs, winpthreads has been compiled statically. It will be statically linked with every program you compile, which will increase your baseline executable size.

The same mechanism used in libgcc and libstdc++ to allow EXEs and DLLs to share state for handling exceptions has also been patched into winpthreads, to allow your EXEs and DLLs to share C++11 thread handles via the underlying pthread handles.

Because every program you compile will now rely on winpthreads, you should make sure to read and comply with its MIT-style license, included in the file "COPYING.winpthreads.txt".


IMPORTANT NOTE: There is a known bug in the binutils 2.32-1 release that makes LTO unable to work with static libraries (.a files) in many cases.

Every TDM-GCC release since 4.5.1 includes support for GCC's Link-Time Optimizer. As long as GCC's own drivers (gcc, g++, etc.) are used at both compile-time and link-time, and the "-flto" option is specified at both compile- time and link-time, link-time optimization will be applied. See for further details.


GCC currently supports two methods of stack frame unwinding: Dwarf-2 (DW2) or SJLJ (setjmp/longjmp). Until recently, only SJLJ has been available for the Windows platform. This affects you, the end user, primarily in programs that throw and catch exceptions. Programs which utilize the DW2 unwind method generally execute more quickly than programs which utilize the SJLJ method, because the DW2 method incurs no runtime overhead until an exception is thrown. However, the DW2 method does incur a size penalty on code that must handle exceptions, and more importantly the DW2 method cannot yet unwind (pass exceptions) through "foreign" stack frames: stack frames compiled by another non-DW2-enabled compiler, such as OS DLLs in a Windows callback.

This means that you should in general choose the SJLJ version of the TDM-GCC builds, unless you know you need faster exception-aware programs and can be certain you will never throw an exception through a foreign stack area.

As distributed, the SJLJ and DW2 packages of TDM-GCC can coexist peacefully extracted to the same directory (i.e. any files in common are for all intents and purposes identical), because the driver executables (the ones in the "bin" directory) are suffixed with "-dw2" for the DW2 build, and the libraries and other executables hide in another "-dw2" directory in "lib(exec)/gcc/mingw32". This allows you to use the same single addition to your PATH, and use DW2 exceptions only when you need them by calling "gcc-dw2", etc. If you truly want DW2 exceptions as the default when calling "gcc" (from Makefiles or configury systems, for example), you can rename or copy the suffixed executables to their original names.


IMPORTANT NOTE: TDM-GCC uses a statically-linked libstdc++ by default! To use the libstdc++ DLL, specify -shared-libstdc++ on the command line.

For the GCC 4.5 release series and later, the mingw32 port finally supports fully the same method every other platform uses to allow exceptions to propagate out of shared libraries (DLLs): gcc library DLLs. For any GCC language that supports exceptions (and DLLs), this method requires the runtime presence of two additional DLLs: (1) libgcc_s*.dll, which contains common core data, and (2) a language-specific DLL.

However, TDM-GCC also continues to integrate a versioned shared memory region for the static (non-DLL) runtime libraries, which will still allow you to throw exceptions between any DLLs or executables that are built with TDM-GCC. This method incurs a very small execution overhead as compared to the shared library method, but has the very important benefit of not requiring you to redistribute extra DLLs with your program.

By default, TDM-GCC will continue to create executables and DLLs that use the static libraries and do not require you to redistribute further DLLs. If you would like to use the shared libraries, you should add "-shared-libgcc" to the command line to use a shared version of libgcc, and additionally ensure that the shared version of your language-specific runtime library is being used. For C++, add -shared-libstdc++.

You cannot use a shared version of libgcc with a static version of a language- specific runtime. The reverse -- static libgcc with shared language-specific runtime -- should work fine.


There has been an update to the license exception clause that permits you to distribute programs that make use of the GCC runtime libraries without requiring you to license your programs under the GPLv3. As always, please be familiar with the terms of GCC's GPLv3 license and exception clauses, and do not redistribute any portion of GCC, including its runtime DLLs, in any way except as granted by the license. If you are unclear about which permissions are granted by the license, please consult a lawyer and/or the Free Software Foundation (

A copy of the GPLv3 may be found in the file COPYING-gcc-tdm.txt, and a copy of the runtime library exception clause may be found in COPYING.RUNTIME-gcc-tdm.txt. In general, the runtime library exception clause probably applies to any file found in the "lib" directory or its subdirectories, and any DLL found in the "bin" directory -- but you should consult the sources, available for download from the TDM-GCC project site on SourceForge, if you are unsure.


TDM-GCC has been built to allow the use of GCC's "-fopenmp" option for generating parallel code as specified by the OpenMP API. (See for details.) If you want to use OpenMP in your programs, be sure to install the "openmp" optional package.

The OpenMP support in the TDM-GCC builds has received very little testing; if you find build or packaging problems, please send a bug report (see BUGS above).

LibGOMP, GCC's implementation of OpenMP, currently only supports the use of the POSIX Threads (pthreads) api for implementing its threading model. Because the MinGW project itself doesn't distribute a pthreads implementation, the "winpthreads" library, available as part of the MinGW-w64 project libraries, is included in this distribution. The "winpthreads" library is distributed under the terms of an MIT-style license; see "COPYING.winpthreads.txt" for details.

In order to correctly compile code that utilizes OpenMP/libGOMP, you need to add the "-fopenmp" option at compile time AND link time. By default, this will link the static version of winpthreads to your program, and you should not need to distribute any additional DLLs with your program. If you plan to distribute a program that relies on OpenMP and winpthreads, be sure to understand and comply with the terms of winpthreads' license (see COPYING.winpthreads.txt).

"libpthread.a" is included in the "lib" subdirectory of the openmp package along with three other pthreads library files:

  • "libpthread_s.a" and "libwinpthread.dll.a" link to a DLL version of winpthreads - libwinpthread-1.dll.
  • "libwinpthread.a" is the same as "libpthread.a".


Recent GCC releases make significant strides in optimization capabilities, error detection, and standards compliance. For you, the end user, this often means that code which compiled and ran without problems on previous GCC releases will exhibit some warnings and maybe even a few errors.

These meaningful warnings and errors are a very good thing, as they help the programmer to write safer and more correct code. Unfortunately, there's also a chance you might encounter incorrect warnings or errors, ICE's (internal compiler errors, where the compiler makes a mistake and has to bail out), or even miscompilations (where your code is incorrectly compiled and produces the wrong result).

If you encounter an ICE while using a TDM-GCC build, feel free to file a bug report (see BUGS above). With any other unexpected problem, you are urged to work from the assumption that it stems from user error, and ensure that your code is correct and standards-compliant.


You can detect the operation of TDM32 GCC by parsing the GCC --version string, which will include "(tdm-n)" in the output, where n is a number indicating how many TDM32 binary releases were made against a given upstream GCC release. TDM-GCC does not otherwise attempt to identify itself at compile time, such as with preprocessor defines.

Ideally, the binaries and compiled code produced by TDM-GCC would be ABI-compatible with other Windows compilers, such as, MinGW-w64/MSYS2, and even Microsoft Visual C/C++. This is sadly not the case.

  • Generated object files:
    • [MAYBE:, mingw32]
      • The DW2 flavor of this TDM32 edition is "drop-in" compatible with object files (.o) and static library files (.a) from the same GCC release series. Just don't mix generated code from SJLJ with DW2 in the same executable or DLL, and don't mix code from two different GCC major release numbers.
    • [NO: MinGW-w64, i686-w64-mingw32]
      • The SJLJ flavor of this TDM32 edition may or may not be compatible with MinGW-w64 generated 32-bit code at any given point in time, and you should assume it isn't. Don't mix TDM generated code with MinGW-w64 generated code in the same executable or DLL.
    • [NO: MSVC]
      • Microsoft Visual C/C++ generated code is not compatible with GCC unless you are truly elite.
  • DLL linkage:
    • [MAYBE:, MinGW-w64]
      • TDM-GCC builds DLLs and EXEs with statically-linked libgcc and libstdc++, that rely on a shared memory region to propagate exceptions.
      • Linking DLLs to EXEs with C linkage (extern "C", __cdecl, __stdcall) is generally safe regardless of maintainer, GCC version, or exception flavor.
      • If you pass the -shared-libgcc and -shared-libstdc++ flags to TDM-GCC, it will build DLLs and EXEs that depend on the libgcc and libstdc++ DLLs. A DLL or EXE built with these options can safely link to a or MinGW-w64 DLL or EXE and pass exceptions into and out of DLLs, if the other GCC and TDM-GCC share the same GCC libstdc++ ABI. The ABI may change between GCC minor releases. 32-bit and 64-bit DLLs and EXEs mostly cannot interoperate.
      • If you link a normal TDM-GCC-built DLL to a or MinGW-w64-built EXE, you must distribute the TDM versions of the libgcc and libstdc++ DLLs. These versions will track the shared memory region and allow exceptions to propagate between DLL and EXE. The same goes for linking a or MinGW-w64 DLL to a normal non-shared TDM-GCC EXE.
      • If you take care to match calling conventions and catch exceptions, C linkage is possible. C++ linkage for classes is fraught and for STL / libstdc++ objects is not possible. Maybe there's a compatibility layer somewhere.
  • libgcc and libstdc++ DLL replaceability:
    • The libgcc DLL distributed with TDM32 GCC is expected to be ABI compatible with the GCC 10 series libgcc DLL, when it is released.
    • The libstdc++ DLL distributed with TDM32 GCC is expected to be ABI compatible with GCC 10.3 libstdc++, if and when it is released.
    • The same goes for MinGW-w64/i686-w64-mingw32; expect major version compatibility for libgcc and major+minor compatibility for libstdc++.


As these builds are provided on the same basis as the source releases, and the mingw32 target in GCC tends to receive somewhat less-than-average attention, some bugs are expected. If you encounter a bug that you are certain is in the GCC sources (such as an ICE), you should report it to GCC Bugzilla: If it is due to an issue in the TDM-GCC build or packaging process, report it at


See the Github repository for more details.

  • Fix-using-large-PCH.patch # Handle larger precompiled headers
  • make-rel-pref.patch # Make GCC fully portable (relocatable)
  • lfs.patch # Enable large file support in libstdc++
  • libgomp.patch # Allow libgomp to interoperate with user-generated pthreads
  • libgcceh.patch # Reintegrate libgcc_eh into libgcc
  • defstatic.patch # Make static versions of libgcc and libstdc++ the default, instead of the shared versions
  • ada-lfs.patch # Allow Ada to build for older versions of the MSVCRT without a stat64 equivalent
  • more-gnattools.patch # Enable building gnatdll for mingw* targets
  • windows-lrealpath.patch # Allow forward slashes in libiberty as path separators on Windows
  • xmmintrin.patch # Add C++ include guards to xmmintrin.h
  • crtbegin.patch # Remove static modifier from __EH_FRAME_BEGIN__
  • gnat-implibs.patch # Create import libraries for the DLL versions of libgnat and libgnarl
  • mingw-ansi-stdio.patch # ANSI stdio definition fix
  • mcrtdll.patch # Allow specifying newer MSVCRT versions with -mcrtdll=
  • dw2-reg-frame.patch # Prevent DW2 frame register/unregister from getting mistakenly stripped
  • libgfortran.patch # Allow libgfortran to use umask semantics on MinGW64 but not on MinGW32
  • ssp-wincrypt.patch # Include wincrypt.h for libssp
  • libobjc-install.patch # Allow the libobjc DLL to be stripped when installed
  • branch-clone_function_name_1-Retain-any-stdcall-suffix.patch # Preserve stdcall @n suffixes at the end of function names when cloning
  • fix-libatomic-building-for-threads-win32.patch # Build libatomic with pthreads on Windows
  • ktietz-libgomp.patch # Zero allocated memory in libgomp and run DejaGNU tests if desired
  • gcc-libgomp-ftime64.patch # Use 64-bit ftime in libgomp
  • buildsys.patch # Minor build system hacks for building TDM-GCC in MSYS
  • diagnostic-color.patch # Emit colors in GCC diagnostics when running under MinTTY
  • Handle-spaces-in-path-for-default-manifest.patch # Allow spaces in specfile entries that expand to full paths if they are library files
  • Windows-Don-t-ignore-native-system-header-dir.patch # Windows: Don't ignore native system header dir
  • relocate.patch # Make GCC fully relocatable, not searching any fixed paths
  • Relocate-libintl.patch # Makes libintl resources in Windows binaries automatically relocatable
  • ada-unicode.patch # Fix the include and define order in ada headers to allow Unicode TCHAR detection to work under
  • stdcxx-mingw32.patch # Fixes for building libstdc++ under API
  • libgomp-Don-t-hard-code-MS-printf-attributes.patch # Don't hard-code MS printf attributes
  • libgcc-ldflags.patch # Propagate LDFLAGS while building libgcc_s
  • backport-longjmp-fix.patch # Fix SEH frame pointer alignment
  • mingw32-ada-socket.patch # Fix headers so that winsock constants are correctly found and used in Ada runtime.
  • mingw32.patch # Fixes for building C and Ada under TDM-GCC
  • libstdc__-in-out.patch # Don't use Microsoft-reserved __in or __out as variable names
  • eh_shmem.patch # Create a shared memory handle to allow exceptions from DLLs without shared GCC DLLs
  • threads.patch # Support winpthreads for the 32-bit mingw32 target and a static version of winpthreads
  • mutex-leak.patch # Fix memory leak when using C++11 mutexes
  • jit-port-libgccjit-to-Windows.patch # Build libgccjit for MinGW targets
  • gcc-jit-Rename-libgccjit-dll.patch # Build libgccjit with version numbers
  • dw2.patch # Modify the GCC version string when building the DW2 unwinding flavor


The source code for the TDM-GCC binary releases is available on Github.

Each of the above repositories contains a _PATCHES folder, holding the patches that were applied to the most recent TDM releases.


The GCC proper packages in TDM-GCC contain binary distributions constituting a work based on GCC, ISL, MPC, libiconv, GMP, MPFR and winpthreads.

  • GCC itself is licensed under the GPLv3; for further details, see "COPYING3-gcc-tdm.txt". GCC's runtime libraries are licensed with an additional exception clause; see "COPYING.RUNTIME-gcc-tdm.txt".

  • MPC, libiconv, GMP, and MPFR are each licensed under the LGPLv3, a somewhat more permissive version of the GPL; see "COPYING3.LIB-gcc-tdm.txt".

  • ISL and winpthreads use an "MIT-style" license, reproduced in "COPYING.ISL.txt" and "COPYING.winpthreads.txt".