It's not clearly wrong if the type of
gSlaTxFrame.payloadPtr[gSlaTxFrame.pos] is char (and r14 holds the current
value of "word"). Unlike IAR, unqualified "char" in mspgcc is signed.
This is consistent with how GCC treats unqualified char on most targets.
If that's not the problem, you'll need to provide a reduced and
reproducible test case.
Peter
On Fri, Feb 8, 2013 at 2:22 PM, Robert Henig <rhe...@redwoodsys.com> wrote:
> I have this line of code:
>
> word |= gSlaTxFrame.payloadPtr[gSlaTxFrame.pos];
>
> In the debug it disassembles to:
>
> => 0x0000da54 <+224>: add r12, r15
> 0x0000da56 <+226>: mov.b @r15, r15
> 0x0000da58 <+228>: sxt r15
> 0x0000da5a <+230>: bis r14, r15
> 0x0000da5c <+232>: mov r15, 0(r1) ;0x0000(r1)
>
> The stx instruction is clearly wrong and should not be there.
>
> I use the -Os option on the compile.
>
> Is this a know bug? Is there a patch?
>
> Thanks,
> Bob.
>
>
> ------------------------------------------------------------------------------
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013
> and get the hardware for free! Learn more.
> http://p.sf.net/sfu/sophos-d2d-feb
> _______________________________________________
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
