Reply by Mark Borgerson May 4, 20082008-05-04
In article <MPG.2287858dc3a919a298990f@news.verizon.net>,=20
first.last@verizon.net says...
> In article <PUAFTtFCVXFIFAS7@phaedsys.demon.co.uk>, chris@phaedsys.org=20 > says... > > In message <MPG.227ec5c2de8d322e98990c@news.verizon.net>, Gene S.=20 > > Berkowitz <first.last@verizon.net> writes > > >In article <JogEctNATJFIFAwF@phaedsys.demon.co.uk>, chris@phaedsys.org > > >says... > > >> In message > > >> <4e894752-5193-471a-8ef3-1e1aa8c12b67@w5g2000prd.googlegroups.com>, > > >> larwe <zwsdotcom@gmail.com> writes > > >> >On Apr 27, 8:33=A0am, Chris H <ch...@phaedsys.org> wrote: > > >> > > > >> >> >I haven't yet groveled through the assembly output to see exactl=
y what
> > >> >> >the difference between the two output flavors is. But this is su=
ch 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 on=
ly
> > >> be "buy" a new version if you were out of support. Which you would b=
e 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 o=
n
> > >> support it is usually free. You only have to pay if it is a very o=
ld
> > >> version. > > >> > > >> However if you want to use an old version that is your look out. > > > > > >Following is what the latest Kickstart version I have (came with the > > >EZ2500 kit) says when About... is clicked. Considering that practical=
ly
> > >every component has a different version and build #, it's virtually > > >impossible to ever say with certainty what "version" of IAR anyone has=
.
> >=20 > > As with ALL compiler suites. You are either being deliberately obtuse o=
r=20
> > don't understand the tools. Neither trait is good for a developer. >=20 > Excuse me, but it isn't ME being obtuse, it's IAR's method of=20 > versioning, which makes it quite difficult to document what toolchain=20 > "version" was/should be used to build a particular "version" of an=20 > application. >=20
> The choice is to either archive the entire IAR environment used to=20 > produce the executable, or never/rarely "upgrade".
I generally choose to keep the old versions around. IAR makes it easy to do that by allowing each new version to install in a different=20 directory. EWARM 5.10 takes up about 622MB of hard disk ( about 20 cents=20 worth of a 250GB disk). The IAR menu bar tab gives you an entry for=20 each installed version, so it's easy to start the appropriate version.
>=20 > > The package has a release number (on the CD, zip file etc) and the=20 > > individual components also have release numbers as you listed. It is=20 > > called version control. Something that happens in professional softwar=
e=20
> > development. >=20 > Ooh, touchy, aren't we? Of course, it also ignores the fact that not=20 > all "releases" of the various components work with earlier release=20 > components of the same major version. >=20 > > I used to have this problem a lot with Keil C51 when asking what versio=
n=20
> > of the compiler someone was using. I often got the version of the IDE. >=20 > Right, my point exactly.
Mark Borgerson
Reply by Gene S. Berkowitz May 4, 20082008-05-04
In article <PUAFTtFCVXFIFAS7@phaedsys.demon.co.uk>, chris@phaedsys.org=20
says...
> In message <MPG.227ec5c2de8d322e98990c@news.verizon.net>, Gene S.=20 > Berkowitz <first.last@verizon.net> writes > >In article <JogEctNATJFIFAwF@phaedsys.demon.co.uk>, chris@phaedsys.org > >says... > >> In message > >> <4e894752-5193-471a-8ef3-1e1aa8c12b67@w5g2000prd.googlegroups.com>, > >> larwe <zwsdotcom@gmail.com> writes > >> >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 not it is a FREE size limited eval version. However that do=
es
> >> 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. > > > >Following is what the latest Kickstart version I have (came with the > >EZ2500 kit) says when About... is clicked. Considering that practically > >every component has a different version and build #, it's virtually > >impossible to ever say with certainty what "version" of IAR anyone has. >=20 > As with ALL compiler suites. You are either being deliberately obtuse or=
=20
> don't understand the tools. Neither trait is good for a developer.
Excuse me, but it isn't ME being obtuse, it's IAR's method of=20 versioning, which makes it quite difficult to document what toolchain=20 "version" was/should be used to build a particular "version" of an=20 application. The choice is to either archive the entire IAR environment used to=20 produce the executable, or never/rarely "upgrade".
> The package has a release number (on the CD, zip file etc) and the=20 > individual components also have release numbers as you listed. It is=20 > called version control. Something that happens in professional software=
=20
> development.
Ooh, touchy, aren't we? Of course, it also ignores the fact that not=20 all "releases" of the various components work with earlier release=20 components of the same major version.
> I used to have this problem a lot with Keil C51 when asking what version=
=20
> of the compiler someone was using. I often got the version of the IDE.
Right, my point exactly. --Gene
Reply by Peter Dickerson April 30, 20082008-04-30
"sprocket" <jas@spam.cop.uk> wrote in message news:fv9ufu$cf$2@aioe.org...
> Peter Dickerson wrote: > >> 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'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.
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
Reply by Chris H April 30, 20082008-04-30
In message <fv9ufu$cf$2@aioe.org>, sprocket <jas@spam.cop.uk> writes
>Peter Dickerson wrote: > >> 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'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" -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by sprocket April 30, 20082008-04-30
Peter Dickerson wrote:

