From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-373505-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 18112 invoked by alias); 9 Nov 2011 18:52:49 -0000
Received: (qmail 18101 invoked by uid 22791); 9 Nov 2011 18:52:48 -0000
X-SWARE-Spam-Status: No, hits=-2.9 required=5.0	tests=ALL_TRUSTED,AWL,BAYES_00
X-Spam-Check-By: sourceware.org
Received: from localhost (HELO gcc.gnu.org) (127.0.0.1)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 09 Nov 2011 18:52:35 +0000
From: "uweigand at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/50762] ICE: in extract_insn, at recog.c:2137 (unrecognizable insn)
Date: Wed, 09 Nov 2011 19:10:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Keywords: ice-on-valid-code, ra
X-Bugzilla-Severity: normal
X-Bugzilla-Who: uweigand at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.7.0
X-Bugzilla-Changed-Fields:
Message-ID: <bug-50762-4-xv6OWwhxMl@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-50762-4@http.gcc.gnu.org/bugzilla/>
References: <bug-50762-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
X-SW-Source: 2011-11/txt/msg01001.txt.bz2

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50762

--- Comment #8 from Ulrich Weigand <uweigand at gcc dot gnu.org> 2011-11-09 18:52:16 UTC ---
(In reply to comment #7)
> Redefining "j" constraint as "define_address_constraint" results in:

Yes, it needs to be define_address_constraint.

> pr50762.c:48:1: error: unrecognizable insn:
> (insn 29 28 30 3 (set (reg:DI 0 ax [77])
>         (zero_extend:DI (const_int 1 [0x1]))) pr50762.c:35 -1
>      (expr_list:REG_DEAD (reg/v:SI 59 [ p_60 ])
>         (nil)))
> pr50762.c:48:1: internal compiler error: in extract_insn, at recog.c:2137
> Please submit a full bug report,

That's odd.

> So, _why_ reload insists on pushing zero_extended constant to the register? I'd
> expect that (const_int 1) is pushed into the register.
> 
> And finally, (zero_extend:DI (const_int 1 [0x1])) equals to (const_int 1
> [0x1]), so why this RTX isn't simplified on-the-fly?

The zero_extend is a fixed part of the insn pattern in question:

(define_insn "*lea_4_zext"
  [(set (match_operand:DI 0 "register_operand" "=r")
        (zero_extend:DI
          (match_operand:SI 1 "lea_address_operand" "p")))]

Reload only ever changes what is *inside* the operands.  It does not change the
fixed parts of the pattern (outside of operands).

What I would have expected to happen is for reload to load the (const_int 1)
into an SImode register, and then zero-extend that one ...

Not sure why that doesn't happen.  I'll have a look.