| Message ID | 4EEBDE65.1@redhat.com |
|---|---|
| State | New |
| Headers | show |
> Putting into gcc/cp/config-lang.in is a layering violation, it's true. But > until there's another instance that needs handling, it seems premature to > build infrastructure to handle this. And it's only one line after all... I don't know exactly why, but this breaks bootstrap on some machines: make[3]: Entering directory `/red.a/gnatmail-x/build-red/x86_64-linux/gnat/obj/libcpp' g++ -I../../src/libcpp -I. -I../../src/libcpp/../include -I../../src/libcpp/include -O2 -g -W -Wall -Wno-narrowing -Wwrite-strings -Wmissing-format-attribute -pedantic -Wno-long-long -Werror -fno-exceptions -fno-rtti -I../../src/libcpp -I. -I../../src/libcpp/../include -I../../src/libcpp/include -c -o charset.o -MT charset.o -MMD -MP -MF .deps/charset.Tpo ../../src/libcpp/charset.c cc1plus: error: unrecognized command line option "-Wno-narrowing" make[3]: *** [charset.o] Error 1 make[3]: Leaving directory `/red.a/gnatmail-x/build-red/x86_64-linux/gnat/obj/libcpp' make[2]: *** [all-stage2-libcpp] Error 2 make[2]: Leaving directory `/red.a/gnatmail-x/build-red/x86_64-linux/gnat/obj' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/red.a/gnatmail-x/build-red/x86_64-linux/gnat/obj' I have seen that on 3 different machines (i586, i686, x86-64).
On Sat, Dec 17, 2011 at 6:19 AM, Eric Botcazou <ebotcazou@adacore.com> wrote: >> Putting into gcc/cp/config-lang.in is a layering violation, it's true. But >> until there's another instance that needs handling, it seems premature to >> build infrastructure to handle this. And it's only one line after all... > > I don't know exactly why, but this breaks bootstrap on some machines: > > make[3]: Entering directory > `/red.a/gnatmail-x/build-red/x86_64-linux/gnat/obj/libcpp' > g++ -I../../src/libcpp -I. -I../../src/libcpp/../include -I../../src/libcpp/include -O2 -g -W -Wall -Wno-narrowing -Wwrite-strings -Wmissing-format-attribute -pedantic -Wno-long-long -Werror -fno-exceptions -fno-rtti -I../../src/libcpp -I. -I../../src/libcpp/../include -I../../src/libcpp/include -c -o > charset.o -MT > charset.o -MMD -MP -MF .deps/charset.Tpo ../../src/libcpp/charset.c > cc1plus: error: unrecognized command line option "-Wno-narrowing" > make[3]: *** [charset.o] Error 1 > make[3]: Leaving directory > `/red.a/gnatmail-x/build-red/x86_64-linux/gnat/obj/libcpp' > make[2]: *** [all-stage2-libcpp] Error 2 > make[2]: Leaving directory `/red.a/gnatmail-x/build-red/x86_64-linux/gnat/obj' > make[1]: *** [stage2-bubble] Error 2 > make[1]: Leaving directory `/red.a/gnatmail-x/build-red/x86_64-linux/gnat/obj' > > I have seen that on 3 different machines (i586, i686, x86-64). > I opened: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51599
On 12/17/2011 06:19 AM, Eric Botcazou wrote: >> Putting into gcc/cp/config-lang.in is a layering violation, it's true. But >> until there's another instance that needs handling, it seems premature to >> build infrastructure to handle this. And it's only one line after all... > > I don't know exactly why, but this breaks bootstrap on some machines: > > make[3]: Entering directory > `/red.a/gnatmail-x/build-red/x86_64-linux/gnat/obj/libcpp' > g++ -I../../src/libcpp -I. -I../../src/libcpp/../include -I../../src/libcpp/include -O2 -g -W -Wall -Wno-narrowing -Wwrite-strings -Wmissing-format-attribute -pedantic -Wno-long-long -Werror -fno-exceptions -fno-rtti -I../../src/libcpp -I. -I../../src/libcpp/../include -I../../src/libcpp/include -c -o > charset.o -MT > charset.o -MMD -MP -MF .deps/charset.Tpo ../../src/libcpp/charset.c > cc1plus: error: unrecognized command line option "-Wno-narrowing" > make[3]: *** [charset.o] Error 1 > make[3]: Leaving directory > `/red.a/gnatmail-x/build-red/x86_64-linux/gnat/obj/libcpp' > make[2]: *** [all-stage2-libcpp] Error 2 > make[2]: Leaving directory `/red.a/gnatmail-x/build-red/x86_64-linux/gnat/obj' > make[1]: *** [stage2-bubble] Error 2 > make[1]: Leaving directory `/red.a/gnatmail-x/build-red/x86_64-linux/gnat/obj' > > I have seen that on 3 different machines (i586, i686, x86-64). > *shrug* It doesn't happen here. And it certainly doesn't have anything to do with that patch. r~
Richard Henderson <rth@redhat.com> writes: > There's no "good" place for this. The description in Makefile.def that libitm uses c++ is only used insofar as the dependencies for libitm -- it's built after libstdc++ as the language support library. If we put this into the toplevel configure.ac directly, we have to write a bunch of shell code which seems less than helpful. > > Putting into gcc/cp/config-lang.in is a layering violation, it's true. But until there's another instance that needs handling, it seems premature to build infrastructure to handle this. And it's only one line after all... That doesn't work. It breaks bootstrap on targets that are unsupported by libitm because the stage2 compiler is built with the host g++ instead of the stage1 g++, eventually breaking down due to -Werror. You get the same error when configuring with --disable-target-libitm. Andreas.
On Sat, 17 Dec 2011, Eric Botcazou wrote: >> Putting into gcc/cp/config-lang.in is a layering violation, it's true. But >> until there's another instance that needs handling, it seems premature to >> build infrastructure to handle this. And it's only one line after all... > I don't know exactly why, but this breaks bootstrap on some machines: I may be wrong, but it occurs to me your log already shows why? > make[3]: Entering directory > `/red.a/gnatmail-x/build-red/x86_64-linux/gnat/obj/libcpp' > g++ -I../../src/libcpp -I. -I../../src/libcpp/../include ... > cc1plus: error: unrecognized command line option "-Wno-narrowing" Here g++ is invoked without an absolute path, so if you have an older version of g++ in your path that does not grok -Wno-narrowing yet that will fail, won't it? I assume that's why only some like you and me are seeing this, but not all of us. Gerald
> Here g++ is invoked without an absolute path, so if you have an older > version of g++ in your path that does not grok -Wno-narrowing yet that > will fail, won't it? I assume that's why only some like you and me are > seeing this, but not all of us. Yes, for some reason the base C++ compiler is used instead of the stage1 one.
On Sun, 18 Dec 2011, Eric Botcazou wrote: >> Here g++ is invoked without an absolute path, so if you have an older >> version of g++ in your path that does not grok -Wno-narrowing yet that >> will fail, won't it? I assume that's why only some like you and me are >> seeing this, but not all of us. > Yes, for some reason the base C++ compiler is used instead of the stage1 one. So, the patch causing this was reverted and bootstrap worked again(?), and now it is broken again with the same failure mode: cc1: error: unrecognized command line option "-Wno-narrowing" Actually, not the same, now it is invoking system gcc instead of system g++: gcc -I/scratch/tmp/gerald/gcc-HEAD/libcpp -I. -I/scratch/tmp/gerald/gcc-HEAD/libcpp/../include -I./../intl -I/scratch/tmp/gerald/gcc-HEAD/libcpp/include -g -f keep-inline-functions -W -Wall -Wno-narrowing -Wwrite-strings -Wmissing-format-attribute -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wc++-compat -pedantic -Wno-long-long -I/scratch/tmp/gerald/gcc-HEAD/libcpp -I. -I/scratch/tmp/gerald/gcc-HEAD/libcpp/../include -I./../intl -I/scratch/tmp/gerald/gcc-HEAD/libcpp/include -c -o identifiers.o -MT identifiers.o -MMD -MP -MF .deps/identifiers.Tpo /scratch/tmp/gerald/gcc-HEAD/libcpp/identifiers.c And it happens in stage1 (stage1-bubble). Gerald
> So, the patch causing this was reverted and bootstrap worked again(?), > and now it is broken again with the same failure mode: > > cc1: error: unrecognized command line option "-Wno-narrowing" > > Actually, not the same, now it is invoking system gcc instead of > system g++: > > gcc -I/scratch/tmp/gerald/gcc-HEAD/libcpp -I. > -I/scratch/tmp/gerald/gcc-HEAD/libcpp/../include -I./../intl > -I/scratch/tmp/gerald/gcc-HEAD/libcpp/include -g -f keep-inline-functions > -W -Wall -Wno-narrowing -Wwrite-strings -Wmissing-format-attribute > -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition > -Wc++-compat -pedantic -Wno-long-long > -I/scratch/tmp/gerald/gcc-HEAD/libcpp -I. > -I/scratch/tmp/gerald/gcc-HEAD/libcpp/../include -I./../intl > -I/scratch/tmp/gerald/gcc-HEAD/libcpp/include -c -o identifiers.o -MT > identifiers.o -MMD -MP -MF .deps/identifiers.Tpo > /scratch/tmp/gerald/gcc-HEAD/libcpp/identifiers.c > > And it happens in stage1 (stage1-bubble). This looks like a different problem though, as naked 'gcc' is supposed to be invoked during stage1. I'll try to reproduce...
On 20.12.11 23:35, Eric Botcazou wrote: >> So, the patch causing this was reverted and bootstrap worked again(?), >> and now it is broken again with the same failure mode: >> >> cc1: error: unrecognized command line option "-Wno-narrowing" >> >> Actually, not the same, now it is invoking system gcc instead of >> system g++: >> >> gcc -I/scratch/tmp/gerald/gcc-HEAD/libcpp -I. >> -I/scratch/tmp/gerald/gcc-HEAD/libcpp/../include -I./../intl >> -I/scratch/tmp/gerald/gcc-HEAD/libcpp/include -g -f keep-inline-functions >> -W -Wall -Wno-narrowing -Wwrite-strings -Wmissing-format-attribute >> -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition >> -Wc++-compat -pedantic -Wno-long-long >> -I/scratch/tmp/gerald/gcc-HEAD/libcpp -I. >> -I/scratch/tmp/gerald/gcc-HEAD/libcpp/../include -I./../intl >> -I/scratch/tmp/gerald/gcc-HEAD/libcpp/include -c -o identifiers.o -MT >> identifiers.o -MMD -MP -MF .deps/identifiers.Tpo >> /scratch/tmp/gerald/gcc-HEAD/libcpp/identifiers.c >> >> And it happens in stage1 (stage1-bubble). > > This looks like a different problem though, as naked 'gcc' is supposed to be > invoked during stage1. I'll try to reproduce... Fyi, there was an issue on FreeBSD with this commit: http://gcc.gnu.org/viewcvs?view=revision&revision=182478 See at the bottom of: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51388 Andreas fixed the issue and committed a fix: http://gcc.gnu.org/ml/gcc-cvs/2011-12/msg00686.html After this commit I was able to succesfully bootstrap (r182546) on x86_64-unknown-freebsd10.0. Right now building 182566. If this is not related, pls ignore. Andreas
On Wed, 21 Dec 2011, Andreas Tobler wrote: > Andreas fixed the issue and committed a fix: > > http://gcc.gnu.org/ml/gcc-cvs/2011-12/msg00686.html > > After this commit I was able to succesfully bootstrap (r182546) on > x86_64-unknown-freebsd10.0. Yep, I am happy to confirm it also works on my testers now again. Gerald
diff --git a/gcc/cp/config-lang.in b/gcc/cp/config-lang.in index 3ed3d8e..6f9b4c9 100644 --- a/gcc/cp/config-lang.in +++ b/gcc/cp/config-lang.in @@ -28,6 +28,9 @@ language="c++" compilers="cc1plus\$(exeext)" -target_libs="target-libstdc++-v3" +# ??? libitm is not a language support library like libstdc++, but it does +# use c++, and this is the easiest way to have it be disabled if we don't +# include c++ in the set of enabled languages. +target_libs="target-libstdc++-v3 target-libitm" gtfiles="\$(srcdir)/cp/rtti.c \$(srcdir)/cp/mangle.c \$(srcdir)/cp/name-lookup.h \$(srcdir)/cp/name-lookup.c \$(srcdir)/cp/cp-tree.h \$(srcdir)/cp/decl.h \$(srcdir)/cp/call.c \$(srcdir)/cp/decl.c \$(srcdir)/cp/decl2.c \$(srcdir)/cp/pt.c \$(srcdir)/cp/repo.c \$(srcdir)/cp/semantics.c \$(srcdir)/cp/tree.c \$(srcdir)/cp/parser.h \$(srcdir)/cp/parser.c \$(srcdir)/cp/method.c \$(srcdir)/cp/typeck2.c \$(srcdir)/c-family/c-common.c \$(srcdir)/c-family/c-common.h \$(srcdir)/c-family/c-objc.h \$(srcdir)/c-family/c-lex.c \$(srcdir)/c-family/c-pragma.h \$(srcdir)/c-family/c-pragma.c \$(srcdir)/cp/class.c \$(srcdir)/cp/cp-objcp-common.c \$(srcdir)/cp/cp-lang.c \$(srcdir)/cp/except.c"
There's no "good" place for this. The description in Makefile.def that libitm uses c++ is only used insofar as the dependencies for libitm -- it's built after libstdc++ as the language support library. If we put this into the toplevel configure.ac directly, we have to write a bunch of shell code which seems less than helpful. Putting into gcc/cp/config-lang.in is a layering violation, it's true. But until there's another instance that needs handling, it seems premature to build infrastructure to handle this. And it's only one line after all... Tested on x86_64-linux and committed. r~ PR bootstrap/51072 * config-lang.in (target_libs): Include target-libitm.