Re: [PATCH] D17130: Debloat some headers

[Craig Topper via cfe-commits]

craig.topper added a subscriber: craig.topper.
craig.topper added a comment.

What's complex about the SVal constructors?



Comment at: 
llvm/tools/clang/include/clang/StaticAnalyzer/Core/PathSensitive/CoreEngine.h:143
@@ -144,3 +142,3 @@
   void addAbortedBlock(const ExplodedNode *node, const CFGBlock *block) {
-blocksAborted.push_back(std::make_pair(block, node));
+blocksAborted.emplace_back(block, node);
   }

I think previous discussions on the mail list have talked about only using 
emplace_back if the type isn't trivially copyable/moveable.


http://reviews.llvm.org/D17130



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

[PATCH] D17130: Debloat some headers

[Alexander Riccio via cfe-commits]

ariccio created this revision.
ariccio added a subscriber: cfe-commits.

As discussed in "Code in headers" on llvm-dev, there are lots of headers with 
complex code in them. I've moved some complex constructors & destructors to 
implementation files, using [[ 
https://www.chromium.org/developers/coding-style/cpp-dos-and-donts | Chromium's 
C++ Dos and Don'ts ]] as a guide.

It's compiling right now, and there're a few errors. I'll update the diff in a 
few minutes.

These changes are mostly in the Static Analyzer, as some files there take more 
than 30 seconds to compile.

http://reviews.llvm.org/D17130

Files:
  llvm/tools/clang/include/clang/StaticAnalyzer/Core/BugReporter/BugReporter.h
  llvm/tools/clang/include/clang/StaticAnalyzer/Core/CheckerManager.h
  llvm/tools/clang/include/clang/StaticAnalyzer/Core/PathSensitive/CoreEngine.h
  llvm/tools/clang/include/clang/StaticAnalyzer/Core/PathSensitive/SVals.h
  llvm/tools/clang/lib/StaticAnalyzer/Core/BugReporter.cpp
  llvm/tools/clang/lib/StaticAnalyzer/Core/CheckerManager.cpp
  llvm/tools/clang/lib/StaticAnalyzer/Core/CoreEngine.cpp
  llvm/tools/clang/lib/StaticAnalyzer/Core/SVals.cpp

Index: llvm/tools/clang/lib/StaticAnalyzer/Core/BugReporter.cpp
===
--- llvm/tools/clang/lib/StaticAnalyzer/Core/BugReporter.cpp
+++ llvm/tools/clang/lib/StaticAnalyzer/Core/BugReporter.cpp
@@ -2680,6 +2680,30 @@
   delete interestingRegions.pop_back_val();
 }
 
+BugReport::BugReport(BugType& bt, StringRef desc, const ExplodedNode *errornode)
+  : BT(bt), DeclWithIssue(nullptr), Description(desc), ErrorNode(errornode),
+ConfigurationChangeToken(0), DoNotPrunePath(false) {}
+
+BugReport::BugReport(BugType& bt, StringRef shortDesc, StringRef desc,
+  const ExplodedNode *errornode)
+  : BT(bt), DeclWithIssue(nullptr), ShortDescription(shortDesc),
+Description(desc), ErrorNode(errornode), ConfigurationChangeToken(0),
+DoNotPrunePath(false) {}
+
+BugReport::BugReport(BugType &bt, StringRef desc, PathDiagnosticLocation l)
+  : BT(bt), DeclWithIssue(nullptr), Description(desc), Location(l),
+ErrorNode(nullptr), ConfigurationChangeToken(0), DoNotPrunePath(false) {}
+
+BugReport::BugReport(BugType& bt, StringRef desc, const ExplodedNode *errornode,
+  PathDiagnosticLocation LocationToUnique, const Decl *DeclToUnique)
+  : BT(bt), DeclWithIssue(nullptr), Description(desc),
+UniqueingLocation(LocationToUnique),
+UniqueingDecl(DeclToUnique),
+ErrorNode(errornode), ConfigurationChangeToken(0),
+DoNotPrunePath(false) {}
+
+
+
 const Stmt *BugReport::getStmt() const {
   if (!ErrorNode)
 return nullptr;
Index: llvm/tools/clang/include/clang/StaticAnalyzer/Core/BugReporter/BugReporter.h
===
--- llvm/tools/clang/include/clang/StaticAnalyzer/Core/BugReporter/BugReporter.h
+++ llvm/tools/clang/include/clang/StaticAnalyzer/Core/BugReporter/BugReporter.h
@@ -143,19 +143,12 @@
   void popInterestingSymbolsAndRegions();
 
 public:
-  BugReport(BugType& bt, StringRef desc, const ExplodedNode *errornode)
-: BT(bt), DeclWithIssue(nullptr), Description(desc), ErrorNode(errornode),
-  ConfigurationChangeToken(0), DoNotPrunePath(false) {}
+  BugReport(BugType& bt, StringRef desc, const ExplodedNode *errornode);
 
   BugReport(BugType& bt, StringRef shortDesc, StringRef desc,
-const ExplodedNode *errornode)
-: BT(bt), DeclWithIssue(nullptr), ShortDescription(shortDesc),
-  Description(desc), ErrorNode(errornode), ConfigurationChangeToken(0),
-  DoNotPrunePath(false) {}
+const ExplodedNode *errornode);
 
-  BugReport(BugType &bt, StringRef desc, PathDiagnosticLocation l)
-: BT(bt), DeclWithIssue(nullptr), Description(desc), Location(l),
-  ErrorNode(nullptr), ConfigurationChangeToken(0), DoNotPrunePath(false) {}
+  BugReport(BugType &bt, StringRef desc, PathDiagnosticLocation l);
 
   /// \brief Create a BugReport with a custom uniqueing location.
   ///
@@ -165,12 +158,7 @@
   /// for uniquing reports. For example, memory leaks checker, could set this to
   /// the allocation site, rather then the location where the bug is reported.
   BugReport(BugType& bt, StringRef desc, const ExplodedNode *errornode,
-PathDiagnosticLocation LocationToUnique, const Decl *DeclToUnique)
-: BT(bt), DeclWithIssue(nullptr), Description(desc),
-  UniqueingLocation(LocationToUnique),
-  UniqueingDecl(DeclToUnique),
-  ErrorNode(errornode), ConfigurationChangeToken(0),
-  DoNotPrunePath(false) {}
+PathDiagnosticLocation LocationToUnique, const Decl *DeclToUnique);
 
   virtual ~BugReport();
 
Index: llvm/tools/clang/lib/StaticAnalyzer/Core/CoreEngine.cpp
===
--- llvm/tools/clang/lib/StaticAnalyzer/Core/CoreEngine.cpp
+++ llvm/tools/clang/lib/StaticAnalyzer/Core/CoreEngine.cpp
@@ -160,6 +160

r260497 - clang-format: Make it more expensive to break template parameters.

[Daniel Jasper via cfe-commits]

Author: djasper
Date: Thu Feb 11 00:43:01 2016
New Revision: 260497

URL: http://llvm.org/viewvc/llvm-project?rev=260497&view=rev
Log:
clang-format: Make it more expensive to break template parameters.

In particular, make it more expensive than breaking after the return
type of a function definition/declaration.

Before:
  template 
  aa aaa<
  T>::a(aaa aaa);

After:
  template 
  aa
  aaa::a(
  aaa aaa);

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

Modified: cfe/trunk/lib/Format/TokenAnnotator.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/TokenAnnotator.cpp?rev=260497&r1=260496&r2=260497&view=diff
==
--- cfe/trunk/lib/Format/TokenAnnotator.cpp (original)
+++ cfe/trunk/lib/Format/TokenAnnotator.cpp Thu Feb 11 00:43:01 2016
@@ -59,7 +59,7 @@ private:
 
 FormatToken *Left = CurrentToken->Previous;
 Left->ParentBracket = Contexts.back().ContextKind;
-ScopedContextCreator ContextCreator(*this, tok::less, 10);
+ScopedContextCreator ContextCreator(*this, tok::less, 12);
 
 // If this angle is in the context of an expression, we need to be more
 // hesitant to detect it as opening template parameters.

Modified: cfe/trunk/unittests/Format/FormatTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Format/FormatTest.cpp?rev=260497&r1=260496&r2=260497&view=diff
==
--- cfe/trunk/unittests/Format/FormatTest.cpp (original)
+++ cfe/trunk/unittests/Format/FormatTest.cpp Thu Feb 11 00:43:01 2016
@@ -3850,6 +3850,11 @@ TEST_F(FormatTest, BreaksFunctionDeclara
   "typename aa::aaa\n"
   "aa::aaa(\n"
   "bool *aa, bool *aa) {}");
+  verifyGoogleFormat(
+  "template \n"
+  "aa\n"
+  "aaa::a(\n"
+  "aaa aaa);");
 
   FormatStyle Style = getLLVMStyle();
   Style.PointerAlignment = FormatStyle::PAS_Left;


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

r260496 - [Objective-c] Stop attaching section "datacoal_nt" to global variables.

[Akira Hatanaka via cfe-commits]

Author: ahatanak
Date: Thu Feb 11 00:36:35 2016
New Revision: 260496

URL: http://llvm.org/viewvc/llvm-project?rev=260496&view=rev
Log:
[Objective-c] Stop attaching section "datacoal_nt" to global variables.

The current macho linker just copies symbols in section datacoal_nt to
section data, so it doesn't really matter whether or not section
"datacoal_nt" is attached to the global variable.

This is a follow-up to r250370, which made changes in llvm to stop
putting functions and data in the *coal* sections.

rdar://problem/24528611

Modified:
cfe/trunk/lib/CodeGen/CGObjCMac.cpp
cfe/trunk/lib/Frontend/Rewrite/RewriteModernObjC.cpp
cfe/trunk/test/CodeGenObjC/exceptions-asm-attribute.m
cfe/trunk/test/CodeGenObjC/metadata-symbols-64.m
cfe/trunk/test/CodeGenObjC/metadata_symbols.m

Modified: cfe/trunk/lib/CodeGen/CGObjCMac.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGObjCMac.cpp?rev=260496&r1=260495&r2=260496&view=diff
==
--- cfe/trunk/lib/CodeGen/CGObjCMac.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGObjCMac.cpp Thu Feb 11 00:36:35 2016
@@ -6409,7 +6409,7 @@ llvm::Constant *CGObjCNonFragileABIMac::
   const ObjCProtocolDecl *PD) {
   llvm::GlobalVariable *&Entry = Protocols[PD->getIdentifier()];
 
-  if (!Entry) {
+  if (!Entry)
 // We use the initializer as a marker of whether this is a forward
 // reference or not. At module finalization we add the empty
 // contents for protocols which were referenced but never defined.
@@ -6418,8 +6418,6 @@ llvm::Constant *CGObjCNonFragileABIMac::
  false, llvm::GlobalValue::ExternalLinkage,
  nullptr,
  "\01l_OBJC_PROTOCOL_$_" + 
PD->getObjCRuntimeNameAsString());
-Entry->setSection("__DATA,__datacoal_nt,coalesced");
-  }
 
   return Entry;
 }
@@ -6546,7 +6544,6 @@ llvm::Constant *CGObjCNonFragileABIMac::
"\01l_OBJC_PROTOCOL_$_" + 
PD->getObjCRuntimeNameAsString());
 Entry->setAlignment(
   CGM.getDataLayout().getABITypeAlignment(ObjCTypes.ProtocolnfABITy));
-Entry->setSection("__DATA,__datacoal_nt,coalesced");
 
 Protocols[PD->getIdentifier()] = Entry;
   }
@@ -7271,8 +7268,6 @@ CGObjCNonFragileABIMac::GetInterfaceEHTy
 
   if (ForDefinition)
 Entry->setSection("__DATA,__objc_const");
-  else
-Entry->setSection("__DATA,__datacoal_nt,coalesced");
 
   return Entry;
 }

Modified: cfe/trunk/lib/Frontend/Rewrite/RewriteModernObjC.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/Rewrite/RewriteModernObjC.cpp?rev=260496&r1=260495&r2=260496&view=diff
==
--- cfe/trunk/lib/Frontend/Rewrite/RewriteModernObjC.cpp (original)
+++ cfe/trunk/lib/Frontend/Rewrite/RewriteModernObjC.cpp Thu Feb 11 00:36:35 
2016
@@ -6981,7 +6981,7 @@ void RewriteModernObjC::RewriteObjCProto
 Result += "static ";
   Result += "struct _protocol_t _OBJC_PROTOCOL_";
   Result += PDecl->getNameAsString();
-  Result += " __attribute__ ((used, section 
(\"__DATA,__datacoal_nt,coalesced\"))) = {\n";
+  Result += " __attribute__ ((used)) = {\n";
   Result += "\t0,\n"; // id is; is null
   Result += "\t\""; Result += PDecl->getNameAsString(); Result += "\",\n";
   if (SuperProtocols.size() > 0) {

Modified: cfe/trunk/test/CodeGenObjC/exceptions-asm-attribute.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenObjC/exceptions-asm-attribute.m?rev=260496&r1=260495&r2=260496&view=diff
==
--- cfe/trunk/test/CodeGenObjC/exceptions-asm-attribute.m (original)
+++ cfe/trunk/test/CodeGenObjC/exceptions-asm-attribute.m Thu Feb 11 00:36:35 
2016
@@ -12,7 +12,7 @@
 // CHECK-X86_64: @"OBJC_CLASS_$_MySecretNamespace.A" = global {{.*}}, section 
"__DATA, __objc_data", align 8
 // CHECK-X86_64: @"OBJC_METACLASS_$_MySecretNamespace.A" = global {{.*}}, 
section "__DATA, __objc_data", align 8
 // CHECK-X86_64: @OBJC_CLASS_NAME_ = {{.*}}, section 
"__TEXT,__objc_classname,cstring_literals", align 1
-// CHECK-X86_64: @"OBJC_EHTYPE_$_MySecretNamespace.EH1" = weak global {{.*}}, 
section "__DATA,__datacoal_nt,coalesced", align 8
+// CHECK-X86_64: @"OBJC_EHTYPE_$_MySecretNamespace.EH1" = weak global {{.*}}, 
align 8
 // CHECK-X86_64: @"OBJC_EHTYPE_$_MySecretNamespace.EH2" = external global
 // CHECK-X86_64: @"OBJC_EHTYPE_$_MySecretNamespace.EH3" = global {{.*}}, 
section "__DATA,__objc_const", align 8
 // CHECK-X86_64: @"OBJC_LABEL_CLASS_$" = private global {{.*}}, section 
"__DATA, __objc_classlist, regular, no_dead_strip", align 8
@@ -24,7 +24,7 @@
 
 // CHECK-X86_64-HIDDEN: @"OBJC_CLASS_$_MySecretNamespace.A" = hidden global 
{{.*}}, section "__DATA, __objc_data", align 8
 // CHECK-X86_64-HIDDEN: @"OBJC_METACLASS_$_MySecretNamespace.A" = hidden 
global {{.*}}, section

r260492 - [OPENMP] Rename OMPCapturedFieldDecl to OMPCapturedExprDecl, NFC.

[Alexey Bataev via cfe-commits]

Author: abataev
Date: Wed Feb 10 23:35:55 2016
New Revision: 260492

URL: http://llvm.org/viewvc/llvm-project?rev=260492&view=rev
Log:
[OPENMP] Rename OMPCapturedFieldDecl to OMPCapturedExprDecl, NFC.
OMPCapturedExprDecl allows caopturing not only of fielddecls, but also
other expressions. It also allows to simplify codegen for several
clauses.

Modified:
cfe/trunk/include/clang/AST/DeclOpenMP.h
cfe/trunk/include/clang/AST/RecursiveASTVisitor.h
cfe/trunk/include/clang/Basic/DeclNodes.td
cfe/trunk/include/clang/Serialization/ASTBitCodes.h
cfe/trunk/lib/AST/DeclBase.cpp
cfe/trunk/lib/AST/DeclOpenMP.cpp
cfe/trunk/lib/AST/DeclPrinter.cpp
cfe/trunk/lib/AST/StmtPrinter.cpp
cfe/trunk/lib/CodeGen/CGDecl.cpp
cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp
cfe/trunk/lib/Sema/SemaExpr.cpp
cfe/trunk/lib/Sema/SemaOpenMP.cpp
cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp
cfe/trunk/lib/Serialization/ASTCommon.cpp
cfe/trunk/lib/Serialization/ASTReaderDecl.cpp
cfe/trunk/lib/Serialization/ASTWriterDecl.cpp
cfe/trunk/tools/libclang/CIndex.cpp

Modified: cfe/trunk/include/clang/AST/DeclOpenMP.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/DeclOpenMP.h?rev=260492&r1=260491&r2=260492&view=diff
==
--- cfe/trunk/include/clang/AST/DeclOpenMP.h (original)
+++ cfe/trunk/include/clang/AST/DeclOpenMP.h Wed Feb 10 23:35:55 2016
@@ -87,33 +87,33 @@ public:
   static bool classofKind(Kind K) { return K == OMPThreadPrivate; }
 };
 
-/// Pseudo declaration for capturing of non-static data members in non-static
-/// member functions.
+/// Pseudo declaration for capturing expressions. Also is used for capturing of
+/// non-static data members in non-static member functions.
 ///
 /// Clang supports capturing of variables only, but OpenMP 4.5 allows to
 /// privatize non-static members of current class in non-static member
 /// functions. This pseudo-declaration allows properly handle this kind of
 /// capture by wrapping captured expression into a variable-like declaration.
-class OMPCapturedFieldDecl final : public VarDecl {
+class OMPCapturedExprDecl final : public VarDecl {
   friend class ASTDeclReader;
   void anchor() override;
 
-  OMPCapturedFieldDecl(ASTContext &C, DeclContext *DC, IdentifierInfo *Id,
-   QualType Type)
-  : VarDecl(OMPCapturedField, C, DC, SourceLocation(), SourceLocation(), 
Id,
+  OMPCapturedExprDecl(ASTContext &C, DeclContext *DC, IdentifierInfo *Id,
+  QualType Type)
+  : VarDecl(OMPCapturedExpr, C, DC, SourceLocation(), SourceLocation(), Id,
 Type, nullptr, SC_None) {
 setImplicit();
   }
 
 public:
-  static OMPCapturedFieldDecl *Create(ASTContext &C, DeclContext *DC,
-  IdentifierInfo *Id, QualType T);
+  static OMPCapturedExprDecl *Create(ASTContext &C, DeclContext *DC,
+ IdentifierInfo *Id, QualType T);
 
-  static OMPCapturedFieldDecl *CreateDeserialized(ASTContext &C, unsigned ID);
+  static OMPCapturedExprDecl *CreateDeserialized(ASTContext &C, unsigned ID);
 
   // Implement isa/cast/dyncast/etc.
   static bool classof(const Decl *D) { return classofKind(D->getKind()); }
-  static bool classofKind(Kind K) { return K == OMPCapturedField; }
+  static bool classofKind(Kind K) { return K == OMPCapturedExpr; }
 };
 
 } // end namespace clang

Modified: cfe/trunk/include/clang/AST/RecursiveASTVisitor.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/RecursiveASTVisitor.h?rev=260492&r1=260491&r2=260492&view=diff
==
--- cfe/trunk/include/clang/AST/RecursiveASTVisitor.h (original)
+++ cfe/trunk/include/clang/AST/RecursiveASTVisitor.h Wed Feb 10 23:35:55 2016
@@ -1434,7 +1434,7 @@ DEF_TRAVERSE_DECL(OMPThreadPrivateDecl,
   }
 })
 
-DEF_TRAVERSE_DECL(OMPCapturedFieldDecl, { TRY_TO(TraverseVarHelper(D)); })
+DEF_TRAVERSE_DECL(OMPCapturedExprDecl, { TRY_TO(TraverseVarHelper(D)); })
 
 // A helper method for TemplateDecl's children.
 template 

Modified: cfe/trunk/include/clang/Basic/DeclNodes.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DeclNodes.td?rev=260492&r1=260491&r2=260492&view=diff
==
--- cfe/trunk/include/clang/Basic/DeclNodes.td (original)
+++ cfe/trunk/include/clang/Basic/DeclNodes.td Wed Feb 10 23:35:55 2016
@@ -51,7 +51,7 @@ def Named : Decl<1>;
 : DDecl;
 def ImplicitParam : DDecl;
 def ParmVar : DDecl;
-def OMPCapturedField : DDecl;
+def OMPCapturedExpr : DDecl;
   def NonTypeTemplateParm : DDecl;
   def Template : DDecl;
 def RedeclarableTemplate : DDecl;

Modified: cfe/trunk/include/clang/Serialization/ASTBitCodes.h
URL: 
http://llvm.org/viewvc/llvm

Re: [PATCH] D16517: ClangTidy check to flag uninitialized builtin and pointer fields.

[Felix Berger via cfe-commits]

flx updated this revision to Diff 47594.
flx added a comment.

Added comment that we're returning early if this constructor simply delegates 
to another constructor.


http://reviews.llvm.org/D16517

Files:
  clang-tidy/cppcoreguidelines/CMakeLists.txt
  clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
  clang-tidy/cppcoreguidelines/ProTypeMemberInitCheck.cpp
  clang-tidy/cppcoreguidelines/ProTypeMemberInitCheck.h
  docs/clang-tidy/checks/cppcoreguidelines-pro-type-member-init.rst
  docs/clang-tidy/checks/list.rst
  test/clang-tidy/cppcoreguidelines-pro-type-member-init-cxx98.cpp
  test/clang-tidy/cppcoreguidelines-pro-type-member-init.cpp

