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

["rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>]

------- 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.  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 :)

Richard.


-- 


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