date:20160211

Hi,

In my latests rc2+patches build I've also found that we need to rename 
HAVE_CXX_ATOMICS_WITH_LIB to something like LIBCXX_HAVE_CXX_ATOMICS_WITH_LIB. 
It's currently re-using the result of LLVM's check which doesn't include 64-bit 
atomics.

From: Vasileios Kalintiris
Sent: 09 February 2016 23:50
To: h...@chromium.org
Cc: cfe-commits@lists.llvm.org; Daniel Sanders; mclow.li...@gmail.com
Subject: RE: [libcxx] r260235 - Introduce a cmake module to figure out whether 
we need to link with libatomic.

Hi Hans,

Please wait before merging this as it breaks LLVM bootstraps when using the 
-gcc-toolchain option and the system's default gcc installation does not 
provide libatomic. We have to check LIBCXX_GCC_TOOLCHAIN in our test. I'll 
create a patch tomorrow and I'll let you know when it's okay to merge them. In 
the meantime, I reverted it in r260323.

- Vasileios

From: Vasileios Kalintiris
Sent: 09 February 2016 18:56
To: h...@chromium.org
Cc: cfe-commits@lists.llvm.org; Daniel Sanders; mclow.li...@gmail.com
Subject: RE: [libcxx] r260235 - Introduce a cmake module to figure out whether 
we need to link with libatomic.

Hi Hans,

Can we merge this on the 3.8 release branch? It fixes libcxx builds on MIPS by 
linking with libatomic when needed. Also, all the x86_64 and ARM buildbots for 
libcxx look good.

Thanks,
Vasileios

From: cfe-commits [cfe-commits-boun...@lists.llvm.org] on behalf of Vasileios 
Kalintiris via cfe-commits [cfe-commits@lists.llvm.org]
Sent: 09 February 2016 17:00
To: cfe-commits@lists.llvm.org
Subject: [libcxx] r260235 - Introduce a cmake module to figure out whether we 
need to link with libatomic.

Author: vkalintiris
Date: Tue Feb  9 11:00:38 2016
New Revision: 260235

URL: http://llvm.org/viewvc/llvm-project?rev=260235=rev
Log:
Introduce a cmake module to figure out whether we need to link with libatomic.

Summary:
This fixes the tests under std/atomics for 32-bit MIPS CPUs where the
8-byte atomic operations call into the libatomic library.

Reviewers: dsanders, mclow.lists, EricWF, jroelofs, joerg

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D16613

Added:
libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake
Modified:
libcxx/trunk/cmake/config-ix.cmake
libcxx/trunk/lib/CMakeLists.txt
libcxx/trunk/test/CMakeLists.txt
libcxx/trunk/test/libcxx/test/target_info.py
libcxx/trunk/test/lit.site.cfg.in

