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.
