------- Comment #35 from rguenther at suse dot de 2007-06-05 16:30 -------
Subject: Re: [4.2 regression] miscompilation of sigc++-2.0
based code with -fstrict-aliasing
On Tue, 5 Jun 2007, dberlin at dberlin dot org wrote:
> Subject: Re: [4.2 regression] miscompilation of sigc++-2.0 based code with
> -fstrict-aliasing
>
> On 5 Jun 2007 09:27:34 -0000, rguenth at gcc dot gnu dot org
> <[EMAIL PROTECTED]> wrote:
> >
> >
> > ------- Comment #30 from rguenth at gcc dot gnu dot org 2007-06-05 09:27
> > -------
> > See this testcase (reduced from spec2k6 dealII by Micha):
> >
> > struct I {
> > int ix;
> > struct II {
> > int j,i;
> > void *ptr;
> > } ii;
> > };// inner;
> > struct O : public I {
> > // int x;
> > int y;
> > };
> >
> > static int geti (struct O *o)
> > {
> > return o->ii.i;
> > }
> > extern void init(struct O*);
> > extern void deinit(struct O*);
> > extern int getcond(void);
> > struct O::I *getinner (struct O*);
> > int reset (int cond)
> > {
> >
> > struct O cell;
> > struct O *o;
> > struct I::II *in;
> > int *pi;
> > o = &cell;
> > init (o);
> > in = &o->ii;
> > while (getcond()) {
> > if (o->y)
> > cell.ii.i = -2;
> > if (!getcond()) {
> > in->i = -1;
> > in->j = o->ii.i;
> > break;
> > }
> > }
> > pi = &in->j;
> > pi++;
> > deinit(&cell);
> > return *pi;
> > }
> >
> > and note how we compute the wrong points-to solution for in:
> >
> > o_3 = { cell cell.y cell.ptr cell.i cell.j }
> > in_4 = { cell.y cell.ptr cell.j }
> >
>
> > we are missing cell.i in the points-to set. This is because with looking
> > simply for vars with oldoffset + offset is appearantly not enough here.
> >
> > cell + 64 -> cell.j
> > cell.y + 64 -> off structure
> > cell.ptr + 64 -> cell.y
> > cell.i + 64 -> cell.ptr (actually in the middle of it)
> > cell.j + 64 -> cell.ptr
> >
> > so, there is nothing in the structure that, if added 64, will point to
> > cell.i. But of course we are taking the address of the substructure and
> > so we are indeed pointing to cell.i.
> We are pointing to cell, and using that to access cell.i
> Not quite the same thing.
> But I guess in our world we have to make them the same thing.
>
> > So a different solution would be to add _each_ var starting with the
> > first one + offset.
>
> You don't want to play in solution_set_add, which is common to a bunch of
> code.
>
> The only cases where the above problem comes into play is in offseted
> copy constraints, line 1520 (IE the last part of
> do_complex_constraint).
>
> In actuality, this is a bug in constraint building.
>
> When we generate the constraints for in = &o->ii, we should be adding
> an offsetted copy constraint for each offset of type *o.
>
> This will fix the problem.
How so? The solution_set_add method is still wrong.
> > I did with the patch (it needs some fixing still, as pruning at the
> > end is bogus in it as vars may be still reached from others).
> >
>
> You can never get back to the parent structure from a pointer to the
> substructure.
> I asked this explicitly and was told it was undefined behavior.
Yep, this is what I convinced myself aswell.
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30252
