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

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

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

On 5 Jun 2007 19:59:32 -0000, rguenther at suse dot de
<gcc-bugzilla@gcc.gnu.org> wrote:
>
>
> ------- Comment #39 from rguenther at suse dot de  2007-06-05 19:59 -------
> 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:
>
> > ------- 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:
> > >
> > > 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.
>
> But there are cases there is no constraint variable for p + 5.  Like
> the problem with the empty bases that we take the address of but don't
> generate constraint variables for.  Or consider
>
> int p[2];
> void *q = p;
> int *p2;
> q = q + 1;
> q = q + 1;
> q = q + 1;
> q = q + 1;
> p2 = q;
> *p2 = 1;
>
> which is a valid way to store into p[1].  We obviously don't have
> constraint variables for q + 1 -- we have one for &p[0] and one
> for &p[1], but we cannot represent q + 1 exactly.

q_2 = q_1 + 1
q_3 = q_2 + 1
q_4 = q_3 + 1
q_5 = q_4 + 1
p2 = q_5

Will become the set of constraints
q_2 = q_1
q_2 = q_1 + 1
q_3 = q_2
q_3 = q_2 + 1
q_4 = q_3
q_4 = q_3 + 1
q_5 = q_4
q_5 = q_4 +1

Hmmm.
You are right, we should give up here and collapse the variable.
Sigh.

Well, we can always just make it give up on all direct pointer
arithmetic, rather than try to handle it at all :)

> Somehow it
> doesn't cause problems to "fall back" to &p[0] for &p[0] + 1B,
> but it would be nice to have some more confidence in that parts :)

TBQH, the only way i'll ever have confidence in these parts is if we
make it stop trying to come up with everything a pointer to a
structure could deref.
Note that this also prevents us from doing cool things.

In particular, because we say a pointer to struct p points to all it's
members, we can never simply propagate the object it does point to if
it points to a single object.


-- 


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