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? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150902/fd351e3c/attachment.html>
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>
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>
Possibly Parallel Threads
- [LLVMdev] Compiling via bitcode on Windows
- [LLVMdev] is it impossible to use the external llvm custom pass on windows?
- Propagation of foreign c++ exceptions (msvc, x64, llvm 3.7.1, MCJIT) through IR code
- [LLVMdev] Unwind behaviour in Clang/LLVM
- Exceptions on Windows & MSVC