ARM compiler misbehaves ?
Grant Edwards
grante@visi.com
Thu Apr 29 15:02:00 GMT 2004
On Thu, Apr 29, 2004 at 03:34:33PM +0100, Richard Earnshaw wrote:
> None of them. I was referring to the statement:
>
> > Actually, I'm pretty sure it is guaranteed to work as long as the
> > compiler can see the "packed" attribute during compilation (if it
> > couldn't, that would be a serious structural problem in your source
> code!).
>
> Which claimed it should work. It doesn't, and isn't intended to.
It does too.
I just checked on the H8
------------------------------source file------------------------------
struct mine
{
char c;
short int s;
} __attribute__((packed));
struct mine s;
short foo(void)
{
return s.s;
}
void bar(short v)
{
s.s = v;
}
------------------------------source file------------------------------
Here's the code:
00000000 <_foo>:
struct mine s;
short foo(void)
{
return s.s;
0: 6a 08 00 00 6a 08 00 00 mov.b @0x0:16,r0l
4: f0 00 f0 00 mov.b #0x0,r0h
6: 6a 0a 00 00 6a 0a 00 00 mov.b @0x0:16,r2l
a: 14 a0 14 a0 or.b r2l,r0h
}
c: 54 70 54 70 rts
0000000e <_bar>:
void bar(short v)
{
s.s = v;
e: 6a 80 00 00 6a 80 00 00 mov.b r0h,@0x0:16
12: 6a 88 00 00 6a 88 00 00 mov.b r0l,@0x0:16
}
16: 54 70 54 70 rts
Notice how the compiler generates byte moves to store and read
the value of the packed 16-bit integer field?
Here's the same thing without the packed attribute:
00000000 <_foo>:
short foo(void)
{
return s.s;
}
0: 6b 00 00 00 6b 00 00 00 mov.w @0x0:16,r0
4: 54 70 54 70 rts
00000006 <_bar>:
void bar(short v)
{
s.s = v;
6: 6b 80 00 00 6b 80 00 00 mov.w r0,@0x0:16
}
a: 54 70 54 70 rts
This time it used word moves.
I'm pretty sure the same thing happens for the ARM, but my arm
tools are on my other computer. I can verify that for you
later today if you like.
> No, even that isn't guaranteed, since the compiler is entitled
> to "know" the implementation of memcpy, and therefore to
> implement it inline.
Eh? memcpy() isn't guaranteed to work for any alignemnt of
source and dest?
--
Grant Edwards
grante@visi.com
------
Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com
More information about the crossgcc
mailing list