[clang-tools-extra] r260944 - clang-tools-extra/test/Unit/lit.site.cfg.in: Prune on_clone. I guess it has been unused since r188006.

[NAKAMURA Takumi via cfe-commits]

Author: chapuni
Date: Tue Feb 16 02:13:36 2016
New Revision: 260944

URL: http://llvm.org/viewvc/llvm-project?rev=260944&view=rev
Log:
clang-tools-extra/test/Unit/lit.site.cfg.in: Prune on_clone. I guess it has 
been unused since r188006.

Modified:
clang-tools-extra/trunk/test/Unit/lit.site.cfg.in

Modified: clang-tools-extra/trunk/test/Unit/lit.site.cfg.in
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/Unit/lit.site.cfg.in?rev=260944&r1=260943&r2=260944&view=diff
==
--- clang-tools-extra/trunk/test/Unit/lit.site.cfg.in (original)
+++ clang-tools-extra/trunk/test/Unit/lit.site.cfg.in Tue Feb 16 02:13:36 2016
@@ -6,10 +6,4 @@ config.llvm_libs_dir = "@LLVM_LIBS_DIR@"
 config.shlibdir = "@SHLIBDIR@"
 config.target_triple = "@TARGET_TRIPLE@"
 
-# Make sure any custom vars defined above that are required in lit.local.cfg
-# files are made available.
-def on_clone(parent, clone, path):
-  clone.extra_tools_src_dir = parent.extra_tools_src_dir
-
-config.on_clone = on_clone
 lit_config.load_config(config, "@CLANG_TOOLS_SOURCE_DIR@/test/Unit/lit.cfg")


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

[PATCH] D17286: Make FreeBSD and NetBSD use CLANG_DEFAULT_CXX_STDLIB

[Jonas Hahnfeld via cfe-commits]

Hahnfeld created this revision.
Hahnfeld added reviewers: rsmith, t.p.northover.
Hahnfeld added a subscriber: cfe-commits.
Herald added a subscriber: emaste.

Also introduce `-stdlib=default` to override the configured value and use it to 
make the tests always pass.

http://reviews.llvm.org/D17286

Files:
  lib/Driver/ToolChain.cpp
  lib/Driver/ToolChains.cpp
  lib/Driver/ToolChains.h
  test/Driver/freebsd.cpp
  test/Driver/netbsd.cpp

Index: test/Driver/netbsd.cpp
===
--- test/Driver/netbsd.cpp
+++ test/Driver/netbsd.cpp
@@ -1,93 +1,93 @@
 // RUN: %clangxx -no-canonical-prefixes -target x86_64--netbsd \
-// RUN: --sysroot=%S/Inputs/basic_netbsd_tree %s -### 2>&1 \
+// RUN: -stdlib=default --sysroot=%S/Inputs/basic_netbsd_tree %s -### 2>&1 \
 // RUN: | FileCheck -check-prefix=X86_64 %s
 // RUN: %clangxx -no-canonical-prefixes -target x86_64--netbsd7.0.0 \
-// RUN: --sysroot=%S/Inputs/basic_netbsd_tree %s -### 2>&1 \
+// RUN: -stdlib=default --sysroot=%S/Inputs/basic_netbsd_tree %s -### 2>&1 \
 // RUN: | FileCheck -check-prefix=X86_64-7 %s
 // RUN: %clangxx -no-canonical-prefixes -target x86_64--netbsd6.0.0 \
-// RUN: --sysroot=%S/Inputs/basic_netbsd_tree %s -### 2>&1 \
+// RUN: -stdlib=default --sysroot=%S/Inputs/basic_netbsd_tree %s -### 2>&1 \
 // RUN: | FileCheck -check-prefix=X86_64-6 %s
 // RUN: %clangxx -no-canonical-prefixes -target arm--netbsd6.0.0-eabi \
-// RUN: --sysroot=%S/Inputs/basic_netbsd_tree %s -### 2>&1 \
+// RUN: -stdlib=default --sysroot=%S/Inputs/basic_netbsd_tree %s -### 2>&1 \
 // RUN: | FileCheck -check-prefix=ARM %s
 // RUN: %clangxx -no-canonical-prefixes -target arm--netbsd7.0.0-eabi \
-// RUN: --sysroot=%S/Inputs/basic_netbsd_tree %s -### 2>&1 \
+// RUN: -stdlib=default --sysroot=%S/Inputs/basic_netbsd_tree %s -### 2>&1 \
 // RUN: | FileCheck -check-prefix=ARM-7 %s
 // RUN: %clangxx -no-canonical-prefixes -target aarch64--netbsd \
-// RUN: --sysroot=%S/Inputs/basic_netbsd_tree %s -### 2>&1 \
+// RUN: -stdlib=default --sysroot=%S/Inputs/basic_netbsd_tree %s -### 2>&1 \
 // RUN: | FileCheck -check-prefix=AARCH64 %s
 // RUN: %clangxx -no-canonical-prefixes -target aarch64--netbsd7.0.0 \
-// RUN: --sysroot=%S/Inputs/basic_netbsd_tree %s -### 2>&1 \
+// RUN: -stdlib=default --sysroot=%S/Inputs/basic_netbsd_tree %s -### 2>&1 \
 // RUN: | FileCheck -check-prefix=AARCH64-7 %s
 // RUN: %clangxx -no-canonical-prefixes -target sparc--netbsd \
-// RUN: --sysroot=%S/Inputs/basic_netbsd_tree %s -### 2>&1 \
+// RUN: -stdlib=default --sysroot=%S/Inputs/basic_netbsd_tree %s -### 2>&1 \
 // RUN: | FileCheck -check-prefix=SPARC %s
 // RUN: %clangxx -no-canonical-prefixes -target sparc--netbsd6.0.0 \
-// RUN: --sysroot=%S/Inputs/basic_netbsd_tree %s -### 2>&1 \
+// RUN: -stdlib=default --sysroot=%S/Inputs/basic_netbsd_tree %s -### 2>&1 \
 // RUN: | FileCheck -check-prefix=SPARC-6 %s
 // RUN: %clangxx -no-canonical-prefixes -target sparc--netbsd7.0.0 \
-// RUN: --sysroot=%S/Inputs/basic_netbsd_tree %s -### 2>&1 \
+// RUN: -stdlib=default --sysroot=%S/Inputs/basic_netbsd_tree %s -### 2>&1 \
 // RUN: | FileCheck -check-prefix=SPARC-7 %s
 // RUN: %clangxx -no-canonical-prefixes -target sparc64--netbsd \
-// RUN: --sysroot=%S/Inputs/basic_netbsd_tree %s -### 2>&1 \
+// RUN: -stdlib=default --sysroot=%S/Inputs/basic_netbsd_tree %s -### 2>&1 \
 // RUN: | FileCheck -check-prefix=SPARC64 %s
 // RUN: %clangxx -no-canonical-prefixes -target sparc64--netbsd6.0.0 \
-// RUN: --sysroot=%S/Inputs/basic_netbsd_tree %s -### 2>&1 \
+// RUN: -stdlib=default --sysroot=%S/Inputs/basic_netbsd_tree %s -### 2>&1 \
 // RUN: | FileCheck -check-prefix=SPARC64-6 %s
 // RUN: %clangxx -no-canonical-prefixes -target sparc64--netbsd7.0.0 \
-// RUN: --sysroot=%S/Inputs/basic_netbsd_tree %s -### 2>&1 \
+// RUN: -stdlib=default --sysroot=%S/Inputs/basic_netbsd_tree %s -### 2>&1 \
 // RUN: | FileCheck -check-prefix=SPARC64-7 %s
 // RUN: %clangxx -no-canonical-prefixes -target powerpc--netbsd \
-// RUN: --sysroot=%S/Inputs/basic_netbsd_tree %s -### 2>&1 \
+// RUN: -stdlib=default --sysroot=%S/Inputs/basic_netbsd_tree %s -### 2>&1 \
 // RUN: | FileCheck -check-prefix=POWERPC %s
 // RUN: %clangxx -no-canonical-prefixes -target powerpc64--netbsd \
-// RUN: --sysroot=%S/Inputs/basic_netbsd_tree %s -### 2>&1 \
+// RUN: -stdlib=default --sysroot=%S/Inputs/basic_netbsd_tree %s -### 2>&1 \
 // RUN: | FileCheck -check-prefix=POWERPC64 %s
 
 // RUN: %clangxx -no-canonical-prefixes -target x86_64--netbsd -static \
-// RUN: --sysroot=%S/Inputs/basic_netbsd_tree %s -### 2>&1 \
+// RUN: -stdlib=default --sysroot=%S/Inputs/basic_netbsd_tree %s -### 2>&1 \
 // RUN: | FileCheck -check-prefix=S-X86_64 %s
 // RUN: %clangxx -no-canonical-prefixes -target x86_64--netbsd7.0.0 -static \
-// RUN: --sysroot=%S/Inputs/basic_netbsd_tree %s -### 2>&1 \
+// RUN: -stdlib=default --sysroot=%S/Inputs/basic_netbsd_tree %s -### 2>&1 \
 // RUN: | FileCheck -check-prefix=S-X86_64-7 %s
 // RUN: %clangxx -no

Re: [PATCH] D16686: [OpenCL] Generate metadata for opencl_unroll_hint attribute

[Pekka Jääskeläinen via cfe-commits]

pekka.jaaskelainen accepted this revision.
pekka.jaaskelainen added a comment.

LGTM.


http://reviews.llvm.org/D16686



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

Re: [PATCH] D16928: [OpenCL] Apply missing restrictions for Blocks in OpenCL v2.0

[Pekka Jääskeläinen via cfe-commits]

pekka.jaaskelainen added inline comments.


Comment at: test/SemaOpenCL/invalid-func.cl:6
@@ +5,2 @@
+void foo(int, ...); // expected-error{{OpenCL does not allow variadic 
arguments}}
+int printf(const char *, ...);

I wonder should we check for the fingerprint too when letting printf() pass?
This is not the correct OpenCL printf() as the first argument should be in 
constant address space.


http://reviews.llvm.org/D16928



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

Re: [PATCH] D16953: Enhance clang-tidy modernize-redundant-void-arg check to apply fixes to header files

[Alexander Kornienko via cfe-commits]

alexfh added a comment.

Unfortunately, the review of the changes in the script might take some time. I 
think, we can submit the fix itself already and work on the rest of the patch 
after that.


http://reviews.llvm.org/D16953



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

Re: [PATCH] D16953: Enhance clang-tidy modernize-redundant-void-arg check to apply fixes to header files

