[llvm-dev] clang-cl and exceptions

[Russell Wallace via llvm-dev]

Ah, that makes sense, thanks!

On Wed, Sep 2, 2015 at 6:28 PM, Reid Kleckner <rnk at google.com> wrote:

> This was intentional, since the old implementation was broken. VS projects
> set /EHsc by default, so users who weren't actively using EH were
> automatically getting EH anyway, which would crash the compiler. I can't
> reasonably ask everyone who wants to try clang to manually change their VS
> project settings, so I made clang-cl temporarily ignore /EHs.
>
> We've started over with new LLVM IR constructs for representing Windows
> EH, and when that's done, we can make /EHs enable it. For now you have to
> pass all of the following to clang-cl to try the new implementation:
> -Xclang -fexceptions -Xclang -fcxx-exceptions -Xclang -fnew-ms-eh
>
> The current status is that we can catch some 32-bit exceptions, but will
> usually crash at runtime. The compiler will reject destructor cleanups very
> late during codegen.
>
> Hope that helps.
>
> For future reference, this is more of a cfe-dev kind of topic.
>
> On Wed, Sep 2, 2015 at 3:25 AM, Russell Wallace via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Tried a small test just now to see how exception handling on Windows is
>> getting on, and it seems to work except for one thing.
>>
>> clang-cl /EHsc (the Microsoft compiler option to enable exceptions)
>> doesn't do anything; they remain disabled. However, -Xclang
>> -fcxx-exceptions succeeds. Is this a bug in the handling of compatibility
>> options or am I missing something?
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150902/90d7c45d/attachment.html>