[PATCH] D28383: build: add a heuristic to determine the C++ ABI

[Saleem Abdulrasool via Phabricator via cfe-commits]

compnerd abandoned this revision.
compnerd added a comment.

We have a temporary workaround while a proper macro is considered by SD-6.


Repository:
  rL LLVM

https://reviews.llvm.org/D28383



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D28383: build: add a heuristic to determine the C++ ABI

[Eric Fiselier via Phabricator via cfe-commits]

EricWF added a comment.

In https://reviews.llvm.org/D28383#637672, @compnerd wrote:

> @rnk happy to add such a macro.  Would `__cpp_abi_itanium` and 
> `__cpp_abi_microsoft` be palatable?


I would love these macros. I would prefer if the stock `__config` worked for 
all but the rarest of configurations.


Repository:
  rL LLVM

https://reviews.llvm.org/D28383



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D28383: build: add a heuristic to determine the C++ ABI

[Saleem Abdulrasool via Phabricator via cfe-commits]

compnerd added a comment.

@rnk happy to add such a macro.  Would `__cpp_abi_itanium` and 
`__cpp_abi_microsoft` be palatable?

This actually does get encoded into `__config` albeit in a round-about way.  
The `__config_site` gets concatenated with `__config` into `__generated_config` 
which is installed as `__config`.


Repository:
  rL LLVM

https://reviews.llvm.org/D28383



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D28383: build: add a heuristic to determine the C++ ABI

[Reid Kleckner via Phabricator via cfe-commits]

rnk added a comment.

In https://reviews.llvm.org/D28383#637570, @majnemer wrote:

> Why isn't this equivalent to `_MSC_VER` ?


It might also be nice for clang to define some macro to indicate which C++ ABI 
is in use.

All that said, I think it makes sense to encode this in libc++ 
include/__config_site because you don't want people to build libc++ for the MS 
ABI and then try to use it with a mingw triple. It'd be nice if we could 
diagnose that at compile time instead of link time.


Repository:
  rL LLVM

https://reviews.llvm.org/D28383



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D28383: build: add a heuristic to determine the C++ ABI

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added a comment.

In https://reviews.llvm.org/D28383#637570, @majnemer wrote:

> Why isn't this equivalent to `_MSC_VER` ?


You can have scenarios where you're targeting the Itanium ABI but still have 
`_MSC_VER` defined, e.g.

  % clang -target i686-windows-itanium -fmsc-version=1900 -E -dM - < /dev/null 
| grep _MSC_VER
  #define _MSC_VER 1900


Repository:
  rL LLVM

https://reviews.llvm.org/D28383



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D28383: build: add a heuristic to determine the C++ ABI

[David Majnemer via Phabricator via cfe-commits]

majnemer added a comment.

Why isn't this equivalent to `_MSC_VER` ?


Repository:
  rL LLVM

https://reviews.llvm.org/D28383



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D28383: build: add a heuristic to determine the C++ ABI

[Saleem Abdulrasool via Phabricator via cfe-commits]

compnerd created this revision.
compnerd added reviewers: EricWF, mclow.lists, smeenai, kastiglione.
compnerd added subscribers: cfe-commits, rnk.
compnerd set the repository for this revision to rL LLVM.
Herald added a subscriber: mgorny.

We need to have a more principled method to detect the C++ ABI we are
targeting.  Add a heuristic to determine that and pass it to the build.


Repository:
  rL LLVM

https://reviews.llvm.org/D28383

Files:
  CMakeLists.txt
  include/__config
  include/__config_site.in


Index: include/__config_site.in
===
--- include/__config_site.in
+++ include/__config_site.in
@@ -22,5 +22,6 @@
 #cmakedefine _LIBCPP_HAS_THREAD_API_PTHREAD
 #cmakedefine _LIBCPP_HAS_THREAD_API_EXTERNAL
 #cmakedefine _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS
+#cmakedefine _LIBCPP_USES_MS_ABI
 
 #endif // _LIBCPP_CONFIG_SITE
