date:20160203

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/

2016-02-03 Thread 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&r1=170427&r2=170428&view=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 = 
> Context.getPointerType(Type.withConst());
> -  RTTIBuilder(*this).BuildTypeInfo(

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

2016-02-03 Thread 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, bool>
+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 &Args) {

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] D16613: Introduce a cmake module to figure out whether we need to link with libatomic.

2016-02-03 Thread 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

Re: [PATCH] D16626: [x86] Correct setting of WIntType for MCU target

2016-02-03 Thread Andrey Bokhanko via cfe-commits

andreybokhanko added a comment.

Ping!


http://reviews.llvm.org/D16626



___
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.

2016-02-03 Thread 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&view=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&r1=259636&r2=259637&view=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: [PATCH] D16801: [OpenMP] Change in initial size of DSAStackTy::StackTy

2016-02-03 Thread 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

2016-02-03 Thread 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&view=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&r1=259638&r2=259639&view=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&r1=259638&r2=259639&view=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(), &TempSrcMgr);

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&view=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&r1=259638&r2=259639&view=diff
==
--- cfe/trunk/test/Sema/asm.c (original)
+++ cfe/trunk/test/Sema/asm.c Wed Feb  3 05:32:08 2016
@@ -25,7 +25

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

2016-02-03 Thread 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&view=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&r1=259639&r2=259640&view=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 &Result) {
   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: [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/

2016-02-03 Thread Aleksey Bader via cfe-commits

FYI: OpenCL is planning to add C++ flavor of kernel language:
https://www.khronos.org/registry/cl/specs/opencl-2.1-openclc++.pdf

On Wed, Feb 3, 2016 at 12:04 PM, Benyei, Guy via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> 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 <
> cfe-commits@lists.llvm.org>
> 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&r1=170427&r2=170428&view=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:
> > +

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

2016-02-03 Thread 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&view=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&r1=259642&r2=259643&view=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&r1=259642&r2=259643&view=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

Re: [PATCH] D16578: [clang-tidy] bug fix: Don't warn on partial template specialization in `misc-definitions-in-headers` check.

2016-02-03 Thread Haojian Wu via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL259643: [clang-tidy] bug fix: Don't warn on partial template 
specialization in `misc… (authored by hokein).

Changed prior to commit:
  http://reviews.llvm.org/D16578?vs=45984&id=46767#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D16578

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

Index: clang-tools-extra/trunk/test/clang-tidy/misc-definitions-in-headers.hpp
===
--- clang-tools-extra/trunk/test/clang-tidy/misc-definitions-in-headers.hpp
+++ clang-tools-extra/trunk/test/clang-tidy/misc-definitions-in-headers.hpp
@@ -133,3 +133,28 @@
 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;
+}
Index: clang-tools-extra/trunk/clang-tidy/misc/DefinitionsInHeadersCheck.cpp
===
--- clang-tools-extra/trunk/clang-tidy/misc/DefinitionsInHeadersCheck.cpp
+++ clang-tools-extra/trunk/clang-tidy/misc/DefinitionsInHeadersCheck.cpp
@@ -91,9 +91,12 @@
 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();
   }
 }


Index: clang-tools-extra/trunk/test/clang-tidy/misc-definitions-in-headers.hpp
===
--- clang-tools-extra/trunk/test/clang-tidy/misc-definitions-in-headers.hpp
+++ clang-tools-extra/trunk/test/clang-tidy/misc-definitions-in-headers.hpp
@@ -133,3 +133,28 @@
 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;
+}
Index: clang-tools-extra/trunk/clang-tidy/misc/DefinitionsInHeadersCheck.cpp
===
--- clang-tools-extra/trunk/clang-tidy/misc/DefinitionsInHeadersCheck.cpp
+++ clang-tools-extra/trunk/clang-tidy/misc/DefinitionsInHeadersCheck.cpp
@@ -91,9 +91,12 @@
 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();
   }
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D16578: [clang-tidy] bug fix: Don't warn on partial template specialization in `misc-definitions-in-headers` check.

2016-02-03 Thread Haojian Wu via cfe-commits

hokein added a comment.

@alexfh, I get commit access, and have committed the patch by myself (Seems it 
is a successful commit :D ).


Repository:
  rL LLVM

http://reviews.llvm.org/D16578



___
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

2016-02-03 Thread 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
+++ test/CodeGenOpenCL/generic-mang

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

2016-02-03 Thread 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

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

2016-02-03 Thread 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 &operator=(const A &) = delete;
+// CHECK-FIXES-NEXT: //
+// CHECK-FIXES-NEXT: };
+
+class B {
+  B(const B &);
+  B &operator=(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 &operator=(const C &) = default;
+// CHECK-FIXES-NEXT: //
+// CHECK-FIXES-NEXT: };
+
+class D {
+  D(const D &);
+  D &operator=(const D &) = default;
+};
+
+class E {
+  E(const E &);
+  E &operator=(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 &operator=(const F &) = delete;
+// CHECK-FIXES-NEXT: //
+// CHECK-FIXES-NEXT: };
+
+
+//
+// User defined copy assignment
+//
+class A2 {
+  A2 &operator=(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 &operator=(const A2 &);
+// CHECK-FIXES-NEXT: //
+// CHECK-FIXES-NEXT: };
+
+class B2 {
+  B2(const B2 &);
+  B2 &operator=(const B2 &);
+};
+
+class C2 {
+  C2 &operator=(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 &operator=(const C2 &) = default;
+// CHECK-FIXES-NEXT: //
+// CHECK-FIXES-NEXT: };
+
+class D2 {
+  D2(const D2 &) = default;
+  D2 &operator=(const D2 &);
+};
+
+class E2 {
+  E2(const E2 &) = delete;
+  E2 &operator=(const E2 &);
+};
+
+class F2 {
+  F2 &operator=(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 &operator=(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 &operator=(A3 &&) = delete;
+// CHECK-FIXES-NEXT: //
+// CHECK-FIXES-NEXT: };
+
+class B3 {
+  B3(B3 &&);
+  B3 &operator=(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 &operator=(C3 &&) = default;
+// CHECK-FIXES-NEXT: //
+// CHECK-FIXES-NEXT: };
+
+class D3 {
+  D3(D3 &&);
+  D3 &operator=(D3 &&) = default;
+};
+
+class E3 {
+  E3(E3 &&);
+  E3 &operator=(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 &operator=(F3 &&) =

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

2016-02-03 Thread 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

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

2016-02-03 Thread 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&view=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&r1=259645&r2=259646&view=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&view=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

2016-02-03 Thread 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&id=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

r259647 - Forgot to remove file in previous commit.

2016-02-03 Thread 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&view=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&view=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

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

2016-02-03 Thread 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

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

2016-02-03 Thread 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

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

2016-02-03 Thread 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.

2016-02-03 Thread 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&view=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&r1=259647&r2=259648&view=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 &Context);
 /// @}
 
+/// \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 &Context);
+
 /// \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 &Nod
   return match(Matcher, ast_type_traits::DynTypedNode::create(Node), Context);
 }
 
+template 
+SmallVector
+match(MatcherT Matcher, ASTContext &Context) {
+  internal::CollectMatchesCallback Callback;
+  MatchFinder Finder;
+  Finder.addMatcher(Matcher, &Callback);
+  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&r1=259647&r2=259648&view=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] D16770: [MS] PR26234: Allow typedef redefinition of equally qualified, sized and aligned types in C

2016-02-03 Thread 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 &Context) {
+#ifndef NDEBUG
+  const LangOptions &Opts = 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 &Opts = 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] D16482: Add builtins for bitreverse intrinsic

2016-02-03 Thread 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] D16376: clang-tidy check: rule-of-five

2016-02-03 Thread Alexander Kornienko via cfe-commits

alexfh added inline comments.


Comment at: clang-tidy/misc/RuleOfFiveCheck.cpp:30
@@ +29,3 @@
+.bind("copy-ctor")),
+  unless(hasDescendant(cxxMethodDecl(isCopyAssignmentOperator(),
+  this);

Why is `hasDescendant` needed? Doesn't just `has(...)` work? I think, methods 
are direct children of the CXXRecordDecl they are declared in.

Same applies to other matchers. 


Comment at: clang-tidy/misc/RuleOfFiveCheck.cpp:80
@@ +79,3 @@
+  case RuleOfFiveCheck::SpecialFunctionKind::MoveAssignment: {
+SourceLocation DeclBegin = MatchedDecl.getLocStart();
+return DeclBegin.getLocWithOffset(-1);

The variable doesn't make the code shorter or easier to read. Please remove it.


Comment at: clang-tidy/misc/RuleOfFiveCheck.cpp:110
@@ +109,3 @@
+return (llvm::Twine("\n") + ClassName + " &operator=(const " + ClassName +
+" &) = " + deleteOrDefault(MatchedDecl) + ";")
+.str();

How about removing the `deleteOrDefault` function and inserting this before the 
switch:

  StringRef deleteOrDefault = MethodDecl.isDefaulted() ? " = default;" : " = 
delete;";

?


Comment at: clang-tidy/misc/RuleOfFiveCheck.cpp:117
@@ +116,3 @@
+  case RuleOfFiveCheck::SpecialFunctionKind::MoveConstructor:
+return (llvm::Twine("\n") + ClassName + " &operator=(" + ClassName +
+" &&) = " + deleteOrDefault(MatchedDecl) + ";")

We usually rely on clang-format to clean up formatting after applying fixes, 
but in some cases clang-format looks into possible preferences already present 
in the code. Placement of `*` or `&` on pointers and references is one of such 
things. I think, clang-tidy should keep neutrality in this regard, e.g. by 
adding spaces on both sides of the `*` an `&` in its fixes.


Comment at: test/clang-tidy/misc-rule-of-five.cpp:1
@@ +1,2 @@
+// RUN: %check_clang_tidy %s misc-rule-of-five %t
+

Please add tests with macros and templates with multiple instantiations.


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

2016-02-03 Thread 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

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

2016-02-03 Thread 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&view=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&r1=259650&r2=259651&view=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&r1=259650&r2=259651&view=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&r1=259650&r2=259651&view=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&r1=259650&r2=259651&view=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&r1=259650&r2=259651&view=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&r1=259650&r2=259651&view=diff
===

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

2016-02-03 Thread 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.

2016-02-03 Thread 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&view=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&r1=259651&r2=259652&view=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&r1=259651&r2=259652&view=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 &ID) const {
-  ID.AddInteger((unsigned)getKind());
+  ID.AddInteger(static_cast(getKind()));
 }
 
 void StackSpaceRegion::Profile(llvm::FoldingSetNodeID &ID) const {
-  ID.AddInteger((unsigned)getKind());
+  ID.AddInteger(static_cast(getKind()));
   ID.AddPointer(getStackFrame());
 }
 
 void StaticGlobalSpaceRegion::Profile(llvm::FoldingSetNodeID &ID) 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(Alloca

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

2016-02-03 Thread 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

2016-02-03 Thread 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 &S, Decl *D,
+ const AttributeList &Attr) {
+  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] D16686: [OpenCL] Generate metadata for opencl_unroll_hint attribute

2016-02-03 Thread 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]],   !

Re: [PATCH] D16854: [clang-tidy] Fix a crash issue on misc-virtual-near-miss check.

2016-02-03 Thread Cong Liu via cfe-commits

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

LGTM. Thanks!


Repository:
  rL LLVM

http://reviews.llvm.org/D16854



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

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

2016-02-03 Thread 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] D16113: [clang-tdiy] Add header file extension configuration support.

2016-02-03 Thread 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 &SM,

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

2016-02-03 Thread Samuel Benzaquen via cfe-commits

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

Added comment about StringLikeClasses


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 `std::basic_string` is considered. This list can b

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

2016-02-03 Thread 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] D16574: Bug 15685 - OpenCL 'char' is not signed

2016-02-03 Thread Igor Chesnokov via cfe-commits

ichesnokov added a comment.

Please review and approve.


Repository:
  rL LLVM

http://reviews.llvm.org/D16574



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

r259667 - Add back the ABITest makefiles

2016-02-03 Thread Chris Bieneman via cfe-commits

Author: cbieneman
Date: Wed Feb  3 11:16:01 2016
New Revision: 259667

URL: http://llvm.org/viewvc/llvm-project?rev=259667&view=rev
Log:
Add back the ABITest makefiles

These files are standalone and not integrated with CMake, so we probably want 
them.

Added:
cfe/trunk/utils/ABITest/Makefile.test.common
cfe/trunk/utils/ABITest/layout/Makefile
cfe/trunk/utils/ABITest/return-types-32/Makefile
cfe/trunk/utils/ABITest/return-types-64/Makefile
cfe/trunk/utils/ABITest/single-args-32/Makefile
cfe/trunk/utils/ABITest/single-args-64/Makefile

Added: cfe/trunk/utils/ABITest/Makefile.test.common
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/utils/ABITest/Makefile.test.common?rev=259667&view=auto
==
--- cfe/trunk/utils/ABITest/Makefile.test.common (added)
+++ cfe/trunk/utils/ABITest/Makefile.test.common Wed Feb  3 11:16:01 2016
@@ -0,0 +1,170 @@
+# -*- Makefile -*-
+
+# Usage: make test.N.report 
+#
+# COUNT can be over-ridden to change the number of tests generated per
+# file, and TESTARGS is used to change the type generation. Make sure
+# to 'make clean' after changing either of these parameters.
+
+TESTARGS := --no-unsigned --no-vector --no-complex --no-bool
+
+COUNT := 1
+TIMEOUT := 5
+
+CFLAGS := -std=gnu99
+
+X_COMPILER := gcc
+X_LL_CFLAGS := -emit-llvm -S
+Y_COMPILER := clang
+Y_LL_CFLAGS := -emit-llvm -S
+CC := gcc
+
+###
+
+ABITESTGEN := ../ABITestGen.py
+
+ifndef VERBOSE
+  Verb := @
+endif
+
+.PHONY: test.%.report
+test.%.report: temps/test.%.xx.diff temps/test.%.xy.diff temps/test.%.yx.diff 
temps/test.%.yy.diff
+   @ok=1;\
+   for t in $^; do \
+   if [ -s $$t ]; then \
+   echo "TEST $*: $$t failed"; \
+   ok=0;\
+   fi; \
+   done; \
+   if [ $$ok -eq 1 ]; then \
+   true; \
+   else \
+   false; \
+   fi
+
+
+.PHONY: test.%.defs-report
+test.%.defs-report: temps/test.%.defs.diff
+   @for t in $^; do \
+   if [ -s $$t ]; then \
+   echo "TEST $*: $$t failed"; \
+   cat $$t; \
+   fi; \
+   done
+
+.PHONY: test.%.build
+test.%.build: temps/test.%.ref temps/test.%.xx temps/test.%.xy temps/test.%.yx 
temps/test.%.yy temps/test.%.x.defs temps/test.%.y.defs
+   @true
+
+###
+
+# Diffs and output
+
+.PRECIOUS: temps/.dir
+
+.PRECIOUS: temps/test.%.xx.diff
+temps/test.%.xx.diff: temps/test.%.ref.out temps/test.%.xx.out
+   $(Verb) diff $^ > $@ || true
+.PRECIOUS: temps/test.%.xy.diff
+temps/test.%.xy.diff: temps/test.%.ref.out temps/test.%.xy.out
+   $(Verb) diff $^ > $@ || true
+.PRECIOUS: temps/test.%.yx.diff
+temps/test.%.yx.diff: temps/test.%.ref.out temps/test.%.yx.out
+   $(Verb) diff $^ > $@ || true
+.PRECIOUS: temps/test.%.yy.diff
+temps/test.%.yy.diff: temps/test.%.ref.out temps/test.%.yy.out
+   $(Verb) diff $^ > $@ || true
+.PRECIOUS: temps/test.%.defs.diff
+temps/test.%.defs.diff: temps/test.%.x.defs temps/test.%.y.defs
+   $(Verb) zipdifflines \
+ --replace "%struct.T[0-9]+" "%struct.s" \
+ --replace "%union.T[0-9]+" "%struct.s" \
+ --replace "byval align [0-9]+" "byval" \
+ $^ > $@
+
+.PRECIOUS: temps/test.%.out
+temps/test.%.out: temps/test.%
+   -$(Verb) ./$< > $@
+
+# Executables
+
+.PRECIOUS: temps/test.%.ref
+temps/test.%.ref: temps/test.%.driver.ref.o temps/test.%.a.ref.o 
temps/test.%.b.ref.o
+   $(Verb) $(CC) $(CFLAGS) $(CC_CFLAGS) -O3 -o $@ $^
+.PRECIOUS: temps/test.%.xx
+temps/test.%.xx: temps/test.%.driver.ref.o temps/test.%.a.x.o 
temps/test.%.b.x.o
+   $(Verb) $(CC) $(CFLAGS) $(CC_CFLAGS) -O3  -o $@ $^
+.PRECIOUS: temps/test.%.xy
+temps/test.%.xy: temps/test.%.driver.ref.o temps/test.%.a.x.o 
temps/test.%.b.y.o
+   $(Verb) $(CC) $(CFLAGS) $(CC_CFLAGS) -O3  -o $@ $^
+.PRECIOUS: temps/test.%.yx
+temps/test.%.yx: temps/test.%.driver.ref.o temps/test.%.a.y.o 
temps/test.%.b.x.o
+   $(Verb) $(CC) $(CFLAGS) $(CC_CFLAGS) -O3  -o $@ $^
+.PRECIOUS: temps/test.%.yy
+temps/test.%.yy: temps/test.%.driver.ref.o temps/test.%.a.y.o 
temps/test.%.b.y.o
+   $(Verb) $(CC) $(CFLAGS) $(CC_CFLAGS) -O3  -o $@ $^
+
+# Object files
+
+.PRECIOUS: temps/test.%.ref.o
+temps/test.%.ref.o: inputs/test.%.c temps/.dir
+   $(Verb) $(CC) -c $(CFLAGS) $(CC_CFLAGS) -o $@ $<
+.PRECIOUS: temps/test.%.x.o
+temps/test.%.x.o: inputs/test.%.c temps/.dir
+   $(Verb) $(X_COMPILER) -c $(CFLAGS) $(X_CFLAGS) -o $@ $<
+.PRECIOUS: temps/test.%.y.o
+temps/test.%.y.o: inputs/test.%.c temps/.dir
+   $(Verb) $(Y_COMPILER) -c $(CFLAGS) $(Y_CFLAGS) -o $@ $<
+
+.PRECIOUS: temps/test.%.x.defs
+temps/test.%.x.defs: temps/test.%.a.x.ll temps/.dir
+   -$(Verb) -grep '^define ' $< > $@
+.PRECIOUS: temps/test.%.y.defs
+temps/test.%.y.defs: temps/test.%.a.y.ll temps/.dir
+   -$(Verb) -grep '^define ' $< > $@
+
+.PRECIOUS: temps/test.%.a.x.ll
+temps/test.%.a.

[clang-tools-extra] r259668 - [clang-tidy] Fix a crash issue on misc-virtual-near-miss check.

2016-02-03 Thread Haojian Wu via cfe-commits

Author: hokein
Date: Wed Feb  3 11:21:44 2016
New Revision: 259668

URL: http://llvm.org/viewvc/llvm-project?rev=259668&view=rev
Log:
[clang-tidy] Fix a crash issue on misc-virtual-near-miss check.

Summary:
The crash is caused by triggering a Assertion failed in DeclCXX.h when the
check detects non-defined class return type in a class method declaration.

Reviewers: congliu, alexfh

Subscribers: cfe-commits

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

Modified:
clang-tools-extra/trunk/clang-tidy/misc/VirtualNearMissCheck.cpp
clang-tools-extra/trunk/test/clang-tidy/misc-virtual-near-miss.cpp

Modified: clang-tools-extra/trunk/clang-tidy/misc/VirtualNearMissCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/misc/VirtualNearMissCheck.cpp?rev=259668&r1=259667&r2=259668&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/misc/VirtualNearMissCheck.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/misc/VirtualNearMissCheck.cpp Wed Feb  3 
11:21:44 2016
@@ -72,6 +72,9 @@ static bool checkOverridingFunctionRetur
   if (DRD == nullptr || BRD == nullptr)
 return false;
 
+  if (!DRD->hasDefinition() || !BRD->hasDefinition())
+return false;
+
   if (DRD == BRD)
 return true;
 

Modified: clang-tools-extra/trunk/test/clang-tidy/misc-virtual-near-miss.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/misc-virtual-near-miss.cpp?rev=259668&r1=259667&r2=259668&view=diff
==
--- clang-tools-extra/trunk/test/clang-tidy/misc-virtual-near-miss.cpp 
(original)
+++ clang-tools-extra/trunk/test/clang-tidy/misc-virtual-near-miss.cpp Wed Feb  
3 11:21:44 2016
@@ -1,10 +1,14 @@
 // RUN: %check_clang_tidy %s misc-virtual-near-miss %t
 
+class NoDefinedClass1;
+class NoDefinedClass2;
+
 struct Base {
   virtual void func();
   virtual void gunk();
   virtual ~Base();
   virtual Base &operator=(const Base &);
+  virtual NoDefinedClass1 *f();
 };
 
 struct Derived : Base {
@@ -24,6 +28,8 @@ struct Derived : Base {
   // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: method 'Derived::fun' has {{.*}} 
'Base::func'
 
   Derived &operator==(const Base &); // Should not warn: operators are ignored.
+
+  virtual NoDefinedClass2 *f1(); // Should not crash: non-defined class return 
type is ignored.
 };
 
 typedef Derived derived_type;


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

Re: [PATCH] D16854: [clang-tidy] Fix a crash issue on misc-virtual-near-miss check.

2016-02-03 Thread Haojian Wu via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL259668: [clang-tidy] Fix a crash issue on 
misc-virtual-near-miss check. (authored by hokein).

Changed prior to commit:
  http://reviews.llvm.org/D16854?vs=46787&id=46800#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D16854

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

Index: clang-tools-extra/trunk/test/clang-tidy/misc-virtual-near-miss.cpp
===
--- clang-tools-extra/trunk/test/clang-tidy/misc-virtual-near-miss.cpp
+++ clang-tools-extra/trunk/test/clang-tidy/misc-virtual-near-miss.cpp
@@ -1,10 +1,14 @@
 // RUN: %check_clang_tidy %s misc-virtual-near-miss %t
 
+class NoDefinedClass1;
+class NoDefinedClass2;
+
 struct Base {
   virtual void func();
   virtual void gunk();
   virtual ~Base();
   virtual Base &operator=(const Base &);
+  virtual NoDefinedClass1 *f();
 };
 
 struct Derived : Base {
@@ -24,6 +28,8 @@
   // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: method 'Derived::fun' has {{.*}} 
'Base::func'
 
   Derived &operator==(const Base &); // Should not warn: operators are ignored.
+
+  virtual NoDefinedClass2 *f1(); // Should not crash: non-defined class return 
type is ignored.
 };
 
 typedef Derived derived_type;
Index: clang-tools-extra/trunk/clang-tidy/misc/VirtualNearMissCheck.cpp
===
--- clang-tools-extra/trunk/clang-tidy/misc/VirtualNearMissCheck.cpp
+++ clang-tools-extra/trunk/clang-tidy/misc/VirtualNearMissCheck.cpp
@@ -72,6 +72,9 @@
   if (DRD == nullptr || BRD == nullptr)
 return false;
 
+  if (!DRD->hasDefinition() || !BRD->hasDefinition())
+return false;
+
   if (DRD == BRD)
 return true;
 


Index: clang-tools-extra/trunk/test/clang-tidy/misc-virtual-near-miss.cpp
===
--- clang-tools-extra/trunk/test/clang-tidy/misc-virtual-near-miss.cpp
+++ clang-tools-extra/trunk/test/clang-tidy/misc-virtual-near-miss.cpp
@@ -1,10 +1,14 @@
 // RUN: %check_clang_tidy %s misc-virtual-near-miss %t
 
+class NoDefinedClass1;
+class NoDefinedClass2;
+
 struct Base {
   virtual void func();
   virtual void gunk();
   virtual ~Base();
   virtual Base &operator=(const Base &);
+  virtual NoDefinedClass1 *f();
 };
 
 struct Derived : Base {
@@ -24,6 +28,8 @@
   // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: method 'Derived::fun' has {{.*}} 'Base::func'
 
   Derived &operator==(const Base &); // Should not warn: operators are ignored.
+
+  virtual NoDefinedClass2 *f1(); // Should not crash: non-defined class return type is ignored.
 };
 
 typedef Derived derived_type;
Index: clang-tools-extra/trunk/clang-tidy/misc/VirtualNearMissCheck.cpp
===
--- clang-tools-extra/trunk/clang-tidy/misc/VirtualNearMissCheck.cpp
+++ clang-tools-extra/trunk/clang-tidy/misc/VirtualNearMissCheck.cpp
@@ -72,6 +72,9 @@
   if (DRD == nullptr || BRD == nullptr)
 return false;
 
+  if (!DRD->hasDefinition() || !BRD->hasDefinition())
+return false;
+
   if (DRD == BRD)
 return true;
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r259622 - Fix miscompile and rejects-valids when disambiguating after an ambiguous

2016-02-03 Thread Renato Golin via cfe-commits

On 3 February 2016 at 02:58, Richard Smith via cfe-commits
 wrote:
> Author: rsmith
> Date: Tue Feb  2 20:58:20 2016
> New Revision: 259622
>
> URL: http://llvm.org/viewvc/llvm-project?rev=259622&view=rev
> Log:
> Fix miscompile and rejects-valids when disambiguating after an ambiguous
> C-style-cast to function/array type or parenthesized function-style cast/array
> indexing.

Hi Richard,

After bisecting, I found that your commit is the responsible for this
test-suite failure on AArch64:

1. 
/external/buildbot/clang-native-arm-lnt/test/test-suite/MultiSource/Benchmarks/MallocBench/gs/zpaint.c:181:45:
current parser token ';'
2. 
/external/buildbot/clang-native-arm-lnt/test/test-suite/MultiSource/Benchmarks/MallocBench/gs/zpaint.c:165:1:
parsing function body 'image_continue'
3. 
/external/buildbot/clang-native-arm-lnt/test/test-suite/MultiSource/Benchmarks/MallocBench/gs/zpaint.c:165:1:
in compound statement ('{}')
4. 
/external/buildbot/clang-native-arm-lnt/test/test-suite/MultiSource/Benchmarks/MallocBench/gs/zpaint.c:181:5:
in compound statement ('{}')

http://lab.llvm.org:8011/builders/clang-cmake-aarch64-full/builds/1330

http://lab.llvm.org:8011/builders/clang-native-arm-lnt/builds/16211

http://lab.llvm.org:8011/builders/clang-cmake-aarch64-quick/builds/4487

Can you have a look, please?

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

r259670 - clang-format: Fix formatting of ternary expressions with comments.

2016-02-03 Thread Daniel Jasper via cfe-commits

Author: djasper
Date: Wed Feb  3 11:27:10 2016
New Revision: 259670

URL: http://llvm.org/viewvc/llvm-project?rev=259670&view=rev
Log:
clang-format: Fix formatting of ternary expressions with comments.

Before:
  int i = aa ?
  /*=*/b :
   ccc;

After:
  int i = aa ?
  /*=*/b :
  ccc;

Modified:
cfe/trunk/lib/Format/ContinuationIndenter.cpp
cfe/trunk/unittests/Format/FormatTest.cpp

Modified: cfe/trunk/lib/Format/ContinuationIndenter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/ContinuationIndenter.cpp?rev=259670&r1=259669&r2=259670&view=diff
==
--- cfe/trunk/lib/Format/ContinuationIndenter.cpp (original)
+++ cfe/trunk/lib/Format/ContinuationIndenter.cpp Wed Feb  3 11:27:10 2016
@@ -705,11 +705,15 @@ unsigned ContinuationIndenter::moveState
   if (Current.is(TT_ArraySubscriptLSquare) &&
   State.Stack.back().StartOfArraySubscripts == 0)
 State.Stack.back().StartOfArraySubscripts = State.Column;
-  if ((Current.is(tok::question) && Style.BreakBeforeTernaryOperators) ||
-  (Current.getPreviousNonComment() && Current.isNot(tok::colon) &&
-   Current.getPreviousNonComment()->is(tok::question) &&
-   !Style.BreakBeforeTernaryOperators))
+  if (Style.BreakBeforeTernaryOperators && Current.is(tok::question))
 State.Stack.back().QuestionColumn = State.Column;
+  if (!Style.BreakBeforeTernaryOperators && Current.isNot(tok::colon)) {
+const FormatToken *Previous = Current.Previous;
+while (Previous && Previous->isTrailingComment())
+  Previous = Previous->Previous;
+if (Previous && Previous->is(tok::question))
+  State.Stack.back().QuestionColumn = State.Column;
+  }
   if (!Current.opensScope() && !Current.closesScope())
 State.LowestLevelOnLine =
 std::min(State.LowestLevelOnLine, Current.NestingLevel);

Modified: cfe/trunk/unittests/Format/FormatTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Format/FormatTest.cpp?rev=259670&r1=259669&r2=259670&view=diff
==
--- cfe/trunk/unittests/Format/FormatTest.cpp (original)
+++ cfe/trunk/unittests/Format/FormatTest.cpp Wed Feb  3 11:27:10 2016
@@ -4694,6 +4694,10 @@ TEST_F(FormatTest, BreaksConditionalExpr
"   ccc :\n"
"   ddd);",
Style);
+  verifyFormat("int i = aa ?\n"
+   "/*bbb=*/b :\n"
+   "ccc;",
+   Style);
 }
 
 TEST_F(FormatTest, DeclarationsOfMultipleVariables) {


___
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

2016-02-03 Thread David Blaikie via cfe-commits

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] D16770: [MS] PR26234: Allow typedef redefinition of equally qualified, sized and aligned types in C

2016-02-03 Thread Reid Kleckner via cfe-commits

rnk added inline comments.


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);
+

d.zobnin.bugzilla wrote:
> 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?
> So, do you think we need to compatible with MSVC, for example, also 
> considering only integer types?

I'd rather not for now. I can imagine that there's lots of code out there with 
crazy mixed up typedefs that it's useful to accept, but it's a lot less common 
to re-prototype someone else's functions incorrectly.


Comment at: lib/Sema/SemaDecl.cpp:1898-1902
@@ +1897,7 @@
+  << NewType << OldType;
+  if (OldTypedef->isModed())
+New->setModedTypeSourceInfo(OldTypedef->getTypeSourceInfo(),
+OldTypedef->getUnderlyingType());
+  else
+New->setTypeSourceInfo(OldTypedef->getTypeSourceInfo());
+  OldLocation = OldTypedef->getFirstDecl()->getLocation();

Hm, this seems like an AST fidelity issue that Richard would care about. The 
TSI should reflect the type the user wrote at this position. Maybe you could 
wrap an AdjustedType node around the original type and install that instead.


http://reviews.llvm.org/D16770



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

r259671 - Add builtins for bitreverse intrinsic

2016-02-03 Thread Matt Arsenault via cfe-commits

Author: arsenm
Date: Wed Feb  3 11:49:38 2016
New Revision: 259671

URL: http://llvm.org/viewvc/llvm-project?rev=259671&view=rev
Log:
Add builtins for bitreverse intrinsic

Follow the naming convention that bswap uses since it's a
similar sort of operation.

Modified:
cfe/trunk/include/clang/Basic/Builtins.def
cfe/trunk/lib/CodeGen/CGBuiltin.cpp
cfe/trunk/test/CodeGen/builtins.c

Modified: cfe/trunk/include/clang/Basic/Builtins.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Builtins.def?rev=259671&r1=259670&r2=259671&view=diff
==
--- cfe/trunk/include/clang/Basic/Builtins.def (original)
+++ cfe/trunk/include/clang/Basic/Builtins.def Wed Feb  3 11:49:38 2016
@@ -404,6 +404,10 @@ BUILTIN(__builtin_bswap16, "UsUs", "nc")
 BUILTIN(__builtin_bswap32, "UiUi", "nc")
 BUILTIN(__builtin_bswap64, "ULLiULLi", "nc")
 
+BUILTIN(__builtin_bitreverse16, "UsUs", "nc")
+BUILTIN(__builtin_bitreverse32, "UiUi", "nc")
+BUILTIN(__builtin_bitreverse64, "ULLiULLi", "nc")
+
 // Random GCC builtins
 BUILTIN(__builtin_constant_p, "i.", "nctu")
 BUILTIN(__builtin_classify_type, "i.", "nctu")

Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBuiltin.cpp?rev=259671&r1=259670&r2=259671&view=diff
==
--- cfe/trunk/lib/CodeGen/CGBuiltin.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp Wed Feb  3 11:49:38 2016
@@ -288,6 +288,40 @@ static llvm::Value *EmitOverflowIntrinsi
   return CGF.Builder.CreateExtractValue(Tmp, 0);
 }
 
+// Emit a simple mangled intrinsic that has 1 argument and a return type
+// matching the argument type.
+static Value *emitUnaryBuiltin(CodeGenFunction &CGF,
+   const CallExpr *E,
+   unsigned IntrinsicID) {
+  llvm::Value *Src0 = CGF.EmitScalarExpr(E->getArg(0));
+
+  Value *F = CGF.CGM.getIntrinsic(IntrinsicID, Src0->getType());
+  return CGF.Builder.CreateCall(F, Src0);
+}
+
+// Emit an intrinsic that has 3 float or double operands.
+static Value *emitTernaryFPBuiltin(CodeGenFunction &CGF,
+   const CallExpr *E,
+   unsigned IntrinsicID) {
+  llvm::Value *Src0 = CGF.EmitScalarExpr(E->getArg(0));
+  llvm::Value *Src1 = CGF.EmitScalarExpr(E->getArg(1));
+  llvm::Value *Src2 = CGF.EmitScalarExpr(E->getArg(2));
+
+  Value *F = CGF.CGM.getIntrinsic(IntrinsicID, Src0->getType());
+  return CGF.Builder.CreateCall(F, {Src0, Src1, Src2});
+}
+
+// Emit an intrinsic that has 1 float or double operand, and 1 integer.
+static Value *emitFPIntBuiltin(CodeGenFunction &CGF,
+   const CallExpr *E,
+   unsigned IntrinsicID) {
+  llvm::Value *Src0 = CGF.EmitScalarExpr(E->getArg(0));
+  llvm::Value *Src1 = CGF.EmitScalarExpr(E->getArg(1));
+
+  Value *F = CGF.CGM.getIntrinsic(IntrinsicID, Src0->getType());
+  return CGF.Builder.CreateCall(F, {Src0, Src1});
+}
+
 namespace {
   struct WidthAndSignedness {
 unsigned Width;
@@ -645,10 +679,12 @@ RValue CodeGenFunction::EmitBuiltinExpr(
   case Builtin::BI__builtin_bswap16:
   case Builtin::BI__builtin_bswap32:
   case Builtin::BI__builtin_bswap64: {
-Value *ArgValue = EmitScalarExpr(E->getArg(0));
-llvm::Type *ArgType = ArgValue->getType();
-Value *F = CGM.getIntrinsic(Intrinsic::bswap, ArgType);
-return RValue::get(Builder.CreateCall(F, ArgValue));
+return RValue::get(emitUnaryBuiltin(*this, E, Intrinsic::bswap));
+  }
+  case Builtin::BI__builtin_bitreverse16:
+  case Builtin::BI__builtin_bitreverse32:
+  case Builtin::BI__builtin_bitreverse64: {
+return RValue::get(emitUnaryBuiltin(*this, E, Intrinsic::bitreverse));
   }
   case Builtin::BI__builtin_object_size: {
 unsigned Type =
@@ -6990,39 +7026,6 @@ Value *CodeGenFunction::EmitPPCBuiltinEx
   }
 }
 
-// Emit an intrinsic that has 1 float or double.
-static Value *emitUnaryFPBuiltin(CodeGenFunction &CGF,
- const CallExpr *E,
- unsigned IntrinsicID) {
-  llvm::Value *Src0 = CGF.EmitScalarExpr(E->getArg(0));
-
-  Value *F = CGF.CGM.getIntrinsic(IntrinsicID, Src0->getType());
-  return CGF.Builder.CreateCall(F, Src0);
-}
-
-// Emit an intrinsic that has 3 float or double operands.
-static Value *emitTernaryFPBuiltin(CodeGenFunction &CGF,
-   const CallExpr *E,
-   unsigned IntrinsicID) {
-  llvm::Value *Src0 = CGF.EmitScalarExpr(E->getArg(0));
-  llvm::Value *Src1 = CGF.EmitScalarExpr(E->getArg(1));
-  llvm::Value *Src2 = CGF.EmitScalarExpr(E->getArg(2));
-
-  Value *F = CGF.CGM.getIntrinsic(IntrinsicID, Src0->getType());
-  return CGF.Builder.CreateCall(F, {Src0, Src1, Src2});
-}
-
-// Emit an intrinsic that has 1 float or double operand, and 1

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

2016-02-03 Thread Matt Arsenault via cfe-commits

arsenm closed this revision.
arsenm added a comment.

r259671.

Should I put some documentation for these somewhere? 
docs/LanguageExtensions.rst seems to be the place, but it only has a random 
subset of the current builtins.


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] D16770: [MS] PR26234: Allow typedef redefinition of equally qualified, sized and aligned types in C

2016-02-03 Thread Nico Weber via cfe-commits

thakis added a subscriber: thakis.
thakis added a comment.

Out of interest, what is this needed for? System headers?


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] D16808: [MCU] PR26438: Fix assertion failure on function returning an empty struct or union

2016-02-03 Thread David Kreitzer via cfe-commits

DavidKreitzer added a comment.

Denis, can you please explain your rationale for choosing to return 0-sized 
aggregates in memory for MCU? It doesn't match gcc behavior.  For example,

  int g;
  union U {} u;
  union U f(int a, int b, int c) { g = a + b + c; return u; }
  void f1() { f(1, 2, 3); }

Produces this, where all three incoming arguments are in registers. With your 
patch, %eax will be used for the return value pointer.

  f:
addl%eax, %edx
subl$4, %esp
addl%edx, %ecx
movl%ecx, g
popl%eax
ret

(Using i586-intel-elfiamcu-gcc 5.2.1 20150820)

HJ, even though a strict reading of the ABI suggests that a 0-size aggregate 
should be returned in register, it would be a good idea to make this more 
explicit in the ABI here, by adding the underlined text, for example.

> **Returning Values**

>  Table 2.4 lists the location used to return a value for each fundamental 
> data type.

>  Aggregate types (structs and unions) are returned as follows:

>  • Short aggregate types no larger than 8 bytes, __including 0-length 
> aggregate types,__ are returned in %edx:%eax.

>  The most significant 32 bits are returned in %edx. The least significant 32

>  bits are returned in %eax.

>  • Other aggregate types are returned in memory.





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] D16846: PR26449: Fixes for bugs in __builtin_classify_type implementation

2016-02-03 Thread John McCall via cfe-commits

rjmccall added inline comments.


Comment at: lib/AST/ExprConstant.cpp:6213
@@ -6211,3 +6212,3 @@
   else if (ArgTy->isEnumeralType())
-return enumeral_type_class;
+return LangOpts.CPlusPlus ? enumeral_type_class : integer_type_class;
   else if (ArgTy->isBooleanType())

I mean, matching GCC exactly on this weird little extension seems reasonable to 
me, but this is very strange behavior.  Sure, there's an implicit conversion to 
enum types in C, but there are implicit conversions between a lot of types that 
are distinguished.


Comment at: lib/AST/ExprConstant.cpp:6217
@@ -6215,3 +6216,3 @@
   else if (ArgTy->isCharType())
-return string_type_class; // gcc doesn't appear to use char_type_class
+return integer_type_class; // gcc doesn't appear to use char_type_class
   else if (ArgTy->isIntegerType())

You can just eliminate this case completely; it's caught by the next line.  The 
comment is good, please add it there.


Comment at: lib/AST/ExprConstant.cpp:6223
@@ -6221,3 +6222,3 @@
   else if (ArgTy->isReferenceType())
 return reference_type_class;
   else if (ArgTy->isRealType())

Note that this case is not actually possible; expressions never have reference 
type, they're just l-values or x-values.  It's vaguely possible that GCC 
actually does something like the C++11 decltype feature, which IIRC recognizes 
direct decl references and reports their declared type instead of the formal 
type of the reference expression.


Comment at: lib/AST/ExprConstant.cpp:6231
@@ -6229,1 +6230,3 @@
+  else if (ArgTy->isMemberFunctionPointerType())
+return method_type_class;
   else if (ArgTy->isStructureOrClassType())

I assume member data pointers are supposed to be offset_type_class.


Comment at: lib/AST/ExprConstant.cpp:6241
@@ -6238,2 +6240,3 @@
+  else  // FIXME: offset_type_class & lang_type_class?
 llvm_unreachable("CallExpr::isBuiltinClassifyType(): unimplemented type");
 }

We should be able to turn this into an exhaustive switch over the canonical 
types.


http://reviews.llvm.org/D16846



___
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

2016-02-03 Thread Denis Zobnin via cfe-commits

d.zobnin.bugzilla marked 2 inline comments as done.
d.zobnin.bugzilla added a comment.

@thakis, it is needed to be able to compile SPEC2000: 255.vortex.


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] D16638: [CUDA] Added device-side system call decls and related wrappers.

2016-02-03 Thread Artem Belevich via cfe-commits

tra retitled this revision from "[CUDA] Added device-side std::{malloc/free}" 
to "[CUDA] Added device-side system call decls and related wrappers.".
tra updated the summary for this revision.
tra updated this revision to Diff 46803.
tra marked 3 inline comments as done.
tra added a comment.

Addressed Justin's comments.


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
+
+// vprintf() declaration is there for type-safety, not because things
+// will fail to compile if it is removed.
+__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
+
+// vprintf() declaration is there for type-safety, not because things
+// will fail to compile if it is removed.
+__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,
+

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

2016-02-03 Thread Jonathan Coe via cfe-commits

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.

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] D16626: [x86] Correct setting of WIntType for MCU target

2016-02-03 Thread Reid Kleckner via cfe-commits

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

lgtm


http://reviews.llvm.org/D16626



___
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

2016-02-03 Thread Anastasia Stulova via cfe-commits

Anastasia added inline comments.


Comment at: lib/Sema/SemaDecl.cpp:2039
@@ +2038,3 @@
+  if (Old->isImplicit() || New->isImplicit()) {
+// Since we don't emit system header warnings for compatibility with GCC,
+// don't do this for implicit type redifinition warnings the same way.

redifinition -> redefinition


Comment at: test/SemaOpenCL/implicit-typedef.cl:1
@@ +1,2 @@
+// RUN: %clang_cc1 %s -cl-std=CL2.0 -verify -pedantic -fsyntax-only 
-Wsystem-headers
+typedef atomic_int atomic_flag; // expected-warning {{redefinition of typedef 
'atomic_flag' is a C11 feature}}

Could we also add a run line without  -Wsystem-headers.

You can pass -D and use #ifdef for checking the error conditionally in this 
test. 


Comment at: test/SemaOpenCL/implicit-typedef.cl:2
@@ +1,2 @@
+// RUN: %clang_cc1 %s -cl-std=CL2.0 -verify -pedantic -fsyntax-only 
-Wsystem-headers
+typedef atomic_int atomic_flag; // expected-warning {{redefinition of typedef 
'atomic_flag' is a C11 feature}}

ichesnokov wrote:
> ichesnokov wrote:
> > Test case command line fixed.
> Added a warning (reused existing C/C++). Warning is checked in test case.
atomic_flag is a part of OpenCL not C11 here.

I think it would be nicer to change this error to use select and pass either 
C11 or OpenCL.


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] D16686: [OpenCL] Generate metadata for opencl_unroll_hint attribute

2016-02-03 Thread Anastasia Stulova via cfe-commits

Anastasia added inline comments.


Comment at: lib/Sema/SemaStmtAttr.cpp:230
@@ +229,3 @@
+  << A.getName() << AANT_ArgumentIntegerConstant << 
E->getSourceRange();
+  return 0;
+}

0 -> nullptr


http://reviews.llvm.org/D16686



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

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

2016-02-03 Thread Alexey Samsonov via cfe-commits

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

LGTM



Comment at: lib/CodeGen/CGClass.cpp:2608
@@ -2607,3 +2607,3 @@
   auto TypeId = CGM.CreateCfiIdForTypeMetadata(MD);
   if (CGM.getCodeGenOpts().SanitizeCfiCrossDso && TypeId) {
 EmitCfiSlowPathCheck(M, BitSetTest, TypeId, CastedVTable, StaticData);

Can we rewrite this as if-elseif-else block now?


Comment at: lib/CodeGen/CGExpr.cpp:2642
@@ +2641,3 @@
+  llvm::MDString::get(CGM.getLLVMContext(), "all-vtables"));
+  llvm::Value *ValidVtable = Builder.CreateZExt(
+  Builder.CreateCall(CGM.getIntrinsic(llvm::Intrinsic::bitset_test),

eugenis wrote:
> samsonov wrote:
> > This is almost the same as EmitVTablePtrCheck, but with ZExt? Is the 
> > difference intentional/important? Is it possible to extract this logic 
> > (getting "all-vtables" metadata and running bitset test) to a function?
> Not important. Zext makes the test a bit simpler.
> Extracting these two lines to a function is surely possible, but is it worth 
> it?
> 
Probably not, as long as we have the test coverage.


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] D16376: clang-tidy check: rule-of-five

2016-02-03 Thread David Blaikie via cfe-commits

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.

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."

(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

r259677 - Fix regression from r259622: the operand of an increment that is the operand of

2016-02-03 Thread Richard Smith via cfe-commits

Author: rsmith
Date: Wed Feb  3 12:48:43 2016
New Revision: 259677

URL: http://llvm.org/viewvc/llvm-project?rev=259677&view=rev
Log:
Fix regression from r259622: the operand of an increment that is the operand of
a cast expression is not the operand of a cast expression itself, so if it's
parenthesized we need to form a ParenExpr not a ParenListExpr.

Modified:
cfe/trunk/lib/Parse/ParseExpr.cpp
cfe/trunk/test/Parser/cxx-ambig-paren-expr.cpp

Modified: cfe/trunk/lib/Parse/ParseExpr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/ParseExpr.cpp?rev=259677&r1=259676&r2=259677&view=diff
==
--- cfe/trunk/lib/Parse/ParseExpr.cpp (original)
+++ cfe/trunk/lib/Parse/ParseExpr.cpp Wed Feb  3 12:48:43 2016
@@ -516,7 +516,7 @@ class CastExpressionIdValidator : public
 /// \p isAddressOfOperand exists because an id-expression that is the operand
 /// of address-of gets special treatment due to member pointers. NotCastExpr
 /// is set to true if the token is not the start of a cast-expression, and no
-/// diagnostic is emitted in this case.
+/// diagnostic is emitted in this case and no tokens are consumed.
 ///
 /// \verbatim
 ///   cast-expression: [C99 6.5.4]
@@ -1020,7 +1020,7 @@ ExprResult Parser::ParseCastExpression(b
 // determine whether the '++' is prefix or postfix.
 Res = ParseCastExpression(!getLangOpts().CPlusPlus,
   /*isAddressOfOperand*/false, NotCastExpr,
-  isTypeCast);
+  NotTypeCast);
 if (NotCastExpr) {
   // If we return with NotCastExpr = true, we must not consume any tokens,
   // so put the token back where we found it.

Modified: cfe/trunk/test/Parser/cxx-ambig-paren-expr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Parser/cxx-ambig-paren-expr.cpp?rev=259677&r1=259676&r2=259677&view=diff
==
--- cfe/trunk/test/Parser/cxx-ambig-paren-expr.cpp (original)
+++ cfe/trunk/test/Parser/cxx-ambig-paren-expr.cpp Wed Feb  3 12:48:43 2016
@@ -28,6 +28,7 @@ void f() {
   int &postfix_incr = (X()[3])++;
   (X())++ ++; // ok, not a C-style cast
   (X())++ ++X(); // expected-error {{C-style cast from 'int' to 'X ()'}}
+  int q = (int)++(x);
 }
 
 // Make sure we do tentative parsing correctly in conditions.


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

Re: r259622 - Fix miscompile and rejects-valids when disambiguating after an ambiguous

2016-02-03 Thread Richard Smith via cfe-commits

On Wed, Feb 3, 2016 at 9:30 AM, Renato Golin  wrote:
> On 3 February 2016 at 02:58, Richard Smith via cfe-commits
>  wrote:
>> Author: rsmith
>> Date: Tue Feb  2 20:58:20 2016
>> New Revision: 259622
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=259622&view=rev
>> Log:
>> Fix miscompile and rejects-valids when disambiguating after an ambiguous
>> C-style-cast to function/array type or parenthesized function-style 
>> cast/array
>> indexing.
>
> Hi Richard,
>
> After bisecting, I found that your commit is the responsible for this
> test-suite failure on AArch64:
>
> 1. 
> /external/buildbot/clang-native-arm-lnt/test/test-suite/MultiSource/Benchmarks/MallocBench/gs/zpaint.c:181:45:
> current parser token ';'
> 2. 
> /external/buildbot/clang-native-arm-lnt/test/test-suite/MultiSource/Benchmarks/MallocBench/gs/zpaint.c:165:1:
> parsing function body 'image_continue'
> 3. 
> /external/buildbot/clang-native-arm-lnt/test/test-suite/MultiSource/Benchmarks/MallocBench/gs/zpaint.c:165:1:
> in compound statement ('{}')
> 4. 
> /external/buildbot/clang-native-arm-lnt/test/test-suite/MultiSource/Benchmarks/MallocBench/gs/zpaint.c:181:5:
> in compound statement ('{}')
>
> http://lab.llvm.org:8011/builders/clang-cmake-aarch64-full/builds/1330
>
> http://lab.llvm.org:8011/builders/clang-native-arm-lnt/builds/16211
>
> http://lab.llvm.org:8011/builders/clang-cmake-aarch64-quick/builds/4487
>
> Can you have a look, please?

Fixed in r259677, sorry about that!
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r259678 - Added Anastasia Stulova as a code owner for OpenCL

2016-02-03 Thread Anastasia Stulova via cfe-commits

Author: stulova
Date: Wed Feb  3 12:51:19 2016
New Revision: 259678

URL: http://llvm.org/viewvc/llvm-project?rev=259678&view=rev
Log:
Added Anastasia Stulova as a code owner for OpenCL

Reviewers: Chris Lattner

Subscribers: cfe-dev


Modified:
cfe/trunk/CODE_OWNERS.TXT

Modified: cfe/trunk/CODE_OWNERS.TXT
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/CODE_OWNERS.TXT?rev=259678&r1=259677&r2=259678&view=diff
==
--- cfe/trunk/CODE_OWNERS.TXT (original)
+++ cfe/trunk/CODE_OWNERS.TXT Wed Feb  3 12:51:19 2016
@@ -52,3 +52,7 @@ D: Clang LLVM IR generation
 N: Richard Smith
 E: rich...@metafoo.co.uk
 D: All parts of Clang not covered by someone else
+
+N: Anastasia Stulova
+E: anastasia.stul...@arm.com
+D: OpenCL support


___
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.

2016-02-03 Thread Justin Lebar via cfe-commits

jlebar added a comment.

lg with one question about printf.



Comment at: lib/Headers/__clang_cuda_runtime_wrapper.h:237
@@ +236,3 @@
+// device-side declaration for it.
+__device__ int printf(const char *, ...);
+} // extern "C"

I think we want an attribute on this so that we know it's printf-like, so you 
get appropriate format-string warnings.  Unless the compiler is going to add 
said attribute automatically based on the just the function name.


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: r259622 - Fix miscompile and rejects-valids when disambiguating after an ambiguous

2016-02-03 Thread Bill Seurer via cfe-commits


On 02/03/16 11:30, Renato Golin via cfe-commits wrote:

On 3 February 2016 at 02:58, Richard Smith via cfe-commits
 wrote:

Author: rsmith
Date: Tue Feb  2 20:58:20 2016
New Revision: 259622

URL: http://llvm.org/viewvc/llvm-project?rev=259622&view=rev
Log:
Fix miscompile and rejects-valids when disambiguating after an ambiguous
C-style-cast to function/array type or parenthesized function-style cast/array
indexing.


Hi Richard,

After bisecting, I found that your commit is the responsible for this
test-suite failure on AArch64:

1. 
/external/buildbot/clang-native-arm-lnt/test/test-suite/MultiSource/Benchmarks/MallocBench/gs/zpaint.c:181:45:
current parser token ';'
2. 
/external/buildbot/clang-native-arm-lnt/test/test-suite/MultiSource/Benchmarks/MallocBench/gs/zpaint.c:165:1:
parsing function body 'image_continue'
3. 
/external/buildbot/clang-native-arm-lnt/test/test-suite/MultiSource/Benchmarks/MallocBench/gs/zpaint.c:165:1:
in compound statement ('{}')
4. 
/external/buildbot/clang-native-arm-lnt/test/test-suite/MultiSource/Benchmarks/MallocBench/gs/zpaint.c:181:5:
in compound statement ('{}')

http://lab.llvm.org:8011/builders/clang-cmake-aarch64-full/builds/1330

http://lab.llvm.org:8011/builders/clang-native-arm-lnt/builds/16211

http://lab.llvm.org:8011/builders/clang-cmake-aarch64-quick/builds/4487

Can you have a look, please?

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



This causes a similar failure on powerpc64 (both big and little endian). 
 Note that this was found during the running of the lnt tests.



	  /home/seurer/llvm/install/llvm-test3/bin/clang -DNOMEMOPT 
-DGS_LIB_DEFAULT=\"/home/seurer/llvm-test-suite/MultiSource/Benchmarks/MallocBench/gs:/home/seurer/llvm-test-suite/MultiSource/Benchmarks/MallocBench/gs/fonts\" 
-DNOPRIVATE 
-I/home/seurer/sandbox/test-2016-02-03_18-03-09/MultiSource/Benchmarks/MallocBench/gs 
-I/home/seurer/llvm-test-suite/MultiSource/Benchmarks/MallocBench/gs 
-I/home/seurer/llvm-test-suite/include -I../../../../include 
-D_GNU_SOURCE -D__STDC_LIMIT_MACROS -DNDEBUG 
-Wno-implicit-function-declaration -O3  -ffp-contract=off 
-fomit-frame-pointer -c 
/home/seurer/llvm-test-suite/MultiSource/Benchmarks/MallocBench/gs/zpaint.c 
-o Output/zpaint.llvm.o
TEST /home/seurer/llvm/install/llvm-test3/bin/clang FAILED: process 
terminated by signal (exit status 254)!
error: command failed while generating 
/home/seurer/sandbox/test-2016-02-03_18-03-09/MultiSource/Benchmarks/MallocBench/gs/Output/zpaint.llvm.o.compile

---
clang-3.9: 
/home/seurer/llvm/llvm-test3/tools/clang/include/clang/AST/Type.h:589: 
const clang::ExtQualsTypeCommonBase* clang::QualType::getCommonPtr() 
const: Assertion `!isNull() && "Cannot retrieve a NULL type pointer"' 
failed.
0  clang-3.9 0x11975ad4 
llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 116

1  clang-3.9 0x11975f30
2  clang-3.9 0x11972dfc llvm::sys::RunSignalHandlers() + 124
3  clang-3.9 0x119730e0
40x10040478 __kernel_sigtramp_rt64 + 0
5  libc.so.6 0x104d0a88 gsignal + 72
6  libc.so.6 0x104d693c abort + 620
7  libc.so.6 0x104c65b4
8  libc.so.6 0x104c66a4 __assert_fail + 100
9  clang-3.9 0x12811dec clang::Sema::BuildUnaryOp(clang::Scope*, 
clang::SourceLocation, clang::UnaryOperatorKind, clang::Expr*) + 236
10 clang-3.9 0x12812214 clang::Sema::ActOnUnaryOp(clang::Scope*, 
clang::SourceLocation, clang::tok::TokenKind, clang::Expr*) + 68
11 clang-3.9 0x124a6664 clang::Parser::ParseCastExpression(bool, 
bool, bool&, clang::Parser::TypeCastState) + 5188
12 clang-3.9 0x124a779c clang::Parser::ParseCastExpression(bool, 
bool, clang::Parser::TypeCastState) + 44
13 clang-3.9 0x124ac928 
clang::Parser::ParseParenExpression(clang::Parser::ParenParseOption&, 
bool, bool, clang::OpaquePtr&, clang::SourceLocation&) 
+ 2376
14 clang-3.9 0x124a5b68 clang::Parser::ParseCastExpression(bool, 
bool, bool&, clang::Parser::TypeCastState) + 2376
15 clang-3.9 0x124a779c clang::Parser::ParseCastExpression(bool, 
bool, clang::Parser::TypeCastState) + 44
16 clang-3.9 0x124a7888 
clang::Parser::ParseAssignmentExpression(clang::Parser::TypeCastState) + 72
17 clang-3.9 0x1247d144 
clang::Parser::ParseDeclarationAfterDeclaratorAndAttributes(clang::Declarator&, 
clang::Parser::ParsedTemplateInfo const&, clang::Parser::ForRangeInit*) 
+ 756
18 clang-3.9 0x12489fa0 
clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, unsigned int, 
clang::SourceLocation*, clang::Parser::ForRangeInit*) + 1472
19 clang-3.9 0x1248c978 
clang::Parser::ParseSimpleDeclaration(unsigned int, 
clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&, bool, 
clang::Parser::ForRangeInit*) + 536
20 clang-3.9 0x1248ce20 clang::Parser::ParseDeclaration(unsigned 
int, clang::Sour

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

2016-02-03 Thread Anastasia Stulova via cfe-commits

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?

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.

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&view=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&r1=258781&r2=258782&view=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) 
>> +LANGBUILTIN(work_group_commit_write_pipe, "v.", "tn", OCLC_LANG)
>> +
>> +LANGBUILTIN(get_pipe_num_packets, "Ui.", "tn", OCLC_LANG) 
>> +LANGBUILTIN(get_pipe_max_packets, "Ui.", "tn", OCLC_LANG)
>> +
>>  #undef BUILTIN
>>  #undef LIBBUILTIN
>>  #undef LANGBUILTIN
>>
>> Modified: cfe/trunk/include/clang/Basic/Builtins.h
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Bui
>> ltins.h?rev=258782&r1=258781&r2=258782&view=diff
>> =
>> =
>> --- cfe/trunk/include/clang/Basic/Builtins.h (original)
>> +++ cfe/trunk/include/clang/Basic/Builtins.h Mon Jan 25 22:03:48 2016
>> @@ -36,6 +36,7 @@ enum LanguageID {
>>CXX_LANG = 0x4,  // builtin for cplusplus only.
>>OBJC_LANG

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

2016-02-03 Thread Artem Belevich via cfe-commits

tra added inline comments.


Comment at: lib/Headers/__clang_cuda_runtime_wrapper.h:232
@@ +231,3 @@
+// Clang will convert printf into vprintf, but we still need
+// device-side declaration for it.
+__device__ int printf(const char *, ...);

jlebar wrote:
> I'd prefer to keep the information from the previous comment: This 
> declaration is there for type-safety, not because things will fail to compile 
> if it is removed.
> 
> Otherwise someone may look at this, delete this definition, see that 
> everything still works, and conclude that they can safely remove this line.
I don't quite see what makes vprintf() special compared to other decls here or, 
let's say, in /usr/include/*.h. I think 'declaration is there for type safety' 
applies to all of them and does not need to be spelled out for each individual 
decl.



Comment at: lib/Headers/__clang_cuda_runtime_wrapper.h:237
@@ +236,3 @@
+// device-side declaration for it.
+__device__ int printf(const char *, ...);
+} // extern "C"

jlebar wrote:
> I think we want an attribute on this so that we know it's printf-like, so you 
> get appropriate format-string warnings.  Unless the compiler is going to add 
> said attribute automatically based on the just the function name.
I've verified that lang is already aware that it's printf and checks arguments 
against format string appropriately.


http://reviews.llvm.org/D16638



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

r259681 - [Sema debugger support] Require non-void types to be complete in unknown-anytype casts.

2016-02-03 Thread Douglas Gregor via cfe-commits

Author: dgregor
Date: Wed Feb  3 13:13:08 2016
New Revision: 259681

URL: http://llvm.org/viewvc/llvm-project?rev=259681&view=rev
Log:
[Sema debugger support] Require non-void types to be complete in 
unknown-anytype casts.

When performing a cast from an __unknown_anytype function call to a
non-void type, we need to make sure that type is complete. Fixes
rdar://problem/23959960.

Modified:
cfe/trunk/lib/Sema/SemaExpr.cpp
cfe/trunk/test/SemaCXX/unknown-anytype.cpp

Modified: cfe/trunk/lib/Sema/SemaExpr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaExpr.cpp?rev=259681&r1=259680&r2=259681&view=diff
==
--- cfe/trunk/lib/Sema/SemaExpr.cpp (original)
+++ cfe/trunk/lib/Sema/SemaExpr.cpp Wed Feb  3 13:13:08 2016
@@ -14478,6 +14478,12 @@ ExprResult RebuildUnknownAnyExpr::resolv
 ExprResult Sema::checkUnknownAnyCast(SourceRange TypeRange, QualType CastType,
  Expr *CastExpr, CastKind &CastKind,
  ExprValueKind &VK, CXXCastPath &Path) {
+  // The type we're casting to must be either void or complete.
+  if (!CastType->isVoidType() &&
+  RequireCompleteType(TypeRange.getBegin(), CastType,
+  diag::err_typecheck_cast_to_incomplete))
+return ExprError();
+
   // Rewrite the casted expression from scratch.
   ExprResult result = RebuildUnknownAnyExpr(*this, CastType).Visit(CastExpr);
   if (!result.isUsable()) return ExprError();

Modified: cfe/trunk/test/SemaCXX/unknown-anytype.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/unknown-anytype.cpp?rev=259681&r1=259680&r2=259681&view=diff
==
--- cfe/trunk/test/SemaCXX/unknown-anytype.cpp (original)
+++ cfe/trunk/test/SemaCXX/unknown-anytype.cpp Wed Feb  3 13:13:08 2016
@@ -45,3 +45,14 @@ namespace test4 {
 int x = (int) test1; // expected-error {{function 'test1' with unknown 
type must be given a function type}}
   }
 }
+
+// rdar://problem/23959960
+namespace test5 {
+  template struct X; // expected-note{{template is declared here}}
+
+  extern __unknown_anytype test0(...);
+
+  void test() {
+(X)test0(); // expected-error{{implicit instantiation of undefined 
template 'test5::X'}}
+  }
+}


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

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

2016-02-03 Thread Marshall Clow via cfe-commits

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

LGTM


http://reviews.llvm.org/D16467



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

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

2016-02-03 Thread Duncan P. N. Exon Smith via cfe-commits

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

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

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

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

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

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

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

2016-02-03 Thread Duncan P. N. Exon Smith via cfe-commits

Committed in r259682.

> On 2016-Feb-03, at 11:16, Marshall Clow  wrote:
> 
> mclow.lists accepted this revision.
> mclow.lists added a comment.
> This revision is now accepted and ready to land.
> 
> LGTM
> 
> 
> http://reviews.llvm.org/D16467
> 
> 
> 

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

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

2016-02-03 Thread Duncan P. N. Exon Smith via cfe-commits

dexonsmith added a comment.

Committed in r259682.


http://reviews.llvm.org/D16467



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

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

2016-02-03 Thread Evgeniy Stepanov via cfe-commits

eugenis added inline comments.


Comment at: lib/CodeGen/CGClass.cpp:2608
@@ -2607,3 +2607,3 @@
   auto TypeId = CGM.CreateCfiIdForTypeMetadata(MD);
   if (CGM.getCodeGenOpts().SanitizeCfiCrossDso && TypeId) {
 EmitCfiSlowPathCheck(M, BitSetTest, TypeId, CastedVTable, StaticData);

samsonov wrote:
> Can we rewrite this as if-elseif-else block now?
even better, with 2 early returns.


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] D16823: [cfi] Safe handling of unaddressable vtable pointers (clang).

2016-02-03 Thread Evgeniy Stepanov via cfe-commits

eugenis updated this revision to Diff 46807.

Repository:
  rL LLVM

http://reviews.llvm.org/D16823

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

Index: test/CodeGenCXX/cfi-vcall.cpp
===
--- test/CodeGenCXX/cfi-vcall.cpp
+++ test/CodeGenCXX/cfi-vcall.cpp
@@ -1,5 +1,5 @@
-// RUN: %clang_cc1 -triple x86_64-unknown-linux -fsanitize=cfi-vcall -fsanitize-trap=cfi-vcall -emit-llvm -o - %s | FileCheck --check-prefix=CHECK --check-prefix=ITANIUM --check-prefix=NDIAG %s
-// RUN: %clang_cc1 -triple x86_64-unknown-linux -fsanitize=cfi-vcall -emit-llvm -o - %s | FileCheck --check-prefix=CHECK --check-prefix=ITANIUM --check-prefix=DIAG --check-prefix=DIAG-ABORT %s
+// RUN: %clang_cc1 -triple x86_64-unknown-linux -fsanitize=cfi-vcall -fsanitize-trap=cfi-vcall -emit-llvm -o - %s | FileCheck --check-prefix=CHECK --check-prefix=ITANIUM --check-prefix=ITANIUM-NDIAG --check-prefix=NDIAG %s
+// RUN: %clang_cc1 -triple x86_64-unknown-linux -fsanitize=cfi-vcall -emit-llvm -o - %s | FileCheck --check-prefix=CHECK --check-prefix=ITANIUM --check-prefix=ITANIUM-DIAG --check-prefix=DIAG --check-prefix=DIAG-ABORT %s
 // RUN: %clang_cc1 -triple x86_64-unknown-linux -fsanitize=cfi-vcall -fsanitize-recover=cfi-vcall -emit-llvm -o - %s | FileCheck --check-prefix=CHECK --check-prefix=ITANIUM --check-prefix=DIAG --check-prefix=DIAG-RECOVER %s
 // RUN: %clang_cc1 -triple x86_64-pc-windows-msvc -fsanitize=cfi-vcall -fsanitize-trap=cfi-vcall -emit-llvm -o - %s | FileCheck --check-prefix=CHECK --check-prefix=MS --check-prefix=NDIAG %s
 
@@ -55,23 +55,25 @@
 
 // DIAG: @[[SRC:.*]] = private unnamed_addr constant [{{.*}} x i8] c"{{.*}}cfi-vcall.cpp\00", align 1
 // DIAG: @[[TYPE:.*]] = private unnamed_addr constant { i16, i16, [4 x i8] } { i16 -1, i16 0, [4 x i8] c"'A'\00" }
-// DIAG: @[[BADTYPESTATIC:.*]] = private unnamed_addr global { i8, { [{{.*}} x i8]*, i32, i32 }, { i16, i16, [4 x i8] }* } { i8 0, { [{{.*}} x i8]*, i32, i32 } { [{{.*}} x i8]* @[[SRC]], i32 [[@LINE+21]], i32 3 }, { i16, i16, [4 x i8] }* @[[TYPE]] }
+// DIAG: @[[BADTYPESTATIC:.*]] = private unnamed_addr global { i8, { [{{.*}} x i8]*, i32, i32 }, { i16, i16, [4 x i8] }* } { i8 0, { [{{.*}} x i8]*, i32, i32 } { [{{.*}} x i8]* @[[SRC]], i32 [[@LINE+23]], i32 3 }, { i16, i16, [4 x i8] }* @[[TYPE]] }
 
 // ITANIUM: define void @_Z2afP1A
 // MS: define void @"\01?af@@YAXPEAUA@@@Z"
 void af(A *a) {
   // ITANIUM: [[P:%[^ ]*]] = call i1 @llvm.bitset.test(i8* [[VT:%[^ ]*]], metadata !"_ZTS1A")
   // MS: [[P:%[^ ]*]] = call i1 @llvm.bitset.test(i8* [[VT:%[^ ]*]], metadata !"?AUA@@")
+  // DIAG-NEXT: [[VTVALID0:%[^ ]*]] = call i1 @llvm.bitset.test(i8* [[VT]], metadata !"all-vtables")
   // CHECK-NEXT: br i1 [[P]], label %[[CONTBB:[^ ,]*]], label %[[TRAPBB:[^ ,]*]]
   // CHECK-NEXT: {{^$}}
 
   // CHECK: [[TRAPBB]]
   // NDIAG-NEXT: call void @llvm.trap()
   // NDIAG-NEXT: unreachable
   // DIAG-NEXT: [[VTINT:%[^ ]*]] = ptrtoint i8* [[VT]] to i64
-  // DIAG-ABORT-NEXT: call void @__ubsan_handle_cfi_check_fail_abort(i8* getelementptr inbounds ({{.*}} @[[BADTYPESTATIC]], i32 0, i32 0), i64 [[VTINT]])
+  // DIAG-NEXT: [[VTVALID:%[^ ]*]] = zext i1 [[VTVALID0]] to i64
+  // DIAG-ABORT-NEXT: call void @__ubsan_handle_cfi_check_fail_abort(i8* getelementptr inbounds ({{.*}} @[[BADTYPESTATIC]], i32 0, i32 0), i64 [[VTINT]], i64 [[VTVALID]])
   // DIAG-ABORT-NEXT: unreachable
-  // DIAG-RECOVER-NEXT: call void @__ubsan_handle_cfi_check_fail(i8* getelementptr inbounds ({{.*}} @[[BADTYPESTATIC]], i32 0, i32 0), i64 [[VTINT]])
+  // DIAG-RECOVER-NEXT: call void @__ubsan_handle_cfi_check_fail(i8* getelementptr inbounds ({{.*}} @[[BADTYPESTATIC]], i32 0, i32 0), i64 [[VTINT]], i64 [[VTVALID]])
   // DIAG-RECOVER-NEXT: br label %[[CONTBB]]
 
   // CHECK: [[CONTBB]]
@@ -157,32 +159,47 @@
 
 }
 
