From mboxrd@z Thu Jan  1 00:00:00 1970
From: pbonzini@redhat.com (Paolo Bonzini)
Date: Mon, 15 Feb 2010 17:55:54 +0100
Subject: [ltt-dev] [PATCH 07/11] add uatomic_gcc.h,
 use it for default definitions
In-Reply-To: <20100215165154.GA25040@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> <4B796A92.9030308@redhat.com>
	<20100215162354.GA21995@Krystal> <4B79780E.6060104@redhat.com>
	<20100215165154.GA25040@Krystal>
Message-ID: <4B797C9A.9090804@redhat.com>

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. :-)

Paolo