From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27195 invoked by alias); 18 Sep 2009 13:27:27 -0000 Received: (qmail 27180 invoked by uid 22791); 18 Sep 2009 13:27:25 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mtagate6.de.ibm.com (HELO mtagate6.de.ibm.com) (195.212.17.166) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 18 Sep 2009 13:27:21 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate6.de.ibm.com (8.13.1/8.13.1) with ESMTP id n8IDRJqJ030239 for ; Fri, 18 Sep 2009 13:27:19 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n8IDRIrW2850818 for ; Fri, 18 Sep 2009 15:27:18 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n8IDRI3j029946 for ; Fri, 18 Sep 2009 15:27:18 +0200 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id n8IDRHrs029907; Fri, 18 Sep 2009 15:27:17 +0200 Message-Id: <200909181327.n8IDRHrs029907@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Fri, 18 Sep 2009 15:27:17 +0200 Subject: Re: i370 port To: mutazilah@gmail.com (Paul Edwards) Date: Fri, 18 Sep 2009 13:27:00 -0000 From: "Ulrich Weigand" Cc: gcc@gcc.gnu.org In-Reply-To: from "Paul Edwards" at Sep 18, 2009 10:23:01 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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-09/txt/msg00320.txt.bz2 Paul Edwards wrote: > And as I mentioned, there's just one real bug that I know of left. I can > bypass the bug in the GCC code that I am compiling, by forcing a > function call. > > C:\devel\gccnew\gcc>gccmvs -DUSE_MEMMGR -Os -S -ansi -pedantic-errors -DHAVE_CON > FIG_H -DIN_GCC -DPUREISO -I ../../pdos/pdpclib -I . -I config/i370 -I > ../include > varasm.c > varasm.c: In function `force_const_mem': > varasm.c:3021: internal compiler error: in instantiate_virtual_regs_lossage, > at > function.c:3765 > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. That's a bit hard to diagnose without some further information ... What insn it is failing on? (To find out, use a debugger, or maybe add a "debug_rtx (insn)" statement before the abort in instantiate_virtual_regs_lossage)? > which is bizarre. It seems to be comparing two values that are 8 bytes > apart, for a length of 196. Can't imagine that doing anything useful. This is conceivably another effect of the same bug, but again it's hard to say. You'd have to look at the generated RTX and see how it changes over the various optimization stages (use -da to generate RTX dumps after each stage). Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com