All of lore.kernel.org
 help / color / mirror / Atom feed
* [xen-4.0-testing test] 7147: regressions - FAIL
@ 2011-05-21 21:34 xen.org
  2011-05-21 22:19 ` Keir Fraser
  0 siblings, 1 reply; 16+ messages in thread
From: xen.org @ 2011-05-21 21:34 UTC (permalink / raw)
  To: xen-devel; +Cc: ian.jackson

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)

^ permalink raw reply	[flat|nested] 16+ messages in thread
* Re: [xen-4.0-testing test] 7147: regressions - FAIL
  2011-05-21 21:34 [xen-4.0-testing test] 7147: regressions - FAIL xen.org
@ 2011-05-21 22:19 ` Keir Fraser
  2011-05-23 11:10   ` Olaf Hering
                     ` (2 more replies)
  0 siblings, 3 replies; 16+ messages in thread
From: Keir Fraser @ 2011-05-21 22:19 UTC (permalink / raw)
  To: Ian Jackson, xen-devel; +Cc: Olaf Hering

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

^ permalink raw reply	[flat|nested] 16+ messages in thread
* Re: [xen-4.0-testing test] 7147: regressions - FAIL
  2011-05-21 22:19 ` Keir Fraser
@ 2011-05-23 11:10   ` Olaf Hering
  2011-05-23 12:32   ` Ian Campbell
  2011-05-23 12:59   ` Olaf Hering
  2 siblings, 0 replies; 16+ messages in thread
From: Olaf Hering @ 2011-05-23 11:10 UTC (permalink / raw)
  To: Keir Fraser; +Cc: xen-devel, Ian Jackson

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

^ permalink raw reply	[flat|nested] 16+ messages in thread
* Re: [xen-4.0-testing test] 7147: regressions - FAIL
  2011-05-21 22:19 ` Keir Fraser
  2011-05-23 11:10   ` Olaf Hering
@ 2011-05-23 12:32   ` Ian Campbell
  2011-05-23 14:06     ` Ian Jackson
  2011-05-23 12:59   ` Olaf Hering
  2 siblings, 1 reply; 16+ messages in thread
From: Ian Campbell @ 2011-05-23 12:32 UTC (permalink / raw)
  To: Keir Fraser; +Cc: Olaf Hering, xen-devel, Ian Jackson

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.

^ permalink raw reply	[flat|nested] 16+ messages in thread
* Re: [xen-4.0-testing test] 7147: regressions - FAIL
  2011-05-21 22:19 ` Keir Fraser
  2011-05-23 11:10   ` Olaf Hering
  2011-05-23 12:32   ` Ian Campbell
@ 2011-05-23 12:59   ` Olaf Hering
  2 siblings, 0 replies; 16+ messages in thread
From: Olaf Hering @ 2011-05-23 12:59 UTC (permalink / raw)
  To: Keir Fraser; +Cc: xen-devel, Ian Jackson

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

^ permalink raw reply	[flat|nested] 16+ messages in thread
* Re: [xen-4.0-testing test] 7147: regressions - FAIL
  2011-05-23 12:32   ` Ian Campbell
@ 2011-05-23 14:06     ` Ian Jackson
  2011-05-23 15:08       ` Ian Jackson
  0 siblings, 1 reply; 16+ messages in thread
From: Ian Jackson @ 2011-05-23 14:06 UTC (permalink / raw)
  To: Ian Campbell; +Cc: Olaf Hering, Keir Fraser, xen-devel

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.

^ permalink raw reply	[flat|nested] 16+ messages in thread
* Re: [xen-4.0-testing test] 7147: regressions - FAIL
  2011-05-23 14:06     ` Ian Jackson
@ 2011-05-23 15:08       ` Ian Jackson
  2011-05-23 15:14         ` Ian Campbell
  2011-05-23 15:24         ` Keir Fraser
  0 siblings, 2 replies; 16+ messages in thread
From: Ian Jackson @ 2011-05-23 15:08 UTC (permalink / raw)
  To: Ian Campbell, Keir Fraser, xen-devel, Olaf Hering

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) { }

^ permalink raw reply	[flat|nested] 16+ messages in thread
* Re: [xen-4.0-testing test] 7147: regressions - FAIL
  2011-05-23 15:08       ` Ian Jackson
@ 2011-05-23 15:14         ` Ian Campbell
  2011-05-23 15:18           ` Ian Jackson
  2011-05-23 15:24         ` Keir Fraser
  1 sibling, 1 reply; 16+ messages in thread
From: Ian Campbell @ 2011-05-23 15:14 UTC (permalink / raw)
  To: Ian Jackson; +Cc: Olaf Hering, Keir Fraser, xen-devel

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`"; then

Where 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) { }

^ permalink raw reply	[flat|nested] 16+ messages in thread
* Re: [xen-4.0-testing test] 7147: regressions - FAIL
  2011-05-23 15:14         ` Ian Campbell
