Re: RFH - Testing targets for the switch to C++

Re: RFH - Testing targets for the switch to C++

[Joel Sherrill]

For *-rtems* all test results are cross with tests run on simulators. We use a native compiler bulit from the same source for testing. Newlib is the C library and built at the same time. 

Do we need to enable any special flags from our existing configure?

FWIW we have a few targets where the simulator is limited in memory and many tests fail. These get rejected because the mail message is too large. If someone is willing to help us trim things so the known failures get skipped, it would be appreciated. We would report more. :)

--joel
RTEMS

Diego Novillo <dnovillo@google.com> wrote:

>On Sat, Apr 7, 2012 at 13:15, Marc Glisse <marc.glisse@inria.fr> wrote:
>
>> I would expect most problems to be related to the host, and more
>> specifically the compiler used to initiate the build, not so much the
>> target. Or is this aiming specifically for targets that only get
>> cross-compilers and thus don't have stage 2 and haven't been tested with a
>> C++ compiler yet?
>
>You are right that it is mainly an issue for the host.  But some of
>the target code gets only exposed when building for that target, and I
>figured that the targets reported in gcc-testresults are tested in a
>variety of hosts.  Hence my call for help.  I want to get as much
>testing variety as possible.
>
>> For build issues with other compilers, 50167 and 50177 are still open (last
>> time I looked, I couldn't find the meta-bug about switching to C++ in stage1
>> to add them as blockers).
>
>Thanks.  I will take a look.  If there is no meta bug, I'll create one.
>
>
>Diego.

Re: RFH - Testing targets for the switch to C++

[Diego Novillo]

On 4/7/12 4:09 PM, Joel Sherrill wrote:
> For *-rtems* all test results are cross with tests run on simulators.
> We use a native compiler bulit from the same source for testing.
> Newlib is the C library and built at the same time.
>
> Do we need to enable any special flags from our existing configure?

Just add --enable-build-with-cxx to the configure call.  The C++ testing 
wiki page has full details.

>
> FWIW we have a few targets where the simulator is limited in memory
> and many tests fail. These get rejected because the mail message is
> too large. If someone is willing to help us trim things so the known
> failures get skipped, it would be appreciated. We would report more.
> :)

Perhaps you could use the script 
contrib/testsuite-management/validate_failures.py?  You can add those 
tests that are known to fail to a manifest file.  It will then only 
report the failures that are not in that manifest.

The only thing with this script is that it is not used by default by 
make check nor the testsuite reporting script.  You'd have to call it 
from there.


Thanks.  Diego.

RFH - Testing targets for the switch to C++

[Diego Novillo]

I have started testing the switch to C++ and there is a pile of
testing to be done.  The testing itself is trivial, but the number of
targets that need to be tested is large and I don't have access to all
these combinations.

My proposal is to make sure that C++ builds work with:

- Primary targets
- Secondary targets
- Any other targets that people regularly test.

The first two items are easy to define.  I took them from
http://gcc.gnu.org/gcc-4.8/criteria.html.

The third item I populated from gcc-testresults postings in 2011.
This gave me a list of 136 targets.  Further, I sorted them by the
number of test reports sent, to determine an idea of "popularity".  I
removed from the list all the targets that had a popularity index
lower than 0.01%.

This is still a large list (about 109 entries), but there are several
overlapping entries (like different flavours of the same basic
target), so it should not be too bad.

The testing plan is, then, to go through this table to make sure that
we can build all of them with C++ enabled for all stages.

I have created a wiki page to track testing progress:
http://gcc.gnu.org/wiki/CppBuildStatus

My plea for help is to everyone who has access to the targets
mentioned in the list: please follow the instructions in that page and
fill-in the table entries of the targets that you tested.

If you see a missing target that should be tested, by all means, add
it to the list.


Thanks.  Diego.

Re: RFH - Testing targets for the switch to C++

[Marc Glisse]

On Fri, 6 Apr 2012, Diego Novillo wrote:

