Re: [PATCH] D16215: ASTMatchers: enable hasBody() matcher for FunctionDecls

2016-01-20 Thread Aleksei Sidorin via cfe-commits
a.sidorin updated this revision to Diff 45360.
a.sidorin added a comment.

Replace NULL with nullptr.


http://reviews.llvm.org/D16215

Files:
  docs/LibASTMatchersReference.html
  include/clang/ASTMatchers/ASTMatchers.h
  include/clang/ASTMatchers/ASTMatchersInternal.h
  unittests/ASTMatchers/ASTMatchersTest.cpp
  unittests/ASTMatchers/Dynamic/ParserTest.cpp

Index: unittests/ASTMatchers/Dynamic/ParserTest.cpp
===
--- unittests/ASTMatchers/Dynamic/ParserTest.cpp
+++ unittests/ASTMatchers/Dynamic/ParserTest.cpp
@@ -263,7 +263,7 @@
 "1:1: Matcher does not support binding.",
 ParseWithError("isArrow().bind(\"foo\")"));
   EXPECT_EQ("Input value has unresolved overloaded type: "
-"Matcher",
+"Matcher",
 ParseMatcherWithError("hasBody(stmt())"));
 }
 
Index: unittests/ASTMatchers/ASTMatchersTest.cpp
===
--- unittests/ASTMatchers/ASTMatchersTest.cpp
+++ unittests/ASTMatchers/ASTMatchersTest.cpp
@@ -2869,6 +2869,10 @@
   doStmt(hasBody(compoundStmt();
   EXPECT_TRUE(matches("void f() { int p[2]; for (auto x : p) {} }",
   cxxForRangeStmt(hasBody(compoundStmt();
+  EXPECT_TRUE(matches("void f() {}", functionDecl(hasBody(compoundStmt();
+  EXPECT_TRUE(notMatches("void f();", functionDecl(hasBody(compoundStmt();
+  EXPECT_TRUE(matches("void f(); void f() {}",
+ functionDecl(hasBody(compoundStmt();
 }
 
 TEST(HasAnySubstatement, MatchesForTopLevelCompoundStatement) {
Index: include/clang/ASTMatchers/ASTMatchersInternal.h
===
--- include/clang/ASTMatchers/ASTMatchersInternal.h
+++ include/clang/ASTMatchers/ASTMatchersInternal.h
@@ -1584,6 +1584,18 @@
   ast_type_traits::DynTypedNode Node;
 };
 
+template 
+struct GetBodyMatcher {
+  static const Stmt *get(const Ty &Node) {
+return Node.getBody();
+  }
+};
+
+template <>
+inline const Stmt *GetBodyMatcher::get(const FunctionDecl &Node) {
+  return Node.doesThisDeclarationHaveABody() ? Node.getBody() : nullptr;
+}
+
 } // end namespace internal
 } // end namespace ast_matchers
 } // end namespace clang
Index: include/clang/ASTMatchers/ASTMatchers.h
===
--- include/clang/ASTMatchers/ASTMatchers.h
+++ include/clang/ASTMatchers/ASTMatchers.h
@@ -3114,8 +3114,8 @@
   return false;
 }
 
-/// \brief Matches a 'for', 'while', or 'do while' statement that has
-/// a given body.
+/// \brief Matches a 'for', 'while', 'do while' statement or a function
+/// definition that has a given body.
 ///
 /// Given
 /// \code
@@ -3128,9 +3128,10 @@
 AST_POLYMORPHIC_MATCHER_P(hasBody,
   AST_POLYMORPHIC_SUPPORTED_TYPES(DoStmt, ForStmt,
   WhileStmt,
-  CXXForRangeStmt),
+  CXXForRangeStmt,
+  FunctionDecl),
   internal::Matcher, InnerMatcher) {
-  const Stmt *const Statement = Node.getBody();
+  const Stmt *const Statement = internal::GetBodyMatcher::get(Node);
   return (Statement != nullptr &&
   InnerMatcher.matches(*Statement, Finder, Builder));
 }
Index: docs/LibASTMatchersReference.html
===
--- docs/LibASTMatchersReference.html
+++ docs/LibASTMatchersReference.html
@@ -3400,8 +3400,8 @@
 
 
 MatcherCXXForRangeStmt>hasBodyMatcherStmt> InnerMatcher
-Matches a 'for', 'while', or 'do while' statement that has
-a given body.
+Matches a 'for', 'while', 'do while' statement or a function
+definition that has a given body.
 
 Given
   for (;;) {}
@@ -3825,8 +3825,8 @@
 
 
 MatcherDoStmt>hasBodyMatcherStmt> InnerMatcher
-Matches a 'for', 'while', or 'do while' statement that has
-a given body.
+Matches a 'for', 'while', 'do while' statement or a function
+definition that has a given body.
 
 Given
   for (;;) {}
@@ -4006,8 +4006,8 @@
 
 
 MatcherForStmt>hasBodyMatcherStmt> InnerMatcher
-Matches a 'for', 'while', or 'do while' statement that has
-a given body.
+Matches a 'for', 'while', 'do while' statement or a function
+definition that has a given body.
 
 Given
   for (;;) {}
@@ -4061,6 +4061,19 @@
 
 
 
+MatcherFunctionDecl>hasBodyMatcher

Re: [libcxx] Reinstate and fix overload sets to be const-correct wherever possible

2016-01-20 Thread Eric Fiselier via cfe-commits
The direction and change LGTM. Feel free to commit once the change has some
tests.

On Fri, Jan 8, 2016 at 5:45 PM, Duncan P. N. Exon Smith <
dexonsm...@apple.com> wrote:

> No one is waiting for me on this, are they?  FWIW, this seems like
> a good solution to me.  I'll see what I can do internally (I filed
> a radar), but other platforms will likely need this anyway.
>
> > On 2016-Jan-08, at 16:06, Richard Smith  wrote:
> >
> > Ping, is this OK to commit?
> >
> > On Thu, Dec 10, 2015 at 3:32 PM, Richard Smith 
> wrote:
> > On Thu, Dec 10, 2015 at 11:45 AM, Marshall Clow 
> wrote:
> > On Tue, Dec 8, 2015 at 3:52 PM, Richard Smith 
> wrote:
> > Ping.
> >
> > Sorry about that.
> > Completely missed this in my email flood.
> >
> > This approach looks ok to me, but I wonder if it would be better to get
> Apple to fix their iOS C library instead.
> >
> > Well, it's not broken in the sense that it does what the C standard
> library is supposed to do. But it's not providing the "C pieces" of a C++
> standard library. I don't know what its design goal is here, but with this
> patch we don't need to care.
> >
> > Duncan offered to file a bug on this, but I don't know if that's
> happened.
> >
> > Are there other broken C libraries that we are concerned with?
> >
> > Probably :) I don't know the complete set of C standard library
> implementations that people use with libc++, but I'd be surprised if Darwin
> were the only case we need to fix.
> >
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r258299 - [OPENMP 4.5] Allow to use non-static data members in non-static member functions in 'private' clause.

2016-01-20 Thread Alexey Bataev via cfe-commits
Author: abataev
Date: Wed Jan 20 03:07:54 2016
New Revision: 258299

URL: http://llvm.org/viewvc/llvm-project?rev=258299&view=rev
Log:
[OPENMP 4.5] Allow to use non-static data members in non-static member 
functions in 'private' clause.
OpenMP 4.5 allows to use non-static members of current class in non-static 
member functions in 'private' clause. Patch adds initial support for 
privatizing data members.

Modified:
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/include/clang/Sema/Sema.h
cfe/trunk/lib/Sema/SemaExpr.cpp
cfe/trunk/lib/Sema/SemaOpenMP.cpp
cfe/trunk/test/OpenMP/distribute_ast_print.cpp
cfe/trunk/test/OpenMP/for_ast_print.cpp
cfe/trunk/test/OpenMP/for_private_messages.cpp
cfe/trunk/test/OpenMP/for_simd_ast_print.cpp
cfe/trunk/test/OpenMP/for_simd_private_messages.cpp
cfe/trunk/test/OpenMP/parallel_ast_print.cpp
cfe/trunk/test/OpenMP/parallel_for_ast_print.cpp
cfe/trunk/test/OpenMP/parallel_for_private_messages.cpp
cfe/trunk/test/OpenMP/parallel_for_simd_ast_print.cpp
cfe/trunk/test/OpenMP/parallel_for_simd_private_messages.cpp
cfe/trunk/test/OpenMP/parallel_sections_private_messages.cpp
cfe/trunk/test/OpenMP/sections_private_messages.cpp
cfe/trunk/test/OpenMP/simd_private_messages.cpp
cfe/trunk/test/OpenMP/single_private_messages.cpp
cfe/trunk/test/OpenMP/target_private_messages.cpp
cfe/trunk/test/OpenMP/task_ast_print.cpp
cfe/trunk/test/OpenMP/taskloop_private_messages.cpp
cfe/trunk/test/OpenMP/taskloop_simd_private_messages.cpp

Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=258299&r1=258298&r2=258299&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Wed Jan 20 03:07:54 
2016
@@ -7710,10 +7710,10 @@ def err_omp_reduction_incomplete_type :
   "a reduction list item with incomplete type %0">;
 def err_omp_unexpected_clause_value : Error<
   "expected %0 in OpenMP clause '%1'">;
-def err_omp_expected_var_name : Error<
-  "expected variable name">;
-def err_omp_expected_var_name_or_array_item : Error<
-  "expected variable name, array element or array section">;
+def err_omp_expected_var_name_member_expr : Error<
+  "expected variable name%select{| or data member of current class}0">;
+def err_omp_expected_var_name_member_expr_or_array_item : Error<
+  "expected variable name%select{|, data member of current class}0, array 
element or array section">;
 def note_omp_task_predetermined_firstprivate_here : Note<
   "predetermined as a firstprivate in a task construct here">;
 def err_omp_threadprivate_incomplete_type : Error<

Modified: cfe/trunk/include/clang/Sema/Sema.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=258299&r1=258298&r2=258299&view=diff
==
--- cfe/trunk/include/clang/Sema/Sema.h (original)
+++ cfe/trunk/include/clang/Sema/Sema.h Wed Jan 20 03:07:54 2016
@@ -7778,23 +7778,23 @@ public:
   /// \brief Return true if the provided declaration \a VD should be captured 
by
   /// reference in the provided scope \a RSI. This will take into account the
   /// semantics of the directive and associated clauses.
-  bool IsOpenMPCapturedByRef(VarDecl *VD,
+  bool IsOpenMPCapturedByRef(ValueDecl *D,
  const sema::CapturedRegionScopeInfo *RSI);
 
   /// \brief Check if the specified variable is used in one of the private
   /// clauses (private, firstprivate, lastprivate, reduction etc.) in OpenMP
   /// constructs.
-  bool IsOpenMPCapturedVar(VarDecl *VD);
+  bool IsOpenMPCapturedDecl(ValueDecl *D);
 
   /// \brief Check if the specified variable is used in 'private' clause.
   /// \param Level Relative level of nested OpenMP construct for that the check
   /// is performed.
-  bool isOpenMPPrivateVar(VarDecl *VD, unsigned Level);
+  bool isOpenMPPrivateDecl(ValueDecl *D, unsigned Level);
 
   /// \brief Check if the specified variable is captured  by 'target' 
directive.
   /// \param Level Relative level of nested OpenMP construct for that the check
   /// is performed.
-  bool isOpenMPTargetCapturedVar(VarDecl *VD, unsigned Level);
+  bool isOpenMPTargetCapturedDecl(ValueDecl *D, unsigned Level);
 
   ExprResult PerformOpenMPImplicitIntegerConversion(SourceLocation OpLoc,
 Expr *Op);
@@ -7854,19 +7854,19 @@ public:
   StmtResult ActOnOpenMPSimdDirective(
   ArrayRef Clauses, Stmt *AStmt, SourceLocation StartLoc,
   SourceLocation EndLoc,
-  llvm::DenseMap &VarsWithImplicitDSA);
+  llvm::DenseMap &VarsWithImplicitDSA);
   /// \brief Called on well-formed '\#pragma omp for' after parsing
   /// of the associated st

Re: [PATCH] D16006: [libcxxabi] Teach cxa_demangle about Hexagon's long double size

2016-01-20 Thread Eric Fiselier via cfe-commits
EricWF added a subscriber: EricWF.
EricWF accepted this revision.
EricWF added a reviewer: EricWF.
EricWF added a comment.
This revision is now accepted and ready to land.

LGTM.


http://reviews.llvm.org/D16006



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


Re: [PATCH] D16007: [libcxxabi] Make test tolerant of uncommon floating literal demanglings

2016-01-20 Thread Eric Fiselier via cfe-commits
EricWF accepted this revision.
EricWF added a comment.
This revision is now accepted and ready to land.

LGTM.

I don't see anything in the Itanium ABI spec that would prefer one demangling 
over another.
I also double checked that `scanf("%a",  ...)` generates the expected 
bit-pattern for each test value.

Thanks for the patch.


http://reviews.llvm.org/D16007



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


r258307 - [OPENMP 4.0] Fix for codegen of 'cancel' directive within 'sections' directive.

2016-01-20 Thread Alexey Bataev via cfe-commits
Author: abataev
Date: Wed Jan 20 06:29:47 2016
New Revision: 258307

URL: http://llvm.org/viewvc/llvm-project?rev=258307&view=rev
Log:
[OPENMP 4.0] Fix for codegen of 'cancel' directive within 'sections' directive.
Allow to emit code for 'cancel' directive within 'sections' directive with 
single sub-section.

Modified:
cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp
cfe/trunk/test/OpenMP/cancel_codegen.cpp

Modified: cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp?rev=258307&r1=258306&r2=258307&view=diff
==
--- cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp Wed Jan 20 06:29:47 2016
@@ -3685,8 +3685,6 @@ void CGOpenMPRuntime::emitCancelCall(Cod
   // kmp_int32 cncl_kind);
   if (auto *OMPRegionInfo =
   dyn_cast_or_null(CGF.CapturedStmtInfo)) {
-if (OMPRegionInfo->getDirectiveKind() == OMPD_single)
-  return;
 auto &&ThenGen = [this, Loc, CancelRegion,
   OMPRegionInfo](CodeGenFunction &CGF) {
   llvm::Value *Args[] = {

Modified: cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp?rev=258307&r1=258306&r2=258307&view=diff
==
--- cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp Wed Jan 20 06:29:47 2016
@@ -1786,7 +1786,11 @@ CodeGenFunction::EmitSections(const OMPE
 CGF.EmitOMPPrivateClause(S, SingleScope);
 (void)SingleScope.Privatize();
 
+auto Exit = CGF.getJumpDestInCurrentScope("omp.sections.exit");
+CGF.BreakContinueStack.push_back(BreakContinue(Exit, Exit));
 CGF.EmitStmt(Stmt);
+CGF.EmitBlock(Exit.getBlock());
+CGF.BreakContinueStack.pop_back();
   };
   CGM.getOpenMPRuntime().emitSingleRegion(*this, CodeGen, S.getLocStart(),
   llvm::None, llvm::None, llvm::None,
@@ -2647,7 +2651,8 @@ CodeGenFunction::getOMPCancelDestination
   if (Kind == OMPD_parallel || Kind == OMPD_task)
 return ReturnBlock;
   assert(Kind == OMPD_for || Kind == OMPD_section || Kind == OMPD_sections ||
- Kind == OMPD_parallel_sections || Kind == OMPD_parallel_for);
+ Kind == OMPD_parallel_sections || Kind == OMPD_parallel_for ||
+ Kind == OMPD_single);
   return BreakContinueStack.back().BreakBlock;
 }
 

Modified: cfe/trunk/test/OpenMP/cancel_codegen.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/OpenMP/cancel_codegen.cpp?rev=258307&r1=258306&r2=258307&view=diff
==
--- cfe/trunk/test/OpenMP/cancel_codegen.cpp (original)
+++ cfe/trunk/test/OpenMP/cancel_codegen.cpp Wed Jan 20 06:29:47 2016
@@ -20,7 +20,7 @@ int main (int argc, char **argv) {
 #pragma omp cancel sections
 }
 // CHECK: call i32 @__kmpc_single(
-// CHECK-NOT: @__kmpc_cancel
+// CHECK: call i32 @__kmpc_cancel(
 // CHECK: call void @__kmpc_end_single(
 // CHECK: call void @__kmpc_barrier(%ident_t*
 #pragma omp sections
@@ -126,7 +126,7 @@ for (int i = 0; i < argc; ++i) {
 
 // CHECK: define internal void @{{[^(]+}}(i32* {{[^,]+}}, i32* {{[^,]+}})
 // CHECK: call i32 @__kmpc_single(
-// CHECK-NOT: @__kmpc_cancel
+// CHECK: call i32 @__kmpc_cancel(
 // CHECK: call void @__kmpc_end_single(
 // CHECK: ret void
 


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


[PATCH] D16352: Fix printing of C style casts with suppressed specifiers

2016-01-20 Thread Nick Sumner via cfe-commits
nick.sumner created this revision.
nick.sumner added reviewers: bkramer, rsmith.
nick.sumner added a subscriber: cfe-commits.

Allow C style casts to be printed correctly even when the incoming
PrintingPolicy suppresses specifiers. This can happen, for instance,
when casts occur during the initialization of variables inside a
DeclGroup. Given the code:
void foo() {
  int *x = ((void *)0), *y = ((void *)0);
}

The casts are printed as:
int *x = ((void *)0), *y = ((*)0);

Note that the second cast lacks 'void' because specifiers are
suppressed when printing members of the declgroup (after the first).

With the patch, the casts are printed as:
int *x = ((void *)0), *y = ((void *)0);

http://reviews.llvm.org/D16352

Files:
  lib/AST/StmtPrinter.cpp
  test/Sema/ast-print.c

Index: test/Sema/ast-print.c
===
--- test/Sema/ast-print.c
+++ test/Sema/ast-print.c
@@ -53,3 +53,8 @@
 
 // CHECK: struct pair_t p = {a: 3, .b = 4};
 struct pair_t p = {a: 3, .b = 4};
+
+void cast() {
+// CHECK: int *x = ((void *)0), *y = ((void *)0);
+  int *x = ((void *)0), *y = ((void *)0);
+}
Index: lib/AST/StmtPrinter.cpp
===
--- lib/AST/StmtPrinter.cpp
+++ lib/AST/StmtPrinter.cpp
@@ -1476,7 +1476,9 @@
 }
 void StmtPrinter::VisitCStyleCastExpr(CStyleCastExpr *Node) {
   OS << '(';
-  Node->getTypeAsWritten().print(OS, Policy);
+  PrintingPolicy SubPolicy(Policy);
+  SubPolicy.SuppressSpecifiers = false;
+  Node->getTypeAsWritten().print(OS, SubPolicy);
   OS << ')';
   PrintExpr(Node->getSubExpr());
 }


Index: test/Sema/ast-print.c
===
--- test/Sema/ast-print.c
+++ test/Sema/ast-print.c
@@ -53,3 +53,8 @@
 
 // CHECK: struct pair_t p = {a: 3, .b = 4};
 struct pair_t p = {a: 3, .b = 4};
+
+void cast() {
+// CHECK: int *x = ((void *)0), *y = ((void *)0);
+  int *x = ((void *)0), *y = ((void *)0);
+}
Index: lib/AST/StmtPrinter.cpp
===
--- lib/AST/StmtPrinter.cpp
+++ lib/AST/StmtPrinter.cpp
@@ -1476,7 +1476,9 @@
 }
 void StmtPrinter::VisitCStyleCastExpr(CStyleCastExpr *Node) {
   OS << '(';
-  Node->getTypeAsWritten().print(OS, Policy);
+  PrintingPolicy SubPolicy(Policy);
+  SubPolicy.SuppressSpecifiers = false;
+  Node->getTypeAsWritten().print(OS, SubPolicy);
   OS << ')';
   PrintExpr(Node->getSubExpr());
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [libcxx] r249798 - Split out of .

2016-01-20 Thread Nico Weber via cfe-commits
Eric, Marshall: another ping. This should be fixed on the 3.8 branch, so it
needs to be resolved soon.
On Jan 5, 2016 5:25 PM, "Nico Weber"  wrote:

> On Wed, Dec 30, 2015 at 8:28 PM, Richard Smith 
> wrote:
>
>> On Wed, Dec 30, 2015 at 1:17 PM, Nico Weber  wrote:
>>
>>> One problem with this patch: stdio.h can be used in .c files, and when
>>> building .c files with -gnu99 -pedantic,
>>>
>>
>> Do you mean -std=gnu89?
>>
>>
>>> clang will complain about // comments. Not only does this stdio.h have
>>> // comments, it also pulls in some libc++ headers (__config) that have //
>>> comments as well. I suppose all the comments in header files pulled in by C
>>> headers need to become /* */ comments?
>>>
>>
>> I suppose so too. Your configuration is probably somewhat broken if
>> libc++'s headers are in your include path while building C code, but it
>> doesn't seem unreasonable to properly support that mode, and my changes
>> were already trying to do so.
>>
>> Eric, Marshall, what do you think about using only /*...*/-style comments
>> in these headers, to handle the case where libc++ is somehow in the include
>> path for a C89 compilation?
>>
>
> Eric, Marshall: Ping ^
>
>
>>
>>
>>> On Tue, Oct 13, 2015 at 7:34 PM, Richard Smith via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
 On Tue, Oct 13, 2015 at 3:26 PM, Eric Fiselier  wrote:

> This change LGTM. Let's hold off on the using "_Static_assert" until
> we understand how that would work with "-pedantic" when the macro is
> expanded in user code.
>

 Committed as r250247, thanks.


> /Eric
>
> On Tue, Oct 13, 2015 at 4:19 PM, Richard Smith 
> wrote:
>
>> On Tue, Oct 13, 2015 at 2:12 PM, Eric Fiselier via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> I would rather not do this if possible but I understand why we need
>>> to do it.
>>>
>>> Richard is there a cost associated with the 'extern "C++"'
>>> construct? or by forcing the compiler to switch modes in general?
>>>
>>
>> Not a significant one compared to the cost of the code wrapped in the
>> 'extern "C++"' here. (Also, this is wrapped in an #ifdef that only 
>> applies
>> in C++98; we could further reduce the set of cases when this happens by
>> using _Static_assert when available instead of this static_assert
>> emulation.)
>>
>>
>>> On Mon, Oct 12, 2015 at 12:27 PM, Richard Smith <
>>> rich...@metafoo.co.uk> wrote:
>>>
 On Mon, Oct 12, 2015 at 9:41 AM, Steven Wu via cfe-commits <
 cfe-commits@lists.llvm.org> wrote:

> Hi Richard
>
> Your splitting seems causing problem when using extern "C". Here
> is a test case:
>
> $ cat test.cpp
> #ifdef __cplusplus
> extern "C" {
> #endif
> #include 
> #ifdef __cplusplus
> }
> #endif
>
> Error:
> clang -fsyntax-only test.cpp
> In file included from test.cpp:4:
> In file included from /usr/bin/../include/c++/v1/stdio.h:102:
> /usr/bin/../include/c++/v1/__config:593:1: error:
>   templates must have C++ linkage
> template  struct __static_assert_test;
> ^~~
> /usr/bin/../include/c++/v1/__config:594:20: error:
>   explicit specialization of non-template struct
> '__static_assert_test'
> template <> struct __static_assert_test {};
>^   ~~
> /usr/bin/../include/c++/v1/__config:595:1: error:
>   templates must have C++ linkage
> template  struct __static_assert_check {};
> ^~~
> 3 errors generated.
>
> Because the code is actually compiled in C++, the guard in the
> header failed to exclude the templates. In the meantime, I don't know 
> if
> there are ways to detect the header is in extern "C".
>

 This was supposed to work, but apparently I only tested it when
 compiling as C++11; the static_assert emulation in C++98 mode needs 
 some
 massaging to cope with this.

 Eric, Marshall: Are you OK with the attached patch? The idea is to
 make <__config> be fine to include in extern "C" or extern "C++" modes 
 (and
 likewise for the  headers). This is something that comes up 
 pretty
 often in practice (people wrap an include of a C header in 'extern 
 "C"',
 and that C header includes a  file that libc++ provides).


> Steven
>
>
> > On Oct 8, 2015, at 6:29 PM, Richard Smith via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
> >
> > Author: rsmith
> > Date: Thu Oct  8 20:29:09 2015
> > New Revision: 249798
>

Re: [PATCH] D16310: new clang-tidy checker misc-long-cast

2016-01-20 Thread Daniel Marjamäki via cfe-commits
danielmarjamaki added a comment.

In http://reviews.llvm.org/D16310#330367, @LegalizeAdulthood wrote:

> Why not supply a fixit that removes the cast?


I am skeptic. There are different valid fixes.

Example code:

  l = (long)(a*1000);

Fix1:

  l = ((long)a * 1000);

Fix2:

  l = (a * (long)1000);

Fix3:

  l = (a * 1000L);


Repository:
  rL LLVM

http://reviews.llvm.org/D16310



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


Re: [PATCH] D16310: new clang-tidy checker misc-long-cast

2016-01-20 Thread Daniel Marjamäki via cfe-commits
danielmarjamaki removed rL LLVM as the repository for this revision.
danielmarjamaki updated this revision to Diff 45378.
danielmarjamaki added a comment.

Fixed review comment; s/checker/check/


http://reviews.llvm.org/D16310

Files:
  clang-tidy/misc/CMakeLists.txt
  clang-tidy/misc/LongCastCheck.cpp
  clang-tidy/misc/LongCastCheck.h
  clang-tidy/misc/MiscTidyModule.cpp
  docs/clang-tidy/checks/list.rst
  docs/clang-tidy/checks/misc-long-cast.rst
  test/clang-tidy/misc-long-cast.cpp

Index: test/clang-tidy/misc-long-cast.cpp
===
--- test/clang-tidy/misc-long-cast.cpp
+++ test/clang-tidy/misc-long-cast.cpp
@@ -0,0 +1,48 @@
+// RUN: %check_clang_tidy %s misc-long-cast %t
+
+void assign(int a, int b) {
+  long l;
+
+  l = a * b;
+  l = (long)(a * b);
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: either cast from 'int' to 'long' is ineffective, or there is loss of precision before the conversion
+  l = (long)a * b;
+
+  l = (long)(a << 8);
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: either cast from 'int' to 'long'
+  l = (long)b << 8;
+}
+
+void init(unsigned int n) {
+  long l = (long)(n << 8);
+  // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: either cast from 'int' to 'long'
+}
+
+long ret(int a) {
+  return (long)(a * 1000);
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: either cast from 'int' to 'long'
+}
+
+void dontwarn1(unsigned char a, int i, unsigned char *p) {
+  long l;
+  // the result is a 9 bit value, there is no truncation in the implicit cast
+  l = (long)(a + 15);
+  // the result is a 12 bit value, there is no truncation in the implicit cast
+  l = (long)(a << 4);
+  // the result is a 3 bit value, there is no truncation in the implicit cast
+  l = (long)((i%5)+1);
+  // the result is a 16 bit value, there is no truncation in the implicit cast
+  l = (long)(((*p)<<8) + *(p+1));
+}
+
+// Cast is not suspicious when casting macro
+#define A  (X<<2)
+long macro1(int X) {
+  return (long)A;
+}
+
+// Don't warn about cast in macro
+#define B(X,Y)   (long)(X*Y)
+long macro2(int x, int y) {
+  return B(x,y);
+}
Index: docs/clang-tidy/checks/misc-long-cast.rst
===
--- docs/clang-tidy/checks/misc-long-cast.rst
+++ docs/clang-tidy/checks/misc-long-cast.rst
@@ -0,0 +1,29 @@
+.. title:: clang-tidy - misc-long-cast
+
+misc-long-cast
+==
+
+This check will warn when there is a explicit redundant cast of a calculation
+result to a bigger type. If the intention of the cast is to avoid loss of
+precision then the cast is misplaced, and there can be loss of precision.
+Otherwise the cast is ineffective.
+
+Example code::
+
+long f(int x) {
+return (long)(x*1000);
+}
+
+The result x*1000 is first calculated using int precision. If the result
+exceeds int precision there is loss of precision. Then the result is casted to
+long.
+
+If there is no loss of precision then the cast can be removed or you can
+explicitly cast to int instead.
+
+If you want to avoid loss of precision then put the cast in a proper location,
+for instance::
+
+long f(int x) {
+return (long)x * 1000;
+}
Index: docs/clang-tidy/checks/list.rst
===
--- docs/clang-tidy/checks/list.rst
+++ docs/clang-tidy/checks/list.rst
@@ -49,6 +49,7 @@
misc-definitions-in-headers
misc-inaccurate-erase
misc-inefficient-algorithm
+   misc-long-cast
misc-macro-parentheses
misc-macro-repeated-side-effects
misc-move-constructor-init
Index: clang-tidy/misc/MiscTidyModule.cpp
===
--- clang-tidy/misc/MiscTidyModule.cpp
+++ clang-tidy/misc/MiscTidyModule.cpp
@@ -17,6 +17,7 @@
 #include "DefinitionsInHeadersCheck.h"
 #include "InaccurateEraseCheck.h"
 #include "InefficientAlgorithmCheck.h"
+#include "LongCastCheck.h"
 #include "MacroParenthesesCheck.h"
 #include "MacroRepeatedSideEffectsCheck.h"
 #include "MoveConstantArgumentCheck.h"
@@ -56,6 +57,8 @@
 "misc-inaccurate-erase");
 CheckFactories.registerCheck(
 "misc-inefficient-algorithm");
+CheckFactories.registerCheck(
+"misc-long-cast");
 CheckFactories.registerCheck(
 "misc-macro-parentheses");
 CheckFactories.registerCheck(
Index: clang-tidy/misc/LongCastCheck.h
===
--- clang-tidy/misc/LongCastCheck.h
+++ clang-tidy/misc/LongCastCheck.h
@@ -0,0 +1,33 @@
+//===--- LongCastCheck.h - clang-tidy*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_MISC_LONG_CAST_H
+#define LLVM_CLANG_TO

Re: [PATCH] D16310: new clang-tidy checker misc-long-cast

2016-01-20 Thread Daniel Marjamäki via cfe-commits
danielmarjamaki marked an inline comment as done.
danielmarjamaki added a comment.

http://reviews.llvm.org/D16310



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


Re: [PATCH] D16310: new clang-tidy checker misc-long-cast

2016-01-20 Thread Daniel Marjamäki via cfe-commits
danielmarjamaki added a comment.

In http://reviews.llvm.org/D16310#330312, @Eugene.Zelenko wrote:

> Clang-tidy has 6 cast related checks. May be this is good time to introduce 
> dedicated category for them?


I am not against this.

I don't know which ones you are thinking about.. but if a check is not in the 
misc category now then it should probably not be moved.

I can do this.. but I would prefer to do it separately. If there is agreement 
that this should be done I can create a new revision that move the cast checks. 
I suggest that is done before this long-cast checker is committed.


http://reviews.llvm.org/D16310



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


[libcxxabi] r258311 - [libcxxabi] Make test tolerant of uncommon floating literal demanglings

2016-01-20 Thread Ben Craig via cfe-commits
Author: bcraig
Date: Wed Jan 20 08:03:27 2016
New Revision: 258311

URL: http://llvm.org/viewvc/llvm-project?rev=258311&view=rev
Log:
[libcxxabi] Make test tolerant of uncommon floating literal demanglings

libcxxabi uses the C99 library's %a format specifier to turn a floating
point value into a hexadecimal string representation. The %a format
specifier is rather loosely defined in the C spec though, and some C
libraries emit a different (but valid) string for a given floating
point value. In particular, the C spec only requires that there is a
single, non-zero hexadecimal digit on the left of the decimal point.
Given that constraint, there are typically four different valid 
representations of a floating point number. I have updated the test to
accept any of the valid representations for demangled floating
point literals.

Modified:
libcxxabi/trunk/test/test_demangle.pass.cpp

Modified: libcxxabi/trunk/test/test_demangle.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxxabi/trunk/test/test_demangle.pass.cpp?rev=258311&r1=258310&r2=258311&view=diff
==
--- libcxxabi/trunk/test/test_demangle.pass.cpp (original)
+++ libcxxabi/trunk/test/test_demangle.pass.cpp Wed Jan 20 08:03:27 2016
@@ -29516,11 +29516,6 @@ const char* cases[][2] =
 {"_ZN6PR58615AllocIcNS_6PolicyINS_1PELb18allocateEiPKv", 
"PR5861::Alloc >::allocate(int, void 
const*)"},
 {"_ZN5test01fIdEEvT_RAszcl3ovlcvS1__EE_c", "void test0::f(double, 
char (&) [sizeof (ovl((double)()))])"},
 {"_ZN5test01fIiEEvT_RAszcl3ovlcvS1__EE_c", "void test0::f(int, char 
(&) [sizeof (ovl((int)()))])"},
-{"_ZN5test01gIfEEvRAszplcvT__ELf40a0E_c", "void test0::g(char 
(&) [sizeof (((float)()) + (0x1.4p+2f))])"},
-{"_ZN5test01hIfEEvRAszplcvT__ELd4014E_c", "void 
test0::h(char (&) [sizeof (((float)()) + (0x1.4p+2))])"},
-#if LDBL_FP80
-{"_ZN5test01hIfEEvRAcvjplstT_Le4001a000E_c", "void 
test0::h(char (&) [(unsigned int)((sizeof (float)) + (0xap-1L))])"},
-#endif
 {"_ZN5test01jINS_1AEEEvRAszdtcvT__E6buffer_c", "void 
test0::j(char (&) [sizeof ((test0::A)().buffer)])"},
 {"_ZN5test11fINS_1XEiEEvT_IT0_E", "void test1::f(test1::X)"},
 {"_ZN5test211read_memberINS_1AEEEDtptcvPT_Li0E6memberERS2_", 
"decltype((test2::A*)(0)->member) test2::read_member(test2::A&)"},
@@ -29600,6 +29595,37 @@ const char* cases[][2] =
 
 const unsigned N = sizeof(cases) / sizeof(cases[0]);
 
+struct FPLiteralCase {
+const char *mangled;
+// There are four possible demanglings of a given float.
+std::string expecting[4];
+} fp_literal_cases[] =
+{
+{"_ZN5test01gIfEEvRAszplcvT__ELf40a0E_c", {
+"void test0::g(char (&) [sizeof (((float)()) + (0x1.4p+2f))])",
+"void test0::g(char (&) [sizeof (((float)()) + (0x2.8p+1f))])",
+"void test0::g(char (&) [sizeof (((float)()) + (0x5p+0f))])",
+"void test0::g(char (&) [sizeof (((float)()) + (0xap-1f))])",
+}},
+{"_ZN5test01hIfEEvRAszplcvT__ELd4014E_c", {
+"void test0::h(char (&) [sizeof (((float)()) + (0x1.4p+2))])",
+"void test0::h(char (&) [sizeof (((float)()) + (0x2.8p+1))])",
+"void test0::h(char (&) [sizeof (((float)()) + (0x5p+0))])",
+"void test0::h(char (&) [sizeof (((float)()) + (0xap-1))])",
+}},
+#if LDBL_FP80
+{"_ZN5test01hIfEEvRAcvjplstT_Le4001a000E_c", {
+"void test0::h(char (&) [(unsigned int)((sizeof (float)) + 
(0x1.4p+2L))])",
+"void test0::h(char (&) [(unsigned int)((sizeof (float)) + 
(0x2.8p+1L))])",
+"void test0::h(char (&) [(unsigned int)((sizeof (float)) + 
(0x5p+0L))])",
+"void test0::h(char (&) [(unsigned int)((sizeof (float)) + 
(0xap-1L))])",
+}},
+#endif
+};
+const unsigned NF = sizeof(fp_literal_cases) / sizeof(fp_literal_cases[0]);
+const unsigned NEF = sizeof(fp_literal_cases[0].expecting) / 
sizeof(fp_literal_cases[0].expecting[0]);
+
+
 const char* invalid_cases[] =
 {
 "_ZIPPreEncode",
@@ -29665,6 +29691,36 @@ void test2()
 free(buf);
 }
 
+void testFPLiterals()
+{
+std::size_t len = 0;
+char* buf = nullptr;
+for (unsigned i = 0; i < NF; ++i)
+{
+FPLiteralCase *fpCase = fp_literal_cases+i;
+int status;
+char* demang = __cxxabiv1::__cxa_demangle(fpCase->mangled, buf, &len, 
&status);
+if (demang == 0)
+{
+std::cout << fpCase->mangled << " -> " << fpCase->expecting[0] << 
'\n';
+std::cout << "Got instead: NULL, " << status << '\n';
+assert(false);
+continue;
+}
+std::string *e_beg = fpCase->expecting;
+std::string *e_end = fpCase->expecting + NEF;
+if (std::find(e_beg, e_end, demang) == e_end)
+{
+std::cout << fpCase->mangled << " -> " << fpCase->expecting[0] << 
'\n';
+std::cout << "Got instead: " << demang << '\n';
+assert(false);
+   

[libcxxabi] r258313 - [libcxxabi] Teach cxa_demangle about Hexagon's long double size

2016-01-20 Thread Ben Craig via cfe-commits
Author: bcraig
Date: Wed Jan 20 08:10:23 2016
New Revision: 258313

URL: http://llvm.org/viewvc/llvm-project?rev=258313&view=rev
Log:
[libcxxabi] Teach cxa_demangle about Hexagon's long double size

cxa_demangle's default size for a long double is 10 bytes. Hexagon
only has an 8 byte long double though.

Modified:
libcxxabi/trunk/src/cxa_demangle.cpp

Modified: libcxxabi/trunk/src/cxa_demangle.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxxabi/trunk/src/cxa_demangle.cpp?rev=258313&r1=258312&r2=258313&view=diff
==
--- libcxxabi/trunk/src/cxa_demangle.cpp (original)
+++ libcxxabi/trunk/src/cxa_demangle.cpp Wed Jan 20 08:10:23 2016
@@ -168,7 +168,7 @@ struct float_data
 #if defined(__mips__) && defined(__mips_n64) || defined(__aarch64__) || \
 defined(__wasm__)
 static const size_t mangled_size = 32;
-#elif defined(__arm__) || defined(__mips__)
+#elif defined(__arm__) || defined(__mips__) || defined(__hexagon__)
 static const size_t mangled_size = 16;
 #else
 static const size_t mangled_size = 20;  // May need to be adjusted to 16 
or 24 on other platforms


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


r258317 - Silencing several -Wcast-qual warnings; NFC.

2016-01-20 Thread Aaron Ballman via cfe-commits
Author: aaronballman
Date: Wed Jan 20 09:25:30 2016
New Revision: 258317

URL: http://llvm.org/viewvc/llvm-project?rev=258317&view=rev
Log:
Silencing several -Wcast-qual warnings; NFC.

Modified:
cfe/trunk/tools/libclang/CIndex.cpp

Modified: cfe/trunk/tools/libclang/CIndex.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/libclang/CIndex.cpp?rev=258317&r1=258316&r2=258317&view=diff
==
--- cfe/trunk/tools/libclang/CIndex.cpp (original)
+++ cfe/trunk/tools/libclang/CIndex.cpp Wed Jan 20 09:25:30 2016
@@ -3594,7 +3594,8 @@ CXEvalResult clang_Cursor_Evaluate(CXCur
   expr = Field->getInClassInitializer();
 }
 if (expr)
-  return (CXEvalResult)evaluateExpr((Expr *)expr, C);
+  return const_cast(reinterpret_cast(
+  evaluateExpr(const_cast(expr), C)));
 return nullptr;
   }
 
@@ -3607,7 +3608,8 @@ CXEvalResult clang_Cursor_Evaluate(CXCur
   }
 }
 if (expr)
-  return (CXEvalResult)evaluateExpr(expr, C);
+  return const_cast(
+  reinterpret_cast(evaluateExpr(expr, C)));
   }
   return nullptr;
 }


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


Re: [PATCH] D13126: New static analyzer checker for loss of sign/precision

2016-01-20 Thread Daniel Marjamäki via cfe-commits
danielmarjamaki marked 7 inline comments as done.
danielmarjamaki added a comment.

http://reviews.llvm.org/D13126



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


r258321 - Add AST matcher for paren expressions.

2016-01-20 Thread Aaron Ballman via cfe-commits
Author: aaronballman
Date: Wed Jan 20 10:17:39 2016
New Revision: 258321

URL: http://llvm.org/viewvc/llvm-project?rev=258321&view=rev
Log:
Add AST matcher for paren expressions.

Patch by Adrian Zgorzałek.

Modified:
cfe/trunk/docs/LibASTMatchersReference.html
cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h
cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp
cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.cpp
cfe/trunk/unittests/ASTMatchers/Dynamic/RegistryTest.cpp

Modified: cfe/trunk/docs/LibASTMatchersReference.html
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/LibASTMatchersReference.html?rev=258321&r1=258320&r2=258321&view=diff
==
--- cfe/trunk/docs/LibASTMatchersReference.html (original)
+++ cfe/trunk/docs/LibASTMatchersReference.html Wed Jan 20 10:17:39 2016
@@ -1061,6 +1061,14 @@ NSString's "alloc". This matcher should
   [[NSString alloc] initWithString:@"Hello"]
 
 
+MatcherStmt>parenExprMatcherParenExpr>...
+Matches parentheses used 
in expressions.
+
+Given
+  int foo() { return 1; }
+  int a = (foo() + 1);
+matches '(foo() + 1)'
+
 
 MatcherStmt>returnStmtMatcherReturnStmt>...
 Matches return 
statements.

Modified: cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h?rev=258321&r1=258320&r2=258321&view=diff
==
--- cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h (original)
+++ cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h Wed Jan 20 10:17:39 2016
@@ -1048,6 +1048,17 @@ const internal::VariadicDynCastAllOfMatc
   Decl,
   UnresolvedUsingTypenameDecl> unresolvedUsingTypenameDecl;
 
+/// \brief Matches parentheses used in expressions.
+///
+/// Example matches (foo() + 1)
+/// \code
+///   int foo() { return 1; }
+///   int a = (foo() + 1);
+/// \endcode
+const internal::VariadicDynCastAllOfMatcher<
+  Stmt,
+  ParenExpr> parenExpr;
+
 /// \brief Matches constructor call expressions (including implicit ones).
 ///
 /// Example matches string(ptr, n) and ptr within arguments of f

Modified: cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp?rev=258321&r1=258320&r2=258321&view=diff
==
--- cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp (original)
+++ cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp Wed Jan 20 10:17:39 2016
@@ -328,6 +328,7 @@ RegistryMaps::RegistryMaps() {
   REGISTER_MATCHER(on);
   REGISTER_MATCHER(onImplicitObjectArgument);
   REGISTER_MATCHER(parameterCountIs);
+  REGISTER_MATCHER(parenExpr);
   REGISTER_MATCHER(parenType);
   REGISTER_MATCHER(parmVarDecl);
   REGISTER_MATCHER(pointee);

Modified: cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.cpp?rev=258321&r1=258320&r2=258321&view=diff
==
--- cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.cpp (original)
+++ cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.cpp Wed Jan 20 10:17:39 2016
@@ -3667,6 +3667,14 @@ TEST(ExceptionHandling, SimpleCases) {
  varDecl(isExceptionVariable(;
 }
 
+TEST(ParenExpression, SimpleCases) {
+  EXPECT_TRUE(matches("int i = (3);", parenExpr()));
+  EXPECT_TRUE(matches("int i = (3 + 7);", parenExpr()));
+  EXPECT_TRUE(notMatches("int i = 3;", parenExpr()));
+  EXPECT_TRUE(notMatches("int foo() { return 1; }; int a = foo();",
+ parenExpr()));
+}
+
 TEST(HasConditionVariableStatement, DoesNotMatchCondition) {
   EXPECT_TRUE(notMatches(
   "void x() { if(true) {} }",

Modified: cfe/trunk/unittests/ASTMatchers/Dynamic/RegistryTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/ASTMatchers/Dynamic/RegistryTest.cpp?rev=258321&r1=258320&r2=258321&view=diff
==
--- cfe/trunk/unittests/ASTMatchers/Dynamic/RegistryTest.cpp (original)
+++ cfe/trunk/unittests/ASTMatchers/Dynamic/RegistryTest.cpp Wed Jan 20 
10:17:39 2016
@@ -506,6 +506,12 @@ TEST_F(RegistryTest, HasArgs) {
   EXPECT_FALSE(matches("struct X {};", Value));
 }
 
+TEST_F(RegistryTest, ParenExpr) {
+  Matcher Value = constructMatcher("parenExpr").getTypedMatcher();
+  EXPECT_TRUE(matches("int i = (1);", Value));
+  EXPECT_FALSE(matches("int i = 1;", Value));
+}
+
 } // end anonymous namespace
 } // end namespace dynamic
 } // end namespace ast_matchers


__

Re: [PATCH] D16278: ASTMatcher for ParenExpr node.

2016-01-20 Thread Aaron Ballman via cfe-commits
aaron.ballman closed this revision.
aaron.ballman added a comment.

Thanks! I've commit in r258321


http://reviews.llvm.org/D16278



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


Re: [PATCH] D16215: ASTMatchers: enable hasBody() matcher for FunctionDecls

2016-01-20 Thread Aaron Ballman via cfe-commits
aaron.ballman closed this revision.
aaron.ballman added a comment.

Thanks! I went ahead and commit in r258322.


http://reviews.llvm.org/D16215



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


r258322 - Add AST matcher support for FunctionDecls with the hasBody matcher.

2016-01-20 Thread Aaron Ballman via cfe-commits
Author: aaronballman
Date: Wed Jan 20 10:26:48 2016
New Revision: 258322

URL: http://llvm.org/viewvc/llvm-project?rev=258322&view=rev
Log:
Add AST matcher support for FunctionDecls with the hasBody matcher.

Patch by Aleksei Sidorin.

Modified:
cfe/trunk/docs/LibASTMatchersReference.html
cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h
cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h
cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.cpp
cfe/trunk/unittests/ASTMatchers/Dynamic/ParserTest.cpp

Modified: cfe/trunk/docs/LibASTMatchersReference.html
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/LibASTMatchersReference.html?rev=258322&r1=258321&r2=258322&view=diff
==
--- cfe/trunk/docs/LibASTMatchersReference.html (original)
+++ cfe/trunk/docs/LibASTMatchersReference.html Wed Jan 20 10:26:48 2016
@@ -3436,8 +3436,8 @@ with withInitializer matching (1)
 
 
 MatcherCXXForRangeStmt>hasBodyMatcherStmt> 
InnerMatcher
-Matches a 'for', 'while', 
or 'do while' statement that has
-a given body.
+Matches a 'for', 'while', 
'do while' statement or a function
+definition that has a given body.
 
 Given
   for (;;) {}
@@ -3878,8 +3878,8 @@ declaration of class D.
 
 
 MatcherDoStmt>hasBodyMatcherStmt> 
InnerMatcher
-Matches a 'for', 'while', 
or 'do while' statement that has
-a given body.
+Matches a 'for', 'while', 
'do while' statement or a function
+definition that has a given body.
 
 Given
   for (;;) {}
@@ -4059,8 +4059,8 @@ would only match the declaration for a.
 
 
 MatcherForStmt>hasBodyMatcherStmt> 
InnerMatcher
-Matches a 'for', 'while', 
or 'do while' statement that has
-a given body.
+Matches a 'for', 'while', 
'do while' statement or a function
+definition that has a given body.
 
 Given
   for (;;) {}
@@ -4114,6 +4114,19 @@ with hasAnyParameter(...)
 
 
 
+MatcherFunctionDecl>hasBodyMatcherStmt> 
InnerMatcher
+Matches a 'for', 'while', 
'do while' statement or a function
+definition that has a given body.
+
+Given
+  for (;;) {}
+hasBody(compoundStmt())
+  matches 'for (;;) {}'
+with compoundStmt()
+  matching '{}'
+
+
+
 MatcherFunctionDecl>hasParameterunsigned N, MatcherParmVarDecl>
 InnerMatcher
 Matches the n'th 
parameter of a function declaration.
 
@@ -4891,8 +4904,8 @@ variableArrayType(hasSizeExpr(ignoringIm
 
 
 MatcherWhileStmt>hasBodyMatcherStmt> 
InnerMatcher
-Matches a 'for', 'while', 
or 'do while' statement that has
-a given body.
+Matches a 'for', 'while', 
'do while' statement or a function
+definition that has a given body.
 
 Given
   for (;;) {}

Modified: cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h?rev=258322&r1=258321&r2=258322&view=diff
==
--- cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h (original)
+++ cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h Wed Jan 20 10:26:48 2016
@@ -3189,8 +3189,8 @@ AST_MATCHER_P(ArraySubscriptExpr, hasBas
   return false;
 }
 
-/// \brief Matches a 'for', 'while', or 'do while' statement that has
-/// a given body.
+/// \brief Matches a 'for', 'while', 'do while' statement or a function
+/// definition that has a given body.
 ///
 /// Given
 /// \code
@@ -3203,9 +3203,10 @@ AST_MATCHER_P(ArraySubscriptExpr, hasBas
 AST_POLYMORPHIC_MATCHER_P(hasBody,
   AST_POLYMORPHIC_SUPPORTED_TYPES(DoStmt, ForStmt,
   WhileStmt,
-  CXXForRangeStmt),
+  CXXForRangeStmt,
+  FunctionDecl),
   internal::Matcher, InnerMatcher) {
-  const Stmt *const Statement = Node.getBody();
+  const Stmt *const Statement = internal::GetBodyMatcher::get(Node);
   return (Statement != nullptr &&
   InnerMatcher.matches(*Statement, Finder, Builder));
 }

Modified: cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/ASTMatchers/ASTMatchersIn

Re: [PATCH] D16113: [clang-tdiy] Add header file extension configuration support.

2016-01-20 Thread Aaron Ballman via cfe-commits
aaron.ballman added a comment.

Mostly looks good, except I do still have the question about list delimiters 
that I'd like to hear some thoughts on. My primary concern is that I hope to 
avoid having different separators for different lists, and I wonder whether we 
want a common "parse a list of stuff" interface for the options that then gets 
used by functions like parseHeaderFileExtensions() to do sanitization of the 
list as-needed.


http://reviews.llvm.org/D16113



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


[PATCH] D16358: [OpenMP] Parsing + Sema for nowait clause on target directive

2016-01-20 Thread Arpith Jacob via cfe-commits
arpith-jacob created this revision.
arpith-jacob added reviewers: ABataev, kkwli0, hfinkel, sfantao, carlo.bertolli.
arpith-jacob added subscribers: cfe-commits, caomhin, fraggamuffin.

Allow nowait clause on target directive in sema and add test cases.

http://reviews.llvm.org/D16358

Files:
  include/clang/Basic/OpenMPKinds.def
  test/OpenMP/target_ast_print.cpp
  test/OpenMP/target_nowait_messages.cpp

Index: test/OpenMP/target_nowait_messages.cpp
===
--- /dev/null
+++ test/OpenMP/target_nowait_messages.cpp
@@ -0,0 +1,17 @@
+// RUN: %clang_cc1 -triple x86_64-apple-macos10.7.0 -verify -fopenmp 
-ferror-limit 100 -o - %s
+
+void foo() {
+}
+
+int main(int argc, char **argv) {
+  #pragma omp target nowait( // expected-warning {{extra tokens at the end of 
'#pragma omp target' are ignored}}
+  foo();
+  #pragma omp target nowait (argc)) // expected-warning {{extra tokens at the 
end of '#pragma omp target' are ignored}}
+  foo();
+  #pragma omp target nowait device (-10u)
+  foo();
+  #pragma omp target nowait (3.14) device (-10u) // expected-warning {{extra 
tokens at the end of '#pragma omp target' are ignored}}
+  foo();
+
+  return 0;
+}
Index: test/OpenMP/target_ast_print.cpp
===
--- test/OpenMP/target_ast_print.cpp
+++ test/OpenMP/target_ast_print.cpp
@@ -25,6 +25,8 @@
   foo();
 #pragma omp target map(always,alloc: i)
   foo();
+#pragma omp target nowait
+  foo();
   return 0;
 }
 
@@ -44,6 +46,8 @@
 // CHECK-NEXT: foo()
 // CHECK-NEXT: #pragma omp target map(always,alloc: i)
 // CHECK-NEXT: foo()
+// CHECK-NEXT: #pragma omp target nowait
+// CHECK-NEXT: foo()
 // CHECK: template  char tmain(char argc, char 
*argv) {
 // CHECK-NEXT: char i, j, a[20]
 // CHECK-NEXT: #pragma omp target
@@ -60,6 +64,8 @@
 // CHECK-NEXT: foo()
 // CHECK-NEXT: #pragma omp target map(always,alloc: i)
 // CHECK-NEXT: foo()
+// CHECK-NEXT: #pragma omp target nowait
+// CHECK-NEXT: foo()
 // CHECK: template  T tmain(T argc, T *argv) {
 // CHECK-NEXT: T i, j, a[20]
 // CHECK-NEXT: #pragma omp target
@@ -76,6 +82,8 @@
 // CHECK-NEXT: foo()
 // CHECK-NEXT: #pragma omp target map(always,alloc: i)
 // CHECK-NEXT: foo()
+// CHECK-NEXT: #pragma omp target nowait
+// CHECK-NEXT: foo()
 
 // CHECK-LABEL: int main(int argc, char **argv) {
 int main (int argc, char **argv) {
@@ -115,6 +123,11 @@
   foo();
 // CHECK-NEXT: foo();
 
+#pragma omp target nowait
+// CHECK-NEXT: #pragma omp target nowait
+  foo();
+// CHECK-NEXT: foo();
+
   return tmain(argc, &argc) + tmain(argv[0][0], argv[0]);
 }
 
Index: include/clang/Basic/OpenMPKinds.def
===
--- include/clang/Basic/OpenMPKinds.def
+++ include/clang/Basic/OpenMPKinds.def
@@ -355,6 +355,7 @@
 OPENMP_TARGET_CLAUSE(device)
 OPENMP_TARGET_CLAUSE(map)
 OPENMP_TARGET_CLAUSE(private)
+OPENMP_TARGET_CLAUSE(nowait)
 
 // Clauses allowed for OpenMP directive 'target data'.
 // TODO More clauses for 'target data' directive.


Index: test/OpenMP/target_nowait_messages.cpp
===
--- /dev/null
+++ test/OpenMP/target_nowait_messages.cpp
@@ -0,0 +1,17 @@
+// RUN: %clang_cc1 -triple x86_64-apple-macos10.7.0 -verify -fopenmp -ferror-limit 100 -o - %s
+
+void foo() {
+}
+
+int main(int argc, char **argv) {
+  #pragma omp target nowait( // expected-warning {{extra tokens at the end of '#pragma omp target' are ignored}}
+  foo();
+  #pragma omp target nowait (argc)) // expected-warning {{extra tokens at the end of '#pragma omp target' are ignored}}
+  foo();
+  #pragma omp target nowait device (-10u)
+  foo();
+  #pragma omp target nowait (3.14) device (-10u) // expected-warning {{extra tokens at the end of '#pragma omp target' are ignored}}
+  foo();
+
+  return 0;
+}
Index: test/OpenMP/target_ast_print.cpp
===
--- test/OpenMP/target_ast_print.cpp
+++ test/OpenMP/target_ast_print.cpp
@@ -25,6 +25,8 @@
   foo();
 #pragma omp target map(always,alloc: i)
   foo();
+#pragma omp target nowait
+  foo();
   return 0;
 }
 
