This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Merge from pch branch; call for testers



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>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]