From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26831 invoked by alias); 9 Jul 2014 11:09:03 -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 26815 invoked by uid 89); 9 Jul 2014 11:09:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.8 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 09 Jul 2014 11:09:01 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s69B8viD021239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 9 Jul 2014 07:08:57 -0400 Received: from tucnak.zalov.cz (ovpn-116-32.ams2.redhat.com [10.36.116.32]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s69B8sDN006414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 9 Jul 2014 07:08:56 -0400 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.14.8/8.14.7) with ESMTP id s69B8rkw025284; Wed, 9 Jul 2014 13:08:53 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.14.8/8.14.8/Submit) id s69B8oaR025283; Wed, 9 Jul 2014 13:08:50 +0200 Date: Wed, 09 Jul 2014 11:09:00 -0000 From: Jakub Jelinek To: Richard Biener Cc: Jason Merrill , "Joseph S. Myers" , "Carlos O'Donell" , Siddhesh Poyarekar , GCC Patches , GNU C Library Subject: Re: [RFC PATCH] -Wmemset-transposed-args (PR middle-end/61294) Message-ID: <20140709110850.GV31640@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <20140708125017.GN31640@tucnak.redhat.com> <20140708203151.GP31640@tucnak.redhat.com> <53BC71CE.6000504@redhat.com> <20140709103255.GS31640@tucnak.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2014-07/txt/msg00622.txt.bz2 On Wed, Jul 09, 2014 at 12:51:32PM +0200, Richard Biener wrote: > At least it shouldn't (they are not required to be shared and usually are not > if they've gone a transition from TREE_OVERFLOW to !TREE_OVERFLOW). > > Well, still feels ugly to me - but it's Jasons call in the end. Another possibility is to keep that info on the side, something e.g. the C FE already does. There, c_parser_expr_list fills for the first 3 arguments (if requested by the caller) info about whether the argument used to be originally a sizeof, and then the caller can look at this info. For the literal zeros, it can be stored as a bitmask in a single char. All of these warnings (-Wsizeof-pointer-memaccess, -Wsizeof-array-argument and -Wmemset-transposed-args) are implemented in a hackish way, because we fold everything too early. Perhaps for such analysis we want a FOLDED_EXPR which would have arguments what it has been folded to and the original tree, for the purposes of code generation the first argument would be used and the second one only for the analysis. We don't have that many spots where we need the original trees to be analyzed yet for it to be worth it though IMHO. Jakub