[Bug tree-optimization/26726] -fivopts producing out of bounds array refs

2006-05-01 Thread rguenth at gcc dot gnu dot org
--- 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]>

[Bug tree-optimization/26726] -fivopts producing out of bounds array refs

2006-04-28 Thread patchapp at dberlin dot org
--- 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

[Bug tree-optimization/26726] -fivopts producing out of bounds array refs

2006-04-27 Thread rguenther at suse dot de
--- 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 >

[Bug tree-optimization/26726] -fivopts producing out of bounds array refs

2006-04-27 Thread rakdver at atrey dot karlin dot mff dot cuni dot cz
--- 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

[Bug tree-optimization/26726] -fivopts producing out of bounds array refs

2006-04-27 Thread rguenth at gcc dot gnu dot org
--- 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

[Bug tree-optimization/26726] -fivopts producing out of bounds array refs

2006-04-27 Thread rguenth at gcc dot gnu dot org
--- 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

[Bug tree-optimization/26726] -fivopts producing out of bounds array refs

2006-03-17 Thread dberlin at dberlin dot org
--- 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

Re: [Bug tree-optimization/26726] -fivopts producing out of bounds array refs

2006-03-17 Thread Daniel Berlin
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,

[Bug tree-optimization/26726] -fivopts producing out of bounds array refs

2006-03-17 Thread rguenth at gcc dot gnu dot org
--- 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

[Bug tree-optimization/26726] -fivopts producing out of bounds array refs

2006-03-17 Thread rguenth at gcc dot gnu dot org
--- 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. --

[Bug tree-optimization/26726] -fivopts producing out of bounds array refs

2006-03-17 Thread rguenth at gcc dot gnu dot org
--- 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

[Bug tree-optimization/26726] -fivopts producing out of bounds array refs

2006-03-17 Thread mueller at gcc dot gnu dot org
--- 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 -

[Bug tree-optimization/26726] -fivopts producing out of bounds array refs

2006-03-17 Thread rguenth at gcc dot gnu dot org
--- 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