[cfe-dev] One more EH patch...

[Daniel Dunbar]

On Sat, May 9, 2009 at 6:09 AM, David Chisnall <csdavec at swansea.ac.uk> wrote:
> On 9 May 2009, at 12:40, David Chisnall wrote:
>
>> This one fixes the case where an exception is thrown inside a @catch()
>> block (GNU runtime).
>
> And this version now emits code for @synchronized.  As with GCC, this code
> doesn't actually work, because the required functions are not present in the
> GNU runtime library.
>
> I've also attached the test case I've been using while working on this.  The
> following two commands should produce the same output:
>
> clang  -lobjc -fexceptions trycatch.m -g && ./a.out
> gcc -lobjc -fobjc-exceptions trycatch.m && ./a.out
>
> I don't know if someone wants to add this to the clang test suite.

Right now we don't have executable test cases in the suite, and do
have an active policy to avoid them. I think we should eventually
extend the test infrastructure so that we can have some (optionally
executable) executable tests, but this hasn't really been discussed.

What you can do if you like is add them to the llvm-test suite, with
appropriate Makefile magic to only enable if the platform supports it.
I have already added a few NeXT Objective-C tests there (although
nothing particularly consequential).

> At the moment, clang has the same behaviour as gcc when -fexceptions is not
> specified; it generates code which aborts at runtime if an exception is
> thrown, rather than handling it.  Although this is the same as gcc, it seems
> like the wrong thing to do.  We should probably either:
>
> 1) Implicitly turn on -fexceptions when @try/@catch/@throw/@synchronized is
> encountered, or
> 2) Emit an error and let the user know at compile-time that they are
> generating broken code.
>
> My personal preference would be (2), because all of the intervening
> functions between the @throw and the @catch should be compiled with
> exception support to work correctly, and it's likely that just turning on
> exceptions for the files that throw or catch them will introduce subtle
> failures.

#2, definitely.

 - Daniel

> David
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>