From patchwork Wed Oct 31 14:29:58 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Carlini X-Patchwork-Id: 195885 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 BF28D2C01FA for ; Thu, 1 Nov 2012 01:30:16 +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=1352298617; 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:Mailing-List: Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:Sender:Delivered-To; bh=5PPhOe6pr8/+Aco464H5h74wpv8=; b=ElTTYTjG1fOJjQav71dbLktikV4akCC1msJLlggd9KTo9EO5c5Bd2gIZQGjNMO vPVy6yt+aRNvpFkMSsMVv+i21nV3yr4Mn9IEA8Bs1mZj6AIGKVbkiwM+5u3LC8eX jW3DIdd8m2ZZPQFZiqkZdLYw5DB9YKHw3x32XLBZ+4xNA= 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:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=WYHE96OAZfdV9iZw5UvsZ1B5Sw7Z38aKAlSjipO+d6t/0larlNM0x7kJc9kdAP hdG55ziMosOmLayeNPLacCykW4h/Ch2bUmvZE6kD1XWsPTLIQEyyWvotlyDlrulX nNZMQQutCzRmznfm2AwjH/yrej7MupLEjw9sFYuuscwy8=; Received: (qmail 21989 invoked by alias); 31 Oct 2012 14:30:09 -0000 Received: (qmail 21978 invoked by uid 22791); 31 Oct 2012 14:30:08 -0000 X-SWARE-Spam-Status: No, hits=-5.9 required=5.0 tests=AWL, BAYES_00, FSL_NEW_HELO_USER, KHOP_THREADED, RCVD_IN_HOSTKARMA_NO, RCVD_IN_HOSTKARMA_YE, RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 31 Oct 2012 14:30:03 +0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q9VEU1PB029446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 31 Oct 2012 14:30:02 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q9VEU1ZY022223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Oct 2012 14:30:01 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q9VEU1LW009074; Wed, 31 Oct 2012 09:30:01 -0500 Received: from [192.168.1.4] (/79.40.56.124) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 31 Oct 2012 07:30:00 -0700 Message-ID: <509135E6.3090004@oracle.com> Date: Wed, 31 Oct 2012 15:29:58 +0100 From: Paolo Carlini User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121025 Thunderbird/16.0.2 MIME-Version: 1.0 To: Jason Merrill CC: "gcc-patches@gcc.gnu.org" Subject: Re: [C++ Patch] PR 54583 References: <50906671.5050706@oracle.com> <50912C9C.9040500@redhat.com> In-Reply-To: <50912C9C.9040500@redhat.com> 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 Hi, On 10/31/2012 02:50 PM, Jason Merrill wrote: > On 10/30/2012 07:44 PM, Paolo Carlini wrote: >> straightforward fix. The below, which regtests fine, simply acts on any >> MULT_EXPR as TYPE_SIZE, which I think should be fine, but, in case the >> idea is basically Ok, we could also consider the more complex but more >> sophisticated variably_modified_type_p? > I think I'd use EXPR_P rather than check for a particular tree code. Yes, I also wondered whether that would be better. The below also passes testing. Thanks, Paolo. ///////////////// Index: testsuite/g++.dg/ext/vla13.C =================================================================== --- testsuite/g++.dg/ext/vla13.C (revision 0) +++ testsuite/g++.dg/ext/vla13.C (working copy) @@ -0,0 +1,8 @@ +// PR c++/54583 +// { dg-options "-Wunused-value" } + +void fred() +{ + int n=10; + double (*x)[n]; +} Index: cp/tree.c =================================================================== --- cp/tree.c (revision 193033) +++ cp/tree.c (working copy) @@ -824,6 +824,10 @@ build_cplus_array_type (tree elt_type, tree index_ } } + /* Avoid spurious warnings with VLAs (c++/54583). */ + if (TYPE_SIZE (t) && EXPR_P (TYPE_SIZE (t))) + TREE_NO_WARNING (TYPE_SIZE (t)) = 1; + /* Push these needs up so that initialization takes place more easily. */ TYPE_NEEDS_CONSTRUCTING (t)