<div dir="ltr">Thank you very much Siarhei, I am still building something huge and had no way to double check but at least I can confirm the gcc is 4.9.2.<div> </div><div>I will try to --disable-arm-iwmmxt when it shows arm6l as uname -m and let you know if that fixed.</div><div> </div><div>Do you think it should be enabled in the future or it's needed to let pixman properly work?</div><div> </div><div>Cheers</div></div><div class="gmail_extra"> <div class="gmail_quote">On Wed, Dec 3, 2014 at 12:50 PM, Siarhei Siamashka <<a href="mailto:siarhei.siamashka@gmail.com" target="_blank">siarhei.siamashka@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, 2 Dec 2014 07:53:38 +0200 <div><div class="h5">Siarhei Siamashka <<a href="mailto:siarhei.siamashka@gmail.com">siarhei.siamashka@gmail.com</a>> wrote: > On Mon, 1 Dec 2014 23:46:43 +0000 > Andrea Giammarchi <<a href="mailto:andrea.giammarchi@gmail.com">andrea.giammarchi@gmail.com</a>> wrote: > > > On Mon, Dec 1, 2014 at 8:48 PM, Siarhei Siamashka < > > <a href="mailto:siarhei.siamashka@gmail.com">siarhei.siamashka@gmail.com</a>> wrote: > > > > > On Mon, 1 Dec 2014 10:12:05 +0000 > > > Andrea Giammarchi <<a href="mailto:andrea.giammarchi@gmail.com">andrea.giammarchi@gmail.com</a>> wrote: > > > > > > > Hello there, > > > > I wonder if anyone else ever tried to build directly on the R-Pi > > > without > > > > reaching the (in)famous "Max. number of generated reload insns per insn > > > is > > > > achieved (90)" point. > > > > > > > > I can build just fine with same dependencies and OS ( Arch Linux ) > > > > everywhere else but in the ARM v6 hf I keep having troubles. > > > > > > > > I know this error is usually a GCC one and I am not sure I should even > > > > bother here, but from mesa to cairo, including varius xorg, pixman is the > > > > only one that never manages to complete its build. > > > > > > > > Will try eventually a stable branch instead of latest from master and let > > > > you know. > > > > > > > > Thanks for any outcome ( if any, thanks for pixman otherwise anyway ) > > > > > > I have just tested building the current pixman master branch on an > > > ARM board with GCC 4.8.3. It compiled fine and passed the 'make check' > > > tests. The native and crosscompiled builds of pixman should generally > > > work fine on ARM. > > > > > > First of all, you can probably try to ensure that the compiler is not > > > running out of memory and maybe enable a large swap. Raspberry Pi > > > does not have much RAM. > > > > > > Also pixman uses deep inlining and somewhat complicated code constructs > > > in some places. And it has triggered a number of compiler bugs in the > > > past. Especially with the unstable/experimental dot-zero versions of > > > compilers. In such cases, we typically report problems to GCC/Clang > > > developers and the problems tend to be addressed relatively fast. > > > Tools like C-Reduce can be used for finding a smaller testcase when > > > debugging internal compiler error problems: > > > <a href="http://embed.cs.utah.edu/creduce/" target="_blank">http://embed.cs.utah.edu/creduce/</a> > > > > Thanks Siarhei, > > I have 4GB /swap that made me build even QtWebEngine ( blink + v8 ... > > basically 2/3rd of Chromium ) so I'd say that both linker ( ld.gold by > > default ) and swap should be fine but I actually don't have right now exact > > version of the GCC used in Arch Linux but usually it's the latest one. > > > > I also can build pixman in ARM v7 hf boards but I could not manage yet in > > the R-Pi model B > > > > I will try to see if I can use C-Reduce so thanks for your hint but if you > > have anything else in mind that could cause pixman only to fail please > > share ( at some point I thought it was about NEON which is not supported in > > the PI ... I haven't disabled that during build time, might try doing that > > and fingers crossed! ) > > BTW, if your Raspberry Pi happens to be overclocked, then it might be a > potential source of reliability problems too. > > Running "gcc -v" should provide information about the GCC version and > its configuration. > > NEON code is unlikely to cause problems because most of it is > implemented in assembly language, so the C compiler is not used > for it and can't fail. </div></div>Actually I have managed to reproduce something similar with the following toolchain generated by the gentoo crossdev tool: $ arm-test-linux-gnueabi-gcc -v Using built-in specs. COLLECT_GCC=/usr/x86_64-pc-linux-gnu/arm-test-linux-gnueabi/gcc-bin/4.9.1/arm-test-linux-gnueabi-gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/arm-test-linux-gnueabi/4.9.1/lto-wrapper Target: arm-test-linux-gnueabi Configured with: /var/tmp/portage/cross-arm-test-linux-gnueabi/gcc-4.9.1/work/gcc-4.9.1/configure --host=x86_64-pc-linux-gnu --target=arm-test-linux-gnueabi --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/arm-test-linux-gnueabi/gcc-bin/4.9.1 --includedir=/usr/lib/gcc/arm-test-linux-gnueabi/4.9.1/include --datadir=/usr/share/gcc-data/arm-test-linux-gnueabi/4.9.1 --mandir=/usr/share/gcc-data/arm-test-linux-gnueabi/4.9.1/man --infodir=/usr/share/gcc-data/arm-test-linux-gnueabi/4.9.1/info --with-gxx-include-dir=/usr/lib/gcc/arm-test-linux-gnueabi/4.9.1/include/g++-v4 --with-python-dir=/share/gcc-data/arm-test-linux-gnueabi/4.9.1/python --enable-languages=c,c++ --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --disable-nls --enable-checking=release --with-bugurl=<a href="https://bugs.gentoo.org/" target="_blank">https://bugs.gentoo.org/</a> --with-pkgversion='Gentoo 4.9.1 p1.0, pie-0.6.0' --enable-libstdcxx-time --enable-poison-system-directories --with-sysroot=/usr/arm-test-linux-gnueabi --disable-bootstrap --enable-__cxa_atexit --enable-clocale=gnu --disable-multilib --disable-altivec --disable-fixed-point --disable-libgcj --disable-libgomp --disable-libmudflap --disable-libssp --disable-libquadmath --enable-lto --without-cloog --enable-libsanitizer --with-cpu=cortex-a8 --with-float=hard Thread model: posix gcc version 4.9.1 (Gentoo 4.9.1 p1.0, pie-0.6.0) It fails to compile the pixman mmx (arm-iwmmxt) code: CC libpixman_iwmmxt_la-pixman-mmx.lo pixman-mmx.c: In function 'mmx_fetch_x8r8g8b8': pixman-mmx.c:3911:1: internal compiler error: Max. number of generated reload insns per insn is achieved (90) } ^ Please submit a full bug report, with preprocessed source if appropriate. See <<a href="https://bugs.gentoo.org/" target="_blank">https://bugs.gentoo.org/</a>> for instructions. Makefile:1111: recipe for target 'libpixman_iwmmxt_la-pixman-mmx.lo' failed If that's what you get, then the workaround is simple. You can run the configure script with "--disable-arm-iwmmxt" option. <div class="HOEnZb"><div class="h5"> -- Best regards, Siarhei Siamashka </div></div></blockquote></div> </div>