Index: test/clang-tidy/cppcoreguidelines-pro-type-member-init.cpp
===
--- /dev/null
+++ test/clang-tidy/cppcoreguidelines-pro-type-member-init.cpp
@@ -0,0 +1,107 @@
+// RUN: %check_clang_tidy %s cppcoreguidelines-pro-type-member-init %t
+
+struct PositiveFieldBeforeConstructor {
+  int F;
+  // CHECK-FIXES: int F{};
+  PositiveFieldBeforeConstructor() {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: constructor does not initialize these built-in/pointer fields: F
+  // CHECK-FIXES: PositiveFieldBeforeConstructor() {}
+};
+
+struct PositiveFieldAfterConstructor {
+  PositiveFieldAfterConstructor() {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: constructor does not initialize these built-in/pointer fields: F, G
+  // CHECK-FIXES: PositiveFieldAfterConstructor() {}
+  int F;
+  // CHECK-FIXES: int F{};
+  bool G /* with comment */;
+  // CHECK-FIXES: bool G{} /* with comment */;
+  PositiveFieldBeforeConstructor IgnoredField;
+};
+
+struct PositiveSeparateDefinition {
+  PositiveSeparateDefinition();
+  int F;
+  // CHECK-FIXES: int F{};
+};
+
+PositiveSeparateDefinition::PositiveSeparateDefinition() {}
+// CHECK-MESSAGES: :[[@LINE-1]]:1: warning: constructor does not initialize these built-in/pointer fields: F
+// CHECK-FIXES: PositiveSeparateDefinition::PositiveSeparateDefinition() {}
+
+struct PositiveMixedFieldOrder {
+  PositiveMixedFieldOrder() : J(0) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: constructor does not initialize these built-in/pointer fields: I, K
+  // CHECK-FIXES: PositiveMixedFieldOrder() : J(0) {}
+  int I;
+  // CHECK-FIXES: int I{};
+  int J;
+  int K;
+  // CHECK-FIXES: int K{};
+};
+
+template 
+struct Template {
+  Template() {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: constructor does not initialize these built-in/pointer fields: F
+  int F;
+  // CHECK-FIXES: int F{};
+  T T1;
+  // CHECK-FIXES: T T1;
+};
+
+void instantiate() {
+  Template TInt;
+}
+
+struct NegativeFieldInitialized {
+  int F;
+
+  NegativeFieldInitialized() : F() {}
+};
+
+struct NegativeFieldInitializedInDefinition {
+  int F;
+
+  NegativeFieldInitializedInDefinition();
+};
+NegativeFieldInitializedInDefinition::NegativeFieldInitializedInDefinition() : F() {}
+
+
+struct NegativeInClassInitialized {
+  int F = 0;
+
+  NegativeInClassInitialized() {}
+};
+
+struct NegativeConstructorDelegated {
+  int F;
+
+  NegativeConstructorDelegated(int F) : F(F) {}
+  NegativeConstructorDelegated() : NegativeConstructorDelegated(0) {}
+};
+
+struct NegativeInitializedInBody {
+  NegativeInitializedInBody() { I = 0; }
+  int I;
+};
+
+#define UNINITIALIZED_FIELD_IN_MACRO_BODY(FIELD) \
+  struct UninitializedField##FIELD {		 \
+UninitializedField##FIELD() {}		 \
+int FIELD;	 \
+  };		 \
+
+UNINITIALIZED_FIELD_IN_MACRO_BODY(F);
+// CHECK-MESSAGES: :[[@LINE-1]]:1: warning: constructor does not initialize these built-in/pointer fields: F
+UNINITIALIZED_FIELD_IN_MACRO_BODY(G);
+// CHECK-MESSAGES: :[[@LINE-1]]:1: warning: constructor does not initialize these built-in/pointer fields: G
+
+#define UNINITIALIZED_FIELD_IN_MACRO_ARGUMENT(ARGUMENT) \
+  ARGUMENT		\
+
+UNINITIALIZED_FIELD_IN_MACRO_ARGUMENT(struct UninitializedFieldInMacroArg {
+  UninitializedFieldInMacroArg() {}
+  int Field;
+});
+// CHECK-MESSAGES: :[[@LINE-3]]:3: warning: constructor does not initialize these built-in/pointer fields: Field
Index: test/clang-tidy/cppcoreguidelines-pro-type-member-init-cxx98.cpp
===
--- /dev/null
+++ test/clang-tidy/cppcoreguidelines-pro-type-member-init-cxx98.cpp
@@ -0,0 +1,67 @@
+// RUN: %check_clang_tidy %s cppcoreguidelines-pro-type-member-init %t -- -- -std=c++98
+
+struct PositiveFieldBeforeConstructor {
+  int F;
+  PositiveFieldBeforeConstructor() /* some comment */ {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: constructor does not initialize these built-in/pointer fields: F
+  // CHECK-FIXES: PositiveFieldBeforeConstructor() : F() /* some comment */ {}
+};
+
+struct PositiveFieldAfterConstructor {
+  PositiveFieldAfterConstructor() {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: constructor does not initialize these built-in/pointer fields: F, G, H
+  // CHECK-FIXES: PositiveFieldAfterConstructor() : F(), 

Re: [PATCH] D16517: ClangTidy check to flag uninitialized builtin and pointer fields.

[Felix Berger via cfe-commits]

flx added inline comments.


Comment at: clang-tidy/cppcoreguidelines/ProTypeMemberInitCheck.cpp:205
@@ +204,3 @@
+  Diag << FixItHint::CreateInsertion(
+  Field->getSourceRange().getEnd().getLocWithOffset(
+  Field->getName().size()),

alexfh wrote:
> Maybe Lexer::getLocForEndOfToken?
Tried:

Lexer::getLocForEndOfToken(Field->getSourceRange().getEnd(),
 Field->getName().size(),
 Result.Context->getSourceManager(),
 Result.Context->getLangOpts()),

but that placed the {} before the field name:

-  bool G /* with comment */;
+  bool {}G /* with comment */;
 




http://reviews.llvm.org/D16517



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

Re: [PATCH] D16517: ClangTidy check to flag uninitialized builtin and pointer fields.

[Felix Berger via cfe-commits]

flx updated this revision to Diff 47590.
flx marked 3 inline comments as done.

http://reviews.llvm.org/D16517

Files:
  clang-tidy/cppcoreguidelines/CMakeLists.txt
  clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
  clang-tidy/cppcoreguidelines/ProTypeMemberInitCheck.cpp
  clang-tidy/cppcoreguidelines/ProTypeMemberInitCheck.h
  docs/clang-tidy/checks/cppcoreguidelines-pro-type-member-init.rst
  docs/clang-tidy/checks/list.rst
  test/clang-tidy/cppcoreguidelines-pro-type-member-init-cxx98.cpp
  test/clang-tidy/cppcoreguidelines-pro-type-member-init.cpp

Index: test/clang-tidy/cppcoreguidelines-pro-type-member-init.cpp
===
--- /dev/null
+++ test/clang-tidy/cppcoreguidelines-pro-type-member-init.cpp
@@ -0,0 +1,107 @@
+// RUN: %check_clang_tidy %s cppcoreguidelines-pro-type-member-init %t
+
+struct PositiveFieldBeforeConstructor {
+  int F;
+  // CHECK-FIXES: int F{};
+  PositiveFieldBeforeConstructor() {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: constructor does not initialize these built-in/pointer fields: F
+  // CHECK-FIXES: PositiveFieldBeforeConstructor() {}
+};
+
+struct PositiveFieldAfterConstructor {
+  PositiveFieldAfterConstructor() {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: constructor does not initialize these built-in/pointer fields: F, G
+  // CHECK-FIXES: PositiveFieldAfterConstructor() {}
+  int F;
+  // CHECK-FIXES: int F{};
+  bool G /* with comment */;
+  // CHECK-FIXES: bool G{} /* with comment */;
+  PositiveFieldBeforeConstructor IgnoredField;
+};
+
+struct PositiveSeparateDefinition {
+  PositiveSeparateDefinition();
+  int F;
+  // CHECK-FIXES: int F{};
+};
+
+PositiveSeparateDefinition::PositiveSeparateDefinition() {}
+// CHECK-MESSAGES: :[[@LINE-1]]:1: warning: constructor does not initialize these built-in/pointer fields: F
+// CHECK-FIXES: PositiveSeparateDefinition::PositiveSeparateDefinition() {}
+
+struct PositiveMixedFieldOrder {
+  PositiveMixedFieldOrder() : J(0) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: constructor does not initialize these built-in/pointer fields: I, K
+  // CHECK-FIXES: PositiveMixedFieldOrder() : J(0) {}
+  int I;
+  // CHECK-FIXES: int I{};
+  int J;
+  int K;
+  // CHECK-FIXES: int K{};
+};
+
+template 
+struct Template {
+  Template() {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: constructor does not initialize these built-in/pointer fields: F
+  int F;
+  // CHECK-FIXES: int F{};
+  T T1;
+  // CHECK-FIXES: T T1;
+};
+
+void instantiate() {
+  Template TInt;
+}
+
+struct NegativeFieldInitialized {
+  int F;
+
+  NegativeFieldInitialized() : F() {}
+};
+
+struct NegativeFieldInitializedInDefinition {
+  int F;
+
+  NegativeFieldInitializedInDefinition();
+};
+NegativeFieldInitializedInDefinition::NegativeFieldInitializedInDefinition() : F() {}
+
+
+struct NegativeInClassInitialized {
+  int F = 0;
+
+  NegativeInClassInitialized() {}
+};
+
+struct NegativeConstructorDelegated {
+  int F;
+
+  NegativeConstructorDelegated(int F) : F(F) {}
+  NegativeConstructorDelegated() : NegativeConstructorDelegated(0) {}
+};
+
+struct NegativeInitializedInBody {
+  NegativeInitializedInBody() { I = 0; }
+  int I;
+};
+
+#define UNINITIALIZED_FIELD_IN_MACRO_BODY(FIELD) \
+  struct UninitializedField##FIELD {		 \
+UninitializedField##FIELD() {}		 \
+int FIELD;	 \
+  };		 \
+
+UNINITIALIZED_FIELD_IN_MACRO_BODY(F);
+// CHECK-MESSAGES: :[[@LINE-1]]:1: warning: constructor does not initialize these built-in/pointer fields: F
+UNINITIALIZED_FIELD_IN_MACRO_BODY(G);
+// CHECK-MESSAGES: :[[@LINE-1]]:1: warning: constructor does not initialize these built-in/pointer fields: G
+
+#define UNINITIALIZED_FIELD_IN_MACRO_ARGUMENT(ARGUMENT) \
+  ARGUMENT		\
+
+UNINITIALIZED_FIELD_IN_MACRO_ARGUMENT(struct UninitializedFieldInMacroArg {
+  UninitializedFieldInMacroArg() {}
+  int Field;
+});
+// CHECK-MESSAGES: :[[@LINE-3]]:3: warning: constructor does not initialize these built-in/pointer fields: Field
Index: test/clang-tidy/cppcoreguidelines-pro-type-member-init-cxx98.cpp
===
--- /dev/null
+++ test/clang-tidy/cppcoreguidelines-pro-type-member-init-cxx98.cpp
@@ -0,0 +1,67 @@
+// RUN: %check_clang_tidy %s cppcoreguidelines-pro-type-member-init %t -- -- -std=c++98
+
+struct PositiveFieldBeforeConstructor {
+  int F;
+  PositiveFieldBeforeConstructor() /* some comment */ {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: constructor does not initialize these built-in/pointer fields: F
+  // CHECK-FIXES: PositiveFieldBeforeConstructor() : F() /* some comment */ {}
+};
+
+struct PositiveFieldAfterConstructor {
+  PositiveFieldAfterConstructor() {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: constructor does not initialize these built-in/pointer fields: F, G, H
+  // CHECK-FIXES: PositiveFieldAfterConstructor() : F(), G(), H() {}
+  int F;
+  bool G /* with comment */;
+  int *H;
+  PositiveFieldBeforeCon

Re: [libcxx] r260012 - Cleanup node-type handling in the unordered containers

[Marshall Clow via cfe-commits]

On Wed, Feb 10, 2016 at 2:46 PM, Duncan P. N. Exon Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> I'm hoping only a year or two (or three...)?
>

As I pointed out to Eric on IRC, those files have had a "deprecation
warning" every time they are included ... since 2010.

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

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

[Sean Silva via cfe-commits]

silvas added a subscriber: silvas.
silvas added a comment.

Assuming the features are implemented this seems fine. LGTM.



Comment at: docs/UsersManual.rst:1698
@@ -1697,3 @@
--  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,

Should we close that bug then?


http://reviews.llvm.org/D16851



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

Re: [PATCH] D17043: Check that the result of a library call w/o side effects is used

[Sidney San Martín via cfe-commits]

> On Feb 10, 2016, at 8:05 PM, Joerg Sonnenberger  
> wrote:
> 
> I'm not a big fan of this. Those calls are by the very definition
> harmless, so they aggrevate the existing problem of stupid annotation.

The issue is that the annotation's current diagnostic is pretty nonspecific and 
therefore not useful to programmers who don't know what it means in that 
specific case. Adding parameters to specify a specific, useful diagnostic (and 
maybe deprecating the argument-less use), or forking this into two more 
specific annotations, should resolve things.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r260478 - Remove unused ToolChain arg from Driver::ConstructPhaseAction and BuildAction.

[Justin Lebar via cfe-commits]

Author: jlebar
Date: Wed Feb 10 20:00:50 2016
New Revision: 260478

URL: http://llvm.org/viewvc/llvm-project?rev=260478&view=rev
Log:
Remove unused ToolChain arg from Driver::ConstructPhaseAction and BuildAction.

Summary:
Actions don't depend on the toolchain; they get bound to a particular
toolchain via BindArch.

No functional changes.

Reviewers: echristo

Subscribers: cfe-commits

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

Modified:
cfe/trunk/include/clang/Driver/Driver.h
cfe/trunk/lib/Driver/Driver.cpp

Modified: cfe/trunk/include/clang/Driver/Driver.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Driver.h?rev=260478&r1=260477&r2=260478&view=diff
==
--- cfe/trunk/include/clang/Driver/Driver.h (original)
+++ cfe/trunk/include/clang/Driver/Driver.h Wed Feb 10 20:00:50 2016
@@ -299,12 +299,10 @@ public:
   /// given arguments, which are only done for a single architecture.
   ///
   /// \param C - The compilation that is being built.
-  /// \param TC - The default host tool chain.
   /// \param Args - The input arguments.
   /// \param Actions - The list to store the resulting actions onto.
-  void BuildActions(Compilation &C, const ToolChain &TC,
-llvm::opt::DerivedArgList &Args, const InputList &Inputs,
-ActionList &Actions) const;
+  void BuildActions(Compilation &C, llvm::opt::DerivedArgList &Args,
+const InputList &Inputs, ActionList &Actions) const;
 
   /// BuildUniversalActions - Construct the list of actions to perform
   /// for the given arguments, which may require a universal build.
@@ -376,9 +374,8 @@ public:
   /// ConstructAction - Construct the appropriate action to do for
   /// \p Phase on the \p Input, taking in to account arguments
   /// like -fsyntax-only or --analyze.
-  Action *ConstructPhaseAction(Compilation &C, const ToolChain &TC,
-   const llvm::opt::ArgList &Args, phases::ID 
Phase,
-   Action *Input) const;
+  Action *ConstructPhaseAction(Compilation &C, const llvm::opt::ArgList &Args,
+   phases::ID Phase, Action *Input) const;
 
   /// BuildJobsForAction - Construct the jobs to perform for the action \p A 
and
   /// return an InputInfo for the result of running \p A.  Will only construct

Modified: cfe/trunk/lib/Driver/Driver.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Driver.cpp?rev=260478&r1=260477&r2=260478&view=diff
==
--- cfe/trunk/lib/Driver/Driver.cpp (original)
+++ cfe/trunk/lib/Driver/Driver.cpp Wed Feb 10 20:00:50 2016
@@ -510,8 +510,7 @@ Compilation *Driver::BuildCompilation(Ar
   if (TC.getTriple().isOSBinFormatMachO())
 BuildUniversalActions(*C, C->getDefaultToolChain(), Inputs);
   else
-BuildActions(*C, C->getDefaultToolChain(), C->getArgs(), Inputs,
- C->getActions());
+BuildActions(*C, C->getArgs(), Inputs, C->getActions());
 
   if (CCCPrintPhases) {
 PrintActions(*C);
@@ -625,7 +624,7 @@ void Driver::generateCompilationDiagnost
   if (TC.getTriple().isOSBinFormatMachO())
 BuildUniversalActions(C, TC, Inputs);
   else
-BuildActions(C, TC, C.getArgs(), Inputs, C.getActions());
+BuildActions(C, C.getArgs(), Inputs, C.getActions());
 
   BuildJobs(C);
 
@@ -1036,7 +1035,7 @@ void Driver::BuildUniversalActions(Compi
 Archs.push_back(Args.MakeArgString(TC.getDefaultUniversalArchName()));
 
   ActionList SingleActions;
-  BuildActions(C, TC, Args, BAInputs, SingleActions);
+  BuildActions(C, Args, BAInputs, SingleActions);
 
   // Add in arch bindings for every top level action, as well as lipo and
   // dsymutil steps if needed.
@@ -1322,8 +1321,7 @@ static Action *buildCudaActions(Compilat
   assert(C.getCudaDeviceToolChain() &&
  "Missing toolchain for device-side compilation.");
   ActionList CudaDeviceActions;
-  C.getDriver().BuildActions(C, *C.getCudaDeviceToolChain(), Args,
- CudaDeviceInputs, CudaDeviceActions);
+  C.getDriver().BuildActions(C, Args, CudaDeviceInputs, CudaDeviceActions);
   assert(GpuArchList.size() == CudaDeviceActions.size() &&
  "Failed to create actions for all devices");
 
@@ -1387,9 +1385,8 @@ static Action *buildCudaActions(Compilat
   ActionList({FatbinAction}));
 }
 
-void Driver::BuildActions(Compilation &C, const ToolChain &TC,
-  DerivedArgList &Args, const InputList &Inputs,
-  ActionList &Actions) const {
+void Driver::BuildActions(Compilation &C, DerivedArgList &Args,
+  const InputList &Inputs, ActionList &Actions) const {
   llvm::PrettyStackTraceString CrashInfo("Building compilation actions");
 
   if (!SuppressMissingInputWarning && Inputs.empty()) {
@@ -15

r260479 - [CUDA] Don't crash when trying to printf a non-scalar object.

[Justin Lebar via cfe-commits]

Author: jlebar
Date: Wed Feb 10 20:00:52 2016
New Revision: 260479

URL: http://llvm.org/viewvc/llvm-project?rev=260479&view=rev
Log:
[CUDA] Don't crash when trying to printf a non-scalar object.

Summary:
We can't do the right thing, since there's no right thing to do, but at
least we can not crash the compiler.

Reviewers: majnemer, rnk

Subscribers: cfe-commits, jhen, tra

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

Added:
cfe/trunk/test/CodeGenCUDA/printf-aggregate.cu
Modified:
cfe/trunk/lib/CodeGen/CGCUDABuiltin.cpp

Modified: cfe/trunk/lib/CodeGen/CGCUDABuiltin.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCUDABuiltin.cpp?rev=260479&r1=260478&r2=260479&view=diff
==
--- cfe/trunk/lib/CodeGen/CGCUDABuiltin.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGCUDABuiltin.cpp Wed Feb 10 20:00:52 2016
@@ -83,6 +83,13 @@ CodeGenFunction::EmitCUDADevicePrintfCal
E->arguments(), E->getDirectCallee(),
/* ParamsToSkip = */ 0);
 
+  // We don't know how to emit non-scalar varargs.
+  if (std::any_of(Args.begin() + 1, Args.end(),
+  [](const CallArg &A) { return !A.RV.isScalar(); })) {
+CGM.ErrorUnsupported(E, "non-scalar arg to printf");
+return RValue::get(llvm::ConstantInt::get(IntTy, 0));
+  }
+
   // Construct and fill the args buffer that we'll pass to vprintf.
   llvm::Value *BufferPtr;
   if (Args.size() <= 1) {

Added: cfe/trunk/test/CodeGenCUDA/printf-aggregate.cu
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCUDA/printf-aggregate.cu?rev=260479&view=auto
==
--- cfe/trunk/test/CodeGenCUDA/printf-aggregate.cu (added)
+++ cfe/trunk/test/CodeGenCUDA/printf-aggregate.cu Wed Feb 10 20:00:52 2016
@@ -0,0 +1,17 @@
+// REQUIRES: x86-registered-target
+// REQUIRES: nvptx-registered-target
+
+// RUN: not %clang_cc1 -triple nvptx64-nvidia-cuda -fcuda-is-device -emit-llvm 
\
+// RUN:   -o - %s 2>&1 | FileCheck %s
+
+#include "Inputs/cuda.h"
+
+// Check that we don't crash when asked to printf a non-scalar arg.
+struct Struct {
+  int x;
+  int y;
+};
+__device__ void PrintfNonScalar() {
+  // CHECK: cannot compile this non-scalar arg to printf
+  printf("%d", Struct());
+}


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

Re: [PATCH] D17103: [CUDA] Don't crash when trying to printf a non-scalar object.

[Justin Lebar via cfe-commits]

This revision was automatically updated to reflect the committed changes.
jlebar marked an inline comment as done.
Closed by commit rL260479: [CUDA] Don't crash when trying to printf a 
non-scalar object. (authored by jlebar).

Changed prior to commit:
  http://reviews.llvm.org/D17103?vs=47569&id=47572#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D17103

Files:
  cfe/trunk/lib/CodeGen/CGCUDABuiltin.cpp
  cfe/trunk/test/CodeGenCUDA/printf-aggregate.cu

Index: cfe/trunk/lib/CodeGen/CGCUDABuiltin.cpp
===
--- cfe/trunk/lib/CodeGen/CGCUDABuiltin.cpp
+++ cfe/trunk/lib/CodeGen/CGCUDABuiltin.cpp
@@ -83,6 +83,13 @@
E->arguments(), E->getDirectCallee(),
/* ParamsToSkip = */ 0);
 
+  // We don't know how to emit non-scalar varargs.
+  if (std::any_of(Args.begin() + 1, Args.end(),
+  [](const CallArg &A) { return !A.RV.isScalar(); })) {
+CGM.ErrorUnsupported(E, "non-scalar arg to printf");
+return RValue::get(llvm::ConstantInt::get(IntTy, 0));
+  }
+
   // Construct and fill the args buffer that we'll pass to vprintf.
   llvm::Value *BufferPtr;
   if (Args.size() <= 1) {
Index: cfe/trunk/test/CodeGenCUDA/printf-aggregate.cu
===
--- cfe/trunk/test/CodeGenCUDA/printf-aggregate.cu
+++ cfe/trunk/test/CodeGenCUDA/printf-aggregate.cu
@@ -0,0 +1,17 @@
+// REQUIRES: x86-registered-target
+// REQUIRES: nvptx-registered-target
+
+// RUN: not %clang_cc1 -triple nvptx64-nvidia-cuda -fcuda-is-device -emit-llvm 
\
+// RUN:   -o - %s 2>&1 | FileCheck %s
+
+#include "Inputs/cuda.h"
+
+// Check that we don't crash when asked to printf a non-scalar arg.
+struct Struct {
+  int x;
+  int y;
+};
+__device__ void PrintfNonScalar() {
+  // CHECK: cannot compile this non-scalar arg to printf
+  printf("%d", Struct());
+}


Index: cfe/trunk/lib/CodeGen/CGCUDABuiltin.cpp
===
--- cfe/trunk/lib/CodeGen/CGCUDABuiltin.cpp
+++ cfe/trunk/lib/CodeGen/CGCUDABuiltin.cpp
@@ -83,6 +83,13 @@
E->arguments(), E->getDirectCallee(),
/* ParamsToSkip = */ 0);
 
+  // We don't know how to emit non-scalar varargs.
+  if (std::any_of(Args.begin() + 1, Args.end(),
+  [](const CallArg &A) { return !A.RV.isScalar(); })) {
+CGM.ErrorUnsupported(E, "non-scalar arg to printf");
+return RValue::get(llvm::ConstantInt::get(IntTy, 0));
+  }
+
   // Construct and fill the args buffer that we'll pass to vprintf.
   llvm::Value *BufferPtr;
   if (Args.size() <= 1) {
Index: cfe/trunk/test/CodeGenCUDA/printf-aggregate.cu
===
--- cfe/trunk/test/CodeGenCUDA/printf-aggregate.cu
+++ cfe/trunk/test/CodeGenCUDA/printf-aggregate.cu
@@ -0,0 +1,17 @@
+// REQUIRES: x86-registered-target
+// REQUIRES: nvptx-registered-target
+
+// RUN: not %clang_cc1 -triple nvptx64-nvidia-cuda -fcuda-is-device -emit-llvm \
+// RUN:   -o - %s 2>&1 | FileCheck %s
+
+#include "Inputs/cuda.h"
+
+// Check that we don't crash when asked to printf a non-scalar arg.
+struct Struct {
+  int x;
+  int y;
+};
+__device__ void PrintfNonScalar() {
+  // CHECK: cannot compile this non-scalar arg to printf
+  printf("%d", Struct());
+}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D17100: Remove unused ToolChain arg from Driver::ConstructPhaseAction and BuildAction.

[Justin Lebar via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL260478: Remove unused ToolChain arg from 
Driver::ConstructPhaseAction and BuildAction. (authored by jlebar).

Changed prior to commit:
  http://reviews.llvm.org/D17100?vs=47526&id=47571#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D17100

Files:
  cfe/trunk/include/clang/Driver/Driver.h
  cfe/trunk/lib/Driver/Driver.cpp

Index: cfe/trunk/include/clang/Driver/Driver.h
===
--- cfe/trunk/include/clang/Driver/Driver.h
+++ cfe/trunk/include/clang/Driver/Driver.h
@@ -299,12 +299,10 @@
   /// given arguments, which are only done for a single architecture.
   ///
   /// \param C - The compilation that is being built.
-  /// \param TC - The default host tool chain.
   /// \param Args - The input arguments.
   /// \param Actions - The list to store the resulting actions onto.
-  void BuildActions(Compilation &C, const ToolChain &TC,
-llvm::opt::DerivedArgList &Args, const InputList &Inputs,
-ActionList &Actions) const;
+  void BuildActions(Compilation &C, llvm::opt::DerivedArgList &Args,
+const InputList &Inputs, ActionList &Actions) const;
 
   /// BuildUniversalActions - Construct the list of actions to perform
   /// for the given arguments, which may require a universal build.
@@ -376,9 +374,8 @@
   /// ConstructAction - Construct the appropriate action to do for
   /// \p Phase on the \p Input, taking in to account arguments
   /// like -fsyntax-only or --analyze.
-  Action *ConstructPhaseAction(Compilation &C, const ToolChain &TC,
-   const llvm::opt::ArgList &Args, phases::ID Phase,
-   Action *Input) const;
+  Action *ConstructPhaseAction(Compilation &C, const llvm::opt::ArgList &Args,
+   phases::ID Phase, Action *Input) const;
 
   /// BuildJobsForAction - Construct the jobs to perform for the action \p A and
   /// return an InputInfo for the result of running \p A.  Will only construct
Index: cfe/trunk/lib/Driver/Driver.cpp
===
--- cfe/trunk/lib/Driver/Driver.cpp
+++ cfe/trunk/lib/Driver/Driver.cpp
@@ -510,8 +510,7 @@
   if (TC.getTriple().isOSBinFormatMachO())
 BuildUniversalActions(*C, C->getDefaultToolChain(), Inputs);
   else
-BuildActions(*C, C->getDefaultToolChain(), C->getArgs(), Inputs,
- C->getActions());
+BuildActions(*C, C->getArgs(), Inputs, C->getActions());
 
   if (CCCPrintPhases) {
 PrintActions(*C);
@@ -625,7 +624,7 @@
   if (TC.getTriple().isOSBinFormatMachO())
 BuildUniversalActions(C, TC, Inputs);
   else
-BuildActions(C, TC, C.getArgs(), Inputs, C.getActions());
+BuildActions(C, C.getArgs(), Inputs, C.getActions());
 
   BuildJobs(C);
 
@@ -1036,7 +1035,7 @@
 Archs.push_back(Args.MakeArgString(TC.getDefaultUniversalArchName()));
 
   ActionList SingleActions;
-  BuildActions(C, TC, Args, BAInputs, SingleActions);
+  BuildActions(C, Args, BAInputs, SingleActions);
 
   // Add in arch bindings for every top level action, as well as lipo and
   // dsymutil steps if needed.
@@ -1322,8 +1321,7 @@
   assert(C.getCudaDeviceToolChain() &&
  "Missing toolchain for device-side compilation.");
   ActionList CudaDeviceActions;
-  C.getDriver().BuildActions(C, *C.getCudaDeviceToolChain(), Args,
- CudaDeviceInputs, CudaDeviceActions);
+  C.getDriver().BuildActions(C, Args, CudaDeviceInputs, CudaDeviceActions);
   assert(GpuArchList.size() == CudaDeviceActions.size() &&
  "Failed to create actions for all devices");
 
@@ -1387,9 +1385,8 @@
   ActionList({FatbinAction}));
 }
 
-void Driver::BuildActions(Compilation &C, const ToolChain &TC,
-  DerivedArgList &Args, const InputList &Inputs,
-  ActionList &Actions) const {
+void Driver::BuildActions(Compilation &C, DerivedArgList &Args,
+  const InputList &Inputs, ActionList &Actions) const {
   llvm::PrettyStackTraceString CrashInfo("Building compilation actions");
 
   if (!SuppressMissingInputWarning && Inputs.empty()) {
@@ -1516,7 +1513,7 @@
 continue;
 
   // Otherwise construct the appropriate action.
-  Current = ConstructPhaseAction(C, TC, Args, Phase, Current);
+  Current = ConstructPhaseAction(C, Args, Phase, Current);
 
   if (InputType == types::TY_CUDA && Phase == CudaInjectionPhase) {
 Current = buildCudaActions(C, Args, InputArg, Current, Actions);
@@ -1553,9 +1550,8 @@
   Args.ClaimAllArgs(options::OPT_cuda_host_only);
 }
 
-Action *Driver::ConstructPhaseAction(Compilation &C, const ToolChain &TC,
- const ArgList &Args, phases::ID Phase,
- Action *Input) const {
+Action *D

Re: [PATCH] D17043: Check that the result of a library call w/o side effects is used

[Richard Smith via cfe-commits]

On Wed, Feb 10, 2016 at 5:05 PM, Joerg Sonnenberger via cfe-commits
 wrote:
> On Wed, Feb 10, 2016 at 04:21:02PM +, Alexander Kornienko via cfe-commits 
> wrote:
>> alexfh added a comment.
>>
>> Thank you for working on this check!
>>
>> I'd like to note that there is a library-side way to mitigate this
>> issue using the `[[clang::warn_unused_result]]` attribute on
>> `vector::empty()` and similar methods:
>
> I'm not a big fan of this. Those calls are by the very definition
> harmless, so they aggrevate the existing problem of stupid annotation.
> The original intention of this attribute was to flag cases of side
> effects where ignoring the the result is a definite bug. Consider
> calling malloc or realloc and throwing away the result -- that never
> makes sense. Then GNU came along and starting to annotate various libc
> functions including most of the stdio family. Guess what, standard
> streams have a (sticky) error flag, exactly so that you don't have check
> every single call. Congratulation, people are just starting to ignore
> the warnings now. Fast forward and we have this suggestion...

I'm not sure what point you're making here. A call to vector::empty()
that discards the result is always a bug; usually, the intent was to
call vector::clear() instead, and the problem isn't just pointless
code.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D17103: [CUDA] Don't crash when trying to printf a non-scalar object.

[Reid Kleckner via cfe-commits]

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

lgtm



Comment at: lib/CodeGen/CGCUDABuiltin.cpp:90
@@ +89,3 @@
+CGM.ErrorUnsupported(E, "non-scalar arg to printf");
+return RValue::getIgnored();
+  }

Doesn't printf return int? Maybe return 
RValue::get(llvm::ConstantInt::get(IntTy, 0))?


http://reviews.llvm.org/D17103



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

Re: [PATCH] D17103: [CUDA] Don't crash when trying to printf a non-scalar object.

[Justin Lebar via cfe-commits]

jlebar updated this revision to Diff 47569.
jlebar added a comment.

Error out with CGM.ErrorUnsupported when we receive a non-scalar arg.


http://reviews.llvm.org/D17103

Files:
  lib/CodeGen/CGCUDABuiltin.cpp
  test/CodeGenCUDA/printf-aggregate.cu

Index: test/CodeGenCUDA/printf-aggregate.cu
===
--- /dev/null
+++ test/CodeGenCUDA/printf-aggregate.cu
@@ -0,0 +1,17 @@
+// REQUIRES: x86-registered-target
+// REQUIRES: nvptx-registered-target
+
+// RUN: not %clang_cc1 -triple nvptx64-nvidia-cuda -fcuda-is-device -emit-llvm 
\
+// RUN:   -o - %s 2>&1 | FileCheck %s
+
+#include "Inputs/cuda.h"
+
+// Check that we don't crash when asked to printf a non-scalar arg.
+struct Struct {
+  int x;
+  int y;
+};
+__device__ void PrintfNonScalar() {
+  // CHECK: cannot compile this non-scalar arg to printf
+  printf("%d", Struct());
+}
Index: lib/CodeGen/CGCUDABuiltin.cpp
===
--- lib/CodeGen/CGCUDABuiltin.cpp
+++ lib/CodeGen/CGCUDABuiltin.cpp
@@ -83,6 +83,13 @@
E->arguments(), E->getDirectCallee(),
/* ParamsToSkip = */ 0);
 
+  // We don't know how to emit non-scalar varargs.
+  if (std::any_of(Args.begin() + 1, Args.end(),
+  [](const CallArg &A) { return !A.RV.isScalar(); })) {
+CGM.ErrorUnsupported(E, "non-scalar arg to printf");
+return RValue::getIgnored();
+  }
+
   // Construct and fill the args buffer that we'll pass to vprintf.
   llvm::Value *BufferPtr;
   if (Args.size() <= 1) {


Index: test/CodeGenCUDA/printf-aggregate.cu
===
--- /dev/null
+++ test/CodeGenCUDA/printf-aggregate.cu
@@ -0,0 +1,17 @@
+// REQUIRES: x86-registered-target
+// REQUIRES: nvptx-registered-target
+
+// RUN: not %clang_cc1 -triple nvptx64-nvidia-cuda -fcuda-is-device -emit-llvm \
+// RUN:   -o - %s 2>&1 | FileCheck %s
+
+#include "Inputs/cuda.h"
+
+// Check that we don't crash when asked to printf a non-scalar arg.
+struct Struct {
+  int x;
+  int y;
+};
+__device__ void PrintfNonScalar() {
+  // CHECK: cannot compile this non-scalar arg to printf
+  printf("%d", Struct());
+}
Index: lib/CodeGen/CGCUDABuiltin.cpp
===
--- lib/CodeGen/CGCUDABuiltin.cpp
+++ lib/CodeGen/CGCUDABuiltin.cpp
@@ -83,6 +83,13 @@
E->arguments(), E->getDirectCallee(),
/* ParamsToSkip = */ 0);
 
+  // We don't know how to emit non-scalar varargs.
+  if (std::any_of(Args.begin() + 1, Args.end(),
+  [](const CallArg &A) { return !A.RV.isScalar(); })) {
+CGM.ErrorUnsupported(E, "non-scalar arg to printf");
+return RValue::getIgnored();
+  }
+
   // Construct and fill the args buffer that we'll pass to vprintf.
   llvm::Value *BufferPtr;
   if (Args.size() <= 1) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D17111: [CUDA] pass debug options to ptxas.

[Eric Christopher via cfe-commits]

echristo added inline comments.


Comment at: lib/Driver/Tools.cpp:10707
@@ +10706,3 @@
+// ptxas does not accept -g option if optimization is enabled, so we ignore
+// compiler's -O* options if we want debug info.
+CmdArgs.push_back("-g");

tra wrote:
> hfinkel wrote:
> > echristo wrote:
> > > tra wrote:
> > > > echristo wrote:
> > > > > tra wrote:
> > > > > > hfinkel wrote:
> > > > > > > echristo wrote:
> > > > > > > > jlebar wrote:
> > > > > > > > > I think this is would be very surprising to users.  -g does 
> > > > > > > > > not usually have a large performance impact, so -O2 -g does 
> > > > > > > > > not generally mean "generate slow code," as far as I know.  
> > > > > > > > > I'm concerned that this will result in people accidentally 
> > > > > > > > > compiling with ptxas -O0 (which is why I didn't do it like 
> > > > > > > > > this to begin with).
> > > > > > > > > 
> > > > > > > > > Can we accomplish this in a more explicit way?
> > > > > > > > Other than warning I'm not sure what we can do, we could do 
> > > > > > > > that instead and make everyone use O0 that wants debug info in 
> > > > > > > > their ptx?
> > > > > > > I'd rather we refuse to do anything (i.e. produce an error) than 
> > > > > > > silently remove either optimizations or -g. Do we have a way to 
> > > > > > > separately specify the optimization level for host and device 
> > > > > > > code? If not, looks like we should add one.
> > > > > > NVCC has -G option to control ptxas' debug options. If it's 
> > > > > > present, ptxas optimizations are disabled. I could add a similar 
> > > > > > option. "-gcuda-device" perhaps?
> > > > > > 
> > > > > We can do that, I'd have warned because it doesn't seem like 
> > > > > something we should hard error on, but I can see that perspective, 
> > > > > i.e. we asked for "incompatible" options.
> > > > > 
> > > > > And no, we don't currently have a way to do that. We can try to come 
> > > > > up with a driver interface.
> > > > @hfinkel: separate option should work. Any suggestions for a good name? 
> > > > -gcuda-device sounds awkward.
> > > > 
> > > > @echristo: "-O0" is not going to work for everyone in practice due to 
> > > > ptxas limitations. For instance on some thrust files ptxas runs out of 
> > > > memory on all non-inlined functions in unoptimized code. Compiling with 
> > > > -O2 is one way to work around that, but I do want device-side debug 
> > > > info!
> > > > 
> > > Huh? I'm not sure what you're doing here then with turning off 
> > > optimizations in the presence of debug info requests. Your commentary 
> > > made it sound like you can't have both.
> > > @hfinkel: separate option should work. Any suggestions for a good name? 
> > > -gcuda-device sounds awkward.
> > 
> > I agree it sounds awkward, but I currently have no better suggestion.
> @echristo: I assumed you were talking about compiler when you said "make 
> everyone use O0". I need compiler to optimize code with -O2, but run ptxas 
> with -g and -O0 which this patch makes possible.
> 
> I'll update the patch to add an option to control device-side debug info 
> explicitly.
> 
OK.


http://reviews.llvm.org/D17111



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

Re: [PATCH] D17103: [CUDA] Don't crash when trying to printf a non-scalar object.

[Justin Lebar via cfe-commits]

jlebar added a comment.

OK, talked to Reid irl.  Since this is just printf, not general varargs 
handling, the Simplest Thing That Could Possibly Work is to error-unsupported.  
Once we fix sema as described above, we can move the check there.  Will update 
the patch, thanks everyone.


http://reviews.llvm.org/D17103



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

Re: [PATCH] D17111: [CUDA] pass debug options to ptxas.

[Artem Belevich via cfe-commits]

tra added inline comments.


Comment at: lib/Driver/Tools.cpp:10707
@@ +10706,3 @@
+// ptxas does not accept -g option if optimization is enabled, so we ignore
+// compiler's -O* options if we want debug info.
+CmdArgs.push_back("-g");

hfinkel wrote:
> echristo wrote:
> > tra wrote:
> > > echristo wrote:
> > > > tra wrote:
> > > > > hfinkel wrote:
> > > > > > echristo wrote:
> > > > > > > jlebar wrote:
> > > > > > > > I think this is would be very surprising to users.  -g does not 
> > > > > > > > usually have a large performance impact, so -O2 -g does not 
> > > > > > > > generally mean "generate slow code," as far as I know.  I'm 
> > > > > > > > concerned that this will result in people accidentally 
> > > > > > > > compiling with ptxas -O0 (which is why I didn't do it like this 
> > > > > > > > to begin with).
> > > > > > > > 
> > > > > > > > Can we accomplish this in a more explicit way?
> > > > > > > Other than warning I'm not sure what we can do, we could do that 
> > > > > > > instead and make everyone use O0 that wants debug info in their 
> > > > > > > ptx?
> > > > > > I'd rather we refuse to do anything (i.e. produce an error) than 
> > > > > > silently remove either optimizations or -g. Do we have a way to 
> > > > > > separately specify the optimization level for host and device code? 
> > > > > > If not, looks like we should add one.
> > > > > NVCC has -G option to control ptxas' debug options. If it's present, 
> > > > > ptxas optimizations are disabled. I could add a similar option. 
> > > > > "-gcuda-device" perhaps?
> > > > > 
> > > > We can do that, I'd have warned because it doesn't seem like something 
> > > > we should hard error on, but I can see that perspective, i.e. we asked 
> > > > for "incompatible" options.
> > > > 
> > > > And no, we don't currently have a way to do that. We can try to come up 
> > > > with a driver interface.
> > > @hfinkel: separate option should work. Any suggestions for a good name? 
> > > -gcuda-device sounds awkward.
> > > 
> > > @echristo: "-O0" is not going to work for everyone in practice due to 
> > > ptxas limitations. For instance on some thrust files ptxas runs out of 
> > > memory on all non-inlined functions in unoptimized code. Compiling with 
> > > -O2 is one way to work around that, but I do want device-side debug info!
> > > 
> > Huh? I'm not sure what you're doing here then with turning off 
> > optimizations in the presence of debug info requests. Your commentary made 
> > it sound like you can't have both.
> > @hfinkel: separate option should work. Any suggestions for a good name? 
> > -gcuda-device sounds awkward.
> 
> I agree it sounds awkward, but I currently have no better suggestion.
@echristo: I assumed you were talking about compiler when you said "make 
everyone use O0". I need compiler to optimize code with -O2, but run ptxas with 
-g and -O0 which this patch makes possible.

I'll update the patch to add an option to control device-side debug info 
explicitly.



http://reviews.llvm.org/D17111



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

Re: r260411 - Silence some MSVC false positive warnings about integer zexts and falling off the end of a covered switch

[Joerg Sonnenberger via cfe-commits]

On Wed, Feb 10, 2016 at 07:09:16PM -, Reid Kleckner via cfe-commits wrote:
> Modified: cfe/trunk/lib/Sema/CodeCompleteConsumer.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/CodeCompleteConsumer.cpp?rev=260411&r1=260410&r2=260411&view=diff
> ==
> --- cfe/trunk/lib/Sema/CodeCompleteConsumer.cpp (original)
> +++ cfe/trunk/lib/Sema/CodeCompleteConsumer.cpp Wed Feb 10 13:09:15 2016
> @@ -309,7 +309,7 @@ StringRef CodeCompletionTUInfo::getParen
>  if (!Interface) {
>// Assign an empty StringRef but with non-null data to distinguish
>// between empty because we didn't process the DeclContext yet.
> -  CachedParentName = StringRef((const char *)~0U, 0);
> +  CachedParentName = StringRef((const char *)(uintptr_t)~0U, 0);
>return StringRef();
>  }
>  
> 

Is this address supposed to be special somehow? Because right now, it is
just below 4GB on a 64bit system and otherwise perfectly valid for use
by other things.

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

Re: r260333 - This patch adds doxygen comments for all the intrinsincs in the header file f16cintrin.h. The doxygen comments are automatically generated based on Sony's intrinsics document.

[Eric Christopher via cfe-commits]

On Wed, Feb 10, 2016 at 5:07 PM Joerg Sonnenberger 
wrote:

> On Thu, Feb 11, 2016 at 12:18:49AM +, Eric Christopher via cfe-commits
> wrote:
> > Mostly that you didn't mention it in your commit message.
> >
> > I'd rather prefer the rest of the file be changed to match the __ rather
> > than the other way around :)
>
> Depends. If it is a macro, not using __ is fine. If it is an inline
> function, it *must* use the protected namespace, since an application can
> #define a fancy junk here.
>
>
Yep. Which is why I'd prefer the rest of the file changed to match the __.
I was just trying to get Katya to do it :)

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

Re: r260333 - This patch adds doxygen comments for all the intrinsincs in the header file f16cintrin.h. The doxygen comments are automatically generated based on Sony's intrinsics document.

[Joerg Sonnenberger via cfe-commits]

On Thu, Feb 11, 2016 at 12:18:49AM +, Eric Christopher via cfe-commits 
wrote:
> Mostly that you didn't mention it in your commit message.
> 
> I'd rather prefer the rest of the file be changed to match the __ rather
> than the other way around :)

Depends. If it is a macro, not using __ is fine. If it is an inline
function, it *must* use the protected namespace, since an application can
#define a fancy junk here.

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

Re: [PATCH] D17043: Check that the result of a library call w/o side effects is used

[Joerg Sonnenberger via cfe-commits]

On Wed, Feb 10, 2016 at 04:21:02PM +, Alexander Kornienko via cfe-commits 
wrote:
> alexfh added a comment.
> 
> Thank you for working on this check!
> 
> I'd like to note that there is a library-side way to mitigate this
> issue using the `[[clang::warn_unused_result]]` attribute on
> `vector::empty()` and similar methods:

I'm not a big fan of this. Those calls are by the very definition
harmless, so they aggrevate the existing problem of stupid annotation.
The original intention of this attribute was to flag cases of side
effects where ignoring the the result is a definite bug. Consider
calling malloc or realloc and throwing away the result -- that never
makes sense. Then GNU came along and starting to annotate various libc
functions including most of the stdio family. Guess what, standard
streams have a (sticky) error flag, exactly so that you don't have check
every single call. Congratulation, people are just starting to ignore
the warnings now. Fast forward and we have this suggestion...

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

Re: [PATCH] D17111: [CUDA] pass debug options to ptxas.

[Hal Finkel via cfe-commits]

hfinkel added inline comments.


Comment at: lib/Driver/Tools.cpp:10707
@@ +10706,3 @@
+// ptxas does not accept -g option if optimization is enabled, so we ignore
+// compiler's -O* options if we want debug info.
+CmdArgs.push_back("-g");

echristo wrote:
> tra wrote:
> > echristo wrote:
> > > tra wrote:
> > > > hfinkel wrote:
> > > > > echristo wrote:
> > > > > > jlebar wrote:
> > > > > > > I think this is would be very surprising to users.  -g does not 
> > > > > > > usually have a large performance impact, so -O2 -g does not 
> > > > > > > generally mean "generate slow code," as far as I know.  I'm 
> > > > > > > concerned that this will result in people accidentally compiling 
> > > > > > > with ptxas -O0 (which is why I didn't do it like this to begin 
> > > > > > > with).
> > > > > > > 
> > > > > > > Can we accomplish this in a more explicit way?
> > > > > > Other than warning I'm not sure what we can do, we could do that 
> > > > > > instead and make everyone use O0 that wants debug info in their ptx?
> > > > > I'd rather we refuse to do anything (i.e. produce an error) than 
> > > > > silently remove either optimizations or -g. Do we have a way to 
> > > > > separately specify the optimization level for host and device code? 
> > > > > If not, looks like we should add one.
> > > > NVCC has -G option to control ptxas' debug options. If it's present, 
> > > > ptxas optimizations are disabled. I could add a similar option. 
> > > > "-gcuda-device" perhaps?
> > > > 
> > > We can do that, I'd have warned because it doesn't seem like something we 
> > > should hard error on, but I can see that perspective, i.e. we asked for 
> > > "incompatible" options.
> > > 
> > > And no, we don't currently have a way to do that. We can try to come up 
> > > with a driver interface.
> > @hfinkel: separate option should work. Any suggestions for a good name? 
> > -gcuda-device sounds awkward.
> > 
> > @echristo: "-O0" is not going to work for everyone in practice due to ptxas 
> > limitations. For instance on some thrust files ptxas runs out of memory on 
> > all non-inlined functions in unoptimized code. Compiling with -O2 is one 
> > way to work around that, but I do want device-side debug info!
> > 
> Huh? I'm not sure what you're doing here then with turning off optimizations 
> in the presence of debug info requests. Your commentary made it sound like 
> you can't have both.
> @hfinkel: separate option should work. Any suggestions for a good name? 
> -gcuda-device sounds awkward.

I agree it sounds awkward, but I currently have no better suggestion.


http://reviews.llvm.org/D17111



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

Re: [PATCH] D17111: [CUDA] pass debug options to ptxas.

[Eric Christopher via cfe-commits]

echristo added inline comments.


Comment at: lib/Driver/Tools.cpp:10707
@@ +10706,3 @@
+// ptxas does not accept -g option if optimization is enabled, so we ignore
+// compiler's -O* options if we want debug info.
+CmdArgs.push_back("-g");

tra wrote:
> hfinkel wrote:
> > echristo wrote:
> > > jlebar wrote:
> > > > I think this is would be very surprising to users.  -g does not usually 
> > > > have a large performance impact, so -O2 -g does not generally mean 
> > > > "generate slow code," as far as I know.  I'm concerned that this will 
> > > > result in people accidentally compiling with ptxas -O0 (which is why I 
> > > > didn't do it like this to begin with).
> > > > 
> > > > Can we accomplish this in a more explicit way?
> > > Other than warning I'm not sure what we can do, we could do that instead 
> > > and make everyone use O0 that wants debug info in their ptx?
> > I'd rather we refuse to do anything (i.e. produce an error) than silently 
> > remove either optimizations or -g. Do we have a way to separately specify 
> > the optimization level for host and device code? If not, looks like we 
> > should add one.
> NVCC has -G option to control ptxas' debug options. If it's present, ptxas 
> optimizations are disabled. I could add a similar option. "-gcuda-device" 
> perhaps?
> 
We can do that, I'd have warned because it doesn't seem like something we 
should hard error on, but I can see that perspective, i.e. we asked for 
"incompatible" options.

And no, we don't currently have a way to do that. We can try to come up with a 
driver interface.


Comment at: lib/Driver/Tools.cpp:10707
@@ +10706,3 @@
+// ptxas does not accept -g option if optimization is enabled, so we ignore
+// compiler's -O* options if we want debug info.
+CmdArgs.push_back("-g");

tra wrote:
> echristo wrote:
> > tra wrote:
> > > hfinkel wrote:
> > > > echristo wrote:
> > > > > jlebar wrote:
> > > > > > I think this is would be very surprising to users.  -g does not 
> > > > > > usually have a large performance impact, so -O2 -g does not 
> > > > > > generally mean "generate slow code," as far as I know.  I'm 
> > > > > > concerned that this will result in people accidentally compiling 
> > > > > > with ptxas -O0 (which is why I didn't do it like this to begin 
> > > > > > with).
> > > > > > 
> > > > > > Can we accomplish this in a more explicit way?
> > > > > Other than warning I'm not sure what we can do, we could do that 
> > > > > instead and make everyone use O0 that wants debug info in their ptx?
> > > > I'd rather we refuse to do anything (i.e. produce an error) than 
> > > > silently remove either optimizations or -g. Do we have a way to 
> > > > separately specify the optimization level for host and device code? If 
> > > > not, looks like we should add one.
> > > NVCC has -G option to control ptxas' debug options. If it's present, 
> > > ptxas optimizations are disabled. I could add a similar option. 
> > > "-gcuda-device" perhaps?
> > > 
> > We can do that, I'd have warned because it doesn't seem like something we 
> > should hard error on, but I can see that perspective, i.e. we asked for 
> > "incompatible" options.
> > 
> > And no, we don't currently have a way to do that. We can try to come up 
> > with a driver interface.
> @hfinkel: separate option should work. Any suggestions for a good name? 
> -gcuda-device sounds awkward.
> 
> @echristo: "-O0" is not going to work for everyone in practice due to ptxas 
> limitations. For instance on some thrust files ptxas runs out of memory on 
> all non-inlined functions in unoptimized code. Compiling with -O2 is one way 
> to work around that, but I do want device-side debug info!
> 
Huh? I'm not sure what you're doing here then with turning off optimizations in 
the presence of debug info requests. Your commentary made it sound like you 
can't have both.


http://reviews.llvm.org/D17111



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

Re: [PATCH] D17111: [CUDA] pass debug options to ptxas.

[Artem Belevich via cfe-commits]

tra added inline comments.


Comment at: lib/Driver/Tools.cpp:10707
@@ +10706,3 @@
+// ptxas does not accept -g option if optimization is enabled, so we ignore
+// compiler's -O* options if we want debug info.
+CmdArgs.push_back("-g");

tra wrote:
> hfinkel wrote:
> > echristo wrote:
> > > jlebar wrote:
> > > > I think this is would be very surprising to users.  -g does not usually 
> > > > have a large performance impact, so -O2 -g does not generally mean 
> > > > "generate slow code," as far as I know.  I'm concerned that this will 
> > > > result in people accidentally compiling with ptxas -O0 (which is why I 
> > > > didn't do it like this to begin with).
> > > > 
> > > > Can we accomplish this in a more explicit way?
> > > Other than warning I'm not sure what we can do, we could do that instead 
> > > and make everyone use O0 that wants debug info in their ptx?
> > I'd rather we refuse to do anything (i.e. produce an error) than silently 
> > remove either optimizations or -g. Do we have a way to separately specify 
> > the optimization level for host and device code? If not, looks like we 
> > should add one.
> NVCC has -G option to control ptxas' debug options. If it's present, ptxas 
> optimizations are disabled. I could add a similar option. "-gcuda-device" 
> perhaps?
> 
@hfinkel: separate option should work. Any suggestions for a good name? 
-gcuda-device sounds awkward.

@echristo: "-O0" is not going to work for everyone in practice due to ptxas 
limitations. For instance on some thrust files ptxas runs out of memory on all 
non-inlined functions in unoptimized code. Compiling with -O2 is one way to 
work around that, but I do want device-side debug info!



http://reviews.llvm.org/D17111



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

Re: [PATCH] D17111: [CUDA] pass debug options to ptxas.

[Artem Belevich via cfe-commits]

tra added inline comments.


Comment at: lib/Driver/Tools.cpp:10707
@@ +10706,3 @@
+// ptxas does not accept -g option if optimization is enabled, so we ignore
+// compiler's -O* options if we want debug info.
+CmdArgs.push_back("-g");

hfinkel wrote:
> echristo wrote:
> > jlebar wrote:
> > > I think this is would be very surprising to users.  -g does not usually 
> > > have a large performance impact, so -O2 -g does not generally mean 
> > > "generate slow code," as far as I know.  I'm concerned that this will 
> > > result in people accidentally compiling with ptxas -O0 (which is why I 
> > > didn't do it like this to begin with).
> > > 
> > > Can we accomplish this in a more explicit way?
> > Other than warning I'm not sure what we can do, we could do that instead 
> > and make everyone use O0 that wants debug info in their ptx?
> I'd rather we refuse to do anything (i.e. produce an error) than silently 
> remove either optimizations or -g. Do we have a way to separately specify the 
> optimization level for host and device code? If not, looks like we should add 
> one.
NVCC has -G option to control ptxas' debug options. If it's present, ptxas 
optimizations are disabled. I could add a similar option. "-gcuda-device" 
perhaps?



http://reviews.llvm.org/D17111



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

Re: [PATCH] D17111: [CUDA] pass debug options to ptxas.

[Hal Finkel via cfe-commits]

hfinkel added a subscriber: hfinkel.


Comment at: lib/Driver/Tools.cpp:10707
@@ +10706,3 @@
+// ptxas does not accept -g option if optimization is enabled, so we ignore
+// compiler's -O* options if we want debug info.
+CmdArgs.push_back("-g");

echristo wrote:
> jlebar wrote:
> > I think this is would be very surprising to users.  -g does not usually 
> > have a large performance impact, so -O2 -g does not generally mean 
> > "generate slow code," as far as I know.  I'm concerned that this will 
> > result in people accidentally compiling with ptxas -O0 (which is why I 
> > didn't do it like this to begin with).
> > 
> > Can we accomplish this in a more explicit way?
> Other than warning I'm not sure what we can do, we could do that instead and 
> make everyone use O0 that wants debug info in their ptx?
I'd rather we refuse to do anything (i.e. produce an error) than silently 
remove either optimizations or -g. Do we have a way to separately specify the 
optimization level for host and device code? If not, looks like we should add 
one.


http://reviews.llvm.org/D17111



___
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

[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/D16808



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

Re: [PATCH] D17111: [CUDA] pass debug options to ptxas.

[Eric Christopher via cfe-commits]

echristo added inline comments.


Comment at: lib/Driver/Tools.cpp:10707
@@ +10706,3 @@
+// ptxas does not accept -g option if optimization is enabled, so we ignore
+// compiler's -O* options if we want debug info.
+CmdArgs.push_back("-g");

jlebar wrote:
> I think this is would be very surprising to users.  -g does not usually have 
> a large performance impact, so -O2 -g does not generally mean "generate slow 
> code," as far as I know.  I'm concerned that this will result in people 
> accidentally compiling with ptxas -O0 (which is why I didn't do it like this 
> to begin with).
> 
> Can we accomplish this in a more explicit way?
Other than warning I'm not sure what we can do, we could do that instead and 
make everyone use O0 that wants debug info in their ptx?


http://reviews.llvm.org/D17111



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

Re: [PATCH] D17111: [CUDA] pass debug options to ptxas.

[Eric Christopher via cfe-commits]

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

Wow really? That's ... wow.

OK


http://reviews.llvm.org/D17111



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

Re: [PATCH] D17111: [CUDA] pass debug options to ptxas.

[Justin Lebar via cfe-commits]

jlebar added inline comments.


Comment at: lib/Driver/Tools.cpp:10707
@@ +10706,3 @@
+// ptxas does not accept -g option if optimization is enabled, so we ignore
+// compiler's -O* options if we want debug info.
+CmdArgs.push_back("-g");

I think this is would be very surprising to users.  -g does not usually have a 
large performance impact, so -O2 -g does not generally mean "generate slow 
code," as far as I know.  I'm concerned that this will result in people 
accidentally compiling with ptxas -O0 (which is why I didn't do it like this to 
begin with).

Can we accomplish this in a more explicit way?


http://reviews.llvm.org/D17111



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

Re: [PATCH] D17103: [CUDA] Don't crash when trying to printf a non-scalar object.

[Hal Finkel via cfe-commits]

hfinkel added a comment.

In http://reviews.llvm.org/D17103#349280, @jlebar wrote:

> > > I guess this is the part I'm unsure of.  If it's legal to pass a struct 
> > > to printf in regular C++ (seems to be?), I'd guess it should be legal in 
> > > CUDA, too?  I'm just not sure what it's supposed to do (in either case).
>
> > 
>
> > 
>
> > Is this because PTX does not have a way to represent va_arg structs?
>
>
> We do build up something that looks an awful lot like a va_arg struct in this 
> function.  (It's a struct with N members, one for each of the varargs.)  
> Exactly what printf expects is not particularly carefully specified in the 
> nvvm documentation.
>
> If an arg to printf is non-scalar, we could pass the whole thing into the 
> struct we build here, but that doesn't seem to be what regular C++ does (it 
> seems to take the first 64 bits of the struct -- I have no idea if this is 
> specified somewhere or just UB).


It takes the first 64 bits of the struct in your example because the struct is 
only 64 bits in size (two 32-bit ints). If you're example was:

  $ cat /tmp/p.cpp 
  #include 
  
  struct Struct {
int x;
int y;
int z;
int w;
  };
  
  void PrintfNonScalar() {
Struct S = { 1, 2, 3, 4 };
printf("%d", S);
  }

then you'd get:

  target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
  target triple = "x86_64-unknown-linux-gnu"
  
  @.str = private unnamed_addr constant [3 x i8] c"%d\00", align 1
  
  ; Function Attrs: nounwind uwtable
  define void @_Z15PrintfNonScalarv() #0 {
%1 = tail call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([3 x i8], 
[3 x i8]* @.str, i64 0, i64 0), i64 8589934593, i64 17179869187)
ret void
  }

and so on. The target ABI code decides how to handle this (by coercing the 
types to a series of ints in this case).

If you were to do this on ppc64, for example, the target ABI code there does a 
slightly different thing:

  target datalayout = "E-m:e-i64:64-n32:64"
  target triple = "powerpc64-unknown-linux-gnu"
  
  @.str = private unnamed_addr constant [3 x i8] c"%d\00", align 1
  
  ; Function Attrs: nounwind
  define void @_Z15PrintfNonScalarv() #0 {
%1 = tail call signext i32 (i8*, ...) @printf(i8* getelementptr inbounds 
([3 x i8], [3 x i8]* @.str, i64 0, i64 0), [2 x i64] [i64 4294967298, i64 
12884901892])
ret void
  }

it looks like maybe you just need some more sophisticated code in NVPTXABIInfo 
in lib/CodeGen/TargetInfo.cpp to produce something the backend will accept?


http://reviews.llvm.org/D17103



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

[PATCH] D17111: [CUDA] pass debug options to ptxas.

[Artem Belevich via cfe-commits]

tra created this revision.
tra added reviewers: jlebar, echristo.
tra added a subscriber: cfe-commits.

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

http://reviews.llvm.org/D17111

Files:
  lib/Driver/Tools.cpp
  test/Driver/cuda-external-tools.cu

Index: test/Driver/cuda-external-tools.cu
===
--- test/Driver/cuda-external-tools.cu
+++ test/Driver/cuda-external-tools.cu
@@ -18,6 +18,14 @@
 // RUN: %clang -### -target x86_64-linux-gnu -Ofast -c %s 2>&1 \
 // RUN: | FileCheck -check-prefix ARCH64 -check-prefix SM20 -check-prefix OPT3 
%s
 
+// With debugging enabled, ptxas should be run with with no ptxas 
optimizations.
+// RUN: %clang -### -target x86_64-linux-gnu -g -O2 -c %s 2>&1 \
+// RUN: | FileCheck -check-prefix ARCH64 -check-prefix SM20 -check-prefix DBG 
%s
+
+// Except when -g0 is passed which whould re-enable ptxas optimizations
+// RUN: %clang -### -target x86_64-linux-gnu -g0 -O2 -c %s 2>&1 \
+// RUN: | FileCheck -check-prefix ARCH64 -check-prefix SM20 -check-prefix OPT2 
%s
+
 // Regular compile without -O.  This should result in us passing -O0 to ptxas.
 // RUN: %clang -### -target x86_64-linux-gnu -c %s 2>&1 \
 // RUN: | FileCheck -check-prefix ARCH64 -check-prefix SM20 -check-prefix OPT0 
%s
@@ -59,9 +67,14 @@
 // ARCH64: "-m64"
 // ARCH32: "-m32"
 // OPT0: "-O0"
+// OPT0-NOT: "-g"
 // OPT1: "-O1"
+// OPT1-NOT: "-g"
 // OPT2: "-O2"
+// OPT2-NOT: "-g"
 // OPT3: "-O3"
+// OPT3-NOT: "-g"
+// DBG: "-g" "--dont-merge-basicblocks" "--return-at-end"
 // SM20: "--gpu-name" "sm_20"
 // SM35: "--gpu-name" "sm_35"
 // SM20: "--output-file" "[[CUBINFILE:[^"]*]]"
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -10695,15 +10695,25 @@
   assert(gpu_archs.size() == 1 && "Exactly one GPU Arch required for ptxas.");
   const std::string& gpu_arch = gpu_archs[0];
 
-
   ArgStringList CmdArgs;
   CmdArgs.push_back(TC.getTriple().isArch64Bit() ? "-m64" : "-m32");
+  bool WantDebug = false;
+  Args.ClaimAllArgs(options::OPT_g_Group);
+  if (Arg *A = Args.getLastArg(options::OPT_g_Group))
+WantDebug = !A->getOption().matches(options::OPT_g0) &&
+!A->getOption().matches(options::OPT_ggdb0);
+  if (WantDebug) {
+// ptxas does not accept -g option if optimization is enabled, so we ignore
+// compiler's -O* options if we want debug info.
+CmdArgs.push_back("-g");
+CmdArgs.push_back("--dont-merge-basicblocks");
+CmdArgs.push_back("--return-at-end");
+  } else if (Arg *A = Args.getLastArg(options::OPT_O_Group)) {
+// Map the -O we received to -O{0,1,2,3}.
+//
+// TODO: Perhaps we should map host -O2 to ptxas -O3. -O3 is ptxas's
+// default, so it may correspond more closely to the spirit of clang -O2.
 
-  // Map the -O we received to -O{0,1,2,3}.
-  //
-  // TODO: Perhaps we should map host -O2 to ptxas -O3. -O3 is ptxas's default,
-  // so it may correspond more closely to the spirit of clang -O2.
-  if (Arg *A = Args.getLastArg(options::OPT_O_Group)) {
 // -O3 seems like the least-bad option when -Osomething is specified to
 // clang but it isn't handled below.
 StringRef OOpt = "3";
@@ -10729,9 +10739,6 @@
 CmdArgs.push_back("-O0");
   }
 
-  // Don't bother passing -g to ptxas: It's enabled by default at -O0, and
-  // not supported at other optimization levels.
-
   CmdArgs.push_back("--gpu-name");
   CmdArgs.push_back(Args.MakeArgString(gpu_arch));
   CmdArgs.push_back("--output-file");


Index: test/Driver/cuda-external-tools.cu
===
--- test/Driver/cuda-external-tools.cu
+++ test/Driver/cuda-external-tools.cu
@@ -18,6 +18,14 @@
 // RUN: %clang -### -target x86_64-linux-gnu -Ofast -c %s 2>&1 \
 // RUN: | FileCheck -check-prefix ARCH64 -check-prefix SM20 -check-prefix OPT3 %s
 
+// With debugging enabled, ptxas should be run with with no ptxas optimizations.
+// RUN: %clang -### -target x86_64-linux-gnu -g -O2 -c %s 2>&1 \
+// RUN: | FileCheck -check-prefix ARCH64 -check-prefix SM20 -check-prefix DBG %s
+
+// Except when -g0 is passed which whould re-enable ptxas optimizations
+// RUN: %clang -### -target x86_64-linux-gnu -g0 -O2 -c %s 2>&1 \
+// RUN: | FileCheck -check-prefix ARCH64 -check-prefix SM20 -check-prefix OPT2 %s
+
 // Regular compile without -O.  This should result in us passing -O0 to ptxas.
 // RUN: %clang -### -target x86_64-linux-gnu -c %s 2>&1 \
 // RUN: | FileCheck -check-prefix ARCH64 -check-prefix SM20 -check-prefix OPT0 %s
@@ -59,9 +67,14 @@
 // ARCH64: "-m64"
 // ARCH32: "-m32"
 // OPT0: "-O0"
+// OPT0-NOT: "-g"
 // OPT1: "-O1"
+// OPT1-NOT: "-g"
 // OPT2: "-O2"
+// OPT2-NOT: "-g"
 // OPT3: "-O3"
+// OPT3-NOT: "-g"
+// DBG: "-g" "--dont-merge-basicblocks" "--return-at-end"
 // SM20: "--gpu-name" "sm_20"
 // SM35: "--gpu-name" "sm_35"

Re: r260333 - This patch adds doxygen comments for all the intrinsincs in the header file f16cintrin.h. The doxygen comments are automatically generated based on Sony's intrinsics document.

[Eric Christopher via cfe-commits]

Mostly that you didn't mention it in your commit message.

I'd rather prefer the rest of the file be changed to match the __ rather
than the other way around :)

-eric

On Wed, Feb 10, 2016 at 4:14 PM Romanova, Katya <
katya_roman...@playstation.sony.com> wrote:

> Hi Eric,
>
> Everywhere else in this file formal parameter “a” is used. This one “__a”
>  was inconsistent.
>
> However, if you don’t like it, I could change it back.
>
>
>
> Katya.
>
>
>
> *From:* Eric Christopher [mailto:echri...@gmail.com]
> *Sent:* Wednesday, February 10, 2016 3:16 PM
> *To:* Romanova, Katya; cfe-commits@lists.llvm.org
> *Subject:* Re: r260333 - This patch adds doxygen comments for all the
> intrinsincs in the header file f16cintrin.h. The doxygen comments are
> automatically generated based on Sony's intrinsics document.
>
>
>
>
>
> On Tue, Feb 9, 2016 at 4:16 PM Ekaterina Romanova via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
> Author: kromanova
> Date: Tue Feb  9 18:12:24 2016
> New Revision: 260333
>
> URL: http://llvm.org/viewvc/llvm-project?rev=260333&view=rev
> Log:
> This patch adds doxygen comments for all the intrinsincs in the header
> file f16cintrin.h. The doxygen comments are automatically generated based
> on Sony's intrinsics document.
>
> -_mm_cvtph_ps(__m128i __a)
> +_mm_cvtph_ps(__m128i a)
>  {
> -  return (__m128)__builtin_ia32_vcvtph2ps((__v8hi)__a);
> +  return (__m128)__builtin_ia32_vcvtph2ps((__v8hi)a);
>  }
>
>
>
> Ur? What's with this change?
>
>
>
> -eric
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r260472 - Fix two tests relying on LLVM -O1 behavior

[Reid Kleckner via cfe-commits]

Author: rnk
Date: Wed Feb 10 18:14:04 2016
New Revision: 260472

URL: http://llvm.org/viewvc/llvm-project?rev=260472&view=rev
Log:
Fix two tests relying on LLVM -O1 behavior

Something changed the inference of nonnull.

Modified:
cfe/trunk/test/CodeGenCXX/init-invariant.cpp
cfe/trunk/test/CodeGenCXX/microsoft-abi-dynamic-cast.cpp

Modified: cfe/trunk/test/CodeGenCXX/init-invariant.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/init-invariant.cpp?rev=260472&r1=260471&r2=260472&view=diff
==
--- cfe/trunk/test/CodeGenCXX/init-invariant.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/init-invariant.cpp Wed Feb 10 18:14:04 2016
@@ -56,5 +56,5 @@ void e() {
 
 // CHECK-LABEL: define void @_Z1ev(
 // CHECK: call void @_ZN1AC1Ev(%struct.A* nonnull @_ZZ1evE1a)
-// CHECK: call {{.*}}@llvm.invariant.start(i64 4, i8* nonnull bitcast ({{.*}} 
@_ZZ1evE1a to i8*))
+// CHECK: call {{.*}}@llvm.invariant.start(i64 4, i8* {{.*}}bitcast ({{.*}} 
@_ZZ1evE1a to i8*))
 // CHECK-NOT: llvm.invariant.end

Modified: cfe/trunk/test/CodeGenCXX/microsoft-abi-dynamic-cast.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/microsoft-abi-dynamic-cast.cpp?rev=260472&r1=260471&r2=260472&view=diff
==
--- cfe/trunk/test/CodeGenCXX/microsoft-abi-dynamic-cast.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/microsoft-abi-dynamic-cast.cpp Wed Feb 10 
18:14:04 2016
@@ -60,7 +60,7 @@ T* test5(A* x) { return dynamic_cast
 // CHECK-NEXT:   [[VBOFFP:%.*]] = getelementptr inbounds i32, i32* [[VBTBL]], 
i32 1
 // CHECK-NEXT:   [[VBOFFS:%.*]] = load i32, i32* [[VBOFFP]], align 4
 // CHECK-NEXT:   [[ADJ:%.*]] = getelementptr inbounds i8, i8* [[VOIDP]], i32 
[[VBOFFS]]
-// CHECK-NEXT:   [[CALL:%.*]] = tail call i8* @__RTDynamicCast(i8* [[ADJ]], 
i32 [[VBOFFS]], i8* nonnull bitcast (%rtti.TypeDescriptor7* @"\01??_R0?AUA@@@8" 
to i8*), i8* nonnull bitcast (%rtti.TypeDescriptor7* @"\01??_R0?AUT@@@8" to 
i8*), i32 0)
+// CHECK-NEXT:   [[CALL:%.*]] = tail call i8* @__RTDynamicCast(i8* [[ADJ]], 
i32 [[VBOFFS]], i8* {{.*}}bitcast (%rtti.TypeDescriptor7* @"\01??_R0?AUA@@@8" 
to i8*), i8* {{.*}}bitcast (%rtti.TypeDescriptor7* @"\01??_R0?AUT@@@8" to i8*), 
i32 0)
 // CHECK-NEXT:   [[RES:%.*]] = bitcast i8* [[CALL]] to %struct.T*
 // CHECK-NEXT:   br label
 // CHECK:[[RET:%.*]] = phi %struct.T*
@@ -78,7 +78,7 @@ T* test6(B* x) { return dynamic_cast
 // CHECK-NEXT:   [[VBOFFS:%.*]] = load i32, i32* [[VBOFFP]], align 4
 // CHECK-NEXT:   [[DELTA:%.*]] = add nsw i32 [[VBOFFS]], 4
 // CHECK-NEXT:   [[ADJ:%.*]] = getelementptr inbounds i8, i8* [[CAST]], i32 
[[DELTA]]
-// CHECK-NEXT:   [[CALL:%.*]] = tail call i8* @__RTDynamicCast(i8* [[ADJ]], 
i32 [[DELTA]], i8* nonnull bitcast (%rtti.TypeDescriptor7* @"\01??_R0?AUB@@@8" 
to i8*), i8* nonnull bitcast (%rtti.TypeDescriptor7* @"\01??_R0?AUT@@@8" to 
i8*), i32 0)
+// CHECK-NEXT:   [[CALL:%.*]] = tail call i8* @__RTDynamicCast(i8* [[ADJ]], 
i32 [[DELTA]], i8* {{.*}}bitcast (%rtti.TypeDescriptor7* @"\01??_R0?AUB@@@8" to 
i8*), i8* {{.*}}bitcast (%rtti.TypeDescriptor7* @"\01??_R0?AUT@@@8" to i8*), 
i32 0)
 // CHECK-NEXT:   [[RES:%.*]] = bitcast i8* [[CALL]] to %struct.T*
 // CHECK-NEXT:   br label
 // CHECK:[[RET:%.*]] = phi %struct.T*


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

RE: r260333 - This patch adds doxygen comments for all the intrinsincs in the header file f16cintrin.h. The doxygen comments are automatically generated based on Sony's intrinsics document.

[Romanova, Katya via cfe-commits]

Hi Eric,
Everywhere else in this file formal parameter “a” is used. This one “__a”  was 
inconsistent.
However, if you don’t like it, I could change it back.

Katya.

From: Eric Christopher [mailto:echri...@gmail.com]
Sent: Wednesday, February 10, 2016 3:16 PM
To: Romanova, Katya; cfe-commits@lists.llvm.org
Subject: Re: r260333 - This patch adds doxygen comments for all the intrinsincs 
in the header file f16cintrin.h. The doxygen comments are automatically 
generated based on Sony's intrinsics document.


On Tue, Feb 9, 2016 at 4:16 PM Ekaterina Romanova via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: kromanova
Date: Tue Feb  9 18:12:24 2016
New Revision: 260333

URL: http://llvm.org/viewvc/llvm-project?rev=260333&view=rev
Log:
This patch adds doxygen comments for all the intrinsincs in the header file 
f16cintrin.h. The doxygen comments are automatically generated based on Sony's 
intrinsics document.

-_mm_cvtph_ps(__m128i __a)
+_mm_cvtph_ps(__m128i a)
 {
-  return (__m128)__builtin_ia32_vcvtph2ps((__v8hi)__a);
+  return (__m128)__builtin_ia32_vcvtph2ps((__v8hi)a);
 }

Ur? What's with this change?

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

Re: [PATCH] D17103: [CUDA] Don't crash when trying to printf a non-scalar object.

[Reid Kleckner via cfe-commits]

rnk added inline comments.


Comment at: lib/CodeGen/CGCUDABuiltin.cpp:105
@@ -99,3 +104,3 @@
   llvm::Value *P = Builder.CreateStructGEP(AllocaTy, Alloca, I - 1);
   llvm::Value *Arg = Args[I].RV.getScalarVal();
   Builder.CreateAlignedStore(Arg, P, 
DL.getPrefTypeAlignment(Arg->getType()));

rnk wrote:
> I assume this is what's asserting. Probably this code should do something 
> like:
>   if (Args[I].RV.isScalar()) {
> Arg = Args[I].RV.getScalarVal();
>   } else {
> ErrorUnsupported(E, "non-scalar variadic argument");
> Arg = CGM.getNullValue(...);
>   }
Under the assumption that the implementation of vprintf expects an old-school 
va_list byte array, then it's probably easier to implement this behavior rather 
than try to diagnose it. All you have to do is memcpy the bytes of the 
aggregate.

You also might want to handle _Complex values.


http://reviews.llvm.org/D17103



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

Re: [PATCH] D17103: [CUDA] Don't crash when trying to printf a non-scalar object.

[Justin Lebar via cfe-commits]

jlebar added a comment.

> > I guess this is the part I'm unsure of.  If it's legal to pass a struct to 
> > printf in regular C++ (seems to be?), I'd guess it should be legal in CUDA, 
> > too?  I'm just not sure what it's supposed to do (in either case).

> 

> 

> Is this because PTX does not have a way to represent va_arg structs?


We do build up something that looks an awful lot like a va_arg struct in this 
function.  (It's a struct with N members, one for each of the varargs.)  
Exactly what printf expects is not particularly carefully specified in the nvvm 
documentation.

If an arg to printf is non-scalar, we could pass the whole thing into the 
struct we build here, but that doesn't seem to be what regular C++ does (it 
seems to take the first 64 bits of the struct -- I have no idea if this is 
specified somewhere or just UB).


http://reviews.llvm.org/D17103



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

Re: [PATCH] D17103: [CUDA] Don't crash when trying to printf a non-scalar object.

[Hal Finkel via cfe-commits]

hfinkel added a comment.

In http://reviews.llvm.org/D17103#349274, @jlebar wrote:

> > Ultimately, Sema should be responsible for rejecting this, correct?
>
>
> I guess this is the part I'm unsure of.  If it's legal to pass a struct to 
> printf in regular C++ (seems to be?), I'd guess it should be legal in CUDA, 
> too?  I'm just not sure what it's supposed to do (in either case).


Is this because PTX does not have a way to represent va_arg structs?


http://reviews.llvm.org/D17103



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

Re: [PATCH] D17103: [CUDA] Don't crash when trying to printf a non-scalar object.

[Justin Lebar via cfe-commits]

jlebar added a comment.

> Ultimately, Sema should be responsible for rejecting this, correct?


I guess this is the part I'm unsure of.  If it's legal to pass a struct to 
printf in regular C++ (seems to be?), I'd guess it should be legal in CUDA, 
too?  I'm just not sure what it's supposed to do (in either case).


http://reviews.llvm.org/D17103



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

Re: [PATCH] D17103: [CUDA] Don't crash when trying to printf a non-scalar object.

[Hal Finkel via cfe-commits]

hfinkel added a comment.

In http://reviews.llvm.org/D17103#349254, @jlebar wrote:

> In http://reviews.llvm.org/D17103#349245, @hfinkel wrote:
>
> > In http://reviews.llvm.org/D17103#349182, @jlebar wrote:
> >
> > > Yeah, I have no idea what's the right thing to do here.  We can always 
> > > pass a null pointer, that's easy.  David, Reid, do you know what is the 
> > > correct behavior?
> >
> >
> > I think we need to diagnose / reject this during semantic analysis (and 
> > then put a reasonable assert in the backend).
>
>
> Two things.
>
> a) That doesn't seem to be what we do in regular C++.  It will happily let 
> you pass a Struct in with only a warning.


Yes, but it also can be legally lowered and does not crash.

> b) At the moment, we don't have the capability to do a proper semantic 
> analysis of this.  The issue is, when doing sema checking of __host__ 
> __device__ functions, we don't know whether the function will end up being 
> codegen'ed for device.  And the semantics of cuda are that it's OK to do 
> things that are illegal in device mode from __host__ __device__ functions, so 
> long as you never codegen those functions for the device.

> 

> We have a plan to address (b) (basically, when doing sema checking, buffer 
> any errors we would emit if we were to codegen for device; then we can emit 
> all those errors right before codegen), but it's a much bigger thing.  Until 
> then, we need to do *something* other than crash here, even if we add 
> additional sema checking for plain __device__ fns.


Interesting dilemma. In the mean time, you can call CGM.ErrorUnsupported 
instead of removing arguments.


http://reviews.llvm.org/D17103



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

Re: [PATCH] D17103: [CUDA] Don't crash when trying to printf a non-scalar object.

[Reid Kleckner via cfe-commits]

rnk added a comment.

Ultimately, Sema should be responsible for rejecting this, correct? In the 
meantime we can have CodeGen reject this and emit a null value to avoid 
crashing.



Comment at: lib/CodeGen/CGCUDABuiltin.cpp:105
@@ -99,3 +104,3 @@
   llvm::Value *P = Builder.CreateStructGEP(AllocaTy, Alloca, I - 1);
   llvm::Value *Arg = Args[I].RV.getScalarVal();
   Builder.CreateAlignedStore(Arg, P, 
DL.getPrefTypeAlignment(Arg->getType()));

I assume this is what's asserting. Probably this code should do something like:
  if (Args[I].RV.isScalar()) {
Arg = Args[I].RV.getScalarVal();
  } else {
ErrorUnsupported(E, "non-scalar variadic argument");
Arg = CGM.getNullValue(...);
  }


http://reviews.llvm.org/D17103



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

Re: [PATCH] D17103: [CUDA] Don't crash when trying to printf a non-scalar object.

[Justin Lebar via cfe-commits]

jlebar added a comment.

In http://reviews.llvm.org/D17103#349245, @hfinkel wrote:

> In http://reviews.llvm.org/D17103#349182, @jlebar wrote:
>
> > Yeah, I have no idea what's the right thing to do here.  We can always pass 
> > a null pointer, that's easy.  David, Reid, do you know what is the correct 
> > behavior?
>
>
> I think we need to diagnose / reject this during semantic analysis (and then 
> put a reasonable assert in the backend).


Two things.

a) That doesn't seem to be what we do in regular C++.  It will happily let you 
pass a Struct in with only a warning.
b) At the moment, we don't have the capability to do a proper semantic analysis 
of this.  The issue is, when doing sema checking of __host__ __device__ 
functions, we don't know whether the function will end up being codegen'ed for 
device.  And the semantics of cuda are that it's OK to do things that are 
illegal in device mode from __host__ __device__ functions, so long as you never 
codegen those functions for the device.

We have a plan to address (b) (basically, when doing sema checking, buffer any 
errors we would emit if we were to codegen for device; then we can emit all 
those errors right before codegen), but it's a much bigger thing.  Until then, 
we need to do *something* other than crash here, even if we add additional sema 
checking for plain __device__ fns.


http://reviews.llvm.org/D17103



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

Re: [PATCH] D17103: [CUDA] Don't crash when trying to printf a non-scalar object.

[Hal Finkel via cfe-commits]

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

In http://reviews.llvm.org/D17103#349182, @jlebar wrote:

> Yeah, I have no idea what's the right thing to do here.  We can always pass a 
> null pointer, that's easy.  David, Reid, do you know what is the correct 
> behavior?


I think we need to diagnose / reject this during semantic analysis (and then 
put a reasonable assert in the backend).


http://reviews.llvm.org/D17103



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

Re: r260333 - This patch adds doxygen comments for all the intrinsincs in the header file f16cintrin.h. The doxygen comments are automatically generated based on Sony's intrinsics document.

[Eric Christopher via cfe-commits]

On Tue, Feb 9, 2016 at 4:16 PM Ekaterina Romanova via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: kromanova
> Date: Tue Feb  9 18:12:24 2016
> New Revision: 260333
>
> URL: http://llvm.org/viewvc/llvm-project?rev=260333&view=rev
> Log:
> This patch adds doxygen comments for all the intrinsincs in the header
> file f16cintrin.h. The doxygen comments are automatically generated based
> on Sony's intrinsics document.
>
> -_mm_cvtph_ps(__m128i __a)
> +_mm_cvtph_ps(__m128i a)
>  {
> -  return (__m128)__builtin_ia32_vcvtph2ps((__v8hi)__a);
> +  return (__m128)__builtin_ia32_vcvtph2ps((__v8hi)a);
>  }
>
>
Ur? What's with this change?

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

Re: [PATCH] D17104: [VFS] Drop path traversal assertion

[Ben Langmuir via cfe-commits]

benlangmuir added a comment.

I don't think this is the right approach.  If we don't canonicalize the source 
path then:

- looking up the path *without* the .. won't work, which means anything that 
looks up a realpath will fail
- directory iteration won't combine entries from foo/bar/.. and foo/

I think we're better off handling ".." in lookup and always using canonicalized 
paths in the YAML representation.


http://reviews.llvm.org/D17104



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

Re: [PATCH] D17103: [CUDA] Don't crash when trying to printf a non-scalar object.

[Justin Lebar via cfe-commits]

jlebar added a comment.

Yeah, I have no idea what's the right thing to do here.  We can always pass a 
null pointer, that's easy.  David, Reid, do you know what is the correct 
behavior?


http://reviews.llvm.org/D17103



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

Re: [PATCH] D17104: [VFS] Drop path traversal assertion

[Bruno Cardoso Lopes via cfe-commits]

bruno added a comment.

In http://reviews.llvm.org/D17104#349141, @benlangmuir wrote:

> Please clarify what you mean here:
>
> > The rationale is that if source and destination paths in the YAML file 
> > contain ".." this is enough
>
> >  for the file manager to retrieve the right file, meaning that it doesn't 
> > matter how we write it
>
> >  since the FileManager is capable of transforming it in real/feasible paths.
>
>
> The VFS layer does not have access to the FileManager.  I agree that ".." in 
> a destination path should be fine.  But ".." in a source path will only work 
> if we have code in the redirecting file system to handle ".." explicitly, 
> which AFAICT we don't:
>
>   RedirectingFileSystem::lookupPath(sys::path::const_iterator Start,
> sys::path::const_iterator End, Entry 
> *From) {
> if (Start->equals("."))
>   ++Start;
>  
> // FIXME: handle ..
>


What I mean here is that if you ask the FileManager for 
"/llvm-install/bin/../lib/clang/3.8.0/include/__stddef_max_align_t.h", it will 
successfully invoke VFS code and find 
"/vfs/llvm-install/bin/../lib/clang/3.8.0/include/__stddef_max_align_t.h".
 Since ".." is split into its own path component, it will compare ".." in Start 
and From, succeed and the search will continue. Probably this traversal code 
was not initially meant to work this way, but the actual fact is that it does.

The test in the patch tests exactly that.


http://reviews.llvm.org/D17104



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

Re: [PATCH] D17103: [CUDA] Don't crash when trying to printf a non-scalar object.

[Artem Belevich via cfe-commits]

tra added a comment.

Erasing an argument would only complicate the problem.
I guess for consistency we need to match clang's behavior for regular C++ code.
For optimized builds it just seems to pass NULL pointer instead.


http://reviews.llvm.org/D17103



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

Re: [PATCH] D17104: [VFS] Drop path traversal assertion

[Ben Langmuir via cfe-commits]

benlangmuir added a comment.

Please clarify what you mean here:

> The rationale is that if source and destination paths in the YAML file 
> contain ".." this is enough

>  for the file manager to retrieve the right file, meaning that it doesn't 
> matter how we write it

>  since the FileManager is capable of transforming it in real/feasible paths.


The VFS layer does not have access to the FileManager.  I agree that ".." in a 
destination path should be fine.  But ".." in a source path will only work if 
we have code in the redirecting file system to handle ".." explicitly, which 
AFAICT we don't:

  RedirectingFileSystem::lookupPath(sys::path::const_iterator Start,
sys::path::const_iterator End, Entry *From) 
{
if (Start->equals("."))
  ++Start;
  
// FIXME: handle ..


http://reviews.llvm.org/D17104



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

Re: [libcxx] r260012 - Cleanup node-type handling in the unordered containers

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

I'm hoping only a year or two (or three...)?

> On 2016-Feb-10, at 14:29, Eric Fiselier  wrote:
> 
> > Can we hold off a little longer?
> 
> Yes we can. The entire point of the AFAIK was to encourage migration to 
> libc++ so it makes some
> sense to keep them while they still serve this purpose.
> 
> When you say "a little longer" what sort of timeline do you have in mind?
> 
> It would be nice to get rid of these in the *long term*, but they aren't in 
> danger ATM.
> 
> /Eric
> 
> 
> On Wed, Feb 10, 2016 at 3:17 PM, Duncan P. N. Exon Smith 
>  wrote:
> 
> > On 2016-Feb-10, at 13:25, Bob Wilson  wrote:
> >
> >
> >> On Feb 10, 2016, at 12:59 PM, Tim Northover  
> >> wrote:
> >>
> >> On 10 February 2016 at 12:52, Eric Fiselier  wrote:
> >>> @Tim Are these tests in the clang test suite?
> >>
> >> Yep, at http://llvm.org/git/test-suite.git.
> >>
> >>> Marshall and I were just talking about removing  all 
> >>> together. Could you explain who still uses it?
> >>
> >> In the test-suite, it looks like it's just these two micro-benchmarks.
> >> I doubt anyone would complain about converting them to use
> >> std::unordered_map (especially since the underlying implementation
> >> seems to be shared anyway).
> >>
> >> Outside that, we seem to have a handful of internal users and Bob may
> >> have ABI backwards-compatibility concerns (or not). I've added him
> >> explicitly.
> >
> > I will defer to Duncan on that question.
> 
> Removing ext/hash_map and ext/hash_set is a great idea.  I don't have
> any ABI concerns with removing them, since they are both header-only.
> 
> Unfortunately, we still have users on libstdc++ that use ext/hash_set
> and ext/hash_map, and deleting these would make migration to libc++
> harder.  Can we hold off a little longer?  Feel free to file a PR and
> assign it to me.
> 

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

[PATCH] D17104: [VFS] Drop path traversal assertion

[Bruno Cardoso Lopes via cfe-commits]

bruno created this revision.
bruno added reviewers: bogner, benlangmuir.
bruno added subscribers: cfe-commits, dexonsmith.

This patch removes the path traversals check/assertion related with the 
presence of ".." in paths.

The rationale is that if source and destination paths in the YAML file contain 
".." this is enough
for the file manager to retrieve the right file, meaning that it doesn't matter 
how we write it
since the FileManager is capable of transforming it in real/feasible paths.

This is really common and has been working unnoticed in non-assert builds for 
while; example of an
entry like this in the VFS YAML file follow:

{
  'type': 'directory',
  'name': "/llvm-install/bin/../lib/clang/3.8.0/include",
  'contents': [
{
  'type': 'file',
  'name': "__stddef_max_align_t.h",
  'external-contents': 
"/vfs/llvm-install/bin/../lib/clang/3.8.0/include/__stddef_max_align_t.h"
},
  ...

Add a test to cover this up.

http://reviews.llvm.org/D17104

Files:
  lib/Basic/VirtualFileSystem.cpp
  test/Modules/crash-vfs-path-traversal.m

Index: test/Modules/crash-vfs-path-traversal.m
===
--- /dev/null
+++ test/Modules/crash-vfs-path-traversal.m
@@ -0,0 +1,44 @@
+// REQUIRES: crash-recovery, shell
+
+// FIXME: This XFAIL is cargo-culted from crash-report.c. Do we need it?
+// XFAIL: mingw32
+
+// RUN: rm -rf %t
+// RUN: mkdir -p %t/i %t/m %t
+
+// RUN: not env FORCE_CLANG_DIAGNOSTICS_CRASH= TMPDIR=%t TEMP=%t TMP=%t \
+// RUN: %clang -fsyntax-only %s -I %S/Inputs/System -isysroot %/t/i/\
+// RUN: -fmodules -fmodules-cache-path=%t/m/ 2>&1 | FileCheck %s
+
+// RUN: FileCheck --check-prefix=CHECKSRC %s -input-file %t/crash-vfs-*.m
+// RUN: FileCheck --check-prefix=CHECKSH %s -input-file %t/crash-vfs-*.sh
+// RUN: FileCheck --check-prefix=CHECKYAML %s -input-file \
+// RUN: %t/crash-vfs-*.cache/vfs/vfs.yaml
+// RUN: find %t/crash-vfs-*.cache/vfs | \
+// RUN:grep "Inputs/System/usr/include/stdio.h" | count 1
+
+#include "usr/include/../include/stdio.h"
+
+// CHECK: Preprocessed source(s) and associated run script(s) are located at:
+// CHECK-NEXT: note: diagnostic msg: {{.*}}.m
+// CHECK-NEXT: note: diagnostic msg: {{.*}}.cache
+
+// CHECKSRC: @import cstd.stdio;
+
+// CHECKSH: # Crash reproducer
+// CHECKSH-NEXT: # Driver args: "-fsyntax-only"
+// CHECKSH-NEXT: # Original command: {{.*$}}
+// CHECKSH-NEXT: "-cc1"
+// CHECKSH: "-isysroot" "{{[^"]*}}/i/"
+// CHECKSH-NOT: "-fmodules-cache-path="
+// CHECKSH: "crash-vfs-{{[^ ]*}}.m"
+// CHECKSH: "-ivfsoverlay" "crash-vfs-{{[^ ]*}}.cache/vfs/vfs.yaml"
+
+// CHECKYAML: 'type': 'directory'
+// CHECKYAML: 'name': "{{[^ ]*}}/Inputs/System/usr/include/../include",
+// CHECKYAML-NEXT: 'contents': [
+// CHECKYAML-NEXT:   {
+// CHECKYAML-NEXT: 'type': 'file',
+// CHECKYAML-NEXT: 'name': "module.map",
+// CHECKYAML-NEXT: 'external-contents': "{{[^ 
]*}}/Inputs/System/usr/include/../include/module.map"
+// CHECKYAML-NEXT:   },
Index: lib/Basic/VirtualFileSystem.cpp
===
--- lib/Basic/VirtualFileSystem.cpp
+++ lib/Basic/VirtualFileSystem.cpp
@@ -1376,20 +1376,13 @@
   return UniqueID(std::numeric_limits::max(), ID);
 }
 
-#ifndef NDEBUG
-static bool pathHasTraversal(StringRef Path) {
-  using namespace llvm::sys;
-  for (StringRef Comp : llvm::make_range(path::begin(Path), path::end(Path)))
-if (Comp == "." || Comp == "..")
-  return true;
-  return false;
-}
-#endif
-
 void YAMLVFSWriter::addFileMapping(StringRef VirtualPath, StringRef RealPath) {
+  // Note that the path traversals "." or ".." aren't translated (removed)
+  // along the paths, but using the path string without translation is
+  // currently enough for VirtualPath and RealPath to work when reading out the
+  // YAML with the VFS description. Would it be cleaner to handle traversals?
   assert(sys::path::is_absolute(VirtualPath) && "virtual path not absolute");
   assert(sys::path::is_absolute(RealPath) && "real path not absolute");
-  assert(!pathHasTraversal(VirtualPath) && "path traversal is not supported");
   Mappings.emplace_back(VirtualPath, RealPath);
 }
 


Index: test/Modules/crash-vfs-path-traversal.m
===
--- /dev/null
+++ test/Modules/crash-vfs-path-traversal.m
@@ -0,0 +1,44 @@
+// REQUIRES: crash-recovery, shell
+
+// FIXME: This XFAIL is cargo-culted from crash-report.c. Do we need it?
+// XFAIL: mingw32
+
+// RUN: rm -rf %t
+// RUN: mkdir -p %t/i %t/m %t
+
+// RUN: not env FORCE_CLANG_DIAGNOSTICS_CRASH= TMPDIR=%t TEMP=%t TMP=%t \
+// RUN: %clang -fsyntax-only %s -I %S/Inputs/System -isysroot %/t/i/\
+// RUN: -fmodules -fmodules-cache-path=%t/m/ 2>&1 | FileCheck %s
+
+// RUN: FileCheck --check-prefix=CHECKSRC %s -input-file %t/crash-vfs-*.m
+// RUN: FileCheck --check-prefix=CHECKSH %s -input-file %t/crash-vfs-*.sh
+// RUN: FileCheck --check-prefix=CHECKYA

[PATCH] D17103: [CUDA] Don't crash when trying to printf a non-scalar object.

[Justin Lebar via cfe-commits]

jlebar created this revision.
jlebar added reviewers: majnemer, rnk.
jlebar added subscribers: tra, jhen, cfe-commits.

We can't do the right thing, since there's no right thing to do, but at
least we can not crash the compiler.

http://reviews.llvm.org/D17103

Files:
  lib/CodeGen/CGCUDABuiltin.cpp
  test/CodeGenCUDA/printf.cu

Index: test/CodeGenCUDA/printf.cu
===
--- test/CodeGenCUDA/printf.cu
+++ test/CodeGenCUDA/printf.cu
@@ -41,3 +41,12 @@
 printf("%d", 42);
   }
 }
+
+// Check that we don't crash when asked to printf a non-scalar arg.
+struct Struct {
+  int x;
+  int y;
+};
+__device__ void PrintfNonScalar() {
+  printf("%d", Struct());
+}
Index: lib/CodeGen/CGCUDABuiltin.cpp
===
--- lib/CodeGen/CGCUDABuiltin.cpp
+++ lib/CodeGen/CGCUDABuiltin.cpp
@@ -83,6 +83,11 @@
E->arguments(), E->getDirectCallee(),
/* ParamsToSkip = */ 0);
 
+  // We don't know how to emit non-scalar varargs, so just remove them.
+  Args.erase(std::remove_if(Args.begin() + 1, Args.end(),
+[](const CallArg &A) { return !A.RV.isScalar(); }),
+ Args.end());
+
   // Construct and fill the args buffer that we'll pass to vprintf.
   llvm::Value *BufferPtr;
   if (Args.size() <= 1) {


Index: test/CodeGenCUDA/printf.cu
===
--- test/CodeGenCUDA/printf.cu
+++ test/CodeGenCUDA/printf.cu
@@ -41,3 +41,12 @@
 printf("%d", 42);
   }
 }
+
+// Check that we don't crash when asked to printf a non-scalar arg.
+struct Struct {
+  int x;
+  int y;
+};
+__device__ void PrintfNonScalar() {
+  printf("%d", Struct());
+}
Index: lib/CodeGen/CGCUDABuiltin.cpp
===
--- lib/CodeGen/CGCUDABuiltin.cpp
+++ lib/CodeGen/CGCUDABuiltin.cpp
@@ -83,6 +83,11 @@
E->arguments(), E->getDirectCallee(),
/* ParamsToSkip = */ 0);
 
+  // We don't know how to emit non-scalar varargs, so just remove them.
+  Args.erase(std::remove_if(Args.begin() + 1, Args.end(),
+[](const CallArg &A) { return !A.RV.isScalar(); }),
+ Args.end());
+
   // Construct and fill the args buffer that we'll pass to vprintf.
   llvm::Value *BufferPtr;
   if (Args.size() <= 1) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r260012 - Cleanup node-type handling in the unordered containers

[Eric Fiselier via cfe-commits]

> Can we hold off a little longer?

Yes we can. The entire point of the AFAIK was to encourage migration to
libc++ so it makes some
sense to keep them while they still serve this purpose.

When you say "a little longer" what sort of timeline do you have in mind?

It would be nice to get rid of these in the *long term*, but they aren't in
danger ATM.

/Eric


On Wed, Feb 10, 2016 at 3:17 PM, Duncan P. N. Exon Smith <
dexonsm...@apple.com> wrote:

>
> > On 2016-Feb-10, at 13:25, Bob Wilson  wrote:
> >
> >
> >> On Feb 10, 2016, at 12:59 PM, Tim Northover 
> wrote:
> >>
> >> On 10 February 2016 at 12:52, Eric Fiselier  wrote:
> >>> @Tim Are these tests in the clang test suite?
> >>
> >> Yep, at http://llvm.org/git/test-suite.git.
> >>
> >>> Marshall and I were just talking about removing  all
> together. Could you explain who still uses it?
> >>
> >> In the test-suite, it looks like it's just these two micro-benchmarks.
> >> I doubt anyone would complain about converting them to use
> >> std::unordered_map (especially since the underlying implementation
> >> seems to be shared anyway).
> >>
> >> Outside that, we seem to have a handful of internal users and Bob may
> >> have ABI backwards-compatibility concerns (or not). I've added him
> >> explicitly.
> >
> > I will defer to Duncan on that question.
>
> Removing ext/hash_map and ext/hash_set is a great idea.  I don't have
> any ABI concerns with removing them, since they are both header-only.
>
> Unfortunately, we still have users on libstdc++ that use ext/hash_set
> and ext/hash_map, and deleting these would make migration to libc++
> harder.  Can we hold off a little longer?  Feel free to file a PR and
> assign it to me.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r260388 - [MS ABI] Never reference dllimport'd vtables

[Hans Wennborg via cfe-commits]

On Wed, Feb 10, 2016 at 9:40 AM, David Majnemer via cfe-commits
 wrote:
> Author: majnemer
> Date: Wed Feb 10 11:40:47 2016
> New Revision: 260388
>
> URL: http://llvm.org/viewvc/llvm-project?rev=260388&view=rev
> Log:
> [MS ABI] Never reference dllimport'd vtables
>
> Referencing a dllimported vtable is impossible in a constexpr
> constructor.  It would be friendlier to C++ programmers if we
> synthesized a copy of the vftable which referenced imported virtual
> functions.  This would let us initialize the object in a way which
> preserves both the intent to import functionality from another DLL while
> also making constexpr work.
>
> Differential Revision: http://reviews.llvm.org/D17061

I reverted this in r260449 as it caused PR26569.

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

r260449 - Revert r260388 "[MS ABI] Never reference dllimport'd vtables"

[Hans Wennborg via cfe-commits]

Author: hans
Date: Wed Feb 10 16:18:37 2016
New Revision: 260449

URL: http://llvm.org/viewvc/llvm-project?rev=260449&view=rev
Log:
Revert r260388 "[MS ABI] Never reference dllimport'd vtables"

This caused the compiler to fail with "invalid linkage type
for global declaration" (PR26569).

Modified:
cfe/trunk/lib/AST/MicrosoftMangle.cpp
cfe/trunk/lib/AST/VTableBuilder.cpp
cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp
cfe/trunk/test/CodeGenCXX/dllimport-rtti.cpp
cfe/trunk/test/CodeGenCXX/dllimport.cpp
cfe/trunk/test/CodeGenCXX/microsoft-abi-vftables.cpp

Modified: cfe/trunk/lib/AST/MicrosoftMangle.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/MicrosoftMangle.cpp?rev=260449&r1=260448&r2=260449&view=diff
==
--- cfe/trunk/lib/AST/MicrosoftMangle.cpp (original)
+++ cfe/trunk/lib/AST/MicrosoftMangle.cpp Wed Feb 10 16:18:37 2016
@@ -2599,10 +2599,7 @@ void MicrosoftMangleContextImpl::mangleC
   // NOTE:  here is always 'B' (const). 
   // is always '6' for vftables.
   MicrosoftCXXNameMangler Mangler(*this, Out);
-  if (Derived->hasAttr())
-Mangler.getStream() << "\01??_S";
-  else
-Mangler.getStream() << "\01??_7";
+  Mangler.getStream() << "\01??_7";
   Mangler.mangleName(Derived);
   Mangler.getStream() << "6B"; // '6' for vftable, 'B' for const.
   for (const CXXRecordDecl *RD : BasePath)

Modified: cfe/trunk/lib/AST/VTableBuilder.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/VTableBuilder.cpp?rev=260449&r1=260448&r2=260449&view=diff
==
--- cfe/trunk/lib/AST/VTableBuilder.cpp (original)
+++ cfe/trunk/lib/AST/VTableBuilder.cpp Wed Feb 10 16:18:37 2016
@@ -2548,6 +2548,7 @@ public:
 // Only include the RTTI component if we know that we will provide a
 // definition of the vftable.
 HasRTTIComponent = Context.getLangOpts().RTTIData &&
+   !MostDerivedClass->hasAttr() &&
MostDerivedClass->getTemplateSpecializationKind() !=
TSK_ExplicitInstantiationDeclaration;
 

Modified: cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp?rev=260449&r1=260448&r2=260449&view=diff
==
--- cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp (original)
+++ cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp Wed Feb 10 16:18:37 2016
@@ -1673,16 +1673,7 @@ llvm::GlobalVariable *MicrosoftCXXABI::g
   SmallString<256> VFTableName;
   mangleVFTableName(getMangleContext(), RD, VFPtr, VFTableName);
 
-  // Classes marked __declspec(dllimport) need vftables generated on the
-  // import-side in order to support features like constexpr.  No other
-  // translation unit relies on the emission of the local vftable, translation
-  // units are expected to generate them as needed.
-  //
-  // Because of this unique behavior, we maintain this logic here instead of
-  // getVTableLinkage.
-  llvm::GlobalValue::LinkageTypes VFTableLinkage =
-  RD->hasAttr() ? llvm::GlobalValue::LinkOnceODRLinkage
-   : CGM.getVTableLinkage(RD);
+  llvm::GlobalValue::LinkageTypes VFTableLinkage = CGM.getVTableLinkage(RD);
   bool VFTableComesFromAnotherTU =
   llvm::GlobalValue::isAvailableExternallyLinkage(VFTableLinkage) ||
   llvm::GlobalValue::isExternalLinkage(VFTableLinkage);
@@ -1755,7 +1746,9 @@ llvm::GlobalVariable *MicrosoftCXXABI::g
   if (C)
 VTable->setComdat(C);
 
-  if (RD->hasAttr())
+  if (RD->hasAttr())
+VFTable->setDLLStorageClass(llvm::GlobalValue::DLLImportStorageClass);
+  else if (RD->hasAttr())
 VFTable->setDLLStorageClass(llvm::GlobalValue::DLLExportStorageClass);
 
   VFTablesMap[ID] = VFTable;

Modified: cfe/trunk/test/CodeGenCXX/dllimport-rtti.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/dllimport-rtti.cpp?rev=260449&r1=260448&r2=260449&view=diff
==
--- cfe/trunk/test/CodeGenCXX/dllimport-rtti.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/dllimport-rtti.cpp Wed Feb 10 16:18:37 2016
@@ -4,8 +4,7 @@
 struct __declspec(dllimport) S {
   virtual void f() {}
 } s;
-// MSVC: [[VF_S:.*]] = private unnamed_addr constant [2 x i8*]
-// MSVC-DAG: @"\01??_SS@@6B@" = unnamed_addr alias i8*, getelementptr inbounds 
([2 x i8*], [2 x i8*]* [[VF_S]], i32 0, i32 1)
+// MSVC-DAG: @"\01??_7S@@6B@" = available_externally dllimport
 // MSVC-DAG: @"\01??_R0?AUS@@@8" = linkonce_odr
 // MSVC-DAG: @"\01??_R1A@?0A@EA@S@@8" = linkonce_odr
 // MSVC-DAG: @"\01??_R2S@@8" = linkonce_odr

Modified: cfe/trunk/test/CodeGenCXX/dllimport.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/dllimport.cpp?rev=260449&r1=260448&r2=260449&view=diff

[PATCH] D17100: Remove unused ToolChain arg from Driver::ConstructPhaseAction and BuildAction.

[Justin Lebar via cfe-commits]

jlebar created this revision.
jlebar added a reviewer: echristo.
jlebar added a subscriber: cfe-commits.

Actions don't depend on the toolchain; they get bound to a particular
toolchain via BindArch.

No functional changes.

http://reviews.llvm.org/D17100

Files:
  include/clang/Driver/Driver.h
  lib/Driver/Driver.cpp

Index: lib/Driver/Driver.cpp
===
--- lib/Driver/Driver.cpp
+++ lib/Driver/Driver.cpp
@@ -510,8 +510,7 @@
   if (TC.getTriple().isOSBinFormatMachO())
 BuildUniversalActions(*C, C->getDefaultToolChain(), Inputs);
   else
-BuildActions(*C, C->getDefaultToolChain(), C->getArgs(), Inputs,
- C->getActions());
+BuildActions(*C, C->getArgs(), Inputs, C->getActions());
 
   if (CCCPrintPhases) {
 PrintActions(*C);
@@ -625,7 +624,7 @@
   if (TC.getTriple().isOSBinFormatMachO())
 BuildUniversalActions(C, TC, Inputs);
   else
-BuildActions(C, TC, C.getArgs(), Inputs, C.getActions());
+BuildActions(C, C.getArgs(), Inputs, C.getActions());
 
   BuildJobs(C);
 
@@ -1036,7 +1035,7 @@
 Archs.push_back(Args.MakeArgString(TC.getDefaultUniversalArchName()));
 
   ActionList SingleActions;
-  BuildActions(C, TC, Args, BAInputs, SingleActions);
+  BuildActions(C, Args, BAInputs, SingleActions);
 
   // Add in arch bindings for every top level action, as well as lipo and
   // dsymutil steps if needed.
@@ -1322,8 +1321,7 @@
   assert(C.getCudaDeviceToolChain() &&
  "Missing toolchain for device-side compilation.");
   ActionList CudaDeviceActions;
-  C.getDriver().BuildActions(C, *C.getCudaDeviceToolChain(), Args,
- CudaDeviceInputs, CudaDeviceActions);
+  C.getDriver().BuildActions(C, Args, CudaDeviceInputs, CudaDeviceActions);
   assert(GpuArchList.size() == CudaDeviceActions.size() &&
  "Failed to create actions for all devices");
 
@@ -1387,9 +1385,8 @@
   ActionList({FatbinAction}));
 }
 
-void Driver::BuildActions(Compilation &C, const ToolChain &TC,
-  DerivedArgList &Args, const InputList &Inputs,
-  ActionList &Actions) const {
+void Driver::BuildActions(Compilation &C, DerivedArgList &Args,
+  const InputList &Inputs, ActionList &Actions) const {
   llvm::PrettyStackTraceString CrashInfo("Building compilation actions");
 
   if (!SuppressMissingInputWarning && Inputs.empty()) {
@@ -1516,7 +1513,7 @@
 continue;
 
   // Otherwise construct the appropriate action.
-  Current = ConstructPhaseAction(C, TC, Args, Phase, Current);
+  Current = ConstructPhaseAction(C, Args, Phase, Current);
 
   if (InputType == types::TY_CUDA && Phase == CudaInjectionPhase) {
 Current = buildCudaActions(C, Args, InputArg, Current, Actions);
@@ -1553,9 +1550,8 @@
   Args.ClaimAllArgs(options::OPT_cuda_host_only);
 }
 
-Action *Driver::ConstructPhaseAction(Compilation &C, const ToolChain &TC,
- const ArgList &Args, phases::ID Phase,
- Action *Input) const {
+Action *Driver::ConstructPhaseAction(Compilation &C, const ArgList &Args,
+ phases::ID Phase, Action *Input) const {
   llvm::PrettyStackTraceString CrashInfo("Constructing phase actions");
   // Build the appropriate action.
   switch (Phase) {
Index: include/clang/Driver/Driver.h
===
--- include/clang/Driver/Driver.h
+++ include/clang/Driver/Driver.h
@@ -299,12 +299,10 @@
   /// given arguments, which are only done for a single architecture.
   ///
   /// \param C - The compilation that is being built.
-  /// \param TC - The default host tool chain.
   /// \param Args - The input arguments.
   /// \param Actions - The list to store the resulting actions onto.
-  void BuildActions(Compilation &C, const ToolChain &TC,
-llvm::opt::DerivedArgList &Args, const InputList &Inputs,
-ActionList &Actions) const;
+  void BuildActions(Compilation &C, llvm::opt::DerivedArgList &Args,
+const InputList &Inputs, ActionList &Actions) const;
 
   /// BuildUniversalActions - Construct the list of actions to perform
   /// for the given arguments, which may require a universal build.
@@ -376,9 +374,8 @@
   /// ConstructAction - Construct the appropriate action to do for
   /// \p Phase on the \p Input, taking in to account arguments
   /// like -fsyntax-only or --analyze.
-  Action *ConstructPhaseAction(Compilation &C, const ToolChain &TC,
-   const llvm::opt::ArgList &Args, phases::ID Phase,
-   Action *Input) const;
+  Action *ConstructPhaseAction(Compilation &C, const llvm::opt::ArgList &Args,
+   phases::ID Phase, Action *Input) const;
 
   /// BuildJobsForAction - Construct the jobs to pe

r260448 - Bail on compilation as soon as a job fails.

[Justin Lebar via cfe-commits]

Author: jlebar
Date: Wed Feb 10 16:17:00 2016
New Revision: 260448

URL: http://llvm.org/viewvc/llvm-project?rev=260448&view=rev
Log:
Bail on compilation as soon as a job fails.

Previously we attempted to be smart; if one job failed, we'd run all
jobs that didn't depend on the failing job.

Problem is, this doesn't work well for e.g. CUDA compilation without
-save-temps.  In this case, the device-side and host-side Assemble
actions (which actually are responsible for preprocess, compile,
backend, and assemble, since we're not saving temps) are necessarily
distinct.  So our clever heuristic doesn't help us, and we repeat every
error message once for host and once for each device arch.

The main effect of this change, other than fixing CUDA, is that if you
pass multiple cc files to one instance of clang and you get a compile
error, we'll stop when the first cc1 job fails.

Reviewers: tra, echristo

Subscribers: jhen, cfe-commits

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

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

Modified: cfe/trunk/lib/Driver/Compilation.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Compilation.cpp?rev=260448&r1=260447&r2=260448&view=diff
==
--- cfe/trunk/lib/Driver/Compilation.cpp (original)
+++ cfe/trunk/lib/Driver/Compilation.cpp Wed Feb 10 16:17:00 2016
@@ -163,39 +163,17 @@ int Compilation::ExecuteCommand(const Co
   return ExecutionFailed ? 1 : Res;
 }
 
-typedef SmallVectorImpl< std::pair > FailingCommandList;
-
-static bool ActionFailed(const Action *A,
- const FailingCommandList &FailingCommands) {
-
-  if (FailingCommands.empty())
-return false;
-
-  for (FailingCommandList::const_iterator CI = FailingCommands.begin(),
- CE = FailingCommands.end(); CI != CE; ++CI)
-if (A == &(CI->second->getSource()))
-  return true;
-
-  for (Action::const_iterator AI = A->begin(), AE = A->end(); AI != AE; ++AI)
-if (ActionFailed(*AI, FailingCommands))
-  return true;
-
-  return false;
-}
-
-static bool InputsOk(const Command &C,
- const FailingCommandList &FailingCommands) {
-  return !ActionFailed(&C.getSource(), FailingCommands);
-}
-
-void Compilation::ExecuteJobs(const JobList &Jobs,
-  FailingCommandList &FailingCommands) const {
+void Compilation::ExecuteJobs(
+const JobList &Jobs,
+SmallVectorImpl> &FailingCommands) const {
   for (const auto &Job : Jobs) {
-if (!InputsOk(Job, FailingCommands))
-  continue;
 const Command *FailingCommand = nullptr;
-if (int Res = ExecuteCommand(Job, FailingCommand))
+if (int Res = ExecuteCommand(Job, FailingCommand)) {
   FailingCommands.push_back(std::make_pair(Res, FailingCommand));
+  // Bail as soon as one command fails, so we don't output duplicate error
+  // messages if we die on e.g. the same file.
+  return;
+}
   }
 }
 


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

Re: [PATCH] D16514: Add -stop-on-failure driver option, and enable it by default for CUDA compiles.

[Justin Lebar via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL260448: Bail on compilation as soon as a job fails. 
(authored by jlebar).

Changed prior to commit:
  http://reviews.llvm.org/D16514?vs=47520&id=47525#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D16514

Files:
  cfe/trunk/lib/Driver/Compilation.cpp

Index: cfe/trunk/lib/Driver/Compilation.cpp
===
--- cfe/trunk/lib/Driver/Compilation.cpp
+++ cfe/trunk/lib/Driver/Compilation.cpp
@@ -163,39 +163,17 @@
   return ExecutionFailed ? 1 : Res;
 }
 
-typedef SmallVectorImpl< std::pair > FailingCommandList;
-
-static bool ActionFailed(const Action *A,
- const FailingCommandList &FailingCommands) {
-
-  if (FailingCommands.empty())
-return false;
-
-  for (FailingCommandList::const_iterator CI = FailingCommands.begin(),
- CE = FailingCommands.end(); CI != CE; ++CI)
-if (A == &(CI->second->getSource()))
-  return true;
-
-  for (Action::const_iterator AI = A->begin(), AE = A->end(); AI != AE; ++AI)
-if (ActionFailed(*AI, FailingCommands))
-  return true;
-
-  return false;
-}
-
-static bool InputsOk(const Command &C,
- const FailingCommandList &FailingCommands) {
-  return !ActionFailed(&C.getSource(), FailingCommands);
-}
-
-void Compilation::ExecuteJobs(const JobList &Jobs,
-  FailingCommandList &FailingCommands) const {
+void Compilation::ExecuteJobs(
+const JobList &Jobs,
+SmallVectorImpl> &FailingCommands) const {
   for (const auto &Job : Jobs) {
-if (!InputsOk(Job, FailingCommands))
-  continue;
 const Command *FailingCommand = nullptr;
-if (int Res = ExecuteCommand(Job, FailingCommand))
+if (int Res = ExecuteCommand(Job, FailingCommand)) {
   FailingCommands.push_back(std::make_pair(Res, FailingCommand));
+  // Bail as soon as one command fails, so we don't output duplicate error
+  // messages if we die on e.g. the same file.
+  return;
+}
   }
 }
 


Index: cfe/trunk/lib/Driver/Compilation.cpp
===
--- cfe/trunk/lib/Driver/Compilation.cpp
+++ cfe/trunk/lib/Driver/Compilation.cpp
@@ -163,39 +163,17 @@
   return ExecutionFailed ? 1 : Res;
 }
 
-typedef SmallVectorImpl< std::pair > FailingCommandList;
-
-static bool ActionFailed(const Action *A,
- const FailingCommandList &FailingCommands) {
-
-  if (FailingCommands.empty())
-return false;
-
-  for (FailingCommandList::const_iterator CI = FailingCommands.begin(),
- CE = FailingCommands.end(); CI != CE; ++CI)
-if (A == &(CI->second->getSource()))
-  return true;
-
-  for (Action::const_iterator AI = A->begin(), AE = A->end(); AI != AE; ++AI)
-if (ActionFailed(*AI, FailingCommands))
-  return true;
-
-  return false;
-}
-
-static bool InputsOk(const Command &C,
- const FailingCommandList &FailingCommands) {
-  return !ActionFailed(&C.getSource(), FailingCommands);
-}
-
-void Compilation::ExecuteJobs(const JobList &Jobs,
-  FailingCommandList &FailingCommands) const {
+void Compilation::ExecuteJobs(
+const JobList &Jobs,
+SmallVectorImpl> &FailingCommands) const {
   for (const auto &Job : Jobs) {
-if (!InputsOk(Job, FailingCommands))
-  continue;
 const Command *FailingCommand = nullptr;
-if (int Res = ExecuteCommand(Job, FailingCommand))
+if (int Res = ExecuteCommand(Job, FailingCommand)) {
   FailingCommands.push_back(std::make_pair(Res, FailingCommand));
+  // Bail as soon as one command fails, so we don't output duplicate error
+  // messages if we die on e.g. the same file.
+  return;
+}
   }
 }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D16514: Add -stop-on-failure driver option, and enable it by default for CUDA compiles.

[Eric Christopher via cfe-commits]

echristo accepted this revision.
echristo added a reviewer: echristo.
echristo added a comment.

This works for me and I can't think of anything it's going to break so LGTM.

Thanks!

-eric


http://reviews.llvm.org/D16514



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

Re: [libcxx] r260012 - Cleanup node-type handling in the unordered containers

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

> On 2016-Feb-10, at 13:25, Bob Wilson  wrote:
> 
> 
>> On Feb 10, 2016, at 12:59 PM, Tim Northover  wrote:
>> 
>> On 10 February 2016 at 12:52, Eric Fiselier  wrote:
>>> @Tim Are these tests in the clang test suite?
>> 
>> Yep, at http://llvm.org/git/test-suite.git.
>> 
>>> Marshall and I were just talking about removing  all 
>>> together. Could you explain who still uses it?
>> 
>> In the test-suite, it looks like it's just these two micro-benchmarks.
>> I doubt anyone would complain about converting them to use
>> std::unordered_map (especially since the underlying implementation
>> seems to be shared anyway).
>> 
>> Outside that, we seem to have a handful of internal users and Bob may
>> have ABI backwards-compatibility concerns (or not). I've added him
>> explicitly.
> 
> I will defer to Duncan on that question.

Removing ext/hash_map and ext/hash_set is a great idea.  I don't have
any ABI concerns with removing them, since they are both header-only.

Unfortunately, we still have users on libstdc++ that use ext/hash_set
and ext/hash_map, and deleting these would make migration to libc++
harder.  Can we hold off a little longer?  Feel free to file a PR and
assign it to me.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D16514: Add -stop-on-failure driver option, and enable it by default for CUDA compiles.

[Justin Lebar via cfe-commits]

jlebar updated this revision to Diff 47520.
jlebar added a comment.

Per IRL discussion with echristo, updated so that we just bail as soon as one
subjob fails.


http://reviews.llvm.org/D16514

Files:
  lib/Driver/Compilation.cpp

Index: lib/Driver/Compilation.cpp
===
--- lib/Driver/Compilation.cpp
+++ lib/Driver/Compilation.cpp
@@ -163,39 +163,17 @@
   return ExecutionFailed ? 1 : Res;
 }
 
-typedef SmallVectorImpl< std::pair > FailingCommandList;
-
-static bool ActionFailed(const Action *A,
- const FailingCommandList &FailingCommands) {
-
-  if (FailingCommands.empty())
-return false;
-
-  for (FailingCommandList::const_iterator CI = FailingCommands.begin(),
- CE = FailingCommands.end(); CI != CE; ++CI)
-if (A == &(CI->second->getSource()))
-  return true;
-
-  for (Action::const_iterator AI = A->begin(), AE = A->end(); AI != AE; ++AI)
-if (ActionFailed(*AI, FailingCommands))
-  return true;
-
-  return false;
-}
-
-static bool InputsOk(const Command &C,
- const FailingCommandList &FailingCommands) {
-  return !ActionFailed(&C.getSource(), FailingCommands);
-}
-
-void Compilation::ExecuteJobs(const JobList &Jobs,
-  FailingCommandList &FailingCommands) const {
+void Compilation::ExecuteJobs(
+const JobList &Jobs,
+SmallVectorImpl> &FailingCommands) const {
   for (const auto &Job : Jobs) {
-if (!InputsOk(Job, FailingCommands))
-  continue;
 const Command *FailingCommand = nullptr;
-if (int Res = ExecuteCommand(Job, FailingCommand))
+if (int Res = ExecuteCommand(Job, FailingCommand)) {
   FailingCommands.push_back(std::make_pair(Res, FailingCommand));
+  // Bail as soon as one command fails, so we don't output duplicate error
+  // messages if we die on e.g. the same file.
+  return;
+}
   }
 }
 


Index: lib/Driver/Compilation.cpp
===
--- lib/Driver/Compilation.cpp
+++ lib/Driver/Compilation.cpp
@@ -163,39 +163,17 @@
   return ExecutionFailed ? 1 : Res;
 }
 
-typedef SmallVectorImpl< std::pair > FailingCommandList;
-
-static bool ActionFailed(const Action *A,
- const FailingCommandList &FailingCommands) {
-
-  if (FailingCommands.empty())
-return false;
-
-  for (FailingCommandList::const_iterator CI = FailingCommands.begin(),
- CE = FailingCommands.end(); CI != CE; ++CI)
-if (A == &(CI->second->getSource()))
-  return true;
-
-  for (Action::const_iterator AI = A->begin(), AE = A->end(); AI != AE; ++AI)
-if (ActionFailed(*AI, FailingCommands))
-  return true;
-
-  return false;
-}
-
-static bool InputsOk(const Command &C,
- const FailingCommandList &FailingCommands) {
-  return !ActionFailed(&C.getSource(), FailingCommands);
-}
-
-void Compilation::ExecuteJobs(const JobList &Jobs,
-  FailingCommandList &FailingCommands) const {
+void Compilation::ExecuteJobs(
+const JobList &Jobs,
+SmallVectorImpl> &FailingCommands) const {
   for (const auto &Job : Jobs) {
-if (!InputsOk(Job, FailingCommands))
-  continue;
 const Command *FailingCommand = nullptr;
-if (int Res = ExecuteCommand(Job, FailingCommand))
+if (int Res = ExecuteCommand(Job, FailingCommand)) {
   FailingCommands.push_back(std::make_pair(Res, FailingCommand));
+  // Bail as soon as one command fails, so we don't output duplicate error
+  // messages if we die on e.g. the same file.
+  return;
+}
   }
 }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libcxx] r260443 - Remove changes that snuck in within r260431

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Wed Feb 10 15:58:36 2016
New Revision: 260443

URL: http://llvm.org/viewvc/llvm-project?rev=260443&view=rev
Log:
Remove changes that snuck in within r260431

Modified:
libcxx/trunk/include/unordered_map

Modified: libcxx/trunk/include/unordered_map
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/unordered_map?rev=260443&r1=260442&r2=260443&view=diff
==
--- libcxx/trunk/include/unordered_map (original)
+++ libcxx/trunk/include/unordered_map Wed Feb 10 15:58:36 2016
@@ -384,7 +384,6 @@ template ::__map_value_type _PairT;
 public:
 _LIBCPP_INLINE_VISIBILITY
 __unordered_map_hasher()
@@ -414,8 +413,6 @@ template 
 {
 _Hash __hash_;
-
-typedef typename __key_value_types<_Cp>::__map_value_type _PairT;
 public:
 _LIBCPP_INLINE_VISIBILITY
 __unordered_map_hasher()
@@ -457,7 +454,6 @@ template ::__map_value_type _PairT;
 public:
 _LIBCPP_INLINE_VISIBILITY
 __unordered_map_equal()
@@ -490,8 +486,6 @@ template 
 {
 _Pred __pred_;
-
-typedef typename __key_value_types<_Cp>::__map_value_type _PairT;
 public:
 _LIBCPP_INLINE_VISIBILITY
 __unordered_map_equal()
@@ -512,9 +506,6 @@ public:
 _LIBCPP_INLINE_VISIBILITY
 bool operator()(const _Key& __x, const _Cp& __y) const
 {return __pred_(__x, __y.__cc.first);}
-  _LIBCPP_INLINE_VISIBILITY
-bool operator()(const _Key& __x, const _PairT& __y) const
-{return __pred_(__x, __y.first);}
 void swap(__unordered_map_equal&__y)
 _NOEXCEPT_(__is_nothrow_swappable<_Pred>::value)
 {


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

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

[Evgeniy Stepanov via cfe-commits]

eugenis closed this revision.
eugenis added a comment.

Thanks for the review!
Committed as r260441.


Repository:
  rL LLVM

http://reviews.llvm.org/D16738



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

[libcxx] r260441 - Fix invalid casts in .

[Evgeniy Stepanov via cfe-commits]

Author: eugenis
Date: Wed Feb 10 15:53:28 2016
New Revision: 260441

URL: http://llvm.org/viewvc/llvm-project?rev=260441&view=rev
Log:
Fix invalid casts in .

static_cast of a pointer to object before the start of the object's
lifetime has undefined behavior.

This code triggers CFI warnings.

This change replaces C-style casts with reinterpret_cast, which is
fine per the standard, add applies an attribute to silence CFI (which
barks on reinterpret_cast, too).

Modified:
libcxx/trunk/include/__config
libcxx/trunk/include/functional

Modified: libcxx/trunk/include/__config
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__config?rev=260441&r1=260440&r2=260441&view=diff
==
--- libcxx/trunk/include/__config (original)
+++ libcxx/trunk/include/__config Wed Feb 10 15:53:28 2016
@@ -180,6 +180,12 @@
 # endif
 #endif  // !defined(_LIBCPP_LITTLE_ENDIAN) || !defined(_LIBCPP_BIG_ENDIAN)
 
+#if __has_attribute(__no_sanitize__)
+#define _LIBCPP_NO_CFI __attribute__((__no_sanitize__("cfi")))
+#else
+#define _LIBCPP_NO_CFI
+#endif
+
 #ifdef _WIN32
 
 // only really useful for a DLL

Modified: libcxx/trunk/include/functional
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/functional?rev=260441&r1=260440&r2=260441&view=diff
==
--- libcxx/trunk/include/functional (original)
+++ libcxx/trunk/include/functional Wed Feb 10 15:53:28 2016
@@ -1564,6 +1564,10 @@ class _LIBCPP_TYPE_VIS_ONLY function<_Rp
 typename aligned_storage<3*sizeof(void*)>::type __buf_;
 __base* __f_;
 
+_LIBCPP_NO_CFI static __base *__as_base(void *p) {
+  return reinterpret_cast<__base*>(p);
+}
+
 template ::value &&
 __invokable<_Fp&, _ArgTypes...>::value>
 struct __callable;
@@ -1660,9 +1664,9 @@ function<_Rp(_ArgTypes...)>::function(co
 {
 if (__f.__f_ == 0)
 __f_ = 0;
-else if (__f.__f_ == (const __base*)&__f.__buf_)
+else if ((void *)__f.__f_ == &__f.__buf_)
 {
-__f_ = (__base*)&__buf_;
+__f_ = __as_base(&__buf_);
 __f.__f_->__clone(__f_);
 }
 else
@@ -1676,9 +1680,9 @@ function<_Rp(_ArgTypes...)>::function(al
 {
 if (__f.__f_ == 0)
 __f_ = 0;
-else if (__f.__f_ == (const __base*)&__f.__buf_)
+else if ((void *)__f.__f_ == &__f.__buf_)
 {
-__f_ = (__base*)&__buf_;
+__f_ = __as_base(&__buf_);
 __f.__f_->__clone(__f_);
 }
 else
@@ -1690,9 +1694,9 @@ function<_Rp(_ArgTypes...)>::function(fu
 {
 if (__f.__f_ == 0)
 __f_ = 0;
-else if (__f.__f_ == (__base*)&__f.__buf_)
+else if ((void *)__f.__f_ == &__f.__buf_)
 {
-__f_ = (__base*)&__buf_;
+__f_ = __as_base(&__buf_);
 __f.__f_->__clone(__f_);
 }
 else
@@ -1709,9 +1713,9 @@ function<_Rp(_ArgTypes...)>::function(al
 {
 if (__f.__f_ == 0)
 __f_ = 0;
-else if (__f.__f_ == (__base*)&__f.__buf_)
+else if ((void *)__f.__f_ == &__f.__buf_)
 {
-__f_ = (__base*)&__buf_;
+__f_ = __as_base(&__buf_);
 __f.__f_->__clone(__f_);
 }
 else
@@ -1736,8 +1740,7 @@ function<_Rp(_ArgTypes...)>::function(_F
 typedef __function::__func<_Fp, allocator<_Fp>, _Rp(_ArgTypes...)> _FF;
 if (sizeof(_FF) <= sizeof(__buf_) && 
is_nothrow_copy_constructible<_Fp>::value)
 {
-__f_ = (__base*)&__buf_;
-::new (__f_) _FF(_VSTD::move(__f));
+__f_ = ::new((void*)&__buf_) _FF(_VSTD::move(__f));
 }
 else
 {
@@ -1766,8 +1769,7 @@ function<_Rp(_ArgTypes...)>::function(al
 if (sizeof(_FF) <= sizeof(__buf_) && 
 is_nothrow_copy_constructible<_Fp>::value && 
is_nothrow_copy_constructible<_Ap>::value)
 {
-__f_ = (__base*)&__buf_;
-::new (__f_) _FF(_VSTD::move(__f), _Alloc(__a));
+__f_ = ::new((void*)&__buf_) _FF(_VSTD::move(__f), _Alloc(__a));
 }
 else
 {
@@ -1791,16 +1793,16 @@ template
 function<_Rp(_ArgTypes...)>&
 function<_Rp(_ArgTypes...)>::operator=(function&& __f) _NOEXCEPT
 {
-if (__f_ == (__base*)&__buf_)
+if ((void *)__f_ == &__buf_)
 __f_->destroy();
 else if (__f_)
 __f_->destroy_deallocate();
 __f_ = 0;
 if (__f.__f_ == 0)
 __f_ = 0;
-else if (__f.__f_ == (__base*)&__f.__buf_)
+else if ((void *)__f.__f_ == &__f.__buf_)
 {
-__f_ = (__base*)&__buf_;
+__f_ = __as_base(&__buf_);
 __f.__f_->__clone(__f_);
 }
 else
@@ -1815,7 +1817,7 @@ template
 function<_Rp(_ArgTypes...)>&
 function<_Rp(_ArgTypes...)>::operator=(nullptr_t) _NOEXCEPT
 {
-if (__f_ == (__base*)&__buf_)
+if ((void *)__f_ == &__buf_)
 __f_->destroy();
 else if (__f_)
 __f_->destroy_deallocate();
@@ -1840,7 +1842,7 @@ function<_Rp(_A

Re: [libcxx] r260337 - Fix overload sets of strchr, strpbrk, strrchr, memchr and strstr from

[Tim Northover via cfe-commits]

On 10 February 2016 at 12:06, Richard Smith  wrote:
> OK, got the build working. This should be fixed in r260425. Please let
> me know if you're still seeing failures.

Thanks Richard, that did it.

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

Re: [PATCH] D17043: Check that the result of a library call w/o side effects is used

[Sidney San Martín via cfe-commits]

sidney added a comment.

In http://reviews.llvm.org/D17043#348982, @alexfh wrote:

> The attribute can have arguments (e.g. `[[deprecated("use some other API")]] 
> void f();`), so if there is a good reason, an argument (e.g. a custom 
> message) can be added to the `warn_unused_result` attribute. Richard might 
> have thoughts on the matter.


Ah, nice! It looks like the format is fairly flexible, too. Maybe it could take 
presets like `warn_unused_result(no_side_effects)` for common cases in addition 
to a string for a custom one? I'd be happy to try to work on this once there's 
a consensus on how/if it should work.



Comment at: clang-tidy/misc/NoSideEffectsCheck.cpp:52
@@ +51,3 @@
+AST_MATCHER(CXXMethodDecl, isAPurelyInformationalMethod) {
+  static const std::unordered_set whitelist{
+"get_allocator",

alexfh wrote:
> Can we assume that all const methods shouldn't be called without using their 
> result? This will make this list much shorter.
Good idea. I originally considered making a check that just looks for const 
methods with unused return values, but Marshall reminded me that const methods 
in third party code might have side effects. Now that this patch is restricted 
to STL containers it's safe, though.


http://reviews.llvm.org/D17043



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

Re: [PATCH] D15095: Accept "-Weverything" in pragma clang diagnostic ...

[Richard Smith via cfe-commits]

rsmith added a comment.

There seem to be two principled approaches here:

1. `DiagnosticsEngine` has a `Group` named `"everything"` (all of its interface 
supports that group, and from the point of view of someone using 
`DiagnosticsEngine` it behaves like any other group), or
2. There is no such group, and everyone calling into `DiagnosticsEngine` treats 
it as a special case if they want to allow it.

This patch is more ad-hoc: some of the `DiagnosticsEngine` interface would 
allow `"everything"`, but other parts would reject it, and we would still have 
a special case for `"everything"` in `clang::ProcessWarningOptions`. That 
results in a confusing interface contract for `DiagnosticsEngine`.

Can you move the special case code out of `DiagnosticsEngine` and into the 
pragma handler for now?


http://reviews.llvm.org/D15095



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

Re: [PATCH] D5238: [analyzer] Detect duplicate [super dealloc] calls

[Devin Coughlin via cfe-commits]

dcoughlin added a comment.

In http://reviews.llvm.org/D5238#348199, @zaks.anna wrote:

> Looks good, below are some comments which are mostly nits.
>
> What's the plan for bringing this out of alpha? Is it pending evaluation on 
> real code?


I will first extend this checker to check for uses of self after dealloc and 
then evaluate.


http://reviews.llvm.org/D5238



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

r260435 - [clang-cl] /Z7 now generates normal debug info, not just line info

[Reid Kleckner via cfe-commits]

Author: rnk
Date: Wed Feb 10 15:28:38 2016
New Revision: 260435

URL: http://llvm.org/viewvc/llvm-project?rev=260435&view=rev
Log:
[clang-cl] /Z7 now generates normal debug info, not just line info

Previously LLVM could not process any debug info we produced, so it
didn't make sense to spend time generating it. Now that it has primitive
support for local variable info, it does make sense to generate normal
debug info.

Modified:
cfe/trunk/lib/Driver/Tools.cpp
cfe/trunk/test/Driver/cl-options.c

Modified: cfe/trunk/lib/Driver/Tools.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=260435&r1=260434&r2=260435&view=diff
==
--- cfe/trunk/lib/Driver/Tools.cpp (original)
+++ cfe/trunk/lib/Driver/Tools.cpp Wed Feb 10 15:28:38 2016
@@ -5890,11 +5890,8 @@ void Clang::AddClangCLArgs(const ArgList
 
   // Emit CodeView if -Z7 is present.
   *EmitCodeView = Args.hasArg(options::OPT__SLASH_Z7);
-  bool EmitDwarf = Args.hasArg(options::OPT_gdwarf);
-  // If we are emitting CV but not DWARF, don't build information that LLVM
-  // can't yet process.
-  if (*EmitCodeView && !EmitDwarf)
-*DebugInfoKind = codegenoptions::DebugLineTablesOnly;
+  if (*EmitCodeView)
+*DebugInfoKind = codegenoptions::LimitedDebugInfo;
   if (*EmitCodeView)
 CmdArgs.push_back("-gcodeview");
 

Modified: cfe/trunk/test/Driver/cl-options.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/cl-options.c?rev=260435&r1=260434&r2=260435&view=diff
==
--- cfe/trunk/test/Driver/cl-options.c (original)
+++ cfe/trunk/test/Driver/cl-options.c Wed Feb 10 15:28:38 2016
@@ -379,11 +379,11 @@
 
 // RUN: %clang_cl /Zi /c -### -- %s 2>&1 | FileCheck -check-prefix=Zi %s
 // Zi: "-gcodeview"
-// Zi: "-debug-info-kind=line-tables-only"
+// Zi: "-debug-info-kind=limited"
 
 // RUN: %clang_cl /Z7 /c -### -- %s 2>&1 | FileCheck -check-prefix=Z7 %s
 // Z7: "-gcodeview"
-// Z7: "-debug-info-kind=line-tables-only"
+// Z7: "-debug-info-kind=limited"
 
 // RUN: %clang_cl /c -### -- %s 2>&1 | FileCheck -check-prefix=BreproDefault %s
 // BreproDefault: "-mincremental-linker-compatible"


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

Re: [PATCH] D5238: [analyzer] Detect duplicate [super dealloc] calls

[Devin Coughlin via cfe-commits]

dcoughlin updated this revision to Diff 47514.
dcoughlin added a comment.

Address more of Anna's comments.

- Add a more explicit comment about checker in header comment
- Changed the checker to always use the receiver symbol rather than the self 
symbol for clarity.
- Rework SuperDeallocBRVisitor::VisitNode() to add a note on the node where 
state transitioned from not having CalledSuperDealloc for the receiver symbol 
to having it set.
- Reworded diagnostic text.

I didn't extend Gabor's function helper to Objective-C. I'll do that in a later 
patch.


http://reviews.llvm.org/D5238

Files:
  lib/StaticAnalyzer/Checkers/CMakeLists.txt
  lib/StaticAnalyzer/Checkers/Checkers.td
  lib/StaticAnalyzer/Checkers/ObjCSuperDeallocChecker.cpp
  test/Analysis/DeallocUseAfterFreeErrors.m

Index: test/Analysis/DeallocUseAfterFreeErrors.m
===
--- /dev/null
+++ test/Analysis/DeallocUseAfterFreeErrors.m
@@ -0,0 +1,298 @@
+// RUN: %clang_cc1 -analyze -analyzer-checker=core,alpha.osx.cocoa.SuperDealloc,debug.ExprInspection -analyzer-output=text -verify %s
+
+void clang_analyzer_warnIfReached();
+
+#define nil ((id)0)
+
+typedef unsigned long NSUInteger;
+@protocol NSObject
+- (instancetype)retain;
+- (oneway void)release;
+@end
+
+@interface NSObject  { }
+- (void)dealloc;
+- (instancetype)init;
+@end
+
+typedef struct objc_selector *SEL;
+
+//======
+//  
+//  Check that 'self' is not referenced after calling '[super dealloc]'.
+
+@interface SuperDeallocThenReleaseIvarClass : NSObject {
+  NSObject *_ivar;
+}
+@end
+
+@implementation SuperDeallocThenReleaseIvarClass
+- (instancetype)initWithIvar:(NSObject *)ivar {
+  self = [super init];
+  if (!self)
+return nil;
+  _ivar = [ivar retain];
+  return self;
+}
+- (void)dealloc {
+  [super dealloc];
+  [_ivar release];
+}
+@end
+
+@interface SuperDeallocThenAssignNilToIvarClass : NSObject {
+  NSObject *_delegate;
+}
+@end
+
+@implementation SuperDeallocThenAssignNilToIvarClass
+- (instancetype)initWithDelegate:(NSObject *)delegate {
+  self = [super init];
+  if (!self)
+return nil;
+  _delegate = delegate;
+  return self;
+}
+- (void)dealloc {
+  [super dealloc];
+  _delegate = nil;
+}
+@end
+
+@interface SuperDeallocThenReleasePropertyClass : NSObject { }
+@property (retain) NSObject *ivar;
+@end
+
+@implementation SuperDeallocThenReleasePropertyClass
+- (instancetype)initWithProperty:(NSObject *)ivar {
+  self = [super init];
+  if (!self)
+return nil;
+  self.ivar = ivar;
+  return self;
+}
+- (void)dealloc {
+  [super dealloc];
+  self.ivar = nil;
+}
+@end
+
+@interface SuperDeallocThenAssignNilToPropertyClass : NSObject { }
+@property (assign) NSObject *delegate;
+@end
+
+@implementation SuperDeallocThenAssignNilToPropertyClass
+- (instancetype)initWithDelegate:(NSObject *)delegate {
+  self = [super init];
+  if (!self)
+return nil;
+  self.delegate = delegate;
+  return self;
+}
+- (void)dealloc {
+  [super dealloc];
+  self.delegate = nil;
+}
+@end
+
+@interface SuperDeallocThenCallInstanceMethodClass : NSObject { }
+- (void)_invalidate;
+@end
+
+@implementation SuperDeallocThenCallInstanceMethodClass
+- (void)_invalidate {
+}
+- (void)dealloc {
+  [super dealloc];
+  [self _invalidate];
+}
+@end
+
+@interface SuperDeallocThenCallNonObjectiveCMethodClass : NSObject { }
+@end
+
+static void _invalidate(NSObject *object) {
+  (void)object;
+}
+
+@implementation SuperDeallocThenCallNonObjectiveCMethodClass
+- (void)dealloc {
+  [super dealloc];
+  _invalidate(self);
+}
+@end
+
+@interface TwoSuperDeallocCallsClass : NSObject {
+  NSObject *_ivar;
+}
+- (void)_invalidate;
+@end
+
+@implementation TwoSuperDeallocCallsClass
+- (void)_invalidate {
+}
+- (void)dealloc {
+  if (_ivar) {
+[_ivar release];
+[super dealloc];
+return;
+  }
+  [super dealloc];
+  [self _invalidate];
+}
+@end
+
+//======
+// Warn about calling [super dealloc] twice due to missing return statement.
+
+@interface MissingReturnCausesDoubleSuperDeallocClass : NSObject {
+  NSObject *_ivar;
+}
+@end
+
+@implementation MissingReturnCausesDoubleSuperDeallocClass
+- (void)dealloc {
+  if (_ivar) { // expected-note {{Taking true branch}}
+[_ivar release];
+[super dealloc]; // expected-note {{[super dealloc] called here}}
+// return;
+  }
+  [super dealloc]; // expected-warning{{[super dealloc] called again}}
+  // expected-note@-1{{[super dealloc] called again}}
+}
+@end
+
+//======
+// Warn about calling [super dealloc] twice in two different methods.
+
+@interface SuperDeallocInOtherMethodClass : NSObject {
+  NSObject *_ivar;
+}
+- (void)_cleanup;
+@end
+
+@implementation SuperDeallocInOtherMethodClass
+- (void)_cleanup {
+  [_ivar release];
+  [super dealloc]; // expected-note {{[super 

Re: [PATCH] D17043: Check that the result of a library call w/o side effects is used

[Alexander Kornienko via cfe-commits]

alexfh added a comment.

In http://reviews.llvm.org/D17043#348569, @sidney wrote:

> In http://reviews.llvm.org/D17043#348525, @alexfh wrote:
>
> > I'd like to note that there is a library-side way to mitigate this issue 
> > using the `[[clang::warn_unused_result]]` attribute on `vector::empty()` 
> > and similar methods:
>
>
> Using an attribute sounds much better than this kind of check and I'd be fine 
> with throwing this patch out completely. IMHO the diagnostic is bad, though. 
> A message like this:
>
> >   q.cc:17:3: warning: ignoring return value of function declared with 
> > warn_unused_result attribute [-Wunused-result]
>
> > v.empty();
>
> > ^~~
>
> > 
>
>
> …is way too literal. It could indicate two completely different issues:
>
> 1. `empty()` just tells you whether the container is empty.
> 2. `empty()` has side effects and returns a value which should never be 
> ignored (like recv, send, and scanf).
>
>   Searching for this warning 
> (https://www.google.com/search?q="Wunused-result";) turns up tons of confusion.
>
>   I'm not an expert on attributes. Is there a way to attach metadata (like a 
> subtype, or a string description), so that calls without side effects could 
> have a diagnostic more like the one I wrote, and things like `recv(2)` and 
> `scanf(3)` could have rich messages?


The attribute can have arguments (e.g. `[[deprecated("use some other API")]] 
void f();`), so if there is a good reason, an argument (e.g. a custom message) 
can be added to the `warn_unused_result` attribute. Richard might have thoughts 
on the matter.

> I'm going to hold of on addressing any of your other comments until I hear 
> back. Thanks for the review!





http://reviews.llvm.org/D17043



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

Re: [libcxx] r260012 - Cleanup node-type handling in the unordered containers

[Bob Wilson via cfe-commits]

> On Feb 10, 2016, at 12:59 PM, Tim Northover  wrote:
> 
> On 10 February 2016 at 12:52, Eric Fiselier  wrote:
>> @Tim Are these tests in the clang test suite?
> 
> Yep, at http://llvm.org/git/test-suite.git.
> 
>> Marshall and I were just talking about removing  all together. 
>> Could you explain who still uses it?
> 
> In the test-suite, it looks like it's just these two micro-benchmarks.
> I doubt anyone would complain about converting them to use
> std::unordered_map (especially since the underlying implementation
> seems to be shared anyway).
> 
> Outside that, we seem to have a handful of internal users and Bob may
> have ABI backwards-compatibility concerns (or not). I've added him
> explicitly.

I will defer to Duncan on that question.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D15095: Accept "-Weverything" in pragma clang diagnostic ...

[Sunil Srivastava via cfe-commits]

Sunil_Srivastava added a comment.

Richard, Your comment and my concern about the getDiagnosticsInGroup is still 
visible in the greyed out area.

Given that do you still want to modify getDiagnosticsInGroup ?

I have removed the separate test and added the new tests to existing files, as 
you suggested.


http://reviews.llvm.org/D15095



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

Re: [PATCH] D15095: Accept "-Weverything" in pragma clang diagnostic ...

[Sunil Srivastava via cfe-commits]

Sunil_Srivastava added a reviewer: rsmith.
Sunil_Srivastava updated this revision to Diff 47509.
Sunil_Srivastava added a comment.

Changed the test, but the compiler code is still same, pending reply from 
Richard Smith


http://reviews.llvm.org/D15095

Files:
  lib/Basic/Diagnostic.cpp
  test/Preprocessor/pragma_diagnostic.c
  test/Preprocessor/pushable-diagnostics.c

Index: test/Preprocessor/pushable-diagnostics.c
===
--- test/Preprocessor/pushable-diagnostics.c
+++ test/Preprocessor/pushable-diagnostics.c
@@ -15,3 +15,27 @@
 int c = 'df';  // expected-warning{{multi-character character constant}}
 
 #pragma clang diagnostic pop // expected-warning{{pragma diagnostic pop could 
not pop, no matching push}}
+
+// Test -Weverything
+
+void ppo0(){} // first verify that we do not give anything on this
+#pragma clang diagnostic push // now push
+
+#pragma clang diagnostic warning "-Weverything" 
+void ppr1(){} // expected-warning {{no previous prototype for function 'ppr1'}}
+
+#pragma clang diagnostic push // push again
+#pragma clang diagnostic ignored "-Weverything"  // Set to ignore in this 
level.
+void pps2(){}
+#pragma clang diagnostic warning "-Weverything"  // Set to warning in this 
level.
+void ppt2(){} // expected-warning {{no previous prototype for function 'ppt2'}}
+#pragma clang diagnostic error "-Weverything"  // Set to error in this level.
+void ppt3(){} // expected-error {{no previous prototype for function 'ppt3'}}
+#pragma clang diagnostic pop // pop should go back to warning level
+
+void pps1(){} // expected-warning {{no previous prototype for function 'pps1'}}
+
+
+#pragma clang diagnostic pop // Another pop should disble it again
+void ppu(){}
+
Index: test/Preprocessor/pragma_diagnostic.c
===
--- test/Preprocessor/pragma_diagnostic.c
+++ test/Preprocessor/pragma_diagnostic.c
@@ -30,3 +30,18 @@
 
 #pragma GCC diagnostic error "-Winvalid-name"  // expected-warning {{unknown 
warning group '-Winvalid-name', ignored}}
 
+
+// Testing pragma clang diagnostic with -Weverything
+void ppo(){} // First test that we do not diagnose on this.
+
+#pragma clang diagnostic warning "-Weverything"
+void ppp(){} // expected-warning {{no previous prototype for function 'ppp'}}
+
+#pragma clang diagnostic ignored "-Weverything" // Reset it.
+void ppq(){}
+
+#pragma clang diagnostic error "-Weverything" // Now set to error
+void ppr(){} // expected-error {{no previous prototype for function 'ppr'}}
+
+#pragma clang diagnostic warning "-Weverything" // This should not be effective
+void pps(){} // expected-error {{no previous prototype for function 'pps'}}
Index: lib/Basic/Diagnostic.cpp
===
--- lib/Basic/Diagnostic.cpp
+++ lib/Basic/Diagnostic.cpp
@@ -248,6 +248,14 @@
 bool DiagnosticsEngine::setSeverityForGroup(diag::Flavor Flavor,
 StringRef Group, diag::Severity 
Map,
 SourceLocation Loc) {
+  // Special handling for pragma clang diagnostic ... "-Weverything"
+  // There is no formal group named "everything", so there has to be a special
+  // case for it.
+  if (Group == "everything") {
+   setSeverityForAll(Flavor, Map, Loc);
+   return false;
+  }
+
   // Get the diagnostics in this group.
   SmallVector GroupDiags;
   if (Diags->getDiagnosticsInGroup(Flavor, Group, GroupDiags))


Index: test/Preprocessor/pushable-diagnostics.c
===
--- test/Preprocessor/pushable-diagnostics.c
+++ test/Preprocessor/pushable-diagnostics.c
@@ -15,3 +15,27 @@
 int c = 'df';  // expected-warning{{multi-character character constant}}
 
 #pragma clang diagnostic pop // expected-warning{{pragma diagnostic pop could not pop, no matching push}}
+
+// Test -Weverything
+
+void ppo0(){} // first verify that we do not give anything on this
+#pragma clang diagnostic push // now push
+
+#pragma clang diagnostic warning "-Weverything" 
+void ppr1(){} // expected-warning {{no previous prototype for function 'ppr1'}}
+
+#pragma clang diagnostic push // push again
+#pragma clang diagnostic ignored "-Weverything"  // Set to ignore in this level.
+void pps2(){}
+#pragma clang diagnostic warning "-Weverything"  // Set to warning in this level.
+void ppt2(){} // expected-warning {{no previous prototype for function 'ppt2'}}
+#pragma clang diagnostic error "-Weverything"  // Set to error in this level.
+void ppt3(){} // expected-error {{no previous prototype for function 'ppt3'}}
+#pragma clang diagnostic pop // pop should go back to warning level
+
+void pps1(){} // expected-warning {{no previous prototype for function 'pps1'}}
+
+
+#pragma clang diagnostic pop // Another pop should disble it again
+void ppu(){}
+
Index: test/Preprocessor/pragma_diagnostic.c
==

r260433 - Test commit, fixed "clang" to "Clang" in docs

[Mandeep Singh Grang via cfe-commits]

Author: mgrang
Date: Wed Feb 10 15:06:10 2016
New Revision: 260433

URL: http://llvm.org/viewvc/llvm-project?rev=260433&view=rev
Log:
Test commit, fixed "clang" to "Clang" in docs

Reviewers: weimingz

Subscribers: cfe-commits

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

Modified:
cfe/trunk/www/index.html

Modified: cfe/trunk/www/index.html
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/www/index.html?rev=260433&r1=260432&r2=260433&view=diff
==
--- cfe/trunk/www/index.html (original)
+++ cfe/trunk/www/index.html Wed Feb 10 15:06:10 2016
@@ -93,7 +93,7 @@
be a production quality C, Objective-C, C++ and Objective-C++ compiler when 
targeting X86-32, X86-64, and ARM (other targets may have caveats, but are 
usually easy to fix).  If you are looking for source analysis or
-   source-to-source transformation tools, clang is probably a great
+   source-to-source transformation tools, Clang is probably a great
solution for you.  Clang supports C++11, please see the C++ status page for more
information.
@@ -104,14 +104,14 @@
   
   Start by getting the code, building it, and
  playing with it.  This will show you the sorts of things we can do
- today and will let you have the "clang experience" first hand: hopefully
+ today and will let you have the "Clang experience" first hand: hopefully
  it will "resonate" with you. :)
   
   Once you've done that, please consider getting
- involved in the clang community.  The clang developers include 
numerous
+ involved in the clang community.  The Clang developers include 
numerous
  volunteer contributors with a variety of backgrounds.  If you're 
  interested in
- following the development of clang, signing up for a mailing list is a 
good
+ following the development of Clang, signing up for a mailing list is a 
good
  way to learn about how the project works.
 
 


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

Re: [PATCH] D17085: Test commit, fixed "clang" to "Clang" in docs

[Mandeep Singh Grang via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL260433: Test commit, fixed "clang" to "Clang" in docs 
(authored by mgrang).

Changed prior to commit:
  http://reviews.llvm.org/D17085?vs=47493&id=47510#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D17085

Files:
  cfe/trunk/www/index.html

Index: cfe/trunk/www/index.html
===
--- cfe/trunk/www/index.html
+++ cfe/trunk/www/index.html
@@ -93,7 +93,7 @@
be a production quality C, Objective-C, C++ and Objective-C++ compiler when 
targeting X86-32, X86-64, and ARM (other targets may have caveats, but are 
usually easy to fix).  If you are looking for source analysis or
-   source-to-source transformation tools, clang is probably a great
+   source-to-source transformation tools, Clang is probably a great
solution for you.  Clang supports C++11, please see the C++ status page for more
information.
@@ -104,14 +104,14 @@
   
   Start by getting the code, building it, and
  playing with it.  This will show you the sorts of things we can do
- today and will let you have the "clang experience" first hand: hopefully
+ today and will let you have the "Clang experience" first hand: hopefully
  it will "resonate" with you. :)
   
   Once you've done that, please consider getting
- involved in the clang community.  The clang developers include 
numerous
+ involved in the clang community.  The Clang developers include 
numerous
  volunteer contributors with a variety of backgrounds.  If you're 
  interested in
- following the development of clang, signing up for a mailing list is a 
good
+ following the development of Clang, signing up for a mailing list is a 
good
  way to learn about how the project works.
 
 


Index: cfe/trunk/www/index.html
===
--- cfe/trunk/www/index.html
+++ cfe/trunk/www/index.html
@@ -93,7 +93,7 @@
be a production quality C, Objective-C, C++ and Objective-C++ compiler when 
targeting X86-32, X86-64, and ARM (other targets may have caveats, but are 
usually easy to fix).  If you are looking for source analysis or
-   source-to-source transformation tools, clang is probably a great
+   source-to-source transformation tools, Clang is probably a great
solution for you.  Clang supports C++11, please see the C++ status page for more
information.
@@ -104,14 +104,14 @@
   
   Start by getting the code, building it, and
  playing with it.  This will show you the sorts of things we can do
- today and will let you have the "clang experience" first hand: hopefully
+ today and will let you have the "Clang experience" first hand: hopefully
  it will "resonate" with you. :)
   
   Once you've done that, please consider getting
- involved in the clang community.  The clang developers include numerous
+ involved in the clang community.  The Clang developers include numerous
  volunteer contributors with a variety of backgrounds.  If you're 
  interested in
- following the development of clang, signing up for a mailing list is a good
+ following the development of Clang, signing up for a mailing list is a good
  way to learn about how the project works.
 
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Eric Fiselier via cfe-commits]

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

LGTM. Thanks for putting up with my pickyness.  It looks like there are 
exception safety issues with the order of `__f_ = __as_base(&__buf_)` and 
`__f->__f_..__clone(__f)` in a bunch of places but those are existing and so 
I'll fix them separately.

Also we are not applying this fix to the C++03 versions of std::function, but 
I'm OK with that because I want those versions to die.


Repository:
  rL LLVM

http://reviews.llvm.org/D16738



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

Re: [libcxx] r260012 - Cleanup node-type handling in the unordered containers

[Tim Northover via cfe-commits]

On 10 February 2016 at 12:52, Eric Fiselier  wrote:
> @Tim Are these tests in the clang test suite?

Yep, at http://llvm.org/git/test-suite.git.

> Marshall and I were just talking about removing  all together. 
> Could you explain who still uses it?

In the test-suite, it looks like it's just these two micro-benchmarks.
I doubt anyone would complain about converting them to use
std::unordered_map (especially since the underlying implementation
seems to be shared anyway).

Outside that, we seem to have a handful of internal users and Bob may
have ABI backwards-compatibility concerns (or not). I've added him
explicitly.

Cheers.

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

Re: [libcxx] r260012 - Cleanup node-type handling in the unordered containers

[Eric Fiselier via cfe-commits]

(Re-adding the list)

Re-committed as r260431. Let me know if there is any more breakage.

@Tim Are these tests in the clang test suite? Marshall and I were just
talking about removing  all together.
Could you explain who still uses it?


On Mon, Feb 8, 2016 at 4:52 PM, Eric Fiselier  wrote:

> Hey Tim,
>
> Sorry about the breakage. I've reverted the commit in r260172. I'll make
> sure that gnu_cxx::hash_map continues to work before recommitting.
>
> /Eric
>
>
> On Mon, Feb 8, 2016 at 2:23 PM, Tim Northover 
> wrote:
>
>> Hi Eric,
>>
>> On 6 February 2016 at 16:36, Eric Fiselier via cfe-commits
>>  wrote:
>> > Cleanup node-type handling in the unordered containers
>>
>> This seems to have broken __gnu_cxx::hash_map (used by hash.cpp and
>> hash2.cpp in the test-suite). A smaller reproducer is:
>>
>> #include 
>> typedef __gnu_cxx::hash_map> char*> > HM;
>> int foo(HM &h) {
>>   return h["wibble"];
>> }
>>
>> I don't suppose you could take a look? Or is that already planned and
>> what you're talking about with:
>>
>> > This patch will be followed up shortly with fixes for various
>> unordered_map
>> > fixes.
>>
>> Cheers.
>>
>> Tim.
>>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libcxx] r260431 - Recommit r260012 - Cleanup node-type handling in the unordered containers.

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Wed Feb 10 14:46:23 2016
New Revision: 260431

URL: http://llvm.org/viewvc/llvm-project?rev=260431&view=rev
Log:
Recommit r260012 - Cleanup node-type handling in the unordered containers.

This time I kept  working!

This patch is the first in a series of patches that's meant to better
support unordered_map. unordered_map has a special "value_type" that
differs from pair. In order to meet the EmplaceConstructible
and CopyInsertable requirements we need to teach __hash_table about this
special value_type.

This patch creates a "__hash_node_types" traits class that contains
all of the typedefs needed by the unordered containers and it's iterators.
These typedefs include ones for each node type and  node pointer type,
as well as special typedefs for "unordered_map"'s value type.

As a result of this change all of the unordered containers now all support
incomplete types.

As a drive-by fix I changed the difference_type in __hash_table to always
be ptrdiff_t. There is a corresponding change to size_type but it cannot
take affect until an ABI break.

This patch will be followed up shortly with fixes for various unordered_map
bugs and problems.

Added:
libcxx/trunk/test/libcxx/containers/unord/key_value_traits.pass.cpp
libcxx/trunk/test/std/containers/unord/iterator_difference_type.pass.cpp
libcxx/trunk/test/std/containers/unord/unord.map/incomplete_type.pass.cpp
libcxx/trunk/test/std/containers/unord/unord.multimap/incomplete.pass.cpp
libcxx/trunk/test/std/containers/unord/unord.multiset/incomplete.pass.cpp
libcxx/trunk/test/std/containers/unord/unord.set/incomplete.pass.cpp
Modified:
libcxx/trunk/include/__config
libcxx/trunk/include/__hash_table
libcxx/trunk/include/ext/hash_map
libcxx/trunk/include/unordered_map

Modified: libcxx/trunk/include/__config
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__config?rev=260431&r1=260430&r2=260431&view=diff
==
--- libcxx/trunk/include/__config (original)
+++ libcxx/trunk/include/__config Wed Feb 10 14:46:23 2016
@@ -42,6 +42,7 @@
 // Fix undefined behavior in how std::list stores it's linked nodes.
 #define _LIBCPP_ABI_LIST_REMOVE_NODE_POINTER_UB
 #define _LIBCPP_ABI_FORWARD_LIST_REMOVE_NODE_POINTER_UB
+#define _LIBCPP_ABI_FIX_UNORDERED_CONTAINER_SIZE_TYPE
 #endif
 
 #define _LIBCPP_CONCAT1(_LIBCPP_X,_LIBCPP_Y) _LIBCPP_X##_LIBCPP_Y

Modified: libcxx/trunk/include/__hash_table
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__hash_table?rev=260431&r1=260430&r2=260431&view=diff
==
--- libcxx/trunk/include/__hash_table (original)
+++ libcxx/trunk/include/__hash_table Wed Feb 10 14:46:23 2016
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include <__undef_min_max>
 #include <__undef___deallocate>
@@ -49,10 +50,10 @@ struct __hash_node
  typename __rebind_pointer<_VoidPtr, __hash_node<_Tp, 
_VoidPtr> >::type
  >
 {
-typedef _Tp value_type;
+typedef _Tp __node_value_type;
 
 size_t __hash_;
-value_type __value_;
+__node_value_type __value_;
 };
 
 inline _LIBCPP_INLINE_VISIBILITY
@@ -77,23 +78,126 @@ __next_hash_pow2(size_t __n)
 }
 
 template  class 
__hash_table;
+
+template   class _LIBCPP_TYPE_VIS_ONLY __hash_iterator;
 template  class _LIBCPP_TYPE_VIS_ONLY 
__hash_const_iterator;
+template   class _LIBCPP_TYPE_VIS_ONLY 
__hash_local_iterator;
+template  class _LIBCPP_TYPE_VIS_ONLY 
__hash_const_local_iterator;
 template  class _LIBCPP_TYPE_VIS_ONLY __hash_map_iterator;
 template  class _LIBCPP_TYPE_VIS_ONLY 
__hash_map_const_iterator;
 
+#if __cplusplus >= 201103L
+template 
+union __hash_value_type;
+#else
+template 
+struct __hash_value_type;
+#endif
+
+template 
+struct __key_value_types {
+  static_assert(!is_reference<_Tp>::value && !is_const<_Tp>::value, "");
+  typedef _Tp key_type;
+  typedef _Tp __node_value_type;
+  typedef _Tp __container_value_type;
+  static const bool __is_map = false;
+};
+
+template 
+struct __key_value_types<__hash_value_type<_Key, _Tp> > {
+  typedef _Key key_type;
+  typedef _Tp  mapped_type;
+  typedef __hash_value_type<_Key, _Tp> __node_value_type;
+  typedef pair__container_value_type;
+  typedef __container_value_type   __map_value_type;
+  static const bool __is_map = true;
+};
+
+template ,
+  bool = _KVTypes::__is_map>
+struct __map_pointer_types {};
+
+template 
+struct __map_pointer_types<_Tp, _AllocPtr, _KVTypes, true> {
+  typedef typename _KVTypes::__map_value_type   _Mv;
+  typedef typename __rebind_pointer<_AllocPtr, _Mv>::type
+   
__map_value_type_pointer;
+  typedef typename __rebind_pointer<_AllocPtr, c

[PATCH] D17091: [analyzer][scan-build-py] Non-existing directory for scan-build output.

[Anton Yartsev via cfe-commits]

ayartsev created this revision.
ayartsev added a reviewer: rizsotto.mailinglist.
ayartsev added a subscriber: cfe-commits.

Attached patch makes scan-build successfully accept non-existing output 
directories provided via "-o" option. The directory is created in this case. 
This behavior is conforming to the old perl scan-build implementation. Please 
review.

http://reviews.llvm.org/D17091

Files:
  tools/scan-build-py/libscanbuild/report.py

Index: tools/scan-build-py/libscanbuild/report.py
===
--- tools/scan-build-py/libscanbuild/report.py
+++ tools/scan-build-py/libscanbuild/report.py
@@ -35,7 +35,12 @@
 keep -- a boolean value to keep or delete the empty report directory. """
 
 stamp = time.strftime('scan-build-%Y-%m-%d-%H%M%S-', time.localtime())
-name = tempfile.mkdtemp(prefix=stamp, dir=hint)
+
+parentdir = os.path.abspath(hint);
+if not os.path.exists(parentdir):
+os.makedirs(parentdir)
+
+name = tempfile.mkdtemp(prefix=stamp, dir=parentdir)
 
 logging.info('Report directory created: %s', name)
 


Index: tools/scan-build-py/libscanbuild/report.py
===
--- tools/scan-build-py/libscanbuild/report.py
+++ tools/scan-build-py/libscanbuild/report.py
@@ -35,7 +35,12 @@
 keep -- a boolean value to keep or delete the empty report directory. """
 
 stamp = time.strftime('scan-build-%Y-%m-%d-%H%M%S-', time.localtime())
-name = tempfile.mkdtemp(prefix=stamp, dir=hint)
+
+parentdir = os.path.abspath(hint);
+if not os.path.exists(parentdir):
+os.makedirs(parentdir)
+
+name = tempfile.mkdtemp(prefix=stamp, dir=parentdir)
 
 logging.info('Report directory created: %s', name)
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r260337 - Fix overload sets of strchr, strpbrk, strrchr, memchr and strstr from

[Richard Smith via cfe-commits]

OK, got the build working. This should be fixed in r260425. Please let
me know if you're still seeing failures.

On Wed, Feb 10, 2016 at 11:59 AM, Richard Smith  wrote:
> On Wed, Feb 10, 2016 at 10:32 AM, Tim Northover  
> wrote:
>> Hi Richard,
>>
>> On 9 February 2016 at 16:59, Richard Smith via cfe-commits
>>  wrote:
>>> Fix overload sets of strchr, strpbrk, strrchr, memchr and strstr from
>>>  and wcschr, wcspbrk, wcsrchr, wmemchr, and wcsstr from  
>>> to
>>> provide a const-correct overload set even when the underlying C library does
>>> not.
>>
>> This seems to have caused breakage on one of compiler-rt's tests on
>> Darwin: lib/asan/test/asan_str_test.cc if I'm reading the runes
>> correctly. See 
>> http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA_check/10117/
>> for example.
>>
>> I'm not quite sure what's going on, but it seems to involve enable_if
>> disabling some overload checks, leading to an inconsistent set of
>> possible functions. That's probably an independent bug in clang
>> (there's certainly no mangling to support it in Itanium), but I
>> suspect libc++ shouldn't be trying to produce such combinations
>> anyway.
>>
>> The smallest test case with the essential Clang details I've found is:
>>
>> char *foo(const char *);
>> char *foo(char *);
>> __attribute__ ((__enable_if__(true, ""))) const char *foo(const char *);
>>
>> void test(char *(*)(const char *));
>> void test(char *(*)(char *));
>>
>> void func(char *in) {
>>   test(&foo);
>> }
>>
>> Do you have any ideas on what to do, because I'm a bit stuck I'm
>> afraid. I can give you preprocessed source if you're struggling to
>> reproduce the issue (it's 2.4MB for the default 7ish for
>> -frewrite-includes).
>
> Thanks for the reduction. I've been trying to reproduce this, but
> compiler-rt won't build for me (apparently something has broken in its
> support for libc++ since I last used it -- it's passing -stdlib=libc++
> to compile actions but not to the link).
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r260337 - Fix overload sets of strchr, strpbrk, strrchr, memchr and strstr from

[Richard Smith via cfe-commits]

On Wed, Feb 10, 2016 at 10:32 AM, Tim Northover  wrote:
> Hi Richard,
>
> On 9 February 2016 at 16:59, Richard Smith via cfe-commits
>  wrote:
>> Fix overload sets of strchr, strpbrk, strrchr, memchr and strstr from
>>  and wcschr, wcspbrk, wcsrchr, wmemchr, and wcsstr from  
>> to
>> provide a const-correct overload set even when the underlying C library does
>> not.
>
> This seems to have caused breakage on one of compiler-rt's tests on
> Darwin: lib/asan/test/asan_str_test.cc if I'm reading the runes
> correctly. See 
> http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA_check/10117/
> for example.
>
> I'm not quite sure what's going on, but it seems to involve enable_if
> disabling some overload checks, leading to an inconsistent set of
> possible functions. That's probably an independent bug in clang
> (there's certainly no mangling to support it in Itanium), but I
> suspect libc++ shouldn't be trying to produce such combinations
> anyway.
>
> The smallest test case with the essential Clang details I've found is:
>
> char *foo(const char *);
> char *foo(char *);
> __attribute__ ((__enable_if__(true, ""))) const char *foo(const char *);
>
> void test(char *(*)(const char *));
> void test(char *(*)(char *));
>
> void func(char *in) {
>   test(&foo);
> }
>
> Do you have any ideas on what to do, because I'm a bit stuck I'm
> afraid. I can give you preprocessed source if you're struggling to
> reproduce the issue (it's 2.4MB for the default 7ish for
> -frewrite-includes).

Thanks for the reduction. I've been trying to reproduce this, but
compiler-rt won't build for me (apparently something has broken in its
support for libc++ since I last used it -- it's passing -stdlib=libc++
to compile actions but not to the link).
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D16971: Fixed crash when partial specialization is missing required parameters

[don hinton via cfe-commits]

hintonda added a comment.

I don't have commit access, so if this patch is accepted, could someone please 
commit it for me?


http://reviews.llvm.org/D16971



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

Re: [PATCH] D17072: Return immediatedly if Method is null, otherwise you'll get a crash when dyn_cast is called with a nullptr

[don hinton via cfe-commits]

hintonda added a comment.

I don't have commit access, so if this patch is accepted, could someone please 
commit it for me?


http://reviews.llvm.org/D17072



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

Re: [PATCH] D17072: Return immediatedly if Method is null, otherwise you'll get a crash when dyn_cast is called with a nullptr

[don hinton via cfe-commits]

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

- Added test for PR25181


http://reviews.llvm.org/D17072

Files:
  lib/Parse/ParseCXXInlineMethods.cpp
  test/SemaCXX/pr25181-crash-on-invalid.cpp

Index: test/SemaCXX/pr25181-crash-on-invalid.cpp
===
--- /dev/null
+++ test/SemaCXX/pr25181-crash-on-invalid.cpp
@@ -0,0 +1,7 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c++11 %s
+// Don't crash (PR25181).
+
+template  class Foo { // expected-note {{template parameter is 
declared here}}
+  template  // expected-error {{declaration of 'T' shadows 
template parameter}}
+  void Foo::method(T *) const throw() {} // expected-error {{nested name 
specifier 'Foo::' for declaration does not refer into a class, class 
template or class template partial specialization}}
+};
Index: lib/Parse/ParseCXXInlineMethods.cpp
===
--- lib/Parse/ParseCXXInlineMethods.cpp
+++ lib/Parse/ParseCXXInlineMethods.cpp
@@ -293,6 +293,8 @@
 }
 
 void Parser::ParseLexedMethodDeclaration(LateParsedMethodDeclaration &LM) {
+  if (!LM.Method)
+return;
   // If this is a member template, introduce the template parameter scope.
   ParseScope TemplateScope(this, Scope::TemplateParamScope, LM.TemplateScope);
   TemplateParameterDepthRAII CurTemplateDepthTracker(TemplateParameterDepth);


Index: test/SemaCXX/pr25181-crash-on-invalid.cpp
===
--- /dev/null
+++ test/SemaCXX/pr25181-crash-on-invalid.cpp
@@ -0,0 +1,7 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c++11 %s
+// Don't crash (PR25181).
+
+template  class Foo { // expected-note {{template parameter is declared here}}
+  template  // expected-error {{declaration of 'T' shadows template parameter}}
+  void Foo::method(T *) const throw() {} // expected-error {{nested name specifier 'Foo::' for declaration does not refer into a class, class template or class template partial specialization}}
+};
Index: lib/Parse/ParseCXXInlineMethods.cpp
===
--- lib/Parse/ParseCXXInlineMethods.cpp
+++ lib/Parse/ParseCXXInlineMethods.cpp
@@ -293,6 +293,8 @@
 }
 
 void Parser::ParseLexedMethodDeclaration(LateParsedMethodDeclaration &LM) {
+  if (!LM.Method)
+return;
   // If this is a member template, introduce the template parameter scope.
   ParseScope TemplateScope(this, Scope::TemplateParamScope, LM.TemplateScope);
   TemplateParameterDepthRAII CurTemplateDepthTracker(TemplateParameterDepth);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D16971: Fixed crash when partial specialization is missing required parameters

[don hinton via cfe-commits]

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

- Added test for PR26077


http://reviews.llvm.org/D16971

Files:
  lib/Sema/SemaTemplate.cpp
  test/SemaCXX/pr26077-crash-on-invalid.cpp

Index: test/SemaCXX/pr26077-crash-on-invalid.cpp
===
--- /dev/null
+++ test/SemaCXX/pr26077-crash-on-invalid.cpp
@@ -0,0 +1,15 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c++11 %s
+// Don't crash (PR26077).
+
+class DB {};
+
+template  class RemovePolicy : public T {};
+
+template >
+  class Crash : T, Policy {};
+
+template 
+class Crash : public DB, public Policy { // expected-error {{partial 
specialization of 'Crash' does not use any of its template parameters}}
+public:
+  Crash(){}
+};
Index: lib/Sema/SemaTemplate.cpp
===
--- lib/Sema/SemaTemplate.cpp
+++ lib/Sema/SemaTemplate.cpp
@@ -2542,7 +2542,7 @@
 InstantiationDependent)) {
   Diag(TemplateNameLoc, diag::err_partial_spec_fully_specialized)
   << VarTemplate->getDeclName();
-  IsPartialSpecialization = false;
+  return true;
 }
 
 if (isSameAsPrimaryTemplate(VarTemplate->getTemplateParameters(),
@@ -6286,7 +6286,7 @@
  InstantiationDependent)) {
   Diag(TemplateNameLoc, diag::err_partial_spec_fully_specialized)
 << ClassTemplate->getDeclName();
-  isPartialSpecialization = false;
+  return true;
 }
   }
 


Index: test/SemaCXX/pr26077-crash-on-invalid.cpp
===
--- /dev/null
+++ test/SemaCXX/pr26077-crash-on-invalid.cpp
@@ -0,0 +1,15 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c++11 %s
+// Don't crash (PR26077).
+
+class DB {};
+
+template  class RemovePolicy : public T {};
+
+template >
+  class Crash : T, Policy {};
+
+template 
+class Crash : public DB, public Policy { // expected-error {{partial specialization of 'Crash' does not use any of its template parameters}}
+public:
+  Crash(){}
+};
Index: lib/Sema/SemaTemplate.cpp
===
--- lib/Sema/SemaTemplate.cpp
+++ lib/Sema/SemaTemplate.cpp
@@ -2542,7 +2542,7 @@
 InstantiationDependent)) {
   Diag(TemplateNameLoc, diag::err_partial_spec_fully_specialized)
   << VarTemplate->getDeclName();
-  IsPartialSpecialization = false;
+  return true;
 }
 
 if (isSameAsPrimaryTemplate(VarTemplate->getTemplateParameters(),
@@ -6286,7 +6286,7 @@
  InstantiationDependent)) {
   Diag(TemplateNameLoc, diag::err_partial_spec_fully_specialized)
 << ClassTemplate->getDeclName();
-  isPartialSpecialization = false;
+  return true;
 }
   }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r260420 - [analyzer] Windows: launch scan-build from an arbitrary location.

[Anton Yartsev via cfe-commits]

Author: ayartsev
Date: Wed Feb 10 13:46:41 2016
New Revision: 260420

URL: http://llvm.org/viewvc/llvm-project?rev=260420&view=rev
Log:
[analyzer] Windows: launch scan-build from an arbitrary location.

The following batch files allow to launch scan-build from an arbitrary location 
if path to clang\tools\scan-build-py\bin is added to %PATH%.

Added:
cfe/trunk/tools/scan-build-py/bin/analyze-build.bat
cfe/trunk/tools/scan-build-py/bin/analyze-c++.bat
cfe/trunk/tools/scan-build-py/bin/analyze-cc.bat
cfe/trunk/tools/scan-build-py/bin/intercept-build.bat
cfe/trunk/tools/scan-build-py/bin/intercept-c++.bat
cfe/trunk/tools/scan-build-py/bin/intercept-cc.bat
cfe/trunk/tools/scan-build-py/bin/scan-build.bat

Added: cfe/trunk/tools/scan-build-py/bin/analyze-build.bat
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/scan-build-py/bin/analyze-build.bat?rev=260420&view=auto
==
--- cfe/trunk/tools/scan-build-py/bin/analyze-build.bat (added)
+++ cfe/trunk/tools/scan-build-py/bin/analyze-build.bat Wed Feb 10 13:46:41 2016
@@ -0,0 +1 @@
+python %~dp0analyze-build %*

Added: cfe/trunk/tools/scan-build-py/bin/analyze-c++.bat
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/scan-build-py/bin/analyze-c%2B%2B.bat?rev=260420&view=auto
==
--- cfe/trunk/tools/scan-build-py/bin/analyze-c++.bat (added)
+++ cfe/trunk/tools/scan-build-py/bin/analyze-c++.bat Wed Feb 10 13:46:41 2016
@@ -0,0 +1 @@
+python %~dp0analyze-c++ %*

Added: cfe/trunk/tools/scan-build-py/bin/analyze-cc.bat
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/scan-build-py/bin/analyze-cc.bat?rev=260420&view=auto
==
--- cfe/trunk/tools/scan-build-py/bin/analyze-cc.bat (added)
+++ cfe/trunk/tools/scan-build-py/bin/analyze-cc.bat Wed Feb 10 13:46:41 2016
@@ -0,0 +1 @@
+python %~dp0analyze-cc %*

Added: cfe/trunk/tools/scan-build-py/bin/intercept-build.bat
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/scan-build-py/bin/intercept-build.bat?rev=260420&view=auto
==
--- cfe/trunk/tools/scan-build-py/bin/intercept-build.bat (added)
+++ cfe/trunk/tools/scan-build-py/bin/intercept-build.bat Wed Feb 10 13:46:41 
2016
@@ -0,0 +1 @@
+python %~dp0intercept-build %*

Added: cfe/trunk/tools/scan-build-py/bin/intercept-c++.bat
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/scan-build-py/bin/intercept-c%2B%2B.bat?rev=260420&view=auto
==
--- cfe/trunk/tools/scan-build-py/bin/intercept-c++.bat (added)
+++ cfe/trunk/tools/scan-build-py/bin/intercept-c++.bat Wed Feb 10 13:46:41 2016
@@ -0,0 +1 @@
+python %~dp0intercept-c++ %*

Added: cfe/trunk/tools/scan-build-py/bin/intercept-cc.bat
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/scan-build-py/bin/intercept-cc.bat?rev=260420&view=auto
==
--- cfe/trunk/tools/scan-build-py/bin/intercept-cc.bat (added)
+++ cfe/trunk/tools/scan-build-py/bin/intercept-cc.bat Wed Feb 10 13:46:41 2016
@@ -0,0 +1 @@
+python %~dp0intercept-cc %*

Added: cfe/trunk/tools/scan-build-py/bin/scan-build.bat
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/scan-build-py/bin/scan-build.bat?rev=260420&view=auto
==
--- cfe/trunk/tools/scan-build-py/bin/scan-build.bat (added)
+++ cfe/trunk/tools/scan-build-py/bin/scan-build.bat Wed Feb 10 13:46:41 2016
@@ -0,0 +1 @@
+python %~dp0scan-build %*


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

Re: [PATCH] D17085: Test commit, fixed "clang" to "Clang" in docs

[Weiming Zhao via cfe-commits]

weimingz added a comment.

LGTM


http://reviews.llvm.org/D17085



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

Re: [PATCH] D17060: [Clang] Fix Clang-tidy readability-redundant-control-flow warnings; other minor fixes

[Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL260414: Fix some Clang-tidy 
readability-redundant-control-flow warnings; other minor… (authored by 
eugenezelenko).

Changed prior to commit:
  http://reviews.llvm.org/D17060?vs=47415&id=47492#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D17060

Files:
  cfe/trunk/include/clang/Analysis/Analyses/ThreadSafetyUtil.h
  cfe/trunk/lib/ARCMigrate/ObjCMT.cpp
  cfe/trunk/lib/AST/ASTDiagnostic.cpp
  cfe/trunk/lib/AST/CommentLexer.cpp
  cfe/trunk/lib/AST/CommentSema.cpp
  cfe/trunk/lib/CodeGen/CGClass.cpp
  cfe/trunk/lib/CodeGen/CGDecl.cpp
  cfe/trunk/lib/CodeGen/CGObjCGNU.cpp
  cfe/trunk/lib/CodeGen/CGObjCMac.cpp
  cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
  cfe/trunk/lib/Frontend/Rewrite/RewriteModernObjC.cpp
  cfe/trunk/lib/Frontend/Rewrite/RewriteObjC.cpp
  cfe/trunk/lib/StaticAnalyzer/Checkers/BasicObjCFoundationChecks.cpp
  cfe/trunk/lib/StaticAnalyzer/Checkers/CheckerDocumentation.cpp
  cfe/trunk/lib/StaticAnalyzer/Checkers/ChrootChecker.cpp
  cfe/trunk/lib/StaticAnalyzer/Checkers/DynamicTypePropagation.cpp
  cfe/trunk/lib/StaticAnalyzer/Checkers/IvarInvalidationChecker.cpp
  cfe/trunk/lib/StaticAnalyzer/Checkers/ObjCContainersChecker.cpp
  cfe/trunk/lib/StaticAnalyzer/Checkers/VLASizeChecker.cpp
  cfe/trunk/lib/StaticAnalyzer/Core/ExprEngineCallAndReturn.cpp
  cfe/trunk/lib/StaticAnalyzer/Core/MemRegion.cpp
  cfe/trunk/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
  cfe/trunk/tools/libclang/CXSourceLocation.cpp

Index: cfe/trunk/lib/CodeGen/CGObjCMac.cpp
===
--- cfe/trunk/lib/CodeGen/CGObjCMac.cpp
+++ cfe/trunk/lib/CodeGen/CGObjCMac.cpp
@@ -576,7 +576,6 @@
 return CGM.CreateRuntimeFunction(
   llvm::FunctionType::get(CGM.Int32Ty, params, false),
   "objc_exception_match");
-
   }
 
   /// SetJmpFn - LLVM _setjmp function.
@@ -600,7 +599,6 @@
 /// modern abi
 class ObjCNonFragileABITypesHelper : public ObjCCommonTypesHelper {
 public:
-
   // MethodListnfABITy - LLVM for struct _method_list_t
   llvm::StructType *MethodListnfABITy;
 
@@ -1509,12 +1507,15 @@
   llvm::Constant *GetSetStructFunction() override {
 return ObjCTypes.getCopyStructFn();
   }
+
   llvm::Constant *GetGetStructFunction() override {
 return ObjCTypes.getCopyStructFn();
   }
+
   llvm::Constant *GetCppAtomicObjectSetFunction() override {
 return ObjCTypes.getCppAtomicObjectFunction();
   }
+
   llvm::Constant *GetCppAtomicObjectGetFunction() override {
 return ObjCTypes.getCppAtomicObjectFunction();
   }
@@ -2030,6 +2031,7 @@
 bool IsDisordered = false;
 
 llvm::SmallVector IvarsInfo;
+
   public:
 IvarLayoutBuilder(CodeGenModule &CGM, CharUnits instanceBegin,
   CharUnits instanceEnd, bool forStrongLayout)
@@ -2065,7 +2067,7 @@
   printf("\n");
 }
   };
-}
+} // end anonymous namespace
 
 llvm::Constant *CGObjCCommonMac::BuildGCBlockLayout(CodeGenModule &CGM,
 const CGBlockInfo &blockInfo) {
@@ -2144,7 +2146,6 @@
   }
 }
 
-
 /// getBlockCaptureLifetime - This routine returns life time of the captured
 /// block variable for the purpose of block layout meta-data generation. FQT is
 /// the type of the variable captured in the block.
@@ -2632,7 +2633,6 @@
   return getBitmapBlockLayout(false);
 }
 
-
 llvm::Constant *CGObjCCommonMac::BuildByrefLayout(CodeGen::CodeGenModule &CGM,
   QualType T) {
   assert(CGM.getLangOpts().getGC() == LangOptions::NonGC);
@@ -3640,13 +3640,15 @@
 llvm::Constant *CGObjCMac::GetGetStructFunction() {
   return ObjCTypes.getCopyStructFn();
 }
+
 llvm::Constant *CGObjCMac::GetSetStructFunction() {
   return ObjCTypes.getCopyStructFn();
 }
 
 llvm::Constant *CGObjCMac::GetCppAtomicObjectGetFunction() {
   return ObjCTypes.getCppAtomicObjectFunction();
 }
+
 llvm::Constant *CGObjCMac::GetCppAtomicObjectSetFunction() {
   return ObjCTypes.getCppAtomicObjectFunction();
 }
@@ -3744,7 +3746,7 @@
 void emitWriteHazard();
 void emitHazardsInNewBlocks();
   };
-}
+} // end anonymous namespace
 
 /// Create the fragile-ABI read and write hazards based on the current
 /// state of the function, which is presumed to be immediately prior
@@ -4365,7 +4367,6 @@
   llvm::Value *args[] = { src, dst.getPointer() };
   CGF.EmitNounwindRuntimeCall(ObjCTypes.getGcAssignWeakFn(),
   args, "weakassign");
-  return;
 }
 
 /// EmitObjCGlobalAssign - Code gen for assigning to a __strong object.
@@ -4391,7 +4392,6 @@
   else
 CGF.EmitNounwindRuntimeCall(ObjCTypes.getGcAssignThreadLocalFn(),
 args, "threadlocalassign");
-  return;
 }
 
 /// EmitObjCIvarAssign - Code gen for assigning to a __strong object.
@@ -4413,7 +4413,6 @@
   dst = CGF.Builder.CreateBitCast(dst, ObjCTypes.PtrObjectPtrTy);
   llvm::Value *args[] = { src, dst.getPointer(), ivarOf

r260414 - Fix some Clang-tidy readability-redundant-control-flow warnings; other minor fixes.

[Eugene Zelenko via cfe-commits]

Author: eugenezelenko
Date: Wed Feb 10 13:11:58 2016
New Revision: 260414

URL: http://llvm.org/viewvc/llvm-project?rev=260414&view=rev
Log:
Fix some Clang-tidy readability-redundant-control-flow warnings; other minor 
fixes.

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

Modified:
cfe/trunk/include/clang/Analysis/Analyses/ThreadSafetyUtil.h
cfe/trunk/lib/ARCMigrate/ObjCMT.cpp
cfe/trunk/lib/AST/ASTDiagnostic.cpp
cfe/trunk/lib/AST/CommentLexer.cpp
cfe/trunk/lib/AST/CommentSema.cpp
cfe/trunk/lib/CodeGen/CGClass.cpp
cfe/trunk/lib/CodeGen/CGDecl.cpp
cfe/trunk/lib/CodeGen/CGObjCGNU.cpp
cfe/trunk/lib/CodeGen/CGObjCMac.cpp
cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
cfe/trunk/lib/Frontend/Rewrite/RewriteModernObjC.cpp
cfe/trunk/lib/Frontend/Rewrite/RewriteObjC.cpp
cfe/trunk/lib/StaticAnalyzer/Checkers/BasicObjCFoundationChecks.cpp
cfe/trunk/lib/StaticAnalyzer/Checkers/CheckerDocumentation.cpp
cfe/trunk/lib/StaticAnalyzer/Checkers/ChrootChecker.cpp
cfe/trunk/lib/StaticAnalyzer/Checkers/DynamicTypePropagation.cpp
cfe/trunk/lib/StaticAnalyzer/Checkers/IvarInvalidationChecker.cpp
cfe/trunk/lib/StaticAnalyzer/Checkers/ObjCContainersChecker.cpp
cfe/trunk/lib/StaticAnalyzer/Checkers/VLASizeChecker.cpp
cfe/trunk/lib/StaticAnalyzer/Core/ExprEngineCallAndReturn.cpp
cfe/trunk/lib/StaticAnalyzer/Core/MemRegion.cpp
cfe/trunk/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
cfe/trunk/tools/libclang/CXSourceLocation.cpp

Modified: cfe/trunk/include/clang/Analysis/Analyses/ThreadSafetyUtil.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Analysis/Analyses/ThreadSafetyUtil.h?rev=260414&r1=260413&r2=260414&view=diff
==
--- cfe/trunk/include/clang/Analysis/Analyses/ThreadSafetyUtil.h (original)
+++ cfe/trunk/include/clang/Analysis/Analyses/ThreadSafetyUtil.h Wed Feb 10 
13:11:58 2016
@@ -58,18 +58,15 @@ private:
   llvm::BumpPtrAllocator *Allocator;
 };
 
-
 } // end namespace til
 } // end namespace threadSafety
 } // end namespace clang
 
