Forums

Bug in latest IAR MSP430 compiler optimization???

Started by larwe April 27, 2008
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.
In message 
<1b8713e7-1edf-401c-a4b2-58e36e20d72b@s33g2000pri.googlegroups.com>, 
larwe <zwsdotcom@gmail.com> writes
>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.
What did IAR support say about it when you told them? -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
On Apr 27, 8:33=A0am, 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".
In message 
<4e894752-5193-471a-8ef3-1e1aa8c12b67@w5g2000prd.googlegroups.com>, 
larwe <zwsdotcom@gmail.com> writes
>On Apr 27, 8:33&#2013266080;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 not it is a FREE size limited eval version. However that does not mean you can't report bugs to the support team. Why wouldn't you?
>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".
Because you had a very old version (IAR compilers have 12 months support) and they had fixed the bug in a later version. It would only be "buy" a new version if you were out of support. Which you would be or you would have got the update for free. You do like trying to make mountains out of molehills. If you find a bug in ANY compiler (not just IAR) that is fixed in a newer version they tell you to get the latest version. If you are on support it is usually free. You only have to pay if it is a very old version. However if you want to use an old version that is your look out. -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

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? > > 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.
I am not particularly familiar with IAR for MSP430, however I have seen several times that the IAR for AVR can loose a local variable if the function is complex enough and the optimization is set to maximum. Declaring this variable as static helps.
> 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.
Why are you so astounded? *Every* C/C++ compiler that I ever worked with did have bugs. If one doesn't see any bugs in compiler, that simply means that he haven't yet done any serious projects with it. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com

Chris H wrote:


> If you find a bug in ANY compiler (not just IAR) that is fixed in a > newer version they tell you to get the latest version.
Sure. The latest version of compiler with the fresh not yet known bugs. Porting a working project to the next revision of a compiter is PITA.
> If you are on > support it is usually free. You only have to pay if it is a very old > version. > However if you want to use an old version that is your look out.
Yes, this is one of the problems. They can't make money from just making bug fixes to the current software, so they have to release new versions. There is a phylosophycal principle: "It is better to be the first, then to be the best". I wonder if it is a universal law or just a current direction of the development of the civilization. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
In message <wC1Rj.3626$26.1421@newssvr23.news.prodigy.net>, Vladimir 
Vassilevsky <antispam_bogus@hotmail.com> writes
>Chris H wrote: >> If you find a bug in ANY compiler (not just IAR) that is fixed in a >>newer version they tell you to get the latest version. >Sure. The latest version of compiler with the fresh not yet known bugs. >Porting a working project to the next revision of a compiter is PITA.
Then don't use a compiler.
>> If you are on support it is usually free. You only have to pay if >>it is a very old version. >> However if you want to use an old version that is your look out. >Yes, this is one of the problems. They can't make money from just >making bug fixes to the current software, so they have to release new >versions.
If you fix bugs in a compiler you get a new version. These are usually free in the first year after purchase as part of the compiler price. It cost money to do support and continue development. How would you fund it? Triple the cost of the compiler to start with to cover the ongoing work?
>There is a phylosophycal principle: "It is better to be the first, then >to be the best".
This does not apply to compilers. You seem to understand very little. The problem with compilers is that it is never ending. As you appear not to know silicon vendors fix and patch chips requiring changes to the compiler. Silicon vendors release new version and additions to the family requiring changes to the compiler. The C standard changes (frequently) requiring changes to the compiler and or the library. Then there are changes to the simulator and linker for many of the reasons above. Then there are changes to Windows that affect the whole system... Compiler development is an on going task. Not a 1 off release. I recall a customer complaining to me that he should have a free upgrade to a 6 year old compiler because it did not support a new part (with new memory system) that had just been released!
> I wonder if it is a universal law or just a current direction of the >development of the civilization.
It is a universal law of civilisation since the dawn of time. However most software tools tend to go for small changes and release often after the initial release. -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Chris H wrote:

