r264700 - [OPENMP] Allow runtime insert its own code inside OpenMP regions.

[Alexey Bataev via cfe-commits]

Author: abataev
Date: Tue Mar 29 00:34:15 2016
New Revision: 264700

URL: http://llvm.org/viewvc/llvm-project?rev=264700=rev
Log:
[OPENMP] Allow runtime insert its own code inside OpenMP regions.

Solution unifies interface of RegionCodeGenTy type to allow insert
runtime-specific code before/after main codegen action defined in
CGStmtOpenMP.cpp file. Runtime should not define its own RegionCodeGenTy
for general OpenMP directives, but must be allowed to insert its own
 (required) code to support target specific codegen.

Modified:
cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
cfe/trunk/lib/CodeGen/CGOpenMPRuntime.h
cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.h
cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp
cfe/trunk/lib/CodeGen/CodeGenFunction.h
cfe/trunk/test/OpenMP/critical_codegen.cpp
cfe/trunk/test/OpenMP/parallel_copyin_codegen.cpp
cfe/trunk/test/OpenMP/single_codegen.cpp
cfe/trunk/test/OpenMP/taskgroup_codegen.cpp

Modified: cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp?rev=264700=264699=264700=diff
==
--- cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp Tue Mar 29 00:34:15 2016
@@ -252,7 +252,7 @@ private:
   StringRef HelperName;
 };
 
-static void EmptyCodeGen(CodeGenFunction &) {
+static void EmptyCodeGen(CodeGenFunction &, PrePostActionTy &) {
   llvm_unreachable("No codegen for expressions");
 }
 /// \brief API for generation of expressions captured in a innermost OpenMP
@@ -564,8 +564,33 @@ enum OpenMPRTLFunction {
   OMPRTL__tgt_unregister_lib,
 };
 
+/// A basic class for pre|post-action for advanced codegen sequence for OpenMP
+/// region.
+class CleanupTy final : public EHScopeStack::Cleanup {
+  PrePostActionTy *Action;
+
+public:
+  explicit CleanupTy(PrePostActionTy *Action) : Action(Action) {}
+  void Emit(CodeGenFunction , Flags /*flags*/) override {
+if (!CGF.HaveInsertPoint())
+  return;
+Action->Exit(CGF);
+  }
+};
+
 } // anonymous namespace
 
+void RegionCodeGenTy::operator()(CodeGenFunction ) const {
+  CodeGenFunction::RunCleanupsScope Scope(CGF);
+  if (PrePostAction) {
+CGF.EHStack.pushCleanup(NormalAndEHCleanup, PrePostAction);
+Callback(CodeGen, CGF, *PrePostAction);
+  } else {
+PrePostActionTy Action;
+Callback(CodeGen, CGF, Action);
+  }
+}
+
 LValue CGOpenMPRegionInfo::getThreadIDVariableLValue(CodeGenFunction ) {
   return CGF.EmitLoadOfPointerLValue(
   CGF.GetAddrOfLocalVar(getThreadIDVariable()),
@@ -581,10 +606,7 @@ void CGOpenMPRegionInfo::EmitBody(CodeGe
   // The point of exit cannot be a branch out of the structured block.
   // longjmp() and throw() must not violate the entry/exit criteria.
   CGF.EHStack.pushTerminate();
-  {
-CodeGenFunction::RunCleanupsScope Scope(CGF);
-CodeGen(CGF);
-  }
+  CodeGen(CGF);
   CGF.EHStack.popTerminate();
 }
 
@@ -601,10 +623,6 @@ CGOpenMPRuntime::CGOpenMPRuntime(CodeGen
   "ident_t", CGM.Int32Ty /* reserved_1 */, CGM.Int32Ty /* flags */,
   CGM.Int32Ty /* reserved_2 */, CGM.Int32Ty /* reserved_3 */,
   CGM.Int8PtrTy /* psource */, nullptr);
-  // Build void (*kmpc_micro)(kmp_int32 *global_tid, kmp_int32 *bound_tid,...)
-  llvm::Type *MicroParams[] = {llvm::PointerType::getUnqual(CGM.Int32Ty),
-   llvm::PointerType::getUnqual(CGM.Int32Ty)};
-  Kmpc_MicroTy = llvm::FunctionType::get(CGM.VoidTy, MicroParams, true);
   KmpCriticalNameTy = llvm::ArrayType::get(CGM.Int32Ty, /*NumElements*/ 8);
 
   loadOffloadInfoMetadata();
@@ -896,10 +914,18 @@ void CGOpenMPRuntime::functionFinished(C
 }
 
 llvm::Type *CGOpenMPRuntime::getIdentTyPointerTy() {
+  if (!IdentTy) {
+  }
   return llvm::PointerType::getUnqual(IdentTy);
 }
 
 llvm::Type *CGOpenMPRuntime::getKmpc_MicroPointerTy() {
+  if (!Kmpc_MicroTy) {
+// Build void (*kmpc_micro)(kmp_int32 *global_tid, kmp_int32 
*bound_tid,...)
+llvm::Type *MicroParams[] = {llvm::PointerType::getUnqual(CGM.Int32Ty),
+ llvm::PointerType::getUnqual(CGM.Int32Ty)};
+Kmpc_MicroTy = llvm::FunctionType::get(CGM.VoidTy, MicroParams, true);
+  }
   return llvm::PointerType::getUnqual(Kmpc_MicroTy);
 }
 
@@ -1644,12 +1670,10 @@ static void emitOMPIfClause(CodeGenFunct
   // the condition and the dead arm of the if/else.
   bool CondConstant;
   if (CGF.ConstantFoldsToSimpleInteger(Cond, CondConstant)) {
-CodeGenFunction::RunCleanupsScope Scope(CGF);
-if (CondConstant) {
+if (CondConstant)
   ThenGen(CGF);
-} else {
+else
   ElseGen(CGF);
-}
 return;
   }
 
@@ -1662,26 +1686,16 @@ static void emitOMPIfClause(CodeGenFunct
 
   // Emit the 'then' code.
   CGF.EmitBlock(ThenBlock);
-  {
-CodeGenFunction::RunCleanupsScope ThenScope(CGF);
-ThenGen(CGF);
-  }
+  

Re: [PATCH] D18540: [Sema] Note when we've actually encountered a failure in ExprConstant, and take that into account when looking up objects.

[George Burgess IV via cfe-commits]

george.burgess.iv added inline comments.


Comment at: test/SemaCXX/constant-expression-cxx1y.cpp:182
@@ -181,4 +181,3 @@
 
-  // FIXME: We should be able to reject this before it's called
-  constexpr void f() {
+  constexpr void f() { // expected-error{{constexpr function never produces a 
constant expression}} expected-note@+2{{assignment to dereferenced 
one-past-the-end pointer is not allowed in a constant expression}}
 char foo[10] = { "z" }; // expected-note {{here}}

Aside: This test was fixed because we no longer give up on trying to look up 
`foo`, because we know an unmodeled side-effect hasn't happened.


http://reviews.llvm.org/D18540



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

[PATCH] D18540: [Sema] Note when we've actually encountered a failure in ExprConstant, and take that into account when looking up objects.

[George Burgess IV via cfe-commits]

george.burgess.iv created this revision.
george.burgess.iv added a reviewer: rsmith.
george.burgess.iv added a subscriber: cfe-commits.

This patch aims to fix a bug encountered by compiling code with C++14.

Specifically, when evaluating `p` in `__builtin_object_size(p, n)`, we start 
speculatively evaluating. Currently, clang pretends that side-effects have 
always occurred when we start speculatively evaluating. This prevents us from 
reading any locals in C++14. So, the following code compiles fine in C++11 
mode, but fails to compile with C++14:

```
void foo(char *p) __attribute__((enable_if(__builtin_object_size(p, 0) != -1, 
"")));

void runFoo() {
  char buf[5];
  foo(buf);
}
```

This patch makes ExprConstant note when we've actually failed (read: may have 
an unmodeled side-effect), and makes us act as conservatively before if a 
failure happened. If a failure hasn't happened, we can be more aggressive.

http://reviews.llvm.org/D18540

Files:
  include/clang/AST/Expr.h
  lib/AST/ExprConstant.cpp
  test/SemaCXX/builtin-object-size-cxx14.cpp
  test/SemaCXX/constant-expression-cxx1y.cpp

Index: test/SemaCXX/constant-expression-cxx1y.cpp
===
--- test/SemaCXX/constant-expression-cxx1y.cpp
+++ test/SemaCXX/constant-expression-cxx1y.cpp
@@ -179,12 +179,10 @@
   static_assert(!test1(100), "");
   static_assert(!test1(101), ""); // expected-error {{constant expression}} expected-note {{in call to 'test1(101)'}}
 
-  // FIXME: We should be able to reject this before it's called
-  constexpr void f() {
+  constexpr void f() { // expected-error{{constexpr function never produces a constant expression}} expected-note@+2{{assignment to dereferenced one-past-the-end pointer is not allowed in a constant expression}}
 char foo[10] = { "z" }; // expected-note {{here}}
-foo[10] = 'x'; // expected-warning {{past the end}} expected-note {{assignment to dereferenced one-past-the-end pointer}}
+foo[10] = 'x'; // expected-warning {{past the end}}
   }
-  constexpr int k = (f(), 0); // expected-error {{constant expression}} expected-note {{in call}}
 }
 
 namespace array_resize {
Index: test/SemaCXX/builtin-object-size-cxx14.cpp
===
--- /dev/null
+++ test/SemaCXX/builtin-object-size-cxx14.cpp
@@ -0,0 +1,99 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c++14 %s
+
+namespace basic {
+// Ensuring that __bos can be used in constexpr functions without anything
+// sketchy going on...
+constexpr int bos0() {
+  int k = 5;
+  char cs[10] = {};
+  return __builtin_object_size([k], 0);
+}
+
+constexpr int bos1() {
+  int k = 5;
+  char cs[10] = {};
+  return __builtin_object_size([k], 1);
+}
+
+constexpr int bos2() {
+  int k = 5;
+  char cs[10] = {};
+  return __builtin_object_size([k], 2);
+}
+
+constexpr int bos3() {
+  int k = 5;
+  char cs[10] = {};
+  return __builtin_object_size([k], 3);
+}
+
+static_assert(bos0() == sizeof(char) * 5, "");
+static_assert(bos1() == sizeof(char) * 5, "");
+static_assert(bos2() == sizeof(char) * 5, "");
+static_assert(bos3() == sizeof(char) * 5, "");
+}
+
+namespace in_enable_if {
+// The code that prompted these changes was __bos in enable_if
+
+void copy5CharsInto(char *buf) // expected-note{{candidate}}
+__attribute__((enable_if(__builtin_object_size(buf, 0) != -1 &&
+ __builtin_object_size(buf, 0) > 5,
+ "")));
+
+// We use different EvalModes for __bos with type 0 versus 1. Ensure 1 works,
+// too...
+void copy5CharsIntoStrict(char *buf) // expected-note{{candidate}}
+__attribute__((enable_if(__builtin_object_size(buf, 1) != -1 &&
+ __builtin_object_size(buf, 1) > 5,
+ "")));
+
+struct LargeStruct {
+  int pad;
+  char buf[6];
+  int pad2;
+};
+
+struct SmallStruct {
+  int pad;
+  char buf[5];
+  int pad2;
+};
+
+void noWriteToBuf() {
+  char buf[6];
+  copy5CharsInto(buf);
+
+  LargeStruct large;
+  copy5CharsIntoStrict(large.buf);
+}
+
+void initTheBuf() {
+  char buf[6] = {};
+  copy5CharsInto(buf);
+
+  LargeStruct large = {0, {}, 0};
+  copy5CharsIntoStrict(large.buf);
+}
+
+int getI();
+void initTheBufWithALoop() {
+  char buf[6] = {};
+  for (unsigned I = getI(); I != sizeof(buf); ++I)
+buf[I] = I;
+  copy5CharsInto(buf);
+
+  LargeStruct large;
+  for (unsigned I = getI(); I != sizeof(buf); ++I)
+large.buf[I] = I;
+  copy5CharsIntoStrict(large.buf);
+}
+
+void tooSmallBuf() {
+  char buf[5];
+  copy5CharsInto(buf); // expected-error{{no matching function for call}}
+
+  SmallStruct small;
+  copy5CharsIntoStrict(small.buf); // expected-error{{no matching function for call}}
+}
+}
Index: lib/AST/ExprConstant.cpp
===
--- lib/AST/ExprConstant.cpp
+++ lib/AST/ExprConstant.cpp
@@ -478,6 +478,9 @@
 /// fold (not just why it's not strictly a 

Re: [PATCH] D18380: [CUDA] Make unattributed constexpr functions (usually) implicitly host+device.

[Justin Lebar via cfe-commits]

jlebar added a comment.

In http://reviews.llvm.org/D18380#385240, @tra wrote:

> What if instead of permanently sticking HD attributes on the constexpr 
> function, we instead postpone decision to the point of overload resolution 
> and figure out effective attributes or call preference based on contents of 
> the whole overload set regardless of the order the decls were added to the 
> set.


The problem we were trying to prevent by requiring that the __device__ overload 
come first is:

  constexpr int foo();
  __device__ void bar() { foo(); }
  __device__ int foo();
  __device__ void baz() { foo(); }

In this example, we're forced to instantiate both versions of foo() on the 
device.  Being lazy about making the first foo HD doesn't help, because at the 
time we see bar, it's the only option available.

(Instantiating both foos is a problem if they have the same mangling.  And we 
want them to have the same mangling so we maintain ABI compatibility with nvcc.)


http://reviews.llvm.org/D18380



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

Re: [PATCH] D17491: Add performance check to flag function parameters of expensive to copy types that can be safely converted to const references.

[Richard via cfe-commits]

LegalizeAdulthood added a subscriber: LegalizeAdulthood.
LegalizeAdulthood added a comment.

Can you add something to the docs/ReleaseNotes.rst for this new check, please?


Repository:
  rL LLVM

http://reviews.llvm.org/D17491



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

Re: [PATCH] D17482: [clang-tidy] Allow tests to verify changes made to header files

[Richard via cfe-commits]

LegalizeAdulthood added a comment.

Squeak


http://reviews.llvm.org/D17482



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

Re: [PATCH] D12761: MPI-Checker patch for Clang Static Analyzer

[Anna Zaks via cfe-commits]

zaks.anna added inline comments.


Comment at: test/Analysis/MPIChecker.cpp:98
@@ +97,3 @@
+
+  MPI_Request req;
+  MPI_Ireduce(MPI_IN_PLACE, , 1, MPI_DOUBLE, MPI_SUM, 0, MPI_COMM_WORLD, 
); // expected-note{{Request is previously used by nonblocking call here.}}

Do you see the notes in the report? I think you should pass 
"-analyzer-output=text" to see the notes.


http://reviews.llvm.org/D12761



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

Re: [PATCH] D17491: Add performance check to flag function parameters of expensive to copy types that can be safely converted to const references.

[Felix Berger via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL264694: [clang-tidy] Add performance check to flag function 
parameters of expensive… (authored by flx).

Changed prior to commit:
  http://reviews.llvm.org/D17491?vs=51385=51869#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D17491

Files:
  clang-tools-extra/trunk/clang-tidy/performance/CMakeLists.txt
  clang-tools-extra/trunk/clang-tidy/performance/PerformanceTidyModule.cpp
  clang-tools-extra/trunk/clang-tidy/performance/UnnecessaryValueParamCheck.cpp
  clang-tools-extra/trunk/clang-tidy/performance/UnnecessaryValueParamCheck.h
  clang-tools-extra/trunk/docs/clang-tidy/checks/list.rst
  
clang-tools-extra/trunk/docs/clang-tidy/checks/performance-unnecessary-value-param.rst
  
clang-tools-extra/trunk/test/clang-tidy/performance-unnecessary-value-param.cpp

Index: clang-tools-extra/trunk/test/clang-tidy/performance-unnecessary-value-param.cpp
===
--- clang-tools-extra/trunk/test/clang-tidy/performance-unnecessary-value-param.cpp
+++ clang-tools-extra/trunk/test/clang-tidy/performance-unnecessary-value-param.cpp
@@ -0,0 +1,171 @@
+// RUN: %check_clang_tidy %s performance-unnecessary-value-param %t
+
+struct ExpensiveToCopyType {
+  const ExpensiveToCopyType & constReference() const {
+return *this;
+  }
+  void nonConstMethod();
+  virtual ~ExpensiveToCopyType();
+};
+
+void mutate(ExpensiveToCopyType &);
+void mutate(ExpensiveToCopyType *);
+void useAsConstReference(const ExpensiveToCopyType &);
+void useByValue(ExpensiveToCopyType);
+
+// This class simulates std::pair<>. It is trivially copy constructible
+// and trivially destructible, but not trivially copy assignable.
+class SomewhatTrivial {
+ public:
+  SomewhatTrivial();
+  SomewhatTrivial(const SomewhatTrivial&) = default;
+  ~SomewhatTrivial() = default;
+  SomewhatTrivial& operator=(const SomewhatTrivial&);
+};
+
+void positiveExpensiveConstValue(const ExpensiveToCopyType Obj);
+// CHECK-FIXES: void positiveExpensiveConstValue(const ExpensiveToCopyType& Obj);
+void positiveExpensiveConstValue(const ExpensiveToCopyType Obj) {
+  // CHECK-MESSAGES: [[@LINE-1]]:60: warning: the const qualified parameter 'Obj' is copied for each invocation; consider making it a reference [performance-unnecessary-value-param]
+  // CHECK-FIXES: void positiveExpensiveConstValue(const ExpensiveToCopyType& Obj) {
+}
+
+void positiveExpensiveValue(ExpensiveToCopyType Obj);
+// CHECK-FIXES: void positiveExpensiveValue(const ExpensiveToCopyType& Obj);
+void positiveExpensiveValue(ExpensiveToCopyType Obj) {
+  // CHECK-MESSAGES: [[@LINE-1]]:49: warning: the parameter 'Obj' is copied for each invocation but only used as a const reference; consider making it a const reference [performance-unnecessary-value-param]
+  // CHECK-FIXES: void positiveExpensiveValue(const ExpensiveToCopyType& Obj) {
+  Obj.constReference();
+  useAsConstReference(Obj);
+  auto Copy = Obj;
+  useByValue(Obj);
+}
+
+void positiveWithComment(const ExpensiveToCopyType /* important */ S);
+// CHECK-FIXES: void positiveWithComment(const ExpensiveToCopyType& /* important */ S);
+void positiveWithComment(const ExpensiveToCopyType /* important */ S) {
+  // CHECK-MESSAGES: [[@LINE-1]]:68: warning: the const qualified
+  // CHECK-FIXES: void positiveWithComment(const ExpensiveToCopyType& /* important */ S) {
+}
+
+void positiveUnnamedParam(const ExpensiveToCopyType) {
+  // CHECK-MESSAGES: [[@LINE-1]]:52: warning: the const qualified parameter #1
+  // CHECK-FIXES: void positiveUnnamedParam(const ExpensiveToCopyType&) {
+}
+
+void positiveAndNegative(const ExpensiveToCopyType ConstCopy, const ExpensiveToCopyType& ConstRef, ExpensiveToCopyType Copy);
+// CHECK-FIXES: void positiveAndNegative(const ExpensiveToCopyType& ConstCopy, const ExpensiveToCopyType& ConstRef, const ExpensiveToCopyType& Copy);
+void positiveAndNegative(const ExpensiveToCopyType ConstCopy, const ExpensiveToCopyType& ConstRef, ExpensiveToCopyType Copy) {
+  // CHECK-MESSAGES: [[@LINE-1]]:52: warning: the const qualified parameter 'ConstCopy'
+  // CHECK-MESSAGES: [[@LINE-2]]:120: warning: the parameter 'Copy'
+  // CHECK-FIXES: void positiveAndNegative(const ExpensiveToCopyType& ConstCopy, const ExpensiveToCopyType& ConstRef, const ExpensiveToCopyType& Copy) {
+}
+
+struct PositiveConstValueConstructor {
+  PositiveConstValueConstructor(const ExpensiveToCopyType ConstCopy) {}
+  // CHECK-MESSAGES: [[@LINE-1]]:59: warning: the const qualified parameter 'ConstCopy'
+};
+
+template  void templateWithNonTemplatizedParameter(const ExpensiveToCopyType S, T V) {
+  // CHECK-MESSAGES: [[@LINE-1]]:90: warning: the const qualified parameter 'S'
+  // CHECK-FIXES: template  void templateWithNonTemplatizedParameter(const ExpensiveToCopyType& S, T V) {
+}
+
+void instantiated() {
+  templateWithNonTemplatizedParameter(ExpensiveToCopyType(), ExpensiveToCopyType());
+  

[clang-tools-extra] r264694 - [clang-tidy] Add performance check to flag function parameters of expensive to copy types that can be safely converted to const references.

[Felix Berger via cfe-commits]

Author: flx
Date: Mon Mar 28 21:42:38 2016
New Revision: 264694

URL: http://llvm.org/viewvc/llvm-project?rev=264694=rev
Log:
[clang-tidy] Add performance check to flag function parameters of expensive to 
copy types that can be safely converted to const references.

Reviewers: alexfh

Subscribers: fowles, cfe-commits

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

Added:

clang-tools-extra/trunk/clang-tidy/performance/UnnecessaryValueParamCheck.cpp
clang-tools-extra/trunk/clang-tidy/performance/UnnecessaryValueParamCheck.h

clang-tools-extra/trunk/docs/clang-tidy/checks/performance-unnecessary-value-param.rst

clang-tools-extra/trunk/test/clang-tidy/performance-unnecessary-value-param.cpp
Modified:
clang-tools-extra/trunk/clang-tidy/performance/CMakeLists.txt
clang-tools-extra/trunk/clang-tidy/performance/PerformanceTidyModule.cpp
clang-tools-extra/trunk/docs/clang-tidy/checks/list.rst

Modified: clang-tools-extra/trunk/clang-tidy/performance/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/performance/CMakeLists.txt?rev=264694=264693=264694=diff
==
--- clang-tools-extra/trunk/clang-tidy/performance/CMakeLists.txt (original)
+++ clang-tools-extra/trunk/clang-tidy/performance/CMakeLists.txt Mon Mar 28 
21:42:38 2016
@@ -6,6 +6,7 @@ add_clang_library(clangTidyPerformanceMo
   ImplicitCastInLoopCheck.cpp
   PerformanceTidyModule.cpp
   UnnecessaryCopyInitialization.cpp
+  UnnecessaryValueParamCheck.cpp
 
   LINK_LIBS
   clangAST

Modified: 
clang-tools-extra/trunk/clang-tidy/performance/PerformanceTidyModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/performance/PerformanceTidyModule.cpp?rev=264694=264693=264694=diff
==
--- clang-tools-extra/trunk/clang-tidy/performance/PerformanceTidyModule.cpp 
(original)
+++ clang-tools-extra/trunk/clang-tidy/performance/PerformanceTidyModule.cpp 
Mon Mar 28 21:42:38 2016
@@ -15,6 +15,7 @@
 #include "ForRangeCopyCheck.h"
 #include "ImplicitCastInLoopCheck.h"
 #include "UnnecessaryCopyInitialization.h"
+#include "UnnecessaryValueParamCheck.h"
 
 namespace clang {
 namespace tidy {
@@ -31,6 +32,8 @@ public:
 "performance-implicit-cast-in-loop");
 CheckFactories.registerCheck(
 "performance-unnecessary-copy-initialization");
+CheckFactories.registerCheck(
+"performance-unnecessary-value-param");
   }
 };
 

Added: 
clang-tools-extra/trunk/clang-tidy/performance/UnnecessaryValueParamCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/performance/UnnecessaryValueParamCheck.cpp?rev=264694=auto
==
--- 
clang-tools-extra/trunk/clang-tidy/performance/UnnecessaryValueParamCheck.cpp 
(added)
+++ 
clang-tools-extra/trunk/clang-tidy/performance/UnnecessaryValueParamCheck.cpp 
Mon Mar 28 21:42:38 2016
@@ -0,0 +1,87 @@
+//===--- UnnecessaryValueParamCheck.cpp - 
clang-tidy---===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "UnnecessaryValueParamCheck.h"
+
+#include "../utils/DeclRefExprUtils.h"
+#include "../utils/FixItHintUtils.h"
+#include "../utils/Matchers.h"
+
+using namespace clang::ast_matchers;
+
+namespace clang {
+namespace tidy {
+namespace performance {
+
+namespace {
+
+std::string paramNameOrIndex(StringRef Name, size_t Index) {
+  return (Name.empty() ? llvm::Twine('#') + llvm::Twine(Index + 1)
+   : llvm::Twine('\'') + Name + llvm::Twine('\''))
+  .str();
+}
+
+} // namespace
+
+void UnnecessaryValueParamCheck::registerMatchers(MatchFinder *Finder) {
+  const auto ExpensiveValueParamDecl =
+  parmVarDecl(hasType(hasCanonicalType(allOf(matchers::isExpensiveToCopy(),
+ unless(referenceType(),
+  decl().bind("param"));
+  Finder->addMatcher(
+  functionDecl(isDefinition(), unless(cxxMethodDecl(isOverride())),
+   unless(isInstantiated()),
+   has(typeLoc(forEach(ExpensiveValueParamDecl))),
+   decl().bind("functionDecl")),
+  this);
+}
+
+void UnnecessaryValueParamCheck::check(const MatchFinder::MatchResult ) 
{
+  const auto *Param = Result.Nodes.getNodeAs("param");
+  const auto *Function = Result.Nodes.getNodeAs("functionDecl");
+  const size_t Index = std::find(Function->parameters().begin(),
+ Function->parameters().end(), Param) -
+   Function->parameters().begin();
+  bool IsConstQualified =
+  

Re: [PATCH] D18380: [CUDA] Make unattributed constexpr functions (usually) implicitly host+device.

[Artem Belevich via cfe-commits]

tra added a comment.

I wonder if we can find a way to decide whether particular constexpr function 
should be treated as HD or not without relying on particular order the 
functions are seen by compiler (or whether they come from system headers).

Right now we're relying on checking overloads of constexpr's function decl once 
and applying HD attributes based on state of overload set at the point in TU. 
We then use those attributes during overload resolution.

What if instead of permanently sticking HD attributes on the constexpr 
function, we instead postpone decision to the point of overload resolution and 
figure out effective attributes or call preference based on contents of the 
whole overload set regardless of the order the decls were added to the set.



Comment at: test/SemaCUDA/host-device-constexpr.cu:30-31
@@ +29,4 @@
+namespace ns {
+// The "using" statement in overload.h should this OverloadMe from being
+// implicitly host+device.
+constexpr HostReturnTy OverloadMe() { return HostReturnTy(); }

"should prevent this"


http://reviews.llvm.org/D18380



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

Re: [PATCH] D17407: [Sema] PR25755 Fix crash when initializing out-of-order struct references

[don hinton via cfe-commits]

hintonda added inline comments.


Comment at: lib/Sema/SemaInit.cpp:1926-1927
@@ +1925,4 @@
+  assert(Field != FieldEnd);
+  if (SeenFields[i])
+continue;
+  if (!Field->isUnnamedBitfield() && !Field->hasInClassInitializer() &&

rsmith wrote:
> Use `SeenFields[Field->getFieldIndex()]` here and then remove the variable 
> `i`. We don't need to hardcode assumptions about how field indexes are 
> computed here.
You raise a good point I missed.  SeenFields should be big enough to mark all 
fields, but we should only set/examine from FieldStart->getFieldIndex().  
However, we still need the i.


http://reviews.llvm.org/D17407



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

Re: [PATCH] D18380: [CUDA] Make unattributed constexpr functions (usually) implicitly host+device.

[Justin Lebar via cfe-commits]

jlebar updated this revision to Diff 51868.
jlebar added a comment.

Update per changes to patch description.  Now a constexpr becomes implicitly HD
unless there's a preceeding __device__ overload.


http://reviews.llvm.org/D18380

Files:
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Basic/LangOptions.def
  include/clang/Driver/CC1Options.td
  include/clang/Sema/Sema.h
  lib/Frontend/CompilerInvocation.cpp
  lib/Sema/SemaCUDA.cpp
  lib/Sema/SemaDecl.cpp
  lib/Sema/SemaOverload.cpp
  test/SemaCUDA/Inputs/overload.h
  test/SemaCUDA/host-device-constexpr.cu
  test/SemaCUDA/no-host-device-constexpr.cu

Index: test/SemaCUDA/no-host-device-constexpr.cu
===
--- /dev/null
+++ test/SemaCUDA/no-host-device-constexpr.cu
@@ -0,0 +1,20 @@
+// RUN: %clang_cc1 -std=c++11 -fsyntax-only -fno-cuda-host-device-constexpr -verify %s
+// RUN: %clang_cc1 -std=c++11 -fsyntax-only -fno-cuda-host-device-constexpr -fcuda-is-device -verify %s
+
+#include "Inputs/cuda.h"
+
+// Check that, with -fno-cuda-host-device-constexpr, constexpr functions are
+// host-only, and __device__ constexpr functions are still device-only.
+
+constexpr int f() { return 0; } // expected-note {{not viable}}
+__device__ constexpr int g() { return 0; } // expected-note {{not viable}}
+
+void __device__ foo() {
+  f(); // expected-error {{no matching function}}
+  g();
+}
+
+void __host__ foo() {
+  f();
+  g(); // expected-error {{no matching function}}
+}
Index: test/SemaCUDA/host-device-constexpr.cu
===
--- /dev/null
+++ test/SemaCUDA/host-device-constexpr.cu
@@ -0,0 +1,69 @@
+// RUN: %clang_cc1 -std=c++11 -fsyntax-only -verify -isystem %S/Inputs %s
+// RUN: %clang_cc1 -std=c++11 -fsyntax-only -verify -isystem %S/Inputs %s -fcuda-is-device
+
+#include "Inputs/cuda.h"
+
+// Declares one function and pulls it into namespace ns:
+//
+//   __device__ int OverloadMe();
+//   namespace ns { using ::OverloadMe; }
+//
+// Clang cares that this is done in a system header.
+#include 
+
+// Opaque type used to determine which overload we're invoking.
+struct HostReturnTy {};
+
+// These shouldn't become host+device because they already have attributes.
+__host__ constexpr int HostOnly() { return 0; }
+// expected-note@-1 0+ {{not viable}}
+__device__ constexpr int DeviceOnly() { return 0; }
+// expected-note@-1 0+ {{not viable}}
+
+constexpr int HostDevice() { return 0; }
+
+// This should be a host-only function, because there's a previous __device__
+// overload in .
+constexpr HostReturnTy OverloadMe() { return HostReturnTy(); }
+
+namespace ns {
+// The "using" statement in overload.h should this OverloadMe from being
+// implicitly host+device.
+constexpr HostReturnTy OverloadMe() { return HostReturnTy(); }
+}  // namespace ns
+
+// This is an error, because NonSysHdrOverload was not defined in a system
+// header.
+__device__ int NonSysHdrOverload() { return 0; }
+// expected-note@-1 {{conflicting __device__ function declared here}}
+constexpr int NonSysHdrOverload() { return 0; }
+// expected-error@-1 {{constexpr function 'NonSysHdrOverload' without __host__ or __device__ attributes}}
+
+// Variadic device functions are not allowed, so this is just treated as
+// host-only.
+constexpr void Variadic(const char*, ...);
+// expected-note@-1 {{call to __host__ function from __device__ function}}
+
+__host__ void HostFn() {
+  HostOnly();
+  DeviceOnly(); // expected-error {{no matching function}}
+  HostReturnTy x = OverloadMe();
+  HostReturnTy y = ns::OverloadMe();
+  Variadic("abc", 42);
+}
+
+__device__ void DeviceFn() {
+  HostOnly(); // expected-error {{no matching function}}
+  DeviceOnly();
+  int x = OverloadMe();
+  int y = ns::OverloadMe();
+  Variadic("abc", 42); // expected-error {{no matching function}}
+}
+
+__host__ __device__ void HostDeviceFn() {
+#ifdef __CUDA_ARCH__
+  int y = OverloadMe();
+#else
+  constexpr HostReturnTy y = OverloadMe();
+#endif
+}
Index: test/SemaCUDA/Inputs/overload.h
===
--- /dev/null
+++ test/SemaCUDA/Inputs/overload.h
@@ -0,0 +1,8 @@
+// This header is used by tests which are interested in __device__ functions
+// which appear in a system header.
+
+__device__ int OverloadMe();
+
+namespace ns {
+using ::OverloadMe;
+}
Index: lib/Sema/SemaOverload.cpp
===
--- lib/Sema/SemaOverload.cpp
+++ lib/Sema/SemaOverload.cpp
@@ -985,7 +985,7 @@
 }
 
 bool Sema::IsOverload(FunctionDecl *New, FunctionDecl *Old,
-  bool UseMemberUsingDeclRules) {
+  bool UseMemberUsingDeclRules, bool ConsiderCudaAttrs) {
   // C++ [basic.start.main]p2: This function shall not be overloaded.
   if (New->isMain())
 return false;
@@ -1118,7 +1118,7 @@
   return true;
   }
 
-  if (getLangOpts().CUDA) {
+  if (getLangOpts().CUDA && 

Re: [PATCH] D18380: [CUDA] Make unattributed constexpr functions (usually) implicitly host+device.

[Justin Lebar via cfe-commits]

jlebar added a comment.

Updated as discussed -- please have a look.


http://reviews.llvm.org/D18380



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

[PATCH] D18539: [CUDA] Add math forward declares.

[Justin Lebar via cfe-commits]

jlebar created this revision.
jlebar added reviewers: rnk, rsmith, tra.
jlebar added a subscriber: cfe-commits.

This is necessary for a future patch which will make all constexpr
functions implicitly host+device.  cmath may declare constexpr
functions, but these we do *not* want to be host+device.  The forward
declares added in this patch prevent this (because the rule will be,
constexpr functions become implicitly host+device unless they're
preceeded by a decl with __device__).

http://reviews.llvm.org/D18539

Files:
  lib/Headers/CMakeLists.txt
  lib/Headers/__clang_cuda_math_forward_declares.h
  lib/Headers/__clang_cuda_runtime_wrapper.h

Index: lib/Headers/__clang_cuda_runtime_wrapper.h
===
--- lib/Headers/__clang_cuda_runtime_wrapper.h
+++ lib/Headers/__clang_cuda_runtime_wrapper.h
@@ -42,6 +42,9 @@
 
 #if defined(__CUDA__) && defined(__clang__)
 
+// Include some forward declares that must come before cmath.
+#include <__clang_cuda_cmath.h>
+
 // Include some standard headers to avoid CUDA headers including them
 // while some required macros (like __THROW) are in a weird state.
 #include 
Index: lib/Headers/__clang_cuda_math_forward_declares.h
===
--- /dev/null
+++ lib/Headers/__clang_cuda_math_forward_declares.h
@@ -0,0 +1,191 @@
+/*=== __clang_cuda_cmath.h - Device-side CUDA cmath support ===
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ *
+ *===---===
+ */
+#ifndef __CLANG__CUDA_MATH_FORWARD_DECLARES_H__
+#define __CLANG__CUDA_MATH_FORWARD_DECLARES_H__
+#ifndef __CUDA__
+#error "This file is for CUDA compilation only."
+#endif
+
+// This file forward-declares of some math functions we (or the CUDA headers)
+// will define later.  We need to do this, and do it before cmath is included,
+// because the standard library may have constexpr math functions.  In the
+// absence of a prior __device__ decl, those constexpr functions may become
+// implicitly host+device.  host+device functions can't be overloaded, so that
+// would preclude the use of our own __device__ overloads for these functions.
+
+#pragma push_macro("__DEVICE__")
+#define __DEVICE__ \
+  static __inline__ __attribute__((always_inline)) __attribute__((device))
+
+__DEVICE__ int abs(int);
+__DEVICE__ double acos(double);
+__DEVICE__ float acosh(float);
+__DEVICE__ double acosh(double);
+__DEVICE__ double asin(double);
+__DEVICE__ float asinh(float);
+__DEVICE__ double asinh(double);
+__DEVICE__ double atan(double);
+__DEVICE__ double atan2(double, double);
+__DEVICE__ float atanh(float);
+__DEVICE__ double atanh(double);
+__DEVICE__ float cbrt(float);
+__DEVICE__ double cbrt(double);
+__DEVICE__ double ceil(double);
+__DEVICE__ float copysign(float, float);
+__DEVICE__ double copysign(double, double);
+__DEVICE__ double cos(double);
+__DEVICE__ double cosh(double);
+__DEVICE__ float erf(float);
+__DEVICE__ double erf(double);
+__DEVICE__ float erfc(float);
+__DEVICE__ double erfc(double);
+__DEVICE__ double exp(double);
+__DEVICE__ float exp2(float);
+__DEVICE__ double exp2(double);
+__DEVICE__ float expm1(float);
+__DEVICE__ double expm1(double);
+__DEVICE__ double fabs(double);
+__DEVICE__ float fdim(float, float);
+__DEVICE__ double fdim(double, double);
+__DEVICE__ double floor(double);
+__DEVICE__ float fma(float, float, float);
+__DEVICE__ double fma(double, double, double);
+__DEVICE__ float fmax(float, float);
+__DEVICE__ double fmax(double, double);
+__DEVICE__ float fmin(float, float);
+__DEVICE__ double fmin(double, double);
+__DEVICE__ double fmod(double, double);
+__DEVICE__ double frexp(double, int *);
+__DEVICE__ float hypot(float, float);
+__DEVICE__ double hypot(double, double);
+__DEVICE__ int ilogb(float);
+__DEVICE__ 

[PATCH] D18538: [Sema] s/UseUsingDeclRules/UseMemberUsingDeclRules/

[Justin Lebar via cfe-commits]

jlebar created this revision.
jlebar added a reviewer: rsmith.
jlebar added a subscriber: cfe-commits.

IsOverload has a param named UseUsingDeclRules.  But as far as I can
tell, it should be called UseMemberUsingDeclRules.  That is, it only
applies to "using" declarations inside classes or structs.

http://reviews.llvm.org/D18538

Files:
  lib/Sema/SemaOverload.cpp

Index: lib/Sema/SemaOverload.cpp
===
--- lib/Sema/SemaOverload.cpp
+++ lib/Sema/SemaOverload.cpp
@@ -985,7 +985,7 @@
 }
 
 bool Sema::IsOverload(FunctionDecl *New, FunctionDecl *Old,
-  bool UseUsingDeclRules) {
+  bool UseMemberUsingDeclRules) {
   // C++ [basic.start.main]p2: This function shall not be overloaded.
   if (New->isMain())
 return false;
@@ -1041,7 +1041,7 @@
   //
   // However, we don't consider either of these when deciding whether
   // a member introduced by a shadow declaration is hidden.
-  if (!UseUsingDeclRules && NewTemplate &&
+  if (!UseMemberUsingDeclRules && NewTemplate &&
   (!TemplateParameterListsAreEqual(NewTemplate->getTemplateParameters(),
OldTemplate->getTemplateParameters(),
false, TPL_TemplateMatch) ||
@@ -1061,7 +1061,7 @@
   if (OldMethod && NewMethod &&
   !OldMethod->isStatic() && !NewMethod->isStatic()) {
 if (OldMethod->getRefQualifier() != NewMethod->getRefQualifier()) {
-  if (!UseUsingDeclRules &&
+  if (!UseMemberUsingDeclRules &&
   (OldMethod->getRefQualifier() == RQ_None ||
NewMethod->getRefQualifier() == RQ_None)) {
 // C++0x [over.load]p2:


Index: lib/Sema/SemaOverload.cpp
===
--- lib/Sema/SemaOverload.cpp
+++ lib/Sema/SemaOverload.cpp
@@ -985,7 +985,7 @@
 }
 
 bool Sema::IsOverload(FunctionDecl *New, FunctionDecl *Old,
-  bool UseUsingDeclRules) {
+  bool UseMemberUsingDeclRules) {
   // C++ [basic.start.main]p2: This function shall not be overloaded.
   if (New->isMain())
 return false;
@@ -1041,7 +1041,7 @@
   //
   // However, we don't consider either of these when deciding whether
   // a member introduced by a shadow declaration is hidden.
-  if (!UseUsingDeclRules && NewTemplate &&
+  if (!UseMemberUsingDeclRules && NewTemplate &&
   (!TemplateParameterListsAreEqual(NewTemplate->getTemplateParameters(),
OldTemplate->getTemplateParameters(),
false, TPL_TemplateMatch) ||
@@ -1061,7 +1061,7 @@
   if (OldMethod && NewMethod &&
   !OldMethod->isStatic() && !NewMethod->isStatic()) {
 if (OldMethod->getRefQualifier() != NewMethod->getRefQualifier()) {
-  if (!UseUsingDeclRules &&
+  if (!UseMemberUsingDeclRules &&
   (OldMethod->getRefQualifier() == RQ_None ||
NewMethod->getRefQualifier() == RQ_None)) {
 // C++0x [over.load]p2:
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D18458: [CUDA] Mangle __host__ __device__ functions differently than __host__ or __device__ functions.

[Justin Lebar via cfe-commits]

jlebar abandoned this revision.
jlebar added a comment.

New plan, R2: Let nvcc win.

After much discussion, we're abandoning this because we want to maintain abi 
compatibility with nvcc.  I'm about to upload a revised approach to 
http://reviews.llvm.org/D18380 that won't require this.


http://reviews.llvm.org/D18458



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

Re: [PATCH] D17407: [Sema] PR25755 Fix crash when initializing out-of-order struct references

[don hinton via cfe-commits]

hintonda added a comment.

I'm probably missing something, but isn't 
InitListChecker::CheckStructUnionTypes() called recursively, if indirectly?  In 
which case we'd want to start from the Field iterator we were given, not the 
look at all the fields.


http://reviews.llvm.org/D17407



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

Re: [PATCH] D18296: [Sema] Handle UTF-8 invalid format string specifiers

[Richard Smith via cfe-commits]

rsmith accepted this revision.
This revision is now accepted and ready to land.


Comment at: lib/Analysis/FormatString.cpp:276
@@ +275,3 @@
+  // UTF-8 sequence. If that's the case, adjust the length accordingly.
+  if (llvm::sys::locale::isPrint(FirstByte))
+return false;

How about using `getNumBytesForUTF8(FirstByte) != 1` here?


Comment at: lib/Analysis/FormatString.cpp:278
@@ +277,3 @@
+return false;
+  if (!isLegalUTF8String(, SE))
+return false;

Perhaps only check `,  + Len` -- it doesn't seem problematic if there's 
some non-UTF8 data after the specifier.


http://reviews.llvm.org/D18296



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

Re: [PATCH] D17407: [Sema] PR25755 Fix crash when initializing out-of-order struct references

[Richard Smith via cfe-commits]

rsmith added inline comments.


Comment at: lib/Sema/SemaInit.cpp:1818-1823
@@ +1817,8 @@
+  RecordDecl::field_iterator FieldStart = Field;
+  unsigned FieldSize = [FieldStart, FieldEnd]() mutable -> unsigned {
+unsigned i = 0;
+for (; FieldStart != FieldEnd; ++FieldStart, ++i)
+  /*empty*/;
+return i;
+  }();
+  llvm::BitVector SeenFields(FieldSize);

`FieldStart` isn't necessarily the first field (in particular, if we got here 
from a nested field designator). Instead, how about using

  FieldSize = std::distance(RD->field_begin(), RD->field_end());


Comment at: lib/Sema/SemaInit.cpp:1922
@@ +1921,3 @@
+  if (VerifyOnly && !DeclType->isUnionType() &&
+  (Field != FieldEnd || !CheckForMissingFields)) {
+Field = FieldStart;

The `CheckForMissingFields` test here doesn't make much sense with this name. 
Please reverse the sense of this flag, rename it to `HadAnyDesignators` or 
similar, and initialize it to `true` if `Field != RD->field_begin()` before you 
enter the field initialization loop.


Comment at: lib/Sema/SemaInit.cpp:1923
@@ +1922,3 @@
+  (Field != FieldEnd || !CheckForMissingFields)) {
+Field = FieldStart;
+for (unsigned i = 0; i < FieldSize && !hadError; ++i, ++Field) {

Start from `RD->field_begin()` here (or track the position at which you first 
set `HadAnyDesignators` to `true` and start from there). In particular, if 
`FieldStart != RD->field_begin()`, then an initial sequence of fields is 
uninitialized unless a later designator jumped back to them.


Comment at: lib/Sema/SemaInit.cpp:1926-1927
@@ +1925,4 @@
+  assert(Field != FieldEnd);
+  if (SeenFields[i])
+continue;
+  if (!Field->isUnnamedBitfield() && !Field->hasInClassInitializer() &&

Use `SeenFields[Field->getFieldIndex()]` here and then remove the variable `i`. 
We don't need to hardcode assumptions about how field indexes are computed here.


http://reviews.llvm.org/D17407



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

Re: [PATCH] D16749: [OpenMP] Map clause codegeneration.

[Samuel Antao via cfe-commits]

sfantao added a comment.

Ping!


http://reviews.llvm.org/D16749



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

Re: [PATCH] D18110: [OpenMP] Fix SEMA bug in the capture of global variables in template functions.

[Samuel Antao via cfe-commits]

sfantao added a comment.

Ping!


http://reviews.llvm.org/D18110



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

Re: [PATCH] D17407: [Sema] PR25755 Fix crash when initializing out-of-order struct references

[don hinton via cfe-commits]

hintonda marked 7 inline comments as done.


Comment at: lib/Sema/SemaInit.cpp:1815-1816
@@ -1814,3 +1814,4 @@
   // worthwhile to skip over the rest of the initializer, though.
   RecordDecl *RD = DeclType->getAs()->getDecl();
   RecordDecl::field_iterator FieldEnd = RD->field_end();
+  RecordDecl::field_iterator FieldStart = Field;

Still need FieldSize -- see below.


Comment at: lib/Sema/SemaInit.cpp:1856
@@ -1843,3 +1855,3 @@
 
 if (Field == FieldEnd) {
   // We've run out of fields. We're done.

Couldn't find getNumFields(), counted them instead.


http://reviews.llvm.org/D17407



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

Re: [PATCH] D18296: [Sema] Handle UTF-8 invalid format string specifiers

[Bruno Cardoso Lopes via cfe-commits]

bruno updated this revision to Diff 51859.
bruno added a comment.

Update after Richard's review.

- Handle scanf
- Properly update `ConversionSpecifier`


http://reviews.llvm.org/D18296

Files:
  include/clang/Analysis/Analyses/FormatString.h
  lib/Analysis/FormatString.cpp
  lib/Analysis/FormatStringParsing.h
  lib/Analysis/PrintfFormatString.cpp
  lib/Analysis/ScanfFormatString.cpp
  lib/Sema/SemaChecking.cpp
  test/SemaObjC/format-strings-objc.m

Index: test/SemaObjC/format-strings-objc.m
===
--- test/SemaObjC/format-strings-objc.m
+++ test/SemaObjC/format-strings-objc.m
@@ -265,3 +265,16 @@
   NSLog(@"%2$[tt]@ %1$[tt]s", @"Foo", @"Bar"); // expected-warning {{object format flags cannot be used with 's' conversion specifier}}
 }
 
+// Test Objective-C invalid no printable specifiers
+void testObjcInvalidNoPrintable(int *a) {
+  NSLog(@"%\u25B9", 3); // expected-warning {{invalid conversion specifier '\u25b9'}}
+  NSLog(@"%\xE2\x96\xB9", 3); // expected-warning {{invalid conversion specifier '\u25b9'}}
+  NSLog(@"%\U00010348", 42); // expected-warning {{invalid conversion specifier '\U00010348'}}
+  NSLog(@"%\xF0\x90\x8D\x88", 42); // expected-warning {{invalid conversion specifier '\U00010348'}}
+  NSLog(@"%\xe2", @"Foo"); // expected-warning {{input conversion stopped}} expected-warning {{invalid conversion specifier '\xe2'}}
+  scanf("%\u25B9", a); // expected-warning {{implicitly declaring library}} expected-note {{include the header}} expected-warning {{invalid conversion specifier '\u25b9'}}
+  scanf("%\xE2\x96\xB9", a); // expected-warning {{invalid conversion specifier '\u25b9'}}
+  scanf("%\U00010348", a); // expected-warning {{invalid conversion specifier '\U00010348'}}
+  scanf("%\xF0\x90\x8D\x88", a); // expected-warning {{invalid conversion specifier '\U00010348'}}
+  scanf("%\xe2", a); // expected-warning {{invalid conversion specifier '\xe2'}}
+}
Index: lib/Sema/SemaChecking.cpp
===
--- lib/Sema/SemaChecking.cpp
+++ lib/Sema/SemaChecking.cpp
@@ -36,6 +36,8 @@
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/SmallBitVector.h"
 #include "llvm/ADT/SmallString.h"
+#include "llvm/Support/Format.h"
+#include "llvm/Support/Locale.h"
 #include "llvm/Support/ConvertUTF.h"
 #include "llvm/Support/raw_ostream.h"
 #include 
@@ -3976,12 +3978,41 @@
 // gibberish when trying to match arguments.
 keepGoing = false;
   }
-  
-  EmitFormatDiagnostic(S.PDiag(diag::warn_format_invalid_conversion)
- << StringRef(csStart, csLen),
-   Loc, /*IsStringLocation*/true,
-   getSpecifierRange(startSpec, specifierLen));
-  
+
+  StringRef Specifier(csStart, csLen);
+
+  // If the specifier in non-printable, it could be the first byte of a UTF-8
+  // sequence. In that case, print the UTF-8 code point. If not, print the byte
+  // hex value.
+  std::string CodePointStr;
+  if (!llvm::sys::locale::isPrint(*csStart)) {
+UTF32 CodePoint;
+const UTF8 **B = reinterpret_cast();
+const UTF8 *E =
+reinterpret_cast(csStart + csLen);
+ConversionResult Result =
+llvm::convertUTF8Sequence(B, E, , strictConversion);
+
+if (Result != conversionOK) {
+  unsigned char FirstChar = *csStart;
+  CodePoint = (UTF32)FirstChar;
+}
+
+llvm::raw_string_ostream OS(CodePointStr);
+if (CodePoint < 256)
+  OS << "\\x" << llvm::format("%02x", CodePoint);
+else if (CodePoint <= 0x)
+  OS << "\\u" << llvm::format("%04x", CodePoint);
+else
+  OS << "\\U" << llvm::format("%08x", CodePoint);
+OS.flush();
+Specifier = CodePointStr;
+  }
+
+  EmitFormatDiagnostic(
+  S.PDiag(diag::warn_format_invalid_conversion) << Specifier, Loc,
+  /*IsStringLocation*/ true, getSpecifierRange(startSpec, specifierLen));
+
   return keepGoing;
 }
 
Index: lib/Analysis/ScanfFormatString.cpp
===
--- lib/Analysis/ScanfFormatString.cpp
+++ lib/Analysis/ScanfFormatString.cpp
@@ -79,7 +79,7 @@
 unsigned ,
 const LangOptions ,
 const TargetInfo ) {
-  
+  using namespace clang::analyze_format_string;
   using namespace clang::analyze_scanf;
   const char *I = Beg;
   const char *Start = nullptr;
@@ -210,10 +210,15 @@
   
   // FIXME: '%' and '*' doesn't make sense.  Issue a warning.
   // FIXME: 'ConsumedSoFar' and '*' doesn't make sense.
-  
+
   if (k == ScanfConversionSpecifier::InvalidSpecifier) {
+unsigned Len = I - Beg;
+if (ParseUTF8InvalidSpecifier(Beg, E, Len)) {
+  CS.setEndScanList(Beg + Len);
+  FS.setConversionSpecifier(CS);
+}
 // Assume the conversion takes one argument.
-return !H.HandleInvalidScanfConversionSpecifier(FS, Beg, I - 

[PATCH] D18533: Fixing PR26558: the adc builtins do not require the adx target attribute

[Yunzhong Gao via cfe-commits]

ygao created this revision.
ygao added subscribers: craig.topper, bogner, cfe-commits.

Hi,
The addcarry and subborrow variants of the builtins do not require the adx 
target attribute. Only the addcarryx variants require them.
This patch attempts to remove the target attribute requirements from these 
builtins, and also to update the test (run the same test without adx and make 
sure nothing breaks).
Could you review?

Many thanks,
- Gao

http://reviews.llvm.org/D18533

Files:
  include/clang/Basic/BuiltinsX86.def
  test/CodeGen/adc-builtins.c

Index: test/CodeGen/adc-builtins.c
===
--- test/CodeGen/adc-builtins.c
+++ test/CodeGen/adc-builtins.c
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 -triple x86_64-unknown-unknown -target-feature +adx 
-emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -emit-llvm -o - %s | 
FileCheck %s
 
 #define __MM_MALLOC_H
 
Index: include/clang/Basic/BuiltinsX86.def
===
--- include/clang/Basic/BuiltinsX86.def
+++ include/clang/Basic/BuiltinsX86.def
@@ -690,10 +690,10 @@
 // ADX
 TARGET_BUILTIN(__builtin_ia32_addcarryx_u32, "UcUcUiUiUi*", "", "adx")
 TARGET_BUILTIN(__builtin_ia32_addcarryx_u64, "UcUcULLiULLiULLi*", "", "adx")
-TARGET_BUILTIN(__builtin_ia32_addcarry_u32, "UcUcUiUiUi*", "", "adx")
-TARGET_BUILTIN(__builtin_ia32_addcarry_u64, "UcUcULLiULLiULLi*", "", "adx")
-TARGET_BUILTIN(__builtin_ia32_subborrow_u32, "UcUcUiUiUi*", "", "adx")
-TARGET_BUILTIN(__builtin_ia32_subborrow_u64, "UcUcULLiULLiULLi*", "", "adx")
+TARGET_BUILTIN(__builtin_ia32_addcarry_u32, "UcUcUiUiUi*", "", "")
+TARGET_BUILTIN(__builtin_ia32_addcarry_u64, "UcUcULLiULLiULLi*", "", "")
+TARGET_BUILTIN(__builtin_ia32_subborrow_u32, "UcUcUiUiUi*", "", "")
+TARGET_BUILTIN(__builtin_ia32_subborrow_u64, "UcUcULLiULLiULLi*", "", "")
 
 // RDSEED
 TARGET_BUILTIN(__builtin_ia32_rdseed16_step, "UiUs*", "", "rdseed")


Index: test/CodeGen/adc-builtins.c
===
--- test/CodeGen/adc-builtins.c
+++ test/CodeGen/adc-builtins.c
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 -triple x86_64-unknown-unknown -target-feature +adx -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -emit-llvm -o - %s | FileCheck %s
 
 #define __MM_MALLOC_H
 
Index: include/clang/Basic/BuiltinsX86.def
===
--- include/clang/Basic/BuiltinsX86.def
+++ include/clang/Basic/BuiltinsX86.def
@@ -690,10 +690,10 @@
 // ADX
 TARGET_BUILTIN(__builtin_ia32_addcarryx_u32, "UcUcUiUiUi*", "", "adx")
 TARGET_BUILTIN(__builtin_ia32_addcarryx_u64, "UcUcULLiULLiULLi*", "", "adx")
-TARGET_BUILTIN(__builtin_ia32_addcarry_u32, "UcUcUiUiUi*", "", "adx")
-TARGET_BUILTIN(__builtin_ia32_addcarry_u64, "UcUcULLiULLiULLi*", "", "adx")
-TARGET_BUILTIN(__builtin_ia32_subborrow_u32, "UcUcUiUiUi*", "", "adx")
-TARGET_BUILTIN(__builtin_ia32_subborrow_u64, "UcUcULLiULLiULLi*", "", "adx")
+TARGET_BUILTIN(__builtin_ia32_addcarry_u32, "UcUcUiUiUi*", "", "")
+TARGET_BUILTIN(__builtin_ia32_addcarry_u64, "UcUcULLiULLiULLi*", "", "")
+TARGET_BUILTIN(__builtin_ia32_subborrow_u32, "UcUcUiUiUi*", "", "")
+TARGET_BUILTIN(__builtin_ia32_subborrow_u64, "UcUcULLiULLiULLi*", "", "")
 
 // RDSEED
 TARGET_BUILTIN(__builtin_ia32_rdseed16_step, "UiUs*", "", "rdseed")
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r264687 - [analyzer] Use BodyFarm-synthesized body even when actual body available.

[Devin Coughlin via cfe-commits]

Author: dcoughlin
Date: Mon Mar 28 18:55:58 2016
New Revision: 264687

URL: http://llvm.org/viewvc/llvm-project?rev=264687=rev
Log:
[analyzer] Use BodyFarm-synthesized body even when actual body available.

Change body autosynthesis to use the BodyFarm-synthesized body even when
an actual body exists. This enables the analyzer to use the simpler,
analyzer-provided body to model the behavior of the function rather than trying
to understand the actual body. Further, this makes the analyzer robust against
changes in headers that expose the implementations of those bodies.

rdar://problem/25145950

Modified:
cfe/trunk/lib/Analysis/AnalysisDeclContext.cpp
cfe/trunk/test/Analysis/NSString.m
cfe/trunk/test/Analysis/properties.m

Modified: cfe/trunk/lib/Analysis/AnalysisDeclContext.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Analysis/AnalysisDeclContext.cpp?rev=264687=264686=264687=diff
==
--- cfe/trunk/lib/Analysis/AnalysisDeclContext.cpp (original)
+++ cfe/trunk/lib/Analysis/AnalysisDeclContext.cpp Mon Mar 28 18:55:58 2016
@@ -94,19 +94,25 @@ Stmt *AnalysisDeclContext::getBody(bool
   IsAutosynthesized = false;
   if (const FunctionDecl *FD = dyn_cast(D)) {
 Stmt *Body = FD->getBody();
-if (!Body && Manager && Manager->synthesizeBodies()) {
-  Body = getBodyFarm(getASTContext(), Manager->Injector.get()).getBody(FD);
-  if (Body)
+if (Manager && Manager->synthesizeBodies()) {
+  Stmt *SynthesizedBody =
+  getBodyFarm(getASTContext(), Manager->Injector.get()).getBody(FD);
+  if (SynthesizedBody) {
+Body = SynthesizedBody;
 IsAutosynthesized = true;
+  }
 }
 return Body;
   }
   else if (const ObjCMethodDecl *MD = dyn_cast(D)) {
 Stmt *Body = MD->getBody();
-if (!Body && Manager && Manager->synthesizeBodies()) {
-  Body = getBodyFarm(getASTContext(), Manager->Injector.get()).getBody(MD);
-  if (Body)
+if (Manager && Manager->synthesizeBodies()) {
+  Stmt *SynthesizedBody =
+  getBodyFarm(getASTContext(), Manager->Injector.get()).getBody(MD);
+  if (SynthesizedBody) {
+Body = SynthesizedBody;
 IsAutosynthesized = true;
+  }
 }
 return Body;
   } else if (const BlockDecl *BD = dyn_cast(D))

Modified: cfe/trunk/test/Analysis/NSString.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Analysis/NSString.m?rev=264687=264686=264687=diff
==
--- cfe/trunk/test/Analysis/NSString.m (original)
+++ cfe/trunk/test/Analysis/NSString.m Mon Mar 28 18:55:58 2016
@@ -1,7 +1,7 @@
 // RUN: %clang_cc1 -triple i386-apple-darwin10 -analyze 
-analyzer-checker=core,osx.cocoa.NilArg,osx.cocoa.RetainCount,alpha.core 
-analyzer-store=region -analyzer-constraints=range -verify -Wno-objc-root-class 
%s
 // RUN: %clang_cc1 -triple i386-apple-darwin10 -analyze 
-analyzer-checker=core,osx.cocoa.NilArg,osx.cocoa.RetainCount,alpha.core 
-analyzer-store=region -analyzer-constraints=range -analyzer-config 
mode=shallow -verify -Wno-objc-root-class %s
 // RUN: %clang_cc1 -DTEST_64 -triple x86_64-apple-darwin10 -analyze 
-analyzer-checker=core,osx.cocoa.NilArg,osx.cocoa.RetainCount,alpha.core 
-analyzer-store=region -analyzer-constraints=range -verify -Wno-objc-root-class 
%s
-
+// RUN: %clang_cc1 -DOSATOMIC_USE_INLINED -triple i386-apple-darwin10 -analyze 
-analyzer-checker=core,osx.cocoa.NilArg,osx.cocoa.RetainCount,alpha.core 
-analyzer-store=region -analyzer-constraints=range -verify -Wno-objc-root-class 
%s
 
 
//===--===//
 // The following code is reduced using delta-debugging from
@@ -279,9 +279,22 @@ id testSharedClassFromFunction() {
   return [[SharedClass alloc] _init]; // no-warning
 }
 
+#if !(defined(OSATOMIC_USE_INLINED) && OSATOMIC_USE_INLINED)
 // Test OSCompareAndSwap
 _Bool OSAtomicCompareAndSwapPtr( void *__oldValue, void *__newValue, void * 
volatile *__theValue );
 extern BOOL objc_atomicCompareAndSwapPtr(id predicate, id replacement, 
volatile id *objectLocation);
+#else
+// Test that the body farm models are still used even when a body is available.
+_Bool opaque_OSAtomicCompareAndSwapPtr( void *__oldValue, void *__newValue, 
void * volatile *__theValue );
+_Bool OSAtomicCompareAndSwapPtr( void *__oldValue, void *__newValue, void * 
volatile *__theValue ) {
+  return opaque_OSAtomicCompareAndSwapPtr(__oldValue, __newValue, __theValue);
+}
+
+extern BOOL opaque_objc_atomicCompareAndSwapPtr(id predicate, id replacement, 
volatile id *objectLocation);
+extern BOOL objc_atomicCompareAndSwapPtr(id predicate, id replacement, 
volatile id *objectLocation) {
+  return opaque_objc_atomicCompareAndSwapPtr(predicate, replacement, 
objectLocation);
+}
+#endif
 
 void testOSCompareAndSwap() {
   NSString *old = 0;

Modified: cfe/trunk/test/Analysis/properties.m

r264681 - [PGO] More comments how function pointers for indirect calls are mapped

[Adam Nemet via cfe-commits]

Author: anemet
Date: Mon Mar 28 17:18:53 2016
New Revision: 264681

URL: http://llvm.org/viewvc/llvm-project?rev=264681=rev
Log:
[PGO] More comments how function pointers for indirect calls are mapped
to function names

Summary:
Hopefully this will make it easier for the next person to figure all
this out...

Reviewers: bogner, davidxl

Subscribers: davidxl, cfe-commits

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

Modified:
cfe/trunk/lib/CodeGen/CGCall.cpp

Modified: cfe/trunk/lib/CodeGen/CGCall.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCall.cpp?rev=264681=264680=264681=diff
==
--- cfe/trunk/lib/CodeGen/CGCall.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGCall.cpp Mon Mar 28 17:18:53 2016
@@ -3817,7 +3817,9 @@ RValue CodeGenFunction::EmitCall(const C
   CS.setAttributes(Attrs);
   CS.setCallingConv(static_cast(CallingConv));
 
-  // Insert instrumentation or attach profile metadata at indirect call sites
+  // Insert instrumentation or attach profile metadata at indirect call sites.
+  // For more details, see the comment before the definition of
+  // IPVK_IndirectCallTarget in InstrProfData.inc.
   if (!CS.getCalledFunction())
 PGO.valueProfile(Builder, llvm::IPVK_IndirectCallTarget,
  CS.getInstruction(), Callee);


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

Re: [PATCH] D18489: [PGO, clang] Comment how function pointers for indirect calls are mapped to function names

[Adam Nemet via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL264678: [PGO] More comments how function pointers for 
indirect calls are mapped (authored by anemet).

Changed prior to commit:
  http://reviews.llvm.org/D18489?vs=51713=51845#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D18489

Files:
  llvm/trunk/include/llvm/ProfileData/InstrProfData.inc

Index: llvm/trunk/include/llvm/ProfileData/InstrProfData.inc
===
--- llvm/trunk/include/llvm/ProfileData/InstrProfData.inc
+++ llvm/trunk/include/llvm/ProfileData/InstrProfData.inc
@@ -133,6 +133,15 @@
 #else
 #define INSTR_PROF_DATA_DEFINED
 #endif
+/* For indirect function call value profiling, the addresses of the target
+ * functions are profiled by the instrumented code. The target addresses are
+ * written in the raw profile data and converted to target function name's MD5
+ * hash by the profile reader during deserialization.  Typically, this happens
+ * when the the raw profile data is read during profile merging.
+ *
+ * For this remapping the ProfData is used.  ProfData contains both the 
function
+ * name hash and the function address.
+ */
 VALUE_PROF_KIND(IPVK_IndirectCallTarget, 0)
 /* These two kinds must be the last to be
  * declared. This is to make sure the string


Index: llvm/trunk/include/llvm/ProfileData/InstrProfData.inc
===
--- llvm/trunk/include/llvm/ProfileData/InstrProfData.inc
+++ llvm/trunk/include/llvm/ProfileData/InstrProfData.inc
@@ -133,6 +133,15 @@
 #else
 #define INSTR_PROF_DATA_DEFINED
 #endif
+/* For indirect function call value profiling, the addresses of the target
+ * functions are profiled by the instrumented code. The target addresses are
+ * written in the raw profile data and converted to target function name's MD5
+ * hash by the profile reader during deserialization.  Typically, this happens
+ * when the the raw profile data is read during profile merging.
+ *
+ * For this remapping the ProfData is used.  ProfData contains both the function
+ * name hash and the function address.
+ */
 VALUE_PROF_KIND(IPVK_IndirectCallTarget, 0)
 /* These two kinds must be the last to be
  * declared. This is to make sure the string
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D17378: Add additional Hi/Lo registers to Clang MipsTargetInfoBase

[Chandler Carruth via cfe-commits]

chandlerc added a comment.

I don't know anything about MIPS and this seems a highly MIPS specific change, 
so I can't provide any useful review here. You have someone with MIPS specific 
knowledge on the review though, so you seem to have the appropriate people 
looped in...


http://reviews.llvm.org/D17378



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

Re: [PATCH] D18489: [PGO, clang] Comment how function pointers for indirect calls are mapped to function names

[Adam Nemet via cfe-commits]

anemet accepted this revision.
anemet added a reviewer: anemet.
anemet added a comment.
This revision is now accepted and ready to land.

Was accepted by davidxl.


http://reviews.llvm.org/D18489



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

Re: [PATCH] D18479: [CodeGenCXX] Fix ItaniumCXXABI::getAlignmentOfExnObject to return 8-byte alignment on Darwin

[Akira Hatanaka via cfe-commits]

> On Mar 25, 2016, at 2:23 PM, Akira Hatanaka via cfe-commits 
>  wrote:
> 
>> 
>> On Mar 25, 2016, at 2:06 PM, David Majnemer via cfe-commits 
>> > wrote:
>> 
>> 
>> 
>> On Fri, Mar 25, 2016 at 12:57 PM, Akira Hatanaka via cfe-commits 
>> > wrote:
>> ahatanak created this revision.
>> ahatanak added a reviewer: rjmccall.
>> ahatanak added a subscriber: cfe-commits.
>> 
>> r246985 made changes to give a higher alignment for exception objects on the 
>> grounds that Itanium says _Unwind_Exception should be "double-word" aligned 
>> and the structure is normally declared with __attribute__((aligned)) 
>> guaranteeing 16-byte alignment. It turns out that libc++abi doesn't declare 
>> the structure with __attribute__((aligned)) and therefore only guarantees 
>> 8-byte alignment on 32-bit and 64-bit platforms. This caused a crash in some 
>> cases when the backend emitted SIMD store instructions that requires 16-byte 
>> alignment (such as movaps).
>> 
>> This patch makes ItaniumCXXABI::getAlignmentOfExnObject return an 8-byte 
>> alignment on Darwin to fix the crash.
>> 
>> http://reviews.llvm.org/D18479 
>> 
>> Files:
>>   lib/CodeGen/ItaniumCXXABI.cpp
>>   test/CodeGenCXX/eh.cpp
>> 
>> Index: test/CodeGenCXX/eh.cpp
>> ===
>> --- test/CodeGenCXX/eh.cpp
>> +++ test/CodeGenCXX/eh.cpp
>> @@ -448,5 +448,27 @@
>>}
>>  }
>> 
>> +namespace test17 {
>> +class BaseException {
>> +private:
>> +  int a[4];
>> +public:
>> +  BaseException() {};
>> +};
>> +
>> +class DerivedException: public BaseException {
>> +};
>> +
>> +int foo() {
>> +  throw DerivedException();
>> +  // The alignment passed to memset is 8, not 16, on Darwin.
>> +
>> +  // CHECK: [[T0:%.*]] = call i8* @__cxa_allocate_exception(i64 16)
>> +  // CHECK-NEXT: [[T1:%.*]] = bitcast i8* [[T0]] to 
>> %"class.test17::DerivedException"*
>> +  // CHECK-NEXT: [[T2:%.*]] = bitcast %"class.test17::DerivedException"* 
>> [[T1]] to i8*
>> +  // CHECK-NEXT: call void @llvm.memset.p0i8.i64(i8* [[T2]], i8 0, i64 16, 
>> i32 8, i1 false)
>> +}
>> +}
>> +
>>  // CHECK: attributes [[NUW]] = { nounwind }
>>  // CHECK: attributes [[NR]] = { noreturn }
>> Index: lib/CodeGen/ItaniumCXXABI.cpp
>> ===
>> --- lib/CodeGen/ItaniumCXXABI.cpp
>> +++ lib/CodeGen/ItaniumCXXABI.cpp
>> @@ -163,8 +163,17 @@
>>/// we assume that alignment here.  (It's generally 16 bytes, but
>>/// some targets overwrite it.)
>>CharUnits getAlignmentOfExnObject() {
>> -auto align = 
>> CGM.getContext().getTargetDefaultAlignForAttributeAligned();
>> -return CGM.getContext().toCharUnitsFromBits(align);
>> +unsigned Align;
>> +
>> +// Alignment is 8 for darwin since libc++abi doesn't declare
>> +// _Unwind_Exception with __attribute__((aligned)) and therefore doesn't
>> +// guarantee 16-byte alignment.
>> +if (CGM.getContext().getTargetInfo().getTriple().isOSDarwin())
>> 
>> What about Linux/FreeBSD targets which use libc++abi?
>>  
> 
> Is there a way to detect whether libc++abi is used?
> 

I wasn’t planning to fix this for Linux or FreeBSD because I don’t know whether 
that is what people want. If the library being used returns an object that is 
16-byte aligned (does libsupc++ return an aligned object?), my change would 
unnecessarily pessimize the code.

>> +  Align = 64;
>> +else
>> +  Align = CGM.getContext().getTargetDefaultAlignForAttributeAligned();
>> +
>> +return CGM.getContext().toCharUnitsFromBits(Align);
>>}
>> 
>>void emitRethrow(CodeGenFunction , bool isNoReturn) override;
>> 
>> 
>> 
>> ___
>> 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 
>> 
> ___
> 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

r264669 - Improvements to the ASTImporter to support LLDB top-level Clang expressions.

[Sean Callanan via cfe-commits]

Author: spyffe
Date: Mon Mar 28 16:43:01 2016
New Revision: 264669

URL: http://llvm.org/viewvc/llvm-project?rev=264669=rev
Log:
Improvements to the ASTImporter to support LLDB top-level Clang expressions.

The testcase for this is in LLDB, adeed by r264662.

This patch adds support for a variety of new expression types to the AST
importer, mostly related to C++.  It also adds support for importing lambdas
correctly, and adds support for importing the attributes attached to any Decl.

Finally, the patch adds a new templated function to ASTNodeImporter that imports
arbitrary arrays of importable things into a bump-allocated array attached to
getToContext().  This is a pattern we see at many places in ASTNodeImporter;
rather than do it slightly differently at each point, this function does it one
way.



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

Modified: cfe/trunk/lib/AST/ASTImporter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ASTImporter.cpp?rev=264669=264668=264669=diff
==
--- cfe/trunk/lib/AST/ASTImporter.cpp (original)
+++ cfe/trunk/lib/AST/ASTImporter.cpp Mon Mar 28 16:43:01 2016
@@ -224,8 +224,36 @@ namespace clang {
 Expr *VisitImplicitCastExpr(ImplicitCastExpr *E);
 Expr *VisitCStyleCastExpr(CStyleCastExpr *E);
 Expr *VisitCXXConstructExpr(CXXConstructExpr *E);
+Expr *VisitCXXMemberCallExpr(CXXMemberCallExpr *E);
+Expr *VisitCXXThisExpr(CXXThisExpr *E);
+Expr *VisitCXXBoolLiteralExpr(CXXBoolLiteralExpr *E);
 Expr *VisitMemberExpr(MemberExpr *E);
 Expr *VisitCallExpr(CallExpr *E);
+Expr *VisitInitListExpr(InitListExpr *E);
+
+template  bool ImportArray(Iter B, Iter E, 
llvm::ArrayRef ) {
+  size_t NumElements = E - B;
+  SmallVector ImportedElements(NumElements);
+  ASTImporter &_Importer = Importer;
+  
+  bool Failed = false;
+  std::transform(B, E, ImportedElements.begin(),
+ [&_Importer, ](T *Element) -> T* {
+   T *ToElement = _Importer.Import(Element);
+   if (Element && !ToElement)
+ Failed = true;
+   return ToElement;
+ });
+  
+  if (Failed)
+return false;
+  
+  T **CopiedElements = new (Importer.getToContext()) T*[NumElements];
+  std::copy(ImportedElements.begin(), ImportedElements.end(), 
[0]);
+  ToArray = llvm::ArrayRef(CopiedElements, NumElements);
+  
+  return true;
+}
   };
 }
 using namespace clang;
@@ -2683,11 +2711,26 @@ Decl *ASTNodeImporter::VisitRecordDecl(R
   RecordDecl *D2 = AdoptDecl;
   SourceLocation StartLoc = Importer.Import(D->getLocStart());
   if (!D2) {
-if (isa(D)) {
-  CXXRecordDecl *D2CXX = CXXRecordDecl::Create(Importer.getToContext(), 
-   D->getTagKind(),
-   DC, StartLoc, Loc,
-   Name.getAsIdentifierInfo());
+CXXRecordDecl *D2CXX = nullptr;
+if (CXXRecordDecl *DCXX = llvm::dyn_cast(D)) {
+  if (DCXX->isLambda()) {
+TypeSourceInfo *TInfo = Importer.Import(DCXX->getLambdaTypeInfo());
+D2CXX = CXXRecordDecl::CreateLambda(Importer.getToContext(),
+DC, TInfo, Loc,
+DCXX->isDependentLambda(),
+DCXX->isGenericLambda(),
+DCXX->getLambdaCaptureDefault());
+Decl *CDecl = Importer.Import(DCXX->getLambdaContextDecl());
+if (DCXX->getLambdaContextDecl() && !CDecl)
+  return nullptr;
+D2CXX->setLambdaMangling(DCXX->getLambdaManglingNumber(),
+ CDecl);
+  } else {
+D2CXX = CXXRecordDecl::Create(Importer.getToContext(),
+  D->getTagKind(),
+  DC, StartLoc, Loc,
+  Name.getAsIdentifierInfo());
+  }
   D2 = D2CXX;
   D2->setAccess(D->getAccess());
 } else {
@@ -4653,16 +4696,11 @@ Stmt *ASTNodeImporter::VisitNullStmt(Nul
 }
 
 Stmt *ASTNodeImporter::VisitCompoundStmt(CompoundStmt *S) {
-  SmallVector ToStmts(S->size());
-  auto &_Importer = this->Importer;
-  std::transform(S->body_begin(), S->body_end(), ToStmts.begin(),
-[&_Importer](Stmt *CS) -> Stmt * {
-  return _Importer.Import(CS);
-});
-  for (Stmt *ToS : ToStmts) {
-if (!ToS)
-  return nullptr;
-  }
+  llvm::ArrayRef ToStmts;
+
+  if (!ImportArray(S->body_begin(), S->body_end(), ToStmts))
+return nullptr;
+
   SourceLocation ToLBraceLoc = Importer.Import(S->getLBracLoc());
   SourceLocation ToRBraceLoc = Importer.Import(S->getRBracLoc());
   return new 

r264664 - [modules] If both a module file and a module map for the same module are

[Richard Smith via cfe-commits]

Author: rsmith
Date: Mon Mar 28 16:31:09 2016
New Revision: 264664

URL: http://llvm.org/viewvc/llvm-project?rev=264664=rev
Log:
[modules] If both a module file and a module map for the same module are
explicitly provided, and the module map lists a header that does not exist,
unmark the module as 'unavailable' when loading its .pcm file. (Use of the
module might still fail if the relevant headers aren't embedded, but this
behavior is now consistent with how we behave if the module map is not
provided, and with the desired behavior for embedding headers in modules.)

Modified:
cfe/trunk/lib/Serialization/ASTReader.cpp
cfe/trunk/test/Modules/embed-files.cpp

Modified: cfe/trunk/lib/Serialization/ASTReader.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Serialization/ASTReader.cpp?rev=264664=264663=264664=diff
==
--- cfe/trunk/lib/Serialization/ASTReader.cpp (original)
+++ cfe/trunk/lib/Serialization/ASTReader.cpp Mon Mar 28 16:31:09 2016
@@ -4541,14 +4541,25 @@ ASTReader::ReadSubmoduleBlock(ModuleFile
   
   SubmodulesLoaded[GlobalIndex] = CurrentModule;
 
-  // Clear out data that will be replaced by what is the module file.
+  // Clear out data that will be replaced by what is in the module file.
   CurrentModule->LinkLibraries.clear();
   CurrentModule->ConfigMacros.clear();
   CurrentModule->UnresolvedConflicts.clear();
   CurrentModule->Conflicts.clear();
+
+  // The module is available unless it's missing a requirement; relevant
+  // requirements will be (re-)added by SUBMODULE_REQUIRES records.
+  // Missing headers that were present when the module was built do not
+  // make it unavailable -- if we got this far, this must be an explicitly
+  // imported module file.
+  CurrentModule->Requirements.clear();
+  CurrentModule->MissingHeaders.clear();
+  CurrentModule->IsMissingRequirement =
+  ParentModule && ParentModule->IsMissingRequirement;
+  CurrentModule->IsAvailable = !CurrentModule->IsMissingRequirement;
   break;
 }
-
+
 case SUBMODULE_UMBRELLA_HEADER: {
   std::string Filename = Blob;
   ResolveImportedPath(F, Filename);

Modified: cfe/trunk/test/Modules/embed-files.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/embed-files.cpp?rev=264664=264663=264664=diff
==
--- cfe/trunk/test/Modules/embed-files.cpp (original)
+++ cfe/trunk/test/Modules/embed-files.cpp Mon Mar 28 16:31:09 2016
@@ -1,11 +1,17 @@
 // RUN: rm -rf %t
 // RUN: mkdir %t
-// RUN: echo 'module a { header "a.h" } module b { header "b.h" }' > 
%t/modulemap
+// RUN: echo 'module a { header "a.h" header "x.h" } module b { header "b.h" 
}' > %t/modulemap
 // RUN: echo 'extern int t;' > %t/t.h
 // RUN: echo '#include "t.h"' > %t/a.h
 // RUN: echo '#include "t.h"' > %t/b.h
+// RUN: echo '#include "t.h"' > %t/x.h
 
 // RUN: %clang_cc1 -fmodules -I%t -fmodules-cache-path=%t 
-fmodule-map-file=%t/modulemap -fmodules-embed-all-files %s -verify
+//
+// RUN: %clang_cc1 -fmodules -I%t -fmodules-embed-all-files %t/modulemap 
-fmodule-name=a -x c++ -emit-module -o %t/a.pcm
+// RUN: %clang_cc1 -fmodules -I%t -fmodules-embed-all-files %t/modulemap 
-fmodule-name=b -x c++ -emit-module -o %t/b.pcm
+// RUN: rm %t/x.h
+// RUN: %clang_cc1 -fmodules -I%t -fmodule-map-file=%t/modulemap 
-fmodule-file=%t/a.pcm -fmodule-file=%t/b.pcm %s -verify
 #include "a.h"
 char t; // expected-error {{different type}}
 // expected-note@t.h:1 {{here}}


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

Re: [PATCH] D17002: [lanai] Add Lanai backend to clang driver

[Jacques Pienaar via cfe-commits]

This revision was automatically updated to reflect the committed changes.
jpienaar marked an inline comment as done.
Closed by commit rL264655: [lanai] Add Lanai backend to clang driver. (authored 
by jpienaar).

Changed prior to commit:
  http://reviews.llvm.org/D17002?vs=51806=51838#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D17002

Files:
  cfe/trunk/lib/Basic/Targets.cpp
  cfe/trunk/lib/CodeGen/TargetInfo.cpp
  cfe/trunk/lib/Driver/Driver.cpp
  cfe/trunk/lib/Driver/ToolChains.h
  cfe/trunk/lib/Driver/Tools.cpp
  cfe/trunk/lib/Driver/Tools.h
  cfe/trunk/test/CodeGen/lanai-arguments.c
  cfe/trunk/test/CodeGen/lanai-regparm.c
  cfe/trunk/test/CodeGen/target-data.c
  cfe/trunk/test/Driver/lanai-toolchain.c
  cfe/trunk/test/Driver/lanai-unknown-unknown.cpp
  cfe/trunk/test/Preprocessor/init.c

Index: cfe/trunk/test/Preprocessor/init.c
===
--- cfe/trunk/test/Preprocessor/init.c
+++ cfe/trunk/test/Preprocessor/init.c
@@ -8414,6 +8414,9 @@
 // RUN: %clang_cc1 -triple arm-linux-androideabi -E -dM < /dev/null | FileCheck -match-full-lines -check-prefix ANDROID %s
 // ANDROID:#define __ANDROID__ 1
 //
+// RUN: %clang_cc1 -triple lanai-unknown-unknown -E -dM < /dev/null | FileCheck -match-full-lines -check-prefix LANAI %s
+// LANAI: #define __lanai__ 1
+//
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc64-unknown-freebsd < /dev/null | FileCheck -match-full-lines -check-prefix PPC64-FREEBSD %s
 // PPC64-FREEBSD-NOT: #define __LONG_DOUBLE_128__ 1
 //
Index: cfe/trunk/test/CodeGen/lanai-arguments.c
===
--- cfe/trunk/test/CodeGen/lanai-arguments.c
+++ cfe/trunk/test/CodeGen/lanai-arguments.c
@@ -0,0 +1,75 @@
+// RUN: %clang_cc1 -triple lanai-unknown-unknown %s -emit-llvm -o - \
+// RUN:   | FileCheck %s
+
+// Basic argument/attribute tests for Lanai.
+
+// CHECK: define void @f0(i32 inreg %i, i32 inreg %j, i64 inreg %k)
+void f0(int i, long j, long long k) {}
+
+typedef struct {
+  int aa;
+  int bb;
+} s1;
+// CHECK: define void @f1(%struct.s1* byval align 4 %i)
+void f1(s1 i) {}
+
+typedef struct {
+  int cc;
+} s2;
+// CHECK: define void @f2(%struct.s2* noalias sret %agg.result)
+s2 f2() {
+  s2 foo;
+  return foo;
+}
+
+typedef struct {
+  int cc;
+  int dd;
+} s3;
+// CHECK: define void @f3(%struct.s3* noalias sret %agg.result)
+s3 f3() {
+  s3 foo;
+  return foo;
+}
+
+// CHECK: define void @f4(i64 inreg %i)
+void f4(long long i) {}
+
+// CHECK: define void @f5(i8 inreg %a, i16 inreg %b)
+void f5(char a, short b) {}
+
+// CHECK: define void @f6(i8 inreg %a, i16 inreg %b)
+void f6(unsigned char a, unsigned short b) {}
+
+enum my_enum {
+  ENUM1,
+  ENUM2,
+  ENUM3,
+};
+// Enums should be treated as the underlying i32.
+// CHECK: define void @f7(i32 inreg %a)
+void f7(enum my_enum a) {}
+
+enum my_big_enum {
+  ENUM4 = 0x,
+};
+// Big enums should be treated as the underlying i64.
+// CHECK: define void @f8(i64 inreg %a)
+void f8(enum my_big_enum a) {}
+
+union simple_union {
+  int a;
+  char b;
+};
+// Unions should be passed as byval structs.
+// CHECK: define void @f9(%union.simple_union* byval align 4 %s)
+void f9(union simple_union s) {}
+
+typedef struct {
+  int b4 : 4;
+  int b3 : 3;
+  int b8 : 8;
+} bitfield1;
+// Bitfields should be passed as byval structs.
+// CHECK: define void @f10(%struct.bitfield1* byval align 4 %bf1)
+void f10(bitfield1 bf1) {}
Index: cfe/trunk/test/CodeGen/target-data.c
===
--- cfe/trunk/test/CodeGen/target-data.c
+++ cfe/trunk/test/CodeGen/target-data.c
@@ -86,6 +86,10 @@
 // RUN: FileCheck %s -check-prefix=WEBASSEMBLY64
 // WEBASSEMBLY64: target datalayout = "e-m:e-p:64:64-i64:64-n32:64-S128"
 
+// RUN: %clang_cc1 -triple lanai-unknown-unknown -o - -emit-llvm %s | \
+// RUN: FileCheck %s -check-prefix=LANAI
+// LANAI: target datalayout = "E-m:e-p:32:32-i64:64-a:0:32-n32-S64"
+
 // RUN: %clang_cc1 -triple powerpc-unknown -o - -emit-llvm %s | \
 // RUN: FileCheck %s -check-prefix=PPC
 // PPC: target datalayout = "E-m:e-p:32:32-i64:64-n32"
Index: cfe/trunk/test/CodeGen/lanai-regparm.c
===
--- cfe/trunk/test/CodeGen/lanai-regparm.c
+++ cfe/trunk/test/CodeGen/lanai-regparm.c
@@ -0,0 +1,18 @@
+// RUN: %clang_cc1 -triple lanai-unknown-unknown -mregparm 4 %s -emit-llvm -o - | FileCheck %s
+
+void f1(int a, int b, int c, int d,
+int e, int f, int g, int h);
+
+void f2(int a, int b) __attribute((regparm(0)));
+
+void f0() {
+// CHECK: call void @f1(i32 inreg 1, i32 inreg 2, i32 inreg 3, i32 inreg 4,
+// CHECK: i32 5, i32 6, i32 7, i32 8)
+  f1(1, 2, 3, 4, 5, 6, 7, 8);
+// CHECK: call void @f2(i32 1, i32 2)
+  f2(1, 2);
+}
+
+// CHECK: declare void @f1(i32 inreg, i32 inreg, i32 inreg, i32 inreg,
+// CHECK: i32, i32, i32, i32)
+// CHECK: declare void @f2(i32, i32)
Index: 

r264655 - [lanai] Add Lanai backend to clang driver.

[Jacques Pienaar via cfe-commits]

Author: jpienaar
Date: Mon Mar 28 16:02:54 2016
New Revision: 264655

URL: http://llvm.org/viewvc/llvm-project?rev=264655=rev
Log:
[lanai] Add Lanai backend to clang driver.

Changes to clang to add Lanai backend. Adds a new target, ABI and toolchain.

General Lanai backend discussion on llvm-dev thread "[RFC] Lanai backend" 
(http://lists.llvm.org/pipermail/llvm-dev/2016-February/095118.html).

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


Added:
cfe/trunk/test/CodeGen/lanai-arguments.c
cfe/trunk/test/CodeGen/lanai-regparm.c
cfe/trunk/test/Driver/lanai-toolchain.c
cfe/trunk/test/Driver/lanai-unknown-unknown.cpp
Modified:
cfe/trunk/lib/Basic/Targets.cpp
cfe/trunk/lib/CodeGen/TargetInfo.cpp
cfe/trunk/lib/Driver/Driver.cpp
cfe/trunk/lib/Driver/ToolChains.h
cfe/trunk/lib/Driver/Tools.cpp
cfe/trunk/lib/Driver/Tools.h
cfe/trunk/test/CodeGen/target-data.c
cfe/trunk/test/Preprocessor/init.c

Modified: cfe/trunk/lib/Basic/Targets.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=264655=264654=264655=diff
==
--- cfe/trunk/lib/Basic/Targets.cpp (original)
+++ cfe/trunk/lib/Basic/Targets.cpp Mon Mar 28 16:02:54 2016
@@ -5950,6 +5950,111 @@ const Builtin::Info HexagonTargetInfo::B
 #include "clang/Basic/BuiltinsHexagon.def"
 };
 
+class LanaiTargetInfo : public TargetInfo {
+  // Class for Lanai (32-bit).
+  // The CPU profiles supported by the Lanai backend
+  enum CPUKind {
+CK_NONE,
+CK_V11,
+  } CPU;
+
+  static const TargetInfo::GCCRegAlias GCCRegAliases[];
+  static const char *const GCCRegNames[];
+
+public:
+  LanaiTargetInfo(const llvm::Triple ) : TargetInfo(Triple) {
+// Description string has to be kept in sync with backend.
+resetDataLayout("E"// Big endian
+"-m:e" // ELF name manging
+"-p:32:32" // 32 bit pointers, 32 bit aligned
+"-i64:64"  // 64 bit integers, 64 bit aligned
+"-a:0:32"  // 32 bit alignment of objects of aggregate type
+"-n32" // 32 bit native integer width
+"-S64" // 64 bit natural stack alignment
+);
+
+// Setting RegParmMax equal to what mregparm was set to in the old
+// toolchain
+RegParmMax = 4;
+
+// Set the default CPU to V11
+CPU = CK_V11;
+
+// Temporary approach to make everything at least word-aligned and allow 
for
+// safely casting between pointers with different alignment requirements.
+// TODO: Remove this when there are no more cast align warnings on the
+// firmware.
+MinGlobalAlign = 32;
+  }
+
+  void getTargetDefines(const LangOptions ,
+MacroBuilder ) const override {
+// Define __lanai__ when building for target lanai.
+Builder.defineMacro("__lanai__");
+
+// Set define for the CPU specified.
+switch (CPU) {
+case CK_V11:
+  Builder.defineMacro("__LANAI_V11__");
+  break;
+case CK_NONE:
+  llvm_unreachable("Unhandled target CPU");
+}
+  }
+
+  bool setCPU(const std::string ) override {
+CPU = llvm::StringSwitch(Name)
+  .Case("v11", CK_V11)
+  .Default(CK_NONE);
+
+return CPU != CK_NONE;
+  }
+
+  bool hasFeature(StringRef Feature) const override {
+return llvm::StringSwitch(Feature).Case("lanai", 
true).Default(false);
+  }
+
+  ArrayRef getGCCRegNames() const override;
+
+  ArrayRef getGCCRegAliases() const override;
+
+  BuiltinVaListKind getBuiltinVaListKind() const override {
+return TargetInfo::VoidPtrBuiltinVaList;
+  }
+
+  ArrayRef getTargetBuiltins() const override { return None; }
+
+  bool validateAsmConstraint(const char *,
+ TargetInfo::ConstraintInfo ) const override {
+return false;
+  }
+
+  const char *getClobbers() const override { return ""; }
+};
+
+const char *const LanaiTargetInfo::GCCRegNames[] = {
+"r0",  "r1",  "r2",  "r3",  "r4",  "r5",  "r6",  "r7",  "r8",  "r9",  
"r10",
+"r11", "r12", "r13", "r14", "r15", "r16", "r17", "r18", "r19", "r20", 
"r21",
+"r22", "r23", "r24", "r25", "r26", "r27", "r28", "r29", "r30", "r31"};
+
+ArrayRef LanaiTargetInfo::getGCCRegNames() const {
+  return llvm::makeArrayRef(GCCRegNames);
+}
+
+const TargetInfo::GCCRegAlias LanaiTargetInfo::GCCRegAliases[] = {
+{{"pc"}, "r2"},
+{{"sp"}, "r4"},
+{{"fp"}, "r5"},
+{{"rv"}, "r8"},
+{{"rr1"}, "r10"},
+{{"rr2"}, "r11"},
+{{"rca"}, "r15"},
+};
+
+ArrayRef LanaiTargetInfo::getGCCRegAliases() const {
+  return llvm::makeArrayRef(GCCRegAliases);
+}
+
 // Shared base class for SPARC v8 (32-bit) and SPARC v9 (64-bit).
 class SparcTargetInfo : public TargetInfo {
   static const TargetInfo::GCCRegAlias GCCRegAliases[];
@@ -7672,6 +,9 @@ static TargetInfo *AllocateTarget(const
   case llvm::Triple::hexagon:
 return new 

r264651 - Update the description of Clang's MSVC compatibility flags

[Reid Kleckner via cfe-commits]

Author: rnk
Date: Mon Mar 28 15:42:41 2016
New Revision: 264651

URL: http://llvm.org/viewvc/llvm-project?rev=264651=rev
Log:
Update the description of Clang's MSVC compatibility flags

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=264651=264650=264651=diff
==
--- cfe/trunk/docs/UsersManual.rst (original)
+++ cfe/trunk/docs/UsersManual.rst Mon Mar 28 15:42:41 2016
@@ -1770,13 +1770,11 @@ Intentionally unsupported GCC extensions
 Microsoft extensions
 
 
-clang has some experimental support for extensions from Microsoft Visual
-C++; to enable it, use the ``-fms-extensions`` command-line option. This is
-the default for Windows targets. Note that the support is incomplete.
-Some constructs such as ``dllexport`` on classes are ignored with a warning,
-and others such as `Microsoft IDL annotations
-`_ are silently
-ignored.
+clang has support for many extensions from Microsoft Visual C++. To enable 
these
+extensions, use the ``-fms-extensions`` command-line option. This is the 
default
+for Windows targets. Clang does not implement every pragma or declspec provided
+by MSVC, but the popular ones, such as ``__declspec(dllexport)`` and ``#pragma
+comment(lib)`` are well supported.
 
 clang has a ``-fms-compatibility`` flag that makes clang accept enough
 invalid C++ to be able to parse most Microsoft headers. For example, it
@@ -1789,23 +1787,14 @@ for Windows targets.
 definitions until the end of a translation unit. This flag is enabled by
 default for Windows targets.
 
--  clang allows setting ``_MSC_VER`` with ``-fmsc-version=``. It defaults to
-   1700 which is the same as Visual C/C++ 2012. Any number is supported
-   and can greatly affect what Windows SDK and c++stdlib headers clang
-   can compile.
--  clang does not support the Microsoft extension where anonymous record
-   members can be declared using user defined typedefs.
--  clang supports the Microsoft ``#pragma pack`` feature for controlling
-   record layout. GCC also contains support for this feature, however
-   where MSVC and GCC are incompatible clang follows the MSVC
-   definition.
--  clang supports the Microsoft ``#pragma comment(lib, "foo.lib")`` feature for
-   automatically linking against the specified library.  Currently this feature
-   only works with the Visual C++ linker.
--  clang supports the Microsoft ``#pragma comment(linker, "/flag:foo")`` 
feature
-   for adding linker flags to COFF object files.  The user is responsible for
-   ensuring that the linker understands the flags.
--  clang defaults to C++11 for Windows targets.
+For compatibility with existing code that compiles with MSVC, clang defines the
+``_MSC_VER`` and ``_MSC_FULL_VER`` macros. These default to the values of 1800
+and 18000 respectively, making clang look like an early release of Visual
+C++ 2013. The ``-fms-compatibility-version=`` flag overrides these values.  It
+accepts a dotted version tuple, such as 19.00.23506. Changing the MSVC
+compatibility version makes clang behave more like that version of MSVC. For
+example, ``-fms-compatibility-version=19`` will enable C++14 features and 
define
+``char16_t`` and ``char32_t`` as builtin types.
 
 .. _cxx:
 


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

Re: [PATCH] D17861: [OpenCL] Accept __attribute__((nosvm))

[Aaron Ballman via cfe-commits]

aaron.ballman requested changes to this revision.
This revision now requires changes to proceed.


Comment at: lib/Sema/SemaDeclAttr.cpp:5210
@@ +5209,3 @@
+static void handleOpenCLNoSVMAttr(Sema , Decl *D, const AttributeList ) 
{
+  if (!S.LangOpts.OpenCL) {
+S.Diag(Attr.getLoc(), diag::warn_unknown_attribute_ignored)

Please use the language option feature in tabelgen as in your previous patch 
instead of performing this work manually. We want use of the attribute to 
provide a different diagnostic in this case because the attribute *isn't* 
unknown, it simply doesn't apply under the compilation target (and hence is 
ignored).


Comment at: lib/Sema/SemaDeclAttr.cpp:5218
@@ +5217,3 @@
+<< Attr.getName() << "2.0" << 0;
+}
+

This should have an else clause telling the user that the attribute is being 
ignored; silently accepting it and then not performing the semantics of the 
attribute will be confusing behavior for most users. It might not be a bad idea 
to also have the diagnostic tell the user that the attribute has been 
deprecated and is removed in OpenCL 2.1.


http://reviews.llvm.org/D17861



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

Re: [PATCH] D18296: [Sema] Handle UTF-8 invalid format string specifiers

[Bruno Cardoso Lopes via cfe-commits]

bruno added a comment.

In http://reviews.llvm.org/D18296#384766, @rsmith wrote:

> This patch builds a length-1 `ConversionSpecifier` but includes the complete 
> code point in the length of the overall format specifier, which is 
> inconsistent. Please either treat the trailing bytes as part of the 
> `ConversionSpecifier` or revert the changes to `ParsePrintfSpecifier` and 
> handle this entirely within `HandleInvalidConversionSpecifier`.


Ok, gonna handle this entirely within `HandleInvalidConversionSpecifier` then.

> Does the same problem exist when parsing `scanf` specifiers?


Yes, I missed that, will update accordingly.



Comment at: lib/Analysis/PrintfFormatString.cpp:324
@@ +323,3 @@
+// UTF-8 sequence. If that's the case, adjust the length accordingly.
+if (Start + 1 < I && !llvm::sys::locale::isPrint(FirstByte) &&
+isLegalUTF8String(, SE))

rsmith wrote:
> The interpretation of a format string by `printf` should not depend on the 
> locale, so our parsing of a format string should not either.
llvm::sys::locale::isPrint does not actually do any locale specific check 
(maybe it should be moved elsewhere for better consitency?):

  bool isPrint(int UCS) {
  #if LLVM_ON_WIN32
// Restrict characters that we'll try to print to the lower part of ASCII
// except for the control characters (0x20 - 0x7E). In general one can not
// reliably output code points U+0080 and higher using narrow character 
C/C++
// output functions in Windows, because the meaning of the upper 128 codes 
is
// determined by the active code page in the console.
return ' ' <= UCS && UCS <= '~';
  #else
return llvm::sys::unicode::isPrintable(UCS);
  #endif
  }

This logic is needed anyway though. Suggestions?


http://reviews.llvm.org/D18296



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

r264647 - [analyzer] Nullability: Don't warn along paths where null returned from non-null.

[Devin Coughlin via cfe-commits]

Author: dcoughlin
Date: Mon Mar 28 15:30:25 2016
New Revision: 264647

URL: http://llvm.org/viewvc/llvm-project?rev=264647=rev
Log:
[analyzer] Nullability: Don't warn along paths where null returned from 
non-null.

Change the nullability checker to not warn along paths where null is returned 
from
a method with a non-null return type, even when the diagnostic for this return
has been suppressed. This prevents warning from methods with non-null return 
types
that inline methods that themselves return nil but that suppressed the 
diagnostic.

Also change the PreconditionViolated state component to be called 
"InvariantViolated"
because it is set when a post-condition is violated, as well.

rdar://problem/25393539

Modified:
cfe/trunk/lib/StaticAnalyzer/Checkers/NullabilityChecker.cpp
cfe/trunk/test/Analysis/Inputs/system-header-simulator-for-nullability.h
cfe/trunk/test/Analysis/nullability-no-arc.mm

Modified: cfe/trunk/lib/StaticAnalyzer/Checkers/NullabilityChecker.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Checkers/NullabilityChecker.cpp?rev=264647=264646=264647=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Checkers/NullabilityChecker.cpp (original)
+++ cfe/trunk/lib/StaticAnalyzer/Checkers/NullabilityChecker.cpp Mon Mar 28 
15:30:25 2016
@@ -168,11 +168,11 @@ private:
   ///
   /// When \p SuppressPath is set to true, no more bugs will be reported on 
this
   /// path by this checker.
-  void reportBugIfPreconditionHolds(StringRef Msg, ErrorKind Error,
-ExplodedNode *N, const MemRegion *Region,
-CheckerContext ,
-const Stmt *ValueExpr = nullptr,
-bool SuppressPath = false) const;
+  void reportBugIfInvariantHolds(StringRef Msg, ErrorKind Error,
+ ExplodedNode *N, const MemRegion *Region,
+ CheckerContext ,
+ const Stmt *ValueExpr = nullptr,
+  bool SuppressPath = false) const;
 
   void reportBug(StringRef Msg, ErrorKind Error, ExplodedNode *N,
  const MemRegion *Region, BugReporter ,
@@ -247,12 +247,31 @@ bool operator==(NullabilityState Lhs, Nu
 REGISTER_MAP_WITH_PROGRAMSTATE(NullabilityMap, const MemRegion *,
NullabilityState)
 
-// If the nullability precondition of a function is violated, we should not
-// report nullability related issues on that path. For this reason once a
-// precondition is not met on a path, this checker will be esentially turned 
off
-// for the rest of the analysis. We do not want to generate a sink node 
however,
-// so this checker would not lead to reduced coverage.
-REGISTER_TRAIT_WITH_PROGRAMSTATE(PreconditionViolated, bool)
+// We say "the nullability type invariant is violated" when a location with a
+// non-null type contains NULL or a function with a non-null return type 
returns
+// NULL. Violations of the nullability type invariant can be detected either
+// directly (for example, when NULL is passed as an argument to a nonnull
+// parameter) or indirectly (for example, when, inside a function, the
+// programmer defensively checks whether a nonnull parameter contains NULL and
+// finds that it does).
+//
+// As a matter of policy, the nullability checker typically warns on direct
+// violations of the nullability invariant (although it uses various
+// heuristics to suppress warnings in some cases) but will not warn if the
+// invariant has already been violated along the path (either directly or
+// indirectly). As a practical matter, this prevents the analyzer from
+// (1) warning on defensive code paths where a nullability precondition is
+// determined to have been violated, (2) warning additional times after an
+// initial direct violation has been discovered, and (3) warning after a direct
+// violation that has been implicitly or explicitly suppressed (for
+// example, with a cast of NULL to _Nonnull). In essence, once an invariant
+// violation is detected on a path, this checker will be esentially turned off
+// for the rest of the analysis
+//
+// The analyzer takes this approach (rather than generating a sink node) to
+// ensure coverage of defensive paths, which may be important for backwards
+// compatibility in codebases that were developed without nullability in mind.
+REGISTER_TRAIT_WITH_PROGRAMSTATE(InvariantViolated, bool)
 
 enum class NullConstraint { IsNull, IsNotNull, Unknown };
 
@@ -366,9 +385,9 @@ checkParamsForPreconditionViolation(cons
   return false;
 }
 
-static bool checkPreconditionViolation(ProgramStateRef State, ExplodedNode *N,
-   CheckerContext ) {
-  if (State->get())
+static bool checkInvariantViolation(ProgramStateRef State, ExplodedNode *N,
+  

Re: r264564 - P0138R2: Allow direct-list-initialization of an enumeration from an integral

[Reid Kleckner via cfe-commits]

I made the test pass in r264642 with a triple. We should deal with this
properly at some point, though.

On Sun, Mar 27, 2016 at 11:08 PM, Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rsmith
> Date: Mon Mar 28 01:08:37 2016
> New Revision: 264564
>
> URL: http://llvm.org/viewvc/llvm-project?rev=264564=rev
> Log:
> P0138R2: Allow direct-list-initialization of an enumeration from an
> integral
> value that can convert to the enum's underlying type.
>
> Added:
> cfe/trunk/test/CXX/dcl.decl/dcl.init/dcl.init.list/p3.cpp
>   - copied, changed from r264563,
> cfe/trunk/test/CXX/dcl.decl/dcl.init/dcl.init.list/p3-0x.cpp
> Removed:
> cfe/trunk/test/CXX/dcl.decl/dcl.init/dcl.init.list/p3-0x.cpp
> Modified:
> cfe/trunk/lib/Sema/SemaInit.cpp
> cfe/trunk/lib/Sema/SemaOverload.cpp
> cfe/trunk/www/cxx_status.html
>
> Modified: cfe/trunk/lib/Sema/SemaInit.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaInit.cpp?rev=264564=264563=264564=diff
>
> ==
> --- cfe/trunk/lib/Sema/SemaInit.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaInit.cpp Mon Mar 28 01:08:37 2016
> @@ -3862,8 +3862,48 @@ static void TryListInitialization(Sema &
>}
>
>if (S.getLangOpts().CPlusPlus && !DestType->isAggregateType() &&
> -  InitList->getNumInits() == 1 &&
> -  InitList->getInit(0)->getType()->isRecordType()) {
> +  InitList->getNumInits() == 1) {
> +Expr *E = InitList->getInit(0);
> +
> +//   - Otherwise, if T is an enumeration with a fixed underlying type,
> +// the initializer-list has a single element v, and the
> initialization
> +// is direct-list-initialization, the object is initialized with
> the
> +// value T(v); if a narrowing conversion is required to convert v
> to
> +// the underlying type of T, the program is ill-formed.
> +auto *ET = DestType->getAs();
> +if (S.getLangOpts().CPlusPlus1z &&
> +Kind.getKind() == InitializationKind::IK_DirectList &&
> +ET && ET->getDecl()->isFixed() &&
> +!S.Context.hasSameUnqualifiedType(E->getType(), DestType) &&
> +(E->getType()->isIntegralOrEnumerationType() ||
> + E->getType()->isFloatingType())) {
> +  // There are two ways that T(v) can work when T is an enumeration
> type.
> +  // If there is either an implicit conversion sequence from v to T or
> +  // a conversion function that can convert from v to T, then we use
> that.
> +  // Otherwise, if v is of integral, enumeration, or floating-point
> type,
> +  // it is converted to the enumeration type via its underlying type.
> +  // There is no overlap possible between these two cases (except
> when the
> +  // source value is already of the destination type), and the first
> +  // case is handled by the general case for single-element lists
> below.
> +  ImplicitConversionSequence ICS;
> +  ICS.setStandard();
> +  ICS.Standard.setAsIdentityConversion();
> +  // If E is of a floating-point type, then the conversion is
> ill-formed
> +  // due to narrowing, but go through the motions in order to produce
> the
> +  // right diagnostic.
> +  ICS.Standard.Second = E->getType()->isFloatingType()
> +? ICK_Floating_Integral
> +: ICK_Integral_Conversion;
> +  ICS.Standard.setFromType(E->getType());
> +  ICS.Standard.setToType(0, E->getType());
> +  ICS.Standard.setToType(1, DestType);
> +  ICS.Standard.setToType(2, DestType);
> +  Sequence.AddConversionSequenceStep(ICS, ICS.Standard.getToType(2),
> + /*TopLevelOfInitList*/true);
> +  Sequence.RewrapReferenceInitList(Entity.getType(), InitList);
> +  return;
> +}
> +
>  //   - Otherwise, if the initializer list has a single element of
> type E
>  // [...references are handled above...], the object or reference
> is
>  // initialized from that element (by copy-initialization for
> @@ -3877,19 +3917,21 @@ static void TryListInitialization(Sema &
>  // copy-initialization. This only matters if we might use an
> 'explicit'
>  // conversion operator, so we only need to handle the cases where the
> source
>  // is of record type.
> -InitializationKind SubKind =
> -Kind.getKind() == InitializationKind::IK_DirectList
> -? InitializationKind::CreateDirect(Kind.getLocation(),
> -   InitList->getLBraceLoc(),
> -   InitList->getRBraceLoc())
> -: Kind;
> -Expr *SubInit[1] = { InitList->getInit(0) };
> -Sequence.InitializeFrom(S, Entity, SubKind, SubInit,
> -/*TopLevelOfInitList*/true,
> -TreatUnavailableAsInvalid);
> -if (Sequence)
> -  

r264642 - Paper over the Windows-only enum initialization test failure until the bug is fixed

[Reid Kleckner via cfe-commits]

Author: rnk
Date: Mon Mar 28 15:13:55 2016
New Revision: 264642

URL: http://llvm.org/viewvc/llvm-project?rev=264642=rev
Log:
Paper over the Windows-only enum initialization test failure until the bug is 
fixed

Modified:
cfe/trunk/test/CXX/dcl.decl/dcl.init/dcl.init.list/p3.cpp

Modified: cfe/trunk/test/CXX/dcl.decl/dcl.init/dcl.init.list/p3.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CXX/dcl.decl/dcl.init/dcl.init.list/p3.cpp?rev=264642=264641=264642=diff
==
--- cfe/trunk/test/CXX/dcl.decl/dcl.init/dcl.init.list/p3.cpp (original)
+++ cfe/trunk/test/CXX/dcl.decl/dcl.init/dcl.init.list/p3.cpp Mon Mar 28 
15:13:55 2016
@@ -1,6 +1,7 @@
 // RUN: %clang_cc1 -std=c++11 -fsyntax-only -verify %s
 // RUN: %clang_cc1 -std=c++14 -fsyntax-only -verify %s
-// RUN: %clang_cc1 -std=c++1z -fsyntax-only -verify %s
+// FIXME: Remove the triple when PR27098 is fixed.
+// RUN: %clang_cc1 -std=c++1z -fsyntax-only -verify %s -triple 
%itanium_abi_triple
 
 namespace std {
   typedef decltype(sizeof(int)) size_t;


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

Re: [PATCH] D18304: [DarwinDriver] Increase the number of valid digits for ld version string

[Bruno Cardoso Lopes via cfe-commits]

bruno updated this revision to Diff 51828.
bruno added a comment.

Thanks Reid. The original idea was to have MaxDigits despite the size of the 
input array (but bounded by its size). But since there are no other users up to 
this point, your suggestion seems better, updated the patch to reflect it.


http://reviews.llvm.org/D18304

Files:
  include/clang/Driver/Driver.h
  lib/Driver/Driver.cpp
  lib/Driver/Tools.cpp
  test/Driver/darwin-ld.c

Index: test/Driver/darwin-ld.c
===
--- test/Driver/darwin-ld.c
+++ test/Driver/darwin-ld.c
@@ -303,3 +303,27 @@
 // RUN:   FileCheck --check-prefix=LINK-IFRAMEWORK %s
 // LINK-IFRAMEWORK: {{ld(.exe)?"}}
 // LINK-IFRAMEWORK: "-FBar"
+
+// Check ld64 accepts up to 5 digits with no extra characters
+// RUN: %clang -target x86_64-apple-darwin12 %s -### -o %t \
+// RUN:   -mlinker-version=133.3 2> %t.log
+// RUN: %clang -target x86_64-apple-darwin12 %s -### -o %t \
+// RUN:   -mlinker-version=133.3.0 2>> %t.log
+// RUN: %clang -target x86_64-apple-darwin12 %s -### -o %t \
+// RUN:   -mlinker-version=133.3.0.1 2>> %t.log
+// RUN: %clang -target x86_64-apple-darwin12 %s -### -o %t \
+// RUN:   -mlinker-version=133.3.0.1.2 2>> %t.log
+// RUN: %clang -target x86_64-apple-darwin12 %s -### -o %t \
+// RUN:   -mlinker-version=133.3.0.1.2.6 2>> %t.log
+// RUN: %clang -target x86_64-apple-darwin12 %s -### -o %t \
+// RUN:   -mlinker-version=133.3.0.1.a 2>> %t.log
+// RUN: %clang -target x86_64-apple-darwin12 %s -### -o %t \
+// RUN:   -mlinker-version=133.3.0.1a 2>> %t.log
+// RUN: FileCheck -check-prefix=LINK_VERSION_DIGITS %s < %t.log
+// LINK_VERSION_DIGITS-NOT: invalid version number in '-mlinker-version=133.3'
+// LINK_VERSION_DIGITS-NOT: invalid version number in '-mlinker-version=133.3.0'
+// LINK_VERSION_DIGITS-NOT: invalid version number in '-mlinker-version=133.3.0.1'
+// LINK_VERSION_DIGITS-NOT: invalid version number in '-mlinker-version=133.3.0.1.2'
+// LINK_VERSION_DIGITS: invalid version number in '-mlinker-version=133.3.0.1.2.6'
+// LINK_VERSION_DIGITS: invalid version number in '-mlinker-version=133.3.0.1.a'
+// LINK_VERSION_DIGITS: invalid version number in '-mlinker-version=133.3.0.1a'
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -7221,12 +7221,9 @@
   const Driver  = getToolChain().getDriver();
   const toolchains::MachO  = getMachOToolChain();
 
-  unsigned Version[3] = {0, 0, 0};
+  unsigned Version[5] = {0, 0, 0, 0, 0};
   if (Arg *A = Args.getLastArg(options::OPT_mlinker_version_EQ)) {
-bool HadExtra;
-if (!Driver::GetReleaseVersion(A->getValue(), Version[0], Version[1],
-   Version[2], HadExtra) ||
-HadExtra)
+if (!Driver::GetReleaseVersion(A->getValue(), Version))
   D.Diag(diag::err_drv_invalid_version_number) << A->getAsString(Args);
   }
 
Index: lib/Driver/Driver.cpp
===
--- lib/Driver/Driver.cpp
+++ lib/Driver/Driver.cpp
@@ -2533,6 +2533,35 @@
   return true;
 }
 
+/// Parse digits from a string \p Str and fulfill \p Digits with
+/// the parsed numbers. This method assumes that the max number of
+/// digits to look for is equal to Digits.size().
+///
+/// \return True if the entire string was parsed and there are
+/// no extra characters remaining at the end.
+bool Driver::GetReleaseVersion(const char *Str,
+   MutableArrayRef Digits) {
+  if (*Str == '\0')
+return false;
+
+  char *End;
+  unsigned CurDigit = 0;
+  unsigned MaxDigits = Digits.size();
+  while (CurDigit < MaxDigits) {
+unsigned Digit = (unsigned)strtol(Str, , 10);
+Digits[CurDigit] = Digit;
+if (*Str != '\0' && *End == '\0')
+  return true;
+if (*End != '.' || Str == End)
+  return false;
+Str = End + 1;
+CurDigit++;
+  }
+
+  // More digits than requested, bail out...
+  return false;
+}
+
 std::pair Driver::getIncludeExcludeOptionFlagMasks() const {
   unsigned IncludedFlagsBitmask = 0;
   unsigned ExcludedFlagsBitmask = options::NoDriverOption;
Index: include/clang/Driver/Driver.h
===
--- include/clang/Driver/Driver.h
+++ include/clang/Driver/Driver.h
@@ -475,6 +475,15 @@
   static bool GetReleaseVersion(const char *Str, unsigned ,
 unsigned , unsigned ,
 bool );
+
+  /// Parse digits from a string \p Str and fulfill \p Digits with
+  /// the parsed numbers. This method assumes that the max number of
+  /// digits to look for is equal to Digits.size().
+  ///
+  /// \return True if the entire string was parsed and there are
+  /// no extra characters remaining at the end.
+  static bool GetReleaseVersion(const char *Str,
+MutableArrayRef Digits);
 };
 
 /// 

Re: [PATCH] D17002: [lanai] Add Lanai backend to clang driver

[Eric Christopher via cfe-commits]

echristo added a subscriber: echristo.
echristo accepted this revision.
echristo added a reviewer: echristo.
echristo added a comment.

LGTM, thanks.

-eric


http://reviews.llvm.org/D17002



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

Re: [PATCH] D17002: [lanai] Add Lanai backend to clang driver

[Chandler Carruth via cfe-commits]

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

LGTM with the comments from David addressed and the comment below addressed.



Comment at: lib/Basic/Targets.cpp:6000-6001
@@ +5999,4 @@
+  break;
+default:
+  llvm_unreachable("Unhandled target CPU");
+}

Instead of a default, make this a covering switch? We get warnings that way if 
someone adds a CPU and doesn't add a case.


http://reviews.llvm.org/D17002



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

Re: [PATCH] D18489: [PGO, clang] Comment how function pointers for indirect calls are mapped to function names

[Xinliang David Li via cfe-commits]

Sure.

thanks,

David

On Mon, Mar 28, 2016 at 12:41 PM, Adam Nemet  wrote:

> anemet added a comment.
>
> In http://reviews.llvm.org/D18489#384851, @davidxl wrote:
>
> > What I meant is that putting the comments in InstrProfData.inc file, and
> >  update the one in CodeGenPGO.cpp to reference that.
>
>
> Sounds good.  You mean CGCall.cpp instead of CodeGenPGO.cpp though,
> correct?
>
> So to summarize, I'll move this comment to InstrProfData.inc and just have
> a reference to it in CGCall.cpp before the call to valueProfile.
>
> OK?
>
>
> http://reviews.llvm.org/D18489
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D18489: [PGO, clang] Comment how function pointers for indirect calls are mapped to function names

[Adam Nemet via cfe-commits]

anemet added a comment.

In http://reviews.llvm.org/D18489#384851, @davidxl wrote:

> What I meant is that putting the comments in InstrProfData.inc file, and
>  update the one in CodeGenPGO.cpp to reference that.


Sounds good.  You mean CGCall.cpp instead of CodeGenPGO.cpp though, correct?

So to summarize, I'll move this comment to InstrProfData.inc and just have a 
reference to it in CGCall.cpp before the call to valueProfile.

OK?


http://reviews.llvm.org/D18489



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

Re: [PATCH] D18489: [PGO, clang] Comment how function pointers for indirect calls are mapped to function names

[Xinliang David Li via cfe-commits]

What I meant is that putting the comments in InstrProfData.inc file, and
update the one in CodeGenPGO.cpp to reference that.

David

On Mon, Mar 28, 2016 at 12:35 PM, Xinliang David Li 
wrote:

>
>
> On Mon, Mar 28, 2016 at 12:31 PM, Adam Nemet  wrote:
>
>> anemet added inline comments.
>>
>> 
>> Comment at: lib/CodeGen/CodeGenPGO.cpp:758
>> @@ -757,1 +757,3 @@
>>
>> +  // During instrumentation, function pointers are collected for the
>> different
>> +  // indirect call targets.  Then as part of the conversion from raw to
>> merged
>> 
>> anemet wrote:
>> > davidxl wrote:
>> > > anemet wrote:
>> > > > davidxl wrote:
>> > > > > CodeGenPGO::valueProfile is a common API which can also be used
>> for other kinds of value profile, so the comments belong to the callsite of
>> this method in CGCall.cpp.
>> > > > >
>> > > > > Suggested wording:
>> > > > >
>> > > > > For indirect function call value profiling, the addresses of the
>> target functions are profiled by the instrumented code. The target
>> addresses are written in the raw profile data and converted to target
>> function name's MD5 hash by the profile reader during deserialization.
>> > > > Hi David,
>> > > >
>> > > > Thanks for taking a look.
>> > > >
>> > > > I don't mind rewording the comment if you have some specific issues
>> but your version drops many of the details that was painful for me to
>> discover.  I carefully worded my comment to describe some of the design
>> details for indirect profiling that are not covered elsewhere:
>> > > >
>> > > > 1) the remapping from function pointer to hashes of function names
>> happens during profdata merging
>> > > >
>> > > >   It was surprisingly hard to figure out what the PGO file
>> contained for indirect call targets: function pointers or func name
>> hashes?  And of course as stated, the answer is -- it depends.
>> > > >
>> > > > 2) the remapping happens pretty deep in the infrastructure code
>> during deserializing of the rawdata
>> > > >
>> > > >   I was looking at several more logical places to find where this
>> happens and this was a bit unexpected location for this functionality.
>> > > >
>> > > > 3) how do we know the function addresses necessary for the mapping
>> from function address -> func name -> hash
>> > > >
>> > > >   The entire code to populate the FunctionAddr using macro magic in
>> InstrProfiling::getOrCreateRegionCounters is pretty hard to follow.  I much
>> rather have an overview of the logic somewhere centrally.
>> > > >
>> > > > From the above list I feel that your version dropped 1 and 3 and
>> only kept 2.  Of course, feel free to add more context to my comments and
>> fix inaccuracies/oversimplifications but I would want want to drop any of
>> the points mentioned above.
>> > > >
>> > > > Thanks.
>> > > Actually bullet 1 is not dropped from my suggested version: each time
>> when a raw profile data is read, the reader interface will covert the
>> address into MD5 -- profile merging is simply a user of the reader.
>> > >
>> > > About bullet 3, it is ok to add it if you think it is useful. ( I did
>> not suggest it because ProfData is needed here is not for the purpose of
>> conversion, but to pass the context for the runtime to find/set the counter
>> arrays.)
>> > > Actually bullet 1 is not dropped from my suggested version: each time
>> when a raw profile data is read, the reader interface will covert the
>> address into MD5 -- profile merging is simply a user of the reader.
>> >
>> > Sure but that is still pretty implicit.  I'd like to describe this in
>> terms of the well established phases of PGO: instrumentation, profile
>> merge,  recompile with profile data.
>> >
>> > How about:
>> >
>> > ```
>> > For indirect function call value profiling, the addresses of the target
>> functions are profiled by the instrumented code. The target addresses are
>> written in the raw profile data and converted to target function name's MD5
>> hash by the profile reader during deserialization.  Typically, this happens
>> when the the raw profile data is read during profile merging.
>> > ```
>> >
>> > > About bullet 3, it is ok to add it if you think it is useful. ( I did
>> not suggest it because ProfData is needed here is not for the purpose of
>> conversion, but to pass the context for the runtime to find/set the counter
>> arrays.)
>> >
>> > I am not completely sure I understand what you're saying here but if
>> you mean that the comment does not really apply to the surrounding code
>> then that I guess is expected.  I wanted to give a high-level overview of
>> *what* we collect at run-time, and *how* we map that into function names
>> hashes that are then used in the IR.
>> >
>> > I can also put this in the function comment if you think that's better.
>> >
>> David,
>>
>> > CodeGenPGO::valueProfile is a common API which can also be used for
>> other kinds of value profile, so the comments belong to the callsite 

Re: [PATCH] D18489: [PGO, clang] Comment how function pointers for indirect calls are mapped to function names

[Xinliang David Li via cfe-commits]

On Mon, Mar 28, 2016 at 12:31 PM, Adam Nemet  wrote:

> anemet added inline comments.
>
> 
> Comment at: lib/CodeGen/CodeGenPGO.cpp:758
> @@ -757,1 +757,3 @@
>
> +  // During instrumentation, function pointers are collected for the
> different
> +  // indirect call targets.  Then as part of the conversion from raw to
> merged
> 
> anemet wrote:
> > davidxl wrote:
> > > anemet wrote:
> > > > davidxl wrote:
> > > > > CodeGenPGO::valueProfile is a common API which can also be used
> for other kinds of value profile, so the comments belong to the callsite of
> this method in CGCall.cpp.
> > > > >
> > > > > Suggested wording:
> > > > >
> > > > > For indirect function call value profiling, the addresses of the
> target functions are profiled by the instrumented code. The target
> addresses are written in the raw profile data and converted to target
> function name's MD5 hash by the profile reader during deserialization.
> > > > Hi David,
> > > >
> > > > Thanks for taking a look.
> > > >
> > > > I don't mind rewording the comment if you have some specific issues
> but your version drops many of the details that was painful for me to
> discover.  I carefully worded my comment to describe some of the design
> details for indirect profiling that are not covered elsewhere:
> > > >
> > > > 1) the remapping from function pointer to hashes of function names
> happens during profdata merging
> > > >
> > > >   It was surprisingly hard to figure out what the PGO file contained
> for indirect call targets: function pointers or func name hashes?  And of
> course as stated, the answer is -- it depends.
> > > >
> > > > 2) the remapping happens pretty deep in the infrastructure code
> during deserializing of the rawdata
> > > >
> > > >   I was looking at several more logical places to find where this
> happens and this was a bit unexpected location for this functionality.
> > > >
> > > > 3) how do we know the function addresses necessary for the mapping
> from function address -> func name -> hash
> > > >
> > > >   The entire code to populate the FunctionAddr using macro magic in
> InstrProfiling::getOrCreateRegionCounters is pretty hard to follow.  I much
> rather have an overview of the logic somewhere centrally.
> > > >
> > > > From the above list I feel that your version dropped 1 and 3 and
> only kept 2.  Of course, feel free to add more context to my comments and
> fix inaccuracies/oversimplifications but I would want want to drop any of
> the points mentioned above.
> > > >
> > > > Thanks.
> > > Actually bullet 1 is not dropped from my suggested version: each time
> when a raw profile data is read, the reader interface will covert the
> address into MD5 -- profile merging is simply a user of the reader.
> > >
> > > About bullet 3, it is ok to add it if you think it is useful. ( I did
> not suggest it because ProfData is needed here is not for the purpose of
> conversion, but to pass the context for the runtime to find/set the counter
> arrays.)
> > > Actually bullet 1 is not dropped from my suggested version: each time
> when a raw profile data is read, the reader interface will covert the
> address into MD5 -- profile merging is simply a user of the reader.
> >
> > Sure but that is still pretty implicit.  I'd like to describe this in
> terms of the well established phases of PGO: instrumentation, profile
> merge,  recompile with profile data.
> >
> > How about:
> >
> > ```
> > For indirect function call value profiling, the addresses of the target
> functions are profiled by the instrumented code. The target addresses are
> written in the raw profile data and converted to target function name's MD5
> hash by the profile reader during deserialization.  Typically, this happens
> when the the raw profile data is read during profile merging.
> > ```
> >
> > > About bullet 3, it is ok to add it if you think it is useful. ( I did
> not suggest it because ProfData is needed here is not for the purpose of
> conversion, but to pass the context for the runtime to find/set the counter
> arrays.)
> >
> > I am not completely sure I understand what you're saying here but if you
> mean that the comment does not really apply to the surrounding code then
> that I guess is expected.  I wanted to give a high-level overview of *what*
> we collect at run-time, and *how* we map that into function names hashes
> that are then used in the IR.
> >
> > I can also put this in the function comment if you think that's better.
> >
> David,
>
> > CodeGenPGO::valueProfile is a common API which can also be used for
> other kinds of value profile, so the comments belong to the callsite of
> this method in CGCall.cpp.
>
> How would you actually feel about moving this comment to InstrProfData.inc
> as well, just before the definition of IPVK_IndirectCallTarget?
>
> I think that's a better place in terms of its centrality since this
> applies to both early and late instrumentation.  What do you think?
>
>

Re: [PATCH] D18489: [PGO, clang] Comment how function pointers for indirect calls are mapped to function names

[Adam Nemet via cfe-commits]

anemet added inline comments.


Comment at: lib/CodeGen/CodeGenPGO.cpp:758
@@ -757,1 +757,3 @@
 
+  // During instrumentation, function pointers are collected for the different
+  // indirect call targets.  Then as part of the conversion from raw to merged

anemet wrote:
> davidxl wrote:
> > anemet wrote:
> > > davidxl wrote:
> > > > CodeGenPGO::valueProfile is a common API which can also be used for 
> > > > other kinds of value profile, so the comments belong to the callsite of 
> > > > this method in CGCall.cpp.
> > > > 
> > > > Suggested wording:
> > > > 
> > > > For indirect function call value profiling, the addresses of the target 
> > > > functions are profiled by the instrumented code. The target addresses 
> > > > are written in the raw profile data and converted to target function 
> > > > name's MD5 hash by the profile reader during deserialization.
> > > Hi David,
> > > 
> > > Thanks for taking a look.
> > > 
> > > I don't mind rewording the comment if you have some specific issues but 
> > > your version drops many of the details that was painful for me to 
> > > discover.  I carefully worded my comment to describe some of the design 
> > > details for indirect profiling that are not covered elsewhere:
> > > 
> > > 1) the remapping from function pointer to hashes of function names 
> > > happens during profdata merging
> > > 
> > >   It was surprisingly hard to figure out what the PGO file contained for 
> > > indirect call targets: function pointers or func name hashes?  And of 
> > > course as stated, the answer is -- it depends.
> > > 
> > > 2) the remapping happens pretty deep in the infrastructure code during 
> > > deserializing of the rawdata
> > > 
> > >   I was looking at several more logical places to find where this happens 
> > > and this was a bit unexpected location for this functionality.
> > > 
> > > 3) how do we know the function addresses necessary for the mapping from 
> > > function address -> func name -> hash
> > > 
> > >   The entire code to populate the FunctionAddr using macro magic in 
> > > InstrProfiling::getOrCreateRegionCounters is pretty hard to follow.  I 
> > > much rather have an overview of the logic somewhere centrally.
> > > 
> > > From the above list I feel that your version dropped 1 and 3 and only 
> > > kept 2.  Of course, feel free to add more context to my comments and fix 
> > > inaccuracies/oversimplifications but I would want want to drop any of the 
> > > points mentioned above.
> > > 
> > > Thanks.
> > Actually bullet 1 is not dropped from my suggested version: each time when 
> > a raw profile data is read, the reader interface will covert the address 
> > into MD5 -- profile merging is simply a user of the reader. 
> > 
> > About bullet 3, it is ok to add it if you think it is useful. ( I did not 
> > suggest it because ProfData is needed here is not for the purpose of 
> > conversion, but to pass the context for the runtime to find/set the counter 
> > arrays.)
> > Actually bullet 1 is not dropped from my suggested version: each time when 
> > a raw profile data is read, the reader interface will covert the address 
> > into MD5 -- profile merging is simply a user of the reader.
> 
> Sure but that is still pretty implicit.  I'd like to describe this in terms 
> of the well established phases of PGO: instrumentation, profile merge,  
> recompile with profile data.
> 
> How about:
> 
> ```
> For indirect function call value profiling, the addresses of the target 
> functions are profiled by the instrumented code. The target addresses are 
> written in the raw profile data and converted to target function name's MD5 
> hash by the profile reader during deserialization.  Typically, this happens 
> when the the raw profile data is read during profile merging.
> ``` 
> 
> > About bullet 3, it is ok to add it if you think it is useful. ( I did not 
> > suggest it because ProfData is needed here is not for the purpose of 
> > conversion, but to pass the context for the runtime to find/set the counter 
> > arrays.)
> 
> I am not completely sure I understand what you're saying here but if you mean 
> that the comment does not really apply to the surrounding code then that I 
> guess is expected.  I wanted to give a high-level overview of *what* we 
> collect at run-time, and *how* we map that into function names hashes that 
> are then used in the IR.
> 
> I can also put this in the function comment if you think that's better.
> 
David,

> CodeGenPGO::valueProfile is a common API which can also be used for other 
> kinds of value profile, so the comments belong to the callsite of this method 
> in CGCall.cpp.

How would you actually feel about moving this comment to InstrProfData.inc as 
well, just before the definition of IPVK_IndirectCallTarget?

I think that's a better place in terms of its centrality since this applies to 
both early and late instrumentation.  What do you think?

Adam 

Re: [PATCH] D17861: [OpenCL] Accept __attribute__((nosvm))

[Yaxun Liu via cfe-commits]

yaxunl removed rL LLVM as the repository for this revision.
yaxunl updated this revision to Diff 51821.
yaxunl marked 4 inline comments as done.
yaxunl added a comment.

Revised by Aaron's and Anastasia's comments.

Changed error/warning message for invalid usage of nosvm attribute.


http://reviews.llvm.org/D17861

Files:
  include/clang/Basic/Attr.td
  include/clang/Basic/AttrDocs.td
  include/clang/Basic/DiagnosticSemaKinds.td
  lib/Sema/SemaDeclAttr.cpp
  lib/Sema/SemaStmtAttr.cpp
  test/SemaOpenCL/nosvm.cl

Index: test/SemaOpenCL/nosvm.cl
===
--- /dev/null
+++ test/SemaOpenCL/nosvm.cl
@@ -0,0 +1,14 @@
+// RUN: %clang_cc1 -verify %s
+// RUN: %clang_cc1 -verify -cl-std=CL2.0 -D CL20 %s
+// RUN: %clang_cc1 -verify -x c -D NOCL %s
+
+#ifndef NOCL
+kernel void f(__attribute__((nosvm)) global int* a);
+#ifndef CL20
+// expected-error@-2 {{'nosvm' attribute requires OpenCL version 2.0}}
+#endif
+__attribute__((nosvm)) void g(); // expected-warning {{'nosvm' attribute only applies to variables}}
+
+#else
+void f(__attribute__((nosvm)) int* a); // expected-warning {{unknown attribute 'nosvm' ignored}}
+#endif
Index: lib/Sema/SemaStmtAttr.cpp
===
--- lib/Sema/SemaStmtAttr.cpp
+++ lib/Sema/SemaStmtAttr.cpp
@@ -221,7 +221,7 @@
 
   if (S.getLangOpts().OpenCLVersion < 200) {
 S.Diag(A.getLoc(), diag::err_attribute_requires_opencl_version)
-<< A.getName() << "2.0";
+<< A.getName() << "2.0" << 1;
 return nullptr;
   }
 
Index: lib/Sema/SemaDeclAttr.cpp
===
--- lib/Sema/SemaDeclAttr.cpp
+++ lib/Sema/SemaDeclAttr.cpp
@@ -5206,6 +5206,17 @@
 D->addAttr(Internal);
 }
 
+static void handleOpenCLNoSVMAttr(Sema , Decl *D, const AttributeList ) {
+  if (!S.LangOpts.OpenCL) {
+S.Diag(Attr.getLoc(), diag::warn_unknown_attribute_ignored)
+<< Attr.getName();
+return;
+  }
+  if (S.LangOpts.OpenCLVersion != 200)
+S.Diag(Attr.getLoc(), diag::err_attribute_requires_opencl_version)
+<< Attr.getName() << "2.0" << 0;
+}
+
 /// Handles semantic checking for features that are common to all attributes,
 /// such as checking whether a parameter was properly specified, or the correct
 /// number of arguments were passed, etc.
@@ -5698,6 +5709,9 @@
   case AttributeList::AT_SwiftIndirectResult:
 handleParameterABIAttr(S, D, Attr, ParameterABI::SwiftIndirectResult);
 break;
+  case AttributeList::AT_OpenCLNoSVM:
+handleOpenCLNoSVMAttr(S, D, Attr);
+break;
   case AttributeList::AT_InternalLinkage:
 handleInternalLinkageAttr(S, D, Attr);
 break;
Index: include/clang/Basic/DiagnosticSemaKinds.td
===
--- include/clang/Basic/DiagnosticSemaKinds.td
+++ include/clang/Basic/DiagnosticSemaKinds.td
@@ -2129,7 +2129,7 @@
 def err_attribute_requires_positive_integer : Error<
   "%0 attribute requires a positive integral compile time constant expression">;
 def err_attribute_requires_opencl_version : Error<
-  "%0 attribute requires OpenCL version %1 or above">;
+  "%0 attribute requires OpenCL version %1%select{| or above}2">;
 def warn_unsupported_target_attribute
 : Warning<"Ignoring unsupported '%0' in the target attribute string">,
 InGroup;
Index: include/clang/Basic/AttrDocs.td
===
--- include/clang/Basic/AttrDocs.td
+++ include/clang/Basic/AttrDocs.td
@@ -1745,6 +1745,17 @@
   }];
 }
 
+def OpenCLNoSVMDocs : Documentation {
+  let Category = DocCatVariable;
+  let Content = [{
+OpenCL 2.0 supports the optional ``__attribute__((nosvm))`` qualifier for
+pointer variable. It informs the compiler that the pointer does not refer
+to a shared virtual memory region. See OpenCL v2.0 s6.7.2 for details.
+
+Since it is not widely used and has been removed from OpenCL 2.1, it is ignored
+by Clang.
+  }];
+}
 def NullabilityDocs : DocumentationCategory<"Nullability Attributes"> {
   let Content = [{
 Whether a particular pointer may be "null" is an important concern when working with pointers in the C family of languages. The various nullability attributes indicate whether a particular pointer can be null or not, which makes APIs more expressive and can help static analysis tools identify bugs involving null pointers. Clang supports several kinds of nullability attributes: the ``nonnull`` and ``returns_nonnull`` attributes indicate which function or method parameters and result types can never be null, while nullability type qualifiers indicate which pointer types can be null (``_Nullable``) or cannot be null (``_Nonnull``). 
Index: include/clang/Basic/Attr.td
===
--- include/clang/Basic/Attr.td
+++ include/clang/Basic/Attr.td
@@ -719,6 +719,13 @@
   let Documentation = 

r264621 - This file was accidentally committed with bad line endings. Fixed...

[Mike Spertus via cfe-commits]

Author: mps
Date: Mon Mar 28 14:08:27 2016
New Revision: 264621

URL: http://llvm.org/viewvc/llvm-project?rev=264621=rev
Log:
This file was accidentally committed with bad line endings. Fixed...

Modified:
cfe/trunk/utils/ClangVisualizers/CMakeLists.txt

Modified: cfe/trunk/utils/ClangVisualizers/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/utils/ClangVisualizers/CMakeLists.txt?rev=264621=264620=264621=diff
==
--- cfe/trunk/utils/ClangVisualizers/CMakeLists.txt (original)
+++ cfe/trunk/utils/ClangVisualizers/CMakeLists.txt Mon Mar 28 14:08:27 2016
@@ -1,7 +1,7 @@
-# Do this by hand instead of using add_llvm_utilities(), which
-# tries to create a corresponding executable, which we don't want.
-if (LLVM_ADD_NATIVE_VISUALIZERS_TO_SOLUTION)
-  set(CLANG_VISUALIZERS clang.natvis)
-  add_custom_target(ClangVisualizers SOURCES ${CLANG_VISUALIZERS})
-  set_target_properties(ClangVisualizers PROPERTIES FOLDER "Utils")
-endif()
+# Do this by hand instead of using add_llvm_utilities(), which
+# tries to create a corresponding executable, which we don't want.
+if (LLVM_ADD_NATIVE_VISUALIZERS_TO_SOLUTION)
+  set(CLANG_VISUALIZERS clang.natvis)
+  add_custom_target(ClangVisualizers SOURCES ${CLANG_VISUALIZERS})
+  set_target_properties(ClangVisualizers PROPERTIES FOLDER "Utils")
+endif()


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

Re: [PATCH] D16989: Change interpretation of function definition in friend declaration of template class.

[Serge Pavlov via cfe-commits]

2016-03-18 20:50 GMT+06:00 Richard Smith :

> rsmith added a comment.
>
> Can we instead not add the function to the redeclaration chain until it's
> instantiated (like we do if it's dependent)?
>
>
I prepared implementation that uses this approach. In this variant
information about potential definitions is lost, in some cases it makes
difficult to make analysis. For instance we can diagnose misfit of
declarations in the code:
```
void func9(int);  // expected-note{{previous declaration is here}}
template struct C9a {
  friend int func9(int);  // expected-error{{functions that differ only in
their return type cannot be overloaded}}
};
```
but not in the case:
```
template struct C9a {
  friend int func9(int);
};
void func9(int);
```
Otherwise both approaches seem almost equivalent.

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

Re: [PATCH] D16989: Change interpretation of function definition in friend declaration of template class.

[Serge Pavlov via cfe-commits]

sepavloff updated this revision to Diff 51817.
sepavloff added a comment.

Changed implementation

This implementation uses another approach. Previous version of the patch put 
friend functions
into redeclaration chains but modified search algorithm so that it skipped such 
functions. In
this version such functions are not included into redeclaration chains at all.


http://reviews.llvm.org/D16989

Files:
  include/clang/Sema/Sema.h
  lib/Sema/SemaDecl.cpp
  lib/Sema/SemaDeclCXX.cpp
  lib/Sema/SemaTemplateInstantiateDecl.cpp
  test/SemaCXX/PR25848.cpp
  test/SemaCXX/friend2.cpp

Index: test/SemaCXX/friend2.cpp
===
--- /dev/null
+++ test/SemaCXX/friend2.cpp
@@ -0,0 +1,145 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s -std=c++11
+
+// If a friend function is defined in several non-template classes,
+// it is an error.
+
+void func1(int);
+struct C1a {
+  friend void func1(int) {}  // expected-note{{previous definition is here}}
+};
+struct C1b {
+  friend void func1(int) {}  // expected-error{{redefinition of 'func1'}}
+};
+
+
+// If a friend function is defined in both non-template and template
+// classes it is an error only if the template is instantiated.
+
+void func2(int);
+struct C2a {
+  friend void func2(int) {}
+};
+template struct C2b {
+  friend void func2(int) {}
+};
+
+void func3(int);
+struct C3a {
+  friend void func3(int) {}  // expected-note{{previous definition is here}}
+};
+template struct C3b {
+  friend void func3(int) {}  // expected-error{{redefinition of 'func3'}}
+};
+C3b c3;  // expected-note{{in instantiation of template class 'C3b' requested here}}
+
+
+// If a friend function is defined in several template classes it is an error
+// only if several templates are instantiated.
+
+void func4(int);
+template struct C4a {
+  friend void func4(int) {}
+};
+template struct C4b {
+  friend void func4(int) {}
+};
+
+
+void func5(int);
+template struct C5a {
+  friend void func5(int) {}
+};
+template struct C5b {
+  friend void func5(int) {}
+};
+C5a c5a;
+
+void func6(int);
+template struct C6a {
+  friend void func6(int) {}  // expected-note{{previous definition is here}}
+};
+template struct C6b {
+  friend void func6(int) {}  // expected-error{{redefinition of 'func6'}}
+};
+C6a c6a;
+C6b c6b;  // expected-note{{in instantiation of template class 'C6b' requested here}}
+
+void func7(int);
+template struct C7 {
+  friend void func7(int) {}  // expected-error{{redefinition of 'func7'}}
+ // expected-note@-1{{previous definition is here}}
+};
+C7 c7a;
+C7 c7b;  // expected-note{{in instantiation of template class 'C7' requested here}}
+
+
+// Even if clases are not instantiated and hence friend functions defined in them are not
+// available, their declarations must be checked.
+
+void func8(int);  // expected-note{{previous declaration is here}}
+template struct C8a {
+  friend long func8(int);  // expected-error{{functions that differ only in their return type cannot be overloaded}}
+};
+
+void func9(int);  // expected-note{{previous declaration is here}}
+template struct C9a {
+  friend int func9(int);  // expected-error{{functions that differ only in their return type cannot be overloaded}}
+};
+
+void func10(int);  // expected-note{{previous declaration is here}}
+template struct C10a {
+  friend int func10(int);  // expected-error{{functions that differ only in their return type cannot be overloaded}}
+};
+
+
+namespace pr22307 {
+
+struct t {
+  friend int leak(t);
+};
+
+template
+struct m {
+  friend int leak(t) { return sizeof(v); }  // expected-error{{redefinition of 'leak'}} expected-note{{previous definition is here}}
+};
+
+template struct m;
+template struct m;  // expected-note{{in instantiation of template class 'pr22307::m' requested here}}
+
+int main() {
+  leak(t());
+}
+
+}
+
+namespace pr17923 {
+
+void f(unsigned long long);
+
+template struct X {
+  friend void f(unsigned long long) {
+ T t;
+  }
+};
+
+int main() { f(1234); }
+
+}
+
+namespace pr17923a {
+
+int get();
+
+template< int value >
+class set {
+  friend int get()
+{ return value; } // return 0; is OK
+};
+
+template class set< 5 >;
+
+int main() {
+  get();
+}
+
+}
Index: test/SemaCXX/PR25848.cpp
===
--- /dev/null
+++ test/SemaCXX/PR25848.cpp
@@ -0,0 +1,17 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+
+struct A;
+typedef int A::* P;
+
+inline P g();  // expected-warning{{inline function 'g' is not defined}}
+
+template
+struct R {
+  friend P g() {
+return M;
+  }
+};
+
+void m() {
+  g();  // expected-note{{used here}}
+}
Index: lib/Sema/SemaTemplateInstantiateDecl.cpp
===
--- lib/Sema/SemaTemplateInstantiateDecl.cpp
+++ lib/Sema/SemaTemplateInstantiateDecl.cpp
@@ -1599,7 +1599,7 @@
   }
 
   SemaRef.CheckFunctionDeclaration(/*Scope*/ nullptr, 

Re: [PATCH] D18498: Auto-install Clang Visual Studio visualizers for VS2015 and up

[Alexander Riccio via cfe-commits]

ariccio added a comment.

In http://reviews.llvm.org/D18498#384711, @mspertus wrote:

> I installed both VS2015 and VS2013 on my laptop and saw the correct solution 
> files built by cmake.


Btw, make sure you're running the latest updates for both Visual Studio, else 
you'll get funny build errors (probably about /Zc:strictStrings).


http://reviews.llvm.org/D18498



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

Re: [PATCH] D18088: Add a new warning to notify users of mismatched SDK and deployment target

[Chris Bieneman via cfe-commits]

beanz updated this revision to Diff 51813.
beanz added a comment.

Updates based on review feedback.


http://reviews.llvm.org/D18088

Files:
  include/clang/Basic/DiagnosticDriverKinds.td
  lib/Driver/ToolChains.cpp
  lib/Driver/ToolChains.h
  test/Driver/incompatible_sysroot.c

Index: test/Driver/incompatible_sysroot.c
===
--- /dev/null
+++ test/Driver/incompatible_sysroot.c
@@ -0,0 +1,12 @@
+// RUN: %clang -Wincompatible-sysroot -isysroot SDKs/MacOSX10.9.sdk 
-mios-version-min=9.0 -S -o - %s 2>&1 | FileCheck -check-prefix CHECK-OSX-IOS %s
+// RUN: %clang -Wincompatible-sysroot -isysroot SDKs/iPhoneOS9.2.sdk 
-mwatchos-version-min=2.0 -S -o - %s 2>&1 | FileCheck -check-prefix 
CHECK-IOS-WATCHOS %s
+// RUN: %clang -Wincompatible-sysroot -isysroot SDKs/iPhoneOS9.2.sdk 
-mtvos-version-min=9.0 -S -o - %s 2>&1 | FileCheck -check-prefix CHECK-IOS-TVOS 
%s
+// RUN: %clang -Wincompatible-sysroot -isysroot SDKs/iPhoneSimulator9.2.sdk 
-mios-version-min=9.0 -S -o - %s 2>&1 | FileCheck -check-prefix 
CHECK-IOS-IOSSIM %s
+// RUN: %clang -Wno-incompatible-sysroot -isysroot SDKs/MacOSX10.9.sdk 
-mios-version-min=9.0 -S -o - %s 2>&1 | FileCheck -check-prefix 
CHECK-OSX-IOS-DISABLED %s
+
+int main() { return 0; }
+// CHECK-OSX-IOS: warning: using sysroot for 'MacOSX10.9' but targeting 
'iPhone'
+// CHECK-IOS-WATCHOS: warning: using sysroot for 'iPhoneOS9.2' but targeting 
'Watch'
+// CHECK-IOS-TVOS: warning: using sysroot for 'iPhoneOS9.2' but targeting 
'AppleTV'
+// CHECK-IOS-IOSSIM-NOT: warning: using sysroot for '{{.*}}' but targeting 
'{{.*}}'
+// CHECK-OSX-IOS-DISABLED-NOT: warning: using sysroot for '{{.*}}' but 
targeting '{{.*}}'
Index: lib/Driver/ToolChains.h
===
--- lib/Driver/ToolChains.h
+++ lib/Driver/ToolChains.h
@@ -496,6 +496,7 @@
 return TargetVersion < VersionTuple(V0, V1, V2);
   }
 
+  StringRef getPlatformFamily() const;
   StringRef getOSLibraryNameSuffix() const;
 
 public:
Index: lib/Driver/ToolChains.cpp
===
--- lib/Driver/ToolChains.cpp
+++ lib/Driver/ToolChains.cpp
@@ -329,6 +329,23 @@
   }
 }
 
+StringRef Darwin::getPlatformFamily() const {
+  switch (TargetPlatform) {
+case DarwinPlatformKind::MacOS:
+  return "MacOSX";
+case DarwinPlatformKind::IPhoneOS:
+case DarwinPlatformKind::IPhoneOSSimulator:
+  return "iPhone";
+case DarwinPlatformKind::TvOS:
+case DarwinPlatformKind::TvOSSimulator:
+  return "AppleTV";
+case DarwinPlatformKind::WatchOS:
+case DarwinPlatformKind::WatchOSSimulator:
+  return "Watch";
+  }
+  llvm_unreachable("Unsupported platform");
+}
+
 StringRef Darwin::getOSLibraryNameSuffix() const {
   switch(TargetPlatform) {
   case DarwinPlatformKind::MacOS:
@@ -695,6 +712,19 @@
 Platform = WatchOSSimulator;
 
   setTarget(Platform, Major, Minor, Micro);
+
+  if (const Arg *A = Args.getLastArg(options::OPT_isysroot)) {
+StringRef isysroot = A->getValue();
+// Assume SDK has path: SOME_PATH/SDKs/PlatformXX.YY.sdk
+size_t BeginSDK = isysroot.rfind("SDKs/");
+size_t EndSDK = isysroot.rfind(".sdk");
+if (BeginSDK != StringRef::npos && EndSDK != StringRef::npos) {
+  StringRef SDK = isysroot.slice(BeginSDK + 5, EndSDK);
+  if (!SDK.startswith(getPlatformFamily()))
+getDriver().Diag(diag::warn_incompatible_sysroot)
+<< SDK << getPlatformFamily();
+}
+  }
 }
 
 void DarwinClang::AddCXXStdlibLibArgs(const ArgList ,
Index: include/clang/Basic/DiagnosticDriverKinds.td
===
--- include/clang/Basic/DiagnosticDriverKinds.td
+++ include/clang/Basic/DiagnosticDriverKinds.td
@@ -195,6 +195,8 @@
   "precompiled header '%0' was ignored because '%1' is not first '-include'">;
 def warn_missing_sysroot : Warning<"no such sysroot directory: '%0'">,
   InGroup>;
+def warn_incompatible_sysroot : Warning<"using sysroot for '%0' but targeting 
'%1'">,
+  InGroup>;
 def warn_debug_compression_unavailable : Warning<"cannot compress debug 
sections (zlib not installed)">,
   InGroup>;
 def warn_drv_enabling_rtti_with_exceptions : Warning<


Index: test/Driver/incompatible_sysroot.c
===
--- /dev/null
+++ test/Driver/incompatible_sysroot.c
@@ -0,0 +1,12 @@
+// RUN: %clang -Wincompatible-sysroot -isysroot SDKs/MacOSX10.9.sdk -mios-version-min=9.0 -S -o - %s 2>&1 | FileCheck -check-prefix CHECK-OSX-IOS %s
+// RUN: %clang -Wincompatible-sysroot -isysroot SDKs/iPhoneOS9.2.sdk -mwatchos-version-min=2.0 -S -o - %s 2>&1 | FileCheck -check-prefix CHECK-IOS-WATCHOS %s
+// RUN: %clang -Wincompatible-sysroot -isysroot SDKs/iPhoneOS9.2.sdk -mtvos-version-min=9.0 -S -o - %s 2>&1 | FileCheck 

r264610 - Convert to Unix line endings due to previous commit error.

[Mike Spertus via cfe-commits]

Author: mps
Date: Mon Mar 28 13:24:22 2016
New Revision: 264610

URL: http://llvm.org/viewvc/llvm-project?rev=264610=rev
Log:
Convert to Unix line endings due to previous commit error.

Modified:
cfe/trunk/CMakeLists.txt

Modified: cfe/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/CMakeLists.txt?rev=264610=264609=264610=diff
==
--- cfe/trunk/CMakeLists.txt (original)
+++ cfe/trunk/CMakeLists.txt Mon Mar 28 13:24:22 2016
@@ -1,823 +1,823 @@
-cmake_minimum_required(VERSION 2.8.8)
-
-# FIXME: It may be removed when we use 2.8.12.
-if(CMAKE_VERSION VERSION_LESS 2.8.12)
-  # Invalidate a couple of keywords.
-  set(cmake_2_8_12_INTERFACE)
-  set(cmake_2_8_12_PRIVATE)
-else()
-  # Use ${cmake_2_8_12_KEYWORD} intead of KEYWORD in target_link_libraries().
-  set(cmake_2_8_12_INTERFACE INTERFACE)
-  set(cmake_2_8_12_PRIVATE PRIVATE)
-  if(POLICY CMP0022)
-cmake_policy(SET CMP0022 NEW) # automatic when 2.8.12 is required
-  endif()
-endif()
-
-# If we are not building as a part of LLVM, build Clang as an
-# standalone project, using LLVM as an external library:
-if( CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR )
-  project(Clang)
-
-  # Rely on llvm-config.
-  set(CONFIG_OUTPUT)
-  find_program(LLVM_CONFIG "llvm-config")
-  if(LLVM_CONFIG)
-message(STATUS "Found LLVM_CONFIG as ${LLVM_CONFIG}")
-set(CONFIG_COMMAND ${LLVM_CONFIG}
-  "--assertion-mode"
-  "--bindir"
-  "--libdir"
-  "--includedir"
-  "--prefix"
-  "--src-root")
-execute_process(
-  COMMAND ${CONFIG_COMMAND}
-  RESULT_VARIABLE HAD_ERROR
-  OUTPUT_VARIABLE CONFIG_OUTPUT
-)
-if(NOT HAD_ERROR)
-  string(REGEX REPLACE
-"[ \t]*[\r\n]+[ \t]*" ";"
-CONFIG_OUTPUT ${CONFIG_OUTPUT})
-else()
-  string(REPLACE ";" " " CONFIG_COMMAND_STR "${CONFIG_COMMAND}")
-  message(STATUS "${CONFIG_COMMAND_STR}")
-  message(FATAL_ERROR "llvm-config failed with status ${HAD_ERROR}")
-endif()
-  else()
-message(FATAL_ERROR "llvm-config not found -- ${LLVM_CONFIG}")
-  endif()
-
-  list(GET CONFIG_OUTPUT 0 ENABLE_ASSERTIONS)
-  list(GET CONFIG_OUTPUT 1 TOOLS_BINARY_DIR)
-  list(GET CONFIG_OUTPUT 2 LIBRARY_DIR)
-  list(GET CONFIG_OUTPUT 3 INCLUDE_DIR)
-  list(GET CONFIG_OUTPUT 4 LLVM_OBJ_ROOT)
-  list(GET CONFIG_OUTPUT 5 MAIN_SRC_DIR)
-
-  if(NOT MSVC_IDE)
-set(LLVM_ENABLE_ASSERTIONS ${ENABLE_ASSERTIONS}
-  CACHE BOOL "Enable assertions")
-# Assertions should follow llvm-config's.
-mark_as_advanced(LLVM_ENABLE_ASSERTIONS)
-  endif()
-
-  set(LLVM_TOOLS_BINARY_DIR ${TOOLS_BINARY_DIR} CACHE PATH "Path to llvm/bin")
-  set(LLVM_LIBRARY_DIR ${LIBRARY_DIR} CACHE PATH "Path to llvm/lib")
-  set(LLVM_MAIN_INCLUDE_DIR ${INCLUDE_DIR} CACHE PATH "Path to llvm/include")
-  set(LLVM_BINARY_DIR ${LLVM_OBJ_ROOT} CACHE PATH "Path to LLVM build tree")
-  set(LLVM_MAIN_SRC_DIR ${MAIN_SRC_DIR} CACHE PATH "Path to LLVM source tree")
-
-  find_program(LLVM_TABLEGEN_EXE "llvm-tblgen" ${LLVM_TOOLS_BINARY_DIR}
-NO_DEFAULT_PATH)
-
-  set(LLVM_CMAKE_PATH "${LLVM_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/cmake/llvm")
-  set(LLVMCONFIG_FILE "${LLVM_CMAKE_PATH}/LLVMConfig.cmake")
-  if(EXISTS ${LLVMCONFIG_FILE})
-list(APPEND CMAKE_MODULE_PATH "${LLVM_CMAKE_PATH}")
-include(${LLVMCONFIG_FILE})
-  else()
-message(FATAL_ERROR "Not found: ${LLVMCONFIG_FILE}")
-  endif()
-
-  # They are used as destination of target generators.
-  set(LLVM_RUNTIME_OUTPUT_INTDIR ${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/bin)
-  set(LLVM_LIBRARY_OUTPUT_INTDIR 
${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/lib${LLVM_LIBDIR_SUFFIX})
-  if(WIN32 OR CYGWIN)
-# DLL platform -- put DLLs into bin.
-set(LLVM_SHLIB_OUTPUT_INTDIR ${LLVM_RUNTIME_OUTPUT_INTDIR})
-  else()
-set(LLVM_SHLIB_OUTPUT_INTDIR ${LLVM_LIBRARY_OUTPUT_INTDIR})
-  endif()
-
-  option(LLVM_INSTALL_TOOLCHAIN_ONLY
-"Only include toolchain files in the 'install' target." OFF)
-
-  option(LLVM_FORCE_USE_OLD_HOST_TOOLCHAIN
-"Set to ON to force using an old, unsupported host toolchain." OFF)
-  option(CLANG_ENABLE_BOOTSTRAP "Generate the clang bootstrap target" OFF)
-
-  include(AddLLVM)
-  include(TableGen)
-  include(HandleLLVMOptions)
-  include(VersionFromVCS)
-
-  set(PACKAGE_VERSION "${LLVM_PACKAGE_VERSION}")
-
-  if (NOT DEFINED LLVM_INCLUDE_TESTS)
-set(LLVM_INCLUDE_TESTS ON)
-  endif()
-
-  include_directories("${LLVM_BINARY_DIR}/include" "${LLVM_MAIN_INCLUDE_DIR}")
-  link_directories("${LLVM_LIBRARY_DIR}")
-
-  set( CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin )
-  set( CMAKE_LIBRARY_OUTPUT_DIRECTORY 
${CMAKE_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX} )
-  set( CMAKE_ARCHIVE_OUTPUT_DIRECTORY 
${CMAKE_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX} )
-
-  if(LLVM_INCLUDE_TESTS)
-set(Python_ADDITIONAL_VERSIONS 2.7)
-include(FindPythonInterp)
-if(NOT PYTHONINTERP_FOUND)
-  message(FATAL_ERROR
-"Unable to find 

Re: [PATCH] D18296: [Sema] Handle UTF-8 invalid format string specifiers

[Richard Smith via cfe-commits]

rsmith added a comment.

This patch builds a length-1 `ConversionSpecifier` but includes the complete 
code point in the length of the overall format specifier, which is 
inconsistent. Please either treat the trailing bytes as part of the 
`ConversionSpecifier` or revert the changes to `ParsePrintfSpecifier` and 
handle this entirely within `HandleInvalidConversionSpecifier`.

Does the same problem exist when parsing `scanf` specifiers?



Comment at: lib/Analysis/PrintfFormatString.cpp:322
@@ +321,3 @@
+
+// If the specifier in non-printable, it could be the first byte of a
+// UTF-8 sequence. If that's the case, adjust the length accordingly.

in -> is


Comment at: lib/Analysis/PrintfFormatString.cpp:324
@@ +323,3 @@
+// UTF-8 sequence. If that's the case, adjust the length accordingly.
+if (Start + 1 < I && !llvm::sys::locale::isPrint(FirstByte) &&
+isLegalUTF8String(, SE))

The interpretation of a format string by `printf` should not depend on the 
locale, so our parsing of a format string should not either.


http://reviews.llvm.org/D18296



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

Re: [PATCH] D18498: Auto-install Clang Visual Studio visualizers for VS2015 and up

[Mike Spertus via cfe-commits]

mspertus closed this revision.
mspertus added a comment.

Closing diff after commit


http://reviews.llvm.org/D18498



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

Re: [PATCH] D18498: Auto-install Clang Visual Studio visualizers for VS2015 and up

[Mike Spertus via cfe-commits]

mspertus added a comment.

Commited as revision 264603


http://reviews.llvm.org/D18498



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

r264603 - Use VS2015 Project Support for Natvis to eliminate the need to manually install clang native visualizer

[Mike Spertus via cfe-commits]

Author: mps
Date: Mon Mar 28 13:03:37 2016
New Revision: 264603

URL: http://llvm.org/viewvc/llvm-project?rev=264603=rev
Log:
Use VS2015 Project Support for Natvis to eliminate the need to manually install 
clang native visualizer

This is the clang equivalent to llvm commit 264601. When using Visual Studio 
2015, cmake now puts the native visualizers in llvm.sln, so the developer 
automatically sees custom visualizations.
Much thanks to ariccio who provided extensive help on this change. (manual 
installation still needed on VS2013).


Added:
cfe/trunk/utils/ClangVisualizers/
cfe/trunk/utils/ClangVisualizers/CMakeLists.txt
cfe/trunk/utils/ClangVisualizers/clang.natvis
  - copied, changed from r264602, cfe/trunk/utils/clang.natvis
Removed:
cfe/trunk/utils/clang.natvis
Modified:
cfe/trunk/CMakeLists.txt
cfe/trunk/www/hacking.html

Modified: cfe/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/CMakeLists.txt?rev=264603=264602=264603=diff
==
--- cfe/trunk/CMakeLists.txt (original)
+++ cfe/trunk/CMakeLists.txt Mon Mar 28 13:03:37 2016
@@ -1,819 +1,823 @@
-cmake_minimum_required(VERSION 2.8.8)
-
-# FIXME: It may be removed when we use 2.8.12.
-if(CMAKE_VERSION VERSION_LESS 2.8.12)
-  # Invalidate a couple of keywords.
-  set(cmake_2_8_12_INTERFACE)
-  set(cmake_2_8_12_PRIVATE)
-else()
-  # Use ${cmake_2_8_12_KEYWORD} intead of KEYWORD in target_link_libraries().
-  set(cmake_2_8_12_INTERFACE INTERFACE)
-  set(cmake_2_8_12_PRIVATE PRIVATE)
-  if(POLICY CMP0022)
-cmake_policy(SET CMP0022 NEW) # automatic when 2.8.12 is required
-  endif()
-endif()
-
-# If we are not building as a part of LLVM, build Clang as an
-# standalone project, using LLVM as an external library:
-if( CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR )
-  project(Clang)
-
-  # Rely on llvm-config.
-  set(CONFIG_OUTPUT)
-  find_program(LLVM_CONFIG "llvm-config")
-  if(LLVM_CONFIG)
-message(STATUS "Found LLVM_CONFIG as ${LLVM_CONFIG}")
-set(CONFIG_COMMAND ${LLVM_CONFIG}
-  "--assertion-mode"
-  "--bindir"
-  "--libdir"
-  "--includedir"
-  "--prefix"
-  "--src-root")
-execute_process(
-  COMMAND ${CONFIG_COMMAND}
-  RESULT_VARIABLE HAD_ERROR
-  OUTPUT_VARIABLE CONFIG_OUTPUT
-)
-if(NOT HAD_ERROR)
-  string(REGEX REPLACE
-"[ \t]*[\r\n]+[ \t]*" ";"
-CONFIG_OUTPUT ${CONFIG_OUTPUT})
-else()
-  string(REPLACE ";" " " CONFIG_COMMAND_STR "${CONFIG_COMMAND}")
-  message(STATUS "${CONFIG_COMMAND_STR}")
-  message(FATAL_ERROR "llvm-config failed with status ${HAD_ERROR}")
-endif()
-  else()
-message(FATAL_ERROR "llvm-config not found -- ${LLVM_CONFIG}")
-  endif()
-
-  list(GET CONFIG_OUTPUT 0 ENABLE_ASSERTIONS)
-  list(GET CONFIG_OUTPUT 1 TOOLS_BINARY_DIR)
-  list(GET CONFIG_OUTPUT 2 LIBRARY_DIR)
-  list(GET CONFIG_OUTPUT 3 INCLUDE_DIR)
-  list(GET CONFIG_OUTPUT 4 LLVM_OBJ_ROOT)
-  list(GET CONFIG_OUTPUT 5 MAIN_SRC_DIR)
-
-  if(NOT MSVC_IDE)
-set(LLVM_ENABLE_ASSERTIONS ${ENABLE_ASSERTIONS}
-  CACHE BOOL "Enable assertions")
-# Assertions should follow llvm-config's.
-mark_as_advanced(LLVM_ENABLE_ASSERTIONS)
-  endif()
-
-  set(LLVM_TOOLS_BINARY_DIR ${TOOLS_BINARY_DIR} CACHE PATH "Path to llvm/bin")
-  set(LLVM_LIBRARY_DIR ${LIBRARY_DIR} CACHE PATH "Path to llvm/lib")
-  set(LLVM_MAIN_INCLUDE_DIR ${INCLUDE_DIR} CACHE PATH "Path to llvm/include")
-  set(LLVM_BINARY_DIR ${LLVM_OBJ_ROOT} CACHE PATH "Path to LLVM build tree")
-  set(LLVM_MAIN_SRC_DIR ${MAIN_SRC_DIR} CACHE PATH "Path to LLVM source tree")
-
-  find_program(LLVM_TABLEGEN_EXE "llvm-tblgen" ${LLVM_TOOLS_BINARY_DIR}
-NO_DEFAULT_PATH)
-
-  set(LLVM_CMAKE_PATH "${LLVM_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/cmake/llvm")
-  set(LLVMCONFIG_FILE "${LLVM_CMAKE_PATH}/LLVMConfig.cmake")
-  if(EXISTS ${LLVMCONFIG_FILE})
-list(APPEND CMAKE_MODULE_PATH "${LLVM_CMAKE_PATH}")
-include(${LLVMCONFIG_FILE})
-  else()
-message(FATAL_ERROR "Not found: ${LLVMCONFIG_FILE}")
-  endif()
-
-  # They are used as destination of target generators.
-  set(LLVM_RUNTIME_OUTPUT_INTDIR ${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/bin)
-  set(LLVM_LIBRARY_OUTPUT_INTDIR 
${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/lib${LLVM_LIBDIR_SUFFIX})
-  if(WIN32 OR CYGWIN)
-# DLL platform -- put DLLs into bin.
-set(LLVM_SHLIB_OUTPUT_INTDIR ${LLVM_RUNTIME_OUTPUT_INTDIR})
-  else()
-set(LLVM_SHLIB_OUTPUT_INTDIR ${LLVM_LIBRARY_OUTPUT_INTDIR})
-  endif()
-
-  option(LLVM_INSTALL_TOOLCHAIN_ONLY
-"Only include toolchain files in the 'install' target." OFF)
-
-  option(LLVM_FORCE_USE_OLD_HOST_TOOLCHAIN
-"Set to ON to force using an old, unsupported host toolchain." OFF)
-  option(CLANG_ENABLE_BOOTSTRAP "Generate the clang bootstrap target" OFF)
-
-  include(AddLLVM)
-  include(TableGen)
-  include(HandleLLVMOptions)
-  include(VersionFromVCS)
-
-  set(PACKAGE_VERSION 

Re: [PATCH] D18497: Auto-install LLVM Visual Studio visualizers for VS2015 and up

[Mike Spertus via cfe-commits]

mspertus closed this revision.
mspertus added a comment.

Committed as revisions 264601 and 264602


http://reviews.llvm.org/D18497



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

Re: [PATCH] D18304: [DarwinDriver] Increase the number of valid digits for ld version string

[Reid Kleckner via cfe-commits]

rnk added a subscriber: rnk.


Comment at: lib/Driver/Driver.cpp:2541
@@ +2540,3 @@
+/// no extra characters remaining at the end.
+bool Driver::GetReleaseVersion(const char *Str, unsigned MaxDigits,
+   MutableArrayRef Digits) {

You don't need a MaxDigits parameter, it's the same as Digits.size().


http://reviews.llvm.org/D18304



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

Re: [PATCH] D17002: [lanai] Add Lanai backend to clang driver

[Jacques Pienaar via cfe-commits]

jpienaar added a comment.

Updated, thanks



Comment at: lib/CodeGen/TargetInfo.cpp:6622-6626
@@ +6621,7 @@
+
+  if (const BuiltinType *BT = T->getAs()) {
+BuiltinType::Kind K = BT->getKind();
+if (K == BuiltinType::Float || K == BuiltinType::Double)
+  return Float;
+  }
+  return Integer;

majnemer wrote:
> Is floating point supported?
No, good point. I think we can remove this and introduce it again if floating 
point is supported.


http://reviews.llvm.org/D17002



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

Re: [PATCH] D17002: [lanai] Add Lanai backend to clang driver

[Jacques Pienaar via cfe-commits]

jpienaar updated this revision to Diff 51806.
jpienaar marked 6 inline comments as done.
jpienaar added a comment.

Removed unnecessary floating point classification (only integer is supported) 
and performed suggested cleanups.


http://reviews.llvm.org/D17002

Files:
  lib/Basic/Targets.cpp
  lib/CodeGen/TargetInfo.cpp
  lib/Driver/Driver.cpp
  lib/Driver/ToolChains.h
  lib/Driver/Tools.cpp
  lib/Driver/Tools.h
  test/CodeGen/lanai-arguments.c
  test/CodeGen/lanai-regparm.c
  test/CodeGen/target-data.c
  test/Driver/lanai-toolchain.c
  test/Driver/lanai-unknown-unknown.cpp
  test/Preprocessor/init.c

Index: test/Preprocessor/init.c
===
--- test/Preprocessor/init.c
+++ test/Preprocessor/init.c
@@ -8414,6 +8414,9 @@
 // RUN: %clang_cc1 -triple arm-linux-androideabi -E -dM < /dev/null | FileCheck -match-full-lines -check-prefix ANDROID %s
 // ANDROID:#define __ANDROID__ 1
 //
+// RUN: %clang_cc1 -triple lanai-unknown-unknown -E -dM < /dev/null | FileCheck -match-full-lines -check-prefix LANAI %s
+// LANAI: #define __lanai__ 1
+//
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc64-unknown-freebsd < /dev/null | FileCheck -match-full-lines -check-prefix PPC64-FREEBSD %s
 // PPC64-FREEBSD-NOT: #define __LONG_DOUBLE_128__ 1
 //
Index: test/Driver/lanai-unknown-unknown.cpp
===
--- test/Driver/lanai-unknown-unknown.cpp
+++ test/Driver/lanai-unknown-unknown.cpp
@@ -0,0 +1,86 @@
+// RUN: %clang -target lanai-unknown-unknown -### %s -emit-llvm-only -c 2>&1 \
+// RUN:   | FileCheck %s -check-prefix=ECHO
+// RUN: %clang -target lanai-unknown-unknown %s -emit-llvm -S -o - \
+// RUN:   | FileCheck %s
+
+// ECHO: {{.*}} "-cc1" {{.*}}lanai-unknown-unknown.c
+
+typedef __builtin_va_list va_list;
+typedef __SIZE_TYPE__ size_t;
+typedef __PTRDIFF_TYPE__ ptrdiff_t;
+
+extern "C" {
+
+// CHECK: @align_c = global i32 1
+int align_c = __alignof(char);
+
+// CHECK: @align_s = global i32 2
+int align_s = __alignof(short);
+
+// CHECK: @align_i = global i32 4
+int align_i = __alignof(int);
+
+// CHECK: @align_l = global i32 4
+int align_l = __alignof(long);
+
+// CHECK: @align_ll = global i32 8
+int align_ll = __alignof(long long);
+
+// CHECK: @align_p = global i32 4
+int align_p = __alignof(void*);
+
+// CHECK: @align_vl = global i32 4
+int align_vl = __alignof(va_list);
+
+// Check types
+
+// CHECK: signext i8 @check_char()
+char check_char() { return 0; }
+
+// CHECK: signext i16 @check_short()
+short check_short() { return 0; }
+
+// CHECK: i32 @check_int()
+int check_int() { return 0; }
+
+// CHECK: i32 @check_long()
+long check_long() { return 0; }
+
+// CHECK: i64 @check_longlong()
+long long check_longlong() { return 0; }
+
+// CHECK: zeroext i8 @check_uchar()
+unsigned char check_uchar() { return 0; }
+
+// CHECK: zeroext i16 @check_ushort()
+unsigned short check_ushort() { return 0; }
+
+// CHECK: i32 @check_uint()
+unsigned int check_uint() { return 0; }
+
+// CHECK: i32 @check_ulong()
+unsigned long check_ulong() { return 0; }
+
+// CHECK: i64 @check_ulonglong()
+unsigned long long check_ulonglong() { return 0; }
+
+// CHECK: i32 @check_size_t()
+size_t check_size_t() { return 0; }
+
+}
+
+template void Switch();
+template<> void Switch<4>();
+template<> void Switch<8>();
+template<> void Switch<16>();
+
+void check_pointer_size() {
+  // CHECK: SwitchILi4
+  Switch();
+
+  // CHECK: SwitchILi8
+  Switch();
+
+  // CHECK: SwitchILi4
+  Switch();
+}
Index: test/Driver/lanai-toolchain.c
===
--- test/Driver/lanai-toolchain.c
+++ test/Driver/lanai-toolchain.c
@@ -0,0 +1,2 @@
+// RUN: %clang -target lanai-unknown-unknown -v 2> %t
+// RUN: grep 'Target: lanai-unknown-unknown' %t
Index: test/CodeGen/target-data.c
===
--- test/CodeGen/target-data.c
+++ test/CodeGen/target-data.c
@@ -86,6 +86,10 @@
 // RUN: FileCheck %s -check-prefix=WEBASSEMBLY64
 // WEBASSEMBLY64: target datalayout = "e-m:e-p:64:64-i64:64-n32:64-S128"
 
+// RUN: %clang_cc1 -triple lanai-unknown-unknown -o - -emit-llvm %s | \
+// RUN: FileCheck %s -check-prefix=LANAI
+// LANAI: target datalayout = "E-m:e-p:32:32-i64:64-a:0:32-n32-S64"
+
 // RUN: %clang_cc1 -triple powerpc-unknown -o - -emit-llvm %s | \
 // RUN: FileCheck %s -check-prefix=PPC
 // PPC: target datalayout = "E-m:e-p:32:32-i64:64-n32"
Index: test/CodeGen/lanai-regparm.c
===
--- test/CodeGen/lanai-regparm.c
+++ test/CodeGen/lanai-regparm.c
@@ -0,0 +1,18 @@
+// RUN: %clang_cc1 -triple lanai-unknown-unknown -mregparm 4 %s -emit-llvm -o - | FileCheck %s
+
+void f1(int a, int b, int c, int d,
+int e, int f, int g, int h);
+
+void f2(int a, int b) __attribute((regparm(0)));
+
+void f0() {
+// CHECK: call void @f1(i32 inreg 

Re: r263709 - clang-format: Slightly weaken AlignAfterOpenBracket=AlwaysBreak.

[Daniel Jasper via cfe-commits]

Hi Jean-Philippe,

I have also been thinking some more about the naming and I think it is not
entirely inaccurate. It is a setting of the option AlignAfterOpenBracket
and setting that to "AlwaysBreak" means "always break instead of aligning".
And it kind of makes sense that one-parameter functions are an exception as
they never need aligning. Not saying it is perfect, though .. ;-).

Cheers,
Daniel

On Mon, Mar 28, 2016 at 2:27 PM, Jean-philippe Dufraigne <
j.dufrai...@gmail.com> wrote:

> Hi Daniel,
>
> Thanks, I understand why your users would have requested that and why you
> need to provide this improvement for them.
> I will survey the other people writing code with me on whether they are
> happy with this improvement considering both the readability of the
> statements and the relatively small impact in our day to day
> reading/writing.
> I'll get back to you, maybe I was wasting time on a non issue..
>
> Cheers,
> Jean-Philippe.
>
>
> 2016-03-28 9:51 GMT+01:00 Daniel Jasper :
>
>> Hi Jean-Philippe,
>>
>> no, you have not convinced me with those examples. There is not a single
>> one, I find more readable. Many of them I find equally unreadable and would
>> write the code differently. But I would never have chose AlwaysBreak for my
>> own code in the first place and I rarely work in a codebase that uses it.
>> When I do, it usually bugs me. So, that (my opinion) is completely beside
>> the point.
>>
>> There is one fundamental half-way objective argument you can make here
>> (and in many other cases): Being more compact generally makes it easier to
>> read larger chunks of code as it is more likely for a whole
>> function/loop/... to fit on a single page. Using more linebreaks to make
>> the syntactic structure clearer and more uniform can make individual
>> statements more readable. My argument is that in this case, often many
>> lines are saved with very little to no impact on local readability. You
>> disagree and that's fine, I am not trying to convince you. People a
>> different here.
>>
>> If you need the uniformity so that many subsequent statements are
>> formatted equally (e.g. in your "connRegist.Add( ..." case), you are
>> likely doing it wrong. Try harder not to repeat yourself. The problem here
>> is that such uniformly appearing sequence can hide very subtle (copy)
>> errors. However, even all of this is beside the point.
>>
>> You found changes in ~10% of your files. I'd bet that less than 10% of a
>> file was changed on average. So, this influences <1% of the code. That is
>> reasonably rare and you won't stumble over this frequently in practice.
>> Yes, of course you see hundreds of examples when you reformat a
>> thousand-file codebase and I understand why that bugs you.
>>
>> I definitely need the new behavior as it was requested frequently by my
>> internal users. This was the most frequent bug report I have gotten from
>> people using AlwaysBreak. I suggest that you also speak to the other
>> authors of the codebase you are working on to make sure that you are
>> actually getting a feel for what most people want here. And also include
>> cases where it is significantly better IMO:
>>
>>   call(call(call(call(call(call(call(call(call(call(call(
>> parameterThatGoesUpToTheColumnLimit)));
>>
>> vs.
>>
>>   call(
>>   call(
>>   call(
>>   call(
>>   ...
>>   parameterThatGoesUpToTheColumnLimit)));  //
>> probably even a column limit violation
>>
>> Again, I am not against adding an additional option. And if we do
>> introduce a new option, we should probably make that one strict and not
>> have the other exceptions.
>>
>> Cheers,
>> Daniel
>>
>>
>> On Sun, Mar 27, 2016 at 8:16 PM, Jean-philippe Dufraigne <
>> j.dufrai...@gmail.com> wrote:
>>
>>> Hi Daniel,
>>>
>>> Thanks a lot for your answer and clarifications.
>>> Sorry for the long answer, TLDR at the beginning (and end for code
>>> examples).
>>>
>>> To answer your 2 questions immediately:
>>> - It happens a lot more than I thought, about 10% of the few thousands
>>> file I checked had instances of this.
>>> - Yes, there is a significant readability disadvantage as these
>>> functions become a special case that needs to be read differently from all
>>> the other functions.
>>>   With consistent AlwaysBreak, it is obvious from the shape of the call
>>> how to read it (horizontally or diagonally).
>>>   Now, it is not longer obvious and it impact readability mostly for
>>> these functions, but also a bit for the other functions since it is not
>>> clear if they are one of the special case or not.
>>>   (The eye needs to jump at the end and then back to parse the arguments)
>>>   (This ls less/not of an issue for lambda and small functions)
>>>
>>>
>>> My conclusion:
>>> I really think an option should provide a consistent break but I'm
>>> really not sure it should be a new option.
>>> If I manage to convince you through the 

Re: [PATCH] D18304: [DarwinDriver] Increase the number of valid digits for ld version string

[Bruno Cardoso Lopes via cfe-commits]

bruno added a comment.

Ping :-)


http://reviews.llvm.org/D18304



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

Re: [PATCH] D18498: Auto-install Clang Visual Studio visualizers for VS2015 and up

[Mike Spertus via cfe-commits]

mspertus added a comment.

This is still showing as "Needs review" Are there any further changes required 
or can someone accept it? I installed both VS2015 and VS2013 on my laptop and 
saw the correct solution files built by cmake.


http://reviews.llvm.org/D18498



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

Re: [PATCH] D18489: [PGO, clang] Comment how function pointers for indirect calls are mapped to function names

[Xinliang David Li via cfe-commits]

On Mon, Mar 28, 2016 at 10:40 AM, Adam Nemet  wrote:

> anemet added inline comments.
>
> 
> Comment at: lib/CodeGen/CodeGenPGO.cpp:758
> @@ -757,1 +757,3 @@
>
> +  // During instrumentation, function pointers are collected for the
> different
> +  // indirect call targets.  Then as part of the conversion from raw to
> merged
> 
> davidxl wrote:
> > anemet wrote:
> > > davidxl wrote:
> > > > CodeGenPGO::valueProfile is a common API which can also be used for
> other kinds of value profile, so the comments belong to the callsite of
> this method in CGCall.cpp.
> > > >
> > > > Suggested wording:
> > > >
> > > > For indirect function call value profiling, the addresses of the
> target functions are profiled by the instrumented code. The target
> addresses are written in the raw profile data and converted to target
> function name's MD5 hash by the profile reader during deserialization.
> > > Hi David,
> > >
> > > Thanks for taking a look.
> > >
> > > I don't mind rewording the comment if you have some specific issues
> but your version drops many of the details that was painful for me to
> discover.  I carefully worded my comment to describe some of the design
> details for indirect profiling that are not covered elsewhere:
> > >
> > > 1) the remapping from function pointer to hashes of function names
> happens during profdata merging
> > >
> > >   It was surprisingly hard to figure out what the PGO file contained
> for indirect call targets: function pointers or func name hashes?  And of
> course as stated, the answer is -- it depends.
> > >
> > > 2) the remapping happens pretty deep in the infrastructure code during
> deserializing of the rawdata
> > >
> > >   I was looking at several more logical places to find where this
> happens and this was a bit unexpected location for this functionality.
> > >
> > > 3) how do we know the function addresses necessary for the mapping
> from function address -> func name -> hash
> > >
> > >   The entire code to populate the FunctionAddr using macro magic in
> InstrProfiling::getOrCreateRegionCounters is pretty hard to follow.  I much
> rather have an overview of the logic somewhere centrally.
> > >
> > > From the above list I feel that your version dropped 1 and 3 and only
> kept 2.  Of course, feel free to add more context to my comments and fix
> inaccuracies/oversimplifications but I would want want to drop any of the
> points mentioned above.
> > >
> > > Thanks.
> > Actually bullet 1 is not dropped from my suggested version: each time
> when a raw profile data is read, the reader interface will covert the
> address into MD5 -- profile merging is simply a user of the reader.
> >
> > About bullet 3, it is ok to add it if you think it is useful. ( I did
> not suggest it because ProfData is needed here is not for the purpose of
> conversion, but to pass the context for the runtime to find/set the counter
> arrays.)
> > Actually bullet 1 is not dropped from my suggested version: each time
> when a raw profile data is read, the reader interface will covert the
> address into MD5 -- profile merging is simply a user of the reader.
>
> Sure but that is still pretty implicit.  I'd like to describe this in
> terms of the well established phases of PGO: instrumentation, profile
> merge,  recompile with profile data.
>
> How about:
>
> ```
> For indirect function call value profiling, the addresses of the target
> functions are profiled by the instrumented code. The target addresses are
> written in the raw profile data and converted to target function name's MD5
> hash by the profile reader during deserialization.  Typically, this happens
> when the the raw profile data is read during profile merging.
>


This sounds great!



> ```
>
> > About bullet 3, it is ok to add it if you think it is useful. ( I did
> not suggest it because ProfData is needed here is not for the purpose of
> conversion, but to pass the context for the runtime to find/set the counter
> arrays.)
>
> I am not completely sure I understand what you're saying here but if you
> mean that the comment does not really apply to the surrounding code then
> that I guess is expected.


Right.


> I wanted to give a high-level overview of *what* we collect at run-time,
> and *how* we map that into function names hashes that are then used in the
> IR.
>

I am fine putting them here.

So LGTM with your revised version.

David


>

I can also put this in the function comment if you think that's better.
>
>
>
> http://reviews.llvm.org/D18489
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D18489: [PGO, clang] Comment how function pointers for indirect calls are mapped to function names

[Adam Nemet via cfe-commits]

anemet added inline comments.


Comment at: lib/CodeGen/CodeGenPGO.cpp:758
@@ -757,1 +757,3 @@
 
+  // During instrumentation, function pointers are collected for the different
+  // indirect call targets.  Then as part of the conversion from raw to merged

davidxl wrote:
> anemet wrote:
> > davidxl wrote:
> > > CodeGenPGO::valueProfile is a common API which can also be used for other 
> > > kinds of value profile, so the comments belong to the callsite of this 
> > > method in CGCall.cpp.
> > > 
> > > Suggested wording:
> > > 
> > > For indirect function call value profiling, the addresses of the target 
> > > functions are profiled by the instrumented code. The target addresses are 
> > > written in the raw profile data and converted to target function name's 
> > > MD5 hash by the profile reader during deserialization.
> > Hi David,
> > 
> > Thanks for taking a look.
> > 
> > I don't mind rewording the comment if you have some specific issues but 
> > your version drops many of the details that was painful for me to discover. 
> >  I carefully worded my comment to describe some of the design details for 
> > indirect profiling that are not covered elsewhere:
> > 
> > 1) the remapping from function pointer to hashes of function names happens 
> > during profdata merging
> > 
> >   It was surprisingly hard to figure out what the PGO file contained for 
> > indirect call targets: function pointers or func name hashes?  And of 
> > course as stated, the answer is -- it depends.
> > 
> > 2) the remapping happens pretty deep in the infrastructure code during 
> > deserializing of the rawdata
> > 
> >   I was looking at several more logical places to find where this happens 
> > and this was a bit unexpected location for this functionality.
> > 
> > 3) how do we know the function addresses necessary for the mapping from 
> > function address -> func name -> hash
> > 
> >   The entire code to populate the FunctionAddr using macro magic in 
> > InstrProfiling::getOrCreateRegionCounters is pretty hard to follow.  I much 
> > rather have an overview of the logic somewhere centrally.
> > 
> > From the above list I feel that your version dropped 1 and 3 and only kept 
> > 2.  Of course, feel free to add more context to my comments and fix 
> > inaccuracies/oversimplifications but I would want want to drop any of the 
> > points mentioned above.
> > 
> > Thanks.
> Actually bullet 1 is not dropped from my suggested version: each time when a 
> raw profile data is read, the reader interface will covert the address into 
> MD5 -- profile merging is simply a user of the reader. 
> 
> About bullet 3, it is ok to add it if you think it is useful. ( I did not 
> suggest it because ProfData is needed here is not for the purpose of 
> conversion, but to pass the context for the runtime to find/set the counter 
> arrays.)
> Actually bullet 1 is not dropped from my suggested version: each time when a 
> raw profile data is read, the reader interface will covert the address into 
> MD5 -- profile merging is simply a user of the reader.

Sure but that is still pretty implicit.  I'd like to describe this in terms of 
the well established phases of PGO: instrumentation, profile merge,  recompile 
with profile data.

How about:

```
For indirect function call value profiling, the addresses of the target 
functions are profiled by the instrumented code. The target addresses are 
written in the raw profile data and converted to target function name's MD5 
hash by the profile reader during deserialization.  Typically, this happens 
when the the raw profile data is read during profile merging.
``` 

> About bullet 3, it is ok to add it if you think it is useful. ( I did not 
> suggest it because ProfData is needed here is not for the purpose of 
> conversion, but to pass the context for the runtime to find/set the counter 
> arrays.)

I am not completely sure I understand what you're saying here but if you mean 
that the comment does not really apply to the surrounding code then that I 
guess is expected.  I wanted to give a high-level overview of *what* we collect 
at run-time, and *how* we map that into function names hashes that are then 
used in the IR.

I can also put this in the function comment if you think that's better.



http://reviews.llvm.org/D18489



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

r264597 - Windows: Shrink sizeof(MacroInfo) from 256 to 248, MacroDirective 24 to 16

[Nico Weber via cfe-commits]

Author: nico
Date: Mon Mar 28 12:28:06 2016
New Revision: 264597

URL: http://llvm.org/viewvc/llvm-project?rev=264597=rev
Log:
Windows: Shrink sizeof(MacroInfo) from 256 to 248, MacroDirective 24 to 16

In the Microsoft ABI, only bitfields with identical types get packed together,
so use consistently use one of the two instead of a mix.
Saves 457kB when parsing windows.h.

No intended behavior change.

Modified:
cfe/trunk/include/clang/Lex/MacroInfo.h

Modified: cfe/trunk/include/clang/Lex/MacroInfo.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Lex/MacroInfo.h?rev=264597=264596=264597=diff
==
--- cfe/trunk/include/clang/Lex/MacroInfo.h (original)
+++ cfe/trunk/include/clang/Lex/MacroInfo.h Mon Mar 28 12:28:06 2016
@@ -106,7 +106,7 @@ class MacroInfo {
   bool IsWarnIfUnused : 1;
 
   /// \brief Whether this macro info was loaded from an AST file.
-  unsigned FromASTFile : 1;
+  bool FromASTFile : 1;
 
   /// \brief Whether this macro was used as header guard.
   bool UsedForHeaderGuard : 1;
@@ -318,13 +318,13 @@ protected:
   unsigned MDKind : 2;
 
   /// \brief True if the macro directive was loaded from a PCH file.
-  bool IsFromPCH : 1;
+  unsigned IsFromPCH : 1;
 
   // Used by VisibilityMacroDirective 
//
 
   /// \brief Whether the macro has public visibility (when described in a
   /// module).
-  bool IsPublic : 1;
+  unsigned IsPublic : 1;
 
   MacroDirective(Kind K, SourceLocation Loc)
   : Previous(nullptr), Loc(Loc), MDKind(K), IsFromPCH(false),


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

Re: [PATCH] D18489: [PGO, clang] Comment how function pointers for indirect calls are mapped to function names

[David Li via cfe-commits]

davidxl added inline comments.


Comment at: lib/CodeGen/CodeGenPGO.cpp:758
@@ -757,1 +757,3 @@
 
+  // During instrumentation, function pointers are collected for the different
+  // indirect call targets.  Then as part of the conversion from raw to merged

anemet wrote:
> davidxl wrote:
> > CodeGenPGO::valueProfile is a common API which can also be used for other 
> > kinds of value profile, so the comments belong to the callsite of this 
> > method in CGCall.cpp.
> > 
> > Suggested wording:
> > 
> > For indirect function call value profiling, the addresses of the target 
> > functions are profiled by the instrumented code. The target addresses are 
> > written in the raw profile data and converted to target function name's MD5 
> > hash by the profile reader during deserialization.
> Hi David,
> 
> Thanks for taking a look.
> 
> I don't mind rewording the comment if you have some specific issues but your 
> version drops many of the details that was painful for me to discover.  I 
> carefully worded my comment to describe some of the design details for 
> indirect profiling that are not covered elsewhere:
> 
> 1) the remapping from function pointer to hashes of function names happens 
> during profdata merging
> 
>   It was surprisingly hard to figure out what the PGO file contained for 
> indirect call targets: function pointers or func name hashes?  And of course 
> as stated, the answer is -- it depends.
> 
> 2) the remapping happens pretty deep in the infrastructure code during 
> deserializing of the rawdata
> 
>   I was looking at several more logical places to find where this happens and 
> this was a bit unexpected location for this functionality.
> 
> 3) how do we know the function addresses necessary for the mapping from 
> function address -> func name -> hash
> 
>   The entire code to populate the FunctionAddr using macro magic in 
> InstrProfiling::getOrCreateRegionCounters is pretty hard to follow.  I much 
> rather have an overview of the logic somewhere centrally.
> 
> From the above list I feel that your version dropped 1 and 3 and only kept 2. 
>  Of course, feel free to add more context to my comments and fix 
> inaccuracies/oversimplifications but I would want want to drop any of the 
> points mentioned above.
> 
> Thanks.
Actually bullet 1 is not dropped from my suggested version: each time when a 
raw profile data is read, the reader interface will covert the address into MD5 
-- profile merging is simply a user of the reader. 

About bullet 3, it is ok to add it if you think it is useful. ( I did not 
suggest it because ProfData is needed here is not for the purpose of 
conversion, but to pass the context for the runtime to find/set the counter 
arrays.)


http://reviews.llvm.org/D18489



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

Re: [PATCH] D18458: [CUDA] Mangle __host__ __device__ functions differently than __host__ or __device__ functions.

[Justin Lebar via cfe-commits]

> That would break the semantics of things like static local variables in 
> inline functions, uniqueness of local types in inline functions, etc. For an 
> HD function, that's likely to be fine since HD already breaks those 
> properties by creating two independent versions of the function (as noted 
> elsewhere, this seems like a surprising thing to implicitly do to all 
> constexpr functions, but that's a separate change, and sidesteps some of 
> these issues since you can't have static locals in a constexpr function -- 
> yet).

(At the moment we treat all device functions as internal, but changing
that is definitely on the radar.)

It does not seem that external declarations of functions implicitly
converted to HD is compatible with nvcc's ABI, if we allow the
implicit-HD functions to overload explicit-D functions.

The reason is, suppose I have two TUs:

  a.cu:
void foo();  // implicitly HD
  b.cu:
__device__ void foo();

To be ABI compatible with nvcc, both overloads must have the same
mangled name, which means this is an ODR violation, yes?  But saying
that this program is an error means that we don't allow overloading of
implicit-HD with explicit-D.  And anyway that seems pretty wrong to me
-- why does the presence of some unattributed function you don't care
about make your __device__ function decl invalid?  IOW the nvcc
behavior seems broken.

So I guess we're left with breaking ABI compatibility with nvcc.  In
which case the only remaining questions are:

a) How much overloading of HD do we want to allow?  One side of the
spectrum is to allow all HD / D and HD / H overloading.  The other
side is to allow only implicit-HD / D overloading.  And there are
points in between.

b) Do we want to mangle all HD functions differently, or just the HD
functions which can be overloaded?



On Mon, Mar 28, 2016 at 9:23 AM, Richard Smith  wrote:
> On 27 Mar 2016 9:56 a.m., "Justin Lebar via cfe-commits"
>  wrote:
>>
>> jlebar added a comment.
>>
>> > OK, so the question for you is, how much ABI compatibility with NVCC are
>> > you prepared to give up in order to allow HD / D overloading and HD / H
>> > overloading?
>>
>>
>> At the moment, getting this feature to work seems more important than
>> maintaining ABI compatibility with NVCC.  But I cannot confidently assign a
>> probability to how likely it will be at some point in the future that we'll
>> want this ABI compatibility.  I really don't know.
>>
>> So, that's one option.  Here's another:
>>
>> The motivation behind this one is, we have this pie-in-the-sky notion
>> that, morally, device code should be able to call anything it wants.  Only
>> if we cannot codegen for device a function transitively invoked by a device
>> function will we error out.  constexpr-is-implicitly-HD is a step towards
>> this more ambitious goal.
>>
>> Setting aside the constexpr bit, it seems to me that when we codegen an
>> unattributed function for device, we should mark the function as having
>> internal linkage (or whatever the thing is called such that it's not visible
>> from other TUs).  The reason is, other TUs cannot rely on this function
>> being present in the first object file, because the function is only
>> generated on-demand.  If you want to call an HD function defined in another
>> .cu file, then the header in both files needs to explicitly define it as HD.
>>
>> If that is true -- that unattributed functions which we codegen for device
>> can/should be made internal -- then the mangling of those names has no
>> bearing on ABI compatibility.  So we could say, no explicit-HD / D or
>> explicit-HD / H overloading, but *implicit*-HD / D overloading is OK, and we
>> will mangle implicit-HD functions differently to allow this.
>>
>> Does that sound like it might work?
>
> Not completely. That would break the semantics of things like static local
> variables in inline functions, uniqueness of local types in inline
> functions, etc. For an HD function, that's likely to be fine since HD
> already breaks those properties by creating two independent versions of the
> function (as noted elsewhere, this seems like a surprising thing to
> implicitly do to all constexpr functions, but that's a separate change, and
> sidesteps some of these issues since you can't have static locals in a
> constexpr function -- yet).
>
>> http://reviews.llvm.org/D18458
>>
>>
>>
>> ___
>> 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] D18489: [PGO, clang] Comment how function pointers for indirect calls are mapped to function names

[Adam Nemet via cfe-commits]

anemet added inline comments.


Comment at: lib/CodeGen/CodeGenPGO.cpp:758
@@ -757,1 +757,3 @@
 
+  // During instrumentation, function pointers are collected for the different
+  // indirect call targets.  Then as part of the conversion from raw to merged

davidxl wrote:
> CodeGenPGO::valueProfile is a common API which can also be used for other 
> kinds of value profile, so the comments belong to the callsite of this method 
> in CGCall.cpp.
> 
> Suggested wording:
> 
> For indirect function call value profiling, the addresses of the target 
> functions are profiled by the instrumented code. The target addresses are 
> written in the raw profile data and converted to target function name's MD5 
> hash by the profile reader during deserialization.
Hi David,

Thanks for taking a look.

I don't mind rewording the comment if you have some specific issues but your 
version drops many of the details that was painful for me to discover.  I 
carefully worded my comment to describe some of the design details for indirect 
profiling that are not covered elsewhere:

1) the remapping from function pointer to hashes of function names happens 
during profdata merging

  It was surprisingly hard to figure out what the PGO file contained for 
indirect call targets: function pointers or func name hashes?  And of course as 
stated, the answer is -- it depends.

2) the remapping happens pretty deep in the infrastructure code during 
deserializing of the rawdata

  I was looking at several more logical places to find where this happens and 
this was a bit unexpected location for this functionality.

3) how do we know the function addresses necessary for the mapping from 
function address -> func name -> hash

  The entire code to populate the FunctionAddr using macro magic in 
InstrProfiling::getOrCreateRegionCounters is pretty hard to follow.  I much 
rather have an overview of the logic somewhere centrally.

From the above list I feel that your version dropped 1 and 3 and only kept 2.  
Of course, feel free to add more context to my comments and fix 
inaccuracies/oversimplifications but I would want want to drop any of the 
points mentioned above.

Thanks.


http://reviews.llvm.org/D18489



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

Re: [PATCH] D18458: [CUDA] Mangle __host__ __device__ functions differently than __host__ or __device__ functions.

[Richard Smith via cfe-commits]

On 27 Mar 2016 9:56 a.m., "Justin Lebar via cfe-commits" <
cfe-commits@lists.llvm.org> wrote:
>
> jlebar added a comment.
>
> > OK, so the question for you is, how much ABI compatibility with NVCC
are you prepared to give up in order to allow HD / D overloading and HD / H
overloading?
>
>
> At the moment, getting this feature to work seems more important than
maintaining ABI compatibility with NVCC.  But I cannot confidently assign a
probability to how likely it will be at some point in the future that we'll
want this ABI compatibility.  I really don't know.
>
> So, that's one option.  Here's another:
>
> The motivation behind this one is, we have this pie-in-the-sky notion
that, morally, device code should be able to call anything it wants.  Only
if we cannot codegen for device a function transitively invoked by a device
function will we error out.  constexpr-is-implicitly-HD is a step towards
this more ambitious goal.
>
> Setting aside the constexpr bit, it seems to me that when we codegen an
unattributed function for device, we should mark the function as having
internal linkage (or whatever the thing is called such that it's not
visible from other TUs).  The reason is, other TUs cannot rely on this
function being present in the first object file, because the function is
only generated on-demand.  If you want to call an HD function defined in
another .cu file, then the header in both files needs to explicitly define
it as HD.
>
> If that is true -- that unattributed functions which we codegen for
device can/should be made internal -- then the mangling of those names has
no bearing on ABI compatibility.  So we could say, no explicit-HD / D or
explicit-HD / H overloading, but *implicit*-HD / D overloading is OK, and
we will mangle implicit-HD functions differently to allow this.
>
> Does that sound like it might work?

Not completely. That would break the semantics of things like static local
variables in inline functions, uniqueness of local types in inline
functions, etc. For an HD function, that's likely to be fine since HD
already breaks those properties by creating two independent versions of the
function (as noted elsewhere, this seems like a surprising thing to
implicitly do to all constexpr functions, but that's a separate change, and
sidesteps some of these issues since you can't have static locals in a
constexpr function -- yet).

> http://reviews.llvm.org/D18458
>
>
>
> ___
> 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] D18088: Add a new warning to notify users of mismatched SDK and deployment target

[Chris Bieneman via cfe-commits]

beanz added a comment.

Perhaps naming this warning 'incompatible-sdk' isn't the best name. I can see 
how it would cause some confusion for Visual Studio users. On Darwin the SDK is 
the collection of headers and libraries you link against, not the toolkit you 
have installed.

Perhaps calling the warning 'incompatible-sysroot' is a better name. Even 
though this patch only implements it for Darwin I imagine that similar 
functionality could be added for Windows and Linux too. The idea being to have 
the compiler perform some basic check to ensure that the headers and libraries 
you are building against actually support your target.

Updated patches coming shortly.


http://reviews.llvm.org/D18088



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

Re: [PATCH] D17002: [lanai] Add Lanai backend to clang driver

[David Majnemer via cfe-commits]

majnemer added a subscriber: majnemer.


Comment at: lib/CodeGen/TargetInfo.cpp:6592-6594
@@ +6591,5 @@
+
+  static bool isRegisterSize(unsigned Size) {
+return (Size == 8 || Size == 16 || Size == 32);
+  }
+

Is this used? A quick grep didn't find any callers.


Comment at: lib/CodeGen/TargetInfo.cpp:6622-6626
@@ +6621,7 @@
+
+  if (const BuiltinType *BT = T->getAs()) {
+BuiltinType::Kind K = BT->getKind();
+if (K == BuiltinType::Float || K == BuiltinType::Double)
+  return Float;
+  }
+  return Integer;

Is floating point supported?


Comment at: lib/CodeGen/TargetInfo.cpp:6636
@@ +6635,3 @@
+  unsigned Size = getContext().getTypeSize(Ty);
+  unsigned SizeInRegs = (Size + 31) / 32;
+

I think this can be `unsigned SizeInRegs = alignTo(Size, 32U);`


Comment at: lib/CodeGen/TargetInfo.cpp:6656-6658
@@ +6655,5 @@
+
+  // Treat an enum type as its underlying type.
+  if (const EnumType *EnumTy = Ty->getAs())
+Ty = EnumTy->getDecl()->getIntegerType();
+

I'd use `const auto *` here because `EnumType is visible in the `getAs`.


Comment at: lib/CodeGen/TargetInfo.cpp:6660-6670
@@ +6659,13 @@
+
+  bool InReg = shouldUseInReg(Ty, State);
+  if (Ty->isPromotableIntegerType()) {
+if (InReg) {
+  return ABIArgInfo::getDirectInReg();
+}
+return ABIArgInfo::getExtend();
+  }
+  if (InReg)
+return ABIArgInfo::getDirectInReg();
+
+  return ABIArgInfo::getDirect();
+}

I think this is equivalent to:

  if (shouldUseInReg(Ty, State))
return ABIArgInfo::getDirectInReg();

  if (Ty->isPromotableIntegerType())
return ABIArgInfo::getExtend();

  return ABIArgInfo::getDirect();


Comment at: test/CodeGen/lanai-arguments.c:2
@@ +1,3 @@
+// RUN: %clang_cc1 -triple lanai-unknown-unknown %s -emit-llvm -o - \
+// RUN:   | FileCheck %s -check-prefix=LANAI
+

No need to use a check-prefix if there is only one FileCheck invocation.


http://reviews.llvm.org/D17002



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

Re: [PATCH] D18475: [clang-tidy] Add more detection rules for redundant c_str calls.

[Aaron Ballman via cfe-commits]

aaron.ballman added a subscriber: aaron.ballman.


Comment at: clang-tidy/readability/RedundantStringCStrCheck.cpp:129
@@ +128,3 @@
+  // Detect: 'dst += str.c_str()'  ->  'dst += str'
+  // Detect: 's == str.c_str()'  ->  's == str'
+  Finder->addMatcher(

I think this comment is incorrect, you want assignment, not equality.


http://reviews.llvm.org/D18475



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

Re: [PATCH] D18221: [Concepts] Implement subsection [dcl.spec.concept]p7 of the Concepts TS

[Aaron Ballman via cfe-commits]

aaron.ballman added a comment.

Generally looks good to me, but you should wait for @rsmith as he may have 
other ideas on the error recovery.



Comment at: lib/Sema/SemaDecl.cpp:6295
@@ +6294,3 @@
+  Diag(NewVD->getLocation(), diag::err_concept_specialized)
+  << 1 << (IsPartialSpecialization ? 2 : 1);
+  Diag(VarTmpl->getLocation(), diag::note_previous_declaration);

Can you put comments near the magic numbers to describe what they mean? e.g., 
`1 /*variable*/`

Same comment applies elsewhere in the patch as well.


http://reviews.llvm.org/D18221



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

r264582 - Reduce size of DefinitionData from 120 to 96 bytes on Windows.

[Nico Weber via cfe-commits]

Author: nico
Date: Mon Mar 28 09:55:24 2016
New Revision: 264582

URL: http://llvm.org/viewvc/llvm-project?rev=264582=rev
Log:
Reduce size of DefinitionData from 120 to 96 bytes on Windows.

In the Microsoft ABI, only bitfields with identical types get
packed together, so use unsigned consistently instead of a
bool / unsigned mix.

No intended behavior change.

Modified:
cfe/trunk/include/clang/AST/DeclCXX.h

Modified: cfe/trunk/include/clang/AST/DeclCXX.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/DeclCXX.h?rev=264582=264581=264582=diff
==
--- cfe/trunk/include/clang/AST/DeclCXX.h (original)
+++ cfe/trunk/include/clang/AST/DeclCXX.h Mon Mar 28 09:55:24 2016
@@ -301,30 +301,30 @@ class CXXRecordDecl : public RecordDecl
 DefinitionData(CXXRecordDecl *D);
 
 /// \brief True if this class has any user-declared constructors.
-bool UserDeclaredConstructor : 1;
+unsigned UserDeclaredConstructor : 1;
 
 /// \brief The user-declared special members which this class has.
 unsigned UserDeclaredSpecialMembers : 6;
 
 /// \brief True when this class is an aggregate.
-bool Aggregate : 1;
+unsigned Aggregate : 1;
 
 /// \brief True when this class is a POD-type.
-bool PlainOldData : 1;
+unsigned PlainOldData : 1;
 
 /// true when this class is empty for traits purposes,
 /// i.e. has no data members other than 0-width bit-fields, has no
 /// virtual function/base, and doesn't inherit from a non-empty
 /// class. Doesn't take union-ness into account.
-bool Empty : 1;
+unsigned Empty : 1;
 
 /// \brief True when this class is polymorphic, i.e., has at
 /// least one virtual member or derives from a polymorphic class.
-bool Polymorphic : 1;
+unsigned Polymorphic : 1;
 
 /// \brief True when this class is abstract, i.e., has at least
 /// one pure virtual function, (that can come from a base class).
-bool Abstract : 1;
+unsigned Abstract : 1;
 
 /// \brief True when this class has standard layout.
 ///
@@ -340,62 +340,62 @@ class CXXRecordDecl : public RecordDecl
 ///   classes with non-static data members, and
 /// * has no base classes of the same type as the first non-static data
 ///   member.
-bool IsStandardLayout : 1;
+unsigned IsStandardLayout : 1;
 
 /// \brief True when there are no non-empty base classes.
 ///
 /// This is a helper bit of state used to implement IsStandardLayout more
 /// efficiently.
-bool HasNoNonEmptyBases : 1;
+unsigned HasNoNonEmptyBases : 1;
 
 /// \brief True when there are private non-static data members.
-bool HasPrivateFields : 1;
+unsigned HasPrivateFields : 1;
 
 /// \brief True when there are protected non-static data members.
-bool HasProtectedFields : 1;
+unsigned HasProtectedFields : 1;
 
 /// \brief True when there are private non-static data members.
-bool HasPublicFields : 1;
+unsigned HasPublicFields : 1;
 
 /// \brief True if this class (or any subobject) has mutable fields.
-bool HasMutableFields : 1;
+unsigned HasMutableFields : 1;
 
 /// \brief True if this class (or any nested anonymous struct or union)
 /// has variant members.
-bool HasVariantMembers : 1;
+unsigned HasVariantMembers : 1;
 
 /// \brief True if there no non-field members declared by the user.
-bool HasOnlyCMembers : 1;
+unsigned HasOnlyCMembers : 1;
 
 /// \brief True if any field has an in-class initializer, including those
 /// within anonymous unions or structs.
-bool HasInClassInitializer : 1;
+unsigned HasInClassInitializer : 1;
 
 /// \brief True if any field is of reference type, and does not have an
 /// in-class initializer.
 ///
 /// In this case, value-initialization of this class is illegal in C++98
 /// even if the class has a trivial default constructor.
-bool HasUninitializedReferenceMember : 1;
+unsigned HasUninitializedReferenceMember : 1;
 
 /// \brief True if any non-mutable field whose type doesn't have a user-
 /// provided default ctor also doesn't have an in-class initializer.
-bool HasUninitializedFields : 1;
+unsigned HasUninitializedFields : 1;
 
 /// \brief These flags are \c true if a defaulted corresponding special
 /// member can't be fully analyzed without performing overload resolution.
 /// @{
-bool NeedOverloadResolutionForMoveConstructor : 1;
-bool NeedOverloadResolutionForMoveAssignment : 1;
-bool NeedOverloadResolutionForDestructor : 1;
+unsigned NeedOverloadResolutionForMoveConstructor : 1;
+unsigned NeedOverloadResolutionForMoveAssignment : 1;
+unsigned NeedOverloadResolutionForDestructor : 1;
 /// @}
 
 /// \brief These flags are \c true if an implicit defaulted corresponding
 /// special member would be defined as deleted.
   

Re: [PATCH] D18265: [clang-tidy] New: checker misc-assign-operator-return

[Aaron Ballman via cfe-commits]

aaron.ballman added a subscriber: aaron.ballman.
aaron.ballman added a reviewer: aaron.ballman.


Comment at: clang-tidy/misc/AssignOperatorCheck.cpp:74
@@ +73,3 @@
+  } else {
+std::string Name = Method->getParent()->getName();
+

This can be lowered into the if statement in place of Name.


Comment at: clang-tidy/misc/AssignOperatorCheck.h:19
@@ +18,3 @@
+
+/// Finds declarations of assign operators with the wrong return and/or 
argument
+/// types.

s/assign/assignment.


Comment at: test/clang-tidy/misc-assign-operator.cpp:15
@@ +14,3 @@
+  // By value is also fine.
+  AlsoGood& operator=(AlsoGood);
+};

This seems at odds with the core guidelines for 
cppcoreguidelines-c-copy-assignment-signature.


http://reviews.llvm.org/D18265



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

Re: [PATCH] D18424: [Clang] Fix Clang-tidy modernize-deprecated-headers warnings; other minor fixes

[Aaron Ballman via cfe-commits]

aaron.ballman added inline comments.


Comment at: include/clang-c/Index.h:19
@@ -18,1 +18,3 @@
 
+#ifdef __cplusplus
+#include 

Is this produced by the deprecated headers check? If not, what value does ctime 
add over time.h?


Comment at: lib/Lex/ModuleMap.cpp:1286
@@ -1284,3 +1285,3 @@
   };
-}
+} // end anonymous namespaces
 

namespace instead of namespaces


Repository:
  rL LLVM

http://reviews.llvm.org/D18424



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

Re: [PATCH] D18472: AMDGPU: Remove separate r600 double data layout

[Tom Stellard via cfe-commits]

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

LGTM.


http://reviews.llvm.org/D18472



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

Re: [PATCH] D18473: AMDGPU: Add test for generic builtin behavior

[Tom Stellard via cfe-commits]

tstellarAMD added inline comments.


Comment at: lib/Basic/Targets.cpp:1854-1857
@@ -1853,1 +1853,6 @@
 
+  bool isCLZForZeroUndef() const override {
+// It is -1 instead of expected for intrinsic.
+return true;
+  }
+

Why do we need to add this if it's the same as the default?


http://reviews.llvm.org/D18473



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

Re: r264428 - [ASTMatchers] Fix build for VariadicFunction.

[Samuel Benzaquen via cfe-commits]

On Fri, Mar 25, 2016 at 7:01 PM, Richard Smith 
wrote:

> On Fri, Mar 25, 2016 at 10:55 AM, David Blaikie via cfe-commits
>  wrote:
> >
> >
> > On Fri, Mar 25, 2016 at 10:46 AM, Samuel Benzaquen via cfe-commits
> >  wrote:
> >>
> >> Author: sbenza
> >> Date: Fri Mar 25 12:46:02 2016
> >> New Revision: 264428
> >>
> >> URL: http://llvm.org/viewvc/llvm-project?rev=264428=rev
> >> Log:
> >> [ASTMatchers] Fix build for VariadicFunction.
> >>
> >> Under some conditions the implicit conversion from array to ArrayRef<>
> >> is not working.
> >
> > Any idea what those conditions are?
>
> Well, the code's ill-formed (relying on a compiler extension) when
> Args is empty. Maybe GCC diagnoses that in some cases?
>

But Args is never empty on this function.
It is only every called from the 1+ arg overload of operator().
There is another overload for the 0-arg case to prevent this problem.


>
> >> Fix the build by making it explicit.
> >>
> >> Modified:
> >> cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h
> >>
> >> Modified: cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h
> >> URL:
> >>
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h?rev=264428=264427=264428=diff
> >>
> >>
> ==
> >> --- cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h (original)
> >> +++ cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h Fri Mar 25
> >> 12:46:02 2016
> >> @@ -90,7 +90,7 @@ private:
> >>// before we make the array.
> >>template  ResultT Execute(const ArgsT &... Args)
> >> const {
> >>  const ArgT *const ArgsArray[] = {};
> >> -return Func(ArgsArray);
> >> +return Func(ArrayRef(ArgsArray, sizeof...(ArgsT)));
> >>}
> >>  };
> >>
> >>
> >>
> >> ___
> >> 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
> >
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D16962: clang-tidy: avoid std::bind

[Aaron Ballman via cfe-commits]

aaron.ballman added inline comments.


Comment at: clang-tidy/readability/AvoidStdBindCheck.cpp:116
@@ +115,3 @@
+  Finder->addMatcher(
+  callExpr(callee(namedDecl(isStdBind())),
+   hasArgument(0, declRefExpr(to(functionDecl().bind("f")

alexfh wrote:
> You should be able to use `hasName("std::bind")` instead.
I think that has to be `hasName("::std::bind")` to support `namespace mine { 
namespace std { void bind(); } }`


Comment at: clang-tidy/readability/AvoidStdBindCheck.cpp:126
@@ +125,3 @@
+
+  if (!getLangOpts().CPlusPlus14) // Need C++14 for generic lambdas.
+return;

Might as well move this to the top of check() since there's no need to create 
the diagnostic or find the matched decl unless this check passes.


Comment at: clang-tidy/readability/ReadabilityTidyModule.cpp:37
@@ -35,1 +36,3 @@
+CheckFactories.registerCheck(
+"readability-avoid-std-bind");
 CheckFactories.registerCheck(

I kind of wonder if this should be in modernize instead of readability? Tough 
call, and I'm fine with either place, just wanted to pose the question.


Comment at: docs/clang-tidy/checks/readability-avoid-std-bind.rst:9
@@ +8,3 @@
+
+Right now it only handles free functions not member functions.
+

alexfh wrote:
> Add a comma before "not"?
or "and not" instead of a comma, if verbosity is your thing.


Comment at: test/clang-tidy/readability-avoid-std-bind.cpp:1
@@ +1,2 @@
+// RUN: %check_clang_tidy %s readability-avoid-std-bind %t -- -- -std=c++14
+

Can you clang-format this file as well?


Comment at: test/clang-tidy/readability-avoid-std-bind.cpp:21
@@ +20,3 @@
+
+// CHECK-FIXES: auto clj = [] { return add(2, 2); };
+

This should immediately follow the CHECK-MESSAGES in the same compound 
statement (here and elsewhere).


http://reviews.llvm.org/D16962



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

Re: [PATCH] D17861: [OpenCL] Accept __attribute__((nosvm))

[Aaron Ballman via cfe-commits]

aaron.ballman added inline comments.


Comment at: include/clang/Basic/Attr.td:701
@@ -699,1 +700,3 @@
 
+def OpenCLNoSVM : Attr {
+  let Spellings = [GNU<"nosvm">];

yaxunl wrote:
> aaron.ballman wrote:
> > yaxunl wrote:
> > > aaron.ballman wrote:
> > > > Since the attribute is ignored by clang, you should inherit from 
> > > > IgnoredAttr.
> > > I tried that from beginning. If I inherit from IgnoredAttr, it seems to 
> > > be ignored by the parser and won't reach the sema check part, and I 
> > > cannot emit error msg based on OpenCL version.
> > Ah. so it isn't *totally* ignored. Okay, in that case, you should set 
> > ASTNode = 0 and SemaHandler = 0.
> If I set ASTNode = 0 and SemaHandler = 0, tablegen will not generate an id 
> AT_OpenCLNoSVM to identify this attribute, and I cannot diagnose its invalid 
> usage in SemaDeclAttr.cpp due to that. Then it seems the only viable place to 
> diagnose its invalid usage is in Parser::ParseGNUAttributes. However 
> currently Parser::ParseGNUAttributes only does generic processing of GNU 
> attributes and does not diagnose specific attribute. Since there is no id for 
> NoSVM attribute, I have to diagnose based on its name string.
> 
> Do we really want to do this?
Oh! I forgot that setting SemaHandler to 0 means that the AttributeList 
enumeration won't get an entry for the attribute, so we probably diagnose it as 
being unknown rather than getting to the language option checking. Ugh, sorry 
for the noise, you will want SemaHandler = 1 still (which it is by default, so 
no need to explicitly specify that), but ASTNode = 0 since we don't generate 
any AST information for the attribute.


Repository:
  rL LLVM

http://reviews.llvm.org/D17861



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

Re: [PATCH] D17002: [lanai] Add Lanai backend to clang driver

[Jacques Pienaar via cfe-commits]

jpienaar added a comment.

Friendly ping.


http://reviews.llvm.org/D17002



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

Re: [PATCH] D17815: [libc++abi] Use fallback_malloc to allocate __cxa_eh_globals in case of dynamic memory exhaustion.

[Igor Kudrin via cfe-commits]

ikudrin updated the summary for this revision.
ikudrin updated this revision to Diff 51782.
ikudrin added a comment.

Make cxa_exception.cpp and cxa_exception_storage.cpp to use the same emergency 
memory pool.


http://reviews.llvm.org/D17815

Files:
  libcxxabi/trunk/src/CMakeLists.txt
  libcxxabi/trunk/src/cxa_exception.cpp
  libcxxabi/trunk/src/cxa_exception_storage.cpp
  libcxxabi/trunk/src/fallback_malloc.cpp
  libcxxabi/trunk/src/fallback_malloc.h
  libcxxabi/trunk/test/test_exception_storage_nodynmem.pass.cpp

Index: libcxxabi/trunk/test/test_exception_storage_nodynmem.pass.cpp
===
--- /dev/null
+++ libcxxabi/trunk/test/test_exception_storage_nodynmem.pass.cpp
@@ -0,0 +1,21 @@
+//===--- test_exception_storage_nodynmem.cpp --===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include 
+
+// Override calloc to simulate exhaustion of dynamic memory
+void *calloc(size_t, size_t) { return 0; }
+
+int main(int argc, char *argv[]) {
+  try {
+throw 42;
+  } catch (...) {
+  }
+  return 0;
+}
Index: libcxxabi/trunk/src/fallback_malloc.h
===
--- /dev/null
+++ libcxxabi/trunk/src/fallback_malloc.h
@@ -0,0 +1,29 @@
+//===- fallback_malloc.h --===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef _FALLBACK_MALLOC_H
+#define _FALLBACK_MALLOC_H
+
+namespace __cxxabiv1 {
+
+#pragma GCC visibility push(hidden)
+
+// Allocate some memory from _somewhere_
+void * __cxa_malloc_with_fallback(size_t size);
+
+// Allocate and zero-initialize memory from _somewhere_
+void * __cxa_calloc_with_fallback(size_t count, size_t size);
+
+void __cxa_free_with_fallback(void *ptr);
+
+#pragma GCC visibility pop
+
+} // namespace __cxxabiv1
+
+#endif
Index: libcxxabi/trunk/src/fallback_malloc.cpp
===
--- /dev/null
+++ libcxxabi/trunk/src/fallback_malloc.cpp
@@ -0,0 +1,49 @@
+//=== fallback_malloc.ipp -===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "config.h"
+
+#include  // for malloc, calloc, free
+#include  // for memset
+
+#if !LIBCXXABI_HAS_NO_THREADS
+#include  // for fallback_malloc.ipp's mutexes
+#endif
+
+#include "fallback_malloc.h"
+#include "fallback_malloc.ipp"
+
+namespace __cxxabiv1 {
+
+void * __cxa_malloc_with_fallback(size_t size) {
+void *ptr = std::malloc(size);
+if (NULL == ptr) // if malloc fails, fall back to emergency stash
+ptr = fallback_malloc(size);
+return ptr;
+}
+
+void * __cxa_calloc_with_fallback(size_t count, size_t size) {
+void *ptr = std::calloc(count, size);
+if (NULL != ptr)
+return ptr;
+// if calloc fails, fall back to emergency stash
+ptr = fallback_malloc(size * count);
+if (NULL != ptr)
+std::memset(ptr, 0, size * count);
+return ptr;
+}
+
+void __cxa_free_with_fallback(void *ptr) {
+if (is_fallback_ptr(ptr))
+fallback_free(ptr);
+else
+std::free(ptr);
+}
+
+} // namespace __cxxabiv1
Index: libcxxabi/trunk/src/cxa_exception_storage.cpp
===
--- libcxxabi/trunk/src/cxa_exception_storage.cpp
+++ libcxxabi/trunk/src/cxa_exception_storage.cpp
@@ -45,8 +45,8 @@
 #else
 
 #include 
-#include   // for calloc, free
 #include "abort_message.h"
+#include "fallback_malloc.h"
 
 //  In general, we treat all pthread errors as fatal.
 //  We cannot call std::terminate() because that will in turn
@@ -58,7 +58,7 @@
 pthread_once_t flag_ = PTHREAD_ONCE_INIT;
 
 void destruct_ (void *p) {
-std::free ( p );
+__cxa_free_with_fallback ( p );
 if ( 0 != ::pthread_setspecific ( key_, NULL ) ) 
 abort_message("cannot zero out thread value for __cxa_get_globals()");
 }
@@ -77,7 +77,7 @@
 //  If this is the first time we've been asked for these globals, create them
 if ( NULL == retVal ) {
 retVal = static_cast<__cxa_eh_globals*>
-(std::calloc (1, sizeof (__cxa_eh_globals)));
+

r264577 - Revert "[OPENMP] Allow runtime insert its own code inside OpenMP regions."

[Alexey Bataev via cfe-commits]

Author: abataev
Date: Mon Mar 28 07:58:34 2016
New Revision: 264577

URL: http://llvm.org/viewvc/llvm-project?rev=264577=rev
Log:
Revert "[OPENMP] Allow runtime insert its own code inside OpenMP regions."

Reverting because of failed tests.

Modified:
cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
cfe/trunk/lib/CodeGen/CGOpenMPRuntime.h
cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.h
cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp
cfe/trunk/lib/CodeGen/CodeGenFunction.h
cfe/trunk/test/OpenMP/critical_codegen.cpp
cfe/trunk/test/OpenMP/parallel_copyin_codegen.cpp
cfe/trunk/test/OpenMP/single_codegen.cpp
cfe/trunk/test/OpenMP/taskgroup_codegen.cpp

Modified: cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp?rev=264577=264576=264577=diff
==
--- cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp Mon Mar 28 07:58:34 2016
@@ -252,7 +252,7 @@ private:
   StringRef HelperName;
 };
 
-static void EmptyCodeGen(CodeGenFunction &, PrePostActionTy &) {
+static void EmptyCodeGen(CodeGenFunction &) {
   llvm_unreachable("No codegen for expressions");
 }
 /// \brief API for generation of expressions captured in a innermost OpenMP
@@ -564,33 +564,8 @@ enum OpenMPRTLFunction {
   OMPRTL__tgt_unregister_lib,
 };
 
-/// A basic class for pre|post-action for advanced codegen sequence for OpenMP
-/// region.
-class CleanupTy final : public EHScopeStack::Cleanup {
-  PrePostActionTy *Action;
-
-public:
-  explicit CleanupTy(PrePostActionTy *Action) : Action(Action) {}
-  void Emit(CodeGenFunction , Flags /*flags*/) override {
-if (!CGF.HaveInsertPoint())
-  return;
-Action->Exit(CGF);
-  }
-};
-
 } // anonymous namespace
 
-void RegionCodeGenTy::operator()(CodeGenFunction ) const {
-  CodeGenFunction::RunCleanupsScope Scope(CGF);
-  if (PrePostAction) {
-CGF.EHStack.pushCleanup(NormalAndEHCleanup, PrePostAction);
-Callback(CodeGen, CGF, *PrePostAction);
-  } else {
-PrePostActionTy Action;
-Callback(CodeGen, CGF, Action);
-  }
-}
-
 LValue CGOpenMPRegionInfo::getThreadIDVariableLValue(CodeGenFunction ) {
   return CGF.EmitLoadOfPointerLValue(
   CGF.GetAddrOfLocalVar(getThreadIDVariable()),
@@ -606,7 +581,10 @@ void CGOpenMPRegionInfo::EmitBody(CodeGe
   // The point of exit cannot be a branch out of the structured block.
   // longjmp() and throw() must not violate the entry/exit criteria.
   CGF.EHStack.pushTerminate();
-  CodeGen(CGF);
+  {
+CodeGenFunction::RunCleanupsScope Scope(CGF);
+CodeGen(CGF);
+  }
   CGF.EHStack.popTerminate();
 }
 
@@ -623,6 +601,10 @@ CGOpenMPRuntime::CGOpenMPRuntime(CodeGen
   "ident_t", CGM.Int32Ty /* reserved_1 */, CGM.Int32Ty /* flags */,
   CGM.Int32Ty /* reserved_2 */, CGM.Int32Ty /* reserved_3 */,
   CGM.Int8PtrTy /* psource */, nullptr);
+  // Build void (*kmpc_micro)(kmp_int32 *global_tid, kmp_int32 *bound_tid,...)
+  llvm::Type *MicroParams[] = {llvm::PointerType::getUnqual(CGM.Int32Ty),
+   llvm::PointerType::getUnqual(CGM.Int32Ty)};
+  Kmpc_MicroTy = llvm::FunctionType::get(CGM.VoidTy, MicroParams, true);
   KmpCriticalNameTy = llvm::ArrayType::get(CGM.Int32Ty, /*NumElements*/ 8);
 
   loadOffloadInfoMetadata();
@@ -914,18 +896,10 @@ void CGOpenMPRuntime::functionFinished(C
 }
 
 llvm::Type *CGOpenMPRuntime::getIdentTyPointerTy() {
-  if (!IdentTy) {
-  }
   return llvm::PointerType::getUnqual(IdentTy);
 }
 
 llvm::Type *CGOpenMPRuntime::getKmpc_MicroPointerTy() {
-  if (!Kmpc_MicroTy) {
-// Build void (*kmpc_micro)(kmp_int32 *global_tid, kmp_int32 
*bound_tid,...)
-llvm::Type *MicroParams[] = {llvm::PointerType::getUnqual(CGM.Int32Ty),
- llvm::PointerType::getUnqual(CGM.Int32Ty)};
-Kmpc_MicroTy = llvm::FunctionType::get(CGM.VoidTy, MicroParams, true);
-  }
   return llvm::PointerType::getUnqual(Kmpc_MicroTy);
 }
 
@@ -1670,10 +1644,12 @@ static void emitOMPIfClause(CodeGenFunct
   // the condition and the dead arm of the if/else.
   bool CondConstant;
   if (CGF.ConstantFoldsToSimpleInteger(Cond, CondConstant)) {
-if (CondConstant)
+CodeGenFunction::RunCleanupsScope Scope(CGF);
+if (CondConstant) {
   ThenGen(CGF);
-else
+} else {
   ElseGen(CGF);
+}
 return;
   }
 
@@ -1686,16 +1662,26 @@ static void emitOMPIfClause(CodeGenFunct
 
   // Emit the 'then' code.
   CGF.EmitBlock(ThenBlock);
-  ThenGen(CGF);
+  {
+CodeGenFunction::RunCleanupsScope ThenScope(CGF);
+ThenGen(CGF);
+  }
   CGF.EmitBranch(ContBlock);
   // Emit the 'else' code if present.
-  // There is no need to emit line number for unconditional branch.
-  (void)ApplyDebugLocation::CreateEmpty(CGF);
-  CGF.EmitBlock(ElseBlock);
-  ElseGen(CGF);
-  // There is no need to emit line number for 

r264576 - [OPENMP] Allow runtime insert its own code inside OpenMP regions.

[Alexey Bataev via cfe-commits]

Author: abataev
Date: Mon Mar 28 07:52:58 2016
New Revision: 264576

URL: http://llvm.org/viewvc/llvm-project?rev=264576=rev
Log:
[OPENMP] Allow runtime insert its own code inside OpenMP regions.

Solution unifies interface of RegionCodeGenTy type to allow insert
runtime-specific code before/after main codegen action defined in
CGStmtOpenMP.cpp file. Runtime should not define its own RegionCodeGenTy
for general OpenMP directives, but must be allowed to insert its own
 (required) code to support target specific codegen.

Modified:
cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
cfe/trunk/lib/CodeGen/CGOpenMPRuntime.h
cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.h
cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp
cfe/trunk/lib/CodeGen/CodeGenFunction.h
cfe/trunk/test/OpenMP/critical_codegen.cpp
cfe/trunk/test/OpenMP/parallel_copyin_codegen.cpp
cfe/trunk/test/OpenMP/single_codegen.cpp
cfe/trunk/test/OpenMP/taskgroup_codegen.cpp

Modified: cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp?rev=264576=264575=264576=diff
==
--- cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp Mon Mar 28 07:52:58 2016
@@ -252,7 +252,7 @@ private:
   StringRef HelperName;
 };
 
-static void EmptyCodeGen(CodeGenFunction &) {
+static void EmptyCodeGen(CodeGenFunction &, PrePostActionTy &) {
   llvm_unreachable("No codegen for expressions");
 }
 /// \brief API for generation of expressions captured in a innermost OpenMP
@@ -564,8 +564,33 @@ enum OpenMPRTLFunction {
   OMPRTL__tgt_unregister_lib,
 };
 
+/// A basic class for pre|post-action for advanced codegen sequence for OpenMP
+/// region.
+class CleanupTy final : public EHScopeStack::Cleanup {
+  PrePostActionTy *Action;
+
+public:
+  explicit CleanupTy(PrePostActionTy *Action) : Action(Action) {}
+  void Emit(CodeGenFunction , Flags /*flags*/) override {
+if (!CGF.HaveInsertPoint())
+  return;
+Action->Exit(CGF);
+  }
+};
+
 } // anonymous namespace
 
+void RegionCodeGenTy::operator()(CodeGenFunction ) const {
+  CodeGenFunction::RunCleanupsScope Scope(CGF);
+  if (PrePostAction) {
+CGF.EHStack.pushCleanup(NormalAndEHCleanup, PrePostAction);
+Callback(CodeGen, CGF, *PrePostAction);
+  } else {
+PrePostActionTy Action;
+Callback(CodeGen, CGF, Action);
+  }
+}
+
 LValue CGOpenMPRegionInfo::getThreadIDVariableLValue(CodeGenFunction ) {
   return CGF.EmitLoadOfPointerLValue(
   CGF.GetAddrOfLocalVar(getThreadIDVariable()),
@@ -581,10 +606,7 @@ void CGOpenMPRegionInfo::EmitBody(CodeGe
   // The point of exit cannot be a branch out of the structured block.
   // longjmp() and throw() must not violate the entry/exit criteria.
   CGF.EHStack.pushTerminate();
-  {
-CodeGenFunction::RunCleanupsScope Scope(CGF);
-CodeGen(CGF);
-  }
+  CodeGen(CGF);
   CGF.EHStack.popTerminate();
 }
 
@@ -601,10 +623,6 @@ CGOpenMPRuntime::CGOpenMPRuntime(CodeGen
   "ident_t", CGM.Int32Ty /* reserved_1 */, CGM.Int32Ty /* flags */,
   CGM.Int32Ty /* reserved_2 */, CGM.Int32Ty /* reserved_3 */,
   CGM.Int8PtrTy /* psource */, nullptr);
-  // Build void (*kmpc_micro)(kmp_int32 *global_tid, kmp_int32 *bound_tid,...)
-  llvm::Type *MicroParams[] = {llvm::PointerType::getUnqual(CGM.Int32Ty),
-   llvm::PointerType::getUnqual(CGM.Int32Ty)};
-  Kmpc_MicroTy = llvm::FunctionType::get(CGM.VoidTy, MicroParams, true);
   KmpCriticalNameTy = llvm::ArrayType::get(CGM.Int32Ty, /*NumElements*/ 8);
 
   loadOffloadInfoMetadata();
@@ -896,10 +914,18 @@ void CGOpenMPRuntime::functionFinished(C
 }
 
 llvm::Type *CGOpenMPRuntime::getIdentTyPointerTy() {
+  if (!IdentTy) {
+  }
   return llvm::PointerType::getUnqual(IdentTy);
 }
 
 llvm::Type *CGOpenMPRuntime::getKmpc_MicroPointerTy() {
+  if (!Kmpc_MicroTy) {
+// Build void (*kmpc_micro)(kmp_int32 *global_tid, kmp_int32 
*bound_tid,...)
+llvm::Type *MicroParams[] = {llvm::PointerType::getUnqual(CGM.Int32Ty),
+ llvm::PointerType::getUnqual(CGM.Int32Ty)};
+Kmpc_MicroTy = llvm::FunctionType::get(CGM.VoidTy, MicroParams, true);
+  }
   return llvm::PointerType::getUnqual(Kmpc_MicroTy);
 }
 
@@ -1644,12 +1670,10 @@ static void emitOMPIfClause(CodeGenFunct
   // the condition and the dead arm of the if/else.
   bool CondConstant;
   if (CGF.ConstantFoldsToSimpleInteger(Cond, CondConstant)) {
-CodeGenFunction::RunCleanupsScope Scope(CGF);
-if (CondConstant) {
+if (CondConstant)
   ThenGen(CGF);
-} else {
+else
   ElseGen(CGF);
-}
 return;
   }
 
@@ -1662,26 +1686,16 @@ static void emitOMPIfClause(CodeGenFunct
 
   // Emit the 'then' code.
   CGF.EmitBlock(ThenBlock);
-  {
-CodeGenFunction::RunCleanupsScope ThenScope(CGF);
-ThenGen(CGF);
-  }
+  

[PATCH] tools: Low hanging Python 3 compatibility fixes

[Ville Skyttä via cfe-commits]

---
 tools/clang-format/clang-format-diff.py |  4 +--
 tools/clang-format/clang-format.py  |  6 ++---
 tools/clang-format/git-clang-format | 42 --
 tools/scan-build/bin/set-xcode-analyzer | 24 -
 tools/scan-view/bin/scan-view   | 11 
 tools/scan-view/share/Reporter.py   |  6 ++---
 tools/scan-view/share/ScanView.py   | 46 -
 tools/scan-view/share/startfile.py  |  2 +-
 8 files changed, 72 insertions(+), 69 deletions(-)

diff --git a/tools/clang-format/clang-format-diff.py b/tools/clang-format/clang-format-diff.py
index 5e728f5..8bf5ce0 100755
--- a/tools/clang-format/clang-format-diff.py
+++ b/tools/clang-format/clang-format-diff.py
@@ -89,9 +89,9 @@ def main():
   ['-lines', str(start_line) + ':' + str(end_line)])
 
   # Reformat files containing changes in place.
-  for filename, lines in lines_by_file.iteritems():
+  for filename, lines in lines_by_file.items():
 if args.i and args.verbose:
-  print 'Formatting', filename
+  print('Formatting %s' % filename)
 command = [args.binary, filename]
 if args.i:
   command.append('-i')
diff --git a/tools/clang-format/clang-format.py b/tools/clang-format/clang-format.py
index 5cb41fc..68a6a32 100644
--- a/tools/clang-format/clang-format.py
+++ b/tools/clang-format/clang-format.py
@@ -61,7 +61,7 @@ def main():
   # Determine the cursor position.
   cursor = int(vim.eval('line2byte(line("."))+col(".")')) - 2
   if cursor < 0:
-print 'Couldn\'t determine cursor position. Is your file empty?'
+print('Couldn\'t determine cursor position. Is your file empty?')
 return
 
   # Avoid flashing an ugly, ugly cmd prompt on Windows when invoking clang-format.
@@ -86,7 +86,7 @@ def main():
 
   # If successful, replace buffer contents.
   if stderr:
-print stderr
+print(stderr)
 
   if not stdout:
 print ('No output from clang-format (crashed?).\n' +
@@ -100,7 +100,7 @@ def main():
   if op[0] is not 'equal':
 vim.current.buffer[op[1]:op[2]] = lines[op[3]:op[4]]
 if output.get('IncompleteFormat'):
-  print 'clang-format: incomplete (syntax errors)'
+  print('clang-format: incomplete (syntax errors)')
 vim.command('goto %d' % (output['Cursor'] + 1))
 
 main()
diff --git a/tools/clang-format/git-clang-format b/tools/clang-format/git-clang-format
index 0c45762..99a6fe6 100755
--- a/tools/clang-format/git-clang-format
+++ b/tools/clang-format/git-clang-format
@@ -23,6 +23,8 @@ git clang-format -h
 Requires Python 2.7  
 """   
 
+from __future__ import print_function
+
 import argparse
 import collections
 import contextlib
@@ -128,15 +130,15 @@ def main():
   if opts.verbose >= 1:
 ignored_files.difference_update(changed_lines)
 if ignored_files:
-  print 'Ignoring changes in the following files (wrong extension):'
+  print('Ignoring changes in the following files (wrong extension):')
   for filename in ignored_files:
-print '   ', filename
+print('   ', filename)
 if changed_lines:
-  print 'Running clang-format on the following files:'
+  print('Running clang-format on the following files:')
   for filename in changed_lines:
-print '   ', filename
+print('   ', filename)
   if not changed_lines:
-print 'no modified files to format'
+print('no modified files to format')
 return
   # The computed diff outputs absolute paths, so we must cd before accessing
   # those files.
@@ -146,20 +148,20 @@ def main():
binary=opts.binary,
style=opts.style)
   if opts.verbose >= 1:
-print 'old tree:', old_tree
-print 'new tree:', new_tree
+print('old tree:', old_tree)
+print('new tree:', new_tree)
   if old_tree == new_tree:
 if opts.verbose >= 0:
-  print 'clang-format did not modify any files'
+  print('clang-format did not modify any files')
   elif opts.diff:
 print_diff(old_tree, new_tree)
   else:
 changed_files = apply_changes(old_tree, new_tree, force=opts.force,
   patch_mode=opts.patch)
 if (opts.verbose >= 0 and not opts.patch) or opts.verbose >= 1:
-  print 'changed files:'
+  print('changed files:')
   for filename in changed_files:
-print '   ', filename
+print('   ', filename)
 
 
 def load_git_config(non_string_options=None):
@@ -323,7 +325,7 @@ def run_clang_format_and_save_to_tree(changed_lines, binary='clang-format',
 
   Returns the object ID (SHA-1) of the created tree."""
   def index_info_generator():
-for filename, line_ranges in changed_lines.iteritems():
+for filename, line_ranges in changed_lines.items():
   mode = oct(os.stat(filename).st_mode)
   blob_id = clang_format_to_blob(filename, line_ranges, binary=binary,

Re: r263709 - clang-format: Slightly weaken AlignAfterOpenBracket=AlwaysBreak.

[Jean-philippe Dufraigne via cfe-commits]

Hi Daniel,

Thanks, I understand why your users would have requested that and why you
need to provide this improvement for them.
I will survey the other people writing code with me on whether they are
happy with this improvement considering both the readability of the
statements and the relatively small impact in our day to day
reading/writing.
I'll get back to you, maybe I was wasting time on a non issue..

Cheers,
Jean-Philippe.


2016-03-28 9:51 GMT+01:00 Daniel Jasper :

> Hi Jean-Philippe,
>
> no, you have not convinced me with those examples. There is not a single
> one, I find more readable. Many of them I find equally unreadable and would
> write the code differently. But I would never have chose AlwaysBreak for my
> own code in the first place and I rarely work in a codebase that uses it.
> When I do, it usually bugs me. So, that (my opinion) is completely beside
> the point.
>
> There is one fundamental half-way objective argument you can make here
> (and in many other cases): Being more compact generally makes it easier to
> read larger chunks of code as it is more likely for a whole
> function/loop/... to fit on a single page. Using more linebreaks to make
> the syntactic structure clearer and more uniform can make individual
> statements more readable. My argument is that in this case, often many
> lines are saved with very little to no impact on local readability. You
> disagree and that's fine, I am not trying to convince you. People a
> different here.
>
> If you need the uniformity so that many subsequent statements are
> formatted equally (e.g. in your "connRegist.Add( ..." case), you are
> likely doing it wrong. Try harder not to repeat yourself. The problem here
> is that such uniformly appearing sequence can hide very subtle (copy)
> errors. However, even all of this is beside the point.
>
> You found changes in ~10% of your files. I'd bet that less than 10% of a
> file was changed on average. So, this influences <1% of the code. That is
> reasonably rare and you won't stumble over this frequently in practice.
> Yes, of course you see hundreds of examples when you reformat a
> thousand-file codebase and I understand why that bugs you.
>
> I definitely need the new behavior as it was requested frequently by my
> internal users. This was the most frequent bug report I have gotten from
> people using AlwaysBreak. I suggest that you also speak to the other
> authors of the codebase you are working on to make sure that you are
> actually getting a feel for what most people want here. And also include
> cases where it is significantly better IMO:
>
>   call(call(call(call(call(call(call(call(call(call(call(
> parameterThatGoesUpToTheColumnLimit)));
>
> vs.
>
>   call(
>   call(
>   call(
>   call(
>   ...
>   parameterThatGoesUpToTheColumnLimit)));  //
> probably even a column limit violation
>
> Again, I am not against adding an additional option. And if we do
> introduce a new option, we should probably make that one strict and not
> have the other exceptions.
>
> Cheers,
> Daniel
>
>
> On Sun, Mar 27, 2016 at 8:16 PM, Jean-philippe Dufraigne <
> j.dufrai...@gmail.com> wrote:
>
>> Hi Daniel,
>>
>> Thanks a lot for your answer and clarifications.
>> Sorry for the long answer, TLDR at the beginning (and end for code
>> examples).
>>
>> To answer your 2 questions immediately:
>> - It happens a lot more than I thought, about 10% of the few thousands
>> file I checked had instances of this.
>> - Yes, there is a significant readability disadvantage as these
>> functions become a special case that needs to be read differently from all
>> the other functions.
>>   With consistent AlwaysBreak, it is obvious from the shape of the call
>> how to read it (horizontally or diagonally).
>>   Now, it is not longer obvious and it impact readability mostly for
>> these functions, but also a bit for the other functions since it is not
>> clear if they are one of the special case or not.
>>   (The eye needs to jump at the end and then back to parse the arguments)
>>   (This ls less/not of an issue for lambda and small functions)
>>
>>
>> My conclusion:
>> I really think an option should provide a consistent break but I'm really
>> not sure it should be a new option.
>> If I manage to convince you through the examples, that formatting all
>> function consistently will actually improve overall readability more
>> generally, I think AlwaysBreak is just fine as it was.
>> I'm happy to help with coding or writing tests for whatever decision you
>> make.
>>
>>
>> Examples:
>> I've pasted / attached the code examples that I saw, some many many times
>> (with .clang-format file).
>> You'll be able to see how before things were more consistent and now
>> things are moved to unexpected places depending on the call.
>> Moreover the benefit is very limited for us, because gaining 1 line does
>> not seem to add to our 

r264570 - Revert "[OPENMP] Allow runtime insert its own code inside OpenMP regions."

[Alexey Bataev via cfe-commits]

Author: abataev
Date: Mon Mar 28 05:12:03 2016
New Revision: 264570

URL: http://llvm.org/viewvc/llvm-project?rev=264570=rev
Log:
Revert "[OPENMP] Allow runtime insert its own code inside OpenMP regions."

This reverts commit 3ee791165100607178073f14531a0dc90c622b36.

Modified:
cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
cfe/trunk/lib/CodeGen/CGOpenMPRuntime.h
cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.h
cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp
cfe/trunk/lib/CodeGen/CodeGenFunction.h
cfe/trunk/test/OpenMP/critical_codegen.cpp
cfe/trunk/test/OpenMP/parallel_copyin_codegen.cpp
cfe/trunk/test/OpenMP/single_codegen.cpp
cfe/trunk/test/OpenMP/taskgroup_codegen.cpp

Modified: cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp?rev=264570=264569=264570=diff
==
--- cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp Mon Mar 28 05:12:03 2016
@@ -252,7 +252,7 @@ private:
   StringRef HelperName;
 };
 
-static void EmptyCodeGen(CodeGenFunction &, PrePostActionTy &) {
+static void EmptyCodeGen(CodeGenFunction &) {
   llvm_unreachable("No codegen for expressions");
 }
 /// \brief API for generation of expressions captured in a innermost OpenMP
@@ -564,33 +564,8 @@ enum OpenMPRTLFunction {
   OMPRTL__tgt_unregister_lib,
 };
 
-/// A basic class for pre|post-action for advanced codegen sequence for OpenMP
-/// region.
-class CleanupTy final : public EHScopeStack::Cleanup {
-  PrePostActionTy *Action;
-
-public:
-  explicit CleanupTy(PrePostActionTy *Action) : Action(Action) {}
-  void Emit(CodeGenFunction , Flags /*flags*/) override {
-if (!CGF.HaveInsertPoint())
-  return;
-Action->Exit(CGF);
-  }
-};
-
 } // anonymous namespace
 
-void RegionCodeGenTy::operator()(CodeGenFunction ) const {
-  CodeGenFunction::RunCleanupsScope Scope(CGF);
-  if (PrePostAction) {
-CGF.EHStack.pushCleanup(NormalAndEHCleanup, PrePostAction);
-Callback(CodeGen, CGF, *PrePostAction);
-  } else {
-PrePostActionTy Action;
-Callback(CodeGen, CGF, Action);
-  }
-}
-
 LValue CGOpenMPRegionInfo::getThreadIDVariableLValue(CodeGenFunction ) {
   return CGF.EmitLoadOfPointerLValue(
   CGF.GetAddrOfLocalVar(getThreadIDVariable()),
@@ -606,7 +581,10 @@ void CGOpenMPRegionInfo::EmitBody(CodeGe
   // The point of exit cannot be a branch out of the structured block.
   // longjmp() and throw() must not violate the entry/exit criteria.
   CGF.EHStack.pushTerminate();
-  CodeGen(CGF);
+  {
+CodeGenFunction::RunCleanupsScope Scope(CGF);
+CodeGen(CGF);
+  }
   CGF.EHStack.popTerminate();
 }
 
@@ -1666,10 +1644,12 @@ static void emitOMPIfClause(CodeGenFunct
   // the condition and the dead arm of the if/else.
   bool CondConstant;
   if (CGF.ConstantFoldsToSimpleInteger(Cond, CondConstant)) {
-if (CondConstant)
+CodeGenFunction::RunCleanupsScope Scope(CGF);
+if (CondConstant) {
   ThenGen(CGF);
-else
+} else {
   ElseGen(CGF);
+}
 return;
   }
 
@@ -1682,16 +1662,26 @@ static void emitOMPIfClause(CodeGenFunct
 
   // Emit the 'then' code.
   CGF.EmitBlock(ThenBlock);
-  ThenGen(CGF);
+  {
+CodeGenFunction::RunCleanupsScope ThenScope(CGF);
+ThenGen(CGF);
+  }
   CGF.EmitBranch(ContBlock);
   // Emit the 'else' code if present.
-  // There is no need to emit line number for unconditional branch.
-  (void)ApplyDebugLocation::CreateEmpty(CGF);
-  CGF.EmitBlock(ElseBlock);
-  ElseGen(CGF);
-  // There is no need to emit line number for unconditional branch.
-  (void)ApplyDebugLocation::CreateEmpty(CGF);
-  CGF.EmitBranch(ContBlock);
+  {
+// There is no need to emit line number for unconditional branch.
+auto NL = ApplyDebugLocation::CreateEmpty(CGF);
+CGF.EmitBlock(ElseBlock);
+  }
+  {
+CodeGenFunction::RunCleanupsScope ThenScope(CGF);
+ElseGen(CGF);
+  }
+  {
+// There is no need to emit line number for unconditional branch.
+auto NL = ApplyDebugLocation::CreateEmpty(CGF);
+CGF.EmitBranch(ContBlock);
+  }
   // Emit the continuation block for code after the if.
   CGF.EmitBlock(ContBlock, /*IsFinished=*/true);
 }
@@ -1703,8 +1693,8 @@ void CGOpenMPRuntime::emitParallelCall(C
   if (!CGF.HaveInsertPoint())
 return;
   auto *RTLoc = emitUpdateLocation(CGF, Loc);
-  RegionCodeGenTy ThenGen = [this, OutlinedFn, CapturedVars,
-RTLoc](CodeGenFunction , PrePostActionTy &) {
+  auto & = [this, OutlinedFn, CapturedVars,
+RTLoc](CodeGenFunction ) {
 // Build call __kmpc_fork_call(loc, n, microtask, var1, .., varn);
 llvm::Value *Args[] = {
 RTLoc,
@@ -1717,8 +1707,8 @@ void CGOpenMPRuntime::emitParallelCall(C
 auto RTLFn = createRuntimeFunction(OMPRTL__kmpc_fork_call);
 CGF.EmitRuntimeCall(RTLFn, RealArgs);
   };
-  

r264569 - [OPENMP] Allow runtime insert its own code inside OpenMP regions.

[Alexey Bataev via cfe-commits]

Author: abataev
Date: Mon Mar 28 04:53:43 2016
New Revision: 264569

URL: http://llvm.org/viewvc/llvm-project?rev=264569=rev
Log:
[OPENMP] Allow runtime insert its own code inside OpenMP regions.

Solution unifies interface of RegionCodeGenTy type to allow insert
runtime-specific code before/after main codegen action defined in
CGStmtOpenMP.cpp file. Runtime should not define its own RegionCodeGenTy
for general OpenMP directives, but must be allowed to insert its own
  (required) code to support target specific codegen.

Modified:
cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
cfe/trunk/lib/CodeGen/CGOpenMPRuntime.h
cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.h
cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp
cfe/trunk/lib/CodeGen/CodeGenFunction.h
cfe/trunk/test/OpenMP/critical_codegen.cpp
cfe/trunk/test/OpenMP/parallel_copyin_codegen.cpp
cfe/trunk/test/OpenMP/single_codegen.cpp
cfe/trunk/test/OpenMP/taskgroup_codegen.cpp

Modified: cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp?rev=264569=264568=264569=diff
==
--- cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp Mon Mar 28 04:53:43 2016
@@ -252,7 +252,7 @@ private:
   StringRef HelperName;
 };
 
-static void EmptyCodeGen(CodeGenFunction &) {
+static void EmptyCodeGen(CodeGenFunction &, PrePostActionTy &) {
   llvm_unreachable("No codegen for expressions");
 }
 /// \brief API for generation of expressions captured in a innermost OpenMP
@@ -564,8 +564,33 @@ enum OpenMPRTLFunction {
   OMPRTL__tgt_unregister_lib,
 };
 
+/// A basic class for pre|post-action for advanced codegen sequence for OpenMP
+/// region.
+class CleanupTy final : public EHScopeStack::Cleanup {
+  PrePostActionTy *Action;
+
+public:
+  explicit CleanupTy(PrePostActionTy *Action) : Action(Action) {}
+  void Emit(CodeGenFunction , Flags /*flags*/) override {
+if (!CGF.HaveInsertPoint())
+  return;
+Action->Exit(CGF);
+  }
+};
+
 } // anonymous namespace
 
+void RegionCodeGenTy::operator()(CodeGenFunction ) const {
+  CodeGenFunction::RunCleanupsScope Scope(CGF);
+  if (PrePostAction) {
+CGF.EHStack.pushCleanup(NormalAndEHCleanup, PrePostAction);
+Callback(CodeGen, CGF, *PrePostAction);
+  } else {
+PrePostActionTy Action;
+Callback(CodeGen, CGF, Action);
+  }
+}
+
 LValue CGOpenMPRegionInfo::getThreadIDVariableLValue(CodeGenFunction ) {
   return CGF.EmitLoadOfPointerLValue(
   CGF.GetAddrOfLocalVar(getThreadIDVariable()),
@@ -581,10 +606,7 @@ void CGOpenMPRegionInfo::EmitBody(CodeGe
   // The point of exit cannot be a branch out of the structured block.
   // longjmp() and throw() must not violate the entry/exit criteria.
   CGF.EHStack.pushTerminate();
-  {
-CodeGenFunction::RunCleanupsScope Scope(CGF);
-CodeGen(CGF);
-  }
+  CodeGen(CGF);
   CGF.EHStack.popTerminate();
 }
 
@@ -1644,12 +1666,10 @@ static void emitOMPIfClause(CodeGenFunct
   // the condition and the dead arm of the if/else.
   bool CondConstant;
   if (CGF.ConstantFoldsToSimpleInteger(Cond, CondConstant)) {
-CodeGenFunction::RunCleanupsScope Scope(CGF);
-if (CondConstant) {
+if (CondConstant)
   ThenGen(CGF);
-} else {
+else
   ElseGen(CGF);
-}
 return;
   }
 
@@ -1662,26 +1682,16 @@ static void emitOMPIfClause(CodeGenFunct
 
   // Emit the 'then' code.
   CGF.EmitBlock(ThenBlock);
-  {
-CodeGenFunction::RunCleanupsScope ThenScope(CGF);
-ThenGen(CGF);
-  }
+  ThenGen(CGF);
   CGF.EmitBranch(ContBlock);
   // Emit the 'else' code if present.
-  {
-// There is no need to emit line number for unconditional branch.
-auto NL = ApplyDebugLocation::CreateEmpty(CGF);
-CGF.EmitBlock(ElseBlock);
-  }
-  {
-CodeGenFunction::RunCleanupsScope ThenScope(CGF);
-ElseGen(CGF);
-  }
-  {
-// There is no need to emit line number for unconditional branch.
-auto NL = ApplyDebugLocation::CreateEmpty(CGF);
-CGF.EmitBranch(ContBlock);
-  }
+  // There is no need to emit line number for unconditional branch.
+  (void)ApplyDebugLocation::CreateEmpty(CGF);
+  CGF.EmitBlock(ElseBlock);
+  ElseGen(CGF);
+  // There is no need to emit line number for unconditional branch.
+  (void)ApplyDebugLocation::CreateEmpty(CGF);
+  CGF.EmitBranch(ContBlock);
   // Emit the continuation block for code after the if.
   CGF.EmitBlock(ContBlock, /*IsFinished=*/true);
 }
@@ -1693,8 +1703,8 @@ void CGOpenMPRuntime::emitParallelCall(C
   if (!CGF.HaveInsertPoint())
 return;
   auto *RTLoc = emitUpdateLocation(CGF, Loc);
-  auto & = [this, OutlinedFn, CapturedVars,
-RTLoc](CodeGenFunction ) {
+  RegionCodeGenTy ThenGen = [this, OutlinedFn, CapturedVars,
+RTLoc](CodeGenFunction , PrePostActionTy &) {
 // Build call __kmpc_fork_call(loc, 

Re: r263709 - clang-format: Slightly weaken AlignAfterOpenBracket=AlwaysBreak.

[Daniel Jasper via cfe-commits]

Hi Jean-Philippe,

no, you have not convinced me with those examples. There is not a single
one, I find more readable. Many of them I find equally unreadable and would
write the code differently. But I would never have chose AlwaysBreak for my
own code in the first place and I rarely work in a codebase that uses it.
When I do, it usually bugs me. So, that (my opinion) is completely beside
the point.

There is one fundamental half-way objective argument you can make here (and
in many other cases): Being more compact generally makes it easier to read
larger chunks of code as it is more likely for a whole function/loop/... to
fit on a single page. Using more linebreaks to make the syntactic structure
clearer and more uniform can make individual statements more readable. My
argument is that in this case, often many lines are saved with very little
to no impact on local readability. You disagree and that's fine, I am not
trying to convince you. People a different here.

If you need the uniformity so that many subsequent statements are formatted
equally (e.g. in your "connRegist.Add( ..." case), you are likely doing it
wrong. Try harder not to repeat yourself. The problem here is that such
uniformly appearing sequence can hide very subtle (copy) errors.
However, even all of this is beside the point.

You found changes in ~10% of your files. I'd bet that less than 10% of a
file was changed on average. So, this influences <1% of the code. That is
reasonably rare and you won't stumble over this frequently in practice.
Yes, of course you see hundreds of examples when you reformat a
thousand-file codebase and I understand why that bugs you.

I definitely need the new behavior as it was requested frequently by my
internal users. This was the most frequent bug report I have gotten from
people using AlwaysBreak. I suggest that you also speak to the other
authors of the codebase you are working on to make sure that you are
actually getting a feel for what most people want here. And also include
cases where it is significantly better IMO:

  call(call(call(call(call(call(call(call(call(call(call(
parameterThatGoesUpToTheColumnLimit)));

vs.

  call(
  call(
  call(
  call(
  ...
  parameterThatGoesUpToTheColumnLimit)));  //
probably even a column limit violation

Again, I am not against adding an additional option. And if we do introduce
a new option, we should probably make that one strict and not have the
other exceptions.

Cheers,
Daniel


On Sun, Mar 27, 2016 at 8:16 PM, Jean-philippe Dufraigne <
j.dufrai...@gmail.com> wrote:

> Hi Daniel,
>
> Thanks a lot for your answer and clarifications.
> Sorry for the long answer, TLDR at the beginning (and end for code
> examples).
>
> To answer your 2 questions immediately:
> - It happens a lot more than I thought, about 10% of the few thousands
> file I checked had instances of this.
> - Yes, there is a significant readability disadvantage as these functions
> become a special case that needs to be read differently from all the other
> functions.
>   With consistent AlwaysBreak, it is obvious from the shape of the call
> how to read it (horizontally or diagonally).
>   Now, it is not longer obvious and it impact readability mostly for these
> functions, but also a bit for the other functions since it is not clear if
> they are one of the special case or not.
>   (The eye needs to jump at the end and then back to parse the arguments)
>   (This ls less/not of an issue for lambda and small functions)
>
>
> My conclusion:
> I really think an option should provide a consistent break but I'm really
> not sure it should be a new option.
> If I manage to convince you through the examples, that formatting all
> function consistently will actually improve overall readability more
> generally, I think AlwaysBreak is just fine as it was.
> I'm happy to help with coding or writing tests for whatever decision you
> make.
>
>
> Examples:
> I've pasted / attached the code examples that I saw, some many many times
> (with .clang-format file).
> You'll be able to see how before things were more consistent and now
> things are moved to unexpected places depending on the call.
> Moreover the benefit is very limited for us, because gaining 1 line does
> not seem to add to our readability, and the indentation saved (most often 1
> (4 spaces)) does not lead to better or different arguments formatting in
> most cases. (less than 10 where arguments where improved in the hundreds of
> cases I've looked at).
>
>
> Methodology:
> I wanted to make sure that I really understood the problem before coming
> back to you:
> - I've done a full reformat of 2 of our projects first with snapshot
> r260967, then with snapshot r264047 (with the new change).
>   That is few thousands of cpp/h files, and about 10% were modified when
> running the updated format.
> - I spent more hours than I should have yesterday just scrolling through
> 

Re: [PATCH] D18498: Auto-install Clang Visual Studio visualizers for VS2015 and up

[Alexander Riccio via cfe-commits]

ariccio added inline comments.


Comment at: utils/ClangVisualizers/CMakeLists.txt:3
@@ +2,3 @@
+# tries to create a corresponding executable, which we don't want.
+if (LLVM_ADD_NATIVE_VISUALIZERS_TO_SOLUTION)
+  set(CLANG_VISUALIZERS clang.natvis)

Hmm, that's gonna bug me. Maybe I'll just have to proofread //all// of them.


Comment at: utils/ClangVisualizers/clang.natvis:9
@@ -8,2 +8,3 @@
+For later versions of Visual Studio, no setup is required-->
 http://schemas.microsoft.com/vstudio/debugger/natvis/2010;>
 

Ahh, that's actually quite smart.


http://reviews.llvm.org/D18498



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

Re: [PATCH] D17438: [OpenCL] Add Sema checks for atomics and implicit declaration

[Xiuli PAN via cfe-commits]

pxli168 added a comment.

Hi Anastasia,
https://cvs.khronos.org/bugzilla/show_bug.cgi?id=15603
Now we got clarify from khronos. I will continue on this patch.
BTW, https://cvs.khronos.org/bugzilla/show_bug.cgi?id=15599 is also fixed in 
the same revision. 
Thanks
Xiuli


http://reviews.llvm.org/D17438



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