[cfe-dev] clang-cl equivalent option for VC++'s /EH(x)

[Edward Diener]

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
>>> 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. ;)

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.