This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: objects_must_conflict_p
- From: Eric Botcazou <ebotcazou at libertysurf dot fr>
- To: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- Cc: gcc at gcc dot gnu dot org
- Date: Sat, 5 Jul 2003 15:20:11 +0200
- Subject: Re: objects_must_conflict_p
- References: <10307051208.AA18702@vlsi1.ultra.nyu.edu>
> So try again to explain what it's doing wrong, since my comment makes no
> sense when I go back and look at it.
Here's the context (from a C++ testcase):
struct iterator1 {
inline iterator1 (matrix *m):
dead1 (m), i (0) {}
void *dead1;
int i;
int dead2;
};
struct a_iterator1 {
a_iterator1 (adaptor &a, struct iterator1 &it1):
a (&a), dead1 (it1) {}
adaptor *a;
struct iterator1 dead1;
}
A temporary 'struct iterator1' object is created: allocated on the stack and
constructed, so 'dead1' is assigned. It is used for initializing another
object and then dies.
Then a (non-temporary) 'struct a_iterator1' object is created: allocated on
the stack and constructed, so 'adaptor' is assigned. 'struct iterator1' and
'struct a_iterator1' conflicts according to objects_must_conflict_p, because
the latter is a supertype of the former. So the stack slot of the 'struct
iterator1' object is reused for the 'struct a_iterator1' object. Hence
'dead1' from the first object and 'adaptor' from the second object gets the
same address.
Now, for some reason, 'dead1' is never read, so we end up with two
consecutive assignments to the same address that are not aliasing and the
2nd scheduling pass swaps them.
The alias sets of the structures have two strict subsets in common, those of
'int' and of 'void *'.
--
Eric Botcazou