[Bug c++/30252] [4.2 regression] miscompilation of sigc++-2.0 based code with -fstrict-aliasing

["dberlin at dberlin dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #38 from dberlin at gcc dot gnu dot org  2007-06-05 19:07 -------
Subject: Re:  [4.2 regression] miscompilation of sigc++-2.0 based code with
-fstrict-aliasing

On 5 Jun 2007 18:24:54 -0000, matz at gcc dot gnu dot org
<gcc-bugzilla@gcc.gnu.org> wrote:
>
>
> ------- Comment #37 from matz at gcc dot gnu dot org  2007-06-05 18:24 -------
> > We are pointing to cell, and using that to access cell.i
>
> No.  We are pointing to cell.ii, and use that pointer to access cell.ii.i
> (via in->i).  Hence of course the points-to set of 'in' needs to include
> cell.in.i (or cell.i, as the point-to debug dump likes to call it).  At least
> how the points-to solver is used.
>  Theoretically it would of course be more
> sensible to only note that 'in' can point to 'cell.ii', and make the user
> of that information recognize that this actually is a structure, and hence
> over that pointer you can access all members of it.  But that's not
> how the info is used, so we have to include cell.ii.i in the points to set
> (which in our case rather is a can-access set).

Or we have to fix how it is used to handle these issues there.  :)

Honestly, doing the second would result in much much saner points-to
constraint generation and solving.

Probably better results, too.
Now that we calculate the set of loaded/stored symbols on a
per-statement basis, it may be quite easy to do.

>
> Now, regarding where to fix it properly: if you say that solution_set_add()
> is not the right place (and I don't buy that yet, because something is wrong
> with it no matter what, e.g. looking for subfields starting from the things
> in the pt set, which themself might be subfields feels wrong)
You keep thinking the solver knows anything about types or structures
or fields or programming languages or fields.
It doesn't.
The only thing it knows is that constraint variable + 5 is some other
constraint variable.

Clear your mind of any relation to the original program variables.
The variables the solver is talking about need to be mapped back to
original program variables.  They are simply a unique set of
variables, some of which may be accessed by offseting something else.

All relations of the original variables need to be expressed to the
solver in constraints. The solver does not, and should not, know
anything about programming languages and their type systems :)

> not use pointer arithmetic (or at least '+' constraints) to represent pointing
> to substructures.  And I'm not sure that's easily doable.  Because the insn
> we see is not "in = &cell.in", but "in = &o->in", and only the pt solver
> itself sees that 'o' points to cell.

for in = &o->in, we should add

in = o + <offset> constraints

for every offset that can exist in the typeof("o->in").

And we should be doing this inside the various structure copy
constraint builders, but it's quite possible i fucked it up.

This would give you what you want, and make in point to cell.in.ii

Note that this is all a side-effect of trying to shoehorn may-alias
info directly into points-to sets, because our system thinks that a->i
is an access only to whatever a can point-to, instead of what a->i can
point to.

> > You don't want to play in solution_set_add, which is common to a bunch of
> > code.
>
> Well, it's common to exactly the code which handles offsetted constraints.
> And I don't see why the problem we face here (with offseted copy constraints)
> doesn't also occur with any other of the offseted constraints, e.g.
> "*x = y+32", handled in do_ds_constraint.

*x = y + 32 is an invalid constraint.

do_ds_constraint can't actually ever have a call where roffset is not
zero.  I've actually made this explicit on the pta-dev branch.

(you'll note do_sd_constraint also can't have loffset != zero).


>
> > > 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.
>
> Well, it's perhaps illegal in C (I'm not sure about that actually),

Joseph told me it was
>  but
> certainly occurs in C++, and even if it didn't occur there we are talking
> about the middle-end, for which such invalidity shouldn't matter (except we
> choose to define it as invalid).  To see why this is valid, consider this
> C++ program:
This is done through subtraction in C++, and we explicitly don't support it.

If we can't figure out what is going on, we collapse the whole thing
to a single variable and call it a day.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30252