Bug in latest IAR MSP430 compiler optimization???

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.

Try it sometime. :)

I believe it's an occupational hazard for every living person, so watch out :)

I hope that's not an occupational hazard for such people, because I've done both these things :-).

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.

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.

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.

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

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

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

It is interesting that Lewin apparently NEVER gets this sort of service out of any compiler or silicon company. He has ranted at me several times when I say that the sort of help IAR have given you, as described above, is the norm. Actually it is the norm for most of the tools vendors.

Perhaps the problem is more with Leiwn's approach than anything else. After al his first action on finding a bug was to publicly attack IAR before even asking them for a response or a fix.

I note that elsewhere in this thread an IAR support person has asked Lewin for an example code to look at. It's not because he has made a fuss here either. It is because this is the fist time they have been made aware of it.

Thanks for the code, I managed to add some parts to the code to get it to compile. I can confirm that you indeed found a problem in the code generator. The cause was much more complex than you guessed, it contained a problem with register allocation, in the presence of post- inc:s and unrolling, where "tmpsrc" and "src" variables were placed in the same register, which clearly is wrong.

It has been assigned bug id EW20095, and it will be fixed in the V4.11A release which we are in the process of finishing. It will be available relatively soon.

Thanks for finding this problem!

-- Anders Lindgren, IAR Systems

-- Disclaimer: Opinions expressed in this posting are strictly my own and not necessarily those of my employer.

Any chance of posting the generated assembly for this? It should not be hard to follow, to see where the problem lies, if call_another_func is declared extern (to avoid it being inlined by the optimiser).

The problem has been found see below:-

In message , " snipped-for-privacy@gmail.com" writes

As Anders says it is not as simple as you might think. To fix something like this is more than a simple patch. Well the code may end up being a simple patch but the rigorous checking and cross checking required for side effects is substantial before you do full regression testing.

The tests compiler companies do are quite extensive. Usually one or both of Plum-Hall or Perennial plus several sets of in house test suites for things like maths, assembler etc

One thing all the compiler writers I know say is the problem is not in finding the bug but how to fix it with not putting more in. The level of testing required afterwards is out of the reach of most programmers.

So, with this level of testing how come something so serious got though the release process? Yes, I know, these things happen and another couple of tests are added to the validation suite.

Peter

In message , Peter Dickerson writes

Because with the number of variations and permutations both of the language and the optimisations it is always possible to miss things. It is interesting that "something so serious" and a "show stopping" bug has only been found by one person.

No one else has apparently reported it yet. So clearly it is not something everyone is doing or show stopping despite this compiler being used by many.

Also as you can see from Anders comment it was quite complex to do with register allocation when combined with post-incs and rollup. Not trivial at all even if the symptom appeared to be.

I knew you didn't understand. A basic OTPF Sets suite is about 70,000 tests. IAR use an industry standard test suite like this (that you don't edit or add a couple of tests to) and FOUR other extensive test systems they do edit. Quite apart from test compilations on a large set of benchmark programs. Most of which are large applications not benchmarks as such.

Compared to many other compilers IAR are very good at testing compilers and fixing any bugs.

So in short it was not an obvious problem. They found the cause within 24 hours of being notified They are rolling out an update with the fix in it

Any other compiler vendors that swift to respond on eval compilers with "no support" according to Lewin.

The problem is?

All I can see is Lewin started an unjustified rant against IAR because he doesn't like them. Had he reported the bug to them in the first place this would have been a non event.

We could look at the bug- fix- test- release cycle of other compilers to compare?

I was reading about a monumental bug in the way *some* GCC compilers handled "volatile". Now that is a show stopper.

So lets get things into perspective.

If I were evaluating a compiler and it failed in some bad way then I'd email the developers with example code then bin the tools or get my money back if any had exchanged hands by then.

You mean one person reported it here. Not the same thing. If I can't trust the tools then that's show stopping but others may be happy that it has an easy workaround or avoidance stratagy.

I am very happy that Anders put his hand up and said t'was me. Respect for that. I think it was loop unrolling he mentioned. Surely register allocation and even loop unrolling are standard bread-and-butter aspects of compilers. No they are not trivial but they are standard fare. Chris, you're the one who says how far behind gcc is V commercial compilers.

No, you think you knew that I didn't understand. In fact I've have had reason to communicate with the IAR compiler team in the past (for M16C62). It was some time ago and the outcome after the response from them was to bin the eval disk and avoid IAR. As I say, it was some time ago, maybe 2000, but they had been in business long enough by then to have known better. Perhaps now they do.

I would still prefer them to avoid releasing them...

Good. So they're learning.

Perhaps. As I said, I would have reported the bug and gone from there. However, if others on this group are using the same compiler and experiencing 'problems' then it might help them.

Have you got a link, because I'd certainly like to know about that. volatile is a bit of a can of worms for any compiler because what is required for standards conformance and what is required for customer acceptance in the embedded field are somewhat different.

Yes, lets.

peter

You'll end up binning them all in the end- there isn't a serious program in the world without some bug waiting in the depths. And you won't get your money back. Read the small print.

I am glad some one else said that. :-)

There are no compilers that are perfect. Some people are just determined to find fault and blow it up out of all proportion.

They still find fault even after a 24 hour response (despite the fault was not reported to IAR) on a compiler that "has no support"

Note that I said evaluating with some time limit. Just because software ships with bugs doesn't mean we have to accept them. A product still has to be fit for purpose.

Peter