From patchwork Thu Feb 16 08:57:30 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christian Bruel X-Patchwork-Id: 141523 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 9D061B6F98 for ; Thu, 16 Feb 2012 19:58:09 +1100 (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=1329987489; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:Received:Message-ID:Date:From:User-Agent:MIME-Version: To:Cc:Subject:References:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mailing-List:Precedence:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=r+BZP+Wq28GBGNLrdelXH4WIuWY=; b=pR7+jjc2dQCrFtL RMFW3+raWmQkzJI2uUyeSB36ZOONsdpmPMB3fRRsZJDOEBWxrNVGuJ7CwcKRMpYf PSZDxstS2AuFYj3Msoefq7W9U1kZQb6unA6RMRzfy84gV9fNkbWtHcRoxKGA2gnW EMDHGjpLd541u7qih2urWP+Aa58o= 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:Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Cc:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=ldbHl3AMjw1eY9h88sDrq7Yz/z0JXeVSpYJPPCXq5EYXSDKQGjU6KGF0cBg3yG XkVzSzpzTdcIjyy7oZ5AmJKvIGIN3RyhVHoVDEl2SHuUiTG/6ci+jl8vsqYBvUEb 3hzgUuyLjylKQ1HA4b4hvd9UQps05oSUV8RNm0QXUp8pc=; Received: (qmail 24474 invoked by alias); 16 Feb 2012 08:58:01 -0000 Received: (qmail 24299 invoked by uid 22791); 16 Feb 2012 08:57:58 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from eu1sys200aog112.obsmtp.com (HELO eu1sys200aog112.obsmtp.com) (207.126.144.133) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 16 Feb 2012 08:57:45 +0000 Received: from beta.dmz-eu.st.com ([164.129.1.35]) (using TLSv1) by eu1sys200aob112.postini.com ([207.126.147.11]) with SMTP ID DSNKTzzFA8dN5wrLeI37gnki69q8ZrGfhBck@postini.com; Thu, 16 Feb 2012 08:57:44 UTC Received: from zeta.dmz-eu.st.com (zeta.dmz-eu.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 5CF8E1FD; Thu, 16 Feb 2012 08:57:38 +0000 (GMT) Received: from Webmail-eu.st.com (safex1hubcas5.st.com [10.75.90.71]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 118F9209B; Thu, 16 Feb 2012 08:57:37 +0000 (GMT) Received: from [164.129.122.89] (164.129.122.89) by webmail-eu.st.com (10.75.90.13) with Microsoft SMTP Server (TLS) id 8.3.192.1; Thu, 16 Feb 2012 09:57:30 +0100 Message-ID: <4F3CC4FA.2070209@st.com> Date: Thu, 16 Feb 2012 09:57:30 +0100 From: Christian Bruel User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Joseph S. Myers" Cc: "gcc-patches@gcc.gnu.org" Subject: Re: [PATCH, 4.6 regression]. New error: case label does not reduce References: <4F3B75DE.9030406@st.com> In-Reply-To: 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 02/15/2012 06:03 PM, Joseph S. Myers wrote: > On Wed, 15 Feb 2012, Christian Bruel wrote: > >> Removal of this NOP_EXPR if !CAN_HAVE_LOCATION_P fixes the problem. >> looks safe from my testing, because the loc is inserted using >> 'protected_set_expr_location', whereas no loc for a constant case >> doesn't seem to introduce new problems with the debugging information. >> But in case I also added a few paranoid gcc_assert. > > Is it safe to set TREE_NO_WARNING without that check? I'd have thought > the check was to avoid setting TREE_NO_WARNING on a shared node when > warnings are to be disabled in only one context where that node is used. > OK, I see, we can still keep the check, like with : We propagate the flag to the new node for non-constant folded expressions, or for a converted constant (so NOT_EXPR is not stripped), Does it make sense to set TREE_NO_WARNING for a not-converted folded constant ? it seems that in the proposal, a warning before the fold is OK, and a warning after the fold on the new expression is still to be honored. The NO_WARNING flag on an non-converted constant that is folded looks unnecessary. I tried to forge different scenarios, were the result of the folded constant would force a duplicate warning, but no success to find a regression case. Thanks Christian Index: c-common.c =================================================================== --- c-common.c (revision 184301) +++ c-common.c (working copy) @@ -1435,12 +1435,9 @@ have been done by this point, so remove them again. */ nowarning |= TREE_NO_WARNING (ret); STRIP_TYPE_NOPS (ret); - if (nowarning && !TREE_NO_WARNING (ret)) - { - if (!CAN_HAVE_LOCATION_P (ret)) - ret = build1 (NOP_EXPR, TREE_TYPE (ret), ret); - TREE_NO_WARNING (ret) = 1; - } + if (nowarning && CAN_HAVE_LOCATION_P (ret)) + TREE_NO_WARNING (ret) = 1; + if (ret != expr) protected_set_expr_location (ret, loc); return ret;