在 2026-7-3 08:53, Jonathan Yong 写道:
It should really be mingw* for consistency. *-*-mingw32* applies to both the original mingw and mingw-w64 while cygwin has its own triplet. mingw-w64 is identified by the w64 vendor part. As of now, libgomp depends on a pthread implementation being available, either the classic pthread-win32 or winpthreads or mcfgthread, which is not a default for mingw* target. Cygwin is a POSIX emulation layer on top of win32, so pthread is always available and libgomp should be enabled by default.
At the moment, libgomp calls pthread functions such as `pthread_attr_setstacksize()` and `pthread_create()` even when `LIBGOMP_USE_PTHREADS` is not defined, so it's not buildable without winpthreads.
There are some missing parts in existing mingw32/ which I have sent to gcc-patches:* https://github.com/lhmouse/MINGW-packages/blob/ad0a520b84efe92975a1ee80fe81cd530da435a0/mingw-w64-gcc/9202-libgomp-mingw32-Increase-precision-of-omp_get_wtime-.patch * https://github.com/lhmouse/MINGW-packages/blob/ad0a520b84efe92975a1ee80fe81cd530da435a0/mingw-w64-gcc/9203-libgomp-mingw32-Fix-plugin-suffix.patch * https://github.com/lhmouse/MINGW-packages/blob/ad0a520b84efe92975a1ee80fe81cd530da435a0/mingw-w64-gcc/9204-libgomp-mingw32-Implement-cpu_relax-and-doacross_spi.patch
Coincidentally, in this week I have managed to build libgomp without winpthreads with this patch:* https://github.com/lhmouse/MINGW-packages/blob/ad0a520b84efe92975a1ee80fe81cd530da435a0/mingw-w64-gcc/9205-libgomp-win32-Add-win32-implementation.patch
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):
* https://sourceforge.net/p/mingw-w64/mailman/message/59353887/
Assuming it is supported, I shall try to not break it. During ongoing development, I'll need to run a number of GCC/libgomp builds for the supported MinGW variants over the next few weeks/months (tentatively); therefore would like to do it myself instead of asking you each time. I need GCC 'configure'd with '--enable-languages=c,c++,fortran', '--enable-libgomp', and then 'make', and 'make check-target-libgomp' if feasible. Ideally, easiest, I'd do native builds. Otherwise, cross builds with testing option, or without testing, in case that's not feasible. (I assume that, as for other configurations, my C -> C++ baseline conversion changes are good to go also for MinGW, once they compile without error.) In particular, I'd like to test the following libgomp configuration variants, which are specific to MinGW: Per 'libgomp/configure.tgt': *-*-mingw32*) config_path="mingw32 posix" ..., that is 'libgomp/config/mingw32/' files. As far as I can easily tell, there aren't any architecture-specific compile-time conditionals in these files, so I assume I don't really care about the specific CPU architecture.i686 and x86_64 mingw-w64 is most tested. There is also arm and aarch64 mingw-w64 that is less tested.
There's no architecture-specific hack. (In my patch 9204 above, it's covered by `YieldProcessor()` which is defined in winnt.h, thankfully.)
Additionally, MinGW-specific things in 'libgomp/config/posix/' and core libgomp files. I don't see any Windows systems listed on <https://portal.cfarm.net/machines/list/>. Are there any such systems that I could log in remotely, and do my builds? Otherwise, is cross-compiling GCC an option, and could you provide pointers how to do that?I don't know any available Windows machine for native testing, but cross-compilation should be the minimum. My own personal cross compiler configuration has --enable-host-shared --enable-fully-dynamic- string --enable-libstdcxx-threads --disable-multilib --enable-libgomp --enable-libssp, one build for each architecture. --enable-sjlj-exceptions is needed for i686 mingw* while no specific exception argument is set for x86_64 so SEH exception is used. multilib is also a supported but setup is more complicated.
I do native x86-64 builds almost all the time. If you don't have a native Windows machine, I suggest you have a look at GitHub Actions which provides Windows runners on x86-64 and ARM64. It's where we (mingw-w64) run our CI, and also where MSYS2 build their packages.
This is the MSYS2 recipe to build their native compilers:* https://github.com/msys2/MINGW-packages/blob/100faa15d7ed50930f8a82a84f98abef5a76862d/mingw-w64-gcc/PKGBUILD#L140-L307
-- Best regards, LIU Hao
OpenPGP_signature.asc
Description: OpenPGP digital signature
