------- Comment #3 from dberlin at gcc dot gnu dot org 2009-01-13 18:42 ------- Subject: Re: points-to result wrong for reads from call-clobbered vars
Interesting. I have emailed some others for their thoughts. One way to eliminate this bug would be to mark the entire structure as indirect nodes due to &s when we initialize the offline problem. You would also have to do the same if you see &s.p. The problem of course, is that i think our C++ implementation still plays games with subtracting offsets, so for C++, you'd have to mark the entire structure full of variables indirect when you see address taking of any member :( Anyway, give me a short time to wait for responses and see if there is a good way out of this. On Tue, Jan 13, 2009 at 7:34 AM, rguenth at gcc dot gnu dot org <gcc-bugzi...@gcc.gnu.org> wrote: > > > ------- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-13 12:34 > ------- > It is interesting to see how taking the address of &s.q makes it a pointer > variable. The fundamental issue seems to be that eliminating non-pointers > and their edges conflicts with field-sensitive analysis. > > Consider > > struct S { int *p; int *q; }; > > void foo (struct S **); > > int *bar (int b) > { > struct S s; > struct S *p = &s; > foo (&p); > return s.q; > } > > to see that just generating extra ADDRESSOF constraints for call arguments > will not fix the issue. > > Not only we will need to avoid eliminating non-pointers / edges if any of a > variables sub-field has got a proper pointer label, unifying them (they > still have pointer label 0) is also wrong. > > Danny, any idea where/how to fix this? > > > -- > > rguenth at gcc dot gnu dot org changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |dberlin at gcc dot gnu dot > | |org > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38826 > > ------- You are receiving this mail because: ------- > You are on the CC list for the bug, or are watching someone who is. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38826