On 13 January 2014 15:51, Kyrill Tkachov <kyrylo.tkac...@arm.com> wrote: > On 13/01/14 13:57, Christophe Lyon wrote: >> >> Hi Kyrill, >> >> Your patch fixes most of the problems I noticed, however, it makes the >> compiler crash on vld1Q_dupp64 when the target is big-endian: >> --with-target= armeb-none-linux-gnueabihf >> --with-cpu=cortex-a9 >> --with-fpu=neon-fp16 >> >> >> >> /aci-gcc-fsf/sources/gcc-fsf/trunk/gcc/testsuite/gcc.target/arm/neon/vld1Q_dupp64.c: >> In function 'test_vld1Q_dupp64': >> >> /aci-gcc-fsf/sources/gcc-fsf/trunk/gcc/testsuite/gcc.target/arm/neon/vld1Q_dupp64.c:16:1: >> error: unrecognizable insn: >> (insn 30 29 16 (set (subreg:DI (reg:V2DI 48 d16 [orig:110 D.14607 ] [110]) >> 0) >> (subreg:DI (reg:V2DI 48 d16 [orig:110 D.14607 ] [110]) 8)) >> >> /aci-gcc-fsf/builds/gcc-fsf-trunk/obj-armeb-none-linux-gnueabihf/gcc3/gcc/include/arm_neon.h:8624 >> -1 >> (nil)) > > > Hmmm... This seems to be a failure in the vld1Q_dupu64 and vld1Q_dups64 > intrinsics as well that were not part of my crypto patches and were likely > ICEing before that in big-endian. The problem seems that we end up splitting > into subregs after register allocation, which causes the ICE. The cuprit is > the neon_vld1_dupv2di. I think it can be modified to directly use the hard > registers after reload instead of generating their low and high parts. >
You are probably right; before your patch it failed in my configuration because it was trying to #include gnu/stubs-soft.h in the hf configuration. Since you fixed that, the other problem appeared. > I'll test a patch... > Thanks
