From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-42280-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 18710 invoked by alias); 5 Dec 2001 17:16:48 -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 18589 invoked from network); 5 Dec 2001 17:16:39 -0000
Received: from unknown (HELO atrey.karlin.mff.cuni.cz) (195.113.31.123)
  by sources.redhat.com with SMTP; 5 Dec 2001 17:16:39 -0000
Received: (from hubicka@localhost)
	by atrey.karlin.mff.cuni.cz (8.9.3/8.9.3/Debian 8.9.3-21) id SAA01147;
	Wed, 5 Dec 2001 18:16:37 +0100
Date: Wed, 05 Dec 2001 09:16:00 -0000
From: Jan Hubicka <jh@suse.cz>
To: dimmy <diwil@mail.ru>
Cc: Jan Hubicka <jh@suse.cz>, gcc@gcc.gnu.org
Subject: Re: Legitimize address, Please HELP!
Message-ID: <20011205181637.N12305@atrey.karlin.mff.cuni.cz>
References: <3C0E1421.1080906@mail.ru> <20011205163059.M30680@atrey.karlin.mff.cuni.cz> <3C0E5775.1040904@mail.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3C0E5775.1040904@mail.ru>
User-Agent: Mutt/1.3.20i
X-SW-Source: 2001-12/txt/msg00216.txt.bz2

> Jan,
> return is not missing.
> Even some improvements to legitimate_address_p
> such as:
> -------------------
> int
> legitimate_address_p (mode, operand, strict)
> enum machine_mode mode;
> rtx operand;
> int strict;
> {
>    rtx xfoob, x = operand;
> 
> 
>  if (GET_CODE (operand) == PLUS
>        && ((GET_CODE (XEXP (operand, 0)) == MEM )
>            ||GET_CODE (XEXP (operand, 1)) == MEM )
>       )
>    {  
>        fprintf(stderr,"interesting address mode\n");     
>        goto fail;
>    }
> 
>    xfoob = XEXP (operand, 0);
>   
>    if (GET_CODE (operand) == MEM  
>        &&  GET_CODE (xfoob) == PLUS
>        &&  GET_CODE (XEXP (xfoob, 0)) == MEM)
>    {
>        fprintf(stderr,"Super interesting address mode\n");
>        goto fail;
>    }
>    
> 
>    if (GET_CODE (operand) == PLUS
>                 && GET_CODE (XEXP (operand, 0)) == PLUS)
>    return 0;
>                   
>    /* accept @Rn */
>    if (GET_CODE (operand) == REG
>            &&(strict ? REG_OK_FOR_BASE_STRICT_P (x)
>               : REG_OK_FOR_BASE_NOSTRICT_P (x)))
>        goto granded;
> 
>    /* accept address */
>    if (CONSTANT_ADDRESS_P (operand))
>        goto granded;
> 
>    /* accept X(Rn) */
>    if (GET_CODE (operand) == PLUS
>            && GET_CODE (XEXP (operand, 0)) == REG 
>            && REG_OK_FOR_BASE_P (XEXP (operand, 0))
>            && CONSTANT_ADDRESS_P (XEXP (operand, 1))
>        )
>        goto granded;
> 
> fail:
>    return 0;
> granded:
>    fprintf(stderr,"legitimate_address_p --- Ok\n");
>    return 1;
> }
> 
> do not help.
> 
> I thought that it might be cause I defined
> frame_pointer_regnum  equial to stack pointer.
> Now I assigned frame_pointer_regnum to another register and still got
> the same error.
> 
> This happens only when frame pointer required.
> 
> here is the part of RTL dump:
> 
> (jump_insn/i 451 450 452 (set (pc)
>        (if_then_else (ne (cc0)
>                (const_int 0 [0x0]))
>            (label_ref 380)
>            (pc))) 127 {bne} (nil)
>    (expr_list:REG_BR_PROB (const_int 6001 [0x1771])
>        (nil)))  
> *****************/
>        jne      .L402  ;        .L402
> /*****************
> (insn/i 457 946 458 (set (mem/s:HI (plus:HI (reg/v:HI 6 r6 [136])
>                (const_int 2 [0x2])) 0)
>        (plus:HI (mem/s:HI (plus:HI (reg/v:HI 6 r6 [136])
>                    (const_int 2 [0x2])) 0)
>            (mem/s:HI (plus:HI (mem:HI (plus:HI (reg/f:HI 4 r4)
>                            (const_int 22 [0x16])) 0)
>                    (const_int 2 [0x2])) 0))) 37 {*addhi3_3} (nil)
>    (expr_list:REG_DEAD (reg/v:HI 6 r6 [136])
>        (nil)))  
> *****************/
>        add     2(22(r4)), 2(r6)            ;       ----- INVALID!!
> ;; will be output as:      add     2(r675750800), 2(r6)

Do you know how the instruction got created?  What appears to be wrong
is not legitimate_address_p (in case it really refuse the address in question),
but the origin of insn.
Most of addresses are legitimized - gcc replaces the subexpressions by 
registers until the resulting address is valid, but this apparently not.
This may be due to bug in compiler, but more probably due to wrong
expander or something who accepts the operand, expect it to be register
but it really is memory (the inner one).