Date: Tue, 13 Aug 2019 11:45:12 -0500 From: Justin Hibbits <chmeeedalf@gmail.com> To: Warner Losh <imp@bsdimp.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: <20190813114512.7ec4910e@ralga.knownspace> In-Reply-To: <CANCZdfoE%2BtC54toB%2BX5He4FdMMrucPSFth7E9RJ8Wnghr6oMqw@mail.gmail.com> References: <CANCZdfrZ-C37c7Eso7NrtMG5_kv3T9qO3c3k8xcgEeTCrY3nQg@mail.gmail.com> <20190813112956.7c9f648e@ralga.knownspace> <CANCZdfoE%2BtC54toB%2BX5He4FdMMrucPSFth7E9RJ8Wnghr6oMqw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 13 Aug 2019 10:39:45 -0600 Warner Losh <imp@bsdimp.com> wrote: > On Tue, Aug 13, 2019 at 10:30 AM Justin Hibbits <chmeeedalf@gmail.com> > wrote: >=20 > > On Tue, 13 Aug 2019 10:00:30 -0600 > > Warner Losh <imp@bsdimp.com> wrote: > > =20 > > > 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 p= lan > > > 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 > > > 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=E2=80=99s expected that this always will be worki= ng > > > later in the 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 o= ff > > > -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 par= t 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 > > > 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=E2=80=99t supported = by > > > the release engineer=E2=80=99s 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=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 =20 > > > > 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).=20 >=20 > 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? >=20 > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190813114512.7ec4910e>