-
 inline void *operator new(size_t Sz,
   clang::threadSafety::til::MemRegionRef &R) {
   return R.allocate(Sz);
 }
 
-
 namespace clang {
 namespace threadSafety {
 
@@ -80,7 +77,6 @@ using clang::SourceLocation;
 
 namespace til {
 
-
 // A simple fixed size array class that does not manage its own memory,
 // suitable for use with bump pointer allocation.
 template  class SimpleArray {
@@ -117,7 +113,6 @@ public:
 Data = A.allocateT(Ncp);
 Capacity = Ncp;
 memcpy(Data, Odata, sizeof(T) * Size);
-return;
   }
 
   // Reserve space for at least N more items.
@@ -221,10 +216,8 @@ private:
   size_t Capacity;
 };
 
-
 }  // end namespace til
 
-
 // A copy on write vector.
 // The vector can be in one of three states:
 // * invalid -- no operations are permitted.
@@ -346,13 +339,11 @@ private:
   VectorData *Data;
 };
 
-
 inline std::ostream& operator<<(std::ostream& ss, const StringRef str) {
   return ss.write(str.data(), str.size());
 }
 
-
 } // end namespace threadSafety
 } // end namespace clang
 
-#endif  // LLVM_CLANG_THREAD_SAFETY_UTIL_H
+#endif // LLVM_CLANG_THREAD_SAFETY_UTIL_H

