Re: [PATCH] D16613: Introduce a cmake module to figure out whether we need to link with libatomic.

[Daniel Sanders via cfe-commits]

dsanders added a comment.

FWIW, the changes in the last revision look minor to me. I doubt it affects the 
LGTM

> Do we have any test cases for arbitrary sized trivally copyable structures? 
> That might also be needed.


The failures in 3.8.0rc1 (and presumably still occur in the 3.8.0rc2 that was 
tagged last night) were all related to 64-bit atomics.


http://reviews.llvm.org/D16613



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

r259637 - Reduce initial Sema memory consumption by 400KB. By Elisavet Sakellari.

[Axel Naumann via cfe-commits]

Author: axel
Date: Wed Feb  3 04:45:22 2016
New Revision: 259637

URL: http://llvm.org/viewvc/llvm-project?rev=259637=rev
Log:
Reduce initial Sema memory consumption by 400KB. By Elisavet Sakellari.

Modified:
cfe/trunk/lib/Sema/SemaOpenMP.cpp

Modified: cfe/trunk/lib/Sema/SemaOpenMP.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaOpenMP.cpp?rev=259637=259636=259637=diff
==
--- cfe/trunk/lib/Sema/SemaOpenMP.cpp (original)
+++ cfe/trunk/lib/Sema/SemaOpenMP.cpp Wed Feb  3 04:45:22 2016
@@ -123,7 +123,7 @@ private:
   CancelRegion(false), AssociatedLoops(1), InnerTeamsRegionLoc() {}
   };
 
-  typedef SmallVector StackTy;
+  typedef SmallVector StackTy;
 
   /// \brief Stack of used declaration and their data-sharing attributes.
   StackTy Stack;


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

RE: [cfe-commits] r170428 [1/3] - in /cfe/trunk: include/clang/AST/ include/clang/Basic/ include/clang/Sema/ include/clang/Serialization/ lib/AST/ lib/CodeGen/ lib/Parse/ lib/Sema/ lib/Serialization/

[Benyei, Guy via cfe-commits]

Hi Richard,
Since these are OpenCL specific types, I think you are right,  these types 
shouldn't be part of the C++ ABI library.

Thanks
 Guy

-Original Message-
From: meta...@gmail.com [mailto:meta...@gmail.com] On Behalf Of Richard Smith
Sent: Wednesday, February 03, 2016 02:46
To: Benyei, Guy ; cfe-commits 
Subject: Fwd: [cfe-commits] r170428 [1/3] - in /cfe/trunk: include/clang/AST/ 
include/clang/Basic/ include/clang/Sema/ include/clang/Serialization/ lib/AST/ 
lib/CodeGen/ lib/Parse/ lib/Sema/ lib/Serialization/ test/CodeGenOpenCL/ 
test/PCH/ test/Parser/ tools/li...

Hi Guy,

