From owner-freebsd-arch@freebsd.org Tue Aug 13 16:39:59 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 36F37B505C for ; Tue, 13 Aug 2019 16:39:59 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 467JNG31yRz452V for ; Tue, 13 Aug 2019 16:39:58 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x831.google.com with SMTP id j15so13386907qtl.13 for ; Tue, 13 Aug 2019 09:39:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=L/DZx3Zy6kRmRjF0Glafl6VZRYLUiqgUwEpESVz5/rI=; b=Cs+z1y2jZZDuYASvvXYTSCTwmb3uVthvSbmyTC26oc9oH1bhdFqRje9mqBccqSRkBH 3QWwjSjE8IJfFZ+fgEMPtQzJwYvfTlzFO5FMHj7h3RwpKRySO/YpTHFB9H2jm3JZt4bm vhDUM0sILO5YPwR/IBh5bIaW4xGfWsv4DqmVbVbQYikBeAJMBw8OyDnpaDwd3HL8UGvp C1EHiQTe0KhAOFpFDX7Afv4brgrH6XoFtqOUY0w6yOje6995W/xO/Ul3WIFkoLBNxtRK G29NDuFuiDJ19CFcNewLnz5jZiamIY5yOiLi6ReltxUMEHE0yqbjzcLwdG8epLuGKJo2 69eA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=L/DZx3Zy6kRmRjF0Glafl6VZRYLUiqgUwEpESVz5/rI=; b=T2mgd+wov+bsZxIiLbQ/8kUMnZYCLAXqQM0jwBHwFvhFDXeYLc67CjnlB3WlKBco9E 6jLeJljrqD9C5NV33308spdzQmHtDc+qQGZ0dlJ96lmL3iZNIeiD4TvlPzskIytrqTZh 0jW5ei1idtgM52LadToHDOKBztq/VBPqPNOKpHMD89qUSYl8duXrMvoYAoWf9rkdvmxg LCl3O4UZEFXbW+75VTAVWUig4p5IKuFP1BOYulIoatnJ1pimjREGesz0sMqCYStVEbCP iLbfD9dGR5k/NMVnXx9OjXlf9rJMJ5oF2WRkstXA0XPqpj94G+ngeOOJyw1N+4DFHjTe Ns7g== X-Gm-Message-State: APjAAAXInafH1CpFUMcOswX0y4a+wDtUugAA5cNWNkdLi5PoLifUslcX 2rXYS69kbASbV0PIWsV1PMboz5DeZeP9sKdN9b+iiiOMhRQ= X-Google-Smtp-Source: APXvYqw1o+/ETxDfIOTR4u7oBCNCeFtEF+RbpK2zSeEfF8ShKfWVy+fQgtYMUcPrID10HIq4ay82GGKgIuAkNVXLvAw= X-Received: by 2002:aed:34a6:: with SMTP id x35mr5947841qtd.187.1565714396792; Tue, 13 Aug 2019 09:39:56 -0700 (PDT) MIME-Version: 1.0 References: <20190813112956.7c9f648e@ralga.knownspace> In-Reply-To: <20190813112956.7c9f648e@ralga.knownspace> From: Warner Losh Date: Tue, 13 Aug 2019 10:39:45 -0600 Message-ID: Subject: Re: Gcc 4.2.1 to be removed before FreeBSD 13, a firm timeline To: Justin Hibbits Cc: "freebsd-arch@freebsd.org" X-Rspamd-Queue-Id: 467JNG31yRz452V X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=Cs+z1y2j; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::831) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-5.95 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[1.3.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-1.00)[-0.997,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; FREEMAIL_TO(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-2.96)[ip: (-9.36), ipnet: 2607:f8b0::/32(-2.97), asn: 15169(-2.39), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2019 16:39:59 -0000 On Tue, Aug 13, 2019 at 10:30 AM Justin Hibbits wrote: > On Tue, 13 Aug 2019 10:00:30 -0600 > Warner Losh 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