From nobody Fri Jul 26 14:03:47 2002 From: Hartmut Penner Subject: PR 7409/Loop optimization bug patch To: mark@codesourcery.com, gcc-patches@gcc.gnu.org Cc: uweigand@de.ibm.com Date: Thu, 25 Jul 2002 19:53:53 +0200 A proposed patch for problem described in PR7409 is appended here. The problem was, that the usage of a register as a parameter was not taken into acount in the function find_single_use_in_loop. Index: loop.c =================================================================== RCS file: /cvs/gcc/gcc/gcc/loop.c,v retrieving revision 1.389.2.7 diff -u -r1.389.2.7 loop.c --- loop.c 15 Jun 2002 01:12:04 -0000 1.389.2.7 +++ loop.c 25 Jul 2002 17:41:28 -0000 @@ -3470,6 +3470,19 @@ const char *fmt = GET_RTX_FORMAT (code); int i, j; + if (x == PATTERN (insn) && GET_CODE (insn) == CALL_INSN) + { + rtx link; + for (link = CALL_INSN_FUNCTION_USAGE (insn); link; link = XEXP (link, 1)) + { + rtx op, reg; + + if (GET_CODE (op = XEXP (link, 0)) == USE + && GET_CODE (reg = XEXP (op, 0)) == REG) + regs->array[REGNO (reg)].single_usage = const0_rtx; + } + } + if (code == REG) regs->array[REGNO (x)].single_usage = (regs->array[REGNO (x)].single_usage != 0 Mit freundlichem Gruß / Best regards, Hartmut Penner GCC for S/390 Development ------------------------------------------------------------------------- Ja, das ist das Problem, unser Register 6 handling (parameter & call saved) ist sehr eigen, deshalb ist es wohl auch noch nicht auf anderen Systemen aufgetreten. Der Fix erscheint mir gut, sollte aber einen intensiven Test erfahren. Ich kann das Problem un den potentiellen Fix ja mal auf der GCC mailing list posten, vielleicht macht er es ja noch in 3.1.1... Mit freundlichem Gruß / Best regards, Hartmut Penner GCC for S/390 Development Internet Mail Address : hpenner@de.ibm.com ---------------------------------------------------------------------------- Hallo Hartmut, hallo Bernd, das Problem ist, dass der Use von Register 6 in der Call-Insn von find_single_use_in_loop ignoriert wird; deshalb denkt er, dass Reg 6 einmal vor dem Call gesetzt und einmal nach dem Call benutzt wird, und verschiebt das Setzen an die Stelle, wo es benutzt wird. Das ist natürlich dann falsch, wenn ein call-saved register vom Call selbst benutzt wird! Dieser Patch fixt das Problem erst mal, aber man muss das trotzdem noch ordentlich testen und mit den gcc-Leuten diskutieren. Das kann ich von hier aus schlecht machen ... Mit freundlichen Gruessen / Best Regards Ulrich Weigand ---------------------------------------------------------------------------- From: Bernhard Kaindl To: HPENNER@de.ibm.com, Volker Tosta Cc: Ulrich.Weigand@de.ibm.com, Marcus Kraft , Susanne Oberhauser Date: Thu, 25 Jul 2002 12:39:34 +0200 (CEST) Subject: call of function misses to pass value on the stack (fwd) Hallo Volker, Hallo Hartmut, Dieser Bug bewirkt, dass ein Compile von tcl, solange man keinen Workaround benutzt, ein Binary ergibt, das sich sofort beim Start mit einen Bus Error verabschiedet. Ich kann den Fehler auf s390x mit -O1 auf reproduzieren. Testcase: tar xvfz tclUtil.tar.gz (attacht) drwxr-xr-x nobody/nogroup 0 2002-07-25 02:42:01 tclUtil/ -rw-r--r-- nobody/nogroup 292056 2002-07-25 02:22:10 tclUtil/tclUtil.i -rw-r--r-- nobody/nogroup 550612 2002-07-25 02:27:18 tclUtil/tclUtil.s.fixed -rw-r--r-- nobody/nogroup 550589 2002-07-25 02:22:13 tclUtil/tclUtil.s.bad cd tclUtil cc -S -g -O1 -fPIC tclUtil.i (das .i ist mit meinel letzten s390x-gcc erzeugt) Bei mir kommt dann das tclUtil.s.bad raus. bad, weil in Tcl_SplitList beim Aufruf von TclFindElement das Argument 5, (char **) &list nicht uebergeben wird. Das ist der Aufruf ("TclFindElement@PLT" kommt im .s nur einmal vor): lgfr %r4,%r8 la %r1,184(%r15) stg %r1,160(%r15) la %r1,188(%r15) stg %r1,168(%r15) lg %r2,200(%r15) lgr %r3,%r10 la %r5,192(%r15) + la %r6,176(%r15) brasl %r14,TclFindElement@PLT Die Zeile mit dem + vorne bekomme ich aber nur, wenn ich weiter oben ein printf einbaue, und dann tut es auch. Die Zeile aus dem anderen .i-File zu nehmen und nur die ein das tclUtil.s.bad einzutragen fixt es auch. Mit -O0 und -O2 tritt es auch nicht auf. Ist es bei euch reproduzieren? Der Testcase ist hier Downloadbar: http://www.suse.de/~bk/gcc/testcases/tclUtil