Hi,
I've noticed that g++ 4.9.1 behaves differently than 4.8.1 with
regards to (implicit) threading support. The 4.8.1 and 4.9.1 compilers
used were configured with identical options (*) to the configure
script (except --prefix) using --enable-threads=posix.
For the following test-case
#include <string>
#include <iostream>
int main() {
std::string test("test");
std::cout << test << std::endl;
}
invoking g++ -O3 test.cc -o test, the 'test' binary is compiled with
multi-threading support using 4.9.1 but not using 4.8.1, e.g. for the
libstdc++ pool allocator a mutex is locked when allocating memory for
the string in the test program above while no such locking is present
in the 'test' binary compiled with 4.8.1. (There is also a difference
in that there is a weak symbol __pthread_key_create in the binary
compiled with 4.9.1 but no such thing for the 4.8.1 case.)
As my application is single-threaded, I don't want to pay the
performance penalty of mutexes etc. Hence, my question is if it is
possible to explicitly request gcc to compile my application in
single-threaded mode.
I'm also curious about what the correct behaviour is -- I found some
PR:s in bugzilla that may be related, like 61144. To me, it seems like
the implicit way of figuring out whether to use locks or not is not a
robust solution as you might dlopen() a library that uses threads from
a single-threaded application and thereby risk data races.
Regards,
/Johan Alfredsson
(*) ./configure --enable-languages=c,c++,fortran
--enable-targets=x86_64-suse-linux,i686-suse-linux
--prefix=/usr/local/gcc/<version> --with-gnu-as
--with-as=/usr/local/binutils-2.23.2/bin/as --with-gnu-ld
--with-ld=/usr/local/binutils-2.23.2/bin/ld
--with-gmp=/usr/local/gmp-5.0.1 --with-mpfr=/usr/local/mpfr-3.0.0
--with-mpc=/usr/local/mpc-0.8.2 --enable-threads=posix --enable-shared
--enable-__cxa_atexit --enable-libstdcxx-allocator=pool
x86_64-suse-linux
