From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2682 invoked by alias); 12 Jan 2010 08:57:39 -0000 Received: (qmail 2571 invoked by uid 48); 12 Jan 2010 08:57:26 -0000 Date: Tue, 12 Jan 2010 08:57:00 -0000 Message-ID: <20100112085726.2570.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug rtl-optimization/42691] problematic REG_EQUAL note added to SUBREG In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "ebotcazou at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2010-01/txt/msg01304.txt.bz2 ------- Comment #4 from ebotcazou at gcc dot gnu dot org 2010-01-12 08:57 ------- > Then gcc comes to line3657. Since changed_i3_dest is 0, gcc does not > call adjust_for_new_dest at all. > > line3657: > if (changed_i3_dest) > { > PATTERN (i3) = newpat; > adjust_for_new_dest (i3); > } We should try and set changed_i3_dest to 1 in this particular case as well. Where does the dest get changed exactly? > I did not read the entire combine pass. So I am not sure whether it is > fine to just add something like this after line3062 where > recog_for_combine is called. > > if (insn_code_number >= 0) > changed_i3_dest = 1; Too big a hammer, the dest of I3 is generally not changed. > Another option to fix this problem is not to attach REG_EQUAL note to > "set subreg reg" at all during forward propagation. Too big a hammer as well, the note is correct at this point. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42691