Re: [3.3] Followup to C++ forced unwinding

[Mark Mitchell <mark at codesourcery dot com>]

On Wed, 2003-04-30 at 10:53, Richard Henderson wrote:
> The result of the original thread
> 
>     http://gcc.gnu.org/ml/gcc-patches/2003-04/msg00008.html
> 
> endorsed different semantics than I assumed in my original
> patch.  Here I update things to match the consensus.

So, if I understand the patch:

(1) The libsupc++ bits make:

      void f() throw () { read (...); }
  
    be handled just like:

      void f() throw () { throw 3; }
 
    would.

    Those bits are fine.

(2) You made the C++ front end tell the truth about C library functions,
in that -- with -fforced-unwind-exceptions -- we now treat cancellable
library functions as possibly throwing exceptions.  These bits are fine.

(3) You've taught the middle end not to emit cleanups if a region does
not contain any calls to functions that may throw, even if
-fforced-unwind-exceptions is on.  This is an improvement to my earlier
compile-time performance fix, and works because you now know which
library functions might be cancellable.  These bits are fine.

(4) Some other black magic in except.c that I couldn't get my head
around on the first try.  What do these bits do?

One key question that I'm not sure got resolved on the thread was what
happens in this case:

   try { 
     // Something that might:
     // (a) result in cancellation.
     // (b) result in a foreign exception being thrown.
     // (c) result in longjmp_unwind being called.
   } catch (...) {
     // There is no "throw;" here to rethrow.
   }

Presumably (a) is the same as either (b) or (c).  Which one?

And, if which of these cases are we implicitly rethrowing from the
catch, even though the user didn't write "throw;"?  

Does the IA-64 ABI specify this?

The reason I ask is that:

  f = fopen(...);
  try {
  } catch (...) {
  }
  fclose (f);

looks to a C++ programmer to be a perfectly safe piece of code, modulo
longjmp.  I wouldn't be too unhappy if longjmp_unwind skipped closing
"f", as longjmp would do that anyhow, and longjmp_unwind is this new
weird thing that can do whatever it wants to do.  

But, I'd be unhappy if foreign exceptions and/or thread cancellation did
an implicit rethrow.

Thanks,

-- 
Mark Mitchell <mark@codesourcery.com>
CodeSourcery, LLC