clang-cl equivalent option for VC++'s /EH(x)

Does clang-cl have any equivalent option for VC++'s /EH(x) series of choices for exception handling and asynchronous exception handling when compiling under Windows using the VC++ RTL, since it does not support the /EH(x) compiler flags ?

clang-cl currently does not expose this option because LLVM doesn’t support VC+±compatible 32-bit exception handling today. However, I believe it does support win64 exceptions, but I haven’t tested it personally.

LLVM will probably never support the full asynchronous exception model of MSVC because it won’t ever model control flow from each load, store, or div that might trap to associated cleanup code.

I would support wiring up /EH(x) to support C++ exceptions on win64, and warning that we’re ignoring it on 32-bit Windows like we do today. We should probably warn on the ‘a’ modifier, since we won’t implement it.

clang-cl currently does not expose this option because LLVM doesn't
support VC++-compatible 32-bit exception handling today. However, I
believe it *does* support win64 exceptions, but I haven't tested it
personally.

What do you mean by "win64" exceptions ?

LLVM will probably never support the full asynchronous exception model
of MSVC because it won't ever model control flow from each load, store,
or div that might trap to associated cleanup code.

I would support wiring up /EH(x) to support C++ exceptions on win64, and
warning that we're ignoring it on 32-bit Windows like we do today. We
should probably warn on the 'a' modifier, since we won't implement it.

Does clang-cl therefore automatically handle synchronous C++ exceptions and not handle asynchronous structured error handling exceptions ?

Does it do anything about extern "C" functions which may or may not throw exceptions, or is this just a VC++-ism irrelevant to clang-cl ?

However, I believe it does support win64 exceptions, but I haven’t tested it personally.

It does not, because I never finished that support. :wink: Kai Nacke is working on finishing it (based on the unfinished patch I sent him), but the part that actually calls MC to write the Win64 SEH unwinding instructions hasn’t been committed yet. He recently sent an updated patch to llvm-commits; you might try that ;).

LLVM will probably never support the full asynchronous exception model of MSVC because it won’t ever model control flow from each load, store, or div that might trap to associated cleanup code.

I would support wiring up /EH(x) to support C++ exceptions on win64, and warning that we’re ignoring it on 32-bit Windows like we do today. We should probably warn on the ‘a’ modifier, since we won’t implement it.

Just so you know, explicit SEH (i.e. ‘__try’/’__except’/’__finally’ blocks) needs the ‘a’ modifier to work fully. (At least, that’s what the documentation says. My informal and incomplete testing seems to indicate otherwise.)

clang-cl currently does not expose this option because LLVM doesn't
support VC++-compatible 32-bit exception handling today. However, I
believe it *does* support win64 exceptions, but I haven't tested it
personally.

What do you mean by "win64" exceptions ?

We mean the table-based exception handling model used by Windows/x64, as opposed to the frame-based model used by Windows/x86.

LLVM will probably never support the full asynchronous exception model
of MSVC because it won't ever model control flow from each load, store,
or div that might trap to associated cleanup code.

I would support wiring up /EH(x) to support C++ exceptions on win64, and
warning that we're ignoring it on 32-bit Windows like we do today. We
should probably warn on the 'a' modifier, since we won't implement it.

Does clang-cl therefore automatically handle synchronous C++ exceptions and not handle asynchronous structured error handling exceptions ?

It doesn't handle anything at the moment, at all. And even if the Win64 table-based SEH support were finished, the MSVC ABI (which clang-cl uses by default, I believe) still won't magically grow EH support, because RTTI needs to be implemented first. (Frame-based SEH for 32-bit x86 is yet another matter.)

Does it do anything about extern "C" functions which may or may not throw exceptions, or is this just a VC++-ism irrelevant to clang-cl ?

Don't worry, we just haven't gotten around to implementing that particular functionality yet. As always, patches welcome. :wink:

Chip

clang-cl currently does not expose this option because LLVM doesn't
support VC++-compatible 32-bit exception handling today. However, I
believe it *does* support win64 exceptions, but I haven't tested it
personally.

What do you mean by "win64" exceptions ?

We mean the table-based exception handling model used by Windows/x64, as opposed to the frame-based model used by Windows/x86.

LLVM will probably never support the full asynchronous exception model
of MSVC because it won't ever model control flow from each load, store,
or div that might trap to associated cleanup code.

I would support wiring up /EH(x) to support C++ exceptions on win64, and
warning that we're ignoring it on 32-bit Windows like we do today. We
should probably warn on the 'a' modifier, since we won't implement it.

Does clang-cl therefore automatically handle synchronous C++ exceptions and not handle asynchronous structured error handling exceptions ?

It doesn't handle anything at the moment, at all. And even if the Win64 table-based SEH support were finished, the MSVC ABI (which clang-cl uses by default, I believe) still won't magically grow EH support, because RTTI needs to be implemented first. (Frame-based SEH for 32-bit x86 is yet another matter.)

The lack of RTTI support is the primary showstopper I have encountered when testing Boost libraries against the latest clang-cl. Quite honestly until this is fixed in clang-cl it is not worthwhile for me to further test clang-cl against Boost libraries and see what other problems migh ensue. In cases where no RTTI is needed in a Boost library and its dependencies clang-cl works quite well but a number of Boost's lowest level libraries include <typeinfo> and this leads to the clang-cl errors:

error: cannot mangle RTTI descriptors for type 'codecvt' yet
error: cannot mangle the name of type 'codecvt' into RTTI descriptors yet
error: cannot mangle RTTI descriptors for type 'codecvt_base' yet
error: cannot mangle the name of type 'codecvt_base' into RTTI descriptors yet
error: cannot mangle RTTI descriptors for type 'facet' yet
error: cannot mangle the name of type 'facet' into RTTI descriptors yet
error: cannot mangle RTTI descriptors for type '_Facet_base' yet
error: cannot mangle the name of type '_Facet_base' into RTTI descriptors yet

While the /fallback switch can be used for the individual cases, it is both too tedious to specify for each individual case in Boost build scripts and provides no real clang-cl result for that individual case since it is just a means of turning over compilation to VC++.

I realize clang developers have their own priorities but this is easily the top priority for using clang-cl under Windows for Boost compilation.

Does it do anything about extern "C" functions which may or may not throw exceptions, or is this just a VC++-ism irrelevant to clang-cl ?

Don't worry, we just haven't gotten around to implementing that particular functionality yet. As always, patches welcome. :wink:

I am not a clang developer <g>, just trying to test clang-cl for Boost and reporting problems if I see them. I have other work I do with my own Boost library, proposed libraries, and help with some other existing Boost libraries.