This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code



------- Comment #17 from dougkwan at google dot com  2007-06-14 01:09 -------
Subject: Re:  [4.2 Regression] Incorrect stack sharing causing removal of live
code

Unless the compiler can prove that f() does not save the pointer to c
and use it later, it cannot share a stack slot for c & c1. This is
true regardless of any block scoping in the source. Yeah, it looks
like accessing c outside of the first block was undefined but I was
told me that GIMPLE promote c & c1 all the function scope.

-Doug

14 Jun 2007 01:02:48 -0000, pinskia at gcc dot gnu dot org
<gcc-bugzilla@gcc.gnu.org>:
>
>
> ------- Comment #16 from pinskia at gcc dot gnu dot org  2007-06-14 01:02 -------
> The problem is that it needs also source style scoping also:
> take:
> int f(int *a);
> int g(int b)
> {
>   {
>     int c;
>     f(&c);
>   }
>   {
>     int c1;
>     f(&c1);
>   }
> }
>
> Without source based ones, we don't know if c/c1 can ever be shared.
> I have code here at Sony where we actually depend on this behavior with large
> structs (and arrays).
>
>
> --
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
>
> ------- 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=32327


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]