From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6724 invoked by alias); 2 Sep 2014 11:40:52 -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 6690 invoked by uid 89); 2 Sep 2014 11:40:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: gate.crashing.org Received: from gate.crashing.org (HELO gate.crashing.org) (63.228.1.57) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 02 Sep 2014 11:40:47 +0000 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.13.8) with ESMTP id s82Bdt6e012040; Tue, 2 Sep 2014 06:39:55 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id s82BdrSw012027; Tue, 2 Sep 2014 06:39:53 -0500 Date: Tue, 02 Sep 2014 11:40:00 -0000 From: Segher Boessenkool To: "Bin.Cheng" Cc: Jeff Law , Richard Earnshaw , Bin Cheng , "gcc-patches@gcc.gnu.org" , Ulrich Weigand Subject: Re: [PATCH PR62151]Fix uninitialized register issue caused by distribute_notes in combine pass Message-ID: <20140902113948.GA9387@gate.crashing.org> References: <000a01cfc1de$cac1c230$60454690$@arm.com> <53FDB440.5030904@arm.com> <5401680D.60907@redhat.com> <20140831121844.GA8949@gate.crashing.org> <20140901113850.GA15134@gate.crashing.org> <5404A12E.1020501@redhat.com> <20140901175036.GA6643@gate.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2014-09/txt/msg00118.txt.bz2 On Tue, Sep 02, 2014 at 10:02:38AM +0800, Bin.Cheng wrote: > >> >Archaeology suggests this check is because the clobber might be an > >> >earlyclobber. Which seems silly: how can it be a valid insn at all > >> >in that case? It seems to me the check can just be removed. That > >> >will hide your issue, maybe even solve it (but I doubt it). > >> Silly for other reasons, namely that earlyclobber doesn't come into play > >> until after combine (register allocation and later). > > > > The last change to this code was by Ulrich (cc:ed); in that thread (June > > 2004, mostly not threaded in the mail archive, broken MUAs :-( ) it was > > said that any clobber should be considered an earlyclobber (an RTL insn > > can expand to multiple machine instructions, for example). But I don't > > see how that can matter for "dest" here (the dest of "insn", that's 76 > > in the example), only for "src". > > > > The version of "flags" set in 76 obviously dies in 77 (it clobbers the > > reg after all), but there is no way it could clobber it before it uses > > it, that just makes no sense. And in the combined insn that version of > > flags does not exist at all. > Agreed, otherwise it would be another uninitialized use problem. > Maybe the check is too strict here? Do you have some archived page > address for that, just saving us some time for digging. http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00994.html (and look in that month's archives for the rest of the messages). > My only concern is, logic in dictribute_notes should also be revisited > under this BZ. I think the issue will be hidden by changes we are > talking about in can_combine_p. Yes. Unless we disallow all combinations that *would* cause problems :-) Segher