Re: Phase 1 of gcc-in-cxx now complete

Re: Phase 1 of gcc-in-cxx now complete

[Matt]

> * Develop some trial patches which require C++, e.g., convert VEC to
>  std::vector.

Do you have any ideas for the easiest starting points? Is there anywhere 
that is decently self-contained, or will if have to be a big bang?

I'd love to see this happen so there's more exercising of template 
expansion during the profiledbootstrap. If I can get pointed in the right 
direction, I can probably produce a patch within the next week.

Thanks for this work and adding all the extra warnings!

--
tangled strands of DNA explain the way that I behave.
http://www.clock.org/~matt

Re: Phase 1 of gcc-in-cxx now complete

[Ian Lance Taylor]

Matt <matt@use.net> writes:

>> * Develop some trial patches which require C++, e.g., convert VEC to
>>  std::vector.
>
> Do you have any ideas for the easiest starting points? Is there
> anywhere that is decently self-contained, or will if have to be a big
> bang?

Thanks for your interest.

I think the one I mentioned--converting VEC to std::vector--is a good
starting point.  This is the interface in vec.h.

Another easy starting point would be converting uses of htab_t to type
safe C++ hash tables, e.g., std::tr1:;unordered_map.  Here portability
suggests the ability to switch to different hash table implementations;
see gold/gold.h in the GNU binutils for one way to approach that.

Another easy starting point is finding calls to qsort and converting
them to std::sort, which typically leads to code which is larger but
runs faster.

Longer term, we know that memory usage is an issue in gcc.  In the old
obstack days, we had a range of obstacks with different lifespans, so we
could create RTL with a temporary lifetime which was given a longer
lifetime when needed.  We got away from that because we spent far too
much time chasing bugs in which RTL should have been saved to a longer
lifetime but wasn't.  However, that model should permit us to run with
significantly less memory, which would translate to less compile time.
I think we might be able to do it by implementing a custom allocator,
such as a pool allocator which permits allocating different sizes of
memory, and never frees memory.  Then the tree class could take an
allocator as a template parameter.  Then we would provide convertors
which copied the tree class to a different allocation style.  Then, for
example, fold-const.c could use a temporary pool which lived only for
the length of the call to fold.  If it returned a new value, the
convertor would force a copy out of the temporary pool.  If this works
out, we can use type safety to enforce memory discipline, use
significantly less memory during compilation, and take a big step toward
getting rid of the garbage collector.

Ian

Re: Phase 1 of gcc-in-cxx now complete

[Richard Guenther]

On Sat, Jun 27, 2009 at 2:55 AM, Ian Lance Taylor<iant@google.com> wrote:
> Matt <matt@use.net> writes:
>
>>> * Develop some trial patches which require C++, e.g., convert VEC to
>>>  std::vector.
>>
>> Do you have any ideas for the easiest starting points? Is there
>> anywhere that is decently self-contained, or will if have to be a big
>> bang?
>
> Thanks for your interest.
>
> I think the one I mentioned--converting VEC to std::vector--is a good
> starting point.  This is the interface in vec.h.
>
> Another easy starting point would be converting uses of htab_t to type
> safe C++ hash tables, e.g., std::tr1:;unordered_map.  Here portability
> suggests the ability to switch to different hash table implementations;
> see gold/gold.h in the GNU binutils for one way to approach that.
>
> Another easy starting point is finding calls to qsort and converting
> them to std::sort, which typically leads to code which is larger but
> runs faster.
>
> Longer term, we know that memory usage is an issue in gcc.  In the old
> obstack days, we had a range of obstacks with different lifespans, so we
> could create RTL with a temporary lifetime which was given a longer
> lifetime when needed.  We got away from that because we spent far too
> much time chasing bugs in which RTL should have been saved to a longer
> lifetime but wasn't.  However, that model should permit us to run with
> significantly less memory, which would translate to less compile time.
> I think we might be able to do it by implementing a custom allocator,
> such as a pool allocator which permits allocating different sizes of
> memory, and never frees memory.  Then the tree class could take an
> allocator as a template parameter.  Then we would provide convertors
> which copied the tree class to a different allocation style.  Then, for
> example, fold-const.c could use a temporary pool which lived only for
> the length of the call to fold.  If it returned a new value, the
> convertor would force a copy out of the temporary pool.  If this works
> out, we can use type safety to enforce memory discipline, use
> significantly less memory during compilation, and take a big step toward
> getting rid of the garbage collector.

