From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-71712-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 21109 invoked by alias); 10 Apr 2003 20:43:25 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
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
Received: (qmail 21085 invoked from network); 10 Apr 2003 20:43:25 -0000
Received: from unknown (HELO mail-out2.apple.com) (17.254.0.51)
  by sources.redhat.com with SMTP; 10 Apr 2003 20:43:25 -0000
Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225])
	by mail-out2.apple.com (8.12.9/8.12.9) with ESMTP id h3AKhOQd019081
	for <gcc@gcc.gnu.org>; Thu, 10 Apr 2003 13:43:24 -0700 (PDT)
Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T6184398830118064e170c@mailgate1.apple.com>;
 Thu, 10 Apr 2003 13:43:10 -0700
Received: from apple.com (johada5.apple.com [17.201.20.185])
	by scv1.apple.com (8.12.9/8.12.9) with ESMTP id h3AKhJVX009347;
	Thu, 10 Apr 2003 13:43:19 -0700 (PDT)
Date: Thu, 10 Apr 2003 20:51:00 -0000
Subject: Re: Reload bug
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
Cc: Dale Johannesen <dalej@apple.com>, Jan Hubicka <jh@suse.cz>,
   gcc@gcc.gnu.org
To: Eric Botcazou <ebotcazou@libertysurf.fr>
From: Dale Johannesen <dalej@apple.com>
In-Reply-To: <200304102200.35188.ebotcazou@libertysurf.fr>
Message-Id: <F42911E8-6B94-11D7-A9B8-000393D76DAA@apple.com>
Content-Transfer-Encoding: 7bit
X-SW-Source: 2003-04/txt/msg00455.txt.bz2

On Thursday, April 10, 2003, at 01:01  PM, Eric Botcazou wrote:
>> I think you're completely right: the reload pass has no specific
>> infrastructure for dealing with invalid subregs. It may "fix" these
>> subregs, but only if it happens that the operand needs reloading 
>> because
>> of the insn constraints.
>
> I've found why: the code has been disabled in find_reloads()
>
> 		  /* This following hunk of code should no longer be
> 		     needed at all with SUBREG_BYTE.  If you need this
> 		     code back, please explain to me why so I can
> 		     fix the real problem.  -DaveM */
>
> Re-enabling it fix PR target/10286.
>
> Now the question: what is the replacement machinery that is supposed 
> to be
> doing the work?

Ask DaveM?  He does seem to have volunteered.