-mpower4 sched2 bug miscompiles linux kernel

[Alan Modra]

The attached file from current linux kernel sources is miscompiled by
current mainline powerpc64-linux gcc, causing a kernel hang.

compile options:
cc1 -fpreprocessed pty.i -quiet -dumpbase pty.c -msoft-float -mminimal-toc -mcpu=power4 -auxbase pty -O2 -Wall -Wstrict-prototypes -Wno-trigraphs -Wno-uninitialized -version -fomit-frame-pointer -fno-strict-aliasing -fno-common -finline-limit-2000 -o pty.s

Looking at the assignment to pty_driver.init_termios.c_cflag in pty_init:

        pty_driver.init_termios = tty_std_termios;
        pty_driver.init_termios.c_iflag = 0;
        pty_driver.init_termios.c_oflag = 0;
        pty_driver.init_termios.c_cflag = 0000017 | 00001400 | 00004000;
        pty_driver.init_termios.c_lflag = 0;

We see:

[snip]
	ld 31,.LC25-.LCTOC1(30)
	li 4,0
	li 5,328
	li 23,2
	li 22,2831		# 0000017 | 00001400 | 00004000
	mr 3,31
	bl .memset
	nop
	stw 21,52(31)
	stw 22,48(31)		# write it
	li 0,21506
	ld 29,.LC30-.LCTOC1(30)
	ld 7,.LC27-.LCTOC1(30)
	addi 11,31,40		# r11 = &pty_driver.init_termios
				# c_cflag is at r11 + 8
	li 5,328
	stw 0,0(31)
	ld 8,.LC29-.LCTOC1(30)
	mr 4,31
	li 0,256
	ld 26,.LC31-.LCTOC1(30)
	ld 25,.LC32-.LCTOC1(30)
	ld 9,0(29)
	sth 0,32(31)
	li 0,4
	ld 6,8(29)
	ld 3,16(29)
	ld 28,24(29)
	ld 27,32(29)
	lwz 10,40(29)
	ld 24,.LC33-.LCTOC1(30)
	std 9,40(31)
	sth 0,34(31)
	li 9,1
	li 0,6
	std 6,8(11)		# oops, overwrite with tty_std_termios
[snip]

That "stw" certainly percolated a long way!

I haven't really started debugging this, except to find that the bug
appears on the 3.2 branch with the following commit.  I'm hoping
someone can say "Ah ha, I know what this is, you need to..."

date: 2002/08/19 18:59:31;  author: sirl;  state: Exp;  lines: +36 -1
2002-06-24  Jeff Law <law@redhat.com>

	* flow.c (propagate_one_insn): When removing an insn
	with a REG_LIBCALL note but not the entire libcall sequence,
	delete the associated REG_RETVAL note.

2002-06-04  Jeff Law <law@redhat.com.
	    David Edelsohn <edelsohn@gnu.org>
	    Michael Matz <matz@kde.org>

	* sched-int.h (struct deps): New field libcall_block_tail_insn.
	* sched_deps.c (init_deps): Initialize libcall_block_tail_insn.
	* sched_deps.c (sched_analyze_insn): If libcall_block_tail_insn
	is set, then mark the current insn as being part of a libcall
	scheduling group.
	(sched_analyze): Set and clear libcall_block_tail_insn appropriately.

	* haifa-sched.c (schedule_block): Do not count USE or CLOBBER
	insns against the issue rate.

2002-05-30  Jeff Law <law@redhat.com>

	* flow.c (propagate_one_insn): Revise yesterday's patch.  Delete
	a dead insn with a REG_RETVAL note when the entire libcall is not
	dead and remove the associated REG_LIBCALL note at the same time.

2002-05-29  Jeff Law <law@redhat.com>

	* flow.c (propagate_one_insn): Do not remove a dead insn if it
	contains a REG_RETVAL note.

	* haifa-sched (sched_analyze): Remove another useless clearing
	of SCHED_GROUP_P I missed yesterday.

2002-05-28  David Edelsohn  <edelsohn@gnu.org>
	    Jeff Law <law@redhat.com>

	* optabs.c (expand_binop): Fix nwords sign warnings.
	generate pseudo for add_optab.

	* sched-deps.c (sched_analyze): Do not clear SCHED_GROUP_P.
	* haifa-sched.c (move_insn): Clear SCHED_GROUP_P after it is used.

ie. -D"2002-08-20 00:00 UTC" -rgcc-3_2-branch is bad,
-D"2002-08-19 00:00 UTC" -rgcc-3_2-branch is good.

Note that the gcc-3.2 branch doesn't support power4 without some
patches.  You can grab David Edelsohn's patch for power4 support
from mainline with:
cvs diff -D"2002-06-08 UTC" -D"2002-06-10 UTC" > /tmp/power4.diff
then apply this to the branch.  At least, this works for the purpose
of debugging this particular problem.  I haven't checked that just
this patch alone is all that is required for power4 support on the
branch.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pty.i.gz
Type: application/x-gunzip
Size: 53228 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-bugs/attachments/20020908/e2220fb8/attachment.bin>