This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/34334] [4.3 Regression] ICE in vuses_compare, at tree-vn.c:118
- From: "rguenth at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 4 Dec 2007 14:03:39 -0000
- Subject: [Bug tree-optimization/34334] [4.3 Regression] ICE in vuses_compare, at tree-vn.c:118
- References: <bug-34334-10053@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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