All that above said - do you expect us to carry both vec.h (for VEC in
GC memory) and std::vector (for VECs in heap memory) (and vec.h
for the alloca trick ...)?  Or do you think we should try to make the GTY
machinery C++ aware and annotate the standard library (ick...)?

That said - I was more expecting to re-write the existing vec.h to
C++ to avoid this GC vs. non-GC use differences.  Also as the
standard library uses a very inefficient allocator by default, should
we for example switch from bitmap to an equivalend standard
library container.

IMHO we should at least try without the standard library for a start,
fixing the GTY machinery.

Richard.

Re: Phase 1 of gcc-in-cxx now complete

[Daniel Berlin]

>
> All that above said - do you expect us to carry both vec.h (for VEC in
> GC memory) and std::vector (for VECs in heap memory) (and vec.h
> for the alloca trick ...)?  Or do you think we should try to make the GTY
> machinery C++ aware and annotate the standard library (ick...)?

Since the containers have mostly standard iterators, i'm not sure we
have to do much to the standard library. Simply require a set of
iterators with the right properties exist and generate code that
depends on this.
If you make your own container, you have to implement the iterators.

Re: Phase 1 of gcc-in-cxx now complete

[Robert Dewar]

Daniel Berlin wrote:
>> All that above said - do you expect us to carry both vec.h (for VEC in
>> GC memory) and std::vector (for VECs in heap memory) (and vec.h
>> for the alloca trick ...)?  Or do you think we should try to make the GTY
>> machinery C++ aware and annotate the standard library (ick...)?
> 
> Since the containers have mostly standard iterators, i'm not sure we
> have to do much to the standard library. Simply require a set of
> iterators with the right properties exist and generate code that
> depends on this.
> If you make your own container, you have to implement the iterators.

Shouldn't this be a new thread, or is this really part of phase 1?

Re: Phase 1 of gcc-in-cxx now complete

[Ian Lance Taylor]

Richard Guenther <richard.guenther@gmail.com> writes:

> All that above said - do you expect us to carry both vec.h (for VEC in
> GC memory) and std::vector (for VECs in heap memory) (and vec.h
> for the alloca trick ...)?  Or do you think we should try to make the GTY
> machinery C++ aware and annotate the standard library (ick...)?

I expect us to write a GC allocator, and use that with std::vector.
This will require more hooks into the GC code, but I think it is doable.

> IMHO we should at least try without the standard library for a start,
> fixing the GTY machinery.

If we can't write a GC allocator, then I agree.

Ian

Re: Phase 1 of gcc-in-cxx now complete

[NightStrike]

On Sat, Jun 27, 2009 at 6:25 PM, Ian Lance Taylor<iant@google.com> wrote:
> Richard Guenther <richard.guenther@gmail.com> writes:
>
>> All that above said - do you expect us to carry both vec.h (for VEC in
>> GC memory) and std::vector (for VECs in heap memory) (and vec.h
>> for the alloca trick ...)?  Or do you think we should try to make the GTY
>> machinery C++ aware and annotate the standard library (ick...)?
>
> I expect us to write a GC allocator, and use that with std::vector.
> This will require more hooks into the GC code, but I think it is doable.

I'm curious about this.  I thought c++ wasn't a garbage collected
language on purpose.  Why does GCC have one?  What purpose does it
serve?  I'm not suggesting otherwise, but just trying to learn more
about the way things are done.

Re: Phase 1 of gcc-in-cxx now complete

[Andrew Haley]

NightStrike wrote:
> On Sat, Jun 27, 2009 at 6:25 PM, Ian Lance Taylor<iant@google.com> wrote:
>> Richard Guenther <richard.guenther@gmail.com> writes:
>>
>>> All that above said - do you expect us to carry both vec.h (for VEC in
>>> GC memory) and std::vector (for VECs in heap memory) (and vec.h
>>> for the alloca trick ...)?  Or do you think we should try to make the GTY
>>> machinery C++ aware and annotate the standard library (ick...)?
>> I expect us to write a GC allocator, and use that with std::vector.
>> This will require more hooks into the GC code, but I think it is doable.
> 
> I'm curious about this.  I thought c++ wasn't a garbage collected
> language on purpose.  Why does GCC have one?  What purpose does it
> serve?  I'm not suggesting otherwise, but just trying to learn more
> about the way things are done.

