Gcc 4.2.1 to be removed before FreeBSD 13, a firm timeline

[Justin Hibbits]

On Tue, 13 Aug 2019 10:39:45 -0600
Warner Losh <imp at bsdimp.com> wrote:

> On Tue, Aug 13, 2019 at 10:30 AM Justin Hibbits <chmeeedalf at gmail.com>
> wrote:
> 
> > On Tue, 13 Aug 2019 10:00:30 -0600
> > Warner Losh <imp at bsdimp.com> wrote:
> >  
> > > Greetings,
> > >
> > > As promised for almost the past decade or so, gcc 4.2.1 will be
> > > removed from the tree before FreeBSD 13 is branched.
> > >
> > > I propose the following timeline for its removal:
> > >
> > > 2019-08-31: disconnect gcc 4.2.1 from CI build
> > >
> > > Turn off -Werror on gcc 4.2.1 platforms
> > >
> > > Turn off all gcc 4.2.1 from universe by default (can be turned on)
> > >
> > > 2019-12-31: Turn off gcc 4.2.1 build by default (can be turned on)
> > >
> > > 2020-03-31: svn rm gcc 4.2.1 and friends
> > >
> > > 2020-05-31: svn rm all non-clang platforms not supported by
> > > in-tree LLVM or converted to ext toolchain.
> > >
> > > 2020-07-31: svn rm all ext toolchain platforms not supported by
> > > re@ release scripts
> > >
> > > The basic notion is that it’s long past time to have a firm plan
> > > for EOL gcc 4.2.1 in the tree. There is ample external toolchain
> > > support today for platforms that need it to build images, though
> > > that integration with buildworld could use some more polish. It’s
> > > now completely sufficient to move to the next phase of removing
> > > gcc 4.2.1 from the tree.
> > >
> > > We already have gcc 6.4 as an xtoolchain on amd64 in CI. This
> > > should somewhat mitigate the risk for cross-compiler portability.
> > > This is a long-established part of our CI. We want to retain gcc
> > > support for modern versions of gcc since its debuggability is
> > > higher. Notifications for this are currently turned off, but will
> > > be enabled soon. It’s expected that this always will be working
> > > later in the year. We’ll work to update the committers guide to
> > > reflect this, as well as give a recipe for testing.
> > >
> > > The first phase will be at the end of the month. We’ll turn off
> > > -Werror on gcc 4.2.1 (and MFC it to stable/11 and stable/12).
> > > We’ll then stop building all platforms that require it as part of
> > > CI. New warnings will come up, but will no longer waste developer
> > > time in trying to fix. Gcc 4.2.1 platforms will no longer be
> > > built as part of universe, unless you add -DMAKE_OBSOLETE_GCC is
> > > added to the command line. We plan on implementing this by
> > > 2019-08-31.
> > >
> > > An experimental branch will be created that will remove gcc
> > > related bits to expose gaps in planning and to come up with a
> > > list of action items needed to ensure Tier 1 platforms are
> > > unaffected by the gcc removal. The timeline for this is by the
> > > end of September.
> > >
> > > Next, we’ll turn off building gcc by default. This will
> > > effectively break all gcc platforms with in-tree compilers. The
> > > external toolchain support we have will suffice here, and patches
> > > will be accepted for whatever integration are needed for these
> > > platforms with our current ports / packages. The onus for these
> > > changes will be squarely on people that want the platforms to
> > > continue. However, as a stop-gap gcc building can be turned on
> > > for those people transitioning gcc-only platforms until gcc 4.2.1
> > > is removed. This will happen on or about 2019-12-31.
> > >
> > > After a 3 month transition period, gcc 4.2.1 will be removed from
> > > the tree. This will be done on or about 2020-03-31.
> > >
> > > After an additional 2 month transition period, all those platforms
> > > that have not integrated with the FreeBSD CI system, work in a
> > > make universe with the proper packages installed, and are shown
> > > to boot on real hardware will be removed from the tree. This will
> > > happen on or about 2020-05-31.
> > >
> > > After an additional 2 month grace period, those platforms that
> > > require external toolchain integration that aren’t supported by
> > > the release engineer’s release scripts will be removed. This
> > > will happen on or about 2020-07-31.
> > >
> > > The timeline gives powerpc, mips, mips64, and sparc64 9 months to
> > > integrate either into an in-tree compiler, or to have a proven
> > > external toolchain solution. This is on top of the many-years-long
> > > warnings about this being the end game of the clang integration.
> > >
> > > This is the proposed timeline, but should there be a significant
> > > issue that’s discovered, the timeline can be amended.
> > >
> > > Also note: the all toolchains in tree discussions are specifically
> > > out of bounds here. Let’s remove one compiler and get the
> > > infrastructure needed to make external toolchains robust before
> > > embarking on that discussion.
> > >
> > > Comments?
> > >
> > > Warner  
> >
> > Hi Warner,
> >
> > I like this proposal.  All powerpc targets (powerpc, powerpc64,
> > powerpcspe) will switch to clang when we get 9.0 into the tree,
> > which won't be until September or October.
> >
> > That said, I think we should not MFC disabling -Werror on gcc 4.2.1
> > to 12 and 11, since we cannot MFC the clang migration for powerpc64
> > to 12, as it will break the ABI (lld only supports ELFv2, not
> > ELFv1). 
> 
> Why would that be a problem? It will allow us to ease the MFCs that
> might otherwise trigger errors because some new warning (likely
> bogus) is triggered... It would make things easier to cope with not
> being able to MFC the clang thing, I'd think. Am I missing something?
> 
> Warner

Good point.  The concern I have is legitimate warnings getting lost.
However, that can probably be dealt with without too much hassle, on a
case-by-case basis.

- Justin