From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-156928-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 23277 invoked by alias); 30 Sep 2009 12:40:48 -0000
Received: (qmail 23268 invoked by uid 22791); 30 Sep 2009 12:40:47 -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 fg-out-1718.google.com (HELO fg-out-1718.google.com) (72.14.220.156)     by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 30 Sep 2009 12:40:43 +0000
Received: by fg-out-1718.google.com with SMTP id d23so1858672fga.8         for <gcc@gcc.gnu.org>; Wed, 30 Sep 2009 05:40:41 -0700 (PDT)
Received: by 10.86.158.29 with SMTP id g29mr5212893fge.4.1254314441031;         Wed, 30 Sep 2009 05:40:41 -0700 (PDT)
Received: from ?192.168.2.99? (cpc2-cmbg8-0-0-cust61.cmbg.cable.ntl.com [82.6.108.62])         by mx.google.com with ESMTPS id 4sm29068fgg.19.2009.09.30.05.40.39         (version=SSLv3 cipher=RC4-MD5);         Wed, 30 Sep 2009 05:40:40 -0700 (PDT)
Message-ID: <4AC3552F.80204@gmail.com>
Date: Wed, 30 Sep 2009 14:41:00 -0000
From: Dave Korn <dave.korn.cygwin@googlemail.com>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: daniel tian <daniel.xntian@gmail.com>
CC: gcc@gcc.gnu.org, Ian Lance Taylor <iant@google.com>,   Dave Korn <dave.korn.cygwin@googlemail.com>,  peng.zheng@mavrixtech.com
Subject: Re: SUBREG Unrecognizable RTL
References: <121fadb80909300017y2041da80o87ef26f7e15a794f@mail.gmail.com> <121fadb80909300053o7dc796d8y3c8e60028e7652e@mail.gmail.com>
In-Reply-To: <121fadb80909300053o7dc796d8y3c8e60028e7652e@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
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/msg00637.txt.bz2

daniel tian wrote:
> here are some information from the libgcc2.c.176r.greg. (BTY: the
> error happened when cc1 build the libgcc2.c)
> 
> Reloads for insn # 147
> Reload 0: reload_out (SI) = (reg/v:SI 99 [ __d0 ])
> 	GENERAL_REGS, RELOAD_FOR_OUTPUT (opnum = 0)
> 	reload_out_reg: (reg/v:SI 99 [ __d0 ])
> 	reload_reg_rtx: (reg:SI 5 R5)
> Reload 1: reload_in (HI) = (subreg:HI (reg/v:SI 94 [ d0 ]) 0)
> 	GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 1)
> 	reload_in_reg: (subreg:HI (reg/v:SI 94 [ d0 ]) 0)
> 	reload_reg_rtx: (reg:HI 5 R5)
> 
> So does it mean when the pseduo register 94 allocated fail, the memory
> location will be substitute ?

  Yes, when the register allocator can't find a spare register for a variable,
it makes use of a stack slot instead.

> (insn 749 156 147 22 (set (reg:HI 5 R5)
>         (subreg:HI (mem/c:SI (plus:SI (reg/f:SI 15 R15)
>                     (const_int 108 [0x6c])) [19 d0+0 S4 A32]) 0)) -1 (nil))

  So, does your CPU support HImode sized load and store operations?

    cheers,
      DaveK