This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa] Mainline merge as of 2003-04-06
- From: law at redhat dot com
- To: Diego Novillo <dnovillo at redhat dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Thu, 10 Apr 2003 10:19:52 -0600
- Subject: Re: [tree-ssa] Mainline merge as of 2003-04-06
- Reply-to: law at redhat dot com
In message <1049944224 dot 5236 dot 145 dot camel at frodo dot toronto dot redhat dot com>, Diego Novillo
writes:
>When you are about to make the recursive call to make_blocks to build
>the blocks for the body of the TRY_EXPR, you should set the
>NEXT_BLOCK_LINK argument to whichever statement should execute after
>that body has executed.
Remember, we're trying to get the correct NEXT_BLOCK_LINK for block #2 for
the following code:
# BLOCK 0 (k.C:13). PRED:. SUCC:.
{
<UVcf50> = __cxa_allocate_exception (1);
try
{
# BLOCK 1 (k.C:14). PRED:. SUCC:.
T.1 = (struct bad_cast *)<UVcf50>;
{
struct bad_cast * const this;
this = (struct bad_cast * const)T.1;
{
try
{
# BLOCK 2 (k.C:7). PRED:. SUCC:.
{
{
(void)0
}
}
}
catch
{
# BLOCK 3 (k.C:7). PRED:. SUCC:.
<<<eh_filter ()>>>
{
# BLOCK 4 (k.C:7). PRED:. SUCC:.
__cxa_call_unexpected (<<<exception object>>>)
}
}
}
};
1-> (void)0
}
catch
{
# BLOCK 5 (k.C:14). PRED:. SUCC:.
<<<eh_filter ()>>>
{
# BLOCK 6 (k.C:14). PRED:. SUCC:.
terminate ()
}
};
# BLOCK 7 (k.C:14). PRED:. SUCC:.
2-> _ZTISt8bad_cast.2 = &_ZTISt8bad_cast;
__cxa_throw (<UVcf50>, _ZTISt8bad_cast.2, 0B)
}
}
Should NEXT_BLOCK_LINK point to the statement at point #1 or point #2 in
the above code?
If it should point to #2, then all these little fragments in tree-cfg.c
must skip empty statements when trying to determine what NEXT_BLOCK_LINK
ought to be to catch cases were a tree ends with one or more empty
statement statements:
/* Determine NEXT_BLOCK_LINK for statements inside the COND_EXPR body. */
si = tsi_start (cond_p);
tsi_next (&si);
if (!tsi_end_p (si))
next_block_link = *(tsi_container (si));
Would skipping through empty statements in these loops potentially
cause problems elsewhere?
--
If NEXT_BLOCK_LINK should point to #1 above (which is what we do right
now as far as I can tell), then, well, I'm not sure how to proceed, but
I know it won't be particularly pretty
Jeff