> Modified: cfe/trunk/lib/CodeGen/CGRTTI.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGRTTI.cpp?r
> ev=170428=170427=170428=diff
> ==
> 
> --- cfe/trunk/lib/CodeGen/CGRTTI.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGRTTI.cpp Tue Dec 18 06:30:03 2012
> @@ -1,1011 +1,1017 @@
[...]
> -/// TypeInfoIsInStandardLibrary - Given a builtin type, returns 
> whether the type -/// info for that type is defined in the standard library.
> -static bool TypeInfoIsInStandardLibrary(const BuiltinType *Ty) {
> -  // Itanium C++ ABI 2.9.2:
> -  //   Basic type information (e.g. for "int", "bool", etc.) will be kept in
> -  //   the run-time support library. Specifically, the run-time support
> -  //   library should contain type_info objects for the types X, X* and
> -  //   X const*, for every X in: void, std::nullptr_t, bool, wchar_t, char,
> -  //   unsigned char, signed char, short, unsigned short, int, unsigned int,
> -  //   long, unsigned long, long long, unsigned long long, float, double,
> -  //   long double, char16_t, char32_t, and the IEEE 754r decimal and
> -  //   half-precision floating point types.
> -  switch (Ty->getKind()) {
> -case BuiltinType::Void:
> -case BuiltinType::NullPtr:
> -case BuiltinType::Bool:
> -case BuiltinType::WChar_S:
> -case BuiltinType::WChar_U:
> -case BuiltinType::Char_U:
> -case BuiltinType::Char_S:
> -case BuiltinType::UChar:
> -case BuiltinType::SChar:
> -case BuiltinType::Short:
> -case BuiltinType::UShort:
> -case BuiltinType::Int:
> -case BuiltinType::UInt:
> -case BuiltinType::Long:
> -case BuiltinType::ULong:
> -case BuiltinType::LongLong:
> -case BuiltinType::ULongLong:
> -case BuiltinType::Half:
> -case BuiltinType::Float:
> -case BuiltinType::Double:
> -case BuiltinType::LongDouble:
> -case BuiltinType::Char16:
> -case BuiltinType::Char32:
> -case BuiltinType::Int128:
> -case BuiltinType::UInt128:
> -  return true;
> +/// TypeInfoIsInStandardLibrary - Given a builtin type, returns 
> +whether the type /// info for that type is defined in the standard library.
> +static bool TypeInfoIsInStandardLibrary(const BuiltinType *Ty) {
> +  // Itanium C++ ABI 2.9.2:
> +  //   Basic type information (e.g. for "int", "bool", etc.) will be kept in
> +  //   the run-time support library. Specifically, the run-time support
> +  //   library should contain type_info objects for the types X, X* and
> +  //   X const*, for every X in: void, std::nullptr_t, bool, wchar_t, char,
> +  //   unsigned char, signed char, short, unsigned short, int, unsigned int,
> +  //   long, unsigned long, long long, unsigned long long, float, double,
> +  //   long double, char16_t, char32_t, and the IEEE 754r decimal and
> +  //   half-precision floating point types.
> +  switch (Ty->getKind()) {
> +case BuiltinType::Void:
> +case BuiltinType::NullPtr:
> +case BuiltinType::Bool:
> +case BuiltinType::WChar_S:
> +case BuiltinType::WChar_U:
> +case BuiltinType::Char_U:
> +case BuiltinType::Char_S:
> +case BuiltinType::UChar:
> +case BuiltinType::SChar:
> +case BuiltinType::Short:
> +case BuiltinType::UShort:
> +case BuiltinType::Int:
> +case BuiltinType::UInt:
> +case BuiltinType::Long:
> +case BuiltinType::ULong:
> +case BuiltinType::LongLong:
> +case BuiltinType::ULongLong:
> +case BuiltinType::Half:
> +case BuiltinType::Float:
> +case BuiltinType::Double:
> +case BuiltinType::LongDouble:
> +case BuiltinType::Char16:
> +case BuiltinType::Char32:
> +case BuiltinType::Int128:
> +case BuiltinType::UInt128:
> +case BuiltinType::OCLImage1d:
> +case BuiltinType::OCLImage1dArray:
> +case BuiltinType::OCLImage1dBuffer:
> +case BuiltinType::OCLImage2d:
> +case BuiltinType::OCLImage2dArray:
> +case BuiltinType::OCLImage3d:
> +  return true;

This change is wrong. If you add types here, you must also add them to
EmitFundamentalRTTIDescriptor:

[...]
> -void CodeGenModule::EmitFundamentalRTTIDescriptor(QualType Type) {
> -  QualType PointerType = Context.getPointerType(Type);
> -  QualType PointerTypeConst = 
> 

Re: [PATCH] D14471: [AArch64] Fix a crash in driver

[Renato Golin via cfe-commits]

rengolin added subscribers: labrinea, bsmith.
rengolin added a comment.

Hi,

I think it's clear now to me that this strategy isn't going to work. What you 
need is to add support for AArch64 in the TargetParser and simplify the name 
matching in the same way we did for ARM. There really is no other meaningful 
way of doing this.

Please check with Bradley and Alexandros, as they were the ones dealing with 
this last.

cheers,
--renato



Comment at: lib/Driver/Tools.cpp:1026
@@ +1025,3 @@
+/// valid AArch64 cpu.
+static std::pair
+getAArch64FeaturesFromCPU(StringRef CPU) {

You don't need the IsValid flag, since if the returned vector is empty, it has 
the same semantics.

Also, you're returning the vector by value, whereas the pattern used in this 
file is to pass a reference to the vector as an argument.


Comment at: lib/Driver/Tools.cpp:1042
@@ +1041,3 @@
+
+  return std::make_pair(Features, IsValid);
+}

You don't need to return a pair. Pass the vector by reference.

You may return a boolean for the IsValid, if there is a case where an empty 
vector is valid (no default properties). But as it stands, you don't really 
need to.


Comment at: lib/Driver/Tools.cpp:1047
@@ +1046,3 @@
+/// targeting. Return false to indicate the cpu is not a valid AArch64 cpu.
+static std::pair
+getAArch64TargetCPU(const ArgList ) {

Avoid using pairs as return type. This is really meant for extremely connected 
concepts, not to make C++ look like Perl.


Comment at: lib/Driver/Tools.cpp:1073
@@ +1072,3 @@
+IsNative = true;
+CPU = llvm::sys::getHostCPUName();
+  }

You could have used a different variable and avoided the ternary operator below.


Comment at: lib/Driver/Tools.cpp:1077
@@ +1076,3 @@
+  // Check if CPU is a valid aarch64 cpu.
+  if (getAArch64FeaturesFromCPU(CPU).second)
+return std::make_pair(CPU, true);

That's a misuse of this function. You're building a vector, filling it with 
stuff, copying it back to a temp and throwing it away just for the CPU name 
detection.

This is clearly a job for the TargetParser.


http://reviews.llvm.org/D14471



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

Re: [PATCH] D16801: [OpenMP] Change in initial size of DSAStackTy::StackTy

[Axel Naumann via cfe-commits]

karies added a subscriber: karies.
karies closed this revision.
karies added a comment.

Committed as r259637


http://reviews.llvm.org/D16801



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

r259639 - -inline-asm][X86] Add ability to use AVX512 in MS inline asm

[Marina Yatsina via cfe-commits]

Author: myatsina
Date: Wed Feb  3 05:32:08 2016
New Revision: 259639

URL: http://llvm.org/viewvc/llvm-project?rev=259639=rev
Log:
-inline-asm][X86] Add ability to use AVX512 in MS inline asm

Defined the new AVX512 registers in clang inline asm.
Fixed a bug in the MC subtarget info creation during the parsing of MS asm 
statement - now it receives the actual CPU and target features information.

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


Added:
cfe/trunk/test/CodeGen/ms-inline-asm-avx512.c   (with props)
Modified:
cfe/trunk/lib/Basic/Targets.cpp
cfe/trunk/lib/Parse/ParseStmtAsm.cpp
cfe/trunk/test/Sema/asm.c

Modified: cfe/trunk/lib/Basic/Targets.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=259639=259638=259639=diff
==
--- cfe/trunk/lib/Basic/Targets.cpp (original)
+++ cfe/trunk/lib/Basic/Targets.cpp Wed Feb  3 05:32:08 2016
@@ -2047,6 +2047,14 @@ static const char* const GCCRegNames[] =
   "xmm8", "xmm9", "xmm10", "xmm11", "xmm12", "xmm13", "xmm14", "xmm15",
   "ymm0", "ymm1", "ymm2", "ymm3", "ymm4", "ymm5", "ymm6", "ymm7",
   "ymm8", "ymm9", "ymm10", "ymm11", "ymm12", "ymm13", "ymm14", "ymm15",
+  "xmm16", "xmm17", "xmm18", "xmm19", "xmm20", "xmm21", "xmm22", "xmm23",
+  "xmm24", "xmm25", "xmm26", "xmm27", "xmm28", "xmm29", "xmm30", "xmm31",
+  "ymm16", "ymm17", "ymm18", "ymm19", "ymm20", "ymm21", "ymm22", "ymm23",
+  "ymm24", "ymm25", "ymm26", "ymm27", "ymm28", "ymm29", "ymm30", "ymm31",
+  "zmm0", "zmm1", "zmm2", "zmm3", "zmm4", "zmm5", "zmm6", "zmm7",
+  "zmm8", "zmm9", "zmm10", "zmm11", "zmm12", "zmm13", "zmm14", "zmm15",
+  "zmm16", "zmm17", "zmm18", "zmm19", "zmm20", "zmm21", "zmm22", "zmm23",
+  "zmm24", "zmm25", "zmm26", "zmm27", "zmm28", "zmm29", "zmm30", "zmm31",
 };
 
 const TargetInfo::AddlRegName AddlRegNames[] = {

Modified: cfe/trunk/lib/Parse/ParseStmtAsm.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/ParseStmtAsm.cpp?rev=259639=259638=259639=diff
==
--- cfe/trunk/lib/Parse/ParseStmtAsm.cpp (original)
+++ cfe/trunk/lib/Parse/ParseStmtAsm.cpp Wed Feb  3 05:32:08 2016
@@ -17,6 +17,7 @@
 #include "clang/Basic/Diagnostic.h"
 #include "clang/Basic/TargetInfo.h"
 #include "llvm/ADT/SmallString.h"
+#include "llvm/ADT/StringExtras.h"
 #include "llvm/MC/MCAsmInfo.h"
 #include "llvm/MC/MCContext.h"
 #include "llvm/MC/MCInstPrinter.h"
@@ -522,13 +523,17 @@ StmtResult Parser::ParseMicrosoftAsmStat
   if (buildMSAsmString(PP, AsmLoc, AsmToks, TokOffsets, AsmString))
 return StmtError();
 
+  TargetOptions TO = Actions.Context.getTargetInfo().getTargetOpts();
+  std::string FeaturesStr =
+  llvm::join(TO.Features.begin(), TO.Features.end(), ",");
+
   std::unique_ptr MRI(TheTarget->createMCRegInfo(TT));
   std::unique_ptr MAI(TheTarget->createMCAsmInfo(*MRI, TT));
   // Get the instruction descriptor.
   std::unique_ptr MII(TheTarget->createMCInstrInfo());
   std::unique_ptr MOFI(new llvm::MCObjectFileInfo());
   std::unique_ptr STI(
-  TheTarget->createMCSubtargetInfo(TT, "", ""));
+  TheTarget->createMCSubtargetInfo(TT, TO.CPU, FeaturesStr));
 
   llvm::SourceMgr TempSrcMgr;
   llvm::MCContext Ctx(MAI.get(), MRI.get(), MOFI.get(), );

Added: cfe/trunk/test/CodeGen/ms-inline-asm-avx512.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/ms-inline-asm-avx512.c?rev=259639=auto
==
--- cfe/trunk/test/CodeGen/ms-inline-asm-avx512.c (added)
+++ cfe/trunk/test/CodeGen/ms-inline-asm-avx512.c Wed Feb  3 05:32:08 2016
@@ -0,0 +1,11 @@
+// REQUIRES: x86-registered-target
+// RUN: %clang_cc1 %s -triple x86_64-pc-windows-msvc -target-cpu knl 
-fasm-blocks -emit-llvm -o - | FileCheck %s
+
+void t1() {
+// CHECK: @t1
+// CHECK: call void asm sideeffect inteldialect "vaddpd zmm8, zmm27, zmm6", 
"~{zmm8},~{dirflag},~{fpsr},~{flags}"()
+// CHECK: ret void
+  __asm {
+ vaddpd zmm8, zmm27, zmm6
+  }
+}

Propchange: cfe/trunk/test/CodeGen/ms-inline-asm-avx512.c
--
svn:eol-style = native

Propchange: cfe/trunk/test/CodeGen/ms-inline-asm-avx512.c
--
svn:keywords = Author Date Id Rev URL

Propchange: cfe/trunk/test/CodeGen/ms-inline-asm-avx512.c
--
svn:mime-type = text/plain

Modified: cfe/trunk/test/Sema/asm.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/asm.c?rev=259639=259638=259639=diff
==
--- cfe/trunk/test/Sema/asm.c (original)
+++ cfe/trunk/test/Sema/asm.c Wed Feb  3 05:32:08 2016
@@ -25,7 +25,7 @@ void clobbers() {
   asm ("nop" : : : "0", 

[clang-tools-extra] r259640 - clang-tidy: [misc-unused-parameters] Ignore template instantiations.

[Daniel Jasper via cfe-commits]

Author: djasper
Date: Wed Feb  3 05:33:18 2016
New Revision: 259640

URL: http://llvm.org/viewvc/llvm-project?rev=259640=rev
Log:
clang-tidy: [misc-unused-parameters] Ignore template instantiations.

No functional changes intended as we should already do the
corresponding fixes when visiting the primary template. There are
existing tests that verify that we do change unused parameters of
templated functions.

Modified:
clang-tools-extra/trunk/clang-tidy/misc/UnusedParametersCheck.cpp

Modified: clang-tools-extra/trunk/clang-tidy/misc/UnusedParametersCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/misc/UnusedParametersCheck.cpp?rev=259640=259639=259640=diff
==
--- clang-tools-extra/trunk/clang-tidy/misc/UnusedParametersCheck.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/misc/UnusedParametersCheck.cpp Wed Feb  
3 05:33:18 2016
@@ -104,7 +104,8 @@ void UnusedParametersCheck::warnOnUnused
 void UnusedParametersCheck::check(const MatchFinder::MatchResult ) {
   const auto *Function = Result.Nodes.getNodeAs("function");
   if (!Function->doesThisDeclarationHaveABody() ||
-  !Function->hasWrittenPrototype())
+  !Function->hasWrittenPrototype() ||
+  Function->isTemplateInstantiation())
 return;
   if (const auto *Method = dyn_cast(Function))
 if (Method->isLambdaStaticInvoker())


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

Re: [PATCH] D16376: clang-tidy check: rule-of-five

[Jonathan B Coe via cfe-commits]

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

I think I'll move this check to `cppcoreguidelines` and call it `rule-of-five`.

https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#c21-if-you-define-or-delete-any-default-operation-define-or-delete-them-all

I'll add destructor handling as a later patch.


http://reviews.llvm.org/D16376



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

Re: [PATCH] D16376: clang-tidy check: rule-of-five

[Jonathan B Coe via cfe-commits]

jbcoe retitled this revision from "clang-tidy check: Assignment and 
Construction" to "clang-tidy check: rule-of-five".
jbcoe removed rL LLVM as the repository for this revision.
jbcoe updated this revision to Diff 46775.
jbcoe added a comment.

I've responded to review comments (thanks for those) and renamed the check to 
'rule-of-five'.

I think it needs moving to cppcoreguidelines and needs destructor handling 
adding to it. As suggested, I'll address that in a later patch if everything 
else looks ok.


http://reviews.llvm.org/D16376

Files:
  clang-tidy/misc/CMakeLists.txt
  clang-tidy/misc/MiscTidyModule.cpp
  clang-tidy/misc/RuleOfFiveCheck.cpp
  clang-tidy/misc/RuleOfFiveCheck.h
  docs/clang-tidy/checks/list.rst
  docs/clang-tidy/checks/misc-rule-of-five.rst
  test/clang-tidy/misc-rule-of-five.cpp

Index: test/clang-tidy/misc-rule-of-five.cpp
===
--- /dev/null
+++ test/clang-tidy/misc-rule-of-five.cpp
@@ -0,0 +1,209 @@
+// RUN: %check_clang_tidy %s misc-rule-of-five %t
+
+//
+// User defined copy constructors
+//
+class A {
+  A(const A &);
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: class 'A' defines a copy constructor but not a copy assignment operator [misc-rule-of-five]
+};
+
+// CHECK-FIXES: class A {
+// CHECK-FIXES-NEXT: A(const A &);
+// CHECK-FIXES-NEXT: A =(const A &) = delete;
+// CHECK-FIXES-NEXT: //
+// CHECK-FIXES-NEXT: };
+
+class B {
+  B(const B &);
+  B =(const B &);
+};
+
+class C {
+  C(const C &) = default;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: class 'C' defines a copy constructor but not a copy assignment operator [misc-rule-of-five]
+};
+
+// CHECK-FIXES: class C {
+// CHECK-FIXES-NEXT: C(const C &) = default;
+// CHECK-FIXES-NEXT: C =(const C &) = default;
+// CHECK-FIXES-NEXT: //
+// CHECK-FIXES-NEXT: };
+
+class D {
+  D(const D &);
+  D =(const D &) = default;
+};
+
+class E {
+  E(const E &);
+  E =(const E &) = delete;
+};
+
+class F {
+  F(const F &) = delete;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: class 'F' defines a copy constructor but not a copy assignment operator [misc-rule-of-five]
+};
+
+// CHECK-FIXES: class F {
+// CHECK-FIXES-NEXT: F(const F &) = delete;
+// CHECK-FIXES-NEXT: F =(const F &) = delete;
+// CHECK-FIXES-NEXT: //
+// CHECK-FIXES-NEXT: };
+
+
+//
+// User defined copy assignment
+//
+class A2 {
+  A2 =(const A2 &);
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: class 'A2' defines a copy assignment operator but not a copy constructor [misc-rule-of-five]
+};
+
+// CHECK-FIXES: class A2 {
+// CHECK-FIXES-NEXT: A2(const A2 &) = delete;
+// CHECK-FIXES-NEXT: A2 =(const A2 &);
+// CHECK-FIXES-NEXT: //
+// CHECK-FIXES-NEXT: };
+
+class B2 {
+  B2(const B2 &);
+  B2 =(const B2 &);
+};
+
+class C2 {
+  C2 =(const C2 &) = default;
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: class 'C2' defines a copy assignment operator but not a copy constructor [misc-rule-of-five]
+};
+
+// CHECK-FIXES: class C2 {
+// CHECK-FIXES-NEXT: C2(const C2 &) = default;
+// CHECK-FIXES-NEXT: C2 =(const C2 &) = default;
+// CHECK-FIXES-NEXT: //
+// CHECK-FIXES-NEXT: };
+
+class D2 {
+  D2(const D2 &) = default;
+  D2 =(const D2 &);
+};
+
+class E2 {
+  E2(const E2 &) = delete;
+  E2 =(const E2 &);
+};
+
+class F2 {
+  F2 =(const F2 &) = delete;
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: class 'F2' defines a copy assignment operator but not a copy constructor [misc-rule-of-five]
+};
+
+// CHECK-FIXES: class F2 {
+// CHECK-FIXES-NEXT: F2(const F2 &) = delete;
+// CHECK-FIXES-NEXT: F2 =(const F2 &) = delete;
+// CHECK-FIXES-NEXT: //
+// CHECK-FIXES-NEXT: };
+
+
+//
+// User defined move constructors
+//
+class A3 {
+  A3(A3 &&);
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: class 'A3' defines a move constructor but not a move assignment operator [misc-rule-of-five]
+};
+
+// CHECK-FIXES: class A3 {
+// CHECK-FIXES-NEXT: A3(A3 &&);
+// CHECK-FIXES-NEXT: A3 =(A3 &&) = delete;
+// CHECK-FIXES-NEXT: //
+// CHECK-FIXES-NEXT: };
+
+class B3 {
+  B3(B3 &&);
+  B3 =(B3 &&);
+};
+
+class C3 {
+  C3(C3 &&) = default;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: class 'C3' defines a move constructor but not a move assignment operator [misc-rule-of-five]
+};
+
+// CHECK-FIXES: class C3 {
+// CHECK-FIXES-NEXT: C3(C3 &&) = default;
+// CHECK-FIXES-NEXT: C3 =(C3 &&) = default;
+// CHECK-FIXES-NEXT: //
+// CHECK-FIXES-NEXT: };
+
+class D3 {
+  D3(D3 &&);
+  D3 =(D3 &&) = default;
+};
+
+class E3 {
+  E3(E3 &&);
+  E3 =(E3 &&) = delete;
+};
+
+class F3 {
+  F3(F3 &&) = delete;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: class 'F3' defines a move constructor but not a move assignment operator [misc-rule-of-five]
+};
+
+// CHECK-FIXES: class F3 {
+// CHECK-FIXES-NEXT: F3(F3 &&) = delete;
+// CHECK-FIXES-NEXT: F3 =(F3 &&) = delete;
+// CHECK-FIXES-NEXT: //
+// CHECK-FIXES-NEXT: };
+
+
+//
+// User defined move assignment
+//
+class A4 {
+  A4 =(A4 &&);
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: class 'A4' 

Re: [PATCH] D16539: [FIX] 26194 - LLVM crash in CXXNameMangler::mangleType

[Igor Chesnokov via cfe-commits]

ichesnokov added a comment.

I noticed that MicrosoftMangler already has many extension functions. I.e. this 
MicrosoftMangler.cpp change is Ok.
Please review and accept/commit.


http://reviews.llvm.org/D16539



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

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

[Andrey Bokhanko via cfe-commits]

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

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

http://reviews.llvm.org/D16851

Files:
  docs/UsersManual.rst

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


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

[clang-tools-extra] r259643 - [clang-tidy] bug fix: Don't warn on partial template specialization in `misc-definitions-in-headers` check.

[Haojian Wu via cfe-commits]

Author: hokein
Date: Wed Feb  3 06:10:27 2016
New Revision: 259643

URL: http://llvm.org/viewvc/llvm-project?rev=259643=rev
Log:
[clang-tidy] bug fix: Don't warn on partial template specialization in 
`misc-definitions-in-headers` check.

Reviewers: alexfh

Subscribers: cfe-commits

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

Modified:
clang-tools-extra/trunk/clang-tidy/misc/DefinitionsInHeadersCheck.cpp
clang-tools-extra/trunk/test/clang-tidy/misc-definitions-in-headers.hpp

Modified: clang-tools-extra/trunk/clang-tidy/misc/DefinitionsInHeadersCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/misc/DefinitionsInHeadersCheck.cpp?rev=259643=259642=259643=diff
==
--- clang-tools-extra/trunk/clang-tidy/misc/DefinitionsInHeadersCheck.cpp 
(original)
+++ clang-tools-extra/trunk/clang-tidy/misc/DefinitionsInHeadersCheck.cpp Wed 
Feb  3 06:10:27 2016
@@ -91,9 +91,12 @@ void DefinitionsInHeadersCheck::check(co
 if (const auto *MD = dyn_cast(FD)) {
   const auto *DC = MD->getDeclContext();
   while (DC->isRecord()) {
-if (const auto *RD = dyn_cast(DC))
+if (const auto *RD = dyn_cast(DC)) {
+  if (isa(RD))
+return;
   if (RD->getDescribedClassTemplate())
 return;
+}
 DC = DC->getParent();
   }
 }

Modified: 
clang-tools-extra/trunk/test/clang-tidy/misc-definitions-in-headers.hpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/misc-definitions-in-headers.hpp?rev=259643=259642=259643=diff
==
--- clang-tools-extra/trunk/test/clang-tidy/misc-definitions-in-headers.hpp 
(original)
+++ clang-tools-extra/trunk/test/clang-tidy/misc-definitions-in-headers.hpp Wed 
Feb  3 06:10:27 2016
@@ -133,3 +133,28 @@ const char* const g = "foo"; // OK: inte
 static int h = 1; // OK: internal linkage variable definition.
 const int i = 1; // OK: internal linkage variable definition.
 extern int j; // OK: internal linkage variable definition.
+
+template 
+struct CD {
+  int f();
+};
+
+template 
+struct CD {
+  int f();
+};
+
+template <>
+struct CD {
+  int f();
+};
+
+int CD::f() {
+// CHECK-MESSAGES: :[[@LINE-1]]:19: warning: function 'f' defined in a header 
file;
+  return 0;
+}
+
+template 
+int CD::f() { // OK: partial template specialization.
+  return 0;
+}


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

r259647 - Forgot to remove file in previous commit.

[Yury Gribov via cfe-commits]

Author: ygribov
Date: Wed Feb  3 07:36:31 2016
New Revision: 259647

URL: http://llvm.org/viewvc/llvm-project?rev=259647=rev
Log:
Forgot to remove file in previous commit.

Removed:
cfe/trunk/test/Analysis/analyze_display_progress.c

Removed: cfe/trunk/test/Analysis/analyze_display_progress.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Analysis/analyze_display_progress.c?rev=259646=auto
==
--- cfe/trunk/test/Analysis/analyze_display_progress.c (original)
+++ cfe/trunk/test/Analysis/analyze_display_progress.c (removed)
@@ -1,9 +0,0 @@
-// RUN: %clang_cc1 -analyze -analyzer-display-progress %s 2>&1 | FileCheck %s
-
-void f() {};
-void g() {};
-void h() {}
-
-// CHECK: analyze_display_progress.c f
-// CHECK: analyze_display_progress.c g
-// CHECK: analyze_display_progress.c h
\ No newline at end of file


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

Re: [PATCH] D16539: [FIX] 26194 - LLVM crash in CXXNameMangler::mangleType

[Igor Chesnokov via cfe-commits]

ichesnokov updated the summary for this revision.
ichesnokov updated this revision to Diff 46772.
ichesnokov added a comment.

This diff adds mangling check test cases for Itanium and Microsoft manglers


http://reviews.llvm.org/D16539

Files:
  lib/AST/ItaniumMangle.cpp
  lib/AST/MicrosoftMangle.cpp
  test/CodeGenOpenCL/generic-mangling-itanium.cl
  test/CodeGenOpenCL/generic-mangling-microsoft.cl

Index: test/CodeGenOpenCL/generic-mangling-microsoft.cl
===
--- test/CodeGenOpenCL/generic-mangling-microsoft.cl
+++ test/CodeGenOpenCL/generic-mangling-microsoft.cl
@@ -0,0 +1,11 @@
+// RUN: %clang_cc1 -triple i686-pc-windows-msvc -emit-llvm -x cl -cl-std=CL2.0 
-o - %s | FileCheck %s
+
+// CHECK: define zeroext i1 
@"\01?atomic_compare_exchange_strong@@$$J0YA_NPCU8CLglobalU?$_Atomic@H@__clang@@PAU9CLgenericHH@Z"(i32*
 %object, i32* %expected, i32 %desired)
+bool __attribute__((__overloadable__)) atomic_compare_exchange_strong(
+   volatile  __global atomic_int *object,
+  int  *expected,
+  int  desired)
+{
+  return atomic_compare_exchange_strong_explicit(
+object, expected, desired, 1, 2);
+}
Index: test/CodeGenOpenCL/generic-mangling-itanium.cl
===
--- test/CodeGenOpenCL/generic-mangling-itanium.cl
+++ test/CodeGenOpenCL/generic-mangling-itanium.cl
@@ -0,0 +1,11 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -x cl 
-cl-std=CL2.0 -o - %s | FileCheck %s
+
+// CHECK: 
_Z30atomic_compare_exchange_strongPVU8CLglobalU7_AtomiciPU9CLgenericii
+bool __attribute__((__overloadable__)) atomic_compare_exchange_strong(
+   volatile  __global atomic_int *object,
+  int  *expected,
+  int  desired)
+{
+  return atomic_compare_exchange_strong_explicit(
+object, expected, desired, 1, 2);
+}
Index: lib/AST/MicrosoftMangle.cpp
===
--- lib/AST/MicrosoftMangle.cpp
+++ lib/AST/MicrosoftMangle.cpp
@@ -1383,6 +1383,37 @@
 }
   }
 
+  if (Quals.hasAddressSpace()) {
+// Address space extension:
+//
+//::= U 
+//::= U 
+//::= U 
+
+SmallString<64> ASString;
+unsigned AS = Quals.getAddressSpace();
+
+if (Context.getASTContext().addressSpaceMapManglingFor(AS)) {
+  //   ::= "AS" 
+  unsigned TargetAS = Context.getASTContext().getTargetAddressSpace(AS);
+  ASString = "AS" + llvm::utostr(TargetAS);
+} else {
+  switch (AS) {
+  default: llvm_unreachable("Not a language specific address space");
+//   ::= "CL" [ "global" | "local" | "constant" ]
+  case LangAS::opencl_global:   ASString = "CLglobal";   break;
+  case LangAS::opencl_local:ASString = "CLlocal";break;
+  case LangAS::opencl_constant: ASString = "CLconstant"; break;
+  case LangAS::opencl_generic:  ASString = "CLgeneric";  break;
+//   ::= "CU" [ "device" | "constant" | "shared" ]
+  case LangAS::cuda_device: ASString = "CUdevice";   break;
+  case LangAS::cuda_constant:   ASString = "CUconstant"; break;
+  case LangAS::cuda_shared: ASString = "CUshared";   break;
+  }
+}
+Out << 'U' << ASString.size() << ASString;
+  }
+
   // FIXME: For now, just drop all extension qualifiers on the floor.
 }
 
Index: lib/AST/ItaniumMangle.cpp
===
--- lib/AST/ItaniumMangle.cpp
+++ lib/AST/ItaniumMangle.cpp
@@ -1796,6 +1796,7 @@
   case LangAS::opencl_global:   ASString = "CLglobal";   break;
   case LangAS::opencl_local:ASString = "CLlocal";break;
   case LangAS::opencl_constant: ASString = "CLconstant"; break;
+  case LangAS::opencl_generic:  ASString = "CLgeneric";  break;
   //   ::= "CU" [ "device" | "constant" | "shared" ]
   case LangAS::cuda_device: ASString = "CUdevice";   break;
   case LangAS::cuda_constant:   ASString = "CUconstant"; break;


Index: test/CodeGenOpenCL/generic-mangling-microsoft.cl
===
--- test/CodeGenOpenCL/generic-mangling-microsoft.cl
+++ test/CodeGenOpenCL/generic-mangling-microsoft.cl
@@ -0,0 +1,11 @@
+// RUN: %clang_cc1 -triple i686-pc-windows-msvc -emit-llvm -x cl -cl-std=CL2.0 -o - %s | FileCheck %s
+
+// CHECK: define zeroext i1 @"\01?atomic_compare_exchange_strong@@$$J0YA_NPCU8CLglobalU?$_Atomic@H@__clang@@PAU9CLgenericHH@Z"(i32* %object, i32* %expected, i32 %desired)
+bool __attribute__((__overloadable__)) atomic_compare_exchange_strong(
+	volatile  __global atomic_int *object,
+  int  *expected,
+  int  desired)
+{
+  return atomic_compare_exchange_strong_explicit(
+object, expected, desired, 1, 2);
+}
Index: test/CodeGenOpenCL/generic-mangling-itanium.cl
===
--- test/CodeGenOpenCL/generic-mangling-itanium.cl
+++ 

r259646 - [analyzer] AnalysisConsumer: print fully-qualified function name while displaying progress

[Yury Gribov via cfe-commits]

Author: ygribov
Date: Wed Feb  3 07:35:33 2016
New Revision: 259646

URL: http://llvm.org/viewvc/llvm-project?rev=259646=rev
Log:
[analyzer] AnalysisConsumer: print fully-qualified function name while 
displaying progress

-analyzer-display progress option prints only function names which may be 
ambiguous. This patch forces AnalysisConsumer to print fully-qualified function 
names.
Patch by Alex Sidorin!

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

Added:
cfe/trunk/test/Analysis/analyze_display_progress.cpp
Modified:
cfe/trunk/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp

Modified: cfe/trunk/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp?rev=259646=259645=259646=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp (original)
+++ cfe/trunk/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp Wed Feb  3 
07:35:33 2016
@@ -274,7 +274,7 @@ public:
   llvm::errs() << ": " << Loc.getFilename();
   if (isa(D) || isa(D)) {
 const NamedDecl *ND = cast(D);
-llvm::errs() << ' ' << *ND << '\n';
+llvm::errs() << ' ' << ND->getQualifiedNameAsString() << '\n';
   }
   else if (isa(D)) {
 llvm::errs() << ' ' << "block(line:" << Loc.getLine() << ",col:"

Added: cfe/trunk/test/Analysis/analyze_display_progress.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Analysis/analyze_display_progress.cpp?rev=259646=auto
==
--- cfe/trunk/test/Analysis/analyze_display_progress.cpp (added)
+++ cfe/trunk/test/Analysis/analyze_display_progress.cpp Wed Feb  3 07:35:33 
2016
@@ -0,0 +1,26 @@
+// RUN: %clang_cc1 -analyze -analyzer-display-progress %s 2>&1 | FileCheck %s
+
+void f() {};
+void g() {};
+void h() {}
+
+struct SomeStruct {
+  void f() {}
+};
+
+struct SomeOtherStruct {
+  void f() {}
+};
+
+namespace ns {
+  struct SomeStruct {
+void f() {}
+  };
+}
+
+// CHECK: analyze_display_progress.cpp f
+// CHECK: analyze_display_progress.cpp g
+// CHECK: analyze_display_progress.cpp h
+// CHECK: analyze_display_progress.cpp SomeStruct::f
+// CHECK: analyze_display_progress.cpp SomeOtherStruct::f
+// CHECK: analyze_display_progress.cpp ns::SomeStruct::f


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

Re: [PATCH] D16804: [analyzer] AnalysisConsumer: print fully-qualified function name while displaying progress

[Yury Gribov via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL259646: [analyzer] AnalysisConsumer: print fully-qualified 
function name while… (authored by ygribov).

Changed prior to commit:
  http://reviews.llvm.org/D16804?vs=46640=46777#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D16804

Files:
  cfe/trunk/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
  cfe/trunk/test/Analysis/analyze_display_progress.cpp

Index: cfe/trunk/test/Analysis/analyze_display_progress.cpp
===
--- cfe/trunk/test/Analysis/analyze_display_progress.cpp
+++ cfe/trunk/test/Analysis/analyze_display_progress.cpp
@@ -0,0 +1,26 @@
+// RUN: %clang_cc1 -analyze -analyzer-display-progress %s 2>&1 | FileCheck %s
+
+void f() {};
+void g() {};
+void h() {}
+
+struct SomeStruct {
+  void f() {}
+};
+
+struct SomeOtherStruct {
+  void f() {}
+};
+
+namespace ns {
+  struct SomeStruct {
+void f() {}
+  };
+}
+
+// CHECK: analyze_display_progress.cpp f
+// CHECK: analyze_display_progress.cpp g
+// CHECK: analyze_display_progress.cpp h
+// CHECK: analyze_display_progress.cpp SomeStruct::f
+// CHECK: analyze_display_progress.cpp SomeOtherStruct::f
+// CHECK: analyze_display_progress.cpp ns::SomeStruct::f
Index: cfe/trunk/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
===
--- cfe/trunk/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
+++ cfe/trunk/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
@@ -274,7 +274,7 @@
   llvm::errs() << ": " << Loc.getFilename();
   if (isa(D) || isa(D)) {
 const NamedDecl *ND = cast(D);
-llvm::errs() << ' ' << *ND << '\n';
+llvm::errs() << ' ' << ND->getQualifiedNameAsString() << '\n';
   }
   else if (isa(D)) {
 llvm::errs() << ' ' << "block(line:" << Loc.getLine() << ",col:"


Index: cfe/trunk/test/Analysis/analyze_display_progress.cpp
===
--- cfe/trunk/test/Analysis/analyze_display_progress.cpp
+++ cfe/trunk/test/Analysis/analyze_display_progress.cpp
@@ -0,0 +1,26 @@
+// RUN: %clang_cc1 -analyze -analyzer-display-progress %s 2>&1 | FileCheck %s
+
+void f() {};
+void g() {};
+void h() {}
+
+struct SomeStruct {
+  void f() {}
+};
+
+struct SomeOtherStruct {
+  void f() {}
+};
+
+namespace ns {
+  struct SomeStruct {
+void f() {}
+  };
+}
+
+// CHECK: analyze_display_progress.cpp f
+// CHECK: analyze_display_progress.cpp g
+// CHECK: analyze_display_progress.cpp h
+// CHECK: analyze_display_progress.cpp SomeStruct::f
+// CHECK: analyze_display_progress.cpp SomeOtherStruct::f
+// CHECK: analyze_display_progress.cpp ns::SomeStruct::f
Index: cfe/trunk/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
===
--- cfe/trunk/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
+++ cfe/trunk/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
@@ -274,7 +274,7 @@
   llvm::errs() << ": " << Loc.getFilename();
   if (isa(D) || isa(D)) {
 const NamedDecl *ND = cast(D);
-llvm::errs() << ' ' << *ND << '\n';
+llvm::errs() << ' ' << ND->getQualifiedNameAsString() << '\n';
   }
   else if (isa(D)) {
 llvm::errs() << ' ' << "block(line:" << Loc.getLine() << ",col:"
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Alexander Droste via cfe-commits]

Alexander_Droste added a comment.

Hi Anna,

thanks for having a look once more!



Comment at: tools/clang/lib/StaticAnalyzer/Checkers/Checkers.td:75
@@ -74,1 +74,3 @@
 
+def MPI : Package<"mpi">;
+

zaks.anna wrote:
> This should probably go under the 'option' package. What do you think?
Do you mean the 'optin' package? I could not find an 'option' package in 
`Checkers.td`.


Comment at: 
tools/clang/lib/StaticAnalyzer/Checkers/MPI-Checker/MPIBugReporter.h:24
@@ +23,3 @@
+namespace clang {
+namespace mpi {
+

zaks.anna wrote:
> Should this be clang::ento::mpi? Alternatively, you could place everything 
> into a single file and have it live in anonymous namespace. This would also 
> be more consistent with the existing checkers.
I would prefer to put this into `clang::ento::mpi`, rather than having 
everything in a single file.



Comment at: 
tools/clang/lib/StaticAnalyzer/Checkers/MPI-Checker/MPIBugReporter.h:40
@@ +39,3 @@
+
+  // ast reports ––
+

zaks.anna wrote:
> Looks like some of the AST stuff was deleted and some was kept. Please, 
> either remove all of it or keep all of it in.
Sorry about the inconsistent change. I will remove the AST related
functionality completety from this patch, as it will be part of the clang-tidy 
patch.


Comment at: 
tools/clang/lib/StaticAnalyzer/Checkers/MPI-Checker/MPIChecker.cpp:43
@@ +42,3 @@
+private:
+  const std::unique_ptr CheckerSens;
+

zaks.anna wrote:
> I'd stress "path" instead of "sensitive" in the name. Also, this indirection 
> is redundant if you remove the AST checks.
If sufficient, I would rename `MPICheckerPathSensitive` to `MPICheckerPath` 
then.
Do you mind the indirection?


Comment at: 
tools/clang/lib/StaticAnalyzer/Checkers/MPI-Checker/MPICheckerPathSensitive.cpp:74
@@ +73,3 @@
+  // A wait has no matching nonblocking call.
+  BugReporter.reportUnmatchedWait(PreCallEvent, ReqRegion, ExplNode);
+}

zaks.anna wrote:
> This is called in a loop. Should you break once the first error is reported?
> 
> Also, as before you should use the CheckerContext API to produce a node on 
> which the error should be reported.
> 
> 
I don't think break should be called after the first error is reported. Each 
memory region
represents a different request, why this should be rated as multiple errors. 


Comment at: 
tools/clang/lib/StaticAnalyzer/Checkers/MPI-Checker/MPICheckerPathSensitive.cpp:79
@@ +78,3 @@
+  if (!ReqRegions.empty()) {
+Ctx.addTransition(State);
+  }

zaks.anna wrote:
> Don't forget to specify a predecessor here once the code above changes.
Will do.


Comment at: 
tools/clang/lib/StaticAnalyzer/Checkers/MPI-Checker/MPICheckerPathSensitive.h:87
@@ +86,3 @@
+  const MPIFunctionClassifier FuncClassifier;
+  MPIBugReporter BugReporter;
+};

zaks.anna wrote:
> Please, use a name other than 'BugReporter' to avoid confusing it with the 
> BugReporter in the analyzer.
I see, that could be confusing. Maybe renaming the variable to BReporter will 
do.


Comment at: 
tools/clang/lib/StaticAnalyzer/Checkers/MPI-Checker/MPIFunctionClassifier.h:45
@@ +44,3 @@
+  bool isAllgatherType(const clang::IdentifierInfo *const IdentInfo) const;
+  bool isAlltoallType(const clang::IdentifierInfo *const IdentInfo) const;
+  bool isReduceType(const clang::IdentifierInfo *const IdentInfo) const;

zaks.anna wrote:
> Some of these classifier functions are not used either..
These model distinct MPI function classes. I agree that it would be better to 
remove the unused ones, in order to keep the interface as narrow as possible.


Comment at: tools/clang/lib/StaticAnalyzer/Checkers/MPI-Checker/MPITypes.h:56
@@ +55,3 @@
+struct RequestMap {};
+typedef llvm::ImmutableMap RequestMapImpl;

zaks.anna wrote:
> Let's add some documentation on why you are not using the standard macro 
> REGISTER_MAP_WITH_PROGRAMSTATE. (Might help to avoid confusion lear on.)
Sure, I can do that.


Comment at: tools/clang/lib/StaticAnalyzer/Checkers/MPI-Checker/Utility.cpp:21
@@ +20,3 @@
+
+namespace util {
+

zaks.anna wrote:
> I'd like to remove the Utility.cpp completely by either making the helper 
> functions static or moving them to other shared components.
So where shall we put `sourceRange()`? It is only used by the BugReporter class.
I could make it a member function of the Reporter class. Or would you prefer 
this
as a member function of `MemRegion`?


Comment at: tools/clang/lib/StaticAnalyzer/Checkers/MPI-Checker/Utility.cpp:47
@@ +46,3 @@
+
+const clang::IdentifierInfo *getIdentInfo(const clang::CallExpr *CE) {
+  if (CE->getDirectCallee()) {

zaks.anna wrote:
> This 

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

[H.J Lu via cfe-commits]

hjl.tools added a comment.

I am planning to update i386, x86-64 and IA MCU psABIs to address how to
pass and return C++ empty class after resolving:

https://llvm.org/bugs/show_bug.cgi?id=26337

by updating C++ ABI to explicitly pass and return C++ empty class like C empty
structure.


http://reviews.llvm.org/D16808



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

Re: [PATCH] D16638: [CUDA] Added device-side system call decls and related wrappers.

[Artem Belevich via cfe-commits]

tra closed this revision.
tra added a comment.

Committed in r259690


http://reviews.llvm.org/D16638



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

Re: [PATCH] D13893: Roll-back r250822.

[Alexander Riccio via cfe-commits]

ariccio added a comment.

See original diff here: http://reviews.llvm.org/D13890


Repository:
  rL LLVM

http://reviews.llvm.org/D13893



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

Re: [PATCH] D13893: Roll-back r250822.

[Alexander Riccio via cfe-commits]

ariccio added a subscriber: ariccio.
ariccio added a comment.

Whatever happened to this? What in `ASTMatchers` did it break? It seems like a 
good change, and nobody followed up to fix it?


Repository:
  rL LLVM

http://reviews.llvm.org/D13893



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

Re: r258782 - Recommit: R258773 [OpenCL] Pipe builtin functions

[Hans Wennborg via cfe-commits]

On Wed, Feb 3, 2016 at 1:00 PM, Richard Smith  wrote:
> On Wed, Feb 3, 2016 at 11:08 AM, Anastasia Stulova
>  wrote:
>>
>> I think the main reason is that we have committed pipe type before the
>> release branch was taken. It appears to have no use without the pipe builtin
>> functions.
>>
>> Are there any risks of adding this now?
>
>
> Based on my post-commit review of the patch, I don't think this is yet
> mature enough for 3.8 (in particular, it improperly handles type sugar, and
> should be performing argument conversions in SemaChecking rather than in
> CGBuiltin). If you're confident that this can be cleaned up in time, and
> Hans is prepared to take those cleanup patches onto the branch too, then I
> think this is fine to go into 3.8 to finish off the OpenCL pipe work.

I wouldn't be keen on taking those patches. We've already tagged RC2,
and I want bugfixes only going forward. I think the reality is that
this landed a little too late to make it into the release, and will
have to wait until 3.9.

 - Hans


>> -Original Message-
>> From: meta...@gmail.com [mailto:meta...@gmail.com] On Behalf Of Richard
>> Smith
>> Sent: 01 February 2016 21:54
>> To: Hans Wennborg
>> Cc: xiuli pan; cfe-commits; Pekka Jääskeläinen; Anastasia Stulova
>> Subject: Re: r258782 - Recommit: R258773 [OpenCL] Pipe builtin functions
>>
>> On Thu, Jan 28, 2016 at 11:25 AM, Hans Wennborg 
>> wrote:
>> > I don't think we have a specific code owner for OpenCL in Clang, which
>> > means Richard is the owner.
>> >
>> > Richard, what do you think?
>>
>> Is there a reason we want to push this new feature into 3.8 rather than
>> waiting for the next release?
>>
>> > On Wed, Jan 27, 2016 at 10:08 PM, xiuli pan 
>> > wrote:
>> >> Hi hans,
>> >>
>> >> Request to merge it to release 38
>> >>
>> >> It adds Pipe BIFs to be used along with Pipe type committed earlier (in
>> >> r257254).
>> >>
>> >> Thanks
>> >> Xiuli
>> >>
>> >> -Original Message-
>> >> From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On
>> >> Behalf Of Xiuli Pan via cfe-commits
>> >> Sent: Tuesday, January 26, 2016 12:04 PM
>> >> To: cfe-commits@lists.llvm.org
>> >> Subject: r258782 - Recommit: R258773 [OpenCL] Pipe builtin functions
>> >>
>> >> Author: pxl
>> >> Date: Mon Jan 25 22:03:48 2016
>> >> New Revision: 258782
>> >>
>> >> URL: http://llvm.org/viewvc/llvm-project?rev=258782=rev
>> >> Log:
>> >> Recommit: R258773 [OpenCL] Pipe builtin functions Fix arc patch fuzz
>> >> error.
>> >> Summary:
>> >> Support for the pipe built-in functions for OpenCL 2.0.
>> >> The pipe builtin functions may have infinite kinds of element types,
>> >> one approach would be to just generate calls that would always use
>> >> generic types such as void*.
>> >> This patch is based on bader's opencl support patch on SPIR-V branch.
>> >>
>> >> Reviewers: Anastasia, pekka.jaaskelainen
>> >>
>> >> Subscribers: keryell, bader, cfe-commits
>> >>
>> >> Differential Revision: http://reviews.llvm.org/D15914
>> >>
>> >> Added:
>> >> cfe/trunk/test/CodeGenOpenCL/pipe_builtin.cl
>> >> cfe/trunk/test/SemaOpenCL/invalid-pipe-builtin-cl2.0.cl
>> >> Modified:
>> >> cfe/trunk/include/clang/Basic/Builtins.def
>> >> cfe/trunk/include/clang/Basic/Builtins.h
>> >> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
>> >> cfe/trunk/lib/Basic/Builtins.cpp
>> >> cfe/trunk/lib/CodeGen/CGBuiltin.cpp
>> >> cfe/trunk/lib/Sema/SemaChecking.cpp
>> >>
>> >> Modified: cfe/trunk/include/clang/Basic/Builtins.def
>> >> URL:
>> >> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Bui
>> >> ltins.def?rev=258782=258781=258782=diff
>> >> =
>> >> =
>> >> --- cfe/trunk/include/clang/Basic/Builtins.def (original)
>> >> +++ cfe/trunk/include/clang/Basic/Builtins.def Mon Jan 25 22:03:48
>> >> +++ 2016
>> >> @@ -1252,6 +1252,32 @@ BUILTIN(__builtin___get_unsafe_stack_ptr
>> >>  BUILTIN(__builtin_nontemporal_store, "v.", "t")
>> >> BUILTIN(__builtin_nontemporal_load, "v.", "t")
>> >>
>> >> +// OpenCL v2.0 s6.13.16, s9.17.3.5 - Pipe functions.
>> >> +// We need the generic prototype, since the packet type could be
>> >> anything.
>> >> +LANGBUILTIN(read_pipe, "i.", "tn", OCLC_LANG)
>> >> +LANGBUILTIN(write_pipe, "i.", "tn", OCLC_LANG)
>> >> +
>> >> +LANGBUILTIN(reserve_read_pipe, "i.", "tn", OCLC_LANG)
>> >> +LANGBUILTIN(reserve_write_pipe, "i.", "tn", OCLC_LANG)
>> >> +
>> >> +LANGBUILTIN(commit_write_pipe, "v.", "tn", OCLC_LANG)
>> >> +LANGBUILTIN(commit_read_pipe, "v.", "tn", OCLC_LANG)
>> >> +
>> >> +LANGBUILTIN(sub_group_reserve_read_pipe, "i.", "tn", OCLC_LANG)
>> >> +LANGBUILTIN(sub_group_reserve_write_pipe, "i.", "tn", OCLC_LANG)
>> >> +
>> >> +LANGBUILTIN(sub_group_commit_read_pipe, "v.", "tn", OCLC_LANG)
>> >> +LANGBUILTIN(sub_group_commit_write_pipe, "v.", "tn", OCLC_LANG)
>> >> +

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

[Yaxun Liu via cfe-commits]

yaxunl updated this revision to Diff 46838.
yaxunl marked 3 inline comments as done.
yaxunl added a comment.

Revised as Anastasia suggested.


http://reviews.llvm.org/D16686

Files:
  include/clang/Basic/Attr.td
  include/clang/Basic/AttrDocs.td
  include/clang/Basic/DiagnosticParseKinds.td
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Parse/Parser.h
  lib/CodeGen/CGLoopInfo.cpp
  lib/Parse/ParseDecl.cpp
  lib/Parse/ParseStmt.cpp
  lib/Sema/SemaStmtAttr.cpp
  test/CodeGenOpenCL/unroll-hint.cl
  test/Parser/opencl-unroll-hint.cl
  test/SemaOpenCL/unroll-hint.cl

Index: test/SemaOpenCL/unroll-hint.cl
===
--- /dev/null
+++ test/SemaOpenCL/unroll-hint.cl
@@ -0,0 +1,24 @@
+//RUN: %clang_cc1 -O0 -cl-std=CL2.0 -fsyntax-only -verify %s
+
+kernel void C (global int *x) {
+  int I = 3;
+  __attribute__((opencl_unroll_hint(I))) // expected-error {{'opencl_unroll_hint' attribute requires an integer constant}}
+  while (I--);
+}
+
+kernel void D (global int *x) {
+  int i = 10;
+  __attribute__((opencl_unroll_hint))
+  do {
+  } while(i--);
+}
+
+kernel void E() {
+  __attribute__((opencl_unroll_hint(2,4))) // expected-error {{'opencl_unroll_hint' attribute takes no more than 1 argument}}
+  for(int i=0; i<100; i++);
+}
+
+kernel void F() {
+  __attribute__((opencl_unroll_hint(-1))) // expected-error {{'opencl_unroll_hint' attribute requires a positive integral compile time constant expression}}
+  for(int i=0; i<100; i++);
+}
Index: test/Parser/opencl-unroll-hint.cl
===
--- /dev/null
+++ test/Parser/opencl-unroll-hint.cl
@@ -0,0 +1,8 @@
+//RUN: %clang_cc1 -O0 -cl-std=CL2.0 -fsyntax-only -verify %s
+
+kernel void B (global int *x) {
+  __attribute__((opencl_unroll_hint(42)))
+  if (x[0]) // expected-error {{OpenCL only supports 'opencl_unroll_hint' attribute on for, while, and do statements}}
+x[0] = 15;
+}
+
Index: test/CodeGenOpenCL/unroll-hint.cl
===
--- /dev/null
+++ test/CodeGenOpenCL/unroll-hint.cl
@@ -0,0 +1,96 @@
+// RUN: %clang_cc1 -emit-llvm -O0 -cl-std=CL2.0 -o - %s | FileCheck %s
+
+/*** for ***/
+void for_count()
+{
+// CHECK-LABEL: for_count
+__attribute__((opencl_unroll_hint(8)))
+for( int i = 0; i < 1000; ++i);
+// CHECK: br label %{{.*}}, !llvm.loop ![[FOR_COUNT:.*]]
+}
+
+void for_disable()
+{
+// CHECK-LABEL: for_disable
+__attribute__((opencl_unroll_hint(1)))
+for( int i = 0; i < 1000; ++i);
+// CHECK: br label %{{.*}}, !llvm.loop ![[FOR_DISABLE:.*]]
+}
+
+void for_full()
+{
+// CHECK-LABEL: for_full
+__attribute__((opencl_unroll_hint))
+for( int i = 0; i < 1000; ++i);
+// CHECK: br label %{{.*}}, !llvm.loop ![[FOR_FULL:.*]]
+}
+
+/*** while ***/
+void while_count()
+{
+// CHECK-LABEL: while_count
+int i = 1000;
+__attribute__((opencl_unroll_hint(8)))
+while(i-->0);
+// CHECK: br label %{{.*}}, !llvm.loop ![[WHILE_COUNT:.*]]
+}
+
+void while_disable()
+{
+// CHECK-LABEL: while_disable
+int i = 1000;
+__attribute__((opencl_unroll_hint(1)))
+while(i-->0);
+// CHECK: br label %{{.*}}, !llvm.loop ![[WHILE_DISABLE:.*]]
+}
+
+void while_full()
+{
+// CHECK-LABEL: while_full
+int i = 1000;
+__attribute__((opencl_unroll_hint))
+while(i-->0);
+// CHECK: br label %{{.*}}, !llvm.loop ![[WHILE_FULL:.*]]
+}
+
+/*** do ***/
+void do_count()
+{
+// CHECK-LABEL: do_count
+int i = 1000;
+__attribute__((opencl_unroll_hint(8)))
+do {} while(i--> 0);
+// CHECK: br i1 %{{.*}}, label %{{.*}}, label %{{.*}}, !llvm.loop ![[DO_COUNT:.*]]
+}
+
+void do_disable()
+{
+// CHECK-LABEL: do_disable
+int i = 1000;
+__attribute__((opencl_unroll_hint(1)))
+do {} while(i--> 0);
+// CHECK: br i1 %{{.*}}, label %{{.*}}, label %{{.*}}, !llvm.loop ![[DO_DISABLE:.*]]
+}
+
+void do_full()
+{
+// CHECK-LABEL: do_full
+int i = 1000;
+__attribute__((opencl_unroll_hint))
+do {} while(i--> 0);
+// CHECK: br i1 %{{.*}}, label %{{.*}}, label %{{.*}}, !llvm.loop ![[DO_FULL:.*]]
+}
+
+
+// CHECK: ![[FOR_COUNT]] =  distinct !{![[FOR_COUNT]],  ![[COUNT:.*]]}
+// CHECK: ![[COUNT]] =  !{!"llvm.loop.unroll.count", i32 8}
+// CHECK: ![[FOR_DISABLE]]   =  distinct !{![[FOR_DISABLE]],  ![[DISABLE:.*]]}
+// CHECK: ![[DISABLE]]   =  !{!"llvm.loop.unroll.disable"}
+// CHECK: ![[FOR_FULL]]  =  distinct !{![[FOR_FULL]],  ![[FULL:.*]]}
+// CHECK: ![[FULL]]  =  !{!"llvm.loop.unroll.full"}
+// CHECK: ![[WHILE_COUNT]]   =  distinct !{![[WHILE_COUNT]],![[COUNT]]}
+// CHECK: ![[WHILE_DISABLE]] =  distinct !{![[WHILE_DISABLE]],  ![[DISABLE]]}
+// CHECK: ![[WHILE_FULL]]=  distinct !{![[WHILE_FULL]], ![[FULL]]}
+// CHECK: ![[DO_COUNT]]  =  distinct !{![[DO_COUNT]],   ![[COUNT]]}
+// CHECK: ![[DO_DISABLE]]=  distinct !{![[DO_DISABLE]], ![[DISABLE]]}
+// CHECK: ![[DO_FULL]]   =  

r259690 - [CUDA] added declarations for device-side system calls

[Artem Belevich via cfe-commits]

Author: tra
Date: Wed Feb  3 14:53:58 2016
New Revision: 259690

URL: http://llvm.org/viewvc/llvm-project?rev=259690=rev
Log:
[CUDA] added declarations for device-side system calls

...and std:: wrappers for free/malloc.

Modified:
cfe/trunk/lib/Headers/__clang_cuda_runtime_wrapper.h

Modified: cfe/trunk/lib/Headers/__clang_cuda_runtime_wrapper.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/__clang_cuda_runtime_wrapper.h?rev=259690=259689=259690=diff
==
--- cfe/trunk/lib/Headers/__clang_cuda_runtime_wrapper.h (original)
+++ cfe/trunk/lib/Headers/__clang_cuda_runtime_wrapper.h Wed Feb  3 14:53:58 
2016
@@ -80,17 +80,15 @@
 // definitions from .hpp files.
 #define __DEVICE_FUNCTIONS_H__
 #define __MATH_FUNCTIONS_H__
+#define __COMMON_FUNCTIONS_H__
 
 #undef __CUDACC__
 #define __CUDABE__
 // Disables definitions of device-side runtime support stubs in
 // cuda_device_runtime_api.h
-#define __CUDADEVRT_INTERNAL__
 #include "host_config.h"
 #include "host_defines.h"
 #include "driver_types.h"
-#include "common_functions.h"
-#undef __CUDADEVRT_INTERNAL__
 
 #undef __CUDABE__
 #define __CUDACC__
@@ -211,13 +209,42 @@ extern "C" __device__ __attribute__((con
 static __device__ __attribute__((used)) int __nvvm_reflect_anchor() {
   return __nvvm_reflect("NONE");
 }
-
-// The nvptx vprintf syscall.  This doesn't actually need to be declared, but 
we
-// declare it so that if someone else declares it with a different signature,
-// we'll throw an error.
-extern "C" __device__ int vprintf(const char*, const char*);
 #endif
 
+extern "C" {
+// Device-side CUDA system calls.
+// 
http://docs.nvidia.com/cuda/ptx-writers-guide-to-interoperability/index.html#system-calls
+// We need these declarations and wrappers for device-side
+// malloc/free/printf calls to work without relying on
+// -fcuda-disable-target-call-checks option.
+__device__ int vprintf(const char*, const char*);
+__device__ void free(void *) __attribute((nothrow));
+__device__ void *malloc(size_t) __attribute((nothrow)) __attribute__((malloc));
+__device__ void __assertfail(const char *message, const char *file,
+ unsigned line, const char *function,
+ size_t charSize) __attribute__((noreturn));
+
+// In order for standard assert() macro on linux to work we need to
+// provide device-side __assert_fail()
+__device__ static inline void __assert_fail(const char *message,
+const char *file, unsigned line,
+const char *function) {
+  __assertfail(message, file, line, function, sizeof(char));
+}
+
+// Clang will convert printf into vprintf, but we still need
+// device-side declaration for it.
+__device__ int printf(const char *, ...);
+} // extern "C"
+
+// We also need device-side std::malloc and std::free.
+namespace std {
+__device__ static inline void free(void *__ptr) { ::free(__ptr); }
+__device__ static inline void *malloc(size_t __size) {
+  return ::malloc(__size);
+}
+} // namespace std
+
 #include <__clang_cuda_cmath.h>
 
 #endif // __CUDA__


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

Re: [PATCH] D16259: Add clang-tidy readability-redundant-control-flow check

[Kim Gräsman via cfe-commits]

On Mon, Feb 1, 2016 at 4:32 PM, Aaron Ballman  wrote:
>
> 
> Comment at: clang-tidy/readability/RedundantControlFlowCheck.cpp:60
> @@ +59,3 @@
> +  if (const auto *Return = dyn_cast(*last))
> +issueDiagnostic(Result, Block, Return->getSourceRange(),
> +RedundantReturnDiag);
> 
> It is the LLVM coding style (though I don't personally care for it), and you 
> are right -- a clang-tidy check in the LLVM module wouldn't be amiss. :-)

Isn't this: 
http://clang.llvm.org/extra/clang-tidy/checks/readability-braces-around-statements.html?

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

Re: [PATCH] D16376: clang-tidy check: rule-of-five

[David Blaikie via cfe-commits]

On Wed, Feb 3, 2016 at 1:03 PM, Jonathan Coe  wrote:

>
>
> On 3 February 2016 at 18:44, David Blaikie  wrote:
>
>>
>>
>> On Wed, Feb 3, 2016 at 10:23 AM, Jonathan Coe  wrote:
>>
>>> All the C++ compilers I have tried using (GCC,Clang,MSVC) will generate
>>> assignment operators even if the user defines a copy-constructor. This is
>>> the behaviour I set out to write a check for.
>>>
>>> The cpp core guide lines recommend defining all or none of the special
>>> functions
>>> https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#c21-if-you-define-or-delete-any-default-operation-define-or-delete-them-all
>>>
>>> If the deprecation warning you mention will turn off the deprecated
>>> generation of special member functions when others are defined (or warn
>>> when deprecated compiler-generated functions are used) then the
>>> rule-of-five check is of reduced value.
>>>
>>
>> It can't stop them being generated, because that's required behavior -
>> warnings don't change the program behavior.
>>
>>
> That's true but promoting them to errors will stop compilation and prevent
> the sort of bug I'm trying to stop.
>

Sure - and the user can do that with -Werror=deprecated (but, yes, we
should split out that specific deprecation so it can be turned on without
turning on other deprecation)


>
>
>> Wording like this is in the C++11 standard:
>>
>> "If the class definition does not explicitly declare a copy constructor,
>> one is declared implicitly. If the class definition declares a move
>> constructor or move assignment operator, the implicitly declared copy
>> constructor is defined as deleted; otherwise, it is defined as defaulted
>> (8.4). The latter case is deprecated if the class has a user-declared copy
>> assignment operator or a user-declared destructor."
>>
>>
> The 'deprecated' part is my target. I've seen code with user-defined copy
> constructors behave badly when compiler-generated assignment operators are
> unwittingly used.
>

For sure - because it's only deprecated, not an error. Clang-tidy won't
change that - it still won't be a hard error in every codebase.

I agree that having all the Core Guidelines checks in one place is a good
idea, so I'm not making any real suggestion here, sorry - just that it
seems unfortunate to relegate this check (& encourage explicit & mostly
redundant defaulting/deleting) to a separate tool when it's essentially
built into the language and compiler already. My disagreement is perhaps
more with the Core Guideline than with its implementation here.


> The rule of five lets me locally reason about code without having to worry
> (needlessly or not) about whether some functions are potentially being
> compiler-generated.
>

But once the language does the right thing directly, rather than providing
a clang-tidy warning that encourages you to change the code to achieve the
same result, why would we worry about being explicit?


>
> I don't advocate putting this in 'misc'. It belongs in
> 'cppcoreguidelines', I'll move it if the approach taken thus far is sound
> (as discussed in the review).
>
>
>> (similar wording for the copy assignment operator, the dtor has a
>> different/special case if I recall correctly)
>>
>>
>>>
>>> Jon
>>>
>>> On 3 February 2016 at 17:40, David Blaikie  wrote:
>>>
 Is this really that useful of a rule? The language does the right thing
 for the most part already (you don't need to explicitly delete them -
 they're implicitly deleted if you define any others - except for backcompat
 with C++98, but those cases are deprecated & we should probably split out
 the warning for that deprecation so it's easier to turn on separately)

 On Wed, Feb 3, 2016 at 5:25 AM, Jonathan B Coe via cfe-commits <
 cfe-commits@lists.llvm.org> wrote:

> jbcoe retitled this revision from "clang-tidy check: Assignment and
> Construction" to "clang-tidy check: rule-of-five".
> jbcoe removed rL LLVM as the repository for this revision.
> jbcoe updated this revision to Diff 46775.
> jbcoe added a comment.
>
> I've responded to review comments (thanks for those) and renamed the
> check to 'rule-of-five'.
>
> I think it needs moving to cppcoreguidelines and needs destructor
> handling adding to it. As suggested, I'll address that in a later patch if
> everything else looks ok.
>
>
> http://reviews.llvm.org/D16376
>
> Files:
>   clang-tidy/misc/CMakeLists.txt
>   clang-tidy/misc/MiscTidyModule.cpp
>   clang-tidy/misc/RuleOfFiveCheck.cpp
>   clang-tidy/misc/RuleOfFiveCheck.h
>   docs/clang-tidy/checks/list.rst
>   docs/clang-tidy/checks/misc-rule-of-five.rst
>   test/clang-tidy/misc-rule-of-five.cpp
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> 

Re: [PATCH] D16784: [OpenMP] Reorganize code to allow specialized code generation for different devices.

[Samuel Antao via cfe-commits]

sfantao updated this revision to Diff 46825.
sfantao marked 4 inline comments as done.
sfantao added a comment.

Clean up changes that are not required now.

Use CGOpenMPRuntime to contain everything that requires sharing.

Create diagnostic to notify user about unsupported OpenMP targets.


http://reviews.llvm.org/D16784

Files:
  include/clang/Basic/DiagnosticDriverKinds.td
  lib/CodeGen/CGOpenMPRuntime.cpp
  lib/CodeGen/CGOpenMPRuntime.h
  lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
  lib/CodeGen/CMakeLists.txt
  lib/CodeGen/CodeGenModule.cpp
  lib/Frontend/CompilerInvocation.cpp
  test/OpenMP/target_messages.cpp

Index: test/OpenMP/target_messages.cpp
===
--- test/OpenMP/target_messages.cpp
+++ test/OpenMP/target_messages.cpp
@@ -1,6 +1,9 @@
 // RUN: %clang_cc1 -verify -fopenmp -std=c++11 -o - %s
 // RUN: not %clang_cc1 -fopenmp -std=c++11 -omptargets=aaa-bbb-ccc-ddd -o - %s 2>&1 | FileCheck %s
 // CHECK: error: OpenMP target is invalid: 'aaa-bbb-ccc-ddd'
+// RUN: not %clang_cc1 -fopenmp -std=c++11 -triple nvptx64-nvidia-cuda -o - %s 2>&1 | FileCheck --check-prefix CHECK-UNSUPPORTED-HOST-TARGET %s
+// RUN: not %clang_cc1 -fopenmp -std=c++11 -triple nvptx-nvidia-cuda -o - %s 2>&1 | FileCheck --check-prefix CHECK-UNSUPPORTED-HOST-TARGET %s
+// CHECK-UNSUPPORTED-HOST-TARGET: error: The target '{{nvptx64-nvidia-cuda|nvptx-nvidia-cuda}}' is not a supported OpenMP host target.
 
 void foo() {
 }
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -1427,6 +1427,7 @@
 }
 
 static void ParseLangArgs(LangOptions , ArgList , InputKind IK,
+  const TargetOptions ,
   DiagnosticsEngine ) {
   // FIXME: Cleanup per-file based stuff.
   LangStandard::Kind LangStd = LangStandard::lang_unspecified;
@@ -1822,6 +1823,22 @@
   Opts.OpenMPIsDevice =
   Opts.OpenMP && Args.hasArg(options::OPT_fopenmp_is_device);
 
+  // Provide diagnostic when a given target is not expected to be an OpenMP
+  // device or host.
+  if (Opts.OpenMP && !Opts.OpenMPIsDevice) {
+llvm::Triple T(TargetOpts.Triple);
+switch (T.getArch()) {
+default:
+  break;
+// Add unsupported host targets here:
+case llvm::Triple::nvptx:
+case llvm::Triple::nvptx64:
+  Diags.Report(clang::diag::err_drv_omp_host_or_device_target_not_supported)
+  << TargetOpts.Triple << Opts.OpenMPIsDevice;
+  break;
+}
+  }
+
   // Get the OpenMP target triples if any.
   if (Arg *A = Args.getLastArg(options::OPT_omptargets_EQ)) {
 
@@ -2088,7 +2105,7 @@
 Diags, Res.getLangOpts()->Sanitize);
   } else {
 // Other LangOpts are only initialzed when the input is not AST or LLVM IR.
-ParseLangArgs(*Res.getLangOpts(), Args, DashX, Diags);
+ParseLangArgs(*Res.getLangOpts(), Args, DashX, Res.getTargetOpts(), Diags);
 if (Res.getFrontendOpts().ProgramAction == frontend::RewriteObjC)
   Res.getLangOpts()->ObjCExceptions = 1;
   }
Index: lib/CodeGen/CodeGenModule.cpp
===
--- lib/CodeGen/CodeGenModule.cpp
+++ lib/CodeGen/CodeGenModule.cpp
@@ -200,7 +200,7 @@
 }
 
 void CodeGenModule::createOpenMPRuntime() {
-  OpenMPRuntime = new CGOpenMPRuntime(*this);
+  OpenMPRuntime = CGOpenMPRuntime::create(*this);
 }
 
 void CodeGenModule::createCUDARuntime() {
Index: lib/CodeGen/CMakeLists.txt
===
--- lib/CodeGen/CMakeLists.txt
+++ lib/CodeGen/CMakeLists.txt
@@ -57,6 +57,7 @@
   CGObjCRuntime.cpp
   CGOpenCLRuntime.cpp
   CGOpenMPRuntime.cpp
+  CGOpenMPRuntimeNVPTX.cpp
   CGRecordLayoutBuilder.cpp
   CGStmt.cpp
   CGStmtOpenMP.cpp
Index: lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
===
--- /dev/null
+++ lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
@@ -0,0 +1,30 @@
+//=== CGOpenMPRuntimeNVPTX.cpp - Interface to OpenMP NVPTX Runtimes ---===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+//
+// This provides a class for OpenMP runtime code generation specialized to NVPTX
+// targets.
+//
+//===--===//
+
+#include "CGOpenMPRuntime.h"
+
+namespace clang {
+namespace CodeGen {
+
+class CGOpenMPRuntimeNVPTX : public CGOpenMPRuntime {
+public:
+  explicit CGOpenMPRuntimeNVPTX(CodeGenModule ) : CGOpenMPRuntime(CGM) {}
+};
+
+CGOpenMPRuntime *
+CGOpenMPRuntime::createCGOpenMPRuntimeNVPTX(CodeGenModule ) {
+  return new CGOpenMPRuntimeNVPTX(CGM);
+}
+} // CodeGen namespace.
+} // clang namespace.
Index: 

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

[Ben Craig via cfe-commits]

bcraig added a comment.

@mclow.lists ping


http://reviews.llvm.org/D15539



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

Re: [PATCH] D16376: clang-tidy check: rule-of-five

[Aaron Ballman via cfe-commits]

On Wed, Feb 3, 2016 at 4:13 PM, David Blaikie  wrote:
>
>
> On Wed, Feb 3, 2016 at 1:03 PM, Jonathan Coe  wrote:
>>
>>
>>
>> On 3 February 2016 at 18:44, David Blaikie  wrote:
>>>
>>>
>>>
>>> On Wed, Feb 3, 2016 at 10:23 AM, Jonathan Coe  wrote:

 All the C++ compilers I have tried using (GCC,Clang,MSVC) will generate
 assignment operators even if the user defines a copy-constructor. This is
 the behaviour I set out to write a check for.

 The cpp core guide lines recommend defining all or none of the special
 functions
 https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#c21-if-you-define-or-delete-any-default-operation-define-or-delete-them-all

 If the deprecation warning you mention will turn off the deprecated
 generation of special member functions when others are defined (or warn 
 when
 deprecated compiler-generated functions are used) then the rule-of-five
 check is of reduced value.
>>>
>>>
>>> It can't stop them being generated, because that's required behavior -
>>> warnings don't change the program behavior.
>>>
>>
>> That's true but promoting them to errors will stop compilation and prevent
>> the sort of bug I'm trying to stop.
>
>
> Sure - and the user can do that with -Werror=deprecated (but, yes, we should
> split out that specific deprecation so it can be turned on without turning
> on other deprecation)
>
>>
>>
>>>
>>> Wording like this is in the C++11 standard:
>>>
>>> "If the class definition does not explicitly declare a copy constructor,
>>> one is declared implicitly. If the class definition declares a move
>>> constructor or move assignment operator, the implicitly declared copy
>>> constructor is defined as deleted; otherwise, it is defined as defaulted
>>> (8.4). The latter case is deprecated if the class has a user-declared copy
>>> assignment operator or a user-declared destructor."
>>>
>>
>> The 'deprecated' part is my target. I've seen code with user-defined copy
>> constructors behave badly when compiler-generated assignment operators are
>> unwittingly used.
>
>
> For sure - because it's only deprecated, not an error. Clang-tidy won't
> change that - it still won't be a hard error in every codebase.
>
> I agree that having all the Core Guidelines checks in one place is a good
> idea, so I'm not making any real suggestion here, sorry - just that it seems
> unfortunate to relegate this check (& encourage explicit & mostly redundant
> defaulting/deleting) to a separate tool when it's essentially built into the
> language and compiler already. My disagreement is perhaps more with the Core
> Guideline than with its implementation here.
>
>>
>> The rule of five lets me locally reason about code without having to worry
>> (needlessly or not) about whether some functions are potentially being
>> compiler-generated.
>
>
> But once the language does the right thing directly, rather than providing a
> clang-tidy warning that encourages you to change the code to achieve the
> same result, why would we worry about being explicit?

It could be argued that implicit code generated by the compiler is
magic, and being explicit is a readability improvement. You no longer
have to think "under what circumstances is this generated?"

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

Re: [PATCH] D16259: Add clang-tidy readability-redundant-control-flow check

[Aaron Ballman via cfe-commits]

On Wed, Feb 3, 2016 at 3:57 PM, Kim Gräsman  wrote:
> On Mon, Feb 1, 2016 at 4:32 PM, Aaron Ballman  wrote:
>>
>> 
>> Comment at: clang-tidy/readability/RedundantControlFlowCheck.cpp:60
>> @@ +59,3 @@
>> +  if (const auto *Return = dyn_cast(*last))
>> +issueDiagnostic(Result, Block, Return->getSourceRange(),
>> +RedundantReturnDiag);
>> 
>> It is the LLVM coding style (though I don't personally care for it), and you 
>> are right -- a clang-tidy check in the LLVM module wouldn't be amiss. :-)
>
> Isn't this: 
> http://clang.llvm.org/extra/clang-tidy/checks/readability-braces-around-statements.html?

Yes, that seems to be it. Probably could have an alias in the LLVM
umbrella that points here.

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

r259715 - Revert r259624 - Make CF constant string decl visible to name lookup to fix module errors.

[Quentin Colombet via cfe-commits]

Author: qcolombet
Date: Wed Feb  3 16:14:53 2016
New Revision: 259715

URL: http://llvm.org/viewvc/llvm-project?rev=259715=rev
Log:
Revert r259624 - Make CF constant string decl visible to name lookup to fix 
module errors.

This breaks some internal bots in stage2: clang seg fault.
Looking with Ben to see what is going on.

Modified:
cfe/trunk/include/clang/AST/ASTContext.h
cfe/trunk/include/clang/Serialization/ASTBitCodes.h
cfe/trunk/lib/AST/ASTContext.cpp
cfe/trunk/lib/Sema/Sema.cpp
cfe/trunk/lib/Serialization/ASTReader.cpp
cfe/trunk/lib/Serialization/ASTWriter.cpp
cfe/trunk/test/CodeGenObjC/2010-02-01-utf16-with-null.m
cfe/trunk/test/CodeGenObjC/arc-no-arc-exceptions.m
cfe/trunk/test/CodeGenObjC/tentative-cfconstantstring.m
cfe/trunk/test/Modules/Inputs/builtin.h
cfe/trunk/test/Modules/builtins.m

Modified: cfe/trunk/include/clang/AST/ASTContext.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/ASTContext.h?rev=259715=259714=259715=diff
==
--- cfe/trunk/include/clang/AST/ASTContext.h (original)
+++ cfe/trunk/include/clang/AST/ASTContext.h Wed Feb  3 16:14:53 2016
@@ -1385,7 +1385,6 @@ public:
 return QualType();
   }
   void setCFConstantStringType(QualType T);
-  TagDecl *getCFConstantStringDecl() const;
 
   // This setter/getter represents the ObjC type for an NSConstantString.
   void setObjCConstantStringInterface(ObjCInterfaceDecl *Decl);

Modified: cfe/trunk/include/clang/Serialization/ASTBitCodes.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Serialization/ASTBitCodes.h?rev=259715=259714=259715=diff
==
--- cfe/trunk/include/clang/Serialization/ASTBitCodes.h (original)
+++ cfe/trunk/include/clang/Serialization/ASTBitCodes.h Wed Feb  3 16:14:53 2016
@@ -987,16 +987,13 @@ namespace clang {
 
   /// \brief The internal '__make_integer_seq' template.
   PREDEF_DECL_MAKE_INTEGER_SEQ_ID = 13,
-
-  /// \brief The internal '__NSConstantString' type.
-  PREDEF_DECL_CF_CONSTANT_STRING_ID = 14,
 };
 
 /// \brief The number of declaration IDs that are predefined.
 ///
 /// For more information about predefined declarations, see the
 /// \c PredefinedDeclIDs type and the PREDEF_DECL_*_ID constants.
-const unsigned int NUM_PREDEF_DECL_IDS = 15;
+const unsigned int NUM_PREDEF_DECL_IDS = 14;
 
 /// \brief Record code for a list of local redeclarations of a declaration.
 const unsigned int LOCAL_REDECLARATIONS = 50;

Modified: cfe/trunk/lib/AST/ASTContext.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ASTContext.cpp?rev=259715=259714=259715=diff
==
--- cfe/trunk/lib/AST/ASTContext.cpp (original)
+++ cfe/trunk/lib/AST/ASTContext.cpp Wed Feb  3 16:14:53 2016
@@ -4868,11 +4868,10 @@ int ASTContext::getIntegerTypeOrder(Qual
   return 1;
 }
 
-TagDecl *ASTContext::getCFConstantStringDecl() const {
+// getCFConstantStringType - Return the type used for constant CFStrings.
+QualType ASTContext::getCFConstantStringType() const {
   if (!CFConstantStringTypeDecl) {
-// This type is designed to be compatible with NSConstantString, but cannot
-// use the same name, since NSConstantString is an interface.
-CFConstantStringTypeDecl = buildImplicitRecord("__NSConstantString");
+CFConstantStringTypeDecl = buildImplicitRecord("NSConstantString");
 CFConstantStringTypeDecl->startDefinition();
 
 QualType FieldTypes[4];
@@ -4902,12 +4901,7 @@ TagDecl *ASTContext::getCFConstantString
 CFConstantStringTypeDecl->completeDefinition();
   }
 
-  return CFConstantStringTypeDecl;
-}
-
-// getCFConstantStringType - Return the type used for constant CFStrings.
-QualType ASTContext::getCFConstantStringType() const {
-  return getTagDeclType(getCFConstantStringDecl());
+  return getTagDeclType(CFConstantStringTypeDecl);
 }
 
 QualType ASTContext::getObjCSuperType() const {

Modified: cfe/trunk/lib/Sema/Sema.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/Sema.cpp?rev=259715=259714=259715=diff
==
--- cfe/trunk/lib/Sema/Sema.cpp (original)
+++ cfe/trunk/lib/Sema/Sema.cpp Wed Feb  3 16:14:53 2016
@@ -189,10 +189,6 @@ void Sema::Initialize() {
 DeclarationName Protocol = ("Protocol");
 if (IdResolver.begin(Protocol) == IdResolver.end())
   PushOnScopeChains(Context.getObjCProtocolDecl(), TUScope);
-
-DeclarationName ConstantString = ("NSConstantString");
-if (IdResolver.begin(ConstantString) == IdResolver.end())
-  PushOnScopeChains(Context.getCFConstantStringDecl(), TUScope);
   }
 
   // Initialize Microsoft "predefined C++ types".

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

Re: [PATCH] D16823: [cfi] Safe handling of unaddressable vtable pointers (clang).

[Evgeniy Stepanov via cfe-commits]

eugenis closed this revision.
eugenis added a comment.

http://llvm.org/viewvc/llvm-project?rev=259716=rev


Repository:
  rL LLVM

http://reviews.llvm.org/D16823



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

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

[Alexander Droste via cfe-commits]

Alexander_Droste added a comment.





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

Alexander_Droste wrote:
> xazax.hun wrote:
> > These are the only cases that can occur? So it is not possible to have a 
> > loc index? Maybe we could get the value for loc and nonloc ConcreteInts and 
> > use getVariableName for everzthing else? Would that wok?
> `getIndex()` returns a `nonloc` and `loc` is in no subclass relation to 
> `nonloc`.
> Therefore, `getIndex()` cannot be a `loc` type.
> 
> There are actually 5 `nonloc` subclasses but I assumed 
> that it only makes sense to check for `SymbolVal` and 
> `ConcreteInt`. 
> http://clang.llvm.org/doxygen/classclang_1_1ento_1_1NonLoc.html
> 
> So would you suggest to only check for `ConcreteInt`
> and call `getVariableName()` recursively if it isn't one?
If we want to call `getVariableName` recursively, should we strip the single 
quotes then?
Else we would get something like `'x['a']['b']'`. What do you think?


http://reviews.llvm.org/D16044



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

Re: [PATCH] D16376: clang-tidy check: rule-of-five

[Jonathan Coe via cfe-commits]

On 3 February 2016 at 18:44, David Blaikie  wrote:

>
>
> On Wed, Feb 3, 2016 at 10:23 AM, Jonathan Coe  wrote:
>
>> All the C++ compilers I have tried using (GCC,Clang,MSVC) will generate
>> assignment operators even if the user defines a copy-constructor. This is
>> the behaviour I set out to write a check for.
>>
>> The cpp core guide lines recommend defining all or none of the special
>> functions
>> https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#c21-if-you-define-or-delete-any-default-operation-define-or-delete-them-all
>>
>> If the deprecation warning you mention will turn off the deprecated
>> generation of special member functions when others are defined (or warn
>> when deprecated compiler-generated functions are used) then the
>> rule-of-five check is of reduced value.
>>
>
> It can't stop them being generated, because that's required behavior -
> warnings don't change the program behavior.
>
>
That's true but promoting them to errors will stop compilation and prevent
the sort of bug I'm trying to stop.


> Wording like this is in the C++11 standard:
>
> "If the class definition does not explicitly declare a copy constructor,
> one is declared implicitly. If the class definition declares a move
> constructor or move assignment operator, the implicitly declared copy
> constructor is defined as deleted; otherwise, it is defined as defaulted
> (8.4). The latter case is deprecated if the class has a user-declared copy
> assignment operator or a user-declared destructor."
>
>
The 'deprecated' part is my target. I've seen code with user-defined copy
constructors behave badly when compiler-generated assignment operators are
unwittingly used. The rule of five lets me locally reason about code
without having to worry (needlessly or not) about whether some functions
are potentially being compiler-generated.

I don't advocate putting this in 'misc'. It belongs in 'cppcoreguidelines',
I'll move it if the approach taken thus far is sound (as discussed in the
review).


> (similar wording for the copy assignment operator, the dtor has a
> different/special case if I recall correctly)
>
>
>>
>> Jon
>>
>> On 3 February 2016 at 17:40, David Blaikie  wrote:
>>
>>> Is this really that useful of a rule? The language does the right thing
>>> for the most part already (you don't need to explicitly delete them -
>>> they're implicitly deleted if you define any others - except for backcompat
>>> with C++98, but those cases are deprecated & we should probably split out
>>> the warning for that deprecation so it's easier to turn on separately)
>>>
>>> On Wed, Feb 3, 2016 at 5:25 AM, Jonathan B Coe via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
 jbcoe retitled this revision from "clang-tidy check: Assignment and
 Construction" to "clang-tidy check: rule-of-five".
 jbcoe removed rL LLVM as the repository for this revision.
 jbcoe updated this revision to Diff 46775.
 jbcoe added a comment.

 I've responded to review comments (thanks for those) and renamed the
 check to 'rule-of-five'.

 I think it needs moving to cppcoreguidelines and needs destructor
 handling adding to it. As suggested, I'll address that in a later patch if
 everything else looks ok.


 http://reviews.llvm.org/D16376

 Files:
   clang-tidy/misc/CMakeLists.txt
   clang-tidy/misc/MiscTidyModule.cpp
   clang-tidy/misc/RuleOfFiveCheck.cpp
   clang-tidy/misc/RuleOfFiveCheck.h
   docs/clang-tidy/checks/list.rst
   docs/clang-tidy/checks/misc-rule-of-five.rst
   test/clang-tidy/misc-rule-of-five.cpp


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


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

Re: [PATCH] D15829: [PGO] Clang Option that enables IR level PGO instrumentation

[Xinliang David Li via cfe-commits]

On Wed, Feb 3, 2016 at 12:40 PM, Bob Wilson  wrote:
>
> On Feb 3, 2016, at 12:23 PM, Xinliang David Li  wrote:
>
> On Tue, Feb 2, 2016 at 1:31 PM, Bob Wilson  wrote:
>
>
> On Jan 22, 2016, at 1:43 PM, Sean Silva via cfe-commits
>  wrote:
>
> silvas added a comment.
>
> In http://reviews.llvm.org/D15829#333902, @davidxl wrote:
>
> For the longer term, one possible solution is to make FE based
> instrumentation only used for coverage testing which can be turned on
> with -fcoverage-mapping option (currently, -fcoverage-mapping can not
> be used alone and must be used together with
> -fprofile-instr-generate). To summarize:
>
> A. Current behavior:
>
> ---
>
> 1. -fprofile-instr-generate turns on FE based instrumentation
> 2. -fprofile-instr-generate -fcoverage-mapping turns on FE based
> instrumentation and coverage mapping data generation.
> 3. -fprofile-instr-use=<..> assumes profile data from FE instrumentation.
>
> B. Proposed new behavior:
>
> 
>
> 1. -fprofile-instr-generate turns on IR late instrumentation
> 2. -fcoverage-mapping turns on FE instrumentation and coverage-mapping
> 3. -fprofile-instr-generate -fcoverage-mapping result in compiler warning
> 4. -fprofile-instr-use=<> will automatically determine how to use the
> profile data.
>
>
>
> Very good observation that we can determine FE or IR automatically based on
> the input profdata. That simplifies things.
>
> B.2) above can be done today for improved usability.
>
>
>
> I don't see how this improves usability. In fact, it is confusing because it
> hijacks an existing option.
>
>
> Hijacking an existing option to do something different would definitely be a
> problem. Please find a way to specify IR-level instrumentation without
> breaking compatibility. If you want to replace the existing options with
> something different, we’ll need a transition period of at least 1-2 LLVM
> releases to migrate.
>
>
> If we remove B.3 above,  then the proposed change (B.2) is essentially
> making '-fcoverage-mapping' an alias to '-fprofile-instr-generate
> -fcoverage-mapping'.   No existing workflow will be broken and new
> users can take advantage of the shortened option.  The reason is that
> there will be no users that only use -fcoverage-mapping option alone
> and rely on its behavior (which is clang error).
>
>
> The part I’m concerned about is B.1. The current behavior is that
> -fprofile-instr-generate enabled FE instrumentation. We can’t hijack that to
> do something different, at least without a sufficiently long transition
> period for clients to adapt. We use that to generate PGO profiles even when
> not using -fcoverage-mapping.

yes. I don't see this happening overnight. IR based instrumentation
also needs to get stablized and widely used before the switch can
happen.

>>
> Yes, that is a requirement for us. We need existing profdata to work with
> newer versions of clang (which is why IR-level instrumentation doesn’t work
> for us).
>
>
> profile-use can automatically detect FE based profile data and use it
> properly. The question is whether we have a need to support merging
> profiles from IR and FE instrumentation.
>
>
> I don’t think it makes sense to merge those. They seem like fundamentally
> different kinds of data. The “forward compatibility” requirement is about
> different versions of the FE-based profile data.


great -- one fewer thing to worry about.

>

>
> I want to understand how we can guarantee to support old (FE based)
> profiles with new compilers.  The region to counter id
> mapping/assignment depends on how the AST is generated by the frontend
> and how the AST is traversed. Do we have any guarantee that the new
> compiler can generate them in the same order? How is that enforced?
> The function structural hash generated may also be different (given
> the same source).
>
>
> The FE-based instrumentation uses a custom traversal of the ASTs so that we
> can control the order and make sure it doesn’t change. It still depends on
> the way the ASTs are generated but the AST nodes that are relevant for this
> are unlikely to change in ways that would affect the instrumentation. I
> would love to have a better way to enforce that.

My guess is that IR based instrumentation (which is CFG based) can
produce as stable profile as what FE based instrumentation (when it is
used in a conservative mode that does not require pre-inlining).  CFG
based checksum is also used to detect incompatible changes such that
old profile data can be kept live for a long time (while
gradually/slowly degrades in quality due to the increased number of
mismatches).To get really stable profile, we need to used a source
location based representation (which sample based PGO uses).In
other words, I don't see a big obstacle that prevent IR based
instrumentation from being usable  in such a workflow.

>
> The 

r259716 - [cfi] Safe handling of unaddressable vtable pointers (clang).

[Evgeniy Stepanov via cfe-commits]

Author: eugenis
Date: Wed Feb  3 16:18:55 2016
New Revision: 259716

URL: http://llvm.org/viewvc/llvm-project?rev=259716=rev
Log:
[cfi] Safe handling of unaddressable vtable pointers (clang).

Avoid crashing when printing diagnostics for vtable-related CFI
errors. In diagnostic mode, the frontend does an additional check of
the vtable pointer against the set of all known vtable addresses and
lets the runtime handler know if it is safe to inspect the vtable.

http://reviews.llvm.org/D16823

Modified:
cfe/trunk/lib/CodeGen/CGClass.cpp
cfe/trunk/lib/CodeGen/CGExpr.cpp
cfe/trunk/lib/CodeGen/CodeGenModule.cpp
cfe/trunk/lib/CodeGen/CodeGenModule.h
cfe/trunk/test/CodeGen/cfi-check-fail.c
cfe/trunk/test/CodeGenCXX/cfi-cast.cpp
cfe/trunk/test/CodeGenCXX/cfi-vcall.cpp

Modified: cfe/trunk/lib/CodeGen/CGClass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGClass.cpp?rev=259716=259715=259716=diff
==
--- cfe/trunk/lib/CodeGen/CGClass.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGClass.cpp Wed Feb  3 16:18:55 2016
@@ -2607,10 +2607,22 @@ void CodeGenFunction::EmitVTablePtrCheck
   auto TypeId = CGM.CreateCfiIdForTypeMetadata(MD);
   if (CGM.getCodeGenOpts().SanitizeCfiCrossDso && TypeId) {
 EmitCfiSlowPathCheck(M, BitSetTest, TypeId, CastedVTable, StaticData);
-  } else {
-EmitCheck(std::make_pair(BitSetTest, M), "cfi_check_fail", StaticData,
-  CastedVTable);
+return;
   }
+
+  if (CGM.getCodeGenOpts().SanitizeTrap.has(M)) {
+EmitTrapCheck(BitSetTest);
+return;
+  }
+
+  llvm::Value *AllVtables = llvm::MetadataAsValue::get(
+  CGM.getLLVMContext(),
+  llvm::MDString::get(CGM.getLLVMContext(), "all-vtables"));
+  llvm::Value *ValidVtable =
+  Builder.CreateCall(CGM.getIntrinsic(llvm::Intrinsic::bitset_test),
+ {CastedVTable, AllVtables});
+  EmitCheck(std::make_pair(BitSetTest, M), "cfi_check_fail", StaticData,
+{CastedVTable, ValidVtable});
 }
 
 // FIXME: Ideally Expr::IgnoreParenNoopCasts should do this, but it doesn't do

Modified: cfe/trunk/lib/CodeGen/CGExpr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGExpr.cpp?rev=259716=259715=259716=diff
==
--- cfe/trunk/lib/CodeGen/CGExpr.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGExpr.cpp Wed Feb  3 16:18:55 2016
@@ -2636,6 +2636,14 @@ void CodeGenFunction::EmitCfiCheckFail()
   Address CheckKindAddr(V, getIntAlign());
   llvm::Value *CheckKind = Builder.CreateLoad(CheckKindAddr);
 
+  llvm::Value *AllVtables = llvm::MetadataAsValue::get(
+  CGM.getLLVMContext(),
+  llvm::MDString::get(CGM.getLLVMContext(), "all-vtables"));
+  llvm::Value *ValidVtable = Builder.CreateZExt(
+  Builder.CreateCall(CGM.getIntrinsic(llvm::Intrinsic::bitset_test),
+ {Addr, AllVtables}),
+  IntPtrTy);
+
   const std::pair CheckKinds[] = {
   {CFITCK_VCall, SanitizerKind::CFIVCall},
   {CFITCK_NVCall, SanitizerKind::CFINVCall},
@@ -2649,7 +2657,8 @@ void CodeGenFunction::EmitCfiCheckFail()
 SanitizerMask Mask = CheckKindMaskPair.second;
 llvm::Value *Cond =
 Builder.CreateICmpNE(CheckKind, llvm::ConstantInt::get(Int8Ty, Kind));
-EmitCheck(std::make_pair(Cond, Mask), "cfi_check_fail", {}, {Data, Addr});
+EmitCheck(std::make_pair(Cond, Mask), "cfi_check_fail", {},
+  {Data, Addr, ValidVtable});
   }
 
   FinishFunction();
@@ -3970,7 +3979,8 @@ RValue CodeGenFunction::EmitCall(QualTyp
CastedCallee, StaticData);
 } else {
   EmitCheck(std::make_pair(BitSetTest, SanitizerKind::CFIICall),
-"cfi_check_fail", StaticData, CastedCallee);
+"cfi_check_fail", StaticData,
+{CastedCallee, llvm::UndefValue::get(IntPtrTy)});
 }
   }
 

Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp?rev=259716=259715=259716=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Wed Feb  3 16:18:55 2016
@@ -4021,6 +4021,20 @@ llvm::Metadata *CodeGenModule::CreateMet
   return InternalId;
 }
 
+/// Returns whether this module needs the "all-vtables" bitset.
+bool CodeGenModule::NeedAllVtablesBitSet() const {
+  // Returns true if at least one of vtable-based CFI checkers is enabled and
+  // is not in the trapping mode.
+  return ((LangOpts.Sanitize.has(SanitizerKind::CFIVCall) &&
+   !CodeGenOpts.SanitizeTrap.has(SanitizerKind::CFIVCall)) ||
+  (LangOpts.Sanitize.has(SanitizerKind::CFINVCall) &&
+   !CodeGenOpts.SanitizeTrap.has(SanitizerKind::CFINVCall)) ||
+  

Re: [PATCH] D15829: [PGO] Clang Option that enables IR level PGO instrumentation

[Xinliang David Li via cfe-commits]

On Tue, Feb 2, 2016 at 1:31 PM, Bob Wilson  wrote:
>
>> On Jan 22, 2016, at 1:43 PM, Sean Silva via cfe-commits 
>>  wrote:
>>
>> silvas added a comment.
>>
>> In http://reviews.llvm.org/D15829#333902, @davidxl wrote:
>>
>>> For the longer term, one possible solution is to make FE based
>>> instrumentation only used for coverage testing which can be turned on
>>> with -fcoverage-mapping option (currently, -fcoverage-mapping can not
>>> be used alone and must be used together with
>>> -fprofile-instr-generate). To summarize:
>>>
>>> A. Current behavior:
>>>
>>> ---
>>>
>>> 1. -fprofile-instr-generate turns on FE based instrumentation
>>> 2. -fprofile-instr-generate -fcoverage-mapping turns on FE based 
>>> instrumentation and coverage mapping data generation.
>>> 3. -fprofile-instr-use=<..> assumes profile data from FE instrumentation.
>>>
>>> B. Proposed new behavior:
>>>
>>> 
>>>
>>> 1. -fprofile-instr-generate turns on IR late instrumentation
>>> 2. -fcoverage-mapping turns on FE instrumentation and coverage-mapping
>>> 3. -fprofile-instr-generate -fcoverage-mapping result in compiler warning
>>> 4. -fprofile-instr-use=<> will automatically determine how to use the 
>>> profile data.
>>
>>
>> Very good observation that we can determine FE or IR automatically based on 
>> the input profdata. That simplifies things.
>>
>>> B.2) above can be done today for improved usability.
>>
>>
>> I don't see how this improves usability. In fact, it is confusing because it 
>> hijacks an existing option.
>
> Hijacking an existing option to do something different would definitely be a 
> problem. Please find a way to specify IR-level instrumentation without 
> breaking compatibility. If you want to replace the existing options with 
> something different, we’ll need a transition period of at least 1-2 LLVM 
> releases to migrate.
>

If we remove B.3 above,  then the proposed change (B.2) is essentially
making '-fcoverage-mapping' an alias to '-fprofile-instr-generate
-fcoverage-mapping'.   No existing workflow will be broken and new
users can take advantage of the shortened option.  The reason is that
there will be no users that only use -fcoverage-mapping option alone
and rely on its behavior (which is clang error).


>>
>> Also B.3 causes existing user builds to emit a warning, which is annoying.
>>
>> I would propose the following modification of B:
>>
>> C.:
>>
>> 1. -fprofile-instr-generate defaults to IR instrumentation (i.e. behaves 
>> exactly as before, except that it uses IR instrumentation)
>> 2. -fprofile-instr-generate -fcoverage-mapping turns on frontend 
>> instrumentation and coverage. (i.e. behaves exactly as before)
>> 3. -fprofile-instr-use=<> automatically determines which method to use
>>
>> All existing user workflows continue to work, except for workflows that 
>> attempt to `llvm-profdata merge` some old frontend profile data (e.g. they 
>> have checked-in to version control and represents some special workload) 
>> with the profile data from new binaries.
>
> The coverage mapping adds considerable cost. IR-level instrumentation has 
> some problems that make it undesirable for our workflow, so we need a way to 
> select front-end instrumentation without adding a bunch of unnecessary 
> overhead (generating the coverage mapping when you’re not actually doing 
> coverage testing). I disagree with your assessment that existing workflows 
> would continue to “work” because ours would not.
>
>>
>> Concretely, imagine the following workflow:
>>
>>  clang -fprofile-instr-generate foo.c -o foo
>>  ./foo
>>  llvm-profdata merge default.profraw -o new.profdata
>>  llvm-profdata merge new.profdata 
>> /versioncontrol/some-important-but-expensive-to-reproduce-workload.profdata 
>> -o foo.profdata
>>  clang -fprofile-instr-use=foo.profdata foo.c -o foo_pgo
>>
>> I think this is a reasonable breakage. We would need to add a note in the 
>> release notes. Unfortunately this is not expected breakage if we claim to 
>> have forward compatibility for profdata (which IIRC Apple requires; 
>> @bogner?).
>
> Yes, that is a requirement for us. We need existing profdata to work with 
> newer versions of clang (which is why IR-level instrumentation doesn’t work 
> for us).
>

profile-use can automatically detect FE based profile data and use it
properly. The question is whether we have a need to support merging
profiles from IR and FE instrumentation.



>> But I think this case will be rare and exceptional enough that we can 
>> tolerate it:
>>
>> - a simple immediate workaround is to specify `-fcoverage-mapping` (which 
>> also adds some extra stuff, but works around the issue)
>> - Presumably 
>> /versioncontrol/some-important-but-expensive-to-reproduce-workload.profdata 
>> is regenerated with some frequency which is more frequent than upgrading the 
>> compiler, and so it is likely reasonable to regenerate it 

Re: [PATCH] D16784: [OpenMP] Reorganize code to allow specialized code generation for different devices.

[Samuel Antao via cfe-commits]

sfantao added a comment.

Hi Alexey,

Thanks again for the review!



Comment at: lib/CodeGen/CGOpenMPRuntimeCommon.h:1
@@ +1,2 @@
+//=== CGOpenMPRuntimeCommon.h - Helpers for OpenMP Runtimes Codegen 
==//
+//

ABataev wrote:
> I don't think we need this new file and new namespace. If some (currently) 
> internal classes are needed, they must be exposed via CGOpenMPRuntime class. 
> Derived class will be able to use these classes.
> Also, do not expose classes if they are not required right now.
Alright. I will add what is required as protected members of CGOpenMPRuntime. 
For now I didn't do that for any of the classes given that we are not doing any 
actual codegen.


Comment at: lib/CodeGen/CGOpenMPRuntimeCommon.h:267-268
@@ +266,4 @@
+
+LValue emitLoadOfPointerLValue(CodeGenFunction , Address PtrAddr,
+  QualType Ty);
+

ABataev wrote:
> I think it is better to make this function a member of CodeGenFunction.
Ok, once we start moving things to `CGOpenMPRntime` runtime, we add this to 
CodeGenFunction accordingly.


Comment at: lib/CodeGen/CGOpenMPRuntimeCommon.h:270-279
@@ +269,12 @@
+
+/// \brief Emits code for OpenMP 'if' clause using specified \a CodeGen
+/// function. Here is the logic:
+/// if (Cond) {
+///   ThenGen();
+/// } else {
+///   ElseGen();
+/// }
+void emitOMPIfClause(CodeGenFunction , const Expr *Cond,
+const RegionCodeGenTy ,
+const RegionCodeGenTy );
+

ABataev wrote:
> If you need this one, make it a virtual member of CGOpenMPRuntime
Ok. I'll do  that once we post the codegen patches.


Comment at: lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp:24
@@ +23,3 @@
+  explicit CGOpenMPRuntimeNVPTX(CodeGenModule ) : CGOpenMPRuntime(CGM) {
+if (!CGM.getLangOpts().OpenMPIsDevice)
+  llvm_unreachable("OpenMP NVPTX is only prepared to deal with device 
code.");

ABataev wrote:
> I think it must be checked during creation of NVPTX specific OpenMPRuntime 
> instance.
Ok, I did that. Also I added a new diagnostic in the compiler invocation so 
that the user gets a message instead of a stack dump. Let me know if you agree.


http://reviews.llvm.org/D16784



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

r259687 - Refactor conversion of deduced template arguments to reduce repetition.

[Richard Smith via cfe-commits]

Author: rsmith
Date: Wed Feb  3 14:15:01 2016
New Revision: 259687

URL: http://llvm.org/viewvc/llvm-project?rev=259687=rev
Log:
Refactor conversion of deduced template arguments to reduce repetition.

Modified:
cfe/trunk/lib/Sema/SemaTemplateDeduction.cpp

Modified: cfe/trunk/lib/Sema/SemaTemplateDeduction.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaTemplateDeduction.cpp?rev=259687=259686=259687=diff
==
--- cfe/trunk/lib/Sema/SemaTemplateDeduction.cpp (original)
+++ cfe/trunk/lib/Sema/SemaTemplateDeduction.cpp Wed Feb  3 14:15:01 2016
@@ -2060,11 +2060,46 @@ static bool
 ConvertDeducedTemplateArgument(Sema , NamedDecl *Param,
DeducedTemplateArgument Arg,
NamedDecl *Template,
-   QualType NTTPType,
-   unsigned ArgumentPackIndex,
TemplateDeductionInfo ,
bool InFunctionTemplate,
SmallVectorImpl ) {
+  // First, for a non-type template parameter type that is
+  // initialized by a declaration, we need the type of the
+  // corresponding non-type template parameter.
+  QualType NTTPType;
+  if (NonTypeTemplateParmDecl *NTTP =
+  dyn_cast(Param)) {
+NTTPType = NTTP->getType();
+if (NTTPType->isDependentType()) {
+  TemplateArgumentList TemplateArgs(TemplateArgumentList::OnStack,
+Output.data(), Output.size());
+  NTTPType = S.SubstType(NTTPType,
+ MultiLevelTemplateArgumentList(TemplateArgs),
+ NTTP->getLocation(),
+ NTTP->getDeclName());
+  if (NTTPType.isNull())
+return true;
+}
+  }
+
+  auto ConvertArg = [&](DeducedTemplateArgument Arg,
+unsigned ArgumentPackIndex) {
+// Convert the deduced template argument into a template
+// argument that we can check, almost as if the user had written
+// the template argument explicitly.
+TemplateArgumentLoc ArgLoc =
+getTrivialTemplateArgumentLoc(S, Arg, NTTPType, Info.getLocation());
+
+// Check the template argument, converting it as necessary.
+return S.CheckTemplateArgument(
+Param, ArgLoc, Template, Template->getLocation(),
+Template->getSourceRange().getEnd(), ArgumentPackIndex, Output,
+InFunctionTemplate
+? (Arg.wasDeducedFromArrayBound() ? 
Sema::CTAK_DeducedFromArrayBound
+  : Sema::CTAK_Deduced)
+: Sema::CTAK_Specified);
+  };
+
   if (Arg.getKind() == TemplateArgument::Pack) {
 // This is a template argument pack, so check each of its arguments against
 // the template parameter.
@@ -2075,39 +2110,25 @@ ConvertDeducedTemplateArgument(Sema ,
   // checking logic has all of the prior template arguments available.
   DeducedTemplateArgument InnerArg(P);
   InnerArg.setDeducedFromArrayBound(Arg.wasDeducedFromArrayBound());
-  if (ConvertDeducedTemplateArgument(S, Param, InnerArg, Template,
- NTTPType, PackedArgsBuilder.size(),
- Info, InFunctionTemplate, Output))
+  assert(InnerArg.getKind() != TemplateArgument::Pack &&
+ "deduced nested pack");
+  if (ConvertArg(InnerArg, PackedArgsBuilder.size()))
 return true;
 
   // Move the converted template argument into our argument pack.
   PackedArgsBuilder.push_back(Output.pop_back_val());
 }
 
+// FIXME: If the pack is empty and this is a template template parameter,
+// we still need to substitute into the parameter itself.
+
 // Create the resulting argument pack.
 Output.push_back(
 TemplateArgument::CreatePackCopy(S.Context, PackedArgsBuilder));
 return false;
   }
 
-  // Convert the deduced template argument into a template
-  // argument that we can check, almost as if the user had written
-  // the template argument explicitly.
-  TemplateArgumentLoc ArgLoc = getTrivialTemplateArgumentLoc(S, Arg, NTTPType,
- 
Info.getLocation());
-
-  // Check the template argument, converting it as necessary.
-  return S.CheckTemplateArgument(Param, ArgLoc,
- Template,
- Template->getLocation(),
- Template->getSourceRange().getEnd(),
- ArgumentPackIndex,
- Output,
- InFunctionTemplate
-  ? (Arg.wasDeducedFromArrayBound()
-   ? Sema::CTAK_DeducedFromArrayBound
-   : 

Re: [PATCH] D16638: [CUDA] Added device-side system call decls and related wrappers.

[Artem Belevich via cfe-commits]

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

Updated comment.


http://reviews.llvm.org/D16638

Files:
  lib/Headers/__clang_cuda_runtime_wrapper.h

Index: lib/Headers/__clang_cuda_runtime_wrapper.h
===
--- lib/Headers/__clang_cuda_runtime_wrapper.h
+++ lib/Headers/__clang_cuda_runtime_wrapper.h
@@ -80,17 +80,15 @@
 // definitions from .hpp files.
 #define __DEVICE_FUNCTIONS_H__
 #define __MATH_FUNCTIONS_H__
+#define __COMMON_FUNCTIONS_H__
 
 #undef __CUDACC__
 #define __CUDABE__
 // Disables definitions of device-side runtime support stubs in
 // cuda_device_runtime_api.h
-#define __CUDADEVRT_INTERNAL__
 #include "host_config.h"
 #include "host_defines.h"
 #include "driver_types.h"
-#include "common_functions.h"
-#undef __CUDADEVRT_INTERNAL__
 
 #undef __CUDABE__
 #define __CUDACC__
@@ -211,13 +209,42 @@
 static __device__ __attribute__((used)) int __nvvm_reflect_anchor() {
   return __nvvm_reflect("NONE");
 }
-
-// The nvptx vprintf syscall.  This doesn't actually need to be declared, but 
we
-// declare it so that if someone else declares it with a different signature,
-// we'll throw an error.
-extern "C" __device__ int vprintf(const char*, const char*);
 #endif
 
+extern "C" {
+// Device-side CUDA system calls.
+// 
http://docs.nvidia.com/cuda/ptx-writers-guide-to-interoperability/index.html#system-calls
+// We need these declarations and wrappers for device-side
+// malloc/free/printf calls to work without relying on
+// -fcuda-disable-target-call-checks option.
+__device__ int vprintf(const char*, const char*);
+__device__ void free(void *) __attribute((nothrow));
+__device__ void *malloc(size_t) __attribute((nothrow)) __attribute__((malloc));
+__device__ void __assertfail(const char *message, const char *file,
+ unsigned line, const char *function,
+ size_t charSize) __attribute__((noreturn));
+
+// In order for standard assert() macro on linux to work we need to
+// provide device-side __assert_fail()
+__device__ static inline void __assert_fail(const char *message,
+const char *file, unsigned line,
+const char *function) {
+  __assertfail(message, file, line, function, sizeof(char));
+}
+
+// Clang will convert printf into vprintf, but we still need
+// device-side declaration for it.
+__device__ int printf(const char *, ...);
+} // extern "C"
+
+// We also need device-side std::malloc and std::free.
+namespace std {
+__device__ static inline void free(void *__ptr) { ::free(__ptr); }
+__device__ static inline void *malloc(size_t __size) {
+  return ::malloc(__size);
+}
+} // namespace std
+
 #include <__clang_cuda_cmath.h>
 
 #endif // __CUDA__


Index: lib/Headers/__clang_cuda_runtime_wrapper.h
===
--- lib/Headers/__clang_cuda_runtime_wrapper.h
+++ lib/Headers/__clang_cuda_runtime_wrapper.h
@@ -80,17 +80,15 @@
 // definitions from .hpp files.
 #define __DEVICE_FUNCTIONS_H__
 #define __MATH_FUNCTIONS_H__
+#define __COMMON_FUNCTIONS_H__
 
 #undef __CUDACC__
 #define __CUDABE__
 // Disables definitions of device-side runtime support stubs in
 // cuda_device_runtime_api.h
-#define __CUDADEVRT_INTERNAL__
 #include "host_config.h"
 #include "host_defines.h"
 #include "driver_types.h"
-#include "common_functions.h"
-#undef __CUDADEVRT_INTERNAL__
 
 #undef __CUDABE__
 #define __CUDACC__
@@ -211,13 +209,42 @@
 static __device__ __attribute__((used)) int __nvvm_reflect_anchor() {
   return __nvvm_reflect("NONE");
 }
-
-// The nvptx vprintf syscall.  This doesn't actually need to be declared, but we
-// declare it so that if someone else declares it with a different signature,
-// we'll throw an error.
-extern "C" __device__ int vprintf(const char*, const char*);
 #endif
 
+extern "C" {
+// Device-side CUDA system calls.
+// http://docs.nvidia.com/cuda/ptx-writers-guide-to-interoperability/index.html#system-calls
+// We need these declarations and wrappers for device-side
+// malloc/free/printf calls to work without relying on
+// -fcuda-disable-target-call-checks option.
+__device__ int vprintf(const char*, const char*);
+__device__ void free(void *) __attribute((nothrow));
+__device__ void *malloc(size_t) __attribute((nothrow)) __attribute__((malloc));
+__device__ void __assertfail(const char *message, const char *file,
+ unsigned line, const char *function,
+ size_t charSize) __attribute__((noreturn));
+
+// In order for standard assert() macro on linux to work we need to
+// provide device-side __assert_fail()
+__device__ static inline void __assert_fail(const char *message,
+const char *file, unsigned line,
+const char *function) {
+  __assertfail(message, file, line, 

Re: [PATCH] D13893: Roll-back r250822.

[Angel Garcia via cfe-commits]

angelgarcia added a subscriber: angelgarcia.
angelgarcia added a comment.

The compiler complained about creating constant instances of classes
without a user provided constructor (which is the case for the ASTMatchers).

I gave up this change because it broke the build for a huge amount of
people and I didn't want that to happen again.


Repository:
  rL LLVM

http://reviews.llvm.org/D13893



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

Re: [PATCH] D16376: clang-tidy check: rule-of-five

[David Blaikie via cfe-commits]

On Wed, Feb 3, 2016 at 1:40 PM, Aaron Ballman 
wrote:

> On Wed, Feb 3, 2016 at 4:13 PM, David Blaikie  wrote:
> >
> >
> > On Wed, Feb 3, 2016 at 1:03 PM, Jonathan Coe  wrote:
> >>
> >>
> >>
> >> On 3 February 2016 at 18:44, David Blaikie  wrote:
> >>>
> >>>
> >>>
> >>> On Wed, Feb 3, 2016 at 10:23 AM, Jonathan Coe  wrote:
> 
>  All the C++ compilers I have tried using (GCC,Clang,MSVC) will
> generate
>  assignment operators even if the user defines a copy-constructor.
> This is
>  the behaviour I set out to write a check for.
> 
>  The cpp core guide lines recommend defining all or none of the special
>  functions
> 
> https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#c21-if-you-define-or-delete-any-default-operation-define-or-delete-them-all
> 
>  If the deprecation warning you mention will turn off the deprecated
>  generation of special member functions when others are defined (or
> warn when
>  deprecated compiler-generated functions are used) then the
> rule-of-five
>  check is of reduced value.
> >>>
> >>>
> >>> It can't stop them being generated, because that's required behavior -
> >>> warnings don't change the program behavior.
> >>>
> >>
> >> That's true but promoting them to errors will stop compilation and
> prevent
> >> the sort of bug I'm trying to stop.
> >
> >
> > Sure - and the user can do that with -Werror=deprecated (but, yes, we
> should
> > split out that specific deprecation so it can be turned on without
> turning
> > on other deprecation)
> >
> >>
> >>
> >>>
> >>> Wording like this is in the C++11 standard:
> >>>
> >>> "If the class definition does not explicitly declare a copy
> constructor,
> >>> one is declared implicitly. If the class definition declares a move
> >>> constructor or move assignment operator, the implicitly declared copy
> >>> constructor is defined as deleted; otherwise, it is defined as
> defaulted
> >>> (8.4). The latter case is deprecated if the class has a user-declared
> copy
> >>> assignment operator or a user-declared destructor."
> >>>
> >>
> >> The 'deprecated' part is my target. I've seen code with user-defined
> copy
> >> constructors behave badly when compiler-generated assignment operators
> are
> >> unwittingly used.
> >
> >
> > For sure - because it's only deprecated, not an error. Clang-tidy won't
> > change that - it still won't be a hard error in every codebase.
> >
> > I agree that having all the Core Guidelines checks in one place is a good
> > idea, so I'm not making any real suggestion here, sorry - just that it
> seems
> > unfortunate to relegate this check (& encourage explicit & mostly
> redundant
> > defaulting/deleting) to a separate tool when it's essentially built into
> the
> > language and compiler already. My disagreement is perhaps more with the
> Core
> > Guideline than with its implementation here.
> >
> >>
> >> The rule of five lets me locally reason about code without having to
> worry
> >> (needlessly or not) about whether some functions are potentially being
> >> compiler-generated.
> >
> >
> > But once the language does the right thing directly, rather than
> providing a
> > clang-tidy warning that encourages you to change the code to achieve the
> > same result, why would we worry about being explicit?
>
> It could be argued that implicit code generated by the compiler is
> magic, and being explicit is a readability improvement. You no longer
> have to think "under what circumstances is this generated?"


Except this rule doesn't argue that - if all the members are implicit that
is acceptable to this rule (even if the implicit special members are
entirely non-trivial because one of the member variables has non-trivial
special members). The issue is about implicit code when at least one of
them is explicit.

Except that doesn't happen in C++11 (except in the two deprecated cases) -
there is no implicit code to be worried about except for historic (and
deprecated - I agree, we could do better there*) reasons. New C++
programmers won't need to be taught the rule of 5 - the language will just
DTRT. I'm not sure it's necessarily an improvement to create coding
conventions for that sort of historic reason.

* but 'better' might just be separating out that deprecation warning and
enabling it as a clang-tidy warning in the core guidelines group

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

Re: [PATCH] D16638: [CUDA] Added device-side system call decls and related wrappers.

[Justin Lebar via cfe-commits]

jlebar added a comment.

lgtm.  Thank you.


http://reviews.llvm.org/D16638



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

Re: [PATCH] D13893: Roll-back r250822.

[Ángel García Gómez via cfe-commits]

The compiler complained about creating constant instances of classes
without a user provided constructor (which is the case for the ASTMatchers).

I gave up this change because it broke the build for a huge amount of
people and I didn't want that to happen again.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D15636: Reduce false positives in printf/scanf format checker

[Andy Gibbs via cfe-commits]

AndyG added a comment.

Thoughts?  Am I good to go?

Cheers,
Andy


http://reviews.llvm.org/D15636



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

Re: [PATCH] D16692: [OpenCL] Eliminate warning when declaring OpenCL builtin functions

[Yaxun Liu via cfe-commits]

yaxunl closed this revision.
yaxunl added a comment.

committed


http://reviews.llvm.org/D16692



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

Re: [PATCH] D15829: [PGO] Clang Option that enables IR level PGO instrumentation

[Bob Wilson via cfe-commits]

> On Feb 3, 2016, at 12:23 PM, Xinliang David Li  wrote:
> 
> On Tue, Feb 2, 2016 at 1:31 PM, Bob Wilson  > wrote:
>> 
>>> On Jan 22, 2016, at 1:43 PM, Sean Silva via cfe-commits 
>>>  wrote:
>>> 
>>> silvas added a comment.
>>> 
>>> In http://reviews.llvm.org/D15829#333902, @davidxl wrote:
>>> 
 For the longer term, one possible solution is to make FE based
 instrumentation only used for coverage testing which can be turned on
 with -fcoverage-mapping option (currently, -fcoverage-mapping can not
 be used alone and must be used together with
 -fprofile-instr-generate). To summarize:
 
 A. Current behavior:
 
 ---
 
 1. -fprofile-instr-generate turns on FE based instrumentation
 2. -fprofile-instr-generate -fcoverage-mapping turns on FE based 
 instrumentation and coverage mapping data generation.
 3. -fprofile-instr-use=<..> assumes profile data from FE instrumentation.
 
 B. Proposed new behavior:
 
 
 
 1. -fprofile-instr-generate turns on IR late instrumentation
 2. -fcoverage-mapping turns on FE instrumentation and coverage-mapping
 3. -fprofile-instr-generate -fcoverage-mapping result in compiler warning
 4. -fprofile-instr-use=<> will automatically determine how to use the 
 profile data.
>>> 
>>> 
>>> Very good observation that we can determine FE or IR automatically based on 
>>> the input profdata. That simplifies things.
>>> 
 B.2) above can be done today for improved usability.
>>> 
>>> 
>>> I don't see how this improves usability. In fact, it is confusing because 
>>> it hijacks an existing option.
>> 
>> Hijacking an existing option to do something different would definitely be a 
>> problem. Please find a way to specify IR-level instrumentation without 
>> breaking compatibility. If you want to replace the existing options with 
>> something different, we’ll need a transition period of at least 1-2 LLVM 
>> releases to migrate.
>> 
> 
> If we remove B.3 above,  then the proposed change (B.2) is essentially
> making '-fcoverage-mapping' an alias to '-fprofile-instr-generate
> -fcoverage-mapping'.   No existing workflow will be broken and new
> users can take advantage of the shortened option.  The reason is that
> there will be no users that only use -fcoverage-mapping option alone
> and rely on its behavior (which is clang error).

The part I’m concerned about is B.1. The current behavior is that 
-fprofile-instr-generate enabled FE instrumentation. We can’t hijack that to do 
something different, at least without a sufficiently long transition period for 
clients to adapt. We use that to generate PGO profiles even when not using 
-fcoverage-mapping.

> 
> 
>>> 
>>> Also B.3 causes existing user builds to emit a warning, which is annoying.
>>> 
>>> I would propose the following modification of B:
>>> 
>>> C.:
>>> 
>>> 1. -fprofile-instr-generate defaults to IR instrumentation (i.e. behaves 
>>> exactly as before, except that it uses IR instrumentation)
>>> 2. -fprofile-instr-generate -fcoverage-mapping turns on frontend 
>>> instrumentation and coverage. (i.e. behaves exactly as before)
>>> 3. -fprofile-instr-use=<> automatically determines which method to use
>>> 
>>> All existing user workflows continue to work, except for workflows that 
>>> attempt to `llvm-profdata merge` some old frontend profile data (e.g. they 
>>> have checked-in to version control and represents some special workload) 
>>> with the profile data from new binaries.
>> 
>> The coverage mapping adds considerable cost. IR-level instrumentation has 
>> some problems that make it undesirable for our workflow, so we need a way to 
>> select front-end instrumentation without adding a bunch of unnecessary 
>> overhead (generating the coverage mapping when you’re not actually doing 
>> coverage testing). I disagree with your assessment that existing workflows 
>> would continue to “work” because ours would not.
>> 
>>> 
>>> Concretely, imagine the following workflow:
>>> 
>>> clang -fprofile-instr-generate foo.c -o foo
>>> ./foo
>>> llvm-profdata merge default.profraw -o new.profdata
>>> llvm-profdata merge new.profdata 
>>> /versioncontrol/some-important-but-expensive-to-reproduce-workload.profdata 
>>> -o foo.profdata
>>> clang -fprofile-instr-use=foo.profdata foo.c -o foo_pgo
>>> 
>>> I think this is a reasonable breakage. We would need to add a note in the 
>>> release notes. Unfortunately this is not expected breakage if we claim to 
>>> have forward compatibility for profdata (which IIRC Apple requires; 
>>> @bogner?).
>> 
>> Yes, that is a requirement for us. We need existing profdata to work with 
>> newer versions of clang (which is why IR-level instrumentation doesn’t work 
>> for us).
>> 
> 
> profile-use can automatically detect FE based profile data and use it
> 

r259688 - Ensure that we substitute into the declaration of a template parameter pack

[Richard Smith via cfe-commits]

Author: rsmith
Date: Wed Feb  3 14:40:30 2016
New Revision: 259688

URL: http://llvm.org/viewvc/llvm-project?rev=259688=rev
Log:
Ensure that we substitute into the declaration of a template parameter pack
(that is not a pack expansion) during template argument deduction, even if we
deduced that the pack would be empty.

Added:
cfe/trunk/test/CXX/temp/temp.fct.spec/temp.deduct/p7.cpp
Modified:
cfe/trunk/lib/Sema/SemaTemplateDeduction.cpp

Modified: cfe/trunk/lib/Sema/SemaTemplateDeduction.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaTemplateDeduction.cpp?rev=259688=259687=259688=diff
==
--- cfe/trunk/lib/Sema/SemaTemplateDeduction.cpp (original)
+++ cfe/trunk/lib/Sema/SemaTemplateDeduction.cpp Wed Feb  3 14:40:30 2016
@@ -2119,8 +2119,25 @@ ConvertDeducedTemplateArgument(Sema ,
   PackedArgsBuilder.push_back(Output.pop_back_val());
 }
 
-// FIXME: If the pack is empty and this is a template template parameter,
-// we still need to substitute into the parameter itself.
+// If the pack is empty, we still need to substitute into the parameter
+// itself, in case that substitution fails. For non-type parameters, we did
+// this above. For type parameters, no substitution is ever required.
+auto *TTP = dyn_cast(Param);
+if (TTP && PackedArgsBuilder.empty()) {
+  // Set up a template instantiation context.
+  LocalInstantiationScope Scope(S);
+  Sema::InstantiatingTemplate Inst(S, Template->getLocation(), Template,
+   TTP, Output,
+   Template->getSourceRange());
+  if (Inst.isInvalid())
+return true;
+
+  TemplateArgumentList TemplateArgs(TemplateArgumentList::OnStack,
+Output.data(), Output.size());
+  if (!S.SubstDecl(TTP, S.CurContext,
+   MultiLevelTemplateArgumentList(TemplateArgs)))
+return true;
+}
 
 // Create the resulting argument pack.
 Output.push_back(
@@ -2808,11 +2825,22 @@ Sema::FinishTemplateArgumentDeduction(Fu
 Builder.push_back(TemplateArgument(
 llvm::makeArrayRef(ExplicitArgs, NumExplicitArgs)));
 
-// Forget the partially-substituted pack; it's substitution is now
+// Forget the partially-substituted pack; its substitution is now
 // complete.
 CurrentInstantiationScope->ResetPartiallySubstitutedPack();
   } else {
-Builder.push_back(TemplateArgument::getEmptyPack());
+// Go through the motions of checking the empty argument pack against
+// the parameter pack.
+DeducedTemplateArgument DeducedPack(TemplateArgument::getEmptyPack());
+if (ConvertDeducedTemplateArgument(*this, Param, DeducedPack,
+   FunctionTemplate, Info, true,
+   Builder)) {
+  Info.Param = makeTemplateParameter(Param);
+  // FIXME: These template arguments are temporary. Free them!
+  Info.reset(TemplateArgumentList::CreateCopy(Context, Builder.data(),
+  Builder.size()));
+  return TDK_SubstitutionFailure;
+}
   }
   continue;
 }

Added: cfe/trunk/test/CXX/temp/temp.fct.spec/temp.deduct/p7.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CXX/temp/temp.fct.spec/temp.deduct/p7.cpp?rev=259688=auto
==
--- cfe/trunk/test/CXX/temp/temp.fct.spec/temp.deduct/p7.cpp (added)
+++ cfe/trunk/test/CXX/temp/temp.fct.spec/temp.deduct/p7.cpp Wed Feb  3 
14:40:30 2016
@@ -0,0 +1,22 @@
+// RUN: %clang_cc1 -std=c++11 -verify %s
+
+struct Q { typedef int type; };
+
+// "The substitution occurs in all types and expressions that are used in [...]
+// template parameter declarations." In particular, we must substitute into the
+// type of a parameter pack that is not a pack expansion, even if we know the
+// corresponding argument pack is empty.
+template void a(T);
+int (...);
+int _disabled = a(0);
+int _enabled = a(Q()); // expected-error {{cannot bind to a temporary of 
type 'void'}}
+
+template class ...X> void b(T);
+int (...);
+int _disabled = b(0);
+int _enabled = b(Q()); // expected-error {{cannot bind to a temporary of 
type 'void'}}
+
+template class ...X> void c(T);
+int (...);
+int _disabled = c(0);
+int _enabled = c(Q()); // expected-error {{cannot bind to a temporary of 
type 'void'}}


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

Re: r258782 - Recommit: R258773 [OpenCL] Pipe builtin functions

[Richard Smith via cfe-commits]

On Wed, Feb 3, 2016 at 11:08 AM, Anastasia Stulova <
anastasia.stul...@arm.com> wrote:

> I think the main reason is that we have committed pipe type before the
> release branch was taken. It appears to have no use without the pipe
> builtin functions.
>
> Are there any risks of adding this now?
>

Based on my post-commit review of the patch, I don't think this is yet
mature enough for 3.8 (in particular, it improperly handles type sugar, and
should be performing argument conversions in SemaChecking rather than in
CGBuiltin). If you're confident that this can be cleaned up in time, and
Hans is prepared to take those cleanup patches onto the branch too, then I
think this is fine to go into 3.8 to finish off the OpenCL pipe work.

Btw, @Richard, I have just updated CODE_OWNERS.TXT putting myself as a code
> owner of OpenCL (approved by Chris Lattner via cfe-dev). I hope you have no
> objections to that.
>

Sounds great, thanks!


> Thanks,
> Anastasia
>
> -Original Message-
> From: meta...@gmail.com [mailto:meta...@gmail.com] On Behalf Of Richard
> Smith
> Sent: 01 February 2016 21:54
> To: Hans Wennborg
> Cc: xiuli pan; cfe-commits; Pekka Jääskeläinen; Anastasia Stulova
> Subject: Re: r258782 - Recommit: R258773 [OpenCL] Pipe builtin functions
>
> On Thu, Jan 28, 2016 at 11:25 AM, Hans Wennborg 
> wrote:
> > I don't think we have a specific code owner for OpenCL in Clang, which
> > means Richard is the owner.
> >
> > Richard, what do you think?
>
> Is there a reason we want to push this new feature into 3.8 rather than
> waiting for the next release?
>
> > On Wed, Jan 27, 2016 at 10:08 PM, xiuli pan 
> wrote:
> >> Hi hans,
> >>
> >> Request to merge it to release 38
> >>
> >> It adds Pipe BIFs to be used along with Pipe type committed earlier (in
> r257254).
> >>
> >> Thanks
> >> Xiuli
> >>
> >> -Original Message-
> >> From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On
> >> Behalf Of Xiuli Pan via cfe-commits
> >> Sent: Tuesday, January 26, 2016 12:04 PM
> >> To: cfe-commits@lists.llvm.org
> >> Subject: r258782 - Recommit: R258773 [OpenCL] Pipe builtin functions
> >>
> >> Author: pxl
> >> Date: Mon Jan 25 22:03:48 2016
> >> New Revision: 258782
> >>
> >> URL: http://llvm.org/viewvc/llvm-project?rev=258782=rev
> >> Log:
> >> Recommit: R258773 [OpenCL] Pipe builtin functions Fix arc patch fuzz
> >> error.
> >> Summary:
> >> Support for the pipe built-in functions for OpenCL 2.0.
> >> The pipe builtin functions may have infinite kinds of element types,
> >> one approach would be to just generate calls that would always use
> generic types such as void*.
> >> This patch is based on bader's opencl support patch on SPIR-V branch.
> >>
> >> Reviewers: Anastasia, pekka.jaaskelainen
> >>
> >> Subscribers: keryell, bader, cfe-commits
> >>
> >> Differential Revision: http://reviews.llvm.org/D15914
> >>
> >> Added:
> >> cfe/trunk/test/CodeGenOpenCL/pipe_builtin.cl
> >> cfe/trunk/test/SemaOpenCL/invalid-pipe-builtin-cl2.0.cl
> >> Modified:
> >> cfe/trunk/include/clang/Basic/Builtins.def
> >> cfe/trunk/include/clang/Basic/Builtins.h
> >> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> >> cfe/trunk/lib/Basic/Builtins.cpp
> >> cfe/trunk/lib/CodeGen/CGBuiltin.cpp
> >> cfe/trunk/lib/Sema/SemaChecking.cpp
> >>
> >> Modified: cfe/trunk/include/clang/Basic/Builtins.def
> >> URL:
> >> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Bui
> >> ltins.def?rev=258782=258781=258782=diff
> >> =
> >> =
> >> --- cfe/trunk/include/clang/Basic/Builtins.def (original)
> >> +++ cfe/trunk/include/clang/Basic/Builtins.def Mon Jan 25 22:03:48
> >> +++ 2016
> >> @@ -1252,6 +1252,32 @@ BUILTIN(__builtin___get_unsafe_stack_ptr
> >>  BUILTIN(__builtin_nontemporal_store, "v.", "t")
> >> BUILTIN(__builtin_nontemporal_load, "v.", "t")
> >>
> >> +// OpenCL v2.0 s6.13.16, s9.17.3.5 - Pipe functions.
> >> +// We need the generic prototype, since the packet type could be
> anything.
> >> +LANGBUILTIN(read_pipe, "i.", "tn", OCLC_LANG)
> >> +LANGBUILTIN(write_pipe, "i.", "tn", OCLC_LANG)
> >> +
> >> +LANGBUILTIN(reserve_read_pipe, "i.", "tn", OCLC_LANG)
> >> +LANGBUILTIN(reserve_write_pipe, "i.", "tn", OCLC_LANG)
> >> +
> >> +LANGBUILTIN(commit_write_pipe, "v.", "tn", OCLC_LANG)
> >> +LANGBUILTIN(commit_read_pipe, "v.", "tn", OCLC_LANG)
> >> +
> >> +LANGBUILTIN(sub_group_reserve_read_pipe, "i.", "tn", OCLC_LANG)
> >> +LANGBUILTIN(sub_group_reserve_write_pipe, "i.", "tn", OCLC_LANG)
> >> +
> >> +LANGBUILTIN(sub_group_commit_read_pipe, "v.", "tn", OCLC_LANG)
> >> +LANGBUILTIN(sub_group_commit_write_pipe, "v.", "tn", OCLC_LANG)
> >> +
> >> +LANGBUILTIN(work_group_reserve_read_pipe, "i.", "tn", OCLC_LANG)
> >> +LANGBUILTIN(work_group_reserve_write_pipe, "i.", "tn", OCLC_LANG)
> >> +
> >> +LANGBUILTIN(work_group_commit_read_pipe, "v.", "tn", OCLC_LANG)
> >> 

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

[Ben Craig via cfe-commits]

bcraig added a comment.

ping


http://reviews.llvm.org/D16545



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

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

[Ben Craig via cfe-commits]

bcraig added a comment.

ping


http://reviews.llvm.org/D16544



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

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

[Gábor Horváth via cfe-commits]

xazax.hun added inline comments.


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

Alexander_Droste wrote:
> Alexander_Droste wrote:
> > xazax.hun wrote:
> > > These are the only cases that can occur? So it is not possible to have a 
> > > loc index? Maybe we could get the value for loc and nonloc ConcreteInts 
> > > and use getVariableName for everzthing else? Would that wok?
> > `getIndex()` returns a `nonloc` and `loc` is in no subclass relation to 
> > `nonloc`.
> > Therefore, `getIndex()` cannot be a `loc` type.
> > 
> > There are actually 5 `nonloc` subclasses but I assumed 
> > that it only makes sense to check for `SymbolVal` and 
> > `ConcreteInt`. 
> > http://clang.llvm.org/doxygen/classclang_1_1ento_1_1NonLoc.html
> > 
> > So would you suggest to only check for `ConcreteInt`
> > and call `getVariableName()` recursively if it isn't one?
> If we want to call `getVariableName` recursively, should we strip the single 
> quotes then?
> Else we would get something like `'x['a']['b']'`. What do you think?
I agree. I think stripping is the way to go.


http://reviews.llvm.org/D16044



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

Re: [PATCH] D16376: clang-tidy check: rule-of-five

[Jonathan B Coe via cfe-commits]

jbcoe planned changes to this revision.
jbcoe added a comment.

If the destructor is user-declared then I need to `=delete` the 
compiler-generated copy constructor and copy assignment  operator (if they are 
not defined, if either is defined then they are already handled by this check).

The move constructor and move assignment operator do not suffer from deprecated 
compiler behaviour so do not need to be explicitly deleted if the destructor is 
user-declared. Perhaps they should be though as this is called 'rule-of-five' 
(for now).

I think that deleting special member functions in the presence of a 
user-defined destructor is the right thing to do even if the user has defined 
the destructor as `=default` otherwise the check will go against the intention 
of the standard.


http://reviews.llvm.org/D16376



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

Re: [PATCH] D16770: [MS] PR26234: Allow typedef redefinition of equally qualified, sized and aligned types in C

[Denis Zobnin via cfe-commits]

d.zobnin.bugzilla updated this revision to Diff 46781.
d.zobnin.bugzilla added a comment.

Thanks for the review!

Updated the patch according to the comments: allowed only integer, enum and 
pointer types which have the same qualifiers, signedness, width and alignment. 
Changed the diagnostic text.

Please take a look.


http://reviews.llvm.org/D16770

Files:
  include/clang/AST/ASTContext.h
  include/clang/Basic/DiagnosticSemaKinds.td
  lib/AST/ASTContext.cpp
  lib/Sema/SemaDecl.cpp
  test/Sema/ms-benign-typedef-redef.c

Index: lib/AST/ASTContext.cpp
===
--- lib/AST/ASTContext.cpp
+++ lib/AST/ASTContext.cpp
@@ -6729,6 +6729,42 @@
   return false;
 }
 
+bool ASTContext::areMSCompatibleTypedefTypesInC(QualType OldType,
+QualType NewType) {
+  assert(getLangOpts().MSVCCompat &&
+ "This routine must be called in Microsoft mode only!");
+  assert(!getLangOpts().CPlusPlus && !getLangOpts().ObjC1 &&
+ !getLangOpts().ObjC2 && "This routine must be called in C mode only!");
+
+  QualType OldCan = getCanonicalType(OldType);
+  QualType NewCan = getCanonicalType(NewType);
+
+  if (OldCan.getCVRQualifiers() != NewCan.getCVRQualifiers())
+return false;
+
+  if (OldCan->isPointerType() && NewCan->isPointerType()) {
+QualType OldPointee = OldType->getPointeeType();
+QualType NewPointee = NewType->getPointeeType();
+// void * and char * are interchangeable.
+if ((OldPointee->isCharType() && NewPointee->isVoidType()) ||
+(OldPointee->isVoidType() && NewPointee->isCharType()))
+  return true;
+return areMSCompatibleTypedefTypesInC(OldPointee, NewPointee);
+  }
+
+  bool EquallySignedInts = (OldCan->isSignedIntegerOrEnumerationType() &&
+NewCan->isSignedIntegerOrEnumerationType()) ||
+   (OldCan->isUnsignedIntegerOrEnumerationType() &&
+NewCan->isUnsignedIntegerOrEnumerationType());
+  if (!EquallySignedInts)
+return false;
+
+  auto OldTypeInfo = getTypeInfo(OldCan);
+  auto NewTypeInfo = getTypeInfo(NewCan);
+  return (OldTypeInfo.Width == NewTypeInfo.Width &&
+  OldTypeInfo.Align == NewTypeInfo.Align);
+}
+
 //===--===//
 // ObjCQualifiedIdTypesAreCompatible - Compatibility testing for qualified id's.
 //===--===//
Index: lib/Sema/SemaDecl.cpp
===
--- lib/Sema/SemaDecl.cpp
+++ lib/Sema/SemaDecl.cpp
@@ -1842,9 +1842,30 @@
   Filter.done();
 }
 
+static bool areMSCompatibleTypedefs(TypedefNameDecl *Old, TypedefNameDecl *New,
+ASTContext ) {
+#ifndef NDEBUG
+  const LangOptions  = Context.getLangOpts();
+  assert(Opts.MSVCCompat &&
+ "This routine must be called in Microsoft mode only!");
+  assert(!Opts.CPlusPlus && !Opts.ObjC1 && !Opts.ObjC2 &&
+ "This routine must be called in C mode only!");
+  assert(Old && New && "Expected valid typedef declarations!");
+#endif
+
+  // If both are locally-scoped, emit an error.
+  if (!Old->getDeclContext()->isFileContext() &&
+  !New->getDeclContext()->isFileContext())
+return false;
+
+  return Context.areMSCompatibleTypedefTypesInC(Old->getUnderlyingType(),
+New->getUnderlyingType());
+}
+
 bool Sema::isIncompatibleTypedef(TypeDecl *Old, TypedefNameDecl *New) {
   QualType OldType;
-  if (TypedefNameDecl *OldTypedef = dyn_cast(Old))
+  auto *OldTypedef = dyn_cast(Old);
+  if (OldTypedef)
 OldType = OldTypedef->getUnderlyingType();
   else
 OldType = Context.getTypeDeclType(Old);
@@ -1860,18 +1881,35 @@
 New->setInvalidDecl();
 return true;
   }
-  
+
   if (OldType != NewType &&
   !OldType->isDependentType() &&
   !NewType->isDependentType() &&
-  !Context.hasSameType(OldType, NewType)) { 
-int Kind = isa(Old) ? 1 : 0;
-Diag(New->getLocation(), diag::err_redefinition_different_typedef)
-  << Kind << NewType << OldType;
-if (Old->getLocation().isValid())
-  Diag(Old->getLocation(), diag::note_previous_definition);
-New->setInvalidDecl();
-return true;
+  !Context.hasSameType(OldType, NewType)) {
+const LangOptions  = Context.getLangOpts();
+bool AllowedAsMicrosoftExtInC =
+Opts.MSVCCompat && !Opts.CPlusPlus && !Opts.ObjC1 && !Opts.ObjC2 &&
+OldTypedef && areMSCompatibleTypedefs(OldTypedef, New, Context);
+
+SourceLocation OldLocation = Old->getLocation();
+if (AllowedAsMicrosoftExtInC) {
+  Diag(New->getLocation(), diag::warn_int_typedef_redefinition_ignored)
+  << NewType << OldType;
+  if (OldTypedef->isModed())
+New->setModedTypeSourceInfo(OldTypedef->getTypeSourceInfo(),
+  

Re: [PATCH] D16770: [MS] PR26234: Allow typedef redefinition of equally qualified, sized and aligned types in C

[Denis Zobnin via cfe-commits]

d.zobnin.bugzilla marked 5 inline comments as done.


Comment at: include/clang/AST/ASTContext.h:1772-1783
@@ -1771,1 +1771,14 @@
 
+  /// Return true is the given typedef types are compatible in C from MSVC's
+  /// point of view.
+  //
+  // Conditions:
+  //   1. Both typedef types are either integer, enumeral or pointers;
+  //   2. Both typedef types have the same qualifiers and signedness;
+  //   3. Both typedef types have the same size and alignment;
+  //   4. If pointers:
+  // 4.1. Levels of pointers are equal;
+  // 4.2. Pointee types are MSVC-compatible OR
+  // 4.3. One type points to void and another points to char.
+  bool areMSCompatibleTypedefTypesInC(QualType OldType, QualType NewType);
+

By the way, MSVC allows to redefine not anly typedefs, but variables as well 
(under the same conditions as typedefs):

```
int x;
long x;
```
Typedef redefinition seems to be just an example of MSVC's permissive behavior. 
The same for return types, etc.

So, do you think we need to compatible with MSVC, for example, also considering 
only integer types?


Comment at: include/clang/Basic/DiagnosticSemaKinds.td:4267-4269
@@ -4266,1 +4266,5 @@
   InGroup>;
+def warn_int_typedef_redefinition_ignored : ExtWarn<
+  "ignoring conflicting integer typedef redefinition%diff{ ($ vs $)|}0,1 "
+  "as a Microsoft extension; types have the same width and signedness">,
+  InGroup;

Done. I also tried to move the phrase "types have the same ..." to a note, but 
I thought the only warning was better.


http://reviews.llvm.org/D16770



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

Re: [PATCH] D16759: [OpenMP] Parsing + sema for target parallel for directive.

[Arpith Jacob via cfe-commits]

arpith-jacob marked an inline comment as done.
arpith-jacob added a comment.

Alexey, I've made the change in the comments.  Thanks very much for your time!


http://reviews.llvm.org/D16759



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

Re: [PATCH] D12834: add gcc abi_tag support

[Dmitry Polukhin via cfe-commits]

DmitryPolukhin added a comment.

I think Sema part should be exacted to separate patch and committed first after 
fixing Aaron's comments. Mangling part requires more work and much more tests. 
I'm still looking what actually GCC does and how it can be re-implemented in 
Clang without calling mangler twice.



Comment at: lib/Sema/SemaDeclAttr.cpp:4450
@@ +4449,3 @@
+static void handleAbiTagAttr(Sema , Decl *D,
+ const AttributeList ) {
+  const auto *NS = dyn_cast(D);

Nit, all args fits to single line and the whole function needs clang-format.


Repository:
  rL LLVM

http://reviews.llvm.org/D12834



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

Re: [PATCH] D16482: Add builtins for bitreverse intrinsic

[Hal Finkel via cfe-commits]

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

LGTM.


http://reviews.llvm.org/D16482



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

Re: [PATCH] D16748: Cleanup MemRegion.cpp/MemRegion.h

[Aaron Ballman via cfe-commits]

aaron.ballman closed this revision.
aaron.ballman added a comment.

LGTM, but the patch does not apply cleanly because it was created using 
absolute paths. In the future, please generate the patch with relative paths. 
;-)

Commit in r259652


http://reviews.llvm.org/D16748



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

r259652 - Minor cleanup to remove casts and improve some const correctness. NFC.

[Aaron Ballman via cfe-commits]

Author: aaronballman
Date: Wed Feb  3 09:20:51 2016
New Revision: 259652

URL: http://llvm.org/viewvc/llvm-project?rev=259652=rev
Log:
Minor cleanup to remove casts and improve some const correctness. NFC.

Patch by Alexander Riccio.

Modified:
cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h
cfe/trunk/lib/StaticAnalyzer/Core/MemRegion.cpp

Modified: cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h?rev=259652=259651=259652=diff
==
--- cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h 
(original)
+++ cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h Wed 
Feb  3 09:20:51 2016
@@ -1320,8 +1320,8 @@ public:
 
   void setTrait(SymbolRef Sym, InvalidationKinds IK);
   void setTrait(const MemRegion *MR, InvalidationKinds IK);
-  bool hasTrait(SymbolRef Sym, InvalidationKinds IK);
-  bool hasTrait(const MemRegion *MR, InvalidationKinds IK);
+  bool hasTrait(SymbolRef Sym, InvalidationKinds IK) const;
+  bool hasTrait(const MemRegion *MR, InvalidationKinds IK) const;
 };
   
 } // end GR namespace

Modified: cfe/trunk/lib/StaticAnalyzer/Core/MemRegion.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Core/MemRegion.cpp?rev=259652=259651=259652=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Core/MemRegion.cpp (original)
+++ cfe/trunk/lib/StaticAnalyzer/Core/MemRegion.cpp Wed Feb  3 09:20:51 2016
@@ -46,7 +46,7 @@ RegionTy* MemRegionManager::getRegion(co
InsertPos));
 
   if (!R) {
-R = (RegionTy*) A.Allocate();
+R = A.Allocate();
 new (R) RegionTy(a1, superRegion);
 Regions.InsertNode(R, InsertPos);
   }
@@ -64,7 +64,7 @@ RegionTy* MemRegionManager::getSubRegion
InsertPos));
 
   if (!R) {
-R = (RegionTy*) A.Allocate();
+R = A.Allocate();
 new (R) RegionTy(a1, superRegion);
 Regions.InsertNode(R, InsertPos);
   }
@@ -85,7 +85,7 @@ RegionTy* MemRegionManager::getRegion(co
InsertPos));
 
   if (!R) {
-R = (RegionTy*) A.Allocate();
+R = A.Allocate();
 new (R) RegionTy(a1, a2, superRegion);
 Regions.InsertNode(R, InsertPos);
   }
@@ -104,7 +104,7 @@ RegionTy* MemRegionManager::getSubRegion
InsertPos));
 
   if (!R) {
-R = (RegionTy*) A.Allocate();
+R = A.Allocate();
 new (R) RegionTy(a1, a2, superRegion);
 Regions.InsertNode(R, InsertPos);
   }
@@ -123,7 +123,7 @@ RegionTy* MemRegionManager::getSubRegion
InsertPos));
 
   if (!R) {
-R = (RegionTy*) A.Allocate();
+R = A.Allocate();
 new (R) RegionTy(a1, a2, a3, superRegion);
 Regions.InsertNode(R, InsertPos);
   }
@@ -246,23 +246,23 @@ QualType CXXBaseObjectRegion::getValueTy
 
//===--===//
 
 void MemSpaceRegion::Profile(llvm::FoldingSetNodeID ) const {
-  ID.AddInteger((unsigned)getKind());
+  ID.AddInteger(static_cast(getKind()));
 }
 
 void StackSpaceRegion::Profile(llvm::FoldingSetNodeID ) const {
-  ID.AddInteger((unsigned)getKind());
+  ID.AddInteger(static_cast(getKind()));
   ID.AddPointer(getStackFrame());
 }
 
 void StaticGlobalSpaceRegion::Profile(llvm::FoldingSetNodeID ) const {
-  ID.AddInteger((unsigned)getKind());
+  ID.AddInteger(static_cast(getKind()));
   ID.AddPointer(getCodeRegion());
 }
 
 void StringRegion::ProfileRegion(llvm::FoldingSetNodeID& ID,
  const StringLiteral* Str,
  const MemRegion* superRegion) {
-  ID.AddInteger((unsigned) StringRegionKind);
+  ID.AddInteger(static_cast(StringRegionKind));
   ID.AddPointer(Str);
   ID.AddPointer(superRegion);
 }
@@ -270,7 +270,7 @@ void StringRegion::ProfileRegion(llvm::F
 void ObjCStringRegion::ProfileRegion(llvm::FoldingSetNodeID& ID,
  const ObjCStringLiteral* Str,
  const MemRegion* superRegion) {
-  ID.AddInteger((unsigned) ObjCStringRegionKind);
+  ID.AddInteger(static_cast(ObjCStringRegionKind));
   ID.AddPointer(Str);
   ID.AddPointer(superRegion);
 }
@@ -278,7 +278,7 @@ void ObjCStringRegion::ProfileRegion(llv
 void AllocaRegion::ProfileRegion(llvm::FoldingSetNodeID& ID,
  const Expr *Ex, unsigned cnt,
  const MemRegion *superRegion) {
-  ID.AddInteger((unsigned) AllocaRegionKind);
+  ID.AddInteger(static_cast(AllocaRegionKind));
   ID.AddPointer(Ex);

Re: [PATCH] D16376: clang-tidy check: rule-of-five

[Alexander Kornienko via cfe-commits]

alexfh added a comment.

In http://reviews.llvm.org/D16376#342901, @jbcoe wrote:

> I think I'll move this check to `cppcoreguidelines` and call it 
> `rule-of-five`.


Yes, please move it to cppcoreguidelines.

> https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#c21-if-you-define-or-delete-any-default-operation-define-or-delete-them-all


Please use anchors defined in the .md file. They are somewhat stable unlike the 
automatic anchors generated by github (which have changed at least once since 
first C++ Core Guidelines checks were committed). For the rule of five this 
would be 
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rc-five

> I'll add destructor handling as a later patch.


SG


http://reviews.llvm.org/D16376



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

r259651 - [OpenCL] Adding reserved operator logical xor for OpenCL

[Anastasia Stulova via cfe-commits]

Author: stulova
Date: Wed Feb  3 09:17:14 2016
New Revision: 259651

URL: http://llvm.org/viewvc/llvm-project?rev=259651=rev
Log:
[OpenCL] Adding reserved operator logical xor for OpenCL

This patch adds the reserved operator ^^ when compiling for OpenCL (spec v1.1 
s6.3.g),
which results in a more meaningful error message.

Patch by Neil Hickey!

Review: http://reviews.llvm.org/D13280

Mtest/SemaOpenCL/unsupported.cl
Minclude/clang/Basic/TokenKinds.def
Minclude/clang/Basic/DiagnosticParseKinds.td
Mlib/Basic/OperatorPrecedence.cpp
Mlib/Lex/Lexer.cpp
Mlib/Parse/ParseExpr.cpp

Modified:
cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td
cfe/trunk/include/clang/Basic/TokenKinds.def
cfe/trunk/lib/Basic/OperatorPrecedence.cpp
cfe/trunk/lib/Lex/Lexer.cpp
cfe/trunk/lib/Parse/ParseExpr.cpp
cfe/trunk/test/SemaOpenCL/unsupported.cl

Modified: cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td?rev=259651=259650=259651=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td Wed Feb  3 09:17:14 
2016
@@ -910,9 +910,11 @@ def warn_pragma_expected_enable_disable
 def warn_pragma_unknown_extension : Warning<
   "unknown OpenCL extension %0 - ignoring">, InGroup;
 
-// OpenCL error
+// OpenCL errors.
 def err_opencl_taking_function_address_parser : Error<
   "taking address of function is not allowed">;
+def err_opencl_logical_exclusive_or : Error<
+  "^^ is a reserved operator in OpenCL">;
 
 // OpenMP support.
 def warn_pragma_omp_ignored : Warning<

Modified: cfe/trunk/include/clang/Basic/TokenKinds.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/TokenKinds.def?rev=259651=259650=259651=diff
==
--- cfe/trunk/include/clang/Basic/TokenKinds.def (original)
+++ cfe/trunk/include/clang/Basic/TokenKinds.def Wed Feb  3 09:17:14 2016
@@ -219,6 +219,9 @@ PUNCTUATOR(at,  "@")
 PUNCTUATOR(lesslessless,  "<<<")
 PUNCTUATOR(greatergreatergreater, ">>>")
 
+// CL support
+PUNCTUATOR(caretcaret,"^^")
+
 // C99 6.4.1: Keywords.  These turn into kw_* tokens.
 // Flags allowed:
 //   KEYALL   - This is a keyword in all variants of C and C++, or it

Modified: cfe/trunk/lib/Basic/OperatorPrecedence.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/OperatorPrecedence.cpp?rev=259651=259650=259651=diff
==
--- cfe/trunk/lib/Basic/OperatorPrecedence.cpp (original)
+++ cfe/trunk/lib/Basic/OperatorPrecedence.cpp Wed Feb  3 09:17:14 2016
@@ -53,6 +53,7 @@ prec::Level getBinOpPrecedence(tok::Toke
   case tok::pipeequal:return prec::Assignment;
   case tok::question: return prec::Conditional;
   case tok::pipepipe: return prec::LogicalOr;
+  case tok::caretcaret:
   case tok::ampamp:   return prec::LogicalAnd;
   case tok::pipe: return prec::InclusiveOr;
   case tok::caret:return prec::ExclusiveOr;

Modified: cfe/trunk/lib/Lex/Lexer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/Lexer.cpp?rev=259651=259650=259651=diff
==
--- cfe/trunk/lib/Lex/Lexer.cpp (original)
+++ cfe/trunk/lib/Lex/Lexer.cpp Wed Feb  3 09:17:14 2016
@@ -3505,6 +3505,9 @@ LexNextToken:
 if (Char == '=') {
   CurPtr = ConsumeChar(CurPtr, SizeTmp, Result);
   Kind = tok::caretequal;
+} else if (LangOpts.OpenCL && Char == '^') {
+  CurPtr = ConsumeChar(CurPtr, SizeTmp, Result);
+  Kind = tok::caretcaret;
 } else {
   Kind = tok::caret;
 }

Modified: cfe/trunk/lib/Parse/ParseExpr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/ParseExpr.cpp?rev=259651=259650=259651=diff
==
--- cfe/trunk/lib/Parse/ParseExpr.cpp (original)
+++ cfe/trunk/lib/Parse/ParseExpr.cpp Wed Feb  3 09:17:14 2016
@@ -263,6 +263,9 @@ Parser::ParseRHSOfBinaryExpression(ExprR
 Token OpToken = Tok;
 ConsumeToken();
 
+if (OpToken.is(tok::caretcaret)) {
+  return ExprError(Diag(Tok, diag::err_opencl_logical_exclusive_or));
+}
 // Bail out when encountering a comma followed by a token which can't
 // possibly be the start of an expression. For instance:
 //   int f() { return 1, }

Modified: cfe/trunk/test/SemaOpenCL/unsupported.cl
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaOpenCL/unsupported.cl?rev=259651=259650=259651=diff
==
--- cfe/trunk/test/SemaOpenCL/unsupported.cl 

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

[Daniel Marjamäki via cfe-commits]

danielmarjamaki added a comment.

In http://reviews.llvm.org/D13126#335929, @danielmarjamaki wrote:

> For information, I am testing this patch right now.. it will take a while 1-2 
> days.


I have run my latest patch..

In 2215 projects it found 875 warnings.

For comparison the -Wconversion generates ~1.5 million warnings in these 
projects. So it's drastically less noisy.

I have triaged random warnings of those 875. I classified 11 warnings as false 
positive, 85 as true positive, 3 as dontknow (I fail to determine if there is 
or is not truncation).


http://reviews.llvm.org/D13126



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

r259648 - Provide match function to look over an entire TU again.

[Daniel Jasper via cfe-commits]

Author: djasper
Date: Wed Feb  3 08:29:55 2016
New Revision: 259648

URL: http://llvm.org/viewvc/llvm-project?rev=259648=rev
Log:
Provide match function to look over an entire TU again.

Modified:
cfe/trunk/include/clang/ASTMatchers/ASTMatchFinder.h
cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.cpp

Modified: cfe/trunk/include/clang/ASTMatchers/ASTMatchFinder.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/ASTMatchers/ASTMatchFinder.h?rev=259648=259647=259648=diff
==
--- cfe/trunk/include/clang/ASTMatchers/ASTMatchFinder.h (original)
+++ cfe/trunk/include/clang/ASTMatchers/ASTMatchFinder.h Wed Feb  3 08:29:55 
2016
@@ -241,6 +241,11 @@ match(MatcherT Matcher, const ast_type_t
   ASTContext );
 /// @}
 
+/// \brief Returns the results of matching \p Matcher on the translation unit 
of
+/// \p Context and collects the \c BoundNodes of all callback invocations.
+template 
+SmallVector match(MatcherT Matcher, ASTContext );
+
 /// \brief Returns the first result of type \c NodeT bound to \p BoundTo.
 ///
 /// Returns \c NULL if there is no match, or if the matching node cannot be
@@ -288,6 +293,16 @@ match(MatcherT Matcher, const NodeT 
   return match(Matcher, ast_type_traits::DynTypedNode::create(Node), Context);
 }
 
+template 
+SmallVector
+match(MatcherT Matcher, ASTContext ) {
+  internal::CollectMatchesCallback Callback;
+  MatchFinder Finder;
+  Finder.addMatcher(Matcher, );
+  Finder.matchAST(Context);
+  return std::move(Callback.Nodes);
+}
+
 } // end namespace ast_matchers
 } // end namespace clang
 

Modified: cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.cpp?rev=259648=259647=259648=diff
==
--- cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.cpp (original)
+++ cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.cpp Wed Feb  3 08:29:55 2016
@@ -5050,6 +5050,15 @@ TEST(MatchFinder, InterceptsEndOfTransla
   EXPECT_TRUE(VerifyCallback.Called);
 }
 
+TEST(Matcher, matchOverEntireASTContext) {
+  std::unique_ptr AST =
+  clang::tooling::buildASTFromCode("struct { int *foo; };");
+  ASSERT_TRUE(AST.get());
+  auto PT = selectFirst(
+  "x", match(pointerType().bind("x"), AST->getASTContext()));
+  EXPECT_NE(nullptr, PT);
+}
+
 TEST(EqualsBoundNodeMatcher, QualType) {
   EXPECT_TRUE(matches(
   "int i = 1;", varDecl(hasType(qualType().bind("type")),
@@ -5276,7 +5285,6 @@ TEST(ObjCMessageExprMatcher, SimpleExprs
   objcMessageExpr(matchesSelector("uppercase*"),
   argumentCountIs(0)
   )));
-  
 }
 
 } // end namespace ast_matchers


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

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

[Yaxun Liu via cfe-commits]

yaxunl updated this revision to Diff 46783.
yaxunl marked an inline comment as done.
yaxunl added a comment.

Revised as Xiuli suggested.

With the change, there will be quotation marks around the attribute name, so 
other diagnostics are also changed to be consistent.


http://reviews.llvm.org/D16686

Files:
  include/clang/Basic/Attr.td
  include/clang/Basic/AttrDocs.td
  include/clang/Basic/DiagnosticParseKinds.td
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Parse/Parser.h
  lib/CodeGen/CGLoopInfo.cpp
  lib/Parse/ParseDecl.cpp
  lib/Parse/ParseStmt.cpp
  lib/Sema/SemaStmtAttr.cpp
  test/CodeGenOpenCL/unroll-hint.cl
  test/Parser/opencl-unroll-hint.cl
  test/SemaOpenCL/unroll-hint.cl

Index: test/SemaOpenCL/unroll-hint.cl
===
--- /dev/null
+++ test/SemaOpenCL/unroll-hint.cl
@@ -0,0 +1,24 @@
+//RUN: %clang_cc1 -O0 -cl-std=CL2.0 -fsyntax-only -verify %s
+
+kernel void C (global int *x) {
+  int I = 3;
+  __attribute__((opencl_unroll_hint(I))) // expected-error {{'opencl_unroll_hint' attribute requires an integer constant}}
+  while (I--);
+}
+
+kernel void D (global int *x) {
+  int i = 10;
+  __attribute__((opencl_unroll_hint))
+  do {
+  } while(i--);
+}
+
+kernel void E() {
+  __attribute__((opencl_unroll_hint(2,4))) // expected-error {{'opencl_unroll_hint' attribute takes no more than 1 argument}}
+  for(int i=0; i<100; i++);
+}
+
+kernel void F() {
+  __attribute__((opencl_unroll_hint(-1))) // expected-error {{'opencl_unroll_hint' attribute requires a positive integral compile time constant expression}}
+  for(int i=0; i<100; i++);
+}
Index: test/Parser/opencl-unroll-hint.cl
===
--- /dev/null
+++ test/Parser/opencl-unroll-hint.cl
@@ -0,0 +1,8 @@
+//RUN: %clang_cc1 -O0 -cl-std=CL2.0 -fsyntax-only -verify %s
+
+kernel void B (global int *x) {
+  __attribute__((opencl_unroll_hint(42)))
+  if (x[0]) // expected-error {{OpenCL only supports 'opencl_unroll_hint' attribute on for, while, and do statements}}
+x[0] = 15;
+}
+
Index: test/CodeGenOpenCL/unroll-hint.cl
===
--- /dev/null
+++ test/CodeGenOpenCL/unroll-hint.cl
@@ -0,0 +1,96 @@
+// RUN: %clang_cc1 -emit-llvm -O0 -cl-std=CL2.0 -o - %s | FileCheck %s
+
+/*** for ***/
+void for_count()
+{
+// CHECK-LABEL: for_count
+__attribute__((opencl_unroll_hint(8)))
+for( int i = 0; i < 1000; ++i);
+// CHECK: br label %{{.*}}, !llvm.loop ![[FOR_COUNT:.*]]
+}
+
+void for_disable()
+{
+// CHECK-LABEL: for_disable
+__attribute__((opencl_unroll_hint(1)))
+for( int i = 0; i < 1000; ++i);
+// CHECK: br label %{{.*}}, !llvm.loop ![[FOR_DISABLE:.*]]
+}
+
+void for_full()
+{
+// CHECK-LABEL: for_full
+__attribute__((opencl_unroll_hint))
+for( int i = 0; i < 1000; ++i);
+// CHECK: br label %{{.*}}, !llvm.loop ![[FOR_FULL:.*]]
+}
+
+/*** while ***/
+void while_count()
+{
+// CHECK-LABEL: while_count
+int i = 1000;
+__attribute__((opencl_unroll_hint(8)))
+while(i-->0);
+// CHECK: br label %{{.*}}, !llvm.loop ![[WHILE_COUNT:.*]]
+}
+
+void while_disable()
+{
+// CHECK-LABEL: while_disable
+int i = 1000;
+__attribute__((opencl_unroll_hint(1)))
+while(i-->0);
+// CHECK: br label %{{.*}}, !llvm.loop ![[WHILE_DISABLE:.*]]
+}
+
+void while_full()
+{
+// CHECK-LABEL: while_full
+int i = 1000;
+__attribute__((opencl_unroll_hint))
+while(i-->0);
+// CHECK: br label %{{.*}}, !llvm.loop ![[WHILE_FULL:.*]]
+}
+
+/*** do ***/
+void do_count()
+{
+// CHECK-LABEL: do_count
+int i = 1000;
+__attribute__((opencl_unroll_hint(8)))
+do {} while(i--> 0);
+// CHECK: br i1 %{{.*}}, label %{{.*}}, label %{{.*}}, !llvm.loop ![[DO_COUNT:.*]]
+}
+
+void do_disable()
+{
+// CHECK-LABEL: do_disable
+int i = 1000;
+__attribute__((opencl_unroll_hint(1)))
+do {} while(i--> 0);
+// CHECK: br i1 %{{.*}}, label %{{.*}}, label %{{.*}}, !llvm.loop ![[DO_DISABLE:.*]]
+}
+
+void do_full()
+{
+// CHECK-LABEL: do_full
+int i = 1000;
+__attribute__((opencl_unroll_hint))
+do {} while(i--> 0);
+// CHECK: br i1 %{{.*}}, label %{{.*}}, label %{{.*}}, !llvm.loop ![[DO_FULL:.*]]
+}
+
+
+// CHECK: ![[FOR_COUNT]] =  distinct !{![[FOR_COUNT]],  ![[COUNT:.*]]}
+// CHECK: ![[COUNT]] =  !{!"llvm.loop.unroll.count", i32 8}
+// CHECK: ![[FOR_DISABLE]]   =  distinct !{![[FOR_DISABLE]],  ![[DISABLE:.*]]}
+// CHECK: ![[DISABLE]]   =  !{!"llvm.loop.unroll.disable"}
+// CHECK: ![[FOR_FULL]]  =  distinct !{![[FOR_FULL]],  ![[FULL:.*]]}
+// CHECK: ![[FULL]]  =  !{!"llvm.loop.unroll.full"}
+// CHECK: ![[WHILE_COUNT]]   =  distinct !{![[WHILE_COUNT]],![[COUNT]]}
+// CHECK: ![[WHILE_DISABLE]] =  distinct !{![[WHILE_DISABLE]],  ![[DISABLE]]}
+// CHECK: ![[WHILE_FULL]]=  distinct !{![[WHILE_FULL]], ![[FULL]]}
+// CHECK: ![[DO_COUNT]]  =  distinct !{![[DO_COUNT]],   

[PATCH] D16870: [CUDA] Tweak attribute-based overload resolution to match nvcc behavior.

[Artem Belevich via cfe-commits]

tra created this revision.
tra added reviewers: jlebar, jingyue, jpienaar, eliben.
tra added a subscriber: cfe-commits.

This is an artefact of split-mode CUDA compilation that we need to
mimic. HD functions are sometimes allowed to call H or D functions. Due
to split compilation mode device-side compilation will not see host-only
function and thus they will not be considered at all. For clang both H
and D variants will become function overloads visible to
compiler. Normally target attribute is considered only if C++ rules can
not determine which function is better. However in this case we need to
discard functions that would not be present during current compilation
phase before we apply normal overload resolution rules.

Changes:
* introduce another level of call preference to better describe
  possible call combinations.
* added early check for calls matching scenario above
  in isBetterOverloadCandidate().
* disabled H->D and D->H and G->H calls. These combinations are
  not allowed by CUDA and we were reluctantly allowing them to work
  around device-side calls to math functions in std namespace.
  We no longer need it after r258880.


http://reviews.llvm.org/D16870

Files:
  include/clang/Sema/Sema.h
  lib/Sema/SemaCUDA.cpp
  lib/Sema/SemaOverload.cpp
  test/CodeGenCUDA/function-overload.cu

Index: test/CodeGenCUDA/function-overload.cu
===
--- test/CodeGenCUDA/function-overload.cu
+++ test/CodeGenCUDA/function-overload.cu
@@ -7,7 +7,8 @@
 // RUN: | FileCheck -check-prefix=CHECK-BOTH -check-prefix=CHECK-HOST %s
 // RUN: %clang_cc1 -triple nvptx64-nvidia-cuda -fcuda-is-device \
 // RUN: -fcuda-target-overloads -emit-llvm -o - %s \
-// RUN: | FileCheck -check-prefix=CHECK-BOTH -check-prefix=CHECK-DEVICE %s
+// RUN: | FileCheck -check-prefix=CHECK-BOTH -check-prefix=CHECK-DEVICE \
+// RUN:   -check-prefix=CHECK-DEVICE-STRICT %s
 
 // Check target overloads handling with disabled call target checks.
 // RUN: %clang_cc1 -DNOCHECKS -triple x86_64-unknown-linux-gnu -emit-llvm \
@@ -77,6 +78,91 @@
 extern "C" __host__ __device__ int chd(void) {return 14;}
 // CHECK-BOTH: ret i32 14
 
+// NOTE: this is an artefact of split-mode CUDA compilation that we
+// need to mimic. HD functions are sometimes allowed to call H or D
+// functions. Due to split compilation mode device-side compilation
+// will not see host-only function and thus they will not be
+// considered at all. For clang both H and D variants will become
+// function overloads. Normally target attribute is considered only if
+// C++ rules can not determine which function is better. However in
+// this case we need to discard functions that would not be present
+// during current compilation phase before we apply normal overload
+// resolution rules.
+
+// Large enough difference in calling preferences should have
+// precedence over standard C++ overloading rules.
+template  T template_vs_function(T arg) { return 15; }
+__device__ float template_vs_function(float arg) { return 16; }
+
+// In this case during host compilation we expect to cal function
+// template even if __device__ function may be available and allowed
+// by -fcuda-disable-target-call-checks and, according to C++ overload
+// resolution rules, would be prefered over function template.
+// CHECK-BOTH-LABEL: define void @_Z5hd_tfv()
+__host__ __device__ void hd_tf(void) {
+  template_vs_function(1.0f);
+  // CHECK-HOST: call float @_Z20template_vs_functionIfET_S0_(float
+  // CHECK-DEVICE: call float @_Z20template_vs_functionf(float
+  template_vs_function(2.0);
+  // CHECK-HOST: call double @_Z20template_vs_functionIdET_S0_(double
+  // CHECK-DEVICE: call float @_Z20template_vs_functionf(float
+}
+
+// Calls from __host__ and __device__ functions should always call
+// overloaded function that matches their mode.
+// CHECK-HOST-LABEL: define void @_Z4h_tfv()
+__host__ void h_tf() {
+  template_vs_function(1.0f);
+  // CHECK-HOST: call float @_Z20template_vs_functionIfET_S0_(float
+  template_vs_function(2.0);
+  // CHECK-HOST: call double @_Z20template_vs_functionIdET_S0_(double
+}
+
+// CHECK-DEVICE-LABEL: define void @_Z4d_tfv()
+__device__ void d_tf() {
+  template_vs_function(1.0f);
+  // CHECK-DEVICE: call float @_Z20template_vs_functionf(float
+  template_vs_function(2.0);
+  // CHECK-DEVICE: call float @_Z20template_vs_functionf(float
+}
+
+// In case of smaller difference between calling preferences
+// (HD->{HD,H} call), C++ rules take precedence. So, when we need to pick
+// between (host or device) function template and HD function, C++
+// rules will have precedence.
+
+template  T template_vs_hd_function(T arg) { return 15; }
+__host__ __device__ float template_vs_hd_function(float arg) { return 16; }
+
+// CHECK-BOTH-LABEL: define void @_Z7hd_thdfv()
+__host__ __device__ void hd_thdf() {
+  template_vs_hd_function(1.0f);
+  // CHECK-HOST: call float 

Re: [PATCH] D16700: [Clang-tidy] Make null pointer literals for fixes configurable for two checks

[Richard via cfe-commits]

LegalizeAdulthood added inline comments.


Comment at: clang-tidy/readability/ImplicitBoolCastCheck.h:32
@@ -30,1 +31,3 @@
+Options.get("NullPointerLiteral",
+Context->getLangOpts().CPlusPlus11 ? "nullptr" : "0")) {}
   void registerMatchers(ast_matchers::MatchFinder *Finder) override;

aaron.ballman wrote:
> I know you are following the pattern used in the code here, but I think this 
> class needs a storeOptions() function as well. See AssertSideEffectCheck as 
> an example.
This will need rebasing on the existing code, which is using "NULL" as the 
pre-C++11 fallback default, not "0".


Comment at: clang-tidy/readability/ImplicitBoolCastCheck.h:36-38
@@ -32,1 +35,5 @@
 
+  StringRef getNullPointerLiteral() const {
+return NullPointerLiteral;
+  }
+

I don't understand why the checks need a public getter for the nullptr literal 
being used.


Comment at: clang-tidy/readability/SimplifyBooleanExprCheck.cpp:175
@@ -174,2 +174,3 @@
 
-std::string replacementExpression(const MatchFinder::MatchResult ,
+std::string replacementExpression(SimplifyBooleanExprCheck *Check,
+  const MatchFinder::MatchResult ,

aaron.ballman wrote:
> Check can be a const pointer.
Passing the check in here is overkill.  This helper function isn't going to 
ever be used for multiple checks and the only thing you ever do with the check 
is get the nullptr literal, so just pass in the thing it needs directly.

This will also need to be rebased onto the current code.


Comment at: docs/clang-tidy/checks/readability-simplify-boolean-expr.rst:79-81
@@ -78,1 +78,4 @@
 
+Null pointer literal for fixes could be changed with option
+``NullPointerLiteral``. The default value for C++11 or later is ``nullptr``, 
for
+ C++98/C++03 - ``0``.

The wording here is awkward.  Instead, I suggest:

```
The option ``NullPointerLiteral`` configures the text used for comparisons of 
pointers
against zero to synthesize boolean expressions.  The default value for C++11 or 
later
is ``nullptr``, otherwise the value is ``NULL``.
```

It's subjective, but my experience is that pre C++11 code bases prefer `NULL` 
over `0`.


Repository:
  rL LLVM

http://reviews.llvm.org/D16700



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

Re: [PATCH] D16794: [Clang-tidy] Make readability-simplify-boolean-expr working with included files

[Eugene Zelenko via cfe-commits]

Eugene.Zelenko added a comment.

In http://reviews.llvm.org/D16794#343652, @LegalizeAdulthood wrote:

> Again, isn't this already assigned to me in the bug tracker?
>
> In general, my assumption in bug trackers is that if someone has assigned the 
> bug to themselves, then they are working on it.


Sorry, if I steeped on you toes. My intention was to backport fix into 3.8 if 
it'll be OK. Sure, it'll be much better if original author will fix problem.


Repository:
  rL LLVM

http://reviews.llvm.org/D16794



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

r259728 - Bump DiagnosticSemaKinds count; we're close to hitting it.

[Manman Ren via cfe-commits]

Author: mren
Date: Wed Feb  3 17:35:29 2016
New Revision: 259728

URL: http://llvm.org/viewvc/llvm-project?rev=259728=rev
Log:
Bump DiagnosticSemaKinds count; we're close to hitting it.

 $ grep '= DIAG_START_SEMA' include/clang/Basic/DiagnosticIDs.h
   DIAG_START_ANALYSIS  = DIAG_START_SEMA+ 3000
 $ grep 'def ' include/clang/Basic/DiagnosticSemaKinds.td | wc -l
   2994

Modified:
cfe/trunk/include/clang/Basic/DiagnosticIDs.h

Modified: cfe/trunk/include/clang/Basic/DiagnosticIDs.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticIDs.h?rev=259728=259727=259728=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticIDs.h (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticIDs.h Wed Feb  3 17:35:29 2016
@@ -36,7 +36,7 @@ namespace clang {
   DIAG_START_AST   = DIAG_START_PARSE   +  500,
   DIAG_START_COMMENT   = DIAG_START_AST +  110,
   DIAG_START_SEMA  = DIAG_START_COMMENT +  100,
-  DIAG_START_ANALYSIS  = DIAG_START_SEMA+ 3000,
+  DIAG_START_ANALYSIS  = DIAG_START_SEMA+ 3500,
   DIAG_UPPER_LIMIT = DIAG_START_ANALYSIS+  100
 };
 


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

Re: [PATCH] D16794: [Clang-tidy] Make readability-simplify-boolean-expr working with included files

[Richard via cfe-commits]

LegalizeAdulthood added a comment.

In http://reviews.llvm.org/D16794#341552, @aaron.ballman wrote:

> Missing a test case for this functionality. The isExpansionInMainFile() was 
> used to silence the diagnostic in macros, but it was pointed out during 
> review that this should be fixed and it seems to have fallen through the 
> cracks. Can you also add tests for macros to ensure the behavior is 
> acceptable there still?
>
> See http://reviews.llvm.org/D8996 for more context.


It hasn't fallen through the cracks, I've been having an offline discussion 
with Alexander Kornienko about how to get automated checks to work for fixits 
applied to headers.


Repository:
  rL LLVM

http://reviews.llvm.org/D16794



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

Re: [PATCH] D16794: [Clang-tidy] Make readability-simplify-boolean-expr working with included files

[Richard via cfe-commits]

LegalizeAdulthood added a comment.

Again, isn't this already assigned to me in the bug tracker?

In general, my assumption in bug trackers is that if someone has assigned the 
bug to themselves, then they are working on it.


Repository:
  rL LLVM

http://reviews.llvm.org/D16794



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

Re: [PATCH] D16748: Cleanup MemRegion.cpp/MemRegion.h

[Alexander Riccio via cfe-commits]

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

Grr! missed a single note.


http://reviews.llvm.org/D16748



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

Re: [PATCH] D13893: Roll-back r250822.

[Alexander Riccio via cfe-commits]

ariccio added a comment.

In http://reviews.llvm.org/D13893#343436, @angelgarcia wrote:

> The compiler complained about creating constant instances of classes
>  without a user provided constructor (which is the case for the ASTMatchers).
>
> I gave up this change because it broke the build for a huge amount of
>  people and I didn't want that to happen again.


Ahh, ok. I saw one of these in MemRegion.cpp, and noticed this.


Repository:
  rL LLVM

http://reviews.llvm.org/D13893



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

Re: [PATCH] D16786: [Clang-tidy] Make modernize-redundant-void-arg working with included files

[Richard via cfe-commits]

LegalizeAdulthood added a comment.

I am already working on fixing this bug (isn't PR25894 
 already assigned to me?), but 
what's missing from this patch is an automated test that proves it works.

In order to write such an automated test, I believe some enhancements are 
needed to the `check_clang_tidy.py` script before such a test can be written.


Repository:
  rL LLVM

http://reviews.llvm.org/D16786



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

r259721 - Reapply r259624, it is likely not the commit causing the bot failures.

[Quentin Colombet via cfe-commits]

Author: qcolombet
Date: Wed Feb  3 16:41:00 2016
New Revision: 259721

URL: http://llvm.org/viewvc/llvm-project?rev=259721=rev
Log:
Reapply r259624, it is likely not the commit causing the bot failures.
Original message:
Make CF constant string decl visible to name lookup to fix module errors

The return type of the __builtin___*StringMakeConstantString functions
is a pointer to a struct, so we need that struct to be visible to name
lookup so that we will correctly merge multiple declarations of that
type if they come from different modules.

Incidentally, to make this visible to name lookup we need to rename the
type to __NSConstantString, since the real NSConstantString is an
Objective-C interface type.  This shouldn't affect anyone outside the
compiler since users of the constant string builtins cast the result
immediately to CFStringRef.

Since this struct type is otherwise implicitly created by the AST
context and cannot access namelookup, we make this a predefined type
and initialize it in Sema.

Note: this issue of builtins that refer to types not visible to name
lookup technically also affects other builtins (e.g. objc_msgSendSuper),
but in all other cases the builtin is a library builtin and the issue
goes away if you include the library that defines the types it uses,
unlike for these constant string builtins.

rdar://problem/24425801

Modified:
cfe/trunk/include/clang/AST/ASTContext.h
cfe/trunk/include/clang/Serialization/ASTBitCodes.h
cfe/trunk/lib/AST/ASTContext.cpp
cfe/trunk/lib/Sema/Sema.cpp
cfe/trunk/lib/Serialization/ASTReader.cpp
cfe/trunk/lib/Serialization/ASTWriter.cpp
cfe/trunk/test/CodeGenObjC/2010-02-01-utf16-with-null.m
cfe/trunk/test/CodeGenObjC/arc-no-arc-exceptions.m
cfe/trunk/test/CodeGenObjC/tentative-cfconstantstring.m
cfe/trunk/test/Modules/Inputs/builtin.h
cfe/trunk/test/Modules/builtins.m

Modified: cfe/trunk/include/clang/AST/ASTContext.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/ASTContext.h?rev=259721=259720=259721=diff
==
--- cfe/trunk/include/clang/AST/ASTContext.h (original)
+++ cfe/trunk/include/clang/AST/ASTContext.h Wed Feb  3 16:41:00 2016
@@ -1385,6 +1385,7 @@ public:
 return QualType();
   }
   void setCFConstantStringType(QualType T);
+  TagDecl *getCFConstantStringDecl() const;
 
   // This setter/getter represents the ObjC type for an NSConstantString.
   void setObjCConstantStringInterface(ObjCInterfaceDecl *Decl);

Modified: cfe/trunk/include/clang/Serialization/ASTBitCodes.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Serialization/ASTBitCodes.h?rev=259721=259720=259721=diff
==
--- cfe/trunk/include/clang/Serialization/ASTBitCodes.h (original)
+++ cfe/trunk/include/clang/Serialization/ASTBitCodes.h Wed Feb  3 16:41:00 2016
@@ -987,13 +987,16 @@ namespace clang {
 
   /// \brief The internal '__make_integer_seq' template.
   PREDEF_DECL_MAKE_INTEGER_SEQ_ID = 13,
+
+  /// \brief The internal '__NSConstantString' type.
+  PREDEF_DECL_CF_CONSTANT_STRING_ID = 14,
 };
 
 /// \brief The number of declaration IDs that are predefined.
 ///
 /// For more information about predefined declarations, see the
 /// \c PredefinedDeclIDs type and the PREDEF_DECL_*_ID constants.
-const unsigned int NUM_PREDEF_DECL_IDS = 14;
+const unsigned int NUM_PREDEF_DECL_IDS = 15;
 
 /// \brief Record code for a list of local redeclarations of a declaration.
 const unsigned int LOCAL_REDECLARATIONS = 50;

Modified: cfe/trunk/lib/AST/ASTContext.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ASTContext.cpp?rev=259721=259720=259721=diff
==
--- cfe/trunk/lib/AST/ASTContext.cpp (original)
+++ cfe/trunk/lib/AST/ASTContext.cpp Wed Feb  3 16:41:00 2016
@@ -4868,10 +4868,11 @@ int ASTContext::getIntegerTypeOrder(Qual
   return 1;
 }
 
-// getCFConstantStringType - Return the type used for constant CFStrings.
-QualType ASTContext::getCFConstantStringType() const {
+TagDecl *ASTContext::getCFConstantStringDecl() const {
   if (!CFConstantStringTypeDecl) {
-CFConstantStringTypeDecl = buildImplicitRecord("NSConstantString");
+// This type is designed to be compatible with NSConstantString, but cannot
+// use the same name, since NSConstantString is an interface.
+CFConstantStringTypeDecl = buildImplicitRecord("__NSConstantString");
 CFConstantStringTypeDecl->startDefinition();
 
 QualType FieldTypes[4];
@@ -4901,7 +4902,12 @@ QualType ASTContext::getCFConstantString
 CFConstantStringTypeDecl->completeDefinition();
   }
 
-  return getTagDeclType(CFConstantStringTypeDecl);
+  return CFConstantStringTypeDecl;
+}
+
+// getCFConstantStringType - Return the type used for constant 

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

[Anna Zaks via cfe-commits]

zaks.anna added inline comments.


Comment at: tools/clang/lib/StaticAnalyzer/Checkers/Checkers.td:75
@@ -74,1 +74,3 @@
 
+def MPI : Package<"mpi">;
+

Alexander_Droste wrote:
> zaks.anna wrote:
> > This should probably go under the 'option' package. What do you think?
> Do you mean the 'optin' package? I could not find an 'option' package in 
> `Checkers.td`.
Yes, 'option'. I think it got spell checked.


Comment at: 
tools/clang/lib/StaticAnalyzer/Checkers/MPI-Checker/MPIChecker.cpp:43
@@ +42,3 @@
+private:
+  const std::unique_ptr CheckerSens;
+

Alexander_Droste wrote:
> zaks.anna wrote:
> > I'd stress "path" instead of "sensitive" in the name. Also, this 
> > indirection is redundant if you remove the AST checks.
> If sufficient, I would rename `MPICheckerPathSensitive` to `MPICheckerPath` 
> then.
> Do you mind the indirection?
I indirection buying us anything? I think it makes the code more difficult to 
follow,


Comment at: 
tools/clang/lib/StaticAnalyzer/Checkers/MPI-Checker/MPICheckerPathSensitive.cpp:74
@@ +73,3 @@
+  // A wait has no matching nonblocking call.
+  BugReporter.reportUnmatchedWait(PreCallEvent, ReqRegion, ExplNode);
+}

Alexander_Droste wrote:
> zaks.anna wrote:
> > This is called in a loop. Should you break once the first error is reported?
> > 
> > Also, as before you should use the CheckerContext API to produce a node on 
> > which the error should be reported.
> > 
> > 
> I don't think break should be called after the first error is reported. Each 
> memory region
> represents a different request, why this should be rated as multiple errors. 
You might be right, I am not 100% sure what's more user-friendly..  Presumably 
the fixes are different in each case? Could you add a test case where multiple 
errors on the same call site are reported? (Ups can use expected-warning@+1 to 
report multiple warnings on the same line.)


Comment at: tools/clang/lib/StaticAnalyzer/Checkers/MPI-Checker/Utility.cpp:21
@@ +20,3 @@
+
+namespace util {
+

Alexander_Droste wrote:
> zaks.anna wrote:
> > I'd like to remove the Utility.cpp completely by either making the helper 
> > functions static or moving them to other shared components.
> So where shall we put `sourceRange()`? It is only used by the BugReporter 
> class.
> I could make it a member function of the Reporter class. Or would you prefer 
> this
> as a member function of `MemRegion`?
I don't see why we should't add it to MemRegion. Let's submit that as a 
separate patch. (If someone else has a better idea they'll tell us:))


http://reviews.llvm.org/D12761



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

Re: [PATCH] D15120: Add support for __float128 type to be used by targets that support it

[Richard Smith via cfe-commits]

rsmith added inline comments.


Comment at: include/clang/Driver/Options.td:1463
@@ +1462,3 @@
+Group;
+def mnofloat128 : Flag<["-"], "mno-float128">,
+Group;

Per the mangling rules at the top of this file, this should be named 
`mno_float128`.


Comment at: lib/CodeGen/ItaniumCXXABI.cpp:3357-3358
@@ -3355,4 +3356,4 @@
   getContext().FloatTy,getContext().DoubleTy,
   getContext().LongDoubleTy,   getContext().Char16Ty,
-  getContext().Char32Ty,
+  getContext().Char32Ty,   getContext().Float128Ty
   };

Please keep this in the same order as `TypeInfoIsInStandardLibrary` (put 
`Float128Ty` after `LongDoubleTy`).


Comment at: lib/Sema/SemaExpr.cpp:1156-1159
@@ +1155,6 @@
+
+  QualType LHSElemType = dyn_cast(LHSType) ?
+cast(LHSType)->getElementType() : LHSType;
+  QualType RHSElemType = dyn_cast(RHSType) ?
+cast(RHSType)->getElementType() : RHSType;
+

hubert.reinterpretcast wrote:
> The result of the `dyn_cast` can be saved instead of using `cast` after the 
> `dyn_cast`.
Do not use `dyn_cast` / `cast` on types, use `LHSType->getAs<...>()` / 
`LHSType->castAs<...>()` instead. This will do the wrong thing on sugared types 
(eg, a typedef for a complex type).


Comment at: lib/Sema/SemaExpr.cpp:1337
@@ -1303,1 +1336,3 @@
 
+  // Diagnose builtin types that have the same size and different 
representation
+  if (sameWidthDifferentRepresentation(*this, LHSType, RHSType))

Please indicate why you're diagnosing these here.


Comment at: lib/Sema/SemaExpr.cpp:1339
@@ +1338,3 @@
+  if (sameWidthDifferentRepresentation(*this, LHSType, RHSType))
+  return QualType();
+

Too much indentation.


Comment at: lib/Sema/SemaOverload.cpp:1655-1664
@@ -1654,2 +1654,12 @@
   } else if (FromType->isRealFloatingType() && ToType->isRealFloatingType()) {
+  // FIXME: disable conversions between long double and __float128 if
+  // their representation is different until there is back end support
+  if ((FromType) !=
+  (ToType)) {
+if ((FromType == S.Context.Float128Ty &&
+ ToType == S.Context.LongDoubleTy) ||
+(FromType == S.Context.LongDoubleTy &&
+ ToType == S.Context.Float128Ty))
+  return false;
+  }
 // Floating point conversions (C++ 4.8).

This is over-indented.


Repository:
  rL LLVM

http://reviews.llvm.org/D15120



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

Re: [PATCH] D15636: Reduce false positives in printf/scanf format checker

[Richard Trieu via cfe-commits]

rtrieu added a comment.

Oops, forget to hit send on my last comment.

My concern is something like:

  printf(condition ? "first message: %d" : "second message: %d", 5, 10);

There's nothing in the code implying that either message is the one that should 
be using two arguments, so which one will be highlighted?  At that point, we 
may need to consider rewriting the message to indicate that multiple format 
strings would be affected.


http://reviews.llvm.org/D15636



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

Re: [PATCH] D16700: [Clang-tidy] Make null pointer literals for fixes configurable for two checks

[Eugene Zelenko via cfe-commits]

Eugene.Zelenko added inline comments.


Comment at: clang-tidy/readability/ImplicitBoolCastCheck.h:32
@@ -30,1 +31,3 @@
+Options.get("NullPointerLiteral",
+Context->getLangOpts().CPlusPlus11 ? "nullptr" : "0")) {}
   void registerMatchers(ast_matchers::MatchFinder *Finder) override;

LegalizeAdulthood wrote:
> aaron.ballman wrote:
> > I know you are following the pattern used in the code here, but I think 
> > this class needs a storeOptions() function as well. See 
> > AssertSideEffectCheck as an example.
> This will need rebasing on the existing code, which is using "NULL" as the 
> pre-C++11 fallback default, not "0".
This was in original code. I just didn't want to change default.


Comment at: clang-tidy/readability/SimplifyBooleanExprCheck.cpp:175
@@ -174,2 +174,3 @@
 
-std::string replacementExpression(const MatchFinder::MatchResult ,
+std::string replacementExpression(SimplifyBooleanExprCheck *Check,
+  const MatchFinder::MatchResult ,

LegalizeAdulthood wrote:
> aaron.ballman wrote:
> > Check can be a const pointer.
> Passing the check in here is overkill.  This helper function isn't going to 
> ever be used for multiple checks and the only thing you ever do with the 
> check is get the nullptr literal, so just pass in the thing it needs directly.
> 
> This will also need to be rebased onto the current code.
I had same idea, but I'm waiting for global options implementation to make 
other changes,


Comment at: docs/clang-tidy/checks/readability-simplify-boolean-expr.rst:79-81
@@ -78,1 +78,4 @@
 
+Null pointer literal for fixes could be changed with option
+``NullPointerLiteral``. The default value for C++11 or later is ``nullptr``, 
for
+ C++98/C++03 - ``0``.

LegalizeAdulthood wrote:
> The wording here is awkward.  Instead, I suggest:
> 
> ```
> The option ``NullPointerLiteral`` configures the text used for comparisons of 
> pointers
> against zero to synthesize boolean expressions.  The default value for C++11 
> or later
> is ``nullptr``, otherwise the value is ``NULL``.
> ```
> 
> It's subjective, but my experience is that pre C++11 code bases prefer `NULL` 
> over `0`.
English is not my native language, so help is welcomed.


Repository:
  rL LLVM

http://reviews.llvm.org/D16700



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

Re: [PATCH] D16259: Add clang-tidy readability-redundant-control-flow check

[Richard via cfe-commits]

In article 

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

[Duncan P. N. Exon Smith via cfe-commits]

Hans, do you mind merging this to the 3.8 branch?

Marshall, do you agree this is okay to take?

> On 2016-Feb-03, at 11:30, Duncan P. N. Exon Smith via cfe-commits 
>  wrote:
> 
> Author: dexonsmith
> Date: Wed Feb  3 13:30:20 2016
> New Revision: 259682
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=259682=rev
> Log:
> re.results.form: Format out-of-range subexpression references as null
> 
> Rather than crashing in match_results::format() when a reference to a
> marked subexpression is out of range, format the subexpression as empty
> (i.e., replace it with an empty string).  Note that
> match_results::operator[]() has a range-check and returns a null match
> in this case, so this just re-uses that logic.
> 
> Modified:
>libcxx/trunk/include/regex
>libcxx/trunk/test/std/re/re.results/re.results.form/form1.pass.cpp
> 
> Modified: libcxx/trunk/include/regex
> URL: 
> http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/regex?rev=259682=259681=259682=diff
> ==
> --- libcxx/trunk/include/regex (original)
> +++ libcxx/trunk/include/regex Wed Feb  3 13:30:20 2016
> @@ -5387,8 +5387,8 @@ match_results<_BidirectionalIterator, _A
> if ('0' <= *__fmt_first && *__fmt_first <= '9')
> {
> size_t __i = *__fmt_first - '0';
> -__out = _VSTD::copy(__matches_[__i].first,
> -   __matches_[__i].second, __out);
> +__out = _VSTD::copy((*this)[__i].first,
> +(*this)[__i].second, __out);
> }
> else
> {
> @@ -5439,8 +5439,8 @@ match_results<_BidirectionalIterator, _A
> ++__fmt_first;
> __i = 10 * __i + *__fmt_first - '0';
> }
> -__out = _VSTD::copy(__matches_[__i].first,
> -   __matches_[__i].second, __out);
> +__out = _VSTD::copy((*this)[__i].first,
> +(*this)[__i].second, __out);
> }
> else
> {
> 
> Modified: libcxx/trunk/test/std/re/re.results/re.results.form/form1.pass.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/re/re.results/re.results.form/form1.pass.cpp?rev=259682=259681=259682=diff
> ==
> --- libcxx/trunk/test/std/re/re.results/re.results.form/form1.pass.cpp 
> (original)
> +++ libcxx/trunk/test/std/re/re.results/re.results.form/form1.pass.cpp Wed 
> Feb  3 13:30:20 2016
> @@ -38,6 +38,31 @@ int main()
> {
> std::match_results m;
> const char s[] = "abcdefghijk";
> +assert(std::regex_search(s, m, std::regex("cd((e)fg)hi",
> +  
> std::regex_constants::nosubs)));
> +
> +char out[100] = {0};
> +const char fmt[] = "prefix: $`, match: $&, suffix: $', m[1]: $1, 
> m[2]: $2";
> +char* r = m.format(output_iterator(out),
> +fmt, fmt + std::char_traits::length(fmt)).base();
> +assert(r == out + 54);
> +assert(std::string(out) == "prefix: ab, match: cdefghi, suffix: jk, 
> m[1]: , m[2]: ");
> +}
> +{
> +std::match_results m;
> +const char s[] = "abcdefghijk";
> +assert(std::regex_search(s, m, std::regex("cdefghi")));
> +
> +char out[100] = {0};
> +const char fmt[] = "prefix: $`, match: $&, suffix: $', m[1]: $1, 
> m[2]: $2";
> +char* r = m.format(output_iterator(out),
> +fmt, fmt + std::char_traits::length(fmt)).base();
> +assert(r == out + 54);
> +assert(std::string(out) == "prefix: ab, match: cdefghi, suffix: jk, 
> m[1]: , m[2]: ");
> +}
> +{
> +std::match_results m;
> +const char s[] = "abcdefghijk";
> assert(std::regex_search(s, m, std::regex("cd((e)fg)hi")));
> 
> char out[100] = {0};
> @@ -61,6 +86,33 @@ int main()
> assert(r == out + 34);
> assert(std::string(out) == "match: cdefghi, m[1]: efg, m[2]: e");
> }
> +{
> +std::match_results m;
> +const char s[] = "abcdefghijk";
> +assert(std::regex_search(s, m, std::regex("cd((e)fg)hi",
> +  
> std::regex_constants::nosubs)));
> +
> +char out[100] = {0};
> +const char fmt[] = "match: &, m[1]: \\1, m[2]: \\2";
> +char* r = m.format(output_iterator(out),
> +fmt, fmt + std::char_traits::length(fmt),
> +std::regex_constants::format_sed).base();
> +assert(r == out + 30);
> +assert(std::string(out) == "match: cdefghi, m[1]: , 

Re: [PATCH] D16738: Fix invalid casts in .

[Evgeniy Stepanov via cfe-commits]

eugenis updated this revision to Diff 46857.
eugenis added a comment.

How about this?


Repository:
  rL LLVM

http://reviews.llvm.org/D16738

Files:
  include/__config
  include/functional

Index: include/functional
===
--- include/functional
+++ include/functional
@@ -1564,6 +1564,10 @@
 typename aligned_storage<3*sizeof(void*)>::type __buf_;
 __base* __f_;
 
+_LIBCPP_NO_CFI static __base *__as_base(void *p) {
+  return reinterpret_cast<__base*>(p);
+}
+
 template ::value &&
 __invokable<_Fp&, _ArgTypes...>::value>
 struct __callable;
@@ -1662,7 +1666,7 @@
 __f_ = 0;
 else if (__f.__f_ == (const __base*)&__f.__buf_)
 {
-__f_ = (__base*)&__buf_;
+__f_ = __as_base(&__buf_);
 __f.__f_->__clone(__f_);
 }
 else
@@ -1678,7 +1682,7 @@
 __f_ = 0;
 else if (__f.__f_ == (const __base*)&__f.__buf_)
 {
-__f_ = (__base*)&__buf_;
+__f_ = __as_base(&__buf_);
 __f.__f_->__clone(__f_);
 }
 else
@@ -1690,9 +1694,9 @@
 {
 if (__f.__f_ == 0)
 __f_ = 0;
-else if (__f.__f_ == (__base*)&__f.__buf_)
+else if (__f.__f_ == __as_base(&__f.__buf_))
 {
-__f_ = (__base*)&__buf_;
+__f_ = __as_base(&__buf_);
 __f.__f_->__clone(__f_);
 }
 else
@@ -1709,9 +1713,9 @@
 {
 if (__f.__f_ == 0)
 __f_ = 0;
-else if (__f.__f_ == (__base*)&__f.__buf_)
+else if (__f.__f_ == __as_base(&__f.__buf_))
 {
-__f_ = (__base*)&__buf_;
+__f_ = __as_base(&__buf_);
 __f.__f_->__clone(__f_);
 }
 else
@@ -1736,8 +1740,7 @@
 typedef __function::__func<_Fp, allocator<_Fp>, _Rp(_ArgTypes...)> _FF;
 if (sizeof(_FF) <= sizeof(__buf_) && is_nothrow_copy_constructible<_Fp>::value)
 {
-__f_ = (__base*)&__buf_;
-::new (__f_) _FF(_VSTD::move(__f));
+__f_ = ::new((void*)&__buf_) _FF(_VSTD::move(__f));
 }
 else
 {
@@ -1766,8 +1769,7 @@
 if (sizeof(_FF) <= sizeof(__buf_) && 
 is_nothrow_copy_constructible<_Fp>::value && is_nothrow_copy_constructible<_Ap>::value)
 {
-__f_ = (__base*)&__buf_;
-::new (__f_) _FF(_VSTD::move(__f), _Alloc(__a));
+__f_ = ::new((void*)&__buf_) _FF(_VSTD::move(__f), _Alloc(__a));
 }
 else
 {
@@ -1791,16 +1793,16 @@
 function<_Rp(_ArgTypes...)>&
 function<_Rp(_ArgTypes...)>::operator=(function&& __f) _NOEXCEPT
 {
-if (__f_ == (__base*)&__buf_)
+if (__f_ == __as_base(&__buf_))
 __f_->destroy();
 else if (__f_)
 __f_->destroy_deallocate();
 __f_ = 0;
 if (__f.__f_ == 0)
 __f_ = 0;
-else if (__f.__f_ == (__base*)&__f.__buf_)
+else if (__f.__f_ == __as_base(&__f.__buf_))
 {
-__f_ = (__base*)&__buf_;
+__f_ = __as_base(&__buf_);
 __f.__f_->__clone(__f_);
 }
 else
@@ -1815,7 +1817,7 @@
 function<_Rp(_ArgTypes...)>&
 function<_Rp(_ArgTypes...)>::operator=(nullptr_t) _NOEXCEPT
 {
-if (__f_ == (__base*)&__buf_)
+if (__f_ == __as_base(&__buf_))
 __f_->destroy();
 else if (__f_)
 __f_->destroy_deallocate();
@@ -1840,7 +1842,7 @@
 template
 function<_Rp(_ArgTypes...)>::~function()
 {
-if (__f_ == (__base*)&__buf_)
+if (__f_ == __as_base(&__buf_))
 __f_->destroy();
 else if (__f_)
 __f_->destroy_deallocate();
@@ -1850,34 +1852,34 @@
 void
 function<_Rp(_ArgTypes...)>::swap(function& __f) _NOEXCEPT
 {
-if (__f_ == (__base*)&__buf_ && __f.__f_ == (__base*)&__f.__buf_)
+if (__f_ == __as_base(&__buf_) && __f.__f_ == __as_base(&__f.__buf_))
 {
 typename aligned_storage::type __tempbuf;
-__base* __t = (__base*)&__tempbuf;
+__base* __t = __as_base(&__tempbuf);
 __f_->__clone(__t);
 __f_->destroy();
 __f_ = 0;
-__f.__f_->__clone((__base*)&__buf_);
+__f.__f_->__clone(__as_base(&__buf_));
 __f.__f_->destroy();
 __f.__f_ = 0;
-__f_ = (__base*)&__buf_;
-__t->__clone((__base*)&__f.__buf_);
+__f_ = __as_base(&__buf_);
+__t->__clone(__as_base(&__f.__buf_));
 __t->destroy();
-__f.__f_ = (__base*)&__f.__buf_;
+__f.__f_ = __as_base(&__f.__buf_);
 }
-else if (__f_ == (__base*)&__buf_)
+else if (__f_ == __as_base(&__buf_))
 {
-__f_->__clone((__base*)&__f.__buf_);
+__f_->__clone(__as_base(&__f.__buf_));
 __f_->destroy();
 __f_ = __f.__f_;
-__f.__f_ = (__base*)&__f.__buf_;
+__f.__f_ = __as_base(&__f.__buf_);
 }
-else if (__f.__f_ == (__base*)&__f.__buf_)
+else if (__f.__f_ == __as_base(&__f.__buf_))
 {
-__f.__f_->__clone((__base*)&__buf_);
+__f.__f_->__clone(__as_base(&__buf_));
 

[PATCH] D16873: Refactor MemRegionManager::getVarRegion to call two new functions, improving readability

[Alexander Riccio via cfe-commits]

ariccio created this revision.
ariccio added reviewers: aaron.ballman, dcoughlin.
ariccio added a subscriber: cfe-commits.

Instead of one long function, `MemRegionManager::getVarRegion` now calls 
`getMemRegionGloballyStored` for global, non-static variables, and 
`getMemRegionStaticLocal` for static locals. The behavior of 
`MemRegionManager::getVarRegion` is thus clearer, and easier to reason about.



http://reviews.llvm.org/D16873

Files:
  llvm/tools/clang/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h
  llvm/tools/clang/lib/StaticAnalyzer/Core/MemRegion.cpp

Index: llvm/tools/clang/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h
===
--- llvm/tools/clang/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h
+++ llvm/tools/clang/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h
@@ -1180,6 +1180,16 @@
   ///  a specified VarDecl and LocationContext.
   const VarRegion* getVarRegion(const VarDecl *D, const LocationContext *LC);
 
+private:
+  /// getMemRegionGloballyStored - Retrieve or create the memory region
+  ///  associated with a specified globally stored, non-static local, VarDecl.
+  const MemRegion *getMemRegionGloballyStored(const VarDecl *D);
+
+  /// getMemRegionStaticLocal - Retrieve or create the memory region
+  ///  associated with a specified VarDecl and LocationContext.
+  const MemRegion *getMemRegionStaticLocal(const VarDecl *D, const LocationContext *LC);
+
+public:
   /// getVarRegion - Retrieve or create the memory region associated with
   ///  a specified VarDecl and super region.
   const VarRegion* getVarRegion(const VarDecl *D, const MemRegion *superR);
Index: llvm/tools/clang/lib/StaticAnalyzer/Core/MemRegion.cpp
===
--- llvm/tools/clang/lib/StaticAnalyzer/Core/MemRegion.cpp
+++ llvm/tools/clang/lib/StaticAnalyzer/Core/MemRegion.cpp
@@ -766,87 +766,89 @@
   return (const StackFrameContext *)nullptr;
 }
 
-const VarRegion* MemRegionManager::getVarRegion(const VarDecl *D,
-const LocationContext *LC) {
-  const MemRegion *sReg = nullptr;
+const MemRegion* MemRegionManager::getMemRegionGloballyStored(const VarDecl *D) {
+  assert(D->hasGlobalStorage());
+  assert(!D->isStaticLocal());
+  // First handle the globals defined in system headers.
+  if (C.getSourceManager().isInSystemHeader(D->getLocation())) {
+// Whitelist the system globals which often DO GET modified, assume the
+// rest are immutable.
+if (D->getName().find("errno") != StringRef::npos)
+  return getGlobalsRegion(MemRegion::GlobalSystemSpaceRegionKind);
 
-  if (D->hasGlobalStorage() && !D->isStaticLocal()) {
+return getGlobalsRegion(MemRegion::GlobalImmutableSpaceRegionKind);
+  }
+  // Treat other globals as GlobalInternal unless they are constants.
+  QualType GQT = D->getType();
+  const Type *GT = GQT.getTypePtrOrNull();
+  // TODO: We could walk the complex types here and see if everything is
+  // constified.
+  if (GT && GQT.isConstQualified() && GT->isArithmeticType())
+return getGlobalsRegion(MemRegion::GlobalImmutableSpaceRegionKind);
 
-// First handle the globals defined in system headers.
-if (C.getSourceManager().isInSystemHeader(D->getLocation())) {
-  // Whitelist the system globals which often DO GET modified, assume the
-  // rest are immutable.
-  if (D->getName().find("errno") != StringRef::npos)
-sReg = getGlobalsRegion(MemRegion::GlobalSystemSpaceRegionKind);
-  else
-sReg = getGlobalsRegion(MemRegion::GlobalImmutableSpaceRegionKind);
+  return getGlobalsRegion();
+}
 
-// Treat other globals as GlobalInternal unless they are constants.
-} else {
-  QualType GQT = D->getType();
-  const Type *GT = GQT.getTypePtrOrNull();
-  // TODO: We could walk the complex types here and see if everything is
-  // constified.
-  if (GT && GQT.isConstQualified() && GT->isArithmeticType())
-sReg = getGlobalsRegion(MemRegion::GlobalImmutableSpaceRegionKind);
-  else
-sReg = getGlobalsRegion();
-}
+const MemRegion* MemRegionManager::getMemRegionStaticLocal(const VarDecl *D, const LocationContext *LC) {
+  // FIXME: Once we implement scope handling, we will need to properly lookup
+  // 'D' to the proper LocationContext.
+  const DeclContext *DC = D->getDeclContext();
+  llvm::PointerUnion V =
+getStackOrCaptureRegionForDeclContext(LC, DC, D);
 
-  // Finally handle static locals.
-  } else {
-// FIXME: Once we implement scope handling, we will need to properly lookup
-// 'D' to the proper LocationContext.
-const DeclContext *DC = D->getDeclContext();
-llvm::PointerUnion V =
-  getStackOrCaptureRegionForDeclContext(LC, DC, D);
+  if (V.is())
+return V.get();
 
-if (V.is())
-  return V.get();
+  const StackFrameContext *STC = V.get();
 
-const 

Re: [PATCH] D13357: [Concepts] Diagnose when 'concept' is specified on a specialization

[Hubert Tong via cfe-commits]

hubert.reinterpretcast added a comment.

Minor comments; otherwise, LGTM.



Comment at: lib/Sema/SemaDecl.cpp:6007
@@ +6006,3 @@
+  // applied only to the definition of a [...] variable template, declared
+  // in namespace scope. [...] A concept definition refers to [...] a
+  // variable concept and its initializer.

We do not need to quote the second sentence here. The ellipsis in the first 
sentence should be expanded since the full list is necessary to conclude that 
the cases being diagnosed here are excluded.


Comment at: lib/Sema/SemaDecl.cpp:7754
@@ +7753,3 @@
+  // in namespace scope. [...] A concept definition refers to either a
+  // function concept and its definition [...].
+  if (isFunctionTemplateSpecialization) {

We do not need to quote the second sentence here. The ellipsis in the first 
sentence should be expanded since the full list is necessary to conclude that 
the cases being diagnosed here are excluded.


http://reviews.llvm.org/D13357



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

r259734 - Fix predefine for __NSConstantString struct type

[Ben Langmuir via cfe-commits]

Author: benlangmuir
Date: Wed Feb  3 18:55:24 2016
New Revision: 259734

URL: http://llvm.org/viewvc/llvm-project?rev=259734=rev
Log:
Fix predefine for __NSConstantString struct type

Per review feedback the name was wrong and it can be used outside
Objective-C.

Unfortunately, making the internal struct visible broke some ASTMatchers
tests that assumed that the first record decl would be from user code,
rather than a builtin type.  I'm worried that this will also affect
users' code.  So this patch adds a typedef to wrap the internal struct
and only makes the typedef visible to namelookup.  This is sufficient to
allow the ASTReader to merge the decls we need without making the struct
itself visible.

rdar://problem/24425801

Modified:
cfe/trunk/include/clang/AST/ASTContext.h
cfe/trunk/include/clang/Serialization/ASTBitCodes.h
cfe/trunk/lib/AST/ASTContext.cpp
cfe/trunk/lib/Sema/Sema.cpp
cfe/trunk/lib/Serialization/ASTReader.cpp
cfe/trunk/lib/Serialization/ASTWriter.cpp
cfe/trunk/test/CodeGenObjC/2010-02-01-utf16-with-null.m
cfe/trunk/test/CodeGenObjC/arc-no-arc-exceptions.m
cfe/trunk/test/CodeGenObjC/tentative-cfconstantstring.m
cfe/trunk/test/Modules/Inputs/builtin.h
cfe/trunk/test/Modules/builtins.m

Modified: cfe/trunk/include/clang/AST/ASTContext.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/ASTContext.h?rev=259734=259733=259734=diff
==
--- cfe/trunk/include/clang/AST/ASTContext.h (original)
+++ cfe/trunk/include/clang/AST/ASTContext.h Wed Feb  3 18:55:24 2016
@@ -253,8 +253,9 @@ class ASTContext : public RefCountedBase
   mutable IdentifierInfo *MakeIntegerSeqName = nullptr;
 
   QualType ObjCConstantStringType;
-  mutable RecordDecl *CFConstantStringTypeDecl;
-  
+  mutable RecordDecl *CFConstantStringTagDecl;
+  mutable TypedefDecl *CFConstantStringTypeDecl;
+
   mutable QualType ObjCSuperType;
   
   QualType ObjCNSStringType;
@@ -1381,11 +1382,12 @@ public:
   /// if it hasn't yet been built.
   QualType getRawCFConstantStringType() const {
 if (CFConstantStringTypeDecl)
-  return getTagDeclType(CFConstantStringTypeDecl);
+  return getTypedefType(CFConstantStringTypeDecl);
 return QualType();
   }
   void setCFConstantStringType(QualType T);
-  TagDecl *getCFConstantStringDecl() const;
+  TypedefDecl *getCFConstantStringDecl() const;
+  RecordDecl *getCFConstantStringTagDecl() const;
 
   // This setter/getter represents the ObjC type for an NSConstantString.
   void setObjCConstantStringInterface(ObjCInterfaceDecl *Decl);

Modified: cfe/trunk/include/clang/Serialization/ASTBitCodes.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Serialization/ASTBitCodes.h?rev=259734=259733=259734=diff
==
--- cfe/trunk/include/clang/Serialization/ASTBitCodes.h (original)
+++ cfe/trunk/include/clang/Serialization/ASTBitCodes.h Wed Feb  3 18:55:24 2016
@@ -988,15 +988,18 @@ namespace clang {
   /// \brief The internal '__make_integer_seq' template.
   PREDEF_DECL_MAKE_INTEGER_SEQ_ID = 13,
 
-  /// \brief The internal '__NSConstantString' type.
+  /// \brief The internal '__NSConstantString' typedef.
   PREDEF_DECL_CF_CONSTANT_STRING_ID = 14,
+
+  /// \brief The internal '__NSConstantString' tag type.
+  PREDEF_DECL_CF_CONSTANT_STRING_TAG_ID = 15,
 };
 
 /// \brief The number of declaration IDs that are predefined.
 ///
 /// For more information about predefined declarations, see the
 /// \c PredefinedDeclIDs type and the PREDEF_DECL_*_ID constants.
-const unsigned int NUM_PREDEF_DECL_IDS = 15;
+const unsigned int NUM_PREDEF_DECL_IDS = 16;
 
 /// \brief Record code for a list of local redeclarations of a declaration.
 const unsigned int LOCAL_REDECLARATIONS = 50;

Modified: cfe/trunk/lib/AST/ASTContext.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ASTContext.cpp?rev=259734=259733=259734=diff
==
--- cfe/trunk/lib/AST/ASTContext.cpp (original)
+++ cfe/trunk/lib/AST/ASTContext.cpp Wed Feb  3 18:55:24 2016
@@ -738,12 +738,13 @@ ASTContext::ASTContext(LangOptions 
   BuiltinVaListDecl(nullptr), BuiltinMSVaListDecl(nullptr),
   ObjCIdDecl(nullptr), ObjCSelDecl(nullptr), ObjCClassDecl(nullptr),
   ObjCProtocolClassDecl(nullptr), BOOLDecl(nullptr),
-  CFConstantStringTypeDecl(nullptr), ObjCInstanceTypeDecl(nullptr),
-  FILEDecl(nullptr), jmp_bufDecl(nullptr), sigjmp_bufDecl(nullptr),
-  ucontext_tDecl(nullptr), BlockDescriptorType(nullptr),
-  BlockDescriptorExtendedType(nullptr), cudaConfigureCallDecl(nullptr),
-  FirstLocalImport(), LastLocalImport(), ExternCContext(nullptr),
-  MakeIntegerSeqDecl(nullptr), SourceMgr(SM), LangOpts(LOpts),
+  CFConstantStringTagDecl(nullptr), 

Re: [PATCH] D16692: [OpenCL] Eliminate warning when declaring OpenCL builtin functions

[Xiuli PAN via cfe-commits]

pxli168 added a comment.

I see you have committed this patch, you can try to follow the guide here:
http://llvm.org/docs/Phabricator.html#committing-a-change
To add something in your commit and then the system will automatic close the 
diff and have link to the commmit.
This will help others to find the review process and easy to track the commit.
Or you can just use the arc tool to make the commit automatically.
Thanks
Xiuli


http://reviews.llvm.org/D16692



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

Re: [PATCH] D16870: [CUDA] Tweak attribute-based overload resolution to match nvcc behavior.

[Jingyue Wu via cfe-commits]

jingyue added inline comments.


Comment at: include/clang/Sema/Sema.h:8801
@@ -8798,3 +8800,3 @@
 // LangOpts.CUDADisableTargetCallChecks is true.
-CFP_Fallback,   // Low priority caller/callee combination
-CFP_Best,   // Preferred caller/callee combination
+CFP_SameSide,   // Calls from host-device to host or device
+// function matching current compilation mode.

Why not merging CFP_SameSide and CFP_Native? You can conceptually treat HD as H 
in host mode or D in device mode. Then, it seems that we can just reuse 
CFP_Native to express the same meaning. 


http://reviews.llvm.org/D16870



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

Re: [PATCH] D16870: [CUDA] Tweak attribute-based overload resolution to match nvcc behavior.

[Artem Belevich via cfe-commits]

tra added a comment.

When overload set contains h and HD functions that are otherwise equal for
overload resolution, you want to be able to tell which one is better.


http://reviews.llvm.org/D16870



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

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

[Xiuli PAN via cfe-commits]

pxli168 added inline comments.


Comment at: lib/CodeGen/CGLoopInfo.cpp:131
@@ +130,3 @@
+// equivalent LoopHintAttr enums.
+// See OpenCL v2.0 s6.11.5 for details.
+// 0 corresponds to opencl_unroll_hint attribute without

Can you also change this comment to the style that reference go first then 
summary.


Comment at: lib/Sema/SemaStmtAttr.cpp:224
@@ +223,3 @@
+Expr *E = A.getArgAsExpr(0);
+assert(E != nullptr && "Invalid opencl_unroll_hint argument");
+llvm::APSInt ArgVal(32);

Should this assert be here?
Can it be something else?
And you shuold just use assert(E && ).


Comment at: test/SemaOpenCL/unroll-hint.cl:1
@@ +1,2 @@
+//RUN: %clang_cc1 -O0 -cl-std=CL2.0 -fsyntax-only -verify %s
+

What will happen if using OpenCL 1.2 or 1.1 that earlier than 2.0?
You can also make a test for it, and can change this test case to 
unroll-hint-cl2.0.cl
as you can see other cl2.0 features in the folder.


http://reviews.llvm.org/D16686



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

Re: r259624 - Make CF constant string decl visible to name lookup to fix module errors

[Ben Langmuir via cfe-commits]

Hey Doug,

I fixed this in r259734; could you take a glance at that patch too?

As I mentioned in person it required more changes than just moving this 
definition outside the if/fixing the name.

Thanks,

Ben

> On Feb 3, 2016, at 11:50 AM, Ben Langmuir via cfe-commits 
>  wrote:
> 
> 
>> On Feb 3, 2016, at 11:45 AM, Douglas Gregor > > wrote:
>> 
>>> 
>>> On Feb 2, 2016, at 7:26 PM, Ben Langmuir via cfe-commits 
>>> > wrote:
>>> 
>>> Author: benlangmuir
>>> Date: Tue Feb  2 21:26:19 2016
>>> New Revision: 259624
>>> 
>>> URL: http://llvm.org/viewvc/llvm-project?rev=259624=rev 
>>> 
>>> Log:
>>> Make CF constant string decl visible to name lookup to fix module errors
>>> 
>>> The return type of the __builtin___*StringMakeConstantString functions
>>> is a pointer to a struct, so we need that struct to be visible to name
>>> lookup so that we will correctly merge multiple declarations of that
>>> type if they come from different modules.
>>> 
>>> Incidentally, to make this visible to name lookup we need to rename the
>>> type to __NSConstantString, since the real NSConstantString is an
>>> Objective-C interface type.  This shouldn't affect anyone outside the
>>> compiler since users of the constant string builtins cast the result
>>> immediately to CFStringRef.
>>> 
>>> Since this struct type is otherwise implicitly created by the AST
>>> context and cannot access namelookup, we make this a predefined type
>>> and initialize it in Sema.
>>> 
>>> Note: this issue of builtins that refer to types not visible to name
>>> lookup technically also affects other builtins (e.g. objc_msgSendSuper),
>>> but in all other cases the builtin is a library builtin and the issue
>>> goes away if you include the library that defines the types it uses,
>>> unlike for these constant string builtins.
>>> 
>>> rdar://problem/24425801 
>> 
>> Two comments below…
>> 
>>> [snip]
>>> 
>>> Modified: cfe/trunk/lib/Sema/Sema.cpp
>>> URL: 
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/Sema.cpp?rev=259624=259623=259624=diff
>>>  
>>> 
>>> ==
>>> --- cfe/trunk/lib/Sema/Sema.cpp (original)
>>> +++ cfe/trunk/lib/Sema/Sema.cpp Tue Feb  2 21:26:19 2016
>>> @@ -189,6 +189,10 @@ void Sema::Initialize() {
>>>DeclarationName Protocol = ("Protocol");
>>>if (IdResolver.begin(Protocol) == IdResolver.end())
>>>  PushOnScopeChains(Context.getObjCProtocolDecl(), TUScope);
>>> +
>>> +DeclarationName ConstantString = 
>>> ("NSConstantString");
>>> +if (IdResolver.begin(ConstantString) == IdResolver.end())
>>> +  PushOnScopeChains(Context.getCFConstantStringDecl(), TUScope);
>> 
>> Shouldn’t this be looking for __NSConstantString?
> 
> D’oh.
> 
>> 
>> Also, isn’t CFSTR available even in C? This code path is Objective-C-only...
> 
> Yes on both counts, will fix, thanks!
> 
> ___
> 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: [libcxx] r259682 - re.results.form: Format out-of-range subexpression references as null

[Hans Wennborg via cfe-commits]

I'm OK if Marshall is.

Thanks,
Hans

On Wed, Feb 3, 2016 at 4:59 PM, Duncan P. N. Exon Smith via
cfe-commits  wrote:
> Hans, do you mind merging this to the 3.8 branch?
>
> Marshall, do you agree this is okay to take?
>
>> On 2016-Feb-03, at 11:30, Duncan P. N. Exon Smith via cfe-commits 
>>  wrote:
>>
>> Author: dexonsmith
>> Date: Wed Feb  3 13:30:20 2016
>> New Revision: 259682
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=259682=rev
>> Log:
>> re.results.form: Format out-of-range subexpression references as null
>>
>> Rather than crashing in match_results::format() when a reference to a
>> marked subexpression is out of range, format the subexpression as empty
>> (i.e., replace it with an empty string).  Note that
>> match_results::operator[]() has a range-check and returns a null match
>> in this case, so this just re-uses that logic.
>>
>> Modified:
>>libcxx/trunk/include/regex
>>libcxx/trunk/test/std/re/re.results/re.results.form/form1.pass.cpp
>>
>> Modified: libcxx/trunk/include/regex
>> URL: 
>> http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/regex?rev=259682=259681=259682=diff
>> ==
>> --- libcxx/trunk/include/regex (original)
>> +++ libcxx/trunk/include/regex Wed Feb  3 13:30:20 2016
>> @@ -5387,8 +5387,8 @@ match_results<_BidirectionalIterator, _A
>> if ('0' <= *__fmt_first && *__fmt_first <= '9')
>> {
>> size_t __i = *__fmt_first - '0';
>> -__out = _VSTD::copy(__matches_[__i].first,
>> -   __matches_[__i].second, __out);
>> +__out = _VSTD::copy((*this)[__i].first,
>> +(*this)[__i].second, __out);
>> }
>> else
>> {
>> @@ -5439,8 +5439,8 @@ match_results<_BidirectionalIterator, _A
>> ++__fmt_first;
>> __i = 10 * __i + *__fmt_first - '0';
>> }
>> -__out = _VSTD::copy(__matches_[__i].first,
>> -   __matches_[__i].second, __out);
>> +__out = _VSTD::copy((*this)[__i].first,
>> +(*this)[__i].second, __out);
>> }
>> else
>> {
>>
>> Modified: libcxx/trunk/test/std/re/re.results/re.results.form/form1.pass.cpp
>> URL: 
>> http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/re/re.results/re.results.form/form1.pass.cpp?rev=259682=259681=259682=diff
>> ==
>> --- libcxx/trunk/test/std/re/re.results/re.results.form/form1.pass.cpp 
>> (original)
>> +++ libcxx/trunk/test/std/re/re.results/re.results.form/form1.pass.cpp Wed 
>> Feb  3 13:30:20 2016
>> @@ -38,6 +38,31 @@ int main()
>> {
>> std::match_results m;
>> const char s[] = "abcdefghijk";
>> +assert(std::regex_search(s, m, std::regex("cd((e)fg)hi",
>> +  
>> std::regex_constants::nosubs)));
>> +
>> +char out[100] = {0};
>> +const char fmt[] = "prefix: $`, match: $&, suffix: $', m[1]: $1, 
>> m[2]: $2";
>> +char* r = m.format(output_iterator(out),
>> +fmt, fmt + std::char_traits::length(fmt)).base();
>> +assert(r == out + 54);
>> +assert(std::string(out) == "prefix: ab, match: cdefghi, suffix: jk, 
>> m[1]: , m[2]: ");
>> +}
>> +{
>> +std::match_results m;
>> +const char s[] = "abcdefghijk";
>> +assert(std::regex_search(s, m, std::regex("cdefghi")));
>> +
>> +char out[100] = {0};
>> +const char fmt[] = "prefix: $`, match: $&, suffix: $', m[1]: $1, 
>> m[2]: $2";
>> +char* r = m.format(output_iterator(out),
>> +fmt, fmt + std::char_traits::length(fmt)).base();
>> +assert(r == out + 54);
>> +assert(std::string(out) == "prefix: ab, match: cdefghi, suffix: jk, 
>> m[1]: , m[2]: ");
>> +}
>> +{
>> +std::match_results m;
>> +const char s[] = "abcdefghijk";
>> assert(std::regex_search(s, m, std::regex("cd((e)fg)hi")));
>>
>> char out[100] = {0};
>> @@ -61,6 +86,33 @@ int main()
>> assert(r == out + 34);
>> assert(std::string(out) == "match: cdefghi, m[1]: efg, m[2]: e");
>> }
>> +{
>> +std::match_results m;
>> +const char s[] = "abcdefghijk";
>> +assert(std::regex_search(s, m, std::regex("cd((e)fg)hi",
>> +  
>> std::regex_constants::nosubs)));
>> +
>> +char out[100] = {0};
>> +const char fmt[] = "match: &, m[1]: \\1, m[2]: \\2";
>> +char* r = 

Re: [PATCH] D13357: [Concepts] Diagnose when 'concept' is specified on a specialization

[Nathan Wilson via cfe-commits]

nwilson updated this revision to Diff 46854.
nwilson added a comment.

- This update removes the parameter in `TemplateDecl::setConcept` since there 
isn't a need to mark a concept false.


http://reviews.llvm.org/D13357

Files:
  include/clang/AST/DeclTemplate.h
  include/clang/Basic/DiagnosticSemaKinds.td
  lib/Sema/SemaDecl.cpp
  lib/Sema/SemaTemplate.cpp
  test/CXX/concepts-ts/dcl.dcl/dcl.spec/dcl.spec.concept/p1.cpp

Index: test/CXX/concepts-ts/dcl.dcl/dcl.spec/dcl.spec.concept/p1.cpp
===
--- test/CXX/concepts-ts/dcl.dcl/dcl.spec/dcl.spec.concept/p1.cpp
+++ test/CXX/concepts-ts/dcl.dcl/dcl.spec/dcl.spec.concept/p1.cpp
@@ -41,3 +41,20 @@
 void fpc(concept int i) {} // expected-error {{'concept' can only appear on the definition of a function template or variable template}}
 
 concept bool; // expected-error {{'concept' can only appear on the definition of a function template or variable template}}
+
+template  concept bool VCEI{ true };
+template concept bool VCEI; // expected-error {{'concept' cannot be applied on an explicit instantiation}}
+extern template concept bool VCEI; // expected-error {{'concept' cannot be applied on an explicit instantiation}}
+
+template  concept bool VCPS{ true };
+template  concept bool VCPS{ true }; // expected-error {{'concept' cannot be applied on an partial specialization}}
+
+template  concept bool VCES{ true };
+template <> concept bool VCES{ true }; // expected-error {{'concept' cannot be applied on an explicit specialization}}
+
+template  concept bool FCEI() { return true; }
+template concept bool FCEI(); // expected-error {{'concept' cannot be applied on an explicit instantiation}}
+extern template concept bool FCEI(); // expected-error {{'concept' cannot be applied on an explicit instantiation}}
+
+template  concept bool FCES() { return true; }
+template <> concept bool FCES() { return true; } // expected-error {{'concept' cannot be applied on an explicit specialization}}
Index: lib/Sema/SemaTemplate.cpp
===
--- lib/Sema/SemaTemplate.cpp
+++ lib/Sema/SemaTemplate.cpp
@@ -7673,6 +7673,15 @@
 Diag(D.getDeclSpec().getConstexprSpecLoc(),
  diag::err_explicit_instantiation_constexpr);
 
+  // C++ Concepts TS [dcl.spec.concept]p1: The concept specifier shall be
+  // applied only to the definition of a function template or variable template,
+  // declared in namespace scope.
+  if (D.getDeclSpec().isConceptSpecified()) {
+Diag(D.getDeclSpec().getConceptSpecLoc(),
+ diag::err_concept_specified_specialization) << 0;
+return true;
+  }
+
   // C++0x [temp.explicit]p2:
   //   There are two forms of explicit instantiation: an explicit instantiation
   //   definition and an explicit instantiation declaration. An explicit
Index: lib/Sema/SemaDecl.cpp
===
--- lib/Sema/SemaDecl.cpp
+++ lib/Sema/SemaDecl.cpp
@@ -6002,6 +6002,16 @@
 NewVD->setInvalidDecl(true);
   }
 
+  // C++ Concepts TS [dcl.spec.concept]p1: The concept specifier shall be
+  // applied only to the definition of a [...] variable template, declared
+  // in namespace scope. [...] A concept definition refers to [...] a
+  // variable concept and its initializer.
+  if (IsVariableTemplateSpecialization) {
+Diag(D.getDeclSpec().getConceptSpecLoc(),
+ diag::err_concept_specified_specialization)
+<< (IsPartialSpecialization ? 2 : 1);
+  }
+
   // C++ Concepts TS [dcl.spec.concept]p6: A variable concept has the
   // following restrictions:
   // - The declared type shall have the type bool.
@@ -7667,6 +7677,10 @@
 }
 
 if (isConcept) {
+  // This is a function concept.
+  if (FunctionTemplateDecl *FTD = NewFD->getDescribedFunctionTemplate())
+FTD->setConcept();
+
   // C++ Concepts TS [dcl.spec.concept]p1: The concept specifier shall be
   // applied only to the definition of a function template [...]
   if (!D.isFunctionDefinition()) {
@@ -7733,6 +7747,15 @@
 << 1 << 3;
 NewFD->setInvalidDecl(true);
   }
+
+  // C++ Concepts TS [dcl.spec.concept]p1: The concept specifier shall be
+  // applied only to the definition of a function template [...], declared
+  // in namespace scope. [...] A concept definition refers to either a
+  // function concept and its definition [...].
+  if (isFunctionTemplateSpecialization) {
+Diag(D.getDeclSpec().getConceptSpecLoc(),
+ diag::err_concept_specified_specialization) << 1;
+  }
 }
 
 // If __module_private__ was specified, mark the function accordingly.
@@ -7994,9 +8017,9 @@
  TemplateId->NumArgs);
   translateTemplateArguments(TemplateArgsPtr,
  TemplateArgs);
-
+
   

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

[Alexander Kornienko via cfe-commits]

alexfh added a comment.

Sorry for the delay. A few more comments.



Comment at: clang-tidy/google/GlobalNamesInHeadersCheck.cpp:30
@@ +29,3 @@
+  RawStringHeaderFileExtensions, HeaderFileExtensions)) {
+llvm::errs() << "Invalid header file extension: "
+ << RawStringHeaderFileExtensions << "\n";

That's not the best way to report errors, especially, when clang-tidy is used 
as a library. There are multiple possibilities, e.g. add a callback to 
`ClangTidyContext` (or a method to `ClangTidyCheck`) to report a problem with 
configuration, or move to two-stage initialization of checks, or something 
similar. No need to change this now, but please add a FIXME to find a more 
suitable way to handle invalid configuration options.


Comment at: clang-tidy/google/GlobalNamesInHeadersCheck.cpp:59
@@ -45,1 +58,3 @@
+if (!header_file_extensions_utils::isSpellingLocInHeaderFile(
+D->getLocStart(), *(Result.SourceManager), HeaderFileExtensions))
   return;

No need for the parentheses around `Result.SourceManager`.


Comment at: clang-tidy/utils/HeaderFileExtensionsUtils.cpp:50
@@ +49,3 @@
+  HeaderFileExtensions.clear();
+  for (llvm::StringRef Suffix : Suffixes) {
+llvm::StringRef Extension = Suffix.trim();

> seems that this is the first time to introduce list option into clang-tidy.

Comma is used as a delimiter in two more checks' options: 
clang-tidy/modernize/UseNullptrCheck.cpp and 
clang-tidy/misc/AssertSideEffectCheck.cpp. It's also used on the command line 
for the -checks and -warnings-as-errors options. I'm not sure what to do here, 
if we want consistency. For now, I'd rather switch back to comma and maybe 
provide a more generic facility to parse lists from clang-tidy options, which 
could also handle both separators in a smart way (e.g. when the list contains 
semicolons, use only them - this will allow listing entries like "A", 
otherwise use comma; maybe also support some other separator, say `|` for cases 
when we need to list entries containing semicolons).


Comment at: clang-tidy/utils/HeaderFileExtensionsUtils.h:23
@@ +22,3 @@
+namespace tidy {
+namespace header_file_extensions_utils {
+

That's an unnecessary long and too specific namespace name. I'd go for just 
`utils`, at least for now.


Comment at: clang-tidy/utils/HeaderFileExtensionsUtils.h:33
@@ +32,3 @@
+/// \brief Checks whether presumed location of Loc is in header file.
+bool isPresumedLocInHeaderFile(
+SourceLocation Loc, SourceManager ,

Don't add unused functions. When someone needs them, they can add them.


http://reviews.llvm.org/D16113



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

Re: [PATCH] D16152: [clang-tidy] Add check performance-faster-string-find

[Samuel Benzaquen via cfe-commits]

sbenza updated this revision to Diff 46798.
sbenza added a comment.

Make the delimiter a constant and fix mismatch between parse/serialize of the 
option.


http://reviews.llvm.org/D16152

Files:
  clang-tidy/performance/CMakeLists.txt
  clang-tidy/performance/FasterStringFindCheck.cpp
  clang-tidy/performance/FasterStringFindCheck.h
  clang-tidy/performance/PerformanceTidyModule.cpp
  docs/clang-tidy/checks/list.rst
  docs/clang-tidy/checks/performance-faster-string-find.rst
  test/clang-tidy/performance-faster-string-find.cpp

Index: test/clang-tidy/performance-faster-string-find.cpp
===
--- /dev/null
+++ test/clang-tidy/performance-faster-string-find.cpp
@@ -0,0 +1,110 @@
+// RUN: %check_clang_tidy %s performance-faster-string-find %t -- \
+// RUN:   -config="{CheckOptions: \
+// RUN: [{key: performance-faster-string-find.StringLikeClasses, \
+// RUN:   value: 'std::basic_string; ::llvm::StringRef;'}]}" --
+
+namespace std {
+template 
+struct basic_string {
+  int find(const Char *, int = 0) const;
+  int find(const Char *, int, int) const;
+  int rfind(const Char *) const;
+  int find_first_of(const Char *) const;
+  int find_first_not_of(const Char *) const;
+  int find_last_of(const Char *) const;
+  int find_last_not_of(const Char *) const;
+};
+
+typedef basic_string string;
+typedef basic_string wstring;
+}  // namespace std
+
+namespace llvm {
+struct StringRef {
+  int find(const char *) const;
+};
+}  // namespace llvm
+
+struct NotStringRef {
+  int find(const char *);
+};
+
+void StringFind() {
+  std::string Str;
+
+  Str.find("a");
+  // CHECK-MESSAGES: [[@LINE-1]]:12: warning: find called with a string literal consisting of a single character; consider using the more effective overload accepting a character [performance-faster-string-find]
+  // CHECK-FIXES: Str.find('a');
+
+  // Works with the pos argument.
+  Str.find("a", 1);
+  // CHECK-MESSAGES: [[@LINE-1]]:12: warning: find called with a string literal
+  // CHECK-FIXES: Str.find('a', 1);
+
+  // Doens't work with strings smaller or larger than 1 char.
+  Str.find("");
+  Str.find("ab");
+
+  // Doesn't do anything with the 3 argument overload.
+  Str.find("a", 1, 1);
+
+  // Other methods that can also be replaced
+  Str.rfind("a");
+  // CHECK-MESSAGES: [[@LINE-1]]:13: warning: rfind called with a string literal
+  // CHECK-FIXES: Str.rfind('a');
+  Str.find_first_of("a");
+  // CHECK-MESSAGES: [[@LINE-1]]:21: warning: find_first_of called with a string
+  // CHECK-FIXES: Str.find_first_of('a');
+  Str.find_first_not_of("a");
+  // CHECK-MESSAGES: [[@LINE-1]]:25: warning: find_first_not_of called with a
+  // CHECK-FIXES: Str.find_first_not_of('a');
+  Str.find_last_of("a");
+  // CHECK-MESSAGES: [[@LINE-1]]:20: warning: find_last_of called with a string
+  // CHECK-FIXES: Str.find_last_of('a');
+  Str.find_last_not_of("a");
+  // CHECK-MESSAGES: [[@LINE-1]]:24: warning: find_last_not_of called with a
+  // CHECK-FIXES: Str.find_last_not_of('a');
+
+  // std::wstring should work.
+  std::wstring WStr;
+  WStr.find(L"n");
+  // CHECK-MESSAGES: [[@LINE-1]]:13: warning: find called with a string literal
+  // CHECK-FIXES: Str.find(L'n');
+  // Even with unicode that fits in one wide char.
+  WStr.find(L"\x3A9");
+  // CHECK-MESSAGES: [[@LINE-1]]:13: warning: find called with a string literal
+  // CHECK-FIXES: Str.find(L'\x3A9');
+
+  // Also with other types, but only if it was specified in the options.
+  llvm::StringRef sr;
+  sr.find("x");
+  // CHECK-MESSAGES: [[@LINE-1]]:11: warning: find called with a string literal
+  // CHECK-FIXES: sr.find('x');
+  NotStringRef nsr;
+  nsr.find("x");
+}
+
+
+template 
+int FindTemplateDependant(T value) {
+  return value.find("A");
+}
+template 
+int FindTemplateNotDependant(T pos) {
+  return std::string().find("A", pos);
+  // CHECK-MESSAGES: [[@LINE-1]]:29: warning: find called with a string literal
+  // CHECK-FIXES: return std::string().find('A', pos);
+}
+
+int FindStr() {
+  return FindTemplateDependant(std::string()) + FindTemplateNotDependant(1);
+}
+
+#define STR_MACRO(str) str.find("A")
+#define POS_MACRO(pos) std::string().find("A",pos)
+
+int Macros() {
+  return STR_MACRO(std::string()) + POS_MACRO(1);
+  // CHECK-MESSAGES: [[@LINE-1]]:10: warning: find called with a string literal
+  // CHECK-MESSAGES: [[@LINE-2]]:37: warning: find called with a string literal
+}
Index: docs/clang-tidy/checks/performance-faster-string-find.rst
===
--- /dev/null
+++ docs/clang-tidy/checks/performance-faster-string-find.rst
@@ -0,0 +1,22 @@
+.. title:: clang-tidy - performance-faster-string-find
+
+performance-faster-string-find
+==
+
+Optimize calls to std::string::find() and friends when the needle passed is
+a single character string literal.
+The character literal overload is more efficient.
+
+By default only 

Re: [PATCH] D16819: Remove llvm::(cast|isa) from lib/CodeGen/Address.h to fix build with gcc-4.8.1

[Igor Sugak via cfe-commits]

sugak added a comment.

@rsmith: yes, I need someone to commit this.


http://reviews.llvm.org/D16819



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

Re: [PATCH] D15120: Add support for __float128 type to be used by targets that support it

[Hubert Tong via cfe-commits]

hubert.reinterpretcast added inline comments.


Comment at: lib/Sema/SemaExpr.cpp:1156-1159
@@ +1155,6 @@
+
+  QualType LHSElemType = dyn_cast(LHSType) ?
+cast(LHSType)->getElementType() : LHSType;
+  QualType RHSElemType = dyn_cast(RHSType) ?
+cast(RHSType)->getElementType() : RHSType;
+

rsmith wrote:
> hubert.reinterpretcast wrote:
> > The result of the `dyn_cast` can be saved instead of using `cast` after the 
> > `dyn_cast`.
> Do not use `dyn_cast` / `cast` on types, use `LHSType->getAs<...>()` / 
> `LHSType->castAs<...>()` instead. This will do the wrong thing on sugared 
> types (eg, a typedef for a complex type).
Are there contexts in Clang where sugared types don't occur? Is the general 
guidance to use `getAs` or `castAs` even if the types are known to be canonical 
(which I agree isn't the case here)?


Repository:
  rL LLVM

http://reviews.llvm.org/D15120



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

Re: [PATCH] D15120: Add support for __float128 type to be used by targets that support it

[Richard Smith via cfe-commits]

On Wed, Feb 3, 2016 at 3:52 PM, Hubert Tong <
hubert.reinterpretc...@gmail.com> wrote:

> hubert.reinterpretcast added inline comments.
>
> 
> Comment at: lib/Sema/SemaExpr.cpp:1156-1159
> @@ +1155,6 @@
> +
> +  QualType LHSElemType = dyn_cast(LHSType) ?
> +cast(LHSType)->getElementType() : LHSType;
> +  QualType RHSElemType = dyn_cast(RHSType) ?
> +cast(RHSType)->getElementType() : RHSType;
> +
> 
> rsmith wrote:
> > hubert.reinterpretcast wrote:
> > > The result of the `dyn_cast` can be saved instead of using `cast`
> after the `dyn_cast`.
> > Do not use `dyn_cast` / `cast` on types, use `LHSType->getAs<...>()` /
> `LHSType->castAs<...>()` instead. This will do the wrong thing on sugared
> types (eg, a typedef for a complex type).
> Are there contexts in Clang where sugared types don't occur? Is the
> general guidance to use `getAs` or `castAs` even if the types are known to
> be canonical (which I agree isn't the case here)?


If you're intentionally inspecting the immediate type sugar node, then
dyn_cast/cast are appropriate. If it's obvious from context that you have a
canonical type, then they're OK (and might be marginally faster), but it's
an immediate red flag to a reader of the code to see those operations, so
they should often be avoided for that reason even if they're correct.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D16351: [FIX] Bug 25404 - Crash on typedef in OpenCL 2.0

[Igor Chesnokov via cfe-commits]

ichesnokov marked 3 inline comments as done.
ichesnokov added a comment.

Notice that redefinition of typedef defined at system header will show the same 
message.


http://reviews.llvm.org/D16351



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

Re: [PATCH] D16784: [OpenMP] Reorganize code to allow specialized code generation for different devices.

[Samuel Antao via cfe-commits]

sfantao added a comment.

Hi Alexey,

Thanks for the feedback!



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:340-341
@@ +339,4 @@
+  case llvm::Triple::nvptx64:
+assert(CGM.getLangOpts().OpenMPIsDevice &&
+   "OpenMP NVPTX is only prepared to deal with device code.");
+return createCGOpenMPRuntimeNVPTX(CGM);

ABataev wrote:
> I think it is better to reorganize this code like that:
> ```
> switch (CGM.getTarget().getTriple().getArch()) {
>   case llvm::Triple::nvptx:
>   case llvm::Triple::nvptx64:
> assert(CGM.getLangOpts().OpenMPIsDevice &&
>"OpenMP NVPTX is only prepared to deal with device code.");
> return new CGOpenMPRuntimeNVPTX(CGM);
>   default:
> break;
> }
> return new CGOpenMPRuntime(CGM);
> ```
Ok, will do.


Comment at: lib/CodeGen/CGOpenMPRuntime.h:552-555
@@ -551,2 +551,6 @@
 
+  /// \brief Create specialized OpenMP runtime code generation class for NVPTX
+  /// targets.
+  static CGOpenMPRuntime *createCGOpenMPRuntimeNVPTX(CodeGenModule );
+
 public:

ABataev wrote:
> Do you really need this function? Currently, I don't see a point in adding 
> this platform-specific thing to (mostly) common interface
I am using that function to avoid exposing the constructor of 
`CGOpenMPRuntimeNVPTX ` in CGOpenMPRuntime.h. Do you prefer me to do that 
instead?


http://reviews.llvm.org/D16784



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

Re: [PATCH] D16351: [FIX] Bug 25404 - Crash on typedef in OpenCL 2.0

[Igor Chesnokov via cfe-commits]

ichesnokov updated this revision to Diff 46876.
ichesnokov marked 2 inline comments as done.
ichesnokov added a comment.

Test case enriched to check typedef redefinition without warnings.
Minor fix of comment.


http://reviews.llvm.org/D16351

Files:
  lib/Sema/SemaDecl.cpp
  test/SemaOpenCL/implicit-typedef.cl

Index: test/SemaOpenCL/implicit-typedef.cl
===
--- test/SemaOpenCL/implicit-typedef.cl
+++ test/SemaOpenCL/implicit-typedef.cl
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 %s -DTEST_WARNINGS -cl-std=CL2.0 -verify -pedantic 
-fsyntax-only -Wsystem-headers
+// RUN: %clang_cc1 %s -cl-std=CL2.0 -fsyntax-only
+
+#if defined(TEST_WARNINGS)
+typedef atomic_int atomic_flag; // expected-warning {{redefinition of typedef 
'atomic_flag' is a C11 feature}}
+#else
+typedef atomic_int atomic_flag;
+#endif
Index: lib/Sema/SemaDecl.cpp
===
--- lib/Sema/SemaDecl.cpp
+++ lib/Sema/SemaDecl.cpp
@@ -2036,6 +2036,22 @@
   if (getLangOpts().Modules || getLangOpts().C11)
 return;
   
+  // Added isImplicit() check, because implicit TypeDecl::getLocation()
+  // returns 0. The're many implicit typedefs in OpenCL, e.g. atomic_flag.
+  if (Old->isImplicit() || New->isImplicit()) {
+// Since we don't emit system header warnings for compatibility with GCC,
+// don't do this for implicit type redefinition warnings the same way.
+if (!getDiagnostics().getSuppressSystemWarnings()) {
+  if (New->getLocation().isValid()) {
+Diag(New->getLocation(), diag::ext_redefinition_of_typedef)
+  << New->getDeclName();
+if (Old->getLocation().isValid())
+  Diag(Old->getLocation(), diag::note_previous_definition);
+  }
+}
+return;
+  }
+
   // If we have a redefinition of a typedef in C, emit a warning.  This warning
   // is normally mapped to an error, but can be controlled with
   // -Wtypedef-redefinition.  If either the original or the redefinition is


Index: test/SemaOpenCL/implicit-typedef.cl
===
--- test/SemaOpenCL/implicit-typedef.cl
+++ test/SemaOpenCL/implicit-typedef.cl
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 %s -DTEST_WARNINGS -cl-std=CL2.0 -verify -pedantic -fsyntax-only -Wsystem-headers
+// RUN: %clang_cc1 %s -cl-std=CL2.0 -fsyntax-only
+
+#if defined(TEST_WARNINGS)
+typedef atomic_int atomic_flag; // expected-warning {{redefinition of typedef 'atomic_flag' is a C11 feature}}
+#else
+typedef atomic_int atomic_flag;
+#endif
Index: lib/Sema/SemaDecl.cpp
===
--- lib/Sema/SemaDecl.cpp
+++ lib/Sema/SemaDecl.cpp
@@ -2036,6 +2036,22 @@
   if (getLangOpts().Modules || getLangOpts().C11)
 return;
   
+  // Added isImplicit() check, because implicit TypeDecl::getLocation()
+  // returns 0. The're many implicit typedefs in OpenCL, e.g. atomic_flag.
+  if (Old->isImplicit() || New->isImplicit()) {
+// Since we don't emit system header warnings for compatibility with GCC,
+// don't do this for implicit type redefinition warnings the same way.
+if (!getDiagnostics().getSuppressSystemWarnings()) {
+  if (New->getLocation().isValid()) {
+Diag(New->getLocation(), diag::ext_redefinition_of_typedef)
+  << New->getDeclName();
+if (Old->getLocation().isValid())
+  Diag(Old->getLocation(), diag::note_previous_definition);
+  }
+}
+return;
+  }
+
   // If we have a redefinition of a typedef in C, emit a warning.  This warning
   // is normally mapped to an error, but can be controlled with
   // -Wtypedef-redefinition.  If either the original or the redefinition is
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits