From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10757 invoked by alias); 25 Sep 2009 07:21:01 -0000 Received: (qmail 10744 invoked by uid 22791); 25 Sep 2009 07:20:59 -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-px0-f191.google.com (HELO mail-px0-f191.google.com) (209.85.216.191) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 25 Sep 2009 07:20:54 +0000 Received: by pxi29 with SMTP id 29so2783464pxi.14 for ; Fri, 25 Sep 2009 00:20:53 -0700 (PDT) Received: by 10.114.242.2 with SMTP id p2mr5993607wah.153.1253863253178; Fri, 25 Sep 2009 00:20:53 -0700 (PDT) Received: from Paullaptop (124-170-16-182.dyn.iinet.net.au [124.170.16.182]) by mx.google.com with ESMTPS id 20sm761066pzk.5.2009.09.25.00.20.49 (version=SSLv3 cipher=RC4-MD5); Fri, 25 Sep 2009 00:20:50 -0700 (PDT) Message-ID: <0C24A544AA784F4BAFF30DE39853866C@Paullaptop> From: "Paul Edwards" To: "Ulrich Weigand" Cc: References: <200909181608.n8IG8Dqi000786@d12av02.megacenter.de.ibm.com> In-Reply-To: <200909181608.n8IG8Dqi000786@d12av02.megacenter.de.ibm.com> Subject: Re: i370 port Date: Fri, 25 Sep 2009 10:19: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-09/txt/msg00531.txt.bz2 Ulrich, here's one of the workarounds I mentioned. The other one is pretty similar to this one as well. After my investigation, I've come to the conclusion that this never worked, and was not noticed before, because the optimizer mustn't have ever used it before. As such, it's appropriate to simply comment it out (which was my "workaround"). However, before I do so, do you think this is close to being correct? I already made one correction, to put in that XL1 rather than doing a fullword (which was always zero obviously). (define_insn "movstrictqi" [(set (strict_low_part (match_operand:QI 0 "nonimmediate_operand" "+d")) (match_operand:QI 1 "general_operand" "g"))] "" "* { check_label_emit (); if (REG_P (operands[1])) { mvs_check_page (0, 8, 0); return \"STC^I%1,\" CONVLO \"(,13)\;IC^I%0,\" CONVLO \"(,13)\"; } mvs_check_page (0, 4, 0); return \"IC^I%0,=XL1'%X1'\"; }" [(set_attr "length" "8")] ) The trouble is that when the instruction is active, things like this happen: C:\devel\gccnew\gcc>diff -c6 old\alias.s new\alias.s | head -50 *** old\alias.s Tue Sep 22 09:37:45 2009 --- new\alias.s Fri Sep 25 16:38:31 2009 *************** *** 277,290 **** L26 EQU * N 2,=XL4'000000FF' LA 3,242(0,0) CR 2,3 BE L30 BH L45 ! LA 3,241(0,0) ! CLR 2,3 BE L28 B L44 L45 EQU * LA 3,243(0,0) CLR 2,3 BE L37 --- 277,289 ---- L26 EQU * N 2,=XL4'000000FF' LA 3,242(0,0) CR 2,3 BE L30 BH L45 ! IC 3,=XL1'F1' BE L28 B L44 L45 EQU * LA 3,243(0,0) CLR 2,3 BE L37 Which I can clearly see is different. Specifically, the IC by itself is fine, although I would have preferred to see the LA instruction there, but for some reason it is dropping the CLR. That makes it technically incorrect. I checked the S/370 reference summary, and IC doesn't set the condition code, and nor does the instruction pattern mention condition codes anywhere. Normally I would be suspicious of the rest of the compiler, but in this case, I know that the compiler is stable and the i370 target is dubious. :-) After resolution of this one way or another, I think it's in a good enough state for version 1.0 and will start on the preparations for all that. BFN. Paul.