From patchwork Mon Apr 18 17:52:15 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Steve Ellcey X-Patchwork-Id: 91823 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 10350B7003 for ; Tue, 19 Apr 2011 03:52:33 +1000 (EST) Received: (qmail 10075 invoked by alias); 18 Apr 2011 17:52:32 -0000 Received: (qmail 10064 invoked by uid 22791); 18 Apr 2011 17:52:31 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL, BAYES_00, T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from g6t0184.atlanta.hp.com (HELO g6t0184.atlanta.hp.com) (15.193.32.61) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 18 Apr 2011 17:52:17 +0000 Received: from g5t0030.atlanta.hp.com (g5t0030.atlanta.hp.com [16.228.8.142]) by g6t0184.atlanta.hp.com (Postfix) with ESMTP id CF62CC599; Mon, 18 Apr 2011 17:52:16 +0000 (UTC) Received: from [16.89.92.85] (hpsje.cup.hp.com [16.89.92.85]) by g5t0030.atlanta.hp.com (Postfix) with ESMTP id F1871141FB; Mon, 18 Apr 2011 17:52:15 +0000 (UTC) Subject: Re: PATCH: PR middle-end/48440: [4.7 Regression] FAIL: gcc.c-torture/compile/labels-3.c From: Steve Ellcey Reply-To: sje@cup.hp.com To: Michael Matz Cc: "H.J. Lu" , Richard Guenther , Paolo Bonzini , gcc-patches@gcc.gnu.org In-Reply-To: References: <201104152233.p3FMXKH00818@lucas.cup.hp.com> Date: Mon, 18 Apr 2011 10:52:15 -0700 Message-ID: <1303149135.27175.146.camel@hpsje.cup.hp.com> Mime-Version: 1.0 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org On Sat, 2011-04-16 at 00:49 +0200, Michael Matz wrote: > Callers of expand_expr are expected to deal with the situation that the > returned object doesn't have the desired mode, hence I think it's okay for > expand_expr to return a DImode code_label rtx. Meaning we have to deal > with it. The patch of HJ is a first step but doesn't cater for op0 being > a CONST_INT, which doesn't have a mode, hence at the very least the code > should look like: > > enum machine_mode inner_mode = GET_MODE (op0); > if (inner_mode == VOIDmode) > inner_mode = TYPE_MODE (inner_type); > > I do wonder what other places in expand really would need something > similar. Right now nothing else ICEs but perhaps silently generates code > that only works by accident. Well, I guess we'll see. > > > Ciao, > Michael. I tested your patch and it fixed the problem with labels-3.c. It also ran through the test suite with no regressions on IA64 HP-UX and Linux and on x86 Linux. I do see other places in the compiler where we call GET_MODE and then check for VOIDmode to do something special/different if we got that return value (in cfgexpand.c for example) so maybe this is just one more place where we need this type of check. Steve Ellcey sje@cup.hp.com Can someone approve this patch? 2011-05-18 Michael Matz Steve Ellcey * expr.c (expand_expr_real_2): Use GET_MODE instead of TYPE_MODE. Index: expr.c =================================================================== --- expr.c (revision 172632) +++ expr.c (working copy) @@ -7360,8 +7360,11 @@ else if (CONSTANT_P (op0)) { tree inner_type = TREE_TYPE (treeop0); - enum machine_mode inner_mode = TYPE_MODE (inner_type); + enum machine_mode inner_mode = GET_MODE (op0); + if (inner_mode == VOIDmode) + inner_mode = TYPE_MODE (inner_type); + if (modifier == EXPAND_INITIALIZER) op0 = simplify_gen_subreg (mode, op0, inner_mode, subreg_lowpart_offset (mode,