> I have started testing the switch to C++ and there is a pile of
> testing to be done.  The testing itself is trivial, but the number of
> targets that need to be tested is large and I don't have access to all
> these combinations.

Hello,

sorry for being slow, but the way things are presented is surprising to 
me. I would expect most problems to be related to the host, and more 
specifically the compiler used to initiate the build, not so much the 
target. Or is this aiming specifically for targets that only get 
cross-compilers and thus don't have stage 2 and haven't been tested with a 
C++ compiler yet?

For build issues with other compilers, 50167 and 50177 are still open 
(last time I looked, I couldn't find the meta-bug about switching to C++ 
in stage1 to add them as blockers).

-- 
Marc Glisse

Re: RFH - Testing targets for the switch to C++

[Diego Novillo]

On Sat, Apr 7, 2012 at 13:15, Marc Glisse <marc.glisse@inria.fr> wrote:

> I would expect most problems to be related to the host, and more
> specifically the compiler used to initiate the build, not so much the
> target. Or is this aiming specifically for targets that only get
> cross-compilers and thus don't have stage 2 and haven't been tested with a
> C++ compiler yet?

You are right that it is mainly an issue for the host.  But some of
the target code gets only exposed when building for that target, and I
figured that the targets reported in gcc-testresults are tested in a
variety of hosts.  Hence my call for help.  I want to get as much
testing variety as possible.

> For build issues with other compilers, 50167 and 50177 are still open (last
> time I looked, I couldn't find the meta-bug about switching to C++ in stage1
> to add them as blockers).

Thanks.  I will take a look.  If there is no meta bug, I'll create one.


Diego.

Re: RFH - Testing targets for the switch to C++

[Gerald Pfeifer]

On Fri, 6 Apr 2012, Diego Novillo wrote:
> The testing plan is, then, to go through this table to make sure that
> we can build all of them with C++ enabled for all stages.
> 
> I have created a wiki page to track testing progress:
> http://gcc.gnu.org/wiki/CppBuildStatus
> 
> My plea for help is to everyone who has access to the targets
> mentioned in the list: please follow the instructions in that
> page and fill-in the table entries of the targets that you tested.

Done for i386-unknown-freebsd10.0 (GCC 4.2 as system compiler).
No problems.

Gerald

Re: RFH - Testing targets for the switch to C++

[Diego Novillo]

On Mon, Apr 9, 2012 at 20:26, Gerald Pfeifer <gerald@pfeifer.com> wrote:

> Done for i386-unknown-freebsd10.0 (GCC 4.2 as system compiler).
> No problems.

Thanks!


Diego.

Re: RFH - Testing targets for the switch to C++

[NightStrike]

On Fri, Apr 6, 2012 at 6:55 PM, Diego Novillo <dnovillo@google.com> wrote:
> My plea for help is to everyone who has access to the targets
> mentioned in the list: please follow the instructions in that page and
> fill-in the table entries of the targets that you tested.
>
> If you see a missing target that should be tested, by all means, add
> it to the list.

I will test all of the mingw-w64 host/target combinations once trunk
doesn't cause an ICE again (should be soon with Kai's recent patch).
I'll add them to your list as I test them.

Re: RFH - Testing targets for the switch to C++

[Diego Novillo]

On 4/10/12 9:04 AM, NightStrike wrote:
> On Fri, Apr 6, 2012 at 6:55 PM, Diego Novillo<dnovillo@google.com>  wrote:
>> My plea for help is to everyone who has access to the targets
>> mentioned in the list: please follow the instructions in that page and
>> fill-in the table entries of the targets that you tested.
>>
>> If you see a missing target that should be tested, by all means, add
>> it to the list.
>
> I will test all of the mingw-w64 host/target combinations once trunk
> doesn't cause an ICE again (should be soon with Kai's recent patch).
> I'll add them to your list as I test them.

Excellent, thanks.


Diego.

Re: RFH - Testing targets for the switch to C++

[NightStrike]

