[cfe-dev] Clang for Windows and Boost

[John McCall]

On Mar 18, 2011, at 7:24 PM, Óscar Fuentes wrote:

> John McCall <rjmccall-2kanFRK1NckAvxtiuMwx3w at public.gmane.org> writes:
> 
>> On Mar 18, 2011, at 5:41 PM, Ahmed Charles wrote:
>>> Does clang built with MSVC support exceptions? Or is it such that
>>> clang + windows = no eh support?
>> 
>> IANAL, but the conventional wisdom is that Windows SEH cannot be
>> implemented by arbitrary compilers because it is protected by
>> U.S. Patent # 5,628,016, issued to Borland and presumably licensed
>> by other compiler vendors.  Absent a generous grant of technology,
>> we will not be able to support EH on Windows until that patent expires,
>> which (again, IANAL) is on June 14th, 2014.
> 
> Structured Exception Handling != C++ exceptions.

Yes, but "Windows" means the Microsoft C++ implementation unless
otherwise specified (moreso because the question was asking about MSVC),
and none of the other EH implementations interoperate with that.

>> If you only care about interoperability with mingw, it apparently doesn't
>> work, but I don't really know what the issues are.
> 
> I guess that the missing pieces pertain to Clang's C++ runtime
> libraries. Platform-specific bits. Or does Clang use the g++ libraries
> for EH? If that's the case, we need to teach Clang how to use them for
> MinGW/Dwarf

We produce binaries that will link and run with libstdc++ and its EH runtime
on a good variety of other platforms; that's a reasonable goal on MinGW, too.
I just don't know how mingw's requirements for the EH tables differ from, say,
Linux's.

> (assuming that Clang has no support for SJLJ).

Right.  Even if we wanted to support GCC-style SJ/LJ exceptions, they
should really be lowered to actual setjmp calls mostly by the backend —
we implemented "legacy" Objective-C SJ/LJ exceptions in the frontend,
and I think it's largely agreed that that was a mistake, mostly because it
leads to totally wrong and unoptimizable CFGs.

John.