[llvm-dev] clang-cl and exceptions
Reid Kleckner via llvm-dev
llvm-dev at lists.llvm.org
Wed Sep 2 10:28:32 PDT 2015
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/dcefc164/attachment.html>
More information about the llvm-dev
mailing list