Re: Transitioning libgomp from C to C++ implementation: Windows ('--mingw32*')

LIU Hao via Gcc <[email protected]> Fri, 3 Jul 2026 10:45:44 +0800
Newsgroups	gmane.comp.gcc.devel
Message-ID	<[email protected]>
在 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 (application/pgp-signature, 840 B)