From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8155 invoked by alias); 2 Dec 2009 22:03:39 -0000 Received: (qmail 8009 invoked by uid 22791); 2 Dec 2009 22:03:38 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-yx0-f195.google.com (HELO mail-yx0-f195.google.com) (209.85.210.195) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 02 Dec 2009 22:03:32 +0000 Received: by yxe33 with SMTP id 33so925874yxe.0 for ; Wed, 02 Dec 2009 14:03:30 -0800 (PST) Received: by 10.150.102.37 with SMTP id z37mr1358500ybb.69.1259791410311; Wed, 02 Dec 2009 14:03:30 -0800 (PST) Received: from Paullaptop (203-158-49-56.dyn.iinet.net.au [203.158.49.56]) by mx.google.com with ESMTPS id 15sm791803gxk.0.2009.12.02.14.03.24 (version=SSLv3 cipher=RC4-MD5); Wed, 02 Dec 2009 14:03:26 -0800 (PST) Message-ID: <5380649C84CD4BC0B9CCB1657A6C8FA6@Paullaptop> From: "Paul Edwards" To: "Ian Lance Taylor" Cc: "Ulrich Weigand" , References: <200911041646.nA4Gkx1m032222@d12av02.megacenter.de.ibm.com><49D99EB7E50944F4A09820F1016ACA77@Paullaptop> In-Reply-To: Subject: Re: i370 port Date: Wed, 02 Dec 2009 22:03:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original 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-12/txt/msg00024.txt.bz2 >>> I think I would stop right there. Why can't the i370 port support >>> 64-bit integers? Plenty of 32-bit hosts support them. >> >> It got an internal error. I don't have the skills to get that to work, >> but I do have the skills to bypass it one way or another (and I >> demonstrated what I am doing now, but I know that that >> intrusive code will break everything else, so want to back it out, >> without losing the functionality that I want). > > A failure in your target is not a reason to change target-independent > code. Well I found out what was causing this - the adddi3 definition. Commenting that out allowed the target to be built the normal way. However, when doing the host build, I wanted everything done by the (ansi) book so that I end up with code that can be compiled with a C90 compiler, be it IBM's C/370 or Borland C++. I found that I could achieve that by making my dummy cross-compile script introduce the -ansi -pedantic-errors options. However, that triggered off some more changes to configure like this ... Index: gccnew/libiberty/configure diff -c gccnew/libiberty/configure:1.1.1.3 gccnew/libiberty/configure:1.25 *** gccnew/libiberty/configure:1.1.1.3^ISun Nov 15 19:41:46 2009 --- gccnew/libiberty/configure^IWed Dec 2 17:18:07 2009 *************** *** 4190,4196 **** #if defined (__stub_$ac_func) || defined (__stub___$ac_func) choke me #else ! char (*f) () = $ac_func; #endif #ifdef __cplusplus } --- 4190,4196 ---- #if defined (__stub_$ac_func) || defined (__stub___$ac_func) choke me #else ! char (*f) () = (char (*)())$ac_func; #endif #ifdef __cplusplus } *************** *** 4199,4205 **** int main () { ! return f != $ac_func; ; return 0; } --- 4199,4205 ---- int main () { ! return f != (char (*)())$ac_func; ; return 0; } I still haven't found the wild pointer in my GCC 3.2.3 port that gets masked with xcalloc. It's a tough one because the problem keeps on disappearing whenever I try to introduce debug info and I haven't found a technique yet. So I'm working on 3.2.3, 3.4.6 and 4.4 at any particular time. :-) BFN. Paul..