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

On 7/2/26 22:38, Thomas Schwinge wrote:
> Hi Jonathan!
> 
> The GCC 'MAINTAINERS' file lists you as maintainer for cygwin, mingw-w64.
> 

+LH, NS and Cygwin developers.

> On 2026-05-07T13:16:59+0200, I wrote:
>> [...]
>>
>> The idea of transitioning libgomp from C to C++ implementation has come
>> up a number of times, [...]
>>
>> I'm now working on this.
>>
>> For a start, I've assessed that all GCC configurations that support
>> libgomp also are able to build the GCC/C++ front end, as far as I can
>> easily tell.
>>
>> I'll try to be mindful about handling all of libgomp's implementation
>> files, but may reach out to individual GCC target maintainers for
>> 'libgomp/config/' files, for example, that I can't easily test myself.
>>
>> [...]
> 
> Per my understanding, for GCC/MinGW, libgomp is not enabled by default in
> GCC 'configure.ac' (needs explicit '--enable-libgomp'), but it appears to
> be supported: 'mingw32' (only explicitly '32', though?) is mentioned in
> 'libgomp/configure.tgt', and has 'libgomp/config/mingw32/' files.
> 
> What about the original MinGW vs. MinGW-w64 vs. Cygwin variants; does the
> '*-*-mingw32*' triplet (as used in 'libgomp/configure.tgt') apply to all
> these, or just some?
> 
> Please let me know in case libgomp/MinGW is in fact not supported
> (anymore).
> 

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.

> 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.

> 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.

Cygwin configuration details is available at 
https://www.cygwin.com/cgit/cygwin-packages/gcc/tree/gcc.cygport, only 
x86_64 cygwin is supported currently, i686 is no longer maintained.

There is a known race condition when enabling libgomp and C++ at the 
same time where libgomp depends on target/bits headers from libstdc++ 
being generated while libstdc++.la depends on libgomp.la being 
generated. It might be a mingw* specific issue, one that I'm not sure 
how to resolve.