Created attachment 122649 [details] Full MacPorts build log When building pixman 0.34.0 using MacPorts on a OS X 10.5.8 G5 iMac, I get the following error: /bin/sh ../libtool --tag=CC --mode=compile /usr/bin/gcc-4.2 -DHAVE_CONFIG_H -I. -I.. -I/opt/local/include -faltivec -pipe -Os -arch ppc -Wall -Wdeclaration-after-statement -fno-strict-aliasing -fvisibility=hidden -pipe -Os -arch ppc -Wall -Wdeclaration-after-statement -fno-strict-aliasing -fvisibility=hidden -pthread -MT libpixman_vmx_la-pixman-vmx.lo -MD -MP -MF .deps/libpixman_vmx_la-pixman-vmx.Tpo -c -o libpixman_vmx_la-pixman-vmx.lo `test -f 'pixman-vmx.c' || echo './'`pixman-vmx.c libtool: compile: /usr/bin/gcc-4.2 -DHAVE_CONFIG_H -I. -I.. -I/opt/local/include -faltivec -pipe -Os -arch ppc -Wall -Wdeclaration-after-statement -fno-strict-aliasing -fvisibility=hidden -pipe -Os -arch ppc -Wall -Wdeclaration-after-statement -fno-strict-aliasing -fvisibility=hidden -pthread -MT libpixman_vmx_la-pixman-vmx.lo -MD -MP -MF .deps/libpixman_vmx_la-pixman-vmx.Tpo -c pixman-vmx.c -fno-common -DPIC -o .libs/libpixman_vmx_la-pixman-vmx.o In file included from pixman-vmx.c:34: /usr/lib/gcc/powerpc-apple-darwin9/4.2.1/include/altivec.h:45:2: warning: #warning Ignoring <altivec.h> because "-faltivec" specified pixman-vmx.c: In function âscaled_nearest_scanline_vmx_8888_8888_OVERâ: pixman-vmx.c:2936: error: subscripted value is neither array nor pointer pixman-vmx.c:2937: error: subscripted value is neither array nor pointer pixman-vmx.c:2938: error: subscripted value is neither array nor pointer pixman-vmx.c:2939: error: subscripted value is neither array nor pointer make[2]: *** [libpixman_vmx_la-pixman-vmx.lo] Error 1 make[2]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_libpixman/libpixman/work/pixman-0.34.0/pixman' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_libpixman/libpixman/work/pixman-0.34.0' make: *** [all] Error 2 make: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_libpixman/libpixman/work/pixman-0.34.0' Command failed: cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_libpixman/libpixman/work/pixman-0.34.0" && /usr/bin/make -w all V=1 Exit code: 2 Obviously, I can build by configuring with --disable-vmx, but configure should have never enabled vmx extensions in the first place.
The PowerMac G5 hardware supports Altivec (also known as VMX), which is a 128-bit SIMD instruction set extension that is useful for making graphics and multimedia faster. So probably you actually don't want to get it disabled. However there seems to be some discrepancy between the interpretation of the Altivec related compiler options between your toolchain and the current GCC in powerpc Linux systems. Can you try experimenting with CFLAGS to find out whether you can make the Altivec/VMX code work? Then somebody would need to update configure.ac to make it handle all kind of toolchains gracefully. Have a look at https://cgit.freedesktop.org/pixman/tree/configure.ac?id=pixman-0.34.0#n542
Maybe it's best to rely on auto-vectorisation built into GCC4, i.e., leave out -faltivec. The source code in pixman-vmx.c used the vector type so GCC should know that it can perform auto-vectorisation. I'm no developer, so it's merely a guess. I'll try some experiments on my G4 Mac later, could be on Sunday.
Changing the flags in configure on lines # 13667 #if test -n "`$CC -v 2>&1 | grep version | grep Apple`"; then 13668 # VMX_CFLAGS="-faltivec" 13669 #else 13670 VMX_CFLAGS="-maltivec -mabi=altivec" 13671 #fi brings no other change than additional errors. I presume that the reported lines in pixman/pixman-vmx.c 2936 tmp[0] = tmp1; 2937 tmp[1] = tmp2; 2938 tmp[2] = tmp3; 2939 tmp[3] = tmp4; are not correct, as GCC reports, and might need to be handled like the following line? 2941 vsrc = combine4 ((const uint32_t *) &tmp, pm); Pixman builds on my G4 Mac (PowerPC 7447A) when configured with --disable-vmx. I think the warning can be ignored.
As I don't have OS X myself, I can't help much. We will have to keep this bug open until somebody with the right hardware and the right software skills can take care of it. But it is good to know that the --disable-vmx workaround works. It just costs you quite a bit of lost performance.
I exactly have the same problem while compiling on my PowerMac G5 under FreeBSD 10.2. Thanks for the workaround.
Created attachment 123155 [details] [review] Workaround for gcc, at least <=4.5 for pixman-vmx.c Hi, I stumbled across this trying to build pixman-0.34.0 for NetBSD/macppc 6.0. As far as I've been able to figure out there are two possible ways to deal with this: 1) Apply the patch above, which makes this build with "older" gcc -- NetBSD 6.0 is using gcc 4.5.2 and rejects the construct as shown in this bug report. 2) Use a newer gcc. NetBSD/macppc 7.0 is using gcc 4.8.4 and accepts the code as it stands. Both applying the patch and building with newer gcc does not appear to create any regression wrt. the output from "make check" in pixman. However, I should perhaps also note that with the older compiler, several of the pixman self-tests fail, while with the newer compiler, only one fails, and that test also fails on NetBSD/i386 6.0 (glyph-test), so perhaps there's something wrong with that particular test(?) Regards, - Håvard
(In reply to Håvard Eidnes from comment #6) > Created attachment 123155 [details] [review] [review] > Workaround for gcc, at least <=4.5 for pixman-vmx.c Thanks, confirmed this GCC 4.5 problem. It is also possible to fix this using a smaller patch without the union hack: https://lists.freedesktop.org/archives/pixman/2016-April/004577.html > I stumbled across this trying to build pixman-0.34.0 for > NetBSD/macppc 6.0. As far as I've been able to figure out > there are two possible ways to deal with this: > > 1) Apply the patch above, which makes this build with > "older" gcc -- NetBSD 6.0 is using gcc 4.5.2 and rejects > the construct as shown in this bug report. > > 2) Use a newer gcc. NetBSD/macppc 7.0 is using gcc 4.8.4 > and accepts the code as it stands. > > Both applying the patch and building with newer gcc does > not appear to create any regression wrt. the output from > "make check" in pixman. > > However, I should perhaps also note that with the older > compiler, several of the pixman self-tests fail, while with the > newer compiler, only one fails, and that test also fails on > NetBSD/i386 6.0 (glyph-test), so perhaps there's something > wrong with that particular test(?) Pixman has a 100% test suite pass rate on all platforms. As you have a 'make check' failure on both ppc and i386 architectures in NetBSD, something seems to be really wrong and needs to be debugged. Does NetBSD use a heavily patched GCC?
Created attachment 123184 [details] attachment-6699-0.html > Pixman has a 100% test suite pass rate on all platforms. As you have a 'make check' > failure on both ppc and i386 architectures in NetBSD, something seems to be really > wrong and needs to be debugged. Does NetBSD use a heavily patched GCC? Not that I'm aware of, no. I've now also done the test on NetBSD/amd64 7.0, and the glyph-test fails there as well. The test log shows glyph test failed! (checksum=CA053E2D, expected FA478A79) with the exact same error message for all of them. (macppc 6.0 and 7.0, amd64 7.0, i386 6.1.5). Regards, - Håvard ------------------------------ > You are receiving this mail because: > > - You are on the CC list for the bug. > >
(In reply to Håvard Eidnes from comment #8) > I've now also done the test on NetBSD/amd64 7.0, and the glyph-test fails > there > as well. The test log shows > > glyph test failed! (checksum=CA053E2D, expected FA478A79) > > with the exact same error message for all of them. (macppc 6.0 and 7.0, > amd64 7.0, > i386 6.1.5). All the pixman tests (including the glyph test) successfully pass in Linux on different hardware (x86, ARM, PowerPC, MIPS), both in the 64-bit and the 32-bit mode, both using big and little endian byte order, and also using different compilers. The Windows users of pixman are also maintaining the test suite support in the build scripts, so presumably the tests are supposed to pass there too. Considering the wide variety of different possible configurations, ensuring that all the pixman tests always pass is the only sane way to keep things in a good shape. The 'make check' failure is a pretty serious problem. BTW, I have just tried GCC, Clang and Intel C compilers on my x86-64 system in Linux with pixman 0.34.0 and all of them pass the tests. If you have Clang in NetBSD, maybe you can try it too? Just run 'export CC=clang' before running autogen.sh and/or configure. You can also try to reduce the GCC optimizations level by running 'export CFLAGS="-O1 -g"' before doing a full clean rebuild of pixman (including the autogen.sh step). When you collect all the relevant information, please open a new bugreport about the pixman 'make check' failure in NetBSD. Thanks!
(In reply to Siarhei Siamashka from comment #7) > (In reply to Håvard Eidnes from comment #6) > > Created attachment 123155 [details] [review] [review] [review] > > Workaround for gcc, at least <=4.5 for pixman-vmx.c > > Thanks, confirmed this GCC 4.5 problem. It is also possible to fix this > using a smaller patch without the union hack: > https://lists.freedesktop.org/archives/pixman/2016-April/004577.html > Strangely this simple patch really works on my G4 (PowerPC 7447A) Mac with Mac OS X 10.5.8, Leopard! And also all tests are passed. I use an Apple patched GCC 4.2.1, the default for this OS version.
Created attachment 123196 [details] attachment-9001-0.html > All the pixman tests (including the glyph test) successfully pass in Linux on different hardware > (x86, ARM, PowerPC, MIPS), both in the 64-bit and the 32-bit mode, both using big and little > endian byte order, and also using different compilers. I've done some further testing, but so far only on NetBSD 7.0 amd64, which uses gcc 4.8.4. CFLAGS="-O1 -g" gives the exact same failure for glyph-test. Building pixman with clang (3.6) *also* gives the exact same failure for glyph-test. I guess I should do as you suggested and go ahead and open a new bug report for this problem. Regards, - Håvard
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pixman/pixman/issues/4.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.