Re: PATCH RFA: Build stages 2 and 3 with C++
A comment on the documentation:
Index: gcc/doc/install.texi
===
--- gcc/doc/install.texi (revision 176348)
+++ gcc/doc/install.texi (working copy)
@@ -1286,6 +1286,13 @@ will try to guess whether the @code{.ini
Build GCC using a C++ compiler rather than a C compiler. This is an
experimental option which may become the default in a later release.
+@item --enable-build-poststage1-with-cxx
+When bootstrapping, build stages 2 and 3 of GCC using a C++ compiler
+rather than a C compiler. Stage 1 is still built with a C compiler.
+This is an experimental option which may become the default in a later
+release. This is enabled by default and may be disabled using
+@option{--disable-build-poststage1-with-cxx}.
+
The document says This is an experimental option which may become the
default in a later release and then says This is enabled by default.
The latter statement is true.
Re: PATCH RFA: Build stages 2 and 3 with C++
Gary Funck g...@intrepid.com writes:
A comment on the documentation:
Index: gcc/doc/install.texi
===
--- gcc/doc/install.texi (revision 176348)
+++ gcc/doc/install.texi (working copy)
@@ -1286,6 +1286,13 @@ will try to guess whether the @code{.ini
Build GCC using a C++ compiler rather than a C compiler. This is an
experimental option which may become the default in a later release.
+@item --enable-build-poststage1-with-cxx
+When bootstrapping, build stages 2 and 3 of GCC using a C++ compiler
+rather than a C compiler. Stage 1 is still built with a C compiler.
+This is an experimental option which may become the default in a later
+release. This is enabled by default and may be disabled using
+@option{--disable-build-poststage1-with-cxx}.
+
The document says This is an experimental option which may become the
default in a later release and then says This is enabled by default.
The latter statement is true.
Thanks for pointing this out. I committed this patch to fix this in the
obvious way. Bootstrapped on x86_64-unknown-linux-gnu.
Ian
2011-11-22 Ian Lance Taylor i...@google.com
* doc/install.texi (Configuration): Correct doc of
--enable-build-poststage1-with-cxx: it is not experimental.
Index: doc/install.texi
===
--- doc/install.texi (revision 181627)
+++ doc/install.texi (working copy)
@@ -1298,8 +1298,7 @@ experimental option which may become the
@item --enable-build-poststage1-with-cxx
When bootstrapping, build stages 2 and 3 of GCC using a C++ compiler
rather than a C compiler. Stage 1 is still built with a C compiler.
-This is an experimental option which may become the default in a later
-release. This is enabled by default and may be disabled using
+This is enabled by default and may be disabled using
@option{--disable-build-poststage1-with-cxx}.
@item --enable-maintainer-mode
Re: PATCH RFA: Build stages 2 and 3 with C++
On 07/15/11 23:52:46, Ian Lance Taylor wrote: [...] @@ -444,6 +448,9 @@ STAGE1_LANGUAGES = @stage1_languages@ # the last argument when conflicting --enable arguments are passed. # * Likewise, we force-disable coverage flags, since the installed # compiler probably has never heard of them. +# * Don't remove this, because above we added +# POSTSTAGE1_CONFIGURE_FLAGS to STAGE[+id+]_CONFIGURE_FLAGS, which +# we don't want for STAGE1_CONFIGURE_FLAGS. STAGE1_CONFIGURE_FLAGS = --disable-intermodule $(STAGE1_CHECKING) \ --disable-coverage --enable-languages=$(STAGE1_LANGUAGES) When g++ is used to compile gcc in stages 2 and 3, which compilation flags (CFLAGS or CXXFLAGS) are in force? If CXXFLAGS, is this a potentially surprising departure from previous configure behavior? thanks, - Gary
Re: PATCH RFA: Build stages 2 and 3 with C++
Gary Funck g...@intrepid.com writes: On 07/15/11 23:52:46, Ian Lance Taylor wrote: [...] @@ -444,6 +448,9 @@ STAGE1_LANGUAGES = @stage1_languages@ # the last argument when conflicting --enable arguments are passed. # * Likewise, we force-disable coverage flags, since the installed # compiler probably has never heard of them. +# * Don't remove this, because above we added +# POSTSTAGE1_CONFIGURE_FLAGS to STAGE[+id+]_CONFIGURE_FLAGS, which +# we don't want for STAGE1_CONFIGURE_FLAGS. STAGE1_CONFIGURE_FLAGS = --disable-intermodule $(STAGE1_CHECKING) \ --disable-coverage --enable-languages=$(STAGE1_LANGUAGES) When g++ is used to compile gcc in stages 2 and 3, which compilation flags (CFLAGS or CXXFLAGS) are in force? CXXFLAGS. If CXXFLAGS, is this a potentially surprising departure from previous configure behavior? Perhaps. I don't see how we could reasonably make any other choice, though. Ian
Re: PATCH RFA: Build stages 2 and 3 with C++
On 11/22/11 11:32:03, Ian Lance Taylor wrote: If CXXFLAGS, is this a potentially surprising departure from previous configure behavior? Perhaps. I don't see how we could reasonably make any other choice,though. Agreed. Just wondering if there might be potential documentation impact, re: configure/build.
Re: PATCH RFA: Build stages 2 and 3 with C++
Hi! On Sat, 16 Jul 2011 11:27:46 -0400, Diego Novillo dnovi...@google.com wrote: On Sat, Jul 16, 2011 at 02:52, Ian Lance Taylor i...@google.com wrote: 2011-07-15 Ian Lance Taylor i...@google.com * configure.ac: Add --enable-build-poststage1-with-cxx. If set, make C++ a boot_language. Set and substitute POSTSTAGE1_CONFIGURE_FLAGS. * Makefile.tpl (POSTSTAGE1_CONFIGURE_FLAGS): New variable. (STAGE[+id+]_CONFIGURE_FLAGS): Add $(POSTSTAGE1_CONFIGURE_FLAGS). * configure, Makefile.in: Rebuild. I agree with this change. For reference, have you measured the difference in bootstrap time? Clearly, it will be slower, but how much? I can provide some data from my GNU/Hurd regression and comparing to GNU/Linux testing. This is GCC Git master branch, going from 7c9f953a01d23c6b6885dc908d5b1dba8009efd4 (2011-07-18; ``before'') to 18540031a8b2070a56f5b7e94d6b24e8bd335c57 (2011-07-20; ``after''); which is shortly before and after the switch to using g++. For GNU/Hurd, I have applied a few patches that are minor to this experiment. kepler is a Xen domU on a AMD Athlon II X2 215 with 2700 MHz, the domU has 1 GiB of RAM, and is running Debian GNU/Linux testing x86. coulomb is a AMD Athlon XP with 1466 MHz, has 1 GiB of RAM, and is running Debian GNU/Hurd unstable x86. kepler coulomb before 2 h 35 min 10 h 50 min after 3 h 00 min 13 h 00 min The ``after'' data is averaged from two iterations only, ``before'' data has seen many more iterations, and has (roughly) been constant over a long period of time. Both systems have been idle apart from the GCC build. The build was essentially a native ``configure make''. So, yes, bootstrap is slower now. The bootstrap time now is 16 % to 20 % longer, roughly. Grüße, Thomas pgparneuDYJvY.pgp Description: PGP signature
Re: PATCH RFA: Build stages 2 and 3 with C++
Romain Geissler romain.geiss...@gmail.com writes:
This new build behavior broke former plugins built with gcc. Indeed,
all cc1 function symbols are now mangled and thus with the current
trunk, plugins should also look for mangled symbols (and so built
with g++).
What's the new GCC policy about that ? Do plugins have to be built
using g++ only, or does the plugin developer have the choice to
use both gcc and g++ according to it's need (at the cost of adding
extern C {…} in almost every headers to forbid mangling) ?
I think that ideally we would have a well-defined plugin interface,
plugins would stick to calling that, and that interface would be a C
interface. (I see that gcc-plugin.h does already provide a C interface
even when gcc is compiled with C++.)
However, since we currently permit plugins to call anything in gcc, I
think the answer is going to have to be that plugins which do that
should be compiled with C++. I don't think that adding extern C to
all gcc header files is the right approach. Adding extern C to a few
selected header files seems fine.
Ian
Re: PATCH RFA: Build stages 2 and 3 with C++
Le 8 août 2011 à 20:49, Ian Lance Taylor a écrit : However, since we currently permit plugins to call anything in gcc, I think the answer is going to have to be that plugins which do that should be compiled with C++. Ok, i'll move to C++ then, until a dedicated C plugin API comes out. I don't think that adding extern C to all gcc header files is the right approach. Adding extern C to a few selected header files seems fine. Adding extern C to a small set of files doesn't make sense to me. When working with real-world plugin, you will certainly end up calling many different gcc primitives coming from a wide bunch of header files (which for most of them don't use extern C for now). This hack should be applied to all of the plugin visible files, or none, but not to just a few when someone needs it.
Re: PATCH RFA: Build stages 2 and 3 with C++
On 07/22/2011 07:45 AM, Ian Lance Taylor wrote: OK for mainline? Sure. Paolo.
Re: PATCH RFA: Build stages 2 and 3 with C++
This is not the global constructor/destructor issue with names generated by collect2. But ELF or SVR4 is able to provide a unique name without resorting to random numbers. Not clear if the name needs be unique at all if you have the right features, see name-lookup.c:get_anonymous_namespace_name. -- Eric Botcazou
Re: PATCH RFA: Build stages 2 and 3 with C++
On Wed, 20 Jul 2011 14:41:16 -0700
Ian Lance Taylor i...@google.com wrote:
Mike Stump mikest...@comcast.net writes:
Presumably the fix will be to use -frandom-seed.
But, the random seem was to ensure that things that should not collide,
don't. If you use 0, then things that should not collide, eventually will
and your world with then end. In the present code base, it is perfectly
safe to do this. If the codebase is ever extended to use C++ features,
then, that code can break.
I wasn't suggesting using -frandom-seed=0.
I have a similar issue in the MELT branch, and I am passing to -frandom-seed
the md5sum
of relevant source files. With such a trick, the seed is reproducible from one
build to
the next one (of the exact same source tree), and does provide much more
randomness than
just using 0 all the time.
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: PATCH RFA: Build stages 2 and 3 with C++
On Wed, Jul 20, 2011 at 4:25 PM, Ian Lance Taylor i...@google.com wrote: Presumably the fix will be to use -frandom-seed. Does this patch fix the problem? (The only real change is to fragment.am, the other changes are all generated by automake). This patch gets the build past the compiler and runtime, although the build time now is much longer on AIX. Thanks, David
Re: PATCH RFA: Build stages 2 and 3 with C++
Basile Starynkevitch bas...@starynkevitch.net writes: I have a similar issue in the MELT branch, and I am passing to -frandom-seed the md5sum of relevant source files. With such a trick, the seed is reproducible from one build to the next one (of the exact same source tree), and does provide much more randomness than just using 0 all the time. In practice I think it is fine to just pass the source file name to -frandom-seed. That's what the patch I sent out does. The source file name should be unique within a given program. Ian
Re: PATCH RFA: Build stages 2 and 3 with C++
On Thu, Jul 21, 2011 at 08:51:46AM -0700, Ian Lance Taylor wrote: Basile Starynkevitch bas...@starynkevitch.net writes: I have a similar issue in the MELT branch, and I am passing to -frandom-seed the md5sum of relevant source files. With such a trick, the seed is reproducible from one build to the next one (of the exact same source tree), and does provide much more randomness than just using 0 all the time. In practice I think it is fine to just pass the source file name to -frandom-seed. That's what the patch I sent out does. The source file name should be unique within a given program. Isn't the filename already encoded in what get_file_function_name returns? It is filename_weak_var_name_crc32_random_seed_crc32, so IMHO -frandom-seed=$@ brings almost no advantages at all over -frandom-seed=0. Except perhaps for the characters from the filename that are wiped into _ by clean_symbol_name. Jakub
Re: PATCH RFA: Build stages 2 and 3 with C++
Jakub Jelinek ja...@redhat.com writes: On Thu, Jul 21, 2011 at 08:51:46AM -0700, Ian Lance Taylor wrote: Basile Starynkevitch bas...@starynkevitch.net writes: I have a similar issue in the MELT branch, and I am passing to -frandom-seed the md5sum of relevant source files. With such a trick, the seed is reproducible from one build to the next one (of the exact same source tree), and does provide much more randomness than just using 0 all the time. In practice I think it is fine to just pass the source file name to -frandom-seed. That's what the patch I sent out does. The source file name should be unique within a given program. Isn't the filename already encoded in what get_file_function_name returns? It is filename_weak_var_name_crc32_random_seed_crc32, so IMHO -frandom-seed=$@ brings almost no advantages at all over -frandom-seed=0. Except perhaps for the characters from the filename that are wiped into _ by clean_symbol_name. That's a fair point, but I guess I still think using the file name with -frandom-seed is going to be more future-proof against other users of random numbers. Ian
Re: PATCH RFA: Build stages 2 and 3 with C++
On Thu, 21 Jul 2011 11:13:00 -0700
Ian Lance Taylor i...@google.com wrote:
Jakub Jelinek ja...@redhat.com writes:
On Thu, Jul 21, 2011 at 08:51:46AM -0700, Ian Lance Taylor wrote:
Basile Starynkevitch bas...@starynkevitch.net writes:
I have a similar issue in the MELT branch, and I am passing to
-frandom-seed the md5sum
of relevant source files. With such a trick, the seed is reproducible
from one build to
the next one (of the exact same source tree), and does provide much more
randomness than
just using 0 all the time.
In practice I think it is fine to just pass the source file name to
-frandom-seed. That's what the patch I sent out does. The source file
name should be unique within a given program.
Isn't the filename already encoded in what get_file_function_name returns?
It is filename_weak_var_name_crc32_random_seed_crc32, so IMHO
-frandom-seed=$@ brings almost no advantages at all over -frandom-seed=0.
Except perhaps for the characters from the filename that are
wiped into _ by clean_symbol_name.
That's a fair point, but I guess I still think using the file name with
-frandom-seed is going to be more future-proof against other users of
random numbers.
Using the md5sum of the file is probably not bad neither. I would understand
that you
find it being perhaps too complex for your need, but it is much more random
than just the
file name (because the md5sum changes with the file content).
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: PATCH RFA: Build stages 2 and 3 with C++
Basile Starynkevitch bas...@starynkevitch.net writes: Using the md5sum of the file is probably not bad neither. I would understand that you find it being perhaps too complex for your need, but it is much more random than just the file name (because the md5sum changes with the file content). Granted, but I am concerned about the affect on bootstrap time. Ian
Re: PATCH RFA: Build stages 2 and 3 with C++
David Edelsohn dje@gmail.com writes: On Wed, Jul 20, 2011 at 4:25 PM, Ian Lance Taylor i...@google.com wrote: Presumably the fix will be to use -frandom-seed. Does this patch fix the problem? (The only real change is to fragment.am, the other changes are all generated by automake). This patch gets the build past the compiler and runtime, although the build time now is much longer on AIX. I have bootstrapped with the patch and run the libstdc++ testsuite on x86_64-unknown-linux-gnu. OK for mainline? Ian 2011-07-21 Ian Lance Taylor i...@google.com * fragment.am (CONFIG_CXXFLAGS): Add -frandom-seed. * Makefile.in: Rebuild. * doc/Makefile.in: Rebuild. * include/Makefile.in: Rebuild. * libsupc++/Makefile.in: Rebuild. * po/Makefile.in: Rebuild. * python/Makefile.in: Rebuild. * src/Makefile.in: Rebuild. * testsuite/Makefile.in: Rebuild. Index: fragment.am === --- fragment.am (revision 176515) +++ fragment.am (working copy) @@ -16,7 +16,7 @@ toolexeclibdir = $(glibcxx_toolexeclibdi # These bits are all figured out from configure. Look in acinclude.m4 # or configure.ac to see how they are set. See GLIBCXX_EXPORT_FLAGS. CONFIG_CXXFLAGS = \ - $(SECTION_FLAGS) $(EXTRA_CXX_FLAGS) + $(SECTION_FLAGS) $(EXTRA_CXX_FLAGS) -frandom-seed=$@ WARN_CXXFLAGS = \ $(WARN_FLAGS) $(WERROR) -fdiagnostics-show-location=once
Re: PATCH RFA: Build stages 2 and 3 with C++
On 20 July 2011 02:14, David Edelsohn wrote: On Tue, Jul 19, 2011 at 2:33 PM, Ian Lance Taylor i...@google.com wrote: I got agreement from two global reviewers and no objections. I have committed this patch. Please let me know about any problems. This also breaks bootstrap on AIX. I cannot debug further at the moment because of a separate problem with the infrastructure at IBM, but I receive the following error during the first build of libstdc++: In file included from /farm/dje/src/src/libstdc++-v3/src/debug.cc:30:0: /tmp/20110719/powerpc-ibm-aix5.3.0.0/libstdc++-v3/include/debug/safe_local_iterator.h:91:50: error: 'size_t' has not been declared Hmm, that should possibly be using std::size_t instead. We ensure std::size_t has been declared by the library, but not necessarily ::size_t
Re: PATCH RFA: Build stages 2 and 3 with C++
On 20 July 2011 09:35, Jonathan Wakely wrote: On 20 July 2011 02:14, David Edelsohn wrote: On Tue, Jul 19, 2011 at 2:33 PM, Ian Lance Taylor i...@google.com wrote: I got agreement from two global reviewers and no objections. I have committed this patch. Please let me know about any problems. This also breaks bootstrap on AIX. I cannot debug further at the moment because of a separate problem with the infrastructure at IBM, but I receive the following error during the first build of libstdc++: In file included from /farm/dje/src/src/libstdc++-v3/src/debug.cc:30:0: /tmp/20110719/powerpc-ibm-aix5.3.0.0/libstdc++-v3/include/debug/safe_local_iterator.h:91:50: error: 'size_t' has not been declared Hmm, that should possibly be using std::size_t instead. We ensure std::size_t has been declared by the library, but not necessarily ::size_t Paolo has committed a change to that code, does it help the AIX bootstrap issue?
Re: PATCH RFA: Build stages 2 and 3 with C++
On Wed, Jul 20, 2011 at 3:37 AM, Ian Lance Taylor i...@google.com wrote: H.J. Lu hjl.to...@gmail.com writes: It caused: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49787 Here is a patch. Tested only by running configure, though I am starting a bootstrap. OK for mainline? Ok. Thanks, Richard. Ian 2011-07-19 Ian Lance Taylor i...@google.com PR bootstrap/49787 * configure.ac: Move --enable-bootstrap handling earlier in file. If --enable-bootstrap and either --enable-build-with-cxx or --enable-build-poststage1-with-cxx, enable C++ automatically. * configure: Rebuild.
Re: PATCH RFA: Build stages 2 and 3 with C++
On Wed, Jul 20, 2011 at 5:43 AM, Jonathan Wakely jwakely@gmail.com wrote: Paolo has committed a change to that code, does it help the AIX bootstrap issue? Paolo's patch gets me past the debug.cc issue. Using C++ on AIX will greatly increase the bootstrap time on AIX because configure is much slower, even using Bash instead of AIX Ksh. And, as this libstdc++ typo demonstrates, using C++ with the development version of libstdc++ makes the bootstrap process more fragile because bootstrap now relies on a complex, additional codebase that is not stable. GMP, MPFR, MPC, CLooG and PPL add large, external codebases, but at least they do not change from build to build, even if they are built in the tree. - David
Re: PATCH RFA: Build stages 2 and 3 with C++
On Wed, Jul 20, 2011 at 2:36 PM, David Edelsohn dje@gmail.com wrote: On Wed, Jul 20, 2011 at 5:43 AM, Jonathan Wakely jwakely@gmail.com wrote: Paolo has committed a change to that code, does it help the AIX bootstrap issue? Paolo's patch gets me past the debug.cc issue. Using C++ on AIX will greatly increase the bootstrap time on AIX because configure is much slower, even using Bash instead of AIX Ksh. And, as this libstdc++ typo demonstrates, using C++ with the development version of libstdc++ makes the bootstrap process more fragile because bootstrap now relies on a complex, additional codebase that is not stable. Which is good as it increases testing coverage. We probably would have missed this bug completely if you wouldn't have notice it. Richard.
Re: PATCH RFA: Build stages 2 and 3 with C++
On Wed, Jul 20, 2011 at 08:41, Richard Guenther richard.guent...@gmail.com wrote: Which is good as it increases testing coverage. We probably would have missed this bug completely if you wouldn't have notice it. Agreed. The pain we feel due to this is similar to the pain one feels after exercising vigorously. Diego.
Re: PATCH RFA: Build stages 2 and 3 with C++
Diego Novillo dnovi...@google.com writes: On Wed, Jul 20, 2011 at 08:41, Richard Guenther richard.guent...@gmail.com wrote: Which is good as it increases testing coverage. We probably would have missed this bug completely if you wouldn't have notice it. Agreed. The pain we feel due to this is similar to the pain one feels after exercising vigorously. I am going to use this quote with all of my patches. Ian
Re: PATCH RFA: Build stages 2 and 3 with C++
On 07/19/2011 08:33 PM, Ian Lance Taylor wrote: 2011-07-15 Ian Lance Taylori...@google.com * configure.ac: Add --enable-build-poststage1-with-cxx. If set, make C++ a boot_language. Set and substitute POSTSTAGE1_CONFIGURE_FLAGS. * Makefile.tpl (POSTSTAGE1_CONFIGURE_FLAGS): New variable. (STAGE[+id+]_CONFIGURE_FLAGS): Add $(POSTSTAGE1_CONFIGURE_FLAGS). * configure, Makefile.in: Rebuild. I got agreement from two global reviewers and no objections. I have committed this patch. Please let me know about any problems. This was probably the reason for: http://gcc.gnu.org/ml/gcc-testresults/2011-07/msg02302.html I subsequently performed the following bootstrap (--enable-languages=c++), which succeeded: http://gcc.gnu.org/ml/gcc-testresults/2011-07/msg02352.html So I changed my lto bootstrap script to do the following: language=fortran if [ $RANDOM -lt 16384 ] then language=ada fi ... ../gcc/configure \ ... --enable-languages=c++,$language \ Still have to see if this will fit in the 2:20 hour gap between two weather forecasting runs. Cheers, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Re: PATCH RFA: Build stages 2 and 3 with C++
Toon Moene t...@moene.org writes: On 07/19/2011 08:33 PM, Ian Lance Taylor wrote: 2011-07-15 Ian Lance Taylori...@google.com * configure.ac: Add --enable-build-poststage1-with-cxx. If set, make C++ a boot_language. Set and substitute POSTSTAGE1_CONFIGURE_FLAGS. * Makefile.tpl (POSTSTAGE1_CONFIGURE_FLAGS): New variable. (STAGE[+id+]_CONFIGURE_FLAGS): Add $(POSTSTAGE1_CONFIGURE_FLAGS). * configure, Makefile.in: Rebuild. I got agreement from two global reviewers and no objections. I have committed this patch. Please let me know about any problems. This was probably the reason for: http://gcc.gnu.org/ml/gcc-testresults/2011-07/msg02302.html Yes. I just committed a patch to fix that problem. Ian
Re: PATCH RFA: Build stages 2 and 3 with C++
Feel the burn^Wchurn! On 20/07/2011, Ian Lance Taylor i...@google.com wrote: Diego Novillo dnovi...@google.com writes: On Wed, Jul 20, 2011 at 08:41, Richard Guenther richard.guent...@gmail.com wrote: Which is good as it increases testing coverage. We probably would have missed this bug completely if you wouldn't have notice it. Agreed. The pain we feel due to this is similar to the pain one feels after exercising vigorously. I am going to use this quote with all of my patches. Ian
Re: PATCH RFA: Build stages 2 and 3 with C++
AIX needs libsupc++ for libstdc++ static linking. * Makefile.tpl (POSTSTAGE1_CONFIGURE_FLAGS): Add libsupc++ to link directories. * Makefile.in: Rebuild. Index: Makefile.tpl === --- Makefile.tpl(revision 176487) +++ Makefile.tpl(working copy) @@ -240,10 +240,13 @@ CXX=$(STAGE_CC_WRAPPER) $$r/$(HOST_SUBDIR)/prev-gcc/g++$(exeext) \ -B$$r/$(HOST_SUBDIR)/prev-gcc/ -B$(build_tooldir)/bin/ -nostdinc++ \ -B$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/src/.libs \ + -B$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/libsupc++/.libs \ -I$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/include/$(TARGET_SUBDIR) \ -I$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/include \ -I$$s/libstdc++-v3/libsupc++ \ - -L$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/src/.libs; export CXX; \ + -L$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/src/.libs \ + -L$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/libsupc++/.libs; + export CXX; \ CXX_FOR_BUILD=$$CXX; export CXX_FOR_BUILD; @endif target-libstdc++-v3-bootstrap
Re: PATCH RFA: Build stages 2 and 3 with C++
Hi! On Wed, 20 Jul 2011 11:41:37 -0400, David Edelsohn dje@gmail.com wrote: AIX needs libsupc++ for libstdc++ static linking. * Makefile.tpl (POSTSTAGE1_CONFIGURE_FLAGS): Add libsupc++ to link directories. * Makefile.in: Rebuild. Index: Makefile.tpl === --- Makefile.tpl(revision 176487) +++ Makefile.tpl(working copy) @@ -240,10 +240,13 @@ CXX=$(STAGE_CC_WRAPPER) $$r/$(HOST_SUBDIR)/prev-gcc/g++$(exeext) \ -B$$r/$(HOST_SUBDIR)/prev-gcc/ -B$(build_tooldir)/bin/ -nostdinc++ \ -B$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/src/.libs \ + -B$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/libsupc++/.libs \ -I$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/include/$(TARGET_SUBDIR) \ -I$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/include \ -I$$s/libstdc++-v3/libsupc++ \ - -L$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/src/.libs; export CXX; \ + -L$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/src/.libs \ + -L$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/libsupc++/.libs; + export CXX; \ CXX_FOR_BUILD=$$CXX; export CXX_FOR_BUILD; @endif target-libstdc++-v3-bootstrap Doesn't this need a backslash at the end of the second-last + line, too? + -L$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/libsupc++/.libs; \ + export CXX; \ Grüße, Thomas pgpM3Xaonxlvd.pgp Description: PGP signature
Re: PATCH RFA: Build stages 2 and 3 with C++
David Edelsohn dje@gmail.com writes: AIX needs libsupc++ for libstdc++ static linking. * Makefile.tpl (POSTSTAGE1_CONFIGURE_FLAGS): Add libsupc++ to link directories. * Makefile.in: Rebuild. Index: Makefile.tpl === --- Makefile.tpl(revision 176487) +++ Makefile.tpl(working copy) @@ -240,10 +240,13 @@ CXX=$(STAGE_CC_WRAPPER) $$r/$(HOST_SUBDIR)/prev-gcc/g++$(exeext) \ -B$$r/$(HOST_SUBDIR)/prev-gcc/ -B$(build_tooldir)/bin/ -nostdinc++ \ -B$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/src/.libs \ + -B$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/libsupc++/.libs \ -I$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/include/$(TARGET_SUBDIR) \ -I$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/include \ -I$$s/libstdc++-v3/libsupc++ \ - -L$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/src/.libs; export CXX; \ + -L$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/src/.libs \ + -L$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/libsupc++/.libs; + export CXX; \ CXX_FOR_BUILD=$$CXX; export CXX_FOR_BUILD; @endif target-libstdc++-v3-bootstrap This is OK. Thanks. Ian
Re: PATCH RFA: Build stages 2 and 3 with C++
I now can get through the build of the compiler, but stage2 and stage3 libstdc++ and libsupc++ files have many comparison failures due to tree.c:get_file_function_name() introducing explicit randomness to produce different symbols for anonymous namespaces: /* Otherwise, the name must be unique across the entire link. We don't have anything that we know to be unique to this translation unit, so use what we do have and throw in some randomness. */ unsigned len; const char *name = weak_global_object_name; const char *file = main_input_filename; if (! name) name = ; if (! file) file = input_filename; len = strlen (file); q = (char *) alloca (9 * 2 + len + 1); memcpy (q, file, len + 1); sprintf (q + len, _%08X_%08X, crc32_string (0, name), crc32_string (0, get_random_seed (false))); producing differences like: - .lglobl H.92.._ZN10__cxxabiv176_GLOBAL__N__farm_dje_src_src_libstdc___v3_libsupc___vec.cc__8F8DBED417uncatch_exceptionC2Ev - .lglobl H.100.._ZN10__cxxabiv176_GLOBAL__N__farm_dje_src_src_libstdc___v3_libsupc___vec.cc__8F8DBED417uncatch_exceptionC1Ev - .lglobl H.114.._ZN10__cxxabiv176_GLOBAL__N__farm_dje_src_src_libstdc___v3_libsupc___vec.cc__8F8DBED417uncatch_exceptionD2Ev - .lglobl H.121.._ZN10__cxxabiv176_GLOBAL__N__farm_dje_src_src_libstdc___v3_libsupc___vec.cc__8F8DBED417uncatch_exceptionD1Ev + .lglobl H.92.._ZN10__cxxabiv176_GLOBAL__N__farm_dje_src_src_libstdc___v3_libsupc___vec.cc__2322ABD117uncatch_exceptionC2Ev + .lglobl H.100.._ZN10__cxxabiv176_GLOBAL__N__farm_dje_src_src_libstdc___v3_libsupc___vec.cc__2322ABD117uncatch_exceptionC1Ev + .lglobl H.114.._ZN10__cxxabiv176_GLOBAL__N__farm_dje_src_src_libstdc___v3_libsupc___vec.cc__2322ABD117uncatch_exceptionD2Ev + .lglobl H.121.._ZN10__cxxabiv176_GLOBAL__N__farm_dje_src_src_libstdc___v3_libsupc___vec.cc__2322ABD117uncatch_exceptionD1Ev - David
Re: PATCH RFA: Build stages 2 and 3 with C++
David Edelsohn dje@gmail.com writes: I now can get through the build of the compiler, but stage2 and stage3 libstdc++ and libsupc++ files have many comparison failures due to tree.c:get_file_function_name() introducing explicit randomness to produce different symbols for anonymous namespaces: Interesting. I don't know why this doesn't happen on GNU/Linux. Perhaps AIX has symbols which are dropped on GNU/Linux for some reason. Presumably the fix will be to use -frandom-seed. Does this patch fix the problem? (The only real change is to fragment.am, the other changes are all generated by automake). Ian Index: fragment.am === --- fragment.am (revision 176515) +++ fragment.am (working copy) @@ -16,7 +16,7 @@ toolexeclibdir = $(glibcxx_toolexeclibdi # These bits are all figured out from configure. Look in acinclude.m4 # or configure.ac to see how they are set. See GLIBCXX_EXPORT_FLAGS. CONFIG_CXXFLAGS = \ - $(SECTION_FLAGS) $(EXTRA_CXX_FLAGS) + $(SECTION_FLAGS) $(EXTRA_CXX_FLAGS) -frandom-seed=$@ WARN_CXXFLAGS = \ $(WARN_FLAGS) $(WERROR) -fdiagnostics-show-location=once Index: python/Makefile.in === --- python/Makefile.in (revision 176515) +++ python/Makefile.in (working copy) @@ -291,7 +291,7 @@ toolexeclibdir = $(glibcxx_toolexeclibdi # These bits are all figured out from configure. Look in acinclude.m4 # or configure.ac to see how they are set. See GLIBCXX_EXPORT_FLAGS. CONFIG_CXXFLAGS = \ - $(SECTION_FLAGS) $(EXTRA_CXX_FLAGS) + $(SECTION_FLAGS) $(EXTRA_CXX_FLAGS) -frandom-seed=$@ WARN_CXXFLAGS = \ $(WARN_FLAGS) $(WERROR) -fdiagnostics-show-location=once Index: Makefile.in === --- Makefile.in (revision 176515) +++ Makefile.in (working copy) @@ -293,7 +293,7 @@ toolexeclibdir = $(glibcxx_toolexeclibdi # These bits are all figured out from configure. Look in acinclude.m4 # or configure.ac to see how they are set. See GLIBCXX_EXPORT_FLAGS. CONFIG_CXXFLAGS = \ - $(SECTION_FLAGS) $(EXTRA_CXX_FLAGS) + $(SECTION_FLAGS) $(EXTRA_CXX_FLAGS) -frandom-seed=$@ WARN_CXXFLAGS = \ $(WARN_FLAGS) $(WERROR) -fdiagnostics-show-location=once Index: src/Makefile.in === --- src/Makefile.in (revision 176515) +++ src/Makefile.in (working copy) @@ -331,7 +331,7 @@ toolexeclibdir = $(glibcxx_toolexeclibdi # These bits are all figured out from configure. Look in acinclude.m4 # or configure.ac to see how they are set. See GLIBCXX_EXPORT_FLAGS. CONFIG_CXXFLAGS = \ - $(SECTION_FLAGS) $(EXTRA_CXX_FLAGS) + $(SECTION_FLAGS) $(EXTRA_CXX_FLAGS) -frandom-seed=$@ WARN_CXXFLAGS = \ $(WARN_FLAGS) $(WERROR) -fdiagnostics-show-location=once Index: doc/Makefile.in === --- doc/Makefile.in (revision 176515) +++ doc/Makefile.in (working copy) @@ -277,7 +277,7 @@ toolexeclibdir = $(glibcxx_toolexeclibdi # These bits are all figured out from configure. Look in acinclude.m4 # or configure.ac to see how they are set. See GLIBCXX_EXPORT_FLAGS. CONFIG_CXXFLAGS = \ - $(SECTION_FLAGS) $(EXTRA_CXX_FLAGS) + $(SECTION_FLAGS) $(EXTRA_CXX_FLAGS) -frandom-seed=$@ WARN_CXXFLAGS = \ $(WARN_FLAGS) $(WERROR) -fdiagnostics-show-location=once Index: po/Makefile.in === --- po/Makefile.in (revision 176515) +++ po/Makefile.in (working copy) @@ -267,7 +267,7 @@ toolexeclibdir = $(glibcxx_toolexeclibdi # These bits are all figured out from configure. Look in acinclude.m4 # or configure.ac to see how they are set. See GLIBCXX_EXPORT_FLAGS. CONFIG_CXXFLAGS = \ - $(SECTION_FLAGS) $(EXTRA_CXX_FLAGS) + $(SECTION_FLAGS) $(EXTRA_CXX_FLAGS) -frandom-seed=$@ WARN_CXXFLAGS = \ $(WARN_FLAGS) $(WERROR) -fdiagnostics-show-location=once Index: include/Makefile.in === --- include/Makefile.in (revision 176515) +++ include/Makefile.in (working copy) @@ -267,7 +267,7 @@ toolexeclibdir = $(glibcxx_toolexeclibdi # These bits are all figured out from configure. Look in acinclude.m4 # or configure.ac to see how they are set. See GLIBCXX_EXPORT_FLAGS. CONFIG_CXXFLAGS = \ - $(SECTION_FLAGS) $(EXTRA_CXX_FLAGS) + $(SECTION_FLAGS) $(EXTRA_CXX_FLAGS) -frandom-seed=$@ WARN_CXXFLAGS = \ $(WARN_FLAGS) $(WERROR) -fdiagnostics-show-location=once Index: libsupc++/Makefile.in === --- libsupc++/Makefile.in (revision 176515) +++ libsupc++/Makefile.in (working copy) @@ -326,7 +326,7 @@ toolexeclibdir = $(glibcxx_toolexeclibdi # These bits are all figured out from configure. Look in acinclude.m4 # or configure.ac to see how they are set. See GLIBCXX_EXPORT_FLAGS. CONFIG_CXXFLAGS = \ - $(SECTION_FLAGS) $(EXTRA_CXX_FLAGS) +
Re: PATCH RFA: Build stages 2 and 3 with C++
On 07/20/2011 04:34 PM, Toon Moene wrote: So I changed my lto bootstrap script to do the following: language=fortran if [ $RANDOM -lt 16384 ] then language=ada fi ... ../gcc/configure \ ... --enable-languages=c++,$language \ Still have to see if this will fit in the 2:20 hour gap between two weather forecasting runs. Well, that took *way* too long, so I am changing it back to language=fortran if [ $RANDOM -lt 16384 ] then language=ada fi language=c++ ... ../gcc/configure \ ... --enable-languages=$language \ Next run 21/07/2011 at 18:00 UTC. Cheers, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Re: PATCH RFA: Build stages 2 and 3 with C++
Mike Stump mikest...@comcast.net writes: Presumably the fix will be to use -frandom-seed. But, the random seem was to ensure that things that should not collide, don't. If you use 0, then things that should not collide, eventually will and your world with then end. In the present code base, it is perfectly safe to do this. If the codebase is ever extended to use C++ features, then, that code can break. I wasn't suggesting using -frandom-seed=0. Ian
Re: PATCH RFA: Build stages 2 and 3 with C++
On Wed, Jul 20, 2011 at 4:53 PM, Mike Stump mikest...@comcast.net wrote: On Jul 20, 2011, at 1:25 PM, Ian Lance Taylor wrote: Interesting. I don't know why this doesn't happen on GNU/Linux. It doesn't happen as the symbols in question are local on linux. collect2 runs nm on public symbols looking for symbols of a particular form, it then builds two lists, one for constructors of global objects (simplistic view) and one for destructors. a.out systems liked doing this sort of things as well. On more modern OSes, the constructors and destructors hook into crt code that can run per translation unit initializations, for example on elf, one might use .init to achieve this. When one uses one of these more advanced features to hook into the OS, then the symbols no longer need to be public and the port is changed to make them non-public. This is not the global constructor/destructor issue with names generated by collect2. But ELF or SVR4 is able to provide a unique name without resorting to random numbers. - David
Re: PATCH RFA: Build stages 2 and 3 with C++
Ian Lance Taylor i...@google.com writes: I would like to propose this patch as a step toward building gcc using a C++ compiler. This patch builds stage1 with the C compiler as usual, and defaults to building stages 2 and 3 with a C++ compiler built during stage 1. This means that the gcc installed and used by most people will be built by a C++ compiler. This will ensure that gcc is fully buildable with C++, while retaining the ability to bootstrap with only a C compiler, not a C++ compiler. This will permit us to experiment with optionally using C++ for some code, using a #ifdef to select the C implementation or the C++ implementation. I would suggest that we consider releasing 4.7 this way, as a small trial for building gcc with C++. This is a big step, so I am sending the patch to both gcc@ and gcc-patches@ for comments. Bootstrapped and ran testsuite on x86_64-unknown-linux-gnu. Ian 2011-07-15 Ian Lance Taylor i...@google.com * configure.ac: Add --enable-build-poststage1-with-cxx. If set, make C++ a boot_language. Set and substitute POSTSTAGE1_CONFIGURE_FLAGS. * Makefile.tpl (POSTSTAGE1_CONFIGURE_FLAGS): New variable. (STAGE[+id+]_CONFIGURE_FLAGS): Add $(POSTSTAGE1_CONFIGURE_FLAGS). * configure, Makefile.in: Rebuild. I got agreement from two global reviewers and no objections. I have committed this patch. Please let me know about any problems. Ian
Re: PATCH RFA: Build stages 2 and 3 with C++
On Tue, Jul 19, 2011 at 1:33 PM, Ian Lance Taylor i...@google.com wrote: Ian Lance Taylor i...@google.com writes: I got agreement from two global reviewers and no objections. I have committed this patch. Great! -- Gaby
Re: PATCH RFA: Build stages 2 and 3 with C++
On Tue, Jul 19, 2011 at 11:33 AM, Ian Lance Taylor i...@google.com wrote: Ian Lance Taylor i...@google.com writes: I would like to propose this patch as a step toward building gcc using a C++ compiler. This patch builds stage1 with the C compiler as usual, and defaults to building stages 2 and 3 with a C++ compiler built during stage 1. This means that the gcc installed and used by most people will be built by a C++ compiler. This will ensure that gcc is fully buildable with C++, while retaining the ability to bootstrap with only a C compiler, not a C++ compiler. This will permit us to experiment with optionally using C++ for some code, using a #ifdef to select the C implementation or the C++ implementation. I would suggest that we consider releasing 4.7 this way, as a small trial for building gcc with C++. This is a big step, so I am sending the patch to both gcc@ and gcc-patches@ for comments. Bootstrapped and ran testsuite on x86_64-unknown-linux-gnu. Ian 2011-07-15 Ian Lance Taylor i...@google.com * configure.ac: Add --enable-build-poststage1-with-cxx. If set, make C++ a boot_language. Set and substitute POSTSTAGE1_CONFIGURE_FLAGS. * Makefile.tpl (POSTSTAGE1_CONFIGURE_FLAGS): New variable. (STAGE[+id+]_CONFIGURE_FLAGS): Add $(POSTSTAGE1_CONFIGURE_FLAGS). * configure, Makefile.in: Rebuild. I got agreement from two global reviewers and no objections. I have committed this patch. Please let me know about any problems. It caused: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49787 -- H.J.
Re: PATCH RFA: Build stages 2 and 3 with C++
On Tue, Jul 19, 2011 at 5:26 PM, H.J. Lu hjl.to...@gmail.com wrote: On Tue, Jul 19, 2011 at 11:33 AM, Ian Lance Taylor i...@google.com wrote: Ian Lance Taylor i...@google.com writes: I would like to propose this patch as a step toward building gcc using a C++ compiler. This patch builds stage1 with the C compiler as usual, and defaults to building stages 2 and 3 with a C++ compiler built during stage 1. This means that the gcc installed and used by most people will be built by a C++ compiler. This will ensure that gcc is fully buildable with C++, while retaining the ability to bootstrap with only a C compiler, not a C++ compiler. This will permit us to experiment with optionally using C++ for some code, using a #ifdef to select the C implementation or the C++ implementation. I would suggest that we consider releasing 4.7 this way, as a small trial for building gcc with C++. This is a big step, so I am sending the patch to both gcc@ and gcc-patches@ for comments. Bootstrapped and ran testsuite on x86_64-unknown-linux-gnu. Ian 2011-07-15 Ian Lance Taylor i...@google.com * configure.ac: Add --enable-build-poststage1-with-cxx. If set, make C++ a boot_language. Set and substitute POSTSTAGE1_CONFIGURE_FLAGS. * Makefile.tpl (POSTSTAGE1_CONFIGURE_FLAGS): New variable. (STAGE[+id+]_CONFIGURE_FLAGS): Add $(POSTSTAGE1_CONFIGURE_FLAGS). * configure, Makefile.in: Rebuild. I got agreement from two global reviewers and no objections. I have committed this patch. Please let me know about any problems. It caused: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49787 It also caused: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49786 -- H.J.
Re: PATCH RFA: Build stages 2 and 3 with C++
On Tue, Jul 19, 2011 at 2:33 PM, Ian Lance Taylor i...@google.com wrote: I got agreement from two global reviewers and no objections. I have committed this patch. Please let me know about any problems. This also breaks bootstrap on AIX. I cannot debug further at the moment because of a separate problem with the infrastructure at IBM, but I receive the following error during the first build of libstdc++: In file included from /farm/dje/src/src/libstdc++-v3/src/debug.cc:30:0: /tmp/20110719/powerpc-ibm-aix5.3.0.0/libstdc++-v3/include/debug/safe_local_iterator.h:91:50: error: 'size_t' has not been declared - David
Re: PATCH RFA: Build stages 2 and 3 with C++
H.J. Lu hjl.to...@gmail.com writes:
It caused:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49787
Here is a patch. Tested only by running configure, though I am starting
a bootstrap.
OK for mainline?
Ian
2011-07-19 Ian Lance Taylor i...@google.com
PR bootstrap/49787
* configure.ac: Move --enable-bootstrap handling earlier in file.
If --enable-bootstrap and either --enable-build-with-cxx or
--enable-build-poststage1-with-cxx, enable C++ automatically.
* configure: Rebuild.
Index: configure.ac
===
--- configure.ac (revision 176494)
+++ configure.ac (working copy)
@@ -1133,6 +1133,48 @@ fi
ACX_PROG_GNAT
ACX_PROG_CMP_IGNORE_INITIAL
+AC_ARG_ENABLE([bootstrap],
+[AS_HELP_STRING([--enable-bootstrap],
+ [enable bootstrapping @:@yes if native build@:@])],,
+enable_bootstrap=default)
+
+# Issue errors and warnings for invalid/strange bootstrap combinations.
+case $configdirs in
+ *gcc*) have_compiler=yes ;;
+ *) have_compiler=no ;;
+esac
+
+case $have_compiler:$host:$target:$enable_bootstrap in
+ *:*:*:no) ;;
+
+ # Default behavior. Enable bootstrap if we have a compiler
+ # and we are in a native configuration.
+ yes:$build:$build:default)
+enable_bootstrap=yes ;;
+
+ *:*:*:default)
+enable_bootstrap=no ;;
+
+ # We have a compiler and we are in a native configuration, bootstrap is ok
+ yes:$build:$build:yes)
+;;
+
+ # Other configurations, but we have a compiler. Assume the user knows
+ # what he's doing.
+ yes:*:*:yes)
+AC_MSG_WARN([trying to bootstrap a cross compiler])
+;;
+
+ # No compiler: if they passed --enable-bootstrap explicitly, fail
+ no:*:*:yes)
+AC_MSG_ERROR([cannot bootstrap without a compiler]) ;;
+
+ # Fail if wrong command line
+ *)
+AC_MSG_ERROR([invalid option for --enable-bootstrap])
+;;
+esac
+
# See if we are building gcc with C++.
AC_ARG_ENABLE(build-with-cxx,
[AS_HELP_STRING([--enable-build-with-cxx],
@@ -1628,6 +1670,19 @@ if test -d ${srcdir}/gcc; then
;;
esac
+ # If bootstrapping, then using --enable-build-with-cxx or
+ # --enable-build-poststage1-with-cxx requires enabling C++.
+ case ,$enable_languages,:,$ENABLE_BUILD_WITH_CXX,$ENABLE_BUILD_POSTSTAGE1_WITH_CXX,:$enable_bootstrap in
+*,c++,*:*:*) ;;
+*:*,yes,*:yes)
+ if test -f ${srcdir}/gcc/cp/config-lang.in; then
+enable_languages=${enable_languages},c++
+ else
+AC_MSG_ERROR([bootstrapping with --enable-build-with-cxx or --enable-build-poststage1-with-cxx requires c++ sources])
+ fi
+ ;;
+ esac
+
# First scan to see if an enabled language requires some other language.
# We assume that a given config-lang.in will list all the language
# front ends it requires, even if some are required indirectly.
@@ -2378,55 +2433,6 @@ INSTALL_GDB_TK=`echo ${GDB_TK} | sed s/-
# 99 commands in a script, for HP-UX sed.
# Do not nest @if/@endif pairs, because configure will not warn you at all.
-AC_ARG_ENABLE([bootstrap],
-[AS_HELP_STRING([--enable-bootstrap],
- [enable bootstrapping @:@yes if native build@:@])],,
-enable_bootstrap=default)
-
-# Issue errors and warnings for invalid/strange bootstrap combinations.
-case $configdirs in
- *gcc*) have_compiler=yes ;;
- *) have_compiler=no ;;
-esac
-
-case $have_compiler:$host:$target:$enable_bootstrap in
- *:*:*:no) ;;
-
- # Default behavior. Enable bootstrap if we have a compiler
- # and we are in a native configuration.
- yes:$build:$build:default)
-enable_bootstrap=yes ;;
-
- *:*:*:default)
-enable_bootstrap=no ;;
-
- # We have a compiler and we are in a native configuration, bootstrap is ok
- yes:$build:$build:yes)
-;;
-
- # Other configurations, but we have a compiler. Assume the user knows
- # what he's doing.
- yes:*:*:yes)
-AC_MSG_WARN([trying to bootstrap a cross compiler])
-;;
-
- # No compiler: if they passed --enable-bootstrap explicitly, fail
- no:*:*:yes)
-AC_MSG_ERROR([cannot bootstrap without a compiler]) ;;
-
- # Fail if wrong command line
- *)
-AC_MSG_ERROR([invalid option for --enable-bootstrap])
-;;
-esac
-
-case ,$enable_languages,:,$ENABLE_BUILD_WITH_CXX,$ENABLE_BUILD_POSTSTAGE1_WITH_CXX,:$enable_bootstrap in
- *,c++,*:*:*) ;;
- *:*,yes,*:yes)
-AC_MSG_ERROR([bootstrapping with --enable-build-with-cxx or --enable-build-postage1-with-cxx requires c++ in --enable-languages])
-;;
-esac
-
case $enable_bootstrap:$ENABLE_GOLD: $configdirs :,$stage1_languages, in
yes:yes:*\ gold\ *:*,c++,*) ;;
yes:yes:*\ gold\ *:*)
Re: PATCH RFA: Build stages 2 and 3 with C++
On Sun, Jul 17, 2011 at 12:57 AM, Ian Lance Taylor i...@google.com wrote: Diego Novillo dnovi...@google.com writes: On Sat, Jul 16, 2011 at 02:52, Ian Lance Taylor i...@google.com wrote: 2011-07-15 Ian Lance Taylor i...@google.com * configure.ac: Add --enable-build-poststage1-with-cxx. If set, make C++ a boot_language. Set and substitute POSTSTAGE1_CONFIGURE_FLAGS. * Makefile.tpl (POSTSTAGE1_CONFIGURE_FLAGS): New variable. (STAGE[+id+]_CONFIGURE_FLAGS): Add $(POSTSTAGE1_CONFIGURE_FLAGS). * configure, Makefile.in: Rebuild. I agree with this change. I agree with this change as well. It will give us the opportunity to experience debugging a C++ built cc1 ... For reference, have you measured the difference in bootstrap time? Clearly, it will be slower, but how much? I have not measured the change in bootstrap time, no. I have measured it at some point and IIRC it was about 10% slower (comparing C bootstrap with C++ in stag1 languages with C++ bootstrap, not sure if that included bootstrapping libstdc++ for the former). Richard. Ian
Re: PATCH RFA: Build stages 2 and 3 with C++
I have measured it at some point and IIRC it was about 10% slower (comparing C bootstrap with C++ in stag1 languages with C++ bootstrap, not sure if that included bootstrapping libstdc++ for the former). IMO acceptable now that the build time of libjava has been halved. -- Eric Botcazou
Re: PATCH RFA: Build stages 2 and 3 with C++
On Sun, Jul 17, 2011 at 1:30 PM, Eric Botcazou ebotca...@adacore.com wrote: I have measured it at some point and IIRC it was about 10% slower (comparing C bootstrap with C++ in stag1 languages with C++ bootstrap, not sure if that included bootstrapping libstdc++ for the former). IMO acceptable now that the build time of libjava has been halved. Actually the penalty for using C++ was only 1.5%, that of bootstrapping C++ and libstdc++ was 15%. For reference: http://gcc.gnu.org/ml/gcc/2010-06/msg00100.html Richard.
Re: PATCH RFA: Build stages 2 and 3 with C++
On 2011.07.17 at 18:30 +0200, Richard Guenther wrote: On Sun, Jul 17, 2011 at 1:30 PM, Eric Botcazou ebotca...@adacore.com wrote: I have measured it at some point and IIRC it was about 10% slower (comparing C bootstrap with C++ in stag1 languages with C++ bootstrap, not sure if that included bootstrapping libstdc++ for the former). IMO acceptable now that the build time of libjava has been halved. Actually the penalty for using C++ was only 1.5%, that of bootstrapping C++ and libstdc++ was 15%. For reference: I've tested the difference today on an average 4 CPU machine with 8GB RAM. This is the result of otherwise identical LTO+PGO builds: --enable-build-with-cxx make -j4 profiledbootstrap 3384.20s user 177.02s system 291% cpu 20:23.12 total defaultmake -j4 profiledbootstrap 3011.03s user 144.30s system 297% cpu 17:41.59 total That's a ~15% increase in build time. (I couldn't test --enable-build-poststage1-with-cxx, because it doesn't seem to work with this configuration. Maybe the patch needs to be updated to also cover LTO or PGO builds?) Configured with: ../gcc/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.7.0 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.7.0 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.7.0/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.7.0/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --without-ppl --without-cloog --enable-lto --enable-nls --without-included-gettext --with-system-zlib --disable-werror --with-gold --enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --enable-cld --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.7.0/python --enable-checking=release --disable-libgcj --enable-languages=c,c++ --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-build-config=bootstrap-lto And built with: make -j4 BOOT_CFLAGS=-march=native -O2 -pipe STAGE1_CFLAGS=-march=native -O2 -pipe CFLAGS_FOR_TARGET=-march=native -O2 -pipe profiledbootstrap -- Markus
Re: PATCH RFA: Build stages 2 and 3 with C++
On Fri, Jul 15, 2011 at 11:52 PM, Ian Lance Taylor i...@google.com wrote: I would like to propose this patch as a step toward building gcc using a C++ compiler. This patch builds stage1 with the C compiler as usual, and defaults to building stages 2 and 3 with a C++ compiler built during stage 1. This means that the gcc installed and used by most people will be built by a C++ compiler. This will ensure that gcc is fully buildable with C++, while retaining the ability to bootstrap with only a C compiler, not a C++ compiler. This will permit us to experiment with optionally using C++ for some code, using a #ifdef to select the C implementation or the C++ implementation. I would suggest that we consider releasing 4.7 this way, as a small trial for building gcc with C++. Do you build libstdc++ at stage1 also? That is what happens if you don't have a C++ compiler to begin with. Thanks, Andrew Pinski
Re: PATCH RFA: Build stages 2 and 3 with C++
Andrew Pinski pins...@gmail.com writes: On Fri, Jul 15, 2011 at 11:52 PM, Ian Lance Taylor i...@google.com wrote: I would like to propose this patch as a step toward building gcc using a C++ compiler. This patch builds stage1 with the C compiler as usual, and defaults to building stages 2 and 3 with a C++ compiler built during stage 1. This means that the gcc installed and used by most people will be built by a C++ compiler. This will ensure that gcc is fully buildable with C++, while retaining the ability to bootstrap with only a C compiler, not a C++ compiler. This will permit us to experiment with optionally using C++ for some code, using a #ifdef to select the C implementation or the C++ implementation. I would suggest that we consider releasing 4.7 this way, as a small trial for building gcc with C++. Do you build libstdc++ at stage1 also? That is what happens if you don't have a C++ compiler to begin with. Yes. With this patch, we build cc1plus at stage 1, and use it to build libstdc++ at stage 1, and use both to build stage 2. Ian
Re: PATCH RFA: Build stages 2 and 3 with C++
On Sat, 16 Jul 2011 00:04:58 -0700
Ian Lance Taylor i...@google.com wrote:
Andrew Pinski pins...@gmail.com writes:
On Fri, Jul 15, 2011 at 11:52 PM, Ian Lance Taylor i...@google.com wrote:
I would like to propose this patch as a step toward building gcc using a
C++ compiler. This patch builds stage1 with the C compiler as usual,
and defaults to building stages 2 and 3 with a C++ compiler built during
stage 1.
Do you build libstdc++ at stage1 also? That is what happens if you
don't have a C++ compiler to begin with.
Yes. With this patch, we build cc1plus at stage 1, and use it to build
libstdc++ at stage 1, and use both to build stage 2.
I think that we might also want to have some easy documented way to build the
stage1
directly with g++, assuming (or when) it is already available.
Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: PATCH RFA: Build stages 2 and 3 with C++
On Sat, Jul 16, 2011 at 02:52, Ian Lance Taylor i...@google.com wrote: 2011-07-15 Ian Lance Taylor i...@google.com * configure.ac: Add --enable-build-poststage1-with-cxx. If set, make C++ a boot_language. Set and substitute POSTSTAGE1_CONFIGURE_FLAGS. * Makefile.tpl (POSTSTAGE1_CONFIGURE_FLAGS): New variable. (STAGE[+id+]_CONFIGURE_FLAGS): Add $(POSTSTAGE1_CONFIGURE_FLAGS). * configure, Makefile.in: Rebuild. I agree with this change. For reference, have you measured the difference in bootstrap time? Clearly, it will be slower, but how much? Diego.
Re: PATCH RFA: Build stages 2 and 3 with C++
On 07/16/2011 08:52 AM, Ian Lance Taylor wrote: I would like to propose this patch as a step toward building gcc using a C++ compiler. This patch builds stage1 with the C compiler as usual, and defaults to building stages 2 and 3 with a C++ compiler built during stage 1. I just completed a run using the following language configure options: ../gcc/configure \ ... --enable-build-with-cxx \ --enable-languages=c,c++,fortran,ada \ on x86-64-unknown-linux-gnu. As far as I can see it was successful: http://gcc.gnu.org/ml/gcc-testresults/2011-07/msg01852.html For extra fun, the 0:20 UTC run at home using: ../gcc/configure \ ... --with-build-config=bootstrap-lto \ is going to use Ada as a language *of choice* instead of Fortran based on the value of $RANDOM in the bash shell :-) language=fortran if [ $RANDOM -lt 16384 ] then language=ada fi ../gcc/configure \ --prefix=/tmp/lto \ --enable-languages=$language \ --with-build-config=bootstrap-lto \ I'll see you tomorrow (evil cackle) :-) All this is using: $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.1-1' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-multiarch --with-multiarch-defaults=x86_64-linux-gnu --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib/x86_64-linux-gnu --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib/x86_64-linux-gnu --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.6.1 (Debian 4.6.1-1) toon@super:~$ gnat -v GNAT 4.6.1 ... -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Re: PATCH RFA: Build stages 2 and 3 with C++
Diego Novillo dnovi...@google.com writes: On Sat, Jul 16, 2011 at 02:52, Ian Lance Taylor i...@google.com wrote: 2011-07-15 Ian Lance Taylor i...@google.com * configure.ac: Add --enable-build-poststage1-with-cxx. If set, make C++ a boot_language. Set and substitute POSTSTAGE1_CONFIGURE_FLAGS. * Makefile.tpl (POSTSTAGE1_CONFIGURE_FLAGS): New variable. (STAGE[+id+]_CONFIGURE_FLAGS): Add $(POSTSTAGE1_CONFIGURE_FLAGS). * configure, Makefile.in: Rebuild. I agree with this change. For reference, have you measured the difference in bootstrap time? Clearly, it will be slower, but how much? I have not measured the change in bootstrap time, no. Ian
