* More info on exception bug
@ 1997-10-02 12:51 H.J. Lu
1997-11-01 19:59 ` Jeffrey A Law
0 siblings, 1 reply; 3+ messages in thread
From: H.J. Lu @ 1997-10-02 12:51 UTC (permalink / raw)
To: egcs
Hi,
It seems that expand_exception_blocks () in cp/except.c is kind of
screwed up. When entering expand_exception_blocks (),
pending_stack_adjust is 0. But in expand_leftover_cleanups (),
pending_stack_adjust is changed for the exception handler. As the
result, the stacks of the function and its exception handler are
all mixed up.
I am enclosing a kludge here. There must be a better fix than that.
Thanks.
--
H.J. Lu (hjl@gnu.ai.mit.edu)
---
Thu Oct 2 12:41:44 1997 H.J. Lu (hjl@gnu.ai.mit.edu)
* except.c (expand_exception_blocks): Inhibit deferred pop
in the exception handler.
Index: cp/except.c
===================================================================
RCS file: /home/work/cvs/gnu/egcs/gcc/cp/except.c,v
retrieving revision 1.1.1.3
diff -u -r1.1.1.3 except.c
--- except.c 1997/09/17 20:10:28 1.1.1.3
+++ except.c 1997/10/02 19:48:28
@@ -1000,6 +1000,9 @@
void
expand_exception_blocks ()
{
+ /* No deferred pop in the exception handling. */
+ NO_DEFER_POP;
+
push_to_sequence (catch_clauses);
expand_leftover_cleanups ();
catch_clauses = get_insns ();
@@ -1017,6 +1020,8 @@
catch_clauses = get_insns ();
end_sequence ();
}
+
+ OK_DEFER_POP;
if (catch_clauses)
{
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: More info on exception bug
1997-10-02 12:51 More info on exception bug H.J. Lu
@ 1997-11-01 19:59 ` Jeffrey A Law
1997-11-02 9:36 ` H.J. Lu
0 siblings, 1 reply; 3+ messages in thread
From: Jeffrey A Law @ 1997-11-01 19:59 UTC (permalink / raw)
To: H.J. Lu; +Cc: egcs
In message <m0xGrFm-0004eeC@ocean.lucon.org>you write:
> Hi,
>
> It seems that expand_exception_blocks () in cp/except.c is kind of
> screwed up. When entering expand_exception_blocks (),
> pending_stack_adjust is 0. But in expand_leftover_cleanups (),
> pending_stack_adjust is changed for the exception handler. As the
> result, the stacks of the function and its exception handler are
> all mixed up.
>
> I am enclosing a kludge here. There must be a better fix than that.
I believe Jason fixed this on Oct 20th:
Mon Oct 20 12:06:34 1997 Jason Merrill <jason@yorick.cygnus.com>
* except.c (expand_exception_blocks): Call do_pending_stack_adust.
(expand_end_catch_block): Likewise.
(expand_end_eh_spec): Likewise.
Your testcase compiles and executes fine for me on my linux box.
jeff
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: More info on exception bug
1997-11-01 19:59 ` Jeffrey A Law
@ 1997-11-02 9:36 ` H.J. Lu
0 siblings, 0 replies; 3+ messages in thread
From: H.J. Lu @ 1997-11-02 9:36 UTC (permalink / raw)
To: law; +Cc: egcs
>
> In message <m0xGrFm-0004eeC@ocean.lucon.org>you write:
> > Hi,
> >
> > It seems that expand_exception_blocks () in cp/except.c is kind of
> > screwed up. When entering expand_exception_blocks (),
> > pending_stack_adjust is 0. But in expand_leftover_cleanups (),
> > pending_stack_adjust is changed for the exception handler. As the
> > result, the stacks of the function and its exception handler are
> > all mixed up.
> >
> > I am enclosing a kludge here. There must be a better fix than that.
> I believe Jason fixed this on Oct 20th:
>
> Mon Oct 20 12:06:34 1997 Jason Merrill <jason@yorick.cygnus.com>
>
> * except.c (expand_exception_blocks): Call do_pending_stack_adust.
> (expand_end_catch_block): Likewise.
> (expand_end_eh_spec): Likewise.
>
> Your testcase compiles and executes fine for me on my linux box.
> jeff
>
Yes. Thanks.
--
H.J. Lu (hjl@gnu.ai.mit.edu)
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~1997-11-02 9:36 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1997-10-02 12:51 More info on exception bug H.J. Lu
1997-11-01 19:59 ` Jeffrey A Law
1997-11-02 9:36 ` H.J. Lu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).