This is the mail archive of the
mailing list for the GCC project.
Re: Merge C++ conversion into trunk (0/6 - Overview)
- From: Diego Novillo <dnovillo at google dot com>
- To: Richard Guenther <richard dot guenther at gmail dot com>
- Cc: gcc-patches at gcc dot gnu dot org, Lawrence Crowl <crowl at google dot com>, bonzini at gnu dot org, dj at redhat dot com, rguenther at suse dot de, tromey at redhat dot com, laurynas dot biveinis at gmail dot com
- Date: Mon, 13 Aug 2012 07:43:07 -0400
- Subject: Re: Merge C++ conversion into trunk (0/6 - Overview)
- References: <20120812200427.GA12561@google.com> <CAFiYyc24t8Xc9=fMY7emqadg90_m=_WW9gKwMDQ7SSRna1uJ7g@mail.gmail.com>
On 12-08-13 05:37 , Richard Guenther wrote:
On Sun, Aug 12, 2012 at 10:04 PM, Diego Novillo <firstname.lastname@example.org> wrote:
I will be sending 6 patches that implement all the changes we
have been making on the cxx-conversion branch. As described in
http://gcc.gnu.org/ml/gcc/2012-08/msg00015.html, these patches
change the default bootstrap process so that stage 1 always
builds with a C++ compiler.
Other than the bootstrap change, the patches make no functional
changes to the compiler. Everything should build as it does now
I have split the merge in 6 main patches. I will send these
patches to the respective maintainers and gcc-patches.
Please remember that the patches conform to the new C++ coding
1- Configuration changes.
2- Re-write of VEC.
3- Re-write of gengtype to support C++ templates and
user-provided marking functions.
4- New hash table class.
5- Re-write double_int.
6- Implement tree macros as inline functions so they can be
called from gdb.
As discussed before, several of these patches do not fully change
the call sites to use the new APIs. We will do this change once
the branch has been merged into trunk. Otherwise, the branch
becomes a maintenance nightmare (despite not having changed many
caller sites we were already starting to run into maintenance
As I understand only 1. to 3. were kind-of required for the merge, all
other changes are a bonus at this time and should be delayed IMHO
(thus not merged with this batch).
Both #4 and #5 have the same issues as #3 (VEC). What remains to be
done is update a whole swath of user code. This is hard to maintain in
the branch and needs to be done during stage 1. The change in #6 is
similarly ready, so delaying it makes no sense.
What I can do is merge #1-#3 as one rev and merge the others as 3
I also understand that you will, quickly after merging 1. to 3. convert
all VEC users and remove the old interface. This should be done
before any of 4. - 6. is merged as generally we don't want the
"half-converted" to persist, nor have multiple such half-conversions
at the same time.
Yes, there will be no half conversions. We are committed to continue
making changes in this area.