@@ -44,6 +46,8 @@
 // CHECK-NEXT: foo()
 // CHECK-NEXT: #pragma omp target map(always,alloc: i)
 // CHECK-NEXT: foo()
+// CHECK-NEXT: #pragma omp target nowait
+// CHECK-NEXT: foo()
 // CHECK: template  char tmain(char argc, char *argv) {
 // CHECK-NEXT: char i, j, a[20]
 // CHECK-NEXT: #pragma omp target
@@ -60,6 +64,8 @@
 // CHECK-NEXT: foo()
 // CHECK-NEXT: #pragma omp target map(always,alloc: i)
 // CHECK-NEXT: foo()
+// CHECK-NEXT: #pragma omp target nowait
+// CHECK-NEXT: foo()
 // CHECK: template  T tmain(T argc, T *argv) {
 // CHECK-NEXT: T i, j, a[20]
 // CHECK-NEXT: #pragma omp target
@@ -76,6 +82,8 @@
 // CHECK-NEXT: foo()
 // CHECK-NEXT: #pragma omp target map(always,alloc: i)
 // CHECK-NEXT: foo()
+// CHECK-NEXT: #pragma omp target nowait
+// CHECK-NEXT: foo()
 
 // CHECK-

Re: [PATCH] D15977: [Clang] Supporting all entities declared in lexical scope in LLVM debug info

2016-01-20 Thread Amjad Aboud via cfe-commits
aaboud updated this revision to Diff 45400.
aaboud added a comment.

Merged all 4 Lit tests into one.


http://reviews.llvm.org/D15977

Files:
  lib/CodeGen/CGDebugInfo.cpp
  lib/CodeGen/CGDebugInfo.h
  lib/CodeGen/CGDecl.cpp
  test/CodeGenCXX/debug-info-lb.cpp

Index: lib/CodeGen/CGDecl.cpp
===
--- lib/CodeGen/CGDecl.cpp
+++ lib/CodeGen/CGDecl.cpp
@@ -83,26 +83,30 @@
   case Decl::UsingShadow:
   case Decl::ObjCTypeParam:
 llvm_unreachable("Declaration should not be in declstmts!");
-  case Decl::Function:  // void X();
-  case Decl::Record:// struct/union/class X;
-  case Decl::Enum:  // enum X;
-  case Decl::EnumConstant: // enum ? { X = ? }
-  case Decl::CXXRecord: // struct/union/class X; [C++]
+  case Decl::Function: // void X();
   case Decl::StaticAssert: // static_assert(X, ""); [C++0x]
   case Decl::Label:// __label__ x;
   case Decl::Import:
   case Decl::OMPThreadPrivate:
   case Decl::Empty:
 // None of these decls require codegen support.
 return;
 
+  case Decl::Record:   // struct/union/class X;
+  case Decl::Enum: // enum X;
+  case Decl::EnumConstant: // enum ? { X = ? }
+  case Decl::CXXRecord:// struct/union/class X; [C++]
+if (CGDebugInfo *DI = getDebugInfo())
+  DI->recordDeclarationLexicalScope(D);
+return;
+
   case Decl::NamespaceAlias:
 if (CGDebugInfo *DI = getDebugInfo())
-DI->EmitNamespaceAlias(cast(D));
+  DI->EmitNamespaceAlias(cast(D));
 return;
   case Decl::Using:  // using X; [C++]
 if (CGDebugInfo *DI = getDebugInfo())
-DI->EmitUsingDecl(cast(D));
+  DI->EmitUsingDecl(cast(D));
 return;
   case Decl::UsingDirective: // using namespace X; [C++]
 if (CGDebugInfo *DI = getDebugInfo())
@@ -120,6 +124,9 @@
 const TypedefNameDecl &TD = cast(D);
 QualType Ty = TD.getUnderlyingType();
 
+if (CGDebugInfo *DI = getDebugInfo())
+  DI->recordDeclarationLexicalScope(D);
+
 if (Ty->isVariablyModifiedType())
   EmitVariablyModifiedType(Ty);
   }
Index: lib/CodeGen/CGDebugInfo.h
===
--- lib/CodeGen/CGDebugInfo.h
+++ lib/CodeGen/CGDebugInfo.h
@@ -114,6 +114,11 @@
 
   /// Keep track of our current nested lexical block.
   std::vector> LexicalBlockStack;
+
+  /// Map of AST declaration to its lexical block scope.
+  llvm::DenseMap>
+  LexicalBlockMap;
+
   llvm::DenseMap RegionMap;
   /// Keep track of LexicalBlockStack counter at the beginning of a
   /// function. This is used to pop unbalanced regions at the end of a
@@ -365,6 +370,12 @@
   /// Emit an Objective-C interface type standalone debug info.
   llvm::DIType *getOrCreateInterfaceType(QualType Ty, SourceLocation Loc);
 
+  /// Map AST declaration to its lexical block scope if available.
+  void recordDeclarationLexicalScope(const Decl &D);
+
+  /// Get lexical scope of AST declaration.
+  llvm::DIScope *getDeclarationLexicalScope(const Decl &D, QualType Ty);
+
   /// Emit standalone debug info for a type.
   llvm::DIType *getOrCreateStandaloneType(QualType Ty, SourceLocation Loc);
 
Index: lib/CodeGen/CGDebugInfo.cpp
===
--- lib/CodeGen/CGDebugInfo.cpp
+++ lib/CodeGen/CGDebugInfo.cpp
@@ -831,15 +831,18 @@
 
 llvm::DIType *CGDebugInfo::CreateType(const TypedefType *Ty,
   llvm::DIFile *Unit) {
+  TypedefNameDecl *TD = Ty->getDecl();
   // We don't set size information, but do specify where the typedef was
   // declared.
-  SourceLocation Loc = Ty->getDecl()->getLocation();
+  SourceLocation Loc = TD->getLocation();
+
+  llvm::DIScope *TDContext = getDeclarationLexicalScope(*TD, QualType(Ty, 0));
 
   // Typedefs are derived from some other type.
   return DBuilder.createTypedef(
   getOrCreateType(Ty->getDecl()->getUnderlyingType(), Unit),
   Ty->getDecl()->getName(), getOrCreateFile(Loc), getLineNumber(Loc),
-  getDeclContextDescriptor(Ty->getDecl()));
+  TDContext);
 }
 
 llvm::DIType *CGDebugInfo::CreateType(const FunctionType *Ty,
@@ -1472,6 +1475,23 @@
   return T;
 }
 
