different results with optimation / debug on

[Franzki]

The program I'm working on randomly shows some strange behaviour. Results vary depending on optimation / debug settings.

Some floating point values seem to be squared at a certain point in the program when building release code. When I compile with debug info on (to find out what's going wrong) everything seems to be fine again. Also when I print the values (using printf()) everything turns back to expected behaviour.

Disabling optimation for speed when building release code seems to solve the problem.

Is this just my poor coding, or could this be a bug?

Pelles C 5.00.8

[AlexN]

The program I'm working on randomly shows some strange behaviour. Results vary depending on optimation / debug settings.

Some floating point values seem to be squared at a certain point in the program when building release code. When I compile with debug info on (to find out what's going wrong) everything seems to be fine again. Also when I print the values (using printf()) everything turns back to expected behaviour.

Disabling optimation for speed when building release code seems to solve the problem.

Is this just my poor coding, or could this be a bug?

Pelles C 5.00.8

Optmization can cause some problems. You can try to switch on debug and optmizing (perhaps the active line will not jump as expected and not all locale variables will be shown but you can test some things of your code).

Pelles C 6.0RC2 (or later) has a new (better) optimzer, maybe it works with this. 

If nothing helps you should us show the parts of code with does not work.

[Franzki]

Code: [Select]

#include <stdio.h>

int main (void)
{
float percent;
int heel;
char teken;

percent =5;
teken = 0;

heel=percent + teken;
heel=teken * heel ;
printf("%d\n",heel); // should result in 0 * 5 = 0 ???

teken =1;

heel=percent + teken;
heel=teken * heel ;
printf("%d\n",heel); // should result in 1 * 6 = 6 ???

return (0);
}
Just simplified the code to make it clear... Choosing "debug build" or "no optimation" gives the right results. Using speed optimation in release build gives wrong results.

Not tested in version 6 yet.

Am I doing something wrong or is it an optimizer bug?

[AlexN]

Just simplified the code to make it clear... Choosing "debug build" or "no optimation" gives the right results. Using speed optimation in release build gives wrong results.

Not tested in version 6 yet.

Am I doing something wrong or is it an optimizer bug?

It's a problem of Pelles C 5.0 (and maybe older). the compiler forgets in the code to reload teken and multilies heel with heel.

Pelles C 6 works in my opion correct, so I assume Pelle will not correct this error in version 5.

[Franzki]

I have finished a portable PellesC 6RC2 installation this evening. After that I tried to create a (clean) new project and added my sourcefiles. I experienced a real problem afterwards: Access Violation errors when running the compiled program.

Unfortunately I have not been able to find the cause of the crashes... there must be something going wrong with the memory management.

The project didn't cause Access Violation errors in PellesC 5.0 and also compiles to a working executable in Code::Blocks with the GNU GCC compiler.

Could this be a PellesC bug or is PellesC just more strict so it reveals some weak spots in my code sooner than other compilers?

[AlexN]

Could this be a PellesC bug or is PellesC just more strict so it reveals some weak spots in my code sooner than other compilers?

Without more context we can not say, why you have some access violations.

I can only say the example you posted works for me with Pelles C 6.0RC2.

In RC1 I found a problem with allocation of memory (solved in RC2), maybe there are some more - but without your code nobody can say anything.