Il 04/07/2013 18:27, Jan Kiszka ha scritto:
> This workaround causes troubles here with gcc-4.5.1:
>
> In file included from /data/qemu/include/exec/memory.h:29:0,
> from /data/qemu/include/exec/ioport.h:29,
> from /data/qemu/include/hw/hw.h:11,
>
On 2013-07-01 12:14, Paolo Bonzini wrote:
> Il 01/07/2013 11:54, Peter Maydell ha scritto:
>> On 1 July 2013 10:35, Stefan Hajnoczi wrote:
>>> From: Paolo Bonzini
>>>
>>> Fast TLS is not available on some platforms, but it is always nice to
>>> use it. This wrapper implementation falls back to p
Il 01/07/2013 22:30, Richard Henderson ha scritto:
> On 07/01/2013 12:25 PM, Peter Maydell wrote:
>> Does any OS have a __thread which compiles but is broken, or can
>> we just have a configure test for this? That would let MacOSX+clang
>> use __thread.
>
> I suspect that this will work. Some tar
On Mon, Jul 01, 2013 at 02:52:08PM -0400, Ed Maste wrote:
> On 1 July 2013 05:35, Stefan Hajnoczi wrote:
> > From: Paolo Bonzini
> >
> > Fast TLS is not available on some platforms, but it is always nice to
> > use it. This wrapper implementation falls back to pthread_get/setspecific
> > on POS
On 07/01/2013 12:25 PM, Peter Maydell wrote:
> Does any OS have a __thread which compiles but is broken, or can
> we just have a configure test for this? That would let MacOSX+clang
> use __thread.
I suspect that this will work. Some targets may succeed in using gcc's
"emutls" path, which while s
On 1 July 2013 15:25, Peter Maydell wrote:
> Does any OS have a __thread which compiles but is broken, or can
> we just have a configure test for this? That would let MacOSX+clang
> use __thread.
I believe this was recently the case on NetBSD - code with __thread
would build, but fail at run time
On 1 July 2013 19:52, Ed Maste wrote:
> The most recent version of this patch posted by Paolo that I see has:
>
> +#if defined(__linux__) || defined(__FreeBSD__)
> +#define DECLARE_TLS(type, x) \
>
> while this one has only __linux__. Do you mind picking up that
> change, if t
On 1 July 2013 05:35, Stefan Hajnoczi wrote:
> From: Paolo Bonzini
>
> Fast TLS is not available on some platforms, but it is always nice to
> use it. This wrapper implementation falls back to pthread_get/setspecific
> on POSIX systems that lack __thread, but uses the dynamic linker's TLS
> sup
On Mon, Jul 01, 2013 at 10:54:56AM +0100, Peter Maydell wrote:
> On 1 July 2013 10:35, Stefan Hajnoczi wrote:
> > From: Paolo Bonzini
> >
> > Fast TLS is not available on some platforms, but it is always nice to
> > use it. This wrapper implementation falls back to pthread_get/setspecific
> > on
Il 01/07/2013 11:54, Peter Maydell ha scritto:
> On 1 July 2013 10:35, Stefan Hajnoczi wrote:
>> From: Paolo Bonzini
>>
>> Fast TLS is not available on some platforms, but it is always nice to
>> use it. This wrapper implementation falls back to pthread_get/setspecific
>> on POSIX systems that l
On 1 July 2013 10:35, Stefan Hajnoczi wrote:
> From: Paolo Bonzini
>
> Fast TLS is not available on some platforms, but it is always nice to
> use it. This wrapper implementation falls back to pthread_get/setspecific
> on POSIX systems that lack __thread, but uses the dynamic linker's TLS
> supp
From: Paolo Bonzini
Fast TLS is not available on some platforms, but it is always nice to
use it. This wrapper implementation falls back to pthread_get/setspecific
on POSIX systems that lack __thread, but uses the dynamic linker's TLS
support on Linux and Windows.
The user shall call tls_alloc_
12 matches
Mail list logo
