This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: bootstrap compare failure in ada/targparm.o on i686-pc-linux-gnu?

On Apr  4, 2005, Dale Johannesen <> wrote:

> On Apr 4, 2005, at 3:21 PM, Alexandre Oliva wrote:

>> On Apr  4, 2005, Dale Johannesen <> wrote:
>>> On Apr 4, 2005, at 2:32 PM, Alexandre Oliva wrote:
>>>> On Mar 26, 2005, Graham Stott <> 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.

> Hmm.  Of the earlier bugs, in
> the hash table in question is built by DOM, and in
> it's built by PRE (VN).  I don't think there's general agreement
> that "we shouldn't be hashing on pointers"....

Odd...  I was pretty sure there was.  Maybe it's only in binutils?  I
thought we'd been sufficiently bitten by pointer-hashing problems in
GCC to know better.

Anyhow...  The only way I can think of to enable us to hash on
pointers that doesn't involve adding an id to every tree node
(assuming the issue only shows up with tree nodes) is to create a
separate table to maps arbitrary pointers to an intptr_t counter that
gets incremented every time a pointer is added to this hash table.
Computing the hash of a pointer would then amount to looking the
pointer up in this table and obtaining its value.  We could set a
number aside (say 0 or -1) to use in NO_INSERT lookups.

My head hurts about the GGC implications of opaque pointers in such a
hash table, and retaining pointers in the hash table that have already
been otherwise freed.  It surely doesn't hurt, unless you actually
want to save/restore this table; it's perfectly ok to reuse an id for
a pointer to a recycled memory area.  But this table would spend
memory and slow things down.  Maybe we should only use it for
bootstraps (enabled with a flag in the default BOOT_CFLAGS), and
simply hash pointers if the flag is not given?

Alexandre Oliva   
Red Hat Compiler Engineer   aoliva@{,}
Free Software Evangelist  oliva@{,}

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]