Date: Thu, 26 Dec 2019 23:39:45 -0800 From: Mark Millard <marklmi@yahoo.com> To: Gerald Pfeifer <gerald@pfeifer.com> Cc: John Baldwin <jhb@freebsd.org>, freebsd-toolchain@freebsd.org, freebsd-ppc@freebsd.org, freebsd-ports@freebsd.org Subject: Re: devel/freebsd-gcc9@powerpc (for example) : it has the clang vs. gcc vec_step name conflict (for powerpc families): build fails under clang Message-ID: <D9EFE02F-E9C4-4F78-9FFE-842938C10F13@yahoo.com> In-Reply-To: <alpine.LSU.2.21.1912271441380.3227@anthias> References: <BE95732C-A03D-47D6-969B-78966768AD5E.ref@yahoo.com> <BE95732C-A03D-47D6-969B-78966768AD5E@yahoo.com> <alpine.LSU.2.21.1912271441380.3227@anthias>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2019-Dec-26, at 20:49, Gerald Pfeifer <gerald@pfeifer.com> wrote: > On Thu, 26 Dec 2019, Mark Millard wrote: >> I tried to build devel/freebsd-gcc9@powerpc on a powerpc64 (in an >> ELFv1 clang environment) and it reported (listing just one of the >> examples that pointed to vec_step): >=20 > I maintain this is a bug in clang which should be address there. >=20 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D239266 I wish they would, but . . . Unfortunately, this is likely a hard sell to the upstream clang folks because https://www.nxp.com/docs/en/reference-manual/ALTIVECPIM.pdf defines vec_step in "2.5.3 Value for Adjusting Pointers" and does not bother with specifying language namespace niceties, as I remember. That dates back to 1999-June. (The "POWER expert" quoted in comment 11 was wrong about the Altivec PIM not having a definition.) Clang has been this way for a long time and ends up considering how many AltiVec related builds would be broken by such a breaking change for those builds. The later OpenCL specification of its vec_step has the same sort of status as I remember. Thus, the same type of considerations likely are involved again. So I expect that, if devel/freebsd-gcc[69] waits for clang to be fixed, instead of having a (hopefully temporary) workaround, then for a significant time those ports likely will not work for being built via clang for targeting powerpc64 or powerpc. An unfortunate context, for sure. >> It turns out that: >>=20 >> # ls -laT /usr/ports/devel/freebsd-gcc9/files/ >> total 44 >> drwxr-xr-x 2 root wheel 512 Dec 25 19:25:26 2019 . >> drwxr-xr-x 3 root wheel 512 Dec 25 19:25:26 2019 .. >> -rw-r--r-- 1 root wheel 4781 Dec 25 19:25:26 2019 = patch-freebsd-format-extensions >> -rw-r--r-- 1 root wheel 1413 Dec 25 19:25:26 2019 = patch-freebsd-libdir >> -rw-r--r-- 1 root wheel 588 Dec 25 19:25:26 2019 = patch-gcc-configure >> -rw-r--r-- 1 root wheel 16346 Dec 25 19:25:26 2019 = patch-gcc-freebsd-mips >> -rw-r--r-- 1 root wheel 231 Dec 25 19:25:26 2019 = xtoolchain.mk.in >>=20 >> is missing the patch-clang-vec_step that is in: >>=20 >> FBSDG5L2# ls -laT /usr/ports/lang/gcc9/files/ >=20 > That is a hack that can be used to work around the issue; I strongly > recommend addressing this in clang properly, though. >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D9EFE02F-E9C4-4F78-9FFE-842938C10F13>