> 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'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.
Reply by Peter Dickerson April 30, 20082008-04-30
"Chris H" <chris@phaedsys.org> wrote in message 
news:l0kPbsKdPEGIFA8X@phaedsys.demon.co.uk...
> In message <RcWRj.98190$4f4.36105@newsfe6-win.ntli.net>, Peter Dickerson > <firstname.lastname@REMOVE.tesco.net> writes >>"Chris H" <chris@phaedsys.org> wrote in message >>news:3iDru1EA7BGIFAuh@phaedsys.demon.co.uk... >>> In message <C6Kdnd_ktoaTDorVnZ2dnUVZ8uOdnZ2d@lyse.net>, David Brown >>> <david.brown@hesbynett.removethisbit.no> writes >>>>larwe wrote: >>>>> On Apr 29, 4:04 am, David Brown <da...@westcontrol.removethisbit.com> >>>>> wrote: >>>>> >>>>>> 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, >>>>> 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 = pointer_to_const_data_struct; >>>>> for (i=0;i<8;i++) { >>>>> tmpsrc = src; // BAD LINE >>>>> for (j=0;j<3;j++) { >>>>> call_another_func(*(tmpsrc++),0); >>>>> } // j-loop >>>>> src += 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. >>>>> >>>> >>>>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 >>> <3b2e11dc-393f-4eef-8790-8ea6d4245d02@d1g2000hsg.googlegroups.com>, >>> "andlind@gmail.com" <andlind@gmail.com> writes >>>>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. >>> >>> 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? > > 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.
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.
> 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.
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.
> 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 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.
>> Yes, I know, these things happen and another couple of >>tests are added to the validation suite. > > 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.
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.
> Compared to many other compilers IAR are very good at testing compilers > and fixing any bugs.
I would still prefer them to avoid releasing them...
> 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
Good. So they're learning.
> 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.
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.
> 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.
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.
> So lets get things into perspective.
Yes, lets. peter
Reply by Chris H April 30, 20082008-04-30
In message <RcWRj.98190$4f4.36105@newsfe6-win.ntli.net>, Peter Dickerson 
<firstname.lastname@REMOVE.tesco.net> writes
>"Chris H" <chris@phaedsys.org> wrote in message >news:3iDru1EA7BGIFAuh@phaedsys.demon.co.uk... >> In message <C6Kdnd_ktoaTDorVnZ2dnUVZ8uOdnZ2d@lyse.net>, David Brown >> <david.brown@hesbynett.removethisbit.no> writes >>>larwe wrote: >>>> On Apr 29, 4:04 am, David Brown <da...@westcontrol.removethisbit.com> >>>> wrote: >>>> >>>>> 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, >>>> 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 = pointer_to_const_data_struct; >>>> for (i=0;i<8;i++) { >>>> tmpsrc = src; // BAD LINE >>>> for (j=0;j<3;j++) { >>>> call_another_func(*(tmpsrc++),0); >>>> } // j-loop >>>> src += 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. >>>> >>> >>>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 >> <3b2e11dc-393f-4eef-8790-8ea6d4245d02@d1g2000hsg.googlegroups.com>, >> "andlind@gmail.com" <andlind@gmail.com> writes >>>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. >> >> 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?
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.
> Yes, I know, these things happen and another couple of >tests are added to the validation suite.
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. -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by Peter Dickerson April 30, 20082008-04-30
"Chris H" <chris@phaedsys.org> wrote in message 
news:3iDru1EA7BGIFAuh@phaedsys.demon.co.uk...
> In message <C6Kdnd_ktoaTDorVnZ2dnUVZ8uOdnZ2d@lyse.net>, David Brown > <david.brown@hesbynett.removethisbit.no> writes >>larwe wrote: >>> On Apr 29, 4:04 am, David Brown <da...@westcontrol.removethisbit.com> >>> wrote: >>> >>>> 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, >>> 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 = pointer_to_const_data_struct; >>> for (i=0;i<8;i++) { >>> tmpsrc = src; // BAD LINE >>> for (j=0;j<3;j++) { >>> call_another_func(*(tmpsrc++),0); >>> } // j-loop >>> src += 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. >>> >> >>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 > <3b2e11dc-393f-4eef-8790-8ea6d4245d02@d1g2000hsg.googlegroups.com>, > "andlind@gmail.com" <andlind@gmail.com> writes >>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. > > 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
Reply by Chris H April 30, 20082008-04-30
In message <C6Kdnd_ktoaTDorVnZ2dnUVZ8uOdnZ2d@lyse.net>, David Brown 
<david.brown@hesbynett.removethisbit.no> writes
>larwe wrote: >> On Apr 29, 4:04 am, David Brown <da...@westcontrol.removethisbit.com> >> wrote: >> >>> 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, >> 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 = pointer_to_const_data_struct; >> for (i=0;i<8;i++) { >> tmpsrc = src; // BAD LINE >> for (j=0;j<3;j++) { >> call_another_func(*(tmpsrc++),0); >> } // j-loop >> src += 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. >> > >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 <3b2e11dc-393f-4eef-8790-8ea6d4245d02@d1g2000hsg.googlegroups.com>, "andlind@gmail.com" <andlind@gmail.com> writes
>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.
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. -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by David Brown April 29, 20082008-04-29
larwe wrote:
> On Apr 29, 4:04 am, David Brown <da...@westcontrol.removethisbit.com> > wrote: > >> 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, > > 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 = pointer_to_const_data_struct; > > for (i=0;i<8;i++) { > tmpsrc = src; // BAD LINE > for (j=0;j<3;j++) { > call_another_func(*(tmpsrc++),0); > } // j-loop > src += 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. >
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).