public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Johan Alfredsson <sduvan.gcc@gmail.com>
To: gcc-help@gcc.gnu.org
Subject: Fwd: Compiling for single-threaded use (implicit threading support difference in 4.9.1 vs. 4.8.1)
Date: Tue, 14 Oct 2014 17:29:00 -0000	[thread overview]
Message-ID: <CA+pZiO77AOuMR671vKsE4un1cspRkKAJaesD_Xe5KXMPgMY1YA@mail.gmail.com> (raw)
In-Reply-To: <CA+pZiO6XXzJ7y-qu_F167ruqRwvZc8Sxnj4EAH2rXZwiODPbyw@mail.gmail.com>

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

       reply	other threads:[~2014-10-14 17:29 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CA+pZiO6XXzJ7y-qu_F167ruqRwvZc8Sxnj4EAH2rXZwiODPbyw@mail.gmail.com>
2014-10-14 17:29 ` Johan Alfredsson [this message]
2014-10-15  9:14   ` Jonathan Wakely
2014-10-15 10:44     ` Jonathan Wakely
2014-10-16 14:43       ` Johan Alfredsson
2014-10-16 15:01         ` Marc Glisse
2014-10-16 16:06         ` Jonathan Wakely
2014-10-16 17:51           ` Johan Alfredsson
2014-10-15 11:40     ` Marc Glisse
2014-10-15 23:15       ` leon zadorin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CA+pZiO77AOuMR671vKsE4un1cspRkKAJaesD_Xe5KXMPgMY1YA@mail.gmail.com \
    --to=sduvan.gcc@gmail.com \
    --cc=gcc-help@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).