% cat test.c unsigned long f (void) { return __builtin_alpha_inswl(0, 3); } % gcc -c test.c test.c: In function `f': test.c:3: error: unrecognizable insn: (insn 8 19 9 0 (set (reg:DI 69 [ T.0 ]) (ashift:DI (zero_extend:DI (const_int 0 [0x0])) (ashift:DI (const_int 3 [0x3]) (const_int 3 [0x3])))) -1 (nil) (nil)) test.c:3: internal compiler error: in extract_insn, at recog.c:2068 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. This is not a regression, since the builtins are new in 3.4. The problem is the illegal RTL of a zero extension of a constant. This is exactly the same problem as in PR 10083. I'm not sure whether fixing it the same way is a good idea since it would create lots of patterns, maybe somebody has a better idea? It would be nice if this could be fixed in a way that would completely fold the constant, since this comes from code byte-swapping a constant magic value.
Maybe the suggestion of a target dependent version of fold_builtin? I think someone suggested this when fixinig the altivec bug.
Actually, it seems a simple hack like diff -u -p -r1.194.2.21 alpha.md --- alpha.md 26 Mar 2004 16:23:02 -0000 1.194.2.21 +++ alpha.md 17 Apr 2004 18:03:40 -0000 @@ -7201,7 +7201,7 @@ (define_expand "builtin_inswl" [(match_operand:DI 0 "register_operand" "") - (match_operand:DI 1 "reg_or_0_operand" "") + (match_operand:DI 1 "register_operand" "") (match_operand:DI 2 "reg_or_8bit_operand" "")] "" { will already suffice, since other constants work. It'll even get folded then.
Testing a patch.
Fixed.