Compiler not preserving local variable in while loop

[theJoel]

Hi all,

I am using CodeWarrior 5.6.1 for an MCF5270 target.

While debugging an error in my application I found the problem to be a local variable -- initialized once and used inside a while loop -- was unexpectedly changed during the loop body.

The variable was assigned by the compiler to a register, and the same register is used inside a function, called within the loop body. This overwrites my local var.

I'm all for optimal register use, but if the compiler chose a register (D3 in this case), why would it not preserve (push) the reg value around a function using that register?

Is this a compiler error? Has anyone else seen this? Or, can certain coding practices fool the compiler to not saving the local variable around function calls.

Source / compiled source is available but the specific case where I have proved this error does not lend itself to a clear example posting for forums.

Thanks,
Joel.

[blackjack]

Hello Joel,

                   Did you find the answer that you were looking for. I have got the same problem as yours. I donot know how the local variable changes itself without assigning any values.

If you have solved then could you give some advice to me.

[Lundin]

Stack overflow.

[CrasyCat]

Hello

You need to submit a service request  for that to get one of our support engineer looking into that
Click here to submit a service request..
 
Make sure to attach  a project reproducing the issue and installed product information to the SR.
To make sure you provide all necessary project information, you can use the Pack and Go wizard.
  - Start the IDEA
  - Open the Project
  - Select Help -> "Pack and Go"
  - Follow the instruction on the screen. That will generate a zip file containing all necessary
    information (including the installed product information).

CrasyCat

[theJoel]

---

CrasyCat wrote:
To make sure you provide all necessary project information, you can use the Pack and Go wizard.
 - Start the IDEA
 - Open the Project
 - Select Help -> "Pack and Go"
 - Follow the instruction on the screen. That will generate a zip file containing all necessary
   information (including the installed product information).

CrasyCat

---

Hey, what's the big "IDEA"! ...you mentioned?
What is Pack and Go?

I have no such options.

I have a purchased copy of CW 5.6.1 but do not have an active support agreement. I know I can prove this issue, but will my Service Request be considered? And, will they correct the problem in my compiler version?


I am also looking for other options and forum input, ie. change of coding style, turning off certain optimizations, etc.. anything to guarantee our C algorithms are compiled as intended.

I can no longer be confident this isn't happening throughout our application.


Joel.

[Alban]

Hello Joel,

CrasyCat meant the IDE for Integrated Develpment Environment or something like this.
In clear, start CodeWarrior and follow instructions.

Pack and Go is an option which allow easier support on projects.


YES, your service requests WILL be looked at. You probably won't have the higher priority, of course.

Note for later, though... Please read this post.............
Also, there is a special folder for MCF5270 questions.

Cheers,
Alban.

Message Edited by Alban on 2007-04-28 04:45 PM

[CompilerGuru]

Pack and Go was added in a 6.X version (6.3?). So your ide does probably not have it.
Anyway, its a tool to collect all the files to report the bug and it creates a zip file to be sent to support. It would be good if support would be able to compile and run the incorrect code on their own so they have everhing too see how this bug happens.

About the actual bug, I think (not 100%) that for ColdFire D3 is callee saved. This means that the code with the loop is actually OK and its the function called (which does overwrite the D3 without saving it first) which contains the bug.

Daniel

[theJoel]

Thanks Daniel

No I don't have Pack and Go. But I can make a zip file of my project settings and source code.

I'm not really comfortable sending our entire source directory but I will try demonstrate the problem in a stripped down project directory. Perhaps in the process I will even see where the compiler is breaking.

I'll post here if I find anything.


Joel.