Re: [PATCH] D19804: Make clang-format cleaner remove redundant commas in list and redundant colon in constructor initializer.

[Daniel Jasper via cfe-commits]

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

Looks good :-).


http://reviews.llvm.org/D19804



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

Re: [PATCH] D19829: [scan-build] fix dead store warnings emitted on clang code base

[Apelete Seketeli via cfe-commits]

apelete updated this revision to Diff 57560.
apelete added a comment.

[scan-build] fix dead store warnings emitted on clang code base

Changes since last revision:

- lib/Sema/SemaLookup.cpp: remove changes since they were already applied 
upstream,
- lib/Sema/SemaExpr.cpp: move 'IsDereference' and 'NextIsDereference' variables 
into the code block where they are used.


http://reviews.llvm.org/D19829

Files:
  lib/Sema/SemaDeclCXX.cpp
  lib/Sema/SemaExpr.cpp
  lib/Sema/SemaTemplate.cpp

Index: lib/Sema/SemaTemplate.cpp
===
--- lib/Sema/SemaTemplate.cpp
+++ lib/Sema/SemaTemplate.cpp
@@ -6248,8 +6248,6 @@
 SourceRange(TemplateParams->getTemplateLoc(),
 TemplateParams->getRAngleLoc()))
 << SourceRange(LAngleLoc, RAngleLoc);
-else
-  isExplicitSpecialization = true;
   } else {
 assert(TUK == TUK_Friend && "should have a 'template<>' for this decl");
   }
Index: lib/Sema/SemaExpr.cpp
===
--- lib/Sema/SemaExpr.cpp
+++ lib/Sema/SemaExpr.cpp
@@ -9692,16 +9692,16 @@
 
   // Track if the current expression is the result of a derefence, and if the
   // next checked expression is the result of a derefence.
+  // These variables are only updated when processing MemberExpr
+  // chains in the loop below.
   bool IsDereference = false;
   bool NextIsDereference = false;
 
   // Loop to process MemberExpr chains.
   while (true) {
-IsDereference = NextIsDereference;
-NextIsDereference = false;
-
 E = E->IgnoreParenImpCasts();
 if (const MemberExpr *ME = dyn_cast(E)) {
+  IsDereference = NextIsDereference;
   NextIsDereference = ME->isArrow();
   const ValueDecl *VD = ME->getMemberDecl();
   if (const FieldDecl *Field = dyn_cast(VD)) {
Index: lib/Sema/SemaDeclCXX.cpp
===
--- lib/Sema/SemaDeclCXX.cpp
+++ lib/Sema/SemaDeclCXX.cpp
@@ -12470,6 +12470,7 @@
   Diag(TemplateParams->getTemplateLoc(), diag::err_template_tag_noparams)
 << TypeWithKeyword::getTagTypeKindName(Kind) << Name;
   isExplicitSpecialization = true;
+  (void) isExplicitSpecialization;
 }
   }
 


Index: lib/Sema/SemaTemplate.cpp
===
--- lib/Sema/SemaTemplate.cpp
+++ lib/Sema/SemaTemplate.cpp
@@ -6248,8 +6248,6 @@
 SourceRange(TemplateParams->getTemplateLoc(),
 TemplateParams->getRAngleLoc()))
 << SourceRange(LAngleLoc, RAngleLoc);
-else
-  isExplicitSpecialization = true;
   } else {
 assert(TUK == TUK_Friend && "should have a 'template<>' for this decl");
   }
Index: lib/Sema/SemaExpr.cpp
===
--- lib/Sema/SemaExpr.cpp
+++ lib/Sema/SemaExpr.cpp
@@ -9692,16 +9692,16 @@
 
   // Track if the current expression is the result of a derefence, and if the
   // next checked expression is the result of a derefence.