-// Check for the expected number of elements (9 or 15 respectively).
-// MS: !llvm.bitsets = !{[[X:[^,]*(,[^,]*){8}]]}
-// ITANIUM: !llvm.bitsets = !{[[X:[^,]*(,[^,]*){14}]]}
+// Check for the expected number of elements (15 or 23 respectively).
+// MS-NDIAG: !llvm.bitsets = !{[[X:[^,]*(,[^,]*){9}]]}
+// MS-DIAG: !llvm.bitsets = !{[[X:[^,]*(,[^,]*){15}]]}
+// ITANIUM-NDIAG: !llvm.bitsets = !{[[X:[^,]*(,[^,]*){14}]]}
+// ITANIUM-DIAG: !llvm.bitsets = !{[[X:[^,]*(,[^,]*){23}]]}
 
 // ITANIUM-DAG: !{!"_ZTS1A", [3 x i8*]* @_ZTV1A, i64 16}
+// ITANIUM-DIAG-DAG: !{!"all-vtables", [3 x i8*]* @_ZTV1A, i64 16}
 // ITANIUM-DAG: !{!"_ZTS1A", [7 x i8*]* @_ZTCN12_GLOBAL__N_11DE0_1B, i64 32}
+// ITANIUM-DIAG-DAG: !{!"all-vtables", [7 x i8*]* @_ZTCN12_GLOBAL__N_11DE0_1B, i64 32}
 // ITANIUM-DAG: !{!"_ZTS1B", [7 x i8*]* @_ZTCN12_GLOBAL__N_11DE0_1B, i64 32}
 // ITANIUM-DAG: !{!"_ZTS1A", [9 x i8*]* @_ZTCN12_GLOBAL__N_11DE8_1C, i64 64}
