From owner-freebsd-arch@freebsd.org Tue Aug 13 16:00:44 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 56A02B3D7F for ; Tue, 13 Aug 2019 16:00:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 467HVz5MrGz42dH for ; Tue, 13 Aug 2019 16:00:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x730.google.com with SMTP id m2so6215851qki.12 for ; Tue, 13 Aug 2019 09:00:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=hbeWk6FZ9VvexZHDslruuBSvfg+3/M9+X1nf4n3ly4w=; b=nbOCVDqG2P7Jrv9lgHNFDQnRWwrBLykz1kVyhLwIqwRRFIv7Ul/S9i7OSpMFSDZGv0 uKgmaIgN1ECN8kd/pmw7mzkpGbsdomosNfZ2o2S7AXxG1IL2ZNon+uqwXcquA1WIV2mn fJVSxbWUatOALr0nv/VMdVcVJY5ESxAUPoYI+p/RRvnfEtN/Kwnf0yd9CWRjW8/wMQ5G XV1QbW5EoHr3Qem02/86ywaMQ71HQVtfJmj9RCR0yB4fUcOLlX0BaVy3bpvpdaG+ThVb PxuhggesWLTm3Qa2GvaQEslxBFeouv+cmO7do9chXFdKfpauV1LHOZmFOBZa0LCaEhYd xAIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=hbeWk6FZ9VvexZHDslruuBSvfg+3/M9+X1nf4n3ly4w=; b=dj2nnPYu9OnyJUvMeZdAAITGk8veSwO3ZqLvJ4muOL8Yr/UQFAOCFeTiMayDBeQzpe 08UW9w95eiE+GEggO0xUjWVRQfCOt5xeI4f/+sdb0NHY7CRAO3eWl0moLAONZ/5QD5nN M/JxLorK+7Cf6Te6yZ7/nUAcxGvlaEtp/OsY4j8BIQDEZvaVqe0Gj69w8y1Trboj7Mbt 41avbI42aQ2K4kf7sOA2e5gBPRgzlsAD2QbT8YT+8Fnq/IWnoCjsf/4peAqxwfDukcrI 5V0nwGZU7wVGbof9lhPBE1ux/4rOUftq9u2rN25WtwlG2Juz6gK6GW6rJnAlEQofHzsG jS6Q== X-Gm-Message-State: APjAAAXT+xYS+4NY/vA+4DgcZnszD2QJVhx8CFkIsvP8Xp6/+5RptR1y 0O0l3TJV7jUi8dsbwxGs+GIRJ/fiPWodmYGIBasS1jqJADGzQg== X-Google-Smtp-Source: APXvYqyg+xoqVVHLX+NTZC9b0Latru6Y/9eZ+B1eWz++yFeKsFD6iomPe6eXl+G9n5yYBmshsf6E8j9mrrMUrgMSno0= X-Received: by 2002:a37:83c4:: with SMTP id f187mr33757076qkd.380.1565712041884; Tue, 13 Aug 2019 09:00:41 -0700 (PDT) MIME-Version: 1.0 From: Warner Losh Date: Tue, 13 Aug 2019 10:00:30 -0600 Message-ID: Subject: Gcc 4.2.1 to be removed before FreeBSD 13, a firm timeline To: "freebsd-arch@freebsd.org" X-Rspamd-Queue-Id: 467HVz5MrGz42dH X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=nbOCVDqG; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::730) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-5.96 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(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]; RCPT_COUNT_ONE(0.00)[1]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; NEURAL_HAM_SHORT(-1.00)[-0.997,0]; RCVD_IN_DNSWL_NONE(0.00)[0.3.7.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]; TO_DN_EQ_ADDR_ALL(0.00)[]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-2.96)[ip: (-9.41), 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:00:44 -0000 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 plan fo= r 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 sufficie= nt 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 t= hat this always will be working 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 off -We= rror 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 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 n= eeded to make external toolchains robust before embarking on that discussion. Comments? Warner