Hello, this commit introduces a regression on mipsel, seen through testsuite failures: commit c78e986085b3993f1b4355151820228c53d54cad Author: Matt Turner <mattst88@gmail.com> Date: Fri Feb 24 12:43:43 2012 -0500 mmx: compile on MIPS for Loongson MMI optimizations Test suite failures: -------------------- PASS: region-translate-test /bin/bash: line 5: 6459 Illegal instruction ${dir}$tst FAIL: fetch-test PASS: oob-test PASS: trap-crasher PASS: alpha-loop /bin/bash: line 5: 6545 Illegal instruction ${dir}$tst FAIL: scaling-crash-test PASS: scaling-helpers-test /bin/bash: line 5: 6607 Illegal instruction ${dir}$tst FAIL: gradient-crash-test region_contains test passed (checksum=D2BF8C73) PASS: region-contains-test /bin/bash: line 5: 6700 Illegal instruction ${dir}$tst FAIL: alphamap /bin/bash: line 5: 6723 Illegal instruction ${dir}$tst FAIL: stress-test /bin/bash: line 5: 7114 Illegal instruction ${dir}$tst FAIL: composite-traps-test /bin/bash: line 5: 7137 Illegal instruction ${dir}$tst FAIL: blitters-test /bin/bash: line 5: 7160 Illegal instruction ${dir}$tst FAIL: scaling-test /bin/bash: line 5: 7183 Illegal instruction ${dir}$tst FAIL: affine-test /bin/bash: line 5: 7206 Illegal instruction ${dir}$tst FAIL: composite ============================================= 10 of 19 tests failed Please report to pixman@lists.freedesktop.org ============================================= Full build log: https://buildd.debian.org/status/fetch.php?pkg=pixman&arch=mipsel&ver=0.26.0-2&stamp=1339729075 Mraw, KiBi.
What kind CPU are you running this on? Might be a problem with the CPU detection. Then again, there's no check for loongson2e, so that might be the problem, but without more info..
Need more than cpuinfo? Here it is in the meanwhile: kibi@eder:~$ cat /proc/cpuinfo system type : lemote-fuloong-2e-box processor : 0 cpu model : ICT Loongson-2 V0.2 FPU V0.1 BogoMIPS : 441.34 wait instruction : no microsecond timers : yes tlb_entries : 64 extra interrupt vector : no hardware watchpoint : yes, count: 0, address/irw mask: [] ASEs implemented : shadow register sets : 1 kscratch registers : 0 core : 0 VCED exceptions : not available VCEI exceptions : not available
(In reply to comment #2) > kibi@eder:~$ cat /proc/cpuinfo > system type : lemote-fuloong-2e-box Ahh, right. A 2e system. Since there's no way to simply turn on loongson vector instructions, I just have pixman compile pixman-mmx.c with -march=loongson2f. You should be able to override this by setting LS_CFLAGS to -march=loongson2e. It would be good to at least confirm that using -march=loongson2e fixes the problem. From there, I'm not really sure what the best solution is, since loongson2e/2f are apparently mutually incompatible.
Passing LS_CFLAGS="-march=loongson2e" fixes it. I guess the best way to go from here would be a triple build (no -march, -march=loongson2e, and -march=loongson2f), and pick the right bits at run time. In the meanwhile, I'll probably just pass LS_CFLAGS=" " for the time being to get it to build again.
Created attachment 65249 [details] [review] triple build (In reply to comment #4) > I guess the best way to go from here would be a triple build (no -march, > -march=loongson2e, and -march=loongson2f), and pick the right bits at run time. I started playing with this today, but it seems that there's no fucking way to tell whether 'system type : lemote-fuloong' is a 2e or 2f. So screw people who have those kernels. The attached, untested, patch builds pixman-mmx.c for 2e, 2f, and if gcc-4.6 -- 3a, and checks cpuinfo at runtime to select which to use. My yeeloong is packed in a box somewhere so I won't be able to test anytime soon but I can make changes if you can test.
Created attachment 72605 [details] [review] patch Cyril, please test the attached patch. (I cannot test it, as my system is compiled with -march=loongson2f and therefore I cannot even link code compiled with -march=loongson2e with my C library. Thanks binutils.)
New patch on the list.
(In reply to comment #7) > New patch on the list. Presumably this one: http://lists.freedesktop.org/archives/pixman/2012-September/002249.html What is the current status of this problem?
(In reply to comment #8) > (In reply to comment #7) > > New patch on the list. > > Presumably this one: > http://lists.freedesktop.org/archives/pixman/2012-September/002249.html > > What is the current status of this problem? My memory is that Søren didn't want hacks in pixman to make different object files link together (e.g., loongson2e and loongson2f). I also never figured out how to do it. I think I had a patch that built the MMX code into .so's for each architecture and dynamically linked them, but that felt really hacky and meant I had to export some internal pixman symbols.
There is also the HWCAPS based multiarch mechanism, which allows installing multiple variants of the same library in different directories. So that the ld.so can pick the best variant automatically: https://wiki.debian.org/Multiarch/LibraryPathOverview ("Dynamic libraries" section) But I'm not sure if MIPS actually supports this for differentiating the incompatible variants of loongson. In any case, this seems to be a toolchain and/or platform problem. And it probably needs to be communicated to gcc developers.
-- 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/3.
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.