sdcc -v
9949
test.c
unsigned char *backgrounds[10]= { 25768 + 32 + 32 + 32 + 32 + 32 + 32, 25768 + 32 + 32 + 32 + 32 + 32 + 32 + 32, 25768 + 32 + 32 + 32 + 32 + 32 + 32 + 32 + 32, 25768 + 32 + 32 + 32 + 32 + 32 + 32 + 32 + 32 + 32, 25768 + 32 + 32 + 32 + 32 + 32 + 32 + 32 + 32 + 32 + 32, 25768 + 32 + 32 + 32 + 32 + 32 + 32 + 32 + 32 + 32 + 32 + 32, 25768 + 32 + 32 + 32 + 32 + 32 + 32 + 32 + 32 + 32 + 32 + 32 + 32, 25768 + 32 + 32 + 32 + 32 + 32 + 32 + 32 + 32 + 32 + 32 + 32 + 32 + 32, 25768 + 32 + 32 + 32 + 32 + 32 + 32 + 32 + 32 + 32 + 32 + 32 + 32 + 32 + 32, 25768 + 32 + 32 + 32 + 32 + 32 + 32 + 32 + 32 + 32 + 32 + 32 + 32 + 32 + 32 + 32 }; ~~~~~~ sdcc -mz80 -S test.c The generated asm file: ~~~~~~ __xinit__backgrounds: .dw #0x0068 .dw #0x0088 .dw #0xffa8 .dw #0xffc8 .dw #0xffe8 .dw #0x0008 .dw #0x0028 .dw #0x0048 .dw #0x0068 .dw #0x0088
It looks like the integer value of each expression is computed, then the result is truncated to signed char and that is sign extended to form each unsigned char*.
Attached diff contains potential fix. It looks all values are calculated correctly but in the last step, when array content is generated, instead of array of pointers, array of unsigned char is generated.
In this step all values are truncated.
Changed code checks if array contains pointers.
Fixed by applying your patch in revision [r10005].
Philipp
The regression test for this bug generates (valid) warnings. An integer is not the same as a pointer. And for a Harvard architecture like the mcs51 it is not even obvious what memory the pointers are targeting.
I'd like to object against creating tests that generate warnings. And suppressing the warning is IMO only allowed if the test really tests what is warned against.
It does not generate the warning when targeting z80, which is probably why I didn'T notice it at the time.
C allows converting integers to pointers, and AFAIK requires that the result is the same, no matter how the conversion is done.
In this bug, the resulting pointer was different when using a cast vs. when doing it in the initialization.
The test indeed tests what is warned against, so I'll supress the warning.
Philipp