------- Comment #41 from rguenther at suse dot de 2007-06-06 08:49 ------- Subject: Re: [4.2 regression] miscompilation of sigc++-2.0 based code with -fstrict-aliasing
On Wed, 5 Jun 2007, dberlin at dberlin dot org wrote: > 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. Now, this is of course only because of aliasing. It should be completely irrelevant for points-to. So, if points-to comes up with "only" &struct as a solution we would need some intermediate processing to translate it to the correct alias set, possibly looking at the type hierarchy again. > Note that this also prevents us from doing cool things. Too bad ;) > 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. So we seem to agree the current solution is ugly and doesn't really work. Enough time to fix it for 4.3 then ;) Btw, how does a patch to disable field sensitivity look like for the 4.2 branch? Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30252
