From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-156613-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 1637 invoked by alias); 18 Sep 2009 13:42:00 -0000
Received: (qmail 1627 invoked by uid 22791); 18 Sep 2009 13:41:58 -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-pz0-f185.google.com (HELO mail-pz0-f185.google.com) (209.85.222.185)     by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 18 Sep 2009 13:41:55 +0000
Received: by pzk15 with SMTP id 15so779526pzk.0         for <gcc@gcc.gnu.org>; Fri, 18 Sep 2009 06:41:53 -0700 (PDT)
Received: by 10.114.162.4 with SMTP id k4mr2431235wae.149.1253281313244;         Fri, 18 Sep 2009 06:41:53 -0700 (PDT)
Received: from Paullaptop (203-214-134-90.perm.iinet.net.au [203.214.134.90])         by mx.google.com with ESMTPS id 22sm525929pzk.10.2009.09.18.06.41.50         (version=SSLv3 cipher=RC4-MD5);         Fri, 18 Sep 2009 06:41:52 -0700 (PDT)
Message-ID: <189DB7AD89504F0FB022373BDCB207A7@Paullaptop>
From: "Paul Edwards" <mutazilah@gmail.com>
To: "Ulrich Weigand" <uweigand@de.ibm.com>
Cc: <gcc@gcc.gnu.org>
References: <200909181327.n8IDRHrs029907@d12av02.megacenter.de.ibm.com>
In-Reply-To: <200909181327.n8IDRHrs029907@d12av02.megacenter.de.ibm.com>
Subject: Re: i370 port
Date: Fri, 18 Sep 2009 13:42: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: <gcc.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
X-SW-Source: 2009-09/txt/msg00322.txt.bz2

> 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)?

I did the latter.

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
(insn 117 429 118 7 (parallel [
            (set (reg:SI 64)
                (compare:SI (mem/s:BLK (plus:SI (reg/f:SI 21 
virtual-stack-vars)

                            (const_int 456 [0x1c8])) [232 value+0 S196 A64])
                    (mem:BLK (plus:SI (reg/v/f:SI 61 [ desc ])
                            (const_int 8 [0x8])) [0 A8])))
            (use (const_int 196 [0xc4]))
        ]) -1 (nil)
    (nil))
varasm.c: In function `force_const_mem':
varasm.c:3021: internal compiler error: in instantiate_virtual_regs_lossage, 
at
function.c:3767
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gccmvs.sourceforge.net> for instructions.


Which would seem to correspond to this:

; Compare a block that is less than 256 bytes in length.

(define_insn ""
  [(set (match_operand:SI 0 "register_operand" "=d")
^I(compare:SI (match_operand:BLK 1 "s_operand" "m")
^I^I (match_operand:BLK 2 "s_operand" "m")))
   (use (match_operand:QI 3 "immediate_operand" "I"))]
  "((unsigned) INTVAL (operands[3]) < 256)"
  "*
{
  check_label_emit ();
  mvs_check_page (0, 22, 0);
  return 
\"CLC^I%O1(%c3,%R1),%2\;BH^I*+12\;BL^I*+6\;SLR^I%0,%0\;LNR^I%0,%0\";
}"
   [(set_attr "length" "22")]
)


> 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).

Ok, I'll see if I can see something.  Probably easier for me to play
around with the md though.

BFN.  Paul.