From patchwork Thu Apr 19 17:46:17 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Thomas Schwinge X-Patchwork-Id: 153845 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 AADBDB6FE6 for ; Fri, 20 Apr 2012 03:46:54 +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=1335462415; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: From:To:Cc:Subject:In-Reply-To:References:User-Agent:Date: Message-ID:MIME-Version:Content-Type:Mailing-List:Precedence: List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=eGj5VtFM/0kDT9dOw9xxl3cHQPo=; b=PNNgNgy/VxnSO1d dxqwA+PXeKYDRnzbJEMxMIyt0QuqOD8SXOY6oLYdxrnkX2tkoZElekNebmzuvvA7 I5ZMBGLrQmdCjuxNJToPE/J5I81gq7f2sgL1Ye+0F4py9+nbV46aDLuwIZqx19dW Y2u/MH4nnm8aJu4ryVfL5jkiGbSU= 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:Received:From:To:Cc:Subject:In-Reply-To:References:User-Agent:Date:Message-ID:MIME-Version:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=frmVllTTnQAMd66DHpzWC28eEL4KnqnO3I+X53Pj39JLBtqUBCPl1PLV9XkdGa wk+K8aWmOuw2UbT5TEnGGLwxs8spLukBaqRPJhL4e3/Kl7C9dTFE40p8a+i1JZsX LtJ7Uct2m9tncNE14YvkyqaJ9elEGdT7ngMbWIgwgKPyQ=; Received: (qmail 22540 invoked by alias); 19 Apr 2012 17:46:46 -0000 Received: (qmail 22527 invoked by uid 22791); 19 Apr 2012 17:46:44 -0000 X-SWARE-Spam-Status: No, hits=-7.2 required=5.0 tests=AWL, BAYES_00, KHOP_PGP_SIGNED, KHOP_RCVD_UNTRUST, KHOP_THREADED, RCVD_IN_HOSTKARMA_W, RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 19 Apr 2012 17:46:30 +0000 Received: from nat-dem.mentorg.com ([195.212.93.2] helo=eu2-mail.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1SKvR6-0000qz-Ki from Thomas_Schwinge@mentor.com ; Thu, 19 Apr 2012 10:46:28 -0700 Received: from feldtkeller.schwinge.homeip.net ([172.30.64.237]) by eu2-mail.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 Apr 2012 19:46:27 +0200 From: Thomas Schwinge To: Bernd Schmidt , Richard Earnshaw Cc: Richard Guenther , Joey Ye , "dj\@redhat.com" , GCC Patches , "Mitchell\, Mark" Subject: Re: Continue strict-volatile-bitfields fixes In-Reply-To: <4F8EE8E0.6020907@codesourcery.com> References: <4EBD4BCB.4080807@codesourcery.com> <4ED50901.8090300@codesourcery.com> <4F1D72CA.1060908@codesourcery.com> <874nupb2v4.fsf@schwinge.name> <4F4282AF.7000804@codesourcery.com> <4F428565.1050508@arm.com> <4F42881B.80800@codesourcery.com> <4F436677.9090203@arm.com> <87obqpnj9i.fsf@schwinge.name> <4F8EE84C.20501@arm.com> <4F8EE8E0.6020907@codesourcery.com> User-Agent: Notmuch/0.9-101-g81dad07 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu) Date: Thu, 19 Apr 2012 19:46:17 +0200 Message-ID: <871unjobrq.fsf@schwinge.name> 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 Hi! On Wed, 18 Apr 2012 18:16:32 +0200, Bernd Schmidt wrote: > On 04/18/2012 06:14 PM, Richard Earnshaw wrote: > > On 18/04/12 16:37, Thomas Schwinge wrote: > >> gcc/testsuite/ > >> * gcc.dg/tree-ssa/20030922-1.c: Compile with > >> -fno-strict-volatile-bitfields. > >> * gcc.dg/tree-ssa/foldconst-3.c: Likewise. > >> * gcc.dg/tree-ssa/vrp15.c: Likewise. > >> > > > > None of these have any volatile bitfields, so the option should be a no-op. That's what I thought, too. :-) > The problem is that we have to treat normal bitfields differently as > well, since a variable may later be declared as volatile. Here is my current test case, reduced from gcc.dg/tree-ssa/20030922-1.c: extern void abort (void); enum tree_code { BIND_EXPR, }; struct tree_common { enum tree_code code:8; }; void voidify_wrapper_expr (struct tree_common *common) { switch (common->code) { case BIND_EXPR: if (common->code != BIND_EXPR) abort (); } } The diff for -fdump-tree-all between compiling with -fno-strict-volatile-bitfields and -fstrict-volatile-bitfields begins with the following, right in 20030922-1.c.003t.original: That is, for -fno-strict-volatile-bitfields the second instance of »common->code« it is a component_ref, whereas for -fstrict-volatile-bitfields it is a bit_field_ref. The former will be optimized as intended, the latter will not. So, what should be emitted in the -fstrict-volatile-bitfields case? A component_ref -- but this is what Bernd's commit r182545 (for PR51200) changed, I think? Or should later optimization stages learn to better deal with a bit_field_ref, and where would this have to happen? Grüße, Thomas diff -ru fnsvb/20030922-1.c.003t.original fsvb/20030922-1.c.003t.original --- fnsvb/20030922-1.c.003t.original 2012-04-19 16:51:18.322150866 +0200 +++ fsvb/20030922-1.c.003t.original 2012-04-19 16:49:18.132088498 +0200 @@ -7,7 +7,7 @@ switch ((int) common->code) { case 0:; - if (common->code != 0) + if ((BIT_FIELD_REF <*common, 32, 0> & 255) != 0) { abort (); }