evil alias rule strikes again

[Kate Feng]

Till Straumann wrote:

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

I really do not see this as an evil b/c I have seen the worst. :-)
I think most people are using -fno-strict-aliasing except
it is forgotten to be updated  in the release,
where all the makefile are for the BSP (e.g. make/custom).
The make/custom is not where each BSP is.  Thus it is easy
to be ignored.  However, the compiling warning message
without the -fno-strict-aliasing option could be so ugly that
one could simply update  the makefile for the system
without thinking.

I had a look at the mvme5500.cfg and found out that
I have been using the -fno-strict-aliasing option.  However,
it was not updated in the CVS.  I will submit a PR
for the mvme5500.cfg.  However, this does not imply
that -fno-strict-aliasing will solve all alias problems.

Kate

>
>
> 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
>
>------------------------------------------------------------------------
>
>#include <stdint.h>
>
>/* This is from <libcpu/byteorder.h>; type was changed 
> * recently changed (vers. 1.6 -> 1.7)
> *
> * from
> *   volatile unsigned * 
> * to
> *   volatile uint32_t *
> *
> */
>
>static inline void st_le32(volatile uint32_t *a, unsigned v)
>{
>  __asm__ __volatile__ ("stwbrx %1,0,%2" : "=m" (*a) : "r" (v), "r" (a));
>}
>
>/* Some Driver defines inline function for swapping to LE */
>static inline uint32_t
>swp32(uint32_t v)
>{
>unsigned rval __attribute__((may_alias));
>/* Change of types in byteorder.h introduces
> * violation of alias rule here; compiler assumes
> * unsigned cannot alias uint32_t
> */
>	st_le32((volatile uint32_t*)&rval,v);
>	return rval;
>}
>
>void test(uint32_t *buf)
>{
>	buf[0] = swp32(0);
>	/* Gcc assumes pointer passed to st_le32() cannot't alias
>	 * 'rval' above and therefore it stores a cached value
>	 * in buf[1].
>	 */
>	buf[1] = swp32(1);
>	/*
>	00000000 <test>:
>		0:   94 21 ff e8     stwu    r1,-24(r1)
>		4:   38 00 00 00     li      r0,0
>		8:   39 21 00 08     addi    r9,r1,8
>		c:   7c 00 4d 2c     stwbrx  r0,0,r9
>		10:   81 61 00 08     lwz     r11,8(r1)
>		14:   38 00 00 01     li      r0,1
>		18:   91 63 00 00     stw     r11,0(r3)
>		1c:   7c 00 4d 2c     stwbrx  r0,0,r9
>		20:   38 21 00 18     addi    r1,r1,24
>		24:   91 63 00 04     stw     r11,4(r3)
>		28:   4e 80 00 20     blr
>
>	which corresponds to
>
>	  rval = bytereverse(0)
>	  buf[0] = rval;
>	  buf[1] = rval;
>	  rval = bytereverse(1)
>
>	*/
>}
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>rtems-users mailing list
>rtems-users at rtems.com
>http://rtems.rtems.org/mailman/listinfo/rtems-users
>  
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20071108/83f42e01/attachment-0001.html>