Richard Henderson wrote:
On Thu, Apr 14, 2005 at 05:26:15PM -0700, Mark Mitchell wrote:
Richard, what's your level of confidence here? I'd rather not break C++
or Java...
I think it's pretty safe.
OK, Alexandre, please install the patch.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
On Apr 15, 2005, Mark Mitchell [EMAIL PROTECTED] wrote:
Richard Henderson wrote:
On Thu, Apr 14, 2005 at 05:26:15PM -0700, Mark Mitchell wrote:
Richard, what's your level of confidence here? I'd rather not
break C++ or Java...
I think it's pretty safe.
OK, Alexandre, please install the
On Thu, Apr 14, 2005 at 12:13:59PM -0300, Alexandre Oliva wrote:
* tree-eh.c (lower_try_finally_copy): Generate new code in
response to goto_queue entries as if the queue was sorted by
index, not pointers.
(lower_try_finally_switch): Likewise.
Ok.
r~
On Apr 14, 2005, Richard Henderson [EMAIL PROTECTED] wrote:
On Thu, Apr 14, 2005 at 12:13:59PM -0300, Alexandre Oliva wrote:
* tree-eh.c (lower_try_finally_copy): Generate new code in
response to goto_queue entries as if the queue was sorted by
index, not pointers.
Alexandre Oliva wrote:
On Apr 14, 2005, Richard Henderson [EMAIL PROTECTED] wrote:
On Thu, Apr 14, 2005 at 12:13:59PM -0300, Alexandre Oliva wrote:
* tree-eh.c (lower_try_finally_copy): Generate new code in
response to goto_queue entries as if the queue was sorted by
index, not pointers.
On Apr 14, 2005, Mark Mitchell [EMAIL PROTECTED] wrote:
Alexandre Oliva wrote:
On Apr 14, 2005, Richard Henderson [EMAIL PROTECTED] wrote:
On Thu, Apr 14, 2005 at 12:13:59PM -0300, Alexandre Oliva wrote:
* tree-eh.c (lower_try_finally_copy): Generate new code in
response to goto_queue
On Thu, Apr 14, 2005 at 05:26:15PM -0700, Mark Mitchell wrote:
Richard, what's your level of confidence here? I'd rather not break C++
or Java...
I think it's pretty safe.
r~
On Apr 12, 2005, Alexandre Oliva [EMAIL PROTECTED] wrote:
It looks like it wouldn't be too hard to overcome this problem by
generating the artificial labels in case_index order, instead of in
goto_queue order, but it's not obvious to me that the potential
randomness from sorting of stmt
On Apr 4, 2005, Richard Henderson [EMAIL PROTECTED] wrote:
On Mon, Apr 04, 2005 at 07:57:09PM -0300, Alexandre Oliva wrote:
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.
On Apr 11, 2005, Alexandre Oliva [EMAIL PROTECTED] wrote:
On Apr 4, 2005, Richard Henderson [EMAIL PROTECTED] wrote:
On Mon, Apr 04, 2005 at 07:57:09PM -0300, Alexandre Oliva wrote:
My head hurts about the GGC implications of opaque pointers in such a
hash table, and retaining pointers in
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
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
On Mon, Apr 04, 2005 at 07:21:43PM -0300, Alexandre Oliva wrote:
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.
I've heard both versions: that hashing on pointers is no big
deal, and that
On Mon, Apr 04, 2005 at 08:06:42PM -0400, Diego Novillo wrote:
On Mon, Apr 04, 2005 at 07:21:43PM -0300, Alexandre Oliva wrote:
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.
I've
On Mon, Apr 04, 2005 at 07:57:09PM -0300, Alexandre Oliva wrote:
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.
These are solved problems.
Joe has the correct answer to the
I've been getting bootstrap failures on i686-pc-linux-gnu for the past
few days, with --enable-languages=all,ada, on Fedora Core devel.
There are indeed differences between stage2 and stage3 targparm.o, but
upon visual inspection, they appear to be harmless, possibly some
effect of FP extra
Hi Alex,
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.
Cheers
Graham
17 matches
Mail list logo
