Date: Thu, 5 Jan 2017 14:16:19 -0800 From: Mark Millard <markmi@dsl-only.net> To: Ed Maste <emaste@freebsd.org> Cc: FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: Re: I've submitted llvm bugzilla report 31538 on clang 3.9.1 not supporting the mfpmr and mtpmr instructions used in dev/hwpmc/hwpmc_e500.c Message-ID: <AECFEDA1-B5A6-498E-B598-282B4C4BE6B0@dsl-only.net> In-Reply-To: <CAPyFy2C2Ae98jKV6BdW9Bskn1M_0f-PkEwyBHdHkCqXSyK2DZQ@mail.gmail.com> References: <282B1B1D-9345-4BEA-AC30-DF7D75F8C026@dsl-only.net> <CAPyFy2C2Ae98jKV6BdW9Bskn1M_0f-PkEwyBHdHkCqXSyK2DZQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2017-Jan-5, at 12:33 PM, Ed Maste <emaste at freebsd.org> wrote: > On 4 January 2017 at 17:46, Mark Millard <markmi at dsl-only.net> = wrote: >> I have submitted to llvm (matching up with FreeBSD bugzilla 214904): >>=20 >> Bug 31538 - FreeBSD head (12) buildkernel based on clang FreeBSD's = 3.9.1 stops for mfpmr and mtpmr instructions not being supported (used = in dev/hwpmc/hwpmc_e500.c ) >=20 > Thank you. >=20 >> This report likely should be added to the depends on list in: >>=20 >> Bug 25780 - [META] Using Clang as the FreeBSD/ppc system compiler >=20 > Agreed, I've added it there. Please feel free to add other issues you > find as blocking 25780; my intent is to have it track all of the > outstanding issues preventing a Clang-based "make buildworld > buildkernel" from succeeding on any ppc / ppc64. Thanks and okay. I'll take "succeeding" to include being operational, not just having the builds complete. For example: builds complete but C++ exception handling is completely broken in operation. Even trivial examples fail if they throw an exception. I take devel/kyua being able to be used as going along with buildworld and buildkernel --and that requires C++ exception handling being in working order. (Sound appropriate to include devel/kyua as part of the criteria so that the test environment works?) My bias is to not list things in 25780 that have trivial source code changes for FreeBSD that avoid the issue. And example is the matching-pair: llvm bugzilla 31541 / FreeBSD bugzilla 21568 In this context explicitly supplying one supposedly optional assembler instruction operand in one place in one .S sidesteps the clang's mishandling of the optional status. With WERROR=3D buildkernel was able to "complete" when I made that change in my environment. [In fact the other examples of the instruction in question in that .S file have the optional operand explicitly listed.] ["Complete": because, for example, I've a workaround for the hwpmc_e500.c rejection in place already in order to explore looking for the "next problem". Thus the starting point is not pure head or pure stable/11 in various of my reports.] There are issues not tied to llvm, such as needing to use older versions of devel/binutils and devel/powerpc64-binutils . The slave-port relationship means that to have devel/powerpc64-binutils be older requires devel/binutils to also be older. In my context this is an unfortunate tie for my cross build context but I'm sticking to the Makefiles from svn for such. =3D=3D=3D Mark Millard markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AECFEDA1-B5A6-498E-B598-282B4C4BE6B0>