On 12-08-13 05:37 , Richard Guenther wrote:
On Sun, Aug 12, 2012 at 10:04 PM, Diego Novillo <dnovi...@google.com> 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
in trunk.
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
guidelines (http://gcc.gnu.org/codingconventions.html#Cxx_Conventions):
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
problems).
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
separate revisions.
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.
Diego.
