This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: objects_must_conflict_p


> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]