From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 41599 invoked by alias); 14 Dec 2019 07:47:09 -0000 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 Received: (qmail 41568 invoked by uid 89); 14 Dec 2019 07:47:05 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-7.8 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,KAM_ASCII_DIVIDERS,KAM_NUMSUBJECT,SPF_PASS autolearn=ham version=3.3.1 spammy=H*f:sk:VTkpww@, H*i:sk:Sn1k44w, H*f:sk:Sn1k44w, H*f:sk:G-U8pHs X-HELO: mx1.suse.de Received: from mx2.suse.de (HELO mx1.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 14 Dec 2019 07:47:04 +0000 Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 01D6FAC92; Sat, 14 Dec 2019 07:47:01 +0000 (UTC) Date: Sat, 14 Dec 2019 07:47:00 -0000 User-Agent: K-9 Mail for Android In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [PATCH] Fix PR70985 To: Andrew Pinski CC: GCC Patches From: Richard Biener Message-ID: X-SW-Source: 2019-12/txt/msg01060.txt.bz2 On December 14, 2019 6:28:48 AM GMT+01:00, Andrew Pinski wrote: >On Mon, May 9, 2016 at 2:32 AM Richard Biener >wrote: >> >> >> I am testing the following followup to my BIT_FIELD_REF >simplification >> changes which resolve issues when applying to memory BIT_FIELD_REFs. >> >> Bootstrap and regtest running on x86_64-unknown-linux-gnu. > >My question is not directly related to this patch but is partly >related. >While I was working on lowering bit-field access patch, I ran into a >problem where I am building the lhs, I use fold_build3 to build the >BIT_FIELD_REF and we get a convert expression from it. >Should we be using a fold_build3 for the BIT_FIELD_REF that will be >used on the lhs or should we just disable this optimization for non >GIMPLE? >The testcases where I ran into the issue are the ones which I added >back in October; gcc.c-torture/compile/20191015-1.c and >gcc.c-torture/compile/20191015-2.c. I added them so when I submit the >patch for lowering for GCC 11, we don't regress (there was no testcase >beforehand). You should never apply fold_* to where you require an lvalue.=20 Richard.=20 >Thanks, >Andrew Pinski > >> >> Richard. >> >> 2016-05-09 Richard Biener >> >> PR tree-optimization/70985 >> * match.pd (BIT_FIELD_REF -> (type)): Disable on GIMPLE when >> op0 isn't a gimple register. >> >> * gcc.dg/torture/pr70985.c: New testcase. >> >> Index: gcc/match.pd >> =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 >> *** gcc/match.pd (revision 236021) >> --- gcc/match.pd (working copy) >> *************** DEFINE_INT_AND_FLOAT_ROUND_FN (RINT) >> *** 3244,3249 **** >> --- 3244,3251 ---- >> (view_convert (imagpart @0))))) >> (if (INTEGRAL_TYPE_P (TREE_TYPE (@0)) >> && INTEGRAL_TYPE_P (type) >> + /* On GIMPLE this should only apply to register arguments.=20 >*/ >> + && (! GIMPLE || is_gimple_reg (@0)) >> /* A bit-field-ref that referenced the full argument can be >stripped. */ >> && ((compare_tree_int (@1, TYPE_PRECISION (TREE_TYPE (@0))) >=3D=3D 0 >> && integer_zerop (@2)) >> Index: gcc/testsuite/gcc.dg/torture/pr70985.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 >> *** gcc/testsuite/gcc.dg/torture/pr70985.c (revision 0) >> --- gcc/testsuite/gcc.dg/torture/pr70985.c (working copy) >> *************** >> *** 0 **** >> --- 1,28 ---- >> + /* { dg-do compile } */ >> + /* { dg-require-effective-target int32plus } */ >> + >> + struct >> + { >> + int f0:24; >> + } a, c, d; >> + >> + int b; >> + >> + int >> + fn1 () >> + { >> + return 0; >> + } >> + >> + void >> + fn2 () >> + { >> + int e; >> + if (b) >> + for (; e;) >> + { >> + d =3D c; >> + if (fn1 (b)) >> + b =3D a.f0; >> + } >> + }