Forums

Bug in latest IAR MSP430 compiler optimization???

Started by larwe April 27, 2008
On Apr 28, 12:24=A0pm, Mark Borgerson <mborger...@comcast.net> wrote:

> I'm not sure that someone qualified to write good embedded > code for the MSP430 is also qualified to patch the code > generator of mspgcc.
I've only known two people that had real professional level understanding at both ends of the spectrum, to the degree where I would feel comfortable hiring them for either role. Both of those people are, incidentally dead. I've patched XFree86 and Linux and a couple of other major major projects, but I never even felt the slightest desire to dabble in gcc's sources. Wouldn't consider it, in this case. It would be a situation of making the furnace to smelt the iron to make the hammer to bang in the nail.
larwe wrote:
> I've only known two people that had real professional level > understanding at both ends of the spectrum, to the degree where I > would feel comfortable hiring them for either role. Both of those > people are, incidentally dead.
I hope that's not an occupational hazard for such people, because I've done both these things :-).
On 2008-04-28, Mark Borgerson <mborgerson@comcast.net> wrote:

>>> Of course, last time I was working with a bought version of >>> their compiler, and found a [different] bug, the answer was >>> "buy the latest upgrade". >> >> Um, that's pretty much how commercial software works. If you >> were using mspgcc, you could just fix the problem, submit the >> patch, and get on with your work. > > I'm not sure that someone qualified to write good embedded > code for the MSP430 is also qualified to patch the code > generator of mspgcc.
It's not that hard. I've done a few fixes and feature additions to gcc, binutils, and gdb. over the years. I can't claim to understand the whole of gcc, but it's not that hard to figure out enough of one part of it when you need to do something (I added support for --fdata-sections and -ffunction-sections to the H8 and MSP430 targets). I'd been using those features on ARM targets for ages, and found them to be an indispensable way to provide encapsulation and information-hiding without sacrificing build granularity.
> I've written a lot of embedded code for the MSP430 and other > embedded systems, but I've never even LOOKED at the source for > the code generator of any compiler!
Try it sometime. :) -- Grant Edwards grante Yow! Where's SANDY DUNCAN? at visi.com
On Apr 28, 6:44=A0pm, Clifford Heath <n...@spam.please.net> wrote:

