https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96817
--- Comment #21 from Jonathan Wakely ---
The abi_check failures are of course expected if you configure with an option
that alters the library ABI.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96817
--- Comment #20 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:9c1125c121423a9948fa39e71ef89ba4059a2fad
commit r11-4723-g9c1125c121423a9948fa39e71ef89ba4059a2fad
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96817
--- Comment #19 from Jonathan Wakely ---
I don't really care about test failures for non-standard configurations like
that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96817
Rimvydas (RJ) changed:
What|Removed |Added
CC||rimvydas.jas at gmail dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96817
--- Comment #17 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:e6923541fae5081b646f240d54de2a32e17a0382
commit r11-3484-ge6923541fae5081b646f240d54de2a32e17a0382
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96817
--- Comment #16 from Yuxuan Shui ---
But yeah, that's definitely a bug in itself as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96817
--- Comment #15 from Yuxuan Shui ---
(In reply to Jonathan Wakely from comment #13)
> (In reply to Yuxuan Shui from comment #1)
> > Example:
> >
> > This program normally deadlocks when using linked pthread:
> >
> > https://godbolt.org/z/Yrza4e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96817
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96817
--- Comment #13 from Jonathan Wakely ---
(In reply to Yuxuan Shui from comment #1)
> Example:
>
> This program normally deadlocks when using linked pthread:
>
> https://godbolt.org/z/Yrza4e
>
> But it will throw recursive_init_error when using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96817
--- Comment #12 from Jonathan Wakely ---
Oh plus this for the aborted init case:
@@ -351,7 +366,17 @@ namespace __cxxabiv1
#ifdef _GLIBCXX_USE_FUTEX
// If __atomic_* and futex syscall are supported, don't use any global
// mutex.
+#if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96817
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96817
--- Comment #10 from Jonathan Wakely ---
Because it pessimizes single threaded programs. After we've made some other
changes that depend on a recent glibc, then we can avoid that pessimization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96817
--- Comment #9 from Yuxuan Shui ---
(In reply to Jonathan Wakely from comment #7)
> It will work when Glibc defines all the pthread functions in libc.so and
> libpthread.so becomes empty.
Won't that mean libstdc++ will always use the thread-safe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96817
--- Comment #8 from Jonathan Wakely ---
I'm also going to start using Glibc's __libc_single_threaded instead of
__gthread_active_p() for deciding whether to use atomics for reference counting
in shared_ptr and the old std::string.
Once reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96817
--- Comment #7 from Jonathan Wakely ---
It will work when Glibc defines all the pthread functions in libc.so and
libpthread.so becomes empty. There's not really any way to make it work until
then that wouldn't pessimize programs that are entirely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96817
--- Comment #6 from Yuxuan Shui ---
I meant to say "Is there anything ... can do, to improve the situation?"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96817
--- Comment #5 from Yuxuan Shui ---
(In reply to Richard Biener from comment #4)
> it's been always that way - but yes, people repeatedly fall into this trap
If there anything libstdc++, or maybe the middle man (Mesa in my case) can do,
to impro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96817
--- Comment #4 from Richard Biener ---
it's been always that way - but yes, people repeatedly fall into this trap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96817
--- Comment #3 from Yuxuan Shui ---
(In reply to Jonathan Wakely from comment #2)
> Dynamically loading libpthread breaks everything in libstdc++, it just isn't
> supported.
But it has real use cases, e.g. writing a C++ OpenGL program that doesn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96817
--- Comment #2 from Jonathan Wakely ---
Dynamically loading libpthread breaks everything in libstdc++, it just isn't
supported.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96817
--- Comment #1 from Yuxuan Shui ---
Example:
This program normally deadlocks when using linked pthread:
https://godbolt.org/z/Yrza4e
But it will throw recursive_init_error when using dlopen'd pthread:
https://godbolt.org/z/afMe5d
21 matches
Mail list logo
