evil alias rule strikes again

[Till Straumann]

Today, I was again hit by the alias rule when a driver
stopped working.

I have a driver which uses

#include <libcpu/byteorder.h>

/* Driver defines helper inline function for swapping to LE */

static inline uint32_t
swp32(uint32_t v)
{
unsigned rval;
    st_le32(&rval,v);
    return rval;
}

and the driver then does things, simplified:

void test(uint32_t *buf)
{
   buf[0] = swp32(0xdeadbeef);
   buf[1] = swp32(0xcafecafe);
}


However, recently Ralf changed byteorder.h so that st_le32 is no
longer

static inline void st_le32( volatile unsigned *a, unsigned v);

but it is now

static inline void st_le32( volatile uint32_t *a, unsigned v);

which introduces a violation of the alias rule into 'swp32'.
The compiler now may assume that st_le32 does not modify
'rval' above because according to the alias rule
the pointer argument to st_le32 must not alias 'rval'
since rval is unsigned and the pointer
is a pointer to uint32_t which are incompatible.

Indeed, gcc-4.2.2 does use that assumption (it warns about
incompatible pointer types but gives no type-punnning warning).

Just another example for how a small change (in this case:
to the byteorder.h header) can have big effects that are
hard to track down.

How many more of these incidents do we need to convince
you to use -fno-strict-aliasing (linux uses it) ?

More detailed description attached...

-- Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xxx.c
Type: text/x-csrc
Size: 1436 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/users/attachments/20071107/464ce6a9/attachment.bin>