Re: PATCH: Expose the 'file' that is associated with a compile database command

[Manuel Klimek via cfe-commits]

On Thu, Sep 10, 2015 at 8:36 PM Argyrios Kyrtzidis 
wrote:

> On Sep 10, 2015, at 1:48 AM, Manuel Klimek  wrote:
>
> @@ -179,11 +185,13 @@ public:
>/// \param Directory The base directory used in the
> FixedCompilationDatabase.
>static FixedCompilationDatabase *loadFromCommandLine(int &Argc,
> const char *const
> *Argv,
> -   Twine Directory =
> ".");
> +   Twine Directory =
> ".",
> +   Twine File =
> Twine());
>
> A fixed compilation database returns the same command lines for all files,
> thus having a file in the function seems strange.
>
>
> Ah ok, thanks for clarifying.
>
>
> What exactly is the use case? So far, the compilation database has been
> designed for 2 use cases:
> 1. for a file, get the compile commands; the user already knows the file,
> no need to get the file
> 2. get all compile commands; for that, we have the getAllFiles() method,
> so a user can get all known files (for compilation databases that support
> that), and then get the compile command line.
>
>
> It’s #2, I want to get all compile commands. But it seems really strange
> to me that the ‘file’ starts as a property of the compile command in the
> json file but then it gets dropped and I need to do work to re-associate
> the files with the compile commands again.
>

The JSON file format is one possible implementation for the
compilation-database interface. The FixedCompilationDatabase is another
one, that doesn't have any information on files.


> I need to get a list of all the files and then for each one do a lookup to
> get the associated commands. I then have to maintain this association
> myself, passing a command along with its file separately or the structure
> that keeps track of the association.
>
> It seems simpler to me to include the file that was associated with the
> command (if the compilation database supports that) along with the command,
> is there a downside I’m missing ?
>

Well, to me, it's a design question - if it also makes sense to have a
CompileCommand without a file associated with it, putting the file in
there, while convenient, is a design smell.
That said, I'm happy to be convinced that I'm wrong :) I guess I don't see
yet that keeping track of the files outside is more than one line of extra
code.

Cheers,
/Manuel


>
>
> Thoughts?
> /Manuel
>
> On Wed, Sep 9, 2015 at 9:36 PM Argyrios Kyrtzidis 
> wrote:
>
>> Hi,
>>
>> The attached patch exposes the ‘file’ entry in a compilation database
>> command, via the CompileCommand structure.
>>
>>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D12358: [Analyzer] Handling constant bound loops

[Sean Eveson via cfe-commits]

seaneveson added a comment.

In http://reviews.llvm.org/D12358#241631, @cfe-commits wrote:

> Hi Sean,
>
> Ted provided more details off-list. He suspects that the problem is that we 
> likely don't add MemSpaceRegions to the worklist because every region is a 
> subregion of a MemSpaceRegion, and thus we would invalidate, by default, all 
> regions that were in the same MemSpace as the regions we were invalidating.  
> He thinks we want to not change that behavior, but also provide a way of 
> invalidating an entire MemSpace if so desired.  That's probably just a slight 
> tweak to the algorithm.
>
> I’ll take a look at your updated patch to reproduce what you are seeing and 
> investigate to see if that is what is going on.
>
> Thanks,
> Devin


Hi Devin,

That sounds good, thanks for looking at this.  Can you let me know when you 
will be able to look at this?  I am doing some work that builds on this patch's 
functionality and having this patch accepted would help.

Thanks,
Sean


http://reviews.llvm.org/D12358



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

r247392 - Fix \param in r247251. [-Wdocumentation]

[NAKAMURA Takumi via cfe-commits]

Author: chapuni
Date: Fri Sep 11 03:13:32 2015
New Revision: 247392

URL: http://llvm.org/viewvc/llvm-project?rev=247392&view=rev
Log:
Fix \param in r247251. [-Wdocumentation]

Modified:
cfe/trunk/lib/CodeGen/CGOpenMPRuntime.h

Modified: cfe/trunk/lib/CodeGen/CGOpenMPRuntime.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGOpenMPRuntime.h?rev=247392&r1=247391&r2=247392&view=diff
==
--- cfe/trunk/lib/CodeGen/CGOpenMPRuntime.h (original)
+++ cfe/trunk/lib/CodeGen/CGOpenMPRuntime.h Fri Sep 11 03:13:32 2015
@@ -398,7 +398,7 @@ public:
   /// CapturedStruct.
   /// \param OutlinedFn Outlined function to be run in parallel threads. Type 
of
   /// this function is void(*)(kmp_int32 *, kmp_int32, struct context_vars*).
-  /// \param CapturedStruct A pointer to the record with the references to
+  /// \param CapturedVars A pointer to the record with the references to
   /// variables used in \a OutlinedFn function.
   /// \param IfCond Condition in the associated 'if' clause, if it was
   /// specified, nullptr otherwise.


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

[clang-tools-extra] r247394 - clang-tidy/misc-sizeof-container.cpp: Add explicit triple.

[NAKAMURA Takumi via cfe-commits]

Author: chapuni
Date: Fri Sep 11 03:16:30 2015
New Revision: 247394

URL: http://llvm.org/viewvc/llvm-project?rev=247394&view=rev
Log:
clang-tidy/misc-sizeof-container.cpp: Add explicit triple.

For targeting LLP64, like Windows x86, size_t is not unsigned long.

  
tools/clang/tools/extra/test/clang-tidy/Output/misc-sizeof-container.cpp.tmp.cpp:33:12:
 error: target of using declaration conflicts with declaration already in scope 
[clang-diagnostic-error]
  using std::size_t;
 ^

Modified:
clang-tools-extra/trunk/test/clang-tidy/misc-sizeof-container.cpp

Modified: clang-tools-extra/trunk/test/clang-tidy/misc-sizeof-container.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/misc-sizeof-container.cpp?rev=247394&r1=247393&r2=247394&view=diff
==
--- clang-tools-extra/trunk/test/clang-tidy/misc-sizeof-container.cpp (original)
+++ clang-tools-extra/trunk/test/clang-tidy/misc-sizeof-container.cpp Fri Sep 
11 03:16:30 2015
@@ -1,4 +1,4 @@
-// RUN: %python %S/check_clang_tidy.py %s misc-sizeof-container %t
+// RUN: %python %S/check_clang_tidy.py %s misc-sizeof-container %t -- 
-std=c++11 -target x86_64-unknown-unknown
 
 namespace std {
 


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

[clang-tools-extra] r247393 - clang-tidy/readability-inconsistent-declaration-parameter-name.cpp: Appease MS-incompatibility [-fno-delayed-template-parsing]

[NAKAMURA Takumi via cfe-commits]

Author: chapuni
Date: Fri Sep 11 03:16:22 2015
New Revision: 247393

URL: http://llvm.org/viewvc/llvm-project?rev=247393&view=rev
Log:
clang-tidy/readability-inconsistent-declaration-parameter-name.cpp: Appease 
MS-incompatibility [-fno-delayed-template-parsing]

Modified:

clang-tools-extra/trunk/test/clang-tidy/readability-inconsistent-declaration-parameter-name.cpp

Modified: 
clang-tools-extra/trunk/test/clang-tidy/readability-inconsistent-declaration-parameter-name.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/readability-inconsistent-declaration-parameter-name.cpp?rev=247393&r1=247392&r2=247393&view=diff
==
--- 
clang-tools-extra/trunk/test/clang-tidy/readability-inconsistent-declaration-parameter-name.cpp
 (original)
+++ 
clang-tools-extra/trunk/test/clang-tidy/readability-inconsistent-declaration-parameter-name.cpp
 Fri Sep 11 03:16:22 2015
@@ -1,4 +1,4 @@
-// RUN: %python %S/check_clang_tidy.py %s 
readability-inconsistent-declaration-parameter-name %t
+// RUN: %python %S/check_clang_tidy.py %s 
readability-inconsistent-declaration-parameter-name %t -- -std=c++11 
-fno-delayed-template-parsing
 
 void consistentFunction(int a, int b, int c);
 void consistentFunction(int a, int b, int c);


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

r247396 - clang/test/Modules/ExtDebugInfo.cpp: Use [[@LINE]].

[NAKAMURA Takumi via cfe-commits]

Author: chapuni
Date: Fri Sep 11 03:53:29 2015
New Revision: 247396

URL: http://llvm.org/viewvc/llvm-project?rev=247396&view=rev
Log:
clang/test/Modules/ExtDebugInfo.cpp: Use [[@LINE]].

Modified:
cfe/trunk/test/Modules/ExtDebugInfo.cpp

Modified: cfe/trunk/test/Modules/ExtDebugInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/ExtDebugInfo.cpp?rev=247396&r1=247395&r2=247396&view=diff
==
--- cfe/trunk/test/Modules/ExtDebugInfo.cpp (original)
+++ cfe/trunk/test/Modules/ExtDebugInfo.cpp Fri Sep 11 03:53:29 2015
@@ -71,4 +71,4 @@ char _anchor = anon_enum + conflicting_u
 
 // CHECK: !DIGlobalVariable(name: "anon_enum", {{.*}}, type: ![[ANON_ENUM]]
 
-// CHECK: !DIImportedEntity(tag: DW_TAG_imported_declaration, scope: !0, 
entity: !"_ZTSN8DebugCXX6StructE", line: 21)
+// CHECK: !DIImportedEntity(tag: DW_TAG_imported_declaration, scope: !0, 
entity: !"_ZTSN8DebugCXX6StructE", line: [[@LINE-53]])


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

r247397 - clang/test/Modules/ExtDebugInfo.cpp: Use %itanium_abi_triple.

[NAKAMURA Takumi via cfe-commits]

Author: chapuni
Date: Fri Sep 11 03:56:12 2015
New Revision: 247397

URL: http://llvm.org/viewvc/llvm-project?rev=247397&view=rev
Log:
clang/test/Modules/ExtDebugInfo.cpp: Use %itanium_abi_triple.

Modified:
cfe/trunk/test/Modules/ExtDebugInfo.cpp

Modified: cfe/trunk/test/Modules/ExtDebugInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/ExtDebugInfo.cpp?rev=247397&r1=247396&r2=247397&view=diff
==
--- cfe/trunk/test/Modules/ExtDebugInfo.cpp (original)
+++ cfe/trunk/test/Modules/ExtDebugInfo.cpp Fri Sep 11 03:56:12 2015
@@ -3,14 +3,17 @@
 
 // Modules:
 // RUN: %clang_cc1 -x objective-c++ -std=c++11 -g -dwarf-ext-refs -fmodules \
+// RUN: -triple %itanium_abi_triple \
 // RUN: -fmodule-format=obj -fimplicit-module-maps -DMODULES \
 // RUN: -fmodules-cache-path=%t %s -I %S/Inputs -I %t -emit-llvm -o 
%t-mod.ll
 // RUN: cat %t-mod.ll |  FileCheck %s
 
 // PCH:
 // RUN: %clang_cc1 -x c++ -std=c++11 -fmodule-format=obj -emit-pch -I%S/Inputs 
\
+// RUN: -triple %itanium_abi_triple \
 // RUN: -o %t.pch %S/Inputs/DebugCXX.h
 // RUN: %clang_cc1 -std=c++11 -g -dwarf-ext-refs -fmodule-format=obj \
+// RUN: -triple %itanium_abi_triple \
 // RUN: -include-pch %t.pch %s -emit-llvm -o %t-pch.ll %s
 // RUN: cat %t-pch.ll |  FileCheck %s
 


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

Re: [PATCH] D12734: Another patch for modernize-loop-convert.

[Manuel Klimek via cfe-commits]

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

In http://reviews.llvm.org/D12734#243157, @angelgarcia wrote:

> Comment the enumerators.
>
> > Do we need default?
>
>
> I think so. We need to set the cases that do not fall in any of these 
> categories to something, and I think that using one of the other three as the 
> default kind would be confusing. But maybe there is a better name than just 
> UK_Default. Any ideas?


Can we perhaps just add a couple of example of other cases that are not member 
expressions? With that, LG.


http://reviews.llvm.org/D12734



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

Re: [PATCH] D12734: Another patch for modernize-loop-convert.

[Angel Garcia via cfe-commits]

angelgarcia updated this revision to Diff 34535.
angelgarcia added a comment.

Add examples of 'default' usages.


http://reviews.llvm.org/D12734

Files:
  clang-tidy/modernize/LoopConvertCheck.cpp
  clang-tidy/modernize/LoopConvertCheck.h
  clang-tidy/modernize/LoopConvertUtils.cpp
  clang-tidy/modernize/LoopConvertUtils.h
  test/clang-tidy/Inputs/modernize-loop-convert/structures.h
  test/clang-tidy/modernize-loop-convert-basic.cpp
  test/clang-tidy/modernize-loop-convert-extra.cpp
  test/clang-tidy/modernize-loop-convert-negative.cpp

Index: test/clang-tidy/modernize-loop-convert-negative.cpp
===
--- test/clang-tidy/modernize-loop-convert-negative.cpp
+++ test/clang-tidy/modernize-loop-convert-negative.cpp
@@ -290,7 +290,6 @@
 dependent v;
 dependent *pv;
 
-transparent> cv;
 int Sum = 0;
 
 // Checks for the Index start and end:
@@ -473,3 +472,41 @@
 }
 
 } // namespace NegativeMultiEndCall
+
+namespace NoUsages {
+
+const int N = 6;
+int arr[N] = {1, 2, 3, 4, 5, 6};
+S s;
+dependent v;
+int Count = 0;
+
+void foo();
+
+void f() {
+  for (int I = 0; I < N; ++I) {}
+  for (int I = 0; I < N; ++I)
+printf("Hello world\n");
+  for (int I = 0; I < N; ++I)
+++Count;
+  for (int I = 0; I < N; ++I)
+foo();
+
+  for (S::iterator I = s.begin(), E = s.end(); I != E; ++I) {}
+  for (S::iterator I = s.begin(), E = s.end(); I != E; ++I)
+printf("Hello world\n");
+  for (S::iterator I = s.begin(), E = s.end(); I != E; ++I)
+++Count;
+  for (S::iterator I = s.begin(), E = s.end(); I != E; ++I)
+foo();
+
+  for (int I = 0; I < v.size(); ++I) {}
+  for (int I = 0; I < v.size(); ++I)
+printf("Hello world\n");
+  for (int I = 0; I < v.size(); ++I)
+++Count;
+  for (int I = 0; I < v.size(); ++I)
+foo();
+}
+
+} // namespace NoUsages
Index: test/clang-tidy/modernize-loop-convert-extra.cpp
===
--- test/clang-tidy/modernize-loop-convert-extra.cpp
+++ test/clang-tidy/modernize-loop-convert-extra.cpp
@@ -14,10 +14,9 @@
 int b = arr[i][a];
   }
   // CHECK-MESSAGES: :[[@LINE-4]]:3: warning: use range-based for loop instead
-  // CHECK-FIXES: for (auto & elem : arr) {
+  // CHECK-FIXES: for (auto & elem : arr)
   // CHECK-FIXES-NEXT: int a = 0;
   // CHECK-FIXES-NEXT: int b = elem[a];
-  // CHECK-FIXES-NEXT: }
 
   for (int j = 0; j < M; ++j) {
 int a = 0;
@@ -121,16 +120,16 @@
   }
   // CHECK-MESSAGES: :[[@LINE-5]]:3: warning: use range-based for loop instead
   // CHECK-FIXES: for (auto alias : IntArr)
-  // CHECK-FIXES-NEXT: if (alias) {
+  // CHECK-FIXES-NEXT: if (alias)
 
   for (unsigned i = 0; i < N; ++i) {
 while (int alias = IntArr[i]) {
   sideEffect(alias);
 }
   }
   // CHECK-MESSAGES: :[[@LINE-5]]:3: warning: use range-based for loop instead
   // CHECK-FIXES: for (auto alias : IntArr)
-  // CHECK-FIXES-NEXT: while (alias) {
+  // CHECK-FIXES-NEXT: while (alias)
 
   for (unsigned i = 0; i < N; ++i) {
 switch (int alias = IntArr[i]) {
@@ -140,32 +139,32 @@
   }
   // CHECK-MESSAGES: :[[@LINE-6]]:3: warning: use range-based for loop instead
   // CHECK-FIXES: for (auto alias : IntArr)
-  // CHECK-FIXES-NEXT: switch (alias) {
+  // CHECK-FIXES-NEXT: switch (alias)
 
   for (unsigned i = 0; i < N; ++i) {
 for (int alias = IntArr[i]; alias < N; ++alias) {
   sideEffect(alias);
 }
   }
   // CHECK-MESSAGES: :[[@LINE-5]]:3: warning: use range-based for loop instead
   // CHECK-FIXES: for (auto alias : IntArr)
-  // CHECK-FIXES-NEXT: for (; alias < N; ++alias) {
+  // CHECK-FIXES-NEXT: for (; alias < N; ++alias)
 
   for (unsigned i = 0; i < N; ++i) {
 for (unsigned j = 0; int alias = IntArr[i]; ++j) {
   sideEffect(alias);
 }
   }
   // CHECK-MESSAGES: :[[@LINE-5]]:3: warning: use range-based for loop instead
   // CHECK-FIXES: for (auto alias : IntArr)
-  // CHECK-FIXES-NEXT: for (unsigned j = 0; alias; ++j) {
+  // CHECK-FIXES-NEXT: for (unsigned j = 0; alias; ++j)
 
   struct IntRef { IntRef(const int& i); };
   for (int i = 0; i < N; ++i) {
 IntRef Int(IntArr[i]);
   }
   // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: use range-based for loop instead
-  // CHECK-FIXES: for (auto & elem : IntArr) {
+  // CHECK-FIXES: for (auto & elem : IntArr)
   // CHECK-FIXES-NEXT: IntRef Int(elem);
 }
 
@@ -288,7 +287,7 @@
   }
   // CHECK-MESSAGES: :[[@LINE-5]]:3: warning: use range-based for loop instead
   // CHECK-FIXES: for (auto & DEFs_it : DEFs)
-  // CHECK-FIXES-NEXT: if (DEFs_it == DEF) {
+  // CHECK-FIXES-NEXT: if (DEFs_it == DEF)
   // CHECK-FIXES-NEXT: printf("I found %d\n", DEFs_it);
 }
 
@@ -315,8 +314,8 @@
   T Vals;
   // Using the name "Val", although it is the name of an existing struct, is
   // safe in this loop since it will only exist within this scope.
-  for (T::iterator it = Vals.begin(), e = Vals.end(); it != e; ++it) {
-  }
+  for (T::iterator it = Vals.begin(), e = Vals.end(); it != e; ++it)
+   

[clang-tools-extra] r247399 - Another patch for modernize-loop-convert.

[Angel Garcia Gomez via cfe-commits]

Author: angelgarcia
Date: Fri Sep 11 05:02:07 2015
New Revision: 247399

URL: http://llvm.org/viewvc/llvm-project?rev=247399&view=rev
Log:
Another patch for modernize-loop-convert.

Summary:
1. Avoid converting loops that iterate over the size of a container and don't 
use its elements, as this would result in an unused-result warning.
2. Never capture the elements by value on lambdas, thus avoiding doing 
unnecessary copies and errors with non-copyable types.
3. The 'const auto &' instead of 'auto &' substitution on const containers now 
works on arrays and pseudoarrays as well.
4. The error about multiple replacements in the same macro call is now 
documented in the tests (not solved though).
5. Due to [1], I had to add a dummy usage of the range element (like "(void) 
*It;" or similars) on the tests that had empty loops.
6. I removed the braces from the CHECK comments. I think that there is no need 
for them, and they confuse vim.

Reviewers: klimek

Subscribers: alexfh, cfe-commits

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

Modified:
clang-tools-extra/trunk/clang-tidy/modernize/LoopConvertCheck.cpp
clang-tools-extra/trunk/clang-tidy/modernize/LoopConvertCheck.h
clang-tools-extra/trunk/clang-tidy/modernize/LoopConvertUtils.cpp
clang-tools-extra/trunk/clang-tidy/modernize/LoopConvertUtils.h

clang-tools-extra/trunk/test/clang-tidy/Inputs/modernize-loop-convert/structures.h
clang-tools-extra/trunk/test/clang-tidy/modernize-loop-convert-basic.cpp
clang-tools-extra/trunk/test/clang-tidy/modernize-loop-convert-extra.cpp
clang-tools-extra/trunk/test/clang-tidy/modernize-loop-convert-negative.cpp

Modified: clang-tools-extra/trunk/clang-tidy/modernize/LoopConvertCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/modernize/LoopConvertCheck.cpp?rev=247399&r1=247398&r2=247399&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/modernize/LoopConvertCheck.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/modernize/LoopConvertCheck.cpp Fri Sep 
11 05:02:07 2015
@@ -381,6 +381,20 @@ static bool usagesReturnRValues(const Us
   return true;
 }
 
+/// \brief Returns true if the container is const-qualified.
+static bool containerIsConst(const Expr *ContainerExpr, bool Dereference) {
+  if (const auto *VDec = getReferencedVariable(ContainerExpr)) {
+QualType CType = VDec->getType();
+if (Dereference) {
+  if (!CType->isPointerType())
+return false;
+  CType = CType->getPointeeType();
+}
+return CType.isConstQualified();
+  }
+  return false;
+}
+
 LoopConvertCheck::LoopConvertCheck(StringRef Name, ClangTidyContext *Context)
 : ClangTidyCheck(Name, Context), TUInfo(new TUTrackingInfo),
   MinConfidence(StringSwitch(
@@ -401,6 +415,11 @@ void LoopConvertCheck::doConversion(
 StringRef ContainerString, const UsageResult &Usages,
 const DeclStmt *AliasDecl, bool AliasUseRequired, bool AliasFromForInit,
 const ForStmt *TheLoop, RangeDescriptor Descriptor) {
+  // If there aren't any usages, converting the loop would generate an unused
+  // variable warning.
+  if (Usages.size() == 0)
+return;
+
   auto Diag = diag(TheLoop->getForLoc(), "use range-based for loop instead");
 
   std::string VarName;
@@ -436,11 +455,23 @@ void LoopConvertCheck::doConversion(
 VarName = Namer.createIndexName();
 // First, replace all usages of the array subscript expression with our new
 // variable.
-for (const auto &I : Usages) {
-  std::string ReplaceText = I.IsArrow ? VarName + "." : VarName;
+for (const auto &Usage : Usages) {
+  std::string ReplaceText;
+  if (Usage.Expression) {
+// If this is an access to a member through the arrow operator, after
+// the replacement it must be accessed through the '.' operator.
+ReplaceText = Usage.Kind == Usage::UK_MemberThroughArrow ? VarName + 
"."
+ : VarName;
+  } else {
+// The Usage expression is only null in case of lambda captures (which
+// are VarDecl). If the index is captured by value, add '&' to capture
+// by reference instead.
+ReplaceText =
+Usage.Kind == Usage::UK_CaptureByCopy ? "&" + VarName : VarName;
+  }
   TUInfo->getReplacedVars().insert(std::make_pair(TheLoop, IndexVar));
   Diag << FixItHint::CreateReplacement(
-  CharSourceRange::getTokenRange(I.Range), ReplaceText);
+  CharSourceRange::getTokenRange(Usage.Range), ReplaceText);
 }
   }
 
@@ -537,16 +568,24 @@ void LoopConvertCheck::findAndVerifyUsag
   if (FixerKind == LFK_Array) {
 // The array being indexed by IndexVar was discovered during traversal.
 ContainerExpr = Finder.getContainerIndexed()->IgnoreParenImpCasts();
+
 // Very few loops are over expressions that generate arrays rather than
 // a

Re: [PATCH] D10599: [OPENMP 4.0] Initial support for '#pragma omp declare simd' directive.

[Alexey Bataev via cfe-commits]

ABataev added a comment.

Richard, any comments about latest version?


http://reviews.llvm.org/D10599



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

Re: [PATCH] D11182: [OPENMP 4.0] Initial support for 'omp declare reduction' construct.

[Alexey Bataev via cfe-commits]

ABataev added a comment.

Richard?


http://reviews.llvm.org/D11182



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

r247401 - [OPENMP] Preserve alignment of the original variables for the captured references.

[Alexey Bataev via cfe-commits]

Author: abataev
Date: Fri Sep 11 05:29:41 2015
New Revision: 247401

URL: http://llvm.org/viewvc/llvm-project?rev=247401&view=rev
Log:
[OPENMP] Preserve alignment of the original variables for the captured 
references.
Patch makes codegen to preserve alignment of the shared variables captured and 
used in OpenMP regions.

Modified:
cfe/trunk/lib/CodeGen/CGExpr.cpp
cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp
cfe/trunk/test/OpenMP/parallel_firstprivate_codegen.cpp
cfe/trunk/test/OpenMP/task_codegen.cpp
cfe/trunk/test/OpenMP/task_firstprivate_codegen.cpp
cfe/trunk/test/OpenMP/task_private_codegen.cpp

Modified: cfe/trunk/lib/CodeGen/CGExpr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGExpr.cpp?rev=247401&r1=247400&r2=247401&view=diff
==
--- cfe/trunk/lib/CodeGen/CGExpr.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGExpr.cpp Fri Sep 11 05:29:41 2015
@@ -2061,8 +2061,12 @@ LValue CodeGenFunction::EmitDeclRefLValu
   }
   return MakeAddrLValue(it->second, T);
 }
-return EmitCapturedFieldLValue(*this, CapturedStmtInfo->lookup(VD),
-   CapturedStmtInfo->getContextValue());
+LValue CapLVal =
+EmitCapturedFieldLValue(*this, CapturedStmtInfo->lookup(VD),
+CapturedStmtInfo->getContextValue());
+return MakeAddrLValue(
+Address(CapLVal.getPointer(), getContext().getDeclAlign(VD)),
+CapLVal.getType(), AlignmentSource::Decl);
   }
 
   assert(isa(CurCodeDecl));

Modified: cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp?rev=247401&r1=247400&r2=247401&view=diff
==
--- cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp Fri Sep 11 05:29:41 2015
@@ -1848,14 +1848,15 @@ void CGOpenMPRuntime::emitKmpRoutineEntr
   }
 }
 