+// ITANIUM-DIAG-DAG: !{!"all-vtables", [9 x i8*]* @_ZTCN12_GLOB

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

2016-02-03 Thread Douglas Gregor via cfe-commits


> 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&view=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&r1=259623&r2=259624&view=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 = &Context.Idents.get("Protocol");
> if (IdResolver.begin(Protocol) == IdResolver.end())
>   PushOnScopeChains(Context.getObjCProtocolDecl(), TUScope);
> +
> +DeclarationName ConstantString = &Context.Idents.get("NSConstantString");
> +if (IdResolver.begin(ConstantString) == IdResolver.end())
> +  PushOnScopeChains(Context.getCFConstantStringDecl(), TUScope);

Shouldn’t this be looking for __NSConstantString?

Also, isn’t CFSTR available even in C? This code path is Objective-C-only...

- Doug


___
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

2016-02-03 Thread Ben Langmuir via cfe-commits


> 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&view=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&r1=259623&r2=259624&view=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 = &Context.Idents.get("Protocol");
>>if (IdResolver.begin(Protocol) == IdResolver.end())
>>  PushOnScopeChains(Context.getObjCProtocolDecl(), TUScope);
>> +
>> +DeclarationName ConstantString = 
>> &Context.Idents.get("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

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

2016-02-03 Thread Alexander Riccio via cfe-commits

ariccio added a comment.

In http://reviews.llvm.org/D16748#343011, @aaron.ballman wrote:

> 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


Oops.


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] D16482: Add builtins for bitreverse intrinsic

2016-02-03 Thread Hal Finkel via cfe-commits

hfinkel added a comment.

In http://reviews.llvm.org/D16482#343177, @arsenm wrote:

> r259671.
>
> Should I put some documentation for these somewhere? 
> docs/LanguageExtensions.rst seems to be the place, but it only has a random 
> subset of the current builtins.

My impression is that we prioritize documenting the builtins that don't have 
GCC equivalents. Thus, documenting them there along with the other assorted 
Clang-specific builtins seems reasonable.

http://reviews.llvm.org/D16482

___
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.

2016-02-03 Thread 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&view=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&r1=259686&r2=259687&view=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 &S, NamedDecl *Param,
DeducedTemplateArgument Arg,
NamedDecl *Template,
-   QualType NTTPType,
-   unsigned ArgumentPackIndex,
TemplateDeductionInfo &Info,
bool InFunctionTemplate,
SmallVectorImpl &Output) {
+  // 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 &S,
   // 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] D15829: [PGO] Clang Option that enables IR level PGO instrumentation

2016-02-03 Thread 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 alongside a 
>> compiler upgrade, using the workaround

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

2016-02-03 Thread 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 is

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

2016-02-03 Thread 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] D16044: getVariableName() for MemRegion

2016-02-03 Thread 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] D15829: [PGO] Clang Option that enables IR level PGO instrumentation