[Alexander Kornienko via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL260948: [clang-tidy] Enhance modernize-redundant-void-arg 
check to apply fixes to… (authored by alexfh).

Changed prior to commit:
  http://reviews.llvm.org/D16953?vs=47319&id=48054#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D16953

Files:
  clang-tools-extra/trunk/clang-tidy/modernize/RedundantVoidArgCheck.cpp

Index: clang-tools-extra/trunk/clang-tidy/modernize/RedundantVoidArgCheck.cpp
===
--- clang-tools-extra/trunk/clang-tidy/modernize/RedundantVoidArgCheck.cpp
+++ clang-tools-extra/trunk/clang-tidy/modernize/RedundantVoidArgCheck.cpp
@@ -46,42 +46,30 @@
 namespace modernize {
 
 void RedundantVoidArgCheck::registerMatchers(MatchFinder *Finder) {
-  Finder->addMatcher(functionDecl(isExpansionInMainFile(), parameterCountIs(0),
-  unless(isImplicit()), unless(isExternC()))
+  Finder->addMatcher(functionDecl(parameterCountIs(0), unless(isImplicit()),
+  unless(isExternC()))
  .bind(FunctionId),
  this);
-  Finder->addMatcher(typedefDecl(isExpansionInMainFile()).bind(TypedefId),
- this);
+  Finder->addMatcher(typedefDecl().bind(TypedefId), this);
   auto ParenFunctionType = parenType(innerType(functionType()));
   auto PointerToFunctionType = pointee(ParenFunctionType);
   auto FunctionOrMemberPointer =
   anyOf(hasType(pointerType(PointerToFunctionType)),
 hasType(memberPointerType(PointerToFunctionType)));
-  Finder->addMatcher(
-  fieldDecl(isExpansionInMainFile(), 
FunctionOrMemberPointer).bind(FieldId),
-  this);
-  Finder->addMatcher(
-  varDecl(isExpansionInMainFile(), FunctionOrMemberPointer).bind(VarId),
-  this);
+  Finder->addMatcher(fieldDecl(FunctionOrMemberPointer).bind(FieldId), this);
+  Finder->addMatcher(varDecl(FunctionOrMemberPointer).bind(VarId), this);
   auto CastDestinationIsFunction =
   hasDestinationType(pointsTo(ParenFunctionType));
   Finder->addMatcher(
-  cStyleCastExpr(isExpansionInMainFile(), CastDestinationIsFunction)
-  .bind(CStyleCastId),
-  this);
+  cStyleCastExpr(CastDestinationIsFunction).bind(CStyleCastId), this);
   Finder->addMatcher(
-  cxxStaticCastExpr(isExpansionInMainFile(), CastDestinationIsFunction)
-  .bind(NamedCastId),
-  this);
+  cxxStaticCastExpr(CastDestinationIsFunction).bind(NamedCastId), this);
   Finder->addMatcher(
-  cxxReinterpretCastExpr(isExpansionInMainFile(), 
CastDestinationIsFunction)
-  .bind(NamedCastId),
+  cxxReinterpretCastExpr(CastDestinationIsFunction).bind(NamedCastId),
   this);
   Finder->addMatcher(
-  cxxConstCastExpr(isExpansionInMainFile(), CastDestinationIsFunction)
-  .bind(NamedCastId),
-  this);
-  Finder->addMatcher(lambdaExpr(isExpansionInMainFile()).bind(LambdaId), this);
+  cxxConstCastExpr(CastDestinationIsFunction).bind(NamedCastId), this);
+  Finder->addMatcher(lambdaExpr().bind(LambdaId), this);
 }
 
 void RedundantVoidArgCheck::check(const MatchFinder::MatchResult &Result) {


Index: clang-tools-extra/trunk/clang-tidy/modernize/RedundantVoidArgCheck.cpp
===
--- clang-tools-extra/trunk/clang-tidy/modernize/RedundantVoidArgCheck.cpp
+++ clang-tools-extra/trunk/clang-tidy/modernize/RedundantVoidArgCheck.cpp
@@ -46,42 +46,30 @@
 namespace modernize {
 
 void RedundantVoidArgCheck::registerMatchers(MatchFinder *Finder) {
-  Finder->addMatcher(functionDecl(isExpansionInMainFile(), parameterCountIs(0),
-  unless(isImplicit()), unless(isExternC()))
+  Finder->addMatcher(functionDecl(parameterCountIs(0), unless(isImplicit()),
+  unless(isExternC()))
  .bind(FunctionId),
  this);
-  Finder->addMatcher(typedefDecl(isExpansionInMainFile()).bind(TypedefId),
- this);
+  Finder->addMatcher(typedefDecl().bind(TypedefId), this);
   auto ParenFunctionType = parenType(innerType(functionType()));
   auto PointerToFunctionType = pointee(ParenFunctionType);
   auto FunctionOrMemberPointer =
   anyOf(hasType(pointerType(PointerToFunctionType)),
 hasType(memberPointerType(PointerToFunctionType)));
-  Finder->addMatcher(
-  fieldDecl(isExpansionInMainFile(), FunctionOrMemberPointer).bind(FieldId),
-  this);
-  Finder->addMatcher(
-  varDecl(isExpansionInMainFile(), FunctionOrMemberPointer).bind(VarId),
-  this);
+  Finder->addMatcher(fieldDecl(FunctionOrMemberPointer).bind(FieldId), this);
+  Finder->addMatcher(varDecl(FunctionOrMemberPointer).bind(VarId), this);
   auto CastDestinationIsFunction =
   hasDestinationType(pointsTo(ParenFunctionType));
   Finder->addMatcher(
-  cStyleCastExpr(isExpansionIn

[clang-tools-extra] r260948 - [clang-tidy] Enhance modernize-redundant-void-arg check to apply fixes to header files

[Alexander Kornienko via cfe-commits]

Author: alexfh
Date: Tue Feb 16 03:49:05 2016
New Revision: 260948

URL: http://llvm.org/viewvc/llvm-project?rev=260948&view=rev
Log:
[clang-tidy] Enhance modernize-redundant-void-arg check to apply fixes to 
header files

Fixes http://llvm.org/PR25894

Patch by Richard Thomson!

Differential revision: http://reviews.llvm.org/D16953

Modified:
clang-tools-extra/trunk/clang-tidy/modernize/RedundantVoidArgCheck.cpp

Modified: clang-tools-extra/trunk/clang-tidy/modernize/RedundantVoidArgCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/modernize/RedundantVoidArgCheck.cpp?rev=260948&r1=260947&r2=260948&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/modernize/RedundantVoidArgCheck.cpp 
(original)
+++ clang-tools-extra/trunk/clang-tidy/modernize/RedundantVoidArgCheck.cpp Tue 
Feb 16 03:49:05 2016
@@ -46,42 +46,30 @@ namespace tidy {
 namespace modernize {
 
 void RedundantVoidArgCheck::registerMatchers(MatchFinder *Finder) {
-  Finder->addMatcher(functionDecl(isExpansionInMainFile(), parameterCountIs(0),
-  unless(isImplicit()), unless(isExternC()))
+  Finder->addMatcher(functionDecl(parameterCountIs(0), unless(isImplicit()),
+  unless(isExternC()))
  .bind(FunctionId),
  this);
-  Finder->addMatcher(typedefDecl(isExpansionInMainFile()).bind(TypedefId),
- this);
+  Finder->addMatcher(typedefDecl().bind(TypedefId), this);
   auto ParenFunctionType = parenType(innerType(functionType()));
   auto PointerToFunctionType = pointee(ParenFunctionType);
   auto FunctionOrMemberPointer =
   anyOf(hasType(pointerType(PointerToFunctionType)),
 hasType(memberPointerType(PointerToFunctionType)));
-  Finder->addMatcher(
-  fieldDecl(isExpansionInMainFile(), 
FunctionOrMemberPointer).bind(FieldId),
-  this);
-  Finder->addMatcher(
-  varDecl(isExpansionInMainFile(), FunctionOrMemberPointer).bind(VarId),
-  this);
+  Finder->addMatcher(fieldDecl(FunctionOrMemberPointer).bind(FieldId), this);
+  Finder->addMatcher(varDecl(FunctionOrMemberPointer).bind(VarId), this);
   auto CastDestinationIsFunction =
   hasDestinationType(pointsTo(ParenFunctionType));
   Finder->addMatcher(
-  cStyleCastExpr(isExpansionInMainFile(), CastDestinationIsFunction)
-  .bind(CStyleCastId),
-  this);
+  cStyleCastExpr(CastDestinationIsFunction).bind(CStyleCastId), this);
   Finder->addMatcher(
-  cxxStaticCastExpr(isExpansionInMainFile(), CastDestinationIsFunction)
-  .bind(NamedCastId),
-  this);
+  cxxStaticCastExpr(CastDestinationIsFunction).bind(NamedCastId), this);
   Finder->addMatcher(
-  cxxReinterpretCastExpr(isExpansionInMainFile(), 
CastDestinationIsFunction)
-  .bind(NamedCastId),
+  cxxReinterpretCastExpr(CastDestinationIsFunction).bind(NamedCastId),
   this);
   Finder->addMatcher(
-  cxxConstCastExpr(isExpansionInMainFile(), CastDestinationIsFunction)
-  .bind(NamedCastId),
-  this);
-  Finder->addMatcher(lambdaExpr(isExpansionInMainFile()).bind(LambdaId), this);
+  cxxConstCastExpr(CastDestinationIsFunction).bind(NamedCastId), this);
+  Finder->addMatcher(lambdaExpr().bind(LambdaId), this);
 }
 
 void RedundantVoidArgCheck::check(const MatchFinder::MatchResult &Result) {


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

Re: [PATCH] D16953: Enhance clang-tidy modernize-redundant-void-arg check to apply fixes to header files

[Alexander Kornienko via cfe-commits]

alexfh added a comment.

I've committed the changes to the check code. Can you submit the change to the 
script as a separate patch?


Repository:
  rL LLVM

http://reviews.llvm.org/D16953



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

Re: [PATCH] D16953: Enhance clang-tidy modernize-redundant-void-arg check to apply fixes to header files

[Alexander Kornienko via cfe-commits]

alexfh added a comment.

And thank you for the fix, btw!


Repository:
  rL LLVM

http://reviews.llvm.org/D16953



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

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

[Alexander Kornienko via cfe-commits]

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

Looks good. Thank you!


http://reviews.llvm.org/D17134



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

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

[Haojian Wu via cfe-commits]

hokein updated this revision to Diff 48057.
hokein marked an inline comment as done.
hokein added a comment.

Add a note in testcase.


http://reviews.llvm.org/D17134

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

Index: test/clang-tidy/readability-braces-around-statements-assert-failure.cpp
===
--- test/clang-tidy/readability-braces-around-statements-assert-failure.cpp
+++ test/clang-tidy/readability-braces-around-statements-assert-failure.cpp
@@ -1,7 +1,12 @@
-// RUN: %check_clang_tidy %s readability-braces-around-statements %t
+// RUN: clang-tidy -checks='-*,readability-braces-around-statements' %s --
+
+// Note: this test expects no assert failure happened in clang-tidy.
 
 int test_failure() {
   if (std::rand()) {
-  // CHECK-MESSAGES: :[[@LINE-1]]:7: error: use of undeclared identifier 'std'
   }
 }
+
+void test_failure2() {
+  for (a b c;;
+}
Index: clang-tidy/readability/BracesAroundStatementsCheck.cpp
===
--- clang-tidy/readability/BracesAroundStatementsCheck.cpp
+++ clang-tidy/readability/BracesAroundStatementsCheck.cpp
@@ -215,6 +215,8 @@
 return false;
   }
 
+  if (!InitialLoc.isValid())
+return false;
   const SourceManager &SM = *Result.SourceManager;
   const ASTContext *Context = Result.Context;
 
@@ -225,8 +227,6 @@
   if (FileRange.isInvalid())
 return false;
 
-  // InitialLoc points at the last token before opening brace to be inserted.
-  assert(InitialLoc.isValid());
   // Convert InitialLoc to file location, if it's on the same macro expansion
   // level as the start of the statement. We also need file locations for
   // Lexer::getLocForEndOfToken working properly.


Index: test/clang-tidy/readability-braces-around-statements-assert-failure.cpp
===
--- test/clang-tidy/readability-braces-around-statements-assert-failure.cpp
+++ test/clang-tidy/readability-braces-around-statements-assert-failure.cpp
@@ -1,7 +1,12 @@
-// RUN: %check_clang_tidy %s readability-braces-around-statements %t
+// RUN: clang-tidy -checks='-*,readability-braces-around-statements' %s --
+
+// Note: this test expects no assert failure happened in clang-tidy.
 
 int test_failure() {
   if (std::rand()) {
-  // CHECK-MESSAGES: :[[@LINE-1]]:7: error: use of undeclared identifier 'std'
   }
 }
+
+void test_failure2() {
+  for (a b c;;
+}
Index: clang-tidy/readability/BracesAroundStatementsCheck.cpp
===
--- clang-tidy/readability/BracesAroundStatementsCheck.cpp
+++ clang-tidy/readability/BracesAroundStatementsCheck.cpp
@@ -215,6 +215,8 @@
 return false;
   }
 
+  if (!InitialLoc.isValid())
+return false;
   const SourceManager &SM = *Result.SourceManager;
   const ASTContext *Context = Result.Context;
 
@@ -225,8 +227,6 @@
   if (FileRange.isInvalid())
 return false;
 
-  // InitialLoc points at the last token before opening brace to be inserted.
-  assert(InitialLoc.isValid());
   // Convert InitialLoc to file location, if it's on the same macro expansion
   // level as the start of the statement. We also need file locations for
   // Lexer::getLocForEndOfToken working properly.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] r260952 - [clang-tidy] Fix an assert failure of ForStmt in `readability-braces-around-statements` check.

[Haojian Wu via cfe-commits]

Author: hokein
Date: Tue Feb 16 04:31:33 2016
New Revision: 260952

URL: http://llvm.org/viewvc/llvm-project?rev=260952&view=rev
Log:
[clang-tidy] Fix an assert failure of ForStmt in 
`readability-braces-around-statements` check.

Reviewers: alexfh

Subscribers: cfe-commits

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

Modified:

clang-tools-extra/trunk/clang-tidy/readability/BracesAroundStatementsCheck.cpp

clang-tools-extra/trunk/test/clang-tidy/readability-braces-around-statements-assert-failure.cpp

Modified: 
clang-tools-extra/trunk/clang-tidy/readability/BracesAroundStatementsCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/readability/BracesAroundStatementsCheck.cpp?rev=260952&r1=260951&r2=260952&view=diff
==
--- 
clang-tools-extra/trunk/clang-tidy/readability/BracesAroundStatementsCheck.cpp 
(original)
+++ 
clang-tools-extra/trunk/clang-tidy/readability/BracesAroundStatementsCheck.cpp 
Tue Feb 16 04:31:33 2016
@@ -215,6 +215,8 @@ bool BracesAroundStatementsCheck::checkS
 return false;
   }
 
+  if (!InitialLoc.isValid())
+return false;
   const SourceManager &SM = *Result.SourceManager;
   const ASTContext *Context = Result.Context;
 
@@ -225,8 +227,6 @@ bool BracesAroundStatementsCheck::checkS
   if (FileRange.isInvalid())
 return false;
 
-  // InitialLoc points at the last token before opening brace to be inserted.
-  assert(InitialLoc.isValid());
   // Convert InitialLoc to file location, if it's on the same macro expansion
   // level as the start of the statement. We also need file locations for
   // Lexer::getLocForEndOfToken working properly.

Modified: 
clang-tools-extra/trunk/test/clang-tidy/readability-braces-around-statements-assert-failure.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/readability-braces-around-statements-assert-failure.cpp?rev=260952&r1=260951&r2=260952&view=diff
==
--- 
clang-tools-extra/trunk/test/clang-tidy/readability-braces-around-statements-assert-failure.cpp
 (original)
+++ 
clang-tools-extra/trunk/test/clang-tidy/readability-braces-around-statements-assert-failure.cpp
 Tue Feb 16 04:31:33 2016
@@ -1,7 +1,12 @@
-// RUN: %check_clang_tidy %s readability-braces-around-statements %t
+// RUN: clang-tidy -checks='-*,readability-braces-around-statements' %s --
+
+// Note: this test expects no assert failure happened in clang-tidy.
 
 int test_failure() {
   if (std::rand()) {
-  // CHECK-MESSAGES: :[[@LINE-1]]:7: error: use of undeclared identifier 'std'
   }
 }
+
+void test_failure2() {
+  for (a b c;;
+}


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

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

[Haojian Wu via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL260952: [clang-tidy] Fix an assert failure of ForStmt in 
`readability-braces-around… (authored by hokein).

Changed prior to commit:
  http://reviews.llvm.org/D17134?vs=48057&id=48058#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D17134

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

Index: 
clang-tools-extra/trunk/clang-tidy/readability/BracesAroundStatementsCheck.cpp
===
--- 
clang-tools-extra/trunk/clang-tidy/readability/BracesAroundStatementsCheck.cpp
+++ 
clang-tools-extra/trunk/clang-tidy/readability/BracesAroundStatementsCheck.cpp
@@ -215,6 +215,8 @@
 return false;
   }
 
+  if (!InitialLoc.isValid())
+return false;
   const SourceManager &SM = *Result.SourceManager;
   const ASTContext *Context = Result.Context;
 
@@ -225,8 +227,6 @@
   if (FileRange.isInvalid())
 return false;
 
-  // InitialLoc points at the last token before opening brace to be inserted.
-  assert(InitialLoc.isValid());
   // Convert InitialLoc to file location, if it's on the same macro expansion
   // level as the start of the statement. We also need file locations for
   // Lexer::getLocForEndOfToken working properly.
Index: 
clang-tools-extra/trunk/test/clang-tidy/readability-braces-around-statements-assert-failure.cpp
===
--- 
clang-tools-extra/trunk/test/clang-tidy/readability-braces-around-statements-assert-failure.cpp
+++ 
clang-tools-extra/trunk/test/clang-tidy/readability-braces-around-statements-assert-failure.cpp
@@ -1,7 +1,12 @@
-// RUN: %check_clang_tidy %s readability-braces-around-statements %t
+// RUN: clang-tidy -checks='-*,readability-braces-around-statements' %s --
+
+// Note: this test expects no assert failure happened in clang-tidy.
 
 int test_failure() {
   if (std::rand()) {
-  // CHECK-MESSAGES: :[[@LINE-1]]:7: error: use of undeclared identifier 'std'
   }
 }
+
+void test_failure2() {
+  for (a b c;;
+}


Index: clang-tools-extra/trunk/clang-tidy/readability/BracesAroundStatementsCheck.cpp
===
--- clang-tools-extra/trunk/clang-tidy/readability/BracesAroundStatementsCheck.cpp
+++ clang-tools-extra/trunk/clang-tidy/readability/BracesAroundStatementsCheck.cpp
@@ -215,6 +215,8 @@
 return false;
   }
 
+  if (!InitialLoc.isValid())
+return false;
   const SourceManager &SM = *Result.SourceManager;
   const ASTContext *Context = Result.Context;
 
@@ -225,8 +227,6 @@
   if (FileRange.isInvalid())
 return false;
 
-  // InitialLoc points at the last token before opening brace to be inserted.
-  assert(InitialLoc.isValid());
   // Convert InitialLoc to file location, if it's on the same macro expansion
   // level as the start of the statement. We also need file locations for
   // Lexer::getLocForEndOfToken working properly.
Index: clang-tools-extra/trunk/test/clang-tidy/readability-braces-around-statements-assert-failure.cpp
===
--- clang-tools-extra/trunk/test/clang-tidy/readability-braces-around-statements-assert-failure.cpp
+++ clang-tools-extra/trunk/test/clang-tidy/readability-braces-around-statements-assert-failure.cpp
@@ -1,7 +1,12 @@
-// RUN: %check_clang_tidy %s readability-braces-around-statements %t
+// RUN: clang-tidy -checks='-*,readability-braces-around-statements' %s --
+
+// Note: this test expects no assert failure happened in clang-tidy.
 
 int test_failure() {
   if (std::rand()) {
-  // CHECK-MESSAGES: :[[@LINE-1]]:7: error: use of undeclared identifier 'std'
   }
 }
+
+void test_failure2() {
+  for (a b c;;
+}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] r260953 - [clang-tidy] Fix an assert failure in `modernize-loop-convert`.

[Haojian Wu via cfe-commits]

Author: hokein
Date: Tue Feb 16 04:36:51 2016
New Revision: 260953

URL: http://llvm.org/viewvc/llvm-project?rev=260953&view=rev
Log:
[clang-tidy] Fix an assert failure in `modernize-loop-convert`.

Summary:
The test code will trigger following an assert failure:

assert.h assertion failed at LoopConvertUtils.cpp:560 in
bool 
clang::tidy::modernize::ForLoopIndexUseVisitor::TraverseMemberExpr(clang::MemberExpr*):
 ExprType->isPointerType() && "Operator-> returned non-pointer type"

Reviewers: alexfh

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

Added:

clang-tools-extra/trunk/test/clang-tidy/modernize-loop-convert-assert-failure.cpp
Modified:
clang-tools-extra/trunk/clang-tidy/modernize/LoopConvertUtils.cpp

Modified: clang-tools-extra/trunk/clang-tidy/modernize/LoopConvertUtils.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/modernize/LoopConvertUtils.cpp?rev=260953&r1=260952&r2=260953&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/modernize/LoopConvertUtils.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/modernize/LoopConvertUtils.cpp Tue Feb 
16 04:36:51 2016
@@ -557,7 +557,9 @@ bool ForLoopIndexUseVisitor::TraverseMem
 if (ExprType.isNull())
   ExprType = Obj->getType();
 
-assert(ExprType->isPointerType() && "Operator-> returned non-pointer 
type");
+if (!ExprType->isPointerType())
+  return false;
+
 // FIXME: This works around not having the location of the arrow operator.
 // Consider adding OperatorLoc to MemberExpr?
 SourceLocation ArrowLoc = Lexer::getLocForEndOfToken(

Added: 
clang-tools-extra/trunk/test/clang-tidy/modernize-loop-convert-assert-failure.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/modernize-loop-convert-assert-failure.cpp?rev=260953&view=auto
==
--- 
clang-tools-extra/trunk/test/clang-tidy/modernize-loop-convert-assert-failure.cpp
 (added)
+++ 
clang-tools-extra/trunk/test/clang-tidy/modernize-loop-convert-assert-failure.cpp
 Tue Feb 16 04:36:51 2016
@@ -0,0 +1,18 @@
+// RUN: clang-tidy %s -checks=-*,modernize-loop-convert --
+
+// Note: this test expects no assert failure happened in clang-tidy.
+
+class LinguisticItem {
+  LinguisticItem *x0;
+  class x1 {
+bool operator!= ( const x1 &;
+operator* ( ;
+LinguisticItem * &operator-> ( ;
+operator++ (
+  } begin() const;
+  x1 end() const {
+LinguisticStream x2;
+for (x1 x3 = x2.begin x3 != x2.end; ++x3)
+  x3->x0
+  }
+};


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

r260954 - [OPENMP] Improved handling of pseudo-captured expressions in OpenMP.

[Alexey Bataev via cfe-commits]

Author: abataev
Date: Tue Feb 16 05:18:12 2016
New Revision: 260954

URL: http://llvm.org/viewvc/llvm-project?rev=260954&view=rev
Log:
[OPENMP] Improved handling of pseudo-captured expressions in OpenMP.
Expressions inside 'schedule'|'dist_schedule' clause must be captured in
combined directives to avoid possible crash during codegen. Patch
improves handling of such constructs

Modified:
cfe/trunk/include/clang/AST/OpenMPClause.h
cfe/trunk/include/clang/AST/RecursiveASTVisitor.h
cfe/trunk/lib/AST/OpenMPClause.cpp
cfe/trunk/lib/AST/StmtPrinter.cpp
cfe/trunk/lib/AST/StmtProfile.cpp
cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp
cfe/trunk/lib/CodeGen/CodeGenFunction.h
cfe/trunk/lib/Sema/SemaOpenMP.cpp
cfe/trunk/lib/Serialization/ASTReaderStmt.cpp
cfe/trunk/lib/Serialization/ASTWriterStmt.cpp
cfe/trunk/test/OpenMP/parallel_num_threads_codegen.cpp
cfe/trunk/tools/libclang/CIndex.cpp

Modified: cfe/trunk/include/clang/AST/OpenMPClause.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/OpenMPClause.h?rev=260954&r1=260953&r2=260954&view=diff
==
--- cfe/trunk/include/clang/AST/OpenMPClause.h (original)
+++ cfe/trunk/include/clang/AST/OpenMPClause.h Tue Feb 16 05:18:12 2016
@@ -70,6 +70,28 @@ public:
   static bool classof(const OMPClause *) { return true; }
 };
 
+/// Class that handles pre-initialization statement for some clauses, like
+/// 'shedule', 'firstprivate' etc.
+class OMPClauseWithPreInit {
+  friend class OMPClauseReader;
+  /// Pre-initialization statement for the clause.
+  Stmt *PreInit;
+protected:
+  /// Set pre-initialization statement for the clause.
+  void setPreInitStmt(Stmt *S) { PreInit = S; }
+  OMPClauseWithPreInit(const OMPClause *This) : PreInit(nullptr) {
+assert(get(This) && "get is not tuned.");
+  }
+
+public:
+  /// Get pre-initialization statement for the clause.
+  const Stmt *getPreInitStmt() const { return PreInit; }
+  /// Get pre-initialization statement for the clause.
+  Stmt *getPreInitStmt() { return PreInit; }
+  static OMPClauseWithPreInit *get(OMPClause *C);
+  static const OMPClauseWithPreInit *get(const OMPClause *C);
+};
+
 /// \brief This represents clauses with the list of variables like 'private',
 /// 'firstprivate', 'copyin', 'shared', or 'reduction' clauses in the
 /// '#pragma omp ...' directives.
@@ -650,7 +672,7 @@ public:
 /// In this example directive '#pragma omp for' has 'schedule' clause with
 /// arguments 'static' and '3'.
 ///
-class OMPScheduleClause : public OMPClause {
+class OMPScheduleClause : public OMPClause, public OMPClauseWithPreInit {
   friend class OMPClauseReader;
   /// \brief Location of '('.
   SourceLocation LParenLoc;
@@ -665,10 +687,8 @@ class OMPScheduleClause : public OMPClau
   SourceLocation KindLoc;
   /// \brief Location of ',' (if any).
   SourceLocation CommaLoc;
-  /// \brief Chunk size and a reference to pseudo variable for combined
-  /// directives.
-  enum { CHUNK_SIZE, HELPER_CHUNK_SIZE, NUM_EXPRS };
-  Stmt *ChunkSizes[NUM_EXPRS];
+  /// \brief Chunk size.
+  Expr *ChunkSize;
 
   /// \brief Set schedule kind.
   ///
@@ -730,12 +750,7 @@ class OMPScheduleClause : public OMPClau
   ///
   /// \param E Chunk size.
   ///
-  void setChunkSize(Expr *E) { ChunkSizes[CHUNK_SIZE] = E; }
-  /// \brief Set helper chunk size.
-  ///
-  /// \param E Helper chunk size.
-  ///
-  void setHelperChunkSize(Expr *E) { ChunkSizes[HELPER_CHUNK_SIZE] = E; }
+  void setChunkSize(Expr *E) { ChunkSize = E; }
 
 public:
   /// \brief Build 'schedule' clause with schedule kind \a Kind and chunk size
@@ -757,13 +772,13 @@ public:
   OMPScheduleClause(SourceLocation StartLoc, SourceLocation LParenLoc,
 SourceLocation KLoc, SourceLocation CommaLoc,
 SourceLocation EndLoc, OpenMPScheduleClauseKind Kind,
-Expr *ChunkSize, Expr *HelperChunkSize,
+Expr *ChunkSize, Stmt *HelperChunkSize,
 OpenMPScheduleClauseModifier M1, SourceLocation M1Loc,
 OpenMPScheduleClauseModifier M2, SourceLocation M2Loc)
-  : OMPClause(OMPC_schedule, StartLoc, EndLoc), LParenLoc(LParenLoc),
-Kind(Kind), KindLoc(KLoc), CommaLoc(CommaLoc) {
-ChunkSizes[CHUNK_SIZE] = ChunkSize;
-ChunkSizes[HELPER_CHUNK_SIZE] = HelperChunkSize;
+  : OMPClause(OMPC_schedule, StartLoc, EndLoc), OMPClauseWithPreInit(this),
+LParenLoc(LParenLoc), Kind(Kind), KindLoc(KLoc), CommaLoc(CommaLoc),
+ChunkSize(ChunkSize) {
+setPreInitStmt(HelperChunkSize);
 Modifiers[FIRST] = M1;
 Modifiers[SECOND] = M2;
 ModifiersLoc[FIRST] = M1Loc;
@@ -774,9 +789,8 @@ public:
   ///
   explicit OMPScheduleClause()
   : OMPClause(OMPC_schedule, SourceLocation(), SourceLocation()),
-Kind(OMPC_SCHEDULE_unknown) {
-ChunkSizes[CHUNK_SIZE] = nullptr;
-ChunkSizes[HELPER_CHUNK_SIZE] = nullptr;

Re: [PATCH] D15283: [ARMv8-M] Add Clang targeting for ARMv8-M Baseline/Mainline

[Bradley Smith via cfe-commits]

bsmith added a comment.

Ping, it would be nice to get this committed to complete ARMv8-M support.


Repository:
  rL LLVM

http://reviews.llvm.org/D15283



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

r260957 - [OPENMP] Allow to use compound assignment operators.

[Alexey Bataev via cfe-commits]

Author: abataev
Date: Tue Feb 16 06:13:49 2016
New Revision: 260957

URL: http://llvm.org/viewvc/llvm-project?rev=260957&view=rev
Log:
[OPENMP] Allow to use compound assignment operators.
Loop-based directives allow to use iterators as loop counters. Iterators are 
allowed to define their own operators. This patch allows to use compound 
assignment operators for iterators.

Modified:
cfe/trunk/lib/Sema/SemaOpenMP.cpp
cfe/trunk/test/OpenMP/for_loop_messages.cpp

Modified: cfe/trunk/lib/Sema/SemaOpenMP.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaOpenMP.cpp?rev=260957&r1=260956&r2=260957&view=diff
==
--- cfe/trunk/lib/Sema/SemaOpenMP.cpp (original)
+++ cfe/trunk/lib/Sema/SemaOpenMP.cpp Tue Feb 16 06:13:49 2016
@@ -4072,7 +4072,8 @@ static ExprResult BuildCounterUpdate(Sem
   if (!Update.isUsable())
 return ExprError();
 
-  // Build 'VarRef = Start + Iter * Step'.
+  // Try to build 'VarRef = Start, VarRef (+|-)= Iter * Step' or
+  // 'VarRef = Start (+|-) Iter * Step'.
   auto NewStart = Transform.TransformExpr(Start.get()->IgnoreImplicit());
   if (NewStart.isInvalid())
 return ExprError();
@@ -4082,17 +4083,43 @@ static ExprResult BuildCounterUpdate(Sem
   /*AllowExplicit=*/true);
   if (NewStart.isInvalid())
 return ExprError();
-  Update = SemaRef.BuildBinOp(S, Loc, (Subtract ? BO_Sub : BO_Add),
-  NewStart.get(), Update.get());
-  if (!Update.isUsable())
-return ExprError();
 
-  Update = SemaRef.PerformImplicitConversion(
-  Update.get(), VarRef.get()->getType(), Sema::AA_Converting, true);
-  if (!Update.isUsable())
-return ExprError();
+  // First attempt: try to build 'VarRef = Start, VarRef += Iter * Step'.
+  ExprResult SavedUpdate = Update;
+  ExprResult UpdateVal;
+  if (VarRef.get()->getType()->isOverloadableType() ||
+  NewStart.get()->getType()->isOverloadableType() ||
+  Update.get()->getType()->isOverloadableType()) {
+bool Suppress = SemaRef.getDiagnostics().getSuppressAllDiagnostics();
+SemaRef.getDiagnostics().setSuppressAllDiagnostics(/*Val=*/true);
+Update =
+SemaRef.BuildBinOp(S, Loc, BO_Assign, VarRef.get(), NewStart.get());
+if (Update.isUsable()) {
+  UpdateVal =
+  SemaRef.BuildBinOp(S, Loc, Subtract ? BO_SubAssign : BO_AddAssign,
+ VarRef.get(), SavedUpdate.get());
+  if (UpdateVal.isUsable()) {
+Update = SemaRef.CreateBuiltinBinOp(Loc, BO_Comma, Update.get(),
+UpdateVal.get());
+  }
+}
+SemaRef.getDiagnostics().setSuppressAllDiagnostics(Suppress);
+  }
+
+  // Second attempt: try to build 'VarRef = Start (+|-) Iter * Step'.
+  if (!Update.isUsable() || !UpdateVal.isUsable()) {
+Update = SemaRef.BuildBinOp(S, Loc, Subtract ? BO_Sub : BO_Add,
+NewStart.get(), SavedUpdate.get());
+if (!Update.isUsable())
+  return ExprError();
+
+Update = SemaRef.PerformImplicitConversion(
+Update.get(), VarRef.get()->getType(), Sema::AA_Converting, true);
+if (!Update.isUsable())
+  return ExprError();
 
-  Update = SemaRef.BuildBinOp(S, Loc, BO_Assign, VarRef.get(), Update.get());
+Update = SemaRef.BuildBinOp(S, Loc, BO_Assign, VarRef.get(), Update.get());
+  }
   return Update;
 }
 

Modified: cfe/trunk/test/OpenMP/for_loop_messages.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/OpenMP/for_loop_messages.cpp?rev=260957&r1=260956&r2=260957&view=diff
==
--- cfe/trunk/test/OpenMP/for_loop_messages.cpp (original)
+++ cfe/trunk/test/OpenMP/for_loop_messages.cpp Tue Feb 16 06:13:49 2016
@@ -426,6 +426,19 @@ public:
   typedef int difference_type;
   typedef std::random_access_iterator_tag iterator_category;
 };
+class GoodIter1 {
+public:
+  GoodIter1() {}
+  GoodIter1(const GoodIter1 &) {}
+  GoodIter1 &operator++(int) { return *this; }
+  GoodIter1 &operator=(const GoodIter1 &that) { return *this; }
+  GoodIter1 &operator+=(int x) { return *this; }
+  friend long operator-(const GoodIter1 &, const GoodIter1 &);
+  GoodIter1 &operator-(int) { return *this; }
+  bool operator<(GoodIter1 a) { return true; }
+  typedef int difference_type;
+  typedef std::random_access_iterator_tag iterator_category;
+};
 // expected-note@+2 {{candidate function not viable: no known conversion from 
'Iter0' to 'GoodIter' for 2nd argument}}
 // expected-note@+1 2 {{candidate function not viable: no known conversion 
from 'Iter1' to 'GoodIter' for 1st argument}}
 int operator-(GoodIter a, GoodIter b) { return 0; }
@@ -572,6 +585,10 @@ int test_with_random_access_iterator() {
 #pragma omp for
   for (Iter1 I; I < end1; ++I) {
   }
+  GoodIter1 I1, E1;
+#pragma omp for
+  for (GoodIter1 I = I1; I < E1; I++)
+;
   return 0;
 }
 


_

Re: [PATCH] D16928: [OpenCL] Apply missing restrictions for Blocks in OpenCL v2.0

[Mats Petersson via cfe-commits]

MatsPetersson added a subscriber: MatsPetersson.


Comment at: include/clang/Basic/DiagnosticSemaKinds.td:7700
@@ -7698,2 +7699,3 @@
+  "OpenCL does not allow variadic arguments">;
 
 // OpenCL v2.0 s6.13.6 -- Builtin Pipe Functions

Looks good


Comment at: include/clang/Basic/DiagnosticSemaKinds.td:7717
@@ +7716,3 @@
+def err_opencl_block_storage_type : Error<
+  "the __block storage type is not permitted">;
+def err_opencl_invalid_block_declaration : Error<

Looks good now (from my official account this time! :) )


http://reviews.llvm.org/D16928



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

[libcxx] r260961 - Issue a warning instead of fatal errors when checks for libatomic fail.

[Vasileios Kalintiris via cfe-commits]

Author: vkalintiris
Date: Tue Feb 16 08:15:27 2016
New Revision: 260961

URL: http://llvm.org/viewvc/llvm-project?rev=260961&view=rev
Log:
Issue a warning instead of fatal errors when checks for libatomic fail.

This should fix PR26631, PR26622 and has the nice property that the addition
of the CheckLibcxxAtomic.cmake module acts as an NFC on the platforms of the
reporters (at least for the time being).

As these bug reports explain, CMake fails the atomic check because the
include headers might not exist in the host environment. We could
potentially point to the headers provided by libcxx itself.

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

Modified: libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake?rev=260961&r1=260960&r2=260961&view=diff
==
--- libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake (original)
+++ libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake Tue Feb 16 08:15:27 2016
@@ -33,9 +33,9 @@ if(NOT LIBCXX_HAVE_CXX_ATOMICS_WITHOUT_L
 list(APPEND CMAKE_REQUIRED_LIBRARIES "atomic")
 check_cxx_atomics(LIBCXX_HAVE_CXX_ATOMICS_WITH_LIB)
 if (NOT LIBCXX_HAVE_CXX_ATOMICS_WITH_LIB)
-  message(FATAL_ERROR "Host compiler must support std::atomic!")
+  message(WARNING "Host compiler must support std::atomic!")
 endif()
   else()
-message(FATAL_ERROR "Host compiler appears to require libatomic, but 
cannot find it.")
+message(WARNING "Host compiler appears to require libatomic, but cannot 
find it.")
   endif()
 endif()


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

Re: [PATCH] D16928: [OpenCL] Apply missing restrictions for Blocks in OpenCL v2.0

[Mats Petersson via cfe-commits]

MatsPetersson added inline comments.


Comment at: test/SemaOpenCL/invalid-func.cl:6
@@ +5,2 @@
+void foo(int, ...); // expected-error{{OpenCL does not allow variadic 
arguments}}
+int printf(const char *, ...);

pekka.jaaskelainen wrote:
> I wonder should we check for the fingerprint too when letting printf() pass?
> This is not the correct OpenCL printf() as the first argument should be in 
> constant address space.
Good spot, this should be fixed.


http://reviews.llvm.org/D16928



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

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

[Carlo Bertolli via cfe-commits]

carlo.bertolli added inline comments.


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

I added this because OpenMPScheduleClauseKind and OpenMPDistScheduleClauseKind 
are two different unrelated types. Do you suggest something like the following?

void emitForStaticInit(CodeGenFunction &CGF, SourceLocation Loc, 
OpenMPScheduleClauseKind ScheduleKind, OpenMPDistScheduleClauseKind 
ScheduleKind, unsigned IVSize, bool IVSigned, bool Ordered, Address IL, Address 
LB, Address UB, Address ST, llvm::Value *Chunk);

and for dist_schedule called like:

OpenMPDistScheduleClauseKind DistScheduleKind = ..;

RT.emitForStaticInit(*this, S.getLocStart(), OMPC_SCHEDULE_unknown, 
DistScheduleKind, IVSize, IVSigned, Ordered, IL, LB, UB, ST, Chunk);

Similarly, for schedule clause:

OpenMPScheduleClauseKind ScheduleKind = ..;

RT.emitForStaticInit(*this, S.getLocStart(), ScheduleKind, 
OMPC_DIST_SCHEDULE_unknown, IVSize, IVSigned, Ordered, IL, LB, UB, ST, Chunk);




Repository:
  rL LLVM

http://reviews.llvm.org/D17170



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

[libcxx] r260964 - Added a (private) status page for the Jacksonville meeting

[Marshall Clow via cfe-commits]

Author: marshall
Date: Tue Feb 16 08:35:56 2016
New Revision: 260964

URL: http://llvm.org/viewvc/llvm-project?rev=260964&view=rev
Log:
Added a (private) status page for the Jacksonville meeting

Added:
libcxx/trunk/www/upcoming_meeting.html
Removed:
libcxx/trunk/www/kona.html

Removed: libcxx/trunk/www/kona.html
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/www/kona.html?rev=260963&view=auto
==
--- libcxx/trunk/www/kona.html (original)
+++ libcxx/trunk/www/kona.html (removed)
@@ -1,154 +0,0 @@
-http://www.w3.org/TR/html4/strict.dtd";>
-
-
-
-  
-  libc++ Kona Status
-  
-  
-
-
-
-
-  
-http://llvm.org/";>LLVM Home
-  
-
-  
-libc++ Info
-About
-  
-
-  
-Quick Links
-http://lists.llvm.org/mailman/listinfo/cfe-dev";>cfe-dev
-http://lists.llvm.org/mailman/listinfo/cfe-commits";>cfe-commits
-http://llvm.org/bugs/";>Bug Reports
-http://llvm.org/svn/llvm-project/libcxx/trunk/";>Browse SVN
-http://llvm.org/viewvc/llvm-project/libcxx/trunk/";>Browse 
ViewVC
-  
-
-
-
-  
-  libc++ Kona Status
-  
-
-  This is a temporary page; please check the c++1z status http://libcxx.llvm.org/cxx1z_status.html";>here
-  This page shows the status of the papers and issues that are expected to 
be adopted in Kona.
-
-  The groups that have contributed papers:
-  
-LWG - Library working group
-CWG - Core Language Working group
-SG1 - Study group #1 (Concurrency working group)
-  
-  
-  
-  Paper Status
-  
-   Paper #GroupPaper 
NameMeetingStatusFirst released version
-
-
-  
-
-  Library Working group Issues Status
-  
-   Issue #Issue 
NameMeetingStatus
-   http://cplusplus.github.io/LWG/lwg-defects.html#1169";>1169num_get
 not fully compatible with strto*Kona
-   http://cplusplus.github.io/LWG/lwg-defects.html#2072";>2072Unclear
 wording about capacity of temporary 
buffersKonaComplete
-   http://cplusplus.github.io/LWG/lwg-defects.html#2101";>2101Some
 transformation types can produce impossible 
typesKona
-   http://cplusplus.github.io/LWG/lwg-defects.html#2111";>2111Which
 unexpected/terminate handler is called from the 
exception handling runtime?KonaComplete
-   http://cplusplus.github.io/LWG/lwg-defects.html#2119";>2119Missing
 hash specializations for extended integer 
typesKona
-   http://cplusplus.github.io/LWG/lwg-defects.html#2127";>2127Move-construction
 with raw_storage_iteratorKonaPatch Ready
-   http://cplusplus.github.io/LWG/lwg-defects.html#2133";>2133Attitude
 to overloaded comma for iteratorsKonaComplete
-   http://cplusplus.github.io/LWG/lwg-defects.html#2156";>2156Unordered
 containers' reserve(n) reserves for n-1 
elementsKona
-   http://cplusplus.github.io/LWG/lwg-defects.html#2218";>2218Unclear
 how containers use 
allocator_traits::construct()Kona
-   http://cplusplus.github.io/LWG/lwg-defects.html#2219";>2219INVOKE-ing
 a pointer to member with a reference_wrapper as the object 
expressionKona
-   http://cplusplus.github.io/LWG/lwg-defects.html#2224";>2224Ambiguous
 status of access to non-live objectsKona
-   http://cplusplus.github.io/LWG/lwg-defects.html#2234";>2234assert()
 should allow usage in constant expressionsKona
-   http://cplusplus.github.io/LWG/lwg-defects.html#2244";>2244Issue
 on basic_istream::seekgKonaPatch Ready
-   http://cplusplus.github.io/LWG/lwg-defects.html#2250";>2250Follow-up
 On Library Issue 2207Kona
-   http://cplusplus.github.io/LWG/lwg-defects.html#2259";>2259Issues
 in 17.6.5.5 rules for member functionsKonaComplete
-   http://cplusplus.github.io/LWG/lwg-defects.html#2273";>2273regex_match
 ambiguityKona
-   http://cplusplus.github.io/LWG/lwg-defects.html#2336";>2336is_trivially_constructible/is_trivially_assignable
 traits are always falseKona
-   http://cplusplus.github.io/LWG/lwg-defects.html#2353";>2353std::next
 is over-constrainedKona
-   http://cplusplus.github.io/LWG/lwg-defects.html#2367";>2367pair
 and tuple are not correctly implemented for is_constructible 
with no argsKonaPatch Ready
-   http://cplusplus.github.io/LWG/lwg-defects.html#2380";>2380May
  provide long ::abs(long) and long long 
::abs(long long)?KonaComplete
-   http://cplusplus.github.io/LWG/lwg-defects.html#2384";>2384Allocator's
 deallocate function needs better 
specificationKonaComplete
-   http://cplusplus.github.io/LWG/lwg-defects.html#2385";>2385function::assign
 allocator argument doesn't make senseKona
-   http://cplusplus.github.io/LWG/lwg-defects.html#2435";>2435reference_wrapper::operator()'s
 Remark should be deletedKonaComplete
-   http://cplusplus.github.io/LWG/lwg-defects.html#2447";>2447Allocators
 and volatile-qualified value 
typesKonaComplete
-   http://cplusplus.github.io/LWG/lwg-defects.html#2462";>2462std::ios_base::failure
 is overspecifiedKonaComplete
-   http://cplusplus.github.io/LWG/lwg-defects.html#2466";

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

[Vasileios Kalintiris via cfe-commits]

I changed the type of message from fatal_error to warning in r260961. While the 
test for atomics works fine in most cases, it fails because we include 
 and , and the user's host compiler might not provide them 
during a bootstrap (see PR26631 and PR26622).

Does anyone have any idea how to tackle this problem? As suggested by the bug 
reports, we could include the headers provided by libc++. However, I'm not sure 
whether we are supposed to do that during configuration time.

- Vasileios




From: Eric Fiselier [e...@efcs.ca]
Sent: 11 February 2016 16:08
To: Daniel Sanders
Cc: Vasileios Kalintiris; h...@chromium.org; mclow.li...@gmail.com; 
cfe-commits@lists.llvm.org
Subject: Re: [libcxx] r260235 - Introduce a cmake module to figure out whether 
we need to link with libatomic.

>  we need to rename HAVE_CXX_ATOMICS_WITH_LIB to something like 
> LIBCXX_HAVE_CXX_ATOMICS_WITH_LIB.

Fixed in r260531.

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

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

@Marshall Any objections?

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

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

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

Hi Hans,

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

- Vasileios

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

Hi Hans,

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

Thanks,
Vasileios


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

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

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

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

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

Subscribers: cfe-commits

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

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

Added: libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake?rev=260235&view=auto
==
--- libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake (added)
+++ libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake Tue Feb  9 11:00:38 2016
@@ -0,0 +1,38 @@
+INCLUDE(CheckCXXSourceCompiles)
+
+# Sometimes linking against libatomic is required for atomic ops, if
+# the platform doesn't support lock-free 

[libcxx] r260966 - Add some comments

[Marshall Clow via cfe-commits]

Author: marshall
Date: Tue Feb 16 08:42:23 2016
New Revision: 260966

URL: http://llvm.org/viewvc/llvm-project?rev=260966&view=rev
Log:
Add some comments

Modified:
libcxx/trunk/www/upcoming_meeting.html

Modified: libcxx/trunk/www/upcoming_meeting.html
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/www/upcoming_meeting.html?rev=260966&r1=260965&r2=260966&view=diff
==
--- libcxx/trunk/www/upcoming_meeting.html (original)
+++ libcxx/trunk/www/upcoming_meeting.html Tue Feb 16 08:42:23 2016
@@ -68,8 +68,8 @@
http://cplusplus.github.io/LWG/lwg-defects.html#2537";>2537Constructors
 for priority_queue taking allocators should call 
make_heapJacksonville
http://cplusplus.github.io/LWG/lwg-defects.html#2539";>2539[fund.ts.v2]
 invocation_trait definition definition doesn't work for surrogate 
call functionsJacksonville
http://cplusplus.github.io/LWG/lwg-defects.html#2545";>2545Simplify
 wording for bind without explicitly specified return 
typeJacksonville
-   http://cplusplus.github.io/LWG/lwg-defects.html#2557";>2557Logical
 operator traits are broken in the zero-argument 
caseJacksonville
-   http://cplusplus.github.io/LWG/lwg-defects.html#2558";>2558[fund.ts.v2]
 Logical operator traits are broken in the zero-argument 
caseJacksonville
+   http://cplusplus.github.io/LWG/lwg-defects.html#2557";>2557Logical
 operator traits are broken in the zero-argument 
caseJacksonvilleComplete
+   http://cplusplus.github.io/LWG/lwg-defects.html#2558";>2558[fund.ts.v2]
 Logical operator traits are broken in the zero-argument 
caseJacksonvilleComplete
http://cplusplus.github.io/LWG/lwg-defects.html#2559";>2559Error
 in LWG 2234's resolutionJacksonville
http://cplusplus.github.io/LWG/lwg-defects.html#2560";>2560is_constructible
 underspecified when applied to a function 
typeJacksonville
http://cplusplus.github.io/LWG/lwg-defects.html#2565";>2565std::function's
 move constructor should guarantee nothrow for reference_wrappers and 
function pointersJacksonville
@@ -92,8 +92,8 @@
 Comments about the issues
 
 2192 - 
-2253 - 
-2255 - 
+2253 - Arrays.ts is moribund. No action needed.
+2255 - Arrays.ts is moribund. No action needed.
 2276 - 
 2450 - 
 2520 - 
@@ -102,8 +102,8 @@
 2537 - 
 2539 - 
 2545 - 
-2557 - 
-2558 - 
+2557 - Cleaning up wording; no code change required.
+2558 - Cleaning up wording; no code change required.
 2559 - 
 2560 - 
 2565 - 
@@ -114,11 +114,11 @@
 2575 - I don't think we ever implemented this; so 'removing' it is 
trivial
 2576 - This one is simple
 2577 - This one is simple
-2579 - 
+2579 - This one is simple
 2581 - 
 2582 - 
-2583 - 
-2585 - 
+2583 - This looks easy.
+2585 - This looks easy.
 2586 - 
 2590 - 
 


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

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

[Aaron Ballman via cfe-commits]

aaron.ballman added inline comments.


Comment at: lib/Sema/SemaDeclAttr.cpp:5046
@@ +5045,3 @@
+  if (D->hasAttr()) {
+S.Diag(D->getLocation(), diag::err_opencl_multiple_access_qualifiers)
+<< D->getSourceRange();

That's why I think it should be pointing at the attribute. The presence of the 
second attribute is what triggers the diagnostic, not anything about the 
declaration. The location should always point to "this thing is what caused the 
diagnostic."


Comment at: lib/Sema/SemaDeclAttr.cpp:5062
@@ +5061,3 @@
+S.Diag(Attr.getLoc(), diag::err_opencl_invalid_read_write)
+  //TODO
+<< PDecl->getType() << DeclTy->isImageType() << 
D->getSourceRange();

Spurious TODO?


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

pxli168 wrote:
> I think this attribute one that need to be slid on the declaration. Now I 
> just handle this in ProcessDeclAttributes, with
> 
> ```
>   const ParmVarDecl *PDecl = llvm::dyn_cast(D);
>   if (!PDecl ||
>   !PDecl->getType().getCanonicalType().getTypePtr()->isPipeType()) {
> ```
> And I tried to handle it in  distributeTypeAttrsFromDeclarator but it seems 
> this attribute does not go through that path and I am still working on how to 
> place this check.
You should look into why it does not make its way into 
distributeTypeAttrsFromDeclarator(); as it stands, I am uncomfortable with the 
current approach.


http://reviews.llvm.org/D16040



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

Re: [PATCH] D16929: add support for -print-imm-hex for AArch64

[Paul Osmialowski via cfe-commits]

pawosm01 added a comment.

You're right, this patch smuggles elimination of two dead functions. I've 
prepared alternative version of this patch which does not do that.


Repository:
  rL LLVM

http://reviews.llvm.org/D16929



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

[libcxx] r260975 - Add some status

[Marshall Clow via cfe-commits]

Author: marshall
Date: Tue Feb 16 10:05:15 2016
New Revision: 260975

URL: http://llvm.org/viewvc/llvm-project?rev=260975&view=rev
Log:
Add some status

Modified:
libcxx/trunk/www/upcoming_meeting.html

Modified: libcxx/trunk/www/upcoming_meeting.html
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/www/upcoming_meeting.html?rev=260975&r1=260974&r2=260975&view=diff
==
--- libcxx/trunk/www/upcoming_meeting.html (original)
+++ libcxx/trunk/www/upcoming_meeting.html Tue Feb 16 10:05:15 2016
@@ -78,9 +78,9 @@
http://cplusplus.github.io/LWG/lwg-defects.html#2572";>2572The
 remarks for shared_ptr::operator* should apply to cv-qualified 
void as wellJacksonville
http://cplusplus.github.io/LWG/lwg-defects.html#2574";>2574[fund.ts.v2]
 std::experimental::function::operator=(F&&) should be 
constrainedJacksonville
http://cplusplus.github.io/LWG/lwg-defects.html#2575";>2575[fund.ts.v2]
 experimental::function::assign should be 
removedJacksonville
-   http://cplusplus.github.io/LWG/lwg-defects.html#2576";>2576istream_iterator
 and ostream_iterator should use 
std::addressofJacksonville
+   http://cplusplus.github.io/LWG/lwg-defects.html#2576";>2576istream_iterator
 and ostream_iterator should use 
std::addressofJacksonvillePatch done; needs 
tests
http://cplusplus.github.io/LWG/lwg-defects.html#2577";>2577{shared,unique}_lock
 should use std::addressofJacksonville
-   http://cplusplus.github.io/LWG/lwg-defects.html#2579";>2579Inconsistency
 wrt Allocators in basic_string assignment vs. 
basic_string::assignJacksonville
+   http://cplusplus.github.io/LWG/lwg-defects.html#2579";>2579Inconsistency
 wrt Allocators in basic_string assignment vs. 
basic_string::assignJacksonvillePatch 
Ready
http://cplusplus.github.io/LWG/lwg-defects.html#2581";>2581Specialization
 of  variable templates should be 
prohibitedJacksonville
http://cplusplus.github.io/LWG/lwg-defects.html#2582";>2582§[res.on.functions]/2's
 prohibition against incomplete types shouldn't apply to type 
traitsJacksonville
http://cplusplus.github.io/LWG/lwg-defects.html#2583";>2583There
 is no way to supply an allocator for basic_string(str, 
pos)Jacksonville
@@ -112,9 +112,9 @@
 2572 - 
 2574 - 
 2575 - I don't think we ever implemented this; so 'removing' it is 
trivial
-2576 - This one is simple
+2576 - This one is simple, but testing it will be hard. I tried making a 
sublass of istringstream, but it got sliced.
 2577 - This one is simple
-2579 - This one is simple
+2579 - Done.
 2581 - 
 2582 - 
 2583 - This looks easy.


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

Re: [PATCH] D17034: Add an AST matcher for null pointers

[Aaron Ballman via cfe-commits]

aaron.ballman updated this revision to Diff 48075.
aaron.ballman added a comment.

Using the AST_MATCHER_FUNCTION macro instead.

Using Expr::isNullPointerConstant() turns out to have strange behavior with 
implicit casts and nullptr, and also requires further restrictions (for 
instance, it claims the initializer for `int i = 0` is a null pointer constant, 
which is strictly true, but practically useless).


http://reviews.llvm.org/D17034

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
@@ -5348,5 +5348,15 @@
   )));
 }
 
+TEST(NullPointerConstants, Basic) {
+  EXPECT_TRUE(matches("#define NULL ((void *)0)\n"
+  "void *v1 = NULL;", expr(nullPointerConstant(;
+  EXPECT_TRUE(matches("void *v2 = nullptr;", expr(nullPointerConstant(;
+  EXPECT_TRUE(matches("void *v3 = __null;", expr(nullPointerConstant(;
+  EXPECT_TRUE(matches("char *cp = (char *)0;", expr(nullPointerConstant(;
+  EXPECT_TRUE(matches("int *ip = 0;", expr(nullPointerConstant(;
+  EXPECT_TRUE(notMatches("int i = 0", expr(nullPointerConstant(;
+}
+
 } // end namespace ast_matchers
 } // end namespace clang
Index: lib/ASTMatchers/Dynamic/Registry.cpp
===
--- lib/ASTMatchers/Dynamic/Registry.cpp
+++ lib/ASTMatchers/Dynamic/Registry.cpp
@@ -326,6 +326,7 @@
   REGISTER_MATCHER(namesType);
   REGISTER_MATCHER(nestedNameSpecifier);
   REGISTER_MATCHER(nestedNameSpecifierLoc);
+  REGISTER_MATCHER(nullPointerConstant);
   REGISTER_MATCHER(nullStmt);
   REGISTER_MATCHER(numSelectorArgs);
   REGISTER_MATCHER(ofClass);
Index: include/clang/ASTMatchers/ASTMatchers.h
===
--- include/clang/ASTMatchers/ASTMatchers.h
+++ include/clang/ASTMatchers/ASTMatchers.h
@@ -4816,6 +4816,27 @@
   Stmt,
   CUDAKernelCallExpr> cudaKernelCallExpr;
 
+
+/// \brief Matches expressions that resolve to a null pointer constant, such as
+/// GNU's __null, C++11's nullptr, or C's NULL macro.
+///
+/// Given:
+/// \code
+///   void *v1 = NULL;
+///   void *v2 = nullptr;
+///   void *v3 = __null; // GNU extension
+///   char *cp = (char *)0;
+///   int *ip = 0;
+///   int i = 0;
+/// \endcode
+/// expr(nullPointerConstant())
+///   matches the initializer for v1, v2, v3, cp, and ip. Does not match the
+///   initializer for i.
+AST_MATCHER_FUNCTION(internal::Matcher, nullPointerConstant) {
+  return anyOf(
+  gnuNullExpr(), cxxNullPtrLiteralExpr(),
+  expr(integerLiteral(equals(0), 
hasParent(expr(hasType(pointerType()));
+}
 } // end namespace ast_matchers
 } // end namespace clang
 
Index: docs/LibASTMatchersReference.html
===
--- docs/LibASTMatchersReference.html
+++ docs/LibASTMatchersReference.html
@@ -2176,6 +2176,23 @@
 
 
 
+MatcherExpr>nullPointerConstant
+Matches 
expressions that resolve to a null pointer constant, such as
+GNU's __null, C++11's nullptr, or C's NULL macro.
+
+Given:
+  void *v1 = NULL;
+  void *v2 = nullptr;
+  void *v3 = __null; GNU extension
+  char *cp = (char *)0;
+  int *ip = 0;
+  int i = 0;
+expr(nullPointerConstant())
+  matches the initializer for v1, v2, v3, cp, and ip. Does not match the
+  initializer for i.
+
+
+
 MatcherFloatingLiteral>equalsValueT  Value
 Matches literals that are 
equal to the given value.
 


Index: unittests/ASTMatchers/ASTMatchersTest.cpp
===
--- unittests/ASTMatchers/ASTMatchersTest.cpp
+++ unittests/ASTMatchers/ASTMatchersTest.cpp
@@ -5348,5 +5348,15 @@
   )));
 }
 
+TEST(NullPointerConstants, Basic) {
+  EXPECT_TRUE(matches("#define NULL ((void *)0)\n"
+  "void *v1 = NULL;", expr(nullPointerConstant(;
+  EXPECT_TRUE(matches("void *v2 = nullptr;", expr(nullPointerConstant(;
+  EXPECT_TRUE(matches("void *v3 = __null;", expr(nullPointerConstant(;
+  EXPECT_TRUE(matches("char *cp = (char *)0;", expr(nullPointerConstant(;
+  EXPECT_TRUE(matches("int *ip = 0;", expr(nullPointerConstant(;
+  EXPECT_TRUE(notMatches("int i = 0", expr(nullPointerConstant(;
+}
+
 } // end namespace ast_matchers
 } // end namespace clang
Index: lib/ASTMatchers/Dynamic/Registry.cpp
===
--- lib/ASTMatchers/Dynamic/Registry.cpp
+++ lib/ASTMatchers/Dynamic/Registry.cpp
@@ -326,6 +326,7 @@
   REGISTER_MATCHER(namesType);
   REGISTER_MATCHER(nestedNameSpe

Re: [PATCH] D17272: Teach clang to use the ThinLTO pipeline

[Teresa Johnson via cfe-commits]

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

LGTM, thanks


http://reviews.llvm.org/D17272



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

[libcxx] r260982 - Merging r258107:

[Hans Wennborg via cfe-commits]

Author: hans
Date: Tue Feb 16 11:16:15 2016
New Revision: 260982

URL: http://llvm.org/viewvc/llvm-project?rev=260982&view=rev
Log:
Merging r258107:

r258107 | marshall | 2016-01-18 16:50:37 -0800 (Mon, 18 Jan 2016) | 1 line

Fix PR#26175. Thanks to Josh Petrie for the report and the patch. Reviewed as 
http://reviews.llvm.org/D16262


Modified:
libcxx/branches/release_38/   (props changed)
libcxx/branches/release_38/include/regex

libcxx/branches/release_38/test/std/re/re.regex/re.regex.construct/bad_escape.pass.cpp

Propchange: libcxx/branches/release_38/
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Tue Feb 16 11:16:15 2016
@@ -1,2 +1,2 @@
 /libcxx/branches/apple:136569-137939
-/libcxx/trunk:257682,257696,257702,258403
+/libcxx/trunk:257682,257696,257702,258107,258403

Modified: libcxx/branches/release_38/include/regex
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/branches/release_38/include/regex?rev=260982&r1=260981&r2=260982&view=diff
==
--- libcxx/branches/release_38/include/regex (original)
+++ libcxx/branches/release_38/include/regex Tue Feb 16 11:16:15 2016
@@ -4265,6 +4265,9 @@ basic_regex<_CharT, _Traits>::__parse_at
 if (__first != __last && *__first == '\\')
 {
 _ForwardIterator __t1 = _VSTD::next(__first);
+if (__t1 == __last)
+__throw_regex_error();
+
 _ForwardIterator __t2 = __parse_decimal_escape(__t1, __last);
 if (__t2 != __t1)
 __first = __t2;

Modified: 
libcxx/branches/release_38/test/std/re/re.regex/re.regex.construct/bad_escape.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/branches/release_38/test/std/re/re.regex/re.regex.construct/bad_escape.pass.cpp?rev=260982&r1=260981&r2=260982&view=diff
==
--- 
libcxx/branches/release_38/test/std/re/re.regex/re.regex.construct/bad_escape.pass.cpp
 (original)
+++ 
libcxx/branches/release_38/test/std/re/re.regex/re.regex.construct/bad_escape.pass.cpp
 Tue Feb 16 11:16:15 2016
@@ -33,6 +33,7 @@ int main()
 {
 assert(error_escape_thrown("[\\a]"));
 assert(error_escape_thrown("\\a"));
+assert(error_escape_thrown("\\"));
 
 assert(error_escape_thrown("[\\e]"));
 assert(error_escape_thrown("\\e"));


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

Re: [libcxx] r258107 - Fix PR#26175. Thanks to Josh Petrie for the report and the patch. Reviewed as http://reviews.llvm.org/D16262

[Hans Wennborg via cfe-commits]

Marshall told me this one's approved. Merged in r260982. Thanks, Hans

On Fri, Feb 12, 2016 at 10:22 AM, Hans Wennborg  wrote:
> Marshall: ping?
>
> On Mon, Feb 1, 2016 at 1:48 PM, Hans Wennborg  wrote:
>> Marshall: ping?
>>
>> On Tue, Jan 26, 2016 at 11:08 AM, Hans Wennborg  wrote:
>>> On Tue, Jan 19, 2016 at 9:21 AM, Hans Wennborg  wrote:
 On Tue, Jan 19, 2016 at 12:01 AM, Dimitry Andric  
 wrote:
> On 19 Jan 2016, at 01:50, Marshall Clow via cfe-commits 
>  wrote:
>>
>> Author: marshall
>> Date: Mon Jan 18 18:50:37 2016
>> New Revision: 258107
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=258107&view=rev
>> Log:
>> Fix PR#26175. Thanks to Josh Petrie for the report and the patch. 
>> Reviewed as http://reviews.llvm.org/D16262
>
> This looks like a good candidate for the 3.8 branch, do you agree?

 Sounds good to me if Marshall agrees.
>>>
>>> Ping?
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D17034: Add an AST matcher for null pointers

[Samuel Benzaquen via cfe-commits]

sbenza added inline comments.


Comment at: include/clang/ASTMatchers/ASTMatchers.h:4838
@@ +4837,3 @@
+  gnuNullExpr(), cxxNullPtrLiteralExpr(),
+  expr(integerLiteral(equals(0), 
hasParent(expr(hasType(pointerType()));
+}

is this expr() necessary?


http://reviews.llvm.org/D17034



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

[libcxx] r260983 - Merging r259682:

[Hans Wennborg via cfe-commits]

Author: hans
Date: Tue Feb 16 11:17:42 2016
New Revision: 260983

URL: http://llvm.org/viewvc/llvm-project?rev=260983&view=rev
Log:
Merging r259682:

r259682 | dexonsmith | 2016-02-03 11:30:20 -0800 (Wed, 03 Feb 2016) | 7 lines

re.results.form: Format out-of-range subexpression references as null

Rather than crashing in match_results::format() when a reference to a
marked subexpression is out of range, format the subexpression as empty
(i.e., replace it with an empty string).  Note that
match_results::operator[]() has a range-check and returns a null match
in this case, so this just re-uses that logic.


Modified:
libcxx/branches/release_38/   (props changed)
libcxx/branches/release_38/include/regex

libcxx/branches/release_38/test/std/re/re.results/re.results.form/form1.pass.cpp

Propchange: libcxx/branches/release_38/
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Tue Feb 16 11:17:42 2016
@@ -1,2 +1,2 @@
 /libcxx/branches/apple:136569-137939
-/libcxx/trunk:257682,257696,257702,258107,258403
+/libcxx/trunk:257682,257696,257702,258107,258403,259682

Modified: libcxx/branches/release_38/include/regex
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/branches/release_38/include/regex?rev=260983&r1=260982&r2=260983&view=diff
==
--- libcxx/branches/release_38/include/regex (original)
+++ libcxx/branches/release_38/include/regex Tue Feb 16 11:17:42 2016
@@ -5387,8 +5387,8 @@ match_results<_BidirectionalIterator, _A
 if ('0' <= *__fmt_first && *__fmt_first <= '9')
 {
 size_t __i = *__fmt_first - '0';
-__out = _VSTD::copy(__matches_[__i].first,
-   __matches_[__i].second, __out);
+__out = _VSTD::copy((*this)[__i].first,
+(*this)[__i].second, __out);
 }
 else
 {
@@ -5439,8 +5439,8 @@ match_results<_BidirectionalIterator, _A
 ++__fmt_first;
 __i = 10 * __i + *__fmt_first - '0';
 }
-__out = _VSTD::copy(__matches_[__i].first,
-   __matches_[__i].second, __out);
+__out = _VSTD::copy((*this)[__i].first,
+(*this)[__i].second, __out);
 }
 else
 {

Modified: 
libcxx/branches/release_38/test/std/re/re.results/re.results.form/form1.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/branches/release_38/test/std/re/re.results/re.results.form/form1.pass.cpp?rev=260983&r1=260982&r2=260983&view=diff
==
--- 
libcxx/branches/release_38/test/std/re/re.results/re.results.form/form1.pass.cpp
 (original)
+++ 
libcxx/branches/release_38/test/std/re/re.results/re.results.form/form1.pass.cpp
 Tue Feb 16 11:17:42 2016
@@ -38,6 +38,31 @@ int main()
 {
 std::match_results m;
 const char s[] = "abcdefghijk";
+assert(std::regex_search(s, m, std::regex("cd((e)fg)hi",
+  
std::regex_constants::nosubs)));
+
+char out[100] = {0};
+const char fmt[] = "prefix: $`, match: $&, suffix: $', m[1]: $1, m[2]: 
$2";
+char* r = m.format(output_iterator(out),
+fmt, fmt + std::char_traits::length(fmt)).base();
+assert(r == out + 54);
+assert(std::string(out) == "prefix: ab, match: cdefghi, suffix: jk, 
m[1]: , m[2]: ");
+}
+{
+std::match_results m;
+const char s[] = "abcdefghijk";
+assert(std::regex_search(s, m, std::regex("cdefghi")));
+
+char out[100] = {0};
+const char fmt[] = "prefix: $`, match: $&, suffix: $', m[1]: $1, m[2]: 
$2";
+char* r = m.format(output_iterator(out),
+fmt, fmt + std::char_traits::length(fmt)).base();
+assert(r == out + 54);
+assert(std::string(out) == "prefix: ab, match: cdefghi, suffix: jk, 
m[1]: , m[2]: ");
+}
+{
+std::match_results m;
+const char s[] = "abcdefghijk";
 assert(std::regex_search(s, m, std::regex("cd((e)fg)hi")));
 
 char out[100] = {0};
@@ -61,6 +86,33 @@ int main()
 assert(r == out + 34);
 assert(std::string(out) == "match: cdefghi, m[1]: efg, m[2]: e");
 }
+{
+std::match_results m;
+const char s[] = "abcdefghijk";
+assert(std::regex_search(s, m, std::regex("cd((e)fg)hi",
+  
std::regex_con

Re: [libcxx] r259682 - re.results.form: Format out-of-range subexpression references as null

[Hans Wennborg via cfe-commits]

Marshall told me it's approved. Merged in r260983. Thanks, Hans

On Fri, Feb 12, 2016 at 10:34 AM, Hans Wennborg  wrote:
> Marshall: ping?
>
> On Wed, Feb 3, 2016 at 5:08 PM, Hans Wennborg  wrote:
>> I'm OK if Marshall is.
>>
>> Thanks,
>> Hans
>>
>> On Wed, Feb 3, 2016 at 4:59 PM, Duncan P. N. Exon Smith via
>> cfe-commits  wrote:
>>> Hans, do you mind merging this to the 3.8 branch?
>>>
>>> Marshall, do you agree this is okay to take?
>>>
 On 2016-Feb-03, at 11:30, Duncan P. N. Exon Smith via cfe-commits 
  wrote:

 Author: dexonsmith
 Date: Wed Feb  3 13:30:20 2016
 New Revision: 259682

 URL: http://llvm.org/viewvc/llvm-project?rev=259682&view=rev
 Log:
 re.results.form: Format out-of-range subexpression references as null

 Rather than crashing in match_results::format() when a reference to a
 marked subexpression is out of range, format the subexpression as empty
 (i.e., replace it with an empty string).  Note that
 match_results::operator[]() has a range-check and returns a null match
 in this case, so this just re-uses that logic.

 Modified:
libcxx/trunk/include/regex
libcxx/trunk/test/std/re/re.results/re.results.form/form1.pass.cpp

 Modified: libcxx/trunk/include/regex
 URL: 
 http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/regex?rev=259682&r1=259681&r2=259682&view=diff
 ==
 --- libcxx/trunk/include/regex (original)
 +++ libcxx/trunk/include/regex Wed Feb  3 13:30:20 2016
 @@ -5387,8 +5387,8 @@ match_results<_BidirectionalIterator, _A
 if ('0' <= *__fmt_first && *__fmt_first <= '9')
 {
 size_t __i = *__fmt_first - '0';
 -__out = _VSTD::copy(__matches_[__i].first,
 -   __matches_[__i].second, __out);
 +__out = _VSTD::copy((*this)[__i].first,
 +(*this)[__i].second, __out);
 }
 else
 {
 @@ -5439,8 +5439,8 @@ match_results<_BidirectionalIterator, _A
 ++__fmt_first;
 __i = 10 * __i + *__fmt_first - '0';
 }
 -__out = _VSTD::copy(__matches_[__i].first,
 -   __matches_[__i].second, __out);
 +__out = _VSTD::copy((*this)[__i].first,
 +(*this)[__i].second, __out);
 }
 else
 {

 Modified: 
 libcxx/trunk/test/std/re/re.results/re.results.form/form1.pass.cpp
 URL: 
 http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/re/re.results/re.results.form/form1.pass.cpp?rev=259682&r1=259681&r2=259682&view=diff
 ==
 --- libcxx/trunk/test/std/re/re.results/re.results.form/form1.pass.cpp 
 (original)
 +++ libcxx/trunk/test/std/re/re.results/re.results.form/form1.pass.cpp Wed 
 Feb  3 13:30:20 2016
 @@ -38,6 +38,31 @@ int main()
 {
 std::match_results m;
 const char s[] = "abcdefghijk";
 +assert(std::regex_search(s, m, std::regex("cd((e)fg)hi",
 +  
 std::regex_constants::nosubs)));
 +
 +char out[100] = {0};
 +const char fmt[] = "prefix: $`, match: $&, suffix: $', m[1]: $1, 
 m[2]: $2";
 +char* r = m.format(output_iterator(out),
 +fmt, fmt + 
 std::char_traits::length(fmt)).base();
 +assert(r == out + 54);
 +assert(std::string(out) == "prefix: ab, match: cdefghi, suffix: 
 jk, m[1]: , m[2]: ");
 +}
 +{
 +std::match_results m;
 +const char s[] = "abcdefghijk";
 +assert(std::regex_search(s, m, std::regex("cdefghi")));
 +
 +char out[100] = {0};
 +const char fmt[] = "prefix: $`, match: $&, suffix: $', m[1]: $1, 
 m[2]: $2";
 +char* r = m.format(output_iterator(out),
 +fmt, fmt + 
 std::char_traits::length(fmt)).base();
 +assert(r == out + 54);
 +assert(std::string(out) == "prefix: ab, match: cdefghi, suffix: 
 jk, m[1]: , m[2]: ");
 +}
 +{
 +std::match_results m;
 +const char s[] = "abcdefghijk";
 assert(std::regex_search(s, m, std::regex("cd((e)fg)hi")));

 char out[100] = {0};
 @@ -61,6 +86,33 @@ int main()
 assert(r == out + 34);
 assert(std::string(out) == "match: cdefghi, m[1]: efg, m[2]: e");
>

Re: [PATCH] D16929: add support for -print-imm-hex for AArch64

[James Molloy via cfe-commits]

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

LGTM, thanks!


Repository:
  rL LLVM

http://reviews.llvm.org/D16929



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

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

[Eli Bendersky via cfe-commits]

eliben added inline comments.


Comment at: lib/CodeGen/TargetInfo.cpp:6498
@@ +6497,3 @@
+
+  Class classify(QualType Ty) const;
+

jpienaar wrote:
> We only had one DefaultNumRegisterParameters that we supported 
> (DefaultNumRegisterParameters=4) so I just propagated the constant, removed 
> the member variable and added a comment at its use.
SG, thanks


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

why wasm triple?


http://reviews.llvm.org/D17002



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

Re: r260851 - As reported in https://llvm.org/bugs/show_bug.cgi?id=25496, on FreeBSD,

[Hans Wennborg via cfe-commits]

On Sun, Feb 14, 2016 at 8:14 AM, Dimitry Andric  wrote:
> On 14 Feb 2016, at 17:08, Dimitry Andric via cfe-commits 
>  wrote:
>>
>> Author: dim
>> Date: Sun Feb 14 10:08:20 2016
>> New Revision: 260851
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=260851&view=rev
>> Log:
>> As reported in https://llvm.org/bugs/show_bug.cgi?id=25496, on FreeBSD,
>> C++ programs compiled for profiling (using `-pg`) should be linked with
>> `-lc++_p` (or `-lstdc++_p`, depending on the `-stdlib=` setting), not
>> with the regular C++ libraries.
>>
>> Add a `FreeBSD::AddCXXStdlibLibArgs()` override to handle this, and add
>> a test case for it.  While here, extend the test case for the proper
>> passing of -lm and -lm_p.
>>
>> Reviewers: compnerd, davide, dws, emaste
>> Reviewed By: compnerd
>> Differential Revision: http://reviews.llvm.org/D16264
>
> Hi Hans,
>
> I would like to merge this to the 3.8 branch.  This only affects FreeBSD.

I'm OK with that, go ahead (or let me know if you'd like me to merge it).

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

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

[H.J. Lu via cfe-commits]

On Fri, Feb 12, 2016 at 11:39 AM, H.J. Lu  wrote:
> On Fri, Feb 12, 2016 at 6:58 AM, Matthijs van Duin
>  wrote:
>> On 11 February 2016 at 16:31, H.J. Lu  wrote:
>>> struct A {
>>> static void foo (void) ();
>>> static int xxx;
>>> };
>>
>> What about it? It's an empty struct.  (And it declares a function and
>> a variable in the namespace of A, which however do not have any
>> relevant impact here.)
>>
>
> Thanks for all the feedbacks.  Here is the new proposal:
>
> 1. "empty type".  An empty type is a trivially-copyable aggregate
> occupying zero bytes (excluding any padding).
> 2. No memory slot nor register should be used to pass or return an object
> of empty type.
>
> Footnote: Array of empty type can only passed by reference in C/C++.
>

I updated intel386, x86-64 and IA MCU psABIs:

https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI

to specify:

Empty type is defined as a trivially-copyable aggregate occupying zero bytes
(excluding any padding). No memory slot nor register should be used to pass or
return an object object of empty type.

with footnote: Array of empty type can only passed by reference in C and C++.

Any comments?

Thanks.


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

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

[Carlo Bertolli via cfe-commits]

carlo.bertolli added inline comments.


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

carlo.bertolli wrote:
> I added this because OpenMPScheduleClauseKind and 
> OpenMPDistScheduleClauseKind are two different unrelated types. Do you 
> suggest something like the following?
> 
> void emitForStaticInit(CodeGenFunction &CGF, SourceLocation Loc, 
> OpenMPScheduleClauseKind ScheduleKind, OpenMPDistScheduleClauseKind 
> ScheduleKind, unsigned IVSize, bool IVSigned, bool Ordered, Address IL, 
> Address LB, Address UB, Address ST, llvm::Value *Chunk);
> 
> and for dist_schedule called like:
> 
> OpenMPDistScheduleClauseKind DistScheduleKind = ..;
> 
> RT.emitForStaticInit(*this, S.getLocStart(), OMPC_SCHEDULE_unknown, 
> DistScheduleKind, IVSize, IVSigned, Ordered, IL, LB, UB, ST, Chunk);
> 
> Similarly, for schedule clause:
> 
> OpenMPScheduleClauseKind ScheduleKind = ..;
> 
> RT.emitForStaticInit(*this, S.getLocStart(), ScheduleKind, 
> OMPC_DIST_SCHEDULE_unknown, IVSize, IVSigned, Ordered, IL, LB, UB, ST, Chunk);
> 
> 
Another solution is to have a generic schedule type as a union of the schedule 
and dist_schedule enum types.


```
  union OMPGenericSchedule {
OpenMPScheduleClauseKind forSchedule;
OpenMPDistScheduleClauseKind distributeSchedule;
  };
```

Then we can decide which case we are in as following:

```
void CGOpenMPRuntime::emitForStaticInit(CodeGenFunction &CGF,
SourceLocation Loc,
OMPGenericSchedule SchedKind,
bool isForSchedule,
unsigned IVSize, bool IVSigned,
bool Ordered, Address IL, Address LB,
Address UB, Address ST,
llvm::Value *Chunk) {

  OpenMPSchedType Schedule = (isForSchedule) ?
  getRuntimeSchedule(SchedKind.forSchedule, Chunk != nullptr, Ordered) :
  getRuntimeSchedule(SchedKind.distributeSchedule, Chunk != nullptr);
```


Repository:
  rL LLVM

http://reviews.llvm.org/D17170



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

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

[Samuel Antao via cfe-commits]

sfantao added a comment.

Hi Alexey,

Thanks for the review!



Comment at: lib/CodeGen/CGExpr.cpp:2937-2943
@@ -2936,2 +2936,9 @@
   QualType BaseTy = Base.getType();
+  // If the base is a pointer, we actually need to compute the offset in the
+  // pointee.
+  if (BaseTy->isAnyPointerType()) {
+auto RBase = EmitLoadOfLValue(Base, E->getExprLoc());
+Base = MakeNaturalAlignAddrLValue(
+RBase.getScalarVal(), BaseTy->getAs()->getPointeeType());
+  }
   llvm::Value *Idx = nullptr;

ABataev wrote:
> This must be fixed already, please reabse
Thanks for the fix! I've  just posted a rebased patch.


Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:3915-3946
@@ +3914,34 @@
+// Reference types are ignored for mapping purposes.
+if (auto *RefTy = ExprTy->getAs())
+  ExprTy = RefTy->getPointeeType().getCanonicalType();
+
+// Given that an array section is considered a built-in type, we need to
+// do the calculation based on the length of the section instead of relying
+// on CGF.getTypeSize(E->getType()).
+if (const auto *OAE = dyn_cast(E)) {
+
+  auto BaseTy = OAE->getBase()->getType().getCanonicalType();
+  // Reference types are ignored for mapping purposes.
+  if (auto *RefTy = BaseTy->getAs())
+BaseTy = RefTy->getPointeeType().getCanonicalType();
+
+  // If there is no length associated with the expression, that means we
+  // are using the whole length of the base.
+  if (!OAE->getLength())
+return CGF.getTypeSize(BaseTy);
+
+  llvm::Value *ElemSize;
+  if (auto *PTy = BaseTy->getAs()) {
+ElemSize = CGF.getTypeSize(PTy->getPointeeType().getCanonicalType());
+  } else {
+auto *ATy = cast(BaseTy.getTypePtr());
+assert(ATy && "Expecting array type if not a pointer type.");
+ElemSize = CGF.getTypeSize(ATy->getElementType().getCanonicalType());
+  }
+
+  auto *LengthVal = CGF.EmitScalarExpr(OAE->getLength());
+  LengthVal =
+  CGF.Builder.CreateIntCast(LengthVal, CGF.SizeTy, /*isSigned=*/false);
+  return CGF.Builder.CreateNUWMul(LengthVal, ElemSize);
+}
+return CGF.getTypeSize(ExprTy);

ABataev wrote:
> I don't think this is correct. It won't work for 2(and more)-dimensional 
> array sections. Instead calculate size as 
> 'last_item_address-first_item_address+1'.
I don't see why it should not work. There was only a small issue related with 
array decays to pointer that I fixed in the new diff. The size of the section 
always refer to the right most expression, even for multidimensional arrays. I 
added regression tests for that.

Other reason I avoided computing sizes based on addresses is that they do not 
get folded into constants. In code generation we have optimized behaviors for 
when all the sizes are constants so that a constant array is implemented 
instead of filling (at runtime) an array with constants to be passed  to the 
runtime library.

Let me know if you disagree.


Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:4126-4128
@@ +4125,5 @@
+  if (auto *ME = dyn_cast(I->first)) {
+// The base is the 'this' pointer. The content of the pointer is going
+// to be the base of the field being mapped.
+BP = CGF.EmitScalarExpr(ME->getBase());
+  } else {

ABataev wrote:
> In a few days you won't need it at all. All member references are implicitly 
> captured into special declaration and you should not worry about them at all
Great! Thanks for working on that! I'll then see how that will interfere with 
the map clause code generation.


http://reviews.llvm.org/D16749



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

[PATCH] D17299: [ASTReader] Report error when accessing corrupt record data

[Vedant Kumar via cfe-commits]

vsk created this revision.
vsk added reviewers: rsmith, benlangmuir.
vsk added a subscriber: cfe-commits.

If we try to read a corrupt pch, we can easily assert-fail or trigger invalid
memory accesses when manipulating ASTReader::RecordData objects. This problem
is easy enough to diagnose when assertions are enabled, but can cause trouble
otherwise.

Emit an error diagnostic when we detect a bad RecordData access.

http://reviews.llvm.org/D17299

Files:
  include/clang/Serialization/ASTReader.h
  lib/Serialization/ASTReader.cpp
  lib/Serialization/ASTReaderDecl.cpp
  lib/Serialization/ASTReaderStmt.cpp

Index: lib/Serialization/ASTReaderStmt.cpp
===
--- lib/Serialization/ASTReaderStmt.cpp
+++ lib/Serialization/ASTReaderStmt.cpp
@@ -2575,7 +2575,7 @@
   unsigned PrevNumStmts = StmtStack.size();
 #endif
 
-  RecordData Record;
+  RecordData Record(this);
   unsigned Idx;
   ASTStmtReader Reader(*this, F, Cursor, Record, Idx);
   Stmt::EmptyShell Empty;
Index: lib/Serialization/ASTReaderDecl.cpp
===
--- lib/Serialization/ASTReaderDecl.cpp
+++ lib/Serialization/ASTReaderDecl.cpp
@@ -3129,7 +3129,7 @@
   Deserializing ADecl(this);
 
   DeclsCursor.JumpToBit(Loc.Offset);
-  RecordData Record;
+  RecordData Record(this);
   unsigned Code = DeclsCursor.ReadCode();
   unsigned Idx = 0;
   ASTDeclReader Reader(*this, *Loc.F, ID, RawLocation, Record,Idx);
@@ -3408,7 +3408,7 @@
   llvm::BitstreamCursor &Cursor = F->DeclsCursor;
   SavedStreamPosition SavedPosition(Cursor);
   Cursor.JumpToBit(Offset);
-  RecordData Record;
+  RecordData Record(this);
   unsigned Code = Cursor.ReadCode();
   unsigned RecCode = Cursor.readRecord(Code, Record);
   (void)RecCode;
@@ -3452,7 +3452,7 @@
   SavedStreamPosition SavedPosition(Cursor);
   Cursor.JumpToBit(LocalOffset);
 
-  RecordData Record;
+  RecordData Record(this);
   unsigned Code = Cursor.ReadCode();
   unsigned RecCode = Cursor.readRecord(Code, Record);
   (void)RecCode;
Index: lib/Serialization/ASTReader.cpp
===
--- lib/Serialization/ASTReader.cpp
+++ lib/Serialization/ASTReader.cpp
@@ -988,7 +988,7 @@
   SavedStreamPosition SavedPosition(Cursor);
   Cursor.JumpToBit(Offset);
 
-  RecordData Record;
+  RecordData Record(this);
   StringRef Blob;
   unsigned Code = Cursor.ReadCode();
   unsigned RecCode = Cursor.readRecord(Code, Record, &Blob);
@@ -1024,7 +1024,7 @@
   SavedStreamPosition SavedPosition(Cursor);
   Cursor.JumpToBit(Offset);
 
-  RecordData Record;
+  RecordData Record(this);
   StringRef Blob;
   unsigned Code = Cursor.ReadCode();
   unsigned RecCode = Cursor.readRecord(Code, Record, &Blob);
@@ -1130,7 +1130,7 @@
 return true;
   }
 
-  RecordData Record;
+  RecordData Record(this);
   while (true) {
 llvm::BitstreamEntry E = SLocEntryCursor.advanceSkippingSubblocks();
 
@@ -1209,7 +1209,7 @@
   auto ReadBuffer = [this](
   BitstreamCursor &SLocEntryCursor,
   StringRef Name) -> std::unique_ptr {
-RecordData Record;
+RecordData Record(this);
 StringRef Blob;
 unsigned Code = SLocEntryCursor.ReadCode();
 unsigned RecCode = SLocEntryCursor.readRecord(Code, Record, &Blob);
@@ -1242,7 +1242,7 @@
 return true;
   }
   
-  RecordData Record;
+  RecordData Record(this);
   StringRef Blob;
   switch (SLocEntryCursor.readRecord(Entry.ID, Record, &Blob)) {
   default:
@@ -1410,7 +1410,7 @@
   SavedStreamPosition SavedPosition(Stream);
 
   Stream.JumpToBit(Offset);
-  RecordData Record;
+  RecordData Record(this);
   SmallVector MacroArgs;
   MacroInfo *Macro = nullptr;
 
@@ -1656,7 +1656,7 @@
 BitstreamCursor Cursor = MacroCursor;
 Cursor.JumpToBit(I->MacroStartOffset);
 
-RecordData Record;
+RecordData Record(this);
 while (true) {
   llvm::BitstreamEntry E = Cursor.advanceSkippingSubblocks();
   
@@ -1798,7 +1798,7 @@
   // We expect to see a sequence of PP_MODULE_MACRO records listing exported
   // macros, followed by a PP_MACRO_DIRECTIVE_HISTORY record with the complete
   // macro histroy.
-  RecordData Record;
+  RecordData Record(this);
   while (true) {
 llvm::BitstreamEntry Entry =
 Cursor.advance(BitstreamCursor::AF_DontPopBlockAtEnd);
@@ -1898,7 +1898,7 @@
   Cursor.JumpToBit(F.InputFileOffsets[ID-1]);
 
   unsigned Code = Cursor.ReadCode();
-  RecordData Record;
+  RecordData Record(this);
   StringRef Blob;
 
   unsigned Result = Cursor.readRecord(Code, Record, &Blob);
@@ -2090,7 +2090,7 @@
 return Failure;
 
   // Read all of the records in the options block.
-  RecordData Record;
+  RecordData Record(nullptr);
   ASTReadResult Result = Success;
   while (1) {
 llvm::BitstreamEntry Entry = Stream.advance();
@@ -2176,7 +2176,7 @@
   }
 
   // Read all of the records and blocks in the control block.
-  RecordData Record;
+  RecordData Recor

r260990 - clang-cl: Expose -isystem.

[Nico Weber via cfe-commits]

Author: nico
Date: Tue Feb 16 13:05:50 2016
New Revision: 260990

URL: http://llvm.org/viewvc/llvm-project?rev=260990&view=rev
Log:
clang-cl: Expose -isystem.

Like cl.exe, clang-cl allows adding system include directories via the
INCLUDE env var.  Having a driver flag for this functionality is useful,
so add this too.

(In the future, we probably also want to have a flag alternative to
VCINSTALLDIR as used in MSVCToolChain::getVisualStudioBinaries(), and
a way to override the registry accesses in MSVCToolChain::getWindowsSDKDir()
-- maybe -ivcroot= and -iwinsdkroot=?).


Modified:
cfe/trunk/include/clang/Driver/Options.td
cfe/trunk/test/Driver/cl-options.c

Modified: cfe/trunk/include/clang/Driver/Options.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=260990&r1=260989&r2=260990&view=diff
==
--- cfe/trunk/include/clang/Driver/Options.td (original)
+++ cfe/trunk/include/clang/Driver/Options.td Tue Feb 16 13:05:50 2016
@@ -1229,7 +1229,8 @@ def iquote : JoinedOrSeparate<["-"], "iq
   HelpText<"Add directory to QUOTE include search path">, 
MetaVarName<"">;
 def isysroot : JoinedOrSeparate<["-"], "isysroot">, Group, 
Flags<[CC1Option]>,
   HelpText<"Set the system root directory (usually /)">, MetaVarName<"">;
-def isystem : JoinedOrSeparate<["-"], "isystem">, Group, 
Flags<[CC1Option]>,
+def isystem : JoinedOrSeparate<["-"], "isystem">, Group,
+  Flags<[CC1Option, CoreOption]>,
   HelpText<"Add directory to SYSTEM include search path">, 
MetaVarName<"">;
 def iwithprefixbefore : JoinedOrSeparate<["-"], "iwithprefixbefore">, 
Group,
   HelpText<"Set directory to include search path with prefix">, 
MetaVarName<"">,

Modified: cfe/trunk/test/Driver/cl-options.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/cl-options.c?rev=260990&r1=260989&r2=260990&view=diff
==
--- cfe/trunk/test/Driver/cl-options.c (original)
+++ cfe/trunk/test/Driver/cl-options.c Tue Feb 16 13:05:50 2016
@@ -437,6 +437,7 @@
 // RUN: -fno-ms-compatibility \
 // RUN: -fms-extensions \
 // RUN: -fno-ms-extensions \
+// RUN: -isystem=some/path \
 // RUN: -mllvm -disable-llvm-optzns \
 // RUN: -Wunused-variable \
 // RUN: -fmacro-backtrace-limit=0 \


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

Re: r258524 - Merge templated static member variables, fixes http://llvm.org/pr26179.

[Vassil Vassilev via cfe-commits]

ping...
On 07/02/16 22:33, Vassil Vassilev wrote:

Improve a comment.
--Vassil
On 07/02/16 20:48, Vassil Vassilev wrote:

Would this patch be any better?
--Vassil
On 05/02/16 21:49, Richard Smith wrote:
This belongs in ASTDeclReader::attachPreviousDecl[Impl]. That's 
where we propagate data that's supposed to be consistent across a 
redeclaration chain from earlier declarations to later ones.


There's another wrinkle here: we should only be propagating the type 
from a previous declaration that's declared in the same scope (in 
particular, we should skip over declarations declared as local 
extern declarations within a function). This may in some cases 
require walking backwards along the redeclaration chain to find the 
previous declaration that was not a local extern declaration. That'd 
be observable in a case like this:


modulemap:
module A { module A1 { header "a1.h" } module A2 { header "a2.h" } }
module B { header "b.h" }

a1.h:
int a[];

b.h:
void g(int(*)[], int);
void g(int(*)[1], int) = delete;
template void f(T t) {
  extern int a[];
  g(&a, t);
}

a2.h:
int a[1];

x.cc:
#include "a1.h"
#include "b.h"
void h() { f(0); } // should not produce an error; type of 'a' 
within 'f' should not have been updated


That example actually reveals another problem: we really don't want 
the completed type to be visible unless there is a visible 
declaration with the completed type. That suggests that propagating 
the type across the redeclaration chain may be the wrong approach, 
and we should instead handle this by changing 
isPreferredLookupResult (in SemaLookup.cpp) to prefer a VarDecl with 
a complete type over one with an incomplete type.


On Fri, Feb 5, 2016 at 12:27 PM, Vassil Vassilev 
 wrote:


I am not sure where else to put this logic if not in
isSameEntity... Could you point me to a better place?
--Vassil

On 05/02/16 19:56, Richard Smith wrote:

On Fri, Feb 5, 2016 at 7:04 AM, Vassil Vassilev
 wrote:

Good point. Do you have in mind calling
'clang::Sema::MergeVarDeclTypes' or we to just "duplicate"
the logic in clang::ASTDeclReader::mergeRedeclarable?


It's not safe to call into Sema while we're in a
partially-deserialized state. We know the only interesting case
here is complete versus incomplete array types, so we don't
need anything like the complexity of MergeVarDeclTypes --
something as easy as "if (new type is incomplete and old type
is not) set new type to old type" should work.

On 05/02/16 02:50, Richard Smith via cfe-commits wrote:

I suspect we'll need to do a little more than this: when
we rebuild the redeclaration chain, we should probably
propagate the complete type to later redeclarations in the
same scope. Otherwise, if we import a module that has a
complete type and one that has an incomplete type, the
declaration found by name lookup might be the one with the
incomplete type, possibly resulting in rejects-valid on
code like this:

a.h:
extern int a[5];

b.h:
extern int a[];

x.cc:
#include "a.h"
#include "b.h"
int k = sizeof(a);

On Fri, Jan 22, 2016 at 11:03 AM, Yaron Keren via
cfe-commits  wrote:

Author: yrnkrn
Date: Fri Jan 22 13:03:27 2016
New Revision: 258524

URL:
http://llvm.org/viewvc/llvm-project?rev=258524&view=rev
Log:
Merge templated static member variables, fixes
http://llvm.org/pr26179.

Patch by Vassil Vassilev!
Reviewed by Richard Smith.


Added:
cfe/trunk/test/Modules/Inputs/PR26179/
cfe/trunk/test/Modules/Inputs/PR26179/A.h
cfe/trunk/test/Modules/Inputs/PR26179/B.h
cfe/trunk/test/Modules/Inputs/PR26179/basic_string.h
cfe/trunk/test/Modules/Inputs/PR26179/module.modulemap
cfe/trunk/test/Modules/pr26179.cpp
Modified:
cfe/trunk/lib/Serialization/ASTReaderDecl.cpp

Modified: cfe/trunk/lib/Serialization/ASTReaderDecl.cpp
URL:

http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Serialization/ASTReaderDecl.cpp?rev=258524&r1=258523&r2=258524&view=diff

==
--- cfe/trunk/lib/Serialization/ASTReaderDecl.cpp
(original)
+++ cfe/trunk/lib/Serialization/ASTReaderDecl.cpp Fri
Jan 22 13:03:27 2016
@@ -2595,8 +2595,24 @@ static bool
isSameEntity(NamedDecl *X, N
   // Variables with the same type and linkage match.
   if (VarDecl *VarX = dyn_cast(X)) {
 VarDecl *VarY = cast(Y);
-return (VarX->getLinkageInternal() ==
VarY->getLinkageInternal()) &&
- VarX->getAS

r260993 - [typo-correction] Apply name specifier corrections when forming a NNS

[Reid Kleckner via cfe-commits]

Author: rnk
Date: Tue Feb 16 13:16:20 2016
New Revision: 260993

URL: http://llvm.org/viewvc/llvm-project?rev=260993&view=rev
Log:
[typo-correction] Apply name specifier corrections when forming a NNS

Previously we would leave behind the old name specifier prefix, which
creates an invalid AST.  Other callers of CorrectTypo update their
CXXScopeSpec objects with the correction specifier if one is present.

Modified:
cfe/trunk/lib/Sema/SemaCXXScopeSpec.cpp
cfe/trunk/test/SemaCXX/typo-correction-crash.cpp

Modified: cfe/trunk/lib/Sema/SemaCXXScopeSpec.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaCXXScopeSpec.cpp?rev=260993&r1=260992&r2=260993&view=diff
==
--- cfe/trunk/lib/Sema/SemaCXXScopeSpec.cpp (original)
+++ cfe/trunk/lib/Sema/SemaCXXScopeSpec.cpp Tue Feb 16 13:16:20 2016
@@ -606,6 +606,10 @@ bool Sema::BuildCXXNestedNameSpecifier(S
 diagnoseTypo(Corrected, PDiag(diag::err_undeclared_var_use_suggest)
   << Name);
 
+  if (Corrected.getCorrectionSpecifier())
+SS.MakeTrivial(Context, Corrected.getCorrectionSpecifier(),
+   SourceRange(Found.getNameLoc()));
+
   if (NamedDecl *ND = Corrected.getFoundDecl())
 Found.addDecl(ND);
   Found.setLookupName(Corrected.getCorrection());

Modified: cfe/trunk/test/SemaCXX/typo-correction-crash.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/typo-correction-crash.cpp?rev=260993&r1=260992&r2=260993&view=diff
==
--- cfe/trunk/test/SemaCXX/typo-correction-crash.cpp (original)
+++ cfe/trunk/test/SemaCXX/typo-correction-crash.cpp Tue Feb 16 13:16:20 2016
@@ -9,3 +9,11 @@ auto check2() {
   return "s";
   return tes; // expected-error {{use of undeclared identifier 'tes'; did you 
mean 'test'?}}
 }
+
+namespace BarNamespace {
+namespace NestedNamespace { // expected-note {{'BarNamespace::NestedNamespace' 
declared here}}
+typedef int type;
+}
+}
+struct FooRecord { };
+FooRecord::NestedNamespace::type x; // expected-error {{no member named 
'NestedNamespace' in 'FooRecord'; did you mean 
'BarNamespace::NestedNamespace'?}}


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

r260994 - Exclude PCH/missing-file.cpp on Windows, it does not pass reliably

[Reid Kleckner via cfe-commits]

Author: rnk
Date: Tue Feb 16 13:16:28 2016
New Revision: 260994

URL: http://llvm.org/viewvc/llvm-project?rev=260994&view=rev
Log:
Exclude PCH/missing-file.cpp on Windows, it does not pass reliably

Tag the test with "REQUIRES: can-remove-opened-file", which is what we
use for the similar test Modules/explicit-build-missing-file.cpp.

Modified:
cfe/trunk/test/PCH/missing-file.cpp

Modified: cfe/trunk/test/PCH/missing-file.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/PCH/missing-file.cpp?rev=260994&r1=260993&r2=260994&view=diff
==
--- cfe/trunk/test/PCH/missing-file.cpp (original)
+++ cfe/trunk/test/PCH/missing-file.cpp Tue Feb 16 13:16:28 2016
@@ -4,16 +4,15 @@
 // RUN: echo 'struct S{char c; int i; }; void foo() {}' > %t.h
 // RUN: echo 'template  void tf() { T::foo(); }' >> %t.h
 // RUN: %clang_cc1 -x c++ -emit-pch -o %t.h.pch %t.h
-
-// %t.h might be touched by scanners as a hot file on Windows,
-// to fail to remove %.h with single run.
-// FIXME: Do we really want to work around bugs in virus checkers here?
-// RUN: rm %t.h || rm %t.h || rm %t.h
+// RUN: rm %t.h
 
 // Check diagnostic with location in original source:
 // RUN: not %clang_cc1 -include-pch %t.h.pch -emit-obj -o %t.o %s 2> %t.stderr
 // RUN: grep 'could not find file' %t.stderr
 
+// Oftentimes on Windows there are open handles, and deletion will fail.
+// REQUIRES: can-remove-opened-file
+
 void qq(S*) {}
 
 #ifdef REDECL


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

Re: [PATCH] D17214: Stop using "template" when printing qualtype names

[Sterling Augustine via cfe-commits]

saugustine requested a review of this revision.
saugustine added a comment.

Would you mind reviewing this, and checking it in if you find it acceptable?


http://reviews.llvm.org/D17214



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

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

[David Blaikie via cfe-commits]

Since this is just a wording change, presumably the diagnostic is already
tested in an existing file - perhaps you could exetendi that test to cover
this functionality (we try not to add new test files too much - better to
test functionality once/in one place as much as possible (both for ease of
reading/updating/understanding the test suite, and for speed of execution
(process startup time makes up a significant portion of the test execution
time, so reducing the total number of test files/commands is useful there)))

On Sat, Feb 13, 2016 at 8:32 PM, Ryan Yee via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> ryee88 updated this revision to Diff 47925.
> ryee88 added a comment.
>
> Sorry-- re-uploading the diff. Didn't notice I dropped the code changes.
>
>
> http://reviews.llvm.org/D16949
>
> Files:
>   include/clang/Basic/DiagnosticSemaKinds.td
>   lib/Sema/SemaOverload.cpp
>   test/Parser/overloaded-pointer-vs-reference-hint.cpp
>
> Index: test/Parser/overloaded-pointer-vs-reference-hint.cpp
> ===
> --- /dev/null
> +++ test/Parser/overloaded-pointer-vs-reference-hint.cpp
> @@ -0,0 +1,15 @@
> +// RUN: %clang_cc1 %s -fsyntax-only -verify
> +
> +class A;
> +
> +void f0(A *a); // expected-note {{candidate function not viable: cannot
> convert argument of incomplete type 'A' to 'A *' for 1st argument; take the
> address of the argument with &}}
> +void f1(A &a) {
> +  f0(a); // expected-error {{no matching function for call to 'f0'}}
> +}
> +
> +void f2(A &a); // expected-note {{candidate function not viable: cannot
> convert argument of incomplete type 'A *' to 'A &' for 1st argument;
> dereference the argument with *}}
> +void f3(A *a) {
> +  f2(a); // expected-error {{no matching function for call to 'f2'}}
> +}
> +
> +
> Index: lib/Sema/SemaOverload.cpp
> ===
> --- lib/Sema/SemaOverload.cpp
> +++ lib/Sema/SemaOverload.cpp
> @@ -9104,10 +9104,13 @@
>if (const PointerType *PTy = TempFromTy->getAs())
>  TempFromTy = PTy->getPointeeType();
>if (TempFromTy->isIncompleteType()) {
> +// Emit the generic diagnostic and, optionally, add the hints to it.
>  S.Diag(Fn->getLocation(),
> diag::note_ovl_candidate_bad_conv_incomplete)
><< (unsigned) FnKind << FnDesc
><< (FromExpr ? FromExpr->getSourceRange() : SourceRange())
> -  << FromTy << ToTy << (unsigned) isObjectArgument << I+1;
> +  << FromTy << ToTy << (unsigned) isObjectArgument << I+1
> +  << (unsigned) (Cand->Fix.Kind);
> +
>  MaybeEmitInheritedConstructorNote(S, Fn);
>  return;
>}
> Index: include/clang/Basic/DiagnosticSemaKinds.td
> ===
> --- include/clang/Basic/DiagnosticSemaKinds.td
> +++ include/clang/Basic/DiagnosticSemaKinds.td
> @@ -3189,7 +3189,12 @@
>  "function (the implicit move assignment operator)|"
>  "constructor (inherited)}0%1 "
>  "not viable: cannot convert argument of incomplete type "
> -"%diff{$ to $|to parameter type}2,3">;
> +"%diff{$ to $|to parameter type}2,3 for "
> +"%select{%ordinal5 argument|object argument}4"
> +"%select{|; dereference the argument with *|"
> +"; take the address of the argument with &|"
> +"; remove *|"
> +"; remove &}6">;
>  def note_ovl_candidate_bad_list_argument : Note<"candidate "
>  "%select{function|function|constructor|"
>  "function |function |constructor |"
>
>
>
> ___
> 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] D17034: Add an AST matcher for null pointers

[Aaron Ballman via cfe-commits]

aaron.ballman marked an inline comment as done.


Comment at: include/clang/ASTMatchers/ASTMatchers.h:4838
@@ +4837,3 @@
+  gnuNullExpr(), cxxNullPtrLiteralExpr(),
+  expr(integerLiteral(equals(0), 
hasParent(expr(hasType(pointerType()));
+}

sbenza wrote:
> is this expr() necessary?
Yes, without it I get errors about not having a matching overload for 
hasParent().


http://reviews.llvm.org/D17034



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

Re: [PATCH] D17034: Add an AST matcher for null pointers

[Samuel Benzaquen via cfe-commits]

sbenza added inline comments.


Comment at: include/clang/ASTMatchers/ASTMatchers.h:4838
@@ +4837,3 @@
+  gnuNullExpr(), cxxNullPtrLiteralExpr(),
+  expr(integerLiteral(equals(0), 
hasParent(expr(hasType(pointerType()));
+}

aaron.ballman wrote:
> sbenza wrote:
> > is this expr() necessary?
> Yes, without it I get errors about not having a matching overload for 
> hasParent().
Sorry, I meant the one around integerLiteral().


http://reviews.llvm.org/D17034



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

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

[Hans Wennborg via cfe-commits]

Do I understand correctly that there are still issues here's that are not fixed?

(I'm trying to understand if there is something here to merge for 3.8,
but I'm having trouble following these commits.)

On Tue, Feb 16, 2016 at 6:44 AM, Vasileios Kalintiris
 wrote:
> I changed the type of message from fatal_error to warning in r260961. While
> the test for atomics works fine in most cases, it fails because we include
>  and , and the user's host compiler might not provide them
> during a bootstrap (see PR26631 and PR26622).
>
> Does anyone have any idea how to tackle this problem? As suggested by the
> bug reports, we could include the headers provided by libc++. However, I'm
> not sure whether we are supposed to do that during configuration time.
>
> - Vasileios
>
>
> 
> From: Eric Fiselier [e...@efcs.ca]
> Sent: 11 February 2016 16:08
> To: Daniel Sanders
> Cc: Vasileios Kalintiris; h...@chromium.org; mclow.li...@gmail.com;
> cfe-commits@lists.llvm.org
> Subject: Re: [libcxx] r260235 - Introduce a cmake module to figure out
> whether we need to link with libatomic.
>
>>  we need to rename HAVE_CXX_ATOMICS_WITH_LIB to something like
>> LIBCXX_HAVE_CXX_ATOMICS_WITH_LIB.
>
> Fixed in r260531.
>
> I think we will eventually want to merge the following commits, assuming
> they don't regress the build, especially with the -gcc-toolchain option.
>
> - [libcxx] r260515 - Re-commit "Introduce a cmake module to figure out
> whether we need to link with libatomic."
> - [libcxx] r260524 - Fix r260515 - Correct typos in CMake changes
> - [libcxx] r260531 - Rename CheckLibcxxAtomic.cmake variable result names so
> they don't clash with LLVM
>
> @Marshall Any objections?
>
> On Thu, Feb 11, 2016 at 2:18 AM, Daniel Sanders via cfe-commits
>  wrote:
>>
>> Hi,
>>
>> In my latests rc2+patches build I've also found that we need to rename
>> HAVE_CXX_ATOMICS_WITH_LIB to something like
>> LIBCXX_HAVE_CXX_ATOMICS_WITH_LIB. It's currently re-using the result of
>> LLVM's check which doesn't include 64-bit atomics.
>> 
>> From: Vasileios Kalintiris
>> Sent: 09 February 2016 23:50
>> To: h...@chromium.org
>> Cc: cfe-commits@lists.llvm.org; Daniel Sanders; mclow.li...@gmail.com
>> Subject: RE: [libcxx] r260235 - Introduce a cmake module to figure out
>> whether we need to link with libatomic.
>>
>> Hi Hans,
>>
>> Please wait before merging this as it breaks LLVM bootstraps when using
>> the -gcc-toolchain option and the system's default gcc installation does not
>> provide libatomic. We have to check LIBCXX_GCC_TOOLCHAIN in our test. I'll
>> create a patch tomorrow and I'll let you know when it's okay to merge them.
>> In the meantime, I reverted it in r260323.
>>
>> - Vasileios
>> 
>> From: Vasileios Kalintiris
>> Sent: 09 February 2016 18:56
>> To: h...@chromium.org
>> Cc: cfe-commits@lists.llvm.org; Daniel Sanders; mclow.li...@gmail.com
>> Subject: RE: [libcxx] r260235 - Introduce a cmake module to figure out
>> whether we need to link with libatomic.
>>
>> Hi Hans,
>>
>> Can we merge this on the 3.8 release branch? It fixes libcxx builds on
>> MIPS by linking with libatomic when needed. Also, all the x86_64 and ARM
>> buildbots for libcxx look good.
>>
>> Thanks,
>> Vasileios
>>
>> 
>> From: cfe-commits [cfe-commits-boun...@lists.llvm.org] on behalf of
>> Vasileios Kalintiris via cfe-commits [cfe-commits@lists.llvm.org]
>> Sent: 09 February 2016 17:00
>> To: cfe-commits@lists.llvm.org
>> Subject: [libcxx] r260235 - Introduce a cmake module to figure out whether
>> we need to link with libatomic.
>>
>> Author: vkalintiris
>> Date: Tue Feb  9 11:00:38 2016
>> New Revision: 260235
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=260235&view=rev
>> Log:
>> Introduce a cmake module to figure out whether we need to link with
>> libatomic.
>>
>> Summary:
>> This fixes the tests under std/atomics for 32-bit MIPS CPUs where the
>> 8-byte atomic operations call into the libatomic library.
>>
>> Reviewers: dsanders, mclow.lists, EricWF, jroelofs, joerg
>>
>> Subscribers: cfe-commits
>>
>> Differential Revision: http://reviews.llvm.org/D16613
>>
>> Added:
>> libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake
>> Modified:
>> libcxx/trunk/cmake/config-ix.cmake
>> libcxx/trunk/lib/CMakeLists.txt
>> libcxx/trunk/test/CMakeLists.txt
>> libcxx/trunk/test/libcxx/test/target_info.py
>> libcxx/trunk/test/lit.site.cfg.in
>>
>> Added: libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake
>> URL:
>> http://llvm.org/viewvc/llvm-project/libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake?rev=260235&view=auto
>>
>> ==
>> --- libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake (added)
>> +++ libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake Tue Feb  9 11:00:38
>> 2016
>> @@ -0,0 +1,38 @@
>> +INCLUDE(CheckCXXSo

Re: r260370 - Fix PR26543: add a check for definition in CXXRecordDecl.

[Hans Wennborg via cfe-commits]

On Wed, Feb 10, 2016 at 2:50 AM, Alexey Bataev via cfe-commits
 wrote:
> Author: abataev
> Date: Wed Feb 10 04:50:12 2016
> New Revision: 260370
>
> URL: http://llvm.org/viewvc/llvm-project?rev=260370&view=rev
> Log:
> Fix PR26543: add a check for definition in CXXRecordDecl.
>
> Modified:
> cfe/trunk/lib/Sema/SemaOpenMP.cpp
> cfe/trunk/test/OpenMP/parallel_messages.cpp

Merged to 3.8 in r261002. As requested on
https://llvm.org/bugs/show_bug.cgi?id=26059#c20

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

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

[Hans Wennborg via cfe-commits]

Or is this comment on PR26059 all that needs to be done for 3.8?

"Bug 26369, which has been fixed with r260961, requires the following
commits to get merged on the release branch:

- [libcxx] r260515 - Re-commit "Introduce a cmake module to figure out
whether we need to link with libatomic."
- [libcxx] r260524 - Fix r260515 - Correct typos in CMake changes
- [libcxx] r260531 - Rename CheckLibcxxAtomic.cmake variable result
names so they don't clash with LLVM
- [libcxx] r260961 - Issue a warning instead of fatal errors when
checks for libatomic fail."

Thanks,
Hans

On Tue, Feb 16, 2016 at 11:47 AM, Hans Wennborg  wrote:
> Do I understand correctly that there are still issues here's that are not 
> fixed?
>
> (I'm trying to understand if there is something here to merge for 3.8,
> but I'm having trouble following these commits.)
>
> On Tue, Feb 16, 2016 at 6:44 AM, Vasileios Kalintiris
>  wrote:
>> I changed the type of message from fatal_error to warning in r260961. While
>> the test for atomics works fine in most cases, it fails because we include
>>  and , and the user's host compiler might not provide them
>> during a bootstrap (see PR26631 and PR26622).
>>
>> Does anyone have any idea how to tackle this problem? As suggested by the
>> bug reports, we could include the headers provided by libc++. However, I'm
>> not sure whether we are supposed to do that during configuration time.
>>
>> - Vasileios
>>
>>
>> 
>> From: Eric Fiselier [e...@efcs.ca]
>> Sent: 11 February 2016 16:08
>> To: Daniel Sanders
>> Cc: Vasileios Kalintiris; h...@chromium.org; mclow.li...@gmail.com;
>> cfe-commits@lists.llvm.org
>> Subject: Re: [libcxx] r260235 - Introduce a cmake module to figure out
>> whether we need to link with libatomic.
>>
>>>  we need to rename HAVE_CXX_ATOMICS_WITH_LIB to something like
>>> LIBCXX_HAVE_CXX_ATOMICS_WITH_LIB.
>>
>> Fixed in r260531.
>>
>> I think we will eventually want to merge the following commits, assuming
>> they don't regress the build, especially with the -gcc-toolchain option.
>>
>> - [libcxx] r260515 - Re-commit "Introduce a cmake module to figure out
>> whether we need to link with libatomic."
>> - [libcxx] r260524 - Fix r260515 - Correct typos in CMake changes
>> - [libcxx] r260531 - Rename CheckLibcxxAtomic.cmake variable result names so
>> they don't clash with LLVM
>>
>> @Marshall Any objections?
>>
>> On Thu, Feb 11, 2016 at 2:18 AM, Daniel Sanders via cfe-commits
>>  wrote:
>>>
>>> Hi,
>>>
>>> In my latests rc2+patches build I've also found that we need to rename
>>> HAVE_CXX_ATOMICS_WITH_LIB to something like
>>> LIBCXX_HAVE_CXX_ATOMICS_WITH_LIB. It's currently re-using the result of
>>> LLVM's check which doesn't include 64-bit atomics.
>>> 
>>> From: Vasileios Kalintiris
>>> Sent: 09 February 2016 23:50
>>> To: h...@chromium.org
>>> Cc: cfe-commits@lists.llvm.org; Daniel Sanders; mclow.li...@gmail.com
>>> Subject: RE: [libcxx] r260235 - Introduce a cmake module to figure out
>>> whether we need to link with libatomic.
>>>
>>> Hi Hans,
>>>
>>> Please wait before merging this as it breaks LLVM bootstraps when using
>>> the -gcc-toolchain option and the system's default gcc installation does not
>>> provide libatomic. We have to check LIBCXX_GCC_TOOLCHAIN in our test. I'll
>>> create a patch tomorrow and I'll let you know when it's okay to merge them.
>>> In the meantime, I reverted it in r260323.
>>>
>>> - Vasileios
>>> 
>>> From: Vasileios Kalintiris
>>> Sent: 09 February 2016 18:56
>>> To: h...@chromium.org
>>> Cc: cfe-commits@lists.llvm.org; Daniel Sanders; mclow.li...@gmail.com
>>> Subject: RE: [libcxx] r260235 - Introduce a cmake module to figure out
>>> whether we need to link with libatomic.
>>>
>>> Hi Hans,
>>>
>>> Can we merge this on the 3.8 release branch? It fixes libcxx builds on
>>> MIPS by linking with libatomic when needed. Also, all the x86_64 and ARM
>>> buildbots for libcxx look good.
>>>
>>> Thanks,
>>> Vasileios
>>>
>>> 
>>> From: cfe-commits [cfe-commits-boun...@lists.llvm.org] on behalf of
>>> Vasileios Kalintiris via cfe-commits [cfe-commits@lists.llvm.org]
>>> Sent: 09 February 2016 17:00
>>> To: cfe-commits@lists.llvm.org
>>> Subject: [libcxx] r260235 - Introduce a cmake module to figure out whether
>>> we need to link with libatomic.
>>>
>>> Author: vkalintiris
>>> Date: Tue Feb  9 11:00:38 2016
>>> New Revision: 260235
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=260235&view=rev
>>> Log:
>>> Introduce a cmake module to figure out whether we need to link with
>>> libatomic.
>>>
>>> Summary:
>>> This fixes the tests under std/atomics for 32-bit MIPS CPUs where the
>>> 8-byte atomic operations call into the libatomic library.
>>>
>>> Reviewers: dsanders, mclow.lists, EricWF, jroelofs, joerg
>>>
>>> Subscribers: cfe-commits
>>>
>>> Differential Revision: http://reviews.llvm.org/D16613
>>>
>>> Ad

Re: [PATCH] D17034: Add an AST matcher for null pointers

[Aaron Ballman via cfe-commits]

aaron.ballman updated this revision to Diff 48092.
aaron.ballman marked an inline comment as done.
aaron.ballman added a comment.

Removed an unnecessary expr() matcher.


http://reviews.llvm.org/D17034

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
@@ -5348,5 +5348,15 @@
   )));
 }
 
+TEST(NullPointerConstants, Basic) {
+  EXPECT_TRUE(matches("#define NULL ((void *)0)\n"
+  "void *v1 = NULL;", expr(nullPointerConstant(;
+  EXPECT_TRUE(matches("void *v2 = nullptr;", expr(nullPointerConstant(;
+  EXPECT_TRUE(matches("void *v3 = __null;", expr(nullPointerConstant(;
+  EXPECT_TRUE(matches("char *cp = (char *)0;", expr(nullPointerConstant(;
+  EXPECT_TRUE(matches("int *ip = 0;", expr(nullPointerConstant(;
+  EXPECT_TRUE(notMatches("int i = 0", expr(nullPointerConstant(;
+}
+
 } // end namespace ast_matchers
 } // end namespace clang
Index: lib/ASTMatchers/Dynamic/Registry.cpp
===
--- lib/ASTMatchers/Dynamic/Registry.cpp
+++ lib/ASTMatchers/Dynamic/Registry.cpp
@@ -326,6 +326,7 @@
   REGISTER_MATCHER(namesType);
   REGISTER_MATCHER(nestedNameSpecifier);
   REGISTER_MATCHER(nestedNameSpecifierLoc);
+  REGISTER_MATCHER(nullPointerConstant);
   REGISTER_MATCHER(nullStmt);
   REGISTER_MATCHER(numSelectorArgs);
   REGISTER_MATCHER(ofClass);
Index: include/clang/ASTMatchers/ASTMatchers.h
===
--- include/clang/ASTMatchers/ASTMatchers.h
+++ include/clang/ASTMatchers/ASTMatchers.h
@@ -4816,6 +4816,27 @@
   Stmt,
   CUDAKernelCallExpr> cudaKernelCallExpr;
 
+
+/// \brief Matches expressions that resolve to a null pointer constant, such as
+/// GNU's __null, C++11's nullptr, or C's NULL macro.
+///
+/// Given:
+/// \code
+///   void *v1 = NULL;
+///   void *v2 = nullptr;
+///   void *v3 = __null; // GNU extension
+///   char *cp = (char *)0;
+///   int *ip = 0;
+///   int i = 0;
+/// \endcode
+/// expr(nullPointerConstant())
+///   matches the initializer for v1, v2, v3, cp, and ip. Does not match the
+///   initializer for i.
+AST_MATCHER_FUNCTION(internal::Matcher, nullPointerConstant) {
+  return anyOf(
+  gnuNullExpr(), cxxNullPtrLiteralExpr(),
+  integerLiteral(equals(0), hasParent(expr(hasType(pointerType());
+}
 } // end namespace ast_matchers
 } // end namespace clang
 
Index: docs/LibASTMatchersReference.html
===
--- docs/LibASTMatchersReference.html
+++ docs/LibASTMatchersReference.html
@@ -2176,6 +2176,23 @@
 
 
 
+MatcherExpr>nullPointerConstant
+Matches 
expressions that resolve to a null pointer constant, such as
+GNU's __null, C++11's nullptr, or C's NULL macro.
+
+Given:
+  void *v1 = NULL;
+  void *v2 = nullptr;
+  void *v3 = __null; GNU extension
+  char *cp = (char *)0;
+  int *ip = 0;
+  int i = 0;
+expr(nullPointerConstant())
+  matches the initializer for v1, v2, v3, cp, and ip. Does not match the
+  initializer for i.
+
+
+
 MatcherFloatingLiteral>equalsValueT  Value
 Matches literals that are 
equal to the given value.
 


Index: unittests/ASTMatchers/ASTMatchersTest.cpp
===
--- unittests/ASTMatchers/ASTMatchersTest.cpp
+++ unittests/ASTMatchers/ASTMatchersTest.cpp
@@ -5348,5 +5348,15 @@
   )));
 }
 
+TEST(NullPointerConstants, Basic) {
+  EXPECT_TRUE(matches("#define NULL ((void *)0)\n"
+  "void *v1 = NULL;", expr(nullPointerConstant(;
+  EXPECT_TRUE(matches("void *v2 = nullptr;", expr(nullPointerConstant(;
+  EXPECT_TRUE(matches("void *v3 = __null;", expr(nullPointerConstant(;
+  EXPECT_TRUE(matches("char *cp = (char *)0;", expr(nullPointerConstant(;
+  EXPECT_TRUE(matches("int *ip = 0;", expr(nullPointerConstant(;
+  EXPECT_TRUE(notMatches("int i = 0", expr(nullPointerConstant(;
+}
+
 } // end namespace ast_matchers
 } // end namespace clang
Index: lib/ASTMatchers/Dynamic/Registry.cpp
===
--- lib/ASTMatchers/Dynamic/Registry.cpp
+++ lib/ASTMatchers/Dynamic/Registry.cpp
@@ -326,6 +326,7 @@
   REGISTER_MATCHER(namesType);
   REGISTER_MATCHER(nestedNameSpecifier);
   REGISTER_MATCHER(nestedNameSpecifierLoc);
+  REGISTER_MATCHER(nullPointerConstant);
   REGISTER_MATCHER(nullStmt);
   REGISTER_MATCHER(numSelectorArgs);
   REGISTER_MATCHER(ofClass);
Index: include/clang/ASTMatchers/ASTMatchers.h
==

Re: [PATCH] D17034: Add an AST matcher for null pointers

[Aaron Ballman via cfe-commits]

aaron.ballman marked 2 inline comments as done.


Comment at: include/clang/ASTMatchers/ASTMatchers.h:4838
@@ +4837,3 @@
+  gnuNullExpr(), cxxNullPtrLiteralExpr(),
+  integerLiteral(equals(0), hasParent(expr(hasType(pointerType());
+}

Ah, good catch! No, that one was not required, I've removed it.


http://reviews.llvm.org/D17034



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

Re: r260851 - As reported in https://llvm.org/bugs/show_bug.cgi?id=25496, on FreeBSD,

[Dimitry Andric via cfe-commits]

On 16 Feb 2016, at 18:51, Hans Wennborg  wrote:
> 
> On Sun, Feb 14, 2016 at 8:14 AM, Dimitry Andric  wrote:
>> On 14 Feb 2016, at 17:08, Dimitry Andric via cfe-commits 
>>  wrote:
>>> 
>>> Author: dim
>>> Date: Sun Feb 14 10:08:20 2016
>>> New Revision: 260851
>>> 
>>> URL: http://llvm.org/viewvc/llvm-project?rev=260851&view=rev
>>> Log:
>>> As reported in https://llvm.org/bugs/show_bug.cgi?id=25496, on FreeBSD,
>>> C++ programs compiled for profiling (using `-pg`) should be linked with
>>> `-lc++_p` (or `-lstdc++_p`, depending on the `-stdlib=` setting), not
>>> with the regular C++ libraries.
>>> 
>>> Add a `FreeBSD::AddCXXStdlibLibArgs()` override to handle this, and add
>>> a test case for it.  While here, extend the test case for the proper
>>> passing of -lm and -lm_p.
>>> 
>>> Reviewers: compnerd, davide, dws, emaste
>>> Reviewed By: compnerd
>>> Differential Revision: http://reviews.llvm.org/D16264
>> 
>> Hi Hans,
>> 
>> I would like to merge this to the 3.8 branch.  This only affects FreeBSD.
> 
> I'm OK with that, go ahead (or let me know if you'd like me to merge it).

Thanks, merged in r261003.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Vasileios Kalintiris via cfe-commits]

Hi Hans,

> Or is this comment on PR26059 all that needs to be done for 3.8?

That's correct. I wrote that comment in order to clarify which bits we should 
merge in 3.8.

The latest commit:

- [libcxx] r260961 - Issue a warning instead of fatal errors when checks for 
libatomic fail."

makes sure that my changes don't break older configurations that used to work 
previously, by emitting a warning message instead of a fatal error.

I had to turn the error to warning because there are cases where the host 
compiler doesn't provide the  and  headers when bootstrapping 
llvm.

The correct solution would be to use the headers provided from libc++ itself. 
However, I wanted to take the safe route for the 3.8 branch and provide the 
elegant solution on the trunk after having the proper discussion with the 
libc++ devs.

Thanks,
Vasileios


From: hwennb...@google.com [hwennb...@google.com] on behalf of Hans Wennborg 
[h...@chromium.org]
Sent: 16 February 2016 19:53
To: Vasileios Kalintiris
Cc: Eric Fiselier; Daniel Sanders; mclow.li...@gmail.com; 
cfe-commits@lists.llvm.org
Subject: Re: [libcxx] r260235 - Introduce a cmake module to figure out whether 
we need to link with libatomic.

Or is this comment on PR26059 all that needs to be done for 3.8?

"Bug 26369, which has been fixed with r260961, requires the following
commits to get merged on the release branch:

- [libcxx] r260515 - Re-commit "Introduce a cmake module to figure out
whether we need to link with libatomic."
- [libcxx] r260524 - Fix r260515 - Correct typos in CMake changes
- [libcxx] r260531 - Rename CheckLibcxxAtomic.cmake variable result
names so they don't clash with LLVM
- [libcxx] r260961 - Issue a warning instead of fatal errors when
checks for libatomic fail."

Thanks,
Hans

On Tue, Feb 16, 2016 at 11:47 AM, Hans Wennborg  wrote:
> Do I understand correctly that there are still issues here's that are not 
> fixed?
>
> (I'm trying to understand if there is something here to merge for 3.8,
> but I'm having trouble following these commits.)
>
> On Tue, Feb 16, 2016 at 6:44 AM, Vasileios Kalintiris
>  wrote:
>> I changed the type of message from fatal_error to warning in r260961. While
>> the test for atomics works fine in most cases, it fails because we include
>>  and , and the user's host compiler might not provide them
>> during a bootstrap (see PR26631 and PR26622).
>>
>> Does anyone have any idea how to tackle this problem? As suggested by the
>> bug reports, we could include the headers provided by libc++. However, I'm
>> not sure whether we are supposed to do that during configuration time.
>>
>> - Vasileios
>>
>>
>> 
>> From: Eric Fiselier [e...@efcs.ca]
>> Sent: 11 February 2016 16:08
>> To: Daniel Sanders
>> Cc: Vasileios Kalintiris; h...@chromium.org; mclow.li...@gmail.com;
>> cfe-commits@lists.llvm.org
>> Subject: Re: [libcxx] r260235 - Introduce a cmake module to figure out
>> whether we need to link with libatomic.
>>
>>>  we need to rename HAVE_CXX_ATOMICS_WITH_LIB to something like
>>> LIBCXX_HAVE_CXX_ATOMICS_WITH_LIB.
>>
>> Fixed in r260531.
>>
>> I think we will eventually want to merge the following commits, assuming
>> they don't regress the build, especially with the -gcc-toolchain option.
>>
>> - [libcxx] r260515 - Re-commit "Introduce a cmake module to figure out
>> whether we need to link with libatomic."
>> - [libcxx] r260524 - Fix r260515 - Correct typos in CMake changes
>> - [libcxx] r260531 - Rename CheckLibcxxAtomic.cmake variable result names so
>> they don't clash with LLVM
>>
>> @Marshall Any objections?
>>
>> On Thu, Feb 11, 2016 at 2:18 AM, Daniel Sanders via cfe-commits
>>  wrote:
>>>
>>> Hi,
>>>
>>> In my latests rc2+patches build I've also found that we need to rename
>>> HAVE_CXX_ATOMICS_WITH_LIB to something like
>>> LIBCXX_HAVE_CXX_ATOMICS_WITH_LIB. It's currently re-using the result of
>>> LLVM's check which doesn't include 64-bit atomics.
>>> 
>>> From: Vasileios Kalintiris
>>> Sent: 09 February 2016 23:50
>>> To: h...@chromium.org
>>> Cc: cfe-commits@lists.llvm.org; Daniel Sanders; mclow.li...@gmail.com
>>> Subject: RE: [libcxx] r260235 - Introduce a cmake module to figure out
>>> whether we need to link with libatomic.
>>>
>>> Hi Hans,
>>>
>>> Please wait before merging this as it breaks LLVM bootstraps when using
>>> the -gcc-toolchain option and the system's default gcc installation does not
>>> provide libatomic. We have to check LIBCXX_GCC_TOOLCHAIN in our test. I'll
>>> create a patch tomorrow and I'll let you know when it's okay to merge them.
>>> In the meantime, I reverted it in r260323.
>>>
>>> - Vasileios
>>> 
>>> From: Vasileios Kalintiris
>>> Sent: 09 February 2016 18:56
>>> To: h...@chromium.org
>>> Cc: cfe-commits@lists.llvm.org; Daniel Sanders; mclow.li...@gmail.com
>>> Subject: RE: [libcxx] r260235 - Introduce a cmake module to figure o

Re: r258524 - Merge templated static member variables, fixes http://llvm.org/pr26179.

[Richard Smith via cfe-commits]

--- a/lib/Sema/SemaLookup.cpp
+++ b/lib/Sema/SemaLookup.cpp
@@ -419,6 +419,25 @@ static bool isPreferredLookupResult(Sema &S,
Sema::LookupNameKind Kind,
 }
   }

+  // VarDecl can have incomplete array types, prefer the one with more complete
+  // array type.
+  if (VarDecl *DVD = dyn_cast(DUnderlying)) {
+VarDecl *EVD = cast(EUnderlying);
+// Skip local VarDecls with incomplete array type.
+if ((!DVD->isLocalVarDecl() && DVD->hasExternalStorage()) ||
+(!EVD->isLocalVarDecl() && EVD->hasExternalStorage())) {

Why do you need this special case?

+
+  ASTContext &C = S.getASTContext();
+
+  if (const ArrayType *DVDTy = C.getAsArrayType(DVD->getType())) {
+const ArrayType *EVDTy = C.getAsArrayType(EVD->getType());
+// Prefer the decl with more complete type if visible.
+return !DVDTy->isIncompleteArrayType() &&
EVDTy->isIncompleteArrayType()

Checking for an array type here seems unnecessary -- it'd be simpler to
check EVD->getType()->isIncompleteType() &&
!DVD->getType()->isIncompleteType().

+ && S.isVisible(D);

This seems like a very subtle case: we're performing redeclaration lookup
for a variable declaration X, and we find two results D and E. D is hidden
but has a complete type. E is visible but has an incomplete type. If X has
no array bound, it should not inherit one from D. But if it does have an
array bound, and that bound differs from E's bound, we should diagnose the
mismatch.

Please add another test to the end of merge-incomplete-array-vars.cpp to
check this is working:

int c[2]; // expected-error {{different type: 'int [2]' vs 'int [1]'}}

That said, I think this test will fail if you reorder c1 and c2 in the
module map, but that's a pre-existing bug (see the last FIXME in
Sema::MergeVarDeclTypes).

+  }
+}
+  }


On Tue, Feb 16, 2016 at 11:12 AM, Vassil Vassilev 
wrote:

> ping...
>
> On 07/02/16 22:33, Vassil Vassilev wrote:
>
> Improve a comment.
> --Vassil
> On 07/02/16 20:48, Vassil Vassilev wrote:
>
> Would this patch be any better?
> --Vassil
> On 05/02/16 21:49, Richard Smith wrote:
>
> This belongs in ASTDeclReader::attachPreviousDecl[Impl]. That's where we
> propagate data that's supposed to be consistent across a redeclaration
> chain from earlier declarations to later ones.
>
> There's another wrinkle here: we should only be propagating the type from
> a previous declaration that's declared in the same scope (in particular, we
> should skip over declarations declared as local extern declarations within
> a function). This may in some cases require walking backwards along the
> redeclaration chain to find the previous declaration that was not a local
> extern declaration. That'd be observable in a case like this:
>
> modulemap:
> module A { module A1 { header "a1.h" } module A2 { header "a2.h" } }
> module B { header "b.h" }
>
> a1.h:
> int a[];
>
> b.h:
> void g(int(*)[], int);
> void g(int(*)[1], int) = delete;
> template void f(T t) {
>   extern int a[];
>   g(&a, t);
> }
>
> a2.h:
> int a[1];
>
> x.cc:
> #include "a1.h"
> #include "b.h"
> void h() { f(0); } // should not produce an error; type of 'a' within 'f'
> should not have been updated
>
> That example actually reveals another problem: we really don't want the
> completed type to be visible unless there is a visible declaration with the
> completed type. That suggests that propagating the type across the
> redeclaration chain may be the wrong approach, and we should instead handle
> this by changing isPreferredLookupResult (in SemaLookup.cpp) to prefer a
> VarDecl with a complete type over one with an incomplete type.
>
> On Fri, Feb 5, 2016 at 12:27 PM, Vassil Vassilev <
> v.g.vassi...@gmail.com> wrote:
>
>> I am not sure where else to put this logic if not in isSameEntity...
>> Could you point me to a better place?
>> --Vassil
>>
>> On 05/02/16 19:56, Richard Smith wrote:
>>
>> On Fri, Feb 5, 2016 at 7:04 AM, Vassil Vassilev <
>> v.g.vassi...@gmail.com> wrote:
>>
>>> Good point. Do you have in mind calling 'clang::Sema::MergeVarDeclTypes'
>>> or we to just "duplicate" the logic in
>>> clang::ASTDeclReader::mergeRedeclarable?
>>>
>>
>> It's not safe to call into Sema while we're in a partially-deserialized
>> state. We know the only interesting case here is complete versus incomplete
>> array types, so we don't need anything like the complexity of
>> MergeVarDeclTypes -- something as easy as "if (new type is incomplete and
>> old type is not) set new type to old type" should work.
>>
>>
>>> On 05/02/16 02:50, Richard Smith via cfe-commits wrote:
>>>
>>> I suspect we'll need to do a little more than this: when we rebuild the
>>> redeclaration chain, we should probably propagate the complete type to
>>> later redeclarations in the same scope. Otherwise, if we import a module
>>> that has a complete type and one that has an incomplete type, the
>>> declaration found by name lookup might be the one with the incomplete type,
>>> possibly resultin

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

[Richard Smith via cfe-commits]

On Tue, Feb 16, 2016 at 10:24 AM, H.J. Lu  wrote:
>
> On Fri, Feb 12, 2016 at 11:39 AM, H.J. Lu  wrote:
> > On Fri, Feb 12, 2016 at 6:58 AM, Matthijs van Duin
> >  wrote:
> >> On 11 February 2016 at 16:31, H.J. Lu  wrote:
> >>> struct A {
> >>> static void foo (void) ();
> >>> static int xxx;
> >>> };
> >>
> >> What about it? It's an empty struct.  (And it declares a function and
> >> a variable in the namespace of A, which however do not have any
> >> relevant impact here.)
> >>
> >
> > Thanks for all the feedbacks.  Here is the new proposal:
> >
> > 1. "empty type".  An empty type is a trivially-copyable aggregate
> > occupying zero bytes (excluding any padding).
> > 2. No memory slot nor register should be used to pass or return an object
> > of empty type.
> >
> > Footnote: Array of empty type can only passed by reference in C/C++.
> >
>
> I updated intel386, x86-64 and IA MCU psABIs:
>
> https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI
>
> to specify:
>
> Empty type is defined as a trivially-copyable aggregate occupying zero bytes
> (excluding any padding).

I think this is now extremely unclear. Does an empty struct in C++
occupy zero bytes? sizeof applied to it will produce at least 1.

> No memory slot nor register should be used to pass or
> return an object object of empty type.
>
> with footnote: Array of empty type can only passed by reference in C and C++.
>
> Any comments?
>
> Thanks.
>
>
> --
> H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[H.J. Lu via cfe-commits]

On Tue, Feb 16, 2016 at 12:22 PM, Richard Smith  wrote:
> On Tue, Feb 16, 2016 at 10:24 AM, H.J. Lu  wrote:
>>
>> On Fri, Feb 12, 2016 at 11:39 AM, H.J. Lu  wrote:
>> > On Fri, Feb 12, 2016 at 6:58 AM, Matthijs van Duin
>> >  wrote:
>> >> On 11 February 2016 at 16:31, H.J. Lu  wrote:
>> >>> struct A {
>> >>> static void foo (void) ();
>> >>> static int xxx;
>> >>> };
>> >>
>> >> What about it? It's an empty struct.  (And it declares a function and
>> >> a variable in the namespace of A, which however do not have any
>> >> relevant impact here.)
>> >>
>> >
>> > Thanks for all the feedbacks.  Here is the new proposal:
>> >
>> > 1. "empty type".  An empty type is a trivially-copyable aggregate
>> > occupying zero bytes (excluding any padding).
>> > 2. No memory slot nor register should be used to pass or return an object
>> > of empty type.
>> >
>> > Footnote: Array of empty type can only passed by reference in C/C++.
>> >
>>
>> I updated intel386, x86-64 and IA MCU psABIs:
>>
>> https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI
>>
>> to specify:
>>
>> Empty type is defined as a trivially-copyable aggregate occupying zero bytes
>> (excluding any padding).
>
> I think this is now extremely unclear. Does an empty struct in C++
> occupy zero bytes? sizeof applied to it will produce at least 1.

Can it be considered as padding?

>> No memory slot nor register should be used to pass or
>> return an object object of empty type.
>>
>> with footnote: Array of empty type can only passed by reference in C and C++.
>>
>> Any comments?
>>
>> Thanks.
>>
>>
>> --
>> H.J.



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

r261005 - Stop using "template" when printing qualtype names

[Reid Kleckner via cfe-commits]

Author: rnk
Date: Tue Feb 16 14:34:27 2016
New Revision: 261005

URL: http://llvm.org/viewvc/llvm-project?rev=261005&view=rev
Log:
Stop using "template" when printing qualtype names

Summary:
The keyword "template" isn't necessary when
printing a fully-qualified qualtype name, and, in fact,
results in a syntax error if one tries to use it. So stop
printing it.

Reviewers: rsmith, rnk

Subscribers: rnk, klimek, cfe-commits

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

Modified:
cfe/trunk/lib/Tooling/Core/QualTypeNames.cpp
cfe/trunk/unittests/Tooling/QualTypeNamesTest.cpp

Modified: cfe/trunk/lib/Tooling/Core/QualTypeNames.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Tooling/Core/QualTypeNames.cpp?rev=261005&r1=261004&r2=261005&view=diff
==
--- cfe/trunk/lib/Tooling/Core/QualTypeNames.cpp (original)
+++ cfe/trunk/lib/Tooling/Core/QualTypeNames.cpp Tue Feb 16 14:34:27 2016
@@ -329,7 +329,8 @@ NestedNameSpecifier *createNestedNameSpe
 NestedNameSpecifier *createNestedNameSpecifier(
 const ASTContext &Ctx, const TypeDecl *TD, bool FullyQualify) {
   return NestedNameSpecifier::Create(Ctx, createOuterNNS(Ctx, TD, 
FullyQualify),
- true /*Template*/, TD->getTypeForDecl());
+ false /*No TemplateKeyword*/,
+ TD->getTypeForDecl());
 }
 
 /// \brief Return the fully qualified type, including fully-qualified

Modified: cfe/trunk/unittests/Tooling/QualTypeNamesTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Tooling/QualTypeNamesTest.cpp?rev=261005&r1=261004&r2=261005&view=diff
==
--- cfe/trunk/unittests/Tooling/QualTypeNamesTest.cpp (original)
+++ cfe/trunk/unittests/Tooling/QualTypeNamesTest.cpp Tue Feb 16 14:34:27 2016
@@ -85,7 +85,8 @@ TEST(QualTypeNameTest, getFullyQualified
   // Namespace alias
   Visitor.ExpectedQualTypeNames["CheckL"] = "A::B::C::MyInt";
   Visitor.ExpectedQualTypeNames["non_dependent_type_var"] =
-  "template Foo::non_dependent_type";
+  "Foo::non_dependent_type";
+  Visitor.ExpectedQualTypeNames["AnEnumVar"] = "EnumScopeClass::AnEnum";
   Visitor.runOver(
   "int CheckInt;\n"
   "namespace A {\n"
@@ -143,6 +144,11 @@ TEST(QualTypeNameTest, getFullyQualified
   "  var.dependent_type_var = 0;\n"
   "var.non_dependent_type_var = 0;\n"
   "}\n"
+  "class EnumScopeClass {\n"
+  "public:\n"
+  "  enum AnEnum { ZERO, ONE };\n"
+  "};\n"
+  "EnumScopeClass::AnEnum AnEnumVar;\n"
 );
 
   TypeNameVisitor Complex;


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

Re: [PATCH] D17214: Stop using "template" when printing qualtype names

[Reid Kleckner via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL261005: Stop using "template" when printing qualtype names 
(authored by rnk).

Changed prior to commit:
  http://reviews.llvm.org/D17214?vs=47854&id=48095#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D17214

Files:
  cfe/trunk/lib/Tooling/Core/QualTypeNames.cpp
  cfe/trunk/unittests/Tooling/QualTypeNamesTest.cpp

Index: cfe/trunk/lib/Tooling/Core/QualTypeNames.cpp
===
--- cfe/trunk/lib/Tooling/Core/QualTypeNames.cpp
+++ cfe/trunk/lib/Tooling/Core/QualTypeNames.cpp
@@ -329,7 +329,8 @@
 NestedNameSpecifier *createNestedNameSpecifier(
 const ASTContext &Ctx, const TypeDecl *TD, bool FullyQualify) {
   return NestedNameSpecifier::Create(Ctx, createOuterNNS(Ctx, TD, 
FullyQualify),
- true /*Template*/, TD->getTypeForDecl());
+ false /*No TemplateKeyword*/,
+ TD->getTypeForDecl());
 }
 
 /// \brief Return the fully qualified type, including fully-qualified
Index: cfe/trunk/unittests/Tooling/QualTypeNamesTest.cpp
===
--- cfe/trunk/unittests/Tooling/QualTypeNamesTest.cpp
+++ cfe/trunk/unittests/Tooling/QualTypeNamesTest.cpp
@@ -85,7 +85,8 @@
   // Namespace alias
   Visitor.ExpectedQualTypeNames["CheckL"] = "A::B::C::MyInt";
   Visitor.ExpectedQualTypeNames["non_dependent_type_var"] =
-  "template Foo::non_dependent_type";
+  "Foo::non_dependent_type";
+  Visitor.ExpectedQualTypeNames["AnEnumVar"] = "EnumScopeClass::AnEnum";
   Visitor.runOver(
   "int CheckInt;\n"
   "namespace A {\n"
@@ -143,6 +144,11 @@
   "  var.dependent_type_var = 0;\n"
   "var.non_dependent_type_var = 0;\n"
   "}\n"
+  "class EnumScopeClass {\n"
+  "public:\n"
+  "  enum AnEnum { ZERO, ONE };\n"
+  "};\n"
+  "EnumScopeClass::AnEnum AnEnumVar;\n"
 );
 
   TypeNameVisitor Complex;


Index: cfe/trunk/lib/Tooling/Core/QualTypeNames.cpp
===
--- cfe/trunk/lib/Tooling/Core/QualTypeNames.cpp
+++ cfe/trunk/lib/Tooling/Core/QualTypeNames.cpp
@@ -329,7 +329,8 @@
 NestedNameSpecifier *createNestedNameSpecifier(
 const ASTContext &Ctx, const TypeDecl *TD, bool FullyQualify) {
   return NestedNameSpecifier::Create(Ctx, createOuterNNS(Ctx, TD, FullyQualify),
- true /*Template*/, TD->getTypeForDecl());
+ false /*No TemplateKeyword*/,
+ TD->getTypeForDecl());
 }
 
 /// \brief Return the fully qualified type, including fully-qualified
Index: cfe/trunk/unittests/Tooling/QualTypeNamesTest.cpp
===
--- cfe/trunk/unittests/Tooling/QualTypeNamesTest.cpp
+++ cfe/trunk/unittests/Tooling/QualTypeNamesTest.cpp
@@ -85,7 +85,8 @@
   // Namespace alias
   Visitor.ExpectedQualTypeNames["CheckL"] = "A::B::C::MyInt";
   Visitor.ExpectedQualTypeNames["non_dependent_type_var"] =
-  "template Foo::non_dependent_type";
+  "Foo::non_dependent_type";
+  Visitor.ExpectedQualTypeNames["AnEnumVar"] = "EnumScopeClass::AnEnum";
   Visitor.runOver(
   "int CheckInt;\n"
   "namespace A {\n"
@@ -143,6 +144,11 @@
   "  var.dependent_type_var = 0;\n"
   "var.non_dependent_type_var = 0;\n"
   "}\n"
+  "class EnumScopeClass {\n"
+  "public:\n"
+  "  enum AnEnum { ZERO, ONE };\n"
+  "};\n"
+  "EnumScopeClass::AnEnum AnEnumVar;\n"
 );
 
   TypeNameVisitor Complex;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Carlo Bertolli via cfe-commits]

carlo.bertolli added a comment.

I have addressed some of the comments and restructured the code as requested.
Let me know about further comments.
Thanks for making this a better patch!


Repository:
  rL LLVM

http://reviews.llvm.org/D17170



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

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

[Carlo Bertolli via cfe-commits]

carlo.bertolli marked an inline comment as done.
carlo.bertolli added a comment.

I have addressed some of the comments and restructured the code as requested.
Let me know about further comments.
Thanks for making this a better patch!



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

Fixed - now everything related to the openmp library is encapsulated back into 
the CGOpenMPRuntime.cpp file.


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

No difference: deleted the latter.


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

If this is about missing comments for booleans - done.
Otherwise, please be specific about the bad formatting I did.


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

I will wait until a new patch related to this is submitted - if it has not 
already.


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

Made EmitOMPDistributeLoop public. What else needs to be public?


Repository:
  rL LLVM

http://reviews.llvm.org/D17170



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

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

[Richard Smith via cfe-commits]

On Tue, Feb 16, 2016 at 12:25 PM, H.J. Lu  wrote:
> On Tue, Feb 16, 2016 at 12:22 PM, Richard Smith  wrote:
>> On Tue, Feb 16, 2016 at 10:24 AM, H.J. Lu  wrote:
>>>
>>> On Fri, Feb 12, 2016 at 11:39 AM, H.J. Lu  wrote:
>>> > On Fri, Feb 12, 2016 at 6:58 AM, Matthijs van Duin
>>> >  wrote:
>>> >> On 11 February 2016 at 16:31, H.J. Lu  wrote:
>>> >>> struct A {
>>> >>> static void foo (void) ();
>>> >>> static int xxx;
>>> >>> };
>>> >>
>>> >> What about it? It's an empty struct.  (And it declares a function and
>>> >> a variable in the namespace of A, which however do not have any
>>> >> relevant impact here.)
>>> >>
>>> >
>>> > Thanks for all the feedbacks.  Here is the new proposal:
>>> >
>>> > 1. "empty type".  An empty type is a trivially-copyable aggregate
>>> > occupying zero bytes (excluding any padding).
>>> > 2. No memory slot nor register should be used to pass or return an object
>>> > of empty type.
>>> >
>>> > Footnote: Array of empty type can only passed by reference in C/C++.
>>> >
>>>
>>> I updated intel386, x86-64 and IA MCU psABIs:
>>>
>>> https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI
>>>
>>> to specify:
>>>
>>> Empty type is defined as a trivially-copyable aggregate occupying zero bytes
>>> (excluding any padding).
>>
>> I think this is now extremely unclear. Does an empty struct in C++
>> occupy zero bytes? sizeof applied to it will produce at least 1.
>
> Can it be considered as padding?

Perhaps, but I would contend that that's unclear in at least some
cases (when the class is used as the type of a member, ...). What
about this case:

  struct X { unsigned : 15; };

Is that empty or not? Do we have a formal definition somewhere of what
does, and does not, count as padding?

>>> No memory slot nor register should be used to pass or
>>> return an object object of empty type.
>>>
>>> with footnote: Array of empty type can only passed by reference in C and 
>>> C++.
>>>
>>> Any comments?
>>>
>>> Thanks.
>>>
>>>
>>> --
>>> H.J.
>
>
>
> --
> H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r261008 - Add a nullPointerConstant() AST matcher to handle variations of null pointer constants in one matcher.

[Aaron Ballman via cfe-commits]

Author: aaronballman
Date: Tue Feb 16 15:02:23 2016
New Revision: 261008

URL: http://llvm.org/viewvc/llvm-project?rev=261008&view=rev
Log:
Add a nullPointerConstant() AST matcher to handle variations of null pointer 
constants in one matcher.

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

Modified: cfe/trunk/docs/LibASTMatchersReference.html
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/LibASTMatchersReference.html?rev=261008&r1=261007&r2=261008&view=diff
==
--- cfe/trunk/docs/LibASTMatchersReference.html (original)
+++ cfe/trunk/docs/LibASTMatchersReference.html Tue Feb 16 15:02:23 2016
@@ -2176,6 +2176,23 @@ fieldDecl(isPublic())
 
 
 
+MatcherExpr>nullPointerConstant
+Matches 
expressions that resolve to a null pointer constant, such as
+GNU's __null, C++11's nullptr, or C's NULL macro.
+
+Given:
+  void *v1 = NULL;
+  void *v2 = nullptr;
+  void *v3 = __null; GNU extension
+  char *cp = (char *)0;
+  int *ip = 0;
+  int i = 0;
+expr(nullPointerConstant())
+  matches the initializer for v1, v2, v3, cp, and ip. Does not match the
+  initializer for i.
+
+
+
 MatcherFloatingLiteral>equalsValueT  Value
 Matches literals that are 
equal to the given value.
 

Modified: cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h?rev=261008&r1=261007&r2=261008&view=diff
==
--- cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h (original)
+++ cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h Tue Feb 16 15:02:23 2016
@@ -4816,6 +4816,27 @@ const internal::VariadicDynCastAllOfMatc
   Stmt,
   CUDAKernelCallExpr> cudaKernelCallExpr;
 
+
+/// \brief Matches expressions that resolve to a null pointer constant, such as
+/// GNU's __null, C++11's nullptr, or C's NULL macro.
+///
+/// Given:
+/// \code
+///   void *v1 = NULL;
+///   void *v2 = nullptr;
+///   void *v3 = __null; // GNU extension
+///   char *cp = (char *)0;
+///   int *ip = 0;
+///   int i = 0;
+/// \endcode
+/// expr(nullPointerConstant())
+///   matches the initializer for v1, v2, v3, cp, and ip. Does not match the
+///   initializer for i.
+AST_MATCHER_FUNCTION(internal::Matcher, nullPointerConstant) {
+  return anyOf(
+  gnuNullExpr(), cxxNullPtrLiteralExpr(),
+  integerLiteral(equals(0), hasParent(expr(hasType(pointerType());
+}
 } // end namespace ast_matchers
 } // end namespace clang
 

Modified: cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp?rev=261008&r1=261007&r2=261008&view=diff
==
--- cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp (original)
+++ cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp Tue Feb 16 15:02:23 2016
@@ -326,6 +326,7 @@ RegistryMaps::RegistryMaps() {
   REGISTER_MATCHER(namesType);
   REGISTER_MATCHER(nestedNameSpecifier);
   REGISTER_MATCHER(nestedNameSpecifierLoc);
+  REGISTER_MATCHER(nullPointerConstant);
   REGISTER_MATCHER(nullStmt);
   REGISTER_MATCHER(numSelectorArgs);
   REGISTER_MATCHER(ofClass);

Modified: cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.cpp?rev=261008&r1=261007&r2=261008&view=diff
==
--- cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.cpp (original)
+++ cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.cpp Tue Feb 16 15:02:23 2016
@@ -5348,5 +5348,15 @@ TEST(ObjCMessageExprMatcher, SimpleExprs
   )));
 }
 
+TEST(NullPointerConstants, Basic) {
+  EXPECT_TRUE(matches("#define NULL ((void *)0)\n"
+  "void *v1 = NULL;", expr(nullPointerConstant(;
+  EXPECT_TRUE(matches("void *v2 = nullptr;", expr(nullPointerConstant(;
+  EXPECT_TRUE(matches("void *v3 = __null;", expr(nullPointerConstant(;
+  EXPECT_TRUE(matches("char *cp = (char *)0;", expr(nullPointerConstant(;
+  EXPECT_TRUE(matches("int *ip = 0;", expr(nullPointerConstant(;
+  EXPECT_TRUE(notMatches("int i = 0", expr(nullPointerConstant(;
+}
+
 } // end namespace ast_matchers
 } // end namespace clang


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

Re: [PATCH] D17034: Add an AST matcher for null pointers

[Aaron Ballman via cfe-commits]

aaron.ballman closed this revision.
aaron.ballman marked an inline comment as done.
aaron.ballman added a comment.

Thanks for the review and suggestions! I've commit in r261008.


http://reviews.llvm.org/D17034



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

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

[Craig, Ben via cfe-commits]

FYI, this change and the LLVM version have each broken my libcxx 
builds.  I cross compile from Linux x64 to Hexagon, and my host machine 
doesn't have .  The LLVM change was particularly offensive 
because I wasn't planning on building LLVM itself.


I have since worked around the issue by making my cmake invocation longer.

I'm not sure what you can do for the LLVM check, but if you can use the 
libcxx headers directly for the  check, while still using all 
the custom flags and tools that I pass on the command line, then I 
should be able to remove the explicit setting of 
"LIBCXX_HAVE_CXX_ATOMICS_WITHOUT_LIB" in the future.


On 2/16/2016 2:09 PM, Vasileios Kalintiris via cfe-commits wrote:

Hi Hans,


Or is this comment on PR26059 all that needs to be done for 3.8?

That's correct. I wrote that comment in order to clarify which bits we should 
merge in 3.8.

The latest commit:

- [libcxx] r260961 - Issue a warning instead of fatal errors when checks for 
libatomic fail."

makes sure that my changes don't break older configurations that used to work 
previously, by emitting a warning message instead of a fatal error.

I had to turn the error to warning because there are cases where the host compiler doesn't 
provide the  and  headers when bootstrapping llvm.

The correct solution would be to use the headers provided from libc++ itself. 
However, I wanted to take the safe route for the 3.8 branch and provide the 
elegant solution on the trunk after having the proper discussion with the 
libc++ devs.

Thanks,
Vasileios


From: hwennb...@google.com [hwennb...@google.com] on behalf of Hans Wennborg 
[h...@chromium.org]
Sent: 16 February 2016 19:53
To: Vasileios Kalintiris
Cc: Eric Fiselier; Daniel Sanders; mclow.li...@gmail.com; 
cfe-commits@lists.llvm.org
Subject: Re: [libcxx] r260235 - Introduce a cmake module to figure out whether 
we need to link with libatomic.

Or is this comment on PR26059 all that needs to be done for 3.8?

"Bug 26369, which has been fixed with r260961, requires the following
commits to get merged on the release branch:

- [libcxx] r260515 - Re-commit "Introduce a cmake module to figure out
whether we need to link with libatomic."
- [libcxx] r260524 - Fix r260515 - Correct typos in CMake changes
- [libcxx] r260531 - Rename CheckLibcxxAtomic.cmake variable result
names so they don't clash with LLVM
- [libcxx] r260961 - Issue a warning instead of fatal errors when
checks for libatomic fail."

Thanks,
Hans

On Tue, Feb 16, 2016 at 11:47 AM, Hans Wennborg  wrote:

Do I understand correctly that there are still issues here's that are not fixed?

(I'm trying to understand if there is something here to merge for 3.8,
but I'm having trouble following these commits.)

On Tue, Feb 16, 2016 at 6:44 AM, Vasileios Kalintiris
 wrote:

I changed the type of message from fatal_error to warning in r260961. While
the test for atomics works fine in most cases, it fails because we include
 and , and the user's host compiler might not provide them
during a bootstrap (see PR26631 and PR26622).

Does anyone have any idea how to tackle this problem? As suggested by the
bug reports, we could include the headers provided by libc++. However, I'm
not sure whether we are supposed to do that during configuration time.

- Vasileios



From: Eric Fiselier [e...@efcs.ca]
Sent: 11 February 2016 16:08
To: Daniel Sanders
Cc: Vasileios Kalintiris; h...@chromium.org; mclow.li...@gmail.com;
cfe-commits@lists.llvm.org
Subject: Re: [libcxx] r260235 - Introduce a cmake module to figure out
whether we need to link with libatomic.


  we need to rename HAVE_CXX_ATOMICS_WITH_LIB to something like
LIBCXX_HAVE_CXX_ATOMICS_WITH_LIB.

Fixed in r260531.

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

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

@Marshall Any objections?

On Thu, Feb 11, 2016 at 2:18 AM, Daniel Sanders via cfe-commits
 wrote:

Hi,

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

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

Hi Hans,

Please wait before merging this as it breaks LLVM bootstraps when using
the -gcc-toolchain option and the system's default gcc installation does n

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

[H.J. Lu via cfe-commits]

On Tue, Feb 16, 2016 at 1:02 PM, Richard Smith  wrote:
> On Tue, Feb 16, 2016 at 12:25 PM, H.J. Lu  wrote:
>> On Tue, Feb 16, 2016 at 12:22 PM, Richard Smith  
>> wrote:
>>> On Tue, Feb 16, 2016 at 10:24 AM, H.J. Lu  wrote:

 On Fri, Feb 12, 2016 at 11:39 AM, H.J. Lu  wrote:
 > On Fri, Feb 12, 2016 at 6:58 AM, Matthijs van Duin
 >  wrote:
 >> On 11 February 2016 at 16:31, H.J. Lu  wrote:
 >>> struct A {
 >>> static void foo (void) ();
 >>> static int xxx;
 >>> };
 >>
 >> What about it? It's an empty struct.  (And it declares a function and
 >> a variable in the namespace of A, which however do not have any
 >> relevant impact here.)
 >>
 >
 > Thanks for all the feedbacks.  Here is the new proposal:
 >
 > 1. "empty type".  An empty type is a trivially-copyable aggregate
 > occupying zero bytes (excluding any padding).
 > 2. No memory slot nor register should be used to pass or return an object
 > of empty type.
 >
 > Footnote: Array of empty type can only passed by reference in C/C++.
 >

 I updated intel386, x86-64 and IA MCU psABIs:

 https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI

 to specify:

 Empty type is defined as a trivially-copyable aggregate occupying zero 
 bytes
 (excluding any padding).
>>>
>>> I think this is now extremely unclear. Does an empty struct in C++
>>> occupy zero bytes? sizeof applied to it will produce at least 1.
>>
>> Can it be considered as padding?
>
> Perhaps, but I would contend that that's unclear in at least some
> cases (when the class is used as the type of a member, ...). What
> about this case:
>
>   struct X { unsigned : 15; };
>
> Is that empty or not? Do we have a formal definition somewhere of what
> does, and does not, count as padding?

How about this?

Empty type is defined as a trivially-copyable aggregate occupying zero bytes
(excluding any padding or contributing zero bytes to the size of derived
classes in C++).

This will cover

struct dummy0
{
  void bar (void);
};
struct dummy1
{
  void foo (void);
};
struct dummy : dummy0, dummy1 { };

But not

struct dummy0
{
};
struct dummy1
{
  unsigned : 15;
};
struct dummy : dummy0, dummy1
{
};


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

r261009 - Missing semicolons are kind of important. Who knew?

[Aaron Ballman via cfe-commits]

Author: aaronballman
Date: Tue Feb 16 15:06:10 2016
New Revision: 261009

URL: http://llvm.org/viewvc/llvm-project?rev=261009&view=rev
Log:
Missing semicolons are kind of important. Who knew?

Modified:
cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.cpp

Modified: cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.cpp?rev=261009&r1=261008&r2=261009&view=diff
==
--- cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.cpp (original)
+++ cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.cpp Tue Feb 16 15:06:10 2016
@@ -5355,7 +5355,7 @@ TEST(NullPointerConstants, Basic) {
   EXPECT_TRUE(matches("void *v3 = __null;", expr(nullPointerConstant(;
   EXPECT_TRUE(matches("char *cp = (char *)0;", expr(nullPointerConstant(;
   EXPECT_TRUE(matches("int *ip = 0;", expr(nullPointerConstant(;
-  EXPECT_TRUE(notMatches("int i = 0", expr(nullPointerConstant(;
+  EXPECT_TRUE(notMatches("int i = 0;", expr(nullPointerConstant(;
 }
 
 } // end namespace ast_matchers


___
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

[David Blaikie via cfe-commits]

dblaikie added a comment.

Thanks - please commit when ready


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] D16376: clang-tidy check: misc-deprecated-special-member-functions

[David Blaikie via cfe-commits]

Is this anything more than the -Wdeprecated warning? (could we split out
the -Wdeprecated warning that deals with the deprecated implicit special
member generation, then just use that warning for this clang-tidy check?)

On Thu, Feb 11, 2016 at 3:16 PM, Jonathan B Coe via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> jbcoe retitled this revision from "clang-tidy check: rule-of-five" to
> "clang-tidy check: misc-deprecated-special-member-functions".
> jbcoe updated the summary for this revision.
> jbcoe set the repository for this revision to rL LLVM.
> jbcoe updated this revision to Diff 47735.
> jbcoe added a comment.
>
> This check now deals only with deprecated special member function
> generation, not move constructors or move assignment operators. I have
> renamed it and modified documentation accordingly.
>
> Code has been updated in line with review comments.
>
>
> Repository:
>   rL LLVM
>
> http://reviews.llvm.org/D16376
>
> Files:
>   clang-tidy/misc/CMakeLists.txt
>   clang-tidy/misc/DeprecatedSpecialMemberGenerationCheck.cpp
>   clang-tidy/misc/DeprecatedSpecialMemberGenerationCheck.h
>   clang-tidy/misc/MiscTidyModule.cpp
>   docs/clang-tidy/checks/list.rst
>   docs/clang-tidy/checks/misc-deprecated-special-member-generation.rst
>   test/clang-tidy/misc-deprecated-special-member-generation.cpp
>
>
> ___
> 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: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[Richard Smith via cfe-commits]

On Tue, Feb 16, 2016 at 1:10 PM, H.J. Lu  wrote:
> On Tue, Feb 16, 2016 at 1:02 PM, Richard Smith  wrote:
>> On Tue, Feb 16, 2016 at 12:25 PM, H.J. Lu  wrote:
>>> On Tue, Feb 16, 2016 at 12:22 PM, Richard Smith  
>>> wrote:
 On Tue, Feb 16, 2016 at 10:24 AM, H.J. Lu  wrote:
>
> On Fri, Feb 12, 2016 at 11:39 AM, H.J. Lu  wrote:
> > On Fri, Feb 12, 2016 at 6:58 AM, Matthijs van Duin
> >  wrote:
> >> On 11 February 2016 at 16:31, H.J. Lu  wrote:
> >>> struct A {
> >>> static void foo (void) ();
> >>> static int xxx;
> >>> };
> >>
> >> What about it? It's an empty struct.  (And it declares a function and
> >> a variable in the namespace of A, which however do not have any
> >> relevant impact here.)
> >>
> >
> > Thanks for all the feedbacks.  Here is the new proposal:
> >
> > 1. "empty type".  An empty type is a trivially-copyable aggregate
> > occupying zero bytes (excluding any padding).
> > 2. No memory slot nor register should be used to pass or return an 
> > object
> > of empty type.
> >
> > Footnote: Array of empty type can only passed by reference in C/C++.
> >
>
> I updated intel386, x86-64 and IA MCU psABIs:
>
> https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI
>
> to specify:
>
> Empty type is defined as a trivially-copyable aggregate occupying zero 
> bytes
> (excluding any padding).

 I think this is now extremely unclear. Does an empty struct in C++
 occupy zero bytes? sizeof applied to it will produce at least 1.
>>>
>>> Can it be considered as padding?
>>
>> Perhaps, but I would contend that that's unclear in at least some
>> cases (when the class is used as the type of a member, ...). What
>> about this case:
>>
>>   struct X { unsigned : 15; };
>>
>> Is that empty or not? Do we have a formal definition somewhere of what
>> does, and does not, count as padding?
>
> How about this?
>
> Empty type is defined as a trivially-copyable aggregate occupying zero bytes
> (excluding any padding or contributing zero bytes to the size of derived
> classes in C++).
>
> This will cover
>
> struct dummy0
> {
>   void bar (void);
> };
> struct dummy1
> {
>   void foo (void);
> };
> struct dummy : dummy0, dummy1 { };
>
> But not
>
> struct dummy0
> {
> };
> struct dummy1
> {
>   unsigned : 15;
> };
> struct dummy : dummy0, dummy1
> {
> };

Why not? That looks empty to me. The ABI will classify the
corresponding eightbyte as NO_CLASS, as it has no members, so it
should not be passed.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Carlo Bertolli via cfe-commits]

carlo.bertolli updated this revision to Diff 48100.
carlo.bertolli added a comment.

Address comments and rebase over new version of http://reviews.llvm.org/D17148.


Repository:
  rL LLVM

http://reviews.llvm.org/D17170

Files:
  include/clang/AST/StmtOpenMP.h
  lib/CodeGen/CGOpenMPRuntime.cpp
  lib/CodeGen/CGOpenMPRuntime.h
  lib/CodeGen/CGStmtOpenMP.cpp
  lib/CodeGen/CodeGenFunction.h
  lib/Serialization/ASTReaderStmt.cpp
  lib/Serialization/ASTWriterStmt.cpp
  test/OpenMP/distribute_codegen.cpp

Index: test/OpenMP/distribute_codegen.cpp
===
--- /dev/null
+++ test/OpenMP/distribute_codegen.cpp
@@ -0,0 +1,239 @@
+// Test host codegen.
+// RUN: %clang_cc1 -verify -fopenmp -x c++ -triple powerpc64le-unknown-unknown -omptargets=powerpc64le-ibm-linux-gnu -emit-llvm %s -o - | FileCheck %s --check-prefix CHECK --check-prefix CHECK-64
+// RUN: %clang_cc1 -fopenmp -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -omptargets=powerpc64le-ibm-linux-gnu -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp -x c++ -triple powerpc64le-unknown-unknown -omptargets=powerpc64le-ibm-linux-gnu -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck %s --check-prefix CHECK --check-prefix CHECK-64  --check-prefix HCHECK
+// RUN: %clang_cc1 -verify -fopenmp -x c++ -triple i386-unknown-unknown -omptargets=i386-pc-linux-gnu -emit-llvm %s -o - | FileCheck %s --check-prefix CHECK --check-prefix CHECK-32  --check-prefix HCHECK
+// RUN: %clang_cc1 -fopenmp -x c++ -std=c++11 -triple i386-unknown-unknown -omptargets=i386-pc-linux-gnu -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp -x c++ -triple i386-unknown-unknown -omptargets=i386-pc-linux-gnu -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck %s --check-prefix CHECK --check-prefix CHECK-32 --check-prefix HCHECK
+
+// Test target codegen - host bc file has to be created first. (no significant differences with host version of target region)
+// RUN: %clang_cc1 -verify -fopenmp -x c++ -triple powerpc64le-unknown-unknown -omptargets=powerpc64le-ibm-linux-gnu -emit-llvm-bc %s -o %t-ppc-host.bc
+// RUN: %clang_cc1 -verify -fopenmp -x c++ -triple powerpc64le-unknown-unknown -omptargets=powerpc64le-ibm-linux-gnu -emit-llvm %s -fopenmp-is-device -omp-host-ir-file-path %t-ppc-host.bc -o - | FileCheck %s
+// RUN: %clang_cc1 -fopenmp -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -omptargets=powerpc64le-ibm-linux-gnu -emit-pch -fopenmp-is-device -omp-host-ir-file-path %t-ppc-host.bc -o %t %s
+// RUN: %clang_cc1 -fopenmp -x c++ -triple powerpc64le-unknown-unknown -omptargets=powerpc64le-ibm-linux-gnu -std=c++11 -fopenmp-is-device -omp-host-ir-file-path %t-ppc-host.bc -include-pch %t -verify %s -emit-llvm -o - | FileCheck %s
+// RUN: %clang_cc1 -verify -fopenmp -x c++ -triple i386-unknown-unknown -omptargets=i386-pc-linux-gnu -emit-llvm-bc %s -o %t-x86-host.bc
+// RUN: %clang_cc1 -verify -fopenmp -x c++ -triple i386-unknown-unknown -omptargets=i386-pc-linux-gnu -emit-llvm %s -fopenmp-is-device -omp-host-ir-file-path %t-x86-host.bc -o - | FileCheck %s
+// RUN: %clang_cc1 -fopenmp -x c++ -std=c++11 -triple i386-unknown-unknown -omptargets=i386-pc-linux-gnu -emit-pch -fopenmp-is-device -omp-host-ir-file-path %t-x86-host.bc -o %t %s
+// RUN: %clang_cc1 -fopenmp -x c++ -triple i386-unknown-unknown -omptargets=i386-pc-linux-gnu -std=c++11 -fopenmp-is-device -omp-host-ir-file-path %t-x86-host.bc -include-pch %t -verify %s -emit-llvm -o - | FileCheck %s
+
+// expected-no-diagnostics
+#ifndef HEADER
+#define HEADER
+
+// CHECK-DAG: %ident_t = type { i32, i32, i32, i32, i8* }
+// CHECK-DAG: [[STR:@.+]] = private unnamed_addr constant [23 x i8] c";unknown;unknown;0;0;;\00"
+// CHECK-DAG: [[DEF_LOC_0:@.+]] = private unnamed_addr constant %ident_t { i32 0, i32 2, i32 0, i32 0, i8* getelementptr inbounds ([23 x i8], [23 x i8]* [[STR]], i32 0, i32 0) }
+
+// CHECK-LABEL: define {{.*void}} @{{.*}}without_schedule_clause{{.*}}(float* {{.+}}, float* {{.+}}, float* {{.+}}, float* {{.+}})
+void without_schedule_clause(float *a, float *b, float *c, float *d) {
+  #pragma omp target
+  #pragma omp teams
+  #pragma omp distribute
+  for (int i = 33; i < 3200; i += 7) {
+a[i] = b[i] * c[i] * d[i];
+  }
+}
+
+// CHECK: define {{.*}}void @.omp_outlined.(i32* noalias [[GBL_TIDP:%.+]], i32* noalias [[BND_TID:%.+]], float** dereferenceable({{[0-9]+}}) [[APTR:%.+]], float** dereferenceable({{[0-9]+}}) [[BPTR:%.+]], float** dereferenceable({{[0-9]+}}) [[CPTR:%.+]], float** dereferenceable({{[0-9]+}}) [[DPTR:%.+]])
+// CHECK:  [[TID_ADDR:%.+]] = alloca i32*
+// CHECK:  [[IV:%.+iv]] = alloca i32
+// CHECK:  [[LB:%.+lb]] = alloca i32
+// CHECK:  [[UB:%.+ub]] = alloca i32
+// CHECK:  [[ST:%.+stride]] = alloca i32
+// CHECK:  [[LAST:%.+last]] = alloca i32
+// CHECK-DAG:  store i32* [[GBL_TIDP]], i32** [[TID_ADDR]]
+// CHECK-DAG:  store i32 0, i32* [[LB]]
+// CHECK-DAG:  store i32 4571423, i32* [[UB]]
+// CHECK-DAG:  store i32 1, 

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

[H.J. Lu via cfe-commits]

On Tue, Feb 16, 2016 at 1:15 PM, Richard Smith  wrote:
> On Tue, Feb 16, 2016 at 1:10 PM, H.J. Lu  wrote:
>> On Tue, Feb 16, 2016 at 1:02 PM, Richard Smith  wrote:
>>> On Tue, Feb 16, 2016 at 12:25 PM, H.J. Lu  wrote:
 On Tue, Feb 16, 2016 at 12:22 PM, Richard Smith  
 wrote:
> On Tue, Feb 16, 2016 at 10:24 AM, H.J. Lu  wrote:
>>
>> On Fri, Feb 12, 2016 at 11:39 AM, H.J. Lu  wrote:
>> > On Fri, Feb 12, 2016 at 6:58 AM, Matthijs van Duin
>> >  wrote:
>> >> On 11 February 2016 at 16:31, H.J. Lu  wrote:
>> >>> struct A {
>> >>> static void foo (void) ();
>> >>> static int xxx;
>> >>> };
>> >>
>> >> What about it? It's an empty struct.  (And it declares a function and
>> >> a variable in the namespace of A, which however do not have any
>> >> relevant impact here.)
>> >>
>> >
>> > Thanks for all the feedbacks.  Here is the new proposal:
>> >
>> > 1. "empty type".  An empty type is a trivially-copyable aggregate
>> > occupying zero bytes (excluding any padding).
>> > 2. No memory slot nor register should be used to pass or return an 
>> > object
>> > of empty type.
>> >
>> > Footnote: Array of empty type can only passed by reference in C/C++.
>> >
>>
>> I updated intel386, x86-64 and IA MCU psABIs:
>>
>> https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI
>>
>> to specify:
>>
>> Empty type is defined as a trivially-copyable aggregate occupying zero 
>> bytes
>> (excluding any padding).
>
> I think this is now extremely unclear. Does an empty struct in C++
> occupy zero bytes? sizeof applied to it will produce at least 1.

 Can it be considered as padding?
>>>
>>> Perhaps, but I would contend that that's unclear in at least some
>>> cases (when the class is used as the type of a member, ...). What
>>> about this case:
>>>
>>>   struct X { unsigned : 15; };
>>>
>>> Is that empty or not? Do we have a formal definition somewhere of what
>>> does, and does not, count as padding?
>>
>> How about this?
>>
>> Empty type is defined as a trivially-copyable aggregate occupying zero bytes
>> (excluding any padding or contributing zero bytes to the size of derived
>> classes in C++).
>>
>> This will cover
>>
>> struct dummy0
>> {
>>   void bar (void);
>> };
>> struct dummy1
>> {
>>   void foo (void);
>> };
>> struct dummy : dummy0, dummy1 { };
>>
>> But not
>>
>> struct dummy0
>> {
>> };
>> struct dummy1
>> {
>>   unsigned : 15;
>> };
>> struct dummy : dummy0, dummy1
>> {
>> };
>
> Why not? That looks empty to me. The ABI will classify the
> corresponding eightbyte as NO_CLASS, as it has no members, so it
> should not be passed.

Do you have a wording to describe it?


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

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

[Richard Smith via cfe-commits]

On Tue, Feb 16, 2016 at 1:21 PM, H.J. Lu  wrote:
> On Tue, Feb 16, 2016 at 1:15 PM, Richard Smith  wrote:
>> On Tue, Feb 16, 2016 at 1:10 PM, H.J. Lu  wrote:
>>> On Tue, Feb 16, 2016 at 1:02 PM, Richard Smith  
>>> wrote:
 On Tue, Feb 16, 2016 at 12:25 PM, H.J. Lu  wrote:
> On Tue, Feb 16, 2016 at 12:22 PM, Richard Smith  
> wrote:
>> On Tue, Feb 16, 2016 at 10:24 AM, H.J. Lu  wrote:
>>>
>>> On Fri, Feb 12, 2016 at 11:39 AM, H.J. Lu  wrote:
>>> > On Fri, Feb 12, 2016 at 6:58 AM, Matthijs van Duin
>>> >  wrote:
>>> >> On 11 February 2016 at 16:31, H.J. Lu  wrote:
>>> >>> struct A {
>>> >>> static void foo (void) ();
>>> >>> static int xxx;
>>> >>> };
>>> >>
>>> >> What about it? It's an empty struct.  (And it declares a function and
>>> >> a variable in the namespace of A, which however do not have any
>>> >> relevant impact here.)
>>> >>
>>> >
>>> > Thanks for all the feedbacks.  Here is the new proposal:
>>> >
>>> > 1. "empty type".  An empty type is a trivially-copyable aggregate
>>> > occupying zero bytes (excluding any padding).
>>> > 2. No memory slot nor register should be used to pass or return an 
>>> > object
>>> > of empty type.
>>> >
>>> > Footnote: Array of empty type can only passed by reference in C/C++.
>>> >
>>>
>>> I updated intel386, x86-64 and IA MCU psABIs:
>>>
>>> https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI
>>>
>>> to specify:
>>>
>>> Empty type is defined as a trivially-copyable aggregate occupying zero 
>>> bytes
>>> (excluding any padding).
>>
>> I think this is now extremely unclear. Does an empty struct in C++
>> occupy zero bytes? sizeof applied to it will produce at least 1.
>
> Can it be considered as padding?

 Perhaps, but I would contend that that's unclear in at least some
 cases (when the class is used as the type of a member, ...). What
 about this case:

   struct X { unsigned : 15; };

 Is that empty or not? Do we have a formal definition somewhere of what
 does, and does not, count as padding?
>>>
>>> How about this?
>>>
>>> Empty type is defined as a trivially-copyable aggregate occupying zero bytes
>>> (excluding any padding or contributing zero bytes to the size of derived
>>> classes in C++).
>>>
>>> This will cover
>>>
>>> struct dummy0
>>> {
>>>   void bar (void);
>>> };
>>> struct dummy1
>>> {
>>>   void foo (void);
>>> };
>>> struct dummy : dummy0, dummy1 { };
>>>
>>> But not
>>>
>>> struct dummy0
>>> {
>>> };
>>> struct dummy1
>>> {
>>>   unsigned : 15;
>>> };
>>> struct dummy : dummy0, dummy1
>>> {
>>> };
>>
>> Why not? That looks empty to me. The ABI will classify the
>> corresponding eightbyte as NO_CLASS, as it has no members, so it
>> should not be passed.
>
> Do you have a wording to describe it?

Yes, something like what you had before was fine:

  "empty type". An empty type is a type where it and all of its
subobjects (recursively) are of class, structure, union, or array
type.

Or, if you think it makes the intent clearer, reverse the sense:

  A type is non-empty if it or any subobject (recursively) is of any
type other than class, structure, union, or array type.

If you like, you could add notes that a parameter type is never an
array type, and that unnamed bit-fields are not subobjects, but they
seem redundant given the wording of the relevant standards. (You don't
need to say anything about "POD for the purpose of layout", or
destructors, or whatever else, because the C++ ABI only delegates to
the C psABI for cases that are valid to pass in registers from a C++
language semantics point of view.)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[H.J. Lu via cfe-commits]

On Tue, Feb 16, 2016 at 1:45 PM, Richard Smith  wrote:
> On Tue, Feb 16, 2016 at 1:21 PM, H.J. Lu  wrote:
>> On Tue, Feb 16, 2016 at 1:15 PM, Richard Smith  wrote:
>>> On Tue, Feb 16, 2016 at 1:10 PM, H.J. Lu  wrote:
 On Tue, Feb 16, 2016 at 1:02 PM, Richard Smith  
 wrote:
> On Tue, Feb 16, 2016 at 12:25 PM, H.J. Lu  wrote:
>> On Tue, Feb 16, 2016 at 12:22 PM, Richard Smith  
>> wrote:
>>> On Tue, Feb 16, 2016 at 10:24 AM, H.J. Lu  wrote:

 On Fri, Feb 12, 2016 at 11:39 AM, H.J. Lu  wrote:
 > On Fri, Feb 12, 2016 at 6:58 AM, Matthijs van Duin
 >  wrote:
 >> On 11 February 2016 at 16:31, H.J. Lu  wrote:
 >>> struct A {
 >>> static void foo (void) ();
 >>> static int xxx;
 >>> };
 >>
 >> What about it? It's an empty struct.  (And it declares a function 
 >> and
 >> a variable in the namespace of A, which however do not have any
 >> relevant impact here.)
 >>
 >
 > Thanks for all the feedbacks.  Here is the new proposal:
 >
 > 1. "empty type".  An empty type is a trivially-copyable aggregate
 > occupying zero bytes (excluding any padding).
 > 2. No memory slot nor register should be used to pass or return an 
 > object
 > of empty type.
 >
 > Footnote: Array of empty type can only passed by reference in C/C++.
 >

 I updated intel386, x86-64 and IA MCU psABIs:

 https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI

 to specify:

 Empty type is defined as a trivially-copyable aggregate occupying zero 
 bytes
 (excluding any padding).
>>>
>>> I think this is now extremely unclear. Does an empty struct in C++
>>> occupy zero bytes? sizeof applied to it will produce at least 1.
>>
>> Can it be considered as padding?
>
> Perhaps, but I would contend that that's unclear in at least some
> cases (when the class is used as the type of a member, ...). What
> about this case:
>
>   struct X { unsigned : 15; };
>
> Is that empty or not? Do we have a formal definition somewhere of what
> does, and does not, count as padding?

 How about this?

 Empty type is defined as a trivially-copyable aggregate occupying zero 
 bytes
 (excluding any padding or contributing zero bytes to the size of derived
 classes in C++).

 This will cover

 struct dummy0
 {
   void bar (void);
 };
 struct dummy1
 {
   void foo (void);
 };
 struct dummy : dummy0, dummy1 { };

 But not

 struct dummy0
 {
 };
 struct dummy1
 {
   unsigned : 15;
 };
 struct dummy : dummy0, dummy1
 {
 };
>>>
>>> Why not? That looks empty to me. The ABI will classify the
>>> corresponding eightbyte as NO_CLASS, as it has no members, so it
>>> should not be passed.
>>
>> Do you have a wording to describe it?
>
> Yes, something like what you had before was fine:
>
>   "empty type". An empty type is a type where it and all of its
> subobjects (recursively) are of class, structure, union, or array
> type.
>
> Or, if you think it makes the intent clearer, reverse the sense:
>
>   A type is non-empty if it or any subobject (recursively) is of any
> type other than class, structure, union, or array type.

Does the above cover

struct dummy0
{
  void bar (void);
};
struct dummy1
{
  void foo (void);
};
struct dummy : dummy0, dummy1 { };

> If you like, you could add notes that a parameter type is never an
> array type, and that unnamed bit-fields are not subobjects, but they
> seem redundant given the wording of the relevant standards. (You don't
> need to say anything about "POD for the purpose of layout", or
> destructors, or whatever else, because the C++ ABI only delegates to
> the C psABI for cases that are valid to pass in registers from a C++
> language semantics point of view.)



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

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

[Daniel Sanders via cfe-commits]

dsanders added a comment.

Sorry for the early ping but I need to fix this for rc3 (which Hans is hoping 
to tag mid-week) and I'm stuck as long as the requirement that the C++ tests in 
r260527 fail without my patch is in place.

I'm happy to make this '#ifdef __mips__' if that helps.


http://reviews.llvm.org/D17132



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

Re: [PATCH] D16552: Let clang not error out on `const std::vector empty_vec; ` with libstdc++5.3.

[Nico Weber via cfe-commits]

thakis updated this revision to Diff 48107.
thakis added a comment.

Checkpointing; not production quality. I tried implementing the general DR 253 
rule, and this patch mostly does that. It currently walks all fields and all 
bases for every const record decl; there should probably be a cache for "are 
all fields obviously initialized"; probably on CXXRecordDecl. I had to change 
some test cases, but nothing surprising.

However, while this patch does fix `const std::unordered_map um;` 
with libstdc++5.3, it does _not_ fix `std::vector v;` or `const 
std::unordered_map um;` when -D_GLIBCXX_DEBUG=1 is passed in. 
Investigating that case more now.


http://reviews.llvm.org/D16552

Files:
  lib/Sema/SemaInit.cpp
  test/CXX/dcl.decl/dcl.fct.def/dcl.fct.def.default/p2.cpp
  test/CXX/dcl.decl/dcl.init/p6.cpp
  test/SemaCXX/attr-selectany.cpp
  test/SemaCXX/constexpr-value-init.cpp
  test/SemaCXX/cxx0x-cursory-default-delete.cpp
  test/SemaCXX/illegal-member-initialization.cpp

Index: test/SemaCXX/illegal-member-initialization.cpp
===
--- test/SemaCXX/illegal-member-initialization.cpp
+++ test/SemaCXX/illegal-member-initialization.cpp
@@ -7,6 +7,7 @@
 };
 
 struct B {
+  int field;
 };
 
 struct X {
Index: test/SemaCXX/cxx0x-cursory-default-delete.cpp
===
--- test/SemaCXX/cxx0x-cursory-default-delete.cpp
+++ test/SemaCXX/cxx0x-cursory-default-delete.cpp
@@ -11,6 +11,7 @@
   non_const_copy& operator = (non_const_copy&) &;
   non_const_copy& operator = (non_const_copy&) &&;
   non_const_copy() = default; // expected-note {{not viable}}
+  int uninit_field;
 };
 non_const_copy::non_const_copy(non_const_copy&) = default; // expected-note {{not viable}}
 non_const_copy& non_const_copy::operator = (non_const_copy&) & = default; // expected-note {{not viable}}
@@ -30,6 +31,56 @@
   ncc = cncc; // expected-error {{no viable overloaded}}
 };
 
+struct no_fields { };
+struct all_init {
+  int a = 0;
+  int b = 0;
+};
+struct some_init {
+  int a = 0;
+  int b;
+  int c = 0;
+};
+struct some_init_def {
+  some_init_def() = default;
+  int a = 0;
+  int b;
+  int c = 0;
+};
+struct some_init_ctor {
+  some_init_ctor();
+  int a = 0;
+  int b;
+  int c = 0;
+};
+struct sub_some_init : public some_init_def { };
+struct sub_some_init_ctor : public some_init_def {
+  sub_some_init_ctor();
+};
+struct some_init_container {
+  some_init_def sid;
+};
+struct some_init_container_ctor {
+  some_init_container_ctor();
+  some_init_def sid;
+};
+struct no_fields_container {
+  no_fields nf;
+};
+
+void constobjs() {
+  const no_fields nf; // ok
+  const all_init ai; // ok
+  const some_init si; // expected-error {{default initialization of an object of const type 'const some_init' without a user-provided default constructor}}
+  const some_init_def sid; // expected-error {{default initialization of an object of const type 'const some_init_def' without a user-provided default constructor}}
+  const some_init_ctor sic; // ok
+  const sub_some_init ssi; // expected-error {{default initialization of an object of const type 'const sub_some_init' without a user-provided default constructor}}
+  const sub_some_init_ctor ssic; // ok
+  const some_init_container sicon; // expected-error {{default initialization of an object of const type 'const some_init_container' without a user-provided default constructor}}
+  const some_init_container_ctor siconc; // ok
+  const no_fields_container nfc; // ok
+}
+
 struct non_const_derived : non_const_copy {
   non_const_derived(const non_const_derived&) = default; // expected-error {{requires it to be non-const}}
   non_const_derived& operator =(non_const_derived&) = default;
Index: test/SemaCXX/constexpr-value-init.cpp
===
--- test/SemaCXX/constexpr-value-init.cpp
+++ test/SemaCXX/constexpr-value-init.cpp
@@ -14,7 +14,7 @@
   constexpr A a; // expected-error {{constant expression}} expected-note {{in call to 'A()'}}
 }
 
-constexpr B b1; // expected-error {{without a user-provided default constructor}}
+constexpr B b1; // ok
 constexpr B b2 = B(); // ok
 static_assert(b2.a.a == 1, "");
 static_assert(b2.a.b == 2, "");
Index: test/SemaCXX/attr-selectany.cpp
===
--- test/SemaCXX/attr-selectany.cpp
+++ test/SemaCXX/attr-selectany.cpp
@@ -39,7 +39,9 @@
 // The D3D11 headers do something like this.  MSVC doesn't error on this at
 // all, even without the __declspec(selectany), in violation of the standard.
 // We fall back to a warning for selectany to accept headers.
-struct SomeStruct {};
+struct SomeStruct {
+  int foo;
+};
 extern const __declspec(selectany) SomeStruct some_struct; // expected-warning {{default initialization of an object of const type 'const SomeStruct' without a user-provided default constructor is a Microsoft extension}}
 
 // It shou

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

[Daniel Sanders via cfe-commits]

Hi Ben,

Does 'this change' refer to r260235 or r260961?

From: cfe-commits [cfe-commits-boun...@lists.llvm.org] on behalf of Craig, Ben 
via cfe-commits [cfe-commits@lists.llvm.org]
Sent: 16 February 2016 21:09
To: cfe-commits@lists.llvm.org
Subject: Re: [libcxx] r260235 - Introduce a cmake module to figure out whether 
we need to link with libatomic.

FYI, this change and the LLVM version have each broken my libcxx
builds.  I cross compile from Linux x64 to Hexagon, and my host machine
doesn't have .  The LLVM change was particularly offensive
because I wasn't planning on building LLVM itself.

I have since worked around the issue by making my cmake invocation longer.

I'm not sure what you can do for the LLVM check, but if you can use the
libcxx headers directly for the  check, while still using all
the custom flags and tools that I pass on the command line, then I
should be able to remove the explicit setting of
"LIBCXX_HAVE_CXX_ATOMICS_WITHOUT_LIB" in the future.

On 2/16/2016 2:09 PM, Vasileios Kalintiris via cfe-commits wrote:
> Hi Hans,
>
>> Or is this comment on PR26059 all that needs to be done for 3.8?
> That's correct. I wrote that comment in order to clarify which bits we should 
> merge in 3.8.
>
> The latest commit:
>
> - [libcxx] r260961 - Issue a warning instead of fatal errors when checks for 
> libatomic fail."
>
> makes sure that my changes don't break older configurations that used to work 
> previously, by emitting a warning message instead of a fatal error.
>
> I had to turn the error to warning because there are cases where the host 
> compiler doesn't provide the  and  headers when 
> bootstrapping llvm.
>
> The correct solution would be to use the headers provided from libc++ itself. 
> However, I wanted to take the safe route for the 3.8 branch and provide the 
> elegant solution on the trunk after having the proper discussion with the 
> libc++ devs.
>
> Thanks,
> Vasileios
>
> 
> From: hwennb...@google.com [hwennb...@google.com] on behalf of Hans Wennborg 
> [h...@chromium.org]
> Sent: 16 February 2016 19:53
> To: Vasileios Kalintiris
> Cc: Eric Fiselier; Daniel Sanders; mclow.li...@gmail.com; 
> cfe-commits@lists.llvm.org
> Subject: Re: [libcxx] r260235 - Introduce a cmake module to figure out 
> whether we need to link with libatomic.
>
> Or is this comment on PR26059 all that needs to be done for 3.8?
>
> "Bug 26369, which has been fixed with r260961, requires the following
> commits to get merged on the release branch:
>
> - [libcxx] r260515 - Re-commit "Introduce a cmake module to figure out
> whether we need to link with libatomic."
> - [libcxx] r260524 - Fix r260515 - Correct typos in CMake changes
> - [libcxx] r260531 - Rename CheckLibcxxAtomic.cmake variable result
> names so they don't clash with LLVM
> - [libcxx] r260961 - Issue a warning instead of fatal errors when
> checks for libatomic fail."
>
> Thanks,
> Hans
>
> On Tue, Feb 16, 2016 at 11:47 AM, Hans Wennborg  wrote:
>> Do I understand correctly that there are still issues here's that are not 
>> fixed?
>>
>> (I'm trying to understand if there is something here to merge for 3.8,
>> but I'm having trouble following these commits.)
>>
>> On Tue, Feb 16, 2016 at 6:44 AM, Vasileios Kalintiris
>>  wrote:
>>> I changed the type of message from fatal_error to warning in r260961. While
>>> the test for atomics works fine in most cases, it fails because we include
>>>  and , and the user's host compiler might not provide them
>>> during a bootstrap (see PR26631 and PR26622).
>>>
>>> Does anyone have any idea how to tackle this problem? As suggested by the
>>> bug reports, we could include the headers provided by libc++. However, I'm
>>> not sure whether we are supposed to do that during configuration time.
>>>
>>> - Vasileios
>>>
>>>
>>> 
>>> From: Eric Fiselier [e...@efcs.ca]
>>> Sent: 11 February 2016 16:08
>>> To: Daniel Sanders
>>> Cc: Vasileios Kalintiris; h...@chromium.org; mclow.li...@gmail.com;
>>> cfe-commits@lists.llvm.org
>>> Subject: Re: [libcxx] r260235 - Introduce a cmake module to figure out
>>> whether we need to link with libatomic.
>>>
   we need to rename HAVE_CXX_ATOMICS_WITH_LIB to something like
 LIBCXX_HAVE_CXX_ATOMICS_WITH_LIB.
>>> Fixed in r260531.
>>>
>>> I think we will eventually want to merge the following commits, assuming
>>> they don't regress the build, especially with the -gcc-toolchain option.
>>>
>>> - [libcxx] r260515 - Re-commit "Introduce a cmake module to figure out
>>> whether we need to link with libatomic."
>>> - [libcxx] r260524 - Fix r260515 - Correct typos in CMake changes
>>> - [libcxx] r260531 - Rename CheckLibcxxAtomic.cmake variable result names so
>>> they don't clash with LLVM
>>>
>>> @Marshall Any objections?
>>>
>>> On Thu, Feb 11, 2016 at 2:18 AM, Daniel Sanders via cfe-commits
>>>  wrote:
 Hi,

 In my latests rc2+patches build I've al

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

[Vasileios Kalintiris via cfe-commits]

Hi Ben,

> FYI, this change and the LLVM version have each broken my libcxx
> builds.  I cross compile from Linux x64 to Hexagon, and my host machine
> doesn't have .  The LLVM change was particularly offensive
> because I wasn't planning on building LLVM itself.

There's no change on the LLVM side, ie. I abandoned the review request you have 
in mind after discussion with the reviewers.

> I have since worked around the issue by making my cmake invocation longer.
>
> I'm not sure what you can do for the LLVM check, but if you can use the
> libcxx headers directly for the  check, while still using all
> the custom flags and tools that I pass on the command line, then I
> should be able to remove the explicit setting of
> "LIBCXX_HAVE_CXX_ATOMICS_WITHOUT_LIB" in the future.

You shouldn't have any problems with the latest commit (r260961):  "Issue a 
warning instead of fatal errors when checks for libatomic fail."  I suppose 
that you aren't using the latest trunk, right?

- Vasileios

 

From: cfe-commits [cfe-commits-boun...@lists.llvm.org] on behalf of Craig, Ben 
via cfe-commits [cfe-commits@lists.llvm.org]
Sent: 16 February 2016 21:09
To: cfe-commits@lists.llvm.org
Subject: Re: [libcxx] r260235 - Introduce a cmake module to figure out whether 
we need to link with libatomic.

FYI, this change and the LLVM version have each broken my libcxx
builds.  I cross compile from Linux x64 to Hexagon, and my host machine
doesn't have .  The LLVM change was particularly offensive
because I wasn't planning on building LLVM itself.

I have since worked around the issue by making my cmake invocation longer.

I'm not sure what you can do for the LLVM check, but if you can use the
libcxx headers directly for the  check, while still using all
the custom flags and tools that I pass on the command line, then I
should be able to remove the explicit setting of
"LIBCXX_HAVE_CXX_ATOMICS_WITHOUT_LIB" in the future.

On 2/16/2016 2:09 PM, Vasileios Kalintiris via cfe-commits wrote:
> Hi Hans,
>
>> Or is this comment on PR26059 all that needs to be done for 3.8?
> That's correct. I wrote that comment in order to clarify which bits we should 
> merge in 3.8.
>
> The latest commit:
>
> - [libcxx] r260961 - Issue a warning instead of fatal errors when checks for 
> libatomic fail."
>
> makes sure that my changes don't break older configurations that used to work 
> previously, by emitting a warning message instead of a fatal error.
>
> I had to turn the error to warning because there are cases where the host 
> compiler doesn't provide the  and  headers when 
> bootstrapping llvm.
>
> The correct solution would be to use the headers provided from libc++ itself. 
> However, I wanted to take the safe route for the 3.8 branch and provide the 
> elegant solution on the trunk after having the proper discussion with the 
> libc++ devs.
>
> Thanks,
> Vasileios
>
> 
> From: hwennb...@google.com [hwennb...@google.com] on behalf of Hans Wennborg 
> [h...@chromium.org]
> Sent: 16 February 2016 19:53
> To: Vasileios Kalintiris
> Cc: Eric Fiselier; Daniel Sanders; mclow.li...@gmail.com; 
> cfe-commits@lists.llvm.org
> Subject: Re: [libcxx] r260235 - Introduce a cmake module to figure out 
> whether we need to link with libatomic.
>
> Or is this comment on PR26059 all that needs to be done for 3.8?
>
> "Bug 26369, which has been fixed with r260961, requires the following
> commits to get merged on the release branch:
>
> - [libcxx] r260515 - Re-commit "Introduce a cmake module to figure out
> whether we need to link with libatomic."
> - [libcxx] r260524 - Fix r260515 - Correct typos in CMake changes
> - [libcxx] r260531 - Rename CheckLibcxxAtomic.cmake variable result
> names so they don't clash with LLVM
> - [libcxx] r260961 - Issue a warning instead of fatal errors when
> checks for libatomic fail."
>
> Thanks,
> Hans
>
> On Tue, Feb 16, 2016 at 11:47 AM, Hans Wennborg  wrote:
>> Do I understand correctly that there are still issues here's that are not 
>> fixed?
>>
>> (I'm trying to understand if there is something here to merge for 3.8,
>> but I'm having trouble following these commits.)
>>
>> On Tue, Feb 16, 2016 at 6:44 AM, Vasileios Kalintiris
>>  wrote:
>>> I changed the type of message from fatal_error to warning in r260961. While
>>> the test for atomics works fine in most cases, it fails because we include
>>>  and , and the user's host compiler might not provide them
>>> during a bootstrap (see PR26631 and PR26622).
>>>
>>> Does anyone have any idea how to tackle this problem? As suggested by the
>>> bug reports, we could include the headers provided by libc++. However, I'm
>>> not sure whether we are supposed to do that during configuration time.
>>>
>>> - Vasileios
>>>
>>>
>>> 
>>> From: Eric Fiselier [e...@efcs.ca]
>>> Sent: 11 February 2016 16:08
>>> To: Daniel Sanders
>>> Cc: Vasileios Kalintiris; h...@chromium.org; mc

r261018 - [CUDA] pass debug options to ptxas.

[Artem Belevich via cfe-commits]

Author: tra
Date: Tue Feb 16 16:03:20 2016
New Revision: 261018

URL: http://llvm.org/viewvc/llvm-project?rev=261018&view=rev
Log:
[CUDA] pass debug options to ptxas.

ptxas optimizations are disabled if we need to generate debug info
as ptxas does not accept '-g' otherwise.

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

Modified:
cfe/trunk/include/clang/Driver/Options.td
cfe/trunk/lib/Driver/Tools.cpp
cfe/trunk/test/Driver/cuda-external-tools.cu

Modified: cfe/trunk/include/clang/Driver/Options.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=261018&r1=261017&r2=261018&view=diff
==
--- cfe/trunk/include/clang/Driver/Options.td (original)
+++ cfe/trunk/include/clang/Driver/Options.td Tue Feb 16 16:03:20 2016
@@ -378,6 +378,8 @@ def cuda_gpu_arch_EQ : Joined<["--"], "c
   Flags<[DriverOption, HelpHidden]>, HelpText<"CUDA GPU architecture">;
 def cuda_host_only : Flag<["--"], "cuda-host-only">,
   HelpText<"Do host-side CUDA compilation only">;
+def cuda_noopt_device_debug : Flag<["--"], "cuda-noopt-device-debug">,
+  HelpText<"Enable device-side debug info generation. Disables ptxas 
optimizations.">;
 def cuda_path_EQ : Joined<["--"], "cuda-path=">, Group,
   HelpText<"CUDA installation path">;
 def dA : Flag<["-"], "dA">, Group;

Modified: cfe/trunk/lib/Driver/Tools.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=261018&r1=261017&r2=261018&view=diff
==
--- cfe/trunk/lib/Driver/Tools.cpp (original)
+++ cfe/trunk/lib/Driver/Tools.cpp Tue Feb 16 16:03:20 2016
@@ -10691,15 +10691,20 @@ void NVPTX::Assembler::ConstructJob(Comp
   assert(gpu_archs.size() == 1 && "Exactly one GPU Arch required for ptxas.");
   const std::string& gpu_arch = gpu_archs[0];
 
-
   ArgStringList CmdArgs;
   CmdArgs.push_back(TC.getTriple().isArch64Bit() ? "-m64" : "-m32");
+  if (Args.getLastArg(options::OPT_cuda_noopt_device_debug)) {
+// ptxas does not accept -g option if optimization is enabled, so
+// we ignore the compiler's -O* options if we want debug info.
+CmdArgs.push_back("-g");
+CmdArgs.push_back("--dont-merge-basicblocks");
+CmdArgs.push_back("--return-at-end");
+  } else if (Arg *A = Args.getLastArg(options::OPT_O_Group)) {
+// Map the -O we received to -O{0,1,2,3}.
+//
+// TODO: Perhaps we should map host -O2 to ptxas -O3. -O3 is ptxas's
+// default, so it may correspond more closely to the spirit of clang -O2.
 
-  // Map the -O we received to -O{0,1,2,3}.
-  //
-  // TODO: Perhaps we should map host -O2 to ptxas -O3. -O3 is ptxas's default,
-  // so it may correspond more closely to the spirit of clang -O2.
-  if (Arg *A = Args.getLastArg(options::OPT_O_Group)) {
 // -O3 seems like the least-bad option when -Osomething is specified to
 // clang but it isn't handled below.
 StringRef OOpt = "3";
@@ -10725,9 +10730,6 @@ void NVPTX::Assembler::ConstructJob(Comp
 CmdArgs.push_back("-O0");
   }
 
-  // Don't bother passing -g to ptxas: It's enabled by default at -O0, and
-  // not supported at other optimization levels.
-
   CmdArgs.push_back("--gpu-name");
   CmdArgs.push_back(Args.MakeArgString(gpu_arch));
   CmdArgs.push_back("--output-file");

Modified: cfe/trunk/test/Driver/cuda-external-tools.cu
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/cuda-external-tools.cu?rev=261018&r1=261017&r2=261018&view=diff
==
--- cfe/trunk/test/Driver/cuda-external-tools.cu (original)
+++ cfe/trunk/test/Driver/cuda-external-tools.cu Tue Feb 16 16:03:20 2016
@@ -18,6 +18,10 @@
 // RUN: %clang -### -target x86_64-linux-gnu -Ofast -c %s 2>&1 \
 // RUN: | FileCheck -check-prefix ARCH64 -check-prefix SM20 -check-prefix OPT3 
%s
 
+// With debugging enabled, ptxas should be run with with no ptxas 
optimizations.
+// RUN: %clang -### -target x86_64-linux-gnu --cuda-noopt-device-debug -O2 -c 
%s 2>&1 \
+// RUN: | FileCheck -check-prefix ARCH64 -check-prefix SM20 -check-prefix DBG 
%s
+
 // Regular compile without -O.  This should result in us passing -O0 to ptxas.
 // RUN: %clang -### -target x86_64-linux-gnu -c %s 2>&1 \
 // RUN: | FileCheck -check-prefix ARCH64 -check-prefix SM20 -check-prefix OPT0 
%s
@@ -59,9 +63,14 @@
 // ARCH64: "-m64"
 // ARCH32: "-m32"
 // OPT0: "-O0"
+// OPT0-NOT: "-g"
 // OPT1: "-O1"
+// OPT1-NOT: "-g"
 // OPT2: "-O2"
+// OPT2-NOT: "-g"
 // OPT3: "-O3"
+// OPT3-NOT: "-g"
+// DBG: "-g" "--dont-merge-basicblocks" "--return-at-end"
 // SM20: "--gpu-name" "sm_20"
 // SM35: "--gpu-name" "sm_35"
 // SM20: "--output-file" "[[CUBINFILE:[^"]*]]"


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

Re: [PATCH] D17111: [CUDA] Added --cuda-noopt-device-debug option to control ptxas' debug info generation.

[Artem Belevich via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL261018: [CUDA] pass debug options to ptxas. (authored by 
tra).

Changed prior to commit:
  http://reviews.llvm.org/D17111?vs=47680&id=48108#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D17111

Files:
  cfe/trunk/include/clang/Driver/Options.td
  cfe/trunk/lib/Driver/Tools.cpp
  cfe/trunk/test/Driver/cuda-external-tools.cu

Index: cfe/trunk/lib/Driver/Tools.cpp
===
--- cfe/trunk/lib/Driver/Tools.cpp
+++ cfe/trunk/lib/Driver/Tools.cpp
@@ -10691,15 +10691,20 @@
   assert(gpu_archs.size() == 1 && "Exactly one GPU Arch required for ptxas.");
   const std::string& gpu_arch = gpu_archs[0];
 
-
   ArgStringList CmdArgs;
   CmdArgs.push_back(TC.getTriple().isArch64Bit() ? "-m64" : "-m32");
+  if (Args.getLastArg(options::OPT_cuda_noopt_device_debug)) {
+// ptxas does not accept -g option if optimization is enabled, so
+// we ignore the compiler's -O* options if we want debug info.
+CmdArgs.push_back("-g");
+CmdArgs.push_back("--dont-merge-basicblocks");
+CmdArgs.push_back("--return-at-end");
+  } else if (Arg *A = Args.getLastArg(options::OPT_O_Group)) {
+// Map the -O we received to -O{0,1,2,3}.
+//
+// TODO: Perhaps we should map host -O2 to ptxas -O3. -O3 is ptxas's
+// default, so it may correspond more closely to the spirit of clang -O2.
 
-  // Map the -O we received to -O{0,1,2,3}.
-  //
-  // TODO: Perhaps we should map host -O2 to ptxas -O3. -O3 is ptxas's default,
-  // so it may correspond more closely to the spirit of clang -O2.
-  if (Arg *A = Args.getLastArg(options::OPT_O_Group)) {
 // -O3 seems like the least-bad option when -Osomething is specified to
 // clang but it isn't handled below.
 StringRef OOpt = "3";
@@ -10725,9 +10730,6 @@
 CmdArgs.push_back("-O0");
   }
 
-  // Don't bother passing -g to ptxas: It's enabled by default at -O0, and
-  // not supported at other optimization levels.
-
   CmdArgs.push_back("--gpu-name");
   CmdArgs.push_back(Args.MakeArgString(gpu_arch));
   CmdArgs.push_back("--output-file");
Index: cfe/trunk/include/clang/Driver/Options.td
===
--- cfe/trunk/include/clang/Driver/Options.td
+++ cfe/trunk/include/clang/Driver/Options.td
@@ -378,6 +378,8 @@
   Flags<[DriverOption, HelpHidden]>, HelpText<"CUDA GPU architecture">;
 def cuda_host_only : Flag<["--"], "cuda-host-only">,
   HelpText<"Do host-side CUDA compilation only">;
+def cuda_noopt_device_debug : Flag<["--"], "cuda-noopt-device-debug">,
+  HelpText<"Enable device-side debug info generation. Disables ptxas 
optimizations.">;
 def cuda_path_EQ : Joined<["--"], "cuda-path=">, Group,
   HelpText<"CUDA installation path">;
 def dA : Flag<["-"], "dA">, Group;
Index: cfe/trunk/test/Driver/cuda-external-tools.cu
===
--- cfe/trunk/test/Driver/cuda-external-tools.cu
+++ cfe/trunk/test/Driver/cuda-external-tools.cu
@@ -18,6 +18,10 @@
 // RUN: %clang -### -target x86_64-linux-gnu -Ofast -c %s 2>&1 \
 // RUN: | FileCheck -check-prefix ARCH64 -check-prefix SM20 -check-prefix OPT3 
%s
 
+// With debugging enabled, ptxas should be run with with no ptxas 
optimizations.
+// RUN: %clang -### -target x86_64-linux-gnu --cuda-noopt-device-debug -O2 -c 
%s 2>&1 \
+// RUN: | FileCheck -check-prefix ARCH64 -check-prefix SM20 -check-prefix DBG 
%s
+
 // Regular compile without -O.  This should result in us passing -O0 to ptxas.
 // RUN: %clang -### -target x86_64-linux-gnu -c %s 2>&1 \
 // RUN: | FileCheck -check-prefix ARCH64 -check-prefix SM20 -check-prefix OPT0 
%s
@@ -59,9 +63,14 @@
 // ARCH64: "-m64"
 // ARCH32: "-m32"
 // OPT0: "-O0"
+// OPT0-NOT: "-g"
 // OPT1: "-O1"
+// OPT1-NOT: "-g"
 // OPT2: "-O2"
+// OPT2-NOT: "-g"
 // OPT3: "-O3"
+// OPT3-NOT: "-g"
+// DBG: "-g" "--dont-merge-basicblocks" "--return-at-end"
 // SM20: "--gpu-name" "sm_20"
 // SM35: "--gpu-name" "sm_35"
 // SM20: "--output-file" "[[CUBINFILE:[^"]*]]"


Index: cfe/trunk/lib/Driver/Tools.cpp
===
--- cfe/trunk/lib/Driver/Tools.cpp
+++ cfe/trunk/lib/Driver/Tools.cpp
@@ -10691,15 +10691,20 @@
   assert(gpu_archs.size() == 1 && "Exactly one GPU Arch required for ptxas.");
   const std::string& gpu_arch = gpu_archs[0];
 
-
   ArgStringList CmdArgs;
   CmdArgs.push_back(TC.getTriple().isArch64Bit() ? "-m64" : "-m32");
+  if (Args.getLastArg(options::OPT_cuda_noopt_device_debug)) {
+// ptxas does not accept -g option if optimization is enabled, so
+// we ignore the compiler's -O* options if we want debug info.
+CmdArgs.push_back("-g");
+CmdArgs.push_back("--dont-merge-basicblocks");
+CmdArgs.push_back("--return-at-end");
+  } else if (Arg *A = Args.getLastArg(options::OPT_O_Group)) {
+// Map the -O we received to -O{0,1,2,3}.
+//
+// 

Re: [PATCH] D16376: clang-tidy check: misc-deprecated-special-member-functions

[Jonathan B Coe via cfe-commits]

jbcoe added a comment.

It's more than the warning because it offers fixits. Other than that it should 
be the same. Using the same code as used to warn on deprecated special members 
would be a great idea. I'm not too sure where to start looking and how much of 
Sema is exposed to clang-tidy though.


http://reviews.llvm.org/D16376



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

Re: [PATCH] D15539: [libcxxabi] Reducing stack usage of test

[Marshall Clow via cfe-commits]

mclow.lists added a comment.

> Any objections to using the original sizes, but constructing the objects at 
> global scope?


I think that should work.


http://reviews.llvm.org/D15539



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

Re: [PATCH] D13704: [Fix] Allow implicit conversions of the address of overloadable functions in C + docs update

[George Burgess IV via cfe-commits]

george.burgess.iv updated this revision to Diff 48111.
george.burgess.iv added a comment.

- Reworded docs update
- Added support for `reinterpret_cast`s of overloaded functions in both C and 
C++
- Added general facility in `Sema` to query if an overloaded expression can 
resolve to being not-overloaded on its own (e.g. if it's an address-of function 
expression *and* it's the only addressable overload with the given name)

I made it generally available because there's a problem that this patch doesn't 
fix (will submit as separate phabricator review), and I suspect that this new 
functionality will be useful for solving that problem. Namely, the problem is 
template argument deduction (joy):

  template  int foo(Fn);
  
  void bar();
  void bar(int) __attribute__((enable_if(0, "")));
  int a = foo(bar); // cannot deduce `Fn` because `bar` is an overload.


http://reviews.llvm.org/D13704

Files:
  include/clang/Basic/AttrDocs.td
  include/clang/Sema/Sema.h
  lib/Sema/SemaCast.cpp
  lib/Sema/SemaOverload.cpp
  test/CodeGen/overloadable.c
  test/Sema/overloadable.c
  test/Sema/pass-object-size.c
  test/SemaCXX/enable_if.cpp

Index: test/SemaCXX/enable_if.cpp
===
--- test/SemaCXX/enable_if.cpp
+++ test/SemaCXX/enable_if.cpp
@@ -253,3 +253,96 @@
 a = &noOvlNoCandidate; // expected-error{{cannot take address of function 'noOvlNoCandidate' becuase it has one or more non-tautological enable_if conditions}}
   }
 }
+
+namespace casting {
+using VoidFnTy = void (*)();
+
+void foo(void *c) __attribute__((enable_if(0, "")));
+void foo(int *c) __attribute__((enable_if(c, "")));
+void foo(char *c) __attribute__((enable_if(1, "")));
+
+void testIt() {
+  auto A = reinterpret_cast(foo);
+  auto AAmp = reinterpret_cast(&foo);
+
+  using VoidFooTy = void (*)(void *);
+  auto B = reinterpret_cast(foo);
+  auto BAmp = reinterpret_cast(&foo);
+
+  using IntFooTy = void (*)(int *);
+  auto C = reinterpret_cast(foo);
+  auto CAmp = reinterpret_cast(&foo);
+
+  using CharFooTy = void (*)(void *);
+  auto D = reinterpret_cast(foo);
+  auto DAmp = reinterpret_cast(&foo);
+}
+
+void testItCStyle() {
+  auto A = (VoidFnTy)foo;
+  auto AAmp = (VoidFnTy)&foo;
+
+  using VoidFooTy = void (*)(void *);
+  auto B = (VoidFooTy)foo;
+  auto BAmp = (VoidFooTy)&foo;
+
+  using IntFooTy = void (*)(int *);
+  auto C = (IntFooTy)foo;
+  auto CAmp = (IntFooTy)&foo;
+
+  using CharFooTy = void (*)(void *);
+  auto D = (CharFooTy)foo;
+  auto DAmp = (CharFooTy)&foo;
+}
+}
+
+namespace casting_templates {
+template  void foo(T) {} // expected-note 4 {{candidate function}}
+
+void foo(int *c) __attribute__((enable_if(c, ""))); //expected-note 4 {{candidate function}}
+void foo(char *c) __attribute__((enable_if(c, ""))); //expected-note 4 {{candidate function}}
+
+void testIt() {
+  using IntFooTy = void (*)(int *);
+  auto A = reinterpret_cast(foo); // expected-error{{reinterpret_cast cannot resolve overloaded function 'foo' to type}}
+  auto ARef = reinterpret_cast(&foo); // expected-error{{reinterpret_cast cannot resolve overloaded function 'foo' to type}}
+  auto AExplicit = reinterpret_cast(foo);
+
+  using CharFooTy = void (*)(char *);
+  auto B = reinterpret_cast(foo); // expected-error{{reinterpret_cast cannot resolve overloaded function 'foo' to type}}
+  auto BRef = reinterpret_cast(&foo); // expected-error{{reinterpret_cast cannot resolve overloaded function 'foo' to type}}
+  auto BExplicit = reinterpret_cast(foo);
+}
+
+void testItCStyle() {
+  // constexpr is usable here because all of these should become static_casts.
+  using IntFooTy = void (*)(int *);
+  constexpr auto A = (IntFooTy)foo;
+  constexpr auto ARef = (IntFooTy)&foo;
+  constexpr auto AExplicit = (IntFooTy)foo;
+
+  using CharFooTy = void (*)(char *);
+  constexpr auto B = (CharFooTy)foo;
+  constexpr auto BRef = (CharFooTy)&foo;
+  constexpr auto BExplicit = (CharFooTy)foo;
+
+  static_assert(A == ARef && ARef == AExplicit, "");
+  static_assert(B == BRef && BRef == BExplicit, "");
+}
+}
+
+namespace multiple_matches {
+using NoMatchTy = void (*)();
+
+void foo(float *c); //expected-note 4 {{candidate function}}
+void foo(int *c) __attribute__((enable_if(1, ""))); //expected-note 4 {{candidate function}}
+void foo(char *c) __attribute__((enable_if(1, ""))); //expected-note 4 {{candidate function}}
+
+void testIt() {
+  auto A = reinterpret_cast(foo); // expected-error{{reinterpret_cast cannot resolve overloaded function 'foo' to type}}
+  auto ARef = reinterpret_cast(&foo); // expected-error{{reinterpret_cast cannot resolve overloaded function 'foo' to type}}
+
+  auto C = (NoMatchTy)foo; // expected-error{{address of overloaded function 'foo' does not match required type 'void ()'}}
+  auto CRef = (NoMatchTy)&foo; // expected-error{{address of overloaded function 'foo' does not match required type 'void ()'}}
+}
+}
Index: test/Sema/pass-object-size.c
=

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

[Marshall Clow via cfe-commits]

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

Let's wrap it in a MIPS ifdef for the moment, and then, post-release we can see 
if that can be relaxed.

Given that, LGTM.


http://reviews.llvm.org/D17132



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

Re: [PATCH] D15883: Add ARM EHABI-related constants to unwind.h.

[Logan Chien via cfe-commits]

logan added a comment.

In general, it looks good to me if the comments are addressed.

Sorry for not replying responsively.  Not sure why I missed the follow-up 
e-mails after @rengolin's reply.



Comment at: lib/Headers/unwind.h:61
@@ +60,3 @@
+#define _UNWIND_ARM_EHABI 0
+#endif
+

Since this is `unwind.h`, I feel that we can get a step further and use 
`__ARM_EABI_UNWINDER__` to get more compatibility to GCC's unwind.h.

Here's the change:

```
#if defined(__arm__) && !defined(__USING_SJLJ_EXCEPTIONS__) && \
!defined(__ARM_DWARF_EH__)
#define __ARM_EABI_UNWINDER__ 1
#endif
```


Comment at: lib/Headers/unwind.h:89
@@ -81,1 +88,3 @@
   _URC_NO_REASON = 0,
+#if _UNWIND_ARM_EHABI
+  _URC_OK = 0, /* used by ARM EHABI */

```
#ifdef __ARM_EABI_UNWINDER__
```


Comment at: lib/Headers/unwind.h:166
@@ -152,1 +165,3 @@
 
+#if _UNWIND_ARM_EHABI
+typedef uint32_t _Unwind_State;

```
#ifdef __ARM_EABI_UNWINDER__
```


http://reviews.llvm.org/D15883



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

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

[Ben Craig via cfe-commits]

bcraig updated this revision to Diff 48112.
bcraig added a comment.

Addressed EricWF's feedback.


http://reviews.llvm.org/D16545

Files:
  CMakeLists.txt
  test/CMakeLists.txt
  test/libcxxabi/test/config.py
  test/lit.site.cfg.in

Index: test/lit.site.cfg.in
===
--- test/lit.site.cfg.in
+++ test/lit.site.cfg.in
@@ -13,6 +13,8 @@
 config.enable_32bit = "@LLVM_BUILD_32_BITS@"
 config.target_info  = "@LIBCXXABI_TARGET_INFO@"
 config.executor = "@LIBCXXABI_EXECUTOR@"
+config.libcxxabi_shared = "@LIBCXXABI_ENABLE_SHARED@"
+config.enable_shared= "@LIBCXX_ENABLE_SHARED@"
 
 # Let the main config do the real work.
 lit_config.load_config(config, "@LIBCXXABI_SOURCE_DIR@/test/lit.cfg")
Index: test/libcxxabi/test/config.py
===
--- test/libcxxabi/test/config.py
+++ test/libcxxabi/test/config.py
@@ -63,13 +63,3 @@
 
 def configure_compile_flags_rtti(self):
 pass
-
-# TODO(ericwf): Remove this. This is a hack for OS X.
-# libc++ *should* export all of the symbols found in libc++abi on OS X.
-# For this reason LibcxxConfiguration will not link libc++abi in OS X.
-# However __cxa_throw_bad_new_array_length doesn't get exported into libc++
-# yet so we still need to explicitly link libc++abi.
-# See PR22654.
-def configure_link_flags_abi_library(self):
-self.cxx.link_flags += ['-lc++abi']
-
Index: test/CMakeLists.txt
===
--- test/CMakeLists.txt
+++ test/CMakeLists.txt
@@ -6,7 +6,12 @@
   endif()
 endmacro()
 
+if (NOT DEFINED LIBCXX_ENABLE_SHARED)
+  set(LIBCXX_ENABLE_SHARED ON)
+endif()
+
 pythonize_bool(LLVM_BUILD_32_BITS)
+pythonize_bool(LIBCXX_ENABLE_SHARED)
 pythonize_bool(LIBCXXABI_ENABLE_SHARED)
 pythonize_bool(LIBCXXABI_ENABLE_THREADS)
 pythonize_bool(LIBCXXABI_USE_LLVM_UNWINDER)
@@ -21,7 +26,12 @@
   ${CMAKE_CURRENT_BINARY_DIR}/lit.site.cfg
   @ONLY)
 
-set(LIBCXXABI_TEST_DEPS cxxabi_shared)
+if (LIBCXXABI_ENABLE_SHARED)
+  set(LIBCXXABI_TEST_DEPS cxxabi_shared)
+else()
+  set(LIBCXXABI_TEST_DEPS cxxabi_static)
+endif()
+
 if (NOT LIBCXXABI_BUILT_STANDALONE)
   list(APPEND LIBCXXABI_TEST_DEPS cxx)
 endif()
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -116,9 +116,8 @@
 option(LIBCXXABI_ENABLE_WERROR "Fail and stop if a warning is triggered." OFF)
 option(LIBCXXABI_USE_LLVM_UNWINDER "Build and use the LLVM unwinder." OFF)
 option(LIBCXXABI_ENABLE_THREADS "Build with threads enabled" ON)
-set(LIBCXXABI_GCC_TOOLCHAIN "" CACHE STRING "GCC toolchain for cross compiling.")
-set(LIBCXXABI_SYSROOT "" CACHE STRING "Sysroot for cross compiling.")
-set(LIBCXXABI_LIBCXX_LIBRARY_PATH "" CACHE STRING "The path to libc++ library.")
+set(LIBCXXABI_GCC_TOOLCHAIN "" CACHE PATH "GCC toolchain for cross compiling.")
+set(LIBCXXABI_SYSROOT "" CACHE PATH "Sysroot for cross compiling.")
 
 # Default to building a shared library so that the default options still test
 # the libc++abi that is being built. There are two problems with testing a
@@ -182,6 +181,13 @@
 set(LIBCXXABI_BINARY_DIR  ${CMAKE_CURRENT_BINARY_DIR})
 set(LIBCXXABI_LIBRARY_DIR ${CMAKE_BINARY_DIR}/lib${LIBCXXABI_LIBDIR_SUFFIX})
 
+# By default, for non-standalone builds, libcxx and libcxxabi share a library
+# directory.
+if (NOT LIBCXXABI_LIBCXX_LIBRARY_PATH)
+  set(LIBCXXABI_LIBCXX_LIBRARY_PATH "${LIBCXXABI_LIBRARY_DIR}" CACHE PATH
+  "The path to libc++ library.")
+endif ()
+
 #===
 # Setup Compiler Flags
 #===
@@ -338,14 +344,16 @@
 # soname, etc...
 add_subdirectory(src)
 
-if(NOT LIBCXXABI_ENABLE_SHARED)
-  # TODO: Fix the libc++ cmake files so that libc++abi can be statically linked.
-  # As it is now, libc++ will prefer linking against a dynamic libc++abi in the
-  # system library paths over a static libc++abi in the out directory. This
-  # would test the system library rather than the one we just built, which isn't
-  # very helpful.
-  message(WARNING "The libc++abi tests are currently only valid when "
-  "LIBCXXABI_ENABLE_SHARED is on, no check target will be "
+if (LIBCXXABI_BUILT_STANDALONE AND NOT LIBCXXABI_ENABLE_SHARED)
+  # We can't reasonably test the system C++ library with a static libc++abi.
+  # We either need to be able to replace libc++abi at run time (with a shared
+  # libc++abi), or we need to be able to replace the C++ runtime (with a non-
+  # standalone build).
+  message(WARNING "The libc++abi tests aren't valid when libc++abi is built "
+  "standalone (i.e. outside of llvm/projects/libcxxabi ) and "
+  "is built without a shared library.  Either build a sha

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

[Daniel Sanders via cfe-commits]

Thanks. I'll commit using a MIPS ifdef in the morning and merge once it's 
through the buildbots.

From: Marshall Clow [mclow.li...@gmail.com]
Sent: 16 February 2016 22:37
To: Daniel Sanders; h...@chromium.org; mclow.li...@gmail.com
Cc: cfe-commits@lists.llvm.org
Subject: Re: [PATCH] D17132: [libcxx] Fix definition of 
regex_traits::__regex_word on big-endian glibc systems

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

Let's wrap it in a MIPS ifdef for the moment, and then, post-release we can see 
if that can be relaxed.

Given that, LGTM.


http://reviews.llvm.org/D17132



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

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

[Ben Craig via cfe-commits]

bcraig updated this revision to Diff 48113.
bcraig added a comment.

Addressed EricWF's feedback (hopefully).


http://reviews.llvm.org/D16544

Files:
  test/CMakeLists.txt
  test/libcxx/test/config.py
  test/libcxx/test/target_info.py
  test/lit.site.cfg.in

Index: test/lit.site.cfg.in
===
--- test/lit.site.cfg.in
+++ test/lit.site.cfg.in
@@ -21,6 +21,7 @@
 config.executor = "@LIBCXX_EXECUTOR@"
 config.llvm_unwinder= "@LIBCXXABI_USE_LLVM_UNWINDER@"
 config.use_libatomic= "@LIBCXX_HAS_ATOMIC_LIB@"
+config.libcxxabi_shared = "@LIBCXXABI_ENABLE_SHARED@"
 
 # Let the main config do the real work.
 lit_config.load_config(config, "@LIBCXX_SOURCE_DIR@/test/lit.cfg")
Index: test/libcxx/test/target_info.py
===
--- test/libcxx/test/target_info.py
+++ test/libcxx/test/target_info.py
@@ -104,6 +104,14 @@
 env['DYLD_LIBRARY_PATH'] = ':'.join(library_paths)
 
 def allow_cxxabi_link(self):
+# libc++ *should* export all of the symbols found in libc++abi on OS X.
+# For this reason LibcxxConfiguration will not link libc++abi in OS X.
+# However __cxa_throw_bad_new_array_length doesn't get exported into
+# libc++ yet so we still need to explicitly link libc++abi when testing
+# libc++abi
+# See PR22654.
+if(self.full_config.get_lit_conf('name', '') == 'libc++abi'):
+return True
 # Don't link libc++abi explicitly on OS X because the symbols
 # should be available in libc++ directly.
 return False
@@ -162,11 +170,14 @@
 enable_threads = ('libcpp-has-no-threads' not in
   self.full_config.config.available_features)
 llvm_unwinder = self.full_config.get_lit_bool('llvm_unwinder', False)
+shared_libcxx = self.full_config.get_lit_bool('enable_shared', True)
 flags += ['-lm']
 if not llvm_unwinder:
 flags += ['-lgcc_s', '-lgcc']
 if enable_threads:
 flags += ['-lpthread']
+if not shared_libcxx:
+  flags += ['-lrt']
 flags += ['-lc']
 if llvm_unwinder:
 flags += ['-lunwind', '-ldl']
Index: test/libcxx/test/config.py
===
--- test/libcxx/test/config.py
+++ test/libcxx/test/config.py
@@ -460,7 +460,16 @@
 if libcxx_library:
 self.cxx.link_flags += [libcxx_library]
 else:
-self.cxx.link_flags += ['-lc++']
+libcxx_shared = self.get_lit_bool('enable_shared', default=True)
+if libcxx_shared:
+self.cxx.link_flags += ['-lc++']
+else:
+cxx_library_root = self.get_lit_conf('cxx_library_root')
+if cxx_library_root:
+abs_path = cxx_library_root + "/libc++.a"
+self.cxx.link_flags += [abs_path]
+else:
+self.cxx.link_flags += ['-lc++']
 
 def configure_link_flags_abi_library(self):
 cxx_abi = self.get_lit_conf('cxx_abi', 'libcxxabi')
@@ -470,7 +479,16 @@
 self.cxx.link_flags += ['-lsupc++']
 elif cxx_abi == 'libcxxabi':
 if self.target_info.allow_cxxabi_link():
-self.cxx.link_flags += ['-lc++abi']
+libcxxabi_shared = self.get_lit_bool('libcxxabi_shared', default=True)
+if libcxxabi_shared:
+self.cxx.link_flags += ['-lc++abi']
+else:
+cxxabi_library_root = self.get_lit_conf('abi_library_path')
+if cxxabi_library_root:
+abs_path = cxxabi_library_root + "/libc++abi.a"
+self.cxx.link_flags += [abs_path]
+else:
+self.cxx.link_flags += ['-lc++abi']
 elif cxx_abi == 'libcxxrt':
 self.cxx.link_flags += ['-lcxxrt']
 elif cxx_abi == 'none':
Index: test/CMakeLists.txt
===
--- test/CMakeLists.txt
+++ test/CMakeLists.txt
@@ -14,6 +14,7 @@
 pythonize_bool(LIBCXX_ENABLE_SHARED)
 pythonize_bool(LIBCXX_BUILD_32_BITS)
 pythonize_bool(LIBCXX_GENERATE_COVERAGE)
+pythonize_bool(LIBCXXABI_ENABLE_SHARED)
 pythonize_bool(LIBCXXABI_USE_LLVM_UNWINDER)
 pythonize_bool(LIBCXX_HAS_ATOMIC_LIB)
 
@@ -23,6 +24,13 @@
   set(LIBCXX_CXX_ABI_LIBNAME "none")
 endif()
 
+# By default, for non-standalone builds, libcxx and libcxxabi share a library
+# directory.
+if (NOT LIBCXX_CXX_ABI_LIBRARY_PATH)
+  set(LIBCXX_CXX_ABI_LIBRARY_PATH "${LIBCXX_LIBRARY_DIR}" CACHE PATH
+  "The path to libc++abi library.")
+endif()
+
 set(LIBCXX_TARGET_INFO "libcxx.test.target_info.LocalTI" CACHE STRING
 "TargetInfo to use when setting up test environment.")
 set(LIBCX

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

[Ben Craig via cfe-commits]

bcraig marked 6 inline comments as done.
bcraig added a comment.

http://reviews.llvm.org/D16544



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

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

[Ben Craig via cfe-commits]

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

http://reviews.llvm.org/D16545



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

Re: [PATCH] D15539: [libcxxabi] Reducing stack usage of test

[Ben Craig via cfe-commits]

bcraig added a comment.

So does this latest revision get the check-mark of approval?


http://reviews.llvm.org/D15539



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

Re: [PATCH] D16552: Let clang not error out on `const std::vector empty_vec; ` with libstdc++5.3.

[Nico Weber via cfe-commits]

thakis updated this revision to Diff 48115.
thakis added a comment.

Ok, that was just a bug. Now all libstdc++5.3 cases I tried build. Still not 
production-quality, but the overall direction won't change. If you want to 
comment on that, please do, else I'll ping this again after I've cleaned it up.


http://reviews.llvm.org/D16552

Files:
  lib/Sema/SemaInit.cpp
  test/CXX/dcl.decl/dcl.fct.def/dcl.fct.def.default/p2.cpp
  test/CXX/dcl.decl/dcl.init/p6.cpp
  test/SemaCXX/attr-selectany.cpp
  test/SemaCXX/constexpr-value-init.cpp
  test/SemaCXX/cxx0x-cursory-default-delete.cpp
  test/SemaCXX/illegal-member-initialization.cpp

Index: test/SemaCXX/illegal-member-initialization.cpp
===
--- test/SemaCXX/illegal-member-initialization.cpp
+++ test/SemaCXX/illegal-member-initialization.cpp
@@ -7,6 +7,7 @@
 };
 
 struct B {
+  int field;
 };
 
 struct X {
Index: test/SemaCXX/cxx0x-cursory-default-delete.cpp
===
--- test/SemaCXX/cxx0x-cursory-default-delete.cpp
+++ test/SemaCXX/cxx0x-cursory-default-delete.cpp
@@ -11,6 +11,7 @@
   non_const_copy& operator = (non_const_copy&) &;
   non_const_copy& operator = (non_const_copy&) &&;
   non_const_copy() = default; // expected-note {{not viable}}
+  int uninit_field;
 };
 non_const_copy::non_const_copy(non_const_copy&) = default; // expected-note {{not viable}}
 non_const_copy& non_const_copy::operator = (non_const_copy&) & = default; // expected-note {{not viable}}
@@ -30,6 +31,59 @@
   ncc = cncc; // expected-error {{no viable overloaded}}
 };
 
+struct no_fields { };
+struct all_init {
+  int a = 0;
+  int b = 0;
+};
+struct some_init {
+  int a = 0;
+  int b;
+  int c = 0;
+};
+struct some_init_def {
+  some_init_def() = default;
+  int a = 0;
+  int b;
+  int c = 0;
+};
+struct some_init_ctor {
+  some_init_ctor();
+  int a = 0;
+  int b;
+  int c = 0;
+};
+struct sub_some_init : public some_init_def { };
+struct sub_some_init_ctor : public some_init_def {
+  sub_some_init_ctor();
+};
+struct sub_some_init_ctor2 : public some_init_ctor {
+};
+struct some_init_container {
+  some_init_def sid;
+};
+struct some_init_container_ctor {
+  some_init_container_ctor();
+  some_init_def sid;
+};
+struct no_fields_container {
+  no_fields nf;
+};
+
+void constobjs() {
+  const no_fields nf; // ok
+  const all_init ai; // ok
+  const some_init si; // expected-error {{default initialization of an object of const type 'const some_init' without a user-provided default constructor}}
+  const some_init_def sid; // expected-error {{default initialization of an object of const type 'const some_init_def' without a user-provided default constructor}}
+  const some_init_ctor sic; // ok
+  const sub_some_init ssi; // expected-error {{default initialization of an object of const type 'const sub_some_init' without a user-provided default constructor}}
+  const sub_some_init_ctor ssic; // ok
+  const sub_some_init_ctor2 ssic2; // ok
+  const some_init_container sicon; // expected-error {{default initialization of an object of const type 'const some_init_container' without a user-provided default constructor}}
+  const some_init_container_ctor siconc; // ok
+  const no_fields_container nfc; // ok
+}
+
 struct non_const_derived : non_const_copy {
   non_const_derived(const non_const_derived&) = default; // expected-error {{requires it to be non-const}}
   non_const_derived& operator =(non_const_derived&) = default;
Index: test/SemaCXX/constexpr-value-init.cpp
===
--- test/SemaCXX/constexpr-value-init.cpp
+++ test/SemaCXX/constexpr-value-init.cpp
@@ -14,7 +14,7 @@
   constexpr A a; // expected-error {{constant expression}} expected-note {{in call to 'A()'}}
 }
 
-constexpr B b1; // expected-error {{without a user-provided default constructor}}
+constexpr B b1; // ok
 constexpr B b2 = B(); // ok
 static_assert(b2.a.a == 1, "");
 static_assert(b2.a.b == 2, "");
Index: test/SemaCXX/attr-selectany.cpp
===
--- test/SemaCXX/attr-selectany.cpp
+++ test/SemaCXX/attr-selectany.cpp
@@ -39,7 +39,9 @@
 // The D3D11 headers do something like this.  MSVC doesn't error on this at
 // all, even without the __declspec(selectany), in violation of the standard.
 // We fall back to a warning for selectany to accept headers.
-struct SomeStruct {};
+struct SomeStruct {
+  int foo;
+};
 extern const __declspec(selectany) SomeStruct some_struct; // expected-warning {{default initialization of an object of const type 'const SomeStruct' without a user-provided default constructor is a Microsoft extension}}
 
 // It should be possible to redeclare variables that were defined
Index: test/CXX/dcl.decl/dcl.init/p6.cpp
===
--- test/CXX/dcl.decl/dcl.init/p6.cpp
+++ test/CXX/dcl.decl/dcl.init/p6.cpp
@@ -4,8 +4,

Re: [PATCH] D16552: Let clang not error out on `const std::vector empty_vec; ` with libstdc++5.3.

[Richard Smith via cfe-commits]

rsmith added a comment.

The direction here looks fine to me.



Comment at: lib/Sema/SemaInit.cpp:369
@@ +368,3 @@
+   ND = dyn_cast(ND->getParent())) {
+if (S.getStdNamespace()->InEnclosingNamespaceSetOf(ND))
+  return true;

I wonder if this recursion through non-inline namespaces is really warranted; 
can we replace the call to this function with `R->isInStdNamespace()`?


Comment at: lib/Sema/SemaInit.cpp:434-435
@@ -424,10 +433,4 @@
 SemaRef.SourceMgr.isInSystemHeader(CtorDecl->getLocation())) {
-  bool IsInStd = false;
-  for (NamespaceDecl *ND = dyn_cast(R->getDeclContext());
-   ND && !IsInStd; ND = dyn_cast(ND->getParent())) {
-if (SemaRef.getStdNamespace()->InEnclosingNamespaceSetOf(ND))
-  IsInStd = true;
-  }
-
-  if (IsInStd && llvm::StringSwitch(R->getName()) 
+  if (IsContainedInNamespaceStd(SemaRef, R) &&
+  llvm::StringSwitch(R->getName())
   .Cases("basic_string", "deque", "forward_list", true)

(Please commit this separately if you still want to make this change.)


http://reviews.llvm.org/D16552



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

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

[Richard Smith via cfe-commits]

On Tue, Feb 16, 2016 at 1:48 PM, H.J. Lu  wrote:
> On Tue, Feb 16, 2016 at 1:45 PM, Richard Smith  wrote:
>> On Tue, Feb 16, 2016 at 1:21 PM, H.J. Lu  wrote:
>>> On Tue, Feb 16, 2016 at 1:15 PM, Richard Smith  
>>> wrote:
 On Tue, Feb 16, 2016 at 1:10 PM, H.J. Lu  wrote:
> On Tue, Feb 16, 2016 at 1:02 PM, Richard Smith  
> wrote:
>> On Tue, Feb 16, 2016 at 12:25 PM, H.J. Lu  wrote:
>>> On Tue, Feb 16, 2016 at 12:22 PM, Richard Smith  
>>> wrote:
 On Tue, Feb 16, 2016 at 10:24 AM, H.J. Lu  wrote:
>
> On Fri, Feb 12, 2016 at 11:39 AM, H.J. Lu  wrote:
> > On Fri, Feb 12, 2016 at 6:58 AM, Matthijs van Duin
> >  wrote:
> >> On 11 February 2016 at 16:31, H.J. Lu  wrote:
> >>> struct A {
> >>> static void foo (void) ();
> >>> static int xxx;
> >>> };
> >>
> >> What about it? It's an empty struct.  (And it declares a function 
> >> and
> >> a variable in the namespace of A, which however do not have any
> >> relevant impact here.)
> >>
> >
> > Thanks for all the feedbacks.  Here is the new proposal:
> >
> > 1. "empty type".  An empty type is a trivially-copyable aggregate
> > occupying zero bytes (excluding any padding).
> > 2. No memory slot nor register should be used to pass or return an 
> > object
> > of empty type.
> >
> > Footnote: Array of empty type can only passed by reference in C/C++.
> >
>
> I updated intel386, x86-64 and IA MCU psABIs:
>
> https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI
>
> to specify:
>
> Empty type is defined as a trivially-copyable aggregate occupying 
> zero bytes
> (excluding any padding).

 I think this is now extremely unclear. Does an empty struct in C++
 occupy zero bytes? sizeof applied to it will produce at least 1.
>>>
>>> Can it be considered as padding?
>>
>> Perhaps, but I would contend that that's unclear in at least some
>> cases (when the class is used as the type of a member, ...). What
>> about this case:
>>
>>   struct X { unsigned : 15; };
>>
>> Is that empty or not? Do we have a formal definition somewhere of what
>> does, and does not, count as padding?
>
> How about this?
>
> Empty type is defined as a trivially-copyable aggregate occupying zero 
> bytes
> (excluding any padding or contributing zero bytes to the size of derived
> classes in C++).
>
> This will cover
>
> struct dummy0
> {
>   void bar (void);
> };
> struct dummy1
> {
>   void foo (void);
> };
> struct dummy : dummy0, dummy1 { };
>
> But not
>
> struct dummy0
> {
> };
> struct dummy1
> {
>   unsigned : 15;
> };
> struct dummy : dummy0, dummy1
> {
> };

 Why not? That looks empty to me. The ABI will classify the
 corresponding eightbyte as NO_CLASS, as it has no members, so it
 should not be passed.
>>>
>>> Do you have a wording to describe it?
>>
>> Yes, something like what you had before was fine:
>>
>>   "empty type". An empty type is a type where it and all of its
>> subobjects (recursively) are of class, structure, union, or array
>> type.
>>
>> Or, if you think it makes the intent clearer, reverse the sense:
>>
>>   A type is non-empty if it or any subobject (recursively) is of any
>> type other than class, structure, union, or array type.
>
> Does the above cover
>
> struct dummy0
> {
>   void bar (void);
> };
> struct dummy1
> {
>   void foo (void);
> };
> struct dummy : dummy0, dummy1 { };

Yes

>> If you like, you could add notes that a parameter type is never an
>> array type, and that unnamed bit-fields are not subobjects, but they
>> seem redundant given the wording of the relevant standards. (You don't
>> need to say anything about "POD for the purpose of layout", or
>> destructors, or whatever else, because the C++ ABI only delegates to
>> the C psABI for cases that are valid to pass in registers from a C++
>> language semantics point of view.)
>
>
>
> --
> H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[H.J. Lu via cfe-commits]

On Tue, Feb 16, 2016 at 3:36 PM, Richard Smith  wrote:
> On Tue, Feb 16, 2016 at 1:48 PM, H.J. Lu  wrote:
>> On Tue, Feb 16, 2016 at 1:45 PM, Richard Smith  wrote:
>>> On Tue, Feb 16, 2016 at 1:21 PM, H.J. Lu  wrote:
 On Tue, Feb 16, 2016 at 1:15 PM, Richard Smith  
 wrote:
> On Tue, Feb 16, 2016 at 1:10 PM, H.J. Lu  wrote:
>> On Tue, Feb 16, 2016 at 1:02 PM, Richard Smith  
>> wrote:
>>> On Tue, Feb 16, 2016 at 12:25 PM, H.J. Lu  wrote:
 On Tue, Feb 16, 2016 at 12:22 PM, Richard Smith 
  wrote:
> On Tue, Feb 16, 2016 at 10:24 AM, H.J. Lu  wrote:
>>
>> On Fri, Feb 12, 2016 at 11:39 AM, H.J. Lu  
>> wrote:
>> > On Fri, Feb 12, 2016 at 6:58 AM, Matthijs van Duin
>> >  wrote:
>> >> On 11 February 2016 at 16:31, H.J. Lu  wrote:
>> >>> struct A {
>> >>> static void foo (void) ();
>> >>> static int xxx;
>> >>> };
>> >>
>> >> What about it? It's an empty struct.  (And it declares a function 
>> >> and
>> >> a variable in the namespace of A, which however do not have any
>> >> relevant impact here.)
>> >>
>> >
>> > Thanks for all the feedbacks.  Here is the new proposal:
>> >
>> > 1. "empty type".  An empty type is a trivially-copyable aggregate
>> > occupying zero bytes (excluding any padding).
>> > 2. No memory slot nor register should be used to pass or return an 
>> > object
>> > of empty type.
>> >
>> > Footnote: Array of empty type can only passed by reference in 
>> > C/C++.
>> >
>>
>> I updated intel386, x86-64 and IA MCU psABIs:
>>
>> https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI
>>
>> to specify:
>>
>> Empty type is defined as a trivially-copyable aggregate occupying 
>> zero bytes
>> (excluding any padding).
>
> I think this is now extremely unclear. Does an empty struct in C++
> occupy zero bytes? sizeof applied to it will produce at least 1.

 Can it be considered as padding?
>>>
>>> Perhaps, but I would contend that that's unclear in at least some
>>> cases (when the class is used as the type of a member, ...). What
>>> about this case:
>>>
>>>   struct X { unsigned : 15; };
>>>
>>> Is that empty or not? Do we have a formal definition somewhere of what
>>> does, and does not, count as padding?
>>
>> How about this?
>>
>> Empty type is defined as a trivially-copyable aggregate occupying zero 
>> bytes
>> (excluding any padding or contributing zero bytes to the size of derived
>> classes in C++).
>>
>> This will cover
>>
>> struct dummy0
>> {
>>   void bar (void);
>> };
>> struct dummy1
>> {
>>   void foo (void);
>> };
>> struct dummy : dummy0, dummy1 { };
>>
>> But not
>>
>> struct dummy0
>> {
>> };
>> struct dummy1
>> {
>>   unsigned : 15;
>> };
>> struct dummy : dummy0, dummy1
>> {
>> };
>
> Why not? That looks empty to me. The ABI will classify the
> corresponding eightbyte as NO_CLASS, as it has no members, so it
> should not be passed.

 Do you have a wording to describe it?
>>>
>>> Yes, something like what you had before was fine:
>>>
>>>   "empty type". An empty type is a type where it and all of its
>>> subobjects (recursively) are of class, structure, union, or array
>>> type.
>>>
>>> Or, if you think it makes the intent clearer, reverse the sense:
>>>
>>>   A type is non-empty if it or any subobject (recursively) is of any
>>> type other than class, structure, union, or array type.
>>
>> Does the above cover
>>
>> struct dummy0
>> {
>>   void bar (void);
>> };
>> struct dummy1
>> {
>>   void foo (void);
>> };
>> struct dummy : dummy0, dummy1 { };
>
> Yes
>

Here is the new definition:

An empty type is a type where it and all of its subobjects (recursively)
are of class, structure, union, or array type.  No memory slot nor register
should be used to pass or return an object of empty type.

Footnote: Array of empty type can only passed by reference in C and C++.


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

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

[Jacques Pienaar via cfe-commits]

jpienaar updated the summary for this revision.
jpienaar updated this revision to Diff 48119.
jpienaar marked an inline comment as done.
jpienaar added a comment.
Herald added a subscriber: joker.eph.

Move mregparm check to Tools.cpp and correct triple used in test.


http://reviews.llvm.org/D17002

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

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

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

[Jacques Pienaar via cfe-commits]

jpienaar added inline comments.


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

eliben wrote:
> why wasm triple?
Fixed, thanks.


http://reviews.llvm.org/D17002



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

r261034 - Improve diagnostics for ill-formed literal operator declarations.

[Richard Smith via cfe-commits]

Author: rsmith
Date: Tue Feb 16 18:04:04 2016
New Revision: 261034

URL: http://llvm.org/viewvc/llvm-project?rev=261034&view=rev
Log:
Improve diagnostics for ill-formed literal operator declarations.

Patch by Erik Pilkington!

Modified:
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/lib/Sema/SemaDeclCXX.cpp
cfe/trunk/test/CXX/over/over.oper/over.literal/p5.cpp
cfe/trunk/test/CXX/over/over.oper/over.literal/p8.cpp
cfe/trunk/test/SemaCXX/literal-operators.cpp

Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=261034&r1=261033&r2=261034&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Tue Feb 16 18:04:04 
2016
@@ -6886,9 +6886,16 @@ def err_literal_operator_id_outside_name
   "non-namespace scope '%0' cannot have a literal operator member">;
 def err_literal_operator_default_argument : Error<
   "literal operator cannot have a default argument">;
-// FIXME: This diagnostic sucks
-def err_literal_operator_params : Error<
-  "parameter declaration for literal operator %0 is not valid">;
+def err_literal_operator_bad_param_count : Error<
+  "non-template literal operator must have one or two parameters">;
+def err_literal_operator_invalid_param : Error<
+  "parameter of literal operator must have type 'unsigned long long', 'long 
double', 'char', 'wchar_t', 'char16_t', 'char32_t', or 'const char *'">;
+def err_literal_operator_param : Error<
+  "invalid literal operator parameter type %0, did you mean %1?">;
+def err_literal_operator_template_with_params : Error<
+  "literal operator template cannot have any parameters">;
+def err_literal_operator_template : Error<
+  "template parameter list for literal operator must be either 'char...' or 
'typename T, T...'">;
 def err_literal_operator_extern_c : Error<
   "literal operator must have C++ linkage">;
 def ext_string_literal_operator_template : ExtWarn<

Modified: cfe/trunk/lib/Sema/SemaDeclCXX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclCXX.cpp?rev=261034&r1=261033&r2=261034&view=diff
==
--- cfe/trunk/lib/Sema/SemaDeclCXX.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDeclCXX.cpp Tue Feb 16 18:04:04 2016
@@ -11765,6 +11765,49 @@ bool Sema::CheckOverloadedOperatorDeclar
   return false;
 }
 
+static bool
+checkLiteralOperatorTemplateParameterList(Sema &SemaRef,
+  FunctionTemplateDecl *TpDecl) {
+  TemplateParameterList *TemplateParams = TpDecl->getTemplateParameters();
+
+  // Must have one or two template parameters.
+  if (TemplateParams->size() == 1) {
+NonTypeTemplateParmDecl *PmDecl =
+dyn_cast(TemplateParams->getParam(0));
+
+// The template parameter must be a char parameter pack.
+if (PmDecl && PmDecl->isTemplateParameterPack() &&
+SemaRef.Context.hasSameType(PmDecl->getType(), SemaRef.Context.CharTy))
+  return false;
+
+  } else if (TemplateParams->size() == 2) {
+TemplateTypeParmDecl *PmType =
+dyn_cast(TemplateParams->getParam(0));
+NonTypeTemplateParmDecl *PmArgs =
+dyn_cast(TemplateParams->getParam(1));
+
+// The second template parameter must be a parameter pack with the
+// first template parameter as its type.
+if (PmType && PmArgs && !PmType->isTemplateParameterPack() &&
+PmArgs->isTemplateParameterPack()) {
+  const TemplateTypeParmType *TArgs =
+  PmArgs->getType()->getAs();
+  if (TArgs && TArgs->getDepth() == PmType->getDepth() &&
+  TArgs->getIndex() == PmType->getIndex()) {
+if (SemaRef.ActiveTemplateInstantiations.empty())
+  SemaRef.Diag(TpDecl->getLocation(),
+   diag::ext_string_literal_operator_template);
+return false;
+  }
+}
+  }
+
+  SemaRef.Diag(TpDecl->getTemplateParameters()->getSourceRange().getBegin(),
+   diag::err_literal_operator_template)
+  << TpDecl->getTemplateParameters()->getSourceRange();
+  return true;
+}
+
 /// CheckLiteralOperatorDeclaration - Check whether the declaration
 /// of this literal operator function is well-formed. If so, returns
 /// false; otherwise, emits appropriate diagnostics and returns true.
@@ -11780,10 +11823,9 @@ bool Sema::CheckLiteralOperatorDeclarati
 return true;
   }
 
-  bool Valid = false;
-
   // This might be the definition of a literal operator template.
   FunctionTemplateDecl *TpDecl = FnDecl->getDescribedFunctionTemplate();
+
   // This might be a specialization of a literal operator template.
   if (!TpDecl)
 TpDecl = FnDecl->getPrimaryTemplate();
@@ -11792,101 +11834,117 @@ bool Sema::CheckLiteralOperatorDeclarati
   // template  type operator "" name() a