Modified: cfe/trunk/lib/ARCMigrate/ObjCMT.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/ARCMigrate/ObjCMT.cpp?rev=260414&r1=260413&r2=260414&view=diff
==
--- cfe/trunk/lib/ARCMigrate/ObjCMT.cpp (original)
+++ cfe/trunk/lib/ARCMigrate/ObjCMT.cpp Wed Feb 10 13:11:58 2016
@@ -177,7 +177,7 @@ protected:
   }
 };
 
-}
+} // end anonymous namespace
 
 ObjCMigrateAction::ObjCMigrateAction(
   std::unique_ptr 
WrappedAction,
@@ -307,7 +307,6 @@ namespace {
 }
 return true;
   }
-  
 
 class ObjCMigrator : public RecursiveASTVisitor {
   ObjCMigrateASTConsumer &Consumer;
@@ -370,7 +369,7 @@ public:
 return true;
   }
 };
-}
+} // end anonymous namespace
 
 void ObjCMigrateASTConsumer::migrateDecl(Decl *D) {
   if (!D)
@@ -1106,7 +1105,6 @@ static bool AvailabilityAttrsMatch(Attr
   versionsMatch(Deprecated1, Deprecated2) &&
   versionsMatch(Obsoleted1, Obsoleted2) &&
   IsUnavailable1 == IsUnavailable2);
-  
 }
 
 static bool MatchTwoAttributeLists(const AttrVec &Attrs1, const AttrVec 
&Attrs2,
@@ -1511,7 +1509,6 @@ void ObjCMigrateASTConsumer::AddCFAnnota
   }
 }
 
-
 ObjCMigrateASTConsumer::CF_BRIDGING_KIND
   ObjCMigrateASTConsumer::migrateAddFunctionAnnotation(
   ASTContext &Ctx,
@@ -1685,7 +1682,6 @@ void ObjCMigrateASTConsumer::migrateAddM
   return;
 }
   }
-  return;
 }
 
 namespace {
@@ -1702,7 +1698,7 @@ public:
 return true;
   }
 };
-} // anonymous namespace
+} // end anonymous namespace
 
 static bool hasSuperInitCall(const ObjCMethodDecl *MD) {
   return !SuperInitC

Re: [PATCH] D15040: [ARM] Add command-line options for ARMv8.2-A

[Tim Northover via cfe-commits]

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

Looks reasonable to me now.

Tim.


http://reviews.llvm.org/D15040



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

r260411 - Silence some MSVC false positive warnings about integer zexts and falling off the end of a covered switch

[Reid Kleckner via cfe-commits]

Author: rnk
Date: Wed Feb 10 13:09:15 2016
New Revision: 260411

URL: http://llvm.org/viewvc/llvm-project?rev=260411&view=rev
Log:
Silence some MSVC false positive warnings about integer zexts and falling off 
the end of a covered switch

Modified:
cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp
cfe/trunk/lib/Sema/CodeCompleteConsumer.cpp
cfe/trunk/lib/Tooling/Core/QualTypeNames.cpp

Modified: cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp?rev=260411&r1=260410&r2=260411&view=diff
==
--- cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp (original)
+++ cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp Wed Feb 10 13:09:15 2016
@@ -2311,7 +2311,7 @@ struct ResetGuardBit final : EHScopeStac
 CGBuilderTy &Builder = CGF.Builder;
 llvm::LoadInst *LI = Builder.CreateLoad(Guard);
 llvm::ConstantInt *Mask =
-llvm::ConstantInt::get(CGF.IntTy, ~(1U << GuardNum));
+llvm::ConstantInt::get(CGF.IntTy, ~(1ULL << GuardNum));
 Builder.CreateStore(Builder.CreateAnd(LI, Mask), Guard);
   }
 };

