Optimization bug in 6.50.8 rc4 ....

[CommonTater]

The following code snippet clearly demonstrates an optimization bug in version 6.50.8 rc 4...

Code: [Select]


 // sample code to demonstrate optimization bug
// in Pelles C ... 6.50.8 RC4... 32 and 64 bit versions

#include<stdio.h>
int main( void )
{
 char *b = "asdfjh";
  { char *c = b;
    while(*c)
      { printf("%p %c\n ",c, *c);
        c++; } }
  printf("\n\n");
  // this section clearly demonstrates the problem
  // note the pointer addresses.
 printf("%p %c %p\n",b, *b++, b);
 printf("%p %c %p\n",b, *b--, b);
 printf("%p %c %p\n",b, *b, b);
  return 0;
}

Attachment 1 is the result with optimizations set to "none".
Attachment 2 shows the result with it set to anything but "none".
The problem is evident in both debug and release builds.
 
Notice how the pointer gets messed up right away in the second attachment.
Also with optimizations on, we get this error message which is clearly nonsense...

Code: [Select]

Building main.obj.
D:\Programming\C_Code\Experiments\junk\main.c(22): warning #2238: Array index for 'char [6]' is out-of-bounds.
Building junk.exe.
Done.

EDIT: On further experimentation this appears to be a problem only with pointers to string literals and is evident in all RC versions of 6.50.
 

 
 
 
 
 
 

[AlexN]

The problem is that PellesC stores the string "asdfjh" two times. One time the string is stored complete and one time without the 'a',  so that it is alined at the second letter. The incorrect output is made with the short string and produceses an warning #2238 (the compiler knows there is not defined memory).

You can avoid this bug by adding static to the declaration of b ( static char *b = "asdfjh"; ) or you can define it as global variable. Both works correct as far as I can see.

You also can switch off and on the optimizer with #pragma statment around the missoptimized code.

Both are better in my opion than switching back to Pelles C 6.0, which also has some problems with the optmizer.

[CommonTater]

Thank you Alex, that's very helpful...  Of course the example is simply a demonstration of the problem, it also happens in much more complex code.  Both workarounds are appreciated... especially the static keyword, I hadn't considered that.