On 15 February 2011 21:46, JMGross <[email protected]> wrote:
>
> Well, in this case, it IS a bug.
> I wonder why this was never noticed before.
>
Well, I guess it was, since it is fixed in mspgcc4.
> I tried several variations. if you have a multiplication in between that
> does not use the 100
Actually, that was my workaround, and it worked once, then failed soon
after! So my workaround is more elaborate now (multiplying by 50 and
shifting the result left by 1). I know that sounds like it should not fix
the problem if any other multiplication by another constant doesn't work,
but for now it does.
> or if 100 is not a constant, all is well. But it does not matter whether
> you swap the parameters.
>
Yes, swapping the parameters was my first workaround, and didn't work as you
have observed.
> It seems that either the logic that 'optimizes' the multiplication confuses
> OP2 and MPY (MPY could be the one with a constant value across several
> multiplications), or it is missing the 'volatile' information for the
> optimizer. I bet it is the first one, as it is more difficult to fix :)
>
I believe it's the volatile information. Murphy (of Murphy's law fame) must
have had a day off.
> So yes, it is definitely a bug, and a nasty one too.
>
Well, the latest version of mspgcc4 is out. I need to find some time to
build it, to verify that it fixes both this multiply bug, and the interrupt
vector locations. The latter is the reason I couldn't just switch to
mspgcc4.
- Mike
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Mspgcc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