> > would feel comfortable hiring them for either role. Both of those > > people are, incidentally dead. > > I hope that's not an occupational hazard for such people, because > I've done both these things :-).
I believe it's an occupational hazard for every living person, so watch out :)
Chris H wrote:
> In message <MPG.227f99fe4c3cef81989841@newsgroups.comcast.net>, Mark > Borgerson <mborgerson@comcast.net> writes >> In article <GLSdnZPTPfSDQYjVnZ2dnUVZ_t3inZ2d@visi>, grante@visi.com >> says... >>> Um, that's pretty much how commercial software works. If you >>> were using mspgcc, you could just fix the problem, submit the >>> patch, and get on with your work. >> >> I'm not sure that someone qualified to write good embedded >> code for the MSP430 is also qualified to patch the code >> generator of mspgcc. > > I would agree... most only think they are. >
It depends on the level you are looking at. There are plenty of parts of gcc which are easy to follow if you want to poke around and maybe do some minor changes. Doing something major, like a new target port, is a much bigger challenge, and there are parts of gcc where even veteran gcc developers fear to tread. Being open source does not automatically make it *practical* for end-users to fix or enhance the code. But it makes it *possible*. That gives you a sort of insurance policy - it might cost you time and money to get the fixes done yourself, but you always have the option.
larwe wrote:
> Has anyone else observed that the latest kickstart MSP430 compiler > from IAR has an extremely serious code generation bug when configured > with optimizations=high,size? > > IAR C/C++ Compiler for MSP430 > V4.10E/W32 [Kickstart] (4.10.5.3) > C:\Program Files\IAR Systems\Embedded Workbench 5.0\430\bin\icc430.exe > 2/15/2008 11:03:06 AM, 15015936 bytes > > I have a test case that demos the problem perfectly, but it's tied to > specific hardware. The symptom is that a pointer, if declared locally, > is being sent off into random-land after one iteration of a loop. If > the same declaration is moved out into global scope, or if > optimization is turned off, the problem disappears. Target is > MSP430F2012. > > I haven't yet groveled through the assembly output to see exactly what > the difference between the two output flavors is. But this is such an > astoundingly show-stopping bug I'm appalled it escaped.
Are you going to give us a clue as to what this bug is? Until you post something more concrete, this is merely FUD. But if it is a real bug, boil it down to some minimal test code and post the code, the compiler options, and the generated assembly. That way we can guess if it is a compiler bug, or a source code bug.
On 27 Apr, 13:56, larwe <zwsdot...@gmail.com> wrote:
> Has anyone else observed that the latest kickstart MSP430 compiler > fromIARhas an extremely serious code generation bug when configured > with optimizations=high,size? > > IARC/C++ Compiler for MSP430 > V4.10E/W32 [Kickstart] (4.10.5.3) > C:\Program Files\IARSystems\Embedded Workbench 5.0\430\bin\icc430.exe > 2/15/2008 11:03:06 AM, 15015936 bytes > > I have a test case that demos the problem perfectly, but it's tied to > specific hardware. The symptom is that a pointer, if declared locally, > is being sent off into random-land after one iteration of a loop. If > the same declaration is moved out into global scope, or if > optimization is turned off, the problem disappears. Target is > MSP430F2012. > > I haven't yet groveled through the assembly output to see exactly what > the difference between the two output flavors is. But this is such an > astoundingly show-stopping bug I'm appalled it escaped.
This is not a problem that I recognize. However, I could take a look at it, but I would need a small, stand-alone, example that demonstrates what you think is the problem. -- Anders Lindgren, IAR Systems, author of the MSP430 compiler -- Disclaimer: Opinions expressed in this posting are strictly my own and not necessarily those of my employer.
In article <4816d0fb$0$23816$8404b019@news.wineasy.se>, 
david@westcontrol.removethisbit.com says...
> larwe wrote: > > Has anyone else observed that the latest kickstart MSP430 compiler > > from IAR has an extremely serious code generation bug when configured > > with optimizations=high,size? > > > > IAR C/C++ Compiler for MSP430 > > V4.10E/W32 [Kickstart] (4.10.5.3) > > C:\Program Files\IAR Systems\Embedded Workbench 5.0\430\bin\icc430.exe > > 2/15/2008 11:03:06 AM, 15015936 bytes > > > > I have a test case that demos the problem perfectly, but it's tied to > > specific hardware. The symptom is that a pointer, if declared locally, > > is being sent off into random-land after one iteration of a loop. If > > the same declaration is moved out into global scope, or if > > optimization is turned off, the problem disappears. Target is > > MSP430F2012. > > > > I haven't yet groveled through the assembly output to see exactly what > > the difference between the two output flavors is. But this is such an > > astoundingly show-stopping bug I'm appalled it escaped. > > Are you going to give us a clue as to what this bug is? Until you post > something more concrete, this is merely FUD. But if it is a real bug, > boil it down to some minimal test code and post the code, the compiler > options, and the generated assembly. That way we can guess if it is a > compiler bug, or a source code bug. >
More importantly, we can scan our own code to see if we have similar cases that might need work-arounds until the problem is resolved. Mark Borgerson
On Apr 29, 4:04=A0am, David Brown <da...@westcontrol.removethisbit.com>
wrote:

> Are you going to give us a clue as to what this bug is? =A0Until you post > something more concrete, this is merely FUD. =A0But if it is a real bug,
I don't have the code here at work, but the gist of it is that I have a subroutine which does something like this: void mysub(int a, int b) { const unsigned char *src, *tmpsrc; int i,j; src =3D pointer_to_const_data_struct; for (i=3D0;i<8;i++) { tmpsrc =3D src; // BAD LINE for (j=3D0;j<3;j++) { call_another_func(*(tmpsrc++),0); } // j-loop src +=3D 3; } // i-loop } // mysub [the reason for doing the arithmetic this way is because the code will have to support some more complicated cases in future - I realize there are other ways of doing the same thing]. As shown, built in maximum speed optimization mode, the code fails. The reason appears to be that on the second iteration through the i- loop, the value for "src" (which was in a register) got corrupted, probably during call_another_func(). Either of the following will fix the problem: - move the src declaration so it becomes a global variable, or - turn off speed optimization I can post the whole project somewhere if someone actually wants to look in detail. It's going to be public domain code anyway.
On Apr 27, 1:52 pm, larwe <zwsdot...@gmail.com> wrote:
> On Apr 27, 8:33 am, Chris H <ch...@phaedsys.org> wrote: > > > >I haven't yet groveled through the assembly output to see exactly what > > >the difference between the two output flavors is. But this is such an > > >astoundingly show-stopping bug I'm appalled it escaped. > > > What did IAR support say about it when you told them? > > Kickstart has no support. Of course, last time I was working with a > bought version of their compiler, and found a [different] bug, the > answer was "buy the latest upgrade".
I have found two bugs, one in each of the last two releases of their MSP430X compiler and on each occasion I have had a new version of the compiler sent to me with the bug fixed. These bugs then appear on the release notes for the next version published on the web-site. Where the problem was a code generation error then a short compilable example together with my compiler listing was all that was required to convince IAR that there was a problem and the corrected tools appeared a few days later. If the bug has been found and corrected in a more up to date version of the tools then the answer to get a legal (as defined in the vendor's licence agreement) copy of the newer toolset is the *right* answer. Ian