This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Merge from pch branch; call for testers
- From: Geoff Keating <geoffk at geoffk dot org>
- To: gcc at gcc dot gnu dot org
- Date: Thu, 23 May 2002 14:09:29 -0700
- Subject: Merge from pch branch; call for testers
- Reply-to: Geoff Keating <geoffk at redhat dot com>
The PCH branch is now at a point where I think it would be helpful to
merge the work so far onto the mainline. It fixes a number of bugs
that would be visible in rare circumstances on the mainline (and would
be very difficult to reproduce), the changes don't seem to affect GC
speed much, and it makes it much more convenient to change data
structures in the compiler.
So, I'd first like to call for testers. I'd particularly like:
- Anyone who can build ada to try out the ada on the branch. I am
unable to build ada, so what's there is not very well tested.
- Anyone who has a host that isn't x86-linux and lots of CPU time,
to build and test with --enable-checking=tree,misc,gc,gcac.
The aim is to see if the branch has any regressions relative to
the mainline at the tag 'pch-merge-20020517'. So, to test the branch
you'd usually need to do two builds, on the trees you'd get by doing
cvs co -r pch-merge-20020517 gcc-full
cvs co -r pch-branch gcc-full
and see if the results of the second are at least as good as the
first.
I plan to test
i686-linux native with gcac checking
i686-linux X powerpc-eabisim with gcac checking
i686-linux X mips-elf with gcac checking
sparc-sun-solaris2.6 native
powerpc-ibm-aix4.3.3.0 native
so any other combinations would be helpful.
I have put an initial version of the patch at
<http://people.redhat.com/geoffk/patches/pch-10.patch>. It is 990k in
size.
There are no changes to the behaviour of the compiler in the patch;
from the user's perspective, everything should be just as it is
before. In particular, this doesn't implement any kind of precompiled
headers. It is also not enough, yet, to implement generational or
compacting GC (although it's very close); the remaining tasks before
that point are:
- Make splay trees GCable (for alpha backend)
- Auto-generate RTL marker routine
- Rewrite the RTL constant pool handling,
including integrating the pool from rs6000 backend
- Convert dwarf2 output to use GC
- Do struct JCF and Cpool in the Java frontend
These are another set of possibly destabilizing changes that will take
some time (perhaps 4 weeks), and none of them will be really useful
until they're all done.
I hope to perform the merge in about a week's time, which would be
Thursday, May 30.
--
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>