bug in AVR 8-bit tool chain

Go To Last Post
15 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The following attached programme works perfectly well if optimization is set to NONE. It does not works if optimization is set to optimize for size on an ATmega644P, under AVR studio5 (5.1.208) windows vista 6.0.6002 32 bits

The program deliver a sync (fb_sync) of value 3 at index (k) of 4 (5 on programme output).

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The first thing that comes to mind is that the compiler may be optimizing your variables so have you tried to declare the variables as volatile to see if it works?

Also I don't see a super loop, as soon as the while is done you exit the main and this is not good.
Add a while(1); before the end of main.

Alex

"For every effect there is a root cause. Find and address the root cause rather than try to fix the effect, as there is no end to the latter."
Author Unknown

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

alexan_e wrote:
The first thing that comes to mind is that the compiler may be optimizing your variables so have you tried to declare the variables as volatile to see if it works?

Also I don't see a super loop, as soon as the while is done you exit the main and this is not good.
Add a while(1); before the end of main.

Alex

declare the variables as volatile works indeed.

The super loop is not an issue it is just a test sequence extracted from a more complex programm to find out what was wrong.

Pierre

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Of-course the compiler optimizes most everything away.

A C compiler is allowed to optimize anything away that does not have any "real-world efects". In essence, since you never use neither fb_sync not k for anything then the compiler can remove those. This in turn will likely make the compiler see that it the array RDS_Val is no longer neded, so it throws that one out too.

Your program is just a slightly more convoluted version of this

unsigned char whatever;

int main(void)
{
  whatever = 1;
}

, the point being that since it, from the compilers point of view, does no meaningful thing most all of it can be optimized out.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Mon. Nov 12, 2012 - 02:41 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

is not an issue

But you haven't actually said what the "issue" is? o far we have:
Quote:

works perfectly well if optimization is set to NONE

and
Quote:

It does not works if optimization is set to optimize for size

with no further explanation of what "perfectly well" and "not works" actually mean?

Clearly when you snip small sequences out of a larger code like this the optimiser is completely at liberty to cut the code to shreds.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OP stated it is a cut-out from a larger program. I believe the OP thinks there is an error in the short snippet of code above - i.e. in the larger program it does not behave as intended.

Now the OP cuts out this piece of code into a small test project, and immediately is tripped on the fact that since fb_sync is no longer used for anything meaningful the optimizer chews up the whole test program.

Peter! Make your two variables fb_sync and k 'volatile' and you will be much better off simulating this code snippet.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Quote:

is not an issue

But you haven't actually said what the "issue" is? o far we have:
Quote:

works perfectly well if optimization is set to NONE

and
Quote:

It does not works if optimization is set to optimize for size

with no further explanation of what "perfectly well" and "not works" actually mean?

Clearly when you snip small sequences out of a larger code like this the optimiser is completely at liberty to cut the code to shreds.

Thanks 10k super freak for your time, but you should read the complete sequence, alexan_e suggested to declare the variable as volatile, which I tested and answered to let him know that with the volatile declarationb my program works i.E. it delivers what I was expecting.

> Clearly when you snip small sequences out of a larger code like this the optimiser is completely at liberty to cut the code to shreds

If I do snip a small sequence it is because my big programm (87% of RAM) caused me troubles and I wanted to find out why!!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

(87% of RAM)

Well that's a danger sign right there - anything over about 75% is in "dangerous" territory unless you have almost everything global and don't use automatics. While it's not an exact science as it does depend on the amount of use you make of locals it's generally been shown here that 75% is usually about the usable limit.

I'd paint the stack and then watch it in a debugger.

I've built your code and single stepped it (simulator) and I cannot see anything untoward happening.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I've built your code and single stepped it (simulator) and I cannot see anything untoward happening.

Have you changed the optimization parameter from optimize for size to no optimization. That is how, in the AVR studio simulator, I detected what I thought was a bug.

Now we know the answer: declare as volatile

Thanks

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I fear you misunderstand. "volatile" just over-rides optimisation and prevents too much of your example being thrown away but that does not explain why the code might misbehave "in-situ" where it occurs in a larger program where the sequence would be valid.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
I fear you misunderstand. "volatile" just over-rides optimisation and prevents too much of your example being thrown away but that does not explain why the code might misbehave "in-situ" where it occurs in a larger program where the sequence would be valid.

I am not an expert but I don't understand why either.

> quote: "A C compiler is allowed to optimize anything away that does not have any "real-world efects".

Except that the variable feedback_sync is used even if only locally in small portion of the overall code.

I can send you the complete code should you wish.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Except that the variable feedback_sync is used even if only locally in small portion of the overall code.

Not in the example program you posted above, and that is the only thing we can relate to.

I do not think that people will be very interested in getting the complete code for your application to analyze. That would put the workload of isolating the problem you are seeing on us. What you should do is to post a minimal but still buildable and runnable program that people here can look at.

Creating that minimal demonstrator is a valuable exercise for you. And it is also not unlikely that you in the process will get clues enough to solve the problem yourself.

If I understand it correctly, the code you posted here was an attempt to solve a problem you had - but instead you ran into another problem with it, i.e. that it was too much of a reduvtion for it to work as a debugging attempt. The optimizer ate it all.

You could try to cut away part after part of your application, starting with those that are farthest from the original problem you experienced. For each cut, you check that you can still provoke the problem you have. At some point you are left with a rather small piece of code to debug. If you fail to get to the problem yourself at that point then post the thing here.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
under AVR studio5 (5.1.208)
Before you do anything read this https://www.avrfreaks.net/index.p...

It may not fix things but who knows.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

js wrote:
Quote:
under AVR studio5 (5.1.208)
Before you do anything read this https://www.avrfreaks.net/index.p...

It may not fix things but who knows.

Thanks for advice, but it is not the solution

Pierre

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:

.....
If I understand it correctly, the code you posted here was an attempt to solve a problem you had -
....
You could try to cut away part after part of your application, ...At some point you are left with a rather small piece of code to debug. If you fail to get to the problem yourself at that point then post the thing here.

> but instead you ran into another problem with it
No, it is exactly the same issue. I add an attachment which is the issue I try to solve, obtained by cutting away chunk of the complete programme.

> You could try to cut away part after part of your application
It is exactly what I have done to find out the issue with optimization.

> If you fail to get to the problem yourself at that point then post the thing here:

See attachment

As a reminder issue is in m4.c/run_m4_specific. The loop while should get out with fb_sync=3 at k = 5 which does not happen if optimization for size is selected.

Attachment(s):