From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 65620 invoked by alias); 19 Feb 2016 20:04:45 -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 65598 invoked by uid 89); 19 Feb 2016 20:04:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: DUB004-OMC3S34.hotmail.com Received: from dub004-omc3s34.hotmail.com (HELO DUB004-OMC3S34.hotmail.com) (157.55.2.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA256 encrypted) ESMTPS; Fri, 19 Feb 2016 20:04:43 +0000 Received: from emea01-am1-obe.outbound.protection.outlook.com ([157.55.2.8]) by DUB004-OMC3S34.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Fri, 19 Feb 2016 12:04:40 -0800 Received: from HE1PR07MB0905.eurprd07.prod.outlook.com (10.162.26.12) by HE1PR07MB0908.eurprd07.prod.outlook.com (10.162.26.15) with Microsoft SMTP Server (TLS) id 15.1.409.15; Fri, 19 Feb 2016 20:04:39 +0000 Received: from HE1PR07MB0905.eurprd07.prod.outlook.com ([10.162.26.12]) by HE1PR07MB0905.eurprd07.prod.outlook.com ([10.162.26.12]) with mapi id 15.01.0409.017; Fri, 19 Feb 2016 20:04:39 +0000 From: Bernd Edlinger To: Jakub Jelinek CC: "gcc-patches@gcc.gnu.org" , Bernd Schmidt , Eric Botcazou , "jason@redhat.com" Subject: Re: [PATCH] Fix expansion of TREE_ADDRESSABLE bitwise copies (PR c++/69851) Date: Fri, 19 Feb 2016 20:04:00 -0000 Message-ID: References: <20160219190447.GX3017@tucnak.redhat.com> In-Reply-To: <20160219190447.GX3017@tucnak.redhat.com> authentication-results: redhat.com; dkim=none (message not signed) header.d=none;redhat.com; dmarc=none action=none header.from=hotmail.de; x-ms-exchange-messagesentrepresentingtype: 1 x-microsoft-exchange-diagnostics: 1;HE1PR07MB0908;23:zMifYjXqNWyPiNju51jQiqzVgXQ6+IUqXu4oFJVQh2BAJVvGJAtf2Udd0JAGnI/ppWHU6u8+yXzG4GOQISUzJVLWreT+8VMys6xy4a79qY3el//qM/AKYx6RNNyolJt6RRwUbAOcjKvnawvqqaRFXS6rPd9df7pGopvGmVL+KN+7vr+Q9U9cN+0po2DJSpOkB8upxWTeWMstjwpg6NKA8Q==;5:pWPVoFypoMB6E5tlrjFM5aygsy2DESHs4SQmJ3alTW6Semrd/Gr5JuLivZajhaeqXP3XE6lvofOdqhzI3dJCF0diG7Of1Vp9mJBqN6i1o7sEY1eEl7gsT4GdpjRxjcwA/f6ozdlURvMqKKZaGVJGbg==;24:FEVSDdHAdcnaigiRSpPKs1GqJVQ93miAVnDSRcE7+oTTvVL1wJen5nuhjelvXXeXgvSGidUbfHvVrZt967fJ2niI8dF/SGSbB45Gfxgisv8= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR07MB0908; x-ms-office365-filtering-correlation-id: e555ac36-ab59-4b34-3542-08d33967e3ed x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(432015012)(82015046);SRVR:HE1PR07MB0908;BCL:0;PCL:0;RULEID:;SRVR:HE1PR07MB0908; x-forefront-prvs: 08572BD77F x-forefront-antispam-report: SFV:NSPM;SFS:(7070004)(98900003);DIR:OUT;SFP:1901;SCL:1;SRVR:HE1PR07MB0908;H:HE1PR07MB0905.eurprd07.prod.outlook.com;FPR:;SPF:None;MLV:ovrnspm;LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-ID: <8D48F97DC24D664783AB3685194BE973@eurprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sct-15-1-409-10-msonline-outlook-d6129.templateTenant X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2016 20:04:39.3073 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB0908 X-SW-Source: 2016-02/txt/msg01380.txt.bz2 On 19.02.2016 20:04, Jakub Jelinek wrote: > On Fri, Feb 19, 2016 at 06:42:32PM +0000, Bernd Edlinger wrote: >> Hi, >> >> >>> --- gcc/expr.c.jj 2016-02-12 00:50:55.000000000 +0100 >>> +++ gcc/expr.c 2016-02-19 10:43:59.639162531 +0100 >>> @@ -6643,14 +6643,24 @@ store_field (rtx target, HOST_WIDE_INT b >>> /* Except for initialization of full bytes from a CONSTRUCTOR, whi= ch >>> we will handle specially below. */ >>> && !(TREE_CODE (exp) =3D=3D CONSTRUCTOR >>> - && bitsize % BITS_PER_UNIT =3D=3D 0)) >>> + && bitsize % BITS_PER_UNIT =3D=3D 0) >>> + /* And except for bitwise copying of TREE_ADDRESSABLE types, >>> + where the FIELD_DECL has the right bitsize, but TREE_TYPE (exp) >>> + includes some extra padding. */ >>> + && (!TREE_ADDRESSABLE (TREE_TYPE (exp)) >>> + || TREE_CODE (exp) !=3D COMPONENT_REF >>> + || TREE_CODE (DECL_SIZE (TREE_OPERAND (exp, 1))) !=3D INTEGER_C= ST >>> + || (bitsize % BITS_PER_UNIT !=3D 0) >>> + || (bitpos % BITS_PER_UNIT !=3D 0) >>> + || (compare_tree_int (DECL_SIZE (TREE_OPERAND (exp, 1)), bitsiz= e) >>> + !=3D 0))) >>> /* If we are expanding a MEM_REF of a non-BLKmode non-addressab= le >>> decl we must use bitfield operations. */ >> >> isn't the indentation of the new block wrong? > > No, I think it is correct. > > Jakub > but you are just adding another term to this expression: !(TREE_CODE (exp) =3D=3D CONSTRUCTOR && bitsize % BITS_PER_UNIT =3D=3D 0) so the result should look like !(TREE_CODE (exp) =3D=3D CONSTRUCTOR && bitsize % BITS_PER_UNIT =3D=3D 0 && (!TREE_ADDRESSABLE ... || TREE_CODE () ... ... || (compare_tree_int ... !=3D 0))) Bernd.