From owner-freebsd-arch@freebsd.org Fri Oct 6 00:05:24 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 808C4E020A4 for ; Fri, 6 Oct 2017 00:05:24 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 6B1BF67399 for ; Fri, 6 Oct 2017 00:05:24 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 6A520E020A3; Fri, 6 Oct 2017 00:05:24 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 69C2FE020A2; Fri, 6 Oct 2017 00:05:24 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 42AEA67398; Fri, 6 Oct 2017 00:05:24 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id DDF3110A8BA; Thu, 5 Oct 2017 20:05:22 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Cc: Warner Losh , "freebsd-arch@freebsd.org" Subject: Re: Making C++11 a hard requirement for FreeBSD Date: Thu, 05 Oct 2017 16:47:57 -0700 Message-ID: <2116882.XEKuxOb729@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.1-STABLE; KDE/4.14.30; amd64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Thu, 05 Oct 2017 20:05:22 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 00:05:24 -0000 On Thursday, October 05, 2017 04:28:44 PM Warner Losh wrote: > I'd like to start a conversation about the viability of making C++11 a hard > requirement for bootstrapping FreeBSD and setting a specific deadline for > doing so. > > This discussion is motivated by an ask from the jemalloc folks to use a > limited subset of C++11 inside of malloc in such a way that is C safe (so > the C programs wouldn't bloat with a C++ runtime). That's an ongoing > discussion in another forum, and isn't appropriate for this thread because > this has become a frequent request (but if you have opinions, please find > the thread in current@ about it). I don't know the timeline of their plans > to do this. > > I'd like to take the rather vague plans we've had "before 12" and create a > timeline for removal of gcc 4.2 coupled with a requirement for support in > clang or a working external toolchain. This requirement would be coupled > with the requirement that the external toolchain support C++11 constructs. > > I'd like to propose we do this 12/31/17. Any architectures that can't meet > this timeline will be disconnected from universe at that time and deleted > 3/31/18. > > It's my belief that i386, amd64, arm, aarch64, powerpc and powerpc64 are > ready for this change and mips* would be ready for this change with an > external clang toolchain. I'm unsure of riscv and sparc64, but suspect that > a newer version of gcc as an external toolchain could work. In-tree clang 5.0 for MIPS mostly works (modulo some small patches). However, it requires external ld.bfd. I know that there ld.lld can link a working mips64 world with some patches (notably the multigot patch). mips works fine with external GCC. riscv is already using external GCC that is C++11-capable. The problem with external GCC is that you can cross-build a world + kernel just fine and get a working system via CROSS_TOOLCHAIN=foo-gcc. However, that system has no viable '/usr/bin/cc' once GCC 4.2 is removed. bapt@ started on ports to cross-build binutils and gcc packages via the base/* ports, but those are not yet finished / fully tested. I don't think anyone has thought about how release builds will work either with only an external toolchain available. (I'm pretty sure sparc64 has booted fine with external GCC, it's just in the same boat as mips with regard to /usr/bin/cc.) Also, if you svn rm contrib/gcc you will nuke all of our systems because we still use 'crtstuff.c' from there on all architectures for part of the C startup code. emaste@ has looked at a replacement for that from NetBSD in the past but I'm not sure what state that is in currently. Another concern is fully replacing the compiler support libraries (libgcc and friends). Some of those also come from contrib/gcc. For mips I have some patches in review upstream to add mips to LLVM's libunwind (which allows mips to use that for libgcc unwinding). I think sparc64 might be the only other architecture not using llvm libunwind. (Fixing that is a much smaller lift than fixing clang on sparc64 btw, and I've successfully used llvm libunwind on mips worlds that are fully compiled with external GCC.) That said, I definitely support the goal of requiring C++11. I will happily start using it myself in some userland bits (truss for example could benefit from std::unordered_map<>) once it is available across the board. 12/31/17 might be a bit aggressive given the holidays at the end of the quarter, but we can start with that and revisit if need be. -- John Baldwin