http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
--- Comment #50 from eraman at gcc dot gnu.org 2012-11-02 00:28:45 UTC ---
Author: eraman
Date: Fri Nov 2 00:28:40 2012
New Revision: 193085
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193085
Log:
Backport 191302 and 1926
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
--- Comment #49 from Eric Botcazou 2012-10-21
12:36:21 UTC ---
Author: ebotcazou
Date: Sun Oct 21 12:36:16 2012
New Revision: 192651
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192651
Log:
PR rtl-optimization/44194
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
--- Comment #48 from Chip Salzenberg 2012-09-14
17:23:08 UTC ---
May Shub-Internet not see you as you pass.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
--- Comment #46 from Eric Botcazou 2012-09-14
13:28:52 UTC ---
Author: ebotcazou
Date: Fri Sep 14 13:28:44 2012
New Revision: 191302
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191302
Log:
PR rtl-optimization/44194
* calls.c (e
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
--- Comment #45 from Eric Botcazou 2012-09-12
23:59:03 UTC ---
> Note that the x86 target has been changed in svn to use TImode for 128-bit
> structures, and structures bigger than 128 bits may not be passed in
> registers,
> so triggering this
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
--- Comment #44 from Chip Salzenberg 2012-09-12
23:21:21 UTC ---
Note that the x86 target has been changed in svn to use TImode for 128-bit
structures, and structures bigger than 128 bits may not be passed in registers,
so triggering this bug may
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
--- Comment #43 from Eric Botcazou 2012-09-12
22:30:41 UTC ---
> Is bug #28831 a dup of this?
Not exactly, PR middle-end/28831 is a generic problem while this one is
specific to architectures that can return structures in registers.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
Chip Salzenberg changed:
What|Removed |Added
CC||chip at pobox dot com
--- Comment #42 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
Richard Guenther changed:
What|Removed |Added
Target Milestone|4.7.1 |---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
--- Comment #41 from Eric Botcazou 2012-03-22
18:17:59 UTC ---
> Any plans w.r.t the fix to this problem?
Yes, I have plans, but less time unfortunately. But I'll definitely tackle it
during this stage #1.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
Uros Bizjak changed:
What|Removed |Added
CC||ubizjak at gmail dot com
--- Comment #40 fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
Richard Guenther changed:
What|Removed |Added
Target Milestone|4.7.0 |4.7.1
--- Comment #39 from Richard Gue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
Eric Botcazou changed:
What|Removed |Added
Status|REOPENED|ASSIGNED
AssignedTo|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
Eric Botcazou changed:
What|Removed |Added
CC||ro at gcc dot gnu.org
--- Comment #37 fro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
--- Comment #36 from Eric Botcazou 2011-06-22
07:57:28 UTC ---
> There is a comment in calls.c that says
>/* Handle calls that return values in multiple non-contiguous
> locations.
> The Irix 6 ABI has examples of this. */
>
> I d
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
--- Comment #35 from Easwaran Raman 2011-06-20
16:51:18 UTC ---
(In reply to comment #33)
> > I think these two are totally independent of each other -- one should not be
> > gated against each other. If Eawaran's approach is completely flawed, t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
--- Comment #34 from davidxl 2011-06-20 16:25:04
UTC ---
(In reply to comment #33)
> > I think these two are totally independent of each other -- one should not be
> > gated against each other. If Eawaran's approach is completely flawed, that
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
--- Comment #33 from Eric Botcazou 2011-06-20
15:27:06 UTC ---
> I think these two are totally independent of each other -- one should not be
> gated against each other. If Eawaran's approach is completely flawed, that is
> different story. With
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
--- Comment #32 from rguenther at suse dot de
2011-06-20 09:22:31 UTC ---
On Sat, 18 Jun 2011, xinliangli at gmail dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
>
> --- Comment #29 from davidxl 2011-06-18
> 09:05:10 UTC -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
--- Comment #31 from davidxl 2011-06-18 16:32:32
UTC ---
(In reply to comment #30)
> > Is Easwaran's patch a reasonable way to go?
>
> So, in the end, you weren't talking about the general situation, were you?
> Let's try first to avoid spillin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
--- Comment #30 from Eric Botcazou 2011-06-18
09:27:36 UTC ---
> Is Easwaran's patch a reasonable way to go?
So, in the end, you weren't talking about the general situation, were you?
Let's try first to avoid spilling to memory, if possible.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
--- Comment #29 from davidxl 2011-06-18 09:05:10
UTC ---
Is Easwaran's patch a reasonable way to go?
David
(In reply to comment #28)
> On Thu, 16 Jun 2011, eraman at google dot com wrote:
>
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4419
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
--- Comment #28 from rguenther at suse dot de
2011-06-17 08:21:30 UTC ---
On Thu, 16 Jun 2011, eraman at google dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
>
> --- Comment #27 from Easwaran Raman 2011-06-16
> 17:14:38 U
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
--- Comment #27 from Easwaran Raman 2011-06-16
17:14:38 UTC ---
(In reply to comment #26)
> On Wed, 15 Jun 2011, xinliangli at gmail dot com wrote:
>
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
> >
> > davidxl changed:
> >
> >
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
--- Comment #26 from rguenther at suse dot de
2011-06-16 08:36:21 UTC ---
On Wed, 15 Jun 2011, xinliangli at gmail dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
>
> davidxl changed:
>
>What|Removed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
--- Comment #25 from davidxl 2011-06-16 07:41:57
UTC ---
On Wed, Jun 15, 2011 at 10:26 PM, ebotcazou at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
>
> --- Comment #24 from Eric Botcazou
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
--- Comment #24 from Eric Botcazou 2011-06-16
05:26:56 UTC ---
> It would be nice if the expander does not spill the return into memory in the
> first place if possible. On other hand tagging compiler created memory
> location with temp decls so
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
davidxl changed:
What|Removed |Added
CC||xinliangli at gmail dot com
--- Comment #23 fro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
Eric Botcazou changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
--- Comment #21 from Easwaran Raman 2011-06-15
20:34:32 UTC ---
The DSE patch still leaves 2 redundant stores. The following patch will enable
DSE to remove those two stores. Does this look ok?
Index: gcc/testsuite/gcc.dg/pr44194-1.c
=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
Eric Botcazou changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
--- Comment #19 from eraman at gcc dot gnu.org 2011-06-14 22:58:24 UTC ---
Author: eraman
Date: Tue Jun 14 22:58:20 2011
New Revision: 175063
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175063
Log:
2011-06-14 Easwaran Raman
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
--- Comment #18 from rguenther at suse dot de
2011-04-21 08:36:14 UTC ---
On Thu, 21 Apr 2011, eraman at google dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
>
> --- Comment #17 from Easwaran Raman 2011-04-21
> 00:20:51 U
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
--- Comment #17 from Easwaran Raman 2011-04-21
00:20:51 UTC ---
On Sun, Apr 17, 2011 at 3:45 AM, rguenther at suse dot de
wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
>
> --- Comment #16 from rguenther at suse dot de
> 2011-04-17
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
--- Comment #16 from rguenther at suse dot de
2011-04-17 10:44:02 UTC ---
On Fri, 15 Apr 2011, eraman at google dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
>
> --- Comment #15 from Easwaran Raman 2011-04-15
> 22:22:15 U
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
--- Comment #15 from Easwaran Raman 2011-04-15
22:22:15 UTC ---
(In reply to comment #14)
> On Fri, 15 Apr 2011, eraman at google dot com wrote:
>
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
> >
> > Easwaran Raman changed:
> >
> >
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
--- Comment #14 from rguenther at suse dot de
2011-04-15 19:31:36 UTC ---
On Fri, 15 Apr 2011, eraman at google dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
>
> Easwaran Raman changed:
>
>What|Removed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
Easwaran Raman changed:
What|Removed |Added
CC||eraman at google dot com
--- Comment #13
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
--- Comment #12 from Richard Guenther 2011-04-15
09:10:07 UTC ---
Yes, something like that. Though can_escape can be made simpler and more
precise by
bool
can_escape (tree expr)
{
tree base;
if (!expr)
return true;
base = get_base_add
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
--- Comment #11 from Eric Botcazou 2011-04-14
22:22:35 UTC ---
Richard, did you have something like that in mind when writing comment #3?
What aliasing info do we have at the RTL level now?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
Easwaran Raman changed:
What|Removed |Added
Attachment #23968|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
--- Comment #9 from Easwaran Raman 2011-04-12
22:39:23 UTC ---
Created attachment 23968
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23968
Patch to dse.c to be less conservative with calls.
Currently dse kills all stores on a call since c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
--- Comment #8 from Josh Haberman 2011-02-24
03:27:04 UTC ---
I found another test case for this. I thought I'd post it since it's extremely
different than the original one.
--
class Foo {
public:
virtual ~Foo() {}
virtual void DoSomethin
--- Comment #7 from jhaberman at gmail dot com 2010-07-10 01:48 ---
I must have been on crack when I wrote that last comment. Sorry for the noise.
Though I do wonder how difficult the original bug is to fix. This seems to
make it more expensive to return structures by value.
--
h
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-07-10 01:42 ---
>In 64-bit mode there is no store, but it *does* allocate 8 bytes of stack that
it never uses:
Oh no that is called aligning the stack to be 16 byte aligned.
>It also
seems to overallocate the stack (28 bytes alloc
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-07-10 01:40 ---
>In 32-bit mode it spills the return value to the stack for no reason.
Huh? arguments are passed via the stack in 32bit mode.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
--- Comment #4 from jhaberman at gmail dot com 2010-07-10 01:38 ---
This seems to happen even with POD return types:
int foo();
void bar(int a);
void func() {
bar(foo());
}
In 32-bit mode it spills the return value to the stack for no reason. It also
seems to overallocate the stack
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-05-19 10:22 ---
At leas the stores to s have alias info:
(insn 12 10 14 2 t.c:7 (set (mem/s/c:DI (plus:DI (reg/f:DI 20 frame)
(const_int -16 [0xfff0])) [2 s+0 S8 A128])
(reg:DI 60)) 89 {*movdi_1_
--- Comment #2 from jakub at gcc dot gnu dot org 2010-05-19 10:13 ---
RTL DSE doesn't handle this because the call to bar, which isn't a const
function, is considered a wild read and thus makes all stores necessary in the
global as well as local algorithm.
RTL DSE doesn't consider whethe
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-05-19 09:38 ---
Confirmed.
We already expand it that way:
;; s = foo ();
(insn 5 4 6 t.c:7 (set (reg:QI 0 ax)
(const_int 0 [0x0])) -1 (nil))
(call_insn 6 5 7 t.c:7 (set (parallel:BLK [
(expr_list:REG_DEP_
51 matches
Mail list logo
