------- 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 > <[EMAIL PROTECTED]> 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
