From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18425 invoked by alias); 29 Nov 2009 07:57:15 -0000 Received: (qmail 18404 invoked by uid 22791); 29 Nov 2009 07:57:14 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-gx0-f228.google.com (HELO mail-gx0-f228.google.com) (209.85.217.228) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 29 Nov 2009 07:57:08 +0000 Received: by gxk28 with SMTP id 28so453834gxk.9 for ; Sat, 28 Nov 2009 23:57:06 -0800 (PST) Received: by 10.150.213.6 with SMTP id l6mr4839154ybg.87.1259481426082; Sat, 28 Nov 2009 23:57:06 -0800 (PST) Received: from Paullaptop (203-158-49-56.dyn.iinet.net.au [203.158.49.56]) by mx.google.com with ESMTPS id 14sm512674gxk.6.2009.11.28.23.57.02 (version=SSLv3 cipher=RC4-MD5); Sat, 28 Nov 2009 23:57:03 -0800 (PST) Message-ID: <07600C4C9EAE47ADB6B1F8C655EDE27E@Paullaptop> From: "Paul Edwards" To: "Richard Guenther" Cc: Subject: Re: i370 port - music/sp - possible generic gcc problem Date: Sun, 29 Nov 2009 07:57:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=response Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-11/txt/msg00804.txt.bz2 > : In function `acos': > :137: Internal compiler error in ?, at :724 > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > > I might be able to trace it from a different approach, getting more > information about that internal error, now that I know where some > of the involved memory is. I'll get that converted into a > PC filename first. 6 hours of compilation later, I was unsuccessful in getting the proper filename displayed. As far as I can tell, it's aborting but not displaying any output. ie randomly displaying the above message. However, not to worry, since there's only one line 724 with an abort() in it, and it's this bit of code: static int insert_save (chain, before_p, regno, to_save, save_mode) struct insn_chain *chain; int before_p; int regno; HARD_REG_SET *to_save; enum machine_mode *save_mode; { int i; unsigned int k; rtx pat = NULL_RTX; int code; unsigned int numregs = 0; struct insn_chain *new; rtx mem; /* A common failure mode if register status is not correct in the RTL is for this routine to be called with a REGNO we didn't expect to save. That will cause us to write an insn with a (nil) SET_DEST or SET_SRC. Instead of doing so and causing a crash later, check for this common case and abort here instead. This will remove one step in debugging such problems. */ if (regno_save_mem[regno][1] == 0) abort (); which is in the same file as the init_caller_save() function that allocated the memory in the first place. One fortunate thing is that this source file is under 1000 lines long so hopefully amenable to debugging. BFN. Paul.