Re: [tree-ssa] Mainline merge as of 2003-04-06

[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