[Bug libstdc++/89740] reading from cin & writing to cout sync_with_stdio(false) has race conditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89740 --- Comment #4 from bert hubert --- I did a longer writeup here, where I tentatively conclude this is not a bug, just highly unfortunate: https://ds9a.nl/articles/posts/iostreams-unexpected/
[Bug libstdc++/89740] reading from cin & writing to cout sync_with_stdio(false) has race conditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89740 --- Comment #3 from bert hubert --- Note that in https://stackoverflow.com/questions/12605725/basic-thread-locking-in-c11/12608911#12608911 we read the calling flush() from two threads at the same time is not legal if the streams are unsynchronised. The tie() may be causing this unexpectedly.
[Bug libstdc++/89740] reading from cin & writing to cout sync_with_stdio(false) has race conditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89740 --- Comment #2 from bert hubert --- Created attachment 45982 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45982=edit reproduction that actually shows the bug This is the version of the reproduction that exhibits the problem. The other version had the "fix" included, cin.tie(nullptr), and thus did not have the problem.
[Bug libstdc++/89740] reading from cin & writing to cout sync_with_stdio(false) has race conditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89740
--- Comment #1 from bert hubert ---
Comment on attachment 45981
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45981
a small reproduction for this bug.
>#include
>#include
>#include
>#include
>
>using namespace std;
>
>void theThread()
>{
> for(int counter = 0 ;; ++counter) {
>usleep(25);
>cout << "Hi "<< counter << endl;
> }
>}
>
>int main()
>{
> std::ios_base::sync_with_stdio(false);
> // cin.tie(nullptr);
>
> string line;
> thread t(theThread);
> while(getline(cin, line))
>;
>}
[Bug libstdc++/89740] New: reading from cin & writing to cout sync_with_stdio(false) has race conditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89740 Bug ID: 89740 Summary: reading from cin & writing to cout sync_with_stdio(false) has race conditions Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: ahu at ds9a dot nl Target Milestone: --- Created attachment 45981 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45981=edit a small reproduction for this bug. Reading lots of lines from cin in main() and writing to cout from an additional thread usually works fine. However, when doing sync_with_stdio(false), duplicate output appears on the terminal. No C stdio is performed by the program. No two threads are attempting simultaneous output. Output of attached 25 line reproduction: $ yes | ./repro HHi 0 Hi Hi 1 Hi Hi 2 Verification with strace shows that the main thread is doing writes to file descriptor 1 that are also happening in the output thread. The problem goes away when setting 'cin.tie(nullptr)' or when removing sync_with_stdio(false): $ yes | ./repro Hi 0 Hi 1 Hi 2 A trivial reproduction is attached. The hypothesis is that cin/cout tying is somehow relying on sync_with_stdio to prevent race conditions. Bug #70276 touches on slightly similar material, but it looks like something different.
[Bug c++/66971] thread_local with external linkage and constructor cannot be compiled correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66971 bert hubert changed: What|Removed |Added CC||ahu at ds9a dot nl --- Comment #1 from bert hubert --- I can confirm this issue on the stock Ubuntu Xenial g++ which describes itself as gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) In addition, PowerDNS recursor from git has run into this problem too. This workaround helps: https://github.com/PowerDNS/pdns/pull/5350/commits/f165a1f4fc8ebd9b7ca060e4a332a687c4d46510 Other versions of g++ do not show this problem. I have not yet verified if this bug shows in g++ 5.4.0 without Ubuntu patches.
[Bug c++/59079] New: a lambda with a parameter that depends on vector::value_type typedef leads to compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59079
Bug ID: 59079
Summary: a lambda with a parameter that depends on
vector::value_type typedef leads to compiler error
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ahu at ds9a dot nl
Created attachment 31194
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31194action=edit
small test file that fails to compile
Thanks for the c++2011 support, it makes me happy! However, the following fails
to compile in g++ 4.6.3 and 4.8.3 (at least), and I think it is valid c++2011.
#include vector
#include functional
templatetypename T
void buildvect(const T vect,
std::functiondouble(typename T::value_type) yTransform)
{}
int main()
{
std::vectorint blah{1,2,3,4};
buildvect(blah, [](int a) { return 1.0*a;});
}
Delivers:
t.cc: In function ‘int main()’:
t.cc:12:45: error: no matching function for call to
‘buildvect(std::vectorint, main()::__lambda0)’
buildvect(blah, [](int a) { return 1.0*a;});
^
t.cc:12:45: note: candidate is:
t.cc:5:6: note: templateclass T void buildvect(const T,
std::functiondouble(typename T::value_type))
void buildvect(const T vect,
^
t.cc:5:6: note: template argument deduction/substitution failed:
t.cc:12:45: note: ‘main()::__lambda0’ is not derived from
‘std::functiondouble(typename T::value_type)’
buildvect(blah, [](int a) { return 1.0*a;});
^
Does compile in clang 3.3, does compile if T::value_type is replaced by int.
Thanks!
[Bug c++/59079] a lambda with a parameter that depends on vector::value_type typedef leads to compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59079 bert hubert ahu at ds9a dot nl changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from bert hubert ahu at ds9a dot nl --- Turns out that in trunk, this issue is fixed. Apologies for not testing against trunk first.
[Bug libstdc++/41267] New: vector::resize() from an empty vector calls memmove for 0 bytes, wasting a lot of cpu time in a production PowerDNS
This sequence makes no less than 2 calls memmoving 0 bytes:
vectorchar content;
content.resize(12);
From *0x0 no less!
On a 64 bit system, the effect is far less pronounced (25%), but on 32 bits,
this loop takes 2.3 seconds on a vanilla g++;
for(int n=0; n 1000; ++n) {
vectorchar content;
content.resize(12);
}
But if we add:
if(__last != __first)
before the __builtin_memmove on line 377 of stl_algobase.h, it takes 0.9
seconds!
On a real 32 bit benchmark of PowerDNS, this single line gave a 9% performance
boost.
Seems worthwhile. Andrew Pinski suggested _M_fill_insert may need to do this
check instead.
#0 *__GI_memmove (dest=0x8b8dc18, src=0x0, len=0) at memmove.c:47
#1 0x080557f0 in std::__copy_movefalse, true,
std::random_access_iterator_tag::__copy_munsigned char (__first=0x0,
__last=0x0,
__result=0x8b8dc18 ) at /usr/include/c++/4.3/bits/stl_algobase.h:378
#2 0x08055a3f in std::__copy_move_afalse, unsigned char*, unsigned char*
(__first=0x0, __last=0x0, __result=0x8b8dc18 )
at /usr/include/c++/4.3/bits/stl_algobase.h:397
#3 0x08055a7e in std::__copy_move_a2false, unsigned char*, unsigned char*
(__first=0x0, __last=0x0, __result=0x8b8dc18 )
at /usr/include/c++/4.3/bits/stl_algobase.h:436
#4 0x08055ab9 in std::copyunsigned char*, unsigned char* (__first=0x0,
__last=0x0, __result=0x8b8dc18 )
at /usr/include/c++/4.3/bits/stl_algobase.h:467
#5 0x08055ade in std::__uninitialized_copytrue::uninitialized_copyunsigned
char*, unsigned char* (__first=0x0, __last=0x0,
__result=0x8b8dc18 ) at /usr/include/c++/4.3/bits/stl_uninitialized.h:98
#6 0x08055aff in std::uninitialized_copyunsigned char*, unsigned char*
(__first=0x0, __last=0x0, __result=0x8b8dc18 )
at /usr/include/c++/4.3/bits/stl_uninitialized.h:122
#7 0x08055b20 in std::__uninitialized_copy_aunsigned char*, unsigned char*,
unsigned char (__first=0x0, __last=0x0, __result=0x8b8dc18 )
at /usr/include/c++/4.3/bits/stl_uninitialized.h:262
#8 0x08055b48 in std::__uninitialized_move_aunsigned char*, unsigned char*,
std::allocatorunsigned char (__first=0x0, __last=0x0,
__result=0x8b8dc18 , __all...@0xff815c2c) at
/usr/include/c++/4.3/bits/stl_uninitialized.h:272
#9 0x0805af27 in std::vectorunsigned char, std::allocatorunsigned char
::_M_fill_insert (this=0xff815c2c, __position={_M_current = 0x0},
__n=12, _...@0xff815ab0) at /usr/include/c++/4.3/bits/vector.tcc:399
#10 0x0805b034 in std::vectorunsigned char, std::allocatorunsigned char
::insert (this=0xff815c2c, __position={_M_current = 0x0}, __n=12,
_...@0xff815ab0) at /usr/include/c++/4.3/bits/stl_vector.h:792
#11 0x0805b0b7 in std::vectorunsigned char, std::allocatorunsigned char
::resize (this=0xff815c2c, __new_size=12, __x=0 '\0')
at /usr/include/c++/4.3/bits/stl_vector.h:509
#12 0x08083057 in DNSPacketWriter (this=0xff815b9c, conte...@0xff815c2c,
qna...@0xff815c04, qtype=6, qclass=1, opcode=0 '\0') at dnswriter.cc:21
#13 0x0804d449 in makeRootReferral () at speedtest.cc:259
#14 0x080601e9 in RootRefTest::operator() (this=0xff815e87) at speedtest.cc:329
#15 0x080602cc in doRunRootRefTest (c...@0xff815e87, mseconds=100) at
speedtest.cc:37
#16 0x0804da3e in main () at speedtest.cc:443
--
Summary: vector::resize() from an empty vector calls memmove
for 0 bytes, wasting a lot of cpu time in a production
PowerDNS
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ahu at ds9a dot nl
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41267
[Bug c++/26633] New: Minimal c++ program using threads and exceptions crashes when compiled statically
The below does not crash with g++ 4.0.2, nor when removing -static:
(see also http://ds9a.nl/minimal.cc.txt)
#include stdexcept
/*
compiled with g++ 4.1.0 (g++ minimal.cc -o minimal -static -pthread), on
Ubuntu Breezy:
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.1.0/configure --prefix=/opt/gcc-4.1/
--enable-shared --enable-__cxa_atexit --enable-libstdcxx-debug
Thread model: posix
gcc version 4.1.0
Crash:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16386 (LWP 8238)]
__gnu_internal::get_global () at
../../../../gcc-4.1.0/libstdc++-v3/libsupc++/eh_globals.cc:58
58get_global() throw()
Current language: auto; currently c++
(gdb) bt
#0 __gnu_internal::get_global () at
../../../../gcc-4.1.0/libstdc++-v3/libsupc++/eh_globals.cc:58
#1 0x0804c767 in __cxa_get_globals () at
../../../../gcc-4.1.0/libstdc++-v3/libsupc++/eh_globals.cc:71
#2 0x0804c33f in __cxa_allocate_exception (thrown_size=8)
at ../../../../gcc-4.1.0/libstdc++-v3/libsupc++/eh_alloc.cc:154
#3 0x08048298 in doStuff ()
#4 0x080577af in pthread_start_thread (arg=0xaf5ffbe0) at manager.c:310
#5 0x08057827 in pthread_start_thread_event (arg=0xaf5ffbe0) at manager.c:334
#6 0x08069d9a in clone ()
*/
void *doStuff(void *)
try
{
throw std::runtime_error(boe);
}
catch(std::exception e)
{}
int main()
{
pthread_t tid;
pthread_create(tid, 0, doStuff,0);
void *result;
pthread_join(tid, result);
}
--
Summary: Minimal c++ program using threads and exceptions crashes
when compiled statically
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ahu at ds9a dot nl
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26633
[Bug other/26633] [4.1/4.2 Regression] Minimal c++ program using threads and exceptions crashes when compiled statically
--- Comment #3 from ahu at ds9a dot nl 2006-03-10 17:54 ---
Subject: Re: [4.1/4.2 Regression] Minimal c++ program using threads and
exceptions crashes when compiled statically
Sure this is (exactly) related? I tried to pull in some of the symbols that
might be missing to no avail.
Interestingly, the problem does not appear on my x86-64!
Also:
Starting program: /home/ahu/programming-new/exploit/minimal
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 11300)]
[New Thread 32769 (LWP 11301)]
[New Thread 16386 (LWP 11302)]
[Switching to Thread 16386 (LWP 11302)]
Breakpoint 1, __cxa_allocate_exception (thrown_size=8)
at ../../../../gcc-4.1.0/libstdc++-v3/libsupc++/eh_alloc.cc:115
115 thrown_size += sizeof (__cxa_exception);
(gdb) step
116 ret = malloc (thrown_size);
(gdb) print thrown_size
$1 = 88
(gdb) step
118 if (! ret)
(gdb) print ret
$2 = (void *) 0x8115a60
(gdb) step
116 ret = malloc (thrown_size);
(gdb) step
118 if (! ret)
(gdb)
154 __cxa_eh_globals *globals = __cxa_get_globals ();
(gdb)
__cxa_get_globals () at
../../../../gcc-4.1.0/libstdc++-v3/libsupc++/eh_globals.cc:71
71 { return __gnu_internal::get_global(); }
(gdb)
__gnu_internal::get_global () at
../../../../gcc-4.1.0/libstdc++-v3/libsupc++/eh_globals.cc:58
58get_global() throw()
(gdb)
Program received signal SIGSEGV, Segmentation fault.
__gnu_internal::get_global () at
../../../../gcc-4.1.0/libstdc++-v3/libsupc++/eh_globals.cc:58
58get_global() throw()
On Fri, Mar 10, 2006 at 04:55:41PM -, pinskia at gcc dot gnu dot org wrote:
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-10 16:55
---
Some information about this bug in both the libstdc++ library and the
libgfortran library on the mainline:
http://gcc.gnu.org/ml/gcc/2006-03/msg00248.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26633
--- You are receiving this mail because: ---
You reported the bug, or are watching the reporter.
!DSPAM:4411af8b239412042891523!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26633
[Bug other/26633] [4.1/4.2 Regression] Minimal c++ program using threads and exceptions crashes when compiled statically
--- Comment #4 from ahu at ds9a dot nl 2006-03-10 20:44 ---
Andrew Pinski tells me this is a glibc TLS bug and that it should be reported
to Ubuntu, which I have done here:
https://launchpad.net/distros/ubuntu/+source/glibc/+bug/34362
The reduced testcase is:
#include pthread.h
void *doStuff(void *ignore)
{
static __thread int a; // crashes HERE
return (void*) a;
}
int main()
{
pthread_t tid;
pthread_create(tid, 0, doStuff,0);
void *result;
pthread_join(tid, result);
}
--
ahu at ds9a dot nl changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26633
[Bug tree-optimization/26570] New: -fprofile-generate -fprofile-use cause memory corruption immediately
This is reported: recursor_cache.hh:58: warning: comparison between signed and unsigned integer expressions syncres.cc: In function â(static destructors for syncres.cc)â: syncres.cc:649: note: file syncres.gcda not found, execution counts estimated *** glibc detected *** corrupted double-linked list: 0xa7fba938 *** When compiling only with -fprofile-generate, no errors get emitted. When adding -fprofile-use later on when the program has been run once, the following happens: if g++ -DHAVE_CONFIG_H -I. -I. -I.. -Ibackends/bind -pthread -DSYSCONFDIR=\/usr/local/etc\ -DLIBDIR=\/usr/local/lib\ -DLOCALSTATEDIR=\/var/run\ -Ibackends/bind -D_GNU_SOURCE -Wall -O2 -fprofile-generate -fprofile-use -MT syncres.o -MD -MP -MF .deps/syncres.Tpo -c -o syncres.o syncres.cc; \ then mv -f .deps/syncres.Tpo .deps/syncres.Po; else rm -f .deps/syncres.Tpo; exit 1; fi recursor_cache.hh: In member function âbool MemRecursorCache::predicate::operator()(const MemRecursorCache::StoredRecord) constâ: recursor_cache.hh:58: warning: comparison between signed and unsigned integer expressions *** glibc detected *** corrupted double-linked list: 0xa7f55938 *** syncres.cc: In function â_EuclideanRingElement std::__gcd(_EuclideanRingElement, _EuclideanRingElement) [with _EuclideanRingElement = int]â: syncres.cc:649: internal compiler error: Aborted Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. make: *** [syncres.o] Error 1 To repeat, check out the latest revision of PowerDNS as described on http://wiki.powerdns.com, run ./configure, cd pdns, edit CXXFLAGS in Makefile so it includes -fprofile-generate and/or -fprofile-use, then run 'make pdns_recursor'. Error should appear immediately. Confirmed on Ubuntu Breezy, FreeBSD 6.0, Debian Sid crosscompiling to x86_64. -- Summary: -fprofile-generate -fprofile-use cause memory corruption immediately Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ahu at ds9a dot nl GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26570
[Bug gcov/profile/26570] -fprofile-generate -fprofile-use cause memory corruption immediately
--- Comment #3 from ahu at ds9a dot nl 2006-03-05 23:42 --- Thanks Nicholas, I can run the command you suggest without errors (I saved the file as exploit.cc). However, if I compile first with -fprofile-generate, then run it once, and then add -fprofile-use, it reports: $ g++ -O2 -fprofile-use -fprofile-generate exploit.cc -o exploit *** glibc detected *** double free or corruption (fasttop): 0x085c7e78 *** exploit.cc: In function â_ForwardIterator2 std::swap_ranges(_ForwardIterator1, _ForwardIterator1, _ForwardIterator2) [with _ForwardIterator1 = int*, _ForwardIterator2 = int*]â: exploit.cc:14: internal compiler error: Aborted Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. This w/o any profiling information present: [EMAIL PROTECTED]:~/work/pdns/pdns/pdns$ rm exploit.gc* [EMAIL PROTECTED]:~/work/pdns/pdns/pdns$ g++ -O2 -fprofile-use -fprofile-generate exploit.cc -o exploit exploit.cc: In function âvoid std::iter_swap(_ForwardIterator1, _ForwardIterator2) [with _ForwardIterator1 = int*, _ForwardIterator2 = int*]â: exploit.cc:14: note: file exploit.gcda not found, execution counts estimated *** glibc detected *** double free or corruption (fasttop): 0x085f2438 *** exploit.cc: In function â_ForwardIterator2 std::swap_ranges(_ForwardIterator1, _ForwardIterator1, _ForwardIterator2) [with _ForwardIterator1 = int*, _ForwardIterator2 = int*]â: exploit.cc:14: internal compiler error: Aborted Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26570
[Bug gcov/profile/26570] [4.1/4.2 Regression] -fprofile-generate -fprofile-use cause memory corruption immediately
--- Comment #7 from ahu at ds9a dot nl 2006-03-06 00:10 --- The crasher bugs go away from release 4.1.0 when never running with -fprofile-use and -fprofile-generate simultaneously. There is another 'checksum mismatch' issue with PowerDNS: base64.cc: In function âcharunnamed::B64Encode1(unsigned char)â: base64.cc:220: error: coverage mismatch for function â_ZN38_GLOBAL__N_base64.cc__B36B9A3210B64Encode1Ehâ while reading counter âarcsâ base64.cc:220: error: checksum is 913e4cf0 instead of e0c8a426 base64.cc: In function âcharunnamed::B64Decode1(char)â: base64.cc:220: error: coverage mismatch for function â_ZN38_GLOBAL__N_base64.cc__B36B9A3210B64Decode1Ecâ while reading counter âarcsâ base64.cc:220: error: checksum is 93e2f130 instead of e21419e6 These go away when I delete the relevant .gc* files. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26570
[Bug libstdc++/24704] __gnu_cxx::__exchange_and_add is called even for single threaded applications
--- Comment #10 from ahu at ds9a dot nl 2005-11-08 10:15 --- An easy solution might be to check for __gthread_active_p() in bits/basic_string before calling __exchange_and_add, and to do this locally and non-atomically otherwise. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24704
[Bug libstdc++/24704] New: __gnu_cxx::__exchange_and_add is out of line and called even for single threaded applications using std::string
__gnu_cxx::__exchange_and_add shows up in profiles of the PowerDNS recursor, which is single threaded. I'm somewhat amazed this is an out-of-line function (there are 40 cycles to be gained by inlining it, and this function gets called a lot), but I'm worried more about the 1000 cycle overhead even in a single-threaded program! I think it would be good to teach std::string to use a non-atomic exchange_and_add (or even just 'add') for non-REENTRANT applications, plus it would be good to be able to inline the function, but I understand this is of far smaller importance. The code exhibiting prominent profiled use of __gnu_cxx::__exchange_and_add can be found via the repository described on http://wiki.powerdn.somc. Thanks! -- Summary: __gnu_cxx::__exchange_and_add is out of line and called even for single threaded applications using std::string Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ahu at ds9a dot nl GCC build triplet: i486-linux-gnu GCC host triplet: i486-linux-gnu GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24704
[Bug libstdc++/24704] __gnu_cxx::__exchange_and_add is out of line and called even for single threaded applications using std::string
--- Comment #1 from ahu at ds9a dot nl 2005-11-07 12:39 --- that would be http://wiki.powerdns.com - not sure how I mistyped that. Also, the application in question is rather string-happy, which is probably why the exchange_and_add thing shows up so much. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24704
[Bug libstdc++/24704] __gnu_cxx::__exchange_and_add is out of line and called even for single threaded applications using std::string
--- Comment #3 from ahu at ds9a dot nl 2005-11-07 17:00 --- I've now verified that even when the entire compiler is compiled with --enable-threads=single, the resulting libstdc++ does the full 'lock; xadd' thing in __exchange_and_add, which I consider a bug (and more importantly, so does pinskia). -- ahu at ds9a dot nl changed: What|Removed |Added Severity|enhancement |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24704
