http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45805
--- Comment #5 from belagod at gcc dot gnu.org 2010-09-28 16:25:37 UTC --- (In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > > > (In reply to comment #1) > > > > Created attachment 21897 [details] [details] [details] [details] > > > > Fix register specifier in instruction template for vmovl. > > > > > > I tried similar patch locally before submitting the bug (changed only > > > vmovl > > > pattern) > > > but I got an ICE which is again same I am getting with this patch too > > > > > > $ arm-none-linux-gnueabi-gcc-4.6.0 -mfloat-abi=softfp -mfpu=neon a.c -O3 > > > a.c: In function ‘try_8x8basis_c’: > > > a.c:14:1: internal compiler error: output_operand: invalid operand for > > > code 'P' > > > > That's strange. I'm not able to reproduce the ICE on my side with or without > > -mvectorize-with-neon-quad with this patch. I don't know if configuring to > > build for cortex-a9 has anything to do with this because that's what is on > > my > > side and you don't seem to have it configured to build for a cpu with NEON. > > Does the ICE happen if you specify -mcpu=cortex-a9 on the command-line? > > Also, > > are you using trunk's HEAD? > > with -mcpu=cortex-a9 it works without it gets the ICE. you can try > -mcpu=cortex-a8 it should ICE. Ah, now I can reproduce it. The rtl-trace shows that memory operands were being matched for the neon_unpack<US>_<mode> pattern inpsite of the 'register_operand' predicate. The constraint here needs a "w" which makes the ICE go away by matching register operands only and your example to compile fine. I've attached another patch.
