PATCH RFA: Build stages 2 and 3 with C++

PATCH RFA: Build stages 2 and 3 with C++

[Ian Lance Taylor]

[-- Attachment #1: Type: text/plain, Size: 1224 bytes --]

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



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: patch --]
[-- Type: text/x-diff, Size: 4538 bytes --]

Index: configure.ac
===================================================================
--- configure.ac	(revision 176348)
+++ configure.ac	(working copy)
@@ -1126,6 +1126,13 @@ AC_ARG_ENABLE(build-with-cxx,
 ENABLE_BUILD_WITH_CXX=$enableval,
 ENABLE_BUILD_WITH_CXX=no)
 
+# Build stage1 with C and build stages 2 and 3 with C++.
+AC_ARG_ENABLE(build-poststage1-with-cxx,
+[AS_HELP_STRING([--enable-build-poststage1-with-cxx],
+		[build stages 2 and 3 with C++, not C])],
+ENABLE_BUILD_POSTSTAGE1_WITH_CXX=$enableval,
+ENABLE_BUILD_POSTSTAGE1_WITH_CXX=yes)
+
 # Used for setting $lt_cv_objdir
 _LT_CHECK_OBJDIR
 
@@ -1696,9 +1703,11 @@ if test -d ${srcdir}/gcc; then
           exit 1
         fi
 
-	if test "$language" = "c++" \
-	   && test "$ENABLE_BUILD_WITH_CXX" = "yes"; then
-	  boot_language=yes
+	if test "$language" = "c++"; then
+	  if test "$ENABLE_BUILD_WITH_CXX" = "yes" \
+	     || test "$ENABLE_BUILD_POSTSTAGE1_WITH_CXX" = "yes"; then
+	    boot_language=yes
+	  fi
 	fi
 
         case ,${enable_languages}, in
@@ -2397,10 +2406,10 @@ case "$have_compiler:$host:$target:$enab
     ;;
 esac
 
-case ",$enable_languages,:$ENABLE_BUILD_WITH_CXX:$enable_bootstrap" in
-  *,c++,*:yes:yes) ;;
-  *:yes:yes)
-    AC_MSG_ERROR([bootstrapping with --enable-build-with-cxx requires c++ in --enable-languages])
+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
 
@@ -3188,6 +3197,15 @@ case ${enable_werror} in
 esac
 AC_SUBST(stage2_werror_flag)
 
+# If using ENABLE_BUILD_POSTSTAGE1_WITH_CXX, pass
+# --enable-build-with-cxx after stage1.
+if test "$ENABLE_BUILD_POSTSTAGE1_WITH_CXX" = "yes"; then
+  POSTSTAGE1_CONFIGURE_FLAGS=--enable-build-with-cxx
+else
+  POSTSTAGE1_CONFIGURE_FLAGS=
+fi
+AC_SUBST(POSTSTAGE1_CONFIGURE_FLAGS)
+
 # Specify what files to not compare during bootstrap.
 
 compare_exclusions="gcc/cc*-checksum\$(objext) | gcc/ada/*tools/*"
Index: Makefile.tpl
===================================================================
--- Makefile.tpl	(revision 176348)
+++ Makefile.tpl	(working copy)
@@ -416,6 +416,7 @@ TFLAGS =
 STAGE_CFLAGS = $(BOOT_CFLAGS)
 STAGE_TFLAGS = $(TFLAGS)
 STAGE_CONFIGURE_FLAGS=@stage2_werror_flag@
+POSTSTAGE1_CONFIGURE_FLAGS = @POSTSTAGE1_CONFIGURE_FLAGS@
 
 [+ FOR bootstrap-stage +]
 # Defaults for stage [+id+]; some are overridden below.
@@ -426,7 +427,10 @@ STAGE[+id+]_CXXFLAGS = $(CXXFLAGS)
 STAGE[+id+]_CXXFLAGS = $(STAGE[+id+]_CFLAGS)
 @endif target-libstdc++-v3-bootstrap
 STAGE[+id+]_TFLAGS = $(STAGE_TFLAGS)
-STAGE[+id+]_CONFIGURE_FLAGS = $(STAGE_CONFIGURE_FLAGS)
+# STAGE1_CONFIGURE_FLAGS overridden below, so we can use
+# POSTSTAGE1_CONFIGURE_FLAGS here.
+STAGE[+id+]_CONFIGURE_FLAGS = \
+	$(STAGE_CONFIGURE_FLAGS) $(POSTSTAGE1_CONFIGURE_FLAGS)
 [+ ENDFOR bootstrap-stage +]
 
 # Only build the C compiler for stage1, because that is the only one that
@@ -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)"
 
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}.
+
 @item --enable-maintainer-mode
 The build rules that regenerate the Autoconf and Automake output files as
 well as the GCC master message catalog @file{gcc.pot} are normally

Re: PATCH RFA: Build stages 2 and 3 with C++

[Andrew Pinski]

On Fri, Jul 15, 2011 at 11:52 PM, Ian Lance Taylor <iant@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++

[Ian Lance Taylor]

Andrew Pinski <pinskia@gmail.com> writes:

> On Fri, Jul 15, 2011 at 11:52 PM, Ian Lance Taylor <iant@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++

[Basile Starynkevitch]

On Sat, 16 Jul 2011 00:04:58 -0700
Ian Lance Taylor <iant@google.com> wrote:

> Andrew Pinski <pinskia@gmail.com> writes:
> 
> > On Fri, Jul 15, 2011 at 11:52 PM, Ian Lance Taylor <iant@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: basile<at>starynkevitch<dot>net 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++

[Diego Novillo]

On Sat, Jul 16, 2011 at 02:52, Ian Lance Taylor <iant@google.com> wrote:

> 2011-07-15  Ian Lance Taylor  <iant@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++

[Toon Moene]

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: toon@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++

[Ian Lance Taylor]

Diego Novillo <dnovillo@google.com> writes:

> On Sat, Jul 16, 2011 at 02:52, Ian Lance Taylor <iant@google.com> wrote:
>
>> 2011-07-15  Ian Lance Taylor  <iant@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

Re: PATCH RFA: Build stages 2 and 3 with C++

[Ian Lance Taylor]

Basile Starynkevitch <basile@starynkevitch.net> writes:

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

We already do: configure with --enable-build-with-cxx.

Ian

Re: PATCH RFA: Build stages 2 and 3 with C++

[Richard Guenther]

On Sun, Jul 17, 2011 at 12:57 AM, Ian Lance Taylor <iant@google.com> wrote:
> Diego Novillo <dnovillo@google.com> writes:
>
>> On Sat, Jul 16, 2011 at 02:52, Ian Lance Taylor <iant@google.com> wrote:
>>
>>> 2011-07-15  Ian Lance Taylor  <iant@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++

[Eric Botcazou]

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

[Richard Guenther]

On Sun, Jul 17, 2011 at 1:30 PM, Eric Botcazou <ebotcazou@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++

[Markus Trippelsdorf]

On 2011.07.17 at 18:30 +0200, Richard Guenther wrote:
> On Sun, Jul 17, 2011 at 1:30 PM, Eric Botcazou <ebotcazou@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
<default>                make -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++

[Markus Trippelsdorf]

On 2011.07.17 at 18:54 +0200, Markus Trippelsdorf wrote:
> On 2011.07.17 at 18:30 +0200, Richard Guenther wrote:
> > On Sun, Jul 17, 2011 at 1:30 PM, Eric Botcazou <ebotcazou@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
> <default>                make -j4 profiledbootstrap  3011.03s user 144.30s system 297% cpu 17:41.59 total
> 
> That's a ~15% increase in build time.

And I guess that most of it comes from building libstdc++ to train the
instrumented compiler. This doesn't happen in the default case AFAICS.

-- 
Markus

Re: PATCH RFA: Build stages 2 and 3 with C++

[Ian Lance Taylor]

Ian Lance Taylor <iant@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  <iant@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++

[Gabriel Dos Reis]

On Tue, Jul 19, 2011 at 1:33 PM, Ian Lance Taylor <iant@google.com> wrote:
> Ian Lance Taylor <iant@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++

[H.J. Lu]

On Tue, Jul 19, 2011 at 11:33 AM, Ian Lance Taylor <iant@google.com> wrote:
> Ian Lance Taylor <iant@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  <iant@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++

[H.J. Lu]

On Tue, Jul 19, 2011 at 5:26 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Tue, Jul 19, 2011 at 11:33 AM, Ian Lance Taylor <iant@google.com> wrote:
>> Ian Lance Taylor <iant@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  <iant@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++

[David Edelsohn]

On Tue, Jul 19, 2011 at 2:33 PM, Ian Lance Taylor <iant@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++

[Jonathan Wakely]

On 20 July 2011 02:14, David Edelsohn wrote:
> On Tue, Jul 19, 2011 at 2:33 PM, Ian Lance Taylor <iant@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++

[Jonathan Wakely]

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 <iant@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++

[David Edelsohn]

On Wed, Jul 20, 2011 at 5:43 AM, Jonathan Wakely <jwakely.gcc@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++

