Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!usc!brutus.cs.uiuc.edu!psuvax1!psuvm!DJUKFA11!HBO043
From: HBO043@DJUKFA11.BITNET (Christoph van Wuellen)
Newsgroups: comp.os.minix
Subject: GCC(1.35) compiler error and fix
Message-ID: <MINIX-L%90021912202160@DEARN>
Date: 19 Feb 90 17:17:52 GMT
Sender: Minix operating system <MINIX-L@NDSUVM1>
Reply-To: INFO-MINIX@UDEL.EDU
Lines: 39
Approved: NETNEWS@PSUVM.BITNET Gateway

After tracking down some difficulties with my MINIX-Port to the mc68000
(message follows), I noticed a bug in GCC compiler (version 1.35) when
doing a zero-extend on a quarterword (to a 16-bit-word) while pushing
the resulting value on the stack:
char c; .... test3(c & 0377) produced the following code:

clr.w -(a7)
move.b -1(a6),-(a7)

which is VERY wrong (4 bytes pushed instead of 2, the byte is at the wrong
place. This is, in fact, the strategy to to the extend when loading it into
a data register.

The error is in file m68k.md at line 1167. It is very obvious. Copy the
material for zero-extending a byte to a long from few lines below to this
place, change clr.l to clr.w and the offset 3 to offset 1, and GCC produces
the correct code

clr.w -(a7)
move.b -1(a6),1(a7)

I would like to hear if this error is present in the actual version of GCC
(1.36, I think) so, would everyone try this five-liner:

test()
{
char c;
test1 ( &c); /* this prevents the optimizer from being too skillfull */
test2 (c & 0377);
}

Translate it with -S and -O switches and look at the assembly code.
Please, tell me or post your findings.

If it should be an so-far-unknown bug, we should tell it to the FSF guys.
It seems we are the only group using 16-bit ints, thus the only group where
the error can occur.

Christoph van Wuellen