@ 2011-05-23 15:18           ` Ian Jackson
  0 siblings, 0 replies; 16+ messages in thread
From: Ian Jackson @ 2011-05-23 15:18 UTC (permalink / raw)
  To: Ian Campbell; +Cc: Olaf Hering, Keir Fraser, xen-devel

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.

^ permalink raw reply	[flat|nested] 16+ messages in thread
* Re: [xen-4.0-testing test] 7147: regressions - FAIL
  2011-05-23 15:08       ` Ian Jackson
  2011-05-23 15:14         ` Ian Campbell
@ 2011-05-23 15:24         ` Keir Fraser
  2011-05-23 15:33           ` Ian Jackson
  2011-05-23 15:37           ` Keir Fraser
  1 sibling, 2 replies; 16+ messages in thread
From: Keir Fraser @ 2011-05-23 15:24 UTC (permalink / raw)
  To: Ian Jackson, Ian Campbell, xen-devel, Olaf Hering

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) { }

^ permalink raw reply	[flat|nested] 16+ messages in thread
* Re: [xen-4.0-testing test] 7147: regressions - FAIL
  2011-05-23 15:24         ` Keir Fraser
@ 2011-05-23 15:33           ` Ian Jackson
  2011-05-23 15:37           ` Keir Fraser
  1 sibling, 0 replies; 16+ messages in thread
From: Ian Jackson @ 2011-05-23 15:33 UTC (permalink / raw)
  To: Keir Fraser; +Cc: Ian Campbell, Olaf Hering, xen-devel

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) { }

^ permalink raw reply	[flat|nested] 16+ messages in thread
* Re: [xen-4.0-testing test] 7147: regressions - FAIL
  2011-05-23 15:24         ` Keir Fraser
  2011-05-23 15:33           ` Ian Jackson
@ 2011-05-23 15:37           ` Keir Fraser
  2011-05-23 15:40             ` Ian Jackson
  1 sibling, 1 reply; 16+ messages in thread
From: Keir Fraser @ 2011-05-23 15:37 UTC (permalink / raw)
  To: Ian Jackson, Ian Campbell, xen-devel, Olaf Hering

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) { }
> 
> 

^ permalink raw reply	[flat|nested] 16+ messages in thread
* Re: [xen-4.0-testing test] 7147: regressions - FAIL
  2011-05-23 15:37           ` Keir Fraser
@ 2011-05-23 15:40             ` Ian Jackson
  2011-05-23 15:49               ` Keir Fraser
  0 siblings, 1 reply; 16+ messages in thread
From: Ian Jackson @ 2011-05-23 15:40 UTC (permalink / raw)
  To: Keir Fraser; +Cc: Ian Campbell, Olaf Hering, xen-devel

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.

^ permalink raw reply	[flat|nested] 16+ messages in thread
* Re: [xen-4.0-testing test] 7147: regressions - FAIL
  2011-05-23 15:40             ` Ian Jackson
@ 2011-05-23 15:49               ` Keir Fraser
  2011-05-23 16:16                 ` Keir Fraser
  0 siblings, 1 reply; 16+ messages in thread
From: Keir Fraser @ 2011-05-23 15:49 UTC (permalink / raw)
  To: Ian Jackson; +Cc: Ian Campbell, Olaf Hering, xen-devel

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.

^ permalink raw reply	[flat|nested] 16+ messages in thread
* Re: [xen-4.0-testing test] 7147: regressions - FAIL
  2011-05-23 15:49               ` Keir Fraser
@ 2011-05-23 16:16                 ` Keir Fraser
  0 siblings, 0 replies; 16+ messages in thread
From: Keir Fraser @ 2011-05-23 16:16 UTC (permalink / raw)
  To: Ian Jackson; +Cc: Ian Campbell, Olaf Hering, xen-devel

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

^ permalink raw reply	[flat|nested] 16+ messages in thread
* Re: [xen-4.0-testing test] 7147: regressions - FAIL
  2011-05-22 16:29 M A Young
@ 2011-05-22 18:10 ` Keir Fraser
  0 siblings, 0 replies; 16+ messages in thread
From: Keir Fraser @ 2011-05-22 18:10 UTC (permalink / raw)
  To: M A Young, xen-devel

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

^ permalink raw reply	[flat|nested] 16+ messages in thread
end of thread, other threads:[~2011-05-23 16:16 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-05-21 21:34 [xen-4.0-testing test] 7147: regressions - FAIL xen.org
2011-05-21 22:19 ` Keir Fraser
2011-05-23 11:10   ` Olaf Hering
2011-05-23 12:32   ` Ian Campbell
2011-05-23 14:06     ` Ian Jackson
2011-05-23 15:08       ` Ian Jackson
2011-05-23 15:14         ` Ian Campbell
2011-05-23 15:18           ` Ian Jackson
2011-05-23 15:24         ` Keir Fraser
2011-05-23 15:33           ` Ian Jackson
2011-05-23 15:37           ` Keir Fraser
2011-05-23 15:40             ` Ian Jackson
2011-05-23 15:49               ` Keir Fraser
2011-05-23 16:16                 ` Keir Fraser
2011-05-23 12:59   ` Olaf Hering
2011-05-22 16:29 M A Young
2011-05-22 18:10 ` [xen-4.0-testing " Keir Fraser

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.