Thanks for the ticket and the reproducing code. I've attached to the
ticket a (second attempt at a) patch that I believe fixes this. It has not
undergone significant testing but I'll be using it in my own work.
Those of you playing along at home might find the patch attached to
https://sourceforge.net/p/mspgcc/bugs/352/ useful as well. They are to the
20120911 development release, and are unsupported, but are most of what
would have qualified as patches if that were an LTS release. If you apply
them and build a system, please update the version number in some way so
you're reminded they're not standard builds.
Sorry, I don't provide instructions or support for applying patches to
mspgcc.
Peter
On Wed, Jul 3, 2013 at 11:38 AM, Daniele Alessandrelli <
daniele.alessandre...@gmail.com> wrote:
> 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
