From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26054 invoked by alias); 11 Apr 2003 16:51:15 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 26036 invoked from network); 11 Apr 2003 16:51:15 -0000 Received: from unknown (HELO nikam.ms.mff.cuni.cz) (195.113.18.106) by sources.redhat.com with SMTP; 11 Apr 2003 16:51:15 -0000 Received: from camelot.ms.mff.cuni.cz (kampanus.ms.mff.cuni.cz [195.113.18.107]) by nikam.ms.mff.cuni.cz (Postfix) with SMTP id 26E094DE86; Fri, 11 Apr 2003 18:51:16 +0200 (CEST) Received: by camelot.ms.mff.cuni.cz (sSMTP sendmail emulation); Fri, 11 Apr 2003 18:51:17 +0200 Date: Fri, 11 Apr 2003 18:09:00 -0000 From: Jan Hubicka To: Eric Botcazou Cc: Jan Hubicka , gcc@gcc.gnu.org Subject: Re: Reload bug Message-ID: <20030411165117.GB15771@kam.mff.cuni.cz> References: <200304081937.16859.ebotcazou@libertysurf.fr> <200304102200.35188.ebotcazou@libertysurf.fr> <20030410202612.GI9319@kam.mff.cuni.cz> <200304111356.23415.ebotcazou@libertysurf.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200304111356.23415.ebotcazou@libertysurf.fr> User-Agent: Mutt/1.3.28i X-SW-Source: 2003-04/txt/msg00553.txt.bz2 > > The code is wrong for post-SUBREG_BYTE patch as it checks that the > > partial regs have exactly size of one word, but we do allow subregs on > > registers of different sizes. We need to verify that offset can > > represent the register exactly. > > Is it really wrong or is it incomplete now, in the post-SUBREG_BYTE era? > > > Looking as subreg_regno_offset, I think we need to practically check > > that division in: > > return (y_offset / (mode_multiple / nregs_multiple)) * nregs_ymode; > > Does not round. When it rounds we are having registers too wide and we > > must reload. > > All the other divisions should be safe from SUBREG definition that is > > already verified by my simplify_subreg code. > > We also should add a trap to subreg_regno_offset in the mainline... > > Seems to make sense? > > Do you mean that we can generate > > (subreg:HI (reg/v:SI 67) 2) > > and we currently have no means to fix it during the reload pass? Forgot to mention, I have patch in testing, will send it as soon as I will be able to access the net (it is down for some reason now) Honza > > -- > Eric Botcazou