On Tue, Apr 10, 2012 at 9:07 AM, Diego Novillo <dnovillo@google.com> wrote:
> On 4/10/12 9:04 AM, NightStrike wrote:
>>
>> On Fri, Apr 6, 2012 at 6:55 PM, Diego Novillo<dnovillo@google.com>  wrote:
>>>
>>> My plea for help is to everyone who has access to the targets
>>> mentioned in the list: please follow the instructions in that page and
>>> fill-in the table entries of the targets that you tested.
>>>
>>> If you see a missing target that should be tested, by all means, add
>>> it to the list.
>>
>>
>> I will test all of the mingw-w64 host/target combinations once trunk
>> doesn't cause an ICE again (should be soon with Kai's recent patch).
>> I'll add them to your list as I test them.
>
>
> Excellent, thanks.

Do these have to be tested as native compilers or cross compilers?
Does one or the other affect which gcc is used throughout the build?
I know that cross compiling does things differently, which is why the
advice is often to build a cross compiler with the most recent version
of GCC.

Re: RFH - Testing targets for the switch to C++

[Diego Novillo]

On 4/10/12 9:27 AM, NightStrike wrote:

> Do these have to be tested as native compilers or cross compilers?

It doesn't really matter.  As long as stage 1 is built with the host C++ 
compiler, either type of build should be fine.


Diego.

Re: RFH - Testing targets for the switch to C++

[NightStrike]

On Tue, Apr 10, 2012 at 3:07 AM, Diego Novillo <dnovillo@google.com> wrote:
> On 4/10/12 9:04 AM, NightStrike wrote:
>>
>> On Fri, Apr 6, 2012 at 6:55 PM, Diego Novillo<dnovillo@google.com>  wrote:
>>
>>> My plea for help is to everyone who has access to the targets
>>> mentioned in the list: please follow the instructions in that page and
>>> fill-in the table entries of the targets that you tested.
>>>
>>> If you see a missing target that should be tested, by all means, add
>>> it to the list.
>>
>>
>> I will test all of the mingw-w64 host/target combinations once trunk
>> doesn't cause an ICE again (should be soon with Kai's recent patch).
>> I'll add them to your list as I test them.
>
>
> Excellent, thanks.

Took me a while, but I built a linux to win64 cross compiler using
--enable-build-with-cxx.  How do I verify that the compiler was
actually built with g++?  ldd on the gcc binary?

Re: RFH - Testing targets for the switch to C++

[Diego Novillo]

On 12-06-15 12:42 , NightStrike wrote:

> Took me a while, but I built a linux to win64 cross compiler using
> --enable-build-with-cxx.

Thanks.

>  How do I verify that the compiler was
> actually built with g++?  ldd on the gcc binary?

That would work, yes.  But do it on stage1-gcc/xgcc.  The binaries in 
stage2-gcc/ and gcc/ are always built with C++.


Diego.

Re: RFH - Testing targets for the switch to C++

[NightStrike]

On Fri, Jun 15, 2012 at 7:24 AM, Diego Novillo <dnovillo@google.com> wrote:
> On 12-06-15 12:42 , NightStrike wrote:
>
>> Took me a while, but I built a linux to win64 cross compiler using
>> --enable-build-with-cxx.
>
>
> Thanks.
>
>
>>  How do I verify that the compiler was
>> actually built with g++?  ldd on the gcc binary?
>
>
> That would work, yes.  But do it on stage1-gcc/xgcc.  The binaries in
> stage2-gcc/ and gcc/ are always built with C++.

Looks like it worked.  The testsuite is still running (under wine).

For reference, this target is x86_64-w64-mingw32.

RE: RFH - Testing targets for the switch to C++

[Paul_Koning]

Tested x86_64-apple-darwin10, pdp11-aout -- both pass.

	paul

Re: RFH - Testing targets for the switch to C++

[Diego Novillo]

On 4/10/12 9:59 AM, Paul_Koning@Dell.com wrote:
> Tested x86_64-apple-darwin10, pdp11-aout -- both pass.

Thanks.


Diego.

Re: RFH - Testing targets for the switch to C++

[David Weatherford]

Tests pass for xtensa-unknown-elf on 64-bit linux with host gcc 4.6.3.

Dave Weatherford
weath@tensilica.com

Re: RFH - Testing targets for the switch to C++

[Diego Novillo]

On Tue, Apr 10, 2012 at 14:48, David Weatherford <weath@tensilica.com> wrote:
> Tests pass for xtensa-unknown-elf on 64-bit linux with host gcc 4.6.3.

Thanks!


Diego.

Re: RFH - Testing targets for the switch to C++

[Rainer Orth]

Diego Novillo <dnovillo@google.com> writes:

> My plea for help is to everyone who has access to the targets
> mentioned in the list: please follow the instructions in that page and
> fill-in the table entries of the targets that you tested.

i386-pc-solaris2.10 just passed, although I had several special-case
options for graphite and go to allow the host compiler's libstdc++ to be
found.

sparc-sun-solaris2.11 in progress, could add other OS versions (Solaris
9 to 11) if desired. 

> If you see a missing target that should be tested, by all means, add
> it to the list.

The alpha*-dec-osf* and mips-sgi-irix* entries can go: both have been
removed from mainline, as well as *-*-solaris2.8.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: RFH - Testing targets for the switch to C++

[Diego Novillo]

On 4/10/12 10:35 AM, Rainer Orth wrote:

> sparc-sun-solaris2.11 in progress, could add other OS versions (Solaris
> 9 to 11) if desired.

That would be great, particularly if they use different host C++ 
compilers.  Thanks.

>> If you see a missing target that should be tested, by all means, add
>> it to the list.
>
> The alpha*-dec-osf* and mips-sgi-irix* entries can go: both have been
> removed from mainline, as well as *-*-solaris2.8.

Thanks.  Removed.


Diego.

Re: RFH - Testing targets for the switch to C++

[Rainer Orth]

Diego Novillo <dnovillo@google.com> writes:

> On 4/10/12 10:35 AM, Rainer Orth wrote:
>
>> sparc-sun-solaris2.11 in progress, could add other OS versions (Solaris
>> 9 to 11) if desired.
>
> That would be great, particularly if they use different host C++ compilers.

Currently, they all use versions of g++ 4.4, but I could give it a try
with different versions of Sun/Oracle Studio CC.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: RFH - Testing targets for the switch to C++

[Marc Glisse]

On Tue, 10 Apr 2012, Rainer Orth wrote:

> Diego Novillo <dnovillo@google.com> writes:
>
>> On 4/10/12 10:35 AM, Rainer Orth wrote:
>>
>>> sparc-sun-solaris2.11 in progress, could add other OS versions (Solaris
>>> 9 to 11) if desired.
>>
>> That would be great, particularly if they use different host C++ compilers.
>
> Currently, they all use versions of g++ 4.4, but I could give it a try
> with different versions of Sun/Oracle Studio CC.

They should all fail, versions up to 12.2 because of CC bugs (reported to 
Oracle and fixed in 12.3 I think), and version 12.3 at least because of 
gcc bugs (already filed: 50167 and 50177).

-- 
Marc Glisse

Re: RFH - Testing targets for the switch to C++

[Rainer Orth]

Marc Glisse <marc.glisse@inria.fr> writes:

>> Currently, they all use versions of g++ 4.4, but I could give it a try
>> with different versions of Sun/Oracle Studio CC.
>
> They should all fail, versions up to 12.2 because of CC bugs (reported to
> Oracle and fixed in 12.3 I think), and version 12.3 at least because of gcc
> bugs (already filed: 50167 and 50177).

Thanks for the heads-up, that saved me time and effort.  Do you have CRs
for the CC bugs?

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: RFH - Testing targets for the switch to C++

[Marc Glisse]

On Tue, 10 Apr 2012, Rainer Orth wrote:

> Marc Glisse <marc.glisse@inria.fr> writes:
>
>>> Currently, they all use versions of g++ 4.4, but I could give it a try
>>> with different versions of Sun/Oracle Studio CC.
>>
>> They should all fail, versions up to 12.2 because of CC bugs (reported to
>> Oracle and fixed in 12.3 I think), and version 12.3 at least because of gcc
>> bugs (already filed: 50167 and 50177).
>
> Thanks for the heads-up, that saved me time and effort.  Do you have CRs
> for the CC bugs?

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7073578
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7073575

I think that was it, but I can't remember for sure.

Other people tried too, there are traces in gcc's bugzilla (50167 and 
50177 are still there, but there used to be a few more).

-- 
Marc Glisse

Re: RFH - Testing targets for the switch to C++

[Rainer Orth]

Marc Glisse <marc.glisse@inria.fr> writes:

>> Thanks for the heads-up, that saved me time and effort.  Do you have CRs
>> for the CC bugs?
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7073578
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7073575
>
> I think that was it, but I can't remember for sure.

Thanks.  Unfortunately, they were both classified as low-priority and
thus not backported to 12.2.  Not really an issue since 12.3 is already
available, just important to document when we throw the switch.

> Other people tried too, there are traces in gcc's bugzilla (50167 and 50177
> are still there, but there used to be a few more).

Ok.
	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: RFH - Testing targets for the switch to C++

[Marc Glisse]

On Tue, 10 Apr 2012, Rainer Orth wrote:

> Marc Glisse <marc.glisse@inria.fr> writes:
>
>>> Thanks for the heads-up, that saved me time and effort.  Do you have CRs
>>> for the CC bugs?
>>
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7073578
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7073575
>>
>> I think that was it, but I can't remember for sure.
>
> Thanks.  Unfortunately, they were both classified as low-priority and
> thus not backported to 12.2.  Not really an issue since 12.3 is already
> available, just important to document when we throw the switch.

Note that if people really care, and if I remember correctly, both bugs 
are really simple to work around in gcc. But I expect documenting 12.3 as 
a minimal version will be sufficient.

-- 
Marc Glisse

Re: RFH - Testing targets for the switch to C++

[Diego Novillo]

On 4/10/12 12:28 PM, Marc Glisse wrote:
> On Tue, 10 Apr 2012, Rainer Orth wrote:
>
>> Marc Glisse <marc.glisse@inria.fr> writes:
>>
>>>> Thanks for the heads-up, that saved me time and effort. Do you have CRs
>>>> for the CC bugs?
>>>
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7073578
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7073575
>>>
>>> I think that was it, but I can't remember for sure.
>>
>> Thanks. Unfortunately, they were both classified as low-priority and
>> thus not backported to 12.2. Not really an issue since 12.3 is already
>> available, just important to document when we throw the switch.
>
> Note that if people really care, and if I remember correctly, both bugs
> are really simple to work around in gcc. But I expect documenting 12.3
> as a minimal version will be sufficient.

Thanks folks.  Could you modify the testing matrix with these notes?  If 
you don't have wiki access, let me know and I'll paraphrase.


Diego.

Re: RFH - Testing targets for the switch to C++

[Rainer Orth]

Diego Novillo <dnovillo@google.com> writes:

> On 4/10/12 10:35 AM, Rainer Orth wrote:
>
>> sparc-sun-solaris2.11 in progress, could add other OS versions (Solaris
>> 9 to 11) if desired.
>
> That would be great, particularly if they use different host C++ compilers.

The sparc-sun-solaris2.11 bootstrap also completed successfully.  I
don't think there's much point in repeating the exercise on other
Solaris versions right now, given that they would all be built with the
same g++ version, CC doesn't yet work anywhere, and the amount of
discussion about how/if to perform the transition.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: RFH - Testing targets for the switch to C++

[Diego Novillo]

On 4/11/12 11:19 AM, Rainer Orth wrote:
> Diego Novillo<dnovillo@google.com>  writes:
>
>> On 4/10/12 10:35 AM, Rainer Orth wrote:
>>
>>> sparc-sun-solaris2.11 in progress, could add other OS versions (Solaris
>>> 9 to 11) if desired.
>>
>> That would be great, particularly if they use different host C++ compilers.
>
> The sparc-sun-solaris2.11 bootstrap also completed successfully.  I
> don't think there's much point in repeating the exercise on other
> Solaris versions right now, given that they would all be built with the
> same g++ version, CC doesn't yet work anywhere, and the amount of
> discussion about how/if to perform the transition.

