From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13161 invoked by alias); 6 Jun 2009 15:00:46 -0000 Received: (qmail 13153 invoked by uid 22791); 6 Jun 2009 15:00:45 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-pz0-f173.google.com (HELO mail-pz0-f173.google.com) (209.85.222.173) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 06 Jun 2009 15:00:38 +0000 Received: by pzk3 with SMTP id 3so61041pzk.0 for ; Sat, 06 Jun 2009 08:00:36 -0700 (PDT) Received: by 10.143.4.16 with SMTP id g16mr1625259wfi.139.1244300436307; Sat, 06 Jun 2009 08:00:36 -0700 (PDT) Received: from Paullaptop (203-206-7-21.dyn.iinet.net.au [203.206.7.21]) by mx.google.com with ESMTPS id 31sm3434259wff.4.2009.06.06.08.00.33 (version=SSLv3 cipher=RC4-MD5); Sat, 06 Jun 2009 08:00:35 -0700 (PDT) Message-ID: <25D4C7F8A9394EA2A1A2D67B1DFF6472@Paullaptop> From: "Paul Edwards" To: "Daniel Jacobowitz" Cc: "Ulrich Weigand" , References: <200906051520.n55FKg7T016481@d12av02.megacenter.de.ibm.com> <69CCB0B6B70141F0BCD2BAFA6DDF314F@Paullaptop> <20090605154849.GA12676@caradoc.them.org> In-Reply-To: <20090605154849.GA12676@caradoc.them.org> Subject: Re: i370 port Date: Sat, 06 Jun 2009 15:00: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-06/txt/msg00128.txt.bz2 > Why are you migrating to 3.4.6 now, instead of to a current version? > If you want to include this in mainline some day, then eventually it > has to be caught up - and 3.4.6 is older than it may appear from the > release date, since it branched off of mainline five years ago. A lot > has changed since then. A question about those changes. One of the things that I experienced when porting 3.2.3 to MVS was that GCC was sensitive to the exact floating point representation. Register selection was different depending on those slight differences. Below is what documentation I have for it. Dave Edwards, who wrote another S/370 emulator, was the one who discovered that. Does anyone know if that was changed somewhere along the line? BFN. Paul. 17. The assembler code generated by gccmvs when run on the PC is slightly different (even when the same parameters are used for code generation) from that when run on the mainframe, if -O2 is used instead of -Os. But functionally equivalent. This non-deterministic nature of the compiler is disconcerting. It seems to not always allocate registers consistently. This has been traced to floating point code in predict.c and local-alloc.c which is sensitive to the very small changes in floating point representation. This should be changed to include deltas when comparing floating point values. Here's an example of what's happening: *** c-lex.s Mon Jan 14 20:48:35 2008 --- temp.dat Mon Jan 14 21:14:04 2008 *************** *** 1328,1335 **** SLR 15,15 STC 15,0(3,4) SLR 6,6 - LR 9,6 LR 8,6 L 2,192(13) CLR 2,5 BNL L303 --- 1328,1335 ---- SLR 15,15 STC 15,0(3,4) SLR 6,6 LR 8,6 + LR 9,6 L 2,192(13) CLR 2,5 BNL L303