Index: include/__config
===
--- include/__config
+++ include/__config
@@ -33,6 +33,12 @@
 #define _LIBCPP_ABI_VERSION 1
 #endif
 
+#if defined(_LIBCPP_USES_MS_ABI)
+#define _LIBCPP_ABI_MS
+#else
+#define _LIBCPP_ABI_IA
+#endif
+
 #if defined(_LIBCPP_ABI_UNSTABLE) || _LIBCPP_ABI_VERSION >= 2
 // Change short string representation so that string data starts at offset 0,
 // improving its alignment in some cases.
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -522,6 +522,17 @@
 config_define_if(LIBCXX_HAS_EXTERNAL_THREAD_API 
_LIBCPP_HAS_THREAD_API_EXTERNAL)
 config_define_if(LIBCXX_HAS_MUSL_LIBC _LIBCPP_HAS_MUSL_LIBC)
 
+# Indicate the ABI that we are targeting.  If the c++abi library is none and we
+# are building for windows, assume that we want the Microsoft C++ ABI.  Note
+# that MinGW uses the itanium ABI and still reports as WIN32 under CMake.  If 
we
+# are targeting the itanium ABI, then we must have one of the itanium ABI
+# support libraries (libc++abi, libsupc++, or libcxxrt).  Windows itanium and
+# MinGW both will use one of those to provide the support routines which
+# differentiates it from MS ABI.
+if(WIN32 AND NOT MINGW AND "${LIBCXX_CXX_ABI}" STREQUAL "none")
+  config_define_if(TRUE _LIBCPP_USES_MS_ABI)
+endif()
+
 # By default libc++ on Windows expects to use a shared library, which requires
 # the headers to use DLL import/export semantics. However when building a
 # static library only we modify the headers to disable DLL import/export.


Index: include/__config_site.in
===
--- include/__config_site.in
+++ include/__config_site.in
@@ -22,5 +22,6 @@
 #cmakedefine _LIBCPP_HAS_THREAD_API_PTHREAD
 #cmakedefine _LIBCPP_HAS_THREAD_API_EXTERNAL
 #cmakedefine _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS
+#cmakedefine _LIBCPP_USES_MS_ABI
 
 #endif // _LIBCPP_CONFIG_SITE
Index: include/__config
===
--- include/__config
+++ include/__config
@@ -33,6 +33,12 @@
 #define _LIBCPP_ABI_VERSION 1
 #endif
 
+#if defined(_LIBCPP_USES_MS_ABI)
+#define _LIBCPP_ABI_MS
+#else
+#define _LIBCPP_ABI_IA
+#endif
+
 #if defined(_LIBCPP_ABI_UNSTABLE) || _LIBCPP_ABI_VERSION >= 2
 // Change short string representation so that string data starts at offset 0,
 // improving its alignment in some cases.
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -522,6 +522,17 @@
 config_define_if(LIBCXX_HAS_EXTERNAL_THREAD_API _LIBCPP_HAS_THREAD_API_EXTERNAL)
 config_define_if(LIBCXX_HAS_MUSL_LIBC _LIBCPP_HAS_MUSL_LIBC)
 
+# Indicate the ABI that we are targeting.  If the c++abi library is none and we
+# are building for windows, assume that we want the Microsoft C++ ABI.  Note
+# that MinGW uses the itanium ABI and still reports as WIN32 under CMake.  If we
+# are targeting the itanium ABI, then we must have one of the itanium ABI
+# support libraries (libc++abi, libsupc++, or libcxxrt).  Windows itanium and
+# MinGW both will use one of those to provide the support routines which
+# differentiates it from MS ABI.
+if(WIN32 AND NOT MINGW AND "${LIBCXX_CXX_ABI}" STREQUAL "none")
+  config_define_if(TRUE _LIBCPP_USES_MS_ABI)
+endif()
+
 # By default libc++ on Windows expects to use a shared library, which requires
 # the headers to use DLL import/export semantics. However when building a
 # static library only we modify the headers to disable DLL import/export.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits