bugGNU Development Chain for 68HC11/68HC12 - Bugs: bug #12243, Loop compiles incorrectly (HC12)

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #12243: Loop compiles incorrectly (HC12)

Submitter:  None
Submitted:  Mon 07 Mar 2005 11:27:29 PM UTC
   
 
Category:  gcc Severity:  3 - Normal
Item Group:  sw-bug Status:  Fixed
Privacy:  Public Assigned to:  ciceron
Open/Closed:  Closed

Sun 12 Jun 2005 09:57:58 AM UTC, comment #5: 

Fixed in 3.0.1

Stephane Carrez <ciceron>
Group administrator
Tue 05 Apr 2005 09:07:50 PM UTC, comment #4: 

I'll mark this bug as closed when doing the next release.

Stephane Carrez <ciceron>
Group administrator
Sun 03 Apr 2005 06:43:18 PM UTC, comment #3: 

Thanks for the feedback.

I've added the test in the gcc test suite with execution of
the test case.  It passes completely (118 gcc options
combinations).

It passes on gcc 3.3.5 with patch 2005-04-03.

I think (confidence 95%) that the problem is solved in r3.0.

Stephane Carrez <ciceron>
Group administrator
Sun 03 Apr 2005 11:41:16 AM UTC, comment #2: 

Hi

This is the exact compile / link command. The GCC version is 3.3.4-m68hc1x-20040829.

C:\Programme\usr\bin\m6811-elf-gcc -D GNU -D _HW_NE64 -g -Os -m68hcs12 -mshort -Wl,-m,m68hc12elfb,--defsym,vectors_addr=0xff80 -o ETHERNET.elf OpSys\rtmk.c ethernet.c OpSys\driver.c watchdog.c OpSys\eth_drv.c OpSys\malloc.c Hardware\NE64.c OpSys\tty_drv.c stack\arp.c stack\ip.c stack\icp.c stack\udp.c stack\tcp.c stack\dhcp.c stack\dns.c stack\pop3.c stack\http.c application.c

Please tell me if you need more info

Anonymous
Sun 03 Apr 2005 10:03:03 AM UTC, comment #1: 


I am not able to reproduce this problem with release 3.0
(gcc 3.3.5).

What are the gcc options used to compile and see the problem?

I've tried -m68hc12 -Os -fomit-frame-pointer as well as some
other combinations without success to point out the problem.

Stephane Carrez <ciceron>
Group administrator
Mon 07 Mar 2005 11:27:29 PM UTC, original submission:  

Hallo
I am quite sure to have a problem with a specific loop where an array is filled with the loops variable value. The array is found to be filled backwards with the decending instead of accending value and also writes are made over the end of the array.

Please accept the following description which I posted a couple of days ago in the yahoo gnu-m68hc11 group. I checked to see whether this case has maybe already reported but didn't see anything obvious - please accept appologies if already reported / fixed.

Regards

Mark Butcher
-email is unavailable-

//////////////////////////////////////////////////////

 

Hi All

I wonder whether I have found a bug in the compiler?

The compiler version is:
Thread model: single
gcc version 3.3.4-m68hc1x-20040829

The code which I have written is:


static unsigned char spi_test1[256];

void fnTest(void)
{
unsigned short i;

for (i=0; i < sizeof(spi_test1); i++) {
spi_test1[i] = (unsigned char)i;
}
}

The result which I obtain is that the array spi_test1[] is
initialised but not as expected. I expect it to be initialised as
follows:
spi_test1[0] = 0;
spi_test1[1] = 1;
spi_test1[2] = 2;
...
spi_test1[255] = 255;

The results which I get is

spi_test1[0] = 0; // I think this was not set as it was 0 by default
spi_test1[1] = 255;
spi_test1[2] = 254;
...
spi_test1[255] = 1;
spi_test1[256] = 0; // !! 256 doesn't exit so a write is made after
end of buffer

That is BACKWARDS...As can be seen it actually also overwrites data
after the end of the array....

I had a look at the generated assembler code which is as follows:
0xc187 [ce 00 00] LDX #0000
0xc18A [1b 86] LEAS 6,SP
0xc18C [cc 01 00] LDD #0x0100
0xc18F [b7 c5] EXG D,X
0xc191 [6b e2 31 42] STAB 3142,X // first time around
saves spi_test[0x100] with 0x00 (writes after end of array),
// then spi_test[0xff]
with 0xff, etc.
0xc195 [b7 c5] EXG D,X
0xc197 [08] INX
0xc198 [04 34 f4] DBNE D,-C


Then I tried this code:

static unsigned char spi_test1[256];

void fnTest(void)
{
unsigned short i;
unsigned short j = 0;

for (i=0; i < sizeof(spi_test1); i++) {
spi_test1[j++] = (unsigned char)j;
}
}

but the produced assembler code was identical.


The problem was cured only when the following code was used:

static unsigned char spi_test1[256];

void fnTest(void)
{
unsigned short i;
unsigned char j = 0; // unsigned char rather that unsigned
short

for (i=0; i < sizeof(spi_test1); i++) {
spi_test1[j++] = j;
}
}

This is the assembler code which then worked properly (it is quite a
bit longer..):

0xc189 [fd 31 2c] LDY 312c
0xc18C [69 e8 70] CLR 70,Y
0xc18F [1b 86] LEAS 6,SP
0xc191 [ce 01 00] LDX #0100
0xc194 [7e 31 28] STX 3128
0xc197 [ce 31 42] LDX #3142
0xc19A [fd 31 2c] LDY 312c
0xc19D [e6 e8 70] LDAB 70,Y
0xc1A0 [1a e5] LEAX B,X
0xc1A2 [6b 00] STAB 0,X
0xc1A4 [52] INCB
0xc1A5 [6b e8 70] STAB 70,Y
0xc1A8 [fe 31 28] LDX 3128
0xc1AB [09] DEX
0xc1AC [7e 31 28] STX 3128
0xc1AF [26 e6] BNE -1A


Can anyone confirm this or explain why it happens?

regards

Mark Butcher

www.mjbc.ch
 
 
//////////////////////////////////////////////////

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

 

Follow 6 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2005-06-12 ciceron Open/ClosedOpen Closed
2005-06-12 ciceron StatusIn Progress Fixed
2005-04-05 ciceron StatusNeed Info In Progress
2005-04-03 ciceron Assigned toNone ciceron
    Carbon-Copy- Added -email is unavailable-
2005-04-03 ciceron StatusNone Need Info

Back to the top

Powered by Savane 3.13-d3ae.
Corresponding source code