From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-105265-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 10175 invoked by alias); 13 Nov 2004 19:24:52 -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 10151 invoked from network); 13 Nov 2004 19:24:48 -0000
Received: from unknown (HELO mail.libertysurf.net) (213.36.80.91)
  by sourceware.org with SMTP; 13 Nov 2004 19:24:48 -0000
Received: from dyn-83-156-221-232.ppp.tiscali.fr (83.156.221.232) by mail.libertysurf.net (6.5.036)
        id 4195901000200155; Sat, 13 Nov 2004 20:24:48 +0100
From: Eric Botcazou <ebotcazou@libertysurf.fr>
To: Ulrich Weigand <uweigand@de.ibm.com>
Subject: Re: Non-representable subregs of subword pseudoregs
Date: Sat, 13 Nov 2004 20:24:00 -0000
User-Agent: KMail/1.6.1
Cc: gcc@gcc.gnu.org,
 jh@suse.cz,
 Jeffrey A Law <law@redhat.com>
References: <200411131839.iADId4ht001145@53v30g15.boeblingen.de.ibm.com>
In-Reply-To: <200411131839.iADId4ht001145@53v30g15.boeblingen.de.ibm.com>
MIME-Version: 1.0
Content-Disposition: inline
Message-Id: <200411132022.41562.ebotcazou@libertysurf.fr>
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-SW-Source: 2004-11/txt/msg00458.txt.bz2

> (I assume this has word_mode == DImode?)

Of course.  Sorry for not explicitly mentioning it.

> While there's unfortunately some amount of confusion as to which
> subregs are valid, exactly, I think it should be pretty clear
> that *this* subreg is certainly *not* valid.
>
> As per the documentation, subregs can be used to denote either
> - a value re-interpreted in another mode (this always means lowpart)
> or
> - one of the words of a multi-word value (i.e. > word_mode)
> or
> - a combination of the two (a lowpart of one word of a multi-word)
>
> Since (reg:DI 126) is a single-word value, and the subreg does
> not denote the lowpart, it should be invalid.

I think this makes sense.  But take a look at gen_realpart:

  if (WORDS_BIG_ENDIAN
      && GET_MODE_BITSIZE (mode) < BITS_PER_WORD
      && REG_P (x)
      && REGNO (x) < FIRST_PSEUDO_REGISTER)
    internal_error
      ("can't access real part of complex value in hard register");
  else if (WORDS_BIG_ENDIAN)
    return gen_highpart (mode, x);
  else
    return gen_lowpart (mode, x);

You can't help but thinking that whoever wrote the check thought that highpart 
subregs of subword pseudo regs were valid.  It turns out that Jeff added it 
in rev. 1.62 of emit-rtl.c.

Jeff, what's your take on this?

-- 
Eric Botcazou