This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: bootstrap compare failure in ada/targparm.o on i686-pc-linux-gnu?
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: Dale Johannesen <dalej at apple dot com>, rth at redhat dot com, dnovillo at redhat dot com
- Cc: gcc at gcc dot gnu dot org, Graham Stott <graham dot stott at btinternet dot com>
- Date: 04 Apr 2005 19:21:43 -0300
- Subject: Re: bootstrap compare failure in ada/targparm.o on i686-pc-linux-gnu?
- Organization: Red Hat Global Engineering Services Compiler Team
- References: <oroed6ptx3.fsf@livre.redhat.lsd.ic.unicamp.br><42454D1C.1080208@btinternet.com><orvf72grcs.fsf@livre.redhat.lsd.ic.unicamp.br><0c570d2572e3680b41ebffaddac9cf60@apple.com>
On Apr 4, 2005, Dale Johannesen <dalej@apple.com> wrote:
> On Apr 4, 2005, at 2:32 PM, Alexandre Oliva wrote:
>> On Mar 26, 2005, Graham Stott <graham.stott@btinternet.com> wrote:
>>> I do regular bootstraps of mainline all languages on FC3
>>> i686-pc-linuux-gnu and haven't seen any problemss upto Friday. I'm
>>> using --enable-checking=tree,misc,rtl,rtlflag which might make a
>>> difference.
>> I'm still observing this problem every now and then. It's not
>> consistent or easily reproducible, unfortunately. I suspect we're
>> using pointers somewhere, and that stack/mmap/whatever address
>> randomization is causing different results. I'm looking into it.
> I've found 2 bugs over the last 6 months where the problem is exposed
> only if two pointers happen to hash to the same bucket. It's occurred
> to me that doing a bootstrap with all hashtable sizes set to 1 might be
> a good idea.
Perhaps. But the fundamental problem is that we shouldn't be hashing
on pointers, and tree-eh.c does just that for finally_tree and
throw_stmt_table.
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}