[PATCH] D45121: [coroutines] Add noop_coroutine to

2018-04-03 Thread Gor Nishanov via Phabricator via cfe-commits
GorNishanov updated this revision to Diff 140903.
GorNishanov added a comment.

incorporated review feedback


https://reviews.llvm.org/D45121

Files:
  include/experimental/coroutine
  
test/std/experimental/language.support/support.coroutines/coroutine.handle/coroutine.handle.noop/noop_coroutine.pass.cpp

Index: test/std/experimental/language.support/support.coroutines/coroutine.handle/coroutine.handle.noop/noop_coroutine.pass.cpp
===
--- /dev/null
+++ test/std/experimental/language.support/support.coroutines/coroutine.handle/coroutine.handle.noop/noop_coroutine.pass.cpp
@@ -0,0 +1,64 @@
+// -*- C++ -*-
+//===--===//
+//
+// 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.
+//
+//===--===//
+
+// UNSUPPORTED: c++98, c++03, c++11
+// XFAIL: clang-5, clang-6
+// 
+// struct noop_coroutine_promise;
+// using noop_coroutine_handle = coroutine_handle;
+// noop_coroutine_handle noop_coroutine() noexcept;
+
+#include 
+#include 
+#include 
+
+namespace coro = std::experimental;
+
+static_assert(std::is_same::value, "");
+static_assert(std::is_same::value, "");
+
+// template <> struct coroutine_handle : coroutine_handle<>
+// {
+// // 18.11.2.7 noop observers
+// constexpr explicit operator bool() const noexcept;
+// constexpr bool done() const noexcept;
+
+// // 18.11.2.8 noop resumption
+// constexpr void operator()() const noexcept;
+// constexpr void resume() const noexcept;
+// constexpr void destroy() const noexcept;
+
+// // 18.11.2.9 noop promise access
+// noop_coroutine_promise& promise() const noexcept;
+
+// // 18.11.2.10 noop address
+// constexpr void* address() const noexcept;
+
+int main()
+{
+  auto h = coro::noop_coroutine();
+  coro::coroutine_handle<> base = h;
+
+  assert(h);
+  assert(base);
+
+  assert(!h.done());
+  assert(!base.done());
+
+  h.resume();
+  h.destroy();
+  h();
+
+  h.promise();
+  assert(h.address() == base.address());
+  assert(h.address() != nullptr);
+  assert(coro::coroutine_handle<>::from_address(h.address()) == base);
+}
+
Index: include/experimental/coroutine
===
--- include/experimental/coroutine
+++ include/experimental/coroutine
@@ -259,6 +259,45 @@
 }
 };
 
+#if __has_builtin(__builtin_coro_noop)
+struct noop_coroutine_promise {};
+
+template <>
+class _LIBCPP_TEMPLATE_VIS coroutine_handle
+: public coroutine_handle<> {
+  using _Base = coroutine_handle<>;
+  using _Promise = noop_coroutine_promise;
+public:
+
+_LIBCPP_INLINE_VISIBILITY
+_Promise& promise() const {
+return *reinterpret_cast<_Promise*>(
+__builtin_coro_promise(this->__handle_, __alignof(_Promise), false));
+}
+
+constexpr explicit operator bool() const noexcept { return true; }
+constexpr bool done() const noexcept { return false; }
+
+constexpr void operator()() const noexcept {}
+constexpr void resume() const noexcept {}
+constexpr void destroy() const noexcept {}
+
+private:
+friend coroutine_handle noop_coroutine()  _NOEXCEPT;
+
+coroutine_handle() {
+  this->__handle_ = __builtin_coro_noop();
+}
+};
+
+using noop_coroutine_handle = coroutine_handle;
+
+inline _LIBCPP_INLINE_VISIBILITY
+noop_coroutine_handle noop_coroutine() _NOEXCEPT {
+  return {};
+}
+#endif // __has_builtin(__builtin_coro_noop)
+
 struct _LIBCPP_TYPE_VIS suspend_never {
   _LIBCPP_ALWAYS_INLINE
   bool await_ready() const _NOEXCEPT { return true; }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D45121: [coroutines] Add noop_coroutine to

2018-04-03 Thread Gor Nishanov via Phabricator via cfe-commits
GorNishanov added a comment.

In https://reviews.llvm.org/D45121#1056408, @lewissbaker wrote:

> The `coroutine_handle` type does not have a 
> `from_address()` or a `from_promise()` static functions in the same way that 
> the `coroutine_handle` implementation does.
>  Is this intentional or an oversight in the TS wording?
>
> They don't seem hugely useful, so I'm not that worried.
>  If you know that you have a `coroutine_handle` then 
> you can just use `noop_coroutine()` to get the handle instead.


This is intentional. The only way to get a noop coroutine is to ask for it via 
`noop_coroutine()`


https://reviews.llvm.org/D45121



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


[libcxx] r329149 - Fix undefined macro issue in locale tests; Try 2

2018-04-03 Thread Eric Fiselier via cfe-commits
Author: ericwf
Date: Tue Apr  3 21:48:26 2018
New Revision: 329149

URL: http://llvm.org/viewvc/llvm-project?rev=329149=rev
Log:
Fix undefined macro issue in locale tests; Try 2

Modified:

libcxx/trunk/test/std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/get_long_double_fr_FR.pass.cpp

libcxx/trunk/test/std/localization/locale.categories/category.monetary/locale.money.put/locale.money.put.members/put_long_double_fr_FR.pass.cpp

libcxx/trunk/test/std/localization/locale.categories/category.monetary/locale.moneypunct.byname/thousands_sep.pass.cpp

Modified: 
libcxx/trunk/test/std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/get_long_double_fr_FR.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/get_long_double_fr_FR.pass.cpp?rev=329149=329148=329149=diff
==
--- 
libcxx/trunk/test/std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/get_long_double_fr_FR.pass.cpp
 (original)
+++ 
libcxx/trunk/test/std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/get_long_double_fr_FR.pass.cpp
 Tue Apr  3 21:48:26 2018
@@ -52,9 +52,10 @@ public:
 // this function converts the spaces in string inputs to that character if need
 // be.
 static std::wstring convert_thousands_sep(std::wstring const& in) {
-#if !defined(TEST_HAS_GLIBC) || !TEST_GLIBC_PREREQ(2,27)
-  return in;
-#else
+#ifndef TEST_GLIBC_PREREQ
+#define TEST_GLIBC_PREREQ(x, y) 0
+#endif
+#if TEST_GLIBC_PREREQ(2,27)
   std::wstring out;
   unsigned I = 0;
   bool seen_decimal = false;
@@ -68,6 +69,8 @@ static std::wstring convert_thousands_se
 out.push_back(L'\u202F');
   }
   return out;
+#else
+  return in;
 #endif
 }
 

Modified: 
libcxx/trunk/test/std/localization/locale.categories/category.monetary/locale.money.put/locale.money.put.members/put_long_double_fr_FR.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/localization/locale.categories/category.monetary/locale.money.put/locale.money.put.members/put_long_double_fr_FR.pass.cpp?rev=329149=329148=329149=diff
==
--- 
libcxx/trunk/test/std/localization/locale.categories/category.monetary/locale.money.put/locale.money.put.members/put_long_double_fr_FR.pass.cpp
 (original)
+++ 
libcxx/trunk/test/std/localization/locale.categories/category.monetary/locale.money.put/locale.money.put.members/put_long_double_fr_FR.pass.cpp
 Tue Apr  3 21:48:26 2018
@@ -52,9 +52,10 @@ public:
 // this function converts the spaces in string inputs to that character if need
 // be.
 static std::wstring convert_thousands_sep(std::wstring const& in) {
-#if !defined(TEST_HAS_GLIBC) || !TEST_GLIBC_PREREQ(2,27)
-  return in;
-#else
+#ifndef TEST_GLIBC_PREREQ
+#define TEST_GLIBC_PREREQ(x, y) 0
+#endif
+#if TEST_GLIBC_PREREQ(2,27)
   std::wstring out;
   unsigned I = 0;
   bool seen_num_start = false;
@@ -70,6 +71,8 @@ static std::wstring convert_thousands_se
 out.push_back(L'\u202F');
   }
   return out;
+#else
+  return in;
 #endif
 }
 

Modified: 
libcxx/trunk/test/std/localization/locale.categories/category.monetary/locale.moneypunct.byname/thousands_sep.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/localization/locale.categories/category.monetary/locale.moneypunct.byname/thousands_sep.pass.cpp?rev=329149=329148=329149=diff
==
--- 
libcxx/trunk/test/std/localization/locale.categories/category.monetary/locale.moneypunct.byname/thousands_sep.pass.cpp
 (original)
+++ 
libcxx/trunk/test/std/localization/locale.categories/category.monetary/locale.moneypunct.byname/thousands_sep.pass.cpp
 Tue Apr  3 21:48:26 2018
@@ -101,6 +101,9 @@ int main()
 assert(f.thousands_sep() == ' ');
 }
 // The below tests work around GLIBC's use of U202F as mon_thousands_sep.
+#ifndef TEST_GLIBC_PREREQ
+#define TEST_GLIBC_PREREQ(x, y) 0
+#endif
 #if defined(TEST_HAS_GLIBC) && TEST_GLIBC_PREREQ(2, 27)
 const wchar_t fr_sep = L'\u202F';
 #else
@@ -118,9 +121,6 @@ int main()
 // and U002E as mon_decimal_point.
 // TODO: Fix thousands_sep for 'char'.
 // related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16006
-#ifndef TEST_GLIBC_PREREQ
-#define TEST_GLIBC_PREREQ(x, y) 0
-#endif
 #ifndef TEST_HAS_GLIBC
 const char sep = ' ';
 const wchar_t wsep = L' ';


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


[libcxx] r329148 - Fix undefined macro issue in locale tests

2018-04-03 Thread Eric Fiselier via cfe-commits
Author: ericwf
Date: Tue Apr  3 21:39:38 2018
New Revision: 329148

URL: http://llvm.org/viewvc/llvm-project?rev=329148=rev
Log:
Fix undefined macro issue in locale tests

Modified:

libcxx/trunk/test/std/localization/locale.categories/category.monetary/locale.moneypunct.byname/decimal_point.pass.cpp

libcxx/trunk/test/std/localization/locale.categories/category.monetary/locale.moneypunct.byname/thousands_sep.pass.cpp

Modified: 
libcxx/trunk/test/std/localization/locale.categories/category.monetary/locale.moneypunct.byname/decimal_point.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/localization/locale.categories/category.monetary/locale.moneypunct.byname/decimal_point.pass.cpp?rev=329148=329147=329148=diff
==
--- 
libcxx/trunk/test/std/localization/locale.categories/category.monetary/locale.moneypunct.byname/decimal_point.pass.cpp
 (original)
+++ 
libcxx/trunk/test/std/localization/locale.categories/category.monetary/locale.moneypunct.byname/decimal_point.pass.cpp
 Tue Apr  3 21:39:38 2018
@@ -110,7 +110,10 @@ int main()
 assert(f.decimal_point() == L',');
 }
 // GLIBC 2.23 uses '.' as the decimal point while other C libraries use ','
-// GLIBC 2.27 corrects this.
+// GLIBC 2.27 corrects this
+#ifndef TEST_GLIBC_PREREQ
+#define TEST_GLIBC_PREREQ(x, y) 0
+#endif
 #if !defined(TEST_HAS_GLIBC) || TEST_GLIBC_PREREQ(2, 27)
 const char sep = ',';
 const wchar_t wsep = L',';

Modified: 
libcxx/trunk/test/std/localization/locale.categories/category.monetary/locale.moneypunct.byname/thousands_sep.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/localization/locale.categories/category.monetary/locale.moneypunct.byname/thousands_sep.pass.cpp?rev=329148=329147=329148=diff
==
--- 
libcxx/trunk/test/std/localization/locale.categories/category.monetary/locale.moneypunct.byname/thousands_sep.pass.cpp
 (original)
+++ 
libcxx/trunk/test/std/localization/locale.categories/category.monetary/locale.moneypunct.byname/thousands_sep.pass.cpp
 Tue Apr  3 21:39:38 2018
@@ -118,6 +118,9 @@ int main()
 // and U002E as mon_decimal_point.
 // TODO: Fix thousands_sep for 'char'.
 // related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16006
+#ifndef TEST_GLIBC_PREREQ
+#define TEST_GLIBC_PREREQ(x, y) 0
+#endif
 #ifndef TEST_HAS_GLIBC
 const char sep = ' ';
 const wchar_t wsep = L' ';


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


[libcxx] r329145 - Update Clang version on Appveyor bots

2018-04-03 Thread Eric Fiselier via cfe-commits
Author: ericwf
Date: Tue Apr  3 21:33:09 2018
New Revision: 329145

URL: http://llvm.org/viewvc/llvm-project?rev=329145=rev
Log:
Update Clang version on Appveyor bots

Modified:
libcxx/trunk/appveyor-reqs-install.cmd

Modified: libcxx/trunk/appveyor-reqs-install.cmd
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/appveyor-reqs-install.cmd?rev=329145=329144=329145=diff
==
--- libcxx/trunk/appveyor-reqs-install.cmd (original)
+++ libcxx/trunk/appveyor-reqs-install.cmd Tue Apr  3 21:33:09 2018
@@ -9,7 +9,7 @@ cd C:\projects\deps
 :: Setup Compiler
 ::###
 if NOT EXIST llvm-installer.exe (
-  appveyor DownloadFile 
http://prereleases.llvm.org/win-snapshots/LLVM-6.0.0-r316086-win32.exe 
-FileName llvm-installer.exe
+  appveyor DownloadFile 
http://prereleases.llvm.org/win-snapshots/LLVM-7.0.0-r325576-win32.exe 
-FileName llvm-installer.exe
 )
 if "%CLANG_VERSION%"=="ToT" (
 START /WAIT llvm-installer.exe /S /D=C:\"Program Files\LLVM"


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


[PATCH] D45212: [HIP] Let CUDA toolchain support HIP language mode

2018-04-03 Thread John McCall via Phabricator via cfe-commits
rjmccall added a comment.

The other changes I see here seem reasonable, but please do split the patch.




Comment at: include/clang/Basic/Cuda.h:61
+  GFX900,
+  GFX902,
   LAST,

Does this actually have anything to do with HIP?  You have a lot of changes in 
this patch which seem to just be about supporting more GPU revisions.



Comment at: include/clang/Driver/Options.td:556
+def offload_archs : Joined<["--"], "offload-archs=">, Flags<[DriverOption]>,
+  HelpText<"List of offload architectures for CUDA/HIP/OpenMP (e.g. 
sm_35,gfx803).">;
 def no_cuda_gpu_arch_EQ : Joined<["--"], "no-cuda-gpu-arch=">, 
Flags<[DriverOption]>,

Do we absolutely need the non-CUDA-related aliases here?  We generally try to 
be good about namespacing extension-specific language options.

I understand that you're probably trying to maintain command-line compatibility 
with some existing toolchain, but if it's possible to avoid this, I would be 
much happier.



Comment at: include/clang/Driver/ToolChain.h:124
   mutable std::unique_ptr Clang;
+  mutable std::unique_ptr Backend;
   mutable std::unique_ptr Assemble;

"Backend" is a really generic name for this thing that is probably 
hyper-specific to the CUDA translation model.


https://reviews.llvm.org/D45212



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


[PATCH] D45121: [coroutines] Add noop_coroutine to

2018-04-03 Thread Eric Fiselier via Phabricator via cfe-commits
EricWF added inline comments.



Comment at: include/experimental/coroutine:262
 
+struct noop_coroutine_promise {};
+

This whole thing should be wrapped in a `__has_builtin(__builtin_coro_noop)` so 
the header still compiles with older clang versions.



Comment at: include/experimental/coroutine:294
+
+inline _LIBCPP_ALWAYS_INLINE
+noop_coroutine_handle noop_coroutine() _NOEXCEPT {

This should just be `_LIBCPP_INLINE_VISIBILITY`. We try not to use 
`_LIBCPP_ALWAYS_INLINE` in new code.



Comment at: 
test/std/experimental/language.support/support.coroutines/coroutine.handle/coroutine.handle.noop/noop_coroutine.pass.cpp:12
+// UNSUPPORTED: c++98, c++03, c++11
+
+// 

This probably needs an `// XFAIL: clang-5, clang-6`


https://reviews.llvm.org/D45121



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


[PATCH] D44580: Sema: allow comparison between blocks & block-compatible objc types

2018-04-03 Thread John McCall via Phabricator via cfe-commits
rjmccall accepted this revision.
rjmccall added a comment.
This revision is now accepted and ready to land.

Okay, LGTM with the reduced set of changes to the functionality.


Repository:
  rC Clang

https://reviews.llvm.org/D44580



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


[libcxx] r329144 - Touch up tests for new header; fix module.modulemap.

2018-04-03 Thread Eric Fiselier via cfe-commits
Author: ericwf
Date: Tue Apr  3 21:21:54 2018
New Revision: 329144

URL: http://llvm.org/viewvc/llvm-project?rev=329144=rev
Log:
Touch up tests for new  header; fix module.modulemap.

This patch does some housekeeping for the new  header.
It adds it to the module.modulemap, and the double_include.sh.cpp test.

Additionally it corrects the // UNSUPPORTED options for the libc++
specific test. The header needs to compile under C++03 to support
modules, and it should compile under all available compilers.

Modified:
libcxx/trunk/include/module.modulemap
libcxx/trunk/test/libcxx/double_include.sh.cpp
libcxx/trunk/test/libcxx/language.support/support.limits/version.pass.cpp

Modified: libcxx/trunk/include/module.modulemap
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/module.modulemap?rev=329144=329143=329144=diff
==
--- libcxx/trunk/include/module.modulemap (original)
+++ libcxx/trunk/include/module.modulemap Tue Apr  3 21:21:54 2018
@@ -470,6 +470,10 @@ module std [system] {
 export initializer_list
 export *
   }
+  module version {
+header "version"
+export *
+  }
 
   // FIXME: These should be private.
   module __bit_reference { header "__bit_reference" export * }

Modified: libcxx/trunk/test/libcxx/double_include.sh.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/libcxx/double_include.sh.cpp?rev=329144=329143=329144=diff
==
--- libcxx/trunk/test/libcxx/double_include.sh.cpp (original)
+++ libcxx/trunk/test/libcxx/double_include.sh.cpp Tue Apr  3 21:21:54 2018
@@ -129,6 +129,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 

Modified: 
libcxx/trunk/test/libcxx/language.support/support.limits/version.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/libcxx/language.support/support.limits/version.pass.cpp?rev=329144=329143=329144=diff
==
--- libcxx/trunk/test/libcxx/language.support/support.limits/version.pass.cpp 
(original)
+++ libcxx/trunk/test/libcxx/language.support/support.limits/version.pass.cpp 
Tue Apr  3 21:21:54 2018
@@ -8,9 +8,6 @@
 
//===--===//
 
 // 
-// UNSUPPORTED: c++98, c++03, c++11, c++14, c++17
-// UNSUPPORTED: clang-3.3, clang-3.4, clang-3.5, clang-3.6, clang-3.7
-// UNSUPPORTED: clang-3.8, clang-3.9, clang-4.0, clang-5.0, clang-6.0
 
 #include 
 


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


[PATCH] D45176: implement recent "standard-layout" changes

2018-04-03 Thread John McCall via Phabricator via cfe-commits
rjmccall accepted this revision.
rjmccall added a comment.
This revision is now accepted and ready to land.

Okay.  LGTM.  Thank you for putting the effort into maintaining both rules 
simultaneously.


https://reviews.llvm.org/D45176



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


[libcxx] r329143 - Fix locale test data for GLIBC 2.27 and newer.

2018-04-03 Thread Eric Fiselier via cfe-commits
Author: ericwf
Date: Tue Apr  3 21:00:14 2018
New Revision: 329143

URL: http://llvm.org/viewvc/llvm-project?rev=329143=rev
Log:
Fix locale test data for GLIBC 2.27 and newer.

GLIBC 2.27 changed the locale data for fr_FR and ru_RU. In particular
they change the decimal and thousands separators used. This patch
makes the locale tests tolerate the updated locales.

Modified:
libcxx/trunk/src/locale.cpp

libcxx/trunk/test/std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/get_long_double_fr_FR.pass.cpp

libcxx/trunk/test/std/localization/locale.categories/category.monetary/locale.money.put/locale.money.put.members/put_long_double_fr_FR.pass.cpp

libcxx/trunk/test/std/localization/locale.categories/category.monetary/locale.moneypunct.byname/decimal_point.pass.cpp

libcxx/trunk/test/std/localization/locale.categories/category.monetary/locale.moneypunct.byname/thousands_sep.pass.cpp

libcxx/trunk/test/std/localization/locale.categories/facet.numpunct/locale.numpunct.byname/thousands_sep.pass.cpp

Modified: libcxx/trunk/src/locale.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/src/locale.cpp?rev=329143=329142=329143=diff
==
--- libcxx/trunk/src/locale.cpp (original)
+++ libcxx/trunk/src/locale.cpp Tue Apr  3 21:00:14 2018
@@ -4240,6 +4240,7 @@ static bool checked_string_to_char_conve
   // FIXME: Work around specific multibyte sequences that we can reasonable
   // translate into a different single byte.
   switch (wout) {
+  case L'\u202F': // narrow non-breaking space
   case L'\u00A0': // non-breaking space
 dest = ' ';
 return true;

Modified: 
libcxx/trunk/test/std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/get_long_double_fr_FR.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/get_long_double_fr_FR.pass.cpp?rev=329143=329142=329143=diff
==
--- 
libcxx/trunk/test/std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/get_long_double_fr_FR.pass.cpp
 (original)
+++ 
libcxx/trunk/test/std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/get_long_double_fr_FR.pass.cpp
 Tue Apr  3 21:00:14 2018
@@ -25,6 +25,7 @@
 #include "test_iterators.h"
 
 #include "platform_support.h" // locale name macros
+#include "test_macros.h"
 
 typedef std::money_get Fn;
 
@@ -46,6 +47,30 @@ public:
 : Fw(refs) {}
 };
 
+
+// GLIBC 2.27 and newer use U2027 (narrow non-breaking space) as a thousands 
sep.
+// this function converts the spaces in string inputs to that character if need
+// be.
+static std::wstring convert_thousands_sep(std::wstring const& in) {
+#if !defined(TEST_HAS_GLIBC) || !TEST_GLIBC_PREREQ(2,27)
+  return in;
+#else
+  std::wstring out;
+  unsigned I = 0;
+  bool seen_decimal = false;
+  for (; I < in.size(); ++I) {
+if (seen_decimal || in[I] != L' ') {
+  seen_decimal |= in[I] == L',';
+  out.push_back(in[I]);
+  continue;
+}
+assert(in[I] == L' ');
+out.push_back(L'\u202F');
+  }
+  return out;
+#endif
+}
+
 int main()
 {
 std::ios ios(0);
@@ -417,7 +442,7 @@ int main()
 assert(ex == -1);
 }
 {   // positive
-std::wstring v = L"1 234 567,89 ";
+std::wstring v = convert_thousands_sep(L"1 234 567,89 ");
 typedef input_iterator I;
 long double ex;
 std::ios_base::iostate err = std::ios_base::goodbit;
@@ -428,7 +453,7 @@ int main()
 assert(ex == 123456789);
 }
 {   // negative
-std::wstring v = L"-1 234 567,89";
+std::wstring v = convert_thousands_sep(L"-1 234 567,89");
 typedef input_iterator I;
 long double ex;
 std::ios_base::iostate err = std::ios_base::goodbit;
@@ -497,7 +522,7 @@ int main()
 assert(ex == -1);
 }
 {   // positive, showbase
-std::wstring v = L"1 234 567,89 \u20ac";  // EURO SIGN
+std::wstring v = convert_thousands_sep(L"1 234 567,89 \u20ac");  
// EURO SIGN
 typedef input_iterator I;
 long double ex;
 std::ios_base::iostate err = std::ios_base::goodbit;
@@ -508,7 +533,7 @@ int main()
 assert(ex == 123456789);
 }
 {   // positive, showbase
-std::wstring v = L"1 234 567,89 \u20ac";  // EURO SIGN
+std::wstring v = convert_thousands_sep(L"1 234 567,89 \u20ac");  
// EURO SIGN
 showbase(ios);
 typedef input_iterator I;
 long double ex;
@@ -521,7 +546,7 @@ int main()
 noshowbase(ios);
 }
 { 

[PATCH] D45194: [Sema] Defer checking constexpr lambda until after we've finished the lambda class.

2018-04-03 Thread Faisal Vali via Phabricator via cfe-commits
faisalv added a comment.

Thanks for working on this fairly embarrassing bug (let's fix this before the 
week is over :)




Comment at: clang/lib/Sema/SemaDecl.cpp:12886
 if (!IsInstantiation && FD && FD->isConstexpr() && !FD->isInvalidDecl() &&
+!isLambdaCallOperator(FD) &&
 (!CheckConstexprFunctionDecl(FD) ||

Hmm - as opposed to further leaking our lambda's implementation-details into 
ActOnFinishFunctionBody - and duplicating these checks for a lambda marked 
constexpr, I think I would prefer teaching the expression-evaluator 
(ExprConstant.cpp) to know how to check a lambda's function call operator for 
constexprness (i.e. avoid creating the capture-to-field-map when 
'checkingPotentialConstantExpression()' and ignore evaluating expressions that 
refer to enclosing variables since their evaluation should not affect inferring 
constexprness).  

Thoughts?




Repository:
  rC Clang

https://reviews.llvm.org/D45194



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


[PATCH] D44619: [CodeGen] Add cleanup scope to EmitInlinedInheritingCXXConstructorCall

2018-04-03 Thread Shoaib Meenai via Phabricator via cfe-commits
smeenai planned changes to this revision.
smeenai added a comment.

This doesn't pass all tests right now, and I'll also need to change the test in 
accordance with the review comments.


Repository:
  rC Clang

https://reviews.llvm.org/D44619



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


[PATCH] D44619: [CodeGen] Add cleanup scope to EmitInlinedInheritingCXXConstructorCall

2018-04-03 Thread Shoaib Meenai via Phabricator via cfe-commits
smeenai added a comment.

Finally got a chance to dig into some of the failures this patch is causing. 
Here's an example crasher (run with `clang -cc1 -triple i686-windows 
-emit-llvm`):

  struct Q {
Q(int);
~Q();
  };
  struct Z {};
  struct A {
A(Q);
  };
  struct B : Z, A {
using A::A;
  };
  B b(Q(1));

What's happening here is that we emit the inlined inherited constructor call 
(B's `using A::A`), which in turn emits the constructor call (`A::A`), which 
eventually winds up in CodeGenFunction::EmitCall, which calls 
deactivateArgCleanupsBeforeCall, which cleans the cleanup stack. However, the 
RunCleanupsScope that I added thinks it has cleanups to do, because the 
EHStack's stable_begin iterator holds a different (empty) value at its 
destruction than it did at its construction. Of course, the cleanup stack is 
actually empty at this point, so attempting to run cleanups just asserts.

I guess what I want is for my added scope to only apply to the cleanups added 
for base destructor calls (since any cleanups for arguments will be handled by 
deactivateArgCleanupsBeforeCall), but I'm not sure how best to accomplish that.

CodeGenFunction::EmitConstructorBody also wraps a RunCleanupsScope around its 
EmitCtorPrologue call, so in theory it should be affected by the same problem. 
I'll try to craft a test.


Repository:
  rC Clang

https://reviews.llvm.org/D44619



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


Re: r328731 - [ObjC++] Make parameter passing and function return compatible with ObjC

2018-04-03 Thread Richard Smith via cfe-commits
On 3 April 2018 at 13:07, Akira Hatanaka via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

>
>
> On Apr 1, 2018, at 6:00 PM, Richard Smith  wrote:
>
> On 28 March 2018 at 14:13, Akira Hatanaka via cfe-commits  lists.llvm.org> wrote:
>
>> Author: ahatanak
>> Date: Wed Mar 28 14:13:14 2018
>> New Revision: 328731
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=328731=rev
>> Log:
>> [ObjC++] Make parameter passing and function return compatible with ObjC
>>
>> ObjC and ObjC++ pass non-trivial structs in a way that is incompatible
>> with each other. For example:
>>
>> typedef struct {
>>   id f0;
>>   __weak id f1;
>> } S;
>>
>> // this code is compiled in c++.
>> extern "C" {
>>   void foo(S s);
>> }
>>
>> void caller() {
>>   // the caller passes the parameter indirectly and destructs it.
>>   foo(S());
>> }
>>
>> // this function is compiled in c.
>> // 'a' is passed directly and is destructed in the callee.
>> void foo(S a) {
>> }
>>
>> This patch fixes the incompatibility by passing and returning structs
>> with __strong or weak fields using the C ABI in C++ mode. __strong and
>> __weak fields in a struct do not cause the struct to be destructed in
>> the caller and __strong fields do not cause the struct to be passed
>> indirectly.
>>
>> Also, this patch fixes the microsoft ABI bug mentioned here:
>>
>> https://reviews.llvm.org/D41039?id=128767#inline-364710
>>
>> rdar://problem/38887866
>>
>> Differential Revision: https://reviews.llvm.org/D44908
>>
>> Added:
>> cfe/trunk/test/CodeGenObjCXX/objc-struct-cxx-abi.mm
>>   - copied, changed from r328730, cfe/trunk/test/CodeGenObjCXX/t
>> rivial_abi.mm
>> Removed:
>> cfe/trunk/test/CodeGenObjCXX/trivial_abi.mm
>> Modified:
>> cfe/trunk/include/clang/AST/Decl.h
>> cfe/trunk/include/clang/AST/DeclCXX.h
>> cfe/trunk/include/clang/AST/Type.h
>> cfe/trunk/include/clang/Basic/LangOptions.def
>> cfe/trunk/include/clang/Basic/LangOptions.h
>> cfe/trunk/include/clang/Basic/TargetInfo.h
>> cfe/trunk/include/clang/Frontend/CodeGenOptions.def
>> cfe/trunk/lib/AST/ASTContext.cpp
>> cfe/trunk/lib/AST/Decl.cpp
>> cfe/trunk/lib/AST/DeclCXX.cpp
>> cfe/trunk/lib/AST/Type.cpp
>> cfe/trunk/lib/Basic/TargetInfo.cpp
>> cfe/trunk/lib/Basic/Targets/X86.h
>> cfe/trunk/lib/CodeGen/CGCall.cpp
>> cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
>> cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp
>> cfe/trunk/lib/CodeGen/TargetInfo.cpp
>> cfe/trunk/lib/Frontend/CompilerInvocation.cpp
>> cfe/trunk/lib/Sema/SemaDecl.cpp
>> cfe/trunk/lib/Sema/SemaDeclCXX.cpp
>> cfe/trunk/lib/Serialization/ASTReaderDecl.cpp
>> cfe/trunk/lib/Serialization/ASTWriter.cpp
>> cfe/trunk/lib/Serialization/ASTWriterDecl.cpp
>> cfe/trunk/test/CodeGenCXX/microsoft-abi-sret-and-byval.cpp
>> cfe/trunk/test/CodeGenObjCXX/arc-special-member-functions.mm
>> cfe/trunk/test/CodeGenObjCXX/property-dot-copy-elision.mm
>>
>> Modified: cfe/trunk/include/clang/AST/Decl.h
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/
>> include/clang/AST/Decl.h?rev=328731=328730=328731=diff
>> 
>> ==
>> --- cfe/trunk/include/clang/AST/Decl.h (original)
>> +++ cfe/trunk/include/clang/AST/Decl.h Wed Mar 28 14:13:14 2018
>> @@ -3559,6 +3559,11 @@ class RecordDecl : public TagDecl {
>>/// pass an object of this class.
>>bool CanPassInRegisters : 1;
>>
>> +  /// Indicates whether this struct is destroyed in the callee. This
>> flag is
>> +  /// meaningless when Microsoft ABI is used since parameters are always
>> +  /// destroyed in the callee.
>> +  bool ParamDestroyedInCallee : 1;
>> +
>>  protected:
>>RecordDecl(Kind DK, TagKind TK, const ASTContext , DeclContext *DC,
>>   SourceLocation StartLoc, SourceLocation IdLoc,
>> @@ -3654,6 +3659,14 @@ public:
>>  CanPassInRegisters = CanPass;
>>}
>>
>> +  bool isParamDestroyedInCallee() const {
>> +return ParamDestroyedInCallee;
>> +  }
>> +
>> +  void setParamDestroyedInCallee(bool V) {
>> +ParamDestroyedInCallee = V;
>> +  }
>> +
>>/// \brief Determines whether this declaration represents the
>>/// injected class name.
>>///
>>
>> Modified: cfe/trunk/include/clang/AST/DeclCXX.h
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/
>> include/clang/AST/DeclCXX.h?rev=328731=328730=328731=diff
>> 
>> ==
>> --- cfe/trunk/include/clang/AST/DeclCXX.h (original)
>> +++ cfe/trunk/include/clang/AST/DeclCXX.h Wed Mar 28 14:13:14 2018
>> @@ -1468,13 +1468,6 @@ public:
>>  return data().HasIrrelevantDestructor;
>>}
>>
>> -  /// Determine whether the triviality for the purpose of calls for this
>> class
>> -  /// is overridden to be trivial because this class or the type of one
>> of its
>> -  /// subobjects has attribute "trivial_abi".
>> -  bool 

[PATCH] D45176: implement recent "standard-layout" changes

2018-04-03 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith updated this revision to Diff 140897.
rsmith marked an inline comment as done.

https://reviews.llvm.org/D45176

Files:
  AST/ASTImporter.cpp
  AST/DeclCXX.cpp
  AST/RecordLayoutBuilder.cpp
  CXX/drs/dr14xx.cpp
  CXX/drs/dr16xx.cpp
  CXX/drs/dr18xx.cpp
  CXX/drs/dr21xx.cpp
  CXX/drs/dr22xx.cpp
  Layout/watchos-standard-layout.cpp
  ReleaseNotes.rst
  SemaCXX/type-traits.cpp
  Serialization/ASTReaderDecl.cpp
  Serialization/ASTWriter.cpp
  clang/AST/DeclCXX.h
  clang/AST/Type.h
  cxx_dr_status.html
  make_cxx_dr_status

Index: make_cxx_dr_status
===
--- make_cxx_dr_status
+++ make_cxx_dr_status
@@ -129,6 +129,9 @@
   elif status == 'na lib':
 avail = 'N/A (Library DR)'
 avail_style = ' class="na"'
+  elif status == 'na abi':
+avail = 'N/A (ABI constraint)'
+avail_style = ' class="na"'
   elif status.startswith('sup '):
 dup = status.split(' ', 1)[1]
 avail = 'Superseded by %s' % (dup, dup)
Index: cxx_dr_status.html
===
--- cxx_dr_status.html
+++ cxx_dr_status.html
@@ -8365,7 +8365,7 @@
 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1425;>1425
 CD3
 Base-class subobjects of standard-layout structs
-Unknown
+N/A (ABI constraint)
   
   
 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#1426;>1426
@@ -9847,7 +9847,7 @@
 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1672;>1672
 CD4
 Layout compatibility with multiple empty bases
-Unknown
+SVN
   
   
 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1673;>1673
@@ -10693,7 +10693,7 @@
 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1813;>1813
 CD4
 Direct vs indirect bases in standard-layout classes
-Unknown
+SVN
   
   
 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1814;>1814
@@ -11101,7 +11101,7 @@
 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1881;>1881
 CD4
 Standard-layout classes and unnamed bit-fields
-Unknown
+SVN
   
   
 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1882;>1882
@@ -12535,7 +12535,7 @@
 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#2120;>2120
 CD4
 Array as first non-static data member in standard-layout class
-Unknown
+SVN
   
   
 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#2121;>2121
@@ -13189,7 +13189,7 @@
 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#2229;>2229
 tentatively ready
 Volatile unnamed bit-fields
-Unknown
+SVN
   
   
 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#2230;>2230
Index: SemaCXX/type-traits.cpp
===
--- SemaCXX/type-traits.cpp
+++ SemaCXX/type-traits.cpp
@@ -1353,6 +1353,59 @@
   int t43[F(__is_standard_layout(AnIncompleteType[1]))]; // expected-error {{incomplete type}}
   int t44[F(__is_standard_layout(void))];
   int t45[F(__is_standard_layout(const volatile void))];
+
+  struct HasAnonEmptyBitfield { int : 0; };
+  struct HasAnonBitfield { int : 4; };
+  struct DerivesFromBitfield : HasAnonBitfield {};
+  struct DerivesFromBitfieldWithBitfield : HasAnonBitfield { int : 5; };
+  struct DerivesFromBitfieldTwice : DerivesFromBitfield, HasAnonEmptyBitfield {};
+
+  int t50[T(__is_standard_layout(HasAnonEmptyBitfield))];
+  int t51[T(__is_standard_layout(HasAnonBitfield))];
+  int t52[T(__is_standard_layout(DerivesFromBitfield))];
+  int t53[F(__is_standard_layout(DerivesFromBitfieldWithBitfield))];
+  int t54[F(__is_standard_layout(DerivesFromBitfieldTwice))];
+
+  struct Empty {};
+  struct HasEmptyBase : Empty {};
+  struct HoldsEmptyBase { Empty e; };
+  struct HasRepeatedEmptyBase : Empty, HasEmptyBase {}; // expected-warning {{inaccessible}}
+  struct HasEmptyBaseAsMember : Empty { Empty e; };
+  struct HasEmptyBaseAsSubobjectOfMember1 : Empty { HoldsEmptyBase e; };
+  struct HasEmptyBaseAsSubobjectOfMember2 : Empty { HasEmptyBase e; };
+  struct HasEmptyBaseAsSubobjectOfMember3 : Empty { HoldsEmptyBase e[2]; };
+  struct HasEmptyIndirectBaseAsMember : HasEmptyBase { Empty e; };
+  struct HasEmptyIndirectBaseAsSecondMember : HasEmptyBase { int n; Empty e; };
+  struct HasEmptyIndirectBaseAfterBitfield : HasEmptyBase { int : 4; Empty e; };
+
+  int t60[T(__is_standard_layout(Empty))];
+  int t61[T(__is_standard_layout(HasEmptyBase))];
+  int t62[F(__is_standard_layout(HasRepeatedEmptyBase))];
+  int t63[F(__is_standard_layout(HasEmptyBaseAsMember))];
+  int t64[F(__is_standard_layout(HasEmptyBaseAsSubobjectOfMember1))];
+  int t65[T(__is_standard_layout(HasEmptyBaseAsSubobjectOfMember2))]; // FIXME: standard bug?
+  int t66[F(__is_standard_layout(HasEmptyBaseAsSubobjectOfMember3))];
+  int t67[F(__is_standard_layout(HasEmptyIndirectBaseAsMember))];
+  int 

[PATCH] D45176: implement recent "standard-layout" changes

2018-04-03 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith marked an inline comment as done.
rsmith added inline comments.



Comment at: AST/DeclCXX.cpp:1130
   data().IsStandardLayout = false;
+  data().IsCXX11StandardLayout = false;
+}

rjmccall wrote:
> `IsCXX11StandardLayout` should be based on 
> `FieldRec->isCXX11StandardLayout()`, I assume.
Oops. Yes.


https://reviews.llvm.org/D45176



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


[PATCH] D45176: implement recent "standard-layout" changes

2018-04-03 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith updated this revision to Diff 140896.

https://reviews.llvm.org/D45176

Files:
  AST/ASTImporter.cpp
  AST/DeclCXX.cpp
  AST/RecordLayoutBuilder.cpp
  CXX/drs/dr14xx.cpp
  CXX/drs/dr16xx.cpp
  CXX/drs/dr18xx.cpp
  CXX/drs/dr21xx.cpp
  CXX/drs/dr22xx.cpp
  Layout/watchos-standard-layout.cpp
  ReleaseNotes.rst
  SemaCXX/type-traits.cpp
  Serialization/ASTReaderDecl.cpp
  Serialization/ASTWriter.cpp
  clang/AST/DeclCXX.h
  clang/AST/Type.h
  cxx_dr_status.html
  make_cxx_dr_status

Index: make_cxx_dr_status
===
--- make_cxx_dr_status
+++ make_cxx_dr_status
@@ -129,6 +129,9 @@
   elif status == 'na lib':
 avail = 'N/A (Library DR)'
 avail_style = ' class="na"'
+  elif status == 'na abi':
+avail = 'N/A (ABI constraint)'
+avail_style = ' class="na"'
   elif status.startswith('sup '):
 dup = status.split(' ', 1)[1]
 avail = 'Superseded by %s' % (dup, dup)
Index: cxx_dr_status.html
===
--- cxx_dr_status.html
+++ cxx_dr_status.html
@@ -8365,7 +8365,7 @@
 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1425;>1425
 CD3
 Base-class subobjects of standard-layout structs
-Unknown
+N/A (ABI constraint)
   
   
 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#1426;>1426
@@ -9847,7 +9847,7 @@
 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1672;>1672
 CD4
 Layout compatibility with multiple empty bases
-Unknown
+SVN
   
   
 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1673;>1673
@@ -10693,7 +10693,7 @@
 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1813;>1813
 CD4
 Direct vs indirect bases in standard-layout classes
-Unknown
+SVN
   
   
 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1814;>1814
@@ -11101,7 +11101,7 @@
 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1881;>1881
 CD4
 Standard-layout classes and unnamed bit-fields
-Unknown
+SVN
   
   
 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1882;>1882
@@ -12535,7 +12535,7 @@
 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#2120;>2120
 CD4
 Array as first non-static data member in standard-layout class
-Unknown
+SVN
   
   
 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#2121;>2121
@@ -13189,7 +13189,7 @@
 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#2229;>2229
 tentatively ready
 Volatile unnamed bit-fields
-Unknown
+SVN
   
   
 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#2230;>2230
Index: SemaCXX/type-traits.cpp
===
--- SemaCXX/type-traits.cpp
+++ SemaCXX/type-traits.cpp
@@ -1353,6 +1353,59 @@
   int t43[F(__is_standard_layout(AnIncompleteType[1]))]; // expected-error {{incomplete type}}
   int t44[F(__is_standard_layout(void))];
   int t45[F(__is_standard_layout(const volatile void))];
+
+  struct HasAnonEmptyBitfield { int : 0; };
+  struct HasAnonBitfield { int : 4; };
+  struct DerivesFromBitfield : HasAnonBitfield {};
+  struct DerivesFromBitfieldWithBitfield : HasAnonBitfield { int : 5; };
+  struct DerivesFromBitfieldTwice : DerivesFromBitfield, HasAnonEmptyBitfield {};
+
+  int t50[T(__is_standard_layout(HasAnonEmptyBitfield))];
+  int t51[T(__is_standard_layout(HasAnonBitfield))];
+  int t52[T(__is_standard_layout(DerivesFromBitfield))];
+  int t53[F(__is_standard_layout(DerivesFromBitfieldWithBitfield))];
+  int t54[F(__is_standard_layout(DerivesFromBitfieldTwice))];
+
+  struct Empty {};
+  struct HasEmptyBase : Empty {};
+  struct HoldsEmptyBase { Empty e; };
+  struct HasRepeatedEmptyBase : Empty, HasEmptyBase {}; // expected-warning {{inaccessible}}
+  struct HasEmptyBaseAsMember : Empty { Empty e; };
+  struct HasEmptyBaseAsSubobjectOfMember1 : Empty { HoldsEmptyBase e; };
+  struct HasEmptyBaseAsSubobjectOfMember2 : Empty { HasEmptyBase e; };
+  struct HasEmptyBaseAsSubobjectOfMember3 : Empty { HoldsEmptyBase e[2]; };
+  struct HasEmptyIndirectBaseAsMember : HasEmptyBase { Empty e; };
+  struct HasEmptyIndirectBaseAsSecondMember : HasEmptyBase { int n; Empty e; };
+  struct HasEmptyIndirectBaseAfterBitfield : HasEmptyBase { int : 4; Empty e; };
+
+  int t60[T(__is_standard_layout(Empty))];
+  int t61[T(__is_standard_layout(HasEmptyBase))];
+  int t62[F(__is_standard_layout(HasRepeatedEmptyBase))];
+  int t63[F(__is_standard_layout(HasEmptyBaseAsMember))];
+  int t64[F(__is_standard_layout(HasEmptyBaseAsSubobjectOfMember1))];
+  int t65[T(__is_standard_layout(HasEmptyBaseAsSubobjectOfMember2))]; // FIXME: standard bug?
+  int t66[F(__is_standard_layout(HasEmptyBaseAsSubobjectOfMember3))];
+  int t67[F(__is_standard_layout(HasEmptyIndirectBaseAsMember))];
+  int 

[PATCH] D45178: Fixes errors caused by https://reviews.llvm.org/D44960

2018-04-03 Thread Max Moroz via Phabricator via cfe-commits
Dor1s added a comment.

Friendly ping. We'll probably land it tomorrow anyway, as it blocks another fix 
needed for llvm-cov, but having another pair of eyes to look at this would be 
still helpful :)


Repository:
  rC Clang

https://reviews.llvm.org/D45178



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


[PATCH] D45241: [analyzer] Invalidate union regions properly. Don't hesitate to load the default binding later.

2018-04-03 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ added inline comments.



Comment at: test/Analysis/unions.cpp:82
 uu = vv;
-// FIXME: Should be true.
-clang_analyzer_eval(uu.i == 5); // expected-warning{{UNKNOWN}}
+clang_analyzer_eval(uu.i == 5); // expected-warning{{TRUE}}
   }

This test got fixed because we're now loading the default-bound lazy compound 
value for `vv` from `uu` correctly.


Repository:
  rC Clang

https://reviews.llvm.org/D45241



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


[PATCH] D45241: [analyzer] Invalidate union regions properly. Don't hesitate to load the default binding later.

2018-04-03 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ created this revision.
NoQ added reviewers: dcoughlin, xazax.hun, a.sidorin, george.karpenkov, szepet.
Herald added subscribers: cfe-commits, rnkovacs.

(1) We weren't invalidating our unions correctly. The previous behavior in 
`invalidateRegionsWorker::VisitCluster()` was to //direct//-bind an 
`UnknownVal` to the union (at offset 0). The proposed behavior is to 
//default//-bind a conjured symbol (of irrelevant type) to the union that's 
being invalidated, similarly to what we do for structures and classes.

(2) In order to keep ourselves afloat, we were never actually loading default 
bindings from our unions, because there never was any default binding to load, 
and the value that is presumed when there's no default binding to load is 
usually completely incorrect (eg. `UndefinedVal` for stack unions).

Fix bug (1) and then remove hack (2).


Repository:
  rC Clang

https://reviews.llvm.org/D45241

Files:
  lib/StaticAnalyzer/Core/RegionStore.cpp
  test/Analysis/unions.cpp


Index: test/Analysis/unions.cpp
===
--- test/Analysis/unions.cpp
+++ test/Analysis/unions.cpp
@@ -79,8 +79,7 @@
 IntOrString vv;
 vv.i = 5;
 uu = vv;
-// FIXME: Should be true.
-clang_analyzer_eval(uu.i == 5); // expected-warning{{UNKNOWN}}
+clang_analyzer_eval(uu.i == 5); // expected-warning{{TRUE}}
   }
 
   void testInvalidation() {
@@ -106,3 +105,20 @@
 clang_analyzer_eval(uu.s[0] == 'a'); // expected-warning{{UNKNOWN}}
   }
 }
+
+namespace assume_union_contents {
+union U {
+  int x;
+};
+
+U get();
+
+void test() {
+  U u = get();
+  int y = 0;
+  if (u.x)
+y = 1;
+  if (u.x)
+y = 1 / y; // no-warning
+}
+} // end namespace assume_union_contents
Index: lib/StaticAnalyzer/Core/RegionStore.cpp
===
--- lib/StaticAnalyzer/Core/RegionStore.cpp
+++ lib/StaticAnalyzer/Core/RegionStore.cpp
@@ -230,11 +230,6 @@
 }
 
 Optional RegionBindingsRef::getDefaultBinding(const MemRegion *R) const {
-  if (R->isBoundable())
-if (const TypedValueRegion *TR = dyn_cast(R))
-  if (TR->getValueType()->isUnionType())
-return UnknownVal();
-
   return Optional::create(lookup(R, BindingKey::Default));
 }
 
@@ -1095,7 +1090,7 @@
 return;
   }
 
-  if (T->isStructureOrClassType()) {
+  if (T->isRecordType()) {
 // Invalidate the region by setting its default value to
 // conjured symbol. The type of the symbol is irrelevant.
 DefinedOrUnknownSVal V = svalBuilder.conjureSymbolVal(baseR, Ex, LCtx,


Index: test/Analysis/unions.cpp
===
--- test/Analysis/unions.cpp
+++ test/Analysis/unions.cpp
@@ -79,8 +79,7 @@
 IntOrString vv;
 vv.i = 5;
 uu = vv;
-// FIXME: Should be true.
-clang_analyzer_eval(uu.i == 5); // expected-warning{{UNKNOWN}}
+clang_analyzer_eval(uu.i == 5); // expected-warning{{TRUE}}
   }
 
   void testInvalidation() {
@@ -106,3 +105,20 @@
 clang_analyzer_eval(uu.s[0] == 'a'); // expected-warning{{UNKNOWN}}
   }
 }
+
+namespace assume_union_contents {
+union U {
+  int x;
+};
+
+U get();
+
+void test() {
+  U u = get();
+  int y = 0;
+  if (u.x)
+y = 1;
+  if (u.x)
+y = 1 / y; // no-warning
+}
+} // end namespace assume_union_contents
Index: lib/StaticAnalyzer/Core/RegionStore.cpp
===
--- lib/StaticAnalyzer/Core/RegionStore.cpp
+++ lib/StaticAnalyzer/Core/RegionStore.cpp
@@ -230,11 +230,6 @@
 }
 
 Optional RegionBindingsRef::getDefaultBinding(const MemRegion *R) const {
-  if (R->isBoundable())
-if (const TypedValueRegion *TR = dyn_cast(R))
-  if (TR->getValueType()->isUnionType())
-return UnknownVal();
-
   return Optional::create(lookup(R, BindingKey::Default));
 }
 
@@ -1095,7 +1090,7 @@
 return;
   }
 
-  if (T->isStructureOrClassType()) {
+  if (T->isRecordType()) {
 // Invalidate the region by setting its default value to
 // conjured symbol. The type of the symbol is irrelevant.
 DefinedOrUnknownSVal V = svalBuilder.conjureSymbolVal(baseR, Ex, LCtx,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r329141 - Split test/Driver/darwin-sdkroot.c into two tests

2018-04-03 Thread Alex Lorenz via cfe-commits
Author: arphaman
Date: Tue Apr  3 19:11:20 2018
New Revision: 329141

URL: http://llvm.org/viewvc/llvm-project?rev=329141=rev
Log:
Split test/Driver/darwin-sdkroot.c into two tests

The test additions in r329110 are Darwin-specific, as they rely
on a code path that is reachabled when driver is invoked without
-target. Instead of making the old test checks Darwin-specific too,
let's simply split it into two files to ensure that the old
checks are still platform-agnostic. Thanks Chandler for
suggesting this!

Added:
cfe/trunk/test/Driver/darwin-infer-simulator-sdkroot.c
Modified:
cfe/trunk/test/Driver/darwin-sdkroot.c

Added: cfe/trunk/test/Driver/darwin-infer-simulator-sdkroot.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/darwin-infer-simulator-sdkroot.c?rev=329141=auto
==
--- cfe/trunk/test/Driver/darwin-infer-simulator-sdkroot.c (added)
+++ cfe/trunk/test/Driver/darwin-infer-simulator-sdkroot.c Tue Apr  3 19:11:20 
2018
@@ -0,0 +1,73 @@
+// Check that SDKROOT does not infer simulator on when it points to a regular
+// SDK.
+// REQUIRES: system-darwin
+//
+// RUN: rm -rf %t/SDKs/iPhoneOS8.0.0.sdk
+// RUN: mkdir -p %t/SDKs/iPhoneOS8.0.0.sdk
+// RUN: env SDKROOT=%t/SDKs/iPhoneOS8.0.0.sdk %clang %s -### 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-IPHONE %s
+// CHECK-IPHONE: clang
+// CHECK-IPHONE: "-cc1"
+// CHECK-IPHONE: -apple-ios8.0.0"
+// CHECK-IPHONE: ld
+// CHECK-IPHONE: "-iphoneos_version_min" "8.0.0"
+//
+//
+// RUN: rm -rf %t/SDKs/iPhoneSimulator8.0.sdk
+// RUN: mkdir -p %t/SDKs/iPhoneSimulator8.0.sdk
+// RUN: env SDKROOT=%t/SDKs/iPhoneSimulator8.0.sdk %clang %s -### 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-SIMULATOR %s
+//
+// CHECK-SIMULATOR: clang
+// CHECK-SIMULATOR: "-cc1"
+// CHECK-SIMULATOR: -apple-ios8.0.0-simulator"
+// CHECK-SIMULATOR: ld
+// CHECK-SIMULATOR: "-ios_simulator_version_min" "8.0.0"
+//
+//
+// RUN: rm -rf %t/SDKs/WatchOS3.0.sdk
+// RUN: mkdir -p %t/SDKs/WatchOS3.0.sdk
+// RUN: env SDKROOT=%t/SDKs/WatchOS3.0.sdk %clang %s -### 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-WATCH %s
+//
+// CHECK-WATCH: clang
+// CHECK-WATCH: "-cc1"
+// CHECK-WATCH: -apple-watchos3.0.0"
+// CHECK-WATCH: ld
+// CHECK-WATCH: "-watchos_version_min" "3.0.0"
+//
+//
+// RUN: rm -rf %t/SDKs/WatchSimulator3.0.sdk
+// RUN: mkdir -p %t/SDKs/WatchSimulator3.0.sdk
+// RUN: env SDKROOT=%t/SDKs/WatchSimulator3.0.sdk %clang %s -### 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-WATCH-SIMULATOR %s
+//
+// CHECK-WATCH-SIMULATOR: clang
+// CHECK-WATCH-SIMULATOR: "-cc1"
+// CHECK-WATCH-SIMULATOR: -apple-watchos3.0.0-simulator"
+// CHECK-WATCH-SIMULATOR: ld
+// CHECK-WATCH-SIMULATOR: "-watchos_simulator_version_min" "3.0.0"
+//
+//
+// RUN: rm -rf %t/SDKs/AppleTVOS10.0.sdk
+// RUN: mkdir -p %t/SDKs/AppleTVOS10.0.sdk
+// RUN: env SDKROOT=%t/SDKs/AppleTVOS10.0.sdk %clang %s -### 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-TV %s
+//
+// CHECK-TV: clang
+// CHECK-TV: "-cc1"
+// CHECK-TV: -apple-tvos10.0.0"
+// CHECK-TV: ld
+// CHECK-TV: "-tvos_version_min" "10.0.0"
+//
+//
+// RUN: rm -rf %t/SDKs/AppleTVSimulator10.0.sdk
+// RUN: mkdir -p %t/SDKs/AppleTVSimulator10.0.sdk
+// RUN: env SDKROOT=%t/SDKs/AppleTVSimulator10.0.sdk %clang %s -### 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-TV-SIMULATOR %s
+//
+// CHECK-TV-SIMULATOR: clang
+// CHECK-TV-SIMULATOR: "-cc1"
+// CHECK-TV-SIMULATOR: -apple-tvos10.0.0-simulator"
+// CHECK-TV-SIMULATOR: ld
+// CHECK-TV-SIMULATOR: "-tvos_simulator_version_min" "10.0.0"

Modified: cfe/trunk/test/Driver/darwin-sdkroot.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/darwin-sdkroot.c?rev=329141=329140=329141=diff
==
--- cfe/trunk/test/Driver/darwin-sdkroot.c (original)
+++ cfe/trunk/test/Driver/darwin-sdkroot.c Tue Apr  3 19:11:20 2018
@@ -1,5 +1,4 @@
 // Check that SDKROOT is used to define the default for -isysroot on Darwin.
-// REQUIRES: system-darwin
 //
 // RUN: rm -rf %t.tmpdir
 // RUN: mkdir -p %t.tmpdir
@@ -52,21 +51,12 @@
 // CHECK-IPHONE: "-triple" "arm64-apple-ios8.0.0"
 // CHECK-IPHONE: ld
 // CHECK-IPHONE: "-iphoneos_version_min" "8.0.0"
-// RUN: env SDKROOT=%t/SDKs/iPhoneOS8.0.0.sdk %clang %s -### 2>&1 \
-// RUN:   | FileCheck --check-prefix=CHECK-IPHONE-X86 %s
-// CHECK-IPHONE-X86: clang
-// CHECK-IPHONE-X86: "-cc1"
-// CHECK-IPHONE-X86: -apple-ios8.0.0"
-// CHECK-IPHONE-X86: ld
-// CHECK-IPHONE-X86: "-iphoneos_version_min" "8.0.0"
 //
 //
 // RUN: rm -rf %t/SDKs/iPhoneSimulator8.0.sdk
 // RUN: mkdir -p %t/SDKs/iPhoneSimulator8.0.sdk
 // RUN: env SDKROOT=%t/SDKs/iPhoneSimulator8.0.sdk %clang -target 
x86_64-apple-darwin %s -### 2>&1 \
 // RUN:   | FileCheck --check-prefix=CHECK-SIMULATOR %s
-// RUN: env SDKROOT=%t/SDKs/iPhoneSimulator8.0.sdk %clang -arch x86_64 %s -### 
2>&1 \
-// RUN:   | FileCheck --check-prefix=CHECK-SIMULATOR %s
 //
 // 

[PATCH] D45240: [ARM] Compute a target feature which corresponds to the ARM version.

2018-04-03 Thread Eli Friedman via Phabricator via cfe-commits
efriedma created this revision.
efriedma added reviewers: compnerd, SjoerdMeijer, fhahn.
Herald added subscribers: kristof.beyls, javed.absar, mehdi_amini.

Currently, the interaction between the triple, the CPU, and the supported 
features is a mess: the driver edits the triple to indicate the supported 
architecture version, and the LLVM backend uses this to figure out what 
instructions are legal.  This makes it difficult to understand what's 
happening, and makes it impossible to LTO together two modules with different 
computed architectures.

Instead of relying on triple rewriting to get the correct target features, we 
should add the right target features explicitly.


Repository:
  rC Clang

https://reviews.llvm.org/D45240

Files:
  lib/Basic/Targets/ARM.cpp
  test/CodeGen/arm-long-calls.c
  test/CodeGen/arm-no-movt.c
  test/CodeGen/arm-target-features.c
  test/CodeGen/arm-thumb-mode-target-feature.c

Index: test/CodeGen/arm-thumb-mode-target-feature.c
===
--- test/CodeGen/arm-thumb-mode-target-feature.c
+++ test/CodeGen/arm-thumb-mode-target-feature.c
@@ -17,8 +17,8 @@
 // THUMB: void @t1() [[ThumbAttr:#[0-7]]]
 // THUMB: void @t2() [[NoThumbAttr:#[0-7]]]
 // THUMB: void @t3() [[ThumbAttr:#[0-7]]]
-// THUMB: attributes [[ThumbAttr]] = { {{.*}} "target-features"="+thumb-mode"
-// THUMB: attributes [[NoThumbAttr]] = { {{.*}} "target-features"="-thumb-mode"
+// THUMB: attributes [[ThumbAttr]] = { {{.*}} "target-features"="+thumb-mode,+v7"
+// THUMB: attributes [[NoThumbAttr]] = { {{.*}} "target-features"="+v7,-thumb-mode"
 //
 // THUMB-CLANG: void @t1() [[ThumbAttr:#[0-7]]]
 // THUMB-CLANG: void @t2() [[NoThumbAttr:#[0-7]]]
@@ -29,5 +29,5 @@
 // ARM: void @t1() [[NoThumbAtr:#[0-7]]]
 // ARM: void @t2() [[NoThumbAttr:#[0-7]]]
 // ARM: void @t3() [[ThumbAttr:#[0-7]]]
-// ARM: attributes [[NoThumbAttr]] = { {{.*}} "target-features"="-thumb-mode"
-// ARM: attributes [[ThumbAttr]] = { {{.*}} "target-features"="+thumb-mode"
+// ARM: attributes [[NoThumbAttr]] = { {{.*}} "target-features"="+v7,-thumb-mode"
+// ARM: attributes [[ThumbAttr]] = { {{.*}} "target-features"="+thumb-mode,+v7"
Index: test/CodeGen/arm-target-features.c
===
--- test/CodeGen/arm-target-features.c
+++ test/CodeGen/arm-target-features.c
@@ -1,22 +1,22 @@
 // REQUIRES: arm-registered-target
 
 // RUN: %clang_cc1 -triple thumbv7-linux-gnueabihf -target-cpu cortex-a8 -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-VFP3
-// CHECK-VFP3: "target-features"="+dsp,+neon,+thumb-mode
+// CHECK-VFP3: "target-features"="+dsp,+neon,+thumb-mode,+v7,+vfp3"
 
 
 // RUN: %clang_cc1 -triple thumbv7-linux-gnueabihf -target-cpu cortex-a5 -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-VFP4
-// CHECK-VFP4: "target-features"="+dsp,+neon,+thumb-mode,+vfp4"
+// CHECK-VFP4: "target-features"="+dsp,+neon,+thumb-mode,+v7,+vfp4"
 
 
 // RUN: %clang_cc1 -triple thumbv7-linux-gnueabihf -target-cpu cortex-a7 -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-VFP4-DIV
 // RUN: %clang_cc1 -triple thumbv7-linux-gnueabi -target-cpu cortex-a12 -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-VFP4-DIV
 // RUN: %clang_cc1 -triple thumbv7s-linux-gnueabi -target-cpu swift -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-VFP4-DIV
 // RUN: %clang_cc1 -triple thumbv7-linux-gnueabihf -target-cpu krait -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-VFP4-DIV
-// CHECK-VFP4-DIV: "target-features"="+dsp,+hwdiv,+hwdiv-arm,+neon,+thumb-mode,+vfp4"
+// CHECK-VFP4-DIV: "target-features"="+dsp,+hwdiv,+hwdiv-arm,+neon,+thumb-mode,+v7,+vfp4"
 
 // RUN: %clang_cc1 -triple armv7-linux-gnueabihf -target-cpu cortex-a15 -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-VFP4-DIV-ARM
 // RUN: %clang_cc1 -triple armv7-linux-gnueabihf -target-cpu cortex-a17 -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-VFP4-DIV-ARM
-// CHECK-VFP4-DIV-ARM: "target-features"="+dsp,+hwdiv,+hwdiv-arm,+neon,+vfp4,-thumb-mode"
+// CHECK-VFP4-DIV-ARM: "target-features"="+dsp,+hwdiv,+hwdiv-arm,+neon,+v7,+vfp4,-thumb-mode"
 
 // RUN: %clang_cc1 -triple thumbv7s-apple-ios7.0 -target-cpu cyclone -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-BASIC-V8
 // RUN: %clang_cc1 -triple thumbv8-linux-gnueabihf -target-cpu cortex-a32 -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-BASIC-V8
@@ -27,37 +27,37 @@
 // RUN: %clang_cc1 -triple thumbv8-linux-gnueabihf -target-cpu exynos-m1 -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-BASIC-V8
 // RUN: %clang_cc1 -triple thumbv8-linux-gnueabihf -target-cpu exynos-m2 -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-BASIC-V8
 // RUN: %clang_cc1 -triple thumbv8-linux-gnueabihf -target-cpu exynos-m3 -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-BASIC-V8
-// CHECK-BASIC-V8: "target-features"="+crc,+crypto,+dsp,+fp-armv8,+hwdiv,+hwdiv-arm,+neon,+thumb-mode"
+// CHECK-BASIC-V8: 

[PATCH] D45121: [coroutines] Add noop_coroutine to

2018-04-03 Thread Lewis Baker via Phabricator via cfe-commits
lewissbaker accepted this revision.
lewissbaker added a comment.
This revision is now accepted and ready to land.

The `coroutine_handle` type does not have a 
`from_address()` or a `from_promise()` static functions in the same way that 
the `coroutine_handle` implementation does.
Is this intentional or an oversight in the TS wording?

They don't seem hugely useful, so I'm not that worried.
If you know that you have a `coroutine_handle` then you 
can just use `noop_coroutine()` to get the handle instead.




Comment at: 
test/std/experimental/language.support/support.coroutines/coroutine.handle/coroutine.handle.noop/noop_coroutine.pass.cpp:62
+  assert(h.address() != nullptr);
+}
+

Maybe also add a test for `from_address()`?
eg. `assert(coroutine_handle<>::from_address(h.address()) == base);`


https://reviews.llvm.org/D45121



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


[PATCH] D45239: AArch64: Implement support for the shadowcallstack attribute.

2018-04-03 Thread Peter Collingbourne via Phabricator via cfe-commits
pcc created this revision.
pcc added reviewers: vlad.tsyrklevich, eugenis, kcc, t.p.northover, olista01.
Herald added subscribers: hiraditya, kristof.beyls, javed.absar, rengolin.

The implementation of shadow call stack on aarch64 is quite different to
the implementation on x86_64. Instead of reserving a segment register for
the shadow call stack, we reserve the platform register, x18. Any function
that spills lr to sp also spills it to the shadow call stack, a pointer to
which is stored in x18.


https://reviews.llvm.org/D45239

Files:
  clang/docs/ShadowCallStack.rst
  clang/lib/Driver/SanitizerArgs.cpp
  clang/lib/Driver/ToolChain.cpp
  clang/test/Driver/sanitizer-ld.c
  llvm/include/llvm/Support/TargetParser.h
  llvm/lib/Support/TargetParser.cpp
  llvm/lib/Target/AArch64/AArch64CallingConvention.td
  llvm/lib/Target/AArch64/AArch64FrameLowering.cpp
  llvm/lib/Target/AArch64/AArch64RegisterInfo.cpp
  llvm/lib/Target/AArch64/AArch64Subtarget.cpp
  llvm/test/CodeGen/AArch64/shadow-call-stack.ll

Index: llvm/test/CodeGen/AArch64/shadow-call-stack.ll
===
--- /dev/null
+++ llvm/test/CodeGen/AArch64/shadow-call-stack.ll
@@ -0,0 +1,47 @@
+; RUN: llc -verify-machineinstrs -o - %s -mtriple=aarch64-linux-gnu -mattr=+reserve-x18 | FileCheck %s
+
+define void @f1() shadowcallstack {
+  ; CHECK: f1:
+  ; CHECK-NOT: x18
+  ; CHECK: ret
+  ret void
+}
+
+declare void @foo()
+
+define void @f2() shadowcallstack {
+  ; CHECK: f2:
+  ; CHECK-NOT: x18
+  ; CHECK: b foo
+  tail call void @foo()
+  ret void
+}
+
+declare i32 @bar()
+
+define i32 @f3() shadowcallstack {
+  ; CHECK: f3:
+  ; CHECK: str x30, [x18], #8
+  ; CHECK: str x30, [sp, #-16]!
+  %res = call i32 @bar()
+  %res1 = add i32 %res, 1
+  ; CHECK: ldr x30, [sp], #16
+  ; CHECK: ldr x30, [x18, #-8]!
+  ; CHECK: ret
+  ret i32 %res
+}
+
+define i32 @f4() shadowcallstack {
+  ; CHECK: f4:
+  %res1 = call i32 @bar()
+  %res2 = call i32 @bar()
+  %res3 = call i32 @bar()
+  %res4 = call i32 @bar()
+  %res12 = add i32 %res1, %res2
+  %res34 = add i32 %res3, %res4
+  %res1234 = add i32 %res12, %res34
+  ; CHECK: ldp {{.*}}x30, [sp
+  ; CHECK: ldr x30, [x18, #-8]!
+  ; CHECK: ret
+  ret i32 %res1234
+}
Index: llvm/lib/Target/AArch64/AArch64Subtarget.cpp
===
--- llvm/lib/Target/AArch64/AArch64Subtarget.cpp
+++ llvm/lib/Target/AArch64/AArch64Subtarget.cpp
@@ -24,6 +24,7 @@
 #include "llvm/CodeGen/GlobalISel/InstructionSelect.h"
 #include "llvm/CodeGen/MachineScheduler.h"
 #include "llvm/IR/GlobalValue.h"
+#include "llvm/Support/TargetParser.h"
 
 using namespace llvm;
 
@@ -151,8 +152,8 @@
const std::string ,
const TargetMachine , bool LittleEndian)
 : AArch64GenSubtargetInfo(TT, CPU, FS),
-  ReserveX18(TT.isOSDarwin() || TT.isOSFuchsia() || TT.isOSWindows()),
-  IsLittle(LittleEndian), TargetTriple(TT), FrameLowering(),
+  ReserveX18(AArch64::isX18ReservedByDefault(TT)), IsLittle(LittleEndian),
+  TargetTriple(TT), FrameLowering(),
   InstrInfo(initializeSubtargetDependencies(FS, CPU)), TSInfo(),
   TLInfo(TM, *this) {
   CallLoweringInfo.reset(new AArch64CallLowering(*getTargetLowering()));
Index: llvm/lib/Target/AArch64/AArch64RegisterInfo.cpp
===
--- llvm/lib/Target/AArch64/AArch64RegisterInfo.cpp
+++ llvm/lib/Target/AArch64/AArch64RegisterInfo.cpp
@@ -75,21 +75,25 @@
 const uint32_t *
 AArch64RegisterInfo::getCallPreservedMask(const MachineFunction ,
   CallingConv::ID CC) const {
+  bool SCS = MF.getFunction().hasFnAttribute(Attribute::ShadowCallStack);
   if (CC == CallingConv::GHC)
 // This is academic because all GHC calls are (supposed to be) tail calls
-return CSR_AArch64_NoRegs_RegMask;
+return SCS ? CSR_AArch64_NoRegs_SCS_RegMask : CSR_AArch64_NoRegs_RegMask;
   if (CC == CallingConv::AnyReg)
-return CSR_AArch64_AllRegs_RegMask;
+return SCS ? CSR_AArch64_AllRegs_SCS_RegMask : CSR_AArch64_AllRegs_RegMask;
   if (CC == CallingConv::CXX_FAST_TLS)
-return CSR_AArch64_CXX_TLS_Darwin_RegMask;
+return SCS ? CSR_AArch64_CXX_TLS_Darwin_SCS_RegMask
+   : CSR_AArch64_CXX_TLS_Darwin_RegMask;
   if (MF.getSubtarget().getTargetLowering()
   ->supportSwiftError() &&
   MF.getFunction().getAttributes().hasAttrSomewhere(Attribute::SwiftError))
-return CSR_AArch64_AAPCS_SwiftError_RegMask;
+return SCS ? CSR_AArch64_AAPCS_SwiftError_SCS_RegMask
+   : CSR_AArch64_AAPCS_SwiftError_RegMask;
   if (CC == CallingConv::PreserveMost)
-return CSR_AArch64_RT_MostRegs_RegMask;
+return SCS ? CSR_AArch64_RT_MostRegs_SCS_RegMask
+   : CSR_AArch64_RT_MostRegs_RegMask;
   else
-return CSR_AArch64_AAPCS_RegMask;
+return SCS ? CSR_AArch64_AAPCS_SCS_RegMask : 

[PATCH] D32411: [libcxx] Provide #include_next alternative for MSVC

2018-04-03 Thread Eric Fiselier via Phabricator via cfe-commits
EricWF added a comment.
Herald added a subscriber: christof.

I spoke to STL on the MSVC team a while ago, and he stated that if we produced 
a paper describing why we need `#include_next` and the rational behind it, and 
they would pass that on to the front-end team. They didn't guarantee that they 
would implement it, but that seems like a good first step.


https://reviews.llvm.org/D32411



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


[PATCH] D44411: [libc++] Fix Container::insert(value_type const&) tests

2018-04-03 Thread Eric Fiselier via Phabricator via cfe-commits
EricWF added a comment.

Have you verified that we're not losing test coverage here? That is, are you 
sure we still have tests for the rvalue overloads in other test files?




Comment at: 
libcxx/test/std/containers/associative/multiset/insert_cv.pass.cpp:41
+const VT v3(3);
+r = m.insert(3);
+assert(r == prev(m.end()));

Should be `v3`?


Repository:
  rCXX libc++

https://reviews.llvm.org/D44411



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


[PATCH] D45015: [Preprocessor] Allow libc++ to detect when aligned allocation is unavailable.

2018-04-03 Thread Eric Fiselier via Phabricator via cfe-commits
EricWF added a comment.

Ping. I would like to get a way for libc++ to detect this case before the next 
release.


Repository:
  rC Clang

https://reviews.llvm.org/D45015



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


[PATCH] D40218: [Clang] Add __builtin_launder

2018-04-03 Thread Eric Fiselier via Phabricator via cfe-commits
EricWF added a comment.

Ping.


https://reviews.llvm.org/D40218



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


[PATCH] D44883: [Sema] Extend -Wself-assign and -Wself-assign-field to warn on overloaded self-assignment (classes)

2018-04-03 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added a comment.

In https://reviews.llvm.org/D44883#1054326, @thakis wrote:

> In https://reviews.llvm.org/D44883#1048751, @dblaikie wrote:
>
> > Historically Clang's policy on warnings was, I think, much more
> >  conservative than it seems to be today. There was a strong desire not to
> >  implement off-by-default warnings, and to have warnings with an
> >  exceptionally low false-positive rate - maybe the user-defined operator
> >  detection was either assumed to, or demonstrated to, have a sufficiently
> >  high false positive rate to not meet that high bar.
>
>
> This is still the case. For a new warning, you should evaluate some large 
> open-source codebase and measure true positive and false positive rate and 
> post the numbers here.


Just finished running it on chrome: (wow, that took a while!)

  $ cat /tmp/test.cpp 
  struct S {};
  
  void test (S a) {
a = a;
  }
  $ /build/llvm-build-Clang-release/bin/clang++ -c /tmp/test.cpp -Wall
  /tmp/test.cpp:4:5: warning: explicitly assigning value of variable of type 
'S' to itself [-Wself-assign]
a = a;
~ ^ ~
  1 warning generated.
  $ ninja -C out/ClangStage2 chrome
  ninja: Entering directory `out/ClangStage2'
  [31309/31309] LINK ./chrome

Config: F5937598: args.gn 

So unless the config ^ is wrong, there have been no occurrences, no 
false-positives.

Down to one [trivial] prerequisite - https://reviews.llvm.org/D45082 - would be 
super nice if someone could review/accept it :)


Repository:
  rC Clang

https://reviews.llvm.org/D44883



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


[PATCH] D45237: [RISCV] Fix logic check if frame pointer should be used

2018-04-03 Thread Mandeep Singh Grang via Phabricator via cfe-commits
mgrang added a comment.

@asb Should we keep frame pointer enabled for debug builds? Internally, for 
ARM/Thumb we leave frame pointer ON if debug is enabled.


Repository:
  rC Clang

https://reviews.llvm.org/D45237



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


Re: r329110 - [driver][darwin] Do not infer -simulator environment for non-simulator SDKs

2018-04-03 Thread Chandler Carruth via cfe-commits
On Tue, Apr 3, 2018 at 4:01 PM Alex L via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> On 3 April 2018 at 14:30, Chandler Carruth  wrote:
>
>> On Tue, Apr 3, 2018 at 1:52 PM Alex Lorenz via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: arphaman
>>> Date: Tue Apr  3 13:50:05 2018
>>> New Revision: 329110
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=329110=rev
>>> Log:
>>> [driver][darwin] Do not infer -simulator environment for non-simulator
>>> SDKs
>>>
>>
>> I know you added a REQUIRES line to these tests, but I think there is a
>> much better way:
>>
>>
>>> --- cfe/trunk/test/Driver/darwin-sdkroot.c (original)
>>> +++ cfe/trunk/test/Driver/darwin-sdkroot.c Tue Apr  3 13:50:05 2018
>>> @@ -51,12 +51,21 @@
>>>  // CHECK-IPHONE: "-triple" "arm64-apple-ios8.0.0"
>>>  // CHECK-IPHONE: ld
>>>  // CHECK-IPHONE: "-iphoneos_version_min" "8.0.0"
>>> +// RUN: env SDKROOT=%t/SDKs/iPhoneOS8.0.0.sdk %clang %s -### 2>&1 \
>>>
>>
>> Instead of just running %clang, actually pass the `-target` you want to
>> it like we do in the below invocation and the other invocations in this
>> file.
>>
>> We shouldn't lose driver testing on other systems as long as you can
>> specify the desired target.
>>
>
>
> Hi Chandler!
>
> Thanks for pointing this out! We actually can't use -target here because
> when -target is specified, Darwin's driver won't infer the triple's
> environment from the SDKROOT. So this test covers the path in the driver
> that won't be taken when -target is specified.
>

Ah, I see, that's where the inference is triggered. Sure.


>
> You've made a good point about losing testing though. I can split out this
> test into the original file (with -target use) and the new tests which
> can't use -target and are Darwin specific to ensure we won't loose the
> existing coverage. I will commit a follow-up commit that does this.
>

Sure, makes sense to factor out inference-based tests where possible and
cover as much as you can w/o inference.

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


[PATCH] D45237: [RISCV] Fix logic check if frame pointer should be used

2018-04-03 Thread Mandeep Singh Grang via Phabricator via cfe-commits
mgrang created this revision.
mgrang added a reviewer: asb.
Herald added subscribers: shiva0217, kito-cheng.

The logic was broken for Linux triples as it returns true in the switch for 
Triple.isOSLinux().


Repository:
  rC Clang

https://reviews.llvm.org/D45237

Files:
  lib/Driver/ToolChains/Clang.cpp


Index: lib/Driver/ToolChains/Clang.cpp
===
--- lib/Driver/ToolChains/Clang.cpp
+++ lib/Driver/ToolChains/Clang.cpp
@@ -529,6 +529,9 @@
 // XCore never wants frame pointers, regardless of OS.
 // WebAssembly never wants frame pointers.
 return false;
+  case llvm::Triple::riscv32:
+  case llvm::Triple::riscv64:
+return !areOptimizationsEnabled(Args);
   default:
 break;
   }
@@ -552,14 +555,6 @@
 }
   }
 
-  switch (Triple.getArch()) {
-case llvm::Triple::riscv32:
-case llvm::Triple::riscv64:
-  return !areOptimizationsEnabled(Args);
-default:
-  break;
-  }
-
   if (Triple.isOSWindows()) {
 switch (Triple.getArch()) {
 case llvm::Triple::x86:


Index: lib/Driver/ToolChains/Clang.cpp
===
--- lib/Driver/ToolChains/Clang.cpp
+++ lib/Driver/ToolChains/Clang.cpp
@@ -529,6 +529,9 @@
 // XCore never wants frame pointers, regardless of OS.
 // WebAssembly never wants frame pointers.
 return false;
+  case llvm::Triple::riscv32:
+  case llvm::Triple::riscv64:
+return !areOptimizationsEnabled(Args);
   default:
 break;
   }
@@ -552,14 +555,6 @@
 }
   }
 
-  switch (Triple.getArch()) {
-case llvm::Triple::riscv32:
-case llvm::Triple::riscv64:
-  return !areOptimizationsEnabled(Args);
-default:
-  break;
-  }
-
   if (Triple.isOSWindows()) {
 switch (Triple.getArch()) {
 case llvm::Triple::x86:
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D45233: [Driver] Update GCC libraries detection logic for Gentoo.

2018-04-03 Thread Manoj Gupta via Phabricator via cfe-commits
manojgupta added a reviewer: chandlerc.
manojgupta added a comment.

Chandler, I recall that you are also a Gentoo user so please take a look.


Repository:
  rC Clang

https://reviews.llvm.org/D45233



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


Re: r329110 - [driver][darwin] Do not infer -simulator environment for non-simulator SDKs

2018-04-03 Thread Alex L via cfe-commits
On 3 April 2018 at 14:30, Chandler Carruth  wrote:

> On Tue, Apr 3, 2018 at 1:52 PM Alex Lorenz via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: arphaman
>> Date: Tue Apr  3 13:50:05 2018
>> New Revision: 329110
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=329110=rev
>> Log:
>> [driver][darwin] Do not infer -simulator environment for non-simulator
>> SDKs
>>
>
> I know you added a REQUIRES line to these tests, but I think there is a
> much better way:
>
>
>> --- cfe/trunk/test/Driver/darwin-sdkroot.c (original)
>> +++ cfe/trunk/test/Driver/darwin-sdkroot.c Tue Apr  3 13:50:05 2018
>> @@ -51,12 +51,21 @@
>>  // CHECK-IPHONE: "-triple" "arm64-apple-ios8.0.0"
>>  // CHECK-IPHONE: ld
>>  // CHECK-IPHONE: "-iphoneos_version_min" "8.0.0"
>> +// RUN: env SDKROOT=%t/SDKs/iPhoneOS8.0.0.sdk %clang %s -### 2>&1 \
>>
>
> Instead of just running %clang, actually pass the `-target` you want to it
> like we do in the below invocation and the other invocations in this file.
>
> We shouldn't lose driver testing on other systems as long as you can
> specify the desired target.
>


Hi Chandler!

Thanks for pointing this out! We actually can't use -target here because
when -target is specified, Darwin's driver won't infer the triple's
environment from the SDKROOT. So this test covers the path in the driver
that won't be taken when -target is specified.

You've made a good point about losing testing though. I can split out this
test into the original file (with -target use) and the new tests which
can't use -target and are Darwin specific to ensure we won't loose the
existing coverage. I will commit a follow-up commit that does this.

Cheers,
Alex




>
>
>> +// RUN:   | FileCheck --check-prefix=CHECK-IPHONE-X86 %s
>> +// CHECK-IPHONE-X86: clang
>> +// CHECK-IPHONE-X86: "-cc1"
>> +// CHECK-IPHONE-X86: -apple-ios8.0.0"
>> +// CHECK-IPHONE-X86: ld
>> +// CHECK-IPHONE-X86: "-iphoneos_version_min" "8.0.0"
>>  //
>>  //
>>  // RUN: rm -rf %t/SDKs/iPhoneSimulator8.0.sdk
>>  // RUN: mkdir -p %t/SDKs/iPhoneSimulator8.0.sdk
>>  // RUN: env SDKROOT=%t/SDKs/iPhoneSimulator8.0.sdk %clang -target
>> x86_64-apple-darwin %s -### 2>&1 \
>>  // RUN:   | FileCheck --check-prefix=CHECK-SIMULATOR %s
>> +// RUN: env SDKROOT=%t/SDKs/iPhoneSimulator8.0.sdk %clang -arch x86_64
>> %s -### 2>&1 \
>> +// RUN:   | FileCheck --check-prefix=CHECK-SIMULATOR %s
>>  //
>>  // CHECK-SIMULATOR: clang
>>  // CHECK-SIMULATOR: "-cc1"
>> @@ -74,3 +83,49 @@
>>  // CHECK-MACOSX: "-triple" "x86_64-apple-macosx10.10.0"
>>  // CHECK-MACOSX: ld
>>  // CHECK-MACOSX: "-macosx_version_min" "10.10.0"
>> +
>> +// RUN: rm -rf %t/SDKs/WatchOS3.0.sdk
>> +// RUN: mkdir -p %t/SDKs/WatchOS3.0.sdk
>> +// RUN: env SDKROOT=%t/SDKs/WatchOS3.0.sdk %clang %s -### 2>&1 \
>> +// RUN:   | FileCheck --check-prefix=CHECK-WATCH %s
>> +//
>> +// CHECK-WATCH: clang
>> +// CHECK-WATCH: "-cc1"
>> +// CHECK-WATCH: -apple-watchos3.0.0"
>> +// CHECK-WATCH: ld
>> +// CHECK-WATCH: "-watchos_version_min" "3.0.0"
>> +//
>> +//
>> +// RUN: rm -rf %t/SDKs/WatchSimulator3.0.sdk
>> +// RUN: mkdir -p %t/SDKs/WatchSimulator3.0.sdk
>> +// RUN: env SDKROOT=%t/SDKs/WatchSimulator3.0.sdk %clang %s -### 2>&1 \
>> +// RUN:   | FileCheck --check-prefix=CHECK-WATCH-SIMULATOR %s
>> +//
>> +// CHECK-WATCH-SIMULATOR: clang
>> +// CHECK-WATCH-SIMULATOR: "-cc1"
>> +// CHECK-WATCH-SIMULATOR: -apple-watchos3.0.0-simulator"
>> +// CHECK-WATCH-SIMULATOR: ld
>> +// CHECK-WATCH-SIMULATOR: "-watchos_simulator_version_min" "3.0.0"
>> +
>> +// RUN: rm -rf %t/SDKs/AppleTVOS10.0.sdk
>> +// RUN: mkdir -p %t/SDKs/AppleTVOS10.0.sdk
>> +// RUN: env SDKROOT=%t/SDKs/AppleTVOS10.0.sdk %clang %s -### 2>&1 \
>> +// RUN:   | FileCheck --check-prefix=CHECK-TV %s
>> +//
>> +// CHECK-TV: clang
>> +// CHECK-TV: "-cc1"
>> +// CHECK-TV: -apple-tvos10.0.0"
>> +// CHECK-TV: ld
>> +// CHECK-TV: "-tvos_version_min" "10.0.0"
>> +//
>> +//
>> +// RUN: rm -rf %t/SDKs/AppleTVSimulator10.0.sdk
>> +// RUN: mkdir -p %t/SDKs/AppleTVSimulator10.0.sdk
>> +// RUN: env SDKROOT=%t/SDKs/AppleTVSimulator10.0.sdk %clang %s -###
>> 2>&1 \
>> +// RUN:   | FileCheck --check-prefix=CHECK-TV-SIMULATOR %s
>> +//
>> +// CHECK-TV-SIMULATOR: clang
>> +// CHECK-TV-SIMULATOR: "-cc1"
>> +// CHECK-TV-SIMULATOR: -apple-tvos10.0.0-simulator"
>> +// CHECK-TV-SIMULATOR: ld
>> +// CHECK-TV-SIMULATOR: "-tvos_simulator_version_min" "10.0.0"
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D45233: [Driver] Update GCC libraries detection logic for Gentoo.

2018-04-03 Thread Manoj Gupta via Phabricator via cfe-commits
manojgupta added a comment.

Michał, will appreciate if you can test this on your (multiple?) Gentoo 
configurations.
Will work on updating the testcases after that.

To test it locally, I used the following :

$ cat test.cpp

  #include 
  #include 
  
  int main() {
std::cout << " Hello, World!" << std::endl;
return 0;
  }



Setup cross compilers for x86_64 and aarch64.
=

$ sudo crossdev -S x86_64-gentoo-linux-gnu
$ sudo crossdev -S aarch64-gentoo-linux-gnu

$ Build and install clang in a location other than /usr/bin e.g. 
$HOME/clang-testing/bin
Verify that correct gcc libs are picked.
$ /path/to/clang++ --sysroot=/usr/aarch64-gentoo-linux-gnu 
-B/usr/libexec/gcc/aarch64-gentoo-linux-gnu -target aarch64-gentoo-linux-gnu 
test.cpp -o main -Wl,-t -v

Further verify that any lib/headers from x86_64-pc-linux-gnu are NOT picked 
after the patch is applied.
$ /path/to/clang++ --sysroot=/usr/x86_64-gentoo-linux-gnu 
-B/usr/libexec/gcc/x86_64-gentoo-linux-gnu -target x86_64-gentoo-linux-gnu 
test.cpp -o main -Wl,-t -v


Repository:
  rC Clang

https://reviews.llvm.org/D45233



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


[PATCH] D45101: [ObjC] Use the name specified by objc_runtime_name instead of the class identifier

2018-04-03 Thread Akira Hatanaka via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL329128: [ObjC] Use the name specified by objc_runtime_name 
instead of the class (authored by ahatanak, committed by ).
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D45101?vs=140461=140876#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D45101

Files:
  cfe/trunk/lib/CodeGen/CGObjCMac.cpp
  cfe/trunk/test/CodeGenObjC/objc-runtime-name.m


Index: cfe/trunk/test/CodeGenObjC/objc-runtime-name.m
===
--- cfe/trunk/test/CodeGenObjC/objc-runtime-name.m
+++ cfe/trunk/test/CodeGenObjC/objc-runtime-name.m
@@ -0,0 +1,24 @@
+// RUN: %clang_cc1 -triple i386-apple-macosx10.13.0 
-fobjc-runtime=macosx-fragile-10.13.0 -fobjc-subscripting-legacy-runtime 
-emit-llvm -o - %s | FileCheck %s
+
+// Check that the runtime name is emitted and used instead of the class
+// identifier.
+
+// CHECK: module asm {{.*}}objc_class_name_XYZ=0
+// CHECK: module asm {{.*}}globl .objc_class_name_XYZ
+// CHECK: module asm {{.*}}lazy_reference .objc_class_name_XYZ
+
+// CHECK: @[[OBJC_CLASS_NAME:.*]] = private unnamed_addr constant [4 x i8] 
c"XYZ{{.*}}, section "__TEXT,__cstring,cstring_literals",
+// CHECK: = private global {{.*}} bitcast ([4 x i8]* @[[OBJC_CLASS_NAME]] to 
{{.*}}), section "__OBJC,__cls_refs,literal_pointers,no_dead_strip"
+
+__attribute__((objc_root_class,objc_runtime_name("XYZ")))
+@interface A
++(void)m1;
+@end
+
+@implementation A
++(void)m1 {}
+@end
+
+void test(void) {
+  [A m1];
+}
Index: cfe/trunk/lib/CodeGen/CGObjCMac.cpp
===
--- cfe/trunk/lib/CodeGen/CGObjCMac.cpp
+++ cfe/trunk/lib/CodeGen/CGObjCMac.cpp
@@ -3401,7 +3401,9 @@
   See EmitClassExtension();
 */
 void CGObjCMac::GenerateClass(const ObjCImplementationDecl *ID) {
-  DefinedSymbols.insert(ID->getIdentifier());
+  IdentifierInfo *RuntimeName =
+  ().Idents.get(ID->getObjCRuntimeNameAsString());
+  DefinedSymbols.insert(RuntimeName);
 
   std::string ClassName = ID->getNameAsString();
   // FIXME: Gross
@@ -4980,7 +4982,9 @@
   if (ID->hasAttr())
 return EmitClassRefViaRuntime(CGF, ID, ObjCTypes);
 
-  return EmitClassRefFromId(CGF, ID->getIdentifier());
+  IdentifierInfo *RuntimeName =
+  ().Idents.get(ID->getObjCRuntimeNameAsString());
+  return EmitClassRefFromId(CGF, RuntimeName);
 }
 
 llvm::Value *CGObjCMac::EmitNSAutoreleasePoolClassRef(CodeGenFunction ) {


Index: cfe/trunk/test/CodeGenObjC/objc-runtime-name.m
===
--- cfe/trunk/test/CodeGenObjC/objc-runtime-name.m
+++ cfe/trunk/test/CodeGenObjC/objc-runtime-name.m
@@ -0,0 +1,24 @@
+// RUN: %clang_cc1 -triple i386-apple-macosx10.13.0 -fobjc-runtime=macosx-fragile-10.13.0 -fobjc-subscripting-legacy-runtime -emit-llvm -o - %s | FileCheck %s
+
+// Check that the runtime name is emitted and used instead of the class
+// identifier.
+
+// CHECK: module asm {{.*}}objc_class_name_XYZ=0
+// CHECK: module asm {{.*}}globl .objc_class_name_XYZ
+// CHECK: module asm {{.*}}lazy_reference .objc_class_name_XYZ
+
+// CHECK: @[[OBJC_CLASS_NAME:.*]] = private unnamed_addr constant [4 x i8] c"XYZ{{.*}}, section "__TEXT,__cstring,cstring_literals",
+// CHECK: = private global {{.*}} bitcast ([4 x i8]* @[[OBJC_CLASS_NAME]] to {{.*}}), section "__OBJC,__cls_refs,literal_pointers,no_dead_strip"
+
+__attribute__((objc_root_class,objc_runtime_name("XYZ")))
+@interface A
++(void)m1;
+@end
+
+@implementation A
++(void)m1 {}
+@end
+
+void test(void) {
+  [A m1];
+}
Index: cfe/trunk/lib/CodeGen/CGObjCMac.cpp
===
--- cfe/trunk/lib/CodeGen/CGObjCMac.cpp
+++ cfe/trunk/lib/CodeGen/CGObjCMac.cpp
@@ -3401,7 +3401,9 @@
   See EmitClassExtension();
 */
 void CGObjCMac::GenerateClass(const ObjCImplementationDecl *ID) {
-  DefinedSymbols.insert(ID->getIdentifier());
+  IdentifierInfo *RuntimeName =
+  ().Idents.get(ID->getObjCRuntimeNameAsString());
+  DefinedSymbols.insert(RuntimeName);
 
   std::string ClassName = ID->getNameAsString();
   // FIXME: Gross
@@ -4980,7 +4982,9 @@
   if (ID->hasAttr())
 return EmitClassRefViaRuntime(CGF, ID, ObjCTypes);
 
-  return EmitClassRefFromId(CGF, ID->getIdentifier());
+  IdentifierInfo *RuntimeName =
+  ().Idents.get(ID->getObjCRuntimeNameAsString());
+  return EmitClassRefFromId(CGF, RuntimeName);
 }
 
 llvm::Value *CGObjCMac::EmitNSAutoreleasePoolClassRef(CodeGenFunction ) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r329128 - [ObjC] Use the name specified by objc_runtime_name instead of the class

2018-04-03 Thread Akira Hatanaka via cfe-commits
Author: ahatanak
Date: Tue Apr  3 15:50:16 2018
New Revision: 329128

URL: http://llvm.org/viewvc/llvm-project?rev=329128=rev
Log:
[ObjC] Use the name specified by objc_runtime_name instead of the class
identifier.

This patch fixes a few places in CGObjCMac.cpp where the class
identifier was used instead of the name specified by objc_runtime_name.

rdar://problem/37910822

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

Added:
cfe/trunk/test/CodeGenObjC/objc-runtime-name.m
Modified:
cfe/trunk/lib/CodeGen/CGObjCMac.cpp

Modified: cfe/trunk/lib/CodeGen/CGObjCMac.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGObjCMac.cpp?rev=329128=329127=329128=diff
==
--- cfe/trunk/lib/CodeGen/CGObjCMac.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGObjCMac.cpp Tue Apr  3 15:50:16 2018
@@ -3401,7 +3401,9 @@ static bool hasMRCWeakIvars(CodeGenModul
   See EmitClassExtension();
 */
 void CGObjCMac::GenerateClass(const ObjCImplementationDecl *ID) {
-  DefinedSymbols.insert(ID->getIdentifier());
+  IdentifierInfo *RuntimeName =
+  ().Idents.get(ID->getObjCRuntimeNameAsString());
+  DefinedSymbols.insert(RuntimeName);
 
   std::string ClassName = ID->getNameAsString();
   // FIXME: Gross
@@ -4980,7 +4982,9 @@ llvm::Value *CGObjCMac::EmitClassRef(Cod
   if (ID->hasAttr())
 return EmitClassRefViaRuntime(CGF, ID, ObjCTypes);
 
-  return EmitClassRefFromId(CGF, ID->getIdentifier());
+  IdentifierInfo *RuntimeName =
+  ().Idents.get(ID->getObjCRuntimeNameAsString());
+  return EmitClassRefFromId(CGF, RuntimeName);
 }
 
 llvm::Value *CGObjCMac::EmitNSAutoreleasePoolClassRef(CodeGenFunction ) {

Added: cfe/trunk/test/CodeGenObjC/objc-runtime-name.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenObjC/objc-runtime-name.m?rev=329128=auto
==
--- cfe/trunk/test/CodeGenObjC/objc-runtime-name.m (added)
+++ cfe/trunk/test/CodeGenObjC/objc-runtime-name.m Tue Apr  3 15:50:16 2018
@@ -0,0 +1,24 @@
+// RUN: %clang_cc1 -triple i386-apple-macosx10.13.0 
-fobjc-runtime=macosx-fragile-10.13.0 -fobjc-subscripting-legacy-runtime 
-emit-llvm -o - %s | FileCheck %s
+
+// Check that the runtime name is emitted and used instead of the class
+// identifier.
+
+// CHECK: module asm {{.*}}objc_class_name_XYZ=0
+// CHECK: module asm {{.*}}globl .objc_class_name_XYZ
+// CHECK: module asm {{.*}}lazy_reference .objc_class_name_XYZ
+
+// CHECK: @[[OBJC_CLASS_NAME:.*]] = private unnamed_addr constant [4 x i8] 
c"XYZ{{.*}}, section "__TEXT,__cstring,cstring_literals",
+// CHECK: = private global {{.*}} bitcast ([4 x i8]* @[[OBJC_CLASS_NAME]] to 
{{.*}}), section "__OBJC,__cls_refs,literal_pointers,no_dead_strip"
+
+__attribute__((objc_root_class,objc_runtime_name("XYZ")))
+@interface A
++(void)m1;
+@end
+
+@implementation A
++(void)m1 {}
+@end
+
+void test(void) {
+  [A m1];
+}


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


[PATCH] D45128: [libcxx][test] Silence -Wself-assign diagnostics

2018-04-03 Thread Eric Fiselier via Phabricator via cfe-commits
EricWF accepted this revision.
EricWF added a comment.
This revision is now accepted and ready to land.

LGTM. Perhaps we could add a comment for the first such occurrence of the cast 
in each file explaining it.


Repository:
  rCXX libc++

https://reviews.llvm.org/D45128



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


[PATCH] D45234: CMake: Check LLVM_ENABLE_LIBXML2 in clang

2018-04-03 Thread Stephen Crane via Phabricator via cfe-commits
rinon created this revision.
rinon added reviewers: hans, rnk.
Herald added subscribers: cfe-commits, mgorny.

If LLVM_ENABLE_LIBXML2=OFF, we should not attempt to link clang against
libxml2.


Repository:
  rC Clang

https://reviews.llvm.org/D45234

Files:
  CMakeLists.txt


Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -86,6 +86,11 @@
   option(LLVM_INSTALL_TOOLCHAIN_ONLY
 "Only include toolchain files in the 'install' target." OFF)
 
+  # Ensure that LLVM_ENABLE_LIBXML2 is set for standalone builds
+  if(NOT DEFINED LLVM_ENABLE_LIBXML2)
+set(LLVM_ENABLE_LIBXML2 "ON" CACHE STRING "Use libxml2 if available. Can 
be ON, OFF, or FORCE_ON")
+  endif()
+
   option(LLVM_FORCE_USE_OLD_HOST_TOOLCHAIN
 "Set to ON to force using an old, unsupported host toolchain." OFF)
   option(CLANG_ENABLE_BOOTSTRAP "Generate the clang bootstrap target" OFF)
@@ -186,14 +191,18 @@
 
 # Don't look for libxml if we're using MSan, since uninstrumented third party
 # code may call MSan interceptors like strlen, leading to false positives.
-if(NOT LLVM_USE_SANITIZER MATCHES "Memory.*")
+if((LLVM_ENABLE_LIBXML2) AND (NOT LLVM_USE_SANITIZER MATCHES "Memory.*"))
   set (LIBXML2_FOUND 0)
   find_package(LibXml2 2.5.3 QUIET)
   if (LIBXML2_FOUND)
 set(CLANG_HAVE_LIBXML 1)
   endif()
 endif()
 
+if (LLVM_ENABLE_LIBXML2 STREQUAL "FORCE_ON" AND NOT CLANG_HAVE_LIBXML)
+  message(FATAL_ERROR "Failed to configure libxml2")
+endif()
+
 include(CheckIncludeFile)
 check_include_file(sys/resource.h CLANG_HAVE_RLIMITS)
 


Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -86,6 +86,11 @@
   option(LLVM_INSTALL_TOOLCHAIN_ONLY
 "Only include toolchain files in the 'install' target." OFF)
 
+  # Ensure that LLVM_ENABLE_LIBXML2 is set for standalone builds
+  if(NOT DEFINED LLVM_ENABLE_LIBXML2)
+set(LLVM_ENABLE_LIBXML2 "ON" CACHE STRING "Use libxml2 if available. Can be ON, OFF, or FORCE_ON")
+  endif()
+
   option(LLVM_FORCE_USE_OLD_HOST_TOOLCHAIN
 "Set to ON to force using an old, unsupported host toolchain." OFF)
   option(CLANG_ENABLE_BOOTSTRAP "Generate the clang bootstrap target" OFF)
@@ -186,14 +191,18 @@
 
 # Don't look for libxml if we're using MSan, since uninstrumented third party
 # code may call MSan interceptors like strlen, leading to false positives.
-if(NOT LLVM_USE_SANITIZER MATCHES "Memory.*")
+if((LLVM_ENABLE_LIBXML2) AND (NOT LLVM_USE_SANITIZER MATCHES "Memory.*"))
   set (LIBXML2_FOUND 0)
   find_package(LibXml2 2.5.3 QUIET)
   if (LIBXML2_FOUND)
 set(CLANG_HAVE_LIBXML 1)
   endif()
 endif()
 
+if (LLVM_ENABLE_LIBXML2 STREQUAL "FORCE_ON" AND NOT CLANG_HAVE_LIBXML)
+  message(FATAL_ERROR "Failed to configure libxml2")
+endif()
+
 include(CheckIncludeFile)
 check_include_file(sys/resource.h CLANG_HAVE_RLIMITS)
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D45233: [Driver] Update GCC libraries detection logic for Gentoo.

2018-04-03 Thread Manoj Gupta via Phabricator via cfe-commits
manojgupta created this revision.
manojgupta added a reviewer: mgorny.

1. Find GCC's LDPATH from the actual GCC config file.
2. Make library detection to take into account crossdev installed 
cross-compiler gcc libraries even when a sysroot is specified.
3. Avoid picking libraries from a similar named tuple if the exact tuple is 
installed.


Repository:
  rC Clang

https://reviews.llvm.org/D45233

Files:
  lib/Driver/ToolChains/Gnu.cpp
  lib/Driver/ToolChains/Gnu.h

Index: lib/Driver/ToolChains/Gnu.h
===
--- lib/Driver/ToolChains/Gnu.h
+++ lib/Driver/ToolChains/Gnu.h
@@ -265,9 +265,15 @@
 StringRef CandidateTriple,
 bool NeedsBiarchSuffix = false);
 
+bool ScanGentooConfigs(const llvm::Triple ,
+   const llvm::opt::ArgList ,
+   const SmallVectorImpl ,
+   const SmallVectorImpl );
+
 bool ScanGentooGccConfig(const llvm::Triple ,
  const llvm::opt::ArgList ,
  StringRef CandidateTriple,
+ const std::string& SysRootPrefix,
  bool NeedsBiarchSuffix = false);
   };
 
Index: lib/Driver/ToolChains/Gnu.cpp
===
--- lib/Driver/ToolChains/Gnu.cpp
+++ lib/Driver/ToolChains/Gnu.cpp
@@ -1707,18 +1707,21 @@
   // in /usr. This avoids accidentally enforcing the system GCC version
   // when using a custom toolchain.
   if (GCCToolchainDir == "" || GCCToolchainDir == D.SysRoot + "/usr") {
-for (StringRef CandidateTriple : ExtraTripleAliases) {
-  if (ScanGentooGccConfig(TargetTriple, Args, CandidateTriple))
-return;
-}
-for (StringRef CandidateTriple : CandidateTripleAliases) {
-  if (ScanGentooGccConfig(TargetTriple, Args, CandidateTriple))
-return;
-}
-for (StringRef CandidateTriple : CandidateBiarchTripleAliases) {
-  if (ScanGentooGccConfig(TargetTriple, Args, CandidateTriple, true))
-return;
-}
+SmallVector GentooTestTriples;
+// Try to match an exact triple as target triple first.
+// e.g. crossdev -S x86_64-gentoo-linux-gnu will install gcc libs for
+// x86_64-gentoo-linux-gnu. But "clang -target x86_64-gentoo-linux-gnu"
+// may pick the libraries for x86_64-pc-linux-gnu even when exact matching
+// triple x86_64-gentoo-linux-gnu is present.
+GentooTestTriples.push_back(TargetTriple.str());
+// Check rest of triples.
+GentooTestTriples.append(ExtraTripleAliases.begin(),
+ ExtraTripleAliases.end());
+GentooTestTriples.append(CandidateTripleAliases.begin(),
+ CandidateTripleAliases.end());
+if (ScanGentooConfigs(TargetTriple, Args, GentooTestTriples,
+  CandidateBiarchTripleAliases))
+  return;
   }
 
   // Loop over the various components which exist and select the best GCC
@@ -2224,38 +2227,99 @@
   }
 }
 
+bool Generic_GCC::GCCInstallationDetector::ScanGentooConfigs(
+const llvm::Triple , const ArgList ,
+const SmallVectorImpl ,
+const SmallVectorImpl ) {
+  // First scan libraries from the sysroot directory if specified.
+  // If not sucessful, scan the root directories. This is needed to find
+  // cross-compilation files/libraries installed by crossdev. For instance,
+  // crossdev -S aarch64-gentoo-linux-gnu installs GCC libraries in
+  // /usr/lib/gcc/version/aarch64-gentoo-linux-gnu and the headers are
+  // installed at /usr/aarch64-gentoo-linux-gnu. Sysroot argument is
+  // needed to find the headers installed in /usr/aarch64-gentoo-linux-gnu.
+  SmallVector SysRootPrefixes;
+  if (!D.SysRoot.empty()) {
+SysRootPrefixes.push_back(D.SysRoot);
+  }
+  SysRootPrefixes.push_back("");
+
+  for (const std::string  : SysRootPrefixes) {
+for (StringRef CandidateTriple : CandidateTriples) {
+  if (ScanGentooGccConfig(TargetTriple, Args, CandidateTriple, SysRoot))
+return true;
+}
+
+for (StringRef CandidateTriple : CandidateBiarchTriples) {
+  if (ScanGentooGccConfig(TargetTriple, Args, CandidateTriple, SysRoot,
+  true))
+return true;
+}
+  }
+  return false;
+}
+
 bool Generic_GCC::GCCInstallationDetector::ScanGentooGccConfig(
 const llvm::Triple , const ArgList ,
-StringRef CandidateTriple, bool NeedsBiarchSuffix) {
+StringRef CandidateTriple, const std::string ,
+bool NeedsBiarchSuffix) {
   llvm::ErrorOr File =
-  D.getVFS().getBufferForFile(D.SysRoot + "/etc/env.d/gcc/config-" +
+  D.getVFS().getBufferForFile(SysRootPrefix + "/etc/env.d/gcc/config-" +
   CandidateTriple.str());
   if (File) {
 SmallVector Lines;
 

[PATCH] D45231: [CUDA] Check initializers of instantiated template variables.

2018-04-03 Thread Artem Belevich via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rC329127: [CUDA] Check initializers of instantiated template 
variables. (authored by tra, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D45231?vs=140867=140871#toc

Repository:
  rC Clang

https://reviews.llvm.org/D45231

Files:
  include/clang/Sema/Sema.h
  lib/Sema/SemaCUDA.cpp
  lib/Sema/SemaDecl.cpp
  lib/Sema/SemaTemplateInstantiateDecl.cpp
  test/SemaCUDA/device-var-init.cu

Index: include/clang/Sema/Sema.h
===
--- include/clang/Sema/Sema.h
+++ include/clang/Sema/Sema.h
@@ -10150,6 +10150,16 @@
   bool isEmptyCudaConstructor(SourceLocation Loc, CXXConstructorDecl *CD);
   bool isEmptyCudaDestructor(SourceLocation Loc, CXXDestructorDecl *CD);
 
+  // \brief Checks that initializers of \p Var satisfy CUDA restrictions. In
+  // case of error emits appropriate diagnostic and invalidates \p Var.
+  //
+  // \details CUDA allows only empty constructors as initializers for global
+  // variables (see E.2.3.1, CUDA 7.5). The same restriction also applies to all
+  // __shared__ variables whether they are local or not (they all are implicitly
+  // static in CUDA). One exception is that CUDA allows constant initializers
+  // for __constant__ and __device__ variables.
+  void checkAllowedCUDAInitializer(VarDecl *Var);
+
   /// Check whether NewFD is a valid overload for CUDA. Emits
   /// diagnostics and invalidates NewFD if not.
   void checkCUDATargetOverload(FunctionDecl *NewFD,
Index: test/SemaCUDA/device-var-init.cu
===
--- test/SemaCUDA/device-var-init.cu
+++ test/SemaCUDA/device-var-init.cu
@@ -225,3 +225,20 @@
   static int x = 42; // no error on device because this is never codegen'ed there.
 }
 void call_hd_emitted_host_only() { hd_emitted_host_only(); }
+
+// Verify that we also check field initializers in instantiated structs.
+struct NontrivialInitializer {
+  __host__ __device__ NontrivialInitializer() : x(43) {}
+  int x;
+};
+
+template 
+__global__ void bar() {
+  __shared__ T bad;
+// expected-error@-1 {{initialization is not supported for __shared__ variables.}}
+}
+
+void instantiate() {
+  bar<<<1, 1>>>();
+// expected-note@-1 {{in instantiation of function template specialization 'bar' requested here}}
+}
Index: lib/Sema/SemaCUDA.cpp
===
--- lib/Sema/SemaCUDA.cpp
+++ lib/Sema/SemaCUDA.cpp
@@ -471,6 +471,59 @@
   return true;
 }
 
+void Sema::checkAllowedCUDAInitializer(VarDecl *VD) {
+  if (VD->isInvalidDecl() || !VD->hasInit() || !VD->hasGlobalStorage())
+return;
+  const Expr *Init = VD->getInit();
+  if (VD->hasAttr() || VD->hasAttr() ||
+  VD->hasAttr()) {
+assert(!VD->isStaticLocal() || VD->hasAttr());
+bool AllowedInit = false;
+if (const CXXConstructExpr *CE = dyn_cast(Init))
+  AllowedInit =
+  isEmptyCudaConstructor(VD->getLocation(), CE->getConstructor());
+// We'll allow constant initializers even if it's a non-empty
+// constructor according to CUDA rules. This deviates from NVCC,
+// but allows us to handle things like constexpr constructors.
+if (!AllowedInit &&
+(VD->hasAttr() || VD->hasAttr()))
+  AllowedInit = VD->getInit()->isConstantInitializer(
+  Context, VD->getType()->isReferenceType());
+
+// Also make sure that destructor, if there is one, is empty.
+if (AllowedInit)
+  if (CXXRecordDecl *RD = VD->getType()->getAsCXXRecordDecl())
+AllowedInit =
+isEmptyCudaDestructor(VD->getLocation(), RD->getDestructor());
+
+if (!AllowedInit) {
+  Diag(VD->getLocation(), VD->hasAttr()
+  ? diag::err_shared_var_init
+  : diag::err_dynamic_var_init)
+  << Init->getSourceRange();
+  VD->setInvalidDecl();
+}
+  } else {
+// This is a host-side global variable.  Check that the initializer is
+// callable from the host side.
+const FunctionDecl *InitFn = nullptr;
+if (const CXXConstructExpr *CE = dyn_cast(Init)) {
+  InitFn = CE->getConstructor();
+} else if (const CallExpr *CE = dyn_cast(Init)) {
+  InitFn = CE->getDirectCallee();
+}
+if (InitFn) {
+  CUDAFunctionTarget InitFnTarget = IdentifyCUDATarget(InitFn);
+  if (InitFnTarget != CFT_Host && InitFnTarget != CFT_HostDevice) {
+Diag(VD->getLocation(), diag::err_ref_bad_target_global_initializer)
+<< InitFnTarget << InitFn;
+Diag(InitFn->getLocation(), diag::note_previous_decl) << InitFn;
+VD->setInvalidDecl();
+  }
+}
+  }
+}
+
 // With -fcuda-host-device-constexpr, an unattributed constexpr function is
 // treated as implicitly __host__ __device__, unless:
 //  * it is a variadic function (device-side variadic functions are not
Index: 

[PATCH] D44921: [PowerPC] Option for secure plt mode

2018-04-03 Thread Nemanja Ivanovic via Phabricator via cfe-commits
nemanjai added a comment.

In https://reviews.llvm.org/D44921#1050299, @joerg wrote:

> GCC supports -mbss-plt to get the legacy behavior. Not sure if anyone 
> actually uses it though.


@spetrovic Is this something we want to implement?


https://reviews.llvm.org/D44921



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


r329127 - [CUDA] Check initializers of instantiated template variables.

2018-04-03 Thread Artem Belevich via cfe-commits
Author: tra
Date: Tue Apr  3 15:41:06 2018
New Revision: 329127

URL: http://llvm.org/viewvc/llvm-project?rev=329127=rev
Log:
[CUDA] Check initializers of instantiated template variables.

We were already performing checks on non-template variables,
but the checks on templated ones were missing.

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

Modified:
cfe/trunk/include/clang/Sema/Sema.h
cfe/trunk/lib/Sema/SemaCUDA.cpp
cfe/trunk/lib/Sema/SemaDecl.cpp
cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp
cfe/trunk/test/SemaCUDA/device-var-init.cu

Modified: cfe/trunk/include/clang/Sema/Sema.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=329127=329126=329127=diff
==
--- cfe/trunk/include/clang/Sema/Sema.h (original)
+++ cfe/trunk/include/clang/Sema/Sema.h Tue Apr  3 15:41:06 2018
@@ -10150,6 +10150,16 @@ public:
   bool isEmptyCudaConstructor(SourceLocation Loc, CXXConstructorDecl *CD);
   bool isEmptyCudaDestructor(SourceLocation Loc, CXXDestructorDecl *CD);
 
+  // \brief Checks that initializers of \p Var satisfy CUDA restrictions. In
+  // case of error emits appropriate diagnostic and invalidates \p Var.
+  //
+  // \details CUDA allows only empty constructors as initializers for global
+  // variables (see E.2.3.1, CUDA 7.5). The same restriction also applies to 
all
+  // __shared__ variables whether they are local or not (they all are 
implicitly
+  // static in CUDA). One exception is that CUDA allows constant initializers
+  // for __constant__ and __device__ variables.
+  void checkAllowedCUDAInitializer(VarDecl *Var);
+
   /// Check whether NewFD is a valid overload for CUDA. Emits
   /// diagnostics and invalidates NewFD if not.
   void checkCUDATargetOverload(FunctionDecl *NewFD,

Modified: cfe/trunk/lib/Sema/SemaCUDA.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaCUDA.cpp?rev=329127=329126=329127=diff
==
--- cfe/trunk/lib/Sema/SemaCUDA.cpp (original)
+++ cfe/trunk/lib/Sema/SemaCUDA.cpp Tue Apr  3 15:41:06 2018
@@ -471,6 +471,59 @@ bool Sema::isEmptyCudaDestructor(SourceL
   return true;
 }
 
+void Sema::checkAllowedCUDAInitializer(VarDecl *VD) {
+  if (VD->isInvalidDecl() || !VD->hasInit() || !VD->hasGlobalStorage())
+return;
+  const Expr *Init = VD->getInit();
+  if (VD->hasAttr() || VD->hasAttr() ||
+  VD->hasAttr()) {
+assert(!VD->isStaticLocal() || VD->hasAttr());
+bool AllowedInit = false;
+if (const CXXConstructExpr *CE = dyn_cast(Init))
+  AllowedInit =
+  isEmptyCudaConstructor(VD->getLocation(), CE->getConstructor());
+// We'll allow constant initializers even if it's a non-empty
+// constructor according to CUDA rules. This deviates from NVCC,
+// but allows us to handle things like constexpr constructors.
+if (!AllowedInit &&
+(VD->hasAttr() || VD->hasAttr()))
+  AllowedInit = VD->getInit()->isConstantInitializer(
+  Context, VD->getType()->isReferenceType());
+
+// Also make sure that destructor, if there is one, is empty.
+if (AllowedInit)
+  if (CXXRecordDecl *RD = VD->getType()->getAsCXXRecordDecl())
+AllowedInit =
+isEmptyCudaDestructor(VD->getLocation(), RD->getDestructor());
+
+if (!AllowedInit) {
+  Diag(VD->getLocation(), VD->hasAttr()
+  ? diag::err_shared_var_init
+  : diag::err_dynamic_var_init)
+  << Init->getSourceRange();
+  VD->setInvalidDecl();
+}
+  } else {
+// This is a host-side global variable.  Check that the initializer is
+// callable from the host side.
+const FunctionDecl *InitFn = nullptr;
+if (const CXXConstructExpr *CE = dyn_cast(Init)) {
+  InitFn = CE->getConstructor();
+} else if (const CallExpr *CE = dyn_cast(Init)) {
+  InitFn = CE->getDirectCallee();
+}
+if (InitFn) {
+  CUDAFunctionTarget InitFnTarget = IdentifyCUDATarget(InitFn);
+  if (InitFnTarget != CFT_Host && InitFnTarget != CFT_HostDevice) {
+Diag(VD->getLocation(), diag::err_ref_bad_target_global_initializer)
+<< InitFnTarget << InitFn;
+Diag(InitFn->getLocation(), diag::note_previous_decl) << InitFn;
+VD->setInvalidDecl();
+  }
+}
+  }
+}
+
 // With -fcuda-host-device-constexpr, an unattributed constexpr function is
 // treated as implicitly __host__ __device__, unless:
 //  * it is a variadic function (device-side variadic functions are not

Modified: cfe/trunk/lib/Sema/SemaDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDecl.cpp?rev=329127=329126=329127=diff
==
--- cfe/trunk/lib/Sema/SemaDecl.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDecl.cpp Tue Apr  3 15:41:06 2018
@@ -11629,58 

[PATCH] D42034: [clang-format] In tests, expected code should be format-stable

2018-04-03 Thread Mark Zeren via Phabricator via cfe-commits
mzeren-vmw added a comment.

In https://reviews.llvm.org/D42034#1051965, @mzeren-vmw wrote:

> Update other verifyFormat implementations.


Ping?


Repository:
  rC Clang

https://reviews.llvm.org/D42034



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


[PATCH] D44801: Add the -fsanitize=shadow-call-stack flag

2018-04-03 Thread Vlad Tsyrklevich via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL329122: Add the -fsanitize=shadow-call-stack flag (authored 
by vlad.tsyrklevich, committed by ).
Herald added a subscriber: llvm-commits.

Repository:
  rL LLVM

https://reviews.llvm.org/D44801

Files:
  cfe/trunk/docs/ShadowCallStack.rst
  cfe/trunk/docs/index.rst
  cfe/trunk/include/clang/Basic/Sanitizers.def
  cfe/trunk/lib/CodeGen/CGDeclCXX.cpp
  cfe/trunk/lib/CodeGen/CodeGenFunction.cpp
  cfe/trunk/lib/Driver/SanitizerArgs.cpp
  cfe/trunk/lib/Driver/ToolChain.cpp
  cfe/trunk/lib/Lex/PPMacroExpansion.cpp
  cfe/trunk/test/CodeGen/shadowcallstack-attr.c
  cfe/trunk/test/Driver/sanitizer-ld.c

Index: cfe/trunk/docs/ShadowCallStack.rst
===
--- cfe/trunk/docs/ShadowCallStack.rst
+++ cfe/trunk/docs/ShadowCallStack.rst
@@ -0,0 +1,150 @@
+===
+ShadowCallStack
+===
+
+.. contents::
+   :local:
+
+Introduction
+
+
+ShadowCallStack is an **experimental** instrumentation pass, currently only
+implemented for x86_64, that protects programs against return address
+overwrites (e.g. stack buffer overflows.) It works by saving a function's return
+address to a separately allocated 'shadow call stack' in the function prolog and
+checking the return address on the stack against the shadow call stack in the
+function epilog.
+
+Comparison
+--
+
+To optimize for memory consumption and cache locality, the shadow call stack
+stores an index followed by an array of return addresses. This is in contrast
+to other schemes, like :doc:`SafeStack`, that mirror the entire stack and
+trade-off consuming more memory for shorter function prologs and epilogs with
+fewer memory accesses. Similarly, `Return Flow Guard`_ consumes more memory with
+shorter function prologs and epilogs than ShadowCallStack but suffers from the
+same race conditions (see `Security`_). Intel `Control-flow Enforcement Technology`_
+(CET) is a proposed hardware extension that would add native support to
+use a shadow stack to store/check return addresses at call/return time. It
+would not suffer from race conditions at calls and returns and not incur the
+overhead of function instrumentation, but it does require operating system
+support.
+
+.. _`Return Flow Guard`: https://xlab.tencent.com/en/2016/11/02/return-flow-guard/
+.. _`Control-flow Enforcement Technology`: https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf
+
+Compatibility
+-
+
+ShadowCallStack currently only supports x86_64. A runtime is not currently
+provided in compiler-rt so one must be provided by the compiled application.
+
+Security
+
+
+ShadowCallStack is intended to be a stronger alternative to
+``-fstack-protector``. It protects from non-linear overflows and arbitrary
+memory writes to the return address slot; however, similarly to
+``-fstack-protector`` this protection suffers from race conditions because of
+the call-return semantics on x86_64. There is a short race between the call
+instruction and the first instruction in the function that reads the return
+address where an attacker could overwrite the return address and bypass
+ShadowCallStack. Similarly, there is a time-of-check-to-time-of-use race in the
+function epilog where an attacker could overwrite the return address after it
+has been checked and before it has been returned to. Modifying the call-return
+semantics to fix this on x86_64 would incur an unacceptable performance overhead
+due to return branch prediction.
+
+The instrumentation makes use of the ``gs`` segment register to reference the
+shadow call stack meaning that references to the shadow call stack do not have
+to be stored in memory. This makes it possible to implement a runtime that
+avoids exposing the address of the shadow call stack to attackers that can read
+arbitrary memory. However, attackers could still try to exploit side channels
+exposed by the operating system `[1]`_ `[2]`_ or processor `[3]`_ to discover
+the address of the shadow call stack.
+
+.. _`[1]`: https://eyalitkin.wordpress.com/2017/09/01/cartography-lighting-up-the-shadows/
+.. _`[2]`: https://www.blackhat.com/docs/eu-16/materials/eu-16-Goktas-Bypassing-Clangs-SafeStack.pdf
+.. _`[3]`: https://www.vusec.net/projects/anc/
+
+Leaf functions are optimized to store the return address in a free register
+and avoid writing to the shadow call stack if a register is available. Very
+short leaf functions are uninstrumented if their execution is judged to be
+shorter than the race condition window intrinsic to the instrumentation.
+
+Usage
+=
+
+To enable ShadowCallStack, just pass the ``-fsanitize=shadow-call-stack`` flag
+to both compile and link command lines.
+
+Low-level API
+-
+
+``__has_feature(shadow_call_stack)``
+
+
+In some cases one may need to execute 

r329122 - Add the -fsanitize=shadow-call-stack flag

2018-04-03 Thread Vlad Tsyrklevich via cfe-commits
Author: vlad.tsyrklevich
Date: Tue Apr  3 15:33:53 2018
New Revision: 329122

URL: http://llvm.org/viewvc/llvm-project?rev=329122=rev
Log:
Add the -fsanitize=shadow-call-stack flag

Summary:
Add support for the -fsanitize=shadow-call-stack flag which causes clang
to add ShadowCallStack attribute to functions compiled with that flag
enabled.

Reviewers: pcc, kcc

Reviewed By: pcc, kcc

Subscribers: cryptoad, cfe-commits, kcc

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

Added:
cfe/trunk/docs/ShadowCallStack.rst
cfe/trunk/test/CodeGen/shadowcallstack-attr.c
Modified:
cfe/trunk/docs/index.rst
cfe/trunk/include/clang/Basic/Sanitizers.def
cfe/trunk/lib/CodeGen/CGDeclCXX.cpp
cfe/trunk/lib/CodeGen/CodeGenFunction.cpp
cfe/trunk/lib/Driver/SanitizerArgs.cpp
cfe/trunk/lib/Driver/ToolChain.cpp
cfe/trunk/lib/Lex/PPMacroExpansion.cpp
cfe/trunk/test/Driver/sanitizer-ld.c

Added: cfe/trunk/docs/ShadowCallStack.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ShadowCallStack.rst?rev=329122=auto
==
--- cfe/trunk/docs/ShadowCallStack.rst (added)
+++ cfe/trunk/docs/ShadowCallStack.rst Tue Apr  3 15:33:53 2018
@@ -0,0 +1,150 @@
+===
+ShadowCallStack
+===
+
+.. contents::
+   :local:
+
+Introduction
+
+
+ShadowCallStack is an **experimental** instrumentation pass, currently only
+implemented for x86_64, that protects programs against return address
+overwrites (e.g. stack buffer overflows.) It works by saving a function's 
return
+address to a separately allocated 'shadow call stack' in the function prolog 
and
+checking the return address on the stack against the shadow call stack in the
+function epilog.
+
+Comparison
+--
+
+To optimize for memory consumption and cache locality, the shadow call stack
+stores an index followed by an array of return addresses. This is in contrast
+to other schemes, like :doc:`SafeStack`, that mirror the entire stack and
+trade-off consuming more memory for shorter function prologs and epilogs with
+fewer memory accesses. Similarly, `Return Flow Guard`_ consumes more memory 
with
+shorter function prologs and epilogs than ShadowCallStack but suffers from the
+same race conditions (see `Security`_). Intel `Control-flow Enforcement 
Technology`_
+(CET) is a proposed hardware extension that would add native support to
+use a shadow stack to store/check return addresses at call/return time. It
+would not suffer from race conditions at calls and returns and not incur the
+overhead of function instrumentation, but it does require operating system
+support.
+
+.. _`Return Flow Guard`: 
https://xlab.tencent.com/en/2016/11/02/return-flow-guard/
+.. _`Control-flow Enforcement Technology`: 
https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf
+
+Compatibility
+-
+
+ShadowCallStack currently only supports x86_64. A runtime is not currently
+provided in compiler-rt so one must be provided by the compiled application.
+
+Security
+
+
+ShadowCallStack is intended to be a stronger alternative to
+``-fstack-protector``. It protects from non-linear overflows and arbitrary
+memory writes to the return address slot; however, similarly to
+``-fstack-protector`` this protection suffers from race conditions because of
+the call-return semantics on x86_64. There is a short race between the call
+instruction and the first instruction in the function that reads the return
+address where an attacker could overwrite the return address and bypass
+ShadowCallStack. Similarly, there is a time-of-check-to-time-of-use race in the
+function epilog where an attacker could overwrite the return address after it
+has been checked and before it has been returned to. Modifying the call-return
+semantics to fix this on x86_64 would incur an unacceptable performance 
overhead
+due to return branch prediction.
+
+The instrumentation makes use of the ``gs`` segment register to reference the
+shadow call stack meaning that references to the shadow call stack do not have
+to be stored in memory. This makes it possible to implement a runtime that
+avoids exposing the address of the shadow call stack to attackers that can read
+arbitrary memory. However, attackers could still try to exploit side channels
+exposed by the operating system `[1]`_ `[2]`_ or processor `[3]`_ to discover
+the address of the shadow call stack.
+
+.. _`[1]`: 
https://eyalitkin.wordpress.com/2017/09/01/cartography-lighting-up-the-shadows/
+.. _`[2]`: 
https://www.blackhat.com/docs/eu-16/materials/eu-16-Goktas-Bypassing-Clangs-SafeStack.pdf
+.. _`[3]`: https://www.vusec.net/projects/anc/
+
+Leaf functions are optimized to store the return address in a free register
+and avoid writing to the shadow call stack if a register is available. Very
+short leaf functions are uninstrumented if their execution is judged to 

[PATCH] D44801: Add the -fsanitize=shadow-call-stack flag

2018-04-03 Thread Vlad Tsyrklevich via Phabricator via cfe-commits
vlad.tsyrklevich updated this revision to Diff 140868.
vlad.tsyrklevich added a comment.

- Small test, doc updates


Repository:
  rC Clang

https://reviews.llvm.org/D44801

Files:
  docs/ShadowCallStack.rst
  docs/index.rst
  include/clang/Basic/Sanitizers.def
  lib/CodeGen/CGDeclCXX.cpp
  lib/CodeGen/CodeGenFunction.cpp
  lib/Driver/SanitizerArgs.cpp
  lib/Driver/ToolChain.cpp
  lib/Lex/PPMacroExpansion.cpp
  test/CodeGen/shadowcallstack-attr.c
  test/Driver/sanitizer-ld.c

Index: test/Driver/sanitizer-ld.c
===
--- test/Driver/sanitizer-ld.c
+++ test/Driver/sanitizer-ld.c
@@ -557,6 +557,21 @@
 // CHECK-SAFESTACK-LINUX: "-lpthread"
 // CHECK-SAFESTACK-LINUX: "-ldl"
 
+// RUN: %clang -fsanitize=shadow-call-stack %s -### -o %t.o 2>&1 \
+// RUN: -target x86_64-unknown-linux -fuse-ld=ld \
+// RUN:   | FileCheck --check-prefix=CHECK-SHADOWCALLSTACK-LINUX-X86-64 %s
+// CHECK-SHADOWCALLSTACK-LINUX-X86-64-NOT: error:
+
+// RUN: %clang -fsanitize=shadow-call-stack %s -### -o %t.o 2>&1 \
+// RUN: -target x86-unknown-linux -fuse-ld=ld \
+// RUN:   | FileCheck --check-prefix=CHECK-SHADOWCALLSTACK-LINUX-X86 %s
+// CHECK-SHADOWCALLSTACK-LINUX-X86: error: unsupported option '-fsanitize=shadow-call-stack' for target 'x86-unknown-linux'
+
+// RUN: %clang -fsanitize=shadow-call-stack %s -### -o %t.o 2>&1 \
+// RUN: -fsanitize=safe-stack -target x86_64-unknown-linux -fuse-ld=ld \
+// RUN:   | FileCheck --check-prefix=CHECK-SHADOWCALLSTACK-SAFESTACK %s
+// CHECK-SHADOWCALLSTACK-SAFESTACK: error: invalid argument '-fsanitize=shadow-call-stack' not allowed with '-fsanitize=safe-stack'
+
 // RUN: %clang -fsanitize=cfi -fsanitize-stats %s -### -o %t.o 2>&1 \
 // RUN: -target x86_64-unknown-linux -fuse-ld=ld \
 // RUN: --sysroot=%S/Inputs/basic_linux_tree \
Index: test/CodeGen/shadowcallstack-attr.c
===
--- /dev/null
+++ test/CodeGen/shadowcallstack-attr.c
@@ -0,0 +1,16 @@
+// RUN: %clang_cc1 -triple x86_64-linux-unknown -emit-llvm -o - %s -fsanitize=shadow-call-stack | FileCheck -check-prefix=UNBLACKLISTED %s
+
+// RUN: %clang_cc1 -D ATTR -triple x86_64-linux-unknown -emit-llvm -o - %s -fsanitize=shadow-call-stack | FileCheck -check-prefix=BLACKLISTED %s
+
+// RUN: echo -e "[shadow-call-stack]\nfun:foo" > %t
+// RUN: %clang_cc1 -fsanitize-blacklist=%t -triple x86_64-linux-unknown -emit-llvm -o - %s -fsanitize=shadow-call-stack | FileCheck -check-prefix=BLACKLISTED %s
+
+#ifdef ATTR
+__attribute__((no_sanitize("shadow-call-stack")))
+#endif
+int foo(int *a) { return *a; }
+
+// CHECK: define i32 @foo(i32* %a)
+
+// BLACKLISTED-NOT: attributes {{.*}}shadowcallstack{{.*}}
+// UNBLACKLISTED: attributes {{.*}}shadowcallstack{{.*}}
Index: lib/Lex/PPMacroExpansion.cpp
===
--- lib/Lex/PPMacroExpansion.cpp
+++ lib/Lex/PPMacroExpansion.cpp
@@ -1275,6 +1275,8 @@
   .Case("is_union", LangOpts.CPlusPlus)
   .Case("modules", LangOpts.Modules)
   .Case("safe_stack", LangOpts.Sanitize.has(SanitizerKind::SafeStack))
+  .Case("shadow_call_stack",
+LangOpts.Sanitize.has(SanitizerKind::ShadowCallStack))
   .Case("tls", PP.getTargetInfo().isTLSSupported())
   .Case("underlying_type", LangOpts.CPlusPlus)
   .Default(false);
Index: lib/Driver/ToolChain.cpp
===
--- lib/Driver/ToolChain.cpp
+++ lib/Driver/ToolChain.cpp
@@ -814,6 +814,8 @@
   getTriple().getArch() == llvm::Triple::wasm32 ||
   getTriple().getArch() == llvm::Triple::wasm64)
 Res |= CFIICall;
+  if (getTriple().getArch() == llvm::Triple::x86_64)
+Res |= ShadowCallStack;
   return Res;
 }
 
Index: lib/Driver/SanitizerArgs.cpp
===
--- lib/Driver/SanitizerArgs.cpp
+++ lib/Driver/SanitizerArgs.cpp
@@ -343,7 +343,10 @@
   std::make_pair(Scudo, Address | HWAddress | Leak | Thread | Memory |
 KernelAddress | Efficiency),
   std::make_pair(SafeStack, Address | HWAddress | Leak | Thread | Memory |
-KernelAddress | Efficiency)};
+KernelAddress | Efficiency),
+  std::make_pair(ShadowCallStack, Address | HWAddress | Leak | Thread |
+  Memory | KernelAddress | Efficiency |
+  SafeStack)};
 
   // Enable toolchain specific default sanitizers if not explicitly disabled.
   SanitizerMask Default = TC.getDefaultSanitizers() & ~AllRemove;
Index: lib/CodeGen/CodeGenFunction.cpp
===
--- lib/CodeGen/CodeGenFunction.cpp
+++ lib/CodeGen/CodeGenFunction.cpp
@@ -861,6 +861,8 @@
 Fn->addFnAttr(llvm::Attribute::SanitizeMemory);
   if 

[PATCH] D45231: [CUDA] Check initializers of instantiated template variables.

2018-04-03 Thread Artem Belevich via Phabricator via cfe-commits
tra created this revision.
tra added a reviewer: jlebar.
Herald added a subscriber: sanjoy.

We were already performing checks on non-template variables,
but the checks on templated ones were missing.


https://reviews.llvm.org/D45231

Files:
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/SemaCUDA.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
  clang/test/SemaCUDA/device-var-init.cu

Index: clang/test/SemaCUDA/device-var-init.cu
===
--- clang/test/SemaCUDA/device-var-init.cu
+++ clang/test/SemaCUDA/device-var-init.cu
@@ -225,3 +225,20 @@
   static int x = 42; // no error on device because this is never codegen'ed there.
 }
 void call_hd_emitted_host_only() { hd_emitted_host_only(); }
+
+// Verify that we also check field initializers in instantiated structs.
+struct NontrivialInitializer {
+  __host__ __device__ NontrivialInitializer() : x(43) {}
+  int x;
+};
+
+template 
+__global__ void bar() {
+  __shared__ T bad;
+// expected-error@-1 {{initialization is not supported for __shared__ variables.}}
+}
+
+void instantiate() {
+  bar<<<1, 1>>>();
+// expected-note@-1 {{in instantiation of function template specialization 'bar' requested here}}
+}
Index: clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
===
--- clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
+++ clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
@@ -4221,6 +4221,9 @@
 
 ActOnUninitializedDecl(Var);
   }
+
+  if (getLangOpts().CUDA)
+checkAllowedCUDAInitializer(Var);
 }
 
 /// \brief Instantiate the definition of the given variable from its
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -11629,58 +11629,8 @@
   // 7.5). We must also apply the same checks to all __shared__
   // variables whether they are local or not. CUDA also allows
   // constant initializers for __constant__ and __device__ variables.
-  if (getLangOpts().CUDA) {
-const Expr *Init = VD->getInit();
-if (Init && VD->hasGlobalStorage()) {
-  if (VD->hasAttr() || VD->hasAttr() ||
-  VD->hasAttr()) {
-assert(!VD->isStaticLocal() || VD->hasAttr());
-bool AllowedInit = false;
-if (const CXXConstructExpr *CE = dyn_cast(Init))
-  AllowedInit =
-  isEmptyCudaConstructor(VD->getLocation(), CE->getConstructor());
-// We'll allow constant initializers even if it's a non-empty
-// constructor according to CUDA rules. This deviates from NVCC,
-// but allows us to handle things like constexpr constructors.
-if (!AllowedInit &&
-(VD->hasAttr() || VD->hasAttr()))
-  AllowedInit = VD->getInit()->isConstantInitializer(
-  Context, VD->getType()->isReferenceType());
-
-// Also make sure that destructor, if there is one, is empty.
-if (AllowedInit)
-  if (CXXRecordDecl *RD = VD->getType()->getAsCXXRecordDecl())
-AllowedInit =
-isEmptyCudaDestructor(VD->getLocation(), RD->getDestructor());
-
-if (!AllowedInit) {
-  Diag(VD->getLocation(), VD->hasAttr()
-  ? diag::err_shared_var_init
-  : diag::err_dynamic_var_init)
-  << Init->getSourceRange();
-  VD->setInvalidDecl();
-}
-  } else {
-// This is a host-side global variable.  Check that the initializer is
-// callable from the host side.
-const FunctionDecl *InitFn = nullptr;
-if (const CXXConstructExpr *CE = dyn_cast(Init)) {
-  InitFn = CE->getConstructor();
-} else if (const CallExpr *CE = dyn_cast(Init)) {
-  InitFn = CE->getDirectCallee();
-}
-if (InitFn) {
-  CUDAFunctionTarget InitFnTarget = IdentifyCUDATarget(InitFn);
-  if (InitFnTarget != CFT_Host && InitFnTarget != CFT_HostDevice) {
-Diag(VD->getLocation(), diag::err_ref_bad_target_global_initializer)
-<< InitFnTarget << InitFn;
-Diag(InitFn->getLocation(), diag::note_previous_decl) << InitFn;
-VD->setInvalidDecl();
-  }
-}
-  }
-}
-  }
+  if (getLangOpts().CUDA)
+checkAllowedCUDAInitializer(VD);
 
   // Grab the dllimport or dllexport attribute off of the VarDecl.
   const InheritableAttr *DLLAttr = getDLLAttr(VD);
Index: clang/lib/Sema/SemaCUDA.cpp
===
--- clang/lib/Sema/SemaCUDA.cpp
+++ clang/lib/Sema/SemaCUDA.cpp
@@ -471,6 +471,59 @@
   return true;
 }
 
+void Sema::checkAllowedCUDAInitializer(VarDecl *VD) {
+  if (VD->isInvalidDecl() || !VD->hasInit() || !VD->hasGlobalStorage())
+return;
+  const Expr *Init = VD->getInit();
+  if (VD->hasAttr() || VD->hasAttr() ||
+  

[PATCH] D45179: [libc++] Add _LIBCPP_FORCE_NODISCARD define to force-enable nodiscard in pre-C++17

2018-04-03 Thread John McCall via Phabricator via cfe-commits
rjmccall added a comment.

Yes, if we think that the committee is likely to include questionable functions 
on the `[[nodiscard]]` list which we don't want to warn about pre-C++17, then 
it makes sense to have two internal macros, one for functions like `std::move` 
that should be unconditionally warned about and one for the 
iffy-bu-standard-directed cases.


Repository:
  rCXX libc++

https://reviews.llvm.org/D45179



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


[PATCH] D45179: [libc++] Add _LIBCPP_FORCE_NODISCARD define to force-enable nodiscard in pre-C++17

2018-04-03 Thread Eric Fiselier via Phabricator via cfe-commits
EricWF added a comment.

I'm also in favor of making this opt-out instead of opt-in, except for a 
handful of functions like `unique_ptr::release` which may yield false 
positives. However, for functions where discarding the return value is always a 
bug, I don't see an issue in libc++ emitting a warning where it didn't 
previously.


Repository:
  rCXX libc++

https://reviews.llvm.org/D45179



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


[PATCH] D45176: implement recent "standard-layout" changes

2018-04-03 Thread John McCall via Phabricator via cfe-commits
rjmccall added inline comments.



Comment at: AST/DeclCXX.cpp:1130
   data().IsStandardLayout = false;
+  data().IsCXX11StandardLayout = false;
+}

`IsCXX11StandardLayout` should be based on `FieldRec->isCXX11StandardLayout()`, 
I assume.


https://reviews.llvm.org/D45176



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


[PATCH] D45179: [libc++] Add _LIBCPP_FORCE_NODISCARD define to force-enable nodiscard in pre-C++17

2018-04-03 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added a comment.

In https://reviews.llvm.org/D45179#1056183, @rjmccall wrote:

> Is Marshall arguing that the standard doesn't allow compilers to warn about 
> failing to use these function results prior to C++17?


No. He was simply saying that people are opposed to having nodiscard attribute 
specified when the standard does not require that yet.
For same reason, this has to be an opt-in (`_LIBCPP_FORCE_NODISCARD`), it can't 
be just an opt-out.
But, you might as well just ask him that.


Repository:
  rCXX libc++

https://reviews.llvm.org/D45179



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


r329115 - [StaticAnalyzer] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC).

2018-04-03 Thread Eugene Zelenko via cfe-commits
Author: eugenezelenko
Date: Tue Apr  3 14:31:50 2018
New Revision: 329115

URL: http://llvm.org/viewvc/llvm-project?rev=329115=rev
Log:
[StaticAnalyzer] Fix some Clang-tidy modernize and Include What You Use 
warnings; other minor fixes (NFC).

Modified:
cfe/trunk/include/clang/StaticAnalyzer/Core/CheckerRegistry.h
cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h
cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/TaintManager.h
cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/TaintTag.h
cfe/trunk/lib/StaticAnalyzer/Core/CheckerRegistry.cpp
cfe/trunk/lib/StaticAnalyzer/Core/MemRegion.cpp

Modified: cfe/trunk/include/clang/StaticAnalyzer/Core/CheckerRegistry.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/StaticAnalyzer/Core/CheckerRegistry.h?rev=329115=329114=329115=diff
==
--- cfe/trunk/include/clang/StaticAnalyzer/Core/CheckerRegistry.h (original)
+++ cfe/trunk/include/clang/StaticAnalyzer/Core/CheckerRegistry.h Tue Apr  3 
14:31:50 2018
@@ -1,4 +1,4 @@
-//===--- CheckerRegistry.h - Maintains all available checkers ---*- C++ 
-*-===//
+//===- CheckerRegistry.h - Maintains all available checkers -*- C++ 
-*-===//
 //
 // The LLVM Compiler Infrastructure
 //
@@ -12,6 +12,9 @@
 
 #include "clang/Basic/LLVM.h"
 #include "clang/StaticAnalyzer/Core/CheckerManager.h"
+#include "llvm/ADT/StringMap.h"
+#include "llvm/ADT/StringRef.h"
+#include 
 #include 
 
 // FIXME: move this information to an HTML file in docs/.
@@ -64,8 +67,9 @@
 #endif
 
 namespace clang {
-class DiagnosticsEngine;
+
 class AnalyzerOptions;
+class DiagnosticsEngine;
 
 namespace ento {
 
@@ -81,17 +85,18 @@ class CheckerRegistry {
 public:
   /// Initialization functions perform any necessary setup for a checker.
   /// They should include a call to CheckerManager::registerChecker.
-  typedef void (*InitializationFunction)(CheckerManager &);
+  using InitializationFunction = void (*)(CheckerManager &);
+
   struct CheckerInfo {
 InitializationFunction Initialize;
 StringRef FullName;
 StringRef Desc;
 
 CheckerInfo(InitializationFunction fn, StringRef name, StringRef desc)
-: Initialize(fn), FullName(name), Desc(desc) {}
+: Initialize(fn), FullName(name), Desc(desc) {}
   };
 
-  typedef std::vector CheckerInfoList;
+  using CheckerInfoList = std::vector;
 
 private:
   template 
@@ -136,7 +141,8 @@ private:
   mutable llvm::StringMap Packages;
 };
 
-} // end namespace ento
-} // end namespace clang
+} // namespace ento
 
-#endif
+} // namespace clang
+
+#endif // LLVM_CLANG_STATICANALYZER_CORE_CHECKERREGISTRY_H

Modified: cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h?rev=329115=329114=329115=diff
==
--- cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h 
(original)
+++ cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h Tue 
Apr  3 14:31:50 2018
@@ -1,4 +1,4 @@
-//== MemRegion.h - Abstract memory regions for static analysis --*- C++ 
-*--==//
+//==- MemRegion.h - Abstract memory regions for static analysis -*- C++ 
-*--==//
 //
 // The LLVM Compiler Infrastructure
 //
@@ -19,24 +19,39 @@
 #include "clang/AST/ASTContext.h"
 #include "clang/AST/CharUnits.h"
 #include "clang/AST/Decl.h"
-#include "clang/AST/DeclCXX.h"
+#include "clang/AST/DeclObjC.h"
+#include "clang/AST/DeclarationName.h"
+#include "clang/AST/Expr.h"
 #include "clang/AST/ExprObjC.h"
-#include "clang/Analysis/AnalysisDeclContext.h"
+#include "clang/AST/Type.h"
 #include "clang/Basic/LLVM.h"
+#include "clang/Basic/SourceLocation.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/SVals.h"
+#include "clang/StaticAnalyzer/Core/PathSensitive/SymExpr.h"
+#include "llvm/ADT/DenseMap.h"
 #include "llvm/ADT/FoldingSet.h"
+#include "llvm/ADT/Optional.h"
+#include "llvm/ADT/PointerIntPair.h"
 #include "llvm/Support/Allocator.h"
-#include "llvm/Support/ErrorHandling.h"
+#include "llvm/Support/Casting.h"
+#include 
+#include 
+#include 
 #include 
+#include 
 
 namespace clang {
 
+class AnalysisDeclContext;
+class CXXRecordDecl;
+class Decl;
 class LocationContext;
 class StackFrameContext;
 
 namespace ento {
 
 class CodeTextRegion;
+class MemRegion;
 class MemRegionManager;
 class MemSpaceRegion;
 class SValBuilder;
@@ -46,7 +61,7 @@ class VarRegion;
 /// Represent a region's offset within the top level base region.
 class RegionOffset {
   /// The base region.
-  const MemRegion *R;
+  const MemRegion *R = nullptr;
 
   /// The bit offset within the base region. Can be negative.
   int64_t Offset;
@@ -54,9 +69,9 @@ class RegionOffset {
 public:
   // We're using a const instead of an enumeration due to the size 

[PATCH] D45223: [CUDA] Fix overloading resolution failure due to kernel calling convention

2018-04-03 Thread John McCall via Phabricator via cfe-commits
rjmccall added a comment.

I think the appropriate place to do this is in IsStandardConversion, 
immediately after the call to ResolveAddressOfOverloadedFunction.  You might 
want to add a general utility for getting the type-of-reference of a function 
decl.


https://reviews.llvm.org/D45223



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


[PATCH] D45056: [X86] Split up -march=icelake to -client & -server

2018-04-03 Thread Craig Topper via Phabricator via cfe-commits
craig.topper added inline comments.



Comment at: test/Preprocessor/predefined-arch-macros.c:1164
+// CHECK_ICX_M32: #define __corei7 1
+// CHECK_ICX_M32: #define __corei7__ 1
+// CHECK_ICX_M32: #define __i386 1

The ICX_M32 and ICX_M64 should be contiguous in the file. The file is grouped 
by CPUs with the 32 and 64 bit together.


Repository:
  rC Clang

https://reviews.llvm.org/D45056



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


[PATCH] D45179: [libc++] Add _LIBCPP_FORCE_NODISCARD define to force-enable nodiscard in pre-C++17

2018-04-03 Thread John McCall via Phabricator via cfe-commits
rjmccall added a comment.

Is Marshall arguing that the standard doesn't allow compilers to warn about 
failing to use these function results prior to C++17?  Because I don't think 
that's true; warnings are thoroughly non-normative.

If libc++ wants to allow its users to opt out of these warnings just for libc++ 
functions, that's fine (although unusual), but it seems to me that that ought 
to be an explicit opt-out that's independent of language version.


Repository:
  rCXX libc++

https://reviews.llvm.org/D45179



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


Re: r329110 - [driver][darwin] Do not infer -simulator environment for non-simulator SDKs

2018-04-03 Thread Chandler Carruth via cfe-commits
On Tue, Apr 3, 2018 at 1:52 PM Alex Lorenz via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: arphaman
> Date: Tue Apr  3 13:50:05 2018
> New Revision: 329110
>
> URL: http://llvm.org/viewvc/llvm-project?rev=329110=rev
> Log:
> [driver][darwin] Do not infer -simulator environment for non-simulator SDKs
>

I know you added a REQUIRES line to these tests, but I think there is a
much better way:


> --- cfe/trunk/test/Driver/darwin-sdkroot.c (original)
> +++ cfe/trunk/test/Driver/darwin-sdkroot.c Tue Apr  3 13:50:05 2018
> @@ -51,12 +51,21 @@
>  // CHECK-IPHONE: "-triple" "arm64-apple-ios8.0.0"
>  // CHECK-IPHONE: ld
>  // CHECK-IPHONE: "-iphoneos_version_min" "8.0.0"
> +// RUN: env SDKROOT=%t/SDKs/iPhoneOS8.0.0.sdk %clang %s -### 2>&1 \
>

Instead of just running %clang, actually pass the `-target` you want to it
like we do in the below invocation and the other invocations in this file.

We shouldn't lose driver testing on other systems as long as you can
specify the desired target.


> +// RUN:   | FileCheck --check-prefix=CHECK-IPHONE-X86 %s
> +// CHECK-IPHONE-X86: clang
> +// CHECK-IPHONE-X86: "-cc1"
> +// CHECK-IPHONE-X86: -apple-ios8.0.0"
> +// CHECK-IPHONE-X86: ld
> +// CHECK-IPHONE-X86: "-iphoneos_version_min" "8.0.0"
>  //
>  //
>  // RUN: rm -rf %t/SDKs/iPhoneSimulator8.0.sdk
>  // RUN: mkdir -p %t/SDKs/iPhoneSimulator8.0.sdk
>  // RUN: env SDKROOT=%t/SDKs/iPhoneSimulator8.0.sdk %clang -target
> x86_64-apple-darwin %s -### 2>&1 \
>  // RUN:   | FileCheck --check-prefix=CHECK-SIMULATOR %s
> +// RUN: env SDKROOT=%t/SDKs/iPhoneSimulator8.0.sdk %clang -arch x86_64 %s
> -### 2>&1 \
> +// RUN:   | FileCheck --check-prefix=CHECK-SIMULATOR %s
>  //
>  // CHECK-SIMULATOR: clang
>  // CHECK-SIMULATOR: "-cc1"
> @@ -74,3 +83,49 @@
>  // CHECK-MACOSX: "-triple" "x86_64-apple-macosx10.10.0"
>  // CHECK-MACOSX: ld
>  // CHECK-MACOSX: "-macosx_version_min" "10.10.0"
> +
> +// RUN: rm -rf %t/SDKs/WatchOS3.0.sdk
> +// RUN: mkdir -p %t/SDKs/WatchOS3.0.sdk
> +// RUN: env SDKROOT=%t/SDKs/WatchOS3.0.sdk %clang %s -### 2>&1 \
> +// RUN:   | FileCheck --check-prefix=CHECK-WATCH %s
> +//
> +// CHECK-WATCH: clang
> +// CHECK-WATCH: "-cc1"
> +// CHECK-WATCH: -apple-watchos3.0.0"
> +// CHECK-WATCH: ld
> +// CHECK-WATCH: "-watchos_version_min" "3.0.0"
> +//
> +//
> +// RUN: rm -rf %t/SDKs/WatchSimulator3.0.sdk
> +// RUN: mkdir -p %t/SDKs/WatchSimulator3.0.sdk
> +// RUN: env SDKROOT=%t/SDKs/WatchSimulator3.0.sdk %clang %s -### 2>&1 \
> +// RUN:   | FileCheck --check-prefix=CHECK-WATCH-SIMULATOR %s
> +//
> +// CHECK-WATCH-SIMULATOR: clang
> +// CHECK-WATCH-SIMULATOR: "-cc1"
> +// CHECK-WATCH-SIMULATOR: -apple-watchos3.0.0-simulator"
> +// CHECK-WATCH-SIMULATOR: ld
> +// CHECK-WATCH-SIMULATOR: "-watchos_simulator_version_min" "3.0.0"
> +
> +// RUN: rm -rf %t/SDKs/AppleTVOS10.0.sdk
> +// RUN: mkdir -p %t/SDKs/AppleTVOS10.0.sdk
> +// RUN: env SDKROOT=%t/SDKs/AppleTVOS10.0.sdk %clang %s -### 2>&1 \
> +// RUN:   | FileCheck --check-prefix=CHECK-TV %s
> +//
> +// CHECK-TV: clang
> +// CHECK-TV: "-cc1"
> +// CHECK-TV: -apple-tvos10.0.0"
> +// CHECK-TV: ld
> +// CHECK-TV: "-tvos_version_min" "10.0.0"
> +//
> +//
> +// RUN: rm -rf %t/SDKs/AppleTVSimulator10.0.sdk
> +// RUN: mkdir -p %t/SDKs/AppleTVSimulator10.0.sdk
> +// RUN: env SDKROOT=%t/SDKs/AppleTVSimulator10.0.sdk %clang %s -### 2>&1 \
> +// RUN:   | FileCheck --check-prefix=CHECK-TV-SIMULATOR %s
> +//
> +// CHECK-TV-SIMULATOR: clang
> +// CHECK-TV-SIMULATOR: "-cc1"
> +// CHECK-TV-SIMULATOR: -apple-tvos10.0.0-simulator"
> +// CHECK-TV-SIMULATOR: ld
> +// CHECK-TV-SIMULATOR: "-tvos_simulator_version_min" "10.0.0"
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: r329113 - Add REQUIRES: darwin-system to test/Driver/darwin-sdkroot.c

2018-04-03 Thread Chandler Carruth via cfe-commits
See my reply to the original commit, but I think this is the wrong fix.

On Tue, Apr 3, 2018 at 2:13 PM Alex Lorenz via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: arphaman
> Date: Tue Apr  3 14:10:26 2018
> New Revision: 329113
>
> URL: http://llvm.org/viewvc/llvm-project?rev=329113=rev
> Log:
> Add REQUIRES: darwin-system to test/Driver/darwin-sdkroot.c
>
> The test from r329110 is for Darwin only
>
> Modified:
> cfe/trunk/test/Driver/darwin-sdkroot.c
>
> Modified: cfe/trunk/test/Driver/darwin-sdkroot.c
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/darwin-sdkroot.c?rev=329113=329112=329113=diff
>
> ==
> --- cfe/trunk/test/Driver/darwin-sdkroot.c (original)
> +++ cfe/trunk/test/Driver/darwin-sdkroot.c Tue Apr  3 14:10:26 2018
> @@ -1,4 +1,5 @@
>  // Check that SDKROOT is used to define the default for -isysroot on
> Darwin.
> +// REQUIRES: system-darwin
>  //
>  // RUN: rm -rf %t.tmpdir
>  // RUN: mkdir -p %t.tmpdir
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r329113 - Add REQUIRES: darwin-system to test/Driver/darwin-sdkroot.c

2018-04-03 Thread Alex Lorenz via cfe-commits
Author: arphaman
Date: Tue Apr  3 14:10:26 2018
New Revision: 329113

URL: http://llvm.org/viewvc/llvm-project?rev=329113=rev
Log:
Add REQUIRES: darwin-system to test/Driver/darwin-sdkroot.c

The test from r329110 is for Darwin only

Modified:
cfe/trunk/test/Driver/darwin-sdkroot.c

Modified: cfe/trunk/test/Driver/darwin-sdkroot.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/darwin-sdkroot.c?rev=329113=329112=329113=diff
==
--- cfe/trunk/test/Driver/darwin-sdkroot.c (original)
+++ cfe/trunk/test/Driver/darwin-sdkroot.c Tue Apr  3 14:10:26 2018
@@ -1,4 +1,5 @@
 // Check that SDKROOT is used to define the default for -isysroot on Darwin.
+// REQUIRES: system-darwin
 //
 // RUN: rm -rf %t.tmpdir
 // RUN: mkdir -p %t.tmpdir


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


[PATCH] D45152: [MinGW] Add option for disabling looking for a mingw gcc in PATH

2018-04-03 Thread Martin Storsjö via Phabricator via cfe-commits
mstorsjo added a comment.

In https://reviews.llvm.org/D45152#1056134, @rnk wrote:

> In https://reviews.llvm.org/D45152#1056122, @mstorsjo wrote:
>
> > In https://reviews.llvm.org/D45152#1055871, @rnk wrote:
> >
> > > Seems reasonable, looks good.
> >
> >
> > Any opinion on the wording of the option name?
>
>
> Maybe what we're trying to do is find the sysroot relative to clang, so an 
> option name phrased along those lines makes more sense? 
> --clang-in-sysroot-bin? --from-sysroot-bin? --assume-sysroot-bin? 
> --in-sysroot-bin?


That sounds sensible - and positive options is often better than negated/ignore 
etc. I think I prefer `--assume-sysroot-bin` out of those.


Repository:
  rC Clang

https://reviews.llvm.org/D45152



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


r329110 - [driver][darwin] Do not infer -simulator environment for non-simulator SDKs

2018-04-03 Thread Alex Lorenz via cfe-commits
Author: arphaman
Date: Tue Apr  3 13:50:05 2018
New Revision: 329110

URL: http://llvm.org/viewvc/llvm-project?rev=329110=rev
Log:
[driver][darwin] Do not infer -simulator environment for non-simulator SDKs

rdar://36369832

Modified:
cfe/trunk/lib/Driver/ToolChains/Darwin.cpp
cfe/trunk/test/Driver/darwin-sdkroot.c

Modified: cfe/trunk/lib/Driver/ToolChains/Darwin.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Darwin.cpp?rev=329110=329109=329110=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Darwin.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Darwin.cpp Tue Apr  3 13:50:05 2018
@@ -1211,6 +1211,9 @@ struct DarwinPlatform {
   /// Returns true if the target OS was explicitly specified.
   bool isExplicitlySpecified() const { return Kind <= DeploymentTargetEnv; }
 
+  /// Returns true if the simulator environment can be inferred from the arch.
+  bool canInferSimulatorFromArch() const { return Kind != InferredFromSDK; }
+
   /// Adds the -m-version-min argument to the compiler invocation.
   void addOSVersionMinArgument(DerivedArgList , const OptTable ) {
 if (Argument)
@@ -1280,8 +1283,12 @@ struct DarwinPlatform {
 return Result;
   }
   static DarwinPlatform createFromSDK(DarwinPlatformKind Platform,
-  StringRef Value) {
-return DarwinPlatform(InferredFromSDK, Platform, Value);
+  StringRef Value,
+  bool IsSimulator = false) {
+DarwinPlatform Result(InferredFromSDK, Platform, Value);
+if (IsSimulator)
+  Result.Environment = DarwinEnvironmentKind::Simulator;
+return Result;
   }
   static DarwinPlatform createFromArch(llvm::Triple::OSType OS,
StringRef Value) {
@@ -1437,14 +1444,20 @@ Optional inferDeployment
   if (StartVer != StringRef::npos && EndVer > StartVer) {
 StringRef Version = SDK.slice(StartVer, EndVer + 1);
 if (SDK.startswith("iPhoneOS") || SDK.startswith("iPhoneSimulator"))
-  return DarwinPlatform::createFromSDK(Darwin::IPhoneOS, Version);
+  return DarwinPlatform::createFromSDK(
+  Darwin::IPhoneOS, Version,
+  /*IsSimulator=*/SDK.startswith("iPhoneSimulator"));
 else if (SDK.startswith("MacOSX"))
   return DarwinPlatform::createFromSDK(Darwin::MacOS,

getSystemOrSDKMacOSVersion(Version));
 else if (SDK.startswith("WatchOS") || SDK.startswith("WatchSimulator"))
-  return DarwinPlatform::createFromSDK(Darwin::WatchOS, Version);
+  return DarwinPlatform::createFromSDK(
+  Darwin::WatchOS, Version,
+  /*IsSimulator=*/SDK.startswith("WatchSimulator"));
 else if (SDK.startswith("AppleTVOS") || SDK.startswith("AppleTVSimulator"))
-  return DarwinPlatform::createFromSDK(Darwin::TvOS, Version);
+  return DarwinPlatform::createFromSDK(
+  Darwin::TvOS, Version,
+  /*IsSimulator=*/SDK.startswith("AppleTVSimulator"));
   }
   return None;
 }
@@ -1645,6 +1658,7 @@ void Darwin::AddDeploymentTarget(Derived
   DarwinEnvironmentKind Environment = OSTarget->getEnvironment();
   // Recognize iOS targets with an x86 architecture as the iOS simulator.
   if (Environment == NativeEnvironment && Platform != MacOS &&
+  OSTarget->canInferSimulatorFromArch() &&
   (getTriple().getArch() == llvm::Triple::x86 ||
getTriple().getArch() == llvm::Triple::x86_64))
 Environment = Simulator;

Modified: cfe/trunk/test/Driver/darwin-sdkroot.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/darwin-sdkroot.c?rev=329110=329109=329110=diff
==
--- cfe/trunk/test/Driver/darwin-sdkroot.c (original)
+++ cfe/trunk/test/Driver/darwin-sdkroot.c Tue Apr  3 13:50:05 2018
@@ -51,12 +51,21 @@
 // CHECK-IPHONE: "-triple" "arm64-apple-ios8.0.0"
 // CHECK-IPHONE: ld
 // CHECK-IPHONE: "-iphoneos_version_min" "8.0.0"
+// RUN: env SDKROOT=%t/SDKs/iPhoneOS8.0.0.sdk %clang %s -### 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-IPHONE-X86 %s
+// CHECK-IPHONE-X86: clang
+// CHECK-IPHONE-X86: "-cc1"
+// CHECK-IPHONE-X86: -apple-ios8.0.0"
+// CHECK-IPHONE-X86: ld
+// CHECK-IPHONE-X86: "-iphoneos_version_min" "8.0.0"
 //
 //
 // RUN: rm -rf %t/SDKs/iPhoneSimulator8.0.sdk
 // RUN: mkdir -p %t/SDKs/iPhoneSimulator8.0.sdk
 // RUN: env SDKROOT=%t/SDKs/iPhoneSimulator8.0.sdk %clang -target 
x86_64-apple-darwin %s -### 2>&1 \
 // RUN:   | FileCheck --check-prefix=CHECK-SIMULATOR %s
+// RUN: env SDKROOT=%t/SDKs/iPhoneSimulator8.0.sdk %clang -arch x86_64 %s -### 
2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-SIMULATOR %s
 //
 // CHECK-SIMULATOR: clang
 // CHECK-SIMULATOR: "-cc1"
@@ -74,3 +83,49 @@
 // CHECK-MACOSX: "-triple" "x86_64-apple-macosx10.10.0"
 // CHECK-MACOSX: ld
 // CHECK-MACOSX: 

[PATCH] D44788: Add an option to support debug fission on implicit ThinLTO.

2018-04-03 Thread Yunlian Jiang via Phabricator via cfe-commits
yunlian updated this revision to Diff 140857.

https://reviews.llvm.org/D44788

Files:
  docs/ClangCommandLineReference.rst
  include/clang/Driver/Options.td
  lib/Driver/ToolChains/CommonArgs.cpp
  test/Driver/lto-dwo.c


Index: test/Driver/lto-dwo.c
===
--- /dev/null
+++ test/Driver/lto-dwo.c
@@ -0,0 +1,8 @@
+// Confirm that -glto-dwo-dir=DIR is passed to linker
+
+// RUN: %clang -target x86_64-unknown-linux -### %s -flto=thin 
-glto-dwo-dir=DIR 2> %t
+// RUN: FileCheck -check-prefix=CHECK-LINK-DWO-DIR < %t %s
+// RUN: FileCheck -check-prefix=CHECK-LINK-OBJCOPY < %t %s
+//
+// CHECK-LINK-DWO-DIR: "-plugin-opt=dwo_dir=DIR"
+// CHECK-LINK-OBJCOPY: "-plugin-opt=objcopy={{.*}}objcopy"
Index: lib/Driver/ToolChains/CommonArgs.cpp
===
--- lib/Driver/ToolChains/CommonArgs.cpp
+++ lib/Driver/ToolChains/CommonArgs.cpp
@@ -415,6 +415,16 @@
   if (IsThinLTO)
 CmdArgs.push_back("-plugin-opt=thinlto");
 
+  if (Arg *A = Args.getLastArg(options::OPT_glto_dwo_dir_EQ)) {
+const char *Objcopy =
+Args.MakeArgString(ToolChain.GetProgramPath(CLANG_DEFAULT_OBJCOPY));
+CmdArgs.push_back(
+Args.MakeArgString(Twine("-plugin-opt=objcopy=") + Objcopy));
+StringRef DWO_Dir = A->getValue();
+CmdArgs.push_back(
+Args.MakeArgString(Twine("-plugin-opt=dwo_dir=") + DWO_Dir));
+  }
+
   if (unsigned Parallelism = getLTOParallelism(Args, D))
 CmdArgs.push_back(
 Args.MakeArgString("-plugin-opt=jobs=" + Twine(Parallelism)));
Index: include/clang/Driver/Options.td
===
--- include/clang/Driver/Options.td
+++ include/clang/Driver/Options.td
@@ -1700,6 +1700,7 @@
 def gcolumn_info : Flag<["-"], "gcolumn-info">, Group, 
Flags<[CoreOption]>;
 def gno_column_info : Flag<["-"], "gno-column-info">, Group, 
Flags<[CoreOption]>;
 def gsplit_dwarf : Flag<["-"], "gsplit-dwarf">, Group;
+def glto_dwo_dir_EQ : Joined<["-"], "glto-dwo-dir=">, Group;
 def ggnu_pubnames : Flag<["-"], "ggnu-pubnames">, Group, 
Flags<[CC1Option]>;
 def gdwarf_aranges : Flag<["-"], "gdwarf-aranges">, Group;
 def gmodules : Flag <["-"], "gmodules">, Group,
Index: docs/ClangCommandLineReference.rst
===
--- docs/ClangCommandLineReference.rst
+++ docs/ClangCommandLineReference.rst
@@ -2587,6 +2587,8 @@
 
 .. option:: -gstrict-dwarf, -gno-strict-dwarf
 
+.. option:: -glto-dwo-dir=
+
 .. option:: -gz
 
 DWARF debug sections compression type


Index: test/Driver/lto-dwo.c
===
--- /dev/null
+++ test/Driver/lto-dwo.c
@@ -0,0 +1,8 @@
+// Confirm that -glto-dwo-dir=DIR is passed to linker
+
+// RUN: %clang -target x86_64-unknown-linux -### %s -flto=thin -glto-dwo-dir=DIR 2> %t
+// RUN: FileCheck -check-prefix=CHECK-LINK-DWO-DIR < %t %s
+// RUN: FileCheck -check-prefix=CHECK-LINK-OBJCOPY < %t %s
+//
+// CHECK-LINK-DWO-DIR: "-plugin-opt=dwo_dir=DIR"
+// CHECK-LINK-OBJCOPY: "-plugin-opt=objcopy={{.*}}objcopy"
Index: lib/Driver/ToolChains/CommonArgs.cpp
===
--- lib/Driver/ToolChains/CommonArgs.cpp
+++ lib/Driver/ToolChains/CommonArgs.cpp
@@ -415,6 +415,16 @@
   if (IsThinLTO)
 CmdArgs.push_back("-plugin-opt=thinlto");
 
+  if (Arg *A = Args.getLastArg(options::OPT_glto_dwo_dir_EQ)) {
+const char *Objcopy =
+Args.MakeArgString(ToolChain.GetProgramPath(CLANG_DEFAULT_OBJCOPY));
+CmdArgs.push_back(
+Args.MakeArgString(Twine("-plugin-opt=objcopy=") + Objcopy));
+StringRef DWO_Dir = A->getValue();
+CmdArgs.push_back(
+Args.MakeArgString(Twine("-plugin-opt=dwo_dir=") + DWO_Dir));
+  }
+
   if (unsigned Parallelism = getLTOParallelism(Args, D))
 CmdArgs.push_back(
 Args.MakeArgString("-plugin-opt=jobs=" + Twine(Parallelism)));
Index: include/clang/Driver/Options.td
===
--- include/clang/Driver/Options.td
+++ include/clang/Driver/Options.td
@@ -1700,6 +1700,7 @@
 def gcolumn_info : Flag<["-"], "gcolumn-info">, Group, Flags<[CoreOption]>;
 def gno_column_info : Flag<["-"], "gno-column-info">, Group, Flags<[CoreOption]>;
 def gsplit_dwarf : Flag<["-"], "gsplit-dwarf">, Group;
+def glto_dwo_dir_EQ : Joined<["-"], "glto-dwo-dir=">, Group;
 def ggnu_pubnames : Flag<["-"], "ggnu-pubnames">, Group, Flags<[CC1Option]>;
 def gdwarf_aranges : Flag<["-"], "gdwarf-aranges">, Group;
 def gmodules : Flag <["-"], "gmodules">, Group,
Index: docs/ClangCommandLineReference.rst
===
--- docs/ClangCommandLineReference.rst
+++ docs/ClangCommandLineReference.rst
@@ -2587,6 +2587,8 @@
 
 .. option:: -gstrict-dwarf, -gno-strict-dwarf
 
+.. option:: -glto-dwo-dir=
+
 .. option:: -gz
 
 DWARF debug sections 

[PATCH] D45152: [MinGW] Add option for disabling looking for a mingw gcc in PATH

2018-04-03 Thread Reid Kleckner via Phabricator via cfe-commits
rnk added a comment.

In https://reviews.llvm.org/D45152#1056122, @mstorsjo wrote:

> In https://reviews.llvm.org/D45152#1055871, @rnk wrote:
>
> > Seems reasonable, looks good.
>
>
> Any opinion on the wording of the option name?


Maybe what we're trying to do is find the sysroot relative to clang, so an 
option name phrased along those lines makes more sense? --clang-in-sysroot-bin? 
--from-sysroot-bin? --assume-sysroot-bin? --in-sysroot-bin?


Repository:
  rC Clang

https://reviews.llvm.org/D45152



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


[PATCH] D45152: [MinGW] Add option for disabling looking for a mingw gcc in PATH

2018-04-03 Thread Martin Storsjö via Phabricator via cfe-commits
mstorsjo added a comment.

In https://reviews.llvm.org/D45152#1055871, @rnk wrote:

> Seems reasonable, looks good.


Any opinion on the wording of the option name?


Repository:
  rC Clang

https://reviews.llvm.org/D45152



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


[PATCH] D44720: [clangd] Simplify fuzzy matcher (sequence alignment) by removing some condition checks.

2018-04-03 Thread Sam McCall via Phabricator via cfe-commits
sammccall added a comment.

In https://reviews.llvm.org/D44720#1055997, @MaskRay wrote:

> Glad you took another look. I don't want to yield, let's find another 
> reviewer :)


OK - the people with the most context on this particular code are ilya-biryukov 
and klimek (but klimek is out this week).
Others who write/review clangd stuff include hokein, malaperle, simark, 
bkramer. (ioeric is out for a few weeks).

I can give ilya or someone context on the specific changes we're looking at if 
that's useful.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D44720



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


[PATCH] D45179: [libc++] Add _LIBCPP_FORCE_NODISCARD define to force-enable nodiscard in pre-C++17

2018-04-03 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added a comment.

In https://reviews.llvm.org/D45179#1056108, @Quuxplusone wrote:

> > Opt-in is an enhancement. Of course, it would be nice to always default it 
> > to on, but as it was disscussed with @mclow.lists, this is simply not going 
> > to happen. This is the best we'll get.
>
> Is @mclow.lists on record anywhere as saying that, that you could link to?


That particular disscussion was in IRC, so no, i can not link/paste.

> I ask because I haven't seen him commenting on these patches.



> At the moment, it seems like you're alone in both pushing these patches and 
> simultaneously arguing that any effort is futile. :)

:)


Repository:
  rCXX libc++

https://reviews.llvm.org/D45179



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


[PATCH] D45179: [libc++] Add _LIBCPP_FORCE_NODISCARD define to force-enable nodiscard in pre-C++17

2018-04-03 Thread Arthur O'Dwyer via Phabricator via cfe-commits
Quuxplusone added a comment.

>> If we must have an opt-in/out mechanism (which I don't believe we do)
> 
> Yes, we do. Opt-out is pre-existing, and removing it would be an 
> [unacceptable] regression.

Ah, I see now that you weren't the originator of 
`_LIBCPP_DISABLE_NODISCARD_AFTER_CXX17`; that existed on the left-hand side of 
this diff already. Okay, I don't object to keeping it around for historical 
interest.

> Opt-in is an enhancement. Of course, it would be nice to always default it to 
> on, but as it was disscussed with @mclow.lists, this is simply not going to 
> happen. This is the best we'll get.

Is @mclow.lists on record anywhere as saying that, that you could link to? I 
ask because I haven't seen him commenting on these patches. At the moment, it 
seems like you're alone in both pushing these patches and simultaneously 
arguing that any effort is futile. :)

>>   #ifdef _LIBCPP_NODISCARD
>>  // the user has given us their preferred spelling; use it 
>> unconditionally
> 
> So you propose to shift the burden of picking which define to use to each and 
> every libc++ user

Not at all!  I merely suggested that rather than having three different macros 
concerned with the spelling of `nodiscard`, you reduce it to *one* macro: 
`_LIBCPP_NODISCARD`. There would be a "sensible default" (namely, whatever 
spelling Does The Right Thing on the detected compiler), and then users who 
didn't want that default would be free to override it by passing `-D` on the 
command line. The `#ifdef` I suggested is a clean, concise way of allowing the 
user's explicit choice to override the libc++-provided "sensible default", no 
matter whether the user is trying to opt-in on an unsupported compiler 
(`-D_LIBCPP_NODISCARD='[[foobar::nodiscard]]'`) or opt-out on a supported 
compiler (`-D_LIBCPP_NODISCARD=''`). It would be a way to eliminate the soup of 
`ENABLE_` and `DISABLE_` macros.

Of course the benefit of this idea decreases if we must preserve 
`_LIBCPP_DISABLE_NODISCARD_AFTER_CXX17` for historical reasons anyway.


Repository:
  rCXX libc++

https://reviews.llvm.org/D45179



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


[PATCH] D45163: [Sema] -Wunused-value: diagnose unused std::move() call results.

2018-04-03 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added a comment.

In https://reviews.llvm.org/D45163#1056044, @rjmccall wrote:

> It seems reasonable to ask libc++ to use 
> `__attribute__((warn_unused_result))` if `[[nodiscard]]` is unavailable.


https://reviews.llvm.org/D45179 should hopefully add an **opt-in** define to 
allow doing just that. But it will then have to be enabled in the LLVM 
buildsystem.

In https://reviews.llvm.org/D45163#1056074, @Quuxplusone wrote:

> In https://reviews.llvm.org/D45163#1055957, @lebedev.ri wrote:
>
> > In https://reviews.llvm.org/D45163#1055856, @rjmccall wrote:
> >
> > > Well, we should feel welcome to submit patches to the C++ library 
> > > implementations, I think.  I can understand why Marshall is waiting to 
> > > just do this until he gets a comprehensive committee paper, but he might 
> > > consider taking a patch in the meantime.
> >
> >
> > That has been discussed, and it's not going to happen. Ask him if you want 
> > more info.
>
>
> You say a library patch is not going to happen, but isn't that library patch 
> literally https://reviews.llvm.org/D45179, which has been accepted (although 
> I just left a comment explaining why the current macro-soup is suboptimal)?


We may be talking about different things here.
I'm simply pointing out that libc++ will not be adding `nodiscard` attribute to 
functions unless it is mandated by the standard,
and that it *has* to be opt-in for earlier standards. I'm not saying that just 
to argue, i'm literally retranslating what @mclow.lists has said, it's his 
words.


Repository:
  rC Clang

https://reviews.llvm.org/D45163



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


[PATCH] D45179: [libc++] Add _LIBCPP_FORCE_NODISCARD define to force-enable nodiscard in pre-C++17

2018-04-03 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added inline comments.



Comment at: test/libcxx/diagnostics/force_nodiscard.fail.cpp:15
+// MODULES_DEFINES: _LIBCPP_FORCE_NODISCARD
+#define _LIBCPP_FORCE_NODISCARD
+#include <__config>

Quuxplusone wrote:
> What is the purpose of `_LIBCPP_FORCE_NODISCARD`?
> On one of your other nodiscard-related reviews, @EricWF suggested that we 
> should warn all the time, even e.g. on a discarded `std::move(x)` in C++11, 
> or a discarded `vec.empty()` in C++03. And *maybe* we could provide an 
> opt-out mechanism, but honestly *I* don't see why anyone would want to opt 
> out.
> `_LIBCPP_FORCE_NODISCARD` smells like an opt-in mechanism, which I would 
> think is the opposite of what we want.
> _LIBCPP_FORCE_NODISCARD smells like an opt-in mechanism
Correct.

> And *maybe* we could provide an opt-out mechanism, but honestly *I* don't see 
> why anyone would want to opt out.
I agree.

> which I would think is the opposite of what we want.
Also correct.



Comment at: test/libcxx/diagnostics/force_nodiscard.pass.cpp:16
+// MODULES_DEFINES: _LIBCPP_FORCE_NODISCARD
+#define _LIBCPP_DISABLE_NODISCARD_AFTER_CXX17
+#define _LIBCPP_FORCE_NODISCARD

Quuxplusone wrote:
> What is the purpose of `_LIBCPP_DISABLE_NODISCARD_AFTER_CXX17`? I guess I 
> could understand a blanket opt-in "please don't warn me about discarded 
> [[nodiscard]] results"; but that should be (and is) spelled 
> `-Wno-unused-result`, and it has nothing to do with C++17.
> 
> I like how this patch defines `_LIBCPP_NODISCARD` in non-C++17 modes; that's 
> going to be very useful. But I think all these opt-in mechanisms are 
> confusing and not-helpful.
> 
> If we must have an opt-in/out mechanism (which I don't believe we do), please 
> consider adding the following two lines to `<__config>` and removing the rest:
> 
> #ifdef _LIBCPP_NODISCARD
> // the user has given us their preferred spelling; use it 
> unconditionally
> #elif __has_cpp_attribute(nodiscard) && _LIBCPP_STD_VER > 17
> [... etc etc ...]
> 
> If we must have an opt-in/out mechanism (which I don't believe we do)

Yes, we do.
Opt-out is pre-existing, and removing it would be an [unacceptable] regression.
Opt-in is an enhancement. Of course, it would be nice to always default it to 
on,
but as it was disscussed with @mclow.lists, this is simply not going to happen.
This is the best we'll get.

```
#ifdef _LIBCPP_NODISCARD
// the user has given us their preferred spelling; use it unconditionally
```
So you propose to shift the burden of picking which define to use to each and 
every
libc++ user (who wants to enable nodiscard attribute for pre-C++17/whatever) 
out there?
I really don't see how that would be better.


Repository:
  rCXX libc++

https://reviews.llvm.org/D45179



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


[PATCH] D45202: [X86] Replacing X86-specific floor and ceil vector intrinsics with generic LLVM intrinsics

2018-04-03 Thread Craig Topper via Phabricator via cfe-commits
craig.topper added inline comments.



Comment at: include/clang/Basic/BuiltinsX86.def:951
 TARGET_BUILTIN(__builtin_ia32_rndscalepd_mask, "V8dV8dIiV8dUcIi", "", 
"avx512f")
+TARGET_BUILTIN(__builtin_ia32_floorps_mask, "V16fV16fV16fUs", "", "avx512f")
+TARGET_BUILTIN(__builtin_ia32_floorpd_mask, "V8dV8dV8dUc", "", "avx512f")

I'd prefer CGBuiltin to detect the specific immediates on the rndscale value. 
Primarily because we should be able to optimize _mm512_roundscale_pd when the 
ceil/floor immediate is used.


Repository:
  rC Clang

https://reviews.llvm.org/D45202



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


[PATCH] D45163: [Sema] -Wunused-value: diagnose unused std::move() call results.

2018-04-03 Thread Arthur O'Dwyer via Phabricator via cfe-commits
Quuxplusone added a comment.

In https://reviews.llvm.org/D45163#1055957, @lebedev.ri wrote:

> In https://reviews.llvm.org/D45163#1055856, @rjmccall wrote:
>
> > Well, we should feel welcome to submit patches to the C++ library 
> > implementations, I think.  I can understand why Marshall is waiting to just 
> > do this until he gets a comprehensive committee paper, but he might 
> > consider taking a patch in the meantime.
>
>
> That has been discussed, and it's not going to happen. Ask him if you want 
> more info.


You say a library patch is not going to happen, but isn't that library patch 
literally https://reviews.llvm.org/D45179, which has been accepted (although I 
just left a comment explaining why the current macro-soup is suboptimal)?

> TLDW: `std::move()` is "The Assign Operator (`a = b;`) of RAII". It would be 
> good to diagnose such a problem, and not just rely that some day the std libs 
> will mark it with the attribute.
>  BTW, even when they do, even for libcxx, it won't be of any immediate use to 
> LLVM, we will need to provide a define (see https://reviews.llvm.org/D45179) 
> to actually enable that attribute, because LLVM is using C++11, not 
> C++17/something...

Yes, but that patch (which you've written in https://reviews.llvm.org/D45179) 
is essentially just "if C++17, `[[nodiscard]]`, else 
`__attribute__((warn_unused_result))`." The library vendor is completely free 
to mark nodiscard-ish function with [[nodiscard]] or any other attribute they 
want to. And if I'm not mistaken, https://reviews.llvm.org/D45179 is a step in 
that direction.


Repository:
  rC Clang

https://reviews.llvm.org/D45163



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


[PATCH] D45179: [libc++] Add _LIBCPP_FORCE_NODISCARD define to force-enable nodiscard in pre-C++17

2018-04-03 Thread Arthur O'Dwyer via Phabricator via cfe-commits
Quuxplusone added inline comments.



Comment at: test/libcxx/diagnostics/force_nodiscard.fail.cpp:15
+// MODULES_DEFINES: _LIBCPP_FORCE_NODISCARD
+#define _LIBCPP_FORCE_NODISCARD
+#include <__config>

What is the purpose of `_LIBCPP_FORCE_NODISCARD`?
On one of your other nodiscard-related reviews, @EricWF suggested that we 
should warn all the time, even e.g. on a discarded `std::move(x)` in C++11, or 
a discarded `vec.empty()` in C++03. And *maybe* we could provide an opt-out 
mechanism, but honestly *I* don't see why anyone would want to opt out.
`_LIBCPP_FORCE_NODISCARD` smells like an opt-in mechanism, which I would think 
is the opposite of what we want.



Comment at: test/libcxx/diagnostics/force_nodiscard.pass.cpp:16
+// MODULES_DEFINES: _LIBCPP_FORCE_NODISCARD
+#define _LIBCPP_DISABLE_NODISCARD_AFTER_CXX17
+#define _LIBCPP_FORCE_NODISCARD

What is the purpose of `_LIBCPP_DISABLE_NODISCARD_AFTER_CXX17`? I guess I could 
understand a blanket opt-in "please don't warn me about discarded [[nodiscard]] 
results"; but that should be (and is) spelled `-Wno-unused-result`, and it has 
nothing to do with C++17.

I like how this patch defines `_LIBCPP_NODISCARD` in non-C++17 modes; that's 
going to be very useful. But I think all these opt-in mechanisms are confusing 
and not-helpful.

If we must have an opt-in/out mechanism (which I don't believe we do), please 
consider adding the following two lines to `<__config>` and removing the rest:

#ifdef _LIBCPP_NODISCARD
// the user has given us their preferred spelling; use it 
unconditionally
#elif __has_cpp_attribute(nodiscard) && _LIBCPP_STD_VER > 17
[... etc etc ...]



Repository:
  rCXX libc++

https://reviews.llvm.org/D45179



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


[PATCH] D45163: [Sema] -Wunused-value: diagnose unused std::move() call results.

2018-04-03 Thread John McCall via Phabricator via cfe-commits
rjmccall added a comment.

Trust me, I understand that this is an important function, but a lot of 
functions are important, and we're not going to hardcode knowledge about all of 
them in the compiler.

It seems reasonable to ask libc++ to use `__attribute__((warn_unused_result))` 
if `[[nodiscard]]` is unavailable.


Repository:
  rC Clang

https://reviews.llvm.org/D45163



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


[PATCH] D45223: [CUDA] Fix overloading resolution failure due to kernel calling convention

2018-04-03 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl created this revision.
yaxunl added reviewers: rjmccall, tra.

The following test causes overloading resolution failure in clang due to
missing kernel calling convention in the function pointer type.

  template 
  __global__ void EmptyKernel(void) {}
  
  struct Dummy {
/// Type definition of the EmptyKernel kernel entry point
typedef void (*EmptyKernelPtr)();
EmptyKernelPtr Empty() { return EmptyKernel; } 
  };

This happens before DRE is created. The fix is to drop the kernel
calling convention when converting function types.


https://reviews.llvm.org/D45223

Files:
  lib/Sema/SemaOverload.cpp
  test/CodeGenCUDA/kernel-amdgcn.cu


Index: test/CodeGenCUDA/kernel-amdgcn.cu
===
--- test/CodeGenCUDA/kernel-amdgcn.cu
+++ test/CodeGenCUDA/kernel-amdgcn.cu
@@ -15,15 +15,27 @@
   non_kernel();
 }
 
+// CHECK: define amdgpu_kernel void @_Z11EmptyKernelIvEvv
+template 
+__global__ void EmptyKernel(void) {}
+
+struct Dummy {
+  /// Type definition of the EmptyKernel kernel entry point
+  typedef void (*EmptyKernelPtr)();
+  EmptyKernelPtr Empty() { return EmptyKernel; } 
+};
+
 // CHECK: define amdgpu_kernel void @_Z15template_kernelI1AEvT_
 template
 __global__ void template_kernel(T x) {}
 
 void launch(void *f);
 
 int main() {
+  Dummy D;
   launch((void*)A::kernel);
   launch((void*)kernel);
   launch((void*)template_kernel);
+  launch((void*)D.Empty());
   return 0;
 }
Index: lib/Sema/SemaOverload.cpp
===
--- lib/Sema/SemaOverload.cpp
+++ lib/Sema/SemaOverload.cpp
@@ -1471,16 +1471,26 @@
 Changed = true;
   }
 
-  // Drop 'noexcept' if not present in target type.
   if (const auto *FromFPT = dyn_cast(FromFn)) {
 const auto *ToFPT = cast(ToFn);
+
+// Drop 'noexcept' if not present in target type.
 if (FromFPT->isNothrow(Context) && !ToFPT->isNothrow(Context)) {
   FromFn = cast(
   Context.getFunctionTypeWithExceptionSpec(QualType(FromFPT, 0),
EST_None)
  .getTypePtr());
   Changed = true;
 }
+
+// Drop cuda_kernel calling convention since it is invisible in AST.
+if (FromFPT->getCallConv() == CC_CUDAKernel &&
+FromFPT->getCallConv() != ToFPT->getCallConv()) {
+  FromFn = Context.adjustFunctionType(
+  FromFn, FromEInfo.withCallingConv(ToFPT->getCallConv()));
+  Changed = true;
+}
+
 // Convert FromFPT's ExtParameterInfo if necessary. The conversion is valid
 // only if the ExtParameterInfo lists of the two function prototypes can be
 // merged and the merged list is identical to ToFPT's ExtParameterInfo 
list.


Index: test/CodeGenCUDA/kernel-amdgcn.cu
===
--- test/CodeGenCUDA/kernel-amdgcn.cu
+++ test/CodeGenCUDA/kernel-amdgcn.cu
@@ -15,15 +15,27 @@
   non_kernel();
 }
 
+// CHECK: define amdgpu_kernel void @_Z11EmptyKernelIvEvv
+template 
+__global__ void EmptyKernel(void) {}
+
+struct Dummy {
+  /// Type definition of the EmptyKernel kernel entry point
+  typedef void (*EmptyKernelPtr)();
+  EmptyKernelPtr Empty() { return EmptyKernel; } 
+};
+
 // CHECK: define amdgpu_kernel void @_Z15template_kernelI1AEvT_
 template
 __global__ void template_kernel(T x) {}
 
 void launch(void *f);
 
 int main() {
+  Dummy D;
   launch((void*)A::kernel);
   launch((void*)kernel);
   launch((void*)template_kernel);
+  launch((void*)D.Empty());
   return 0;
 }
Index: lib/Sema/SemaOverload.cpp
===
--- lib/Sema/SemaOverload.cpp
+++ lib/Sema/SemaOverload.cpp
@@ -1471,16 +1471,26 @@
 Changed = true;
   }
 
-  // Drop 'noexcept' if not present in target type.
   if (const auto *FromFPT = dyn_cast(FromFn)) {
 const auto *ToFPT = cast(ToFn);
+
+// Drop 'noexcept' if not present in target type.
 if (FromFPT->isNothrow(Context) && !ToFPT->isNothrow(Context)) {
   FromFn = cast(
   Context.getFunctionTypeWithExceptionSpec(QualType(FromFPT, 0),
EST_None)
  .getTypePtr());
   Changed = true;
 }
+
+// Drop cuda_kernel calling convention since it is invisible in AST.
+if (FromFPT->getCallConv() == CC_CUDAKernel &&
+FromFPT->getCallConv() != ToFPT->getCallConv()) {
+  FromFn = Context.adjustFunctionType(
+  FromFn, FromEInfo.withCallingConv(ToFPT->getCallConv()));
+  Changed = true;
+}
+
 // Convert FromFPT's ExtParameterInfo if necessary. The conversion is valid
 // only if the ExtParameterInfo lists of the two function prototypes can be
 // merged and the merged list is identical to ToFPT's ExtParameterInfo list.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org

[PATCH] D44720: [clangd] Simplify fuzzy matcher (sequence alignment) by removing some condition checks.

2018-04-03 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added a comment.

Glad you took another look. I don't want to yield, let's find another reviewer 
:)




Comment at: clangd/FuzzyMatch.cpp:230
 void FuzzyMatcher::buildGraph() {
+  Scores[0][0][Miss] = Scores[0][0][Match] = {0, Miss};
   for (int W = 0; W < WordN; ++W) {

sammccall wrote:
> MaskRay wrote:
> > MaskRay wrote:
> > > sammccall wrote:
> > > > MaskRay wrote:
> > > > > sammccall wrote:
> > > > > > why this change?
> > > > > > this has also been moved from the cheaper constructor to the more 
> > > > > > expensive per-match call. (also the diagonal assignment added in 
> > > > > > the next loop)
> > > > > > 
> > > > > > Also, shouldn't [0][0][Match] be AwfulScore?
> > > > > > 
> > > > > "The more expensive per-match call" is just two value assignments.
> > > > > 
> > > > > I have removed the expensive table initialization in the constructor.
> > > > > 
> > > > > [0][0][*] can be any value.
> > > > > "The more expensive per-match call" is just two value assignments.
> > > > Oops, sorry - by "more expensive" I mean "called thousands of times 
> > > > more often".
> > > > 
> > > > > I have removed the expensive table initialization in the constructor.
> > > > I don't want to be rude, but I asked why you changed this, and you 
> > > > didn't answer. Unless there's a strong reason, I'd prefer to revert 
> > > > this change, as I find this harder to reason about.
> > > > (Roughly: in the old version of the code, any data that didn't need to 
> > > > change for the life of the object was initialized in the constructor. 
> > > > That way I didn't need to worry what was performance-critical and what 
> > > > wasn't - match() only did what was strictly necessary).
> > > > 
> > > > > [0][0][*] can be any value.
> > > > Can you please explain why?
> > > > Oops, sorry - by "more expensive" I mean "called thousands of times 
> > > > more often".
> > > 
> > > It is true that `Scores[0][0][Miss] = Scores[0][0][Match] = {0, Miss};` 
> > > is the cost incurred for each word.
> > > 
> > > But **it is not full table initialization**, it is just two variable 
> > > assignments. And we will assign to other values of the first row 
> > > `Scores[0][*][*]` in the following loop. The old scatters the table 
> > > construction to **two places**, the constructor and this dynamic 
> > > programming site.
> > > [0][0][*] can be any value.
> > 
> > Can you please explain why?
> > 
> > `Scores[0][0][*]` is the initial value which will be propagated to all 
> > other values in the table.
> > The relative difference of pairwise values in the table is a constant 
> > whatever initial value is chosen.
> > 
> > If you ignore the max clamp you used later, the initial value does not 
> > matter.
> > 
> > 
> Is it not possible that we'll choose a best path starting at 
> Scores[0][0][Match]?
> This is invalid, and previously that was signaled by giving that cell 
> AwfulScore, which ensures any path that emerges from it isAwful.
I think `Scores[0][0][Match]` is as valid as `Scores[0][0][Miss]`. The argument 
is that a `Miss` state should ensure a skipped position in Text. When there is 
zero position, it cannot be `Miss`ed. A dynamic programming algorithm does not 
necessarily have only one valid initial state (thinking about the constant term 
in an indefinite integral). I will choose the one which makes more sense if 
such initial state exists or if there is one that simplifies the case. In this 
case treating both of them as valid simplifies the code.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D44720



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


[PATCH] D25001: [Module] Merge function prototype with a non-prototype function declaration

2018-04-03 Thread Akira Hatanaka via Phabricator via cfe-commits
ahatanak abandoned this revision.
ahatanak added a comment.

This appears to have been fixed.


https://reviews.llvm.org/D25001



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


[PATCH] D44720: [clangd] Simplify fuzzy matcher (sequence alignment) by removing some condition checks.

2018-04-03 Thread Sam McCall via Phabricator via cfe-commits
sammccall added a comment.

Thanks for your work on this patch!
I think there a several useful improvements here, which I'd love to see landed. 
Particularly the logic around matches that end early is much better.

There are also places that change existing design decisions in ways that don't 
seem to be clear improvements: doing extra work (albeit minor) at `match()` 
time, and using different naming conventions for indexes in `dumpLast`. I see 
you have strong feelings about these and I do think I understand your 
arguments, but don't agree as discussed above.

Where should we go from here? One option is to land the pieces we agree on. But 
it's your patch, and if you'd like an opinion from another clangd maintainer 
that's fine too; happy to help with that.




Comment at: clangd/FuzzyMatch.cpp:230
 void FuzzyMatcher::buildGraph() {
+  Scores[0][0][Miss] = Scores[0][0][Match] = {0, Miss};
   for (int W = 0; W < WordN; ++W) {

MaskRay wrote:
> MaskRay wrote:
> > sammccall wrote:
> > > MaskRay wrote:
> > > > sammccall wrote:
> > > > > why this change?
> > > > > this has also been moved from the cheaper constructor to the more 
> > > > > expensive per-match call. (also the diagonal assignment added in the 
> > > > > next loop)
> > > > > 
> > > > > Also, shouldn't [0][0][Match] be AwfulScore?
> > > > > 
> > > > "The more expensive per-match call" is just two value assignments.
> > > > 
> > > > I have removed the expensive table initialization in the constructor.
> > > > 
> > > > [0][0][*] can be any value.
> > > > "The more expensive per-match call" is just two value assignments.
> > > Oops, sorry - by "more expensive" I mean "called thousands of times more 
> > > often".
> > > 
> > > > I have removed the expensive table initialization in the constructor.
> > > I don't want to be rude, but I asked why you changed this, and you didn't 
> > > answer. Unless there's a strong reason, I'd prefer to revert this change, 
> > > as I find this harder to reason about.
> > > (Roughly: in the old version of the code, any data that didn't need to 
> > > change for the life of the object was initialized in the constructor. 
> > > That way I didn't need to worry what was performance-critical and what 
> > > wasn't - match() only did what was strictly necessary).
> > > 
> > > > [0][0][*] can be any value.
> > > Can you please explain why?
> > > Oops, sorry - by "more expensive" I mean "called thousands of times more 
> > > often".
> > 
> > It is true that `Scores[0][0][Miss] = Scores[0][0][Match] = {0, Miss};` is 
> > the cost incurred for each word.
> > 
> > But **it is not full table initialization**, it is just two variable 
> > assignments. And we will assign to other values of the first row 
> > `Scores[0][*][*]` in the following loop. The old scatters the table 
> > construction to **two places**, the constructor and this dynamic 
> > programming site.
> > [0][0][*] can be any value.
> 
> Can you please explain why?
> 
> `Scores[0][0][*]` is the initial value which will be propagated to all other 
> values in the table.
> The relative difference of pairwise values in the table is a constant 
> whatever initial value is chosen.
> 
> If you ignore the max clamp you used later, the initial value does not matter.
> 
> 
Is it not possible that we'll choose a best path starting at 
Scores[0][0][Match]?
This is invalid, and previously that was signaled by giving that cell 
AwfulScore, which ensures any path that emerges from it isAwful.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D44720



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


[PATCH] D45117: [analyzer] Fix diagnostics in callees of interesting callees.

2018-04-03 Thread Phabricator via Phabricator via cfe-commits
This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit rL329102: [analyzer] Fix diagnostics in callees of interesting 
callees. (authored by dergachev, committed by ).
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D45117?vs=140513=140840#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D45117

Files:
  cfe/trunk/lib/StaticAnalyzer/Core/BugReporter.cpp
  cfe/trunk/test/Analysis/inlining/path-notes.c

Index: cfe/trunk/test/Analysis/inlining/path-notes.c
===
--- cfe/trunk/test/Analysis/inlining/path-notes.c
+++ cfe/trunk/test/Analysis/inlining/path-notes.c
@@ -140,6 +140,22 @@
// expected-note@-1 {{Dereference of null pointer}}
 }
 
+void boringCallee() {
+}
+
+void interestingCallee(int *x) {
+  *x = 0; // expected-note{{The value 0 is assigned to 'x'}}
+  boringCallee(); // no-note
+}
+
+int testBoringCalleeOfInterestingCallee() {
+  int x;
+  interestingCallee(); // expected-note{{Calling 'interestingCallee'}}
+ // expected-note@-1{{Returning from 'interestingCallee'}}
+  return 1 / x; // expected-warning{{Division by zero}}
+// expected-note@-1{{Division by zero}}
+}
+
 // CHECK:  diagnostics
 // CHECK-NEXT:  
 // CHECK-NEXT:   
@@ -3377,4 +3393,290 @@
 // CHECK-NEXT:file0
 // CHECK-NEXT:   
 // CHECK-NEXT:   
+// CHECK-NEXT:   
+// CHECK-NEXT:path
+// CHECK-NEXT:
+// CHECK-NEXT: 
+// CHECK-NEXT:  kindcontrol
+// CHECK-NEXT:  edges
+// CHECK-NEXT:   
+// CHECK-NEXT:
+// CHECK-NEXT: start
+// CHECK-NEXT:  
+// CHECK-NEXT:   
+// CHECK-NEXT:line152
+// CHECK-NEXT:col3
+// CHECK-NEXT:file0
+// CHECK-NEXT:   
+// CHECK-NEXT:   
+// CHECK-NEXT:line152
+// CHECK-NEXT:col5
+// CHECK-NEXT:file0
+// CHECK-NEXT:   
+// CHECK-NEXT:  
+// CHECK-NEXT: end
+// CHECK-NEXT:  
+// CHECK-NEXT:   
+// CHECK-NEXT:line153
+// CHECK-NEXT:col3
+// CHECK-NEXT:file0
+// CHECK-NEXT:   
+// CHECK-NEXT:   
+// CHECK-NEXT:line153
+// CHECK-NEXT:col19
+// CHECK-NEXT:file0
+// CHECK-NEXT:   
+// CHECK-NEXT:  
+// CHECK-NEXT:
+// CHECK-NEXT:   
+// CHECK-NEXT: 
+// CHECK-NEXT: 
+// CHECK-NEXT:  kindevent
+// CHECK-NEXT:  location
+// CHECK-NEXT:  
+// CHECK-NEXT:   line153
+// CHECK-NEXT:   col3
+// CHECK-NEXT:   file0
+// CHECK-NEXT:  
+// CHECK-NEXT:  ranges
+// CHECK-NEXT:  
+// CHECK-NEXT:
+// CHECK-NEXT: 
+// CHECK-NEXT:  line153
+// CHECK-NEXT:  col3
+// CHECK-NEXT:  file0
+// CHECK-NEXT: 
+// CHECK-NEXT: 
+// CHECK-NEXT:  line153
+// CHECK-NEXT:  col23
+// CHECK-NEXT:  file0
+// CHECK-NEXT: 
+// CHECK-NEXT:
+// CHECK-NEXT:  
+// CHECK-NEXT:  depth0
+// CHECK-NEXT:  extended_message
+// CHECK-NEXT:  Calling interestingCallee
+// CHECK-NEXT:  message
+// CHECK-NEXT:  Calling interestingCallee
+// CHECK-NEXT: 
+// CHECK-NEXT: 
+// CHECK-NEXT:  kindevent
+// CHECK-NEXT:  location
+// CHECK-NEXT:  
+// CHECK-NEXT:   line146
+// CHECK-NEXT:   col1
+// CHECK-NEXT:   file0
+// CHECK-NEXT:  
+// CHECK-NEXT:  depth1
+// CHECK-NEXT:  extended_message
+// CHECK-NEXT:  Entered call from testBoringCalleeOfInterestingCallee
+// CHECK-NEXT:  message
+// CHECK-NEXT:  Entered call from testBoringCalleeOfInterestingCallee
+// CHECK-NEXT: 
+// CHECK-NEXT: 
+// CHECK-NEXT:  kindcontrol
+// CHECK-NEXT:  edges
+// CHECK-NEXT:   
+// CHECK-NEXT:
+// CHECK-NEXT: start
+// CHECK-NEXT:  
+// CHECK-NEXT:   
+// CHECK-NEXT:line146
+// CHECK-NEXT:col1
+// CHECK-NEXT:file0
+// CHECK-NEXT:   
+// CHECK-NEXT:   
+// CHECK-NEXT:line146
+// CHECK-NEXT:col4
+// CHECK-NEXT:file0
+// CHECK-NEXT:   
+// CHECK-NEXT:  
+// CHECK-NEXT: end
+// CHECK-NEXT:  
+// CHECK-NEXT:   
+// CHECK-NEXT:line147
+// CHECK-NEXT:col3
+// CHECK-NEXT:file0
+// CHECK-NEXT:   
+// CHECK-NEXT:   
+// CHECK-NEXT:line147
+// CHECK-NEXT:col3
+// CHECK-NEXT:file0
+// CHECK-NEXT:   
+// CHECK-NEXT:  
+// CHECK-NEXT:
+// CHECK-NEXT:   
+// CHECK-NEXT: 
+// CHECK-NEXT: 
+// CHECK-NEXT:  kindevent
+// CHECK-NEXT:  location
+// CHECK-NEXT:  
+// CHECK-NEXT:   line147
+// CHECK-NEXT:   

r329102 - [analyzer] Fix diagnostics in callees of interesting callees.

2018-04-03 Thread Artem Dergachev via cfe-commits
Author: dergachev
Date: Tue Apr  3 11:52:30 2018
New Revision: 329102

URL: http://llvm.org/viewvc/llvm-project?rev=329102=rev
Log:
[analyzer] Fix diagnostics in callees of interesting callees.

removeUnneededCalls() is responsible for removing path diagnostic pieces within
functions that don't contain "interesting" events. It makes bug reports
much tidier.

When a stack frame is known to be interesting, the function doesn't descend
into it to prune anything within it, even other callees that are totally boring.

Fix the function to prune boring callees in interesting stack frames.

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

Modified:
cfe/trunk/lib/StaticAnalyzer/Core/BugReporter.cpp
cfe/trunk/test/Analysis/inlining/path-notes.c

Modified: cfe/trunk/lib/StaticAnalyzer/Core/BugReporter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Core/BugReporter.cpp?rev=329102=329101=329102=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Core/BugReporter.cpp (original)
+++ cfe/trunk/lib/StaticAnalyzer/Core/BugReporter.cpp Tue Apr  3 11:52:30 2018
@@ -192,8 +192,9 @@ using LocationContextMap =
 /// that aren't needed.  Return true if afterwards the path contains
 /// "interesting stuff" which means it shouldn't be pruned from the parent 
path.
 static bool removeUnneededCalls(PathPieces , BugReport *R,
-LocationContextMap ) {
-  bool containsSomethingInteresting = false;
+LocationContextMap ,
+bool IsInteresting = false) {
+  bool containsSomethingInteresting = IsInteresting;
   const unsigned N = pieces.size();
 
   for (unsigned i = 0 ; i < N ; ++i) {
@@ -207,12 +208,8 @@ static bool removeUnneededCalls(PathPiec
 auto  = cast(*piece);
 // Check if the location context is interesting.
 assert(LCM.count());
-if (R->isInteresting(LCM[])) {
-  containsSomethingInteresting = true;
-  break;
-}
-
-if (!removeUnneededCalls(call.path, R, LCM))
+if (!removeUnneededCalls(call.path, R, LCM,
+ R->isInteresting(LCM[])))
   continue;
 
 containsSomethingInteresting = true;
@@ -220,7 +217,7 @@ static bool removeUnneededCalls(PathPiec
   }
   case PathDiagnosticPiece::Macro: {
 auto  = cast(*piece);
-if (!removeUnneededCalls(macro.subPieces, R, LCM))
+if (!removeUnneededCalls(macro.subPieces, R, LCM, IsInteresting))
   continue;
 containsSomethingInteresting = true;
 break;

Modified: cfe/trunk/test/Analysis/inlining/path-notes.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Analysis/inlining/path-notes.c?rev=329102=329101=329102=diff
==
--- cfe/trunk/test/Analysis/inlining/path-notes.c (original)
+++ cfe/trunk/test/Analysis/inlining/path-notes.c Tue Apr  3 11:52:30 2018
@@ -140,6 +140,22 @@ void test4(int **p) {
// expected-note@-1 {{Dereference of null pointer}}
 }
 
+void boringCallee() {
+}
+
+void interestingCallee(int *x) {
+  *x = 0; // expected-note{{The value 0 is assigned to 'x'}}
+  boringCallee(); // no-note
+}
+
+int testBoringCalleeOfInterestingCallee() {
+  int x;
+  interestingCallee(); // expected-note{{Calling 'interestingCallee'}}
+ // expected-note@-1{{Returning from 
'interestingCallee'}}
+  return 1 / x; // expected-warning{{Division by zero}}
+// expected-note@-1{{Division by zero}}
+}
+
 // CHECK:  diagnostics
 // CHECK-NEXT:  
 // CHECK-NEXT:   
@@ -3377,4 +3393,290 @@ void test4(int **p) {
 // CHECK-NEXT:file0
 // CHECK-NEXT:   
 // CHECK-NEXT:   
+// CHECK-NEXT:   
+// CHECK-NEXT:path
+// CHECK-NEXT:
+// CHECK-NEXT: 
+// CHECK-NEXT:  kindcontrol
+// CHECK-NEXT:  edges
+// CHECK-NEXT:   
+// CHECK-NEXT:
+// CHECK-NEXT: start
+// CHECK-NEXT:  
+// CHECK-NEXT:   
+// CHECK-NEXT:line152
+// CHECK-NEXT:col3
+// CHECK-NEXT:file0
+// CHECK-NEXT:   
+// CHECK-NEXT:   
+// CHECK-NEXT:line152
+// CHECK-NEXT:col5
+// CHECK-NEXT:file0
+// CHECK-NEXT:   
+// CHECK-NEXT:  
+// CHECK-NEXT: end
+// CHECK-NEXT:  
+// CHECK-NEXT:   
+// CHECK-NEXT:line153
+// CHECK-NEXT:col3
+// CHECK-NEXT:file0
+// CHECK-NEXT:   
+// CHECK-NEXT:   
+// CHECK-NEXT:line153
+// CHECK-NEXT:col19
+// CHECK-NEXT:file0
+// CHECK-NEXT:   
+// CHECK-NEXT:  
+// CHECK-NEXT:
+// CHECK-NEXT:   
+// CHECK-NEXT: 
+// CHECK-NEXT: 
+// CHECK-NEXT:  kindevent
+// CHECK-NEXT:  location
+// CHECK-NEXT:  
+// CHECK-NEXT: 

[PATCH] D45163: [Sema] -Wunused-value: diagnose unused std::move() call results.

2018-04-03 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added a comment.

In https://reviews.llvm.org/D45163#1055856, @rjmccall wrote:

> Well, we should feel welcome to submit patches to the C++ library 
> implementations, I think.  I can understand why Marshall is waiting to just 
> do this until he gets a comprehensive committee paper,




> but he might consider taking a patch in the meantime.

That has been discussed, and it's not going to happen. Ask him if you want more 
info.

> But I'm not sure what the rush is if it doesn't change what goes into any 
> concrete release of the compiler + library.

TLDW: `std::move()` is "The Assign Operator (`a = b;`) of RAII". It would be 
good to diagnose such a problem, and not just rely that some day the std libs 
will mark it with the attribute.
BTW, even when they do, even for libcxx, it won't be of any immediate use to 
LLVM, we will need to provide a define (see https://reviews.llvm.org/D45179) to 
actually enable that attribute, because LLVM is using C++11, not 
C++17/something...



Repository:
  rC Clang

https://reviews.llvm.org/D45163



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


[PATCH] D44747: Set calling convention for CUDA kernel

2018-04-03 Thread Artem Belevich via Phabricator via cfe-commits
tra added a comment.

In https://reviews.llvm.org/D44747#1055894, @yaxunl wrote:

> Let's revert it for now. I will create a review after fixing it and commit it 
> again with the fix.
>
> Thanks.
>
> Sam


reverted in r329099.


Repository:
  rL LLVM

https://reviews.llvm.org/D44747



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


r329099 - Revert "Set calling convention for CUDA kernel"

2018-04-03 Thread Artem Belevich via cfe-commits
Author: tra
Date: Tue Apr  3 11:29:31 2018
New Revision: 329099

URL: http://llvm.org/viewvc/llvm-project?rev=329099=rev
Log:
Revert "Set calling convention for CUDA kernel"

This reverts r328795 which introduced an issue with referencing __global__
function templates. More details in the original review D44747.

Removed:
cfe/trunk/test/CodeGenCUDA/kernel-amdgcn.cu
Modified:
cfe/trunk/include/clang/Basic/Specifiers.h
cfe/trunk/lib/AST/ItaniumMangle.cpp
cfe/trunk/lib/AST/Type.cpp
cfe/trunk/lib/AST/TypePrinter.cpp
cfe/trunk/lib/CodeGen/CGCall.cpp
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
cfe/trunk/lib/CodeGen/TargetInfo.cpp
cfe/trunk/lib/CodeGen/TargetInfo.h
cfe/trunk/lib/Sema/SemaExpr.cpp
cfe/trunk/lib/Sema/SemaOverload.cpp
cfe/trunk/lib/Sema/SemaType.cpp
cfe/trunk/tools/libclang/CXType.cpp

Modified: cfe/trunk/include/clang/Basic/Specifiers.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Specifiers.h?rev=329099=329098=329099=diff
==
--- cfe/trunk/include/clang/Basic/Specifiers.h (original)
+++ cfe/trunk/include/clang/Basic/Specifiers.h Tue Apr  3 11:29:31 2018
@@ -231,24 +231,23 @@ namespace clang {
 
   /// \brief CallingConv - Specifies the calling convention that a function 
uses.
   enum CallingConv {
-CC_C, // __attribute__((cdecl))
-CC_X86StdCall,// __attribute__((stdcall))
-CC_X86FastCall,   // __attribute__((fastcall))
-CC_X86ThisCall,   // __attribute__((thiscall))
+CC_C,   // __attribute__((cdecl))
+CC_X86StdCall,  // __attribute__((stdcall))
+CC_X86FastCall, // __attribute__((fastcall))
+CC_X86ThisCall, // __attribute__((thiscall))
 CC_X86VectorCall, // __attribute__((vectorcall))
-CC_X86Pascal, // __attribute__((pascal))
-CC_Win64, // __attribute__((ms_abi))
-CC_X86_64SysV,// __attribute__((sysv_abi))
-CC_X86RegCall,// __attribute__((regcall))
-CC_AAPCS, // __attribute__((pcs("aapcs")))
-CC_AAPCS_VFP, // __attribute__((pcs("aapcs-vfp")))
-CC_IntelOclBicc,  // __attribute__((intel_ocl_bicc))
-CC_SpirFunction,  // default for OpenCL functions on SPIR target
-CC_OpenCLKernel,  // inferred for OpenCL kernels
-CC_Swift, // __attribute__((swiftcall))
-CC_PreserveMost,  // __attribute__((preserve_most))
-CC_PreserveAll,   // __attribute__((preserve_all))
-CC_CUDAKernel,// inferred for CUDA kernels
+CC_X86Pascal,   // __attribute__((pascal))
+CC_Win64,   // __attribute__((ms_abi))
+CC_X86_64SysV,  // __attribute__((sysv_abi))
+CC_X86RegCall, // __attribute__((regcall))
+CC_AAPCS,   // __attribute__((pcs("aapcs")))
+CC_AAPCS_VFP,   // __attribute__((pcs("aapcs-vfp")))
+CC_IntelOclBicc, // __attribute__((intel_ocl_bicc))
+CC_SpirFunction, // default for OpenCL functions on SPIR target
+CC_OpenCLKernel, // inferred for OpenCL kernels
+CC_Swift,// __attribute__((swiftcall))
+CC_PreserveMost, // __attribute__((preserve_most))
+CC_PreserveAll,  // __attribute__((preserve_all))
   };
 
   /// \brief Checks whether the given calling convention supports variadic

Modified: cfe/trunk/lib/AST/ItaniumMangle.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ItaniumMangle.cpp?rev=329099=329098=329099=diff
==
--- cfe/trunk/lib/AST/ItaniumMangle.cpp (original)
+++ cfe/trunk/lib/AST/ItaniumMangle.cpp Tue Apr  3 11:29:31 2018
@@ -2628,7 +2628,6 @@ StringRef CXXNameMangler::getCallingConv
   case CC_OpenCLKernel:
   case CC_PreserveMost:
   case CC_PreserveAll:
-  case CC_CUDAKernel:
 // FIXME: we should be mangling all of the above.
 return "";
 

Modified: cfe/trunk/lib/AST/Type.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/Type.cpp?rev=329099=329098=329099=diff
==
--- cfe/trunk/lib/AST/Type.cpp (original)
+++ cfe/trunk/lib/AST/Type.cpp Tue Apr  3 11:29:31 2018
@@ -2748,7 +2748,6 @@ StringRef FunctionType::getNameForCallCo
   case CC_Swift: return "swiftcall";
   case CC_PreserveMost: return "preserve_most";
   case CC_PreserveAll: return "preserve_all";
-  case CC_CUDAKernel: return "cuda_kernel";
   }
 
   llvm_unreachable("Invalid calling convention.");

Modified: cfe/trunk/lib/AST/TypePrinter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/TypePrinter.cpp?rev=329099=329098=329099=diff
==
--- cfe/trunk/lib/AST/TypePrinter.cpp (original)
+++ cfe/trunk/lib/AST/TypePrinter.cpp Tue Apr  3 11:29:31 2018
@@ -780,10 +780,6 @@ void TypePrinter::printFunctionAfter(con
 case CC_OpenCLKernel:
   // Do nothing. These CCs are not available as attributes.
   break;
-case 

[PATCH] D45174: non-zero-length bit-fields should make a class non-empty

2018-04-03 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith marked an inline comment as done.
rsmith added inline comments.



Comment at: ReleaseNotes.rst:68-72
+- Clang implements the proposed resolution of LWG issue 2358, along with the
+  `corresponding change to the Itanium C++ ABI
+  `_, which make classes
+  containing only unnamed non-zero-length bit-fields be considered non-empty.
+  This is an ABI break compared to prior Clang releases, but makes Clang

majnemer wrote:
> The "Clang" in the above paragraph has a lowercase "clang". I think we should 
> choose a consistent capitalization.
Fixed in r329098.


Repository:
  rC Clang

https://reviews.llvm.org/D45174



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


[PATCH] D44878: libFuzzer OpenBSD support

2018-04-03 Thread David CARLIER via Phabricator via cfe-commits
devnexen added a comment.

ping


Repository:
  rC Clang

https://reviews.llvm.org/D44878



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


r329098 - Use Clang when referring to the project and clang when referring to the binary.

2018-04-03 Thread Richard Smith via cfe-commits
Author: rsmith
Date: Tue Apr  3 11:28:13 2018
New Revision: 329098

URL: http://llvm.org/viewvc/llvm-project?rev=329098=rev
Log:
Use Clang when referring to the project and clang when referring to the binary.

Modified:
cfe/trunk/docs/ReleaseNotes.rst

Modified: cfe/trunk/docs/ReleaseNotes.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ReleaseNotes.rst?rev=329098=329097=329098=diff
==
--- cfe/trunk/docs/ReleaseNotes.rst (original)
+++ cfe/trunk/docs/ReleaseNotes.rst Tue Apr  3 11:28:13 2018
@@ -62,8 +62,9 @@ Improvements to Clang's diagnostics
 Non-comprehensive list of changes in this release
 -
 
-- clang binary and libraries have been renamed from 7.0 to 7.
-  For example, the clang binary will be called clang-7 instead of clang-7.0.
+- Clang binary and libraries have been renamed from 7.0 to 7.
+  For example, the ``clang`` binary will be called ``clang-7``
+  instead of ``clang-7.0``.
 
 - ...
 


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


r329097 - Restrict a test using named file descriptors to using the system shell

2018-04-03 Thread David Blaikie via cfe-commits
Author: dblaikie
Date: Tue Apr  3 11:22:14 2018
New Revision: 329097

URL: http://llvm.org/viewvc/llvm-project?rev=329097=rev
Log:
Restrict a test using named file descriptors to using the system shell

Modified:
cfe/trunk/test/Misc/dev-fd-fs.c

Modified: cfe/trunk/test/Misc/dev-fd-fs.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Misc/dev-fd-fs.c?rev=329097=329096=329097=diff
==
--- cfe/trunk/test/Misc/dev-fd-fs.c (original)
+++ cfe/trunk/test/Misc/dev-fd-fs.c Tue Apr  3 11:22:14 2018
@@ -1,5 +1,6 @@
 // Check that we can operate on files from /dev/fd.
 // REQUIRES: dev-fd-fs
+// REQUIRES: shell
 
 // Check reading from named pipes. We cat the input here instead of redirecting
 // it to ensure that /dev/fd/0 is a named pipe, not just a redirected file.


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


[PATCH] D45217: [ThinLTO] Pass -save-temps to LTO backend for distributed ThinLTO builds

2018-04-03 Thread Teresa Johnson via Phabricator via cfe-commits
tejohnson created this revision.
tejohnson added a reviewer: pcc.
Herald added subscribers: eraman, inglorion, mehdi_amini.

The clang driver option -save-temps was not passed to the LTO config,
so when invoking the ThinLTO backends via clang during distributed
builds there was no way to get LTO to save temp files.

Getting this to work with ThinLTO distributed builds also required
changing the driver to avoid a separate compile step to emit unoptimized
bitcode when the input was already bitcode under -save-temps. Not only is
this unnecessary in general, it is problematic for ThinLTO backends since
the temporary bitcode file to the backend would not match the module path
in the combined index, leading to incorrect ThinLTO backend index-based
optimizations.


Repository:
  rC Clang

https://reviews.llvm.org/D45217

Files:
  include/clang/Driver/Options.td
  include/clang/Frontend/CodeGenOptions.h
  lib/CodeGen/BackendUtil.cpp
  lib/Driver/Driver.cpp
  lib/Driver/ToolChains/Clang.cpp
  lib/Frontend/CompilerInvocation.cpp
  test/CodeGen/thinlto_backend.ll
  test/Driver/thinlto_backend.c

Index: test/Driver/thinlto_backend.c
===
--- test/Driver/thinlto_backend.c
+++ test/Driver/thinlto_backend.c
@@ -5,6 +5,15 @@
 // RUN: %clang -O2 -o %t1.o -x ir %t.o -c -fthinlto-index=%t.thinlto.bc -### 2>&1 | FileCheck %s -check-prefix=CHECK-THINLTOBE-ACTION
 // CHECK-THINLTOBE-ACTION: -fthinlto-index=
 
+// -save-temps should be passed to cc1
+// RUN: %clang -O2 -o %t1.o -x ir %t.o -c -fthinlto-index=%t.thinlto.bc -save-temps -### 2>&1 | FileCheck %s -check-prefix=CHECK-SAVE-TEMPS -check-prefix=CHECK-SAVE-TEMPS-CWD
+// RUN: %clang -O2 -o %t1.o -x ir %t.o -c -fthinlto-index=%t.thinlto.bc -save-temps=cwd -### 2>&1 | FileCheck %s -check-prefix=CHECK-SAVE-TEMPS -check-prefix=CHECK-SAVE-TEMPS-CWD
+// RUN: %clang -O2 -o %t1.o -x ir %t.o -c -fthinlto-index=%t.thinlto.bc -save-temps=obj -### 2>&1 | FileCheck %s -check-prefix=CHECK-SAVE-TEMPS -check-prefix=CHECK-SAVE-TEMPS-OBJ
+// CHECK-SAVE-TEMPS-NOT: -emit-llvm-bc
+// CHECK-SAVE-TEMPS-CWD: -save-temps=cwd
+// CHECK-SAVE-TEMPS-OBJ: -save-temps=obj
+// CHECK-SAVE-TEMPS-NOT: -emit-llvm-bc
+
 // Ensure clang driver gives the expected error for incorrect input type
 // RUN: not %clang -O2 -o %t1.o %s -c -fthinlto-index=%t.thinlto.bc 2>&1 | FileCheck %s -check-prefix=CHECK-WARNING
 // CHECK-WARNING: error: invalid argument '-fthinlto-index={{.*}}' only allowed with '-x ir'
Index: test/CodeGen/thinlto_backend.ll
===
--- test/CodeGen/thinlto_backend.ll
+++ test/CodeGen/thinlto_backend.ll
@@ -27,10 +27,12 @@
 ; RUN: llvm-nm %t4.o | count 0
 
 ; Ensure f2 was imported
-; RUN: %clang -target x86_64-unknown-linux-gnu -O2 -o %t3.o -x ir %t1.o -c -fthinlto-index=%t.thinlto.bc
+; RUN: %clang -target x86_64-unknown-linux-gnu -O2 -o %t3.o -x ir %t1.o -c -fthinlto-index=%t.thinlto.bc -save-temps=obj
 ; RUN: llvm-nm %t3.o | FileCheck --check-prefix=CHECK-OBJ %s
 ; CHECK-OBJ: T f1
 ; CHECK-OBJ-NOT: U f2
+; RUN: llvm-dis %t1.s.0.3.import.bc -o - | FileCheck --check-prefix=CHECK-IMPORT %s
+; CHECK-IMPORT: define available_externally void @f2()
 
 ; Ensure we get expected error for input files without summaries
 ; RUN: opt -o %t2.o %s
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -487,7 +487,8 @@
 
 static bool ParseCodeGenArgs(CodeGenOptions , ArgList , InputKind IK,
  DiagnosticsEngine ,
- const TargetOptions ) {
+ const TargetOptions ,
+ const FrontendOptions ) {
   bool Success = true;
   llvm::Triple Triple = llvm::Triple(TargetOpts.Triple);
 
@@ -739,6 +740,13 @@
   << A->getAsString(Args) << "-x ir";
 Opts.ThinLTOIndexFile = Args.getLastArgValue(OPT_fthinlto_index_EQ);
   }
+  if (Arg *A = Args.getLastArg(OPT_save_temps_EQ))
+Opts.SaveTempsFilePrefix =
+llvm::StringSwitch(A->getValue())
+.Case("obj", FrontendOpts.OutputFile)
+.Default("./" +
+ llvm::sys::path::filename(FrontendOpts.OutputFile).str());
+
   Opts.ThinLinkBitcodeFile = Args.getLastArgValue(OPT_fthin_link_bitcode_EQ);
 
   Opts.MSVolatile = Args.hasArg(OPT_fms_volatile);
@@ -2890,7 +2898,7 @@
   LangOpts.IsHeaderFile);
   ParseTargetArgs(Res.getTargetOpts(), Args, Diags);
   Success &= ParseCodeGenArgs(Res.getCodeGenOpts(), Args, DashX, Diags,
-  Res.getTargetOpts());
+  Res.getTargetOpts(), Res.getFrontendOpts());
   ParseHeaderSearchArgs(Res.getHeaderSearchOpts(), Args,
 Res.getFileSystemOpts().WorkingDir);
   if (DashX.getFormat() == InputKind::Precompiled ||
Index: 

RE: [PATCH] D44747: Set calling convention for CUDA kernel

2018-04-03 Thread Liu, Yaxun (Sam) via cfe-commits
Let's revert it for now. I will create a review after fixing it and commit it 
again with the fix.

Thanks.

Sam 

-Original Message-
From: Artem Belevich via Phabricator [mailto:revi...@reviews.llvm.org] 
Sent: Tuesday, April 03, 2018 2:09 PM
To: Liu, Yaxun (Sam) ; rjmcc...@gmail.com; Arsenault, 
Matthew 
Cc: jle...@google.com; llvm-comm...@lists.llvm.org; t...@google.com; 
Zhuravlyov, Konstantin ; wei.di...@amd.com; 
Stuttard, David ; tpr.l...@botech.co.uk; Tye, Tony 
; cfe-commits@lists.llvm.org
Subject: [PATCH] D44747: Set calling convention for CUDA kernel

tra added a comment.

In https://reviews.llvm.org/D44747#1055877, @yaxunl wrote:

> I will try fixing that.
>
> The CUDA kernel calling convention should be dropped in all DRE's since it is 
> invisible to the user.
>
> Sam


Apparently it's not always the case.
Here's a bit more elaborate example demonstrating inconsistency in this 
behavior. Calling convention is ignored for regular functions, but not for 
function templates.

  __global__ void EmptyKernel(void) { }
  
  template 
  __global__ void EmptyKernelT(void) { }
  
  struct Dummy {
/// Type definition of the EmptyKernel kernel entry point
typedef void (*EmptyKernelPtr)();
EmptyKernelPtr Empty() { return EmptyKernel; } // this one works
EmptyKernelPtr EmptyT() { return EmptyKernelT; } // this one errors 
out.
  };

Do you think this is something you can fix quickly or do you want to unroll the 
change while you figure out what's going on?


Repository:
  rL LLVM

https://reviews.llvm.org/D44747



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


[PATCH] D44747: Set calling convention for CUDA kernel

2018-04-03 Thread Artem Belevich via Phabricator via cfe-commits
tra added a comment.

In https://reviews.llvm.org/D44747#1055877, @yaxunl wrote:

> I will try fixing that.
>
> The CUDA kernel calling convention should be dropped in all DRE's since it is 
> invisible to the user.
>
> Sam


Apparently it's not always the case.
Here's a bit more elaborate example demonstrating inconsistency in this 
behavior. Calling convention is ignored for regular functions, but not for 
function templates.

  __global__ void EmptyKernel(void) { }
  
  template 
  __global__ void EmptyKernelT(void) { }
  
  struct Dummy {
/// Type definition of the EmptyKernel kernel entry point
typedef void (*EmptyKernelPtr)();
EmptyKernelPtr Empty() { return EmptyKernel; } // this one works
EmptyKernelPtr EmptyT() { return EmptyKernelT; } // this one errors 
out.
  };

Do you think this is something you can fix quickly or do you want to unroll the 
change while you figure out what's going on?


Repository:
  rL LLVM

https://reviews.llvm.org/D44747



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


[PATCH] D45161: [AST] Add new printing policy to suppress printing template arguments

2018-04-03 Thread Kalle Huttunen via Phabricator via cfe-commits
khuttun abandoned this revision.
khuttun added a comment.

Figured out a better way to do this by using 
`FunctionDecl::getInstantiatedFromMemberFunction`


Repository:
  rC Clang

https://reviews.llvm.org/D45161



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


[PATCH] D44842: Add Parameters to DW_AT_name Attribute of Template Variables

2018-04-03 Thread Matthew Voss via Phabricator via cfe-commits
ormris added a comment.

No such luck...
Patch:

  Index: source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
  ===
  --- source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp 
(revision 329079)
  +++ source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp 
(working copy)
  @@ -400,8 +400,9 @@
   break;
 case lldb::eLanguageTypeC_plus_plus:
 case lldb::eLanguageTypeC_plus_plus_11:
  +m_compiler->getLangOpts().CPlusPlus11 = true;
 case lldb::eLanguageTypeC_plus_plus_14:
  -m_compiler->getLangOpts().CPlusPlus11 = true;
  +m_compiler->getLangOpts().CPlusPlus14 = true;
   m_compiler->getHeaderSearchOpts().UseLibcxx = true;
   LLVM_FALLTHROUGH;
 case lldb::eLanguageTypeC_plus_plus_03:

Output:

  (lldb) e crazy
  error: use of undeclared identifier 'crazy'
  error: expected '(' for function-style cast or type construction
  error: expected expression


Repository:
  rC Clang

https://reviews.llvm.org/D44842



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


RE: [PATCH] D44747: Set calling convention for CUDA kernel

2018-04-03 Thread Liu, Yaxun (Sam) via cfe-commits
I will try fixing that.

The CUDA kernel calling convention should be dropped in all DRE's since it is 
invisible to the user.

Sam

-Original Message-
From: Artem Belevich via Phabricator [mailto:revi...@reviews.llvm.org] 
Sent: Tuesday, April 03, 2018 1:51 PM
To: Liu, Yaxun (Sam) ; rjmcc...@gmail.com; Arsenault, 
Matthew 
Cc: llvm-comm...@lists.llvm.org; t...@google.com; Zhuravlyov, Konstantin 
; wei.di...@amd.com; Stuttard, David 
; tpr.l...@botech.co.uk; Tye, Tony ; 
cfe-commits@lists.llvm.org; jle...@google.com
Subject: [PATCH] D44747: Set calling convention for CUDA kernel

tra added inline comments.



Comment at: lib/Sema/SemaType.cpp:3319-3330
+  // Attribute AT_CUDAGlobal affects the calling convention for AMDGPU targets.
+  // This is the simplest place to infer calling convention for CUDA kernels.
+  if (S.getLangOpts().CUDA && S.getLangOpts().CUDAIsDevice) {
+for (const AttributeList *Attr = D.getDeclSpec().getAttributes().getList();
+ Attr; Attr = Attr->getNext()) {
+  if (Attr->getKind() == AttributeList::AT_CUDAGlobal) {
+CC = CC_CUDAKernel;

tra wrote:
> This apparently breaks compilation of some CUDA code in our internal tests. 
> I'm working on minimizing a reproduction case. Should this code be enabled 
> for AMD GPUs only?
Here's a small snippet of code that previously used to compile and work:

```
template 
__global__ void EmptyKernel(void) { }

struct Dummy {
  /// Type definition of the EmptyKernel kernel entry point
  typedef void (*EmptyKernelPtr)();
  EmptyKernelPtr Empty() { return EmptyKernel; } }; ``` AFAICT,  it's 
currently impossible to apply __global__ to pointers, so there's no way to make 
the code above work with this patch applied.


Repository:
  rL LLVM

https://reviews.llvm.org/D44747



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


[PATCH] D44842: Add Parameters to DW_AT_name Attribute of Template Variables

2018-04-03 Thread Matthew Voss via Phabricator via cfe-commits
ormris added a comment.

About to test with CPlusPlus14 enabled

Here's the output from those two commands.

  (lldb) frame var -g crazy
  error: no variable named 'crazy' found in this frame
  (lldb) frame var -g crazy
  error: no variable named 'crazy' found in this frame
  (lldb)


Repository:
  rC Clang

https://reviews.llvm.org/D44842



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


[PATCH] D45152: [MinGW] Add option for disabling looking for a mingw gcc in PATH

2018-04-03 Thread Reid Kleckner via Phabricator via cfe-commits
rnk accepted this revision.
rnk added a comment.
This revision is now accepted and ready to land.

Seems reasonable, looks good.


Repository:
  rC Clang

https://reviews.llvm.org/D45152



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


[PATCH] D45212: [HIP] Let CUDA toolchain support HIP language mode

2018-04-03 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl updated this revision to Diff 140827.
yaxunl retitled this revision from "[WIP][HIP] Let CUDA toolchain support HIP 
language mode" to "[HIP] Let CUDA toolchain support HIP language mode".
yaxunl edited the summary of this revision.
yaxunl added a comment.

Fixed typo which causes lit test failures. Now all lit tests pass.


https://reviews.llvm.org/D45212

Files:
  include/clang/Basic/Cuda.h
  include/clang/Basic/DiagnosticDriverKinds.td
  include/clang/Driver/Options.td
  include/clang/Driver/ToolChain.h
  include/clang/Driver/Types.def
  lib/Basic/Cuda.cpp
  lib/Basic/Targets.cpp
  lib/Basic/Targets.h
  lib/Basic/Targets/AMDGPU.cpp
  lib/Basic/Targets/AMDGPU.h
  lib/Basic/Targets/NVPTX.cpp
  lib/Driver/Driver.cpp
  lib/Driver/SanitizerArgs.cpp
  lib/Driver/ToolChain.cpp
  lib/Driver/ToolChains/Clang.cpp
  lib/Driver/ToolChains/Cuda.cpp
  lib/Driver/ToolChains/Cuda.h
  lib/Driver/ToolChains/Gnu.cpp
  lib/Driver/Types.cpp
  lib/Frontend/CompilerInstance.cpp
  test/Driver/cuda-phases.cu

Index: test/Driver/cuda-phases.cu
===
--- test/Driver/cuda-phases.cu
+++ test/Driver/cuda-phases.cu
@@ -7,22 +7,26 @@
 // REQUIRES: clang-driver
 // REQUIRES: powerpc-registered-target
 // REQUIRES: nvptx-registered-target
-
+// REQUIRES: amdgpu-registered-target
 //
 // Test single gpu architecture with complete compilation.
 //
 // RUN: %clang -target powerpc64le-ibm-linux-gnu -ccc-print-phases --cuda-gpu-arch=sm_30 %s 2>&1 \
-// RUN: | FileCheck -check-prefix=BIN %s
-// BIN-DAG: [[P0:[0-9]+]]: input, "{{.*}}cuda-phases.cu", cuda, (host-cuda)
-// BIN-DAG: [[P1:[0-9]+]]: preprocessor, {[[P0]]}, cuda-cpp-output, (host-cuda)
+// RUN: | FileCheck -check-prefixes=BIN,BIN_NV %s
+// RUN: %clang -x hip -target powerpc64le-ibm-linux-gnu -ccc-print-phases --cuda-gpu-arch=gfx803 %s 2>&1 \
+// RUN: | FileCheck -check-prefixes=BIN,BIN_AMD %s
+// BIN_NV-DAG: [[P0:[0-9]+]]: input, "{{.*}}cuda-phases.cu", [[T:cuda]], (host-cuda)
+// BIN_AMD-DAG: [[P0:[0-9]+]]: input, "{{.*}}cuda-phases.cu", [[T:hip]], (host-cuda)
+// BIN-DAG: [[P1:[0-9]+]]: preprocessor, {[[P0]]}, [[T]]-cpp-output, (host-cuda)
 // BIN-DAG: [[P2:[0-9]+]]: compiler, {[[P1]]}, ir, (host-cuda)
-// BIN-DAG: [[P3:[0-9]+]]: input, "{{.*}}cuda-phases.cu", cuda, (device-cuda, sm_30)
-// BIN-DAG: [[P4:[0-9]+]]: preprocessor, {[[P3]]}, cuda-cpp-output, (device-cuda, sm_30)
-// BIN-DAG: [[P5:[0-9]+]]: compiler, {[[P4]]}, ir, (device-cuda, sm_30)
-// BIN-DAG: [[P6:[0-9]+]]: backend, {[[P5]]}, assembler, (device-cuda, sm_30)
-// BIN-DAG: [[P7:[0-9]+]]: assembler, {[[P6]]}, object, (device-cuda, sm_30)
-// BIN-DAG: [[P8:[0-9]+]]: offload, "device-cuda (nvptx64-nvidia-cuda:sm_30)" {[[P7]]}, object
-// BIN-DAG: [[P9:[0-9]+]]: offload, "device-cuda (nvptx64-nvidia-cuda:sm_30)" {[[P6]]}, assembler
+// BIN_NV-DAG: [[P3:[0-9]+]]: input, "{{.*}}cuda-phases.cu", [[T]], (device-cuda, [[ARCH:sm_30]])
+// BIN_AMD-DAG: [[P3:[0-9]+]]: input, "{{.*}}cuda-phases.cu", [[T]], (device-cuda, [[ARCH:gfx803]])
+// BIN-DAG: [[P4:[0-9]+]]: preprocessor, {[[P3]]}, [[T]]-cpp-output, (device-cuda, [[ARCH]])
+// BIN-DAG: [[P5:[0-9]+]]: compiler, {[[P4]]}, ir, (device-cuda, [[ARCH]])
+// BIN-DAG: [[P6:[0-9]+]]: backend, {[[P5]]}, assembler, (device-cuda, [[ARCH]])
+// BIN-DAG: [[P7:[0-9]+]]: assembler, {[[P6]]}, object, (device-cuda, [[ARCH]])
+// BIN-DAG: [[P8:[0-9]+]]: offload, "device-cuda (nvptx64-nvidia-cuda:[[ARCH]])" {[[P7]]}, object
+// BIN-DAG: [[P9:[0-9]+]]: offload, "device-cuda (nvptx64-nvidia-cuda:[[ARCH]])" {[[P6]]}, assembler
 // BIN-DAG: [[P10:[0-9]+]]: linker, {[[P8]], [[P9]]}, cuda-fatbin, (device-cuda)
 // BIN-DAG: [[P11:[0-9]+]]: offload, "host-cuda (powerpc64le-ibm-linux-gnu)" {[[P2]]}, "device-cuda (nvptx64-nvidia-cuda)" {[[P10]]}, ir
 // BIN-DAG: [[P12:[0-9]+]]: backend, {[[P11]]}, assembler, (host-cuda)
@@ -34,38 +38,42 @@
 //
 // RUN: %clang -target powerpc64le-ibm-linux-gnu -ccc-print-phases --cuda-gpu-arch=sm_30 %s -S 2>&1 \
 // RUN: | FileCheck -check-prefix=ASM %s
-// ASM-DAG: [[P0:[0-9]+]]: input, "{{.*}}cuda-phases.cu", cuda, (device-cuda, sm_30)
-// ASM-DAG: [[P1:[0-9]+]]: preprocessor, {[[P0]]}, cuda-cpp-output, (device-cuda, sm_30)
-// ASM-DAG: [[P2:[0-9]+]]: compiler, {[[P1]]}, ir, (device-cuda, sm_30)
-// ASM-DAG: [[P3:[0-9]+]]: backend, {[[P2]]}, assembler, (device-cuda, sm_30)
-// ASM-DAG: [[P4:[0-9]+]]: offload, "device-cuda (nvptx64-nvidia-cuda:sm_30)" {[[P3]]}, assembler
-// ASM-DAG: [[P5:[0-9]+]]: input, "{{.*}}cuda-phases.cu", cuda, (host-cuda)
-// ASM-DAG: [[P6:[0-9]+]]: preprocessor, {[[P5]]}, cuda-cpp-output, (host-cuda)
+// RUN: %clang -x hip -target powerpc64le-ibm-linux-gnu -ccc-print-phases --cuda-gpu-arch=gfx803 %s -S 2>&1 \
+// RUN: | FileCheck -check-prefix=ASM %s
+// ASM-DAG: [[P0:[0-9]+]]: input, "{{.*}}cuda-phases.cu", [[T:cuda|hip]], (device-cuda, [[ARCH:sm_30|gfx803]])
+// ASM-DAG: [[P1:[0-9]+]]: preprocessor, {[[P0]]}, [[T]]-cpp-output, (device-cuda, [[ARCH]])
+// ASM-DAG: 

[PATCH] D44747: Set calling convention for CUDA kernel

2018-04-03 Thread Artem Belevich via Phabricator via cfe-commits
tra added inline comments.



Comment at: lib/Sema/SemaType.cpp:3319-3330
+  // Attribute AT_CUDAGlobal affects the calling convention for AMDGPU targets.
+  // This is the simplest place to infer calling convention for CUDA kernels.
+  if (S.getLangOpts().CUDA && S.getLangOpts().CUDAIsDevice) {
+for (const AttributeList *Attr = D.getDeclSpec().getAttributes().getList();
+ Attr; Attr = Attr->getNext()) {
+  if (Attr->getKind() == AttributeList::AT_CUDAGlobal) {
+CC = CC_CUDAKernel;

tra wrote:
> This apparently breaks compilation of some CUDA code in our internal tests. 
> I'm working on minimizing a reproduction case. Should this code be enabled 
> for AMD GPUs only?
Here's a small snippet of code that previously used to compile and work:

```
template 
__global__ void EmptyKernel(void) { }

struct Dummy {
  /// Type definition of the EmptyKernel kernel entry point
  typedef void (*EmptyKernelPtr)();
  EmptyKernelPtr Empty() { return EmptyKernel; }
};
```
AFAICT,  it's currently impossible to apply __global__ to pointers, so there's 
no way to make the code above work with this patch applied.


Repository:
  rL LLVM

https://reviews.llvm.org/D44747



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


[PATCH] D45163: [Sema] -Wunused-value: diagnose unused std::move() call results.

2018-04-03 Thread John McCall via Phabricator via cfe-commits
rjmccall added a comment.

Well, we should feel welcome to submit patches to the C++ library 
implementations, I think.  I can understand why Marshall is waiting to just do 
this until he gets a comprehensive committee paper, but he might consider 
taking a patch in the meantime.  But I'm not sure what the rush is if it 
doesn't change what goes into any concrete release of the compiler + library.


Repository:
  rC Clang

https://reviews.llvm.org/D45163



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


[PATCH] D44842: Add Parameters to DW_AT_name Attribute of Template Variables

2018-04-03 Thread Jim Ingham via Phabricator via cfe-commits
jingham added a comment.

Apparently this makes a global variable, so "frame var" wouldn't show it by 
default.  What does "frame var -g" show?

We would also need to get:

  (lldb) frame var -g crazy

or something like it to work.  "frame var" has its own parser to support "->" 
and ".".  That doesn't currently work with:

  (lldb) frame var -g crazy
  error: unexpected char '<' encountered after "crazy" in ""

so for that part to work, either the name lookup must work w/o the  or 
frame var's parser must be updated to cope with this (and of course with any 
arbitrarily complex type that could get substituted in there).  That's likely a 
non-trivial bit of work.

I wonder if expr is failing because this is a C++14 extension, lldb sets 
CPlusPlus11 to true in the LangOpts for the compiler it makes, but not 
CPlusPlus14.


Repository:
  rC Clang

https://reviews.llvm.org/D44842



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


[PATCH] D44747: Set calling convention for CUDA kernel

2018-04-03 Thread Artem Belevich via Phabricator via cfe-commits
tra added inline comments.



Comment at: lib/Sema/SemaType.cpp:3319-3330
+  // Attribute AT_CUDAGlobal affects the calling convention for AMDGPU targets.
+  // This is the simplest place to infer calling convention for CUDA kernels.
+  if (S.getLangOpts().CUDA && S.getLangOpts().CUDAIsDevice) {
+for (const AttributeList *Attr = D.getDeclSpec().getAttributes().getList();
+ Attr; Attr = Attr->getNext()) {
+  if (Attr->getKind() == AttributeList::AT_CUDAGlobal) {
+CC = CC_CUDAKernel;

This apparently breaks compilation of some CUDA code in our internal tests. I'm 
working on minimizing a reproduction case. Should this code be enabled for AMD 
GPUs only?


Repository:
  rL LLVM

https://reviews.llvm.org/D44747



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


  1   2   >