From mboxrd@z Thu Jan  1 00:00:00 1970
From: compudj@krystal.dyndns.org (Mathieu Desnoyers)
Date: Mon, 15 Feb 2010 12:13:09 -0500
Subject: [ltt-dev] [PATCH 07/11] add uatomic_gcc.h,
	use it for default	definitions
In-Reply-To: <4B797C9A.9090804@redhat.com>
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> <4B796A92.9030308@redhat.com>
	<20100215162354.GA21995@Krystal> <4B79780E.6060104@redhat.com>
	<20100215165154.GA25040@Krystal> <4B797C9A.9090804@redhat.com>
Message-ID: <20100215171309.GA28647@Krystal>

* Paolo Bonzini (pbonzini at redhat.com) wrote:
> On 02/15/2010 05:51 PM, Mathieu Desnoyers wrote:
>>>>
>>>> I was thinking of doing (3) with the additional twist that S390
>>>> would count as a "new architecture".  On it, GCC is providing
>>>> really everything that is needed and furthermore, unlike PPC,
>>>> your testers surely have a new-enough GCC because they're using
>>>> api_gcc.h.
>> Hrm. As things stand, I would recommend plainly going with (3),
>> using gcc builtins only for the new architectures which are not
>> supported at the moment, being ready to merge compatibility code for
>> these architectures if we see the need for it at some point.
>>
>> From this point of view, moving s390 from the custom operations to
>> gcc builtins seems like a step backward.
>
> Fine, will adjust.
>
>> I'd prefer to look into the api_gcc.h issues and fix those so we can
>> ensure that sparc64 and s390 are OK with older gcc.
>
> Requiring GCC for testing purposes doesn't seem too bad, but I guess  
> this latest paragraph was a kind of "patches are welcome" thing. :-)

Exactly ;)

Thanks,

Mathieu

>
> Paolo
>

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68