Modified: cfe/trunk/lib/Sema/CodeCompleteConsumer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/CodeCompleteConsumer.cpp?rev=260411&r1=260410&r2=260411&view=diff
==
--- cfe/trunk/lib/Sema/CodeCompleteConsumer.cpp (original)
+++ cfe/trunk/lib/Sema/CodeCompleteConsumer.cpp Wed Feb 10 13:09:15 2016
@@ -309,7 +309,7 @@ StringRef CodeCompletionTUInfo::getParen
 if (!Interface) {
   // Assign an empty StringRef but with non-null data to distinguish
   // between empty because we didn't process the DeclContext yet.
-  CachedParentName = StringRef((const char *)~0U, 0);
+  CachedParentName = StringRef((const char *)(uintptr_t)~0U, 0);
   return StringRef();
 }
 

Modified: cfe/trunk/lib/Tooling/Core/QualTypeNames.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Tooling/Core/QualTypeNames.cpp?rev=260411&r1=260410&r2=260411&view=diff
==
--- cfe/trunk/lib/Tooling/Core/QualTypeNames.cpp (original)
+++ cfe/trunk/lib/Tooling/Core/QualTypeNames.cpp Wed Feb 10 13:09:15 2016
@@ -243,6 +243,7 @@ static NestedNameSpecifier *getFullyQual
   return Scope;
 }
   }
