http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55162
Oleg Endo <olegendo at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pinskia at gcc dot gnu.org
--- Comment #3 from Oleg Endo <olegendo at gcc dot gnu.org> 2012-11-02 10:07:26
UTC ---
(In reply to comment #2)
> >For example, passing a virtual address 0x00001000 and c = 0x80000000 to the
> function should actually run over the address range 0x00001000 .. 0x80001000,
>
>
> No it runs over the address range 0x00001000 .. -1 and more as 0x80000000 * 4
> wraps/overflows. If x was char* then I would say there is a bug but this is
> int* which has a size of 4.
Ugh, sorry for the mess up. Of course you're right.
I guess that the pointer wrap-around would fall into "undefined behavior"
category. If so, then the loop counter adjustment could be left out entirely,
couldn't it?
My point is that the loop counter adjustment can become quite bloaty on SH:
struct X
{
int a, b, c, d, e;
};
int test (X* x, unsigned int c)
{
int s = 0;
unsigned int i;
for (i = 0; i < c; ++i)
s += x[i].b;
return s;
}
results in:
tst r5,r5
bt/s .L4
mov r5,r1
shll2 r1
add r5,r1
mov.l .L9,r2
shll2 r1
add #-20,r1
shlr2 r1
mul.l r2,r1
mov.l .L10,r2
add #4,r4
mov #0,r0
sts macl,r1
and r2,r1
add #1,r1
.L3:
mov.l @r4,r2
dt r1
add #20,r4
bf/s .L3
add r2,r0
rts
nop
.L4:
rts
mov #0,r0
.L11:
.align 2
.L9:
.long 214748365
.L10:
.long 1073741823
