From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9474 invoked by alias); 7 Apr 2011 08:51:34 -0000 Received: (qmail 9466 invoked by uid 22791); 7 Apr 2011 08:51:33 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-ww0-f51.google.com (HELO mail-ww0-f51.google.com) (74.125.82.51) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 07 Apr 2011 08:51:28 +0000 Received: by wwf26 with SMTP id 26so2738424wwf.8 for ; Thu, 07 Apr 2011 01:51:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.200.73 with SMTP id ev9mr620369wbb.207.1302166286974; Thu, 07 Apr 2011 01:51:26 -0700 (PDT) Received: by 10.227.0.140 with HTTP; Thu, 7 Apr 2011 01:51:26 -0700 (PDT) In-Reply-To: References: Date: Thu, 07 Apr 2011 08:51:00 -0000 Message-ID: Subject: Re: PATCH: PR middle-end/48440: [4.7 Regression] FAIL: gcc.c-torture/compile/labels-3.c From: Richard Guenther To: "H.J. Lu" Cc: Paolo Bonzini , Michael Matz , gcc-patches@gcc.gnu.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-04/txt/msg00537.txt.bz2 On Wed, Apr 6, 2011 at 7:03 PM, H.J. Lu wrote: > On Tue, Apr 5, 2011 at 3:29 AM, Richard Guenther > wrote: >> On Tue, Apr 5, 2011 at 8:44 AM, Paolo Bonzini wrote: >>>>>> Index: cgraphbuild.c >>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>> --- cgraphbuild.c.orig =A02011-04-03 11:28:45.000000000 +0200 >>>>>> +++ cgraphbuild.c =A0 =A0 =A0 2011-04-03 11:31:21.000000000 +0200 >>>>>> @@ -53,6 +53,12 @@ record_reference (tree *tp, int *walk_su >>>>>> =A0 tree decl; >>>>>> =A0 struct record_reference_ctx *ctx =3D (struct record_reference_ct= x *)data; >>>>>> >>>>>> + =A0t =3D canonicalize_constructor_val (t); >>>>>> + =A0if (!t) >>>>>> + =A0 =A0t =3D *tp; >>>>>> + =A0else if (t !=3D *tp) >>>>>> + =A0 =A0*tp =3D t; >>>>>> + >>>>>> =A0 switch (TREE_CODE (t)) >>>>>> =A0 =A0 { >>>>>> =A0 =A0 case VAR_DECL: >>>>> >>>>> This change caused: >>>>> >>>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D48440 >>>>> >>>> >>>> This avoids =A0canonicalizing constructor values for address conversion >>>> if Pmode !=3D ptr_mode. =A0OK for trunk? >>> >>> Certainly the right place to fix it is in canonicalize_constructor_val = itself. >> >> There should never be any Pmode pointer types in the gimple IL. =A0The >> proper place to fix it if any is in useless_type_conversion_p. >> > > We have > > 5600 =A0 =A0 =A0newx =3D simplify_subreg (outermode, op, innermode, byte); > (gdb) f 1 > #1 =A00x0000000000708494 in expand_expr_real_2 (ops=3D0x7fffffffb0c0, tar= get=3D0x0, > =A0 =A0tmode=3DVOIDmode, modifier=3DEXPAND_INITIALIZER) > =A0 =A0at /export/gnu/import/git/gcc-x32/gcc/expr.c:7366 > 7366 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0op0 =3D simplify_gen_subreg (mode, op= 0, inner_mode, > (gdb) call debug_tree (treeop0) > =A0 =A0 =A0type =A0 =A0 =A0 =A0type =A0 =A0 =A0 =A0 =A0 =A0align 8 symtab 0 alias set -1 canonical type 0x7ff= ff0b83e70 > =A0 =A0 =A0 =A0 =A0 =A0pointer_to_this > > =A0 =A0 =A0 =A0sizes-gimplified public unsigned SI > =A0 =A0 =A0 =A0size > =A0 =A0 =A0 =A0unit size > =A0 =A0 =A0 =A0align 32 symtab 0 alias set -1 canonical type 0x7ffff0b83f= 18 > =A0 =A0 =A0 =A0pointer_to_this > > =A0 =A0constant > =A0 =A0arg 0 > =A0 =A0 =A0 =A0side-effects VOID file x.i line 8 col 2 > =A0 =A0 =A0 =A0align 1 context initial > > =A0 =A0 =A0 =A0(code_label/s 22 0 0 4 4 ("l2") [2 uses]) > > =A0 =A0 =A0 =A0chain > =A0 =A0 =A0 =A0 =A0 =A0used unsigned SI file x.i line 4 col 9 size 0x7ffff0b706e0 32> unit size > =A0 =A0 =A0 =A0 =A0 =A0align 32 context > =A0 =A0 =A0 =A0 =A0 =A0(mem/f/c/i:SI (plus:DI (reg/f:DI 20 frame) > =A0 =A0 =A0 =A0(const_int -4 [0xfffffffffffffffc])) [0 p+0 S4 A32])>> > =A0 =A0x.i:3:44> > (gdb) call debug_rtx (op0) > (label_ref/v:DI 22) > (gdb) > > Since ptr_mode !=3D Pmode, the type of op0 !=3D type of treeop0. > Should we use GET_MODE (op0) instead of TYPE_MODE (inner_type) > here? Does this patch make any senses? First I wonder what CONSTANT_P object we arrive with here (it looks like something unfolded, given that we likely came here with a NOP_EXPR). Second, no, it doesn't make sense as CONST_INTs are modeless (which is exactly why we look at tree types here ...) The above gdb session paste is from a totally different place, so I can't match the data to the place you are trying to patch. Richard. > > -- > H.J. > --- > diff --git a/gcc/expr.c b/gcc/expr.c > index d521f64..439f245 100644 > --- a/gcc/expr.c > +++ b/gcc/expr.c > @@ -7360,7 +7360,7 @@ expand_expr_real_2 (sepops ops, rtx target, enum ma= chine_m > ode tmode, > =A0 =A0 =A0 else if (CONSTANT_P (op0)) > =A0 =A0 =A0 =A0{ > =A0 =A0 =A0 =A0 =A0tree inner_type =3D TREE_TYPE (treeop0); > - =A0 =A0 =A0 =A0 enum machine_mode inner_mode =3D TYPE_MODE (inner_type); > + =A0 =A0 =A0 =A0 enum machine_mode inner_mode =3D GET_MODE (op0); > > =A0 =A0 =A0 =A0 =A0if (modifier =3D=3D EXPAND_INITIALIZER) > =A0 =A0 =A0 =A0 =A0 =A0op0 =3D simplify_gen_subreg (mode, op0, inner_mode, >