Package: g++-mingw-w64-x86-64-posix
Version: 10.2.1-6+24.2
Severity: normal
X-Debbugs-Cc: osm...@problemloesungsmaschine.de
Dear Maintainer,
Consider the following C++ program:
```
#if defined(__STDCPP_THREADS__) && (__STDCPP_THREADS__ == 1)
#include <iostream>
#include <thread>
#include <cmath>
static void mythread(double param) {
double value = std::pow(param, param);
std::cout << value << std::endl;
return;
}
bool test(int param) {
{
std::thread t{&mythread, static_cast<double>(param)};
t.join();
}
return true;
}
int main(int argc, const char * argv []) {
static_cast<void>(argv);
return test(argc) ? 1 : 0;
}
#else
#error "no threads"
#endif
```
I am seeing:
```
manx@appendix:~/tmp$ x86_64-w64-mingw32-g++-posix -std=c++17 -O3 -Wall -Wextra
-Wpedantic -mthreads cxx17.cpp -o test
cxx17.cpp:30:2: error: #error "no threads"
30 | #error "no threads"
| ^~~~~
```
However, when I manually set -D__STDCPP_THREADS__=1, it builds just fine. The
resulting binary also runs fine on Windows.
```
manx@appendix:~/tmp$ x86_64-w64-mingw32-g++-posix -std=c++17 -O3 -Wall -Wextra
-Wpedantic -mthreads -D__STDCPP_THREADS__=1 cxx17.cpp -o test
manx@appendix:~/tmp$
```
The C++ standard requires compliant implementations to set __STDCPP_THREADS__=1
when they provide <thread>, std::thread, and threading support in general.
The internal _GLIBCXX_HAS_GTHREADS is defined (after including a standard
library header).
Upstream told me in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103949#c5 that
this would be a GCC configuration error, and that GCC needs to be built
differently. I am not knowledgable enough about GCC internals to make that
call. As I understand it, this configuration ought to be blocked by upstream
from even be buildable at all, as it very obviously contradicts itself and is
confused about whether it supports threads or not.
In any case, can you please build MinGW-w64 GCC in a way so that the version
with POSIX threading model properly sets __STDCPP_THREADS__=1 ?
If you agree with my assertion of this being an upstream bug, could you also
please report it upstream? I feel a bug coming from Debian would have more
influence on upstream than a bug report from only a user.
As already said, I am not an expert in GCC internals. What are the implications
of the current supposed misconfiguration on the implemenation of C++11
threadsafe-statics? Does GCC not being properly thread-aware introduce an
initialization race?
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, s390x, armhf, arm64, ppc64el
Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages g++-mingw-w64-x86-64-posix depends on:
ii gcc-mingw-w64-base 10.2.1-6+24.2
ii gcc-mingw-w64-x86-64-posix 10.2.1-6+24.2
ii gcc-mingw-w64-x86-64-posix-runtime 10.2.1-6+24.2
ii libc6 2.33-1
ii libgcc-s1 11.2.0-13
ii libgmp10 2:6.2.1+dfsg-3
ii libisl23 0.24-2
ii libmpc3 1.2.1-1
ii libmpfr6 4.1.0-3
ii libstdc++6 11.2.0-13
ii zlib1g 1:1.2.11.dfsg-2
g++-mingw-w64-x86-64-posix recommends no packages.
Versions of packages g++-mingw-w64-x86-64-posix suggests:
pn gcc-10-locales <none>
-- no debconf information
