Date: Sun, 22 Oct 2017 22:48:28 -0700 From: "Ngie Cooper (yaneurabeya)" <yaneurabeya@gmail.com> To: Marius Strobl <marius@freebsd.org> Cc: Mark Linimon <linimon@lonesome.com>, "A. Wilcox" <AWilcox@Wilcox-Tech.com>, Gerald Pfeifer <gerald@pfeifer.com>, freebsd-sparc64@FreeBSD.org, freebsd-arch@freebsd.org Subject: Re: future of sparc64 (was: Making C++11 a hard requirement for FreeBSD) Message-ID: <353165E9-561A-4A4E-9906-3471928C770B@gmail.com> In-Reply-To: <CB71FA85-BBE1-4633-990C-4AB10A91D071@gmail.com> References: <CANCZdfq5=KRp4NYKsc15gyS9C7CxrBFxcKQLPwnb_0oPb15vJw@mail.gmail.com> <20171005234149.GE8557@spindle.one-eyed-alien.net> <59D6CA6C.1040502@Wilcox-Tech.com> <20171007174124.GA20810@lonesome.com> <20171010211428.GA51868@alchemy.franken.de> <CB71FA85-BBE1-4633-990C-4AB10A91D071@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_BECFF20C-DDF8-4900-A417-329769119FE4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 22, 2017, at 22:47, Ngie Cooper (yaneurabeya) = <yaneurabeya@gmail.com> wrote: >=20 >=20 >> On Oct 10, 2017, at 14:14, Marius Strobl <marius@freebsd.org> wrote: >>=20 >> On Sat, Oct 07, 2017 at 12:41:24PM -0500, Mark Linimon wrote: >>>=20 >>> All gccs > 4.9 fail to build. Looking at the logs AFAICT the = failure >>> is a floating-point exception as soon as the first built binary is = run >>> during the internal testing. >>=20 >> The most plausible cause for that is executables and/or dynamic = libraries >> not installing the user trap handlers as specified by the libc 64 = psABI, >> i. e. not call __sparc_utrap_setup(). Do the ports GCCs use their own = CRT >> nowadays? Do they no longer link libc last? Please provide their = linker >> invocation. Also, please provide the backtrace of a minimal program >> exhibiting that problem. >=20 > An idea occurred to me (after having dealt with building things over, = and over, and over, this weekend): since we can=E2=80=99t rely on the = ABI on ^/head to be stable, why don=E2=80=99t we produce working = dynamic/static toolchains on HEAD-1 in ports, then require them for the = areas that can=E2=80=99t bootstrap (yet, or at all?) with clang? We=E2=80=99= ve already done that with some of our code that=E2=80=99s been deorbited = from base (like rsh, etc). I don=E2=80=99t see why making a toolchain = based on a stable ABI for architectures that will migrate or will be = killed off needs to be a huge undertaking (politically), and needs to = hold us back from making progress using a compiler that implements an = almost 7 year old C++ spec. =E2=80=A6 and yes, this can be interpreted as =E2=80=9CI will do it as = long as people don=E2=80=99t bikeshed me to death on the idea=E2=80=9D. -Ngie --Apple-Mail=_BECFF20C-DDF8-4900-A417-329769119FE4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE5bk3FaGcY5rvqmb79YOpJmkwhhUFAlntgqwACgkQ9YOpJmkw hhXJqg/8D0o4xyRPGevVzoN9XsJGlfC9ZBOrfOx6F9Q2N8yGWyn8IH/git4wHFej xw0sshT5ySbmVa0dHqikArzE4pCzAXfGMa3UoZFUT075FZJHOeYqsQsVnKOCWbEo Zj4xW0z2UGxBKG0CnfxoRpIgh3W4Ch8uxE2ZyFmYvuzTa6EQvmHxN0Kh6kPv+6D7 fcS/oVKie8fIjdga5jl/jaRWandq6Nefweo1BZ6yS/0P+KGdL7QU/Vtgat59ILlb rkYYcigagxLHJCY3NraBb/bFwvIwMTjfX5iloIOccjXzKxyZCfWi4aLL+cMvEaIO 6KXsKlRxPnFCqj6edlf5A7lr/Hz8E3+luH2U72FmBgYLf4HD/cXrxelHsxJiSP4R HLXQrI7zuNJCGgUwIbIS9ThGejq/oYGDtao403KPSfiO7z0/k0zY5wvtKtwW8jIi 9GQANY10H5+yFwIUpdRCaPEYKCVjTp1nISrW0w2ZBrQY4lXsvuZ9Ll6kRjB8LsI1 S4EJDjOlFNdoDYwvwnJGShl69pzjAffO8kStInJATP/d4Qz34R5oJubo+LzKRjAG TFcWJrPiQwtfzDpricjWK0i1mdqGOc6JlJ4o/9yjUSywPeqn8zaQn/7/n7123ieH 5xTGcBbxpwJhvVqv9mV02zd9znhDrDNmWj3vgcFTvx1kniy3X5Y= =MoDd -----END PGP SIGNATURE----- --Apple-Mail=_BECFF20C-DDF8-4900-A417-329769119FE4--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?353165E9-561A-4A4E-9906-3471928C770B>