Date: Tue, 13 Aug 2019 10:39:45 -0600 From: Warner Losh <imp@bsdimp.com> To: Justin Hibbits <chmeeedalf@gmail.com> Cc: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: Gcc 4.2.1 to be removed before FreeBSD 13, a firm timeline Message-ID: <CANCZdfoE%2BtC54toB%2BX5He4FdMMrucPSFth7E9RJ8Wnghr6oMqw@mail.gmail.com> In-Reply-To: <20190813112956.7c9f648e@ralga.knownspace> References: <CANCZdfrZ-C37c7Eso7NrtMG5_kv3T9qO3c3k8xcgEeTCrY3nQg@mail.gmail.com> <20190813112956.7c9f648e@ralga.knownspace>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Aug 13, 2019 at 10:30 AM Justin Hibbits <chmeeedalf@gmail.com> wrote: > On Tue, 13 Aug 2019 10:00:30 -0600 > Warner Losh <imp@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=E2=80=99s long past time to have a firm pla= n 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=E2=80=99s no= w > > 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=E2=80=99s expected that this always will be working later in t= he > > year. We=E2=80=99ll 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=E2=80=99ll turn off > > -Werror on gcc 4.2.1 (and MFC it to stable/11 and stable/12). We=E2=80= =99ll > > 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=E2=80=99ll turn off building gcc by default. This will effecti= vely > > 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=E2=80=99t supported by the rel= ease > > engineer=E2=80=99s release scripts will be removed. This will happen o= n 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=E2=80=99s discovered, the timeline can be amended. > > > > Also note: the all toolchains in tree discussions are specifically > > out of bounds here. Let=E2=80=99s 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfoE%2BtC54toB%2BX5He4FdMMrucPSFth7E9RJ8Wnghr6oMqw>