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