That looks like a bug.  Only happens on CPUX architectures.  If you open up
a ticket on https://sourceforge.net/p/mspgcc/bugs/ I may be able to look at
it some time.

Peter


On Wed, Jul 3, 2013 at 7:37 AM, Daniele Alessandrelli <
daniele.alessandre...@gmail.com> wrote:

> Hi everybody,
>
> I noticed a strange behavior when executing certain shift operations and I
> wonder whether this is because of a compiler bug or just my ignorance in
> low-level C.
>
> For example, when compiling (with no optimization) and then executing the
> following lines of code the result I obtain is 16 instead of 64:
>
> uint32_t  u32_var;
>
> int main(void)
> {
>     int tmp;
>     ...
>     u32_var = 0xa;
>     tmp = 16 << (u32_var & 0x07);
>     printf("tmp: %d\n", tmp);
>     ...
> }
>
> However, if I change the type of tmp form "int" to "unsigned int" the
> result is correct (i.e., 64).
>
> This is assembly code generated when tmp is defined as int (i.e., when the
> result is wrong).
>
>     5c44:       b2 40 0a 00     mov     #10,    &0x1c02 ;#0x000a
>
>     5c48:       02 1c
>
>     5c4a:       82 43 04 1c     mov     #0,     &0x1c04 ;r3 As==00
>
>     5c4e:       1e 42 02 1c     mov     &0x1c02,r14
>
>     5c52:       1f 42 04 1c     mov     &0x1c04,r15
>
>     5c56:       0f 4e           mov     r14,    r15
>
>     5c58:       3f f0 07 00     and     #7,     r15     ;#0x0007
>
>     5c5c:       3e 40 10 00     mov     #16,    r14     ;#0x0010
>
>     5c60:       4f 4f           mov.b   r15,    r15
>
>     5c62:       7f f0 0f 00     and.b   #15,    r15     ;#0x000f
>
>     5c66:       84 4e fc ff     mov     r14,    -4(r4)  ;0xfffc(r4)
>
>     5c6a:       4f 93           tst.b   r15
>
>     5c6c:       03 24           jz      $+8             ;abs 0x5c74
>
>     5c6e:       7f 53           add.b   #-1,    r15     ;r3 As==11
>
>     5c70:       cf 18 0e 5e     .rpt    r15
>
>                                 addx    r14,    r14
>
>     5c74:       14 12 fc ff     push    -4(r4)          ;0xfffc(r4)
>
>     5c78:       30 12 9a 66     push    #26266          ;#0x669a
>
>     5c7c:       b0 12 ae 5c     call    #0x5cae
>
>
> As you can see, at address 0x5c66, register 14 (containing 16) is stored in
> memory before being shifted. The stored valued (i.e., 16) is then pushed in
> the stack (i.e., passed as an argument to the printf() function).
>
> I have a similar problem also when using -Os, but I can't replicate it with
> simple code because of the optimization. However, if needed, I can post the
> (large) source code that is giving me this problem.
>
> The version of msp430-gcc that I am using is:
> msp430-gcc (GCC) 4.7.0 20120322 (mspgcc dev 20120911)
>
> Thank you for any help you can provide.
>
> Regards.
>
> Daniele
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
>
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Reply via email to