Re: [avr-gcc-list] Bit-field packing order changed between avrgcc implementations

[Georg-Johann Lay]

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

struct
{
    unsigned b0 :1;
    unsigned b1 :1;
    unsigned b2 :1;
    unsigned b3 :1;
    unsigned b4 :1;
    unsigned b5 :1;
    unsigned b6 :1;
    unsigned b7 :1;
} b;

void f1 (void)
{
    b.b7 = 1;
}

the compilation result in foo.s is

f1:
        lds r24,b
        ori r24,lo8(1<<7)
        sts b,r24
        ret

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:

f1:
        lds r24,b
        ori r24,lo8(-128)
        sts b,r24

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, 
version, etc.)

> 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 
release notes.

> compiler-supported packing/unpacking - I am ready to bet on changes
> occuring very unfrequently and live with this risk, but with added
> control.

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 */
#else
/* Code for other compilers than avr-gcc */
# endif

Notice that there are fake-GCC compilers like LLVM that define __GNUC__ 
even though LLVM is not GCC.


Johann