[cfe-dev] clang-cl equivalent option for VC++'s /EH(x)
eldlistmailingz at tropicsoft.com
Thu Dec 5 23:49:10 PST 2013
On 12/5/2013 11:42 PM, Charles Davis wrote:
> On Nov 20, 2013, at 3:15 PM, Edward Diener wrote:
>> On 11/20/2013 1:15 PM, Reid Kleckner wrote:
>>> 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
>> 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
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
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. ;)
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
More information about the cfe-dev