Sounds goods.  Thanks for all the help!


Diego.

Re: RFH - Testing targets for the switch to C++

[Sebastian Huber]

Hello Diego,

what is with targets that only use cross compilers like RTEMS?  I think there 
is no need for a bootstrap?

-- 
Sebastian Huber, embedded brains GmbH

Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone   : +49 89 18 90 80 79-6
Fax     : +49 89 18 90 80 79-9
E-Mail  : sebastian.huber@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

Re: RFH - Testing targets for the switch to C++

[Diego Novillo]

On 4/12/12 3:11 AM, Sebastian Huber wrote:
> Hello Diego,
>
> what is with targets that only use cross compilers like RTEMS? I think
> there is no need for a bootstrap?

No.  I'm mostly interested in the stage 0 compiler used in those 
targets.  I want to decide what we should recommend as a minimum g++ 
version and/or vendor compiler version.


Thanks.  Diego.

Re: RFH - Testing targets for the switch to C++

[Ralf Corsepius]

On 04/12/2012 02:32 PM, Diego Novillo wrote:
> On 4/12/12 3:11 AM, Sebastian Huber wrote:
>> Hello Diego,
>>
>> what is with targets that only use cross compilers like RTEMS? I think
>> there is no need for a bootstrap?
>
> No. I'm mostly interested in the stage 0 compiler used in those targets.
> I want to decide what we should recommend as a minimum g++ version
> and/or vendor compiler version.

The *-rtems4* toolchains I supply for RTEMS currently are hosted on 
CentOS5+6, openSUSE 11.3+12.1, Fedora 15+16+17, mingw32 and cygwin, 
using these OSes' native toolchains.

Other folks have reported to build these toolchains under different 
*BSDs and MacOSX variants.

That said, in my understanding, the rtems targets entries on your table 
do not make much sense, because the limiting factor is the host-OS. From 
my list above, the oldest native compiler being in use are Cygwin's 
GCC-3.4.4 and CentOS5's gcc-4.1.2.

Ralf

Re: RFH - Testing targets for the switch to C++

[Diego Novillo]

On 4/12/12 11:34 AM, Ralf Corsepius wrote:

> The *-rtems4* toolchains I supply for RTEMS currently are hosted on
> CentOS5+6, openSUSE 11.3+12.1, Fedora 15+16+17, mingw32 and cygwin,
> using these OSes' native toolchains.
>
> Other folks have reported to build these toolchains under different
> *BSDs and MacOSX variants.
>
> That said, in my understanding, the rtems targets entries on your table
> do not make much sense, because the limiting factor is the host-OS. From
> my list above, the oldest native compiler being in use are Cygwin's
> GCC-3.4.4 and CentOS5's gcc-4.1.2.

Thanks.  I've coalesced the rtems entries into one and added this data 
in the notes.


Diego.

Re: RFH - Testing targets for the switch to C++

[Thomas Schwinge]

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

Hi!

A bit late to the game...  :-)

On Fri, 6 Apr 2012 18:55:28 -0400, Diego Novillo <dnovillo@google.com> wrote:
> I have started testing the switch to C++ and there is a pile of
> testing to be done.  The testing itself is trivial, but the number of
> targets that need to be tested is large and I don't have access to all
> these combinations.

i686-gnu would be mine.

This is based on 8b64dc3c58b54d07156c99a24576be76e8cbdc10 (2012-05-28)
sources, doing native builds on x86 Debian GNU/Linux as well as x86
Debian GNU/Hurd.

