Bug 94769

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.