Pelles C > Bug reports
V12 time optimization
John Z:
To start - I've used Maximize Speed plus checked Extra Optimizations for what follows since about version 9. Unfortunately starting when I finally switched to version 12 a problem has occurred which I failed to catch until this week. My bad for not testing each and every feature of my program after upgrading to version 12. I use third party mini zip sources to complete the assembly of an ODS format spreadsheet. Starting in version 12 it was created but was always corrupt and UN-openable. Today I isolated the source code where the problem occurs.
This code does not work correctly when optimized for time, but works well when no optimization or only size optimization is used. Here is the code -
--- Code: ---#pragma optimize(none) // needed for Pelles C v12 optimization bug in time
static char *strrpl(const char *str, size_t n, char oldchar, char newchar) {
char c;
size_t i;
char *rpl = (char *)calloc((1 + n), sizeof(char));
char *begin = rpl;
if (!rpl) {
return NULL;
}
for (i = 0; (i < n) && (c = *str++); ++i) {
if (c == oldchar) {
c = newchar;
}
*rpl++ = c;
}
Write_To_Log("c:/temp/vcardz.log", (char *)begin, 0, 0); // added by John Z for testing
return begin;
}
#pragma optimize(time) // back on for remaining source
--- End code ---
When optimized for time the begin character pointer somehow ends up pointing to the string start plus 1 char - so it ends up pointing to the 2nd character in the string as the start of the string. ONLY happens when using the time optimization.
The attached log file shows the output with various optimizations.
So bracketing this one procedure with #pragma fixes my issue.
Maybe information can help find a weak optimization point that can be improved in future versions.
John Z
frankie:
John I can't reproduce the problem.
Anyway some points:
--- Code: ---char *rpl = (char *)calloc((1 + n), sizeof(char));
--- End code ---
The cast to character pointer returned from calloc call is not required, in some cases can cause problems, moreover sizeof(char) is always 1, because by language standard it is always the smallest allocation unit for a system.
But what sound strange is the cast to character pointer of the variable begin inside the call to Write_To_Log function:
--- Code: ---Write_To_Log("c:/temp/vcardz.log", (char *)begin, 0, 0);
--- End code ---
Is it a typo? What is exactly the definition of the function Write_To_Log?
Which compilation is it? 32 or 64 bits? The bug happens for both bitness?
The character pointer begin gets wrong inside the function strrpl or only inside the function Write_To_Log?
John Z:
Thanks frankie,
Wow - it is 100% repeatable in my program/setup. I'm going to follow Pelle's inputs from before and move this single procedure into its own file. The code I've shown is preceded with about 950 lines of code, and this is now the last procedure in the file. I relocated from the middle it to the bottom once I isolated it with #pragma statements that showed where the corruption was occurring. I found this was the problem proc basically using a search inserting #pragma optimize(none) and #pragma optimize(time) at locations until I narrowed it down to one procedure. Yes - it took a while but each test you half the search space :)
I added my Write_to_Log call after I found where the problem was. The log file was easier to show the output than using the ODS zip file which has the 1st character missing on each of the 4 file names inside of the zip.
Yes the cast on 'begin' is redundant removing it has no effect. The pointer 'begin' becomes wrong before the Write_to_Log.
I removed the cast and re-ran, everything is the same with or without the cast, as expected since I added the proc to log the issue that was already happening. I should have clarified that in the original post - sorry that is a red herring ....
When I move it into it's own file, I'll also be able to generate a complete ppj and example. If that shows the issue I'll post the complete minimized project. If it all of the sudden works ok when broken out I'll be stumped and may have to re-install Pelles C.....
It is only a 32 bit program BTW - way too much to change to make it into 64 bit ;(
The zip procedure where the issue is found is unchanged from GitHub.
it only happens in version 12 not in version 11.
Thanks very much for looking at this and your analysis.
John Z
Marco:
Hello John, I tried the function on my system, and I have the same issue (32-bit compilation - Pelles C v12). The 64-bit executable seems to work as expected (i.e. no errors). To fix the issue you need to add the volatile keyword to the 'i' variable.
--- Code: ---static char *strrpl(const char *str, size_t n, char oldchar, char newchar) {
[...]
volatile size_t i; // <-- FIX
[...]
}
--- End code ---
Here are the options used during the compilation, if it can help:
--- Code: ---pocc: -fp:precise -W2 -Gz -Ze -Zx -MT -Tx86-coff
polink: -debug:no -subsystem:console -machine:x86
--- End code ---
Marco
John Z:
SUCCESS! Well sort of.....
Attached here is a simple minimum (mostly) program that demonstrates the issue under V12 on my WIN 11 system.
A simple Hello_world program. When executed click the OK button, first an optimized procedure is tested, then the
same thing is sent to an unoptimized procedure. the exact procedure is duplicated so that one will be optimized and one will not. This was easier than rebuilding for each test.
Clearly shows that the problem exists on my system under V12. It does not manifest when run under V11, both outputs are correct and identical. It also does not manifest when run under V10, all good with or without optimization. Both V11 and V10 were run on the same system as the V12 test.
Also it can easily demonstrate that it is only the Maximize Speed optimization, with and without Extra Optimization.
So with help this could show it is my installation, or not....BTW tested with all add-ins disabled too.
John Z
Navigation
[0] Message Index
[#] Next page
Go to full version