From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9709 invoked by alias); 24 Nov 2009 18:42:21 -0000 Received: (qmail 9630 invoked by alias); 24 Nov 2009 18:42:05 -0000 Date: Tue, 24 Nov 2009 18:42:00 -0000 Message-ID: <20091124184205.9629.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug bootstrap/42157] [4.5 regression] ICE building stage 1 libgcc on IRIX 5.3: SEGV in compare_access_positions In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "ro at CeBiTec dot Uni-Bielefeld dot DE" 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: 2009-11/txt/msg02077.txt.bz2 ------- Comment #2 from ro at CeBiTec dot Uni-Bielefeld dot DE 2009-11-24 18:42 ------- Subject: Re: [4.5 regression] ICE building stage 1 libgcc on IRIX 5.3: SEGV in compare_access_positions > ------- Comment #1 from jamborm at gcc dot gnu dot org 2009-11-24 18:16 ------- > Can you please add a check before the qsort call (tree-sra.c, line > 1407) whether all pointers in the access_vec seem OK or whether it is > SRA that passes the invalid pointer to qsort? Nothing fancy, > something as stupid as the loop below should do: > > for (i =0; i < access_count; i++) > gcc_assert (((unsigned) VEC_index (access_p, access_vec, i)) > 0x1000); > > If it passes I can't see any other explanation but a bad qsort. If it > doesn't we'll need to figure out how the bad pointers get there. It seems that the qsort is broken (although I haven't found any report about qsort on IRIX 5.3 yet). Anyway, I've added a slightly modified qsort from glibc to libiberty (which won't work due to license differences, I suppose, but maybe newlib is an option), which allowed the bootstrap to continue. I'll later check (either with the code above or with gdb watchpoints) what is causing the corruption. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42157