------- Comment #42 from dberlin at gcc dot gnu dot org 2007-06-06 15:52 ------- Subject: Re: [4.2 regression] miscompilation of sigc++-2.0 based code with -fstrict-aliasing
On 6 Jun 2007 08:49:50 -0000, rguenther at suse dot de <[EMAIL PROTECTED]> wrote: > > > ------- 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. > Well, actually, you don't. At the point where you process it, we either have created SFT's or we haven't (if we haven't than the deref is going to touch the one variable we've created for the struct) The rest is more or less equivalent to what access_can_touch_variable does :) > 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? The patch is trivial. We have static bool use_field_sensitive = true at the top of the file. Just set it to false and away you go. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30252
