flight 7147 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/7147/
Regressions :-(
Tests which did not succeed and are blocking:
build-amd64-oldkern 4 xen-build fail REGR. vs. 7136
build-amd64 4 xen-build fail REGR. vs. 7136
build-i386-oldkern 4 xen-build fail REGR. vs. 7136
build-i386 4 xen-build fail REGR. vs. 7136
Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a
test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a
test-amd64-amd64-win 1 xen-build-check(1) blocked n/a
test-amd64-amd64-xl-win 1 xen-build-check(1) blocked n/a
test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a
test-amd64-i386-pair 1 xen-build-check(1) blocked n/a
test-amd64-i386-pv 1 xen-build-check(1) blocked n/a
test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a
test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a
test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked n/a
test-amd64-i386-win 1 xen-build-check(1) blocked n/a
test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a
test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a
test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a
test-amd64-i386-xl 1 xen-build-check(1) blocked n/a
test-amd64-xcpkern-i386-pair 1 xen-build-check(1) blocked n/a
test-amd64-xcpkern-i386-pv 1 xen-build-check(1) blocked n/a
test-amd64-xcpkern-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a
test-amd64-xcpkern-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a
test-amd64-xcpkern-i386-win 1 xen-build-check(1) blocked n/a
test-amd64-xcpkern-i386-xl-credit2 1 xen-build-check(1) blocked n/a
test-amd64-xcpkern-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a
test-amd64-xcpkern-i386-xl-win 1 xen-build-check(1) blocked n/a
test-amd64-xcpkern-i386-xl 1 xen-build-check(1) blocked n/a
test-i386-i386-pair 1 xen-build-check(1) blocked n/a
test-i386-i386-pv 1 xen-build-check(1) blocked n/a
test-i386-i386-win 1 xen-build-check(1) blocked n/a
test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a
test-i386-i386-xl 1 xen-build-check(1) blocked n/a
test-i386-xcpkern-i386-pair 1 xen-build-check(1) blocked n/a
test-i386-xcpkern-i386-pv 1 xen-build-check(1) blocked n/a
test-i386-xcpkern-i386-win 1 xen-build-check(1) blocked n/a
test-i386-xcpkern-i386-xl 1 xen-build-check(1) blocked n/a
version targeted for testing:
xen 9f8f91033546
baseline version:
xen c6034ee9b46e
------------------------------------------------------------
People who touched revisions under test:
Jan Beulich <jbeulich@novell.com>
Keir Fraser <keir@xen.org>
Olaf Hering <olaf@aepfle.de>
------------------------------------------------------------
jobs:
build-i386-xcpkern pass
build-amd64 fail
build-i386 fail
build-amd64-oldkern fail
build-i386-oldkern fail
build-amd64-pvops pass
build-i386-pvops pass
test-amd64-amd64-xl blocked
test-amd64-i386-xl blocked
test-i386-i386-xl blocked
test-amd64-xcpkern-i386-xl blocked
test-i386-xcpkern-i386-xl blocked
test-amd64-i386-rhel6hvm-amd blocked
test-amd64-xcpkern-i386-rhel6hvm-amd blocked
test-amd64-i386-xl-credit2 blocked
test-amd64-xcpkern-i386-xl-credit2 blocked
test-amd64-i386-rhel6hvm-intel blocked
test-amd64-xcpkern-i386-rhel6hvm-intel blocked
test-amd64-i386-xl-multivcpu blocked
test-amd64-xcpkern-i386-xl-multivcpu blocked
test-amd64-amd64-pair blocked
test-amd64-i386-pair blocked
test-i386-i386-pair blocked
test-amd64-xcpkern-i386-pair blocked
test-i386-xcpkern-i386-pair blocked
test-amd64-amd64-pv blocked
test-amd64-i386-pv blocked
test-i386-i386-pv blocked
test-amd64-xcpkern-i386-pv blocked
test-i386-xcpkern-i386-pv blocked
test-amd64-i386-win-vcpus1 blocked
test-amd64-i386-xl-win-vcpus1 blocked
test-amd64-amd64-win blocked
test-amd64-i386-win blocked
test-i386-i386-win blocked
test-amd64-xcpkern-i386-win blocked
test-i386-xcpkern-i386-win blocked
test-amd64-amd64-xl-win blocked
test-i386-i386-xl-win blocked
test-amd64-xcpkern-i386-xl-win blocked
------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images
Logs, config files, etc. are available at
http://www.chiark.greenend.org.uk/~xensrcts/logs
Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
Not pushing.
------------------------------------------------------------
changeset: 21495:9f8f91033546
tag: tip
user: Keir Fraser <keir@xen.org>
date: Sat May 21 07:59:15 2011 +0100
Added signature for changeset 82f6fd38f5c2
changeset: 21494:50134c9b77ca
user: Keir Fraser <keir@xen.org>
date: Sat May 21 07:58:38 2011 +0100
Added tag 4.0.2-rc4 for changeset 82f6fd38f5c2
changeset: 21493:82f6fd38f5c2
tag: 4.0.2-rc4
user: Keir Fraser <keir@xen.org>
date: Sat May 21 07:58:25 2011 +0100
Update Xen version to 4.0.2-rc4
changeset: 21492:19eefd764f6f
user: Olaf Hering <olaf@aepfle.de>
date: Sat May 21 07:57:03 2011 +0100
gcc-4.6 compile fix: build with -Wno-unused-but-set-variable
Avoid "error: variable ''unused'' set but not used
[-Werror=unused-but-set-variable]" with gcc 4.6.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
xen-unstable changeset: 23368:0f670f5146c8
xen-unstable date: Sat May 21 07:55:46 2011 +0100
changeset: 21491:c6034ee9b46e
user: Keir Fraser <keir@xen.org>
date: Fri May 20 13:56:31 2011 +0100
x86: clear CPUID output of leaf 0xd for Dom0 when xsave is disabled
Linux starting with 2.6.36 uses the XSAVEOPT instruction and has
certain code paths that look only at the feature bit reported through
CPUID leaf 0xd sub-leaf 1 (i.e. without qualifying the check with one
evaluating leaf 4 output). Consequently the hypervisor ought to mimic
actual hardware in clearing leaf 0xd output when not supporting xsave.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
xen-unstable changeset: 23353:a768a10d32b4
xen-unstable date: Fri May 20 08:54:45 2011 +0100
Make this unconditional for 4.0 (no pv xsave support) and fix for domU
guests as well (this was already okay in 4.1 and later).
Signed-off-by: Keir Fraser <keir@xen.org>
(qemu changes not included)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Keir Fraser
2011-May-21 22:19 UTC
Re: [Xen-devel] [xen-4.0-testing test] 7147: regressions - FAIL
Related to the -Wno-unused-but-set-variable patch. But this is weird because the compiler runs many times with this option quite happily, before failing on it as an unrecognised option much later in the build (building qemu in this case, or stubdom in the case of xen-unstable). Any ideas? -- Keir On 21/05/2011 22:34, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:> flight 7147 xen-4.0-testing real [real] > http://www.chiark.greenend.org.uk/~xensrcts/logs/7147/ > > Regressions :-( > > Tests which did not succeed and are blocking: > build-amd64-oldkern 4 xen-build fail REGR. vs. > 7136 > build-amd64 4 xen-build fail REGR. vs. > 7136 > build-i386-oldkern 4 xen-build fail REGR. vs. > 7136 > build-i386 4 xen-build fail REGR. vs. > 7136 > > Tests which did not succeed, but are not blocking, > including regressions (tests previously passed) regarded as allowable: > test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a > test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a > test-amd64-amd64-win 1 xen-build-check(1) blocked n/a > test-amd64-amd64-xl-win 1 xen-build-check(1) blocked n/a > test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a > test-amd64-i386-pair 1 xen-build-check(1) blocked n/a > test-amd64-i386-pv 1 xen-build-check(1) blocked n/a > test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a > test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a > test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked n/a > test-amd64-i386-win 1 xen-build-check(1) blocked n/a > test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a > test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a > test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a > test-amd64-i386-xl 1 xen-build-check(1) blocked n/a > test-amd64-xcpkern-i386-pair 1 xen-build-check(1) blocked n/a > test-amd64-xcpkern-i386-pv 1 xen-build-check(1) blocked n/a > test-amd64-xcpkern-i386-rhel6hvm-amd 1 xen-build-check(1) blocked > n/a > test-amd64-xcpkern-i386-rhel6hvm-intel 1 xen-build-check(1) blocked > n/a > test-amd64-xcpkern-i386-win 1 xen-build-check(1) blocked n/a > test-amd64-xcpkern-i386-xl-credit2 1 xen-build-check(1) blocked > n/a > test-amd64-xcpkern-i386-xl-multivcpu 1 xen-build-check(1) blocked > n/a > test-amd64-xcpkern-i386-xl-win 1 xen-build-check(1) blocked n/a > test-amd64-xcpkern-i386-xl 1 xen-build-check(1) blocked n/a > test-i386-i386-pair 1 xen-build-check(1) blocked n/a > test-i386-i386-pv 1 xen-build-check(1) blocked n/a > test-i386-i386-win 1 xen-build-check(1) blocked n/a > test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a > test-i386-i386-xl 1 xen-build-check(1) blocked n/a > test-i386-xcpkern-i386-pair 1 xen-build-check(1) blocked n/a > test-i386-xcpkern-i386-pv 1 xen-build-check(1) blocked n/a > test-i386-xcpkern-i386-win 1 xen-build-check(1) blocked n/a > test-i386-xcpkern-i386-xl 1 xen-build-check(1) blocked n/a > > version targeted for testing: > xen 9f8f91033546 > baseline version: > xen c6034ee9b46e > > ------------------------------------------------------------ > People who touched revisions under test: > Jan Beulich <jbeulich@novell.com> > Keir Fraser <keir@xen.org> > Olaf Hering <olaf@aepfle.de> > ------------------------------------------------------------ > > jobs: > build-i386-xcpkern pass > build-amd64 fail > build-i386 fail > build-amd64-oldkern fail > build-i386-oldkern fail > build-amd64-pvops pass > build-i386-pvops pass > test-amd64-amd64-xl blocked > test-amd64-i386-xl blocked > test-i386-i386-xl blocked > test-amd64-xcpkern-i386-xl blocked > test-i386-xcpkern-i386-xl blocked > test-amd64-i386-rhel6hvm-amd blocked > test-amd64-xcpkern-i386-rhel6hvm-amd blocked > test-amd64-i386-xl-credit2 blocked > test-amd64-xcpkern-i386-xl-credit2 blocked > test-amd64-i386-rhel6hvm-intel blocked > test-amd64-xcpkern-i386-rhel6hvm-intel blocked > test-amd64-i386-xl-multivcpu blocked > test-amd64-xcpkern-i386-xl-multivcpu blocked > test-amd64-amd64-pair blocked > test-amd64-i386-pair blocked > test-i386-i386-pair blocked > test-amd64-xcpkern-i386-pair blocked > test-i386-xcpkern-i386-pair blocked > test-amd64-amd64-pv blocked > test-amd64-i386-pv blocked > test-i386-i386-pv blocked > test-amd64-xcpkern-i386-pv blocked > test-i386-xcpkern-i386-pv blocked > test-amd64-i386-win-vcpus1 blocked > test-amd64-i386-xl-win-vcpus1 blocked > test-amd64-amd64-win blocked > test-amd64-i386-win blocked > test-i386-i386-win blocked > test-amd64-xcpkern-i386-win blocked > test-i386-xcpkern-i386-win blocked > test-amd64-amd64-xl-win blocked > test-i386-i386-xl-win blocked > test-amd64-xcpkern-i386-xl-win blocked > > > ------------------------------------------------------------ > sg-report-flight on woking.cam.xci-test.com > logs: /home/xc_osstest/logs > images: /home/xc_osstest/images > > Logs, config files, etc. are available at > http://www.chiark.greenend.org.uk/~xensrcts/logs > > Test harness code can be found at > http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary > > > Not pushing. > > ------------------------------------------------------------ > changeset: 21495:9f8f91033546 > tag: tip > user: Keir Fraser <keir@xen.org> > date: Sat May 21 07:59:15 2011 +0100 > > Added signature for changeset 82f6fd38f5c2 > > > changeset: 21494:50134c9b77ca > user: Keir Fraser <keir@xen.org> > date: Sat May 21 07:58:38 2011 +0100 > > Added tag 4.0.2-rc4 for changeset 82f6fd38f5c2 > > > changeset: 21493:82f6fd38f5c2 > tag: 4.0.2-rc4 > user: Keir Fraser <keir@xen.org> > date: Sat May 21 07:58:25 2011 +0100 > > Update Xen version to 4.0.2-rc4 > > > changeset: 21492:19eefd764f6f > user: Olaf Hering <olaf@aepfle.de> > date: Sat May 21 07:57:03 2011 +0100 > > gcc-4.6 compile fix: build with -Wno-unused-but-set-variable > > Avoid "error: variable ''unused'' set but not used > [-Werror=unused-but-set-variable]" with gcc 4.6. > > Signed-off-by: Olaf Hering <olaf@aepfle.de> > xen-unstable changeset: 23368:0f670f5146c8 > xen-unstable date: Sat May 21 07:55:46 2011 +0100 > > > changeset: 21491:c6034ee9b46e > user: Keir Fraser <keir@xen.org> > date: Fri May 20 13:56:31 2011 +0100 > > x86: clear CPUID output of leaf 0xd for Dom0 when xsave is disabled > > Linux starting with 2.6.36 uses the XSAVEOPT instruction and has > certain code paths that look only at the feature bit reported through > CPUID leaf 0xd sub-leaf 1 (i.e. without qualifying the check with one > evaluating leaf 4 output). Consequently the hypervisor ought to mimic > actual hardware in clearing leaf 0xd output when not supporting xsave. > > Signed-off-by: Jan Beulich <jbeulich@novell.com> > xen-unstable changeset: 23353:a768a10d32b4 > xen-unstable date: Fri May 20 08:54:45 2011 +0100 > > Make this unconditional for 4.0 (no pv xsave support) and fix for domU > guests as well (this was already okay in 4.1 and later). > > Signed-off-by: Keir Fraser <keir@xen.org> > > > (qemu changes not included) > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
M A Young
2011-May-22 16:29 UTC
Re:[Xen-devel] [xen-4.0-testing test] 7147: regressions - FAIL
I don''t know if it helps, but you could use -Wno-error=unused-but-set-variable instead of -Wno-unused-but-set-variable (ie. still log it but don''t treat it as an error). I have been using the patch http://pkgs.fedoraproject.org/gitweb/?p=xen.git;a=blob;f=localgcc46fix.patch;h=e485c3b5887ae65b8ec6f0278b5973469eea3c03;hb=f1397f37927368acbf47514c810809d546b35fb2 in Fedora which includes the option, and it builds for me (on F14, F15 and RHEL6). Michael Young _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2011-May-22 18:10 UTC
Re: [Xen-devel] [xen-4.0-testing test] 7147: regressions - FAIL
On 22/05/2011 17:29, "M A Young" <m.a.young@durham.ac.uk> wrote:> I don''t know if it helps, but you could use > -Wno-error=unused-but-set-variable instead of -Wno-unused-but-set-variable > (ie. still log it but don''t treat it as an error). I have been using the > patch > http://pkgs.fedoraproject.org/gitweb/?p=xen.git;a=blob;f=localgcc46fix.patch;h > =e485c3b5887ae65b8ec6f0278b5973469eea3c03;hb=f1397f37927368acbf47514c810809d54 > 6b35fb2 > in Fedora which includes the option, and it builds for me (on F14, F15 and > RHEL6).Well, it builds as-is for me already, on a recent Fedora. It likely has something to do with the automated-test build environment, which is some Debian version I believe, which surely makes it elderly compared with the Fedoras/OpenSuses that many like me use. -- Keir> Michael Young_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Olaf Hering
2011-May-23 11:10 UTC
Re: [Xen-devel] [xen-4.0-testing test] 7147: regressions - FAIL
On Sat, May 21, Keir Fraser wrote:> Related to the -Wno-unused-but-set-variable patch. But this is weird because > the compiler runs many times with this option quite happily, before failing > on it as an unrecognised option much later in the build (building qemu in > this case, or stubdom in the case of xen-unstable). Any ideas?I will look at this today. Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Campbell
2011-May-23 12:32 UTC
Re: [Xen-devel] [xen-4.0-testing test] 7147: regressions - FAIL
On Sat, 2011-05-21 at 23:19 +0100, Keir Fraser wrote:> Related to the -Wno-unused-but-set-variable patch. But this is weird because > the compiler runs many times with this option quite happily, before failing > on it as an unrecognised option much later in the build (building qemu in > this case, or stubdom in the case of xen-unstable). Any ideas?Weirdly it seems like the unrecognized command line option "-Wno-unused-but-set-variable" only shows up if the compiler has also generated a warning of some sort. Since much of the xen tree is built with -Werror it is generally warning free and so succeeds, but the stbudom and ioemu builds do not use Werror and sodo have some warnings... I noticed this because I made a change to hvmloader which caused a warning, followed by this error. Having fixed the warning it now succeeds. It seems like gcc (at least in Debian Squeeze) does some sort of lazy evaluation of -W options, which seems terribly unlikely but does seem to be reality. Try compiling the following always with -Wno-unused-but-set-variable but with and without -DHACK to see what I mean: $ gcc -Wno-unused-but-set-variable -DHACK ~/t.c /home/ianc/t.c: In function ''main'': /home/ianc/t.c:6: warning: initialization makes pointer from integer without a cast At top level: cc1: warning: unrecognized command line option "-Wno-unused-but-set-variable" $ gcc -Wno-unused-but-set-variable ~/t.c $ cat ~/t.c #include <stdio.h> int main(void) { #ifdef HACK void *p = 0x1234; #else void *p = NULL; #endif printf("P is %p\n", p); } Funky. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Olaf Hering
2011-May-23 12:59 UTC
Re: [Xen-devel] [xen-4.0-testing test] 7147: regressions - FAIL
On Sat, May 21, Keir Fraser wrote:> Related to the -Wno-unused-but-set-variable patch. But this is weird because > the compiler runs many times with this option quite happily, before failing > on it as an unrecognised option much later in the build (building qemu in > this case, or stubdom in the case of xen-unstable). Any ideas?This is weird, why did the new option get passed to CFLAGS anyway? Its properly filtered out in my SLES11SP1 builds. What compiler is that? Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Jackson
2011-May-23 14:06 UTC
Re: [Xen-devel] [xen-4.0-testing test] 7147: regressions - FAIL
Ian Campbell writes ("Re: [Xen-devel] [xen-4.0-testing test] 7147:
regressions - FAIL"):> It seems like gcc (at least in Debian Squeeze) does some sort of lazy
> evaluation of -W options, which seems terribly unlikely but does seem to
> be reality. Try compiling the following always with
> -Wno-unused-but-set-variable but with and without -DHACK to see what I
> mean:
>
> $ gcc -Wno-unused-but-set-variable -DHACK ~/t.c
> /home/ianc/t.c: In function ''main'':
> /home/ianc/t.c:6: warning: initialization makes pointer from integer
without a cast
> At top level:
> cc1: warning: unrecognized command line option
"-Wno-unused-but-set-variable"
> $ gcc -Wno-unused-but-set-variable ~/t.c
> $ cat ~/t.c
This is related to my efforts to try to make new warnings easier to
cope with in future. Note that the "unrecognised -W option" message
is itself only a warning in squeeze (which is correct), but apparently
in lenny it is an error:
mariner:~/junk> gcc -Wno-unused-but-set-variable -DHACK t.c
t.c: In function ''main'':
t.c:7: warning: initialization makes pointer from integer without a cast
At top level:
cc1: error: unrecognized command line option
"-Wno-unused-but-set-variable"
mariner:~/junk> gcc -Wno-unused-but-set-variable t.c
mariner:~/junk>
That makes it harder, rather than easier, to figure out what''s going
on and write correct Makefiles.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Ian Jackson
2011-May-23 15:08 UTC
Re: [Xen-devel] [xen-4.0-testing test] 7147: regressions - FAIL
I wrote:> At top level: > cc1: error: unrecognized command line option "-Wno-unused-but-set-variable"How about this fix. Ian. diff -r 0f670f5146c8 Config.mk --- a/Config.mk Sat May 21 07:55:46 2011 +0100 +++ b/Config.mk Mon May 23 16:07:59 2011 +0100 @@ -72,8 +72,7 @@ PYTHON_PREFIX_ARG ?= --prefix="$(PREFIX) # cc-option: Check if compiler supports first option, else fall back to second. # 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 $(XEN_ROOT)/config/test-cc-option.sh $(1) $(2) $(3)) # cc-option-add: Add an option to compilation flags, but only if supported. # Usage: $(call cc-option-add CFLAGS,CC,-march=winchip-c6) diff -r 0f670f5146c8 config/test-cc-option.sh --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/config/test-cc-option.sh Mon May 23 16:07:59 2011 +0100 @@ -0,0 +1,31 @@ +#!/bin/sh +set -e + +cc="$1" +opt="$2" +alt="$3" + +case "$opt" in +-Wno-*) + # Sadly a broken implementation of the fix to GCC PR 28322 + # (actually shipped eg in Debian lenny) makes it hard to spot + # whether the compiler recognises a -Wno-foo option without + # generating a warning for some other reason. + + input="${0%-cc-option.sh}-cc-warning.c" + if $cc $opt -Wreturn-type -Wno-error -S -o /dev/null "$input" \ + >/dev/null 2>&1; then + res="$opt" + else + res="$alt" + fi + ;; +*) + if test -z "`$cc $opt $nerr -S -o /dev/null -xc $input 2>&1`"; then + res="$opt" + else + res="$alt" + fi + ;; +esac +printf "%s\n" "$res" diff -r 0f670f5146c8 config/test-cc-warning.c --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/config/test-cc-warning.c Mon May 23 16:07:59 2011 +0100 @@ -0,0 +1,2 @@ +extern int bogus(void); +int bogus(void) { } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Campbell
2011-May-23 15:14 UTC
Re: [Xen-devel] [xen-4.0-testing test] 7147: regressions - FAIL
On Mon, 2011-05-23 at 16:08 +0100, Ian Jackson wrote:> I wrote: > > At top level: > > cc1: error: unrecognized command line option "-Wno-unused-but-set-variable" > > How about this fix. > > Ian. > > diff -r 0f670f5146c8 Config.mk > --- a/Config.mk Sat May 21 07:55:46 2011 +0100 > +++ b/Config.mk Mon May 23 16:07:59 2011 +0100 > @@ -72,8 +72,7 @@ PYTHON_PREFIX_ARG ?= --prefix="$(PREFIX) > > # cc-option: Check if compiler supports first option, else fall back to second. > # 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 $(XEN_ROOT)/config/test-cc-option.sh $(1) $(2) $(3)) > > # cc-option-add: Add an option to compilation flags, but only if supported. > # Usage: $(call cc-option-add CFLAGS,CC,-march=winchip-c6) > diff -r 0f670f5146c8 config/test-cc-option.sh > --- /dev/null Thu Jan 01 00:00:00 1970 +0000 > +++ b/config/test-cc-option.sh Mon May 23 16:07:59 2011 +0100 > @@ -0,0 +1,31 @@ > +#!/bin/sh > +set -e > + > +cc="$1" > +opt="$2" > +alt="$3" > + > +case "$opt" in > +-Wno-*) > + # Sadly a broken implementation of the fix to GCC PR 28322 > + # (actually shipped eg in Debian lenny) makes it hard to spot > + # whether the compiler recognises a -Wno-foo option without > + # generating a warning for some other reason. > + > + input="${0%-cc-option.sh}-cc-warning.c" > + if $cc $opt -Wreturn-type -Wno-error -S -o /dev/null "$input" \ > + >/dev/null 2>&1; then > + res="$opt" > + else > + res="$alt" > + fi > + ;; > +*) > + if test -z "`$cc $opt $nerr -S -o /dev/null -xc $input 2>&1`"; thenWhere does $nerr come from?> + res="$opt" > + else > + res="$alt" > + fi > + ;; > +esac > +printf "%s\n" "$res" > diff -r 0f670f5146c8 config/test-cc-warning.c > --- /dev/null Thu Jan 01 00:00:00 1970 +0000 > +++ b/config/test-cc-warning.c Mon May 23 16:07:59 2011 +0100 > @@ -0,0 +1,2 @@ > +extern int bogus(void); > +int bogus(void) { }_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Jackson
2011-May-23 15:18 UTC
Re: [Xen-devel] [xen-4.0-testing test] 7147: regressions - FAIL
Ian Campbell writes ("Re: [Xen-devel] [xen-4.0-testing test] 7147:
regressions - FAIL"):> On Mon, 2011-05-23 at 16:08 +0100, Ian Jackson wrote:
> > + if test -z "`$cc $opt $nerr -S -o /dev/null -xc $input
2>&1`"; then
>
> Where does $nerr come from?
Oh, that''s a leftover from a previous version. I''ll delete
it.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Keir Fraser
2011-May-23 15:24 UTC
Re: [Xen-devel] [xen-4.0-testing test] 7147: regressions - FAIL
On 23/05/2011 16:08, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:> I wrote: >> At top level: >> cc1: error: unrecognized command line option "-Wno-unused-but-set-variable" > > How about this fix.I''ve been fiddling with a similar principle but much smaller patch (see below). But it''s failing for me in the same way as yours -- *all* optional flags disappear from my CFLAGS (e.g., -Wno-unused-but-set-variable, which my gcc-4.5.1 definitely does support). So I''m still scratching my head on this one... :-( diff -r 0f670f5146c8 Config.mk --- a/Config.mk Sat May 21 07:55:46 2011 +0100 +++ b/Config.mk Mon May 23 16:16:54 2011 +0100 @@ -72,8 +72,10 @@ PYTHON_PREFIX_ARG ?= --prefix="$(PREFIX) # cc-option: Check if compiler supports first option, else fall back to second. # 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 "`$(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`"; then echo "$(2)"; else echo "$(3)"; fi ;) # cc-option-add: Add an option to compilation flags, but only if supported. # Usage: $(call cc-option-add CFLAGS,CC,-march=winchip-c6)> Ian. > > diff -r 0f670f5146c8 Config.mk > --- a/Config.mk Sat May 21 07:55:46 2011 +0100 > +++ b/Config.mk Mon May 23 16:07:59 2011 +0100 > @@ -72,8 +72,7 @@ PYTHON_PREFIX_ARG ?= --prefix="$(PREFIX) > > # cc-option: Check if compiler supports first option, else fall back to > second. > # 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 $(XEN_ROOT)/config/test-cc-option.sh $(1) $(2) $(3)) > > # cc-option-add: Add an option to compilation flags, but only if supported. > # Usage: $(call cc-option-add CFLAGS,CC,-march=winchip-c6) > diff -r 0f670f5146c8 config/test-cc-option.sh > --- /dev/null Thu Jan 01 00:00:00 1970 +0000 > +++ b/config/test-cc-option.sh Mon May 23 16:07:59 2011 +0100 > @@ -0,0 +1,31 @@ > +#!/bin/sh > +set -e > + > +cc="$1" > +opt="$2" > +alt="$3" > + > +case "$opt" in > +-Wno-*) > + # Sadly a broken implementation of the fix to GCC PR 28322 > + # (actually shipped eg in Debian lenny) makes it hard to spot > + # whether the compiler recognises a -Wno-foo option without > + # generating a warning for some other reason. > + > + input="${0%-cc-option.sh}-cc-warning.c" > + if $cc $opt -Wreturn-type -Wno-error -S -o /dev/null "$input" \ > + >/dev/null 2>&1; then > + res="$opt" > + else > + res="$alt" > + fi > + ;; > +*) > + if test -z "`$cc $opt $nerr -S -o /dev/null -xc $input 2>&1`"; then > + res="$opt" > + else > + res="$alt" > + fi > + ;; > +esac > +printf "%s\n" "$res" > diff -r 0f670f5146c8 config/test-cc-warning.c > --- /dev/null Thu Jan 01 00:00:00 1970 +0000 > +++ b/config/test-cc-warning.c Mon May 23 16:07:59 2011 +0100 > @@ -0,0 +1,2 @@ > +extern int bogus(void); > +int bogus(void) { }_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Jackson
2011-May-23 15:33 UTC
Re: [Xen-devel] [xen-4.0-testing test] 7147: regressions - FAIL
Keir Fraser writes ("Re: [Xen-devel] [xen-4.0-testing test] 7147:
regressions - FAIL"):> I''ve been fiddling with a similar principle but much smaller patch
(see
> below). But it''s failing for me in the same way as yours -- *all*
optional
> flags disappear from my CFLAGS (e.g., -Wno-unused-but-set-variable, which
my
> gcc-4.5.1 definitely does support).
You have to check the exit status, not the stderr output. It might be
right do do that even for ordinary (non -Wno-*) options.
But TBH I really prefer my script because it''s actually
comprehensible. You can even run it by hand from the command line:
mariner:xen-unstable-tools.hg> config/test-cc-option.sh gcc
-fno-strict-aliasing
-fno-strict-aliasing
mariner:xen-unstable-tools.hg> config/test-cc-option.sh gcc -fno-rapture
mariner:xen-unstable-tools.hg> config/test-cc-option.sh gcc
-Wdeclaration-after-statement
-Wdeclaration-after-statement
mariner:xen-unstable-tools.hg> config/test-cc-option.sh gcc
-Wno-declaration-after-statement
-Wno-declaration-after-statement
mariner:xen-unstable-tools.hg> config/test-cc-option.sh gcc -Wno-rapture
mariner:xen-unstable-tools.hg>
Below is a final version of my fix, ready to push to unstable.
Ian.
# HG changeset patch
# User Ian Jackson <Ian.Jackson@eu.citrix.com>
# Date 1306164314 -3600
# Node ID 512f0b1937b40e3ecc79dea6768646206e0f69f3
# Parent 0f670f5146c858ffdc743176d4e22aef4bfe12da
gcc compile fix (reprise): deal with fallout from GCC PR 28322
21492:19eefd764f6f breaks the build on certain GCC 4.3 systems which
have a broken version of the fix to upstream GCC PR 28322.
Specifically, those gcc''s (which include current Debian
lenny''s)
ignore unknown -Wno-foo options if there are no warnings, but treat
them as an error otherwise. If you compile with -Wno-error the effect
is to defeat straightforward attempts (like ours) to filter out
unknown -Wno-foo options and instead to bomb out with a complaint the
first time any file is compiled which causes any other, unrelated,
warning.
In this patch I introduce a more sophisticated way of trying to filter
out unknown -Wno-foo options. The machinery is moved into a helper
script. For -Wno-foo options, we test whether compiling a file with
another warning, with -Wno-error, and with the option to be tested,
succeeds or fails. On compilers with no fix for PR 28322, or with the
broken fix, this will fail. On compilers with a correct fix for PR
28322 this will succeed but the warning option is then harmless.
For normal compiler options, we simply use the same test we did
before: does compiling /dev/null with this option produce any stderr
output.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
diff -r 0f670f5146c8 -r 512f0b1937b4 Config.mk
--- a/Config.mk Sat May 21 07:55:46 2011 +0100
+++ b/Config.mk Mon May 23 16:25:14 2011 +0100
@@ -72,8 +72,7 @@ PYTHON_PREFIX_ARG ?= --prefix="$(PREFIX)
# cc-option: Check if compiler supports first option, else fall back to second.
# 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 $(XEN_ROOT)/config/test-cc-option.sh "$(1)"
"$(2)" "$(3)")
# cc-option-add: Add an option to compilation flags, but only if supported.
# Usage: $(call cc-option-add CFLAGS,CC,-march=winchip-c6)
diff -r 0f670f5146c8 -r 512f0b1937b4 config/test-cc-option.sh
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/config/test-cc-option.sh Mon May 23 16:25:14 2011 +0100
@@ -0,0 +1,31 @@
+#!/bin/sh
+set -e
+
+cc="$1"
+opt="$2"
+alt="$3"
+
+case "$opt" in
+-Wno-*)
+ # Sadly a broken implementation of the fix to GCC PR 28322
+ # (actually shipped eg in Debian lenny) makes it hard to spot
+ # whether the compiler recognises a -Wno-foo option without
+ # generating a warning for some other reason.
+
+ input="${0%-cc-option.sh}-cc-warning.c"
+ if $cc $opt -Wreturn-type -Wno-error -S -o /dev/null "$input" \
+ >/dev/null 2>&1; then
+ res="$opt"
+ else
+ res="$alt"
+ fi
+ ;;
+*)
+ if test -z "`$cc $opt -S -o /dev/null -xc $input 2>&1`";
then
+ res="$opt"
+ else
+ res="$alt"
+ fi
+ ;;
+esac
+printf "%s\n" "$res"
diff -r 0f670f5146c8 -r 512f0b1937b4 config/test-cc-warning.c
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/config/test-cc-warning.c Mon May 23 16:25:14 2011 +0100
@@ -0,0 +1,2 @@
+extern int bogus(void);
+int bogus(void) { }
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Keir Fraser
2011-May-23 15:37 UTC
Re: [Xen-devel] [xen-4.0-testing test] 7147: regressions - FAIL
On 23/05/2011 16:24, "Keir Fraser" <keir@xen.org> wrote:> On 23/05/2011 16:08, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote: > >> I wrote: >>> At top level: >>> cc1: error: unrecognized command line option "-Wno-unused-but-set-variable" >> >> How about this fix. > > I''ve been fiddling with a similar principle but much smaller patch (see > below). But it''s failing for me in the same way as yours -- *all* optional > flags disappear from my CFLAGS (e.g., -Wno-unused-but-set-variable, which my > gcc-4.5.1 definitely does support). > > So I''m still scratching my head on this one... :-(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. 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. I''ll refrain from applying it until we have general agreement. -- Keir diff -r 0f670f5146c8 Config.mk --- a/Config.mk Sat May 21 07:55:46 2011 +0100 +++ b/Config.mk Mon May 23 16:32:43 2011 +0100 @@ -72,8 +72,9 @@ PYTHON_PREFIX_ARG ?= --prefix="$(PREFIX) # cc-option: Check if compiler supports first option, else fall back to second. # 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 unrecognized`"; \ + then echo "$(2)"; else echo "$(3)"; fi ;) # cc-option-add: Add an option to compilation flags, but only if supported. # Usage: $(call cc-option-add CFLAGS,CC,-march=winchip-c6)> > diff -r 0f670f5146c8 Config.mk > --- a/Config.mk Sat May 21 07:55:46 2011 +0100 > +++ b/Config.mk Mon May 23 16:16:54 2011 +0100 > @@ -72,8 +72,10 @@ PYTHON_PREFIX_ARG ?= --prefix="$(PREFIX) > > # cc-option: Check if compiler supports first option, else fall back to > second. > # 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 "`$(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`"; then echo "$(2)"; > else echo "$(3)"; fi ;) > > # cc-option-add: Add an option to compilation flags, but only if supported. > # Usage: $(call cc-option-add CFLAGS,CC,-march=winchip-c6) > > >> Ian. >> >> diff -r 0f670f5146c8 Config.mk >> --- a/Config.mk Sat May 21 07:55:46 2011 +0100 >> +++ b/Config.mk Mon May 23 16:07:59 2011 +0100 >> @@ -72,8 +72,7 @@ PYTHON_PREFIX_ARG ?= --prefix="$(PREFIX) >> >> # cc-option: Check if compiler supports first option, else fall back to >> second. >> # 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 $(XEN_ROOT)/config/test-cc-option.sh $(1) $(2) $(3)) >> >> # cc-option-add: Add an option to compilation flags, but only if supported. >> # Usage: $(call cc-option-add CFLAGS,CC,-march=winchip-c6) >> diff -r 0f670f5146c8 config/test-cc-option.sh >> --- /dev/null Thu Jan 01 00:00:00 1970 +0000 >> +++ b/config/test-cc-option.sh Mon May 23 16:07:59 2011 +0100 >> @@ -0,0 +1,31 @@ >> +#!/bin/sh >> +set -e >> + >> +cc="$1" >> +opt="$2" >> +alt="$3" >> + >> +case "$opt" in >> +-Wno-*) >> + # Sadly a broken implementation of the fix to GCC PR 28322 >> + # (actually shipped eg in Debian lenny) makes it hard to spot >> + # whether the compiler recognises a -Wno-foo option without >> + # generating a warning for some other reason. >> + >> + input="${0%-cc-option.sh}-cc-warning.c" >> + if $cc $opt -Wreturn-type -Wno-error -S -o /dev/null "$input" \ >> + >/dev/null 2>&1; then >> + res="$opt" >> + else >> + res="$alt" >> + fi >> + ;; >> +*) >> + if test -z "`$cc $opt $nerr -S -o /dev/null -xc $input 2>&1`"; then >> + res="$opt" >> + else >> + res="$alt" >> + fi >> + ;; >> +esac >> +printf "%s\n" "$res" >> diff -r 0f670f5146c8 config/test-cc-warning.c >> --- /dev/null Thu Jan 01 00:00:00 1970 +0000 >> +++ b/config/test-cc-warning.c Mon May 23 16:07:59 2011 +0100 >> @@ -0,0 +1,2 @@ >> +extern int bogus(void); >> +int bogus(void) { } > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Jackson
2011-May-23 15:40 UTC
Re: [Xen-devel] [xen-4.0-testing test] 7147: regressions - FAIL
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.
> 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.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Keir Fraser
2011-May-23 15:49 UTC
Re: [Xen-devel] [xen-4.0-testing test] 7147: regressions - FAIL
On 23/05/2011 16:40, "Ian Jackson" <Ian.Jackson@eu.citrix.com> 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.>> 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 Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2011-May-23 16:16 UTC
Re: [Xen-devel] [xen-4.0-testing test] 7147: regressions - FAIL
On 23/05/2011 16:49, "Keir Fraser" <keir@xen.org> wrote:> On 23/05/2011 16:40, "Ian Jackson" <Ian.Jackson@eu.citrix.com> 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 second. +# +# 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 code +# fragment that will always produce a warning (integer assigned to pointer). +# We then grep for the option-under-test in the compiler''s output, the presence +# of which would indicate an "unrecognized command-line option" warning/error. +# # 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 Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel