This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ARM memcpy on unaligned pointers and -O2


> I believe I've found a bug in GCC 3.0.2 wrt the ARM target and -O2 
> optimisation. I found it when I wrote the following functions to load and 
> store unaligned pointers. This is the objdump -S output.
> 
> /**
>  * unaligned load
>  */
> uint32
> ld32( const uint32* p)
> {
>         uint32 ret;
>         memcpy( &ret, p, sizeof( ret));
>   90:   e5900000        ldr     r0, [r0]
>         return ret;
>   94:   e1a0f00e        mov     pc, lr
> }
> 
> /**
>  * unaligned store
>  */
> void
> str32( uint32* p, uint32 val)
> {
>         memcpy( p, &val, sizeof( *p));
>   98:   e5801000        str     r1, [r0]
>   9c:   e1a0f00e        mov     pc, lr
> }
> 
> 
> As you can see this did not have the intended effect. GCC recognised the 
> length of the memcpy as being constant and optimised it away to a simple ldr 
> or str instruction. What it doesn't seem to have taken into account though, 
> is the fact that the pointer it's passed may not be aligned. I believe it's 
> allowed to pass unaligned pointers to memcpy and the compiler should 
> handle it correctly.
> 

No, your pointer is aligned.  You declared it to be so in the declarations 
of your functions.  Having done this, the compiler can and does use this 
knowledge to optimise the code.

R.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]