This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [xen-4.0-testing test] 7147: regressions - FAIL

To: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [xen-4.0-testing test] 7147: regressions - FAIL
From: Keir Fraser <keir@xxxxxxx>
Date: Mon, 23 May 2011 17:16:25 +0100
Cc: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>, Olaf Hering <olaf@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 23 May 2011 09:17:51 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:user-agent:date:subject:from:to:cc :message-id:thread-topic:thread-index:in-reply-to:mime-version :content-type:content-transfer-encoding; bh=K7XEWNVFej6iUtv7ZIoibIAckYn1kKKfJ5ND/dAwxQ4=; b=HnVzh4F8PrJQABCPvlvJNkkYiV/dFOcvL2kCmHVL5OemG7RiMzjzAbbvpCuvHLfFAF ncAjON4kYyTfMPKYJwFJ2NICh5AjU6EfaD6YBqfvL1yIkPTuTojtz+nftMpmtMvrNINH wrcwb2WXCyBixFSiUA85nf0aN3qNlgdjonQq0=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=Zn1aEu6A+5NJ/LiowJXFwGEkfFUcuwIsJNVs8BtQJiYN7D/jciJG9qPLkTSGQZ/0CF QcNDWdCtTIhng4p1R0vJPcDxnQV49u0C+RkUqeDn1S+y5hspUNTA9YNEZY4XbnzZLCet ZuDtBC7E+CXaWpWFSyZjcGNnBF3wKmLk37ywY=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <CA00409B.2D9AF%keir@xxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcwZYQE5Am5T+VDkLUm6IuNqCfedSQAA8IEu
Thread-topic: [Xen-devel] [xen-4.0-testing test] 7147: regressions - FAIL
User-agent: Microsoft-Entourage/
On 23/05/2011 16:49, "Keir Fraser" <keir@xxxxxxx> wrote:

> On 23/05/2011 16:40, "Ian Jackson" <Ian.Jackson@xxxxxxxxxxxxx> wrote:
>> Keir Fraser writes ("Re: [Xen-devel] [xen-4.0-testing test] 7147: regressions
>> - FAIL"):
>>> Here's a nice short one that seems to work for me. It does rely on the
>>> compiler emitting the word 'unrecognized' iff the option under test is
>>> unrecognised. I strongly suspect this is a safe bet.
>> Sadly, some mad people run with LC_MESSAGES set to something other
>> than C which produces native-language error messages even from gcc.
> Well LC_ALL=C is easy to add.

Here is an updated version taking into account comments on- and off-list. To
be clear, its main advantages are brevity and that it strips out even
options that only cause harmless (but potentially annoying/crufting)
conditional compile warnings. Its main *disadvantage* is that it scrapes the
compiler's stdout/stderr, albeit for the option-under-test itself which
frankly should be a very safe bet.

 -- Keir

diff -r 0f670f5146c8 Config.mk
--- a/Config.mk Sat May 21 07:55:46 2011 +0100
+++ b/Config.mk Mon May 23 17:12:55 2011 +0100
@@ -71,9 +71,19 @@ PYTHON_PREFIX_ARG ?= --prefix="$(PREFIX)
 #  https://bugs.launchpad.net/ubuntu/+bug/362570
 # cc-option: Check if compiler supports first option, else fall back to
+# This is complicated by the fact that unrecognised -Wno-* options:
+#   (a) are ignored unless the compilation emits a warning; and
+#   (b) even then produce a warning rather than an error
+# To handle this we do a test compile, passing the option-under-test, on a
+# fragment that will always produce a warning (integer assigned to
+# We then grep for the option-under-test in the compiler's output, the
+# of which would indicate an "unrecognized command-line option"
 # Usage: cflags-y += $(call cc-option,$(CC),-march=winchip-c6,-march=i586)
-cc-option = $(shell if test -z "`$(1) $(2) -S -o /dev/null -xc \
-              /dev/null 2>&1`"; then echo "$(2)"; else echo "$(3)"; fi ;)
+cc-option = $(shell if test -z "`echo 'void*p=1;' | \
+              $(1) $(2) -S -o /dev/null -xc - 2>&1 | grep -- $(2)`"; \
+              then echo "$(2)"; else echo "$(3)"; fi ;)

>>> Unfortunately I can't
>>> see any way around grepping the output, since otherwise we can't distinguish
>>> the integer-assignment-to-pointer warning from the unrecognised-option
>>> warning.
>> We don't need to distinguish them.  We just need to know whether
>> passing the option works or not.  That's what my patch does.
> Ahhh... Is this because of a emitted-as-an-error-not-a-warning bug in Debian
> gcc, on top of the more general lazily-detected-unrecognised-Wno-option
> behaviour?
> Well, tbh I'd rather get rid of unsupported -Wno- options in general, not
> just where they are erroneously emitted as errors. Otherwise it will confuse
> everyone that each time they get a compile warning they also get extra bogus
> unrecognised option messages. That would be pretty crappy.
>  -- Keir
>> Ian.

Xen-devel mailing list