From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13808 invoked by alias); 7 Sep 2008 16:02:42 -0000 Received: (qmail 13643 invoked by uid 48); 7 Sep 2008 16:01:19 -0000 Date: Sun, 07 Sep 2008 16:02:00 -0000 Message-ID: <20080907160119.13642.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug rtl-optimization/37377] [4.4 Regression] Bootstrap failure compiling libgcc 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: 2008-09/txt/msg00835.txt.bz2 ------- Comment #10 from ebotcazou at gcc dot gnu dot org 2008-09-07 16:01 ------- The problem is the 4th line in Remove r222:a590->a10(mem) Remove r69:a566->a389(mem) Remove r69:a549->a389(mem) Remove r376:a432->a12(mem) Remove r220:a148->a9(mem) (r373 is now r376 on mainline) generated by generate_edge_moves: /* Actually it is not a optimization we need this code because the memory (remember about equivalent memory) might be ROM (or placed in read only section). */ if (ALLOCNO_HARD_REGNO (dest_allocno) < 0 && ALLOCNO_HARD_REGNO (src_allocno) >= 0 && not_modified_p (src_allocno, dest_allocno)) { ALLOCNO_MEM_OPTIMIZED_DEST (src_allocno) = dest_allocno; ALLOCNO_MEM_OPTIMIZED_DEST_P (dest_allocno) = true; if (internal_flag_ira_verbose > 3 && ira_dump_file != NULL) fprintf (ira_dump_file, " Remove r%d:a%d->a%d(mem)\n", regno, ALLOCNO_NUM (src_allocno), ALLOCNO_NUM (dest_allocno)); continue; } Here's the list of allocnos for r376: 579:r376 l20 5 562:r376 l21 5 545:r376 l23 5 526:r376 l24 5 507:r376 l25 5 460:r376 l22 5 446:r376 l19 5 432:r376 l8 5 398:r376 l7 5 386:r376 l9 mem 366:r376 l13 mem 343:r376 l14 mem 320:r376 l16 mem 295:r376 l17 mem 270:r376 l18 mem 227:r376 l15 mem 213:r376 l12 mem 199:r376 l11 mem 167:r376 l10 mem 12:r376 l0 mem The move putting back r376 to its memory location is not generated on a border of the "5" domain. This domain contains the 2nd and 3rd insns of comment #4. Moreover, the live range of a460 is not added to that of a12 during flattening so r376 is not detected as conflicting with r90 (formerly r85) and r92 (f r87). In the end, the memory location of r376 is reused within the "5" domain without being reset at the border. If I comment out the code quoted above, the compiler bootstraps fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37377