Subject: Re: Old gnu tools
To: None <thorpej@nas.nasa.gov>
From: Kerry James Paulson <umpaul11@cc.UManitoba.CA>
List: netbsd-help
Date: 08/25/1995 19:59:58
Jason Thorpe writes:
> 
> umpaul11@cc.UManitoba.CA (Kerry James Paulson) writes:
> 
>  >   I think it would be a good idea to freeze current now (it's been a long
>  > time since the last release) and update all the GNU tools to the latest
>  > version.  If the source is in a relatively bug free state prior to the
>  > release any bugs caused by the compiler upgrade will be easier to find and
>  > correct. 
> 
> This approach seems flawed.  For one, if you've frozen the source tree, 
> you can't upgrade the toolchain, by definition.  Secondly, it seems to me 
> like it's a Bad Idea to upgrade the compiler just before a release.  
> (That's the kind of thing you want to do just _after_ a release.)
> 

  Sorry, I'm not very familiar with the release procedures so I may have
worded this badly.  What I mean is that in order to find the compiler bugs
the release needs to be in as bug free a state as possible so that compiler
bugs are not confused with code bugs.  I use current anyway so I would not
mind if the upgrade was made after the official release.


> It's also not clear to me that the `latest verion' of the GNU toolchain 
> is bug-free enough to upgrade to.  I've heard of bad code generation for 
> the m68k under 2.7.0.
> 
> Don't get me wrong, I want a new toolchain as much as anyone else, but 
> the upgrade needs to be approached _very_ carefully (indeed, you're kind 
> of screwed if you break the compiler).
> 
> --------------------------------------------------------------------------
> Jason R. Thorpe                                       thorpej@nas.nasa.gov
> NASA Ames Research Center                               Home: 408.866.1912
> NAS: M/S 258-6                                          Work: 415.604.0935
> Moffett Field, CA 94035                                Pager: 415.428.6939
> 

  I don't think the upgrade has to be to the latest version, especially
not if is known to be buggy.  Most platforms lag behind by a release
because the bugs of the older version tend to be known by that point. 
It's possible to ingrate the fixes from the newer release without adding
the features (ie: bugs). 2.6.? would be fine with me.  My reason for
upgrading to >2.4.5 was so that I would be using the same compiler for my
C/C++ courses as my university and they are using 2.6.3.  The point isn't
to upgrade for the sake of being trendy, but the last few releases have
added quite a few useful improvements as opposed to just new `features'. 

Kerry