This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug rtl-optimization/25654] [4.0/4.1/4.2 Regression] RTL alias analysis unprepared to handle stack slot sharing
- From: "steven at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 13 Jan 2006 21:30:51 -0000
- Subject: [Bug rtl-optimization/25654] [4.0/4.1/4.2 Regression] RTL alias analysis unprepared to handle stack slot sharing
- References: <bug-25654-280@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #2 from steven at gcc dot gnu dot org 2006-01-13 21:30 -------
I wonder if this problem can also be triggered without using two variables of
the same union type. There is code in add_alias_set_conflicts to avoid the
situation we're running into:
static void
add_alias_set_conflicts (void)
{
size_t i, j, n = stack_vars_num;
for (i = 0; i < n; ++i)
{
tree type_i = TREE_TYPE (stack_vars[i].decl);
bool aggr_i = AGGREGATE_TYPE_P (type_i);
for (j = 0; j < i; ++j)
{
tree type_j = TREE_TYPE (stack_vars[j].decl);
bool aggr_j = AGGREGATE_TYPE_P (type_j);
if (aggr_i != aggr_j || !objects_must_conflict_p (type_i, type_j))
add_stack_var_conflict (i, j);
}
}
}
but if you have two stack variables of the same union type, aggr_i == aggr_j,
and type_i == type_j so objects_must_conflict_p returns true. So perhaps if
type_i and type_j are unions and type_i == type_j, we should also do an
add_stack_var_conflict...?
--
steven at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hubicka at gcc dot gnu dot
| |org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25654