From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31544 invoked by alias); 11 Feb 2003 22:51:19 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 31516 invoked from network); 11 Feb 2003 22:51:18 -0000 Received: from unknown (HELO hiauly1.hia.nrc.ca) (132.246.100.193) by 172.16.49.205 with SMTP; 11 Feb 2003 22:51:18 -0000 Received: from hiauly1.hia.nrc.ca (localhost [127.0.0.1]) by hiauly1.hia.nrc.ca (8.12.0.Beta16/8.12.0.Beta16) with ESMTP id h1BMpBot003138; Tue, 11 Feb 2003 17:51:12 -0500 (EST) Received: (from dave@localhost) by hiauly1.hia.nrc.ca (8.12.0.Beta16/8.12.0.Beta16) id h1BMpA5h003137; Tue, 11 Feb 2003 17:51:10 -0500 (EST) Message-Id: <200302112251.h1BMpA5h003137@hiauly1.hia.nrc.ca> Subject: Re: Bootstrap failure on hppa-unknown-linux-gnu, trunk To: zlomj9am@artax.karlin.mff.cuni.cz (Josef Zlomek) Date: Tue, 11 Feb 2003 22:51:00 -0000 From: "John David Anglin" Cc: gcc@gcc.gnu.org, gcc-patches@gcc.gnu.org In-Reply-To: <20030211223743.GA9891@artax.karlin.mff.cuni.cz> from "Josef Zlomek" at Feb 11, 2003 11:37:43 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SW-Source: 2003-02/txt/msg00886.txt.bz2 > > > stage1/xgcc -Bstage1/ -B/home/dave/opt/gnu/hppa-linux/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -fno-common -Werror -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/config -I../../gcc/gcc/../include > > > ../../gcc/gcc/bb-reorder.c -o bb-reorder.o > > > ../../gcc/gcc/bb-reorder.c: In function `find_traces': > > > ../../gcc/gcc/bb-reorder.c:219: error: unrecognizable insn: > > > (insn 776 775 777 0x40568f60 (set (reg:DI 70 %fr23 [252]) > > > (mult:DI (zero_extend:DI (reg:SI 69 %fr22R [246])) > > > (reg:DI 74 %fr25))) -1 (nil) > > > (expr_list:REG_UNUSED (reg:SI 71 %fr23R) > > > (expr_list:REG_DEAD (reg:DI 74 %fr25) > > > (nil)))) > > > ../../gcc/gcc/bb-reorder.c:219: internal compiler error: in num_delay_slots, at insn-attrtab.c:4085 > > > > I have determined that it is the addition of this patch that results in > > the above ICE: > > > > 2003-02-10 Josef Zlomek > > > > * Makefile.in (bb-reorder.o): Add dependency on $(FIBHEAP_H). > > * bb-reorder.c (make_reorder_chain): Deleted. > > (make_reorder_chain_1): Deleted. > > (find_traces): New function. > > (rotate_loop): New function. > > (mark_bb_visited): New function. > > (find_traces_1_round): New function. > > (copy_bb): New function. > > (bb_to_key): New function. > > (better_edge_p): New function. > > (connect_traces): New function. > > (copy_bb_p): New function. > > (get_uncond_jump_length): New function. > > (reorder_basic_blocks): Use new functions (Software Trace Cache). > > * cfgcleanup.c (outgoing_edges_match): Enable crossjumping across loop > > boundaries. > > I apologize for the breakage. It seems that new bb-reorder has uncovered > bugs in machine descriptions. > Honza Hubicka has checked in a patch > (http://gcc.gnu.org/ml/gcc-patches/2003-02/msg00847.html) > which hopefully should enable gcc to bootstrap again. I have been looking at the patterns which use the xmpyu insn on the PA. There are two patterns (32 and 64 bit) which have an uint32_operand predicate and "f" constraint. The "f" constraint is inconsistent with the predicate. The uint32_operand predicate is inconsistent with the actual capability of the machine instruction. I had queried Jeff Law about this in the past. This was his response: > I thought changing the operands of the pattern to register_operand is a more > accurate description of the machine insn although reloads still can > potentially occur. It's certainly more accurate, but due to secondary effects of register allocation and reloading it's actually more profitable to be more general in the operand predicates than what the instruction actually allows. That is generally a bad thing to do, but from time to time it is helpful. Basically, some games are being played with the predicate and constraint to improve the generated code. The 32-bit seems to be building again. However, the have been some "strange" warning messages on hppa64-hp-hpux11.11: g-yacc.29398.c: In function `yystrlen': g-yacc.29398.c:708: warning: traditional C rejects ISO C style function definiti ons g-yacc.29398.c: In function `yystpcpy': g-yacc.29398.c:733: warning: traditional C rejects ISO C style function definiti ons g-yacc.29398.c: In function `yydestruct': g-yacc.29398.c:800: warning: traditional C rejects ISO C style function definiti ons g-yacc.29398.c: In function `yyparse': g-yacc.29398.c:863: warning: traditional C rejects ISO C style function definiti ons and c-p29635.c: In function `yy_stack_print': c-p29635.c:2150: warning: traditional C rejects ISO C style function definitions c-p29635.c: In function `yy_reduce_print': c-p29635.c:2176: warning: traditional C rejects ISO C style function definitions c-p29635.c: In function `yysymprint': c-p29635.c:2297: warning: traditional C rejects ISO C style function definitions c-p29635.c: In function `yydestruct': c-p29635.c:2333: warning: traditional C rejects ISO C style function definitions c-p29635.c: In function `yyparse': c-p29635.c:2396: warning: traditional C rejects ISO C style function definitions Possibly, this is a bison 1.875 problem. Yes, it seems to be. Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605)