+void CGDebugInfo::recordDeclarationLexicalScope(const Decl &D) {
+  assert(LexicalBlockMap.find(&D) == LexicalBlockMap.end() &&
+ "D is already mapped to lexical block scope");
+  if (!LexicalBlockStack.empty())
+LexicalBlockMap[&D] = LexicalBlockStack.back();
+}
+
+llvm::DIScope *CGDebugInfo::getDeclarationLexicalScope(const Decl &D,
+   QualType Ty) {
+  auto I = LexicalBlockMap.find(&D);
+  if (I != LexicalBlockMap.end()) {
+RetainedTypes.push_back(Ty.getAsOpaquePtr());
+return I->second;
+  } else
+return getDeclContextDescriptor(cast(&D));
+}
+
 void CGDebugInfo::completeType(const EnumDecl *ED) {
   if (DebugKind <= CodeGenOptions::DebugLineTablesOnly)
 return;
@@ -2043,7 +2063,7 @@
   // If thi

Re: [PATCH] D16308: clang-tidy Enhance readability-simplify-boolean-expr check to handle implicit conversions of integral types to bool and member pointers

2016-01-20 Thread Richard via cfe-commits
LegalizeAdulthood added inline comments.


Comment at: docs/clang-tidy/checks/readability-simplify-boolean-expr.rst:59
@@ -56,3 +58,3 @@
 
   4. The conditional return ``if (p) return true; return false;`` has an
  implicit conversion of a pointer to ``bool`` and becomes

aaron.ballman wrote:
> Update for member pointers.
Do I really need to explicitly say member pointer as well?  It seems redundant.

I didn't update it because a pointer to a member is a pointer.  When used as an 
implicit conversion to `bool`, the syntax is no different for a plain pointer 
than for a member pointer.  If the syntax were different, I could see your 
point.



http://reviews.llvm.org/D16308



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


Re: [PATCH] D16308: clang-tidy Enhance readability-simplify-boolean-expr check to handle implicit conversions of integral types to bool and member pointers

2016-01-20 Thread Richard via cfe-commits
LegalizeAdulthood added inline comments.


Comment at: clang-tidy/readability/SimplifyBooleanExprCheck.h:77
@@ -74,3 +76,3 @@
 ///  implicit conversion of `i & 1` to `bool` and becomes
-///  `bool b = static_cast(i & 1);`.
+///  `bool b = i & 1 != 0;`.
 ///

aaron.ballman wrote:
> LegalizeAdulthood wrote:
> > aaron.ballman wrote:
> > > To me, this does not improve readability -- I now have to think much 
> > > harder about operator precedence. Including parens would help 
> > > significantly, IMO, so that it becomes `(i & 1) != 0`.
> > To clarify: You'd like to see parens around the expression when it is a 
> > binary operator, correct?
> > 
> > When it is a variable, there's no need to add parentheses.
> Correct; if it's just a DeclRefExpr or unary operator then parens aren't 
> useful; but if it's a binary operator, I think parens may help clarify.
Ironically, in another review we were talking about eliminating redundant 
parentheses globally and these parentheses added for binary operators would be 
considered redundant and removed.


http://reviews.llvm.org/D16308



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


Re: [PATCH] D16012: Carry raw string literal information through to the AST StringLiteral representation

2016-01-20 Thread Aaron Ballman via cfe-commits
aaron.ballman added a comment.

Ping


http://reviews.llvm.org/D16012



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


Re: [PATCH] D15935: Improve diagnostics for literal conversion to Boolean

2016-01-20 Thread Aaron Ballman via cfe-commits
aaron.ballman added a comment.

Ping


http://reviews.llvm.org/D15935



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


Re: Merge libc++/libc++abi license headers fixes into 3.8

2016-01-20 Thread Hans Wennborg via cfe-commits
On Tue, Jan 19, 2016 at 6:08 PM, Marshall Clow  wrote:
> On Tue, Jan 19, 2016 at 3:34 PM, Eric Fiselier  wrote:
>> I would like to merge the following commits into 3.8.
>>
>> 1. r258196 (libc++)
>> 2. r258198 (libc++)
>> 3. r258201 (libc++abi)
>>
>> These commits simply add missing license headers.
>>
>> @Marshall Can you please OK this?
>>
>
> I am fine with this.

Thanks. Eric, please go ahead and merge with the script in
util/release/merge.sh.

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


Re: [PATCH] D16219: PR8901: attribute "mode" rejected for enums and dependent types

2016-01-20 Thread Denis Zobnin via cfe-commits
d.zobnin.bugzilla updated this revision to Diff 45401.
d.zobnin.bugzilla added a comment.

Updated the patch after committed fix for http://reviews.llvm.org/D16301 
(r258213).

This patch:

1. Adds "Enum" Subject to 'mode' attribute to be able to compile code like 
"typedef enum { X } __attribute__((mode(QI))) T;"
2. Moves handling of the attribute to a new Sema's method in order to support 
'mode' attribute on dependent types;
3. Adds several cases to the tests (both for templates and non-dependent types).

Please take a look.


http://reviews.llvm.org/D16219

Files:
  include/clang/Basic/Attr.td
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Sema/AttributeList.h
  include/clang/Sema/Sema.h
  lib/Sema/SemaDeclAttr.cpp
  lib/Sema/SemaTemplateInstantiateDecl.cpp
  test/CodeGen/attr-mode-enums.c
  test/CodeGenCXX/attr-mode-vector-types-tmpl.cpp
  test/Sema/attr-mode-enums.c
  test/Sema/attr-mode.c
  test/SemaCXX/attr-mode-tmpl.cpp

Index: lib/Sema/SemaTemplateInstantiateDecl.cpp
===
--- lib/Sema/SemaTemplateInstantiateDecl.cpp
+++ lib/Sema/SemaTemplateInstantiateDecl.cpp
@@ -227,6 +227,14 @@
 Attr.getSpellingListIndex());
 }
 
+static void
+instantiateDependentModeAttr(Sema &S,
+ const MultiLevelTemplateArgumentList &TemplateArgs,
+ const ModeAttr &Attr, Decl *New) {
+  S.AddModeAttr(Attr.getRange(), New, Attr.getMode(),
+Attr.getSpellingListIndex(), /*InInstantiation=*/true);
+}
+
 void Sema::InstantiateAttrs(const MultiLevelTemplateArgumentList &TemplateArgs,
 const Decl *Tmpl, Decl *New,
 LateInstantiatedAttrVec *LateAttrs,
@@ -265,6 +273,11 @@
   continue;
 }
 
+if (const ModeAttr *Mode = dyn_cast(TmplAttr)) {
+  instantiateDependentModeAttr(*this, TemplateArgs, *Mode, New);
+  continue;
+}
+
 // Existing DLL attribute on the instantiation takes precedence.
 if (TmplAttr->getKind() == attr::DLLExport ||
 TmplAttr->getKind() == attr::DLLImport) {
Index: lib/Sema/SemaDeclAttr.cpp
===
--- lib/Sema/SemaDeclAttr.cpp
+++ lib/Sema/SemaDeclAttr.cpp
@@ -3293,6 +3293,8 @@
 /// attribute.
 static void parseModeAttrArg(Sema &S, StringRef Str, unsigned &DestWidth,
  bool &IntegerMode, bool &ComplexMode) {
+  IntegerMode = true;
+  ComplexMode = false;
   switch (Str.size()) {
   case 2:
 switch (Str[0]) {
@@ -3359,9 +3361,15 @@
   }
 
   IdentifierInfo *Name = Attr.getArgAsIdent(0)->Ident;
-  StringRef Str = Name->getName();
 
+  S.AddModeAttr(Attr.getRange(), D, Name, Attr.getAttributeSpellingListIndex());
+}
+
+void Sema::AddModeAttr(SourceRange AttrRange, Decl *D, IdentifierInfo *Name,
+   unsigned SpellingListIndex, bool InInstantiation) {
+  StringRef Str = Name->getName();
   normalizeName(Str);
+  SourceLocation AttrLoc = AttrRange.getBegin();
 
   unsigned DestWidth = 0;
   bool IntegerMode = true;
@@ -3377,99 +3385,126 @@
 if (VectorStringLength &&
 !Str.substr(1, VectorStringLength).getAsInteger(10, VectorSize) &&
 VectorSize.isPowerOf2()) {
-  parseModeAttrArg(S, Str.substr(VectorStringLength + 1), DestWidth,
+  parseModeAttrArg(*this, Str.substr(VectorStringLength + 1), DestWidth,
IntegerMode, ComplexMode);
-  S.Diag(Attr.getLoc(), diag::warn_vector_mode_deprecated);
+  // Avoid duplicate warning from template instantiation.
+  if (!InInstantiation)
+Diag(AttrLoc, diag::warn_vector_mode_deprecated);
 } else {
   VectorSize = 0;
 }
   }
 
   if (!VectorSize)
-parseModeAttrArg(S, Str, DestWidth, IntegerMode, ComplexMode);
+parseModeAttrArg(*this, Str, DestWidth, IntegerMode, ComplexMode);
+
+  // FIXME: Sync this with InitializePredefinedMacros; we need to match int8_t
+  // and friends, at least with glibc.
+  // FIXME: Make sure floating-point mappings are accurate
+  // FIXME: Support XF and TF types
+  if (!DestWidth) {
+Diag(AttrLoc, diag::err_machine_mode) << 0 /*Unknown*/ << Name;
+return;
+  }
 
   QualType OldTy;
   if (TypedefNameDecl *TD = dyn_cast(D))
 OldTy = TD->getUnderlyingType();
-  else
+  else if (EnumDecl *ED = dyn_cast(D)) {
+// Something like 'typedef enum { X } __attribute__((mode(XX))) T;'.
+// Try to get type from enum declaration, default to int.
+OldTy = ED->getIntegerType();
+if (OldTy.isNull())
+  OldTy = Context.IntTy;
+  } else
 OldTy = cast(D)->getType();
 
+  if (OldTy->isDependentType()) {
+D->addAttr(::new (Context)
+   ModeAttr(AttrRange, Context, Name, SpellingListIndex));
+return;
+  }
+
   // Base type can also be a vector type (see PR17453).
   // Distinguish between base type and base element type.
   QualType OldElemTy = OldTy;
   if (const V

Re: [libcxxabi] r258249 - Recommit r256322: Fix PR25898 - Check for incomplete pointers types in can_catch(...)

2016-01-20 Thread Hans Wennborg via cfe-commits
No problem. Please go ahead and merge with utils/release/merge.sh, or
let me know if you'd prefer me to do it.

On Tue, Jan 19, 2016 at 7:09 PM, Eric Fiselier  wrote:
> Hi Hans,
>
> Sorry to make this more complicated, but can you also include the follow-up
> libc++abi commit r258277.
>
> /Eric
>
> On Tue, Jan 19, 2016 at 7:08 PM, Marshall Clow 
> wrote:
>>
>>
>>
>> On Tue, Jan 19, 2016 at 3:48 PM, Eric Fiselier  wrote:
>>>
>>> Hi Hans,
>>>
>>> I fixed the problem that caused Nico to revert this. I would like to
>>> re-land this in 3.8.
>>> This depends on libc++ commit r258217 also landing in 3.8.
>>>
>>> @Marshall can you OK this?
>>>
>>
>> This is fine with me.  (both r258217 and r256322)
>>
>> -- Marshall
>>
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [PATCH] D16308: clang-tidy Enhance readability-simplify-boolean-expr check to handle implicit conversions of integral types to bool and member pointers

2016-01-20 Thread Aaron Ballman via cfe-commits
aaron.ballman added inline comments.


Comment at: clang-tidy/readability/SimplifyBooleanExprCheck.h:77
@@ -74,3 +76,3 @@
 ///  implicit conversion of `i & 1` to `bool` and becomes
-///  `bool b = static_cast(i & 1);`.
+///  `bool b = i & 1 != 0;`.
 ///

LegalizeAdulthood wrote:
> aaron.ballman wrote:
> > LegalizeAdulthood wrote:
> > > aaron.ballman wrote:
> > > > To me, this does not improve readability -- I now have to think much 
> > > > harder about operator precedence. Including parens would help 
> > > > significantly, IMO, so that it becomes `(i & 1) != 0`.
> > > To clarify: You'd like to see parens around the expression when it is a 
> > > binary operator, correct?
> > > 
> > > When it is a variable, there's no need to add parentheses.
> > Correct; if it's just a DeclRefExpr or unary operator then parens aren't 
> > useful; but if it's a binary operator, I think parens may help clarify.
> Ironically, in another review we were talking about eliminating redundant 
> parentheses globally and these parentheses added for binary operators would 
> be considered redundant and removed.
In the other review, I was suggesting that parens in expressions involving 
binary operators of differing precedence should not be removed. ;-)


Comment at: docs/clang-tidy/checks/readability-simplify-boolean-expr.rst:59
@@ -56,3 +58,3 @@
 
   4. The conditional return ``if (p) return true; return false;`` has an
  implicit conversion of a pointer to ``bool`` and becomes

LegalizeAdulthood wrote:
> aaron.ballman wrote:
> > Update for member pointers.
> Do I really need to explicitly say member pointer as well?  It seems 
> redundant.
> 
> I didn't update it because a pointer to a member is a pointer.  When used as 
> an implicit conversion to `bool`, the syntax is no different for a plain 
> pointer than for a member pointer.  If the syntax were different, I could see 
> your point.
> 
A pointer to a member is not a pointer according to the language standard, and 
that's why it may not be a bad idea to call it out explicitly as being 
supported. From [basic.compound]p3, "Except for pointers to static members, 
text referring to “pointers” does not apply to pointers to members." I do take 
your point about the syntax of the implicit conversion being the same, but it 
would be nice to be explicit about what we support. I would just change it to 
say "...implicit conversion of a pointer (or pointer to member) to ``bool``..."


http://reviews.llvm.org/D16308



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


[PATCH] D16360: unordered_map: Avoid unnecessary mallocs when no insert occurs

2016-01-20 Thread Duncan P. N. Exon Smith via cfe-commits
dexonsmith created this revision.
dexonsmith added a reviewer: EricWF.
dexonsmith added a subscriber: cfe-commits.

(Repost of:
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20160118/147379.html
on Phabricator as requested by Eric.)

This is a follow-up to r239666: "Fix PR12999 - unordered_set::insert
calls operator new when no insert occurs".  That fix didn't apply to
`unordered_map` because unordered_map::value_type gets packed inside:
--
union __value_type {
  pair __nc;   // Only C++11 or higher.
  pair __cc; // Always.
  // Constructors...
};
--
and the underlying __hash_table only knows about __value_type.

This patch should avoid unnecessary mallocs whenever the caller passes
in a pair such that T is trivially convertible to key_type.

Since __hash_table's value_type is really *never* a pair (for
unordered_map, it's a union of two pairs) the static dispatch is all in
unordered_map.  It's doing this:
 - If the argument isn't a pair<>, alloc.
 - If argument.first can be referenced as const key_type&, don't alloc.
 - If argument.first can be trivially converted to key_type, don't
   alloc.
 - Else alloc.

In the pre-C++11 world the caller has already converted to
unordered_map::value_type.  We can always avoid the alloc.

To support all of this:
 - In C++03, __unordered_map_equal and __unordered_map_hasher need to
   handle unordered_map::value_type.
 - In C++03, __hash_table::__insert_unique_value() now takes its
   argument by template.
 - In C++11, __hash_table::__insert_unique_value() is now a one-liner
   that forwards to __insert_unique_key_value() for the real work.
 - The versions of __hash_table::__construct_node() that take a
   pre-computed hash have been renamed to __construct_node_hash(), and
   these versions use perfect forwarding.

This is one of my first patches for libc++, so I may need some extra
guidance:
- Did I successfully match the coding style?  (I'm kind of lost
  without clang-format TBH.)
- Should I separate the change to __construct_node_hash() into a
  separate prep commit?  (I would if this were LLVM, but I'm not sure
  if the common practice is different for libc++.)

After this I'll fix the same performance issue in std::map (and I
assume std::set?).


http://reviews.llvm.org/D16360

Files:
  include/__hash_table
  include/unordered_map
  test/libcxx/containers/unord/unord.map/insert_dup_alloc.pass.cpp

Index: test/libcxx/containers/unord/unord.map/insert_dup_alloc.pass.cpp
===
--- /dev/null
+++ test/libcxx/containers/unord/unord.map/insert_dup_alloc.pass.cpp
@@ -0,0 +1,79 @@
+//===--===//
+//
+// 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.
+//
+//===--===//
+
+// Check that we don't allocate when trying to insert a duplicate value into a
+// unordered_map.
+
+#include 
+#include 
+#include "count_new.hpp"
+#include "MoveOnly.h"
+
+int main()
+{
+{
+std::unordered_map s;
+assert(globalMemCounter.checkNewCalledEq(0));
+
+for(int i=0; i < 100; ++i) {
+s.insert(std::make_pair(3, i));
+s.insert(std::make_pair(3, unsigned(i)));
+s.insert(std::make_pair(3u, i));
+s.insert(std::make_pair(3u, unsigned(i)));
+s.insert(std::make_pair(3, i));
+{
+const std::pair P(3, i);
+s.insert(P);
+}
+{
+const std::pair P(3, i);
+s.insert(P);
+}
+}
+
+assert(s.size() == 1);
+assert(s.count(3) == 1);
+assert(s.at(3) == 0);
+assert(globalMemCounter.checkNewCalledEq(2));
+}
+assert(globalMemCounter.checkOutstandingNewEq(0));
+globalMemCounter.reset();
+#ifndef _LIBCPP_HAS_NO_RVALUE_REFERENCES
+{
+std::unordered_map s;
+assert(globalMemCounter.checkNewCalledEq(0));
+
+for(int i=0; i<100; i++)
+s.insert(std::make_pair(MoveOnly(3), MoveOnly(i)));
+
+assert(s.size() == 1);
+assert(s.count(MoveOnly(3)) == 1);
+assert(s.at(MoveOnly(3)) == 0);
+assert(globalMemCounter.checkNewCalledEq(2));
+}
+assert(globalMemCounter.checkOutstandingNewEq(0));
+globalMemCounter.reset();
+{
+std::unordered_map s;
+assert(globalMemCounter.checkNewCalledEq(0));
+
+for(int i=0; i<100; i++) {
+s.insert(std::make_pair(3, MoveOnly(i)));
+s.insert(std::make_pair(3u, MoveOnly(i)));
+}
+
+assert(s.size() == 1);
+assert(s.count(3) == 1);
+assert(s.at(3) == 0);
+assert(globalMemCounter.checkNewCalledEq(2));
+}
+assert(globalMemCounter.checkOutstandingNewEq(0));
+globalMemCounter.reset();
+#endif
+}
Index: include/unordered_map
===
--- incl

Re: [libcxx] [PATCH] unordered_map: Avoid unnecessary mallocs when no insert occurs

2016-01-20 Thread Duncan P. N. Exon Smith via cfe-commits
Reviewer's choice:
  http://reviews.llvm.org/D16360

(I've barely used phab, so let me know if it's broken somehow...)

> On 2016-Jan-19, at 16:15, Eric Fiselier  wrote:
> 
> Hey Duncan,
> 
> I know this isn't required, but would it be possible to put this on 
> phabricator?
> 
> /Eric
> 
> On Mon, Jan 18, 2016 at 4:34 PM, Duncan P. N. Exon Smith 
>  wrote:
> ping
> 
> > On 2016-Jan-11, at 16:23, Duncan P. N. Exon Smith  
> > wrote:
> >
> > ping
> >
> >> On 2016-Jan-04, at 12:37, Duncan P. N. Exon Smith  
> >> wrote:
> >>
> >> ping
> >>
> >>> On 2015-Dec-17, at 13:56, Duncan P. N. Exon Smith  
> >>> wrote:
> >>>
> >>>
>  On 2015-Dec-16, at 14:42, Duncan P. N. Exon Smith  
>  wrote:
> 
>  This is a follow-up to r239666: "Fix PR12999 - unordered_set::insert
>  calls operator new when no insert occurs".  That fix didn't apply to
>  `unordered_map` because unordered_map::value_type gets packed inside:
>  --
>  union __value_type {
>  pair __nc;   // Only C++11 or higher.
>  pair __cc; // Always.
>  // Constructors...
>  };
>  --
>  and the underlying __hash_table only knows about __value_type.
> >>>
> >>> Sorry for the quick ping, but I realized this morning that my approach
> >>> was still leaving mallocs on the table.
> >>>
> >>> I've attached a new patch that handles more cases.
> >>>
> >>> This patch should avoid unnecessary mallocs whenever the caller passes
> >>> in a pair such that T is trivially convertible to key_type.
> >>>
> >>> Since __hash_table's value_type is really *never* a pair (for
> >>> unordered_map, it's a union of two pairs) the static dispatch is all in
> >>> unordered_map.  It's doing this:
> >>> - If the argument isn't a pair<>, alloc.
> >>> - If argument.first can be referenced as const key_type&, don't alloc.
> >>> - If argument.first can be trivially converted to key_type, don't
> >>>  alloc.
> >>> - Else alloc.
> >>>
> >>> In the pre-C++11 world the caller has already converted to
> >>> unordered_map::value_type.  We can always avoid the alloc.
> >>>
> >>> To support all of this:
> >>> - In C++03, __unordered_map_equal and __unordered_map_hasher need to
> >>>  handle unordered_map::value_type.
> >>> - In C++03, __hash_table::__insert_unique_value() now takes its
> >>>  argument by template.
> >>> - In C++11, __hash_table::__insert_unique_value() is now a one-liner
> >>>  that forwards to __insert_unique_key_value() for the real work.
> >>> - The versions of __hash_table::__construct_node() that take a
> >>>  pre-computed hash have been renamed to __construct_node_hash(), and
> >>>  these versions use perfect forwarding.
> >>>
> >>> Most of the following still apply:
> >>>
>  This is one of my first patches for libc++, and I'm not sure of a few
>  things:
>  - Did I successfully match the coding style?  (I'm kind of lost
>  without clang-format TBH.)
>  - Should I separate the change to __construct_node_hash() into a
>  separate prep commit?  (I would if this were LLVM, but I'm not sure
>  if the common practice is different for libc++.)
>  - Most of the overloads I added to __unordered_map_hasher and
>  __unordered_map_equal aren't actually used by
>  __hash_table::__insert_unique_value().  Should I omit the unused
>  ones?  (Again, for LLVM I would have omitted them.)
> >>>
> >>> (For the updated patch, I went with the LLVM approach of only adding
> >>> the used API.  It seems more appropriate in this case.)
> >>>
>  After this I'll fix the same performance issue in std::map (and I
>  assume std::set?).
> >>
> >> <0001-unordered_map-Avoid-unnecessary-mallocs-when-no-i-v2.patch>
> >
> 
> 

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


Re: [PATCH] D15599: [CodeGen] Fix a crash that occurs when attribute "naked" is attached to a c++ member function

2016-01-20 Thread Akira Hatanaka via cfe-commits
ahatanak added a comment.

ping


http://reviews.llvm.org/D15599



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


Re: [libcxx] r249798 - Split out of .

2016-01-20 Thread Hans Wennborg via cfe-commits
/sub

On Wed, Jan 20, 2016 at 4:45 AM, Nico Weber via cfe-commits
 wrote:
> Eric, Marshall: another ping. This should be fixed on the 3.8 branch, so it
> needs to be resolved soon.
>
> On Jan 5, 2016 5:25 PM, "Nico Weber"  wrote:
>>
>> On Wed, Dec 30, 2015 at 8:28 PM, Richard Smith 
>> wrote:
>>>
>>> On Wed, Dec 30, 2015 at 1:17 PM, Nico Weber  wrote:

 One problem with this patch: stdio.h can be used in .c files, and when
 building .c files with -gnu99 -pedantic,
>>>
>>>
>>> Do you mean -std=gnu89?
>>>

 clang will complain about // comments. Not only does this stdio.h have
 // comments, it also pulls in some libc++ headers (__config) that have //
 comments as well. I suppose all the comments in header files pulled in by C
 headers need to become /* */ comments?
>>>
>>>
>>> I suppose so too. Your configuration is probably somewhat broken if
>>> libc++'s headers are in your include path while building C code, but it
>>> doesn't seem unreasonable to properly support that mode, and my changes were
>>> already trying to do so.
>>>
>>> Eric, Marshall, what do you think about using only /*...*/-style comments
>>> in these headers, to handle the case where libc++ is somehow in the include
>>> path for a C89 compilation?
>>
>>
>> Eric, Marshall: Ping ^
>>
>>>
>>>

 On Tue, Oct 13, 2015 at 7:34 PM, Richard Smith via cfe-commits
  wrote:
>
> On Tue, Oct 13, 2015 at 3:26 PM, Eric Fiselier  wrote:
>>
>> This change LGTM. Let's hold off on the using "_Static_assert" until
>> we understand how that would work with "-pedantic" when the macro is
>> expanded in user code.
>
>
> Committed as r250247, thanks.
>
>>
>> /Eric
>>
>> On Tue, Oct 13, 2015 at 4:19 PM, Richard Smith 
>> wrote:
>>>
>>> On Tue, Oct 13, 2015 at 2:12 PM, Eric Fiselier via cfe-commits
>>>  wrote:

 I would rather not do this if possible but I understand why we need
 to do it.

 Richard is there a cost associated with the 'extern "C++"'
 construct? or by forcing the compiler to switch modes in general?
>>>
>>>
>>> Not a significant one compared to the cost of the code wrapped in the
>>> 'extern "C++"' here. (Also, this is wrapped in an #ifdef that only 
>>> applies
>>> in C++98; we could further reduce the set of cases when this happens by
>>> using _Static_assert when available instead of this static_assert
>>> emulation.)
>>>

 On Mon, Oct 12, 2015 at 12:27 PM, Richard Smith
  wrote:
>
> On Mon, Oct 12, 2015 at 9:41 AM, Steven Wu via cfe-commits
>  wrote:
>>
>> Hi Richard
>>
>> Your splitting seems causing problem when using extern "C". Here
>> is a test case:
>>
>> $ cat test.cpp
>> #ifdef __cplusplus
>> extern "C" {
>> #endif
>> #include 
>> #ifdef __cplusplus
>> }
>> #endif
>>
>> Error:
>> clang -fsyntax-only test.cpp
>> In file included from test.cpp:4:
>> In file included from /usr/bin/../include/c++/v1/stdio.h:102:
>> /usr/bin/../include/c++/v1/__config:593:1: error:
>>   templates must have C++ linkage
>> template  struct __static_assert_test;
>> ^~~
>> /usr/bin/../include/c++/v1/__config:594:20: error:
>>   explicit specialization of non-template struct
>> '__static_assert_test'
>> template <> struct __static_assert_test {};
>>^   ~~
>> /usr/bin/../include/c++/v1/__config:595:1: error:
>>   templates must have C++ linkage
>> template  struct __static_assert_check {};
>> ^~~
>> 3 errors generated.
>>
>> Because the code is actually compiled in C++, the guard in the
>> header failed to exclude the templates. In the meantime, I don't 
>> know if
>> there are ways to detect the header is in extern "C".
>
>
> This was supposed to work, but apparently I only tested it when
> compiling as C++11; the static_assert emulation in C++98 mode needs 
> some
> massaging to cope with this.
>
> Eric, Marshall: Are you OK with the attached patch? The idea is to
> make <__config> be fine to include in extern "C" or extern "C++" 
> modes (and
> likewise for the  headers). This is something that comes up 
> pretty
> often in practice (people wrap an include of a C header in 'extern 
> "C"', and
> that C header includes a  file that libc++ provides).
>
>>
>> Steven
>>
>>
>> > On Oct 8, 2015, at 6:29 PM, Richard Smith via cfe-commits
>> >  wrote:
>> >
>> > Au

[PATCH] D16361: [OpenMP] Parsing + Sema for nowait clause on target enter data directive.

2016-01-20 Thread Arpith Jacob via cfe-commits
arpith-jacob created this revision.
arpith-jacob added reviewers: ABataev, kkwli0, hfinkel, sfantao, carlo.bertolli.
arpith-jacob added subscribers: cfe-commits, fraggamuffin, caomhin.

Accept nowait clause on target enter data directive in sema and add test cases.

http://reviews.llvm.org/D16361

Files:
  include/clang/Basic/OpenMPKinds.def
  test/OpenMP/target_enter_data_ast_print.cpp
  test/OpenMP/target_enter_data_nowait_messages.cpp

Index: test/OpenMP/target_enter_data_nowait_messages.cpp
===
--- /dev/null
+++ test/OpenMP/target_enter_data_nowait_messages.cpp
@@ -0,0 +1,17 @@
+// RUN: %clang_cc1 -triple x86_64-apple-macos10.7.0 -verify -fopenmp -ferror-limit 100 -o - %s
+
+int main(int argc, char **argv) {
+  int i;
+
+  #pragma omp nowait target enter data map(to: i) // expected-error {{expected an OpenMP directive}}
+  #pragma omp target nowait enter data map(to: i) // expected-warning {{extra tokens at the end of '#pragma omp target' are ignored}}
+  #pragma omp target enter nowait data map(to: i) // expected-error {{expected an OpenMP directive}}
+  #pragma omp target enter data nowait() map(to: i) // expected-warning {{extra tokens at the end of '#pragma omp target enter data' are ignored}} expected-error {{expected at least one map clause for '#pragma omp target enter data'}}
+  #pragma omp target enter data map(to: i) nowait( // expected-warning {{extra tokens at the end of '#pragma omp target enter data' are ignored}}
+  #pragma omp target enter data map(to: i) nowait (argc)) // expected-warning {{extra tokens at the end of '#pragma omp target enter data' are ignored}}
+  #pragma omp target enter data map(to: i) nowait device (-10u)
+  #pragma omp target enter data map(to: i) nowait (3.14) device (-10u) // expected-warning {{extra tokens at the end of '#pragma omp target enter data' are ignored}}
+  #pragma omp target enter data map(to: i) nowait nowait // expected-error {{directive '#pragma omp target enter data' cannot contain more than one 'nowait' clause}}
+  #pragma omp target enter data nowait map(to: i) nowait // expected-error {{directive '#pragma omp target enter data' cannot contain more than one 'nowait' clause}}
+  return 0;
+}
Index: test/OpenMP/target_enter_data_ast_print.cpp
===
--- test/OpenMP/target_enter_data_ast_print.cpp
+++ test/OpenMP/target_enter_data_ast_print.cpp
@@ -27,6 +27,22 @@
 
 #pragma omp target enter data map(always,alloc: e)
 
+#pragma omp target enter data nowait map(to: i)
+
+#pragma omp target enter data nowait map(to: i) if (target enter data: j > 0)
+
+#pragma omp target enter data map(to: i) if (b) nowait
+
+#pragma omp target enter data map(to: c) nowait
+
+#pragma omp target enter data map(to: c) nowait if(b>e)
+
+#pragma omp target enter data nowait map(alloc: x[0:10], c)
+
+#pragma omp target enter data nowait map(to: c) map(alloc: d)
+
+#pragma omp target enter data nowait map(always,alloc: e)
+
   return 0;
 }
 
@@ -41,6 +57,14 @@
 // CHECK-NEXT: #pragma omp target enter data map(alloc: x[0:10],c)
 // CHECK-NEXT: #pragma omp target enter data map(to: c) map(alloc: d)
 // CHECK-NEXT: #pragma omp target enter data map(always,alloc: e)
+// CHECK-NEXT: #pragma omp target enter data nowait map(to: i)
+// CHECK-NEXT: #pragma omp target enter data nowait map(to: i) if(target enter data: j > 0)
+// CHECK-NEXT: #pragma omp target enter data map(to: i) if(b) nowait
+// CHECK-NEXT: #pragma omp target enter data map(to: c) nowait
+// CHECK-NEXT: #pragma omp target enter data map(to: c) nowait if(b > e)
+// CHECK-NEXT: #pragma omp target enter data nowait map(alloc: x[0:10],c)
+// CHECK-NEXT: #pragma omp target enter data nowait map(to: c) map(alloc: d)
+// CHECK-NEXT: #pragma omp target enter data nowait map(always,alloc: e)
 // CHECK: template  char tmain(char argc, char *argv) {
 // CHECK-NEXT: char i, j, b, c, d, e, x[20];
 // CHECK-NEXT: i = argc;
@@ -52,6 +76,14 @@
 // CHECK-NEXT: #pragma omp target enter data map(alloc: x[0:10],c)
 // CHECK-NEXT: #pragma omp target enter data map(to: c) map(alloc: d)
 // CHECK-NEXT: #pragma omp target enter data map(always,alloc: e)
+// CHECK-NEXT: #pragma omp target enter data nowait map(to: i)
+// CHECK-NEXT: #pragma omp target enter data nowait map(to: i) if(target enter data: j > 0)
+// CHECK-NEXT: #pragma omp target enter data map(to: i) if(b) nowait
+// CHECK-NEXT: #pragma omp target enter data map(to: c) nowait
+// CHECK-NEXT: #pragma omp target enter data map(to: c) nowait if(b > e)
+// CHECK-NEXT: #pragma omp target enter data nowait map(alloc: x[0:10],c)
+// CHECK-NEXT: #pragma omp target enter data nowait map(to: c) map(alloc: d)
+// CHECK-NEXT: #pragma omp target enter data nowait map(always,alloc: e)
 // CHECK: template  T tmain(T argc, T *argv) {
 // CHECK-NEXT: T i, j, b, c, d, e, x[20];
 // CHECK-NEXT: i = argc;
@@ -63,6 +95,14 @@
 // CHECK-NEXT: #pragma omp target enter data m

[PATCH] D16362: [OpenMP] Parsing + Sema for nowait clause on target exit data directive.

2016-01-20 Thread Arpith Jacob via cfe-commits
arpith-jacob created this revision.
arpith-jacob added reviewers: ABataev, kkwli0, hfinkel, sfantao, carlo.bertolli.
arpith-jacob added subscribers: cfe-commits, fraggamuffin, caomhin.

Accept nowait clause on target exit data directive in sema and add test cases.

http://reviews.llvm.org/D16362

Files:
  include/clang/Basic/OpenMPKinds.def
  test/OpenMP/target_exit_data_ast_print.cpp
  test/OpenMP/target_exit_data_nowait_messages.cpp

