C++ threads without winpthreads library

[niXman]

Hello! @here

I just successfully build the gcc-trunk using the patch[1] provided by Eric Botcazou for inclusion in GCC.

the toolchain was configured as: ./build --mode=gcc-trunk --bootstrapall --jobs=4 --rev=0 --rt-version=v10 --threads=win32 --with-default-win32-winnt=0x0601 --exceptions=seh --arch=x86_64 --bin-compress --enable-languages=c,c++

please test and report any issues!

the archive: https://www.filemail.com/d/fkvheftgmwnhzou
sha256 sum: aa2c516a0c23a8888ab4de26ed201927db7c7cbea0683efb00d6576e81653777
VirusTotal report: https://www.virustotal.com/gui/file/aa2c516a0c23a8888ab4de26ed201927db7c7cbea0683efb00d6576e81653777?nocache=1

[1] https://gcc.gnu.org/pipermail/libstdc++/2022-October/054895.html

[niXman]

published: 15add2a

will merge it later.

[xtemp09]

My hands are shaking. I feel like a little child. Thousands of chickens were sacrificed to please the dark gods. Now we have one abstraction layer less, the programs will be smaller and faster.

Even grass is greener! Twenty years ago we had snow in the end of September, now we have it in the end of November!

Though, one question remains, niXman, you compiled with --threads=win32, while LH proposes to compile it with --threads=mcf. What is the difference between the two?

Why did you provide libwinpthread-1.dll, while it's no longer required to build with std::thread?

Does Fortran work? You built the toolchain with --enable-languages=c,c++,lto, so, I can't test it.

g++.exe and x86_64-w64-mingw32-g++.exe are the same. Why do you not prefer symlinks? 7z preserves them. From here:

Starting with Windows 10 Insiders build 14972, symlinks can be created without needing to elevate the console as administrator.

[niXman]

My hands are shaking. I feel like a little child. Thousands of chickens were sacrificed to please the dark gods. Now we have one abstraction layer less, the programs will be smaller and faster.

=)

Twenty years ago we had snow in the end of September, now we have it in the end of November!

I don't want snow in September, too early =)

Though, one question remains, niXman, you compiled with --threads=win32, while LH proposes to compile it with --threads=mcf. What is the difference between the two?

because LH proposed to replace winpthreads with mcfthreads and his proposal was not supported because it does not fix an existing problem, but is the same additional abstraction layer as winpthreads.

Why did you provide libwinpthread-1.dll, while it's no longer required to build with std::thread?

because of libgomp.dll, it requires pthreads API.

Does Fortran work? You built the toolchain with --enable-languages=c,c++,lto, so, I can't test it.

hmm... I don't know, I din't try to build with fortran for now.

g++.exe and x86_64-w64-mingw32-g++.exe are the same. Why do you not prefer symlinks? 7z preserves them.

because locally im still using Win7 =)

[starg2]

Win32 native std::thread implementation is a long-awaited feature. Until that patch gets merged to GCC trunk, I would preserve the old win32 threading as-is, and would introduce a new threading model for this patch:

• --threads=win32: win32 without the patch
• --threads=win32-eric: win32 with the patch

[niXman]

@starg2

Until that patch gets merged to GCC trunk

it will not be merged until it be tested, but no one reported back about any success/fail cases...
I think the only way to get any reports back is to deploy that patch as the current win32-threads builds and to wait for the reports =)

[starg2]

I see. In that case, I would add an option (which is enabled by default) to apply the patch.

Actually, I prefer MCF threading over this patch, but MCF isn't without its problems.

[niXman]

In that case, I would add an option (which is enabled by default) to apply the patch.

then for what that option needed if it will be enabled by default?

[starg2]

I mean I still want a way to disable the patch.

[niXman]

then it never be tested and accepted in GCC...

up
got it!
for some reason you need the ability to build without the patch?

[starg2]

for some reason you need the ability to build without the patch?

Yes. If you decided to apply the patch unconditionally, it'd be fine anyway because I could manually revert it if necessary. It's just that I would provide an option if I were you.

---

What's your plan? Are you planning to release GCC 13 binaries with the patch and expecting it to be merged to GCC 14 or 15? Or are you going to release GCC 12.2.0 binaries with the patch backported and hoping it gets merged to GCC 13?

[niXman]

Yes. If you decided to apply the patch unconditionally, it'd be fine anyway because I could manually revert it if necessary. It's just that I would provide an option if I were you.

got it. I'll add the option.

What's your plan? Are you planning to release GCC 13 binaries with the patch and expecting it to be merged to GCC 14 or 15?

correct.

Or are you going to release GCC 12.2.0 binaries with the patch backported

no, let's leave 12.2.0 as is.
I will do it today or tomorrow.

thanks for your thoughts!

[niXman]

@starg2 done: #629

[niXman]

so, libstdc++ thread support without libwinpthread is now in gcc-master!
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=9149a5b7e0a66b7b94d5b7db3194a975d18dea2f

this means we will get libstdc++ thread support without libwinpthread support in gcc-13!

[niXman]

@starg2 well, how should we deal with --win32-threads-without-threads option?
just to remove its use from gcc-13 and later?: https://github.com/niXman/mingw-builds/blob/develop/scripts/gcc-trunk.sh#L62

or we will use it for conditional use of --enable-libstdcxx-threads=yes? : https://github.com/niXman/mingw-builds/blob/develop/scripts/gcc-trunk.sh#L97

[starg2]

Now win32 native threading is fully supported by upstream, I think we can simply remove --win32-threads-without-threads option entirely.

(BTW I didn't expect the patch to be merged so quickly.)

[niXman]

we can simply remove --win32-threads-without-threads option entirely.

great, I will do it.

(BTW I didn't expect the patch to be merged so quickly.)

me too, but this is great news!

[niXman]

done: 9e8a849