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

[Daniel Dunbar]

On Mon, May 11, 2009 at 1:00 PM, David Chisnall <csdavec at swansea.ac.uk> wrote:
> On 11 May 2009, at 20:49, Fariborz Jahanian wrote:
>> On May 11, 2009, at 11:34 AM, Chris Lattner wrote:
>>> On May 9, 2009, at 6:09 AM, David Chisnall 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.
>>>
>>> Thanks David, applied.  I don't have an opinion on:
>>>
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>>
>>
>> This may make sense for Gnu runtime. But for us, objc runtime library
>> always
>> supports the eh. Any error reporting should be done on the GNU side.
>
> Are you sure about this?  I just compiled a trivial test function
> containing @throw, @catch and @finally with -emit-llvm -fnext-runtime
> and -fobjc2, but without -fexceptions, and it emitted bitcode
> containing references to the LLVM exception intrinsics in a function
> marked as nounwind.  This is exactly what happens on the GNU runtime
> without -fexceptions, and it results in LLVM not emitting the
> unwinding info for the function and the unwind library being unable to
> unwind into it.

I think this is probably a bug, can you file it?

 - Daniel

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