head 1.1;
branch 1.1.1;
access;
symbols
netbsd-11-0-RC4:1.1.1.7
netbsd-11-0-RC3:1.1.1.7
netbsd-11-0-RC2:1.1.1.7
netbsd-11-0-RC1:1.1.1.7
perseant-exfatfs-base-20250801:1.1.1.7
netbsd-11:1.1.1.7.0.10
netbsd-11-base:1.1.1.7
netbsd-10-1-RELEASE:1.1.1.7
perseant-exfatfs-base-20240630:1.1.1.7
perseant-exfatfs:1.1.1.7.0.8
perseant-exfatfs-base:1.1.1.7
netbsd-8-3-RELEASE:1.1.1.6
netbsd-9-4-RELEASE:1.1.1.6
netbsd-10-0-RELEASE:1.1.1.7
netbsd-10-0-RC6:1.1.1.7
netbsd-10-0-RC5:1.1.1.7
netbsd-10-0-RC4:1.1.1.7
netbsd-10-0-RC3:1.1.1.7
netbsd-10-0-RC2:1.1.1.7
netbsd-10-0-RC1:1.1.1.7
netbsd-10:1.1.1.7.0.6
netbsd-10-base:1.1.1.7
netbsd-9-3-RELEASE:1.1.1.6
cjep_sun2x:1.1.1.7.0.4
cjep_sun2x-base:1.1.1.7
cjep_staticlib_x-base1:1.1.1.7
netbsd-9-2-RELEASE:1.1.1.6
cjep_staticlib_x:1.1.1.7.0.2
cjep_staticlib_x-base:1.1.1.7
netbsd-9-1-RELEASE:1.1.1.6
phil-wifi-20200421:1.1.1.7
phil-wifi-20200411:1.1.1.7
phil-wifi-20200406:1.1.1.7
netbsd-8-2-RELEASE:1.1.1.6
netbsd-9-0-RELEASE:1.1.1.6
netbsd-9-0-RC2:1.1.1.6
netbsd-9-0-RC1:1.1.1.6
netbsd-9:1.1.1.6.0.16
netbsd-9-base:1.1.1.6
phil-wifi-20190609:1.1.1.6
netbsd-8-1-RELEASE:1.1.1.6
netbsd-8-1-RC1:1.1.1.6
pgoyette-compat-merge-20190127:1.1.1.6
pgoyette-compat-20190127:1.1.1.6
pgoyette-compat-20190118:1.1.1.6
pgoyette-compat-1226:1.1.1.6
pgoyette-compat-1126:1.1.1.6
pgoyette-compat-1020:1.1.1.6
pgoyette-compat-0930:1.1.1.6
pgoyette-compat-0906:1.1.1.6
netbsd-7-2-RELEASE:1.1.1.3.2.1
pgoyette-compat-0728:1.1.1.6
clang-337282:1.1.1.6
netbsd-8-0-RELEASE:1.1.1.6
phil-wifi:1.1.1.6.0.14
phil-wifi-base:1.1.1.6
pgoyette-compat-0625:1.1.1.6
netbsd-8-0-RC2:1.1.1.6
pgoyette-compat-0521:1.1.1.6
pgoyette-compat-0502:1.1.1.6
pgoyette-compat-0422:1.1.1.6
netbsd-8-0-RC1:1.1.1.6
pgoyette-compat-0415:1.1.1.6
pgoyette-compat-0407:1.1.1.6
pgoyette-compat-0330:1.1.1.6
pgoyette-compat-0322:1.1.1.6
pgoyette-compat-0315:1.1.1.6
netbsd-7-1-2-RELEASE:1.1.1.3.2.1
pgoyette-compat:1.1.1.6.0.12
pgoyette-compat-base:1.1.1.6
netbsd-7-1-1-RELEASE:1.1.1.3.2.1
clang-319952:1.1.1.6
matt-nb8-mediatek:1.1.1.6.0.10
matt-nb8-mediatek-base:1.1.1.6
clang-309604:1.1.1.6
perseant-stdc-iso10646:1.1.1.6.0.8
perseant-stdc-iso10646-base:1.1.1.6
netbsd-8:1.1.1.6.0.6
netbsd-8-base:1.1.1.6
prg-localcount2-base3:1.1.1.6
prg-localcount2-base2:1.1.1.6
prg-localcount2-base1:1.1.1.6
prg-localcount2:1.1.1.6.0.4
prg-localcount2-base:1.1.1.6
pgoyette-localcount-20170426:1.1.1.6
bouyer-socketcan-base1:1.1.1.6
pgoyette-localcount-20170320:1.1.1.6
netbsd-7-1:1.1.1.3.2.1.0.6
netbsd-7-1-RELEASE:1.1.1.3.2.1
netbsd-7-1-RC2:1.1.1.3.2.1
clang-294123:1.1.1.6
netbsd-7-nhusb-base-20170116:1.1.1.3.2.1
bouyer-socketcan:1.1.1.6.0.2
bouyer-socketcan-base:1.1.1.6
clang-291444:1.1.1.6
pgoyette-localcount-20170107:1.1.1.5
netbsd-7-1-RC1:1.1.1.3.2.1
pgoyette-localcount-20161104:1.1.1.5
netbsd-7-0-2-RELEASE:1.1.1.3.2.1
localcount-20160914:1.1.1.5
netbsd-7-nhusb:1.1.1.3.2.1.0.4
netbsd-7-nhusb-base:1.1.1.3.2.1
clang-280599:1.1.1.5
pgoyette-localcount-20160806:1.1.1.5
pgoyette-localcount-20160726:1.1.1.5
pgoyette-localcount:1.1.1.5.0.2
pgoyette-localcount-base:1.1.1.5
netbsd-7-0-1-RELEASE:1.1.1.3.2.1
clang-261930:1.1.1.5
netbsd-7-0:1.1.1.3.2.1.0.2
netbsd-7-0-RELEASE:1.1.1.3.2.1
netbsd-7-0-RC3:1.1.1.3.2.1
netbsd-7-0-RC2:1.1.1.3.2.1
netbsd-7-0-RC1:1.1.1.3.2.1
clang-237755:1.1.1.4
clang-232565:1.1.1.4
clang-227398:1.1.1.4
tls-maxphys-base:1.1.1.3
tls-maxphys:1.1.1.3.0.4
netbsd-7:1.1.1.3.0.2
netbsd-7-base:1.1.1.3
clang-215315:1.1.1.3
clang-209886:1.1.1.2
yamt-pagecache:1.1.1.1.0.4
yamt-pagecache-base9:1.1.1.1
tls-earlyentropy:1.1.1.1.0.2
tls-earlyentropy-base:1.1.1.2
riastradh-xf86-video-intel-2-7-1-pre-2-21-15:1.1.1.1
riastradh-drm2-base3:1.1.1.1
clang-202566:1.1.1.1
LLVM:1.1.1;
locks; strict;
comment @# @;
1.1
date 2014.03.04.19.53.12; author joerg; state Exp;
branches
1.1.1.1;
next ;
commitid 29z1hJonZISIXprx;
1.1.1.1
date 2014.03.04.19.53.12; author joerg; state Exp;
branches
1.1.1.1.2.1
1.1.1.1.4.1;
next 1.1.1.2;
commitid 29z1hJonZISIXprx;
1.1.1.2
date 2014.05.30.18.14.37; author joerg; state Exp;
branches;
next 1.1.1.3;
commitid 8q0kdlBlCn09GACx;
1.1.1.3
date 2014.08.10.17.08.23; author joerg; state Exp;
branches
1.1.1.3.2.1
1.1.1.3.4.1;
next 1.1.1.4;
commitid N85tXAN6Ex9VZPLx;
1.1.1.4
date 2015.01.29.19.57.42; author joerg; state Exp;
branches;
next 1.1.1.5;
commitid mlISSizlPKvepX7y;
1.1.1.5
date 2016.02.27.22.10.53; author joerg; state Exp;
branches
1.1.1.5.2.1;
next 1.1.1.6;
commitid tIimz3oDlh1NpBWy;
1.1.1.6
date 2017.01.11.10.40.30; author joerg; state Exp;
branches
1.1.1.6.14.1;
next 1.1.1.7;
commitid CNnUNfII1jgNmxBz;
1.1.1.7
date 2019.11.13.22.19.10; author joerg; state dead;
branches;
next ;
commitid QD8YATxuNG34YJKB;
1.1.1.1.2.1
date 2014.08.10.07.08.03; author tls; state Exp;
branches;
next ;
commitid t01A1TLTYxkpGMLx;
1.1.1.1.4.1
date 2014.03.04.19.53.12; author yamt; state dead;
branches;
next 1.1.1.1.4.2;
commitid WSrDtL5nYAUyiyBx;
1.1.1.1.4.2
date 2014.05.22.16.18.19; author yamt; state Exp;
branches;
next ;
commitid WSrDtL5nYAUyiyBx;
1.1.1.3.2.1
date 2015.06.04.20.04.23; author snj; state Exp;
branches;
next ;
commitid yRnjq9fueSo6n9oy;
1.1.1.3.4.1
date 2014.08.10.17.08.23; author tls; state dead;
branches;
next 1.1.1.3.4.2;
commitid jTnpym9Qu0o4R1Nx;
1.1.1.3.4.2
date 2014.08.19.23.47.19; author tls; state Exp;
branches;
next ;
commitid jTnpym9Qu0o4R1Nx;
1.1.1.5.2.1
date 2017.03.20.06.52.30; author pgoyette; state Exp;
branches;
next ;
commitid jjw7cAwgyKq7RfKz;
1.1.1.6.14.1
date 2020.04.13.07.46.20; author martin; state dead;
branches;
next ;
commitid X01YhRUPVUDaec4C;
desc
@@
1.1
log
@Initial revision
@
text
@.. raw:: html
.. role:: none
.. role:: partial
.. role:: good
==================
MSVC compatibility
==================
When Clang compiles C++ code for Windows, it attempts to be compatible with
MSVC. There are multiple dimensions to compatibility.
First, Clang attempts to be ABI-compatible, meaning that Clang-compiled code
should be able to link against MSVC-compiled code successfully. However, C++
ABIs are particular large and complicated, and Clang's support for MSVC's C++
ABI is a work in progress. If you don't require MSVC ABI compatibility or don't
want to use Microsoft's C and C++ runtimes, the mingw32 toolchain might be a
better fit for your project.
Second, Clang implements many MSVC language extensions, such as
``__declspec(dllexport)`` and a handful of pragmas. These are typically
controlled by ``-fms-extensions``.
Finally, MSVC accepts some C++ code that Clang will typically diagnose as
invalid. When these constructs are present in widely included system headers,
Clang attempts to recover and continue compiling the user's program. Most
parsing and semantic compatibility tweaks are controlled by
``-fms-compatibility`` and ``-fdelayed-template-parsing``, and they are a work
in progress.
ABI features
============
The status of major ABI-impacting C++ features:
* Record layout: :good:`Mostly complete`. We've attacked this with a fuzzer,
and most of the remaining failures involve ``#pragma pack``,
``__declspec(align(N))``, or other pragmas.
* Class inheritance: :good:`Mostly complete`. This covers all of the standard
OO features you would expect: virtual method inheritance, multiple
inheritance, and virtual inheritance. Every so often we uncover a bug where
our tables are incompatible, but this is pretty well in hand.
* Name mangling: :good:`Ongoing`. Every new C++ feature generally needs its own
mangling. For example, member pointer template arguments have an interesting
and distinct mangling. Fortunately, incorrect manglings usually do not result
in runtime errors. Non-inline functions with incorrect manglings usually
result in link errors, which are relatively easy to diagnose. Incorrect
manglings for inline functions and templates result in multiple copies in the
final image. The C++ standard requires that those addresses be equal, but few
programs rely on this.
* Member pointers: :good:`Mostly complete`. Standard C++ member pointers are
fully implemented and should be ABI compatible. Both `#pragma
pointers_to_members`_ and the `/vm`_ flags are supported. However, MSVC
supports an extension to allow creating a `pointer to a member of a virtual
base class`_. Clang does not yet support this.
.. _#pragma pointers_to_members:
http://msdn.microsoft.com/en-us/library/83cch5a6.aspx
.. _/vm: http://msdn.microsoft.com/en-us/library/yad46a6z.aspx
.. _pointer to a member of a virtual base class: http://llvm.org/PR15713
* Debug info: :partial:`Minimal`. Clang emits CodeView line tables into the
object file, similar to what MSVC emits when given the ``/Z7`` flag.
Microsoft's link.exe will read this information and use it to create a PDB,
enabling stack traces in all modern Windows debuggers. Clang does not emit
any type info or description of variable layout.
* `RTTI`_: :none:`Unstarted`. See the bug for a discussion of what needs to
happen first.
.. _RTTI: http://llvm.org/PR18951
* Exceptions and SEH: :none:`Unstarted`. Clang can parse both constructs, but
does not know how to emit compatible handlers. This depends on RTTI.
* Thread-safe initialization of local statics: :none:`Unstarted`. We are ABI
compatible with MSVC 2012, which does not support thread-safe local statics.
MSVC 2013 changed the ABI to make initialization of local statics thread safe,
and we have not yet implemented this.
* Lambdas in ABI boundaries: :none:`Infeasible`. It is unlikely that we will
ever be fully ABI compatible with lambdas declared in inline functions due to
what appears to be a hash code in the name mangling. Lambdas that are not
externally visible should work fine.
Template instantiation and name lookup
======================================
In addition to the usual `dependent name lookup FAQs `_, Clang is often unable
to parse certain invalid C++ constructs that MSVC allows. As of this writing,
Clang will reject code with missing ``typename`` annotations:
.. _dependent name lookup FAQs:
http://clang.llvm.org/compatibility.html#dep_lookup
.. code-block:: c++
struct X {
typedef int type;
};
template int f() {
// missing typename keyword
return sizeof(/*typename*/ T::type);
}
template void f();
Accepting code like this is ongoing work. Ultimately, it may be cleaner to
`implement a token-based template instantiation mode`_ than it is to add
compatibility hacks to the existing AST-based instantiation.
.. _implement a token-based template instantiation mode: http://llvm.org/PR18714
@
1.1.1.1
log
@Import Clang 3.5svn r202566.
@
text
@@
1.1.1.1.2.1
log
@Rebase.
@
text
@d31 1
a31 1
Third, MSVC accepts some C++ code that Clang will typically diagnose as
a37 3
Finally, there is :ref:`clang-cl`, a driver program for clang that attempts to
be compatible with MSVC's cl.exe.
d43 2
a44 2
* Record layout: :good:`Mostly complete`. We've tested this with a fuzzer, and
most of the remaining failures involve ``#pragma pack``,
d99 2
a100 2
In addition to the usual `dependent name lookup FAQs`_, Clang is often unable to
parse certain invalid C++ constructs that MSVC allows. As of this writing,
@
1.1.1.2
log
@Import Clang 3.5svn r209886.
@
text
@d31 1
a31 1
Third, MSVC accepts some C++ code that Clang will typically diagnose as
a37 3
Finally, there is :ref:`clang-cl`, a driver program for clang that attempts to
be compatible with MSVC's cl.exe.
d43 2
a44 2
* Record layout: :good:`Mostly complete`. We've tested this with a fuzzer, and
most of the remaining failures involve ``#pragma pack``,
d99 2
a100 2
In addition to the usual `dependent name lookup FAQs`_, Clang is often unable to
parse certain invalid C++ constructs that MSVC allows. As of this writing,
@
1.1.1.3
log
@Import clang 3.6svn r215315.
@
text
@d22 1
a22 1
ABIs are particularly large and complicated, and Clang's support for MSVC's C++
d46 3
a48 2
* Record layout: :good:`Complete`. We've tested this with a fuzzer and have
fixed all known bugs.
d53 1
a53 2
our tables are incompatible, but this is pretty well in hand. This feature
has also been fuzz tested.
d81 4
a84 2
* RTTI: :good:`Complete`. Generation of RTTI data structures has been
finished, along with support for the ``/GR`` flag.
d87 1
a87 1
does not know how to emit compatible handlers.
d90 2
a91 2
compatible with MSVC 2013, which does not support thread-safe local statics.
MSVC "14" changed the ABI to make initialization of local statics thread safe,
d94 4
a97 4
* Lambdas: :good:`Mostly complete`. Clang is compatible with Microsoft's
implementation of lambdas except for providing overloads for conversion to
function pointer for different calling conventions. However, Microsoft's
extension is non-conforming.
d102 3
a104 23
MSVC allows many invalid constructs in class templates that Clang has
historically rejected. In order to parse widely distributed headers for
libraries such as the Active Template Library (ATL) and Windows Runtime Library
(WRL), some template rules have been relaxed or extended in Clang on Windows.
The first major semantic difference is that MSVC appears to defer all parsing
an analysis of inline method bodies in class templates until instantiation
time. By default on Windows, Clang attempts to follow suit. This behavior is
controlled by the ``-fdelayed-template-parsing`` flag. While Clang delays
parsing of method bodies, it still parses the bodies *before* template argument
substitution, which is not what MSVC does. The following compatibility tweaks
are necessary to parse the the template in those cases.
MSVC allows some name lookup into dependent base classes. Even on other
platforms, this has been a `frequently asked question`_ for Clang users. A
dependent base class is a base class that depends on the value of a template
parameter. Clang cannot see any of the names inside dependent bases while it
is parsing your template, so the user is sometimes required to use the
``typename`` keyword to assist the parser. On Windows, Clang attempts to
follow the normal lookup rules, but if lookup fails, it will assume that the
user intended to find the name in a dependent base. While parsing the
following program, Clang will recover as if the user had written the
commented-out code:
d106 1
a106 1
.. _frequently asked question:
d111 2
a112 5
template
struct Foo : T {
void f() {
/*typename*/ T::UnknownType x = /*this->*/unknownMember;
}
d114 9
d124 1
a124 6
After recovery, Clang warns the user that this code is non-standard and issues
a hint suggesting how to fix the problem.
As of this writing, Clang is able to compile a simple ATL hello world
application. There are still issues parsing WRL headers for modern Windows 8
apps, but they should be addressed soon.
@
1.1.1.3.2.1
log
@Update LLVM to 3.6.1, requested by joerg in ticket 824.
@
text
@d75 3
a77 4
* Debug info: :partial:`Minimal`. Clang emits both CodeView line tables
(similar to what MSVC emits when given the ``/Z7`` flag) and DWARF debug
information into the object file.
Microsoft's link.exe will transform the CodeView line tables into a PDB,
d79 1
a79 3
any CodeView-compatible type info or description of variable layout.
Binaries linked with either binutils' ld or LLVM's lld should be usable with
GDB however sophisticated C++ expressions are likely to fail.
d84 2
a85 3
* Exceptions and SEH: :partial:`Minimal`. Clang can parse both constructs, but
does not know how to emit compatible handlers. Clang cannot throw exceptions
but it can rethrow them.
@
1.1.1.4
log
@Import Clang 3.6RC1 r227398.
@
text
@d75 3
a77 4
* Debug info: :partial:`Minimal`. Clang emits both CodeView line tables
(similar to what MSVC emits when given the ``/Z7`` flag) and DWARF debug
information into the object file.
Microsoft's link.exe will transform the CodeView line tables into a PDB,
d79 1
a79 3
any CodeView-compatible type info or description of variable layout.
Binaries linked with either binutils' ld or LLVM's lld should be usable with
GDB however sophisticated C++ expressions are likely to fail.
d84 2
a85 3
* Exceptions and SEH: :partial:`Minimal`. Clang can parse both constructs, but
does not know how to emit compatible handlers. Clang cannot throw exceptions
but it can rethrow them.
@
1.1.1.5
log
@Import Clang 3.8.0rc3 r261930.
@
text
@d87 8
a94 17
* Exceptions and SEH: :partial:`Partial`.
C++ exceptions (``try`` / ``catch`` / ``throw``) and
structured exceptions (``__try`` / ``__except`` / ``__finally``) mostly
work on x64. 32-bit exception handling support is being worked on. LLVM does
not model asynchronous exceptions, so it is currently impossible to catch an
asynchronous exception generated in the same frame as the catching ``__try``.
C++ exception specifications are ignored, but this is `consistent with Visual
C++`_.
.. _consistent with Visual C++:
https://msdn.microsoft.com/en-us/library/wfa0edys.aspx
* Thread-safe initialization of local statics: :good:`Complete`. MSVC 2015
added support for thread-safe initialization of such variables by taking an
ABI break.
We are ABI compatible with both the MSVC 2013 and 2015 ABI for static local
variables.
d115 1
a115 1
are necessary to parse the template in those cases.
@
1.1.1.5.2.1
log
@Sync with HEAD
@
text
@d75 8
a82 5
* Debug info: :good:`Mostly complete`. Clang emits relatively complete CodeView
debug information if ``/Z7`` or ``/Zi`` is passed. Microsoft's link.exe will
transform the CodeView debug information into a PDB that works in Windows
debuggers and other tools that consume PDB files like ETW. Work to teach lld
about CodeView and PDBs is ongoing.
d87 6
a92 4
* C++ Exceptions: :good:`Mostly complete`. Support for
C++ exceptions (``try`` / ``catch`` / ``throw``) have been implemented for
x86 and x64. Our implementation has been well tested but we still get the
odd bug report now and again.
a98 7
* Asynchronous Exceptions (SEH): :partial:`Partial`.
Structured exceptions (``__try`` / ``__except`` / ``__finally``) mostly
work on x86 and x64.
LLVM does not model asynchronous exceptions, so it is currently impossible to
catch an asynchronous exception generated in the same frame as the catching
``__try``.
@
1.1.1.6
log
@Import Clang pre-4.0.0 r291444.
@
text
@d75 8
a82 5
* Debug info: :good:`Mostly complete`. Clang emits relatively complete CodeView
debug information if ``/Z7`` or ``/Zi`` is passed. Microsoft's link.exe will
transform the CodeView debug information into a PDB that works in Windows
debuggers and other tools that consume PDB files like ETW. Work to teach lld
about CodeView and PDBs is ongoing.
d87 6
a92 4
* C++ Exceptions: :good:`Mostly complete`. Support for
C++ exceptions (``try`` / ``catch`` / ``throw``) have been implemented for
x86 and x64. Our implementation has been well tested but we still get the
odd bug report now and again.
a98 7
* Asynchronous Exceptions (SEH): :partial:`Partial`.
Structured exceptions (``__try`` / ``__except`` / ``__finally``) mostly
work on x86 and x64.
LLVM does not model asynchronous exceptions, so it is currently impossible to
catch an asynchronous exception generated in the same frame as the catching
``__try``.
@
1.1.1.6.14.1
log
@Mostly merge changes from HEAD upto 20200411
@
text
@@
1.1.1.7
log
@Mark old LLVM instance as dead.
@
text
@@
1.1.1.3.4.1
log
@file MSVCCompatibility.rst was added on branch tls-maxphys on 2014-08-19 23:47:19 +0000
@
text
@d1 141
@
1.1.1.3.4.2
log
@Rebase to HEAD as of a few days ago.
@
text
@a0 141
.. raw:: html
.. role:: none
.. role:: partial
.. role:: good
==================
MSVC compatibility
==================
When Clang compiles C++ code for Windows, it attempts to be compatible with
MSVC. There are multiple dimensions to compatibility.
First, Clang attempts to be ABI-compatible, meaning that Clang-compiled code
should be able to link against MSVC-compiled code successfully. However, C++
ABIs are particularly large and complicated, and Clang's support for MSVC's C++
ABI is a work in progress. If you don't require MSVC ABI compatibility or don't
want to use Microsoft's C and C++ runtimes, the mingw32 toolchain might be a
better fit for your project.
Second, Clang implements many MSVC language extensions, such as
``__declspec(dllexport)`` and a handful of pragmas. These are typically
controlled by ``-fms-extensions``.
Third, MSVC accepts some C++ code that Clang will typically diagnose as
invalid. When these constructs are present in widely included system headers,
Clang attempts to recover and continue compiling the user's program. Most
parsing and semantic compatibility tweaks are controlled by
``-fms-compatibility`` and ``-fdelayed-template-parsing``, and they are a work
in progress.
Finally, there is :ref:`clang-cl`, a driver program for clang that attempts to
be compatible with MSVC's cl.exe.
ABI features
============
The status of major ABI-impacting C++ features:
* Record layout: :good:`Complete`. We've tested this with a fuzzer and have
fixed all known bugs.
* Class inheritance: :good:`Mostly complete`. This covers all of the standard
OO features you would expect: virtual method inheritance, multiple
inheritance, and virtual inheritance. Every so often we uncover a bug where
our tables are incompatible, but this is pretty well in hand. This feature
has also been fuzz tested.
* Name mangling: :good:`Ongoing`. Every new C++ feature generally needs its own
mangling. For example, member pointer template arguments have an interesting
and distinct mangling. Fortunately, incorrect manglings usually do not result
in runtime errors. Non-inline functions with incorrect manglings usually
result in link errors, which are relatively easy to diagnose. Incorrect
manglings for inline functions and templates result in multiple copies in the
final image. The C++ standard requires that those addresses be equal, but few
programs rely on this.
* Member pointers: :good:`Mostly complete`. Standard C++ member pointers are
fully implemented and should be ABI compatible. Both `#pragma
pointers_to_members`_ and the `/vm`_ flags are supported. However, MSVC
supports an extension to allow creating a `pointer to a member of a virtual
base class`_. Clang does not yet support this.
.. _#pragma pointers_to_members:
http://msdn.microsoft.com/en-us/library/83cch5a6.aspx
.. _/vm: http://msdn.microsoft.com/en-us/library/yad46a6z.aspx
.. _pointer to a member of a virtual base class: http://llvm.org/PR15713
* Debug info: :partial:`Minimal`. Clang emits CodeView line tables into the
object file, similar to what MSVC emits when given the ``/Z7`` flag.
Microsoft's link.exe will read this information and use it to create a PDB,
enabling stack traces in all modern Windows debuggers. Clang does not emit
any type info or description of variable layout.
* RTTI: :good:`Complete`. Generation of RTTI data structures has been
finished, along with support for the ``/GR`` flag.
* Exceptions and SEH: :none:`Unstarted`. Clang can parse both constructs, but
does not know how to emit compatible handlers.
* Thread-safe initialization of local statics: :none:`Unstarted`. We are ABI
compatible with MSVC 2013, which does not support thread-safe local statics.
MSVC "14" changed the ABI to make initialization of local statics thread safe,
and we have not yet implemented this.
* Lambdas: :good:`Mostly complete`. Clang is compatible with Microsoft's
implementation of lambdas except for providing overloads for conversion to
function pointer for different calling conventions. However, Microsoft's
extension is non-conforming.
Template instantiation and name lookup
======================================
MSVC allows many invalid constructs in class templates that Clang has
historically rejected. In order to parse widely distributed headers for
libraries such as the Active Template Library (ATL) and Windows Runtime Library
(WRL), some template rules have been relaxed or extended in Clang on Windows.
The first major semantic difference is that MSVC appears to defer all parsing
an analysis of inline method bodies in class templates until instantiation
time. By default on Windows, Clang attempts to follow suit. This behavior is
controlled by the ``-fdelayed-template-parsing`` flag. While Clang delays
parsing of method bodies, it still parses the bodies *before* template argument
substitution, which is not what MSVC does. The following compatibility tweaks
are necessary to parse the the template in those cases.
MSVC allows some name lookup into dependent base classes. Even on other
platforms, this has been a `frequently asked question`_ for Clang users. A
dependent base class is a base class that depends on the value of a template
parameter. Clang cannot see any of the names inside dependent bases while it
is parsing your template, so the user is sometimes required to use the
``typename`` keyword to assist the parser. On Windows, Clang attempts to
follow the normal lookup rules, but if lookup fails, it will assume that the
user intended to find the name in a dependent base. While parsing the
following program, Clang will recover as if the user had written the
commented-out code:
.. _frequently asked question:
http://clang.llvm.org/compatibility.html#dep_lookup
.. code-block:: c++
template
struct Foo : T {
void f() {
/*typename*/ T::UnknownType x = /*this->*/unknownMember;
}
};
After recovery, Clang warns the user that this code is non-standard and issues
a hint suggesting how to fix the problem.
As of this writing, Clang is able to compile a simple ATL hello world
application. There are still issues parsing WRL headers for modern Windows 8
apps, but they should be addressed soon.
@
1.1.1.1.4.1
log
@file MSVCCompatibility.rst was added on branch yamt-pagecache on 2014-05-22 16:18:19 +0000
@
text
@d1 121
@
1.1.1.1.4.2
log
@sync with head.
for a reference, the tree before this commit was tagged
as yamt-pagecache-tag8.
this commit was splitted into small chunks to avoid
a limitation of cvs. ("Protocol error: too many arguments")
@
text
@a0 121
.. raw:: html
.. role:: none
.. role:: partial
.. role:: good
==================
MSVC compatibility
==================
When Clang compiles C++ code for Windows, it attempts to be compatible with
MSVC. There are multiple dimensions to compatibility.
First, Clang attempts to be ABI-compatible, meaning that Clang-compiled code
should be able to link against MSVC-compiled code successfully. However, C++
ABIs are particular large and complicated, and Clang's support for MSVC's C++
ABI is a work in progress. If you don't require MSVC ABI compatibility or don't
want to use Microsoft's C and C++ runtimes, the mingw32 toolchain might be a
better fit for your project.
Second, Clang implements many MSVC language extensions, such as
``__declspec(dllexport)`` and a handful of pragmas. These are typically
controlled by ``-fms-extensions``.
Finally, MSVC accepts some C++ code that Clang will typically diagnose as
invalid. When these constructs are present in widely included system headers,
Clang attempts to recover and continue compiling the user's program. Most
parsing and semantic compatibility tweaks are controlled by
``-fms-compatibility`` and ``-fdelayed-template-parsing``, and they are a work
in progress.
ABI features
============
The status of major ABI-impacting C++ features:
* Record layout: :good:`Mostly complete`. We've attacked this with a fuzzer,
and most of the remaining failures involve ``#pragma pack``,
``__declspec(align(N))``, or other pragmas.
* Class inheritance: :good:`Mostly complete`. This covers all of the standard
OO features you would expect: virtual method inheritance, multiple
inheritance, and virtual inheritance. Every so often we uncover a bug where
our tables are incompatible, but this is pretty well in hand.
* Name mangling: :good:`Ongoing`. Every new C++ feature generally needs its own
mangling. For example, member pointer template arguments have an interesting
and distinct mangling. Fortunately, incorrect manglings usually do not result
in runtime errors. Non-inline functions with incorrect manglings usually
result in link errors, which are relatively easy to diagnose. Incorrect
manglings for inline functions and templates result in multiple copies in the
final image. The C++ standard requires that those addresses be equal, but few
programs rely on this.
* Member pointers: :good:`Mostly complete`. Standard C++ member pointers are
fully implemented and should be ABI compatible. Both `#pragma
pointers_to_members`_ and the `/vm`_ flags are supported. However, MSVC
supports an extension to allow creating a `pointer to a member of a virtual
base class`_. Clang does not yet support this.
.. _#pragma pointers_to_members:
http://msdn.microsoft.com/en-us/library/83cch5a6.aspx
.. _/vm: http://msdn.microsoft.com/en-us/library/yad46a6z.aspx
.. _pointer to a member of a virtual base class: http://llvm.org/PR15713
* Debug info: :partial:`Minimal`. Clang emits CodeView line tables into the
object file, similar to what MSVC emits when given the ``/Z7`` flag.
Microsoft's link.exe will read this information and use it to create a PDB,
enabling stack traces in all modern Windows debuggers. Clang does not emit
any type info or description of variable layout.
* `RTTI`_: :none:`Unstarted`. See the bug for a discussion of what needs to
happen first.
.. _RTTI: http://llvm.org/PR18951
* Exceptions and SEH: :none:`Unstarted`. Clang can parse both constructs, but
does not know how to emit compatible handlers. This depends on RTTI.
* Thread-safe initialization of local statics: :none:`Unstarted`. We are ABI
compatible with MSVC 2012, which does not support thread-safe local statics.
MSVC 2013 changed the ABI to make initialization of local statics thread safe,
and we have not yet implemented this.
* Lambdas in ABI boundaries: :none:`Infeasible`. It is unlikely that we will
ever be fully ABI compatible with lambdas declared in inline functions due to
what appears to be a hash code in the name mangling. Lambdas that are not
externally visible should work fine.
Template instantiation and name lookup
======================================
In addition to the usual `dependent name lookup FAQs `_, Clang is often unable
to parse certain invalid C++ constructs that MSVC allows. As of this writing,
Clang will reject code with missing ``typename`` annotations:
.. _dependent name lookup FAQs:
http://clang.llvm.org/compatibility.html#dep_lookup
.. code-block:: c++
struct X {
typedef int type;
};
template int f() {
// missing typename keyword
return sizeof(/*typename*/ T::type);
}
template void f();
Accepting code like this is ongoing work. Ultimately, it may be cleaner to
`implement a token-based template instantiation mode`_ than it is to add
compatibility hacks to the existing AST-based instantiation.
.. _implement a token-based template instantiation mode: http://llvm.org/PR18714
@