Bug 25534

It's a known problem and it is caused by a bug in your toolchain, which makes it practically unusable for anything NEON related.

You need to either upgrade your toolchain to a newer version which has a fix for it or apply the following patch to binutils: http://sourceware.org/ml/binutils/2008-03/msg00260.html

So it's not a pixman problem, marking it as 'fixed, not our bug'.

What we could probably try is to improve checks in configure script to detect this problem and either disable NEON or provide some detailed error message. But I do not have a broken toolchain installed myself for testing this stuff. And it's also not clear how common this problem could be (hopefully you are the only one affected by it), so I'm not sure if it deserves a special treatment and extra clutter in pixman build scripts.

This problem is also reproducible with the standard GNU binutils 2.18 (and is fixed in 2.19) as found out by gentoo arm porting team. So it does have more serious practical impact than I initially expected, hence reopening the bug.

Detecting buggy binutils in configure script is problematic because it involves linking with ".so" file to be detected.

So right now the shortest path to reproduce the problem is to take the following test file:
/**********/
int main()
{
    asm volatile ("vmov d1, d0");
    return 0;
}
/**********/

And run

$ gcc -shared -fPIC -mcpu=cortex-a8 -mfpu=neon -mfloat-abi=softfp -Wl,--no-undefined -o test.so test.c
$ gcc -mcpu=cortex-a8 -mfpu=neon -mfloat-abi=softfp -Wl,--no-undefined test.so
test.so: undefined reference to `d0'
collect2: ld returned 1 exit status

An interesting thing here is that "-Wl,--no-undefined" does not help to detect the problem on the first step. While using a different test program we get:
/**********/
extern int d0;
int main()
{
    d0 = 0;
    return 0;
}
/**********/

$ gcc -shared -fPIC -mcpu=cortex-a8 -mfpu=neon -mfloat-abi=softfp -Wl,--no-undefined -o test2.so test2.c
/tmp/ccI95UGn.o: In function `main':
test2.c:(.text+0x34): undefined reference to `d0'
collect2: ld returned 1 exit status

So looks like testing for this bug in one step from configure via something like AC_LINK_IFELSE does not look possible.

Blacklisting binutils 2.18 based on the version number is also not a good solution because patched versions of 2.18 also exist (for example it is included in maemo SDK).

Created attachment 32309 [details] [review]
0001-ARM-Workaround-for-a-NEON-bug-in-assembler-from-bin.patch

The following patch can be used to workaround this problem when using buggy versions of binutils.

Still it is a good idea to upgrade to binutils 2.19 or better for all armv7 users. Just because gcc can sometimes emit "vmov" instructions itself when using autovectorization or intrinsics, it's kind of "russian roulette".

FWIW, I agree with the initial NOTOURBUG. Gentoo needs to provide a working toolchain anyway, either by patching or upgrading.

(In reply to comment #5)
> FWIW, I agree with the initial NOTOURBUG. Gentoo needs to provide a working
> toolchain anyway, either by patching or upgrading.

Yes, they need to. But the problem here is that the source of this build issue is not completely obvious. That's why I would like to keep this bug open for a while. So that anyone getting hit by it would be able to easily find the needed information in freedesktop.org bugzilla (if they would bother to look here of course).

Various linux distributions have started adopting new versions of pixman and this is one of the potential problems they may encounter.

Workaround was applied in pixman 0.18.0 -> resolved.

The reason to finally apply this patch was an attempt to reduce the likelihood of getting weird build failures. If the target system is armv6 or older, the user may not see the strict need to upgrade binutils just to fix NEON bug.