This is for gcc's internal use, not for the users of gcc.  We have to
manage memory inside gcc somehow, so we use a garbage collector.

Andrew.

Re: Phase 1 of gcc-in-cxx now complete

[Gabriel Dos Reis]

On Mon, Jun 29, 2009 at 5:39 AM, NightStrike<nightstrike@gmail.com> wrote:
> On Sat, Jun 27, 2009 at 6:25 PM, Ian Lance Taylor<iant@google.com> wrote:
>> Richard Guenther <richard.guenther@gmail.com> writes:
>>
>>> All that above said - do you expect us to carry both vec.h (for VEC in
>>> GC memory) and std::vector (for VECs in heap memory) (and vec.h
>>> for the alloca trick ...)?  Or do you think we should try to make the GTY
>>> machinery C++ aware and annotate the standard library (ick...)?
>>
>> I expect us to write a GC allocator, and use that with std::vector.
>> This will require more hooks into the GC code, but I think it is doable.
>
> I'm curious about this.  I thought c++ wasn't a garbage collected
> language on purpose.

Many people are confused about what the 'purpose' is.

>  Why does GCC have one?  What purpose does it
> serve?  I'm not suggesting otherwise, but just trying to learn more
> about the way things are done.
>

This is usually an ingredient for long, heated, debates :-)

-- Gaby

Re: Phase 1 of gcc-in-cxx now complete

[Sebastian Pop]

On Sat, Jun 27, 2009 at 11:51, David Edelsohn<dje.gcc@gmail.com> wrote:
> 2) The Graphite CLooG headers are not C++-clean, so enabling Graphite
> fails in CXX mode.

I did applied the patches from Ian to the cloog-ppl git.
The git version should compile with a C++ compiler.

Sebastian

Re: Phase 1 of gcc-in-cxx now complete

[David Edelsohn]

On Thu, Jun 25, 2009 at 4:32 PM, Ian Lance Taylor<iant@google.com> wrote:

> I would like to encourage people to try using --enable-build-with-cxx in
> other configuration--other bootstraps, cross-compilers--to see how well
> it works.  Please let me know if you run into problems that you don't
> know how, or don't have time, to fix.

I tried bootstrap with AIX.  Because AIX static libstdc++ requires
libsupc++, the search path for that library in the build directory
needs to be on the link line.  Manually adding that directory allows
GCC on AIX to get through stage3 bootstrap.

There are two other problems / annoyances independent of AIX:

1) All of the multilibs for libstdc++ are configured and built during
bootstrap.  This always has been the case for libgcc, but it was not
as much of an inconvenience.

2) The Graphite CLooG headers are not C++-clean, so enabling Graphite
fails in CXX mode.

David

Re: Phase 1 of gcc-in-cxx now complete

[Adam Nemet]

Ian Lance Taylor <iant@google.com> writes:
> I would like to encourage people to try using --enable-build-with-cxx in
> other configuration--other bootstraps, cross-compilers--to see how well
> it works.  Please let me know if you run into problems that you don't
> know how, or don't have time, to fix.

MIPS bootstraps fine with --enable-build-with-cxx:

  http://gcc.gnu.org/ml/gcc-testresults/2009-06/msg02323.html

I don't know if the new failures are related to C++; I will do a C build
later and compare.

Ian, thanks for your C++ work!

Adam

Re: Phase 1 of gcc-in-cxx now complete

[Adam Nemet]

Ian Lance Taylor <iant@google.com> writes:
> I would like to encourage people to try using --enable-build-with-cxx in
> other configuration--other bootstraps, cross-compilers--to see how well
> it works.  Please let me know if you run into problems that you don't
> know how, or don't have time, to fix.

With GMP 4.2.1 build fails like this:

g++ -mabi=n32 -c  -g -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -I. -I../../src/gcc -I../../src/gcc/. -I../../src/gcc/../include -I../../src/gcc/../libcpp/include  -I../../src/gcc/../libdecnumber -I../../src/gcc/../libdecnumber/dpd -I../libdecnumber
../../src/gcc/c-lang.c -o c-lang.o
In file included from ../../src/gcc/double-int.h:24,
                 from ../../src/gcc/tree.h:30,
                 from ../../src/gcc/c-lang.c:27:
