Re: r340483 - Revert "[ASTImporter] Add test for ObjCAtTryStmt/ObjCAtCatchStmt/ObjCAtThrowStmt"

[Shoaib Meenai via cfe-commits]

Might be because the constructed AST for a @finally on Windows will contain a 
CapturedStmt: https://reviews.llvm.org/D47564. You probably want to explicitly 
specify a non windows-msvc triple in the test.

From: cfe-commits  on behalf of Raphael 
Isemann via cfe-commits 
Reply-To: Raphael Isemann 
Date: Wednesday, August 22, 2018 at 4:51 PM
To: "cfe-commits@lists.llvm.org" 
Subject: r340483 - Revert "[ASTImporter] Add test for 
ObjCAtTryStmt/ObjCAtCatchStmt/ObjCAtThrowStmt"

Author: teemperor
Date: Wed Aug 22 16:50:30 2018
New Revision: 340483

URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D340483-26view-3Drev&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=SoW99711ISLe9RQ23xIpwyvcxXTd-Rxawo9VIXlpjuo&s=nc9gqViWXTB0N3ed5Zzdk_7AzYUFDgZpoxqOgBLI4nU&e=
Log:
Revert "[ASTImporter] Add test for 
ObjCAtTryStmt/ObjCAtCatchStmt/ObjCAtThrowStmt"

This test breaks llvm-clang-x86_64-expensive-checks-win.

Removed:
cfe/trunk/test/Import/objc-try-catch/Inputs/F.m
cfe/trunk/test/Import/objc-try-catch/test.m

Removed: cfe/trunk/test/Import/objc-try-catch/Inputs/F.m
URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_cfe_trunk_test_Import_objc-2Dtry-2Dcatch_Inputs_F.m-3Frev-3D340482-26view-3Dauto&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=SoW99711ISLe9RQ23xIpwyvcxXTd-Rxawo9VIXlpjuo&s=kFKOp3N2QmGe252ijaqC1sM6nD0j9xQCdVvuBjevcko&e=
==
--- cfe/trunk/test/Import/objc-try-catch/Inputs/F.m (original)
+++ cfe/trunk/test/Import/objc-try-catch/Inputs/F.m (removed)
@@ -1,28 +0,0 @@
-@interface Exception
-@end
-@interface OtherException
-@end
-
-void f() {
-  @try {
-Exception *e;
-@throw e;
-  }
-  @catch (Exception *varname) {
-  }
-  @finally {
-  }
-
-  @try {
-  }
-  @catch (Exception *varname1) {
-@throw;
-  }
-  @catch (OtherException *varname2) {
-  }
-
-  @try {
-  }
-  @finally {
-  }
-}

Removed: cfe/trunk/test/Import/objc-try-catch/test.m
URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_cfe_trunk_test_Import_objc-2Dtry-2Dcatch_test.m-3Frev-3D340482-26view-3Dauto&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=SoW99711ISLe9RQ23xIpwyvcxXTd-Rxawo9VIXlpjuo&s=q6vS8avd9ajINxEtZW7uL9FWfjCwl4TGy4e6NfUNkZI&e=
==
--- cfe/trunk/test/Import/objc-try-catch/test.m (original)
+++ cfe/trunk/test/Import/objc-try-catch/test.m (removed)
@@ -1,40 +0,0 @@
-// RUN: clang-import-test -x objective-c++ -Xcc -fobjc-exceptions -dump-ast 
-import %S/Inputs/F.m -expression %s | FileCheck %s
-
-// CHECK: ObjCAtTryStmt
-// CHECK-NEXT: CompoundStmt
-// CHECK-NEXT: DeclStmt
-// CHECK-NEXT: VarDecl
-// CHECK-NEXT: ObjCAtThrowStmt
-// CHECK-NEXT: ImplicitCastExpr
-// CHECK-NEXT: DeclRefExpr
-// CHECK-NEXT: ObjCAtCatchStmt
-// CHECK-NEXT: VarDecl
-// CHECK-SAME: varname
-// CHECK-SAME: 'Exception *'
-// CHECK-NEXT: CompoundStmt
-// CHECK-NEXT: ObjCAtFinallyStmt
-// CHECK-NEXT: CompoundStmt
-
-// CHECK-NEXT: ObjCAtTryStmt
-// CHECK-NEXT: CompoundStmt
-// CHECK-NEXT: ObjCAtCatchStmt
-// CHECK-NEXT: VarDecl
-// CHECK-SAME: varname1
-// CHECK-SAME: 'Exception *'
-// CHECK-NEXT: CompoundStmt
-// CHECK-NEXT: ObjCAtThrowStmt
-// CHECK-NEXT: <>
-// CHECK-NEXT: ObjCAtCatchStmt
-// CHECK-NEXT: VarDecl
-// CHECK-SAME: varname2
-// CHECK-SAME: 'OtherException *'
-// CHECK-NEXT: CompoundStmt
-
-// CHECK-NEXT: ObjCAtTryStmt
-// CHECK-NEXT: CompoundStmt
-// CHECK-NEXT: ObjCAtFinallyStmt
-// CHECK-NEXT: CompoundStmt
-
-void expr() {
-  f();
-}


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_cfe-2Dcommits&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=SoW99711ISLe9RQ23xIpwyvcxXTd-Rxawo9VIXlpjuo&s=7OwU_LMC-xQGUKoTBrJZVj4QNfVYAIM5ZZDXF_RS9oc&e=

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

r332777 - [test] Fix run line to use correct triple

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Fri May 18 14:59:29 2018
New Revision: 332777

URL: http://llvm.org/viewvc/llvm-project?rev=332777&view=rev
Log:
[test] Fix run line to use correct triple

objc_begin_catch/objc_end_catch are specific to the Itanium ABI, so we
should be using an Itanium triple for this test.

Additionally, while I'm here, convert the run line to invoke the
compiler directly rather than going through the driver.

Modified:
cfe/trunk/test/CodeGenObjC/runtime-abi-match.m

Modified: cfe/trunk/test/CodeGenObjC/runtime-abi-match.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenObjC/runtime-abi-match.m?rev=332777&r1=332776&r2=332777&view=diff
==
--- cfe/trunk/test/CodeGenObjC/runtime-abi-match.m (original)
+++ cfe/trunk/test/CodeGenObjC/runtime-abi-match.m Fri May 18 14:59:29 2018
@@ -1,4 +1,4 @@
-// RUN: %clang -target armv7-windows -fobjc-runtime=ios -O1 -fexceptions -S 
-emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -triple thumbv7--windows-itanium -fobjc-runtime=ios -O1 
-fexceptions -fobjc-exceptions -emit-llvm %s -o - | FileCheck %s
 // REQUIRES: arm-registered-target
 
 void (*f)(id);


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

[libcxx] r314946 - [libc++] Add site config option for ABI macros

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Wed Oct  4 16:17:12 2017
New Revision: 314946

URL: http://llvm.org/viewvc/llvm-project?rev=314946&view=rev
Log:
[libc++] Add site config option for ABI macros

Some ABI macros affect headers, so it's nice to have a site config
option for them. Add a LIBCXX_ABI_DEFINES cmake macro to allow
specifying a list of ABI macros to define in the site config.

The primary design constraint (as discussed with Eric on IRC a while
back) was to not have to repeat the ABI macro names in cmake, which only
leaves a free-form cmake list as an option. A somewhat unfortunate
consequence is that we can't verify that the ABI macros being defined
actually exist, though we can at least perform some basic sanity
checking, since all the ABI macros begin with _LIBCPP_ABI_.

Differential Revision: https://reviews.llvm.org/D36719

Modified:
libcxx/trunk/CMakeLists.txt
libcxx/trunk/docs/BuildingLibcxx.rst
libcxx/trunk/include/__config_site.in
libcxx/trunk/utils/libcxx/test/config.py

Modified: libcxx/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.txt?rev=314946&r1=314945&r2=314946&view=diff
==
--- libcxx/trunk/CMakeLists.txt (original)
+++ libcxx/trunk/CMakeLists.txt Wed Oct  4 16:17:12 2017
@@ -607,6 +607,19 @@ config_define_if(LIBCXX_HAS_EXTERNAL_THR
 config_define_if(LIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY 
_LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL)
 config_define_if(LIBCXX_HAS_MUSL_LIBC _LIBCPP_HAS_MUSL_LIBC)
 
+set(LIBCXX_ABI_DEFINES "" CACHE STRING "A semicolon separated list of ABI 
macros to define in the site config header")
+if (LIBCXX_ABI_DEFINES)
+  set(abi_defines)
+  foreach (abi_define ${LIBCXX_ABI_DEFINES})
+if (NOT abi_define MATCHES "^_LIBCPP_ABI_")
+  message(SEND_ERROR "Invalid ABI macro ${abi_define} in 
LIBCXX_ABI_DEFINES")
+endif()
+list(APPEND abi_defines "#define ${abi_define}")
+  endforeach()
+  string(REPLACE ";" "\n" abi_defines "${abi_defines}")
+  config_define(${abi_defines} _LIBCPP_ABI_DEFINES)
+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.

Modified: libcxx/trunk/docs/BuildingLibcxx.rst
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/docs/BuildingLibcxx.rst?rev=314946&r1=314945&r2=314946&view=diff
==
--- libcxx/trunk/docs/BuildingLibcxx.rst (original)
+++ libcxx/trunk/docs/BuildingLibcxx.rst Wed Oct  4 16:17:12 2017
@@ -347,6 +347,13 @@ The following options allow building lib
   Build the "unstable" ABI version of libc++. Includes all ABI changing 
features
   on top of the current stable version.
 
+.. option:: LIBCXX_ABI_DEFINES:STRING
+
+  **Default**: ``""``
+
+  A semicolon-separated list of ABI macros to persist in the site config 
header.
+  See ``include/__config`` for the list of ABI macros.
+
 .. _LLVM-specific variables:
 
 LLVM-specific options

Modified: libcxx/trunk/include/__config_site.in
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__config_site.in?rev=314946&r1=314945&r2=314946&view=diff
==
--- libcxx/trunk/include/__config_site.in (original)
+++ libcxx/trunk/include/__config_site.in Wed Oct  4 16:17:12 2017
@@ -24,4 +24,6 @@
 #cmakedefine _LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL
 #cmakedefine _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS
 
+@_LIBCPP_ABI_DEFINES@
+
 #endif // _LIBCPP_CONFIG_SITE

Modified: libcxx/trunk/utils/libcxx/test/config.py
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/utils/libcxx/test/config.py?rev=314946&r1=314945&r2=314946&view=diff
==
--- libcxx/trunk/utils/libcxx/test/config.py (original)
+++ libcxx/trunk/utils/libcxx/test/config.py Wed Oct  4 16:17:12 2017
@@ -668,7 +668,7 @@ class Configuration(object):
 self.config.available_features.add('libcpp-abi-version-v%s'
 % feature_macros[m])
 continue
-assert m.startswith('_LIBCPP_HAS_') or m == '_LIBCPP_ABI_UNSTABLE'
+assert m.startswith('_LIBCPP_HAS_') or m.startswith('_LIBCPP_ABI_')
 m = m.lower()[1:].replace('_', '-')
 self.config.available_features.add(m)
 return feature_macros


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

[libcxx] r314949 - [libc++] Allow users to explicitly specify ABI

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Wed Oct  4 16:44:38 2017
New Revision: 314949

URL: http://llvm.org/viewvc/llvm-project?rev=314949&view=rev
Log:
[libc++] Allow users to explicitly specify ABI

libc++'s current heuristic for detecting Itanium vs. Microsoft ABI falls
short in some cases. For example, it will detect windows-itanium targets
as using the Microsoft ABI, since they set `_MSC_VER` (for compatibility
with Microsoft headers). Leave the current heuristic in place by default
but also allow users to explicitly specify the ABI if need be.

Modified:
libcxx/trunk/CMakeLists.txt
libcxx/trunk/include/__config
libcxx/trunk/include/__config_site.in

Modified: libcxx/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.txt?rev=314949&r1=314948&r2=314949&view=diff
==
--- libcxx/trunk/CMakeLists.txt (original)
+++ libcxx/trunk/CMakeLists.txt Wed Oct  4 16:44:38 2017
@@ -99,6 +99,8 @@ cmake_dependent_option(LIBCXX_INSTALL_EX
 "LIBCXX_ENABLE_EXPERIMENTAL_LIBRARY;LIBCXX_INSTALL_LIBRARY" OFF)
 set(LIBCXX_ABI_VERSION 1 CACHE STRING "ABI version of libc++.")
 option(LIBCXX_ABI_UNSTABLE "Unstable ABI of libc++." OFF)
+option(LIBCXX_ABI_ITANIUM "Ignore auto-detection and force use of the Itanium 
ABI.")
+option(LIBCXX_ABI_MICROSOFT "Ignore auto-detection and force use of the 
Microsoft ABI.")
 option(LIBCXX_USE_COMPILER_RT "Use compiler-rt instead of libgcc" OFF)
 
 if (NOT LIBCXX_ENABLE_SHARED AND NOT LIBCXX_ENABLE_STATIC)
@@ -337,6 +339,10 @@ if (LIBCXX_HAS_MUSL_LIBC AND NOT LIBCXX_
   "when building for Musl with LIBCXX_HAS_MUSL_LIBC.")
 endif()
 
+if (LIBCXX_ABI_ITANIUM AND LIBCXX_ABI_MICROSOFT)
+  message(FATAL_ERROR "Only one of LIBCXX_ABI_ITANIUM and LIBCXX_ABI_MICROSOFT 
can be specified.")
+endif ()
+
 
#===
 # Configure System
 
#===
@@ -594,6 +600,8 @@ if (NOT LIBCXX_ABI_VERSION EQUAL "1")
   config_define(${LIBCXX_ABI_VERSION} _LIBCPP_ABI_VERSION)
 endif()
 config_define_if(LIBCXX_ABI_UNSTABLE _LIBCPP_ABI_UNSTABLE)
+config_define_if(LIBCXX_ABI_ITANIUM _LIBCPP_ABI_ITANIUM)
+config_define_if(LIBCXX_ABI_MICROSOFT _LIBCPP_ABI_MICROSOFT)
 
 config_define_if_not(LIBCXX_ENABLE_GLOBAL_FILESYSTEM_NAMESPACE 
_LIBCPP_HAS_NO_GLOBAL_FILESYSTEM_NAMESPACE)
 config_define_if_not(LIBCXX_ENABLE_STDIN _LIBCPP_HAS_NO_STDIN)

Modified: libcxx/trunk/include/__config
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__config?rev=314949&r1=314948&r2=314949&view=diff
==
--- libcxx/trunk/include/__config (original)
+++ libcxx/trunk/include/__config Wed Oct  4 16:44:38 2017
@@ -157,11 +157,15 @@
 
 // FIXME: ABI detection should be done via compiler builtin macros. This
 // is just a placeholder until Clang implements such macros. For now assume
-// that Windows compilers pretending to be MSVC++ target the microsoft ABI.
-#if defined(_WIN32) && defined(_MSC_VER)
-# define _LIBCPP_ABI_MICROSOFT
-#else
-# define _LIBCPP_ABI_ITANIUM
+// that Windows compilers pretending to be MSVC++ target the Microsoft ABI,
+// and allow the user to explicitly specify the ABI to handle cases where this
+// heuristic falls short.
+#if !defined(_LIBCPP_ABI_ITANIUM) && !defined(_LIBCPP_ABI_MICROSOFT)
+# if defined(_WIN32) && defined(_MSC_VER)
+#  define _LIBCPP_ABI_MICROSOFT
+# else
+#  define _LIBCPP_ABI_ITANIUM
+# endif
 #endif
 
 // Need to detect which libc we're using if we're on Linux.

Modified: libcxx/trunk/include/__config_site.in
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__config_site.in?rev=314949&r1=314948&r2=314949&view=diff
==
--- libcxx/trunk/include/__config_site.in (original)
+++ libcxx/trunk/include/__config_site.in Wed Oct  4 16:44:38 2017
@@ -12,6 +12,8 @@
 
 #cmakedefine _LIBCPP_ABI_VERSION @_LIBCPP_ABI_VERSION@
 #cmakedefine _LIBCPP_ABI_UNSTABLE
+#cmakedefine _LIBCPP_ABI_ITANIUM
+#cmakedefine _LIBCPP_ABI_MICROSOFT
 #cmakedefine _LIBCPP_HAS_NO_GLOBAL_FILESYSTEM_NAMESPACE
 #cmakedefine _LIBCPP_HAS_NO_STDIN
 #cmakedefine _LIBCPP_HAS_NO_STDOUT


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

[libcxx] r314950 - [libc++] Move cache variable definition. NFC

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Wed Oct  4 16:51:57 2017
New Revision: 314950

URL: http://llvm.org/viewvc/llvm-project?rev=314950&view=rev
Log:
[libc++] Move cache variable definition. NFC

Move it to where the other ABI cache variables/options are defined.

Modified:
libcxx/trunk/CMakeLists.txt

Modified: libcxx/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.txt?rev=314950&r1=314949&r2=314950&view=diff
==
--- libcxx/trunk/CMakeLists.txt (original)
+++ libcxx/trunk/CMakeLists.txt Wed Oct  4 16:51:57 2017
@@ -101,6 +101,7 @@ set(LIBCXX_ABI_VERSION 1 CACHE STRING "A
 option(LIBCXX_ABI_UNSTABLE "Unstable ABI of libc++." OFF)
 option(LIBCXX_ABI_ITANIUM "Ignore auto-detection and force use of the Itanium 
ABI.")
 option(LIBCXX_ABI_MICROSOFT "Ignore auto-detection and force use of the 
Microsoft ABI.")
+set(LIBCXX_ABI_DEFINES "" CACHE STRING "A semicolon separated list of ABI 
macros to define in the site config header.")
 option(LIBCXX_USE_COMPILER_RT "Use compiler-rt instead of libgcc" OFF)
 
 if (NOT LIBCXX_ENABLE_SHARED AND NOT LIBCXX_ENABLE_STATIC)
@@ -615,7 +616,6 @@ config_define_if(LIBCXX_HAS_EXTERNAL_THR
 config_define_if(LIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY 
_LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL)
 config_define_if(LIBCXX_HAS_MUSL_LIBC _LIBCPP_HAS_MUSL_LIBC)
 
-set(LIBCXX_ABI_DEFINES "" CACHE STRING "A semicolon separated list of ABI 
macros to define in the site config header")
 if (LIBCXX_ABI_DEFINES)
   set(abi_defines)
   foreach (abi_define ${LIBCXX_ABI_DEFINES})


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

[libcxx] r314965 - [libc++] Clarify names of ABI forcing macros

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Wed Oct  4 19:18:08 2017
New Revision: 314965

URL: http://llvm.org/viewvc/llvm-project?rev=314965&view=rev
Log:
[libc++] Clarify names of ABI forcing macros

Make it clear that these are intended only to force a specific ABI when
the autodetection would give the wrong result by renaming the cmake
options and adding separate forcing macros, as suggested by EricWF in
the post-commit review of r314949 and further discussed on IRC.

Modified:
libcxx/trunk/CMakeLists.txt
libcxx/trunk/include/__config
libcxx/trunk/include/__config_site.in

Modified: libcxx/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.txt?rev=314965&r1=314964&r2=314965&view=diff
==
--- libcxx/trunk/CMakeLists.txt (original)
+++ libcxx/trunk/CMakeLists.txt Wed Oct  4 19:18:08 2017
@@ -99,8 +99,8 @@ cmake_dependent_option(LIBCXX_INSTALL_EX
 "LIBCXX_ENABLE_EXPERIMENTAL_LIBRARY;LIBCXX_INSTALL_LIBRARY" OFF)
 set(LIBCXX_ABI_VERSION 1 CACHE STRING "ABI version of libc++.")
 option(LIBCXX_ABI_UNSTABLE "Unstable ABI of libc++." OFF)
-option(LIBCXX_ABI_ITANIUM "Ignore auto-detection and force use of the Itanium 
ABI.")
-option(LIBCXX_ABI_MICROSOFT "Ignore auto-detection and force use of the 
Microsoft ABI.")
+option(LIBCXX_ABI_FORCE_ITANIUM "Ignore auto-detection and force use of the 
Itanium ABI.")
+option(LIBCXX_ABI_FORCE_MICROSOFT "Ignore auto-detection and force use of the 
Microsoft ABI.")
 set(LIBCXX_ABI_DEFINES "" CACHE STRING "A semicolon separated list of ABI 
macros to define in the site config header.")
 option(LIBCXX_USE_COMPILER_RT "Use compiler-rt instead of libgcc" OFF)
 
@@ -340,8 +340,8 @@ if (LIBCXX_HAS_MUSL_LIBC AND NOT LIBCXX_
   "when building for Musl with LIBCXX_HAS_MUSL_LIBC.")
 endif()
 
-if (LIBCXX_ABI_ITANIUM AND LIBCXX_ABI_MICROSOFT)
-  message(FATAL_ERROR "Only one of LIBCXX_ABI_ITANIUM and LIBCXX_ABI_MICROSOFT 
can be specified.")
+if (LIBCXX_ABI_FORCE_ITANIUM AND LIBCXX_ABI_FORCE_MICROSOFT)
+  message(FATAL_ERROR "Only one of LIBCXX_ABI_FORCE_ITANIUM and 
LIBCXX_ABI_FORCE_MICROSOFT can be specified.")
 endif ()
 
 
#===
@@ -601,8 +601,8 @@ if (NOT LIBCXX_ABI_VERSION EQUAL "1")
   config_define(${LIBCXX_ABI_VERSION} _LIBCPP_ABI_VERSION)
 endif()
 config_define_if(LIBCXX_ABI_UNSTABLE _LIBCPP_ABI_UNSTABLE)
-config_define_if(LIBCXX_ABI_ITANIUM _LIBCPP_ABI_ITANIUM)
-config_define_if(LIBCXX_ABI_MICROSOFT _LIBCPP_ABI_MICROSOFT)
+config_define_if(LIBCXX_ABI_FORCE_ITANIUM _LIBCPP_ABI_FORCE_ITANIUM)
+config_define_if(LIBCXX_ABI_FORCE_MICROSOFT _LIBCPP_ABI_FORCE_MICROSOFT)
 
 config_define_if_not(LIBCXX_ENABLE_GLOBAL_FILESYSTEM_NAMESPACE 
_LIBCPP_HAS_NO_GLOBAL_FILESYSTEM_NAMESPACE)
 config_define_if_not(LIBCXX_ENABLE_STDIN _LIBCPP_HAS_NO_STDIN)

Modified: libcxx/trunk/include/__config
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__config?rev=314965&r1=314964&r2=314965&view=diff
==
--- libcxx/trunk/include/__config (original)
+++ libcxx/trunk/include/__config Wed Oct  4 19:18:08 2017
@@ -160,7 +160,13 @@
 // that Windows compilers pretending to be MSVC++ target the Microsoft ABI,
 // and allow the user to explicitly specify the ABI to handle cases where this
 // heuristic falls short.
-#if !defined(_LIBCPP_ABI_ITANIUM) && !defined(_LIBCPP_ABI_MICROSOFT)
+#if defined(_LIBCPP_ABI_FORCE_ITANIUM) && defined(_LIBCPP_ABI_FORCE_MICROSOFT)
+# error "Only one of _LIBCPP_ABI_FORCE_ITANIUM and _LIBCPP_ABI_FORCE_MICROSOFT 
can be defined"
+#elif defined(_LIBCPP_ABI_FORCE_ITANIUM)
+# define _LIBCPP_ABI_ITANIUM
+#elif defined(_LIBCPP_ABI_FORCE_MICROSOFT)
+# define _LIBCPP_ABI_MICROSOFT
+#else
 # if defined(_WIN32) && defined(_MSC_VER)
 #  define _LIBCPP_ABI_MICROSOFT
 # else

Modified: libcxx/trunk/include/__config_site.in
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__config_site.in?rev=314965&r1=314964&r2=314965&view=diff
==
--- libcxx/trunk/include/__config_site.in (original)
+++ libcxx/trunk/include/__config_site.in Wed Oct  4 19:18:08 2017
@@ -12,8 +12,8 @@
 
 #cmakedefine _LIBCPP_ABI_VERSION @_LIBCPP_ABI_VERSION@
 #cmakedefine _LIBCPP_ABI_UNSTABLE
-#cmakedefine _LIBCPP_ABI_ITANIUM
-#cmakedefine _LIBCPP_ABI_MICROSOFT
+#cmakedefine _LIBCPP_ABI_FORCE_ITANIUM
+#cmakedefine _LIBCPP_ABI_FORCE_MICROSOFT
 #cmakedefine _LIBCPP_HAS_NO_GLOBAL_FILESYSTEM_NAMESPACE
 #cmakedefine _LIBCPP_HAS_NO_STDIN
 #cmakedefine _LIBCPP_HAS_NO_STDOUT


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

Re: [libcxx] r314949 - [libc++] Allow users to explicitly specify ABI

[Shoaib Meenai via cfe-commits]

Eric and I discussed this further on IRC, and r314965 implements his 
suggestions.

From: Eric Fiselier 
Date: Wednesday, October 4, 2017 at 6:11 PM
To: Shoaib Meenai 
Cc: cfe-commits 
Subject: Re: [libcxx] r314949 - [libc++] Allow users to explicitly specify ABI



On Wed, Oct 4, 2017 at 5:44 PM, Shoaib Meenai via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: smeenai
Date: Wed Oct  4 16:44:38 2017
New Revision: 314949

URL: 
http://llvm.org/viewvc/llvm-project?rev=314949&view=rev<https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D314949-26view-3Drev&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=FfTS_aoYUPTcrKzdSBjzDilbxxSRUA__6T0fQtUoDw4&s=cckMmTlQdJTp0e-PZSnITzPCbwRVbumfloKSl3KQOGM&e=>
Log:
[libc++] Allow users to explicitly specify ABI

libc++'s current heuristic for detecting Itanium vs. Microsoft ABI falls
short in some cases. For example, it will detect windows-itanium targets
as using the Microsoft ABI, since they set `_MSC_VER` (for compatibility
with Microsoft headers). Leave the current heuristic in place by default
but also allow users to explicitly specify the ABI if need be.

Modified:
libcxx/trunk/CMakeLists.txt
libcxx/trunk/include/__config

libcxx/trunk/include/__config_site.in<https://urldefense.proofpoint.com/v2/url?u=http-3A__config-5Fsite.in&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=FfTS_aoYUPTcrKzdSBjzDilbxxSRUA__6T0fQtUoDw4&s=DFPNV_9W5sjp5dUlpv6oF__hPknbPHkZ22xnaZhWOfQ&e=>

Modified: libcxx/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.txt?rev=314949&r1=314948&r2=314949&view=diff<https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_libcxx_trunk_CMakeLists.txt-3Frev-3D314949-26r1-3D314948-26r2-3D314949-26view-3Ddiff&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=FfTS_aoYUPTcrKzdSBjzDilbxxSRUA__6T0fQtUoDw4&s=LJoAA9_RLFbfZHWQ0omY5NNRseSbizGWiRSUeJPtuSY&e=>
==
--- libcxx/trunk/CMakeLists.txt (original)
+++ libcxx/trunk/CMakeLists.txt Wed Oct  4 16:44:38 2017
@@ -99,6 +99,8 @@ cmake_dependent_option(LIBCXX_INSTALL_EX
 "LIBCXX_ENABLE_EXPERIMENTAL_LIBRARY;LIBCXX_INSTALL_LIBRARY" OFF)
 set(LIBCXX_ABI_VERSION 1 CACHE STRING "ABI version of libc++.")
 option(LIBCXX_ABI_UNSTABLE "Unstable ABI of libc++." OFF)
+option(LIBCXX_ABI_ITANIUM "Ignore auto-detection and force use of the Itanium 
ABI.")
+option(LIBCXX_ABI_MICROSOFT "Ignore auto-detection and force use of the 
Microsoft ABI.")

Shouldn't these specify a default option?

 option(LIBCXX_USE_COMPILER_RT "Use compiler-rt instead of libgcc" OFF)

 if (NOT LIBCXX_ENABLE_SHARED AND NOT LIBCXX_ENABLE_STATIC)
@@ -337,6 +339,10 @@ if (LIBCXX_HAS_MUSL_LIBC AND NOT LIBCXX_
   "when building for Musl with LIBCXX_HAS_MUSL_LIBC.")
 endif()

+if (LIBCXX_ABI_ITANIUM AND LIBCXX_ABI_MICROSOFT)
+  message(FATAL_ERROR "Only one of LIBCXX_ABI_ITANIUM and LIBCXX_ABI_MICROSOFT 
can be specified.")
+endif ()
+
 
#===
 # Configure System
 
#===
@@ -594,6 +600,8 @@ if (NOT LIBCXX_ABI_VERSION EQUAL "1")
   config_define(${LIBCXX_ABI_VERSION} _LIBCPP_ABI_VERSION)
 endif()
 config_define_if(LIBCXX_ABI_UNSTABLE _LIBCPP_ABI_UNSTABLE)
+config_define_if(LIBCXX_ABI_ITANIUM _LIBCPP_ABI_ITANIUM)
+config_define_if(LIBCXX_ABI_MICROSOFT _LIBCPP_ABI_MICROSOFT)
I'm not a fan of the direction this is going in. It seems to require the 
generation and use of a __config_site header
in all cases where it's used. I don't think we want to require that in the 
common case where you're using Itanium on
Linux or Windows.

However, like you said, the attempt of this is to override the automatic 
detection done in the headers. Maybe the name
should reflect that (Ex. _LIBCPP_ABI_ITANIUM_OVERRIDE)? And then the 
autodetection can operate by checking for an override first?

 config_define_if_not(LIBCXX_ENABLE_GLOBAL_FILESYSTEM_NAMESPACE 
_LIBCPP_HAS_NO_GLOBAL_FILESYSTEM_NAMESPACE)
 config_define_if_not(LIBCXX_ENABLE_STDIN _LIBCPP_HAS_NO_STDIN)

Modified: libcxx/trunk/include/__config
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__config?rev=314949&r1=314948&r2=314949&view=diff<https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_libcxx_trunk_include_-5F-5Fconfig-3Frev-3D314949-26r1-3D314948-26r2-3D314949-26view-3Ddiff&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=FfTS_aoYUPTcrKzdSBjzDilbxxSRUA__6T0fQtUoDw4&s=tvy2iLdreg0H7Q_MnfrAK

[libcxx] r315234 - [libc++] Support Microsoft ABI without vcruntime headers

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Mon Oct  9 12:25:17 2017
New Revision: 315234

URL: http://llvm.org/viewvc/llvm-project?rev=315234&view=rev
Log:
[libc++] Support Microsoft ABI without vcruntime headers

The vcruntime headers are hairy and clash with both libc++ headers
themselves and other libraries. libc++ normally deals with the clashes
by deferring to the vcruntime headers and silencing its own definitions,
but for clients which don't want to depend on vcruntime headers, it's
desirable to support the opposite, i.e. have libc++ provide its own
definitions.

Certain operator new/delete replacement scenarios are not currently
supported in this mode, which requires some tests to be marked XFAIL.
The added documentation has more details.

Differential Revision: https://reviews.llvm.org/D38522

Modified:
libcxx/trunk/CMakeLists.txt
libcxx/trunk/docs/UsingLibcxx.rst
libcxx/trunk/include/__config_site.in
libcxx/trunk/include/exception
libcxx/trunk/include/new
libcxx/trunk/src/new.cpp
libcxx/trunk/src/support/runtime/exception_msvc.ipp
libcxx/trunk/src/support/runtime/exception_pointer_msvc.ipp

libcxx/trunk/test/std/language.support/support.dynamic/new.delete/new.delete.array/new_array_nothrow_replace.pass.cpp

libcxx/trunk/test/std/language.support/support.dynamic/new.delete/new.delete.array/new_array_replace.pass.cpp

libcxx/trunk/test/std/language.support/support.dynamic/new.delete/new.delete.single/new_nothrow_replace.pass.cpp
libcxx/trunk/utils/libcxx/test/config.py

Modified: libcxx/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.txt?rev=315234&r1=315233&r2=315234&view=diff
==
--- libcxx/trunk/CMakeLists.txt (original)
+++ libcxx/trunk/CMakeLists.txt Mon Oct  9 12:25:17 2017
@@ -615,6 +615,7 @@ config_define_if(LIBCXX_HAS_PTHREAD_API
 config_define_if(LIBCXX_HAS_EXTERNAL_THREAD_API 
_LIBCPP_HAS_THREAD_API_EXTERNAL)
 config_define_if(LIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY 
_LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL)
 config_define_if(LIBCXX_HAS_MUSL_LIBC _LIBCPP_HAS_MUSL_LIBC)
+config_define_if(LIBCXX_NO_VCRUNTIME _LIBCPP_NO_VCRUNTIME)
 
 if (LIBCXX_ABI_DEFINES)
   set(abi_defines)

Modified: libcxx/trunk/docs/UsingLibcxx.rst
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/docs/UsingLibcxx.rst?rev=315234&r1=315233&r2=315234&view=diff
==
--- libcxx/trunk/docs/UsingLibcxx.rst (original)
+++ libcxx/trunk/docs/UsingLibcxx.rst Mon Oct  9 12:25:17 2017
@@ -185,6 +185,26 @@ thread safety annotations.
 * Giving `set`, `map`, `multiset`, `multimap` a comparator which is not
   const callable.
 
+**_LIBCPP_NO_VCRUNTIME**:
+  Microsoft's C and C++ headers are fairly entangled, and some of their C++
+  headers are fairly hard to avoid. In particular, `vcruntime_new.h` gets 
pulled
+  in from a lot of other headers and provides definitions which clash with
+  libc++ headers, such as `nothrow_t` (note that `nothrow_t` is a struct, so
+  there's no way for libc++ to provide a compatible definition, since you can't
+  have multiple definitions).
+
+  By default, libc++ solves this problem by deferring to Microsoft's vcruntime
+  headers where needed. However, it may be undesirable to depend on vcruntime
+  headers, since they may not always be available in cross-compilation setups,
+  or they may clash with other headers. The `_LIBCPP_NO_VCRUNTIME` macro
+  prevents libc++ from depending on vcruntime headers. Consequently, it also
+  prevents libc++ headers from being interoperable with vcruntime headers (from
+  the aforementioned clashes), so users of this macro are promising to not
+  attempt to combine libc++ headers with the problematic vcruntime headers. 
This
+  macro also currently prevents certain `operator new`/`operator delete`
+  replacement scenarios from working, e.g. replacing `operator new` and
+  expecting a non-replaced `operator new[]` to call the replaced `operator 
new`.
+
 C++17 Specific Configuration Macros
 ---
 **_LIBCPP_ENABLE_CXX17_REMOVED_FEATURES**:

Modified: libcxx/trunk/include/__config_site.in
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__config_site.in?rev=315234&r1=315233&r2=315234&view=diff
==
--- libcxx/trunk/include/__config_site.in (original)
+++ libcxx/trunk/include/__config_site.in Mon Oct  9 12:25:17 2017
@@ -25,6 +25,7 @@
 #cmakedefine _LIBCPP_HAS_THREAD_API_EXTERNAL
 #cmakedefine _LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL
 #cmakedefine _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS
+#cmakedefine _LIBCPP_NO_VCRUNTIME
 
 @_LIBCPP_ABI_DEFINES@
 

Modified: libcxx/trunk/include/exception
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/exception?rev=315234&r1=315233&r2=315234&view=diff
===

r304761 - [Driver] Don't force .exe suffix for lld

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Mon Jun  5 21:06:28 2017
New Revision: 304761

URL: http://llvm.org/viewvc/llvm-project?rev=304761&view=rev
Log:
[Driver] Don't force .exe suffix for lld

When cross-compiling to Windows using lld, we want the driver to invoke
it as lld-link rather than lld-link.exe. On Windows, the LLVM fs
functions take care of adding the .exe suffix where necessary, so we can
just drop the addition in the toolchain entirely.

Differential Revision: https://reviews.llvm.org/D33923

Modified:
cfe/trunk/lib/Driver/ToolChains/MSVC.cpp
cfe/trunk/test/Driver/cl-link.c

Modified: cfe/trunk/lib/Driver/ToolChains/MSVC.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/MSVC.cpp?rev=304761&r1=304760&r2=304761&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains/MSVC.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/MSVC.cpp Mon Jun  5 21:06:28 2017
@@ -529,9 +529,7 @@ void visualstudio::Linker::ConstructJob(
   SkipSettingEnvironment:;
 #endif
   } else {
-linkPath = Linker;
-llvm::sys::path::replace_extension(linkPath, "exe");
-linkPath = TC.GetProgramPath(linkPath.c_str());
+linkPath = TC.GetProgramPath(Linker.str().c_str());
   }
 
   auto LinkCmd = llvm::make_unique(

Modified: cfe/trunk/test/Driver/cl-link.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/cl-link.c?rev=304761&r1=304760&r2=304761&view=diff
==
--- cfe/trunk/test/Driver/cl-link.c (original)
+++ cfe/trunk/test/Driver/cl-link.c Mon Jun  5 21:06:28 2017
@@ -56,4 +56,4 @@
 // NONEXISTENT: nonexistent
 
 // RUN: %clang_cl /Tc%s -fuse-ld=lld -### 2>&1 | FileCheck 
--check-prefix=USE_LLD %s
-// USE_LLD: lld-link.exe
+// USE_LLD: lld-link


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

Re: [libunwind] r321469 - There is no portable format string for printing `uintptr_t` values.

[Shoaib Meenai via cfe-commits]

Isn't PRIuPTR (from inttypes.h) the portable way to print a uintptr_t?



On 12/27/17, 10:47 AM, "cfe-commits on behalf of Chandler Carruth via 
cfe-commits"  wrote:



Author: chandlerc

Date: Tue Dec 26 21:46:53 2017

New Revision: 321469



URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D321469-26view-3Drev&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=MrCL0yxupzyiw5gb5FUuieLYS_IsKGZWx7bEvlEEcIA&s=TtvpLBY95jLHo_IzHMotPEJ5BSh0lIHhmXjuGYj9GcY&e=

Log:

There is no portable format string for printing `uintptr_t` values.

Instead, cast them to `void *` which has a portable format string syntax

of `%p`.



This fixes a -Wformat error when building libunwind.



Modified:

libunwind/trunk/src/AddressSpace.hpp



Modified: libunwind/trunk/src/AddressSpace.hpp

URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_libunwind_trunk_src_AddressSpace.hpp-3Frev-3D321469-26r1-3D321468-26r2-3D321469-26view-3Ddiff&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=MrCL0yxupzyiw5gb5FUuieLYS_IsKGZWx7bEvlEEcIA&s=ek_G7axgNz_LrqBu1RZ3clq1PkTu1FwDkkaFjZFu1T8&e=


==

--- libunwind/trunk/src/AddressSpace.hpp (original)

+++ libunwind/trunk/src/AddressSpace.hpp Tue Dec 26 21:46:53 2017

@@ -384,13 +384,13 @@ inline bool LocalAddressSpace::findUnwin

   // Bare metal is statically linked, so no need to ask the dynamic loader

   info.dwarf_section_length = (uintptr_t)(&__eh_frame_end - 
&__eh_frame_start);

   info.dwarf_section =(uintptr_t)(&__eh_frame_start);

-  _LIBUNWIND_TRACE_UNWINDING("findUnwindSections: section %X length %x",

- info.dwarf_section, 
info.dwarf_section_length);

+  _LIBUNWIND_TRACE_UNWINDING("findUnwindSections: section %p length %p",

+ (void *)info.dwarf_section, (void 
*)info.dwarf_section_length);

 #if defined(_LIBUNWIND_SUPPORT_DWARF_INDEX)

   info.dwarf_index_section =(uintptr_t)(&__eh_frame_hdr_start);

   info.dwarf_index_section_length = (uintptr_t)(&__eh_frame_hdr_end - 
&__eh_frame_hdr_start);

-  _LIBUNWIND_TRACE_UNWINDING("findUnwindSections: index section %X length 
%x",

- info.dwarf_index_section, 
info.dwarf_index_section_length);

+  _LIBUNWIND_TRACE_UNWINDING("findUnwindSections: index section %p length 
%p",

+ (void *)info.dwarf_index_section, (void 
*)info.dwarf_index_section_length);

 #endif

   if (info.dwarf_section_length)

 return true;

@@ -398,8 +398,8 @@ inline bool LocalAddressSpace::findUnwin

   // Bare metal is statically linked, so no need to ask the dynamic loader

   info.arm_section =(uintptr_t)(&__exidx_start);

   info.arm_section_length = (uintptr_t)(&__exidx_end - &__exidx_start);

-  _LIBUNWIND_TRACE_UNWINDING("findUnwindSections: section %X length %x",

- info.arm_section, info.arm_section_length);

+  _LIBUNWIND_TRACE_UNWINDING("findUnwindSections: section %p length %p",

+ (void *)info.arm_section, (void 
*)info.arm_section_length);

   if (info.arm_section && info.arm_section_length)

 return true;

 #elif defined(_LIBUNWIND_SUPPORT_DWARF_UNWIND) && defined(_WIN32)





___

cfe-commits mailing list

cfe-commits@lists.llvm.org


https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_cfe-2Dcommits&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=MrCL0yxupzyiw5gb5FUuieLYS_IsKGZWx7bEvlEEcIA&s=lW2e-8AqrhoM9xYXcuGtLKrqsZAff2PFJllWlzitxAc&e=


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

Re: [libcxx] r321937 - Correct mistake in pragma usage for Windows

[Shoaib Meenai via cfe-commits]

Hah, we all missed this during review.

From: cfe-commits  on behalf of Saleem 
Abdulrasool via cfe-commits 
Reply-To: Saleem Abdulrasool 
Date: Saturday, January 6, 2018 at 10:48 AM
To: "cfe-commits@lists.llvm.org" 
Subject: [libcxx] r321937 - Correct mistake in pragma usage for Windows

Author: compnerd
Date: Sat Jan  6 10:47:03 2018
New Revision: 321937

URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D321937-26view-3Drev&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=AGe8lTmLFGMlGPm9sLEnF6Id8r0AU2mMf23PCSg_Z-A&s=0Lbt7xk05gsFMXV9JaPHaAuJKJNPL2uAMqa8KGVB0Zc&e=
Log:
Correct mistake in pragma usage for Windows

The autolink pragma was missing the pragma name itself.  This would
result in the pragma being silently dropped.

Modified:
libcxx/trunk/include/__config

Modified: libcxx/trunk/include/__config
URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_libcxx_trunk_include_-5F-5Fconfig-3Frev-3D321937-26r1-3D321936-26r2-3D321937-26view-3Ddiff&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=AGe8lTmLFGMlGPm9sLEnF6Id8r0AU2mMf23PCSg_Z-A&s=XCRMWiLWYMeL6yqcmwRIbUGdeeQ4izrIJs4X9733ddA&e=
==
--- libcxx/trunk/include/__config (original)
+++ libcxx/trunk/include/__config Sat Jan  6 10:47:03 2018
@@ -1278,9 +1278,9 @@ _LIBCPP_FUNC_VIS extern "C" void __sanit
#if defined(_LIBCPP_ABI_MICROSOFT) && !defined(_LIBCPP_BUILDING_LIBRARY)
# if defined(_DLL)
-#   pragma(lib, "c++.lib")
+#   pragma comment(lib, "c++.lib")
# else
-#   pragma(lib, "libc++.lib")
+#   pragma comment(lib, "libc++.lib")
# endif
#endif // defined(_LIBCPP_ABI_MICROSOFT) && !defined(_LIBCPP_BUILDING_LIBRARY)


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_cfe-2Dcommits&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=AGe8lTmLFGMlGPm9sLEnF6Id8r0AU2mMf23PCSg_Z-A&s=1QAEIzWyLnmjbZXGswXGKna_StGDQ_8ZWCXJcv9b-2g&e=

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

Re: r326168 - Attempt to fix greendragon bot after r326141

[Shoaib Meenai via cfe-commits]

This seems bogus to me. CodeView can be generated on any build platform; it 
just needs the correct triple, which Reid added in r326144.

From: cfe-commits  on behalf of Adam Nemet 
via cfe-commits 
Reply-To: Adam Nemet 
Date: Monday, February 26, 2018 at 8:51 PM
To: "cfe-commits@lists.llvm.org" 
Subject: r326168 - Attempt to fix greendragon bot after r326141

Author: anemet
Date: Mon Feb 26 20:49:26 2018
New Revision: 326168

URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D326168-26view-3Drev&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=B6WfLLVLbYMU_571sI0XgBTcOm561QyDCKF2UOJyc-k&s=oqoKnyrAT6kNwxIasdWb7eopGd0q41TFJ5Hxp_eoiZs&e=
Log:
Attempt to fix greendragon bot after r326141

Modified:
cfe/trunk/test/Driver/codeview-column-info.c

Modified: cfe/trunk/test/Driver/codeview-column-info.c
URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_cfe_trunk_test_Driver_codeview-2Dcolumn-2Dinfo.c-3Frev-3D326168-26r1-3D326167-26r2-3D326168-26view-3Ddiff&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=B6WfLLVLbYMU_571sI0XgBTcOm561QyDCKF2UOJyc-k&s=Hs37wkn2y2OFh6b_DWdNuK_AD--vySi-ptv_d_HDqxg&e=
==
--- cfe/trunk/test/Driver/codeview-column-info.c (original)
+++ cfe/trunk/test/Driver/codeview-column-info.c Mon Feb 26 20:49:26 2018
@@ -1,3 +1,4 @@
+// REQUIRES: system-windows
// Check that -dwarf-column-info does not get added to the cc1 line:
// 1) When -gcodeview is present via the clang or clang++ driver
// 2) When /Z7 is present via the cl driver.


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_cfe-2Dcommits&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=B6WfLLVLbYMU_571sI0XgBTcOm561QyDCKF2UOJyc-k&s=JTIVfh7ogIVoFYMFdjOK-30TFLWLX39y8q9KItC_xnY&e=

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

Re: r326168 - Attempt to fix greendragon bot after r326141

[Shoaib Meenai via cfe-commits]

Could you point me to the specific bot that was failing? I've dealt with that 
problem before, and it shouldn't be hard to fix, but I wanna monitor the bot 
after the fix to make sure it stays green.

From:  on behalf of Adam Nemet 
Date: Monday, February 26, 2018 at 9:30 PM
To: Shoaib Meenai 
Cc: "cfe-commits@lists.llvm.org" , Reid Kleckner 
, Zachary Turner 
Subject: Re: r326168 - Attempt to fix greendragon bot after r326141

I don’t think we can deal with the slash options:

clang-7.0: warning: 
'/Users/buildslave/jenkins/workspace/apple-clang-master-RA-stage1-cmake-incremental/clang/src/tools/clang/test/Driver/codeview-column-info.c'
 treated as the '/U' option [-Wslash-u-filename]
clang-7.0: note: Use '--' to treat subsequent arguments as filenames
clang-7.0: warning: argument unused during compilation: '/Z7' 
[-Wunused-command-line-argument]
clang-7.0: warning: argument unused during compilation: ‘-U 
sers/buildslave/jenkins/workspace/apple-clang-master-RA-stage1-cmake-incremental/clang/src/tools/clang/test/Driver/codeview-column-info.c'
 [-Wunused-command-line-argument]

Anyhow as I said to Reid, feel free to improve the patch, I am just bringing 
back a bot that has been red for hours.

Adam


On Feb 26, 2018, at 9:22 PM, Shoaib Meenai 
mailto:smee...@fb.com>> wrote:

This seems bogus to me. CodeView can be generated on any build platform; it 
just needs the correct triple, which Reid added in r326144.

From: cfe-commits 
mailto:cfe-commits-boun...@lists.llvm.org>> 
on behalf of Adam Nemet via cfe-commits 
mailto:cfe-commits@lists.llvm.org>>
Reply-To: Adam Nemet mailto:ane...@apple.com>>
Date: Monday, February 26, 2018 at 8:51 PM
To: "cfe-commits@lists.llvm.org" 
mailto:cfe-commits@lists.llvm.org>>
Subject: r326168 - Attempt to fix greendragon bot after r326141

Author: anemet
Date: Mon Feb 26 20:49:26 2018
New Revision: 326168

URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D326168-26view-3Drev&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=B6WfLLVLbYMU_571sI0XgBTcOm561QyDCKF2UOJyc-k&s=oqoKnyrAT6kNwxIasdWb7eopGd0q41TFJ5Hxp_eoiZs&e=
Log:
Attempt to fix greendragon bot after r326141

Modified:
cfe/trunk/test/Driver/codeview-column-info.c

Modified: cfe/trunk/test/Driver/codeview-column-info.c
URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_cfe_trunk_test_Driver_codeview-2Dcolumn-2Dinfo.c-3Frev-3D326168-26r1-3D326167-26r2-3D326168-26view-3Ddiff&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=B6WfLLVLbYMU_571sI0XgBTcOm561QyDCKF2UOJyc-k&s=Hs37wkn2y2OFh6b_DWdNuK_AD--vySi-ptv_d_HDqxg&e=
==
--- cfe/trunk/test/Driver/codeview-column-info.c (original)
+++ cfe/trunk/test/Driver/codeview-column-info.c Mon Feb 26 20:49:26 2018
@@ -1,3 +1,4 @@
+// REQUIRES: system-windows
// Check that -dwarf-column-info does not get added to the cc1 line:
// 1) When -gcodeview is present via the clang or clang++ driver
// 2) When /Z7 is present via the cl driver.


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_cfe-2Dcommits&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=B6WfLLVLbYMU_571sI0XgBTcOm561QyDCKF2UOJyc-k&s=JTIVfh7ogIVoFYMFdjOK-30TFLWLX39y8q9KItC_xnY&e=

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

Re: r326168 - Attempt to fix greendragon bot after r326141

[Shoaib Meenai via cfe-commits]

Thanks. I'm building on macOS locally to confirm the original problem and my 
fix.

From:  on behalf of Adam Nemet 
Date: Monday, February 26, 2018 at 9:42 PM
To: Shoaib Meenai 
Cc: "cfe-commits@lists.llvm.org" , Reid Kleckner 
, Zachary Turner 
Subject: Re: r326168 - Attempt to fix greendragon bot after r326141

This is the bot with the failure:

http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental/46794/#showFailuresLink

But to make matters worse, greendragon is experience some difficulty fetching 
from SVN so you might want to wait until things recover.  I am not sure if I 
will be able to get in touch with Mike Edwards until the morning PST.

There may also be llvm bots that exhibit the same problem.  You may have better 
luck with those in the short term.

Adam


On Feb 26, 2018, at 9:35 PM, Shoaib Meenai 
mailto:smee...@fb.com>> wrote:

Could you point me to the specific bot that was failing? I've dealt with that 
problem before, and it shouldn't be hard to fix, but I wanna monitor the bot 
after the fix to make sure it stays green.

From: mailto:ane...@apple.com>> on behalf of Adam Nemet 
mailto:ane...@apple.com>>
Date: Monday, February 26, 2018 at 9:30 PM
To: Shoaib Meenai mailto:smee...@fb.com>>
Cc: "cfe-commits@lists.llvm.org" 
mailto:cfe-commits@lists.llvm.org>>, Reid Kleckner 
mailto:r...@google.com>>, Zachary Turner 
mailto:ztur...@google.com>>
Subject: Re: r326168 - Attempt to fix greendragon bot after r326141

I don’t think we can deal with the slash options:

clang-7.0: warning: 
'/Users/buildslave/jenkins/workspace/apple-clang-master-RA-stage1-cmake-incremental/clang/src/tools/clang/test/Driver/codeview-column-info.c'
 treated as the '/U' option [-Wslash-u-filename]
clang-7.0: note: Use '--' to treat subsequent arguments as filenames
clang-7.0: warning: argument unused during compilation: '/Z7' 
[-Wunused-command-line-argument]
clang-7.0: warning: argument unused during compilation: ‘-U 
sers/buildslave/jenkins/workspace/apple-clang-master-RA-stage1-cmake-incremental/clang/src/tools/clang/test/Driver/codeview-column-info.c'
 [-Wunused-command-line-argument]

Anyhow as I said to Reid, feel free to improve the patch, I am just bringing 
back a bot that has been red for hours.

Adam



On Feb 26, 2018, at 9:22 PM, Shoaib Meenai 
mailto:smee...@fb.com>> wrote:

This seems bogus to me. CodeView can be generated on any build platform; it 
just needs the correct triple, which Reid added in r326144.

From: cfe-commits 
mailto:cfe-commits-boun...@lists.llvm.org>> 
on behalf of Adam Nemet via cfe-commits 
mailto:cfe-commits@lists.llvm.org>>
Reply-To: Adam Nemet mailto:ane...@apple.com>>
Date: Monday, February 26, 2018 at 8:51 PM
To: "cfe-commits@lists.llvm.org" 
mailto:cfe-commits@lists.llvm.org>>
Subject: r326168 - Attempt to fix greendragon bot after r326141

Author: anemet
Date: Mon Feb 26 20:49:26 2018
New Revision: 326168

URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D326168-26view-3Drev&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=B6WfLLVLbYMU_571sI0XgBTcOm561QyDCKF2UOJyc-k&s=oqoKnyrAT6kNwxIasdWb7eopGd0q41TFJ5Hxp_eoiZs&e=
Log:
Attempt to fix greendragon bot after r326141

Modified:
cfe/trunk/test/Driver/codeview-column-info.c

Modified: cfe/trunk/test/Driver/codeview-column-info.c
URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_cfe_trunk_test_Driver_codeview-2Dcolumn-2Dinfo.c-3Frev-3D326168-26r1-3D326167-26r2-3D326168-26view-3Ddiff&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=B6WfLLVLbYMU_571sI0XgBTcOm561QyDCKF2UOJyc-k&s=Hs37wkn2y2OFh6b_DWdNuK_AD--vySi-ptv_d_HDqxg&e=
==
--- cfe/trunk/test/Driver/codeview-column-info.c (original)
+++ cfe/trunk/test/Driver/codeview-column-info.c Mon Feb 26 20:49:26 2018
@@ -1,3 +1,4 @@
+// REQUIRES: system-windows
// Check that -dwarf-column-info does not get added to the cc1 line:
// 1) When -gcodeview is present via the clang or clang++ driver
// 2) When /Z7 is present via the cl driver.


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_cfe-2Dcommits&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=B6WfLLVLbYMU_571sI0XgBTcOm561QyDCKF2UOJyc-k&s=JTIVfh7ogIVoFYMFdjOK-30TFLWLX39y8q9KItC_xnY&e=

___
cfe-commits mailing list
cfe-commits@lists.llvm.o

Re: r326168 - Attempt to fix greendragon bot after r326141

[Shoaib Meenai via cfe-commits]

Reid re-committed r326141 this morning (and followed up with r326144), and I 
don't think either of those have been reverted?

From: Zachary Turner 
Date: Monday, February 26, 2018 at 9:47 PM
To: Adam Nemet 
Cc: Shoaib Meenai , "cfe-commits@lists.llvm.org" 
, Reid Kleckner 
Subject: Re: r326168 - Attempt to fix greendragon bot after r326141

I already reverted this a long time ago, but if Shoaib has a proper fix that 
would be great
On Mon, Feb 26, 2018 at 9:45 PM Adam Nemet 
mailto:ane...@apple.com>> wrote:
Ah, that should be sufficient.



On Feb 26, 2018, at 9:44 PM, Shoaib Meenai 
mailto:smee...@fb.com>> wrote:

Thanks. I'm building on macOS locally to confirm the original problem and my 
fix.

From: mailto:ane...@apple.com>> on behalf of Adam Nemet 
mailto:ane...@apple.com>>
Date: Monday, February 26, 2018 at 9:42 PM
To: Shoaib Meenai mailto:smee...@fb.com>>
Cc: "cfe-commits@lists.llvm.org" 
mailto:cfe-commits@lists.llvm.org>>, Reid Kleckner 
mailto:r...@google.com>>, Zachary Turner 
mailto:ztur...@google.com>>
Subject: Re: r326168 - Attempt to fix greendragon bot after r326141

This is the bot with the failure:

http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental/46794/#showFailuresLink

But to make matters worse, greendragon is experience some difficulty fetching 
from SVN so you might want to wait until things recover.  I am not sure if I 
will be able to get in touch with Mike Edwards until the morning PST.

There may also be llvm bots that exhibit the same problem.  You may have better 
luck with those in the short term.

Adam

On Feb 26, 2018, at 9:35 PM, Shoaib Meenai 
mailto:smee...@fb.com>> wrote:

Could you point me to the specific bot that was failing? I've dealt with that 
problem before, and it shouldn't be hard to fix, but I wanna monitor the bot 
after the fix to make sure it stays green.

From: mailto:ane...@apple.com>> on behalf of Adam Nemet 
mailto:ane...@apple.com>>
Date: Monday, February 26, 2018 at 9:30 PM
To: Shoaib Meenai mailto:smee...@fb.com>>
Cc: "cfe-commits@lists.llvm.org" 
mailto:cfe-commits@lists.llvm.org>>, Reid Kleckner 
mailto:r...@google.com>>, Zachary Turner 
mailto:ztur...@google.com>>
Subject: Re: r326168 - Attempt to fix greendragon bot after r326141

I don’t think we can deal with the slash options:

clang-7.0: warning: 
'/Users/buildslave/jenkins/workspace/apple-clang-master-RA-stage1-cmake-incremental/clang/src/tools/clang/test/Driver/codeview-column-info.c'
 treated as the '/U' option [-Wslash-u-filename]
clang-7.0: note: Use '--' to treat subsequent arguments as filenames
clang-7.0: warning: argument unused during compilation: '/Z7' 
[-Wunused-command-line-argument]
clang-7.0: warning: argument unused during compilation: ‘-U 
sers/buildslave/jenkins/workspace/apple-clang-master-RA-stage1-cmake-incremental/clang/src/tools/clang/test/Driver/codeview-column-info.c'
 [-Wunused-command-line-argument]

Anyhow as I said to Reid, feel free to improve the patch, I am just bringing 
back a bot that has been red for hours.

Adam


On Feb 26, 2018, at 9:22 PM, Shoaib Meenai 
mailto:smee...@fb.com>> wrote:

This seems bogus to me. CodeView can be generated on any build platform; it 
just needs the correct triple, which Reid added in r326144.

From: cfe-commits 
mailto:cfe-commits-boun...@lists.llvm.org>> 
on behalf of Adam Nemet via cfe-commits 
mailto:cfe-commits@lists.llvm.org>>
Reply-To: Adam Nemet mailto:ane...@apple.com>>
Date: Monday, February 26, 2018 at 8:51 PM
To: "cfe-commits@lists.llvm.org" 
mailto:cfe-commits@lists.llvm.org>>
Subject: r326168 - Attempt to fix greendragon bot after r326141

Author: anemet
Date: Mon Feb 26 20:49:26 2018
New Revision: 326168

URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D326168-26view-3Drev&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=B6WfLLVLbYMU_571sI0XgBTcOm561QyDCKF2UOJyc-k&s=oqoKnyrAT6kNwxIasdWb7eopGd0q41TFJ5Hxp_eoiZs&e=
Log:
Attempt to fix greendragon bot after r326141

Modified:
cfe/trunk/test/Driver/codeview-column-info.c

Modified: cfe/trunk/test/Driver/codeview-column-info.c
URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_cfe_trunk_test_Driver_codeview-2Dcolumn-2Dinfo.c-3Frev-3D326168-26r1-3D326167-26r2-3D326168-26view-3Ddiff&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=B6WfLLVLbYMU_571sI0XgBTcOm561QyDCKF2UOJyc-k&s=Hs37wkn2y2OFh6b_DWdNuK_AD--vySi-ptv_d_HDqxg&e=
==
--- cfe/trunk/test/Driver/codeview-c

r326171 - [Driver] Fix codeview-column-info on macOS

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Mon Feb 26 22:04:23 2018
New Revision: 326171

URL: http://llvm.org/viewvc/llvm-project?rev=326171&view=rev
Log:
[Driver] Fix codeview-column-info on macOS

macOS home directory paths begin with /Users, and clang-cl interprets
the /U portion as a macro undefine rather than a path, causing test
failures on macOS. Use a -- to explicitly treat the input file as a path
and fix the test.

This effectively reverts r326168 and adds an alternative fix.

Modified:
cfe/trunk/test/Driver/codeview-column-info.c

Modified: cfe/trunk/test/Driver/codeview-column-info.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/codeview-column-info.c?rev=326171&r1=326170&r2=326171&view=diff
==
--- cfe/trunk/test/Driver/codeview-column-info.c (original)
+++ cfe/trunk/test/Driver/codeview-column-info.c Mon Feb 26 22:04:23 2018
@@ -1,4 +1,3 @@
-// REQUIRES: system-windows
 // Check that -dwarf-column-info does not get added to the cc1 line:
 // 1) When -gcodeview is present via the clang or clang++ driver
 // 2) When /Z7 is present via the cl driver.
@@ -7,7 +6,7 @@
 // RUN: FileCheck < %t1 %s
 // RUN: %clangxx -### --target=x86_64-windows-msvc -c -g -gcodeview %s 2> %t2
 // RUN: FileCheck < %t2 %s
-// RUN: %clang_cl -### --target=x86_64-windows-msvc /c /Z7 %s 2> %t2
+// RUN: %clang_cl -### --target=x86_64-windows-msvc /c /Z7 -- %s 2> %t2
 // RUN: FileCheck < %t2 %s
 
 // CHECK: "-cc1"


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

Re: r326168 - Attempt to fix greendragon bot after r326141

[Shoaib Meenai via cfe-commits]

r326171 works locally. I'll keep an eye on the bots.

From:  on behalf of Adam Nemet 
Date: Monday, February 26, 2018 at 9:51 PM
To: Shoaib Meenai 
Cc: Zachary Turner , "cfe-commits@lists.llvm.org" 
, Reid Kleckner 
Subject: Re: r326168 - Attempt to fix greendragon bot after r326141

Yep.


On Feb 26, 2018, at 9:50 PM, Shoaib Meenai 
mailto:smee...@fb.com>> wrote:

Reid re-committed r326141 this morning (and followed up with r326144), and I 
don't think either of those have been reverted?

From: Zachary Turner mailto:ztur...@google.com>>
Date: Monday, February 26, 2018 at 9:47 PM
To: Adam Nemet mailto:ane...@apple.com>>
Cc: Shoaib Meenai mailto:smee...@fb.com>>, 
"cfe-commits@lists.llvm.org" 
mailto:cfe-commits@lists.llvm.org>>, Reid Kleckner 
mailto:r...@google.com>>
Subject: Re: r326168 - Attempt to fix greendragon bot after r326141

I already reverted this a long time ago, but if Shoaib has a proper fix that 
would be great
On Mon, Feb 26, 2018 at 9:45 PM Adam Nemet 
mailto:ane...@apple.com>> wrote:
Ah, that should be sufficient.




On Feb 26, 2018, at 9:44 PM, Shoaib Meenai 
mailto:smee...@fb.com>> wrote:

Thanks. I'm building on macOS locally to confirm the original problem and my 
fix.

From: mailto:ane...@apple.com>> on behalf of Adam Nemet 
mailto:ane...@apple.com>>
Date: Monday, February 26, 2018 at 9:42 PM
To: Shoaib Meenai mailto:smee...@fb.com>>
Cc: "cfe-commits@lists.llvm.org" 
mailto:cfe-commits@lists.llvm.org>>, Reid Kleckner 
mailto:r...@google.com>>, Zachary Turner 
mailto:ztur...@google.com>>
Subject: Re: r326168 - Attempt to fix greendragon bot after r326141

This is the bot with the failure:

http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental/46794/#showFailuresLink

But to make matters worse, greendragon is experience some difficulty fetching 
from SVN so you might want to wait until things recover.  I am not sure if I 
will be able to get in touch with Mike Edwards until the morning PST.

There may also be llvm bots that exhibit the same problem.  You may have better 
luck with those in the short term.

Adam

On Feb 26, 2018, at 9:35 PM, Shoaib Meenai 
mailto:smee...@fb.com>> wrote:

Could you point me to the specific bot that was failing? I've dealt with that 
problem before, and it shouldn't be hard to fix, but I wanna monitor the bot 
after the fix to make sure it stays green.

From: mailto:ane...@apple.com>> on behalf of Adam Nemet 
mailto:ane...@apple.com>>
Date: Monday, February 26, 2018 at 9:30 PM
To: Shoaib Meenai mailto:smee...@fb.com>>
Cc: "cfe-commits@lists.llvm.org" 
mailto:cfe-commits@lists.llvm.org>>, Reid Kleckner 
mailto:r...@google.com>>, Zachary Turner 
mailto:ztur...@google.com>>
Subject: Re: r326168 - Attempt to fix greendragon bot after r326141

I don’t think we can deal with the slash options:

clang-7.0: warning: 
'/Users/buildslave/jenkins/workspace/apple-clang-master-RA-stage1-cmake-incremental/clang/src/tools/clang/test/Driver/codeview-column-info.c'
 treated as the '/U' option [-Wslash-u-filename]
clang-7.0: note: Use '--' to treat subsequent arguments as filenames
clang-7.0: warning: argument unused during compilation: '/Z7' 
[-Wunused-command-line-argument]
clang-7.0: warning: argument unused during compilation: ‘-U 
sers/buildslave/jenkins/workspace/apple-clang-master-RA-stage1-cmake-incremental/clang/src/tools/clang/test/Driver/codeview-column-info.c'
 [-Wunused-command-line-argument]

Anyhow as I said to Reid, feel free to improve the patch, I am just bringing 
back a bot that has been red for hours.

Adam



On Feb 26, 2018, at 9:22 PM, Shoaib Meenai 
mailto:smee...@fb.com>> wrote:

This seems bogus to me. CodeView can be generated on any build platform; it 
just needs the correct triple, which Reid added in r326144.

From: cfe-commits 
mailto:cfe-commits-boun...@lists.llvm.org>> 
on behalf of Adam Nemet via cfe-commits 
mailto:cfe-commits@lists.llvm.org>>
Reply-To: Adam Nemet mailto:ane...@apple.com>>
Date: Monday, February 26, 2018 at 8:51 PM
To: "cfe-commits@lists.llvm.org" 
mailto:cfe-commits@lists.llvm.org>>
Subject: r326168 - Attempt to fix greendragon bot after r326141

Author: anemet
Date: Mon Feb 26 20:49:26 2018
New Revision: 326168

URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D326168-26view-3Drev&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=B6WfLLVLbYMU_571sI0XgBTcOm561QyDCKF2UOJyc-k&s=oqoKnyrAT6kNwxIasdWb7eopGd0q41TFJ5Hxp_eoiZs&e=
Log:
Attempt to fix greendragon bot after r326141

Modified:
cfe/trunk/test/Driver/co

Re: r326168 - Attempt to fix greendragon bot after r326141

[Shoaib Meenai via cfe-commits]

Hmm. Reid had included a fix for compiler-rt in r326141, but that doesn't seem 
particularly relevant to this failure. In any case, I expect I'll receive 
emails when that bot is up and running again, and I can take a look then. (It 
didn't repro locally on Linux for me.)

From: Zachary Turner 
Date: Monday, February 26, 2018 at 10:36 PM
To: Adam Nemet 
Cc: Shoaib Meenai , "cfe-commits@lists.llvm.org" 
, Reid Kleckner 
Subject: Re: r326168 - Attempt to fix greendragon bot after r326141

So this doesn’t appear to fix the issue that led to my revert earlier.

http://lab.llvm.org:8011/builders/clang-cmake-x86_64-sde-avx512-linux/builds/6760

There’s no slashes in the command line that’s failing. However, this bot 
doesn’t seem to be updating and hasn’t pulled in this cl yet, but I expect it 
to fail again when it does
On Mon, Feb 26, 2018 at 10:27 PM Zachary Turner 
mailto:ztur...@google.com>> wrote:
Never mind, I didn’t realize Reid resubmitted my cl after I reverted it. In 
fact, I reverted it because of this greendragon failure which I wasn’t sure how 
to fix at the time
On Mon, Feb 26, 2018 at 10:12 PM Adam Nemet 
mailto:ane...@apple.com>> wrote:
BTW, I think that the LLVM bots have trouble accessing subversion too.  I 
already let Galina know.



On Feb 26, 2018, at 10:06 PM, Shoaib Meenai 
mailto:smee...@fb.com>> wrote:

r326171 works locally. I'll keep an eye on the bots.

From: mailto:ane...@apple.com>> on behalf of Adam Nemet 
mailto:ane...@apple.com>>
Date: Monday, February 26, 2018 at 9:51 PM
To: Shoaib Meenai mailto:smee...@fb.com>>
Cc: Zachary Turner mailto:ztur...@google.com>>, 
"cfe-commits@lists.llvm.org" 
mailto:cfe-commits@lists.llvm.org>>, Reid Kleckner 
mailto:r...@google.com>>
Subject: Re: r326168 - Attempt to fix greendragon bot after r326141

Yep.

On Feb 26, 2018, at 9:50 PM, Shoaib Meenai 
mailto:smee...@fb.com>> wrote:

Reid re-committed r326141 this morning (and followed up with r326144), and I 
don't think either of those have been reverted?

From: Zachary Turner mailto:ztur...@google.com>>
Date: Monday, February 26, 2018 at 9:47 PM
To: Adam Nemet mailto:ane...@apple.com>>
Cc: Shoaib Meenai mailto:smee...@fb.com>>, 
"cfe-commits@lists.llvm.org" 
mailto:cfe-commits@lists.llvm.org>>, Reid Kleckner 
mailto:r...@google.com>>
Subject: Re: r326168 - Attempt to fix greendragon bot after r326141

I already reverted this a long time ago, but if Shoaib has a proper fix that 
would be great
On Mon, Feb 26, 2018 at 9:45 PM Adam Nemet 
mailto:ane...@apple.com>> wrote:
Ah, that should be sufficient.



On Feb 26, 2018, at 9:44 PM, Shoaib Meenai 
mailto:smee...@fb.com>> wrote:

Thanks. I'm building on macOS locally to confirm the original problem and my 
fix.

From: mailto:ane...@apple.com>> on behalf of Adam Nemet 
mailto:ane...@apple.com>>
Date: Monday, February 26, 2018 at 9:42 PM
To: Shoaib Meenai mailto:smee...@fb.com>>
Cc: "cfe-commits@lists.llvm.org" 
mailto:cfe-commits@lists.llvm.org>>, Reid Kleckner 
mailto:r...@google.com>>, Zachary Turner 
mailto:ztur...@google.com>>
Subject: Re: r326168 - Attempt to fix greendragon bot after r326141

This is the bot with the failure:

http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental/46794/#showFailuresLink

But to make matters worse, greendragon is experience some difficulty fetching 
from SVN so you might want to wait until things recover.  I am not sure if I 
will be able to get in touch with Mike Edwards until the morning PST.

There may also be llvm bots that exhibit the same problem.  You may have better 
luck with those in the short term.

Adam

On Feb 26, 2018, at 9:35 PM, Shoaib Meenai 
mailto:smee...@fb.com>> wrote:

Could you point me to the specific bot that was failing? I've dealt with that 
problem before, and it shouldn't be hard to fix, but I wanna monitor the bot 
after the fix to make sure it stays green.

From: mailto:ane...@apple.com>> on behalf of Adam Nemet 
mailto:ane...@apple.com>>
Date: Monday, February 26, 2018 at 9:30 PM
To: Shoaib Meenai mailto:smee...@fb.com>>
Cc: "cfe-commits@lists.llvm.org" 
mailto:cfe-commits@lists.llvm.org>>, Reid Kleckner 
mailto:r...@google.com>>, Zachary Turner 
mailto:ztur...@google.com>>
Subject: Re: r326168 - Attempt to fix greendragon bot after r3261

r327892 - [CodeGen] Add funclet token to ARC marker

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Mon Mar 19 12:34:39 2018
New Revision: 327892

URL: http://llvm.org/viewvc/llvm-project?rev=327892&view=rev
Log:
[CodeGen] Add funclet token to ARC marker

The inline assembly generated for the ARC autorelease elision marker
must have a funclet token if it's emitted inside a funclet, otherwise
the inline assembly (and all subsequent code in the funclet) will be
marked unreachable. r324689 fixed this issue for regular inline assembly
blocks.

Note that clang only emits the marker at -O0, so this only fixes that
case. The optimizations case (where the marker is emitted by the
backend) will be fixed in a separate change.

Differential Revision: https://reviews.llvm.org/D44640

Added:
cfe/trunk/test/CodeGenObjCXX/arc-marker-funclet.mm
Modified:
cfe/trunk/lib/CodeGen/CGObjC.cpp

Modified: cfe/trunk/lib/CodeGen/CGObjC.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGObjC.cpp?rev=327892&r1=327891&r2=327892&view=diff
==
--- cfe/trunk/lib/CodeGen/CGObjC.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGObjC.cpp Mon Mar 19 12:34:39 2018
@@ -2034,7 +2034,7 @@ static void emitAutoreleasedReturnValueM
 
   // Call the marker asm if we made one, which we do only at -O0.
   if (marker)
-CGF.Builder.CreateCall(marker);
+CGF.Builder.CreateCall(marker, None, CGF.getBundlesForFunclet(marker));
 }
 
 /// Retain the given object which is the result of a function call.

Added: cfe/trunk/test/CodeGenObjCXX/arc-marker-funclet.mm
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenObjCXX/arc-marker-funclet.mm?rev=327892&view=auto
==
--- cfe/trunk/test/CodeGenObjCXX/arc-marker-funclet.mm (added)
+++ cfe/trunk/test/CodeGenObjCXX/arc-marker-funclet.mm Mon Mar 19 12:34:39 2018
@@ -0,0 +1,17 @@
+// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fobjc-runtime=ios-6.0 
-fobjc-arc \
+// RUN:   -fexceptions -fcxx-exceptions -emit-llvm -o - %s | FileCheck %s
+
+id f();
+void g() {
+  try {
+f();
+  } catch (...) {
+f();
+  }
+}
+
+// CHECK: call i8* @"?f@@YAPAUobjc_object@@XZ"() [ "funclet"(token %1) ]
+// CHECK-NEXT: call void asm sideeffect "movl{{.*}}%ebp, %ebp{{.*}}", ""() [ 
"funclet"(token %1) ]
+
+// The corresponding f() call was invoked from the entry basic block.
+// CHECK: call void asm sideeffect "movl{{.*}}%ebp, %ebp{{.*}}", ""(){{$}}


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

r333808 - [cmake] Use LLVM's check_linker_flag

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Fri Jun  1 17:49:54 2018
New Revision: 333808

URL: http://llvm.org/viewvc/llvm-project?rev=333808&view=rev
Log:
[cmake] Use LLVM's check_linker_flag

LLVM already defines this function, so make use of it instead of rolling
our own.

Modified:
cfe/trunk/tools/driver/CMakeLists.txt

Modified: cfe/trunk/tools/driver/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/driver/CMakeLists.txt?rev=333808&r1=333807&r2=333808&view=diff
==
--- cfe/trunk/tools/driver/CMakeLists.txt (original)
+++ cfe/trunk/tools/driver/CMakeLists.txt Fri Jun  1 17:49:54 2018
@@ -99,14 +99,7 @@ if (APPLE)
 endif()
 
 if(CLANG_ORDER_FILE AND (LD64_EXECUTABLE OR GOLD_EXECUTABLE))
-  include(CMakePushCheckState)
-
-  function(check_linker_flag flag out_var)
-cmake_push_check_state()
-set(CMAKE_REQUIRED_FLAGS "${CMAKE_REQUIRED_FLAGS} ${flag}")
-check_cxx_compiler_flag("" ${out_var})
-cmake_pop_check_state()
-  endfunction()
+  include(CheckLinkerFlag)
 
   if (LD64_EXECUTABLE)
 set(LINKER_ORDER_FILE_OPTION "-Wl,-order_file,${CLANG_ORDER_FILE}")


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

r333810 - [cmake] Support LLD for CLANG_ORDER_FILE

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Fri Jun  1 18:22:39 2018
New Revision: 333810

URL: http://llvm.org/viewvc/llvm-project?rev=333810&view=rev
Log:
[cmake] Support LLD for CLANG_ORDER_FILE

LLD also supports order files using the `--symbol-ordering-file` option.
As the name would suggest, the order file format is slightly different
from gold; gold's order files specify section names, whereas LLD's
specify symbol names. Assuming you have an order file in the correct
format though, we should support using it with LLD.

Switch the check to actually use LLVM's linker detection rather than
just checking for the presence of the gold executable, since we might
have a gold executable present but be using LLD (or bfd for that matter)
as our linker.

Differential Revision: https://reviews.llvm.org/D47669

Modified:
cfe/trunk/tools/driver/CMakeLists.txt

Modified: cfe/trunk/tools/driver/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/driver/CMakeLists.txt?rev=333810&r1=333809&r2=333810&view=diff
==
--- cfe/trunk/tools/driver/CMakeLists.txt (original)
+++ cfe/trunk/tools/driver/CMakeLists.txt Fri Jun  1 18:22:39 2018
@@ -98,13 +98,16 @@ if (APPLE)
   set(TOOL_INFO_BUILD_VERSION)
 endif()
 
-if(CLANG_ORDER_FILE AND (LD64_EXECUTABLE OR GOLD_EXECUTABLE))
+if(CLANG_ORDER_FILE AND
+   (LD64_EXECUTABLE OR LLVM_LINKER_IS_GOLD OR LLVM_LINKER_IS_LLD))
   include(CheckLinkerFlag)
 
   if (LD64_EXECUTABLE)
 set(LINKER_ORDER_FILE_OPTION "-Wl,-order_file,${CLANG_ORDER_FILE}")
-  elseif (GOLD_EXECUTABLE)
+  elseif (LLVM_LINKER_IS_GOLD)
 set(LINKER_ORDER_FILE_OPTION 
"-Wl,--section-ordering-file,${CLANG_ORDER_FILE}")
+  elseif (LLVM_LINKER_IS_LLD)
+set(LINKER_ORDER_FILE_OPTION 
"-Wl,--symbol-ordering-file,${CLANG_ORDER_FILE}")
   endif()
 
   # This is a test to ensure the actual order file works with the linker.


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

r334145 - [Driver] Stop passing -fseh-exceptions for x86_64-windows-msvc

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Wed Jun  6 16:09:02 2018
New Revision: 334145

URL: http://llvm.org/viewvc/llvm-project?rev=334145&view=rev
Log:
[Driver] Stop passing -fseh-exceptions for x86_64-windows-msvc

-fseh-exceptions is only meaningful for MinGW targets, and that driver
already has logic to pass either -fdwarf-exceptions or -fseh-exceptions
as appropriate. -fseh-exceptions is just a no-op for MSVC triples, and
passing it to cc1 causes unnecessary confusion.

Differential Revision: https://reviews.llvm.org/D47850

Added:
cfe/trunk/test/Driver/windows-exceptions.cpp
Modified:
cfe/trunk/lib/Driver/ToolChain.cpp

Modified: cfe/trunk/lib/Driver/ToolChain.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChain.cpp?rev=334145&r1=334144&r2=334145&view=diff
==
--- cfe/trunk/lib/Driver/ToolChain.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChain.cpp Wed Jun  6 16:09:02 2018
@@ -471,8 +471,6 @@ ObjCRuntime ToolChain::getDefaultObjCRun
 
 llvm::ExceptionHandling
 ToolChain::GetExceptionModel(const llvm::opt::ArgList &Args) const {
-  if (Triple.isOSWindows() && Triple.getArch() != llvm::Triple::x86)
-return llvm::ExceptionHandling::WinEH;
   return llvm::ExceptionHandling::None;
 }
 

Added: cfe/trunk/test/Driver/windows-exceptions.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/windows-exceptions.cpp?rev=334145&view=auto
==
--- cfe/trunk/test/Driver/windows-exceptions.cpp (added)
+++ cfe/trunk/test/Driver/windows-exceptions.cpp Wed Jun  6 16:09:02 2018
@@ -0,0 +1,9 @@
+// RUN: %clang -target i686-windows-msvc -c %s -### 2>&1 | FileCheck 
-check-prefix=MSVC %s
+// RUN: %clang -target x86_64-windows-msvc -c %s -### 2>&1 | FileCheck 
-check-prefix=MSVC %s
+// RUN: %clang -target i686-windows-gnu -c %s -### 2>&1 | FileCheck 
-check-prefix=MINGW-DWARF %s
+// RUN: %clang -target x86_64-windows-gnu -c %s -### 2>&1 | FileCheck 
-check-prefix=MINGW-SEH %s
+
+MSVC-NOT: -fdwarf-exceptions
+MSVC-NOT: -fseh-exceptions
+MINGW-DWARF: -fdwarf-exceptions
+MINGW-SEH: -fseh-exceptions


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

r334224 - [Parse] Use CapturedStmt for @finally on MSVC

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Thu Jun  7 13:07:52 2018
New Revision: 334224

URL: http://llvm.org/viewvc/llvm-project?rev=334224&view=rev
Log:
[Parse] Use CapturedStmt for @finally on MSVC

The body of a `@finally` needs to be executed on both exceptional and
non-exceptional paths. On landingpad platforms, this is straightforward:
the `@finally` body is emitted as a normal (non-exceptional) cleanup,
and then a catch-all is emitted which branches to that cleanup (the
cleanup has code to conditionally re-throw based on a flag which is set
by the catch-all).

Unfortunately, we can't use the same approach for MSVC exceptions, where
the catch-all will be emitted as a catchpad. We can't just branch to the
cleanup from within the catchpad, since we can only exit it via a
catchret, at which point the exception is destroyed and we can't
rethrow. We could potentially emit the finally body inside the catchpad
and have the normal cleanup path somehow branch into it, but that would
require some new IR construct that could branch into a catchpad.

Instead, after discussing it with Reid Kleckner, we decided that
frontend outlining was the best approach, similar to how SEH `__finally`
works today. We decided to use CapturedStmt (which was also suggested by
Reid) rather than CaptureFinder (which is what `__finally` uses) since
the latter doesn't handle a lot of cases we care about, e.g. self
accesses, property accesses, block captures, etc. Extending
CaptureFinder to handle those additional cases proved unwieldy, whereas
CapturedStmt already took care of all of those.  In theory `__finally`
could also be moved over to CapturedStmt, which would remove some
existing limitations (e.g. the inability to capture this), although
CaptureFinder would still be needed for SEH filters.

The one case supported by `@finally` but not CapturedStmt (or
CaptureFinder for that matter) is arbitrary control flow out of the
`@finally`, e.g. having a return statement inside a `@finally`. We can
add that support as a follow-up, but in practice we've found it to be
used very rarely anyway.

Differential Revision: https://reviews.llvm.org/D47564

Added:
cfe/trunk/test/SemaObjC/finally-msvc.m
Modified:
cfe/trunk/include/clang/AST/Stmt.h
cfe/trunk/include/clang/Basic/CapturedStmt.h
cfe/trunk/include/clang/Sema/ScopeInfo.h
cfe/trunk/lib/Parse/ParseObjc.cpp

Modified: cfe/trunk/include/clang/AST/Stmt.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Stmt.h?rev=334224&r1=334223&r2=334224&view=diff
==
--- cfe/trunk/include/clang/AST/Stmt.h (original)
+++ cfe/trunk/include/clang/AST/Stmt.h Thu Jun  7 13:07:52 2018
@@ -2133,7 +2133,7 @@ private:
 
   /// The pointer part is the implicit the outlined function and the 
   /// int part is the captured region kind, 'CR_Default' etc.
-  llvm::PointerIntPair CapDeclAndKind;
+  llvm::PointerIntPair CapDeclAndKind;
 
   /// The record for captured variables, a RecordDecl or CXXRecordDecl.
   RecordDecl *TheRecordDecl = nullptr;

Modified: cfe/trunk/include/clang/Basic/CapturedStmt.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/CapturedStmt.h?rev=334224&r1=334223&r2=334224&view=diff
==
--- cfe/trunk/include/clang/Basic/CapturedStmt.h (original)
+++ cfe/trunk/include/clang/Basic/CapturedStmt.h Thu Jun  7 13:07:52 2018
@@ -16,6 +16,7 @@ namespace clang {
 /// The different kinds of captured statement.
 enum CapturedRegionKind {
   CR_Default,
+  CR_ObjCAtFinally,
   CR_OpenMP
 };
 

Modified: cfe/trunk/include/clang/Sema/ScopeInfo.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/ScopeInfo.h?rev=334224&r1=334223&r2=334224&view=diff
==
--- cfe/trunk/include/clang/Sema/ScopeInfo.h (original)
+++ cfe/trunk/include/clang/Sema/ScopeInfo.h Thu Jun  7 13:07:52 2018
@@ -748,6 +748,8 @@ public:
 switch (CapRegionKind) {
 case CR_Default:
   return "default captured statement";
+case CR_ObjCAtFinally:
+  return "Objective-C @finally statement";
 case CR_OpenMP:
   return "OpenMP region";
 }

Modified: cfe/trunk/lib/Parse/ParseObjc.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/ParseObjc.cpp?rev=334224&r1=334223&r2=334224&view=diff
==
--- cfe/trunk/lib/Parse/ParseObjc.cpp (original)
+++ cfe/trunk/lib/Parse/ParseObjc.cpp Thu Jun  7 13:07:52 2018
@@ -2585,13 +2585,26 @@ StmtResult Parser::ParseObjCTryStmt(Sour
   ParseScope FinallyScope(this,
   Scope::DeclScope | Scope::CompoundStmtScope);
 
+  bool ShouldCapture =
+  getTargetInfo().getTriple().isWindowsMSVCEnvironment();
+  if (ShouldCapture)
+Actions.ActOnCapturedRegionStart(Tok.getLocation

r334240 - Revert "[Parse] Use CapturedStmt for @finally on MSVC"

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Thu Jun  7 15:24:20 2018
New Revision: 334240

URL: http://llvm.org/viewvc/llvm-project?rev=334240&view=rev
Log:
Revert "[Parse] Use CapturedStmt for @finally on MSVC"

This reverts commit r334224.

This is causing buildbot failures on Windows, presumably because some
tests don't specify a triple. I'll test this on Windows locally and
recommit with the tests fixed.

Removed:
cfe/trunk/test/SemaObjC/finally-msvc.m
Modified:
cfe/trunk/include/clang/AST/Stmt.h
cfe/trunk/include/clang/Basic/CapturedStmt.h
cfe/trunk/include/clang/Sema/ScopeInfo.h
cfe/trunk/lib/Parse/ParseObjc.cpp

Modified: cfe/trunk/include/clang/AST/Stmt.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Stmt.h?rev=334240&r1=334239&r2=334240&view=diff
==
--- cfe/trunk/include/clang/AST/Stmt.h (original)
+++ cfe/trunk/include/clang/AST/Stmt.h Thu Jun  7 15:24:20 2018
@@ -2133,7 +2133,7 @@ private:
 
   /// The pointer part is the implicit the outlined function and the 
   /// int part is the captured region kind, 'CR_Default' etc.
-  llvm::PointerIntPair CapDeclAndKind;
+  llvm::PointerIntPair CapDeclAndKind;
 
   /// The record for captured variables, a RecordDecl or CXXRecordDecl.
   RecordDecl *TheRecordDecl = nullptr;

Modified: cfe/trunk/include/clang/Basic/CapturedStmt.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/CapturedStmt.h?rev=334240&r1=334239&r2=334240&view=diff
==
--- cfe/trunk/include/clang/Basic/CapturedStmt.h (original)
+++ cfe/trunk/include/clang/Basic/CapturedStmt.h Thu Jun  7 15:24:20 2018
@@ -16,7 +16,6 @@ namespace clang {
 /// The different kinds of captured statement.
 enum CapturedRegionKind {
   CR_Default,
-  CR_ObjCAtFinally,
   CR_OpenMP
 };
 

Modified: cfe/trunk/include/clang/Sema/ScopeInfo.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/ScopeInfo.h?rev=334240&r1=334239&r2=334240&view=diff
==
--- cfe/trunk/include/clang/Sema/ScopeInfo.h (original)
+++ cfe/trunk/include/clang/Sema/ScopeInfo.h Thu Jun  7 15:24:20 2018
@@ -748,8 +748,6 @@ public:
 switch (CapRegionKind) {
 case CR_Default:
   return "default captured statement";
-case CR_ObjCAtFinally:
-  return "Objective-C @finally statement";
 case CR_OpenMP:
   return "OpenMP region";
 }

Modified: cfe/trunk/lib/Parse/ParseObjc.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/ParseObjc.cpp?rev=334240&r1=334239&r2=334240&view=diff
==
--- cfe/trunk/lib/Parse/ParseObjc.cpp (original)
+++ cfe/trunk/lib/Parse/ParseObjc.cpp Thu Jun  7 15:24:20 2018
@@ -2585,26 +2585,13 @@ StmtResult Parser::ParseObjCTryStmt(Sour
   ParseScope FinallyScope(this,
   Scope::DeclScope | Scope::CompoundStmtScope);
 
-  bool ShouldCapture =
-  getTargetInfo().getTriple().isWindowsMSVCEnvironment();
-  if (ShouldCapture)
-Actions.ActOnCapturedRegionStart(Tok.getLocation(), getCurScope(),
- CR_ObjCAtFinally, 1);
-
   StmtResult FinallyBody(true);
   if (Tok.is(tok::l_brace))
 FinallyBody = ParseCompoundStatementBody();
   else
 Diag(Tok, diag::err_expected) << tok::l_brace;
-
-  if (FinallyBody.isInvalid()) {
+  if (FinallyBody.isInvalid())
 FinallyBody = Actions.ActOnNullStmt(Tok.getLocation());
-if (ShouldCapture)
-  Actions.ActOnCapturedRegionError();
-  } else if (ShouldCapture) {
-FinallyBody = Actions.ActOnCapturedRegionEnd(FinallyBody.get());
-  }
-
   FinallyStmt = Actions.ActOnObjCAtFinallyStmt(AtCatchFinallyLoc,
FinallyBody.get());
   catch_or_finally_seen = true;

Removed: cfe/trunk/test/SemaObjC/finally-msvc.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaObjC/finally-msvc.m?rev=334239&view=auto
==
--- cfe/trunk/test/SemaObjC/finally-msvc.m (original)
+++ cfe/trunk/test/SemaObjC/finally-msvc.m (removed)
@@ -1,14 +0,0 @@
-// RUN: %clang_cc1 -triple i686--windows-msvc -fexceptions -fobjc-exceptions 
-ast-dump %s 2>&1 | FileCheck %s
-// RUN: %clang_cc1 -triple x86_64--windows-msvc -fexceptions -fobjc-exceptions 
-ast-dump %s 2>&1 | FileCheck %s
-
-void f() {
-  @try {
-  } @finally {
-  }
-}
-
-// CHECK:  ObjCAtFinallyStmt
-// CHECK-NEXT:   CapturedStmt
-// CHECK-NEXT: CapturedDecl
-// CHECK-NEXT:   CompoundStmt
-// CHECK-NEXT:   ImplicitParamDecl


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

r334243 - [Frontend] Disallow non-MSVC exception models for windows-msvc targets

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Thu Jun  7 15:54:54 2018
New Revision: 334243

URL: http://llvm.org/viewvc/llvm-project?rev=334243&view=rev
Log:
[Frontend] Disallow non-MSVC exception models for windows-msvc targets

The windows-msvc target is used for MSVC ABI compatibility, including
the exceptions model. It doesn't make sense to pair a windows-msvc
target with a non-MSVC exception model. This would previously cause an
assertion failure; explicitly error out for it in the frontend instead.
This also allows us to reduce the matrix of target/exception models a
bit (see the modified tests), and we can possibly simplify some of the
personality code in a follow-up.

Differential Revision: https://reviews.llvm.org/D47853

Added:
cfe/trunk/test/Frontend/windows-exceptions.cpp
Removed:
cfe/trunk/test/CodeGenCXX/ms-eh-personality.cpp
Modified:
cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
cfe/trunk/lib/Frontend/CompilerInvocation.cpp
cfe/trunk/test/CodeGen/personality.c
cfe/trunk/test/CodeGenCXX/personality.cpp
cfe/trunk/test/CodeGenObjC/personality.m
cfe/trunk/test/CodeGenObjCXX/personality.mm

Modified: cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td?rev=334243&r1=334242&r2=334243&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td Thu Jun  7 
15:54:54 2018
@@ -118,6 +118,8 @@ def err_fe_invalid_alignment : Error<
 "invalid value '%1' in '%0'; alignment must be a power of 2">;
 def err_fe_invalid_wchar_type
 : Error<"invalid wchar_t type '%0'; must be one of 'char', 'short', 
'int'">;
+def err_fe_invalid_exception_model
+   : Error<"invalid exception model '%0' for target '%1'">;
 
 def warn_fe_serialized_diag_merge_failure : Warning<
 "unable to merge a subprocess's serialized diagnostics">,

Modified: cfe/trunk/lib/Frontend/CompilerInvocation.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/CompilerInvocation.cpp?rev=334243&r1=334242&r2=334243&view=diff
==
--- cfe/trunk/lib/Frontend/CompilerInvocation.cpp (original)
+++ cfe/trunk/lib/Frontend/CompilerInvocation.cpp Thu Jun  7 15:54:54 2018
@@ -2344,6 +2344,11 @@ static void ParseLangArgs(LangOptions &O
options::OPT_fdwarf_exceptions);
   if (A) {
 const Option &Opt = A->getOption();
+llvm::Triple T(TargetOpts.Triple);
+if (T.isWindowsMSVCEnvironment())
+  Diags.Report(diag::err_fe_invalid_exception_model)
+  << Opt.getName() << T.str();
+
 Opts.SjLjExceptions = Opt.matches(options::OPT_fsjlj_exceptions);
 Opts.SEHExceptions = Opt.matches(options::OPT_fseh_exceptions);
 Opts.DWARFExceptions = Opt.matches(options::OPT_fdwarf_exceptions);

Modified: cfe/trunk/test/CodeGen/personality.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/personality.c?rev=334243&r1=334242&r2=334243&view=diff
==
--- cfe/trunk/test/CodeGen/personality.c (original)
+++ cfe/trunk/test/CodeGen/personality.c Thu Jun  7 15:54:54 2018
@@ -4,13 +4,13 @@
 // RUN: %clang_cc1 -triple i686-unknown-linux-gnu -fexceptions 
-fsjlj-exceptions -fblocks -S -emit-llvm %s -o - | FileCheck %s -check-prefix 
CHECK-SJLJ
 
 // RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fblocks -S 
-emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-WIN
-// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions 
-fdwarf-exceptions -fblocks -S -emit-llvm %s -o - | FileCheck %s -check-prefix 
CHECK-WIN-DWARF
-// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -D __SEH_EXCEPTIONS__ 
-fms-extensions -fexceptions -fblocks -fseh-exceptions -S -emit-llvm %s -o - | 
FileCheck %s -check-prefix CHECK-WIN-SEH -check-prefix CHECK-WIN-SEH-X86
-// RUN: %clang_cc1 -triple x86_64-unknown-windows-msvc -D __SEH_EXCEPTIONS__ 
-fms-extensions -fexceptions -fblocks -fseh-exceptions -S -emit-llvm %s -o - | 
FileCheck %s -check-prefix CHECK-WIN-SEH -check-prefix CHECK-WIN-SEH-X64
-// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fblocks 
-fsjlj-exceptions -S -emit-llvm %s -o - | FileCheck %s -check-prefix 
CHECK-WIN-SJLJ
+// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -D __SEH_EXCEPTIONS__ 
-fms-extensions -fexceptions -fblocks -S -emit-llvm %s -o - | FileCheck %s 
-check-prefix CHECK-WIN-SEH-X86
+// RUN: %clang_cc1 -triple x86_64-unknown-windows-msvc -D __SEH_EXCEPTIONS__ 
-fms-extensions -fexceptions -fblocks -S -emit-llvm %s -o - | FileCheck %s 
-check-prefix CHECK-WIN-SEH-X64
 
-// RUN: %clang_cc1 -triple i686-unknown-windows-gnu -D __SEH_EXCEPTIONS__ 
-fms-extensions -fexceptions -fblocks -fseh-exceptions -S -emit-llvm %s 

r334251 - Reapply "[Parse] Use CapturedStmt for @finally on MSVC"

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Thu Jun  7 17:30:00 2018
New Revision: 334251

URL: http://llvm.org/viewvc/llvm-project?rev=334251&view=rev
Log:
Reapply "[Parse] Use CapturedStmt for @finally on MSVC"

This reapplies r334224 and adds explicit triples to some tests to fix
them on Windows (where otherwise they would have run with the default
windows-msvc triple, which I'm changing the behavior for).

Original commit message:
The body of a `@finally` needs to be executed on both exceptional and
non-exceptional paths. On landingpad platforms, this is straightforward:
the `@finally` body is emitted as a normal (non-exceptional) cleanup,
and then a catch-all is emitted which branches to that cleanup (the
cleanup has code to conditionally re-throw based on a flag which is set
by the catch-all).

Unfortunately, we can't use the same approach for MSVC exceptions, where
the catch-all will be emitted as a catchpad. We can't just branch to the
cleanup from within the catchpad, since we can only exit it via a
catchret, at which point the exception is destroyed and we can't
rethrow. We could potentially emit the finally body inside the catchpad
and have the normal cleanup path somehow branch into it, but that would
require some new IR construct that could branch into a catchpad.

Instead, after discussing it with Reid Kleckner, we decided that
frontend outlining was the best approach, similar to how SEH `__finally`
works today. We decided to use CapturedStmt (which was also suggested by
Reid) rather than CaptureFinder (which is what `__finally` uses) since
the latter doesn't handle a lot of cases we care about, e.g. self
accesses, property accesses, block captures, etc. Extending
CaptureFinder to handle those additional cases proved unwieldy, whereas
CapturedStmt already took care of all of those.  In theory `__finally`
could also be moved over to CapturedStmt, which would remove some
existing limitations (e.g. the inability to capture this), although
CaptureFinder would still be needed for SEH filters.

The one case supported by `@finally` but not CapturedStmt (or
CaptureFinder for that matter) is arbitrary control flow out of the
`@finally`, e.g. having a return statement inside a `@finally`. We can
add that support as a follow-up, but in practice we've found it to be
used very rarely anyway.

Differential Revision: https://reviews.llvm.org/D47564

Added:
cfe/trunk/test/SemaObjC/finally-msvc.m
Modified:
cfe/trunk/include/clang/AST/Stmt.h
cfe/trunk/include/clang/Basic/CapturedStmt.h
cfe/trunk/include/clang/Sema/ScopeInfo.h
cfe/trunk/lib/Parse/ParseObjc.cpp
cfe/trunk/test/Coverage/ast-printing.m
cfe/trunk/test/PCH/objc_stmts.m
cfe/trunk/test/Parser/objc-try-catch-1.m
cfe/trunk/test/Rewriter/rewrite-modern-try-finally.m
cfe/trunk/test/SemaObjC/scope-check.m

Modified: cfe/trunk/include/clang/AST/Stmt.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Stmt.h?rev=334251&r1=334250&r2=334251&view=diff
==
--- cfe/trunk/include/clang/AST/Stmt.h (original)
+++ cfe/trunk/include/clang/AST/Stmt.h Thu Jun  7 17:30:00 2018
@@ -2133,7 +2133,7 @@ private:
 
   /// The pointer part is the implicit the outlined function and the 
   /// int part is the captured region kind, 'CR_Default' etc.
-  llvm::PointerIntPair CapDeclAndKind;
+  llvm::PointerIntPair CapDeclAndKind;
 
   /// The record for captured variables, a RecordDecl or CXXRecordDecl.
   RecordDecl *TheRecordDecl = nullptr;

Modified: cfe/trunk/include/clang/Basic/CapturedStmt.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/CapturedStmt.h?rev=334251&r1=334250&r2=334251&view=diff
==
--- cfe/trunk/include/clang/Basic/CapturedStmt.h (original)
+++ cfe/trunk/include/clang/Basic/CapturedStmt.h Thu Jun  7 17:30:00 2018
@@ -16,6 +16,7 @@ namespace clang {
 /// The different kinds of captured statement.
 enum CapturedRegionKind {
   CR_Default,
+  CR_ObjCAtFinally,
   CR_OpenMP
 };
 

Modified: cfe/trunk/include/clang/Sema/ScopeInfo.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/ScopeInfo.h?rev=334251&r1=334250&r2=334251&view=diff
==
--- cfe/trunk/include/clang/Sema/ScopeInfo.h (original)
+++ cfe/trunk/include/clang/Sema/ScopeInfo.h Thu Jun  7 17:30:00 2018
@@ -748,6 +748,8 @@ public:
 switch (CapRegionKind) {
 case CR_Default:
   return "default captured statement";
+case CR_ObjCAtFinally:
+  return "Objective-C @finally statement";
 case CR_OpenMP:
   return "OpenMP region";
 }

Modified: cfe/trunk/lib/Parse/ParseObjc.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/ParseObjc.cpp?rev=334251&r1=334250&r2=334251&view=diff
==
--- cfe/trunk

r334253 - [CodeGen] Always use MSVC personality for windows-msvc targets

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Thu Jun  7 17:41:01 2018
New Revision: 334253

URL: http://llvm.org/viewvc/llvm-project?rev=334253&view=rev
Log:
[CodeGen] Always use MSVC personality for windows-msvc targets

The windows-msvc target is meant to be ABI compatible with MSVC,
including the exception handling. Ensure that a windows-msvc triple
always equates to the MSVC personality being used.

This mostly affects the GNUStep and ObjFW Obj-C runtimes. To the best of
my knowledge, those are normally not used with windows-msvc triples. I
believe WinObjC is based on GNUStep (or it at least uses libobjc2), but
that also takes the approach of wrapping Obj-C exceptions in C++
exceptions, so the MSVC personality function is the right one to use
there as well.

Differential Revision: https://reviews.llvm.org/D47862

Modified:
cfe/trunk/lib/CodeGen/CGException.cpp
cfe/trunk/test/CodeGenObjC/personality.m
cfe/trunk/test/CodeGenObjCXX/personality.mm

Modified: cfe/trunk/lib/CodeGen/CGException.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGException.cpp?rev=334253&r1=334252&r2=334253&view=diff
==
--- cfe/trunk/lib/CodeGen/CGException.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGException.cpp Thu Jun  7 17:41:01 2018
@@ -117,12 +117,12 @@ EHPersonality::GNU_Wasm_CPlusPlus = { "_
 static const EHPersonality &getCPersonality(const TargetInfo &Target,
 const LangOptions &L) {
   const llvm::Triple &T = Target.getTriple();
+  if (T.isWindowsMSVCEnvironment())
+return EHPersonality::MSVC_CxxFrameHandler3;
   if (L.SjLjExceptions)
 return EHPersonality::GNU_C_SJLJ;
   if (L.DWARFExceptions)
 return EHPersonality::GNU_C;
-  if (T.isWindowsMSVCEnvironment())
-return EHPersonality::MSVC_CxxFrameHandler3;
   if (L.SEHExceptions)
 return EHPersonality::GNU_C_SEH;
   return EHPersonality::GNU_C;
@@ -131,14 +131,15 @@ static const EHPersonality &getCPersonal
 static const EHPersonality &getObjCPersonality(const TargetInfo &Target,
const LangOptions &L) {
   const llvm::Triple &T = Target.getTriple();
+  if (T.isWindowsMSVCEnvironment())
+return EHPersonality::MSVC_CxxFrameHandler3;
+
   switch (L.ObjCRuntime.getKind()) {
   case ObjCRuntime::FragileMacOSX:
 return getCPersonality(Target, L);
   case ObjCRuntime::MacOSX:
   case ObjCRuntime::iOS:
   case ObjCRuntime::WatchOS:
-if (T.isWindowsMSVCEnvironment())
-  return EHPersonality::MSVC_CxxFrameHandler3;
 return EHPersonality::NeXT_ObjC;
   case ObjCRuntime::GNUstep:
 if (L.ObjCRuntime.getVersion() >= VersionTuple(1, 7))
@@ -158,12 +159,12 @@ static const EHPersonality &getObjCPerso
 static const EHPersonality &getCXXPersonality(const TargetInfo &Target,
   const LangOptions &L) {
   const llvm::Triple &T = Target.getTriple();
+  if (T.isWindowsMSVCEnvironment())
+return EHPersonality::MSVC_CxxFrameHandler3;
   if (L.SjLjExceptions)
 return EHPersonality::GNU_CPlusPlus_SJLJ;
   if (L.DWARFExceptions)
 return EHPersonality::GNU_CPlusPlus;
-  if (T.isWindowsMSVCEnvironment())
-return EHPersonality::MSVC_CxxFrameHandler3;
   if (L.SEHExceptions)
 return EHPersonality::GNU_CPlusPlus_SEH;
   // Wasm EH is a non-MVP feature for now.
@@ -178,6 +179,9 @@ static const EHPersonality &getCXXPerson
 /// and Objective-C exceptions are being caught.
 static const EHPersonality &getObjCXXPersonality(const TargetInfo &Target,
  const LangOptions &L) {
+  if (Target.getTriple().isWindowsMSVCEnvironment())
+return EHPersonality::MSVC_CxxFrameHandler3;
+
   switch (L.ObjCRuntime.getKind()) {
   // In the fragile ABI, just use C++ exception handling and hope
   // they're not doing crazy exception mixing.

Modified: cfe/trunk/test/CodeGenObjC/personality.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenObjC/personality.m?rev=334253&r1=334252&r2=334253&view=diff
==
--- cfe/trunk/test/CodeGenObjC/personality.m (original)
+++ cfe/trunk/test/CodeGenObjC/personality.m Thu Jun  7 17:41:01 2018
@@ -11,14 +11,14 @@
 // RUN: %clang_cc1 -triple i686-unknown-linux-gnu -fexceptions 
-fseh-exceptions -fobjc-exceptions -fobjc-runtime=objfw -S -emit-llvm %s -o - | 
FileCheck %s -check-prefix CHECK-OBJFW-SEH
 // RUN: %clang_cc1 -triple i686-unknown-linux-gnu -fexceptions 
-fsjlj-exceptions -fobjc-exceptions -fobjc-runtime=objfw -S -emit-llvm %s -o - 
| FileCheck %s -check-prefix CHECK-OBJFW-SJLJ
 
-// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions 
-fobjc-exceptions -fobjc-runtime=macosx-fragile -S -emit-llvm %s -o - | 
FileCheck %s -check-prefix CHECK-WIN-MACOSX-FRAGILE
-// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions 
-fobjc-exceptions -fobjc-runt

r334780 - [cmake] Add linker detection for Apple platforms

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Thu Jun 14 16:26:33 2018
New Revision: 334780

URL: http://llvm.org/viewvc/llvm-project?rev=334780&view=rev
Log:
[cmake] Add linker detection for Apple platforms

LLVM currently assumes that Apple platforms will always use ld64. In the
future, LLD Mach-O might also be supported, so add the beginnings of
linker detection support. ld64 is currently the only detected linker,
since `ld64.lld -v` doesn't yield any useful version output, but we can
add that detection later, and in the meantime it's still useful to have
the ld64 identification.

Switch clang's order file check to use this new detection rather than
just checking for the presence of an ld64 executable.

Differential Revision: https://reviews.llvm.org/D48201

Modified:
cfe/trunk/tools/driver/CMakeLists.txt

Modified: cfe/trunk/tools/driver/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/driver/CMakeLists.txt?rev=334780&r1=334779&r2=334780&view=diff
==
--- cfe/trunk/tools/driver/CMakeLists.txt (original)
+++ cfe/trunk/tools/driver/CMakeLists.txt Thu Jun 14 16:26:33 2018
@@ -99,10 +99,10 @@ if (APPLE)
 endif()
 
 if(CLANG_ORDER_FILE AND
-   (LD64_EXECUTABLE OR LLVM_LINKER_IS_GOLD OR LLVM_LINKER_IS_LLD))
+(LLVM_LINKER_IS_LD64 OR LLVM_LINKER_IS_GOLD OR LLVM_LINKER_IS_LLD))
   include(CheckLinkerFlag)
 
-  if (LD64_EXECUTABLE)
+  if (LLVM_LINKER_IS_LD64)
 set(LINKER_ORDER_FILE_OPTION "-Wl,-order_file,${CLANG_ORDER_FILE}")
   elseif (LLVM_LINKER_IS_GOLD)
 set(LINKER_ORDER_FILE_OPTION 
"-Wl,--section-ordering-file,${CLANG_ORDER_FILE}")


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

Re: r345803 - Fix regression in behavior of clang -x c++-header -fmodule-name=XXX

[Shoaib Meenai via cfe-commits]

Comment inline (Outlook handles quoting terribly, so I'm not sure how much 
it'll end up standing out, but I believe you typo'd "preprocessor" as " 
prepreocssor").

From: cfe-commits  on behalf of Richard 
Smith via cfe-commits 
Reply-To: Richard Smith 
Date: Wednesday, October 31, 2018 at 5:49 PM
To: "cfe-commits@lists.llvm.org" 
Subject: r345803 - Fix regression in behavior of clang -x c++-header 
-fmodule-name=XXX

Author: rsmith
Date: Wed Oct 31 17:46:54 2018
New Revision: 345803

URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D345803-26view-3Drev&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=fuhDqKU4xiQGQizq6Oszj5RJTGnnRK6S35y0Pk_bRcg&s=xpyBxlufGiJ3htehnYAB4PVF1WQvpPF9AR-tGM8UMfQ&e=
Log:
Fix regression in behavior of clang -x c++-header -fmodule-name=XXX
-fsyntax-only.

The driver accidentally stopped passing the input filenames on to -cc1
in this mode due to confusion over what action was being requested.

This change also fixes a couple of crashes I encountered when passing
multiple files to such a -cc1 invocation.

Added:
cfe/trunk/test/Modules/strict-decluse-headers.cpp
Modified:
cfe/trunk/lib/Driver/ToolChains/Clang.cpp
cfe/trunk/lib/Frontend/CompilerInstance.cpp
cfe/trunk/lib/Lex/ModuleMap.cpp
cfe/trunk/test/Driver/header-module.cpp

Modified: cfe/trunk/lib/Driver/ToolChains/Clang.cpp
URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_cfe_trunk_lib_Driver_ToolChains_Clang.cpp-3Frev-3D345803-26r1-3D345802-26r2-3D345803-26view-3Ddiff&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=fuhDqKU4xiQGQizq6Oszj5RJTGnnRK6S35y0Pk_bRcg&s=ffTui8JxCdjW5IP4JDgCIPKtFCLV4p96l0j4dM3OM4o&e=
==
--- cfe/trunk/lib/Driver/ToolChains/Clang.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Clang.cpp Wed Oct 31 17:46:54 2018
@@ -3250,8 +3250,6 @@ void Clang::ConstructJob(Compilation &C,
   bool IsCuda = JA.isOffloading(Action::OFK_Cuda);
   bool IsHIP = JA.isOffloading(Action::OFK_HIP);
   bool IsOpenMPDevice = JA.isDeviceOffloading(Action::OFK_OpenMP);
-  bool IsModulePrecompile =
-  isa(JA) && JA.getType() == types::TY_ModuleFile;
   bool IsHeaderModulePrecompile = isa(JA);
   // A header module compilation doesn't have a main input file, so invent a
@@ -3272,7 +3270,7 @@ void Clang::ConstructJob(Compilation &C,
   for (const InputInfo &I : Inputs) {
 if (&I == &Input) {
   // This is the primary input.
-} else if (IsModulePrecompile &&
+} else if (IsHeaderModulePrecompile &&
types::getPrecompiledType(I.getType()) == types::TY_PCH) {
   types::ID Expected =
   types::lookupHeaderTypeForSourceType(Inputs[0].getType());

Modified: cfe/trunk/lib/Frontend/CompilerInstance.cpp
URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_cfe_trunk_lib_Frontend_CompilerInstance.cpp-3Frev-3D345803-26r1-3D345802-26r2-3D345803-26view-3Ddiff&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=fuhDqKU4xiQGQizq6Oszj5RJTGnnRK6S35y0Pk_bRcg&s=KzBhYXfmPHLMrIoUboynLdE1ADPHU0qpcmI6eN5hG9w&e=
==
--- cfe/trunk/lib/Frontend/CompilerInstance.cpp (original)
+++ cfe/trunk/lib/Frontend/CompilerInstance.cpp Wed Oct 31 17:46:54 2018
@@ -372,6 +372,9 @@ static void InitializeFileRemapping(Diag
void CompilerInstance::createPreprocessor(TranslationUnitKind TUKind) {
   const PreprocessorOptions &PPOpts = getPreprocessorOpts();
+  // The module manager holds a reference to the old prepreocssor (if any).

I'm guessing this was meant to be "preprocessor"?

+  ModuleManager.reset();
+
   // Create a PTH manager if we are using some form of a token cache.
   PTHManager *PTHMgr = nullptr;
   if (!PPOpts.TokenCache.empty())

Modified: cfe/trunk/lib/Lex/ModuleMap.cpp
URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_cfe_trunk_lib_Lex_ModuleMap.cpp-3Frev-3D345803-26r1-3D345802-26r2-3D345803-26view-3Ddiff&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=fuhDqKU4xiQGQizq6Oszj5RJTGnnRK6S35y0Pk_bRcg&s=nNcoGXKyPGb6zXQpXy0g-2NVm65eDiskYntWuXgkrmQ&e=
==
--- cfe/trunk/lib/Lex/ModuleMap.cpp (original)
+++ cfe/trunk/lib/Lex/ModuleMap.cpp Wed Oct 31 17:46:54 2018
@@ -523,7 +523,7 @@ void ModuleMap::diagnoseHeaderInclusion(
   // At this point, only non-modular includes remain.
-  if (LangOpts.ModulesStrictDeclUse) {
+  if (RequestingModule && LangOpts.ModulesStrictDeclUse) {
 Diags.Report(FilenameLoc, diag::err_undeclared_use_of_module)
 << RequestingModule->getTopLevelModule()->Name << Filename;
   } else if (RequestingModule && RequestingModuleIsModuleInterface &&

Modified: cfe/trunk/test/Driver/header-module.cpp
URL: 
https://urldefense.proofpoint.com/v2/url?u=htt

r346378 - [clang] Set CMP0075 to new

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Wed Nov  7 16:29:33 2018
New Revision: 346378

URL: http://llvm.org/viewvc/llvm-project?rev=346378&view=rev
Log:
[clang] Set CMP0075 to new

Make the check_include_file* macros honor CMAKE_REQUIRED_LIBRARIES. This
shouldn't cause any of the configuration checks to give different
results, and I verified that a clean configure before and after this
change resulted in identical CMake caches on my machine. The same change
was done for LLVM in r346377.

Modified:
cfe/trunk/CMakeLists.txt

Modified: cfe/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/CMakeLists.txt?rev=346378&r1=346377&r2=346378&view=diff
==
--- cfe/trunk/CMakeLists.txt (original)
+++ cfe/trunk/CMakeLists.txt Wed Nov  7 16:29:33 2018
@@ -1,5 +1,9 @@
 cmake_minimum_required(VERSION 3.4.3)
 
+if(POLICY CMP0075)
+  cmake_policy(SET CMP0075 NEW)
+endif()
+
 # If we are not building as a part of LLVM, build Clang as an
 # standalone project, using LLVM as an external library:
 if( CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR )


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

r346882 - [AST] Fix typo in MicrosoftMangle

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Wed Nov 14 11:16:22 2018
New Revision: 346882

URL: http://llvm.org/viewvc/llvm-project?rev=346882&view=rev
Log:
[AST] Fix typo in MicrosoftMangle

Correct the spelling from Artifical to Artificial.

Differential Revision: https://reviews.llvm.org/D54536

Modified:
cfe/trunk/lib/AST/MicrosoftMangle.cpp

Modified: cfe/trunk/lib/AST/MicrosoftMangle.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/MicrosoftMangle.cpp?rev=346882&r1=346881&r2=346882&view=diff
==
--- cfe/trunk/lib/AST/MicrosoftMangle.cpp (original)
+++ cfe/trunk/lib/AST/MicrosoftMangle.cpp Wed Nov 14 11:16:22 2018
@@ -309,7 +309,7 @@ public:
 const MethodVFTableLocation &ML);
   void mangleNumber(int64_t Number);
   void mangleTagTypeKind(TagTypeKind TK);
-  void mangleArtificalTagType(TagTypeKind TK, StringRef UnqualifiedName,
+  void mangleArtificialTagType(TagTypeKind TK, StringRef UnqualifiedName,
   ArrayRef NestedNames = None);
   void mangleType(QualType T, SourceRange Range,
   QualifierMangleMode QMM = QMM_Mangle);
@@ -1070,7 +1070,7 @@ void MicrosoftCXXNameMangler::mangleNest
   if (PointersAre64Bit)
 Out << 'E';
   Out << 'A';
-  mangleArtificalTagType(TTK_Struct,
+  mangleArtificialTagType(TTK_Struct,
  Discriminate("__block_literal", Discriminator,
   ParameterDiscriminator));
   Out << "@Z";
@@ -1365,7 +1365,7 @@ void MicrosoftCXXNameMangler::mangleExpr
 // It's a global variable.
 Out << '3';
 // It's a struct called __s_GUID.
-mangleArtificalTagType(TTK_Struct, "__s_GUID");
+mangleArtificialTagType(TTK_Struct, "__s_GUID");
 // It's const.
 Out << 'B';
 return;
@@ -1521,9 +1521,9 @@ void MicrosoftCXXNameMangler::mangleObjC
 
   Stream << "?$";
   Extra.mangleSourceName("Protocol");
-  Extra.mangleArtificalTagType(TTK_Struct, PD->getName());
+  Extra.mangleArtificialTagType(TTK_Struct, PD->getName());
 
-  mangleArtificalTagType(TTK_Struct, TemplateMangling, {"__ObjC"});
+  mangleArtificialTagType(TTK_Struct, TemplateMangling, {"__ObjC"});
 }
 
 void MicrosoftCXXNameMangler::mangleObjCLifetime(const QualType Type,
@@ -1552,7 +1552,7 @@ void MicrosoftCXXNameMangler::mangleObjC
   Extra.manglePointerExtQualifiers(Quals, Type);
   Extra.mangleType(Type, Range);
 
-  mangleArtificalTagType(TTK_Struct, TemplateMangling, {"__ObjC"});
+  mangleArtificialTagType(TTK_Struct, TemplateMangling, {"__ObjC"});
 }
 
 void MicrosoftCXXNameMangler::mangleObjCKindOfType(const ObjCObjectType *T,
@@ -1569,7 +1569,7 @@ void MicrosoftCXXNameMangler::mangleObjC
->getAs(),
Quals, Range);
 
-  mangleArtificalTagType(TTK_Struct, TemplateMangling, {"__ObjC"});
+  mangleArtificialTagType(TTK_Struct, TemplateMangling, {"__ObjC"});
 }
 
 void MicrosoftCXXNameMangler::mangleQualifiers(Qualifiers Quals,
@@ -1765,7 +1765,7 @@ void MicrosoftCXXNameMangler::manglePass
   ArgBackRefMap::iterator Found = TypeBackReferences.find(TypePtr);
 
   if (Found == TypeBackReferences.end()) {
-mangleArtificalTagType(TTK_Enum, "__pass_object_size" + llvm::utostr(Type),
+mangleArtificialTagType(TTK_Enum, "__pass_object_size" + 
llvm::utostr(Type),
{"__clang"});
 
 if (TypeBackReferences.size() < 10) {
@@ -1951,13 +1951,13 @@ void MicrosoftCXXNameMangler::mangleType
 llvm_unreachable("placeholder types shouldn't get to name mangling");
 
   case BuiltinType::ObjCId:
-mangleArtificalTagType(TTK_Struct, "objc_object");
+mangleArtificialTagType(TTK_Struct, "objc_object");
 break;
   case BuiltinType::ObjCClass:
-mangleArtificalTagType(TTK_Struct, "objc_class");
+mangleArtificialTagType(TTK_Struct, "objc_class");
 break;
   case BuiltinType::ObjCSel:
-mangleArtificalTagType(TTK_Struct, "objc_selector");
+mangleArtificialTagType(TTK_Struct, "objc_selector");
 break;
 
 #define IMAGE_TYPE(ImgType, Id, SingletonId, Access, Suffix) \
@@ -1967,27 +1967,27 @@ void MicrosoftCXXNameMangler::mangleType
 #include "clang/Basic/OpenCLImageTypes.def"
   case BuiltinType::OCLSampler:
 Out << "PA";
-mangleArtificalTagType(TTK_Struct, "ocl_sampler");
+mangleArtificialTagType(TTK_Struct, "ocl_sampler");
 break;
   case BuiltinType::OCLEvent:
 Out << "PA";
-mangleArtificalTagType(TTK_Struct, "ocl_event");
+mangleArtificialTagType(TTK_Struct, "ocl_event");
 break;
   case BuiltinType::OCLClkEvent:
 Out << "PA";
-mangleArtificalTagType(TTK_Struct, "ocl_clkevent");
+mangleArtificialTagType(TTK_Struct, "ocl_clkevent");
 break;
   case BuiltinType::OCLQueue:
 Out << "PA";
-mangleArtificalTagType(TTK_Struct, "ocl_queue");
+mangleArtificialTagType(TTK_Struct, "ocl_queue");
 break;
   case BuiltinType::OCLReser

Re: r341697 - warn_stdlibcxx_not_found: suggest '-stdlib=libc++' instead of '-std'

[Shoaib Meenai via cfe-commits]

Could we merge this into 7.0.1? It's a trivial typo fix, and the error message 
could otherwise be confusing to users (someone brought this up in IRC a few 
hours ago).

From: cfe-commits  on behalf of Alex Lorenz 
via cfe-commits 
Reply-To: Alex Lorenz 
Date: Friday, September 7, 2018 at 12:01 PM
To: "cfe-commits@lists.llvm.org" 
Subject: r341697 - warn_stdlibcxx_not_found: suggest '-stdlib=libc++' instead 
of '-std'

Author: arphaman
Date: Fri Sep  7 11:59:45 2018
New Revision: 341697

URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D341697-26view-3Drev&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=IqJdIRn5MxFdIr2LEpZYhRLQTay50tZijNg6klhhdRA&s=MYePhuYEkBYd5aK7fqamBrBRJJGtvC-BPPojLInHah8&e=
Log:
warn_stdlibcxx_not_found: suggest '-stdlib=libc++' instead of '-std'

Addresses first post-commit feedback for r335081 from Nico

Modified:
cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
cfe/trunk/test/Frontend/warning-stdlibcxx-darwin.cpp

Modified: cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_cfe_trunk_include_clang_Basic_DiagnosticFrontendKinds.td-3Frev-3D341697-26r1-3D341696-26r2-3D341697-26view-3Ddiff&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=IqJdIRn5MxFdIr2LEpZYhRLQTay50tZijNg6klhhdRA&s=ZQcIenU2yQH3SmDrAhdXm2VKI10aP3_5IoBH-72HxYA&e=
==
--- cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td Fri Sep  7 
11:59:45 2018
@@ -238,7 +238,7 @@ def warn_option_invalid_ocl_version : Wa
   "OpenCL version %0 does not support the option '%1'">, InGroup;
def warn_stdlibcxx_not_found : Warning<
-  "include path for stdlibc++ headers not found; pass '-std=libc++' on the "
+  "include path for stdlibc++ headers not found; pass '-stdlib=libc++' on the "
   "command line to use the libc++ standard library instead">,
   InGroup>;
}

Modified: cfe/trunk/test/Frontend/warning-stdlibcxx-darwin.cpp
URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_cfe_trunk_test_Frontend_warning-2Dstdlibcxx-2Ddarwin.cpp-3Frev-3D341697-26r1-3D341696-26r2-3D341697-26view-3Ddiff&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=IqJdIRn5MxFdIr2LEpZYhRLQTay50tZijNg6klhhdRA&s=YR_ENMKZ9M1ESvYMVXN6PlRtSZ8bXMsfvYf8QaBm5X4&e=
==
--- cfe/trunk/test/Frontend/warning-stdlibcxx-darwin.cpp (original)
+++ cfe/trunk/test/Frontend/warning-stdlibcxx-darwin.cpp Fri Sep  7 11:59:45 
2018
@@ -1,5 +1,5 @@
// RUN: %clang -cc1 -triple arm64-apple-ios6.0.0 -isysroot %S/doesnotexist %s 
2>&1 | FileCheck %s
// RUN: %clang -cc1 -triple arm64-apple-ios6.0.0 -isysroot %S/doesnotexist 
-stdlib=libc++ %s -verify
-// CHECK: include path for stdlibc++ headers not found; pass '-std=libc++' on 
the command line to use the libc++ standard library instead
+// CHECK: include path for stdlibc++ headers not found; pass '-stdlib=libc++' 
on the command line to use the libc++ standard library instead
// expected-no-diagnostics


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_cfe-2Dcommits&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=IqJdIRn5MxFdIr2LEpZYhRLQTay50tZijNg6klhhdRA&s=Q8IVygsR4GuCJTOTCl7xRLj0JSxkuoS-q2HhesuNe4U&e=

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

Re: r338941 - [constexpr] Support for constant evaluation of __builtin_memcpy and

[Shoaib Meenai via cfe-commits]

If it's not too late, could we have this as part of 7.0.1? (You'll also
need to cherry-pick the initial reversion in r338602.) 7.0 hits assertion
failures for pretty basic memcpy cases on windows-msvc targets, and this
patch fixes that.

% cat /tmp/reduced.c
void *memcpy(void *, const void *, __SIZE_TYPE__);
void f(int i) {
  struct { int i } s;
  memcpy((char *)&s.i, &i, sizeof(i));
}

% clang -cc1 -triple x86_64-windows-msvc -emit-llvm -fms-compatibility -o
/dev/null /tmp/reduced.c
llvm::SmallVectorTemplateCommon::const_reference
llvm::SmallVectorTemplateCommon::back() const [T = clang::APValue::LValuePathEntry]: Assertion
`!empty()' failed.

On Fri, Aug 3, 2018 at 5:57 PM Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rsmith
> Date: Fri Aug  3 17:57:17 2018
> New Revision: 338941
>
> URL: http://llvm.org/viewvc/llvm-project?rev=338941&view=rev
> Log:
> [constexpr] Support for constant evaluation of __builtin_memcpy and
> __builtin_memmove (in non-type-punning cases).
>
> This is intended to permit libc++ to make std::copy etc constexpr
> without sacrificing the optimization that uses memcpy on
> trivially-copyable types.
>
> __builtin_strcpy and __builtin_wcscpy are not handled by this change.
> They'd be straightforward to add, but we haven't encountered a need for
> them just yet.
>
> This reinstates r338455, reverted in r338602, with a fix to avoid trying
> to constant-evaluate a memcpy call if either pointer operand has an
> invalid designator.
>
> Modified:
> cfe/trunk/include/clang/Basic/Builtins.def
> cfe/trunk/include/clang/Basic/DiagnosticASTKinds.td
> cfe/trunk/lib/AST/ExprConstant.cpp
> cfe/trunk/test/CodeGen/builtin-memfns.c
> cfe/trunk/test/SemaCXX/constexpr-string.cpp
>
> Modified: cfe/trunk/include/clang/Basic/Builtins.def
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Builtins.def?rev=338941&r1=338940&r2=338941&view=diff
>
> ==
> --- cfe/trunk/include/clang/Basic/Builtins.def (original)
> +++ cfe/trunk/include/clang/Basic/Builtins.def Fri Aug  3 17:57:17 2018
> @@ -471,6 +471,8 @@ BUILTIN(__builtin_wcslen, "zwC*", "nF")
>  BUILTIN(__builtin_wcsncmp, "iwC*wC*z", "nF")
>  BUILTIN(__builtin_wmemchr, "w*wC*wz", "nF")
>  BUILTIN(__builtin_wmemcmp, "iwC*wC*z", "nF")
> +BUILTIN(__builtin_wmemcpy, "w*w*wC*z", "nF")
> +BUILTIN(__builtin_wmemmove, "w*w*wC*z", "nF")
>  BUILTIN(__builtin_return_address, "v*IUi", "n")
>  BUILTIN(__builtin_extract_return_addr, "v*v*", "n")
>  BUILTIN(__builtin_frame_address, "v*IUi", "n")
> @@ -908,6 +910,8 @@ LIBBUILTIN(wcslen,  "zwC*", "f", "wc
>  LIBBUILTIN(wcsncmp, "iwC*wC*z", "f", "wchar.h", ALL_LANGUAGES)
>  LIBBUILTIN(wmemchr, "w*wC*wz",  "f", "wchar.h", ALL_LANGUAGES)
>  LIBBUILTIN(wmemcmp, "iwC*wC*z", "f", "wchar.h", ALL_LANGUAGES)
> +LIBBUILTIN(wmemcpy, "w*w*wC*z", "f", "wchar.h", ALL_LANGUAGES)
> +LIBBUILTIN(wmemmove,"w*w*wC*z", "f", "wchar.h", ALL_LANGUAGES)
>
>  // C99
>  // In some systems setjmp is a macro that expands to _setjmp. We undefine
>
> Modified: cfe/trunk/include/clang/Basic/DiagnosticASTKinds.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticASTKinds.td?rev=338941&r1=338940&r2=338941&view=diff
>
> ==
> --- cfe/trunk/include/clang/Basic/DiagnosticASTKinds.td (original)
> +++ cfe/trunk/include/clang/Basic/DiagnosticASTKinds.td Fri Aug  3
> 17:57:17 2018
> @@ -163,6 +163,20 @@ def note_constexpr_unsupported_unsized_a
>  def note_constexpr_unsized_array_indexed : Note<
>"indexing of array without known bound is not allowed "
>"in a constant expression">;
> +def note_constexpr_memcpy_type_pun : Note<
> +  "cannot constant evaluate '%select{memcpy|memmove}0' from object of "
> +  "type %1 to object of type %2">;
> +def note_constexpr_memcpy_nontrivial : Note<
> +  "cannot constant evaluate '%select{memcpy|memmove}0' between objects of
> "
> +  "non-trivially-copyable type %1">;
> +def note_constexpr_memcpy_overlap : Note<
> +  "'%select{memcpy|wmemcpy}0' between overlapping memory regions">;
> +def note_constexpr_memcpy_unsupported : Note<
> +  "'%select{%select{memcpy|wmemcpy}1|%select{memmove|wmemmove}1}0' "
> +  "not supported: %select{"
> +  "size to copy (%4) is not a multiple of size of element type %3 (%5)|"
> +  "source is not a contiguous array of at least %4 elements of type %3|"
> +  "destination is not a contiguous array of at least %4 elements of type
> %3}2">;
>
>  def warn_integer_constant_overflow : Warning<
>"overflow in expression; result is %0 with type %1">,
>
> Modified: cfe/trunk/lib/AST/ExprConstant.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ExprConstant.cpp?rev=338941&r1=338940&r2=338941&view=diff
>
> ==
> --- cfe/trunk/lib/AST/ExprConstant.cpp (

Re: r338941 - [constexpr] Support for constant evaluation of __builtin_memcpy and

[Shoaib Meenai via cfe-commits]

Uhh, we have our own build that uses the release branch, but somehow we didn’t 
have that commit in there. Not sure how that happened, but sorry for the noise.

From: cfe-commits  on behalf of Richard 
Smith via cfe-commits 
Reply-To: Richard Smith 
Date: Monday, November 26, 2018 at 12:01 PM
To: Shoaib Meenai 
Cc: cfe-commits , Tom Stellard 
Subject: Re: r338941 - [constexpr] Support for constant evaluation of 
__builtin_memcpy and

On Mon, 26 Nov 2018, 11:50 Richard Smith 
mailto:rich...@metafoo.co.uk> wrote:
On Wed, 21 Nov 2018, 15:32 Shoaib Meenai via cfe-commits 
mailto:cfe-commits@lists.llvm.org> wrote:
If it's not too late, could we have this as part of 7.0.1? (You'll also need to 
cherry-pick the initial reversion in r338602.)

The revert was cherrypicked onto the branch in r338674. Was that not in time 
for 7.0?

Looks like the revert was in fact the very first thing cherrypicked into 
clang's release_70 branch after the branch was cut, so it should certainly have 
been in time for 7.0. Are you sure your clang binary is really the 7.0 release?

I don't think we should take this as a new feature for 7.0.1.

7.0 hits assertion failures for pretty basic memcpy cases on windows-msvc 
targets, and this patch fixes that.

% cat /tmp/reduced.c
void *memcpy(void *, const void *, __SIZE_TYPE__);
void f(int i) {
  struct { int i } s;
  memcpy((char *)&s.i, &i, sizeof(i));
}

% clang -cc1 -triple x86_64-windows-msvc -emit-llvm -fms-compatibility -o 
/dev/null /tmp/reduced.c
llvm::SmallVectorTemplateCommon::const_reference 
llvm::SmallVectorTemplateCommon::back() 
const [T = clang::APValue::LValuePathEntry]: Assertion `!empty()' failed.

On Fri, Aug 3, 2018 at 5:57 PM Richard Smith via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: rsmith
Date: Fri Aug  3 17:57:17 2018
New Revision: 338941

URL: 
http://llvm.org/viewvc/llvm-project?rev=338941&view=rev<https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D338941-26view-3Drev&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=Ru-mCU1Dn9QNNn6nn7wO6RrDpRjNecPIDS4JqFjlaDQ&s=kLZGidrWPNCR2HKca-VmTjfl22m1UcG_BNKpUqW8AbU&e=>
Log:
[constexpr] Support for constant evaluation of __builtin_memcpy and
__builtin_memmove (in non-type-punning cases).

This is intended to permit libc++ to make std::copy etc constexpr
without sacrificing the optimization that uses memcpy on
trivially-copyable types.

__builtin_strcpy and __builtin_wcscpy are not handled by this change.
They'd be straightforward to add, but we haven't encountered a need for
them just yet.

This reinstates r338455, reverted in r338602, with a fix to avoid trying
to constant-evaluate a memcpy call if either pointer operand has an
invalid designator.

Modified:
cfe/trunk/include/clang/Basic/Builtins.def
cfe/trunk/include/clang/Basic/DiagnosticASTKinds.td
cfe/trunk/lib/AST/ExprConstant.cpp
cfe/trunk/test/CodeGen/builtin-memfns.c
cfe/trunk/test/SemaCXX/constexpr-string.cpp

Modified: cfe/trunk/include/clang/Basic/Builtins.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Builtins.def?rev=338941&r1=338940&r2=338941&view=diff<https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_cfe_trunk_include_clang_Basic_Builtins.def-3Frev-3D338941-26r1-3D338940-26r2-3D338941-26view-3Ddiff&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=Ru-mCU1Dn9QNNn6nn7wO6RrDpRjNecPIDS4JqFjlaDQ&s=agZQwByY7d4bRMtTI9wisVrDwIsrXQd4SFurViV23qU&e=>
==
--- cfe/trunk/include/clang/Basic/Builtins.def (original)
+++ cfe/trunk/include/clang/Basic/Builtins.def Fri Aug  3 17:57:17 2018
@@ -471,6 +471,8 @@ BUILTIN(__builtin_wcslen, "zwC*", "nF")
 BUILTIN(__builtin_wcsncmp, "iwC*wC*z", "nF")
 BUILTIN(__builtin_wmemchr, "w*wC*wz", "nF")
 BUILTIN(__builtin_wmemcmp, "iwC*wC*z", "nF")
+BUILTIN(__builtin_wmemcpy, "w*w*wC*z", "nF")
+BUILTIN(__builtin_wmemmove, "w*w*wC*z", "nF")
 BUILTIN(__builtin_return_address, "v*IUi", "n")
 BUILTIN(__builtin_extract_return_addr, "v*v*", "n")
 BUILTIN(__builtin_frame_address, "v*IUi", "n")
@@ -908,6 +910,8 @@ LIBBUILTIN(wcslen,  "zwC*", "f", "wc
 LIBBUILTIN(wcsncmp, "iwC*wC*z", "f", "wchar.h", ALL_LANGUAGES)
 LIBBUILTIN(wmemchr, "w*wC*wz",  "f", "wchar.h", ALL_LANGUAGES)
 LIBBUILTIN(wmemcmp, "iwC*wC*z", "f", "wchar.h", ALL_LANGUAGES)
+LIBBUILTIN(wmemcpy, "w*w*wC*z", "f", "wchar.h", ALL_LANGUAGES)
+LIBBUILTIN(wmemmove,"w*w*wC*z", "f", 

[clang-tools-extra] r355340 - [build] Rename clang-headers to clang-resource-headers

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Mon Mar  4 13:19:53 2019
New Revision: 355340

URL: http://llvm.org/viewvc/llvm-project?rev=355340&view=rev
Log:
[build] Rename clang-headers to clang-resource-headers

Summary:
The current install-clang-headers target installs clang's resource
directory headers. This is different from the install-llvm-headers
target, which installs LLVM's API headers. We want to introduce the
corresponding target to clang, and the natural name for that new target
would be install-clang-headers. Rename the existing target to
install-clang-resource-headers to free up the install-clang-headers name
for the new target, following the discussion on cfe-dev [1].

I didn't find any bots on zorg referencing install-clang-headers. I'll
send out another PSA to cfe-dev to accompany this rename.

[1] http://lists.llvm.org/pipermail/cfe-dev/2019-February/061365.html

Reviewers: beanz, phosek, tstellar, rnk, dim, serge-sans-paille

Subscribers: mgorny, javed.absar, jdoerfert, #sanitizers, openmp-commits, 
lldb-commits, cfe-commits, llvm-commits

Tags: #clang, #sanitizers, #lldb, #openmp, #llvm

Differential Revision: https://reviews.llvm.org/D58791

Modified:
clang-tools-extra/trunk/clang-tidy/tool/CMakeLists.txt
clang-tools-extra/trunk/test/CMakeLists.txt

Modified: clang-tools-extra/trunk/clang-tidy/tool/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/tool/CMakeLists.txt?rev=355340&r1=355339&r2=355340&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/tool/CMakeLists.txt (original)
+++ clang-tools-extra/trunk/clang-tidy/tool/CMakeLists.txt Mon Mar  4 13:19:53 
2019
@@ -9,7 +9,7 @@ add_clang_tool(clang-tidy
   ClangTidyMain.cpp
   )
 add_dependencies(clang-tidy
-  clang-headers
+  clang-resource-headers
   )
 target_link_libraries(clang-tidy
   PRIVATE

Modified: clang-tools-extra/trunk/test/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/CMakeLists.txt?rev=355340&r1=355339&r2=355340&view=diff
==
--- clang-tools-extra/trunk/test/CMakeLists.txt (original)
+++ clang-tools-extra/trunk/test/CMakeLists.txt Mon Mar  4 13:19:53 2019
@@ -59,7 +59,7 @@ set(CLANG_TOOLS_TEST_DEPS
   # For the clang-tidy libclang integration test.
   c-index-test
   # clang-tidy tests require it.
-  clang-headers
+  clang-resource-headers
 
   clang-tidy
 )


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

r355340 - [build] Rename clang-headers to clang-resource-headers

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Mon Mar  4 13:19:53 2019
New Revision: 355340

URL: http://llvm.org/viewvc/llvm-project?rev=355340&view=rev
Log:
[build] Rename clang-headers to clang-resource-headers

Summary:
The current install-clang-headers target installs clang's resource
directory headers. This is different from the install-llvm-headers
target, which installs LLVM's API headers. We want to introduce the
corresponding target to clang, and the natural name for that new target
would be install-clang-headers. Rename the existing target to
install-clang-resource-headers to free up the install-clang-headers name
for the new target, following the discussion on cfe-dev [1].

I didn't find any bots on zorg referencing install-clang-headers. I'll
send out another PSA to cfe-dev to accompany this rename.

[1] http://lists.llvm.org/pipermail/cfe-dev/2019-February/061365.html

Reviewers: beanz, phosek, tstellar, rnk, dim, serge-sans-paille

Subscribers: mgorny, javed.absar, jdoerfert, #sanitizers, openmp-commits, 
lldb-commits, cfe-commits, llvm-commits

Tags: #clang, #sanitizers, #lldb, #openmp, #llvm

Differential Revision: https://reviews.llvm.org/D58791

Modified:
cfe/trunk/cmake/caches/Apple-stage2.cmake
cfe/trunk/cmake/caches/BaremetalARM.cmake
cfe/trunk/cmake/caches/DistributionExample-stage2.cmake
cfe/trunk/cmake/caches/Fuchsia-stage2.cmake
cfe/trunk/cmake/modules/AddClang.cmake
cfe/trunk/docs/LibTooling.rst
cfe/trunk/docs/ReleaseNotes.rst
cfe/trunk/examples/clang-interpreter/CMakeLists.txt
cfe/trunk/lib/Headers/CMakeLists.txt
cfe/trunk/test/CMakeLists.txt
cfe/trunk/tools/driver/CMakeLists.txt
cfe/trunk/tools/libclang/CMakeLists.txt

Modified: cfe/trunk/cmake/caches/Apple-stage2.cmake
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/cmake/caches/Apple-stage2.cmake?rev=355340&r1=355339&r2=355340&view=diff
==
--- cfe/trunk/cmake/caches/Apple-stage2.cmake (original)
+++ cfe/trunk/cmake/caches/Apple-stage2.cmake Mon Mar  4 13:19:53 2019
@@ -60,7 +60,7 @@ set(LLVM_DISTRIBUTION_COMPONENTS
   clang
   LTO
   clang-format
-  clang-headers
+  clang-resource-headers
   cxx-headers
   ${LLVM_TOOLCHAIN_TOOLS}
   CACHE STRING "")

Modified: cfe/trunk/cmake/caches/BaremetalARM.cmake
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/cmake/caches/BaremetalARM.cmake?rev=355340&r1=355339&r2=355340&view=diff
==
--- cfe/trunk/cmake/caches/BaremetalARM.cmake (original)
+++ cfe/trunk/cmake/caches/BaremetalARM.cmake Mon Mar  4 13:19:53 2019
@@ -41,7 +41,7 @@ set(LLVM_TOOLCHAIN_TOOLS
 set(LLVM_DISTRIBUTION_COMPONENTS
   clang
   lld
-  clang-headers
+  clang-resource-headers
   builtins-armv6m-none-eabi
   builtins-armv7m-none-eabi
   builtins-armv7em-none-eabi

Modified: cfe/trunk/cmake/caches/DistributionExample-stage2.cmake
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/cmake/caches/DistributionExample-stage2.cmake?rev=355340&r1=355339&r2=355340&view=diff
==
--- cfe/trunk/cmake/caches/DistributionExample-stage2.cmake (original)
+++ cfe/trunk/cmake/caches/DistributionExample-stage2.cmake Mon Mar  4 13:19:53 
2019
@@ -23,7 +23,7 @@ set(LLVM_DISTRIBUTION_COMPONENTS
   clang
   LTO
   clang-format
-  clang-headers
+  clang-resource-headers
   builtins
   runtimes
   ${LLVM_TOOLCHAIN_TOOLS}

Modified: cfe/trunk/cmake/caches/Fuchsia-stage2.cmake
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/cmake/caches/Fuchsia-stage2.cmake?rev=355340&r1=355339&r2=355340&view=diff
==
--- cfe/trunk/cmake/caches/Fuchsia-stage2.cmake (original)
+++ cfe/trunk/cmake/caches/Fuchsia-stage2.cmake Mon Mar  4 13:19:53 2019
@@ -167,7 +167,7 @@ set(LLVM_DISTRIBUTION_COMPONENTS
   LTO
   clang-apply-replacements
   clang-format
-  clang-headers
+  clang-resource-headers
   clang-include-fixer
   clang-refactor
   clang-tidy

Modified: cfe/trunk/cmake/modules/AddClang.cmake
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/cmake/modules/AddClang.cmake?rev=355340&r1=355339&r2=355340&view=diff
==
--- cfe/trunk/cmake/modules/AddClang.cmake (original)
+++ cfe/trunk/cmake/modules/AddClang.cmake Mon Mar  4 13:19:53 2019
@@ -133,7 +133,7 @@ macro(add_clang_tool name)
   endif()
 
   add_clang_executable(${name} ${ARGN})
-  add_dependencies(${name} clang-headers)
+  add_dependencies(${name} clang-resource-headers)
 
   if (CLANG_BUILD_TOOLS)
 if(${name} IN_LIST LLVM_DISTRIBUTION_COMPONENTS OR

Modified: cfe/trunk/docs/LibTooling.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/LibTooling.rst?rev=355340&r1=355339&r2=355340&view=diff
==
--- cfe/trunk/docs

r355354 - [cmake] Create exports for umbrella library targets

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Mon Mar  4 16:38:32 2019
New Revision: 355354

URL: http://llvm.org/viewvc/llvm-project?rev=355354&view=rev
Log:
[cmake] Create exports for umbrella library targets

When using the umbrella llvm-libraries and clang-libraries targets, we
should export all library targets, otherwise they'll be part of our
distribution but not usable from the CMake package.

Differential Revision: https://reviews.llvm.org/D58862

Modified:
cfe/trunk/cmake/modules/AddClang.cmake

Modified: cfe/trunk/cmake/modules/AddClang.cmake
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/cmake/modules/AddClang.cmake?rev=355354&r1=355353&r2=355354&view=diff
==
--- cfe/trunk/cmake/modules/AddClang.cmake (original)
+++ cfe/trunk/cmake/modules/AddClang.cmake Mon Mar  4 16:38:32 2019
@@ -91,6 +91,7 @@ macro(add_clang_library name)
 if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY OR ${name} STREQUAL "libclang")
 
   if(${name} IN_LIST LLVM_DISTRIBUTION_COMPONENTS OR
+  "clang-libraries" IN_LIST LLVM_DISTRIBUTION_COMPONENTS OR
   NOT LLVM_DISTRIBUTION_COMPONENTS)
 set(export_to_clangtargets EXPORT ClangTargets)
 set_property(GLOBAL PROPERTY CLANG_HAS_EXPORTS True)


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

r355853 - [clang] Add install targets for API headers

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Mon Mar 11 11:53:57 2019
New Revision: 355853

URL: http://llvm.org/viewvc/llvm-project?rev=355853&view=rev
Log:
[clang] Add install targets for API headers

Add an install target for clang's API headers, which allows them to be
included in distributions. The install rules already existed, but they
lacked a component and a target, making them only accessible via a full
install. These headers are useful for writing clang-based tooling, for
example. They're the clang equivalent to the llvm-headers target and
complement the clang-libraries target.

Differential Revision: https://reviews.llvm.org/D58317

Modified:
cfe/trunk/CMakeLists.txt
cfe/trunk/docs/ReleaseNotes.rst

Modified: cfe/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/CMakeLists.txt?rev=355853&r1=355852&r2=355853&view=diff
==
--- cfe/trunk/CMakeLists.txt (original)
+++ cfe/trunk/CMakeLists.txt Mon Mar 11 11:53:57 2019
@@ -388,6 +388,7 @@ include_directories(BEFORE
 if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY)
   install(DIRECTORY include/clang include/clang-c
 DESTINATION include
+COMPONENT clang-headers
 FILES_MATCHING
 PATTERN "*.def"
 PATTERN "*.h"
@@ -397,12 +398,23 @@ if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY)
 
   install(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/include/clang
 DESTINATION include
+COMPONENT clang-headers
 FILES_MATCHING
 PATTERN "CMakeFiles" EXCLUDE
 PATTERN "*.inc"
 PATTERN "*.h"
 )
 
+  # Installing the headers needs to depend on generating any public
+  # tablegen'd headers.
+  add_custom_target(clang-headers DEPENDS clang-tablegen-targets)
+  set_target_properties(clang-headers PROPERTIES FOLDER "Misc")
+  if(NOT LLVM_ENABLE_IDE)
+add_llvm_install_targets(install-clang-headers
+ DEPENDS clang-headers
+ COMPONENT clang-headers)
+  endif()
+
   install(PROGRAMS utils/bash-autocomplete.sh
 DESTINATION share/clang
 )

Modified: cfe/trunk/docs/ReleaseNotes.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ReleaseNotes.rst?rev=355853&r1=355852&r2=355853&view=diff
==
--- cfe/trunk/docs/ReleaseNotes.rst (original)
+++ cfe/trunk/docs/ReleaseNotes.rst Mon Mar 11 11:53:57 2019
@@ -156,7 +156,9 @@ release of Clang. Users of the build sys
 - In 8.0.0 and below, the install-clang-headers target would install clang's
   resource directory headers. This installation is now performed by the
   install-clang-resource-headers target. Users of the old install-clang-headers
-  target should switch to the new install-clang-resource-headers target.
+  target should switch to the new install-clang-resource-headers target. The
+  install-clang-headers target now installs clang's API headers (corresponding
+  to its libraries), which is consistent with the install-llvm-headers target.
 
 -  ...
 


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

r357036 - [cmake] Reset variable before using it

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Tue Mar 26 15:16:53 2019
New Revision: 357036

URL: http://llvm.org/viewvc/llvm-project?rev=357036&view=rev
Log:
[cmake] Reset variable before using it

A bunch of macros use the same variable name, and since CMake macros
don't get their own scope, the value persists across macro invocations,
and we can end up exporting targets which shouldn't be exported. Clear
the variable before each use to avoid this.

Converting these macros to functions would also help, since it would
avoid the variable leaking into its parent scope, and that's something I
plan to follow up with. It won't fully address the problem, however,
since functions still inherit variables from their parent scopes, so if
someone in the parent scope just happened to use the same variable name
we'd still have the same issue.

Modified:
cfe/trunk/cmake/modules/AddClang.cmake

Modified: cfe/trunk/cmake/modules/AddClang.cmake
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/cmake/modules/AddClang.cmake?rev=357036&r1=357035&r2=357036&view=diff
==
--- cfe/trunk/cmake/modules/AddClang.cmake (original)
+++ cfe/trunk/cmake/modules/AddClang.cmake Tue Mar 26 15:16:53 2019
@@ -89,7 +89,7 @@ macro(add_clang_library name)
 target_link_libraries(${name} INTERFACE ${LLVM_COMMON_LIBS})
 
 if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY OR ${name} STREQUAL "libclang")
-
+  set(export_to_clangtargets)
   if(${name} IN_LIST LLVM_DISTRIBUTION_COMPONENTS OR
   "clang-libraries" IN_LIST LLVM_DISTRIBUTION_COMPONENTS OR
   NOT LLVM_DISTRIBUTION_COMPONENTS)
@@ -137,6 +137,7 @@ macro(add_clang_tool name)
   add_dependencies(${name} clang-resource-headers)
 
   if (CLANG_BUILD_TOOLS)
+set(export_to_clangtargets)
 if(${name} IN_LIST LLVM_DISTRIBUTION_COMPONENTS OR
 NOT LLVM_DISTRIBUTION_COMPONENTS)
   set(export_to_clangtargets EXPORT ClangTargets)


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

r357184 - [CodeGen] Add additional mangling for struct members of non trivial structs

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Thu Mar 28 10:01:20 2019
New Revision: 357184

URL: http://llvm.org/viewvc/llvm-project?rev=357184&view=rev
Log:
[CodeGen] Add additional mangling for struct members of non trivial structs

In https://bugs.llvm.org/show_bug.cgi?id=41206 we observe bad codegen
when embedding a non-trivial C struct within a C struct. This is due to
the fact that name mangling for non-trivial structs marks the two
structs as identical. This diff contains a fix for this issue.

Patch by Dan Zimmerman .

Differential Revision: https://reviews.llvm.org/D59873

Added:
cfe/trunk/test/CodeGenObjC/nontrivial-c-struct-within-struct-name.m
Modified:
cfe/trunk/lib/CodeGen/CGNonTrivialStruct.cpp
cfe/trunk/test/CodeGenObjC/strong-in-c-struct.m

Modified: cfe/trunk/lib/CodeGen/CGNonTrivialStruct.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGNonTrivialStruct.cpp?rev=357184&r1=357183&r2=357184&view=diff
==
--- cfe/trunk/lib/CodeGen/CGNonTrivialStruct.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGNonTrivialStruct.cpp Thu Mar 28 10:01:20 2019
@@ -139,8 +139,8 @@ struct CopyStructVisitor : StructVisitor
 //  ::=  ["_" ]
 //  ::= +
 //  ::=  | 
-//  ::=  |  
|
-//   
+//  ::= "_S"  |
+//| 
 //  ::= "_AB"  "s"  "n"
 //  "_AE"
 //  ::= 
@@ -175,6 +175,7 @@ template  struct GenFuncN
   void visitStruct(QualType QT, const FieldDecl *FD,
CharUnits CurStructOffset) {
 CharUnits FieldOffset = CurStructOffset + asDerived().getFieldOffset(FD);
+appendStr("_S");
 asDerived().visitStructFields(QT, FieldOffset);
   }
 

Added: cfe/trunk/test/CodeGenObjC/nontrivial-c-struct-within-struct-name.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenObjC/nontrivial-c-struct-within-struct-name.m?rev=357184&view=auto
==
--- cfe/trunk/test/CodeGenObjC/nontrivial-c-struct-within-struct-name.m (added)
+++ cfe/trunk/test/CodeGenObjC/nontrivial-c-struct-within-struct-name.m Thu Mar 
28 10:01:20 2019
@@ -0,0 +1,44 @@
+// RUN: %clang_cc1 -triple arm64-apple-ios11 -fobjc-arc -emit-llvm -o - %s | 
FileCheck %s
+
+@class I;
+
+typedef struct {
+  I *name;
+} Foo;
+
+typedef struct {
+  Foo foo;
+} Bar;
+
+typedef struct {
+  Bar bar;
+} Baz;
+
+I *getI();
+
+void f() {
+  Foo foo = {getI()};
+  Bar bar = {foo};
+  Baz baz = {bar};
+}
+
+// CHECK: define linkonce_odr hidden void @__destructor_8_S_S_s0(i8** 
%[[DST:.*]])
+// CHECK: %[[DST_ADDR:.*]] = alloca i8**, align 8
+// CHECK: store i8** %[[DST]], i8*** %[[DST_ADDR]], align 8
+// CHECK: %[[V0:.*]] = load i8**, i8*** %[[DST_ADDR]], align 8
+// CHECK: call void @__destructor_8_S_s0(i8** %[[V0]])
+// CHECK: ret void
+
+// CHECK: define linkonce_odr hidden void @__destructor_8_S_s0(i8** 
%[[DST:.*]])
+// CHECK: %[[DST_ADDR:.*]] = alloca i8**, align 8
+// CHECK: store i8** %[[DST]], i8*** %[[DST_ADDR]], align 8
+// CHECK: %[[V0:.*]] = load i8**, i8*** %[[DST_ADDR]], align 8
+// CHECK: call void @__destructor_8_s0(i8** %[[V0]])
+// CHECK: ret void
+
+// CHECK: define linkonce_odr hidden void @__destructor_8_s0(i8** %dst)
+// CHECK: %[[DST_ADDR:.*]] = alloca i8**, align 8
+// CHECK: store i8** %[[DST]], i8*** %[[DST_ADDR]], align 8
+// CHECK: %[[V0:.*]] = load i8**, i8*** %[[DST_ADDR]], align 8
+// CHECK: call void @llvm.objc.storeStrong(i8** %[[V0]], i8* null)
+// CHECK: ret void

Modified: cfe/trunk/test/CodeGenObjC/strong-in-c-struct.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenObjC/strong-in-c-struct.m?rev=357184&r1=357183&r2=357184&view=diff
==
--- cfe/trunk/test/CodeGenObjC/strong-in-c-struct.m (original)
+++ cfe/trunk/test/CodeGenObjC/strong-in-c-struct.m Thu Mar 28 10:01:20 2019
@@ -89,12 +89,12 @@ void func(Strong *);
 // CHECK: define void @test_constructor_destructor_StrongOuter()
 // CHECK: %[[T:.*]] = alloca %[[STRUCT_STRONGOUTER:.*]], align 8
 // CHECK: %[[V0:.*]] = bitcast %[[STRUCT_STRONGOUTER]]* %[[T]] to i8**
-// CHECK: call void @__default_constructor_8_s16_s24(i8** %[[V0]])
+// CHECK: call void @__default_constructor_8_S_s16_s24(i8** %[[V0]])
 // CHECK: %[[V1:.*]] = bitcast %[[STRUCT_STRONGOUTER]]* %[[T]] to i8**
-// CHECK: call void @__destructor_8_s16_s24(i8** %[[V1]])
+// CHECK: call void @__destructor_8_S_s16_s24(i8** %[[V1]])
 // CHECK: ret void
 
-// CHECK: define linkonce_odr hidden void 
@__default_constructor_8_s16_s24(i8** %[[DST:.*]])
+// CHECK: define linkonce_odr hidden void 
@__default_constructor_8_S_s16_s24(i8** %[[DST:.*]])
 // CHECK: %[[DST_ADDR:.*]] = alloca i8**, align 8
 // CHECK: store i8** %[[DST]], i8*** %[[DST_ADDR]], align 8
 // CHECK: %[[V0:.*]] = load i8**, i8*** %[[DST_ADDR]], align 8
@@ -117,7 +117,7 @@ void func(Strong *);
 // CHECK: call void @

r343808 - [AST] Revert mangling changes from r339428

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Thu Oct  4 12:50:14 2018
New Revision: 343808

URL: http://llvm.org/viewvc/llvm-project?rev=343808&view=rev
Log:
[AST] Revert mangling changes from r339428

As discussed in https://reviews.llvm.org/D50144, we want Obj-C classes
to have the same mangling as C++ structs, to support headers like the
following:

```
@class I;
struct I;

void f(I *);
```

since the header can be used from both C++ and Obj-C++ TUs, and we want
a consistent mangling across the two to prevent link errors. Itanium
mangles both the same way, and so should the MS ABI.

The main concern with having the same mangling for C++ structs and Obj-C
classes was that we want to treat them differently for the purposes of
exception handling, e.g. we don't want a C++ catch statement for a
struct to be able to catch an Obj-C class with the same name as the
struct. We can accomplish this by mangling Obj-C class names differently
in their RTTI, which I'll do in a follow-up patch.

Differential Revision: https://reviews.llvm.org/D52581

Modified:
cfe/trunk/lib/AST/MicrosoftMangle.cpp
cfe/trunk/test/CodeGenObjCXX/arc-marker-funclet.mm
cfe/trunk/test/CodeGenObjCXX/microsoft-abi-arc-param-order.mm
cfe/trunk/test/CodeGenObjCXX/msabi-objc-extensions.mm
cfe/trunk/test/CodeGenObjCXX/msabi-objc-types.mm

Modified: cfe/trunk/lib/AST/MicrosoftMangle.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/MicrosoftMangle.cpp?rev=343808&r1=343807&r2=343808&view=diff
==
--- cfe/trunk/lib/AST/MicrosoftMangle.cpp (original)
+++ cfe/trunk/lib/AST/MicrosoftMangle.cpp Thu Oct  4 12:50:14 2018
@@ -482,7 +482,7 @@ void MicrosoftCXXNameMangler::mangle(con
 mangleFunctionEncoding(FD, Context.shouldMangleDeclName(FD));
   else if (const VarDecl *VD = dyn_cast(D))
 mangleVariableEncoding(VD);
-  else if (!isa(D))
+  else
 llvm_unreachable("Tried to mangle unexpected NamedDecl!");
 }
 
@@ -1951,13 +1951,13 @@ void MicrosoftCXXNameMangler::mangleType
 llvm_unreachable("placeholder types shouldn't get to name mangling");
 
   case BuiltinType::ObjCId:
-mangleArtificalTagType(TTK_Struct, ".objc_object");
+mangleArtificalTagType(TTK_Struct, "objc_object");
 break;
   case BuiltinType::ObjCClass:
-mangleArtificalTagType(TTK_Struct, ".objc_class");
+mangleArtificalTagType(TTK_Struct, "objc_class");
 break;
   case BuiltinType::ObjCSel:
-mangleArtificalTagType(TTK_Struct, ".objc_selector");
+mangleArtificalTagType(TTK_Struct, "objc_selector");
 break;
 
 #define IMAGE_TYPE(ImgType, Id, SingletonId, Access, Suffix) \
@@ -2637,10 +2637,9 @@ void MicrosoftCXXNameMangler::mangleType
 
 void MicrosoftCXXNameMangler::mangleType(const ObjCInterfaceType *T, 
Qualifiers,
  SourceRange) {
-  // ObjC interfaces are mangled as if they were structs with a name that is
-  // not a valid C/C++ identifier
+  // ObjC interfaces have structs underlying them.
   mangleTagTypeKind(TTK_Struct);
-  mangle(T->getDecl(), ".objc_cls_");
+  mangleName(T->getDecl());
 }
 
 void MicrosoftCXXNameMangler::mangleType(const ObjCObjectType *T,
@@ -2661,11 +2660,11 @@ void MicrosoftCXXNameMangler::mangleType
 
   Out << "?$";
   if (T->isObjCId())
-mangleSourceName(".objc_object");
+mangleSourceName("objc_object");
   else if (T->isObjCClass())
-mangleSourceName(".objc_class");
+mangleSourceName("objc_class");
   else
-mangleSourceName((".objc_cls_" + T->getInterface()->getName()).str());
+mangleSourceName(T->getInterface()->getName());
 
   for (const auto &Q : T->quals())
 mangleObjCProtocol(Q);

Modified: cfe/trunk/test/CodeGenObjCXX/arc-marker-funclet.mm
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenObjCXX/arc-marker-funclet.mm?rev=343808&r1=343807&r2=343808&view=diff
==
--- cfe/trunk/test/CodeGenObjCXX/arc-marker-funclet.mm (original)
+++ cfe/trunk/test/CodeGenObjCXX/arc-marker-funclet.mm Thu Oct  4 12:50:14 2018
@@ -10,7 +10,7 @@ void g() {
   }
 }
 
-// CHECK: call i8* @"?f@@YAPAU.objc_object@@XZ"() [ "funclet"(token %1) ]
+// CHECK: call i8* @"?f@@YAPAUobjc_object@@XZ"() [ "funclet"(token %1) ]
 // CHECK-NEXT: call void asm sideeffect "movl{{.*}}%ebp, %ebp{{.*}}", ""() [ 
"funclet"(token %1) ]
 
 // The corresponding f() call was invoked from the entry basic block.

Modified: cfe/trunk/test/CodeGenObjCXX/microsoft-abi-arc-param-order.mm
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenObjCXX/microsoft-abi-arc-param-order.mm?rev=343808&r1=343807&r2=343808&view=diff
==
--- cfe/trunk/test/CodeGenObjCXX/microsoft-abi-arc-param-order.mm (original)
+++ cfe/trunk/test/CodeGenObjCXX/microsoft-abi-arc-param-order.mm Thu Oct  4 
12:50:14 2018
@@ -9,7 +9,7 @@ struct A {
 
 // Verify that we dest

Re: r350920 - [Sema] Make canPassInRegisters return true if the CXXRecordDecl passed

[Shoaib Meenai via cfe-commits]

Just wanted to point out that r350920 is on the 8.0 release branch as well. I 
don't know if there are any additional considerations there.

On 1/31/19, 2:20 PM, "cfe-commits on behalf of John McCall via cfe-commits" 
 
wrote:



On 31 Jan 2019, at 16:57, Akira Hatanaka wrote:

> Would it be better if we disallowed trivial_abi if the class’ copy 
> and move destructors were all deleted (and revert r350920)? I think 
> that would make it easier to reason about when you are allowed to use 
> trivial_abi and what effect the attribute has (which is to override 
> the trivialness for the purpose of calls).
>
> Sorry for my late reply. It took a while to understand that the patch 
> I committed might not be the right way to fix the problem.

I'd be fine with that.  If nothing else, we can generalize it later if 
we decide that's an important use-case.

John.

>
>> On Jan 16, 2019, at 8:37 PM, John McCall via cfe-commits 
>>  wrote:
>>
>> On 16 Jan 2019, at 20:03, Richard Smith wrote:
>>
>>> On Wed, 16 Jan 2019 at 16:20, John McCall via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
 On 16 Jan 2019, at 18:32, Richard Smith wrote:

> On Wed, 16 Jan 2019 at 09:10, John McCall via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> On 16 Jan 2019, at 9:13, Aaron Ballman wrote:
>>
>>> On Wed, Jan 16, 2019 at 1:57 AM Akira Hatanaka 
>>> 
>>> wrote:

 Yes, the behavior of the compiler doesn’t match what’s 
 explained
 in the documentation anymore.

 Please take a look at the attached patch, which updates the
 documentation.
>>>
>>> Patch mostly LGTM, but I did have one wording suggestion.
>>>
 diff --git a/include/clang/Basic/AttrDocs.td
 b/include/clang/Basic/AttrDocs.td
 index 5773a92c9c..ca3cfcf9b2 100644
 --- a/include/clang/Basic/AttrDocs.td
 +++ b/include/clang/Basic/AttrDocs.td
 @@ -2478,15 +2478,20 @@ def TrivialABIDocs : Documentation {
   let Category = DocCatVariable;
   let Content = [{
 The ``trivial_abi`` attribute can be applied to a C++ class, 
 struct,
 or union.
 -It instructs the compiler to pass and return the type using 
 the C
 ABI for the
 +``trivial_abi`` has the following effects:
 +
 +- It instructs the compiler to pass and return the type using 
 the C
 ABI for the
 underlying type when the type would otherwise be considered
 non-trivial for the
 purpose of calls.
 -A class annotated with `trivial_abi` can have non-trivial
 destructors or copy/move constructors without automatically 
 becoming
 non-trivial for the purposes of calls. For example:
 +- It makes the destructor and copy and move constructors of 
 the
 class trivial
 +that would otherwise be considered non-trivial under the C++ 
 ABI
 rules.
>>>
>>> How about: It makes the destructor, copy constructors, and move
>>> constructors of the class trivial even if they would otherwise 
>>> be
>>> non-trivial under the C++ ABI rules.
>>
>> Let's not say that it makes them trivial, because it doesn't.  It 
>> causes
>> their immediate non-triviality to be ignored for the purposes of
>> deciding
>> whether the type can be passed in registers.
>>
>
> Given the attribute now forces the type to be passed in registers, 
> I
 think
> it'd be more to the point to say that it makes the triviality of 
> those
> special members be ignored when deciding whether to pass a type 
> with a
> subobject of this type in registers.

 Wait, it forces it to be passed in registers?  I thought the design
 was that it didn't override the non-trivial-abi-ness of subobjects;
 see all the discussion of trivially_relocatable.

>>>
>>> The attribute is ill-formed if applied to a class that has a 
>>> subobject that
>>> can't be passed in registers (or that has a vptr). And then as a 
>>> weird
>>> special case we don't instantiate the attribute when instantiating a 
>>> class
>>> if it would be ill-formed (well, we instantiate it and then remove 
>>> it
>>> again, but the effect is the same).
>>>
>>> The commit at the start of this email chain switches us from the 
>>> "just
>>> override the trivialness for the purposes of the A

Re: r350920 - [Sema] Make canPassInRegisters return true if the CXXRecordDecl passed

[Shoaib Meenai via cfe-commits]

+Hans for managing the 8.0 branch.

On 1/31/19, 4:15 PM, "ahatan...@apple.com on behalf of Akira Hatanaka" 
 wrote:

Reverted patch in r352822. I’ll send a new patch later that disallows 
trivial_abi on classes without non-deleted copy or move constructors.

> On Jan 31, 2019, at 3:52 PM, Richard Smith  wrote:
> 
> Given that there's uncertainty as to how to proceed and this patch
> affects the ABI, I would prefer that we revert it for trunk and 8.0.
> 
> The suggested alternative of disallowing trivial_abi in the case where
> all copy/move constructors are deleted seems reasonable to me.
> 
    > On Thu, 31 Jan 2019 at 14:31, Shoaib Meenai via cfe-commits
>  wrote:
>> 
>> Just wanted to point out that r350920 is on the 8.0 release branch as 
well. I don't know if there are any additional considerations there.
>> 
>> On 1/31/19, 2:20 PM, "cfe-commits on behalf of John McCall via 
cfe-commits"  wrote:
>> 
>> 
>> 
>>On 31 Jan 2019, at 16:57, Akira Hatanaka wrote:
>> 
>>> Would it be better if we disallowed trivial_abi if the class’ copy
>>> and move destructors were all deleted (and revert r350920)? I think
>>> that would make it easier to reason about when you are allowed to use
>>> trivial_abi and what effect the attribute has (which is to override
>>> the trivialness for the purpose of calls).
>>> 
>>> Sorry for my late reply. It took a while to understand that the patch
>>> I committed might not be the right way to fix the problem.
>> 
>>I'd be fine with that.  If nothing else, we can generalize it later if
>>we decide that's an important use-case.
>> 
>>John.
>> 
>>> 
>>>> On Jan 16, 2019, at 8:37 PM, John McCall via cfe-commits
>>>>  wrote:
>>>> 
>>>> On 16 Jan 2019, at 20:03, Richard Smith wrote:
>>>> 
>>>>> On Wed, 16 Jan 2019 at 16:20, John McCall via cfe-commits <
>>>>> cfe-commits@lists.llvm.org> wrote:
>>>>> 
>>>>>> On 16 Jan 2019, at 18:32, Richard Smith wrote:
>>>>>> 
>>>>>>> On Wed, 16 Jan 2019 at 09:10, John McCall via cfe-commits <
>>>>>>> cfe-commits@lists.llvm.org> wrote:
>>>>>>> 
>>>>>>>> On 16 Jan 2019, at 9:13, Aaron Ballman wrote:
>>>>>>>> 
>>>>>>>>> On Wed, Jan 16, 2019 at 1:57 AM Akira Hatanaka
>>>>>>>>> 
>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>> Yes, the behavior of the compiler doesn’t match what’s
>>>>>>>>>> explained
>>>>>>>>>> in the documentation anymore.
>>>>>>>>>> 
>>>>>>>>>> Please take a look at the attached patch, which updates the
>>>>>>>>>> documentation.
>>>>>>>>> 
>>>>>>>>> Patch mostly LGTM, but I did have one wording suggestion.
>>>>>>>>> 
>>>>>>>>>> diff --git a/include/clang/Basic/AttrDocs.td
>>>>>>>>>> b/include/clang/Basic/AttrDocs.td
>>>>>>>>>> index 5773a92c9c..ca3cfcf9b2 100644
>>>>>>>>>> --- a/include/clang/Basic/AttrDocs.td
>>>>>>>>>> +++ b/include/clang/Basic/AttrDocs.td
>>>>>>>>>> @@ -2478,15 +2478,20 @@ def TrivialABIDocs : Documentation {
>>>>>>>>>>  let Category = DocCatVariable;
>>>>>>>>>>  let Content = [{
>>>>>>>>>> The ``trivial_abi`` attribute can be applied to a C++ class,
>>>>>>>>>> struct,
>>>>>>>>>> or union.
>>>>>>>>>> -It instructs the compiler to pass and return the type using
>>>>>>>>>> the C
>>>>>>>>>> ABI for the
>>>>>>>>>> +``trivial_abi`` has the following effects:
>>>>>>>>>> +
>>>>>>>>>> +- It instructs the compiler to pass and return the type 

Re: r353590 - This reverts commit 1440a848a635849b97f7a5cfa0ecc40d37451f5b.

[Shoaib Meenai via cfe-commits]

I was gonna point to the directions for using llvm/utils/git-svn/git-svnrevert, 
but it looks like that script only works with git svn and not with the git 
monorepo. James, was updating the revert script something on your roadmap? If 
not, I'd be happy to take a stab at it (and I'm wondering if it makes sense to 
introduce a revert subcommand to `git llvm` rather than having a separate 
script).

On 2/8/19, 5:30 PM, "cfe-commits on behalf of Richard Smith via cfe-commits" 
 
wrote:

On Fri, 8 Feb 2019 at 16:45, Mikhail R. Gadelha via cfe-commits
 wrote:
> Author: mramalho
> Date: Fri Feb  8 16:46:12 2019
> New Revision: 353590
>
> URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D353590-26view-3Drev&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=aepigNtcB7YIT8UBidW_1L_WrJGW-Zw_5JscfbewUQw&s=HF64M7rSDlri8fYyPLRCpEDRRnw_8cw91dU3-ZX_HY4&e=
> Log:
> This reverts commit 1440a848a635849b97f7a5cfa0ecc40d37451f5b.
> and commit a1853e834c65751f92521f7481b15cf0365e796b.

Please include SVN revision numbers in revert messages until LLVM
moves over to git.

> They broke arm and aarch64
>
> Added:
> cfe/trunk/cmake/modules/FindZ3.cmake
> cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/SMTAPI.h
> cfe/trunk/lib/StaticAnalyzer/Core/Z3ConstraintManager.cpp
> Removed:
> cfe/trunk/lib/StaticAnalyzer/Core/SMTConstraintManager.cpp
> Modified:
> cfe/trunk/CMakeLists.txt
> cfe/trunk/include/clang/Config/config.h.cmake
> 
cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/SMTConstraintManager.h
> cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/SMTConv.h
> cfe/trunk/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
> cfe/trunk/lib/StaticAnalyzer/Core/CMakeLists.txt
> cfe/trunk/test/CMakeLists.txt
> cfe/trunk/test/lit.site.cfg.py.in
>
> Modified: cfe/trunk/CMakeLists.txt
> URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_cfe_trunk_CMakeLists.txt-3Frev-3D353590-26r1-3D353589-26r2-3D353590-26view-3Ddiff&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=aepigNtcB7YIT8UBidW_1L_WrJGW-Zw_5JscfbewUQw&s=PSdqknpf3IrSNcvN1YRqhUvqdPEQHudcT7ORCKdt2AY&e=
> 
==
> --- cfe/trunk/CMakeLists.txt (original)
> +++ cfe/trunk/CMakeLists.txt Fri Feb  8 16:46:12 2019
> @@ -411,9 +411,34 @@ option(CLANG_BUILD_TOOLS
>  option(CLANG_ENABLE_ARCMT "Build ARCMT." ON)
>  option(CLANG_ENABLE_STATIC_ANALYZER "Build static analyzer." ON)
>
> +set(CLANG_ANALYZER_Z3_INSTALL_DIR "" CACHE STRING "Install directory of 
the Z3 solver.")
> +
> +find_package(Z3 4.7.1)
> +
> +if (CLANG_ANALYZER_Z3_INSTALL_DIR)
> +  if (NOT Z3_FOUND)
> +message(FATAL_ERROR "Z3 4.7.1 has not been found in 
CLANG_ANALYZER_Z3_INSTALL_DIR: ${CLANG_ANALYZER_Z3_INSTALL_DIR}.")
> +  endif()
> +endif()
> +
> +set(CLANG_ANALYZER_ENABLE_Z3_SOLVER_DEFAULT "${Z3_FOUND}")
> +
> +option(CLANG_ANALYZER_ENABLE_Z3_SOLVER
> +  "Enable Support for the Z3 constraint solver in the Clang Static 
Analyzer."
> +  ${CLANG_ANALYZER_ENABLE_Z3_SOLVER_DEFAULT}
> +)
> +
> +if (CLANG_ANALYZER_ENABLE_Z3_SOLVER)
> +  if (NOT Z3_FOUND)
> +message(FATAL_ERROR "CLANG_ANALYZER_ENABLE_Z3_SOLVER cannot be 
enabled when Z3 is not available.")
> +  endif()
> +
> +  set(CLANG_ANALYZER_WITH_Z3 1)
> +endif()
> +
>  option(CLANG_ENABLE_PROTO_FUZZER "Build Clang protobuf fuzzer." OFF)
>
> -if(NOT CLANG_ENABLE_STATIC_ANALYZER AND CLANG_ENABLE_ARCMT)
> +if(NOT CLANG_ENABLE_STATIC_ANALYZER AND (CLANG_ENABLE_ARCMT OR 
CLANG_ANALYZER_ENABLE_Z3_SOLVER))
>message(FATAL_ERROR "Cannot disable static analyzer while enabling 
ARCMT or Z3")
>  endif()
>
>
> Added: cfe/trunk/cmake/modules/FindZ3.cmake
> URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_cfe_trunk_cmake_modules_FindZ3.cmake-3Frev-3D353590-26view-3Dauto&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=aepigNtcB7YIT8UBidW_1L_WrJGW-Zw_5JscfbewUQw&s=yw58_RYhB1Z7hXxc4_EPOOivPWp9UOdBBnyvwRHLe7M&e=
> 
==
> --- cfe/trunk/cmake/modules/FindZ3.cmake (added)
> +++ cfe/trunk/cmake/modules/FindZ3.cmake Fri Feb  8 16:46:12 2019
> @@ -0,0 +1,51 @@
> +# Looking for Z3 in CLANG_ANALYZER_Z3_INSTALL_DIR
> +find_path(Z3_INCLUDE_DIR NAMES z3.h
> +   NO_DEFAULT_PATH
> +   PATHS ${CLANG_ANALYZER_Z3_INSTALL_DIR}/include
> +   PATH_SUFFIXES libz3 z3
> +   )
> +
> +find_library(Z3_LIBRARIES NAMES z3 libz3
> +   NO_DEFAULT_PATH
> +   PATHS ${CLANG_ANALYZER_Z3_INST

Re: r353976 - [Sema] Delay checking whether objc_designated_initializer is being applied to an init method

[Shoaib Meenai via cfe-commits]

Should this be considered for 8.0? It's late in the branch and I don't know how 
prevalent the issue being fixed is, but it caught my eye.

From: cfe-commits  on behalf of Erik 
Pilkington via cfe-commits 
Reply-To: Erik Pilkington 
Date: Wednesday, February 13, 2019 at 12:32 PM
To: "cfe-commits@lists.llvm.org" 
Subject: r353976 - [Sema] Delay checking whether objc_designated_initializer is 
being applied to an init method

Author: epilk
Date: Wed Feb 13 12:32:37 2019
New Revision: 353976

URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D353976-26view-3Drev&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=SS1gIdRrXBd-rCKs5rBEEPmEevgsHAkkERh1ko2vPEc&s=W245MwgFUCCNz9Ug2Tc0dY5lJ35n855YKxo_fwmicxM&e=
Log:
[Sema] Delay checking whether objc_designated_initializer is being applied to 
an init method

This fixes a regression that was caused by r335084, which reversed
the order that attributes are applied. objc_method_family can change
whether a method is an init method, so the order that these
attributes are applied matters. The commit fixes this by delaying the
init check until after all attributes have been applied.

rdar://47829358

Differential revision: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D58152&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=SS1gIdRrXBd-rCKs5rBEEPmEevgsHAkkERh1ko2vPEc&s=-4Nd4QBW0KxmFdmqS-2w90_5AoHoRQbdwd8K3Z4JzuY&e=

Modified:
cfe/trunk/include/clang/Basic/Attr.td
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/lib/Sema/SemaDeclAttr.cpp
cfe/trunk/test/Misc/pragma-attribute-supported-attributes-list.test
cfe/trunk/test/SemaObjC/attr-designated-init.m

Modified: cfe/trunk/include/clang/Basic/Attr.td
URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_cfe_trunk_include_clang_Basic_Attr.td-3Frev-3D353976-26r1-3D353975-26r2-3D353976-26view-3Ddiff&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=SS1gIdRrXBd-rCKs5rBEEPmEevgsHAkkERh1ko2vPEc&s=tgqq2EylVgj2FgGry6ZO46KA6teeO-xJ1TlvJWvEy6Q&e=
==
--- cfe/trunk/include/clang/Basic/Attr.td (original)
+++ cfe/trunk/include/clang/Basic/Attr.td Wed Feb 13 12:32:37 2019
@@ -102,13 +102,6 @@ def ObjCInstanceMethod : SubsetSubjectisInstanceMethod()}],
"Objective-C instance methods">;
-def ObjCInterfaceDeclInitMethod : SubsetSubjectgetMethodFamily() == OMF_init &&
- (isa(S->getDeclContext()) 
||
-  (isa(S->getDeclContext()) 
&&
-
cast(S->getDeclContext())->IsClassExtension()))}],
-"init methods of interface or class extension declarations">;
-
def Struct : SubsetSubjectisUnion()}], "structs">;
@@ -1786,7 +1779,7 @@ def ObjCExplicitProtocolImpl : Inheritab
def ObjCDesignatedInitializer : Attr {
   let Spellings = [Clang<"objc_designated_initializer">];
-  let Subjects = SubjectList<[ObjCInterfaceDeclInitMethod], ErrorDiag>;
+  let Subjects = SubjectList<[ObjCMethod], ErrorDiag>;
   let Documentation = [Undocumented];
}

Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_cfe_trunk_include_clang_Basic_DiagnosticSemaKinds.td-3Frev-3D353976-26r1-3D353975-26r2-3D353976-26view-3Ddiff&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=SS1gIdRrXBd-rCKs5rBEEPmEevgsHAkkERh1ko2vPEc&s=d6MOBmrgs96qcCuR_Q5j82acKFzDnHxqDkcDiUM_IIk&e=
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Wed Feb 13 12:32:37 
2019
@@ -3481,6 +3481,9 @@ def warn_objc_secondary_init_missing_ini
def warn_objc_implementation_missing_designated_init_override : Warning<
   "method override for the designated initializer of the superclass 
%objcinstance0 not found">,
   InGroup;
+def err_designated_init_attr_non_init : Error<
+  "'objc_designated_initializer' attribute only applies to init methods "
+  "of interface or class extension declarations">;
// objc_bridge attribute diagnostics.
def err_objc_attr_not_id : Error<

Modified: cfe/trunk/lib/Sema/SemaDeclAttr.cpp
URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_cfe_trunk_lib_Sema_SemaDeclAttr.cpp-3Frev-3D353976-26r1-3D353975-26r2-3D353976-26view-3Ddiff&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=SS1gIdRrXBd-rCKs5rBEEPmEevgsHAkkERh1ko2vPEc&s=n3Lrsayy7oQTOdjbionMiki15N4Z4kxZaPSw5Fn4uww&e=
==
--- cfe/trunk/lib/Sema/SemaDeclAttr.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDeclAttr.cpp Wed Feb 13 12:32:37 2019
@@ -5249,11 +5249,22 @@ static void handleObjCBridgeRelatedAttr(
static 

Re: r354074 - [Sema] Fix-up a -Wfloat-conversion diagnostic

[Shoaib Meenai via cfe-commits]

I don't think Hans ended up getting added to the recipients? (Unless Outlook is 
being silly or it was a BCC, in which case I apologize for the spam.)

On 2/14/19, 3:16 PM, "cfe-commits on behalf of Erik Pilkington via 
cfe-commits"  wrote:

Hans, can you merge this diagnostic regression fix into LLVM 8?

Thanks!

> On Feb 14, 2019, at 2:48 PM, Erik Pilkington via cfe-commits 
 wrote:
> 
> Author: epilk
> Date: Thu Feb 14 14:48:01 2019
> New Revision: 354074
> 
> URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D354074-26view-3Drev&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=DO5cOhG2p0lJyoGW_0kLao-RuuAsjuXhKcexb8Du4S8&s=pHB5-cVv8xjeI6USEYPO7XIpvGQena6iXejLqlviUes&e=
> Log:
> [Sema] Fix-up a -Wfloat-conversion diagnostic
> 
> We were warning on valid ObjC property reference exprs, and passing
> in the wrong arguments to DiagnoseFloatingImpCast (leading to a badly
> worded diagnostic).
> 
> rdar://47644670
> 
> Differential revision: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D58145&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=DO5cOhG2p0lJyoGW_0kLao-RuuAsjuXhKcexb8Du4S8&s=ohcFH9VMyZgBARLdvdnbJXaIkchLNxHzkt9R3y_Dy4E&e=
> 
> Modified:
>cfe/trunk/lib/Sema/SemaChecking.cpp
>cfe/trunk/test/SemaCXX/warn-float-conversion.cpp
>cfe/trunk/test/SemaObjC/conversion.m
> 
> Modified: cfe/trunk/lib/Sema/SemaChecking.cpp
> URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_cfe_trunk_lib_Sema_SemaChecking.cpp-3Frev-3D354074-26r1-3D354073-26r2-3D354074-26view-3Ddiff&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=DO5cOhG2p0lJyoGW_0kLao-RuuAsjuXhKcexb8Du4S8&s=noPXZAz2o1d7SWaLkeUQGcFR9mRffBwYz07dWx-vUsM&e=
> 
==
> --- cfe/trunk/lib/Sema/SemaChecking.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaChecking.cpp Thu Feb 14 14:48:01 2019
> @@ -10624,16 +10624,16 @@ static void AnalyzeCompoundAssignment(Se
>   // The below checks assume source is floating point.
>   if (!ResultBT || !RBT || !RBT->isFloatingPoint()) return;
> 
> -  // If source is floating point but target is not.
> -  if (!ResultBT->isFloatingPoint())
> -return DiagnoseFloatingImpCast(S, E, E->getRHS()->getType(),
> -   E->getExprLoc());
> -
> -  // If both source and target are floating points.
> -  // Builtin FP kinds are ordered by increasing FP rank.
> -  if (ResultBT->getKind() < RBT->getKind() &&
> -  // We don't want to warn for system macro.
> -  !S.SourceMgr.isInSystemMacro(E->getOperatorLoc()))
> +  // If source is floating point but target is an integer.
> +  if (ResultBT->isInteger())
> +DiagnoseImpCast(S, E, E->getRHS()->getType(), E->getLHS()->getType(),
> +E->getExprLoc(), diag::warn_impcast_float_integer);
> +  // If both source and target are floating points. Builtin FP kinds are 
ordered
> +  // by increasing FP rank. FIXME: except _Float16, we currently emit a 
bogus
> +  // warning.
> +  else if (ResultBT->isFloatingPoint() && ResultBT->getKind() < 
RBT->getKind() &&
> +   // We don't want to warn for system macro.
> +   !S.SourceMgr.isInSystemMacro(E->getOperatorLoc()))
> // warn about dropping FP rank.
> DiagnoseImpCast(S, E->getRHS(), E->getLHS()->getType(), 
E->getOperatorLoc(),
> diag::warn_impcast_float_result_precision);
> 
> Modified: cfe/trunk/test/SemaCXX/warn-float-conversion.cpp
> URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_cfe_trunk_test_SemaCXX_warn-2Dfloat-2Dconversion.cpp-3Frev-3D354074-26r1-3D354073-26r2-3D354074-26view-3Ddiff&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=DO5cOhG2p0lJyoGW_0kLao-RuuAsjuXhKcexb8Du4S8&s=LPTdxv5StV8_bmyhdyjrJ6m4L5puzINH3F5R2azFXIc&e=
> 
==
> --- cfe/trunk/test/SemaCXX/warn-float-conversion.cpp (original)
> +++ cfe/trunk/test/SemaCXX/warn-float-conversion.cpp Thu Feb 14 14:48:01 
2019
> @@ -44,17 +44,17 @@ void Convert(float f, double d, long dou
> void CompoundAssignment() {
>   int x = 3;
> 
> -  x += 1.234;  //expected-warning{{conversion}}
> -  x -= -0.0;  //expected-warning{{conversion}}
> -  x *= 1.1f;  //expected-warning{{conversion}}
> -  x /= -2.2f;  //expected-warning{{conversion}}
> +  x += 1.234; // expected-warning {{implicit conversion turns 
floating-point number into integer: 'double' to 'int'}}
> +  x -= -0.0;  // expected-warning {{implicit conversion turns 
floating-point number into integer: 'double' to '

r354140 - [clang] Create install targets for non-shared libraries

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Fri Feb 15 07:59:02 2019
New Revision: 354140

URL: http://llvm.org/viewvc/llvm-project?rev=354140&view=rev
Log:
[clang] Create install targets for non-shared libraries

I don't see a reason for these to not have install targets created,
which in turn allows them to be bundled in distributions. This doesn't
affect the "install" target, since that just runs all CMake install
rules (and we were already creating install rules for these).

Differential Revision: https://reviews.llvm.org/D58268

Modified:
cfe/trunk/cmake/modules/AddClang.cmake

Modified: cfe/trunk/cmake/modules/AddClang.cmake
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/cmake/modules/AddClang.cmake?rev=354140&r1=354139&r2=354140&view=diff
==
--- cfe/trunk/cmake/modules/AddClang.cmake (original)
+++ cfe/trunk/cmake/modules/AddClang.cmake Fri Feb 15 07:59:02 2019
@@ -103,7 +103,7 @@ macro(add_clang_library name)
 ARCHIVE DESTINATION lib${LLVM_LIBDIR_SUFFIX}
 RUNTIME DESTINATION bin)
 
-  if (${ARG_SHARED} AND NOT CMAKE_CONFIGURATION_TYPES)
+  if (NOT CMAKE_CONFIGURATION_TYPES)
 add_llvm_install_targets(install-${name}
  DEPENDS ${name}
  COMPONENT ${name})


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

r354141 - [clang] Add build and install targets for clang libraries

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Fri Feb 15 07:59:04 2019
New Revision: 354141

URL: http://llvm.org/viewvc/llvm-project?rev=354141&view=rev
Log:
[clang] Add build and install targets for clang libraries

This is modeled after the existing llvm-libraries target. It's a
convenient way to include all clang libraries in a distribution.

This differs slightly from the llvm-libraries target in that it adds any
library added via add_clang_library, whereas llvm-libraries only
includes targets added via add_llvm_library that didn't use the MODULE
or BUILDTREE_ONLY arguments. add_clang_library doesn't appear to have
any equivalents of those arguments, so the conditions don't apply.

Differential Revision: https://reviews.llvm.org/D58269

Modified:
cfe/trunk/CMakeLists.txt
cfe/trunk/cmake/modules/AddClang.cmake

Modified: cfe/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/CMakeLists.txt?rev=354141&r1=354140&r2=354141&view=diff
==
--- cfe/trunk/CMakeLists.txt (original)
+++ cfe/trunk/CMakeLists.txt Fri Feb 15 07:59:04 2019
@@ -543,6 +543,27 @@ if( CLANG_INCLUDE_DOCS )
   add_subdirectory(docs)
 endif()
 
+# Custom target to install all clang libraries.
+add_custom_target(clang-libraries)
+set_target_properties(clang-libraries PROPERTIES FOLDER "Misc")
+
+if(NOT CMAKE_CONFIGURATION_TYPES)
+  add_llvm_install_targets(install-clang-libraries
+   DEPENDS clang-libraries
+   COMPONENT clang-libraries)
+endif()
+
+get_property(CLANG_LIBS GLOBAL PROPERTY CLANG_LIBS)
+if(CLANG_LIBS)
+  list(REMOVE_DUPLICATES CLANG_LIBS)
+  foreach(lib ${CLANG_LIBS})
+add_dependencies(clang-libraries ${lib})
+if(NOT CMAKE_CONFIGURATION_TYPES)
+  add_dependencies(install-clang-libraries install-${lib})
+endif()
+  endforeach()
+endif()
+
 add_subdirectory(cmake/modules)
 
 if(CLANG_STAGE)

Modified: cfe/trunk/cmake/modules/AddClang.cmake
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/cmake/modules/AddClang.cmake?rev=354141&r1=354140&r2=354141&view=diff
==
--- cfe/trunk/cmake/modules/AddClang.cmake (original)
+++ cfe/trunk/cmake/modules/AddClang.cmake Fri Feb 15 07:59:04 2019
@@ -108,6 +108,8 @@ macro(add_clang_library name)
  DEPENDS ${name}
  COMPONENT ${name})
   endif()
+
+  set_property(GLOBAL APPEND PROPERTY CLANG_LIBS ${name})
 endif()
 set_property(GLOBAL APPEND PROPERTY CLANG_EXPORTS ${name})
   else()


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

r354525 - [clang] Switch to LLVM_ENABLE_IDE

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Wed Feb 20 15:08:43 2019
New Revision: 354525

URL: http://llvm.org/viewvc/llvm-project?rev=354525&view=rev
Log:
[clang] Switch to LLVM_ENABLE_IDE

r344555 switched LLVM to guarding install targets with LLVM_ENABLE_IDE
instead of CMAKE_CONFIGURATION_TYPES, which expresses the intent more
directly and can be overridden by a user. Make the corresponding change
in clang. LLVM_ENABLE_IDE is computed by HandleLLVMOptions, so it should
be available for both standalone and integrated builds.

Differential Revision: https://reviews.llvm.org/D58284

Modified:
cfe/trunk/CMakeLists.txt
cfe/trunk/cmake/modules/AddClang.cmake
cfe/trunk/lib/Headers/CMakeLists.txt
cfe/trunk/tools/c-index-test/CMakeLists.txt
cfe/trunk/tools/diagtool/CMakeLists.txt
cfe/trunk/tools/libclang/CMakeLists.txt

Modified: cfe/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/CMakeLists.txt?rev=354525&r1=354524&r2=354525&view=diff
==
--- cfe/trunk/CMakeLists.txt (original)
+++ cfe/trunk/CMakeLists.txt Wed Feb 20 15:08:43 2019
@@ -552,7 +552,7 @@ endif()
 add_custom_target(clang-libraries)
 set_target_properties(clang-libraries PROPERTIES FOLDER "Misc")
 
-if(NOT CMAKE_CONFIGURATION_TYPES)
+if(NOT LLVM_ENABLE_IDE)
   add_llvm_install_targets(install-clang-libraries
DEPENDS clang-libraries
COMPONENT clang-libraries)
@@ -563,7 +563,7 @@ if(CLANG_LIBS)
   list(REMOVE_DUPLICATES CLANG_LIBS)
   foreach(lib ${CLANG_LIBS})
 add_dependencies(clang-libraries ${lib})
-if(NOT CMAKE_CONFIGURATION_TYPES)
+if(NOT LLVM_ENABLE_IDE)
   add_dependencies(install-clang-libraries install-${lib})
 endif()
   endforeach()

Modified: cfe/trunk/cmake/modules/AddClang.cmake
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/cmake/modules/AddClang.cmake?rev=354525&r1=354524&r2=354525&view=diff
==
--- cfe/trunk/cmake/modules/AddClang.cmake (original)
+++ cfe/trunk/cmake/modules/AddClang.cmake Wed Feb 20 15:08:43 2019
@@ -103,7 +103,7 @@ macro(add_clang_library name)
 ARCHIVE DESTINATION lib${LLVM_LIBDIR_SUFFIX}
 RUNTIME DESTINATION bin)
 
-  if (NOT CMAKE_CONFIGURATION_TYPES)
+  if (NOT LLVM_ENABLE_IDE)
 add_llvm_install_targets(install-${name}
  DEPENDS ${name}
  COMPONENT ${name})
@@ -147,7 +147,7 @@ macro(add_clang_tool name)
   RUNTIME DESTINATION bin
   COMPONENT ${name})
 
-if(NOT CMAKE_CONFIGURATION_TYPES)
+if(NOT LLVM_ENABLE_IDE)
   add_llvm_install_targets(install-${name}
DEPENDS ${name}
COMPONENT ${name})

Modified: cfe/trunk/lib/Headers/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/CMakeLists.txt?rev=354525&r1=354524&r2=354525&view=diff
==
--- cfe/trunk/lib/Headers/CMakeLists.txt (original)
+++ cfe/trunk/lib/Headers/CMakeLists.txt Wed Feb 20 15:08:43 2019
@@ -178,7 +178,7 @@ install(
   PERMISSIONS OWNER_READ OWNER_WRITE GROUP_READ WORLD_READ
   DESTINATION 
lib${LLVM_LIBDIR_SUFFIX}/clang/${CLANG_VERSION}/include/cuda_wrappers)
 
-if (NOT CMAKE_CONFIGURATION_TYPES) # don't add this for IDE's.
+if (NOT LLVM_ENABLE_IDE)
   add_llvm_install_targets(install-clang-headers
DEPENDS clang-headers
COMPONENT clang-headers)

Modified: cfe/trunk/tools/c-index-test/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/c-index-test/CMakeLists.txt?rev=354525&r1=354524&r2=354525&view=diff
==
--- cfe/trunk/tools/c-index-test/CMakeLists.txt (original)
+++ cfe/trunk/tools/c-index-test/CMakeLists.txt Wed Feb 20 15:08:43 2019
@@ -61,7 +61,7 @@ if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY)
 RUNTIME DESTINATION "${INSTALL_DESTINATION}"
 COMPONENT c-index-test)
 
-  if (NOT CMAKE_CONFIGURATION_TYPES) # don't add this for IDE's.
+  if (NOT LLVM_ENABLE_IDE)
 add_llvm_install_targets(install-c-index-test
  DEPENDS c-index-test
  COMPONENT c-index-test)

Modified: cfe/trunk/tools/diagtool/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/diagtool/CMakeLists.txt?rev=354525&r1=354524&r2=354525&view=diff
==
--- cfe/trunk/tools/diagtool/CMakeLists.txt (original)
+++ cfe/trunk/tools/diagtool/CMakeLists.txt Wed Feb 20 15:08:43 2019
@@ -23,7 +23,7 @@ if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY)
 COMPONENT diagtool
 RUNTIME DESTINATION bin)
 
-  if (NOT CMAKE_CONFIGURATION_TYPES)
+  if (NOT LLVM_ENABLE_IDE)
 add_llvm_

r354527 - [clang] Add CMake target for installing clang's CMake exports

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Wed Feb 20 15:16:15 2019
New Revision: 354527

URL: http://llvm.org/viewvc/llvm-project?rev=354527&view=rev
Log:
[clang] Add CMake target for installing clang's CMake exports

This mirrors LLVM's install-cmake-exports target.

Differential Revision: https://reviews.llvm.org/D58480

Modified:
cfe/trunk/cmake/modules/CMakeLists.txt

Modified: cfe/trunk/cmake/modules/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/cmake/modules/CMakeLists.txt?rev=354527&r1=354526&r2=354527&view=diff
==
--- cfe/trunk/cmake/modules/CMakeLists.txt (original)
+++ cfe/trunk/cmake/modules/CMakeLists.txt Wed Feb 20 15:16:15 2019
@@ -55,10 +55,19 @@ set(CLANG_CONFIG_EXPORTS_FILE)
 if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY)
   get_property(clang_has_exports GLOBAL PROPERTY CLANG_HAS_EXPORTS)
   if(clang_has_exports)
-install(EXPORT ClangTargets DESTINATION ${CLANG_INSTALL_PACKAGE_DIR})
+install(EXPORT ClangTargets DESTINATION ${CLANG_INSTALL_PACKAGE_DIR}
+COMPONENT clang-cmake-exports)
   endif()
 
   install(FILES
 ${CMAKE_CURRENT_BINARY_DIR}/CMakeFiles/ClangConfig.cmake
-DESTINATION ${CLANG_INSTALL_PACKAGE_DIR})
+DESTINATION ${CLANG_INSTALL_PACKAGE_DIR}
+COMPONENT clang-cmake-exports)
+
+  if(NOT LLVM_ENABLE_IDE)
+# Add a dummy target so this can be used with LLVM_DISTRIBUTION_COMPONENTS
+add_custom_target(clang-cmake-exports)
+add_llvm_install_targets(install-clang-cmake-exports
+ COMPONENT clang-cmake-exports)
+  endif()
 endif()


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

Re: [libcxxabi] r308470 - Drop 'svn' suffix from version number.

[Shoaib Meenai via cfe-commits]

Note that Reid restored the old behavior in r312043.

Configuring with -DLLVM_APPEND_VC_REV=OFF should also restore the old
behavior, I believe.

On 9/9/17, 1:55 PM, "cfe-commits on behalf of Dimitry Andric via cfe-commits" 
 
wrote:

On 19 Jul 2017, at 16:04, Hans Wennborg via cfe-commits 
 wrote:
> 
> Author: hans
> Date: Wed Jul 19 07:04:19 2017
> New Revision: 308470
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=308470&view=rev
> Log:
> Drop 'svn' suffix from version number.

[Replying to this commit, since I don't have r308469 (which does the same 
for llvm itself) in my mailboxes.]

Note this approach isn't effective anymore after Rafael's
https://reviews.llvm.org/rL306858, which turns on the LLVM_APPEND_VC_REV
option by default.

The handling of that option will overwrite the PACKAGE_VERSION value set
earlier in CMakeLists.txt, with the value returned from
add_version_info_from_vcs().  When using Subversion, that will always be
of the form X.Y.Zsvn-rNN.

I noticed this when preparing the 5.0.0 final import into FreeBSD, where
for example "opt -version" outputs:

LLVM (http://llvm.org/):
  LLVM version 5.0.0svn-r312559
  Optimized build with assertions.
  Default target: x86_64-unknown-freebsd12.0
  Host CPU: ivybridge

-Dimitry



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

[libcxx] r313284 - [libc++] Prevent stale site configuration headers

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Thu Sep 14 11:23:43 2017
New Revision: 313284

URL: http://llvm.org/viewvc/llvm-project?rev=313284&view=rev
Log:
[libc++] Prevent stale site configuration headers

If we define cmake macros that require a site config, and then undefine
all such macros, a stale site config header will be left behind.
Explicitly delete any generate site config if we don't need one to avoid
this.

Differential Revision: https://reviews.llvm.org/D36720

Modified:
libcxx/trunk/CMakeLists.txt

Modified: libcxx/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.txt?rev=313284&r1=313283&r2=313284&view=diff
==
--- libcxx/trunk/CMakeLists.txt (original)
+++ libcxx/trunk/CMakeLists.txt Thu Sep 14 11:23:43 2017
@@ -615,9 +615,10 @@ if (DEFINED WIN32 AND LIBCXX_ENABLE_STAT
   config_define(ON _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS)
 endif()
 
+set(site_config_path "${LIBCXX_BINARY_DIR}/__config_site")
 if (LIBCXX_NEEDS_SITE_CONFIG)
   configure_file("include/__config_site.in"
- "${LIBCXX_BINARY_DIR}/__config_site"
+ "${site_config_path}"
  @ONLY)
 
   # Provide the config definitions by included the generated __config_site
@@ -627,6 +628,11 @@ if (LIBCXX_NEEDS_SITE_CONFIG)
   else()
 add_compile_flags("-include ${LIBCXX_BINARY_DIR}/__config_site")
   endif()
+else()
+  if (EXISTS "${site_config_path}")
+message(STATUS "Removing stale site configuration ${site_config_path}")
+file(REMOVE "${site_config_path}")
+  endif()
 endif()
 
 
#===


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

[libcxx] r313345 - [libc++] Remove unnecessary struct tag

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Thu Sep 14 23:19:31 2017
New Revision: 313345

URL: http://llvm.org/viewvc/llvm-project?rev=313345&view=rev
Log:
[libc++] Remove unnecessary struct tag

It causes warnings about mismatched tags, and it's not needed.

Modified:
libcxx/trunk/include/typeinfo

Modified: libcxx/trunk/include/typeinfo
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/typeinfo?rev=313345&r1=313344&r2=313345&view=diff
==
--- libcxx/trunk/include/typeinfo (original)
+++ libcxx/trunk/include/typeinfo Thu Sep 14 23:19:31 2017
@@ -97,7 +97,7 @@ class _LIBCPP_EXCEPTION_ABI type_info
   const char __decorated_name[1];
 } __data;
 
-int __compare(const struct type_info &__rhs) const _NOEXCEPT;
+int __compare(const type_info &__rhs) const _NOEXCEPT;
 #endif // _LIBCPP_ABI_MICROSOFT
 
 protected:


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

[libcxx] r313377 - [libc++] Account for Microsoft CRT const overloads

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Fri Sep 15 11:49:34 2017
New Revision: 313377

URL: http://llvm.org/viewvc/llvm-project?rev=313377&view=rev
Log:
[libc++] Account for Microsoft CRT const overloads

Microsoft's CRT already provides the const overloads, and it defines the
`_CRT_CONST_CORRECT_OVERLOADS` macro to indicate their presence. Check
for this macro before attempting to define our own const-correct
overloads, to avoid compiler warnings about casts dropping const
qualifiers.

Modified:
libcxx/trunk/include/wchar.h

Modified: libcxx/trunk/include/wchar.h
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/wchar.h?rev=313377&r1=313376&r2=313377&view=diff
==
--- libcxx/trunk/include/wchar.h (original)
+++ libcxx/trunk/include/wchar.h Fri Sep 15 11:49:34 2017
@@ -125,6 +125,10 @@ size_t wcsrtombs(char* restrict dst, con
 #  if __GLIBC_PREREQ(2, 10)
 #define _LIBCPP_WCHAR_H_HAS_CONST_OVERLOADS 1
 #  endif
+#elif defined(_LIBCPP_MSVCRT)
+#  if defined(_CRT_CONST_CORRECT_OVERLOADS)
+#define _LIBCPP_WCHAR_H_HAS_CONST_OVERLOADS 1
+#  endif
 #endif
 
 #if defined(__cplusplus) && !defined(_LIBCPP_WCHAR_H_HAS_CONST_OVERLOADS) && 
defined(_LIBCPP_PREFERRED_OVERLOAD)


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

r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Thu Jul 11 14:20:38 2019
New Revision: 365825

URL: http://llvm.org/viewvc/llvm-project?rev=365825&view=rev
Log:
[clang-shlib] Fix clang-shlib for PRIVATE dependencies

Any static library with a PRIVATE dependency ends up with a
$ generator expression in its INTERFACE_LINK_LIBRARIES,
which won't be evaluated by the $, so we end up
with an unevaluated generator expression in the generated build file and
Ninja chokes on the dollar sign. Just use the static library directly
for its dependencies instead of trying to propagate dependencies
manually.

Differential Revision: https://reviews.llvm.org/D64579

Modified:
cfe/trunk/tools/clang-shlib/CMakeLists.txt

Modified: cfe/trunk/tools/clang-shlib/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/clang-shlib/CMakeLists.txt?rev=365825&r1=365824&r2=365825&view=diff
==
--- cfe/trunk/tools/clang-shlib/CMakeLists.txt (original)
+++ cfe/trunk/tools/clang-shlib/CMakeLists.txt Thu Jul 11 14:20:38 2019
@@ -7,8 +7,35 @@ get_property(clang_libs GLOBAL PROPERTY
 
 foreach (lib ${clang_libs})
   list(APPEND _OBJECTS $)
-  list(APPEND _DEPS $)
-  list(APPEND _DEPS $)
+  # Use the static library for its dependencies. The objects that constitute 
the
+  # static library will appear on the link line before the library, so it'll
+  # just be ignored, but the dependencies of the library will still be linked
+  # correctly.
+  #
+  # We could propagate the dependencies manually using the library's
+  # INTERFACE_LINK_LIBRARIES property, but that will contain $
+  # generator expressions if a static library has a private dependency, so we
+  # can't use a $ generator expression to get the property
+  # (since it wouldn't evaluate any generator expressions inside the property).
+  # We could use get_property and do string manipulation to manually evaluate
+  # the $, but that would miss any dependencies added after we
+  # evaluate the get_property. We could also use the LINK_LIBRARIES property
+  # instead, which should be free of any generator expressions, but that's
+  # technically incorrect (it'd most likely work fine in practice, but still).
+  #
+  # Another alternative would be to use --whole-archive or equivalent instead 
of
+  # using the object library at all. However, CMake reorders static libraries 
on
+  # the link line so that a library appears after all its dependents, which can
+  # reorder static libraries out of their --whole-archive --no-whole-archive
+  # sandwich. It's really hard to avoid that reordering while still propagating
+  # dependencies, which defeats the whole point.
+  #
+  # The ideal solution here is to bump our minimum CMake requirement to 3.12,
+  # which adds support for dependencies on object libraries. Until then, 
linking
+  # both the object and the static libraries seems like the least bad solution.
+  #
+  # TODO: Rework this when we bump our minimum CMake version to 3.12 or newer.
+  list(APPEND _DEPS ${lib})
 endforeach ()
 
 add_clang_library(clang_shared


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

Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies

[Shoaib Meenai via cfe-commits]

Oops, sorry about the breakage.

Chris, aren't BUILD_SHARED_LIBS and the combined Clang dylib incompatible? 
Should we disable building the latter if the former is set?

From: Alex Bradbury 
Date: Friday, July 12, 2019 at 2:02 AM
To: Shoaib Meenai 
Cc: cfe-commits 
Subject: Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies

On Thu, 11 Jul 2019 at 22:20, Shoaib Meenai via cfe-commits
mailto:cfe-commits@lists.llvm.org>> wrote:

Author: smeenai
Date: Thu Jul 11 14:20:38 2019
New Revision: 365825

URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D365825-26view-3Drev&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=ETCU2JhfBcjWz-nbe6LUVSRQR0T1f3wCzxLIhKlMmQo&s=R9NSZG1XQDVSiE0wJUgb1kMUrG6bJkG3v5GDcTdkpAk&e=
Log:
[clang-shlib] Fix clang-shlib for PRIVATE dependencies

Any static library with a PRIVATE dependency ends up with a
$ generator expression in its INTERFACE_LINK_LIBRARIES,
which won't be evaluated by the $, so we end up
with an unevaluated generator expression in the generated build file and
Ninja chokes on the dollar sign. Just use the static library directly
for its dependencies instead of trying to propagate dependencies
manually.

Differential Revision: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D64579&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=ETCU2JhfBcjWz-nbe6LUVSRQR0T1f3wCzxLIhKlMmQo&s=mutN2zF1KixMEVFjNzG_Q7iVJzG5ECbrU4tX3AKWLVQ&e=

This seems to break a -DBUILD_SHARED_LIBS build for me. It fails at
the point of linking lib/libclang_shared.so.9svn with errors like:
ld.lld: error: undefined symbol: llvm::llvm_unreachable_internal(char
const*, char const*, unsigned int)
referenced by Attributes.cpp:34 
(/home/asb/llvm-project/clang/lib/Basic/Attributes.cpp:34)
   
tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Attributes.cpp.o:(clang::attr::getSubjectMatchRuleSpelling(clang::attr::SubjectMatchRule))

ld.lld: error: undefined symbol: llvm::llvm_unreachable_internal(char
const*, char const*, unsigned int)
referenced by TargetCXXABI.h:168 
(/home/asb/llvm-project/clang/include/clang/Basic/TargetCXXABI.h:168)
   
tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Attributes.cpp.o:(clang::TargetCXXABI::isMicrosoft()
 const)

ld.lld: error: undefined symbol: llvm::llvm_unreachable_internal(char
const*, char const*, unsigned int)
referenced by TargetCXXABI.h:149 
(/home/asb/llvm-project/clang/include/clang/Basic/TargetCXXABI.h:149)
   
tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Attributes.cpp.o:(clang::TargetCXXABI::isItaniumFamily()
 const)

ld.lld: error: undefined symbol: llvm::EnableABIBreakingChecks
referenced by Attributes.cpp
   
tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Attributes.cpp.o:(llvm::VerifyEnableABIBreakingChecks)

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

Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies

[Shoaib Meenai via cfe-commits]

See https://reviews.llvm.org/D58418#1577670. More generally it would appear for 
any static library with a PRIVATE dependency though.

I guess an alternative would be to use the LINK_LIBRARIES property (which 
should be free of generator expressions, I believe) to propagate dependencies 
instead of INTERFACE_LINK_LIBRARIES, and just assume that no one is gonna set 
an INTERFACE dependency on a static library. (Supporting PRIVATE dependencies 
on a static library definitely seems more valuable than supporting INTERFACE 
dependencies.)

From:  on behalf of Chris Bieneman 
Date: Friday, July 12, 2019 at 8:49 AM
To: Shoaib Meenai 
Cc: Alex Bradbury , cfe-commits 
Subject: Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies

One of the benefits of the object library approach for generating the clang 
dylib is that it was compatible with BUILD_SHARED_LIBS. We had lots of issues 
with libLLVM where people using BUILD_SHARED_LIBS would make changes that broke 
it, so I was trying to make the clang dylib in a way that it could always be 
enabled.

Do we know where the nested generator expression was coming from?

-Chris


On Jul 12, 2019, at 8:32 AM, Shoaib Meenai 
mailto:smee...@fb.com>> wrote:

Oops, sorry about the breakage.

Chris, aren't BUILD_SHARED_LIBS and the combined Clang dylib incompatible? 
Should we disable building the latter if the former is set?

From: Alex Bradbury mailto:a...@lowrisc.org>>
Date: Friday, July 12, 2019 at 2:02 AM
To: Shoaib Meenai mailto:smee...@fb.com>>
Cc: cfe-commits mailto:cfe-commits@lists.llvm.org>>
Subject: Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies

On Thu, 11 Jul 2019 at 22:20, Shoaib Meenai via cfe-commits
mailto:cfe-commits@lists.llvm.org>> wrote:

Author: smeenai
Date: Thu Jul 11 14:20:38 2019
New Revision: 365825

URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D365825-26view-3Drev&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=ETCU2JhfBcjWz-nbe6LUVSRQR0T1f3wCzxLIhKlMmQo&s=R9NSZG1XQDVSiE0wJUgb1kMUrG6bJkG3v5GDcTdkpAk&e=
Log:
[clang-shlib] Fix clang-shlib for PRIVATE dependencies

Any static library with a PRIVATE dependency ends up with a
$ generator expression in its INTERFACE_LINK_LIBRARIES,
which won't be evaluated by the $, so we end up
with an unevaluated generator expression in the generated build file and
Ninja chokes on the dollar sign. Just use the static library directly
for its dependencies instead of trying to propagate dependencies
manually.

Differential Revision: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D64579&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=ETCU2JhfBcjWz-nbe6LUVSRQR0T1f3wCzxLIhKlMmQo&s=mutN2zF1KixMEVFjNzG_Q7iVJzG5ECbrU4tX3AKWLVQ&e=

This seems to break a -DBUILD_SHARED_LIBS build for me. It fails at
the point of linking lib/libclang_shared.so.9svn with errors like:
ld.lld: error: undefined symbol: llvm::llvm_unreachable_internal(char
const*, char const*, unsigned int)
referenced by Attributes.cpp:34 
(/home/asb/llvm-project/clang/lib/Basic/Attributes.cpp:34)
   
tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Attributes.cpp.o:(clang::attr::getSubjectMatchRuleSpelling(clang::attr::SubjectMatchRule))

ld.lld: error: undefined symbol: llvm::llvm_unreachable_internal(char
const*, char const*, unsigned int)
referenced by TargetCXXABI.h:168 
(/home/asb/llvm-project/clang/include/clang/Basic/TargetCXXABI.h:168)
   
tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Attributes.cpp.o:(clang::TargetCXXABI::isMicrosoft()
 const)

ld.lld: error: undefined symbol: llvm::llvm_unreachable_internal(char
const*, char const*, unsigned int)
referenced by TargetCXXABI.h:149 
(/home/asb/llvm-project/clang/include/clang/Basic/TargetCXXABI.h:149)
   
tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Attributes.cpp.o:(clang::TargetCXXABI::isItaniumFamily()
 const)

ld.lld: error: undefined symbol: llvm::EnableABIBreakingChecks
referenced by Attributes.cpp
   
tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Attributes.cpp.o:(llvm::VerifyEnableABIBreakingChecks)


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

Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies

[Shoaib Meenai via cfe-commits]

Hmm, I thought CMake did something more sensible with PRIVATE/INTERFACE/PUBLIC 
dependencies on static libraries, but now I’m not so sure…

I’m continuing to investigate more, but I’ll revert in the meantime.

From:  on behalf of Chris Bieneman 
Date: Friday, July 12, 2019 at 9:08 AM
To: Shoaib Meenai 
Cc: Alex Bradbury , cfe-commits 
Subject: Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies

Ah! I see what is going on here. This is kinda a silliness of CMake. `PRIVATE` 
linkage for a static archive is silly, and shouldn't be possible. All link 
dependencies for static archives are really `INTERFACE` dependencies, and it 
looks like CMake is doing something kinda silly instead of producing a 
reasonable error or warning like it probably should do.

For context, `PRIVATE` linkage in the context of that change would mean 
DirectoryWalker links something, but things that link DirectoryWalker don't. 
That just isn't possible with static archives, so they become interface 
dependencies (and CMake seems to insert a generator expression to make that 
work).

In `llvm_add_library` we always use `PRIVATE` linkage for shared libraries, and 
`INTERFACE` for static, which does the right thing.

Unless there is a better reason than a new patch coming in, I think the right 
fix is to revert this back and expect the new patch to correct its linkage 
behavior.

-Chris


On Jul 12, 2019, at 8:53 AM, Shoaib Meenai 
mailto:smee...@fb.com>> wrote:

See 
https://reviews.llvm.org/D58418#1577670<https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D58418-231577670&d=DwMFAg&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=BaInVCyhXHMyre_oyIEnYhuQC5zsW6p65QBgZLR7ujc&s=7bhRDMtKEyVqFDlMWzo361mQT2N8lcOt-YDh-XGjZok&e=>.
 More generally it would appear for any static library with a PRIVATE 
dependency though.

I guess an alternative would be to use the LINK_LIBRARIES property (which 
should be free of generator expressions, I believe) to propagate dependencies 
instead of INTERFACE_LINK_LIBRARIES, and just assume that no one is gonna set 
an INTERFACE dependency on a static library. (Supporting PRIVATE dependencies 
on a static library definitely seems more valuable than supporting INTERFACE 
dependencies.)

From: mailto:cbiene...@apple.com>> on behalf of Chris 
Bieneman mailto:be...@apple.com>>
Date: Friday, July 12, 2019 at 8:49 AM
To: Shoaib Meenai mailto:smee...@fb.com>>
Cc: Alex Bradbury mailto:a...@lowrisc.org>>, cfe-commits 
mailto:cfe-commits@lists.llvm.org>>
Subject: Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies

One of the benefits of the object library approach for generating the clang 
dylib is that it was compatible with BUILD_SHARED_LIBS. We had lots of issues 
with libLLVM where people using BUILD_SHARED_LIBS would make changes that broke 
it, so I was trying to make the clang dylib in a way that it could always be 
enabled.

Do we know where the nested generator expression was coming from?

-Chris



On Jul 12, 2019, at 8:32 AM, Shoaib Meenai 
mailto:smee...@fb.com>> wrote:

Oops, sorry about the breakage.

Chris, aren't BUILD_SHARED_LIBS and the combined Clang dylib incompatible? 
Should we disable building the latter if the former is set?

From: Alex Bradbury mailto:a...@lowrisc.org>>
Date: Friday, July 12, 2019 at 2:02 AM
To: Shoaib Meenai mailto:smee...@fb.com>>
Cc: cfe-commits mailto:cfe-commits@lists.llvm.org>>
Subject: Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies

On Thu, 11 Jul 2019 at 22:20, Shoaib Meenai via cfe-commits
mailto:cfe-commits@lists.llvm.org>> wrote:

Author: smeenai
Date: Thu Jul 11 14:20:38 2019
New Revision: 365825

URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D365825-26view-3Drev&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=ETCU2JhfBcjWz-nbe6LUVSRQR0T1f3wCzxLIhKlMmQo&s=R9NSZG1XQDVSiE0wJUgb1kMUrG6bJkG3v5GDcTdkpAk&e=
Log:
[clang-shlib] Fix clang-shlib for PRIVATE dependencies

Any static library with a PRIVATE dependency ends up with a
$ generator expression in its INTERFACE_LINK_LIBRARIES,
which won't be evaluated by the $, so we end up
with an unevaluated generator expression in the generated build file and
Ninja chokes on the dollar sign. Just use the static library directly
for its dependencies instead of trying to propagate dependencies
manually.

Differential Revision: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D64579&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=ETCU2JhfBcjWz-nbe6LUVSRQR0T1f3wCzxLIhKlMmQo&s=mutN2zF1KixMEVFjNzG_Q7iVJzG5ECbrU4tX3AKWLVQ&e=

This seems to break a -DBUILD_SHARED_LIBS build for me. It fails at
the point of linking lib/libclang_shared.so.9svn with errors like:
ld.lld: error: undefined s

Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies

[Shoaib Meenai via cfe-commits]

Reverted in r365922.

From:  on behalf of Chris Bieneman 
Date: Friday, July 12, 2019 at 9:08 AM
To: Shoaib Meenai 
Cc: Alex Bradbury , cfe-commits 
Subject: Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies

Ah! I see what is going on here. This is kinda a silliness of CMake. `PRIVATE` 
linkage for a static archive is silly, and shouldn't be possible. All link 
dependencies for static archives are really `INTERFACE` dependencies, and it 
looks like CMake is doing something kinda silly instead of producing a 
reasonable error or warning like it probably should do.

For context, `PRIVATE` linkage in the context of that change would mean 
DirectoryWalker links something, but things that link DirectoryWalker don't. 
That just isn't possible with static archives, so they become interface 
dependencies (and CMake seems to insert a generator expression to make that 
work).

In `llvm_add_library` we always use `PRIVATE` linkage for shared libraries, and 
`INTERFACE` for static, which does the right thing.

Unless there is a better reason than a new patch coming in, I think the right 
fix is to revert this back and expect the new patch to correct its linkage 
behavior.

-Chris


On Jul 12, 2019, at 8:53 AM, Shoaib Meenai 
mailto:smee...@fb.com>> wrote:

See 
https://reviews.llvm.org/D58418#1577670<https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D58418-231577670&d=DwMFAg&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=BaInVCyhXHMyre_oyIEnYhuQC5zsW6p65QBgZLR7ujc&s=7bhRDMtKEyVqFDlMWzo361mQT2N8lcOt-YDh-XGjZok&e=>.
 More generally it would appear for any static library with a PRIVATE 
dependency though.

I guess an alternative would be to use the LINK_LIBRARIES property (which 
should be free of generator expressions, I believe) to propagate dependencies 
instead of INTERFACE_LINK_LIBRARIES, and just assume that no one is gonna set 
an INTERFACE dependency on a static library. (Supporting PRIVATE dependencies 
on a static library definitely seems more valuable than supporting INTERFACE 
dependencies.)

From: mailto:cbiene...@apple.com>> on behalf of Chris 
Bieneman mailto:be...@apple.com>>
Date: Friday, July 12, 2019 at 8:49 AM
To: Shoaib Meenai mailto:smee...@fb.com>>
Cc: Alex Bradbury mailto:a...@lowrisc.org>>, cfe-commits 
mailto:cfe-commits@lists.llvm.org>>
Subject: Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies

One of the benefits of the object library approach for generating the clang 
dylib is that it was compatible with BUILD_SHARED_LIBS. We had lots of issues 
with libLLVM where people using BUILD_SHARED_LIBS would make changes that broke 
it, so I was trying to make the clang dylib in a way that it could always be 
enabled.

Do we know where the nested generator expression was coming from?

-Chris



On Jul 12, 2019, at 8:32 AM, Shoaib Meenai 
mailto:smee...@fb.com>> wrote:

Oops, sorry about the breakage.

Chris, aren't BUILD_SHARED_LIBS and the combined Clang dylib incompatible? 
Should we disable building the latter if the former is set?

From: Alex Bradbury mailto:a...@lowrisc.org>>
Date: Friday, July 12, 2019 at 2:02 AM
To: Shoaib Meenai mailto:smee...@fb.com>>
Cc: cfe-commits mailto:cfe-commits@lists.llvm.org>>
Subject: Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies

On Thu, 11 Jul 2019 at 22:20, Shoaib Meenai via cfe-commits
mailto:cfe-commits@lists.llvm.org>> wrote:

Author: smeenai
Date: Thu Jul 11 14:20:38 2019
New Revision: 365825

URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D365825-26view-3Drev&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=ETCU2JhfBcjWz-nbe6LUVSRQR0T1f3wCzxLIhKlMmQo&s=R9NSZG1XQDVSiE0wJUgb1kMUrG6bJkG3v5GDcTdkpAk&e=
Log:
[clang-shlib] Fix clang-shlib for PRIVATE dependencies

Any static library with a PRIVATE dependency ends up with a
$ generator expression in its INTERFACE_LINK_LIBRARIES,
which won't be evaluated by the $, so we end up
with an unevaluated generator expression in the generated build file and
Ninja chokes on the dollar sign. Just use the static library directly
for its dependencies instead of trying to propagate dependencies
manually.

Differential Revision: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D64579&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=ETCU2JhfBcjWz-nbe6LUVSRQR0T1f3wCzxLIhKlMmQo&s=mutN2zF1KixMEVFjNzG_Q7iVJzG5ECbrU4tX3AKWLVQ&e=

This seems to break a -DBUILD_SHARED_LIBS build for me. It fails at
the point of linking lib/libclang_shared.so.9svn with errors like:
ld.lld: error: undefined symbol: llvm::llvm_unreachable_internal(char
const*, char const*, unsigned int)
referenced by Attributes.cpp:34 
(/home/asb/llvm-project/clang/lib/Basic/Attributes.cpp:34)
   
tools/clang/

r365922 - Revert [clang-shlib] Fix clang-shlib for PRIVATE dependencies

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Fri Jul 12 10:23:35 2019
New Revision: 365922

URL: http://llvm.org/viewvc/llvm-project?rev=365922&view=rev
Log:
Revert [clang-shlib] Fix clang-shlib for PRIVATE dependencies

This reverts r365825 (git commit 3173c60f96c3ccfc17d403a192ae58e720153c23)

This is breaking BUILD_SHARED_LIBS=ON builds. Reverting while I rethink it.

Modified:
cfe/trunk/tools/clang-shlib/CMakeLists.txt

Modified: cfe/trunk/tools/clang-shlib/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/clang-shlib/CMakeLists.txt?rev=365922&r1=365921&r2=365922&view=diff
==
--- cfe/trunk/tools/clang-shlib/CMakeLists.txt (original)
+++ cfe/trunk/tools/clang-shlib/CMakeLists.txt Fri Jul 12 10:23:35 2019
@@ -7,35 +7,8 @@ get_property(clang_libs GLOBAL PROPERTY
 
 foreach (lib ${clang_libs})
   list(APPEND _OBJECTS $)
-  # Use the static library for its dependencies. The objects that constitute 
the
-  # static library will appear on the link line before the library, so it'll
-  # just be ignored, but the dependencies of the library will still be linked
-  # correctly.
-  #
-  # We could propagate the dependencies manually using the library's
-  # INTERFACE_LINK_LIBRARIES property, but that will contain $
-  # generator expressions if a static library has a private dependency, so we
-  # can't use a $ generator expression to get the property
-  # (since it wouldn't evaluate any generator expressions inside the property).
-  # We could use get_property and do string manipulation to manually evaluate
-  # the $, but that would miss any dependencies added after we
-  # evaluate the get_property. We could also use the LINK_LIBRARIES property
-  # instead, which should be free of any generator expressions, but that's
-  # technically incorrect (it'd most likely work fine in practice, but still).
-  #
-  # Another alternative would be to use --whole-archive or equivalent instead 
of
-  # using the object library at all. However, CMake reorders static libraries 
on
-  # the link line so that a library appears after all its dependents, which can
-  # reorder static libraries out of their --whole-archive --no-whole-archive
-  # sandwich. It's really hard to avoid that reordering while still propagating
-  # dependencies, which defeats the whole point.
-  #
-  # The ideal solution here is to bump our minimum CMake requirement to 3.12,
-  # which adds support for dependencies on object libraries. Until then, 
linking
-  # both the object and the static libraries seems like the least bad solution.
-  #
-  # TODO: Rework this when we bump our minimum CMake version to 3.12 or newer.
-  list(APPEND _DEPS ${lib})
+  list(APPEND _DEPS $)
+  list(APPEND _DEPS $)
 endforeach ()
 
 if (CLANG_LINK_CLANG_DYLIB)


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

Re: [PATCH] D64579: [clang-shlib] Fix clang-shlib for PRIVATE dependencies

[Shoaib Meenai via cfe-commits]

Sorry about the breakage. I reverted it in r365922.

On 7/12/19, 9:12 AM, "Brian Rzycki via Phabricator"  
wrote:

brzycki added a comment.

Hello @smeenai , this commit causes LLVM to fail to build when set set `-D 
BUILD_SHARED_LIBS=ON`. Here is the failing CMake and Ninja invocation:

  /tools/build/cmake-3.14.5/bin/cmake \
  -G Ninja  \
  -D CMAKE_MAKE_PROGRAM=/tools/build/ninja-1.9.0/ninja \
  -D CMAKE_C_COMPILER=/usr/lib/llvm-7/bin/clang \
  -D CMAKE_CXX_COMPILER=/usr/lib/llvm-7/bin/clang++ \
  -D CMAKE_BUILD_TYPE=Release \
  -D CMAKE_INSTALL_PREFIX=/work/upstream/install \
  -D LLVM_TOOL_CLANG_BUILD=ON \
  -D LIBCXX_INCLUDE_BENCHMARKS=ON \
  -D BUILD_SHARED_LIBS=ON \
  -D LLVM_ENABLE_ASSERTIONS=ON \
  -D LLVM_TARGETS_TO_BUILD=X86 \
  /work/upstream/llvm-project/llvm
  
  /tools/build/ninja-1.9.0/ninja -v install

I am able to successfully build LLVM when I change to `-D 
BUILD_SHARED_LIBS=OFF`.

The outputted errors happen during link time of 
`lib/libclang_shared.so.9svn`:

  FAILED: lib/libclang_shared.so.9svn
  
  ...
  
  
tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/CodeGenModule.cpp.o: In 
function `llvm::cl::opt >::~opt()':
  
CodeGenModule.cpp:(.text._ZN4llvm2cl3optIbLb0ENS0_6parserIbEEED2Ev[_ZN4llvm2cl3optIbLb0ENS0_6parserIbEEED2Ev]+0x7):
 undefined reference to `vtable for llvm::cl::Option'
  
tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/CodeGenModule.cpp.o: In 
function `clang::CodeGen::CodeGenModule::CodeGenModule(clang::ASTContext&, 
clang::HeaderSearchOptions const&, clang::PreprocessorOptions const&, 
clang::CodeGenOptions const&, llvm::Module&, clang::DiagnosticsEngine&, 
clang::CoverageSourceInfo*)':
  
CodeGenModule.cpp:(.text._ZN5clang7CodeGen13CodeGenModuleC2ERNS_10ASTContextERKNS_19HeaderSearchOptionsERKNS_19PreprocessorOptionsERKNS_14CodeGenOptionsERN4llvm6ModuleERNS_17DiagnosticsEngineEPNS_18CoverageSourceInfoE+0x57a):
 undefined reference to `llvm::FoldingSetBase::FoldingSetBase(unsigned int)'
  
CodeGenModule.cpp:(.text._ZN5clang7CodeGen13CodeGenModuleC2ERNS_10ASTContextERKNS_19HeaderSearchOptionsERKNS_19PreprocessorOptionsERKNS_14CodeGenOptionsERN4llvm6ModuleERNS_17DiagnosticsEngineEPNS_18CoverageSourceInfoE+0x5cc):
 undefined reference to `llvm::Type::getVoidTy(llvm::LLVMContext&)'
  
CodeGenModule.cpp:(.text._ZN5clang7CodeGen13CodeGenModuleC2ERNS_10ASTContextERKNS_19HeaderSearchOptionsERKNS_19PreprocessorOptionsERKNS_14CodeGenOptionsERN4llvm6ModuleERNS_17DiagnosticsEngineEPNS_18CoverageSourceInfoE+0x5d7):
 undefined reference to `llvm::Type::getInt8Ty(llvm::LLVMContext&)'
  
CodeGenModule.cpp:(.text._ZN5clang7CodeGen13CodeGenModuleC2ERNS_10ASTContextERKNS_19HeaderSearchOptionsERKNS_19PreprocessorOptionsERKNS_14CodeGenOptionsERN4llvm6ModuleERNS_17DiagnosticsEngineEPNS_18CoverageSourceInfoE+0x5e3):
 undefined reference to `llvm::Type::getInt16Ty(llvm::LLVMContext&)'
  
  ... (clipped thousands of similar errors)
  
  
WhitespaceManager.cpp:(.text._ZN5clang6formatL18AlignTokenSequenceIRZNS0_17WhitespaceManager28alignConsecutiveDeclarationsEvE3$_2EEvjjjOT_RN4llvm11SmallVectorINS2_6ChangeELj16EEE+0x129):
 undefined reference to `llvm::SmallVectorBase::grow_pod(void*, unsigned long, 
unsigned long)'
  
tools/clang/tools/clang-fuzzer/handle-cxx/CMakeFiles/obj.clangHandleCXX.dir/handle_cxx.cpp.o:
 In function `clang_fuzzer::HandleCXX(std::__cxx11::basic_string, std::allocator > const&, std::vector > const&)':
  
handle_cxx.cpp:(.text._ZN12clang_fuzzer9HandleCXXERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKSt6vectorIPKcSaISA_EE+0x67):
 undefined reference to `llvm::SmallVectorBase::grow_pod(void*, unsigned long, 
unsigned long)'
  
handle_cxx.cpp:(.text._ZN12clang_fuzzer9HandleCXXERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKSt6vectorIPKcSaISA_EE+0x32b):
 undefined reference to `llvm::MemoryBuffer::getMemBuffer(llvm::StringRef, 
llvm::StringRef, bool)'
  
handle_cxx.cpp:(.text._ZN12clang_fuzzer9HandleCXXERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKSt6vectorIPKcSaISA_EE+0x669):
 undefined reference to `llvm::SmallVectorBase::grow_pod(void*, unsigned long, 
unsigned long)'
  clang: error: linker command failed with exit code 1 (use -v to see 
invocation)


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  
https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D64579_new_&d=DwIFAg&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=cpyWE0YV319Dd3hlteUrLx-qVuVLtE5TuYEWHimU5pE&s=ewqtR4F272LGTH1CzQZcQALTX6_rJIABb5AgGqr2s4Q&e=
 


https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D64579&d=DwIFAg&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=cpyWE0YV319Dd3hlteUrLx-qVuVLtE5TuYEWHimU5pE&s=oL7blc7PIIj9vcaNL2TKUMdmqc1iN_6Tv0ddCFde7as&e=
 

Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies

[Shoaib Meenai via cfe-commits]

I struggled for a while thinking why PRIVATE might be useful in a 
target_link_libraries call for a shared library, and then I found 
https://cmake.org/pipermail/cmake/2016-May/063400.html. The relevant bit is:

If you were paying careful attention, you would have noticed that when A
links in B as PRIVATE, the include directories of B never propagate to
something linking to A, but if A is a static library, then the *linking* of
B behaves as though the relationship was PUBLIC. This
PRIVATE-becomes-PUBLIC behaviour for static libraries only applies to the
*linking*, not to the other dependencies (compiler options/flags and
include search paths).

So PRIVATE/INTERFACE/PUBLIC doesn’t make any difference as far as the actual 
linking goes, but it does affect propagation of other options, and I think it’s 
valid to want to have a PRIVATE dependency for a static library.

From:  on behalf of Chris Bieneman 
Date: Friday, July 12, 2019 at 9:08 AM
To: Shoaib Meenai 
Cc: Alex Bradbury , cfe-commits 
Subject: Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies

Ah! I see what is going on here. This is kinda a silliness of CMake. `PRIVATE` 
linkage for a static archive is silly, and shouldn't be possible. All link 
dependencies for static archives are really `INTERFACE` dependencies, and it 
looks like CMake is doing something kinda silly instead of producing a 
reasonable error or warning like it probably should do.

For context, `PRIVATE` linkage in the context of that change would mean 
DirectoryWalker links something, but things that link DirectoryWalker don't. 
That just isn't possible with static archives, so they become interface 
dependencies (and CMake seems to insert a generator expression to make that 
work).

In `llvm_add_library` we always use `PRIVATE` linkage for shared libraries, and 
`INTERFACE` for static, which does the right thing.

Unless there is a better reason than a new patch coming in, I think the right 
fix is to revert this back and expect the new patch to correct its linkage 
behavior.

-Chris


On Jul 12, 2019, at 8:53 AM, Shoaib Meenai 
mailto:smee...@fb.com>> wrote:

See 
https://reviews.llvm.org/D58418#1577670<https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D58418-231577670&d=DwMFAg&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=BaInVCyhXHMyre_oyIEnYhuQC5zsW6p65QBgZLR7ujc&s=7bhRDMtKEyVqFDlMWzo361mQT2N8lcOt-YDh-XGjZok&e=>.
 More generally it would appear for any static library with a PRIVATE 
dependency though.

I guess an alternative would be to use the LINK_LIBRARIES property (which 
should be free of generator expressions, I believe) to propagate dependencies 
instead of INTERFACE_LINK_LIBRARIES, and just assume that no one is gonna set 
an INTERFACE dependency on a static library. (Supporting PRIVATE dependencies 
on a static library definitely seems more valuable than supporting INTERFACE 
dependencies.)

From: mailto:cbiene...@apple.com>> on behalf of Chris 
Bieneman mailto:be...@apple.com>>
Date: Friday, July 12, 2019 at 8:49 AM
To: Shoaib Meenai mailto:smee...@fb.com>>
Cc: Alex Bradbury mailto:a...@lowrisc.org>>, cfe-commits 
mailto:cfe-commits@lists.llvm.org>>
Subject: Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies

One of the benefits of the object library approach for generating the clang 
dylib is that it was compatible with BUILD_SHARED_LIBS. We had lots of issues 
with libLLVM where people using BUILD_SHARED_LIBS would make changes that broke 
it, so I was trying to make the clang dylib in a way that it could always be 
enabled.

Do we know where the nested generator expression was coming from?

-Chris



On Jul 12, 2019, at 8:32 AM, Shoaib Meenai 
mailto:smee...@fb.com>> wrote:

Oops, sorry about the breakage.

Chris, aren't BUILD_SHARED_LIBS and the combined Clang dylib incompatible? 
Should we disable building the latter if the former is set?

From: Alex Bradbury mailto:a...@lowrisc.org>>
Date: Friday, July 12, 2019 at 2:02 AM
To: Shoaib Meenai mailto:smee...@fb.com>>
Cc: cfe-commits mailto:cfe-commits@lists.llvm.org>>
Subject: Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies

On Thu, 11 Jul 2019 at 22:20, Shoaib Meenai via cfe-commits
mailto:cfe-commits@lists.llvm.org>> wrote:

Author: smeenai
Date: Thu Jul 11 14:20:38 2019
New Revision: 365825

URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D365825-26view-3Drev&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=ETCU2JhfBcjWz-nbe6LUVSRQR0T1f3wCzxLIhKlMmQo&s=R9NSZG1XQDVSiE0wJUgb1kMUrG6bJkG3v5GDcTdkpAk&e=
Log:
[clang-shlib] Fix clang-shlib for PRIVATE dependencies

Any static library with a PRIVATE dependency ends up with a
$ generator expression in its INTERFACE_LINK_LIBRARIES,
which won't be evaluated by the $, so we end up
with 

Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies

[Shoaib Meenai via cfe-commits]

of issues 
with libLLVM where people using BUILD_SHARED_LIBS would make changes that broke 
it, so I was trying to make the clang dylib in a way that it could always be 
enabled.

Do we know where the nested generator expression was coming from?

-Chris




On Jul 12, 2019, at 8:32 AM, Shoaib Meenai 
mailto:smee...@fb.com>> wrote:

Oops, sorry about the breakage.

Chris, aren't BUILD_SHARED_LIBS and the combined Clang dylib incompatible? 
Should we disable building the latter if the former is set?

From: Alex Bradbury mailto:a...@lowrisc.org>>
Date: Friday, July 12, 2019 at 2:02 AM
To: Shoaib Meenai mailto:smee...@fb.com>>
Cc: cfe-commits mailto:cfe-commits@lists.llvm.org>>
Subject: Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies

On Thu, 11 Jul 2019 at 22:20, Shoaib Meenai via cfe-commits
mailto:cfe-commits@lists.llvm.org>> wrote:

Author: smeenai
Date: Thu Jul 11 14:20:38 2019
New Revision: 365825

URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D365825-26view-3Drev&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=ETCU2JhfBcjWz-nbe6LUVSRQR0T1f3wCzxLIhKlMmQo&s=R9NSZG1XQDVSiE0wJUgb1kMUrG6bJkG3v5GDcTdkpAk&e=
Log:
[clang-shlib] Fix clang-shlib for PRIVATE dependencies

Any static library with a PRIVATE dependency ends up with a
$ generator expression in its INTERFACE_LINK_LIBRARIES,
which won't be evaluated by the $, so we end up
with an unevaluated generator expression in the generated build file and
Ninja chokes on the dollar sign. Just use the static library directly
for its dependencies instead of trying to propagate dependencies
manually.

Differential Revision: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D64579&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=ETCU2JhfBcjWz-nbe6LUVSRQR0T1f3wCzxLIhKlMmQo&s=mutN2zF1KixMEVFjNzG_Q7iVJzG5ECbrU4tX3AKWLVQ&e=

This seems to break a -DBUILD_SHARED_LIBS build for me. It fails at
the point of linking lib/libclang_shared.so.9svn with errors like:
ld.lld: error: undefined symbol: llvm::llvm_unreachable_internal(char
const*, char const*, unsigned int)
referenced by Attributes.cpp:34 
(/home/asb/llvm-project/clang/lib/Basic/Attributes.cpp:34)
   
tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Attributes.cpp.o:(clang::attr::getSubjectMatchRuleSpelling(clang::attr::SubjectMatchRule))

ld.lld: error: undefined symbol: llvm::llvm_unreachable_internal(char
const*, char const*, unsigned int)
referenced by TargetCXXABI.h:168 
(/home/asb/llvm-project/clang/include/clang/Basic/TargetCXXABI.h:168)
   
tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Attributes.cpp.o:(clang::TargetCXXABI::isMicrosoft()
 const)

ld.lld: error: undefined symbol: llvm::llvm_unreachable_internal(char
const*, char const*, unsigned int)
referenced by TargetCXXABI.h:149 
(/home/asb/llvm-project/clang/include/clang/Basic/TargetCXXABI.h:149)
   
tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Attributes.cpp.o:(clang::TargetCXXABI::isItaniumFamily()
 const)

ld.lld: error: undefined symbol: llvm::EnableABIBreakingChecks
referenced by Attributes.cpp
   
tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Attributes.cpp.o:(llvm::VerifyEnableABIBreakingChecks)

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

r367982 - [Driver] Introduce -stdlib++-isystem

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Mon Aug  5 23:48:43 2019
New Revision: 367982

URL: http://llvm.org/viewvc/llvm-project?rev=367982&view=rev
Log:
[Driver] Introduce -stdlib++-isystem

There are times when we wish to explicitly control the C++ standard
library search paths used by the driver. For example, when we're
building against the Android NDK, we might want to use the NDK's C++
headers (which have a custom inline namespace) even if we have C++
headers installed next to the driver. We might also be building against
a non-standard directory layout and wanting to specify the C++ standard
library include directories explicitly.

We could accomplish this by passing -nostdinc++ and adding an explicit
-isystem for our custom search directories. However, users of our
toolchain may themselves want to use -nostdinc++ and a custom C++ search
path (libc++'s build does this, for example), and our added -isystem
won't respect the -nostdinc++, leading to multiple C++ header
directories on the search path, which causes build failures.

Add a new driver option -stdlib++-isystem to support this use case.
Passing this option suppresses adding the default C++ library include
paths in the driver, and it also respects -nostdinc++ to allow users to
still override the C++ library paths themselves.

It's a bit unfortunate that we end up with both -stdlib++-isystem and
-cxx-isystem, but their semantics differ significantly. -cxx-isystem is
unaffected by -nostdinc++ and is added to the end of the search path
(which is not appropriate for C++ standard library headers, since they
often #include_next into other system headers), while -stdlib++-isystem
respects -nostdinc++, is added to the beginning of the search path, and
suppresses the default C++ library include paths.

Differential Revision: https://reviews.llvm.org/D64089

Added:
cfe/trunk/test/Driver/stdlibxx-isystem.cpp
Modified:
cfe/trunk/include/clang/Driver/Options.td
cfe/trunk/include/clang/Driver/ToolChain.h
cfe/trunk/lib/Driver/ToolChain.cpp
cfe/trunk/lib/Driver/ToolChains/Clang.cpp

Modified: cfe/trunk/include/clang/Driver/Options.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=367982&r1=367981&r2=367982&view=diff
==
--- cfe/trunk/include/clang/Driver/Options.td (original)
+++ cfe/trunk/include/clang/Driver/Options.td Mon Aug  5 23:48:43 2019
@@ -2642,6 +2642,10 @@ def std_EQ : Joined<["-", "--"], "std=">
   }]>;
 def stdlib_EQ : Joined<["-", "--"], "stdlib=">, Flags<[CC1Option]>,
   HelpText<"C++ standard library to use">, Values<"libc++,libstdc++,platform">;
+def stdlibxx_isystem : JoinedOrSeparate<["-"], "stdlib++-isystem">,
+  Group,
+  HelpText<"Use directory as the C++ standard library include path">,
+  Flags<[DriverOption]>, MetaVarName<"">;
 def unwindlib_EQ : Joined<["-", "--"], "unwindlib=">, Flags<[CC1Option]>,
   HelpText<"Unwind library to use">, Values<"libgcc,unwindlib,platform">;
 def sub__library : JoinedOrSeparate<["-"], "sub_library">;

Modified: cfe/trunk/include/clang/Driver/ToolChain.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/ToolChain.h?rev=367982&r1=367981&r2=367982&view=diff
==
--- cfe/trunk/include/clang/Driver/ToolChain.h (original)
+++ cfe/trunk/include/clang/Driver/ToolChain.h Mon Aug  5 23:48:43 2019
@@ -542,6 +542,11 @@ public:
   AddClangCXXStdlibIncludeArgs(const llvm::opt::ArgList &DriverArgs,
llvm::opt::ArgStringList &CC1Args) const;
 
+  /// AddClangCXXStdlibIsystemArgs - Add the clang -cc1 level arguments to set
+  /// the specified include paths for the C++ standard library.
+  void AddClangCXXStdlibIsystemArgs(const llvm::opt::ArgList &DriverArgs,
+llvm::opt::ArgStringList &CC1Args) const;
+
   /// Returns if the C++ standard library should be linked in.
   /// Note that e.g. -lm should still be linked even if this returns false.
   bool ShouldLinkCXXStdlib(const llvm::opt::ArgList &Args) const;

Modified: cfe/trunk/lib/Driver/ToolChain.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChain.cpp?rev=367982&r1=367981&r2=367982&view=diff
==
--- cfe/trunk/lib/Driver/ToolChain.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChain.cpp Mon Aug  5 23:48:43 2019
@@ -832,6 +832,16 @@ void ToolChain::AddClangCXXStdlibInclude
   DriverArgs.AddAllArgs(CC1Args, options::OPT_stdlib_EQ);
 }
 
+void ToolChain::AddClangCXXStdlibIsystemArgs(
+const llvm::opt::ArgList &DriverArgs,
+llvm::opt::ArgStringList &CC1Args) const {
+  DriverArgs.ClaimAllArgs(options::OPT_stdlibxx_isystem);
+  if (!DriverArgs.hasArg(options::OPT_nostdincxx))
+for (const auto &P :
+ DriverArgs.getAllArgValues(options::OPT_stdlibxx_isystem))
+  addSystemInclude(

r367984 - [DirectoryWatcher] Fix asserts Mac builds

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Tue Aug  6 00:13:53 2019
New Revision: 367984

URL: http://llvm.org/viewvc/llvm-project?rev=367984&view=rev
Log:
[DirectoryWatcher] Fix asserts Mac builds

Add a missing semicolon after an assert. Remove the period from the
assert message while I'm here, because we don't usually have those.

Modified:
cfe/trunk/lib/DirectoryWatcher/mac/DirectoryWatcher-mac.cpp

Modified: cfe/trunk/lib/DirectoryWatcher/mac/DirectoryWatcher-mac.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/DirectoryWatcher/mac/DirectoryWatcher-mac.cpp?rev=367984&r1=367983&r2=367984&view=diff
==
--- cfe/trunk/lib/DirectoryWatcher/mac/DirectoryWatcher-mac.cpp (original)
+++ cfe/trunk/lib/DirectoryWatcher/mac/DirectoryWatcher-mac.cpp Tue Aug  6 
00:13:53 2019
@@ -210,7 +210,7 @@ llvm::Expected Result =
   llvm::make_unique(EventStream, Receiver, Path);


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

Re: r367979 - [clang][DirectoryWatcher] Adding llvm::Expected error handling to create.

[Shoaib Meenai via cfe-commits]

You missed a semicolon after an assert, which broke asserts Mac builds. I fixed 
it in r367984.

From: cfe-commits  on behalf of Puyan Lotfi 
via cfe-commits 
Reply-To: Puyan Lotfi 
Date: Monday, August 5, 2019 at 10:11 PM
To: "cfe-commits@lists.llvm.org" 
Subject: r367979 - [clang][DirectoryWatcher] Adding llvm::Expected error 
handling to create.

Author: zer0
Date: Mon Aug  5 22:12:23 2019
New Revision: 367979

URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D367979-26view-3Drev&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=6k2w1Mw8wKFqzKnFgq4r1I7Zmx7B-N-JdVMvtHYpjJs&s=GdHgTwHdRXipmG75D6eyJGuUUbCL0EMIl0YPYAY0y2U&e=
Log:
[clang][DirectoryWatcher] Adding llvm::Expected error handling to create.

Prior to this patch Unix style errno error reporting from the inotify layer was
used by DirectoryWatcher::create to simply return a nullptr on error. This
would generally be ok, except that in LLVM we have much more robust error
reporting through the facilities of llvm::Expected.

The other critical thing I stumbled across was that the unit tests for
DirectoryWatcher were not failing abruptly when inotify_init() was reporting an
error, but would continue with the testing and eventually hit a deadlock in a
pathological machine state (ie in the unit test, the return nullptr on ::create
was ignored).

Generally this pathological state never happens on any build bot, so it is
totally understandable that it was overlooked, but on a Linux desktop running
a dubious desktop environment (which I will not name) there is a chance that
said desktop environment could use up enough inotify instances to exceed the
user's limit. These are the conditions that led me to hit the deadlock I am
addressing in this patch with more robust error handling.

With the new llvm::Expected error handling when your system runs out of inotify
instances for your user, the unit test will be forced to handle the error or
crash and report the issue to the user instead of weirdly deadlocking on a
condition variable wait.

Differential Revision: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D65704&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=6k2w1Mw8wKFqzKnFgq4r1I7Zmx7B-N-JdVMvtHYpjJs&s=vGtUV_-i1W7ejLSH8cWFnYlusAJMA8EK5kMTvuMmQB4&e=


Modified:
cfe/trunk/include/clang/DirectoryWatcher/DirectoryWatcher.h
cfe/trunk/lib/DirectoryWatcher/default/DirectoryWatcher-not-implemented.cpp
cfe/trunk/lib/DirectoryWatcher/linux/DirectoryWatcher-linux.cpp
cfe/trunk/lib/DirectoryWatcher/mac/DirectoryWatcher-mac.cpp
cfe/trunk/unittests/DirectoryWatcher/DirectoryWatcherTest.cpp

Modified: cfe/trunk/include/clang/DirectoryWatcher/DirectoryWatcher.h
URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_cfe_trunk_include_clang_DirectoryWatcher_DirectoryWatcher.h-3Frev-3D367979-26r1-3D367978-26r2-3D367979-26view-3Ddiff&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=6k2w1Mw8wKFqzKnFgq4r1I7Zmx7B-N-JdVMvtHYpjJs&s=VCfJ3mXkHYvO_8Iw35iGLiTPxX-OaQIrX9fUY22ukbw&e=
==
--- cfe/trunk/include/clang/DirectoryWatcher/DirectoryWatcher.h (original)
+++ cfe/trunk/include/clang/DirectoryWatcher/DirectoryWatcher.h Mon Aug  5 
22:12:23 2019
@@ -11,6 +11,7 @@
#include "llvm/ADT/ArrayRef.h"
#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/Error.h"
#include 
#include 
#include 
@@ -98,10 +99,11 @@ public:
 : Kind(Kind), Filename(Filename) {}
   };
-  /// Returns nullptr if \param Path doesn't exist or isn't a directory.
-  /// Returns nullptr if OS kernel API told us we can't start watching. In such
-  /// case it's unclear whether just retrying has any chance to succeeed.
-  static std::unique_ptr
+  /// Asserts if \param Path doesn't exist or isn't a directory.
+  /// Returns llvm::Expected Error if OS kernel API told us we can't start
+  /// watching. In such case it's unclear whether just retrying has any chance
+  /// to succeeed.
+  static llvm::Expected>
   create(llvm::StringRef Path,
  std::function Events,
 bool IsInitial)>

Modified: 
cfe/trunk/lib/DirectoryWatcher/default/DirectoryWatcher-not-implemented.cpp
URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_cfe_trunk_lib_DirectoryWatcher_default_DirectoryWatcher-2Dnot-2Dimplemented.cpp-3Frev-3D367979-26r1-3D367978-26r2-3D367979-26view-3Ddiff&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=6k2w1Mw8wKFqzKnFgq4r1I7Zmx7B-N-JdVMvtHYpjJs&s=kOGSMivkTUI-mqfkDLYmSGfQM8CSoTUydr4qZdtcaAc&e=
==
--- cfe/trunk/lib/DirectoryWatcher/default/DirectoryWatcher-not-implemented.cpp 
(original)
+++ cfe/trunk/lib/DirectoryWatcher/default/DirectoryWatcher-not-implemented.cpp 
Mon Aug  5 22:12:23 2019
@@ -11,9 +11,11 @@
using namespace llv

Re: r350643 - Limit COFF 'common' emission to <=32 alignment types.

[Shoaib Meenai via cfe-commits]

Why does this check for isKnownWindowsMSVCEnvironment specifically? Wouldn't 
any COFF target (windows-cygnus, windows-gnu, windows-itanium, etc.) have the 
same limitation, since it's an object file format issue and not an ABI issue?

From: cfe-commits  on behalf of Erich Keane 
via cfe-commits 
Reply-To: Erich Keane 
Date: Tuesday, January 8, 2019 at 10:48 AM
To: "cfe-commits@lists.llvm.org" 
Subject: r350643 - Limit COFF 'common' emission to <=32 alignment types.

Author: erichkeane
Date: Tue Jan  8 10:44:22 2019
New Revision: 350643

URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D350643-26view-3Drev&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=RNVKy_b0_Wgp_PTFDpvQXETsZdWubmT5SGnGz3GigS0&s=Ph9GOtRaQERmqyeJeAJTFwV3sg3q8fE05FlJ3qwNx4I&e=
Log:
Limit COFF 'common' emission to <=32 alignment types.

As reported in PR33035, LLVM crashes if given a common object with an
alignment of greater than 32 bits. This is because the COFF file format
does not support these alignments, so emitting them is broken anyway.

This patch changes any global definitions greater than 32 bit alignment
to no longer be in 'common'.

https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.llvm.org_show-5Fbug.cgi-3Fid-3D33035&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=RNVKy_b0_Wgp_PTFDpvQXETsZdWubmT5SGnGz3GigS0&s=ac1NEHuvztd6jSTCsOUJajkklfeyqdzW-xqtddJ-hvM&e=

Differential Revision: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D56391&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=RNVKy_b0_Wgp_PTFDpvQXETsZdWubmT5SGnGz3GigS0&s=AucP9Sp-DYHSaOP-sPfpAOrww3xwdh8FjQkHrLZhhyo&e=

Change-Id: I48609289753b7f3b58c5e2bc1712756750fbd45a

Added:
cfe/trunk/test/CodeGen/microsoft-no-common-align.c
Modified:
cfe/trunk/lib/CodeGen/CodeGenModule.cpp

Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_cfe_trunk_lib_CodeGen_CodeGenModule.cpp-3Frev-3D350643-26r1-3D350642-26r2-3D350643-26view-3Ddiff&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=RNVKy_b0_Wgp_PTFDpvQXETsZdWubmT5SGnGz3GigS0&s=gmTnEmW03ruG8LbJluf5Z4yQcxM64QP7Ce1VTnVqvPo&e=
==
--- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Tue Jan  8 10:44:22 2019
@@ -3761,6 +3761,11 @@ static bool isVarDeclStrongDefinition(co
   }
 }
   }
+  // COFF doesn't support alignments greater than 32, so these cannot be
+  // in common.
+  if (Context.getTargetInfo().getTriple().isKnownWindowsMSVCEnvironment() &&
+  Context.getTypeAlignIfKnown(D->getType()) > 32)
+return true;
   return false;
}

Added: cfe/trunk/test/CodeGen/microsoft-no-common-align.c
URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_cfe_trunk_test_CodeGen_microsoft-2Dno-2Dcommon-2Dalign.c-3Frev-3D350643-26view-3Dauto&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=RNVKy_b0_Wgp_PTFDpvQXETsZdWubmT5SGnGz3GigS0&s=hzPmmVFbvg4OTEVpnQ5pIfy295Ne0-xAsctZs00WZgY&e=
==
--- cfe/trunk/test/CodeGen/microsoft-no-common-align.c (added)
+++ cfe/trunk/test/CodeGen/microsoft-no-common-align.c Tue Jan  8 10:44:22 2019
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 -triple x86_64-windows-msvc -emit-llvm -o - %s | FileCheck 
%s
+typedef float TooLargeAlignment __attribute__((__vector_size__(64)));
+typedef float NormalAlignment __attribute__((__vector_size__(4)));
+
+TooLargeAlignment TooBig;
+// CHECK: @TooBig = dso_local global <16 x float>  zeroinitializer, align 64
+NormalAlignment JustRight;
+// CHECK: @JustRight = common dso_local global <1 x float>  zeroinitializer, 
align 4


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_cfe-2Dcommits&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=RNVKy_b0_Wgp_PTFDpvQXETsZdWubmT5SGnGz3GigS0&s=Myn7SZhcOe32EZiKZr4ByJAZOoFl5aIfmWV9555Vh9A&e=

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

Re: r350643 - Limit COFF 'common' emission to <=32 alignment types.

[Shoaib Meenai via cfe-commits]

Ah, looks like you were originally checking for COFF, and then David suggested 
checking for MSVC instead? I'm curious about why, although I'm sure the 
suggestion is legit :)

From: cfe-commits  on behalf of Shoaib 
Meenai via cfe-commits 
Reply-To: Shoaib Meenai 
Date: Tuesday, January 8, 2019 at 12:39 PM
To: Erich Keane , "cfe-commits@lists.llvm.org" 

Subject: Re: r350643 - Limit COFF 'common' emission to <=32 alignment types.

Why does this check for isKnownWindowsMSVCEnvironment specifically? Wouldn't 
any COFF target (windows-cygnus, windows-gnu, windows-itanium, etc.) have the 
same limitation, since it's an object file format issue and not an ABI issue?

From: cfe-commits  on behalf of Erich Keane 
via cfe-commits 
Reply-To: Erich Keane 
Date: Tuesday, January 8, 2019 at 10:48 AM
To: "cfe-commits@lists.llvm.org" 
Subject: r350643 - Limit COFF 'common' emission to <=32 alignment types.

Author: erichkeane
Date: Tue Jan  8 10:44:22 2019
New Revision: 350643

URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D350643-26view-3Drev&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=RNVKy_b0_Wgp_PTFDpvQXETsZdWubmT5SGnGz3GigS0&s=Ph9GOtRaQERmqyeJeAJTFwV3sg3q8fE05FlJ3qwNx4I&e=
Log:
Limit COFF 'common' emission to <=32 alignment types.

As reported in PR33035, LLVM crashes if given a common object with an
alignment of greater than 32 bits. This is because the COFF file format
does not support these alignments, so emitting them is broken anyway.

This patch changes any global definitions greater than 32 bit alignment
to no longer be in 'common'.

https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.llvm.org_show-5Fbug.cgi-3Fid-3D33035&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=RNVKy_b0_Wgp_PTFDpvQXETsZdWubmT5SGnGz3GigS0&s=ac1NEHuvztd6jSTCsOUJajkklfeyqdzW-xqtddJ-hvM&e=

Differential Revision: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D56391&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=RNVKy_b0_Wgp_PTFDpvQXETsZdWubmT5SGnGz3GigS0&s=AucP9Sp-DYHSaOP-sPfpAOrww3xwdh8FjQkHrLZhhyo&e=

Change-Id: I48609289753b7f3b58c5e2bc1712756750fbd45a

Added:
cfe/trunk/test/CodeGen/microsoft-no-common-align.c
Modified:
cfe/trunk/lib/CodeGen/CodeGenModule.cpp

Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_cfe_trunk_lib_CodeGen_CodeGenModule.cpp-3Frev-3D350643-26r1-3D350642-26r2-3D350643-26view-3Ddiff&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=RNVKy_b0_Wgp_PTFDpvQXETsZdWubmT5SGnGz3GigS0&s=gmTnEmW03ruG8LbJluf5Z4yQcxM64QP7Ce1VTnVqvPo&e=
==
--- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Tue Jan  8 10:44:22 2019
@@ -3761,6 +3761,11 @@ static bool isVarDeclStrongDefinition(co
   }
 }
   }
+  // COFF doesn't support alignments greater than 32, so these cannot be
+  // in common.
+  if (Context.getTargetInfo().getTriple().isKnownWindowsMSVCEnvironment() &&
+  Context.getTypeAlignIfKnown(D->getType()) > 32)
+return true;
   return false;
}

Added: cfe/trunk/test/CodeGen/microsoft-no-common-align.c
URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_cfe_trunk_test_CodeGen_microsoft-2Dno-2Dcommon-2Dalign.c-3Frev-3D350643-26view-3Dauto&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=RNVKy_b0_Wgp_PTFDpvQXETsZdWubmT5SGnGz3GigS0&s=hzPmmVFbvg4OTEVpnQ5pIfy295Ne0-xAsctZs00WZgY&e=
==
--- cfe/trunk/test/CodeGen/microsoft-no-common-align.c (added)
+++ cfe/trunk/test/CodeGen/microsoft-no-common-align.c Tue Jan  8 10:44:22 2019
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 -triple x86_64-windows-msvc -emit-llvm -o - %s | FileCheck 
%s
+typedef float TooLargeAlignment __attribute__((__vector_size__(64)));
+typedef float NormalAlignment __attribute__((__vector_size__(4)));
+
+TooLargeAlignment TooBig;
+// CHECK: @TooBig = dso_local global <16 x float>  zeroinitializer, align 64
+NormalAlignment JustRight;
+// CHECK: @JustRight = common dso_local global <1 x float>  zeroinitializer, 
align 4


___
cfe-commits mailing list
cfe-commits@lists.llvm.org<mailto:cfe-commits@lists.llvm.org>
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_cfe-2Dcommits&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=RNVKy_b0_Wgp_PTFDpvQXETsZdWubmT5SGnGz3GigS0&s=Myn7SZhcOe32EZiKZr4ByJAZOoFl5aIfmWV9555Vh9A&e=

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

Re: r350643 - Limit COFF 'common' emission to <=32 alignment types.

[Shoaib Meenai via cfe-commits]

It checks for both OS=Win32 and Environment=MSVC, so that wouldn't cover other 
COFF environments. wbs (Martin Storsjo) mentioned on IRC that MinGW adds an 
aligncomm directive to specify alignment for common symbols, so perhaps that's 
part of it?

From: "Keane, Erich" 
Date: Tuesday, January 8, 2019 at 1:04 PM
To: Shoaib Meenai , "cfe-commits@lists.llvm.org" 
, David Majnemer 
Subject: RE: r350643 - Limit COFF 'common' emission to <=32 alignment types.

Yep, exactly.  I looked, and isKnownWindowsMSVCEnvironment checks for OS=Win32, 
which I believe would be different for other architectures.

From: Shoaib Meenai [mailto:smee...@fb.com]
Sent: Tuesday, January 8, 2019 12:41 PM
To: Keane, Erich ; cfe-commits@lists.llvm.org; David 
Majnemer 
Subject: Re: r350643 - Limit COFF 'common' emission to <=32 alignment types.

Ah, looks like you were originally checking for COFF, and then David suggested 
checking for MSVC instead? I'm curious about why, although I'm sure the 
suggestion is legit :)

From: cfe-commits 
mailto:cfe-commits-boun...@lists.llvm.org>> 
on behalf of Shoaib Meenai via cfe-commits 
mailto:cfe-commits@lists.llvm.org>>
Reply-To: Shoaib Meenai mailto:smee...@fb.com>>
Date: Tuesday, January 8, 2019 at 12:39 PM
To: Erich Keane mailto:erich.ke...@intel.com>>, 
"cfe-commits@lists.llvm.org<mailto:cfe-commits@lists.llvm.org>" 
mailto:cfe-commits@lists.llvm.org>>
Subject: Re: r350643 - Limit COFF 'common' emission to <=32 alignment types.

Why does this check for isKnownWindowsMSVCEnvironment specifically? Wouldn't 
any COFF target (windows-cygnus, windows-gnu, windows-itanium, etc.) have the 
same limitation, since it's an object file format issue and not an ABI issue?

From: cfe-commits 
mailto:cfe-commits-boun...@lists.llvm.org>> 
on behalf of Erich Keane via cfe-commits 
mailto:cfe-commits@lists.llvm.org>>
Reply-To: Erich Keane mailto:erich.ke...@intel.com>>
Date: Tuesday, January 8, 2019 at 10:48 AM
To: "cfe-commits@lists.llvm.org<mailto:cfe-commits@lists.llvm.org>" 
mailto:cfe-commits@lists.llvm.org>>
Subject: r350643 - Limit COFF 'common' emission to <=32 alignment types.

Author: erichkeane
Date: Tue Jan  8 10:44:22 2019
New Revision: 350643

URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D350643-26view-3Drev&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=RNVKy_b0_Wgp_PTFDpvQXETsZdWubmT5SGnGz3GigS0&s=Ph9GOtRaQERmqyeJeAJTFwV3sg3q8fE05FlJ3qwNx4I&e=
Log:
Limit COFF 'common' emission to <=32 alignment types.

As reported in PR33035, LLVM crashes if given a common object with an
alignment of greater than 32 bits. This is because the COFF file format
does not support these alignments, so emitting them is broken anyway.

This patch changes any global definitions greater than 32 bit alignment
to no longer be in 'common'.

https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.llvm.org_show-5Fbug.cgi-3Fid-3D33035&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=RNVKy_b0_Wgp_PTFDpvQXETsZdWubmT5SGnGz3GigS0&s=ac1NEHuvztd6jSTCsOUJajkklfeyqdzW-xqtddJ-hvM&e=

Differential Revision: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D56391&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=RNVKy_b0_Wgp_PTFDpvQXETsZdWubmT5SGnGz3GigS0&s=AucP9Sp-DYHSaOP-sPfpAOrww3xwdh8FjQkHrLZhhyo&e=

Change-Id: I48609289753b7f3b58c5e2bc1712756750fbd45a

Added:
cfe/trunk/test/CodeGen/microsoft-no-common-align.c
Modified:
cfe/trunk/lib/CodeGen/CodeGenModule.cpp

Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_cfe_trunk_lib_CodeGen_CodeGenModule.cpp-3Frev-3D350643-26r1-3D350642-26r2-3D350643-26view-3Ddiff&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=RNVKy_b0_Wgp_PTFDpvQXETsZdWubmT5SGnGz3GigS0&s=gmTnEmW03ruG8LbJluf5Z4yQcxM64QP7Ce1VTnVqvPo&e=
==
--- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Tue Jan  8 10:44:22 2019
@@ -3761,6 +3761,11 @@ static bool isVarDeclStrongDefinition(co
   }
 }
   }
+  // COFF doesn't support alignments greater than 32, so these cannot be
+  // in common.
+  if (Context.getTargetInfo().getTriple().isKnownWindowsMSVCEnvironment() &&
+  Context.getTypeAlignIfKnown(D->getType()) > 32)
+return true;
   return false;
}

Added: cfe/trunk/test/CodeGen/microsoft-no-common-align.c
URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_cfe_trunk_test_CodeGen_microsoft-2Dno-2Dcommon-2Dalign.c-3Frev-3D3506

Re: r350643 - Limit COFF 'common' emission to <=32 alignment types.

[Shoaib Meenai via cfe-commits]

I sent out https://reviews.llvm.org/D56466 to clarify the comment accordingly.

From: David Majnemer 
Date: Tuesday, January 8, 2019 at 3:21 PM
To: Shoaib Meenai 
Cc: "Keane, Erich" , "cfe-commits@lists.llvm.org" 
, Martin Storsjo 
Subject: Re: r350643 - Limit COFF 'common' emission to <=32 alignment types.

Yes, the MinGW toolchain can handle this by specifying the alignment of a 
common symbol using the aligncomm directive. The MSVC toolchain has no such 
mechanism.

This is why the check uses isKnownWindowsMSVCEnvironment.

On Tue, Jan 8, 2019 at 1:09 PM Shoaib Meenai 
mailto:smee...@fb.com>> wrote:
It checks for both OS=Win32 and Environment=MSVC, so that wouldn't cover other 
COFF environments. wbs (Martin Storsjo) mentioned on IRC that MinGW adds an 
aligncomm directive to specify alignment for common symbols, so perhaps that's 
part of it?

From: "Keane, Erich" mailto:erich.ke...@intel.com>>
Date: Tuesday, January 8, 2019 at 1:04 PM
To: Shoaib Meenai mailto:smee...@fb.com>>, 
"cfe-commits@lists.llvm.org<mailto:cfe-commits@lists.llvm.org>" 
mailto:cfe-commits@lists.llvm.org>>, David Majnemer 
mailto:david.majne...@gmail.com>>
Subject: RE: r350643 - Limit COFF 'common' emission to <=32 alignment types.

Yep, exactly.  I looked, and isKnownWindowsMSVCEnvironment checks for OS=Win32, 
which I believe would be different for other architectures.

From: Shoaib Meenai [mailto:smee...@fb.com<mailto:smee...@fb.com>]
Sent: Tuesday, January 8, 2019 12:41 PM
To: Keane, Erich mailto:erich.ke...@intel.com>>; 
cfe-commits@lists.llvm.org<mailto:cfe-commits@lists.llvm.org>; David Majnemer 
mailto:david.majne...@gmail.com>>
Subject: Re: r350643 - Limit COFF 'common' emission to <=32 alignment types.

Ah, looks like you were originally checking for COFF, and then David suggested 
checking for MSVC instead? I'm curious about why, although I'm sure the 
suggestion is legit :)

From: cfe-commits 
mailto:cfe-commits-boun...@lists.llvm.org>> 
on behalf of Shoaib Meenai via cfe-commits 
mailto:cfe-commits@lists.llvm.org>>
Reply-To: Shoaib Meenai mailto:smee...@fb.com>>
Date: Tuesday, January 8, 2019 at 12:39 PM
To: Erich Keane mailto:erich.ke...@intel.com>>, 
"cfe-commits@lists.llvm.org<mailto:cfe-commits@lists.llvm.org>" 
mailto:cfe-commits@lists.llvm.org>>
Subject: Re: r350643 - Limit COFF 'common' emission to <=32 alignment types.

Why does this check for isKnownWindowsMSVCEnvironment specifically? Wouldn't 
any COFF target (windows-cygnus, windows-gnu, windows-itanium, etc.) have the 
same limitation, since it's an object file format issue and not an ABI issue?

From: cfe-commits 
mailto:cfe-commits-boun...@lists.llvm.org>> 
on behalf of Erich Keane via cfe-commits 
mailto:cfe-commits@lists.llvm.org>>
Reply-To: Erich Keane mailto:erich.ke...@intel.com>>
Date: Tuesday, January 8, 2019 at 10:48 AM
To: "cfe-commits@lists.llvm.org<mailto:cfe-commits@lists.llvm.org>" 
mailto:cfe-commits@lists.llvm.org>>
Subject: r350643 - Limit COFF 'common' emission to <=32 alignment types.

Author: erichkeane
Date: Tue Jan  8 10:44:22 2019
New Revision: 350643

URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D350643-26view-3Drev&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=RNVKy_b0_Wgp_PTFDpvQXETsZdWubmT5SGnGz3GigS0&s=Ph9GOtRaQERmqyeJeAJTFwV3sg3q8fE05FlJ3qwNx4I&e=
Log:
Limit COFF 'common' emission to <=32 alignment types.

As reported in PR33035, LLVM crashes if given a common object with an
alignment of greater than 32 bits. This is because the COFF file format
does not support these alignments, so emitting them is broken anyway.

This patch changes any global definitions greater than 32 bit alignment
to no longer be in 'common'.

https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.llvm.org_show-5Fbug.cgi-3Fid-3D33035&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=RNVKy_b0_Wgp_PTFDpvQXETsZdWubmT5SGnGz3GigS0&s=ac1NEHuvztd6jSTCsOUJajkklfeyqdzW-xqtddJ-hvM&e=

Differential Revision: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D56391&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=RNVKy_b0_Wgp_PTFDpvQXETsZdWubmT5SGnGz3GigS0&s=AucP9Sp-DYHSaOP-sPfpAOrww3xwdh8FjQkHrLZhhyo&e=

Change-Id: I48609289753b7f3b58c5e2bc1712756750fbd45a

Added:
cfe/trunk/test/CodeGen/microsoft-no-common-align.c
Modified:
cfe/trunk/lib/CodeGen/CodeGenModule.cpp

Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_cfe_trunk_lib_CodeGen_CodeGenModule.cpp-3Frev-3D350643-26r1-3D350642-26r2-3D3

r350754 - [CodeGen] Clarify comment about COFF common symbol alignment

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Wed Jan  9 12:05:16 2019
New Revision: 350754

URL: http://llvm.org/viewvc/llvm-project?rev=350754&view=rev
Log:
[CodeGen] Clarify comment about COFF common symbol alignment

After a discussion on the commit thread, it seems the 32 byte alignment
limitation is an MSVC toolchain artifact, not an inherent COFF
restriction. Clarify the comment accordingly, since saying COFF in the
comment but using isKnownWindowsMSVCEnvironment in the conditional is
confusing. Also add a newline before the comment, which is consistent
with the local style.

Differential Revision: https://reviews.llvm.org/D56466

Modified:
cfe/trunk/lib/CodeGen/CodeGenModule.cpp

Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp?rev=350754&r1=350753&r2=350754&view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Wed Jan  9 12:05:16 2019
@@ -3761,8 +3761,12 @@ static bool isVarDeclStrongDefinition(co
   }
 }
   }
-  // COFF doesn't support alignments greater than 32, so these cannot be
-  // in common.
+
+  // Microsoft's link.exe doesn't support alignments greater than 32 for common
+  // symbols, so symbols with greater alignment requirements cannot be common.
+  // Other COFF linkers (ld.bfd and LLD) support arbitrary power-of-two
+  // alignments for common symbols via the aligncomm directive, so this
+  // restriction only applies to MSVC environments.
   if (Context.getTargetInfo().getTriple().isKnownWindowsMSVCEnvironment() &&
   Context.getTypeAlignIfKnown(D->getType()) > 32)
 return true;


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

Re: r329882 - ObjCGNU: Fix empty v3 protocols being emitted two fields short

[Shoaib Meenai via cfe-commits]

This is missing an attribution of changes, right?

From: cfe-commits  on behalf of David 
Chisnall via cfe-commits 
Reply-To: David Chisnall 
Date: Wednesday, April 11, 2018 at 11:49 PM
To: "cfe-commits@lists.llvm.org" 
Subject: r329882 - ObjCGNU: Fix empty v3 protocols being emitted two fields 
short

Author: theraven
Date: Wed Apr 11 23:46:15 2018
New Revision: 329882

URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D329882-26view-3Drev&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=kOSrBx9BPwaPzisR4ZjTMKz416HW7XRohfwPXtT5O9E&s=69tkdQlTNiO-wOTuNHO7a35iqDVy9hW6Jrw-hSq_q6s&e=
Log:
ObjCGNU: Fix empty v3 protocols being emitted two fields short

Summary:
Protocols that were being referenced but could not be fully realized were being 
emitted without `properties`/`optional_properties`. Since all v3 protocols must 
be 9 processor words wide, the lack of these fields is catastrophic for the 
runtime.

As an example, the runtime cannot know 
[here](https://github.com/gnustep/libobjc2/blob/master/protocol.c#L73) that 
`properties` and `optional_properties` are invalid.

Reviewers: rjmccall, theraven

Reviewed By: rjmccall, theraven

Subscribers: cfe-commits

Tags: #clang

Differential Revision: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D45305&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=kOSrBx9BPwaPzisR4ZjTMKz416HW7XRohfwPXtT5O9E&s=JoyP68pCdLsffM8xX9NMx9VXafshpTnxECegbsdc4rc&e=

Added:
cfe/trunk/test/CodeGenObjC/gnu-empty-protocol-v3.m
Modified:
cfe/trunk/lib/CodeGen/CGObjCGNU.cpp

Modified: cfe/trunk/lib/CodeGen/CGObjCGNU.cpp
URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_cfe_trunk_lib_CodeGen_CGObjCGNU.cpp-3Frev-3D329882-26r1-3D329881-26r2-3D329882-26view-3Ddiff&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=kOSrBx9BPwaPzisR4ZjTMKz416HW7XRohfwPXtT5O9E&s=v2_iviP5qFoN3SvBUJtLVbxpLsyewCRlyAbxv96yJiI&e=
==
--- cfe/trunk/lib/CodeGen/CGObjCGNU.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGObjCGNU.cpp Wed Apr 11 23:46:15 2018
@@ -1748,11 +1748,13 @@ CGObjCGNU::GenerateEmptyProtocol(const s
   llvm::ConstantInt::get(Int32Ty, ProtocolVersion), IdTy));
   Elements.add(MakeConstantString(ProtocolName, ".objc_protocol_name"));
-  Elements.add(ProtocolList);
-  Elements.add(MethodList);
-  Elements.add(MethodList);
-  Elements.add(MethodList);
-  Elements.add(MethodList);
+  Elements.add(ProtocolList); /* .protocol_list */
+  Elements.add(MethodList);   /* .instance_methods */
+  Elements.add(MethodList);   /* .class_methods */
+  Elements.add(MethodList);   /* .optional_instance_methods */
+  Elements.add(MethodList);   /* .optional_class_methods */
+  Elements.add(NULLPtr);  /* .properties */
+  Elements.add(NULLPtr);  /* .optional_properties */
   return Elements.finishAndCreateGlobal(".objc_protocol",
 CGM.getPointerAlign());
}

Added: cfe/trunk/test/CodeGenObjC/gnu-empty-protocol-v3.m
URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_cfe_trunk_test_CodeGenObjC_gnu-2Dempty-2Dprotocol-2Dv3.m-3Frev-3D329882-26view-3Dauto&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=kOSrBx9BPwaPzisR4ZjTMKz416HW7XRohfwPXtT5O9E&s=arR3-NaqV7bUw3lmGH8VA1UAMCgPZ2Xf4Zbn-tKJY-A&e=
==
--- cfe/trunk/test/CodeGenObjC/gnu-empty-protocol-v3.m (added)
+++ cfe/trunk/test/CodeGenObjC/gnu-empty-protocol-v3.m Wed Apr 11 23:46:15 2018
@@ -0,0 +1,25 @@
+// RUN: %clang_cc1 -triple i686-pc-linux-gnu -fobjc-runtime=gnustep-1.9 
-emit-llvm -o - %s | FileCheck %s
+
+@protocol X;
+
+__attribute__((objc_root_class))
+@interface Z 
+@end
+
+@implementation Z
+@end
+
+// CHECK:  @.objc_protocol_list = internal global { i8*, i32, [0 x i8*] } 
zeroinitializer, align 4
+// CHECK:  @.objc_method_list = internal global { i32, [0 x { i8*, i8* }] 
} zeroinitializer, align 4
+// CHECK:  @.objc_protocol_name = private unnamed_addr constant [2 x i8] 
c"X\00", align 1
+// CHECK:  @.objc_protocol = internal global { i8*, i8*, { i8*, i32, [0 x 
i8*] }*, { i32, [0 x { i8*, i8* }] }*, { i32, [0 x { i8*, i8* }] }*, { i32, [0 
x { i8*, i8* }] }*, { i32, [0 x { i8*, i8* }] }*, i8*, i8* } {
+// CHECK-SAME: i8* inttoptr (i32 3 to i8*),
+// CHECK-SAME: i8* getelementptr inbounds ([2 x i8], [2 x i8]* 
@.objc_protocol_name, i32 0, i32 0),
+// CHECK-SAME: { i8*, i32, [0 x i8*] }* @.objc_protocol_list,
+// CHECK-SAME: { i32, [0 x { i8*, i8* }] }* @.objc_method_list,
+// CHECK-SAME: { i32, [0 x { i8*, i8* }] }* @.objc_method_list,
+// CHECK-SAME: { i32, [0 x { i8*, i8* }] }* @.objc_method_list,
+// CHECK-SAME: { i32, [0 x { i8*, i8* }] }* @.objc_method_list,
+// CHECK-SAME: i8* null,
+// CHECK-SAME: i8* null
+// CHECK-

Re: r329882 - ObjCGNU: Fix empty v3 protocols being emitted two fields short

[Shoaib Meenai via cfe-commits]

AFAIK you need to add the "Patch by …" line manually. I don't know if arc is 
supposed to preserve the original commit author information, though I would 
suspect the version control system itself plays a role there.

From: David Chisnall  on behalf of David Chisnall 

Date: Thursday, April 12, 2018 at 12:37 AM
To: Shoaib Meenai 
Cc: "cfe-commits@lists.llvm.org" 
Subject: Re: r329882 - ObjCGNU: Fix empty v3 protocols being emitted two fields 
short

It does seem to be.  I used arc to apply the change, so I’m not sure what 
happened - I thought it normally set the author correctly.

David

On 12 Apr 2018, at 08:09, Shoaib Meenai mailto:smee...@fb.com>> 
wrote:
This is missing an attribution of changes, right?

From: cfe-commits 
mailto:cfe-commits-boun...@lists.llvm.org>> 
on behalf of David Chisnall via cfe-commits 
mailto:cfe-commits@lists.llvm.org>>
Reply-To: David Chisnall mailto:csda...@swan.ac.uk>>
Date: Wednesday, April 11, 2018 at 11:49 PM
To: "cfe-commits@lists.llvm.org" 
mailto:cfe-commits@lists.llvm.org>>
Subject: r329882 - ObjCGNU: Fix empty v3 protocols being emitted two fields 
short

Author: theraven
Date: Wed Apr 11 23:46:15 2018
New Revision: 329882

URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D329882-26view-3Drev&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=kOSrBx9BPwaPzisR4ZjTMKz416HW7XRohfwPXtT5O9E&s=69tkdQlTNiO-wOTuNHO7a35iqDVy9hW6Jrw-hSq_q6s&e=
Log:
ObjCGNU: Fix empty v3 protocols being emitted two fields short

Summary:
Protocols that were being referenced but could not be fully realized were being 
emitted without `properties`/`optional_properties`. Since all v3 protocols must 
be 9 processor words wide, the lack of these fields is catastrophic for the 
runtime.

As an example, the runtime cannot know 
[here](https://github.com/gnustep/libobjc2/blob/master/protocol.c#L73) that 
`properties` and `optional_properties` are invalid.

Reviewers: rjmccall, theraven

Reviewed By: rjmccall, theraven

Subscribers: cfe-commits

Tags: #clang

Differential Revision: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D45305&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=kOSrBx9BPwaPzisR4ZjTMKz416HW7XRohfwPXtT5O9E&s=JoyP68pCdLsffM8xX9NMx9VXafshpTnxECegbsdc4rc&e=

Added:
 cfe/trunk/test/CodeGenObjC/gnu-empty-protocol-v3.m
Modified:
 cfe/trunk/lib/CodeGen/CGObjCGNU.cpp

Modified: cfe/trunk/lib/CodeGen/CGObjCGNU.cpp
URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_cfe_trunk_lib_CodeGen_CGObjCGNU.cpp-3Frev-3D329882-26r1-3D329881-26r2-3D329882-26view-3Ddiff&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=kOSrBx9BPwaPzisR4ZjTMKz416HW7XRohfwPXtT5O9E&s=v2_iviP5qFoN3SvBUJtLVbxpLsyewCRlyAbxv96yJiI&e=
==
--- cfe/trunk/lib/CodeGen/CGObjCGNU.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGObjCGNU.cpp Wed Apr 11 23:46:15 2018
@@ -1748,11 +1748,13 @@ CGObjCGNU::GenerateEmptyProtocol(const s
llvm::ConstantInt::get(Int32Ty, ProtocolVersion), IdTy));
Elements.add(MakeConstantString(ProtocolName, ".objc_protocol_name"));
-  Elements.add(ProtocolList);
-  Elements.add(MethodList);
-  Elements.add(MethodList);
-  Elements.add(MethodList);
-  Elements.add(MethodList);
+  Elements.add(ProtocolList); /* .protocol_list */
+  Elements.add(MethodList);   /* .instance_methods */
+  Elements.add(MethodList);   /* .class_methods */
+  Elements.add(MethodList);   /* .optional_instance_methods */
+  Elements.add(MethodList);   /* .optional_class_methods */
+  Elements.add(NULLPtr);  /* .properties */
+  Elements.add(NULLPtr);  /* .optional_properties */
return Elements.finishAndCreateGlobal(".objc_protocol",
  CGM.getPointerAlign());
}

Added: cfe/trunk/test/CodeGenObjC/gnu-empty-protocol-v3.m
URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_cfe_trunk_test_CodeGenObjC_gnu-2Dempty-2Dprotocol-2Dv3.m-3Frev-3D329882-26view-3Dauto&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=kOSrBx9BPwaPzisR4ZjTMKz416HW7XRohfwPXtT5O9E&s=arR3-NaqV7bUw3lmGH8VA1UAMCgPZ2Xf4Zbn-tKJY-A&e=
==
--- cfe/trunk/test/CodeGenObjC/gnu-empty-protocol-v3.m (added)
+++ cfe/trunk/test/CodeGenObjC/gnu-empty-protocol-v3.m Wed Apr 11 23:46:15 2018
@@ -0,0 +1,25 @@
+// RUN: %clang_cc1 -triple i686-pc-linux-gnu -fobjc-runtime=gnustep-1.9 
-emit-llvm -o - %s | FileCheck %s
+
+@protocol X;
+
+__attribute__((objc_root_class))
+@interface Z 
+@end
+
+@implementation Z
+@end
+
+// CHECK:  @.objc_protocol_list = internal global { i8*, i32, [0 x i8*] } 
zeroinitializer, align 4
+// CHECK:  @.objc_method_list = internal global { i32, [0 x { i8*, i8* }] 
} zeroinitializer, align 4
+// CHECK:  @.objc_protocol_na

r331305 - [ARM] Remove redundant #if in test. NFC

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Tue May  1 13:38:05 2018
New Revision: 331305

URL: http://llvm.org/viewvc/llvm-project?rev=331305&view=rev
Log:
[ARM] Remove redundant #if in test. NFC

Both sides of this #if #include the same file. Drop the #if, leaving only the 
#include.

Patch by Matt Glazar.

Differential Revision: https://reviews.llvm.org/D45779

Modified:
cfe/trunk/test/CodeGen/arm-aapcs-vfp.c

Modified: cfe/trunk/test/CodeGen/arm-aapcs-vfp.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/arm-aapcs-vfp.c?rev=331305&r1=331304&r2=331305&view=diff
==
--- cfe/trunk/test/CodeGen/arm-aapcs-vfp.c (original)
+++ cfe/trunk/test/CodeGen/arm-aapcs-vfp.c Tue May  1 13:38:05 2018
@@ -17,11 +17,7 @@
 // RUN:   -ffreestanding \
 // RUN:   -emit-llvm -w -o - %s | FileCheck -check-prefix=CHECK64 %s
 
-#ifdef __arm64__
 #include 
-#else
-#include 
-#endif
 
 struct homogeneous_struct {
   float f[2];


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

r331306 - [libclang] Fix the type of 'int (Foo);'

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Tue May  1 13:45:25 2018
New Revision: 331306

URL: http://llvm.org/viewvc/llvm-project?rev=331306&view=rev
Log:
[libclang] Fix the type of 'int (Foo);'

libclang exposes the type of 'int (Foo);' (a global variable of type int
called Foo) as CXType_Unexposed. This is because Clang represents Foo's
type as ParenType{BuiltinType{Int}}, and libclang does not handle
ParenType.

Make libclang return CXType_Int as the type of 'int (Foo);' by
unwrapping ParenType transparently.

Patch by Matt Glazar.

Differential Revision: https://reviews.llvm.org/D45713

Added:
cfe/trunk/test/Index/paren-type.c
Modified:
cfe/trunk/test/Index/print-type.c
cfe/trunk/tools/libclang/CXType.cpp

Added: cfe/trunk/test/Index/paren-type.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Index/paren-type.c?rev=331306&view=auto
==
--- cfe/trunk/test/Index/paren-type.c (added)
+++ cfe/trunk/test/Index/paren-type.c Tue May  1 13:45:25 2018
@@ -0,0 +1,16 @@
+// RUN: c-index-test -test-print-type %s | FileCheck --check-prefix=CHECK-TYPE 
%s
+// RUN: c-index-test -test-print-type-declaration %s | FileCheck 
--check-prefix=CHECK-TYPEDECL %s
+
+// CHECK-TYPE: VarDecl=VariableWithParentheses:
+// CHECK-TYPE-SAME: [type=int] [typekind=Int]
+// CHECK-TYPE-NOT: canonicaltype
+// CHECK-TYPE-SAME: isPOD
+extern int (VariableWithParentheses);
+
+typedef int MyTypedef;
+// CHECK-TYPE: VarDecl=VariableWithParentheses2:
+// CHECK-TYPE-SAME: [type=MyTypedef] [typekind=Typedef]
+// CHECK-TYPE-SAME: [canonicaltype=int] [canonicaltypekind=Int]
+// CHECK-TYPEDECL: VarDecl=VariableWithParentheses2
+// CHECK-TYPEDECL-SAME: [typedeclaration=MyTypedef] [typekind=Typedef]
+extern MyTypedef (VariableWithParentheses2);

Modified: cfe/trunk/test/Index/print-type.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Index/print-type.c?rev=331306&r1=331305&r2=331306&view=diff
==
--- cfe/trunk/test/Index/print-type.c (original)
+++ cfe/trunk/test/Index/print-type.c Tue May  1 13:45:25 2018
@@ -23,11 +23,11 @@ struct Struct{}; struct Struct elaborate
 // CHECK: TypeRef=FooType:1:13 [type=FooType] [typekind=Typedef] 
[canonicaltype=int] [canonicaltypekind=Int] [isPOD=1]
 // CHECK: ParmDecl=arr:3:40 (Definition) [type=int [5]] 
[typekind=ConstantArray] [isPOD=1]
 // CHECK: IntegerLiteral= [type=int] [typekind=Int] [isPOD=1]
-// CHECK: ParmDecl=fn:3:55 (Definition) [type=void (*)(int)] 
[typekind=Pointer] [canonicaltype=void (*)(int)] [canonicaltypekind=Pointer] 
[isPOD=1] [pointeetype=void (int)] [pointeekind=Unexposed]
+// CHECK: ParmDecl=fn:3:55 (Definition) [type=void (*)(int)] 
[typekind=Pointer] [canonicaltype=void (*)(int)] [canonicaltypekind=Pointer] 
[isPOD=1] [pointeetype=void (int)] [pointeekind=FunctionProto]
 // CHECK: ParmDecl=:3:62 (Definition) [type=int] [typekind=Int] [isPOD=1]
 // CHECK: CompoundStmt= [type=] [typekind=Invalid] [isPOD=0]
 // CHECK: CallExpr=fn:3:55 [type=void] [typekind=Void] [args= [int] [Int]] 
[isPOD=0]
-// CHECK: DeclRefExpr=fn:3:55 [type=void (*)(int)] [typekind=Pointer] 
[canonicaltype=void (*)(int)] [canonicaltypekind=Pointer] [isPOD=1] 
[pointeetype=void (int)] [pointeekind=Unexposed]
+// CHECK: DeclRefExpr=fn:3:55 [type=void (*)(int)] [typekind=Pointer] 
[canonicaltype=void (*)(int)] [canonicaltypekind=Pointer] [isPOD=1] 
[pointeetype=void (int)] [pointeekind=FunctionProto]
 // CHECK: UnaryOperator= [type=int] [typekind=Int] [isPOD=1]
 // CHECK: DeclRefExpr=p:3:13 [type=int *] [typekind=Pointer] [isPOD=1] 
[pointeetype=int] [pointeekind=Int]
 // CHECK: DeclStmt= [type=] [typekind=Invalid] [isPOD=0]

Modified: cfe/trunk/tools/libclang/CXType.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/libclang/CXType.cpp?rev=331306&r1=331305&r2=331306&view=diff
==
--- cfe/trunk/tools/libclang/CXType.cpp (original)
+++ cfe/trunk/tools/libclang/CXType.cpp Tue May  1 13:45:25 2018
@@ -119,6 +119,10 @@ CXType cxtype::MakeCXType(QualType T, CX
 if (auto *ATT = T->getAs()) {
   return MakeCXType(ATT->getModifiedType(), TU);
 }
+// Handle paren types as the original type
+if (auto *PTT = T->getAs()) {
+  return MakeCXType(PTT->getInnerType(), TU);
+}
 
 ASTContext &Ctx = cxtu::getASTUnit(TU)->getASTContext();
 if (Ctx.getLangOpts().ObjC1) {


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

Re: r335618 - [ThinLTO] Add testing of summary index parsing to a couple CFI tests

[Shoaib Meenai via cfe-commits]

The check lines added here are failing for me on CentOS 7. 
https://reviews.llvm.org/P8091 has the lit output and the actual output being 
produced by one of the added RUN lines. My llvm and clang repositories are in 
sync. Any idea what might be going on here?

From: cfe-commits  on behalf of Teresa 
Johnson via cfe-commits 
Reply-To: Teresa Johnson 
Date: Tuesday, June 26, 2018 at 8:55 AM
To: "cfe-commits@lists.llvm.org" 
Subject: r335618 - [ThinLTO] Add testing of summary index parsing to a couple 
CFI tests

Author: tejohnson
Date: Tue Jun 26 08:50:34 2018
New Revision: 335618

URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D335618-26view-3Drev&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=t3QlYWXjMDXjKJ9zRV9gsXH-VakqyyLmPocT9T_axY8&s=sFcyz-6EIWKbnsSlIcghgfqpuW73fEF48XuoUDzbohk&e=
Log:
[ThinLTO] Add testing of summary index parsing to a couple CFI tests

Summary:
Changes to some clang side tests to go with the summary parsing patch.

Depends on D47905.

Reviewers: pcc, dexonsmith, mehdi_amini

Subscribers: inglorion, eraman, cfe-commits, steven_wu

Differential Revision: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D47906&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=t3QlYWXjMDXjKJ9zRV9gsXH-VakqyyLmPocT9T_axY8&s=jQWcXM3uTGYSu5wgYQ_0NcHaJj9V9DOBoJcL8bxbjc4&e=

Modified:
cfe/trunk/test/CodeGen/thinlto-distributed-cfi-devirt.ll
cfe/trunk/test/CodeGen/thinlto-distributed-cfi.ll

Modified: cfe/trunk/test/CodeGen/thinlto-distributed-cfi-devirt.ll
URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_cfe_trunk_test_CodeGen_thinlto-2Ddistributed-2Dcfi-2Ddevirt.ll-3Frev-3D335618-26r1-3D335617-26r2-3D335618-26view-3Ddiff&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=t3QlYWXjMDXjKJ9zRV9gsXH-VakqyyLmPocT9T_axY8&s=DQBuDzMNex1JeoqLkc4S9ZTXRVWN2wCcbmk3U7hzKDQ&e=
==
--- cfe/trunk/test/CodeGen/thinlto-distributed-cfi-devirt.ll (original)
+++ cfe/trunk/test/CodeGen/thinlto-distributed-cfi-devirt.ll Tue Jun 26 
08:50:34 2018
@@ -30,6 +30,8 @@
; CHECK-LABEL: https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_cfe_trunk_test_CodeGen_thinlto-2Ddistributed-2Dcfi.ll-3Frev-3D335618-26r1-3D335617-26r2-3D335618-26view-3Ddiff&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=t3QlYWXjMDXjKJ9zRV9gsXH-VakqyyLmPocT9T_axY8&s=PAH2s9gPirL0F8r0JQYFEoT0zKAnd6n9XnhXUvluugU&e=
==
--- cfe/trunk/test/CodeGen/thinlto-distributed-cfi.ll (original)
+++ cfe/trunk/test/CodeGen/thinlto-distributed-cfi.ll Tue Jun 26 08:50:34 2018
@@ -21,6 +21,8 @@
; CHECK-LABEL: mailto:cfe-commits@lists.llvm.org>
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_cfe-2Dcommits&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=t3QlYWXjMDXjKJ9zRV9gsXH-VakqyyLmPocT9T_axY8&s=xZ7KB8LgXcujdQpqz54h14kTUJ7Tpf8hTlHsd_q2Atk&e=

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

r335686 - [clang] Add test dependency on llvm-as

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Tue Jun 26 16:18:59 2018
New Revision: 335686

URL: http://llvm.org/viewvc/llvm-project?rev=335686&view=rev
Log:
[clang] Add test dependency on llvm-as

r335618 added tests that invoke llvm-as, so we should also ensure that
running clang tests rebuilds llvm-as.

Modified:
cfe/trunk/test/CMakeLists.txt

Modified: cfe/trunk/test/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CMakeLists.txt?rev=335686&r1=335685&r2=335686&view=diff
==
--- cfe/trunk/test/CMakeLists.txt (original)
+++ cfe/trunk/test/CMakeLists.txt Tue Jun 26 16:18:59 2018
@@ -94,6 +94,7 @@ if( NOT CLANG_BUILT_STANDALONE )
 llvm-config
 FileCheck count not
 llc
+llvm-as
 llvm-bcanalyzer
 llvm-cat
 llvm-dis


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

Re: r335618 - [ThinLTO] Add testing of summary index parsing to a couple CFI tests

[Shoaib Meenai via cfe-commits]

Ah, my llvm-as was indeed out of date. I made check-clang depend on llvm-as in 
r335686 to avoid this issue in the future.

From: Teresa Johnson 
Date: Tuesday, June 26, 2018 at 4:11 PM
To: Shoaib Meenai 
Cc: "cfe-commits@lists.llvm.org" 
Subject: Re: r335618 - [ThinLTO] Add testing of summary index parsing to a 
couple CFI tests

I haven't seen any bot failures for the change. The failing check was there 
before, so presumably llvm-dis on its own is producing the expected lines, just 
not when it goes through llvm-as. Can you let me know whether llvm-as has been 
updated and whether it gives an error. Note that there were a number of other 
similar test changes committed in the main llvm-side patch D47905 shortly 
before this one. Are any of those failing for you?
Teresa
On Tue, Jun 26, 2018, 3:47 PM Shoaib Meenai 
mailto:smee...@fb.com>> wrote:
The check lines added here are failing for me on CentOS 7. 
https://reviews.llvm.org/P8091
 has the lit output and the actual output being produced by one of the added 
RUN lines. My llvm and clang repositories are in sync. Any idea what might be 
going on here?

From: cfe-commits 
mailto:cfe-commits-boun...@lists.llvm.org>> 
on behalf of Teresa Johnson via cfe-commits 
mailto:cfe-commits@lists.llvm.org>>
Reply-To: Teresa Johnson mailto:tejohn...@google.com>>
Date: Tuesday, June 26, 2018 at 8:55 AM
To: "cfe-commits@lists.llvm.org" 
mailto:cfe-commits@lists.llvm.org>>
Subject: r335618 - [ThinLTO] Add testing of summary index parsing to a couple 
CFI tests

Author: tejohnson
Date: Tue Jun 26 08:50:34 2018
New Revision: 335618

URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D335618-26view-3Drev&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=t3QlYWXjMDXjKJ9zRV9gsXH-VakqyyLmPocT9T_axY8&s=sFcyz-6EIWKbnsSlIcghgfqpuW73fEF48XuoUDzbohk&e=
Log:
[ThinLTO] Add testing of summary index parsing to a couple CFI tests

Summary:
Changes to some clang side tests to go with the summary parsing patch.

Depends on D47905.

Reviewers: pcc, dexonsmith, mehdi_amini

Subscribers: inglorion, eraman, cfe-commits, steven_wu

Differential Revision: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D47906&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=t3QlYWXjMDXjKJ9zRV9gsXH-VakqyyLmPocT9T_axY8&s=jQWcXM3uTGYSu5wgYQ_0NcHaJj9V9DOBoJcL8bxbjc4&e=

Modified:
cfe/trunk/test/CodeGen/thinlto-distributed-cfi-devirt.ll
cfe/trunk/test/CodeGen/thinlto-distributed-cfi.ll

Modified: cfe/trunk/test/CodeGen/thinlto-distributed-cfi-devirt.ll
URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_cfe_trunk_test_CodeGen_thinlto-2Ddistributed-2Dcfi-2Ddevirt.ll-3Frev-3D335618-26r1-3D335617-26r2-3D335618-26view-3Ddiff&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=t3QlYWXjMDXjKJ9zRV9gsXH-VakqyyLmPocT9T_axY8&s=DQBuDzMNex1JeoqLkc4S9ZTXRVWN2wCcbmk3U7hzKDQ&e=
==
--- cfe/trunk/test/CodeGen/thinlto-distributed-cfi-devirt.ll (original)
+++ cfe/trunk/test/CodeGen/thinlto-distributed-cfi-devirt.ll Tue Jun 26 
08:50:34 2018
@@ -30,6 +30,8 @@
; CHECK-LABEL: https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_cfe_trunk_test_CodeGen_thinlto-2Ddistributed-2Dcfi.ll-3Frev-3D335618-26r1-3D335617-26r2-3D335618-26view-3Ddiff&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=t3QlYWXjMDXjKJ9zRV9gsXH-VakqyyLmPocT9T_axY8&s=PAH2s9gPirL0F8r0JQYFEoT0zKAnd6n9XnhXUvluugU&e=
==
--- cfe/trunk/test/CodeGen/thinlto-distributed-cfi.ll (original)
+++ cfe/trunk/test/CodeGen/thinlto-distributed-cfi.ll Tue Jun 26 08:50:34 2018
@@ -21,6 +21,8 @@
; CHECK-LABEL: mailto:cfe-commits@lists.llvm.org>
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_cfe-2Dcommits&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=t3QlYWXjMDXjKJ9zRV9gsXH-VakqyyLmPocT9T_axY8&s=xZ7KB8LgXcujdQpqz54h14kTUJ7Tpf8hTlHsd_q2Atk&e=

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

[libcxxabi] r336032 - [libc++abi] Limit libc++ header search to specified paths

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Fri Jun 29 18:04:50 2018
New Revision: 336032

URL: http://llvm.org/viewvc/llvm-project?rev=336032&view=rev
Log:
[libc++abi] Limit libc++ header search to specified paths

Right now, when libc++abi is locating libc++ headers, it specifies
several search locations, but it also doesn't prevent CMake from looking
for those headers in system directories. I don't know if this was
intentional or an oversight, but it has several issues:

* We're looking specifically for the vector header, which could just as
  easily be found in a libstdc++ (or other C++ library) installation.
* No system I know of places their C++ headers directly in system
  include directories (they're always under a C++ subdirectory), so the
  system search will never succeed.
* find_path searches system paths before the user-specified PATHS, so
  if some system does happen to have C++ headers in its system include
  directories, those headers will be preferred, which doesn't seem
  desirable.

It makes sense to me to limit this header search to the explicitly
specified paths (using NO_DEFAULT_PATH, as is done for the other
find_path call in this file), but I'm putting it up for review in case
there's some use case I'm not thinking of.

Differential Revision: https://reviews.llvm.org/D48694

Modified:
libcxxabi/trunk/CMakeLists.txt

Modified: libcxxabi/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxxabi/trunk/CMakeLists.txt?rev=336032&r1=336031&r2=336032&view=diff
==
--- libcxxabi/trunk/CMakeLists.txt (original)
+++ libcxxabi/trunk/CMakeLists.txt Fri Jun 29 18:04:50 2018
@@ -116,6 +116,7 @@ find_path(
 ${CMAKE_BINARY_DIR}/${LIBCXXABI_LIBCXX_INCLUDES}
 ${LIBCXXABI_LIBCXX_INCLUDE_DIRS}
 ${LLVM_INCLUDE_DIR}/c++/v1
+  NO_DEFAULT_PATH
   NO_CMAKE_FIND_ROOT_PATH
   )
 


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

[libcxxabi] r336034 - [libc++abi] Look for __config instead of vector

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Fri Jun 29 18:25:47 2018
New Revision: 336034

URL: http://llvm.org/viewvc/llvm-project?rev=336034&view=rev
Log:
[libc++abi] Look for __config instead of vector

vector is a generic C++ header, whereas __config is libc++-specific, so
we can look for it instead to guarantee we're finding a libc++
installation. This was suggested by Eric in https://reviews.llvm.org/D48694.

This is less important now that we're limiting the header search to the
specified directories (which definitely shouldn't have any other C++
library's headers anyway), but it shouldn't hurt either. There's a
chance some other library could also be providing a __config header, so
there's still a trade-off there. It would be ideal if we could check for
the presence of both __config and vector in the same directory, but
there doesn't seem to be any easy way to do that in CMake.

Modified:
libcxxabi/trunk/CMakeLists.txt

Modified: libcxxabi/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxxabi/trunk/CMakeLists.txt?rev=336034&r1=336033&r2=336034&view=diff
==
--- libcxxabi/trunk/CMakeLists.txt (original)
+++ libcxxabi/trunk/CMakeLists.txt Fri Jun 29 18:25:47 2018
@@ -110,7 +110,7 @@ endforeach()
 
 find_path(
   LIBCXXABI_LIBCXX_INCLUDES
-  vector
+  __config
   PATHS ${LIBCXXABI_LIBCXX_INCLUDES}
 ${LIBCXXABI_LIBCXX_PATH}/include
 ${CMAKE_BINARY_DIR}/${LIBCXXABI_LIBCXX_INCLUDES}


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

[clang] f8990fe - [libclang] Install both libclang.a and libclang.so when LIBCLANG_BUILD_STATIC=ON

[Shoaib Meenai via cfe-commits]

Author: Han Zhu
Date: 2020-04-27T13:37:07-07:00
New Revision: f8990feb125a0f8d3f2892a589bc6fad3c430858

URL: 
https://github.com/llvm/llvm-project/commit/f8990feb125a0f8d3f2892a589bc6fad3c430858
DIFF: 
https://github.com/llvm/llvm-project/commit/f8990feb125a0f8d3f2892a589bc6fad3c430858.diff

LOG: [libclang] Install both libclang.a and libclang.so when 
LIBCLANG_BUILD_STATIC=ON

When LIBCLANG_BUILD_STATIC=ON and LLVM_ENABLE_PIC=ON, PIC version of
libclang.a and libclang.so are built as expected. However libclang.a is
not installed. Looking at the macro llvm_add_library(), when both SHARED
and STATIC are set, it renames the static library to ${name}_static and
then adds it to targets. But when add_clang_library() calls install, it
only checks if ${name} is in targets.

To work around this issue, loop through both ${name} and ${name}_static
and install both of them if they're in targets. This is still correct if
only shared or static library is built. In those cases, only ${name} is
added to targets and cmake install will generate the right install
script depending on the library's type.

Test Plan:
cmake with LIBCLANG_BUILD_STATIC=ON and then ninja install, from master
and this diff. Compare the result directory trees. Confirm that only
difference is the added libclang.a.

Differential Revision: https://reviews.llvm.org/D78534

Added: 


Modified: 
clang/cmake/modules/AddClang.cmake

Removed: 




diff  --git a/clang/cmake/modules/AddClang.cmake 
b/clang/cmake/modules/AddClang.cmake
index c1bb386de6f7..d68218eed073 100644
--- a/clang/cmake/modules/AddClang.cmake
+++ b/clang/cmake/modules/AddClang.cmake
@@ -99,38 +99,40 @@ macro(add_clang_library name)
   endif()
   llvm_add_library(${name} ${LIBTYPE} ${ARG_UNPARSED_ARGUMENTS} ${srcs})
 
-  if(TARGET ${name})
-target_link_libraries(${name} INTERFACE ${LLVM_COMMON_LIBS})
-
-if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY OR ARG_INSTALL_WITH_TOOLCHAIN)
-  set(export_to_clangtargets)
-  if(${name} IN_LIST LLVM_DISTRIBUTION_COMPONENTS OR
-  "clang-libraries" IN_LIST LLVM_DISTRIBUTION_COMPONENTS OR
-  NOT LLVM_DISTRIBUTION_COMPONENTS)
-set(export_to_clangtargets EXPORT ClangTargets)
-set_property(GLOBAL PROPERTY CLANG_HAS_EXPORTS True)
+  foreach(lib ${name} ${name}_static)
+if(TARGET ${lib})
+  target_link_libraries(${lib} INTERFACE ${LLVM_COMMON_LIBS})
+
+  if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY OR ARG_INSTALL_WITH_TOOLCHAIN)
+set(export_to_clangtargets)
+if(${lib} IN_LIST LLVM_DISTRIBUTION_COMPONENTS OR
+"clang-libraries" IN_LIST LLVM_DISTRIBUTION_COMPONENTS OR
+NOT LLVM_DISTRIBUTION_COMPONENTS)
+  set(export_to_clangtargets EXPORT ClangTargets)
+  set_property(GLOBAL PROPERTY CLANG_HAS_EXPORTS True)
+endif()
+
+install(TARGETS ${lib}
+  COMPONENT ${lib}
+  ${export_to_clangtargets}
+  LIBRARY DESTINATION lib${LLVM_LIBDIR_SUFFIX}
+  ARCHIVE DESTINATION lib${LLVM_LIBDIR_SUFFIX}
+  RUNTIME DESTINATION bin)
+
+if (NOT LLVM_ENABLE_IDE)
+  add_llvm_install_targets(install-${lib}
+   DEPENDS ${lib}
+   COMPONENT ${lib})
+endif()
+
+set_property(GLOBAL APPEND PROPERTY CLANG_LIBS ${lib})
   endif()
-
-  install(TARGETS ${name}
-COMPONENT ${name}
-${export_to_clangtargets}
-LIBRARY DESTINATION lib${LLVM_LIBDIR_SUFFIX}
-ARCHIVE DESTINATION lib${LLVM_LIBDIR_SUFFIX}
-RUNTIME DESTINATION bin)
-
-  if (NOT LLVM_ENABLE_IDE)
-add_llvm_install_targets(install-${name}
- DEPENDS ${name}
- COMPONENT ${name})
-  endif()
-
-  set_property(GLOBAL APPEND PROPERTY CLANG_LIBS ${name})
+  set_property(GLOBAL APPEND PROPERTY CLANG_EXPORTS ${lib})
+else()
+  # Add empty "phony" target
+  add_custom_target(${lib})
 endif()
-set_property(GLOBAL APPEND PROPERTY CLANG_EXPORTS ${name})
-  else()
-# Add empty "phony" target
-add_custom_target(${name})
-  endif()
+  endforeach()
 
   set_target_properties(${name} PROPERTIES FOLDER "Clang libraries")
   set_clang_windows_version_resource_properties(${name})



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

[clang] 0c9230d - Reland [libclang] Install both libclang.a and libclang.so when LIBCLANG_BUILD_STATIC=ON

[Shoaib Meenai via cfe-commits]

Author: Han Zhu
Date: 2020-05-06T19:33:58-07:00
New Revision: 0c9230dad1692bc3d8f1ce2dddae413a115f2532

URL: 
https://github.com/llvm/llvm-project/commit/0c9230dad1692bc3d8f1ce2dddae413a115f2532
DIFF: 
https://github.com/llvm/llvm-project/commit/0c9230dad1692bc3d8f1ce2dddae413a115f2532.diff

LOG: Reland [libclang] Install both libclang.a and libclang.so when 
LIBCLANG_BUILD_STATIC=ON

f8990feb125a enabled installing PIC version of both libclang.a and
libclang.so when LIBCLANG_BUILD_STATIC is ON. But it broke the no-PIC
build when LLVM_ENABLE_PIC=OFF with the following error:

```
CMake Error at
/b/s/w/ir/cache/builder/src/third_party/llvm/clang/tools/libclang/CMakeLists.txt:123
(target_compile_definitions):
target_compile_definitions called with non-compilable target type
```

This is because as the code loops through ${name} and ${name}_static, it
introduced a side effect, which is adding an empty libclang_static to
targets. Later target_compile_definitions is called on libclang_static.
That function requires that target must have been created by a command
such as add_executable() or add_library(), so it crashed.

The solution is to not naively loop through both libclang and
libclang_static, but only the ones that are actually added by
llvm_add_library(). Here's the library build type to library target name
mapping:

| SHARED only | libclang |
| STATIC only | libclang |
| SHARED and STATIC | libclang and libclang_static |

So only when SHARED and STATIC are both set should we loop through two
targets. Explicitly parse the STATIC argument and set the list
accordingly.

Reviewed By: smeenai

Differential Revision: https://reviews.llvm.org/D79059

Added: 


Modified: 
clang/cmake/modules/AddClang.cmake

Removed: 




diff  --git a/clang/cmake/modules/AddClang.cmake 
b/clang/cmake/modules/AddClang.cmake
index c1bb386de6f7..704278a0e93b 100644
--- a/clang/cmake/modules/AddClang.cmake
+++ b/clang/cmake/modules/AddClang.cmake
@@ -45,7 +45,7 @@ endmacro()
 
 macro(add_clang_library name)
   cmake_parse_arguments(ARG
-"SHARED;INSTALL_WITH_TOOLCHAIN"
+"SHARED;STATIC;INSTALL_WITH_TOOLCHAIN"
 ""
 "ADDITIONAL_HEADERS"
 ${ARGN})
@@ -81,7 +81,10 @@ macro(add_clang_library name)
   ${ARG_ADDITIONAL_HEADERS} # It may contain unparsed unknown args.
   )
   endif()
-  if(ARG_SHARED)
+
+  if(ARG_SHARED AND ARG_STATIC)
+set(LIBTYPE SHARED STATIC)
+  elseif(ARG_SHARED)
 set(LIBTYPE SHARED)
   else()
 # llvm_add_library ignores BUILD_SHARED_LIBS if STATIC is explicitly set,
@@ -99,38 +102,45 @@ macro(add_clang_library name)
   endif()
   llvm_add_library(${name} ${LIBTYPE} ${ARG_UNPARSED_ARGUMENTS} ${srcs})
 
-  if(TARGET ${name})
-target_link_libraries(${name} INTERFACE ${LLVM_COMMON_LIBS})
-
-if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY OR ARG_INSTALL_WITH_TOOLCHAIN)
-  set(export_to_clangtargets)
-  if(${name} IN_LIST LLVM_DISTRIBUTION_COMPONENTS OR
-  "clang-libraries" IN_LIST LLVM_DISTRIBUTION_COMPONENTS OR
-  NOT LLVM_DISTRIBUTION_COMPONENTS)
-set(export_to_clangtargets EXPORT ClangTargets)
-set_property(GLOBAL PROPERTY CLANG_HAS_EXPORTS True)
-  endif()
+  set(libs ${name})
+  if(ARG_SHARED AND ARG_STATIC)
+list(APPEND libs ${name}_static)
+  endif()
 
-  install(TARGETS ${name}
-COMPONENT ${name}
-${export_to_clangtargets}
-LIBRARY DESTINATION lib${LLVM_LIBDIR_SUFFIX}
-ARCHIVE DESTINATION lib${LLVM_LIBDIR_SUFFIX}
-RUNTIME DESTINATION bin)
-
-  if (NOT LLVM_ENABLE_IDE)
-add_llvm_install_targets(install-${name}
- DEPENDS ${name}
- COMPONENT ${name})
+  foreach(lib ${libs})
+if(TARGET ${lib})
+  target_link_libraries(${lib} INTERFACE ${LLVM_COMMON_LIBS})
+
+  if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY OR ARG_INSTALL_WITH_TOOLCHAIN)
+set(export_to_clangtargets)
+if(${lib} IN_LIST LLVM_DISTRIBUTION_COMPONENTS OR
+"clang-libraries" IN_LIST LLVM_DISTRIBUTION_COMPONENTS OR
+NOT LLVM_DISTRIBUTION_COMPONENTS)
+  set(export_to_clangtargets EXPORT ClangTargets)
+  set_property(GLOBAL PROPERTY CLANG_HAS_EXPORTS True)
+endif()
+
+install(TARGETS ${lib}
+  COMPONENT ${lib}
+  ${export_to_clangtargets}
+  LIBRARY DESTINATION lib${LLVM_LIBDIR_SUFFIX}
+  ARCHIVE DESTINATION lib${LLVM_LIBDIR_SUFFIX}
+  RUNTIME DESTINATION bin)
+
+if (NOT LLVM_ENABLE_IDE)
+  add_llvm_install_targets(install-${lib}
+   DEPENDS ${lib}
+   COMPONENT ${lib})
+endif()
+
+set_property(GLOBAL APPEND PROPERTY CLANG_LIBS ${lib})
   endif()
-
-  set_property(GLOBAL APPEND PROPERTY CLANG_LIBS ${name})
+  set_property(GLOBAL APPEND PROPERTY CLANG_EX

Re: [PATCH] D24679: [libc++] Fix extern template visibility for Windows

[Shoaib Meenai via cfe-commits]

smeenai added inline comments.


Comment at: include/__config:559
@@ -554,1 +558,3 @@
+# define _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS
+# define _LIBCPP_CLASS_TEMPLATE_INSTANTIATION_VIS
 #endif

compnerd wrote:
> Does it make sense for `_LIBCPP_CLASS_TEMPLATE_INSTANTIATION_VIS` to ever be 
> marked as `__declspec(dllimport)`?  The macro is applied on instantiations in 
> the implementation, not the header, so this shouldn't be visible to users.
It doesn't, which is why I always made it expand to either 
`__declspec(dllexport)` or empty.


https://reviews.llvm.org/D24679



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

[libcxx] r281925 - [libc++] Fix extern template visibility for Windows

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Mon Sep 19 13:29:07 2016
New Revision: 281925

URL: http://llvm.org/viewvc/llvm-project?rev=281925&view=rev
Log:
[libc++] Fix extern template visibility for Windows

On Windows, marking an `extern template class` declaration as exported
actually forces an instantiation, which is not the desired behavior.
Instead, the actual explicit instantiations need to be exported.

Differential Revision: https://reviews.llvm.org/D24679

Modified:
libcxx/trunk/docs/DesignDocs/VisibilityMacros.rst
libcxx/trunk/include/__config
libcxx/trunk/src/ios.cpp
libcxx/trunk/src/locale.cpp
libcxx/trunk/src/string.cpp

Modified: libcxx/trunk/docs/DesignDocs/VisibilityMacros.rst
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/docs/DesignDocs/VisibilityMacros.rst?rev=281925&r1=281924&r2=281925&view=diff
==
--- libcxx/trunk/docs/DesignDocs/VisibilityMacros.rst (original)
+++ libcxx/trunk/docs/DesignDocs/VisibilityMacros.rst Mon Sep 19 13:29:07 2016
@@ -71,6 +71,26 @@ Visibility Macros
   However since `_LIBCPP_TYPE_VIS_ONLY` is the same as `_LIBCPP_TYPE_VIS` the
   visibility is already correct. The macro has an empty definition with GCC.
 
+  **Windows Behavior**: `extern template` and `dllexport` are fundamentally
+  incompatible *on a template class* on Windows; the former suppresses
+  instantiation, while the latter forces it. Specifying both on the same
+  declaration makes the template class be instantiated, which is not desirable
+  inside headers. This macro therefore expands to `dllimport` outside of libc++
+  but nothing inside of it (rather than expanding to `dllexport`); instead, the
+  explicit instantiations themselves are marked as exported. Note that this
+  applies *only* to extern template *classes*. Extern template *functions* obey
+  regular import/export semantics, and applying `dllexport` directly to the
+  extern template declaration is the correct thing to do for them.
+
+**_LIBCPP_CLASS_TEMPLATE_INSTANTIATION_VIS**
+  Mark the member functions, typeinfo, and vtable of an explicit instantiation
+  of a class template as being exported by the libc++ library. This attribute
+  must be specified on all template class explicit instantiations.
+
+  It is only necessary to mark the explicit instantiation itself (as opposed to
+  the extern template declaration) as exported on Windows, as discussed above.
+  On all other platforms, this macro has an empty definition.
+
 **_LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY**
   Mark a member function of a class template as hidden and inline except when
   building the libc++ library where it marks the symbol as being exported by

Modified: libcxx/trunk/include/__config
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__config?rev=281925&r1=281924&r2=281925&view=diff
==
--- libcxx/trunk/include/__config (original)
+++ libcxx/trunk/include/__config Mon Sep 19 13:29:07 2016
@@ -551,15 +551,20 @@ namespace std {
 // only really useful for a DLL. _LIBCPP_DLL should be a compiler builtin 
define ideally...
 #if defined(_LIBCPP_DLL) && defined(cxx_EXPORTS)
 # define _LIBCPP_DLL_VIS __declspec(dllexport)
+# define _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS
+# define _LIBCPP_CLASS_TEMPLATE_INSTANTIATION_VIS _LIBCPP_DLL_VIS
 #elif defined(_LIBCPP_DLL)
 # define _LIBCPP_DLL_VIS __declspec(dllimport)
+# define _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS _LIBCPP_DLL_VIS
+# define _LIBCPP_CLASS_TEMPLATE_INSTANTIATION_VIS
 #else
 # define _LIBCPP_DLL_VIS
+# define _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS
+# define _LIBCPP_CLASS_TEMPLATE_INSTANTIATION_VIS
 #endif
 #define _LIBCPP_TYPE_VIS_LIBCPP_DLL_VIS
 #define _LIBCPP_FUNC_VIS_LIBCPP_DLL_VIS
 #define _LIBCPP_EXCEPTION_ABI   _LIBCPP_DLL_VIS
-#define _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS _LIBCPP_DLL_VIS
 #define _LIBCPP_HIDDEN
 #define _LIBCPP_TYPE_VIS_ONLY
 #define _LIBCPP_FUNC_VIS_ONLY
@@ -619,6 +624,10 @@ namespace std {
 #  endif
 #endif
 
+#ifndef _LIBCPP_CLASS_TEMPLATE_INSTANTIATION_VIS
+#  define _LIBCPP_CLASS_TEMPLATE_INSTANTIATION_VIS
+#endif
+
 #ifndef _LIBCPP_INLINE_VISIBILITY
 #define _LIBCPP_INLINE_VISIBILITY __attribute__ ((__visibility__("hidden"), 
__always_inline__))
 #endif

Modified: libcxx/trunk/src/ios.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/src/ios.cpp?rev=281925&r1=281924&r2=281925&view=diff
==
--- libcxx/trunk/src/ios.cpp (original)
+++ libcxx/trunk/src/ios.cpp Mon Sep 19 13:29:07 2016
@@ -25,19 +25,19 @@
 
 _LIBCPP_BEGIN_NAMESPACE_STD
 
-template class basic_ios;
-template class basic_ios;
+template class _LIBCPP_CLASS_TEMPLATE_INSTANTIATION_VIS basic_ios;
+template class _LIBCPP_CLASS_TEMPLATE_INSTANTIATION_VIS basic_ios;
 
-template class basic_streambuf;
-template class basic_streambuf;
+template class _LIBCPP_CLASS_T

Re: [PATCH] D24679: [libc++] Fix extern template visibility for Windows

[Shoaib Meenai via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL281925: [libc++] Fix extern template visibility for Windows 
(authored by smeenai).

Changed prior to commit:
  https://reviews.llvm.org/D24679?vs=71685&id=71861#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D24679

Files:
  libcxx/trunk/docs/DesignDocs/VisibilityMacros.rst
  libcxx/trunk/include/__config
  libcxx/trunk/src/ios.cpp
  libcxx/trunk/src/locale.cpp
  libcxx/trunk/src/string.cpp

Index: libcxx/trunk/docs/DesignDocs/VisibilityMacros.rst
===
--- libcxx/trunk/docs/DesignDocs/VisibilityMacros.rst
+++ libcxx/trunk/docs/DesignDocs/VisibilityMacros.rst
@@ -71,6 +71,26 @@
   However since `_LIBCPP_TYPE_VIS_ONLY` is the same as `_LIBCPP_TYPE_VIS` the
   visibility is already correct. The macro has an empty definition with GCC.
 
+  **Windows Behavior**: `extern template` and `dllexport` are fundamentally
+  incompatible *on a template class* on Windows; the former suppresses
+  instantiation, while the latter forces it. Specifying both on the same
+  declaration makes the template class be instantiated, which is not desirable
+  inside headers. This macro therefore expands to `dllimport` outside of libc++
+  but nothing inside of it (rather than expanding to `dllexport`); instead, the
+  explicit instantiations themselves are marked as exported. Note that this
+  applies *only* to extern template *classes*. Extern template *functions* obey
+  regular import/export semantics, and applying `dllexport` directly to the
+  extern template declaration is the correct thing to do for them.
+
+**_LIBCPP_CLASS_TEMPLATE_INSTANTIATION_VIS**
+  Mark the member functions, typeinfo, and vtable of an explicit instantiation
+  of a class template as being exported by the libc++ library. This attribute
+  must be specified on all template class explicit instantiations.
+
+  It is only necessary to mark the explicit instantiation itself (as opposed to
+  the extern template declaration) as exported on Windows, as discussed above.
+  On all other platforms, this macro has an empty definition.
+
 **_LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY**
   Mark a member function of a class template as hidden and inline except when
   building the libc++ library where it marks the symbol as being exported by
Index: libcxx/trunk/src/string.cpp
===
--- libcxx/trunk/src/string.cpp
+++ libcxx/trunk/src/string.cpp
@@ -20,10 +20,10 @@
 
 _LIBCPP_BEGIN_NAMESPACE_STD
 
-template class __basic_string_common;
+template class _LIBCPP_CLASS_TEMPLATE_INSTANTIATION_VIS __basic_string_common;
 
-template class basic_string;
-template class basic_string;
+template class _LIBCPP_CLASS_TEMPLATE_INSTANTIATION_VIS basic_string;
+template class _LIBCPP_CLASS_TEMPLATE_INSTANTIATION_VIS basic_string;
 
 template
 string
Index: libcxx/trunk/src/locale.cpp
===
--- libcxx/trunk/src/locale.cpp
+++ libcxx/trunk/src/locale.cpp
@@ -6031,66 +6031,66 @@
 #endif
 }
 
-template class collate;
-template class collate;
+template class _LIBCPP_CLASS_TEMPLATE_INSTANTIATION_VIS collate;
+template class _LIBCPP_CLASS_TEMPLATE_INSTANTIATION_VIS collate;
 
-template class num_get;
-template class num_get;
+template class _LIBCPP_CLASS_TEMPLATE_INSTANTIATION_VIS num_get;
+template class _LIBCPP_CLASS_TEMPLATE_INSTANTIATION_VIS num_get;
 
-template struct __num_get;
-template struct __num_get;
+template struct _LIBCPP_CLASS_TEMPLATE_INSTANTIATION_VIS __num_get;
+template struct _LIBCPP_CLASS_TEMPLATE_INSTANTIATION_VIS __num_get;
 
-template class num_put;
-template class num_put;
+template class _LIBCPP_CLASS_TEMPLATE_INSTANTIATION_VIS num_put;
+template class _LIBCPP_CLASS_TEMPLATE_INSTANTIATION_VIS num_put;
 
-template struct __num_put;
-template struct __num_put;
+template struct _LIBCPP_CLASS_TEMPLATE_INSTANTIATION_VIS __num_put;
+template struct _LIBCPP_CLASS_TEMPLATE_INSTANTIATION_VIS __num_put;
 
-template class time_get;
-template class time_get;
+template class _LIBCPP_CLASS_TEMPLATE_INSTANTIATION_VIS time_get;
+template class _LIBCPP_CLASS_TEMPLATE_INSTANTIATION_VIS time_get;
 
-template class time_get_byname;
-template class time_get_byname;
+template class _LIBCPP_CLASS_TEMPLATE_INSTANTIATION_VIS time_get_byname;
+template class _LIBCPP_CLASS_TEMPLATE_INSTANTIATION_VIS time_get_byname;
 
-template class time_put;
-template class time_put;
+template class _LIBCPP_CLASS_TEMPLATE_INSTANTIATION_VIS time_put;
+template class _LIBCPP_CLASS_TEMPLATE_INSTANTIATION_VIS time_put;
 
-template class time_put_byname;
-template class time_put_byname;
+template class _LIBCPP_CLASS_TEMPLATE_INSTANTIATION_VIS time_put_byname;
+template class _LIBCPP_CLASS_TEMPLATE_INSTANTIATION_VIS time_put_byname;
 
-template class moneypunct;
-template class moneypunct;
-template class moneypunct;
-template c

[PATCH] D24877: [libc++] Default to DLL semantics on Windows

[Shoaib Meenai via cfe-commits]

smeenai created this revision.
smeenai added reviewers: compnerd, EricWF, mclow.lists.
smeenai added a subscriber: cfe-commits.

On Windows builds, we currently require `_LIBCPP_DLL` to be specified in
order for dllexport/dllimport annotations to be generated. I believe
it's better to do the opposite, i.e. require a macro to be present in
order to *not* include the annotations, since building libc++ shared is
more common.

The problem with having the DLL annotations be opt-in is that any
project using the libc++ headers and linking against a libc++ DLL must
specify `_LIBCPP_DLL` in its build system, otherwise the libc++ headers
will not be annotated with dllimport. This lack of annotation will then
cause inefficient code generation, since the linker will generate import
thunks. No compile-time errors will be reported (except in the case of
data symbols, for which import thunks are not possible) about this
inefficient code generation.

In contrast, having the DLL annotations be opt-out means that any
project using the libc++ headers and linking against a static libc++
will fail to link with missing import table entries if the project
forgets to specify the macro to suppress DLL annotations. Link errors
seem far preferable to silent inefficient code generation.

https://reviews.llvm.org/D24877

Files:
  include/__config

Index: include/__config
===
--- include/__config
+++ include/__config
@@ -548,15 +548,16 @@
 
 
 #ifdef _WIN32
-// only really useful for a DLL. _LIBCPP_DLL should be a compiler builtin 
define ideally...
-#if defined(_LIBCPP_DLL) && defined(cxx_EXPORTS)
+#if !defined(_LIBCPP_STATIC_BUILD)
+#if defined(cxx_EXPORTS)
 # define _LIBCPP_DLL_VIS __declspec(dllexport)
 # define _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS
 # define _LIBCPP_CLASS_TEMPLATE_INSTANTIATION_VIS _LIBCPP_DLL_VIS
-#elif defined(_LIBCPP_DLL)
+#else
 # define _LIBCPP_DLL_VIS __declspec(dllimport)
 # define _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS _LIBCPP_DLL_VIS
 # define _LIBCPP_CLASS_TEMPLATE_INSTANTIATION_VIS
+#endif
 #else
 # define _LIBCPP_DLL_VIS
 # define _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS


Index: include/__config
===
--- include/__config
+++ include/__config
@@ -548,15 +548,16 @@
 
 
 #ifdef _WIN32
-// only really useful for a DLL. _LIBCPP_DLL should be a compiler builtin define ideally...
-#if defined(_LIBCPP_DLL) && defined(cxx_EXPORTS)
+#if !defined(_LIBCPP_STATIC_BUILD)
+#if defined(cxx_EXPORTS)
 # define _LIBCPP_DLL_VIS __declspec(dllexport)
 # define _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS
 # define _LIBCPP_CLASS_TEMPLATE_INSTANTIATION_VIS _LIBCPP_DLL_VIS
-#elif defined(_LIBCPP_DLL)
+#else
 # define _LIBCPP_DLL_VIS __declspec(dllimport)
 # define _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS _LIBCPP_DLL_VIS
 # define _LIBCPP_CLASS_TEMPLATE_INSTANTIATION_VIS
+#endif
 #else
 # define _LIBCPP_DLL_VIS
 # define _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D24879: [libc++] Remove math_win32.h

[Shoaib Meenai via cfe-commits]

smeenai created this revision.
smeenai added reviewers: compnerd, EricWF, mclow.lists.
smeenai added a subscriber: cfe-commits.

Visual Studio 2013 and onward have all the required functions in their
CRT headers, and we don't support older versions anymore.

https://reviews.llvm.org/D24879

Files:
  include/math.h
  include/support/win32/math_win32.h

Index: include/support/win32/math_win32.h
===
--- include/support/win32/math_win32.h
+++ /dev/null
@@ -1,117 +0,0 @@
-// -*- C++ -*-
-//===-- support/win32/math_win32.h ===//
-//
-// The LLVM Compiler Infrastructure
-//
-// This file is dual licensed under the MIT and the University of Illinois Open
-// Source Licenses. See LICENSE.TXT for details.
-//
-//===--===//
-
-#ifndef _LIBCPP_SUPPORT_WIN32_MATH_WIN32_H
-#define _LIBCPP_SUPPORT_WIN32_MATH_WIN32_H
-
-#if !defined(_LIBCPP_MSVCRT)
-#error "This header complements Microsoft's C Runtime library, and should not be included otherwise."
-#else
-
-#include 
-#include  // _FPCLASS_PN etc.
-#include 
-
-#if ((_VC_CRT_MAJOR_VERSION-0) < 12)
-// Necessary?
-typedef float float_t;
-typedef double double_t;
-
-_LIBCPP_ALWAYS_INLINE bool isfinite( double num )
-{
-return _finite(num) != 0;
-}
-_LIBCPP_ALWAYS_INLINE bool isinf( double num )
-{
-return !isfinite(num) && !_isnan(num);
-}
-_LIBCPP_ALWAYS_INLINE bool isnan( double num )
-{
-return _isnan(num) != 0;
-}
-_LIBCPP_ALWAYS_INLINE bool isnormal( double num )
-{
-int class_ = _fpclass(num);
-return class_ == _FPCLASS_NN || class_ == _FPCLASS_PN;
-}
-
-_LIBCPP_ALWAYS_INLINE bool isgreater( double x, double y )
-{
-if(_fpclass(x) == _FPCLASS_SNAN || _fpclass(y) == _FPCLASS_SNAN) return false;
-else return x > y;
-}
-
-_LIBCPP_ALWAYS_INLINE bool isgreaterequal( double x, double y )
-{
-if(_fpclass(x) == _FPCLASS_SNAN || _fpclass(y) == _FPCLASS_SNAN) return false;
-else return x >= y;
-}
-
-_LIBCPP_ALWAYS_INLINE bool isless( double x, double y )
-{
-if(_fpclass(x) == _FPCLASS_SNAN || _fpclass(y) == _FPCLASS_SNAN) return false;
-else return x < y;
-}
-
-_LIBCPP_ALWAYS_INLINE bool islessequal( double x, double y )
-{
-if(::_fpclass(x) == _FPCLASS_SNAN || ::_fpclass(y) == _FPCLASS_SNAN) return false;
-else return x <= y;
-}
-
-_LIBCPP_ALWAYS_INLINE bool islessgreater( double x, double y )
-{
-if(::_fpclass(x) == _FPCLASS_SNAN || ::_fpclass(y) == _FPCLASS_SNAN) return false;
-else return x < y || x > y;
-}
-
-_LIBCPP_ALWAYS_INLINE bool isunordered( double x, double y )
-{
-return isnan(x) || isnan(y);
-}
-_LIBCPP_ALWAYS_INLINE bool signbit( double num )
-{
-switch(_fpclass(num))
-{
-case _FPCLASS_SNAN:
-case _FPCLASS_QNAN:
-case _FPCLASS_NINF:
-case _FPCLASS_NN:
-case _FPCLASS_ND:
-case _FPCLASS_NZ:
-return true;
-case _FPCLASS_PZ:
-case _FPCLASS_PD:
-case _FPCLASS_PN:
-case _FPCLASS_PINF:
-return false;
-}
-return false;
-}
-_LIBCPP_ALWAYS_INLINE float copysignf( float x, float y )
-{
-return (signbit (x) != signbit (y) ? - x : x);
-}
-_LIBCPP_ALWAYS_INLINE double copysign( double x, double y )
-{
-return ::_copysign(x,y);
-}
-_LIBCPP_ALWAYS_INLINE double copysignl( long double x, long double y )
-{
-return ::_copysignl(x,y);
-}
-_LIBCPP_ALWAYS_INLINE int fpclassify( double num )
-{
-return _fpclass(num);
-}
-#endif
-#endif // _LIBCPP_MSVCRT
-
-#endif // _LIBCPP_SUPPORT_WIN32_MATH_WIN32_H
Index: include/math.h
===
--- include/math.h
+++ include/math.h
@@ -308,10 +308,6 @@
 
 #include 
 
-#ifdef _LIBCPP_MSVCRT
-#include "support/win32/math_win32.h"
-#endif
-
 // signbit
 
 #ifdef signbit
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D24879: [libc++] Remove math_win32.h

[Shoaib Meenai via cfe-commits]

smeenai added a comment.

It's worth noting that the entirety of the deleted file was guarded by a `#if 
((_VC_CRT_MAJOR_VERSION-0) < 12)` anyway (i.e. it would only be included on 
Visual Studio 2012 and below), so the code was already dead :)


https://reviews.llvm.org/D24879



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

[libcxx] r282328 - [libc++] Remove math_win32.h

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Sat Sep 24 01:27:28 2016
New Revision: 282328

URL: http://llvm.org/viewvc/llvm-project?rev=282328&view=rev
Log:
[libc++] Remove math_win32.h

Visual Studio 2013 and onward have all the required functions in their
CRT headers, and we don't support older versions anymore.

Differential Revision: https://reviews.llvm.org/D24879

Removed:
libcxx/trunk/include/support/win32/math_win32.h
Modified:
libcxx/trunk/include/math.h

Modified: libcxx/trunk/include/math.h
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/math.h?rev=282328&r1=282327&r2=282328&view=diff
==
--- libcxx/trunk/include/math.h (original)
+++ libcxx/trunk/include/math.h Sat Sep 24 01:27:28 2016
@@ -308,10 +308,6 @@ extern "C++" {
 
 #include 
 
-#ifdef _LIBCPP_MSVCRT
-#include "support/win32/math_win32.h"
-#endif
-
 // signbit
 
 #ifdef signbit

Removed: libcxx/trunk/include/support/win32/math_win32.h
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/support/win32/math_win32.h?rev=282327&view=auto
==
--- libcxx/trunk/include/support/win32/math_win32.h (original)
+++ libcxx/trunk/include/support/win32/math_win32.h (removed)
@@ -1,117 +0,0 @@
-// -*- C++ -*-
-//===-- support/win32/math_win32.h 
===//
-//
-// The LLVM Compiler Infrastructure
-//
-// This file is dual licensed under the MIT and the University of Illinois Open
-// Source Licenses. See LICENSE.TXT for details.
-//
-//===--===//
-
-#ifndef _LIBCPP_SUPPORT_WIN32_MATH_WIN32_H
-#define _LIBCPP_SUPPORT_WIN32_MATH_WIN32_H
-
-#if !defined(_LIBCPP_MSVCRT)
-#error "This header complements Microsoft's C Runtime library, and should not 
be included otherwise."
-#else
-
-#include 
-#include  // _FPCLASS_PN etc.
-#include 
-
-#if ((_VC_CRT_MAJOR_VERSION-0) < 12)
-// Necessary?
-typedef float float_t;
-typedef double double_t;
-
-_LIBCPP_ALWAYS_INLINE bool isfinite( double num )
-{
-return _finite(num) != 0;
-}
-_LIBCPP_ALWAYS_INLINE bool isinf( double num )
-{
-return !isfinite(num) && !_isnan(num);
-}
-_LIBCPP_ALWAYS_INLINE bool isnan( double num )
-{
-return _isnan(num) != 0;
-}
-_LIBCPP_ALWAYS_INLINE bool isnormal( double num )
-{
-int class_ = _fpclass(num);
-return class_ == _FPCLASS_NN || class_ == _FPCLASS_PN;
-}
-
-_LIBCPP_ALWAYS_INLINE bool isgreater( double x, double y )
-{
-if(_fpclass(x) == _FPCLASS_SNAN || _fpclass(y) == _FPCLASS_SNAN) return 
false;
-else return x > y;
-}
-
-_LIBCPP_ALWAYS_INLINE bool isgreaterequal( double x, double y )
-{
-if(_fpclass(x) == _FPCLASS_SNAN || _fpclass(y) == _FPCLASS_SNAN) return 
false;
-else return x >= y;
-}
-
-_LIBCPP_ALWAYS_INLINE bool isless( double x, double y )
-{
-if(_fpclass(x) == _FPCLASS_SNAN || _fpclass(y) == _FPCLASS_SNAN) return 
false;
-else return x < y;
-}
-
-_LIBCPP_ALWAYS_INLINE bool islessequal( double x, double y )
-{
-if(::_fpclass(x) == _FPCLASS_SNAN || ::_fpclass(y) == _FPCLASS_SNAN) 
return false;
-else return x <= y;
-}
-
-_LIBCPP_ALWAYS_INLINE bool islessgreater( double x, double y )
-{
-if(::_fpclass(x) == _FPCLASS_SNAN || ::_fpclass(y) == _FPCLASS_SNAN) 
return false;
-else return x < y || x > y;
-}
-
-_LIBCPP_ALWAYS_INLINE bool isunordered( double x, double y )
-{
-return isnan(x) || isnan(y);
-}
-_LIBCPP_ALWAYS_INLINE bool signbit( double num )
-{
-switch(_fpclass(num))
-{
-case _FPCLASS_SNAN:
-case _FPCLASS_QNAN:
-case _FPCLASS_NINF:
-case _FPCLASS_NN:
-case _FPCLASS_ND:
-case _FPCLASS_NZ:
-return true;
-case _FPCLASS_PZ:
-case _FPCLASS_PD:
-case _FPCLASS_PN:
-case _FPCLASS_PINF:
-return false;
-}
-return false;
-}
-_LIBCPP_ALWAYS_INLINE float copysignf( float x, float y )
-{
-return (signbit (x) != signbit (y) ? - x : x);
-}
-_LIBCPP_ALWAYS_INLINE double copysign( double x, double y )
-{
-return ::_copysign(x,y);
-}
-_LIBCPP_ALWAYS_INLINE double copysignl( long double x, long double y )
-{
-return ::_copysignl(x,y);
-}
-_LIBCPP_ALWAYS_INLINE int fpclassify( double num )
-{
-return _fpclass(num);
-}
-#endif
-#endif // _LIBCPP_MSVCRT
-
-#endif // _LIBCPP_SUPPORT_WIN32_MATH_WIN32_H


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

Re: [PATCH] D24879: [libc++] Remove math_win32.h

[Shoaib Meenai via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL282328: [libc++] Remove math_win32.h (authored by smeenai).

Changed prior to commit:
  https://reviews.llvm.org/D24879?vs=72330&id=72389#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D24879

Files:
  libcxx/trunk/include/math.h
  libcxx/trunk/include/support/win32/math_win32.h

Index: libcxx/trunk/include/math.h
===
--- libcxx/trunk/include/math.h
+++ libcxx/trunk/include/math.h
@@ -308,10 +308,6 @@
 
 #include 
 
-#ifdef _LIBCPP_MSVCRT
-#include "support/win32/math_win32.h"
-#endif
-
 // signbit
 
 #ifdef signbit
Index: libcxx/trunk/include/support/win32/math_win32.h
===
--- libcxx/trunk/include/support/win32/math_win32.h
+++ libcxx/trunk/include/support/win32/math_win32.h
@@ -1,117 +0,0 @@
-// -*- C++ -*-
-//===-- support/win32/math_win32.h ===//
-//
-// The LLVM Compiler Infrastructure
-//
-// This file is dual licensed under the MIT and the University of Illinois Open
-// Source Licenses. See LICENSE.TXT for details.
-//
-//===--===//
-
-#ifndef _LIBCPP_SUPPORT_WIN32_MATH_WIN32_H
-#define _LIBCPP_SUPPORT_WIN32_MATH_WIN32_H
-
-#if !defined(_LIBCPP_MSVCRT)
-#error "This header complements Microsoft's C Runtime library, and should not be included otherwise."
-#else
-
-#include 
-#include  // _FPCLASS_PN etc.
-#include 
-
-#if ((_VC_CRT_MAJOR_VERSION-0) < 12)
-// Necessary?
-typedef float float_t;
-typedef double double_t;
-
-_LIBCPP_ALWAYS_INLINE bool isfinite( double num )
-{
-return _finite(num) != 0;
-}
-_LIBCPP_ALWAYS_INLINE bool isinf( double num )
-{
-return !isfinite(num) && !_isnan(num);
-}
-_LIBCPP_ALWAYS_INLINE bool isnan( double num )
-{
-return _isnan(num) != 0;
-}
-_LIBCPP_ALWAYS_INLINE bool isnormal( double num )
-{
-int class_ = _fpclass(num);
-return class_ == _FPCLASS_NN || class_ == _FPCLASS_PN;
-}
-
-_LIBCPP_ALWAYS_INLINE bool isgreater( double x, double y )
-{
-if(_fpclass(x) == _FPCLASS_SNAN || _fpclass(y) == _FPCLASS_SNAN) return false;
-else return x > y;
-}
-
-_LIBCPP_ALWAYS_INLINE bool isgreaterequal( double x, double y )
-{
-if(_fpclass(x) == _FPCLASS_SNAN || _fpclass(y) == _FPCLASS_SNAN) return false;
-else return x >= y;
-}
-
-_LIBCPP_ALWAYS_INLINE bool isless( double x, double y )
-{
-if(_fpclass(x) == _FPCLASS_SNAN || _fpclass(y) == _FPCLASS_SNAN) return false;
-else return x < y;
-}
-
-_LIBCPP_ALWAYS_INLINE bool islessequal( double x, double y )
-{
-if(::_fpclass(x) == _FPCLASS_SNAN || ::_fpclass(y) == _FPCLASS_SNAN) return false;
-else return x <= y;
-}
-
-_LIBCPP_ALWAYS_INLINE bool islessgreater( double x, double y )
-{
-if(::_fpclass(x) == _FPCLASS_SNAN || ::_fpclass(y) == _FPCLASS_SNAN) return false;
-else return x < y || x > y;
-}
-
-_LIBCPP_ALWAYS_INLINE bool isunordered( double x, double y )
-{
-return isnan(x) || isnan(y);
-}
-_LIBCPP_ALWAYS_INLINE bool signbit( double num )
-{
-switch(_fpclass(num))
-{
-case _FPCLASS_SNAN:
-case _FPCLASS_QNAN:
-case _FPCLASS_NINF:
-case _FPCLASS_NN:
-case _FPCLASS_ND:
-case _FPCLASS_NZ:
-return true;
-case _FPCLASS_PZ:
-case _FPCLASS_PD:
-case _FPCLASS_PN:
-case _FPCLASS_PINF:
-return false;
-}
-return false;
-}
-_LIBCPP_ALWAYS_INLINE float copysignf( float x, float y )
-{
-return (signbit (x) != signbit (y) ? - x : x);
-}
-_LIBCPP_ALWAYS_INLINE double copysign( double x, double y )
-{
-return ::_copysign(x,y);
-}
-_LIBCPP_ALWAYS_INLINE double copysignl( long double x, long double y )
-{
-return ::_copysignl(x,y);
-}
-_LIBCPP_ALWAYS_INLINE int fpclassify( double num )
-{
-return _fpclass(num);
-}
-#endif
-#endif // _LIBCPP_MSVCRT
-
-#endif // _LIBCPP_SUPPORT_WIN32_MATH_WIN32_H
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D24877: [libc++] Default to DLL semantics on Windows

[Shoaib Meenai via cfe-commits]

smeenai abandoned this revision.
smeenai added a comment.

Your patch looks good to me and is a nicer way of accomplishing this. Thanks 
for taking care of it!


https://reviews.llvm.org/D24877



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

[PATCH] D24945: [libc++abi] Default to DLL annotations on Windows

[Shoaib Meenai via cfe-commits]

smeenai created this revision.
smeenai added reviewers: compnerd, EricWF, mclow.lists.
smeenai added a subscriber: cfe-commits.
Herald added subscribers: mgorny, beanz.

`__declspec(dllexport)` and `__declspec(dllimport)` should only be used
when building libc++abi as a DLL, but that's the more common use case,
so default to adding the annotations and add an option to opt out.

Similar to r282449, which made the corresponding change for libc++.

https://reviews.llvm.org/D24945

Files:
  CMakeLists.txt
  include/__cxxabi_config.h

Index: include/__cxxabi_config.h
===
--- include/__cxxabi_config.h
+++ include/__cxxabi_config.h
@@ -21,8 +21,13 @@
 #define __has_attribute(_attribute_) 0
 #endif
 
-#if defined(_LIBCXXABI_DLL)
- #if defined(cxxabi_EXPORTS)
+#if defined(_WIN32)
+ #if defined(_LIBCXXABI_DISABLE_DLL_IMPORT_EXPORT)
+  #define _LIBCXXABI_HIDDEN
+  #define _LIBCXXABI_DATA_VIS
+  #define _LIBCXXABI_FUNC_VIS
+  #define _LIBCXXABI_TYPE_VIS
+ #elif defined(_LIBCXXABI_BUILDING_LIBRARY)
   #define _LIBCXXABI_HIDDEN
   #define _LIBCXXABI_DATA_VIS __declspec(dllexport)
   #define _LIBCXXABI_FUNC_VIS __declspec(dllexport)
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -249,6 +249,10 @@
   list(APPEND LIBCXXABI_LINK_FLAGS "-rtlib=compiler-rt")
 endif()
 
+# Let the library headers know they are currently being used to build the
+# library.
+add_definitions(-D_LIBCXXABI_BUILDING_LIBRARY)
+
 append_if(LIBCXXABI_COMPILE_FLAGS LIBCXXABI_HAS_WERROR_FLAG 
-Werror=return-type)
 
 # Get warning flags
@@ -333,7 +337,6 @@
   add_definitions(-D_LIBCPP_HAS_THREAD_API_PTHREAD)
 endif()
 
-# This is the _ONLY_ place where add_definitions is called.
 if (MSVC)
   add_definitions(-D_CRT_SECURE_NO_WARNINGS)
 endif()


Index: include/__cxxabi_config.h
===
--- include/__cxxabi_config.h
+++ include/__cxxabi_config.h
@@ -21,8 +21,13 @@
 #define __has_attribute(_attribute_) 0
 #endif
 
-#if defined(_LIBCXXABI_DLL)
- #if defined(cxxabi_EXPORTS)
+#if defined(_WIN32)
+ #if defined(_LIBCXXABI_DISABLE_DLL_IMPORT_EXPORT)
+  #define _LIBCXXABI_HIDDEN
+  #define _LIBCXXABI_DATA_VIS
+  #define _LIBCXXABI_FUNC_VIS
+  #define _LIBCXXABI_TYPE_VIS
+ #elif defined(_LIBCXXABI_BUILDING_LIBRARY)
   #define _LIBCXXABI_HIDDEN
   #define _LIBCXXABI_DATA_VIS __declspec(dllexport)
   #define _LIBCXXABI_FUNC_VIS __declspec(dllexport)
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -249,6 +249,10 @@
   list(APPEND LIBCXXABI_LINK_FLAGS "-rtlib=compiler-rt")
 endif()
 
+# Let the library headers know they are currently being used to build the
+# library.
+add_definitions(-D_LIBCXXABI_BUILDING_LIBRARY)
+
 append_if(LIBCXXABI_COMPILE_FLAGS LIBCXXABI_HAS_WERROR_FLAG -Werror=return-type)
 
 # Get warning flags
@@ -333,7 +337,6 @@
   add_definitions(-D_LIBCPP_HAS_THREAD_API_PTHREAD)
 endif()
 
-# This is the _ONLY_ place where add_definitions is called.
 if (MSVC)
   add_definitions(-D_CRT_SECURE_NO_WARNINGS)
 endif()
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D24945: [libc++abi] Default to DLL annotations on Windows

[Shoaib Meenai via cfe-commits]

smeenai updated this revision to Diff 72598.
smeenai added a comment.

Addressing @EricWF's comment


https://reviews.llvm.org/D24945

Files:
  CMakeLists.txt
  include/__cxxabi_config.h

Index: include/__cxxabi_config.h
===
--- include/__cxxabi_config.h
+++ include/__cxxabi_config.h
@@ -21,8 +21,13 @@
 #define __has_attribute(_attribute_) 0
 #endif
 
-#if defined(_LIBCXXABI_DLL)
- #if defined(cxxabi_EXPORTS)
+#if defined(_WIN32)
+ #if defined(_LIBCXXABI_DISABLE_DLL_IMPORT_EXPORT)
+  #define _LIBCXXABI_HIDDEN
+  #define _LIBCXXABI_DATA_VIS
+  #define _LIBCXXABI_FUNC_VIS
+  #define _LIBCXXABI_TYPE_VIS
+ #elif defined(_LIBCXXABI_BUILDING_LIBRARY)
   #define _LIBCXXABI_HIDDEN
   #define _LIBCXXABI_DATA_VIS __declspec(dllexport)
   #define _LIBCXXABI_FUNC_VIS __declspec(dllexport)
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -249,6 +249,15 @@
   list(APPEND LIBCXXABI_LINK_FLAGS "-rtlib=compiler-rt")
 endif()
 
+# Let the library headers know they are currently being used to build the
+# library.
+add_definitions(-D_LIBCXXABI_BUILDING_LIBRARY)
+
+# Disable DLL annotations on Windows for static builds.
+if (WIN32 AND LIBCXXABI_ENABLE_STATIC AND NOT LIBCXXABI_ENABLE_SHARED)
+  add_definitions(-D_LIBCXXABI_DISABLE_DLL_IMPORT_EXPORT)
+endif()
+
 append_if(LIBCXXABI_COMPILE_FLAGS LIBCXXABI_HAS_WERROR_FLAG 
-Werror=return-type)
 
 # Get warning flags
@@ -333,7 +342,6 @@
   add_definitions(-D_LIBCPP_HAS_THREAD_API_PTHREAD)
 endif()
 
-# This is the _ONLY_ place where add_definitions is called.
 if (MSVC)
   add_definitions(-D_CRT_SECURE_NO_WARNINGS)
 endif()


Index: include/__cxxabi_config.h
===
--- include/__cxxabi_config.h
+++ include/__cxxabi_config.h
@@ -21,8 +21,13 @@
 #define __has_attribute(_attribute_) 0
 #endif
 
-#if defined(_LIBCXXABI_DLL)
- #if defined(cxxabi_EXPORTS)
+#if defined(_WIN32)
+ #if defined(_LIBCXXABI_DISABLE_DLL_IMPORT_EXPORT)
+  #define _LIBCXXABI_HIDDEN
+  #define _LIBCXXABI_DATA_VIS
+  #define _LIBCXXABI_FUNC_VIS
+  #define _LIBCXXABI_TYPE_VIS
+ #elif defined(_LIBCXXABI_BUILDING_LIBRARY)
   #define _LIBCXXABI_HIDDEN
   #define _LIBCXXABI_DATA_VIS __declspec(dllexport)
   #define _LIBCXXABI_FUNC_VIS __declspec(dllexport)
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -249,6 +249,15 @@
   list(APPEND LIBCXXABI_LINK_FLAGS "-rtlib=compiler-rt")
 endif()
 
+# Let the library headers know they are currently being used to build the
+# library.
+add_definitions(-D_LIBCXXABI_BUILDING_LIBRARY)
+
+# Disable DLL annotations on Windows for static builds.
+if (WIN32 AND LIBCXXABI_ENABLE_STATIC AND NOT LIBCXXABI_ENABLE_SHARED)
+  add_definitions(-D_LIBCXXABI_DISABLE_DLL_IMPORT_EXPORT)
+endif()
+
 append_if(LIBCXXABI_COMPILE_FLAGS LIBCXXABI_HAS_WERROR_FLAG -Werror=return-type)
 
 # Get warning flags
@@ -333,7 +342,6 @@
   add_definitions(-D_LIBCPP_HAS_THREAD_API_PTHREAD)
 endif()
 
-# This is the _ONLY_ place where add_definitions is called.
 if (MSVC)
   add_definitions(-D_CRT_SECURE_NO_WARNINGS)
 endif()
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D24945: [libc++abi] Default to DLL annotations on Windows

[Shoaib Meenai via cfe-commits]

smeenai marked an inline comment as done.
smeenai added a comment.

https://reviews.llvm.org/D24945



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

[libcxxabi] r282470 - [libc++abi] Default to DLL annotations on Windows

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Mon Sep 26 22:44:09 2016
New Revision: 282470

URL: http://llvm.org/viewvc/llvm-project?rev=282470&view=rev
Log:
[libc++abi] Default to DLL annotations on Windows

`__declspec(dllexport)` and `__declspec(dllimport)` should only be used
when building libc++abi as a DLL, but that's the more common use case,
so default to adding the annotations and add an option to opt out.

Similar to r282449, which made the corresponding change for libc++.

Differential Revision: https://reviews.llvm.org/D24945

Modified:
libcxxabi/trunk/CMakeLists.txt
libcxxabi/trunk/include/__cxxabi_config.h

Modified: libcxxabi/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxxabi/trunk/CMakeLists.txt?rev=282470&r1=282469&r2=282470&view=diff
==
--- libcxxabi/trunk/CMakeLists.txt (original)
+++ libcxxabi/trunk/CMakeLists.txt Mon Sep 26 22:44:09 2016
@@ -249,6 +249,15 @@ if (LIBCXXABI_USE_COMPILER_RT)
   list(APPEND LIBCXXABI_LINK_FLAGS "-rtlib=compiler-rt")
 endif()
 
+# Let the library headers know they are currently being used to build the
+# library.
+add_definitions(-D_LIBCXXABI_BUILDING_LIBRARY)
+
+# Disable DLL annotations on Windows for static builds.
+if (WIN32 AND LIBCXXABI_ENABLE_STATIC AND NOT LIBCXXABI_ENABLE_SHARED)
+  add_definitions(-D_LIBCXXABI_DISABLE_DLL_IMPORT_EXPORT)
+endif()
+
 append_if(LIBCXXABI_COMPILE_FLAGS LIBCXXABI_HAS_WERROR_FLAG 
-Werror=return-type)
 
 # Get warning flags
@@ -333,7 +342,6 @@ if (LIBCXXABI_HAS_PTHREAD_API)
   add_definitions(-D_LIBCPP_HAS_THREAD_API_PTHREAD)
 endif()
 
-# This is the _ONLY_ place where add_definitions is called.
 if (MSVC)
   add_definitions(-D_CRT_SECURE_NO_WARNINGS)
 endif()

Modified: libcxxabi/trunk/include/__cxxabi_config.h
URL: 
http://llvm.org/viewvc/llvm-project/libcxxabi/trunk/include/__cxxabi_config.h?rev=282470&r1=282469&r2=282470&view=diff
==
--- libcxxabi/trunk/include/__cxxabi_config.h (original)
+++ libcxxabi/trunk/include/__cxxabi_config.h Mon Sep 26 22:44:09 2016
@@ -21,8 +21,13 @@
 #define __has_attribute(_attribute_) 0
 #endif
 
-#if defined(_LIBCXXABI_DLL)
- #if defined(cxxabi_EXPORTS)
+#if defined(_WIN32)
+ #if defined(_LIBCXXABI_DISABLE_DLL_IMPORT_EXPORT)
+  #define _LIBCXXABI_HIDDEN
+  #define _LIBCXXABI_DATA_VIS
+  #define _LIBCXXABI_FUNC_VIS
+  #define _LIBCXXABI_TYPE_VIS
+ #elif defined(_LIBCXXABI_BUILDING_LIBRARY)
   #define _LIBCXXABI_HIDDEN
   #define _LIBCXXABI_DATA_VIS __declspec(dllexport)
   #define _LIBCXXABI_FUNC_VIS __declspec(dllexport)


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

Re: [PATCH] D24945: [libc++abi] Default to DLL annotations on Windows

[Shoaib Meenai via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL282470: [libc++abi] Default to DLL annotations on Windows 
(authored by smeenai).

Changed prior to commit:
  https://reviews.llvm.org/D24945?vs=72598&id=72599#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D24945

Files:
  libcxxabi/trunk/CMakeLists.txt
  libcxxabi/trunk/include/__cxxabi_config.h

Index: libcxxabi/trunk/include/__cxxabi_config.h
===
--- libcxxabi/trunk/include/__cxxabi_config.h
+++ libcxxabi/trunk/include/__cxxabi_config.h
@@ -21,8 +21,13 @@
 #define __has_attribute(_attribute_) 0
 #endif
 
-#if defined(_LIBCXXABI_DLL)
- #if defined(cxxabi_EXPORTS)
+#if defined(_WIN32)
+ #if defined(_LIBCXXABI_DISABLE_DLL_IMPORT_EXPORT)
+  #define _LIBCXXABI_HIDDEN
+  #define _LIBCXXABI_DATA_VIS
+  #define _LIBCXXABI_FUNC_VIS
+  #define _LIBCXXABI_TYPE_VIS
+ #elif defined(_LIBCXXABI_BUILDING_LIBRARY)
   #define _LIBCXXABI_HIDDEN
   #define _LIBCXXABI_DATA_VIS __declspec(dllexport)
   #define _LIBCXXABI_FUNC_VIS __declspec(dllexport)
Index: libcxxabi/trunk/CMakeLists.txt
===
--- libcxxabi/trunk/CMakeLists.txt
+++ libcxxabi/trunk/CMakeLists.txt
@@ -249,6 +249,15 @@
   list(APPEND LIBCXXABI_LINK_FLAGS "-rtlib=compiler-rt")
 endif()
 
+# Let the library headers know they are currently being used to build the
+# library.
+add_definitions(-D_LIBCXXABI_BUILDING_LIBRARY)
+
+# Disable DLL annotations on Windows for static builds.
+if (WIN32 AND LIBCXXABI_ENABLE_STATIC AND NOT LIBCXXABI_ENABLE_SHARED)
+  add_definitions(-D_LIBCXXABI_DISABLE_DLL_IMPORT_EXPORT)
+endif()
+
 append_if(LIBCXXABI_COMPILE_FLAGS LIBCXXABI_HAS_WERROR_FLAG 
-Werror=return-type)
 
 # Get warning flags
@@ -333,7 +342,6 @@
   add_definitions(-D_LIBCPP_HAS_THREAD_API_PTHREAD)
 endif()
 
-# This is the _ONLY_ place where add_definitions is called.
 if (MSVC)
   add_definitions(-D_CRT_SECURE_NO_WARNINGS)
 endif()


Index: libcxxabi/trunk/include/__cxxabi_config.h
===
--- libcxxabi/trunk/include/__cxxabi_config.h
+++ libcxxabi/trunk/include/__cxxabi_config.h
@@ -21,8 +21,13 @@
 #define __has_attribute(_attribute_) 0
 #endif
 
-#if defined(_LIBCXXABI_DLL)
- #if defined(cxxabi_EXPORTS)
+#if defined(_WIN32)
+ #if defined(_LIBCXXABI_DISABLE_DLL_IMPORT_EXPORT)
+  #define _LIBCXXABI_HIDDEN
+  #define _LIBCXXABI_DATA_VIS
+  #define _LIBCXXABI_FUNC_VIS
+  #define _LIBCXXABI_TYPE_VIS
+ #elif defined(_LIBCXXABI_BUILDING_LIBRARY)
   #define _LIBCXXABI_HIDDEN
   #define _LIBCXXABI_DATA_VIS __declspec(dllexport)
   #define _LIBCXXABI_FUNC_VIS __declspec(dllexport)
Index: libcxxabi/trunk/CMakeLists.txt
===
--- libcxxabi/trunk/CMakeLists.txt
+++ libcxxabi/trunk/CMakeLists.txt
@@ -249,6 +249,15 @@
   list(APPEND LIBCXXABI_LINK_FLAGS "-rtlib=compiler-rt")
 endif()
 
+# Let the library headers know they are currently being used to build the
+# library.
+add_definitions(-D_LIBCXXABI_BUILDING_LIBRARY)
+
+# Disable DLL annotations on Windows for static builds.
+if (WIN32 AND LIBCXXABI_ENABLE_STATIC AND NOT LIBCXXABI_ENABLE_SHARED)
+  add_definitions(-D_LIBCXXABI_DISABLE_DLL_IMPORT_EXPORT)
+endif()
+
 append_if(LIBCXXABI_COMPILE_FLAGS LIBCXXABI_HAS_WERROR_FLAG -Werror=return-type)
 
 # Get warning flags
@@ -333,7 +342,6 @@
   add_definitions(-D_LIBCPP_HAS_THREAD_API_PTHREAD)
 endif()
 
-# This is the _ONLY_ place where add_definitions is called.
 if (MSVC)
   add_definitions(-D_CRT_SECURE_NO_WARNINGS)
 endif()
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D25042: [libc++] Clarify _LIBCPP_NEW_DELETE_VIS for Windows

[Shoaib Meenai via cfe-commits]

smeenai created this revision.
smeenai added reviewers: compnerd, EricWF, mclow.lists.
smeenai added a subscriber: cfe-commits.

Replace a stale reference to cxx_EXPORTS with _LIBCPP_BUILDING_LIBRARY,
and clarify why the operator new and delete family of functions are
marked dllexport when building but *not* dllimport when including the
header externally.

The new code is identical to the intent of the old code (and would be
functionally equivalent were cxx_EXPORTS still defined when building
libc++). The overall behavior is not ideal, since Microsoft's operator
new and delete functions will get called instead of libc++'s, but I
think consistently calling msvcrt's functions is better than either
calling msvcrt's or libc++'s functions depending on header inclusion.

https://reviews.llvm.org/D25042

Files:
  include/new

Index: include/new
===
--- include/new
+++ include/new
@@ -125,8 +125,18 @@
 
 }  // std
 
-#if defined(_WIN32) && !defined(cxx_EXPORTS)
-# define _LIBCPP_NEW_DELETE_VIS _LIBCPP_FUNC_VIS_ONLY
+/*
+ * NOTE: When using the Microsoft CRT, the operator new and delete
+ * family of functions are defined statically in msvcrt.lib. Marking
+ * them as dllimport in this header is therefore undesirable: if we were
+ * to mark them dllimport and then link against libc++, source files
+ * which included  would end up linking against libc++'s new and
+ * delete, while source files which did not include  would end up
+ * still linking against msvcrt's new, which would be a confusing and
+ * potentially error-prone inconsistency.
+ */
+#if defined(_LIBCPP_MSVCRT) && !defined(_LIBCPP_BUILDING_LIBRARY)
+# define _LIBCPP_NEW_DELETE_VIS
 #else
 # define _LIBCPP_NEW_DELETE_VIS _LIBCPP_FUNC_VIS
 #endif


Index: include/new
===
--- include/new
+++ include/new
@@ -125,8 +125,18 @@
 
 }  // std
 
-#if defined(_WIN32) && !defined(cxx_EXPORTS)
-# define _LIBCPP_NEW_DELETE_VIS _LIBCPP_FUNC_VIS_ONLY
+/*
+ * NOTE: When using the Microsoft CRT, the operator new and delete
+ * family of functions are defined statically in msvcrt.lib. Marking
+ * them as dllimport in this header is therefore undesirable: if we were
+ * to mark them dllimport and then link against libc++, source files
+ * which included  would end up linking against libc++'s new and
+ * delete, while source files which did not include  would end up
+ * still linking against msvcrt's new, which would be a confusing and
+ * potentially error-prone inconsistency.
+ */
+#if defined(_LIBCPP_MSVCRT) && !defined(_LIBCPP_BUILDING_LIBRARY)
+# define _LIBCPP_NEW_DELETE_VIS
 #else
 # define _LIBCPP_NEW_DELETE_VIS _LIBCPP_FUNC_VIS
 #endif
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D25042: [libc++] Clarify _LIBCPP_NEW_DELETE_VIS for Windows

[Shoaib Meenai via cfe-commits]

smeenai updated this revision to Diff 72891.
smeenai added a comment.

Clarifying code comment


https://reviews.llvm.org/D25042

Files:
  include/new

Index: include/new
===
--- include/new
+++ include/new
@@ -125,8 +125,18 @@
 
 }  // std
 
-#if defined(_WIN32) && !defined(cxx_EXPORTS)
-# define _LIBCPP_NEW_DELETE_VIS _LIBCPP_FUNC_VIS_ONLY
+/*
+ * NOTE: When using the Microsoft CRT, the operator new and delete
+ * family of functions are defined statically in msvcrt.lib. Marking
+ * them as dllimport in this header is therefore undesirable: if we were
+ * to mark them dllimport and then link against libc++, source files
+ * which included  would end up linking against libc++'s new and
+ * delete, while source files which did not include  would end up
+ * still linking against msvcrt's new and delete, which would be a
+ * confusing and potentially error-prone inconsistency.
+ */
+#if defined(_LIBCPP_MSVCRT) && !defined(_LIBCPP_BUILDING_LIBRARY)
+# define _LIBCPP_NEW_DELETE_VIS
 #else
 # define _LIBCPP_NEW_DELETE_VIS _LIBCPP_FUNC_VIS
 #endif


Index: include/new
===
--- include/new
+++ include/new
@@ -125,8 +125,18 @@
 
 }  // std
 
-#if defined(_WIN32) && !defined(cxx_EXPORTS)
-# define _LIBCPP_NEW_DELETE_VIS _LIBCPP_FUNC_VIS_ONLY
+/*
+ * NOTE: When using the Microsoft CRT, the operator new and delete
+ * family of functions are defined statically in msvcrt.lib. Marking
+ * them as dllimport in this header is therefore undesirable: if we were
+ * to mark them dllimport and then link against libc++, source files
+ * which included  would end up linking against libc++'s new and
+ * delete, while source files which did not include  would end up
+ * still linking against msvcrt's new and delete, which would be a
+ * confusing and potentially error-prone inconsistency.
+ */
+#if defined(_LIBCPP_MSVCRT) && !defined(_LIBCPP_BUILDING_LIBRARY)
+# define _LIBCPP_NEW_DELETE_VIS
 #else
 # define _LIBCPP_NEW_DELETE_VIS _LIBCPP_FUNC_VIS
 #endif
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D25042: [libc++] Clarify _LIBCPP_NEW_DELETE_VIS for Windows

[Shoaib Meenai via cfe-commits]

smeenai updated this revision to Diff 72911.
smeenai added a comment.

Moving documentation to documentation file, per @EricWF's comment


https://reviews.llvm.org/D25042

Files:
  docs/DesignDocs/VisibilityMacros.rst
  include/new

Index: include/new
===
--- include/new
+++ include/new
@@ -125,8 +125,8 @@
 
 }  // std
 
-#if defined(_WIN32) && !defined(cxx_EXPORTS)
-# define _LIBCPP_NEW_DELETE_VIS _LIBCPP_FUNC_VIS_ONLY
+#if defined(_LIBCPP_MSVCRT) && !defined(_LIBCPP_BUILDING_LIBRARY)
+# define _LIBCPP_NEW_DELETE_VIS
 #else
 # define _LIBCPP_NEW_DELETE_VIS _LIBCPP_FUNC_VIS
 #endif
Index: docs/DesignDocs/VisibilityMacros.rst
===
--- docs/DesignDocs/VisibilityMacros.rst
+++ docs/DesignDocs/VisibilityMacros.rst
@@ -108,6 +108,19 @@
   versioning namespace. This allows throwing and catching some exception types
   between libc++ and libstdc++.
 
+**_LIBCPP_NEW_DELETE_VIS**
+  Mark a symbol as being exported by the libc++ library. This macro must be
+  applied to all `operator new` and `operator delete` overloads.
+
+  **Windows Behavior**: When using the Microsoft CRT, all the `operator new` 
and
+  `operator delete` overloads are defined statically in `msvcrt.lib`. Marking
+  them as `dllimport` in the libc++ `` header is therefore undesirable: if
+  we were to mark them as `dllimport` and then link against libc++, source 
files
+  which included `` would end up linking against libc++'s `operator new`
+  and `operator delete`, while source files which did not include `` would
+  end up linking against msvcrt's `operator new` and `operator delete`, which
+  would be a confusing and potentially error-prone inconsistency.
+
 Links
 =
 


Index: include/new
===
--- include/new
+++ include/new
@@ -125,8 +125,8 @@
 
 }  // std
 
-#if defined(_WIN32) && !defined(cxx_EXPORTS)
-# define _LIBCPP_NEW_DELETE_VIS _LIBCPP_FUNC_VIS_ONLY
+#if defined(_LIBCPP_MSVCRT) && !defined(_LIBCPP_BUILDING_LIBRARY)
+# define _LIBCPP_NEW_DELETE_VIS
 #else
 # define _LIBCPP_NEW_DELETE_VIS _LIBCPP_FUNC_VIS
 #endif
Index: docs/DesignDocs/VisibilityMacros.rst
===
--- docs/DesignDocs/VisibilityMacros.rst
+++ docs/DesignDocs/VisibilityMacros.rst
@@ -108,6 +108,19 @@
   versioning namespace. This allows throwing and catching some exception types
   between libc++ and libstdc++.
 
+**_LIBCPP_NEW_DELETE_VIS**
+  Mark a symbol as being exported by the libc++ library. This macro must be
+  applied to all `operator new` and `operator delete` overloads.
+
+  **Windows Behavior**: When using the Microsoft CRT, all the `operator new` and
+  `operator delete` overloads are defined statically in `msvcrt.lib`. Marking
+  them as `dllimport` in the libc++ `` header is therefore undesirable: if
+  we were to mark them as `dllimport` and then link against libc++, source files
+  which included `` would end up linking against libc++'s `operator new`
+  and `operator delete`, while source files which did not include `` would
+  end up linking against msvcrt's `operator new` and `operator delete`, which
+  would be a confusing and potentially error-prone inconsistency.
+
 Links
 =
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D25042: [libc++] Clarify _LIBCPP_NEW_DELETE_VIS for Windows

[Shoaib Meenai via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL282644: [libc++] Clarify _LIBCPP_NEW_DELETE_VIS for Windows 
(authored by smeenai).

Changed prior to commit:
  https://reviews.llvm.org/D25042?vs=72911&id=72915#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D25042

Files:
  libcxx/trunk/docs/DesignDocs/VisibilityMacros.rst
  libcxx/trunk/include/new

Index: libcxx/trunk/docs/DesignDocs/VisibilityMacros.rst
===
--- libcxx/trunk/docs/DesignDocs/VisibilityMacros.rst
+++ libcxx/trunk/docs/DesignDocs/VisibilityMacros.rst
@@ -108,6 +108,19 @@
   versioning namespace. This allows throwing and catching some exception types
   between libc++ and libstdc++.
 
+**_LIBCPP_NEW_DELETE_VIS**
+  Mark a symbol as being exported by the libc++ library. This macro must be
+  applied to all `operator new` and `operator delete` overloads.
+
+  **Windows Behavior**: When using the Microsoft CRT, all the `operator new` 
and
+  `operator delete` overloads are defined statically in `msvcrt.lib`. Marking
+  them as `dllimport` in the libc++ `` header is therefore undesirable: if
+  we were to mark them as `dllimport` and then link against libc++, source 
files
+  which included `` would end up linking against libc++'s `operator new`
+  and `operator delete`, while source files which did not include `` would
+  end up linking against msvcrt's `operator new` and `operator delete`, which
+  would be a confusing and potentially error-prone inconsistency.
+
 Links
 =
 
Index: libcxx/trunk/include/new
===
--- libcxx/trunk/include/new
+++ libcxx/trunk/include/new
@@ -125,8 +125,8 @@
 
 }  // std
 
-#if defined(_WIN32) && !defined(cxx_EXPORTS)
-# define _LIBCPP_NEW_DELETE_VIS _LIBCPP_FUNC_VIS_ONLY
+#if defined(_LIBCPP_MSVCRT) && !defined(_LIBCPP_BUILDING_LIBRARY)
+# define _LIBCPP_NEW_DELETE_VIS
 #else
 # define _LIBCPP_NEW_DELETE_VIS _LIBCPP_FUNC_VIS
 #endif


Index: libcxx/trunk/docs/DesignDocs/VisibilityMacros.rst
===
--- libcxx/trunk/docs/DesignDocs/VisibilityMacros.rst
+++ libcxx/trunk/docs/DesignDocs/VisibilityMacros.rst
@@ -108,6 +108,19 @@
   versioning namespace. This allows throwing and catching some exception types
   between libc++ and libstdc++.
 
+**_LIBCPP_NEW_DELETE_VIS**
+  Mark a symbol as being exported by the libc++ library. This macro must be
+  applied to all `operator new` and `operator delete` overloads.
+
+  **Windows Behavior**: When using the Microsoft CRT, all the `operator new` and
+  `operator delete` overloads are defined statically in `msvcrt.lib`. Marking
+  them as `dllimport` in the libc++ `` header is therefore undesirable: if
+  we were to mark them as `dllimport` and then link against libc++, source files
+  which included `` would end up linking against libc++'s `operator new`
+  and `operator delete`, while source files which did not include `` would
+  end up linking against msvcrt's `operator new` and `operator delete`, which
+  would be a confusing and potentially error-prone inconsistency.
+
 Links
 =
 
Index: libcxx/trunk/include/new
===
--- libcxx/trunk/include/new
+++ libcxx/trunk/include/new
@@ -125,8 +125,8 @@
 
 }  // std
 
-#if defined(_WIN32) && !defined(cxx_EXPORTS)
-# define _LIBCPP_NEW_DELETE_VIS _LIBCPP_FUNC_VIS_ONLY
+#if defined(_LIBCPP_MSVCRT) && !defined(_LIBCPP_BUILDING_LIBRARY)
+# define _LIBCPP_NEW_DELETE_VIS
 #else
 # define _LIBCPP_NEW_DELETE_VIS _LIBCPP_FUNC_VIS
 #endif
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits