[Bug bootstrap/51388] New: Configure failure to detect unsupported warning options for non-bootstrap builds (including cross builds)

[Bug bootstrap/51388] New: Configure failure to detect unsupported warning options for non-bootstrap builds (including cross builds)

[steven at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51388

             Bug #: 51388
           Summary: Configure failure to detect unsupported warning
                    options for non-bootstrap builds (including cross
                    builds)
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: bootstrap
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: steven@gcc.gnu.org


GCC current trunk (r181908) fails to do a non-bootstrap build (i.e.
--disable-bootstrap, or a cross-compiler build). The build compiler I used was
GCC 4.3. 

...
make[2]: Entering directory `/home/stevenb/devel/build/zlib'
true "AR_FLAGS=rc" "CC_FOR_BUILD=gcc" "CFLAGS=-g -O2" "CXXFLAGS=-g -O2"
"CFLAGS_FOR_BUILD=-g -O2" "CFLAGS_FOR_TARGET=-g -O2" "INSTALL=/usr/b
in/install -c" "INSTALL_DATA=/usr/bin/install -c -m 644"
"INSTALL_PROGRAM=/usr/bin/install -c" "INSTALL_SCRIPT=/usr/bin/install -c"
"LDFLAGS
=" "LIBCFLAGS=-g -O2" "LIBCFLAGS_FOR_TARGET=-g -O2" "MAKE=make"
"MAKEINFO=makeinfo --split-size=5000000 --split-size=5000000 " "PICFLAG=" "P
ICFLAG_FOR_TARGET=" "SHELL=/bin/sh" "EXPECT=expect" "RUNTEST=runtest"
"RUNTESTFLAGS=" "exec_prefix=/usr/local" "infodir=/usr/local/share/inf
o" "libdir=/usr/local/lib" "prefix=/usr/local"
"tooldir=/usr/local/x86_64-unknown-linux-gnu" "AR=ar" "AS=as" "CC=gcc"
"CXX=g++" "LD=ld" "LIB
CFLAGS=-g -O2" "NM=nm" "PICFLAG=" "RANLIB=ranlib" "DESTDIR=" DO=all multi-do #
make
make[2]: Leaving directory `/home/stevenb/devel/build/zlib'
make[2]: Entering directory `/home/stevenb/devel/build/libcpp'
gcc  -I../../trunk/libcpp -I. -I../../trunk/libcpp/../include
-I../../trunk/libcpp/include  -g -O2 -W -Wall -Wno-narrowing -Wwrite-strings -
Wmissing-format-attribute -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wc++-compat -pedantic -Wno-long-long  -I../../tru
nk/libcpp -I. -I../../trunk/libcpp/../include -I../../trunk/libcpp/include  -c
-o macro.o -MT macro.o -MMD -MP -MF .deps/macro.Tpo ../../tru
nk/libcpp/macro.c
../../trunk/libcpp/macro.c:146: warning: â?~tokens_buff_remove_last_tokenâ?T
declared inline after being called
../../trunk/libcpp/macro.c:146: warning: previous declaration of
â?~tokens_buff_remove_last_tokenâ?T was here
cc1: error: unrecognized command line option "-Wno-narrowing"
make[2]: *** [macro.o] Error 1
make[2]: Target `all' not remade because of errors.
make[2]: Leaving directory `/home/stevenb/devel/build/libcpp'
make[1]: *** [all-libcpp] Error 2
make[2]: Entering directory `/home/stevenb/devel/build/libdecnumber'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/stevenb/devel/build/libdecnumber'
make[1]: Target `all-host' not remade because of errors.
make[1]: Target `all-target' not remade because of errors.
make[1]: Leaving directory `/home/stevenb/devel/build'
make: *** [all] Error 2
$

Note the cc1 error. Problem seems to be that ACX_PROG_CC_WARNING_OPTS checks
for -Wno-narrowing in isolation, and that check passes, but the actual options
passed to GCC do not:

$ cat t.c
#ifdef HAVE_ARG
void foo (int t) { return; }
#else
void foo (void) { return; }
#endif

$ # This is how the build process calls GCC, note -W -Wall
$ gcc -c -W -Wall -Wno-narrowing t.c -DHAVE_ARG
t.c:2: warning: unused parameter â?~tâ?T
cc1: error: unrecognized command line option "-Wno-narrowing"
$ # This is how the configure check calls the compiler
$ gcc -c -Wno-narrowing t.c -DHAVE_ARG
$ 
$ # Even more confusing: Make foo a void function, and the warning
$ # does not trigger anymore at all!
$ gcc -c -W -Wall -Wno-narrowing t.c
$ gcc -c -Wno-narrowing t.c
$

[Bug bootstrap/51388] Configure failure to detect unsupported warning options for non-bootstrap builds (including cross builds)

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51388

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2011-12-02
                 CC|                            |jsm28 at gcc dot gnu.org
     Ever Confirmed|0                           |1

--- Comment #1 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-12-02 14:51:14 UTC ---
I think the issue is that we allow random -Wno- as argument, but not
positive variants.  Trunk:

> ./xgcc -B. -c t.c -Wno-foo
> ./xgcc -B. -c t.c -Wfoo
xgcc: error: unrecognized command line option '-Wfoo'

that's probably deliberate.  So the bug is that we check for
-Wno-narrowing instead of -Wnarrowing.

Now, the question is why we don't consistently error in 4.3 ...

I see

> gcc-4.3 -c -Wno-narrowing t.c -DHAVE_ARG
cc1: error: unrecognized command line option "-Wno-narrowing"

with FSF GCC 4.3.6.  So, are you sure this isn't behavior caused by
vendor patches?  (openSUSE GCC 4.3 also works)

Still the behavior of warning for -Wno- changed appearantly.  Joseph?

[Bug bootstrap/51388] Configure failure to detect unsupported warning options for non-bootstrap builds (including cross builds)

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51388

--- Comment #2 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-12-02 14:52:49 UTC ---
Since 4.4.0 we no longer warn for unrecognized -Wno- forms, thus the configure
check is broken as-is.

[Bug bootstrap/51388] Configure failure to detect unsupported warning options for non-bootstrap builds (including cross builds)

[stevenb.gcc at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51388

--- Comment #3 from stevenb.gcc at gmail dot com <stevenb.gcc at gmail dot com> 2011-12-02 14:59:37 UTC ---
On Fri, Dec 2, 2011 at 3:51 PM, rguenth at gcc dot gnu.org
<gcc-bugzilla@gcc.gnu.org> wrote:
> I see
>
>> gcc-4.3 -c -Wno-narrowing t.c -DHAVE_ARG
> cc1: error: unrecognized command line option "-Wno-narrowing"
>
> with FSF GCC 4.3.6.  So, are you sure this isn't behavior caused by
> vendor patches?  (openSUSE GCC 4.3 also works)

What do you see with "gcc-4.3 -c -Wno-narrowing t.c"?

FWIW this is Debian GCC 4.3.2-1.1 on gcc17.

[Bug bootstrap/51388] Configure failure to detect unsupported warning options for non-bootstrap builds (including cross builds)

[steven at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51388

Steven Bosscher <steven at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW

--- Comment #4 from Steven Bosscher <steven at gcc dot gnu.org> 2011-12-02 15:01:15 UTC ---
Confirmed per #2

[Bug bootstrap/51388] Configure failure to detect unsupported warning options for non-bootstrap builds (including cross builds)

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51388

--- Comment #5 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2011-12-02 16:09:57 UTC ---
On Fri, 2 Dec 2011, rguenth at gcc dot gnu.org wrote:

> Still the behavior of warning for -Wno- changed appearantly.  Joseph?

The idea was that if an unknown -Wno- option is passed, but there were no 
warnings, it doesn't matter that we don't know what warnings the -Wno- 
option might have been intended to disable because there were no warnings 
at all for it to disable - so diagnosis of unknown -Wno- options is 
deferred and they are only diagnosed if some other warning (that the 
unknown option might potentially have been intended to disable) is given.

[Bug bootstrap/51388] Configure failure to detect unsupported warning options for non-bootstrap builds (including cross builds)

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51388

--- Comment #6 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-12-02 16:20:56 UTC ---
(In reply to comment #3)
> On Fri, Dec 2, 2011 at 3:51 PM, rguenth at gcc dot gnu.org
> <gcc-bugzilla@gcc.gnu.org> wrote:
> > I see
> >
> >> gcc-4.3 -c -Wno-narrowing t.c -DHAVE_ARG
> > cc1: error: unrecognized command line option "-Wno-narrowing"
> >
> > with FSF GCC 4.3.6.  So, are you sure this isn't behavior caused by
> > vendor patches?  (openSUSE GCC 4.3 also works)
> 
> What do you see with "gcc-4.3 -c -Wno-narrowing t.c"?
> 
> FWIW this is Debian GCC 4.3.2-1.1 on gcc17.

> /space/rguenther/install/gcc-4.3.2/bin/gcc -c -Wno-narrowing t.c
cc1: error: unrecognized command line option "-Wno-narrowing"

[Bug bootstrap/51388] Configure failure to detect unsupported warning options for non-bootstrap builds (including cross builds)

[steven at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51388

--- Comment #7 from Steven Bosscher <steven at gcc dot gnu.org> 2011-12-02 16:48:45 UTC ---
(In reply to comment #1)
> Now, the question is why we don't consistently error in 4.3 ...
> 
> I see
> 
> > gcc-4.3 -c -Wno-narrowing t.c -DHAVE_ARG
> cc1: error: unrecognized command line option "-Wno-narrowing"
> 
> with FSF GCC 4.3.6.  So, are you sure this isn't behavior caused by
> vendor patches?  (openSUSE GCC 4.3 also works)

I think this is due to the patch "pr28322.dpatch" in the Debian GCC 4.3.2-1.1
package. IIUC that patch is also in GCC 4.4. Is that something you can confirm?

[Bug bootstrap/51388] Configure failure to detect unsupported warning options for non-bootstrap builds (including cross builds)

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51388

--- Comment #8 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2011-12-02 16:59:30 UTC ---
(In reply to comment #5)
> On Fri, 2 Dec 2011, rguenth at gcc dot gnu.org wrote:
> 
> > Still the behavior of warning for -Wno- changed appearantly.  Joseph?
> 
> The idea was that if an unknown -Wno- option is passed, but there were no 
> warnings, it doesn't matter that we don't know what warnings the -Wno- 
> option might have been intended to disable because there were no warnings 
> at all for it to disable - so diagnosis of unknown -Wno- options is 
> deferred and they are only diagnosed if some other warning (that the 
> unknown option might potentially have been intended to disable) is given.

That is right. This was requested precisely by Debian GCC maintainers. In fact,
clang seems to follow gcc now, except that they only warn (instead of error)
for unknown positive options:

manuel@gcc12:~$ ~/bin/clang++  pr42356.cc -Wwhatever
warning: unknown warning option '-Wwhatever' [-Wunknown-warning-option]

In any case, how is it -Wno-long-long tested by configure? I guess configure
could test whether "-Wnarrowing -Wno-narrowing" is accepted, or test with a
testcase that triggers a default warning like "1/0".

[Bug bootstrap/51388] Configure failure to detect unsupported warning options for non-bootstrap builds (including cross builds)

[schwab at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51388

--- Comment #9 from Andreas Schwab <schwab at gcc dot gnu.org> 2011-12-19 13:12:31 UTC ---
Author: schwab
Date: Mon Dec 19 13:12:26 2011
New Revision: 182478

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182478
Log:
Check for warning flags without no- prefix

config/:
    PR bootstrap/51388
    * warnings.m4 (ACX_PROG_CC_WARNING_OPTS)
    (ACX_PROG_CC_WARNING_ALMOST_PEDANTIC): Run the test without the
    no- prefix.
fixincludes/:
    * configure: Regenerate.
gcc/:
    * configure: Regenerate.
libcpp/:
    * configure: Regenerate.
libdecnumber/:
    * configure: Regenerate.
libiberty/:
    * configure: Regenerate.
lto-plugin/:
    * configure: Regenerate.

Modified:
    trunk/config/ChangeLog
    trunk/config/warnings.m4
    trunk/fixincludes/ChangeLog
    trunk/fixincludes/configure
    trunk/gcc/ChangeLog
    trunk/gcc/configure
    trunk/libcpp/ChangeLog
    trunk/libcpp/configure
    trunk/libdecnumber/ChangeLog
    trunk/libdecnumber/configure
    trunk/libiberty/ChangeLog
    trunk/libiberty/configure
    trunk/lto-plugin/ChangeLog
    trunk/lto-plugin/configure

[Bug bootstrap/51388] Configure failure to detect unsupported warning options for non-bootstrap builds (including cross builds)

[andreast at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51388

Andreas Tobler <andreast at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andreast at gcc dot gnu.org

--- Comment #10 from Andreas Tobler <andreast at gcc dot gnu.org> 2011-12-20 14:42:03 UTC ---


-Wno-*) option=-W`expr $real_option : '-Wno-\(.*\)'` ;;

The expr on FreeBSD treats leading minus (-) in an expression as an option.
Therefor this does not work there. I'm trying to find a solution.
One would be to remove the leading minus.

[Bug bootstrap/51388] Configure failure to detect unsupported warning options for non-bootstrap builds (including cross builds)

[schwab@linux-m68k.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51388

--- Comment #11 from Andreas Schwab <schwab@linux-m68k.org> 2011-12-20 15:48:28 UTC ---
Does this work?

diff --git a/config/warnings.m4 b/config/warnings.m4
index 292e5a4..b64b594 100644
--- a/config/warnings.m4
+++ b/config/warnings.m4
@@ -32,7 +32,7 @@ for real_option in $1; do
   # Do the check with the no- prefix removed since gcc silently
   # accepts any -Wno-* option on purpose
   case $real_option in
-    -Wno-*) option=-W`expr $real_option : '-Wno-\(.*\)'` ;;
+    -Wno-*) option=-W`expr x$real_option : 'x-Wno-\(.*\)'` ;;
     *) option=$real_option ;;
   esac
   AS_VAR_PUSHDEF([acx_Woption], [acx_cv_prog_cc_warning_$option])

[Bug bootstrap/51388] Configure failure to detect unsupported warning options for non-bootstrap builds (including cross builds)

[andreast at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51388

--- Comment #12 from Andreas Tobler <andreast at gcc dot gnu.org> 2011-12-20 15:57:36 UTC ---
Seems to work. At least in stage one, compiling gcc.

Thank you!