On Wed, 5 Jul 2000, Bernd Ernesti wrote:

: > If you're subscribed to source-changes, you'll see an import of gcc 2.95.2
: > on Friday into src/gnu/gcc-2.95/dist.  There are some points to note about
: > this import, which are listed here to solicit objections or modifications:
: 
: Why not import it under src/gnu/dist/gcc-2.95?
: That way you don't pollute the gnu directory.

Actually, I'm modifying it to be
src/gnu/usr.bin/gcc-2.95/{dist,cc1,gcc,etc}.  The separation *away from*
src/gnu/dist as a shared dist directory addresses two points:

- Last time egcs was imported, people bitched because of how big the source
  tree was with two compilers in-tree.  This will allow someone to nuke the
  whole compiler in one shot, or exclude it from CVS updates with a single
  operation.  If you recall, the old gcc 2.7 was in
  src/gnu/usr.bin/gcc (though it didn't use a dist directory).

- This keeps the BSD makefiles a little closer to the dist tree, which is
  what a lot of other software already does in the tree.  gnu/dist is,
  IMHO, a good idea for certain things (were binutils and gcc to work
  together nicely), but not for some of the things we've put in there,
  such as gawk and sed.  In retrospect, these programs should have had
  their own `dist' directories.

On Wed, 5 Jul 2000, Frank van der Linden wrote:

: Wait. A discussion about a new gcc version came up a while ago, when
: Jason was having some problems with C++. At that time, it was brought
: up that gcc 2.95.x didn't work well with m68k (code generation bugs),
: so that it might not be a good way to go. Since then, Jason has
: worked on getting the NetBSD-specific gcc changes into the main
: gcc tree, which hopefully should give us good native support in 3.0.

This can happen in parallel.  I don't see 1.6 as happening `real soon now'
(given our usual branch-time turnaround), so it's very possible that even
3.0 will be imported before 1.6 is cut.

We really need the compiler in our tree so people will have an easy way to
bang hard on it and get these bugs fixed early on.  (For one, I'm going on a
mission to make the kernel printf work like the userland printf, and get rid
of our gross __KPRINTF_ATTRIBUTE__ hack....)

`Who's going to fix the problems if no one uses it?'  8^)

: Also, I know Matt Thomas has been doing VAX ELF work using 2.96,...

Matt actually approved of the import for the ease of hacking on it (as the
ELF vax stuff is more binutils version dependent, from what I gathered).  I
also intended to bring in binutils 2.10, but that has less code divergence.

: to backport that. What's the reason for not picking 2.96? I've heard
: that it has problems. Does it have more problems than 2.95.x?

More to import a release version than an experimental snapshot.  There are
cpp bugs in 2.96, but not major ones; however, I may be inclined to pull in
a 2.96 snapshot instead of 2.95.2 if there's a call from affected parties
(Matt Thomas?  Richard Earnshaw?)

: libcc1.so was made static because it didn't save that much space, and
: it made things slower. Is there a good reason for bringing in back?

The shared portions, as I've now sliced them, don't affect performance in a
major way.  This contains things like the bundled gettext wrappers and
libiberty goop, which is not used for the main compile passes.  It saves a
couple hundred K per backend (there's six backends now:  cc1, cc1obj,
cc1plus, cc1chill, f771, and jc1).

Note that if I switch the plan to a 2.96 snapshot, the bundled cpp code is a
good candidate for libcc1.so, as well.

-- 
-- Todd Vierling (tv@pobox.com)