From owner-freebsd-arch@freebsd.org Tue Aug 13 16:45:19 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 99C06B54FC for ; Tue, 13 Aug 2019 16:45:19 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (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 467JVQ6Wm6z45Pw for ; Tue, 13 Aug 2019 16:45:18 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-ot1-x335.google.com with SMTP id q20so22133494otl.0 for ; Tue, 13 Aug 2019 09:45:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=14EppGj7yeVV53oHtoiCfp7YesslbVijXWY0J93wOTk=; b=pNuMCOKD/qQ5rPB8AxisHHJGZrhDUR4BE+bw74dB3CSFKygh5ykYT2jizlXsS6/aXY Wd+39mzaVBP5fHJlxuBu6Li0xiUcDk8yMwI9mXOkQt4xLUWD2S6Xzi8Nyi90iFJnKat+ kJzNW80Ze9COU7KN61ZzOLOuL7RlYcLc01WSZlmLz0KKK561/pRb2AnfANCs0+L3q7bz LSV0EY39uTB2iGFv8wny2sxT+LXt4h3K/QWPYTHr7Q2VJ+JbWYjJKLN49RBPguUodpB8 xWklnsqEo/d4APlsnLkB3GDJh1x4aBYPwmOlkUPU7uiVE2aiHjD1YzbBgyjH9u3lVeiC r+Iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=14EppGj7yeVV53oHtoiCfp7YesslbVijXWY0J93wOTk=; b=t0+P2cA7LMOAq5JaYpDjR8R6a9ZNk4Y/cjgw4HGxFZyuAs1upGB5mraFAYtSdeGMvb UIxwePId6hRdWx9rgNxvtKNFC6V7kdbzcOaoJXbnRnYdn9R6Jy4+qKLWb08kU/HobSHH uK3aWyGmE51xDaRpowSS/JxElLo+h0pQl01I5Zk3i8qAuELmtVoCOb/aMsSmXLYqycn4 8oIkmYrC1YKS8j2a1s0ly1WdWvmLSzUFu0kzoCi1fvFlFynnpZOXlwPZSfqQSH6wBAFW uuBvoFFKx8GIAUamzalp1LIqOdLkPi5V9oiLQHYssw6rC4no9iECeEdVuOtsaAt46xSu QKDA== X-Gm-Message-State: APjAAAUC1M90qo8z7DiXZbXtY5I6vRklthuymRvyvhK96YquBBQrb3At awQFQhxpLNUiin14iatGmFU= X-Google-Smtp-Source: APXvYqxltZpyb1xioKJCRTGRsi/uJpeABCpU2kcdLyqLYTi2J2G+iNfzEWHERsgh5xU7QEAd/XgQPQ== X-Received: by 2002:a02:b88b:: with SMTP id p11mr44418786jam.144.1565714716864; Tue, 13 Aug 2019 09:45:16 -0700 (PDT) Received: from ralga.knownspace (173-25-245-129.client.mchsi.com. [173.25.245.129]) by smtp.gmail.com with ESMTPSA id m4sm91239677iok.68.2019.08.13.09.45.16 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Tue, 13 Aug 2019 09:45:16 -0700 (PDT) Date: Tue, 13 Aug 2019 11:45:12 -0500 From: Justin Hibbits To: Warner Losh Cc: "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: References: <20190813112956.7c9f648e@ralga.knownspace> X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; powerpc64-portbld-freebsd13.0) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 467JVQ6Wm6z45Pw X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=pNuMCOKD; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of chmeeedalf@gmail.com designates 2607:f8b0:4864:20::335 as permitted sender) smtp.mailfrom=chmeeedalf@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-0.996,0]; RECEIVED_SPAMHAUS_PBL(0.00)[129.245.25.173.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[5.3.3.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]; IP_SCORE(0.00)[ip: (-8.75), ipnet: 2607:f8b0::/32(-2.97), asn: 15169(-2.39), country: US(-0.05)]; RCVD_TLS_ALL(0.00)[] 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:45:19 -0000 On Tue, 13 Aug 2019 10:39:45 -0600 Warner Losh wrote: > On Tue, Aug 13, 2019 at 10:30 AM Justin Hibbits > wrote: >=20 > > On Tue, 13 Aug 2019 10:00:30 -0600 > > Warner Losh 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