CodeWarrior 6.3 buggy with MCF51QE128

[WayneZ]

I updated from CW 6.2.2 (4.2.0.1) to 6.3 (4.3.0.3), the latest CW for MCF51QE128. My code size went from 88K to 95K (due to libraries) and second the application no longer works. Only if I set Optimization to 0 will CW 6.3 work properly. CW 6.2.2 works fine at all optimizations levels.
What has changed so much that the new version fails? Is there some other settings I need to adjust? It will take some time to find a small example, but I have been comparing the disassembly, but the code base is large, so it is difficult to pin point an example.
Anyone have similar experience they could relate?

Thanks
Wayne

[WayneZ]

After adding this pragma to many routines I narrowed the problem to a file and peephole optimization:

#pragma optimization_level 0

Doing a binary search of that file using:

#pragma peephole off
...code...
#pragma peephole reset

I narrowed the problem to at leaset one function:

#define RADIO_FLAG_PACKET_ID  (1<<1)
static uint8_t radio_last_packetID;

static void radioApi_TogglePacketID(uint8_t *packet_id)
{
    radio_last_packetID = RADIO_FLAG_PACKET_ID & (~radio_last_packetID);
    *packet_id &= ~RADIO_FLAG_PACKET_ID;
    *packet_id |= radio_last_packetID;
}

disassembly of this code with and without peephole optimization comes down to this statement:

    *packet_id &= ~RADIO_FLAG_PACKET_ID;

Here is the code disassembly differences:

;  106: static void radioApi_TogglePacketID(uint8_t *packet_id)
;  107: {
;  108:     radio_last_packetID = RADIO_FLAG_PACKET_ID & (~radio_last_packetID);
;
0x00000000                    _radioApi_TogglePacketID:
;                             radioApi_TogglePacketID:
0x00000000  0x73AD0000               mvz.b    _radio_last_packetID(a5),d1
0x00000004  0x4681                   not.l    d1
0x00000006  0xA540                   mov3q    #2,d0
0x00000008  0xC280                   and.l    d0,d1
0x0000000A  0x1B410000               move.b   d1,_radio_last_packetID(a5)
;
;  109:     *packet_id &= ~RADIO_FLAG_PACKET_ID;
;

without peephole optimization gives this:

0x0000000E  0x70FD                   moveq    #-3,d0
0x00000010  0x1210                   move.b   (a0),d1
0x00000012  0xC280                   and.l    d0,d1
0x00000014  0x1081                   move.b   d1,(a0)

with peephole optimization gives this:

0x0000000E  0xA341                   mov3q    #1,d1
0x00000010  0x0390                   bclr     d1,(a0)

Wayne

[WayneZ]

Here is what CW 6.2.2 generates:

0x0000000E  0x7190                   mvz.b    (a0),d0
0x00000010  0x08800001               bclr     #1,d0
0x00000014  0x1080                   move.b   d0,(a0)

[WayneZ]

Seems to me that this code with peephole optimization :

0x0000000E  0xA341                   mov3q    #1,d1
0x00000010  0x0390                   bclr     d1,(a0)

should actually look like this:

0x0000000E  0xA341                   mov3q    #3,d1
0x00000010  0x0390                   bclr     d1,(a0)

Am I wrong? I hate when I find compiler errors, because it makes all the code suspect.

Wayne

[WayneZ]

Whoops, that should be:

should actually look like this:

0x0000000E  0xA341                   mov3q    #2,d1
0x00000010  0x0390                   bclr     d1,(a0)

[WayneZ]

actually, I'm confused, it is late, maybe the #3 is correct. Any confirmation that this is a compler bug?

[CompilerGuru]

I have the impression the compiler is right to use #1, anding with -3 means to clean the bit with the mask 2, that is the bit number 1.

The actual bug maybe further down the function in the code generated for

> *packet_id |= radio_last_packetID;

or elsewhere...

Daniel

[CompilerGuru · Accepted solution]

I reproduced the issue with CW for MCU's 10.0 beta (I don't have 6.3 installed here) .

0x0000000E  0xA341                   mov3q    #1,d1
0x00000010  0x0390                   bclr     d1,(a0)
;
;
;    7:     *packet_id |= radio_last_packetID;
;
0x00000012  0x102D0000               move.b   _radio_last_packetID(a5),d0
0x00000016  0x8280                   or.l     d0,d1
0x00000018  0x1081                   move.b   d1,(a0)

 As suspected, the bug is in the code after the code shown before. The or.l reads the register which is not maintained by the peephole optimization.

I did report the issue as MTWX40806

Daniel

[WayneZ]

Yes, I traced the two versions of the code, I assumed since the following statement disassembly was the same in both cases, that the other statement was incorrect, but after tracing both, I see what you say, that the following statement was not updated to match the peephole optimization of the previous statement.

I thought CW 6.3 was the latest release of CW for the QE128 ColdFire V1? The actual compiler version reported by __CWCC__ IS 4303 and the previous CW6.2.2 reports 4201.

Thanks for confirming.

Wayne