This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [patch] libstdc++/61841 odr-use pthread_create in std::thread constructor
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Jonathan Wakely <jwakely at redhat dot com>
- Cc: libstdc++ at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org, Matthias Klose <doko at ubuntu dot com>
- Date: Wed, 13 Aug 2014 21:06:21 +0200
- Subject: Re: [patch] libstdc++/61841 odr-use pthread_create in std::thread constructor
- Authentication-results: sourceware.org; auth=none
- References: <20140813184057 dot GF6927 at redhat dot com> <20140813184759 dot GY1784 at tucnak dot redhat dot com> <20140813190221 dot GG6927 at redhat dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Wed, Aug 13, 2014 at 08:02:22PM +0100, Jonathan Wakely wrote:
> On 13/08/14 20:47 +0200, Jakub Jelinek wrote:
> >On Wed, Aug 13, 2014 at 07:40:57PM +0100, Jonathan Wakely wrote:
> >>This should fix the Hurd bug in PR61841 as well as the problem
> >>described in https://gcc.gnu.org/ml/gcc/2013-09/msg00196.html
> >>
> >>Tested x86_64-linux, committed to trunk.
> >>
> >>This is not suitable for the branches as it requires a new exported
> >>symbol. We could maybe just add some other odr-use of pthread_create,
> >>but it would probably be optimized away anyway.
> >
> >E.g. __asm ("" : : "r" (&pthread_create)); would not be optimized away.
>
> Good idea - thanks. Do we want to do that instead of adding the new
> exported function I've added on trunk?
Dunno, you're the maintainer ;) On one side, asm has the disadvantage of
being a scheduling barrier (because it is implicitly volatile), on the other
side, we are talking about pthread_create call, so perhaps a few lost ticks
is nothing compared to that.
Jakub