Re: ARM compiler misbehaves ?

[Grant Edwards <grante at visi dot com>]

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