--- 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.)
--- 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
--- 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
--- 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
--
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
--- 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
--- 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
--- 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
--- 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 ---
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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 #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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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,
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
31 matches
Mail list logo
