[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-gcc-list] Bit-field packing order changed between avrgcc implem
Re: [avr-gcc-list] Bit-field packing order changed between avrgcc implementations
Sun, 02 Dec 2012 19:09:58 +0100
Thunderbird 184.108.40.206 (Windows/20100228)
Juergen Harms schrieb:
Some weeks ago I finally replaced an outdated tarball-installed
version of avrgcc by an rpm installed recent version (avrgcc-4.7.2).
What AVR Libc does it use?
Surprisingly, this replacement brought a change of the bit-field
packing order (my application is a distributed system with AT90CAN
Would you be more specific, e.g. provide a test case that shows this?
With the following C code
unsigned b0 :1;
unsigned b1 :1;
unsigned b2 :1;
unsigned b3 :1;
unsigned b4 :1;
unsigned b5 :1;
unsigned b6 :1;
unsigned b7 :1;
void f1 (void)
b.b7 = 1;
the compilation result in foo.s is
if compiled with 4.7.2 as
$ avr-gcc -c foo.c -Os -mmcu=atmega88 -save-temps
which shows that .b7 ob struct b is accessed as bit 7. Same with 4.8.0.
With 4.6, 4.5, 4.3 and 3.4, for example, the code is the same but just
printed in a slightly different way:
Moreover, the generated code is the same if struct b is packed.
nodes; the limited length of CAN messages forces me to use some
packed structures in the communication between nodes). With some
nodes having been compiled before the change, some after, the
consequences are evident.
Where is the evidence? Please show a test case. You can work out a
minimal test case that can be compiled by others, i.e. does not refer to
headers. The test needs not to link like in my example above.
Or you can compile you code with -save-temps and attach the precompiled
C source *.i. This also can be compiler by others.
Moreover, it is helpful to see what the compiler prints if -v is added
while your code is compiled (shows host OS, subcommands, options,
My internode protocol is carefully designed to allow maximum
independence of node software evolution - but I now realise that the
bit-field packing order is an implicit part of this protocol. The
standards are clear that this is implementation and platform
dependant. I nevertheless want to continue using the ease of
Even thought it is implementation defined, the implementation is not
supposed to be changed arbitrarily or without notifying the users in the
compiler-supported packing/unpacking - I am ready to bet on changes
occuring very unfrequently and live with this risk, but with added
Because the layout has not be changed in the compiler, and by test case
examples shows this, your problem is somewhere else.
Question: can somebody suggest some way to tell - say when running
make - what packing order has been used and to detect if a change has
happened? Otherwise I need to implement a run-time test that strikes
at node initialisation (for various reasons way beyond second-best).
When you port your CAN stuff to a new platform and need to factor out
endianess, you can compile and run a small test.
Or you can factor out the compiler / target platform. For avr-gcc a
test could be
#if defined __GNUC__ && defined __AVR__
/* Code for avr-gcc */
/* Code for other compilers than avr-gcc */
Notice that there are fake-GCC compilers like LLVM that define __GNUC__
even though LLVM is not GCC.