+  llvm_unreachable("bad NNS kind");
 }
 
 /// \brief Create a nested name specifier for the declaring context of


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

Re: [PATCH] D17060: [Clang] Fix Clang-tidy readability-redundant-control-flow warnings; other minor fixes

[Hans Wennborg via cfe-commits]

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

Looks good to me.


Repository:
  rL LLVM

http://reviews.llvm.org/D17060



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

Re: [libcxx] r260337 - Fix overload sets of strchr, strpbrk, strrchr, memchr and strstr from

[Tim Northover via cfe-commits]

Hi Richard,

On 9 February 2016 at 16:59, Richard Smith via cfe-commits
 wrote:
> Fix overload sets of strchr, strpbrk, strrchr, memchr and strstr from
>  and wcschr, wcspbrk, wcsrchr, wmemchr, and wcsstr from  to
> provide a const-correct overload set even when the underlying C library does
> not.

This seems to have caused breakage on one of compiler-rt's tests on
Darwin: lib/asan/test/asan_str_test.cc if I'm reading the runes
correctly. See 
http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA_check/10117/
for example.

I'm not quite sure what's going on, but it seems to involve enable_if
disabling some overload checks, leading to an inconsistent set of
possible functions. That's probably an independent bug in clang
(there's certainly no mangling to support it in Itanium), but I
suspect libc++ shouldn't be trying to produce such combinations
anyway.

The smallest test case with the essential Clang details I've found is:

char *foo(const char *);
char *foo(char *);
__attribute__ ((__enable_if__(true, ""))) const char *foo(const char *);

void test(char *(*)(const char *));
void test(char *(*)(char *));

void func(char *in) {
  test(&foo);
}

Do you have any ideas on what to do, because I'm a bit stuck I'm
afraid. I can give you preprocessed source if you're struggling to
reproduce the issue (it's 2.4MB for the default 7ish for
-frewrite-includes).

Cheers.

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

[Andrey Bokhanko via cfe-commits]

andreybokhanko updated this revision to Diff 47475.
andreybokhanko added a comment.

John, thanks for the re-review! -- I did as you advised, and added *a lot* of 
switches. :-)

Patch updated; please re-review again.


http://reviews.llvm.org/D16846

Files:
  lib/AST/ExprConstant.cpp
  test/Sema/builtin-classify-type.c
  test/SemaCXX/builtin-classify-type.cpp

Index: lib/AST/ExprConstant.cpp
===
--- lib/AST/ExprConstant.cpp
+++ lib/AST/ExprConstant.cpp
@@ -6185,7 +6185,8 @@
 
 /// EvaluateBuiltinClassifyType - Evaluate __builtin_classify_type the same way
 /// as GCC.
-static int EvaluateBuiltinClassifyType(const CallExpr *E) {
+static int EvaluateBuiltinClassifyType(const CallExpr *E,
+   const LangOptions &LangOpts) {
   // The following enum mimics the values returned by GCC.
   // FIXME: Does GCC differ between lvalue and rvalue references here?
   enum gcc_type_class {
@@ -6205,37 +6206,130 @@
   if (E->getNumArgs() == 0)
 return no_type_class;
 
-  QualType ArgTy = E->getArg(0)->getType();
-  if (ArgTy->isVoidType())
-return void_type_class;
-  else if (ArgTy->isEnumeralType())
-return enumeral_type_class;
-  else if (ArgTy->isBooleanType())
-return boolean_type_class;
-  else if (ArgTy->isCharType())
-return string_type_class; // gcc doesn't appear to use char_type_class
-  else if (ArgTy->isIntegerType())
-return integer_type_class;
-  else if (ArgTy->isPointerType())
+  QualType CanTy = E->getArg(0)->getType().getCanonicalType();
+  const BuiltinType *BT = dyn_cast(CanTy);
+
+  switch (CanTy->getTypeClass()) {
+#define TYPE(ID, BASE)
+#define DEPENDENT_TYPE(ID, BASE) case Type::ID:
+#define NON_CANONICAL_TYPE(ID, BASE) case Type::ID:
+#define NON_CANONICAL_UNLESS_DEPENDENT_TYPE(ID, BASE) case Type::ID:
+#include "clang/AST/TypeNodes.def"
+  break;
+
+  case Type::Builtin:
+switch (BT->getKind()) {
+#define BUILTIN_TYPE(ID, SINGLETON_ID)
+#define SIGNED_TYPE(ID, SINGLETON_ID) case BuiltinType::ID: return integer_type_class;
+#define FLOATING_TYPE(ID, SINGLETON_ID) case BuiltinType::ID: return real_type_class;
+#define PLACEHOLDER_TYPE(ID, SINGLETON_ID) case BuiltinType::ID: break;
+#include "clang/AST/BuiltinTypes.def"
+case BuiltinType::Void:
+  return void_type_class;
+
+case BuiltinType::Bool:
+  return boolean_type_class;
+
+case BuiltinType::Char_U: // gcc doesn't appear to use char_type_class
+case BuiltinType::UChar:
+case BuiltinType::UShort:
+case BuiltinType::UInt:
+case BuiltinType::ULong:
+case BuiltinType::ULongLong:
+case BuiltinType::UInt128:
+  return integer_type_class;
+
+case BuiltinType::NullPtr:
+  return pointer_type_class;
+
+case BuiltinType::WChar_U:
+case BuiltinType::Char16:
+case BuiltinType::Char32:
+case BuiltinType::ObjCId:
+case BuiltinType::ObjCClass:
+case BuiltinType::ObjCSel:
+case BuiltinType::OCLImage1d:
+case BuiltinType::OCLImage1dArray:
+case BuiltinType::OCLImage2d:
+case BuiltinType::OCLImage2dArray:
+case BuiltinType::OCLImage1dBuffer:
+case BuiltinType::OCLImage2dDepth:
+case BuiltinType::OCLImage2dArrayDepth:
+case BuiltinType::OCLImage2dMSAA:
+case BuiltinType::OCLImage2dArrayMSAA:
+case BuiltinType::OCLImage2dMSAADepth:
+case BuiltinType::OCLImage2dArrayMSAADepth:
+case BuiltinType::OCLImage3d:
+case BuiltinType::OCLSampler:
+case BuiltinType::OCLEvent:
+case BuiltinType::OCLClkEvent:
+case BuiltinType::OCLQueue:
+case BuiltinType::OCLNDRange:
+case BuiltinType::OCLReserveID:
+case BuiltinType::Dependent:
+  llvm_unreachable("CallExpr::isBuiltinClassifyType(): unimplemented type");
+};
+
+  case Type::Enum:
+return LangOpts.CPlusPlus ? enumeral_type_class : integer_type_class;
+break;
+
+  case Type::Pointer:
 return pointer_type_class;
-  else if (ArgTy->isReferenceType())
-return reference_type_class;
-  else if (ArgTy->isRealType())
-return real_type_class;
-  else if (ArgTy->isComplexType())
+break;
+
+  case Type::MemberPointer:
+if (CanTy->isMemberDataPointerType())
+  return offset_type_class;
+else {
+  assert(CanTy->isMemberFunctionPointerType());
+  return method_type_class;
+}
+
+  case Type::Complex:
 return complex_type_class;
-  else if (ArgTy->isFunctionType())
-return function_type_class;
-  else if (ArgTy->isStructureOrClassType())
-return record_type_class;
-  else if (ArgTy->isUnionType())
-return union_type_class;
-  else if (ArgTy->isArrayType())
-return array_type_class;
-  else if (ArgTy->isUnionType())
-return union_type_class;
-  else  // FIXME: offset_type_class, method_type_class, & lang_type_class?
+
+  case Type::FunctionNoProto:
+  case Type::FunctionProto:
+return LangOpts.CPlusPlus ? function_type_class : pointer_type_class;
+
+  case Type::Record:
+