Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 5 Oct 2017 23:41:49 +0000
From:      Brooks Davis <brooks@freebsd.org>
To:        Warner Losh <imp@bsdimp.com>
Cc:        "freebsd-arch@freebsd.org" <arch@freebsd.org>
Subject:   Re: Making C++11 a hard requirement for FreeBSD
Message-ID:  <20171005234149.GE8557@spindle.one-eyed-alien.net>
In-Reply-To: <CANCZdfq5=KRp4NYKsc15gyS9C7CxrBFxcKQLPwnb_0oPb15vJw@mail.gmail.com>
References:  <CANCZdfq5=KRp4NYKsc15gyS9C7CxrBFxcKQLPwnb_0oPb15vJw@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help

--xHFwDpU9dbj6ez1V
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Oct 05, 2017 at 04:28:44PM -0700, Warner Losh wrote:
> I'd like to start a conversation about the viability of making C++11 a ha=
rd
> requirement for bootstrapping FreeBSD and setting a specific deadline for
> doing so.
>=20
> 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.
>=20
> 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.
>=20
> 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.

This deadline seems viable to me.

> 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 th=
at
> a newer version of gcc as an external toolchain could work.

mips64 should be good to go with external clang and lld in LLVM 6.0
and the llvm-devel port should be ready before then (We need to get
multi-got support landed upstream and then Alex has a fix for the
remaining lld issues).  As it is, I run clang built mips64 binaries
daily.

I'm certain the riscv supporting GCC supports C++11, but we might need
to do some testing and tweak some make bits.

If someone wants to test sparc64, that's fine, but with Oracle laying
off the SPARC it's arguably more dead than IA64 was when we removed it
(Intel shipped the last design *this* May).

-- Brooks

--xHFwDpU9dbj6ez1V
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJZ1sM9AAoJEKzQXbSebgfAMdkIAJNAb/q9qJf6AGZKAebaii9m
z8n+FBcIQWQ+Q9BAclHmZG85DrhQnSlablXWta6R8k6S139XWrMr9sbvLh1YRRjA
UEa9UwnxvaBNveSZBA1jH5UyoTD2mLuGGeYKiczdiQCczSOMohOzuOHCdpJd3fmQ
uAKUaRp7x5P8HPZ2l58RYFG3sHrvdtq8bnuQWXReUfPHuC1ZEqMcl4cgk5Ytrxf2
YYXQypnqKEtxyOlm52F517GX3s87T/noVFcoryV0uLzrb9V0Q8c3rZxfnKBNBQQo
lM6XcGz8CyBtMbttVR572cC8cn+9oZ+OCm1nVcaTjy5c8ScrzOqQ1iwG6x/5m28=
=rTAM
-----END PGP SIGNATURE-----

--xHFwDpU9dbj6ez1V--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171005234149.GE8557>