This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |