Pelles C forum
Pelles C => Bug reports => Topic started by: Boro Sitnikovski on March 07, 2011, 12:50:21 PM
-
Greetings.
File->New->Project->Win32 Console program
Contents of the program are:
#include <windows.h>
int threadcount = 0;
// Thread function
DWORD WINAPI thread_function(LPVOID lpParam) {
//...
threadcount--;
return 0;
}
int main() {
// Some thread functionality here... {
// threadcount++;
// CreateThread()...
// }
//Wait for all threads to terminate
while (threadcount != 0); // the warning is here
return 0;
}
C:\Documents and Settings\b.sitnikovski\My Documents\Pelles C Projects\test\main.c(12): fatal error: Internal error: redirect_cfg_edge().
I noticed that when I turned off optimizations (Project->Project Options->Compiler->Optimizations->None) this error is gone.
Regards,
Boro Sitnikovski
-
Assuming threadcount is properly initialized someplace...
Try differing combinations of optimzations, see if you can isolate which flag(s) cause the problem.
-
Boro, the source you provided doesn't really say much at all. If it contains something secret, then try writing a short version with code that you can provide. Otherwise I doubt Pelle would do anything with the bug report.
That being said, the error complains about some code that we can't see. Also, most compiler environments rarely end up on the exact place where the real error occurs. Without seeing the actual code, we can't even begin to guess what is causing your problem.
-
Yes it seems a bug of the optimizer when it encounters an empty conditional block.
-
Minimal example:
int threadcount = 0;
int __cdecl mainCRTStartup(void)
{
while (threadcount != 0); // the warning is here
return 0;
}
-
Same error also if you use a "for" statement:
int threadcount = 0;
int __cdecl mainCRTStartup(void)
{
for (;threadcount != 0;); // the warning is here
return 0;
}
The optimizer cannot reduce an empty conditional block.
Removing optimizations it compiles OK.
-
Try something... make it non-empty...
// version 1
while (ThreadCount != 0)
Sleep(0);
// version 2
while (ThreadCount != 0){};
Does it still give the warnings?
Also, you might want to use version 1 in your program. That's a very tight loop that's not releasing time slices, it could seriously affect the system's performance and race the CPU.
-
The problem is here
-->> int threadcount = 0;
int __cdecl mainCRTStartup(void)
{
while (threadcount != 0){} // the warning is here
return 0;
}
the error will appear because it doesn't properly pick up 'threadcount'
do this:
int __cdecl mainCRTStartup(void)
{
int threadcount = 0; <-- moved here.
while (threadcount != 0){} // the warning is here
return 0;
}
and it will work.
-
Perhaps it would help to use the qualifier volatile.
volatile int threadcount = 0;
-
The point is that the use of an empty conditional block is perfectly legal in C programming.
The suggested workarounds will help with current release, but this is definitely a bug in optimizer code.
-
Still such a tight loop is bad practice, using Sleep(100) will allow the CPU to work on other things too.
while (threadcount != 0) Sleep(100);
You may use it this way too, as long as threadcount will be greater or equal to zero.
while (!threadcount) Sleep(100);
-
Sleep is not part of standard C, also it differs between platforms (it's 'usleep' on unix for example (it's in 'unistd.h' on unix btw))
I would suggest using a scrapvalue instead:
int threadcount = 0;
int scrap=0;
int __cdecl mainCRTStartup(void)
{
while (threadcount != 0){scrap+=1;} // does nothing of any value. Does help the optimizer to behave though, as a workaround.
return 0;
}
-
Sleep is not part of standard C, also it differs between platforms (it's 'usleep' on unix for example (it's in 'unistd.h' on unix btw))
So you should try to use conditional programming to adjust to several platforms. But if you have not many CPUs, your code will take much power of the CPU.
-
So you should try to use conditional programming to adjust to several platforms. But if you have not many CPUs, your code will take much power of the CPU.
Hmm. I was writing about the closure checks in this example really not needing 'sleep'. .. But I decided to erase it because I don't want to use this channel to have a discussion. However, know that I agree to the idea of letting the CPU go to do other things. But I disagree also because it is not always warranted. .. end of line.
-
Should be fixed in 6.50, RC4.