I opened the ticket:
https://sourceforge.net/p/mspgcc/bugs/357/
Thank you for your time.
Daniele
On Wed, Jul 3, 2013 at 5:20 PM, Peter Bigot <big...@acm.org> wrote:
> 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
