Date: Sun, 22 Oct 2017 22:47:03 -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: <CB71FA85-BBE1-4633-990C-4AB10A91D071@gmail.com> In-Reply-To: <20171010211428.GA51868@alchemy.franken.de> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_6F5B54AF-4860-454F-A1B8-C65D9AA8C288 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > 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. 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. Thanks, -Ngie --Apple-Mail=_6F5B54AF-4860-454F-A1B8-C65D9AA8C288 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----- iQIzBAEBCgAdFiEE5bk3FaGcY5rvqmb79YOpJmkwhhUFAlntglcACgkQ9YOpJmkw hhU1YA/9GqhSESf6+PxdqZzHes+zqITzwrGXIMZjdrOrE8N9lRSDVZtFGPva0jWl xuzpUEdHrFtnY7+ByCaA5qgy4yqLck1X82E2IPdUjeGHSzo+b0skonHbYvGPkT/n ow2PkuuLo1XkbiFOpRkSb3MZ3yqut7wIF7WkL5COn0nkyjLsswsfdHnVwNB2Txq4 4cYjzO7RYcjCI6zKZVg38OoV9sKaAG/2/DzJNPW1KIaZjdzmD7AXn+2+Fp3KqmAT vmNNydbPr43tTPQ8AHBRLgVEC4qz9vmXmLArqC86VKWo/S6kewzFtAHL3SH0KYjX bNsNvPV1XyWl7HnVT/0fWmpjv42rnVvd98jmW2GWO+1HxQTQB3BNJlaEHzJTVsGn CkxarkL7hARHnXJ8bzE4Ecn7gLdn3e+KjLm2cesrTJnqdr2iEHrUP50BjrR9bXFN XtFPIGc7sP086PWyeTnx1AGu8BDIsSlmYXJpo28PNqM6HAxjBwW0LL2isAL79YEt Gvitp/IYUKulajlAlycyXFGtBHPTdP6WGaPwgVl1GFDWq7bq8BDUfpc171KaDpfs sY/uSG8ooC/R32mRBXMY2XtywWl6exzYyM/5SEK0cEcyD9qFncbALurJ9/D0X6+Q SJIHRRum1rCp78VGNReKKQJrQeeAc18uUBm5MQQFlA7bYCBN0hg= =Tnci -----END PGP SIGNATURE----- --Apple-Mail=_6F5B54AF-4860-454F-A1B8-C65D9AA8C288--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CB71FA85-BBE1-4633-990C-4AB10A91D071>