[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #34 from jsm28 at gcc dot gnu dot org 2009-03-30 22:06 --- Closing 4.2 branch, fixed in 4.3. (There's a lot of discussion here of a possible underlying problem that might or might not be fixed but isn't 4.2-only; if still present, please open a separate bug report for it.) -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|4.2.0 |4.2.0 4.2.5 Resolution||FIXED Target Milestone|4.2.5 |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #33 from jsm28 at gcc dot gnu dot org 2008-05-19 20:23 --- 4.2.4 is being released, changing milestones to 4.2.5. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.4 |4.2.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #32 from jsm28 at gcc dot gnu dot org 2008-02-01 16:54 --- 4.2.3 is being released now, changing milestones of open bugs to 4.2.4. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.3 |4.2.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #31 from mmitchel at gcc dot gnu dot org 2007-10-09 19:20 --- Change target milestone to 4.2.3, as 4.2.2 has been released. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.2 |4.2.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.1 |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #30 from dnovillo at google dot com 2007-07-04 11:22 --- Subject: Re: [4.2 Regression] Incorrect stack sharing causing removal of live code On 7/3/07 11:28 PM, mmitchel at gcc dot gnu dot org wrote: --- Comment #29 from mmitchel at gcc dot gnu dot org 2007-07-04 03:28 --- Diego, does this problem still exist on the 4.2 branch? I see that you checked in a patch, which you suggest may not be a complete fix, but does this test case still fail? Yes, the problem still exists on 4.2 and mainline. The patch is valid in that it fixes a codegen deficiency, but it only works around this bug. The test case does not fail anymore, and getting another one to fail may be tricky (it's a fairly rare bug, unfortunately). A real fix is in the works, but it's not clear when it might be ready. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #29 from mmitchel at gcc dot gnu dot org 2007-07-04 03:28 --- Diego, does this problem still exist on the 4.2 branch? I see that you checked in a patch, which you suggest may not be a complete fix, but does this test case still fail? -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #26 from rth at gcc dot gnu dot org 2007-06-19 17:26 --- (In reply to comment #10) Talked to Dan Berlin and Diego Novillo here at Google. They told me that all locals are promoted to function scope. That *only* applies to register variables, not stack variables. We very very much want to preserve scope of stack variables, because we very very much want to share stack space between stack variables of different scopes. Failure to do so causes bad interactions with inlining, and causes stack space consumtion to grow to unacceptable levels. I.e. you can't build kernels anymore. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #27 from dnovillo at google dot com 2007-06-19 17:39 --- Subject: Re: [4.2 Regression] Incorrect stack sharing causing removal of live code On 6/19/07 1:26 PM, rth at gcc dot gnu dot org wrote: --- Comment #26 from rth at gcc dot gnu dot org 2007-06-19 17:26 --- (In reply to comment #10) Talked to Dan Berlin and Diego Novillo here at Google. They told me that all locals are promoted to function scope. That *only* applies to register variables, not stack variables. Yes, but our GIMPLE optimizers don't know that and we do not have a way of enforcing that in GIMPLE. There just are no scope boundaries in the SSA web. So, the end result is that in SSA we only have function scope. We very very much want to preserve scope of stack variables, because we very very much want to share stack space between stack variables of different scopes. Failure to do so causes bad interactions with inlining, and causes stack space consumtion to grow to unacceptable levels. I.e. you can't build kernels anymore. Agreed. We have to find a way of either tying the hands of code motion transformations by making them use the SSA web *and* the TREE_BLOCKs, or make stack slot sharing aware of live ranges. Right now we have the unfortunate situation that an optimizer is making a valid transformation which breaks the scope assumption that stack sharing uses. I am not sure if it would be practical to force code motion optimizations to use anything other than the SSA web to do their analysis. Perhaps we could force scopes by building barriers on the SSA web itself (say, by putting PHI nodes at scope boundaries, or something). Alternatively, we could incorporate live-range analysis to stack slot sharing. That way, if code motion creates undue stack slot pressure, we would merely emit suboptimal code, instead of wrong code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #28 from amacleod at redhat dot com 2007-06-19 18:57 --- Won't solve the problem currently, but I think the long term solution is to do stack analysis when out-of-ssa and expand have been merged into a single entity. The live range info out-of-ssa calculates can be used to do a decent job of stack sharing regardless of scoping info. Short term, we might be able to check to see if a stack variable is used outside its scope when going out of ssa, and flag it for no sharing, or promote it to file level, or the next appropriate scope level. That would work as long as we don't end up promoting too many things in the wrong routines :-). I'm not fond of trying to make the optimization passes aware of scopes on top of everything else they are aware of, Id rather see it taken care of in one place, and not dependent on scoping info. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #25 from dnovillo at gcc dot gnu dot org 2007-06-18 12:30 --- Fixed symptoms with http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01081.html. Real fix still being discussed. -- dnovillo at gcc dot gnu dot org changed: What|Removed |Added CC||amacleod at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #22 from mec at google dot com 2007-06-15 13:15 --- With the test program, gcc 4.1.2 generates correct code and gcc 4.2.0 generates wrong code. Can someone increase the priority and severity of this PR? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #23 from dnovillo at gcc dot gnu dot org 2007-06-15 13:27 --- Working on this today. -- dnovillo at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-15 13:27:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #24 from dnovillo at gcc dot gnu dot org 2007-06-15 22:10 --- Subject: Bug 32327 Author: dnovillo Date: Fri Jun 15 22:10:09 2007 New Revision: 125748 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125748 Log: PR 32327 * tree-ssa-operands.c (build_ssa_operands): Initially assume that the statement does not take any addresses. testsuite/ChangeLog PR 32327 * g++.dg/tree-ssa/pr32327-1.C: New test. * g++.dg/tree-ssa/pr32327.C: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/tree-ssa/pr32327-1.C branches/gcc-4_2-branch/gcc/testsuite/g++.dg/tree-ssa/pr32327.C Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/gcc/tree-ssa-operands.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #19 from ian at airs dot com 2007-06-14 17:57 --- Adding Richard in case he has any comment. I don't agree with comment #17 from Doug. In the code in comment #16, if f saves c, there is no way that it could validly use it after the block scope exits. In general if we expand the scope of a variable outside of its block scope, then the stack sharing code in cfgexpand.c will do the wrong thing. There is normally no reason for the tree code to expand the scope of a variable. But there is also nothing specifically to stop it from doing so. In this particular case store sinking is extending the life of a variable. This is a meaningless move, as there is no valid way for the stored value to be accessed. It is happening because alias analysis thinks that the function call can refer to the stored variable, although this actually can not happen. Part of the reason alias analysis is wrong is that we retain the list of addressable variables in a statement when we shouldn't. Interestingly, if I apply the tree-ssa-operands.c patch from http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01807.html then the problem goes away. But there are a few complex issues here: 1) Alias analysis thinks that a function can refer to a variable in a different block scope. 2) Nothing systematically prevents the tree code from referencing or setting variables outside of their block scope. 3) The stack sharing code in cfgexpand assumes that variables are only referenced or set within their block scope. This is going to require more investigation. I think we are mainly lucky because the tree optimizers tend to not move variables outside of their block scope. This test case just happens to show a way in which that can happen. -- ian at airs dot com changed: What|Removed |Added CC||rth at gcc dot gnu dot org, ||ian at airs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #20 from dougkwan at google dot com 2007-06-14 18:05 --- Subject: Re: [4.2 Regression] Incorrect stack sharing causing removal of live code That was my initial opinion too but Diego and Danny told me there is only one scope in the tree SSA form. So it is okay. About your comment of us being lucky, I believe our luck is running out. As we do more and more things in the tree passes, we will be likely to see this problem more often. 14 Jun 2007 17:58:01 -, ian at airs dot com [EMAIL PROTECTED]: --- Comment #19 from ian at airs dot com 2007-06-14 17:57 --- I don't agree with comment #17 from Doug. In the code in comment #16, if f saves c, there is no way that it could validly use it after the block scope exits. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #21 from rguenther at suse dot de 2007-06-14 18:12 --- Subject: Re: [4.2 Regression] Incorrect stack sharing causing removal of live code On Thu, 14 Jun 2007, ian at airs dot com wrote: --- Comment #19 from ian at airs dot com 2007-06-14 17:57 --- This is going to require more investigation. I think we are mainly lucky because the tree optimizers tend to not move variables outside of their block scope. This test case just happens to show a way in which that can happen. We may finally need to compute life for on-stack variables instead of relying on something not happening that is not explicitly forbidden in our IL (placement new anyone? ;)) (the other) Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-06-13 21:42 --- (In reply to comment #2) The address of dest has been passed to memcpy() and the alias analysis considers the varaible to escape. So potentially foo() can see the value of dest if memcpy() stash the pointer somewhere. This is impossible but the compiler cannot prove this so it has to be conservative and treat foo() as a potential reader of dest. We remove the call to memcpy (in 4.2) in .064t.fab and then alias5 should have changed it (dest) to be non ADDRESSABLE but it is not for some reason. I think may_alias is messed up in 4.2.0. Also sink maybe should not be sinking stores. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to work|4.3.0 |4.3.0 4.1.1 Summary|Incorrect stack sharing |[4.2 Regression] Incorrect |causing removal of live code|stack sharing causing ||removal of live code Target Milestone|--- |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #6 from dougkwan at google dot com 2007-06-13 21:50 --- Subject: Re: [4.2 Regression] Incorrect stack sharing causing removal of live code Fixing alias analysis in 4.2.0 will make this problem go away but it does not change the underlying issue in the stack local sharing code. 13 Jun 2007 21:42:01 -, pinskia at gcc dot gnu dot org [EMAIL PROTECTED]: --- Comment #5 from pinskia at gcc dot gnu dot org 2007-06-13 21:42 --- (In reply to comment #2) The address of dest has been passed to memcpy() and the alias analysis considers the varaible to escape. So potentially foo() can see the value of dest if memcpy() stash the pointer somewhere. This is impossible but the compiler cannot prove this so it has to be conservative and treat foo() as a potential reader of dest. We remove the call to memcpy (in 4.2) in .064t.fab and then alias5 should have changed it (dest) to be non ADDRESSABLE but it is not for some reason. I think may_alias is messed up in 4.2.0. Also sink maybe should not be sinking stores. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to work|4.3.0 |4.3.0 4.1.1 Summary|Incorrect stack sharing |[4.2 Regression] Incorrect |causing removal of live code|stack sharing causing ||removal of live code Target Milestone|--- |4.2.1 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
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-06-13 21:53 --- (In reply to comment #6) Fixing alias analysis in 4.2.0 will make this problem go away but it does not change the underlying issue in the stack local sharing code. Is that really true? The underlying issue is sinking the store is causing the variables to in the same scope. I think that is the real underlying issue and nothing to do with local stack sharing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #8 from dougkwan at google dot com 2007-06-14 00:14 --- Subject: Re: [4.2 Regression] Incorrect stack sharing causing removal of live code I thought like you do initially. But then I was told that in gimple everything is promoted to function scope. So dest is not out of scope. -Doug 13 Jun 2007 21:53:15 -, pinskia at gcc dot gnu dot org [EMAIL PROTECTED]: --- Comment #7 from pinskia at gcc dot gnu dot org 2007-06-13 21:53 --- Is that really true? The underlying issue is sinking the store is causing the variables to in the same scope. I think that is the real underlying issue and nothing to do with local stack sharing. -- 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
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-06-14 00:28 --- (In reply to comment #8) Subject: Re: [4.2 Regression] Incorrect stack sharing causing removal of live code I thought like you do initially. But then I was told that in gimple everything is promoted to function scope. So dest is not out of scope. Who said that? We keep around the scopes, how else do we get stack sharing in the first place? Also you cannot turn off stack sharing because that would cause some programs no longer to be useful (LLVM is one, the stack would just blow up). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #10 from dougkwan at google dot com 2007-06-14 00:35 --- Subject: Re: [4.2 Regression] Incorrect stack sharing causing removal of live code Talked to Dan Berlin and Diego Novillo here at Google. They told me that all locals are promoted to function scope. In generally, the tree passes can do abitrary transformation like hoisting or loop invariant motion that can move a variable out of its original block scope. If we keep the scopes around. There must be code to fix up all block scoping information before the tree passes end. It may be just a matter to find why the scope of dest is not fixed up properly. 14 Jun 2007 00:28:27 -, pinskia at gcc dot gnu dot org [EMAIL PROTECTED]: Who said that? We keep around the scopes, how else do we get stack sharing in the first place? Also you cannot turn off stack sharing because that would cause some programs no longer to be useful (LLVM is one, the stack would just blow up). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-06-14 00:42 --- Look at the code in cfgexpand.c, expand_used_vars, this looks at the source blocks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-06-14 00:42 --- This code has been there since 4.0.0 so this has been true since then. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #13 from dougkwan at google dot com 2007-06-14 00:46 --- Subject: Re: [4.2 Regression] Incorrect stack sharing causing removal of live code Yes, I saw the code there yesterday and I was wondering if the block scope got fixed up somehow. 14 Jun 2007 00:42:23 -, pinskia at gcc dot gnu dot org [EMAIL PROTECTED]: --- Comment #11 from pinskia at gcc dot gnu dot org 2007-06-14 00:42 --- Look at the code in cfgexpand.c, expand_used_vars, this looks at the source blocks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #14 from pinskia at gmail dot com 2007-06-14 00:52 --- Subject: Re: [4.2 Regression] Incorrect stack sharing causing removal of live code On 14 Jun 2007 00:46:28 -, dougkwan at google dot com [EMAIL PROTECTED] wrote: Yes, I saw the code there yesterday and I was wondering if the block scope got fixed up somehow. It can't because the debugging information will be messed up. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #15 from dougkwan at google dot com 2007-06-14 00:59 --- Subject: Re: [4.2 Regression] Incorrect stack sharing causing removal of live code Then the stack local sharing code is very broken. It should do a real live-range analysis instead of using block scoping information form the source tree. -Doug 14 Jun 2007 00:52:45 -, pinskia at gmail dot com [EMAIL PROTECTED]: It can't because the debugging information will be messed up. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- 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
[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 -, pinskia at gcc dot gnu dot org
[EMAIL PROTECTED]:
--- 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
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #18 from pinskia at gmail dot com 2007-06-14 01:14 --- Subject: Re: [4.2 Regression] Incorrect stack sharing causing removal of live code On 14 Jun 2007 01:09:16 -, dougkwan at google dot com [EMAIL PROTECTED] wrote: 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. Yes but I don't think GIMPLE does that, it might promote register based ones but not addressable ones (as mentioned before). Really if we change the stack sharing, we are going to cause a large number of regressions, I already have some regressions between 4.0 and 4.1 due to stack sharing changes with two large structs not being in the same slot even though we can put them there with one having an offset. And yes I still need to file that bug. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