[Richard Guenther]

On Wed, Jul 20, 2011 at 2:36 PM, David Edelsohn <dje.gcc@gmail.com> wrote:
> On Wed, Jul 20, 2011 at 5:43 AM, Jonathan Wakely <jwakely.gcc@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++

[Diego Novillo]

On Wed, Jul 20, 2011 at 08:41, Richard Guenther
<richard.guenther@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++

[Ian Lance Taylor]

Diego Novillo <dnovillo@google.com> writes:

> On Wed, Jul 20, 2011 at 08:41, Richard Guenther
> <richard.guenther@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++

[Toon Moene]

On 07/19/2011 08:33 PM, Ian Lance Taylor wrote:

>> 2011-07-15  Ian Lance Taylor<iant@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: toon@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++

[Ian Lance Taylor]

Toon Moene <toon@moene.org> writes:

> On 07/19/2011 08:33 PM, Ian Lance Taylor wrote:
>
>>> 2011-07-15  Ian Lance Taylor<iant@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++

[Jonathan Wakely]

Feel the burn^Wchurn!



On 20/07/2011, Ian Lance Taylor <iant@google.com> wrote:
> Diego Novillo <dnovillo@google.com> writes:
>
>> On Wed, Jul 20, 2011 at 08:41, Richard Guenther
>> <richard.guenther@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++

[David Edelsohn]

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

[Ian Lance Taylor]

David Edelsohn <dje.gcc@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++

[Thomas Schwinge]

