[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Georg-Johann Lay
Subject: Re: [avr-gcc-list] Bit-field packing order changed between avrgcc implementations
Date: Sun, 02 Dec 2012 19:09:58 +0100
User-agent: Thunderbird (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;
} b;

void f1 (void)
    b.b7 = 1;

the compilation result in foo.s is

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

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:

        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

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 */
# endif

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]