When --enable-build-with-cxx is enabled:

  * Build time mostly stays the same.

  * Looking at the build log, the build system's gcc (as opposed to g++)
    is still being used for building libiberty, fixincludes, zlib,
    libdecnumber, *_FOR_BUILD stuff in gcc/Makefile.  The latter seems to
    have been addressed in a44c8c3b1ee8ae1779fd8ee1ad556ed86a608bd2
    (2012-05-31), the others are probably expected to continue using gcc.

  * The size of the build directory stage1-gcc shrinks (!) from 1.1 GiB
    to 0.4 GiB, such that the whole build tree then occupies 2.6 GiB
    instead of 3.2 GiB.  I did notice that the C build uses
    -fkeep-inline-functions, and the C++ build doesn't (my logs, and
    confirmed in the top-level configure.ac), but don't know if that is
    the (sole) reason; I have not looked at this in more detail -- but
    0.6 GiB or 60 % less is quite a bit.

  * No difference in testsuite results.

When building a i686-linux-gnu to i686-gnu cross-compiler, there are
(expectedly) no surprises either.


Grüße,
 Thomas

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

Re: RFH - Testing targets for the switch to C++

[Diego Novillo]

On 12-06-06 18:58 , Thomas Schwinge wrote:
> Hi!
>
> A bit late to the game...  :-)
>
> On Fri, 6 Apr 2012 18:55:28 -0400, Diego Novillo<dnovillo@google.com>  wrote:
>> I have started testing the switch to C++ and there is a pile of
>> testing to be done.  The testing itself is trivial, but the number of
>> targets that need to be tested is large and I don't have access to all
>> these combinations.
>
> i686-gnu would be mine.
>
> This is based on 8b64dc3c58b54d07156c99a24576be76e8cbdc10 (2012-05-28)
> sources, doing native builds on x86 Debian GNU/Linux as well as x86
> Debian GNU/Hurd.
>
> When --enable-build-with-cxx is enabled:
>
>    * Build time mostly stays the same.
>
>    * Looking at the build log, the build system's gcc (as opposed to g++)
>      is still being used for building libiberty, fixincludes, zlib,
>      libdecnumber, *_FOR_BUILD stuff in gcc/Makefile.  The latter seems to
>      have been addressed in a44c8c3b1ee8ae1779fd8ee1ad556ed86a608bd2
>      (2012-05-31), the others are probably expected to continue using gcc.
>
>    * The size of the build directory stage1-gcc shrinks (!) from 1.1 GiB
>      to 0.4 GiB, such that the whole build tree then occupies 2.6 GiB
>      instead of 3.2 GiB.  I did notice that the C build uses
>      -fkeep-inline-functions, and the C++ build doesn't (my logs, and
>      confirmed in the top-level configure.ac), but don't know if that is
>      the (sole) reason; I have not looked at this in more detail -- but
>      0.6 GiB or 60 % less is quite a bit.
>
>    * No difference in testsuite results.
>
> When building a i686-linux-gnu to i686-gnu cross-compiler, there are
> (expectedly) no surprises either.

Thanks for testing.  If you haven't done so yet, would you mind updating 
the cxx testing wiki page?


Thanks.  Diego.

Re: RFH - Testing targets for the switch to C++

[Thomas Schwinge]

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

Hi!

On Mon, 11 Jun 2012 09:48:03 -0400, Diego Novillo <dnovillo@google.com> wrote:
> On 12-06-06 18:58 , Thomas Schwinge wrote:
> > When --enable-build-with-cxx is enabled:

> >    * The size of the build directory stage1-gcc shrinks (!) from 1.1 GiB
> >      to 0.4 GiB, such that the whole build tree then occupies 2.6 GiB
> >      instead of 3.2 GiB.  I did notice that the C build uses
> >      -fkeep-inline-functions, and the C++ build doesn't (my logs, and
> >      confirmed in the top-level configure.ac), but don't know if that is
> >      the (sole) reason; I have not looked at this in more detail -- but
> >      0.6 GiB or 60 % less is quite a bit.

I filed PR53635 for this.


> Thanks for testing.  If you haven't done so yet, would you mind updating 
> the cxx testing wiki page?

Sure; added an entry for i686-pc-gnu.


Grüße,
 Thomas

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