From mboxrd@z Thu Jan  1 00:00:00 1970
From: pbonzini@redhat.com (Paolo Bonzini)
Date: Mon, 15 Feb 2010 16:38:58 +0100
Subject: [ltt-dev] [PATCH 07/11] add uatomic_gcc.h,
 use it for default definitions
In-Reply-To: <20100215145520.GC13436@Krystal>
References: <1266081392-8732-1-git-send-email-pbonzini@redhat.com>
	<1266081392-8732-8-git-send-email-pbonzini@redhat.com>
	<20100214144525.GH5871@Krystal> <4B79004C.7090407@redhat.com>
	<20100215145520.GC13436@Krystal>
Message-ID: <4B796A92.9030308@redhat.com>

On 02/15/2010 03:55 PM, Mathieu Desnoyers wrote:
> * Paolo Bonzini (pbonzini at redhat.com) wrote:
>> On 02/14/2010 03:45 PM, Mathieu Desnoyers wrote:
>>>>>   - if cmpxchg is present, use it to implement xchg and add_return;
>>>
>>> Not sure I understand this comment, and not sure it matches the patch.
>>> x86 has xchg() which is faster than a cmpxchg-based fallback, and you
>>> seem to leave the code as-is. Can you elaborate ?
>>
>> Each per-architecture file can provide its own xchg and add_return which
>> are then used instead of the defaults.  For example, x86 uses entirely
>> custom code, and PPC uses its own implementation of xchg (since it is
>> also much faster than cmpxchg on ll/sc machines).
>
> OK. Please update the changelog comment with the information above.

Will do.

>>> Starting from which gcc versions does these __sync_* builtins work ?
>>> (question applies for the builtin memory barrier too).
>>
>> The builtins appeared in 4.2, but they were backported to 4.1 by some
>> vendors.
>>
>> Note that on SPARC64 and S390 they were already needed to build the
>> library because the tests used them.
>
> For __builtin_trap() I suspect. This could be changed if needed.

No, for api_gcc.h.

>> After this, a client that is interested in using an older GCC can thus
>> use _LGPL_SOURCE if it finds a compiler that is not new enough.  I can
>> also make this automatic if you prefer.
>
> Hrm, that's a problem. We cannot just say "hey, update the test systems
> you are working with to newer compilers" to people who often only borrow
> these systems and have to deal with the very often deprecated toolchains
> available. This is the case for a 64-core POWER5+ we are doing testing
> on: we're stuck with an old gcc.

Ok, I won't update PPC then.

Paolo