--- Comment #12 from rguenth at gcc dot gnu dot org 2006-05-01 15:07
---
Subject: Bug 26726
Author: rguenth
Date: Mon May 1 15:07:25 2006
New Revision: 113414
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113414
Log:
2006-05-01 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #11 from patchapp at dberlin dot org 2006-04-28 14:35 ---
Subject: Bug number PR26726
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-04/msg01095.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #10 from rguenther at suse dot de 2006-04-27 16:09 ---
Subject: Re: -fivopts producing out of bounds
array refs
On Thu, 27 Apr 2006, rakdver at atrey dot karlin dot mff dot cuni dot cz wrote:
> > Stripping useless type conversions during biv discovery and folding after
>
--- Comment #9 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-04-27 16:02 ---
Subject: Re: -fivopts producing out of bounds array refs
> One thing is, that find_interesting_uses_address () produces bases that look
> like &(&a[0])->s. I.e. they are not folded during IV
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-04-27 15:59 ---
The offset causes the assembler to be sub-optimal:
.LCFI2:
leal-12(%ebp), %eax
leal4(%ebp), %edx
.p2align 4,,7
.L2:
movl$1, -4(%eax)
addl$4, %eax
cmpl
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-04-27 15:47 ---
One thing is, that find_interesting_uses_address () produces bases that look
like &(&a[0])->s. I.e. they are not folded during IV base insertion via
if (!for_each_index (&base, idx_find_step, &ifs_ivopts_data
--- Comment #6 from dberlin at gcc dot gnu dot org 2006-03-17 13:31 ---
Subject: Re: -fivopts producing out of bounds
array refs
On Fri, 2006-03-17 at 12:40 +, mueller at gcc dot gnu dot org wrote:
>
> --- Comment #2 from mueller at gcc dot gnu dot org 2006-03-17 12:4
On Fri, 2006-03-17 at 12:40 +, mueller at gcc dot gnu dot org wrote:
>
> --- Comment #2 from mueller at gcc dot gnu dot org 2006-03-17 12:40
> ---
> one possible workaround would be to lower the ARRAY_REF's to indirect mem
> refs,
> which I don't track
>
>
Uh, no.
We are in fact,
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-03-17 13:17 ---
Simpler testcase:
struct Foo {
Foo() : s(1) {}
int s;
};
void foo(Foo&);
void bar(void)
{
Foo x[4];
foo(x[0]);
}
:
ivtmp.34 = &x[1];
:;
D.1822 = (int *) &x[0];
D.1825 = -&x;
MEM[base: D.1822 + (int
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-03-17 13:00 ---
Now I noticed IVOPTs generates a TMR with base == &iconlist[1] + ivtmp,
offset -&iconlist[0] and offset -4B (ivtmp being &iconlist[0] initially).
Which boils down to using simply *ivtmp instead of a TMR. Funny.
--
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-03-17 12:55 ---
For your warning patch another option is to simply only warn in either the
first or the second VRP pass, not in the third which is the only one run after
loop optimizations. Also you could ignore ADDR_EXPR (ARRAY_RE
--- Comment #2 from mueller at gcc dot gnu dot org 2006-03-17 12:40 ---
one possible workaround would be to lower the ARRAY_REF's to indirect mem refs,
which I don't track
--
mueller at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-17 11:39 ---
Reduced testcase:
struct QValueList {
QValueList() { sh = new int; }
void foo();
int* sh;
};
void queryIconsByContext()
{
QValueList iconlist[8];
iconlist[7].foo();
}
ivopts generates
:
ivtm
13 matches
Mail list logo
