Re: msp430-gcc 4.7 bug with shifts?

Peter Bigot <[email protected]>
Newsgroups gmane.comp.hardware.texas-instruments.msp430.gcc.user
Message-ID <CAPOJ94OoqDnB17h282SzkX-mkr8NGgLrA0cW6pi+girPwv5SJA@mail.gmail.com>
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 <
[email protected]> 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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.