Date: Fri, 30 Sep 2016 00:48:38 -0700 From: Mark Millard <markmi@dsl-only.net> To: svn-ports-head@freebsd.org, jbeich@freebsd.org Subject: Re: svn commit: r422956 - in head: emulators/virtualbox-ose games/eduke32 games/openbor graphics/php55-gd graphics/php56-gd graphics/php70-gd mail/thunderbird multimedia/avidemux multimedia/ffmpeg mult... Message-ID: <BF2EA2BD-3298-4F8C-935F-D4892A87E9F6@dsl-only.net>
next in thread | raw e-mail | index | archive | help
Quoting . . .
> Note, FreeBSD 9.x now builds with Clang 3.4 because GCC 4.2 fails:
> =20
> vp9/encoder/x86/vp9_frame_scale_ssse3.c: In function =
'eight_tap_row_ssse3':
> vp9/encoder/x86/vp9_frame_scale_ssse3.c:93: internal compiler =
error: in simplify_binary_operation_1, at simplify-rtx.c:2563
> Please submit a full bug report,
> with preprocessed source if appropriate.
. . .
> Modified: head/multimedia/libvpx/Makefile
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
> --- head/multimedia/libvpx/Makefile Thu Sep 29 23:35:31 2016 =
(r422955)
> +++ head/multimedia/libvpx/Makefile Fri Sep 30 01:15:10 2016 =
(r422956)
> @@ -3,8 +3,7 @@
. . .
> -USES=3D compiler cpe gmake perl5 shebangfix tar:bzip2
> +USES=3D compiler:c11 cpe gmake perl5 shebangfix =
tar:bzip2
The failure seems to be amd64 specific (sse3 seems to be mentioned) or =
at least unlikely to be involved for something like powerpc64 or =
powerpc. powerpc64 and powerpc buildworld/buildkernel are not done with =
clang (the attempt fails to work) but with gcc 4.2.1 --and a system =
clang may not be present.
[Note: The following is actually based on defects verified in clang++ =
3.8.0. Trunk upstream only got some fixes very recently and I expect =
that older clangs are just as problematical.]=20
clang/clang++ does not even follow the powerpc (non-64) ABI correctly =
(requiring a stack-"red-zone" to protect the stack contents for =
signals). (There are more c++ specific issues for both powerpc64 and =
powerpc, such as exception handling being messed up for both.)
So if/when compiler:c11 binds to a clang (system or port) for powerpc =
(non-64) I expect that powerpc would be broken. (I'm not sure about =
powerpc64 for clang for C11: it might work.)
So despite the later:
> .elif ${ARCH} =3D=3D "powerpc"
> CONFIGURE_ARGS+=3D --target=3Dppc32-linux-gcc
> .elif ${ARCH} =3D=3D "powerpc64"
> CONFIGURE_ARGS+=3D --target=3Dppc64-linux-gcc
For powerpc I expect that use of a gcc port for C11 for may be required.
I do not know if there are other processor families that might have =
issues with the changes or not.
It might have been safer to change only the amd64 build behavior.
=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?BF2EA2BD-3298-4F8C-935F-D4892A87E9F6>