+  // These variables are only updated when processing MemberExpr
+  // chains in the loop below.
   bool IsDereference = false;
   bool NextIsDereference = false;
 
   // Loop to process MemberExpr chains.
   while (true) {
-IsDereference = NextIsDereference;
-NextIsDereference = false;
-
 E = E->IgnoreParenImpCasts();
 if (const MemberExpr *ME = dyn_cast(E)) {
+  IsDereference = NextIsDereference;
   NextIsDereference = ME->isArrow();
   const ValueDecl *VD = ME->getMemberDecl();
   if (const FieldDecl *Field = dyn_cast(VD)) {
Index: lib/Sema/SemaDeclCXX.cpp
===
--- lib/Sema/SemaDeclCXX.cpp
+++ lib/Sema/SemaDeclCXX.cpp
@@ -12470,6 +12470,7 @@
   Diag(TemplateParams->getTemplateLoc(), diag::err_template_tag_noparams)
 << TypeWithKeyword::getTagTypeKindName(Kind) << Name;
   isExplicitSpecialization = true;
+  (void) isExplicitSpecialization;
 }
   }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D20345: [Mips] Finetuning MIPS32 Android default variants

[Simon Atanasyan via cfe-commits]

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

LGTM


http://reviews.llvm.org/D20345



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

[PATCH] D20349: Fix a clang bug in lambda capture of 'this'

[Taewook Oh via cfe-commits]

twoh created this revision.
twoh added reviewers: faisalv, rsmith.
twoh added a subscriber: cfe-commits.

(This is a fix for Bug 27797 https://llvm.org/bugs/show_bug.cgi?id=27797).

Currently when RebuildLambdaScopeInfo() function in lib/Sema/SemaDecl.cpp 
observes lambda capturing 'this', it calls Sema::getCurrentThisType() to get 
the type of 'this'. However, clang (revision 269789) crashes with an assertion 
failure inside Sema::getCurrentThisType() if template instantiation creates 
nested lambdas. Inside, Sema::getCurrentThisType(), there is an assertion 
saying that getCurLambda() never returns nullptr, but nest lambdas created by 
template instantiation makes getCurLambda() returns nullptr. 

Actually, even without the assertion failure, calling 
Sema::getCurrentThisType() from RebuildLambdaScopeInfo() seems wrong. When 
there are nested lambdas, what is required from Sema::getCurrentThisType() is a 
type of 'this' for nesting lambda, while what is supposed to be returned from 
Sema::getCurrentThisType() is a type of 'this' for nested lambda.

This patch addresses this issue and makes RebuildLambdaScopeInfo() compute the 
correct 'this' type. 

http://reviews.llvm.org/D20349

Files:
  lib/Sema/SemaDecl.cpp

Index: lib/Sema/SemaDecl.cpp
===
--- lib/Sema/SemaDecl.cpp
+++ lib/Sema/SemaDecl.cpp
@@ -11109,8 +11109,16 @@
   CaptureType, /*Expr*/ nullptr);
 
 } else if (C.capturesThis()) {
+  QualType ThisTy = CallOperator->getThisType(S.Context);
+  QualType BaseTy = ThisTy->getPointeeType();
+  if (C.getCaptureKind() == LCK_StarThis &&
+  CallOperator->isConst() &&
+  !BaseTy.isConstQualified()) {
+BaseTy.addConst();
+ThisTy = S.Context.getPointerType(BaseTy);
+  }
   LSI->addThisCapture(/*Nested*/ false, C.getLocation(),
-  S.getCurrentThisType(), /*Expr*/ nullptr,
+  ThisTy, /*Expr*/ nullptr,
   C.getCaptureKind() == LCK_StarThis);
 } else {
   LSI->addVLATypeCapture(C.getLocation(), I->getType());


Index: lib/Sema/SemaDecl.cpp
===
--- lib/Sema/SemaDecl.cpp
+++ lib/Sema/SemaDecl.cpp
@@ -11109,8 +11109,16 @@
   CaptureType, /*Expr*/ nullptr);
 
 } else if (C.capturesThis()) {
+  QualType ThisTy = CallOperator->getThisType(S.Context);
+  QualType BaseTy = ThisTy->getPointeeType();
+  if (C.getCaptureKind() == LCK_StarThis &&
+  CallOperator->isConst() &&
+  !BaseTy.isConstQualified()) {
+BaseTy.addConst();
+ThisTy = S.Context.getPointerType(BaseTy);
+  }
   LSI->addThisCapture(/*Nested*/ false, C.getLocation(),
-  S.getCurrentThisType(), /*Expr*/ nullptr,
+  ThisTy, /*Expr*/ nullptr,
   C.getCaptureKind() == LCK_StarThis);
 } else {
   LSI->addVLATypeCapture(C.getLocation(), I->getType());
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r269879 - [Sema, CodeGen] Remove comment from SemaChecking about a builtin_shufflevector form that it doesn't support. Remove CodeGen support for the same form since it could never have been used due

[Craig Topper via cfe-commits]

Author: ctopper
Date: Tue May 17 23:11:25 2016
New Revision: 269879

URL: http://llvm.org/viewvc/llvm-project?rev=269879=rev
Log:
[Sema,CodeGen] Remove comment from SemaChecking about a builtin_shufflevector 
form that it doesn't support. Remove CodeGen support for the same form since it 
could never have been used due to the missing support in Sema.

I couldn't find any documentation that this form existed either. Nor is there 
documentation for one of the remaining two forms, but there is a testcase that 
uses it.

Modified:
cfe/trunk/lib/CodeGen/CGExprScalar.cpp
cfe/trunk/lib/Sema/SemaChecking.cpp

Modified: cfe/trunk/lib/CodeGen/CGExprScalar.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGExprScalar.cpp?rev=269879=269878=269879=diff
==
--- cfe/trunk/lib/CodeGen/CGExprScalar.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGExprScalar.cpp Tue May 17 23:11:25 2016
@@ -984,8 +984,7 @@ Value *ScalarExprEmitter::VisitExpr(Expr
 
 Value *ScalarExprEmitter::VisitShuffleVectorExpr(ShuffleVectorExpr *E) {
   // Vector Mask Case
-  if (E->getNumSubExprs() == 2 ||
-  (E->getNumSubExprs() == 3 && E->getExpr(2)->getType()->isVectorType())) {
+  if (E->getNumSubExprs() == 2) {
 Value *LHS = CGF.EmitScalarExpr(E->getExpr(0));
 Value *RHS = CGF.EmitScalarExpr(E->getExpr(1));
 Value *Mask;
@@ -993,22 +992,7 @@ Value *ScalarExprEmitter::VisitShuffleVe
 llvm::VectorType *LTy = cast(LHS->getType());
 unsigned LHSElts = LTy->getNumElements();
 
-if (E->getNumSubExprs() == 3) {
-  Mask = CGF.EmitScalarExpr(E->getExpr(2));
-
-  // Shuffle LHS & RHS into one input vector.
-  SmallVector concat;
-  for (unsigned i = 0; i != LHSElts; ++i) {
-concat.push_back(Builder.getInt32(2*i));
-concat.push_back(Builder.getInt32(2*i+1));
-  }
-
-  Value* CV = llvm::ConstantVector::get(concat);
-  LHS = Builder.CreateShuffleVector(LHS, RHS, CV, "concat");
-  LHSElts *= 2;
-} else {
-  Mask = RHS;
-}
+Mask = RHS;
 
 llvm::VectorType *MTy = cast(Mask->getType());
 

Modified: cfe/trunk/lib/Sema/SemaChecking.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaChecking.cpp?rev=269879=269878=269879=diff
==
--- cfe/trunk/lib/Sema/SemaChecking.cpp (original)
+++ cfe/trunk/lib/Sema/SemaChecking.cpp Tue May 17 23:11:25 2016
@@ -3136,8 +3136,7 @@ ExprResult Sema::SemaBuiltinShuffleVecto
 
   // Determine which of the following types of shufflevector we're checking:
   // 1) unary, vector mask: (lhs, mask)
-  // 2) binary, vector mask: (lhs, rhs, mask)
-  // 3) binary, scalar mask: (lhs, rhs, index, ..., index)
+  // 2) binary, scalar mask: (lhs, rhs, index, ..., index)
   QualType resType = TheCall->getArg(0)->getType();
   unsigned numElements = 0;
 


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

r269878 - [X86] Add immediate range checks for many of the builtins.

[Craig Topper via cfe-commits]

Author: ctopper
Date: Tue May 17 22:18:12 2016
New Revision: 269878

URL: http://llvm.org/viewvc/llvm-project?rev=269878=rev
Log:
[X86] Add immediate range checks for many of the builtins.

This time allow -128 to 255 for builtins that use a char type immediate."

Modified:
cfe/trunk/include/clang/Basic/BuiltinsX86.def
cfe/trunk/lib/Sema/SemaChecking.cpp
cfe/trunk/test/CodeGen/avx512vl-builtins.c

Modified: cfe/trunk/include/clang/Basic/BuiltinsX86.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/BuiltinsX86.def?rev=269878=269877=269878=diff
==
--- cfe/trunk/include/clang/Basic/BuiltinsX86.def (original)
+++ cfe/trunk/include/clang/Basic/BuiltinsX86.def Tue May 17 22:18:12 2016
@@ -368,7 +368,7 @@ TARGET_BUILTIN(__builtin_ia32_monitor, "
 TARGET_BUILTIN(__builtin_ia32_mwait, "vUiUi", "", "sse3")
 TARGET_BUILTIN(__builtin_ia32_lddqu, "V16ccC*", "", "sse3")
 
-TARGET_BUILTIN(__builtin_ia32_palignr128, "V16cV16cV16cIc", "", "ssse3")
+TARGET_BUILTIN(__builtin_ia32_palignr128, "V16cV16cV16cIi", "", "ssse3")
 
 TARGET_BUILTIN(__builtin_ia32_insertps128, "V4fV4fV4fIc", "", "sse4.1")
 TARGET_BUILTIN(__builtin_ia32_pblendvb128, "V16cV16cV16cV16c", "", "sse4.1")
@@ -537,7 +537,7 @@ TARGET_BUILTIN(__builtin_ia32_paddusb256
 TARGET_BUILTIN(__builtin_ia32_paddusw256, "V16sV16sV16s", "", "avx2")
 TARGET_BUILTIN(__builtin_ia32_psubusb256, "V32cV32cV32c", "", "avx2")
 TARGET_BUILTIN(__builtin_ia32_psubusw256, "V16sV16sV16s", "", "avx2")
-TARGET_BUILTIN(__builtin_ia32_palignr256, "V32cV32cV32cIc", "", "avx2")
+TARGET_BUILTIN(__builtin_ia32_palignr256, "V32cV32cV32cIi", "", "avx2")
 TARGET_BUILTIN(__builtin_ia32_pavgb256, "V32cV32cV32c", "", "avx2")
 TARGET_BUILTIN(__builtin_ia32_pavgw256, "V16sV16sV16s", "", "avx2")
 TARGET_BUILTIN(__builtin_ia32_pblendvb256, "V32cV32cV32cV32c", "", "avx2")

Modified: cfe/trunk/lib/Sema/SemaChecking.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaChecking.cpp?rev=269878=269877=269878=diff
==
--- cfe/trunk/lib/Sema/SemaChecking.cpp (original)
+++ cfe/trunk/lib/Sema/SemaChecking.cpp Tue May 17 22:18:12 2016
@@ -1315,7 +1315,7 @@ static bool SemaBuiltinCpuSupports(Sema
 }
 
 bool Sema::CheckX86BuiltinFunctionCall(unsigned BuiltinID, CallExpr *TheCall) {
-  unsigned i = 0, l = 0, u = 0;
+  int i = 0, l = 0, u = 0;
   switch (BuiltinID) {
   default:
 return false;
@@ -1323,23 +1323,52 @@ bool Sema::CheckX86BuiltinFunctionCall(u
 return SemaBuiltinCpuSupports(*this, TheCall);
   case X86::BI__builtin_ms_va_start:
 return SemaBuiltinMSVAStart(TheCall);
+  case X86::BI__builtin_ia32_extractf64x4_mask:
+  case X86::BI__builtin_ia32_extracti64x4_mask:
+  case X86::BI__builtin_ia32_extractf32x8_mask:
+  case X86::BI__builtin_ia32_extracti32x8_mask:
+  case X86::BI__builtin_ia32_extractf64x2_256_mask:
+  case X86::BI__builtin_ia32_extracti64x2_256_mask:
+  case X86::BI__builtin_ia32_extractf32x4_256_mask:
+  case X86::BI__builtin_ia32_extracti32x4_256_mask:
+i = 1; l = 0; u = 1;
+break;
   case X86::BI_mm_prefetch:
-i = 1;
-l = 0;
-u = 3;
+  case X86::BI__builtin_ia32_extractf32x4_mask:
+  case X86::BI__builtin_ia32_extracti32x4_mask:
+  case X86::BI__builtin_ia32_vpermilpd_mask:
+  case X86::BI__builtin_ia32_vpermilps_mask:
+  case X86::BI__builtin_ia32_extractf64x2_512_mask:
+  case X86::BI__builtin_ia32_extracti64x2_512_mask:
+i = 1; l = 0; u = 3;
+break;
+  case X86::BI__builtin_ia32_insertf32x8_mask:
+  case X86::BI__builtin_ia32_inserti32x8_mask:
+  case X86::BI__builtin_ia32_insertf64x4_mask:
+  case X86::BI__builtin_ia32_inserti64x4_mask:
+  case X86::BI__builtin_ia32_insertf64x2_256_mask:
+  case X86::BI__builtin_ia32_inserti64x2_256_mask:
+  case X86::BI__builtin_ia32_insertf32x4_256_mask:
+  case X86::BI__builtin_ia32_inserti32x4_256_mask:
+i = 2; l = 0; u = 1;
 break;
   case X86::BI__builtin_ia32_sha1rnds4:
-i = 2;
-l = 0;
-u = 3;
+  case X86::BI__builtin_ia32_shuf_f32x4_256_mask:
+  case X86::BI__builtin_ia32_shuf_f64x2_256_mask:
+  case X86::BI__builtin_ia32_shuf_i32x4_256_mask:
+  case X86::BI__builtin_ia32_shuf_i64x2_256_mask:
+  case X86::BI__builtin_ia32_shufpd128_mask:
+  case X86::BI__builtin_ia32_insertf64x2_512_mask:
+  case X86::BI__builtin_ia32_inserti64x2_512_mask:
+  case X86::BI__builtin_ia32_insertf32x4_mask:
+  case X86::BI__builtin_ia32_inserti32x4_mask:
+i = 2; l = 0; u = 3;
 break;
   case X86::BI__builtin_ia32_vpermil2pd:
   case X86::BI__builtin_ia32_vpermil2pd256:
   case X86::BI__builtin_ia32_vpermil2ps:
   case X86::BI__builtin_ia32_vpermil2ps256:
-i = 3;
-l = 0;
-u = 3;
+i = 3; l = 0; u = 3;
 break;
   case X86::BI__builtin_ia32_cmpb128_mask:
   case X86::BI__builtin_ia32_cmpw128_mask:
@@ -1365,23 +1394,36 @@ bool Sema::CheckX86BuiltinFunctionCall(u
   case 

Re: [PATCH] D20325: Add ARM cdp intrinsics

[Tim Northover via cfe-commits]

On 17 May 2016 at 10:32, Renato Golin  wrote:
> I don't think a small future ACLE builtin is on the same league as a whole 
> new back-end. :)

Well yes, it's probably got orders of magnitude less bugs than the
backend for a start.

> Nor I think that having this when the docs are public, rather than now, will 
> affect users in any way.

True. It's an extremely niche feature.

> It's been our stance for a long time to require docs to approve changes, 
> however small. I don't want to relax that which I think is a good constraint, 
> not for such a seemly irrelevant issue.

The only place I've seen that policy in play is with asm aliases
(which have a habit of getting documented nowhere) and even there we
generally grudgingly accept promises to document.

Generally we're far more relaxed as long as a specification is on the
way. We're up to to v8.2 in LLVM proper already, and I don't think
even the v8.1 specification is public (all I can find is a blog
announcing it).

> Or, maybe I am mistaken, and this is really that important... is it?

Goodness no! The entire coprocessor instruction space was
deprecated/reclaimed in v8 as far as I'm aware. But since I don't
think timing matters particularly either way and ARM themselves are
the ones who will be supporting the majority of these users, it's
pretty harmless for us to fall in with their desired schedules.



Well, that's how I view these kinds of things anyway.

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

Re: [PATCH] D18575: [clang-tidy] New checker to replace deprecated throw() specifications

[don hinton via cfe-commits]

hintonda updated this revision to Diff 57555.
hintonda added a comment.

- Added another test.


http://reviews.llvm.org/D18575

Files:
  clang-tidy/modernize/CMakeLists.txt
  clang-tidy/modernize/ModernizeTidyModule.cpp
  clang-tidy/modernize/UseNoexceptCheck.cpp
  clang-tidy/modernize/UseNoexceptCheck.h
  clang-tidy/modernize/UseOverrideCheck.cpp
  clang-tidy/utils/LexerUtils.cpp
  clang-tidy/utils/LexerUtils.h
  docs/ReleaseNotes.rst
  docs/clang-tidy/checks/modernize-use-noexcept.rst
  test/clang-tidy/modernize-use-noexcept-macro.cpp
  test/clang-tidy/modernize-use-noexcept.cpp

Index: test/clang-tidy/modernize-use-noexcept.cpp
===
--- /dev/null
+++ test/clang-tidy/modernize-use-noexcept.cpp
@@ -0,0 +1,43 @@
+// RUN: %check_clang_tidy %s modernize-use-noexcept %t -- \
+// RUN:   -- -std=c++11
+
+class A {};
+class B {};
+
+void foo() throw();
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: function 'foo' uses dynamic exception specification 'throw()' [modernize-use-noexcept]
+// CHECK-FIXES: void foo() noexcept;
+
+void bar() throw(...);
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: function 'bar' uses dynamic exception specification 'throw(...)' [modernize-use-noexcept]
+// CHECK-FIXES: void bar() noexcept(false);
+
+void foobar() throw(A, B)
+{}
+// CHECK-MESSAGES: :[[@LINE-2]]:6: warning: function 'foobar' uses dynamic exception specification 'throw(A, B)' [modernize-use-noexcept]
+// CHECK-FIXES: void foobar() noexcept(false)
+
+void baz(int = (throw A(), 0)) throw(A, B) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: function 'baz' uses dynamic exception specification 'throw(A, B)' [modernize-use-noexcept]
+// CHECK-FIXES: void baz(int = (throw A(), 0)) noexcept(false) {}
+
+void f(void (*fp)(void) throw()) throw(char);
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: function 'f' uses dynamic exception specification 'throw()' [modernize-use-noexcept]
+// CHECK-MESSAGES: :[[@LINE-2]]:6: warning: function 'f' uses dynamic exception specification 'throw(char)' [modernize-use-noexcept]
+// CHECK-FIXES: void f(void (*fp)(void) noexcept) noexcept(false);
+
+void g(void (*fp)(void) throw());
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: function 'g' uses dynamic exception specification 'throw()' [modernize-use-noexcept]
+// CHECK-FIXES: void g(void (*fp)(void) noexcept);
+
+void j() throw(int(int) throw(void(void) throw(int)));
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: function 'j' uses dynamic exception specification 'throw(int(int) throw(void(void) throw(int)))' [modernize-use-noexcept]
+// CHECK-FIXES: void j() noexcept(false);
+
+void k() throw(int(int));
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: function 'k' uses dynamic exception specification 'throw(int(int))' [modernize-use-noexcept]
+// CHECK-FIXES: void k() noexcept(false);
+
+// Should not trigger a replacement.
+void titi() noexcept {}
+void toto() noexcept(true) {}
Index: test/clang-tidy/modernize-use-noexcept-macro.cpp
===
--- /dev/null
+++ test/clang-tidy/modernize-use-noexcept-macro.cpp
@@ -0,0 +1,24 @@
+// RUN: %check_clang_tidy %s modernize-use-noexcept %t -- \
+// RUN:   -config="{CheckOptions: [{key: modernize-use-noexcept.ReplacementString, value: 'NOEXCEPT'}]}" \
+// RUN:   -- -std=c++11
+
+// Example definition of NOEXCEPT -- simplified test to see if noexcept is supported. 
+#if (__has_feature(cxx_noexcept))
+#define NOEXCEPT noexcept
+#else
+#define NOEXCEPT throw()
+#endif
+
+void bar() throw() {}
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: function 'bar' uses dynamic exception specification 'throw()' [modernize-use-noexcept]
+// CHECK-FIXES: void bar() NOEXCEPT {}
+
+// Should not trigger a FixItHint, since macros only support noexcept, and this
+// case throws.
+class A {};
+class B {};
+void foobar() throw(A, B);
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: function 'foobar' uses dynamic exception specification 'throw(A, B)' [modernize-use-noexcept]
+
+// Should not trigger a replacement.
+void foo() noexcept(true);
Index: docs/clang-tidy/checks/modernize-use-noexcept.rst
===
--- /dev/null
+++ docs/clang-tidy/checks/modernize-use-noexcept.rst
@@ -0,0 +1,55 @@
+.. title:: clang-tidy - modernize-use-noexcept
+
+modernize-use-noexcept
+==
+
+The check converts dynamic exception specifications, e.g., ``throw()``,
+``throw([,...])``, or ``throw(...)`` to ``noexcept``, ``noexcept(false)``,
+or a user defined macro.
+
+Example
+---
+
+.. code-block:: c++
+
+  void foo() throw();
+	void bar() throw(int) {}
+
+transforms to:
+
+.. code-block:: c++
+
+  void foo() noexcept;
+	void bar() noexcept(false) {}
+
+
+User defined macros
+---
+
+By default this check will only replace ``throw()`` with ``noexcept``,
+and ``throw([,...])`` or ``throw(...)`` with
+``noexcept(false)``.  Additionally, users can also use

Re: [PATCH] D20283: Add ras/noras flag to enable/disable RAS in clang

[Tim Northover via cfe-commits]

t.p.northover added a subscriber: t.p.northover.
t.p.northover accepted this revision.
t.p.northover added a reviewer: t.p.northover.
t.p.northover added a comment.
This revision is now accepted and ready to land.

Looks pretty straightforward, go for it.

Tim.


http://reviews.llvm.org/D20283



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

Re: [PATCH] D18575: [clang-tidy] New checker to replace deprecated throw() specifications

[don hinton via cfe-commits]

hintonda updated this revision to Diff 57547.
hintonda added a comment.

- First cut on a simple parser for decls.

Successfully parses all the examples I've been given so far.  Please
help me break it.


http://reviews.llvm.org/D18575

Files:
  clang-tidy/modernize/CMakeLists.txt
  clang-tidy/modernize/ModernizeTidyModule.cpp
  clang-tidy/modernize/UseNoexceptCheck.cpp
  clang-tidy/modernize/UseNoexceptCheck.h
  clang-tidy/modernize/UseOverrideCheck.cpp
  clang-tidy/utils/LexerUtils.cpp
  clang-tidy/utils/LexerUtils.h
  docs/ReleaseNotes.rst
  docs/clang-tidy/checks/modernize-use-noexcept.rst
  test/clang-tidy/modernize-use-noexcept-macro.cpp
  test/clang-tidy/modernize-use-noexcept.cpp

Index: test/clang-tidy/modernize-use-noexcept.cpp
===
--- /dev/null
+++ test/clang-tidy/modernize-use-noexcept.cpp
@@ -0,0 +1,39 @@
+// RUN: %check_clang_tidy %s modernize-use-noexcept %t -- \
+// RUN:   -- -std=c++11
+
+class A {};
+class B {};
+
+void foo() throw();
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: function 'foo' uses dynamic exception specification 'throw()' [modernize-use-noexcept]
+// CHECK-FIXES: void foo() noexcept;
+
+void bar() throw(...);
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: function 'bar' uses dynamic exception specification 'throw(...)' [modernize-use-noexcept]
+// CHECK-FIXES: void bar() noexcept(false);
+
+void foobar() throw(A, B)
+{}
+// CHECK-MESSAGES: :[[@LINE-2]]:6: warning: function 'foobar' uses dynamic exception specification 'throw(A, B)' [modernize-use-noexcept]
+// CHECK-FIXES: void foobar() noexcept(false)
+
+void f(void (*fp)(void) throw()) throw(char);
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: function 'f' uses dynamic exception specification 'throw()' [modernize-use-noexcept]
+// CHECK-MESSAGES: :[[@LINE-2]]:6: warning: function 'f' uses dynamic exception specification 'throw(char)' [modernize-use-noexcept]
+// CHECK-FIXES: void f(void (*fp)(void) noexcept) noexcept(false);
+
+void g(void (*fp)(void) throw());
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: function 'g' uses dynamic exception specification 'throw()' [modernize-use-noexcept]
+// CHECK-FIXES: void g(void (*fp)(void) noexcept);
+
+void j() throw(int(int) throw(void(void) throw(int)));
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: function 'j' uses dynamic exception specification 'throw(int(int) throw(void(void) throw(int)))' [modernize-use-noexcept]
+// CHECK-FIXES: void j() noexcept(false);
+
+void k() throw(int(int));
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: function 'k' uses dynamic exception specification 'throw(int(int))' [modernize-use-noexcept]
+// CHECK-FIXES: void k() noexcept(false);
+
+// Should not trigger a replacement.
+void titi() noexcept {}
+void toto() noexcept(true) {}
Index: test/clang-tidy/modernize-use-noexcept-macro.cpp
===
--- /dev/null
+++ test/clang-tidy/modernize-use-noexcept-macro.cpp
@@ -0,0 +1,24 @@
+// RUN: %check_clang_tidy %s modernize-use-noexcept %t -- \
+// RUN:   -config="{CheckOptions: [{key: modernize-use-noexcept.ReplacementString, value: 'NOEXCEPT'}]}" \
+// RUN:   -- -std=c++11
+
+// Example definition of NOEXCEPT -- simplified test to see if noexcept is supported. 
+#if (__has_feature(cxx_noexcept))
+#define NOEXCEPT noexcept
+#else
+#define NOEXCEPT throw()
+#endif
+
+void bar() throw() {}
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: function 'bar' uses dynamic exception specification 'throw()' [modernize-use-noexcept]
+// CHECK-FIXES: void bar() NOEXCEPT {}
+
+// Should not trigger a FixItHint, since macros only support noexcept, and this
+// case throws.
+class A {};
+class B {};
+void foobar() throw(A, B);
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: function 'foobar' uses dynamic exception specification 'throw(A, B)' [modernize-use-noexcept]
+
+// Should not trigger a replacement.
+void foo() noexcept(true);
Index: docs/clang-tidy/checks/modernize-use-noexcept.rst
===
--- /dev/null
+++ docs/clang-tidy/checks/modernize-use-noexcept.rst
@@ -0,0 +1,55 @@
+.. title:: clang-tidy - modernize-use-noexcept
+
+modernize-use-noexcept
+==
+
+The check converts dynamic exception specifications, e.g., ``throw()``,
+``throw([,...])``, or ``throw(...)`` to ``noexcept``, ``noexcept(false)``,
+or a user defined macro.
+
+Example
+---
+
+.. code-block:: c++
+
+  void foo() throw();
+	void bar() throw(int) {}
+
+transforms to:
+
+.. code-block:: c++
+
+  void foo() noexcept;
+	void bar() noexcept(false) {}
+
+
+User defined macros
+---
+
+By default this check will only replace ``throw()`` with ``noexcept``,
+and ``throw([,...])`` or ``throw(...)`` with
+``noexcept(false)``.  Additionally, users can also use
+:option:`ReplacementString` to specify a macro to use instead of
+``noexcept``.  This is useful when maintaining source code that must
+be 

RE: [PATCH] D19567: PR21823: 'nodebug' attribute on global/static variables

[Robinson, Paul via cfe-commits]

About to be away for a week, but I will take this up (and the other one) when I 
get back.
--paulr

From: David Blaikie [mailto:dblai...@gmail.com]
Sent: Tuesday, May 17, 2016 3:05 PM
To: reviews+d19567+public+1ee0c82c0824b...@reviews.llvm.org; David Blaikie
Cc: Robinson, Paul; Aaron Ballman; Adrian Prantl; cfe-commits
Subject: Re: [PATCH] D19567: PR21823: 'nodebug' attribute on global/static 
variables

ping

On Mon, May 2, 2016 at 11:51 AM, David Blaikie via cfe-commits 
> wrote:
dblaikie added a comment.

In http://reviews.llvm.org/D19567#414906, @probinson wrote:

> Huh.  There are strange interactions here, which makes me even more nervous 
> about testing fewer cases.


Generally this sort of thing makes me more interested in testing fewer cases so 
we can see/make sure they're properly covering, as you just did by the sounds 
of it. It's hard to see if everything's really covered if there's lots of 
redundant coverage that adds noise to the test case.

> As it happens, the test as written did not exercise all 3 modified paths. 
> Because 'struct S2' had all its members marked with nodebug, none of the 
> static-member references caused debug info for the class as a whole to be 
> attempted.


Not sure I quite follow. Even without nodebug:

  struct foo { static const int x = 3; int y; };
  int i = foo::x;

doesn't produce any debug info for 'foo', x, etc. Just for 'i'.

>   I needed to add a variable of type S2 (without 'nodebug') in order to 
> exercise that path.  Once that was done, then the modification to 
> CollectRecordFields became necessary.

> Even in an unmodified compiler, "static_const_member" never 
> shows up as a DIGlobalVariable, although the other cases all do.  So, testing 
> only for DIGlobalVariable wouldn't be sufficient to show that it gets 
> suppressed by 'nodebug'.


Have you tested cases where the static member is ODR used and/or defined:

  struct foo { static const int x = 3; };
  const int foo::x; // defined
  void sink(void*);
  void use() { sink(::x); } // ODR used

I'm guessing that the out of line definition will create the DIGlobalVariable 
you're not seeing. But probably through a common codepath you've already 
corrected for.

The ODR use probably doesn't cause anything interesting to happen.

>   "static_member" shows up unless we have modified both 
> EmitGlobalVariable(VarDecl case) and CollectRecordFields, given that the test 
> actually tries to emit debug info for S2 as a whole.


I would imagine this could still boil down to: check-not DIGlobalVariable, 
check-not DIFlagStaticMember ?

But once the test is smaller/more targeted, checking the extra details of the 
member list of a composite type, etc, seems OK.

> So, the genuinely most-minimal did-this-change-do-anything test would need 
> only "static_member" and "const_global_int_def" to show that each path had 
> some effect.  This approach does not fill me with warm fuzzies, or the 
> feeling that future changes in this area will not break the intended 
> behavior.  What do you think?

> --paulr


Repository:
  rL LLVM

http://reviews.llvm.org/D19567



___
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] D20341: [CUDA] Enable fusing FP ops for CUDA by default.

[Justin Lebar via cfe-commits]

jlebar added a comment.

> But people also don't expect IEEE compliance on GPUs


Is that true?  You have a lot more experience with this than I do, but my 
observation of nvidia's hardware is that it's moved to add *more* IEEE 
compliance as it's matured.  For example, older hardware didn't support 
denormals, but newer chips do.  Surely that's in response to some users.

One of our goals with CUDA in clang is to make device code as similar as 
possible to host code.  Throwing out IEEE compliance seems counter to that goal.

I also don't see the bright line here.  Like, if we can FMA to our heart's 
content, where do we draw the line wrt IEEE compliance?  Do we turn on 
flush-denormals-to-zero by default?  Do we use approximate transcendental 
functions instead of the more accurate ones?  Do we assume floating point 
arithmetic is associative?  What is the principle that leads us to do FMAs but 
not these other optimizations?

In addition, CUDA != GPUs.  Maybe this is something to turn on by default for 
NVPTX, although I'm still pretty uncomfortable with that.  Prior art in other 
compilers is interesting, but I think it's notable that clang doesn't do this 
for any other targets (afaict?) despite the fact that gcc does.

The main argument I see for this is "nvcc does it, and people will think clang 
is slow if we don't".  That's maybe not a bad argument, but it makes me sad.  :(


http://reviews.llvm.org/D20341



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

[clang-tools-extra] r269875 - findAllSymbols: Prune unused libdeps.

[NAKAMURA Takumi via cfe-commits]

Author: chapuni
Date: Tue May 17 19:53:31 2016
New Revision: 269875

URL: http://llvm.org/viewvc/llvm-project?rev=269875=rev
Log:
findAllSymbols: Prune unused libdeps.

Modified:
clang-tools-extra/trunk/include-fixer/find-all-symbols/CMakeLists.txt

Modified: clang-tools-extra/trunk/include-fixer/find-all-symbols/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/include-fixer/find-all-symbols/CMakeLists.txt?rev=269875=269874=269875=diff
==
--- clang-tools-extra/trunk/include-fixer/find-all-symbols/CMakeLists.txt 
(original)
+++ clang-tools-extra/trunk/include-fixer/find-all-symbols/CMakeLists.txt Tue 
May 17 19:53:31 2016
@@ -11,10 +11,7 @@ add_clang_library(findAllSymbols
   clangAST
   clangASTMatchers
   clangBasic
-  clangFrontend
   clangLex
-  clangTooling
-  clangToolingCore
   )
 
 add_subdirectory(tool)


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

[clang-tools-extra] r269874 - FindAllSymbolsTests doesn't require clangToolingCore.

[NAKAMURA Takumi via cfe-commits]

Author: chapuni
Date: Tue May 17 19:53:27 2016
New Revision: 269874

URL: http://llvm.org/viewvc/llvm-project?rev=269874=rev
Log:
FindAllSymbolsTests doesn't require clangToolingCore.

Modified:

clang-tools-extra/trunk/unittests/include-fixer/find-all-symbols/CMakeLists.txt

Modified: 
clang-tools-extra/trunk/unittests/include-fixer/find-all-symbols/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/unittests/include-fixer/find-all-symbols/CMakeLists.txt?rev=269874=269873=269874=diff
==
--- 
clang-tools-extra/trunk/unittests/include-fixer/find-all-symbols/CMakeLists.txt 
(original)
+++ 
clang-tools-extra/trunk/unittests/include-fixer/find-all-symbols/CMakeLists.txt 
Tue May 17 19:53:27 2016
@@ -19,6 +19,5 @@ target_link_libraries(FindAllSymbolsTest
   clangFrontend
   clangLex
   clangTooling
-  clangToolingCore
   findAllSymbols
   )


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

[clang-tools-extra] r269873 - include-fixer: They require clangLex.

[NAKAMURA Takumi via cfe-commits]

Author: chapuni
Date: Tue May 17 19:49:16 2016
New Revision: 269873

URL: http://llvm.org/viewvc/llvm-project?rev=269873=rev
Log:
include-fixer: They require clangLex.

Modified:
clang-tools-extra/trunk/include-fixer/find-all-symbols/CMakeLists.txt
clang-tools-extra/trunk/include-fixer/find-all-symbols/tool/CMakeLists.txt

clang-tools-extra/trunk/unittests/include-fixer/find-all-symbols/CMakeLists.txt

Modified: clang-tools-extra/trunk/include-fixer/find-all-symbols/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/include-fixer/find-all-symbols/CMakeLists.txt?rev=269873=269872=269873=diff
==
--- clang-tools-extra/trunk/include-fixer/find-all-symbols/CMakeLists.txt 
(original)
+++ clang-tools-extra/trunk/include-fixer/find-all-symbols/CMakeLists.txt Tue 
May 17 19:49:16 2016
@@ -12,6 +12,7 @@ add_clang_library(findAllSymbols
   clangASTMatchers
   clangBasic
   clangFrontend
+  clangLex
   clangTooling
   clangToolingCore
   )

Modified: 
clang-tools-extra/trunk/include-fixer/find-all-symbols/tool/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/include-fixer/find-all-symbols/tool/CMakeLists.txt?rev=269873=269872=269873=diff
==
--- clang-tools-extra/trunk/include-fixer/find-all-symbols/tool/CMakeLists.txt 
(original)
+++ clang-tools-extra/trunk/include-fixer/find-all-symbols/tool/CMakeLists.txt 
Tue May 17 19:49:16 2016
@@ -7,6 +7,7 @@ target_link_libraries(find-all-symbols
   clangASTMatchers
   clangBasic
   clangFrontend
+  clangLex
   clangTooling
   findAllSymbols
   )

Modified: 
clang-tools-extra/trunk/unittests/include-fixer/find-all-symbols/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/unittests/include-fixer/find-all-symbols/CMakeLists.txt?rev=269873=269872=269873=diff
==
--- 
clang-tools-extra/trunk/unittests/include-fixer/find-all-symbols/CMakeLists.txt 
(original)
+++ 
clang-tools-extra/trunk/unittests/include-fixer/find-all-symbols/CMakeLists.txt 
Tue May 17 19:49:16 2016
@@ -17,6 +17,7 @@ target_link_libraries(FindAllSymbolsTest
   clangASTMatchers
   clangBasic
   clangFrontend
+  clangLex
   clangTooling
   clangToolingCore
   findAllSymbols


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

[PATCH] D20345: [Mips] Finetuning MIPS32 Android default variants

[Petar Jovanovic via cfe-commits]

petarj created this revision.
petarj added a reviewer: atanasyan.
petarj added a subscriber: cfe-commits.
Herald added subscribers: srhines, danalbert, tberghammer.

MIPS32 Android defaults to FPXX ("-fpxx").
MIPS32R6 Android defaults to FP64A ("-mfp64 -mno-odd-spreg").

http://reviews.llvm.org/D20345

Files:
  lib/Driver/Tools.cpp
  lib/Driver/Tools.h
  test/Driver/clang-translation.c

Index: test/Driver/clang-translation.c
===
--- test/Driver/clang-translation.c
+++ test/Driver/clang-translation.c
@@ -246,8 +246,19 @@
 // MIPSEL-ANDROID: clang
 // MIPSEL-ANDROID: "-cc1"
 // MIPSEL-ANDROID: "-target-cpu" "mips32"
+// MIPSEL-ANDROID: "-target-feature" "+fpxx"
+// MIPSEL-ANDROID: "-target-feature" "+nooddspreg"
 // MIPSEL-ANDROID: "-mfloat-abi" "hard"
 
+// RUN: %clang -target mipsel-linux-android -### -S %s -mcpu=mips32r6 2>&1 | \
+// RUN: FileCheck -check-prefix=MIPSEL-ANDROID-R6 %s
+// MIPSEL-ANDROID-R6: clang
+// MIPSEL-ANDROID-R6: "-cc1"
+// MIPSEL-ANDROID-R6: "-target-cpu" "mips32r6"
+// MIPSEL-ANDROID-R6: "-target-feature" "+fp64"
+// MIPSEL-ANDROID-R6: "-target-feature" "+nooddspreg"
+// MIPSEL-ANDROID-R6: "-mfloat-abi" "hard"
+
 // RUN: %clang -target mips64-linux-gnu -### -S %s 2>&1 | \
 // RUN: FileCheck -check-prefix=MIPS64 %s
 // MIPS64: clang
Index: lib/Driver/Tools.h
===
--- lib/Driver/Tools.h
+++ lib/Driver/Tools.h
@@ -299,6 +299,7 @@
 bool hasMipsAbiArg(const llvm::opt::ArgList , const char *Value);
 bool isUCLibc(const llvm::opt::ArgList );
 bool isNaN2008(const llvm::opt::ArgList , const llvm::Triple );
+bool isFP64ADefault(const llvm::Triple , StringRef CPUName);
 bool isFPXXDefault(const llvm::Triple , StringRef CPUName,
StringRef ABIName, mips::FloatABI FloatABI);
 bool shouldUseFPXX(const llvm::opt::ArgList , const llvm::Triple ,
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -1359,8 +1359,9 @@
   AddTargetFeature(Args, Features, options::OPT_mmsa, options::OPT_mno_msa,
"msa");
 
-  // Add the last -mfp32/-mfpxx/-mfp64 or if none are given and the ABI is O32
-  // pass -mfpxx
+  // Add the last -mfp32/-mfpxx/-mfp64, if none are given and the ABI is O32
+  // pass -mfpxx, or if none are given and fp64a is default, pass fp64 and
+  // nooddspreg.
   if (Arg *A = Args.getLastArg(options::OPT_mfp32, options::OPT_mfpxx,
options::OPT_mfp64)) {
 if (A->getOption().matches(options::OPT_mfp32))
@@ -1373,6 +1374,9 @@
   } else if (mips::shouldUseFPXX(Args, Triple, CPUName, ABIName, FloatABI)) {
 Features.push_back(Args.MakeArgString("+fpxx"));
 Features.push_back(Args.MakeArgString("+nooddspreg"));
+  } else if (mips::isFP64ADefault(Triple, CPUName)) {
+Features.push_back(Args.MakeArgString("+fp64"));
+Features.push_back(Args.MakeArgString("+nooddspreg"));
   }
 
   AddTargetFeature(Args, Features, options::OPT_mno_odd_spreg,
@@ -7030,10 +7034,21 @@
   return false;
 }
 
+bool mips::isFP64ADefault(const llvm::Triple , StringRef CPUName) {
+  if (!Triple.isAndroid())
+return false;
+
+  // Android MIPS32R6 defaults to FP64A.
+  return llvm::StringSwitch(CPUName)
+  .Case("mips32r6", true)
+  .Default(false);
+}
+
 bool mips::isFPXXDefault(const llvm::Triple , StringRef CPUName,
  StringRef ABIName, mips::FloatABI FloatABI) {
   if (Triple.getVendor() != llvm::Triple::ImaginationTechnologies &&
-  Triple.getVendor() != llvm::Triple::MipsTechnologies)
+  Triple.getVendor() != llvm::Triple::MipsTechnologies &&
+  !Triple.isAndroid())
 return false;
 
   if (ABIName != "32")


Index: test/Driver/clang-translation.c
===
--- test/Driver/clang-translation.c
+++ test/Driver/clang-translation.c
@@ -246,8 +246,19 @@
 // MIPSEL-ANDROID: clang
 // MIPSEL-ANDROID: "-cc1"
 // MIPSEL-ANDROID: "-target-cpu" "mips32"
+// MIPSEL-ANDROID: "-target-feature" "+fpxx"
+// MIPSEL-ANDROID: "-target-feature" "+nooddspreg"
 // MIPSEL-ANDROID: "-mfloat-abi" "hard"
 
+// RUN: %clang -target mipsel-linux-android -### -S %s -mcpu=mips32r6 2>&1 | \
+// RUN: FileCheck -check-prefix=MIPSEL-ANDROID-R6 %s
+// MIPSEL-ANDROID-R6: clang
+// MIPSEL-ANDROID-R6: "-cc1"
+// MIPSEL-ANDROID-R6: "-target-cpu" "mips32r6"
+// MIPSEL-ANDROID-R6: "-target-feature" "+fp64"
+// MIPSEL-ANDROID-R6: "-target-feature" "+nooddspreg"
+// MIPSEL-ANDROID-R6: "-mfloat-abi" "hard"
+
 // RUN: %clang -target mips64-linux-gnu -### -S %s 2>&1 | \
 // RUN: FileCheck -check-prefix=MIPS64 %s
 // MIPS64: clang
Index: lib/Driver/Tools.h
===
--- lib/Driver/Tools.h
+++ lib/Driver/Tools.h
@@ -299,6 +299,7 @@
 bool hasMipsAbiArg(const llvm::opt::ArgList , const char *Value);
 

[clang-tools-extra] r269870 - IncludeFixerTest.cpp: Add explicit triple for some tests. They are failing for targeting *-win32.

[NAKAMURA Takumi via cfe-commits]

Author: chapuni
Date: Tue May 17 19:20:46 2016
New Revision: 269870

URL: http://llvm.org/viewvc/llvm-project?rev=269870=rev
Log:
IncludeFixerTest.cpp: Add explicit triple for some tests. They are failing for 
targeting *-win32.

Modified:
clang-tools-extra/trunk/unittests/include-fixer/IncludeFixerTest.cpp

Modified: clang-tools-extra/trunk/unittests/include-fixer/IncludeFixerTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/unittests/include-fixer/IncludeFixerTest.cpp?rev=269870=269869=269870=diff
==
--- clang-tools-extra/trunk/unittests/include-fixer/IncludeFixerTest.cpp 
(original)
+++ clang-tools-extra/trunk/unittests/include-fixer/IncludeFixerTest.cpp Tue 
May 17 19:20:46 2016
@@ -129,9 +129,11 @@ TEST(IncludeFixer, MinimizeInclude) {
 #ifndef _WIN32
 // It doesn't pass for targeting win32. Investigating.
 TEST(IncludeFixer, NestedName) {
+  // Some tests don't pass for target *-win32.
+  std::vector args = {"-target", "x86_64-unknown-unknown"};
   EXPECT_EQ("#include \"dir/otherdir/qux.h\"\n"
 "int x = a::b::foo(0);\n",
-runIncludeFixer("int x = a::b::foo(0);\n"));
+runIncludeFixer("int x = a::b::foo(0);\n", args));
 
   // FIXME: Handle simple macros.
   EXPECT_EQ("#define FOO a::b::foo\nint x = FOO;\n",
@@ -141,7 +143,7 @@ TEST(IncludeFixer, NestedName) {
 
   EXPECT_EQ("#include \"dir/otherdir/qux.h\"\n"
 "namespace a {}\nint a = a::b::foo(0);\n",
-runIncludeFixer("namespace a {}\nint a = a::b::foo(0);\n"));
+runIncludeFixer("namespace a {}\nint a = a::b::foo(0);\n", args));
 }
 #endif
 


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

r269869 - Fix use-after-free ASan failures for modules / PCH files that deserialize abi_tag or no_sanitize attributes.

[Richard Smith via cfe-commits]

Author: rsmith
Date: Tue May 17 19:16:51 2016
New Revision: 269869

URL: http://llvm.org/viewvc/llvm-project?rev=269869=rev
Log:
Fix use-after-free ASan failures for modules / PCH files that deserialize 
abi_tag or no_sanitize attributes.

Modified:
cfe/trunk/test/PCH/attrs.c
cfe/trunk/utils/TableGen/ClangAttrEmitter.cpp

Modified: cfe/trunk/test/PCH/attrs.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/PCH/attrs.c?rev=269869=269868=269869=diff
==
--- cfe/trunk/test/PCH/attrs.c (original)
+++ cfe/trunk/test/PCH/attrs.c Tue May 17 19:16:51 2016
@@ -9,10 +9,12 @@
 #define HEADER
 
 int f(int) __attribute__((visibility("default"), overloadable));
+int g(int) __attribute__((abi_tag("foo", "bar", "baz"), no_sanitize("address", 
"memory"))); // expected-warning {{ignored}}
 
 #else
 
 double f(double); // expected-error{{overloadable}}
   // expected-note@11{{previous overload}}
+void h() { g(0); }
 
 #endif

Modified: cfe/trunk/utils/TableGen/ClangAttrEmitter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/utils/TableGen/ClangAttrEmitter.cpp?rev=269869=269868=269869=diff
==
--- cfe/trunk/utils/TableGen/ClangAttrEmitter.cpp (original)
+++ cfe/trunk/utils/TableGen/ClangAttrEmitter.cpp Tue May 17 19:16:51 2016
@@ -98,6 +98,13 @@ static std::string ReadPCHRecord(StringR
 .Default("Record[Idx++]");
 }
 
+// Get a type that is suitable for storing an object of the specified type.
+static StringRef getStorageType(StringRef type) {
+  return StringSwitch(type)
+.Case("StringRef", "std::string")
+.Default(type);
+}
+
 // Assumes that the way to get the value is SA->getname()
 static std::string WritePCHRecord(StringRef type, StringRef name) {
   return "Record." + StringSwitch(type)
@@ -644,15 +651,34 @@ namespace {
 }
 
 void writePCHReadDecls(raw_ostream ) const override {
-  OS << "  unsigned " << getLowerName() << "Size = Record[Idx++];\n";
-  OS << "  SmallVector<" << Type << ", 4> " << getLowerName()
- << ";\n";
-  OS << "  " << getLowerName() << ".reserve(" << getLowerName()
+  OS << "unsigned " << getLowerName() << "Size = Record[Idx++];\n";
+  OS << "SmallVector<" << getType() << ", 4> "
+ << getLowerName() << ";\n";
+  OS << "" << getLowerName() << ".reserve(" << getLowerName()
  << "Size);\n";
-  OS << "for (unsigned i = " << getLowerName() << "Size; i; --i)\n";
-  
+
+  // If we can't store the values in the current type (if it's something
+  // like StringRef), store them in a different type and convert the
+  // container afterwards.
+  std::string StorageType = getStorageType(getType());
+  std::string StorageName = getLowerName();
+  if (StorageType != getType()) {
+StorageName += "Storage";
+OS << "SmallVector<" << StorageType << ", 4> "
+   << StorageName << ";\n";
+OS << "" << StorageName << ".reserve(" << getLowerName()
+   << "Size);\n";
+  }
+
+  OS << "for (unsigned i = 0; i != " << getLowerName() << "Size; 
++i)\n";
   std::string read = ReadPCHRecord(Type);
-  OS << "" << getLowerName() << ".push_back(" << read << ");\n";
+  OS << "  " << StorageName << ".push_back(" << read << ");\n";
+
+  if (StorageType != getType()) {
+OS << "for (unsigned i = 0; i != " << getLowerName() << "Size; 
++i)\n";
+OS << "  " << getLowerName() << ".push_back("
+   << StorageName << "[i]);\n";
+  }
 }
 
 void writePCHReadArgs(raw_ostream ) const override {


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

Re: [PATCH] D20341: [CUDA] Enable fusing FP ops for CUDA by default.

[Artem Belevich via cfe-commits]

tra updated this revision to Diff 57541.
tra added a comment.

Added test case.

Is there a better way to test that correct options are passed to back-end?
This test resorts to checking assembly generated by back-end which is way too 
far away from what actually needs testing.


http://reviews.llvm.org/D20341

Files:
  lib/Frontend/CompilerInvocation.cpp
  test/CodeGenCUDA/fp-contract.cu

Index: test/CodeGenCUDA/fp-contract.cu
===
--- /dev/null
+++ test/CodeGenCUDA/fp-contract.cu
@@ -0,0 +1,32 @@
+// REQUIRES: x86-registered-target
+// REQUIRES: nvptx-registered-target
+
+// By default we should fuse multiply/add into fma instruction.
+// RUN: %clang_cc1 -fcuda-is-device -triple nvptx-nvidia-cuda -S \
+// RUN:   -disable-llvm-passes -o - %s | FileCheck -check-prefix ENABLED %s
+
+// Explicit -ffp-contract=fast
+// RUN: %clang_cc1 -fcuda-is-device -triple nvptx-nvidia-cuda -S \
+// RUN:   -ffp-contract=fast -disable-llvm-passes -o - %s \
+// RUN:   | FileCheck -check-prefix ENABLED %s
+
+// Explicit -ffp-contract=on -- fusing by front-end (disabled).
+// RUN: %clang_cc1 -fcuda-is-device -triple nvptx-nvidia-cuda -S \
+// RUN:   -ffp-contract=on -disable-llvm-passes -o - %s \
+// RUN:   | FileCheck -check-prefix DISABLED %s
+
+// Explicit -ffp-contract=off should disable instruction fusing.
+// RUN: %clang_cc1 -fcuda-is-device -triple nvptx-nvidia-cuda -S \
+// RUN:   -ffp-contract=off -disable-llvm-passes -o - %s \
+// RUN:   | FileCheck -check-prefix DISABLED %s
+
+
+#include "Inputs/cuda.h"
+
+__host__ __device__ float func(float a, float b, float c) { return a + b * c; }
+// ENABLED:   fma.rn.f32
+// ENABLED-NEXT:  st.param.f32
+
+// DISABLED:  mul.rn.f32
+// DISABLED-NEXT: add.rn.f32
+// DISABLED-NEXT: st.param.f32
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -2212,10 +2212,15 @@
   LangOpts.ObjCExceptions = 1;
   }
 
-  // During CUDA device-side compilation, the aux triple is the triple used for
-  // host compilation.
-  if (LangOpts.CUDA && LangOpts.CUDAIsDevice) {
-Res.getTargetOpts().HostTriple = Res.getFrontendOpts().AuxTriple;
+  if (LangOpts.CUDA) {
+// During CUDA device-side compilation, the aux triple is the
+// triple used for host compilation.
+if (LangOpts.CUDAIsDevice)
+  Res.getTargetOpts().HostTriple = Res.getFrontendOpts().AuxTriple;
+
+// Set default FP_CONTRACT to FAST.
+if (!Args.hasArg(OPT_ffp_contract))
+  Res.getCodeGenOpts().setFPContractMode(CodeGenOptions::FPC_Fast);
   }
 
   // FIXME: Override value name discarding when asan or msan is used because 
the


Index: test/CodeGenCUDA/fp-contract.cu
===
--- /dev/null
+++ test/CodeGenCUDA/fp-contract.cu
@@ -0,0 +1,32 @@
+// REQUIRES: x86-registered-target
+// REQUIRES: nvptx-registered-target
+
+// By default we should fuse multiply/add into fma instruction.
+// RUN: %clang_cc1 -fcuda-is-device -triple nvptx-nvidia-cuda -S \
+// RUN:   -disable-llvm-passes -o - %s | FileCheck -check-prefix ENABLED %s
+
+// Explicit -ffp-contract=fast
+// RUN: %clang_cc1 -fcuda-is-device -triple nvptx-nvidia-cuda -S \
+// RUN:   -ffp-contract=fast -disable-llvm-passes -o - %s \
+// RUN:   | FileCheck -check-prefix ENABLED %s
+
+// Explicit -ffp-contract=on -- fusing by front-end (disabled).
+// RUN: %clang_cc1 -fcuda-is-device -triple nvptx-nvidia-cuda -S \
+// RUN:   -ffp-contract=on -disable-llvm-passes -o - %s \
+// RUN:   | FileCheck -check-prefix DISABLED %s
+
+// Explicit -ffp-contract=off should disable instruction fusing.
+// RUN: %clang_cc1 -fcuda-is-device -triple nvptx-nvidia-cuda -S \
+// RUN:   -ffp-contract=off -disable-llvm-passes -o - %s \
+// RUN:   | FileCheck -check-prefix DISABLED %s
+
+
+#include "Inputs/cuda.h"
+
+__host__ __device__ float func(float a, float b, float c) { return a + b * c; }
+// ENABLED:   fma.rn.f32
+// ENABLED-NEXT:  st.param.f32
+
+// DISABLED:  mul.rn.f32
+// DISABLED-NEXT: add.rn.f32
+// DISABLED-NEXT: st.param.f32
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -2212,10 +2212,15 @@
   LangOpts.ObjCExceptions = 1;
   }
 
-  // During CUDA device-side compilation, the aux triple is the triple used for
-  // host compilation.
-  if (LangOpts.CUDA && LangOpts.CUDAIsDevice) {
-Res.getTargetOpts().HostTriple = Res.getFrontendOpts().AuxTriple;
+  if (LangOpts.CUDA) {
+// During CUDA device-side compilation, the aux triple is the
+// triple used for host compilation.
+if (LangOpts.CUDAIsDevice)
+  Res.getTargetOpts().HostTriple = Res.getFrontendOpts().AuxTriple;
+
+// Set default FP_CONTRACT to FAST.
+if 

Re: [PATCH] D20341: [CUDA] Enable fusing FP ops for CUDA by default.

[Artem Belevich via cfe-commits]

tra updated this revision to Diff 57540.
tra added a comment.

Changed default to -ffp-contract=fast.


http://reviews.llvm.org/D20341

Files:
  lib/Frontend/CompilerInvocation.cpp

Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -2212,10 +2212,15 @@
   LangOpts.ObjCExceptions = 1;
   }
 
-  // During CUDA device-side compilation, the aux triple is the triple used for
-  // host compilation.
-  if (LangOpts.CUDA && LangOpts.CUDAIsDevice) {
-Res.getTargetOpts().HostTriple = Res.getFrontendOpts().AuxTriple;
+  if (LangOpts.CUDA) {
+// During CUDA device-side compilation, the aux triple is the
+// triple used for host compilation.
+if (LangOpts.CUDAIsDevice)
+  Res.getTargetOpts().HostTriple = Res.getFrontendOpts().AuxTriple;
+
+// Set default FP_CONTRACT to FAST.
+if (!Args.hasArg(OPT_ffp_contract))
+  Res.getCodeGenOpts().setFPContractMode(CodeGenOptions::FPC_Fast);
   }
 
   // FIXME: Override value name discarding when asan or msan is used because 
the


Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -2212,10 +2212,15 @@
   LangOpts.ObjCExceptions = 1;
   }
 
-  // During CUDA device-side compilation, the aux triple is the triple used for
-  // host compilation.
-  if (LangOpts.CUDA && LangOpts.CUDAIsDevice) {
-Res.getTargetOpts().HostTriple = Res.getFrontendOpts().AuxTriple;
+  if (LangOpts.CUDA) {
+// During CUDA device-side compilation, the aux triple is the
+// triple used for host compilation.
+if (LangOpts.CUDAIsDevice)
+  Res.getTargetOpts().HostTriple = Res.getFrontendOpts().AuxTriple;
+
+// Set default FP_CONTRACT to FAST.
+if (!Args.hasArg(OPT_ffp_contract))
+  Res.getCodeGenOpts().setFPContractMode(CodeGenOptions::FPC_Fast);
   }
 
   // FIXME: Override value name discarding when asan or msan is used because the
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D20341: [CUDA] Enable fusing FP ops for CUDA by default.

[Artem Belevich via cfe-commits]

tra added a comment.

OK. Consensus seems to be that -ffp-contract=fast is the way to go. I'll update 
the patch.
I've just checked Steve's example with nvcc and indeed it fused mul+add.


http://reviews.llvm.org/D20341



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

Re: [PATCH] D20341: [CUDA] Enable fusing FP ops for CUDA by default.

[Hal Finkel via cfe-commits]

hfinkel added a comment.



In http://reviews.llvm.org/D20341#432525, @tra wrote:

> In http://reviews.llvm.org/D20341#432494, @hfinkel wrote:
>
> >
>
>
>
>
> > That having been said, is this change the equivalent of -ffp-contract=fast 
> > or -ffp-contract=on? I think it is the latter and we want the former (i.e. 
> > where we let the backend be as aggressive as possible *after* inlining).
>
>
> It is -ffp-contract=on. As it happens, it appears to produce better code 
> compared to -ffp-contract=fast at least on some benchmarks. Apparently 
> smaller IR (smaller number of intrinsic call instructions vs multiple 
> separate mul+add) makes job easier for straight line strength reduction pass 
> and it's able to remove more redundant calculations in unrolled loops.


That's certainly interesting, and frankly, something I don't immediately 
understand. Given that, at that level, the IR for -ffo-contract=fast is the 
same as -ffp-contract=off, this seems to point to some more-general problem 
that we should likely fix anyway.

I will say that, once templated C++ libraries become involved, the 
per-statement C rules for fusion often don't apply in enough places to be 
useful. You really need to perform the fusion after inlining. Obviously, 
however, for more-directly-programmed expressions, this concern does not apply.


http://reviews.llvm.org/D20341



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

Re: [PATCH] D20341: [CUDA] Enable fusing FP ops for CUDA by default.

[Steve Canon via cfe-commits]

scanon added a comment.

`-ffp-contract=on` obeys the semantics of C's FP_CONTRACT pragma.  In 
particular, it will not fuse:

  float m = x*y;
  float a = m + z;

Whereas you probably want that to fuse for your purposes.  `-ffp-contract=fast` 
seems more in line with your needs.


http://reviews.llvm.org/D20341



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

Re: [PATCH] D20339: Update clang for D20260

[Peter Collingbourne via cfe-commits]

pcc added inline comments.


Comment at: test/CodeGenOpenCL/constant-addr-space-globals.cl:3
@@ -2,3 +2,3 @@
 
-// CHECK: @array = addrspace({{[0-9]+}}) constant
+// CHECK: @array = local_unnamed_addr addrspace({{[0-9]+}}) constant
 __constant float array[2] = {0.0f, 1.0f};

rsmith wrote:
> Where does this come from? It doesn't look like Clang adds this, and this 
> test does not appear to enable any optimizations.
OpenCL enables optimizations by default in the frontend, see 
`getOptimizationLevel` in `lib/Frontend/CompilerInvocation.cpp`.

It does seem a little weird that we're doing this in the frontend, this should 
probably be a driver feature. I must apologise for me-from-5-years-ago who 
implemented this in r120876.

In the meantime, maybe we should be adding `-cl-opt-disable` to the OpenCL 
codegen tests.


http://reviews.llvm.org/D20339



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

Re: [PATCH] D20341: [CUDA] Enable fusing FP ops for CUDA by default.

[Artem Belevich via cfe-commits]

tra added a comment.

In http://reviews.llvm.org/D20341#432494, @hfinkel wrote:

>




> That having been said, is this change the equivalent of -ffp-contract=fast or 
> -ffp-contract=on? I think it is the latter and we want the former (i.e. where 
> we let the backend be as aggressive as possible *after* inlining).


It is -ffp-contract=on. As it happens, it appears to produce better code 
compared to -ffp-contract=fast at least on some benchmarks. Apparently smaller 
IR (smaller number of intrinsic call instructions vs multiple separate mul+add) 
makes job easier for straight line strength reduction pass and it's able to 
remove more redundant calculations in unrolled loops.


http://reviews.llvm.org/D20341



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

Re: [PATCH] D20341: [CUDA] Enable fusing FP ops for CUDA by default.

[Artem Belevich via cfe-commits]

tra added a subscriber: scanon.
tra added a comment.

Things are even more interesting. -ffp-contract=fast is *not* what this change 
does. :-)

We have two places where we can fuse FP instructions -- in clang and in LLVM 
back-end.
Clang fuses add+mul into llvm.fmuladd intrinsic if -ffp-contract=on (default) 
and DefaultFPContract=1 (which is only set for OpenCL for some reason) and 
back-end then decides whether it's profitable to emit fused operation or not. 
NVPTX does emit fmad.

Compare this to -ffp-contract=fast which actually *disables* fusing in clang 
and instead allows LLVM backend to do fusing wherever it sees fit (as opposed 
to 'fuse intrinsics only'. It may potentially fuse any suitable multiply/add 
pair, not only those vetted by front-end.

Currently there's no way to enable front-end fusing via command line, unless 
you compile OpenCL source. With this patch in place for CUDA compilation we can 
pick either no fusing, controlled fusing by front-end or more aggressive fusing 
by back-end.

Setting DefaultFPContract=1 for CUDA seems to be the least evil -- it's 
somewhat controlled in scope and gives us a way to disable fusing completely or 
make it more aggressive if it's needed.

Perhaps @scanon and @hfinkel can weigh in.


http://reviews.llvm.org/D20341



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

Re: [PATCH] D20339: Update clang for D20260

[Richard Smith via cfe-commits]

rsmith added a subscriber: rsmith.


Comment at: test/CodeGenOpenCL/constant-addr-space-globals.cl:3
@@ -2,3 +2,3 @@
 
-// CHECK: @array = addrspace({{[0-9]+}}) constant
+// CHECK: @array = local_unnamed_addr addrspace({{[0-9]+}}) constant
 __constant float array[2] = {0.0f, 1.0f};

Where does this come from? It doesn't look like Clang adds this, and this test 
does not appear to enable any optimizations.


Comment at: test/CodeGenOpenCL/str_literals.cl:8-9
@@ -7,3 +7,3 @@
 // CHECK-NOT: addrspace(3) unnamed_addr constant
-// CHECK: @x = addrspace(3) constant i8 addrspace(3)*
-// CHECK: @y = addrspace(3) constant i8 addrspace(3)*
+// CHECK: @x = local_unnamed_addr addrspace(3) constant i8 addrspace(3)*
+// CHECK: @y = local_unnamed_addr addrspace(3) constant i8 addrspace(3)*

Likewise.


Comment at: test/SemaOpenCL/extern.cl:4
@@ -3,3 +3,3 @@
 
-// CHECK: @foo = external addrspace(3) constant float
+// CHECK: @foo = external local_unnamed_addr addrspace(3) constant float
 extern constant float foo;

Likewise.


http://reviews.llvm.org/D20339



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

Re: [PATCH] D20302: Remove LazyDefinitionDataPtr and rely on getMostRecentDecl. Fixes PR27754.

[Richard Smith via cfe-commits]

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

Review comments resolved and committed as r269858.


Repository:
  rL LLVM

http://reviews.llvm.org/D20302



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

Re: [PATCH] D20341: [CUDA] Enable fusing FP ops for CUDA by default.

[Hal Finkel via cfe-commits]

hfinkel added a subscriber: hfinkel.
hfinkel added a comment.

In http://reviews.llvm.org/D20341#432461, @jlebar wrote:

> I am not sure we want this?  Although it matches nvcc, it does not match our 
> floating-point behavior for C++ in general -- it makes us non-IEEE-whatever 
> compliant by default.
>
> Although I agree that if we don't do this, lots of people are not going to 
> pass -fp-contract=fast and resultantly will think that we're slower than 
> nvcc.  There's no way to win.  :(


But people also don't expect IEEE compliance on GPUs, and also, the system 
default for forming FMAs has long been system specific. The default on IBM 
systems, for example, is generally the equivalent of -ffp-contract=fast (in 
both XLC and GCC).

That having been said, is this change the equivalent of -ffp-contract=fast or 
-ffp-contract=on? I think it is the latter and we want the former (i.e. where 
we let the backend be as aggressive as possible *after* inlining).


http://reviews.llvm.org/D20341



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

Re: r269858 - PR27754: CXXRecordDecl::data() needs to perform an update even if it's called

[Richard Smith via cfe-commits]

Forgot to mention in the commit message: this patch was collaboratively
produced by Vassil Vassilev and myself.

On Tue, May 17, 2016 at 3:44 PM, Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rsmith
> Date: Tue May 17 17:44:15 2016
> New Revision: 269858
>
> URL: http://llvm.org/viewvc/llvm-project?rev=269858=rev
> Log:
> PR27754: CXXRecordDecl::data() needs to perform an update even if it's
> called
> on a declaration that already knows the location of the DefinitionData
> object.
>
> Added:
> cfe/trunk/test/Modules/Inputs/PR27754/
> cfe/trunk/test/Modules/Inputs/PR27754/RConversionRuleParser.h
> cfe/trunk/test/Modules/Inputs/PR27754/TMetaUtils.h
> cfe/trunk/test/Modules/Inputs/PR27754/TSchemaType.h
> cfe/trunk/test/Modules/Inputs/PR27754/algobase.h
> cfe/trunk/test/Modules/Inputs/PR27754/module.modulemap
> cfe/trunk/test/Modules/pr27754.cpp
> Modified:
> cfe/trunk/include/clang/AST/DeclCXX.h
> cfe/trunk/lib/AST/DeclCXX.cpp
> cfe/trunk/lib/Serialization/ASTReaderDecl.cpp
>
> Modified: cfe/trunk/include/clang/AST/DeclCXX.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/DeclCXX.h?rev=269858=269857=269858=diff
>
> ==
> --- cfe/trunk/include/clang/AST/DeclCXX.h (original)
> +++ cfe/trunk/include/clang/AST/DeclCXX.h Tue May 17 17:44:15 2016
> @@ -257,30 +257,6 @@ public:
>TypeSourceInfo *getTypeSourceInfo() const { return BaseTypeInfo; }
>  };
>
> -/// \brief A lazy pointer to the definition data for a declaration.
> -/// FIXME: This is a little CXXRecordDecl-specific that the moment.
> -template class LazyDefinitionDataPtr {
> -  llvm::PointerUnion DataOrCanonicalDecl;
> -
> -  LazyDefinitionDataPtr update() {
> -if (Decl *Canon = DataOrCanonicalDecl.template dyn_cast()) {
> -  if (Canon->isCanonicalDecl())
> -Canon->getMostRecentDecl();
> -  else
> -// Declaration isn't canonical any more;
> -// update it and perform path compression.
> -*this = Canon->getPreviousDecl()->DefinitionData.update();
> -}
> -return *this;
> -  }
> -
> -public:
> -  LazyDefinitionDataPtr(Decl *Canon) : DataOrCanonicalDecl(Canon) {}
> -  LazyDefinitionDataPtr(T *Data) : DataOrCanonicalDecl(Data) {}
> -  T *getNotUpdated() { return DataOrCanonicalDecl.template
> dyn_cast(); }
> -  T *get() { return update().getNotUpdated(); }
> -};
> -
>  /// \brief Represents a C++ struct/union/class.
>  class CXXRecordDecl : public RecordDecl {
>
> @@ -543,11 +519,7 @@ class CXXRecordDecl : public RecordDecl
>  CXXBaseSpecifier *getVBasesSlowCase() const;
>};
>
> -  typedef LazyDefinitionDataPtr
> -  DefinitionDataPtr;
> -  friend class LazyDefinitionDataPtr DefinitionData>;
> -
> -  mutable DefinitionDataPtr DefinitionData;
> +  struct DefinitionData *DefinitionData;
>
>/// \brief Describes a C++ closure type (generated by a lambda
> expression).
>struct LambdaDefinitionData : public DefinitionData {
> @@ -610,8 +582,14 @@ class CXXRecordDecl : public RecordDecl
>
>};
>
> +  struct DefinitionData *dataPtr() const {
> +// Complete the redecl chain (if necessary).
> +getMostRecentDecl();
> +return DefinitionData;
> +  }
> +
>struct DefinitionData () const {
> -auto *DD = DefinitionData.get();
> +auto *DD = dataPtr();
>  assert(DD && "queried property of class with no definition");
>  return *DD;
>}
> @@ -619,7 +597,7 @@ class CXXRecordDecl : public RecordDecl
>struct LambdaDefinitionData () const {
>  // No update required: a merged definition cannot change any lambda
>  // properties.
> -auto *DD = DefinitionData.getNotUpdated();
> +auto *DD = DefinitionData;
>  assert(DD && DD->IsLambda && "queried lambda property of non-lambda
> class");
>  return static_cast(*DD);
>}
> @@ -696,11 +674,13 @@ public:
>}
>
>CXXRecordDecl *getDefinition() const {
> -auto *DD = DefinitionData.get();
> +// We only need an update if we don't already know which
> +// declaration is the definition.
> +auto *DD = DefinitionData ? DefinitionData : dataPtr();
>  return DD ? DD->Definition : nullptr;
>}
>
> -  bool hasDefinition() const { return DefinitionData.get(); }
> +  bool hasDefinition() const { return DefinitionData || dataPtr(); }
>
>static CXXRecordDecl *Create(const ASTContext , TagKind TK,
> DeclContext *DC,
> SourceLocation StartLoc, SourceLocation
> IdLoc,
> @@ -1044,7 +1024,7 @@ public:
>/// \brief Determine whether this class describes a lambda function
> object.
>bool isLambda() const {
>  // An update record can't turn a non-lambda into a lambda.
> -auto *DD = DefinitionData.getNotUpdated();
> +auto *DD = DefinitionData;
>  return DD && DD->IsLambda;
>

Re: [PATCH] D18575: [clang-tidy] New checker to replace deprecated throw() specifications

[Alexander Kornienko via cfe-commits]

alexfh added inline comments.


Comment at: clang-tidy/modernize/UseNoexceptCheck.cpp:39
@@ +38,3 @@
+
+  // FIXME: Add paren matching so we can parse more complex throw statements,
+  // e.g., (examples provided by Aaron Ballman):

aaron.ballman wrote:
> alexfh wrote:
> > aaron.ballman wrote:
> > > alexfh wrote:
> > > > hintonda wrote:
> > > > > aaron.ballman wrote:
> > > > > > @alexfh, what are your feelings on this FIXME? I am a bit concerned 
> > > > > > because these examples will cause the replacement range to be 
> > > > > > incorrect, which will turn working code into ill-formed code. The 
> > > > > > alternative, as I see it, is to instead properly track the 
> > > > > > exception specification source range information as part of the 
> > > > > > FunctionDecl (akin to `FunctionDecl::getReturnTypeSourceRange()`).
> > > > > Btw, I'm working on a fix I believe will handle all cases -- plan to 
> > > > > checkin later today.  However, it won't be that efficient unless I 
> > > > > can find a way to match params that contain dynamic exception 
> > > > > specifications.  If they are only legal for function pointers -- 
> > > > > which I think is the case -- that would make it easy and efficient, 
> > > > > i.e., I wouldn't have to match all FunctionDecl's with one or more 
> > > > > parameter and test them.
> > > > > 
> > > > > Is it possible to match a parameter that is a function pointer?
> > > > > The alternative, as I see it, is to instead properly track the 
> > > > > exception specification source range information as part of the 
> > > > > FunctionDecl (akin to FunctionDecl::getReturnTypeSourceRange()).
> > > > 
> > > > It's all trade-offs: adding this information to the AST allows certain 
> > > > tasks in tooling to be done easier. On the other hand, this leads to 
> > > > bloating of the AST, which can already be huge. In this specific case, 
> > > > always keeping the source range of the exception specifier might be 
> > > > wasteful, since exception specifiers are rather rare (in my world, at 
> > > > least). But there might be a way to optionally store this information, 
> > > > e.g. in the `ASTContext`. In any case, makes sense to ask Richard Smith.
> > > I am more curious as to your comfort level about committing a fixit that 
> > > we know will break working code. ;-)
> > > 
> > > As for the suggested approach, I would obviously cover that with Richard, 
> > > but I think we're going to need exception specifications more now that 
> > > they're going to be part of the type system for C++. We have 
> > > `FunctionProtoTypeLoc` for tracking this information.
> > The important question here is how frequently is this likely to happen. I 
> > guess, it depends on the codebase, but maybe you have a rough guess?
> Multiple uses of `throw` within a dynamic exception specification? Rare. 
> Paren use that doesn't match what we expect? Infrequent, but likely to 
> generate a bug report at some point depending on how often people use 
> clang-tidy to check extensive code bases that actually *use* dynamic 
> exception specifications. So my biggest concern really boils down to the fact 
> that we're assuming the first right paren we come to after a "throw" keyword 
> in a dynamic exception specification is the terminating right paren. I think 
> we need to use paren matching instead. It would be nice if we could use 
> `BalancedDelimiterTracker` to solve this, come to think of it.
Yes, tracking balanced parenthesis sequences makes sense in any case.


http://reviews.llvm.org/D18575



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

Re: [PATCH] D20341: [CUDA] Enable fusing FP ops for CUDA by default.

[Justin Lebar via cfe-commits]

jlebar added a comment.

I am not sure we want this?  Although it matches nvcc, it does not match our 
floating-point behavior for C++ in general -- it makes us non-IEEE-whatever 
compliant by default.

Although I agree that if we don't do this, lots of people are not going to pass 
-fp-contract=fast and resultantly will think that we're slower than nvcc.  
There's no way to win.  :(


http://reviews.llvm.org/D20341



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

r269858 - PR27754: CXXRecordDecl::data() needs to perform an update even if it's called

[Richard Smith via cfe-commits]

Author: rsmith
Date: Tue May 17 17:44:15 2016
New Revision: 269858

URL: http://llvm.org/viewvc/llvm-project?rev=269858=rev
Log:
PR27754: CXXRecordDecl::data() needs to perform an update even if it's called
on a declaration that already knows the location of the DefinitionData object.

Added:
cfe/trunk/test/Modules/Inputs/PR27754/
cfe/trunk/test/Modules/Inputs/PR27754/RConversionRuleParser.h
cfe/trunk/test/Modules/Inputs/PR27754/TMetaUtils.h
cfe/trunk/test/Modules/Inputs/PR27754/TSchemaType.h
cfe/trunk/test/Modules/Inputs/PR27754/algobase.h
cfe/trunk/test/Modules/Inputs/PR27754/module.modulemap
cfe/trunk/test/Modules/pr27754.cpp
Modified:
cfe/trunk/include/clang/AST/DeclCXX.h
cfe/trunk/lib/AST/DeclCXX.cpp
cfe/trunk/lib/Serialization/ASTReaderDecl.cpp

Modified: cfe/trunk/include/clang/AST/DeclCXX.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/DeclCXX.h?rev=269858=269857=269858=diff
==
--- cfe/trunk/include/clang/AST/DeclCXX.h (original)
+++ cfe/trunk/include/clang/AST/DeclCXX.h Tue May 17 17:44:15 2016
@@ -257,30 +257,6 @@ public:
   TypeSourceInfo *getTypeSourceInfo() const { return BaseTypeInfo; }
 };
 
-/// \brief A lazy pointer to the definition data for a declaration.
-/// FIXME: This is a little CXXRecordDecl-specific that the moment.
-template class LazyDefinitionDataPtr {
-  llvm::PointerUnion DataOrCanonicalDecl;
-
-  LazyDefinitionDataPtr update() {
-if (Decl *Canon = DataOrCanonicalDecl.template dyn_cast()) {
-  if (Canon->isCanonicalDecl())
-Canon->getMostRecentDecl();
-  else
-// Declaration isn't canonical any more;
-// update it and perform path compression.
-*this = Canon->getPreviousDecl()->DefinitionData.update();
-}
-return *this;
-  }
-
-public:
-  LazyDefinitionDataPtr(Decl *Canon) : DataOrCanonicalDecl(Canon) {}
-  LazyDefinitionDataPtr(T *Data) : DataOrCanonicalDecl(Data) {}
-  T *getNotUpdated() { return DataOrCanonicalDecl.template dyn_cast(); }
-  T *get() { return update().getNotUpdated(); }
-};
-
 /// \brief Represents a C++ struct/union/class.
 class CXXRecordDecl : public RecordDecl {
 
@@ -543,11 +519,7 @@ class CXXRecordDecl : public RecordDecl
 CXXBaseSpecifier *getVBasesSlowCase() const;
   };
 
-  typedef LazyDefinitionDataPtr
-  DefinitionDataPtr;
-  friend class LazyDefinitionDataPtr;
-
-  mutable DefinitionDataPtr DefinitionData;
+  struct DefinitionData *DefinitionData;
 
   /// \brief Describes a C++ closure type (generated by a lambda expression).
   struct LambdaDefinitionData : public DefinitionData {
@@ -610,8 +582,14 @@ class CXXRecordDecl : public RecordDecl

   };
 
+  struct DefinitionData *dataPtr() const {
+// Complete the redecl chain (if necessary).
+getMostRecentDecl();
+return DefinitionData;
+  }
+
   struct DefinitionData () const {
-auto *DD = DefinitionData.get();
+auto *DD = dataPtr();
 assert(DD && "queried property of class with no definition");
 return *DD;
   }
@@ -619,7 +597,7 @@ class CXXRecordDecl : public RecordDecl
   struct LambdaDefinitionData () const {
 // No update required: a merged definition cannot change any lambda
 // properties.
-auto *DD = DefinitionData.getNotUpdated();
+auto *DD = DefinitionData;
 assert(DD && DD->IsLambda && "queried lambda property of non-lambda 
class");
 return static_cast(*DD);
   }
@@ -696,11 +674,13 @@ public:
   }
 
   CXXRecordDecl *getDefinition() const {
-auto *DD = DefinitionData.get();
+// We only need an update if we don't already know which
+// declaration is the definition.
+auto *DD = DefinitionData ? DefinitionData : dataPtr();
 return DD ? DD->Definition : nullptr;
   }
 
-  bool hasDefinition() const { return DefinitionData.get(); }
+  bool hasDefinition() const { return DefinitionData || dataPtr(); }
 
   static CXXRecordDecl *Create(const ASTContext , TagKind TK, DeclContext 
*DC,
SourceLocation StartLoc, SourceLocation IdLoc,
@@ -1044,7 +1024,7 @@ public:
   /// \brief Determine whether this class describes a lambda function object.
   bool isLambda() const {
 // An update record can't turn a non-lambda into a lambda.
-auto *DD = DefinitionData.getNotUpdated();
+auto *DD = DefinitionData;
 return DD && DD->IsLambda;
   }
 

Modified: cfe/trunk/lib/AST/DeclCXX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/DeclCXX.cpp?rev=269858=269857=269858=diff
==
--- cfe/trunk/lib/AST/DeclCXX.cpp (original)
+++ cfe/trunk/lib/AST/DeclCXX.cpp Tue May 17 17:44:15 2016
@@ -88,7 +88,7 @@ CXXRecordDecl::CXXRecordDecl(Kind K, Tag
  CXXRecordDecl *PrevDecl)
 

Re: [PATCH] D18575: [clang-tidy] New checker to replace deprecated throw() specifications

[Aaron Ballman via cfe-commits]

aaron.ballman added inline comments.


Comment at: clang-tidy/modernize/UseNoexceptCheck.cpp:39
@@ +38,3 @@
+
+  // FIXME: Add paren matching so we can parse more complex throw statements,
+  // e.g., (examples provided by Aaron Ballman):

alexfh wrote:
> aaron.ballman wrote:
> > alexfh wrote:
> > > hintonda wrote:
> > > > aaron.ballman wrote:
> > > > > @alexfh, what are your feelings on this FIXME? I am a bit concerned 
> > > > > because these examples will cause the replacement range to be 
> > > > > incorrect, which will turn working code into ill-formed code. The 
> > > > > alternative, as I see it, is to instead properly track the exception 
> > > > > specification source range information as part of the FunctionDecl 
> > > > > (akin to `FunctionDecl::getReturnTypeSourceRange()`).
> > > > Btw, I'm working on a fix I believe will handle all cases -- plan to 
> > > > checkin later today.  However, it won't be that efficient unless I can 
> > > > find a way to match params that contain dynamic exception 
> > > > specifications.  If they are only legal for function pointers -- which 
> > > > I think is the case -- that would make it easy and efficient, i.e., I 
> > > > wouldn't have to match all FunctionDecl's with one or more parameter 
> > > > and test them.
> > > > 
> > > > Is it possible to match a parameter that is a function pointer?
> > > > The alternative, as I see it, is to instead properly track the 
> > > > exception specification source range information as part of the 
> > > > FunctionDecl (akin to FunctionDecl::getReturnTypeSourceRange()).
> > > 
> > > It's all trade-offs: adding this information to the AST allows certain 
> > > tasks in tooling to be done easier. On the other hand, this leads to 
> > > bloating of the AST, which can already be huge. In this specific case, 
> > > always keeping the source range of the exception specifier might be 
> > > wasteful, since exception specifiers are rather rare (in my world, at 
> > > least). But there might be a way to optionally store this information, 
> > > e.g. in the `ASTContext`. In any case, makes sense to ask Richard Smith.
> > I am more curious as to your comfort level about committing a fixit that we 
> > know will break working code. ;-)
> > 
> > As for the suggested approach, I would obviously cover that with Richard, 
> > but I think we're going to need exception specifications more now that 
> > they're going to be part of the type system for C++. We have 
> > `FunctionProtoTypeLoc` for tracking this information.
> The important question here is how frequently is this likely to happen. I 
> guess, it depends on the codebase, but maybe you have a rough guess?
Multiple uses of `throw` within a dynamic exception specification? Rare. Paren 
use that doesn't match what we expect? Infrequent, but likely to generate a bug 
report at some point depending on how often people use clang-tidy to check 
extensive code bases that actually *use* dynamic exception specifications. So 
my biggest concern really boils down to the fact that we're assuming the first 
right paren we come to after a "throw" keyword in a dynamic exception 
specification is the terminating right paren. I think we need to use paren 
matching instead. It would be nice if we could use `BalancedDelimiterTracker` 
to solve this, come to think of it.


http://reviews.llvm.org/D18575



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

Re: r269765 - Revert "[X86] Add immediate range checks for many of the builtins."

[Craig Topper via cfe-commits]

There was an off list mail to me on this.

The 0-255 checks don't work for the builtins that take a char immediate and
char is signed. In that case the range change needs to be -128 to 127
instead of 0 to 255.

On Tue, May 17, 2016 at 3:09 PM, Sean Silva via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

>
>
> On Tue, May 17, 2016 at 7:07 AM, Filipe Cabecinhas via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: filcab
>> Date: Tue May 17 09:07:43 2016
>> New Revision: 269765
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=269765=rev
>> Log:
>> Revert "[X86] Add immediate range checks for many of the builtins."
>>
>> This reverts commit r269619.
>>
>
> In the future could you include the reason too?
>
> -- Sean Silva
>
>
>>
>> Modified:
>> cfe/trunk/lib/Sema/SemaChecking.cpp
>> cfe/trunk/test/CodeGen/avx512vl-builtins.c
>>
>> Modified: cfe/trunk/lib/Sema/SemaChecking.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaChecking.cpp?rev=269765=269764=269765=diff
>>
>> ==
>> --- cfe/trunk/lib/Sema/SemaChecking.cpp (original)
>> +++ cfe/trunk/lib/Sema/SemaChecking.cpp Tue May 17 09:07:43 2016
>> @@ -1323,52 +1323,23 @@ bool Sema::CheckX86BuiltinFunctionCall(u
>>  return SemaBuiltinCpuSupports(*this, TheCall);
>>case X86::BI__builtin_ms_va_start:
>>  return SemaBuiltinMSVAStart(TheCall);
>> -  case X86::BI__builtin_ia32_extractf64x4_mask:
>> -  case X86::BI__builtin_ia32_extracti64x4_mask:
>> -  case X86::BI__builtin_ia32_extractf32x8_mask:
>> -  case X86::BI__builtin_ia32_extracti32x8_mask:
>> -  case X86::BI__builtin_ia32_extractf64x2_256_mask:
>> -  case X86::BI__builtin_ia32_extracti64x2_256_mask:
>> -  case X86::BI__builtin_ia32_extractf32x4_256_mask:
>> -  case X86::BI__builtin_ia32_extracti32x4_256_mask:
>> -i = 1; l = 0; u = 1;
>> -break;
>>case X86::BI_mm_prefetch:
>> -  case X86::BI__builtin_ia32_extractf32x4_mask:
>> -  case X86::BI__builtin_ia32_extracti32x4_mask:
>> -  case X86::BI__builtin_ia32_vpermilpd_mask:
>> -  case X86::BI__builtin_ia32_vpermilps_mask:
>> -  case X86::BI__builtin_ia32_extractf64x2_512_mask:
>> -  case X86::BI__builtin_ia32_extracti64x2_512_mask:
>> -i = 1; l = 0; u = 3;
>> -break;
>> -  case X86::BI__builtin_ia32_insertf32x8_mask:
>> -  case X86::BI__builtin_ia32_inserti32x8_mask:
>> -  case X86::BI__builtin_ia32_insertf64x4_mask:
>> -  case X86::BI__builtin_ia32_inserti64x4_mask:
>> -  case X86::BI__builtin_ia32_insertf64x2_256_mask:
>> -  case X86::BI__builtin_ia32_inserti64x2_256_mask:
>> -  case X86::BI__builtin_ia32_insertf32x4_256_mask:
>> -  case X86::BI__builtin_ia32_inserti32x4_256_mask:
>> -i = 2; l = 0; u = 1;
>> +i = 1;
>> +l = 0;
>> +u = 3;
>>  break;
>>case X86::BI__builtin_ia32_sha1rnds4:
>> -  case X86::BI__builtin_ia32_shuf_f32x4_256_mask:
>> -  case X86::BI__builtin_ia32_shuf_f64x2_256_mask:
>> -  case X86::BI__builtin_ia32_shuf_i32x4_256_mask:
>> -  case X86::BI__builtin_ia32_shuf_i64x2_256_mask:
>> -  case X86::BI__builtin_ia32_shufpd128_mask:
>> -  case X86::BI__builtin_ia32_insertf64x2_512_mask:
>> -  case X86::BI__builtin_ia32_inserti64x2_512_mask:
>> -  case X86::BI__builtin_ia32_insertf32x4_mask:
>> -  case X86::BI__builtin_ia32_inserti32x4_mask:
>> -i = 2; l = 0; u = 3;
>> +i = 2;
>> +l = 0;
>> +u = 3;
>>  break;
>>case X86::BI__builtin_ia32_vpermil2pd:
>>case X86::BI__builtin_ia32_vpermil2pd256:
>>case X86::BI__builtin_ia32_vpermil2ps:
>>case X86::BI__builtin_ia32_vpermil2ps256:
>> -i = 3; l = 0; u = 3;
>> +i = 3;
>> +l = 0;
>> +u = 3;
>>  break;
>>case X86::BI__builtin_ia32_cmpb128_mask:
>>case X86::BI__builtin_ia32_cmpw128_mask:
>> @@ -1394,36 +1365,23 @@ bool Sema::CheckX86BuiltinFunctionCall(u
>>case X86::BI__builtin_ia32_ucmpw512_mask:
>>case X86::BI__builtin_ia32_ucmpd512_mask:
>>case X86::BI__builtin_ia32_ucmpq512_mask:
>> -  case X86::BI__builtin_ia32_vpcomub:
>> -  case X86::BI__builtin_ia32_vpcomuw:
>> -  case X86::BI__builtin_ia32_vpcomud:
>> -  case X86::BI__builtin_ia32_vpcomuq:
>> -  case X86::BI__builtin_ia32_vpcomb:
>> -  case X86::BI__builtin_ia32_vpcomw:
>> -  case X86::BI__builtin_ia32_vpcomd:
>> -  case X86::BI__builtin_ia32_vpcomq:
>> -i = 2; l = 0; u = 7;
>> +i = 2;
>> +l = 0;
>> +u = 7;
>>  break;
>>case X86::BI__builtin_ia32_roundps:
>>case X86::BI__builtin_ia32_roundpd:
>>case X86::BI__builtin_ia32_roundps256:
>>case X86::BI__builtin_ia32_roundpd256:
>> -  case X86::BI__builtin_ia32_vpermilpd256_mask:
>> -  case X86::BI__builtin_ia32_vpermilps256_mask:
>> -i = 1; l = 0; u = 15;
>> +i = 1;
>> +l = 0;
>> +u = 15;
>>  break;
>>case X86::BI__builtin_ia32_roundss:
>>case X86::BI__builtin_ia32_roundsd:
>> -  case X86::BI__builtin_ia32_rangepd128_mask:
>> -  case X86::BI__builtin_ia32_rangepd256_mask:
>> -  case 

Re: [PATCH] D18575: [clang-tidy] New checker to replace deprecated throw() specifications

[Alexander Kornienko via cfe-commits]

alexfh added inline comments.


Comment at: clang-tidy/modernize/UseNoexceptCheck.cpp:39
@@ +38,3 @@
+
+  // FIXME: Add paren matching so we can parse more complex throw statements,
+  // e.g., (examples provided by Aaron Ballman):

aaron.ballman wrote:
> alexfh wrote:
> > hintonda wrote:
> > > aaron.ballman wrote:
> > > > @alexfh, what are your feelings on this FIXME? I am a bit concerned 
> > > > because these examples will cause the replacement range to be 
> > > > incorrect, which will turn working code into ill-formed code. The 
> > > > alternative, as I see it, is to instead properly track the exception 
> > > > specification source range information as part of the FunctionDecl 
> > > > (akin to `FunctionDecl::getReturnTypeSourceRange()`).
> > > Btw, I'm working on a fix I believe will handle all cases -- plan to 
> > > checkin later today.  However, it won't be that efficient unless I can 
> > > find a way to match params that contain dynamic exception specifications. 
> > >  If they are only legal for function pointers -- which I think is the 
> > > case -- that would make it easy and efficient, i.e., I wouldn't have to 
> > > match all FunctionDecl's with one or more parameter and test them.
> > > 
> > > Is it possible to match a parameter that is a function pointer?
> > > The alternative, as I see it, is to instead properly track the exception 
> > > specification source range information as part of the FunctionDecl (akin 
> > > to FunctionDecl::getReturnTypeSourceRange()).
> > 
> > It's all trade-offs: adding this information to the AST allows certain 
> > tasks in tooling to be done easier. On the other hand, this leads to 
> > bloating of the AST, which can already be huge. In this specific case, 
> > always keeping the source range of the exception specifier might be 
> > wasteful, since exception specifiers are rather rare (in my world, at 
> > least). But there might be a way to optionally store this information, e.g. 
> > in the `ASTContext`. In any case, makes sense to ask Richard Smith.
> I am more curious as to your comfort level about committing a fixit that we 
> know will break working code. ;-)
> 
> As for the suggested approach, I would obviously cover that with Richard, but 
> I think we're going to need exception specifications more now that they're 
> going to be part of the type system for C++. We have `FunctionProtoTypeLoc` 
> for tracking this information.
The important question here is how frequently is this likely to happen. I 
guess, it depends on the codebase, but maybe you have a rough guess?


http://reviews.llvm.org/D18575



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

r269852 - [X86][SSE] Tidied up MMX/SSE/SSE2 builtin tests to the correct test file

[Simon Pilgrim via cfe-commits]

Author: rksimon
Date: Tue May 17 17:03:31 2016
New Revision: 269852

URL: http://llvm.org/viewvc/llvm-project?rev=269852=rev
Log:
[X86][SSE] Tidied up MMX/SSE/SSE2 builtin tests to the correct test file

Modified:
cfe/trunk/test/CodeGen/mmx-builtins.c
cfe/trunk/test/CodeGen/sse-builtins.c
cfe/trunk/test/CodeGen/sse2-builtins.c

Modified: cfe/trunk/test/CodeGen/mmx-builtins.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/mmx-builtins.c?rev=269852=269851=269852=diff
==
--- cfe/trunk/test/CodeGen/mmx-builtins.c (original)
+++ cfe/trunk/test/CodeGen/mmx-builtins.c Tue May 17 17:03:31 2016
@@ -44,8 +44,8 @@ __m64 test_mm_add_pi32(__m64 a, __m64 b)
 
 __m64 test_mm_add_si64(__m64 a, __m64 b) {
   // CHECK-LABEL: test_mm_add_si64
-  // CHECK: call x86_mmx @llvm.x86.mmx.padd.q
-  return __builtin_ia32_paddq(a, b);
+  // CHECK: call x86_mmx @llvm.x86.mmx.padd.q(x86_mmx %{{.*}}, x86_mmx %{{.*}})
+  return _mm_add_si64(a, b);
 }
 
 __m64 test_mm_adds_pi8(__m64 a, __m64 b) {
@@ -315,7 +315,7 @@ int test_mm_movemask_pi8(__m64 a) {
 
 __m64 test_mm_mul_su32(__m64 a, __m64 b) {
   // CHECK-LABEL: test_mm_mul_su32
-  // CHECK: call x86_mmx @llvm.x86.mmx.pmulu.dq
+  // CHECK: call x86_mmx @llvm.x86.mmx.pmulu.dq(x86_mmx %{{.*}}, x86_mmx 
%{{.*}})
   return _mm_mul_su32(a, b);
 }
 
@@ -525,8 +525,8 @@ __m64 test_mm_sub_pi32(__m64 a, __m64 b)
 
 __m64 test_mm_sub_si64(__m64 a, __m64 b) {
   // CHECK-LABEL: test_mm_sub_si64
-  // CHECK: call x86_mmx @llvm.x86.mmx.psub.q
-  return __builtin_ia32_psubq(a, b);
+  // CHECK: call x86_mmx @llvm.x86.mmx.psub.q(x86_mmx %{{.*}}, x86_mmx %{{.*}})
+  return _mm_sub_si64(a, b);
 }
 
 __m64 test_mm_subs_pi8(__m64 a, __m64 b) {

Modified: cfe/trunk/test/CodeGen/sse-builtins.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/sse-builtins.c?rev=269852=269851=269852=diff
==
--- cfe/trunk/test/CodeGen/sse-builtins.c (original)
+++ cfe/trunk/test/CodeGen/sse-builtins.c Tue May 17 17:03:31 2016
@@ -4,6 +4,48 @@
 #include 
 #include 
 
+__m128 test_mm_add_ps(__m128 A, __m128 B) {
+  // CHECK-LABEL: test_mm_add_ps
+  // CHECK: fadd <4 x float>
+  return _mm_add_ps(A, B);
+}
+
+__m128 test_mm_and_ps(__m128 A, __m128 B) {
+  // CHECK-LABEL: test_mm_and_ps
+  // CHECK: and <4 x i32> %{{.*}}, %{{.*}}
+  return _mm_and_ps(A, B);
+}
+
+__m128 test_mm_div_ps(__m128 A, __m128 B) {
+  // CHECK-LABEL: test_mm_div_ps
+  // CHECK: fdiv <4 x float>
+  return _mm_div_ps(A, B);
+}
+
+__m128 test_mm_mul_ps(__m128 A, __m128 B) {
+  // CHECK-LABEL: test_mm_mul_ps
+  // CHECK: fmul <4 x float>
+  return _mm_mul_ps(A, B);
+}
+
+__m128 test_mm_or_ps(__m128 A, __m128 B) {
+  // CHECK-LABEL: test_mm_or_ps
+  // CHECK: or <4 x i32> %{{.*}}, %{{.*}}
+  return _mm_or_ps(A, B);
+}
+
+__m128 test_mm_sub_ps(__m128 A, __m128 B) {
+  // CHECK-LABEL: test_mm_sub_ps
+  // CHECK: fsub <4 x float>
+  return _mm_sub_ps(A, B);
+}
+
+__m128 test_mm_xor_ps(__m128 A, __m128 B) {
+  // CHECK-LABEL: test_mm_xor_ps
+  // CHECK: xor <4 x i32> %{{.*}}, %{{.*}}
+  return _mm_xor_ps(A, B);
+}
+
 __m128 test_rsqrt_ss(__m128 x) {
   // CHECK: define {{.*}} @test_rsqrt_ss
   // CHECK: call <4 x float> @llvm.x86.sse.rsqrt.ss
@@ -68,104 +110,6 @@ void test_store_ss(__m128 x, void* y) {
   _mm_store_ss(y, x);
 }
 
-__m128d test_load1_pd(__m128 x, void* y) {
-  // CHECK: define {{.*}} @test_load1_pd
-  // CHECK: load double, double* {{.*}}, align 1{{$}}
-  return _mm_load1_pd(y);
-}
-
-__m128d test_loadr_pd(__m128 x, void* y) {
-  // CHECK: define {{.*}} @test_loadr_pd
-  // CHECK: load <2 x double>, <2 x double>* {{.*}}, align 16{{$}}
-  return _mm_loadr_pd(y);
-}
-
-__m128d test_load_sd(void* y) {
-  // CHECK: define {{.*}} @test_load_sd
-  // CHECK: load double, double* {{.*}}, align 1{{$}}
-  return _mm_load_sd(y);
-}
-
-__m128d test_loadh_pd(__m128d x, void* y) {
-  // CHECK: define {{.*}} @test_loadh_pd
-  // CHECK: load double, double* {{.*}}, align 1{{$}}
-  return _mm_loadh_pd(x, y);
-}
-
-__m128d test_loadl_pd(__m128d x, void* y) {
-  // CHECK: define {{.*}} @test_loadl_pd
-  // CHECK: load double, double* {{.*}}, align 1{{$}}
-  return _mm_loadl_pd(x, y);
-}
-
-void test_store_sd(__m128d x, void* y) {
-  // CHECK-LABEL: define void @test_store_sd
-  // CHECK: store {{.*}} double* {{.*}}, align 1{{$}}
-  _mm_store_sd(y, x);
-}
-
-void test_store1_pd(__m128d x, void* y) {
-  // CHECK-LABEL: define void @test_store1_pd
-  // CHECK: store {{.*}} double* {{.*}}, align 1{{$}}
-  // CHECK: store {{.*}} double* {{.*}}, align 1{{$}}
-  _mm_store1_pd(y, x);
-}
-
-void test_storer_pd(__m128d x, void* y) {
-  // CHECK-LABEL: define void @test_storer_pd
-  // CHECK: store {{.*}} <2 x double>* {{.*}}, align 16{{$}}
-  _mm_storer_pd(y, x);
-}
-
-void test_storeh_pd(__m128d x, void* y) {
-  // CHECK-LABEL: define void @test_storeh_pd
-  // CHECK: store {{.*}} 

Re: r269765 - Revert "[X86] Add immediate range checks for many of the builtins."

[Sean Silva via cfe-commits]

On Tue, May 17, 2016 at 7:07 AM, Filipe Cabecinhas via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: filcab
> Date: Tue May 17 09:07:43 2016
> New Revision: 269765
>
> URL: http://llvm.org/viewvc/llvm-project?rev=269765=rev
> Log:
> Revert "[X86] Add immediate range checks for many of the builtins."
>
> This reverts commit r269619.
>

In the future could you include the reason too?

-- Sean Silva


>
> Modified:
> cfe/trunk/lib/Sema/SemaChecking.cpp
> cfe/trunk/test/CodeGen/avx512vl-builtins.c
>
> Modified: cfe/trunk/lib/Sema/SemaChecking.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaChecking.cpp?rev=269765=269764=269765=diff
>
> ==
> --- cfe/trunk/lib/Sema/SemaChecking.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaChecking.cpp Tue May 17 09:07:43 2016
> @@ -1323,52 +1323,23 @@ bool Sema::CheckX86BuiltinFunctionCall(u
>  return SemaBuiltinCpuSupports(*this, TheCall);
>case X86::BI__builtin_ms_va_start:
>  return SemaBuiltinMSVAStart(TheCall);
> -  case X86::BI__builtin_ia32_extractf64x4_mask:
> -  case X86::BI__builtin_ia32_extracti64x4_mask:
> -  case X86::BI__builtin_ia32_extractf32x8_mask:
> -  case X86::BI__builtin_ia32_extracti32x8_mask:
> -  case X86::BI__builtin_ia32_extractf64x2_256_mask:
> -  case X86::BI__builtin_ia32_extracti64x2_256_mask:
> -  case X86::BI__builtin_ia32_extractf32x4_256_mask:
> -  case X86::BI__builtin_ia32_extracti32x4_256_mask:
> -i = 1; l = 0; u = 1;
> -break;
>case X86::BI_mm_prefetch:
> -  case X86::BI__builtin_ia32_extractf32x4_mask:
> -  case X86::BI__builtin_ia32_extracti32x4_mask:
> -  case X86::BI__builtin_ia32_vpermilpd_mask:
> -  case X86::BI__builtin_ia32_vpermilps_mask:
> -  case X86::BI__builtin_ia32_extractf64x2_512_mask:
> -  case X86::BI__builtin_ia32_extracti64x2_512_mask:
> -i = 1; l = 0; u = 3;
> -break;
> -  case X86::BI__builtin_ia32_insertf32x8_mask:
> -  case X86::BI__builtin_ia32_inserti32x8_mask:
> -  case X86::BI__builtin_ia32_insertf64x4_mask:
> -  case X86::BI__builtin_ia32_inserti64x4_mask:
> -  case X86::BI__builtin_ia32_insertf64x2_256_mask:
> -  case X86::BI__builtin_ia32_inserti64x2_256_mask:
> -  case X86::BI__builtin_ia32_insertf32x4_256_mask:
> -  case X86::BI__builtin_ia32_inserti32x4_256_mask:
> -i = 2; l = 0; u = 1;
> +i = 1;
> +l = 0;
> +u = 3;
>  break;
>case X86::BI__builtin_ia32_sha1rnds4:
> -  case X86::BI__builtin_ia32_shuf_f32x4_256_mask:
> -  case X86::BI__builtin_ia32_shuf_f64x2_256_mask:
> -  case X86::BI__builtin_ia32_shuf_i32x4_256_mask:
> -  case X86::BI__builtin_ia32_shuf_i64x2_256_mask:
> -  case X86::BI__builtin_ia32_shufpd128_mask:
> -  case X86::BI__builtin_ia32_insertf64x2_512_mask:
> -  case X86::BI__builtin_ia32_inserti64x2_512_mask:
> -  case X86::BI__builtin_ia32_insertf32x4_mask:
> -  case X86::BI__builtin_ia32_inserti32x4_mask:
> -i = 2; l = 0; u = 3;
> +i = 2;
> +l = 0;
> +u = 3;
>  break;
>case X86::BI__builtin_ia32_vpermil2pd:
>case X86::BI__builtin_ia32_vpermil2pd256:
>case X86::BI__builtin_ia32_vpermil2ps:
>case X86::BI__builtin_ia32_vpermil2ps256:
> -i = 3; l = 0; u = 3;
> +i = 3;
> +l = 0;
> +u = 3;
>  break;
>case X86::BI__builtin_ia32_cmpb128_mask:
>case X86::BI__builtin_ia32_cmpw128_mask:
> @@ -1394,36 +1365,23 @@ bool Sema::CheckX86BuiltinFunctionCall(u
>case X86::BI__builtin_ia32_ucmpw512_mask:
>case X86::BI__builtin_ia32_ucmpd512_mask:
>case X86::BI__builtin_ia32_ucmpq512_mask:
> -  case X86::BI__builtin_ia32_vpcomub:
> -  case X86::BI__builtin_ia32_vpcomuw:
> -  case X86::BI__builtin_ia32_vpcomud:
> -  case X86::BI__builtin_ia32_vpcomuq:
> -  case X86::BI__builtin_ia32_vpcomb:
> -  case X86::BI__builtin_ia32_vpcomw:
> -  case X86::BI__builtin_ia32_vpcomd:
> -  case X86::BI__builtin_ia32_vpcomq:
> -i = 2; l = 0; u = 7;
> +i = 2;
> +l = 0;
> +u = 7;
>  break;
>case X86::BI__builtin_ia32_roundps:
>case X86::BI__builtin_ia32_roundpd:
>case X86::BI__builtin_ia32_roundps256:
>case X86::BI__builtin_ia32_roundpd256:
> -  case X86::BI__builtin_ia32_vpermilpd256_mask:
> -  case X86::BI__builtin_ia32_vpermilps256_mask:
> -i = 1; l = 0; u = 15;
> +i = 1;
> +l = 0;
> +u = 15;
>  break;
>case X86::BI__builtin_ia32_roundss:
>case X86::BI__builtin_ia32_roundsd:
> -  case X86::BI__builtin_ia32_rangepd128_mask:
> -  case X86::BI__builtin_ia32_rangepd256_mask:
> -  case X86::BI__builtin_ia32_rangepd512_mask:
> -  case X86::BI__builtin_ia32_rangeps128_mask:
> -  case X86::BI__builtin_ia32_rangeps256_mask:
> -  case X86::BI__builtin_ia32_rangeps512_mask:
> -  case X86::BI__builtin_ia32_getmantsd_round_mask:
> -  case X86::BI__builtin_ia32_getmantss_round_mask:
> -  case X86::BI__builtin_ia32_shufpd256_mask:
> -i = 2; l = 0; u = 15;
> +i = 2;
> +l = 0;
> +u = 15;
>  break;
>case 

Re: [PATCH] D19754: Allow 'nodebug' on local variables

[David Blaikie via cfe-commits]

On Tue, May 17, 2016 at 2:30 PM, Robinson, Paul 
wrote:

> What you are describing is what testing literature refers to as criteria
> for equivalence classes.  There is some level of judgment to that, yes.
>
>
>
> Yep yep, to be sure. I'm just generally trying to encourage the community
> behavior towards being both selective & thorough about testing.
>
>
>
> I have noticed you doing this (not just in this review) and I am very
> appreciative of the principles; when it comes to understanding what a test
> is trying to do, keeping the unnecessary fluff out is very helpful.  You
> have no idea how many times I've had to suss out the intent of a (usually
> comment-free) test after it broke when we merged it into our tree.
> Fortunately that sort of thing has been happening less often, now that more
> of our changes have been integrated upstream, but still, it's great to have
> tests that are very focused….
>
>
>
> ….when they are tests for a bugfix or other comparatively small change.  I
> have to say when it comes to a new-feature kind of patch, I would rather
> have the test err on the side of completeness.
>

I'm not intending to argue against completeness, to be sure.


>   This is partly based on the experience of introducing the 'optnone'
> attribute to Clang, which IIRC popped up with new and surprising cases two
> or three times after its introduction.
>

For the broader discussion about test strategy, I'd love to hear more about
these cases (perhaps on another thread) to make sure I/we/community take
the right lessons from them to improve the process and provide review
feedback that pushes us in a good direction.


>   More thorough tests up front could easily have prevented those
> surprises.  Now here I am again, not with a new attribute but seriously
> expanding the applicability of an attribute, and would like to apply
> previous experience and start out with what I think should be a moderately
> complete test.
>
>
>
> If you're unwilling to accept that argument and insist on minimal upstream
> tests, okay; I can take what I've done and migrate it into our private
> tests, and leave behind only the minimal upstream test.  It will leave me
> with the test I think the feature needs, leaves upstream with the minimal
> test you prefer, and if something breaks it will just take a little longer
> to get that feedback.
>

I think that'd be best, if you've got the option to do so/find it necessary.

Thanks!
- Dave


> Let me know.
>
> Thanks,
>
> --paulr
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D19567: PR21823: 'nodebug' attribute on global/static variables

[David Blaikie via cfe-commits]

ping

On Mon, May 2, 2016 at 11:51 AM, David Blaikie via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> dblaikie added a comment.
>
> In http://reviews.llvm.org/D19567#414906, @probinson wrote:
>
> > Huh.  There are strange interactions here, which makes me even more
> nervous about testing fewer cases.
>
>
> Generally this sort of thing makes me more interested in testing fewer
> cases so we can see/make sure they're properly covering, as you just did by
> the sounds of it. It's hard to see if everything's really covered if
> there's lots of redundant coverage that adds noise to the test case.
>
> > As it happens, the test as written did not exercise all 3 modified
> paths. Because 'struct S2' had all its members marked with nodebug, none of
> the static-member references caused debug info for the class as a whole to
> be attempted.
>
>
> Not sure I quite follow. Even without nodebug:
>
>   struct foo { static const int x = 3; int y; };
>   int i = foo::x;
>
> doesn't produce any debug info for 'foo', x, etc. Just for 'i'.
>
> >   I needed to add a variable of type S2 (without 'nodebug') in order to
> exercise that path.  Once that was done, then the modification to
> CollectRecordFields became necessary.
>
> > Even in an unmodified compiler, "static_const_member"
> never shows up as a DIGlobalVariable, although the other cases all do.  So,
> testing only for DIGlobalVariable wouldn't be sufficient to show that it
> gets suppressed by 'nodebug'.
>
>
> Have you tested cases where the static member is ODR used and/or defined:
>
>   struct foo { static const int x = 3; };
>   const int foo::x; // defined
>   void sink(void*);
>   void use() { sink(::x); } // ODR used
>
> I'm guessing that the out of line definition will create the
> DIGlobalVariable you're not seeing. But probably through a common codepath
> you've already corrected for.
>
> The ODR use probably doesn't cause anything interesting to happen.
>
> >   "static_member" shows up unless we have modified both
> EmitGlobalVariable(VarDecl case) and CollectRecordFields, given that the
> test actually tries to emit debug info for S2 as a whole.
>
>
> I would imagine this could still boil down to: check-not DIGlobalVariable,
> check-not DIFlagStaticMember ?
>
> But once the test is smaller/more targeted, checking the extra details of
> the member list of a composite type, etc, seems OK.
>
> > So, the genuinely most-minimal did-this-change-do-anything test would
> need only "static_member" and "const_global_int_def" to show that each path
> had some effect.  This approach does not fill me with warm fuzzies, or the
> feeling that future changes in this area will not break the intended
> behavior.  What do you think?
>
> > --paulr
>
>
>
> Repository:
>   rL LLVM
>
> http://reviews.llvm.org/D19567
>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D20339: Update clang for D20260

[Peter Collingbourne via cfe-commits]

pcc created this revision.
pcc added reviewers: rafael, majnemer.
pcc added a subscriber: cfe-commits.
Herald added subscribers: srhines, danalbert, tberghammer.

http://reviews.llvm.org/D20339

Files:
  lib/CodeGen/CGDecl.cpp
  lib/CodeGen/CGExpr.cpp
  lib/CodeGen/CGOpenMPRuntime.cpp
  lib/CodeGen/CGVTT.cpp
  lib/CodeGen/CGVTables.cpp
  lib/CodeGen/CodeGenModule.cpp
  lib/CodeGen/ItaniumCXXABI.cpp
  lib/CodeGen/MicrosoftCXXABI.cpp
  test/CodeGen/attr-func-def.c
  test/CodeGen/mips-vector-arg.c
  test/CodeGen/packed-arrays.c
  test/CodeGen/x86_64-longdouble.c
  test/CodeGenCXX/atomicinit.cpp
  test/CodeGenCXX/virtual-base-ctor.cpp
  test/CodeGenOpenCL/constant-addr-space-globals.cl
  test/CodeGenOpenCL/shifts.cl
  test/CodeGenOpenCL/str_literals.cl
  test/SemaOpenCL/extern.cl

Index: test/SemaOpenCL/extern.cl
===
--- test/SemaOpenCL/extern.cl
+++ test/SemaOpenCL/extern.cl
@@ -1,7 +1,7 @@
 // RUN: %clang_cc1 -x cl -cl-std=CL1.2 -emit-llvm -ffake-address-space-map %s -o - -verify | FileCheck %s
 // expected-no-diagnostics
 
-// CHECK: @foo = external addrspace(3) constant float
+// CHECK: @foo = external local_unnamed_addr addrspace(3) constant float
 extern constant float foo;
 
 kernel void test(global float* buf) {
Index: test/CodeGenOpenCL/str_literals.cl
===
--- test/CodeGenOpenCL/str_literals.cl
+++ test/CodeGenOpenCL/str_literals.cl
@@ -5,5 +5,5 @@
 
 // CHECK: unnamed_addr addrspace(3) constant
 // CHECK-NOT: addrspace(3) unnamed_addr constant
-// CHECK: @x = addrspace(3) constant i8 addrspace(3)*
-// CHECK: @y = addrspace(3) constant i8 addrspace(3)*
+// CHECK: @x = local_unnamed_addr addrspace(3) constant i8 addrspace(3)*
+// CHECK: @y = local_unnamed_addr addrspace(3) constant i8 addrspace(3)*
Index: test/CodeGenOpenCL/shifts.cl
===
--- test/CodeGenOpenCL/shifts.cl
+++ test/CodeGenOpenCL/shifts.cl
@@ -5,7 +5,7 @@
 // bits before evaluating. Test this both for variables and constants
 // evaluated in the front-end.
 
-// OPT: @gtest1 = constant i64 2147483648
+// OPT: @gtest1 = local_unnamed_addr constant i64 2147483648
 __constant const unsigned long gtest1 = 1UL << 31;
 
 // NOOPT: @negativeShift32
Index: test/CodeGenOpenCL/constant-addr-space-globals.cl
===
--- test/CodeGenOpenCL/constant-addr-space-globals.cl
+++ test/CodeGenOpenCL/constant-addr-space-globals.cl
@@ -1,6 +1,6 @@
 // RUN: %clang_cc1 %s -ffake-address-space-map -emit-llvm -o - | FileCheck %s
 
-// CHECK: @array = addrspace({{[0-9]+}}) constant
+// CHECK: @array = local_unnamed_addr addrspace({{[0-9]+}}) constant
 __constant float array[2] = {0.0f, 1.0f};
 
 kernel void test(global float *out) {
Index: test/CodeGenCXX/virtual-base-ctor.cpp
===
--- test/CodeGenCXX/virtual-base-ctor.cpp
+++ test/CodeGenCXX/virtual-base-ctor.cpp
@@ -8,4 +8,4 @@
 struct B : virtual A { void* x; };
 B x;
 
-// CHECK: @y = global i8 2
+// CHECK: @y = local_unnamed_addr global i8 2
Index: test/CodeGenCXX/atomicinit.cpp
===
--- test/CodeGenCXX/atomicinit.cpp
+++ test/CodeGenCXX/atomicinit.cpp
@@ -1,13 +1,13 @@
 // RUN: %clang_cc1 %s -emit-llvm -O1 -o - -triple=i686-apple-darwin9 -std=c++11 | FileCheck %s
 
-// CHECK-DAG: @PR22043 = global i32 0, align 4
+// CHECK-DAG: @PR22043 = local_unnamed_addr global i32 0, align 4
 typedef _Atomic(int) AtomicInt;
 AtomicInt PR22043 = AtomicInt();
 
-// CHECK-DAG: @_ZN7PR180978constant1aE = global { i16, i8 } { i16 1, i8 6 }, align 4
-// CHECK-DAG: @_ZN7PR180978constant1bE = global { i16, i8 } { i16 2, i8 6 }, align 4
-// CHECK-DAG: @_ZN7PR180978constant1cE = global { i16, i8 } { i16 3, i8 6 }, align 4
-// CHECK-DAG: @_ZN7PR180978constant1yE = global { { i16, i8 }, i32 } { { i16, i8 } { i16 4, i8 6 }, i32 5 }, align 4
+// CHECK-DAG: @_ZN7PR180978constant1aE = local_unnamed_addr global { i16, i8 } { i16 1, i8 6 }, align 4
+// CHECK-DAG: @_ZN7PR180978constant1bE = local_unnamed_addr global { i16, i8 } { i16 2, i8 6 }, align 4
+// CHECK-DAG: @_ZN7PR180978constant1cE = local_unnamed_addr global { i16, i8 } { i16 3, i8 6 }, align 4
+// CHECK-DAG: @_ZN7PR180978constant1yE = local_unnamed_addr global { { i16, i8 }, i32 } { { i16, i8 } { i16 4, i8 6 }, i32 5 }, align 4
 
 struct A {
   _Atomic(int) i;
Index: test/CodeGen/x86_64-longdouble.c
===
--- test/CodeGen/x86_64-longdouble.c
+++ test/CodeGen/x86_64-longdouble.c
@@ -11,12 +11,12 @@
 // Android uses fp128 for long double but other x86_64 targets use x86_fp80.
 
 long double dataLD = 1.0L;
-// ANDROID: @dataLD = global fp128 0xL3FFF, align 16
-// GNU: @dataLD = global x86_fp80 0xK3FFF8000, 

r269849 - Revert r269717. That change alone did not provide the intended benefit (which

[Richard Smith via cfe-commits]

Author: rsmith
Date: Tue May 17 16:48:41 2016
New Revision: 269849

URL: http://llvm.org/viewvc/llvm-project?rev=269849=rev
Log:
Revert r269717. That change alone did not provide the intended benefit (which
would come from changing the type of ASTContext::DeclAttrs from
DenseMap to DenseMap), and it turns out to be
impractical to avoid the allocation there, because we expose the address of the
attribute vector in ways that are hard to fix.

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

Modified: cfe/trunk/include/clang/AST/AttrIterator.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/AttrIterator.h?rev=269849=269848=269849=diff
==
--- cfe/trunk/include/clang/AST/AttrIterator.h (original)
+++ cfe/trunk/include/clang/AST/AttrIterator.h Tue May 17 16:48:41 2016
@@ -15,7 +15,6 @@
 #define LLVM_CLANG_AST_ATTRITERATOR_H
 
 #include "clang/Basic/LLVM.h"
-#include "llvm/ADT/TinyPtrVector.h"
 #include 
 
 namespace clang {
@@ -23,19 +22,6 @@ namespace clang {
   class Attr;
 }
 
-namespace llvm {
-  // Explicitly opt into 4 byte alignment for Attr*, to avoid the need to
-  // include the heavyweight Attr.h to use a TinyPtrVector.
-  template <>
-  struct PointerLikeTypeTraits {
-static void *getAsVoidPointer(clang::Attr *P) { return P; }
-static clang::Attr *getFromVoidPointer(void *P) {
-  return static_cast(P);
-}
-enum { NumLowBitsAvailable = 2 };
-  };
-}
-
 // Defined in ASTContext.h
 void *operator new(size_t Bytes, const clang::ASTContext ,
size_t Alignment = 8);
@@ -53,8 +39,8 @@ void operator delete[](void *Ptr, const
 namespace clang {
 
 /// AttrVec - A vector of Attr, which is how they are stored on the AST.
-typedef llvm::TinyPtrVector AttrVec;
-typedef llvm::TinyPtrVector ConstAttrVec;
+typedef SmallVector AttrVec;
+typedef SmallVector ConstAttrVec;
 
 /// specific_attr_iterator - Iterates over a subrange of an AttrVec, only
 /// providing attributes that are of a specific type.


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

[PATCH] D20338: [PCH] Fixed overridden files always invalidating preamble even when unchanged

[Cameron via cfe-commits]

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

Remapped files would always cause the preamble's PCH to be invalidated (even if 
they hadn't changed) because the file manager was replacing the remapped 
virtual entry (no modified time) with a real file entry (which has a modified 
time) when an include directive was processed. This happens when the include 
directive results in a slightly different path for the same file (e.g. 
different slash direction, which happens very often on Windows).

Note: This was initially part of D20137 but I had incorrectly applied my own 
patch, so the `IsVirtual = true` line was in the wrong spot and served no 
purpose (and was subsequently removed from the patch). Now it actually does 
something!

Repository:
  rL LLVM

http://reviews.llvm.org/D20338

Files:
  include/clang/Basic/FileManager.h
  lib/Basic/FileManager.cpp

Index: lib/Basic/FileManager.cpp
===
--- lib/Basic/FileManager.cpp
+++ lib/Basic/FileManager.cpp
@@ -301,6 +301,11 @@
 return 
   }
 
+  if (UFE.isVirtual()) {
+UFE.Name = InterndFileName;
+return 
+  }
+
   // Otherwise, we don't have this file yet, add it.
   UFE.Name= InterndFileName;
   UFE.Size = Data.Size;
@@ -381,6 +386,7 @@
   UFE->Dir = DirInfo;
   UFE->UID = NextFileUID++;
   UFE->File.reset();
+  UFE->IsVirtual = true;
   return UFE;
 }
 
Index: include/clang/Basic/FileManager.h
===
--- include/clang/Basic/FileManager.h
+++ include/clang/Basic/FileManager.h
@@ -60,6 +60,7 @@
   bool IsNamedPipe;
   bool InPCH;
   bool IsValid;   // Is this \c FileEntry initialized and valid?
+  bool IsVirtual; // Is this \c FileEntry a virtual file?
 
   /// \brief The open file, if it is owned by the \p FileEntry.
   mutable std::unique_ptr File;
@@ -69,20 +70,23 @@
 
 public:
   FileEntry()
-  : UniqueID(0, 0), IsNamedPipe(false), InPCH(false), IsValid(false)
+  : UniqueID(0, 0), IsNamedPipe(false), InPCH(false), IsValid(false),
+IsVirtual(false)
   {}
 
   // FIXME: this is here to allow putting FileEntry in std::map.  Once we have
   // emplace, we shouldn't need a copy constructor anymore.
   /// Intentionally does not copy fields that are not set in an uninitialized
   /// \c FileEntry.
   FileEntry(const FileEntry ) : UniqueID(FE.UniqueID),
-  IsNamedPipe(FE.IsNamedPipe), InPCH(FE.InPCH), IsValid(FE.IsValid) {
+  IsNamedPipe(FE.IsNamedPipe), InPCH(FE.InPCH), IsValid(FE.IsValid),
+  IsVirtual(FE.IsVirtual) {
 assert(!isValid() && "Cannot copy an initialized FileEntry");
   }
 
   const char *getName() const { return Name; }
   bool isValid() const { return IsValid; }
+  bool isVirtual() const { return IsVirtual; }
   off_t getSize() const { return Size; }
   unsigned getUID() const { return UID; }
   const llvm::sys::fs::UniqueID () const { return UniqueID; }


Index: lib/Basic/FileManager.cpp
===
--- lib/Basic/FileManager.cpp
+++ lib/Basic/FileManager.cpp
@@ -301,6 +301,11 @@
 return 
   }
 
+  if (UFE.isVirtual()) {
+UFE.Name = InterndFileName;
+return 
+  }
+
   // Otherwise, we don't have this file yet, add it.
   UFE.Name= InterndFileName;
   UFE.Size = Data.Size;
@@ -381,6 +386,7 @@
   UFE->Dir = DirInfo;
   UFE->UID = NextFileUID++;
   UFE->File.reset();
+  UFE->IsVirtual = true;
   return UFE;
 }
 
Index: include/clang/Basic/FileManager.h
===
--- include/clang/Basic/FileManager.h
+++ include/clang/Basic/FileManager.h
@@ -60,6 +60,7 @@
   bool IsNamedPipe;
   bool InPCH;
   bool IsValid;   // Is this \c FileEntry initialized and valid?
+  bool IsVirtual; // Is this \c FileEntry a virtual file?
 
   /// \brief The open file, if it is owned by the \p FileEntry.
   mutable std::unique_ptr File;
@@ -69,20 +70,23 @@
 
 public:
   FileEntry()
-  : UniqueID(0, 0), IsNamedPipe(false), InPCH(false), IsValid(false)
+  : UniqueID(0, 0), IsNamedPipe(false), InPCH(false), IsValid(false),
+IsVirtual(false)
   {}
 
   // FIXME: this is here to allow putting FileEntry in std::map.  Once we have
   // emplace, we shouldn't need a copy constructor anymore.
   /// Intentionally does not copy fields that are not set in an uninitialized
   /// \c FileEntry.
   FileEntry(const FileEntry ) : UniqueID(FE.UniqueID),
-  IsNamedPipe(FE.IsNamedPipe), InPCH(FE.InPCH), IsValid(FE.IsValid) {
+  IsNamedPipe(FE.IsNamedPipe), InPCH(FE.InPCH), IsValid(FE.IsValid),
+  IsVirtual(FE.IsVirtual) {
 assert(!isValid() && "Cannot copy an initialized FileEntry");
   }
 
   const char *getName() const { return Name; }
   bool isValid() const { return IsValid; 

Re: [PATCH] D18575: [clang-tidy] New checker to replace deprecated throw() specifications

[Aaron Ballman via cfe-commits]

aaron.ballman added inline comments.


Comment at: clang-tidy/modernize/UseNoexceptCheck.cpp:39
@@ +38,3 @@
+
+  // FIXME: Add paren matching so we can parse more complex throw statements,
+  // e.g., (examples provided by Aaron Ballman):

alexfh wrote:
> hintonda wrote:
> > aaron.ballman wrote:
> > > @alexfh, what are your feelings on this FIXME? I am a bit concerned 
> > > because these examples will cause the replacement range to be incorrect, 
> > > which will turn working code into ill-formed code. The alternative, as I 
> > > see it, is to instead properly track the exception specification source 
> > > range information as part of the FunctionDecl (akin to 
> > > `FunctionDecl::getReturnTypeSourceRange()`).
> > Btw, I'm working on a fix I believe will handle all cases -- plan to 
> > checkin later today.  However, it won't be that efficient unless I can find 
> > a way to match params that contain dynamic exception specifications.  If 
> > they are only legal for function pointers -- which I think is the case -- 
> > that would make it easy and efficient, i.e., I wouldn't have to match all 
> > FunctionDecl's with one or more parameter and test them.
> > 
> > Is it possible to match a parameter that is a function pointer?
> > The alternative, as I see it, is to instead properly track the exception 
> > specification source range information as part of the FunctionDecl (akin to 
> > FunctionDecl::getReturnTypeSourceRange()).
> 
> It's all trade-offs: adding this information to the AST allows certain tasks 
> in tooling to be done easier. On the other hand, this leads to bloating of 
> the AST, which can already be huge. In this specific case, always keeping the 
> source range of the exception specifier might be wasteful, since exception 
> specifiers are rather rare (in my world, at least). But there might be a way 
> to optionally store this information, e.g. in the `ASTContext`. In any case, 
> makes sense to ask Richard Smith.
I am more curious as to your comfort level about committing a fixit that we 
know will break working code. ;-)

As for the suggested approach, I would obviously cover that with Richard, but I 
think we're going to need exception specifications more now that they're going 
to be part of the type system for C++. We have `FunctionProtoTypeLoc` for 
tracking this information.


http://reviews.llvm.org/D18575



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

Re: [PATCH] D18575: [clang-tidy] New checker to replace deprecated throw() specifications

[Alexander Kornienko via cfe-commits]

alexfh added inline comments.


Comment at: clang-tidy/modernize/UseNoexceptCheck.cpp:22
@@ +21,3 @@
+namespace {
+
+StringRef makeDynamicExceptionString(const SourceManager ,

It's much more common for LLVM code to use static functions:

http://llvm.org/docs/CodingStandards.html#anonymous-namespaces
"make anonymous namespaces as small as possible, and only use them for class 
declarations" 


Comment at: clang-tidy/modernize/UseNoexceptCheck.cpp:39
@@ +38,3 @@
+
+  // FIXME: Add paren matching so we can parse more complex throw statements,
+  // e.g., (examples provided by Aaron Ballman):

hintonda wrote:
> aaron.ballman wrote:
> > @alexfh, what are your feelings on this FIXME? I am a bit concerned because 
> > these examples will cause the replacement range to be incorrect, which will 
> > turn working code into ill-formed code. The alternative, as I see it, is to 
> > instead properly track the exception specification source range information 
> > as part of the FunctionDecl (akin to 
> > `FunctionDecl::getReturnTypeSourceRange()`).
> Btw, I'm working on a fix I believe will handle all cases -- plan to checkin 
> later today.  However, it won't be that efficient unless I can find a way to 
> match params that contain dynamic exception specifications.  If they are only 
> legal for function pointers -- which I think is the case -- that would make 
> it easy and efficient, i.e., I wouldn't have to match all FunctionDecl's with 
> one or more parameter and test them.
> 
> Is it possible to match a parameter that is a function pointer?
> The alternative, as I see it, is to instead properly track the exception 
> specification source range information as part of the FunctionDecl (akin to 
> FunctionDecl::getReturnTypeSourceRange()).

It's all trade-offs: adding this information to the AST allows certain tasks in 
tooling to be done easier. On the other hand, this leads to bloating of the 
AST, which can already be huge. In this specific case, always keeping the 
source range of the exception specifier might be wasteful, since exception 
specifiers are rather rare (in my world, at least). But there might be a way to 
optionally store this information, e.g. in the `ASTContext`. In any case, makes 
sense to ask Richard Smith.


http://reviews.llvm.org/D18575



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

Re: [PATCH] D17416: [libcxx] Reorganize locale extension fallbacks. NFCI

[Ben Craig via cfe-commits]

bcraig added a comment.

I'll be submitting this Friday morning, barring any objections (I'm out of the 
office the next couple of days).


http://reviews.llvm.org/D17416



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

Re: [PATCH] D17416: [libcxx] Reorganize locale extension fallbacks. NFCI

[Ben Craig via cfe-commits]

bcraig updated this revision to Diff 57521.
bcraig marked 2 inline comments as done.

http://reviews.llvm.org/D17416

Files:
  include/support/android/locale_bionic.h
  include/support/newlib/xlocale.h
  include/support/xlocale/__posix_l_fallback.h
  include/support/xlocale/__strtonum_fallback.h
  include/support/xlocale/xlocale.h

Index: include/support/xlocale/xlocale.h
===
--- include/support/xlocale/xlocale.h
+++ /dev/null
@@ -1,194 +0,0 @@
-// -*- C++ -*-
-//===--- support/xlocale/xlocale.h ===//
-//
-// The LLVM Compiler Infrastructure
-//
-// This file is dual licensed under the MIT and the University of Illinois Open
-// Source Licenses. See LICENSE.TXT for details.
-//
-//===--===//
-// This is a shared implementation of a shim to provide extended locale support
-// on top of libc's that don't support it (like Android's bionic, and Newlib).
-//
-// The 'illusion' only works when the specified locale is "C" or "POSIX", but
-// that's about as good as we can do without implementing full xlocale support
-// in the underlying libc.
-//===--===//
-
-#ifndef _LIBCPP_SUPPORT_XLOCALE_XLOCALE_H
-#define _LIBCPP_SUPPORT_XLOCALE_XLOCALE_H
-
-#ifdef __cplusplus
-extern "C" {
-#endif
-
-static inline int isalnum_l(int c, locale_t) {
-  return isalnum(c);
-}
-
-static inline int isalpha_l(int c, locale_t) {
-  return isalpha(c);
-}
-
-static inline int isblank_l(int c, locale_t) {
-  return isblank(c);
-}
-
-static inline int iscntrl_l(int c, locale_t) {
-  return iscntrl(c);
-}
-
-static inline int isdigit_l(int c, locale_t) {
-  return isdigit(c);
-}
-
-static inline int isgraph_l(int c, locale_t) {
-  return isgraph(c);
-}
-
-static inline int islower_l(int c, locale_t) {
-  return islower(c);
-}
-
-static inline int isprint_l(int c, locale_t) {
-  return isprint(c);
-}
-
-static inline int ispunct_l(int c, locale_t) {
-  return ispunct(c);
-}
-
-static inline int isspace_l(int c, locale_t) {
-  return isspace(c);
-}
-
-static inline int isupper_l(int c, locale_t) {
-  return isupper(c);
-}
-
-static inline int isxdigit_l(int c, locale_t) {
-  return isxdigit(c);
-}
-
-static inline int iswalnum_l(wint_t c, locale_t) {
-  return iswalnum(c);
-}
-
-static inline int iswalpha_l(wint_t c, locale_t) {
-  return iswalpha(c);
-}
-
-static inline int iswblank_l(wint_t c, locale_t) {
-  return iswblank(c);
-}
-
-static inline int iswcntrl_l(wint_t c, locale_t) {
-  return iswcntrl(c);
-}
-
-static inline int iswdigit_l(wint_t c, locale_t) {
-  return iswdigit(c);
-}
-
-static inline int iswgraph_l(wint_t c, locale_t) {
-  return iswgraph(c);
-}
-
-static inline int iswlower_l(wint_t c, locale_t) {
-  return iswlower(c);
-}
-
-static inline int iswprint_l(wint_t c, locale_t) {
-  return iswprint(c);
-}
-
-static inline int iswpunct_l(wint_t c, locale_t) {
-  return iswpunct(c);
-}
-
-static inline int iswspace_l(wint_t c, locale_t) {
-  return iswspace(c);
-}
-
-static inline int iswupper_l(wint_t c, locale_t) {
-  return iswupper(c);
-}
-
-static inline int iswxdigit_l(wint_t c, locale_t) {
-  return iswxdigit(c);
-}
-
-static inline int toupper_l(int c, locale_t) {
-  return toupper(c);
-}
-
-static inline int tolower_l(int c, locale_t) {
-  return tolower(c);
-}
-
-static inline int towupper_l(int c, locale_t) {
-  return towupper(c);
-}
-
-static inline int towlower_l(int c, locale_t) {
-  return towlower(c);
-}
-
-static inline int strcoll_l(const char *s1, const char *s2, locale_t) {
-  return strcoll(s1, s2);
-}
-
-static inline size_t strxfrm_l(char *dest, const char *src, size_t n,
-   locale_t) {
-  return strxfrm(dest, src, n);
-}
-
-static inline size_t strftime_l(char *s, size_t max, const char *format,
-const struct tm *tm, locale_t) {
-  return strftime(s, max, format, tm);
-}
-
-static inline int wcscoll_l(const wchar_t *ws1, const wchar_t *ws2, locale_t) {
-  return wcscoll(ws1, ws2);
-}
-
-static inline size_t wcsxfrm_l(wchar_t *dest, const wchar_t *src, size_t n,
-   locale_t) {
-  return wcsxfrm(dest, src, n);
-}
-
-static inline long double strtold_l(const char *nptr, char **endptr, locale_t) {
-  return strtold(nptr, endptr);
-}
-
-static inline long long strtoll_l(const char *nptr, char **endptr, int base,
-  locale_t) {
-  return strtoll(nptr, endptr, base);
-}
-
-static inline unsigned long long strtoull_l(const char *nptr, char **endptr,
-int base, locale_t) {
-  return strtoull(nptr, endptr, base);
-}
-
-static inline long long wcstoll_l(const wchar_t *nptr, wchar_t **endptr,
-  int base, locale_t) {
-  return wcstoll(nptr, endptr, base);
-}

RE: [PATCH] D19754: Allow 'nodebug' on local variables

[Robinson, Paul via cfe-commits]

What you are describing is what testing literature refers to as criteria
for equivalence classes.  There is some level of judgment to that, yes.

Yep yep, to be sure. I'm just generally trying to encourage the community 
behavior towards being both selective & thorough about testing.

I have noticed you doing this (not just in this review) and I am very 
appreciative of the principles; when it comes to understanding what a test is 
trying to do, keeping the unnecessary fluff out is very helpful.  You have no 
idea how many times I've had to suss out the intent of a (usually comment-free) 
test after it broke when we merged it into our tree.  Fortunately that sort of 
thing has been happening less often, now that more of our changes have been 
integrated upstream, but still, it's great to have tests that are very focused….

….when they are tests for a bugfix or other comparatively small change.  I have 
to say when it comes to a new-feature kind of patch, I would rather have the 
test err on the side of completeness.  This is partly based on the experience 
of introducing the 'optnone' attribute to Clang, which IIRC popped up with new 
and surprising cases two or three times after its introduction.  More thorough 
tests up front could easily have prevented those surprises.  Now here I am 
again, not with a new attribute but seriously expanding the applicability of an 
attribute, and would like to apply previous experience and start out with what 
I think should be a moderately complete test.

If you're unwilling to accept that argument and insist on minimal upstream 
tests, okay; I can take what I've done and migrate it into our private tests, 
and leave behind only the minimal upstream test.  It will leave me with the 
test I think the feature needs, leaves upstream with the minimal test you 
prefer, and if something breaks it will just take a little longer to get that 
feedback.
Let me know.
Thanks,
--paulr

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

Re: [PATCH] D17416: [libcxx] Reorganize locale extension fallbacks. NFCI

[Ben Craig via cfe-commits]

bcraig updated this revision to Diff 57520.

http://reviews.llvm.org/D17416

Files:
  include/support/android/locale_bionic.h
  include/support/newlib/xlocale.h
  include/support/xlocale/__posix_l_fallback.h
  include/support/xlocale/__strtonum_fallback.h
  include/support/xlocale/xlocale.h

Index: include/support/xlocale/xlocale.h
===
--- include/support/xlocale/xlocale.h
+++ /dev/null
@@ -1,194 +0,0 @@
-// -*- C++ -*-
-//===--- support/xlocale/xlocale.h ===//
-//
-// The LLVM Compiler Infrastructure
-//
-// This file is dual licensed under the MIT and the University of Illinois Open
-// Source Licenses. See LICENSE.TXT for details.
-//
-//===--===//
-// This is a shared implementation of a shim to provide extended locale support
-// on top of libc's that don't support it (like Android's bionic, and Newlib).
-//
-// The 'illusion' only works when the specified locale is "C" or "POSIX", but
-// that's about as good as we can do without implementing full xlocale support
-// in the underlying libc.
-//===--===//
-
-#ifndef _LIBCPP_SUPPORT_XLOCALE_XLOCALE_H
-#define _LIBCPP_SUPPORT_XLOCALE_XLOCALE_H
-
-#ifdef __cplusplus
-extern "C" {
-#endif
-
-static inline int isalnum_l(int c, locale_t) {
-  return isalnum(c);
-}
-
-static inline int isalpha_l(int c, locale_t) {
-  return isalpha(c);
-}
-
-static inline int isblank_l(int c, locale_t) {
-  return isblank(c);
-}
-
-static inline int iscntrl_l(int c, locale_t) {
-  return iscntrl(c);
-}
-
-static inline int isdigit_l(int c, locale_t) {
-  return isdigit(c);
-}
-
-static inline int isgraph_l(int c, locale_t) {
-  return isgraph(c);
-}
-
-static inline int islower_l(int c, locale_t) {
-  return islower(c);
-}
-
-static inline int isprint_l(int c, locale_t) {
-  return isprint(c);
-}
-
-static inline int ispunct_l(int c, locale_t) {
-  return ispunct(c);
-}
-
-static inline int isspace_l(int c, locale_t) {
-  return isspace(c);
-}
-
-static inline int isupper_l(int c, locale_t) {
-  return isupper(c);
-}
-
-static inline int isxdigit_l(int c, locale_t) {
-  return isxdigit(c);
-}
-
-static inline int iswalnum_l(wint_t c, locale_t) {
-  return iswalnum(c);
-}
-
-static inline int iswalpha_l(wint_t c, locale_t) {
-  return iswalpha(c);
-}
-
-static inline int iswblank_l(wint_t c, locale_t) {
-  return iswblank(c);
-}
-
-static inline int iswcntrl_l(wint_t c, locale_t) {
-  return iswcntrl(c);
-}
-
-static inline int iswdigit_l(wint_t c, locale_t) {
-  return iswdigit(c);
-}
-
-static inline int iswgraph_l(wint_t c, locale_t) {
-  return iswgraph(c);
-}
-
-static inline int iswlower_l(wint_t c, locale_t) {
-  return iswlower(c);
-}
-
-static inline int iswprint_l(wint_t c, locale_t) {
-  return iswprint(c);
-}
-
-static inline int iswpunct_l(wint_t c, locale_t) {
-  return iswpunct(c);
-}
-
-static inline int iswspace_l(wint_t c, locale_t) {
-  return iswspace(c);
-}
-
-static inline int iswupper_l(wint_t c, locale_t) {
-  return iswupper(c);
-}
-
-static inline int iswxdigit_l(wint_t c, locale_t) {
-  return iswxdigit(c);
-}
-
-static inline int toupper_l(int c, locale_t) {
-  return toupper(c);
-}
-
-static inline int tolower_l(int c, locale_t) {
-  return tolower(c);
-}
-
-static inline int towupper_l(int c, locale_t) {
-  return towupper(c);
-}
-
-static inline int towlower_l(int c, locale_t) {
-  return towlower(c);
-}
-
-static inline int strcoll_l(const char *s1, const char *s2, locale_t) {
-  return strcoll(s1, s2);
-}
-
-static inline size_t strxfrm_l(char *dest, const char *src, size_t n,
-   locale_t) {
-  return strxfrm(dest, src, n);
-}
-
-static inline size_t strftime_l(char *s, size_t max, const char *format,
-const struct tm *tm, locale_t) {
-  return strftime(s, max, format, tm);
-}
-
-static inline int wcscoll_l(const wchar_t *ws1, const wchar_t *ws2, locale_t) {
-  return wcscoll(ws1, ws2);
-}
-
-static inline size_t wcsxfrm_l(wchar_t *dest, const wchar_t *src, size_t n,
-   locale_t) {
-  return wcsxfrm(dest, src, n);
-}
-
-static inline long double strtold_l(const char *nptr, char **endptr, locale_t) {
-  return strtold(nptr, endptr);
-}
-
-static inline long long strtoll_l(const char *nptr, char **endptr, int base,
-  locale_t) {
-  return strtoll(nptr, endptr, base);
-}
-
-static inline unsigned long long strtoull_l(const char *nptr, char **endptr,
-int base, locale_t) {
-  return strtoull(nptr, endptr, base);
-}
-
-static inline long long wcstoll_l(const wchar_t *nptr, wchar_t **endptr,
-  int base, locale_t) {
-  return wcstoll(nptr, endptr, base);
-}
-
-static inline unsigned long long 

Re: [libcxx] r269789 - Implement LWG2576: istream_iterator and ostream_iterator should use std::addressof

[Eric Fiselier via cfe-commits]

Thanks Richard, I wouldn't have gotten that. One day I'll understand
locales.
On May 17, 2016 3:22 PM, "Richard Smith"  wrote:

> Here's an istream_iterator test for this change:
>
> #include 
> #include 
> #include 
>
> struct evil_traits : std::char_traits {
>   template friend void operator&(T) = delete;
> };
>
> struct pointless_derived_class
> : std::num_get> {};
>
> int main() {
>   std::basic_stringstream ss("1 2 3");
>   ss.imbue(std::locale(ss.getloc(), new pointless_derived_class));
>
>   using II = std::istream_iterator;
>   int n = 0;
>   for (auto i = II(ss), e = II(); i != e; ++i)
> n += *i;
>   assert(n == 6);
> }
>
> PS: locales suck.
>
> On Tue, May 17, 2016 at 2:09 PM, Eric Fiselier via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> OK, I think I figured it out. I added tests for the ostream_iterator
>> constructors in r269838.
>> I'll follow that up with tests for the istream_iterator constructors, but
>> my current test is failing for reasons beyond me.
>>
>> /Eric
>>
>> On Tue, May 17, 2016 at 2:36 PM, Eric Fiselier  wrote:
>>
>>> Or maybe I'm still wrong. I tried using a custom traits class to hijack
>>> ADL for "operator&" but it doesn't seem to work.
>>>
>>> Sorry for the spam.
>>>
>>> /Eric
>>>
>>> On Tue, May 17, 2016 at 2:25 PM, Eric Fiselier  wrote:
>>>
 Woops. I was incorrect. It seems that user defined "operator&"
 overloads can be found in the constructor. From the LWG issue:

 > Note that {i,o}stream_type are specializations of basic_{i,o}stream,
 but the constructors might still pick up an overloaded & via the traits
 template parameter.

 At least that also tells us how to test it.

 /Eric

 On Tue, May 17, 2016 at 2:08 PM, Eric Fiselier  wrote:

> The difference between "operator&" and "addressof"  is inconsequential
> when user defined overloads of "operator&" can't be found, which is the
> case for the changes in the stream iterator constructors. We might as well
> keep it consistent though. I don't see any value changing it back to use
> "operator&" in either the library or the standard.
>
> /Eric
>
> On Tue, May 17, 2016 at 2:02 PM, David Blaikie 
> wrote:
>
>> If some parts are not testable & as you say, not meaningful, then it
>> seems OK to just not implement them & file a DR on the standard, no?
>>
>> On Tue, May 17, 2016 at 1:00 PM, Eric Fiselier  wrote:
>>
>>> I added a test for operator->() in r269812. Marshall and I discussed
>>> offline about how not all parts of this change are testable (and hence 
>>> not
>>> meaningful) but that's what the standard says to do.
>>>
>>>
>>> On Tue, May 17, 2016 at 1:51 PM, David Blaikie via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
 Test coverage?

 On Tue, May 17, 2016 at 10:44 AM, Marshall Clow via cfe-commits <
 cfe-commits@lists.llvm.org> wrote:

> Author: marshall
> Date: Tue May 17 12:44:40 2016
> New Revision: 269789
>
> URL: http://llvm.org/viewvc/llvm-project?rev=269789=rev
> Log:
> Implement LWG2576: istream_iterator and ostream_iterator should
> use std::addressof
>
> Modified:
> libcxx/trunk/include/iterator
> libcxx/trunk/www/cxx1z_status.html
>
> Modified: libcxx/trunk/include/iterator
> URL:
> http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/iterator?rev=269789=269788=269789=diff
>
> ==
> --- libcxx/trunk/include/iterator (original)
> +++ libcxx/trunk/include/iterator Tue May 17 12:44:40 2016
> @@ -772,14 +772,14 @@ private:
>  _Tp __value_;
>  public:
>  _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR
> istream_iterator() : __in_stream_(0), __value_() {}
> -_LIBCPP_INLINE_VISIBILITY istream_iterator(istream_type& __s)
> : __in_stream_(&__s)
> +_LIBCPP_INLINE_VISIBILITY istream_iterator(istream_type& __s)
> : __in_stream_(_VSTD::addressof(__s))
>  {
>  if (!(*__in_stream_ >> __value_))
>  __in_stream_ = 0;
>  }
>
>  _LIBCPP_INLINE_VISIBILITY const _Tp& operator*() const
> {return __value_;}
> -_LIBCPP_INLINE_VISIBILITY const _Tp* operator->() const
> {return &(operator*());}
> +_LIBCPP_INLINE_VISIBILITY const _Tp* operator->() const
> {return _VSTD::addressof((operator*()));}
>  _LIBCPP_INLINE_VISIBILITY 

Re: r269675 - [ms] Reintroduce feature guards in intrinsic headers in Microsoft mode

[Eric Christopher via cfe-commits]

So, why are you doing this for more than just the avx512 headers? I
understand that you're unhappy with all of the intrinsics, but you've added
an incompatibility here for MS mode. Does MS use header guards locking off
particular intrinsics?

What "better intrinsic story" are you looking for? This doesn't seem
related to the PR you reference.

As far as using the right /arch, that's true, however, you should be
getting an error from the front end rather than an error in the backend -
what's up with that?

-eric

On Mon, May 16, 2016 at 11:20 AM Nico Weber via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: nico
> Date: Mon May 16 13:14:07 2016
> New Revision: 269675
>
> URL: http://llvm.org/viewvc/llvm-project?rev=269675=rev
> Log:
> [ms] Reintroduce feature guards in intrinsic headers in Microsoft mode
>
> Visual Studio's C++ standard library headers include intrin.h, so the
> intrinsic
> headers get included a lot more often in Microsoft mode than elsewhere. The
> AVX512 intrinsics are a lot of code (0.7 MB, causing 30% compile time
> overhead
> for small programs including e.g.  and 6% compile time overhead for
> larger projects like e.g. v8). Since multiversioning can't be relied on in
> Microsoft mode (cl.exe doesn't support it), having faster compiles seems
> like
> the much better tradeoff until we have a better intrinsic story going
> forward
> (which we'll need for e.g. PR19898).
>
> Actually using intrinsics on Windows already requires the right /arch:
> settings, so this patch should have no big behavior change.
>
> See also thread "The intrinsics headers (especially avx512) are too big.
> What
> to do about it?" on cfe-dev.
>
> http://reviews.llvm.org/D20291
>
> Modified:
> cfe/trunk/lib/Headers/immintrin.h
> cfe/trunk/lib/Headers/x86intrin.h
> cfe/trunk/test/CodeGen/ms-mm-align.c
>
> Modified: cfe/trunk/lib/Headers/immintrin.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/immintrin.h?rev=269675=269674=269675=diff
>
> ==
> --- cfe/trunk/lib/Headers/immintrin.h (original)
> +++ cfe/trunk/lib/Headers/immintrin.h Mon May 16 13:14:07 2016
> @@ -24,22 +24,41 @@
>  #ifndef __IMMINTRIN_H
>  #define __IMMINTRIN_H
>
> +#if !defined(_MSC_VER) || __has_feature(modules) || defined(__MMX__)
>  #include 
> +#endif
>
> +#if !defined(_MSC_VER) || __has_feature(modules) || defined(__SSE__)
>  #include 
> +#endif
>
> +#if !defined(_MSC_VER) || __has_feature(modules) || defined(__SSE2__)
>  #include 
> +#endif
>
> +#if !defined(_MSC_VER) || __has_feature(modules) || defined(__SSE3__)
>  #include 
> +#endif
>
> +#if !defined(_MSC_VER) || __has_feature(modules) || defined(__SSSE3__)
>  #include 
> +#endif
>
> +#if !defined(_MSC_VER) || __has_feature(modules) || \
> +(defined(__SSE4_2__) || defined(__SSE4_1__))
>  #include 
> +#endif
>
> +#if !defined(_MSC_VER) || __has_feature(modules) || \
> +(defined(__AES__) || defined(__PCLMUL__))
>  #include 
> +#endif
>
> +#if !defined(_MSC_VER) || __has_feature(modules) || defined(__AVX__)
>  #include 
> +#endif
>
> +#if !defined(_MSC_VER) || __has_feature(modules) || defined(__AVX2__)
>  #include 
>
>  /* The 256-bit versions of functions in f16cintrin.h.
> @@ -54,45 +73,90 @@ _mm256_cvtph_ps(__m128i __a)
>  {
>return (__m256)__builtin_ia32_vcvtph2ps256((__v8hi)__a);
>  }
> +#endif /* __AVX2__ */
>
> +#if !defined(_MSC_VER) || __has_feature(modules) || defined(__BMI__)
>  #include 
> +#endif
>
> +#if !defined(_MSC_VER) || __has_feature(modules) || defined(__BMI2__)
>  #include 
> +#endif
>
> +#if !defined(_MSC_VER) || __has_feature(modules) || defined(__LZCNT__)
>  #include 
> +#endif
>
> +#if !defined(_MSC_VER) || __has_feature(modules) || defined(__FMA__)
>  #include 
> +#endif
>
> +#if !defined(_MSC_VER) || __has_feature(modules) || defined(__AVX512F__)
>  #include 
> +#endif
>
> +#if !defined(_MSC_VER) || __has_feature(modules) || defined(__AVX512VL__)
>  #include 
> +#endif
>
> +#if !defined(_MSC_VER) || __has_feature(modules) || defined(__AVX512BW__)
>  #include 
> +#endif
>
> +#if !defined(_MSC_VER) || __has_feature(modules) || defined(__AVX512CD__)
>  #include 
> +#endif
>
> +#if !defined(_MSC_VER) || __has_feature(modules) || defined(__AVX512DQ__)
>  #include 
> +#endif
>
> +#if !defined(_MSC_VER) || __has_feature(modules) || \
> +(defined(__AVX512VL__) && defined(__AVX512BW__))
>  #include 
> +#endif
>
> +#if !defined(_MSC_VER) || __has_feature(modules) || \
> +(defined(__AVX512VL__) && defined(__AVX512CD__))
>  #include 
> +#endif
>
> +#if !defined(_MSC_VER) || __has_feature(modules) || \
> +(defined(__AVX512VL__) && defined(__AVX512DQ__))
>  #include 
> +#endif
>
> +#if !defined(_MSC_VER) || __has_feature(modules) || defined(__AVX512ER__)
>  #include 
> +#endif
>
> +#if !defined(_MSC_VER) || __has_feature(modules) ||
> defined(__AVX512IFMA__)
>  #include 
> +#endif
>
> +#if !defined(_MSC_VER) || __has_feature(modules) 

Re: [libcxx] r269789 - Implement LWG2576: istream_iterator and ostream_iterator should use std::addressof

[Richard Smith via cfe-commits]

Here's an istream_iterator test for this change:

#include 
#include 
#include 

struct evil_traits : std::char_traits {
  template friend void operator&(T) = delete;
};

struct pointless_derived_class
: std::num_get> {};

int main() {
  std::basic_stringstream ss("1 2 3");
  ss.imbue(std::locale(ss.getloc(), new pointless_derived_class));

  using II = std::istream_iterator;
  int n = 0;
  for (auto i = II(ss), e = II(); i != e; ++i)
n += *i;
  assert(n == 6);
}

PS: locales suck.

On Tue, May 17, 2016 at 2:09 PM, Eric Fiselier via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> OK, I think I figured it out. I added tests for the ostream_iterator
> constructors in r269838.
> I'll follow that up with tests for the istream_iterator constructors, but
> my current test is failing for reasons beyond me.
>
> /Eric
>
> On Tue, May 17, 2016 at 2:36 PM, Eric Fiselier  wrote:
>
>> Or maybe I'm still wrong. I tried using a custom traits class to hijack
>> ADL for "operator&" but it doesn't seem to work.
>>
>> Sorry for the spam.
>>
>> /Eric
>>
>> On Tue, May 17, 2016 at 2:25 PM, Eric Fiselier  wrote:
>>
>>> Woops. I was incorrect. It seems that user defined "operator&" overloads
>>> can be found in the constructor. From the LWG issue:
>>>
>>> > Note that {i,o}stream_type are specializations of basic_{i,o}stream,
>>> but the constructors might still pick up an overloaded & via the traits
>>> template parameter.
>>>
>>> At least that also tells us how to test it.
>>>
>>> /Eric
>>>
>>> On Tue, May 17, 2016 at 2:08 PM, Eric Fiselier  wrote:
>>>
 The difference between "operator&" and "addressof"  is inconsequential
 when user defined overloads of "operator&" can't be found, which is the
 case for the changes in the stream iterator constructors. We might as well
 keep it consistent though. I don't see any value changing it back to use
 "operator&" in either the library or the standard.

 /Eric

 On Tue, May 17, 2016 at 2:02 PM, David Blaikie 
 wrote:

> If some parts are not testable & as you say, not meaningful, then it
> seems OK to just not implement them & file a DR on the standard, no?
>
> On Tue, May 17, 2016 at 1:00 PM, Eric Fiselier  wrote:
>
>> I added a test for operator->() in r269812. Marshall and I discussed
>> offline about how not all parts of this change are testable (and hence 
>> not
>> meaningful) but that's what the standard says to do.
>>
>>
>> On Tue, May 17, 2016 at 1:51 PM, David Blaikie via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Test coverage?
>>>
>>> On Tue, May 17, 2016 at 10:44 AM, Marshall Clow via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
 Author: marshall
 Date: Tue May 17 12:44:40 2016
 New Revision: 269789

 URL: http://llvm.org/viewvc/llvm-project?rev=269789=rev
 Log:
 Implement LWG2576: istream_iterator and ostream_iterator should use
 std::addressof

 Modified:
 libcxx/trunk/include/iterator
 libcxx/trunk/www/cxx1z_status.html

 Modified: libcxx/trunk/include/iterator
 URL:
 http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/iterator?rev=269789=269788=269789=diff

 ==
 --- libcxx/trunk/include/iterator (original)
 +++ libcxx/trunk/include/iterator Tue May 17 12:44:40 2016
 @@ -772,14 +772,14 @@ private:
  _Tp __value_;
  public:
  _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR istream_iterator()
 : __in_stream_(0), __value_() {}
 -_LIBCPP_INLINE_VISIBILITY istream_iterator(istream_type& __s)
 : __in_stream_(&__s)
 +_LIBCPP_INLINE_VISIBILITY istream_iterator(istream_type& __s)
 : __in_stream_(_VSTD::addressof(__s))
  {
  if (!(*__in_stream_ >> __value_))
  __in_stream_ = 0;
  }

  _LIBCPP_INLINE_VISIBILITY const _Tp& operator*() const {return
 __value_;}
 -_LIBCPP_INLINE_VISIBILITY const _Tp* operator->() const
 {return &(operator*());}
 +_LIBCPP_INLINE_VISIBILITY const _Tp* operator->() const
 {return _VSTD::addressof((operator*()));}
  _LIBCPP_INLINE_VISIBILITY istream_iterator& operator++()
  {
  if (!(*__in_stream_ >> __value_))
 @@ -811,9 +811,9 @@ private:
  const char_type* __delim_;
  public:
  _LIBCPP_INLINE_VISIBILITY ostream_iterator(ostream_type& __s)
 -: 

Re: [PATCH] D20336: [AMDGPU] Remove individual debugger options + update features

[Konstantin Zhuravlyov via cfe-commits]

kzhuravl retitled this revision from "[AMDGPU] Remove individual debugger 
options" to "[AMDGPU] Remove individual debugger options + update features".
kzhuravl updated this revision to Diff 57518.
kzhuravl added a comment.

Update features


http://reviews.llvm.org/D20336

Files:
  include/clang/Driver/Options.td
  lib/Driver/Tools.cpp
  test/Driver/amdgpu-features.c

Index: test/Driver/amdgpu-features.c
===
--- test/Driver/amdgpu-features.c
+++ test/Driver/amdgpu-features.c
@@ -8,14 +8,4 @@
 // -mamdgpu-debugger-abi=1.0
 // RUN: %clang -### -target amdgcn -x cl -S -emit-llvm -mcpu=kaveri 
-mamdgpu-debugger-abi=1.0 %s -o 2>&1 \
 // RUN:   | FileCheck --check-prefix=CHECK-MAMDGPU-DEBUGGER-ABI-1-0 %s
-// CHECK-MAMDGPU-DEBUGGER-ABI-1-0: "-target-feature" 
"+amdgpu-debugger-insert-nops" "-target-feature" 
"+amdgpu-debugger-reserve-trap-regs"
-//
-// -mamdgpu-debugger-insert-nops
-// RUN: %clang -### -target amdgcn -x cl -S -emit-llvm -mcpu=kaveri 
-mamdgpu-debugger-insert-nops %s -o 2>&1 \
-// RUN:   | FileCheck --check-prefix=CHECK-MAMDGPU-DEBUGGER-INSERT-NOPS %s
-// CHECK-MAMDGPU-DEBUGGER-INSERT-NOPS: "-target-feature" 
"+amdgpu-debugger-insert-nops"
-//
-// -mamdgpu-debugger-reserve-trap-regs
-// RUN: %clang -### -target amdgcn -x cl -S -emit-llvm -mcpu=kaveri 
-mamdgpu-debugger-reserve-trap-regs %s -o 2>&1 \
-// RUN:   | FileCheck --check-prefix=CHECK-MAMDGPU-DEBUGGER-RESERVE-TRAP-REGS 
%s
-// CHECK-MAMDGPU-DEBUGGER-RESERVE-TRAP-REGS: "-target-feature" 
"+amdgpu-debugger-reserve-trap-regs"
+// CHECK-MAMDGPU-DEBUGGER-ABI-1-0: "-target-feature" 
"+amdgpu-debugger-insert-nops" "-target-feature" 
"+amdgpu-debugger-reserve-regs" "-target-feature" 
"+amdgpu-debugger-emit-prologue"
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -2419,7 +2419,8 @@
 StringRef value = dAbi->getValue();
 if (value == "1.0") {
   Features.push_back("+amdgpu-debugger-insert-nops");
-  Features.push_back("+amdgpu-debugger-reserve-trap-regs");
+  Features.push_back("+amdgpu-debugger-reserve-regs");
+  Features.push_back("+amdgpu-debugger-emit-prologue");
 } else {
   D.Diag(diag::err_drv_clang_unsupported) << dAbi->getAsString(Args);
 }
Index: include/clang/Driver/Options.td
===
--- include/clang/Driver/Options.td
+++ include/clang/Driver/Options.td
@@ -1472,10 +1472,6 @@
   Group,
   HelpText<"Generate additional code for specified  of debugger ABI 
(AMDGPU only)">,
   MetaVarName<"">;
-def mamdgpu_debugger_insert_nops : Flag<["-"], "mamdgpu-debugger-insert-nops">,
-  Group;
-def mamdgpu_debugger_reserve_trap_regs : Flag<["-"], 
"mamdgpu-debugger-reserve-trap-regs">,
-  Group;
 
 def mvsx : Flag<["-"], "mvsx">, Group;
 def mno_vsx : Flag<["-"], "mno-vsx">, Group;


Index: test/Driver/amdgpu-features.c
===
--- test/Driver/amdgpu-features.c
+++ test/Driver/amdgpu-features.c
@@ -8,14 +8,4 @@
 // -mamdgpu-debugger-abi=1.0
 // RUN: %clang -### -target amdgcn -x cl -S -emit-llvm -mcpu=kaveri -mamdgpu-debugger-abi=1.0 %s -o 2>&1 \
 // RUN:   | FileCheck --check-prefix=CHECK-MAMDGPU-DEBUGGER-ABI-1-0 %s
-// CHECK-MAMDGPU-DEBUGGER-ABI-1-0: "-target-feature" "+amdgpu-debugger-insert-nops" "-target-feature" "+amdgpu-debugger-reserve-trap-regs"
-//
-// -mamdgpu-debugger-insert-nops
-// RUN: %clang -### -target amdgcn -x cl -S -emit-llvm -mcpu=kaveri -mamdgpu-debugger-insert-nops %s -o 2>&1 \
-// RUN:   | FileCheck --check-prefix=CHECK-MAMDGPU-DEBUGGER-INSERT-NOPS %s
-// CHECK-MAMDGPU-DEBUGGER-INSERT-NOPS: "-target-feature" "+amdgpu-debugger-insert-nops"
-//
-// -mamdgpu-debugger-reserve-trap-regs
-// RUN: %clang -### -target amdgcn -x cl -S -emit-llvm -mcpu=kaveri -mamdgpu-debugger-reserve-trap-regs %s -o 2>&1 \
-// RUN:   | FileCheck --check-prefix=CHECK-MAMDGPU-DEBUGGER-RESERVE-TRAP-REGS %s
-// CHECK-MAMDGPU-DEBUGGER-RESERVE-TRAP-REGS: "-target-feature" "+amdgpu-debugger-reserve-trap-regs"
+// CHECK-MAMDGPU-DEBUGGER-ABI-1-0: "-target-feature" "+amdgpu-debugger-insert-nops" "-target-feature" "+amdgpu-debugger-reserve-regs" "-target-feature" "+amdgpu-debugger-emit-prologue"
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -2419,7 +2419,8 @@
 StringRef value = dAbi->getValue();
 if (value == "1.0") {
   Features.push_back("+amdgpu-debugger-insert-nops");
-  Features.push_back("+amdgpu-debugger-reserve-trap-regs");
+  Features.push_back("+amdgpu-debugger-reserve-regs");
+  Features.push_back("+amdgpu-debugger-emit-prologue");
 } else {
   D.Diag(diag::err_drv_clang_unsupported) << dAbi->getAsString(Args);
 }
Index: include/clang/Driver/Options.td

Re: [PATCH] D19105: Changes in clang after running http://reviews.llvm.org/D18821

[Alexander Kornienko via cfe-commits]

alexfh added a comment.

In http://reviews.llvm.org/D19105#427046, @Prazek wrote:

> In http://reviews.llvm.org/D19105#426903, @alexfh wrote:
>
> > returning a bool from a function that is declared to return a typedef to an 
> > integral type that contains `bool` in its name (e.g. `LLVMBool`), and maybe 
> > some other cases.
>
>
> Isn't it LLVMBool issue?
>
> I won't have enough time to fix it, so I would prefer to comment fixit and 
> only push warnings.


Whether we disable fixits or not, there seem to be too many false positives for 
the check to be useful. We should fix at least cases like `bool b; ... if (b == 
true) ...` and `bool b; ... b ^= true;`.


http://reviews.llvm.org/D19105



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

Re: [libcxx] r269789 - Implement LWG2576: istream_iterator and ostream_iterator should use std::addressof

[Eric Fiselier via cfe-commits]

OK, I think I figured it out. I added tests for the ostream_iterator
constructors in r269838.
I'll follow that up with tests for the istream_iterator constructors, but
my current test is failing for reasons beyond me.

/Eric

On Tue, May 17, 2016 at 2:36 PM, Eric Fiselier  wrote:

> Or maybe I'm still wrong. I tried using a custom traits class to hijack
> ADL for "operator&" but it doesn't seem to work.
>
> Sorry for the spam.
>
> /Eric
>
> On Tue, May 17, 2016 at 2:25 PM, Eric Fiselier  wrote:
>
>> Woops. I was incorrect. It seems that user defined "operator&" overloads
>> can be found in the constructor. From the LWG issue:
>>
>> > Note that {i,o}stream_type are specializations of basic_{i,o}stream,
>> but the constructors might still pick up an overloaded & via the traits
>> template parameter.
>>
>> At least that also tells us how to test it.
>>
>> /Eric
>>
>> On Tue, May 17, 2016 at 2:08 PM, Eric Fiselier  wrote:
>>
>>> The difference between "operator&" and "addressof"  is inconsequential
>>> when user defined overloads of "operator&" can't be found, which is the
>>> case for the changes in the stream iterator constructors. We might as well
>>> keep it consistent though. I don't see any value changing it back to use
>>> "operator&" in either the library or the standard.
>>>
>>> /Eric
>>>
>>> On Tue, May 17, 2016 at 2:02 PM, David Blaikie 
>>> wrote:
>>>
 If some parts are not testable & as you say, not meaningful, then it
 seems OK to just not implement them & file a DR on the standard, no?

 On Tue, May 17, 2016 at 1:00 PM, Eric Fiselier  wrote:

> I added a test for operator->() in r269812. Marshall and I discussed
> offline about how not all parts of this change are testable (and hence not
> meaningful) but that's what the standard says to do.
>
>
> On Tue, May 17, 2016 at 1:51 PM, David Blaikie via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Test coverage?
>>
>> On Tue, May 17, 2016 at 10:44 AM, Marshall Clow via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: marshall
>>> Date: Tue May 17 12:44:40 2016
>>> New Revision: 269789
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=269789=rev
>>> Log:
>>> Implement LWG2576: istream_iterator and ostream_iterator should use
>>> std::addressof
>>>
>>> Modified:
>>> libcxx/trunk/include/iterator
>>> libcxx/trunk/www/cxx1z_status.html
>>>
>>> Modified: libcxx/trunk/include/iterator
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/iterator?rev=269789=269788=269789=diff
>>>
>>> ==
>>> --- libcxx/trunk/include/iterator (original)
>>> +++ libcxx/trunk/include/iterator Tue May 17 12:44:40 2016
>>> @@ -772,14 +772,14 @@ private:
>>>  _Tp __value_;
>>>  public:
>>>  _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR istream_iterator()
>>> : __in_stream_(0), __value_() {}
>>> -_LIBCPP_INLINE_VISIBILITY istream_iterator(istream_type& __s) :
>>> __in_stream_(&__s)
>>> +_LIBCPP_INLINE_VISIBILITY istream_iterator(istream_type& __s) :
>>> __in_stream_(_VSTD::addressof(__s))
>>>  {
>>>  if (!(*__in_stream_ >> __value_))
>>>  __in_stream_ = 0;
>>>  }
>>>
>>>  _LIBCPP_INLINE_VISIBILITY const _Tp& operator*() const {return
>>> __value_;}
>>> -_LIBCPP_INLINE_VISIBILITY const _Tp* operator->() const {return
>>> &(operator*());}
>>> +_LIBCPP_INLINE_VISIBILITY const _Tp* operator->() const {return
>>> _VSTD::addressof((operator*()));}
>>>  _LIBCPP_INLINE_VISIBILITY istream_iterator& operator++()
>>>  {
>>>  if (!(*__in_stream_ >> __value_))
>>> @@ -811,9 +811,9 @@ private:
>>>  const char_type* __delim_;
>>>  public:
>>>  _LIBCPP_INLINE_VISIBILITY ostream_iterator(ostream_type& __s)
>>> -: __out_stream_(&__s), __delim_(0) {}
>>> +: __out_stream_(_VSTD::addressof(__s)), __delim_(0) {}
>>>  _LIBCPP_INLINE_VISIBILITY ostream_iterator(ostream_type& __s,
>>> const _CharT* __delimiter)
>>> -: __out_stream_(&__s), __delim_(__delimiter) {}
>>> +: __out_stream_(_VSTD::addressof(__s)),
>>> __delim_(__delimiter) {}
>>>  _LIBCPP_INLINE_VISIBILITY ostream_iterator& operator=(const
>>> _Tp& __value_)
>>>  {
>>>  *__out_stream_ << __value_;
>>>
>>> Modified: libcxx/trunk/www/cxx1z_status.html
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/libcxx/trunk/www/cxx1z_status.html?rev=269789=269788=269789=diff
>>>
>>> ==
>>> --- 

[libcxx] r269838 - Test hijacking ADL for operator& in the stream iterator constructors.

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Tue May 17 16:01:20 2016
New Revision: 269838

URL: http://llvm.org/viewvc/llvm-project?rev=269838=rev
Log:
Test hijacking ADL for operator& in the stream iterator constructors.

Modified:

libcxx/trunk/test/std/iterators/stream.iterators/ostream.iterator/ostream.iterator.cons.des/ostream.pass.cpp

libcxx/trunk/test/std/iterators/stream.iterators/ostream.iterator/ostream.iterator.cons.des/ostream_delim.pass.cpp

Modified: 
libcxx/trunk/test/std/iterators/stream.iterators/ostream.iterator/ostream.iterator.cons.des/ostream.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/iterators/stream.iterators/ostream.iterator/ostream.iterator.cons.des/ostream.pass.cpp?rev=269838=269837=269838=diff
==
--- 
libcxx/trunk/test/std/iterators/stream.iterators/ostream.iterator/ostream.iterator.cons.des/ostream.pass.cpp
 (original)
+++ 
libcxx/trunk/test/std/iterators/stream.iterators/ostream.iterator/ostream.iterator.cons.des/ostream.pass.cpp
 Tue May 17 16:01:20 2016
@@ -17,9 +17,23 @@
 #include 
 #include 
 
+struct MyTraits : std::char_traits {};
+
+typedef std::basic_ostringstream StringStream;
+typedef std::basic_ostream BasicStream;
+
+void operator&(BasicStream const&) {}
+
 int main()
 {
-std::ostringstream outf;
-std::ostream_iterator i(outf);
-assert(outf.good());
+{
+std::ostringstream outf;
+std::ostream_iterator i(outf);
+assert(outf.good());
+}
+{
+StringStream outf;
+std::ostream_iterator i(outf);
+assert(outf.good());
+}
 }

Modified: 
libcxx/trunk/test/std/iterators/stream.iterators/ostream.iterator/ostream.iterator.cons.des/ostream_delim.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/iterators/stream.iterators/ostream.iterator/ostream.iterator.cons.des/ostream_delim.pass.cpp?rev=269838=269837=269838=diff
==
--- 
libcxx/trunk/test/std/iterators/stream.iterators/ostream.iterator/ostream.iterator.cons.des/ostream_delim.pass.cpp
 (original)
+++ 
libcxx/trunk/test/std/iterators/stream.iterators/ostream.iterator/ostream.iterator.cons.des/ostream_delim.pass.cpp
 Tue May 17 16:01:20 2016
@@ -17,6 +17,14 @@
 #include 
 #include 
 
+
+struct MyTraits : std::char_traits {};
+
+typedef std::basic_ostringstream StringStream;
+typedef std::basic_ostream BasicStream;
+
+void operator&(BasicStream const&) {}
+
 int main()
 {
 {
@@ -29,4 +37,9 @@ int main()
 std::ostream_iterator i(outf, L", ");
 assert(outf.good());
 }
+{
+StringStream outf;
+std::ostream_iterator i(outf, ", ");
+assert(outf.good());
+}
 }


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

[PATCH] D20336: [AMDGPU] Remove individual debugger options

[Konstantin Zhuravlyov via cfe-commits]

kzhuravl created this revision.
kzhuravl added a reviewer: arsenm.
kzhuravl added subscribers: whchung, cfe-commits.
Herald added a reviewer: tstellarAMD.
Herald added a subscriber: kzhuravl.

http://reviews.llvm.org/D20336

Files:
  include/clang/Driver/Options.td
  test/Driver/amdgpu-features.c

Index: test/Driver/amdgpu-features.c
===
--- test/Driver/amdgpu-features.c
+++ test/Driver/amdgpu-features.c
@@ -9,13 +9,3 @@
 // RUN: %clang -### -target amdgcn -x cl -S -emit-llvm -mcpu=kaveri 
-mamdgpu-debugger-abi=1.0 %s -o 2>&1 \
 // RUN:   | FileCheck --check-prefix=CHECK-MAMDGPU-DEBUGGER-ABI-1-0 %s
 // CHECK-MAMDGPU-DEBUGGER-ABI-1-0: "-target-feature" 
"+amdgpu-debugger-insert-nops" "-target-feature" 
"+amdgpu-debugger-reserve-trap-regs"
-//
-// -mamdgpu-debugger-insert-nops
-// RUN: %clang -### -target amdgcn -x cl -S -emit-llvm -mcpu=kaveri 
-mamdgpu-debugger-insert-nops %s -o 2>&1 \
-// RUN:   | FileCheck --check-prefix=CHECK-MAMDGPU-DEBUGGER-INSERT-NOPS %s
-// CHECK-MAMDGPU-DEBUGGER-INSERT-NOPS: "-target-feature" 
"+amdgpu-debugger-insert-nops"
-//
-// -mamdgpu-debugger-reserve-trap-regs
-// RUN: %clang -### -target amdgcn -x cl -S -emit-llvm -mcpu=kaveri 
-mamdgpu-debugger-reserve-trap-regs %s -o 2>&1 \
-// RUN:   | FileCheck --check-prefix=CHECK-MAMDGPU-DEBUGGER-RESERVE-TRAP-REGS 
%s
-// CHECK-MAMDGPU-DEBUGGER-RESERVE-TRAP-REGS: "-target-feature" 
"+amdgpu-debugger-reserve-trap-regs"
Index: include/clang/Driver/Options.td
===
--- include/clang/Driver/Options.td
+++ include/clang/Driver/Options.td
@@ -1472,10 +1472,6 @@
   Group,
   HelpText<"Generate additional code for specified  of debugger ABI 
(AMDGPU only)">,
   MetaVarName<"">;
-def mamdgpu_debugger_insert_nops : Flag<["-"], "mamdgpu-debugger-insert-nops">,
-  Group;
-def mamdgpu_debugger_reserve_trap_regs : Flag<["-"], 
"mamdgpu-debugger-reserve-trap-regs">,
-  Group;
 
 def mvsx : Flag<["-"], "mvsx">, Group;
 def mno_vsx : Flag<["-"], "mno-vsx">, Group;


Index: test/Driver/amdgpu-features.c
===
--- test/Driver/amdgpu-features.c
+++ test/Driver/amdgpu-features.c
@@ -9,13 +9,3 @@
 // RUN: %clang -### -target amdgcn -x cl -S -emit-llvm -mcpu=kaveri -mamdgpu-debugger-abi=1.0 %s -o 2>&1 \
 // RUN:   | FileCheck --check-prefix=CHECK-MAMDGPU-DEBUGGER-ABI-1-0 %s
 // CHECK-MAMDGPU-DEBUGGER-ABI-1-0: "-target-feature" "+amdgpu-debugger-insert-nops" "-target-feature" "+amdgpu-debugger-reserve-trap-regs"
-//
-// -mamdgpu-debugger-insert-nops
-// RUN: %clang -### -target amdgcn -x cl -S -emit-llvm -mcpu=kaveri -mamdgpu-debugger-insert-nops %s -o 2>&1 \
-// RUN:   | FileCheck --check-prefix=CHECK-MAMDGPU-DEBUGGER-INSERT-NOPS %s
-// CHECK-MAMDGPU-DEBUGGER-INSERT-NOPS: "-target-feature" "+amdgpu-debugger-insert-nops"
-//
-// -mamdgpu-debugger-reserve-trap-regs
-// RUN: %clang -### -target amdgcn -x cl -S -emit-llvm -mcpu=kaveri -mamdgpu-debugger-reserve-trap-regs %s -o 2>&1 \
-// RUN:   | FileCheck --check-prefix=CHECK-MAMDGPU-DEBUGGER-RESERVE-TRAP-REGS %s
-// CHECK-MAMDGPU-DEBUGGER-RESERVE-TRAP-REGS: "-target-feature" "+amdgpu-debugger-reserve-trap-regs"
Index: include/clang/Driver/Options.td
===
--- include/clang/Driver/Options.td
+++ include/clang/Driver/Options.td
@@ -1472,10 +1472,6 @@
   Group,
   HelpText<"Generate additional code for specified  of debugger ABI (AMDGPU only)">,
   MetaVarName<"">;
-def mamdgpu_debugger_insert_nops : Flag<["-"], "mamdgpu-debugger-insert-nops">,
-  Group;
-def mamdgpu_debugger_reserve_trap_regs : Flag<["-"], "mamdgpu-debugger-reserve-trap-regs">,
-  Group;
 
 def mvsx : Flag<["-"], "mvsx">, Group;
 def mno_vsx : Flag<["-"], "mno-vsx">, Group;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: Patch submission for bug 27400

[Mads Ravn via cfe-commits]

Cool :) don't the sweat the time. I was just a little excited. Small patch
but it's nice to get started somewhere.

Best regards,
Mads Ravn

> On May 17, 2016, at 2:59 AM, Mads Ravn  wrote:
>
> Hi guys,
>
> I just wanted to check up on this patch. I heard I could just reply to
this mail and see if I could 'ping' anyone in this regard. Hope it's OK.

Sorry for the delay! This looks good. Committed as r269786.

thanks,
vedant

>
> Best regards,
> Mads Ravn
>
> On Thu, May 12, 2016 at 6:11 PM Mads Ravn  wrote:
> Hi,
>
> I have fixed the things you mentioned now. I have attached the new patch
to this email.
>
> Best regards,
> Mads Ravn
>
> On Wed, May 11, 2016 at 11:54 PM Vedant Kumar  wrote:
> Hi,
>
> Thanks for the patch!
>
> This patch is missing a small, lit-style test case. You can find examples
of test cases here:
>
>   extra/test/clang-tidy/
>
> Apart from that, my only other nit-pick is that llvm uses 2-space
indents, and spaces between "if" and "(".
>
> If you reply to this list with an updated patch, someone would be happy
to commit it for you.
>
> best
> vedant
>
> > On May 11, 2016, at 10:01 AM, Mads Ravn via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> >
> > Hi,
> >
> > I would like to submit a patch for
https://llvm.org/bugs/show_bug.cgi?id=27400 .
> >
> > Beside attaching the patch, is there anything I should be aware of? I
have not submitted a patch before.
> >
> > You can find the patch attached to this mail.
> >
> > Kind regards,
> > Mads Ravn
> >
___
> > 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] D16989: Change interpretation of function definition in friend declaration of template class.

[Richard Smith via cfe-commits]

rsmith added a comment.

Please also add some testcases for the corresponding case for a friend function 
template:

  template void f();
  template struct A {
template void f() {}
  };
  template struct B {
template void f() {}
  };
  A a;
  B b; // ill-formed



Comment at: test/SemaCXX/PR25848.cpp:4
@@ +3,3 @@
+struct A;
+typedef int A::* P;
+

Maybe use `int` instead of a pointer to member type here? May as well keep the 
parts that aren't relevant to the test as simple as possible.


Comment at: test/SemaCXX/friend2.cpp:77
@@ +76,3 @@
+// Even if clases are not instantiated and hence friend functions defined in 
them are not
+// available, their declarations must be checked.
+

"must be" -> "can be" (or maybe "should be")

We're not required to diagnose this; it's a QoI issue.


http://reviews.llvm.org/D16989



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

Re: [libcxx] r269789 - Implement LWG2576: istream_iterator and ostream_iterator should use std::addressof

[Eric Fiselier via cfe-commits]

Or maybe I'm still wrong. I tried using a custom traits class to hijack ADL
for "operator&" but it doesn't seem to work.

Sorry for the spam.

/Eric

On Tue, May 17, 2016 at 2:25 PM, Eric Fiselier  wrote:

> Woops. I was incorrect. It seems that user defined "operator&" overloads
> can be found in the constructor. From the LWG issue:
>
> > Note that {i,o}stream_type are specializations of basic_{i,o}stream, but
> the constructors might still pick up an overloaded & via the traits
> template parameter.
>
> At least that also tells us how to test it.
>
> /Eric
>
> On Tue, May 17, 2016 at 2:08 PM, Eric Fiselier  wrote:
>
>> The difference between "operator&" and "addressof"  is inconsequential
>> when user defined overloads of "operator&" can't be found, which is the
>> case for the changes in the stream iterator constructors. We might as well
>> keep it consistent though. I don't see any value changing it back to use
>> "operator&" in either the library or the standard.
>>
>> /Eric
>>
>> On Tue, May 17, 2016 at 2:02 PM, David Blaikie 
>> wrote:
>>
>>> If some parts are not testable & as you say, not meaningful, then it
>>> seems OK to just not implement them & file a DR on the standard, no?
>>>
>>> On Tue, May 17, 2016 at 1:00 PM, Eric Fiselier  wrote:
>>>
 I added a test for operator->() in r269812. Marshall and I discussed
 offline about how not all parts of this change are testable (and hence not
 meaningful) but that's what the standard says to do.


 On Tue, May 17, 2016 at 1:51 PM, David Blaikie via cfe-commits <
 cfe-commits@lists.llvm.org> wrote:

> Test coverage?
>
> On Tue, May 17, 2016 at 10:44 AM, Marshall Clow via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: marshall
>> Date: Tue May 17 12:44:40 2016
>> New Revision: 269789
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=269789=rev
>> Log:
>> Implement LWG2576: istream_iterator and ostream_iterator should use
>> std::addressof
>>
>> Modified:
>> libcxx/trunk/include/iterator
>> libcxx/trunk/www/cxx1z_status.html
>>
>> Modified: libcxx/trunk/include/iterator
>> URL:
>> http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/iterator?rev=269789=269788=269789=diff
>>
>> ==
>> --- libcxx/trunk/include/iterator (original)
>> +++ libcxx/trunk/include/iterator Tue May 17 12:44:40 2016
>> @@ -772,14 +772,14 @@ private:
>>  _Tp __value_;
>>  public:
>>  _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR istream_iterator() :
>> __in_stream_(0), __value_() {}
>> -_LIBCPP_INLINE_VISIBILITY istream_iterator(istream_type& __s) :
>> __in_stream_(&__s)
>> +_LIBCPP_INLINE_VISIBILITY istream_iterator(istream_type& __s) :
>> __in_stream_(_VSTD::addressof(__s))
>>  {
>>  if (!(*__in_stream_ >> __value_))
>>  __in_stream_ = 0;
>>  }
>>
>>  _LIBCPP_INLINE_VISIBILITY const _Tp& operator*() const {return
>> __value_;}
>> -_LIBCPP_INLINE_VISIBILITY const _Tp* operator->() const {return
>> &(operator*());}
>> +_LIBCPP_INLINE_VISIBILITY const _Tp* operator->() const {return
>> _VSTD::addressof((operator*()));}
>>  _LIBCPP_INLINE_VISIBILITY istream_iterator& operator++()
>>  {
>>  if (!(*__in_stream_ >> __value_))
>> @@ -811,9 +811,9 @@ private:
>>  const char_type* __delim_;
>>  public:
>>  _LIBCPP_INLINE_VISIBILITY ostream_iterator(ostream_type& __s)
>> -: __out_stream_(&__s), __delim_(0) {}
>> +: __out_stream_(_VSTD::addressof(__s)), __delim_(0) {}
>>  _LIBCPP_INLINE_VISIBILITY ostream_iterator(ostream_type& __s,
>> const _CharT* __delimiter)
>> -: __out_stream_(&__s), __delim_(__delimiter) {}
>> +: __out_stream_(_VSTD::addressof(__s)),
>> __delim_(__delimiter) {}
>>  _LIBCPP_INLINE_VISIBILITY ostream_iterator& operator=(const _Tp&
>> __value_)
>>  {
>>  *__out_stream_ << __value_;
>>
>> Modified: libcxx/trunk/www/cxx1z_status.html
>> URL:
>> http://llvm.org/viewvc/llvm-project/libcxx/trunk/www/cxx1z_status.html?rev=269789=269788=269789=diff
>>
>> ==
>> --- libcxx/trunk/www/cxx1z_status.html (original)
>> +++ libcxx/trunk/www/cxx1z_status.html Tue May 17 12:44:40 2016
>> @@ -222,7 +222,7 @@
>> http://cplusplus.github.io/LWG/lwg-defects.html#2572;>2572The
>> remarks for shared_ptr::operator* should apply to
>> cv-qualified void as
>> wellJacksonvilleComplete
>> 

Re: [libcxx] r269789 - Implement LWG2576: istream_iterator and ostream_iterator should use std::addressof

[Eric Fiselier via cfe-commits]

Woops. I was incorrect. It seems that user defined "operator&" overloads
can be found in the constructor. From the LWG issue:

> Note that {i,o}stream_type are specializations of basic_{i,o}stream, but
the constructors might still pick up an overloaded & via the traits
template parameter.

At least that also tells us how to test it.

/Eric

On Tue, May 17, 2016 at 2:08 PM, Eric Fiselier  wrote:

> The difference between "operator&" and "addressof"  is inconsequential
> when user defined overloads of "operator&" can't be found, which is the
> case for the changes in the stream iterator constructors. We might as well
> keep it consistent though. I don't see any value changing it back to use
> "operator&" in either the library or the standard.
>
> /Eric
>
> On Tue, May 17, 2016 at 2:02 PM, David Blaikie  wrote:
>
>> If some parts are not testable & as you say, not meaningful, then it
>> seems OK to just not implement them & file a DR on the standard, no?
>>
>> On Tue, May 17, 2016 at 1:00 PM, Eric Fiselier  wrote:
>>
>>> I added a test for operator->() in r269812. Marshall and I discussed
>>> offline about how not all parts of this change are testable (and hence not
>>> meaningful) but that's what the standard says to do.
>>>
>>>
>>> On Tue, May 17, 2016 at 1:51 PM, David Blaikie via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
 Test coverage?

 On Tue, May 17, 2016 at 10:44 AM, Marshall Clow via cfe-commits <
 cfe-commits@lists.llvm.org> wrote:

> Author: marshall
> Date: Tue May 17 12:44:40 2016
> New Revision: 269789
>
> URL: http://llvm.org/viewvc/llvm-project?rev=269789=rev
> Log:
> Implement LWG2576: istream_iterator and ostream_iterator should use
> std::addressof
>
> Modified:
> libcxx/trunk/include/iterator
> libcxx/trunk/www/cxx1z_status.html
>
> Modified: libcxx/trunk/include/iterator
> URL:
> http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/iterator?rev=269789=269788=269789=diff
>
> ==
> --- libcxx/trunk/include/iterator (original)
> +++ libcxx/trunk/include/iterator Tue May 17 12:44:40 2016
> @@ -772,14 +772,14 @@ private:
>  _Tp __value_;
>  public:
>  _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR istream_iterator() :
> __in_stream_(0), __value_() {}
> -_LIBCPP_INLINE_VISIBILITY istream_iterator(istream_type& __s) :
> __in_stream_(&__s)
> +_LIBCPP_INLINE_VISIBILITY istream_iterator(istream_type& __s) :
> __in_stream_(_VSTD::addressof(__s))
>  {
>  if (!(*__in_stream_ >> __value_))
>  __in_stream_ = 0;
>  }
>
>  _LIBCPP_INLINE_VISIBILITY const _Tp& operator*() const {return
> __value_;}
> -_LIBCPP_INLINE_VISIBILITY const _Tp* operator->() const {return
> &(operator*());}
> +_LIBCPP_INLINE_VISIBILITY const _Tp* operator->() const {return
> _VSTD::addressof((operator*()));}
>  _LIBCPP_INLINE_VISIBILITY istream_iterator& operator++()
>  {
>  if (!(*__in_stream_ >> __value_))
> @@ -811,9 +811,9 @@ private:
>  const char_type* __delim_;
>  public:
>  _LIBCPP_INLINE_VISIBILITY ostream_iterator(ostream_type& __s)
> -: __out_stream_(&__s), __delim_(0) {}
> +: __out_stream_(_VSTD::addressof(__s)), __delim_(0) {}
>  _LIBCPP_INLINE_VISIBILITY ostream_iterator(ostream_type& __s,
> const _CharT* __delimiter)
> -: __out_stream_(&__s), __delim_(__delimiter) {}
> +: __out_stream_(_VSTD::addressof(__s)), __delim_(__delimiter)
> {}
>  _LIBCPP_INLINE_VISIBILITY ostream_iterator& operator=(const _Tp&
> __value_)
>  {
>  *__out_stream_ << __value_;
>
> Modified: libcxx/trunk/www/cxx1z_status.html
> URL:
> http://llvm.org/viewvc/llvm-project/libcxx/trunk/www/cxx1z_status.html?rev=269789=269788=269789=diff
>
> ==
> --- libcxx/trunk/www/cxx1z_status.html (original)
> +++ libcxx/trunk/www/cxx1z_status.html Tue May 17 12:44:40 2016
> @@ -222,7 +222,7 @@
> http://cplusplus.github.io/LWG/lwg-defects.html#2572;>2572The
> remarks for shared_ptr::operator* should apply to
> cv-qualified void as
> wellJacksonvilleComplete
> 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

Re: r269717 - Switch from SmallVector to TinyPtrVector for the list of attributes on a declaration. This removes a memory allocation for the common case where the declaration has only one attribute.

[Richard Smith via cfe-commits]

On Tue, May 17, 2016 at 10:17 AM, David Blaikie via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> On Mon, May 16, 2016 at 3:53 PM, Richard Smith via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: rsmith
>> Date: Mon May 16 17:53:19 2016
>> New Revision: 269717
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=269717=rev
>> Log:
>> Switch from SmallVector to TinyPtrVector for the list of attributes on a
>> declaration. This removes a memory allocation for the common case where the
>> declaration has only one attribute.
>>
>
> Just out of curiosity - if the SmallVector had a small size of 2, why was
> an allocation done for a single attribute?
>

Err, good question. Turns out I forgot to make the actual allocation-saving
change here -- switching ASTContext::DeclAttrs from storing an allocated
AttrVec* to storing an AttrVec. And that in turn is quite painful because
we expose the AttrVec object to people who might cause DeclAttrs to be
resized. I'll see if it's practical to finish this change, and revert if
not.

Modified:
>> cfe/trunk/include/clang/AST/AttrIterator.h
>>
>> Modified: cfe/trunk/include/clang/AST/AttrIterator.h
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/AttrIterator.h?rev=269717=269716=269717=diff
>>
>> ==
>> --- cfe/trunk/include/clang/AST/AttrIterator.h (original)
>> +++ cfe/trunk/include/clang/AST/AttrIterator.h Mon May 16 17:53:19 2016
>> @@ -15,6 +15,7 @@
>>  #define LLVM_CLANG_AST_ATTRITERATOR_H
>>
>>  #include "clang/Basic/LLVM.h"
>> +#include "llvm/ADT/TinyPtrVector.h"
>>  #include 
>>
>>  namespace clang {
>> @@ -39,8 +40,8 @@ void operator delete[](void *Ptr, const
>>  namespace clang {
>>
>>  /// AttrVec - A vector of Attr, which is how they are stored on the AST.
>> -typedef SmallVector AttrVec;
>> -typedef SmallVector ConstAttrVec;
>> +typedef llvm::TinyPtrVector AttrVec;
>> +typedef llvm::TinyPtrVector ConstAttrVec;
>>
>>  /// specific_attr_iterator - Iterates over a subrange of an AttrVec, only
>>  /// providing attributes that are of a specific type.
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D20249: [OpenCL] Hierarchical/dynamic parallelism - enqueue kernel in OpenCL 2.0

[Yaxun Liu via cfe-commits]

yaxunl added inline comments.


Comment at: include/clang/Basic/DiagnosticSemaKinds.td:7820
@@ +7819,3 @@
+def err_opencl_function_not_supported : Error<
+  "this function is not supported in this version of CL">;
+def err_opencl_enqueue_kernel_incorrect_args : Error<

Anastasia wrote:
> This diagnostic should follow the latest version reporting style.
Is it better to move this msg to the generic msg part for OpenCL?


Comment at: lib/CodeGen/CGBuiltin.cpp:2150
@@ +2149,3 @@
+
+if (NumArgs == 4) {
+  // The most basic form of the call with parameters:

Can we remove the non-vararg version and keep only the vararg version? The 
vararg can be empty, so the non-vararg version is redundant.


Comment at: lib/CodeGen/CGBuiltin.cpp:2174
@@ +2173,3 @@
+// express to the runtime the number of variadic arguments.
+std::vector Args{Queue, Flags, Range, Block,
+ConstantInt::get(IntTy, NumVaargs)};

Can we drop NumVaargs? It seem redundant.


Comment at: lib/Sema/SemaChecking.cpp:80
@@ +79,3 @@
+/// void*,
+/// which is a requirement of device side enqueue.
+static bool checkBlockArgs(Sema , Expr *BlockArg) {

joint with the previous line?


Comment at: lib/Sema/SemaChecking.cpp:150
@@ +149,3 @@
+/// void*'
+/// parameter of passed block.
+static bool checkEnqueueVariadicArgs(Sema , CallExpr *TheCall, Expr 
*BlockArg,

joint with previous line?


Comment at: lib/Sema/SemaChecking.cpp:201
@@ +200,3 @@
+///uint size0, ...)
+static bool SemaBuiltinOpenCLEnqueueKernel(Sema , CallExpr *TheCall) {
+  unsigned NumArgs = TheCall->getNumArgs();

rename to SemaOpenCLBuiltin... to be consistent with others?


http://reviews.llvm.org/D20249



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

Re: [libcxx] r269789 - Implement LWG2576: istream_iterator and ostream_iterator should use std::addressof

[Eric Fiselier via cfe-commits]

The difference between "operator&" and "addressof"  is inconsequential when
user defined overloads of "operator&" can't be found, which is the case for
the changes in the stream iterator constructors. We might as well keep it
consistent though. I don't see any value changing it back to use
"operator&" in either the library or the standard.

/Eric

On Tue, May 17, 2016 at 2:02 PM, David Blaikie  wrote:

> If some parts are not testable & as you say, not meaningful, then it seems
> OK to just not implement them & file a DR on the standard, no?
>
> On Tue, May 17, 2016 at 1:00 PM, Eric Fiselier  wrote:
>
>> I added a test for operator->() in r269812. Marshall and I discussed
>> offline about how not all parts of this change are testable (and hence not
>> meaningful) but that's what the standard says to do.
>>
>>
>> On Tue, May 17, 2016 at 1:51 PM, David Blaikie via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Test coverage?
>>>
>>> On Tue, May 17, 2016 at 10:44 AM, Marshall Clow via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
 Author: marshall
 Date: Tue May 17 12:44:40 2016
 New Revision: 269789

 URL: http://llvm.org/viewvc/llvm-project?rev=269789=rev
 Log:
 Implement LWG2576: istream_iterator and ostream_iterator should use
 std::addressof

 Modified:
 libcxx/trunk/include/iterator
 libcxx/trunk/www/cxx1z_status.html

 Modified: libcxx/trunk/include/iterator
 URL:
 http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/iterator?rev=269789=269788=269789=diff

 ==
 --- libcxx/trunk/include/iterator (original)
 +++ libcxx/trunk/include/iterator Tue May 17 12:44:40 2016
 @@ -772,14 +772,14 @@ private:
  _Tp __value_;
  public:
  _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR istream_iterator() :
 __in_stream_(0), __value_() {}
 -_LIBCPP_INLINE_VISIBILITY istream_iterator(istream_type& __s) :
 __in_stream_(&__s)
 +_LIBCPP_INLINE_VISIBILITY istream_iterator(istream_type& __s) :
 __in_stream_(_VSTD::addressof(__s))
  {
  if (!(*__in_stream_ >> __value_))
  __in_stream_ = 0;
  }

  _LIBCPP_INLINE_VISIBILITY const _Tp& operator*() const {return
 __value_;}
 -_LIBCPP_INLINE_VISIBILITY const _Tp* operator->() const {return
 &(operator*());}
 +_LIBCPP_INLINE_VISIBILITY const _Tp* operator->() const {return
 _VSTD::addressof((operator*()));}
  _LIBCPP_INLINE_VISIBILITY istream_iterator& operator++()
  {
  if (!(*__in_stream_ >> __value_))
 @@ -811,9 +811,9 @@ private:
  const char_type* __delim_;
  public:
  _LIBCPP_INLINE_VISIBILITY ostream_iterator(ostream_type& __s)
 -: __out_stream_(&__s), __delim_(0) {}
 +: __out_stream_(_VSTD::addressof(__s)), __delim_(0) {}
  _LIBCPP_INLINE_VISIBILITY ostream_iterator(ostream_type& __s,
 const _CharT* __delimiter)
 -: __out_stream_(&__s), __delim_(__delimiter) {}
 +: __out_stream_(_VSTD::addressof(__s)), __delim_(__delimiter)
 {}
  _LIBCPP_INLINE_VISIBILITY ostream_iterator& operator=(const _Tp&
 __value_)
  {
  *__out_stream_ << __value_;

 Modified: libcxx/trunk/www/cxx1z_status.html
 URL:
 http://llvm.org/viewvc/llvm-project/libcxx/trunk/www/cxx1z_status.html?rev=269789=269788=269789=diff

 ==
 --- libcxx/trunk/www/cxx1z_status.html (original)
 +++ libcxx/trunk/www/cxx1z_status.html Tue May 17 12:44:40 2016
 @@ -222,7 +222,7 @@
 http://cplusplus.github.io/LWG/lwg-defects.html#2572;>2572The
 remarks for shared_ptr::operator* should apply to
 cv-qualified void as
 wellJacksonvilleComplete
 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::addressofJacksonvilleComplete
 http://cplusplus.github.io/LWG/lwg-defects.html#2577;>2577{shared,unique}_lock
 should use
 std::addressofJacksonvilleComplete
 http://cplusplus.github.io/LWG/lwg-defects.html#2579;>2579Inconsistency
 wrt Allocators in basic_string assignment vs.
 

Re: [libcxx] r269789 - Implement LWG2576: istream_iterator and ostream_iterator should use std::addressof

[David Blaikie via cfe-commits]

If some parts are not testable & as you say, not meaningful, then it seems
OK to just not implement them & file a DR on the standard, no?

On Tue, May 17, 2016 at 1:00 PM, Eric Fiselier  wrote:

> I added a test for operator->() in r269812. Marshall and I discussed
> offline about how not all parts of this change are testable (and hence not
> meaningful) but that's what the standard says to do.
>
>
> On Tue, May 17, 2016 at 1:51 PM, David Blaikie via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Test coverage?
>>
>> On Tue, May 17, 2016 at 10:44 AM, Marshall Clow via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: marshall
>>> Date: Tue May 17 12:44:40 2016
>>> New Revision: 269789
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=269789=rev
>>> Log:
>>> Implement LWG2576: istream_iterator and ostream_iterator should use
>>> std::addressof
>>>
>>> Modified:
>>> libcxx/trunk/include/iterator
>>> libcxx/trunk/www/cxx1z_status.html
>>>
>>> Modified: libcxx/trunk/include/iterator
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/iterator?rev=269789=269788=269789=diff
>>>
>>> ==
>>> --- libcxx/trunk/include/iterator (original)
>>> +++ libcxx/trunk/include/iterator Tue May 17 12:44:40 2016
>>> @@ -772,14 +772,14 @@ private:
>>>  _Tp __value_;
>>>  public:
>>>  _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR istream_iterator() :
>>> __in_stream_(0), __value_() {}
>>> -_LIBCPP_INLINE_VISIBILITY istream_iterator(istream_type& __s) :
>>> __in_stream_(&__s)
>>> +_LIBCPP_INLINE_VISIBILITY istream_iterator(istream_type& __s) :
>>> __in_stream_(_VSTD::addressof(__s))
>>>  {
>>>  if (!(*__in_stream_ >> __value_))
>>>  __in_stream_ = 0;
>>>  }
>>>
>>>  _LIBCPP_INLINE_VISIBILITY const _Tp& operator*() const {return
>>> __value_;}
>>> -_LIBCPP_INLINE_VISIBILITY const _Tp* operator->() const {return
>>> &(operator*());}
>>> +_LIBCPP_INLINE_VISIBILITY const _Tp* operator->() const {return
>>> _VSTD::addressof((operator*()));}
>>>  _LIBCPP_INLINE_VISIBILITY istream_iterator& operator++()
>>>  {
>>>  if (!(*__in_stream_ >> __value_))
>>> @@ -811,9 +811,9 @@ private:
>>>  const char_type* __delim_;
>>>  public:
>>>  _LIBCPP_INLINE_VISIBILITY ostream_iterator(ostream_type& __s)
>>> -: __out_stream_(&__s), __delim_(0) {}
>>> +: __out_stream_(_VSTD::addressof(__s)), __delim_(0) {}
>>>  _LIBCPP_INLINE_VISIBILITY ostream_iterator(ostream_type& __s, const
>>> _CharT* __delimiter)
>>> -: __out_stream_(&__s), __delim_(__delimiter) {}
>>> +: __out_stream_(_VSTD::addressof(__s)), __delim_(__delimiter) {}
>>>  _LIBCPP_INLINE_VISIBILITY ostream_iterator& operator=(const _Tp&
>>> __value_)
>>>  {
>>>  *__out_stream_ << __value_;
>>>
>>> Modified: libcxx/trunk/www/cxx1z_status.html
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/libcxx/trunk/www/cxx1z_status.html?rev=269789=269788=269789=diff
>>>
>>> ==
>>> --- libcxx/trunk/www/cxx1z_status.html (original)
>>> +++ libcxx/trunk/www/cxx1z_status.html Tue May 17 12:44:40 2016
>>> @@ -222,7 +222,7 @@
>>> http://cplusplus.github.io/LWG/lwg-defects.html#2572;>2572The
>>> remarks for shared_ptr::operator* should apply to
>>> cv-qualified void as
>>> wellJacksonvilleComplete
>>> 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::addressofJacksonvilleComplete
>>> http://cplusplus.github.io/LWG/lwg-defects.html#2577;>2577{shared,unique}_lock
>>> should use
>>> std::addressofJacksonvilleComplete
>>> http://cplusplus.github.io/LWG/lwg-defects.html#2579;>2579Inconsistency
>>> wrt Allocators in basic_string assignment vs.
>>> basic_string::assignJacksonvilleComplete
>>> http://cplusplus.github.io/LWG/lwg-defects.html#2581;>2581Specialization
>>> of type_traits variable templates should be
>>> prohibitedJacksonvilleComplete
>>>
>>>
>>> ___
>>> 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
>> 

Re: [libcxx] r269789 - Implement LWG2576: istream_iterator and ostream_iterator should use std::addressof

[Eric Fiselier via cfe-commits]

I added a test for operator->() in r269812. Marshall and I discussed
offline about how not all parts of this change are testable (and hence not
meaningful) but that's what the standard says to do.


On Tue, May 17, 2016 at 1:51 PM, David Blaikie via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Test coverage?
>
> On Tue, May 17, 2016 at 10:44 AM, Marshall Clow via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: marshall
>> Date: Tue May 17 12:44:40 2016
>> New Revision: 269789
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=269789=rev
>> Log:
>> Implement LWG2576: istream_iterator and ostream_iterator should use
>> std::addressof
>>
>> Modified:
>> libcxx/trunk/include/iterator
>> libcxx/trunk/www/cxx1z_status.html
>>
>> Modified: libcxx/trunk/include/iterator
>> URL:
>> http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/iterator?rev=269789=269788=269789=diff
>>
>> ==
>> --- libcxx/trunk/include/iterator (original)
>> +++ libcxx/trunk/include/iterator Tue May 17 12:44:40 2016
>> @@ -772,14 +772,14 @@ private:
>>  _Tp __value_;
>>  public:
>>  _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR istream_iterator() :
>> __in_stream_(0), __value_() {}
>> -_LIBCPP_INLINE_VISIBILITY istream_iterator(istream_type& __s) :
>> __in_stream_(&__s)
>> +_LIBCPP_INLINE_VISIBILITY istream_iterator(istream_type& __s) :
>> __in_stream_(_VSTD::addressof(__s))
>>  {
>>  if (!(*__in_stream_ >> __value_))
>>  __in_stream_ = 0;
>>  }
>>
>>  _LIBCPP_INLINE_VISIBILITY const _Tp& operator*() const {return
>> __value_;}
>> -_LIBCPP_INLINE_VISIBILITY const _Tp* operator->() const {return
>> &(operator*());}
>> +_LIBCPP_INLINE_VISIBILITY const _Tp* operator->() const {return
>> _VSTD::addressof((operator*()));}
>>  _LIBCPP_INLINE_VISIBILITY istream_iterator& operator++()
>>  {
>>  if (!(*__in_stream_ >> __value_))
>> @@ -811,9 +811,9 @@ private:
>>  const char_type* __delim_;
>>  public:
>>  _LIBCPP_INLINE_VISIBILITY ostream_iterator(ostream_type& __s)
>> -: __out_stream_(&__s), __delim_(0) {}
>> +: __out_stream_(_VSTD::addressof(__s)), __delim_(0) {}
>>  _LIBCPP_INLINE_VISIBILITY ostream_iterator(ostream_type& __s, const
>> _CharT* __delimiter)
>> -: __out_stream_(&__s), __delim_(__delimiter) {}
>> +: __out_stream_(_VSTD::addressof(__s)), __delim_(__delimiter) {}
>>  _LIBCPP_INLINE_VISIBILITY ostream_iterator& operator=(const _Tp&
>> __value_)
>>  {
>>  *__out_stream_ << __value_;
>>
>> Modified: libcxx/trunk/www/cxx1z_status.html
>> URL:
>> http://llvm.org/viewvc/llvm-project/libcxx/trunk/www/cxx1z_status.html?rev=269789=269788=269789=diff
>>
>> ==
>> --- libcxx/trunk/www/cxx1z_status.html (original)
>> +++ libcxx/trunk/www/cxx1z_status.html Tue May 17 12:44:40 2016
>> @@ -222,7 +222,7 @@
>> http://cplusplus.github.io/LWG/lwg-defects.html#2572;>2572The
>> remarks for shared_ptr::operator* should apply to
>> cv-qualified void as
>> wellJacksonvilleComplete
>> 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::addressofJacksonvilleComplete
>> http://cplusplus.github.io/LWG/lwg-defects.html#2577;>2577{shared,unique}_lock
>> should use
>> std::addressofJacksonvilleComplete
>> http://cplusplus.github.io/LWG/lwg-defects.html#2579;>2579Inconsistency
>> wrt Allocators in basic_string assignment vs.
>> basic_string::assignJacksonvilleComplete
>> http://cplusplus.github.io/LWG/lwg-defects.html#2581;>2581Specialization
>> of type_traits variable templates should be
>> prohibitedJacksonvilleComplete
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libcxx] r269812 - Add test for r269789

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Tue May 17 14:52:32 2016
New Revision: 269812

URL: http://llvm.org/viewvc/llvm-project?rev=269812=rev
Log:
Add test for r269789

Modified:

libcxx/trunk/test/std/iterators/stream.iterators/istream.iterator/istream.iterator.ops/arrow.pass.cpp

Modified: 
libcxx/trunk/test/std/iterators/stream.iterators/istream.iterator/istream.iterator.ops/arrow.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/iterators/stream.iterators/istream.iterator/istream.iterator.ops/arrow.pass.cpp?rev=269812=269811=269812=diff
==
--- 
libcxx/trunk/test/std/iterators/stream.iterators/istream.iterator/istream.iterator.ops/arrow.pass.cpp
 (original)
+++ 
libcxx/trunk/test/std/iterators/stream.iterators/istream.iterator/istream.iterator.ops/arrow.pass.cpp
 Tue May 17 14:52:32 2016
@@ -23,6 +23,8 @@ struct A
 int i_;
 };
 
+void operator&(A const&) {}
+
 std::istream& operator>>(std::istream& is, A& a)
 {
 return is >> a.d_ >> a.i_;


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

Re: [libcxx] r269789 - Implement LWG2576: istream_iterator and ostream_iterator should use std::addressof

[David Blaikie via cfe-commits]

Test coverage?

On Tue, May 17, 2016 at 10:44 AM, Marshall Clow via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: marshall
> Date: Tue May 17 12:44:40 2016
> New Revision: 269789
>
> URL: http://llvm.org/viewvc/llvm-project?rev=269789=rev
> Log:
> Implement LWG2576: istream_iterator and ostream_iterator should use
> std::addressof
>
> Modified:
> libcxx/trunk/include/iterator
> libcxx/trunk/www/cxx1z_status.html
>
> Modified: libcxx/trunk/include/iterator
> URL:
> http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/iterator?rev=269789=269788=269789=diff
>
> ==
> --- libcxx/trunk/include/iterator (original)
> +++ libcxx/trunk/include/iterator Tue May 17 12:44:40 2016
> @@ -772,14 +772,14 @@ private:
>  _Tp __value_;
>  public:
>  _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR istream_iterator() :
> __in_stream_(0), __value_() {}
> -_LIBCPP_INLINE_VISIBILITY istream_iterator(istream_type& __s) :
> __in_stream_(&__s)
> +_LIBCPP_INLINE_VISIBILITY istream_iterator(istream_type& __s) :
> __in_stream_(_VSTD::addressof(__s))
>  {
>  if (!(*__in_stream_ >> __value_))
>  __in_stream_ = 0;
>  }
>
>  _LIBCPP_INLINE_VISIBILITY const _Tp& operator*() const {return
> __value_;}
> -_LIBCPP_INLINE_VISIBILITY const _Tp* operator->() const {return
> &(operator*());}
> +_LIBCPP_INLINE_VISIBILITY const _Tp* operator->() const {return
> _VSTD::addressof((operator*()));}
>  _LIBCPP_INLINE_VISIBILITY istream_iterator& operator++()
>  {
>  if (!(*__in_stream_ >> __value_))
> @@ -811,9 +811,9 @@ private:
>  const char_type* __delim_;
>  public:
>  _LIBCPP_INLINE_VISIBILITY ostream_iterator(ostream_type& __s)
> -: __out_stream_(&__s), __delim_(0) {}
> +: __out_stream_(_VSTD::addressof(__s)), __delim_(0) {}
>  _LIBCPP_INLINE_VISIBILITY ostream_iterator(ostream_type& __s, const
> _CharT* __delimiter)
> -: __out_stream_(&__s), __delim_(__delimiter) {}
> +: __out_stream_(_VSTD::addressof(__s)), __delim_(__delimiter) {}
>  _LIBCPP_INLINE_VISIBILITY ostream_iterator& operator=(const _Tp&
> __value_)
>  {
>  *__out_stream_ << __value_;
>
> Modified: libcxx/trunk/www/cxx1z_status.html
> URL:
> http://llvm.org/viewvc/llvm-project/libcxx/trunk/www/cxx1z_status.html?rev=269789=269788=269789=diff
>
> ==
> --- libcxx/trunk/www/cxx1z_status.html (original)
> +++ libcxx/trunk/www/cxx1z_status.html Tue May 17 12:44:40 2016
> @@ -222,7 +222,7 @@
> http://cplusplus.github.io/LWG/lwg-defects.html#2572;>2572The
> remarks for shared_ptr::operator* should apply to
> cv-qualified void as
> wellJacksonvilleComplete
> 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::addressofJacksonvilleComplete
> http://cplusplus.github.io/LWG/lwg-defects.html#2577;>2577{shared,unique}_lock
> should use
> std::addressofJacksonvilleComplete
> http://cplusplus.github.io/LWG/lwg-defects.html#2579;>2579Inconsistency
> wrt Allocators in basic_string assignment vs.
> basic_string::assignJacksonvilleComplete
> http://cplusplus.github.io/LWG/lwg-defects.html#2581;>2581Specialization
> of type_traits variable templates should be
> prohibitedJacksonvilleComplete
>
>
> ___
> 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

[libclc] r269807 - math: Use single precision fmax in sp path

[Jan Vesely via cfe-commits]

Author: jvesely
Date: Tue May 17 14:44:01 2016
New Revision: 269807

URL: http://llvm.org/viewvc/llvm-project?rev=269807=rev
Log:
math: Use single precision fmax in sp path

Fixes fdim piglit on Turks

v2: use CL fmax instead of __builtin

Signed-off-by: Jan Vesely 
Reviewed-by: Tom Stellard 

Modified:
libclc/trunk/generic/lib/math/fdim.inc

Modified: libclc/trunk/generic/lib/math/fdim.inc
URL: 
http://llvm.org/viewvc/llvm-project/libclc/trunk/generic/lib/math/fdim.inc?rev=269807=269806=269807=diff
==
--- libclc/trunk/generic/lib/math/fdim.inc (original)
+++ libclc/trunk/generic/lib/math/fdim.inc Tue May 17 14:44:01 2016
@@ -25,7 +25,7 @@
 _CLC_OVERLOAD _CLC_DEF __CLC_GENTYPE fdim(__CLC_GENTYPE x, __CLC_GENTYPE y) {
 if (__builtin_isnan(x) || __builtin_isnan(y))
 return as_float(QNANBITPATT_SP32);
-return __builtin_fmax(x - y, 0);
+return fmax(x - y, 0.0f);
 }
 #define __CLC_FDIM_VEC(width) \
 _CLC_OVERLOAD _CLC_DEF float##width fdim(float##width x, float##width y) { \


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

[clang-tools-extra] r269804 - [clang-tidy] Lift common matchers to utils namespace

[Etienne Bergeron via cfe-commits]

Author: etienneb
Date: Tue May 17 14:36:09 2016
New Revision: 269804

URL: http://llvm.org/viewvc/llvm-project?rev=269804=rev
Log:
[clang-tidy] Lift common matchers to utils namespace

Summary:
This patch is lifting matchers used by more than one checkers
to the common namespace.

Reviewers: aaron.ballman, alexfh

Subscribers: aaron.ballman, cfe-commits

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

Modified:

clang-tools-extra/trunk/clang-tidy/misc/BoolPointerImplicitConversionCheck.cpp
clang-tools-extra/trunk/clang-tidy/modernize/UseNullptrCheck.cpp
clang-tools-extra/trunk/clang-tidy/performance/FasterStringFindCheck.cpp
clang-tools-extra/trunk/clang-tidy/readability/ImplicitBoolCastCheck.cpp
clang-tools-extra/trunk/clang-tidy/readability/RedundantStringInitCheck.cpp
clang-tools-extra/trunk/clang-tidy/utils/Matchers.h

Modified: 
clang-tools-extra/trunk/clang-tidy/misc/BoolPointerImplicitConversionCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/misc/BoolPointerImplicitConversionCheck.cpp?rev=269804=269803=269804=diff
==
--- 
clang-tools-extra/trunk/clang-tidy/misc/BoolPointerImplicitConversionCheck.cpp 
(original)
+++ 
clang-tools-extra/trunk/clang-tidy/misc/BoolPointerImplicitConversionCheck.cpp 
Tue May 17 14:36:09 2016
@@ -15,14 +15,6 @@ namespace clang {
 namespace tidy {
 namespace misc {
 
-namespace {
-
-AST_MATCHER(CastExpr, isPointerToBoolean) {
-  return Node.getCastKind() == CK_PointerToBoolean;
-}
-
-} // namespace
-
 void BoolPointerImplicitConversionCheck::registerMatchers(MatchFinder *Finder) 
{
   // Look for ifs that have an implicit bool* to bool conversion in the
   // condition. Filter negations.
@@ -32,7 +24,7 @@ void BoolPointerImplicitConversionCheck:
hasSourceExpression(expr(
hasType(pointerType(pointee(booleanType(,
ignoringParenImpCasts(declRefExpr().bind("expr",
-   isPointerToBoolean(),
+   hasCastKind(CK_PointerToBoolean),
  unless(isInTemplateInstantiation())).bind("if"),
   this);
 }

Modified: clang-tools-extra/trunk/clang-tidy/modernize/UseNullptrCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/modernize/UseNullptrCheck.cpp?rev=269804=269803=269804=diff
==
--- clang-tools-extra/trunk/clang-tidy/modernize/UseNullptrCheck.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/modernize/UseNullptrCheck.cpp Tue May 17 
14:36:09 2016
@@ -24,20 +24,6 @@ namespace {
 
 const char CastSequence[] = "sequence";
 
-/// \brief Matches cast expressions that have a cast kind of CK_NullToPointer
-/// or CK_NullToMemberPointer.
-///
-/// Given
-/// \code
-///   int *p = 0;
-/// \endcode
-/// implicitCastExpr(isNullToPointer()) matches the implicit cast clang adds
-/// around \c 0.
-AST_MATCHER(CastExpr, isNullToPointer) {
-  return Node.getCastKind() == CK_NullToPointer ||
- Node.getCastKind() == CK_NullToMemberPointer;
-}
-
 AST_MATCHER(Type, sugaredNullptrType) {
   const Type *DesugaredType = Node.getUnqualifiedDesugaredType();
   if (const BuiltinType *BT = dyn_cast(DesugaredType))
@@ -52,7 +38,8 @@ AST_MATCHER(Type, sugaredNullptrType) {
 /// can be replaced instead of just the inner-most implicit cast.
 StatementMatcher makeCastSequenceMatcher() {
   StatementMatcher ImplicitCastToNull = implicitCastExpr(
-  isNullToPointer(),
+  anyOf(hasCastKind(CK_NullToPointer),
+hasCastKind(CK_NullToMemberPointer)),
   unless(hasSourceExpression(hasType(sugaredNullptrType();
 
   return castExpr(anyOf(ImplicitCastToNull,

Modified: 
clang-tools-extra/trunk/clang-tidy/performance/FasterStringFindCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/performance/FasterStringFindCheck.cpp?rev=269804=269803=269804=diff
==
--- clang-tools-extra/trunk/clang-tidy/performance/FasterStringFindCheck.cpp 
(original)
+++ clang-tools-extra/trunk/clang-tidy/performance/FasterStringFindCheck.cpp 
Tue May 17 14:36:09 2016
@@ -38,8 +38,6 @@ llvm::Optional MakeCharacte
   return Result;
 }
 
-AST_MATCHER(StringLiteral, lengthIsOne) { return Node.getLength() == 1; }
-
 AST_MATCHER_FUNCTION(ast_matchers::internal::Matcher,
  hasSubstitutedType) {
   return hasType(qualType(anyOf(substTemplateTypeParmType(),
@@ -65,7 +63,7 @@ void FasterStringFindCheck::registerMatc
 return;
 
   const auto SingleChar =
-  expr(ignoringParenCasts(stringLiteral(lengthIsOne()).bind("literal")));
+  expr(ignoringParenCasts(stringLiteral(hasSize(1)).bind("literal")));
 
   const auto StringFindFunctions =
   anyOf(hasName("find"), hasName("rfind"), 

[PATCH] D20334: [libcxx] Fix a bug in strstreambuf::overflow

[Akira Hatanaka via cfe-commits]

ahatanak created this revision.
ahatanak added reviewers: mclow.lists, EricWF, howard.hinnant.
ahatanak added a subscriber: cfe-commits.

The end pointer should point to one past the end of the newly allocated buffer.

Without this fix, asan reports an error when the following code is compiled and 
executed:

$ cat test.cpp

```
std::string stringOfLength(const size_t length) {
  std::string s("");

  std::string characters("abcdefghijklmnopqrstuvwxyz0123456789+-*/");
  for (size_t i = 0; i < length; ++i) {
s += characters[i % characters.size()];
  }

  return s;
}

int main(int, char const **argv) {
  std::ostrstream oss;

  oss << stringOfLength(atoi(argv[1])) << std::ends;
  std::cout << oss.str();
  oss.freeze(false);

  return 0;
}```

$ clang++  -fsanitize=address test.cpp && ./a.out 4096
==18970==ERROR: AddressSanitizer: heap-buffer-overflow on address 
0x6211dd00 at pc 0x00010277c45d bp 0x7fff5d4ce6e0 sp 0x7fff5d4cdea0
READ of size 4097 at 0x6211dd00 thread T0
#0 0x10277c45c in wrap_strlen (libclang_rt.asan_osx_dynamic.dylib+0x4345c)
#1 0x102733954 in std::__1::char_traits::length(char const*) 
(a.out+0x12954)
#2 0x10273390b in std::__1::basic_ostream& std::__1::operator<<(std::__1::basic_ostream&, char const*) 
(a.out+0x1290b)
#3 0x102733346 in main (a.out+0x12346)
#4 0x7fff901905ac in start (libdyld.dylib+0x35ac)
#5 0x1  ()

0x6211dd00 is located 0 bytes to the right of 4096-byte region 
[0x6211cd00,0x6211dd00)
allocated by thread T0 here:
#0 0x10278d42b in wrap__Znam (libclang_rt.asan_osx_dynamic.dylib+0x5442b)
#1 0x7fff9bdc9fa1 in std::__1::strstreambuf::overflow(int) 
(libc++.1.dylib+0x44fa1)
#2 0x7fff9bd901cc in std::__1::basic_streambuf::xsputn(char const*, long) (libc++.1.dylib+0xb1cc)
#3 0x10273547c in std::__1::ostreambuf_iterator std::__1::__pad_and_output(std::__1::ostreambuf_iterator, char const*, char const*, char const*, 
std::__1::ios_base&, char) (a.out+0x1447c)
#4 0x102734312 in std::__1::basic_ostream& std::__1::__put_character_sequence(std::__1::basic_ostream&, char const*, 
unsigned long) (a.out+0x13312)
#5 0x10273389d in std::__1::basic_ostream& std::__1::operator<<(std::__1::basic_ostream&, std::__1::basic_string const&) 
(a.out+0x1289d)
#6 0x1027332c4 in main (a.out+0x122c4)
#7 0x7fff901905ac in start (libdyld.dylib+0x35ac)
#8 0x1  ()

http://reviews.llvm.org/D20334

Files:
  src/strstream.cpp

Index: src/strstream.cpp
===
--- src/strstream.cpp
+++ src/strstream.cpp
@@ -180,7 +180,7 @@
 delete [] eback();
 }
 setg(buf, buf + ninp, buf + einp);
-setp(buf + einp, buf + einp + eout);
+setp(buf + einp, buf + new_size);
 pbump(static_cast(nout));
 __strmode_ |= __allocated;
 }


Index: src/strstream.cpp
===
--- src/strstream.cpp
+++ src/strstream.cpp
@@ -180,7 +180,7 @@
 delete [] eback();
 }
 setg(buf, buf + ninp, buf + einp);
-setp(buf + einp, buf + einp + eout);
+setp(buf + einp, buf + new_size);
 pbump(static_cast(nout));
 __strmode_ |= __allocated;
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D19990: [CUDA] Implement __ldg using intrinsics.

[Richard Smith via cfe-commits]

rsmith added inline comments.


Comment at: include/clang/Basic/BuiltinsNVPTX.def:569-603
@@ -568,1 +568,37 @@
 
+// __ldg.  This is not implemented as a builtin by nvcc.
+BUILTIN(__nvvm_ldg_c, "ccC*", "")
+BUILTIN(__nvvm_ldg_s, "ssC*", "")
+BUILTIN(__nvvm_ldg_i, "iiC*", "")
+BUILTIN(__nvvm_ldg_l, "LiLiC*", "")
+BUILTIN(__nvvm_ldg_ll, "LLiLLiC*", "")
+
+BUILTIN(__nvvm_ldg_uc, "UcUcC*", "")
+BUILTIN(__nvvm_ldg_us, "UsUsC*", "")
+BUILTIN(__nvvm_ldg_ui, "UiUiC*", "")
+BUILTIN(__nvvm_ldg_ul, "ULiULiC*", "")
+BUILTIN(__nvvm_ldg_ull, "ULLiULLiC*", "")
+
+BUILTIN(__nvvm_ldg_f, "ffC*", "")
+BUILTIN(__nvvm_ldg_d, "ddC*", "")
+
+BUILTIN(__nvvm_ldg_c2, "E2cE2cC*", "")
+BUILTIN(__nvvm_ldg_c4, "E4cE4cC*", "")
+BUILTIN(__nvvm_ldg_s2, "E2sE2sC*", "")
+BUILTIN(__nvvm_ldg_s4, "E4sE4sC*", "")
+BUILTIN(__nvvm_ldg_i2, "E2iE2iC*", "")
+BUILTIN(__nvvm_ldg_i4, "E4iE4iC*", "")
+BUILTIN(__nvvm_ldg_ll2, "E2LLiE2LLiC*", "")
+
+BUILTIN(__nvvm_ldg_uc2, "E2UcE2UcC*", "")
+BUILTIN(__nvvm_ldg_uc4, "E4UcE4UcC*", "")
+BUILTIN(__nvvm_ldg_us2, "E2UsE2UsC*", "")
+BUILTIN(__nvvm_ldg_us4, "E4UsE4UsC*", "")
+BUILTIN(__nvvm_ldg_ui2, "E2UiE2UiC*", "")
+BUILTIN(__nvvm_ldg_ui4, "E4UiE4UiC*", "")
+BUILTIN(__nvvm_ldg_ull2, "E2ULLiE2ULLiC*", "")
+
+BUILTIN(__nvvm_ldg_f2, "E2fE2fC*", "")
+BUILTIN(__nvvm_ldg_f4, "E4fE4fC*", "")
+BUILTIN(__nvvm_ldg_d2, "E2dE2dC*", "")
+

It sounds like the combinatorial explosion will be unmanageable if we don't 
switch to using a generic builtin for the full suite of 'ld' operations, so it 
seems worthwhile to do that now. This would also be consistent with how we 
handle the somewhat-similar builtin `__builtin_nontemporal_load`.


http://reviews.llvm.org/D19990



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

Re: [PATCH] D18821: Add bugprone-bool-to-integer-conversion

[Alexander Kornienko via cfe-commits]

alexfh requested changes to this revision.
This revision now requires changes to proceed.


Comment at: docs/clang-tidy/checks/bugprone-bool-to-integer-conversion.rst:43
@@ +42,3 @@
+
+This is because z and ``true`` will be implicitly converted to int by 
promotion.
+To get rid of this case use

This is a false positive and should be fixed regardless of whether we disable 
fixits or not. Just documenting it doesn't help much.


http://reviews.llvm.org/D18821



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

r269801 - Teach clang to look for libcxx in /usr/local/include/c++ on Linux

[Yaron Keren via cfe-commits]

Author: yrnkrn
Date: Tue May 17 14:01:16 2016
New Revision: 269801

URL: http://llvm.org/viewvc/llvm-project?rev=269801=rev
Log:
Teach clang to look for libcxx in /usr/local/include/c++ on Linux

As The default CMAKE install prefix is /usr/local ( 
https://cmake.org/cmake/help/v3.0/variable/CMAKE_INSTALL_PREFIX.html ),
sudo ninja install ends up installing clang, LLVM and libcxx under /usr/local.
In development scenario, when clang is run from the build location it will not
find libcxx at neither (build location)/../include/c++ nor /usr/include/c++.
This patch lets development clang find system installed libcxx without adding
-isystem /usr/local/include/c++. Also addresses the FIXME by explaining the 
use-case for these include paths.


Modified:
cfe/trunk/lib/Driver/ToolChains.cpp

Modified: cfe/trunk/lib/Driver/ToolChains.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains.cpp?rev=269801=269800=269801=diff
==
--- cfe/trunk/lib/Driver/ToolChains.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains.cpp Tue May 17 14:01:16 2016
@@ -4130,11 +4130,11 @@ void Linux::AddClangCXXStdlibIncludeArgs
   if (GetCXXStdlibType(DriverArgs) == ToolChain::CST_Libcxx) {
 const std::string LibCXXIncludePathCandidates[] = {
 DetectLibcxxIncludePath(getDriver().Dir + "/../include/c++"),
-
-// We also check the system as for a long time this is the only place
-// Clang looked.
-// FIXME: We should really remove this. It doesn't make any sense.
-DetectLibcxxIncludePath(getDriver().SysRoot + "/usr/include/c++")};
+// If this is a development, non-installed, clang, libcxx will
+// not be found at ../include/c++ but it likely to be found at
+// one of the following two locations:
+DetectLibcxxIncludePath(getDriver().SysRoot + 
"/usr/local/include/c++"),
+DetectLibcxxIncludePath(getDriver().SysRoot + "/usr/include/c++") };
 for (const auto  : LibCXXIncludePathCandidates) {
   if (IncludePath.empty() || !getVFS().exists(IncludePath))
 continue;


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

Re: [PATCH] D19841: [clang-tidy] Lift common matchers to utils namespace

[Aaron Ballman via cfe-commits]

aaron.ballman added inline comments.


Comment at: clang-tidy/utils/Matchers.h:20
@@ -19,1 +19,3 @@
 
+AST_MATCHER_P(Expr, ignoringImplicit,
+  ast_matchers::internal::Matcher, InnerMatcher) {

alexfh wrote:
> Consider moving this to ASTMatchers.h in a follow-up.
Honestly, this one is a lot less interesting as a public AST matcher. I would 
avoid that unless there's a really solid case for it.


http://reviews.llvm.org/D19841



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

Re: [PATCH] D19841: [clang-tidy] Lift common matchers to utils namespace

[Alexander Kornienko via cfe-commits]

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

LG. Thank you!



Comment at: clang-tidy/utils/Matchers.h:20
@@ -19,1 +19,3 @@
 
+AST_MATCHER_P(Expr, ignoringImplicit,
+  ast_matchers::internal::Matcher, InnerMatcher) {

Consider moving this to ASTMatchers.h in a follow-up.


http://reviews.llvm.org/D19841



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

Re: [PATCH] D20326: [clang-tidy] Fix a template function false positive in misc-unused-using-decls check.

[Alexander Kornienko via cfe-commits]

alexfh requested changes to this revision.
This revision now requires changes to proceed.


Comment at: clang-tidy/misc/UnusedUsingDeclsCheck.cpp:24
@@ +23,3 @@
+// FIXME: Add a node matcher for UnresolvedLookupExpr in ASTMatcher.
+AST_MATCHER(CallExpr, hasUnresolvedLookupExpr) {
+  return isa(Node.getCallee());

Sorry for being unclear. Please change this to the node matcher in this patch. 
You can move the matcher to the ASTMatchers.h as a follow-up. 
`hasUnresolvedLookupExpr` is not in line with the matchers design: the 
`CallExpr` node has no property `UnresolvedLookupExpr`. You'll also be able to 
bind the `UnresolvedLookupExpr` to an identifier and make the code in `check()` 
slightly shorter.


http://reviews.llvm.org/D20326



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

Re: [PATCH] D17578: [OpenCL]Allowing explicit conversion of "0" to event_t type

[Aaron En Ye Shi via cfe-commits]

ashi1 added a comment.

Xiuli, are you OK with this patch?


http://reviews.llvm.org/D17578



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

Re: [PATCH] D20296: clang-rename: avoid StringRef members in USRLocFindingASTVisitor

[Miklos Vajna via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL269796: clang-rename: avoid StringRef members in 
USRLocFindingASTVisitor (authored by vmiklos).

Changed prior to commit:
  http://reviews.llvm.org/D20296?vs=57385=57503#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D20296

Files:
  clang-tools-extra/trunk/clang-rename/USRLocFinder.cpp

Index: clang-tools-extra/trunk/clang-rename/USRLocFinder.cpp
===
--- clang-tools-extra/trunk/clang-rename/USRLocFinder.cpp
+++ clang-tools-extra/trunk/clang-rename/USRLocFinder.cpp
@@ -123,9 +123,9 @@
   }
 
   // All the locations of the USR were found.
-  StringRef USR;
+  const std::string USR;
   // Old name that is renamed.
-  StringRef PrevName;
+  const std::string PrevName;
   std::vector LocationsFound;
 };
 } // namespace


Index: clang-tools-extra/trunk/clang-rename/USRLocFinder.cpp
===
--- clang-tools-extra/trunk/clang-rename/USRLocFinder.cpp
+++ clang-tools-extra/trunk/clang-rename/USRLocFinder.cpp
@@ -123,9 +123,9 @@
   }
 
   // All the locations of the USR were found.
-  StringRef USR;
+  const std::string USR;
   // Old name that is renamed.
-  StringRef PrevName;
+  const std::string PrevName;
   std::vector LocationsFound;
 };
 } // namespace
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] r269796 - clang-rename: avoid StringRef members in USRLocFindingASTVisitor

[Miklos Vajna via cfe-commits]

Author: vmiklos
Date: Tue May 17 13:17:16 2016
New Revision: 269796

URL: http://llvm.org/viewvc/llvm-project?rev=269796=rev
Log:
clang-rename: avoid StringRef members in USRLocFindingASTVisitor

Even if this is defined in the .cpp file and only used as part of the
function (so here it's safe), usually storing StringRefs in the class is
dangerous, so don't do so.

Reviewers: cfe-commits, klimek

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

Modified:
clang-tools-extra/trunk/clang-rename/USRLocFinder.cpp

Modified: clang-tools-extra/trunk/clang-rename/USRLocFinder.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-rename/USRLocFinder.cpp?rev=269796=269795=269796=diff
==
--- clang-tools-extra/trunk/clang-rename/USRLocFinder.cpp (original)
+++ clang-tools-extra/trunk/clang-rename/USRLocFinder.cpp Tue May 17 13:17:16 
2016
@@ -123,9 +123,9 @@ private:
   }
 
   // All the locations of the USR were found.
-  StringRef USR;
+  const std::string USR;
   // Old name that is renamed.
-  StringRef PrevName;
+  const std::string PrevName;
   std::vector LocationsFound;
 };
 } // namespace


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

Re: [PATCH] D20171: Support for MSVS default calling convention options (/Gd, /Gz, /Gv, /Gr)

[Reid Kleckner via cfe-commits]

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

Thanks, lgtm!


http://reviews.llvm.org/D20171



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

r269794 - NFC: simplify logic.

[Manman Ren via cfe-commits]

Author: mren
Date: Tue May 17 13:04:38 2016
New Revision: 269794

URL: http://llvm.org/viewvc/llvm-project?rev=269794=rev
Log:
NFC: simplify logic.

Modified:
cfe/trunk/lib/Lex/HeaderSearch.cpp

Modified: cfe/trunk/lib/Lex/HeaderSearch.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/HeaderSearch.cpp?rev=269794=269793=269794=diff
==
--- cfe/trunk/lib/Lex/HeaderSearch.cpp (original)
+++ cfe/trunk/lib/Lex/HeaderSearch.cpp Tue May 17 13:04:38 2016
@@ -617,8 +617,8 @@ const FileEntry *HeaderSearch::LookupFil
   // from a module build. We should treat this as a system header if we're
   // building a [system] module.
   bool IncluderIsSystemHeader =
-  (Includer && getFileInfo(Includer).DirInfo != SrcMgr::C_User) ||
-  (!Includer && BuildSystemModule);
+  Includer ? getFileInfo(Includer).DirInfo != SrcMgr::C_User :
+  BuildSystemModule;
   if (const FileEntry *FE = getFileAndSuggestModule(
   TmpDir, IncluderAndDir.second, IncluderIsSystemHeader,
   RequestingModule, SuggestedModule)) {


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

Re: [PATCH] D19909: [Attr] Add support for the `ms_hook_prologue` attribute.

[Aaron Ballman via cfe-commits]

aaron.ballman added a comment.

The patch is missing semantic test cases. I would like to see tests of the 
attribute being accepted, as well as rejected because the subject was 
incorrect, args were provided, etc.

Also, I believe there are attributes which this attribute should not be 
combined with, such as `__declspec(naked)`. I think we should diagnose in that 
case (MSVC does not because the entire object file is hotpatched, not 
individual functions). e.g., `__declspec(naked) void f(void) 
__attribute__((ms_hook_prologue));`



Comment at: include/clang/Basic/Attr.td:2032
@@ -2031,1 +2031,3 @@
 
+def MSHookPrologue : InheritableAttr {
+  let Spellings = [GCC<"ms_hook_prologue">];

I am wondering whether we want this to be a target-specific attribute or not. 
Right now, this attribute will be silently accepted for CPUs that MSVC does not 
support, for instance. If we made the attribute target-specific, then users 
would get appropriate diagnostics for those architectures.


http://reviews.llvm.org/D19909



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

[libcxx] r269789 - Implement LWG2576: istream_iterator and ostream_iterator should use std::addressof

[Marshall Clow via cfe-commits]

Author: marshall
Date: Tue May 17 12:44:40 2016
New Revision: 269789

URL: http://llvm.org/viewvc/llvm-project?rev=269789=rev
Log:
Implement LWG2576: istream_iterator and ostream_iterator should use 
std::addressof

Modified:
libcxx/trunk/include/iterator
libcxx/trunk/www/cxx1z_status.html

Modified: libcxx/trunk/include/iterator
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/iterator?rev=269789=269788=269789=diff
==
--- libcxx/trunk/include/iterator (original)
+++ libcxx/trunk/include/iterator Tue May 17 12:44:40 2016
@@ -772,14 +772,14 @@ private:
 _Tp __value_;
 public:
 _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR istream_iterator() : 
__in_stream_(0), __value_() {}
-_LIBCPP_INLINE_VISIBILITY istream_iterator(istream_type& __s) : 
__in_stream_(&__s)
+_LIBCPP_INLINE_VISIBILITY istream_iterator(istream_type& __s) : 
__in_stream_(_VSTD::addressof(__s))
 {
 if (!(*__in_stream_ >> __value_))
 __in_stream_ = 0;
 }
 
 _LIBCPP_INLINE_VISIBILITY const _Tp& operator*() const {return __value_;}
-_LIBCPP_INLINE_VISIBILITY const _Tp* operator->() const {return 
&(operator*());}
+_LIBCPP_INLINE_VISIBILITY const _Tp* operator->() const {return 
_VSTD::addressof((operator*()));}
 _LIBCPP_INLINE_VISIBILITY istream_iterator& operator++()
 {
 if (!(*__in_stream_ >> __value_))
@@ -811,9 +811,9 @@ private:
 const char_type* __delim_;
 public:
 _LIBCPP_INLINE_VISIBILITY ostream_iterator(ostream_type& __s)
-: __out_stream_(&__s), __delim_(0) {}
+: __out_stream_(_VSTD::addressof(__s)), __delim_(0) {}
 _LIBCPP_INLINE_VISIBILITY ostream_iterator(ostream_type& __s, const 
_CharT* __delimiter)
-: __out_stream_(&__s), __delim_(__delimiter) {}
+: __out_stream_(_VSTD::addressof(__s)), __delim_(__delimiter) {}
 _LIBCPP_INLINE_VISIBILITY ostream_iterator& operator=(const _Tp& __value_)
 {
 *__out_stream_ << __value_;

Modified: libcxx/trunk/www/cxx1z_status.html
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/www/cxx1z_status.html?rev=269789=269788=269789=diff
==
--- libcxx/trunk/www/cxx1z_status.html (original)
+++ libcxx/trunk/www/cxx1z_status.html Tue May 17 12:44:40 2016
@@ -222,7 +222,7 @@
http://cplusplus.github.io/LWG/lwg-defects.html#2572;>2572The
 remarks for shared_ptr::operator* should apply to cv-qualified 
void as wellJacksonvilleComplete
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::addressofJacksonvilleComplete
http://cplusplus.github.io/LWG/lwg-defects.html#2577;>2577{shared,unique}_lock
 should use 
std::addressofJacksonvilleComplete
http://cplusplus.github.io/LWG/lwg-defects.html#2579;>2579Inconsistency
 wrt Allocators in basic_string assignment vs. 
basic_string::assignJacksonvilleComplete
http://cplusplus.github.io/LWG/lwg-defects.html#2581;>2581Specialization
 of type_traits variable templates should be 
prohibitedJacksonvilleComplete


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

Re: [PATCH] D19990: [CUDA] Implement __ldg using intrinsics.

[Justin Lebar via cfe-commits]

jlebar added a comment.

Friendly ping.  This is a big help with some Tensorflow benchmarks.


http://reviews.llvm.org/D19990



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

Re: [PATCH] D18575: [clang-tidy] New checker to replace deprecated throw() specifications

[don hinton via cfe-commits]

hintonda added inline comments.


Comment at: clang-tidy/modernize/UseNoexceptCheck.cpp:39
@@ +38,3 @@
+
+  // FIXME: Add paren matching so we can parse more complex throw statements,
+  // e.g., (examples provided by Aaron Ballman):

aaron.ballman wrote:
> @alexfh, what are your feelings on this FIXME? I am a bit concerned because 
> these examples will cause the replacement range to be incorrect, which will 
> turn working code into ill-formed code. The alternative, as I see it, is to 
> instead properly track the exception specification source range information 
> as part of the FunctionDecl (akin to 
> `FunctionDecl::getReturnTypeSourceRange()`).
Btw, I'm working on a fix I believe will handle all cases -- plan to checkin 
later today.  However, it won't be that efficient unless I can find a way to 
match params that contain dynamic exception specifications.  If they are only 
legal for function pointers -- which I think is the case -- that would make it 
easy and efficient, i.e., I wouldn't have to match all FunctionDecl's with one 
or more parameter and test them.

Is it possible to match a parameter that is a function pointer?


Comment at: docs/clang-tidy/checks/modernize-use-noexcept.rst:40
@@ +39,3 @@
+``noexcept(false)`` not ``noexcept``, this check will detect, but not
+provide a FixItHint in that case.
+

aaron.ballman wrote:
> This seems to run contrary to one of the examples below where a fixit is 
> provided for ``throw(A, B)``. If I understood properly, this statement is 
> only true when using a ReplacementString. Perhaps it should instead say, 
> "this check will detect, but not
> provide a FixItHint for this case when a :option:`ReplacementString` is 
> provided."
This is only applicable when the user provided a replacement string other than 
noexcept.  I'll try to make it clearer, however, there is a FIXME in the code 
concerning this.  Specifically, should we allow replacement options for both 
noexcept and noexcept(false).


http://reviews.llvm.org/D18575



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

r269787 - Fix line numbers in calling convention test

[Reid Kleckner via cfe-commits]

Author: rnk
Date: Tue May 17 12:33:31 2016
New Revision: 269787

URL: http://llvm.org/viewvc/llvm-project?rev=269787=rev
Log:
Fix line numbers in calling convention test

Modified:
cfe/trunk/test/Sema/callingconv-cast.c

Modified: cfe/trunk/test/Sema/callingconv-cast.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/callingconv-cast.c?rev=269787=269786=269787=diff
==
--- cfe/trunk/test/Sema/callingconv-cast.c (original)
+++ cfe/trunk/test/Sema/callingconv-cast.c Tue May 17 12:33:31 2016
@@ -52,12 +52,12 @@ int main() {
   take_opaque_fn((void (*)(int))mismatched_stdcall);
 }
 
-// MSFIXIT: fix-it:"{{.*}}callingconv-cast.c":{19:6-19:6}:"WINAPI "
-// MSFIXIT: fix-it:"{{.*}}callingconv-cast.c":{19:6-19:6}:"WINAPI "
-// MSFIXIT: fix-it:"{{.*}}callingconv-cast.c":{19:6-19:6}:"WINAPI "
-// MSFIXIT: fix-it:"{{.*}}callingconv-cast.c":{10:6-10:6}:"__stdcall "
+// MSFIXIT: fix-it:"{{.*}}callingconv-cast.c":{16:6-16:6}:"WINAPI "
+// MSFIXIT: fix-it:"{{.*}}callingconv-cast.c":{16:6-16:6}:"WINAPI "
+// MSFIXIT: fix-it:"{{.*}}callingconv-cast.c":{16:6-16:6}:"WINAPI "
+// MSFIXIT: fix-it:"{{.*}}callingconv-cast.c":{7:6-7:6}:"__stdcall "
 
-// GNUFIXIT: fix-it:"{{.*}}callingconv-cast.c":{19:6-19:6}:"WINAPI "
-// GNUFIXIT: fix-it:"{{.*}}callingconv-cast.c":{19:6-19:6}:"WINAPI "
-// GNUFIXIT: fix-it:"{{.*}}callingconv-cast.c":{19:6-19:6}:"WINAPI "
-// GNUFIXIT: 
fix-it:"{{.*}}callingconv-cast.c":{10:6-10:6}:"__attribute__((stdcall)) "
+// GNUFIXIT: fix-it:"{{.*}}callingconv-cast.c":{16:6-16:6}:"WINAPI "
+// GNUFIXIT: fix-it:"{{.*}}callingconv-cast.c":{16:6-16:6}:"WINAPI "
+// GNUFIXIT: fix-it:"{{.*}}callingconv-cast.c":{16:6-16:6}:"WINAPI "
+// GNUFIXIT: 
fix-it:"{{.*}}callingconv-cast.c":{7:6-7:6}:"__attribute__((stdcall)) "


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

Re: Patch submission for bug 27400

[Vedant Kumar via cfe-commits]

> On May 17, 2016, at 2:59 AM, Mads Ravn  wrote:
> 
> Hi guys,
> 
> I just wanted to check up on this patch. I heard I could just reply to this 
> mail and see if I could 'ping' anyone in this regard. Hope it's OK.

Sorry for the delay! This looks good. Committed as r269786.

thanks,
vedant

> 
> Best regards,
> Mads Ravn
> 
> On Thu, May 12, 2016 at 6:11 PM Mads Ravn  wrote:
> Hi,
> 
> I have fixed the things you mentioned now. I have attached the new patch to 
> this email.
> 
> Best regards,
> Mads Ravn
> 
> On Wed, May 11, 2016 at 11:54 PM Vedant Kumar  wrote:
> Hi,
> 
> Thanks for the patch!
> 
> This patch is missing a small, lit-style test case. You can find examples of 
> test cases here:
> 
>   extra/test/clang-tidy/
> 
> Apart from that, my only other nit-pick is that llvm uses 2-space indents, 
> and spaces between "if" and "(".
> 
> If you reply to this list with an updated patch, someone would be happy to 
> commit it for you.
> 
> best
> vedant
> 
> > On May 11, 2016, at 10:01 AM, Mads Ravn via cfe-commits 
> >  wrote:
> >
> > Hi,
> >
> > I would like to submit a patch for 
> > https://llvm.org/bugs/show_bug.cgi?id=27400 .
> >
> > Beside attaching the patch, is there anything I should be aware of? I have 
> > not submitted a patch before.
> >
> > You can find the patch attached to this mail.
> >
> > Kind regards,
> > Mads Ravn
> > ___
> > 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] D20325: Add ARM cdp intrinsics

[Renato Golin via cfe-commits]

rengolin added inline comments.


Comment at: include/clang/Basic/BuiltinsARM.def:55
@@ -54,3 +54,3 @@
 BUILTIN(__builtin_arm_mrc2, "UiUIiUIiUIiUIiUIi", "")
-BUILTIN(__builtin_arm_cdp, "vUiUiUiUiUiUi", "")
-BUILTIN(__builtin_arm_cdp2, "vUiUiUiUiUiUi", "")
+BUILTIN(__builtin_arm_cdp, "vUIiUIiUIiUIiUIiUIi", "")
+BUILTIN(__builtin_arm_cdp2, "vUIiUIiUIiUIiUIiUIi", "")

t.p.northover wrote:
> rengolin wrote:
> > I wonder why the old signature was wrong... probably because the docs 
> > weren't public and no one could really check whether they were right or 
> > not. I don't want to repeat the same mistake.
> The difference between "UIi" and "Ui" is that the fix requires a constant. A 
> pretty obvious restriction even without a specification.
Ah, this makes sense. Looks like a good change in its own.


Repository:
  rL LLVM

http://reviews.llvm.org/D20325



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

[clang-tools-extra] r269786 - [clang-tidy] Skip misc-macro-parentheses for namespaces (Fix PR27400)

[Vedant Kumar via cfe-commits]

Author: vedantk
Date: Tue May 17 12:26:02 2016
New Revision: 269786

URL: http://llvm.org/viewvc/llvm-project?rev=269786=rev
Log:
[clang-tidy] Skip misc-macro-parentheses for namespaces (Fix PR27400)

If a use of a macro argument is preceded by the `namespace` keyword, do
not warn that the use should be wrapped in parentheses.

Patch by Mads Ravn!

Modified:
clang-tools-extra/trunk/clang-tidy/misc/MacroParenthesesCheck.cpp
clang-tools-extra/trunk/test/clang-tidy/misc-macro-parentheses.cpp

Modified: clang-tools-extra/trunk/clang-tidy/misc/MacroParenthesesCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/misc/MacroParenthesesCheck.cpp?rev=269786=269785=269786=diff
==
--- clang-tools-extra/trunk/clang-tidy/misc/MacroParenthesesCheck.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/misc/MacroParenthesesCheck.cpp Tue May 
17 12:26:02 2016
@@ -184,6 +184,10 @@ void MacroParenthesesPPCallbacks::argume
 Next.isOneOf(tok::comma, tok::greater))
   continue;
 
+// Namespaces.
+if (Prev.is(tok::kw_namespace))
+  continue;
+
 Check->diag(Tok.getLocation(), "macro argument should be enclosed in "
"parentheses")
 << FixItHint::CreateInsertion(Tok.getLocation(), "(")

Modified: clang-tools-extra/trunk/test/clang-tidy/misc-macro-parentheses.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/misc-macro-parentheses.cpp?rev=269786=269785=269786=diff
==
--- clang-tools-extra/trunk/test/clang-tidy/misc-macro-parentheses.cpp 
(original)
+++ clang-tools-extra/trunk/test/clang-tidy/misc-macro-parentheses.cpp Tue May 
17 12:26:02 2016
@@ -36,6 +36,7 @@
 #define GOOD25(t) std::set s
 #define GOOD26(x) (a->*x)
 #define GOOD27(x) (a.*x)
+#define GOOD28(x) namespace x {int b;}
 
 // These are allowed for now..
 #define MAYBE1*12.34


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

Re: [PATCH] D20325: Add ARM cdp intrinsics

[Renato Golin via cfe-commits]

rengolin added a comment.

In http://reviews.llvm.org/D20325#432086, @t.p.northover wrote:

> I don't think we need to wait until the document is public, necessarily. The 
> entire AArch64 backend went in before the encodings were public outside ARM 
> (except maybe in binutils source?) and releasing specifications with no 
> implementation yet is a bit annoying too.


I don't think a small future ACLE builtin is on the same league as a whole new 
back-end. :)

Nor I think that having this when the docs are public, rather than now, will 
affect users in any way.

It's been our stance for a long time to require docs to approve changes, 
however small. I don't want to relax that which I think is a good constraint, 
not for such a seemly irrelevant issue.

I also doubt this will be the only addition in the new ACLE, so why not release 
the document, and then submit all changes then?

Or, maybe I am mistaken, and this is really that important... is it?

cheers,
--renato


Repository:
  rL LLVM

http://reviews.llvm.org/D20325



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

Re: [PATCH] D20325: Add ARM cdp intrinsics

[Tim Northover via cfe-commits]

t.p.northover added a subscriber: t.p.northover.
t.p.northover added a comment.

I don't think we need to wait until the document is public, necessarily. The 
entire AArch64 backend went in before the encodings were public outside ARM 
(except maybe in binutils source?) and releasing specifications with no 
implementation yet is a bit annoying too.

We may discover bugs (though this seems fairly straightforward), but I think 
it's highly unlikely we'll have vocal and powerful enough users of such a niche 
feature to prevent us fixing them.

I agree about the asm tests though, they belong in LLVM.



Comment at: include/clang/Basic/BuiltinsARM.def:55
@@ -54,3 +54,3 @@
 BUILTIN(__builtin_arm_mrc2, "UiUIiUIiUIiUIiUIi", "")
-BUILTIN(__builtin_arm_cdp, "vUiUiUiUiUiUi", "")
-BUILTIN(__builtin_arm_cdp2, "vUiUiUiUiUiUi", "")
+BUILTIN(__builtin_arm_cdp, "vUIiUIiUIiUIiUIiUIi", "")
+BUILTIN(__builtin_arm_cdp2, "vUIiUIiUIiUIiUIiUIi", "")

rengolin wrote:
> I wonder why the old signature was wrong... probably because the docs weren't 
> public and no one could really check whether they were right or not. I don't 
> want to repeat the same mistake.
The difference between "UIi" and "Ui" is that the fix requires a constant. A 
pretty obvious restriction even without a specification.


Repository:
  rL LLVM

http://reviews.llvm.org/D20325



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

Re: r269717 - Switch from SmallVector to TinyPtrVector for the list of attributes on a declaration. This removes a memory allocation for the common case where the declaration has only one attribute.

[David Blaikie via cfe-commits]

On Mon, May 16, 2016 at 3:53 PM, Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rsmith
> Date: Mon May 16 17:53:19 2016
> New Revision: 269717
>
> URL: http://llvm.org/viewvc/llvm-project?rev=269717=rev
> Log:
> Switch from SmallVector to TinyPtrVector for the list of attributes on a
> declaration. This removes a memory allocation for the common case where the
> declaration has only one attribute.
>

Just out of curiosity - if the SmallVector had a small size of 2, why was
an allocation done for a single attribute?


>
> Modified:
> cfe/trunk/include/clang/AST/AttrIterator.h
>
> Modified: cfe/trunk/include/clang/AST/AttrIterator.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/AttrIterator.h?rev=269717=269716=269717=diff
>
> ==
> --- cfe/trunk/include/clang/AST/AttrIterator.h (original)
> +++ cfe/trunk/include/clang/AST/AttrIterator.h Mon May 16 17:53:19 2016
> @@ -15,6 +15,7 @@
>  #define LLVM_CLANG_AST_ATTRITERATOR_H
>
>  #include "clang/Basic/LLVM.h"
> +#include "llvm/ADT/TinyPtrVector.h"
>  #include 
>
>  namespace clang {
> @@ -39,8 +40,8 @@ void operator delete[](void *Ptr, const
>  namespace clang {
>
>  /// AttrVec - A vector of Attr, which is how they are stored on the AST.
> -typedef SmallVector AttrVec;
> -typedef SmallVector ConstAttrVec;
> +typedef llvm::TinyPtrVector AttrVec;
> +typedef llvm::TinyPtrVector ConstAttrVec;
>
>  /// specific_attr_iterator - Iterates over a subrange of an AttrVec, only
>  /// providing attributes that are of a specific type.
>
>
> ___
> 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] D20198: clang-format: [JS] sort ES6 imports.

[Martin Probst via cfe-commits]

mprobst updated this revision to Diff 57497.
mprobst marked 8 inline comments as done.
mprobst added a comment.

- address review comments


http://reviews.llvm.org/D20198

Files:
  include/clang/Format/Format.h
  lib/Format/CMakeLists.txt
  lib/Format/Format.cpp
  lib/Format/FormatToken.h
  lib/Format/FormatTokenLexer.cpp
  lib/Format/FormatTokenLexer.h
  lib/Format/SortJavaScriptImports.cpp
  lib/Format/SortJavaScriptImports.h
  lib/Format/TokenAnalyzer.cpp
  lib/Format/TokenAnalyzer.h
  unittests/Format/CMakeLists.txt
  unittests/Format/SortImportsTestJS.cpp

Index: unittests/Format/SortImportsTestJS.cpp
===
--- /dev/null
+++ unittests/Format/SortImportsTestJS.cpp
@@ -0,0 +1,137 @@
+//===- unittest/Format/SortImportsTestJS.cpp - JS import sort unit tests --===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "FormatTestUtils.h"
+#include "clang/Format/Format.h"
+#include "llvm/Support/Debug.h"
+#include "gtest/gtest.h"
+
+#define DEBUG_TYPE "format-test"
+
+namespace clang {
+namespace format {
+namespace {
+
+class SortImportsTestJS : public ::testing::Test {
+protected:
+  std::vector GetCodeRange(StringRef Code) {
+return std::vector(1, tooling::Range(0, Code.size()));
+  }
+
+  std::string sort(StringRef Code, StringRef FileName = "input.js") {
+auto Ranges = GetCodeRange(Code);
+std::string Sorted =
+applyAllReplacements(Code, sortIncludes(Style, Code, Ranges, FileName));
+return applyAllReplacements(Sorted,
+reformat(Style, Sorted, Ranges, FileName));
+  }
+
+  void verifySort(llvm::StringRef Expected, llvm::StringRef Code) {
+std::string Result = sort(Code);
+EXPECT_EQ(Expected.str(), Result) << "Formatted:\n" << Result;
+  }
+
+  FormatStyle Style = getGoogleStyle(FormatStyle::LK_JavaScript);
+};
+
+TEST_F(SortImportsTestJS, BasicSorting) {
+  verifySort("import {sym} from 'a';\n"
+ "import {sym} from 'b';\n"
+ "import {sym} from 'c';\n"
+ "\n"
+ "let x = 1;",
+ "import {sym} from 'a';\n"
+ "import {sym} from 'c';\n"
+ "import {sym} from 'b';\n"
+ "let x = 1;");
+}
+
+TEST_F(SortImportsTestJS, Comments) {
+  verifySort("/** @fileoverview This is a great file. */\n"
+ "// A very important import follows.\n"
+ "import {sym} from 'a'; /* more comments */\n"
+ "import {sym} from 'b'; // from //foo:bar\n",
+ "/** @fileoverview This is a great file. */\n"
+ "import {sym} from 'b'; // from //foo:bar\n"
+ "// A very important import follows.\n"
+ "import {sym} from 'a'; /* more comments */\n");
+}
+
+TEST_F(SortImportsTestJS, SortStar) {
+  verifySort("import * as foo from 'a';\n"
+ "import {sym} from 'a';\n"
+ "import * as bar from 'b';\n",
+ "import {sym} from 'a';\n"
+ "import * as foo from 'a';\n"
+ "import * as bar from 'b';\n");
+}
+
+TEST_F(SortImportsTestJS, AliasesSymbols) {
+  verifySort("import {sym1 as alias1} from 'b';\n"
+ "import {sym2 as alias2, sym3 as alias3} from 'c';\n",
+ "import {sym2 as alias2, sym3 as alias3} from 'c';\n"
+ "import {sym1 as alias1} from 'b';\n");
+}
+
+TEST_F(SortImportsTestJS, GroupImports) {
+  verifySort("import {a} from 'absolute';\n"
+ "\n"
+ "import {b} from '../parent';\n"
+ "import {b} from '../parent/nested';\n"
+ "\n"
+ "import {b} from './relative/path';\n"
+ "import {b} from './relative/path/nested';\n"
+ "\n"
+ "let x = 1;\n",
+ "import {b} from './relative/path/nested';\n"
+ "import {b} from './relative/path';\n"
+ "import {b} from '../parent/nested';\n"
+ "import {b} from '../parent';\n"
+ "import {a} from 'absolute';\n"
+ "let x = 1;\n");
+}
+
+TEST_F(SortImportsTestJS, Exports) {
+  verifySort("import {S} from 'bpath';\n"
+ "\n"
+ "import {T} from './cpath';\n"
+ "\n"
+ "export {A, B} from 'apath';\n"
+ "export {P} from '../parent';\n"
+ "export {R} from './relative';\n"
+ "export {S};\n"
+ "\n"
+ "let x = 1;\n"
+ "export y = 1;\n",
+ "export {R} from './relative';\n"
+ "import {T} from './cpath';\n"
+ "export {S};\n"
+ "export {A, B} from 'apath';\n"
+ "import {S} from 'bpath';\n"
+ "export {P} from '../parent';\n"
+ "let x = 1;\n"
+ "export y 

r269781 - Fix calling convention test

[Reid Kleckner via cfe-commits]

Author: rnk
Date: Tue May 17 11:54:40 2016
New Revision: 269781

URL: http://llvm.org/viewvc/llvm-project?rev=269781=rev
Log:
Fix calling convention test

Modified:
cfe/trunk/test/Sema/callingconv-cast.c

Modified: cfe/trunk/test/Sema/callingconv-cast.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/callingconv-cast.c?rev=269781=269780=269781=diff
==
--- cfe/trunk/test/Sema/callingconv-cast.c (original)
+++ cfe/trunk/test/Sema/callingconv-cast.c Tue May 17 11:54:40 2016
@@ -3,9 +3,6 @@
 // RUN: %clang_cc1 -fms-extensions -triple i686-pc-windows-msvc 
-Wcast-calling-convention -DMSVC -fdiagnostics-parseable-fixits %s 2>&1 | 
FileCheck %s --check-prefix=MSFIXIT
 // RUN: %clang_cc1 -triple i686-pc-windows-gnu -Wcast-calling-convention 
-fdiagnostics-parseable-fixits %s 2>&1 | FileCheck %s --check-prefix=GNUFIXIT
 
-// Check that the warning is disabled by default:
-// RUN: %clang_cc1 -fms-extensions -triple i686-pc-windows-msvc -DMSVC -Werror 
-Wno-pointer-bool-conversion -x c %s
-
 // expected-note@+1 {{consider defining 'mismatched_before_winapi' with the 
'stdcall' calling convention}}
 void mismatched_before_winapi(int x) {}
 


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

Re: [PATCH] D20326: [clang-tidy] Fix a template function false positive in misc-unused-using-decls check.

[Haojian Wu via cfe-commits]

hokein marked an inline comment as done.


Comment at: clang-tidy/misc/UnusedUsingDeclsCheck.cpp:24
@@ +23,3 @@
+AST_MATCHER(CallExpr, hasUnresolvedLookupExpr) {
+  return isa(Node.getCallee());
+}

alexfh wrote:
> I think, we should use a node matcher for `UnresolvedLookupExpr` and instead 
> use `callExpr(callee(unresolvedLookupExpr().bind("something")))`.
> 
> Also, I would create the new matcher in the ASTMatchers.h right away, 
> together with a test and docs. But if you want this patch to be in soon, feel 
> free to move the matcher to the matchers library in a follow up.
Agree. I will add a node matcher for `UnresolvedLookupExpr` in a follow-up 
patch.


http://reviews.llvm.org/D20326



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

Re: [PATCH] D20326: [clang-tidy] Fix a template function false positive in misc-unused-using-decls check.

[Haojian Wu via cfe-commits]

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

Address review comments.


http://reviews.llvm.org/D20326

Files:
  clang-tidy/misc/UnusedUsingDeclsCheck.cpp
  test/clang-tidy/misc-unused-using-decls.cpp

Index: test/clang-tidy/misc-unused-using-decls.cpp
===
--- test/clang-tidy/misc-unused-using-decls.cpp
+++ test/clang-tidy/misc-unused-using-decls.cpp
@@ -16,6 +16,7 @@
  public:
   static int ii;
 };
+template  class J {};
 
 class Base {
  public:
@@ -29,6 +30,7 @@
 int UnusedFunc() { return 1; }
 template  int UsedTemplateFunc() { return 1; }
 template  int UnusedTemplateFunc() { return 1; }
+template  int UsedInTemplateFunc() { return 1; }
 
 class ostream {
 public:
@@ -70,6 +72,13 @@
 using n::cout;
 using n::endl;
 
+using n::UsedInTemplateFunc;
+using n::J;
+template  void Callee() {
+  J j;
+  UsedInTemplateFunc();
+}
+
 #define DEFINE_INT(name)\
   namespace INT {   \
   static const int _##name = 1; \
Index: clang-tidy/misc/UnusedUsingDeclsCheck.cpp
===
--- clang-tidy/misc/UnusedUsingDeclsCheck.cpp
+++ clang-tidy/misc/UnusedUsingDeclsCheck.cpp
@@ -10,20 +10,29 @@
 #include "UnusedUsingDeclsCheck.h"
 #include "clang/AST/ASTContext.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/ASTMatchers/ASTMatchers.h"
 #include "clang/Lex/Lexer.h"
 
 using namespace clang::ast_matchers;
 
 namespace clang {
 namespace tidy {
 namespace misc {
 
+namespace {
+// FIXME: Add a node matcher for UnresolvedLookupExpr in ASTMatcher.
+AST_MATCHER(CallExpr, hasUnresolvedLookupExpr) {
+  return isa(Node.getCallee());
+}
+}
+
 void UnusedUsingDeclsCheck::registerMatchers(MatchFinder *Finder) {
   Finder->addMatcher(usingDecl(isExpansionInMainFile()).bind("using"), this);
   auto DeclMatcher = hasDeclaration(namedDecl().bind("used"));
   Finder->addMatcher(loc(recordType(DeclMatcher)), this);
   Finder->addMatcher(loc(templateSpecializationType(DeclMatcher)), this);
   Finder->addMatcher(declRefExpr().bind("used"), this);
+  Finder->addMatcher(callExpr(hasUnresolvedLookupExpr()).bind("used"), this);
 }
 
 void UnusedUsingDeclsCheck::check(const MatchFinder::MatchResult ) {
@@ -81,6 +90,14 @@
   removeFromFoundDecls(VD);
 }
   }
+  // Check the uninstantiated template function usage.
+  if (auto *CE = Result.Nodes.getNodeAs("used")) {
+auto *ULE = dyn_cast(CE->getCallee());
+for (auto I = ULE->decls_begin(), E = ULE->decls_end(); I != E; ++I) {
+  if (auto *USD = dyn_cast(I.getDecl()))
+removeFromFoundDecls(USD->getTargetDecl()->getCanonicalDecl());
+}
+  }
 }
 
 void UnusedUsingDeclsCheck::removeFromFoundDecls(const Decl *D) {


Index: test/clang-tidy/misc-unused-using-decls.cpp
===
--- test/clang-tidy/misc-unused-using-decls.cpp
+++ test/clang-tidy/misc-unused-using-decls.cpp
@@ -16,6 +16,7 @@
  public:
   static int ii;
 };
+template  class J {};
 
 class Base {
  public:
@@ -29,6 +30,7 @@
 int UnusedFunc() { return 1; }
 template  int UsedTemplateFunc() { return 1; }
 template  int UnusedTemplateFunc() { return 1; }
+template  int UsedInTemplateFunc() { return 1; }
 
 class ostream {
 public:
@@ -70,6 +72,13 @@
 using n::cout;
 using n::endl;
 
+using n::UsedInTemplateFunc;
+using n::J;
+template  void Callee() {
+  J j;
+  UsedInTemplateFunc();
+}
+
 #define DEFINE_INT(name)\
   namespace INT {   \
   static const int _##name = 1; \
Index: clang-tidy/misc/UnusedUsingDeclsCheck.cpp
===
--- clang-tidy/misc/UnusedUsingDeclsCheck.cpp
+++ clang-tidy/misc/UnusedUsingDeclsCheck.cpp
@@ -10,20 +10,29 @@
 #include "UnusedUsingDeclsCheck.h"
 #include "clang/AST/ASTContext.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/ASTMatchers/ASTMatchers.h"
 #include "clang/Lex/Lexer.h"
 
 using namespace clang::ast_matchers;
 
 namespace clang {
 namespace tidy {
 namespace misc {
 
+namespace {
+// FIXME: Add a node matcher for UnresolvedLookupExpr in ASTMatcher.
+AST_MATCHER(CallExpr, hasUnresolvedLookupExpr) {
+  return isa(Node.getCallee());
+}
+}
+
 void UnusedUsingDeclsCheck::registerMatchers(MatchFinder *Finder) {
   Finder->addMatcher(usingDecl(isExpansionInMainFile()).bind("using"), this);
   auto DeclMatcher = hasDeclaration(namedDecl().bind("used"));
   Finder->addMatcher(loc(recordType(DeclMatcher)), this);
   Finder->addMatcher(loc(templateSpecializationType(DeclMatcher)), this);
   Finder->addMatcher(declRefExpr().bind("used"), this);
+  Finder->addMatcher(callExpr(hasUnresolvedLookupExpr()).bind("used"), this);
 }
 
 void UnusedUsingDeclsCheck::check(const MatchFinder::MatchResult ) {
@@ -81,6 +90,14 @@
   removeFromFoundDecls(VD);
 }
   }
+  // Check the uninstantiated template function usage.
+  if (auto *CE = 

Re: r269214 - Relax -Wcalling-convention-cast when casting to the default convention (cdecl)

[Reid Kleckner via cfe-commits]

Cool, r269780. Let's see if anyone finds any bugs or false positives.

On Mon, May 16, 2016 at 4:10 PM, Nico Weber  wrote:
> After this tweak, Chromium builds cleanly with the new warning enabled.
> Maybe it's time to turn it on by default.
>
> On Wed, May 11, 2016 at 1:43 PM, Reid Kleckner via cfe-commits
>  wrote:
>>
>> Author: rnk
>> Date: Wed May 11 12:43:13 2016
>> New Revision: 269214
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=269214=rev
>> Log:
>> Relax -Wcalling-convention-cast when casting to the default convention
>> (cdecl)
>>
>> Modified:
>> cfe/trunk/lib/Sema/SemaCast.cpp
>> cfe/trunk/test/Sema/callingconv-cast.c
>>
>> Modified: cfe/trunk/lib/Sema/SemaCast.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaCast.cpp?rev=269214=269213=269214=diff
>>
>> ==
>> --- cfe/trunk/lib/Sema/SemaCast.cpp (original)
>> +++ cfe/trunk/lib/Sema/SemaCast.cpp Wed May 11 12:43:13 2016
>> @@ -1760,7 +1760,15 @@ static void DiagnoseCallingConvCast(Sema
>>if (!FD || !FD->hasBody(Definition))
>>  return;
>>
>> -  // The source expression is a pointer to a known function defined in
>> this TU.
>> +  // Only warn if we are casting from the default convention to a
>> non-default
>> +  // convention. This can happen when the programmer forgot to apply the
>> calling
>> +  // convention to the function definition and then inserted this cast to
>> +  // satisfy the type system.
>> +  CallingConv DefaultCC =
>> Self.getASTContext().getDefaultCallingConvention(
>> +  FD->isVariadic(), FD->isCXXInstanceMember());
>> +  if (DstCC == DefaultCC || SrcCC != DefaultCC)
>> +return;
>> +
>>// Diagnose this cast, as it is probably bad.
>>StringRef SrcCCName = FunctionType::getNameForCallConv(SrcCC);
>>StringRef DstCCName = FunctionType::getNameForCallConv(DstCC);
>>
>> Modified: cfe/trunk/test/Sema/callingconv-cast.c
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/callingconv-cast.c?rev=269214=269213=269214=diff
>>
>> ==
>> --- cfe/trunk/test/Sema/callingconv-cast.c (original)
>> +++ cfe/trunk/test/Sema/callingconv-cast.c Wed May 11 12:43:13 2016
>> @@ -21,6 +21,10 @@ void mismatched(int x) {}
>>  typedef void (WINAPI *callback_t)(int);
>>  void take_callback(callback_t callback);
>>
>> +void WINAPI mismatched_stdcall(int x) {}
>> +
>> +void take_opaque_fn(void (*callback)(int));
>> +
>>  int main() {
>>// expected-warning@+1 {{cast between incompatible calling conventions
>> 'cdecl' and 'stdcall'}}
>>take_callback((callback_t)mismatched);
>> @@ -44,6 +48,11 @@ int main() {
>>
>>// Another way to suppress the warning.
>>take_callback((callback_t)(void*)mismatched);
>> +
>> +  // Don't warn, because we're casting from stdcall to cdecl. Usually
>> that means
>> +  // the programmer is rinsing the function pointer through some kind of
>> opaque
>> +  // API.
>> +  take_opaque_fn((void (*)(int))mismatched_stdcall);
>>  }
>>
>>  // MSFIXIT: fix-it:"{{.*}}callingconv-cast.c":{19:6-19:6}:"WINAPI "
>>
>>
>> ___
>> 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

r269780 - Tentatively enable -Wcast-calling-convention by default

[Reid Kleckner via cfe-commits]

Author: rnk
Date: Tue May 17 11:50:45 2016
New Revision: 269780

URL: http://llvm.org/viewvc/llvm-project?rev=269780=rev
Log:
Tentatively enable -Wcast-calling-convention by default

In Chrome, this would have found two true positives around CreateThread
if we hadn't already fixed them while rolling out ASan. We didn't get
any other hits in Chrome. I'm curious to hear if this warning finds
anything in other projects.

Modified:
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td

Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=269780=269779=269780=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Tue May 17 11:50:45 
2016
@@ -6639,7 +6639,7 @@ def warn_function_def_in_objc_container
 def warn_cast_calling_conv : Warning<
   "cast between incompatible calling conventions '%0' and '%1'; "
   "calls through this pointer may abort at runtime">,
-  InGroup>, DefaultIgnore;
+  InGroup>;
 def note_change_calling_conv_fixit : Note<
   "consider defining %0 with the '%1' calling convention">;
 def warn_bad_function_cast : Warning<


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

Re: [PATCH] D19816: [find-all-symbols] Add IWYU private pragma support.

[Haojian Wu via cfe-commits]

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

Rebase.


http://reviews.llvm.org/D19816

Files:
  include-fixer/find-all-symbols/CMakeLists.txt
  include-fixer/find-all-symbols/FindAllSymbols.cpp
  include-fixer/find-all-symbols/FindAllSymbols.h
  include-fixer/find-all-symbols/HeaderMapCollector.h
  include-fixer/find-all-symbols/PragmaCommentHandler.cpp
  include-fixer/find-all-symbols/PragmaCommentHandler.h
  include-fixer/find-all-symbols/tool/FindAllSymbolsMain.cpp
  unittests/include-fixer/find-all-symbols/FindAllSymbolsTests.cpp

Index: unittests/include-fixer/find-all-symbols/FindAllSymbolsTests.cpp
===
--- unittests/include-fixer/find-all-symbols/FindAllSymbolsTests.cpp
+++ unittests/include-fixer/find-all-symbols/FindAllSymbolsTests.cpp
@@ -8,11 +8,14 @@
 //===--===//
 
 #include "FindAllSymbols.h"
+#include "HeaderMapCollector.h"
+#include "PragmaCommentHandler.h"
 #include "SymbolInfo.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
 #include "clang/Basic/FileManager.h"
 #include "clang/Basic/FileSystemOptions.h"
 #include "clang/Basic/VirtualFileSystem.h"
+#include "clang/Frontend/CompilerInstance.h"
 #include "clang/Frontend/PCHContainerOperations.h"
 #include "clang/Tooling/Tooling.h"
 #include "llvm/ADT/IntrusiveRefCntPtr.h"
@@ -50,25 +53,58 @@
   std::vector Symbols;
 };
 
+class TestFindAllSymbolsAction : public clang::ASTFrontendAction {
+public:
+  TestFindAllSymbolsAction(FindAllSymbols::ResultReporter *Reporter)
+  : MatchFinder(), Collector(), Handler(),
+Matcher(Reporter, ) {
+Matcher.registerMatchers();
+  }
+
+  std::unique_ptr
+  CreateASTConsumer(clang::CompilerInstance ,
+StringRef InFile) override {
+Compiler.getPreprocessor().addCommentHandler();
+return MatchFinder.newASTConsumer();
+  }
+
+private:
+  ast_matchers::MatchFinder MatchFinder;
+  HeaderMapCollector Collector;
+  PragmaCommentHandler Handler;
+  FindAllSymbols Matcher;
+};
+
+class TestFindAllSymbolsActionFactory
+: public clang::tooling::FrontendActionFactory {
+public:
+  TestFindAllSymbolsActionFactory(MockReporter *Reporter)
+  : Reporter(Reporter) {}
+  clang::FrontendAction *create() override {
+return new TestFindAllSymbolsAction(Reporter);
+  }
+
+private:
+  MockReporter *const Reporter;
+};
+
 class FindAllSymbolsTest : public ::testing::Test {
 public:
   bool hasSymbol(const SymbolInfo ) {
 return Reporter.hasSymbol(Symbol);
   }
 
   bool runFindAllSymbols(StringRef Code) {
-FindAllSymbols matcher();
-clang::ast_matchers::MatchFinder MatchFinder;
-matcher.registerMatchers();
-
 llvm::IntrusiveRefCntPtr InMemoryFileSystem(
 new vfs::InMemoryFileSystem);
 llvm::IntrusiveRefCntPtr Files(
 new FileManager(FileSystemOptions(), InMemoryFileSystem));
 
 std::string FileName = "symbol.cc";
-std::unique_ptr Factory =
-clang::tooling::newFrontendActionFactory();
+
+std::unique_ptr Factory(
+new TestFindAllSymbolsActionFactory());
+
 tooling::ToolInvocation Invocation(
 {std::string("find_all_symbols"), std::string("-fsyntax-only"),
  std::string("-std=c++11"), FileName},
@@ -327,5 +363,18 @@
   EXPECT_FALSE(hasSymbol(Symbol));
 }
 
+TEST_F(FindAllSymbolsTest, IWYUPrivatePragmaTest) {
+  static const char Code[] = R"(
+// IWYU pragma: private, include "bar.h"
+struct Bar {
+};
+  )";
+  runFindAllSymbols(Code);
+
+  SymbolInfo Symbol =
+  SymbolInfo("Bar", SymbolInfo::SymbolKind::Class, "bar.h", 3, {});
+  EXPECT_TRUE(hasSymbol(Symbol));
+}
+
 } // namespace find_all_symbols
 } // namespace clang
Index: include-fixer/find-all-symbols/tool/FindAllSymbolsMain.cpp
===
--- include-fixer/find-all-symbols/tool/FindAllSymbolsMain.cpp
+++ include-fixer/find-all-symbols/tool/FindAllSymbolsMain.cpp
@@ -8,8 +8,14 @@
 //===--===//
 
 #include "FindAllSymbols.h"
+#include "HeaderMapCollector.h"
+#include "PragmaCommentHandler.h"
 #include "SymbolInfo.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/ASTMatchers/ASTMatchers.h"
+#include "clang/Frontend/CompilerInstance.h"
+#include "clang/Frontend/FrontendActions.h"
+#include "clang/Lex/Preprocessor.h"
 #include "clang/Tooling/CommonOptionsParser.h"
 #include "clang/Tooling/Tooling.h"
 #include "llvm/ADT/ArrayRef.h"
@@ -82,6 +88,31 @@
   std::map Symbols;
 };
 
+class FindAllSymbolsAction : public clang::ASTFrontendAction {
+public:
+  FindAllSymbolsAction()
+  : Reporter(), MatchFinder(), Collector(), Handler(),
+Matcher(, ) {
+Matcher.registerMatchers();
+  }
+
+  std::unique_ptr
+  CreateASTConsumer(clang::CompilerInstance ,
+StringRef InFile) override {
+