Added: libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake?rev=260235=auto
==
--- libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake (added)
+++ libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake Tue Feb  9 11:00:38 2016
@@ -0,0 +1,38 @@
+INCLUDE(CheckCXXSourceCompiles)
+
+# Sometimes linking against libatomic is required for atomic ops, if
+# the platform doesn't support lock-free atomics.
+#
+# We could modify LLVM's CheckAtomic module and have it check for 64-bit
+# atomics instead. However, we would like to avoid careless uses of 64-bit
+# atomics inside LLVM over time on 32-bit platforms.
+
+function(check_cxx_atomics varname)
+  set(OLD_CMAKE_REQUIRED_FLAGS ${CMAKE_REQUIRED_FLAGS})
+  set(CMAKE_REQUIRED_FLAGS "-std=c++11")
+  check_cxx_source_compiles("
+#include 
+#include 
+std::atomic x;
+std::atomic y;
+int main() {
+  return x + y;
+}
+" ${varname})
+  set(CMAKE_REQUIRED_FLAGS ${OLD_CMAKE_REQUIRED_FLAGS})
+endfunction(check_cxx_atomics)
+
+check_cxx_atomics(HAVE_CXX_ATOMICS_WITHOUT_LIB)
+# If not, check if the library exists, and atomics work with it.
+if(NOT HAVE_CXX_ATOMICS_WITHOUT_LIB)
+  check_library_exists(atomic __atomic_fetch_add_8 "" HAVE_LIBATOMIC)
+  if(HAVE_LIBATOMIC)
+list(APPEND CMAKE_REQUIRED_LIBRARIES "atomic")
+check_cxx_atomics(HAVE_CXX_ATOMICS_WITH_LIB)
+if (NOT HAVE_CXX_ATOMICS_WITH_LIB)
+  message(FATAL_ERROR "Host compiler must support std::atomic!")
+endif()
+  else()
+message(FATAL_ERROR "Host compiler appears to require libatomic, but 
cannot find it.")
+  endif()
+endif()

Modified: libcxx/trunk/cmake/config-ix.cmake
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/cmake/config-ix.cmake?rev=260235=260234=260235=diff
==
--- libcxx/trunk/cmake/config-ix.cmake (original)
+++ libcxx/trunk/cmake/config-ix.cmake Tue Feb  9 11:00:38 2016
@@ -1,5 +1,6 @@
 include(CheckLibraryExists)
 include(CheckCXXCompilerFlag)
+include(CheckLibcxxAtomic)

 # Check compiler flags

@@ -17,3 +18,7 @@ check_library_exists(c fopen "" LIBCXX_H
 check_library_exists(m ccos "" LIBCXX_HAS_M_LIB)
 check_library_exists(rt clock_gettime "" LIBCXX_HAS_RT_LIB)
 check_library_exists(gcc_s __gcc_personality_v0 "" LIBCXX_HAS_GCC_S_LIB)
+
+if (NOT

Re: [PATCH] D17149: Consolidate and improve the handling of built-in feature-like macros

2016-02-11 Thread Andy Gibbs via cfe-commits

AndyG added a comment.

To be honest, the simple answer is because it was just as easy to do with 
nesting as without (the code would still need to track the appearance of left 
and right parentheses in order to correctly parse to the closing 
right-parenthesis of the macro invocation in any case).

And since the work has to be done anyway, it seemed reasonable to allow it.  My 
other thought was that when people write wrapper macros, they often (indeed 
idiomatically) wrap their parameters in an extra set of parentheses before 
passing down to the next level.  This would therefore handle this use-case.

While it may not technically be part of the specification, neither does it 
break it, and in the 99% most common cases the extra functionality will not 
come into play.

The motivation of the patch was to ensure a more robust parsing of these 
feature-like macros -- that and fixing __is_identifier which was fundamentally 
broken and where I originally started.

If you really disagree with this extension of the rules noted in your comment, 
I can work a logic that errors on the presence of embedded parentheses, but 
IMHO I think it preferable to keep it as is :o)


http://reviews.llvm.org/D17149



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

Re: [PATCH] D15920: [CMake] Add option to switch default C++ stdlib

This revision was automatically updated to reflect the committed changes.
Closed by commit rL260662: [CMake] Add option to switch default C++ stdlib 
(authored by Hahnfeld).

Changed prior to commit:
  http://reviews.llvm.org/D15920?vs=47441=47770#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D15920

Files:
  cfe/trunk/CMakeLists.txt
  cfe/trunk/include/clang/Config/config.h.cmake
  cfe/trunk/include/clang/Config/config.h.in
  cfe/trunk/include/clang/Driver/ToolChain.h
  cfe/trunk/lib/Driver/ToolChain.cpp
  cfe/trunk/lib/Driver/ToolChains.cpp
  cfe/trunk/lib/Driver/ToolChains.h

Index: cfe/trunk/include/clang/Config/config.h.in
===
--- cfe/trunk/include/clang/Config/config.h.in
+++ cfe/trunk/include/clang/Config/config.h.in
@@ -8,6 +8,9 @@
 /* Bug report URL. */
 #undef BUG_REPORT_URL
 
+/* Default C++ stdlib to use. */
+#undef CLANG_DEFAULT_CXX_STDLIB
+
 /* Default OpenMP runtime used by -fopenmp. */
 #undef CLANG_DEFAULT_OPENMP_RUNTIME
 
Index: cfe/trunk/include/clang/Config/config.h.cmake
===
--- cfe/trunk/include/clang/Config/config.h.cmake
+++ cfe/trunk/include/clang/Config/config.h.cmake
@@ -8,6 +8,9 @@
 /* Bug report URL. */
 #define BUG_REPORT_URL "${BUG_REPORT_URL}"
 
+/* Default C++ stdlib to use. */
+#define CLANG_DEFAULT_CXX_STDLIB "${CLANG_DEFAULT_CXX_STDLIB}"
+
 /* Default OpenMP runtime used by -fopenmp. */
 #define CLANG_DEFAULT_OPENMP_RUNTIME "${CLANG_DEFAULT_OPENMP_RUNTIME}"
 
Index: cfe/trunk/include/clang/Driver/ToolChain.h
===
--- cfe/trunk/include/clang/Driver/ToolChain.h
+++ cfe/trunk/include/clang/Driver/ToolChain.h
@@ -256,6 +256,10 @@
 return ToolChain::RLT_Libgcc;
   }
 
+  virtual CXXStdlibType GetDefaultCXXStdlibType() const {
+return ToolChain::CST_Libstdcxx;
+  }
+
   virtual std::string getCompilerRT(const llvm::opt::ArgList ,
 StringRef Component,
 bool Shared = false) const;
Index: cfe/trunk/CMakeLists.txt
===
--- cfe/trunk/CMakeLists.txt
+++ cfe/trunk/CMakeLists.txt
@@ -197,6 +197,15 @@
 set(DEFAULT_SYSROOT "" CACHE PATH
   "Default  to all compiler invocations for --sysroot=." )
 
+set(CLANG_DEFAULT_CXX_STDLIB "" CACHE STRING
+  "Default C++ stdlib to use (empty for architecture default, \"libstdc++\" or \"libc++\"")
+if (NOT(CLANG_DEFAULT_CXX_STDLIB STREQUAL "" OR
+CLANG_DEFAULT_CXX_STDLIB STREQUAL "libstdc++" OR
+CLANG_DEFAULT_CXX_STDLIB STREQUAL "libc++"))
+  message(WARNING "Resetting default C++ stdlib to use architecture default")
+  set(CLANG_DEFAULT_CXX_STDLIB "")
+endif()
+
 set(CLANG_DEFAULT_OPENMP_RUNTIME "libomp" CACHE STRING
   "Default OpenMP runtime used by -fopenmp.")
 
Index: cfe/trunk/lib/Driver/ToolChains.cpp
===
--- cfe/trunk/lib/Driver/ToolChains.cpp
+++ cfe/trunk/lib/Driver/ToolChains.cpp
@@ -65,6 +65,16 @@
 
 bool MachO::HasNativeLLVMSupport() const { return true; }
 
+ToolChain::CXXStdlibType Darwin::GetDefaultCXXStdlibType() const {
+  // Default to use libc++ on OS X 10.9+ and iOS 7+.
+  if ((isTargetMacOS() && !isMacosxVersionLT(10, 9)) ||
+   (isTargetIOSBased() && !isIPhoneOSVersionLT(7, 0)) ||
+   isTargetWatchOSBased())
+return ToolChain::CST_Libcxx;
+
+  return ToolChain::CST_Libstdcxx;
+}
+
 /// Darwin provides an ARC runtime starting in MacOS X 10.7 and iOS 5.0.
 ObjCRuntime Darwin::getDefaultObjCRuntime(bool isNonFragile) const {
   if (isTargetWatchOSBased())
@@ -1020,7 +1030,6 @@
   const char *BoundArch) const {
   // First get the generic Apple args, before moving onto Darwin-specific ones.
   DerivedArgList *DAL = MachO::TranslateArgs(Args, BoundArch);
-  const OptTable  = getDriver().getOpts();
 
   // If no architecture is bound, none of the translations here are relevant.
   if (!BoundArch)
@@ -1051,14 +1060,6 @@
 }
   }
 
-  // Default to use libc++ on OS X 10.9+ and iOS 7+.
-  if (((isTargetMacOS() && !isMacosxVersionLT(10, 9)) ||
-   (isTargetIOSBased() && !isIPhoneOSVersionLT(7, 0)) ||
-   isTargetWatchOSBased()) &&
-  !Args.getLastArg(options::OPT_stdlib_EQ))
-DAL->AddJoinedArg(nullptr, Opts.getOption(options::OPT_stdlib_EQ),
-  "libc++");
-
   // Validate the C++ standard library choice.
   CXXStdlibType Type = GetCXXStdlibType(*DAL);
   if (Type == ToolChain::CST_Libcxx) {
@@ -3027,16 +3028,7 @@
 
 Tool *Bitrig::buildLinker() const { return new tools::bitrig::Linker(*this); }
 
-ToolChain::CXXStdlibType Bitrig::GetCXXStdlibType(const ArgList ) const {
-  if (Arg *A = Args.getLastArg(options::OPT_stdlib_EQ)) {
-StringRef Value = A->getValue();
-if (Value == "libstdc++")
-  return ToolChain::CST_Libstdcxx;
-

r260662 - [CMake] Add option to switch default C++ stdlib

Author: hahnfeld
Date: Fri Feb 12 01:48:37 2016
New Revision: 260662

URL: http://llvm.org/viewvc/llvm-project?rev=260662=rev
Log:
[CMake] Add option to switch default C++ stdlib

With this option one can optionally override the architecture dependent
default library to use if no -stdlib= is provided on compiler invocation.

Differential Revision: http://reviews.llvm.org/D15920

Modified:
cfe/trunk/CMakeLists.txt
cfe/trunk/include/clang/Config/config.h.cmake
cfe/trunk/include/clang/Config/config.h.in
cfe/trunk/include/clang/Driver/ToolChain.h
cfe/trunk/lib/Driver/ToolChain.cpp
cfe/trunk/lib/Driver/ToolChains.cpp
cfe/trunk/lib/Driver/ToolChains.h

Modified: cfe/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/CMakeLists.txt?rev=260662=260661=260662=diff
==
--- cfe/trunk/CMakeLists.txt (original)
+++ cfe/trunk/CMakeLists.txt Fri Feb 12 01:48:37 2016
@@ -197,6 +197,15 @@ set(GCC_INSTALL_PREFIX "" CACHE PATH "Di
 set(DEFAULT_SYSROOT "" CACHE PATH
   "Default  to all compiler invocations for --sysroot=." )
 
+set(CLANG_DEFAULT_CXX_STDLIB "" CACHE STRING
+  "Default C++ stdlib to use (empty for architecture default, \"libstdc++\" or 
\"libc++\"")
+if (NOT(CLANG_DEFAULT_CXX_STDLIB STREQUAL "" OR
+CLANG_DEFAULT_CXX_STDLIB STREQUAL "libstdc++" OR
+CLANG_DEFAULT_CXX_STDLIB STREQUAL "libc++"))
+  message(WARNING "Resetting default C++ stdlib to use architecture default")
+  set(CLANG_DEFAULT_CXX_STDLIB "")
+endif()
+
 set(CLANG_DEFAULT_OPENMP_RUNTIME "libomp" CACHE STRING
   "Default OpenMP runtime used by -fopenmp.")
 

Modified: cfe/trunk/include/clang/Config/config.h.cmake
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Config/config.h.cmake?rev=260662=260661=260662=diff
==
--- cfe/trunk/include/clang/Config/config.h.cmake (original)
+++ cfe/trunk/include/clang/Config/config.h.cmake Fri Feb 12 01:48:37 2016
@@ -8,6 +8,9 @@
 /* Bug report URL. */
 #define BUG_REPORT_URL "${BUG_REPORT_URL}"
 
+/* Default C++ stdlib to use. */
+#define CLANG_DEFAULT_CXX_STDLIB "${CLANG_DEFAULT_CXX_STDLIB}"
+
 /* Default OpenMP runtime used by -fopenmp. */
 #define CLANG_DEFAULT_OPENMP_RUNTIME "${CLANG_DEFAULT_OPENMP_RUNTIME}"
 

Modified: cfe/trunk/include/clang/Config/config.h.in
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Config/config.h.in?rev=260662=260661=260662=diff
==
--- cfe/trunk/include/clang/Config/config.h.in (original)
+++ cfe/trunk/include/clang/Config/config.h.in Fri Feb 12 01:48:37 2016
@@ -8,6 +8,9 @@
 /* Bug report URL. */
 #undef BUG_REPORT_URL
 
+/* Default C++ stdlib to use. */
+#undef CLANG_DEFAULT_CXX_STDLIB
+
 /* Default OpenMP runtime used by -fopenmp. */
 #undef CLANG_DEFAULT_OPENMP_RUNTIME
 

Modified: cfe/trunk/include/clang/Driver/ToolChain.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/ToolChain.h?rev=260662=260661=260662=diff
==
--- cfe/trunk/include/clang/Driver/ToolChain.h (original)
+++ cfe/trunk/include/clang/Driver/ToolChain.h Fri Feb 12 01:48:37 2016
@@ -256,6 +256,10 @@ public:
 return ToolChain::RLT_Libgcc;
   }
 
+  virtual CXXStdlibType GetDefaultCXXStdlibType() const {
+return ToolChain::CST_Libstdcxx;
+  }
+
   virtual std::string getCompilerRT(const llvm::opt::ArgList ,
 StringRef Component,
 bool Shared = false) const;

Modified: cfe/trunk/lib/Driver/ToolChain.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChain.cpp?rev=260662=260661=260662=diff
==
--- cfe/trunk/lib/Driver/ToolChain.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChain.cpp Fri Feb 12 01:48:37 2016
@@ -9,6 +9,7 @@
 
 #include "Tools.h"
 #include "clang/Basic/ObjCRuntime.h"
+#include "clang/Config/config.h"
 #include "clang/Driver/Action.h"
 #include "clang/Driver/Driver.h"
 #include "clang/Driver/DriverDiagnostic.h"
@@ -533,18 +534,34 @@ ToolChain::RuntimeLibType ToolChain::Get
   return GetDefaultRuntimeLibType();
 }
 
+static bool ParseCXXStdlibType(const StringRef& Name,
+   ToolChain::CXXStdlibType& Type) {
+  if (Name == "libc++")
+Type = ToolChain::CST_Libcxx;
+  else if (Name == "libstdc++")
+Type = ToolChain::CST_Libstdcxx;
+  else
+return false;
+
+  return true;
+}
+
 ToolChain::CXXStdlibType ToolChain::GetCXXStdlibType(const ArgList ) 
const{
-  if (Arg *A = Args.getLastArg(options::OPT_stdlib_EQ)) {
-StringRef Value = A->getValue();
-if (Value == "libc++")
-  return ToolChain::CST_Libcxx;
-if (Value == "libstdc++")
-  return

r260661 - tests: Add explicit -stdlib=libstdc++ to tests that require it

Author: hahnfeld
Date: Fri Feb 12 01:48:28 2016
New Revision: 260661

URL: http://llvm.org/viewvc/llvm-project?rev=260661=rev
Log:
tests: Add explicit -stdlib=libstdc++ to tests that require it

This will be needed for the next commit that allows to switch the default
C++ library which would otherwise make these tests fail.

Modified:
cfe/trunk/test/Driver/android-standalone.cpp
cfe/trunk/test/Driver/darwin-iphone-defaults.m
cfe/trunk/test/Driver/darwin-objc-gc.m
cfe/trunk/test/Driver/darwin-sanitizer-ld.c
cfe/trunk/test/Driver/gcc-toolchain.cpp
cfe/trunk/test/Driver/linux-header-search.cpp
cfe/trunk/test/Driver/mips-cs.cpp
cfe/trunk/test/Driver/mips-fsf.cpp
cfe/trunk/test/Driver/mips-img.cpp
cfe/trunk/test/Driver/sanitizer-ld.c
cfe/trunk/test/Driver/windows-cross.c
cfe/trunk/unittests/libclang/LibclangTest.cpp

Modified: cfe/trunk/test/Driver/android-standalone.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/android-standalone.cpp?rev=260661=260660=260661=diff
==
--- cfe/trunk/test/Driver/android-standalone.cpp (original)
+++ cfe/trunk/test/Driver/android-standalone.cpp Fri Feb 12 01:48:28 2016
@@ -2,7 +2,7 @@
 // toolchain.
 //
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
-// RUN: -target arm-linux-androideabi \
+// RUN: -target arm-linux-androideabi -stdlib=libstdc++ \
 // RUN: -B%S/Inputs/basic_android_tree \
 // RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
 // RUN:   | FileCheck  %s
@@ -17,7 +17,7 @@
 // CHECK: "-L{{.*}}/sysroot/usr/lib"
 //
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
-// RUN: -target aarch64-linux-android \
+// RUN: -target aarch64-linux-android -stdlib=libstdc++ \
 // RUN: -B%S/Inputs/basic_android_tree \
 // RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
 // RUN:   | FileCheck --check-prefix=CHECK-AARCH64 %s
@@ -32,7 +32,7 @@
 // CHECK-AARCH64: "-L{{.*}}/sysroot/usr/lib"
 //
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
-// RUN: -target arm64-linux-android \
+// RUN: -target arm64-linux-android -stdlib=libstdc++ \
 // RUN: -B%S/Inputs/basic_android_tree \
 // RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
 // RUN:   | FileCheck --check-prefix=CHECK-ARM64 %s
@@ -48,7 +48,7 @@
 //
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
 // RUN: -target mipsel-linux-android \
-// RUN: -mips32 \
+// RUN: -mips32 -stdlib=libstdc++ \
 // RUN: -B%S/Inputs/basic_android_tree \
 // RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
 // RUN:   | FileCheck --check-prefix=CHECK-MIPS %s
@@ -64,7 +64,7 @@
 //
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
 // RUN: -target mipsel-linux-android \
-// RUN: -march=mips32 -mips32r2 \
+// RUN: -march=mips32 -mips32r2 -stdlib=libstdc++ \
 // RUN: -B%S/Inputs/basic_android_tree \
 // RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
 // RUN:   | FileCheck --check-prefix=CHECK-MIPSR2 %s
@@ -80,7 +80,7 @@
 //
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
 // RUN: -target mipsel-linux-android \
-// RUN: -mips32 -march=mips32r2 \
+// RUN: -mips32 -march=mips32r2 -stdlib=libstdc++ \
 // RUN: -B%S/Inputs/basic_android_tree \
 // RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
 // RUN:   | FileCheck --check-prefix=CHECK-MIPSR2-A %s
@@ -96,7 +96,7 @@
 //
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
 // RUN: -target mipsel-linux-android \
-// RUN: -mips32r6 \
+// RUN: -mips32r6 -stdlib=libstdc++ \
 // RUN: -B%S/Inputs/basic_android_tree \
 // RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
 // RUN:   | FileCheck --check-prefix=CHECK-MIPSR6 %s

Modified: cfe/trunk/test/Driver/darwin-iphone-defaults.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/darwin-iphone-defaults.m?rev=260661=260660=260661=diff
==
--- cfe/trunk/test/Driver/darwin-iphone-defaults.m (original)
+++ cfe/trunk/test/Driver/darwin-iphone-defaults.m Fri Feb 12 01:48:28 2016
@@ -1,4 +1,4 @@
-// RUN: %clang -target i386-apple-darwin9 -miphoneos-version-min=3.0 -arch 
armv7 -flto -S -o - %s | FileCheck %s
+// RUN: %clang -target i386-apple-darwin9 -miphoneos-version-min=3.0 -arch 
armv7 -stdlib=libstdc++ -flto -S -o - %s | FileCheck %s
 
 // CHECK: @f0() [[F0:#[0-9]+]]
 // CHECK: @__f0_block_invoke

Modified: cfe/trunk/test/Driver/darwin-objc-gc.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/darwin-objc-gc.m?rev=260661=260660=260661=diff
==
--- cfe/trunk/test/Driver/darwin-objc-gc.m (original)
+++ cfe/trunk/test/Driver/darwin-objc-gc.m Fri Feb 12 01:48:28 2016
@@ -1,6 +1,6 @@
 // Check that we warn, but

Re: [PATCH] D15920: [CMake] Add option to switch default C++ stdlib

Hahnfeld added a comment.

In http://reviews.llvm.org/D15920#350401, @beanz wrote:

> Can you commit the test changes in a separate commit before committing the 
> other changes? That way if something goes wrong the diff for the meat of the 
> patch is a small diff.


Committed seperately in http://reviews.llvm.org/rL260661, thanks.


Repository:
  rL LLVM

http://reviews.llvm.org/D15920



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

Re: [PATCH] D17140: [clang-tidy] improve misc-misplaced-widening-cast so it also detects portability problems

2016-02-11 Thread Daniel Marjamäki via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL260665: [clang-tidy] improve misc-misplaced-widening-cast so 
it also detects… (authored by danielmarjamaki).

Changed prior to commit:
  http://reviews.llvm.org/D17140?vs=47640=47771#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D17140

Files:
  clang-tools-extra/trunk/clang-tidy/misc/MisplacedWideningCastCheck.cpp
  clang-tools-extra/trunk/test/clang-tidy/misc-misplaced-widening-cast.cpp

Index: clang-tools-extra/trunk/test/clang-tidy/misc-misplaced-widening-cast.cpp
===
--- clang-tools-extra/trunk/test/clang-tidy/misc-misplaced-widening-cast.cpp
+++ clang-tools-extra/trunk/test/clang-tidy/misc-misplaced-widening-cast.cpp
@@ -1,4 +1,4 @@
-// RUN: %check_clang_tidy %s misc-misplaced-widening-cast %t -- -- -target 
x86_64-unknown-unknown
+// RUN: %check_clang_tidy %s misc-misplaced-widening-cast %t
 
 void assign(int a, int b) {
   long l;
Index: clang-tools-extra/trunk/clang-tidy/misc/MisplacedWideningCastCheck.cpp
===
--- clang-tools-extra/trunk/clang-tidy/misc/MisplacedWideningCastCheck.cpp
+++ clang-tools-extra/trunk/clang-tidy/misc/MisplacedWideningCastCheck.cpp
@@ -27,8 +27,7 @@
 
   auto Cast = explicitCastExpr(anyOf(cStyleCastExpr(), cxxStaticCastExpr(),
  cxxReinterpretCastExpr()),
-   hasDestinationType(isInteger()),
-   has(Calc))
+   hasDestinationType(isInteger()), has(Calc))
   .bind("Cast");
 
   Finder->addMatcher(varDecl(has(Cast)), this);
@@ -90,9 +89,29 @@
   QualType CastType = Cast->getType();
   QualType CalcType = Calc->getType();
 
-  if (Context.getIntWidth(CastType) <= Context.getIntWidth(CalcType))
+  // Explicit truncation using cast.
+  if (Context.getIntWidth(CastType) < Context.getIntWidth(CalcType))
 return;
 
+  // If CalcType and CastType have same size then there is no real danger, but
+  // there can be a portability problem.
+  if (Context.getIntWidth(CastType) == Context.getIntWidth(CalcType)) {
+if (CalcType->isSpecificBuiltinType(BuiltinType::Int)) {
+  // There should be a warning when casting from int to long or long long.
+  if (!CastType->isSpecificBuiltinType(BuiltinType::Long) &&
+  !CastType->isSpecificBuiltinType(BuiltinType::LongLong))
+return;
+} else if (CalcType->isSpecificBuiltinType(BuiltinType::Long)) {
+  // There should be a warning when casting from long to long long.
+  if (!CastType->isSpecificBuiltinType(BuiltinType::LongLong))
+return;
+} else {
+  return;
+}
+  }
+
+  // Don't write a warning if we can easily see that the result is not
+  // truncated.
   if (Context.getIntWidth(CalcType) >= getMaxCalculationWidth(Context, Calc))
 return;
 


Index: clang-tools-extra/trunk/test/clang-tidy/misc-misplaced-widening-cast.cpp
===
--- clang-tools-extra/trunk/test/clang-tidy/misc-misplaced-widening-cast.cpp
+++ clang-tools-extra/trunk/test/clang-tidy/misc-misplaced-widening-cast.cpp
@@ -1,4 +1,4 @@
-// RUN: %check_clang_tidy %s misc-misplaced-widening-cast %t -- -- -target x86_64-unknown-unknown
+// RUN: %check_clang_tidy %s misc-misplaced-widening-cast %t
 
 void assign(int a, int b) {
   long l;
Index: clang-tools-extra/trunk/clang-tidy/misc/MisplacedWideningCastCheck.cpp
===
--- clang-tools-extra/trunk/clang-tidy/misc/MisplacedWideningCastCheck.cpp
+++ clang-tools-extra/trunk/clang-tidy/misc/MisplacedWideningCastCheck.cpp
@@ -27,8 +27,7 @@
 
   auto Cast = explicitCastExpr(anyOf(cStyleCastExpr(), cxxStaticCastExpr(),
  cxxReinterpretCastExpr()),
-   hasDestinationType(isInteger()),
-   has(Calc))
+   hasDestinationType(isInteger()), has(Calc))
   .bind("Cast");
 
   Finder->addMatcher(varDecl(has(Cast)), this);
@@ -90,9 +89,29 @@
   QualType CastType = Cast->getType();
   QualType CalcType = Calc->getType();
 
-  if (Context.getIntWidth(CastType) <= Context.getIntWidth(CalcType))
+  // Explicit truncation using cast.
+  if (Context.getIntWidth(CastType) < Context.getIntWidth(CalcType))
 return;
 
+  // If CalcType and CastType have same size then there is no real danger, but
+  // there can be a portability problem.
+  if (Context.getIntWidth(CastType) == Context.getIntWidth(CalcType)) {
+if (CalcType->isSpecificBuiltinType(BuiltinType::Int)) {
+  // There should be a warning when casting from int to long or long long.
+  if (!CastType->isSpecificBuiltinType(BuiltinType::Long) &&
+  !CastType->isSpecificBuiltinType(BuiltinType::LongLong))
+

[clang-tools-extra] r260665 - [clang-tidy] improve misc-misplaced-widening-cast so it also detects portability problems.

2016-02-11 Thread Daniel Marjamaki via cfe-commits

Author: danielmarjamaki
Date: Fri Feb 12 01:51:10 2016
New Revision: 260665

URL: http://llvm.org/viewvc/llvm-project?rev=260665=rev
Log:
[clang-tidy] improve misc-misplaced-widening-cast so it also detects 
portability problems.

Reviewers: alexfh

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D17140

Modified:
clang-tools-extra/trunk/clang-tidy/misc/MisplacedWideningCastCheck.cpp
clang-tools-extra/trunk/test/clang-tidy/misc-misplaced-widening-cast.cpp

Modified: clang-tools-extra/trunk/clang-tidy/misc/MisplacedWideningCastCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/misc/MisplacedWideningCastCheck.cpp?rev=260665=260664=260665=diff
==
--- clang-tools-extra/trunk/clang-tidy/misc/MisplacedWideningCastCheck.cpp 
(original)
+++ clang-tools-extra/trunk/clang-tidy/misc/MisplacedWideningCastCheck.cpp Fri 
Feb 12 01:51:10 2016
@@ -27,8 +27,7 @@ void MisplacedWideningCastCheck::registe
 
   auto Cast = explicitCastExpr(anyOf(cStyleCastExpr(), cxxStaticCastExpr(),
  cxxReinterpretCastExpr()),
-   hasDestinationType(isInteger()),
-   has(Calc))
+   hasDestinationType(isInteger()), has(Calc))
   .bind("Cast");
 
   Finder->addMatcher(varDecl(has(Cast)), this);
@@ -90,9 +89,29 @@ void MisplacedWideningCastCheck::check(c
   QualType CastType = Cast->getType();
   QualType CalcType = Calc->getType();
 
-  if (Context.getIntWidth(CastType) <= Context.getIntWidth(CalcType))
+  // Explicit truncation using cast.
+  if (Context.getIntWidth(CastType) < Context.getIntWidth(CalcType))
 return;
 
+  // If CalcType and CastType have same size then there is no real danger, but
+  // there can be a portability problem.
+  if (Context.getIntWidth(CastType) == Context.getIntWidth(CalcType)) {
+if (CalcType->isSpecificBuiltinType(BuiltinType::Int)) {
+  // There should be a warning when casting from int to long or long long.
+  if (!CastType->isSpecificBuiltinType(BuiltinType::Long) &&
+  !CastType->isSpecificBuiltinType(BuiltinType::LongLong))
+return;
+} else if (CalcType->isSpecificBuiltinType(BuiltinType::Long)) {
+  // There should be a warning when casting from long to long long.
+  if (!CastType->isSpecificBuiltinType(BuiltinType::LongLong))
+return;
+} else {
+  return;
+}
+  }
+
+  // Don't write a warning if we can easily see that the result is not
+  // truncated.
   if (Context.getIntWidth(CalcType) >= getMaxCalculationWidth(Context, Calc))
 return;
 

Modified: 
clang-tools-extra/trunk/test/clang-tidy/misc-misplaced-widening-cast.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/misc-misplaced-widening-cast.cpp?rev=260665=260664=260665=diff
==
--- clang-tools-extra/trunk/test/clang-tidy/misc-misplaced-widening-cast.cpp 
(original)
+++ clang-tools-extra/trunk/test/clang-tidy/misc-misplaced-widening-cast.cpp 
Fri Feb 12 01:51:10 2016
@@ -1,4 +1,4 @@
-// RUN: %check_clang_tidy %s misc-misplaced-widening-cast %t -- -- -target 
x86_64-unknown-unknown
+// RUN: %check_clang_tidy %s misc-misplaced-widening-cast %t
 
 void assign(int a, int b) {
   long l;


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

Re: [PATCH] D17132: [libcxx] Fix definition of regex_traits::__regex_word on big-endian glibc systems

dsanders added inline comments.


Comment at: include/regex:980
@@ +979,3 @@
+#if defined(__GLIBC__)
+static const char_class_type __regex_word = 
static_cast(_ISbit(15));
+#else

The static_cast is necessary to silence a false-positive warning on 
little-endian. _ISbit(15) expands to:
  ((15) < 8 ? ((1 << (15)) << 8) : ((1 << (15)) >> 8))
which simplifies to:
  0 ? 0x80 : 0x80
Clang warns about the truncation of the 0x80 to char_class_type (unsigned 
short) even though this value doesn't matter.



http://reviews.llvm.org/D17132



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

r260506 - Update of "GCC extensions not implemented yet" in Clang User's Manual

2016-02-11 Thread Andrey Bokhanko via cfe-commits

Author: asbokhan
Date: Thu Feb 11 04:36:06 2016
New Revision: 260506

URL: http://llvm.org/viewvc/llvm-project?rev=260506=rev
Log:
Update of "GCC extensions not implemented yet" in Clang User's Manual

#pragma weak, global register variables and static initialization of flexible
array members are supported now, so they are removed from "GCC extensions not
implemented yet" list.

Differential Revision: http://reviews.llvm.org/D16851

Modified:
cfe/trunk/docs/UsersManual.rst

Modified: cfe/trunk/docs/UsersManual.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/UsersManual.rst?rev=260506=260505=260506=diff
==
--- cfe/trunk/docs/UsersManual.rst (original)
+++ cfe/trunk/docs/UsersManual.rst Thu Feb 11 04:36:06 2016
@@ -1694,10 +1694,6 @@ GCC extensions not implemented yet
 clang tries to be compatible with gcc as much as possible, but some gcc
 extensions are not implemented yet:
 
--  clang does not support #pragma weak (`bug
-   3679 `_). Due to the uses
-   described in the bug, this is likely to be implemented at some point,
-   at least partially.
 -  clang does not support decimal floating point types (``_Decimal32`` and
friends) or fixed-point types (``_Fract`` and friends); nobody has
expressed interest in these features yet, so it's hard to say when
@@ -1715,12 +1711,6 @@ extensions are not implemented yet:
  ...
  local_function(1);
 
--  clang does not support global register variables; this is unlikely to
-   be implemented soon because it requires additional LLVM backend
-   support.
--  clang does not support static initialization of flexible array
-   members. This appears to be a rarely used extension, but could be
-   implemented pending user demand.
 -  clang does not support
``__builtin_va_arg_pack``/``__builtin_va_arg_pack_len``. This is
used rarely, but in some potentially interesting places, like the


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

Re: [PATCH] D16851: Update of "GCC extensions not implemented yet" in Clang User's Manual

2016-02-11 Thread Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL260506: Update of "GCC extensions not implemented yet" in 
Clang User's Manual (authored by asbokhan).

Changed prior to commit:
  http://reviews.llvm.org/D16851?vs=46779=47615#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D16851

Files:
  cfe/trunk/docs/UsersManual.rst

Index: cfe/trunk/docs/UsersManual.rst
===
--- cfe/trunk/docs/UsersManual.rst
+++ cfe/trunk/docs/UsersManual.rst
@@ -1694,10 +1694,6 @@
 clang tries to be compatible with gcc as much as possible, but some gcc
 extensions are not implemented yet:
 
--  clang does not support #pragma weak (`bug
-   3679 `_). Due to the uses
-   described in the bug, this is likely to be implemented at some point,
-   at least partially.
 -  clang does not support decimal floating point types (``_Decimal32`` and
friends) or fixed-point types (``_Fract`` and friends); nobody has
expressed interest in these features yet, so it's hard to say when
@@ -1715,12 +1711,6 @@
  ...
  local_function(1);
 
--  clang does not support global register variables; this is unlikely to
-   be implemented soon because it requires additional LLVM backend
-   support.
--  clang does not support static initialization of flexible array
-   members. This appears to be a rarely used extension, but could be
-   implemented pending user demand.
 -  clang does not support
``__builtin_va_arg_pack``/``__builtin_va_arg_pack_len``. This is
used rarely, but in some potentially interesting places, like the


Index: cfe/trunk/docs/UsersManual.rst
===
--- cfe/trunk/docs/UsersManual.rst
+++ cfe/trunk/docs/UsersManual.rst
@@ -1694,10 +1694,6 @@
 clang tries to be compatible with gcc as much as possible, but some gcc
 extensions are not implemented yet:
 
--  clang does not support #pragma weak (`bug
-   3679 `_). Due to the uses
-   described in the bug, this is likely to be implemented at some point,
-   at least partially.
 -  clang does not support decimal floating point types (``_Decimal32`` and
friends) or fixed-point types (``_Fract`` and friends); nobody has
expressed interest in these features yet, so it's hard to say when
@@ -1715,12 +1711,6 @@
  ...
  local_function(1);
 
--  clang does not support global register variables; this is unlikely to
-   be implemented soon because it requires additional LLVM backend
-   support.
--  clang does not support static initialization of flexible array
-   members. This appears to be a rarely used extension, but could be
-   implemented pending user demand.
 -  clang does not support
``__builtin_va_arg_pack``/``__builtin_va_arg_pack_len``. This is
used rarely, but in some potentially interesting places, like the
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

On Thu, Feb 11, 2016 at 2:47 AM, Matthijs van Duin
 wrote:
> On 8 February 2016 at 22:40, H.J. Lu  wrote:
>> "empty type".  An empty type is either an array of empty types or a
>> class type where every member is of empty type.
>
> Note that the term "empty type" is commonly used in type theory to
> denote a (or the) type with no values.  The closest thing C has would be
> an empty enum when using -fstrict-enums.  (Declaring it as return type
> implies [[noreturn]] or undefined behaviour.)
>
> A type with a unique value (such as void or an empty struct) is usually
> known as a unit type.
>
> BTW, being standard layout is not sufficient (nor required afaict) for
> zero-register passing of a unit type.  The requirement you need is
> trivially-copyable.  Example:
>
> #include 
> #include 
> #include 
>
> using namespace std;
>
> class EmptyInt {
> static map< const EmptyInt *, int > values;
>
> public:
> EmptyInt() = default;
> EmptyInt( int x ) {  values[this] = x;  }
> ~EmptyInt() {  values.erase(this);  }
>
> operator int () const {  return values[this];  }
> };
>
> typeof( EmptyInt::values ) EmptyInt::values;
>
> EmptyInt foo() {
> return 42;
> }
>
> int main() {
> cout << is_standard_layout{} << endl;
> cout << foo() << endl;
> return 0;
> }

My current proposal is

1. "class type".  A class type is a structure, union or C++ class.
2. "empty type".  An empty type is Plain Old Data (POD) for the
   purposes of layout, and.a type where it and all of its subobjects
   are of class or array type.

> This evil contraption satisfies all POD-requirements except for not
> being trivially-copyable.  On the other hand taking this example from
> http://en.cppreference.com/w/cpp/concept/StandardLayoutType
>
> struct Q {};
> struct S : Q {};
> struct T : Q {};
> struct U : S, T {}; // not a standard-layout class
>
> Even though U is not standard-layout, it is trivially-copyable and I see
> no reason to allocate a register to pass it.
>

Since this isn't Plain Old Data (POD) for the purposes of layout, it
isn't covered by my proposal for psABI.  I leave this to C++ ABI.


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

Re: [PATCH] D16545: [libcxxabi] Enable testing for static libc++abi

2016-02-11 Thread Ben Craig via cfe-commits

bcraig added a comment.

ping


http://reviews.llvm.org/D16545



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

Re: [PATCH] D16544: [libcxx] Framework to allow testing of static libc++abi

2016-02-11 Thread Ben Craig via cfe-commits

bcraig added a comment.

ping


http://reviews.llvm.org/D16544



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

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

On Thu, Feb 11, 2016 at 6:30 AM, Michael Matz  wrote:
> Hi,
>
> On Thu, 11 Feb 2016, Jonathan Wakely wrote:
>
>> On 11 February 2016 at 12:40, Matthijs van Duin wrote:
>> > You never define "POD for the purposes of layout", and I can only
>> > interpret it as being equivalent to "standard-layout".
>>
>> As Richard pointed out, it's defined in the C++ ABI.
>
> Which is C++y as well (and hence doesn't in itself solve the C/C++
> compatibility we should strive for in the ABI).  I'll concur with Matthijs
> and think that trivially copyable is the correct distinction for passing
> without registers (in addition of it being clearer than a strangly defined
> concept of "POD-but-not-quite-POD").  Do you think different?  Are there
> non-trivially copyable examples that we'd wish to pass without registers
> as well?
>
>

Any suggestions on new wording, something like

1. "class type".  A class type is a structure, union or C++ class.
2. "empty type".  An empty type is a type where it and all of its
subobjects are of class or array type.

Does it cover

struct A { };
struct B { };
struct C : A, B { };

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

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

2016-02-11 Thread Michael Matz via cfe-commits

Hi,

On Thu, 11 Feb 2016, H.J. Lu wrote:

> Any suggestions on new wording, something like
> 
> 1. "class type".  A class type is a structure, union or C++ class.
> 2. "empty type".  An empty type is a type where it and all of its
> subobjects are of class or array type.
> 
> Does it cover
> 
> struct A { };
> struct B { };
> struct C : A, B { };

I think this is covered by the above points.  But without further 
restriction I don't see how e.g. the above example with ctors and dtors 
would be ruled out (except if you regard a ctor as a sub-object).  For 
that you seem to need trivially-copyable, or that POD-ly thing.  So, 
perhaps simply amend (2) "... is a trivially copyable type where it ...".

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

[PATCH] D17140: [clang-tidy] improve misc-misplaced-widening-cast so it also detects portability problems

2016-02-11 Thread Daniel Marjamäki via cfe-commits

danielmarjamaki created this revision.
danielmarjamaki added a reviewer: alexfh.
danielmarjamaki added a subscriber: cfe-commits.
danielmarjamaki set the repository for this revision to rL LLVM.

The misc-misplaced-widening-cast currently only looks at the size to determine 
if a cast is widening. 

With this patch it will also warn when there are portability problems.

The test file should now be target independant.


Repository:
  rL LLVM

http://reviews.llvm.org/D17140

Files:
  clang-tidy/misc/MisplacedWideningCastCheck.cpp
  test/clang-tidy/misc-misplaced-widening-cast.cpp

Index: test/clang-tidy/misc-misplaced-widening-cast.cpp
===
--- test/clang-tidy/misc-misplaced-widening-cast.cpp
+++ test/clang-tidy/misc-misplaced-widening-cast.cpp
@@ -1,4 +1,4 @@
-// RUN: %check_clang_tidy %s misc-misplaced-widening-cast %t -- -- -target 
x86_64-unknown-unknown
+// RUN: %check_clang_tidy %s misc-misplaced-widening-cast %t
 
 void assign(int a, int b) {
   long l;
Index: clang-tidy/misc/MisplacedWideningCastCheck.cpp
===
--- clang-tidy/misc/MisplacedWideningCastCheck.cpp
+++ clang-tidy/misc/MisplacedWideningCastCheck.cpp
@@ -27,8 +27,7 @@
 
   auto Cast = explicitCastExpr(anyOf(cStyleCastExpr(), cxxStaticCastExpr(),
  cxxReinterpretCastExpr()),
-   hasDestinationType(isInteger()),
-   has(Calc))
+   hasDestinationType(isInteger()), has(Calc))
   .bind("Cast");
 
   Finder->addMatcher(varDecl(has(Cast)), this);
@@ -90,9 +89,29 @@
   QualType CastType = Cast->getType();
   QualType CalcType = Calc->getType();
 
-  if (Context.getIntWidth(CastType) <= Context.getIntWidth(CalcType))
+  // Explicit truncation using cast.
+  if (Context.getIntWidth(CastType) < Context.getIntWidth(CalcType))
 return;
 
+  // If CalcType and CastType have same size then there is no real danger, but
+  // there can be a portability problem.
+  if (Context.getIntWidth(CastType) == Context.getIntWidth(CalcType)) {
+if (CalcType->isSpecificBuiltinType(BuiltinType::Int)) {
+  // There should be a warning when casting from int to long or long long.
+  if (!CastType->isSpecificBuiltinType(BuiltinType::Long) &&
+  !CastType->isSpecificBuiltinType(BuiltinType::LongLong))
+return;
+} else if (CalcType->isSpecificBuiltinType(BuiltinType::Long)) {
+  // There should be a warning when casting from long to long long.
+  if (!CastType->isSpecificBuiltinType(BuiltinType::LongLong))
+return;
+} else {
+  return;
+}
+  }
+
+  // Don't write a warning if we can easily see that the result is not
+  // truncated.
   if (Context.getIntWidth(CalcType) >= getMaxCalculationWidth(Context, Calc))
 return;
 


Index: test/clang-tidy/misc-misplaced-widening-cast.cpp
===
--- test/clang-tidy/misc-misplaced-widening-cast.cpp
+++ test/clang-tidy/misc-misplaced-widening-cast.cpp
@@ -1,4 +1,4 @@
-// RUN: %check_clang_tidy %s misc-misplaced-widening-cast %t -- -- -target x86_64-unknown-unknown
+// RUN: %check_clang_tidy %s misc-misplaced-widening-cast %t
 
 void assign(int a, int b) {
   long l;
Index: clang-tidy/misc/MisplacedWideningCastCheck.cpp
===
--- clang-tidy/misc/MisplacedWideningCastCheck.cpp
+++ clang-tidy/misc/MisplacedWideningCastCheck.cpp
@@ -27,8 +27,7 @@
 
   auto Cast = explicitCastExpr(anyOf(cStyleCastExpr(), cxxStaticCastExpr(),
  cxxReinterpretCastExpr()),
-   hasDestinationType(isInteger()),
-   has(Calc))
+   hasDestinationType(isInteger()), has(Calc))
   .bind("Cast");
 
   Finder->addMatcher(varDecl(has(Cast)), this);
@@ -90,9 +89,29 @@
   QualType CastType = Cast->getType();
   QualType CalcType = Calc->getType();
 
-  if (Context.getIntWidth(CastType) <= Context.getIntWidth(CalcType))
+  // Explicit truncation using cast.
+  if (Context.getIntWidth(CastType) < Context.getIntWidth(CalcType))
 return;
 
+  // If CalcType and CastType have same size then there is no real danger, but
+  // there can be a portability problem.
+  if (Context.getIntWidth(CastType) == Context.getIntWidth(CalcType)) {
+if (CalcType->isSpecificBuiltinType(BuiltinType::Int)) {
+  // There should be a warning when casting from int to long or long long.
+  if (!CastType->isSpecificBuiltinType(BuiltinType::Long) &&
+  !CastType->isSpecificBuiltinType(BuiltinType::LongLong))
+return;
+} else if (CalcType->isSpecificBuiltinType(BuiltinType::Long)) {
+  // There should be a warning when casting from long to long long.
+  if

Re: [libcxx] r260515 - Re-commit "Introduce a cmake module to figure out whether we need to link with libatomic."

Hi Vasileios,

This patch doesn't quite work correctly. I've committed a follow up fix to
it as r260524.

Let me know if you have any issues.

/Eric

On Thu, Feb 11, 2016 at 5:43 AM, Vasileios Kalintiris via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: vkalintiris
> Date: Thu Feb 11 06:43:04 2016
> New Revision: 260515
>
> URL: http://llvm.org/viewvc/llvm-project?rev=260515=rev
> Log:
> Re-commit "Introduce a cmake module to figure out whether we need to link
> with libatomic."
>
> This re-applies commit r260235. However, this time we add -gcc-toolchain
> to the compiler's flags when the user has specified the
> LIBCXX_GCC_TOOLCHAIN
> variable.
>
> Added:
> libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake
> Modified:
> libcxx/trunk/cmake/config-ix.cmake
> libcxx/trunk/lib/CMakeLists.txt
> libcxx/trunk/test/CMakeLists.txt
> libcxx/trunk/test/libcxx/test/target_info.py
> libcxx/trunk/test/lit.site.cfg.in
>
> Added: libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake
> URL:
> http://llvm.org/viewvc/llvm-project/libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake?rev=260515=auto
>
> ==
> --- libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake (added)
> +++ libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake Thu Feb 11 06:43:04
> 2016
> @@ -0,0 +1,41 @@
> +INCLUDE(CheckCXXSourceCompiles)
> +
> +# Sometimes linking against libatomic is required for atomic ops, if
> +# the platform doesn't support lock-free atomics.
> +#
> +# We could modify LLVM's CheckAtomic module and have it check for 64-bit
> +# atomics instead. However, we would like to avoid careless uses of 64-bit
> +# atomics inside LLVM over time on 32-bit platforms.
> +
> +function(check_cxx_atomics varname)
> +  set(OLD_CMAKE_REQUIRED_FLAGS ${CMAKE_REQUIRED_FLAGS})
> +  set(CMAKE_REQUIRED_FLAGS "-std=c++11")
> +  if (${LIBCXX_GCC_TOOLCHAIN})
> +set(CMAKE_REQUIRED_FLAGS "-std=c++11
> --gcc-toolchain=${LIBCXX_GCC_TOOLCHAIN}")
> +  endif()
> +  check_cxx_source_compiles("
> +#include 
> +#include 
> +std::atomic x;
> +std::atomic y;
> +int main() {
> +  return x + y;
> +}
> +" ${varname})
> +  set(CMAKE_REQUIRED_FLAGS ${OLD_CMAKE_REQUIRED_FLAGS})
> +endfunction(check_cxx_atomics)
> +
> +check_cxx_atomics(LIBCXX_HAVE_CXX_ATOMICS_WITH_LIB)
> +# If not, check if the library exists, and atomics work with it.
> +if(NOT LIBCXX_HAVE_CXX_ATOMICS_WITH_LIB)
> +  check_library_exists(atomic __atomic_fetch_add_8 "" HAVE_LIBATOMIC)
> +  if(HAVE_LIBATOMIC)
> +list(APPEND CMAKE_REQUIRED_LIBRARIES "atomic")
> +check_cxx_atomics(HAVE_CXX_ATOMICS_WITH_LIB)
> +if (NOT HAVE_CXX_ATOMICS_WITH_LIB)
> +  message(FATAL_ERROR "Host compiler must support std::atomic!")
> +endif()
> +  else()
> +message(FATAL_ERROR "Host compiler appears to require libatomic, but
> cannot find it.")
> +  endif()
> +endif()
>
> Modified: libcxx/trunk/cmake/config-ix.cmake
> URL:
> http://llvm.org/viewvc/llvm-project/libcxx/trunk/cmake/config-ix.cmake?rev=260515=260514=260515=diff
>
> ==
> --- libcxx/trunk/cmake/config-ix.cmake (original)
> +++ libcxx/trunk/cmake/config-ix.cmake Thu Feb 11 06:43:04 2016
> @@ -1,5 +1,6 @@
>  include(CheckLibraryExists)
>  include(CheckCXXCompilerFlag)
> +include(CheckLibcxxAtomic)
>
>  # Check compiler flags
>
> @@ -17,3 +18,7 @@ check_library_exists(c fopen "" LIBCXX_H
>  check_library_exists(m ccos "" LIBCXX_HAS_M_LIB)
>  check_library_exists(rt clock_gettime "" LIBCXX_HAS_RT_LIB)
>  check_library_exists(gcc_s __gcc_personality_v0 "" LIBCXX_HAS_GCC_S_LIB)
> +
> +if (NOT HAVE_CXX_ATOMICS_WITHOUT_LIB)
> +  set(LIBCXX_HAS_ATOMIC_LIB True)
> +endif()
>
> Modified: libcxx/trunk/lib/CMakeLists.txt
> URL:
> http://llvm.org/viewvc/llvm-project/libcxx/trunk/lib/CMakeLists.txt?rev=260515=260514=260515=diff
>
> ==
> --- libcxx/trunk/lib/CMakeLists.txt (original)
> +++ libcxx/trunk/lib/CMakeLists.txt Thu Feb 11 06:43:04 2016
> @@ -79,6 +79,7 @@ add_library_flags_if(LIBCXX_HAS_C_LIB c)
>  add_library_flags_if(LIBCXX_HAS_M_LIB m)
>  add_library_flags_if(LIBCXX_HAS_RT_LIB rt)
>  add_library_flags_if(LIBCXX_HAS_GCC_S_LIB gcc_s)
> +add_library_flags_if(LIBCXX_HAS_ATOMIC_LIB atomic)
>
>  # Setup flags.
>  add_flags_if_supported(-fPIC)
>
> Modified: libcxx/trunk/test/CMakeLists.txt
> URL:
> http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/CMakeLists.txt?rev=260515=260514=260515=diff
>
> ==
> --- libcxx/trunk/test/CMakeLists.txt (original)
> +++ libcxx/trunk/test/CMakeLists.txt Thu Feb 11 06:43:04 2016
> @@ -15,6 +15,7 @@ pythonize_bool(LIBCXX_ENABLE_SHARED)
>  pythonize_bool(LIBCXX_BUILD_32_BITS)
>  pythonize_bool(LIBCXX_GENERATE_COVERAGE)
>  pythonize_bool(LIBCXXABI_USE_LLVM_UNWINDER)
>

RE: [libcxx] r260515 - Re-commit "Introduce a cmake module to figure out whether we need to link with libatomic."

2016-02-11 Thread Vasileios Kalintiris via cfe-commits

Hi Hans,

Can we merge this on the release branch? It's a re-commit of D16613's patch 
with the an additional option (-gcc-toolchain) to the default flags, that we 
use in order to test support for atomics, when the user doesn't want to use the 
default/system GCC installation. Buildbots look good with this.

Thanks,
Vasileios


From: cfe-commits [cfe-commits-boun...@lists.llvm.org] on behalf of Vasileios 
Kalintiris via cfe-commits [cfe-commits@lists.llvm.org]
Sent: 11 February 2016 12:43
To: cfe-commits@lists.llvm.org
Subject: [libcxx] r260515 - Re-commit "Introduce a cmake module to figure out 
whether we need to link with libatomic."

Author: vkalintiris
Date: Thu Feb 11 06:43:04 2016
New Revision: 260515

URL: http://llvm.org/viewvc/llvm-project?rev=260515=rev
Log:
Re-commit "Introduce a cmake module to figure out whether we need to link with 
libatomic."

This re-applies commit r260235. However, this time we add -gcc-toolchain
to the compiler's flags when the user has specified the LIBCXX_GCC_TOOLCHAIN
variable.

Added:
libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake
Modified:
libcxx/trunk/cmake/config-ix.cmake
libcxx/trunk/lib/CMakeLists.txt
libcxx/trunk/test/CMakeLists.txt
libcxx/trunk/test/libcxx/test/target_info.py
libcxx/trunk/test/lit.site.cfg.in

Added: libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake?rev=260515=auto
==
--- libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake (added)
+++ libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake Thu Feb 11 06:43:04 2016
@@ -0,0 +1,41 @@
+INCLUDE(CheckCXXSourceCompiles)
+
+# Sometimes linking against libatomic is required for atomic ops, if
+# the platform doesn't support lock-free atomics.
+#
+# We could modify LLVM's CheckAtomic module and have it check for 64-bit
+# atomics instead. However, we would like to avoid careless uses of 64-bit
+# atomics inside LLVM over time on 32-bit platforms.
+
+function(check_cxx_atomics varname)
+  set(OLD_CMAKE_REQUIRED_FLAGS ${CMAKE_REQUIRED_FLAGS})
+  set(CMAKE_REQUIRED_FLAGS "-std=c++11")
+  if (${LIBCXX_GCC_TOOLCHAIN})
+set(CMAKE_REQUIRED_FLAGS "-std=c++11 
--gcc-toolchain=${LIBCXX_GCC_TOOLCHAIN}")
+  endif()
+  check_cxx_source_compiles("
+#include 
+#include 
+std::atomic x;
+std::atomic y;
+int main() {
+  return x + y;
+}
+" ${varname})
+  set(CMAKE_REQUIRED_FLAGS ${OLD_CMAKE_REQUIRED_FLAGS})
+endfunction(check_cxx_atomics)
+
+check_cxx_atomics(LIBCXX_HAVE_CXX_ATOMICS_WITH_LIB)
+# If not, check if the library exists, and atomics work with it.
+if(NOT LIBCXX_HAVE_CXX_ATOMICS_WITH_LIB)
+  check_library_exists(atomic __atomic_fetch_add_8 "" HAVE_LIBATOMIC)
+  if(HAVE_LIBATOMIC)
+list(APPEND CMAKE_REQUIRED_LIBRARIES "atomic")
+check_cxx_atomics(HAVE_CXX_ATOMICS_WITH_LIB)
+if (NOT HAVE_CXX_ATOMICS_WITH_LIB)
+  message(FATAL_ERROR "Host compiler must support std::atomic!")
+endif()
+  else()
+message(FATAL_ERROR "Host compiler appears to require libatomic, but 
cannot find it.")
+  endif()
+endif()

Modified: libcxx/trunk/cmake/config-ix.cmake
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/cmake/config-ix.cmake?rev=260515=260514=260515=diff
==
--- libcxx/trunk/cmake/config-ix.cmake (original)
+++ libcxx/trunk/cmake/config-ix.cmake Thu Feb 11 06:43:04 2016
@@ -1,5 +1,6 @@
 include(CheckLibraryExists)
 include(CheckCXXCompilerFlag)
+include(CheckLibcxxAtomic)

 # Check compiler flags

@@ -17,3 +18,7 @@ check_library_exists(c fopen "" LIBCXX_H
 check_library_exists(m ccos "" LIBCXX_HAS_M_LIB)
 check_library_exists(rt clock_gettime "" LIBCXX_HAS_RT_LIB)
 check_library_exists(gcc_s __gcc_personality_v0 "" LIBCXX_HAS_GCC_S_LIB)
+
+if (NOT HAVE_CXX_ATOMICS_WITHOUT_LIB)
+  set(LIBCXX_HAS_ATOMIC_LIB True)
+endif()

Modified: libcxx/trunk/lib/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/lib/CMakeLists.txt?rev=260515=260514=260515=diff
==
--- libcxx/trunk/lib/CMakeLists.txt (original)
+++ libcxx/trunk/lib/CMakeLists.txt Thu Feb 11 06:43:04 2016
@@ -79,6 +79,7 @@ add_library_flags_if(LIBCXX_HAS_C_LIB c)
 add_library_flags_if(LIBCXX_HAS_M_LIB m)
 add_library_flags_if(LIBCXX_HAS_RT_LIB rt)
 add_library_flags_if(LIBCXX_HAS_GCC_S_LIB gcc_s)
+add_library_flags_if(LIBCXX_HAS_ATOMIC_LIB atomic)

 # Setup flags.
 add_flags_if_supported(-fPIC)

Modified: libcxx/trunk/test/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/CMakeLists.txt?rev=260515=260514=260515=diff
==
--- libcxx/trunk/test/CMakeLists.txt (original)
+++ libcxx/trunk/test/CMakeLists.txt Thu Feb 11 06:43:04 2016
@@ -15,6 +15,7 @@

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

2016-02-11 Thread Michael Matz via cfe-commits

Hi,

On Thu, 11 Feb 2016, Jonathan Wakely wrote:

> On 11 February 2016 at 12:40, Matthijs van Duin wrote:
> > You never define "POD for the purposes of layout", and I can only
> > interpret it as being equivalent to "standard-layout".
> 
> As Richard pointed out, it's defined in the C++ ABI.

Which is C++y as well (and hence doesn't in itself solve the C/C++ 
compatibility we should strive for in the ABI).  I'll concur with Matthijs 
and think that trivially copyable is the correct distinction for passing 
without registers (in addition of it being clearer than a strangly defined 
concept of "POD-but-not-quite-POD").  Do you think different?  Are there 
non-trivially copyable examples that we'd wish to pass without registers 
as well?

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

Re: [PATCH] D16922: [clang-tidy] Added check-fixes for misc-virtual-near-miss.

2016-02-11 Thread Alexander Kornienko via cfe-commits

alexfh accepted this revision.
alexfh added a comment.
This revision is now accepted and ready to land.

Looks good now. Thank you!


http://reviews.llvm.org/D16922



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

Re: [PATCH] D15797: [clang-tidy] Fix readability-braces-around-statements assert failure

2016-02-11 Thread Alexander Kornienko via cfe-commits

alexfh added a comment.

An alternative fix has recently been committed. Can you run clang-tidy built 
after r260505 on your code?


Repository:
  rL LLVM

http://reviews.llvm.org/D15797



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

Re: [PATCH] D17148: [OPENMP] Basic teams directive implementation

2016-02-11 Thread Alexey Bataev via cfe-commits

ABataev added inline comments.


Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:4378-4398
@@ +4377,23 @@
+
+  const OMPNumTeamsClause *NT = TD.getSingleClause();
+  const OMPThreadLimitClause *TL = TD.getSingleClause();
+  if (NT || TL) {
+NumTeamsVal = (NT) ? CGF.EmitScalarExpr(NT->getNumTeams(), true) :
+NumTeamsVal = CGF.Builder.getInt32(0);
+
+NumTeamsVal = (NT) ? CGF.Builder.CreateIntCast(
+  CGF.EmitScalarExpr(NT->getNumTeams()), CGM.Int32Ty,
+ /* isSigned = */ true) :
+CGF.Builder.getInt32(0);
+
+ThreadLimitVal = (TL) ? CGF.Builder.CreateIntCast(
+  CGF.EmitScalarExpr(TL->getThreadLimit()), CGM.Int32Ty,
+ /* isSigned = */ true) :
+CGF.Builder.getInt32(0);
+
+llvm::Value *PushNumTeamsArgs[] = {
+RTLoc, getThreadID(CGF, Loc), NumTeamsVal, ThreadLimitVal};
+CGF.EmitRuntimeCall(createRuntimeFunction(OMPRTL__kmpc_push_num_teams),
+PushNumTeamsArgs);
+  }
+

I don't like the idea of processing num_teams and thread_limit clauses in 
runtime lib. This must be done in emitCommonOMPTeamsDirective(), not in runtime


Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:4413-4424
@@ +4412,13 @@
+
+llvm::Value *CGOpenMPRuntime::emitTeamsOutlinedFunction(
+const OMPExecutableDirective , const VarDecl *ThreadIDVar,
+OpenMPDirectiveKind InnermostKind, const RegionCodeGenTy ) {
+  assert(ThreadIDVar->getType()->isPointerType() &&
+ "thread id variable must be of type kmp_int32 *");
+  const CapturedStmt *CS = cast(D.getAssociatedStmt());
+  CodeGenFunction CGF(CGM, true);
+  CGOpenMPOutlinedRegionInfo CGInfo(*CS, ThreadIDVar, CodeGen, InnermostKind,
+/*HasCancel =*/ false);
+  CodeGenFunction::CGCapturedStmtRAII CapInfoRAII(CGF, );
+  return CGF.GenerateOpenMPCapturedStmtFunction(*CS);
+}

This is very similar to emitParallelOutlinedFunction(). Maybe it is a good idea 
to join them into a single one?


http://reviews.llvm.org/D17148



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

Re: [PATCH] D17170: [OPENMP] Codegen for distribute directive

2016-02-11 Thread Alexey Bataev via cfe-commits

ABataev added inline comments.


Comment at: lib/CodeGen/CGOpenMPRuntime.h:669-692
@@ -668,1 +668,26 @@
 
+  /// \brief Schedule types for 'omp for' loops (these enumerators are taken 
from
+   /// the enum sched_type in kmp.h).
+   enum OpenMPSchedType {
+ /// \brief Lower bound for default (unordered) versions.
+ OMP_sch_lower = 32,
+ OMP_sch_static_chunked = 33,
+ OMP_sch_static = 34,
+ OMP_sch_dynamic_chunked = 35,
+ OMP_sch_guided_chunked = 36,
+ OMP_sch_runtime = 37,
+ OMP_sch_auto = 38,
+ /// \brief Lower bound for 'ordered' versions.
+ OMP_ord_lower = 64,
+ OMP_ord_static_chunked = 65,
+ OMP_ord_static = 66,
+ OMP_ord_dynamic_chunked = 67,
+ OMP_ord_guided_chunked = 68,
+ OMP_ord_runtime = 69,
+ OMP_ord_auto = 70,
+ /// \brief dist_schedule types
+ OMP_dist_sch_static_chunked = 91,
+ OMP_dist_sch_static = 92,
+ OMP_sch_default = OMP_sch_static,
+   };
+

I don't like the idea of exposing this in the header file. getRuntimeSchedule() 
can be turned into static functions in .cpp file


Comment at: lib/CodeGen/CGOpenMPRuntime.h:717-725
@@ -682,2 +716,11 @@
 
+  /// \brief Check if the specified \a DistScheduleKind is static non-chunked.
+  /// This kind of distribute directive is emitted without outer loop.
+  /// \param ScheduleKind DistSchedule kind specified in the 'dist_schedule'
+  /// clause.
+  /// \param Chunked True if chunk is specified in the clause.
+  ///
+  virtual bool isDistStaticNonchunked(OpenMPDistScheduleClauseKind 
ScheduleKind,
+  bool Chunked) const;
+
   virtual void emitForDispatchInit(CodeGenFunction , SourceLocation Loc,

What's the difference between isStaticNonchunked() and 
isDistStaticNonchunked()? For me they must be the same.


Comment at: lib/CodeGen/CGOpenMPRuntime.h:759
@@ +758,3 @@
+  ///
+  void emitForStaticInitWithKMPSchedule(CodeGenFunction ,
+SourceLocation Loc,

I don't think this function is required at all. You can just add an optional 
argument to emitForStaticInit() function.


Comment at: lib/CodeGen/CGOpenMPRuntime.h:761
@@ +760,3 @@
+SourceLocation Loc,
+OpenMPSchedType Schedule,
+unsigned IVSize, bool IVSigned,

It is a bad idea to expose runtime-specific type in interface functions. Use 
OpenMPDistScheduleClauseKind instead and translate it inside.


Comment at: lib/CodeGen/CGStmtOpenMP.cpp:1540-1541
@@ +1539,4 @@
+
+  RT.emitDistributeStaticInit(*this, S.getLocStart(), ScheduleKind,
+ IVSize, IVSigned, IL, LB, UB, ST, Chunk);
+

Bad formatting


Comment at: lib/CodeGen/CGStmtOpenMP.cpp:2185-2216
@@ -2147,1 +2184,34 @@
 
+static std::pair
+emitDistScheduleClause(CodeGenFunction , const OMPDistributeDirective ,
+   bool OuterRegion) {
+  // Detect the distribute schedule kind and chunk.
+  auto ScheduleKind = OMPC_DIST_SCHEDULE_unknown;
+  llvm::Value *Chunk = nullptr;
+  if (const auto *C = S.getSingleClause()) {
+ScheduleKind = C->getDistScheduleKind();
+if (const auto *Ch = C->getChunkSize()) {
+  if (auto *ImpRef = cast_or_null(C->getHelperChunkSize())) {
+if (OuterRegion) {
+  const VarDecl *ImpVar = cast(ImpRef->getDecl());
+  CGF.EmitVarDecl(*ImpVar);
+  CGF.EmitStoreThroughLValue(
+  CGF.EmitAnyExpr(Ch),
+  CGF.MakeAddrLValue(CGF.GetAddrOfLocalVar(ImpVar),
+ ImpVar->getType()));
+} else {
+  Ch = ImpRef;
+}
+  }
+  if (!C->getHelperChunkSize() || !OuterRegion) {
+Chunk = CGF.EmitScalarExpr(Ch);
+Chunk = CGF.EmitScalarConversion(Chunk, Ch->getType(),
+ S.getIterationVariable()->getType(),
+ S.getLocStart());
+  }
+}
+  }
+  return std::make_pair(Chunk, ScheduleKind);
+}
+
+void CodeGenFunction::EmitOMPDistributeLoop(const OMPDistributeDirective ) {

Wait few days for this code. I will commit improved code for schedule clause 
codegen, that simplifies all similar stuff


Comment at: lib/CodeGen/CodeGenFunction.h:2405
@@ -2397,2 +2404,3 @@
   OpenMPDirectiveKind EmitSections(const OMPExecutableDirective );
+  void EmitOMPDistributeLoop(const OMPDistributeDirective );
 

This must be public along with other codegen function for other directives


Repository:
  rL LLVM

http://reviews.llvm.org/D17170



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

Re: [libcxx] r260337 - Fix overload sets of strchr, strpbrk, strrchr, memchr and strstr from

Argh, the glibc folks broke their string.h and wchar.h prototypes in
this commit:

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=8e2e833ac4d6509b152d6b8d74d388725717c56f

On Thu, Feb 11, 2016 at 11:02 AM, Ismail Donmez  wrote:
> Hi,
>
> On Wed, Feb 10, 2016 at 2:59 AM, Richard Smith via cfe-commits
>  wrote:
>> Author: rsmith
>> Date: Tue Feb  9 18:59:02 2016
>> New Revision: 260337
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=260337=rev
>> Log:
>> Fix overload sets of strchr, strpbrk, strrchr, memchr and strstr from
>>  and wcschr, wcspbrk, wcsrchr, wmemchr, and wcsstr from  
>> to
>> provide a const-correct overload set even when the underlying C library does
>> not.
>>
>> This change adds a new macro, _LIBCPP_PREFERRED_OVERLOAD, which (if defined)
>> specifies that a given overload is a better match than an otherwise equally
>> good function declaration without the overload. This is implemented in modern
>> versions of Clang via __attribute__((enable_if)), and not elsewhere.
>>
>> We use this new macro to define overloads in the global namespace for these
>> functions that displace the overloads provided by the C library, unless we
>> believe the C library is already providing the correct signatures.
>>
>> Added:
>> libcxx/trunk/include/string.h
>>   - copied, changed from r251642, libcxx/trunk/include/string.h
>> Modified:
>> libcxx/trunk/include/__config
>> libcxx/trunk/include/cstring
>> libcxx/trunk/include/cwchar
>> libcxx/trunk/include/wchar.h
>> libcxx/trunk/test/std/depr/depr.c.headers/string_h.pass.cpp
>> libcxx/trunk/test/std/depr/depr.c.headers/wchar_h.pass.cpp
>> libcxx/trunk/test/std/strings/c.strings/cstring.pass.cpp
>> libcxx/trunk/test/std/strings/c.strings/cwchar.pass.cpp
>
> Fails on Linux x86-64 with glibc 2.22:
>
> /home/abuild/rpmbuild/BUILD/llvm/projects/libcxx/test/std/depr/depr.c.headers/string_h.pass.cpp:55:5:
> error: static_assert failed ""
> static_assert((std::is_same char*>::value), "");
> ^ 
> /home/abuild/rpmbuild/BUILD/llvm/projects/libcxx/test/std/depr/depr.c.headers/string_h.pass.cpp:56:5:
> error: static_assert failed ""
> static_assert((std::is_same char*>::value), "");
> ^
> ~~~
> /home/abuild/rpmbuild/BUILD/llvm/projects/libcxx/test/std/depr/depr.c.headers/string_h.pass.cpp:57:5:
> error: static_assert failed ""
> static_assert((std::is_same char*>::value), "");
> ^ 
> ~
> /home/abuild/rpmbuild/BUILD/llvm/projects/libcxx/test/std/depr/depr.c.headers/string_h.pass.cpp:58:5:
> error: static_assert failed ""
> static_assert((std::is_same char*>::value), "");
> ^ 
> ~~
> /home/abuild/rpmbuild/BUILD/llvm/projects/libcxx/test/std/depr/depr.c.headers/string_h.pass.cpp:59:5:
> error: static_assert failed ""
> static_assert((std::is_same void*>::value), "");
> ^
> ~~~
> 5 errors generated.
>
>
> /home/abuild/rpmbuild/BUILD/llvm/projects/libcxx/test/std/strings/c.strings/cstring.pass.cpp:55:5:
> error: static_assert failed ""
> static_assert((std::is_same const void*>::value), "");
> ^
> 
> /home/abuild/rpmbuild/BUILD/llvm/projects/libcxx/test/std/strings/c.strings/cstring.pass.cpp:56:5:
> error: static_assert failed ""
> static_assert((std::is_same char*>::value), "");
> ^
> ~
> /home/abuild/rpmbuild/BUILD/llvm/projects/libcxx/test/std/strings/c.strings/cstring.pass.cpp:57:5:
> error: static_assert failed ""
> static_assert((std::is_same const char*>::value), "");
> ^
> 
> /home/abuild/rpmbuild/BUILD/llvm/projects/libcxx/test/std/strings/c.strings/cstring.pass.cpp:58:5:
> error: static_assert failed ""
> static_assert((std::is_same char*>::value), "");
> ^
> ~~
> /home/abuild/rpmbuild/BUILD/llvm/projects/libcxx/test/std/strings/c.strings/cstring.pass.cpp:59:5:
> error: static_assert failed ""
> static_assert((std::is_same char*>::value), "");
> ^
> ~~~
> 5 errors generated.

Re: [PATCH] D15920: [CMake] Add option to switch default C++ stdlib

2016-02-11 Thread Chris Bieneman via cfe-commits

beanz added a comment.

Everything about this looks reasonable to me.

Can you commit the test changes in a separate commit before committing the 
other changes? That way if something goes wrong the diff for the meat of the 
patch is a small diff.


http://reviews.llvm.org/D15920



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

Re: r252114 - [modules] If we're given a module file, via -fmodule-file=, for a module, but

2016-02-11 Thread Adrian Prantl via cfe-commits


> On Feb 11, 2016, at 11:04 AM, Ben Langmuir  wrote:
> 
> FYI I changed this to early-exit again in r260563 to fix implicit builds.  
> It’s not safe to keep reading if we haven’t told ReadOptionsBlock to expect 
> failures, since it will itself early-exit, leaving the stream in the middle 
> of a block.  It’s also a performance advantage to early exit when doing 
> implicit builds.
> 
> Ben

Thanks, Ben!

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

r260577 - In C11, provide macros FLT_DECIMAL_DIG, DBL_DECIMAL_DIG, and LDBL_DECIMAL_DIG in .

Author: rsmith
Date: Thu Feb 11 13:57:37 2016
New Revision: 260577

URL: http://llvm.org/viewvc/llvm-project?rev=260577=rev
Log:
In C11, provide macros FLT_DECIMAL_DIG, DBL_DECIMAL_DIG, and LDBL_DECIMAL_DIG 
in .

Patch by Jorge Teixeira!

Added:
cfe/trunk/test/Headers/float.c
Modified:
cfe/trunk/lib/Headers/float.h

Modified: cfe/trunk/lib/Headers/float.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/float.h?rev=260577=260576=260577=diff
==
--- cfe/trunk/lib/Headers/float.h (original)
+++ cfe/trunk/lib/Headers/float.h Thu Feb 11 13:57:37 2016
@@ -68,6 +68,9 @@
 #undef FLT_TRUE_MIN
 #undef DBL_TRUE_MIN
 #undef LDBL_TRUE_MIN
+#undef FLT_DECIMAL_DIG
+#undef DBL_DECIMAL_DIG
+#undef LDBL_DECIMAL_DIG
 #  endif
 #endif
 
@@ -119,6 +122,9 @@
 #  define FLT_TRUE_MIN __FLT_DENORM_MIN__
 #  define DBL_TRUE_MIN __DBL_DENORM_MIN__
 #  define LDBL_TRUE_MIN __LDBL_DENORM_MIN__
+#  define FLT_DECIMAL_DIG __FLT_DECIMAL_DIG__
+#  define DBL_DECIMAL_DIG __DBL_DECIMAL_DIG__
+#  define LDBL_DECIMAL_DIG __LDBL_DECIMAL_DIG__
 #endif
 
 #endif /* __FLOAT_H */

Added: cfe/trunk/test/Headers/float.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Headers/float.c?rev=260577=auto
==
--- cfe/trunk/test/Headers/float.c (added)
+++ cfe/trunk/test/Headers/float.c Thu Feb 11 13:57:37 2016
@@ -0,0 +1,211 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c89 -ffreestanding %s
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c99 -ffreestanding %s
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c11 -ffreestanding %s
+// expected-no-diagnostics
+
+/* Basic conformance checks against the N1570 draft of C11 Std. */
+/*
+5.2.4.2.2p11, pp. 30
+*/
+#include 
+
+#ifndef FLT_RADIX
+#error "Mandatory macro FLT_RADIX is missing."
+#elif   FLT_RADIX < 2
+#error "Mandatory macro FLT_RADIX is invalid."
+#endif
+
+
+#ifndef FLT_MANT_DIG
+#error "Mandatory macro FLT_MANT_DIG is missing."
+#elif   FLT_MANT_DIG < 1
+#error "Mandatory macro FLT_MANT_DIG is invalid."
+#endif
+#ifndef DBL_MANT_DIG
+#error "Mandatory macro DBL_MANT_DIG is missing."
+#elif   DBL_MANT_DIG < 1
+#error "Mandatory macro DBL_MANT_DIG is invalid."
+#endif
+#ifndef LDBL_MANT_DIG
+#error "Mandatory macro LDBL_MANT_DIG is missing."
+#elif   LDBL_MANT_DIG < 1
+#error "Mandatory macro LDBL_MANT_DIG is invalid."
+#endif
+#if ((FLT_MANT_DIG > DBL_MANT_DIG) || (DBL_MANT_DIG > LDBL_MANT_DIG))
+#error "Mandatory macros {FLT,DBL,LDBL}_MANT_DIG are invalid."
+#endif
+
+
+#if __STDC_VERSION__ >= 201112L || !defined(__STRICT_ANSI__)
+#ifndef FLT_DECIMAL_DIG
+#error "Mandatory macro FLT_DECIMAL_DIG is missing."
+#elif   FLT_DECIMAL_DIG < 6
+#error "Mandatory macro FLT_DECIMAL_DIG is invalid."
+#endif
+#ifndef DBL_DECIMAL_DIG
+#error "Mandatory macro DBL_DECIMAL_DIG is missing."
+#elif   DBL_DECIMAL_DIG < 10
+#error "Mandatory macro DBL_DECIMAL_DIG is invalid."
+#endif
+#ifndef LDBL_DECIMAL_DIG
+#error "Mandatory macro LDBL_DECIMAL_DIG is missing."
+#elif   LDBL_DECIMAL_DIG < 10
+#error "Mandatory macro LDBL_DECIMAL_DIG is invalid."
+#endif
+#if ((FLT_DECIMAL_DIG > DBL_DECIMAL_DIG) || (DBL_DECIMAL_DIG > 
LDBL_DECIMAL_DIG))
+#error "Mandatory macros {FLT,DBL,LDBL}_DECIMAL_DIG are invalid."
+#endif
+#else
+#ifdef FLT_DECIMAL_DIG
+#error "Macro FLT_DECIMAL_DIG should not be defined."
+#endif
+#ifdef DBL_DECIMAL_DIG
+#error "Macro DBL_DECIMAL_DIG should not be defined."
+#endif
+#ifdef LDBL_DECIMAL_DIG
+#error "Macro LDBL_DECIMAL_DIG should not be defined."
+#endif
+#endif
+
+
+#ifndef DECIMAL_DIG
+#error "Mandatory macro DECIMAL_DIG is missing."
+#elif   DECIMAL_DIG < 10
+#error "Mandatory macro DECIMAL_DIG is invalid."
+#endif
+
+
+#ifndef FLT_DIG
+#error "Mandatory macro FLT_DIG is missing."
+#elif   FLT_DIG < 6
+#error "Mandatory macro FLT_DIG is invalid."
+#endif
+#ifndef DBL_DIG
+#error "Mandatory macro DBL_DIG is missing."
+#elif   DBL_DIG < 10
+#error "Mandatory macro DBL_DIG is invalid."
+#endif
+#ifndef LDBL_DIG
+#error "Mandatory macro LDBL_DIG is missing."
+#elif   LDBL_DIG < 10
+#error "Mandatory macro LDBL_DIG is invalid."
+#endif
+#if ((FLT_DIG > DBL_DIG) || (DBL_DIG > LDBL_DIG))
+#error "Mandatory macros {FLT,DBL,LDBL}_DIG, are invalid."
+#endif
+
+
+#ifndef FLT_MIN_EXP
+#error "Mandatory macro _MIN_EXP is missing."
+#elif   FLT_MIN_EXP > -2
+#error "Mandatory macro _MIN_EXP is invalid."
+#endif
+#ifndef DBL_MIN_EXP
+#error "Mandatory macro DBL_MIN_EXP is missing."
+#elif   DBL_MIN_EXP > -2
+#error "Mandatory macro DBL_MIN_EXP is invalid."
+#endif
+#ifndef LDBL_MIN_EXP
+#error "Mandatory macro LDBL_MIN_EXP is missing."
+#elif   LDBL_MIN_EXP > -2

r260581 - Add parse+sema and regression test for OpenMP firstprivate clause of target directive

2016-02-11 Thread Carlo Bertolli via cfe-commits

Author: cbertol
Date: Thu Feb 11 14:12:28 2016
New Revision: 260581

URL: http://llvm.org/viewvc/llvm-project?rev=260581=rev
Log:
Add parse+sema and regression test for OpenMP firstprivate clause of target 
directive

Added:
cfe/trunk/test/OpenMP/target_firstprivate_messages.cpp
Modified:
cfe/trunk/include/clang/Basic/OpenMPKinds.def

Modified: cfe/trunk/include/clang/Basic/OpenMPKinds.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/OpenMPKinds.def?rev=260581=260580=260581=diff
==
--- cfe/trunk/include/clang/Basic/OpenMPKinds.def (original)
+++ cfe/trunk/include/clang/Basic/OpenMPKinds.def Thu Feb 11 14:12:28 2016
@@ -379,6 +379,7 @@ OPENMP_TARGET_CLAUSE(private)
 OPENMP_TARGET_CLAUSE(nowait)
 OPENMP_TARGET_CLAUSE(depend)
 OPENMP_TARGET_CLAUSE(defaultmap)
+OPENMP_TARGET_CLAUSE(firstprivate)
 
 // Clauses allowed for OpenMP directive 'target data'.
 // TODO More clauses for 'target data' directive.

Added: cfe/trunk/test/OpenMP/target_firstprivate_messages.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/OpenMP/target_firstprivate_messages.cpp?rev=260581=auto
==
--- cfe/trunk/test/OpenMP/target_firstprivate_messages.cpp (added)
+++ cfe/trunk/test/OpenMP/target_firstprivate_messages.cpp Thu Feb 11 14:12:28 
2016
@@ -0,0 +1,196 @@
+// RUN: %clang_cc1 -verify -fopenmp %s
+
+struct S1; // expected-note 2 {{declared here}} expected-note 2 {{forward 
declaration of 'S1'}}
+extern S1 a;
+class S2 {
+  mutable int a;
+
+public:
+  S2() : a(0) {}
+};
+const S2 b;
+const S2 ba[5];
+class S3 {
+  int a;
+
+public:
+  S3() : a(0) {}
+};
+const S3 ca[5];
+class S4 {
+  int a;
+  S4();
+
+public:
+  S4(int v) : a(v) {
+#pragma omp target firstprivate(a) firstprivate(this->a)
+for (int k = 0; k < v; ++k)
+  ++this->a;
+  }
+};
+class S5 {
+  int a;
+  S5() : a(0) {}
+
+public:
+  S5(int v) : a(v) {}
+  S5 =(S5 ) {
+#pragma omp target firstprivate(a) firstprivate(this->a) firstprivate(s.a) // 
expected-error {{expected variable name or data member of current class}}
+for (int k = 0; k < s.a; ++k)
+  ++s.a;
+return *this;
+  }
+};
+
+template 
+class S6 {
+public:
+  T a;
+
+  S6() : a(0) {}
+  S6(T v) : a(v) {
+#pragma omp target firstprivate(a) firstprivate(this->a)
+for (int k = 0; k < v; ++k)
+  ++this->a;
+  }
+  S6 =(S6 ) {
+#pragma omp target firstprivate(a) firstprivate(this->a) firstprivate(s.a) // 
expected-error {{expected variable name or data member of current class}}
+for (int k = 0; k < s.a; ++k)
+  ++s.a;
+return *this;
+  }
+};
+
+template 
+class S7 : public T {
+  T a;
+  S7() : a(0) {}
+
+public:
+  S7(T v) : a(v) {
+#pragma omp target firstprivate(a) firstprivate(this->a) firstprivate(T::a)
+for (int k = 0; k < a.a; ++k)
+  ++this->a.a;
+  }
+  S7 =(S7 ) {
+#pragma omp target firstprivate(a) firstprivate(this->a) firstprivate(s.a) 
firstprivate(s.T::a) // expected-error 2 {{expected variable name or data 
member of current class}}
+for (int k = 0; k < s.a.a; ++k)
+  ++s.a.a;
+return *this;
+  }
+};
+
+S3 h;
+#pragma omp threadprivate(h) // expected-note 2 {{defined as threadprivate or 
thread local}}
+
+template 
+int foomain(I argc, C **argv) {
+  I e(4);
+  I g(5);
+  int i;
+  int  = i;
+#pragma omp target firstprivate // expected-error {{expected '(' after 
'firstprivate'}}
+{}
+#pragma omp target firstprivate( // expected-error {{expected expression}} 
expected-error {{expected ')'}} expected-note {{to match this '('}}
+{}
+#pragma omp target firstprivate() // expected-error {{expected expression}}
+{}
+#pragma omp target firstprivate(argc // expected-error {{expected ')'}} 
expected-note {{to match this '('}}
+{}
+#pragma omp target firstprivate(argc, // expected-error {{expected 
expression}} expected-error {{expected ')'}} expected-note {{to match this '('}}
+{}
+#pragma omp target firstprivate(argc > 0 ? argv[1] : argv[2]) // 
expected-error {{expected variable name}}
+{}
+#pragma omp target firstprivate(argc)
+{}
+#pragma omp target firstprivate(S1) // expected-error {{'S1' does not refer to 
a value}}
+{}
+#pragma omp target firstprivate(a, b) // expected-error {{firstprivate 
variable with incomplete type 'S1'}}
+{}
+#pragma omp target firstprivate(argv[1]) // expected-error {{expected variable 
name}}
+{}
+#pragma omp target firstprivate(e, g)
+{}
+#pragma omp target firstprivate(h) // expected-error {{threadprivate or thread 
local variable cannot be firstprivate}}
+{}
+#pragma omp target shared(i) // expected-error {{unexpected OpenMP clause 
'shared' in directive '#pragma omp target'}}
+#pragma omp parallel
+  {
+int v = 0;
+int i;
+  }
+#pragma omp parallel shared(i)
+#pragma omp parallel firstprivate(i)
+#pragma omp target firstprivate(j)
+{}
+#pragma omp target firstprivate(i)
+  {}
+  return 0;
+}
+
+void bar(S4 a[2]) {

Re: [PATCH] D17076: [OPENMP] firstprivate clause for target

2016-02-11 Thread Carlo Bertolli via cfe-commits

carlo.bertolli closed this revision.
carlo.bertolli added a comment.

Committed revision 260581.


Repository:
  rL LLVM

http://reviews.llvm.org/D17076



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

Re: [PATCH] D16040: [OpenCL] Refine OpenCLImageAccessAttr to OpenCLAccessAttr

2016-02-11 Thread Anastasia Stulova via cfe-commits

Anastasia accepted this revision.
Anastasia added a comment.
This revision is now accepted and ready to land.

LGTM!

@Pekka, any comments here? We will finalize it if not.



Comment at: lib/Sema/SemaDeclAttr.cpp:5823
@@ -5788,8 +5822,3 @@
 
-  // Walk the declarator structure, applying decl attributes that were in a 
type
-  // position to the decl itself.  This handles cases like:
-  //   int *__attr__(x)** D;
-  // when X is a decl attribute.
-  for (unsigned i = 0, e = PD.getNumTypeObjects(); i != e; ++i)
-if (const AttributeList *Attrs = PD.getTypeObject(i).getAttrs())
-  ProcessDeclAttributeList(S, D, Attrs, /*IncludeCXX11Attributes=*/false);
+  // Skip pipe type, otherwise it will be processed twice with its element type
+  const ParmVarDecl *PDecl = llvm::dyn_cast(D);

. missing


http://reviews.llvm.org/D16040



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

Re: [PATCH] D17132: [libcxx] Fix definition of regex_traits::__regex_word on big-endian glibc systems

dsanders added a comment.

I haven't fully proven this yet (because I haven't found the table), but I 
think that C and C++ are sharing the same table and we're colliding with a bit 
that only makes sense to C. This would explain why your tests don't fail but 
regex_word still collides with _ISgraph in the table.

I've confirmed that glibc is testing for _ISgraph, and libstdc++ defines 
ctype_base as per the standard. I just need to find the table.


http://reviews.llvm.org/D17132



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

Re: [PATCH] D16946: Add link to llvm git documentation, and recommend always building libcxx on OSX

2016-02-11 Thread don hinton via cfe-commits

hintonda added a comment.

Thanks Marshall.

Btw, I don't have commit access, so if approved, could someone commit this for 
me?


http://reviews.llvm.org/D16946



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

r260567 - [PR26550] Use a different TBAA root for C++ vs C.

2016-02-11 Thread Manman Ren via cfe-commits

Author: mren
Date: Thu Feb 11 13:19:18 2016
New Revision: 260567

URL: http://llvm.org/viewvc/llvm-project?rev=260567=rev
Log:
[PR26550] Use a different TBAA root for C++ vs C.

This commit changes the root from "Simple C/C++ TBAA" to "Simple C++ TBAA" for
C++.

The problem is that the type name in the TBAA nodes is generated differently
for C vs C++. If we link an IR file for C with an IR file for C++, since they
have the same root and the type names are different, accesses to the two type
nodes will be considered no-alias, even though the two type nodes are from
the same type in a header file.

The fix is to use different roots for C and C++. Types from C will be treated
conservatively in respect to types from C++.

Follow-up commits will change the C root to "Simple C TBAA" plus some mangling
change for C types to make it a little more aggresive.

Modified:
cfe/trunk/lib/CodeGen/CodeGenTBAA.cpp
cfe/trunk/test/CodeGen/tbaa-class.cpp
cfe/trunk/test/CodeGen/tbaa-for-vptr.cpp
cfe/trunk/test/CodeGen/tbaa.cpp

Modified: cfe/trunk/lib/CodeGen/CodeGenTBAA.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenTBAA.cpp?rev=260567=260566=260567=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenTBAA.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenTBAA.cpp Thu Feb 11 13:19:18 2016
@@ -44,8 +44,12 @@ llvm::MDNode *CodeGenTBAA::getRoot() {
   // if our LLVM IR is linked with LLVM IR from a different front-end
   // (or a different version of this front-end), their TBAA trees will
   // remain distinct, and the optimizer will treat them conservatively.
-  if (!Root)
-Root = MDHelper.createTBAARoot("Simple C/C++ TBAA");
+  if (!Root) {
+if (Features.CPlusPlus)
+  Root = MDHelper.createTBAARoot("Simple C++ TBAA");
+else
+  Root = MDHelper.createTBAARoot("Simple C/C++ TBAA");
+  }
 
   return Root;
 }

Modified: cfe/trunk/test/CodeGen/tbaa-class.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/tbaa-class.cpp?rev=260567=260566=260567=diff
==
--- cfe/trunk/test/CodeGen/tbaa-class.cpp (original)
+++ cfe/trunk/test/CodeGen/tbaa-class.cpp Thu Feb 11 13:19:18 2016
@@ -199,7 +199,7 @@ uint32_t g12(StructC *C, StructD *D, uin
 }
 
 // CHECK: [[TYPE_char:!.*]] = !{!"omnipotent char", [[TAG_cxx_tbaa:!.*]],
-// CHECK: [[TAG_cxx_tbaa]] = !{!"Simple C/C++ TBAA"}
+// CHECK: [[TAG_cxx_tbaa]] = !{!"Simple C++ TBAA"}
 // CHECK: [[TAG_i32]] = !{[[TYPE_i32:!.*]], [[TYPE_i32]], i64 0}
 // CHECK: [[TYPE_i32]] = !{!"int", [[TYPE_char]],
 // CHECK: [[TAG_i16]] = !{[[TYPE_i16:!.*]], [[TYPE_i16]], i64 0}

Modified: cfe/trunk/test/CodeGen/tbaa-for-vptr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/tbaa-for-vptr.cpp?rev=260567=260566=260567=diff
==
--- cfe/trunk/test/CodeGen/tbaa-for-vptr.cpp (original)
+++ cfe/trunk/test/CodeGen/tbaa-for-vptr.cpp Thu Feb 11 13:19:18 2016
@@ -32,4 +32,4 @@ void CallFoo(A *a, int (A::*fp)() const)
 //
 // CHECK: [[NUM]] = !{[[TYPE:!.*]], [[TYPE]], i64 0}
 // CHECK: [[TYPE]] = !{!"vtable pointer", !{{.*}}
-// NOTBAA-NOT: = !{!"Simple C/C++ TBAA"}
+// NOTBAA-NOT: = !{!"Simple C++ TBAA"}

Modified: cfe/trunk/test/CodeGen/tbaa.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/tbaa.cpp?rev=260567=260566=260567=diff
==
--- cfe/trunk/test/CodeGen/tbaa.cpp (original)
+++ cfe/trunk/test/CodeGen/tbaa.cpp Thu Feb 11 13:19:18 2016
@@ -237,7 +237,7 @@ uint32_t g15(StructS *S, StructS3 *S3, u
 }
 
 // CHECK: [[TYPE_char:!.*]] = !{!"omnipotent char", [[TAG_cxx_tbaa:!.*]],
-// CHECK: [[TAG_cxx_tbaa]] = !{!"Simple C/C++ TBAA"}
+// CHECK: [[TAG_cxx_tbaa]] = !{!"Simple C++ TBAA"}
 // CHECK: [[TAG_i32]] = !{[[TYPE_i32:!.*]], [[TYPE_i32]], i64 0}
 // CHECK: [[TYPE_i32]] = !{!"int", [[TYPE_char]],
 // CHECK: [[TAG_i16]] = !{[[TYPE_i16:!.*]], [[TYPE_i16]], i64 0}


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

Re: [PATCH] D16946: Add link to llvm git documentation, and recommend always building libcxx on OSX

mclow.lists added a comment.

This looks fine to me.  I think this should be committed.


http://reviews.llvm.org/D16946



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

Re: r252114 - [modules] If we're given a module file, via -fmodule-file=, for a module, but

2016-02-11 Thread Ben Langmuir via cfe-commits

FYI I changed this to early-exit again in r260563 to fix implicit builds.  It’s 
not safe to keep reading if we haven’t told ReadOptionsBlock to expect 
failures, since it will itself early-exit, leaving the stream in the middle of 
a block.  It’s also a performance advantage to early exit when doing implicit 
builds.

Ben

> On Jan 8, 2016, at 2:46 PM, Adrian Prantl via cfe-commits 
>  wrote:
> 
>> 
>> On Jan 8, 2016, at 2:39 PM, Adrian Prantl  wrote:
>> 
>> Hi Richard,
>> 
>> This change 
>>> @@ -2239,16 +2240,21 @@ ASTReader::ReadControlBlock(ModuleFile ,
>> [...]
>>> -  if (!DisableValidation && Result != Success &&
>>> -  (Result != ConfigurationMismatch || 
>>> !AllowConfigurationMismatch))
>>> +  if (DisableValidation ||
>>> +  (AllowConfigurationMismatch && Result == 
>>> ConfigurationMismatch))
>>> +Result = Success;
>>> +
>>> +  // If we've diagnosed a problem, we're done.
>>> +  if (Result != Success &&
>>> +  isDiagnosedResult(Result, ClientLoadCapabilities))
>>>return Result;
>> 
>> either causes or uncovers a bug:
>> 
>>> CC=/Volumes/Data/llvm/_build.ninja.debug/bin/clang # r256948
>>> rm -rf cache && mkdir cache
>>> rm -rf Test && mkdir Test
>>> echo 'module Test {
>>> umbrella header "Test.h"
>>> }' >Test/module.modulemap
>>> touch Test/Test.h
>>> echo '#import '>2.m
>>> 
>>> clang -x objective-c -fmodules -fmodules-cache-path=cache  -DA=0 -I. -c 2.m 
>>> -o 1.o
>>> clang -x objective-c -fmodules -fmodules-cache-path=cache -Werror -DA=0 -I. 
>>> -c 2.m -o 2.o
>>> 
>> 
>> 
>> After encountering a configuration mismatch or out-of-date error, we now 
>> continue instead of returning early and subsequently crash in
>> 
>> ASTReader::ReadControlBlock()
>>   ASTReader::getInputFile()
>> Cursor.JumpToBit(F.InputFileOffsets[ID-1]);
>> 
>> I’ll keep digging deeper, but I thought you may have an intuition of what’s 
>> going on here.
>> Is the behavior change intentional? From the commit message it sounds as if 
>> implicit module builds shouldn’t be affected.
> 
> In my particular crash isDiagnosedResult returns false for an OutOfDate 
> result thus skipping the early return.
> 
> -- adrian
> ___
> 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: Patch for Bug 26283: float.h is missing mandatory C11 fp macros like DBL_DECIMAL_DIG and LDBL_DECIMAL_DIG

2016-02-11 Thread Jorge Teixeira via cfe-commits

Here is a revised test, which I renamed to c11-5_2_4_2_2p11.c instead
of float.c because I am only checking a subset of what the standard
mandates for float.h, and because there were similar precedents, like
test/Preprocessor/c99-*.c. Feel free to override, though.

The first part checks for basic compliance with the referred C11
paragraph, the second for internal consistency between the underscored
and exposed versions of the macros.
No attempt was made to support C99 or C89.

I am not very clear on the proper use of the whole lit.py / RUN
framework, so someone should really confirm if what I wrote is
correct. The goal was to test both hosted and freestanding
implementations with C11, and expect no diagnostics from either.

Thanks for the help,

JT

On Tue, Feb 9, 2016 at 5:56 PM, Richard Smith  wrote:
> On Tue, Feb 9, 2016 at 2:43 PM, Jorge Teixeira
>  wrote:
>> Richard,
>>
>> Can you be more specific?
>>
>> I assume you mean something like my newly attached .h file that tests
>> very basic implementation compliance (i.e., it's required, but not
>> sufficient), but I would need a bit more guidance about the structure
>> of the file, how to perform the tests, and where to exactly place and
>> name the file within test/Headers.
>>
>> I some sort of template exists, or if someone else takes point and
>> makes it, I can "port" the attached p11 test cases. I am unsure of how
>> to perform a more normative compliance - for example, to assert that
>> LDBL_DECIMAL_DIG is 21 on x86-64 and that indeed those many digits are
>> guaranteed to be correct, etc. This is probably not possible / does
>> not make sense.
>
> That looks like a decent basic test for this. The test should be named
> something like test/Headers/float.c, and needs to contain a "RUN:"
> line so that the test runner infrastructure knows how to run it. You
> can look at test/Header/limits.cpp for an example of how this works.
>
> We already have platform-specific tests that __LDBL_DECIMAL_DIG__ is
> the right value, so you could test the values are correct by checking
> that LDBL_DECIMAL_DIG == __LDBL_DECIMAL_DIG__.
>
>> JT
>>
>> On Tue, Feb 9, 2016 at 3:58 PM, Richard Smith  wrote:
>>> Patch looks good. Please also add a testcase to test/Headers.
>>>
>>> On Tue, Feb 9, 2016 at 12:08 PM, Hubert Tong via cfe-commits
>>>  wrote:
 I see no immediate issue with this patch, but I am not one of the usual
 reviewers for this part of the code base.

 -- HT


 On Tue, Feb 9, 2016 at 2:56 PM, Jorge Teixeira 
 wrote:
>
> Thanks Hubert. Somehow I omitted that prefix when typing the macros,
> and I did not noticed it when I was testing because on my arch
> DECIMAL_DIG is defined to be the LDBL version...
>
> Updated patch is attached.
>
> JT
>
> On Tue, Feb 9, 2016 at 1:41 PM, Hubert Tong
>  wrote:
> > There is a __LDBL_DECIMAL_DIG__ predefined macro. __DECIMAL_DIG__ will
> > not
> > always be the same as __LDBL_DECIMAL_DIG__.
> >
> > -- HT
> >
> > On Mon, Feb 8, 2016 at 11:26 PM, Jorge Teixeira via cfe-commits
> >  wrote:
> >>
> >> Hi, I filed the bug (https://llvm.org/bugs/show_bug.cgi?id=26283) some
> >> time ago and nobody picked it up, so here is a trivial patch exposing
> >> the missing macros, that to the best of my ability were already
> >> present as the internal underscored versions.
> >>
> >> Perhaps a more general bug about C11 floating point (lack of)
> >> conformance should be filed, so that some form of unit test/macro
> >> validation could be worked on, but this patch does scratch my current
> >> itch.
> >>
> >> Successfully tested on x86-64 Xubuntu 14.04 with clang 3.8 from the
> >> ppa, patched with the attached diff.
> >>
> >> First contribution, so feel free to suggest improvements or point to
> >> more detailed step-by-step instructions/guidelines.
> >>
> >> Cheers,
> >>
> >> JT
> >>
> >> ___
> >> 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

// RUN: %clang_cc1 -fsyntax-only -verify -std=c11 %s
// RUN: %clang_cc1 -fsyntax-only -verify -std=c11 -ffreestanding %s
// expected-no-diagnostics

/* Basic conformance checks against the N1570 draft of C11 Std. */
/*
5.2.4.2.2p11, pp. 30
*/
#include 
#if ((__STDC_VERSION__ >= 201112L) || !defined(__STRICT_ANSI__))

#ifndef FLT_RADIX
#error "Mandatory macro FLT_RADIX is

Re: [PATCH] D17132: [libcxx] Fix definition of regex_traits::__regex_word on big-endian glibc systems

mclow.lists added a comment.

> ctype_base is defining graph by combining alnum and punct instead of using 
> the _IS* macro like the other bits.


Because that's how the standard (22.4.1) shows to do it :-)

> I'm not sure where it's getting the definition of classic_table. Presumably 
> it's coming from glibc ...


Exactly. The `classic_table` is there for C libraries (like Bionic) that don't 
have their one rune table.


http://reviews.llvm.org/D17132



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

[libcxx] r260570 - Work around regression in glibc 2.22: request that glibc provides the correct

Author: rsmith
Date: Thu Feb 11 13:40:06 2016
New Revision: 260570

URL: http://llvm.org/viewvc/llvm-project?rev=260570=rev
Log:
Work around regression in glibc 2.22: request that glibc provides the correct
prototypes for  functions that are converted into overload sets in
C++. This matches the existing workaround in .

Modified:
libcxx/trunk/include/string.h

Modified: libcxx/trunk/include/string.h
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/string.h?rev=260570=260569=260570=diff
==
--- libcxx/trunk/include/string.h (original)
+++ libcxx/trunk/include/string.h Thu Feb 11 13:40:06 2016
@@ -58,6 +58,10 @@ size_t strlen(const char* s);
 #pragma GCC system_header
 #endif
 
+#ifdef __cplusplus
+#define __CORRECT_ISO_CPP_STRING_H_PROTO
+#endif
+
 #include_next 
 
 // MSVCRT, GNU libc and its derivates already have the correct prototype in


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

Re: [libcxx] r260337 - Fix overload sets of strchr, strpbrk, strrchr, memchr and strstr from

Should be fixed in r260570.

On Thu, Feb 11, 2016 at 11:28 AM, Richard Smith  wrote:
> Argh, the glibc folks broke their string.h and wchar.h prototypes in
> this commit:
>
> https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=8e2e833ac4d6509b152d6b8d74d388725717c56f
>
> On Thu, Feb 11, 2016 at 11:02 AM, Ismail Donmez  wrote:
>> Hi,
>>
>> On Wed, Feb 10, 2016 at 2:59 AM, Richard Smith via cfe-commits
>>  wrote:
>>> Author: rsmith
>>> Date: Tue Feb  9 18:59:02 2016
>>> New Revision: 260337
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=260337=rev
>>> Log:
>>> Fix overload sets of strchr, strpbrk, strrchr, memchr and strstr from
>>>  and wcschr, wcspbrk, wcsrchr, wmemchr, and wcsstr from  
>>> to
>>> provide a const-correct overload set even when the underlying C library does
>>> not.
>>>
>>> This change adds a new macro, _LIBCPP_PREFERRED_OVERLOAD, which (if defined)
>>> specifies that a given overload is a better match than an otherwise equally
>>> good function declaration without the overload. This is implemented in 
>>> modern
>>> versions of Clang via __attribute__((enable_if)), and not elsewhere.
>>>
>>> We use this new macro to define overloads in the global namespace for these
>>> functions that displace the overloads provided by the C library, unless we
>>> believe the C library is already providing the correct signatures.
>>>
>>> Added:
>>> libcxx/trunk/include/string.h
>>>   - copied, changed from r251642, libcxx/trunk/include/string.h
>>> Modified:
>>> libcxx/trunk/include/__config
>>> libcxx/trunk/include/cstring
>>> libcxx/trunk/include/cwchar
>>> libcxx/trunk/include/wchar.h
>>> libcxx/trunk/test/std/depr/depr.c.headers/string_h.pass.cpp
>>> libcxx/trunk/test/std/depr/depr.c.headers/wchar_h.pass.cpp
>>> libcxx/trunk/test/std/strings/c.strings/cstring.pass.cpp
>>> libcxx/trunk/test/std/strings/c.strings/cwchar.pass.cpp
>>
>> Fails on Linux x86-64 with glibc 2.22:
>>
>> /home/abuild/rpmbuild/BUILD/llvm/projects/libcxx/test/std/depr/depr.c.headers/string_h.pass.cpp:55:5:
>> error: static_assert failed ""
>> static_assert((std::is_same> char*>::value), "");
>> ^ 
>> 
>> /home/abuild/rpmbuild/BUILD/llvm/projects/libcxx/test/std/depr/depr.c.headers/string_h.pass.cpp:56:5:
>> error: static_assert failed ""
>> static_assert((std::is_same> char*>::value), "");
>> ^
>> ~~~
>> /home/abuild/rpmbuild/BUILD/llvm/projects/libcxx/test/std/depr/depr.c.headers/string_h.pass.cpp:57:5:
>> error: static_assert failed ""
>> static_assert((std::is_same> char*>::value), "");
>> ^ 
>> ~
>> /home/abuild/rpmbuild/BUILD/llvm/projects/libcxx/test/std/depr/depr.c.headers/string_h.pass.cpp:58:5:
>> error: static_assert failed ""
>> static_assert((std::is_same> char*>::value), "");
>> ^ 
>> ~~
>> /home/abuild/rpmbuild/BUILD/llvm/projects/libcxx/test/std/depr/depr.c.headers/string_h.pass.cpp:59:5:
>> error: static_assert failed ""
>> static_assert((std::is_same> void*>::value), "");
>> ^
>> ~~~
>> 5 errors generated.
>>
>>
>> /home/abuild/rpmbuild/BUILD/llvm/projects/libcxx/test/std/strings/c.strings/cstring.pass.cpp:55:5:
>> error: static_assert failed ""
>> static_assert((std::is_same> const void*>::value), "");
>> ^
>> 
>> /home/abuild/rpmbuild/BUILD/llvm/projects/libcxx/test/std/strings/c.strings/cstring.pass.cpp:56:5:
>> error: static_assert failed ""
>> static_assert((std::is_same> char*>::value), "");
>> ^
>> ~
>> /home/abuild/rpmbuild/BUILD/llvm/projects/libcxx/test/std/strings/c.strings/cstring.pass.cpp:57:5:
>> error: static_assert failed ""
>> static_assert((std::is_same> const char*>::value), "");
>> ^
>> 
>> /home/abuild/rpmbuild/BUILD/llvm/projects/libcxx/test/std/strings/c.strings/cstring.pass.cpp:58:5:
>> error: static_assert failed ""
>> static_assert((std::is_same> char*>::value), "");
>> ^
>> ~~
>> /home/abuild/rpmbuild/BUILD/llvm/projects/libcxx/test/std/strings/c.strings/cstring.pass.cpp:59:5:
>> error:

Re: [PATCH] D17148: [OPENMP] Basic teams directive implementation

2016-02-11 Thread Carlo Bertolli via cfe-commits

carlo.bertolli removed rL LLVM as the repository for this revision.
carlo.bertolli updated this revision to Diff 47695.
carlo.bertolli added a comment.

Remove handling of reductions - not supported by this patch.


http://reviews.llvm.org/D17148

Files:
  lib/CodeGen/CGOpenMPRuntime.cpp
  lib/CodeGen/CGOpenMPRuntime.h
  lib/CodeGen/CGStmtOpenMP.cpp
  test/OpenMP/teams_codegen.cpp

Index: test/OpenMP/teams_codegen.cpp
===
--- test/OpenMP/teams_codegen.cpp
+++ test/OpenMP/teams_codegen.cpp
@@ -208,4 +208,142 @@
 
 }
 #endif // CK3
+
+// Test target codegen - host bc file has to be created first.
+// RUN: %clang_cc1 -DCK4 -verify -fopenmp -x c++ -triple powerpc64le-unknown-unknown -omptargets=powerpc64le-ibm-linux-gnu -emit-llvm-bc %s -o %t-ppc-host.bc
+// RUN: %clang_cc1 -DCK4 -verify -fopenmp -x c++ -triple powerpc64le-unknown-unknown -omptargets=powerpc64le-ibm-linux-gnu -emit-llvm %s -fopenmp-is-device -omp-host-ir-file-path %t-ppc-host.bc -o - | FileCheck %s --check-prefix CK4 --check-prefix CK4-64
+// RUN: %clang_cc1 -DCK4 -fopenmp -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -omptargets=powerpc64le-ibm-linux-gnu -emit-pch -fopenmp-is-device -omp-host-ir-file-path %t-ppc-host.bc -o %t %s
+// RUN: %clang_cc1 -DCK4 -fopenmp -x c++ -triple powerpc64le-unknown-unknown -omptargets=powerpc64le-ibm-linux-gnu -std=c++11 -fopenmp-is-device -omp-host-ir-file-path %t-ppc-host.bc -include-pch %t -verify %s -emit-llvm -o - | FileCheck %s --check-prefix CK4 --check-prefix CK4-64
+// RUN: %clang_cc1 -DCK4 -verify -fopenmp -x c++ -triple i386-unknown-unknown -omptargets=i386-pc-linux-gnu -emit-llvm-bc %s -o %t-x86-host.bc
+// RUN: %clang_cc1 -DCK4 -verify -fopenmp -x c++ -triple i386-unknown-unknown -omptargets=i386-pc-linux-gnu -emit-llvm %s -fopenmp-is-device -omp-host-ir-file-path %t-x86-host.bc -o - | FileCheck %s --check-prefix CK4 --check-prefix CK4-32
+// RUN: %clang_cc1 -DCK4 -fopenmp -x c++ -std=c++11 -triple i386-unknown-unknown -omptargets=i386-pc-linux-gnu -emit-pch -fopenmp-is-device -omp-host-ir-file-path %t-x86-host.bc -o %t %s
+// RUN: %clang_cc1 -DCK4 -fopenmp -x c++ -triple i386-unknown-unknown -omptargets=i386-pc-linux-gnu -std=c++11 -fopenmp-is-device -omp-host-ir-file-path %t-x86-host.bc -include-pch %t -verify %s -emit-llvm -o - | FileCheck %s --check-prefix CK4 --check-prefix CK4-32
+
+#ifdef CK4
+
+// CK4-DAG: %ident_t = type { i32, i32, i32, i32, i8* }
+// CK4-DAG: [[STR:@.+]] = private unnamed_addr constant [23 x i8] c";unknown;unknown;0;0;;\00"
+// CK4-DAG: [[DEF_LOC_0:@.+]] = private unnamed_addr constant %ident_t { i32 0, i32 2, i32 0, i32 0, i8* getelementptr inbounds ([23 x i8], [23 x i8]* [[STR]], i32 0, i32 0) }
+// CK4-DEBUG-DAG: [[LOC1:@.+]] = private unnamed_addr constant [{{.+}} x i8] c";{{.*}}teams_codegen.cpp;main;[[@LINE+14]];9;;\00"
+// CK4-DEBUG-DAG: [[LOC2:@.+]] = private unnamed_addr constant [{{.+}} x i8] c";{{.*}}teams_codegen.cpp;tmain;[[@LINE+7]];9;;\00"
+
+template 
+int tmain(T argc) {
+#pragma omp target
+#pragma omp teams
+  argc = 0;
+  return 0;
+}
+
+int main (int argc, char **argv) {
+#pragma omp target
+#pragma omp teams
+  argc = 0;
+  return tmain(argv);
+}
+
+// CK4:  define {{.*}}void @{{[^,]+}}(i{{.+}} %[[ARGC:.+]])
+// CK4:  [[ARGCADDR:%.+]] = alloca i{{.+}}
+// CK4:  store i{{.+}} %[[ARGC]], i{{.+}}* [[ARGCADDR]]
+// CK4-64:  [[CONV:%.+]] = bitcast i64* [[ARGCADDR]] to i32*
+// CK4-64:  call {{.*}}void (%ident_t*, i32, void (i32*, i32*, ...)*, ...) @__kmpc_fork_teams(%ident_t* [[DEF_LOC_0]], i32 1, void (i32*, i32*, ...)* bitcast (void (i32*, i32*, i32*)* {{.+}} to void (i32*, i32*, ...)*), i32* [[CONV]])
+// CK4-32:  call {{.*}}void (%ident_t*, i32, void (i32*, i32*, ...)*, ...) @__kmpc_fork_teams(%ident_t* [[DEF_LOC_0]], i32 1, void (i32*, i32*, ...)* bitcast (void (i32*, i32*, i32*)* {{.+}} to void (i32*, i32*, ...)*), i32* [[ARGCADDR]])
+// CK4:  ret void
+// CK4-NEXT: }
+
+// CK4:  define {{.*}}void @{{[^,]+}}(i8*** dereferenceable({{.}}) [[ARGC1:%.+]])
+// CK4:  [[ARGCADDR1:%.+]] = alloca i8***
+// CK4:  store i8*** [[ARGC1]], i8 [[ARGCADDR1]]
+// CK4:  [[CONV1:%.+]] = load i8***, i8 [[ARGCADDR1]]
+// CK4:  call {{.*}}void (%ident_t*, i32, void (i32*, i32*, ...)*, ...) @__kmpc_fork_teams(%ident_t* [[DEF_LOC_0]], i32 1, void (i32*, i32*, ...)* bitcast (void (i32*, i32*, i8***)* {{.+}} to void (i32*, i32*, ...)*), i8*** [[CONV1]])
+
+
+#endif // CK4
+
+// Test target codegen - host bc file has to be created first.
+// RUN: %clang_cc1 -DCK5 -verify -fopenmp -x c++ -triple powerpc64le-unknown-unknown -omptargets=powerpc64le-ibm-linux-gnu -emit-llvm-bc %s -o %t-ppc-host.bc
+// RUN: %clang_cc1 -DCK5 -verify -fopenmp -x c++ -triple powerpc64le-unknown-unknown -omptargets=powerpc64le-ibm-linux-gnu -emit-llvm %s -fopenmp-is-device -omp-host-ir-file-path %t-ppc-host.bc -o - | FileCheck %s --check-prefix CK5 --check-prefix CK5-64
+// RUN: %clang_cc1 -DCK5 -fopenmp -x c++

r260563 - [Modules] Early-exit if ReadOptionsBlock fails to avoid crashing

2016-02-11 Thread Ben Langmuir via cfe-commits

Author: benlangmuir
Date: Thu Feb 11 12:54:02 2016
New Revision: 260563

URL: http://llvm.org/viewvc/llvm-project?rev=260563=rev
Log:
[Modules] Early-exit if ReadOptionsBlock fails to avoid crashing

If we didn't tell ReadOptionsBlock to allow failures then we can't
assume that the stream is not in the middle of a block if it returns
out-of-date. This was causing a crash when we tried to continue reading.

Also, it's just generally a good idea to early-exit if we're doing
implicit module builds, since we will want to immediately rebuild this
module anyway and there's no reason to waste time continuing after
failure.

rdar://problem/24114938

Added:
cfe/trunk/test/Modules/implicit-build-config-out-of-date.m
Modified:
cfe/trunk/lib/Serialization/ASTReader.cpp

Modified: cfe/trunk/lib/Serialization/ASTReader.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Serialization/ASTReader.cpp?rev=260563=260562=260563=diff
==
--- cfe/trunk/lib/Serialization/ASTReader.cpp (original)
+++ cfe/trunk/lib/Serialization/ASTReader.cpp Thu Feb 11 12:54:02 2016
@@ -2269,9 +2269,10 @@ ASTReader::ReadControlBlock(ModuleFile &
   (AllowConfigurationMismatch && Result == ConfigurationMismatch))
 Result = Success;
 
-  // If we've diagnosed a problem, we're done.
-  if (Result != Success &&
-  isDiagnosedResult(Result, ClientLoadCapabilities))
+  // If we can't load the module, exit early since we likely
+  // will rebuild the module anyway. The stream may be in the
+  // middle of a block.
+  if (Result != Success)
 return Result;
 } else if (Stream.SkipBlock()) {
   Error("malformed block record in AST file");

Added: cfe/trunk/test/Modules/implicit-build-config-out-of-date.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/implicit-build-config-out-of-date.m?rev=260563=auto
==
--- cfe/trunk/test/Modules/implicit-build-config-out-of-date.m (added)
+++ cfe/trunk/test/Modules/implicit-build-config-out-of-date.m Thu Feb 11 
12:54:02 2016
@@ -0,0 +1,6 @@
+// RUN: rm -rf %t
+// Use -DA=0 so that there is at least one preprocessor option serialized 
after the diagnostic options.
+// RUN: %clang_cc1 -fmodules -fmodules-cache-path=%t -fimplicit-module-maps -I 
%S/Inputs %s -DA=0 -Rmodule-build -verify
+// RUN: %clang_cc1 -fmodules -fmodules-cache-path=%t -fimplicit-module-maps -I 
%S/Inputs %s -DA=0 -Werror -Rmodule-build -verify
+
+@import category_top; // expected-remark {{building module}} expected-remark 
{{finished building}}


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

Re: [PATCH] D17146: [libcxx] locale portability refactor

mclow.lists added a comment.

I am very much in favor of cleaning up this part of libc++. 
Thanks for taking this on.

> I'm open to recommendations on ways to test this that are better than 
> "Submit, watch build bots, revert as necessary".


My suggestion is to do this incrementally.
Implement the infrastructure bits, then move (say) Linux over to use the new 
bits.
Then (say) Mac OS X. Then FreeBSD. Then IBM. Then Windows.
Repeat until everyone's moved over; watching the testbots (and getting the 
people who committed support for each of these systems involved).
Then, when they're all moved, delete the old stuff.


http://reviews.llvm.org/D17146



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

Re: Patch for Bug 26283: float.h is missing mandatory C11 fp macros like DBL_DECIMAL_DIG and LDBL_DECIMAL_DIG

Thanks, I modified the test to also test C89 and C99 modes and
committed this as r260577.

On Thu, Feb 11, 2016 at 11:29 AM, Jorge Teixeira
 wrote:
> Here is a revised test, which I renamed to c11-5_2_4_2_2p11.c instead
> of float.c because I am only checking a subset of what the standard
> mandates for float.h, and because there were similar precedents, like
> test/Preprocessor/c99-*.c. Feel free to override, though.

test/Preprocessor/c99-* are an aberration. The goal would be that this
test grows to cover all of the parts of float.h that we define, so
float.c seems like the appropriate name for it.

> The first part checks for basic compliance with the referred C11
> paragraph, the second for internal consistency between the underscored
> and exposed versions of the macros.
> No attempt was made to support C99 or C89.
>
> I am not very clear on the proper use of the whole lit.py / RUN
> framework, so someone should really confirm if what I wrote is
> correct. The goal was to test both hosted and freestanding
> implementations with C11, and expect no diagnostics from either.

We generally avoid testing hosted mode, because we don't want the
success of our tests to depend on the libc installed on the host
system.

> Thanks for the help,
>
> JT
>
> On Tue, Feb 9, 2016 at 5:56 PM, Richard Smith  wrote:
>> On Tue, Feb 9, 2016 at 2:43 PM, Jorge Teixeira
>>  wrote:
>>> Richard,
>>>
>>> Can you be more specific?
>>>
>>> I assume you mean something like my newly attached .h file that tests
>>> very basic implementation compliance (i.e., it's required, but not
>>> sufficient), but I would need a bit more guidance about the structure
>>> of the file, how to perform the tests, and where to exactly place and
>>> name the file within test/Headers.
>>>
>>> I some sort of template exists, or if someone else takes point and
>>> makes it, I can "port" the attached p11 test cases. I am unsure of how
>>> to perform a more normative compliance - for example, to assert that
>>> LDBL_DECIMAL_DIG is 21 on x86-64 and that indeed those many digits are
>>> guaranteed to be correct, etc. This is probably not possible / does
>>> not make sense.
>>
>> That looks like a decent basic test for this. The test should be named
>> something like test/Headers/float.c, and needs to contain a "RUN:"
>> line so that the test runner infrastructure knows how to run it. You
>> can look at test/Header/limits.cpp for an example of how this works.
>>
>> We already have platform-specific tests that __LDBL_DECIMAL_DIG__ is
>> the right value, so you could test the values are correct by checking
>> that LDBL_DECIMAL_DIG == __LDBL_DECIMAL_DIG__.
>>
>>> JT
>>>
>>> On Tue, Feb 9, 2016 at 3:58 PM, Richard Smith  wrote:
 Patch looks good. Please also add a testcase to test/Headers.

 On Tue, Feb 9, 2016 at 12:08 PM, Hubert Tong via cfe-commits
  wrote:
> I see no immediate issue with this patch, but I am not one of the usual
> reviewers for this part of the code base.
>
> -- HT
>
>
> On Tue, Feb 9, 2016 at 2:56 PM, Jorge Teixeira 
> 
> wrote:
>>
>> Thanks Hubert. Somehow I omitted that prefix when typing the macros,
>> and I did not noticed it when I was testing because on my arch
>> DECIMAL_DIG is defined to be the LDBL version...
>>
>> Updated patch is attached.
>>
>> JT
>>
>> On Tue, Feb 9, 2016 at 1:41 PM, Hubert Tong
>>  wrote:
>> > There is a __LDBL_DECIMAL_DIG__ predefined macro. __DECIMAL_DIG__ will
>> > not
>> > always be the same as __LDBL_DECIMAL_DIG__.
>> >
>> > -- HT
>> >
>> > On Mon, Feb 8, 2016 at 11:26 PM, Jorge Teixeira via cfe-commits
>> >  wrote:
>> >>
>> >> Hi, I filed the bug (https://llvm.org/bugs/show_bug.cgi?id=26283) some
>> >> time ago and nobody picked it up, so here is a trivial patch exposing
>> >> the missing macros, that to the best of my ability were already
>> >> present as the internal underscored versions.
>> >>
>> >> Perhaps a more general bug about C11 floating point (lack of)
>> >> conformance should be filed, so that some form of unit test/macro
>> >> validation could be worked on, but this patch does scratch my current
>> >> itch.
>> >>
>> >> Successfully tested on x86-64 Xubuntu 14.04 with clang 3.8 from the
>> >> ppa, patched with the attached diff.
>> >>
>> >> First contribution, so feel free to suggest improvements or point to
>> >> more detailed step-by-step instructions/guidelines.
>> >>
>> >> Cheers,
>> >>
>> >> JT
>> >>
>> >> ___
>> >> cfe-commits mailing list
>> >> cfe-commits@lists.llvm.org
>> >>

Re: r252114 - [modules] If we're given a module file, via -fmodule-file=, for a module, but

On Thu, Feb 11, 2016 at 11:04 AM, Ben Langmuir  wrote:
> FYI I changed this to early-exit again in r260563 to fix implicit builds.
> It’s not safe to keep reading if we haven’t told ReadOptionsBlock to expect
> failures, since it will itself early-exit, leaving the stream in the middle
> of a block.  It’s also a performance advantage to early exit when doing
> implicit builds.

Thank you.

> Ben
>
> On Jan 8, 2016, at 2:46 PM, Adrian Prantl via cfe-commits
>  wrote:
>
>
> On Jan 8, 2016, at 2:39 PM, Adrian Prantl  wrote:
>
> Hi Richard,
>
> This change
>
> @@ -2239,16 +2240,21 @@ ASTReader::ReadControlBlock(ModuleFile ,
>
> [...]
>
> -  if (!DisableValidation && Result != Success &&
> -  (Result != ConfigurationMismatch ||
> !AllowConfigurationMismatch))
> +  if (DisableValidation ||
> +  (AllowConfigurationMismatch && Result ==
> ConfigurationMismatch))
> +Result = Success;
> +
> +  // If we've diagnosed a problem, we're done.
> +  if (Result != Success &&
> +  isDiagnosedResult(Result, ClientLoadCapabilities))
>return Result;
>
>
> either causes or uncovers a bug:
>
> CC=/Volumes/Data/llvm/_build.ninja.debug/bin/clang # r256948
> rm -rf cache && mkdir cache
> rm -rf Test && mkdir Test
> echo 'module Test {
> umbrella header "Test.h"
> }' >Test/module.modulemap
> touch Test/Test.h
> echo '#import '>2.m
>
> clang -x objective-c -fmodules -fmodules-cache-path=cache  -DA=0 -I. -c 2.m
> -o 1.o
> clang -x objective-c -fmodules -fmodules-cache-path=cache -Werror -DA=0 -I.
> -c 2.m -o 2.o
>
>
>
> After encountering a configuration mismatch or out-of-date error, we now
> continue instead of returning early and subsequently crash in
>
> ASTReader::ReadControlBlock()
>   ASTReader::getInputFile()
> Cursor.JumpToBit(F.InputFileOffsets[ID-1]);
>
> I’ll keep digging deeper, but I thought you may have an intuition of what’s
> going on here.
> Is the behavior change intentional? From the commit message it sounds as if
> implicit module builds shouldn’t be affected.
>
>
> In my particular crash isDiagnosedResult returns false for an OutOfDate
> result thus skipping the early return.
>
> -- adrian
> ___
> 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: [PATCH] D17069: [clang-tidy] Fix an assert failure in 'readability-braces-around-statements' check.

2016-02-11 Thread Haojian Wu via cfe-commits

hokein updated this revision to Diff 47609.
hokein added a comment.

Address review comment.


http://reviews.llvm.org/D17069

Files:
  clang-tidy/readability/BracesAroundStatementsCheck.cpp
  test/clang-tidy/readability-braces-around-statements-assert-failure.cpp

Index: test/clang-tidy/readability-braces-around-statements-assert-failure.cpp
===
--- /dev/null
+++ test/clang-tidy/readability-braces-around-statements-assert-failure.cpp
@@ -0,0 +1,7 @@
+// RUN: %check_clang_tidy %s readability-braces-around-statements %t
+
+int test_failure() {
+  if (std::rand()) {
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: error: use of undeclared identifier 'std'
+  }
+}
Index: clang-tidy/readability/BracesAroundStatementsCheck.cpp
===
--- clang-tidy/readability/BracesAroundStatementsCheck.cpp
+++ clang-tidy/readability/BracesAroundStatementsCheck.cpp
@@ -180,7 +180,10 @@
   if (const DeclStmt *CondVar = S->getConditionVariableDeclStmt())
 CondEndLoc = CondVar->getLocEnd();
 
-  assert(CondEndLoc.isValid());
+  if (!CondEndLoc.isValid()) {
+return SourceLocation();
+  }
+
   SourceLocation PastCondEndLoc =
   Lexer::getLocForEndOfToken(CondEndLoc, 0, SM, Context->getLangOpts());
   if (PastCondEndLoc.isInvalid())


Index: test/clang-tidy/readability-braces-around-statements-assert-failure.cpp
===
--- /dev/null
+++ test/clang-tidy/readability-braces-around-statements-assert-failure.cpp
@@ -0,0 +1,7 @@
+// RUN: %check_clang_tidy %s readability-braces-around-statements %t
+
+int test_failure() {
+  if (std::rand()) {
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: error: use of undeclared identifier 'std'
+  }
+}
Index: clang-tidy/readability/BracesAroundStatementsCheck.cpp
===
--- clang-tidy/readability/BracesAroundStatementsCheck.cpp
+++ clang-tidy/readability/BracesAroundStatementsCheck.cpp
@@ -180,7 +180,10 @@
   if (const DeclStmt *CondVar = S->getConditionVariableDeclStmt())
 CondEndLoc = CondVar->getLocEnd();
 
-  assert(CondEndLoc.isValid());
+  if (!CondEndLoc.isValid()) {
+return SourceLocation();
+  }
+
   SourceLocation PastCondEndLoc =
   Lexer::getLocForEndOfToken(CondEndLoc, 0, SM, Context->getLangOpts());
   if (PastCondEndLoc.isInvalid())
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r260510 - [MCU] Fix assertion failure on function returning empty union.

2016-02-11 Thread Denis Zobnin via cfe-commits

Author: dzobnin
Date: Thu Feb 11 05:26:03 2016
New Revision: 260510

URL: http://llvm.org/viewvc/llvm-project?rev=260510=rev
Log:
[MCU] Fix assertion failure on function returning empty union.

Treat empty struct/union in return type as void for MCU ABI. PR26438.

Differential Revision: http://reviews.llvm.org/D16808

Added:
cfe/trunk/test/CodeGen/mcu-struct-return.c
Modified:
cfe/trunk/lib/CodeGen/TargetInfo.cpp

Modified: cfe/trunk/lib/CodeGen/TargetInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/TargetInfo.cpp?rev=260510=260509=260510=diff
==
--- cfe/trunk/lib/CodeGen/TargetInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/TargetInfo.cpp Thu Feb 11 05:26:03 2016
@@ -364,7 +364,7 @@ static bool isEmptyField(ASTContext 
 static bool isEmptyRecord(ASTContext , QualType T, bool AllowArrays) {
   const RecordType *RT = T->getAs();
   if (!RT)
-return 0;
+return false;
   const RecordDecl *RD = RT->getDecl();
   if (RD->hasFlexibleArrayMember())
 return false;
@@ -1119,6 +1119,10 @@ ABIArgInfo X86_32ABIInfo::classifyReturn
 if (!IsRetSmallStructInRegABI && !RetTy->isAnyComplexType())
   return getIndirectReturnResult(RetTy, State);
 
+// Ignore empty structs/unions.
+if (isEmptyRecord(getContext(), RetTy, true))
+  return ABIArgInfo::getIgnore();
+
 // Small structures which are register sized are generally returned
 // in a register.
 if (shouldReturnTypeInRegister(RetTy, getContext())) {

Added: cfe/trunk/test/CodeGen/mcu-struct-return.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/mcu-struct-return.c?rev=260510=auto
==
--- cfe/trunk/test/CodeGen/mcu-struct-return.c (added)
+++ cfe/trunk/test/CodeGen/mcu-struct-return.c Thu Feb 11 05:26:03 2016
@@ -0,0 +1,70 @@
+// RUN: %clang_cc1 -triple i386-pc-elfiamcu -emit-llvm %s -o - | FileCheck %s
+
+// Structure that is more than 8 byte.
+struct Big {
+  double a[10];
+};
+
+// Empty union with zero size must be returned as void.
+union U1 {
+} u1;
+
+// Too large union (80 bytes) must be returned via memory.
+union U2 {
+  struct Big b;
+} u2;
+
+// Must be returned in register.
+union U3 {
+  int x;
+} u3;
+
+// Empty struct with zero size, must be returned as void.
+struct S1 {
+} s1;
+
+// Must be returend in register.
+struct S2 {
+  int x;
+} s2;
+
+// CHECK: [[UNION1_TYPE:%.+]] = type {}
+// CHECK: [[UNION2_TYPE:%.+]] = type { [[STRUCT_TYPE:%.+]] }
+// CHECK: [[STRUCT_TYPE]] = type { [10 x double] }
+// CHECK: [[UNION3_TYPE:%.+]] = type { i32 }
+// CHECK: [[STRUCT1_TYPE:%.+]] = type {}
+// CHECK: [[STRUCT2_TYPE:%.+]] = type { i32 }
+
+union U1 foo1() { return u1; }
+union U2 foo2() { return u2; }
+union U3 foo3() { return u3; }
+struct S1 bar1() { return s1; }
+struct S2 bar2() { return s2; }
+struct S1 bar3(union U1 u) { return s1; }
+// CHECK: define void @foo1()
+// CHECK: define void @foo2([[UNION2_TYPE]]* noalias sret %{{.+}})
+// CHECK: define i32 @foo3()
+// CHECK: define void @bar1()
+// CHECK: define i32 @bar2()
+// CHECK: define void @bar3()
+
+void run() {
+  union U1 x1 = foo1();
+  union U2 x2 = foo2();
+  union U3 x3 = foo3();
+  struct S1 y1 = bar1();
+  struct S2 y2 = bar2();
+  struct S1 y3 = bar3(x1);
+
+  // CHECK: [[X1:%.+]] = alloca [[UNION1_TYPE]]
+  // CHECK: [[X2:%.+]] = alloca [[UNION2_TYPE]]
+  // CHECK: [[X3:%.+]] = alloca [[UNION3_TYPE]]
+  // CHECK: [[Y1:%.+]] = alloca [[STRUCT1_TYPE]]
+  // CHECK: [[Y2:%.+]] = alloca [[STRUCT2_TYPE]]
+  // CHECK: call void @foo1()
+  // CHECK: call void @foo2([[UNION2_TYPE]]* sret [[X2]])
+  // CHECK: {{.+}} = call i32 @foo3()
+  // CHECK: call void @bar1()
+  // CHECK: {{.+}} = call i32 @bar2()
+  // CHECK: call void @bar3()
+}


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

Re: [PATCH] D16808: [MCU] PR26438: Fix assertion failure on function returning an empty struct or union

2016-02-11 Thread Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL260510: [MCU] Fix assertion failure on function returning 
empty union. (authored by dzobnin).

Changed prior to commit:
  http://reviews.llvm.org/D16808?vs=47333=47624#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D16808

Files:
  cfe/trunk/lib/CodeGen/TargetInfo.cpp
  cfe/trunk/test/CodeGen/mcu-struct-return.c

Index: cfe/trunk/test/CodeGen/mcu-struct-return.c
===
--- cfe/trunk/test/CodeGen/mcu-struct-return.c
+++ cfe/trunk/test/CodeGen/mcu-struct-return.c
@@ -0,0 +1,70 @@
+// RUN: %clang_cc1 -triple i386-pc-elfiamcu -emit-llvm %s -o - | FileCheck %s
+
+// Structure that is more than 8 byte.
+struct Big {
+  double a[10];
+};
+
+// Empty union with zero size must be returned as void.
+union U1 {
+} u1;
+
+// Too large union (80 bytes) must be returned via memory.
+union U2 {
+  struct Big b;
+} u2;
+
+// Must be returned in register.
+union U3 {
+  int x;
+} u3;
+
+// Empty struct with zero size, must be returned as void.
+struct S1 {
+} s1;
+
+// Must be returend in register.
+struct S2 {
+  int x;
+} s2;
+
+// CHECK: [[UNION1_TYPE:%.+]] = type {}
+// CHECK: [[UNION2_TYPE:%.+]] = type { [[STRUCT_TYPE:%.+]] }
+// CHECK: [[STRUCT_TYPE]] = type { [10 x double] }
+// CHECK: [[UNION3_TYPE:%.+]] = type { i32 }
+// CHECK: [[STRUCT1_TYPE:%.+]] = type {}
+// CHECK: [[STRUCT2_TYPE:%.+]] = type { i32 }
+
+union U1 foo1() { return u1; }
+union U2 foo2() { return u2; }
+union U3 foo3() { return u3; }
+struct S1 bar1() { return s1; }
+struct S2 bar2() { return s2; }
+struct S1 bar3(union U1 u) { return s1; }
+// CHECK: define void @foo1()
+// CHECK: define void @foo2([[UNION2_TYPE]]* noalias sret %{{.+}})
+// CHECK: define i32 @foo3()
+// CHECK: define void @bar1()
+// CHECK: define i32 @bar2()
+// CHECK: define void @bar3()
+
+void run() {
+  union U1 x1 = foo1();
+  union U2 x2 = foo2();
+  union U3 x3 = foo3();
+  struct S1 y1 = bar1();
+  struct S2 y2 = bar2();
+  struct S1 y3 = bar3(x1);
+
+  // CHECK: [[X1:%.+]] = alloca [[UNION1_TYPE]]
+  // CHECK: [[X2:%.+]] = alloca [[UNION2_TYPE]]
+  // CHECK: [[X3:%.+]] = alloca [[UNION3_TYPE]]
+  // CHECK: [[Y1:%.+]] = alloca [[STRUCT1_TYPE]]
+  // CHECK: [[Y2:%.+]] = alloca [[STRUCT2_TYPE]]
+  // CHECK: call void @foo1()
+  // CHECK: call void @foo2([[UNION2_TYPE]]* sret [[X2]])
+  // CHECK: {{.+}} = call i32 @foo3()
+  // CHECK: call void @bar1()
+  // CHECK: {{.+}} = call i32 @bar2()
+  // CHECK: call void @bar3()
+}
Index: cfe/trunk/lib/CodeGen/TargetInfo.cpp
===
--- cfe/trunk/lib/CodeGen/TargetInfo.cpp
+++ cfe/trunk/lib/CodeGen/TargetInfo.cpp
@@ -364,7 +364,7 @@
 static bool isEmptyRecord(ASTContext , QualType T, bool AllowArrays) {
   const RecordType *RT = T->getAs();
   if (!RT)
-return 0;
+return false;
   const RecordDecl *RD = RT->getDecl();
   if (RD->hasFlexibleArrayMember())
 return false;
@@ -1119,6 +1119,10 @@
 if (!IsRetSmallStructInRegABI && !RetTy->isAnyComplexType())
   return getIndirectReturnResult(RetTy, State);
 
+// Ignore empty structs/unions.
+if (isEmptyRecord(getContext(), RetTy, true))
+  return ABIArgInfo::getIgnore();
+
 // Small structures which are register sized are generally returned
 // in a register.
 if (shouldReturnTypeInRegister(RetTy, getContext())) {


Index: cfe/trunk/test/CodeGen/mcu-struct-return.c
===
--- cfe/trunk/test/CodeGen/mcu-struct-return.c
+++ cfe/trunk/test/CodeGen/mcu-struct-return.c
@@ -0,0 +1,70 @@
+// RUN: %clang_cc1 -triple i386-pc-elfiamcu -emit-llvm %s -o - | FileCheck %s
+
+// Structure that is more than 8 byte.
+struct Big {
+  double a[10];
+};
+
+// Empty union with zero size must be returned as void.
+union U1 {
+} u1;
+
+// Too large union (80 bytes) must be returned via memory.
+union U2 {
+  struct Big b;
+} u2;
+
+// Must be returned in register.
+union U3 {
+  int x;
+} u3;
+
+// Empty struct with zero size, must be returned as void.
+struct S1 {
+} s1;
+
+// Must be returend in register.
+struct S2 {
+  int x;
+} s2;
+
+// CHECK: [[UNION1_TYPE:%.+]] = type {}
+// CHECK: [[UNION2_TYPE:%.+]] = type { [[STRUCT_TYPE:%.+]] }
+// CHECK: [[STRUCT_TYPE]] = type { [10 x double] }
+// CHECK: [[UNION3_TYPE:%.+]] = type { i32 }
+// CHECK: [[STRUCT1_TYPE:%.+]] = type {}
+// CHECK: [[STRUCT2_TYPE:%.+]] = type { i32 }
+
+union U1 foo1() { return u1; }
+union U2 foo2() { return u2; }
+union U3 foo3() { return u3; }
+struct S1 bar1() { return s1; }
+struct S2 bar2() { return s2; }
+struct S1 bar3(union U1 u) { return s1; }
+// CHECK: define void @foo1()
+// CHECK: define void @foo2([[UNION2_TYPE]]* noalias sret %{{.+}})
+// CHECK: define i32 @foo3()
+// CHECK: define void @bar1()
+// CHECK: define i32 @bar2()
+// CHECK: define void @bar3()
+
+void run() {
+  union U1 x1 = foo1();
+

[PATCH] D17132: [libcxx] Fix definition of regex_traits::__regex_word on big-endian glibc systems

dsanders created this revision.
dsanders added reviewers: mclow.lists, hans.
dsanders added a subscriber: cfe-commits.

On glibc, the bits used for the various character classes is endian dependant
(see _ISbit() in ctypes.h) but __regex_word does not account for this and uses
a spare bit that isn't spare on big-endian. On big-endian, it overlaps with the
bit for graphic characters which causes '-', '@', etc. to be considered a word
character.

Fixed this by defining the value using _ISbit(15) on glibc systems.

Fixes PR26476.

http://reviews.llvm.org/D17132

Files:
  include/regex

Index: include/regex
===
--- include/regex
+++ include/regex
@@ -976,7 +976,12 @@
 typedef locale  locale_type;
 typedef ctype_base::maskchar_class_type;
 
+#if defined(__GLIBC__)
+static const char_class_type __regex_word = 
static_cast(_ISbit(15));
+#else
 static const char_class_type __regex_word = 0x80;
+#endif
+
 private:
 locale __loc_;
 const ctype* __ct_;


Index: include/regex
===
--- include/regex
+++ include/regex
@@ -976,7 +976,12 @@
 typedef locale  locale_type;
 typedef ctype_base::maskchar_class_type;
 
+#if defined(__GLIBC__)
+static const char_class_type __regex_word = static_cast(_ISbit(15));
+#else
 static const char_class_type __regex_word = 0x80;
+#endif
+
 private:
 locale __loc_;
 const ctype* __ct_;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D16851: Update of "GCC extensions not implemented yet" in Clang User's Manual

2016-02-11 Thread Andrey Bokhanko via cfe-commits

andreybokhanko added a comment.

In http://reviews.llvm.org/D16851#349537, @silvas wrote:

> Assuming the features are implemented this seems fine. LGTM.


Thank you!



Comment at: docs/UsersManual.rst:1698
@@ -1697,3 @@
--  clang does not support #pragma weak (`bug
-   3679 `_). Due to the uses
-   described in the bug, this is likely to be implemented at some point,

silvas wrote:
> Should we close that bug then?
As often happens, this bug started as a general feature request ("pragma weak 
doesn't work at all"), but the last few messages just report a specific defect 
in a specific case and keep the PR open.

I will ask one of our (Intel) engineers to take a look and either close the PR 
if the bug is already fixed or fix it otherwise.

Andrey



http://reviews.llvm.org/D16851



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

Re: [PATCH] D16949: Fix for: Bug 5941 - improve diagnostic for * vs & confusion

2016-02-11 Thread Ryan Yee via cfe-commits

ryee88 added a comment.

Ping-- can someone look at this review?


http://reviews.llvm.org/D16949



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

Re: [PATCH] D15998: Implement attribute((gc_leaf_function)).

2016-02-11 Thread Sanjoy Das via cfe-commits

sanjoy resigned from this revision.
sanjoy removed a reviewer: sanjoy.
sanjoy added a comment.

Resigning for now to make my "Revisions Waiting on You" queue less noisy.  
Please don't hesitate to add me back if this or a variant of this change 
becomes active.


http://reviews.llvm.org/D15998



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

Re: Linux-abi group

2016-02-11 Thread Suprateeka R Hegde via cfe-commits

H.J,

I think we are fragmenting with too many standards and mailing lists.
This new discussion group and eventually the resulting standards, all
might be put under LSB http://refspecs.linuxfoundation.org/lsb.shtml

The Intro on LSB says:
http://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/elfintro.html

And thats what this proposal is intended for.

And we can use the LSB mailing list
https://lists.linux-foundation.org/mailman/listinfo/lsb-discuss for all
discussions.

What do you think?

--
Supra

On 09-Feb-2016 08:46 AM, H.J. Lu via llvm-commits wrote:

On Mon, Feb 8, 2016 at 3:08 PM, Joseph Myers wrote:

On Mon, 8 Feb 2016, H.J. Lu wrote:

I was referring to program properties:

https://groups.google.com/forum/#!topic/generic-abi/fyIXttIsYc8

This looks more like an ELF topic to me, not really ABI.

Please discuss this on a GNU project list because it affects the
entire GNU project.

gABI is ELF and affects all users, including GNU project, of gABI.
Linux-abi discusses Linux-specific extensions to gABI. It is for tools
like compilers, assembler, linker and run-time. It isn't appropriate
for any GNU project list.

I find it extremely unlikely that many well-thought-out extensions would
be appropriate for GNU systems using the Linux kernel but not for GNU
systems using Hurd or other kernels - the only such cases would be for
things very closely related to kernel functionality. There is a strong
presumption that toolchain configuration should apply to all GNU systems
rather than being specific to GNU/Linux without good reason.

Most of extensions aren't Linux kernel specific. But some extensions
will require kernel support to function properly.

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

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

On Thu, Feb 11, 2016 at 4:40 AM, Matthijs van Duin
 wrote:
> On 11 February 2016 at 11:53, H.J. Lu  wrote:
>> Since this isn't Plain Old Data (POD) for the purposes of layout, it
>> isn't covered by my proposal for psABI.  I leave this to C++ ABI.
>
> You never define "POD for the purposes of layout", and I can only
> interpret it as being equivalent to "standard-layout". The property of
> being trivially copyable/destructible is not a statement about layout
> and my EmptyInt example is POD in every other aspect.

"POD for the purpose of layout" is defined in the Itanium C++ ABI here:

http://mentorembedded.github.io/cxx-abi/abi.html#definitions


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

Re: [PATCH] D16965: Fix for Bug 14644 - clang confuses scope operator for global namespace giving extra qualification on member

2016-02-11 Thread Ryan Yee via cfe-commits

ryee88 added a comment.

Ping-- I think this review got missed.


http://reviews.llvm.org/D16965



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

Re: [PATCH] D16792: unordered_map: Use __hash_table::__emplace_unique(), NFC

EricWF added a comment.

All of the prep work has landed. This patch is no longer needed though.


http://reviews.llvm.org/D16792



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

Re: [PATCH] D14203: [analyzer] Improve pointer arithmetic checker.

2016-02-11 Thread Gábor Horváth via cfe-commits

xazax.hun added a comment.

Ping.


http://reviews.llvm.org/D14203



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

[libcxx] r260513 - Teach __hash_table how to handle unordered_map's __hash_value_type.

Author: ericwf
Date: Thu Feb 11 05:59:44 2016
New Revision: 260513

URL: http://llvm.org/viewvc/llvm-project?rev=260513=rev
Log:
Teach __hash_table how to handle unordered_map's __hash_value_type.

This patch is fairly large and contains a number of changes. The main change
is teaching '__hash_table' how to handle '__hash_value_type'. Unfortunately
this change is a rampant layering violation, but it's required to make
unordered_map conforming without re-writing all of __hash_table.
After this change 'unordered_map' can delegate to '__hash_table' in almost all 
cases.

The major changes found in this patch are:

  * Teach __hash_table to differentiate between the true container value type
and the node value type by introducing the "__container_value_type" and
"__node_value_type" typedefs. In the case of unordered_map 
'__container_value_type'
is 'pair' and '__node_value_type' is '__hash_value_type'.

  * Switch almost all overloads in '__hash_table' previously taking 'value_type'
(AKA '__node_value_type) to take  '__container_value_type' instead. 
Previously
'pair' would be implicitly converted to '__hash_value_type' 
because
of the function signature.

  * Add '__get_key', '__get_value', '__get_ptr', and '__move' static functions 
to
'__key_value_types'. These functions allow '__hash_table' to unwrap
'__node_value_type' objects into '__container_value_type' and its sub-parts.

  * Pass  '__hash_value_type::__value_'  to 'a.construct(p, ...)' instead of
'__hash_value_type' itself. The C++14 standard requires that 'a.construct()'
and 'a.destroy()' are only ever instantiated for the containers value type.

  * Remove '__hash_value_type's constructors and destructors. We should never
construct an instance of this type.
(TODO this is UB but we already do it in plenty of places).
  
  * Add a generic "try-emplace" function to '__hash_table' called
'__emplace_unique_key_args(Key const&, Args...)'.

  
The following changes were done as cleanup:

  * Introduce the '_LIBCPP_CXX03_LANG' macro to be used in place of
'_LIBCPP_HAS_NO_VARIADICS' or '_LIBCPP_HAS_NO_RVALUE_REFERENCE'.

  * Cleanup C++11 only overloads that assume an incomplete C++11 implementation.
For example this patch removes the __construct_node overloads that do
manual pack expansion.

  * Forward 'unordered_map::emplace' to '__hash_table' and remove dead code
resulting from the change. This includes almost all
'unordered_map::__construct_node' overloads.


The following changes are planed for future revisions:

  * Fix LWG issue #2469 by delegating 'unordered_map::operator[]' to use
'__emplace_unique_key_args'.

  * Rewrite 'unordered_map::try_emplace' in terms of 
'__emplace_unique_key_args'.
  
  * Optimize '__emplace_unique' to call '__emplace_unique_key_args' when 
possible.
This prevent unneeded allocations when inserting duplicate entries.


The additional follow up work needed after this patch:

  * Respect the lifetime rules for '__hash_value_type' by actually constructing 
it.
  * Make '__insert_multi' act similar to '__insert_unique' for objects of type
'T&' and 'T const &&' with 'T = __container_value_type'.
  
  

Added:

libcxx/trunk/test/std/containers/unord/unord.map/unord.map.modifiers/insert_allocator_requirements.pass.cpp

libcxx/trunk/test/std/containers/unord/unord.multimap/unord.multimap.modifiers/insert_allocator_requirements.pass.cpp

libcxx/trunk/test/std/containers/unord/unord.multiset/insert_allocator_requirements.pass.cpp

libcxx/trunk/test/std/containers/unord/unord.set/insert_allocator_requirements.pass.cpp
libcxx/trunk/test/support/container_test_types.h
Modified:
libcxx/trunk/include/__config
libcxx/trunk/include/__hash_table
libcxx/trunk/include/type_traits
libcxx/trunk/include/unordered_map

Modified: libcxx/trunk/include/__config
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__config?rev=260513=260512=260513=diff
==
--- libcxx/trunk/include/__config (original)
+++ libcxx/trunk/include/__config Thu Feb 11 05:59:44 2016
@@ -475,8 +475,6 @@ namespace std {
 #define _LIBCPP_NO_EXCEPTIONS
 #endif
 
-#define _LIBCPP_HAS_NO_TEMPLATE_ALIASES
-
 // constexpr was added to GCC in 4.6.
 #if _GNUC_VER < 406
 #define _LIBCPP_HAS_NO_CONSTEXPR
@@ -508,6 +506,7 @@ namespace std {
 #define _LIBCPP_HAS_NO_VARIADICS
 #define _LIBCPP_HAS_NO_RVALUE_REFERENCES
 #define _LIBCPP_HAS_NO_STRONG_ENUMS
+#define _LIBCPP_HAS_NO_TEMPLATE_ALIASES
 #define _LIBCPP_HAS_NO_NOEXCEPT
 
 #else  // __GXX_EXPERIMENTAL_CXX0X__
@@ -531,6 +530,7 @@ namespace std {
 #if _GNUC_VER < 406
 #define _LIBCPP_HAS_NO_NOEXCEPT
 #define _LIBCPP_HAS_NO_NULLPTR
+#define _LIBCPP_HAS_NO_TEMPLATE_ALIASES
 #endif
 
 #if _GNUC_VER < 407
@@ -849,7 +849,15 @@ extern "C" void __sanitizer_annotate_con
 
 #ifndef

Re: [PATCH] D17069: [clang-tidy] Fix an assert failure in 'readability-braces-around-statements' check.

2016-02-11 Thread Haojian Wu via cfe-commits

hokein marked an inline comment as done.
hokein added a comment.

http://reviews.llvm.org/D17069



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

Re: [PATCH] D17134: [clang-tidy] Fix an assert failure of ForStmt in `readability-braces-around-statements` check.

2016-02-11 Thread Alexander Kornienko via cfe-commits

alexfh added inline comments.


Comment at: 
test/clang-tidy/readability-braces-around-statements-assert-failure.cpp:13
@@ +12,3 @@
+  std::vector e;
+  for (typename std::vector::const_reverse_iterator iter = e.begin(),
+   end2 = e.end();

Can you further reduce the test case so it still causes a crash, but doesn't 
generate so many compilation errors?

The problem with matching compilation errors in clang-tidy tests is that a 
change in Clang parser can break clang-tidy tests. The more errors you verify, 
the higher the chance of this kind of a breakage. If we need to verify clang 
errors, we should keep their number minimal.


Repository:
  rL LLVM

http://reviews.llvm.org/D17134



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

[libcxx] r260515 - Re-commit "Introduce a cmake module to figure out whether we need to link with libatomic."

2016-02-11 Thread Vasileios Kalintiris via cfe-commits

Author: vkalintiris
Date: Thu Feb 11 06:43:04 2016
New Revision: 260515

URL: http://llvm.org/viewvc/llvm-project?rev=260515=rev
Log:
Re-commit "Introduce a cmake module to figure out whether we need to link with 
libatomic."

This re-applies commit r260235. However, this time we add -gcc-toolchain
to the compiler's flags when the user has specified the LIBCXX_GCC_TOOLCHAIN
variable.

Added:
libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake
Modified:
libcxx/trunk/cmake/config-ix.cmake
libcxx/trunk/lib/CMakeLists.txt
libcxx/trunk/test/CMakeLists.txt
libcxx/trunk/test/libcxx/test/target_info.py
libcxx/trunk/test/lit.site.cfg.in

Added: libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake?rev=260515=auto
==
--- libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake (added)
+++ libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake Thu Feb 11 06:43:04 2016
@@ -0,0 +1,41 @@
+INCLUDE(CheckCXXSourceCompiles)
+
+# Sometimes linking against libatomic is required for atomic ops, if
+# the platform doesn't support lock-free atomics.
+#
+# We could modify LLVM's CheckAtomic module and have it check for 64-bit
+# atomics instead. However, we would like to avoid careless uses of 64-bit
+# atomics inside LLVM over time on 32-bit platforms.
+
+function(check_cxx_atomics varname)
+  set(OLD_CMAKE_REQUIRED_FLAGS ${CMAKE_REQUIRED_FLAGS})
+  set(CMAKE_REQUIRED_FLAGS "-std=c++11")
+  if (${LIBCXX_GCC_TOOLCHAIN})
+set(CMAKE_REQUIRED_FLAGS "-std=c++11 
--gcc-toolchain=${LIBCXX_GCC_TOOLCHAIN}")
+  endif()
+  check_cxx_source_compiles("
+#include 
+#include 
+std::atomic x;
+std::atomic y;
+int main() {
+  return x + y;
+}
+" ${varname})
+  set(CMAKE_REQUIRED_FLAGS ${OLD_CMAKE_REQUIRED_FLAGS})
+endfunction(check_cxx_atomics)
+
+check_cxx_atomics(LIBCXX_HAVE_CXX_ATOMICS_WITH_LIB)
+# If not, check if the library exists, and atomics work with it.
+if(NOT LIBCXX_HAVE_CXX_ATOMICS_WITH_LIB)
+  check_library_exists(atomic __atomic_fetch_add_8 "" HAVE_LIBATOMIC)
+  if(HAVE_LIBATOMIC)
+list(APPEND CMAKE_REQUIRED_LIBRARIES "atomic")
+check_cxx_atomics(HAVE_CXX_ATOMICS_WITH_LIB)
+if (NOT HAVE_CXX_ATOMICS_WITH_LIB)
+  message(FATAL_ERROR "Host compiler must support std::atomic!")
+endif()
+  else()
+message(FATAL_ERROR "Host compiler appears to require libatomic, but 
cannot find it.")
+  endif()
+endif()

Modified: libcxx/trunk/cmake/config-ix.cmake
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/cmake/config-ix.cmake?rev=260515=260514=260515=diff
==
--- libcxx/trunk/cmake/config-ix.cmake (original)
+++ libcxx/trunk/cmake/config-ix.cmake Thu Feb 11 06:43:04 2016
@@ -1,5 +1,6 @@
 include(CheckLibraryExists)
 include(CheckCXXCompilerFlag)
+include(CheckLibcxxAtomic)
 
 # Check compiler flags
 
@@ -17,3 +18,7 @@ check_library_exists(c fopen "" LIBCXX_H
 check_library_exists(m ccos "" LIBCXX_HAS_M_LIB)
 check_library_exists(rt clock_gettime "" LIBCXX_HAS_RT_LIB)
 check_library_exists(gcc_s __gcc_personality_v0 "" LIBCXX_HAS_GCC_S_LIB)
+
+if (NOT HAVE_CXX_ATOMICS_WITHOUT_LIB)
+  set(LIBCXX_HAS_ATOMIC_LIB True)
+endif()

Modified: libcxx/trunk/lib/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/lib/CMakeLists.txt?rev=260515=260514=260515=diff
==
--- libcxx/trunk/lib/CMakeLists.txt (original)
+++ libcxx/trunk/lib/CMakeLists.txt Thu Feb 11 06:43:04 2016
@@ -79,6 +79,7 @@ add_library_flags_if(LIBCXX_HAS_C_LIB c)
 add_library_flags_if(LIBCXX_HAS_M_LIB m)
 add_library_flags_if(LIBCXX_HAS_RT_LIB rt)
 add_library_flags_if(LIBCXX_HAS_GCC_S_LIB gcc_s)
+add_library_flags_if(LIBCXX_HAS_ATOMIC_LIB atomic)
 
 # Setup flags.
 add_flags_if_supported(-fPIC)

Modified: libcxx/trunk/test/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/CMakeLists.txt?rev=260515=260514=260515=diff
==
--- libcxx/trunk/test/CMakeLists.txt (original)
+++ libcxx/trunk/test/CMakeLists.txt Thu Feb 11 06:43:04 2016
@@ -15,6 +15,7 @@ pythonize_bool(LIBCXX_ENABLE_SHARED)
 pythonize_bool(LIBCXX_BUILD_32_BITS)
 pythonize_bool(LIBCXX_GENERATE_COVERAGE)
 pythonize_bool(LIBCXXABI_USE_LLVM_UNWINDER)
+pythonize_bool(LIBCXX_HAS_ATOMIC_LIB)
 
 # The tests shouldn't link to any ABI library when it has been linked into
 # libc++ statically or via a linker script.

Modified: libcxx/trunk/test/libcxx/test/target_info.py
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/libcxx/test/target_info.py?rev=260515=260514=260515=diff
==
--- libcxx/trunk/test/libcxx/test/target_info.py (original)
+++

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

2016-02-11 Thread Jonathan Wakely via cfe-commits

On 11 February 2016 at 12:40, Matthijs van Duin wrote:
> You never define "POD for the purposes of layout", and I can only
> interpret it as being equivalent to "standard-layout".

As Richard pointed out, it's defined in the C++ ABI.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libcxx] r260516 - separate nested >>

Author: ericwf
Date: Thu Feb 11 06:51:19 2016
New Revision: 260516

URL: http://llvm.org/viewvc/llvm-project?rev=260516=rev
Log:
separate nested >>

Modified:
libcxx/trunk/test/support/container_test_types.h

Modified: libcxx/trunk/test/support/container_test_types.h
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/support/container_test_types.h?rev=260516=260515=260516=diff
==
--- libcxx/trunk/test/support/container_test_types.h (original)
+++ libcxx/trunk/test/support/container_test_types.h Thu Feb 11 06:51:19 2016
@@ -482,7 +482,7 @@ struct unordered_map_type {
   type;
 };
 
-template , class Value = CopyInsertable<2>>
+template , class Value = CopyInsertable<2> >
 struct unordered_multimap_type {
 typedef std::pair ValueTp;
 typedef


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

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

2016-02-11 Thread Matthijs van Duin via cfe-commits

On 8 February 2016 at 22:40, H.J. Lu  wrote:
> "empty type".  An empty type is either an array of empty types or a
> class type where every member is of empty type.

Note that the term "empty type" is commonly used in type theory to
denote a (or the) type with no values.  The closest thing C has would be
an empty enum when using -fstrict-enums.  (Declaring it as return type
implies [[noreturn]] or undefined behaviour.)

A type with a unique value (such as void or an empty struct) is usually
known as a unit type.

BTW, being standard layout is not sufficient (nor required afaict) for
zero-register passing of a unit type.  The requirement you need is
trivially-copyable.  Example:

#include 
#include 
#include 

using namespace std;

class EmptyInt {
static map< const EmptyInt *, int > values;

public:
EmptyInt() = default;
EmptyInt( int x ) {  values[this] = x;  }
~EmptyInt() {  values.erase(this);  }

operator int () const {  return values[this];  }
};

typeof( EmptyInt::values ) EmptyInt::values;

EmptyInt foo() {
return 42;
}

int main() {
cout << is_standard_layout{} << endl;
cout << foo() << endl;
return 0;
}

This evil contraption satisfies all POD-requirements except for not
being trivially-copyable.  On the other hand taking this example from
http://en.cppreference.com/w/cpp/concept/StandardLayoutType

struct Q {};
struct S : Q {};
struct T : Q {};
struct U : S, T {}; // not a standard-layout class

Even though U is not standard-layout, it is trivially-copyable and I see
no reason to allocate a register to pass it.

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

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

2016-02-11 Thread Matthijs van Duin via cfe-commits

On 11 February 2016 at 11:53, H.J. Lu  wrote:
> Since this isn't Plain Old Data (POD) for the purposes of layout, it
> isn't covered by my proposal for psABI.  I leave this to C++ ABI.

You never define "POD for the purposes of layout", and I can only
interpret it as being equivalent to "standard-layout". The property of
being trivially copyable/destructible is not a statement about layout
and my EmptyInt example is POD in every other aspect.

There's a good argument for trivially copyable/destructible being the
relevant property: it means an object can be copied simply by copying
its bytes and destroyed simply by discarding its storage. If the
object occupies no storage (other than padding) then these operations
become nops hence there is never a need to have a pointer/reference to
the original object.

The precise layout is not really important here, e.g. struct U is
unusually large considering its lack of data members, due to the need
for padding between its base classes, but this doesn't change the fact
it can be copied using no operation (and g++ indeed does).

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

Re: [PATCH] D16517: ClangTidy check to flag uninitialized builtin and pointer fields.

2016-02-11 Thread Alexander Kornienko via cfe-commits

alexfh added inline comments.


Comment at: clang-tidy/cppcoreguidelines/ProTypeMemberInitCheck.cpp:206
@@ +205,3 @@
+  // Do not propose fixes in macros since we cannot place them correctly.
+  if (Ctor->getLocStart().isMacroID())
+return;

IIUC what this is doing, the offset should be `0` instead of 
`Field->getName().size()`. I've tried 
`Lexer::getLocForEndOfToken(Field->getSourceRange().getEnd(), 0, 
*Result.SourceManager, Result.Context->getLangOpts())` and it seems to work 
fine on your tests.


Comment at: test/clang-tidy/cppcoreguidelines-pro-type-member-init.cpp:96
@@ +95,3 @@
+UNINITIALIZED_FIELD_IN_MACRO_BODY(F);
+// CHECK-MESSAGES: :[[@LINE-1]]:1: warning: constructor does not initialize 
these built-in/pointer fields: F
+UNINITIALIZED_FIELD_IN_MACRO_BODY(G);

We also need to check that the macro definition stays the same. The lack of 
CHECK-FIXES doesn't ensure the fix wasn't applied (probably, it should, but 
that's another story).


http://reviews.llvm.org/D16517



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

r260518 - clang-format: [JS] Support for (.. of ..) loops.

2016-02-11 Thread Daniel Jasper via cfe-commits

Author: djasper
Date: Thu Feb 11 07:24:15 2016
New Revision: 260518

URL: http://llvm.org/viewvc/llvm-project?rev=260518=rev
Log:
clang-format: [JS] Support for (.. of ..) loops.

Before:
  for (var i of[2, 3]) {}

After:
  for (var i of [2, 3]) {}

Modified:
cfe/trunk/lib/Format/FormatToken.h
cfe/trunk/lib/Format/TokenAnnotator.cpp
cfe/trunk/unittests/Format/FormatTestJS.cpp

Modified: cfe/trunk/lib/Format/FormatToken.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/FormatToken.h?rev=260518=260517=260518=diff
==
--- cfe/trunk/lib/Format/FormatToken.h (original)
+++ cfe/trunk/lib/Format/FormatToken.h Thu Feb 11 07:24:15 2016
@@ -528,6 +528,7 @@ struct AdditionalKeywords {
 kw_final = ("final");
 kw_override = ("override");
 kw_in = ("in");
+kw_of = ("of");
 kw_CF_ENUM = ("CF_ENUM");
 kw_CF_OPTIONS = ("CF_OPTIONS");
 kw_NS_ENUM = ("NS_ENUM");
@@ -571,6 +572,7 @@ struct AdditionalKeywords {
   IdentifierInfo *kw_final;
   IdentifierInfo *kw_override;
   IdentifierInfo *kw_in;
+  IdentifierInfo *kw_of;
   IdentifierInfo *kw_CF_ENUM;
   IdentifierInfo *kw_CF_OPTIONS;
   IdentifierInfo *kw_NS_ENUM;

Modified: cfe/trunk/lib/Format/TokenAnnotator.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/TokenAnnotator.cpp?rev=260518=260517=260518=diff
==
--- cfe/trunk/lib/Format/TokenAnnotator.cpp (original)
+++ cfe/trunk/lib/Format/TokenAnnotator.cpp Thu Feb 11 07:24:15 2016
@@ -2037,7 +2037,7 @@ bool TokenAnnotator::spaceRequiredBefore
   return true;
   } else if (Style.Language == FormatStyle::LK_JavaScript) {
 if (Left.isOneOf(Keywords.kw_let, Keywords.kw_var, TT_JsFatArrow,
- Keywords.kw_in))
+ Keywords.kw_in, Keywords.kw_of))
   return true;
 if (Left.is(tok::kw_default) && Left.Previous &&
 Left.Previous->is(tok::kw_export))

Modified: cfe/trunk/unittests/Format/FormatTestJS.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Format/FormatTestJS.cpp?rev=260518=260517=260518=diff
==
--- cfe/trunk/unittests/Format/FormatTestJS.cpp (original)
+++ cfe/trunk/unittests/Format/FormatTestJS.cpp Thu Feb 11 07:24:15 2016
@@ -595,6 +595,8 @@ TEST_F(FormatTestJS, ReturnStatements) {
 TEST_F(FormatTestJS, ForLoops) {
   verifyFormat("for (var i in [2, 3]) {\n"
"}");
+  verifyFormat("for (var i of [2, 3]) {\n"
+   "}");
 }
 
 TEST_F(FormatTestJS, AutomaticSemicolonInsertion) {
@@ -758,6 +760,7 @@ TEST_F(FormatTestJS, TypeAnnotations) {
   verifyFormat("function x(): {x: string} {\n  return {x: 'x'};\n}");
   verifyFormat("function x(y: string): string {\n  return 'x';\n}");
   verifyFormat("for (var y: string in x) {\n  x();\n}");
+  verifyFormat("for (var y: string of x) {\n  x();\n}");
   verifyFormat("function x(y: {a?: number;} = {}): number {\n"
"  return 12;\n"
"}");


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

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

2016-02-11 Thread Matthijs van Duin via cfe-commits

On 11 February 2016 at 15:00, H.J. Lu  wrote:
> I intentionally exclude C++ specific features in my propose.

Yet you use a definition from the Itanium C++ ABI which itself depends
on multiple definitions in a particular version of the C++ standard,
which depend on C++ specific features.

This makes no sense to me.

Note that triviality of copying/destruction holds for all C types and
is easy to formulate in languages other than C++. (As is the notion of
an aggregate requiring no storage, other than padding. The whole
argument about array parameters seems a bit silly since this is mere
syntax sugar, C/C++ do not support passing an actual array by value.)

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

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

On Thu, Feb 11, 2016 at 6:18 AM, Matthijs van Duin
 wrote:
> On 11 February 2016 at 15:00, H.J. Lu  wrote:
>> I intentionally exclude C++ specific features in my propose.
>
> Yet you use a definition from the Itanium C++ ABI which itself depends
> on multiple definitions in a particular version of the C++ standard,
> which depend on C++ specific features.

Yes, I used this C++ ABI definition to make C++ and C equivalent in
empty type definition.

> This makes no sense to me.
>
> Note that triviality of copying/destruction holds for all C types and
> is easy to formulate in languages other than C++. (As is the notion of

Can you point out which C++ features for empty type with C counter parts
aren't covered by "POD for the purpose of layout"?

> an aggregate requiring no storage, other than padding. The whole
> argument about array parameters seems a bit silly since this is mere
> syntax sugar, C/C++ do not support passing an actual array by value.)
>
> Matthijs van Duin



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

r260517 - clang-format: Make indentation after "<<" more consistent.

2016-02-11 Thread Daniel Jasper via cfe-commits

Author: djasper
Date: Thu Feb 11 07:15:14 2016
New Revision: 260517

URL: http://llvm.org/viewvc/llvm-project?rev=260517=rev
Log:
clang-format: Make indentation after "<<" more consistent.

Before:
  Diag(, )
  << (
  a);
  Diag(, )
  << (
 a)
  << aaa;

After:
  Diag(, )
  << (
 a);
  Diag(, )
  << (
 a)
  << aaa;

Modified:
cfe/trunk/lib/Format/ContinuationIndenter.cpp
cfe/trunk/unittests/Format/FormatTest.cpp

Modified: cfe/trunk/lib/Format/ContinuationIndenter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/ContinuationIndenter.cpp?rev=260517=260516=260517=diff
==
--- cfe/trunk/lib/Format/ContinuationIndenter.cpp (original)
+++ cfe/trunk/lib/Format/ContinuationIndenter.cpp Thu Feb 11 07:15:14 2016
@@ -402,9 +402,9 @@ void ContinuationIndenter::addTokenOnCur
(Previous.isNot(tok::lessless) || Previous.OperatorIndex != 0 ||
 Previous.NextOperator)) ||
   Current.StartsBinaryExpression)) {
-// Always indent relative to the RHS of the expression unless this is a
-// simple assignment without binary expression on the RHS. Also indent
-// relative to unary operators and the colons of constructor initializers.
+// Indent relative to the RHS of the expression unless this is a simple
+// assignment without binary expression on the RHS. Also indent relative to
+// unary operators and the colons of constructor initializers.
 State.Stack.back().LastSpace = State.Column;
   } else if (Previous.is(TT_InheritanceColon)) {
 State.Stack.back().Indent = State.Column;
@@ -531,6 +531,12 @@ unsigned ContinuationIndenter::addTokenO
 
   if (!Current.isTrailingComment())
 State.Stack.back().LastSpace = State.Column;
+  if (Current.is(tok::lessless))
+// If we are breaking before a "<<", we always want to indent relative to
+// RHS. This is necessary only for "<<", as we special-case it and don't
+// always indent relative to the RHS.
+State.Stack.back().LastSpace += 3; // 3 -> width of "<< ".
+
   State.StartOfLineLevel = Current.NestingLevel;
   State.LowestLevelOnLine = Current.NestingLevel;
 

Modified: cfe/trunk/unittests/Format/FormatTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Format/FormatTest.cpp?rev=260517=260516=260517=diff
==
--- cfe/trunk/unittests/Format/FormatTest.cpp (original)
+++ cfe/trunk/unittests/Format/FormatTest.cpp Thu Feb 11 07:15:14 2016
@@ -5105,6 +5105,13 @@ TEST_F(FormatTest, AlignsPipes) {
"<< aaa;");
   verifyFormat("SemaRef.Diag(Loc, diag::note_for_range_begin_end)\n"
"<< BEF << IsTemplate << Description << E->getType();");
+  verifyFormat("Diag(, )\n"
+   "<< (\n"
+   "   a);");
+  verifyFormat("Diag(, )\n"
+   "<< (\n"
+   "   a)\n"
+   "<< aaa;");
 
   verifyFormat(
   "llvm::errs() << \n"


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

r260519 - Partial revert of rL260506.

2016-02-11 Thread Andrey Bokhanko via cfe-commits

Author: asbokhan
Date: Thu Feb 11 07:27:02 2016
New Revision: 260519

URL: http://llvm.org/viewvc/llvm-project?rev=260519=rev
Log:
Partial revert of rL260506.

After some experiments I discovered that clang doesn't support static
initialization of flexible array members in full, so restored this paragraph in
"GCC extensions not implemented yet" list.

Modified:
cfe/trunk/docs/UsersManual.rst

Modified: cfe/trunk/docs/UsersManual.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/UsersManual.rst?rev=260519=260518=260519=diff
==
--- cfe/trunk/docs/UsersManual.rst (original)
+++ cfe/trunk/docs/UsersManual.rst Thu Feb 11 07:27:02 2016
@@ -1711,6 +1711,9 @@ extensions are not implemented yet:
  ...
  local_function(1);
 
+-  clang does not support static initialization of flexible array
+   members. This appears to be a rarely used extension, but could be
+   implemented pending user demand.
 -  clang does not support
``__builtin_va_arg_pack``/``__builtin_va_arg_pack_len``. This is
used rarely, but in some potentially interesting places, like the


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

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

2016-02-11 Thread Matthijs van Duin via cfe-commits

On 11 February 2016 at 13:58, H.J. Lu  wrote:
> "POD for the purpose of layout" is defined in the Itanium C++ ABI here:
>
> http://mentorembedded.github.io/cxx-abi/abi.html#definitions

Sorry, I overlooked that.

I still stand by my viewpoint however that triviality of copying and
destruction is the appropriate criterion here rather than this obscure
constraint on layout.

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

Re: Linux-abi group

On Thu, Feb 11, 2016 at 2:26 AM, Suprateeka R Hegde
 wrote:
> H.J,
>
> I think we are fragmenting with too many standards and mailing lists. This
> new discussion group and eventually the resulting standards, all might be
> put under LSB http://refspecs.linuxfoundation.org/lsb.shtml
>
> The Intro on LSB says:
> http://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/elfintro.html
>
> And thats what this proposal is intended for.
>
> And we can use the LSB mailing list
> https://lists.linux-foundation.org/mailman/listinfo/lsb-discuss for all
> discussions.
>
> What do you think?
>

LSB lists extensions which have been implemented.  But it isn't a spec
you can use to implement them.  For example:

http://refspecs.linuxbase.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/progheader.html

lists PT_GNU_EH_FRAME, PT_GNU_STACK and PT_GNU_RELRO.
But it gives no details.  Linux ABI group is the place where we propose
extensions before they get implemented.

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

[clang-tools-extra] r260535 - [clang-tidy] google-runtime-int: fix a false positive in implicit code.

2016-02-11 Thread Alexander Kornienko via cfe-commits

Author: alexfh
Date: Thu Feb 11 10:22:58 2016
New Revision: 260535

URL: http://llvm.org/viewvc/llvm-project?rev=260535=rev
Log:
[clang-tidy] google-runtime-int: fix a false positive in implicit code.

Modified:
clang-tools-extra/trunk/clang-tidy/google/IntegerTypesCheck.cpp
clang-tools-extra/trunk/clang-tidy/google/IntegerTypesCheck.h
clang-tools-extra/trunk/test/clang-tidy/google-runtime-int.cpp

Modified: clang-tools-extra/trunk/clang-tidy/google/IntegerTypesCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/google/IntegerTypesCheck.cpp?rev=260535=260534=260535=diff
==
--- clang-tools-extra/trunk/clang-tidy/google/IntegerTypesCheck.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/google/IntegerTypesCheck.cpp Thu Feb 11 
10:22:58 2016
@@ -12,14 +12,34 @@
 #include "clang/ASTMatchers/ASTMatchFinder.h"
 #include "clang/ASTMatchers/ASTMatchers.h"
 #include "clang/Basic/CharInfo.h"
+#include "clang/Basic/IdentifierTable.h"
 #include "clang/Basic/TargetInfo.h"
+#include "clang/Lex/Lexer.h"
 
 namespace clang {
+
+using namespace ast_matchers;
+
+static Token getTokenAtLoc(SourceLocation Loc,
+   const MatchFinder::MatchResult ,
+   IdentifierTable ) {
+  Token Tok;
+  if (Lexer::getRawToken(Loc, Tok, *MatchResult.SourceManager,
+ MatchResult.Context->getLangOpts(), false))
+return Tok;
+
+  if (Tok.is(tok::raw_identifier)) {
+IdentifierInfo  = IdentTable.get(Tok.getRawIdentifier());
+Tok.setIdentifierInfo();
+Tok.setKind(Info.getTokenID());
+  }
+  return Tok;
+}
+
 namespace tidy {
 namespace google {
 namespace runtime {
 
-using namespace ast_matchers;
 
 IntegerTypesCheck::IntegerTypesCheck(StringRef Name, ClangTidyContext *Context)
 : ClangTidyCheck(Name, Context),
@@ -35,8 +55,10 @@ void IntegerTypesCheck::storeOptions(Cla
 
 void IntegerTypesCheck::registerMatchers(MatchFinder *Finder) {
   // Find all TypeLocs. The relevant Style Guide rule only applies to C++.
-  if (getLangOpts().CPlusPlus)
-Finder->addMatcher(typeLoc(loc(isInteger())).bind("tl"), this);
+  if (!getLangOpts().CPlusPlus)
+return;
+  Finder->addMatcher(typeLoc(loc(isInteger())).bind("tl"), this);
+  IdentTable = llvm::make_unique(getLangOpts());
 }
 
 void IntegerTypesCheck::check(const MatchFinder::MatchResult ) {
@@ -54,6 +76,15 @@ void IntegerTypesCheck::check(const Matc
   if (!BuiltinLoc)
 return;
 
+  Token Tok = getTokenAtLoc(Loc, Result, *IdentTable);
+  // Ensure the location actually points to one of the builting integral type
+  // names we're interested in. Otherwise, we might be getting this match from
+  // implicit code (e.g. an implicit assignment operator of a class containing
+  // an array of non-POD types).
+  if (!Tok.isOneOf(tok::kw_short, tok::kw_long, tok::kw_unsigned,
+   tok::kw_signed))
+return;
+
   bool IsSigned;
   unsigned Width;
   const TargetInfo  = Result.Context->getTargetInfo();

Modified: clang-tools-extra/trunk/clang-tidy/google/IntegerTypesCheck.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/google/IntegerTypesCheck.h?rev=260535=260534=260535=diff
==
--- clang-tools-extra/trunk/clang-tidy/google/IntegerTypesCheck.h (original)
+++ clang-tools-extra/trunk/clang-tidy/google/IntegerTypesCheck.h Thu Feb 11 
10:22:58 2016
@@ -12,7 +12,12 @@
 
 #include "../ClangTidy.h"
 
+#include 
+
 namespace clang {
+
+class IdentifierTable;
+
 namespace tidy {
 namespace google {
 namespace runtime {
@@ -32,6 +37,8 @@ private:
   const std::string UnsignedTypePrefix;
   const std::string SignedTypePrefix;
   const std::string TypeSuffix;
+
+  std::unique_ptr IdentTable;
 };
 
 } // namespace runtime

Modified: clang-tools-extra/trunk/test/clang-tidy/google-runtime-int.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/google-runtime-int.cpp?rev=260535=260534=260535=diff
==
--- clang-tools-extra/trunk/test/clang-tidy/google-runtime-int.cpp (original)
+++ clang-tools-extra/trunk/test/clang-tidy/google-runtime-int.cpp Thu Feb 11 
10:22:58 2016
@@ -65,3 +65,10 @@ struct some_value {};
 constexpr some_value operator"" _some_literal(unsigned long long int i);
 // CHECK-MESSAGES: [[@LINE-1]]:47: warning: consider replacing 'unsigned long 
long'
 
+struct A { A& operator=(const A&); };
+class B { A a[0]; };
+
+void fff() {
+  B a, b;
+  a = b;
+}


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

Re: Linux-abi group

2016-02-11 Thread Ed Maste via cfe-commits

On 8 February 2016 at 18:08, Joseph Myers  wrote:
> On Mon, 8 Feb 2016, H.J. Lu wrote:
>
>> >> I was referring to program properties:
>> >>
>> >> https://groups.google.com/forum/#!topic/generic-abi/fyIXttIsYc8
>> >
>> > This looks more like an ELF topic to me, not really ABI.
>> >
>> > Please discuss this on a GNU project list because it affects the
>> > entire GNU project.
>> >
>>
>> gABI is ELF and affects all users, including GNU project, of gABI.
>> Linux-abi discusses Linux-specific extensions to gABI. It is for tools
>> like compilers, assembler, linker and run-time.  It isn't appropriate
>> for any GNU project list.

But the examples presented so far (STT_GNU_IFUNC, PT_GNU_RELRO etc.)
are relevant to GNU systems in general and are not Linux-specific.

> I find it extremely unlikely that many well-thought-out extensions would
> be appropriate for GNU systems using the Linux kernel but not for GNU
> systems using Hurd or other kernels - the only such cases would be for
> things very closely related to kernel functionality.  There is a strong
> presumption that toolchain configuration should apply to all GNU systems
> rather than being specific to GNU/Linux without good reason.

Agreed. As we've seen with the fallout from the abi_tag attribute we
need better communication between groups in the free software tool
chain world, not more fragmentation.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r260533 - [ARM] Add command-line options for ARMv8.2-A

2016-02-11 Thread Oliver Stannard via cfe-commits

Author: olista01
Date: Thu Feb 11 10:05:52 2016
New Revision: 260533

URL: http://llvm.org/viewvc/llvm-project?rev=260533=rev
Log:
[ARM] Add command-line options for ARMv8.2-A

This allows ARMv8.2-A to be targeted either by using "armv8.2a" in the
triple, or by using -march=armv8.2-a (or the alias -march=armv8.2a).

The FP16 extension can be enabled with the "+fp16" suffix to the -march
or -mcpu option. This is consistent with the AArch64 option, rather than
the usual ARM option of -mfpu. We have agreed with the team which will
be upstreaming this to GCC that we want to use this new option format
for new architecture extensions for both ARM and AArch64.

Most of the work for this was done by the TargetParser patch in llvm.

Differential Revision: http://reviews.llvm.org/D15040


Modified:
cfe/trunk/lib/Basic/Targets.cpp
cfe/trunk/lib/Driver/Tools.cpp
cfe/trunk/test/Driver/arm-cortex-cpus.c
cfe/trunk/test/Preprocessor/arm-target-features.c

Modified: cfe/trunk/lib/Basic/Targets.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=260533=260532=260533=diff
==
--- cfe/trunk/lib/Basic/Targets.cpp (original)
+++ cfe/trunk/lib/Basic/Targets.cpp Thu Feb 11 10:05:52 2016
@@ -4473,6 +4473,8 @@ class ARMTargetInfo : public TargetInfo
   return "8A";
 case llvm::ARM::AK_ARMV8_1A:
   return "8_1A";
+case llvm::ARM::AK_ARMV8_2A:
+  return "8_2A";
 }
   }
 

Modified: cfe/trunk/lib/Driver/Tools.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=260533=260532=260533=diff
==
--- cfe/trunk/lib/Driver/Tools.cpp (original)
+++ cfe/trunk/lib/Driver/Tools.cpp Thu Feb 11 10:05:52 2016
@@ -880,10 +880,6 @@ static void getARMTargetFeatures(const T
   Features.push_back("-crc");
   }
 
-  if (Triple.getSubArch() == llvm::Triple::SubArchType::ARMSubArch_v8_1a) {
-Features.insert(Features.begin(), "+v8.1a");
-  }
-
   // Look for the last occurrence of -mlong-calls or -mno-long-calls. If
   // neither options are specified, see if we are compiling for kernel/kext and
   // decide whether to pass "+long-calls" based on the OS and its version.

Modified: cfe/trunk/test/Driver/arm-cortex-cpus.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/arm-cortex-cpus.c?rev=260533=260532=260533=diff
==
--- cfe/trunk/test/Driver/arm-cortex-cpus.c (original)
+++ cfe/trunk/test/Driver/arm-cortex-cpus.c Thu Feb 11 10:05:52 2016
@@ -204,7 +204,7 @@
 // RUN: %clang -mcpu=generic -target armv8.1a -mlittle-endian -### -c %s 2>&1 
| FileCheck -check-prefix=CHECK-V81A %s
 // RUN: %clang -mcpu=generic -target arm -march=armv8.1a -mlittle-endian -### 
-c %s 2>&1 | FileCheck -check-prefix=CHECK-V81A %s
 // RUN: %clang -mcpu=generic -target arm -mlittle-endian -march=armv8.1-a 
-mlittle-endian -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-V81A %s
-// CHECK-V81A: "-cc1"{{.*}} "-triple" "armv8.1a-{{.*}}" "-target-cpu" 
"generic" "-target-feature" "+v8.1a"
+// CHECK-V81A: "-cc1"{{.*}} "-triple" "armv8.1a-{{.*}}" "-target-cpu" "generic"
 
 // RUN: %clang -target armebv8.1a -### -c %s 2>&1 | FileCheck 
-check-prefix=CHECK-BE-V81A %s
 // RUN: %clang -target armeb -march=armebv8.1a -### -c %s 2>&1 | FileCheck 
-check-prefix=CHECK-BE-V81A %s
@@ -212,7 +212,7 @@
 // RUN: %clang -target armv8.1a -mbig-endian -### -c %s 2>&1 | FileCheck 
-check-prefix=CHECK-BE-V81A %s
 // RUN: %clang -target arm -march=armebv8.1a -mbig-endian -### -c %s 2>&1 | 
FileCheck -check-prefix=CHECK-BE-V81A %s
 // RUN: %clang -target arm -march=armebv8.1-a -mbig-endian -### -c %s 2>&1 | 
FileCheck -check-prefix=CHECK-BE-V81A %s
-// CHECK-BE-V81A: "-cc1"{{.*}} "-triple" "armebv8.1a-{{.*}}" "-target-cpu" 
"generic" "-target-feature" "+v8.1a"
+// CHECK-BE-V81A: "-cc1"{{.*}} "-triple" "armebv8.1a-{{.*}}" "-target-cpu" 
"generic"
 
 // RUN: %clang -target armv8.1a -mthumb -### -c %s 2>&1 | FileCheck 
-check-prefix=CHECK-V81A-THUMB %s
 // RUN: %clang -target arm -march=armv8.1a -mthumb -### -c %s 2>&1 | FileCheck 
-check-prefix=CHECK-V81A-THUMB %s
@@ -220,7 +220,7 @@
 // RUN: %clang -target armv8.1a -mlittle-endian -mthumb -### -c %s 2>&1 | 
FileCheck -check-prefix=CHECK-V81A-THUMB %s
 // RUN: %clang -target arm -march=armv8.1a -mlittle-endian -mthumb -### -c %s 
2>&1 | FileCheck -check-prefix=CHECK-V81A-THUMB %s
 // RUN: %clang -target arm -march=armv8.1-a -mlittle-endian -mthumb -### -c %s 
2>&1 | FileCheck -check-prefix=CHECK-V81A-THUMB %s
-// CHECK-V81A-THUMB: "-cc1"{{.*}} "-triple" "thumbv8.1a-{{.*}}" "-target-cpu" 
"generic" "-target-feature" "+v8.1a"
+// CHECK-V81A-THUMB: "-cc1"{{.*}} "-triple" "thumbv8.1a-{{.*}}" "-target-cpu" 
"generic"
 
 // RUN: %clang -target armebv8.1a -mthumb -### -c %s 2>&1 | FileCheck 
-check-prefix=CHECK-BE-V81A-THUMB %s

[libcxx] r260531 - Rename CheckLibcxxAtomic.cmake variable result names so they don't clash with LLVM

Author: ericwf
Date: Thu Feb 11 09:52:52 2016
New Revision: 260531

URL: http://llvm.org/viewvc/llvm-project?rev=260531=rev
Log:
Rename CheckLibcxxAtomic.cmake variable result names so they don't clash with 
LLVM

Modified:
libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake

Modified: libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake?rev=260531=260530=260531=diff
==
--- libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake (original)
+++ libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake Thu Feb 11 09:52:52 2016
@@ -31,8 +31,8 @@ if(NOT LIBCXX_HAVE_CXX_ATOMICS_WITHOUT_L
   check_library_exists(atomic __atomic_fetch_add_8 "" LIBCXX_HAS_ATOMIC_LIB)
   if(LIBCXX_HAS_ATOMIC_LIB)
 list(APPEND CMAKE_REQUIRED_LIBRARIES "atomic")
-check_cxx_atomics(HAVE_CXX_ATOMICS_WITH_LIB)
-if (NOT HAVE_CXX_ATOMICS_WITH_LIB)
+check_cxx_atomics(LIBCXX_HAVE_CXX_ATOMICS_WITH_LIB)
+if (NOT LIBCXX_HAVE_CXX_ATOMICS_WITH_LIB)
   message(FATAL_ERROR "Host compiler must support std::atomic!")
 endif()
   else()


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

Re: Linux-abi group

2016-02-11 Thread Suprateeka R Hegde via cfe-commits

On 11-Feb-2016 07:21 PM, H.J. Lu wrote:

On Thu, Feb 11, 2016 at 2:26 AM, Suprateeka R Hegde
wrote:

H.J,

I think we are fragmenting with too many standards and mailing lists. This
new discussion group and eventually the resulting standards, all might be
put under LSB http://refspecs.linuxfoundation.org/lsb.shtml

The Intro on LSB says:
http://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/elfintro.html

And thats what this proposal is intended for.

And we can use the LSB mailing list
https://lists.linux-foundation.org/mailman/listinfo/lsb-discuss for all
discussions.

What do you think?

LSB lists extensions which have been implemented. But it isn't a spec
you can use to implement them. For example:

http://refspecs.linuxbase.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/progheader.html

lists PT_GNU_EH_FRAME, PT_GNU_STACK and PT_GNU_RELRO.
But it gives no details. Linux ABI group is the place where we propose
extensions before they get implemented.

How to implement, according to me, is design details of a particular
product. It also depends on the language used to develop the product.
Standards, in most cases, are not tied to a language and hence do not
enforce implementation details.

For instance, the document "ELF Handling of Thread Local Storage" is a
technical whitepaper that encourages a way of implementation. It is not
an official extension.

I meant, use LSB mailing lists for proposals and after implementation,
update the LSB for all future references. If there is a need to show
implementation details, it should be a separate document.

My suggestion is to create something for all (entire Linux and not just
ABI) and make the ABI part of it. So as per your description of LSB, we
need a namespace something like LSB-Draft where entire Linux community
can discuss proposals and ABI is part of it.

Also, another namespace within LSB that holds documents showing example
implementations.

As we see through this discussion, there are many mailing lists and
groups with lot of overlaps. I think we have to prevent more such
fragmentation.

These are the thoughts I had. Bottom line is that, a standard is always
welcome. It is beneficial to all across industry.

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

Re: [PATCH] D17140: [clang-tidy] improve misc-misplaced-widening-cast so it also detects portability problems

2016-02-11 Thread Alexander Kornienko via cfe-commits

alexfh accepted this revision.
alexfh added a comment.
This revision is now accepted and ready to land.

LG


Repository:
  rL LLVM

http://reviews.llvm.org/D17140



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

[libcxx] r260526 - Properly down-cast a sentinal node pointer through void*

Author: ericwf
Date: Thu Feb 11 09:22:37 2016
New Revision: 260526

URL: http://llvm.org/viewvc/llvm-project?rev=260526=rev
Log:
Properly down-cast a sentinal node pointer through void*

Modified:
libcxx/trunk/include/__hash_table

Modified: libcxx/trunk/include/__hash_table
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__hash_table?rev=260526=260525=260526=diff
==
--- libcxx/trunk/include/__hash_table (original)
+++ libcxx/trunk/include/__hash_table Thu Feb 11 09:22:37 2016
@@ -917,6 +917,7 @@ public:
 typedef typename _NodeTypes::__node_type __node;
 typedef typename __rebind_alloc_helper<__alloc_traits, __node>::type 
__node_allocator;
 typedef allocator_traits<__node_allocator>   __node_traits;
+typedef typename _NodeTypes::__void_pointer  __void_pointer;
 typedef typename _NodeTypes::__node_pointer  __node_pointer;
 typedef typename _NodeTypes::__node_pointer  __node_const_pointer;
 typedef typename _NodeTypes::__node_base_type__first_node;
@@ -1955,7 +1956,7 @@ __hash_table<_Tp, _Hash, _Equal, _Alloc>
 __node_pointer __pn = __bucket_list_[__chash];
 if (__pn == nullptr)
 {
-__pn = 
static_cast<__node_pointer>(pointer_traits<__node_base_pointer>::pointer_to(__p1_.first()));
+__pn = 
static_cast<__node_pointer>(static_cast<__void_pointer>(pointer_traits<__node_base_pointer>::pointer_to(__p1_.first(;
 __h->__next_ = __pn->__next_;
 __pn->__next_ = __h.get();
 // fix up __bucket_list_


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

[libcxx] r260527 - Add some tests to ensure that the __regex_word does not conflict with any of ctype_base's values.

Author: marshall
Date: Thu Feb 11 09:23:04 2016
New Revision: 260527

URL: http://llvm.org/viewvc/llvm-project?rev=260527=rev
Log:
Add some tests to ensure that the __regex_word does not conflict with any of 
ctype_base's values.
Hopefully this will catch cases like 
https://llvm.org/bugs/show_bug.cgi?id=26476 in the future.


Modified:
libcxx/trunk/test/std/re/re.traits/lookup_classname.pass.cpp

Modified: libcxx/trunk/test/std/re/re.traits/lookup_classname.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/re/re.traits/lookup_classname.pass.cpp?rev=260527=260526=260527=diff
==
--- libcxx/trunk/test/std/re/re.traits/lookup_classname.pass.cpp (original)
+++ libcxx/trunk/test/std/re/re.traits/lookup_classname.pass.cpp Thu Feb 11 
09:23:04 2016
@@ -33,6 +33,19 @@ test(const char_type* A,
 
 int main()
 {
+//  if __regex_word is not distinct from all the classes, bad things happen
+//  See https://llvm.org/bugs/show_bug.cgi?id=26476 for an example.
+assert((std::ctype_base::space  & std::regex_traits::__regex_word) 
== 0);
+assert((std::ctype_base::print  & std::regex_traits::__regex_word) 
== 0);
+assert((std::ctype_base::cntrl  & std::regex_traits::__regex_word) 
== 0);
+assert((std::ctype_base::upper  & std::regex_traits::__regex_word) 
== 0);
+assert((std::ctype_base::lower  & std::regex_traits::__regex_word) 
== 0);
+assert((std::ctype_base::alpha  & std::regex_traits::__regex_word) 
== 0);
+assert((std::ctype_base::digit  & std::regex_traits::__regex_word) 
== 0);
+assert((std::ctype_base::punct  & std::regex_traits::__regex_word) 
== 0);
+assert((std::ctype_base::xdigit & std::regex_traits::__regex_word) 
== 0);
+assert((std::ctype_base::blank  & std::regex_traits::__regex_word) 
== 0);
+
 test("d", std::ctype_base::digit);
 test("D", std::ctype_base::digit);
 test("d", std::ctype_base::digit, true);


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

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

On Thu, Feb 11, 2016 at 6:54 AM, Michael Matz  wrote:
> Hi,
>
> On Thu, 11 Feb 2016, H.J. Lu wrote:
>
>> Any suggestions on new wording, something like
>>
>> 1. "class type".  A class type is a structure, union or C++ class.
>> 2. "empty type".  An empty type is a type where it and all of its
>> subobjects are of class or array type.
>>
>> Does it cover
>>
>> struct A { };
>> struct B { };
>> struct C : A, B { };
>
> I think this is covered by the above points.  But without further
> restriction I don't see how e.g. the above example with ctors and dtors
> would be ruled out (except if you regard a ctor as a sub-object).  For
> that you seem to need trivially-copyable, or that POD-ly thing.  So,
> perhaps simply amend (2) "... is a trivially copyable type where it ...".
>
>
> Ciao,
> Michael.

How about

struct A {
static void foo (void) ();
static int xxx;
};

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

[libcxx] r260524 - Fix r260515 - Correct typos in CMake changes

Author: ericwf
Date: Thu Feb 11 09:05:56 2016
New Revision: 260524

URL: http://llvm.org/viewvc/llvm-project?rev=260524=rev
Log:
Fix r260515 - Correct typos in CMake changes

Modified:
libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake
libcxx/trunk/cmake/config-ix.cmake

Modified: libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake?rev=260524=260523=260524=diff
==
--- libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake (original)
+++ libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake Thu Feb 11 09:05:56 2016
@@ -25,11 +25,11 @@ int main() {
   set(CMAKE_REQUIRED_FLAGS ${OLD_CMAKE_REQUIRED_FLAGS})
 endfunction(check_cxx_atomics)
 
-check_cxx_atomics(LIBCXX_HAVE_CXX_ATOMICS_WITH_LIB)
+check_cxx_atomics(LIBCXX_HAVE_CXX_ATOMICS_WITHOUT_LIB)
 # If not, check if the library exists, and atomics work with it.
-if(NOT LIBCXX_HAVE_CXX_ATOMICS_WITH_LIB)
-  check_library_exists(atomic __atomic_fetch_add_8 "" HAVE_LIBATOMIC)
-  if(HAVE_LIBATOMIC)
+if(NOT LIBCXX_HAVE_CXX_ATOMICS_WITHOUT_LIB)
+  check_library_exists(atomic __atomic_fetch_add_8 "" LIBCXX_HAS_ATOMIC_LIB)
+  if(LIBCXX_HAS_ATOMIC_LIB)
 list(APPEND CMAKE_REQUIRED_LIBRARIES "atomic")
 check_cxx_atomics(HAVE_CXX_ATOMICS_WITH_LIB)
 if (NOT HAVE_CXX_ATOMICS_WITH_LIB)

Modified: libcxx/trunk/cmake/config-ix.cmake
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/cmake/config-ix.cmake?rev=260524=260523=260524=diff
==
--- libcxx/trunk/cmake/config-ix.cmake (original)
+++ libcxx/trunk/cmake/config-ix.cmake Thu Feb 11 09:05:56 2016
@@ -18,7 +18,3 @@ check_library_exists(c fopen "" LIBCXX_H
 check_library_exists(m ccos "" LIBCXX_HAS_M_LIB)
 check_library_exists(rt clock_gettime "" LIBCXX_HAS_RT_LIB)
 check_library_exists(gcc_s __gcc_personality_v0 "" LIBCXX_HAS_GCC_S_LIB)
-
-if (NOT HAVE_CXX_ATOMICS_WITHOUT_LIB)
-  set(LIBCXX_HAS_ATOMIC_LIB True)
-endif()


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

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

2016-02-11 Thread Matthijs van Duin via cfe-commits

To avoid depending again on precise wording of definitions in C++
standard it may be worth being explicit about the requirement to be
trivially copyable *and* destructible, since although the former
implies the latter in the C++ standard this is not obvious from the
terminology (although you also need the latter in all practical cases
including the one being discussed).

The explanation I gave earlier ("it means an object can be copied
simply by copying its bytes and destroyed simply by discarding its
storage") can probably be polished into a language-agnostic
definition.

I think it is helpful in general when ABI standards can be extended to
other languages with as much ease and unambiguity as possible, for the
sake of interoperability.

For similar reasons I would support "aggregate occupying zero bytes
(excluding any padding)" with a footnote on the strange situation of
C/C++ arrays, which cannot be directly passed by value even if the
syntax may suggest they can (hence the rule being discussed is not
applicable to them).

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

Re: [PATCH] D17132: [libcxx] Fix definition of regex_traits::__regex_word on big-endian glibc systems

mclow.lists added a comment.

In r260527, I added some tests to catch this if it happens again.

If those tests fail w/o this patch and succeed with, then I'm happy with 
applying it.


http://reviews.llvm.org/D17132



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

RE: [libcxx] r260515 - Re-commit "Introduce a cmake module to figure out whether we need to link with libatomic."

2016-02-11 Thread Vasileios Kalintiris via cfe-commits

Hi Eric,

Your changes work fine for me. Out of curiosity, the correctness issue you 
mentioned was about the lines you removed from config-ix.cmake, right?

- Vasileios

From: Eric Fiselier [e...@efcs.ca]
Sent: 11 February 2016 15:11
To: Vasileios Kalintiris
Cc: cfe-commits
Subject: Re: [libcxx] r260515 - Re-commit "Introduce a cmake module to figure 
out whether we need to link with libatomic."

Hi Vasileios,

This patch doesn't quite work correctly. I've committed a follow up fix to it 
as r260524.

Let me know if you have any issues.

/Eric

On Thu, Feb 11, 2016 at 5:43 AM, Vasileios Kalintiris via cfe-commits 
> wrote:
Author: vkalintiris
Date: Thu Feb 11 06:43:04 2016
New Revision: 260515

URL: http://llvm.org/viewvc/llvm-project?rev=260515=rev
Log:
Re-commit "Introduce a cmake module to figure out whether we need to link with 
libatomic."

This re-applies commit r260235. However, this time we add -gcc-toolchain
to the compiler's flags when the user has specified the LIBCXX_GCC_TOOLCHAIN
variable.

Added:
libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake
Modified:
libcxx/trunk/cmake/config-ix.cmake
libcxx/trunk/lib/CMakeLists.txt
libcxx/trunk/test/CMakeLists.txt
libcxx/trunk/test/libcxx/test/target_info.py
libcxx/trunk/test/lit.site.cfg.in

Added: libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake?rev=260515=auto
==
--- libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake (added)
+++ libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake Thu Feb 11 06:43:04 2016
@@ -0,0 +1,41 @@
+INCLUDE(CheckCXXSourceCompiles)
+
+# Sometimes linking against libatomic is required for atomic ops, if
+# the platform doesn't support lock-free atomics.
+#
+# We could modify LLVM's CheckAtomic module and have it check for 64-bit
+# atomics instead. However, we would like to avoid careless uses of 64-bit
+# atomics inside LLVM over time on 32-bit platforms.
+
+function(check_cxx_atomics varname)
+  set(OLD_CMAKE_REQUIRED_FLAGS ${CMAKE_REQUIRED_FLAGS})
+  set(CMAKE_REQUIRED_FLAGS "-std=c++11")
+  if (${LIBCXX_GCC_TOOLCHAIN})
+set(CMAKE_REQUIRED_FLAGS "-std=c++11 
--gcc-toolchain=${LIBCXX_GCC_TOOLCHAIN}")
+  endif()
+  check_cxx_source_compiles("
+#include 
+#include 
+std::atomic x;
+std::atomic y;
+int main() {
+  return x + y;
+}
+" ${varname})
+  set(CMAKE_REQUIRED_FLAGS ${OLD_CMAKE_REQUIRED_FLAGS})
+endfunction(check_cxx_atomics)
+
+check_cxx_atomics(LIBCXX_HAVE_CXX_ATOMICS_WITH_LIB)
+# If not, check if the library exists, and atomics work with it.
+if(NOT LIBCXX_HAVE_CXX_ATOMICS_WITH_LIB)
+  check_library_exists(atomic __atomic_fetch_add_8 "" HAVE_LIBATOMIC)
+  if(HAVE_LIBATOMIC)
+list(APPEND CMAKE_REQUIRED_LIBRARIES "atomic")
+check_cxx_atomics(HAVE_CXX_ATOMICS_WITH_LIB)
+if (NOT HAVE_CXX_ATOMICS_WITH_LIB)
+  message(FATAL_ERROR "Host compiler must support std::atomic!")
+endif()
+  else()
+message(FATAL_ERROR "Host compiler appears to require libatomic, but 
cannot find it.")
+  endif()
+endif()

Modified: libcxx/trunk/cmake/config-ix.cmake
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/cmake/config-ix.cmake?rev=260515=260514=260515=diff
==
--- libcxx/trunk/cmake/config-ix.cmake (original)
+++ libcxx/trunk/cmake/config-ix.cmake Thu Feb 11 06:43:04 2016
@@ -1,5 +1,6 @@
 include(CheckLibraryExists)
 include(CheckCXXCompilerFlag)
+include(CheckLibcxxAtomic)

 # Check compiler flags

@@ -17,3 +18,7 @@ check_library_exists(c fopen "" LIBCXX_H
 check_library_exists(m ccos "" LIBCXX_HAS_M_LIB)
 check_library_exists(rt clock_gettime "" LIBCXX_HAS_RT_LIB)
 check_library_exists(gcc_s __gcc_personality_v0 "" LIBCXX_HAS_GCC_S_LIB)
+
+if (NOT HAVE_CXX_ATOMICS_WITHOUT_LIB)
+  set(LIBCXX_HAS_ATOMIC_LIB True)
+endif()

Modified: libcxx/trunk/lib/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/lib/CMakeLists.txt?rev=260515=260514=260515=diff
==
--- libcxx/trunk/lib/CMakeLists.txt (original)
+++ libcxx/trunk/lib/CMakeLists.txt Thu Feb 11 06:43:04 2016
@@ -79,6 +79,7 @@ add_library_flags_if(LIBCXX_HAS_C_LIB c)
 add_library_flags_if(LIBCXX_HAS_M_LIB m)
 add_library_flags_if(LIBCXX_HAS_RT_LIB rt)
 add_library_flags_if(LIBCXX_HAS_GCC_S_LIB gcc_s)
+add_library_flags_if(LIBCXX_HAS_ATOMIC_LIB atomic)

 # Setup flags.
 add_flags_if_supported(-fPIC)

Modified: libcxx/trunk/test/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/CMakeLists.txt?rev=260515=260514=260515=diff
==
--- libcxx/trunk/test/CMakeLists.txt (original)
+++

Re: [libcxx] r260515 - Re-commit "Introduce a cmake module to figure out whether we need to link with libatomic."

There were a couple of correctness issues. 'LIBCXX_HAS_ATOMIC_WITHOUT_LIB'
was accidentally typo-ed '_WITH_' in a couple of places and
'LIBCXX_HAS_ATOMIC_LIB' was not originally a cache variable like it
probably should have been.

I just used 'LIBCXX_HAS_ATOMIC_LIB' directly in 'check_library_exists' and
everything works better :-)

/Eric

On Thu, Feb 11, 2016 at 8:54 AM, Vasileios Kalintiris <
vasileios.kalinti...@imgtec.com> wrote:

> Hi Eric,
>
> Your changes work fine for me. Out of curiosity, the correctness issue you
> mentioned was about the lines you removed from config-ix.cmake, right?
>
> - Vasileios
> --
> *From:* Eric Fiselier [e...@efcs.ca]
> *Sent:* 11 February 2016 15:11
> *To:* Vasileios Kalintiris
> *Cc:* cfe-commits
> *Subject:* Re: [libcxx] r260515 - Re-commit "Introduce a cmake module to
> figure out whether we need to link with libatomic."
>
> Hi Vasileios,
>
> This patch doesn't quite work correctly. I've committed a follow up fix to
> it as r260524.
>
> Let me know if you have any issues.
>
> /Eric
>
> On Thu, Feb 11, 2016 at 5:43 AM, Vasileios Kalintiris via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: vkalintiris
>> Date: Thu Feb 11 06:43:04 2016
>> New Revision: 260515
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=260515=rev
>> Log:
>> Re-commit "Introduce a cmake module to figure out whether we need to link
>> with libatomic."
>>
>> This re-applies commit r260235. However, this time we add -gcc-toolchain
>> to the compiler's flags when the user has specified the
>> LIBCXX_GCC_TOOLCHAIN
>> variable.
>>
>> Added:
>> libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake
>> Modified:
>> libcxx/trunk/cmake/config-ix.cmake
>> libcxx/trunk/lib/CMakeLists.txt
>> libcxx/trunk/test/CMakeLists.txt
>> libcxx/trunk/test/libcxx/test/target_info.py
>> libcxx/trunk/test/lit.site.cfg.in
>>
>> Added: libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake
>> URL:
>> http://llvm.org/viewvc/llvm-project/libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake?rev=260515=auto
>>
>> ==
>> --- libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake (added)
>> +++ libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake Thu Feb 11
>> 06:43:04 2016
>> @@ -0,0 +1,41 @@
>> +INCLUDE(CheckCXXSourceCompiles)
>> +
>> +# Sometimes linking against libatomic is required for atomic ops, if
>> +# the platform doesn't support lock-free atomics.
>> +#
>> +# We could modify LLVM's CheckAtomic module and have it check for 64-bit
>> +# atomics instead. However, we would like to avoid careless uses of
>> 64-bit
>> +# atomics inside LLVM over time on 32-bit platforms.
>> +
>> +function(check_cxx_atomics varname)
>> +  set(OLD_CMAKE_REQUIRED_FLAGS ${CMAKE_REQUIRED_FLAGS})
>> +  set(CMAKE_REQUIRED_FLAGS "-std=c++11")
>> +  if (${LIBCXX_GCC_TOOLCHAIN})
>> +set(CMAKE_REQUIRED_FLAGS "-std=c++11
>> --gcc-toolchain=${LIBCXX_GCC_TOOLCHAIN}")
>> +  endif()
>> +  check_cxx_source_compiles("
>> +#include 
>> +#include 
>> +std::atomic x;
>> +std::atomic y;
>> +int main() {
>> +  return x + y;
>> +}
>> +" ${varname})
>> +  set(CMAKE_REQUIRED_FLAGS ${OLD_CMAKE_REQUIRED_FLAGS})
>> +endfunction(check_cxx_atomics)
>> +
>> +check_cxx_atomics(LIBCXX_HAVE_CXX_ATOMICS_WITH_LIB)
>> +# If not, check if the library exists, and atomics work with it.
>> +if(NOT LIBCXX_HAVE_CXX_ATOMICS_WITH_LIB)
>> +  check_library_exists(atomic __atomic_fetch_add_8 "" HAVE_LIBATOMIC)
>> +  if(HAVE_LIBATOMIC)
>> +list(APPEND CMAKE_REQUIRED_LIBRARIES "atomic")
>> +check_cxx_atomics(HAVE_CXX_ATOMICS_WITH_LIB)
>> +if (NOT HAVE_CXX_ATOMICS_WITH_LIB)
>> +  message(FATAL_ERROR "Host compiler must support std::atomic!")
>> +endif()
>> +  else()
>> +message(FATAL_ERROR "Host compiler appears to require libatomic, but
>> cannot find it.")
>> +  endif()
>> +endif()
>>
>> Modified: libcxx/trunk/cmake/config-ix.cmake
>> URL:
>> http://llvm.org/viewvc/llvm-project/libcxx/trunk/cmake/config-ix.cmake?rev=260515=260514=260515=diff
>>
>> ==
>> --- libcxx/trunk/cmake/config-ix.cmake (original)
>> +++ libcxx/trunk/cmake/config-ix.cmake Thu Feb 11 06:43:04 2016
>> @@ -1,5 +1,6 @@
>>  include(CheckLibraryExists)
>>  include(CheckCXXCompilerFlag)
>> +include(CheckLibcxxAtomic)
>>
>>  # Check compiler flags
>>
>> @@ -17,3 +18,7 @@ check_library_exists(c fopen "" LIBCXX_H
>>  check_library_exists(m ccos "" LIBCXX_HAS_M_LIB)
>>  check_library_exists(rt clock_gettime "" LIBCXX_HAS_RT_LIB)
>>  check_library_exists(gcc_s __gcc_personality_v0 "" LIBCXX_HAS_GCC_S_LIB)
>> +
>> +if (NOT HAVE_CXX_ATOMICS_WITHOUT_LIB)
>> +  set(LIBCXX_HAS_ATOMIC_LIB True)
>> +endif()
>>
>> Modified: libcxx/trunk/lib/CMakeLists.txt
>> URL:
>> http://llvm.org/viewvc/llvm-project/libcxx/trunk/lib/CMakeLists.txt?rev=260515=260514=260515=diff
>>
>>

[clang-tools-extra] r260532 - Merge branch 'arcpatch-D16922'

2016-02-11 Thread Cong Liu via cfe-commits

Author: congliu
Date: Thu Feb 11 10:03:27 2016
New Revision: 260532

URL: http://llvm.org/viewvc/llvm-project?rev=260532=rev
Log:
Merge branch 'arcpatch-D16922'

Modified:
clang-tools-extra/trunk/clang-tidy/misc/VirtualNearMissCheck.cpp
clang-tools-extra/trunk/clang-tidy/misc/VirtualNearMissCheck.h
clang-tools-extra/trunk/test/clang-tidy/misc-virtual-near-miss.cpp

Modified: clang-tools-extra/trunk/clang-tidy/misc/VirtualNearMissCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/misc/VirtualNearMissCheck.cpp?rev=260532=260531=260532=diff
==
--- clang-tools-extra/trunk/clang-tidy/misc/VirtualNearMissCheck.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/misc/VirtualNearMissCheck.cpp Thu Feb 11 
10:03:27 2016
@@ -249,11 +249,19 @@ void VirtualNearMissCheck::check(const M
 if (EditDistance > 0 && EditDistance <= EditDistanceThreshold) {
   if (checkOverrideWithoutName(Context, BaseMD, DerivedMD)) {
 // A "virtual near miss" is found.
-diag(DerivedMD->getLocStart(),
- "method '%0' has a similar name and the same signature as "
- "virtual method '%1'; did you mean to override it?")
+auto Range = CharSourceRange::getTokenRange(
+SourceRange(DerivedMD->getLocation()));
+
+bool ApplyFix = !BaseMD->isTemplateInstantiation() &&
+!DerivedMD->isTemplateInstantiation();
+auto Diag =
+diag(DerivedMD->getLocStart(),
+ "method '%0' has a similar name and the same signature as 
"
+ "virtual method '%1'; did you mean to override it?")
 << DerivedMD->getQualifiedNameAsString()
 << BaseMD->getQualifiedNameAsString();
+if (ApplyFix)
+  Diag << FixItHint::CreateReplacement(Range, BaseMD->getName());
   }
 }
   }

Modified: clang-tools-extra/trunk/clang-tidy/misc/VirtualNearMissCheck.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/misc/VirtualNearMissCheck.h?rev=260532=260531=260532=diff
==
--- clang-tools-extra/trunk/clang-tidy/misc/VirtualNearMissCheck.h (original)
+++ clang-tools-extra/trunk/clang-tidy/misc/VirtualNearMissCheck.h Thu Feb 11 
10:03:27 2016
@@ -12,7 +12,6 @@
 
 #include "../ClangTidy.h"
 #include 
-#include 
 
 namespace clang {
 namespace tidy {
@@ -46,12 +45,12 @@ private:
   bool isOverriddenByDerivedClass(const CXXMethodDecl *BaseMD,
   const CXXRecordDecl *DerivedRD);
 
-  /// key: the unique ID of a method;
-  /// value: whether the method is possible to be overridden.
+  /// Key: the unique ID of a method.
+  /// Value: whether the method is possible to be overridden.
   std::map PossibleMap;
 
-  /// key: 
-  /// value: whether the base method is overridden by some method in the 
derived
+  /// Key: 
+  /// Value: whether the base method is overridden by some method in the 
derived
   /// class.
   std::map
   OverriddenMap;

Modified: clang-tools-extra/trunk/test/clang-tidy/misc-virtual-near-miss.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/misc-virtual-near-miss.cpp?rev=260532=260531=260532=diff
==
--- clang-tools-extra/trunk/test/clang-tidy/misc-virtual-near-miss.cpp 
(original)
+++ clang-tools-extra/trunk/test/clang-tidy/misc-virtual-near-miss.cpp Thu Feb 
11 10:03:27 2016
@@ -16,9 +16,11 @@ struct Derived : Base {
   // overriden by this class.
   virtual void funk();
   // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: method 'Derived::funk' has a 
similar name and the same signature as virtual method 'Base::func'; did you 
mean to override it? [misc-virtual-near-miss]
+  // CHECK-FIXES: virtual void func();
 
   void func2();
   // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: method 'Derived::func2' has 
{{.*}} 'Base::func'
+  // CHECK-FIXES: void func();
 
   void func22(); // Should not warn.
 
@@ -26,12 +28,46 @@ struct Derived : Base {
 
   void fun();
   // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: method 'Derived::fun' has {{.*}} 
'Base::func'
+  // CHECK-FIXES: void func();
 
   Derived ==(const Base &); // Should not warn: operators are ignored.
 
   virtual NoDefinedClass2 *f1(); // Should not crash: non-defined class return 
type is ignored.
 };
 
+template 
+struct TBase {
+  virtual void tfunc(T t);
+};
+
+template 
+struct TDerived : TBase {
+  virtual void tfunk(T t);
+  // Should not apply fix for template.
+  // CHECK-MESSAGES: :[[@LINE-2]]:3: warning: method 'TDerived::tfunk' 
has {{.*}} 'TBase::tfunc'
+  // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: method 'TDerived::tfunk' 
has {{.*}} 'TBase::tfunc'
+  //

Re: [libcxx] r260235 - Introduce a cmake module to figure out whether we need to link with libatomic.

>  we need to rename HAVE_CXX_ATOMICS_WITH_LIB to something like
LIBCXX_HAVE_CXX_ATOMICS_WITH_LIB.

Fixed in r260531.

I think we will eventually want to merge the following commits, assuming
they don't regress the build, especially with the -gcc-toolchain option.

- [libcxx] r260515 - Re-commit "Introduce a cmake module to figure out
whether we need to link with libatomic."
- [libcxx] r260524 - Fix r260515 - Correct typos in CMake changes
- [libcxx] r260531 - Rename CheckLibcxxAtomic.cmake variable result names
so they don't clash with LLVM

@Marshall Any objections?

On Thu, Feb 11, 2016 at 2:18 AM, Daniel Sanders via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Hi,
>
> In my latests rc2+patches build I've also found that we need to rename
> HAVE_CXX_ATOMICS_WITH_LIB to something like
> LIBCXX_HAVE_CXX_ATOMICS_WITH_LIB. It's currently re-using the result of
> LLVM's check which doesn't include 64-bit atomics.
> 
> From: Vasileios Kalintiris
> Sent: 09 February 2016 23:50
> To: h...@chromium.org
> Cc: cfe-commits@lists.llvm.org; Daniel Sanders; mclow.li...@gmail.com
> Subject: RE: [libcxx] r260235 - Introduce a cmake module to figure out
> whether we need to link with libatomic.
>
> Hi Hans,
>
> Please wait before merging this as it breaks LLVM bootstraps when using
> the -gcc-toolchain option and the system's default gcc installation does
> not provide libatomic. We have to check LIBCXX_GCC_TOOLCHAIN in our test.
> I'll create a patch tomorrow and I'll let you know when it's okay to merge
> them. In the meantime, I reverted it in r260323.
>
> - Vasileios
> 
> From: Vasileios Kalintiris
> Sent: 09 February 2016 18:56
> To: h...@chromium.org
> Cc: cfe-commits@lists.llvm.org; Daniel Sanders; mclow.li...@gmail.com
> Subject: RE: [libcxx] r260235 - Introduce a cmake module to figure out
> whether we need to link with libatomic.
>
> Hi Hans,
>
> Can we merge this on the 3.8 release branch? It fixes libcxx builds on
> MIPS by linking with libatomic when needed. Also, all the x86_64 and ARM
> buildbots for libcxx look good.
>
> Thanks,
> Vasileios
>
> 
> From: cfe-commits [cfe-commits-boun...@lists.llvm.org] on behalf of
> Vasileios Kalintiris via cfe-commits [cfe-commits@lists.llvm.org]
> Sent: 09 February 2016 17:00
> To: cfe-commits@lists.llvm.org
> Subject: [libcxx] r260235 - Introduce a cmake module to figure out whether
> we need to link with libatomic.
>
> Author: vkalintiris
> Date: Tue Feb  9 11:00:38 2016
> New Revision: 260235
>
> URL: http://llvm.org/viewvc/llvm-project?rev=260235=rev
> Log:
> Introduce a cmake module to figure out whether we need to link with
> libatomic.
>
> Summary:
> This fixes the tests under std/atomics for 32-bit MIPS CPUs where the
> 8-byte atomic operations call into the libatomic library.
>
> Reviewers: dsanders, mclow.lists, EricWF, jroelofs, joerg
>
> Subscribers: cfe-commits
>
> Differential Revision: http://reviews.llvm.org/D16613
>
> Added:
> libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake
> Modified:
> libcxx/trunk/cmake/config-ix.cmake
> libcxx/trunk/lib/CMakeLists.txt
> libcxx/trunk/test/CMakeLists.txt
> libcxx/trunk/test/libcxx/test/target_info.py
> libcxx/trunk/test/lit.site.cfg.in
>
> Added: libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake
> URL:
> http://llvm.org/viewvc/llvm-project/libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake?rev=260235=auto
>
> ==
> --- libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake (added)
> +++ libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake Tue Feb  9 11:00:38
> 2016
> @@ -0,0 +1,38 @@
> +INCLUDE(CheckCXXSourceCompiles)
> +
> +# Sometimes linking against libatomic is required for atomic ops, if
> +# the platform doesn't support lock-free atomics.
> +#
> +# We could modify LLVM's CheckAtomic module and have it check for 64-bit
> +# atomics instead. However, we would like to avoid careless uses of 64-bit
> +# atomics inside LLVM over time on 32-bit platforms.
> +
> +function(check_cxx_atomics varname)
> +  set(OLD_CMAKE_REQUIRED_FLAGS ${CMAKE_REQUIRED_FLAGS})
> +  set(CMAKE_REQUIRED_FLAGS "-std=c++11")
> +  check_cxx_source_compiles("
> +#include 
> +#include 
> +std::atomic x;
> +std::atomic y;
> +int main() {
> +  return x + y;
> +}
> +" ${varname})
> +  set(CMAKE_REQUIRED_FLAGS ${OLD_CMAKE_REQUIRED_FLAGS})
> +endfunction(check_cxx_atomics)
> +
> +check_cxx_atomics(HAVE_CXX_ATOMICS_WITHOUT_LIB)
> +# If not, check if the library exists, and atomics work with it.
> +if(NOT HAVE_CXX_ATOMICS_WITHOUT_LIB)
> +  check_library_exists(atomic __atomic_fetch_add_8 "" HAVE_LIBATOMIC)
> +  if(HAVE_LIBATOMIC)
> +list(APPEND CMAKE_REQUIRED_LIBRARIES "atomic")
> +check_cxx_atomics(HAVE_CXX_ATOMICS_WITH_LIB)
> +if (NOT HAVE_CXX_ATOMICS_WITH_LIB)
> +  message(FATAL_ERROR "Host compiler must support

[PATCH] D17143: When trying to get destructor name, make we have a complete type before calling LookupQualifiedName(), which will assert otherwise.

2016-02-11 Thread don hinton via cfe-commits

hintonda created this revision.
hintonda added reviewers: doug.gregor, majnemer.
hintonda added a subscriber: cfe-commits.

Fix crash from PR25156 where getDestructorName() calls LookupQualifiedName() on 
incomplete type.

http://reviews.llvm.org/D17143

Files:
  lib/Sema/SemaExprCXX.cpp
  test/SemaCXX/pr25156-crash-on-invalid.cpp

Index: test/SemaCXX/pr25156-crash-on-invalid.cpp
===
--- /dev/null
+++ test/SemaCXX/pr25156-crash-on-invalid.cpp
@@ -0,0 +1,7 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+// Don't crash (PR25156).
+
+class foo; // expected-note {{forward declaration of 'foo'}}
+void f() {
+  foo::~foo(); // expected-error {{incomplete type 'foo' named in nested name 
specifier}}
+}
Index: lib/Sema/SemaExprCXX.cpp
===
--- lib/Sema/SemaExprCXX.cpp
+++ lib/Sema/SemaExprCXX.cpp
@@ -189,9 +189,10 @@
 // have one) and, if that fails to find a match, in the scope (if
 // we're allowed to look there).
 Found.clear();
-if (Step == 0 && LookupCtx)
-  LookupQualifiedName(Found, LookupCtx);
-else if (Step == 1 && LookInScope && S)
+if (Step == 0 && LookupCtx) {
+  if (!RequireCompleteDeclContext(SS, LookupCtx))
+LookupQualifiedName(Found, LookupCtx);
+} else if (Step == 1 && LookInScope && S)
   LookupName(Found, S);
 else
   continue;


Index: test/SemaCXX/pr25156-crash-on-invalid.cpp
===
--- /dev/null
+++ test/SemaCXX/pr25156-crash-on-invalid.cpp
@@ -0,0 +1,7 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+// Don't crash (PR25156).
+
+class foo; // expected-note {{forward declaration of 'foo'}}
+void f() {
+  foo::~foo(); // expected-error {{incomplete type 'foo' named in nested name specifier}}
+}
Index: lib/Sema/SemaExprCXX.cpp
===
--- lib/Sema/SemaExprCXX.cpp
+++ lib/Sema/SemaExprCXX.cpp
@@ -189,9 +189,10 @@
 // have one) and, if that fails to find a match, in the scope (if
 // we're allowed to look there).
 Found.clear();
-if (Step == 0 && LookupCtx)
-  LookupQualifiedName(Found, LookupCtx);
-else if (Step == 1 && LookInScope && S)
+if (Step == 0 && LookupCtx) {
+  if (!RequireCompleteDeclContext(SS, LookupCtx))
+LookupQualifiedName(Found, LookupCtx);
+} else if (Step == 1 && LookInScope && S)
   LookupName(Found, S);
 else
   continue;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: Linux-abi group

On Thu, Feb 11, 2016 at 8:05 AM, Suprateeka R Hegde
 wrote:
> On 11-Feb-2016 07:21 PM, H.J. Lu wrote:
>>
>> On Thu, Feb 11, 2016 at 2:26 AM, Suprateeka R Hegde
>>  wrote:
>>>
>>> H.J,
>>>
>>> I think we are fragmenting with too many standards and mailing lists.
>>> This
>>> new discussion group and eventually the resulting standards, all might be
>>> put under LSB http://refspecs.linuxfoundation.org/lsb.shtml
>>>
>>> The Intro on LSB says:
>>>
>>> http://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/elfintro.html
>>>
>>> And thats what this proposal is intended for.
>>>
>>> And we can use the LSB mailing list
>>> https://lists.linux-foundation.org/mailman/listinfo/lsb-discuss for all
>>> discussions.
>>>
>>> What do you think?
>>>
>>
>> LSB lists extensions which have been implemented.  But it isn't a spec
>> you can use to implement them.  For example:
>>
>>
>> http://refspecs.linuxbase.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/progheader.html
>>
>> lists PT_GNU_EH_FRAME, PT_GNU_STACK and PT_GNU_RELRO.
>> But it gives no details.  Linux ABI group is the place where we propose
>> extensions before they get implemented.
>
>
> How to implement, according to me, is design details of a particular
> product. It also depends on the language used to develop the product.
> Standards, in most cases, are not tied to a language and hence do not
> enforce implementation details.
>
>

That is exactly what Linux ABI group tries to address.  Please see
the Linux gABI extension draft at

https://github.com/hjl-tools/linux-abi/wiki/Linux-Extensions-to-gABI

It describes the conventions and constraints on the implementa-
tion of these extensions for interoperability between various tools.


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

[libunwind] r260595 - [AArch64] Fix libunwind build when using GNU assembler

2016-02-11 Thread Renato Golin via cfe-commits

Author: rengolin
Date: Thu Feb 11 15:22:57 2016
New Revision: 260595

URL: http://llvm.org/viewvc/llvm-project?rev=260595=rev
Log:
[AArch64] Fix libunwind build when using GNU assembler

Use x29 and x30 for fp and lr respectively.

This does not change the code generation with integrated asm
but using x30 and x29 helps compile the code with gnu as. Currently gas
fails to assemble this code with errors as below.

Error: operand X should be an integer register.

Newer versions of binutils should be fixed, but enough exists in the wild
to make this change harmless and worthy.

Patch by Khem Raj.

Modified:
libunwind/trunk/src/UnwindRegistersRestore.S
libunwind/trunk/src/UnwindRegistersSave.S

Modified: libunwind/trunk/src/UnwindRegistersRestore.S
URL: 
http://llvm.org/viewvc/llvm-project/libunwind/trunk/src/UnwindRegistersRestore.S?rev=260595=260594=260595=diff
==
--- libunwind/trunk/src/UnwindRegistersRestore.S (original)
+++ libunwind/trunk/src/UnwindRegistersRestore.S Thu Feb 11 15:22:57 2016
@@ -282,8 +282,8 @@ DEFINE_LIBUNWIND_PRIVATE_FUNCTION(_ZN9li
   ldpx22,x23, [x0, #0x0B0]
   ldpx24,x25, [x0, #0x0C0]
   ldpx26,x27, [x0, #0x0D0]
-  ldpx28,fp,  [x0, #0x0E0]
-  ldrlr,  [x0, #0x100]  // restore pc into lr
+  ldpx28,x29, [x0, #0x0E0]
+  ldrx30, [x0, #0x100]  // restore pc into lr
   ldrx1,  [x0, #0x0F8]
   movsp,x1  // restore sp
 
@@ -306,7 +306,7 @@ DEFINE_LIBUNWIND_PRIVATE_FUNCTION(_ZN9li
   ldrd31, [x0, #0x208]
 
   ldpx0, x1,  [x0, #0x000]  // restore x0,x1
-  retlr // jump to pc
+  retx30// jump to pc
 
 #elif defined(__arm__) && !defined(__APPLE__)
 

Modified: libunwind/trunk/src/UnwindRegistersSave.S
URL: 
http://llvm.org/viewvc/llvm-project/libunwind/trunk/src/UnwindRegistersSave.S?rev=260595=260594=260595=diff
==
--- libunwind/trunk/src/UnwindRegistersSave.S (original)
+++ libunwind/trunk/src/UnwindRegistersSave.S Thu Feb 11 15:22:57 2016
@@ -263,11 +263,11 @@ DEFINE_LIBUNWIND_FUNCTION(unw_getcontext
   stpx22,x23, [x0, #0x0B0]
   stpx24,x25, [x0, #0x0C0]
   stpx26,x27, [x0, #0x0D0]
-  stpx28,fp,  [x0, #0x0E0]
-  strlr,  [x0, #0x0F0]
+  stpx28,x29, [x0, #0x0E0]
+  strx30, [x0, #0x0F0]
   movx1,sp
   strx1,  [x0, #0x0F8]
-  strlr,  [x0, #0x100]// store return address as pc
+  strx30, [x0, #0x100]// store return address as pc
   // skip cpsr
   stpd0, d1,  [x0, #0x110]
   stpd2, d3,  [x0, #0x120]


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

Re: [PATCH] D16544: [libcxx] Framework to allow testing of static libc++abi

2016-02-11 Thread Ben Craig via cfe-commits

bcraig added inline comments.


Comment at: test/libcxx/test/config.py:469
@@ +468,3 @@
+if cxx_library_root:
+abs_path = cxx_library_root + "/libc++.a"
+self.cxx.link_flags += [abs_path]

EricWF wrote:
> Why not just wrap it in '-B,-static'?
I know exactly which binary I want to link against.  Running through the linker 
search path can't make this work better, but it can make it work worse.


Comment at: test/libcxx/test/target_info.py:173
@@ -164,2 +172,3 @@
 llvm_unwinder = self.full_config.get_lit_bool('llvm_unwinder', False)
+shared_libcxx = self.full_config.get_lit_bool('enable_shared', False)
 flags += ['-lm']

EricWF wrote:
> Hmm... this would have a different default compared to elsewhere after my 
> suggested edits.
When testing libcxx, it's going to be difficult to get an unset enable_shared, 
so the default doesn't matter that much in that situation.  It might matter 
more with libcxxabi.  I will investigate.

Regardless, I'm pretty sure "False" is the default here due to copy / paste 
rather than long, careful consideration.


http://reviews.llvm.org/D16544



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

Re: Patch for Bug 26283: float.h is missing mandatory C11 fp macros like DBL_DECIMAL_DIG and LDBL_DECIMAL_DIG