This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/38826] points-to result wrong for reads from call-clobbered vars
- From: "dberlin at dberlin dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 13 Jan 2009 18:43:00 -0000
- Subject: [Bug tree-optimization/38826] points-to result wrong for reads from call-clobbered vars
- References: <bug-38826-10053@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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-bugzilla@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