[-- Attachment #1: Type: text/plain, Size: 1510 bytes --]

Hi!

On Wed, 20 Jul 2011 11:41:37 -0400, David Edelsohn <dje.gcc@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

[-- Attachment #2: Type: application/pgp-signature, Size: 489 bytes --]

Re: PATCH RFA: Build stages 2 and 3 with C++

[David Edelsohn]

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_00000000_8F8DBED417uncatch_exceptionC2Ev
-       .lglobl
H.100.._ZN10__cxxabiv176_GLOBAL__N__farm_dje_src_src_libstdc___v3_libsupc___vec.cc_00000000_8F8DBED417uncatch_exceptionC1Ev
-       .lglobl
H.114.._ZN10__cxxabiv176_GLOBAL__N__farm_dje_src_src_libstdc___v3_libsupc___vec.cc_00000000_8F8DBED417uncatch_exceptionD2Ev
-       .lglobl
H.121.._ZN10__cxxabiv176_GLOBAL__N__farm_dje_src_src_libstdc___v3_libsupc___vec.cc_00000000_8F8DBED417uncatch_exceptionD1Ev
+       .lglobl
H.92.._ZN10__cxxabiv176_GLOBAL__N__farm_dje_src_src_libstdc___v3_libsupc___vec.cc_00000000_2322ABD117uncatch_exceptionC2Ev
+       .lglobl
H.100.._ZN10__cxxabiv176_GLOBAL__N__farm_dje_src_src_libstdc___v3_libsupc___vec.cc_00000000_2322ABD117uncatch_exceptionC1Ev
+       .lglobl
H.114.._ZN10__cxxabiv176_GLOBAL__N__farm_dje_src_src_libstdc___v3_libsupc___vec.cc_00000000_2322ABD117uncatch_exceptionD2Ev
+       .lglobl
H.121.._ZN10__cxxabiv176_GLOBAL__N__farm_dje_src_src_libstdc___v3_libsupc___vec.cc_00000000_2322ABD117uncatch_exceptionD1Ev


- David

Re: PATCH RFA: Build stages 2 and 3 with C++

[Ian Lance Taylor]

[-- Attachment #1: Type: text/plain, Size: 629 bytes --]

David Edelsohn <dje.gcc@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


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: patch --]
[-- Type: text/x-diff, Size: 5086 bytes --]

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)
+	$(SECTION_FLAGS) $(EXTRA_CXX_FLAGS) -frandom-seed=$@
 
 WARN_CXXFLAGS = \
 	$(WARN_FLAGS) $(WERROR) -fdiagnostics-show-location=once
Index: testsuite/Makefile.in
===================================================================
--- testsuite/Makefile.in	(revision 176515)
+++ testsuite/Makefile.in	(working copy)
@@ -270,7 +270,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++

[Mike Stump]

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.

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

Re: PATCH RFA: Build stages 2 and 3 with C++

[Toon Moene]

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: toon@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++

[Ian Lance Taylor]

Mike Stump <mikestump@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++

[David Edelsohn]

On Wed, Jul 20, 2011 at 4:53 PM, Mike Stump <mikestump@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++

[Eric Botcazou]

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

[Basile Starynkevitch]

On Wed, 20 Jul 2011 14:41:16 -0700
Ian Lance Taylor <iant@google.com> wrote:

> Mike Stump <mikestump@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: basile<at>starynkevitch<dot>net 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++

[David Edelsohn]

On Wed, Jul 20, 2011 at 4:25 PM, Ian Lance Taylor <iant@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++

[Ian Lance Taylor]

Basile Starynkevitch <basile@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++

[Jakub Jelinek]

On Thu, Jul 21, 2011 at 08:51:46AM -0700, Ian Lance Taylor wrote:
> Basile Starynkevitch <basile@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++

[Ian Lance Taylor]

Jakub Jelinek <jakub@redhat.com> writes:

> On Thu, Jul 21, 2011 at 08:51:46AM -0700, Ian Lance Taylor wrote:
>> Basile Starynkevitch <basile@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++

[Basile Starynkevitch]

On Thu, 21 Jul 2011 11:13:00 -0700
Ian Lance Taylor <iant@google.com> wrote:

> Jakub Jelinek <jakub@redhat.com> writes:
> 
> > On Thu, Jul 21, 2011 at 08:51:46AM -0700, Ian Lance Taylor wrote:
> >> Basile Starynkevitch <basile@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: basile<at>starynkevitch<dot>net 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++

[Ian Lance Taylor]

Basile Starynkevitch <basile@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++

[Marc Glisse]

On Fri, 15 Jul 2011, 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.  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.

Nice step. Now that gcc can (mostly) build with g++, it would be great if 
it could build with a non-gnu compiler. More precisely, with a compiler 
that doesn't define __GNUC__. Indeed, the code is quite different in this 
case, as can be seen trying to compile gcc with CC='gcc -U__GNUC__' and 
CXX='g++ -U__GNUC__' (there are other reasons why this won't work, but at 
least it shows some of the same issues I see with sunpro).


To start with, the obstack_free macro casts a pointer to an int -> error.
/data/repos/gcc/trunk/libcpp/directives.c:2048:7: error: cast from Β‘char*Β’ 
to Β‘intΒ’ loses precision [-fpermissive]


Then, ENUM_BITFIELD(cpp_ttype) is expanded to unsigned int instead of the 
enum, and conversions from int to enum require an explicit cast in C++, 
giving many errors like:
/data/repos/gcc/trunk/libcpp/charset.c:1615:79: error: invalid conversion 
from Β‘unsigned intΒ’ to Β‘cpp_ttypeΒ’ [-fpermissive]
/data/repos/gcc/trunk/libcpp/charset.c:1371:1: error:   initializing 
argument 5 of Β‘bool cpp_interpret_string(cpp_reader*, const cpp_string*, 
size_t, cpp_string*, cpp_ttype)Β’ [-fpermissive]

Do we want to add a cast in almost every place a field declared with 
ENUM_BITFIELD is used? That's quite a lot of places, everywhere in gcc...
The alternative would be to store the full enum instead of a bitfield 
(just for stage1 so that's not too bad), but some comments in the code 
seem to advise against it.

-- 
Marc Glisse

Re: PATCH RFA: Build stages 2 and 3 with C++

[Richard Guenther]

2011/8/1 Marc Glisse <marc.glisse@inria.fr>:
> On Fri, 15 Jul 2011, 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.  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.
>
> Nice step. Now that gcc can (mostly) build with g++, it would be great if it
> could build with a non-gnu compiler. More precisely, with a compiler that
> doesn't define __GNUC__. Indeed, the code is quite different in this case,
> as can be seen trying to compile gcc with CC='gcc -U__GNUC__' and CXX='g++
> -U__GNUC__' (there are other reasons why this won't work, but at least it
> shows some of the same issues I see with sunpro).
>
>
> To start with, the obstack_free macro casts a pointer to an int -> error.
> /data/repos/gcc/trunk/libcpp/directives.c:2048:7: error: cast from ‘char*’
> to ‘int’ loses precision [-fpermissive]
>
>
> Then, ENUM_BITFIELD(cpp_ttype) is expanded to unsigned int instead of the
> enum, and conversions from int to enum require an explicit cast in C++,
> giving many errors like:
> /data/repos/gcc/trunk/libcpp/charset.c:1615:79: error: invalid conversion
> from ‘unsigned int’ to ‘cpp_ttype’ [-fpermissive]
> /data/repos/gcc/trunk/libcpp/charset.c:1371:1: error:   initializing
> argument 5 of ‘bool cpp_interpret_string(cpp_reader*, const cpp_string*,
> size_t, cpp_string*, cpp_ttype)’ [-fpermissive]
>
> Do we want to add a cast in almost every place a field declared with
> ENUM_BITFIELD is used? That's quite a lot of places, everywhere in gcc...
> The alternative would be to store the full enum instead of a bitfield (just
> for stage1 so that's not too bad), but some comments in the code seem to
> advise against it.

I think it's the only viable solution (use the full enum for a non-GCC stage1
C++ compiler).  We could help it somewhat by at least placing
enum bitfields first/last in our bitfield groups.

Any other opinions?

Btw, thanks for trying non-GCC stage1 compilers ;)

