/tmp/gcc41/libexec/gcc/i686-pc-linux-gnu/4.1.0/cc1 -quiet -v test.c -dumpbase test.c -mtune=pentiumpro -auxbase-strip test.o -O -version -fmove-loop-invariants -fgcse -o test.o GNU C version 4.1.0 20051007 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 4.1.0 20051007 (experimental). GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129306 Compiler executable checksum: a278381769db4d67bad1ec630ceb45dd test.c: In function 'foo': test.c:14: error: unrecognizable insn: (insn 21 16 39 0 (set (reg:DF 64) (const_double:DF -858993460 [0xcccccccc] 2.00000000000000011102230246251565404236316680908e-1 [0x0.ccccccccccccdp-2])) -1 (nil) (nil)) test.c:14: internal compiler error: in extract_insn, at recog.c:2084 Configured with: ../gcc/configure --prefix=/tmp/gcc41 --enable-languages=c --disable-nls --enable-checking=assert,rtlflag,misc ======================================================== void dset (double d1, double d2); void foo () { int i; double m, d = 0.2; dset (m,d); for (i=1; i<=3; i++) { dset (m,d); } } ======================================================== d needs to have the same value in both calls to dset for this ICE to occur.
Confirmed, a regression from 4.0.0. I think this is a target bug as you had: (set (mem:DF (plus:SI (reg/f:SI 7 sp) (const_int 8 [0x8])) [0 S8 A32]) (const_double:DF -858993460 [0xcccccccc] 2.00000000000000011102230246251565404236316680908e-1 [0x0.ccccccccccccdp-2])) before loop-invariant but after, you have: (insn 21 16 17 0 (set (reg:DF 64) + (const_double:DF -858993460 [0xcccccccc] 2.00000000000000011102230246251565404236316680908e-1 [0x0.ccccccccccccdp-2])) -1 (nil) + (nil)) Unless -fmove-loop-invariants is not calling emit_move_insn which might be the issue.
A regression hunt using an i686-linux cross compiler identified this patch from hagog@gcc.gnu.org: http://gcc.gnu.org/ml/gcc-cvs/2005-06/msg00015.html
The patch identified in comment #2 has nothing to do with this problem. Pinski is right in comment #1, loop-invariant.c does not verify that the insns it moves/inserts are valid. Using emit_move_insn is just one thing it should do. Another thing is verifying that a reg-reg move exists for expressions moved out of a loop into a register before the loop. There are a few other issues I found some time ago, but I don't recall the details.
Does the analysis in Comment #3 imply that -fmove-loop-invariants is really not ready for use by the general public?
This is ineed move-loop-invariants bug. It assumes that destination of memory store can be changed to register without validating that is not the case on i386 - you can write arbitrary floating point value to memory, but you can load only 0 and 1 to register by single direct move.
Oh well, I'll try and fix this...
Created attachment 10173 [details] Patch to fix the ice This patch fixes the failure for me, but...
> This patch fixes the failure for me, but... ... we actually gain nothing here. From .loop2_done, we have following sequence, where mem->reg load is pushed out of the loop: (insn 21 16 39 0 (set (reg:DF 64) (mem/u/c/i:DF (symbol_ref/u:SI ("*.LC0") [flags 0x2]) [0 S8 A64])) -1 (nil) (nil)) ;; End of basic block 0, registers live: (nil) (note 39 21 17 NOTE_INSN_LOOP_BEG) ;; Start of basic block 1, registers live: (nil) (code_label 17 39 18 1 2 "" [1 uses]) (note 18 17 47 1 [bb 1] NOTE_INSN_BASIC_BLOCK) (insn 47 18 22 1 (set (mem:DF (plus:SI (reg/f:SI 7 sp) (const_int 8 [0x8])) [0 S8 A32]) (reg:DF 64)) -1 (nil) (nil)) However, in .postreload, the insn 21 (now insn 53) is moved back _into_ the loop (why?): (note 21 16 39 0 NOTE_INSN_DELETED) ;; End of basic block 0, registers live: 6 [bp] 7 [sp] 16 [argp] 20 [frame] 60 64 (note 39 21 17 NOTE_INSN_LOOP_BEG) ;; Start of basic block 1, registers live: 6 [bp] 7 [sp] 59 60 64 (code_label 17 39 18 1 2 "" [1 uses]) (note 18 17 53 1 [bb 1] NOTE_INSN_BASIC_BLOCK) (insn 53 18 47 1 (set (reg:DF 8 st) (mem/u/c/i:DF (symbol_ref/u:SI ("*.LC0") [flags 0x2]) [0 S8 A64])) 63 {*movdf_noin teger} (nil) (nil)) (insn 47 53 54 1 (set (mem:DF (plus:SI (reg/f:SI 7 sp) (const_int 8 [0x8])) [0 S8 A32]) (reg:DF 8 st)) 63 {*movdf_nointeger} (nil) (nil)) Proposed patch thus only fixes the damage. Otherwise, all this register moving/copying doesn't gain anything, as reload fixes something on its own. Also, REG_EQUAL notes are lost (before and after the patch). This results in following asm: ... movl $-1717986918, 8(%esp) movl $1070176665, 12(%esp) fldl -16(%ebp) fstpl (%esp) call dset movl $1, %ebx .L2: fldl .LC0 <<< reload moves this insn back into the loop fstpl 8(%esp) fldl -16(%ebp) fstpl (%esp) call dset incl %ebx cmpl $4, %ebx jne .L2 addl $36, %esp ...
Bah... set_unique_reg_note is needed: /* If new move insn is invalid (i.e. move of const_double to 387 stack register), force constant into memory. */ if (recog_memoized (inv->insn) == -1) { rtx src = SET_SRC (set); if (GET_CODE (src) == CONST_DOUBLE) { SET_SRC (set) = validize_mem (force_const_mem (mode, src)); set_unique_reg_note (inv->insn, REG_EQUAL, src); } } to produce: movl $1, %ebx .L2: movl $-1717986918, 8(%esp) movl $1070176665, 12(%esp) fldl -16(%ebp) fstpl (%esp) call dset addl $1, %ebx cmpl $4, %ebx jne .L2
The patch from comment #7 is wrong. The proper fix is already on the killloop-branch. You could try my patch for PR 24408, which should depend on this one.
Subject: Bug 24265 Author: steven Date: Fri Nov 11 19:34:39 2005 New Revision: 106795 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106795 Log: PR 24265 * loop-invariant.c (may_assign_reg_p): Make sure a hard register can be assigned to. (find_invariant_insn): Do the cheapest check, may_assign_reg_p, before check_maybe_invariant. (move_invariant_reg): Use gen_move_insn instead of replacing SET_DEST with the temporary for the invariant. (move_loop_invariants): If checking is enabled, do internal consistency checks after completing the pass. Modified: trunk/gcc/ChangeLog trunk/gcc/loop-invariant.c
Fixed on mainline. The bug is also on the GCC 4.0 branch, but I am not going to backport the patch.