Index: test/OpenMP/target_exit_data_nowait_messages.cpp
===
--- /dev/null
+++ test/OpenMP/target_exit_data_nowait_messages.cpp
@@ -0,0 +1,17 @@
+// RUN: %clang_cc1 -triple x86_64-apple-macos10.7.0 -verify -fopenmp -ferror-limit 100 -o - %s
+
+int main(int argc, char **argv) {
+  int i;
+
+  #pragma omp nowait target exit data map(from: i) // expected-error {{expected an OpenMP directive}}
+  #pragma omp target nowait exit data map(from: i) // expected-warning {{extra tokens at the end of '#pragma omp target' are ignored}}
+  #pragma omp target exit nowait data map(from: i) // expected-error {{expected an OpenMP directive}}
+  #pragma omp target exit data nowait() map(from: i) // expected-warning {{extra tokens at the end of '#pragma omp target exit data' are ignored}} expected-error {{expected at least one map clause for '#pragma omp target exit data'}}
+  #pragma omp target exit data map(from: i) nowait( // expected-warning {{extra tokens at the end of '#pragma omp target exit data' are ignored}}
+  #pragma omp target exit data map(from: i) nowait (argc)) // expected-warning {{extra tokens at the end of '#pragma omp target exit data' are ignored}}
+  #pragma omp target exit data map(from: i) nowait device (-10u)
+  #pragma omp target exit data map(from: i) nowait (3.14) device (-10u) // expected-warning {{extra tokens at the end of '#pragma omp target exit data' are ignored}}
+  #pragma omp target exit data map(from: i) nowait nowait // expected-error {{directive '#pragma omp target exit data' cannot contain more than one 'nowait' clause}}
+  #pragma omp target exit data nowait map(from: i) nowait // expected-error {{directive '#pragma omp target exit data' cannot contain more than one 'nowait' clause}}
+  return 0;
+}
Index: test/OpenMP/target_exit_data_ast_print.cpp
===
--- test/OpenMP/target_exit_data_ast_print.cpp
+++ test/OpenMP/target_exit_data_ast_print.cpp
@@ -27,6 +27,22 @@
 
 #pragma omp target exit data map(always,release: e)
 
+#pragma omp target exit data nowait map(from: i)
+
+#pragma omp target exit data nowait map(from: i) if (target exit data: j > 0)
+
+#pragma omp target exit data map(from: i) if (b) nowait
+
+#pragma omp target exit data map(from: c) nowait
+
+#pragma omp target exit data map(from: c) nowait if(b>e)
+
+#pragma omp target exit data nowait map(release: x[0:10], c)
+
+#pragma omp target exit data nowait map(from: c) map(release: d)
+
+#pragma omp target exit data nowait map(always,release: e)
+
   return 0;
 }
 
@@ -41,6 +57,14 @@
 // CHECK-NEXT: #pragma omp target exit data map(release: x[0:10],c)
 // CHECK-NEXT: #pragma omp target exit data map(from: c) map(release: d)
 // CHECK-NEXT: #pragma omp target exit data map(always,release: e)
+// CHECK-NEXT: #pragma omp target exit data nowait map(from: i)
+// CHECK-NEXT: #pragma omp target exit data nowait map(from: i) if(target exit data: j > 0)
+// CHECK-NEXT: #pragma omp target exit data map(from: i) if(b) nowait
+// CHECK-NEXT: #pragma omp target exit data map(from: c) nowait
+// CHECK-NEXT: #pragma omp target exit data map(from: c) nowait if(b > e)
+// CHECK-NEXT: #pragma omp target exit data nowait map(release: x[0:10],c)
+// CHECK-NEXT: #pragma omp target exit data nowait map(from: c) map(release: d)
+// CHECK-NEXT: #pragma omp target exit data nowait map(always,release: e)
 // CHECK: template  char tmain(char argc, char *argv) {
 // CHECK-NEXT: char i, j, b, c, d, e, x[20];
 // CHECK-NEXT: i = argc;
@@ -52,6 +76,14 @@
 // CHECK-NEXT: #pragma omp target exit data map(release: x[0:10],c)
 // CHECK-NEXT: #pragma omp target exit data map(from: c) map(release: d)
 // CHECK-NEXT: #pragma omp target exit data map(always,release: e)
+// CHECK-NEXT: #pragma omp target exit data nowait map(from: i)
+// CHECK-NEXT: #pragma omp target exit data nowait map(from: i) if(target exit data: j > 0)
+// CHECK-NEXT: #pragma omp target exit data map(from: i) if(b) nowait
+// CHECK-NEXT: #pragma omp target exit data map(from: c) nowait
+// CHECK-NEXT: #pragma omp target exit data map(from: c) nowait if(b > e)
+// CHECK-NEXT: #pragma omp target exit data nowait map(release: x[0:10],c)
+// CHECK-NEXT: #pragma omp target exit data nowait map(from: c) map(release: d)
+// CHECK-NEXT: #pragma omp target exit data nowait map(always,release: e)
 // CHECK: template  T tmain(T argc, T *argv) {
 // CHECK-NEXT: T i, j, b, c, d, e, x[20];
 // CHECK-NEXT: i = argc;
@@ -63,6 +95,14 @@
 // CHECK-NEXT

[PATCH] D16363: Add option to specify clang-format binary for clang-format-diff

2016-01-20 Thread Kwasi Mensah via cfe-commits
kmensah created this revision.
kmensah added a reviewer: djasper.
kmensah added a subscriber: cfe-commits.
kmensah set the repository for this revision to rL LLVM.

A command line option that lets users of the script specify which clang-format 
binary to use. Useful if clang-format is not on PATH or you want more control 
over which binary gets chosen.

Repository:
  rL LLVM

http://reviews.llvm.org/D16363

Files:
  clang-format-diff.py

Index: clang-format-diff.py
===
--- clang-format-diff.py
+++ clang-format-diff.py
@@ -30,11 +30,8 @@
 import StringIO
 import sys
 
+binary_default = 'clang-format'
 
-# Change this to the full path if clang-format is not on the path.
-binary = 'clang-format'
-
-
 def main():
   parser = argparse.ArgumentParser(description=
'Reformat changed lines in diff. Without -i 
'
@@ -60,6 +57,11 @@
   '-style',
   help=
   'formatting style to apply (LLVM, Google, Chromium, Mozilla, WebKit)')
+  parser.add_argument(
+  '-binary',
+  default=binary_default,
+  help=
+  'location of binary to use for clang-format')
   args = parser.parse_args()
 
   # Extract changed lines for each file.
@@ -95,7 +97,7 @@
   for filename, lines in lines_by_file.iteritems():
 if args.i and args.verbose:
   print 'Formatting', filename
-command = [binary, filename]
+command = [args.binary, filename]
 if args.i:
   command.append('-i')
 if args.sort_includes:


Index: clang-format-diff.py
===
--- clang-format-diff.py
+++ clang-format-diff.py
@@ -30,11 +30,8 @@
 import StringIO
 import sys
 
+binary_default = 'clang-format'
 
-# Change this to the full path if clang-format is not on the path.
-binary = 'clang-format'
-
-
 def main():
   parser = argparse.ArgumentParser(description=
'Reformat changed lines in diff. Without -i '
@@ -60,6 +57,11 @@
   '-style',
   help=
   'formatting style to apply (LLVM, Google, Chromium, Mozilla, WebKit)')
+  parser.add_argument(
+  '-binary',
+  default=binary_default,
+  help=
+  'location of binary to use for clang-format')
   args = parser.parse_args()
 
   # Extract changed lines for each file.
@@ -95,7 +97,7 @@
   for filename, lines in lines_by_file.iteritems():
 if args.i and args.verbose:
   print 'Formatting', filename
-command = [binary, filename]
+command = [args.binary, filename]
 if args.i:
   command.append('-i')
 if args.sort_includes:
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang-tools-extra] r258327 - Ensure the lit.site.cfg and Unit/lit.site.cfg make targets do not use

2016-01-20 Thread Dimitry Andric via cfe-commits
Author: dim
Date: Wed Jan 20 12:53:44 2016
New Revision: 258327

URL: http://llvm.org/viewvc/llvm-project?rev=258327&view=rev
Log:
Ensure the lit.site.cfg and Unit/lit.site.cfg make targets do not use
the same temporary file, otherwise there is a race condition when using
parallel make jobs.

Modified:
clang-tools-extra/trunk/test/Makefile

Modified: clang-tools-extra/trunk/test/Makefile
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/Makefile?rev=258327&r1=258326&r2=258327&view=diff
==
--- clang-tools-extra/trunk/test/Makefile (original)
+++ clang-tools-extra/trunk/test/Makefile Wed Jan 20 12:53:44 2016
@@ -60,12 +60,12 @@ lit.site.cfg: FORCE
 Unit/lit.site.cfg: FORCE
@echo "Making Unit/lit.site.cfg for Clang extra tools..."
@$(MKDIR) $(dir $@)
-   @$(ECHOPATH) s=@LLVM_LIBS_DIR@=$(LibDir)=g >> lit.tmp
-   @$(ECHOPATH) s=@CLANG_TOOLS_BINARY_DIR@=$(PROJ_OBJ_DIR)/..=g >> lit.tmp
-   @$(ECHOPATH) s=@TARGET_TRIPLE@=$(TARGET_TRIPLE)=g >> lit.tmp
-   @$(ECHOPATH) s=@CLANG_TOOLS_SOURCE_DIR@=$(PROJ_SRC_DIR)/..=g >> lit.tmp
-   @sed -f lit.tmp $(PROJ_SRC_DIR)/Unit/lit.site.cfg.in > $@
-   @-rm -f lit.tmp
+   @$(ECHOPATH) s=@LLVM_LIBS_DIR@=$(LibDir)=g >> unit.tmp
+   @$(ECHOPATH) s=@CLANG_TOOLS_BINARY_DIR@=$(PROJ_OBJ_DIR)/..=g >> unit.tmp
+   @$(ECHOPATH) s=@TARGET_TRIPLE@=$(TARGET_TRIPLE)=g >> unit.tmp
+   @$(ECHOPATH) s=@CLANG_TOOLS_SOURCE_DIR@=$(PROJ_SRC_DIR)/..=g >> unit.tmp
+   @sed -f unit.tmp $(PROJ_SRC_DIR)/Unit/lit.site.cfg.in > $@
+   @-rm -f unit.tmp
 
 clean::
@ find . -name Output | xargs rm -fr


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


r258328 - clang-format-diff: Replace hard-code default for clang-format binary with flag.

2016-01-20 Thread Daniel Jasper via cfe-commits
Author: djasper
Date: Wed Jan 20 12:55:57 2016
New Revision: 258328

URL: http://llvm.org/viewvc/llvm-project?rev=258328&view=rev
Log:
clang-format-diff: Replace hard-code default for clang-format binary with flag.

Patch by Kwasi Mensah, thank you.

Modified:
cfe/trunk/tools/clang-format/clang-format-diff.py

Modified: cfe/trunk/tools/clang-format/clang-format-diff.py
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/clang-format/clang-format-diff.py?rev=258328&r1=258327&r2=258328&view=diff
==
--- cfe/trunk/tools/clang-format/clang-format-diff.py (original)
+++ cfe/trunk/tools/clang-format/clang-format-diff.py Wed Jan 20 12:55:57 2016
@@ -31,10 +31,6 @@ import StringIO
 import sys
 
 
-# Change this to the full path if clang-format is not on the path.
-binary = 'clang-format'
-
-
 def main():
   parser = argparse.ArgumentParser(description=
'Reformat changed lines in diff. Without -i 
'
@@ -56,10 +52,11 @@ def main():
   help='let clang-format sort include blocks')
   parser.add_argument('-v', '--verbose', action='store_true',
   help='be more verbose, ineffective without -i')
-  parser.add_argument(
-  '-style',
-  help=
-  'formatting style to apply (LLVM, Google, Chromium, Mozilla, WebKit)')
+  parser.add_argument('-style',
+  help='formatting style to apply (LLVM, Google, Chromium, 
'
+  'Mozilla, WebKit)')
+  parser.add_argument('-binary', default='clang-format',
+  help='location of binary to use for clang-format')
   args = parser.parse_args()
 
   # Extract changed lines for each file.
@@ -95,7 +92,7 @@ def main():
   for filename, lines in lines_by_file.iteritems():
 if args.i and args.verbose:
   print 'Formatting', filename
-command = [binary, filename]
+command = [args.binary, filename]
 if args.i:
   command.append('-i')
 if args.sort_includes:


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


Re: [PATCH] D16363: Add option to specify clang-format binary for clang-format-diff

2016-01-20 Thread Daniel Jasper via cfe-commits
djasper accepted this revision.
djasper added a comment.
This revision is now accepted and ready to land.

Looks good. Submitted as r258328.


Repository:
  rL LLVM

http://reviews.llvm.org/D16363



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


Re: [clang-tools-extra] r258327 - Ensure the lit.site.cfg and Unit/lit.site.cfg make targets do not use

2016-01-20 Thread Jonathan Roelofs via cfe-commits



On 1/20/16 11:53 AM, Dimitry Andric via cfe-commits wrote:

Author: dim
Date: Wed Jan 20 12:53:44 2016
New Revision: 258327

URL: http://llvm.org/viewvc/llvm-project?rev=258327&view=rev
Log:
Ensure the lit.site.cfg and Unit/lit.site.cfg make targets do not use
the same temporary file, otherwise there is a race condition when using
parallel make jobs.


Seems this should go in 3.8... hans, alexfh?


Jon



Modified:
 clang-tools-extra/trunk/test/Makefile

Modified: clang-tools-extra/trunk/test/Makefile
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/Makefile?rev=258327&r1=258326&r2=258327&view=diff
==
--- clang-tools-extra/trunk/test/Makefile (original)
+++ clang-tools-extra/trunk/test/Makefile Wed Jan 20 12:53:44 2016
@@ -60,12 +60,12 @@ lit.site.cfg: FORCE
  Unit/lit.site.cfg: FORCE
@echo "Making Unit/lit.site.cfg for Clang extra tools..."
@$(MKDIR) $(dir $@)
-   @$(ECHOPATH) s=@LLVM_LIBS_DIR@=$(LibDir)=g >> lit.tmp
-   @$(ECHOPATH) s=@CLANG_TOOLS_BINARY_DIR@=$(PROJ_OBJ_DIR)/..=g >> lit.tmp
-   @$(ECHOPATH) s=@TARGET_TRIPLE@=$(TARGET_TRIPLE)=g >> lit.tmp
-   @$(ECHOPATH) s=@CLANG_TOOLS_SOURCE_DIR@=$(PROJ_SRC_DIR)/..=g >> lit.tmp
-   @sed -f lit.tmp $(PROJ_SRC_DIR)/Unit/lit.site.cfg.in > $@
-   @-rm -f lit.tmp
+   @$(ECHOPATH) s=@LLVM_LIBS_DIR@=$(LibDir)=g >> unit.tmp
+   @$(ECHOPATH) s=@CLANG_TOOLS_BINARY_DIR@=$(PROJ_OBJ_DIR)/..=g >> unit.tmp
+   @$(ECHOPATH) s=@TARGET_TRIPLE@=$(TARGET_TRIPLE)=g >> unit.tmp
+   @$(ECHOPATH) s=@CLANG_TOOLS_SOURCE_DIR@=$(PROJ_SRC_DIR)/..=g >> unit.tmp
+   @sed -f unit.tmp $(PROJ_SRC_DIR)/Unit/lit.site.cfg.in > $@
+   @-rm -f unit.tmp

  clean::
@ find . -name Output | xargs rm -fr


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



--
Jon Roelofs
jonat...@codesourcery.com
CodeSourcery / Mentor Embedded
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D16365: Do not define GXX_RTTI macro for C

2016-01-20 Thread Yunzhong Gao via cfe-commits
ygao created this revision.
ygao added a reviewer: rsmith.
ygao added a subscriber: cfe-commits.
Herald added subscribers: dschuff, jfb.

Hi,
I was looking at the list of pre-defined macros by the new LLVM release and 
noticed that the __GXX_RTTI macro is being defined for both C and C++, and I 
wonder maybe it makes sense to only enable RTTI for C++. What do you think?
Thanks in advance,
- Gao

http://reviews.llvm.org/D16365

Files:
  lib/Frontend/CompilerInvocation.cpp
  test/Preprocessor/init.c

Index: test/Preprocessor/init.c
===
--- test/Preprocessor/init.c
+++ test/Preprocessor/init.c
@@ -57,14 +57,22 @@
 //
 // C99:#define __STDC_VERSION__ 199901L
 // C99:#define __STRICT_ANSI__ 1
+// C99-NOT: __GXX_EXPERIMENTAL_CXX0X__
+// C99-NOT: __GXX_RTTI
+// C99-NOT: __GXX_WEAK__
+// C99-NOT: __cplusplus
 //
 // 
 // RUN: %clang_cc1 -std=c11 -E -dM < /dev/null | FileCheck -check-prefix C11 %s
 //
 // C11:#define __STDC_UTF_16__ 1
 // C11:#define __STDC_UTF_32__ 1
 // C11:#define __STDC_VERSION__ 201112L
 // C11:#define __STRICT_ANSI__ 1
+// C11-NOT: __GXX_EXPERIMENTAL_CXX0X__
+// C11-NOT: __GXX_RTTI
+// C11-NOT: __GXX_WEAK__
+// C11-NOT: __cplusplus
 //
 // 
 // RUN: %clang_cc1 -E -dM < /dev/null | FileCheck -check-prefix COMMON %s
@@ -3286,7 +3294,6 @@
 // MIPSN32BE: #define __GNUC_STDC_INLINE__ 1
 // MIPSN32BE: #define __GNUC__ 4
 // MIPSN32BE: #define __GXX_ABI_VERSION 1002
-// MIPSN32BE: #define __GXX_RTTI 1
 // MIPSN32BE: #define __ILP32__ 1
 // MIPSN32BE: #define __INT16_C_SUFFIX__
 // MIPSN32BE: #define __INT16_FMTd__ "hd"
@@ -3592,7 +3599,6 @@
 // MIPSN32EL: #define __GNUC_STDC_INLINE__ 1
 // MIPSN32EL: #define __GNUC__ 4
 // MIPSN32EL: #define __GXX_ABI_VERSION 1002
-// MIPSN32EL: #define __GXX_RTTI 1
 // MIPSN32EL: #define __ILP32__ 1
 // MIPSN32EL: #define __INT16_C_SUFFIX__
 // MIPSN32EL: #define __INT16_FMTd__ "hd"
@@ -7618,7 +7624,6 @@
 // X86_64-CLOUDABI:#define __GNUC_STDC_INLINE__ 1
 // X86_64-CLOUDABI:#define __GNUC__ 4
 // X86_64-CLOUDABI:#define __GXX_ABI_VERSION 1002
-// X86_64-CLOUDABI:#define __GXX_RTTI 1
 // X86_64-CLOUDABI:#define __INT16_C_SUFFIX__ 
 // X86_64-CLOUDABI:#define __INT16_FMTd__ "hd"
 // X86_64-CLOUDABI:#define __INT16_FMTi__ "hi"
@@ -8483,7 +8488,6 @@
 // WEBASSEMBLY32-NEXT:#define __GNUC_STDC_INLINE__ 1{{$}}
 // WEBASSEMBLY32-NEXT:#define __GNUC__ {{.}}
 // WEBASSEMBLY32-NEXT:#define __GXX_ABI_VERSION 1002{{$}}
-// WEBASSEMBLY32-NEXT:#define __GXX_RTTI 1{{$}}
 // WEBASSEMBLY32-NEXT:#define __ILP32__ 1{{$}}
 // WEBASSEMBLY32-NEXT:#define __INT16_C_SUFFIX__ {{$}}
 // WEBASSEMBLY32-NEXT:#define __INT16_FMTd__ "hd"{{$}}
@@ -8799,7 +8803,6 @@
 // WEBASSEMBLY64-NEXT:#define __GNUC_STDC_INLINE__ 1{{$}}
 // WEBASSEMBLY64-NEXT:#define __GNUC__ {{.}}
 // WEBASSEMBLY64-NEXT:#define __GXX_ABI_VERSION 1002{{$}}
-// WEBASSEMBLY64-NEXT:#define __GXX_RTTI 1{{$}}
 // WEBASSEMBLY64-NOT:#define __ILP32__
 // WEBASSEMBLY64-NEXT:#define __INT16_C_SUFFIX__ {{$}}
 // WEBASSEMBLY64-NEXT:#define __INT16_FMTd__ "hd"{{$}}
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -1666,7 +1666,7 @@
   Opts.SjLjExceptions = Args.hasArg(OPT_fsjlj_exceptions);
   Opts.TraditionalCPP = Args.hasArg(OPT_traditional_cpp);
 
-  Opts.RTTI = !Args.hasArg(OPT_fno_rtti);
+  Opts.RTTI = Opts.CPlusPlus && !Args.hasArg(OPT_fno_rtti);
   Opts.RTTIData = Opts.RTTI && !Args.hasArg(OPT_fno_rtti_data);
   Opts.Blocks = Args.hasArg(OPT_fblocks);
   Opts.BlocksRuntimeOptional = Args.hasArg(OPT_fblocks_runtime_optional);


Index: test/Preprocessor/init.c
===
--- test/Preprocessor/init.c
+++ test/Preprocessor/init.c
@@ -57,14 +57,22 @@
 //
 // C99:#define __STDC_VERSION__ 199901L
 // C99:#define __STRICT_ANSI__ 1
+// C99-NOT: __GXX_EXPERIMENTAL_CXX0X__
+// C99-NOT: __GXX_RTTI
+// C99-NOT: __GXX_WEAK__
+// C99-NOT: __cplusplus
 //
 // 
 // RUN: %clang_cc1 -std=c11 -E -dM < /dev/null | FileCheck -check-prefix C11 %s
 //
 // C11:#define __STDC_UTF_16__ 1
 // C11:#define __STDC_UTF_32__ 1
 // C11:#define __STDC_VERSION__ 201112L
 // C11:#define __STRICT_ANSI__ 1
+// C11-NOT: __GXX_EXPERIMENTAL_CXX0X__
+// C11-NOT: __GXX_RTTI
+// C11-NOT: __GXX_WEAK__
+// C11-NOT: __cplusplus
 //
 // 
 // RUN: %clang_cc1 -E -dM < /dev/null | FileCheck -check-prefix COMMON %s
@@ -3286,7 +3294,6 @@
 // MIPSN32BE: #define __GNUC_STDC_INLINE__ 1
 // MIPSN32BE: #define __GNUC__ 4
 // MIPSN32BE: #define __GXX_ABI_VERSION 1002
-// MIPSN32BE: #define __GXX_RTTI 1
 // MIPSN32BE: #define __ILP32__ 1
 // MIPSN32BE: #define __INT16_C_SUFFIX__
 // MIPSN32BE: #define __INT16_FMTd__ "hd"
@@ -3592,7 +3599,6 @@
 // MIPSN32EL: #define __GNUC_STDC_INLINE__ 1
 // MIPSN32EL: #define __GNUC__ 4
 // MIPSN32EL: #define __GXX_ABI_VERSION 1002
-// MIPSN32EL: #define __GXX_RTTI 1
 // MIPSN32EL: #define __ILP32

Re: [PATCH] D15173: [Preprocessor] Fix assertion in AnnotatePreviousCachedTokens

2016-01-20 Thread Bruno Cardoso Lopes via cfe-commits
bruno updated this revision to Diff 45421.
bruno added a comment.

Update patch after Richard comments


http://reviews.llvm.org/D15173

Files:
  include/clang/Lex/Preprocessor.h
  lib/Lex/PPCaching.cpp
  lib/Parse/ParseTemplate.cpp
  test/Parser/objcxx11-protocol-in-template.mm

Index: test/Parser/objcxx11-protocol-in-template.mm
===
--- test/Parser/objcxx11-protocol-in-template.mm
+++ test/Parser/objcxx11-protocol-in-template.mm
@@ -8,3 +8,11 @@
 
 vector> v;
 vector>> v2;
+
+@protocol PA;
+@protocol PB;
+
+@class NSArray;
+typedef int some_t;
+
+id FA(NSArray> *h, some_t group);
Index: lib/Parse/ParseTemplate.cpp
===
--- lib/Parse/ParseTemplate.cpp
+++ lib/Parse/ParseTemplate.cpp
@@ -827,6 +827,7 @@
   }
 
   // Strip the initial '>' from the token.
+  Token PrevTok = Tok;
   if (RemainingToken == tok::equal && Next.is(tok::equal) &&
   areTokensAdjacent(Tok, Next)) {
 // Join two adjacent '=' tokens into one, for cases like:
@@ -843,6 +844,17 @@
  PP.getSourceManager(),
  getLangOpts()));
 
+  // The advance from '>>' to '>' in a ObjectiveC template argument list needs
+  // to be properly reflected in the token cache to allow correct interaction
+  // between annotation and backtracking.
+  if (ObjCGenericList && PrevTok.getKind() == tok::greatergreater &&
+  RemainingToken == tok::greater && PP.IsPreviousCachedToken(PrevTok)) {
+PrevTok.setKind(RemainingToken);
+PrevTok.setLength(1);
+SmallVector NewToks = {PrevTok, Tok};
+PP.ReplacePreviousCachedToken(NewToks);
+  }
+
   if (!ConsumeLastToken) {
 // Since we're not supposed to consume the '>' token, we need to push
 // this token and revert the current token back to the '>'.
Index: lib/Lex/PPCaching.cpp
===
--- lib/Lex/PPCaching.cpp
+++ lib/Lex/PPCaching.cpp
@@ -116,3 +116,27 @@
 }
   }
 }
+
+bool Preprocessor::IsPreviousCachedToken(const Token &Tok) const {
+  assert(CachedLexPos != 0 && "Expected to have some cached tokens");
+  const Token LastCachedTok = CachedTokens[CachedLexPos - 1];
+
+  if (LastCachedTok.getKind() != Tok.getKind())
+return false;
+
+  int RelOffset = 0;
+  if ((!getSourceManager().isInSameSLocAddrSpace(
+  Tok.getLocation(), getLastCachedTokenLocation(), &RelOffset)) ||
+  RelOffset)
+return false;
+
+  return true;
+}
+
+void Preprocessor::ReplacePreviousCachedToken(SmallVectorImpl &NewToks) 
{
+  assert(CachedLexPos != 0 && "Expected to have some cached tokens");
+  CachedTokens.insert(CachedTokens.begin() + CachedLexPos - 1, NewToks.begin(),
+  NewToks.end());
+  CachedTokens.erase(CachedTokens.begin() + CachedLexPos - 1 + NewToks.size());
+  CachedLexPos += NewToks.size() - 1;
+}
Index: include/clang/Lex/Preprocessor.h
===
--- include/clang/Lex/Preprocessor.h
+++ include/clang/Lex/Preprocessor.h
@@ -1185,6 +1185,17 @@
 return CachedTokens[CachedLexPos-1].getLastLoc();
   }
 
+  /// \brief Whether \p Tok is the most recent token (`CachedLexPos - 1`) in
+  /// CachedTokens.
+  bool IsPreviousCachedToken(const Token &Tok) const;
+
+  /// \brief Replace token in `CachedLexPos - 1` in CachedTokens by the tokens
+  /// in \p NewToks.
+  ///
+  /// Useful when a token needs to be split in smaller ones and CachedTokens
+  /// most recent token must to be updated to reflect that.
+  void ReplacePreviousCachedToken(SmallVectorImpl &NewToks);
+
   /// \brief Replace the last token with an annotation token.
   ///
   /// Like AnnotateCachedTokens(), this routine replaces an


Index: test/Parser/objcxx11-protocol-in-template.mm
===
--- test/Parser/objcxx11-protocol-in-template.mm
+++ test/Parser/objcxx11-protocol-in-template.mm
@@ -8,3 +8,11 @@
 
 vector> v;
 vector>> v2;
+
+@protocol PA;
+@protocol PB;
+
+@class NSArray;
+typedef int some_t;
+
+id FA(NSArray> *h, some_t group);
Index: lib/Parse/ParseTemplate.cpp
===
--- lib/Parse/ParseTemplate.cpp
+++ lib/Parse/ParseTemplate.cpp
@@ -827,6 +827,7 @@
   }
 
   // Strip the initial '>' from the token.
+  Token PrevTok = Tok;
   if (RemainingToken == tok::equal && Next.is(tok::equal) &&
   areTokensAdjacent(Tok, Next)) {
 // Join two adjacent '=' tokens into one, for cases like:
@@ -843,6 +844,17 @@
  PP.getSourceManager(),
  getLangOpts()));
 
+  // The advance from '>>' to '>' in a ObjectiveC template argument list needs
+  // to be properly reflected in the token cache to allow correct interaction
+  // between annotation and ba

Re: [PATCH] D15599: [CodeGen] Fix a crash that occurs when attribute "naked" is attached to a c++ member function

2016-01-20 Thread Manman Ren via cfe-commits
manmanren added a subscriber: manmanren.
manmanren added a comment.

Thanks for working on this! A few comments inline.

Manman



Comment at: lib/CodeGen/CodeGenFunction.cpp:1962
@@ +1961,3 @@
+for (auto *U : I->users())
+  InstrsToRemove.push_back(cast(U));
+

Do we need to check if the user has been erased? I am not sure if the same 
instruction can be pushed multiple times into InstrsToRemove.


Comment at: lib/CodeGen/CodeGenFunction.cpp:1979
@@ +1978,3 @@
+  if (auto *T = EntryBB->getTerminator())
+T->eraseFromParent();
+

Is it possible that T has been erased in the above?


http://reviews.llvm.org/D15599



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


Re: [PATCH] D15363: [UBSan] Implement runtime suppressions (PR25066).

2016-01-20 Thread Nico Weber via cfe-commits
thakis added a comment.

After some more debugging, the only thing in this test that's still faiilng on 
Windows is the "unsigned-integer-overflow:do_overflow" suppression -- when 
llvm-symbolizer gets symbols from PDBs it currently requires the DIA SDK. If 
that's not found at cmake time, then llvm-symbolizer silently can't symbolize 
executables with pdb debug info.

The test should probably have some "REQUIRES: symbols" thingie. (I'll also fix 
llvm not finding the DIA SDK in our build setup, but the test will still fail 
for others who don't have that.)


Repository:
  rL LLVM

http://reviews.llvm.org/D15363



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


r258341 - Register the isCopyAssignmentOperator AST matcher so that it can be used dynamically.

2016-01-20 Thread Aaron Ballman via cfe-commits
Author: aaronballman
Date: Wed Jan 20 14:47:58 2016
New Revision: 258341

URL: http://llvm.org/viewvc/llvm-project?rev=258341&view=rev
Log:
Register the isCopyAssignmentOperator AST matcher so that it can be used 
dynamically.

Path by Jonathan Coe.

Modified:
cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp

Modified: cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp?rev=258341&r1=258340&r2=258341&view=diff
==
--- cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp (original)
+++ cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp Wed Jan 20 14:47:58 2016
@@ -268,6 +268,7 @@ RegistryMaps::RegistryMaps() {
   REGISTER_MATCHER(isClass);
   REGISTER_MATCHER(isConst);
   REGISTER_MATCHER(isConstQualified);
+  REGISTER_MATCHER(isCopyAssignmentOperator);
   REGISTER_MATCHER(isCopyConstructor);
   REGISTER_MATCHER(isDefaultConstructor);
   REGISTER_MATCHER(isDefaulted);


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


Re: [PATCH] D16115: [test-suite] Add ClangAnalyzerBenchmarks directory to test-suite repository

2016-01-20 Thread Devin Coughlin via cfe-commits
dcoughlin closed this revision.
dcoughlin added a comment.

Committed in r258336.


http://reviews.llvm.org/D16115



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


Re: [clang-tools-extra] r258327 - Ensure the lit.site.cfg and Unit/lit.site.cfg make targets do not use

2016-01-20 Thread Hans Wennborg via cfe-commits
On Wed, Jan 20, 2016 at 11:00 AM, Jonathan Roelofs
 wrote:
>
>
> On 1/20/16 11:53 AM, Dimitry Andric via cfe-commits wrote:
>>
>> Author: dim
>> Date: Wed Jan 20 12:53:44 2016
>> New Revision: 258327
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=258327&view=rev
>> Log:
>> Ensure the lit.site.cfg and Unit/lit.site.cfg make targets do not use
>> the same temporary file, otherwise there is a race condition when using
>> parallel make jobs.
>
>
> Seems this should go in 3.8... hans, alexfh?

Yes, merged in r258345.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [PATCH] D15624: Add iOS/watchOS/tvOS support for ASan (clang part)

2016-01-20 Thread Anna Zaks via cfe-commits
zaks.anna updated this revision to Diff 45437.
zaks.anna added a comment.

Refactor the code to address Samsonov's review.


http://reviews.llvm.org/D15624

Files:
  lib/Driver/ToolChains.cpp
  lib/Driver/ToolChains.h
  test/Driver/fsanitize.c

Index: test/Driver/fsanitize.c
===
--- test/Driver/fsanitize.c
+++ test/Driver/fsanitize.c
@@ -230,7 +230,7 @@
 // CHECK-VPTR-DARWIN-NEW: -fsanitize=alignment,vptr
 
 // RUN: %clang -target armv7-apple-ios7 -miphoneos-version-min=7.0 
-fsanitize=address %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-ASAN-IOS
-// CHECK-ASAN-IOS: unsupported option '-fsanitize=address' for target 
'arm-apple-ios7'
+// CHECK-ASAN-IOS: -fsanitize=address
 
 // RUN: %clang -target i386-pc-openbsd -fsanitize=address %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-ASAN-OPENBSD
 // CHECK-ASAN-OPENBSD: unsupported option '-fsanitize=address' for target 
'i386-pc-openbsd'
Index: lib/Driver/ToolChains.h
===
--- lib/Driver/ToolChains.h
+++ lib/Driver/ToolChains.h
@@ -496,6 +496,8 @@
 return TargetVersion < VersionTuple(V0, V1, V2);
   }
 
+  StringRef getOSLibraryNameSuffix() const;
+
 public:
   /// }
   /// @name ToolChain Implementation
Index: lib/Driver/ToolChains.cpp
===
--- lib/Driver/ToolChains.cpp
+++ lib/Driver/ToolChains.cpp
@@ -319,6 +319,25 @@
   }
 }
 