> Chris H wrote: >> >>> If you find a bug in ANY compiler (not just IAR) that is fixed in a >>> newer version they tell you to get the latest version. >> >> Sure. The latest version of compiler with the fresh not yet known >> bugs. Porting a working project to the next revision of a compiter is >> PITA. > > Then don't use a compiler.
I prefer keeping the projects with the complete old toolchains and not to jump to the latest and greatest unless it is really required. If a compiler bug was spotted, then it is not dangerous any more.
> >>> If you are on support it is usually free. You only have to pay if >>> it is a very old version. >>> However if you want to use an old version that is your look out. >> >> Yes, this is one of the problems. They can't make money from just >> making bug fixes to the current software, so they have to release new >> versions. > > If you fix bugs in a compiler you get a new version.
If you fixed the bugs you only got a new build of the old version. By releasing the bug fixes you acknowledged that you can't get the things right at the first time, however the good thing is that you care. The new version should have a difference.
> These are usually > free in the first year after purchase as part of the compiler price. > > It cost money to do support and continue development. How would you fund > it? Triple the cost of the compiler to start with to cover the ongoing > work?
This is the problem of the compiler people, not mine. What point are you trying to make? I have no illusion that the compiler development is different from any other sw development. Same kind of lousy and pitifull business.
> >> There is a phylosophycal principle: "It is better to be the first, >> then to be the best". > > This does not apply to compilers. You seem to understand very little. > The problem with compilers is that it is never ending. > > As you appear not to know silicon vendors fix and patch chips requiring > changes to the compiler. Silicon vendors release new version and > additions to the family requiring changes to the compiler. The C > standard changes (frequently) requiring changes to the compiler and or > the library. Then there are changes to the simulator and linker for > many of the reasons above.
The life is hard. Is that what you are trying to prove?
> Then there are changes to Windows that affect the whole system...
Sure. Let's blame Bill Gates for everything.
> Compiler development is an on going task. Not a 1 off release. I recall > a customer complaining to me that he should have a free upgrade to a 6 > year old compiler because it did not support a new part (with new memory > system) that had just been released!
Not my problem.
>> I wonder if it is a universal law or just a current direction of the >> development of the civilization. > > It is a universal law of civilisation since the dawn of time. > > However most software tools tend to go for small changes and release > often after the initial release.
Oh well. I'd better go join the linuxopaths with their GCC... Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
Vladimir Vassilevsky wrote:
> > > Chris H wrote: > >> Chris H wrote: >>> >>>> If you find a bug in ANY compiler (not just IAR) that is fixed in a >>>> newer version they tell you to get the latest version. >>> >>> Sure. The latest version of compiler with the fresh not yet known >>> bugs. Porting a working project to the next revision of a compiter is >>> PITA. >> >> Then don't use a compiler. > > I prefer keeping the projects with the complete old toolchains and not > to jump to the latest and greatest unless it is really required. If a > compiler bug was spotted, then it is not dangerous any more. > >> >>>> If you are on support it is usually free. You only have to pay if >>>> it is a very old version. >>>> However if you want to use an old version that is your look out. >>> >>> Yes, this is one of the problems. They can't make money from just >>> making bug fixes to the current software, so they have to release new >>> versions. >> >> If you fix bugs in a compiler you get a new version. > > If you fixed the bugs you only got a new build of the old version. By > releasing the bug fixes you acknowledged that you can't get the things > right at the first time, however the good thing is that you care. The > new version should have a difference. > >> These are usually free in the first year after purchase as part of the >> compiler price. >>
There's a difference here between what is often termed "updates" and "upgrades". An "upgrade" means a new versions of the tool, typically with new features, and is something you can only expect to get while on a support contract of some kind. You don't "upgrade" the tools you use for a project without good reason, and when a project is finished, you keep track of the tool versions used in its development. "updates" (or "service packs"), on the other hand, are minor changes - often bug fixes, but occasionally small additional changes (perhaps support for a new chip variant). They are usually safe to use without changing your project, and are often freely available to any licensed user. Thus changing from gcc 4.2.2 to gcc 4.3.0 is an upgrade, and may require changes to the project. Changing to 4.2.3 is merely an update to fix a couple of bugs. It is not unreasonable to expect a compiler supplier to provide updates for a certain time after purchase - you should not have to upgrade just to get a bug fix. (Note that I have no idea what IAR's policy is in this - I'm just expressing general comments.)
In message <Qi3Rj.658$To6.320@newssvr21.news.prodigy.net>, Vladimir 
Vassilevsky <antispam_bogus@hotmail.com> writes
> > >Chris H wrote: > >> Chris H wrote: >>> >>>> If you are on support it is usually free. You only have to pay >>>>if it is a very old version. >>>> However if you want to use an old version that is your look out. >>> >>> Yes, this is one of the problems. They can't make money from just >>>making bug fixes to the current software, so they have to release new >>>versions. >> If you fix bugs in a compiler you get a new version. > >If you fixed the bugs you only got a new build of the old version.
No it is a new version
>> These are usually free in the first year after purchase as part of >>the compiler price. >> It cost money to do support and continue development. How would you >>fund it? Triple the cost of the compiler to start with to cover the >>ongoing work? > >This is the problem of the compiler people, not mine. What point are >you trying to make? I have no illusion that the compiler development is >different from any other sw development. Same kind of lousy and >pitifull business.
So your software development is a "lousy and pitiful business" and you judge all the rest by your standards? -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/