//usr/include/gmp.h:515: error: 'std::FILE' has not been declared
make[3]: *** [c-lang.o] Error 1
make[3]: Leaving directory `/mnt/src/gcc-tmp/mips64octeon-linux/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/mnt/src/gcc-tmp/mips64octeon-linux'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/mnt/src/gcc-tmp/mips64octeon-linux'
make: *** [all] Error 2

We need at least GMP 4.2.3 with --enable-build-with-cxx:

From <http://gmplib.org/gmp4.2.html>:

Changes in GMP 4.2.3
Bugs:

    ...
    * For C++, gmp.h now includes cstdio, improving compiler
    compatibility. 
    ...

Adam

Re: Phase 1 of gcc-in-cxx now complete

[Jack Howarth]

On Fri, Jun 26, 2009 at 01:33:06AM -0500, Gabriel Dos Reis wrote:
> On Thu, Jun 25, 2009@5:47 PM, Joe Buck<Joe.Buck@synopsys.com> wrote:
> > On Thu, Jun 25, 2009@03:19:19PM -0700, Joseph S. Myers wrote:
> >> On Thu, 25 Jun 2009, Ian Lance Taylor wrote:
> >>
> >> > * Test starting the bootstrap with earlier versions of the compiler to
> >> >   see which C++ compiler version is required, and document that.
> >>
> >> I think the right approach is not documenting observations like that, but
> >> investigating the causes of failures with older compilers and making it
> >> build with as wide a range of versions of GCC (and ideally@least one
> >> non-GCC C++ compiler, probably an EDG-based one such as the Intel
> >> compiler) as is reasonable.
> >
> > Microsoft's and Sun's compilers would be more likely to run into issues,
> > particularly Sun's; Sun has had a policy of preferring solid backward
> > compatibility to standards compliance, so I've tended to have more
> > problems getting correct, standard C++ to run on their compiler than on
> > others.  This is particularly true of template-based code and nested
> > classes.
> 
> Yes, but I also think that we should aim for a conservative subset
> of C++ -- that is solid enough for the last decade.  I don't pretend
> that is an easy task, but I believe that can only help us.
> 
> -- Gaby
> 
> 

Certainly the minimum version of gcc required for compiling with the
cxx support should be well defined. On Mac OS X for instance, the ppl
required for the graphite support in gcc >= 4.4 doesn't compile with
Apple's g++-4.0.1 compilers and requires their g++-4.2.1 compilers 
instead. 
            Jack

Re: Phase 1 of gcc-in-cxx now complete

[Gabriel Dos Reis]

On Thu, Jun 25, 2009 at 5:47 PM, Joe Buck<Joe.Buck@synopsys.com> wrote:
> On Thu, Jun 25, 2009 at 03:19:19PM -0700, Joseph S. Myers wrote:
>> On Thu, 25 Jun 2009, Ian Lance Taylor wrote:
>>
>> > * Test starting the bootstrap with earlier versions of the compiler to
>> >   see which C++ compiler version is required, and document that.
>>
>> I think the right approach is not documenting observations like that, but
>> investigating the causes of failures with older compilers and making it
>> build with as wide a range of versions of GCC (and ideally at least one
>> non-GCC C++ compiler, probably an EDG-based one such as the Intel
>> compiler) as is reasonable.
>
> Microsoft's and Sun's compilers would be more likely to run into issues,
> particularly Sun's; Sun has had a policy of preferring solid backward
> compatibility to standards compliance, so I've tended to have more
> problems getting correct, standard C++ to run on their compiler than on
> others.  This is particularly true of template-based code and nested
> classes.

Yes, but I also think that we should aim for a conservative subset
of C++ -- that is solid enough for the last decade.  I don't pretend
that is an easy task, but I believe that can only help us.

-- Gaby


>
>

Re: Phase 1 of gcc-in-cxx now complete

[Joe Buck]

On Thu, Jun 25, 2009 at 03:19:19PM -0700, Joseph S. Myers wrote:
> On Thu, 25 Jun 2009, Ian Lance Taylor wrote:
> 
> > * Test starting the bootstrap with earlier versions of the compiler to
> >   see which C++ compiler version is required, and document that.
> 
> I think the right approach is not documenting observations like that, but
> investigating the causes of failures with older compilers and making it
> build with as wide a range of versions of GCC (and ideally at least one
> non-GCC C++ compiler, probably an EDG-based one such as the Intel
> compiler) as is reasonable.

Microsoft's and Sun's compilers would be more likely to run into issues,
particularly Sun's; Sun has had a policy of preferring solid backward
compatibility to standards compliance, so I've tended to have more
problems getting correct, standard C++ to run on their compiler than on
others.  This is particularly true of template-based code and nested
classes.

Re: Phase 1 of gcc-in-cxx now complete

[Eric Botcazou]

> I think the right approach is not documenting observations like that, but
> investigating the causes of failures with older compilers and making it
> build with as wide a range of versions of GCC (and ideally at least one
> non-GCC C++ compiler, probably an EDG-based one such as the Intel
> compiler) as is reasonable.

Yes, I don't think we should require GCC to build GCC, this would be a step 
backwards in my opinion.  I can experiment with the Sun Studio compiler.

-- 
Eric Botcazou

Re: Phase 1 of gcc-in-cxx now complete

[Joseph S. Myers]

On Thu, 25 Jun 2009, Ian Lance Taylor wrote:

> * Test starting the bootstrap with earlier versions of the compiler to
>   see which C++ compiler version is required, and document that.

I think the right approach is not documenting observations like that, but 
investigating the causes of failures with older compilers and making it 
build with as wide a range of versions of GCC (and ideally at least one 
non-GCC C++ compiler, probably an EDG-based one such as the Intel 
compiler) as is reasonable.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Phase 1 of gcc-in-cxx now complete

[Richard Guenther]

On Thu, Jun 25, 2009 at 10:32 PM, Ian Lance Taylor<iant@google.com> wrote:
> I am pleased to report that if you configure gcc with
> --enable-build-with-cxx, which causes the core compiler to be built
> using a C++ compiler, a bootstrap on x86_64-unknown-linux-gnu now
> completes.
>
> I would like to encourage people to try using --enable-build-with-cxx in
> other configuration--other bootstraps, cross-compilers--to see how well
> it works.  Please let me know if you run into problems that you don't
> know how, or don't have time, to fix.
>
> This completes the first phase of the gcc-in-cxx project, which I
> started about one year ago at the 2008 GCC Summit.
>
> At this point I personally will probably not work on this project for
> some weeks, other than bug fixing.  Further steps on the overall project
> of converting gcc to C++ are:
>
> * Write a coding standards document for gcc in C++.
>
> * Convert more code to be compiled as C++ when using
>  --enable-build-with-cxx.  Currently the generator programs
>  (genattrtab, etc.) and libcpp are still compiled as C.
>
> * Develop some trial patches which require C++, e.g., convert VEC to
>  std::vector.
>
> * Test starting the bootstrap with earlier versions of the compiler to
>  see which C++ compiler version is required, and document that.
>
> * Petition the steering committee for formal approval to switch to C++.
>
> I do not expect to convert the compiler to require C++ in the 4.5
> timeframe.

I think it would be a good thing to try forcing the C++ host compiler
requirement for GCC 4.5 with just building stage1 with C++ and stage2/3
with the stage1 C compiler.  --disable-build-with-cxx would be a
workaround for a missing C++ host compiler.

That should give us an idea on what problems we are going to face
when switching to actual C++ code.

Richard.

> I encourage anybody who is interested to experiment with these further
> steps.
>
> Ian
>

Phase 1 of gcc-in-cxx now complete

[Ian Lance Taylor]

I am pleased to report that if you configure gcc with
--enable-build-with-cxx, which causes the core compiler to be built
using a C++ compiler, a bootstrap on x86_64-unknown-linux-gnu now
completes.

I would like to encourage people to try using --enable-build-with-cxx in
other configuration--other bootstraps, cross-compilers--to see how well
it works.  Please let me know if you run into problems that you don't
know how, or don't have time, to fix.

This completes the first phase of the gcc-in-cxx project, which I
started about one year ago at the 2008 GCC Summit.

At this point I personally will probably not work on this project for
some weeks, other than bug fixing.  Further steps on the overall project
of converting gcc to C++ are:

* Write a coding standards document for gcc in C++.

* Convert more code to be compiled as C++ when using
  --enable-build-with-cxx.  Currently the generator programs
  (genattrtab, etc.) and libcpp are still compiled as C.

* Develop some trial patches which require C++, e.g., convert VEC to
  std::vector.

* Test starting the bootstrap with earlier versions of the compiler to
  see which C++ compiler version is required, and document that.

* Petition the steering committee for formal approval to switch to C++.

I do not expect to convert the compiler to require C++ in the 4.5
timeframe.

I encourage anybody who is interested to experiment with these further
steps.

Ian