While this started with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167390,
it looks just as it uncovered a latent IRA bug.
My guess is that the differences are related to ira-emit.c (change_loop) creating
some new pseudos, whose live ranges then don't ignore debug insns (normally debug insns would be changed or reset to avoid different lr ranges caused by debug insns, but probably as this happens still within IRA it won't be adjusted).

Problems start when the combiner leaves in a trivially dead insn by substing it later on in some subsequent insn.  Nothing until IRA calls delete_trivially_dead_insns, and when IRA calls it, it removes that insn, which effectively shortens the lifetime of one of the pseudos.  Unfortunately that psuedo is set multiple times (probably -funroll-loops is the reason), so delete_trivially_dead_insns isn't trying to reset or change related debug insns, it doesn't have enough infrastructure to do so.  Normally DF would then reset them, but DF isn't recomputed until IRA finishes.

--- gcc/ira.c.jj	2011-02-21 15:37:42.000000000 +0100
+++ gcc/ira.c	2011-03-07 12:33:59.000000000 +0100
@@ -3232,7 +3232,8 @@ ira (FILE *f)
     check_allocation ();
 #endif
 
-  delete_trivially_dead_insns (get_insns (), max_reg_num ());
+  if (delete_trivially_dead_insns (get_insns (), max_reg_num ()))
+    df_analyze ();
 
   init_reg_equiv_memory_loc ();
 
indeed fixes this testcase, haven't tried to bootstrap/regtest it nor have any idea whether some IRA bookkeeping will need to be updated in that case.

Author: jakub
Date: Tue Mar  8 15:51:12 2011
New Revision: 170780

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170780
Log:
	PR debug/47881
	* ira.c (ira): Call df_analyze again if delete_trivially_dead_insns
	removed anything.

	* gcc.dg/pr47881.c: New test.

Added:
    trunk/gcc/testsuite/gcc.dg/pr47881.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/cp/ChangeLog
    trunk/gcc/ira.c
    trunk/gcc/testsuite/ChangeLog

Fixed.