public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/55394] New: Using call_once without -lpthread compiles without warning
@ 2012-11-19 12:29 G.J.Giezeman at uu dot nl
2012-11-19 13:45 ` [Bug c++/55394] " redi at gcc dot gnu.org
` (10 more replies)
0 siblings, 11 replies; 12+ messages in thread
From: G.J.Giezeman at uu dot nl @ 2012-11-19 12:29 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55394
Bug #: 55394
Summary: Using call_once without -lpthread compiles without
warning
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned@gcc.gnu.org
ReportedBy: G.J.Giezeman@uu.nl
Created attachment 28731
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28731
Source file
A source file which contains call_once will compile without any errors or
warnings, even when libpthread is not linked. At run time, an exception will be
thrown with a very unhelpful message. The attached source file demonstrates the
problem.
$ g++ -Wall -Wextra -std=c++0x callonce.cpp
$ ./a.out
terminate called after throwing an instance of 'std::system_error'
what(): Unknown error -1
Aborted (core dumped)
Linking libpthread will remove the problem.
$ g++ -Wall -Wextra -std=c++0x callonce.cpp -lpthread
$ ./a.out
$
In the actual use case, call_once was called in a library that could be used in
both multithreaded and singlethreaded code. That made it a hard to trace bug.
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/55394] Using call_once without -lpthread compiles without warning
2012-11-19 12:29 [Bug c++/55394] New: Using call_once without -lpthread compiles without warning G.J.Giezeman at uu dot nl
@ 2012-11-19 13:45 ` redi at gcc dot gnu.org
2012-11-19 14:56 ` [Bug libstdc++/55394] " paolo.carlini at oracle dot com
` (9 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: redi at gcc dot gnu.org @ 2012-11-19 13:45 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55394
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |enhancement
--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-11-19 13:44:48 UTC ---
(In reply to comment #0)
> A source file which contains call_once will compile without any errors or
> warnings, even when libpthread is not linked.
Obviously this is because compiling and linking are separate steps. The
compiler front-end doesn't know in advance whether the linker will be invoked
correctly.
It might be possible to do something similar to PR 52681 to improve the
exception's message.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug libstdc++/55394] Using call_once without -lpthread compiles without warning
2012-11-19 12:29 [Bug c++/55394] New: Using call_once without -lpthread compiles without warning G.J.Giezeman at uu dot nl
2012-11-19 13:45 ` [Bug c++/55394] " redi at gcc dot gnu.org
@ 2012-11-19 14:56 ` paolo.carlini at oracle dot com
2014-09-19 11:04 ` redi at gcc dot gnu.org
` (8 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: paolo.carlini at oracle dot com @ 2012-11-19 14:56 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55394
Paolo Carlini <paolo.carlini at oracle dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|c++ |libstdc++
--- Comment #2 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-11-19 14:55:50 UTC ---
Library anyway.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug libstdc++/55394] Using call_once without -lpthread compiles without warning
2012-11-19 12:29 [Bug c++/55394] New: Using call_once without -lpthread compiles without warning G.J.Giezeman at uu dot nl
2012-11-19 13:45 ` [Bug c++/55394] " redi at gcc dot gnu.org
2012-11-19 14:56 ` [Bug libstdc++/55394] " paolo.carlini at oracle dot com
@ 2014-09-19 11:04 ` redi at gcc dot gnu.org
2020-10-19 22:07 ` slyfox at gcc dot gnu.org
` (7 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: redi at gcc dot gnu.org @ 2014-09-19 11:04 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55394
--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
related to PR 58929
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug libstdc++/55394] Using call_once without -lpthread compiles without warning
2012-11-19 12:29 [Bug c++/55394] New: Using call_once without -lpthread compiles without warning G.J.Giezeman at uu dot nl
` (2 preceding siblings ...)
2014-09-19 11:04 ` redi at gcc dot gnu.org
@ 2020-10-19 22:07 ` slyfox at gcc dot gnu.org
2020-10-20 7:52 ` slyfox at gcc dot gnu.org
` (6 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: slyfox at gcc dot gnu.org @ 2020-10-19 22:07 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55394
Sergei Trofimovich <slyfox at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |slyfox at gcc dot gnu.org
--- Comment #9 from Sergei Trofimovich <slyfox at gcc dot gnu.org> ---
*** Bug 97485 has been marked as a duplicate of this bug. ***
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug libstdc++/55394] Using call_once without -lpthread compiles without warning
2012-11-19 12:29 [Bug c++/55394] New: Using call_once without -lpthread compiles without warning G.J.Giezeman at uu dot nl
` (3 preceding siblings ...)
2020-10-19 22:07 ` slyfox at gcc dot gnu.org
@ 2020-10-20 7:52 ` slyfox at gcc dot gnu.org
2020-10-20 8:29 ` redi at gcc dot gnu.org
` (5 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: slyfox at gcc dot gnu.org @ 2020-10-20 7:52 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55394
--- Comment #10 from Sergei Trofimovich <slyfox at gcc dot gnu.org> ---
How about something as simple as:
--- a/libgcc/gthr-posix.h
+++ b/libgcc/gthr-posix.h
@@ -697,7 +697,12 @@ static inline int
__gthread_once (__gthread_once_t *__once, void (*__func) (void))
{
if (__gthread_active_p ())
- return __gthrw_(pthread_once) (__once, __func);
+ /*
+ * Call non-weak form of a symbol to force linker
+ * resolve real implementation of pthread_once even
+ * for as-needed case: https://gcc.gnu.org/PR55394.
+ */
+ return pthread_once (__once, __func);
else
return -1;
}
Superficial test fixes "-flto -Wl,--as-needed" case above for me.
The fix leaves '__gthread_active_p ()' to probe weak symbols but calls non-weak
form of pthread_once().
If it's a plausible path I can have a pass through all static inline functions,
and convert weak calls to non-weak calls where glibc-2.32 does not define a
symbol in libc.so.6.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug libstdc++/55394] Using call_once without -lpthread compiles without warning
2012-11-19 12:29 [Bug c++/55394] New: Using call_once without -lpthread compiles without warning G.J.Giezeman at uu dot nl
` (4 preceding siblings ...)
2020-10-20 7:52 ` slyfox at gcc dot gnu.org
@ 2020-10-20 8:29 ` redi at gcc dot gnu.org
2020-10-20 23:00 ` slyfox at gcc dot gnu.org
` (4 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: redi at gcc dot gnu.org @ 2020-10-20 8:29 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55394
--- Comment #11 from Jonathan Wakely <redi at gcc dot gnu.org> ---
It's not plausible because it doesn't work for non-pthreads targets where
gthr-default.h is not gthr-posix.h
We can't use pthread_once anyway, see PR 66146, so I'm rewriting it entirely in
terms of either futexes or condition variables.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug libstdc++/55394] Using call_once without -lpthread compiles without warning
2012-11-19 12:29 [Bug c++/55394] New: Using call_once without -lpthread compiles without warning G.J.Giezeman at uu dot nl
` (5 preceding siblings ...)
2020-10-20 8:29 ` redi at gcc dot gnu.org
@ 2020-10-20 23:00 ` slyfox at gcc dot gnu.org
2020-11-03 14:56 ` redi at gcc dot gnu.org
` (3 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: slyfox at gcc dot gnu.org @ 2020-10-20 23:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55394
--- Comment #12 from Sergei Trofimovich <slyfox at gcc dot gnu.org> ---
Aha, makes sense.
My hack did not survive bootstrap anyway as libgcc.a started referring
pthread_once() as well.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug libstdc++/55394] Using call_once without -lpthread compiles without warning
2012-11-19 12:29 [Bug c++/55394] New: Using call_once without -lpthread compiles without warning G.J.Giezeman at uu dot nl
` (6 preceding siblings ...)
2020-10-20 23:00 ` slyfox at gcc dot gnu.org
@ 2020-11-03 14:56 ` redi at gcc dot gnu.org
2020-11-03 18:45 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: redi at gcc dot gnu.org @ 2020-11-03 14:56 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55394
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Target Milestone|--- |11.0
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug libstdc++/55394] Using call_once without -lpthread compiles without warning
2012-11-19 12:29 [Bug c++/55394] New: Using call_once without -lpthread compiles without warning G.J.Giezeman at uu dot nl
` (7 preceding siblings ...)
2020-11-03 14:56 ` redi at gcc dot gnu.org
@ 2020-11-03 18:45 ` cvs-commit at gcc dot gnu.org
2020-11-03 18:46 ` redi at gcc dot gnu.org
2020-11-03 18:46 ` redi at gcc dot gnu.org
10 siblings, 0 replies; 12+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-11-03 18:45 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55394
--- Comment #13 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>:
https://gcc.gnu.org/g:93e79ed391b9c636f087e6eb7e70f14963cd10ad
commit r11-4691-g93e79ed391b9c636f087e6eb7e70f14963cd10ad
Author: Jonathan Wakely <jwakely@redhat.com>
Date: Tue Nov 3 18:44:32 2020 +0000
libstdc++: Rewrite std::call_once to use futexes [PR 66146]
The current implementation of std::call_once uses pthread_once, which
only meets the C++ requirements when compiled with support for
exceptions. For most glibc targets and all non-glibc targets,
pthread_once does not work correctly if the init_routine exits via an
exception. The pthread_once_t object is left in the "active" state, and
any later attempts to run another init_routine will block forever.
This change makes std::call_once work correctly for Linux targets, by
replacing the use of pthread_once with a futex, based on the code from
__cxa_guard_acquire. For both glibc and musl, the Linux implementation
of pthread_once is already based on futexes, and pthread_once_t is just
a typedef for int, so this change does not alter the layout of
std::once_flag. By choosing the values for the int appropriately, the
new code is even ABI compatible. Code that calls the old implementation
of std::call_once will use pthread_once to manipulate the int, while new
code will use the new std::once_flag members to manipulate it, but they
should interoperate correctly. In both cases, the int is initially zero,
has the lowest bit set when there is an active execution, and equals 2
after a successful returning execution. The difference with the new code
is that exceptional exceptions are correctly detected and the int is
reset to zero.
The __cxa_guard_acquire code (and musl's pthread_once) use an additional
state to say there are other threads waiting. This allows the futex wake
syscall to be skipped if there is no contention. Glibc doesn't use a
waiter bit, so we have to unconditionally issue the wake in order to be
compatible with code calling the old std::call_once that uses Glibc's
pthread_once. If we know that we're using musl (and musl's pthread_once
doesn't change) it would be possible to set a waiting state and check
for it in std::once_flag::_M_finish(bool), but this patch doesn't do
that.
This doesn't fix the bug for non-linux targets. A similar approach could
be used for targets where we know the definition of pthread_once_t is a
mutex and an integer. We could make once_flag._M_activate() use
pthread_mutex_lock on the mutex member within the pthread_once_t, and
then only set the integer if the execution finishes, and then unlock the
mutex. That would require careful study of each target's pthread_once
implementation and that work is left for a later date.
This also fixes PR 55394 because pthread_once is no longer needed, and
PR 84323 because the fast path is now just an atomic load.
As a consequence of the new implementation that doesn't use
pthread_once, we can also make std::call_once work for targets with no
gthreads support. The code for the single-threaded implementation
follows the same methods as on Linux, but with no need for atomics or
futexes.
libstdc++-v3/ChangeLog:
PR libstdc++/55394
PR libstdc++/66146
PR libstdc++/84323
* config/abi/pre/gnu.ver (GLIBCXX_3.4.29): Add new symbols.
* include/std/mutex [!_GLIBCXX_HAS_GTHREADS] (once_flag): Define
even when gthreads is not supported.
(once_flag::_M_once) [_GLIBCXX_HAVE_LINUX_FUTEX]: Change type
from __gthread_once_t to int.
(once_flag::_M_passive(), once_flag::_M_activate())
(once_flag::_M_finish(bool), once_flag::_Active_execution):
Define new members for futex and non-threaded implementation.
[_GLIBCXX_HAS_GTHREADS] (once_flag::_Prepare_execution): New
RAII helper type.
(call_once): Use new members of once_flag.
* src/c++11/mutex.cc (std::once_flag::_M_activate): Define.
(std::once_flag::_M_finish): Define.
* testsuite/30_threads/call_once/39909.cc: Do not require
gthreads.
* testsuite/30_threads/call_once/49668.cc: Likewise.
* testsuite/30_threads/call_once/60497.cc: Likewise.
* testsuite/30_threads/call_once/call_once1.cc: Likewise.
* testsuite/30_threads/call_once/dr2442.cc: Likewise.
* testsuite/30_threads/call_once/once_flag.cc: Add test for
constexpr constructor.
* testsuite/30_threads/call_once/66146.cc: New test.
* testsuite/30_threads/call_once/constexpr.cc: Removed.
* testsuite/30_threads/once_flag/cons/constexpr.cc: Removed.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug libstdc++/55394] Using call_once without -lpthread compiles without warning
2012-11-19 12:29 [Bug c++/55394] New: Using call_once without -lpthread compiles without warning G.J.Giezeman at uu dot nl
` (8 preceding siblings ...)
2020-11-03 18:45 ` cvs-commit at gcc dot gnu.org
@ 2020-11-03 18:46 ` redi at gcc dot gnu.org
2020-11-03 18:46 ` redi at gcc dot gnu.org
10 siblings, 0 replies; 12+ messages in thread
From: redi at gcc dot gnu.org @ 2020-11-03 18:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55394
Bug 55394 depends on bug 84323, which changed state.
Bug 84323 Summary: call_once uses TLS even when once_flag is set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84323
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug libstdc++/55394] Using call_once without -lpthread compiles without warning
2012-11-19 12:29 [Bug c++/55394] New: Using call_once without -lpthread compiles without warning G.J.Giezeman at uu dot nl
` (9 preceding siblings ...)
2020-11-03 18:46 ` redi at gcc dot gnu.org
@ 2020-11-03 18:46 ` redi at gcc dot gnu.org
10 siblings, 0 replies; 12+ messages in thread
From: redi at gcc dot gnu.org @ 2020-11-03 18:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55394
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
--- Comment #14 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Fixed for GCC 11.
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2020-11-03 18:46 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-11-19 12:29 [Bug c++/55394] New: Using call_once without -lpthread compiles without warning G.J.Giezeman at uu dot nl
2012-11-19 13:45 ` [Bug c++/55394] " redi at gcc dot gnu.org
2012-11-19 14:56 ` [Bug libstdc++/55394] " paolo.carlini at oracle dot com
2014-09-19 11:04 ` redi at gcc dot gnu.org
2020-10-19 22:07 ` slyfox at gcc dot gnu.org
2020-10-20 7:52 ` slyfox at gcc dot gnu.org
2020-10-20 8:29 ` redi at gcc dot gnu.org
2020-10-20 23:00 ` slyfox at gcc dot gnu.org
2020-11-03 14:56 ` redi at gcc dot gnu.org
2020-11-03 18:45 ` cvs-commit at gcc dot gnu.org
2020-11-03 18:46 ` redi at gcc dot gnu.org
2020-11-03 18:46 ` redi at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).