Date: Sun, 5 Jan 2020 23:55:52 -0700 From: Warner Losh <imp@bsdimp.com> To: "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: <CANCZdfr-=DUVJ7Bd9SgA9kyQ3TKZefOZfu76TJ9XgRgo2OJHWQ@mail.gmail.com> In-Reply-To: <CANCZdfrZ-C37c7Eso7NrtMG5_kv3T9qO3c3k8xcgEeTCrY3nQg@mail.gmail.com> References: <CANCZdfrZ-C37c7Eso7NrtMG5_kv3T9qO3c3k8xcgEeTCrY3nQg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Aug 13, 2019 at 10:00 AM 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
>
OK. We're about half way through this and it's a good time to reevaluate
the schedule.
When we started this, all mips, all powerpc, some arm versions and sparc64
were the problem children that still required gcc 4.2.1 for various reasons.
Since then, all the platforms except sparc64 have made excellent progress.
Nothing non-trivial has been done for sparc64. None of the platforms,
except sparc64, requires gcc 4.2.1 any more. There are issues here and
there to sort out, but the list is massively reduced from when we started,
and people are actively working on (or have credibly signed up to work on)
everything in mips, arm, and powerpc land. We've learned many things we
didn't know when we started, and some of those issues are still in flight.
well done for all the hard work.
sparc64 stands out as an outlier. No non-triival work has been done on it,
as I've said. I think that unless there's some massive amount of work done
on sparc64, in secret, it's time to just remove the port. It's been getting
in the way of forward progress for a long time. It's time to admit there's
no maintainer that's actively maintaining and remove it from the tree. In
addition to not running on relevant sparc hardware, it's broken and a tax
on all forward progress on kernel work that has a MD component to it. The
many cries of 'I'll do something' over the past several years have resulted
in no actual contributions.
in-tree gcc 4.2.1 is also no longer required for forward progress on arm,
mips, and powerpc. libunwind from gcc is still used by 32-bit arm, however,
since the compiler_rt version is broken.
So I'd like to propose we alter the above schedule in light of new
information we gleaned from executing the first half of it.
First, we schedule the removal of sparc64 for 2020-01-31. Nobody has done
anything at all on it to date, making it a significant outlier when
measured against the other architectures. It's pointless to wait another 4
months to remove it when there's no evidence to suggest there will be any
work done on it. It's hindering some kernel work being done that has MD
components, which means we should speed up its removal if truly nobody has
the time to do the work needed to keep the port viable.
Second, all other platforms still have the original deadlines to sort out
the last lingering issues with the external toolchain and/or clang. mips is
a bit up in the air right now since both the external toolchain and clang
have issues (though different issues). powerpc 32-bit is sorting out issues
as well. arm 32-bit still needs libunwind from gcc. An end of May deadline
is ample time for works in progress to get to the point where everything
boots and runs sufficiently well to show the platforms are still viable.
Third, we should move up the removal of gcc 4.2.1 to 2020-02-29 as well,
with a deadline of 2020-01-31 for someone to publish a github branch that
removes gcc for wide-spread testing. An exception to the gcc rule should be
made for libunwind until that can be sorted out.
Fourth, we keep the deadline for release integration to external toolchain
the same at 202-07-31. As far as I know, no work has begun on this, so we
may need to reevaluate it again in 4 months after we've completed the
transition on all the other tier 2 platforms.
In summary:
2020-01-31: start removing sparc64 support from the tree
gcc removal test tree published in github
2020-02-29: remove gcc, assuming no unexpected issues with its removal
remain
2020-05-31: deadline for all other architectures to sort out the last
remaining issues with external toolchain and/or clang and show multiuser
booting
2020-07-31: deadline for the supporters of tier 2 architectures to get any
changes in to the re@ release build process for those requiring external
toolchain support
An informal poll on IRC suggests there will be wide-spread support for
these alterations to the schedule. This email casts a wider net to test the
validity of that hypothesis.
Comments?
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfr-=DUVJ7Bd9SgA9kyQ3TKZefOZfu76TJ9XgRgo2OJHWQ>