+StringRef Darwin::getOSLibraryNameSuffix() const {
+  if (isTargetMacOS())
+return "osx";
+  if (isTargetWatchOSSimulator())
+return "watchossim";
+  if (isTargetWatchOS())
+return "watchos";
+  if (isTargetIOSSimulator())
+return "iossim";
+  if (isTargetIPhoneOS())
+return "ios";
+  if (isTargetTvOSSimulator())
+return "tvossim";
+  if (isTargetTvOS())
+return "tvos";
+
+  llvm_unreachable("Unsuported OS");
+}
+
 void Darwin::addProfileRTLibs(const ArgList &Args,
   ArgStringList &CmdArgs) const {
   if (!needsProfileRT(Args)) return;
@@ -363,12 +382,11 @@
 // Sanitizer runtime libraries requires C++.
 AddCXXStdlibLibArgs(Args, CmdArgs);
   }
-  // ASan is not supported on watchOS.
-  assert(isTargetMacOS() || isTargetIOSSimulator());
-  StringRef OS = isTargetMacOS() ? "osx" : "iossim";
+
   AddLinkRuntimeLib(
   Args, CmdArgs,
-  (Twine("libclang_rt.") + Sanitizer + "_" + OS + "_dynamic.dylib").str(),
+  (Twine("libclang_rt.") + Sanitizer + "_" +
+   getOSLibraryNameSuffix() + "_dynamic.dylib").str(),
   /*AlwaysLink*/ true, /*IsEmbedded*/ false,
   /*AddRPath*/ true);
 
@@ -1220,8 +1238,7 @@
 
 SanitizerMask Darwin::getSupportedSanitizers() const {
   SanitizerMask Res = ToolChain::getSupportedSanitizers();
-  if (isTargetMacOS() || isTargetIOSSimulator())
-Res |= SanitizerKind::Address;
+  Res |= SanitizerKind::Address;
   if (isTargetMacOS()) {
 if (!isMacosxVersionLT(10, 9))
   Res |= SanitizerKind::Vptr;


Index: test/Driver/fsanitize.c
===
--- test/Driver/fsanitize.c
+++ test/Driver/fsanitize.c
@@ -230,7 +230,7 @@
 // CHECK-VPTR-DARWIN-NEW: -fsanitize=alignment,vptr
 
 // RUN: %clang -target armv7-apple-ios7 -miphoneos-version-min=7.0 -fsanitize=address %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-ASAN-IOS
-// CHECK-ASAN-IOS: unsupported option '-fsanitize=address' for target 'arm-apple-ios7'
+// CHECK-ASAN-IOS: -fsanitize=address
 
 // RUN: %clang -target i386-pc-openbsd -fsanitize=address %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-ASAN-OPENBSD
 // CHECK-ASAN-OPENBSD: unsupported option '-fsanitize=address' for target 'i386-pc-openbsd'
Index: lib/Driver/ToolChains.h
===
--- lib/Driver/ToolChains.h
+++ lib/Driver/ToolChains.h
@@ -496,6 +496,8 @@
 return TargetVersion < VersionTuple(V0, V1, V2);
   }
 
+  StringRef getOSLibraryNameSuffix() const;
+
 public:
   /// }
   /// @name ToolChain Implementation
Index: lib/Driver/ToolChains.cpp
===
--- lib/Driver/ToolChains.cpp
+++ lib/Driver/ToolChains.cpp
@@ -319,6 +319,25 @@
   }
 }
 
+StringRef Darwin::getOSLibraryNameSuffix() const {
+  if (isTargetMacOS())
+return "osx";
+  if (isTargetWatchOSSimulator())
+return "watchossim";
+  if (isTargetWatchOS())
+return "watchos";
+  if (isTargetIOSSimulator())
+return "iossim";
+  if (isTargetIPhoneOS())
+return "ios";
+  if (isTargetTvOSSimulator())
+return "tvossim";
+  if (isTargetTvOS())
+return "tvos";
+
+  llvm_unreachable("Unsuported OS");
+}
+
 void Darwin::addProfileRTLibs(const ArgList &Args,
   ArgStringList &CmdArgs) const {
   if (!needsProfileRT(Args)) return;
@@ -363,12 +382,11 @@
 // Sanitizer runtime libraries requires C++.
 AddCXXStdlibLibArgs(Args, CmdArgs);

Re: [PATCH] D15624: Add iOS/watchOS/tvOS support for ASan (clang part)

2016-01-20 Thread Anna Zaks via cfe-commits
zaks.anna marked an inline comment as done.
zaks.anna added a comment.

I've introduced the helper function. Looks like addProfileRTLibs might be able 
to use it in the future (after support for autoconf is dropped) as well.


http://reviews.llvm.org/D15624



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


Re: [PATCH] D15999: Adding doxygen comments to the LLVM intrinsics (part 2, _wmmintrin_pclmul.h)

2016-01-20 Thread Katya Romanova via cfe-commits
kromanova added a comment.

In http://reviews.llvm.org/D15999#330794, @silvas wrote:

> This may sound stupid, but: can you benchmark the time it takes to build some 
> project (that actually uses intrinsics in most translation units, e.g. a 
> game) with the headers w/ and w/o the doxygen comments to check that all the 
> extra comment skipping doesn't affect compilation time? I.e. run your script 
> to add the comments for "all" the intrinsic headers (similar to what you 
> expect the final state to be after all these patches) and test the build time 
> of a game (and compare with the unmodified headers).


This makes sense. I can do this, though it might take a couple of days, since I 
don't have a setup for a game build.
I suspect that that we shouldn't use an application/game that is using 
precompiled headers. Any other limitation should be imposed on the beanchmark?

> Also, can you post a patch that changes "all" the headers to have doxygen 
> comments like you intend, so that others can test and verify?


Yes, I'll do this. However, there are a couple of things that the people should 
be aware:
(a) *only* intrinsics that are supported on PS4 will have doxygen comments. PS4 
documentation is parsed to generate these comments, and it doesn't document the 
intrinsics that are not supported on PS4.
(b) the doxygen comments for the rest (not submitted upstream) headers files 
might have some problems (typos, incorrect parameter types, bugs in the 
description, etc). The tool that generates the comments might have some 
glitches too. Most of this things get fixed after the manual review that I do 
before I submit the Phabricator code review. So, please don't assume that this 
is the final version of the header files with doxygen comments.


Repository:
  rL LLVM

http://reviews.llvm.org/D15999



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


Re: [PATCH] D16308: clang-tidy Enhance readability-simplify-boolean-expr check to handle implicit conversions of integral types to bool and member pointers

2016-01-20 Thread Richard via cfe-commits
LegalizeAdulthood added inline comments.


Comment at: docs/clang-tidy/checks/readability-simplify-boolean-expr.rst:59
@@ -56,3 +58,3 @@
 
   4. The conditional return ``if (p) return true; return false;`` has an
  implicit conversion of a pointer to ``bool`` and becomes

aaron.ballman wrote:
> LegalizeAdulthood wrote:
> > aaron.ballman wrote:
> > > Update for member pointers.
> > Do I really need to explicitly say member pointer as well?  It seems 
> > redundant.
> > 
> > I didn't update it because a pointer to a member is a pointer.  When used 
> > as an implicit conversion to `bool`, the syntax is no different for a plain 
> > pointer than for a member pointer.  If the syntax were different, I could 
> > see your point.
> > 
> A pointer to a member is not a pointer according to the language standard, 
> and that's why it may not be a bad idea to call it out explicitly as being 
> supported. From [basic.compound]p3, "Except for pointers to static members, 
> text referring to “pointers” does not apply to pointers to members." I do 
> take your point about the syntax of the implicit conversion being the same, 
> but it would be nice to be explicit about what we support. I would just 
> change it to say "...implicit conversion of a pointer (or pointer to member) 
> to ``bool``..."
Meh.  I don't mind doing that, but the standard gets hyper-anal about how 
everything is called because without it the standard would be much more 
ambiguous.  I certainly don't want clang (or clang-tidy) documentation to start 
reading like the C++ Standard.  In other words, while such specific language is 
necessary in the standard, I don't think anyone is going to be confused by how 
I originally worded it.


http://reviews.llvm.org/D16308



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


Re: [PATCH] D15506: [ASTMatchers] Allow hasName() to look through inline namespaces

2016-01-20 Thread Samuel Benzaquen via cfe-commits
sbenza updated this revision to Diff 45438.
sbenza added a comment.

Rename functions.


http://reviews.llvm.org/D15506

Files:
  include/clang/ASTMatchers/ASTMatchersInternal.h
  lib/ASTMatchers/ASTMatchersInternal.cpp
  unittests/ASTMatchers/ASTMatchersTest.cpp

Index: unittests/ASTMatchers/ASTMatchersTest.cpp
===
--- unittests/ASTMatchers/ASTMatchersTest.cpp
+++ unittests/ASTMatchers/ASTMatchersTest.cpp
@@ -2788,6 +2788,52 @@
  recordDecl(hasName("A+B::C";
 }
 
+TEST(Matcher, HasNameSupportsInlinedNamespaces) {
+  std::string code = "namespace a { inline namespace b { class C; } }";
+  EXPECT_TRUE(matches(code, recordDecl(hasName("a::b::C";
+  EXPECT_TRUE(matches(code, recordDecl(hasName("a::C";
+  EXPECT_TRUE(matches(code, recordDecl(hasName("::a::b::C";
+  EXPECT_TRUE(matches(code, recordDecl(hasName("::a::C";
+}
+
+TEST(Matcher, HasNameSupportsAnonymousNamespaces) {
+  std::string code = "namespace a { namespace { class C; } }";
+  EXPECT_TRUE(
+  matches(code, recordDecl(hasName("a::(anonymous namespace)::C";
+  EXPECT_TRUE(matches(code, recordDecl(hasName("a::C";
+  EXPECT_TRUE(
+  matches(code, recordDecl(hasName("::a::(anonymous namespace)::C";
+  EXPECT_TRUE(matches(code, recordDecl(hasName("::a::C";
+}
+
+TEST(Matcher, HasNameSupportsAnonymousOuterClasses) {
+  EXPECT_TRUE(matches("class A { class { class C; } x; };",
+  recordDecl(hasName("A::(anonymous class)::C";
+  EXPECT_TRUE(matches("class A { class { class C; } x; };",
+  recordDecl(hasName("::A::(anonymous class)::C";
+  EXPECT_FALSE(matches("class A { class { class C; } x; };",
+   recordDecl(hasName("::A::C";
+  EXPECT_TRUE(matches("class A { struct { class C; } x; };",
+  recordDecl(hasName("A::(anonymous struct)::C";
+  EXPECT_TRUE(matches("class A { struct { class C; } x; };",
+  recordDecl(hasName("::A::(anonymous struct)::C";
+  EXPECT_FALSE(matches("class A { struct { class C; } x; };",
+   recordDecl(hasName("::A::C";
+}
+
+TEST(Matcher, HasNameSupportsFunctionScope) {
+  std::string code =
+  "namespace a { void F(int a) { struct S { int m; }; int i; } }";
+  EXPECT_TRUE(matches(code, varDecl(hasName("i";
+  EXPECT_FALSE(matches(code, varDecl(hasName("F()::i";
+
+  EXPECT_TRUE(matches(code, fieldDecl(hasName("m";
+  EXPECT_TRUE(matches(code, fieldDecl(hasName("S::m";
+  EXPECT_TRUE(matches(code, fieldDecl(hasName("F(int)::S::m";
+  EXPECT_TRUE(matches(code, fieldDecl(hasName("a::F(int)::S::m";
+  EXPECT_TRUE(matches(code, fieldDecl(hasName("::a::F(int)::S::m";
+}
+
 TEST(Matcher, IsDefinition) {
   DeclarationMatcher DefinitionOfClassA =
   recordDecl(hasName("A"), isDefinition());
Index: lib/ASTMatchers/ASTMatchersInternal.cpp
===
--- lib/ASTMatchers/ASTMatchersInternal.cpp
+++ lib/ASTMatchers/ASTMatchersInternal.cpp
@@ -298,45 +298,149 @@
   assert(!Name.empty());
 }
 
-bool HasNameMatcher::matchesNodeUnqualified(const NamedDecl &Node) const {
-  assert(UseUnqualifiedMatch);
-  if (Node.getIdentifier()) {
-// Simple name.
-return Name == Node.getName();
+namespace {
+
+bool ConsumeNameSuffix(StringRef &FullName, StringRef Suffix) {
+  StringRef Name = FullName;
+  if (!Name.endswith(Suffix))
+return false;
+  Name = Name.drop_back(Suffix.size());
+  if (!Name.empty()) {
+if (!Name.endswith("::"))
+  return false;
+Name = Name.drop_back(2);
   }
+  FullName = Name;
+  return true;
+}
+
+bool ConsumeNodeName(StringRef &Name, const NamedDecl &Node) {
+  // Simple name.
+  if (Node.getIdentifier())
+return ConsumeNameSuffix(Name, Node.getName());
+
   if (Node.getDeclName()) {
 // Name needs to be constructed.
 llvm::SmallString<128> NodeName;
 llvm::raw_svector_ostream OS(NodeName);
 Node.printName(OS);
-return Name == OS.str();
+return ConsumeNameSuffix(Name, OS.str());
   }
-  return false;
+
+  return ConsumeNameSuffix(Name, "(anonymous)");
 }
 
-bool HasNameMatcher::matchesNodeFull(const NamedDecl &Node) const {
-  llvm::SmallString<128> NodeName = StringRef("::");
-  llvm::raw_svector_ostream OS(NodeName);
-  Node.printQualifiedName(OS);
-  const StringRef FullName = OS.str();
+}  // namespace
+
+bool HasNameMatcher::matchesNodeUnqualified(const NamedDecl &Node) const {
+  assert(UseUnqualifiedMatch);
+  StringRef NodeName = Name;
+  return ConsumeNodeName(NodeName, Node) && NodeName.empty();
+}
+
+bool HasNameMatcher::matchesNodeFullFast(const NamedDecl &Node) const {
+  // This function is copied and adapted from NamedDecl::printQualifiedName()
+  // By matching each part individually we optimize in a couple of ways:
+  //  - We can exit early on the first failure.
+  //  - We can skip inline/anonymous namesp

Re: [PATCH] D15506: [ASTMatchers] Allow hasName() to look through inline namespaces

2016-01-20 Thread Samuel Benzaquen via cfe-commits
sbenza added inline comments.


Comment at: lib/ASTMatchers/ASTMatchersInternal.cpp:351
@@ +350,3 @@
+
+  // First, match the name.
+  if (!MatchNodeName(Pattern, Node))

klimek wrote:
> Perhaps comment that Pattern will be changed to the prefix, so it's clear 
> afterwards.
> (I wonder whether returning a tuple might be slightly easier to understand 
> here)
Renamed from Match to Consume. Is that better?


http://reviews.llvm.org/D15506



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


Re: [PATCH] D8940: Clang changes for indirect call target profiling

2016-01-20 Thread David Li via cfe-commits
davidxl added inline comments.


Comment at: lib/CodeGen/CodeGenPGO.cpp:768
@@ +767,3 @@
+  llvm::IndexedInstrProfReader *PGOReader = CGM.getPGOReader();
+  if (!InstrumentValueSites && !PGOReader)
+return;

&& --> ||


Comment at: lib/CodeGen/CodeGenPGO.cpp:782
@@ +781,3 @@
+Builder.CreateCall(
+  CGM.getIntrinsic(llvm::Intrinsic::instrprof_value_profile), Args);
+  }

add return here?


Comment at: lib/CodeGen/CodeGenPGO.cpp:813
@@ +812,3 @@
+  Vals.push_back(MDHelper.createString(
+  getRawFuncName(Symtab.getFuncName(VD[I].Value;
+  Vals.push_back(MDHelper.createConstant(

Why not pushing the mapping to string to the user (transformation)? Annotating 
IR with long strings can bloat the IR size a bit. There is also a symtab create 
interface added which takes module as input which is way more efficient (do not 
need to walk through the whole profiile data)


http://reviews.llvm.org/D8940



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


Re: [PATCH] D16310: new clang-tidy checker misc-long-cast

2016-01-20 Thread Richard via cfe-commits
LegalizeAdulthood added a comment.

If you state what the check does, then

In http://reviews.llvm.org/D16310#331054, @danielmarjamaki wrote:

> In http://reviews.llvm.org/D16310#330367, @LegalizeAdulthood wrote:
>
> > Why not supply a fixit that removes the cast?
>
>
> I am skeptic. There are different valid fixes.
>
> Example code:
>
>   l = (long)(a*1000);
>   
>
> Fix1:
>
>   l = ((long)a * 1000);
>   
>
> Fix2:
>
>   l = (a * (long)1000);
>   
>
> Fix3:
>
>   l = (a * 1000L);


The way I see it, the check is complaining about the pointless cast and 
pointing the finger at the beginning of the cast.  To me, my expectation is 
that the suggested fix is none of the options you gave but instead:

  l = (a*1000);

In other words, the cast is superfluous for the code as written.  Omitting the 
cast directly expresses the code as written without unnecessary casting.  
Because the check can't know your intent, it hints that you may have intended 
something else, but for what was written, this **is** the semantics.

If we want to get into detecting numeric overflow, then we're talking some kind 
of run-time assisted check and it's beyond the scope of clang-tidy.

Basically, I look at this unnecessary cast as clutter.  I'm fine with static 
analysis that warns about intermediate expressions possibly overflowing when 
assigned to a "larger" type, but to me that sounds like something for the 
static analyzer and not for tidy.

In other words, I think of clang-tidy as a refactoring tool, not a static 
analysis tool.


Repository:
  rL LLVM

http://reviews.llvm.org/D16310



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


[PATCH] D16372: [CUDA] Make printf work.

2016-01-20 Thread Justin Lebar via cfe-commits
jlebar created this revision.
jlebar added a reviewer: tra.
jlebar added subscribers: jhen, echristo, cfe-commits.

The code in CGCUDACall is largely based on a patch written by Eli
Bendersky:
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20140324/210218.html

That patch implemented an LLVM pass lowering printf to vprintf; this
one does something similar, but in Clang codegen.

http://reviews.llvm.org/D16372

Files:
  lib/CodeGen/CGBuiltin.cpp
  lib/CodeGen/CGCUDACall.cpp
  lib/CodeGen/CMakeLists.txt
  lib/CodeGen/CodeGenFunction.h
  lib/Headers/__clang_cuda_runtime_wrapper.h
  test/CodeGenCUDA/Inputs/cuda.h
  test/CodeGenCUDA/printf.cu

Index: test/CodeGenCUDA/printf.cu
===
--- /dev/null
+++ test/CodeGenCUDA/printf.cu
@@ -0,0 +1,48 @@
+// REQUIRES: x86-registered-target
+// REQUIRES: nvptx-registered-target
+
+// RUN: %clang_cc1 -triple nvptx64-nvidia-cuda -fcuda-is-device -emit-llvm \
+// RUN:   -o - %s | FileCheck %s
+
+#include "Inputs/cuda.h"
+
+extern "C" __device__ int vprintf(const char*, const char*);
+
+// Check a simple call to printf end-to-end.
+__device__ int CheckSimple() {
+  // CHECK: [[FMT:%[0-9]+]] = load{{.*}}%fmt
+  const char* fmt = "%d";
+  // CHECK: [[BUF:%[a-zA-Z0-9_]+]] = alloca i8, i32 4, align 4
+  // CHECK: [[PTR:%[0-9]+]] = getelementptr i8, i8* [[BUF]], i32 0
+  // CHECK: [[CAST:%[0-9]+]] = bitcast i8* [[PTR]] to i32*
+  // CHECK: store i32 42, i32* [[CAST]], align 4
+  // CHECK: [[RET:%[0-9]+]] = call i32 @vprintf(i8* [[FMT]], i8* [[BUF]])
+  // CHECK: ret i32 [[RET]]
+  return printf(fmt, 42);
+}
+
+// Check that the args' types are promoted correctly when we call printf.
+__device__ void CheckTypes() {
+  // CHECK: alloca {{.*}} align 8
+  // CHECK: getelementptr {{.*}} i32 0
+  // CHECK: bitcast {{.*}} to i32*
+  // CHECK: getelementptr {{.*}} i32 4
+  // CHECK: bitcast {{.*}} to i32*
+  // CHECK: getelementptr {{.*}} i32 8
+  // CHECK: bitcast {{.*}} to double*
+  // CHECK: getelementptr {{.*}} i32 16
+  // CHECK: bitcast {{.*}} to double*
+  printf("%d %d %f %f", (char)1, (short)2, 3.0f, 4.0);
+}
+
+// Check that the args are aligned properly in the buffer.
+__device__ void CheckAlign() {
+  // CHECK: alloca i8, i32 40, align 8
+  // CHECK: getelementptr {{.*}} i32 0
+  // CHECK: getelementptr {{.*}} i32 8
+  // CHECK: getelementptr {{.*}} i32 16
+  // CHECK: getelementptr {{.*}} i32 20
+  // CHECK: getelementptr {{.*}} i32 24
+  // CHECK: getelementptr {{.*}} i32 32
+  printf("%d %f %d %d %d %lld", 1, 2.0, 3, 4, 5, (long long)6);
+}
Index: test/CodeGenCUDA/Inputs/cuda.h
===
--- test/CodeGenCUDA/Inputs/cuda.h
+++ test/CodeGenCUDA/Inputs/cuda.h
@@ -8,6 +8,8 @@
 #define __host__ __attribute__((host))
 #define __shared__ __attribute__((shared))
 #define __launch_bounds__(...) __attribute__((launch_bounds(__VA_ARGS__)))
+#define __device_builtin__ __attribute__((device_builtin))
+#define __cudart_builtin__ __attribute__((cudart_builtin))
 
 struct dim3 {
   unsigned x, y, z;
@@ -18,3 +20,5 @@
 
 int cudaConfigureCall(dim3 gridSize, dim3 blockSize, size_t sharedSize = 0,
   cudaStream_t stream = 0);
+
+extern "C" __device__ __device_builtin__ __cudart_builtin__ int printf(const char*, ...);
Index: lib/Headers/__clang_cuda_runtime_wrapper.h
===
--- lib/Headers/__clang_cuda_runtime_wrapper.h
+++ lib/Headers/__clang_cuda_runtime_wrapper.h
@@ -210,6 +210,11 @@
 static __device__ __attribute__((used)) int __nvvm_reflect_anchor() {
   return __nvvm_reflect("NONE");
 }
+
+// The nvptx vprintf syscall.  This doesn't actually need to be declared, but we
+// declare it so that if someone else declares it with a different signature,
+// we'll throw an error.
+extern "C" __device__ int vprintf(const char*, const char*);
 #endif
 
 #endif // __CUDA__
Index: lib/CodeGen/CodeGenFunction.h
===
--- lib/CodeGen/CodeGenFunction.h
+++ lib/CodeGen/CodeGenFunction.h
@@ -2709,6 +2709,8 @@
   RValue EmitCUDAKernelCallExpr(const CUDAKernelCallExpr *E,
 ReturnValueSlot ReturnValue);
 
+  RValue EmitCUDADevicePrintfCallExpr(const CallExpr *E,
+  ReturnValueSlot ReturnValue);
 
   RValue EmitBuiltinExpr(const FunctionDecl *FD,
  unsigned BuiltinID, const CallExpr *E,
Index: lib/CodeGen/CMakeLists.txt
===
--- lib/CodeGen/CMakeLists.txt
+++ lib/CodeGen/CMakeLists.txt
@@ -32,6 +32,7 @@
   CGAtomic.cpp
   CGBlocks.cpp
   CGBuiltin.cpp
+  CGCUDACall.cpp
   CGCUDANV.cpp
   CGCUDARuntime.cpp
   CGCXX.cpp
Index: lib/CodeGen/CGCUDACall.cpp
===
--- /dev/null
+++ lib/CodeGen/CGCUDACall.cpp
@@ -0,0 +1,131 @@
+//===--

Re: [PATCH] D16310: new clang-tidy checker misc-long-cast

2016-01-20 Thread Richard via cfe-commits
LegalizeAdulthood added inline comments.


Comment at: clang-tidy/misc/LongCastCheck.cpp:43
@@ +42,3 @@
+
+static unsigned getMaxCalculationWidth(ASTContext &C, const Expr *E) {
+  E = E->IgnoreParenImpCasts();

Prefer anonymous namespace over `static` to scope visibility.


Comment at: clang-tidy/misc/LongCastCheck.cpp:97
@@ +96,3 @@
+
+  if (!CastType->isIntegerType() || !SubType->isIntegerType())
+return;

Why don't you check for casting a `float` expression to a `double` or `long 
double`?

Isn't this the exact same issue?

If so, add a test case for casting a `float` expression to `double` and a test 
case for casting a `double` expression to a `long double`.


Comment at: clang-tidy/misc/MiscTidyModule.cpp:61
@@ -59,1 +60,3 @@
+CheckFactories.registerCheck(
+"misc-long-cast");
 CheckFactories.registerCheck(

The documentation describes this check as one that looks for a cast to a 
"bigger type", but the name of the check implies that it only works for casts 
to `long`.

The name of the check should be made more generic to reflect reality.

Perhaps `misc-redundant-cast-to-larger-type` or 
`misc-redundant-bigger-type-cast`?


Comment at: docs/clang-tidy/checks/misc-long-cast.rst:11
@@ +10,3 @@
+
+Example code::
+

Please add an example for another type other than `long`, such as casting a 
`float` expression to a `double`.


Repository:
  rL LLVM

http://reviews.llvm.org/D16310



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


Re: [PATCH] D16372: [CUDA] Make printf work.

2016-01-20 Thread Justin Lebar via cfe-commits
jlebar updated this revision to Diff 45446.
jlebar added a comment.

Remove {} around an if statement.


http://reviews.llvm.org/D16372

Files:
  lib/CodeGen/CGBuiltin.cpp
  lib/CodeGen/CGCUDACall.cpp
  lib/CodeGen/CMakeLists.txt
  lib/CodeGen/CodeGenFunction.h
  lib/Headers/__clang_cuda_runtime_wrapper.h
  test/CodeGenCUDA/Inputs/cuda.h
  test/CodeGenCUDA/printf.cu

Index: test/CodeGenCUDA/printf.cu
===
--- /dev/null
+++ test/CodeGenCUDA/printf.cu
@@ -0,0 +1,48 @@
+// REQUIRES: x86-registered-target
+// REQUIRES: nvptx-registered-target
+
+// RUN: %clang_cc1 -triple nvptx64-nvidia-cuda -fcuda-is-device -emit-llvm \
+// RUN:   -o - %s | FileCheck %s
+
+#include "Inputs/cuda.h"
+
+extern "C" __device__ int vprintf(const char*, const char*);
+
+// Check a simple call to printf end-to-end.
+__device__ int CheckSimple() {
+  // CHECK: [[FMT:%[0-9]+]] = load{{.*}}%fmt
+  const char* fmt = "%d";
+  // CHECK: [[BUF:%[a-zA-Z0-9_]+]] = alloca i8, i32 4, align 4
+  // CHECK: [[PTR:%[0-9]+]] = getelementptr i8, i8* [[BUF]], i32 0
+  // CHECK: [[CAST:%[0-9]+]] = bitcast i8* [[PTR]] to i32*
+  // CHECK: store i32 42, i32* [[CAST]], align 4
+  // CHECK: [[RET:%[0-9]+]] = call i32 @vprintf(i8* [[FMT]], i8* [[BUF]])
+  // CHECK: ret i32 [[RET]]
+  return printf(fmt, 42);
+}
+
+// Check that the args' types are promoted correctly when we call printf.
+__device__ void CheckTypes() {
+  // CHECK: alloca {{.*}} align 8
+  // CHECK: getelementptr {{.*}} i32 0
+  // CHECK: bitcast {{.*}} to i32*
+  // CHECK: getelementptr {{.*}} i32 4
+  // CHECK: bitcast {{.*}} to i32*
+  // CHECK: getelementptr {{.*}} i32 8
+  // CHECK: bitcast {{.*}} to double*
+  // CHECK: getelementptr {{.*}} i32 16
+  // CHECK: bitcast {{.*}} to double*
+  printf("%d %d %f %f", (char)1, (short)2, 3.0f, 4.0);
+}
+
+// Check that the args are aligned properly in the buffer.
+__device__ void CheckAlign() {
+  // CHECK: alloca i8, i32 40, align 8
+  // CHECK: getelementptr {{.*}} i32 0
+  // CHECK: getelementptr {{.*}} i32 8
+  // CHECK: getelementptr {{.*}} i32 16
+  // CHECK: getelementptr {{.*}} i32 20
+  // CHECK: getelementptr {{.*}} i32 24
+  // CHECK: getelementptr {{.*}} i32 32
+  printf("%d %f %d %d %d %lld", 1, 2.0, 3, 4, 5, (long long)6);
+}
Index: test/CodeGenCUDA/Inputs/cuda.h
===
--- test/CodeGenCUDA/Inputs/cuda.h
+++ test/CodeGenCUDA/Inputs/cuda.h
@@ -8,6 +8,8 @@
 #define __host__ __attribute__((host))
 #define __shared__ __attribute__((shared))
 #define __launch_bounds__(...) __attribute__((launch_bounds(__VA_ARGS__)))
+#define __device_builtin__ __attribute__((device_builtin))
+#define __cudart_builtin__ __attribute__((cudart_builtin))
 
 struct dim3 {
   unsigned x, y, z;
@@ -18,3 +20,5 @@
 
 int cudaConfigureCall(dim3 gridSize, dim3 blockSize, size_t sharedSize = 0,
   cudaStream_t stream = 0);
+
+extern "C" __device__ __device_builtin__ __cudart_builtin__ int printf(const char*, ...);
Index: lib/Headers/__clang_cuda_runtime_wrapper.h
===
--- lib/Headers/__clang_cuda_runtime_wrapper.h
+++ lib/Headers/__clang_cuda_runtime_wrapper.h
@@ -210,6 +210,11 @@
 static __device__ __attribute__((used)) int __nvvm_reflect_anchor() {
   return __nvvm_reflect("NONE");
 }
+
+// The nvptx vprintf syscall.  This doesn't actually need to be declared, but we
+// declare it so that if someone else declares it with a different signature,
+// we'll throw an error.
+extern "C" __device__ int vprintf(const char*, const char*);
 #endif
 
 #endif // __CUDA__
Index: lib/CodeGen/CodeGenFunction.h
===
--- lib/CodeGen/CodeGenFunction.h
+++ lib/CodeGen/CodeGenFunction.h
@@ -2709,6 +2709,8 @@
   RValue EmitCUDAKernelCallExpr(const CUDAKernelCallExpr *E,
 ReturnValueSlot ReturnValue);
 
+  RValue EmitCUDADevicePrintfCallExpr(const CallExpr *E,
+  ReturnValueSlot ReturnValue);
 
   RValue EmitBuiltinExpr(const FunctionDecl *FD,
  unsigned BuiltinID, const CallExpr *E,
Index: lib/CodeGen/CMakeLists.txt
===
--- lib/CodeGen/CMakeLists.txt
+++ lib/CodeGen/CMakeLists.txt
@@ -32,6 +32,7 @@
   CGAtomic.cpp
   CGBlocks.cpp
   CGBuiltin.cpp
+  CGCUDACall.cpp
   CGCUDANV.cpp
   CGCUDARuntime.cpp
   CGCXX.cpp
Index: lib/CodeGen/CGCUDACall.cpp
===
--- /dev/null
+++ lib/CodeGen/CGCUDACall.cpp
@@ -0,0 +1,131 @@
+//===- CGCUDACall.cpp - Codegen for special CUDA calls ===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--

Re: [PATCH] D15670: Accept elided commas in macro function arguments for MS compatibility

2016-01-20 Thread Ehsan Akhgari via cfe-commits
Richard: ping?

On Tue, Jan 12, 2016 at 6:41 PM, Reid Kleckner  wrote:

> rnk accepted this revision.
> rnk added a comment.
> This revision is now accepted and ready to land.
>
> Seems reasonable to me, but we should check with Richard.
>
>
> http://reviews.llvm.org/D15670
>
>
>
>


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


Re: [PATCH] D15670: Accept elided commas in macro function arguments for MS compatibility

2016-01-20 Thread Ehsan Akhgari via cfe-commits
ehsan added a subscriber: ehsan.
ehsan added a comment.

Richard: ping?


http://reviews.llvm.org/D15670



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


[PATCH] D16375: [OpenMP] Sema for depend clause on target directive.

2016-01-20 Thread Arpith Jacob via cfe-commits
arpith-jacob created this revision.
arpith-jacob added reviewers: ABataev, kkwli0, hfinkel, sfantao, carlo.bertolli.
arpith-jacob added subscribers: cfe-commits, fraggamuffin, caomhin.

Accept depend clause on target directive in sema and add test cases.

http://reviews.llvm.org/D16375

Files:
  include/clang/Basic/OpenMPKinds.def
  test/OpenMP/target_ast_print.cpp
  test/OpenMP/target_depend_messages.cpp

Index: test/OpenMP/target_depend_messages.cpp
===
--- /dev/null
+++ test/OpenMP/target_depend_messages.cpp
@@ -0,0 +1,89 @@
+// RUN: %clang_cc1 -verify -fopenmp -ferror-limit 100 -o - -std=c++11 %s
+
+void foo() {
+}
+
+bool foobool(int argc) {
+  return argc;
+}
+
+struct S1; // expected-note {{declared here}}
+
+class vector {
+  public:
+int operator[](int index) { return 0; }
+};
+
+int main(int argc, char **argv, char *env[]) {
+  vector vec;
+  typedef float V __attribute__((vector_size(16)));
+  V a;
+  auto arr = x; // expected-error {{use of undeclared identifier 'x'}}
+
+  #pragma omp target depend // expected-error {{expected '(' after 'depend'}}
+  foo();
+  #pragma omp target depend ( // expected-error {{expected 'in', 'out' or 'inout' in OpenMP clause 'depend'}} expected-error {{expected ')'}} expected-note {{to match this '('}} expected-warning {{missing ':' after dependency type - ignoring}}
+  foo();
+  #pragma omp target depend () // expected-error {{expected 'in', 'out' or 'inout' in OpenMP clause 'depend'}} expected-warning {{missing ':' after dependency type - ignoring}}
+  foo();
+  #pragma omp target depend (argc // expected-error {{expected 'in', 'out' or 'inout' in OpenMP clause 'depend'}} expected-warning {{missing ':' after dependency type - ignoring}} expected-error {{expected ')'}} expected-note {{to match this '('}}
+  foo();
+  #pragma omp target depend (source : argc) // expected-error {{expected 'in', 'out' or 'inout' in OpenMP clause 'depend'}}
+  foo();
+  #pragma omp target depend (source) // expected-error {{expected expression}} expected-warning {{missing ':' after dependency type - ignoring}}
+  foo();
+  #pragma omp target depend (in : argc)) // expected-warning {{extra tokens at the end of '#pragma omp target' are ignored}}
+  foo();
+  #pragma omp target depend (out: ) // expected-error {{expected expression}}
+  foo();
+  #pragma omp target depend (inout : foobool(argc)), depend (in, argc) // expected-error {{expected variable name, array element or array section}} expected-warning {{missing ':' after dependency type - ignoring}} expected-error {{expected expression}}
+  foo();
+  #pragma omp target depend (out :S1) // expected-error {{'S1' does not refer to a value}}
+  foo();
+  #pragma omp target depend(in : argv[1][1] = '2') // expected-error {{expected variable name, array element or array section}}
+  foo();
+  #pragma omp target depend (in : vec[1]) // expected-error {{expected variable name, array element or array section}}
+  foo();
+  #pragma omp target depend (in : argv[0])
+  foo();
+  #pragma omp target depend (in : ) // expected-error {{expected expression}}
+  foo();
+  #pragma omp target depend (in : main) // expected-error {{expected variable name, array element or array section}}
+  foo();
+  #pragma omp target depend(in : a[0]) // expected-error{{expected variable name, array element or array section}}
+  foo();
+  #pragma omp target depend (in : vec[1:2]) // expected-error {{ value is not an array or pointer}}
+  foo();
+  #pragma omp target depend (in : argv[ // expected-error {{expected expression}} expected-error {{expected ']'}} expected-error {{expected ')'}} expected-note {{to match this '['}} expected-note {{to match this '('}}
+  foo();
+  #pragma omp target depend (in : argv[: // expected-error {{expected expression}} expected-error {{expected ']'}} expected-error {{expected ')'}} expected-note {{to match this '['}} expected-note {{to match this '('}}
+  foo();
+  #pragma omp target depend (in : argv[:] // expected-error {{section length is unspecified and cannot be inferred because subscripted value is not an array}} expected-error {{expected ')'}} expected-note {{to match this '('}}
+  foo();
+  #pragma omp target depend (in : argv[argc: // expected-error {{expected expression}} expected-error {{expected ']'}} expected-error {{expected ')'}} expected-note {{to match this '['}} expected-note {{to match this '('}}
+  foo();
+  #pragma omp target depend (in : argv[argc:argc] // expected-error {{expected ')'}} expected-note {{to match this '('}}
+  foo();
+  #pragma omp target depend (in : argv[0:-1]) // expected-error {{section length is evaluated to a negative value -1}}
+  foo();
+  #pragma omp target depend (in : argv[-1:0]) // expected-error {{section lower bound is evaluated to a negative value -1}}
+  foo();
+  #pragma omp target depend (in : argv[:]) // expected-error {{section length is unspecified and cannot be inferred because subscripted value is not an arr

[clang-tools-extra] r258356 - Make modernize-use-default tolerant of delayed template parsing; this code was previously causing failed assertions because dyn_cast was being passed a null pointer due t

2016-01-20 Thread Aaron Ballman via cfe-commits
Author: aaronballman
Date: Wed Jan 20 16:14:10 2016
New Revision: 258356

URL: http://llvm.org/viewvc/llvm-project?rev=258356&view=rev
Log:
Make modernize-use-default tolerant of delayed template parsing; this code was 
previously causing failed assertions because dyn_cast was being passed a null 
pointer due to the delay-parsed body.

Added:
clang-tools-extra/trunk/test/clang-tidy/modernize-use-default-delayed.cpp
Modified:
clang-tools-extra/trunk/clang-tidy/modernize/UseDefaultCheck.cpp

Modified: clang-tools-extra/trunk/clang-tidy/modernize/UseDefaultCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/modernize/UseDefaultCheck.cpp?rev=258356&r1=258355&r2=258356&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/modernize/UseDefaultCheck.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/modernize/UseDefaultCheck.cpp Wed Jan 20 
16:14:10 2016
@@ -272,6 +272,7 @@ void UseDefaultCheck::check(const MatchF
   // that are not user-provided (automatically generated).
   if (SpecialFunctionDecl->isDeleted() ||
   SpecialFunctionDecl->isExplicitlyDefaulted() ||
+  SpecialFunctionDecl->isLateTemplateParsed() ||
   !SpecialFunctionDecl->isUserProvided() || 
!SpecialFunctionDecl->hasBody())
 return;
 

Added: clang-tools-extra/trunk/test/clang-tidy/modernize-use-default-delayed.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/modernize-use-default-delayed.cpp?rev=258356&view=auto
==
--- clang-tools-extra/trunk/test/clang-tidy/modernize-use-default-delayed.cpp 
(added)
+++ clang-tools-extra/trunk/test/clang-tidy/modernize-use-default-delayed.cpp 
Wed Jan 20 16:14:10 2016
@@ -0,0 +1,8 @@
+// RUN: clang-tidy %s -checks=-*,modernize-use-default -- -std=c++11 
-fdelayed-template-parsing -fexceptions | count 0
+// Note: this test expects no diagnostics, but FileCheck cannot handle that,
+// hence the use of | count 0.
+
+template 
+struct S {
+  S& operator=(const S&) { return *this; }
+};


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


Re: [PATCH] D16044: getVariableName() for MemRegion

2016-01-20 Thread Gábor Horváth via cfe-commits
xazax.hun added inline comments.


Comment at: tools/clang/lib/StaticAnalyzer/Core/MemRegion.cpp:660
@@ +659,3 @@
+}
+
+else if (auto SV =

The else should go into the same line as the closing }.


Comment at: tools/clang/lib/StaticAnalyzer/Core/MemRegion.cpp:662
@@ +661,3 @@
+else if (auto SV =
+ER->getIndex().getAs()) {
+llvm::SmallString<8> buf;

These are the only cases that can occur? So it is not possible to have a loc 
index? Maybe we could get the value for loc and nonloc ConcreteInts and use 
getVariableName for everzthing else? Would that wok?


Comment at: tools/clang/lib/StaticAnalyzer/Core/MemRegion.cpp:669
@@ +668,3 @@
+
+ArrayIndices += "]" + idx + "[";
+R = ER->getSuperRegion();

In this case idx also needs to be reserved. Since it is very rare that there 
are a huge level of []s, it is possible that the Twine solution is more 
desirable.


Comment at: tools/clang/lib/StaticAnalyzer/Core/MemRegion.cpp:682
@@ +681,3 @@
+  // Combine variable name with indices.
+  if (VariableName.size() && VariableName.back() == '\'') {
+VariableName.insert(VariableName.size() - 1, ArrayIndices);

What is happening here exactly? In some cases there are ' symbols around the 
name and in other cases there aren't? Is there a way to solve this 
inconsistency (so we do not need to check for the last character)? Also it 
would be great that this functions always had consistent result, so either 
never put ' around the name or always. 


http://reviews.llvm.org/D16044



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


Buildbot numbers for week of 1/10/2016 - 1/16/2016

2016-01-20 Thread Galina Kistanova via cfe-commits
Hello everyone,

Below are some buildbot numbers for the last week of 1/10/2016 - 1/16/2016.

Thanks

Galina


Number of commits by project:

 project   |   commits
---+---
 llvm  |   391
 cfe   |   100
 lldb  |56
 lld   |46
 compiler-rt   |30
 libcxx| 9
 clang-tools-extra | 7
 polly | 6
 openmp| 4
 libcxxabi | 2
---+---
   651


Number of completed builds, failed builds and average build time for
successful builds per active builder:

 buildername   | completed  |
failed | time
---+++
 clang-aarch64-lnt | 58
|  4 | 02:41:05
 clang-atom-d525-fedora| 17
|  1 | 09:07:26
 clang-atom-d525-fedora-rel| 66
|  5 | 02:18:25
 clang-bpf-build   |365
| 17 | 00:03:20
 clang-cmake-aarch64-42vma |164
| 15 | 00:45:10
 clang-cmake-aarch64-full  | 42
| 12 | 03:56:57
 clang-cmake-aarch64-quick |194
|  7 | 00:30:23
 clang-cmake-armv7-a15 |180
| 12 | 00:35:19
 clang-cmake-armv7-a15-full| 77
|  4 | 01:47:18
 clang-cmake-armv7-a15-selfhost| 41
| 12 | 04:31:57
 clang-cmake-armv7-a15-selfhost-neon   | 31
|  9 | 05:37:14
 clang-cmake-mips  | 76
|  6 | 01:20:24
 clang-cmake-mipsel| 18
|  2 | 07:07:43
 clang-cmake-thumbv7-a15   |191
| 16 | 00:33:22
 clang-cmake-thumbv7-a15-full-sh   | 26
|  6 | 06:45:59
 clang-hexagon-elf |263
| 14 | 00:18:25
 clang-native-aarch64-full | 10
|  3 | 14:30:53
 clang-native-arm-lnt  | 67
|  1 | 01:39:08
 clang-native-arm-lnt-perf | 16
|| 09:15:46
 clang-ppc64-elf-linux | 87
|  6 | 01:34:19
 clang-ppc64-elf-linux2|152
| 33 | 00:40:29
 clang-sphinx-docs |110
|| 00:00:22
 clang-x64-ninja-win7  |195
| 77 | 00:36:55
 clang-x86-win2008-selfhost|125
| 60 | 01:14:15
 clang-x86_64-darwin13-cross-arm   |262
| 13 | 00:20:16
 clang-x86_64-darwin13-cross-mingw32   |237
|  7 | 00:23:59
 clang-x86_64-debian-fast  |144
|  9 | 00:14:07
 clang-x86_64-linux-abi-test   |388
| 11 | 00:09:59
 clang-x86_64-linux-selfhost-modules   |305
| 75 | 00:16:17
 clang-x86_64-ubuntu-gdb-75|113
| 64 | 00:49:48
 libcxx-libcxxabi-arm-linux| 10
|| 01:08:11
 libcxx-libcxxabi-singlethreaded-x86_64-linux-debian   |  8
|| 00:10:42
 libcxx-libcxxabi-x86_64-linux-debian  |  8
|| 00:11:06
 libcxx-libcxxabi-x86_64-linux-debian-noexceptions |  8
|  3 | 00:10:49
 libcxx-libcxxabi-x86_64-linux-ubuntu-asan |  9
|  9 |
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03|  9
|  1 | 00:06:14
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx11| 11
|| 00:06:19
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx14| 11
|| 00:06:29
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx1z| 10
|| 00:06:56
 libcxx-libcxxabi-x86_64-linux-ubuntu-msan |  8
|  8 |
 libcxx-libcxxabi-x86_64-linux-ubuntu-tsan | 11
|| 00:13:43
 libcxx-libcxxabi-x86_64-linux-ubuntu-unstable-abi | 11
|| 00:07:27
 libcxx-sphinx-docs| 11
|| 00:00:17
 libomp-clang-x86_64-linux-debian  |  

Re: [PATCH] D16372: [CUDA] Make printf work.

2016-01-20 Thread Artem Belevich via cfe-commits
tra added inline comments.


Comment at: lib/CodeGen/CGCUDACall.cpp:1
@@ +1,2 @@
+//===- CGCUDACall.cpp - Codegen for special CUDA calls 
===//
+//

We'll need to handle other builtins soon. Perhaps we can keep them in this file 
and rename it CGCUDABuiltins.cpp


Comment at: test/CodeGenCUDA/Inputs/cuda.h:11-12
@@ -10,2 +10,4 @@
 #define __launch_bounds__(...) __attribute__((launch_bounds(__VA_ARGS__)))
+#define __device_builtin__ __attribute__((device_builtin))
+#define __cudart_builtin__ __attribute__((cudart_builtin))
 

These are not needed to test anything relevant to this patch, IMO.


Comment at: test/CodeGenCUDA/printf.cu:12
@@ +11,3 @@
+// Check a simple call to printf end-to-end.
+__device__ int CheckSimple() {
+  // CHECK: [[FMT:%[0-9]+]] = load{{.*}}%fmt

You may want to add a test case for printf("constant string w/o format args").
It would check no-arguments case and would also verify that we don't get 
optimized into puts().


http://reviews.llvm.org/D16372



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


Re: [PATCH] D15999: Adding doxygen comments to the LLVM intrinsics (part 2, _wmmintrin_pclmul.h)

2016-01-20 Thread Katya Romanova via cfe-commits
kromanova added a comment.

In http://reviews.llvm.org/D15999#330794, @silvas wrote:

> This may sound stupid, but: can you benchmark the time it takes to build some 
> project (that actually uses intrinsics in most translation units, e.g. a 
> game) with the headers w/ and w/o the doxygen comments to check that all the 
> extra comment skipping doesn't affect compilation time? I.e. run your script 
> to add the comments for "all" the intrinsic headers (similar to what you 
> expect the final state to be after all these patches) and test the build time 
> of a game (and compare with the unmodified headers).
>
> Also, can you post a patch that changes "all" the headers to have doxygen 
> comments like you intend, so that others can test and verify?


Out of curiosity, do you know if the impact to the build time for Eric's change 
of starting to use the target attributes instead of conditional inclusion was 
measured (r239883) on a large scale application. If so, what were the results? 
I should probably include Eric.


Repository:
  rL LLVM

http://reviews.llvm.org/D15999



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


[PATCH] D16377: Ensure virtual-near-miss does not crash on functions without names

2016-01-20 Thread Aaron Ballman via cfe-commits
aaron.ballman created this revision.
aaron.ballman added reviewers: congliu, alexfh.
aaron.ballman added a subscriber: cfe-commits.

Special member functions don't always have names, and so calling 
FunctionDecl::getName() can cause assertions. This patch addresses the issue by 
assuming any such function needs to have the rest of its signature checked, 
regardless of the function name. The test case was pulled from MSVC's STL 
headers, where this check is causing failed assertions.

http://reviews.llvm.org/D16377

Files:
  clang-tidy/misc/VirtualNearMissCheck.cpp
  test/clang-tidy/misc-virtual-near-miss.cpp

Index: test/clang-tidy/misc-virtual-near-miss.cpp
===
--- test/clang-tidy/misc-virtual-near-miss.cpp
+++ test/clang-tidy/misc-virtual-near-miss.cpp
@@ -63,3 +63,20 @@
 private:
   void funk(); // Should not warn: access qualifers don't match.
 };
+
+namespace {
+// Ensure this code does not crash due to special member functions.
+class  _Facet_base {
+public:
+  virtual ~_Facet_base() noexcept {}
+};
+
+class facet : public _Facet_base {
+protected:
+  virtual ~facet() noexcept {}
+
+public:
+  facet(const facet&) = delete;
+  facet& operator=(const facet&) = delete;
+};
+}
Index: clang-tidy/misc/VirtualNearMissCheck.cpp
===
--- clang-tidy/misc/VirtualNearMissCheck.cpp
+++ clang-tidy/misc/VirtualNearMissCheck.cpp
@@ -244,8 +244,15 @@
 if (isOverriddenByDerivedClass(BaseMD, DerivedRD))
   continue;
 
+// If the function has an identifier for a name, then use that
+// identifier to determine the edit distance. If the function is a
+// special member function without an identifier, assume the edit
+// distance is nonzero to determine whether the signature is a near
+// miss or not.
 unsigned EditDistance =
-BaseMD->getName().edit_distance(DerivedMD->getName());
+BaseMD->getDeclName().isIdentifier()
+? BaseMD->getName().edit_distance(DerivedMD->getName())
+: 1;
 if (EditDistance > 0 && EditDistance <= EditDistanceThreshold) {
   if (checkOverrideWithoutName(Context, BaseMD, DerivedMD)) {
 // A "virtual near miss" is found.


Index: test/clang-tidy/misc-virtual-near-miss.cpp
===
--- test/clang-tidy/misc-virtual-near-miss.cpp
+++ test/clang-tidy/misc-virtual-near-miss.cpp
@@ -63,3 +63,20 @@
 private:
   void funk(); // Should not warn: access qualifers don't match.
 };
+
+namespace {
+// Ensure this code does not crash due to special member functions.
+class  _Facet_base {
+public:
+  virtual ~_Facet_base() noexcept {}
+};
+
+class facet : public _Facet_base {
+protected:
+  virtual ~facet() noexcept {}
+
+public:
+  facet(const facet&) = delete;
+  facet& operator=(const facet&) = delete;
+};
+}
Index: clang-tidy/misc/VirtualNearMissCheck.cpp
===
--- clang-tidy/misc/VirtualNearMissCheck.cpp
+++ clang-tidy/misc/VirtualNearMissCheck.cpp
@@ -244,8 +244,15 @@
 if (isOverriddenByDerivedClass(BaseMD, DerivedRD))
   continue;
 
+// If the function has an identifier for a name, then use that
+// identifier to determine the edit distance. If the function is a
+// special member function without an identifier, assume the edit
+// distance is nonzero to determine whether the signature is a near
+// miss or not.
 unsigned EditDistance =
-BaseMD->getName().edit_distance(DerivedMD->getName());
+BaseMD->getDeclName().isIdentifier()
+? BaseMD->getName().edit_distance(DerivedMD->getName())
+: 1;
 if (EditDistance > 0 && EditDistance <= EditDistanceThreshold) {
   if (checkOverrideWithoutName(Context, BaseMD, DerivedMD)) {
 // A "virtual near miss" is found.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [PATCH] D16377: Ensure virtual-near-miss does not crash on functions without names

2016-01-20 Thread Aaron Ballman via cfe-commits
aaron.ballman updated this revision to Diff 45451.
aaron.ballman added a comment.

Now checking that both the base *and* the derived functions have names.


http://reviews.llvm.org/D16377

Files:
  clang-tidy/misc/VirtualNearMissCheck.cpp
  test/clang-tidy/misc-virtual-near-miss.cpp

Index: test/clang-tidy/misc-virtual-near-miss.cpp
===
--- test/clang-tidy/misc-virtual-near-miss.cpp
+++ test/clang-tidy/misc-virtual-near-miss.cpp
@@ -63,3 +63,20 @@
 private:
   void funk(); // Should not warn: access qualifers don't match.
 };
+
+namespace {
+// Ensure this code does not crash due to special member functions.
+class  _Facet_base {
+public:
+  virtual ~_Facet_base() noexcept {}
+};
+
+class facet : public _Facet_base {
+protected:
+  virtual ~facet() noexcept {}
+
+public:
+  facet(const facet&) = delete;
+  facet& operator=(const facet&) = delete;
+};
+}
Index: clang-tidy/misc/VirtualNearMissCheck.cpp
===
--- clang-tidy/misc/VirtualNearMissCheck.cpp
+++ clang-tidy/misc/VirtualNearMissCheck.cpp
@@ -244,8 +244,16 @@
 if (isOverriddenByDerivedClass(BaseMD, DerivedRD))
   continue;
 
+// If the function has an identifier for a name, then use that
+// identifier to determine the edit distance. If the function is a
+// special member function without an identifier, assume the edit
+// distance is nonzero to determine whether the signature is a near
+// miss or not.
 unsigned EditDistance =
-BaseMD->getName().edit_distance(DerivedMD->getName());
+(BaseMD->getDeclName().isIdentifier() &&
+ DerivedMD->getDeclName().isIdentifier())
+? BaseMD->getName().edit_distance(DerivedMD->getName())
+: 1;
 if (EditDistance > 0 && EditDistance <= EditDistanceThreshold) {
   if (checkOverrideWithoutName(Context, BaseMD, DerivedMD)) {
 // A "virtual near miss" is found.


Index: test/clang-tidy/misc-virtual-near-miss.cpp
===
--- test/clang-tidy/misc-virtual-near-miss.cpp
+++ test/clang-tidy/misc-virtual-near-miss.cpp
@@ -63,3 +63,20 @@
 private:
   void funk(); // Should not warn: access qualifers don't match.
 };
+
+namespace {
+// Ensure this code does not crash due to special member functions.
+class  _Facet_base {
+public:
+  virtual ~_Facet_base() noexcept {}
+};
+
+class facet : public _Facet_base {
+protected:
+  virtual ~facet() noexcept {}
+
+public:
+  facet(const facet&) = delete;
+  facet& operator=(const facet&) = delete;
+};
+}
Index: clang-tidy/misc/VirtualNearMissCheck.cpp
===
--- clang-tidy/misc/VirtualNearMissCheck.cpp
+++ clang-tidy/misc/VirtualNearMissCheck.cpp
@@ -244,8 +244,16 @@
 if (isOverriddenByDerivedClass(BaseMD, DerivedRD))
   continue;
 
+// If the function has an identifier for a name, then use that
+// identifier to determine the edit distance. If the function is a
+// special member function without an identifier, assume the edit
+// distance is nonzero to determine whether the signature is a near
+// miss or not.
 unsigned EditDistance =
-BaseMD->getName().edit_distance(DerivedMD->getName());
+(BaseMD->getDeclName().isIdentifier() &&
+ DerivedMD->getDeclName().isIdentifier())
+? BaseMD->getName().edit_distance(DerivedMD->getName())
+: 1;
 if (EditDistance > 0 && EditDistance <= EditDistanceThreshold) {
   if (checkOverrideWithoutName(Context, BaseMD, DerivedMD)) {
 // A "virtual near miss" is found.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [clang-tools-extra] r258356 - Make modernize-use-default tolerant of delayed template parsing; this code was previously causing failed assertions because dyn_cast was being passed a null pointer d

2016-01-20 Thread Aaron Ballman via cfe-commits
Uncertain whether this meets the bar for inclusion in 3.8.
clang-modernize was moved into clang-tidy and from what I can tell, it
did not suffer from this crash. I wouldn't normally recommend this,
but just about any use of clang-tidy (that does not filter out this
check) over code that includes the MSVC STL headers will trigger that
assert without this fix.

~Aaron

On Wed, Jan 20, 2016 at 5:14 PM, Aaron Ballman via cfe-commits
 wrote:
> Author: aaronballman
> Date: Wed Jan 20 16:14:10 2016
> New Revision: 258356
>
> URL: http://llvm.org/viewvc/llvm-project?rev=258356&view=rev
> Log:
> Make modernize-use-default tolerant of delayed template parsing; this code 
> was previously causing failed assertions because dyn_cast was being passed a 
> null pointer due to the delay-parsed body.
>
> Added:
> clang-tools-extra/trunk/test/clang-tidy/modernize-use-default-delayed.cpp
> Modified:
> clang-tools-extra/trunk/clang-tidy/modernize/UseDefaultCheck.cpp
>
> Modified: clang-tools-extra/trunk/clang-tidy/modernize/UseDefaultCheck.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/modernize/UseDefaultCheck.cpp?rev=258356&r1=258355&r2=258356&view=diff
> ==
> --- clang-tools-extra/trunk/clang-tidy/modernize/UseDefaultCheck.cpp 
> (original)
> +++ clang-tools-extra/trunk/clang-tidy/modernize/UseDefaultCheck.cpp Wed Jan 
> 20 16:14:10 2016
> @@ -272,6 +272,7 @@ void UseDefaultCheck::check(const MatchF
>// that are not user-provided (automatically generated).
>if (SpecialFunctionDecl->isDeleted() ||
>SpecialFunctionDecl->isExplicitlyDefaulted() ||
> +  SpecialFunctionDecl->isLateTemplateParsed() ||
>!SpecialFunctionDecl->isUserProvided() || 
> !SpecialFunctionDecl->hasBody())
>  return;
>
>
> Added: 
> clang-tools-extra/trunk/test/clang-tidy/modernize-use-default-delayed.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/modernize-use-default-delayed.cpp?rev=258356&view=auto
> ==
> --- clang-tools-extra/trunk/test/clang-tidy/modernize-use-default-delayed.cpp 
> (added)
> +++ clang-tools-extra/trunk/test/clang-tidy/modernize-use-default-delayed.cpp 
> Wed Jan 20 16:14:10 2016
> @@ -0,0 +1,8 @@
> +// RUN: clang-tidy %s -checks=-*,modernize-use-default -- -std=c++11 
> -fdelayed-template-parsing -fexceptions | count 0
> +// Note: this test expects no diagnostics, but FileCheck cannot handle that,
> +// hence the use of | count 0.
> +
> +template 
> +struct S {
> +  S& operator=(const S&) { return *this; }
> +};
>
>
> ___
> 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] D15999: Adding doxygen comments to the LLVM intrinsics (part 2, _wmmintrin_pclmul.h)

2016-01-20 Thread Eric Christopher via cfe-commits
On Wed, Jan 20, 2016 at 2:32 PM Katya Romanova via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> kromanova added a comment.
>
> In http://reviews.llvm.org/D15999#330794, @silvas wrote:
>
> > This may sound stupid, but: can you benchmark the time it takes to build
> some project (that actually uses intrinsics in most translation units, e.g.
> a game) with the headers w/ and w/o the doxygen comments to check that all
> the extra comment skipping doesn't affect compilation time? I.e. run your
> script to add the comments for "all" the intrinsic headers (similar to what
> you expect the final state to be after all these patches) and test the
> build time of a game (and compare with the unmodified headers).
> >
> > Also, can you post a patch that changes "all" the headers to have
> doxygen comments like you intend, so that others can test and verify?
>
>
> Out of curiosity, do you know if the impact to the build time for Eric's
> change of starting to use the target attributes instead of conditional
> inclusion was measured (r239883) on a large scale application. If so, what
> were the results? I should probably include Eric.
>

I did not as the feature compatibility was fairly important here. That
said, I don't really expect the compile time difference for the comment
skipping to matter in any large way and having documentation seems pretty
nice.

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


Re: [PATCH] D16163: [Concepts] Diagnose when return type of a function concept or declaration type of a variable concept is not bool.

2016-01-20 Thread Nathan Wilson via cfe-commits
nwilson updated this revision to Diff 45453.
nwilson added a comment.

- Take qualifiers into account.
- Check `VarDecl` is valid when checking declaration type to account for 
`constexpr` being specified. Is there any opinion on a better way to handle 
this? I *could* check for both diagnostics in the test...
- Remove erroneous check for `auto` (containsPlaceholderType) and associated 
function concept test.
- Removed the use of Diagnostic Range because we'd need to enumerate over the 
various qualifiers.


http://reviews.llvm.org/D16163

Files:
  include/clang/Basic/DiagnosticSemaKinds.td
  lib/Sema/SemaDecl.cpp
  test/CXX/concepts-ts/dcl.dcl/dcl.spec/dcl.spec.concept/p5.cpp
  test/CXX/concepts-ts/dcl.dcl/dcl.spec/dcl.spec.concept/p6.cpp

Index: test/CXX/concepts-ts/dcl.dcl/dcl.spec/dcl.spec.concept/p6.cpp
===
--- /dev/null
+++ test/CXX/concepts-ts/dcl.dcl/dcl.spec/dcl.spec.concept/p6.cpp
@@ -0,0 +1,25 @@
+// RUN:  %clang_cc1 -std=c++14 -fconcepts-ts -x c++ -verify %s
+
+template
+concept bool vc { true };
+
+template
+struct B { typedef bool Boolean; };
+
+template
+B::Boolean concept vctb(!0);
+
+template
+concept const bool vctc { true }; // expected-error {{declared type of 
variable concept must be 'bool'}}
+
+template
+concept int vcti { 5 }; // expected-error {{declared type of variable concept 
must be 'bool'}}
+
+template
+concept float vctf { 5.5 }; // expected-error {{declared type of variable 
concept must be 'bool'}}
+
+template
+concept auto vcta { true }; // expected-error {{declared type of variable 
concept must be 'bool'}}
+
+template
+concept decltype(auto) vctd { true }; // expected-error {{declared type of 
variable concept must be 'bool'}}
Index: test/CXX/concepts-ts/dcl.dcl/dcl.spec/dcl.spec.concept/p5.cpp
===
--- test/CXX/concepts-ts/dcl.dcl/dcl.spec/dcl.spec.concept/p5.cpp
+++ test/CXX/concepts-ts/dcl.dcl/dcl.spec/dcl.spec.concept/p5.cpp
@@ -11,3 +11,15 @@
 
 template
 concept bool fcpva(...) { return true; } // expected-error {{function concept 
cannot have any parameters}}
+
+template
+concept const bool fcrtc() { return true; } // expected-error {{declared 
return type of function concept must be 'bool'}}
+
+template
+concept int fcrti() { return 5; } // expected-error {{declared return type of 
function concept must be 'bool'}}
+
+template
+concept float fcrtf() { return 5.5; } // expected-error {{declared return type 
of function concept must be 'bool'}}
+
+template
+concept decltype(auto) fcrtd(void) { return true; } // expected-error 
{{declared return type of function concept must be 'bool'}}
Index: lib/Sema/SemaDecl.cpp
===
--- lib/Sema/SemaDecl.cpp
+++ lib/Sema/SemaDecl.cpp
@@ -5986,6 +5986,15 @@
 << 0 << 3;
 NewVD->setInvalidDecl(true);
   }
+
+  // C++ Concepts TS [dcl.spec.concept]p6: A variable concept has the
+  // following restrictions:
+  // - The declared type shall have the type bool.
+  if (!Context.hasSameType(NewVD->getType(), Context.BoolTy) &&
+  !NewVD->isInvalidDecl()) {
+Diag(D.getIdentifierLoc(), diag::err_variable_concept_bool_decl);
+NewVD->setInvalidDecl(true);
+  }
 }
   }
 
@@ -7668,6 +7677,14 @@
 
 // C++ Concepts TS [dcl.spec.concept]p5: A function concept has the
 // following restrictions:
+// - The declared return type shall have the type bool.
+if (!Context.hasSameType(FPT->getReturnType(), Context.BoolTy)) {
+  Diag(D.getIdentifierLoc(), diag::err_function_concept_bool_ret);
+  NewFD->setInvalidDecl();
+}
+
+// C++ Concepts TS [dcl.spec.concept]p5: A function concept has the
+// following restrictions:
 // - The declaration's parameter list shall be equivalent to an empty
 //   parameter list.
 if (FPT->getNumParams() > 0 || FPT->isVariadic())
Index: include/clang/Basic/DiagnosticSemaKinds.td
===
--- include/clang/Basic/DiagnosticSemaKinds.td
+++ include/clang/Basic/DiagnosticSemaKinds.td
@@ -2074,6 +2074,10 @@
   "'%select{thread_local|inline|friend|constexpr}1'">;
 def err_function_concept_with_params : Error<
   "function concept cannot have any parameters">;
+def err_function_concept_bool_ret : Error<
+  "declared return type of function concept must be 'bool'">;
+def err_variable_concept_bool_decl : Error<
+  "declared type of variable concept must be 'bool'">;
 
 // C++11 char16_t/char32_t
 def warn_cxx98_compat_unicode_type : Warning<


Index: test/CXX/concepts-ts/dcl.dcl/dcl.spec/dcl.spec.concept/p6.cpp
===
--- /dev/null
+++ test/CXX/concepts-ts/dcl.dcl/dcl.spec/dcl.spec.concept/p6.cpp
@@ -0,0 +1,25 @@
+// RUN:  %clang_cc1 -std=c++14 -fconcepts-ts -x c+

Re: [PATCH] D15999: Adding doxygen comments to the LLVM intrinsics (part 2, _wmmintrin_pclmul.h)

2016-01-20 Thread Sean Silva via cfe-commits
silvas added a comment.

In http://reviews.llvm.org/D15999#331601, @kromanova wrote:

> In http://reviews.llvm.org/D15999#330794, @silvas wrote:
>
> > This may sound stupid, but: can you benchmark the time it takes to build 
> > some project (that actually uses intrinsics in most translation units, e.g. 
> > a game) with the headers w/ and w/o the doxygen comments to check that all 
> > the extra comment skipping doesn't affect compilation time? I.e. run your 
> > script to add the comments for "all" the intrinsic headers (similar to what 
> > you expect the final state to be after all these patches) and test the 
> > build time of a game (and compare with the unmodified headers).
> >
> > Also, can you post a patch that changes "all" the headers to have doxygen 
> > comments like you intend, so that others can test and verify?
>
>
> Out of curiosity, do you know if the impact to the build time for Eric's 
> change of starting to use the target attributes instead of conditional 
> inclusion was measured (r239883) on a large scale application. If so, what 
> were the results? I should probably include Eric.


I don't think we did any testing at SCE, but we probably should have. I don't 
think Google's primary codebases (nor Apple's, or anybody else pretty much) 
include the intrinsic headers in basically every TU so the impact is probably 
not a huge concern overall. However, games include these headers in basically 
every TU so we at SCE should take a look.

Also, the target attributes stuff had some correctness issues (e.g. crashes in 
backend) that took a while to iron out and those issues took the limelight.


Repository:
  rL LLVM

http://reviews.llvm.org/D15999



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


Re: [PATCH] D15999: Adding doxygen comments to the LLVM intrinsics (part 2, _wmmintrin_pclmul.h)

2016-01-20 Thread Eric Christopher via cfe-commits
On Wed, Jan 20, 2016 at 3:12 PM Sean Silva  wrote:

> silvas added a comment.
>
> In http://reviews.llvm.org/D15999#331601, @kromanova wrote:
>
> > In http://reviews.llvm.org/D15999#330794, @silvas wrote:
> >
> > > This may sound stupid, but: can you benchmark the time it takes to
> build some project (that actually uses intrinsics in most translation
> units, e.g. a game) with the headers w/ and w/o the doxygen comments to
> check that all the extra comment skipping doesn't affect compilation time?
> I.e. run your script to add the comments for "all" the intrinsic headers
> (similar to what you expect the final state to be after all these patches)
> and test the build time of a game (and compare with the unmodified headers).
> > >
> > > Also, can you post a patch that changes "all" the headers to have
> doxygen comments like you intend, so that others can test and verify?
> >
> >
> > Out of curiosity, do you know if the impact to the build time for Eric's
> change of starting to use the target attributes instead of conditional
> inclusion was measured (r239883) on a large scale application. If so, what
> were the results? I should probably include Eric.
>
>
> I don't think we did any testing at SCE, but we probably should have. I
> don't think Google's primary codebases (nor Apple's, or anybody else pretty
> much) include the intrinsic headers in basically every TU so the impact is
> probably not a huge concern overall. However, games include these headers
> in basically every TU so we at SCE should take a look.
>
>
This seems to be a pretty broad brush to paint things with and an
assumption I wouldn't be willing to make.


> Also, the target attributes stuff had some correctness issues (e.g.
> crashes in backend) that took a while to iron out and those issues took the
> limelight.
>
>
For the record, those were "crash on invalid" rather than "crash on valid".

-eric



>
> Repository:
>   rL LLVM
>
> http://reviews.llvm.org/D15999
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [PATCH] D15999: Adding doxygen comments to the LLVM intrinsics (part 2, _wmmintrin_pclmul.h)

2016-01-20 Thread Sean Silva via cfe-commits
silvas added a comment.

In http://reviews.llvm.org/D15999#331512, @kromanova wrote:

> In http://reviews.llvm.org/D15999#330794, @silvas wrote:
>
> > This may sound stupid, but: can you benchmark the time it takes to build 
> > some project (that actually uses intrinsics in most translation units, e.g. 
> > a game) with the headers w/ and w/o the doxygen comments to check that all 
> > the extra comment skipping doesn't affect compilation time? I.e. run your 
> > script to add the comments for "all" the intrinsic headers (similar to what 
> > you expect the final state to be after all these patches) and test the 
> > build time of a game (and compare with the unmodified headers).
>
>
> This makes sense. I can do this, though it might take a couple of days, since 
> I don't have a setup for a game build.
>  I suspect that that we shouldn't use an application/game that is using 
> precompiled headers. Any other limitation should be imposed on the beanchmark?


Just make sure it is realistic.

> 

> 

> > Also, can you post a patch that changes "all" the headers to have doxygen 
> > comments like you intend, so that others can test and verify?

> 

> 

> Yes, I'll do this. However, there are a couple of things that the people 
> should be aware:

>  (a) *only* intrinsics that are supported on PS4 will have doxygen comments. 
> PS4 documentation is parsed to generate these comments, and it doesn't 
> document the intrinsics that are not supported on PS4.


If we don't have coverage of every intrinsic, we will need to add documentation 
for Clang developers about the comment format so that future intrinsics (and 
intrinsics not covered) can be documented.

> (b) the doxygen comments for the rest (not submitted upstream) headers files 
> might have some problems (typos, incorrect parameter types, bugs in the 
> description, etc). The tool that generates the comments might have some 
> glitches too. Most of this things get fixed after the manual review that I do 
> before I submit the Phabricator code review. So, please don't assume that 
> this is the final version of the header files with doxygen comments.


Sure. Makes sense.


Repository:
  rL LLVM

http://reviews.llvm.org/D15999



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


RE: [PATCH] D15999: Adding doxygen comments to the LLVM intrinsics (part 2, _wmmintrin_pclmul.h)

2016-01-20 Thread Romanova, Katya via cfe-commits
I see. I was hoping that if you were, I could have used the same benchmark and 
compare what build time increase caused by using target attributes (might be 
much more substantial) and  by adding doxygen comments.

From: Eric Christopher [mailto:echri...@gmail.com]
Sent: Wednesday, January 20, 2016 3:09 PM
To: reviews+d15999+public+772a9901b981d...@reviews.llvm.org; Romanova, Katya; 
griboz...@gmail.com; jonat...@codesourcery.com; Gao, Yunzhong; Sean Silva
Cc: cfe-commits@lists.llvm.org
Subject: Re: [PATCH] D15999: Adding doxygen comments to the LLVM intrinsics 
(part 2, _wmmintrin_pclmul.h)


On Wed, Jan 20, 2016 at 2:32 PM Katya Romanova via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
kromanova added a comment.

In http://reviews.llvm.org/D15999#330794, @silvas wrote:

> This may sound stupid, but: can you benchmark the time it takes to build some 
> project (that actually uses intrinsics in most translation units, e.g. a 
> game) with the headers w/ and w/o the doxygen comments to check that all the 
> extra comment skipping doesn't affect compilation time? I.e. run your script 
> to add the comments for "all" the intrinsic headers (similar to what you 
> expect the final state to be after all these patches) and test the build time 
> of a game (and compare with the unmodified headers).
>
> Also, can you post a patch that changes "all" the headers to have doxygen 
> comments like you intend, so that others can test and verify?


Out of curiosity, do you know if the impact to the build time for Eric's change 
of starting to use the target attributes instead of conditional inclusion was 
measured (r239883) on a large scale application. If so, what were the results? 
I should probably include Eric.

I did not as the feature compatibility was fairly important here. That said, I 
don't really expect the compile time difference for the comment skipping to 
matter in any large way and having documentation seems pretty nice.

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


Re: [PATCH] D15921: [analyzer] Utility to match function calls.

2016-01-20 Thread Anna Zaks via cfe-commits
zaks.anna accepted this revision.
zaks.anna added a comment.
This revision is now accepted and ready to land.

LGTM


http://reviews.llvm.org/D15921



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


Re: [PATCH] D15999: Adding doxygen comments to the LLVM intrinsics (part 2, _wmmintrin_pclmul.h)

2016-01-20 Thread Eric Christopher via cfe-commits
I have some benchmarks, but none of them moved when I added the support
that I could see. It wouldn't catch small regressions though.

-eric

On Wed, Jan 20, 2016 at 3:17 PM Romanova, Katya <
katya_roman...@playstation.sony.com> wrote:

> I see. I was hoping that if you were, I could have used the same benchmark
> and compare what build time increase caused by using target attributes
> (might be much more substantial) and  by adding doxygen comments.
>
>
>
> *From:* Eric Christopher [mailto:echri...@gmail.com]
> *Sent:* Wednesday, January 20, 2016 3:09 PM
> *To:* reviews+d15999+public+772a9901b981d...@reviews.llvm.org; Romanova,
> Katya; griboz...@gmail.com; jonat...@codesourcery.com; Gao, Yunzhong;
> Sean Silva
> *Cc:* cfe-commits@lists.llvm.org
> *Subject:* Re: [PATCH] D15999: Adding doxygen comments to the LLVM
> intrinsics (part 2, _wmmintrin_pclmul.h)
>
>
>
>
>
> On Wed, Jan 20, 2016 at 2:32 PM Katya Romanova via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
> kromanova added a comment.
>
> In http://reviews.llvm.org/D15999#330794, @silvas wrote:
>
> > This may sound stupid, but: can you benchmark the time it takes to build
> some project (that actually uses intrinsics in most translation units, e.g.
> a game) with the headers w/ and w/o the doxygen comments to check that all
> the extra comment skipping doesn't affect compilation time? I.e. run your
> script to add the comments for "all" the intrinsic headers (similar to what
> you expect the final state to be after all these patches) and test the
> build time of a game (and compare with the unmodified headers).
> >
> > Also, can you post a patch that changes "all" the headers to have
> doxygen comments like you intend, so that others can test and verify?
>
>
> Out of curiosity, do you know if the impact to the build time for Eric's
> change of starting to use the target attributes instead of conditional
> inclusion was measured (r239883) on a large scale application. If so, what
> were the results? I should probably include Eric.
>
>
>
> I did not as the feature compatibility was fairly important here. That
> said, I don't really expect the compile time difference for the comment
> skipping to matter in any large way and having documentation seems pretty
> nice.
>
>
>
> -eric
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [PATCH] D16372: [CUDA] Make printf work.

2016-01-20 Thread Justin Lebar via cfe-commits
jlebar added inline comments.


Comment at: test/CodeGenCUDA/printf.cu:12
@@ +11,3 @@
+// Check a simple call to printf end-to-end.
+__device__ int CheckSimple() {
+  // CHECK: [[FMT:%[0-9]+]] = load{{.*}}%fmt

tra wrote:
> You may want to add a test case for printf("constant string w/o format args").
> It would check no-arguments case and would also verify that we don't get 
> optimized into puts().
Good idea, done.


http://reviews.llvm.org/D16372



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


Re: [PATCH] D16372: [CUDA] Make printf work.

2016-01-20 Thread Justin Lebar via cfe-commits
jlebar updated this revision to Diff 45456.
jlebar marked 3 inline comments as done.
jlebar added a comment.

Address tra's review comments.


http://reviews.llvm.org/D16372

Files:
  lib/CodeGen/CGBuiltin.cpp
  lib/CodeGen/CGCUDABuiltin.cpp
  lib/CodeGen/CMakeLists.txt
  lib/CodeGen/CodeGenFunction.h
  lib/Headers/__clang_cuda_runtime_wrapper.h
  test/CodeGenCUDA/Inputs/cuda.h
  test/CodeGenCUDA/printf.cu

Index: test/CodeGenCUDA/printf.cu
===
--- /dev/null
+++ test/CodeGenCUDA/printf.cu
@@ -0,0 +1,53 @@
+// REQUIRES: x86-registered-target
+// REQUIRES: nvptx-registered-target
+
+// RUN: %clang_cc1 -triple nvptx64-nvidia-cuda -fcuda-is-device -emit-llvm \
+// RUN:   -o - %s | FileCheck %s
+
+#include "Inputs/cuda.h"
+
+extern "C" __device__ int vprintf(const char*, const char*);
+
+// Check a simple call to printf end-to-end.
+__device__ int CheckSimple() {
+  // CHECK: [[FMT:%[0-9]+]] = load{{.*}}%fmt
+  const char* fmt = "%d";
+  // CHECK: [[BUF:%[a-zA-Z0-9_]+]] = alloca i8, i32 4, align 4
+  // CHECK: [[PTR:%[0-9]+]] = getelementptr i8, i8* [[BUF]], i32 0
+  // CHECK: [[CAST:%[0-9]+]] = bitcast i8* [[PTR]] to i32*
+  // CHECK: store i32 42, i32* [[CAST]], align 4
+  // CHECK: [[RET:%[0-9]+]] = call i32 @vprintf(i8* [[FMT]], i8* [[BUF]])
+  // CHECK: ret i32 [[RET]]
+  return printf(fmt, 42);
+}
+
+// Check that the args' types are promoted correctly when we call printf.
+__device__ void CheckTypes() {
+  // CHECK: alloca {{.*}} align 8
+  // CHECK: getelementptr {{.*}} i32 0
+  // CHECK: bitcast {{.*}} to i32*
+  // CHECK: getelementptr {{.*}} i32 4
+  // CHECK: bitcast {{.*}} to i32*
+  // CHECK: getelementptr {{.*}} i32 8
+  // CHECK: bitcast {{.*}} to double*
+  // CHECK: getelementptr {{.*}} i32 16
+  // CHECK: bitcast {{.*}} to double*
+  printf("%d %d %f %f", (char)1, (short)2, 3.0f, 4.0);
+}
+
+// Check that the args are aligned properly in the buffer.
+__device__ void CheckAlign() {
+  // CHECK: alloca i8, i32 40, align 8
+  // CHECK: getelementptr {{.*}} i32 0
+  // CHECK: getelementptr {{.*}} i32 8
+  // CHECK: getelementptr {{.*}} i32 16
+  // CHECK: getelementptr {{.*}} i32 20
+  // CHECK: getelementptr {{.*}} i32 24
+  // CHECK: getelementptr {{.*}} i32 32
+  printf("%d %f %d %d %d %lld", 1, 2.0, 3, 4, 5, (long long)6);
+}
+
+__device__ void CheckNoArgs() {
+  // CHECK: call i32 @vprintf({{.*}}, i8* null){{$}}
+  printf("hello, world!");
+}
Index: test/CodeGenCUDA/Inputs/cuda.h
===
--- test/CodeGenCUDA/Inputs/cuda.h
+++ test/CodeGenCUDA/Inputs/cuda.h
@@ -18,3 +18,5 @@
 
 int cudaConfigureCall(dim3 gridSize, dim3 blockSize, size_t sharedSize = 0,
   cudaStream_t stream = 0);
+
+extern "C" __device__ int printf(const char*, ...);
Index: lib/Headers/__clang_cuda_runtime_wrapper.h
===
--- lib/Headers/__clang_cuda_runtime_wrapper.h
+++ lib/Headers/__clang_cuda_runtime_wrapper.h
@@ -210,6 +210,11 @@
 static __device__ __attribute__((used)) int __nvvm_reflect_anchor() {
   return __nvvm_reflect("NONE");
 }
+
+// The nvptx vprintf syscall.  This doesn't actually need to be declared, but we
+// declare it so that if someone else declares it with a different signature,
+// we'll throw an error.
+extern "C" __device__ int vprintf(const char*, const char*);
 #endif
 
 #endif // __CUDA__
Index: lib/CodeGen/CodeGenFunction.h
===
--- lib/CodeGen/CodeGenFunction.h
+++ lib/CodeGen/CodeGenFunction.h
@@ -2709,6 +2709,8 @@
   RValue EmitCUDAKernelCallExpr(const CUDAKernelCallExpr *E,
 ReturnValueSlot ReturnValue);
 
+  RValue EmitCUDADevicePrintfCallExpr(const CallExpr *E,
+  ReturnValueSlot ReturnValue);
 
   RValue EmitBuiltinExpr(const FunctionDecl *FD,
  unsigned BuiltinID, const CallExpr *E,
Index: lib/CodeGen/CMakeLists.txt
===
--- lib/CodeGen/CMakeLists.txt
+++ lib/CodeGen/CMakeLists.txt
@@ -32,6 +32,7 @@
   CGAtomic.cpp
   CGBlocks.cpp
   CGBuiltin.cpp
+  CGCUDABuiltin.cpp
   CGCUDANV.cpp
   CGCUDARuntime.cpp
   CGCXX.cpp
Index: lib/CodeGen/CGCUDABuiltin.cpp
===
--- /dev/null
+++ lib/CodeGen/CGCUDABuiltin.cpp
@@ -0,0 +1,131 @@
+//===- CGCUDABuiltin.cpp - Codegen for CUDA builtins --===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+//
+// Generates code for built-in CUDA calls which are not runtime-specific.
+// (Runtime-specific codegen lives in CGCUDARuntime.)
+//
+//===

Re: [PATCH] D15999: Adding doxygen comments to the LLVM intrinsics (part 2, _wmmintrin_pclmul.h)

2016-01-20 Thread Sean Silva via cfe-commits
On Wed, Jan 20, 2016 at 3:14 PM, Eric Christopher 
wrote:

>
>
> On Wed, Jan 20, 2016 at 3:12 PM Sean Silva  wrote:
>
>> silvas added a comment.
>>
>> In http://reviews.llvm.org/D15999#331601, @kromanova wrote:
>>
>> > In http://reviews.llvm.org/D15999#330794, @silvas wrote:
>> >
>> > > This may sound stupid, but: can you benchmark the time it takes to
>> build some project (that actually uses intrinsics in most translation
>> units, e.g. a game) with the headers w/ and w/o the doxygen comments to
>> check that all the extra comment skipping doesn't affect compilation time?
>> I.e. run your script to add the comments for "all" the intrinsic headers
>> (similar to what you expect the final state to be after all these patches)
>> and test the build time of a game (and compare with the unmodified headers).
>> > >
>> > > Also, can you post a patch that changes "all" the headers to have
>> doxygen comments like you intend, so that others can test and verify?
>> >
>> >
>> > Out of curiosity, do you know if the impact to the build time for
>> Eric's change of starting to use the target attributes instead of
>> conditional inclusion was measured (r239883) on a large scale application.
>> If so, what were the results? I should probably include Eric.
>>
>>
>> I don't think we did any testing at SCE, but we probably should have. I
>> don't think Google's primary codebases (nor Apple's, or anybody else pretty
>> much) include the intrinsic headers in basically every TU so the impact is
>> probably not a huge concern overall. However, games include these headers
>> in basically every TU so we at SCE should take a look.
>>
>>
> This seems to be a pretty broad brush to paint things with and an
> assumption I wouldn't be willing to make.
>

Every vendor obviously has some projects that end up pulling in intrinsics
in basically every TU. It's just that for SCE those are the rule and not
the exception, so we should be particularly concerned.

-- Sean Silva


>
>
>> Also, the target attributes stuff had some correctness issues (e.g.
>> crashes in backend) that took a while to iron out and those issues took the
>> limelight.
>>
>>
> For the record, those were "crash on invalid" rather than "crash on valid".
>
> -eric
>
>
>
>>
>> Repository:
>>   rL LLVM
>>
>> http://reviews.llvm.org/D15999
>>
>>
>>
>>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [PATCH] D15977: [Clang] Supporting all entities declared in lexical scope in LLVM debug info

2016-01-20 Thread David Blaikie via cfe-commits
dblaikie added inline comments.


Comment at: lib/CodeGen/CGDebugInfo.cpp:1479
@@ +1478,3 @@
+void CGDebugInfo::recordDeclarationLexicalScope(const Decl &D) {
+  assert(LexicalBlockMap.find(&D) == LexicalBlockMap.end() &&
+ "D is already mapped to lexical block scope");

Dose this assert not fire if there are two decls in the same lexical scope?


Comment at: lib/CodeGen/CGDebugInfo.cpp:1481
@@ +1480,3 @@
+ "D is already mapped to lexical block scope");
+  if (!LexicalBlockStack.empty())
+LexicalBlockMap[&D] = LexicalBlockStack.back();

Should we assert that LexicalBlockStack isn't empty?


Comment at: lib/CodeGen/CGDebugInfo.cpp:1488
@@ +1487,3 @@
+  auto I = LexicalBlockMap.find(&D);
+  if (I != LexicalBlockMap.end()) {
+RetainedTypes.push_back(Ty.getAsOpaquePtr());

Perhaps we should assert here that if D's scope is a lexical block, that it 
should have a corresponding entry in the LexicalBlockMap?


Comment at: lib/CodeGen/CGDebugInfo.cpp:1489
@@ +1488,3 @@
+  if (I != LexicalBlockMap.end()) {
+RetainedTypes.push_back(Ty.getAsOpaquePtr());
+return I->second;

Why does the type need to be added to the retained types list?


Comment at: lib/CodeGen/CGDebugInfo.cpp:1491
@@ +1490,3 @@
+return I->second;
+  } else
+return getDeclContextDescriptor(cast(&D));

else-after-return (just drop the else and let the following code remain 
unconditionally)


Comment at: lib/CodeGen/CGDebugInfo.cpp:2066
@@ -2045,3 +2065,3 @@
   if (isImportedFromModule || !ED->getDefinition()) {
-llvm::DIScope *EDContext = getDeclContextDescriptor(ED);
+llvm::DIScope *EDContext = getDeclarationLexicalScope(*ED, QualType(Ty, 
0));
 llvm::DIFile *DefUnit = getOrCreateFile(ED->getLocation());

Would it be reasonable/possible to do these changes one at a time & demonstrate 
the different situations in which types were not correctly nested in lexical 
scopes? Or are they all necessary for some correctness/invariant that must hold?


http://reviews.llvm.org/D15977



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


Re: [PATCH] D16372: [CUDA] Make printf work.

2016-01-20 Thread Eric Christopher via cfe-commits
echristo accepted this revision.
echristo added a reviewer: echristo.
echristo added a comment.
This revision is now accepted and ready to land.

Looks reasonable to me.

-eric


http://reviews.llvm.org/D16372



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


Re: [PATCH] D15999: Adding doxygen comments to the LLVM intrinsics (part 2, _wmmintrin_pclmul.h)

2016-01-20 Thread Katya Romanova via cfe-commits
kromanova added a comment.

In http://reviews.llvm.org/D15999#331639, @silvas wrote:

> In http://reviews.llvm.org/D15999#331601, @kromanova wrote:
>
> >
>
>
> I don't think we did any testing at SCE, but we probably should have. I don't 
> think Google's primary codebases (nor Apple's, or anybody else pretty much) 
> include the intrinsic headers in basically every TU so the impact is probably 
> not a huge concern overall. However, games include these headers in basically 
> every TU so we at SCE should take a look.


Yes, typical PS4 codebase will heavily include x86 intrinsics headers. At the 
same time, typical PS4 codebase will use precompiled headers or modules for 
most of the time, so I hope the real world impact of doxygen comment will not 
be huge in any case. BTW, in my experiment, I'm planning to measure worst case 
scenario (no modules, no PCH). I think t(ahe benefit of having (1) tooltips and 
autocomplication in XCode, (2) Intellisense tooltips in MS Visual Studio, (3) 
internal intrinsics documentation for clang, (4) ability to generate up-to-date 
internal intrinsic documentation based on the latest Clang headers, etc, should 
overweigh the drawback of slower compile time for the applications/games that 
are heavily using intrinsic headers, but opted not to use modules or PCH. 
Still, I agree that we need to make this measurement. And I'm curious too :)


Repository:
  rL LLVM

http://reviews.llvm.org/D15999



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


Re: [PATCH] D15999: Adding doxygen comments to the LLVM intrinsics (part 2, _wmmintrin_pclmul.h)

2016-01-20 Thread Katya Romanova via cfe-commits
kromanova added a comment.

In http://reviews.llvm.org/D15999#331649, @silvas wrote:

> In http://reviews.llvm.org/D15999#331512, @kromanova wrote:
>
> > In http://reviews.llvm.org/D15999#330794, @silvas wrote:
> >
> > > Also, can you post a patch that changes "all" the headers to have doxygen 
> > > comments like you intend, so that others can test and verify?
> >
> >
> > Yes, I'll do this. However, there are a couple of things that the people 
> > should be aware:
> >  (a) *only* intrinsics that are supported on PS4 will have doxygen 
> > comments. PS4 documentation is parsed to generate these comments, and it 
> > doesn't document the intrinsics that are not supported on PS4.
>
>
> If we don't have coverage of every intrinsic, we will need to add 
> documentation for Clang developers about the comment format so that future 
> intrinsics (and intrinsics not covered) can be documented.


That was the plan... The consistency of the doxygen documentation will be 
especially important for the individuals/companies that decide to generate 
their up-to-date intrinsics guide based on the latest Clang headers. One 
doesn't want to see differently formatted intrinsics guide.

> 

> 

> > (b) the doxygen comments for the rest (not submitted upstream) headers 
> > files might have some problems (typos, incorrect parameter types, bugs in 
> > the description, etc). The tool that generates the comments might have some 
> > glitches too. Most of this things get fixed after the manual review that I 
> > do before I submit the Phabricator code review. So, please don't assume 
> > that this is the final version of the header files with doxygen comments.

> 

> 

> Sure. Makes sense.





Repository:
  rL LLVM

http://reviews.llvm.org/D15999



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


Re: [PATCH] D16177: Adding missing intrinsics _cvtsh_ss and _cvtss_sh

2016-01-20 Thread Katya Romanova via cfe-commits
kromanova updated this revision to Diff 45458.
kromanova added a comment.

Craig, thank you for the review. Here are the changes that you requested.
Katya.


Repository:
  rL LLVM

http://reviews.llvm.org/D16177

Files:
  lib/Headers/f16cintrin.h
  test/CodeGen/f16c-builtins.c

Index: test/CodeGen/f16c-builtins.c
===
--- test/CodeGen/f16c-builtins.c
+++ test/CodeGen/f16c-builtins.c
@@ -5,6 +5,18 @@
 
 #include 
 
+float test_cvtsh_ss(unsigned short a) {
+  // CHECK-LABEL: test_cvtsh_ss
+  // CHECK: @llvm.x86.vcvtph2ps.128
+  return _cvtsh_ss(a);
+}
+
+unsigned short test_cvtss_sh(float a) {
+  // CHECK-LABEL: test_cvtss_sh
+  // CHECK: @llvm.x86.vcvtps2ph.128
+  return _cvtss_sh(a, 0);
+}
+
 __m128 test_mm_cvtph_ps(__m128i a) {
   // CHECK-LABEL: test_mm_cvtph_ps
   // CHECK: @llvm.x86.vcvtph2ps.128
Index: lib/Headers/f16cintrin.h
===
--- lib/Headers/f16cintrin.h
+++ lib/Headers/f16cintrin.h
@@ -31,6 +31,20 @@
 /* Define the default attributes for the functions in this file. */
 #define __DEFAULT_FN_ATTRS __attribute__((__always_inline__, __nodebug__, 
__target__("f16c")))
 
+static __inline float __DEFAULT_FN_ATTRS
+_cvtsh_ss(unsigned short a)
+{
+  __v8hi v = {(short)a, 0, 0, 0, 0, 0, 0, 0};
+  __v4sf r = __builtin_ia32_vcvtph2ps(v);
+  return r[0];
+}
+
+#define _cvtss_sh(a, imm) __extension__ ({ \
+  __v8hi r = __builtin_ia32_vcvtps2ph((__v4sf){a, 0, 0, 0}, (imm)); \
+  (unsigned short)r[0]; \
+})
+
+
 #define _mm_cvtps_ph(a, imm) __extension__ ({ \
  (__m128i)__builtin_ia32_vcvtps2ph((__v4sf)(__m128)(a), (imm)); })
 


Index: test/CodeGen/f16c-builtins.c
===
--- test/CodeGen/f16c-builtins.c
+++ test/CodeGen/f16c-builtins.c
@@ -5,6 +5,18 @@
 
 #include 
 
+float test_cvtsh_ss(unsigned short a) {
+  // CHECK-LABEL: test_cvtsh_ss
+  // CHECK: @llvm.x86.vcvtph2ps.128
+  return _cvtsh_ss(a);
+}
+
+unsigned short test_cvtss_sh(float a) {
+  // CHECK-LABEL: test_cvtss_sh
+  // CHECK: @llvm.x86.vcvtps2ph.128
+  return _cvtss_sh(a, 0);
+}
+
 __m128 test_mm_cvtph_ps(__m128i a) {
   // CHECK-LABEL: test_mm_cvtph_ps
   // CHECK: @llvm.x86.vcvtph2ps.128
Index: lib/Headers/f16cintrin.h
===
--- lib/Headers/f16cintrin.h
+++ lib/Headers/f16cintrin.h
@@ -31,6 +31,20 @@
 /* Define the default attributes for the functions in this file. */
 #define __DEFAULT_FN_ATTRS __attribute__((__always_inline__, __nodebug__, __target__("f16c")))
 
+static __inline float __DEFAULT_FN_ATTRS
+_cvtsh_ss(unsigned short a)
+{
+  __v8hi v = {(short)a, 0, 0, 0, 0, 0, 0, 0};
+  __v4sf r = __builtin_ia32_vcvtph2ps(v);
+  return r[0];
+}
+
+#define _cvtss_sh(a, imm) __extension__ ({ \
+  __v8hi r = __builtin_ia32_vcvtps2ph((__v4sf){a, 0, 0, 0}, (imm)); \
+  (unsigned short)r[0]; \
+})
+
+
 #define _mm_cvtps_ph(a, imm) __extension__ ({ \
  (__m128i)__builtin_ia32_vcvtps2ph((__v4sf)(__m128)(a), (imm)); })
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [PATCH] D16163: [Concepts] Diagnose when return type of a function concept or declaration type of a variable concept is not bool.

2016-01-20 Thread Nathan Wilson via cfe-commits
nwilson marked an inline comment as done.


Comment at: test/CXX/concepts-ts/dcl.dcl/dcl.spec/dcl.spec.concept/p5.cpp:22
@@ +21,3 @@
+template
+concept float fcrtf() { return 5.5; } // expected-error {{declared return type 
of function concept must be 'bool'}}
+

The erroneous test which Hubert was referring to has been removed.


http://reviews.llvm.org/D16163



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


Re: [PATCH] D12354: [libcxx] Add global assertion handler for debug mode.

2016-01-20 Thread Duncan P. N. Exon Smith via cfe-commits
This patch looks correct to me.  Is there any reason it wasn't committed?

> On 2015-Aug-25, at 22:22, Eric Fiselier via cfe-commits 
>  wrote:
> 
> EricWF updated this revision to Diff 33180.
> EricWF added a comment.
> 
> Cleanup the diff and remove extra changes.
> 
> 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D12354&d=BQIFaQ&c=eEvniauFctOgLOKGJOplqw&r=vftFLnHiqThJHdL0qZWd_Vo12qdMVOZDFnNVBhP9GKA&m=U7NByLCkRhADU4iJuTcp4bdYr8db9hyBWz5vdyG9d9k&s=p55LOunlpKoM8BbE4UM64uYqBOSXkUng7Yd8WC7jU6o&e=
>  
> 
> Files:
>  include/__debug
>  include/algorithm
>  test/libcxx/algorithms/debug_less.pass.cpp
>  test/support/debug_mode.h
> 
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_cfe-2Dcommits&d=BQIGaQ&c=eEvniauFctOgLOKGJOplqw&r=vftFLnHiqThJHdL0qZWd_Vo12qdMVOZDFnNVBhP9GKA&m=U7NByLCkRhADU4iJuTcp4bdYr8db9hyBWz5vdyG9d9k&s=W7GVxJlvJ_-0FOp5ZM919JHm-EMk4b3Fs7iufvn60SI&e=
>  

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


Re: [PATCH] D12354: [libcxx] Add global assertion handler for debug mode.

2016-01-20 Thread Duncan P. N. Exon Smith via cfe-commits
dexonsmith added a subscriber: dexonsmith.
dexonsmith added a comment.

This patch looks correct to me.  Is there any reason it wasn't committed?


http://reviews.llvm.org/D12354



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


[PATCH] D16385: [OpenMP] Update map clause SEMA to support OpenMP 4.5 possible list items.

2016-01-20 Thread Samuel Antao via cfe-commits
sfantao created this revision.
sfantao added reviewers: ABataev, hfinkel, kkwli0, arpith-jacob, carlo.bertolli.
sfantao added subscribers: caomhin, fraggamuffin, cfe-commits.

Extend support in the map clause SEMA for the expressions supported in the 
OpenMP 4.5 specification, namely member expressions.  

Fix some bugs in the previous implementation of SEMA related with expressions 
that do not consist of single variable references.

Fix bug in parsing when the expression in the map clause do not start with an 
identifier: accept any expression in the map clause and check for validity in 
SEMA instead of just ignoring it.


http://reviews.llvm.org/D16385

Files:
  include/clang/Basic/DiagnosticSemaKinds.td
  lib/Parse/ParseOpenMP.cpp
  lib/Sema/SemaOpenMP.cpp
  test/OpenMP/target_map_messages.cpp

Index: test/OpenMP/target_map_messages.cpp
===
--- test/OpenMP/target_map_messages.cpp
+++ test/OpenMP/target_map_messages.cpp
@@ -1,5 +1,181 @@
 // RUN: %clang_cc1 -verify -fopenmp -ferror-limit 100 %s
 
+template 
+struct SA {
+  static int ss;
+  #pragma omp threadprivate(ss) // expected-note {{defined as threadprivate or thread local}}
+  float a;
+  int b[12];
+  float *c;
+  T d;
+  float e[I];
+  T *f;
+  void func(int arg) {
+#pragma omp target map(arg,a,d)
+{}
+#pragma omp target map(arg[2:2],a,d) // expected-error {{subscripted value is not an array or pointer}}
+{}
+#pragma omp target map(arg,a*2) // expected-error {{expected expression containing only member accesses and/or array sections based on named variables}}
+{}
+#pragma omp target map(arg,(c+1)[2]) // expected-error {{expected expression containing only member accesses and/or array sections based on named variables}}
+{}
+#pragma omp target map(arg,a[:2],d) // expected-error {{subscripted value is not an array or pointer}}
+{}
+#pragma omp target map(arg,a,d[:2]) // expected-error {{subscripted value is not an array or pointer}}
+{}
+
+#pragma omp target map(to:ss) // expected-error {{threadprivate variables are not allowed in map clause}}
+{}
+
+#pragma omp target map(to:b,e)
+{}
+#pragma omp target map(to:b,e) map(to:b) // expected-error {{variable already marked as mapped in current construct}} expected-note {{used here}}
+{}
+#pragma omp target map(to:b[:2],e)
+{}
+#pragma omp target map(to:b,e[:])
+{}
+
+#pragma omp target map(always, tofrom: c,f)
+{}
+#pragma omp target map(always, tofrom: c[1:2],f)
+{}
+#pragma omp target map(always, tofrom: c,f[1:2])
+{}
+#pragma omp target map(always, tofrom: c[:],f)   // expected-error {{section length is unspecified and cannot be inferred because subscripted value is not an array}}
+{}
+#pragma omp target map(always, tofrom: c,f[:])   // expected-error {{section length is unspecified and cannot be inferred because subscripted value is not an array}}
+{}
+return;
+  }
+};
+
+struct SB {
+  unsigned A;
+  unsigned B;
+  float Arr[100];
+  float *Ptr;
+  float *foo() {
+return &Arr[0];
+  }
+};
+
+struct SC {
+  unsigned A : 2;
+  unsigned B : 3;
+  unsigned C;
+  unsigned D;
+  float Arr[100];
+  SB S;
+  SB ArrS[100];
+  SB *PtrS;
+  SB *&RPtrS;
+  float *Ptr;
+
+  SC(SB *&_RPtrS) : RPtrS(_RPtrS) {}
+};
+
+union SD {
+  unsigned A;
+  float B;
+};
+
+void SAclient(int arg) {
+  SA s;
+  s.func(arg); // expected-note {{in instantiation of member function}}
+
+  SB *p;
+
+  SD u;
+  SC r(p),t(p);
+  #pragma omp target map(r)
+  {}
+  #pragma omp target map(r.ArrS[0].B)
+  {}
+  #pragma omp target map(r.ArrS[0].Arr[1:23])
+  {}
+  #pragma omp target map(r.ArrS[0].Error) // expected-error {{no member named 'Error' in 'SB'}}
+  {}
+  #pragma omp target map(r.ArrS[0].A, r.ArrS[1].A) // expected-error {{multiple array elements associated with the same variable are not allowed in map clauses of the same construct}} expected-note {{used here}}
+  {}
+  #pragma omp target map(r.ArrS[0].A, t.ArrS[1].A)
+  {}
+  #pragma omp target map(r.PtrS[0], r.PtrS->B) // expected-error {{same pointer derreferenced in multiple different ways in map clause expressions}} expected-note {{used here}}
+  {}
+  #pragma omp target map(r.RPtrS[0], r.RPtrS->B) // expected-error {{same pointer derreferenced in multiple different ways in map clause expressions}} expected-note {{used here}}
+  {}
+  #pragma omp target map(r.S.Arr[:12])
+  {}
+  #pragma omp target map(r.S.foo()[:12]) // expected-error {{expected expression containing only member accesses and/or array sections based on named variables}}
+  {}
+  #pragma omp target map(r.C, r.D)
+  {}
+  #pragma omp target map(r.C, r.C) // expected-error {{variable already marked as mapped in current construct}} expected-note {{used here}}
+  {}
+  #pragma omp target map(r.C) map(r.C) // expected-error {{variable already marked as mapped in current construct}} expected-note {{used here}}
+  {

Re: [PATCH] D15721: [Sema] Fix ICE on casting a vector of bools to a vector of T

2016-01-20 Thread George Burgess IV via cfe-commits
george.burgess.iv added a comment.

Ping :)


http://reviews.llvm.org/D15721



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


Re: [PATCH] D16179: [clang-tidy] Handle decayed types and other improvements in VirtualNearMiss check.

2016-01-20 Thread Gábor Horváth via cfe-commits
xazax.hun added inline comments.


Comment at: clang-tidy/misc/VirtualNearMissCheck.cpp:54-55
@@ -53,16 +53,4 @@
 
   // Both types must be pointers or references to classes.
-  if (const auto *DerivedPT = DerivedReturnTy->getAs()) {
-if (const auto *BasePT = BaseReturnTy->getAs()) {
-  DTy = DerivedPT->getPointeeType();
-  BTy = BasePT->getPointeeType();
-}
-  } else if (const auto *DerivedRT = DerivedReturnTy->getAs()) {
-if (const auto *BaseRT = BaseReturnTy->getAs()) {
-  DTy = DerivedRT->getPointeeType();
-  BTy = BaseRT->getPointeeType();
-}
-  }
-
-  // The return types aren't either both pointers or references to a class 
type.
-  if (DTy.isNull())
+  if ((!BaseReturnTy->isPointerType() || !DerivedReturnTy->isPointerType()) &&
+  (!BaseReturnTy->isReferenceType() || 
!DerivedReturnTy->isReferenceType()))

LegalizeAdulthood wrote:
> alexfh wrote:
> > It takes a non-trivial effort to understand the equivalence of the comment 
> > and the condition. I think, pulling the negations one level up would make 
> > the condition read easier:
> > ```
> > if (!(BaseReturnTy->isPointerType() && DerivedReturnTy->isPointerType()) &&
> > !(BaseReturnTy->isReferenceType() && 
> > DerivedReturnTy->isReferenceType()))
> >   return;
> > ```
> > 
> > Also, please move the definitions of the variables `BTy`, `DTy`, `BRD`, 
> > `DRD` after this `if` and merge them with their initialization. 
> IMO, it would be even better would be to extract a predicate function with an 
> intention-revealing name.
I could not come up with a good name, so I left it as it is. If you have 
something in mind, feel free to tell me.


http://reviews.llvm.org/D16179



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


Re: [PATCH] D16179: [clang-tidy] Handle decayed types and other improvements in VirtualNearMiss check.

2016-01-20 Thread Gábor Horváth via cfe-commits
xazax.hun updated this revision to Diff 45482.
xazax.hun marked an inline comment as done.
xazax.hun added a comment.

- Addressed review comments.


http://reviews.llvm.org/D16179

Files:
  clang-tidy/misc/VirtualNearMissCheck.cpp
  clang-tidy/misc/VirtualNearMissCheck.h
  test/clang-tidy/misc-virtual-near-miss.cpp

Index: test/clang-tidy/misc-virtual-near-miss.cpp
===
--- test/clang-tidy/misc-virtual-near-miss.cpp
+++ test/clang-tidy/misc-virtual-near-miss.cpp
@@ -3,6 +3,8 @@
 struct Base {
   virtual void func();
   virtual void gunk();
+  virtual ~Base();
+  virtual Base &operator=(const Base &);
 };
 
 struct Derived : Base {
@@ -20,6 +22,8 @@
 
   void fun();
   // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: method 'Derived::fun' has {{.*}} 'Base::func'
+
+  Derived &operator==(const Base &); // Should not warn: operators are ignored.
 };
 
 class Father {
@@ -36,6 +40,7 @@
   static void method();
   virtual int method(int argc, const char **argv);
   virtual int method(int argc) const;
+  virtual int decay(const char *str);
 };
 
 class Child : private Father, private Mother {
@@ -47,7 +52,8 @@
 
   int methoe(int x, char **strs); // Should not warn: parameter types don't match.
 
-  int methoe(int x); // Should not warn: method is not const.
+  int methoe(int x);
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: method 'Child::methoe' has {{.*}} 'Mother::method'
 
   void methof(int x, const char **strs); // Should not warn: return types don't match.
 
@@ -60,6 +66,10 @@
   virtual Derived &&generat();
   // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: method 'Child::generat' has {{.*}} 'Father::generate'
 
+  int decaz(const char str[]);
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: method 'Child::decaz' has {{.*}} 'Mother::decay'
+
 private:
-  void funk(); // Should not warn: access qualifers don't match.
+  void funk();
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: method 'Child::funk' has {{.*}} 'Father::func'
 };
Index: clang-tidy/misc/VirtualNearMissCheck.h
===
--- clang-tidy/misc/VirtualNearMissCheck.h
+++ clang-tidy/misc/VirtualNearMissCheck.h
@@ -34,7 +34,7 @@
 
 private:
   /// Check if the given method is possible to be overridden by some other
-  /// method.
+  /// method. Operators and destructors are excluded.
   ///
   /// Results are memoized in PossibleMap.
   bool isPossibleToBeOverridden(const CXXMethodDecl *BaseMD);
Index: clang-tidy/misc/VirtualNearMissCheck.cpp
===
--- clang-tidy/misc/VirtualNearMissCheck.cpp
+++ clang-tidy/misc/VirtualNearMissCheck.cpp
@@ -45,31 +45,20 @@
 return true;
 
   /// Check if the return types are covariant.
-  /// BTy is the class type in return type of BaseMD. For example,
-  ///B* Base::md()
-  /// While BRD is the declaration of B.
-  QualType BTy, DTy;
-  const CXXRecordDecl *BRD, *DRD;
 
   // Both types must be pointers or references to classes.
-  if (const auto *DerivedPT = DerivedReturnTy->getAs()) {
-if (const auto *BasePT = BaseReturnTy->getAs()) {
-  DTy = DerivedPT->getPointeeType();
-  BTy = BasePT->getPointeeType();
-}
-  } else if (const auto *DerivedRT = DerivedReturnTy->getAs()) {
-if (const auto *BaseRT = BaseReturnTy->getAs()) {
-  DTy = DerivedRT->getPointeeType();
-  BTy = BaseRT->getPointeeType();
-}
-  }
-
-  // The return types aren't either both pointers or references to a class type.
-  if (DTy.isNull())
+  if (!(BaseReturnTy->isPointerType() && DerivedReturnTy->isPointerType()) &&
+  !(BaseReturnTy->isReferenceType() && DerivedReturnTy->isReferenceType()))
 return false;
 
-  DRD = DTy->getAsCXXRecordDecl();
-  BRD = BTy->getAsCXXRecordDecl();
+  /// BTy is the class type in return type of BaseMD. For example,
+  ///B* Base::md()
+  /// While BRD is the declaration of B.
+  QualType DTy = DerivedReturnTy->getPointeeType();
+  QualType BTy = BaseReturnTy->getPointeeType();
+
+  const CXXRecordDecl *DRD = DTy->getAsCXXRecordDecl();
+  const CXXRecordDecl *BRD = BTy->getAsCXXRecordDecl();
   if (DRD == nullptr || BRD == nullptr)
 return false;
 
@@ -116,6 +105,13 @@
   return true;
 }
 
+/// \returns decayed type for arrays and functions.
+static QualType getDecayedType(QualType Type) {
+  if (const auto *Decayed = Type->getAs())
+return Decayed->getDecayedType();
+  return Type;
+}
+
 /// \returns true if the param types are the same.
 static bool checkParamTypes(const CXXMethodDecl *BaseMD,
 const CXXMethodDecl *DerivedMD) {
@@ -125,8 +121,8 @@
 return false;
 
   for (unsigned I = 0; I < NumParamA; I++) {
-if (BaseMD->getParamDecl(I)->getType() !=
-DerivedMD->getParamDecl(I)->getType())
+if (getDecayedType(BaseMD->getParamDecl(I)->getType()) !=
+getDecayedType(DerivedMD->getParamDecl(I)->getType()))
   return false;
   }

[PATCH] D16394: Add an isVirtualAsWritten AST matcher.

2016-01-20 Thread Nico Weber via cfe-commits
thakis created this revision.
thakis added a reviewer: aaron.ballman.
thakis added a subscriber: cfe-commits.
Herald added a subscriber: klimek.

http://reviews.llvm.org/D16394

Files:
  docs/LibASTMatchersReference.html
  include/clang/ASTMatchers/ASTMatchers.h
  lib/ASTMatchers/Dynamic/Registry.cpp
  unittests/ASTMatchers/ASTMatchersTest.cpp

Index: unittests/ASTMatchers/ASTMatchersTest.cpp
===
--- unittests/ASTMatchers/ASTMatchersTest.cpp
+++ unittests/ASTMatchers/ASTMatchersTest.cpp
@@ -2028,6 +2028,16 @@
   EXPECT_TRUE(notMatches("class X { int f(); };", cxxMethodDecl(isVirtual(;
 }
 
+TEST(Matcher, MatchesVirtualAsWrittenMethod) {
+  EXPECT_TRUE(matches("class A { virtual int f(); };"
+  "class B : public A { int f(); };",
+  cxxMethodDecl(isVirtualAsWritten(), hasName("::A::f";
+  EXPECT_TRUE(
+  notMatches("class A { virtual int f(); };"
+ "class B : public A { int f(); };",
+ cxxMethodDecl(isVirtualAsWritten(), hasName("::B::f";
+}
+
 TEST(Matcher, MatchesPureMethod) {
   EXPECT_TRUE(matches("class X { virtual int f() = 0; };",
   cxxMethodDecl(isPure(), hasName("::X::f";
Index: docs/LibASTMatchersReference.html
===
--- docs/LibASTMatchersReference.html
+++ docs/LibASTMatchersReference.html
@@ -1845,6 +1845,20 @@
   matches A::x
 
 
+MatcherCXXMethodDecl>isVirtualAsWritten
+Matches if the 
given method declaration has an explicit "virtual".
+
+Given
+  class A {
+   public:
+virtual void x();
+  };
+  class B : public A {
+   public:
+void x();
+  };
+  matches A::x but not B::x
+
 
 MatcherCXXOperatorCallExpr>hasOverloadedOperatorNameStringRef
 Name
 Matches 
overloaded operator names.
Index: include/clang/ASTMatchers/ASTMatchers.h
===
--- include/clang/ASTMatchers/ASTMatchers.h
+++ include/clang/ASTMatchers/ASTMatchers.h
@@ -3479,6 +3479,24 @@
   return Node.isVirtual();
 }
 
+/// \brief Matches if the given method declaration has an explicit "virtual".
+///
+/// Given
+/// \code
+///   class A {
+///public:
+/// virtual void x();
+///   };
+///   class B : public A {
+///public:
+/// void x();
+///   };
+/// \endcode
+///   matches A::x but not B::x
+AST_MATCHER(CXXMethodDecl, isVirtualAsWritten) {
+  return Node.isVirtualAsWritten();
+}
+
 /// \brief Matches if the given method or class declaration is final.
 ///
 /// Given:
Index: lib/ASTMatchers/Dynamic/Registry.cpp
===
--- lib/ASTMatchers/Dynamic/Registry.cpp
+++ lib/ASTMatchers/Dynamic/Registry.cpp
@@ -302,6 +302,7 @@
   REGISTER_MATCHER(isUnion);
   REGISTER_MATCHER(isVariadic);
   REGISTER_MATCHER(isVirtual);
+  REGISTER_MATCHER(isVirtualAsWritten);
   REGISTER_MATCHER(isVolatileQualified);
   REGISTER_MATCHER(isWritten);
   REGISTER_MATCHER(labelStmt);


Index: unittests/ASTMatchers/ASTMatchersTest.cpp
===
--- unittests/ASTMatchers/ASTMatchersTest.cpp
+++ unittests/ASTMatchers/ASTMatchersTest.cpp
@@ -2028,6 +2028,16 @@
   EXPECT_TRUE(notMatches("class X { int f(); };", cxxMethodDecl(isVirtual(;
 }
 
+TEST(Matcher, MatchesVirtualAsWrittenMethod) {
+  EXPECT_TRUE(matches("class A { virtual int f(); };"
+  "class B : public A { int f(); };",
+  cxxMethodDecl(isVirtualAsWritten(), hasName("::A::f";
+  EXPECT_TRUE(
+  notMatches("class A { virtual int f(); };"
+ "class B : public A { int f(); };",
+ cxxMethodDecl(isVirtualAsWritten(), hasName("::B::f";
+}
+
 TEST(Matcher, MatchesPureMethod) {
   EXPECT_TRUE(matches("class X { virtual int f() = 0; };",
   cxxMethodDecl(isPure(), hasName("::X::f";
Index: docs/LibASTMatchersReference.html
===
--- docs/LibASTMatchersReference.html
+++ docs/LibASTMatchersReference.html
@@ -1845,6 +1845,20 @@
   matches A::x
 
 
+MatcherCXXMethodDecl>isVirtualAsWritten
+Matches if the given method declaration has an explicit "virtual".
+
+Given
+  class A {
+   public:
+virtual void x();
+  };
+  class B : public A {
+   public:
+void x();
+  };
+  matches A::x but not B::x
+
 
 MatcherCXXOperatorCallExpr>hasOverloadedOperatorNameStringRef Name
 Matches overloaded operator names.
Index: include/clang/ASTMatchers/ASTMatchers.h
===
--- include/clang/ASTMa

Re: [PATCH] D16385: [OpenMP] Update map clause SEMA to support OpenMP 4.5 possible list items.

2016-01-20 Thread Alexey Bataev via cfe-commits
ABataev added a comment.

Please, update your workspace to latest version, many changes are in trunk 
already


http://reviews.llvm.org/D16385



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


Re: [PATCH] D16394: Add an isVirtualAsWritten AST matcher.

2016-01-20 Thread Manuel Klimek via cfe-commits
klimek accepted this revision.
klimek added a reviewer: klimek.
klimek added a comment.
This revision is now accepted and ready to land.

lg


http://reviews.llvm.org/D16394



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


Re: [PATCH] D16177: Adding missing intrinsics _cvtsh_ss and _cvtss_sh

2016-01-20 Thread Craig Topper via cfe-commits
craig.topper added inline comments.


Comment at: lib/Headers/f16cintrin.h:47
@@ -34,1 +46,3 @@
+
+
 #define _mm_cvtps_ph(a, imm) __extension__ ({ \

Can we do something like this to remove the last temporary?

#define _cvtss_sh(a, imm) __extension__ ({ \
  (unsigned short)((__v8hi)__builtin_ia32_vcvtps2ph((__v4sf){a, 0, 0, 0}, 
(imm))[0]); \
})


Repository:
  rL LLVM

http://reviews.llvm.org/D16177



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


RE: D16358: [OpenMP] Parsing + Sema for nowait clause on target directive

2016-01-20 Thread Hahnfeld, Jonas via cfe-commits
Hi Alexey,

Phabricator doesn't send mails when only the review state changes as mentioned 
in documentation. This makes following the current status hard when relying on 
them.
Could you therefore please type a "LGTM" which should trigger an email to the 
mailing list?

Thanks,
Jonas

> -Original Message-
> From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf
> Of Arpith Jacob via cfe-commits
> Sent: Wednesday, January 20, 2016 5:56 PM
> To: acja...@us.ibm.com; a.bat...@hotmail.com; kkw...@gmail.com;
> hfin...@anl.gov; sfan...@us.ibm.com; cber...@us.ibm.com
> Cc: caom...@us.ibm.com; cfe-commits@lists.llvm.org
> Subject: [PATCH] D16358: [OpenMP] Parsing + Sema for nowait clause on
> target directive
>
> arpith-jacob created this revision.
> arpith-jacob added reviewers: ABataev, kkwli0, hfinkel, sfantao,
> carlo.bertolli.
> arpith-jacob added subscribers: cfe-commits, caomhin, fraggamuffin.
>
> Allow nowait clause on target directive in sema and add test cases.
>
> http://reviews.llvm.org/D16358
>
> Files:
>   include/clang/Basic/OpenMPKinds.def
>   test/OpenMP/target_ast_print.cpp
>   test/OpenMP/target_nowait_messages.cpp
>
> Index: test/OpenMP/target_nowait_messages.cpp
> ==
> =
> --- /dev/null
> +++ test/OpenMP/target_nowait_messages.cpp
> @@ -0,0 +1,17 @@
> +// RUN: %clang_cc1 -triple x86_64-apple-macos10.7.0 -verify -fopenmp
> +-ferror-limit 100 -o - %s
> +
> +void foo() {
> +}
> +
> +int main(int argc, char **argv) {
> +  #pragma omp target nowait( // expected-warning {{extra tokens at the
> +end of '#pragma omp target' are ignored}}
> +  foo();
> +  #pragma omp target nowait (argc)) // expected-warning {{extra tokens
> +at the end of '#pragma omp target' are ignored}}
> +  foo();
> +  #pragma omp target nowait device (-10u)
> +  foo();
> +  #pragma omp target nowait (3.14) device (-10u) // expected-warning
> +{{extra tokens at the end of '#pragma omp target' are ignored}}
> +  foo();
> +
> +  return 0;
> +}
> Index: test/OpenMP/target_ast_print.cpp
> ==
> =
> --- test/OpenMP/target_ast_print.cpp
> +++ test/OpenMP/target_ast_print.cpp
> @@ -25,6 +25,8 @@
>foo();
>  #pragma omp target map(always,alloc: i)
>foo();
> +#pragma omp target nowait
> +  foo();
>return 0;
>  }
>
> @@ -44,6 +46,8 @@
>  // CHECK-NEXT: foo()
>  // CHECK-NEXT: #pragma omp target map(always,alloc: i)  // CHECK-NEXT:
> foo()
> +// CHECK-NEXT: #pragma omp target nowait // CHECK-NEXT: foo()
>  // CHECK: template  char tmain(char argc, 
> char
> *argv) {  // CHECK-NEXT: char i, j, a[20]  // CHECK-NEXT: #pragma omp target
> @@ -60,6 +64,8 @@  // CHECK-NEXT: foo()  // CHECK-NEXT: #pragma omp
> target map(always,alloc: i)  // CHECK-NEXT: foo()
> +// CHECK-NEXT: #pragma omp target nowait // CHECK-NEXT: foo()
>  // CHECK: template  T tmain(T argc, T *argv) {  // 
> CHECK-
> NEXT: T i, j, a[20]  // CHECK-NEXT: #pragma omp target @@ -76,6 +82,8 @@
> // CHECK-NEXT: foo()  // CHECK-NEXT: #pragma omp target
> map(always,alloc: i)  // CHECK-NEXT: foo()
> +// CHECK-NEXT: #pragma omp target nowait // CHECK-NEXT: foo()
>
>  // CHECK-LABEL: int main(int argc, char **argv) {  int main (int argc, char
> **argv) { @@ -115,6 +123,11 @@
>foo();
>  // CHECK-NEXT: foo();
>
> +#pragma omp target nowait
> +// CHECK-NEXT: #pragma omp target nowait
> +  foo();
> +// CHECK-NEXT: foo();
> +
>return tmain(argc, &argc) + tmain(argv[0][0], 
> rgv[0]);  }
>
> Index: include/clang/Basic/OpenMPKinds.def
> ==
> =
> --- include/clang/Basic/OpenMPKinds.def
> +++ include/clang/Basic/OpenMPKinds.def
> @@ -355,6 +355,7 @@
>  OPENMP_TARGET_CLAUSE(device)
>  OPENMP_TARGET_CLAUSE(map)
>  OPENMP_TARGET_CLAUSE(private)
> +OPENMP_TARGET_CLAUSE(nowait)
>
>  // Clauses allowed for OpenMP directive 'target data'.
>  // TODO More clauses for 'target data' directive.
>



smime.p7s
Description: S/MIME cryptographic signature
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D16395: [Coverage] Reduce complexity of adding function mapping records

2016-01-20 Thread Vedant Kumar via cfe-commits
vsk created this revision.
vsk added a reviewer: davidxl.
vsk added a subscriber: cfe-commits.

Replace a string append operation in addFunctionMappingRecord with a
vector append. The existing behavior is quadratic in the worst case:
this patch makes it linear.

http://reviews.llvm.org/D16395

Files:
  lib/CodeGen/CoverageMappingGen.cpp
  lib/CodeGen/CoverageMappingGen.h

Index: lib/CodeGen/CoverageMappingGen.h
===
--- lib/CodeGen/CoverageMappingGen.h
+++ lib/CodeGen/CoverageMappingGen.h
@@ -56,7 +56,7 @@
   std::vector FunctionRecords;
   std::vector FunctionNames;
   llvm::StructType *FunctionRecordTy;
-  std::string CoverageMappings;
+  std::vector CoverageMappings;
 
 public:
   CoverageMappingModuleGen(CodeGenModule &CGM, CoverageSourceInfo &SourceInfo)
Index: lib/CodeGen/CoverageMappingGen.cpp
===
--- lib/CodeGen/CoverageMappingGen.cpp
+++ lib/CodeGen/CoverageMappingGen.cpp
@@ -15,6 +15,7 @@
 #include "CodeGenFunction.h"
 #include "clang/AST/StmtVisitor.h"
 #include "clang/Lex/Lexer.h"
+#include "llvm/ADT/StringExtras.h"
 #include "llvm/ADT/Optional.h"
 #include "llvm/ProfileData/CoverageMapping.h"
 #include "llvm/ProfileData/CoverageMappingReader.h"
@@ -932,7 +933,7 @@
   if (!IsUsed)
 FunctionNames.push_back(
 llvm::ConstantExpr::getBitCast(NamePtr, 
llvm::Type::getInt8PtrTy(Ctx)));
-  CoverageMappings += CoverageMapping;
+  CoverageMappings.push_back(CoverageMapping);
 
   if (CGM.getCodeGenOpts().DumpCoverageMapping) {
 // Dump the coverage mapping data for this function by decoding the
@@ -978,8 +979,10 @@
   std::string FilenamesAndCoverageMappings;
   llvm::raw_string_ostream OS(FilenamesAndCoverageMappings);
   CoverageFilenamesSectionWriter(FilenameRefs).write(OS);
-  OS << CoverageMappings;
-  size_t CoverageMappingSize = CoverageMappings.size();
+  std::string RawCoverageMappings =
+  llvm::join(CoverageMappings.begin(), CoverageMappings.end(), "");
+  OS << RawCoverageMappings;
+  size_t CoverageMappingSize = RawCoverageMappings.size();
   size_t FilenamesSize = OS.str().size() - CoverageMappingSize;
   // Append extra zeroes if necessary to ensure that the size of the filenames
   // and coverage mappings is a multiple of 8.


Index: lib/CodeGen/CoverageMappingGen.h
===
--- lib/CodeGen/CoverageMappingGen.h
+++ lib/CodeGen/CoverageMappingGen.h
@@ -56,7 +56,7 @@
   std::vector FunctionRecords;
   std::vector FunctionNames;
   llvm::StructType *FunctionRecordTy;
-  std::string CoverageMappings;
+  std::vector CoverageMappings;
 
 public:
   CoverageMappingModuleGen(CodeGenModule &CGM, CoverageSourceInfo &SourceInfo)
Index: lib/CodeGen/CoverageMappingGen.cpp
===
--- lib/CodeGen/CoverageMappingGen.cpp
+++ lib/CodeGen/CoverageMappingGen.cpp
@@ -15,6 +15,7 @@
 #include "CodeGenFunction.h"
 #include "clang/AST/StmtVisitor.h"
 #include "clang/Lex/Lexer.h"
+#include "llvm/ADT/StringExtras.h"
 #include "llvm/ADT/Optional.h"
 #include "llvm/ProfileData/CoverageMapping.h"
 #include "llvm/ProfileData/CoverageMappingReader.h"
@@ -932,7 +933,7 @@
   if (!IsUsed)
 FunctionNames.push_back(
 llvm::ConstantExpr::getBitCast(NamePtr, llvm::Type::getInt8PtrTy(Ctx)));
-  CoverageMappings += CoverageMapping;
+  CoverageMappings.push_back(CoverageMapping);
 
   if (CGM.getCodeGenOpts().DumpCoverageMapping) {
 // Dump the coverage mapping data for this function by decoding the
@@ -978,8 +979,10 @@
   std::string FilenamesAndCoverageMappings;
   llvm::raw_string_ostream OS(FilenamesAndCoverageMappings);
   CoverageFilenamesSectionWriter(FilenameRefs).write(OS);
-  OS << CoverageMappings;
-  size_t CoverageMappingSize = CoverageMappings.size();
+  std::string RawCoverageMappings =
+  llvm::join(CoverageMappings.begin(), CoverageMappings.end(), "");
+  OS << RawCoverageMappings;
+  size_t CoverageMappingSize = RawCoverageMappings.size();
   size_t FilenamesSize = OS.str().size() - CoverageMappingSize;
   // Append extra zeroes if necessary to ensure that the size of the filenames
   // and coverage mappings is a multiple of 8.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


  1   2   >