------- Comment #3 from rguenth at gcc dot gnu dot org  2007-12-04 14:03 -------
The issue is that the loaded_syms bitmap doesn't agree with the VUSEs:

(gdb) call debug_generic_expr (stmt)
# VUSE <SMT.33_40> { SMT.32 SMT.33 }
storetmp.46_60 = *dest_19

as in create_ssa_artificial_load_stmt we make sure to kill build_vuses, but
not to clear the build_loads bitmap.  With that fixed we generate

# VUSE <SMT.33_40> { SMT.33 }
storetmp.46_60 = *dest_19

which looks better, but later still ICEs, because the operand scanner
re-inserts the load of SMT.32.

So one could argue that for the original statement where we copy the
virtual operands from

# SMT.33_40 = VDEF <SMT.33_55> { SMT.33 }
*dest_19 = 0B

that this is missing a VDEF of SMT.32 (the alias sets of both SMT.32 and
*dest_19 are 3).

Note also that even during the first may_alias pass(!) we do not have
flow-sensitive information for dest_19:

NOTE: no flow-sensitive alias info for dest_19 in *dest_19 = 0B;

that is, we only use a fallback SMT here.  And the failure mode is exactly
as I have predicted - we add the aliases of SMT.32 (SMT.33), but not SMT.32
itself!


Mine.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
                   |dot org                     |org
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2007-12-04 14:03:39
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34334

Reply via email to