[gnu.gcc.bug] '-fstrength-reduce' can produce bad code in GCC 1.30

lgm@ODDJOB.UCHICAGO.EDU (11/14/88)

SYNOPSIS:
The new '-fstrength-reduce' flag can produce incorrect code in
certain circumstances.  The example below shows incorrect assembly
language using '-O -fstrength-reduce'; '-O' alone generates correct
code.

The example is simplified from "genemit.c".  Even after circumventing
this problem, 'cpp' and 'cc1' compile with '-fstrength-reduce' but
promptly core-dump when attempting to compile themselves.

MACHINE AND OS:
AT&T UNIX PC 3B1 (based on Motorola 68010 microprocessor) running
OS Version 3.5 (compatible with UNIX System V Release 2).

CONFIGURATION FILES:
(usual for the UNIX PC)
"tm-3b1.h"
"config-3b1.h"
"m68k.md"
"output-m68k.c"

TRANSCRIPT (INPUT FILE, COMMAND LINE, OUTPUT):
_______________________________________
$ cat emit.c
extern	void	f();

struct	S {
	int	c;
	struct	S	*s[ 1 ];
};

void
g( x, y )
struct	S	*x;
int	y;
{
	register	int	m = x->s[ y ]->c;
	register	int	i;

	for ( i = 0; i < m; ++i )
		f( x->s[ y ]->s[ i ] );
}
$ ../src/gcc -B../src/ -v -S -O -fstrength-reduce emit.c
gcc version 1.30
 ../src/cpp -v -undef -D__GNU__ -D__GNUC__ -Dmc68k -Dunix -Dunixpc -D__OPTIMIZE__ emit.c /tmp/cca13712.cpp
GNU CPP version 1.30
 ../src/cc1 /tmp/cca13712.cpp -quiet -dumpbase emit.c -fstrength-reduce -O -version -o emit.s
GNU C version 1.30 (68k, SGS/AT&T unixpc syntax) compiled by GNU C version 1.30.
$ cat emit.s
	file	"emit.c"
text
	even
	global g
g:
	link.w %a6,&0
	movm.l &0x3820,-(%sp)
	mov.l 8(%fp),%a1
	mov.l 12(%fp),%d1
	mov.l %d1,%d0
	asl.l &2,%d0
	mov.l 4(%a1,%d0.l),%a0
	clr.l %d4
	cmp.l %d4,(%a0)
	bge.w L%6
	mov.l %d1,%d0
	asl.l &2,%d0
	lea 4(%a1,%d0.l),%a2
	clr.l %d2
	add.l %d2,%d3		#  %d3  has no meaningful value here.
L%5:
	mov.l (%a2),%a0
	add.l %d2,%a0
	mov.l 4(%a0),-(%sp)
	jsr f
	addq.w &4,%sp
	addq.l &4,%d2
	cmp.l %d3,%d2		#  %d3  is still meaningless here.
	bgt.w L%5
L%6:
	movm.l -16(%a6),&0x41c
	unlk %a6
	rts
$
_______________________________________

EXPLANATION OF TRANSCRIPT:
The generated assembly language above *uses*  %d3  without ever
assigning a meaningful value to it.  I suspect  %d3  was meant to
hold  (%a0) , which would be the correct value to add to and later
compare against.


	Lawrence G. Mayka
	Aurora, Illinois

	chinet!lmayk!lgm