From patchwork Tue May 22 14:12:03 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Richard Biener X-Patchwork-Id: 160646 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 CDFC3B6F9D for ; Wed, 23 May 2012 00:12:36 +1000 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1338300758; h=Comment: DomainKey-Signature:Received:Received:Received:Received: MIME-Version:Received:Received:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type: Content-Transfer-Encoding:Mailing-List:Precedence:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=HcKBTXYfGQFJBJc+Yc2q2CE8FrU=; b=OTUf5e66bKH8SI3 QUgik11Me3eH2/3DsRHIIvI+G0xy7d9bns614Rf8eTPHopLmWkrzHnNCiUszOoKK yC2cCRq5pU4fG2jW7g2tXqudrB9QJdN67bDKAGx9r+XNAUJ+FO5/C2dCNr+H3HlO f+Hh8rMLrTpXRtvItS2XIxCs9kDw= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:MIME-Version:Received:Received:In-Reply-To:References:Date:Message-ID:Subject:From:To:Cc:Content-Type:Content-Transfer-Encoding:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=pdfupSgRoPbmVPX2LhSsuS29boWTW8zeF6TL7rickgMkXll+7uuacZy3utZc08 j95nig+7hffEO0nUPMMnQ9ojg1G9Jjk6Ylrl0iGYGrsZZi7MtCzR/AMoKU2cihMq jaEYo8oHK8wkrdxftFIKW8iJQQigJXRXx3hbu4PgLz+IM=; Received: (qmail 30615 invoked by alias); 22 May 2012 14:12:25 -0000 Received: (qmail 30593 invoked by uid 22791); 22 May 2012 14:12:22 -0000 X-SWARE-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL, BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, KHOP_RCVD_TRUST, KHOP_THREADED, RCVD_IN_DNSWL_LOW, RCVD_IN_HOSTKARMA_YE, TW_TM X-Spam-Check-By: sourceware.org Received: from mail-yx0-f175.google.com (HELO mail-yx0-f175.google.com) (209.85.213.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 22 May 2012 14:12:06 +0000 Received: by yenl13 with SMTP id l13so5678545yen.20 for ; Tue, 22 May 2012 07:12:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.0.193 with SMTP id 1mr11805291oeg.39.1337695923710; Tue, 22 May 2012 07:12:03 -0700 (PDT) Received: by 10.76.83.230 with HTTP; Tue, 22 May 2012 07:12:03 -0700 (PDT) In-Reply-To: <4FBB93A4.5070509@acm.org> References: <4FB928DA.8090806@acm.org> <4FBB93A4.5070509@acm.org> Date: Tue, 22 May 2012 16:12:03 +0200 Message-ID: Subject: Re: fix cross build From: Richard Guenther To: Nathan Sidwell Cc: GCC Patches X-IsSubscribed: yes 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 Tue, May 22, 2012 at 3:24 PM, Nathan Sidwell wrote: > On 05/21/12 11:03, Richard Guenther wrote: > >> Hmm - I think this papers over the issue that the CONSTRUCTOR is not >> properly gimplified - it still contains a TARGET_EXPR which is not valid >> GIMPLE. >> Why is that TARGET_EXPR not gimplified? > > > As far as I can make out, it just doesn't look inside the constructor. > > 0  gimplify_expr (expr_p=0xb7e90394, pre_p=0xbfffe514, post_p=0xbfffd08c, >    gimple_test_f=0x84b0a80 , fallback=3) at > ../../src/gcc/gimplify.c:7356 > #1  0x084f5882 in gimplify_compound_lval (expr_p=0xb7e9cb94, > pre_p=0xbfffe514, post_p=0xbfffd08c, fallback=1) >    at ../../src/gcc/gimplify.c:2259 > #2  0x08519878 in gimplify_expr (expr_p=0xb7e9cb94, pre_p=0xbfffe514, > post_p=0xbfffd08c, >    gimple_test_f=0x84eaf9f , fallback=1) at > ../../src/gcc/gimplify.c:7081 > #3  0x085087f7 in gimplify_modify_expr (expr_p=0xbfffd6d0, pre_p=0xbfffe514, > post_p=0xbfffd08c, want_value=false) >    at ../../src/gcc/gimplify.c:4843 > > The switch case at that stack frame is for CONSTRUCTORs.  It has the > comment: > /* Don't reduce this in place; let gimplify_init_constructor work its >             magic.  Buf if we're just elaborating this for side effects, > just >             gimplify any element that has side-effects.  */ > > But we never enter G_I_C before the ICE. > > On the second time we get here, fallback has the value 1 at that point > (fb_rvalue), so neither if condition is satisified, and we end up at >            ret = GS_ALL_DONE; > we then proceed down to enter: >  else if ((fallback & fb_rvalue) && is_gimple_reg_rhs_or_call (*expr_p)) >    { >      /* An rvalue will do.  Assign the gimplified expression into a >         new temporary TMP and replace the original expression with >         TMP.  First, make sure that the expression has a type so that >         it can be assigned into a temporary.  */ >      gcc_assert (!VOID_TYPE_P (TREE_TYPE (*expr_p))); >      *expr_p = get_formal_tmp_var (*expr_p, pre_p); >    } > > and ICE inside GFTV when it attempts to generate the hash. > > AFAICT, changing the test case to: >  char *str = ((union {const char * _q; char * _nq;}) >               ((const char *)((num_string) >                               ->string.str)))._nq; > (i.e. removing the stmt-expr) results in the same logical flow as above, but > there's no TARGET_EXPR inside the constructor. > > I'm not sure how it's supposed to work, so I'm a little lost. Hm, ok. I see what happens. The issue is that the CONSTRUCTOR has elements with TREE_SIDE_EFFECTS set but is itself not TREE_SIDE_EFFECTS. Which would have avoided all this mess in lookup_tmp_var. I suppose for duplicating the initializer you could even generate wrong-code with your fix in(?). Now, we never set TREE_SIDE_EFFECTS from build_constructor (but only TREE_CONSTANT), so the fix could either be to fix that or to exclude CONSTRUCTORs in lookup_tmp_var like after all lookup_tmp_var performs a simple-minded CSE here. But I wonder why CONSTRUCTORs do not inherit TREE_SIDE_EFFECTS properly ... Richard. Index: gcc/gimplify.c =================================================================== --- gcc/gimplify.c (revision 187772) +++ gcc/gimplify.c (working copy) @@ -514,7 +514,8 @@ lookup_tmp_var (tree val, bool is_formal block, which means it will go into memory, causing much extra work in reload and final and poorer code generation, outweighing the extra memory allocation here. */ - if (!optimize || !is_formal || TREE_SIDE_EFFECTS (val)) + if (!optimize || !is_formal || TREE_SIDE_EFFECTS (val) + || TREE_CODE (val) == CONSTRUCTOR) ret = create_tmp_from_val (val); else {