Transitioning libgomp for Windows fails with ICE and deadlocks
Porting libgomp to Windows using mingw-w64 without winpthreads leads to ICEs and deadlocks, with remaining test failures.
Following a successful backport of libgomp C++ transition patches to GCC 16, issues arose on Windows where linking against the libgomp DLL caused deadlocks. Despite patching mingw-w64 CRT and attempting a rebuild with the win32 thread model, an ICE was resolved but test failures persist, including missing functions and use of pthread equivalents.
- proposer
Reports that after porting libgomp to C++ and applying patches for win32/mcf thread models, a build on GCC master resulted in an ICE, necessitating backporting to GCC 16. Further issues include deadlocks upon exiting programs linked against libgomp DLLs.
“This allows building libgomp with win32 or mcf thread model. When yesterday I tried to build GCC master it ICE'd, so I had to backport the patches to GCC 16, and everything built successfully. However, it turns out that any program that is linked against libgomp DLL deadlocks upon exit; the reason is complex but tl;dr; mingw-w64 CRT has to be patched as well (which I'll push later today):”
- proposer
Updates on the Windows port of libgomp, noting the ICE is gone after mingw-w46 CRT update, but ~20 test failures remain, including missing functions and use of pthread functions, along with Fortran test failures.
“With https://sourceforge.net/p/mingw-w64/mingw-w64/ci/0fad182ff178044ee442b05e1913aa16cde8efcf/ committed, I tried updating mingw-w64 CRT and rebuilding GCC with win32 thread model. The ICE was gone, so I went ahead and ran libgomp tests. There were ~20 failures in C and C++ tests; some of them didn't compile, for example, libgomp/testsuite/libgomp.c-c++-common/cancel-taskgroup-1.c contains a…”
Technical Tradeoffs
- Switching libgomp to C++ might offer better abstraction but introduces C++/Windows integration challenges.
- Avoiding winpthreads for mingw-w64 targets simplifies dependencies but requires careful handling of Windows-native threading primitives.
In Details
This discussion on transitioning libgomp (GCC's OpenMP runtime) to C++ for Windows targets ('*-*-mingw32*') highlights cross-platform build and runtime issues. The core problem appears to be integrating libgomp with the mingw-w64 CRT and its threading model (win32 thread) as a replacement for winpthreads, which is standard on POSIX systems. Failures include compiler Internal Compiler Errors (ICEs) and runtime deadlocks, indicating fundamental incompatibilities or missing pieces in the mingw-w64 environment for libgomp's threading primitives.
- libgomp
- The GNU Offloading Manager, providing the runtime support for OpenMP in the GCC compiler.
- OpenMP
- An API for supporting shared-memory parallel programming in C, C++, and Fortran.
- mingw-w64
- A development environment for creating Windows applications. It provides GCC toolchains and Windows API headers/libraries.
- winpthreads
- A POSIX threads-compatible implementation for Windows, often used by libraries compiled with mingw-w64.
- CRT
- C Runtime library. Provides essential functions for C programs, including memory management, I/O, and process control.
- ICE
- Internal Compiler Error, a fatal error within the compiler itself, often indicating a bug in the compiler.
- libgomp DLL
- Dynamic Link Library version of libgomp, allowing it to be loaded at runtime by applications.