I am using the IAR C compiler to build an application for an embedded micro (specifically a Renesas uPD78F0537). In this application I am using two nested for loops to initialize some data, as shown in the following MCVE:
#define NUM_OF_OBJS 254
#define MAX_OBJ_SIZE 4
unsigned char objs[NUM_OF_OBJS][MAX_OBJ_SIZE];
unsigned char srcData[NUM_OF_OBJS][MAX_OBJ_SIZE];
srcData = 10;
int x, y;
for (x = 0; x < NUM_OF_OBJS; x++)
for (y = 0; y < MAX_OBJ_SIZE; y++)
objs[x][y] = srcData[x][y];
printf("%d\n", (int) objs);
13 int x, y;
14 for (x = 0; x < NUM_OF_OBJS; x++)
\ 0006 14.... MOVW DE,#objs
\ 0009 16.... MOVW HL,#srcData
16 for (y = 0; y < MAX_OBJ_SIZE; y++)
\ 000C A0F8 MOV X,#248
18 objs[x][y] = srcData[x][y];
\ 000E 87 MOV A,[HL]
\ 000F 95 MOV [DE],A
\ 0010 86 INCW HL
\ 0011 84 INCW DE
\ 0012 50 DEC X
\ 0013 BDF9 BNZ ??main_0
while (len-- > 0) *dst++ = *src++;
I am pretty much convinced that this is a compiler bug based on the following:
Copying the data over using pointers (e.g. something along the lines of
while (len-- > 0) *dst++ = *src++;) works fine. Thus this does not look like a problem of RAM size, pointer size, etc.
More relevant perhaps: If I just replace one of the two constants (
MAX_OBJ_SIZE) with a variable (thus preventing the compiler from precalculating the total count) it works fine.
Unfortunately I contacted IAR (providing a link to this SO question) and this is their answer:
Sorry to read that you don't have a license/support-agreement (SUA). An examination such as needed for this case can take time, and we (post-sales-support) prioritize to put time and effort to users with valid SUA.
Along with some generic comments which are not particularly useful.
So I guess I'll just assume this is a bug and work around it in my code (there are many possible workarounds, including the two described above).