From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 124910 invoked by alias); 4 Sep 2015 20:04:58 -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 124893 invoked by uid 89); 4 Sep 2015 20:04:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no 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; Fri, 04 Sep 2015 20:04:56 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 9A309C0B2B4A; Fri, 4 Sep 2015 20:04:55 +0000 (UTC) Received: from localhost.localdomain (ovpn-113-93.phx2.redhat.com [10.3.113.93]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t84K4sjZ012961; Fri, 4 Sep 2015 16:04:54 -0400 Subject: Re: Fix reload1.c warning for some targets To: Rainer Orth , gcc-patches@gcc.gnu.org, richard.sandiford@arm.com References: <87d1z1kedx.fsf@e105548-lin.cambridge.arm.com> <55CB7F88.5040104@redhat.com> <87bnebc4or.fsf@googlemail.com> <87lhcn6gn4.fsf@e105548-lin.cambridge.arm.com> From: Jeff Law Message-ID: <55E9F965.8030401@redhat.com> Date: Fri, 04 Sep 2015 20:16:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <87lhcn6gn4.fsf@e105548-lin.cambridge.arm.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-09/txt/msg00372.txt.bz2 On 09/03/2015 02:39 AM, Richard Sandiford wrote: > > It sounds like Jeff has a much more radical rewrite in mind, Certainly not anything on the immediate horizon. The amount of block copying that'd be needed to isolate the jump threading path would be significant. I do wonder if we should be looking at a way to mark paths which have jump threading opportunities, but which we do not optimize and exploit that information in the uninit and other analysis. Bodik had a paper on those concepts as well. He was mostly looking at how to account for those paths in code coverage analysis, but there may be something useful in there. > so for now how about just turning -Wmaybe-uninitialized into > a warning for this function? The patch will mean that it becomes > a warning even if someone turns off warnings on the command line, > but I don't think that's important. > > Bootstrapped and regression-tested on x86_64-linux-gnu. Also tested > with a cross-compiler to sparc-linux-gnu (which also triggered the > warning for me). Tested that clang could still compile the file. > OK to install? > > > gcc/ > * reload1.c (elimination_costs_in_insn): Locally turn > -Wmaybe-uninitialized into a warning. I can live with this. Though I'd appreciate it if someone could reduce the sparcv9 testcase and create a bug to track it too. jeff