[Bug target/26726] -fivopts producing out of bounds array refs
--- Comment #19 from ubizjak at gmail dot com 2008-01-27 17:52 --- The problem in comment #13 is fixed for 4.3.0 by the fix for PR 34771. -- ubizjak at gmail dot com changed: What|Removed |Added BugsThisDependsOn||34771 Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26726
[Bug target/26726] -fivopts producing out of bounds array refs
--- Comment #20 from ubizjak at gmail dot com 2008-01-27 17:53 --- (In reply to comment #19) The problem in comment #13 is fixed for 4.3.0 by the fix for PR 34771. Oops, PR 34711. -- ubizjak at gmail dot com changed: What|Removed |Added BugsThisDependsOn|34771 |34711 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26726
[Bug target/26726] -fivopts producing out of bounds array refs
--- Comment #17 from bonzini at gnu dot org 2007-10-29 10:05 --- This issue with -4 offset is annoying because code size of offsetted load insn is huge: f: c7 40 fc 01 00 00 00movl $0x1,-0x4(%eax) -0x4(%eax) is 2 bytes more than (%eax), where IIRC it would be a3 01 00 00 00, and only one byte more than any other non-offsetted load insn. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26726
[Bug target/26726] -fivopts producing out of bounds array refs
--- Comment #18 from ubizjak at gmail dot com 2007-10-29 13:22 ---
Perhaps this analysis will help someone...:
We start with following loop:
void bar() ()
{
unsigned int ivtmp.19;
int pretmp.14;
struct Foo * pretmp.13;
struct Foo x[4];
int D.1669;
struct Foo * D.1668;
bb 2:
bb 3:
# ivtmp.19_2 = PHI ivtmp.19_1(4), 4(2)
# D.1669_34 = PHI D.1669_7(4), 3(2)
# D.1668_33 = PHI D.1668_6(4), x[0](2)
D.1668_33-s = 1;
D.1668_6 = D.1668_33 + 4;
D.1669_7 = D.1669_34 + -1;
ivtmp.19_1 = ivtmp.19_2 - 1;
if (ivtmp.19_1 != 0)
goto bb 4;
else
goto bb 5;
bb 4:
goto bb 3;
...
General ivs in BB are found in tree-ssa-loop-ivopts.c via find_givs_in_bb().
find_givs_in_stmt() is entered with D.1668_6 = D.1668_33 + 4. For this stmt,
find_givs_in_stmt_scev() returns iv.base = x[1] and iv.step = 4.
Digging a bit further, find_givs_in_stmt_scev() calls simple_iv() in
tree-scalar-evolution.c() to determine iv base and step. simple_iv() is called
with op = D.1668_33 + 4 and this op is furhter passed to
analyze_scalar_evolution_in_loop(). This function returns {x[1], +, 4}_1.
analyze_scalar_evolution_in_loop() calls analyze_scalar_evolution() with
D.1668_33 + 4. This expression is further passed to
analyze_scalar_evolution_1(). As the expression is not SSA_NAME, it is passed
to interpret_rhs_modify_stmt() as POINTER_PLUS_EXPR.
interpret_rhs_modify_stmt() decomposes expression into {x[0], +, 4}_1 and
4. These two are summed in chrec_fold_plus() in tree-chrec.c to the final
{x[1], +, 4}_1 expression.
This results in:
struct FooD.1649 xD.1666[4];
intD.2 D.1669;
struct FooD.1649 * D.1668;
ivtmp.24D.1709_11 = (unsigned intD.6) xD.1666[1];
# BLOCK 3 freq:8000
...
MEM[index: ivtmp.24D.1709_9, offset: 0x0fffc]{D.1668-sD.1653} = 1;
ivtmp.24D.1709_10 = ivtmp.24D.1709_9 + 4;
...
and on i686:
leal-12(%ebp), %eax
leal4(%ebp), %edx
.L2:
movl$1, -4(%eax)
addl$4, %eax
cmpl%edx, %eax
jne .L2
...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26726
[Bug target/26726] -fivopts producing out of bounds array refs
--- Comment #15 from pinskia at gcc dot gnu dot org 2007-06-04 05:36
---
One should note that:
/* { dg-final { scan-tree-dump-not offset: -4B ivopts { xfail i?86-*-*
x86_64-*-* } } } */
Will not match any more since switching over offset to sizetype.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26726
[Bug target/26726] -fivopts producing out of bounds array refs
--- Comment #14 from uros at kss-loka dot si 2006-05-13 08:46 --- (In reply to comment #13) This is now a target specific problem, on i?86 and x86_64 we are left with an offset of -4B and so referencing a[5] in the exit condition. This is PR target/24669. -- uros at kss-loka dot si changed: What|Removed |Added BugsThisDependsOn||24669 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26726
[Bug target/26726] -fivopts producing out of bounds array refs
--- Comment #13 from rguenth at gcc dot gnu dot org 2006-05-01 15:09 --- This is now a target specific problem, on i?86 and x86_64 we are left with an offset of -4B and so referencing a[5] in the exit condition. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|tree-optimization |target GCC target triplet||i?86-*-* x86_64-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26726
