In message 001501c5499f$f5364750$1780a8c0@art you wrote:
If this is really true, then there is either bug in GCC or in the code. If I code a 32 bit access the compiler must not use any other accesses.
If you use __attribute__ ((packed)), you are telling the compiler you have an unaligned data structure (e.g. longs not by-4 aligned). Therefore, GCC will always reassemble the 32-bit value from byte accesses.
You are wrong, with both of your statements.
-> cat foo.c struct foo { unsigned long foo1; unsigned long foo2; unsigned long foo3; } __attribute__ ((packed));
unsigned long dummy (struct foo *p) { return (p->foo1 + p->foo2 + p->foo3); }
Test 1: PowerPC:
-> ppc_8xx-gcc -O -S foo.c -> cat foo.s ... dummy: mr 9,3 lwz 3,0(3) lwz 0,4(9) add 3,3,0 lwz 0,8(9) add 3,3,0 blr
Test 2: MIPS:
-> mips_4KC-gcc -O -S foo.c -> cat foo.s ... dummy: .frame $sp,0,$31 # vars= 0, regs= 0/0, args= 0, extra= 0 .mask 0x00000000,0 .fmask 0x00000000,0 .set noreorder .cpload $25 .set reorder ulw $2,0($4) ulw $3,4($4) #nop addu $2,$2,$3 ulw $3,8($4) .set noreorder .set nomacro j $31 addu $2,$2,$3 .set macro .set reorder
As you can see, GCC alway uses plain word accesses (32 bit).
__attribute__ ((packed)) is telling the compiler that IN CASE of unaligned fields in the structure no padding should be performend, which will then result in unaligned fields that may cause access problems on certain architectures.
If a compiler is generating byte accesses instead (especially if the relevant data has been declared as volatile) then this compiler is broken.
Yes, I know that some versions of ARM compilers behave like that. But the fact that they do does not mean that they are correct. Accessing a (volatile) long variable though 4 byte accesses is a bug.
Period.
Best regards,
Wolfgang Denk