--- Comment #45 from bergner at gcc dot gnu dot org 2008-01-08 15:44
---
This has been fixed in mainline (4.3), but has not been fixed in 4.2. I'm ok
with not back porting this to 4.2. I'll give everyone a few days to object,
otherwise I'll change the Target Milestone to 4.3 and
--- Comment #44 from steven at gcc dot gnu dot org 2008-01-07 17:34 ---
Hello world. Please, a status update.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #43 from steven at gcc dot gnu dot org 2007-11-10 17:05 ---
What is the status of this bug now? Re. comment #39, a meta-bug for what?
There is only one open bug left that depends on this one.
Are we still tracking an issue in this bug? If so, what? If not, please close
--- Comment #42 from mmitchel at gcc dot gnu dot org 2007-10-09 19:21
---
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
--- Comment #39 from bonzini at gnu dot org 2007-08-06 08:08 ---
committed??
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
--- Comment #40 from pinskia at gcc dot gnu dot org 2007-08-06 11:35
---
(In reply to comment #39)
committed??
This is now more like a meta-bug, see the other two bugs which are opened for
the current issues (yes both are assigned to me and both are actively being
worked on, well one
--- Comment #41 from paolo dot bonzini at lu dot unisi dot ch 2007-08-06
11:52 ---
Subject: Re: [4.2/4.3 Regression] Performace problem
with indexed load/stores on powerpc
This is now more like a meta-bug, see the other two bugs which are opened for
the current issues (yes both
--
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=28690
--- Comment #38 from bergner at gcc dot gnu dot org 2007-06-09 04:08
---
Created an attachment (id=13671)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13671action=view)
Updated patch to address x86_64 performance issues.
This updated patch reverts the
--- Comment #37 from mmitchel at gcc dot gnu dot org 2007-05-14 22:25
---
Will not be fixed in 4.2.0; retargeting at 4.2.1.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #36 from bergner at gcc dot gnu dot org 2007-02-23 17:14
---
Created an attachment (id=13101)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13101action=view)
Alternate patch to commutative_operand_precedence to increase the precedence of
REG_POINTER and MEM_POINTER
--- Comment #35 from bergner at gcc dot gnu dot org 2007-02-12 17:29
---
Created an attachment (id=13042)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13042action=view)
Alternate patch to commutative_operand_precedence to increase the precedence of
REG_POINTER and MEM_POINTER
--- Comment #34 from bergner at gcc dot gnu dot org 2007-01-17 20:58
---
Created an attachment (id=12915)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12915action=view)
Patch to commutative_operand_precedence to increase the precedence of
REG_POINTER and MEM_POINTER objects.
--- Comment #32 from pthaugen at us dot ibm dot com 2006-12-05 16:12
---
Another example, pared down from ammp benchmark in cpu2000.
void f2(int *, int *);
void mm_fv_update_nonbon(void)
{
int j, nx;
int naybor[27];
f2(naybor, nx);
for(j=0; j 27; j++)
if( naybor[j]) break;
--- Comment #33 from pthaugen at us dot ibm dot com 2006-12-05 16:30
---
My prior comment is missing the closing bracket for the procedure, but example
is otherwise complete.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
--- Comment #30 from bergner at vnet dot ibm dot com 2006-12-05 04:22
---
Ok, the problem from comment #28 was due to a latent bug in
reload1.c:eliminate_regs_in_insn(). The bug is that eliminate_regs_in_insn()
calls single_set() on the passed in insn. This has been fine before, but
--- Comment #31 from bergner at vnet dot ibm dot com 2006-12-05 04:41
---
...and here's the patch I mentioned in the previous comment:
Index: reload1.c
===
--- reload1.c (revision 119497)
+++ reload1.c (working copy)
--- Comment #28 from bergner at vnet dot ibm dot com 2006-11-29 20:11
---
Another problem with the current patch, is we get one testsuite regression
(gfortran.fortran-torture/compile/defined_type_2.f90 at -O1). For this simple
testcase, we end up generating bad assembler:
mr
--- Comment #29 from bergner at vnet dot ibm dot com 2006-11-29 22:23
---
Talking with Andrew on IRC, he said the test case in comment #27 fails for the
same reason as the test case in comment #24 (ie, it looks like an artificial
decl) and should be fixed with his PTR_PLUS_EXPR work.
--- Comment #27 from bonzini at gnu dot org 2006-11-29 07:56 ---
This case is still not fixed:
struct s {
int size;
float *data;
};
void f(struct s *d, struct s *s)
{
int i;
for (i = 0; i s-size; i++)
d-data[i] += s-data[i];
}
The body of the loop is compiled to:
L4:
--- Comment #24 from bergner at vnet dot ibm dot com 2006-11-08 03:30
---
Ok, Anton hit another test case the last patch doesn't transform. It's
actually the same test case as in comment #13, except, int *base is now a
global variable rather than a function parameter.
int *base;
int
--- Comment #25 from pinskia at gcc dot gnu dot org 2006-11-08 03:35
---
(In reply to comment #24)
Does anyone know why var above was marked as
artifical?
Yes because it is an compiler generated decl for the load of the global. The
main reason why we don't mark the RTL for artifical
22 matches
Mail list logo
