------- Comment #2 from rguenth at gcc dot gnu dot org 2007-12-14 12:46 -------
Created an attachment (id=14753)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14753&action=view)
patch
The problem is that the operand scanner is triggered on a fake store inserted
by PRE insert_fake_stores() as if a new stmt_ann is generated, the stmt is
marked modified and bsi_insert_after() will update the stmts operands in this
case.
For some reason this figures new, unrenamed virtual operands:
# VUSE <SFT.2_69, SFT.3_70, SFT.4, SFT.5, SFT.6, SMT.15_71> { SFT.2 SFT.3 SFT.4
SFT.5 SFT.6 SMT.15 }
storetmp.19_3 = *dest_22
which triggers this ICE.
So, I believe we should not re-build operands for this stmt, as we carefuly
use create_ssa_artificial_load_stmt () to do so. In fact, this will make
the following part of that function non-effective:
/* All uses in this fake stmt must not be in the immediate use lists. */
FOR_EACH_SSA_USE_OPERAND (use_p, new_stmt, iter, SSA_OP_ALL_USES)
delink_imm_use (use_p);
BUT - this patch causes a whole lot of new problems because suddenly VN_TOP
starts to leak into virtual operands which causes bootstrap to fail on
x86_64 building bid_decimal_globals.c for 32bit.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34462
