Iyonix rom compiling oddity

I found a problem compiling this program (cc version 5.70 12-Oct-2012)

typedef __packed struct
{
    char a;
    int  b[];
} Test;

char* xxx = "0123456789";

int main(void)
{            
    Test* t = (Test*)(&xxx[1]);
    int a = t->b[0];
    return  a == 0 ;
}

I tracked it down to !builder setting Alias$CC as follows:

Alias$CC : %CC -APCS 3/32bit/fpe3 -cpu 5TE -memaccess +L22+S22+L41 %*0

After compiling the program works on an Iyonix but if you put the compiled program on a beagleboard it fails with data abort. Removing the +L41 and recompiling makes the code work for both machines.

What does the +L41 do? I note that the object file created with it is 4 bytes smaller.

The -memaccess option tells the compiler which memory access sizes and alignments are and aren’t supported by the target machine: http://www.iyonix.com/tools/halfword.shtml

The default setting for the compiler is equivalent to “-memaccess -L22-S22-L41”, which will produce code that’s compatible with all RISC OS machines. But that compatibility will come at the cost of lower performance because the compiler will be forced to use longer instruction sequences for some load/store operations instead of just a single instruction. So for best performance the ROOL build system uses different -memaccess and -cpu settings for each build environment, to allow the compiler to produce the best code that it can for the target machine.

So if you build some code while you’ve got the Tungsten environment selected then the compiler will be trying to use unaligned (rotated) loads/stores in order to get at the ‘b’ member of your struct. But then that code will fail on a BeagleBoard because it doesn’t support that type of memory access (I’m being slightly vague here because it could be LDM or LDR which the compiler is trying to use, and they have differing behaviour with unaligned addresses)

If you select the ‘Disc’ environment then that will set things up to allow you to build code that’s compatible with all machines.