Re: GCC 4.3 target deprecation proposals

["John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>]

> On Tue, Jan 22, 2008 at 10:01:55AM +1100, Ben Elliston wrote:
> > My understanding is that NetBSD port to the vax is very much alive and
> > maintained.  Thus, I expect that those users (eg Matt Thomas) would like
> > to see the GCC port retained.
> 
> How can we encourage the NetBSD folks to participate more directly,
> including helping to test the trunk?  I haven't been following NetBSD
> carefully, but I get the impression that at least some of the BSDs
> work with older gcc branches, staying away from the bleeding edge,
> and this could put some of their ports at risk if we have no one to
> test the compiler.

Here are a few of my thoughts and suggestions on this issue:

1) From personal experience, I know that it is a major commitment for
   someone to become a port maintainer.  It takes a lot of time to keep
   a port going at the bleeding edge.  In addition, skill is needed to
   argue the merit of changes to the compiler outside the area of
   responsibility of the port maintainer.  The maintainer may have to
   maintain a farm of machines with different operating systems.  In
   my case, I have been fortunate that the National Research Council
   of Canada has provided space and resources for machines.  HP has
   donated a number of machines.

   For folks primarily interested in an OS port, the GCC requirement to
   build and test the port on a regular basis is just another hurdle
   in getting their port working.  Thus, I can see why many hesitate to
   become port maintainers.

2) For ports that support full blown operating systems, it would seem
   that simulators provide a mechanism to develop and test these ports.
   Current PCs certainly have the power to do this testing.  So, it might
   be helpful if a set of GCC test simulators were setup and available
   for download.

3) I think the GCC release cycle may be too fast for many distributions.
   We also may be closing branches too early.

   I believe TheWrittenWord is using 3.4 for its HP-UX and AIX distributions.
   Apple Panther used 3.3, Tiger 4.0.1.  Don't know about Leopard.  Debian
   Lenny is using 4.1 and it's not yet stable.  The main point is
   distros pick a GCC version and stay with it for the life of each
   distribution.  It's quite possible that the GCC project will stop
   maintainence of the version being used before a distribution is
   released.

   As a result, I think the distros have to perform their own GCC
   maintenance.  Nobody is going to pay any attention to a bug reported
   against a GCC version that is no longer maintained unless it is still
   present in the head.

4) The GCC project may be too strict about applying fixes to previous
   releases.  The home page suggests that only regression fixes can
   be applied to previous releases.  In practice, the project isn't
   that strict and allows fixes for important bugs to be applied to
   previous releases if they aren't risky.

   I can point to at least one situation where blindly freezing a
   product has led to a situation where the application is non functional
   for many users and the company is ignoring requests for a fix.
   As a result, the company is experiencing a public relations nightmare.

   The main reason I mention this is that it may take one or two
   releases before the cause of a bug surfaces when a port has limited
   support.

   I don't think GCC has major product problems but it might be interesting
   to do a statistical study of bugs reported against released versions.

In sumary, there is a tricky balance in all this.  The stage1 renewal
is clearly essential for the health of GCC.  On the otherhand, we can't
lose sight of the fact that GCC is a tool that must be reliable and
standards complient.  Sometimes stage1 requires a lot of work on the
part of port maintainers.  Port maintainers often have to do the initial
leg work to debug and classify bugs.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)