Wrong code gerated by icc compiler

[Mike B.]

Hi

A short note about an ugly bug in icc (or I'm unable to catch the point).

I'm writing code to program a controller on a T2 TRAM which is mapped to address 0x10.

#define MODE_REG 2
#define MORE_REG 3

#define CONTROLLER ((unsigned int volatile *)0x10)

int test1( unsigned int val ) {

unsigned int volatile *Controller = CONTROLLER;

Controller[ MODE_REG ] = val;
Controller[ MORE_REG ] = val;
}

This generates the following code:

ldl 3 -- val
ldl 0 -- Controller
stnl 2

ldl 3 -- val
ldl 0 -- Controller
stnl 3

Later I recognized that this local variable is not really required and ldl also takes 2 cycles, so I changed the code to:

#define CONTROLLER(r) (((unsigned int volatile *)(0x10))[r])

int test2( unsigned int val ) {

CONTROLLER( MODE_REG ) = val;
CONTROLLER( MORE_REG ) = val;
}

/*

This generates the following code:

ldl 2 -- val
ldc 20
stnl 0

ldl 2 -- val
ldc 22
stnl 0

Unfortunately, the code is 1 byte longer (for each controller access) as ldl 20 requires a prefix.
I don't understand why icc did not generate the more direct variant:

ldl 2 -- val
ldc 16
stnl 2

To get rid of the pfix I changed the code again to:

#define CONTROLLER(r) (((unsigned int volatile *)(0x00))[r+8])

int test3( unsigned int val ) {

CONTROLLER( MODE_REG ) = val;
CONTROLLER( MORE_REG ) = val;
}

My hope was the following desired code:

ldl 2 -- val
ldc 0
stnl 10

BUT that's what icc is generating:

ldl 2 -- val
mint
stnl 10

ldl 2 -- val
mint
stnl 11

We are overwriting values below memstart!

This happens with:

icc 2.01.10
icc 2.02.29
icc 4.01.13

icc 3.01.41 is not able to generate code for T2 but optimizes test3 to the same code as test2.

Generating suboptimal code is frustrating but generating wrong code is unforgivable.
As this will be unfixed for the future, keep always an eye on the generated assembler code if things don't work as expected.

-Mike

[Mike B.]

Fortunately this is 16bit specific only.

-Mike