Richard.

Re: PATCH RFA: Build stages 2 and 3 with C++

[Joseph S. Myers]

On Mon, 1 Aug 2011, Richard Guenther wrote:

> I think it's the only viable solution (use the full enum for a non-GCC stage1
> C++ compiler).  We could help it somewhat by at least placing
> enum bitfields first/last in our bitfield groups.

Are GCC and other compilers declaring that they support the GNU C and C++ 
languages by defining __GNUC__ really the only compilers with this 
extension?  Feature tests for particular features are generally better 
than testing for whether the compiler in use is GCC.  (Using configure 
tests for things in ansidecl.h does require checking where in the gcc and 
src repositories those things are used, to make sure that the relevant 
configure tests are used everywhere necessary.)

(Actually, C++03 appears to support enum bit-fields - it's only for C that 
they are a GNU extension - so can't we just enable them unconditionally 
when building as C++?)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: PATCH RFA: Build stages 2 and 3 with C++

[Richard Guenther]

On Mon, Aug 1, 2011 at 11:53 AM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> On Mon, 1 Aug 2011, Richard Guenther wrote:
>
>> I think it's the only viable solution (use the full enum for a non-GCC stage1
>> C++ compiler).  We could help it somewhat by at least placing
>> enum bitfields first/last in our bitfield groups.
>
> Are GCC and other compilers declaring that they support the GNU C and C++
> languages by defining __GNUC__ really the only compilers with this
> extension?  Feature tests for particular features are generally better
> than testing for whether the compiler in use is GCC.  (Using configure
> tests for things in ansidecl.h does require checking where in the gcc and
> src repositories those things are used, to make sure that the relevant
> configure tests are used everywhere necessary.)
>
> (Actually, C++03 appears to support enum bit-fields - it's only for C that
> they are a GNU extension - so can't we just enable them unconditionally
> when building as C++?)

Oh, sure - that's even better.

Richard.

Re: PATCH RFA: Build stages 2 and 3 with C++

[Marc Glisse]

On Mon, 1 Aug 2011, Joseph S. Myers wrote:

> On Mon, 1 Aug 2011, Richard Guenther wrote:
>
>> I think it's the only viable solution (use the full enum for a non-GCC stage1
>> C++ compiler).  We could help it somewhat by at least placing
>> enum bitfields first/last in our bitfield groups.
>
> Are GCC and other compilers declaring that they support the GNU C and C++
> languages by defining __GNUC__ really the only compilers with this
> extension?  Feature tests for particular features are generally better
> than testing for whether the compiler in use is GCC.  (Using configure
> tests for things in ansidecl.h does require checking where in the gcc and
> src repositories those things are used, to make sure that the relevant
> configure tests are used everywhere necessary.)

I just checked, and indeed sunpro supports this extension as well in C.

> (Actually, C++03 appears to support enum bit-fields - it's only for C that
> they are a GNU extension - so can't we just enable them unconditionally
> when building as C++?)

Great, I didn't know that. That's a much better solution.

-- 
Marc Glisse

Re: PATCH RFA: Build stages 2 and 3 with C++

[Romain Geissler]

Hi

Le 16 juil. 2011 à 08:52, Ian Lance Taylor a écrit :

> 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

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) ?

Romain Geissler

Re: PATCH RFA: Build stages 2 and 3 with C++

[Ian Lance Taylor]

Romain Geissler <romain.geissler@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++

[Romain Geissler]

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

[Thomas Schwinge]

[-- Attachment #1: Type: text/plain, Size: 1934 bytes --]

Hi!

On Sat, 16 Jul 2011 11:27:46 -0400, Diego Novillo <dnovillo@google.com> wrote:
> On Sat, Jul 16, 2011 at 02:52, Ian Lance Taylor <iant@google.com> wrote:
> 
> > 2011-07-15  Ian Lance Taylor  <iant@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

[-- Attachment #2: Type: application/pgp-signature, Size: 489 bytes --]