From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH] xen: Don't use -nostdinc flags with CLANG Date: Thu, 13 Feb 2014 11:49:29 +0000 Message-ID: <52FCB149.4050305@eu.citrix.com> References: <1392074974-1488-1-git-send-email-julien.grall@linaro.org> <20140211085317.GB92054@deinos.phlegethon.org> <52FA17E3.9070105@linaro.org> <20140211123515.GD97288@deinos.phlegethon.org> <52FA1945.8010400@linaro.org> <20140211125928.GE97288@deinos.phlegethon.org> <52FA23B4.5060203@linaro.org> <20140211135926.GB10482@deinos.phlegethon.org> <52FA328C.4000103@linaro.org> <20140211143346.GE10482@deinos.phlegethon.org> <20140213112419.GB82703@deinos.phlegethon.org> <52FCB099.7000902@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WDunX-0000Fr-H0 for xen-devel@lists.xenproject.org; Thu, 13 Feb 2014 11:49:43 +0000 In-Reply-To: <52FCB099.7000902@eu.citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Tim Deegan , george.dunlap@citrix.com Cc: xen-devel@lists.xenproject.org, Julien Grall , keir@xen.org, Ian.Jackson@eu.citrix.com, ian.campbell@citrix.com List-Id: xen-devel@lists.xenproject.org On 02/13/2014 11:46 AM, George Dunlap wrote: > On 02/13/2014 11:24 AM, Tim Deegan wrote: >> George: ping. >> >> At 15:33 +0100 on 11 Feb (1392129226), Tim Deegan wrote: >>> At 14:24 +0000 on 11 Feb (1392125052), Julien Grall wrote: >>>> If it's possible I'd like this patch goes in Xen 4.4 to fix build with >>>> official version of clang (until 3.4). >>>> >>>> Clang 3.5 is still under development, so I don't think it's >>>> important to >>>> have support for it in Xen 4.4. >>> Fair enough. In that case it needs a release ack from George. It: >>> - fixes a compile issue on some version s of clang; >>> - might cause a regression with other compilers, but the regression >>> is likely to be obvious (i.e. a compile-time failure). > > So the main risk would be if stgarg.h contained something like the > "__GNUC_PREREQ__(4, 5)" #ifdef-ery that we missed. Sorry, realized the grammar was ambiguous here. For the record, I meant, the risk would be a system where the stdarg.h contained something of that type that our own copy didn't. -G