Bug in latest IAR MSP430 compiler optimization???

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&#4294967295;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     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/