On Apr 4, 2005, Dale Johannesen <[EMAIL PROTECTED]> wrote: > On Apr 4, 2005, at 3:21 PM, Alexandre Oliva wrote:
>> On Apr 4, 2005, Dale Johannesen <[EMAIL PROTECTED]> wrote: >> >>> On Apr 4, 2005, at 2:32 PM, Alexandre Oliva wrote: >>>> On Mar 26, 2005, Graham Stott <[EMAIL PROTECTED]> 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 > http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01760.html > the hash table in question is built by DOM, and in > http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01810.html > 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 http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