-static void addFieldToRecordDecl(ASTContext &C, DeclContext *DC,
- QualType FieldTy) {
+static FieldDecl *addFieldToRecordDecl(ASTContext &C, DeclContext *DC,
+   QualType FieldTy) {
   auto *Field = FieldDecl::Create(
   C, DC, SourceLocation(), SourceLocation(), /*Id=*/nullptr, FieldTy,
   C.getTrivialTypeSourceInfo(FieldTy, SourceLocation()),
   /*BW=*/nullptr, /*Mutable=*/false, /*InitStyle=*/ICIS_NoInit);
   Field->setAccess(AS_public);
   DC->addDecl(Field);
+  return Field;
 }
 
 namespace {
@@ -1882,9 +1883,16 @@ createPrivatesRecordDecl(CodeGenModule &
 auto *RD = C.buildImplicitRecord(".kmp_privates.t");
 RD->startDefinition();
 for (auto &&Pair : Privates) {
-  auto Type = Pair.second.Original->getType();
+  auto *VD = Pair.second.Original;
+  auto Type = VD->getType();
   Type = Type.getNonReferenceType();
-  addFieldToRecordDecl(C, RD, Type);
+  auto *FD = addFieldToRecordDecl(C, RD, Type);
+  if (VD->hasAttrs()) {
+for (specific_attr_iterator I(VD->getAttrs().begin()),
+ E(VD->getAttrs().end());
+ I != E; ++I)
+  FD->addAttr(*I);
+  }
 }
 RD->completeDefinition();
 return RD;
@@ -2173,7 +2181,7 @@ void CGOpenMPRuntime::emitTaskCall(
   for (auto *E : PrivateVars) {
 auto *VD = cast(cast(E)->getDecl());
 Privates.push_back(std::make_pair(
-C.getTypeAlignInChars(VD->getType()),
+C.getDeclAlign(VD),
 PrivateHelpersTy(VD, cast(cast(*I)->getDecl()),
  /*PrivateElemInit=*/nullptr)));
 ++I;
@@ -2183,7 +2191,7 @@ void CGOpenMPRuntime::emitTaskCall(
   for (auto *E : FirstprivateVars) {
 auto *VD = cast(cast(E)->getDecl());
 Privates.push_back(std::make_pair(
-C.getTypeAlignInChars(VD->getType()),
+C.getDeclAlign(VD),
 PrivateHelpersTy(
 VD, cast(cast(*I)->getDecl()),
 cast(cast(*IElemInitRef)->getDecl();
@@ -2302,6 +2310,9 @@ void CGOpenMPRuntime::emitTaskCall(
   auto *SharedField = CapturesInfo.lookup(OriginalVD);
   auto SharedRefLValue =
   CGF.EmitLValueForField(SharedsBase, SharedField);
+  SharedRefLValue = CGF.MakeAddrLValue(
+  Address(SharedRefLValue.getPointer(), 
C.getDeclAlign(OriginalVD)),
+  SharedRefLValue.getType(), AlignmentSource::Decl);
   QualType Type = OriginalVD->getType();
   if (Type->isArrayType()) {
 // Initialize firstprivate array.

Modified: cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp?rev=247401&r1=247400&r2=247401&view=diff
==
--- 

Re: [PATCH] D12689: [libc++][static linking] std streams are not initialized prior to their use in static object constructors

[Evgeny Astigeevich via cfe-commits]

eastig added a comment.

In http://reviews.llvm.org/D12689#243592, @rsmith wrote:

> Can we instead fix this in Clang by ensuring that libc++ is put at the right 
> position in the static link order so that its initializers run first? 
> libc++'s avoidance of running iostreams init code from every translation unit 
> is a significant startup performance feature, and we shouldn't abandon it 
> unless we really have to.


Let me give more details about the problem we have.

Clang generates a `__cxx_global_var_init` function for each global variable 
that needs to be set-up (initialized) before firing the main routine of the 
user program. Those initializer functions are then grouped under a parent 
initializer function named after the corresponding translation unit: 
`_GLOBAL__sub_I_`.  Those `_GLOBAL__sub_I_` 
entries then get stuffed into the `.init_array` tables of individual object 
files.

In ARM compiler toolchains `armlink` is used for linking, not `GNU ld`. 
`libc++` is a part of the toolchain static system libraries. So `armlink` logic 
should be updated to change the order in which the `.init_array` entries from 
system libraries are added to the final image's `.init_array` table. This can 
be a problem because of an assumption that there are no dependencies among 
initializers from different translation units.

IMHO if the programming language has a means of resolving such problems it's 
better to use it instead of hacking a linker.

About impact on startup performance, I don't see why it will be significant. 
Initialization is done once. Other times it is simply a call to increase a 
counter. To be significant there should be millions of calls. Why does `gnu 
libc++` use a similar way if it hurts performance?

In the patch the `__APPLE__` macro is used to have the old behaviour. Maybe 
instead of it another macro, e.g. `__STATIC_BUILD__`, can be use when we want 
to build a static library.


http://reviews.llvm.org/D12689



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

[PATCH] D12797: Refactor LoopConvertCheck.

[Angel Garcia via cfe-commits]

angelgarcia created this revision.
angelgarcia added a reviewer: klimek.
angelgarcia added subscribers: alexfh, cfe-commits.

Reorder the code in a more logical and understandable way.

http://reviews.llvm.org/D12797

Files:
  clang-tidy/modernize/LoopConvertCheck.cpp
  clang-tidy/modernize/LoopConvertCheck.h
  test/clang-tidy/modernize-loop-convert-basic.cpp

Index: test/clang-tidy/modernize-loop-convert-basic.cpp
===
--- test/clang-tidy/modernize-loop-convert-basic.cpp
+++ test/clang-tidy/modernize-loop-convert-basic.cpp
@@ -406,12 +406,12 @@
 for (const_iterator I = begin(), E = end(); I != E; ++I)
   (void) *I;
 // CHECK-MESSAGES: :[[@LINE-2]]:5: warning: use range-based for loop instead
-// CHECK-FIXES: for (auto & elem : *this)
+// CHECK-FIXES: for (const auto & elem : *this)
 
 for (const_iterator I = C::begin(), E = C::end(); I != E; ++I)
   (void) *I;
 // CHECK-MESSAGES: :[[@LINE-2]]:5: warning: use range-based for loop instead
-// CHECK-FIXES: for (auto & elem : *this)
+// CHECK-FIXES: for (const auto & elem : *this)
 
 for (const_iterator I = begin(), E = end(); I != E; ++I) {
   (void) *I;
Index: clang-tidy/modernize/LoopConvertCheck.h
===
--- clang-tidy/modernize/LoopConvertCheck.h
+++ clang-tidy/modernize/LoopConvertCheck.h
@@ -26,25 +26,32 @@
 
 private:
   struct RangeDescriptor {
+RangeDescriptor();
 bool ContainerNeedsDereference;
 bool DerefByConstRef;
 bool DerefByValue;
 bool IsTriviallyCopyable;
+StringRef ContainerString;
   };
 
   void doConversion(ASTContext *Context, const VarDecl *IndexVar,
-const VarDecl *MaybeContainer, StringRef ContainerString,
-const UsageResult &Usages, const DeclStmt *AliasDecl,
-bool AliasUseRequired, bool AliasFromForInit,
-const ForStmt *TheLoop, RangeDescriptor Descriptor);
-
-  StringRef checkRejections(ASTContext *Context, const Expr *ContainerExpr,
-const ForStmt *TheLoop);
-
-  void findAndVerifyUsages(ASTContext *Context, const VarDecl *LoopVar,
-   const VarDecl *EndVar, const Expr *ContainerExpr,
-   const Expr *BoundExpr, const ForStmt *TheLoop,
-   LoopFixerKind FixerKind, RangeDescriptor Descriptor);
+const VarDecl *MaybeContainer, const UsageResult &Usages,
+const DeclStmt *AliasDecl, bool AliasUseRequired,
+bool AliasFromForInit, const ForStmt *Loop,
+RangeDescriptor Descriptor);
+
+  StringRef getContainerString(ASTContext *Context, const ForStmt *Loop,
+   const Expr *ContainerExpr);
+
+  void determineRangeDescriptor(ASTContext *Context,
+const ast_matchers::BoundNodes &Nodes,
+const ForStmt *Loop, LoopFixerKind FixerKind,
+const Expr *ContainerExpr,
+const UsageResult &Usages,
+RangeDescriptor &Descriptor);
+
+  bool isConvertible(ASTContext *Context, const ast_matchers::BoundNodes &Nodes,
+ const ForStmt *Loop, LoopFixerKind FixerKind);
 
   std::unique_ptr TUInfo;
   Confidence::Level MinConfidence;
Index: clang-tidy/modernize/LoopConvertCheck.cpp
===
--- clang-tidy/modernize/LoopConvertCheck.cpp
+++ clang-tidy/modernize/LoopConvertCheck.cpp
@@ -395,6 +395,10 @@
   return false;
 }
 
+LoopConvertCheck::RangeDescriptor::RangeDescriptor()
+: ContainerNeedsDereference(false), DerefByConstRef(false),
+  DerefByValue(false), IsTriviallyCopyable(false) {}
+
 LoopConvertCheck::LoopConvertCheck(StringRef Name, ClangTidyContext *Context)
 : ClangTidyCheck(Name, Context), TUInfo(new TUTrackingInfo),
   MinConfidence(StringSwitch(
@@ -408,19 +412,24 @@
   Options.store(Opts, "MinConfidence", Confs[static_cast(MinConfidence)]);
 }
 
+void LoopConvertCheck::registerMatchers(MatchFinder *Finder) {
+  // Only register the matchers for C++. Because this checker is used for
+  // modernization, it is reasonable to run it on any C++ standard with the
+  // assumption the user is trying to modernize their codebase.
+  if (getLangOpts().CPlusPlus) {
+Finder->addMatcher(makeArrayLoopMatcher(), this);
+Finder->addMatcher(makeIteratorLoopMatcher(), this);
+Finder->addMatcher(makePseudoArrayLoopMatcher(), this);
+  }
+}
+
 /// \brief Computes the changes needed to convert a given for loop, and
-/// applies it.
+/// applies them.
 void LoopConvertCheck::doConversion(
 ASTContext *Context, const VarDecl *IndexVar, const VarDecl *MaybeContainer,
-StringRef ContainerString, const UsageResult &Usages,
-co

Re: [PATCH] D12695: [Driver] Use UniversalCRT on Windows if available

[İsmail Dönmez via cfe-commits]

This doesn't seem to work here, VS 2015 on Win 10 x64:

C:\Users\ismail\Desktop>clang-cl.exe -fms-compatibility-version=19 foo.cpp
LINK : fatal error LNK1104: cannot open file 'kernel32.lib'
clang-cl.exe: error: linker command failed with exit code 1104 (use -v
to see invocation)

Works fine after setting LIB.

On Fri, Sep 11, 2015 at 3:11 AM, Reid Kleckner via cfe-commits
 wrote:
> This revision was automatically updated to reflect the committed changes.
> Closed by commit rL247362: [Driver] Use UniversalCRT on Windows if available 
> (authored by rnk).
>
> Changed prior to commit:
>   http://reviews.llvm.org/D12695?vs=34475&id=34515#toc
>
> Repository:
>   rL LLVM
>
> http://reviews.llvm.org/D12695
>
> Files:
>   cfe/trunk/lib/Driver/MSVCToolChain.cpp
>   cfe/trunk/lib/Driver/ToolChains.h
>   cfe/trunk/lib/Driver/Tools.cpp
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r247404 - Fixed HasDeclarationMatcher to properly convert all types into decls where possible. Added objcObjectPointerType(), objcInterfaceDecl(), templateTypeParmType(), injectedClassNameType(), and

[Aaron Ballman via cfe-commits]

Author: aaronballman
Date: Fri Sep 11 06:51:24 2015
New Revision: 247404

URL: http://llvm.org/viewvc/llvm-project?rev=247404&view=rev
Log:
Fixed HasDeclarationMatcher to properly convert all types into decls where 
possible. Added objcObjectPointerType(), objcInterfaceDecl(), 
templateTypeParmType(), injectedClassNameType(), and 
unresolvedUsingTypenameDecl(). Updated documentation for pointerType() to call 
out that it does not match ObjCObjectPointerType types. Changed pointsTo() to 
handle ObjCObjectPointerType as well as PointerType.

While this may seem like a lot of unrelated changes, they all relate back to 
fixing HasDeclarationMatcher.

This now allows us to write a matcher like:

varDecl(hasType(namedDecl(hasName("Foo"

that matches code using typedefs, objc interfaces, template type parameters, 
injected class names, or unresolved using typenames.

Modified:
cfe/trunk/docs/LibASTMatchersReference.html
cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h
cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h
cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp
cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.cpp

Modified: cfe/trunk/docs/LibASTMatchersReference.html
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/LibASTMatchersReference.html?rev=247404&r1=247403&r2=247404&view=diff
==
--- cfe/trunk/docs/LibASTMatchersReference.html (original)
+++ cfe/trunk/docs/LibASTMatchersReference.html Fri Sep 11 06:51:24 2015
@@ -307,6 +307,15 @@ namespaceDecl()
 
 
 
+MatcherDecl>objcInterfaceDeclMatcherObjCInterfaceDecl>...
+Matches 
Objective-C interface declarations.
+
+Example matches Foo
+  @interface Foo
+  @end
+
+
+
 MatcherDecl>parmVarDeclMatcherParmVarDecl>...
 Matches parameter 
variable declarations.
 
@@ -364,6 +373,22 @@ typedefDecl()
 
 
 
+MatcherDecl>unresolvedUsingTypenameDeclMatcherUnresolvedUsingTypenameDecl>...
+Matches 
unresolved using value declarations that involve the
+typename.
+
+Given
+  template 
+  struct Base { typedef T Foo; };
+
+  template
+  struct S : private Base {
+using typename Base::Foo;
+  };
+unresolvedUsingTypenameDecl()
+  matches using Base::Foo 
+
+
 MatcherDecl>unresolvedUsingValueDeclMatcherUnresolvedUsingValueDecl>...
 Matches 
unresolved using value declarations.
 
@@ -1254,6 +1279,18 @@ incompleteArrayType()
 
 
 
+MatcherType>injectedClassNameTypeMatcherInjectedClassNameType>...
+Matches 
injected class name types.
+
+Example matches S s, but not S s.
+(matcher = parmVarDecl(hasType(injectedClassNameType(
+  template  struct S {
+void f(S s);
+void g(S s);
+  };
+
+
+
 MatcherType>lValueReferenceTypeMatcherLValueReferenceType>...
 Matches lvalue 
reference types.
 
@@ -1281,6 +1318,21 @@ memberPointerType()
 
 
 
+MatcherType>objcObjectPointerTypeMatcherObjCObjectPointerType>...
+Matches an 
Objective-C object pointer type, which is different from
+a pointer type, despite being syntactically similar.
+
+Given
+  int *a;
+
+  @interface Foo
+  @end
+  Foo *f;
+pointerType()
+  matches "Foo *f", but does not match "int *a".
+
+
+
 MatcherType>parenTypeMatcherParenType>...
 Matches ParenType nodes.
 
@@ -1294,14 +1346,19 @@ array_of_ptrs.
 
 
 MatcherType>pointerTypeMatcherPointerType>...
-Matches pointer types.
+Matches pointer types, 
but does not match Objective-C object pointer
+types.
 
 Given
   int *a;
   int &b = *a;
   int c = 5;
+
+  @interface Foo
+  @end
+  Foo *f;
 pointerType()
-  matches "int *a"
+  matches "int *a", but does not match "Foo *f".
 
 
 
@@ -1382,6 +1439,15 @@ instantiation in A and the type of the v
 
 
 
+MatcherType>templateTypeParmTypeMatcher

Re: [PATCH] D12736: [PATCH] AST traversal from types to decls

[Aaron Ballman via cfe-commits]

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

Thanks! I've commit in r247404.


http://reviews.llvm.org/D12736



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

Re: [PATCH] D12689: [libc++][static linking] std streams are not initialized prior to their use in static object constructors

[Evgeny Astigeevich via cfe-commits]

eastig added a comment.

In http://reviews.llvm.org/D12689#243674, @jroelofs wrote:

> A testcase would be good, regardless of which of the proposed fixes ends up 
> being chosen.


I will write it.


http://reviews.llvm.org/D12689



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

Re: recordDecl() AST matcher

[Aaron Ballman via cfe-commits]

Ping?

On Tue, Sep 8, 2015 at 9:26 AM, Manuel Klimek  wrote:
> On Tue, Sep 8, 2015 at 3:23 PM Aaron Ballman  wrote:
>>
>> On Tue, Sep 8, 2015 at 9:18 AM, Manuel Klimek  wrote:
>> > On Tue, Sep 8, 2015 at 2:23 PM Aaron Ballman 
>> > wrote:
>> >>
>> >> On Tue, Sep 8, 2015 at 5:40 AM, Manuel Klimek 
>> >> wrote:
>> >> > Yea, we had that discussion a few times, and I can never remember why
>> >> > we
>> >> > ended up in the state we're in.
>> >> > We definitely had a time where we switched to just using the exact
>> >> > same
>> >> > name
>> >> > as the node's class name for the matchers.
>> >> > I *think* we didn't do it for cxxRecordDecl, because Richard said
>> >> > that's
>> >> > a
>> >> > relic we should get rid of anyway, but I'm not sure.
>> >>
>> >> FWIW, I think the state we're in is the worst of all worlds. It's not
>> >> intuitive that recordDecl() doesn't match a struct in C mode, and as
>> >> it stands, there is no way to match a struct or union declaration in C
>> >> at all.
>> >
>> >
>> > Agreed. Best intentions. Worst possible outcome. That's software
>> > development
>> > :)
>> >
>> >> >
>> >> > On Fri, Sep 4, 2015 at 8:32 PM Aaron Ballman 
>> >> > wrote:
>> >> >>
>> >> >> It turns out that the recordDecl() AST matcher doesn't match
>> >> >> RecordDecl objects; instead, it matches CXXRecordDecl objects. This
>> >> >> is... unfortunate... as it makes writing AST matchers more
>> >> >> complicated
>> >> >> because of having to translate between recordDecl()/CXXRecordDecl.
>> >> >> It
>> >> >> also makes it impossible to match a struct or union declaration in C
>> >> >> or ObjC. However, given how prevalent recordDecl()'s use is in the
>> >> >> wild (I'm guessing), changing it at this point would be a Bad Thing.
>> >> >>
>> >> >> For people trying to write AST matchers for languages like C or
>> >> >> ObjC,
>> >> >> I would like to propose adding:
>> >> >>
>> >> >> structDecl()
>> >> >> unionDecl()
>> >> >> tagDecl()
>> >> >>
>> >> >> These will match nicely with the existing enumDecl() AST matcher.
>> >> >>
>> >> >> Additionally, I would like to add cxxRecordDecl() to match
>> >> >> CXXRecordDecl objects. While it duplicates the functionality exposed
>> >> >> by recordDecl(), it more clearly matches the intention of which AST
>> >> >> node it corresponds to.
>> >> >>
>> >> >> Finally, I would like to undocument recordDecl() and change our
>> >> >> existing documentation and AST matcher uses to use
>> >> >> cxxRecordDecl/structDecl() instead. Maybe someday we can deprecate
>> >> >> recordDecl() more officially.
>> >> >>
>> >> >> I'm open to other ideas if there are better ways to move forward. If
>> >> >> you think changing the meaning of recordDecl() is acceptable, I can
>> >> >> also go that route (though I would still propose adding unionDecl()
>> >> >> and cxxRecordDecl() in that case).
>> >> >
>> >> >
>> >> > I think changing recordDecl is acceptable. I believe very few tools
>> >> > will
>> >> > actually start doing wrong things because of it. I'd like more
>> >> > opinions
>> >> > first, though :)
>> >>
>> >> I was giving this more thought over the long weekend, and I think you
>> >> may be right. I think changing recordDecl() to mean RecordDecl will
>> >> fix more code than it breaks, so long as we take a holistic approach
>> >> to the change and see which narrowing and traversal matchers we need
>> >> to fix up at the same time. When I tried to think of AST matchers that
>> >> mean CXXRecordDecl but *not* RecordDecl, they were horribly contrived
>> >> because you usually are matching on additional selection criteria that
>> >> is specific to C++ (such as hasMethod() or isDerivedFrom()) which
>> >> would cause the match to continue to fail, as expected. Code that uses
>> >> recordDecl() to mean RecordDecl will suddenly start to match in more
>> >> cases, but that's likely to be a bug fix more than a breaking change.
>> >> To the best of my understanding, the only breaking cases would be
>> >> where you wrote recordDecl(), meant CXXRecordDecl, had no further
>> >> narrowing or traversal matchers, and were compiling in C mode; with
>> >> the result being additional unexpected matches.
>> >
>> >
>> > Ah, there's one thing that can break: the compile can break:
>> > recordDecl(hasMethod(...)) will *not* compile (it'll work in the dynamic
>> > matchers and fail as you suggest, but the in-C++ DSL does more static
>> > type
>> > checking).
>> > I don't think that's super bad though.
>> >
>> >>
>> >> So perhaps it would make sense to:
>> >>
>> >> 1) Make recordDecl() mean RecordDecl
>> >> 2) Do a comprehensive review of matchers that take a CXXRecordDecl and
>> >> see if they should instead take a RecordDecl
>> >> 3) Add unionDecl() as a node matcher (or should we add isUnion() and
>> >> isStruct() as narrowing matchers?)
>> >> 4) Add tagDecl() as a node matcher, but not add cxxRecordDecl()
>> >
>> >
>> > Why not add cxxRecordDecl()? I think we need it if we want narrowing
>> > matchers on CXXRec

Re: [clang-tools-extra] r247393 - clang-tidy/readability-inconsistent-declaration-parameter-name.cpp: Appease MS-incompatibility [-fno-delayed-template-parsing]

[Alexander Kornienko via cfe-commits]

Thank you for the fix and sorry for breaking this again. I wonder what's
the reason windows-targeting enables -fdelayed-template-parsing? Would it
be the right thing to always turn this off in clang-tidy?

On Fri, Sep 11, 2015 at 10:16 AM, NAKAMURA Takumi via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: chapuni
> Date: Fri Sep 11 03:16:22 2015
> New Revision: 247393
>
> URL: http://llvm.org/viewvc/llvm-project?rev=247393&view=rev
> Log:
> clang-tidy/readability-inconsistent-declaration-parameter-name.cpp:
> Appease MS-incompatibility [-fno-delayed-template-parsing]
>
> Modified:
>
> clang-tools-extra/trunk/test/clang-tidy/readability-inconsistent-declaration-parameter-name.cpp
>
> Modified:
> clang-tools-extra/trunk/test/clang-tidy/readability-inconsistent-declaration-parameter-name.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/readability-inconsistent-declaration-parameter-name.cpp?rev=247393&r1=247392&r2=247393&view=diff
>
> ==
> ---
> clang-tools-extra/trunk/test/clang-tidy/readability-inconsistent-declaration-parameter-name.cpp
> (original)
> +++
> clang-tools-extra/trunk/test/clang-tidy/readability-inconsistent-declaration-parameter-name.cpp
> Fri Sep 11 03:16:22 2015
> @@ -1,4 +1,4 @@
> -// RUN: %python %S/check_clang_tidy.py %s
> readability-inconsistent-declaration-parameter-name %t
> +// RUN: %python %S/check_clang_tidy.py %s
> readability-inconsistent-declaration-parameter-name %t -- -std=c++11
> -fno-delayed-template-parsing
>
>  void consistentFunction(int a, int b, int c);
>  void consistentFunction(int a, int b, int c);
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [clang-tools-extra] r247393 - clang-tidy/readability-inconsistent-declaration-parameter-name.cpp: Appease MS-incompatibility [-fno-delayed-template-parsing]

[Aaron Ballman via cfe-commits]

On Fri, Sep 11, 2015 at 9:27 AM, Alexander Kornienko via cfe-commits
 wrote:
> Thank you for the fix and sorry for breaking this again. I wonder what's the
> reason windows-targeting enables -fdelayed-template-parsing?

Because that's required for MSVC compatibility.

> Would it be the right thing to always turn this off in clang-tidy?

 I don't think it would be a good thing to turn off in clang-tidy as
the behavior would diverge from the default in clang on Windows (with
MSVC mode).

~Aaron

>
>
> On Fri, Sep 11, 2015 at 10:16 AM, NAKAMURA Takumi via cfe-commits
>  wrote:
>>
>> Author: chapuni
>> Date: Fri Sep 11 03:16:22 2015
>> New Revision: 247393
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=247393&view=rev
>> Log:
>> clang-tidy/readability-inconsistent-declaration-parameter-name.cpp:
>> Appease MS-incompatibility [-fno-delayed-template-parsing]
>>
>> Modified:
>>
>> clang-tools-extra/trunk/test/clang-tidy/readability-inconsistent-declaration-parameter-name.cpp
>>
>> Modified:
>> clang-tools-extra/trunk/test/clang-tidy/readability-inconsistent-declaration-parameter-name.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/readability-inconsistent-declaration-parameter-name.cpp?rev=247393&r1=247392&r2=247393&view=diff
>>
>> ==
>> ---
>> clang-tools-extra/trunk/test/clang-tidy/readability-inconsistent-declaration-parameter-name.cpp
>> (original)
>> +++
>> clang-tools-extra/trunk/test/clang-tidy/readability-inconsistent-declaration-parameter-name.cpp
>> Fri Sep 11 03:16:22 2015
>> @@ -1,4 +1,4 @@
>> -// RUN: %python %S/check_clang_tidy.py %s
>> readability-inconsistent-declaration-parameter-name %t
>> +// RUN: %python %S/check_clang_tidy.py %s
>> readability-inconsistent-declaration-parameter-name %t -- -std=c++11
>> -fno-delayed-template-parsing
>>
>>  void consistentFunction(int a, int b, int c);
>>  void consistentFunction(int a, int b, int c);
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: recordDecl() AST matcher

[Manuel Klimek via cfe-commits]

Richard! We need an informed opinion :D

On Fri, Sep 11, 2015 at 3:07 PM Aaron Ballman 
wrote:

> Ping?
>
> On Tue, Sep 8, 2015 at 9:26 AM, Manuel Klimek  wrote:
> > On Tue, Sep 8, 2015 at 3:23 PM Aaron Ballman 
> wrote:
> >>
> >> On Tue, Sep 8, 2015 at 9:18 AM, Manuel Klimek 
> wrote:
> >> > On Tue, Sep 8, 2015 at 2:23 PM Aaron Ballman 
> >> > wrote:
> >> >>
> >> >> On Tue, Sep 8, 2015 at 5:40 AM, Manuel Klimek 
> >> >> wrote:
> >> >> > Yea, we had that discussion a few times, and I can never remember
> why
> >> >> > we
> >> >> > ended up in the state we're in.
> >> >> > We definitely had a time where we switched to just using the exact
> >> >> > same
> >> >> > name
> >> >> > as the node's class name for the matchers.
> >> >> > I *think* we didn't do it for cxxRecordDecl, because Richard said
> >> >> > that's
> >> >> > a
> >> >> > relic we should get rid of anyway, but I'm not sure.
> >> >>
> >> >> FWIW, I think the state we're in is the worst of all worlds. It's not
> >> >> intuitive that recordDecl() doesn't match a struct in C mode, and as
> >> >> it stands, there is no way to match a struct or union declaration in
> C
> >> >> at all.
> >> >
> >> >
> >> > Agreed. Best intentions. Worst possible outcome. That's software
> >> > development
> >> > :)
> >> >
> >> >> >
> >> >> > On Fri, Sep 4, 2015 at 8:32 PM Aaron Ballman <
> aa...@aaronballman.com>
> >> >> > wrote:
> >> >> >>
> >> >> >> It turns out that the recordDecl() AST matcher doesn't match
> >> >> >> RecordDecl objects; instead, it matches CXXRecordDecl objects.
> This
> >> >> >> is... unfortunate... as it makes writing AST matchers more
> >> >> >> complicated
> >> >> >> because of having to translate between recordDecl()/CXXRecordDecl.
> >> >> >> It
> >> >> >> also makes it impossible to match a struct or union declaration
> in C
> >> >> >> or ObjC. However, given how prevalent recordDecl()'s use is in the
> >> >> >> wild (I'm guessing), changing it at this point would be a Bad
> Thing.
> >> >> >>
> >> >> >> For people trying to write AST matchers for languages like C or
> >> >> >> ObjC,
> >> >> >> I would like to propose adding:
> >> >> >>
> >> >> >> structDecl()
> >> >> >> unionDecl()
> >> >> >> tagDecl()
> >> >> >>
> >> >> >> These will match nicely with the existing enumDecl() AST matcher.
> >> >> >>
> >> >> >> Additionally, I would like to add cxxRecordDecl() to match
> >> >> >> CXXRecordDecl objects. While it duplicates the functionality
> exposed
> >> >> >> by recordDecl(), it more clearly matches the intention of which
> AST
> >> >> >> node it corresponds to.
> >> >> >>
> >> >> >> Finally, I would like to undocument recordDecl() and change our
> >> >> >> existing documentation and AST matcher uses to use
> >> >> >> cxxRecordDecl/structDecl() instead. Maybe someday we can deprecate
> >> >> >> recordDecl() more officially.
> >> >> >>
> >> >> >> I'm open to other ideas if there are better ways to move forward.
> If
> >> >> >> you think changing the meaning of recordDecl() is acceptable, I
> can
> >> >> >> also go that route (though I would still propose adding
> unionDecl()
> >> >> >> and cxxRecordDecl() in that case).
> >> >> >
> >> >> >
> >> >> > I think changing recordDecl is acceptable. I believe very few tools
> >> >> > will
> >> >> > actually start doing wrong things because of it. I'd like more
> >> >> > opinions
> >> >> > first, though :)
> >> >>
> >> >> I was giving this more thought over the long weekend, and I think you
> >> >> may be right. I think changing recordDecl() to mean RecordDecl will
> >> >> fix more code than it breaks, so long as we take a holistic approach
> >> >> to the change and see which narrowing and traversal matchers we need
> >> >> to fix up at the same time. When I tried to think of AST matchers
> that
> >> >> mean CXXRecordDecl but *not* RecordDecl, they were horribly contrived
> >> >> because you usually are matching on additional selection criteria
> that
> >> >> is specific to C++ (such as hasMethod() or isDerivedFrom()) which
> >> >> would cause the match to continue to fail, as expected. Code that
> uses
> >> >> recordDecl() to mean RecordDecl will suddenly start to match in more
> >> >> cases, but that's likely to be a bug fix more than a breaking change.
> >> >> To the best of my understanding, the only breaking cases would be
> >> >> where you wrote recordDecl(), meant CXXRecordDecl, had no further
> >> >> narrowing or traversal matchers, and were compiling in C mode; with
> >> >> the result being additional unexpected matches.
> >> >
> >> >
> >> > Ah, there's one thing that can break: the compile can break:
> >> > recordDecl(hasMethod(...)) will *not* compile (it'll work in the
> dynamic
> >> > matchers and fail as you suggest, but the in-C++ DSL does more static
> >> > type
> >> > checking).
> >> > I don't think that's super bad though.
> >> >
> >> >>
> >> >> So perhaps it would make sense to:
> >> >>
> >> >> 1) Make recordDecl() mean RecordDecl
> >> >> 2) Do a comprehensive review of matchers that

r247410 - This test requires UTF-8 output to print the UT-8 characters.

[Yaron Keren via cfe-commits]

Author: yrnkrn
Date: Fri Sep 11 08:29:12 2015
New Revision: 247410

URL: http://llvm.org/viewvc/llvm-project?rev=247410&view=rev
Log:
This test requires UTF-8 output to print the UT-8 characters.


Modified:
cfe/trunk/test/Frontend/source-col-map.c

Modified: cfe/trunk/test/Frontend/source-col-map.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/source-col-map.c?rev=247410&r1=247409&r2=247410&view=diff
==
--- cfe/trunk/test/Frontend/source-col-map.c (original)
+++ cfe/trunk/test/Frontend/source-col-map.c Fri Sep 11 08:29:12 2015
@@ -1,4 +1,5 @@
 // RUN: not %clang_cc1 -fsyntax-only -fmessage-length 75 -o /dev/null -x c < 
%s 2>&1 | FileCheck %s -strict-whitespace
+// REQUIRES: utf8-capable-terminal
 
 // Test case for the text diagnostics source column conversion crash.
 


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

Re: r247410 - This test requires UTF-8 output to print the UT-8 characters.

[Aaron Ballman via cfe-commits]

Thank you for this! I wasn't certain of what the right way to fix it was. :-)

~Aaron

On Fri, Sep 11, 2015 at 9:29 AM, Yaron Keren via cfe-commits
 wrote:
> Author: yrnkrn
> Date: Fri Sep 11 08:29:12 2015
> New Revision: 247410
>
> URL: http://llvm.org/viewvc/llvm-project?rev=247410&view=rev
> Log:
> This test requires UTF-8 output to print the UT-8 characters.
>
>
> Modified:
> cfe/trunk/test/Frontend/source-col-map.c
>
> Modified: cfe/trunk/test/Frontend/source-col-map.c
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/source-col-map.c?rev=247410&r1=247409&r2=247410&view=diff
> ==
> --- cfe/trunk/test/Frontend/source-col-map.c (original)
> +++ cfe/trunk/test/Frontend/source-col-map.c Fri Sep 11 08:29:12 2015
> @@ -1,4 +1,5 @@
>  // RUN: not %clang_cc1 -fsyntax-only -fmessage-length 75 -o /dev/null -x c < 
> %s 2>&1 | FileCheck %s -strict-whitespace
> +// REQUIRES: utf8-capable-terminal
>
>  // Test case for the text diagnostics source column conversion crash.
>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D12695: [Driver] Use UniversalCRT on Windows if available

[Igor Kudrin via cfe-commits]

Please, can you show the output of the following commands:

1) set include
2) set lib
3) clang-cl.exe -### -fms-compatibility-version=19 foo.cpp

On 11.09.2015 17:44, İsmail Dönmez wrote:

This doesn't seem to work here, VS 2015 on Win 10 x64:

C:\Users\ismail\Desktop>clang-cl.exe -fms-compatibility-version=19 foo.cpp
LINK : fatal error LNK1104: cannot open file 'kernel32.lib'
clang-cl.exe: error: linker command failed with exit code 1104 (use -v
to see invocation)

Works fine after setting LIB.

On Fri, Sep 11, 2015 at 3:11 AM, Reid Kleckner via cfe-commits
 wrote:

This revision was automatically updated to reflect the committed changes.
Closed by commit rL247362: [Driver] Use UniversalCRT on Windows if available 
(authored by rnk).

Changed prior to commit:
   http://reviews.llvm.org/D12695?vs=34475&id=34515#toc

Repository:
   rL LLVM

http://reviews.llvm.org/D12695

Files:
   cfe/trunk/lib/Driver/MSVCToolChain.cpp
   cfe/trunk/lib/Driver/ToolChains.h
   cfe/trunk/lib/Driver/Tools.cpp


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



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

Re: r247410 - This test requires UTF-8 output to print the UT-8 characters.

[Yaron Keren via cfe-commits]

The test was passing before r247253 without LLVM_ON_WIN32 defined in
lib/Support/Locale.cpp, so the llvm::sys::unicode::* functions were used,
which may mean that the LLVM_ON_WIN32 functions are overly restrictive.
For example, Windows can output the UTF-8 character from source-col-map.c
correctly. Maybe the correct fix it to actually eliminate the
LLVM_ON_WIN32 versions.

What I still don't understand - how the Windows bots were passing this test
and green?


2015-09-11 16:31 GMT+03:00 Aaron Ballman :

> Thank you for this! I wasn't certain of what the right way to fix it was.
> :-)
>
> ~Aaron
>
> On Fri, Sep 11, 2015 at 9:29 AM, Yaron Keren via cfe-commits
>  wrote:
> > Author: yrnkrn
> > Date: Fri Sep 11 08:29:12 2015
> > New Revision: 247410
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=247410&view=rev
> > Log:
> > This test requires UTF-8 output to print the UT-8 characters.
> >
> >
> > Modified:
> > cfe/trunk/test/Frontend/source-col-map.c
> >
> > Modified: cfe/trunk/test/Frontend/source-col-map.c
> > URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/source-col-map.c?rev=247410&r1=247409&r2=247410&view=diff
> >
> ==
> > --- cfe/trunk/test/Frontend/source-col-map.c (original)
> > +++ cfe/trunk/test/Frontend/source-col-map.c Fri Sep 11 08:29:12 2015
> > @@ -1,4 +1,5 @@
> >  // RUN: not %clang_cc1 -fsyntax-only -fmessage-length 75 -o /dev/null
> -x c < %s 2>&1 | FileCheck %s -strict-whitespace
> > +// REQUIRES: utf8-capable-terminal
> >
> >  // Test case for the text diagnostics source column conversion crash.
> >
> >
> >
> > ___
> > cfe-commits mailing list
> > cfe-commits@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D12695: [Driver] Use UniversalCRT on Windows if available

[İsmail Dönmez via cfe-commits]

Hi,

C:\Users\ismail\Desktop>set include
INCLUDE=C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\INCLUDE;C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\ATLMFC\INCLUDE;C:\Program Files (x86)\Windows
Kits\10\include\10.0.10240.0\ucrt;C:\Program Files (x86)\Windows
Kits\NETFXSDK\4.6\include\um;C:\Program Files (x86)\Windows
Kits\10\include\10.0.10240.0\shared;C:\Program Files (x86)\Windows
Kits\10\include\10.0.10240.0\um;C:\Program Files (x86)\Windows
Kits\10\include\10.0.10240.0\winrt;

C:\Users\ismail\Desktop>set lib
LIB=C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\LIB\amd64;C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\ATLMFC\LIB\amd64;C:\Program Files (x86)\Windows
Kits\10\lib\10.0.10240.0\ucrt\x64;C:\Program Files (x86)\Windows
Kits\NETFXSDK\4.6\lib\um\x64;C:\Program Files (x86)\Windows
Kits\10\lib\10.0.10240.0\um\x64;
LIBPATH=C:\WINDOWS\Microsoft.NET\Framework64\v4.0.30319;C:\Program
Files (x86)\Microsoft Visual Studio 14.0\VC\LIB\amd64;C:\Program Files
(x86)\Microsoft Visual Studio 14.0\VC\ATLMFC\LIB\amd64;C:\Program
Files (x86)\Windows Kits\10\UnionMetadata;C:\Program Files
(x86)\Windows Kits\10\References;C:\Program Files (x86)\Windows
Kits\10\References\Windows.Foundation.UniversalApiContract\1.0.0.0;C:\Program
Files (x86)\Windows
Kits\10\References\Windows.Foundation.FoundationContract\1.0.0.0;C:\Program
Files (x86)\Windows
Kits\10\References\indows.Networking.Connectivity.WwanContract\1.0.0.0;C:\Program
Files (x86)\Microsoft SDKs\Windows
Kits\10\ExtensionSDKs\Microsoft.VCLibs\14.0\References\CommonConfiguration\neutral;

C:\Users\ismail\Desktop>clang-cl.exe -###
-fms-compatibility-version=19 mandelbrot-mp.cpp
clang version 3.8.0 (http://llvm.org/git/clang
d2dc884a74b40711955713829e7a09b8ff5ca1bc) (http://llvm.org/git/llvm
595af7ed8595ccf005efb087b5bb7d9a19e50e3b)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files\LLVM\bin
 "C:\\Program Files\\LLVM\\bin\\clang-cl.exe" "-cc1" "-triple"
"x86_64-pc-windows-msvc19.0.0" "-emit-obj" "-mrelax-all"
"-disable-free" "-main-file-name" "mandelbrot-mp.cpp"
"-mrelocation-model" "pic" "-pic-level" "2" "-mthread-model" "posix"
"-relaxed-aliasing" "-fmath-errno" "-masm-verbose"
"-mconstructor-aliases" "-munwind-tables" "-target-cpu" "x86-64"
"-D_MT" "--dependent-lib=libcmt" "--dependent-lib=oldnames"
"-fms-volatile" "-fdiagnostics-format" "msvc"
"-momit-leaf-frame-pointer" "-dwarf-column-info" "-resource-dir"
"C:\\Program Files\\LLVM\\bin\\..\\lib\\clang\\3.8.0"
"-internal-isystem" "C:\\Program
Files\\LLVM\\bin\\..\\lib\\clang\\3.8.0\\include" "-internal-isystem"
"C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\VC\\INCLUDE"
"-internal-isystem" "C:\\Program Files (x86)\\Microsoft Visual Studio
14.0\\VC\\ATLMFC\\INCLUDE" "-internal-isystem" "C:\\Program Files
(x86)\\Windows Kits\\10\\include\\10.0.10240.0\\ucrt"
"-internal-isystem" "C:\\Program Files (x86)\\Windows
Kits\\NETFXSDK\\4.6\\include\\um" "-internal-isystem" "C:\\Program
Files (x86)\\Windows Kits\\10\\include\\10.0.10240.0\\shared"
"-internal-isystem" "C:\\Program Files (x86)\\Windows
Kits\\10\\include\\10.0.10240.0\\um" "-internal-isystem" "C:\\Program
Files (x86)\\Windows Kits\\10\\include\\10.0.10240.0\\winrt" "-Wall"
"-fdeprecated-macro" "-fdebug-compilation-dir"
"C:\\Users\\ismail\\Desktop" "-ferror-limit" "19" "-fmessage-length"
"100" "-mstackrealign" "-fms-extensions" "-fms-compatibility"
"-fms-compatibility-version=19" "-std=c++14"
"-fdelayed-template-parsing" "-fobjc-runtime=gcc"
"-fdiagnostics-show-option" "-fcolor-diagnostics" "-o"
"C:\\Users\\ismail\\AppData\\Local\\Temp\\mandelbrot-mp-d6f68c.obj"
"-x" "c++" "mandelbrot-mp.cpp"
 "C:\\Program Files (x86)\\Microsoft Visual Studio
14.0\\VC\\bin\\amd64\\link.exe" "-out:mandelbrot-mp.exe" "-nologo"
"C:\\Users\\ismail\\AppData\\Local\\Temp\\mandelbrot-mp-d6f68c.obj"


On Fri, Sep 11, 2015 at 4:42 PM, Igor Kudrin  wrote:
> Please, can you show the output of the following commands:
>
> 1) set include
> 2) set lib
> 3) clang-cl.exe -### -fms-compatibility-version=19 foo.cpp
>
>
> On 11.09.2015 17:44, İsmail Dönmez wrote:
>>
>> This doesn't seem to work here, VS 2015 on Win 10 x64:
>>
>> C:\Users\ismail\Desktop>clang-cl.exe -fms-compatibility-version=19 foo.cpp
>> LINK : fatal error LNK1104: cannot open file 'kernel32.lib'
>> clang-cl.exe: error: linker command failed with exit code 1104 (use -v
>> to see invocation)
>>
>> Works fine after setting LIB.
>>
>> On Fri, Sep 11, 2015 at 3:11 AM, Reid Kleckner via cfe-commits
>>  wrote:
>>>
>>> This revision was automatically updated to reflect the committed changes.
>>> Closed by commit rL247362: [Driver] Use UniversalCRT on Windows if
>>> available (authored by rnk).
>>>
>>> Changed prior to commit:
>>>http://reviews.llvm.org/D12695?vs=34475&id=34515#toc
>>>
>>> Repository:
>>>rL LLVM
>>>
>>> http://reviews.llvm.org/D12695
>>>
>>> Files:
>>>cfe/trunk/lib/Driver/MSVCToolChain.cpp
>>>cfe/trunk/lib/Driver/ToolChains.h
>>>

Re: [PATCH] D12695: [Driver] Use UniversalCRT on Windows if available

[Igor Kudrin via cfe-commits]

Hi İsmail,

Clang tries to detect pathes automatically only if corresponding 
environment variables are not set. In your case, you have these 
variables set, so clang honors them.


You have only set pathes for VC libraries and Universal CRT, but the 
kernel32.lib library is shipped with Windows SDKs and probably located 
at the path like "C:\Program Files (x86)\Windows 
Kits\8.1\Lib\winv6.3\um\x64".


On 11.09.2015 19:44, İsmail Dönmez wrote:

Hi,

C:\Users\ismail\Desktop>set include
INCLUDE=C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\INCLUDE;C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\ATLMFC\INCLUDE;C:\Program Files (x86)\Windows
Kits\10\include\10.0.10240.0\ucrt;C:\Program Files (x86)\Windows
Kits\NETFXSDK\4.6\include\um;C:\Program Files (x86)\Windows
Kits\10\include\10.0.10240.0\shared;C:\Program Files (x86)\Windows
Kits\10\include\10.0.10240.0\um;C:\Program Files (x86)\Windows
Kits\10\include\10.0.10240.0\winrt;

C:\Users\ismail\Desktop>set lib
LIB=C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\LIB\amd64;C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\ATLMFC\LIB\amd64;C:\Program Files (x86)\Windows
Kits\10\lib\10.0.10240.0\ucrt\x64;C:\Program Files (x86)\Windows
Kits\NETFXSDK\4.6\lib\um\x64;C:\Program Files (x86)\Windows
Kits\10\lib\10.0.10240.0\um\x64;
LIBPATH=C:\WINDOWS\Microsoft.NET\Framework64\v4.0.30319;C:\Program
Files (x86)\Microsoft Visual Studio 14.0\VC\LIB\amd64;C:\Program Files
(x86)\Microsoft Visual Studio 14.0\VC\ATLMFC\LIB\amd64;C:\Program
Files (x86)\Windows Kits\10\UnionMetadata;C:\Program Files
(x86)\Windows Kits\10\References;C:\Program Files (x86)\Windows
Kits\10\References\Windows.Foundation.UniversalApiContract\1.0.0.0;C:\Program
Files (x86)\Windows
Kits\10\References\Windows.Foundation.FoundationContract\1.0.0.0;C:\Program
Files (x86)\Windows
Kits\10\References\indows.Networking.Connectivity.WwanContract\1.0.0.0;C:\Program
Files (x86)\Microsoft SDKs\Windows
Kits\10\ExtensionSDKs\Microsoft.VCLibs\14.0\References\CommonConfiguration\neutral;

C:\Users\ismail\Desktop>clang-cl.exe -###
-fms-compatibility-version=19 mandelbrot-mp.cpp
clang version 3.8.0 (http://llvm.org/git/clang
d2dc884a74b40711955713829e7a09b8ff5ca1bc) (http://llvm.org/git/llvm
595af7ed8595ccf005efb087b5bb7d9a19e50e3b)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files\LLVM\bin
  "C:\\Program Files\\LLVM\\bin\\clang-cl.exe" "-cc1" "-triple"
"x86_64-pc-windows-msvc19.0.0" "-emit-obj" "-mrelax-all"
"-disable-free" "-main-file-name" "mandelbrot-mp.cpp"
"-mrelocation-model" "pic" "-pic-level" "2" "-mthread-model" "posix"
"-relaxed-aliasing" "-fmath-errno" "-masm-verbose"
"-mconstructor-aliases" "-munwind-tables" "-target-cpu" "x86-64"
"-D_MT" "--dependent-lib=libcmt" "--dependent-lib=oldnames"
"-fms-volatile" "-fdiagnostics-format" "msvc"
"-momit-leaf-frame-pointer" "-dwarf-column-info" "-resource-dir"
"C:\\Program Files\\LLVM\\bin\\..\\lib\\clang\\3.8.0"
"-internal-isystem" "C:\\Program
Files\\LLVM\\bin\\..\\lib\\clang\\3.8.0\\include" "-internal-isystem"
"C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\VC\\INCLUDE"
"-internal-isystem" "C:\\Program Files (x86)\\Microsoft Visual Studio
14.0\\VC\\ATLMFC\\INCLUDE" "-internal-isystem" "C:\\Program Files
(x86)\\Windows Kits\\10\\include\\10.0.10240.0\\ucrt"
"-internal-isystem" "C:\\Program Files (x86)\\Windows
Kits\\NETFXSDK\\4.6\\include\\um" "-internal-isystem" "C:\\Program
Files (x86)\\Windows Kits\\10\\include\\10.0.10240.0\\shared"
"-internal-isystem" "C:\\Program Files (x86)\\Windows
Kits\\10\\include\\10.0.10240.0\\um" "-internal-isystem" "C:\\Program
Files (x86)\\Windows Kits\\10\\include\\10.0.10240.0\\winrt" "-Wall"
"-fdeprecated-macro" "-fdebug-compilation-dir"
"C:\\Users\\ismail\\Desktop" "-ferror-limit" "19" "-fmessage-length"
"100" "-mstackrealign" "-fms-extensions" "-fms-compatibility"
"-fms-compatibility-version=19" "-std=c++14"
"-fdelayed-template-parsing" "-fobjc-runtime=gcc"
"-fdiagnostics-show-option" "-fcolor-diagnostics" "-o"
"C:\\Users\\ismail\\AppData\\Local\\Temp\\mandelbrot-mp-d6f68c.obj"
"-x" "c++" "mandelbrot-mp.cpp"
  "C:\\Program Files (x86)\\Microsoft Visual Studio
14.0\\VC\\bin\\amd64\\link.exe" "-out:mandelbrot-mp.exe" "-nologo"
"C:\\Users\\ismail\\AppData\\Local\\Temp\\mandelbrot-mp-d6f68c.obj"


On Fri, Sep 11, 2015 at 4:42 PM, Igor Kudrin  wrote:

Please, can you show the output of the following commands:

1) set include
2) set lib
3) clang-cl.exe -### -fms-compatibility-version=19 foo.cpp


On 11.09.2015 17:44, İsmail Dönmez wrote:

This doesn't seem to work here, VS 2015 on Win 10 x64:

C:\Users\ismail\Desktop>clang-cl.exe -fms-compatibility-version=19 foo.cpp
LINK : fatal error LNK1104: cannot open file 'kernel32.lib'
clang-cl.exe: error: linker command failed with exit code 1104 (use -v
to see invocation)

Works fine after setting LIB.

On Fri, Sep 11, 2015 at 3:11 AM, Reid Kleckner via cfe-commits
 wrote:

This revision was automatically updated to reflect th

Re: [PATCH] D12695: [Driver] Use UniversalCRT on Windows if available

[İsmail Dönmez via cfe-commits]

Hi,

On Fri, Sep 11, 2015 at 5:03 PM, Igor Kudrin  wrote:
> Hi İsmail,
>
> Clang tries to detect pathes automatically only if corresponding environment
> variables are not set. In your case, you have these variables set, so clang
> honors them.

In the original case no variable was set, I thought you wanted the
variables vs script sets when it works.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D12695: [Driver] Use UniversalCRT on Windows if available

[Igor Kudrin via cfe-commits]

Hi İsmail,

It looks like we need a new logic to detect a Windows 10 SDK 
installation folder. I'll fill the bug about that.


Thank you.

On 11.09.2015 20:11, İsmail Dönmez wrote:

Hi,

On Fri, Sep 11, 2015 at 5:03 PM, Igor Kudrin  wrote:

Hi İsmail,

Clang tries to detect pathes automatically only if corresponding environment
variables are not set. In your case, you have these variables set, so clang
honors them.

In the original case no variable was set, I thought you wanted the
variables vs script sets when it works.


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

Re: [PATCH] D12358: [Analyzer] Handling constant bound loops

[Devin Coughlin via cfe-commits]

dcoughlin added a comment.

I'll look at this today. Thanks for your patience!


http://reviews.llvm.org/D12358



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

Re: [PATCH] D12402: PR24595: clang-cl fails to compile vswriter.h header from Windows SDK 8.1 in 32 bit mode

[Reid Kleckner via cfe-commits]

rnk added inline comments.


Comment at: lib/Sema/SemaType.cpp:5876
@@ +5875,3 @@
+
+if (!IsCtorOrDtor) {
+  if (CurCC != DefaultCC || DefaultCC == ToCC)

This looks like the !IsCtorOrDtor check that affects Itanium. Isn't it already 
handled for MS C++ above?


Comment at: test/CodeGenCXX/ctor-dtor-alias.cpp:170
@@ -169,3 +169,3 @@
   // it has a different calling conversion.
-  // CHECK4: call void @_ZN5test93barD2Ev
+  // CHECK4: call void @_ZN6test103barD2Ev
   bar ptr;

andreybokhanko wrote:
> rnk wrote:
> > Isn't this still in the test9 namespace? Shouldn't this change be reverted?
> Now, after making the change you requested (wrapping checks in "default" part 
> of adjustMemberFunctionCC function with !IsCtorOrDtor (SemaType.cpp:5876)) we 
> start to call ~foo() here, so the check should be changed to:
> 
>   // CHECK4: call void bitcast (void (%"struct.test9::foo"*)* 
> @_ZN5test93fooD2Ev
> 
> Please confirm you are OK with this change and I'll go ahead with commit.
That seems like a bug, we don't want this change to affect destructors on Linux 
or mingw.


http://reviews.llvm.org/D12402



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

Re: r247369 - Module Debugging: Emit forward declarations for types that are defined in

[Adrian Prantl via cfe-commits]

> On Sep 10, 2015, at 6:56 PM, David Blaikie  wrote:
> 
> 
> 
> On Thu, Sep 10, 2015 at 6:40 PM, David Blaikie  > wrote:
> 
> 
> On Thu, Sep 10, 2015 at 6:03 PM, Adrian Prantl via cfe-commits 
> mailto:cfe-commits@lists.llvm.org>> wrote:
> Author: adrian
> Date: Thu Sep 10 20:03:26 2015
> New Revision: 247369
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=247369&view=rev 
> 
> Log:
> Module Debugging: Emit forward declarations for types that are defined in
> clang modules, if -dwarf-ext-refs (DebugTypesExtRefs) is specified.
> 
> This change seems to have a lot more code in it than I was expecting... 
> 
> I was rather expecting something a lot like the flimit-debug-info support. 
> Specifically, I would've expected one more conditional added to 
> CGDebugInfo::shouldOmitDefinition.
> 
> Why the extra complexity?
> 
> I guess part of it is to be able to omit definitions of things other than 
> record types - is there much value in that? (especially typedefs - it seems 
> like a typedef is too small to benefit from a declaration (even if we could 
> emit one)?)

The typedef itself is not interesting, but it can be used to anchor template 
instantiations like std::string. The contract between the debug info in the 
module and the debug info referencing the module is that all explicit template 
specializations and template instantiations referenced used in a typedef can be 
expected to exist in the module.

> Also, we could possibly solve both the problem of "don't emit definitions for 
> module things when compiling the main source file" and "don't emit 
> definitions for module things defined in other modules" with the same tool. 
> If there's a way to say "is this in a foreign AST file" then testing for that 
> in CGDebugInfo::shouldOmitDefinition would solve both problems, I think 
> (conditionalized on the appropriate flags, either dwarf-ext-refs or "I'm 
> building a module here”).

I believe that this is a good point. Really, getExtRefOrNull is a separate 
function mostly for evolutionary reasons — it used to do different things like 
mangling names of ObjC types etc. I will see if I can merge the existing 
functionality into shouldOmitDefinition().

-- adrian
>  
>  
> 
> Added:
> cfe/trunk/test/Modules/ExtDebugInfo.cpp
> cfe/trunk/test/Modules/ExtDebugInfo.m
> Modified:
> cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
> cfe/trunk/lib/CodeGen/CGDebugInfo.h
> 
> Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=247369&r1=247368&r2=247369&view=diff
>  
> 
> ==
> --- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Thu Sep 10 20:03:26 2015
> @@ -148,7 +148,9 @@ void CGDebugInfo::setLocation(SourceLoca
>  }
> 
>  llvm::DIScope *CGDebugInfo::getDeclContextDescriptor(const Decl *D) {
> -  return getContextDescriptor(cast(D->getDeclContext()), TheCU);
> +  llvm::DIScope *Mod = getParentModuleOrNull(D);
> +  return getContextDescriptor(cast(D->getDeclContext()),
> +  Mod ? Mod : TheCU);
>  }
> 
>  llvm::DIScope *CGDebugInfo::getContextDescriptor(const Decl *Context,
> @@ -1448,6 +1450,9 @@ void CGDebugInfo::completeRequiredType(c
>  if (CXXDecl->isDynamicClass())
>return;
> 
> +  if (DebugTypeExtRefs && RD->isFromASTFile())
> +return;
> +
>QualType Ty = CGM.getContext().getRecordType(RD);
>llvm::DIType *T = getTypeOrNull(Ty);
>if (T && T->isForwardDecl())
> @@ -1669,9 +1674,9 @@ CGDebugInfo::getOrCreateModuleRef(Extern
>TheCU->getSourceLanguage(), internString(Mod.ModuleName),
>internString(Mod.Path), TheCU->getProducer(), true, StringRef(), 0,
>internString(Mod.ASTFile), llvm::DIBuilder::FullDebug, Mod.Signature);
> -  llvm::DIModule *M =
> -  DIB.createModule(CU, Mod.ModuleName, ConfigMacros, 
> internString(Mod.Path),
> -   internString(CGM.getHeaderSearchOpts().Sysroot));
> +  llvm::DIModule *M = DIB.createModule(
> +  CU, Mod.ModuleName, ConfigMacros, internString(Mod.Path),
> +  internString(CGM.getHeaderSearchOpts().Sysroot));
>DIB.finalize();
>ModRef.reset(M);
>return M;
> @@ -2081,9 +2086,16 @@ llvm::DIType *CGDebugInfo::getOrCreateTy
>if (auto *T = getTypeOrNull(Ty))
>  return T;
> 
> +  llvm::DIType *Res = nullptr;
> +  if (DebugTypeExtRefs)
> +// Make a forward declaration of an external type.
> +Res = getTypeExtRefOrNull(Ty, Unit);
> +
>// Otherwise create the type.
> -  llvm::DIType *Res = CreateTypeNode(Ty, Unit);
> -  void *TyPtr = Ty.getAsOpaquePtr();
> +  if (!Res)
> +Res = CreateTypeNode(Ty, Unit);
> +
> +  void* TyPtr = Ty.getAsOpaqueP

Re: r247369 - Module Debugging: Emit forward declarations for types that are defined in

[David Blaikie via cfe-commits]

On Fri, Sep 11, 2015 at 8:18 AM, Adrian Prantl  wrote:

>
> On Sep 10, 2015, at 6:56 PM, David Blaikie  wrote:
>
>
>
> On Thu, Sep 10, 2015 at 6:40 PM, David Blaikie  wrote:
>
>>
>>
>> On Thu, Sep 10, 2015 at 6:03 PM, Adrian Prantl via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: adrian
>>> Date: Thu Sep 10 20:03:26 2015
>>> New Revision: 247369
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=247369&view=rev
>>> Log:
>>> Module Debugging: Emit forward declarations for types that are defined in
>>> clang modules, if -dwarf-ext-refs (DebugTypesExtRefs) is specified.
>>>
>>
>> This change seems to have a lot more code in it than I was expecting...
>>
>> I was rather expecting something a lot like the flimit-debug-info
>> support. Specifically, I would've expected one more conditional added to
>> CGDebugInfo::shouldOmitDefinition.
>>
>> Why the extra complexity?
>>
>> I guess part of it is to be able to omit definitions of things other than
>> record types - is there much value in that? (especially typedefs - it seems
>> like a typedef is too small to benefit from a declaration (even if we could
>> emit one)?)
>>
>
> The typedef itself is not interesting, but it can be used to anchor
> template instantiations like std::string. The contract between the debug
> info in the module and the debug info referencing the module is that all
> explicit template specializations
>

This I get ^ (though does that case need any special handling, or will the
isFromASTFile return true for the location of the explicit specialization
declaration/definition?)


> and template instantiations referenced used in a typedef can be expected
> to exist in the module.
>

This I do not get & would imagine it could cause substantial size
increase...

Might be worth splitting out that change to look at it more carefully. I'd
love to see numbers here.

> Also, we could possibly solve both the problem of "don't emit definitions
> for module things when compiling the main source file" and "don't emit
> definitions for module things defined in other modules" with the same tool.
> If there's a way to say "is this in a foreign AST file" then testing for
> that in CGDebugInfo::shouldOmitDefinition would solve both problems, I
> think (conditionalized on the appropriate flags, either dwarf-ext-refs or
> "I'm building a module here”).
>
>
> I believe that this is a good point. Really, getExtRefOrNull is a separate
> function mostly for evolutionary reasons — it used to do different things
> like mangling names of ObjC types etc. I will see if I can merge the
> existing functionality into shouldOmitDefinition().
>

>From a review perspective it might be easier to revert this & commit a new
patch - I haven't reviewed all these changes in detail because they just
seemed more complex than necessary, but if you're going to evolve it from
here I'll need to dig into the current implementation/be more careful about
checking that future changes remove the complexity along with whatever they
add.

- Dave


>
> -- adrian
>
>
>
>>
>>
>>>
>>> Added:
>>> cfe/trunk/test/Modules/ExtDebugInfo.cpp
>>> cfe/trunk/test/Modules/ExtDebugInfo.m
>>> Modified:
>>> cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
>>> cfe/trunk/lib/CodeGen/CGDebugInfo.h
>>>
>>> Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=247369&r1=247368&r2=247369&view=diff
>>>
>>> ==
>>> --- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
>>> +++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Thu Sep 10 20:03:26 2015
>>> @@ -148,7 +148,9 @@ void CGDebugInfo::setLocation(SourceLoca
>>>  }
>>>
>>>  llvm::DIScope *CGDebugInfo::getDeclContextDescriptor(const Decl *D) {
>>> -  return getContextDescriptor(cast(D->getDeclContext()), TheCU);
>>> +  llvm::DIScope *Mod = getParentModuleOrNull(D);
>>> +  return getContextDescriptor(cast(D->getDeclContext()),
>>> +  Mod ? Mod : TheCU);
>>>  }
>>>
>>>  llvm::DIScope *CGDebugInfo::getContextDescriptor(const Decl *Context,
>>> @@ -1448,6 +1450,9 @@ void CGDebugInfo::completeRequiredType(c
>>>  if (CXXDecl->isDynamicClass())
>>>return;
>>>
>>> +  if (DebugTypeExtRefs && RD->isFromASTFile())
>>> +return;
>>> +
>>>QualType Ty = CGM.getContext().getRecordType(RD);
>>>llvm::DIType *T = getTypeOrNull(Ty);
>>>if (T && T->isForwardDecl())
>>> @@ -1669,9 +1674,9 @@ CGDebugInfo::getOrCreateModuleRef(Extern
>>>TheCU->getSourceLanguage(), internString(Mod.ModuleName),
>>>internString(Mod.Path), TheCU->getProducer(), true, StringRef(),
>>> 0,
>>>internString(Mod.ASTFile), llvm::DIBuilder::FullDebug,
>>> Mod.Signature);
>>> -  llvm::DIModule *M =
>>> -  DIB.createModule(CU, Mod.ModuleName, ConfigMacros,
>>> internString(Mod.Path),
>>> -   internString(CGM.getHeaderSearchOpts().Sysroot));
>>> + 

r247421 - [CodeGen] Teach SimplifyPersonality about the updated LandingPadInst

[Vedant Kumar via cfe-commits]

Author: vedantk
Date: Fri Sep 11 10:40:05 2015
New Revision: 247421

URL: http://llvm.org/viewvc/llvm-project?rev=247421&view=rev
Log:
[CodeGen] Teach SimplifyPersonality about the updated LandingPadInst

When uses of personality functions were moved from LandingPadInst to
Function, we forgot to update SimplifyPersonality(). This patch corrects
that.

Note: SimplifyPersonality() is an optimization which replaces
personality functions with the default C++ personality when possible.
Without this update, some ObjC++ projects fail to link against C++
libraries (seeing as the exception ABI had effectively changed).

rdar://problem/22155434

Added:
cfe/trunk/test/CodeGenObjCXX/exception-cxx.mm
cfe/trunk/test/CodeGenObjCXX/personality-abuse.mm
Modified:
cfe/trunk/lib/CodeGen/CGException.cpp

Modified: cfe/trunk/lib/CodeGen/CGException.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGException.cpp?rev=247421&r1=247420&r2=247421&view=diff
==
--- cfe/trunk/lib/CodeGen/CGException.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGException.cpp Fri Sep 11 10:40:05 2015
@@ -229,6 +229,36 @@ static llvm::Constant *getOpaquePersonal
   return llvm::ConstantExpr::getBitCast(Fn, CGM.Int8PtrTy);
 }
 
+/// Check whether a landingpad instruction only uses C++ features.
+static bool LandingPadHasOnlyCXXUses(llvm::LandingPadInst *LPI) {
+  for (unsigned I = 0, E = LPI->getNumClauses(); I != E; ++I) {
+// Look for something that would've been returned by the ObjC
+// runtime's GetEHType() method.
+llvm::Value *Val = LPI->getClause(I)->stripPointerCasts();
+if (LPI->isCatch(I)) {
+  // Check if the catch value has the ObjC prefix.
+  if (llvm::GlobalVariable *GV = dyn_cast(Val))
+// ObjC EH selector entries are always global variables with
+// names starting like this.
+if (GV->getName().startswith("OBJC_EHTYPE"))
+  return false;
+} else {
+  // Check if any of the filter values have the ObjC prefix.
+  llvm::Constant *CVal = cast(Val);
+  for (llvm::User::op_iterator
+  II = CVal->op_begin(), IE = CVal->op_end(); II != IE; ++II) {
+if (llvm::GlobalVariable *GV =
+cast((*II)->stripPointerCasts()))
+  // ObjC EH selector entries are always global variables with
+  // names starting like this.
+  if (GV->getName().startswith("OBJC_EHTYPE"))
+return false;
+  }
+}
+  }
+  return true;
+}
+
 /// Check whether a personality function could reasonably be swapped
 /// for a C++ personality function.
 static bool PersonalityHasOnlyCXXUses(llvm::Constant *Fn) {
@@ -241,34 +271,14 @@ static bool PersonalityHasOnlyCXXUses(ll
   continue;
 }
 
-// Otherwise, it has to be a landingpad instruction.
-llvm::LandingPadInst *LPI = dyn_cast(U);
-if (!LPI) return false;
+// Otherwise it must be a function.
+llvm::Function *F = dyn_cast(U);
+if (!F) return false;
 
-for (unsigned I = 0, E = LPI->getNumClauses(); I != E; ++I) {
-  // Look for something that would've been returned by the ObjC
-  // runtime's GetEHType() method.
-  llvm::Value *Val = LPI->getClause(I)->stripPointerCasts();
-  if (LPI->isCatch(I)) {
-// Check if the catch value has the ObjC prefix.
-if (llvm::GlobalVariable *GV = dyn_cast(Val))
-  // ObjC EH selector entries are always global variables with
-  // names starting like this.
-  if (GV->getName().startswith("OBJC_EHTYPE"))
-return false;
-  } else {
-// Check if any of the filter values have the ObjC prefix.
-llvm::Constant *CVal = cast(Val);
-for (llvm::User::op_iterator
-   II = CVal->op_begin(), IE = CVal->op_end(); II != IE; ++II) {
-  if (llvm::GlobalVariable *GV =
-  cast((*II)->stripPointerCasts()))
-// ObjC EH selector entries are always global variables with
-// names starting like this.
-if (GV->getName().startswith("OBJC_EHTYPE"))
-  return false;
-}
-  }
+for (auto BB = F->begin(), E = F->end(); BB != E; ++BB) {
+  if (BB->isLandingPad())
+if (!LandingPadHasOnlyCXXUses(BB->getLandingPadInst()))
+  return false;
 }
   }
 

Added: cfe/trunk/test/CodeGenObjCXX/exception-cxx.mm
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenObjCXX/exception-cxx.mm?rev=247421&view=auto
==
--- cfe/trunk/test/CodeGenObjCXX/exception-cxx.mm (added)
+++ cfe/trunk/test/CodeGenObjCXX/exception-cxx.mm Fri Sep 11 10:40:05 2015
@@ -0,0 +1,13 @@
+// RUN: %clang_cc1 -x objective-c++ -triple x86_64-apple-darwin10 -emit-llvm 
-fcxx-exceptions -fexceptions -fobjc-exceptions -o - %s | FileCheck %s
+
+// rdar://problem/22155434
+namespace test0 {
+  void foo() {
+   

Re: [PATCH] D12743: [CodeGen] Teach SimplifyPersonality about the updated LandingPadInst

[Vedant Kumar via cfe-commits]

vsk accepted this revision.
vsk added a reviewer: vsk.
vsk marked an inline comment as done.
vsk added a comment.
This revision is now accepted and ready to land.

Committed r247421


http://reviews.llvm.org/D12743



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

Re: [PATCH] D12652: [Static Analyzer] Lambda support.

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

xazax.hun added inline comments.


Comment at: include/clang/StaticAnalyzer/Core/AnalyzerOptions.h:515-517
@@ -511,1 +514,5 @@
 
+  /// Returns true if lambdas should be inlined. Otherwise a sink node will be
+  /// generated each time a LambdaExpr is visited.
+  bool shouldInlineLambdas();
+

jordan_rose wrote:
> "inline" is kind of a misnomer, since we may not actually inline lambdas. I 
> would have suggested "model lambdas" or "lambda support".
Even when this configuration option is set to false, the body of the lambda is 
analyzed as a top level function. For this reason I think the "lambda support" 
might be a misnomer too. What do you think?


Comment at: lib/StaticAnalyzer/Core/MemRegion.cpp:740-741
@@ -739,3 +739,4 @@
   const DeclContext *DC,
-  const VarDecl *VD) {
+  const VarDecl *VD,
+  MemRegionManager *Mmgr) {
   while (LC) {

jordan_rose wrote:
> Why the extra parameter?
This is just a leftover from code evolution, thank you for spotting this.


http://reviews.llvm.org/D12652



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

Re: [PATCH] D12743: [CodeGen] Teach SimplifyPersonality about the updated LandingPadInst

[Reid Kleckner via cfe-commits]

rnk added a subscriber: rnk.
rnk added a comment.

I'm confused. I thought SimplifyPersonalityFunction was an optimization, but 
somehow it caused link failures? Why do you think this was an ABI break?



Comment at: test/CodeGenObjCXX/exception-cxx.mm:8
@@ +7,3 @@
+  throw 0;
+} catch (...) {
+  return;

Don't you want to test the 'catch (int e)' case? That introduces interesting 
uses of the selector that catch-all doesn't have.


http://reviews.llvm.org/D12743



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

r247423 - [Static Analyzer] Minor cleanups for the nullability checker.

[Gabor Horvath via cfe-commits]

Author: xazax
Date: Fri Sep 11 11:29:05 2015
New Revision: 247423

URL: http://llvm.org/viewvc/llvm-project?rev=247423&view=rev
Log:
[Static Analyzer] Minor cleanups for the nullability checker.

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


Modified:
cfe/trunk/lib/StaticAnalyzer/Checkers/NullabilityChecker.cpp

Modified: cfe/trunk/lib/StaticAnalyzer/Checkers/NullabilityChecker.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Checkers/NullabilityChecker.cpp?rev=247423&r1=247422&r2=247423&view=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Checkers/NullabilityChecker.cpp (original)
+++ cfe/trunk/lib/StaticAnalyzer/Checkers/NullabilityChecker.cpp Fri Sep 11 
11:29:05 2015
@@ -58,12 +58,12 @@ enum class Nullability : char {
 /// the nullability of the receiver or the nullability of the return type of 
the
 /// method, depending on which is more nullable. Contradicted is considered to
 /// be the most nullable, to avoid false positive results.
-static Nullability getMostNullable(Nullability Lhs, Nullability Rhs) {
+Nullability getMostNullable(Nullability Lhs, Nullability Rhs) {
   return static_cast(
   std::min(static_cast(Lhs), static_cast(Rhs)));
 }
 
-static const char *getNullabilityString(Nullability Nullab) {
+const char *getNullabilityString(Nullability Nullab) {
   switch (Nullab) {
   case Nullability::Contradicted:
 return "contradicted";
@@ -74,7 +74,7 @@ static const char *getNullabilityString(
   case Nullability::Nonnull:
 return "nonnull";
   }
-  assert(false);
+  llvm_unreachable("Unexpected enumeration.");
   return "";
 }
 
@@ -89,19 +89,17 @@ enum class ErrorKind : int {
   NullablePassedToNonnull
 };
 
-const char *ErrorMessages[] = {"Null pointer is assigned to a pointer which "
-   "has _Nonnull type",
-   "Null pointer is passed to a parameter which is 
"
-   "marked as _Nonnull",
-   "Null pointer is returned from a function that "
-   "has _Nonnull return type",
-   "Nullable pointer is assigned to a pointer "
-   "which has _Nonnull type",
-   "Nullable pointer is returned from a function "
-   "that has _Nonnull return type",
-   "Nullable pointer is dereferenced",
-   "Nullable pointer is passed to a parameter "
-   "which is marked as _Nonnull"};
+const char *const ErrorMessages[] = {
+"Null is assigned to a pointer which is expected to have non-null value",
+"Null passed to a callee that requires a non-null argument",
+"Null is returned from a function that is expected to return a non-null "
+"value",
+"Nullable pointer is assigned to a pointer which is expected to have "
+"non-null value",
+"Nullable pointer is returned from a function that is expected to return a 
"
+"non-null value",
+"Nullable pointer is dereferenced",
+"Nullable pointer is passed to a calle that requires a non-null argument"};
 
 class NullabilityChecker
 : public Checker,
@@ -176,7 +174,6 @@ private:
 if (!BT)
   BT.reset(new BugType(this, "Nullability", "Memory error"));
 const char *Msg = ErrorMessages[static_cast(Error)];
-assert(Msg);
 std::unique_ptr R(new BugReport(*BT, Msg, N));
 if (Region) {
   R->markInteresting(Region);
@@ -262,7 +259,7 @@ static const SymbolicRegion *getTrackReg
   if (CheckSuperRegion) {
 if (auto FieldReg = Region->getAs())
   return dyn_cast(FieldReg->getSuperRegion());
-else if (auto ElementReg = Region->getAs())
+if (auto ElementReg = Region->getAs())
   return dyn_cast(ElementReg->getSuperRegion());
   }
 
@@ -272,12 +269,12 @@ static const SymbolicRegion *getTrackReg
 PathDiagnosticPiece *NullabilityChecker::NullabilityBugVisitor::VisitNode(
 const ExplodedNode *N, const ExplodedNode *PrevN, BugReporterContext &BRC,
 BugReport &BR) {
-  ProgramStateRef state = N->getState();
-  ProgramStateRef statePrev = PrevN->getState();
+  ProgramStateRef State = N->getState();
+  ProgramStateRef StatePrev = PrevN->getState();
 
-  const NullabilityState *TrackedNullab = state->get(Region);
+  const NullabilityState *TrackedNullab = State->get(Region);
   const NullabilityState *TrackedNullabPrev =
-  statePrev->get(Region);
+  StatePrev->get(Region);
   if (!TrackedNullab)
 return nullptr;
 
@@ -645,34 +642,31 @@ void NullabilityChecker::checkPostCall(c
 
 static Nullability getReceiverNullability(const ObjCMethodCall &M,
   ProgramStateRef State) {
-  Nullability RetNullability = Nullability::Unspecified;
   if (M.isReceiverSelfOrSuper()) {
 // For super and super class receivers

Re: [PATCH] D12619: [Static Analyzer] Minor cleanups for the nullability checker.

[Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL247423: [Static Analyzer] Minor cleanups for the nullability 
checker. (authored by xazax).

Changed prior to commit:
  http://reviews.llvm.org/D12619?vs=34458&id=34553#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D12619

Files:
  cfe/trunk/lib/StaticAnalyzer/Checkers/NullabilityChecker.cpp

Index: cfe/trunk/lib/StaticAnalyzer/Checkers/NullabilityChecker.cpp
===
--- cfe/trunk/lib/StaticAnalyzer/Checkers/NullabilityChecker.cpp
+++ cfe/trunk/lib/StaticAnalyzer/Checkers/NullabilityChecker.cpp
@@ -58,12 +58,12 @@
 /// the nullability of the receiver or the nullability of the return type of the
 /// method, depending on which is more nullable. Contradicted is considered to
 /// be the most nullable, to avoid false positive results.
-static Nullability getMostNullable(Nullability Lhs, Nullability Rhs) {
+Nullability getMostNullable(Nullability Lhs, Nullability Rhs) {
   return static_cast(
   std::min(static_cast(Lhs), static_cast(Rhs)));
 }
 
-static const char *getNullabilityString(Nullability Nullab) {
+const char *getNullabilityString(Nullability Nullab) {
   switch (Nullab) {
   case Nullability::Contradicted:
 return "contradicted";
@@ -74,7 +74,7 @@
   case Nullability::Nonnull:
 return "nonnull";
   }
-  assert(false);
+  llvm_unreachable("Unexpected enumeration.");
   return "";
 }
 
@@ -89,19 +89,17 @@
   NullablePassedToNonnull
 };
 
-const char *ErrorMessages[] = {"Null pointer is assigned to a pointer which "
-   "has _Nonnull type",
-   "Null pointer is passed to a parameter which is "
-   "marked as _Nonnull",
-   "Null pointer is returned from a function that "
-   "has _Nonnull return type",
-   "Nullable pointer is assigned to a pointer "
-   "which has _Nonnull type",
-   "Nullable pointer is returned from a function "
-   "that has _Nonnull return type",
-   "Nullable pointer is dereferenced",
-   "Nullable pointer is passed to a parameter "
-   "which is marked as _Nonnull"};
+const char *const ErrorMessages[] = {
+"Null is assigned to a pointer which is expected to have non-null value",
+"Null passed to a callee that requires a non-null argument",
+"Null is returned from a function that is expected to return a non-null "
+"value",
+"Nullable pointer is assigned to a pointer which is expected to have "
+"non-null value",
+"Nullable pointer is returned from a function that is expected to return a "
+"non-null value",
+"Nullable pointer is dereferenced",
+"Nullable pointer is passed to a calle that requires a non-null argument"};
 
 class NullabilityChecker
 : public Checker,
@@ -176,7 +174,6 @@
 if (!BT)
   BT.reset(new BugType(this, "Nullability", "Memory error"));
 const char *Msg = ErrorMessages[static_cast(Error)];
-assert(Msg);
 std::unique_ptr R(new BugReport(*BT, Msg, N));
 if (Region) {
   R->markInteresting(Region);
@@ -262,7 +259,7 @@
   if (CheckSuperRegion) {
 if (auto FieldReg = Region->getAs())
   return dyn_cast(FieldReg->getSuperRegion());
-else if (auto ElementReg = Region->getAs())
+if (auto ElementReg = Region->getAs())
   return dyn_cast(ElementReg->getSuperRegion());
   }
 
@@ -272,12 +269,12 @@
 PathDiagnosticPiece *NullabilityChecker::NullabilityBugVisitor::VisitNode(
 const ExplodedNode *N, const ExplodedNode *PrevN, BugReporterContext &BRC,
 BugReport &BR) {
-  ProgramStateRef state = N->getState();
-  ProgramStateRef statePrev = PrevN->getState();
+  ProgramStateRef State = N->getState();
+  ProgramStateRef StatePrev = PrevN->getState();
 
-  const NullabilityState *TrackedNullab = state->get(Region);
+  const NullabilityState *TrackedNullab = State->get(Region);
   const NullabilityState *TrackedNullabPrev =
-  statePrev->get(Region);
+  StatePrev->get(Region);
   if (!TrackedNullab)
 return nullptr;
 
@@ -645,34 +642,31 @@
 
 static Nullability getReceiverNullability(const ObjCMethodCall &M,
   ProgramStateRef State) {
-  Nullability RetNullability = Nullability::Unspecified;
   if (M.isReceiverSelfOrSuper()) {
 // For super and super class receivers we assume that the receiver is
 // nonnull.
-RetNullability = Nullability::Nonnull;
-  } else {
-// Otherwise look up nullability in the state.
-SVal Receiver = M.getReceiverSVal();
-auto ValueRegionSVal = Receiver.getAs();
-if (ValueRegionSVal) {
-  const MemRegion *SelfRegion = ValueRegionSVal->getRegion();
-  assert(SelfRegion);

r247424 - [SEH] Port __try / __leave test to new IR

[Reid Kleckner via cfe-commits]

Author: rnk
Date: Fri Sep 11 11:29:27 2015
New Revision: 247424

URL: http://llvm.org/viewvc/llvm-project?rev=247424&view=rev
Log:
[SEH] Port __try / __leave test to new IR

It turns out that the IR we already generate for __leave is fine, so no
code changes were needed.

Added:
cfe/trunk/test/CodeGen/exceptions-seh-leave-new.c

Added: cfe/trunk/test/CodeGen/exceptions-seh-leave-new.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/exceptions-seh-leave-new.c?rev=247424&view=auto
==
--- cfe/trunk/test/CodeGen/exceptions-seh-leave-new.c (added)
+++ cfe/trunk/test/CodeGen/exceptions-seh-leave-new.c Fri Sep 11 11:29:27 2015
@@ -0,0 +1,347 @@
+// RUN: %clang_cc1 %s -triple x86_64-pc-win32 -fms-extensions -fnew-ms-eh 
-emit-llvm -o - | FileCheck %s
+
+void g(void);
+
+//
+// __leave with __except
+
+// Nothing in the __try block can trap, so __try.cont isn't created.
+int __leave_with___except_simple() {
+  int myres = 0;
+  __try {
+myres = 15;
+__leave;
+myres = 23;
+  } __except (1) {
+return 0;
+  }
+  return 1;
+}
+// CHECK-LABEL: define i32 @__leave_with___except_simple()
+// CHECK: store i32 15, i32* %myres
+// CHECK-NEXT: br label %[[tryleave:[^ ]*]]
+// CHECK-NOT: store i32 23
+// CHECK: [[tryleave]]
+// CHECK-NEXT: ret i32 1
+
+
+// The "normal" case.
+int __leave_with___except() {
+  int myres = 0;
+  __try {
+g();
+__leave;
+myres = 23;
+  } __except (1) {
+return 0;
+  }
+  return 1;
+}
+// CHECK-LABEL: define i32 @__leave_with___except()
+// CHECK: invoke void @g()
+// CHECK-NEXT:   to label %[[cont:.*]] unwind label %{{.*}}
+// For __excepts, instead of an explicit __try.__leave label, we could use
+// use invoke.cont as __leave jump target instead.  However, not doing this
+// keeps the CodeGen code simpler, __leave is very rare, and SimplifyCFG will
+// simplify this anyways.
+// CHECK: [[cont]]
+// CHECK-NEXT: br label %[[tryleave:[^ ]*]]
+// CHECK-NOT: store i32 23
+// CHECK: [[tryleave]]
+// CHECK-NEXT: br label %
+
+
+//
+// __leave with __finally
+
+void abort(void) __attribute__((noreturn));
+
+// Nothing in the __try block can trap, so __finally.cont and friends aren't
+// created.
+int __leave_with___finally_simple() {
+  int myres = 0;
+  __try {
+myres = 15;
+__leave;
+myres = 23;
+  } __finally {
+return 0;
+  }
+  return 1;
+}
+// CHECK-LABEL: define i32 @__leave_with___finally_simple()
+// CHECK: store i32 15, i32* %myres
+// CHECK-NEXT: br label %[[tryleave:[^ ]*]]
+// CHECK-NOT: store i32 23
+// CHECK: [[tryleave]]
+// CHECK-NEXT: %[[fp:[^ ]*]] = call i8* @llvm.localaddress()
+// CHECK-NEXT: call void @"\01?fin$0@0@__leave_with___finally_simple@@"(i8 0, 
i8* %[[fp]])
+
+// __finally block doesn't return, __finally.cont doesn't exist.
+int __leave_with___finally_noreturn() {
+  int myres = 0;
+  __try {
+myres = 15;
+__leave;
+myres = 23;
+  } __finally {
+abort();
+  }
+  return 1;
+}
+// CHECK-LABEL: define i32 @__leave_with___finally_noreturn()
+// CHECK: store i32 15, i32* %myres
+// CHECK-NEXT: br label %[[tryleave:[^ ]*]]
+// CHECK-NOT: store i32 23
+// CHECK: [[tryleave]]
+// CHECK-NEXT: %[[fp:[^ ]*]] = call i8* @llvm.localaddress()
+// CHECK-NEXT: call void @"\01?fin$0@0@__leave_with___finally_noreturn@@"(i8 
0, i8* %[[fp]])
+
+// The "normal" case.
+int __leave_with___finally() {
+  int myres = 0;
+  __try {
+g();
+__leave;
+myres = 23;
+  } __finally {
+return 0;
+  }
+  return 1;
+}
+// CHECK-LABEL: define i32 @__leave_with___finally()
+// CHECK: invoke void @g()
+// CHECK-NEXT:   to label %[[cont:.*]] unwind label %{{.*}}
+// For __finally, there needs to be an explicit __try.__leave, because
+// abnormal.termination.slot needs to be set there.
+// CHECK: [[cont]]
+// CHECK-NEXT: br label %[[tryleave:[^ ]*]]
+// CHECK-NOT: store i32 23
+// CHECK: [[tryleave]]
+// CHECK-NEXT: %[[fp:[^ ]*]] = call i8* @llvm.localaddress()
+// CHECK-NEXT: call void @"\01?fin$0@0@__leave_with___finally@@"(i8 0, i8* 
%[[fp]])
+
+
+//
+// Mixed, nested cases.
+
+int nested___except___finally() {
+  int myres = 0;
+  __try {
+__try {
+  g();
+} __finally {
+  g();
+  __leave;  // Refers to the outer __try, not the __finally!
+  myres = 23;
+  return 0;
+}
+
+myres = 51;
+  } __except (1) {
+  }
+  return 1;
+}
+// CHECK-LABEL: define i32 @nested___except___finally()
+
+// CHECK-LABEL: invoke void @g()
+// CHECK-NEXT:   to label %[[g1_cont1:.*]] unwind label %[[g1_lpad:.*]]
+
+// CHECK: [[g1_cont1]]
+// CHECK-NEXT: %[[fp:[^ ]*]] = call i8* @llvm.localaddress()
+// CHECK-NEXT: invoke void @"\01?fin$0@0@nested___except___finally@@"(i8 0, 
i8* %[[fp]])

Re: PATCH: Expose the 'file' that is associated with a compile database command

[Argyrios Kyrtzidis via cfe-commits]

> On Sep 11, 2015, at 12:21 AM, Manuel Klimek  wrote:
> 
> On Thu, Sep 10, 2015 at 8:36 PM Argyrios Kyrtzidis  > wrote:
>> On Sep 10, 2015, at 1:48 AM, Manuel Klimek > > wrote:
>> 
>> @@ -179,11 +185,13 @@ public:
>>/// \param Directory The base directory used in the 
>> FixedCompilationDatabase.
>>static FixedCompilationDatabase *loadFromCommandLine(int &Argc,
>> const char *const 
>> *Argv,
>> -   Twine Directory = 
>> ".");
>> +   Twine Directory = 
>> ".",
>> +   Twine File = 
>> Twine());
>>  
>> A fixed compilation database returns the same command lines for all files, 
>> thus having a file in the function seems strange.
> 
> Ah ok, thanks for clarifying.
> 
>> 
>> What exactly is the use case? So far, the compilation database has been 
>> designed for 2 use cases:
>> 1. for a file, get the compile commands; the user already knows the file, no 
>> need to get the file
>> 2. get all compile commands; for that, we have the getAllFiles() method, so 
>> a user can get all known files (for compilation databases that support 
>> that), and then get the compile command line.
> 
> It’s #2, I want to get all compile commands. But it seems really strange to 
> me that the ‘file’ starts as a property of the compile command in the json 
> file but then it gets dropped and I need to do work to re-associate the files 
> with the compile commands again.
> 
> The JSON file format is one possible implementation for the 
> compilation-database interface. The FixedCompilationDatabase is another one, 
> that doesn't have any information on files.
>  
> I need to get a list of all the files and then for each one do a lookup to 
> get the associated commands. I then have to maintain this association myself, 
> passing a command along with its file separately or the structure that keeps 
> track of the association.
> 
> It seems simpler to me to include the file that was associated with the 
> command (if the compilation database supports that) along with the command, 
> is there a downside I’m missing ?
> 
> Well, to me, it's a design question - if it also makes sense to have a 
> CompileCommand without a file associated with it, putting the file in there, 
> while convenient, is a design smell.

It can be optional to communicate that it may not be there. Note that, IMO, 
having multiple files and compile commands for them is the overwhelmingly most 
common use of the compilation database.

> That said, I'm happy to be convinced that I'm wrong :) I guess I don't see 
> yet that keeping track of the files outside is more than one line of extra 
> code.

Not sure what one line this is, I have to declare a map and then populate it, 
no ? And to do it in c-index-test it would take way more that one line.
But it is also beyond populating a map, this has an effect on APIs using a 
CompileCommand. For example:

void doSomethingWithCompileCommand(const CompileCommand &cmd); 

Ah it would be useful to know the file that this command was associated with:

void doSomethingWithCompileCommand(const CompileCommand &cmd, StringRef 
filename); 

What do I have now ? This is a function taking a command and a string for the 
filename separately.
Is this flexibility useful ? Does it make sense to pass any filename there ? No 
there’s only one filename that the command was associated with so this 
‘flexibility’ only increases the complexity of using the function. And this can 
propagate to other function’s callees.
This seems like a design smell to me.

> 
> Cheers,
> /Manuel
>  
> 
>> 
>> Thoughts?
>> /Manuel
>> 
>> On Wed, Sep 9, 2015 at 9:36 PM Argyrios Kyrtzidis > > wrote:
>> Hi,
>> 
>> The attached patch exposes the ‘file’ entry in a compilation database 
>> command, via the CompileCommand structure.

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

Re: [PATCH] D12767: [Static Analyzer] Properly clean up the dynamic type information for dead regions.

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

xazax.hun updated this revision to Diff 34554.
xazax.hun added a comment.

- Addressed the comments.


http://reviews.llvm.org/D12767

Files:
  include/clang/StaticAnalyzer/Core/PathSensitive/DynamicTypeMap.h
  include/clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h
  lib/StaticAnalyzer/Checkers/DynamicTypePropagation.cpp
  lib/StaticAnalyzer/Core/CMakeLists.txt
  lib/StaticAnalyzer/Core/CallEvent.cpp
  lib/StaticAnalyzer/Core/DynamicTypeMap.cpp
  lib/StaticAnalyzer/Core/ProgramState.cpp

Index: lib/StaticAnalyzer/Core/ProgramState.cpp
===
--- lib/StaticAnalyzer/Core/ProgramState.cpp
+++ lib/StaticAnalyzer/Core/ProgramState.cpp
@@ -752,36 +752,3 @@
   return Tainted;
 }
 
-/// The GDM component containing the dynamic type info. This is a map from a
-/// symbol to its most likely type.
-REGISTER_TRAIT_WITH_PROGRAMSTATE(DynamicTypeMap,
- CLANG_ENTO_PROGRAMSTATE_MAP(const MemRegion *,
- DynamicTypeInfo))
-
-DynamicTypeInfo ProgramState::getDynamicTypeInfo(const MemRegion *Reg) const {
-  Reg = Reg->StripCasts();
-
-  // Look up the dynamic type in the GDM.
-  const DynamicTypeInfo *GDMType = get(Reg);
-  if (GDMType)
-return *GDMType;
-
-  // Otherwise, fall back to what we know about the region.
-  if (const TypedRegion *TR = dyn_cast(Reg))
-return DynamicTypeInfo(TR->getLocationType(), /*CanBeSubclass=*/false);
-
-  if (const SymbolicRegion *SR = dyn_cast(Reg)) {
-SymbolRef Sym = SR->getSymbol();
-return DynamicTypeInfo(Sym->getType());
-  }
-
-  return DynamicTypeInfo();
-}
-
-ProgramStateRef ProgramState::setDynamicTypeInfo(const MemRegion *Reg,
- DynamicTypeInfo NewTy) const {
-  Reg = Reg->StripCasts();
-  ProgramStateRef NewState = set(Reg, NewTy);
-  assert(NewState);
-  return NewState;
-}
Index: lib/StaticAnalyzer/Core/DynamicTypeMap.cpp
===
--- /dev/null
+++ lib/StaticAnalyzer/Core/DynamicTypeMap.cpp
@@ -0,0 +1,51 @@
+//==- DynamicTypeMap.cpp - Dynamic Type Info related APIs --*- C++ -*-//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+//
+//  This file defines APIs that track and query dynamic type information. This
+//  information can be used to devirtualize calls during the symbolic exection
+//  or do type checking.
+//
+//===--===//
+
+#include "clang/StaticAnalyzer/Core/PathSensitive/DynamicTypeMap.h"
+
+namespace clang {
+namespace ento {
+
+DynamicTypeInfo getDynamicTypeInfo(ProgramStateRef State,
+   const MemRegion *Reg) {
+  Reg = Reg->StripCasts();
+
+  // Look up the dynamic type in the GDM.
+  const DynamicTypeInfo *GDMType = State->get(Reg);
+  if (GDMType)
+return *GDMType;
+
+  // Otherwise, fall back to what we know about the region.
+  if (const TypedRegion *TR = dyn_cast(Reg))
+return DynamicTypeInfo(TR->getLocationType(), /*CanBeSubclass=*/false);
+
+  if (const SymbolicRegion *SR = dyn_cast(Reg)) {
+SymbolRef Sym = SR->getSymbol();
+return DynamicTypeInfo(Sym->getType());
+  }
+
+  return DynamicTypeInfo();
+}
+
+ProgramStateRef setDynamicTypeInfo(ProgramStateRef State, const MemRegion *Reg,
+   DynamicTypeInfo NewTy) {
+  Reg = Reg->StripCasts();
+  ProgramStateRef NewState = State->set(Reg, NewTy);
+  assert(NewState);
+  return NewState;
+}
+
+} // namespace ento
+} // namespace clang
Index: lib/StaticAnalyzer/Core/CallEvent.cpp
===
--- lib/StaticAnalyzer/Core/CallEvent.cpp
+++ lib/StaticAnalyzer/Core/CallEvent.cpp
@@ -17,6 +17,7 @@
 #include "clang/AST/ParentMap.h"
 #include "clang/Analysis/ProgramPoint.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/CheckerContext.h"
+#include "clang/StaticAnalyzer/Core/PathSensitive/DynamicTypeMap.h"
 #include "llvm/ADT/SmallSet.h"
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/Support/raw_ostream.h"
@@ -435,7 +436,7 @@
 return RuntimeDefinition();
 
   // Do we know anything about the type of 'this'?
-  DynamicTypeInfo DynType = getState()->getDynamicTypeInfo(R);
+  DynamicTypeInfo DynType = getDynamicTypeInfo(getState(), R);
   if (!DynType.isValid())
 return RuntimeDefinition();
 
@@ -800,7 +801,7 @@
   if (!Receiver)
 return RuntimeDefinition();
 
-  DynamicTypeInfo DTI = getState()->getDynamicTypeInfo(Receiver);
+  DynamicTypeInfo DTI = getDynamicTypeInfo(getState(), Receiver);
   QualType DynType = DTI.getType();
   CanBeSubClassed = DTI.canBeASubClass();
   Rece

Re: [PATCH] D12767: [Static Analyzer] Properly clean up the dynamic type information for dead regions.

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

xazax.hun marked 2 inline comments as done.
xazax.hun added a comment.

http://reviews.llvm.org/D12767



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

r247426 - [Static Analyzer] Lambda support.

[Gabor Horvath via cfe-commits]

Author: xazax
Date: Fri Sep 11 11:55:01 2015
New Revision: 247426

URL: http://llvm.org/viewvc/llvm-project?rev=247426&view=rev
Log:
[Static Analyzer] Lambda support.

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


Added:
cfe/trunk/test/Analysis/lambda-notes.cpp
Modified:
cfe/trunk/include/clang/StaticAnalyzer/Core/AnalyzerOptions.h
cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h
cfe/trunk/lib/StaticAnalyzer/Core/AnalyzerOptions.cpp
cfe/trunk/lib/StaticAnalyzer/Core/ExprEngine.cpp
cfe/trunk/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
cfe/trunk/lib/StaticAnalyzer/Core/MemRegion.cpp
cfe/trunk/test/Analysis/dead-stores.cpp
cfe/trunk/test/Analysis/lambdas.cpp
cfe/trunk/test/Analysis/temporaries.cpp

Modified: cfe/trunk/include/clang/StaticAnalyzer/Core/AnalyzerOptions.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/StaticAnalyzer/Core/AnalyzerOptions.h?rev=247426&r1=247425&r2=247426&view=diff
==
--- cfe/trunk/include/clang/StaticAnalyzer/Core/AnalyzerOptions.h (original)
+++ cfe/trunk/include/clang/StaticAnalyzer/Core/AnalyzerOptions.h Fri Sep 11 
11:55:01 2015
@@ -256,6 +256,9 @@ private:
   /// \sa getMaxNodesPerTopLevelFunction
   Optional MaxNodesPerTopLevelFunction;
 
+  /// \sa shouldInlineLambdas
+  Optional InlineLambdas;
+
   /// A helper function that retrieves option for a given full-qualified
   /// checker name.
   /// Options for checkers can be specified via 'analyzer-config' command-line
@@ -509,6 +512,10 @@ public:
   /// This is controlled by the 'max-nodes' config option.
   unsigned getMaxNodesPerTopLevelFunction();
 
+  /// Returns true if lambdas should be inlined. Otherwise a sink node will be
+  /// generated each time a LambdaExpr is visited.
+  bool shouldInlineLambdas();
+
 public:
   AnalyzerOptions() :
 AnalysisStoreOpt(RegionStoreModel),

Modified: cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h?rev=247426&r1=247425&r2=247426&view=diff
==
--- cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h 
(original)
+++ cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h Fri 
Sep 11 11:55:01 2015
@@ -341,6 +341,10 @@ public:
   void VisitBlockExpr(const BlockExpr *BE, ExplodedNode *Pred, 
   ExplodedNodeSet &Dst);
 
+  /// VisitLambdaExpr - Transfer function logic for LambdaExprs.
+  void VisitLambdaExpr(const LambdaExpr *LE, ExplodedNode *Pred, 
+   ExplodedNodeSet &Dst);
+
   /// VisitBinaryOperator - Transfer function logic for binary operators.
   void VisitBinaryOperator(const BinaryOperator* B, ExplodedNode *Pred, 
ExplodedNodeSet &Dst);

Modified: cfe/trunk/lib/StaticAnalyzer/Core/AnalyzerOptions.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Core/AnalyzerOptions.cpp?rev=247426&r1=247425&r2=247426&view=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Core/AnalyzerOptions.cpp (original)
+++ cfe/trunk/lib/StaticAnalyzer/Core/AnalyzerOptions.cpp Fri Sep 11 11:55:01 
2015
@@ -325,3 +325,7 @@ bool AnalyzerOptions::shouldPrunePaths()
 bool AnalyzerOptions::shouldConditionalizeStaticInitializers() {
   return getBooleanOption("cfg-conditional-static-initializers", true);
 }
+
+bool AnalyzerOptions::shouldInlineLambdas() {
+  return getBooleanOption("inline-lambdas", /*Default=*/true);
+}

Modified: cfe/trunk/lib/StaticAnalyzer/Core/ExprEngine.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Core/ExprEngine.cpp?rev=247426&r1=247425&r2=247426&view=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Core/ExprEngine.cpp (original)
+++ cfe/trunk/lib/StaticAnalyzer/Core/ExprEngine.cpp Fri Sep 11 11:55:01 2015
@@ -769,7 +769,6 @@ void ExprEngine::Visit(const Stmt *S, Ex
 case Stmt::SEHTryStmtClass:
 case Stmt::SEHExceptStmtClass:
 case Stmt::SEHLeaveStmtClass:
-case Stmt::LambdaExprClass:
 case Stmt::SEHFinallyStmtClass: {
   const ExplodedNode *node = Bldr.generateSink(S, Pred, Pred->getState());
   Engine.addAbortedBlock(node, currBldrCtx->getBlock());
@@ -1013,6 +1012,17 @@ void ExprEngine::Visit(const Stmt *S, Ex
   Bldr.addNodes(Dst);
   break;
 
+case Stmt::LambdaExprClass:
+  if (AMgr.options.shouldInlineLambdas()) {
+Bldr.takeNodes(Pred);
+VisitLambdaExpr(cast(S), Pred, Dst);
+Bldr.addNodes(Dst);
+  } else {
+const ExplodedNode *node = Bldr.generateSink(S, Pred, 
Pred->getState());
+Engine.addAbortedBlock(node, currBldrCtx->getBlock());
+

Re: [PATCH] D12652: [Static Analyzer] Lambda support.

[Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL247426: [Static Analyzer] Lambda support. (authored by 
xazax).

Changed prior to commit:
  http://reviews.llvm.org/D12652?vs=34498&id=34555#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D12652

Files:
  cfe/trunk/include/clang/StaticAnalyzer/Core/AnalyzerOptions.h
  cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h
  cfe/trunk/lib/StaticAnalyzer/Core/AnalyzerOptions.cpp
  cfe/trunk/lib/StaticAnalyzer/Core/ExprEngine.cpp
  cfe/trunk/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
  cfe/trunk/lib/StaticAnalyzer/Core/MemRegion.cpp
  cfe/trunk/test/Analysis/dead-stores.cpp
  cfe/trunk/test/Analysis/lambda-notes.cpp
  cfe/trunk/test/Analysis/lambdas.cpp
  cfe/trunk/test/Analysis/temporaries.cpp

Index: cfe/trunk/include/clang/StaticAnalyzer/Core/AnalyzerOptions.h
===
--- cfe/trunk/include/clang/StaticAnalyzer/Core/AnalyzerOptions.h
+++ cfe/trunk/include/clang/StaticAnalyzer/Core/AnalyzerOptions.h
@@ -256,6 +256,9 @@
   /// \sa getMaxNodesPerTopLevelFunction
   Optional MaxNodesPerTopLevelFunction;
 
+  /// \sa shouldInlineLambdas
+  Optional InlineLambdas;
+
   /// A helper function that retrieves option for a given full-qualified
   /// checker name.
   /// Options for checkers can be specified via 'analyzer-config' command-line
@@ -509,6 +512,10 @@
   /// This is controlled by the 'max-nodes' config option.
   unsigned getMaxNodesPerTopLevelFunction();
 
+  /// Returns true if lambdas should be inlined. Otherwise a sink node will be
+  /// generated each time a LambdaExpr is visited.
+  bool shouldInlineLambdas();
+
 public:
   AnalyzerOptions() :
 AnalysisStoreOpt(RegionStoreModel),
Index: cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h
===
--- cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h
+++ cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h
@@ -341,6 +341,10 @@
   void VisitBlockExpr(const BlockExpr *BE, ExplodedNode *Pred, 
   ExplodedNodeSet &Dst);
 
+  /// VisitLambdaExpr - Transfer function logic for LambdaExprs.
+  void VisitLambdaExpr(const LambdaExpr *LE, ExplodedNode *Pred, 
+   ExplodedNodeSet &Dst);
+
   /// VisitBinaryOperator - Transfer function logic for binary operators.
   void VisitBinaryOperator(const BinaryOperator* B, ExplodedNode *Pred, 
ExplodedNodeSet &Dst);
Index: cfe/trunk/test/Analysis/dead-stores.cpp
===
--- cfe/trunk/test/Analysis/dead-stores.cpp
+++ cfe/trunk/test/Analysis/dead-stores.cpp
@@ -174,3 +174,17 @@
   return radar13213575_testit(5) + radar13213575_testit(3);
 }
 
+//===--===//
+// Dead store checking involving lambdas.
+//===--===//
+
+int basicLambda(int i, int j) {
+  i = 5; // no warning
+  j = 6; // no warning
+  [i] { (void)i; }();
+  [&j] { (void)j; }();
+  i = 2;
+  j = 3;
+  return i + j;
+}
+
Index: cfe/trunk/test/Analysis/lambda-notes.cpp
===
--- cfe/trunk/test/Analysis/lambda-notes.cpp
+++ cfe/trunk/test/Analysis/lambda-notes.cpp
@@ -0,0 +1,204 @@
+// RUN: %clang_cc1 -std=c++11 -fsyntax-only -analyze -analyzer-checker=core -analyzer-config inline-lambdas=true -analyzer-output plist -verify %s -o %t
+// RUN: FileCheck --input-file=%t %s
+
+
+// Diagnostic inside a lambda
+
+void diagnosticFromLambda() {
+  int i = 0;
+  [=] {
+int p = 5/i; // expected-warning{{Division by zero}}
+(void)p;
+  }();
+}
+
+// CHECK:  
+// CHECK:   
+// CHECK:path
+// CHECK:
+// CHECK: 
+// CHECK:  kindcontrol
+// CHECK:  edges
+// CHECK:   
+// CHECK:
+// CHECK: start
+// CHECK:  
+// CHECK:   
+// CHECK:line8
+// CHECK:col3
+// CHECK:file0
+// CHECK:   
+// CHECK:   
+// CHECK:line8
+// CHECK:col5
+// CHECK:file0
+// CHECK:   
+// CHECK:  
+// CHECK: end
+// CHECK:  
+// CHECK:   
+// CHECK:line9
+// CHECK:col3
+// CHECK:file0
+// CHECK:   
+// CHECK:   
+// CHECK:line9
+// CHECK:col3
+// CHECK:file0
+// CHECK:   
+// CHECK:  
+// CHECK:
+// CHECK:   
+// CHECK: 
+// CHECK: 
+// CHECK:  kindevent
+// CHECK:  location
+// CHECK:  
+// CHECK:   line9
+// CHECK:   col3
+// CHECK:   file0
+// CHECK:  
+// CHECK:  ranges
+// CHECK:  
+// CHECK:
+// CHECK: 
+// CHECK:  line9
+// 

Re: [PATCH] D12652: [Static Analyzer] Lambda support.

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

xazax.hun added inline comments.


Comment at: include/clang/StaticAnalyzer/Core/AnalyzerOptions.h:515-517
@@ -511,1 +514,5 @@
 
+  /// Returns true if lambdas should be inlined. Otherwise a sink node will be
+  /// generated each time a LambdaExpr is visited.
+  bool shouldInlineLambdas();
+

xazax.hun wrote:
> jordan_rose wrote:
> > "inline" is kind of a misnomer, since we may not actually inline lambdas. I 
> > would have suggested "model lambdas" or "lambda support".
> Even when this configuration option is set to false, the body of the lambda 
> is analyzed as a top level function. For this reason I think the "lambda 
> support" might be a misnomer too. What do you think?
If we come up with a better name for the option I will address that in a 
separate patch.


Repository:
  rL LLVM

http://reviews.llvm.org/D12652



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

r247430 - [Static Analyzer] Properly clean up the dynamic type information for dead regions.

[Gabor Horvath via cfe-commits]

Author: xazax
Date: Fri Sep 11 12:19:57 2015
New Revision: 247430

URL: http://llvm.org/viewvc/llvm-project?rev=247430&view=rev
Log:
[Static Analyzer] Properly clean up the dynamic type information for dead 
regions.

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


Added:
cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/DynamicTypeMap.h
cfe/trunk/lib/StaticAnalyzer/Core/DynamicTypeMap.cpp
Modified:
cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h
cfe/trunk/lib/StaticAnalyzer/Checkers/DynamicTypePropagation.cpp
cfe/trunk/lib/StaticAnalyzer/Core/CMakeLists.txt
cfe/trunk/lib/StaticAnalyzer/Core/CallEvent.cpp
cfe/trunk/lib/StaticAnalyzer/Core/ProgramState.cpp

Added: 
cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/DynamicTypeMap.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/DynamicTypeMap.h?rev=247430&view=auto
==
--- cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/DynamicTypeMap.h 
(added)
+++ cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/DynamicTypeMap.h 
Fri Sep 11 12:19:57 2015
@@ -0,0 +1,57 @@
+//== DynamicTypeMap.h - Dynamic type map --- -*- C++ 
-*--=//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+//
+//  This file provides APIs for tracking dynamic type information.
+//
+//===--===//
+
+#ifndef LLVM_CLANG_STATICANALYZER_CORE_PATHSENSITIVE_DYNAMICTYPEMAP_H
+#define LLVM_CLANG_STATICANALYZER_CORE_PATHSENSITIVE_DYNAMICTYPEMAP_H
+#include "clang/StaticAnalyzer/Core/BugReporter/PathDiagnostic.h"
+#include "clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h"
+#include "clang/StaticAnalyzer/Core/PathSensitive/ProgramStateTrait.h"
+#include "llvm/ADT/ImmutableMap.h"
+
+namespace clang {
+namespace ento {
+
+/// The GDM component containing the dynamic type info. This is a map from a
+/// symbol to its most likely type.
+struct DynamicTypeMap {};
+typedef llvm::ImmutableMap
+DynamicTypeMapImpl;
+template <>
+struct ProgramStateTrait
+: public ProgramStatePartialTrait {
+  static void *GDMIndex() {
+static int index = 0;
+return &index;
+  }
+};
+
+/// \brief Get dynamic type information for a region.
+DynamicTypeInfo getDynamicTypeInfo(ProgramStateRef State,
+   const MemRegion *Reg);
+
+/// \brief Set dynamic type information of the region; return the new state.
+ProgramStateRef setDynamicTypeInfo(ProgramStateRef State, const MemRegion *Reg,
+   DynamicTypeInfo NewTy);
+
+/// \brief Set dynamic type information of the region; return the new state.
+inline ProgramStateRef setDynamicTypeInfo(ProgramStateRef State,
+  const MemRegion *Reg, QualType NewTy,
+  bool CanBeSubClassed = true) {
+  return setDynamicTypeInfo(State, Reg,
+DynamicTypeInfo(NewTy, CanBeSubClassed));
+}
+
+} // ento
+} // clang
+
+#endif // LLVM_CLANG_STATICANALYZER_CORE_PATHSENSITIVE_DYNAMICTYPEMAP_H

Modified: 
cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h?rev=247430&r1=247429&r2=247430&view=diff
==
--- cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h 
(original)
+++ cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h 
Fri Sep 11 12:19:57 2015
@@ -337,20 +337,6 @@ public:
   bool isTainted(SymbolRef Sym, TaintTagType Kind = TaintTagGeneric) const;
   bool isTainted(const MemRegion *Reg, TaintTagType Kind=TaintTagGeneric) 
const;
 
-  /// \brief Get dynamic type information for a region.
-  DynamicTypeInfo getDynamicTypeInfo(const MemRegion *Reg) const;
-
-  /// \brief Set dynamic type information of the region; return the new state.
-  ProgramStateRef setDynamicTypeInfo(const MemRegion *Reg,
- DynamicTypeInfo NewTy) const;
-
-  /// \brief Set dynamic type information of the region; return the new state.
-  ProgramStateRef setDynamicTypeInfo(const MemRegion *Reg,
- QualType NewTy,
- bool CanBeSubClassed = true) const {
-return setDynamicTypeInfo(Reg, DynamicTypeInfo(NewTy, CanBeSubClassed));
-  }
-
   //==-==//
   // Accessing the Generic Data Map (GDM).
   //==---

Re: [PATCH] D12767: [Static Analyzer] Properly clean up the dynamic type information for dead regions.

[Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL247430: [Static Analyzer] Properly clean up the dynamic type 
information for dead… (authored by xazax).

Changed prior to commit:
  http://reviews.llvm.org/D12767?vs=34554&id=34559#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D12767

Files:
  cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/DynamicTypeMap.h
  cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h
  cfe/trunk/lib/StaticAnalyzer/Checkers/DynamicTypePropagation.cpp
  cfe/trunk/lib/StaticAnalyzer/Core/CMakeLists.txt
  cfe/trunk/lib/StaticAnalyzer/Core/CallEvent.cpp
  cfe/trunk/lib/StaticAnalyzer/Core/DynamicTypeMap.cpp
  cfe/trunk/lib/StaticAnalyzer/Core/ProgramState.cpp

Index: cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/DynamicTypeMap.h
===
--- cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/DynamicTypeMap.h
+++ cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/DynamicTypeMap.h
@@ -0,0 +1,57 @@
+//== DynamicTypeMap.h - Dynamic type map --- -*- C++ -*--=//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+//
+//  This file provides APIs for tracking dynamic type information.
+//
+//===--===//
+
+#ifndef LLVM_CLANG_STATICANALYZER_CORE_PATHSENSITIVE_DYNAMICTYPEMAP_H
+#define LLVM_CLANG_STATICANALYZER_CORE_PATHSENSITIVE_DYNAMICTYPEMAP_H
+#include "clang/StaticAnalyzer/Core/BugReporter/PathDiagnostic.h"
+#include "clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h"
+#include "clang/StaticAnalyzer/Core/PathSensitive/ProgramStateTrait.h"
+#include "llvm/ADT/ImmutableMap.h"
+
+namespace clang {
+namespace ento {
+
+/// The GDM component containing the dynamic type info. This is a map from a
+/// symbol to its most likely type.
+struct DynamicTypeMap {};
+typedef llvm::ImmutableMap
+DynamicTypeMapImpl;
+template <>
+struct ProgramStateTrait
+: public ProgramStatePartialTrait {
+  static void *GDMIndex() {
+static int index = 0;
+return &index;
+  }
+};
+
+/// \brief Get dynamic type information for a region.
+DynamicTypeInfo getDynamicTypeInfo(ProgramStateRef State,
+   const MemRegion *Reg);
+
+/// \brief Set dynamic type information of the region; return the new state.
+ProgramStateRef setDynamicTypeInfo(ProgramStateRef State, const MemRegion *Reg,
+   DynamicTypeInfo NewTy);
+
+/// \brief Set dynamic type information of the region; return the new state.
+inline ProgramStateRef setDynamicTypeInfo(ProgramStateRef State,
+  const MemRegion *Reg, QualType NewTy,
+  bool CanBeSubClassed = true) {
+  return setDynamicTypeInfo(State, Reg,
+DynamicTypeInfo(NewTy, CanBeSubClassed));
+}
+
+} // ento
+} // clang
+
+#endif // LLVM_CLANG_STATICANALYZER_CORE_PATHSENSITIVE_DYNAMICTYPEMAP_H
Index: cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h
===
--- cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h
+++ cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h
@@ -337,20 +337,6 @@
   bool isTainted(SymbolRef Sym, TaintTagType Kind = TaintTagGeneric) const;
   bool isTainted(const MemRegion *Reg, TaintTagType Kind=TaintTagGeneric) const;
 
-  /// \brief Get dynamic type information for a region.
-  DynamicTypeInfo getDynamicTypeInfo(const MemRegion *Reg) const;
-
-  /// \brief Set dynamic type information of the region; return the new state.
-  ProgramStateRef setDynamicTypeInfo(const MemRegion *Reg,
- DynamicTypeInfo NewTy) const;
-
-  /// \brief Set dynamic type information of the region; return the new state.
-  ProgramStateRef setDynamicTypeInfo(const MemRegion *Reg,
- QualType NewTy,
- bool CanBeSubClassed = true) const {
-return setDynamicTypeInfo(Reg, DynamicTypeInfo(NewTy, CanBeSubClassed));
-  }
-
   //==-==//
   // Accessing the Generic Data Map (GDM).
   //==-==//
Index: cfe/trunk/lib/StaticAnalyzer/Core/DynamicTypeMap.cpp
===
--- cfe/trunk/lib/StaticAnalyzer/Core/DynamicTypeMap.cpp
+++ cfe/trunk/lib/StaticAnalyzer/Core/DynamicTypeMap.cpp
@@ -0,0 +1,51 @@
+//==- DynamicTypeMap.cpp - Dynamic Type Info related APIs

r247432 - Module Debugging: Emit forward declarations for types that are defined in

[Adrian Prantl via cfe-commits]

Author: adrian
Date: Fri Sep 11 12:23:08 2015
New Revision: 247432

URL: http://llvm.org/viewvc/llvm-project?rev=247432&view=rev
Log:
Module Debugging: Emit forward declarations for types that are defined in
clang modules, if -dwarf-ext-refs (DebugTypesExtRefs) is specified.

This reimplements r247369 in about a third of the amount of code.
Thanks to David Blaikie pointing this out in post-commit review!

Added:
cfe/trunk/test/Modules/ExtDebugInfo.cpp
cfe/trunk/test/Modules/ExtDebugInfo.m
Modified:
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
cfe/trunk/lib/CodeGen/CGDebugInfo.h

Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=247432&r1=247431&r2=247432&view=diff
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Fri Sep 11 12:23:08 2015
@@ -148,7 +148,9 @@ void CGDebugInfo::setLocation(SourceLoca
 }
 
 llvm::DIScope *CGDebugInfo::getDeclContextDescriptor(const Decl *D) {
-  return getContextDescriptor(cast(D->getDeclContext()), TheCU);
+  llvm::DIScope *Mod = getParentModuleOrNull(D);
+  return getContextDescriptor(cast(D->getDeclContext()),
+  Mod ? Mod : TheCU);
 }
 
 llvm::DIScope *CGDebugInfo::getContextDescriptor(const Decl *Context,
@@ -1448,6 +1450,9 @@ void CGDebugInfo::completeRequiredType(c
 if (CXXDecl->isDynamicClass())
   return;
 
+  if (DebugTypeExtRefs && RD->isFromASTFile())
+return;
+
   QualType Ty = CGM.getContext().getRecordType(RD);
   llvm::DIType *T = getTypeOrNull(Ty);
   if (T && T->isForwardDecl())
@@ -1478,8 +1483,19 @@ static bool hasExplicitMemberDefinition(
 }
 
 static bool shouldOmitDefinition(CodeGenOptions::DebugInfoKind DebugKind,
+ bool DebugTypeExtRefs,
  const RecordDecl *RD,
  const LangOptions &LangOpts) {
+  // Does the type exist in an imported clang module?
+  if (DebugTypeExtRefs && RD->isFromASTFile()) {
+if (auto *CTSD = dyn_cast(RD))
+  if (CTSD->isExplicitInstantiationOrSpecialization())
+// We may not assume that this type made it into the module.
+return true;
+if (RD->getDefinition())
+  return true;
+  }
+
   if (DebugKind > CodeGenOptions::LimitedDebugInfo)
 return false;
 
@@ -1513,7 +1529,8 @@ static bool shouldOmitDefinition(CodeGen
 llvm::DIType *CGDebugInfo::CreateType(const RecordType *Ty) {
   RecordDecl *RD = Ty->getDecl();
   llvm::DIType *T = cast_or_null(getTypeOrNull(QualType(Ty, 0)));
-  if (T || shouldOmitDefinition(DebugKind, RD, CGM.getLangOpts())) {
+  if (T || shouldOmitDefinition(DebugKind, DebugTypeExtRefs, RD,
+CGM.getLangOpts())) {
 if (!T)
   T = getOrCreateRecordFwdDecl(Ty, getDeclContextDescriptor(RD));
 return T;
@@ -1616,6 +1633,12 @@ llvm::DIType *CGDebugInfo::CreateType(co
   if (!ID)
 return nullptr;
 
+  // Return a forward declaration if this type was imported from a clang 
module.
+  if (DebugTypeExtRefs && ID->isFromASTFile() && ID->getDefinition())
+return DBuilder.createForwardDecl(llvm::dwarf::DW_TAG_structure_type,
+  ID->getName(),
+  getDeclContextDescriptor(ID), Unit, 0);
+
   // Get overall information about the record type for the debug info.
   llvm::DIFile *DefUnit = getOrCreateFile(ID->getLocation());
   unsigned Line = getLineNumber(ID->getLocation());
@@ -1669,9 +1692,9 @@ CGDebugInfo::getOrCreateModuleRef(Extern
   TheCU->getSourceLanguage(), internString(Mod.ModuleName),
   internString(Mod.Path), TheCU->getProducer(), true, StringRef(), 0,
   internString(Mod.ASTFile), llvm::DIBuilder::FullDebug, Mod.Signature);
-  llvm::DIModule *M =
-  DIB.createModule(CU, Mod.ModuleName, ConfigMacros, 
internString(Mod.Path),
-   internString(CGM.getHeaderSearchOpts().Sysroot));
+  llvm::DIModule *M = DIB.createModule(
+  CU, Mod.ModuleName, ConfigMacros, internString(Mod.Path),
+  internString(CGM.getHeaderSearchOpts().Sysroot));
   DIB.finalize();
   ModRef.reset(M);
   return M;
@@ -1930,6 +1953,7 @@ llvm::DIType *CGDebugInfo::CreateType(co
 
 llvm::DIType *CGDebugInfo::CreateEnumType(const EnumType *Ty) {
   const EnumDecl *ED = Ty->getDecl();
+
   uint64_t Size = 0;
   uint64_t Align = 0;
   if (!ED->getTypeForDecl()->isIncompleteType()) {
@@ -1939,9 +1963,12 @@ llvm::DIType *CGDebugInfo::CreateEnumTyp
 
   SmallString<256> FullName = getUniqueTagTypeName(Ty, CGM, TheCU);
 
+  bool isImportedFromModule =
+  DebugTypeExtRefs && ED->isFromASTFile() && ED->getDefinition();
+
   // If this is just a forward declaration, construct an appropriately
   // marked node and just return it.
-  if (!ED->getDefinition()) {
+  if (isImportedFromModule || !ED->getDefinition()) 

Re: PATCH: Expose the 'file' that is associated with a compile database command

[Manuel Klimek via cfe-commits]

Ok, looked at the original patch again, and if we're fixing the
FixedCompilationDatabase to only insert the file when it actually produces
a CompileCommand it seems to be fine.

On Fri, Sep 11, 2015 at 6:32 PM Argyrios Kyrtzidis 
wrote:

> On Sep 11, 2015, at 12:21 AM, Manuel Klimek  wrote:
>
> On Thu, Sep 10, 2015 at 8:36 PM Argyrios Kyrtzidis 
> wrote:
>
>> On Sep 10, 2015, at 1:48 AM, Manuel Klimek  wrote:
>>
>> @@ -179,11 +185,13 @@ public:
>>/// \param Directory The base directory used in the
>> FixedCompilationDatabase.
>>static FixedCompilationDatabase *loadFromCommandLine(int &Argc,
>> const char
>> *const *Argv,
>> -   Twine Directory =
>> ".");
>> +   Twine Directory =
>> ".",
>> +   Twine File =
>> Twine());
>>
>> A fixed compilation database returns the same command lines for all
>> files, thus having a file in the function seems strange.
>>
>>
>> Ah ok, thanks for clarifying.
>>
>>
>> What exactly is the use case? So far, the compilation database has been
>> designed for 2 use cases:
>> 1. for a file, get the compile commands; the user already knows the file,
>> no need to get the file
>> 2. get all compile commands; for that, we have the getAllFiles() method,
>> so a user can get all known files (for compilation databases that support
>> that), and then get the compile command line.
>>
>>
>> It’s #2, I want to get all compile commands. But it seems really strange
>> to me that the ‘file’ starts as a property of the compile command in the
>> json file but then it gets dropped and I need to do work to re-associate
>> the files with the compile commands again.
>>
>
> The JSON file format is one possible implementation for the
> compilation-database interface. The FixedCompilationDatabase is another
> one, that doesn't have any information on files.
>
>
>> I need to get a list of all the files and then for each one do a lookup
>> to get the associated commands. I then have to maintain this association
>> myself, passing a command along with its file separately or the structure
>> that keeps track of the association.
>>
>> It seems simpler to me to include the file that was associated with the
>> command (if the compilation database supports that) along with the command,
>> is there a downside I’m missing ?
>>
>
> Well, to me, it's a design question - if it also makes sense to have a
> CompileCommand without a file associated with it, putting the file in
> there, while convenient, is a design smell.
>
>
> It can be optional to communicate that it may not be there. Note that,
> IMO, having multiple files and compile commands for them is the
> overwhelmingly most common use of the compilation database.
>
> That said, I'm happy to be convinced that I'm wrong :) I guess I don't see
> yet that keeping track of the files outside is more than one line of extra
> code.
>
>
> Not sure what *one* line this is, I have to declare a map and then
> populate it, no ? And to do it in c-index-test it would take way more that
> one line.
> But it is also beyond populating a map, this has an effect on APIs using a
> CompileCommand. For example:
>
> void doSomethingWithCompileCommand(const CompileCommand &cmd);
>
> Ah it would be useful to know the file that this command was associated
> with:
>
> void doSomethingWithCompileCommand(const CompileCommand &cmd, StringRef
> filename);
>
> What do I have now ? This is a function taking a command and a string for
> the filename separately.
> Is this flexibility useful ? Does it make sense to pass any filename there
> ? No there’s only one filename that the command was associated with so this
> ‘flexibility’ only increases the complexity of using the function. And this
> can propagate to other function’s callees.
> This seems like a design smell to me.
>
>
> Cheers,
> /Manuel
>
>
>>
>>
>> Thoughts?
>> /Manuel
>>
>> On Wed, Sep 9, 2015 at 9:36 PM Argyrios Kyrtzidis 
>> wrote:
>>
>>> Hi,
>>>
>>> The attached patch exposes the ‘file’ entry in a compilation database
>>> command, via the CompileCommand structure.
>>
>>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r247431 - Revert "Module Debugging: Emit forward declarations for types that are defined in"

[Adrian Prantl via cfe-commits]

Author: adrian
Date: Fri Sep 11 12:23:03 2015
New Revision: 247431

URL: http://llvm.org/viewvc/llvm-project?rev=247431&view=rev
Log:
Revert "Module Debugging: Emit forward declarations for types that are defined 
in"

This reverts commit r247369 to facilitate reviewing of the following patch.

Removed:
cfe/trunk/test/Modules/ExtDebugInfo.cpp
cfe/trunk/test/Modules/ExtDebugInfo.m
Modified:
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
cfe/trunk/lib/CodeGen/CGDebugInfo.h

Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=247431&r1=247430&r2=247431&view=diff
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Fri Sep 11 12:23:03 2015
@@ -148,9 +148,7 @@ void CGDebugInfo::setLocation(SourceLoca
 }
 
 llvm::DIScope *CGDebugInfo::getDeclContextDescriptor(const Decl *D) {
-  llvm::DIScope *Mod = getParentModuleOrNull(D);
-  return getContextDescriptor(cast(D->getDeclContext()),
-  Mod ? Mod : TheCU);
+  return getContextDescriptor(cast(D->getDeclContext()), TheCU);
 }
 
 llvm::DIScope *CGDebugInfo::getContextDescriptor(const Decl *Context,
@@ -1450,9 +1448,6 @@ void CGDebugInfo::completeRequiredType(c
 if (CXXDecl->isDynamicClass())
   return;
 
-  if (DebugTypeExtRefs && RD->isFromASTFile())
-return;
-
   QualType Ty = CGM.getContext().getRecordType(RD);
   llvm::DIType *T = getTypeOrNull(Ty);
   if (T && T->isForwardDecl())
@@ -1674,9 +1669,9 @@ CGDebugInfo::getOrCreateModuleRef(Extern
   TheCU->getSourceLanguage(), internString(Mod.ModuleName),
   internString(Mod.Path), TheCU->getProducer(), true, StringRef(), 0,
   internString(Mod.ASTFile), llvm::DIBuilder::FullDebug, Mod.Signature);
-  llvm::DIModule *M = DIB.createModule(
-  CU, Mod.ModuleName, ConfigMacros, internString(Mod.Path),
-  internString(CGM.getHeaderSearchOpts().Sysroot));
+  llvm::DIModule *M =
+  DIB.createModule(CU, Mod.ModuleName, ConfigMacros, 
internString(Mod.Path),
+   internString(CGM.getHeaderSearchOpts().Sysroot));
   DIB.finalize();
   ModRef.reset(M);
   return M;
@@ -2086,16 +2081,9 @@ llvm::DIType *CGDebugInfo::getOrCreateTy
   if (auto *T = getTypeOrNull(Ty))
 return T;
 
-  llvm::DIType *Res = nullptr;
-  if (DebugTypeExtRefs)
-// Make a forward declaration of an external type.
-Res = getTypeExtRefOrNull(Ty, Unit);
-
   // Otherwise create the type.
-  if (!Res)
-Res = CreateTypeNode(Ty, Unit);
-
-  void* TyPtr = Ty.getAsOpaquePtr();
+  llvm::DIType *Res = CreateTypeNode(Ty, Unit);
+  void *TyPtr = Ty.getAsOpaquePtr();
 
   // And update the type cache.
   TypeCache[TyPtr].reset(Res);
@@ -2127,123 +2115,6 @@ ObjCInterfaceDecl *CGDebugInfo::getObjCI
   }
 }
 
-llvm::DIModule *CGDebugInfo::getParentModuleOrNull(const Decl *D) {
-  if (!DebugTypeExtRefs || !D || !D->isFromASTFile())
-return nullptr;
-
-  llvm::DIModule *ModuleRef = nullptr;
-  auto *Reader = CGM.getContext().getExternalSource();
-  auto Idx = D->getOwningModuleID();
-  auto Info = Reader->getSourceDescriptor(Idx);
-  if (Info)
-ModuleRef = getOrCreateModuleRef(*Info);
-  return ModuleRef;
-}
-
-llvm::DIType *CGDebugInfo::getTypeExtRefOrNull(QualType Ty, llvm::DIFile *F,
-   bool Anchored) {
-  assert(DebugTypeExtRefs && "module debugging only");
-  Decl *TyDecl = nullptr;
-  StringRef Name;
-  SmallString<256> UID;
-  unsigned Tag = 0;
-
-  // Handle all types that have a declaration.
-  switch (Ty->getTypeClass()) {
-  case Type::Typedef: {
-TyDecl = cast(Ty)->getDecl();
-if (!TyDecl->isFromASTFile())
-  return nullptr;
-
-// A typedef will anchor a type in the module.
-if (auto *TD = dyn_cast(TyDecl)) {
-  // This is a working around the fact that LLVM does not allow
-  // typedefs to be forward declarations.
-  QualType Ty = TD->getUnderlyingType();
-  Ty = UnwrapTypeForDebugInfo(Ty, CGM.getContext());
-  if (auto *AnchoredTy = getTypeExtRefOrNull(Ty, F, /*Anchored=*/true)) {
-TypeCache[Ty.getAsOpaquePtr()].reset(AnchoredTy);
-SourceLocation Loc = TD->getLocation();
-return DBuilder.createTypedef(AnchoredTy, TD->getName(),
-  getOrCreateFile(Loc), getLineNumber(Loc),
-  getDeclContextDescriptor(TD));
-  }
-}
-break;
-  }
-
-  case Type::Record: {
-TyDecl = cast(Ty)->getDecl();
-if (!TyDecl->isFromASTFile())
-  return nullptr;
-
-if (auto *CTSD = dyn_cast(TyDecl))
-  if (!CTSD->isExplicitInstantiationOrSpecialization() && !Anchored)
-// We may not assume that this type made it into the module.
-return nullptr;
-// C++ classes and template instantiations.
-if (auto *RD = dyn_cast(TyDecl)) {
-  if (!RD->getDefinit

Re: r247369 - Module Debugging: Emit forward declarations for types that are defined in

[Adrian Prantl via cfe-commits]

> On Sep 11, 2015, at 8:27 AM, David Blaikie  wrote:
> 
> 
> 
> On Fri, Sep 11, 2015 at 8:18 AM, Adrian Prantl  > wrote:
> 
>> On Sep 10, 2015, at 6:56 PM, David Blaikie > > wrote:
>> 
>> 
>> 
>> On Thu, Sep 10, 2015 at 6:40 PM, David Blaikie > > wrote:
>> 
>> 
>> On Thu, Sep 10, 2015 at 6:03 PM, Adrian Prantl via cfe-commits 
>> mailto:cfe-commits@lists.llvm.org>> wrote:
>> Author: adrian
>> Date: Thu Sep 10 20:03:26 2015
>> New Revision: 247369
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=247369&view=rev 
>> 
>> Log:
>> Module Debugging: Emit forward declarations for types that are defined in
>> clang modules, if -dwarf-ext-refs (DebugTypesExtRefs) is specified.
>> 
>> This change seems to have a lot more code in it than I was expecting... 
>> 
>> I was rather expecting something a lot like the flimit-debug-info support. 
>> Specifically, I would've expected one more conditional added to 
>> CGDebugInfo::shouldOmitDefinition.
>> 
>> Why the extra complexity?
>> 
>> I guess part of it is to be able to omit definitions of things other than 
>> record types - is there much value in that? (especially typedefs - it seems 
>> like a typedef is too small to benefit from a declaration (even if we could 
>> emit one)?)
> 
> The typedef itself is not interesting, but it can be used to anchor template 
> instantiations like std::string. The contract between the debug info in the 
> module and the debug info referencing the module is that all explicit 
> template specializations 
> 
> This I get ^ (though does that case need any special handling, or will the 
> isFromASTFile return true for the location of the explicit specialization 
> declaration/definition?)
>  
> and template instantiations referenced used in a typedef can be expected to 
> exist in the module.
> 
> This I do not get & would imagine it could cause substantial size increase... 
> 
> Might be worth splitting out that change to look at it more carefully. I'd 
> love to see numbers here.
>> Also, we could possibly solve both the problem of "don't emit definitions 
>> for module things when compiling the main source file" and "don't emit 
>> definitions for module things defined in other modules" with the same tool. 
>> If there's a way to say "is this in a foreign AST file" then testing for 
>> that in CGDebugInfo::shouldOmitDefinition would solve both problems, I think 
>> (conditionalized on the appropriate flags, either dwarf-ext-refs or "I'm 
>> building a module here”).
> 
> I believe that this is a good point. Really, getExtRefOrNull is a separate 
> function mostly for evolutionary reasons — it used to do different things 
> like mangling names of ObjC types etc. I will see if I can merge the existing 
> functionality into shouldOmitDefinition().
> 
> From a review perspective it might be easier to revert this & commit a new 
> patch - I haven't reviewed all these changes in detail because they just 
> seemed more complex than necessary, but if you're going to evolve it from 
> here I'll need to dig into the current implementation/be more careful about 
> checking that future changes remove the complexity along with whatever they 
> add.
> 

I just did this in r24743[12].

-- adrian

> - Dave
>  
> 
> -- adrian
> 
>>  
>>  
>> 
>> Added:
>> cfe/trunk/test/Modules/ExtDebugInfo.cpp
>> cfe/trunk/test/Modules/ExtDebugInfo.m
>> Modified:
>> cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
>> cfe/trunk/lib/CodeGen/CGDebugInfo.h
>> 
>> Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=247369&r1=247368&r2=247369&view=diff
>>  
>> 
>> ==
>> --- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
>> +++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Thu Sep 10 20:03:26 2015
>> @@ -148,7 +148,9 @@ void CGDebugInfo::setLocation(SourceLoca
>>  }
>> 
>>  llvm::DIScope *CGDebugInfo::getDeclContextDescriptor(const Decl *D) {
>> -  return getContextDescriptor(cast(D->getDeclContext()), TheCU);
>> +  llvm::DIScope *Mod = getParentModuleOrNull(D);
>> +  return getContextDescriptor(cast(D->getDeclContext()),
>> +  Mod ? Mod : TheCU);
>>  }
>> 
>>  llvm::DIScope *CGDebugInfo::getContextDescriptor(const Decl *Context,
>> @@ -1448,6 +1450,9 @@ void CGDebugInfo::completeRequiredType(c
>>  if (CXXDecl->isDynamicClass())
>>return;
>> 
>> +  if (DebugTypeExtRefs && RD->isFromASTFile())
>> +return;
>> +
>>QualType Ty = CGM.getContext().getRecordType(RD);
>>llvm::DIType *T = getTypeOrNull(Ty);
>>if (T && T->isForwardDecl())
>> @@ -1669,9 +1674,9 @@ CGDebugInfo::getOrCreateModuleRef(Extern
>>TheCU->

r247434 - Update test expectations for LLVM asm printing change

[Reid Kleckner via cfe-commits]

Author: rnk
Date: Fri Sep 11 12:27:53 2015
New Revision: 247434

URL: http://llvm.org/viewvc/llvm-project?rev=247434&view=rev
Log:
Update test expectations for LLVM asm printing change

Modified:
cfe/trunk/test/CodeGen/exceptions-seh-new.c

Modified: cfe/trunk/test/CodeGen/exceptions-seh-new.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/exceptions-seh-new.c?rev=247434&r1=247433&r2=247434&view=diff
==
--- cfe/trunk/test/CodeGen/exceptions-seh-new.c (original)
+++ cfe/trunk/test/CodeGen/exceptions-seh-new.c Fri Sep 11 12:27:53 2015
@@ -30,8 +30,9 @@ int safe_div(int numerator, int denomina
 // CHECK:   to label %{{.*}} unwind label %[[catchpad:[^ ]*]]
 //
 // CHECK: [[catchpad]]
-// X64: %[[padtoken:[^ ]*]] = catchpad [i8* null] to label %[[exceptret:[^ 
]*]] unwind label
-// X86: %[[padtoken:[^ ]*]] = catchpad [i8* bitcast (i32 ()* 
@"\01?filt$0@0@safe_div@@" to i8*)] to label %[[exceptret:[^ ]*]] unwind label
+// X64: %[[padtoken:[^ ]*]] = catchpad [i8* null]
+// X86: %[[padtoken:[^ ]*]] = catchpad [i8* bitcast (i32 ()* 
@"\01?filt$0@0@safe_div@@" to i8*)]
+// CHECK-NEXT:to label %[[exceptret:[^ ]*]] unwind label
 //
 // CHECK: [[exceptret]]
 // CHECK: catchret %[[padtoken]] to label %[[except:[^ ]*]]
@@ -113,7 +114,8 @@ int nested_try(void) {
 // CHECK:   to label %[[cont:[^ ]*]] unwind label %[[cpad_inner:[^ ]*]]
 //
 // CHECK: [[cpad_inner]]
-// CHECK: catchpad [i8* bitcast (i32 ({{.*}})* @"\01?filt$1@0@nested_try@@" to 
i8*)] to label %[[exceptret_inner:[^ ]*]] unwind label %[[cpad_outer:[^ ]*]]
+// CHECK: catchpad [i8* bitcast (i32 ({{.*}})* @"\01?filt$1@0@nested_try@@" to 
i8*)]
+// CHECK-NEXT: to label %[[exceptret_inner:[^ ]*]] unwind label 
%[[cpad_outer:[^ ]*]]
 //
 // CHECK: [[exceptret_inner]]
 // CHECK: catchret {{.*}} to label %[[except_inner:[^ ]*]]
@@ -126,7 +128,8 @@ int nested_try(void) {
 // CHECK: br label %[[outer_try_cont:[^ ]*]]
 //
 // CHECK: [[cpad_outer]]
-// CHECK: catchpad [i8* bitcast (i32 ({{.*}})* @"\01?filt$0@0@nested_try@@" to 
i8*)] to label %[[exceptret_outer:[^ ]*]] unwind label
+// CHECK: catchpad [i8* bitcast (i32 ({{.*}})* @"\01?filt$0@0@nested_try@@" to 
i8*)]
+// CHECK-NEXT: to label %[[exceptret_outer:[^ ]*]] unwind label
 //
 // CHECK: [[exceptret_outer]]
 // CHECK: catchret {{.*}} to label %[[except_outer:[^ ]*]]


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

Re: [PATCH] D12743: [CodeGen] Teach SimplifyPersonality about the updated LandingPadInst

[Vedant Kumar via cfe-commits]

vsk added a comment.

I think 'optimization' is a bit of a misnomer. There's a comment in this code 
that reads: "Can't do the optimization if it has non-C++ uses", so that's why I 
picked up the word. Without SimplifyPersonality(), some objective c++ code can 
no longer link against c++ libraries.

Consider the following test:
$ echo "#include " "\n" 'void foo() { throw 
std::runtime_error("foo"); }' | clang -x objective-cxx -S -emit-llvm - -o - | 
grep personality

After we moved personality from landingpadinst to functions, the output of the 
test changes (from __gxx_personality to __objc_personality). This commit just 
takes us back to the original behavior.

The original comment, "Otherwise, it has to be a landingpad instruction.", is 
wrong after David's patch.


http://reviews.llvm.org/D12743



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

r247436 - [CMake] Making the bootstrap-clear target always delete the boostrap build directories.

[Chris Bieneman via cfe-commits]

Author: cbieneman
Date: Fri Sep 11 12:38:38 2015
New Revision: 247436

URL: http://llvm.org/viewvc/llvm-project?rev=247436&view=rev
Log:
[CMake] Making the bootstrap-clear target always delete the boostrap build 
directories.

Modified:
cfe/trunk/CMakeLists.txt

Modified: cfe/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/CMakeLists.txt?rev=247436&r1=247435&r2=247436&view=diff
==
--- cfe/trunk/CMakeLists.txt (original)
+++ cfe/trunk/CMakeLists.txt Fri Sep 11 12:38:38 2015
@@ -598,7 +598,6 @@ if (CLANG_ENABLE_BOOTSTRAP)
 COMMAND ${CMAKE_COMMAND} -E make_directory ${BINARY_DIR}
 COMMAND ${CMAKE_COMMAND} -E remove_directory ${STAMP_DIR}
 COMMAND ${CMAKE_COMMAND} -E make_directory ${STAMP_DIR}
-COMMAND ${CMAKE_COMMAND} -E touch 
${CMAKE_CURRENT_BINARY_DIR}/bootstrap-cleared
 COMMENT "Clobberring bootstrap build and stamp directories"
 )
 


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

r247437 - [test] Specify exception object type in two tests

[Vedant Kumar via cfe-commits]

Author: vedantk
Date: Fri Sep 11 12:39:34 2015
New Revision: 247437

URL: http://llvm.org/viewvc/llvm-project?rev=247437&view=rev
Log:
[test] Specify exception object type in two tests

Replace:
'try { throw 0; } catch (...)'
with
'try { throw 0; } catch (int e)'

in two test cases.

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

Modified:
cfe/trunk/test/CodeGenObjCXX/exception-cxx.mm
cfe/trunk/test/CodeGenObjCXX/personality-abuse.mm

Modified: cfe/trunk/test/CodeGenObjCXX/exception-cxx.mm
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenObjCXX/exception-cxx.mm?rev=247437&r1=247436&r2=247437&view=diff
==
--- cfe/trunk/test/CodeGenObjCXX/exception-cxx.mm (original)
+++ cfe/trunk/test/CodeGenObjCXX/exception-cxx.mm Fri Sep 11 12:39:34 2015
@@ -5,7 +5,7 @@ namespace test0 {
   void foo() {
 try {
   throw 0;
-} catch (...) {
+} catch (int e) {
   return;
 }
   }

Modified: cfe/trunk/test/CodeGenObjCXX/personality-abuse.mm
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenObjCXX/personality-abuse.mm?rev=247437&r1=247436&r2=247437&view=diff
==
--- cfe/trunk/test/CodeGenObjCXX/personality-abuse.mm (original)
+++ cfe/trunk/test/CodeGenObjCXX/personality-abuse.mm Fri Sep 11 12:39:34 2015
@@ -11,7 +11,7 @@ void *abuse_personality_func() {
 void foo() {
   try {
 throw 0;
-  } catch (...) {
+  } catch (int e) {
 return;
   }
 }


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

Re: [PATCH] D12743: [CodeGen] Teach SimplifyPersonality about the updated LandingPadInst

[Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL247437: [test] Specify exception object type in two tests 
(authored by vedantk).

Changed prior to commit:
  http://reviews.llvm.org/D12743?vs=34408&id=34560#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D12743

Files:
  cfe/trunk/test/CodeGenObjCXX/exception-cxx.mm
  cfe/trunk/test/CodeGenObjCXX/personality-abuse.mm

Index: cfe/trunk/test/CodeGenObjCXX/personality-abuse.mm
===
--- cfe/trunk/test/CodeGenObjCXX/personality-abuse.mm
+++ cfe/trunk/test/CodeGenObjCXX/personality-abuse.mm
@@ -11,7 +11,7 @@
 void foo() {
   try {
 throw 0;
-  } catch (...) {
+  } catch (int e) {
 return;
   }
 }
Index: cfe/trunk/test/CodeGenObjCXX/exception-cxx.mm
===
--- cfe/trunk/test/CodeGenObjCXX/exception-cxx.mm
+++ cfe/trunk/test/CodeGenObjCXX/exception-cxx.mm
@@ -5,7 +5,7 @@
   void foo() {
 try {
   throw 0;
-} catch (...) {
+} catch (int e) {
   return;
 }
   }


Index: cfe/trunk/test/CodeGenObjCXX/personality-abuse.mm
===
--- cfe/trunk/test/CodeGenObjCXX/personality-abuse.mm
+++ cfe/trunk/test/CodeGenObjCXX/personality-abuse.mm
@@ -11,7 +11,7 @@
 void foo() {
   try {
 throw 0;
-  } catch (...) {
+  } catch (int e) {
 return;
   }
 }
Index: cfe/trunk/test/CodeGenObjCXX/exception-cxx.mm
===
--- cfe/trunk/test/CodeGenObjCXX/exception-cxx.mm
+++ cfe/trunk/test/CodeGenObjCXX/exception-cxx.mm
@@ -5,7 +5,7 @@
   void foo() {
 try {
   throw 0;
-} catch (...) {
+} catch (int e) {
   return;
 }
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D12743: [CodeGen] Teach SimplifyPersonality about the updated LandingPadInst

[Vedant Kumar via cfe-commits]

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

Addressed Reid's comment w.r.t exception object type.


Repository:
  rL LLVM

http://reviews.llvm.org/D12743



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

Re: [PATCH] D12743: [CodeGen] Teach SimplifyPersonality about the updated LandingPadInst

[Reid Kleckner via cfe-commits]

rnk added a comment.

Right, I understand the behavior change, I'm just wondering why it results in 
link failures. There isn't a ton of public info about how ObjC++ EH interacts 
with C++ EH.


Repository:
  rL LLVM

http://reviews.llvm.org/D12743



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

r247438 - Use Itanium C++ ABI triple for new modules+debug test

[Reid Kleckner via cfe-commits]

Author: rnk
Date: Fri Sep 11 12:50:14 2015
New Revision: 247438

URL: http://llvm.org/viewvc/llvm-project?rev=247438&view=rev
Log:
Use Itanium C++ ABI triple for new modules+debug test

Modified:
cfe/trunk/test/Modules/ExtDebugInfo.cpp

Modified: cfe/trunk/test/Modules/ExtDebugInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/ExtDebugInfo.cpp?rev=247438&r1=247437&r2=247438&view=diff
==
--- cfe/trunk/test/Modules/ExtDebugInfo.cpp (original)
+++ cfe/trunk/test/Modules/ExtDebugInfo.cpp Fri Sep 11 12:50:14 2015
@@ -4,13 +4,16 @@
 // Modules:
 // RUN: %clang_cc1 -x objective-c++ -std=c++11 -g -dwarf-ext-refs -fmodules \
 // RUN: -fmodule-format=obj -fimplicit-module-maps -DMODULES \
+// RUN: -triple %itanium_abi_triple \
 // RUN: -fmodules-cache-path=%t %s -I %S/Inputs -I %t -emit-llvm -o 
%t-mod.ll
 // RUN: cat %t-mod.ll |  FileCheck %s
 
 // PCH:
 // RUN: %clang_cc1 -x c++ -std=c++11 -fmodule-format=obj -emit-pch -I%S/Inputs 
\
+// RUN: -triple %itanium_abi_triple \
 // RUN: -o %t.pch %S/Inputs/DebugCXX.h
 // RUN: %clang_cc1 -std=c++11 -g -dwarf-ext-refs -fmodule-format=obj \
+// RUN: -triple %itanium_abi_triple \
 // RUN: -include-pch %t.pch %s -emit-llvm -o %t-pch.ll %s
 // RUN: cat %t-pch.ll |  FileCheck %s
 
@@ -66,4 +69,4 @@ char _anchor = anon_enum + conflicting_u
 // CHECK: !DICompositeType(tag: DW_TAG_enumeration_type, scope: ![[NS]],
 // CHECK-SAME: line: 16
 
-// CHECK: !DIImportedEntity(tag: DW_TAG_imported_declaration, scope: !0, 
entity: !"_ZTSN8DebugCXX6StructE", line: 21)
+// CHECK: !DIImportedEntity(tag: DW_TAG_imported_declaration, scope: !0, 
entity: !"_ZTSN8DebugCXX6StructE", line: 24)


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

Re: r247346 - [MS ABI] Make member pointers return true for isIncompleteType

[Hans Wennborg via cfe-commits]

This made the Chromium build sad. For example:
http://build.chromium.org/p/chromium.fyi/builders/ClangToTWin/builds/3092/steps/compile/logs/stdio

Reduction:

$ clang -cc1 -triple i686-pc-windows-msvc18.0.0 -w -fms-extensions
-fms-compatibility -fms-compatibility-version=18.0 -std=c++11
-fdelayed-template-parsing a.ii

template 
void JSMethod(char *, char *, int);
class A {
  int printd(int *, const int &, int &, int &);
  int printd_info;
  void printd() { JSMethod("", "", printd_info); }
};


On Thu, Sep 10, 2015 at 2:52 PM, David Majnemer via cfe-commits
 wrote:
> Author: majnemer
> Date: Thu Sep 10 16:52:00 2015
> New Revision: 247346
>
> URL: http://llvm.org/viewvc/llvm-project?rev=247346&view=rev
> Log:
> [MS ABI] Make member pointers return true for isIncompleteType
>
> The type of a member pointer is incomplete if it has no inheritance
> model.  This lets us reuse more general logic already embedded in clang.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D12743: [CodeGen] Teach SimplifyPersonality about the updated LandingPadInst

[Vedant Kumar via cfe-commits]

vsk added a comment.

Ah, ok. We have some objective-c++ code which calls into a boost routine which 
throws an exception. That results in an undefined reference to 
___objc_personality_v0, because the boost library we linked against doesn't 
have ___objc_personality_v0.

Should the compiler have found the ___objc_personality_v0 symbol in this case 
regardless?


Repository:
  rL LLVM

http://reviews.llvm.org/D12743



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

Re: r247346 - [MS ABI] Make member pointers return true for isIncompleteType

[David Majnemer via cfe-commits]

Taking a look, would appreciate it if we didn't revert this until I give it
a fair shot.  Shouldn't take too long.

On Fri, Sep 11, 2015 at 10:58 AM, Hans Wennborg  wrote:

> This made the Chromium build sad. For example:
>
> http://build.chromium.org/p/chromium.fyi/builders/ClangToTWin/builds/3092/steps/compile/logs/stdio
>
> Reduction:
>
> $ clang -cc1 -triple i686-pc-windows-msvc18.0.0 -w -fms-extensions
> -fms-compatibility -fms-compatibility-version=18.0 -std=c++11
> -fdelayed-template-parsing a.ii
>
> template 
> void JSMethod(char *, char *, int);
> class A {
>   int printd(int *, const int &, int &, int &);
>   int printd_info;
>   void printd() { JSMethod("", "", printd_info); }
> };
>
>
> On Thu, Sep 10, 2015 at 2:52 PM, David Majnemer via cfe-commits
>  wrote:
> > Author: majnemer
> > Date: Thu Sep 10 16:52:00 2015
> > New Revision: 247346
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=247346&view=rev
> > Log:
> > [MS ABI] Make member pointers return true for isIncompleteType
> >
> > The type of a member pointer is incomplete if it has no inheritance
> > model.  This lets us reuse more general logic already embedded in clang.
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D12807: Display name of identifier tokens in Visual Studio native visualizer

[Mike Spertus via cfe-commits]

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

The Token visualizer in clang.natvis makes debugging Clang in Visual Studio 
much easier for keywords (because a given keyword is always the same), but it 
doesn't work very well for identifiers (because they are all different). This 
change has the visualizer display the name of the identifier. I have been using 
this daily, and I find this simple change has lead to a much-improved 
day-to-day experience.

http://reviews.llvm.org/D12807

Files:
  utils/clang.natvis

Index: utils/clang.natvis
===
--- utils/clang.natvis
+++ utils/clang.natvis
@@ -27,7 +27,8 @@
 
   
   
-{(clang::tok::TokenKind)Kind}
+{(clang::tok::TokenKind)Kind}
+{{Identifier 
({*(clang::IdentifierInfo *)(PtrData)})}}
   
   
 [{(clang::DeclSpec::SCS)StorageClassSpec}], 
[{(clang::TypeSpecifierType)TypeSpecType}]


Index: utils/clang.natvis
===
--- utils/clang.natvis
+++ utils/clang.natvis
@@ -27,7 +27,8 @@
 
   
   
-{(clang::tok::TokenKind)Kind}
+{(clang::tok::TokenKind)Kind}
+{{Identifier ({*(clang::IdentifierInfo *)(PtrData)})}}
   
   
 [{(clang::DeclSpec::SCS)StorageClassSpec}], [{(clang::TypeSpecifierType)TypeSpecType}]
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D12807: Display name of identifier tokens in Visual Studio native visualizer

[Aaron Ballman via cfe-commits]

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

LGTM, thank for you this (I think it's going to help me out quite a bit)!


http://reviews.llvm.org/D12807



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

Re: r247432 - Module Debugging: Emit forward declarations for types that are defined in

[David Blaikie via cfe-commits]

On Fri, Sep 11, 2015 at 10:23 AM, Adrian Prantl via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: adrian
> Date: Fri Sep 11 12:23:08 2015
> New Revision: 247432
>
> URL: http://llvm.org/viewvc/llvm-project?rev=247432&view=rev
> Log:
> Module Debugging: Emit forward declarations for types that are defined in
> clang modules, if -dwarf-ext-refs (DebugTypesExtRefs) is specified.
>
> This reimplements r247369 in about a third of the amount of code.
> Thanks to David Blaikie pointing this out in post-commit review!
>
> Added:
> cfe/trunk/test/Modules/ExtDebugInfo.cpp
> cfe/trunk/test/Modules/ExtDebugInfo.m
> Modified:
> cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
> cfe/trunk/lib/CodeGen/CGDebugInfo.h
>
> Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=247432&r1=247431&r2=247432&view=diff
>
> ==
> --- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Fri Sep 11 12:23:08 2015
> @@ -148,7 +148,9 @@ void CGDebugInfo::setLocation(SourceLoca
>  }
>
>  llvm::DIScope *CGDebugInfo::getDeclContextDescriptor(const Decl *D) {
> -  return getContextDescriptor(cast(D->getDeclContext()), TheCU);
> +  llvm::DIScope *Mod = getParentModuleOrNull(D);
> +  return getContextDescriptor(cast(D->getDeclContext()),
> +  Mod ? Mod : TheCU);
>

Might've been nice to separate the module-parenting part of the change,
smaller patches (easier to revert, review, etc), the usual stuff.


>  }
>
>  llvm::DIScope *CGDebugInfo::getContextDescriptor(const Decl *Context,
> @@ -1448,6 +1450,9 @@ void CGDebugInfo::completeRequiredType(c
>  if (CXXDecl->isDynamicClass())
>return;
>
> +  if (DebugTypeExtRefs && RD->isFromASTFile())
> +return;
> +
>QualType Ty = CGM.getContext().getRecordType(RD);
>llvm::DIType *T = getTypeOrNull(Ty);
>if (T && T->isForwardDecl())
> @@ -1478,8 +1483,19 @@ static bool hasExplicitMemberDefinition(
>  }
>
>  static bool shouldOmitDefinition(CodeGenOptions::DebugInfoKind DebugKind,
> + bool DebugTypeExtRefs,
>   const RecordDecl *RD,
>   const LangOptions &LangOpts) {
> +  // Does the type exist in an imported clang module?
> +  if (DebugTypeExtRefs && RD->isFromASTFile()) {
> +if (auto *CTSD = dyn_cast(RD))
> +  if (CTSD->isExplicitInstantiationOrSpecialization())
> +// We may not assume that this type made it into the module.
>

I guess you mean "we may assume this type made it into the module"? (the
"not" seems erroneous - but perhaps I'm misparsing the sentence?)


> +return true;
>

Does this case ^ actually do anything? (aren't all these instantiations
going to be definitions anyway? so if you removed that code the below would
return true anyway, wouldn't it?)


> +if (RD->getDefinition())
> +  return true;
> +  }
> +
>if (DebugKind > CodeGenOptions::LimitedDebugInfo)
>  return false;
>
> @@ -1513,7 +1529,8 @@ static bool shouldOmitDefinition(CodeGen
>  llvm::DIType *CGDebugInfo::CreateType(const RecordType *Ty) {
>RecordDecl *RD = Ty->getDecl();
>llvm::DIType *T = cast_or_null(getTypeOrNull(QualType(Ty,
> 0)));
> -  if (T || shouldOmitDefinition(DebugKind, RD, CGM.getLangOpts())) {
> +  if (T || shouldOmitDefinition(DebugKind, DebugTypeExtRefs, RD,
> +CGM.getLangOpts())) {
>  if (!T)
>T = getOrCreateRecordFwdDecl(Ty, getDeclContextDescriptor(RD));
>  return T;
> @@ -1616,6 +1633,12 @@ llvm::DIType *CGDebugInfo::CreateType(co
>if (!ID)
>  return nullptr;
>
> +  // Return a forward declaration if this type was imported from a clang
> module.
>

What's this extra code needed for? Isn't this what shouldOmitDefinition
already does? It causes calls to getOrCreateRecordFwdDecl and so we should
never get into the CreateTypeDefinition function for the type.


> +  if (DebugTypeExtRefs && ID->isFromASTFile() && ID->getDefinition())
> +return DBuilder.createForwardDecl(llvm::dwarf::DW_TAG_structure_type,
> +  ID->getName(),
> +  getDeclContextDescriptor(ID), Unit,
> 0);
> +
>// Get overall information about the record type for the debug info.
>llvm::DIFile *DefUnit = getOrCreateFile(ID->getLocation());
>unsigned Line = getLineNumber(ID->getLocation());
> @@ -1669,9 +1692,9 @@ CGDebugInfo::getOrCreateModuleRef(Extern
>TheCU->getSourceLanguage(), internString(Mod.ModuleName),
>internString(Mod.Path), TheCU->getProducer(), true, StringRef(), 0,
>internString(Mod.ASTFile), llvm::DIBuilder::FullDebug,
> Mod.Signature);
> -  llvm::DIModule *M =
> -  DIB.createModule(CU, Mod.ModuleName, ConfigMacros,
> internString(Mod.Path),
> -   

r247442 - Extend the Token visualizer used by MSVC to display the identifier text for tok::identifier tokens.

[Aaron Ballman via cfe-commits]

Author: aaronballman
Date: Fri Sep 11 13:35:18 2015
New Revision: 247442

URL: http://llvm.org/viewvc/llvm-project?rev=247442&view=rev
Log:
Extend the Token visualizer used by MSVC to display the identifier text for 
tok::identifier tokens.

Patch by Mike Spertus.

Modified:
cfe/trunk/utils/clang.natvis

Modified: cfe/trunk/utils/clang.natvis
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/utils/clang.natvis?rev=247442&r1=247441&r2=247442&view=diff
==
--- cfe/trunk/utils/clang.natvis (original)
+++ cfe/trunk/utils/clang.natvis Fri Sep 11 13:35:18 2015
@@ -24,13 +24,14 @@ or create a symbolic link so it updates
   *(clang::IdentifierInfo *)(Ptr & 
~PtrMask)
   *(clang::IdentifierInfo *)(Ptr & 
~PtrMask)
   (clang::DeclarationNameExtra::ExtraKind)((clang::DeclarationNameExtra
 *)(Ptr & ~PtrMask))->ExtraKindOrNumArgs
-
-  
-  
-{(clang::tok::TokenKind)Kind}
-  
-  
-[{(clang::DeclSpec::SCS)StorageClassSpec}], 
[{(clang::TypeSpecifierType)TypeSpecType}]
+
+  
+  
+{(clang::tok::TokenKind)Kind}
+{{Identifier 
({*(clang::IdentifierInfo *)(PtrData)})}}
+  
+  
+[{(clang::DeclSpec::SCS)StorageClassSpec}], 
[{(clang::TypeSpecifierType)TypeSpecType}]
   
   
 {Name,s}


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

Re: [PATCH] D12807: Display name of identifier tokens in Visual Studio native visualizer

[Aaron Ballman via cfe-commits]

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

I've commit in r247442, thank you for the patch!


http://reviews.llvm.org/D12807



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

Re: [PATCH] D12807: Display name of identifier tokens in Visual Studio native visualizer

[Mike Spertus via cfe-commits]

mspertus added a comment.

Thanks, Aaron! Hal mentioned that I might need to ask you to commit on my 
behalf as I don't have commit access as of now.


http://reviews.llvm.org/D12807



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

r247444 - [Static Analyzer] Fixed a typo in a diagnostic message.

[Gabor Horvath via cfe-commits]

Author: xazax
Date: Fri Sep 11 13:41:50 2015
New Revision: 247444

URL: http://llvm.org/viewvc/llvm-project?rev=247444&view=rev
Log:
[Static Analyzer] Fixed a typo in a diagnostic message.

Modified:
cfe/trunk/lib/StaticAnalyzer/Checkers/NullabilityChecker.cpp

Modified: cfe/trunk/lib/StaticAnalyzer/Checkers/NullabilityChecker.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Checkers/NullabilityChecker.cpp?rev=247444&r1=247443&r2=247444&view=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Checkers/NullabilityChecker.cpp (original)
+++ cfe/trunk/lib/StaticAnalyzer/Checkers/NullabilityChecker.cpp Fri Sep 11 
13:41:50 2015
@@ -99,7 +99,7 @@ const char *const ErrorMessages[] = {
 "Nullable pointer is returned from a function that is expected to return a 
"
 "non-null value",
 "Nullable pointer is dereferenced",
-"Nullable pointer is passed to a calle that requires a non-null argument"};
+"Nullable pointer is passed to a callee that requires a non-null 
argument"};
 
 class NullabilityChecker
 : public Checker,


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

r247445 - Cleanup: Get rid of a bunch of unnecessary invocations of internString()

[Adrian Prantl via cfe-commits]

Author: adrian
Date: Fri Sep 11 13:45:02 2015
New Revision: 247445

URL: http://llvm.org/viewvc/llvm-project?rev=247445&view=rev
Log:
Cleanup: Get rid of a bunch of unnecessary invocations of internString()
in CGDebugInfo.cpp: MDString::get() copies its arguments.

Modified:
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp

Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=247445&r1=247444&r2=247445&view=diff
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Fri Sep 11 13:45:02 2015
@@ -345,13 +345,6 @@ void CGDebugInfo::CreateCompileUnit() {
 }
   }
 
-  // Save filename string.
-  StringRef Filename = internString(MainFileName);
-
-  // Save split dwarf file string.
-  std::string SplitDwarfFile = CGM.getCodeGenOpts().SplitDwarfFile;
-  StringRef SplitDwarfFilename = internString(SplitDwarfFile);
-
   llvm::dwarf::SourceLanguage LangTag;
   const LangOptions &LO = CGM.getLangOpts();
   if (LO.CPlusPlus) {
@@ -377,13 +370,13 @@ void CGDebugInfo::CreateCompileUnit() {
   // Create new compile unit.
   // FIXME - Eliminate TheCU.
   TheCU = DBuilder.createCompileUnit(
-  LangTag, Filename, getCurrentDirname(), Producer, LO.Optimize,
-  CGM.getCodeGenOpts().DwarfDebugFlags, RuntimeVers, SplitDwarfFilename,
+  LangTag, MainFileName, getCurrentDirname(), Producer, LO.Optimize,
+  CGM.getCodeGenOpts().DwarfDebugFlags, RuntimeVers,
+  CGM.getCodeGenOpts().SplitDwarfFile,
   DebugKind <= CodeGenOptions::DebugLineTablesOnly
   ? llvm::DIBuilder::LineTablesOnly
   : llvm::DIBuilder::FullDebug,
-  0 /* DWOid */,
-  DebugKind != CodeGenOptions::LocTrackingOnly);
+  0 /* DWOid */, DebugKind != CodeGenOptions::LocTrackingOnly);
 }
 
 llvm::DIType *CGDebugInfo::CreateType(const BuiltinType *BT) {
@@ -775,9 +768,9 @@ llvm::DIType *CGDebugInfo::CreateType(co
   Ty->getTemplateName().getAsTemplateDecl())->getTemplatedDecl();
 
   SourceLocation Loc = AliasDecl->getLocation();
-  return DBuilder.createTypedef(
-  Src, internString(OS.str()), getOrCreateFile(Loc), getLineNumber(Loc),
-  getDeclContextDescriptor(AliasDecl));
+  return DBuilder.createTypedef(Src, OS.str(), getOrCreateFile(Loc),
+getLineNumber(Loc),
+getDeclContextDescriptor(AliasDecl));
 }
 
 llvm::DIType *CGDebugInfo::CreateType(const TypedefType *Ty,
@@ -1688,13 +1681,13 @@ CGDebugInfo::getOrCreateModuleRef(Extern
 }
   }
   llvm::DIBuilder DIB(CGM.getModule());
-  auto *CU = DIB.createCompileUnit(
-  TheCU->getSourceLanguage(), internString(Mod.ModuleName),
-  internString(Mod.Path), TheCU->getProducer(), true, StringRef(), 0,
-  internString(Mod.ASTFile), llvm::DIBuilder::FullDebug, Mod.Signature);
-  llvm::DIModule *M = DIB.createModule(
-  CU, Mod.ModuleName, ConfigMacros, internString(Mod.Path),
-  internString(CGM.getHeaderSearchOpts().Sysroot));
+  auto *CU = DIB.createCompileUnit(TheCU->getSourceLanguage(), Mod.ModuleName,
+   Mod.Path, TheCU->getProducer(), true,
+   StringRef(), 0, Mod.ASTFile,
+   llvm::DIBuilder::FullDebug, Mod.Signature);
+  llvm::DIModule *M =
+  DIB.createModule(CU, Mod.ModuleName, ConfigMacros, Mod.Path,
+   CGM.getHeaderSearchOpts().Sysroot);
   DIB.finalize();
   ModRef.reset(M);
   return M;


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

r247447 - Remove a redundant check from CGDebugInfo::shouldOmitDefinition() (NFC).

[Adrian Prantl via cfe-commits]

Author: adrian
Date: Fri Sep 11 13:54:28 2015
New Revision: 247447

URL: http://llvm.org/viewvc/llvm-project?rev=247447&view=rev
Log:
Remove a redundant check from CGDebugInfo::shouldOmitDefinition() (NFC).

Modified:
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp

Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=247447&r1=247446&r2=247447&view=diff
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Fri Sep 11 13:54:28 2015
@@ -1480,14 +1480,8 @@ static bool shouldOmitDefinition(CodeGen
  const RecordDecl *RD,
  const LangOptions &LangOpts) {
   // Does the type exist in an imported clang module?
-  if (DebugTypeExtRefs && RD->isFromASTFile()) {
-if (auto *CTSD = dyn_cast(RD))
-  if (CTSD->isExplicitInstantiationOrSpecialization())
-// We may not assume that this type made it into the module.
-return true;
-if (RD->getDefinition())
+  if (DebugTypeExtRefs && RD->isFromASTFile() && RD->getDefinition())
   return true;
-  }
 
   if (DebugKind > CodeGenOptions::LimitedDebugInfo)
 return false;


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

Re: r247432 - Module Debugging: Emit forward declarations for types that are defined in

[Adrian Prantl via cfe-commits]

> On Sep 11, 2015, at 11:21 AM, David Blaikie  wrote:
> 
> 
> 
> On Fri, Sep 11, 2015 at 10:23 AM, Adrian Prantl via cfe-commits 
> mailto:cfe-commits@lists.llvm.org>> wrote:
> Author: adrian
> Date: Fri Sep 11 12:23:08 2015
> New Revision: 247432
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=247432&view=rev 
> 
> Log:
> Module Debugging: Emit forward declarations for types that are defined in
> clang modules, if -dwarf-ext-refs (DebugTypesExtRefs) is specified.
> 
> This reimplements r247369 in about a third of the amount of code.
> Thanks to David Blaikie pointing this out in post-commit review!
> 
> Added:
> cfe/trunk/test/Modules/ExtDebugInfo.cpp
> cfe/trunk/test/Modules/ExtDebugInfo.m
> Modified:
> cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
> cfe/trunk/lib/CodeGen/CGDebugInfo.h
> 
> Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=247432&r1=247431&r2=247432&view=diff
>  
> 
> ==
> --- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Fri Sep 11 12:23:08 2015
> @@ -148,7 +148,9 @@ void CGDebugInfo::setLocation(SourceLoca
>  }
> 
>  llvm::DIScope *CGDebugInfo::getDeclContextDescriptor(const Decl *D) {
> -  return getContextDescriptor(cast(D->getDeclContext()), TheCU);
> +  llvm::DIScope *Mod = getParentModuleOrNull(D);
> +  return getContextDescriptor(cast(D->getDeclContext()),
> +  Mod ? Mod : TheCU);
> 
> Might've been nice to separate the module-parenting part of the change, 
> smaller patches (easier to revert, review, etc), the usual stuff.
>  
>  }
> 
>  llvm::DIScope *CGDebugInfo::getContextDescriptor(const Decl *Context,
> @@ -1448,6 +1450,9 @@ void CGDebugInfo::completeRequiredType(c
>  if (CXXDecl->isDynamicClass())
>return;
> 
> +  if (DebugTypeExtRefs && RD->isFromASTFile())
> +return;
> +
>QualType Ty = CGM.getContext().getRecordType(RD);
>llvm::DIType *T = getTypeOrNull(Ty);
>if (T && T->isForwardDecl())
> @@ -1478,8 +1483,19 @@ static bool hasExplicitMemberDefinition(
>  }
> 
>  static bool shouldOmitDefinition(CodeGenOptions::DebugInfoKind DebugKind,
> + bool DebugTypeExtRefs,
>   const RecordDecl *RD,
>   const LangOptions &LangOpts) {
> +  // Does the type exist in an imported clang module?
> +  if (DebugTypeExtRefs && RD->isFromASTFile()) {
> +if (auto *CTSD = dyn_cast(RD))
> +  if (CTSD->isExplicitInstantiationOrSpecialization())
> +// We may not assume that this type made it into the module.
> 
> I guess you mean "we may assume this type made it into the module"? (the 
> "not" seems erroneous - but perhaps I'm misparsing the sentence?)

Yes, I inverted the condition without inverting the comment.

>  
> +return true;
> 
> Does this case ^ actually do anything? (aren't all these instantiations going 
> to be definitions anyway? so if you removed that code the below would return 
> true anyway, wouldn't it?)

Good catch! I removed the condition.

>  
> +if (RD->getDefinition())
> +  return true;
> +  }
> +
>if (DebugKind > CodeGenOptions::LimitedDebugInfo)
>  return false;
> 
> @@ -1513,7 +1529,8 @@ static bool shouldOmitDefinition(CodeGen
>  llvm::DIType *CGDebugInfo::CreateType(const RecordType *Ty) {
>RecordDecl *RD = Ty->getDecl();
>llvm::DIType *T = cast_or_null(getTypeOrNull(QualType(Ty, 
> 0)));
> -  if (T || shouldOmitDefinition(DebugKind, RD, CGM.getLangOpts())) {
> +  if (T || shouldOmitDefinition(DebugKind, DebugTypeExtRefs, RD,
> +CGM.getLangOpts())) {
>  if (!T)
>T = getOrCreateRecordFwdDecl(Ty, getDeclContextDescriptor(RD));
>  return T;
> @@ -1616,6 +1633,12 @@ llvm::DIType *CGDebugInfo::CreateType(co
>if (!ID)
>  return nullptr;
> 
> +  // Return a forward declaration if this type was imported from a clang 
> module.
> 
> What's this extra code needed for? Isn't this what shouldOmitDefinition 
> already does? It causes calls to getOrCreateRecordFwdDecl and so we should 
> never get into the CreateTypeDefinition function for the type.

An ObjCInterfaceType is not a RecordDecl, so we have to replicate this here.
>  
> +  if (DebugTypeExtRefs && ID->isFromASTFile() && ID->getDefinition())
> +return DBuilder.createForwardDecl(llvm::dwarf::DW_TAG_structure_type,
> +  ID->getName(),
> +  getDeclContextDescriptor(ID), Unit, 0);
> +
>// Get overall information about the record type for the debug info.
>llvm::DIFile *DefUnit = getOrCreateFile(ID->getLocatio

r247448 - Remove an unnecessary check. NFC

[Adrian Prantl via cfe-commits]

Author: adrian
Date: Fri Sep 11 13:54:31 2015
New Revision: 247448

URL: http://llvm.org/viewvc/llvm-project?rev=247448&view=rev
Log:
Remove an unnecessary check. NFC

Modified:
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp

Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=247448&r1=247447&r2=247448&view=diff
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Fri Sep 11 13:54:31 2015
@@ -2129,7 +2129,7 @@ ObjCInterfaceDecl *CGDebugInfo::getObjCI
 }
 
 llvm::DIModule *CGDebugInfo::getParentModuleOrNull(const Decl *D) {
-  if (!DebugTypeExtRefs || !D || !D->isFromASTFile())
+  if (!DebugTypeExtRefs || !D->isFromASTFile())
 return nullptr;
 
   llvm::DIModule *ModuleRef = nullptr;


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

r247449 - Fix a typo and make this test stricter.

[Adrian Prantl via cfe-commits]

Author: adrian
Date: Fri Sep 11 13:54:34 2015
New Revision: 247449

URL: http://llvm.org/viewvc/llvm-project?rev=247449&view=rev
Log:
Fix a typo and make this test stricter.

Modified:
cfe/trunk/test/Modules/ExtDebugInfo.m

Modified: cfe/trunk/test/Modules/ExtDebugInfo.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/ExtDebugInfo.m?rev=247449&r1=247448&r2=247449&view=diff
==
--- cfe/trunk/test/Modules/ExtDebugInfo.m (original)
+++ cfe/trunk/test/Modules/ExtDebugInfo.m Fri Sep 11 13:54:34 2015
@@ -1,5 +1,5 @@
 // RUN: rm -rf %t
-// Test that only forward declarations are emitted for types dfined in modules.
+// Test that only forward declarations are emitted for types defined in 
modules.
 
 // Modules:
 // RUN: %clang_cc1 -x objective-c -g -dwarf-ext-refs -fmodules \
@@ -23,7 +23,10 @@ int foo(ObjCClass *c) {
   return [c property];
 }
 
-// CHECK: !DICompositeType(tag: DW_TAG_structure_type,
+// CHECK-NOT: !DICompositeType(tag: DW_TAG_structure_type,
+// CHECK: !DICompositeType(tag: DW_TAG_structure_type, name: "ObjCClass",
 // CHECK-SAME: scope: ![[MOD:[0-9]+]],
 // CHECK-SAME: flags: DIFlagFwdDecl)
+// CHECK-NOT: !DICompositeType(tag: DW_TAG_structure_type,
 // CHECK: ![[MOD]] = !DIModule(scope: null, name: {{.*}}DebugObjC
+// CHECK-NOT: !DICompositeType(tag: DW_TAG_structure_type,


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

r247451 - Record function attribute "stackrealign" instead of using backend option

[Akira Hatanaka via cfe-commits]

Author: ahatanak
Date: Fri Sep 11 13:55:09 2015
New Revision: 247451

URL: http://llvm.org/viewvc/llvm-project?rev=247451&view=rev
Log:
Record function attribute "stackrealign" instead of using backend option
-force-align-stack.

Also, make changes to the driver so that -mno-stack-realign is no longer
an option exposed to the end-user that disallows stack realignment in
the backend.

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

Added:
cfe/trunk/test/CodeGen/stackrealign.c
Modified:
cfe/trunk/include/clang/Frontend/CodeGenOptions.def
cfe/trunk/lib/CodeGen/CGCall.cpp
cfe/trunk/lib/Driver/Tools.cpp
cfe/trunk/test/Driver/rewrite-legacy-objc.m
cfe/trunk/test/Driver/rewrite-objc.m
cfe/trunk/test/Driver/stackrealign.c

Modified: cfe/trunk/include/clang/Frontend/CodeGenOptions.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/CodeGenOptions.def?rev=247451&r1=247450&r2=247451&view=diff
==
--- cfe/trunk/include/clang/Frontend/CodeGenOptions.def (original)
+++ cfe/trunk/include/clang/Frontend/CodeGenOptions.def Fri Sep 11 13:55:09 2015
@@ -150,7 +150,7 @@ CODEGENOPT(UseRegisterSizedBitfieldAcces
 CODEGENOPT(VerifyModule  , 1, 1) ///< Control whether the module should be 
run
  ///< through the LLVM Verifier.
 
-CODEGENOPT(StackRealignment  , 1, 0) ///< Control whether to permit stack
+CODEGENOPT(StackRealignment  , 1, 0) ///< Control whether to force stack
  ///< realignment.
 CODEGENOPT(UseInitArray  , 1, 0) ///< Control whether to use .init_array or
  ///< .ctors.

Modified: cfe/trunk/lib/CodeGen/CGCall.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCall.cpp?rev=247451&r1=247450&r2=247451&view=diff
==
--- cfe/trunk/lib/CodeGen/CGCall.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGCall.cpp Fri Sep 11 13:55:09 2015
@@ -1494,8 +1494,8 @@ void CodeGenModule::ConstructAttributeLi
 FuncAttrs.addAttribute("stack-protector-buffer-size",
llvm::utostr(CodeGenOpts.SSPBufferSize));
 
-if (!CodeGenOpts.StackRealignment)
-  FuncAttrs.addAttribute("no-realign-stack");
+if (CodeGenOpts.StackRealignment)
+  FuncAttrs.addAttribute("stackrealign");
 
 // Add target-cpu and target-features attributes to functions. If
 // we have a decl for the function and it has a target attribute then

Modified: cfe/trunk/lib/Driver/Tools.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=247451&r1=247450&r2=247451&view=diff
==
--- cfe/trunk/lib/Driver/Tools.cpp (original)
+++ cfe/trunk/lib/Driver/Tools.cpp Fri Sep 11 13:55:09 2015
@@ -4326,14 +4326,8 @@ void Clang::ConstructJob(Compilation &C,
 
   // Translate -mstackrealign
   if (Args.hasFlag(options::OPT_mstackrealign, options::OPT_mno_stackrealign,
-   false)) {
-CmdArgs.push_back("-backend-option");
-CmdArgs.push_back("-force-align-stack");
-  }
-  if (!Args.hasFlag(options::OPT_mno_stackrealign, options::OPT_mstackrealign,
-false)) {
+   false))
 CmdArgs.push_back(Args.MakeArgString("-mstackrealign"));
-  }
 
   if (Args.hasArg(options::OPT_mstack_alignment)) {
 StringRef alignment = Args.getLastArgValue(options::OPT_mstack_alignment);

Added: cfe/trunk/test/CodeGen/stackrealign.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/stackrealign.c?rev=247451&view=auto
==
--- cfe/trunk/test/CodeGen/stackrealign.c (added)
+++ cfe/trunk/test/CodeGen/stackrealign.c Fri Sep 11 13:55:09 2015
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 %s -emit-llvm -o - -mstackrealign | FileCheck %s 
-check-prefix=REALIGN
+// RUN: %clang_cc1 %s -emit-llvm -o - | FileCheck %s -check-prefix=NO-REALIGN
+
+// REALIGN: attributes #{{[0-9]+}} = {{{.*}} "stackrealign"
+// NO-REALIGN-NOT: attributes #{{[0-9]+}} = {{{.*}} "stackrealign"
+
+void test1() {
+}

Modified: cfe/trunk/test/Driver/rewrite-legacy-objc.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/rewrite-legacy-objc.m?rev=247451&r1=247450&r2=247451&view=diff
==
--- cfe/trunk/test/Driver/rewrite-legacy-objc.m (original)
+++ cfe/trunk/test/Driver/rewrite-legacy-objc.m Fri Sep 11 13:55:09 2015
@@ -3,11 +3,11 @@
 // TEST0: clang{{.*}}" "-cc1"
 // TEST0: "-rewrite-objc"
 // FIXME: CHECK-NOT is broken somehow, it doesn't work here. Check adjacency 
instead.
-// TEST0: "-fmessage-length" "0" "-stack-protector" "1" "-mstackrealign" 
"-fblocks" "-fobjc-runtime=macosx-fragile" "-fencode-extended-block-signature" 
"-fno-objc-infer

Re: [PATCH] D11815: Pass subtarget feature "force-align-stack"

[Akira Hatanaka via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL247451: Record function attribute "stackrealign" instead of 
using backend option (authored by ahatanak).

Changed prior to commit:
  http://reviews.llvm.org/D11815?vs=33456&id=34569#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D11815

Files:
  cfe/trunk/include/clang/Frontend/CodeGenOptions.def
  cfe/trunk/lib/CodeGen/CGCall.cpp
  cfe/trunk/lib/Driver/Tools.cpp
  cfe/trunk/test/CodeGen/stackrealign.c
  cfe/trunk/test/Driver/rewrite-legacy-objc.m
  cfe/trunk/test/Driver/rewrite-objc.m
  cfe/trunk/test/Driver/stackrealign.c

Index: cfe/trunk/include/clang/Frontend/CodeGenOptions.def
===
--- cfe/trunk/include/clang/Frontend/CodeGenOptions.def
+++ cfe/trunk/include/clang/Frontend/CodeGenOptions.def
@@ -150,7 +150,7 @@
 CODEGENOPT(VerifyModule  , 1, 1) ///< Control whether the module should be run
  ///< through the LLVM Verifier.
 
-CODEGENOPT(StackRealignment  , 1, 0) ///< Control whether to permit stack
+CODEGENOPT(StackRealignment  , 1, 0) ///< Control whether to force stack
  ///< realignment.
 CODEGENOPT(UseInitArray  , 1, 0) ///< Control whether to use .init_array or
  ///< .ctors.
Index: cfe/trunk/test/CodeGen/stackrealign.c
===
--- cfe/trunk/test/CodeGen/stackrealign.c
+++ cfe/trunk/test/CodeGen/stackrealign.c
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 %s -emit-llvm -o - -mstackrealign | FileCheck %s -check-prefix=REALIGN
+// RUN: %clang_cc1 %s -emit-llvm -o - | FileCheck %s -check-prefix=NO-REALIGN
+
+// REALIGN: attributes #{{[0-9]+}} = {{{.*}} "stackrealign"
+// NO-REALIGN-NOT: attributes #{{[0-9]+}} = {{{.*}} "stackrealign"
+
+void test1() {
+}
Index: cfe/trunk/test/Driver/rewrite-objc.m
===
--- cfe/trunk/test/Driver/rewrite-objc.m
+++ cfe/trunk/test/Driver/rewrite-objc.m
@@ -3,4 +3,4 @@
 // TEST0: clang{{.*}}" "-cc1"
 // TEST0: "-rewrite-objc"
 // FIXME: CHECK-NOT is broken somehow, it doesn't work here. Check adjacency instead.
-// TEST0: "-fmessage-length" "0" "-stack-protector" "1" "-mstackrealign" "-fblocks" "-fobjc-runtime=macosx" "-fencode-extended-block-signature" "-fno-objc-infer-related-result-type" "-fobjc-exceptions" "-fexceptions" "-fmax-type-align=16" "-fdiagnostics-show-option"
+// TEST0: "-fmessage-length" "0" "-stack-protector" "1" "-fblocks" "-fobjc-runtime=macosx" "-fencode-extended-block-signature" "-fno-objc-infer-related-result-type" "-fobjc-exceptions" "-fexceptions" "-fmax-type-align=16" "-fdiagnostics-show-option"
Index: cfe/trunk/test/Driver/stackrealign.c
===
--- cfe/trunk/test/Driver/stackrealign.c
+++ cfe/trunk/test/Driver/stackrealign.c
@@ -1,12 +1,6 @@
-// RUN: %clang -### %s 2>&1 | FileCheck %s -check-prefix=NORMAL
-// NORMAL-NOT: -force-align-stack
-// NORMAL: -mstackrealign
+// RUN: %clang -### %s 2>&1 | FileCheck %s -check-prefix=NO-REALIGN
+// RUN: %clang -### -mno-stackrealign -mstackrealign %s 2>&1 | FileCheck %s -check-prefix=REALIGN
+// RUN: %clang -### -mstackrealign -mno-stackrealign %s 2>&1 | FileCheck %s -check-prefix=NO-REALIGN
 
-// RUN: %clang -### -mstackrealign %s 2>&1 | FileCheck %s -check-prefix=MREALIGN
-// MREALIGN: -force-align-stack
-// MREALIGN: -mstackrealign
-
-// RUN: %clang -### -mno-stackrealign %s 2>&1 | \
-// RUN: FileCheck %s -check-prefix=MNOREALIGN
-// MNOREALIGN-NOT: -force-align-stack
-// MNOREALIGN-NOT: -mstackrealign
+// REALIGN: -mstackrealign
+// NO-REALIGN-NOT: -mstackrealign
Index: cfe/trunk/test/Driver/rewrite-legacy-objc.m
===
--- cfe/trunk/test/Driver/rewrite-legacy-objc.m
+++ cfe/trunk/test/Driver/rewrite-legacy-objc.m
@@ -3,11 +3,11 @@
 // TEST0: clang{{.*}}" "-cc1"
 // TEST0: "-rewrite-objc"
 // FIXME: CHECK-NOT is broken somehow, it doesn't work here. Check adjacency instead.
-// TEST0: "-fmessage-length" "0" "-stack-protector" "1" "-mstackrealign" "-fblocks" "-fobjc-runtime=macosx-fragile" "-fencode-extended-block-signature" "-fno-objc-infer-related-result-type" "-fobjc-exceptions" "-fexceptions" "-fmax-type-align=16" "-fdiagnostics-show-option"
+// TEST0: "-fmessage-length" "0" "-stack-protector" "1" "-fblocks" "-fobjc-runtime=macosx-fragile" "-fencode-extended-block-signature" "-fno-objc-infer-related-result-type" "-fobjc-exceptions" "-fexceptions" "-fmax-type-align=16" "-fdiagnostics-show-option"
 // TEST0: rewrite-legacy-objc.m"
 // RUN: %clang -no-canonical-prefixes -target i386-apple-macosx10.9.0 -rewrite-legacy-objc %s -o - -### 2>&1 | \
 // RUN:   FileCheck -check-prefix=TEST1 %s
 // RUN: %clang -no-canonical-prefixes -target i386-apple-macosx10.6.0 -rewrite-legacy-objc %s -o - -### 2>&1 | 

Re: [PATCH] D12780: [analyzer] Add generateErrorNode() APIs to CheckerContext

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

xazax.hun added a comment.

In general I like this change, the node handling of the checkers are more 
readable and reflects the intent in a clearer way.  I have some comments inline.



Comment at: include/clang/StaticAnalyzer/Core/PathSensitive/CheckerContext.h:244
@@ +243,3 @@
+  const ProgramPointTag *Tag = nullptr) {
+return generateSink(State, /*Pred=*/nullptr,
+   (Tag ? Tag : Location.getTag()));

zaks.anna wrote:
> Please, use a non-null Pred for clarity
The following workflow is not supported by this API: a checker that generates 
multiple transition in the same callback (the generated nodes are added 
sequentially to the path), and one of the might be an error node.

This also applies to generateNonFatalErrorNode.

In case we would like to improve the documentation it might be useful to give 
some pointers to the users which when should an error node be considered as 
fatal.


Comment at: include/clang/StaticAnalyzer/Core/PathSensitive/CheckerContext.h:322
@@ -290,1 +321,3 @@
+// the same as the predecessor state has made a mistake. We return the
+// predecessor and rather than cache out.
 if (!State || (State == Pred->getState() && !Tag && !MarkAsSink))

As a slightly related note: is it documented anywhere what "cache out" means? 
Maybe it would be great to refer to that document or write it if it is not 
written yet.


http://reviews.llvm.org/D12780



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

Re: r246877 - Increase accuracy of __builtin_object_size.

[Mikhail Zolotukhin via cfe-commits]

Hi George,

After this commit we started to trap on the following case:

#include 
typedef struct {
  int n;
  char key[1];
} obj_t;

char *str = "hello";

int main() {
  obj_t* p = (obj_t*)malloc(strlen(str) + 1 + sizeof(int));
  strcpy(p->key, str);
  free(p);
  return 0;
}

As far as I understand, this might be a common pattern in pre-C99 codebase, and 
it fails when compiled with -D_FORTIFY_SOURCE=2. Is there a way we could fix it 
in clang, or the only fix is to use less strict FORTIFY_SOURCE level?

Thanks,
Michael

> On Sep 4, 2015, at 2:28 PM, George Burgess IV via cfe-commits 
>  wrote:
> 
> Author: gbiv
> Date: Fri Sep  4 16:28:13 2015
> New Revision: 246877
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=246877&view=rev
> Log:
> Increase accuracy of __builtin_object_size.
> 
> Improvements:
> 
> - For all types, we would give up in a case such as:
>__builtin_object_size((char*)&foo, N);
>  even if we could provide an answer to
>__builtin_object_size(&foo, N);
>  We now provide the same answer for both of the above examples in all
>  cases.
> 
> - For type=1|3, we now support subobjects with unknown bases, as long
>  as the designator is valid.
> 
> Thanks to Richard Smith for the review + design planning.
> 
> Review: http://reviews.llvm.org/D12169
> 
> 
> Modified:
>cfe/trunk/lib/AST/ExprConstant.cpp
>cfe/trunk/test/CodeGen/object-size.c
> 
> Modified: cfe/trunk/lib/AST/ExprConstant.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ExprConstant.cpp?rev=246877&r1=246876&r2=246877&view=diff
> ==
> --- cfe/trunk/lib/AST/ExprConstant.cpp (original)
> +++ cfe/trunk/lib/AST/ExprConstant.cpp Fri Sep  4 16:28:13 2015
> @@ -492,7 +492,11 @@ namespace {
>   /// optimizer if we don't constant fold them here, but in an unevaluated
>   /// context we try to fold them immediately since the optimizer never
>   /// gets a chance to look at it.
> -  EM_PotentialConstantExpressionUnevaluated
> +  EM_PotentialConstantExpressionUnevaluated,
> +
> +  /// Evaluate as a constant expression. Continue evaluating if we find a
> +  /// MemberExpr with a base that can't be evaluated.
> +  EM_DesignatorFold,
> } EvalMode;
> 
> /// Are we checking whether the expression is a potential constant
> @@ -595,6 +599,7 @@ namespace {
>   case EM_PotentialConstantExpression:
>   case EM_ConstantExpressionUnevaluated:
>   case EM_PotentialConstantExpressionUnevaluated:
> +  case EM_DesignatorFold:
> HasActiveDiagnostic = false;
> return OptionalDiagnostic();
>   }
> @@ -674,6 +679,7 @@ namespace {
>   case EM_ConstantExpression:
>   case EM_ConstantExpressionUnevaluated:
>   case EM_ConstantFold:
> +  case EM_DesignatorFold:
> return false;
>   }
>   llvm_unreachable("Missed EvalMode case");
> @@ -702,10 +708,15 @@ namespace {
>   case EM_ConstantExpressionUnevaluated:
>   case EM_ConstantFold:
>   case EM_IgnoreSideEffects:
> +  case EM_DesignatorFold:
> return false;
>   }
>   llvm_unreachable("Missed EvalMode case");
> }
> +
> +bool allowInvalidBaseExpr() const {
> +  return EvalMode == EM_DesignatorFold;
> +}
>   };
> 
>   /// Object used to treat all foldable expressions as constant expressions.
> @@ -736,6 +747,21 @@ namespace {
> }
>   };
> 
> +  /// RAII object used to treat the current evaluation as the correct pointer
> +  /// offset fold for the current EvalMode
> +  struct FoldOffsetRAII {
> +EvalInfo &Info;
> +EvalInfo::EvaluationMode OldMode;
> +explicit FoldOffsetRAII(EvalInfo &Info, bool Subobject)
> +: Info(Info), OldMode(Info.EvalMode) {
> +  if (!Info.checkingPotentialConstantExpression())
> +Info.EvalMode = Subobject ? EvalInfo::EM_DesignatorFold
> +  : EvalInfo::EM_ConstantFold;
> +}
> +
> +~FoldOffsetRAII() { Info.EvalMode = OldMode; }
> +  };
> +
>   /// RAII object used to suppress diagnostics and side-effects from a
>   /// speculative evaluation.
>   class SpeculativeEvaluationRAII {
> @@ -917,7 +943,8 @@ namespace {
>   struct LValue {
> APValue::LValueBase Base;
> CharUnits Offset;
> -unsigned CallIndex;
> +bool InvalidBase : 1;
> +unsigned CallIndex : 31;
> SubobjectDesignator Designator;
> 
> const APValue::LValueBase getLValueBase() const { return Base; }
> @@ -938,17 +965,23 @@ namespace {
>   assert(V.isLValue());
>   Base = V.getLValueBase();
>   Offset = V.getLValueOffset();
> +  InvalidBase = false;
>   CallIndex = V.getLValueCallIndex();
>   Designator = SubobjectDesignator(Ctx, V);
> }
> 
> -void set(APValue::LValueBase B, unsigned I = 0) {
> +void set(APValue::LValueBase B, unsigned I = 0, bool BInvalid = false) {
>   Base = B;
>   Offset = CharUnits::Zero();

Re: [PATCH] D12780: [analyzer] Add generateErrorNode() APIs to CheckerContext

[Jordan Rose via cfe-commits]

jordan_rose added inline comments.


Comment at: lib/StaticAnalyzer/Checkers/FixedAddressChecker.cpp:53
@@ -52,3 +52,3 @@
 
-  if (ExplodedNode *N = C.addTransition()) {
+  if (ExplodedNode *N = C.generateNonFatalErrorNode()) {
 if (!BT)

zaks.anna wrote:
> Can this ever fail? In some cases we just assume it won't in others we tests..
> 
> Maybe it only fails when we cache out?
It does fail when we cache out, and I think we can still cache out if Pred has 
a different tag the second time around.


http://reviews.llvm.org/D12780



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

Re: r247346 - [MS ABI] Make member pointers return true for isIncompleteType

[David Majnemer via cfe-commits]

Reduced it a bit:
template 
void JSMethod();
class A {
  int printd(int);
  void printd();
};
void A::printd() { JSMethod(); }

This test case will crash clang at the revision before this commit which
means that something more mysterious/horrific is going on...

On Fri, Sep 11, 2015 at 11:10 AM, David Majnemer 
wrote:

> Taking a look, would appreciate it if we didn't revert this until I give
> it a fair shot.  Shouldn't take too long.
>
> On Fri, Sep 11, 2015 at 10:58 AM, Hans Wennborg  wrote:
>
>> This made the Chromium build sad. For example:
>>
>> http://build.chromium.org/p/chromium.fyi/builders/ClangToTWin/builds/3092/steps/compile/logs/stdio
>>
>> Reduction:
>>
>> $ clang -cc1 -triple i686-pc-windows-msvc18.0.0 -w -fms-extensions
>> -fms-compatibility -fms-compatibility-version=18.0 -std=c++11
>> -fdelayed-template-parsing a.ii
>>
>> template 
>> void JSMethod(char *, char *, int);
>> class A {
>>   int printd(int *, const int &, int &, int &);
>>   int printd_info;
>>   void printd() { JSMethod("", "", printd_info); }
>> };
>>
>>
>> On Thu, Sep 10, 2015 at 2:52 PM, David Majnemer via cfe-commits
>>  wrote:
>> > Author: majnemer
>> > Date: Thu Sep 10 16:52:00 2015
>> > New Revision: 247346
>> >
>> > URL: http://llvm.org/viewvc/llvm-project?rev=247346&view=rev
>> > Log:
>> > [MS ABI] Make member pointers return true for isIncompleteType
>> >
>> > The type of a member pointer is incomplete if it has no inheritance
>> > model.  This lets us reuse more general logic already embedded in clang.
>>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r247432 - Module Debugging: Emit forward declarations for types that are defined in

[David Blaikie via cfe-commits]

On Fri, Sep 11, 2015 at 11:55 AM, Adrian Prantl  wrote:

>
> On Sep 11, 2015, at 11:21 AM, David Blaikie  wrote:
>
>
>
> On Fri, Sep 11, 2015 at 10:23 AM, Adrian Prantl via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: adrian
>> Date: Fri Sep 11 12:23:08 2015
>> New Revision: 247432
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=247432&view=rev
>> Log:
>> Module Debugging: Emit forward declarations for types that are defined in
>> clang modules, if -dwarf-ext-refs (DebugTypesExtRefs) is specified.
>>
>> This reimplements r247369 in about a third of the amount of code.
>> Thanks to David Blaikie pointing this out in post-commit review!
>>
>> Added:
>> cfe/trunk/test/Modules/ExtDebugInfo.cpp
>> cfe/trunk/test/Modules/ExtDebugInfo.m
>> Modified:
>> cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
>> cfe/trunk/lib/CodeGen/CGDebugInfo.h
>>
>> Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=247432&r1=247431&r2=247432&view=diff
>>
>> ==
>> --- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
>> +++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Fri Sep 11 12:23:08 2015
>> @@ -148,7 +148,9 @@ void CGDebugInfo::setLocation(SourceLoca
>>  }
>>
>>  llvm::DIScope *CGDebugInfo::getDeclContextDescriptor(const Decl *D) {
>> -  return getContextDescriptor(cast(D->getDeclContext()), TheCU);
>> +  llvm::DIScope *Mod = getParentModuleOrNull(D);
>> +  return getContextDescriptor(cast(D->getDeclContext()),
>> +  Mod ? Mod : TheCU);
>>
>
> Might've been nice to separate the module-parenting part of the change,
> smaller patches (easier to revert, review, etc), the usual stuff.
>
>
>>  }
>>
>>  llvm::DIScope *CGDebugInfo::getContextDescriptor(const Decl *Context,
>> @@ -1448,6 +1450,9 @@ void CGDebugInfo::completeRequiredType(c
>>  if (CXXDecl->isDynamicClass())
>>return;
>>
>> +  if (DebugTypeExtRefs && RD->isFromASTFile())
>> +return;
>> +
>>QualType Ty = CGM.getContext().getRecordType(RD);
>>llvm::DIType *T = getTypeOrNull(Ty);
>>if (T && T->isForwardDecl())
>> @@ -1478,8 +1483,19 @@ static bool hasExplicitMemberDefinition(
>>  }
>>
>>  static bool shouldOmitDefinition(CodeGenOptions::DebugInfoKind DebugKind,
>> + bool DebugTypeExtRefs,
>>   const RecordDecl *RD,
>>   const LangOptions &LangOpts) {
>> +  // Does the type exist in an imported clang module?
>> +  if (DebugTypeExtRefs && RD->isFromASTFile()) {
>> +if (auto *CTSD = dyn_cast(RD))
>> +  if (CTSD->isExplicitInstantiationOrSpecialization())
>> +// We may not assume that this type made it into the module.
>>
>
> I guess you mean "we may assume this type made it into the module"? (the
> "not" seems erroneous - but perhaps I'm misparsing the sentence?)
>
>
> Yes, I inverted the condition without inverting the comment.
>
>
>
>> +return true;
>>
>
> Does this case ^ actually do anything? (aren't all these instantiations
> going to be definitions anyway? so if you removed that code the below would
> return true anyway, wouldn't it?)
>
>
> Good catch! I removed the condition.
>
>
>
>> +if (RD->getDefinition())
>> +  return true;
>> +  }
>> +
>>if (DebugKind > CodeGenOptions::LimitedDebugInfo)
>>  return false;
>>
>> @@ -1513,7 +1529,8 @@ static bool shouldOmitDefinition(CodeGen
>>  llvm::DIType *CGDebugInfo::CreateType(const RecordType *Ty) {
>>RecordDecl *RD = Ty->getDecl();
>>llvm::DIType *T =
>> cast_or_null(getTypeOrNull(QualType(Ty, 0)));
>> -  if (T || shouldOmitDefinition(DebugKind, RD, CGM.getLangOpts())) {
>> +  if (T || shouldOmitDefinition(DebugKind, DebugTypeExtRefs, RD,
>> +CGM.getLangOpts())) {
>>  if (!T)
>>T = getOrCreateRecordFwdDecl(Ty, getDeclContextDescriptor(RD));
>>  return T;
>> @@ -1616,6 +1633,12 @@ llvm::DIType *CGDebugInfo::CreateType(co
>>if (!ID)
>>  return nullptr;
>>
>> +  // Return a forward declaration if this type was imported from a clang
>> module.
>>
>
> What's this extra code needed for? Isn't this what shouldOmitDefinition
> already does? It causes calls to getOrCreateRecordFwdDecl and so we should
> never get into the CreateTypeDefinition function for the type.
>
>
> An ObjCInterfaceType is not a RecordDecl, so we have to replicate this
> here.
>
>
>
>> +  if (DebugTypeExtRefs && ID->isFromASTFile() && ID->getDefinition())
>> +return DBuilder.createForwardDecl(llvm::dwarf::DW_TAG_structure_type,
>> +  ID->getName(),
>> +  getDeclContextDescriptor(ID),
>> Unit, 0);
>> +
>>// Get overall information about the record type for the debug info.
>>llvm::DIFile *DefUnit = getOrCreateFile(ID->getLocation());
>>unsigned Line = 

Re: r247447 - Remove a redundant check from CGDebugInfo::shouldOmitDefinition() (NFC).

[David Blaikie via cfe-commits]

On Fri, Sep 11, 2015 at 11:54 AM, Adrian Prantl via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: adrian
> Date: Fri Sep 11 13:54:28 2015
> New Revision: 247447
>
> URL: http://llvm.org/viewvc/llvm-project?rev=247447&view=rev
> Log:
> Remove a redundant check from CGDebugInfo::shouldOmitDefinition() (NFC).
>
> Modified:
> cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
>
> Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=247447&r1=247446&r2=247447&view=diff
>
> ==
> --- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Fri Sep 11 13:54:28 2015
> @@ -1480,14 +1480,8 @@ static bool shouldOmitDefinition(CodeGen
>   const RecordDecl *RD,
>   const LangOptions &LangOpts) {
>// Does the type exist in an imported clang module?
> -  if (DebugTypeExtRefs && RD->isFromASTFile()) {
> -if (auto *CTSD = dyn_cast(RD))
> -  if (CTSD->isExplicitInstantiationOrSpecialization())
> -// We may not assume that this type made it into the module.
> -return true;
> -if (RD->getDefinition())
> +  if (DebugTypeExtRefs && RD->isFromASTFile() && RD->getDefinition())
>

Oh - and do we need to check for "getDefinition" here? Since this function
is itself (by name/use) already about whether definitions should be
omitted? I'm not sure, maybe it still makes sense...


>return true;
> -  }
>
>if (DebugKind > CodeGenOptions::LimitedDebugInfo)
>  return false;
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D10018: C11 _Bool bitfield diagnostic

[Rachel Craik via cfe-commits]

rcraik updated the summary for this revision.
rcraik updated this revision to Diff 34571.
rcraik added a comment.

switched to using getIntWidth instead of getTypeSize and updated the error and 
warning messages accordingly, as have the necessary test cases. The separate 
check for _Bool bitfields has been removed, so the check is now consistent for 
all types.


http://reviews.llvm.org/D10018

Files:
  include/clang/Basic/DiagnosticGroups.td
  include/clang/Basic/DiagnosticSemaKinds.td
  lib/Sema/SemaDecl.cpp
  test/CodeGen/bitfield-2.c
  test/CodeGenCXX/warn-padded-packed.cpp
  test/Misc/warning-flags.c
  test/Sema/bitfield.c
  test/SemaCXX/bitfield-layout.cpp
  test/SemaCXX/constant-expression-cxx11.cpp
  test/SemaCXX/constant-expression-cxx1y.cpp
  test/SemaCXX/ms_wide_bitfield.cpp
  test/SemaObjC/class-bitfield.m

Index: test/SemaObjC/class-bitfield.m
===
--- test/SemaObjC/class-bitfield.m
+++ test/SemaObjC/class-bitfield.m
@@ -5,7 +5,7 @@
   int a : -1; // expected-error{{bit-field 'a' has negative width}}
 
   // rdar://6081627
-  int b : 33; // expected-error{{size of bit-field 'b' (33 bits) exceeds size of its type (32 bits)}}
+  int b : 33; // expected-error{{width of bit-field 'b' (33 bits) exceeds width of its type (32 bits)}}
 
   int c : (1 + 0.25); // expected-error{{expression is not an integer constant expression}}
   int d : (int)(1 + 0.25); 
Index: test/SemaCXX/ms_wide_bitfield.cpp
===
--- test/SemaCXX/ms_wide_bitfield.cpp
+++ test/SemaCXX/ms_wide_bitfield.cpp
@@ -1,9 +1,10 @@
 // RUN: %clang_cc1 -fno-rtti -emit-llvm-only -triple i686-pc-win32 -fdump-record-layouts -fsyntax-only -mms-bitfields -verify %s 2>&1
 
 struct A {
-  char a : 9; // expected-error{{size of bit-field 'a' (9 bits) exceeds size of its type (8 bits)}}
-  int b : 33; // expected-error{{size of bit-field 'b' (33 bits) exceeds size of its type (32 bits)}}
-  bool c : 9; // expected-error{{size of bit-field 'c' (9 bits) exceeds size of its type (8 bits)}}
+  char a : 9; // expected-error{{width of bit-field 'a' (9 bits) exceeds width of its type (8 bits)}}
+  int b : 33; // expected-error{{width of bit-field 'b' (33 bits) exceeds width of its type (32 bits)}}
+  bool c : 9; // expected-error{{width of bit-field 'c' (9 bits) exceeds width of its type (1 bit)}}
+  bool d : 3; // expected-error{{width of bit-field 'd' (3 bits) exceeds width of its type (1 bit)}}
 };
 
 int a[sizeof(A) == 1 ? 1 : -1];
Index: test/SemaCXX/constant-expression-cxx1y.cpp
===
--- test/SemaCXX/constant-expression-cxx1y.cpp
+++ test/SemaCXX/constant-expression-cxx1y.cpp
@@ -872,7 +872,7 @@
 
 namespace Bitfields {
   struct A {
-bool b : 3;
+bool b : 1;
 int n : 4;
 unsigned u : 5;
   };
Index: test/SemaCXX/constant-expression-cxx11.cpp
===
--- test/SemaCXX/constant-expression-cxx11.cpp
+++ test/SemaCXX/constant-expression-cxx11.cpp
@@ -1801,9 +1801,9 @@
 bool b : 1;
 unsigned u : 5;
 int n : 5;
-bool b2 : 3;
-unsigned u2 : 74; // expected-warning {{exceeds the size of its type}}
-int n2 : 81; // expected-warning {{exceeds the size of its type}}
+bool b2 : 3; // expected-warning {{exceeds the width of its type}}
+unsigned u2 : 74; // expected-warning {{exceeds the width of its type}}
+int n2 : 81; // expected-warning {{exceeds the width of its type}}
   };
 
   constexpr A a = { false, 33, 31, false, 0x, 0x7fff }; // expected-warning 2{{truncation}}
Index: test/SemaCXX/bitfield-layout.cpp
===
--- test/SemaCXX/bitfield-layout.cpp
+++ test/SemaCXX/bitfield-layout.cpp
@@ -5,25 +5,25 @@
 
 // Simple tests.
 struct Test1 {
-  char c : 9; // expected-warning {{size of bit-field 'c' (9 bits) exceeds the size of its type; value will be truncated to 8 bits}}
+  char c : 9; // expected-warning {{width of bit-field 'c' (9 bits) exceeds the width of its type; value will be truncated to 8 bits}}
 };
 CHECK_SIZE(Test1, 2);
 CHECK_ALIGN(Test1, 1);
 
 struct Test2 {
-  char c : 16; // expected-warning {{size of bit-field 'c' (16 bits) exceeds the size of its type; value will be truncated to 8 bits}}
+  char c : 16; // expected-warning {{width of bit-field 'c' (16 bits) exceeds the width of its type; value will be truncated to 8 bits}}
 };
 CHECK_SIZE(Test2, 2);
 CHECK_ALIGN(Test2, 2);
 
 struct Test3 {
-  char c : 32; // expected-warning {{size of bit-field 'c' (32 bits) exceeds the size of its type; value will be truncated to 8 bits}}
+  char c : 32; // expected-warning {{width of bit-field 'c' (32 bits) exceeds the width of its type; value will be truncated to 8 bits}}
 };
 CHECK_SIZE(Test3, 4);
 CHECK_ALIGN(Test3, 4);
 
 struct Test4 {
-  char c : 64; // expected-warning {{size of bit

Re: [PATCH] D10018: C11 _Bool bitfield diagnostic

[Rachel Craik via cfe-commits]

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

http://reviews.llvm.org/D10018



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

r247462 - [Edit] Fix issue with tracking what macro argument inputs have been edited.

[Argyrios Kyrtzidis via cfe-commits]

Author: akirtzidis
Date: Fri Sep 11 15:09:11 2015
New Revision: 247462

URL: http://llvm.org/viewvc/llvm-project?rev=247462&view=rev
Log:
[Edit] Fix issue with tracking what macro argument inputs have been edited.

This was not working correctly, leading to erroneously rejecting valid edits.

Modified:
cfe/trunk/include/clang/Edit/EditedSource.h
cfe/trunk/lib/Edit/EditedSource.cpp
cfe/trunk/test/ARCMT/objcmt-subscripting-literals.m
cfe/trunk/test/ARCMT/objcmt-subscripting-literals.m.result

Modified: cfe/trunk/include/clang/Edit/EditedSource.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Edit/EditedSource.h?rev=247462&r1=247461&r2=247462&view=diff
==
--- cfe/trunk/include/clang/Edit/EditedSource.h (original)
+++ cfe/trunk/include/clang/Edit/EditedSource.h Fri Sep 11 15:09:11 2015
@@ -10,9 +10,11 @@
 #ifndef LLVM_CLANG_EDIT_EDITEDSOURCE_H
 #define LLVM_CLANG_EDIT_EDITEDSOURCE_H
 
+#include "clang/Basic/IdentifierTable.h"
 #include "clang/Edit/FileOffset.h"
 #include "llvm/ADT/DenseMap.h"
 #include "llvm/ADT/StringRef.h"
+#include "llvm/ADT/TinyPtrVector.h"
 #include "llvm/Support/Allocator.h"
 #include 
 
@@ -39,14 +41,18 @@ class EditedSource {
   typedef std::map FileEditsTy;
   FileEditsTy FileEdits;
 
-  llvm::DenseMap ExpansionToArgMap;
+  llvm::DenseMap>
+ExpansionToArgMap;
+  SmallVector, 2>
+CurrCommitMacroArgExps;
 
+  IdentifierTable IdentTable;
   llvm::BumpPtrAllocator StrAlloc;
 
 public:
   EditedSource(const SourceManager &SM, const LangOptions &LangOpts,
const PPConditionalDirectiveRecord *PPRec = nullptr)
-: SourceMgr(SM), LangOpts(LangOpts), PPRec(PPRec),
+: SourceMgr(SM), LangOpts(LangOpts), PPRec(PPRec), IdentTable(LangOpts),
   StrAlloc() { }
 
   const SourceManager &getSourceManager() const { return SourceMgr; }
@@ -76,6 +82,12 @@ private:
   StringRef getSourceText(FileOffset BeginOffs, FileOffset EndOffs,
   bool &Invalid);
   FileEditsTy::iterator getActionForOffset(FileOffset Offs);
+  void deconstructMacroArgLoc(SourceLocation Loc,
+  SourceLocation &ExpansionLoc,
+  IdentifierInfo *&II);
+
+  void startingCommit();
+  void finishedCommit();
 };
 
 }

Modified: cfe/trunk/lib/Edit/EditedSource.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Edit/EditedSource.cpp?rev=247462&r1=247461&r2=247462&view=diff
==
--- cfe/trunk/lib/Edit/EditedSource.cpp (original)
+++ cfe/trunk/lib/Edit/EditedSource.cpp Fri Sep 11 15:09:11 2015
@@ -23,6 +23,36 @@ void EditsReceiver::remove(CharSourceRan
   replace(range, StringRef());
 }
 
+void EditedSource::deconstructMacroArgLoc(SourceLocation Loc,
+  SourceLocation &ExpansionLoc,
+  IdentifierInfo *&II) {
+  assert(SourceMgr.isMacroArgExpansion(Loc));
+  SourceLocation DefArgLoc = SourceMgr.getImmediateExpansionRange(Loc).first;
+  ExpansionLoc = SourceMgr.getImmediateExpansionRange(DefArgLoc).first;
+  SmallString<20> Buf;
+  StringRef ArgName = Lexer::getSpelling(SourceMgr.getSpellingLoc(DefArgLoc),
+ Buf, SourceMgr, LangOpts);
+  II = nullptr;
+  if (!ArgName.empty()) {
+II = &IdentTable.get(ArgName);
+  }
+}
+
+void EditedSource::startingCommit() {}
+
+void EditedSource::finishedCommit() {
+  for (auto &ExpArg : CurrCommitMacroArgExps) {
+SourceLocation ExpLoc;
+IdentifierInfo *II;
+std::tie(ExpLoc, II) = ExpArg;
+auto &ArgNames = ExpansionToArgMap[ExpLoc.getRawEncoding()];
+if (std::find(ArgNames.begin(), ArgNames.end(), II) == ArgNames.end()) {
+  ArgNames.push_back(II);
+}
+  }
+  CurrCommitMacroArgExps.clear();
+}
+
 StringRef EditedSource::copyString(const Twine &twine) {
   SmallString<128> Data;
   return copyString(twine.toStringRef(Data));
@@ -36,15 +66,27 @@ bool EditedSource::canInsertInOffset(Sou
   }
 
   if (SourceMgr.isMacroArgExpansion(OrigLoc)) {
-SourceLocation
-  DefArgLoc = SourceMgr.getImmediateExpansionRange(OrigLoc).first;
-SourceLocation
-  ExpLoc = SourceMgr.getImmediateExpansionRange(DefArgLoc).first;
-llvm::DenseMap::iterator
-  I = ExpansionToArgMap.find(ExpLoc.getRawEncoding());
-if (I != ExpansionToArgMap.end() && I->second != DefArgLoc)
-  return false; // Trying to write in a macro argument input that has
- // already been written for another argument of the same 
macro. 
+IdentifierInfo *II;
+SourceLocation ExpLoc;
+deconstructMacroArgLoc(OrigLoc, ExpLoc, II);
+auto I = ExpansionToArgMap.find(ExpLoc.getRawEncoding());
+if (I != ExpansionToArgMap.end() &&
+std::find(I->second.begin(), I->second.end(), II) != I->second.end()) {
+  // Trying to write in a macro argument input that

Re: [PATCH] D10018: C11 _Bool bitfield diagnostic

[Richard Smith via cfe-commits]

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

Looks great, please go ahead. Sorry it's taken so long to get this reviewed.


http://reviews.llvm.org/D10018



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

r247463 - [analyzer] Add -analyzer-config option for function size the inliner considers as large

[Devin Coughlin via cfe-commits]

Author: dcoughlin
Date: Fri Sep 11 15:14:05 2015
New Revision: 247463

URL: http://llvm.org/viewvc/llvm-project?rev=247463&view=rev
Log:
[analyzer] Add -analyzer-config option for function size the inliner considers 
as large

Add an option (-analyzer-config min-blocks-for-inline-large=14) to control the 
function
size the inliner considers as large, in relation to "max-times-inline-large". 
The option
defaults to the original hard coded behaviour, which I believe should be 
adjustable with
the other inlining settings.

The analyzer-config test has been modified so that the analyzer will reach the
getMinBlocksForInlineLarge() method and store the result in the ConfigTable, to 
ensure it
is dumped by the debug checker.

A patch by Sean Eveson!

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

Modified:
cfe/trunk/include/clang/StaticAnalyzer/Core/AnalyzerOptions.h
cfe/trunk/lib/StaticAnalyzer/Core/AnalyzerOptions.cpp
cfe/trunk/lib/StaticAnalyzer/Core/ExprEngineCallAndReturn.cpp
cfe/trunk/test/Analysis/analyzer-config.c
cfe/trunk/test/Analysis/analyzer-config.cpp

Modified: cfe/trunk/include/clang/StaticAnalyzer/Core/AnalyzerOptions.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/StaticAnalyzer/Core/AnalyzerOptions.h?rev=247463&r1=247462&r2=247463&view=diff
==
--- cfe/trunk/include/clang/StaticAnalyzer/Core/AnalyzerOptions.h (original)
+++ cfe/trunk/include/clang/StaticAnalyzer/Core/AnalyzerOptions.h Fri Sep 11 
15:14:05 2015
@@ -253,6 +253,9 @@ private:
   /// \sa getMaxTimesInlineLarge
   Optional MaxTimesInlineLarge;
 
+  /// \sa getMinCFGSizeTreatFunctionsAsLarge
+  Optional MinCFGSizeTreatFunctionsAsLarge;
+
   /// \sa getMaxNodesPerTopLevelFunction
   Optional MaxNodesPerTopLevelFunction;
 
@@ -505,6 +508,13 @@ public:
   /// This is controlled by the 'max-times-inline-large' config option.
   unsigned getMaxTimesInlineLarge();
 
+  /// Returns the number of basic blocks a function needs to have to be
+  /// considered large for the 'max-times-inline-large' config option.
+  ///
+  /// This is controlled by the 'min-cfg-size-treat-functions-as-large' config
+  /// option.
+  unsigned getMinCFGSizeTreatFunctionsAsLarge();
+
   /// Returns the maximum number of nodes the analyzer can generate while
   /// exploring a top level function (for each exploded graph).
   /// 15 is default; 0 means no limit.

Modified: cfe/trunk/lib/StaticAnalyzer/Core/AnalyzerOptions.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Core/AnalyzerOptions.cpp?rev=247463&r1=247462&r2=247463&view=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Core/AnalyzerOptions.cpp (original)
+++ cfe/trunk/lib/StaticAnalyzer/Core/AnalyzerOptions.cpp Fri Sep 11 15:14:05 
2015
@@ -295,6 +295,13 @@ unsigned AnalyzerOptions::getMaxTimesInl
   return MaxTimesInlineLarge.getValue();
 }
 
+unsigned AnalyzerOptions::getMinCFGSizeTreatFunctionsAsLarge() {
+  if (!MinCFGSizeTreatFunctionsAsLarge.hasValue())
+MinCFGSizeTreatFunctionsAsLarge = getOptionAsInteger(
+  "min-cfg-size-treat-functions-as-large", 14);
+  return MinCFGSizeTreatFunctionsAsLarge.getValue();
+}
+
 unsigned AnalyzerOptions::getMaxNodesPerTopLevelFunction() {
   if (!MaxNodesPerTopLevelFunction.hasValue()) {
 int DefaultValue = 0;

Modified: cfe/trunk/lib/StaticAnalyzer/Core/ExprEngineCallAndReturn.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Core/ExprEngineCallAndReturn.cpp?rev=247463&r1=247462&r2=247463&view=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Core/ExprEngineCallAndReturn.cpp (original)
+++ cfe/trunk/lib/StaticAnalyzer/Core/ExprEngineCallAndReturn.cpp Fri Sep 11 
15:14:05 2015
@@ -870,7 +870,8 @@ bool ExprEngine::shouldInlineCall(const
   // Do not inline large functions too many times.
   if ((Engine.FunctionSummaries->getNumTimesInlined(D) >
Opts.getMaxTimesInlineLarge()) &&
-  CalleeCFG->getNumBlockIDs() > 13) {
+   CalleeCFG->getNumBlockIDs() >=
+   Opts.getMinCFGSizeTreatFunctionsAsLarge()) {
 NumReachedInlineCountMax++;
 return false;
   }

Modified: cfe/trunk/test/Analysis/analyzer-config.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Analysis/analyzer-config.c?rev=247463&r1=247462&r2=247463&view=diff
==
--- cfe/trunk/test/Analysis/analyzer-config.c (original)
+++ cfe/trunk/test/Analysis/analyzer-config.c Fri Sep 11 15:14:05 2015
@@ -1,22 +1,30 @@
-// RUN: %clang -target x86_64-apple-darwin10 --analyze %s -o /dev/null -Xclang 
-analyzer-checker=debug.ConfigDumper > %t 2>&1
+// RUN: %clang -target x86_64-apple-darwin10 --analyze %s -o /dev/null -Xclang 
-analyzer-checker=debug.ConfigDumper -Xclang -analyzer-max-loop -Xclang 34 >

Re: [PATCH] D12743: [CodeGen] Teach SimplifyPersonality about the updated LandingPadInst

[John McCall via cfe-commits]

rjmccall added a comment.

In http://reviews.llvm.org/D12743#244375, @vsk wrote:

> Ah, ok. We have some objective-c++ code which calls into a boost routine 
> which throws an exception. That results in an undefined reference to 
> ___objc_personality_v0, because the boost library we linked against doesn't 
> have ___objc_personality_v0.
>
> Should the compiler have found the ___objc_personality_v0 symbol in this case 
> regardless?


It's pretty straightforward.  Sometimes people write code in ObjC++ files 
that's really pure C++.  Such code is generally compiled with -fexceptions 
because that's the default, and so it has cleanups, and those cleanups require 
us to pick a personality function.  When they do so, they generally don't link 
against the ObjC runtime, and so __objc_personality_v0 isn't found.  The 
workaround here is to recognize that they're not actually catching ObjC 
exception types and just quietly degrade to use the C++ personality.

It is probably technically an optimization, because it removes some overhead 
from double-parsing the exception tables (because the ObjC personality 
delegates to the C++ personality, instead of being tightly integrated with it), 
but that's not the real reason we do it.


Repository:
  rL LLVM

http://reviews.llvm.org/D12743



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

Re: [PATCH] D12406: [Analyzer] Add -analyzer-config option for function size the inliner considers as large

[Devin Coughlin via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL247463: [analyzer] Add -analyzer-config option for function 
size the inliner… (authored by dcoughlin).

Changed prior to commit:
  http://reviews.llvm.org/D12406?vs=34196&id=34574#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D12406

Files:
  cfe/trunk/include/clang/StaticAnalyzer/Core/AnalyzerOptions.h
  cfe/trunk/lib/StaticAnalyzer/Core/AnalyzerOptions.cpp
  cfe/trunk/lib/StaticAnalyzer/Core/ExprEngineCallAndReturn.cpp
  cfe/trunk/test/Analysis/analyzer-config.c
  cfe/trunk/test/Analysis/analyzer-config.cpp

Index: cfe/trunk/lib/StaticAnalyzer/Core/ExprEngineCallAndReturn.cpp
===
--- cfe/trunk/lib/StaticAnalyzer/Core/ExprEngineCallAndReturn.cpp
+++ cfe/trunk/lib/StaticAnalyzer/Core/ExprEngineCallAndReturn.cpp
@@ -870,7 +870,8 @@
   // Do not inline large functions too many times.
   if ((Engine.FunctionSummaries->getNumTimesInlined(D) >
Opts.getMaxTimesInlineLarge()) &&
-  CalleeCFG->getNumBlockIDs() > 13) {
+   CalleeCFG->getNumBlockIDs() >=
+   Opts.getMinCFGSizeTreatFunctionsAsLarge()) {
 NumReachedInlineCountMax++;
 return false;
   }
Index: cfe/trunk/lib/StaticAnalyzer/Core/AnalyzerOptions.cpp
===
--- cfe/trunk/lib/StaticAnalyzer/Core/AnalyzerOptions.cpp
+++ cfe/trunk/lib/StaticAnalyzer/Core/AnalyzerOptions.cpp
@@ -295,6 +295,13 @@
   return MaxTimesInlineLarge.getValue();
 }
 
+unsigned AnalyzerOptions::getMinCFGSizeTreatFunctionsAsLarge() {
+  if (!MinCFGSizeTreatFunctionsAsLarge.hasValue())
+MinCFGSizeTreatFunctionsAsLarge = getOptionAsInteger(
+  "min-cfg-size-treat-functions-as-large", 14);
+  return MinCFGSizeTreatFunctionsAsLarge.getValue();
+}
+
 unsigned AnalyzerOptions::getMaxNodesPerTopLevelFunction() {
   if (!MaxNodesPerTopLevelFunction.hasValue()) {
 int DefaultValue = 0;
Index: cfe/trunk/include/clang/StaticAnalyzer/Core/AnalyzerOptions.h
===
--- cfe/trunk/include/clang/StaticAnalyzer/Core/AnalyzerOptions.h
+++ cfe/trunk/include/clang/StaticAnalyzer/Core/AnalyzerOptions.h
@@ -253,6 +253,9 @@
   /// \sa getMaxTimesInlineLarge
   Optional MaxTimesInlineLarge;
 
+  /// \sa getMinCFGSizeTreatFunctionsAsLarge
+  Optional MinCFGSizeTreatFunctionsAsLarge;
+
   /// \sa getMaxNodesPerTopLevelFunction
   Optional MaxNodesPerTopLevelFunction;
 
@@ -505,6 +508,13 @@
   /// This is controlled by the 'max-times-inline-large' config option.
   unsigned getMaxTimesInlineLarge();
 
+  /// Returns the number of basic blocks a function needs to have to be
+  /// considered large for the 'max-times-inline-large' config option.
+  ///
+  /// This is controlled by the 'min-cfg-size-treat-functions-as-large' config
+  /// option.
+  unsigned getMinCFGSizeTreatFunctionsAsLarge();
+
   /// Returns the maximum number of nodes the analyzer can generate while
   /// exploring a top level function (for each exploded graph).
   /// 15 is default; 0 means no limit.
Index: cfe/trunk/test/Analysis/analyzer-config.c
===
--- cfe/trunk/test/Analysis/analyzer-config.c
+++ cfe/trunk/test/Analysis/analyzer-config.c
@@ -1,22 +1,30 @@
-// RUN: %clang -target x86_64-apple-darwin10 --analyze %s -o /dev/null -Xclang -analyzer-checker=debug.ConfigDumper > %t 2>&1
+// RUN: %clang -target x86_64-apple-darwin10 --analyze %s -o /dev/null -Xclang -analyzer-checker=debug.ConfigDumper -Xclang -analyzer-max-loop -Xclang 34 > %t 2>&1
 // RUN: FileCheck --input-file=%t %s
 
 void bar() {}
-void foo() { bar(); }
+void foo() {
+  // Call bar 33 times so max-times-inline-large is met and
+  // min-blocks-for-inline-large is checked
+  for (int i = 0; i < 34; ++i) {
+bar();
+  }
+}
 
 // CHECK: [config]
 // CHECK-NEXT: cfg-conditional-static-initializers = true
 // CHECK-NEXT: cfg-temporary-dtors = false
 // CHECK-NEXT: faux-bodies = true
 // CHECK-NEXT: graph-trim-interval = 1000
+// CHECK-NEXT: inline-lambdas = true
 // CHECK-NEXT: ipa = dynamic-bifurcate
 // CHECK-NEXT: ipa-always-inline-size = 3
 // CHECK-NEXT: leak-diagnostics-reference-allocation = false
 // CHECK-NEXT: max-inlinable-size = 50
 // CHECK-NEXT: max-nodes = 15
 // CHECK-NEXT: max-times-inline-large = 32
+// CHECK-NEXT: min-cfg-size-treat-functions-as-large = 14
 // CHECK-NEXT: mode = deep
 // CHECK-NEXT: region-store-small-struct-limit = 2
 // CHECK-NEXT: [stats]
-// CHECK-NEXT: num-entries = 12
+// CHECK-NEXT: num-entries = 14
 
Index: cfe/trunk/test/Analysis/analyzer-config.cpp
===
--- cfe/trunk/test/Analysis/analyzer-config.cpp
+++ cfe/trunk/test/Analysis/analyzer-config.cpp
@@ -1,8 +1,14 @@
-// RUN: %clang -target x86_64-apple-darwin10 --analyze %s -o /dev/null -Xclang -analyzer-checker=debug.ConfigDumper 

Re: r247346 - [MS ABI] Make member pointers return true for isIncompleteType

[Richard Smith via cfe-commits]

On Fri, Sep 11, 2015 at 12:46 PM, David Majnemer via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Reduced it a bit:
> template 
> void JSMethod();
> class A {
>   int printd(int);
>   void printd();
> };
> void A::printd() { JSMethod(); }
>
> This test case will crash clang at the revision before this commit which
> means that something more mysterious/horrific is going on...
>

Are we perhaps failing to RequireCompleteType on M's type after
substituting the value of C into it?

On Fri, Sep 11, 2015 at 11:10 AM, David Majnemer 
> wrote:
>
>> Taking a look, would appreciate it if we didn't revert this until I give
>> it a fair shot.  Shouldn't take too long.
>>
>> On Fri, Sep 11, 2015 at 10:58 AM, Hans Wennborg 
>> wrote:
>>
>>> This made the Chromium build sad. For example:
>>>
>>> http://build.chromium.org/p/chromium.fyi/builders/ClangToTWin/builds/3092/steps/compile/logs/stdio
>>>
>>> Reduction:
>>>
>>> $ clang -cc1 -triple i686-pc-windows-msvc18.0.0 -w -fms-extensions
>>> -fms-compatibility -fms-compatibility-version=18.0 -std=c++11
>>> -fdelayed-template-parsing a.ii
>>>
>>> template 
>>> void JSMethod(char *, char *, int);
>>> class A {
>>>   int printd(int *, const int &, int &, int &);
>>>   int printd_info;
>>>   void printd() { JSMethod("", "", printd_info); }
>>> };
>>>
>>>
>>> On Thu, Sep 10, 2015 at 2:52 PM, David Majnemer via cfe-commits
>>>  wrote:
>>> > Author: majnemer
>>> > Date: Thu Sep 10 16:52:00 2015
>>> > New Revision: 247346
>>> >
>>> > URL: http://llvm.org/viewvc/llvm-project?rev=247346&view=rev
>>> > Log:
>>> > [MS ABI] Make member pointers return true for isIncompleteType
>>> >
>>> > The type of a member pointer is incomplete if it has no inheritance
>>> > model.  This lets us reuse more general logic already embedded in
>>> clang.
>>>
>>
>>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r247464 - [MS ABI] Select an inheritance model in template arguments

[David Majnemer via cfe-commits]

Author: majnemer
Date: Fri Sep 11 15:18:09 2015
New Revision: 247464

URL: http://llvm.org/viewvc/llvm-project?rev=247464&view=rev
Log:
[MS ABI] Select an inheritance model in template arguments

We used to only select an inheritance model if the pointer to member was
nullptr.  Instead, select a model regardless of the member pointer's
value.

N.B.  This bug was exposed by making member pointers report true for
isIncompleteType but has been latent since the member pointer scheme's
inception.

Modified:
cfe/trunk/lib/Sema/SemaTemplate.cpp
cfe/trunk/test/CodeGenCXX/microsoft-abi-member-pointers.cpp

Modified: cfe/trunk/lib/Sema/SemaTemplate.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaTemplate.cpp?rev=247464&r1=247463&r2=247464&view=diff
==
--- cfe/trunk/lib/Sema/SemaTemplate.cpp (original)
+++ cfe/trunk/lib/Sema/SemaTemplate.cpp Fri Sep 11 15:18:09 2015
@@ -4222,7 +4222,11 @@ isNullPointerValueTemplateArgument(Sema
QualType ParamType, Expr *Arg) {
   if (Arg->isValueDependent() || Arg->isTypeDependent())
 return NPV_NotNullPointer;
-  
+
+  if (ParamType->isMemberPointerType())
+if (S.Context.getTargetInfo().getCXXABI().isMicrosoft())
+  S.RequireCompleteType(Arg->getExprLoc(), ParamType, 0);
+
   if (!S.getLangOpts().CPlusPlus11)
 return NPV_NotNullPointer;
   
@@ -4670,8 +4674,6 @@ static bool CheckTemplateArgumentPointer
 S.Diag(Arg->getExprLoc(), diag::warn_cxx98_compat_template_arg_null);
 Converted = TemplateArgument(S.Context.getCanonicalType(ParamType),
  /*isNullPtr*/true);
-if (S.Context.getTargetInfo().getCXXABI().isMicrosoft())
-  S.RequireCompleteType(Arg->getExprLoc(), ParamType, 0);
 return false;
   case NPV_NotNullPointer:
 break;

Modified: cfe/trunk/test/CodeGenCXX/microsoft-abi-member-pointers.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/microsoft-abi-member-pointers.cpp?rev=247464&r1=247463&r2=247464&view=diff
==
--- cfe/trunk/test/CodeGenCXX/microsoft-abi-member-pointers.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/microsoft-abi-member-pointers.cpp Fri Sep 11 
15:18:09 2015
@@ -768,3 +768,14 @@ bool g(int J::*&p, int J::*&q) { return
 // CHECK-LABEL: @"\01?h@ReferenceToMPTWithIncompleteClass@@YAHAAPQK@1@H@Z"(
 int h(int K::*&p) { return k->*p; }
 }
+
+namespace PMFInTemplateArgument {
+template 
+void JSMethod();
+class A {
+  int printd(int);
+  void printd();
+};
+void A::printd() { JSMethod(); }
+// CHECK-LABEL: 
@"\01??$JSMethod@VA@PMFInTemplateArgument@@$1?printd@12@AAEHH@Z@PMFInTemplateArgument@@YAXXZ"(
+}


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

Re: r246877 - Increase accuracy of __builtin_object_size.

[Richard Smith via cfe-commits]

On Fri, Sep 11, 2015 at 12:15 PM, Mikhail Zolotukhin via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Hi George,
>
> After this commit we started to trap on the following case:
>
> #include 
> typedef struct {
>   int n;
>   char key[1];
> } obj_t;
>
> char *str = "hello";
>
> int main() {
>   obj_t* p = (obj_t*)malloc(strlen(str) + 1 + sizeof(int));
>   strcpy(p->key, str);
>   free(p);
>   return 0;
> }
>
> As far as I understand, this might be a common pattern in pre-C99
> codebase, and it fails when compiled with -D_FORTIFY_SOURCE=2. Is there a
> way we could fix it in clang, or the only fix is to use less strict
> FORTIFY_SOURCE level?
>

It might be reasonable for __builtin_object_size(..., 2) to give up if:

1) we lost track of the complete object, and
2) the designator refers to the final subobject of the currently-known
complete object, and
3) that subobject is either a flexible array member or an array of bound 0
or 1.

Then we'd leave it to IR generation to do the llvm.object.size(..., i1
false) dance, and in this case to grab the size of the malloc (minus the
offset of 'key').

Thanks,
> Michael
>
> On Sep 4, 2015, at 2:28 PM, George Burgess IV via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
> Author: gbiv
> Date: Fri Sep  4 16:28:13 2015
> New Revision: 246877
>
> URL: http://llvm.org/viewvc/llvm-project?rev=246877&view=rev
> Log:
> Increase accuracy of __builtin_object_size.
>
> Improvements:
>
> - For all types, we would give up in a case such as:
>__builtin_object_size((char*)&foo, N);
>  even if we could provide an answer to
>__builtin_object_size(&foo, N);
>  We now provide the same answer for both of the above examples in all
>  cases.
>
> - For type=1|3, we now support subobjects with unknown bases, as long
>  as the designator is valid.
>
> Thanks to Richard Smith for the review + design planning.
>
> Review: http://reviews.llvm.org/D12169
>
>
> Modified:
>cfe/trunk/lib/AST/ExprConstant.cpp
>cfe/trunk/test/CodeGen/object-size.c
>
> Modified: cfe/trunk/lib/AST/ExprConstant.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ExprConstant.cpp?rev=246877&r1=246876&r2=246877&view=diff
>
> ==
> --- cfe/trunk/lib/AST/ExprConstant.cpp (original)
> +++ cfe/trunk/lib/AST/ExprConstant.cpp Fri Sep  4 16:28:13 2015
> @@ -492,7 +492,11 @@ namespace {
>   /// optimizer if we don't constant fold them here, but in an
> unevaluated
>   /// context we try to fold them immediately since the optimizer never
>   /// gets a chance to look at it.
> -  EM_PotentialConstantExpressionUnevaluated
> +  EM_PotentialConstantExpressionUnevaluated,
> +
> +  /// Evaluate as a constant expression. Continue evaluating if we
> find a
> +  /// MemberExpr with a base that can't be evaluated.
> +  EM_DesignatorFold,
> } EvalMode;
>
> /// Are we checking whether the expression is a potential constant
> @@ -595,6 +599,7 @@ namespace {
>   case EM_PotentialConstantExpression:
>   case EM_ConstantExpressionUnevaluated:
>   case EM_PotentialConstantExpressionUnevaluated:
> +  case EM_DesignatorFold:
> HasActiveDiagnostic = false;
> return OptionalDiagnostic();
>   }
> @@ -674,6 +679,7 @@ namespace {
>   case EM_ConstantExpression:
>   case EM_ConstantExpressionUnevaluated:
>   case EM_ConstantFold:
> +  case EM_DesignatorFold:
> return false;
>   }
>   llvm_unreachable("Missed EvalMode case");
> @@ -702,10 +708,15 @@ namespace {
>   case EM_ConstantExpressionUnevaluated:
>   case EM_ConstantFold:
>   case EM_IgnoreSideEffects:
> +  case EM_DesignatorFold:
> return false;
>   }
>   llvm_unreachable("Missed EvalMode case");
> }
> +
> +bool allowInvalidBaseExpr() const {
> +  return EvalMode == EM_DesignatorFold;
> +}
>   };
>
>   /// Object used to treat all foldable expressions as constant
> expressions.
> @@ -736,6 +747,21 @@ namespace {
> }
>   };
>
> +  /// RAII object used to treat the current evaluation as the correct
> pointer
> +  /// offset fold for the current EvalMode
> +  struct FoldOffsetRAII {
> +EvalInfo &Info;
> +EvalInfo::EvaluationMode OldMode;
> +explicit FoldOffsetRAII(EvalInfo &Info, bool Subobject)
> +: Info(Info), OldMode(Info.EvalMode) {
> +  if (!Info.checkingPotentialConstantExpression())
> +Info.EvalMode = Subobject ? EvalInfo::EM_DesignatorFold
> +  : EvalInfo::EM_ConstantFold;
> +}
> +
> +~FoldOffsetRAII() { Info.EvalMode = OldMode; }
> +  };
> +
>   /// RAII object used to suppress diagnostics and side-effects from a
>   /// speculative evaluation.
>   class SpeculativeEvaluationRAII {
> @@ -917,7 +943,8 @@ namespace {
>   struct LValue {
> APValue::LValueBase Base;
> CharUnits Offset;
> -unsigned CallIndex;
> +   

Re: r247464 - [MS ABI] Select an inheritance model in template arguments

[Richard Smith via cfe-commits]

On Fri, Sep 11, 2015 at 1:18 PM, David Majnemer via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: majnemer
> Date: Fri Sep 11 15:18:09 2015
> New Revision: 247464
>
> URL: http://llvm.org/viewvc/llvm-project?rev=247464&view=rev
> Log:
> [MS ABI] Select an inheritance model in template arguments
>
> We used to only select an inheritance model if the pointer to member was
> nullptr.  Instead, select a model regardless of the member pointer's
> value.
>
> N.B.  This bug was exposed by making member pointers report true for
> isIncompleteType but has been latent since the member pointer scheme's
> inception.
>
> Modified:
> cfe/trunk/lib/Sema/SemaTemplate.cpp
> cfe/trunk/test/CodeGenCXX/microsoft-abi-member-pointers.cpp
>
> Modified: cfe/trunk/lib/Sema/SemaTemplate.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaTemplate.cpp?rev=247464&r1=247463&r2=247464&view=diff
>
> ==
> --- cfe/trunk/lib/Sema/SemaTemplate.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaTemplate.cpp Fri Sep 11 15:18:09 2015
> @@ -4222,7 +4222,11 @@ isNullPointerValueTemplateArgument(Sema
> QualType ParamType, Expr *Arg) {
>if (Arg->isValueDependent() || Arg->isTypeDependent())
>  return NPV_NotNullPointer;
> -
> +
> +  if (ParamType->isMemberPointerType())
> +if (S.Context.getTargetInfo().getCXXABI().isMicrosoft())
> +  S.RequireCompleteType(Arg->getExprLoc(), ParamType, 0);
>

It seems simpler to unconditionally require the type to be complete.


> +
>if (!S.getLangOpts().CPlusPlus11)
>  return NPV_NotNullPointer;
>
> @@ -4670,8 +4674,6 @@ static bool CheckTemplateArgumentPointer
>  S.Diag(Arg->getExprLoc(), diag::warn_cxx98_compat_template_arg_null);
>  Converted = TemplateArgument(S.Context.getCanonicalType(ParamType),
>   /*isNullPtr*/true);
> -if (S.Context.getTargetInfo().getCXXABI().isMicrosoft())
> -  S.RequireCompleteType(Arg->getExprLoc(), ParamType, 0);
>  return false;
>case NPV_NotNullPointer:
>  break;
>
> Modified: cfe/trunk/test/CodeGenCXX/microsoft-abi-member-pointers.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/microsoft-abi-member-pointers.cpp?rev=247464&r1=247463&r2=247464&view=diff
>
> ==
> --- cfe/trunk/test/CodeGenCXX/microsoft-abi-member-pointers.cpp (original)
> +++ cfe/trunk/test/CodeGenCXX/microsoft-abi-member-pointers.cpp Fri Sep 11
> 15:18:09 2015
> @@ -768,3 +768,14 @@ bool g(int J::*&p, int J::*&q) { return
>  // CHECK-LABEL: @"\01?h@ReferenceToMPTWithIncompleteClass@@YAHAAPQK@1@H@Z
> "(
>  int h(int K::*&p) { return k->*p; }
>  }
> +
> +namespace PMFInTemplateArgument {
> +template 
> +void JSMethod();
> +class A {
> +  int printd(int);
> +  void printd();
> +};
> +void A::printd() { JSMethod(); }
> +// CHECK-LABEL: @"\01??$JSMethod@VA@PMFInTemplateArgument@@$1?printd@12
> @AAEHH@Z@PMFInTemplateArgument@@YAXXZ"(
> +}
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r247346 - [MS ABI] Make member pointers return true for isIncompleteType

[David Majnemer via cfe-commits]

On Fri, Sep 11, 2015 at 1:16 PM, Richard Smith 
wrote:

> On Fri, Sep 11, 2015 at 12:46 PM, David Majnemer via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Reduced it a bit:
>> template 
>> void JSMethod();
>> class A {
>>   int printd(int);
>>   void printd();
>> };
>> void A::printd() { JSMethod(); }
>>
>> This test case will crash clang at the revision before this commit which
>> means that something more mysterious/horrific is going on...
>>
>
> Are we perhaps failing to RequireCompleteType on M's type after
> substituting the value of C into it?
>

Fixed in r247464.


>
> On Fri, Sep 11, 2015 at 11:10 AM, David Majnemer > > wrote:
>>
>>> Taking a look, would appreciate it if we didn't revert this until I give
>>> it a fair shot.  Shouldn't take too long.
>>>
>>> On Fri, Sep 11, 2015 at 10:58 AM, Hans Wennborg 
>>> wrote:
>>>
 This made the Chromium build sad. For example:

 http://build.chromium.org/p/chromium.fyi/builders/ClangToTWin/builds/3092/steps/compile/logs/stdio

 Reduction:

 $ clang -cc1 -triple i686-pc-windows-msvc18.0.0 -w -fms-extensions
 -fms-compatibility -fms-compatibility-version=18.0 -std=c++11
 -fdelayed-template-parsing a.ii

 template 
 void JSMethod(char *, char *, int);
 class A {
   int printd(int *, const int &, int &, int &);
   int printd_info;
   void printd() { JSMethod("", "", printd_info); }
 };


 On Thu, Sep 10, 2015 at 2:52 PM, David Majnemer via cfe-commits
  wrote:
 > Author: majnemer
 > Date: Thu Sep 10 16:52:00 2015
 > New Revision: 247346
 >
 > URL: http://llvm.org/viewvc/llvm-project?rev=247346&view=rev
 > Log:
 > [MS ABI] Make member pointers return true for isIncompleteType
 >
 > The type of a member pointer is incomplete if it has no inheritance
 > model.  This lets us reuse more general logic already embedded in
 clang.

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

Re: [PATCH] D12087: always_inline codegen rewrite

[Evgeniy Stepanov via cfe-commits]

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

rebase, fix a merge conflict


Repository:
  rL LLVM

http://reviews.llvm.org/D12087

Files:
  lib/CodeGen/CGCXX.cpp
  lib/CodeGen/CGClass.cpp
  lib/CodeGen/CGOpenMPRuntime.cpp
  lib/CodeGen/CodeGenModule.cpp
  lib/CodeGen/CodeGenModule.h
  lib/CodeGen/ItaniumCXXABI.cpp
  test/CodeGen/always-inline.c
  test/CodeGen/always_inline-unused.c
  test/CodeGen/always_inline-wrappers.c
  test/CodeGen/always_inline.c
  test/CodeGen/function-attributes.c
  test/CodeGen/pr9614.c
  test/CodeGenCXX/alwaysinline.cpp
  test/Frontend/optimization-remark-line-directive.c
  test/Frontend/optimization-remark.c
  test/Modules/cxx-irgen.cpp

Index: test/Modules/cxx-irgen.cpp
===
--- test/Modules/cxx-irgen.cpp
+++ test/Modules/cxx-irgen.cpp
@@ -26,14 +26,14 @@
   };
 }
 
-// CHECK-DAG: define available_externally hidden {{.*}}{{signext i32|i32}} @_ZN1SIiE1gEv({{.*}} #[[ALWAYS_INLINE:.*]] align
+// CHECK-DAG: define internal i32 @_ZN1SIiE1gEv.alwaysinline() #[[ALWAYS_INLINE:.*]] align
 int a = S::g();
 
 int b = h();
 
 // CHECK-DAG: define linkonce_odr {{.*}}{{signext i32|i32}} @_Z3minIiET_S0_S0_(i32
 int c = min(1, 2);
-// CHECK: define available_externally {{.*}}{{signext i32|i32}} @_ZN1SIiE1fEv({{.*}} #[[ALWAYS_INLINE]] align
+// CHECK-DAG: define internal {{.*}}{{signext i32|i32}} @_ZN1SIiE1fEv.alwaysinline() #[[ALWAYS_INLINE]] align
 
 namespace ImplicitSpecialMembers {
   // CHECK-LABEL: define {{.*}} @_ZN22ImplicitSpecialMembers1BC2ERKS0_(
Index: test/Frontend/optimization-remark.c
===
--- test/Frontend/optimization-remark.c
+++ test/Frontend/optimization-remark.c
@@ -32,6 +32,8 @@
 // CHECK-NOT: !llvm.dbg.cu = !{
 
 int foo(int x, int y) __attribute__((always_inline));
+// expected-remark@+2 {{foo.alwaysinline should always be inlined}}
+// expected-remark@+1 {{foo.alwaysinline inlined into foo}}
 int foo(int x, int y) { return x + y; }
 
 float foz(int x, int y) __attribute__((noinline));
@@ -45,7 +47,7 @@
 // expected-remark@+5 {{foz will not be inlined into bar}}
 // expected-remark@+4 {{foz should never be inlined}}
 // expected-remark@+3 {{foz will not be inlined into bar}}
-// expected-remark@+2 {{foo should always be inlined}}
-// expected-remark@+1 {{foo inlined into bar}}
+// expected-remark@+2 {{foo.alwaysinline should always be inlined}}
+// expected-remark@+1 {{foo.alwaysinline inlined into bar}}
   return foo(j, j - 2) * foz(j - 2, j);
 }
Index: test/Frontend/optimization-remark-line-directive.c
===
--- test/Frontend/optimization-remark-line-directive.c
+++ test/Frontend/optimization-remark-line-directive.c
@@ -5,8 +5,9 @@
 // RUN: %clang_cc1 %s -Rpass=inline -gline-tables-only -dwarf-column-info -emit-llvm-only -verify
 
 int foo(int x, int y) __attribute__((always_inline));
+// expected-remark@+1 {{foo.alwaysinline inlined into foo}}
 int foo(int x, int y) { return x + y; }
 
-// expected-remark@+2 {{foo inlined into bar}} expected-note@+2 {{could not determine the original source location for /bad/path/to/original.c:1230:25}}
+// expected-remark@+2 {{foo.alwaysinline inlined into bar}} expected-note@+2 {{could not determine the original source location for /bad/path/to/original.c:1230:25}}
 #line 1230 "/bad/path/to/original.c"
 int bar(int j) { return foo(j, j - 2); }
Index: test/CodeGenCXX/alwaysinline.cpp
===
--- /dev/null
+++ test/CodeGenCXX/alwaysinline.cpp
@@ -0,0 +1,68 @@
+// Test different kinds of alwaysinline *structor definitions.
+
+// RUN: %clang_cc1 -disable-llvm-optzns -emit-llvm %s -o - | FileCheck %s --check-prefix=CHECK
+// RUN: %clang_cc1 -disable-llvm-optzns -emit-llvm %s -o - | FileCheck %s --check-prefix=CHECK-CALL
+
+// RUN: %clang_cc1 -mconstructor-aliases -disable-llvm-optzns -emit-llvm %s -o - | FileCheck %s --check-prefix=CHECK
+// RUN: %clang_cc1 -mconstructor-aliases -disable-llvm-optzns -emit-llvm %s -o - | FileCheck %s --check-prefix=CHECK-CALL
+
+struct A1 {
+  __attribute__((__always_inline__)) A1() {}
+  __attribute__((__always_inline__)) ~A1() {}
+};
+
+void g1() {
+  A1 a1;
+}
+
+struct A2 {
+  inline __attribute__((__always_inline__)) A2() {}
+  inline __attribute__((__always_inline__)) ~A2() {}
+};
+
+void g2() {
+  A2 a2;
+}
+
+struct A3 {
+  inline __attribute__((gnu_inline, __always_inline__)) A3() {}
+  inline __attribute__((gnu_inline, __always_inline__)) ~A3() {}
+};
+
+void g3() {
+  A3 a3;
+}
+
+// CHECK-DAG: define internal void @_ZN2A1C1Ev.alwaysinline(%struct.A1* %this) unnamed_addr #[[AI:[01-9]+]]
+// CHECK-DAG: define internal void @_ZN2A1C2Ev.alwaysinline(%struct.A1* %this) unnamed_addr #[[AI]]
+// CHECK-DAG: define internal void @_ZN2A1D1Ev.alwaysinline(%struct.A1* %this) unnamed_addr #[[AI]]
+// CHECK-DAG: define internal void @_ZN2

r247465 - Always_inline codegen rewrite.

[Evgeniy Stepanov via cfe-commits]

Author: eugenis
Date: Fri Sep 11 15:29:07 2015
New Revision: 247465

URL: http://llvm.org/viewvc/llvm-project?rev=247465&view=rev
Log:
Always_inline codegen rewrite.

Current implementation may end up emitting an undefined reference for
an "inline __attribute__((always_inline))" function by generating an
"available_externally alwaysinline" IR function for it and then failing to
inline all the calls. This happens when a call to such function is in dead
code. As the inliner is an SCC pass, it does not process dead code.

Libc++ relies on the compiler never emitting such undefined reference.

With this patch, we emit a pair of
1. internal alwaysinline definition (called F.alwaysinline)
2a. A stub F() { musttail call F.alwaysinline }
  -- or, depending on the linkage --
2b. A declaration of F.

The frontend ensures that F.inlinefunction is only used for direct
calls, and the stub is used for everything else (taking the address of
the function, really). Declaration (2b) is emitted in the case when
"inline" is meant for inlining only (like __gnu_inline__ and some
other cases).

This approach, among other nice properties, ensures that alwaysinline
functions are always internal, making it impossible for a direct call
to such function to produce an undefined symbol reference.

This patch is based on ideas by Chandler Carruth and Richard Smith.

Added:
cfe/trunk/test/CodeGen/always_inline-unused.c
cfe/trunk/test/CodeGen/always_inline-wrappers.c
cfe/trunk/test/CodeGenCXX/alwaysinline.cpp
Modified:
cfe/trunk/lib/CodeGen/CGCXX.cpp
cfe/trunk/lib/CodeGen/CGClass.cpp
cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
cfe/trunk/lib/CodeGen/CodeGenModule.cpp
cfe/trunk/lib/CodeGen/CodeGenModule.h
cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
cfe/trunk/test/CodeGen/always-inline.c
cfe/trunk/test/CodeGen/always_inline.c
cfe/trunk/test/CodeGen/function-attributes.c
cfe/trunk/test/CodeGen/pr9614.c
cfe/trunk/test/Frontend/optimization-remark-line-directive.c
cfe/trunk/test/Frontend/optimization-remark.c
cfe/trunk/test/Modules/cxx-irgen.cpp

Modified: cfe/trunk/lib/CodeGen/CGCXX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCXX.cpp?rev=247465&r1=247464&r2=247465&view=diff
==
--- cfe/trunk/lib/CodeGen/CGCXX.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGCXX.cpp Fri Sep 11 15:29:07 2015
@@ -109,6 +109,9 @@ bool CodeGenModule::TryEmitBaseDestructo
   D->getType()->getAs()->getCallConv())
 return true;
 
+  if (BaseD->hasAttr())
+return true;
+
   return TryEmitDefinitionAsAlias(GlobalDecl(D, Dtor_Base),
   GlobalDecl(BaseD, Dtor_Base),
   false);
@@ -161,14 +164,7 @@ bool CodeGenModule::TryEmitDefinitionAsA
 
   // Instead of creating as alias to a linkonce_odr, replace all of the uses
   // of the aliasee.
-  if (llvm::GlobalValue::isDiscardableIfUnused(Linkage) &&
- (TargetLinkage != llvm::GlobalValue::AvailableExternallyLinkage ||
-  !TargetDecl.getDecl()->hasAttr())) {
-// FIXME: An extern template instantiation will create functions with
-// linkage "AvailableExternally". In libc++, some classes also define
-// members with attribute "AlwaysInline" and expect no reference to
-// be generated. It is desirable to reenable this optimisation after
-// corresponding LLVM changes.
+  if (llvm::GlobalValue::isDiscardableIfUnused(Linkage)) {
 Replacements[MangledName] = Aliasee;
 return false;
   }

Modified: cfe/trunk/lib/CodeGen/CGClass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGClass.cpp?rev=247465&r1=247464&r2=247465&view=diff
==
--- cfe/trunk/lib/CodeGen/CGClass.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGClass.cpp Fri Sep 11 15:29:07 2015
@@ -1557,7 +1557,7 @@ void CodeGenFunction::EmitDestructorBody
 // -fapple-kext must inline any call to this dtor into
 // the caller's body.
 if (getLangOpts().AppleKext)
-  CurFn->addFnAttr(llvm::Attribute::AlwaysInline);
+  CGM.AddAlwaysInlineFunction(CurFn);
 
 break;
   }

Modified: cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp?rev=247465&r1=247464&r2=247465&view=diff
==
--- cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp Fri Sep 11 15:29:07 2015
@@ -2114,7 +2114,7 @@ emitTaskPrivateMappingFunction(CodeGenMo
   ".omp_task_privates_map.", &CGM.getModule());
   CGM.SetLLVMFunctionAttributes(/*D=*/nullptr, TaskPrivatesMapFnInfo,
 TaskPrivatesMap);
-  TaskPrivatesMap->addFnAttr(llvm::Attribute::AlwaysInline);
+  CGM.AddAlwaysInlineFunction(TaskPrivatesMap);
   CodeGenFunction CGF(C

Re: recordDecl() AST matcher

[Richard Smith via cfe-commits]

I don't think CXXRecordDecl is an anachronism, so much as an implementation
detail; it makes sense to use a smaller class when in C mode, as we don't
need most of the features and complexity that CXXRecordDecl brings with it.
But... as a user of clang matchers, I don't think I'd want to care about
the difference, and it'd be more convenient if I could nest (say) a
hasMethod matcher within a recordDecl matcher, since it's completely
obvious what that should mean. If I have a matcher that says:

  recordDecl(or(hasMethod(...), hasField(...)))

I would expect that to work in both C and C++ (and the only way it could
match in C would be on a record with the specified field, since the
hasMethod matcher would always fail).

On Fri, Sep 11, 2015 at 6:30 AM, Manuel Klimek  wrote:

> Richard! We need an informed opinion :D
>
> On Fri, Sep 11, 2015 at 3:07 PM Aaron Ballman 
> wrote:
>
>> Ping?
>>
>> On Tue, Sep 8, 2015 at 9:26 AM, Manuel Klimek  wrote:
>> > On Tue, Sep 8, 2015 at 3:23 PM Aaron Ballman 
>> wrote:
>> >>
>> >> On Tue, Sep 8, 2015 at 9:18 AM, Manuel Klimek 
>> wrote:
>> >> > On Tue, Sep 8, 2015 at 2:23 PM Aaron Ballman > >
>> >> > wrote:
>> >> >>
>> >> >> On Tue, Sep 8, 2015 at 5:40 AM, Manuel Klimek 
>> >> >> wrote:
>> >> >> > Yea, we had that discussion a few times, and I can never remember
>> why
>> >> >> > we
>> >> >> > ended up in the state we're in.
>> >> >> > We definitely had a time where we switched to just using the exact
>> >> >> > same
>> >> >> > name
>> >> >> > as the node's class name for the matchers.
>> >> >> > I *think* we didn't do it for cxxRecordDecl, because Richard said
>> >> >> > that's
>> >> >> > a
>> >> >> > relic we should get rid of anyway, but I'm not sure.
>> >> >>
>> >> >> FWIW, I think the state we're in is the worst of all worlds. It's
>> not
>> >> >> intuitive that recordDecl() doesn't match a struct in C mode, and as
>> >> >> it stands, there is no way to match a struct or union declaration
>> in C
>> >> >> at all.
>> >> >
>> >> >
>> >> > Agreed. Best intentions. Worst possible outcome. That's software
>> >> > development
>> >> > :)
>> >> >
>> >> >> >
>> >> >> > On Fri, Sep 4, 2015 at 8:32 PM Aaron Ballman <
>> aa...@aaronballman.com>
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> It turns out that the recordDecl() AST matcher doesn't match
>> >> >> >> RecordDecl objects; instead, it matches CXXRecordDecl objects.
>> This
>> >> >> >> is... unfortunate... as it makes writing AST matchers more
>> >> >> >> complicated
>> >> >> >> because of having to translate between
>> recordDecl()/CXXRecordDecl.
>> >> >> >> It
>> >> >> >> also makes it impossible to match a struct or union declaration
>> in C
>> >> >> >> or ObjC. However, given how prevalent recordDecl()'s use is in
>> the
>> >> >> >> wild (I'm guessing), changing it at this point would be a Bad
>> Thing.
>> >> >> >>
>> >> >> >> For people trying to write AST matchers for languages like C or
>> >> >> >> ObjC,
>> >> >> >> I would like to propose adding:
>> >> >> >>
>> >> >> >> structDecl()
>> >> >> >> unionDecl()
>> >> >> >> tagDecl()
>> >> >> >>
>> >> >> >> These will match nicely with the existing enumDecl() AST matcher.
>> >> >> >>
>> >> >> >> Additionally, I would like to add cxxRecordDecl() to match
>> >> >> >> CXXRecordDecl objects. While it duplicates the functionality
>> exposed
>> >> >> >> by recordDecl(), it more clearly matches the intention of which
>> AST
>> >> >> >> node it corresponds to.
>> >> >> >>
>> >> >> >> Finally, I would like to undocument recordDecl() and change our
>> >> >> >> existing documentation and AST matcher uses to use
>> >> >> >> cxxRecordDecl/structDecl() instead. Maybe someday we can
>> deprecate
>> >> >> >> recordDecl() more officially.
>> >> >> >>
>> >> >> >> I'm open to other ideas if there are better ways to move
>> forward. If
>> >> >> >> you think changing the meaning of recordDecl() is acceptable, I
>> can
>> >> >> >> also go that route (though I would still propose adding
>> unionDecl()
>> >> >> >> and cxxRecordDecl() in that case).
>> >> >> >
>> >> >> >
>> >> >> > I think changing recordDecl is acceptable. I believe very few
>> tools
>> >> >> > will
>> >> >> > actually start doing wrong things because of it. I'd like more
>> >> >> > opinions
>> >> >> > first, though :)
>> >> >>
>> >> >> I was giving this more thought over the long weekend, and I think
>> you
>> >> >> may be right. I think changing recordDecl() to mean RecordDecl will
>> >> >> fix more code than it breaks, so long as we take a holistic approach
>> >> >> to the change and see which narrowing and traversal matchers we need
>> >> >> to fix up at the same time. When I tried to think of AST matchers
>> that
>> >> >> mean CXXRecordDecl but *not* RecordDecl, they were horribly
>> contrived
>> >> >> because you usually are matching on additional selection criteria
>> that
>> >> >> is specific to C++ (such as hasMethod() or isDerivedFrom()) which
>> >> >> would cause the match to continue to fail, as expected. Code that
>> u