From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8551 invoked by alias); 7 Jan 2010 08:22:20 -0000 Received: (qmail 8470 invoked by uid 48); 7 Jan 2010 08:22:05 -0000 Date: Thu, 07 Jan 2010 08:22:00 -0000 Message-ID: <20100107082205.8469.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug rtl-optimization/42511] [4.5 Regression] bootstrap error in stage3 on alpha-linux-gnu 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/msg00742.txt.bz2 ------- Comment #23 from ebotcazou at gcc dot gnu dot org 2010-01-07 08:22 ------- > I'm thinking about the same situation with cse2, where constant assignment > (with its REG_EQUAL note) would match another assignment with the same > REG_EQUAL note. cse2 can equal this other assignment (through matching > REG_EQUAL notes) to the constant - actually the same thing that happens in our > problematic case. Since this transformation would happen in the same BB, it > would be perfectly valid - and disabled by removing REG_EQUAL note on > constant. This mechanism very likely results in a bug if the 2 insns are not originally in the same BB, like in the case at hand. So, assuming they are originally in the same BB and carry the same REG_EQUAL note, the constant will be propagated in both insns. > Sure, but after the assigment was moved, REG_EQUAL points to invalid > assignment, see this part from the dumps: > > 39 r78:DI=zero_extend(r154:QI) > REG_DEAD: r154:QI > REG_EQUAL: zero_extend([r152:DI]) > 583 r82:DI=0x0 << here > REG_EQUAL: zero_extend([r152:DI]) > 40 pc={(r78:DI==0x0)?L230:pc} > REG_BR_PROB: 0x1388 > > The proposed change removes REG_EQUAL note only on moved insn, (insn 538) in > our case. That's too aggressive in the general case, no need to remove a REG_EQUAL note pointing to a constant if the SRC is also function_invariant_p. An acceptable compromise could be to remove the note only if its content is also not itself function_invariant_p. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42511