[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • To: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
  • 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
  • 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=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcwZYQE5Am5T+VDkLUm6IuNqCfedSQAA8IEu
  • Thread-topic: [Xen-devel] [xen-4.0-testing test] 7147: regressions - FAIL

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.