From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21142 invoked by alias); 2 Jul 2007 20:08:01 -0000 Received: (qmail 21110 invoked by alias); 2 Jul 2007 20:07:51 -0000 Date: Mon, 02 Jul 2007 20:08:00 -0000 Message-ID: <20070702200751.21109.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug middle-end/32398] [4.3 Regression] checking for suffix of object files... configure: error: cannot compute suffix of f object files: cannot compile In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "dave at hiauly1 dot hia dot nrc dot ca" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2007-07/txt/msg00223.txt.bz2 ------- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-02 20:07 ------- Subject: Re: [4.3 Regression] checking for suffix of object files... configure: error: cannot compute suffix of f objeRO > Can you send me, the dump produced by -fdump-rtl-expand with the trunk and also > revision 125754. I am 99% sure this was exposed by pointer plus. The problem doesn't appear to be in expand. This is the difference between the assembly code generated with and without -fno-schedule-insns, respectively: --- pr32398.s1 Mon Jul 2 15:08:11 2007 +++ pr32398.s Mon Jul 2 15:06:55 2007 @@ -9,24 +9,24 @@ f: .ENTRY std %r2,-16(%r30) ldo 144(%r30),%r30 + extrd,s %r26,63,32,%r31 std %r4,-128(%r30) - std %r26,-64(%r29) - extrd,s %r26,63,32,%r26 std %r25,-56(%r29) + ldo -56(%r29),%r29 std %r24,-48(%r29) std %r23,-40(%r29) std %r22,-32(%r29) std %r21,-24(%r29) std %r20,-16(%r29) std %r19,-8(%r29) - ldo -56(%r29),%r29 - cmpib,>= 0,%r26,L$0002 + std %r26,-64(%r29) + cmpib,>= 0,%r31,L$0002 std %r29,-136(%r30) ldi 0,%r28 L$0003: ldo 1(%r28),%r28 extrd,s %r28,63,32,%r28 - cmpb,< %r28,%r26,L$0003 + cmpb,< %r28,%r31,L$0003 ldo 8(%r29),%r29 std %r29,-136(%r30) L$0002: The problem is the "ldo -56(%r29),%r29" insn has been moved forward before the argument saves to the stack. r29 is the incoming argument pointer. This occurs in the sched1 pass where the following rtl is generated: (insn 13 8 21 2 pr32398.c:7 (set (mem:DI (plus:DI (reg/f:DI 29 %r29) (const_int -56 [0xffffffffffffffc8])) [0 S8 A64]) (reg:DI 25 %r25)) 124 {*pa.md:4572} (expr_list:REG_DEAD (reg:DI 25 %r25) (nil))) (insn 21 13 7 2 pr32398.c:7 (set (reg/f:DI 78) (plus:DI (reg/f:DI 29 %r29) (const_int -56 [0xffffffffffffffc8]))) 164 {*pa.md:5412} (expr_list:REG_DEAD (reg/f:DI 29 %r29) (nil))) (insn 7 21 14 2 pr32398.c:2 (set (reg/v:DI 75 [ n ]) (sign_extend:DI (reg:SI 26 %r26 [ n+-4 ]))) 143 {extendsidi2} (expr_list:REG_DEAD (reg:SI 26 %r26 [ n+-4 ]) (nil))) (insn 14 7 15 2 pr32398.c:7 (set (mem:DI (plus:DI (reg/f:DI 29 %r29) (const_int -48 [0xffffffffffffffd0])) [0 S8 A64]) (reg:DI 24 %r24)) 124 {*pa.md:4572} (expr_list:REG_DEAD (reg:DI 24 %r24) (nil))) The problem is the REG_DEAD note for r29. r19 isn't dead after insn 21. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32398