2016-02-03 Thread 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
> properly. The question is whether we have a need to support merging
> pro

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

2016-02-03 Thread 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

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

2016-02-03 Thread 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&view=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&r1=259687&r2=259688&view=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 &S,
   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&view=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 &a(...);
+int &a_disabled = a(0);
+int &a_enabled = a(Q()); // expected-error {{cannot bind to a temporary of 
type 'void'}}
+
+template class ...X> void b(T);
+int &b(...);
+int &b_disabled = b(0);
+int &b_enabled = b(Q()); // expected-error {{cannot bind to a temporary of 
type 'void'}}
+
+template class ...X> void c(T);
+int &c(...);
+int &c_disabled = c(0);
+int &c_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: [PATCH] D16638: [CUDA] Added device-side system call decls and related wrappers.

2016-02-03 Thread 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, functio

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

2016-02-03 Thread 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

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

2016-02-03 Thread 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&view=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&r1=259689&r2=259690&view=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] D16638: [CUDA] Added device-side system call decls and related wrappers.

2016-02-03 Thread 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: r258782 - Recommit: R258773 [OpenCL] Pipe builtin functions

2016-02-03 Thread 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&view=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&r1=258781&r2=258782&view=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)
> >> +LANGBUILTIN(work_group_commit

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

2016-02-03 Thread 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] D16259: Add clang-tidy readability-redundant-control-flow check

2016-02-03 Thread 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] D13893: Roll-back r250822.

2016-02-03 Thread 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: [PATCH] D13893: Roll-back r250822.

2016-02-03 Thread 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] D16376: clang-tidy check: rule-of-five

2016-02-03 Thread 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
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>

>>>
>>
>

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

2016-02-03 Thread 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 &Opts, ArgList &Args, InputKind IK,
+  const TargetOptions &TargetOpts,
   DiagnosticsEngine &Diags) {
   // 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 &CGM) : CGOpenMPRuntime(CGM) {}
+};
+
+CGOpenMPRuntime *
+CGOpenMPRuntime::createCGOpenMPRuntimeNVPTX(CodeGenModule &CGM) {
+  return new CGOpenMPRuntimeNVPTX(CGM);
+}
+} // CodeGen namespace.
+}

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

2016-02-03 Thread 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 &CGF, 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 &CGF, const Expr *Cond,
+const RegionCodeGenTy &ThenGen,
+const RegionCodeGenTy &ElseGen);
+

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 &CGM) : 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

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

2016-02-03 Thread 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] D16545: [libcxxabi] Enable testing for static libc++abi

2016-02-03 Thread 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] D16044: getVariableName() for MemRegion

2016-02-03 Thread 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

1 2 >

1 - 100 of 164 matches

Mail list logo