[clang-tools-extra] r260107 - [clang-tidy] Fix assertion failure on `at` function in modernize-loop-convert.

[Haojian Wu via cfe-commits]

Author: hokein
Date: Mon Feb  8 09:59:42 2016
New Revision: 260107

URL: http://llvm.org/viewvc/llvm-project?rev=260107=rev
Log:
[clang-tidy] Fix assertion failure on `at` function in modernize-loop-convert.

Reviewers: alexfh

Subscribers: cfe-commits

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

Modified:
clang-tools-extra/trunk/clang-tidy/modernize/LoopConvertUtils.cpp
clang-tools-extra/trunk/docs/clang-tidy/checks/modernize-loop-convert.rst

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

Modified: clang-tools-extra/trunk/clang-tidy/modernize/LoopConvertUtils.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/modernize/LoopConvertUtils.cpp?rev=260107=260106=260107=diff
==
--- clang-tools-extra/trunk/clang-tidy/modernize/LoopConvertUtils.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/modernize/LoopConvertUtils.cpp Mon Feb  
8 09:59:42 2016
@@ -391,8 +391,8 @@ static bool isAliasDecl(ASTContext *Cont
 // This check is needed because getMethodDecl can return nullptr if the
 // callee is a member function pointer.
 const auto *MDecl = MemCall->getMethodDecl();
-if (MDecl && !isa(MDecl) && MDecl->getName() == "at") {
-  assert(MemCall->getNumArgs() == 1);
+if (MDecl && !isa(MDecl) && MDecl->getName() == "at" &&
+MemCall->getNumArgs() == 1) {
   return isIndexInSubscriptExpr(MemCall->getArg(0), IndexVar);
 }
 return false;

Modified: 
clang-tools-extra/trunk/docs/clang-tidy/checks/modernize-loop-convert.rst
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/docs/clang-tidy/checks/modernize-loop-convert.rst?rev=260107=260106=260107=diff
==
--- clang-tools-extra/trunk/docs/clang-tidy/checks/modernize-loop-convert.rst 
(original)
+++ clang-tools-extra/trunk/docs/clang-tidy/checks/modernize-loop-convert.rst 
Mon Feb  8 09:59:42 2016
@@ -89,7 +89,7 @@ Original:
 
   // reasonable conversion
   for (vector::iterator it = v.begin(); it != v.end(); ++it)
-cout << *it;*
+cout << *it;
 
   // reasonable conversion
   for (int i = 0; i < v.size(); ++i)

Modified: 
clang-tools-extra/trunk/test/clang-tidy/Inputs/modernize-loop-convert/structures.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/Inputs/modernize-loop-convert/structures.h?rev=260107=260106=260107=diff
==
--- 
clang-tools-extra/trunk/test/clang-tidy/Inputs/modernize-loop-convert/structures.h
 (original)
+++ 
clang-tools-extra/trunk/test/clang-tidy/Inputs/modernize-loop-convert/structures.h
 Mon Feb  8 09:59:42 2016
@@ -98,6 +98,7 @@ class dependent {
   ElemType & operator[](unsigned);
   const ElemType & operator[](unsigned) const;
   ElemType & at(unsigned);
+  ElemType & at(unsigned, unsigned);
   const ElemType & at(unsigned) const;
 
   // Intentionally evil.

Modified: 
clang-tools-extra/trunk/test/clang-tidy/modernize-loop-convert-extra.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/modernize-loop-convert-extra.cpp?rev=260107=260106=260107=diff
==
--- clang-tools-extra/trunk/test/clang-tidy/modernize-loop-convert-extra.cpp 
(original)
+++ clang-tools-extra/trunk/test/clang-tidy/modernize-loop-convert-extra.cpp 
Mon Feb  8 09:59:42 2016
@@ -251,8 +251,16 @@ void refs_and_vals() {
   // CHECK-FIXES-NEXT: const int& Idx = Other[0];
   // CHECK-FIXES-NEXT: unsigned Othersize = Other.size();
 
+  for (int i = 0; i <  Other.size(); ++i) {
+Other.at(i);
+  }
+  // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: use range-based for loop instead
+  // CHECK-FIXES: for (int & i : Other)
+  // CHECK-FIXES: i;
+
   for (int I = 0, E = Dep.size(); I != E; ++I) {
 int Idx = Other.at(I);
+Other.at(I, I);  // Should not trigger assert failure.
   }
 }
 


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

Re: [PATCH] D16922: [clang-tidy] Added check-fixes for misc-virtual-near-miss.

[Alexander Kornienko via cfe-commits]

alexfh added inline comments.


Comment at: test/clang-tidy/misc-virtual-near-miss.cpp:1
@@ -1,2 +1,2 @@
 // RUN: %check_clang_tidy %s misc-virtual-near-miss %t
 

The check shouldn't make any changes to template classes based on any single 
instantiation. An easy way to ensure this is to disallow matches in template 
instantiations, e.g. using the `unless(isInTemplateInstantiation())` limiting 
matcher.


Comment at: test/clang-tidy/misc-virtual-near-miss.cpp:58
@@ +57,3 @@
+  MACRO1;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: method 'Derived::funcM' has 
{{.*}} 'Base::func'
+

Please move the #defines close to their usages and also verify they don't 
change as a result of applying fixes.


http://reviews.llvm.org/D16922



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

Re: [PATCH] D16979: [clang-tidy] Some improvements in 'misc-definitions-in-headers' check.

[Haojian Wu via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL260108: [clang-tidy] Some improvements in 
'misc-definitions-in-headers' check. (authored by hokein).

Changed prior to commit:
  http://reviews.llvm.org/D16979?vs=47178=47205#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D16979

Files:
  clang-tools-extra/trunk/clang-tidy/misc/DefinitionsInHeadersCheck.cpp

Index: clang-tools-extra/trunk/clang-tidy/misc/DefinitionsInHeadersCheck.cpp
===
--- clang-tools-extra/trunk/clang-tidy/misc/DefinitionsInHeadersCheck.cpp
+++ clang-tools-extra/trunk/clang-tidy/misc/DefinitionsInHeadersCheck.cpp
@@ -51,6 +51,8 @@
 }
 
 void DefinitionsInHeadersCheck::registerMatchers(MatchFinder *Finder) {
+  if (!getLangOpts().CPlusPlus)
+return;
   if (UseHeaderFileExtension) {
 Finder->addMatcher(
 namedDecl(anyOf(functionDecl(isDefinition()), varDecl(isDefinition())),
@@ -78,6 +80,8 @@
   // satisfy the following requirements.
   const auto *ND = Result.Nodes.getNodeAs("name-decl");
   assert(ND);
+  if (ND->isInvalidDecl())
+return;
 
   // Internal linkage variable definitions are ignored for now:
   //   const int a = 1;


Index: clang-tools-extra/trunk/clang-tidy/misc/DefinitionsInHeadersCheck.cpp
===
--- clang-tools-extra/trunk/clang-tidy/misc/DefinitionsInHeadersCheck.cpp
+++ clang-tools-extra/trunk/clang-tidy/misc/DefinitionsInHeadersCheck.cpp
@@ -51,6 +51,8 @@
 }
 
 void DefinitionsInHeadersCheck::registerMatchers(MatchFinder *Finder) {
+  if (!getLangOpts().CPlusPlus)
+return;
   if (UseHeaderFileExtension) {
 Finder->addMatcher(
 namedDecl(anyOf(functionDecl(isDefinition()), varDecl(isDefinition())),
@@ -78,6 +80,8 @@
   // satisfy the following requirements.
   const auto *ND = Result.Nodes.getNodeAs("name-decl");
   assert(ND);
+  if (ND->isInvalidDecl())
+return;
 
   // Internal linkage variable definitions are ignored for now:
   //   const int a = 1;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu via cfe-commits]

On Mon, Feb 8, 2016 at 8:15 AM, Jonathan Wakely  wrote:
> On 8 February 2016 at 16:05, H.J. Lu wrote:
>> My understanding is
>>
>> A type that is standard-layout means that it orders and packs its
>> members in a way that is compatible with C.
>>
>> What is the corresponding compatible type in C?
>
> An empty structure, such as struct A.
>
> One of the requirements for standard-layout classes is "has all
> non-static data members and bit-fields in the class and its base
> classes first declared in the same class" so standard layout classes
> are allowed to have base classes, as long as either the base class is
> empty (so doesn't alter layout) or the derived class doesn't add
> members (so has the same layout as the base). If neither the base
> class is an empty record, and the derived class doesn't add any
> non-static data members or bit-fields, then the base class should be
> an empty record too.

if it is the case

struct A { };
struct B { };
struct C : A, B { };

is an empty record.


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

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu via cfe-commits]

On Mon, Feb 8, 2016 at 7:02 AM, Jonathan Wakely  wrote:
> On 8 February 2016 at 13:54, H.J. Lu  wrote:
>> On Sun, Feb 7, 2016 at 12:52 PM, H.J. Lu  wrote:
>>
>> The standard-layout POD is well defined:
>>
>> https://en.wikipedia.org/wiki/C%2B%2B11#Modification_to_the_definition_of_plain_old_data
>>
>> Here is the updated proposal for  Intel386, x86-64 and IA MCU psABIs:
>>
>> 1. "collection".  A collection is a structure, union or C++ class.
>
> These are all "class types". Why invent a new term?

Because it applies to both C and C++.  There is no class in C.

>> 2. "empty collection".  An empty collection is:
>>a. A collection without member.  Or
>
> What about base classes?
>
> What about bit-fields of length 0?

Is a collection with them standard-layout POD type?

>>b. A collection with only empty collections.  Or
>
> What does "with" mean? Only members, or bases too?

Is "A collection with only members of empty collections" better?

>>c. An array of empty collections.
>> 3. "empty record".  An empty record is Plain Old Data (POD) for the purpose
>>of standard-layout and
>
> "For the purposes of standard-layout" doesn't mean anything.
>
> A type is a standard-layout type, or it isn't.

How about "An empty record is standard-layout Plain Old Data (POD)
type and ..."?

> Do you mean "An empty record is a standard-layout type and..."
>
>>a. A collection without member.  Or
>>b. A collection with only empty collections.
>
> ?
>

Is "A collection with only members of empty collections" better?

>
>> 4. No memory slot nor register should be used to pass or return an object of
>> empty record.



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

[clang-tools-extra] r260108 - [clang-tidy] Some improvements in 'misc-definitions-in-headers' check.

[Haojian Wu via cfe-commits]

Author: hokein
Date: Mon Feb  8 10:05:39 2016
New Revision: 260108

URL: http://llvm.org/viewvc/llvm-project?rev=260108=rev
Log:
[clang-tidy] Some improvements in 'misc-definitions-in-headers' check.

Reviewers: alexfh

Subscribers: cfe-commits

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

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

Modified: clang-tools-extra/trunk/clang-tidy/misc/DefinitionsInHeadersCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/misc/DefinitionsInHeadersCheck.cpp?rev=260108=260107=260108=diff
==
--- clang-tools-extra/trunk/clang-tidy/misc/DefinitionsInHeadersCheck.cpp 
(original)
+++ clang-tools-extra/trunk/clang-tidy/misc/DefinitionsInHeadersCheck.cpp Mon 
Feb  8 10:05:39 2016
@@ -51,6 +51,8 @@ void DefinitionsInHeadersCheck::storeOpt
 }
 
 void DefinitionsInHeadersCheck::registerMatchers(MatchFinder *Finder) {
+  if (!getLangOpts().CPlusPlus)
+return;
   if (UseHeaderFileExtension) {
 Finder->addMatcher(
 namedDecl(anyOf(functionDecl(isDefinition()), varDecl(isDefinition())),
@@ -78,6 +80,8 @@ void DefinitionsInHeadersCheck::check(co
   // satisfy the following requirements.
   const auto *ND = Result.Nodes.getNodeAs("name-decl");
   assert(ND);
+  if (ND->isInvalidDecl())
+return;
 
   // Internal linkage variable definitions are ignored for now:
   //   const int a = 1;


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

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[Jonathan Wakely via cfe-commits]

On 8 February 2016 at 16:05, H.J. Lu wrote:
> My understanding is
>
> A type that is standard-layout means that it orders and packs its
> members in a way that is compatible with C.
>
> What is the corresponding compatible type in C?

An empty structure, such as struct A.

One of the requirements for standard-layout classes is "has all
non-static data members and bit-fields in the class and its base
classes first declared in the same class" so standard layout classes
are allowed to have base classes, as long as either the base class is
empty (so doesn't alter layout) or the derived class doesn't add
members (so has the same layout as the base). If neither the base
class is an empty record, and the derived class doesn't add any
non-static data members or bit-fields, then the base class should be
an empty record too.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [clang-tools-extra] r260108 - [clang-tidy] Some improvements in 'misc-definitions-in-headers' check.

[Aaron Ballman via cfe-commits]

On Mon, Feb 8, 2016 at 11:05 AM, Haojian Wu via cfe-commits
 wrote:
> Author: hokein
> Date: Mon Feb  8 10:05:39 2016
> New Revision: 260108
>
> URL: http://llvm.org/viewvc/llvm-project?rev=260108=rev
> Log:
> [clang-tidy] Some improvements in 'misc-definitions-in-headers' check.
>
> Reviewers: alexfh
>
> Subscribers: cfe-commits
>
> Differential Revision: http://reviews.llvm.org/D16979
>
> Modified:
> clang-tools-extra/trunk/clang-tidy/misc/DefinitionsInHeadersCheck.cpp
>
> Modified: 
> clang-tools-extra/trunk/clang-tidy/misc/DefinitionsInHeadersCheck.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/misc/DefinitionsInHeadersCheck.cpp?rev=260108=260107=260108=diff
> ==
> --- clang-tools-extra/trunk/clang-tidy/misc/DefinitionsInHeadersCheck.cpp 
> (original)
> +++ clang-tools-extra/trunk/clang-tidy/misc/DefinitionsInHeadersCheck.cpp Mon 
> Feb  8 10:05:39 2016
> @@ -51,6 +51,8 @@ void DefinitionsInHeadersCheck::storeOpt
>  }
>
>  void DefinitionsInHeadersCheck::registerMatchers(MatchFinder *Finder) {
> +  if (!getLangOpts().CPlusPlus)
> +return;

C has the same concept, under different wording. Are there plans to
make this check work in C mode as well?

6.2.7p2:
All declarations that refer to the same object or function shall have
compatible type; otherwise, the behavior is undefined.

It seems like this check may be useful for C too with some pretty
simple modifications.

~Aaron

>if (UseHeaderFileExtension) {
>  Finder->addMatcher(
>  namedDecl(anyOf(functionDecl(isDefinition()), 
> varDecl(isDefinition())),
> @@ -78,6 +80,8 @@ void DefinitionsInHeadersCheck::check(co
>// satisfy the following requirements.
>const auto *ND = Result.Nodes.getNodeAs("name-decl");
>assert(ND);
> +  if (ND->isInvalidDecl())
> +return;
>
>// Internal linkage variable definitions are ignored for now:
>//   const int a = 1;
>
>
> ___
> 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] D16953: Enhance clang-tidy modernize-redundant-void-arg check to apply fixes to header files

[Alexander Kornienko via cfe-commits]

alexfh added a comment.

Hi Richard,

Thank you for working on this. The script has been begging for refactoring for 
a while ;) A couple of initial comments, and while I'm looking further into 
into this patch, could you find other possible usages (in currently existing 
tests) of the new functionality in check_clang_tidy.py?

Thanks!



Comment at: test/clang-tidy/check_clang_tidy.py:82
@@ +81,3 @@
+  try:
+clang_tidy_output = \
+  subprocess.check_output(args, stderr=subprocess.STDOUT).decode()

Looks like this function is used not only for clang-tidy. Maybe this variable 
should be named more generically?


Comment at: test/clang-tidy/check_clang_tidy.py:122
@@ -40,2 +121,3 @@
   parser.add_argument('-resource-dir')
+  parser.add_argument('--header-filter')
   parser.add_argument('input_file_name')

There's no need for a separate argument for this. The script passes all 
arguments after a `--` to clang-tidy, so you can just append `-- 
-header-filter=... -- -std=c++11` to the RUN: line in the test.


Comment at: test/clang-tidy/check_clang_tidy.py:152
@@ -68,4 +151,3 @@
 
-  has_check_fixes = input_text.find('CHECK-FIXES') >= 0
-  has_check_messages = input_text.find('CHECK-MESSAGES') >= 0
+  has_check_fixes, has_check_messages = has_checks(input_text)
 

This function doesn't look like a particularly useful one: 5 lines of code 
instead of 2 lines and an unclear interface (in which order do the two bools 
come?). Please revert this part.


http://reviews.llvm.org/D16953



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

Re: [PATCH] D16926: [clang-tidy] Fix assertion failure on `at` function in modernize-loop-convert.

[Haojian Wu via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL260107: [clang-tidy] Fix assertion failure on `at` function 
in modernize-loop-convert. (authored by hokein).

Changed prior to commit:
  http://reviews.llvm.org/D16926?vs=47019=47204#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D16926

Files:
  clang-tools-extra/trunk/clang-tidy/modernize/LoopConvertUtils.cpp
  clang-tools-extra/trunk/docs/clang-tidy/checks/modernize-loop-convert.rst
  
clang-tools-extra/trunk/test/clang-tidy/Inputs/modernize-loop-convert/structures.h
  clang-tools-extra/trunk/test/clang-tidy/modernize-loop-convert-extra.cpp

Index: 
clang-tools-extra/trunk/test/clang-tidy/Inputs/modernize-loop-convert/structures.h
===
--- 
clang-tools-extra/trunk/test/clang-tidy/Inputs/modernize-loop-convert/structures.h
+++ 
clang-tools-extra/trunk/test/clang-tidy/Inputs/modernize-loop-convert/structures.h
@@ -98,6 +98,7 @@
   ElemType & operator[](unsigned);
   const ElemType & operator[](unsigned) const;
   ElemType & at(unsigned);
+  ElemType & at(unsigned, unsigned);
   const ElemType & at(unsigned) const;
 
   // Intentionally evil.
Index: clang-tools-extra/trunk/test/clang-tidy/modernize-loop-convert-extra.cpp
===
--- clang-tools-extra/trunk/test/clang-tidy/modernize-loop-convert-extra.cpp
+++ clang-tools-extra/trunk/test/clang-tidy/modernize-loop-convert-extra.cpp
@@ -251,8 +251,16 @@
   // CHECK-FIXES-NEXT: const int& Idx = Other[0];
   // CHECK-FIXES-NEXT: unsigned Othersize = Other.size();
 
+  for (int i = 0; i <  Other.size(); ++i) {
+Other.at(i);
+  }
+  // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: use range-based for loop instead
+  // CHECK-FIXES: for (int & i : Other)
+  // CHECK-FIXES: i;
+
   for (int I = 0, E = Dep.size(); I != E; ++I) {
 int Idx = Other.at(I);
+Other.at(I, I);  // Should not trigger assert failure.
   }
 }
 
Index: clang-tools-extra/trunk/clang-tidy/modernize/LoopConvertUtils.cpp
===
--- clang-tools-extra/trunk/clang-tidy/modernize/LoopConvertUtils.cpp
+++ clang-tools-extra/trunk/clang-tidy/modernize/LoopConvertUtils.cpp
@@ -391,8 +391,8 @@
 // This check is needed because getMethodDecl can return nullptr if the
 // callee is a member function pointer.
 const auto *MDecl = MemCall->getMethodDecl();
-if (MDecl && !isa(MDecl) && MDecl->getName() == "at") {
-  assert(MemCall->getNumArgs() == 1);
+if (MDecl && !isa(MDecl) && MDecl->getName() == "at" &&
+MemCall->getNumArgs() == 1) {
   return isIndexInSubscriptExpr(MemCall->getArg(0), IndexVar);
 }
 return false;
Index: clang-tools-extra/trunk/docs/clang-tidy/checks/modernize-loop-convert.rst
===
--- clang-tools-extra/trunk/docs/clang-tidy/checks/modernize-loop-convert.rst
+++ clang-tools-extra/trunk/docs/clang-tidy/checks/modernize-loop-convert.rst
@@ -89,7 +89,7 @@
 
   // reasonable conversion
   for (vector::iterator it = v.begin(); it != v.end(); ++it)
-cout << *it;*
+cout << *it;
 
   // reasonable conversion
   for (int i = 0; i < v.size(); ++i)


Index: clang-tools-extra/trunk/test/clang-tidy/Inputs/modernize-loop-convert/structures.h
===
--- clang-tools-extra/trunk/test/clang-tidy/Inputs/modernize-loop-convert/structures.h
+++ clang-tools-extra/trunk/test/clang-tidy/Inputs/modernize-loop-convert/structures.h
@@ -98,6 +98,7 @@
   ElemType & operator[](unsigned);
   const ElemType & operator[](unsigned) const;
   ElemType & at(unsigned);
+  ElemType & at(unsigned, unsigned);
   const ElemType & at(unsigned) const;
 
   // Intentionally evil.
Index: clang-tools-extra/trunk/test/clang-tidy/modernize-loop-convert-extra.cpp
===
--- clang-tools-extra/trunk/test/clang-tidy/modernize-loop-convert-extra.cpp
+++ clang-tools-extra/trunk/test/clang-tidy/modernize-loop-convert-extra.cpp
@@ -251,8 +251,16 @@
   // CHECK-FIXES-NEXT: const int& Idx = Other[0];
   // CHECK-FIXES-NEXT: unsigned Othersize = Other.size();
 
+  for (int i = 0; i <  Other.size(); ++i) {
+Other.at(i);
+  }
+  // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: use range-based for loop instead
+  // CHECK-FIXES: for (int & i : Other)
+  // CHECK-FIXES: i;
+
   for (int I = 0, E = Dep.size(); I != E; ++I) {
 int Idx = Other.at(I);
+Other.at(I, I);  // Should not trigger assert failure.
   }
 }
 
Index: clang-tools-extra/trunk/clang-tidy/modernize/LoopConvertUtils.cpp
===
--- clang-tools-extra/trunk/clang-tidy/modernize/LoopConvertUtils.cpp
+++ clang-tools-extra/trunk/clang-tidy/modernize/LoopConvertUtils.cpp
@@ -391,8 +391,8 @@
 // This check is 

Re: [PATCH] D16535: [clang-tidy] Check to find unintended semicolons that changes the semantics.

[Alexander Kornienko via cfe-commits]

alexfh added a comment.

Sorry for the long delay. Currently rather swamped.

Haojian, could you take a look at this patch?


http://reviews.llvm.org/D16535



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

[PATCH] D16993: Add documentation for bitreverse builtins

[Matt Arsenault via cfe-commits]

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

Description copied from intrinsic

http://reviews.llvm.org/D16993

Files:
  docs/LanguageExtensions.rst

Index: docs/LanguageExtensions.rst
===
--- docs/LanguageExtensions.rst
+++ docs/LanguageExtensions.rst
@@ -1505,6 +1505,31 @@
 
 Query for this feature with ``__has_builtin(__builtin_convertvector)``.
 
+``__builtin_bitreverse``
+-
+
+* ``__builtin_bitreverse16``
+* ``__builtin_bitreverse32``
+* ``__builtin_bitreverse64``
+
+**Syntax**:
+
+.. code-block:: c++
+ __builtin_bitreverse32(x)
+
+**Examples**:
+
+.. code-block:: c++
+  uint16_t rev_x = __builtin_bitreverse16(x);
+  uint32_t rev_y = __builtin_bitreverse32(y);
+  uint64_t rev_z = __builtin_bitreverse64(z);
+
+**Description**:
+
+The '``__builtin_bitreverse``' family of builtins is used to reverse
+the bitpattern of an integer value; for example ``0b1234567`` becomes
+``0b7654321``.
+
 ``__builtin_unreachable``
 -
 


Index: docs/LanguageExtensions.rst
===
--- docs/LanguageExtensions.rst
+++ docs/LanguageExtensions.rst
@@ -1505,6 +1505,31 @@
 
 Query for this feature with ``__has_builtin(__builtin_convertvector)``.
 
+``__builtin_bitreverse``
+-
+
+* ``__builtin_bitreverse16``
+* ``__builtin_bitreverse32``
+* ``__builtin_bitreverse64``
+
+**Syntax**:
+
+.. code-block:: c++
+ __builtin_bitreverse32(x)
+
+**Examples**:
+
+.. code-block:: c++
+  uint16_t rev_x = __builtin_bitreverse16(x);
+  uint32_t rev_y = __builtin_bitreverse32(y);
+  uint64_t rev_z = __builtin_bitreverse64(z);
+
+**Description**:
+
+The '``__builtin_bitreverse``' family of builtins is used to reverse
+the bitpattern of an integer value; for example ``0b1234567`` becomes
+``0b7654321``.
+
 ``__builtin_unreachable``
 -
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D16317: [Analyzer] Fix for PR23790: bind real value returned from strcmp when modelling strcmp.

[Антон Ярцев via cfe-commits]

ayartsev added a comment.

Ping.


http://reviews.llvm.org/D16317



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

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu via cfe-commits]

On Mon, Feb 8, 2016 at 7:59 AM, Jonathan Wakely  wrote:
> On 8 February 2016 at 15:42, H.J. Lu  wrote:
>> On Mon, Feb 8, 2016 at 7:02 AM, Jonathan Wakely  
>> wrote:
>>> On 8 February 2016 at 13:54, H.J. Lu  wrote:
 On Sun, Feb 7, 2016 at 12:52 PM, H.J. Lu  wrote:

 The standard-layout POD is well defined:

 https://en.wikipedia.org/wiki/C%2B%2B11#Modification_to_the_definition_of_plain_old_data

 Here is the updated proposal for  Intel386, x86-64 and IA MCU psABIs:

 1. "collection".  A collection is a structure, union or C++ class.
>>>
>>> These are all "class types". Why invent a new term?
>>
>> Because it applies to both C and C++.  There is no class in C.
>
> Then you could use the term "class type" in the ABI, defining it to
> mean structure or union in C, or class type in C++. No need for a new
> term.

I will do it.

>
 2. "empty collection".  An empty collection is:
a. A collection without member.  Or
>>>
>>> What about base classes?
>>>
>>> What about bit-fields of length 0?
>>
>> Is a collection with them standard-layout POD type?
>
> (I'm not sure what the "bit-fields of length 0" part is for, but my
> point is it would be useful to examine similar concepts in the
> standard and align with them, not just make up entirely new
> classifications.)

I am replying on C++ compiler to tell if it is standard-layout
or not.

> For base classes, yes. A standard-layout class can have base classes
> of standard-layout type.
>
> struct A { };
> struct B { };
> struct C : A, B { };
>
> C is a standard-layout type. Is it an empty collection?

My understanding is

A type that is standard-layout means that it orders and packs its
members in a way that is compatible with C.

What is the corresponding compatible type in C?

b. A collection with only empty collections.  Or
>>>
>>> What does "with" mean? Only members, or bases too?
>>
>> Is "A collection with only members of empty collections" better?
>
> Should it mention base classes?

It depends on the answer of my question above.

>
c. An array of empty collections.
 3. "empty record".  An empty record is Plain Old Data (POD) for the purpose
of standard-layout and
>>>
>>> "For the purposes of standard-layout" doesn't mean anything.
>>>
>>> A type is a standard-layout type, or it isn't.
>>
>> How about "An empty record is standard-layout Plain Old Data (POD)
>> type and ..."?
>
> That's redundant, all POD types are standard-layout types.
>

I will update it.

Thanks.


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

Re: [PATCH] D16524: [clang-format-vs] Fix sort include main include: Use current path for the '-assume-filename'

[Jean-Philippe Dufraigne via cfe-commits]

jeanphilippeD added a comment.

Ping,

Hi Daniel,

Sorry, should I have put someone else as reviewer, I see the previous 
committers for this file where Manuel Klimek, Hans Wennborg and Marek Kurdej.
Should have i added any or all of them.

I thought it made sense to put you originally since you updated the code for 
sort include in clang-format.

Kind Regards,
Jean-Philippe.


http://reviews.llvm.org/D16524



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

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[Jonathan Wakely via cfe-commits]

On 8 February 2016 at 15:42, H.J. Lu  wrote:
> On Mon, Feb 8, 2016 at 7:02 AM, Jonathan Wakely  wrote:
>> On 8 February 2016 at 13:54, H.J. Lu  wrote:
>>> On Sun, Feb 7, 2016 at 12:52 PM, H.J. Lu  wrote:
>>>
>>> The standard-layout POD is well defined:
>>>
>>> https://en.wikipedia.org/wiki/C%2B%2B11#Modification_to_the_definition_of_plain_old_data
>>>
>>> Here is the updated proposal for  Intel386, x86-64 and IA MCU psABIs:
>>>
>>> 1. "collection".  A collection is a structure, union or C++ class.
>>
>> These are all "class types". Why invent a new term?
>
> Because it applies to both C and C++.  There is no class in C.

Then you could use the term "class type" in the ABI, defining it to
mean structure or union in C, or class type in C++. No need for a new
term.


>>> 2. "empty collection".  An empty collection is:
>>>a. A collection without member.  Or
>>
>> What about base classes?
>>
>> What about bit-fields of length 0?
>
> Is a collection with them standard-layout POD type?

(I'm not sure what the "bit-fields of length 0" part is for, but my
point is it would be useful to examine similar concepts in the
standard and align with them, not just make up entirely new
classifications.)

For base classes, yes. A standard-layout class can have base classes
of standard-layout type.

struct A { };
struct B { };
struct C : A, B { };

C is a standard-layout type. Is it an empty collection?


>>>b. A collection with only empty collections.  Or
>>
>> What does "with" mean? Only members, or bases too?
>
> Is "A collection with only members of empty collections" better?

Should it mention base classes?


>>>c. An array of empty collections.
>>> 3. "empty record".  An empty record is Plain Old Data (POD) for the purpose
>>>of standard-layout and
>>
>> "For the purposes of standard-layout" doesn't mean anything.
>>
>> A type is a standard-layout type, or it isn't.
>
> How about "An empty record is standard-layout Plain Old Data (POD)
> type and ..."?

That's redundant, all POD types are standard-layout types.


>> Do you mean "An empty record is a standard-layout type and..."
>>
>>>a. A collection without member.  Or
>>>b. A collection with only empty collections.
>>
>> ?
>>
>
> Is "A collection with only members of empty collections" better?
>
>>
>>> 4. No memory slot nor register should be used to pass or return an object of
>>> empty record.
>
>
>
> --
> H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D16987: [clang-tidy] Correct IncorrectRoundings namespace.

[Haojian Wu via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL260105: [clang-tidy] Correct IncorrectRoundings namespace. 
(authored by hokein).

Changed prior to commit:
  http://reviews.llvm.org/D16987?vs=47199=47202#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D16987

Files:
  clang-tools-extra/trunk/clang-tidy/misc/IncorrectRoundings.cpp
  clang-tools-extra/trunk/clang-tidy/misc/IncorrectRoundings.h

Index: clang-tools-extra/trunk/clang-tidy/misc/IncorrectRoundings.h
===
--- clang-tools-extra/trunk/clang-tidy/misc/IncorrectRoundings.h
+++ clang-tools-extra/trunk/clang-tidy/misc/IncorrectRoundings.h
@@ -14,6 +14,7 @@
 
 namespace clang {
 namespace tidy {
+namespace misc {
 
 /// \brief Checks the usage of patterns known to produce incorrect rounding.
 /// Programmers often use
@@ -31,8 +32,8 @@
   void check(const ast_matchers::MatchFinder::MatchResult ) override;
 };
 
+} // namespace misc
 } // namespace tidy
 } // namespace clang
 
-
 #endif  // LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_MISC_INCORRECTROUNDINGS_H_
Index: clang-tools-extra/trunk/clang-tidy/misc/IncorrectRoundings.cpp
===
--- clang-tools-extra/trunk/clang-tidy/misc/IncorrectRoundings.cpp
+++ clang-tools-extra/trunk/clang-tidy/misc/IncorrectRoundings.cpp
@@ -36,6 +36,7 @@
 
 namespace clang {
 namespace tidy {
+namespace misc {
 void IncorrectRoundings::registerMatchers(MatchFinder *MatchFinder) {
   // Match a floating literal with value 0.5.
   auto FloatHalf = floatLiteral(floatHalf());
@@ -70,5 +71,6 @@
"consider using lround (#include ) instead");
 }
 
+} // namespace misc
 } // namespace tidy
 } // namespace clang


Index: clang-tools-extra/trunk/clang-tidy/misc/IncorrectRoundings.h
===
--- clang-tools-extra/trunk/clang-tidy/misc/IncorrectRoundings.h
+++ clang-tools-extra/trunk/clang-tidy/misc/IncorrectRoundings.h
@@ -14,6 +14,7 @@
 
 namespace clang {
 namespace tidy {
+namespace misc {
 
 /// \brief Checks the usage of patterns known to produce incorrect rounding.
 /// Programmers often use
@@ -31,8 +32,8 @@
   void check(const ast_matchers::MatchFinder::MatchResult ) override;
 };
 
+} // namespace misc
 } // namespace tidy
 } // namespace clang
 
-
 #endif  // LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_MISC_INCORRECTROUNDINGS_H_
Index: clang-tools-extra/trunk/clang-tidy/misc/IncorrectRoundings.cpp
===
--- clang-tools-extra/trunk/clang-tidy/misc/IncorrectRoundings.cpp
+++ clang-tools-extra/trunk/clang-tidy/misc/IncorrectRoundings.cpp
@@ -36,6 +36,7 @@
 
 namespace clang {
 namespace tidy {
+namespace misc {
 void IncorrectRoundings::registerMatchers(MatchFinder *MatchFinder) {
   // Match a floating literal with value 0.5.
   auto FloatHalf = floatLiteral(floatHalf());
@@ -70,5 +71,6 @@
"consider using lround (#include ) instead");
 }
 
+} // namespace misc
 } // namespace tidy
 } // namespace clang
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D16989: Change interpretation of function definition in friend declaration of template class.

[Serge Pavlov via cfe-commits]

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

Previously if a file-level function was defined inside befriending
template class, it was treated as defined in the code like:
```
  void func(int);
  template class C1 {
friend void func(int) {}
  };
  void m() {
func(1);
  }
```

The Standard requests ([temp.friend], p5) that `When a function is defined in
a friend function declaration in a class template, the function is instantiated
when the function is odr-used`. This statement however does not specify which
template is used for the instantiation, if the function is defined in several,
and what parameters are used for the instantiation. The latter is important if
the function implementation uses template parameter, such usage is not 
prohibited
by the Standard.

Other compilers (gcc, icc) follow viewpoint that body of the function defined
in friend declaration becomes available when corresponding class is 
instantiated.
This patch implements this viewpoint in clang.

Definitions introduced by friend declarations in template classes are added to
the redeclaration chain of corresponding function, but they do not make the
function defined. Only if such definition corresponds to the template
instantiation, the function becomes defined. Presence of function body is not
enough for function definition anymore.

This change fixes PR17923, PR22307 and PR25848.

http://reviews.llvm.org/D16989

Files:
  include/clang/AST/Decl.h
  lib/AST/Decl.cpp
  lib/CodeGen/CodeGenModule.cpp
  lib/Sema/Sema.cpp
  lib/Sema/SemaDecl.cpp
  lib/Sema/SemaTemplateInstantiateDecl.cpp
  test/SemaCXX/PR25848.cpp
  test/SemaCXX/friend2.cpp

Index: test/SemaCXX/friend2.cpp
===
--- /dev/null
+++ test/SemaCXX/friend2.cpp
@@ -0,0 +1,135 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s -std=c++11
+
+// If a friend function is defined in several non-template classes,
+// it is an error.
+
+void func1(int);
+struct C1a {
+  friend void func1(int) {}  // expected-note{{previous definition is here}}
+};
+struct C1b {
+  friend void func1(int) {}  // expected-error{{redefinition of 'func1'}}
+};
+
+
+// If a friend function is defined in both non-template and template
+// classes it is an error only if the template is instantiated.
+
+void func2(int);
+struct C2a {
+  friend void func2(int) {}
+};
+template struct C2b {
+  friend void func2(int) {}
+};
+
+void func3(int);
+struct C3a {
+  friend void func3(int) {}  // expected-note{{previous definition is here}}
+};
+template struct C3b {
+  friend void func3(int) {}  // expected-error{{redefinition of 'func3'}}
+};
+C3b c3;  // expected-note{{in instantiation of template class 'C3b' requested here}}
+
+
+// If a friend function is defined in several template classes it is an error
+// only if several templates are instantiated.
+
+void func4(int);
+template struct C4a {
+  friend void func4(int) {}
+};
+template struct C4b {
+  friend void func4(int) {}
+};
+
+
+void func5(int);
+template struct C5a {
+  friend void func5(int) {}
+};
+template struct C5b {
+  friend void func5(int) {}
+};
+C5a c5a;
+
+void func6(int);
+template struct C6a {
+  friend void func6(int) {}  // expected-note{{previous definition is here}}
+};
+template struct C6b {
+  friend void func6(int) {}  // expected-error{{redefinition of 'func6'}}
+};
+C6a c6a;
+C6b c6b;  // expected-note{{in instantiation of template class 'C6b' requested here}}
+
+void func7(int);
+template struct C7 {
+  friend void func7(int) {}  // expected-error{{redefinition of 'func7'}}
+ // expected-note@-1{{previous definition is here}}
+};
+C7 c7a;
+C7 c7b;  // expected-note{{in instantiation of template class 'C7' requested here}}
+
+
+// Even if clases are not instantiated and hence friend functions defined in them are not
+// available, their declarations must be checked.
+
+void func8(int);  // expected-note{{previous declaration is here}}
+template struct C8a {
+  friend long func8(int) {}  // expected-error{{functions that differ only in their return type cannot be overloaded}}
+};
+
+
+namespace pr22307 {
+
+struct t {
+  friend int leak(t);
+};
+
+template
+struct m {
+  friend int leak(t) { return sizeof(v); }  // expected-error{{redefinition of 'leak'}} expected-note{{previous definition is here}}
+};
+
+template struct m;
+template struct m;  // expected-note{{in instantiation of template class 'pr22307::m' requested here}}
+
+int main() {
+  leak(t());
+}
+
+}
+
+namespace pr17923 {
+
+void f(unsigned long long);
+
+template struct X {
+  friend void f(unsigned long long) {
+ T t;
+  }
+};
+
+int main() { f(1234); }
+
+}
+
+namespace pr17923a {
+
+int get();
+
+template< int value >
+class set {
+  friend int get()
+{ return value; } // return 0; is OK
+};
+
+template class set< 5 >;
+
+int main() {
+  get();
+}
+
+}
Index: test/SemaCXX/PR25848.cpp

Re: [PATCH] D16529: [clang-tidy] Add modernize-raw-string-literal check

[Richard via cfe-commits]

LegalizeAdulthood added a comment.

I wrote:

> Repeated searching of the string for the literal delimiter could be avoided 
> by changing the routine to search for the delimiter. If present, it could 
> examine the characters following the literal to make the literal more unique 
> and then continue searching from there to look for more occurrences of the 
> extended delimiter. It would proceed incrementally through the rest of the 
> string to create a unique delimiter in a single pass through the string. I 
> think the resulting literals would be even more non-sensical than the current 
> implementation, but it would result in a delimiter obtained by a single pass 
> through the string. It's a significantly more complicated implementation and 
> results in an even weirder delimiter to handle a very edge case.


Unfortunately in this paragraph I used the term "literal" in several places 
where I should have said "delimiter".  I hope that wasn't too confusing.  It 
should have read:

> Repeated searching of the string for the delimiter could be avoided by 
> changing the routine to search for the delimiter. If present, it could 
> examine the characters following the delimiter to make the delimiter more 
> unique and then continue searching from there to look for more occurrences of 
> the extended delimiter. It would proceed incrementally through the rest of 
> the string to create a unique delimiter in a single pass through the string. 
> I think the resulting delimiters would be even more non-sensical than the 
> current implementation, but it would result in a delimiter obtained by a 
> single pass through the string. It's a significantly more complicated 
> implementation and results in an even weirder delimiter to handle a very edge 
> case.



http://reviews.llvm.org/D16529



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

r260104 - Move static functions returning UDTs outside of the extern "C" block. Silences an MSVC warning, and reduces the number of exported symbols.

[Aaron Ballman via cfe-commits]

Author: aaronballman
Date: Mon Feb  8 09:52:13 2016
New Revision: 260104

URL: http://llvm.org/viewvc/llvm-project?rev=260104=rev
Log:
Move static functions returning UDTs outside of the extern "C" block. Silences 
an MSVC warning, and reduces the number of exported symbols.

Modified:
cfe/trunk/tools/libclang/CIndex.cpp

Modified: cfe/trunk/tools/libclang/CIndex.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/libclang/CIndex.cpp?rev=260104=260103=260104=diff
==
--- cfe/trunk/tools/libclang/CIndex.cpp (original)
+++ cfe/trunk/tools/libclang/CIndex.cpp Mon Feb  8 09:52:13 2016
@@ -3996,6 +3996,39 @@ static std::string getMangledStructor(st
   return BOS.str();
 }
 
+static std::string getMangledName(std::unique_ptr ,
+  std::unique_ptr ,
+  const NamedDecl *ND) {
+  std::string FrontendBuf;
+  llvm::raw_string_ostream FOS(FrontendBuf);
+
+  M->mangleName(ND, FOS);
+
+  std::string BackendBuf;
+  llvm::raw_string_ostream BOS(BackendBuf);
+
+  llvm::Mangler::getNameWithPrefix(BOS, llvm::Twine(FOS.str()), *DL);
+
+  return BOS.str();
+}
+
+static std::string getMangledThunk(std::unique_ptr ,
+   std::unique_ptr ,
+   const CXXMethodDecl *MD,
+   const ThunkInfo ) {
+  std::string FrontendBuf;
+  llvm::raw_string_ostream FOS(FrontendBuf);
+
+  M->mangleThunk(MD, T, FOS);
+
+  std::string BackendBuf;
+  llvm::raw_string_ostream BOS(BackendBuf);
+
+  llvm::Mangler::getNameWithPrefix(BOS, llvm::Twine(FOS.str()), *DL);
+
+  return BOS.str();
+}
+
 extern "C" {
 
 unsigned clang_visitChildren(CXCursor parent,
@@ -4369,38 +4402,6 @@ CXString clang_Cursor_getMangling(CXCurs
   return cxstring::createDup(FinalBufOS.str());
 }
 
-static std::string getMangledName(std::unique_ptr ,
-  std::unique_ptr ,
-  const NamedDecl *ND) {
-  std::string FrontendBuf;
-  llvm::raw_string_ostream FOS(FrontendBuf);
-
-  M->mangleName(ND, FOS);
-
-  std::string BackendBuf;
-  llvm::raw_string_ostream BOS(BackendBuf);
-
-  llvm::Mangler::getNameWithPrefix(BOS, llvm::Twine(FOS.str()), *DL);
-
-  return BOS.str();
-}
-
-static std::string getMangledThunk(std::unique_ptr ,
-   std::unique_ptr ,
-   const CXXMethodDecl *MD, const ThunkInfo 
) {
-  std::string FrontendBuf;
-  llvm::raw_string_ostream FOS(FrontendBuf);
-
-  M->mangleThunk(MD, T, FOS);
-
-  std::string BackendBuf;
-  llvm::raw_string_ostream BOS(BackendBuf);
-
-  llvm::Mangler::getNameWithPrefix(BOS, llvm::Twine(FOS.str()), *DL);
-
-  return BOS.str();
-}
-
 CXStringSet *clang_Cursor_getCXXManglings(CXCursor C) {
   if (clang_isInvalid(C.kind) || !clang_isDeclaration(C.kind))
 return nullptr;


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

Re: [PATCH] D16310: new clang-tidy checker misc-long-cast

[Alexander Kornienko via cfe-commits]

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

Looks good after fixing capitalization in comments.

Thank you!



Comment at: clang-tidy/misc/MisplacedWideningCastCheck.cpp:32
@@ +31,3 @@
+   has(Calc))
+  .bind("Cast");
+

Err, no. I was wrong. Not all of them can be combined: the stmts and decls 
still need to be separate, so just ignore that comment ;)


Comment at: clang-tidy/misc/MisplacedWideningCastCheck.cpp:80
@@ +79,3 @@
+void MisplacedWideningCastCheck::check(const MatchFinder::MatchResult ) 
{
+  const auto *Cast = Result.Nodes.getNodeAs("Cast");
+  if (Cast->getLocStart().isMacroID())

The assert here could simplify debugging a bit in case the matchers are changed 
and the invariant doesn't hold any more (and the check starts crashing after 
this line). I don't feel strongly about the presence of an assert in similar 
places, but there definitely should be no `if`.


Comment at: docs/clang-tidy/checks/misc-misplaced-widening-cast.rst:2
@@ +1,3 @@
+.. title:: clang-tidy - misc-misplaced-widening-cast
+
+misc-misplaced-widening-cast

danielmarjamaki wrote:
> For information, it seem I had to use -DLLVM_ENABLE_SPHINX=ON also ..
Yes, thanks. Apparently, I haven't found all relevant flags in ccmake.


Comment at: test/clang-tidy/misc-misplaced-widening-cast.cpp:32
@@ +31,3 @@
+  // the result is a 9 bit value, there is no truncation in the implicit cast.
+  l = (long)(a + 15);
+  // the result is a 12 bit value, there is no truncation in the implicit cast.

You missed the "capitalization" part ;)


http://reviews.llvm.org/D16310



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

Re: [PATCH] D16987: [clang-tidy] Correct IncorrectRoundings namespace.

[Alexander Kornienko via cfe-commits]

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

LG


Repository:
  rL LLVM

http://reviews.llvm.org/D16987



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

r260106 - Re-apply for the 2nd-time r259977 - [OpenMP] Reorganize code to allow specialized code generation for different devices.

[Samuel Antao via cfe-commits]

Author: sfantao
Date: Mon Feb  8 09:59:20 2016
New Revision: 260106

URL: http://llvm.org/viewvc/llvm-project?rev=260106=rev
Log:
Re-apply for the 2nd-time r259977 - [OpenMP] Reorganize code to allow 
specialized code generation for different devices.

This was reverted by r260036, but was not the cause of the problem in the 
buildbot.


Added:
cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.h
Modified:
cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
cfe/trunk/lib/CodeGen/CMakeLists.txt
cfe/trunk/lib/CodeGen/CodeGenModule.cpp
cfe/trunk/lib/Frontend/CompilerInvocation.cpp
cfe/trunk/test/OpenMP/target_messages.cpp

Modified: cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td?rev=260106=260105=260106=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td Mon Feb  8 09:59:20 
2016
@@ -132,7 +132,9 @@ def err_drv_no_neon_modifier : Error<"[n
 def err_drv_invalid_omp_target : Error<"OpenMP target is invalid: '%0'">;
 def err_drv_omp_host_ir_file_not_found : Error<
   "The provided host compiler IR file '%0' is required to generate code for 
OpenMP target regions but cannot be found.">;
-
+def err_drv_omp_host_target_not_supported : Error<
+  "The target '%0' is not a supported OpenMP host target.">;
+  
 def warn_O4_is_O3 : Warning<"-O4 is equivalent to -O3">, InGroup;
 def warn_drv_lto_libpath : Warning<"libLTO.dylib relative to clang installed 
dir not found; using 'ld' default search path instead">,
   InGroup;

Added: cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp?rev=260106=auto
==
--- cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp (added)
+++ cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp Mon Feb  8 09:59:20 2016
@@ -0,0 +1,21 @@
+//=== CGOpenMPRuntimeNVPTX.cpp - Interface to OpenMP NVPTX Runtimes 
---===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+//
+// This provides a class for OpenMP runtime code generation specialized to 
NVPTX
+// targets.
+//
+//===--===//
+
+#include "CGOpenMPRuntimeNVPTX.h"
+
+using namespace clang;
+using namespace CodeGen;
+
+CGOpenMPRuntimeNVPTX::CGOpenMPRuntimeNVPTX(CodeGenModule )
+: CGOpenMPRuntime(CGM) {}

Added: cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.h?rev=260106=auto
==
--- cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.h (added)
+++ cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.h Mon Feb  8 09:59:20 2016
@@ -0,0 +1,31 @@
+//===- CGOpenMPRuntimeNVPTX.h - Interface to OpenMP NVPTX Runtimes 
===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+//
+// This provides a class for OpenMP runtime code generation specialized to 
NVPTX
+// targets.
+//
+//===--===//
+
+#ifndef LLVM_CLANG_LIB_CODEGEN_CGOPENMPRUNTIMENVPTX_H
+#define LLVM_CLANG_LIB_CODEGEN_CGOPENMPRUNTIMENVPTX_H
+
+#include "CGOpenMPRuntime.h"
+
+namespace clang {
+namespace CodeGen {
+
+class CGOpenMPRuntimeNVPTX : public CGOpenMPRuntime {
+public:
+  explicit CGOpenMPRuntimeNVPTX(CodeGenModule );
+};
+
+} // CodeGen namespace.
+} // clang namespace.
+
+#endif // LLVM_CLANG_LIB_CODEGEN_CGOPENMPRUNTIMENVPTX_H

Modified: cfe/trunk/lib/CodeGen/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CMakeLists.txt?rev=260106=260105=260106=diff
==
--- cfe/trunk/lib/CodeGen/CMakeLists.txt (original)
+++ cfe/trunk/lib/CodeGen/CMakeLists.txt Mon Feb  8 09:59:20 2016
@@ -57,6 +57,7 @@ add_clang_library(clangCodeGen
   CGObjCRuntime.cpp
   CGOpenCLRuntime.cpp
   CGOpenMPRuntime.cpp
+  CGOpenMPRuntimeNVPTX.cpp
   CGRecordLayoutBuilder.cpp
   CGStmt.cpp
   CGStmtOpenMP.cpp

Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp?rev=260106=260105=260106=diff

[clang-tools-extra] r260105 - [clang-tidy] Correct IncorrectRoundings namespace.

[Haojian Wu via cfe-commits]

Author: hokein
Date: Mon Feb  8 09:54:30 2016
New Revision: 260105

URL: http://llvm.org/viewvc/llvm-project?rev=260105=rev
Log:
[clang-tidy] Correct IncorrectRoundings namespace.

Reviewers: alexfh

Subscribers: cfe-commits

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

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

Modified: clang-tools-extra/trunk/clang-tidy/misc/IncorrectRoundings.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/misc/IncorrectRoundings.cpp?rev=260105=260104=260105=diff
==
--- clang-tools-extra/trunk/clang-tidy/misc/IncorrectRoundings.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/misc/IncorrectRoundings.cpp Mon Feb  8 
09:54:30 2016
@@ -36,6 +36,7 @@ using namespace clang::ast_matchers;
 
 namespace clang {
 namespace tidy {
+namespace misc {
 void IncorrectRoundings::registerMatchers(MatchFinder *MatchFinder) {
   // Match a floating literal with value 0.5.
   auto FloatHalf = floatLiteral(floatHalf());
@@ -70,5 +71,6 @@ void IncorrectRoundings::check(const Mat
"consider using lround (#include ) instead");
 }
 
+} // namespace misc
 } // namespace tidy
 } // namespace clang

Modified: clang-tools-extra/trunk/clang-tidy/misc/IncorrectRoundings.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/misc/IncorrectRoundings.h?rev=260105=260104=260105=diff
==
--- clang-tools-extra/trunk/clang-tidy/misc/IncorrectRoundings.h (original)
+++ clang-tools-extra/trunk/clang-tidy/misc/IncorrectRoundings.h Mon Feb  8 
09:54:30 2016
@@ -14,6 +14,7 @@
 
 namespace clang {
 namespace tidy {
+namespace misc {
 
 /// \brief Checks the usage of patterns known to produce incorrect rounding.
 /// Programmers often use
@@ -31,8 +32,8 @@ public:
   void check(const ast_matchers::MatchFinder::MatchResult ) override;
 };
 
+} // namespace misc
 } // namespace tidy
 } // namespace clang
 
-
 #endif  // LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_MISC_INCORRECTROUNDINGS_H_


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

Re: [PATCH] D16953: Enhance clang-tidy modernize-redundant-void-arg check to apply fixes to header files

[Richard via cfe-commits]

LegalizeAdulthood added inline comments.


Comment at: test/clang-tidy/check_clang_tidy.py:122
@@ -40,2 +121,3 @@
   parser.add_argument('-resource-dir')
+  parser.add_argument('--header-filter')
   parser.add_argument('input_file_name')

alexfh wrote:
> There's no need for a separate argument for this. The script passes all 
> arguments after a `--` to clang-tidy, so you can just append `-- 
> -header-filter=... -- -std=c++11` to the RUN: line in the test.
This argument is the key to making everything work.  It triggers the copying of 
the header, the cleaning of the header of `CHECK-FIXES` and `CHECK-MESSAGES`, 
the diffing of the header, etc.

I originally had it like you suggested by trying to have the test file pass all 
the necessary extra arguments to clang-tidy, but it just isn't enough.  The 
script needs to do a bunch of extra work when headers are involved, so it 
seemed to make the most sense to pass the argument directly to the script so 
that it knows to do this extra work.

In other words, express the intent directly to the script instead of having the 
script infer intent by scraping through extra arguments.

Additionally, this preserves the behavior of eliminating duplicated arguments 
across all clang-tidy tests because the script will assume `-std=c++11` for 
`.cpp` files.


Comment at: test/clang-tidy/check_clang_tidy.py:152
@@ -68,4 +151,3 @@
 
-  has_check_fixes = input_text.find('CHECK-FIXES') >= 0
-  has_check_messages = input_text.find('CHECK-MESSAGES') >= 0
+  has_check_fixes, has_check_messages = has_checks(input_text)
 

alexfh wrote:
> This function doesn't look like a particularly useful one: 5 lines of code 
> instead of 2 lines and an unclear interface (in which order do the two bools 
> come?). Please revert this part.
I initially had it doing the same checks on the header file as well and then it 
made more sense.  I dug myself into a dead-end on that series of changes, 
reverted and started over.

What I settled on here was the assumption that you won't have `CHECK-MESSAGES` 
or `CHECK-FIXES` in your header file, unless you also had them in the 
associated source file.  If that assumption is invalid, then I should call this 
function again for the header and change the tests to be asserting fixes in the 
source or header, messages in the source or header in various places.


http://reviews.llvm.org/D16953



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

Re: r260077 - [OPENMP 4.5] Ccapture/codegen of private non-static data members.

[NAKAMURA Takumi via cfe-commits]

The test is incompatible to i686-pc-win32. See also
http://bb.pgr.jp/builders/ninja-clang-i686-msc18-R/builds/5498

On Mon, Feb 8, 2016 at 6:33 PM Alexey Bataev via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: abataev
> Date: Mon Feb  8 03:29:13 2016
> New Revision: 260077
>
> URL: http://llvm.org/viewvc/llvm-project?rev=260077=rev
> Log:
> [OPENMP 4.5] Ccapture/codegen of private non-static data members.
> OpenMP 4.5 introduces privatization of non-static data members of current
> class in non-static member functions.
> To correctly handle such kind of privatization a new (pseudo)declaration
> VarDecl-based node is added. It allows to reuse an existing code for
> capturing variables in Lambdas/Block/Captured blocks of code for correct
> privatization and codegen.
>
> Modified:
> cfe/trunk/include/clang/AST/DeclOpenMP.h
> cfe/trunk/include/clang/AST/RecursiveASTVisitor.h
> cfe/trunk/include/clang/Basic/DeclNodes.td
> cfe/trunk/include/clang/Sema/Sema.h
> cfe/trunk/include/clang/Serialization/ASTBitCodes.h
> cfe/trunk/lib/AST/DeclBase.cpp
> cfe/trunk/lib/AST/DeclOpenMP.cpp
> cfe/trunk/lib/AST/DeclPrinter.cpp
> cfe/trunk/lib/AST/StmtPrinter.cpp
> cfe/trunk/lib/CodeGen/CGDecl.cpp
> cfe/trunk/lib/Sema/SemaExpr.cpp
> cfe/trunk/lib/Sema/SemaExprMember.cpp
> cfe/trunk/lib/Sema/SemaOpenMP.cpp
> cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp
> cfe/trunk/lib/Serialization/ASTCommon.cpp
> cfe/trunk/lib/Serialization/ASTReaderDecl.cpp
> cfe/trunk/lib/Serialization/ASTWriterDecl.cpp
> cfe/trunk/test/OpenMP/parallel_private_codegen.cpp
> cfe/trunk/tools/libclang/CIndex.cpp
>
> Modified: cfe/trunk/include/clang/AST/DeclOpenMP.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/DeclOpenMP.h?rev=260077=260076=260077=diff
>
> ==
> --- cfe/trunk/include/clang/AST/DeclOpenMP.h (original)
> +++ cfe/trunk/include/clang/AST/DeclOpenMP.h Mon Feb  8 03:29:13 2016
> @@ -87,6 +87,35 @@ public:
>static bool classofKind(Kind K) { return K == OMPThreadPrivate; }
>  };
>
> -}  // end namespace clang
> +/// Pseudo declaration for capturing of non-static data members in
> non-static
> +/// member functions.
> +///
> +/// Clang supports capturing of variables only, but OpenMP 4.5 allows to
> +/// privatize non-static members of current class in non-static member
> +/// functions. This pseudo-declaration allows properly handle this kind of
> +/// capture by wrapping captured expression into a variable-like
> declaration.
> +class OMPCapturedFieldDecl final : public VarDecl {
> +  friend class ASTDeclReader;
> +  void anchor() override;
> +
> +  OMPCapturedFieldDecl(ASTContext , DeclContext *DC, IdentifierInfo *Id,
> +   QualType Type)
> +  : VarDecl(OMPCapturedField, C, DC, SourceLocation(),
> SourceLocation(), Id,
> +Type, nullptr, SC_None) {
> +setImplicit();
> +  }
> +
> +public:
> +  static OMPCapturedFieldDecl *Create(ASTContext , DeclContext *DC,
> +  IdentifierInfo *Id, QualType T);
> +
> +  static OMPCapturedFieldDecl *CreateDeserialized(ASTContext , unsigned
> ID);
> +
> +  // Implement isa/cast/dyncast/etc.
> +  static bool classof(const Decl *D) { return classofKind(D->getKind()); }
> +  static bool classofKind(Kind K) { return K == OMPCapturedField; }
> +};
> +
> +} // end namespace clang
>
>  #endif
>
> Modified: cfe/trunk/include/clang/AST/RecursiveASTVisitor.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/RecursiveASTVisitor.h?rev=260077=260076=260077=diff
>
> ==
> --- cfe/trunk/include/clang/AST/RecursiveASTVisitor.h (original)
> +++ cfe/trunk/include/clang/AST/RecursiveASTVisitor.h Mon Feb  8 03:29:13
> 2016
> @@ -1434,6 +1434,8 @@ DEF_TRAVERSE_DECL(OMPThreadPrivateDecl,
>}
>  })
>
> +DEF_TRAVERSE_DECL(OMPCapturedFieldDecl, { TRY_TO(TraverseVarHelper(D)); })
> +
>  // A helper method for TemplateDecl's children.
>  template 
>  bool RecursiveASTVisitor::TraverseTemplateParameterListHelper(
>
> Modified: cfe/trunk/include/clang/Basic/DeclNodes.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DeclNodes.td?rev=260077=260076=260077=diff
>
> ==
> --- cfe/trunk/include/clang/Basic/DeclNodes.td (original)
> +++ cfe/trunk/include/clang/Basic/DeclNodes.td Mon Feb  8 03:29:13 2016
> @@ -51,6 +51,7 @@ def Named : Decl<1>;
>  : DDecl;
>  def ImplicitParam : DDecl;
>  def ParmVar : DDecl;
> +def OMPCapturedField : DDecl;
>def NonTypeTemplateParm : DDecl;
>def Template : DDecl;
>  def RedeclarableTemplate : DDecl;
>
> Modified: cfe/trunk/include/clang/Sema/Sema.h
> URL:
> 

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

[Aleksei Sidorin via cfe-commits]

a.sidorin added inline comments.


Comment at: llvm/tools/clang/lib/StaticAnalyzer/Core/MemRegion.cpp:792
@@ +791,3 @@
+
+const MemRegion* MemRegionManager::getMemSpaceForLocalVariable(const VarDecl 
*D, llvm::PointerUnion ) {
+  const StackFrameContext *STC = V.get();

That needs to be formatted. Also, you may pass `const StackFrameContext *` 
instead of `PointerUnion` (as Devin pointed) because it is only used once to 
get SFC.
And I still think that making these function return `const MemSpaceRegion *` is 
a good idea.


http://reviews.llvm.org/D16873



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

Re: [PATCH] D16764: [clang-tidy] Move incorrect-roundings to upstream.

[Haojian Wu via cfe-commits]

hokein updated this revision to Diff 47167.
hokein marked 2 inline comments as done.
hokein added a comment.

Update test.


http://reviews.llvm.org/D16764

Files:
  clang-tidy/misc/CMakeLists.txt
  clang-tidy/misc/IncorrectRoundings.cpp
  clang-tidy/misc/IncorrectRoundings.h
  clang-tidy/misc/MiscTidyModule.cpp
  docs/clang-tidy/checks/list.rst
  docs/clang-tidy/checks/misc-incorrect-roundings.rst
  test/clang-tidy/misc-incorrect-roundings.cpp

Index: test/clang-tidy/misc-incorrect-roundings.cpp
===
--- /dev/null
+++ test/clang-tidy/misc-incorrect-roundings.cpp
@@ -0,0 +1,86 @@
+// RUN: %check_clang_tidy %s misc-incorrect-roundings %t
+
+void b(int x) {}
+
+void f1() {
+  float f;
+  double d;
+  long double ld;
+  int x;
+
+  x = (d + 0.5);
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: casting (double + 0.5) to integer leads to incorrect rounding; consider using lround (#include ) instead [misc-incorrect-roundings]
+  x = (d + 0.5f);
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: casting (double + 0.5)
+  x = (f + 0.5);
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: casting (double + 0.5)
+  x = (f + 0.5f);
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: casting (double + 0.5)
+  x = (0.5 + d);
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: casting (double + 0.5)
+  x = (0.5f + d);
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: casting (double + 0.5)
+  x = (0.5 + ld);
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: casting (double + 0.5)
+  x = (0.5f + ld);
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: casting (double + 0.5)
+  x = (0.5 + f);
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: casting (double + 0.5)
+  x = (0.5f + f);
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: casting (double + 0.5)
+  x = (int)(d + 0.5);
+  // CHECK-MESSAGES: [[@LINE-1]]:12: warning: casting (double + 0.5)
+  x = (int)(d + 0.5f);
+  // CHECK-MESSAGES: [[@LINE-1]]:12: warning: casting (double + 0.5)
+  x = (int)(ld + 0.5);
+  // CHECK-MESSAGES: [[@LINE-1]]:12: warning: casting (double + 0.5)
+  x = (int)(ld + 0.5f);
+  // CHECK-MESSAGES: [[@LINE-1]]:12: warning: casting (double + 0.5)
+  x = (int)(f + 0.5);
+  // CHECK-MESSAGES: [[@LINE-1]]:12: warning: casting (double + 0.5)
+  x = (int)(f + 0.5f);
+  // CHECK-MESSAGES: [[@LINE-1]]:12: warning: casting (double + 0.5)
+  x = (int)(0.5 + d);
+  // CHECK-MESSAGES: [[@LINE-1]]:12: warning: casting (double + 0.5)
+  x = (int)(0.5f + d);
+  // CHECK-MESSAGES: [[@LINE-1]]:12: warning: casting (double + 0.5)
+  x = (int)(0.5 + ld);
+  // CHECK-MESSAGES: [[@LINE-1]]:12: warning: casting (double + 0.5)
+  x = (int)(0.5f + ld);
+  // CHECK-MESSAGES: [[@LINE-1]]:12: warning: casting (double + 0.5)
+  x = (int)(0.5 + f);
+  // CHECK-MESSAGES: [[@LINE-1]]:12: warning: casting (double + 0.5)
+  x = (int)(0.5f + f);
+  // CHECK-MESSAGES: [[@LINE-1]]:12: warning: casting (double + 0.5)
+  x = static_cast(d + 0.5);
+  // CHECK-MESSAGES: [[@LINE-1]]:24: warning: casting (double + 0.5)
+  x = static_cast(d + 0.5f);
+  // CHECK-MESSAGES: [[@LINE-1]]:24: warning: casting (double + 0.5)
+  x = static_cast(ld + 0.5);
+  // CHECK-MESSAGES: [[@LINE-1]]:24: warning: casting (double + 0.5)
+  x = static_cast(ld + 0.5f);
+  // CHECK-MESSAGES: [[@LINE-1]]:24: warning: casting (double + 0.5)
+  x = static_cast(f + 0.5);
+  // CHECK-MESSAGES: [[@LINE-1]]:24: warning: casting (double + 0.5)
+  x = static_cast(f + 0.5f);
+  // CHECK-MESSAGES: [[@LINE-1]]:24: warning: casting (double + 0.5)
+  x = static_cast(0.5 + d);
+  // CHECK-MESSAGES: [[@LINE-1]]:24: warning: casting (double + 0.5)
+  x = static_cast(0.5f + d);
+  // CHECK-MESSAGES: [[@LINE-1]]:24: warning: casting (double + 0.5)
+  x = static_cast(0.5 + ld);
+  // CHECK-MESSAGES: [[@LINE-1]]:24: warning: casting (double + 0.5)
+  x = static_cast(0.5f + ld);
+  // CHECK-MESSAGES: [[@LINE-1]]:24: warning: casting (double + 0.5)
+  x = static_cast(0.5 + f);
+  // CHECK-MESSAGES: [[@LINE-1]]:24: warning: casting (double + 0.5)
+  x = static_cast(0.5f + f);
+  // CHECK-MESSAGES: [[@LINE-1]]:24: warning: casting (double + 0.5)
+
+  // Don't warn if constant is not 0.5.
+  x = (int)(d + 0.6);
+  x = (int)(0.6 + d);
+
+  // Don't warn if binary operator is not directly beneath cast.
+  x = (int)(1 + (0.5 + f));
+}
Index: docs/clang-tidy/checks/misc-incorrect-roundings.rst
===
--- /dev/null
+++ docs/clang-tidy/checks/misc-incorrect-roundings.rst
@@ -0,0 +1,12 @@
+misc-incorrect-roundings
+
+
+Checks the usage of patterns known to produce incorrect rounding.
+Programmers often use
+  (int)(double_expression + 0.5)
+to round the double expression to an integer. The problem with this:
+
+1. It is unnecessarily slow.
+2. It is incorrect. The number 0.49975 (smallest representable float
+   number below 0.5) rounds to 1.0. Even worse behavior for negative
+   numbers where both -0.5f and -1.4f both round to 0.0.

[clang-tools-extra] r260084 - [clang-tidy] Move incorrect-roundings to upstream.

[Haojian Wu via cfe-commits]

Author: hokein
Date: Mon Feb  8 04:16:13 2016
New Revision: 260084

URL: http://llvm.org/viewvc/llvm-project?rev=260084=rev
Log:
[clang-tidy] Move incorrect-roundings to upstream.

Summary: This is originally implemented by Jacques Pienaar.

Reviewers: alexfh

Subscribers: cfe-commits, jpienaar

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

Added:
clang-tools-extra/trunk/clang-tidy/misc/IncorrectRoundings.cpp
clang-tools-extra/trunk/clang-tidy/misc/IncorrectRoundings.h
clang-tools-extra/trunk/docs/clang-tidy/checks/misc-incorrect-roundings.rst
clang-tools-extra/trunk/test/clang-tidy/misc-incorrect-roundings.cpp
Modified:
clang-tools-extra/trunk/clang-tidy/misc/CMakeLists.txt
clang-tools-extra/trunk/clang-tidy/misc/MiscTidyModule.cpp
clang-tools-extra/trunk/docs/clang-tidy/checks/list.rst

Modified: clang-tools-extra/trunk/clang-tidy/misc/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/misc/CMakeLists.txt?rev=260084=260083=260084=diff
==
--- clang-tools-extra/trunk/clang-tidy/misc/CMakeLists.txt (original)
+++ clang-tools-extra/trunk/clang-tidy/misc/CMakeLists.txt Mon Feb  8 04:16:13 
2016
@@ -7,11 +7,12 @@ add_clang_library(clangTidyMiscModule
   BoolPointerImplicitConversionCheck.cpp
   DefinitionsInHeadersCheck.cpp
   InaccurateEraseCheck.cpp
+  IncorrectRoundings.cpp
   InefficientAlgorithmCheck.cpp
   MacroParenthesesCheck.cpp
   MacroRepeatedSideEffectsCheck.cpp
   MiscTidyModule.cpp
-  MoveConstantArgumentCheck.cpp 
+  MoveConstantArgumentCheck.cpp
   MoveConstructorInitCheck.cpp
   NewDeleteOverloadsCheck.cpp
   NoexceptMoveConstructorCheck.cpp

Added: clang-tools-extra/trunk/clang-tidy/misc/IncorrectRoundings.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/misc/IncorrectRoundings.cpp?rev=260084=auto
==
--- clang-tools-extra/trunk/clang-tidy/misc/IncorrectRoundings.cpp (added)
+++ clang-tools-extra/trunk/clang-tidy/misc/IncorrectRoundings.cpp Mon Feb  8 
04:16:13 2016
@@ -0,0 +1,74 @@
+//===--- IncorrectRoundings.cpp - clang-tidy 
--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "IncorrectRoundings.h"
+#include "clang/AST/DeclBase.h"
+#include "clang/AST/Type.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/ASTMatchers/ASTMatchers.h"
+#include "clang/Lex/Lexer.h"
+
+namespace clang {
+namespace ast_matchers {
+AST_MATCHER(FloatingLiteral, floatHalf) {
+  const auto  = Node.getValue();
+  if ((()) == ::APFloat::IEEEsingle)
+return literal.convertToFloat() == 0.5f;
+  if ((()) == ::APFloat::IEEEdouble)
+return literal.convertToDouble() == 0.5;
+  return false;
+}
+
+// TODO(hokein): Moving it to ASTMatchers.h
+AST_MATCHER(BuiltinType, isFloatingPoint) {
+  return Node.isFloatingPoint();
+}
+} // namespace ast_matchers
+} // namespace clang
+
+using namespace clang::ast_matchers;
+
+namespace clang {
+namespace tidy {
+void IncorrectRoundings::registerMatchers(MatchFinder *MatchFinder) {
+  // Match a floating literal with value 0.5.
+  auto FloatHalf = floatLiteral(floatHalf());
+
+  // Match a floating point expression.
+  auto FloatType = expr(hasType(builtinType(isFloatingPoint(;
+
+  // Match a floating literal of 0.5 or a floating literal of 0.5 implicitly.
+  // cast to floating type.
+  auto FloatOrCastHalf =
+  anyOf(FloatHalf, implicitCastExpr(FloatType, has(FloatHalf)));
+
+  // Match if either the LHS or RHS is a floating literal of 0.5 or a floating
+  // literal of 0.5 and the other is of type double or vice versa.
+  auto OneSideHalf = anyOf(allOf(hasLHS(FloatOrCastHalf), hasRHS(FloatType)),
+   allOf(hasRHS(FloatOrCastHalf), hasLHS(FloatType)));
+
+  // Find expressions of cast to int of the sum of a floating point expression
+  // and 0.5.
+  MatchFinder->addMatcher(
+  implicitCastExpr(
+  hasImplicitDestinationType(isInteger()),
+  ignoringParenCasts(binaryOperator(hasOperatorName("+"), 
OneSideHalf)))
+  .bind("CastExpr"),
+  this);
+}
+
+void IncorrectRoundings::check(const MatchFinder::MatchResult ) {
+  const auto *CastExpr = Result.Nodes.getStmtAs("CastExpr");
+  diag(CastExpr->getLocStart(),
+   "casting (double + 0.5) to integer leads to incorrect rounding; "
+   "consider using lround (#include ) instead");
+}
+
+} // namespace tidy
+} // namespace clang

Added: clang-tools-extra/trunk/clang-tidy/misc/IncorrectRoundings.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/misc/IncorrectRoundings.h?rev=260084=auto

Re: [PATCH] D16764: [clang-tidy] Move incorrect-roundings to upstream.

[Haojian Wu via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL260084: [clang-tidy] Move incorrect-roundings to upstream. 
(authored by hokein).

Changed prior to commit:
  http://reviews.llvm.org/D16764?vs=47167=47169#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D16764

Files:
  clang-tools-extra/trunk/clang-tidy/misc/CMakeLists.txt
  clang-tools-extra/trunk/clang-tidy/misc/IncorrectRoundings.cpp
  clang-tools-extra/trunk/clang-tidy/misc/IncorrectRoundings.h
  clang-tools-extra/trunk/clang-tidy/misc/MiscTidyModule.cpp
  clang-tools-extra/trunk/docs/clang-tidy/checks/list.rst
  clang-tools-extra/trunk/docs/clang-tidy/checks/misc-incorrect-roundings.rst
  clang-tools-extra/trunk/test/clang-tidy/misc-incorrect-roundings.cpp

Index: clang-tools-extra/trunk/clang-tidy/misc/IncorrectRoundings.h
===
--- clang-tools-extra/trunk/clang-tidy/misc/IncorrectRoundings.h
+++ clang-tools-extra/trunk/clang-tidy/misc/IncorrectRoundings.h
@@ -0,0 +1,38 @@
+//===--- IncorrectRoundings.h - clang-tidy --*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_MISC_INCORRECTROUNDINGS_H_
+#define LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_MISC_INCORRECTROUNDINGS_H_
+
+#include "../ClangTidy.h"
+
+namespace clang {
+namespace tidy {
+
+/// \brief Checks the usage of patterns known to produce incorrect rounding.
+/// Programmers often use
+///   (int)(double_expression + 0.5)
+/// to round the double expression to an integer. The problem with this
+///  1. It is unnecessarily slow.
+///  2. It is incorrect. The number 0.49975 (smallest representable float
+/// number below 0.5) rounds to 1.0. Even worse behavior for negative
+/// numbers where both -0.5f and -1.4f both round to 0.0.
+class IncorrectRoundings : public ClangTidyCheck {
+public:
+  IncorrectRoundings(StringRef Name, ClangTidyContext *Context)
+  : ClangTidyCheck(Name, Context) {}
+  void registerMatchers(ast_matchers::MatchFinder *Finder) override;
+  void check(const ast_matchers::MatchFinder::MatchResult ) override;
+};
+
+} // namespace tidy
+} // namespace clang
+
+
+#endif  // LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_MISC_INCORRECTROUNDINGS_H_
Index: clang-tools-extra/trunk/clang-tidy/misc/CMakeLists.txt
===
--- clang-tools-extra/trunk/clang-tidy/misc/CMakeLists.txt
+++ clang-tools-extra/trunk/clang-tidy/misc/CMakeLists.txt
@@ -7,11 +7,12 @@
   BoolPointerImplicitConversionCheck.cpp
   DefinitionsInHeadersCheck.cpp
   InaccurateEraseCheck.cpp
+  IncorrectRoundings.cpp
   InefficientAlgorithmCheck.cpp
   MacroParenthesesCheck.cpp
   MacroRepeatedSideEffectsCheck.cpp
   MiscTidyModule.cpp
-  MoveConstantArgumentCheck.cpp 
+  MoveConstantArgumentCheck.cpp
   MoveConstructorInitCheck.cpp
   NewDeleteOverloadsCheck.cpp
   NoexceptMoveConstructorCheck.cpp
Index: clang-tools-extra/trunk/clang-tidy/misc/MiscTidyModule.cpp
===
--- clang-tools-extra/trunk/clang-tidy/misc/MiscTidyModule.cpp
+++ clang-tools-extra/trunk/clang-tidy/misc/MiscTidyModule.cpp
@@ -16,6 +16,7 @@
 #include "BoolPointerImplicitConversionCheck.h"
 #include "DefinitionsInHeadersCheck.h"
 #include "InaccurateEraseCheck.h"
+#include "IncorrectRoundings.h"
 #include "InefficientAlgorithmCheck.h"
 #include "MacroParenthesesCheck.h"
 #include "MacroRepeatedSideEffectsCheck.h"
@@ -54,6 +55,8 @@
 "misc-definitions-in-headers");
 CheckFactories.registerCheck(
 "misc-inaccurate-erase");
+CheckFactories.registerCheck(
+"misc-incorrect-roundings");
 CheckFactories.registerCheck(
 "misc-inefficient-algorithm");
 CheckFactories.registerCheck(
Index: clang-tools-extra/trunk/clang-tidy/misc/IncorrectRoundings.cpp
===
--- clang-tools-extra/trunk/clang-tidy/misc/IncorrectRoundings.cpp
+++ clang-tools-extra/trunk/clang-tidy/misc/IncorrectRoundings.cpp
@@ -0,0 +1,74 @@
+//===--- IncorrectRoundings.cpp - clang-tidy --===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "IncorrectRoundings.h"
+#include "clang/AST/DeclBase.h"
+#include "clang/AST/Type.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/ASTMatchers/ASTMatchers.h"
+#include "clang/Lex/Lexer.h"
+
+namespace clang {
+namespace ast_matchers {
+AST_MATCHER(FloatingLiteral, 

Re: [PATCH]: git-clang-format

[Manuel Klimek via cfe-commits]

I believe you forgot to add cfe-commits as subscriber on the patch.

On Sun, Feb 7, 2016 at 12:51 PM Alexander Shukaev <
cl...@alexander.shukaev.name> wrote:

> On 12/14/2015 10:03 PM, Alexander Shukaev wrote:
> > On 12/11/2015 04:40 PM, Daniel Jasper wrote:
> >> Please submit patches to clang-format to reviews.llvm.org. Also, any
> >> change
> >> no matter how easy it is to deduce from the code itself deserves a
> proper
> >> change description :-). Bullet points are fine.
> >
> > Thanks for the quick reply.  I've submitted the patch for review [1] as
> > requested.  Just let me know if anything else is needed.
> >
> > Regards,
> > Alexander
> >
> > [1] http://reviews.llvm.org/D15465
>
> Hello,
>
> I am wondering whether I can expect this patch to be reviewed and
> included into the upcoming 3.8 release?  I didn't receive any feedback
> ever since it was submitted.  Apologies, I don't want to annoy anybody
> but seeing no reaction at all within a couple months feels rude.
>
> Kind regards,
> Alexander
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r260080 - clang-format: Fix weird alignment when not aligning after brackets.

[Daniel Jasper via cfe-commits]

Author: djasper
Date: Mon Feb  8 03:52:54 2016
New Revision: 260080

URL: http://llvm.org/viewvc/llvm-project?rev=260080=rev
Log:
clang-format: Fix weird alignment when not aligning after brackets.

Before:
  (, //
  ccc(a, //
   b));

After:
  (, //
  ccc(a, //
  b));

This fixes llvm.org/PR24905.

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

Modified: cfe/trunk/lib/Format/ContinuationIndenter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/ContinuationIndenter.cpp?rev=260080=260079=260080=diff
==
--- cfe/trunk/lib/Format/ContinuationIndenter.cpp (original)
+++ cfe/trunk/lib/Format/ContinuationIndenter.cpp Mon Feb  8 03:52:54 2016
@@ -863,7 +863,8 @@ void ContinuationIndenter::moveStatePast
 //   ParameterToInnerFunction));
 if (*I > prec::Unknown)
   NewParenState.LastSpace = std::max(NewParenState.LastSpace, 
State.Column);
-if (*I != prec::Conditional && !Current.is(TT_UnaryOperator))
+if (*I != prec::Conditional && !Current.is(TT_UnaryOperator) &&
+Style.AlignAfterOpenBracket != FormatStyle::BAS_DontAlign)
   NewParenState.StartOfFunctionCall = State.Column;
 
 // Always indent conditional expressions. Never indent expression where

Modified: cfe/trunk/unittests/Format/FormatTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Format/FormatTest.cpp?rev=260080=260079=260080=diff
==
--- cfe/trunk/unittests/Format/FormatTest.cpp (original)
+++ cfe/trunk/unittests/Format/FormatTest.cpp Mon Feb  8 03:52:54 2016
@@ -4434,6 +4434,11 @@ TEST_F(FormatTest, AlignsAfterOpenBracke
   "a, a));",
   Style);
 
+  verifyFormat("(, //\n"
+   "ccc(a, //\n"
+   "b));",
+   Style);
+
   Style.AlignAfterOpenBracket = FormatStyle::BAS_AlwaysBreak;
   Style.BinPackArguments = false;
   Style.BinPackParameters = false;


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

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

[Oliver Stannard via cfe-commits]

olista01 added a comment.

Ping?


http://reviews.llvm.org/D15040



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

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

[Felix Berger via cfe-commits]

flx added inline comments.


Comment at: clang-tidy/misc/UninitializedFieldCheck.cpp:178
@@ +177,3 @@
+
+  SmallPtrSet FieldsToInit;
+  fieldsRequiringInit(MemberFields, FieldsToInit);

alexfh wrote:
> What about this? (relates to line 184 now)
My comment on this was not submitted, just in case. Here it is again:

I think he idea is to return immediately if we're delegating to another 
constructor here. Am I misunderstanding the API call?

The important part is that we return in that case.


Comment at: clang-tidy/misc/UninitializedFieldCheck.cpp:124
@@ +123,3 @@
+  std::vector OrderedFields;
+  OrderedFields.push_back({LastWrittenNonMemberInit, nullptr, {}});
+

alexfh wrote:
> `.emplace_back(...)`?
Gave a compile error. Probably because there is no explicit constructor with 
the 3 arguments.


Comment at: clang-tidy/misc/UninitializedFieldCheck.cpp:177
@@ +176,3 @@
+  for (CXXCtorInitializer *Init : Ctor->inits()) {
+if (Init->isDelegatingInitializer())
+  return;

alexfh wrote:
> I think, this is superfluous. `isMemberInitializer()` should be enough.
I think he idea is to return immediately if we're delegating to another 
constructor here. Is this covered through some other check?


Comment at: clang-tidy/misc/UninitializedFieldCheck.cpp:199
@@ +198,3 @@
+
+for (const auto *Field : FieldsToInit)
+  Builder << FixItHint::CreateInsertion(

alexfh wrote:
> nit: We don't use braces only for single-line `if/for` bodies. Same below.
Done. This seems really subtle though when it depends on line length instead of 
single statement inside of loop.


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

alexfh wrote:
> As usual: tests with templates and macros, please ;)
Thanks for the reminder. Added early return for code inside of macros. Added 
template test which revealed I had to suppress the check inside of instantiated 
constructors.


http://reviews.llvm.org/D16517



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

r260189 - Remove 'llvm::TrailingObjects::operator delete', clang side.

[Richard Smith via cfe-commits]

Author: rsmith
Date: Mon Feb  8 19:57:24 2016
New Revision: 260189

URL: http://llvm.org/viewvc/llvm-project?rev=260189=rev
Log:
Remove 'llvm::TrailingObjects::operator delete', clang side.

Modified:
cfe/trunk/include/clang/CodeGen/CGFunctionInfo.h

Modified: cfe/trunk/include/clang/CodeGen/CGFunctionInfo.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/CodeGen/CGFunctionInfo.h?rev=260189=260188=260189=diff
==
--- cfe/trunk/include/clang/CodeGen/CGFunctionInfo.h (original)
+++ cfe/trunk/include/clang/CodeGen/CGFunctionInfo.h Mon Feb  8 19:57:24 2016
@@ -402,7 +402,7 @@ public:
 CanQualType resultType,
 ArrayRef argTypes,
 RequiredArgs required);
-  void operator delete(void *p) { TrailingObjects::operator delete(p); }
+  void operator delete(void *p) { ::operator delete(p); }
 
   typedef const ArgInfo *const_arg_iterator;
   typedef ArgInfo *arg_iterator;


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

[libcxx] r260202 - Minor updates to failing tests. NFC

[Marshall Clow via cfe-commits]

Author: marshall
Date: Tue Feb  9 00:38:56 2016
New Revision: 260202

URL: http://llvm.org/viewvc/llvm-project?rev=260202=rev
Log:
Minor updates to failing tests. NFC

Modified:

libcxx/trunk/test/std/input.output/iostream.format/quoted.manip/quoted_char.fail.cpp

libcxx/trunk/test/std/input.output/iostream.format/quoted.manip/quoted_traits.fail.cpp

Modified: 
libcxx/trunk/test/std/input.output/iostream.format/quoted.manip/quoted_char.fail.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/input.output/iostream.format/quoted.manip/quoted_char.fail.cpp?rev=260202=260201=260202=diff
==
--- 
libcxx/trunk/test/std/input.output/iostream.format/quoted.manip/quoted_char.fail.cpp
 (original)
+++ 
libcxx/trunk/test/std/input.output/iostream.format/quoted.manip/quoted_char.fail.cpp
 Tue Feb  9 00:38:56 2016
@@ -16,7 +16,11 @@
 #include 
 #include 
 
-#if _LIBCPP_STD_VER > 11
+#include "test_macros.h"
+
+// Test that mismatches between strings and wides streams are diagnosed
+
+#if TEST_STD_VER > 11
 
 void round_trip ( const char *p ) {
 std::wstringstream ss;

Modified: 
libcxx/trunk/test/std/input.output/iostream.format/quoted.manip/quoted_traits.fail.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/input.output/iostream.format/quoted.manip/quoted_traits.fail.cpp?rev=260202=260201=260202=diff
==
--- 
libcxx/trunk/test/std/input.output/iostream.format/quoted.manip/quoted_traits.fail.cpp
 (original)
+++ 
libcxx/trunk/test/std/input.output/iostream.format/quoted.manip/quoted_traits.fail.cpp
 Tue Feb  9 00:38:56 2016
@@ -16,7 +16,11 @@
 #include 
 #include 
 
-#if _LIBCPP_STD_VER > 11
+#include "test_macros.h"
+
+#if TEST_STD_VER > 11
+
+// Test that mismatches in the traits between the quoted object and the 
dest string are diagnosed.
 
 template 
 struct test_traits


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

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

[Felix Berger via cfe-commits]

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

Renamed the check to: cppcoreguidelines-pro-type-member-init, note the extra 
dash between member and init to be consistent with the camelcase notation of 
the class name ProTypeMemberInitCheck.


http://reviews.llvm.org/D16517

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

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

Re: r260048 - [Frontend] Make the memory management of FrontendAction pointers explicit by using unique_ptr.

[Argyrios Kyrtzidis via cfe-commits]

Interesting, it seems that libTooling is decoupled from the particular API 
changes in r260048.

> On Feb 8, 2016, at 5:39 PM, David Blaikie  wrote:
> 
> FWIW, I tried to do something like this, perhaps with some other 
> improvements, a few years ago. Not sure if things have changed for the better 
> since then, but maybe those old patches may provide some insight/other 
> improvements/options:
> 
> http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20140915/115122.html 
> 
> http://reviews.llvm.org/D4313 
> http://reviews.llvm.org/D4312 
> 
> On Sun, Feb 7, 2016 at 11:28 AM, Argyrios Kyrtzidis via cfe-commits 
> > wrote:
> Author: akirtzidis
> Date: Sun Feb  7 13:28:36 2016
> New Revision: 260048
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=260048=rev 
> 
> Log:
> [Frontend] Make the memory management of FrontendAction pointers explicit by 
> using unique_ptr.
> 
> Modified:
> cfe/trunk/include/clang/ARCMigrate/ARCMTActions.h
> cfe/trunk/include/clang/Frontend/FrontendAction.h
> cfe/trunk/include/clang/Frontend/FrontendActions.h
> cfe/trunk/include/clang/Rewrite/Frontend/FrontendActions.h
> cfe/trunk/lib/ARCMigrate/ARCMTActions.cpp
> cfe/trunk/lib/ARCMigrate/ObjCMT.cpp
> cfe/trunk/lib/Frontend/ASTMerge.cpp
> cfe/trunk/lib/Frontend/FrontendAction.cpp
> cfe/trunk/lib/FrontendTool/ExecuteCompilerInvocation.cpp
> 
> Modified: cfe/trunk/include/clang/ARCMigrate/ARCMTActions.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/ARCMigrate/ARCMTActions.h?rev=260048=260047=260048=diff
>  
> 
> ==
> --- cfe/trunk/include/clang/ARCMigrate/ARCMTActions.h (original)
> +++ cfe/trunk/include/clang/ARCMigrate/ARCMTActions.h Sun Feb  7 13:28:36 2016
> @@ -22,7 +22,7 @@ protected:
>bool BeginInvocation(CompilerInstance ) override;
> 
>  public:
> -  CheckAction(FrontendAction *WrappedAction);
> +  CheckAction(std::unique_ptr WrappedAction);
>  };
> 
>  class ModifyAction : public WrapperFrontendAction {
> @@ -30,7 +30,7 @@ protected:
>bool BeginInvocation(CompilerInstance ) override;
> 
>  public:
> -  ModifyAction(FrontendAction *WrappedAction);
> +  ModifyAction(std::unique_ptr WrappedAction);
>  };
> 
>  class MigrateSourceAction : public ASTFrontendAction {
> @@ -49,7 +49,8 @@ protected:
>bool BeginInvocation(CompilerInstance ) override;
> 
>  public:
> -  MigrateAction(FrontendAction *WrappedAction, StringRef migrateDir,
> +  MigrateAction(std::unique_ptr WrappedAction,
> +StringRef migrateDir,
>  StringRef plistOut,
>  bool emitPremigrationARCErrors);
>  };
> @@ -61,8 +62,8 @@ class ObjCMigrateAction : public Wrapper
>FileRemapper Remapper;
>CompilerInstance *CompInst;
>  public:
> -  ObjCMigrateAction(FrontendAction *WrappedAction, StringRef migrateDir,
> -unsigned migrateAction);
> +  ObjCMigrateAction(std::unique_ptr WrappedAction,
> +StringRef migrateDir, unsigned migrateAction);
> 
>  protected:
>std::unique_ptr CreateASTConsumer(CompilerInstance ,
> 
> Modified: cfe/trunk/include/clang/Frontend/FrontendAction.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/FrontendAction.h?rev=260048=260047=260048=diff
>  
> 
> ==
> --- cfe/trunk/include/clang/Frontend/FrontendAction.h (original)
> +++ cfe/trunk/include/clang/Frontend/FrontendAction.h Sun Feb  7 13:28:36 2016
> @@ -283,7 +283,7 @@ protected:
>  public:
>/// Construct a WrapperFrontendAction from an existing action, taking
>/// ownership of it.
> -  WrapperFrontendAction(FrontendAction *WrappedAction);
> +  WrapperFrontendAction(std::unique_ptr WrappedAction);
> 
>bool usesPreprocessorOnly() const override;
>TranslationUnitKind getTranslationUnitKind() override;
> 
> Modified: cfe/trunk/include/clang/Frontend/FrontendActions.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/FrontendActions.h?rev=260048=260047=260048=diff
>  
> 
> ==
> --- cfe/trunk/include/clang/Frontend/FrontendActions.h (original)
> +++ cfe/trunk/include/clang/Frontend/FrontendActions.h Sun Feb  7 

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

[Alexander Riccio via cfe-commits]

ariccio updated this revision to Diff 47289.

http://reviews.llvm.org/D16873

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

Index: llvm/tools/clang/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h
===
--- llvm/tools/clang/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h
+++ llvm/tools/clang/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h
@@ -1180,6 +1180,17 @@
   ///  a specified VarDecl and LocationContext.
   const VarRegion* getVarRegion(const VarDecl *D, const LocationContext *LC);
 
+private:
+  /// Retrieve or create the memory region
+  ///  associated with a VarDecl for a global variable.
+  const MemRegion *getMemSpaceForGlobalVariable(const VarDecl *D);
+
+  /// Retrieve or create the memory region
+  ///  associated with a specified VarDecl and LocationContext.
+  const MemRegion *getMemSpaceForLocalVariable(const VarDecl *D,
+   const StackFrameContext *STC);
+
+public:
   /// getVarRegion - Retrieve or create the memory region associated with
   ///  a specified VarDecl and super region.
   const VarRegion* getVarRegion(const VarDecl *D, const MemRegion *superR);
Index: llvm/tools/clang/lib/StaticAnalyzer/Core/MemRegion.cpp
===
--- llvm/tools/clang/lib/StaticAnalyzer/Core/MemRegion.cpp
+++ llvm/tools/clang/lib/StaticAnalyzer/Core/MemRegion.cpp
@@ -766,34 +766,77 @@
   return (const StackFrameContext *)nullptr;
 }
 
+const MemRegion* MemRegionManager::getMemSpaceForGlobalVariable(const VarDecl *D) {
+  assert(D->hasGlobalStorage());
+  assert(!D->isStaticLocal());
+  // First handle the globals defined in system headers.
+  if (C.getSourceManager().isInSystemHeader(D->getLocation())) {
+// Whitelist the system globals which often DO GET modified, assume the
+// rest are immutable.
+if (D->getName().find("errno") != StringRef::npos)
+  return getGlobalsRegion(MemRegion::GlobalSystemSpaceRegionKind);
+
+return getGlobalsRegion(MemRegion::GlobalImmutableSpaceRegionKind);
+  }
+  // Treat other globals as GlobalInternal unless they are constants.
+  QualType GQT = D->getType();
+  const Type *GT = GQT.getTypePtrOrNull();
+  // TODO: We could walk the complex types here and see if everything is
+  // constified.
+  if (GT && GQT.isConstQualified() && GT->isArithmeticType())
+return getGlobalsRegion(MemRegion::GlobalImmutableSpaceRegionKind);
+
+  return getGlobalsRegion();
+}
+
+const MemRegion*
+MemRegionManager::getMemSpaceForLocalVariable(const VarDecl *D,
+  const StackFrameContext *STC) {
+
+  if (!STC)
+return getUnknownRegion();
+
+  if (D->hasLocalStorage()) {
+return (isa(D) || isa(D)
+   ? static_cast(getStackArgumentsRegion(STC))
+   : static_cast(getStackLocalsRegion(STC)));
+  }
+  assert(D->isStaticLocal());
+  const Decl *STCD = STC->getDecl();
+  if (isa(STCD) || isa(STCD))
+return getGlobalsRegion(MemRegion::StaticGlobalSpaceRegionKind,
+getFunctionCodeRegion(cast(STCD)));
+
+  else if (const BlockDecl *BD = dyn_cast(STCD)) {
+// FIXME: The fallback type here is totally bogus -- though it should
+// never be queried, it will prevent uniquing with the real
+// BlockCodeRegion. Ideally we'd fix the AST so that we always had a
+// signature.
+QualType T;
+if (const TypeSourceInfo *TSI = BD->getSignatureAsWritten())
+  T = TSI->getType();
+if (T.isNull())
+  T = getContext().VoidTy;
+if (!T->getAs())
+  T = getContext().getFunctionNoProtoType(T);
+T = getContext().getBlockPointerType(T);
+
+const BlockCodeRegion *BTR =
+  getBlockCodeRegion(BD, C.getCanonicalType(T),
+ STC->getAnalysisDeclContext());
+return getGlobalsRegion(MemRegion::StaticGlobalSpaceRegionKind,
+BTR);
+  }
+  return getGlobalsRegion();
+}
+
 const VarRegion* MemRegionManager::getVarRegion(const VarDecl *D,
 const LocationContext *LC) {
   const MemRegion *sReg = nullptr;
 
   if (D->hasGlobalStorage() && !D->isStaticLocal()) {
+sReg = getMemSpaceForGlobalVariable(D);
 
-// First handle the globals defined in system headers.
-if (C.getSourceManager().isInSystemHeader(D->getLocation())) {
-  // Whitelist the system globals which often DO GET modified, assume the
-  // rest are immutable.
-  if (D->getName().find("errno") != StringRef::npos)
-sReg = getGlobalsRegion(MemRegion::GlobalSystemSpaceRegionKind);
-  else
-sReg = getGlobalsRegion(MemRegion::GlobalImmutableSpaceRegionKind);
-
-// Treat other globals as GlobalInternal unless they are constants.
-} else {
-  QualType GQT = 

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

[Alexey Bataev via cfe-commits]

ABataev added a comment.

Ping


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.

Ping


http://reviews.llvm.org/D11182



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

Re: [PATCH] D16947: [PGO] assignment operator does not get profile data

[David Blaikie via cfe-commits]

On Mon, Feb 8, 2016 at 9:00 PM, Xinliang David Li 
wrote:

> On Mon, Feb 8, 2016 at 8:46 PM, David Blaikie  wrote:
> >
> > On Mon, Feb 8, 2016 at 7:39 PM, Xinliang David Li 
> > wrote:
> >>
> >> I took a look at the problem. The implicitly defaulted operators
> >> should not be instrumented as specified -- I actually I just added the
> >> new test case for that (checking profile counter not generated) right
> >> after my previous reply and it still passes with this patch. The
> >> reason is that those operators have 'implicit' bit set, and profile
> >> instrumentation in FE is implemented in two stages: 1) counter
> >> assignment; 2) actual transformation.  For methods with implicit bit
> >> set, step 1) is skipped as designed, so step 2) simply becomes a
> >> no-op.
> >>
> >> In short, the test case still needs explicit '=default', and the
> >> implicit case is covered elsewhere.
> >
> >
> > OK, thanks for the explanation!
> >
> > Why is that the case, though - why would an implicitly default function
> be
> > any different from a profile (& profile-guided-optimization) perspective
> > from an explicitly defaulted one?
>
> There are two factors to consider -- PGO and coverage testing.
> Implicitly declared functions are usually small/single BB so
> instrumenting them does not bring too much benefit (they will be
> inlined most of the cases any way) while increasing instrumentation
> overhead. They are not needed for coveraging test either (as there are
> no source lines to cover). This is a good tuning heuristic in most
> cases, but can get wrong sometimes (IR based late instrumentation is
> more focused on performance thus not depending on this tuning).
>
> Explicitly defaulted ones are different in the sense that if they are
> not instrumented, the coverage result will be wrong.
>

wrong in what way? Both functions (explicitly or implicitly defaulted) will
be emitted, with line tables (looks like the = defaulted one is attributed
to the line where the = default was written, and the implicitly defaulted
one is attributed to wherever the class name is written)

- David


>
> thanks,
>
> David
>
> >
> >>
> >>
> >> thanks,
> >>
> >> David
> >>
> >> On Mon, Feb 8, 2016 at 5:23 PM, David Blaikie 
> wrote:
> >> >
> >> >
> >> > On Mon, Feb 8, 2016 at 5:05 PM, Xinliang David Li  >
> >> > wrote:
> >> >>
> >> >> ha! somehow I kept thinking you are referring to implicit declared
> >> >> ctors.
> >> >
> >> >
> >> > Ah, glad we figured out the disconnect - thanks for bearing with me!
> >> >
> >> >>
> >> >>
> >> >> From your test case, it is seems that the implicit copy/move op is
> >> >> also broken and is fixed by this patch too. That means  a missing
> test
> >> >> case to me.  Will update the case when verified.
> >> >
> >> >
> >> > Again, this is a case where I'd probably just simplify the test, as I
> >> > asked
> >> > earlier in the thread (I asked if it mattered if the op was explicitly
> >> > or
> >> > implicitly defaulted (& your response: "> Is the fix/codepath
> >> > specifically
> >> > about explicitly defaulted ops?
> >> >
> >> > yes -- explicitly defaulted. There are some test coverage already for
> >> > implicitly declared ctors (but not assignment op -- probably worth
> >> > adding some testing too).")
> >> >
> >> > So I'd just simplify the test by removing the "= default" - I don't
> >> > think
> >> > there's value in testing both the explicit default and implicit
> default
> >> > if
> >> > it's just the default-y-ness that's relevant here. Otherwise we could
> >> > end up
> >> > testing all sorts of ways of writing/interacting with dtors which
> >> > wouldn't
> >> > be relevant to the code/fix/etc.
> >> >
> >> > This seems like the obvious test for the behavior:
> >> >
> >> > struct foo {
> >> >   // non-trivial ops
> >> >   foo =(const foo&);
> >> >   foo =(foo&&);
> >> > };
> >> >
> >> > struct bar {
> >> >   foo f; // or derive bar from foo, but I think the member version is
> >> > simpler
> >> > };
> >> >
> >> > // force emission of bar's implicit special members, one way or
> another:
> >> > bar &(bar::*x)(const bar&) = ::operator=;
> >> > bar &(bar::*x)(bar&&) = ::operator=;
> >> >
> >> > (or just call them as you had in your test case - but that produces
> more
> >> > code, etc in the module, extra functions/profile counters/etc)
> >> >
> >> > - Dave
> >> >
> >> >>
> >> >>
> >> >> thanks,
> >> >>
> >> >> David
> >> >>
> >> >>
> >> >> On Mon, Feb 8, 2016 at 4:58 PM, David Blaikie 
> >> >> wrote:
> >> >> >
> >> >> >
> >> >> > On Mon, Feb 8, 2016 at 4:31 PM, Xinliang David Li
> >> >> > 
> >> >> > wrote:
> >> >> >>
> >> >> >> On Mon, Feb 8, 2016 at 4:05 PM, David Blaikie  >
> >> >> >> wrote:
> >> >> >> >
> >> >> >> >
> >> >> >> > On Mon, Feb 8, 2016 at 3:58 PM, Xinliang David Li
> >> >> >> > 
> >> >> >> > wrote:
> >> 

[PATCH] D17019: [OpenMP] Code generation for teams - kernel launching

[Samuel Antao via cfe-commits]

sfantao created this revision.
sfantao added reviewers: ABataev, hfinkel, carlo.bertolli, arpith-jacob, kkwli0.
sfantao added subscribers: fraggamuffin, caomhin, cfe-commits.

This patch implements the launching of a target region in the presence of a 
nested teams region, i.e calls tgt_target_teams with the required arguments 
gathered from the enclosed teams directive.

The actual codegen of the region enclosed by the teams construct will be 
contributed in a separate patch. 

http://reviews.llvm.org/D17019

Files:
  lib/CodeGen/CGOpenMPRuntime.cpp
  lib/CodeGen/CGOpenMPRuntime.h
  lib/CodeGen/CGStmtOpenMP.cpp
  lib/CodeGen/CodeGenFunction.h
  test/OpenMP/teams_codegen.cpp

Index: test/OpenMP/teams_codegen.cpp
===
--- /dev/null
+++ test/OpenMP/teams_codegen.cpp
@@ -0,0 +1,211 @@
+// expected-no-diagnostics
+#ifndef HEADER
+#define HEADER
+// Test host codegen.
+// RUN: %clang_cc1 -DCK1 -verify -fopenmp -x c++ -triple powerpc64le-unknown-unknown -omptargets=powerpc64le-ibm-linux-gnu -emit-llvm %s -o - | FileCheck %s --check-prefix CK1 --check-prefix CK1-64
+// RUN: %clang_cc1 -DCK1 -fopenmp -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -omptargets=powerpc64le-ibm-linux-gnu -emit-pch -o %t %s
+// RUN: %clang_cc1 -DCK1 -fopenmp -x c++ -triple powerpc64le-unknown-unknown -omptargets=powerpc64le-ibm-linux-gnu -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck %s --check-prefix CK1 --check-prefix CK1-64
+// RUN: %clang_cc1 -DCK1 -verify -fopenmp -x c++ -triple i386-unknown-unknown -omptargets=i386-pc-linux-gnu -emit-llvm %s -o - | FileCheck %s --check-prefix CK1 --check-prefix CK1-32
+// RUN: %clang_cc1 -DCK1 -fopenmp -x c++ -std=c++11 -triple i386-unknown-unknown -omptargets=i386-pc-linux-gnu -emit-pch -o %t %s
+// RUN: %clang_cc1 -DCK1 -fopenmp -x c++ -triple i386-unknown-unknown -omptargets=i386-pc-linux-gnu -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck %s --check-prefix CK1 --check-prefix CK1-32
+#ifdef CK1
+
+int Gbla;
+long long Gblb;
+
+// CK1-LABEL: teams_argument_global_local
+int teams_argument_global_local(int a){
+  int comp = 1;
+
+  int la = 23;
+  float lc = 25.0;
+
+  // CK1: call i32 @__tgt_target_teams(i32 -1, i8* @{{[^,]+}}, i32 1, i8** %{{[^,]+}}, i8** %{{[^,]+}}, i{{64|32}}* {{.+}}@{{[^,]+}}, i32 0, i32 0), i32* {{.+}}@{{[^,]+}}, i32 0, i32 0), i32 0, i32 0)
+  // CK1: call void @{{.+}}(i{{64|32}} %{{.+}})
+  #pragma omp target
+  #pragma omp teams
+  {
+++comp;
+  }
+
+  // CK1-DAG: call i32 @__tgt_target_teams(i32 -1, i8* @{{[^,]+}}, i32 2, i8** %{{[^,]+}}, i8** %{{[^,]+}}, i{{64|32}}* {{.+}}@{{[^,]+}}, i32 0, i32 0), i32* {{.+}}@{{[^,]+}}, i32 0, i32 0), i32 [[NT:%[^,]+]], i32 0)
+  // CK1-DAG: [[NT]] = load i32, i32* [[NTA:%[^,]+]],
+  // CK1-64-DAG: [[NTA]] = bitcast i64* [[NTB:%[^,]+]] to i32*
+  // CK1-64-DAG: store i64 [[NTC:%[^,]+]], i64* [[NTB]],
+  // CK1-64-DAG: [[NTC]] = load i64, i64* [[NTD:%[^,]+]],
+  // CK1-64-DAG: [[NTE:%[^,]+]] = bitcast i64* [[NTD]] to i32*
+  // CK1-64-DAG: store i32 [[NTF:%[^,]+]], i32* [[NTE]],
+  // CK1-64-DAG: [[NTF]] = load i32, i32* {{%[^,]+}},
+
+
+  // CK1: call void @{{.+}}(i{{64|32}} %{{.+}})
+  #pragma omp target
+  #pragma omp teams num_teams(la)
+  {
+++comp;
+  }
+
+  // CK1-DAG: call i32 @__tgt_target_teams(i32 -1, i8* @{{[^,]+}}, i32 2, i8** %{{[^,]+}}, i8** %{{[^,]+}}, i{{64|32}}* {{.+}}@{{[^,]+}}, i32 0, i32 0), i32* {{.+}}@{{[^,]+}}, i32 0, i32 0), i32 0, i32 [[NT:%[^,]+]])
+  // CK1-DAG: [[NT]] = load i32, i32* [[NTA:%[^,]+]],
+  // CK1-64-DAG: [[NTA]] = bitcast i64* [[NTB:%[^,]+]] to i32*
+  // CK1-64-DAG: store i64 [[NTC:%[^,]+]], i64* [[NTB]],
+  // CK1-64-DAG: [[NTC]] = load i64, i64* [[NTD:%[^,]+]],
+  // CK1-64-DAG: [[NTE:%[^,]+]] = bitcast i64* [[NTD]] to i32*
+  // CK1-64-DAG: store i32 [[NTF:%[^,]+]], i32* [[NTE]],
+  // CK1-64-DAG: [[NTF]] = load i32, i32* {{%[^,]+}},
+  // CK1: call void @{{.+}}(i{{64|32}} %{{.+}})
+  #pragma omp target
+  #pragma omp teams thread_limit(la)
+  {
+++comp;
+  }
+
+  // CK1-DAG: call i32 @__tgt_target_teams(i32 -1, i8* @{{[^,]+}}, i32 5, i8** %{{[^,]+}}, i8** %{{[^,]+}}, i{{64|32}}* {{.+}}@{{[^,]+}}, i32 0, i32 0), i32* {{.+}}@{{[^,]+}}, i32 0, i32 0), i32 [[NT:%[^,]+]], i32 [[TL:%[^,]+]])
+
+  // CK1-DAG: [[NT]] = add nsw i32 [[NTA:%[^,]+]], [[NTB:%[^,]+]]
+  // CK1-64-DAG: [[NTB]] = load i32, i32* %c{{.+}},
+  // CK1-64-DAG: [[NTA]] = load i32, i32* %c{{.+}},
+
+  // CK1-DAG: [[TL]] = trunc i64 [[TLA:%[^,]+]] to i32
+  // CK1-DAG: [[TLA]] = add nsw i64 [[TLB:%[^,]+]], [[TLC:%[^,]+]]
+  // CK1-DAG: [[TLC]] = fptosi float [[TLD:%[^,]+]] to i64
+  // CK1-DAG: [[TLD]] = load float, float* %{{.+}},
+  // CK1-DAG: [[TLB]] = load i64, i64* %{{.+}},
+
+  // CK1: call void @{{.+}}(i{{.+}} {{.+}}, i{{.+}} {{.+}}, i{{.+}} {{.+}}, i{{.+}} {{.+}}, i{{.+}} {{.+}})
+  #pragma omp target
+  #pragma omp teams num_teams(Gbla+a) thread_limit(Gblb+(long long)lc)
+  {
+++comp;
+  }
+
+  

r260203 - [CMake] Updating caches README with explanations of useful cache files.

[Chris Bieneman via cfe-commits]

Author: cbieneman
Date: Tue Feb  9 00:49:08 2016
New Revision: 260203

URL: http://llvm.org/viewvc/llvm-project?rev=260203=rev
Log:
[CMake] Updating caches README with explanations of useful cache files.

This is in response to silvas' post-commit suggestion.

Modified:
cfe/trunk/cmake/caches/README.txt

Modified: cfe/trunk/cmake/caches/README.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/cmake/caches/README.txt?rev=260203=260202=260203=diff
==
--- cfe/trunk/cmake/caches/README.txt (original)
+++ cfe/trunk/cmake/caches/README.txt Tue Feb  9 00:49:08 2016
@@ -4,15 +4,71 @@ CMake Caches
 This directory contains CMake cache scripts that pre-populate the CMakeCache in
 a build directory with commonly used settings.
 
-The first two cache files in the directory are used by Apple to build the clang
-distribution packaged with Xcode. You can use the caches with the following
-CMake invocation:
+You can use the caches files with the following CMake invocation:
 
 cmake -G 
-  -C /tools/clang/cmake/caches/Apple-stage1.cmake
-  -DCMAKE_BUILD_TYPE=Release
-  [-DCMAKE_INSTALL_PREFIX=]
+  -C 
+  [additional CMake options (i.e. -DCMAKE_INSTALL_PREFIX=)]
   
 
-Building the `bootstrap` target from this generation will build clang, and
-`bootstrap-install` will install it.
+Options specified on the command line will override options in the cache files.
+
+The following cache files exist.
+
+Apple-stage1
+
+
+The Apple stage1 cache configures a two stage build similar to how Apple builds
+the clang shipped with Xcode. The build files generated from this invocation 
has
+a target named "stage2" which performs an LTO build of clang.
+
+The Apple-stage2 cache can be used directly to match the build settings Apple
+uses in shipping builds without doing a full bootstrap build.
+
+PGO
+---
+
+The PGO CMake cache can be used to generate a multi-stage instrumented 
compiler.
+You can configure your build directory with the following invocation of CMake:
+
+cmake -G  -C /cmake/caches/PGO.cmake 
+
+After configuration the following additional targets will be generated:
+
+stage2-instrumented:
+Builds a stage1 x86 compiler, runtime, and required tools (llvm-config,
+llvm-profdata) then uses that compiler to build an instrumented stage2 
compiler.
+
+stage2-instrumented-generate-profdata:
+Depends on "stage2-instrumented" and will use the instrumented compiler to
+generate profdata based on the training files in /utils/perf-training
+
+stage2:
+Depends on "stage2-instrumented-generate-profdata" and will use the stage1
+compiler with the stage2 profdata to build a PGO-optimized compiler.
+
+stage2-check-llvm:
+Depends on stage2 and runs check-llvm using the stage3 compiler.
+
+stage2-check-clang:
+Depends on stage2 and runs check-clang using the stage3 compiler.
+
+stage2-check-all:
+Depends on stage2 and runs check-all using the stage3 compiler.
+
+stage2-test-suite:
+Depends on stage2 and runs the test-suite using the stage3 compiler (requires
+in-tree test-suite).
+
+3-stage
+---
+
+This cache file can be used to generate a 3-stage clang build. You can 
configure
+using the following CMake command:
+
+cmake -C /cmake/caches/3-stage.cmake -G Ninja 
+
+You can then run "ninja stage3-clang" to build stage1, stage2 and stage3 
clangs.
+
+This is useful for finding non-determinism the compiler by verifying that 
stage2
+and stage3 are identical.


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

Re: r260048 - [Frontend] Make the memory management of FrontendAction pointers explicit by using unique_ptr.

[David Blaikie via cfe-commits]

FWIW, I tried to do something like this, perhaps with some other
improvements, a few years ago. Not sure if things have changed for the
better since then, but maybe those old patches may provide some
insight/other improvements/options:

http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20140915/115122.html
http://reviews.llvm.org/D4313
http://reviews.llvm.org/D4312

On Sun, Feb 7, 2016 at 11:28 AM, Argyrios Kyrtzidis via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: akirtzidis
> Date: Sun Feb  7 13:28:36 2016
> New Revision: 260048
>
> URL: http://llvm.org/viewvc/llvm-project?rev=260048=rev
> Log:
> [Frontend] Make the memory management of FrontendAction pointers explicit
> by using unique_ptr.
>
> Modified:
> cfe/trunk/include/clang/ARCMigrate/ARCMTActions.h
> cfe/trunk/include/clang/Frontend/FrontendAction.h
> cfe/trunk/include/clang/Frontend/FrontendActions.h
> cfe/trunk/include/clang/Rewrite/Frontend/FrontendActions.h
> cfe/trunk/lib/ARCMigrate/ARCMTActions.cpp
> cfe/trunk/lib/ARCMigrate/ObjCMT.cpp
> cfe/trunk/lib/Frontend/ASTMerge.cpp
> cfe/trunk/lib/Frontend/FrontendAction.cpp
> cfe/trunk/lib/FrontendTool/ExecuteCompilerInvocation.cpp
>
> Modified: cfe/trunk/include/clang/ARCMigrate/ARCMTActions.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/ARCMigrate/ARCMTActions.h?rev=260048=260047=260048=diff
>
> ==
> --- cfe/trunk/include/clang/ARCMigrate/ARCMTActions.h (original)
> +++ cfe/trunk/include/clang/ARCMigrate/ARCMTActions.h Sun Feb  7 13:28:36
> 2016
> @@ -22,7 +22,7 @@ protected:
>bool BeginInvocation(CompilerInstance ) override;
>
>  public:
> -  CheckAction(FrontendAction *WrappedAction);
> +  CheckAction(std::unique_ptr WrappedAction);
>  };
>
>  class ModifyAction : public WrapperFrontendAction {
> @@ -30,7 +30,7 @@ protected:
>bool BeginInvocation(CompilerInstance ) override;
>
>  public:
> -  ModifyAction(FrontendAction *WrappedAction);
> +  ModifyAction(std::unique_ptr WrappedAction);
>  };
>
>  class MigrateSourceAction : public ASTFrontendAction {
> @@ -49,7 +49,8 @@ protected:
>bool BeginInvocation(CompilerInstance ) override;
>
>  public:
> -  MigrateAction(FrontendAction *WrappedAction, StringRef migrateDir,
> +  MigrateAction(std::unique_ptr WrappedAction,
> +StringRef migrateDir,
>  StringRef plistOut,
>  bool emitPremigrationARCErrors);
>  };
> @@ -61,8 +62,8 @@ class ObjCMigrateAction : public Wrapper
>FileRemapper Remapper;
>CompilerInstance *CompInst;
>  public:
> -  ObjCMigrateAction(FrontendAction *WrappedAction, StringRef migrateDir,
> -unsigned migrateAction);
> +  ObjCMigrateAction(std::unique_ptr WrappedAction,
> +StringRef migrateDir, unsigned migrateAction);
>
>  protected:
>std::unique_ptr CreateASTConsumer(CompilerInstance ,
>
> Modified: cfe/trunk/include/clang/Frontend/FrontendAction.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/FrontendAction.h?rev=260048=260047=260048=diff
>
> ==
> --- cfe/trunk/include/clang/Frontend/FrontendAction.h (original)
> +++ cfe/trunk/include/clang/Frontend/FrontendAction.h Sun Feb  7 13:28:36
> 2016
> @@ -283,7 +283,7 @@ protected:
>  public:
>/// Construct a WrapperFrontendAction from an existing action, taking
>/// ownership of it.
> -  WrapperFrontendAction(FrontendAction *WrappedAction);
> +  WrapperFrontendAction(std::unique_ptr WrappedAction);
>
>bool usesPreprocessorOnly() const override;
>TranslationUnitKind getTranslationUnitKind() override;
>
> Modified: cfe/trunk/include/clang/Frontend/FrontendActions.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/FrontendActions.h?rev=260048=260047=260048=diff
>
> ==
> --- cfe/trunk/include/clang/Frontend/FrontendActions.h (original)
> +++ cfe/trunk/include/clang/Frontend/FrontendActions.h Sun Feb  7 13:28:36
> 2016
> @@ -168,7 +168,7 @@ public:
>   */
>  class ASTMergeAction : public FrontendAction {
>/// \brief The action that the merge action adapts.
> -  FrontendAction *AdaptedAction;
> +  std::unique_ptr AdaptedAction;
>
>/// \brief The set of AST files to merge.
>std::vector ASTFiles;
> @@ -184,7 +184,8 @@ protected:
>void EndSourceFileAction() override;
>
>  public:
> -  ASTMergeAction(FrontendAction *AdaptedAction, ArrayRef
> ASTFiles);
> +  ASTMergeAction(std::unique_ptr AdaptedAction,
> + ArrayRef ASTFiles);
>~ASTMergeAction() override;
>
>bool usesPreprocessorOnly() const override;
>
> Modified: cfe/trunk/include/clang/Rewrite/Frontend/FrontendActions.h
> URL:
> 

Re: r259931 - [SystemZ] Define __GCC_HAVE_SYNC_COMPARE_AND_SWAP macros

[Hal Finkel via cfe-commits]

- Original Message -
> From: "Ulrich Weigand" 
> To: "Hal Finkel" 
> Cc: cfe-commits@lists.llvm.org
> Sent: Monday, February 8, 2016 7:53:29 AM
> Subject: Re: r259931 - [SystemZ] Define __GCC_HAVE_SYNC_COMPARE_AND_SWAP 
> macros
> 
> Hal Finkel  wrote on 05.02.2016 23:14:54:
> 
> > Just a general comment: I believe we've now fixed this bug for at
> > least four different architectures (each time as a separate
> > effort).
> 
> Yes. Unfortunately I only noticed that after I'd already spent half
> a day debugging the problem from scratch on System Z :-/
> 
> > Is there some kind of auditing we could do to make sure we don't
> > run
> > into this again?
> 
> Well, on GCC common code automatically predefines the macro if and
> only if the back end actually implements the corresponding builtin
> without an external function call. We cannot really do that in LLVM
> due to the stronger separation between front end and back end here.
> 
> However, I guess we could at least provide a *test case* that
> verifies
> that front end and back end make the same choice. This would have to
> be a test case that runs a full compile (from un-preprocessed source
> straight through to assembler output) so we can verify the
> interaction
> of front end and back end, which I guess is frowned upon these days
> ...
> 
> The following example implements one idea I came up with:
> (See attached file: atomic-predefines.c)
> 
> It is neither perfectly complete (it only checks the current target,
> not all; and it doesn't check any variants of the current target,
> e.g. different CPU types), nor is it perfectly safe (some targets
> could theoretically emit weird code to implement a function call
> that would throw off the heuristics in this test).
> 
> In addition, I noticed when running it against some of the more
> obscure targets like Hexagon, the test actually triggers internal
> errors in the back end, so those probably ought to be fixed first.
> 
> Any suggestions to improve this test welcome!

We generally notice this when we try to use some part of the C++ standard 
library (std::atomic or std::thread as I recall). Could we have something in 
the test-suite that uses that functionality in a way likely to expose this bug?

 -Hal

> 
> 
> Bye,
> Ulrich
> 
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] SemaCXX: Support templates in availability attributes

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

This patch adds support for templates in availability attributes.
  - If the context for an availability diagnostic is a
`FunctionTemplateDecl`, look through it to the `FunctionDecl`.
  - Add `__has_feature(attribute_availability_in_templates)`.

Is there anything else I should be testing to be sure availability
works correctly in templates?  I'm working on a patch to add
availability markup to the libc++ headers, and this is the only
problem I've hit so far.  Anyone have thoughts on other things I
should test?



0001-SemaCXX-Support-templates-in-availability-attributes.patch
Description: Binary data
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r260201 - [CMake] Providing a CMake cache for 3-stage builds

[Chris Bieneman via cfe-commits]

Will do. That comment obviously is out of date as I keep adding files :-).

This latest one is a special ball of evil clever cmake goop, I can’t wait till 
bogner spots it :-).

-Chris

> On Feb 8, 2016, at 10:38 PM, Sean Silva  wrote:
> 
> Neat! Besides the awesomeness of the bootstrap, I didn't know about the -C 
> option! (well, except that you told me about it at the social last week, but 
> this is the first time I saw the actual usage).
> 
> btw, the README.txt in cmake/caches says "The first two cache files in the 
> directory" -- but it's not clear what the "first two" are. Could you update 
> the description there?
> 
> -- Sean Silva
> 
> On Mon, Feb 8, 2016 at 10:01 PM, Chris Bieneman via cfe-commits 
> > wrote:
> Author: cbieneman
> Date: Tue Feb  9 00:01:47 2016
> New Revision: 260201
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=260201=rev 
> 
> Log:
> [CMake] Providing a CMake cache for 3-stage builds
> 
> This cache file can be used to generate a 3-stage clang build. You can 
> configure using the following CMake command:
> 
> cmake -C /cmake/caches/3-stage.cmake -G Ninja 
> 
> You can then run "ninja stage3-clang" to build stage1, stage2 and stage3 
> clangs.
> 
> This is useful for finding non-determinism the compiler by verifying that 
> stage2 and stage3 are identical.
> 
> Added:
> cfe/trunk/cmake/caches/3-stage.cmake
> 
> Added: cfe/trunk/cmake/caches/3-stage.cmake
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/cmake/caches/3-stage.cmake?rev=260201=auto
>  
> 
> ==
> --- cfe/trunk/cmake/caches/3-stage.cmake (added)
> +++ cfe/trunk/cmake/caches/3-stage.cmake Tue Feb  9 00:01:47 2016
> @@ -0,0 +1,34 @@
> +set(CMAKE_BUILD_TYPE RELEASE CACHE STRING "")
> +set(CLANG_ENABLE_BOOTSTRAP ON CACHE BOOL "")
> +set(LLVM_BUILD_EXTERNAL_COMPILER_RT ON CACHE BOOL "")
> +set(LLVM_TARGETS_TO_BUILD X86 CACHE STRING "")
> +set(BOOTSTRAP_LLVM_ENABLE_LTO ON CACHE BOOL "")
> +
> +set(CLANG_BOOTSTRAP_PASSTHROUGH
> +  CLANG_ENABLE_BOOTSTRAP
> +  LLVM_BUILD_EXTERNAL_COMPILER_RT
> +  LLVM_TARGETS_TO_BUILD
> +  CLANG_BOOTSTRAP_PASSTHROUGH
> +  BOOTSTRAP_LLVM_ENABLE_LTO
> +  CMAKE_BUILD_TYPE
> +  CACHE STRING "")
> +
> +set(CLANG_BOOTSTRAP_TARGETS
> +  clang
> +  check-all
> +  check-llvm
> +  check-clang
> +  test-suite
> +  stage3
> +  stage3-clang
> +  stage3-check-all
> +  stage3-check-llvm
> +  stage3-check-clang
> +  stage3-test-suite CACHE STRING "")
> +
> +set(BOOTSTRAP_CLANG_BOOTSTRAP_TARGETS
> +  clang
> +  check-all
> +  check-llvm
> +  check-clang
> +  test-suite CACHE STRING "")
> 
> 
> ___
> 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: Linux-abi group

[H.J. Lu via cfe-commits]

On Mon, Feb 8, 2016 at 3:08 PM, Joseph Myers  wrote:
> On Mon, 8 Feb 2016, H.J. Lu wrote:
>
>> >> I was referring to program properties:
>> >>
>> >> https://groups.google.com/forum/#!topic/generic-abi/fyIXttIsYc8
>> >
>> > This looks more like an ELF topic to me, not really ABI.
>> >
>> > Please discuss this on a GNU project list because it affects the
>> > entire GNU project.
>> >
>>
>> gABI is ELF and affects all users, including GNU project, of gABI.
>> Linux-abi discusses Linux-specific extensions to gABI. It is for tools
>> like compilers, assembler, linker and run-time.  It isn't appropriate
>> for any GNU project list.
>
> I find it extremely unlikely that many well-thought-out extensions would
> be appropriate for GNU systems using the Linux kernel but not for GNU
> systems using Hurd or other kernels - the only such cases would be for
> things very closely related to kernel functionality.  There is a strong
> presumption that toolchain configuration should apply to all GNU systems
> rather than being specific to GNU/Linux without good reason.
>

Most of extensions aren't Linux kernel specific.  But some extensions
will require kernel support to function properly.


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

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

[Alexander Riccio via cfe-commits]

ariccio marked 2 inline comments as done.
ariccio added a comment.

I've reformatted, and changed the `PointerUnion` to a `const 
StackFrameContext*`.

Built successfully, etc...

(I hope I don't sound too pushy!)



Comment at: llvm/tools/clang/lib/StaticAnalyzer/Core/MemRegion.cpp:792
@@ +791,3 @@
+
+const MemRegion*
+MemRegionManager::getMemSpaceForLocalVariable(const VarDecl *D,

I'm sorry, I think you're right, but I wanna get this patch over with, so I can 
move on to other things. Some other time, maybe?


http://reviews.llvm.org/D16873



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

Re: [PATCH] D16947: [PGO] assignment operator does not get profile data

[Xinliang David Li via cfe-commits]

Wrong in the sense the the coverage result for the default operators
(the line where they are declared) is marked as if they are not called
which can be confusing to the user.

David

On Mon, Feb 8, 2016 at 9:09 PM, David Blaikie  wrote:
>
>
> On Mon, Feb 8, 2016 at 9:00 PM, Xinliang David Li 
> wrote:
>>
>> On Mon, Feb 8, 2016 at 8:46 PM, David Blaikie  wrote:
>> >
>> > On Mon, Feb 8, 2016 at 7:39 PM, Xinliang David Li 
>> > wrote:
>> >>
>> >> I took a look at the problem. The implicitly defaulted operators
>> >> should not be instrumented as specified -- I actually I just added the
>> >> new test case for that (checking profile counter not generated) right
>> >> after my previous reply and it still passes with this patch. The
>> >> reason is that those operators have 'implicit' bit set, and profile
>> >> instrumentation in FE is implemented in two stages: 1) counter
>> >> assignment; 2) actual transformation.  For methods with implicit bit
>> >> set, step 1) is skipped as designed, so step 2) simply becomes a
>> >> no-op.
>> >>
>> >> In short, the test case still needs explicit '=default', and the
>> >> implicit case is covered elsewhere.
>> >
>> >
>> > OK, thanks for the explanation!
>> >
>> > Why is that the case, though - why would an implicitly default function
>> > be
>> > any different from a profile (& profile-guided-optimization) perspective
>> > from an explicitly defaulted one?
>>
>> There are two factors to consider -- PGO and coverage testing.
>> Implicitly declared functions are usually small/single BB so
>> instrumenting them does not bring too much benefit (they will be
>> inlined most of the cases any way) while increasing instrumentation
>> overhead. They are not needed for coveraging test either (as there are
>> no source lines to cover). This is a good tuning heuristic in most
>> cases, but can get wrong sometimes (IR based late instrumentation is
>> more focused on performance thus not depending on this tuning).
>>
>> Explicitly defaulted ones are different in the sense that if they are
>> not instrumented, the coverage result will be wrong.
>
>
> wrong in what way? Both functions (explicitly or implicitly defaulted) will
> be emitted, with line tables (looks like the = defaulted one is attributed
> to the line where the = default was written, and the implicitly defaulted
> one is attributed to wherever the class name is written)
>
> - David
>
>>
>>
>> thanks,
>>
>> David
>>
>> >
>> >>
>> >>
>> >> thanks,
>> >>
>> >> David
>> >>
>> >> On Mon, Feb 8, 2016 at 5:23 PM, David Blaikie 
>> >> wrote:
>> >> >
>> >> >
>> >> > On Mon, Feb 8, 2016 at 5:05 PM, Xinliang David Li
>> >> > 
>> >> > wrote:
>> >> >>
>> >> >> ha! somehow I kept thinking you are referring to implicit declared
>> >> >> ctors.
>> >> >
>> >> >
>> >> > Ah, glad we figured out the disconnect - thanks for bearing with me!
>> >> >
>> >> >>
>> >> >>
>> >> >> From your test case, it is seems that the implicit copy/move op is
>> >> >> also broken and is fixed by this patch too. That means  a missing
>> >> >> test
>> >> >> case to me.  Will update the case when verified.
>> >> >
>> >> >
>> >> > Again, this is a case where I'd probably just simplify the test, as I
>> >> > asked
>> >> > earlier in the thread (I asked if it mattered if the op was
>> >> > explicitly
>> >> > or
>> >> > implicitly defaulted (& your response: "> Is the fix/codepath
>> >> > specifically
>> >> > about explicitly defaulted ops?
>> >> >
>> >> > yes -- explicitly defaulted. There are some test coverage already for
>> >> > implicitly declared ctors (but not assignment op -- probably worth
>> >> > adding some testing too).")
>> >> >
>> >> > So I'd just simplify the test by removing the "= default" - I don't
>> >> > think
>> >> > there's value in testing both the explicit default and implicit
>> >> > default
>> >> > if
>> >> > it's just the default-y-ness that's relevant here. Otherwise we could
>> >> > end up
>> >> > testing all sorts of ways of writing/interacting with dtors which
>> >> > wouldn't
>> >> > be relevant to the code/fix/etc.
>> >> >
>> >> > This seems like the obvious test for the behavior:
>> >> >
>> >> > struct foo {
>> >> >   // non-trivial ops
>> >> >   foo =(const foo&);
>> >> >   foo =(foo&&);
>> >> > };
>> >> >
>> >> > struct bar {
>> >> >   foo f; // or derive bar from foo, but I think the member version is
>> >> > simpler
>> >> > };
>> >> >
>> >> > // force emission of bar's implicit special members, one way or
>> >> > another:
>> >> > bar &(bar::*x)(const bar&) = ::operator=;
>> >> > bar &(bar::*x)(bar&&) = ::operator=;
>> >> >
>> >> > (or just call them as you had in your test case - but that produces
>> >> > more
>> >> > code, etc in the module, extra functions/profile counters/etc)
>> >> >
>> >> > - Dave
>> >> >
>> >> >>
>> >> >>
>> >> >> thanks,
>> >> >>
>> >> >> David
>> >> >>
>> >> >>
>> >> >> On Mon, Feb 8, 2016 

r260201 - [CMake] Providing a CMake cache for 3-stage builds

[Chris Bieneman via cfe-commits]

Author: cbieneman
Date: Tue Feb  9 00:01:47 2016
New Revision: 260201

URL: http://llvm.org/viewvc/llvm-project?rev=260201=rev
Log:
[CMake] Providing a CMake cache for 3-stage builds

This cache file can be used to generate a 3-stage clang build. You can 
configure using the following CMake command:

cmake -C /cmake/caches/3-stage.cmake -G Ninja 

You can then run "ninja stage3-clang" to build stage1, stage2 and stage3 clangs.

This is useful for finding non-determinism the compiler by verifying that 
stage2 and stage3 are identical.

Added:
cfe/trunk/cmake/caches/3-stage.cmake

Added: cfe/trunk/cmake/caches/3-stage.cmake
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/cmake/caches/3-stage.cmake?rev=260201=auto
==
--- cfe/trunk/cmake/caches/3-stage.cmake (added)
+++ cfe/trunk/cmake/caches/3-stage.cmake Tue Feb  9 00:01:47 2016
@@ -0,0 +1,34 @@
+set(CMAKE_BUILD_TYPE RELEASE CACHE STRING "")
+set(CLANG_ENABLE_BOOTSTRAP ON CACHE BOOL "")
+set(LLVM_BUILD_EXTERNAL_COMPILER_RT ON CACHE BOOL "")
+set(LLVM_TARGETS_TO_BUILD X86 CACHE STRING "")
+set(BOOTSTRAP_LLVM_ENABLE_LTO ON CACHE BOOL "")
+
+set(CLANG_BOOTSTRAP_PASSTHROUGH 
+  CLANG_ENABLE_BOOTSTRAP
+  LLVM_BUILD_EXTERNAL_COMPILER_RT
+  LLVM_TARGETS_TO_BUILD
+  CLANG_BOOTSTRAP_PASSTHROUGH
+  BOOTSTRAP_LLVM_ENABLE_LTO
+  CMAKE_BUILD_TYPE
+  CACHE STRING "")
+
+set(CLANG_BOOTSTRAP_TARGETS
+  clang
+  check-all
+  check-llvm
+  check-clang
+  test-suite
+  stage3
+  stage3-clang
+  stage3-check-all
+  stage3-check-llvm
+  stage3-check-clang
+  stage3-test-suite CACHE STRING "")
+
+set(BOOTSTRAP_CLANG_BOOTSTRAP_TARGETS
+  clang
+  check-all
+  check-llvm
+  check-clang
+  test-suite CACHE STRING "")


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

r260194 - Avoid forcing emission of delayed dllexported classes on template instantiation

[Reid Kleckner via cfe-commits]

Author: rnk
Date: Mon Feb  8 20:51:17 2016
New Revision: 260194

URL: http://llvm.org/viewvc/llvm-project?rev=260194=rev
Log:
Avoid forcing emission of delayed dllexported classes on template instantiation

Fixes PR26490

Modified:
cfe/trunk/lib/Sema/SemaTemplateInstantiate.cpp
cfe/trunk/test/CodeGenCXX/dllexport.cpp

Modified: cfe/trunk/lib/Sema/SemaTemplateInstantiate.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaTemplateInstantiate.cpp?rev=260194=260193=260194=diff
==
--- cfe/trunk/lib/Sema/SemaTemplateInstantiate.cpp (original)
+++ cfe/trunk/lib/Sema/SemaTemplateInstantiate.cpp Mon Feb  8 20:51:17 2016
@@ -1949,6 +1949,13 @@ Sema::InstantiateClass(SourceLocation Po
   bool MergeWithParentScope = 
!Instantiation->isDefinedOutsideFunctionOrMethod();
   LocalInstantiationScope Scope(*this, MergeWithParentScope);
 
+  // All dllexported classes created during instantiation should be fully
+  // emitted after instantiation completes. We may not be ready to emit any
+  // delayed classes already on the stack, so save them away and put them back
+  // later.
+  decltype(DelayedDllExportClasses) ExportedClasses;
+  std::swap(ExportedClasses, DelayedDllExportClasses);
+
   // Pull attributes from the pattern onto the instantiation.
   InstantiateAttrs(TemplateArgs, Pattern, Instantiation);
 
@@ -2034,6 +2041,9 @@ Sema::InstantiateClass(SourceLocation Po
   // default arg exprs for default constructors if necessary now.
   ActOnFinishCXXNonNestedClass(Instantiation);
 
+  // Put back the delayed exported classes that we moved out of the way.
+  std::swap(ExportedClasses, DelayedDllExportClasses);
+
   // Instantiate late parsed attributes, and attach them to their decls.
   // See Sema::InstantiateAttrs
   for (LateInstantiatedAttrVec::iterator I = LateAttrs.begin(),

Modified: cfe/trunk/test/CodeGenCXX/dllexport.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/dllexport.cpp?rev=260194=260193=260194=diff
==
--- cfe/trunk/test/CodeGenCXX/dllexport.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/dllexport.cpp Mon Feb  8 20:51:17 2016
@@ -777,6 +777,17 @@ struct __declspec(dllexport) Baz {
 // M32-DAG: define weak_odr dllexport x86_thiscallcc dereferenceable(1) 
%"struct.InClassInits::Baz"* @"\01??4Baz@InClassInits@@QAEAAU01@ABU01@@Z"
 }
 
+// We had an issue where instantiating A would force emission of B's delayed
+// exported methods.
+namespace pr26490 {
+template  struct A { };
+struct __declspec(dllexport) B {
+  B(int = 0) {}
+  A m_fn1() {}
+};
+// M32-DAG: define weak_odr dllexport x86_thiscallcc void 
@"\01??_FB@pr26490@@QAEXXZ"
+}
+
 
 
//===--===//
 // Classes with template base classes


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

Re: [PATCH] D16947: [PGO] assignment operator does not get profile data

[Xinliang David Li via cfe-commits]

I took a look at the problem. The implicitly defaulted operators
should not be instrumented as specified -- I actually I just added the
new test case for that (checking profile counter not generated) right
after my previous reply and it still passes with this patch. The
reason is that those operators have 'implicit' bit set, and profile
instrumentation in FE is implemented in two stages: 1) counter
assignment; 2) actual transformation.  For methods with implicit bit
set, step 1) is skipped as designed, so step 2) simply becomes a
no-op.

In short, the test case still needs explicit '=default', and the
implicit case is covered elsewhere.

thanks,

David

On Mon, Feb 8, 2016 at 5:23 PM, David Blaikie  wrote:
>
>
> On Mon, Feb 8, 2016 at 5:05 PM, Xinliang David Li 
> wrote:
>>
>> ha! somehow I kept thinking you are referring to implicit declared ctors.
>
>
> Ah, glad we figured out the disconnect - thanks for bearing with me!
>
>>
>>
>> From your test case, it is seems that the implicit copy/move op is
>> also broken and is fixed by this patch too. That means  a missing test
>> case to me.  Will update the case when verified.
>
>
> Again, this is a case where I'd probably just simplify the test, as I asked
> earlier in the thread (I asked if it mattered if the op was explicitly or
> implicitly defaulted (& your response: "> Is the fix/codepath specifically
> about explicitly defaulted ops?
>
> yes -- explicitly defaulted. There are some test coverage already for
> implicitly declared ctors (but not assignment op -- probably worth
> adding some testing too).")
>
> So I'd just simplify the test by removing the "= default" - I don't think
> there's value in testing both the explicit default and implicit default if
> it's just the default-y-ness that's relevant here. Otherwise we could end up
> testing all sorts of ways of writing/interacting with dtors which wouldn't
> be relevant to the code/fix/etc.
>
> This seems like the obvious test for the behavior:
>
> struct foo {
>   // non-trivial ops
>   foo =(const foo&);
>   foo =(foo&&);
> };
>
> struct bar {
>   foo f; // or derive bar from foo, but I think the member version is
> simpler
> };
>
> // force emission of bar's implicit special members, one way or another:
> bar &(bar::*x)(const bar&) = ::operator=;
> bar &(bar::*x)(bar&&) = ::operator=;
>
> (or just call them as you had in your test case - but that produces more
> code, etc in the module, extra functions/profile counters/etc)
>
> - Dave
>
>>
>>
>> thanks,
>>
>> David
>>
>>
>> On Mon, Feb 8, 2016 at 4:58 PM, David Blaikie  wrote:
>> >
>> >
>> > On Mon, Feb 8, 2016 at 4:31 PM, Xinliang David Li 
>> > wrote:
>> >>
>> >> On Mon, Feb 8, 2016 at 4:05 PM, David Blaikie 
>> >> wrote:
>> >> >
>> >> >
>> >> > On Mon, Feb 8, 2016 at 3:58 PM, Xinliang David Li
>> >> > 
>> >> > wrote:
>> >> >>
>> >> >> To be clear, you are suggesting breaking the test into two (one for
>> >> >> copy, and one for move) ? I am totally fine with that.
>> >> >
>> >> >
>> >> > Nah, no need to split the test case - we try to keep the number of
>> >> > test
>> >> > files down (& group related tests into a single file) to reduce test
>> >> > execution time (a non-trivial about of check time is spent in process
>> >> > overhead).
>> >> >
>> >> >>
>> >> >>   I thought you
>> >> >> suggested removing the testing of move/op case because they might
>> >> >> share the same code path (clang's implementation) as the copy/op.
>> >> >
>> >> >
>> >> > I was suggesting that two cases is no big deal whether you test both
>> >> > or
>> >> > test
>> >> > one if they're the same codepath - if there were 5/many more things
>> >> > that
>> >> > shared the same codepath, I'd generally suggest testing a
>> >> > representative
>> >> > sample (possibly just a single one) rather than testing every client
>> >> > of
>> >> > the
>> >> > same code.
>> >> >
>> >> > Feel free to leave the two here as-is. (though if we're talking about
>> >> > test
>> >> > granularity, it's probably worth just putting these cases in the same
>> >> > file/type/etc as the ctor cases you mentioned were already covered)
>> >>
>> >> There is a balance somewhere:
>> >> 1) for small test cases like this, the overhead mainly comes from test
>> >> set up cost -- adding additional incremental test in the same file
>> >> probably almost comes for free (in terms of cost). However
>> >> 2) having too many cases grouped together also reduces the
>> >> debuggability when some test fails.
>> >
>> >
>> > Yep, for sure. In this case, testing the ctors and assignment ops in one
>> > file's probably not a bad tradeoff (you can see how Clang groups its
>> > tests -
>> > a file per language feature in many cases, exploring the myriad ways the
>> > feature can be used - this doesn't always work spectacularly (when you
>> > can't
>> > order the IR emission to happen mostly in the order 

[libcxx] r260195 - Use the reserved spellings for attributes

[Saleem Abdulrasool via cfe-commits]

Author: compnerd
Date: Mon Feb  8 22:05:37 2016
New Revision: 260195

URL: http://llvm.org/viewvc/llvm-project?rev=260195=rev
Log:
Use the reserved spellings for attributes

Change the no_sanitize attribute to use the reserved spelling.

Modified:
libcxx/trunk/include/__config

Modified: libcxx/trunk/include/__config
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__config?rev=260195=260194=260195=diff
==
--- libcxx/trunk/include/__config (original)
+++ libcxx/trunk/include/__config Mon Feb  8 22:05:37 2016
@@ -436,7 +436,7 @@ namespace std {
 
 // Allow for build-time disabling of unsigned integer sanitization
 #if !defined(_LIBCPP_DISABLE_UBSAN_UNSIGNED_INTEGER_CHECK) && 
__has_attribute(no_sanitize)
-#define _LIBCPP_DISABLE_UBSAN_UNSIGNED_INTEGER_CHECK 
__attribute((no_sanitize("unsigned-integer-overflow")))
+#define _LIBCPP_DISABLE_UBSAN_UNSIGNED_INTEGER_CHECK 
__attribute__((__no_sanitize__("unsigned-integer-overflow")))
 #endif 
 
 #elif defined(__GNUC__)


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

Re: [PATCH] D16947: [PGO] assignment operator does not get profile data

[Xinliang David Li via cfe-commits]

On Mon, Feb 8, 2016 at 8:46 PM, David Blaikie  wrote:
>
> On Mon, Feb 8, 2016 at 7:39 PM, Xinliang David Li 
> wrote:
>>
>> I took a look at the problem. The implicitly defaulted operators
>> should not be instrumented as specified -- I actually I just added the
>> new test case for that (checking profile counter not generated) right
>> after my previous reply and it still passes with this patch. The
>> reason is that those operators have 'implicit' bit set, and profile
>> instrumentation in FE is implemented in two stages: 1) counter
>> assignment; 2) actual transformation.  For methods with implicit bit
>> set, step 1) is skipped as designed, so step 2) simply becomes a
>> no-op.
>>
>> In short, the test case still needs explicit '=default', and the
>> implicit case is covered elsewhere.
>
>
> OK, thanks for the explanation!
>
> Why is that the case, though - why would an implicitly default function be
> any different from a profile (& profile-guided-optimization) perspective
> from an explicitly defaulted one?

There are two factors to consider -- PGO and coverage testing.
Implicitly declared functions are usually small/single BB so
instrumenting them does not bring too much benefit (they will be
inlined most of the cases any way) while increasing instrumentation
overhead. They are not needed for coveraging test either (as there are
no source lines to cover). This is a good tuning heuristic in most
cases, but can get wrong sometimes (IR based late instrumentation is
more focused on performance thus not depending on this tuning).

Explicitly defaulted ones are different in the sense that if they are
not instrumented, the coverage result will be wrong.

thanks,

David

>
>>
>>
>> thanks,
>>
>> David
>>
>> On Mon, Feb 8, 2016 at 5:23 PM, David Blaikie  wrote:
>> >
>> >
>> > On Mon, Feb 8, 2016 at 5:05 PM, Xinliang David Li 
>> > wrote:
>> >>
>> >> ha! somehow I kept thinking you are referring to implicit declared
>> >> ctors.
>> >
>> >
>> > Ah, glad we figured out the disconnect - thanks for bearing with me!
>> >
>> >>
>> >>
>> >> From your test case, it is seems that the implicit copy/move op is
>> >> also broken and is fixed by this patch too. That means  a missing test
>> >> case to me.  Will update the case when verified.
>> >
>> >
>> > Again, this is a case where I'd probably just simplify the test, as I
>> > asked
>> > earlier in the thread (I asked if it mattered if the op was explicitly
>> > or
>> > implicitly defaulted (& your response: "> Is the fix/codepath
>> > specifically
>> > about explicitly defaulted ops?
>> >
>> > yes -- explicitly defaulted. There are some test coverage already for
>> > implicitly declared ctors (but not assignment op -- probably worth
>> > adding some testing too).")
>> >
>> > So I'd just simplify the test by removing the "= default" - I don't
>> > think
>> > there's value in testing both the explicit default and implicit default
>> > if
>> > it's just the default-y-ness that's relevant here. Otherwise we could
>> > end up
>> > testing all sorts of ways of writing/interacting with dtors which
>> > wouldn't
>> > be relevant to the code/fix/etc.
>> >
>> > This seems like the obvious test for the behavior:
>> >
>> > struct foo {
>> >   // non-trivial ops
>> >   foo =(const foo&);
>> >   foo =(foo&&);
>> > };
>> >
>> > struct bar {
>> >   foo f; // or derive bar from foo, but I think the member version is
>> > simpler
>> > };
>> >
>> > // force emission of bar's implicit special members, one way or another:
>> > bar &(bar::*x)(const bar&) = ::operator=;
>> > bar &(bar::*x)(bar&&) = ::operator=;
>> >
>> > (or just call them as you had in your test case - but that produces more
>> > code, etc in the module, extra functions/profile counters/etc)
>> >
>> > - Dave
>> >
>> >>
>> >>
>> >> thanks,
>> >>
>> >> David
>> >>
>> >>
>> >> On Mon, Feb 8, 2016 at 4:58 PM, David Blaikie 
>> >> wrote:
>> >> >
>> >> >
>> >> > On Mon, Feb 8, 2016 at 4:31 PM, Xinliang David Li
>> >> > 
>> >> > wrote:
>> >> >>
>> >> >> On Mon, Feb 8, 2016 at 4:05 PM, David Blaikie 
>> >> >> wrote:
>> >> >> >
>> >> >> >
>> >> >> > On Mon, Feb 8, 2016 at 3:58 PM, Xinliang David Li
>> >> >> > 
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> To be clear, you are suggesting breaking the test into two (one
>> >> >> >> for
>> >> >> >> copy, and one for move) ? I am totally fine with that.
>> >> >> >
>> >> >> >
>> >> >> > Nah, no need to split the test case - we try to keep the number of
>> >> >> > test
>> >> >> > files down (& group related tests into a single file) to reduce
>> >> >> > test
>> >> >> > execution time (a non-trivial about of check time is spent in
>> >> >> > process
>> >> >> > overhead).
>> >> >> >
>> >> >> >>
>> >> >> >>   I thought you
>> >> >> >> suggested removing the testing of move/op case because they might
>> >> >> >> share the same code path 

Re: r260201 - [CMake] Providing a CMake cache for 3-stage builds

[Sean Silva via cfe-commits]

Neat! Besides the awesomeness of the bootstrap, I didn't know about the -C
option! (well, except that you told me about it at the social last week,
but this is the first time I saw the actual usage).

btw, the README.txt in cmake/caches says "The first two cache files in the
directory" -- but it's not clear what the "first two" are. Could you update
the description there?

-- Sean Silva

On Mon, Feb 8, 2016 at 10:01 PM, Chris Bieneman via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: cbieneman
> Date: Tue Feb  9 00:01:47 2016
> New Revision: 260201
>
> URL: http://llvm.org/viewvc/llvm-project?rev=260201=rev
> Log:
> [CMake] Providing a CMake cache for 3-stage builds
>
> This cache file can be used to generate a 3-stage clang build. You can
> configure using the following CMake command:
>
> cmake -C /cmake/caches/3-stage.cmake -G Ninja 
>
> You can then run "ninja stage3-clang" to build stage1, stage2 and stage3
> clangs.
>
> This is useful for finding non-determinism the compiler by verifying that
> stage2 and stage3 are identical.
>
> Added:
> cfe/trunk/cmake/caches/3-stage.cmake
>
> Added: cfe/trunk/cmake/caches/3-stage.cmake
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/cmake/caches/3-stage.cmake?rev=260201=auto
>
> ==
> --- cfe/trunk/cmake/caches/3-stage.cmake (added)
> +++ cfe/trunk/cmake/caches/3-stage.cmake Tue Feb  9 00:01:47 2016
> @@ -0,0 +1,34 @@
> +set(CMAKE_BUILD_TYPE RELEASE CACHE STRING "")
> +set(CLANG_ENABLE_BOOTSTRAP ON CACHE BOOL "")
> +set(LLVM_BUILD_EXTERNAL_COMPILER_RT ON CACHE BOOL "")
> +set(LLVM_TARGETS_TO_BUILD X86 CACHE STRING "")
> +set(BOOTSTRAP_LLVM_ENABLE_LTO ON CACHE BOOL "")
> +
> +set(CLANG_BOOTSTRAP_PASSTHROUGH
> +  CLANG_ENABLE_BOOTSTRAP
> +  LLVM_BUILD_EXTERNAL_COMPILER_RT
> +  LLVM_TARGETS_TO_BUILD
> +  CLANG_BOOTSTRAP_PASSTHROUGH
> +  BOOTSTRAP_LLVM_ENABLE_LTO
> +  CMAKE_BUILD_TYPE
> +  CACHE STRING "")
> +
> +set(CLANG_BOOTSTRAP_TARGETS
> +  clang
> +  check-all
> +  check-llvm
> +  check-clang
> +  test-suite
> +  stage3
> +  stage3-clang
> +  stage3-check-all
> +  stage3-check-llvm
> +  stage3-check-clang
> +  stage3-test-suite CACHE STRING "")
> +
> +set(BOOTSTRAP_CLANG_BOOTSTRAP_TARGETS
> +  clang
> +  check-all
> +  check-llvm
> +  check-clang
> +  test-suite CACHE STRING "")
>
>
> ___
> 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] D16926: [clang-tidy] Fix assertion failure on `at` function in modernize-loop-convert.

[Alexander Kornienko via cfe-commits]

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

LG. Thank you!


http://reviews.llvm.org/D16926



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

r260092 - [OPENMP] Fix test incompatibility with arm buildbots

[Alexey Bataev via cfe-commits]

Author: abataev
Date: Mon Feb  8 07:47:46 2016
New Revision: 260092

URL: http://llvm.org/viewvc/llvm-project?rev=260092=rev
Log:
[OPENMP] Fix test incompatibility with arm buildbots

Modified:
cfe/trunk/test/OpenMP/parallel_private_codegen.cpp

Modified: cfe/trunk/test/OpenMP/parallel_private_codegen.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/OpenMP/parallel_private_codegen.cpp?rev=260092=260091=260092=diff
==
--- cfe/trunk/test/OpenMP/parallel_private_codegen.cpp (original)
+++ cfe/trunk/test/OpenMP/parallel_private_codegen.cpp Mon Feb  8 07:47:46 2016
@@ -107,7 +107,7 @@ int main() {
   // LAMBDA: call{{.*}} void {{.+}} @__kmpc_fork_call({{.+}}, i32 0, {{.+}}* 
[[OMP_REGION:@.+]] to {{.+}})
 #pragma omp parallel private(g, sivar)
   {
-// LAMBDA: define {{.+}} @{{.+}}([[SS_TY]]* %
+// LAMBDA: define {{.+}} @{{.+}}([[SS_TY]]*
 // LAMBDA: store i{{[0-9]+}} 0, i{{[0-9]+}}* %
 // LAMBDA: store i8
 // LAMBDA: call void (%{{.+}}*, i{{[0-9]+}}, void (i{{[0-9]+}}*, 
i{{[0-9]+}}*, ...)*, ...) @__kmpc_fork_call(%{{.+}}* @{{.+}}, i{{[0-9]+}} 1, 
void (i{{[0-9]+}}*, i{{[0-9]+}}*, ...)* bitcast (void (i{{[0-9]+}}*, 
i{{[0-9]+}}*, [[SS_TY]]*)* [[SS_MICROTASK:@.+]] to void
@@ -207,7 +207,7 @@ int main() {
   }
   }();
   return 0;
-// BLOCKS: define {{.+}} @{{.+}}([[SS_TY]]* %
+// BLOCKS: define {{.+}} @{{.+}}([[SS_TY]]*
 // BLOCKS: store i{{[0-9]+}} 0, i{{[0-9]+}}* %
 // BLOCKS: store i8
 // BLOCKS: call void (%{{.+}}*, i{{[0-9]+}}, void (i{{[0-9]+}}*, i{{[0-9]+}}*, 
...)*, ...) @__kmpc_fork_call(%{{.+}}* @{{.+}}, i{{[0-9]+}} 1, void 
(i{{[0-9]+}}*, i{{[0-9]+}}*, ...)* bitcast (void (i{{[0-9]+}}*, i{{[0-9]+}}*, 
[[SS_TY]]*)* [[SS_MICROTASK:@.+]] to void


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

Re: [PATCH] D16308: clang-tidy Enhance readability-simplify-boolean-expr check to handle implicit conversions of integral types to bool and member pointers

[Aaron Ballman via cfe-commits]

aaron.ballman added a comment.

This is causing build bot failures:

http://bb.pgr.jp/builders/cmake-clang-tools-x86_64-linux/builds/23351
http://lab.llvm.org:8011/builders/clang-s390x-linux/builds/492
http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/812

The failure is not obvious to me, and I don't have the opportunity to debug 
locally right now, so I have reverted in r260097.


http://reviews.llvm.org/D16308



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

Re: [PATCH] D16310: new clang-tidy checker misc-long-cast

[Daniel Marjamäki via cfe-commits]

danielmarjamaki added inline comments.


Comment at: docs/clang-tidy/checks/misc-misplaced-widening-cast.rst:2
@@ +1,3 @@
+.. title:: clang-tidy - misc-misplaced-widening-cast
+
+misc-misplaced-widening-cast

For information, it seem I had to use -DLLVM_ENABLE_SPHINX=ON also ..


http://reviews.llvm.org/D16310



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

Re: [PATCH] D12834: add gcc abi_tag support

[Dmitry Polukhin via cfe-commits]

DmitryPolukhin added a comment.

Hi Stefan,

What are your plans about this patch? The patch has number of comments about 
Sema part from Aaron and me but in general there are no major issues with Sema 
for the attribute.

As for mangling part I think recursive approach looks reasonable because 
alternative implementation will require re-implementation significant part of 
name mangling just to calculate abi_tags for types. So your approach minimizes 
code duplication. I made following changes in your patch F1448674: 
abi_tags.patch :

- rebase on top-of-the-tree
- fixed all failing tests (now check-clang has no unexpected fails)
- fixed issue with mangling for variables in global namespace with abi_tags
- partially fixed style/clang-format issues
- added more tests on abi_tags (used the newest GCC mangling for templates with 
Jason's patches from Jan 31, 2016)

If you are going to keep working on this patch, please integrate my patch in 
your patch. If you are not going to keep working on this patch, please let me 
know.

Thanks,
Dmitry Polukhin

Software Engineer
Intel Compiler Team


Repository:
  rL LLVM

http://reviews.llvm.org/D12834



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

Re: [PATCH] D16310: new clang-tidy checker misc-long-cast

[Daniel Marjamäki via cfe-commits]

danielmarjamaki added inline comments.


Comment at: clang-tidy/misc/MisplacedWideningCastCheck.cpp:31
@@ +30,3 @@
+
+  Finder->addMatcher(returnStmt(has(Cast)), this);
+  Finder->addMatcher(varDecl(has(Cast)), this);

alexfh wrote:
> FYI, these matchers can be combined using `anyOf`. Not sure whether this will 
> be better (readability-wise and performance-wise) or not.
hmm.. are you sure .. for instance this does not work: stmt(anyOf(returnStmt(), 
varDecl()))



Comment at: clang-tidy/misc/MisplacedWideningCastCheck.h:16
@@ +15,3 @@
+namespace clang {
+namespace tidy {
+

alexfh wrote:
> Please add `namespace misc {`. BTW, do you know the `add_new_check.py` script 
> that uses the currently recommended template?
yes I used add_new_check.py to create this checker, thank you.. so I did not 
think I would have to run it again. I'll try to rerun add_new_check.py in the 
future.


Comment at: docs/clang-tidy/checks/misc-misplaced-widening-cast.rst:1
@@ +1,2 @@
+.. title:: clang-tidy - misc-misplaced-widening-cast
+

alexfh wrote:
> If you wonder how to test the RST you write:
> 
>   1. when running cmake, specify `-DCLANG_TOOLS_EXTRA_INCLUDE_DOCS=ON` (you 
> can also turn on `LLVM_INCLUDE_DOCS` and `CLANG_INCLUDE_DOCS`, if you wish, 
> but this shouldn't be necessary)
>   2. `make/ninja docs-clang-tools-html`, the results should be generated in 
> "/tools/clang/tools/extra/docs/html"
thanks.. something does not work.

mkdir ~/llvm/build && cd ~/llvm/build
cmake -DCLANG_TOOLS_EXTRA_INCLUDE_DOCS=ON ..
make -j4
make docs-clang-tools-html

=>

make: *** No rule to create target ”docs-clang-tools-html”.  Stopping.

I have debian on my computer.



http://reviews.llvm.org/D16310



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

Re: [PATCH] D16308: clang-tidy Enhance readability-simplify-boolean-expr check to handle implicit conversions of integral types to bool and member pointers

[Aaron Ballman via cfe-commits]

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

Commit in r260096, sorry for the delay. You should speak to Chris Lattner about 
getting commit privileges so that you're not blocked on one of us being 
available to commit on your behalf again.


http://reviews.llvm.org/D16308



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

r260091 - [OPENMP] Fixed test incompat with MSVC

[Alexey Bataev via cfe-commits]

Author: abataev
Date: Mon Feb  8 07:02:00 2016
New Revision: 260091

URL: http://llvm.org/viewvc/llvm-project?rev=260091=rev
Log:
[OPENMP] Fixed test incompat with MSVC

Modified:
cfe/trunk/test/OpenMP/parallel_private_codegen.cpp

Modified: cfe/trunk/test/OpenMP/parallel_private_codegen.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/OpenMP/parallel_private_codegen.cpp?rev=260091=260090=260091=diff
==
--- cfe/trunk/test/OpenMP/parallel_private_codegen.cpp (original)
+++ cfe/trunk/test/OpenMP/parallel_private_codegen.cpp Mon Feb  8 07:02:00 2016
@@ -100,7 +100,7 @@ int main() {
   // LAMBDA: [[G:@.+]] = global i{{[0-9]+}} 1212,
   // LAMBDA-LABEL: @main
   // LAMBDA: call
-  // LAMBDA: call{{.*}} void [[OUTER_LAMBDA:@.+]](
+  // LAMBDA: call{{.*}} void [[OUTER_LAMBDA:@[^(]+]](
   [&]() {
   // LAMBDA: define{{.*}} internal{{.*}} void [[OUTER_LAMBDA]](
   // LAMBDA-NOT: = getelementptr inbounds %{{.+}},


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

Re: r259985 - Re-apply r259977 - [OpenMP] Reorganize code to allow specialized code generation for different devices.

[Renato Golin via cfe-commits]

On 7 February 2016 at 17:29, Samuel F Antao  wrote:

> Hi Renato,
>
> This is not related with my patch, I'm afraid your buildbot won't go green
> with the revert. This looks to be related with r259976. My patch
> triggered the problem because it touched a CmakeList.txt. The code itself
> is completely unrelated with the failure.
>

Hi Samuel,

You are correct, I apologise. Nico has disabled the test (r260056
) which made
the bot green again (obviously).

Maybe you can re-apply your patch now?

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

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

[Alexander Kornienko via cfe-commits]

alexfh added a comment.

Looks good apart from renaming and one comment that's still relevant.



Comment at: clang-tidy/misc/UninitializedFieldCheck.cpp:178
@@ +177,3 @@
+
+  SmallPtrSet FieldsToInit;
+  fieldsRequiringInit(MemberFields, FieldsToInit);

What about this? (relates to line 184 now)


http://reviews.llvm.org/D16517



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

Re: [PATCH] D16310: new clang-tidy checker misc-long-cast

[Daniel Marjamäki via cfe-commits]

danielmarjamaki updated this revision to Diff 47182.
danielmarjamaki marked 9 inline comments as done.
danielmarjamaki added a comment.

Fixed review comments


http://reviews.llvm.org/D16310

Files:
  clang-tidy/misc/CMakeLists.txt
  clang-tidy/misc/MiscTidyModule.cpp
  clang-tidy/misc/MisplacedWideningCastCheck.cpp
  clang-tidy/misc/MisplacedWideningCastCheck.h
  docs/clang-tidy/checks/list.rst
  docs/clang-tidy/checks/misc-misplaced-widening-cast.rst
  test/clang-tidy/misc-misplaced-widening-cast.cpp

Index: test/clang-tidy/misc-misplaced-widening-cast.cpp
===
--- test/clang-tidy/misc-misplaced-widening-cast.cpp
+++ test/clang-tidy/misc-misplaced-widening-cast.cpp
@@ -0,0 +1,64 @@
+// RUN: %check_clang_tidy %s misc-misplaced-widening-cast %t
+
+void assign(int a, int b) {
+  long l;
+
+  l = a * b;
+  l = (long)(a * b);
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: either cast from 'int' to 'long' is ineffective, or there is loss of precision before the conversion [misc-misplaced-widening-cast]
+  l = (long)a * b;
+
+  l = (long)(a << 8);
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: either cast from 'int' to 'long'
+  l = (long)b << 8;
+
+  l = static_cast(a * b);
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: either cast from 'int' to 'long' is ineffective, or there is loss of precision before the conversion [misc-misplaced-widening-cast]
+}
+
+void init(unsigned int n) {
+  long l = (long)(n << 8);
+  // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: either cast from 'unsigned int'
+}
+
+long ret(int a) {
+  return (long)(a * 1000);
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: either cast from 'int' to 'long'
+}
+
+void dontwarn1(unsigned char a, int i, unsigned char *p) {
+  long l;
+  // the result is a 9 bit value, there is no truncation in the implicit cast.
+  l = (long)(a + 15);
+  // the result is a 12 bit value, there is no truncation in the implicit cast.
+  l = (long)(a << 4);
+  // the result is a 3 bit value, there is no truncation in the implicit cast.
+  l = (long)((i%5)+1);
+  // the result is a 16 bit value, there is no truncation in the implicit cast.
+  l = (long)(((*p)<<8) + *(p+1));
+}
+
+template  struct DontWarn2 {
+  void assign(T a, T b) {
+long l;
+l = (long)(a * b);
+  }
+};
+DontWarn2 DW2;
+
+// Cast is not suspicious when casting macro.
+#define A  (X<<2)
+long macro1(int X) {
+  return (long)A;
+}
+
+// Don't warn about cast in macro.
+#define B(X,Y)   (long)(X*Y)
+long macro2(int x, int y) {
+  return B(x,y);
+}
+
+void floatingpoint(float a, float b) {
+  double d = (double)(a * b); // Currently we don't warn for this.
+}
+
Index: docs/clang-tidy/checks/misc-misplaced-widening-cast.rst
===
--- docs/clang-tidy/checks/misc-misplaced-widening-cast.rst
+++ docs/clang-tidy/checks/misc-misplaced-widening-cast.rst
@@ -0,0 +1,39 @@
+.. title:: clang-tidy - misc-misplaced-widening-cast
+
+misc-misplaced-widening-cast
+
+
+This check will warn when there is a explicit redundant cast of a calculation
+result to a bigger type. If the intention of the cast is to avoid loss of
+precision then the cast is misplaced, and there can be loss of precision.
+Otherwise the cast is ineffective.
+
+Example code::
+
+long f(int x) {
+return (long)(x*1000);
+}
+
+The result x*1000 is first calculated using int precision. If the result
+exceeds int precision there is loss of precision. Then the result is casted to
+long.
+
+If there is no loss of precision then the cast can be removed or you can
+explicitly cast to int instead.
+
+If you want to avoid loss of precision then put the cast in a proper location,
+for instance::
+
+long f(int x) {
+return (long)x * 1000;
+}
+
+Floating point
+--
+
+Currently warnings are only written for integer conversion. No warning is
+written for this code::
+
+double f(float x) {
+return (double)(x * 10.0f);
+}
Index: docs/clang-tidy/checks/list.rst
===
--- docs/clang-tidy/checks/list.rst
+++ docs/clang-tidy/checks/list.rst
@@ -52,6 +52,7 @@
misc-inefficient-algorithm
misc-macro-parentheses
misc-macro-repeated-side-effects
+   misc-misplaced-widening-cast
misc-move-constructor-init
misc-new-delete-overloads
misc-noexcept-move-constructor
Index: clang-tidy/misc/MisplacedWideningCastCheck.h
===
--- clang-tidy/misc/MisplacedWideningCastCheck.h
+++ clang-tidy/misc/MisplacedWideningCastCheck.h
@@ -0,0 +1,38 @@
+//===--- MisplacedWideningCastCheck.h - clang-tidy---*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//

Re: [PATCH] D16310: new clang-tidy checker misc-long-cast

[Daniel Marjamäki via cfe-commits]

danielmarjamaki added inline comments.


Comment at: clang-tidy/misc/MisplacedWideningCastCheck.cpp:79
@@ +78,3 @@
+
+void MisplacedWideningCastCheck::check(const MatchFinder::MatchResult ) 
{
+  const auto *Cast = Result.Nodes.getNodeAs("Cast");

I looked in another checker , that did not have a condition nor assert so I 
removed it.


Comment at: clang-tidy/misc/MisplacedWideningCastCheck.h:17
@@ +16,3 @@
+namespace tidy {
+namespace misc {
+

I have rerun add_new_check.py for my latest patch.


Comment at: docs/clang-tidy/checks/misc-misplaced-widening-cast.rst:5
@@ +4,3 @@
+
+
+This check will warn when there is a explicit redundant cast of a calculation

yes good catch.


http://reviews.llvm.org/D16310



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

Re: r260077 - [OPENMP 4.5] Ccapture/codegen of private non-static data members.

[NAKAMURA Takumi via cfe-commits]

Thanks. It didn't pass with i686-mingw32.

  // LAMBDA: call
  // LAMBDA: call{{.*}} void [[OUTER_LAMBDA:@.+]](

  call x86_thiscallcc void @_ZN2SSC1ERi(%struct.SS* %ss, i32*
dereferenceable(4) @_ZZ4mainE5sivar)
  call x86_thiscallcc void @"_ZZ4mainENK3$_0clEv"(%class.anon* %temp.lvalue)

The latter LAMBDA hit "callcc void @_ZN2SSC1ERi("

Fixed in r260093.

I suggest like;
  // LAMBDA: call{{.*}} void [[OUTER_LAMBDA:@.+]](%class.anon*

On Mon, Feb 8, 2016 at 10:02 PM Alexey Bataev  wrote:

> Yes, I know, will be fixed in few minutes
>
> Best regards,
> Alexey Bataev
> =
> Software Engineer
> Intel Compiler Team
>
> 08.02.2016 15:43, NAKAMURA Takumi пишет:
>
> The test is incompatible to i686-pc-win32. See also
> http://bb.pgr.jp/builders/ninja-clang-i686-msc18-R/builds/5498
>
> On Mon, Feb 8, 2016 at 6:33 PM Alexey Bataev via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: abataev
>> Date: Mon Feb  8 03:29:13 2016
>> New Revision: 260077
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=260077=rev
>> Log:
>> [OPENMP 4.5] Ccapture/codegen of private non-static data members.
>> OpenMP 4.5 introduces privatization of non-static data members of current
>> class in non-static member functions.
>> To correctly handle such kind of privatization a new (pseudo)declaration
>> VarDecl-based node is added. It allows to reuse an existing code for
>> capturing variables in Lambdas/Block/Captured blocks of code for correct
>> privatization and codegen.
>>
>> Modified:
>> cfe/trunk/include/clang/AST/DeclOpenMP.h
>> cfe/trunk/include/clang/AST/RecursiveASTVisitor.h
>> cfe/trunk/include/clang/Basic/DeclNodes.td
>> cfe/trunk/include/clang/Sema/Sema.h
>> cfe/trunk/include/clang/Serialization/ASTBitCodes.h
>> cfe/trunk/lib/AST/DeclBase.cpp
>> cfe/trunk/lib/AST/DeclOpenMP.cpp
>> cfe/trunk/lib/AST/DeclPrinter.cpp
>> cfe/trunk/lib/AST/StmtPrinter.cpp
>> cfe/trunk/lib/CodeGen/CGDecl.cpp
>> cfe/trunk/lib/Sema/SemaExpr.cpp
>> cfe/trunk/lib/Sema/SemaExprMember.cpp
>> cfe/trunk/lib/Sema/SemaOpenMP.cpp
>> cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp
>> cfe/trunk/lib/Serialization/ASTCommon.cpp
>> cfe/trunk/lib/Serialization/ASTReaderDecl.cpp
>> cfe/trunk/lib/Serialization/ASTWriterDecl.cpp
>> cfe/trunk/test/OpenMP/parallel_private_codegen.cpp
>> cfe/trunk/tools/libclang/CIndex.cpp
>>
>> Modified: cfe/trunk/include/clang/AST/DeclOpenMP.h
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/DeclOpenMP.h?rev=260077=260076=260077=diff
>>
>> ==
>> --- cfe/trunk/include/clang/AST/DeclOpenMP.h (original)
>> +++ cfe/trunk/include/clang/AST/DeclOpenMP.h Mon Feb  8 03:29:13 2016
>> @@ -87,6 +87,35 @@ public:
>>static bool classofKind(Kind K) { return K == OMPThreadPrivate; }
>>  };
>>
>> -}  // end namespace clang
>> +/// Pseudo declaration for capturing of non-static data members in
>> non-static
>> +/// member functions.
>> +///
>> +/// Clang supports capturing of variables only, but OpenMP 4.5 allows to
>> +/// privatize non-static members of current class in non-static member
>> +/// functions. This pseudo-declaration allows properly handle this kind
>> of
>> +/// capture by wrapping captured expression into a variable-like
>> declaration.
>> +class OMPCapturedFieldDecl final : public VarDecl {
>> +  friend class ASTDeclReader;
>> +  void anchor() override;
>> +
>> +  OMPCapturedFieldDecl(ASTContext , DeclContext *DC, IdentifierInfo
>> *Id,
>> +   QualType Type)
>> +  : VarDecl(OMPCapturedField, C, DC, SourceLocation(),
>> SourceLocation(), Id,
>> +Type, nullptr, SC_None) {
>> +setImplicit();
>> +  }
>> +
>> +public:
>> +  static OMPCapturedFieldDecl *Create(ASTContext , DeclContext *DC,
>> +  IdentifierInfo *Id, QualType T);
>> +
>> +  static OMPCapturedFieldDecl *CreateDeserialized(ASTContext ,
>> unsigned ID);
>> +
>> +  // Implement isa/cast/dyncast/etc.
>> +  static bool classof(const Decl *D) { return classofKind(D->getKind());
>> }
>> +  static bool classofKind(Kind K) { return K == OMPCapturedField; }
>> +};
>> +
>> +} // end namespace clang
>>
>>  #endif
>>
>> Modified: cfe/trunk/include/clang/AST/RecursiveASTVisitor.h
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/RecursiveASTVisitor.h?rev=260077=260076=260077=diff
>>
>> ==
>> --- cfe/trunk/include/clang/AST/RecursiveASTVisitor.h (original)
>> +++ cfe/trunk/include/clang/AST/RecursiveASTVisitor.h Mon Feb  8 03:29:13
>> 2016
>> @@ -1434,6 +1434,8 @@ DEF_TRAVERSE_DECL(OMPThreadPrivateDecl,
>>}
>>  })
>>
>> +DEF_TRAVERSE_DECL(OMPCapturedFieldDecl, { TRY_TO(TraverseVarHelper(D));
>> })
>> +
>>  // A helper method for TemplateDecl's children.
>>  template 
>>  bool 

[clang-tools-extra] r260096 - Expand the simplify boolean expression check to handle implicit conversion of integral types to bool and improve the handling of implicit conversion of member pointers to

[Aaron Ballman via cfe-commits]

Author: aaronballman
Date: Mon Feb  8 08:25:25 2016
New Revision: 260096

URL: http://llvm.org/viewvc/llvm-project?rev=260096=rev
Log:
Expand the simplify boolean expression check to handle implicit conversion of 
integral types to bool and improve the handling of implicit conversion of 
member pointers to bool.

Implicit conversion of member pointers are replaced with explicit comparisons 
to nullptr.

Implicit conversions of integral types are replaced with explicit comparisons 
to 0.

Patch by Richard Thomson.

Modified:
clang-tools-extra/trunk/clang-tidy/readability/SimplifyBooleanExprCheck.cpp
clang-tools-extra/trunk/clang-tidy/readability/SimplifyBooleanExprCheck.h

clang-tools-extra/trunk/docs/clang-tidy/checks/readability-simplify-boolean-expr.rst
clang-tools-extra/trunk/test/clang-tidy/readability-simplify-bool-expr.cpp

Modified: 
clang-tools-extra/trunk/clang-tidy/readability/SimplifyBooleanExprCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/readability/SimplifyBooleanExprCheck.cpp?rev=260096=260095=260096=diff
==
--- clang-tools-extra/trunk/clang-tidy/readability/SimplifyBooleanExprCheck.cpp 
(original)
+++ clang-tools-extra/trunk/clang-tidy/readability/SimplifyBooleanExprCheck.cpp 
Mon Feb  8 08:25:25 2016
@@ -85,10 +85,11 @@ bool needsParensAfterUnaryNegation(const
   E = E->IgnoreImpCasts();
   if (isa(E) || isa(E))
 return true;
-  if (const auto *Op = dyn_cast(E)) {
+
+  if (const auto *Op = dyn_cast(E))
 return Op->getNumArgs() == 2 && Op->getOperator() != OO_Call &&
Op->getOperator() != OO_Subscript;
-  }
+
   return false;
 }
 
@@ -107,12 +108,8 @@ StringRef negatedOperator(const BinaryOp
 }
 
 std::pair OperatorNames[] = {
-{OO_EqualEqual, "=="},
-{OO_ExclaimEqual, "!="},
-{OO_Less, "<"},
-{OO_GreaterEqual, ">="},
-{OO_Greater, ">"},
-{OO_LessEqual, "<="}};
+{OO_EqualEqual, "=="},   {OO_ExclaimEqual, "!="}, {OO_Less, "<"},
+{OO_GreaterEqual, ">="}, {OO_Greater, ">"},   {OO_LessEqual, "<="}};
 
 StringRef getOperatorName(OverloadedOperatorKind OpKind) {
   for (auto Name : OperatorNames) {
@@ -148,7 +145,15 @@ std::string asBool(StringRef text, bool
 
 bool needsNullPtrComparison(const Expr *E) {
   if (const auto *ImpCast = dyn_cast(E))
-return ImpCast->getCastKind() == CK_PointerToBoolean;
+return ImpCast->getCastKind() == CK_PointerToBoolean ||
+   ImpCast->getCastKind() == CK_MemberPointerToBoolean;
+
+  return false;
+}
+
+bool needsZeroComparison(const Expr *E) {
+  if (const auto *ImpCast = dyn_cast(E))
+return ImpCast->getCastKind() == CK_IntegralToBoolean;
 
   return false;
 }
@@ -172,6 +177,27 @@ bool needsStaticCast(const Expr *E) {
   return !E->getType()->isBooleanType();
 }
 
+std::string compareExpressionToConstant(const MatchFinder::MatchResult ,
+const Expr *E, bool Negated,
+const char *Constant) {
+  E = E->IgnoreImpCasts();
+  Twine ExprText = isa(E) ? ("(" + getText(Result, *E) + ")")
+  : getText(Result, *E);
+  return (ExprText + " " + (Negated ? "!=" : "==") + " " + Constant).str();
+}
+
+std::string compareExpressionToNullPtr(const MatchFinder::MatchResult ,
+   const Expr *E, bool Negated) {
+  const char *NullPtr =
+  Result.Context->getLangOpts().CPlusPlus11 ? "nullptr" : "NULL";
+  return compareExpressionToConstant(Result, E, Negated, NullPtr);
+}
+
+std::string compareExpressionToZero(const MatchFinder::MatchResult ,
+const Expr *E, bool Negated) {
+  return compareExpressionToConstant(Result, E, Negated, "0");
+}
+
 std::string replacementExpression(const MatchFinder::MatchResult ,
   bool Negated, const Expr *E) {
   E = E->ignoreParenBaseCasts();
@@ -180,14 +206,20 @@ std::string replacementExpression(const
 if (const auto *UnOp = dyn_cast(E)) {
   if (UnOp->getOpcode() == UO_LNot) {
 if (needsNullPtrComparison(UnOp->getSubExpr()))
-  return (getText(Result, *UnOp->getSubExpr()) + " != nullptr").str();
+  return compareExpressionToNullPtr(Result, UnOp->getSubExpr(), true);
+
+if (needsZeroComparison(UnOp->getSubExpr()))
+  return compareExpressionToZero(Result, UnOp->getSubExpr(), true);
 
 return replacementExpression(Result, false, UnOp->getSubExpr());
   }
 }
 
 if (needsNullPtrComparison(E))
-  return (getText(Result, *E) + " == nullptr").str();
+  return compareExpressionToNullPtr(Result, E, false);
+
+if (needsZeroComparison(E))
+  return compareExpressionToZero(Result, E, false);
 
 StringRef NegatedOperator;
 const Expr *LHS = nullptr;
@@ -203,18 +235,21 @@ std::string 

Re: r259985 - Re-apply r259977 - [OpenMP] Reorganize code to allow specialized code generation for different devices.

[Samuel F Antao via cfe-commits]

No worries, sure, I'll do that.

Thanks!
Samuel



From:   Renato Golin 
To: Samuel F Antao/Watson/IBM@IBMUS
Cc: Clang Commits 
Date:   02/08/2016 09:57 AM
Subject:Re: r259985 - Re-apply r259977 - [OpenMP] Reorganize code to
allow specialized code generation for different devices.



On 7 February 2016 at 17:29, Samuel F Antao  wrote:
  Hi Renato,

  This is not related with my patch, I'm afraid your buildbot won't go
  green with the revert. This looks to be related with r259976. My patch
  triggered the problem because it touched a CmakeList.txt. The code itself
  is completely unrelated with the failure.



Hi Samuel,

You are correct, I apologise. Nico has disabled the test (r260056) which
made the bot green again (obviously).

Maybe you can re-apply your patch now?

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

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[Jonathan Wakely via cfe-commits]

On 8 February 2016 at 13:54, H.J. Lu  wrote:
> On Sun, Feb 7, 2016 at 12:52 PM, H.J. Lu  wrote:
>
> The standard-layout POD is well defined:
>
> https://en.wikipedia.org/wiki/C%2B%2B11#Modification_to_the_definition_of_plain_old_data
>
> Here is the updated proposal for  Intel386, x86-64 and IA MCU psABIs:
>
> 1. "collection".  A collection is a structure, union or C++ class.

These are all "class types". Why invent a new term?

> 2. "empty collection".  An empty collection is:
>a. A collection without member.  Or

What about base classes?

What about bit-fields of length 0?

>b. A collection with only empty collections.  Or

What does "with" mean? Only members, or bases too?

>c. An array of empty collections.
> 3. "empty record".  An empty record is Plain Old Data (POD) for the purpose
>of standard-layout and

"For the purposes of standard-layout" doesn't mean anything.

A type is a standard-layout type, or it isn't.

Do you mean "An empty record is a standard-layout type and..."

>a. A collection without member.  Or
>b. A collection with only empty collections.

?



The C++ standard defines the std::is_empty trait as true when:
"T is a class type, but not a union type, with no non-static data
members other than bit-fields of length 0, no virtual member
functions, no virtual base classes, and no base class B for which
is_empty::value is false."



> 4. No memory slot nor register should be used to pass or return an object of
> empty record.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r260077 - [OPENMP 4.5] Ccapture/codegen of private non-static data members.

[Alexey Bataev via cfe-commits]

Yes, I know, will be fixed in few minutes

Best regards,
Alexey Bataev
=
Software Engineer
Intel Compiler Team

08.02.2016 15:43, NAKAMURA Takumi пишет:
The test is incompatible to i686-pc-win32. See also 
http://bb.pgr.jp/builders/ninja-clang-i686-msc18-R/builds/5498

On Mon, Feb 8, 2016 at 6:33 PM Alexey Bataev via cfe-commits 
> wrote:
Author: abataev
Date: Mon Feb  8 03:29:13 2016
New Revision: 260077

URL: http://llvm.org/viewvc/llvm-project?rev=260077=rev
Log:
[OPENMP 4.5] Ccapture/codegen of private non-static data members.
OpenMP 4.5 introduces privatization of non-static data members of current class 
in non-static member functions.
To correctly handle such kind of privatization a new (pseudo)declaration 
VarDecl-based node is added. It allows to reuse an existing code for capturing 
variables in Lambdas/Block/Captured blocks of code for correct privatization 
and codegen.

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

Modified: cfe/trunk/include/clang/AST/DeclOpenMP.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/DeclOpenMP.h?rev=260077=260076=260077=diff
==
--- cfe/trunk/include/clang/AST/DeclOpenMP.h (original)
+++ cfe/trunk/include/clang/AST/DeclOpenMP.h Mon Feb  8 03:29:13 2016
@@ -87,6 +87,35 @@ public:
   static bool classofKind(Kind K) { return K == OMPThreadPrivate; }
 };

-}  // end namespace clang
+/// Pseudo declaration for capturing of non-static data members in non-static
+/// member functions.
+///
+/// Clang supports capturing of variables only, but OpenMP 4.5 allows to
+/// privatize non-static members of current class in non-static member
+/// functions. This pseudo-declaration allows properly handle this kind of
+/// capture by wrapping captured expression into a variable-like declaration.
+class OMPCapturedFieldDecl final : public VarDecl {
+  friend class ASTDeclReader;
+  void anchor() override;
+
+  OMPCapturedFieldDecl(ASTContext , DeclContext *DC, IdentifierInfo *Id,
+   QualType Type)
+  : VarDecl(OMPCapturedField, C, DC, SourceLocation(), SourceLocation(), 
Id,
+Type, nullptr, SC_None) {
+setImplicit();
+  }
+
+public:
+  static OMPCapturedFieldDecl *Create(ASTContext , DeclContext *DC,
+  IdentifierInfo *Id, QualType T);
+
+  static OMPCapturedFieldDecl *CreateDeserialized(ASTContext , unsigned ID);
+
+  // Implement isa/cast/dyncast/etc.
+  static bool classof(const Decl *D) { return classofKind(D->getKind()); }
+  static bool classofKind(Kind K) { return K == OMPCapturedField; }
+};
+
+} // end namespace clang

 #endif

Modified: cfe/trunk/include/clang/AST/RecursiveASTVisitor.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/RecursiveASTVisitor.h?rev=260077=260076=260077=diff
==
--- cfe/trunk/include/clang/AST/RecursiveASTVisitor.h (original)
+++ cfe/trunk/include/clang/AST/RecursiveASTVisitor.h Mon Feb  8 03:29:13 2016
@@ -1434,6 +1434,8 @@ DEF_TRAVERSE_DECL(OMPThreadPrivateDecl,
   }
 })

+DEF_TRAVERSE_DECL(OMPCapturedFieldDecl, { TRY_TO(TraverseVarHelper(D)); })
+
 // A helper method for TemplateDecl's children.
 template 
 bool RecursiveASTVisitor::TraverseTemplateParameterListHelper(

Modified: cfe/trunk/include/clang/Basic/DeclNodes.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DeclNodes.td?rev=260077=260076=260077=diff
==
--- cfe/trunk/include/clang/Basic/DeclNodes.td (original)
+++ cfe/trunk/include/clang/Basic/DeclNodes.td Mon Feb  8 03:29:13 2016
@@ -51,6 +51,7 @@ def Named : Decl<1>;
 : DDecl;
 def ImplicitParam : DDecl;
 def ParmVar : DDecl;
+def OMPCapturedField : DDecl;
   def NonTypeTemplateParm : DDecl;
   def Template : DDecl;
 def RedeclarableTemplate : DDecl;

Modified: cfe/trunk/include/clang/Sema/Sema.h
URL: 

Re: [PATCH] D16310: new clang-tidy checker misc-long-cast

[Daniel Marjamäki via cfe-commits]

danielmarjamaki updated this revision to Diff 47181.
danielmarjamaki added a comment.

Fixes according to review comments.


http://reviews.llvm.org/D16310

Files:
  clang-tidy/misc/CMakeLists.txt
  clang-tidy/misc/MiscTidyModule.cpp
  clang-tidy/misc/MisplacedWideningCastCheck.cpp
  clang-tidy/misc/MisplacedWideningCastCheck.h
  docs/clang-tidy/checks/list.rst
  docs/clang-tidy/checks/misc-misplaced-widening-cast.rst
  test/clang-tidy/misc-misplaced-widening-cast.cpp

Index: test/clang-tidy/misc-misplaced-widening-cast.cpp
===
--- test/clang-tidy/misc-misplaced-widening-cast.cpp
+++ test/clang-tidy/misc-misplaced-widening-cast.cpp
@@ -0,0 +1,64 @@
+// RUN: %check_clang_tidy %s misc-misplaced-widening-cast %t
+
+void assign(int a, int b) {
+  long l;
+
+  l = a * b;
+  l = (long)(a * b);
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: either cast from 'int' to 'long' is ineffective, or there is loss of precision before the conversion [misc-misplaced-widening-cast]
+  l = (long)a * b;
+
+  l = (long)(a << 8);
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: either cast from 'int' to 'long'
+  l = (long)b << 8;
+
+  l = static_cast(a * b);
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: either cast from 'int' to 'long' is ineffective, or there is loss of precision before the conversion [misc-misplaced-widening-cast]
+}
+
+void init(unsigned int n) {
+  long l = (long)(n << 8);
+  // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: either cast from 'unsigned int'
+}
+
+long ret(int a) {
+  return (long)(a * 1000);
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: either cast from 'int' to 'long'
+}
+
+void dontwarn1(unsigned char a, int i, unsigned char *p) {
+  long l;
+  // the result is a 9 bit value, there is no truncation in the implicit cast.
+  l = (long)(a + 15);
+  // the result is a 12 bit value, there is no truncation in the implicit cast.
+  l = (long)(a << 4);
+  // the result is a 3 bit value, there is no truncation in the implicit cast.
+  l = (long)((i%5)+1);
+  // the result is a 16 bit value, there is no truncation in the implicit cast.
+  l = (long)(((*p)<<8) + *(p+1));
+}
+
+template  struct DontWarn2 {
+  void assign(T a, T b) {
+long l;
+l = (long)(a * b);
+  }
+};
+DontWarn2 DW2;
+
+// Cast is not suspicious when casting macro
+#define A  (X<<2)
+long macro1(int X) {
+  return (long)A;
+}
+
+// Don't warn about cast in macro
+#define B(X,Y)   (long)(X*Y)
+long macro2(int x, int y) {
+  return B(x,y);
+}
+
+void floatingpoint(float a, float b) {
+  double d = (double)(a * b); // currently we don't warn for this
+}
+
Index: docs/clang-tidy/checks/misc-misplaced-widening-cast.rst
===
--- docs/clang-tidy/checks/misc-misplaced-widening-cast.rst
+++ docs/clang-tidy/checks/misc-misplaced-widening-cast.rst
@@ -0,0 +1,39 @@
+.. title:: clang-tidy - misc-misplaced-widening-cast
+
+misc-misplaced-widening-cast
+
+
+This check will warn when there is a explicit redundant cast of a calculation
+result to a bigger type. If the intention of the cast is to avoid loss of
+precision then the cast is misplaced, and there can be loss of precision.
+Otherwise the cast is ineffective.
+
+Example code::
+
+long f(int x) {
+return (long)(x*1000);
+}
+
+The result x*1000 is first calculated using int precision. If the result
+exceeds int precision there is loss of precision. Then the result is casted to
+long.
+
+If there is no loss of precision then the cast can be removed or you can
+explicitly cast to int instead.
+
+If you want to avoid loss of precision then put the cast in a proper location,
+for instance::
+
+long f(int x) {
+return (long)x * 1000;
+}
+
+Floating point
+--
+
+Currently warnings are only written for integer conversion. No warning is
+written for this code::
+
+double f(float x) {
+return (double)(x * 10.0f);
+}
Index: docs/clang-tidy/checks/list.rst
===
--- docs/clang-tidy/checks/list.rst
+++ docs/clang-tidy/checks/list.rst
@@ -52,6 +52,7 @@
misc-inefficient-algorithm
misc-macro-parentheses
misc-macro-repeated-side-effects
+   misc-misplaced-widening-cast
misc-move-constructor-init
misc-new-delete-overloads
misc-noexcept-move-constructor
Index: clang-tidy/misc/MisplacedWideningCastCheck.h
===
--- clang-tidy/misc/MisplacedWideningCastCheck.h
+++ clang-tidy/misc/MisplacedWideningCastCheck.h
@@ -0,0 +1,38 @@
+//===--- MisplacedWideningCastCheck.h - clang-tidy---*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//

Re: r259931 - [SystemZ] Define __GCC_HAVE_SYNC_COMPARE_AND_SWAP macros

[Ulrich Weigand via cfe-commits]

Hal Finkel  wrote on 05.02.2016 23:14:54:

> Just a general comment: I believe we've now fixed this bug for at
> least four different architectures (each time as a separate effort).

Yes.  Unfortunately I only noticed that after I'd already spent half
a day debugging the problem from scratch on System Z :-/

> Is there some kind of auditing we could do to make sure we don't run
> into this again?

Well, on GCC common code automatically predefines the macro if and
only if the back end actually implements the corresponding builtin
without an external function call.   We cannot really do that in LLVM
due to the stronger separation between front end and back end here.

However, I guess we could at least provide a *test case* that verifies
that front end and back end make the same choice.  This would have to
be a test case that runs a full compile (from un-preprocessed source
straight through to assembler output) so we can verify the interaction
of front end and back end, which I guess is frowned upon these days ...

The following example implements one idea I came up with:
(See attached file: atomic-predefines.c)

It is neither perfectly complete (it only checks the current target,
not all; and it doesn't check any variants of the current target,
e.g. different CPU types), nor is it perfectly safe (some targets
could theoretically emit weird code to implement a function call
that would throw off the heuristics in this test).

In addition, I noticed when running it against some of the more
obscure targets like Hexagon, the test actually triggers internal
errors in the back end, so those probably ought to be fixed first.

Any suggestions to improve this test welcome!


Bye,
Ulrich


atomic-predefines.c
Description: Binary data
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu via cfe-commits]

On Sun, Feb 7, 2016 at 12:52 PM, H.J. Lu  wrote:
> On Sun, Feb 7, 2016 at 12:48 PM, Florian Weimer  wrote:
>> * H. J. Lu:
>>
 I tested GCC 5.3.1 and Clang 3.5.0.

  GCC  Clang
 s0   non-emptynon-empty
 s1   non-emptyempty
 s2   non-emptyempty
 s3   emptyempty
 s4   emptyempty
 s5   non-emptyempty

 I believe s3, s4, s5 are non-empty according to your rules.  Why put
 both compilers in the wrong?  That doesn't make sense to me.
>>>
>>> Please try testcases in
>>>
>>> https://llvm.org/bugs/show_bug.cgi?id=26337
>>>
>>> with clang on both ia32 and x86-64.  Clang isn't consistent between
>>> ia32 and x86-64.
>>
>> Okay, with -m32, I get non-empty passing for s5 from Clang as well.
>> But I still don't think it makes sense to change the ABI for s3 and
>> s4, and even for s5, the Clang/x86_64 behavior is arguably more
>> correct.
>
> Not really.  For
>
> struct dummy0 { };
> struct dummy { struct dummy0 d[PAD_SIZE]; };
>
> clang changes behavior when PAD_SIZE > 16 on x86-64 and PAD_SIZE > 1
> on ia32.
>
 Jason already indicated he intends GCC to move towards more empty
 arguments, not fewer.

>> How do existing C++ compilers implement empty array members (an
>> extension)?  Does the type of such members affect whether a class is a
>> standard-layout class?

> Are they "POD for the purpose of layout"? If yes, they are covered here.

 The C++ standard does not define this.
>>>
>>> GCC has
>>>
>>> * Nonzero means that this class type is not POD for the purpose of layout
>>>(as defined in the ABI).  This is different from the language's POD.  */
>>> #define CLASSTYPE_NON_LAYOUT_POD_P(NODE) \
>>>
>>> We can use this definition for ia32, x86-64 and IA MCU psABIs.
>>
>> It still has to be spelled out in non-GCC terms, IMHO.
>
> Sure.  Do you care to propose a wording for "POD for the purpose of layout"?
>

The standard-layout POD is well defined:

https://en.wikipedia.org/wiki/C%2B%2B11#Modification_to_the_definition_of_plain_old_data

Here is the updated proposal for  Intel386, x86-64 and IA MCU psABIs:

1. "collection".  A collection is a structure, union or C++ class.
2. "empty collection".  An empty collection is:
   a. A collection without member.  Or
   b. A collection with only empty collections.  Or
   c. An array of empty collections.
3. "empty record".  An empty record is Plain Old Data (POD) for the purpose
   of standard-layout and
   a. A collection without member.  Or
   b. A collection with only empty collections.
4. No memory slot nor register should be used to pass or return an object of
empty record.



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

r260093 - clang/test/OpenMP/parallel_private_codegen.cpp: Fix an expression.

[NAKAMURA Takumi via cfe-commits]

Author: chapuni
Date: Mon Feb  8 08:04:28 2016
New Revision: 260093

URL: http://llvm.org/viewvc/llvm-project?rev=260093=rev
Log:
clang/test/OpenMP/parallel_private_codegen.cpp: Fix an expression.

  call x86_thiscallcc void @_ZN2SSC1ERi(

It matched to:

   x86_this

Modified:
cfe/trunk/test/OpenMP/parallel_private_codegen.cpp

Modified: cfe/trunk/test/OpenMP/parallel_private_codegen.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/OpenMP/parallel_private_codegen.cpp?rev=260093=260092=260093=diff
==
--- cfe/trunk/test/OpenMP/parallel_private_codegen.cpp (original)
+++ cfe/trunk/test/OpenMP/parallel_private_codegen.cpp Mon Feb  8 08:04:28 2016
@@ -99,7 +99,7 @@ int main() {
 #ifdef LAMBDA
   // LAMBDA: [[G:@.+]] = global i{{[0-9]+}} 1212,
   // LAMBDA-LABEL: @main
-  // LAMBDA: call
+  // LAMBDA: call{{.*}} void
   // LAMBDA: call{{.*}} void [[OUTER_LAMBDA:@[^(]+]](
   [&]() {
   // LAMBDA: define{{.*}} internal{{.*}} void [[OUTER_LAMBDA]](


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

Re: r260077 - [OPENMP 4.5] Ccapture/codegen of private non-static data members.

[Alexey Bataev via cfe-commits]

Ok, thanks a lot! Hope it will fix win-based buildbots completely.

Best regards,
Alexey Bataev
=
Software Engineer
Intel Compiler Team

08.02.2016 17:11, NAKAMURA Takumi пишет:
Thanks. It didn't pass with i686-mingw32.

  // LAMBDA: call
  // LAMBDA: call{{.*}} void [[OUTER_LAMBDA:@.+]](

  call x86_thiscallcc void @_ZN2SSC1ERi(%struct.SS* %ss, i32* 
dereferenceable(4) @_ZZ4mainE5sivar)
  call x86_thiscallcc void @"_ZZ4mainENK3$_0clEv"(%class.anon* %temp.lvalue)

The latter LAMBDA hit "callcc void @_ZN2SSC1ERi("

Fixed in r260093.

I suggest like;
  // LAMBDA: call{{.*}} void 
[[OUTER_LAMBDA:@.+]](%class.anon*

On Mon, Feb 8, 2016 at 10:02 PM Alexey Bataev 
> wrote:
Yes, I know, will be fixed in few minutes

Best regards,
Alexey Bataev
=
Software Engineer
Intel Compiler Team

08.02.2016 15:43, NAKAMURA Takumi пишет:
The test is incompatible to i686-pc-win32. See also 
http://bb.pgr.jp/builders/ninja-clang-i686-msc18-R/builds/5498

On Mon, Feb 8, 2016 at 6:33 PM Alexey Bataev via cfe-commits 
> wrote:
Author: abataev
Date: Mon Feb  8 03:29:13 2016
New Revision: 260077

URL: http://llvm.org/viewvc/llvm-project?rev=260077=rev
Log:
[OPENMP 4.5] Ccapture/codegen of private non-static data members.
OpenMP 4.5 introduces privatization of non-static data members of current class 
in non-static member functions.
To correctly handle such kind of privatization a new (pseudo)declaration 
VarDecl-based node is added. It allows to reuse an existing code for capturing 
variables in Lambdas/Block/Captured blocks of code for correct privatization 
and codegen.

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

Modified: cfe/trunk/include/clang/AST/DeclOpenMP.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/DeclOpenMP.h?rev=260077=260076=260077=diff
==
--- cfe/trunk/include/clang/AST/DeclOpenMP.h (original)
+++ cfe/trunk/include/clang/AST/DeclOpenMP.h Mon Feb  8 03:29:13 2016
@@ -87,6 +87,35 @@ public:
   static bool classofKind(Kind K) { return K == OMPThreadPrivate; }
 };

-}  // end namespace clang
+/// Pseudo declaration for capturing of non-static data members in non-static
+/// member functions.
+///
+/// Clang supports capturing of variables only, but OpenMP 4.5 allows to
+/// privatize non-static members of current class in non-static member
+/// functions. This pseudo-declaration allows properly handle this kind of
+/// capture by wrapping captured expression into a variable-like declaration.
+class OMPCapturedFieldDecl final : public VarDecl {
+  friend class ASTDeclReader;
+  void anchor() override;
+
+  OMPCapturedFieldDecl(ASTContext , DeclContext *DC, IdentifierInfo *Id,
+   QualType Type)
+  : VarDecl(OMPCapturedField, C, DC, SourceLocation(), SourceLocation(), 
Id,
+Type, nullptr, SC_None) {
+setImplicit();
+  }
+
+public:
+  static OMPCapturedFieldDecl *Create(ASTContext , DeclContext *DC,
+  IdentifierInfo *Id, QualType T);
+
+  static OMPCapturedFieldDecl *CreateDeserialized(ASTContext , unsigned ID);
+
+  // Implement isa/cast/dyncast/etc.
+  static bool classof(const Decl *D) { return classofKind(D->getKind()); }
+  static bool classofKind(Kind K) { return K == OMPCapturedField; }
+};
+
+} // end namespace clang

 #endif

Modified: cfe/trunk/include/clang/AST/RecursiveASTVisitor.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/RecursiveASTVisitor.h?rev=260077=260076=260077=diff
==
--- cfe/trunk/include/clang/AST/RecursiveASTVisitor.h (original)
+++ cfe/trunk/include/clang/AST/RecursiveASTVisitor.h Mon Feb  8 03:29:13 2016
@@ -1434,6 +1434,8 @@ DEF_TRAVERSE_DECL(OMPThreadPrivateDecl,
   }
 })

+DEF_TRAVERSE_DECL(OMPCapturedFieldDecl, { TRY_TO(TraverseVarHelper(D)); })
+
 // A helper method for TemplateDecl's children.
 template 
 bool 

[clang-tools-extra] r260097 - Reverting r260096; it causes build bot failures:

[Aaron Ballman via cfe-commits]

Author: aaronballman
Date: Mon Feb  8 08:37:56 2016
New Revision: 260097

URL: http://llvm.org/viewvc/llvm-project?rev=260097=rev
Log:
Reverting r260096; it causes build bot failures:

http://bb.pgr.jp/builders/cmake-clang-tools-x86_64-linux/builds/23351
http://lab.llvm.org:8011/builders/clang-s390x-linux/builds/492

Modified:
clang-tools-extra/trunk/clang-tidy/readability/SimplifyBooleanExprCheck.cpp
clang-tools-extra/trunk/clang-tidy/readability/SimplifyBooleanExprCheck.h

clang-tools-extra/trunk/docs/clang-tidy/checks/readability-simplify-boolean-expr.rst
clang-tools-extra/trunk/test/clang-tidy/readability-simplify-bool-expr.cpp

Modified: 
clang-tools-extra/trunk/clang-tidy/readability/SimplifyBooleanExprCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/readability/SimplifyBooleanExprCheck.cpp?rev=260097=260096=260097=diff
==
--- clang-tools-extra/trunk/clang-tidy/readability/SimplifyBooleanExprCheck.cpp 
(original)
+++ clang-tools-extra/trunk/clang-tidy/readability/SimplifyBooleanExprCheck.cpp 
Mon Feb  8 08:37:56 2016
@@ -85,11 +85,10 @@ bool needsParensAfterUnaryNegation(const
   E = E->IgnoreImpCasts();
   if (isa(E) || isa(E))
 return true;
-
-  if (const auto *Op = dyn_cast(E))
+  if (const auto *Op = dyn_cast(E)) {
 return Op->getNumArgs() == 2 && Op->getOperator() != OO_Call &&
Op->getOperator() != OO_Subscript;
-
+  }
   return false;
 }
 
@@ -108,8 +107,12 @@ StringRef negatedOperator(const BinaryOp
 }
 
 std::pair OperatorNames[] = {
-{OO_EqualEqual, "=="},   {OO_ExclaimEqual, "!="}, {OO_Less, "<"},
-{OO_GreaterEqual, ">="}, {OO_Greater, ">"},   {OO_LessEqual, "<="}};
+{OO_EqualEqual, "=="},
+{OO_ExclaimEqual, "!="},
+{OO_Less, "<"},
+{OO_GreaterEqual, ">="},
+{OO_Greater, ">"},
+{OO_LessEqual, "<="}};
 
 StringRef getOperatorName(OverloadedOperatorKind OpKind) {
   for (auto Name : OperatorNames) {
@@ -145,15 +148,7 @@ std::string asBool(StringRef text, bool
 
 bool needsNullPtrComparison(const Expr *E) {
   if (const auto *ImpCast = dyn_cast(E))
-return ImpCast->getCastKind() == CK_PointerToBoolean ||
-   ImpCast->getCastKind() == CK_MemberPointerToBoolean;
-
-  return false;
-}
-
-bool needsZeroComparison(const Expr *E) {
-  if (const auto *ImpCast = dyn_cast(E))
-return ImpCast->getCastKind() == CK_IntegralToBoolean;
+return ImpCast->getCastKind() == CK_PointerToBoolean;
 
   return false;
 }
@@ -177,27 +172,6 @@ bool needsStaticCast(const Expr *E) {
   return !E->getType()->isBooleanType();
 }
 
-std::string compareExpressionToConstant(const MatchFinder::MatchResult ,
-const Expr *E, bool Negated,
-const char *Constant) {
-  E = E->IgnoreImpCasts();
-  Twine ExprText = isa(E) ? ("(" + getText(Result, *E) + ")")
-  : getText(Result, *E);
-  return (ExprText + " " + (Negated ? "!=" : "==") + " " + Constant).str();
-}
-
-std::string compareExpressionToNullPtr(const MatchFinder::MatchResult ,
-   const Expr *E, bool Negated) {
-  const char *NullPtr =
-  Result.Context->getLangOpts().CPlusPlus11 ? "nullptr" : "NULL";
-  return compareExpressionToConstant(Result, E, Negated, NullPtr);
-}
-
-std::string compareExpressionToZero(const MatchFinder::MatchResult ,
-const Expr *E, bool Negated) {
-  return compareExpressionToConstant(Result, E, Negated, "0");
-}
-
 std::string replacementExpression(const MatchFinder::MatchResult ,
   bool Negated, const Expr *E) {
   E = E->ignoreParenBaseCasts();
@@ -206,20 +180,14 @@ std::string replacementExpression(const
 if (const auto *UnOp = dyn_cast(E)) {
   if (UnOp->getOpcode() == UO_LNot) {
 if (needsNullPtrComparison(UnOp->getSubExpr()))
-  return compareExpressionToNullPtr(Result, UnOp->getSubExpr(), true);
-
-if (needsZeroComparison(UnOp->getSubExpr()))
-  return compareExpressionToZero(Result, UnOp->getSubExpr(), true);
+  return (getText(Result, *UnOp->getSubExpr()) + " != nullptr").str();
 
 return replacementExpression(Result, false, UnOp->getSubExpr());
   }
 }
 
 if (needsNullPtrComparison(E))
-  return compareExpressionToNullPtr(Result, E, false);
-
-if (needsZeroComparison(E))
-  return compareExpressionToZero(Result, E, false);
+  return (getText(Result, *E) + " == nullptr").str();
 
 StringRef NegatedOperator;
 const Expr *LHS = nullptr;
@@ -235,21 +203,18 @@ std::string replacementExpression(const
 RHS = OpExpr->getArg(1);
   }
 }
-if (!NegatedOperator.empty() && LHS && RHS)
+if (!NegatedOperator.empty() && LHS && RHS) {
   return (asBool((getText(Result, *LHS) + 

[clang-tools-extra] r260100 - [clang-tidy] Reshuffled paragraphs a bit, added contents.

[Alexander Kornienko via cfe-commits]

Author: alexfh
Date: Mon Feb  8 09:09:39 2016
New Revision: 260100

URL: http://llvm.org/viewvc/llvm-project?rev=260100=rev
Log:
[clang-tidy] Reshuffled paragraphs a bit, added contents.

Modified:
clang-tools-extra/trunk/docs/clang-tidy/index.rst

Modified: clang-tools-extra/trunk/docs/clang-tidy/index.rst
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/docs/clang-tidy/index.rst?rev=260100=260099=260100=diff
==
--- clang-tools-extra/trunk/docs/clang-tidy/index.rst (original)
+++ clang-tools-extra/trunk/docs/clang-tidy/index.rst Mon Feb  8 09:09:39 2016
@@ -2,11 +2,14 @@
 Clang-Tidy
 ==
 
+.. contents::
+
+See also:
+
 .. toctree::
:maxdepth: 1
 
-   checks/list
-
+   The list of clang-tidy checks 
 
 :program:`clang-tidy` is a clang-based C++ linter tool. Its purpose is to
 provide an extensible framework for diagnosing and fixing typical programming
@@ -229,26 +232,29 @@ checks, but its power is in the ability
 Checks are organized in modules, which can be linked into :program:`clang-tidy`
 with minimal or no code changes in clang-tidy.
 
-``add_new_check.py`` is a script to automate the process of adding a new check,
-it will create the check, update the CMake file and create a test.
-
-``rename_check.py`` does what the script name suggest, renames an existsing
-check.
-
-Checks can plug the analysis on the preprocessor level using `PPCallbacks`_ or
-on the AST level using `AST Matchers`_. When an error is found, checks can
+Checks can plug into the analysis on the preprocessor level using 
`PPCallbacks`_
+or on the AST level using `AST Matchers`_. When an error is found, checks can
 report them in a way similar to how Clang diagnostics work. A fix-it hint can 
be
 attached to a diagnostic message.
 
-To find out what matchers you can add, we recommend using 
:program:`clang-query`,
-it's a tool is for interactive exploration of the Clang AST using AST matchers.
-
 The interface provided by clang-tidy makes it easy to write useful and precise
 checks in just a few lines of code. If you have an idea for a good check, the
 rest of this document explains how to do this.
 
+There are a few tools particularly useful when developing clang-tidy checks:
+  * ``add_new_check.py`` is a script to automate the process of adding a new
+check, it will create the check, update the CMake file and create a test;
+  * ``rename_check.py`` does what the script name suggest, renames an existsing
+check;
+  * :program:`clang-query` is invaluable for interactive prototyping of AST
+matchers and exploration of the Clang AST;
+  * `clang-check`_ with the ``-ast-dump`` (and optionally ``-ast-dump-filter``)
+provides a convenient way to dump AST of a C++ program.
+
+
 .. _AST Matchers: http://clang.llvm.org/docs/LibASTMatchers.html
 .. _PPCallbacks: http://clang.llvm.org/doxygen/classclang_1_1PPCallbacks.html
+.. _clang-check: http://clang.llvm.org/docs/ClangCheck.html
 
 
 Choosing the Right Place for your Check


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

[clang-tools-extra] r260099 - [clang-tidy] Fix an error in .rst

[Alexander Kornienko via cfe-commits]

Author: alexfh
Date: Mon Feb  8 09:09:34 2016
New Revision: 260099

URL: http://llvm.org/viewvc/llvm-project?rev=260099=rev
Log:
[clang-tidy] Fix an error in .rst

Modified:
clang-tools-extra/trunk/docs/clang-tidy/checks/misc-incorrect-roundings.rst

Modified: 
clang-tools-extra/trunk/docs/clang-tidy/checks/misc-incorrect-roundings.rst
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/docs/clang-tidy/checks/misc-incorrect-roundings.rst?rev=260099=260098=260099=diff
==
--- clang-tools-extra/trunk/docs/clang-tidy/checks/misc-incorrect-roundings.rst 
(original)
+++ clang-tools-extra/trunk/docs/clang-tidy/checks/misc-incorrect-roundings.rst 
Mon Feb  8 09:09:34 2016
@@ -2,8 +2,10 @@ misc-incorrect-roundings
 
 
 Checks the usage of patterns known to produce incorrect rounding.
-Programmers often use
-  (int)(double_expression + 0.5)
+Programmers often use::
+
+   (int)(double_expression + 0.5)
+
 to round the double expression to an integer. The problem with this:
 
 1. It is unnecessarily slow.


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

Re: [PATCH]: git-clang-format

[Alexander Shukaev via cfe-commits]

On 02/08/2016 12:32 PM, Manuel Klimek wrote:

I believe you forgot to add cfe-commits as subscriber on the patch.

On Sun, Feb 7, 2016 at 12:51 PM Alexander Shukaev <
cl...@alexander.shukaev.name> wrote:


On 12/14/2015 10:03 PM, Alexander Shukaev wrote:

On 12/11/2015 04:40 PM, Daniel Jasper wrote:

Please submit patches to clang-format to reviews.llvm.org. Also, any
change
no matter how easy it is to deduce from the code itself deserves a

proper

change description :-). Bullet points are fine.


Thanks for the quick reply.  I've submitted the patch for review [1] as
requested.  Just let me know if anything else is needed.

Regards,
Alexander

[1] http://reviews.llvm.org/D15465


Hello,

I am wondering whether I can expect this patch to be reviewed and
included into the upcoming 3.8 release?  I didn't receive any feedback
ever since it was submitted.  Apologies, I don't want to annoy anybody
but seeing no reaction at all within a couple months feels rude.

Kind regards,
Alexander





Ah, I suspected something should be wrong with the submission...  Thanks 
for pointing this out.  Nevertheless, I'm sure that I've added key 
people as reviewers, so they should have had definitely received 
notifications about this patch...  I'm confused now.  Anyway, now I've 
added cfe-commits to subscribers.  I hope this patch still has a chance 
to hit 3.8.


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

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu via cfe-commits]

On Mon, Feb 8, 2016 at 7:59 AM, Jonathan Wakely  wrote:
>>> A type is a standard-layout type, or it isn't.
>>
>> How about "An empty record is standard-layout Plain Old Data (POD)
>> type and ..."?
>
> That's redundant, all POD types are standard-layout types.
>

Apparently, not all standard-layout types are POD types.  GCC has

/* Nonzero means that this class type is not POD for the purpose of layout
   (as defined in the ABI).  This is different from the language's POD.  */
CLASSTYPE_NON_LAYOUT_POD_P

and

/* Nonzero means that this class type is a non-standard-layout class.  */
#define CLASSTYPE_NON_STD_LAYOUT

They aren't the same.

struct A { };
struct B { };
struct C : A, B { };

C is a standard-layout type, but not a standard-layout POD type.

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

r260116 - Fix missing space (NFC)

[Rong Xu via cfe-commits]

Author: xur
Date: Mon Feb  8 12:12:41 2016
New Revision: 260116

URL: http://llvm.org/viewvc/llvm-project?rev=260116=rev
Log:
Fix missing space (NFC)

Fixed the inconsistently placed : (missing space) introduced in in r259811.




Modified:
cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
cfe/trunk/include/clang/Driver/CC1Options.td

Modified: cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td?rev=260116=260115=260116=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td Mon Feb  8 12:12:41 
2016
@@ -27,7 +27,7 @@ def err_drv_invalid_thread_model_for_tar
   "invalid thread model '%0' in '%1' for this target">;
 def err_drv_invalid_linker_name : Error<
   "invalid linker name in argument '%0'">;
-def err_drv_invalid_pgo_instrumentor: Error<
+def err_drv_invalid_pgo_instrumentor : Error<
   "invalid PGO instrumentor in argument '%0'">;
 def err_drv_invalid_rtlib_name : Error<
   "invalid runtime library name in argument '%0'">;

Modified: cfe/trunk/include/clang/Driver/CC1Options.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/CC1Options.td?rev=260116=260115=260116=diff
==
--- cfe/trunk/include/clang/Driver/CC1Options.td (original)
+++ cfe/trunk/include/clang/Driver/CC1Options.td Mon Feb  8 12:12:41 2016
@@ -270,10 +270,10 @@ def fsanitize_coverage_trace_cmp
 def fsanitize_coverage_8bit_counters
 : Flag<["-"], "fsanitize-coverage-8bit-counters">,
   HelpText<"Enable frequency counters in sanitizer coverage">;
-def fprofile_instrument_EQ: Joined<["-"], "fprofile-instrument=">,
+def fprofile_instrument_EQ : Joined<["-"], "fprofile-instrument=">,
 HelpText<"Enable PGO instrumentation. The accepted values is clang or "
  "none">;
-def fprofile_instrument_path_EQ: Joined<["-"], "fprofile-instrument-path=">,
+def fprofile_instrument_path_EQ : Joined<["-"], "fprofile-instrument-path=">,
 HelpText<"Generate instrumented code to collect execution counts into "
  " (overridden by LLVM_PROFILE_FILE env var)">;
 


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

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[Jonathan Wakely via cfe-commits]

On 8 February 2016 at 18:26, Jonathan Wakely  wrote:
> On 8 February 2016 at 17:58, H.J. Lu wrote:
>> On Mon, Feb 8, 2016 at 7:59 AM, Jonathan Wakely  
>> wrote:
> A type is a standard-layout type, or it isn't.

 How about "An empty record is standard-layout Plain Old Data (POD)
 type and ..."?
>>>
>>> That's redundant, all POD types are standard-layout types.
>>>
>>
>> Apparently, not all standard-layout types are POD types.  GCC has
>>
>> /* Nonzero means that this class type is not POD for the purpose of layout
>>(as defined in the ABI).  This is different from the language's POD.  */
>> CLASSTYPE_NON_LAYOUT_POD_P
>>
>> and
>>
>> /* Nonzero means that this class type is a non-standard-layout class.  */
>> #define CLASSTYPE_NON_STD_LAYOUT
>>
>> They aren't the same.
>>
>> struct A { };
>> struct B { };
>> struct C : A, B { };
>>
>> C is a standard-layout type, but not a standard-layout POD type.
>
> As the comment says, "POD for the purposes of layout" is different
> from the language's POD. All standard-layout types are POD types
> according to the language.
>
> So when you previously had "POD for the purposes of layout" that was
> at least partially clear that you meant something other than what the
> language means. But as pointed out, using a GCC-specific term is not
> ideal.
>
> When you changed it to "POD for the purpose of standard-layout" that
> became a completely meaningless term. Where is that defined?
>
> Your next suggestion was "standard-layout Plain Old Data (POD)" which
> is even worse, now you're using two terms defined by the C++ language,
> but you mean something different.
>
> When you mean something that is the same as the language (like "class
> type") it makes sense to use the same term.
>
> When you mean something that is not the same as the language (like
> "POD") it makes sense to use a different term, or clearly define how
> you are using it.

To be clear: it's really confusing to take two terms defined by the
language, "POD" and "standard-layout", and smash them together to mean
something new.

According to your proposal, struct C is a POD type, and  a
standard-layout type, but not a "standard-layout POD type". That's
just crazy.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[Jonathan Wakely via cfe-commits]

On 8 February 2016 at 18:31, H.J. Lu  wrote:
> On Mon, Feb 8, 2016 at 10:30 AM, Jonathan Wakely  
> wrote:
>> On 8 February 2016 at 18:26, Jonathan Wakely  wrote:
>>> On 8 February 2016 at 17:58, H.J. Lu wrote:
 On Mon, Feb 8, 2016 at 7:59 AM, Jonathan Wakely  
 wrote:
>>> A type is a standard-layout type, or it isn't.
>>
>> How about "An empty record is standard-layout Plain Old Data (POD)
>> type and ..."?
>
> That's redundant, all POD types are standard-layout types.
>

 Apparently, not all standard-layout types are POD types.  GCC has

 /* Nonzero means that this class type is not POD for the purpose of layout
(as defined in the ABI).  This is different from the language's POD.  */
 CLASSTYPE_NON_LAYOUT_POD_P

 and

 /* Nonzero means that this class type is a non-standard-layout class.  */
 #define CLASSTYPE_NON_STD_LAYOUT

 They aren't the same.

 struct A { };
 struct B { };
 struct C : A, B { };

 C is a standard-layout type, but not a standard-layout POD type.
>>>
>>> As the comment says, "POD for the purposes of layout" is different
>>> from the language's POD. All standard-layout types are POD types
>>> according to the language.
>>>
>>> So when you previously had "POD for the purposes of layout" that was
>>> at least partially clear that you meant something other than what the
>>> language means. But as pointed out, using a GCC-specific term is not
>>> ideal.
>>>
>>> When you changed it to "POD for the purpose of standard-layout" that
>>> became a completely meaningless term. Where is that defined?
>>>
>>> Your next suggestion was "standard-layout Plain Old Data (POD)" which
>>> is even worse, now you're using two terms defined by the C++ language,
>>> but you mean something different.
>>>
>>> When you mean something that is the same as the language (like "class
>>> type") it makes sense to use the same term.
>>>
>>> When you mean something that is not the same as the language (like
>>> "POD") it makes sense to use a different term, or clearly define how
>>> you are using it.
>>
>> To be clear: it's really confusing to take two terms defined by the
>> language, "POD" and "standard-layout", and smash them together to mean
>> something new.
>>
>> According to your proposal, struct C is a POD type, and  a
>> standard-layout type, but not a "standard-layout POD type". That's
>> just crazy.
>
> Can you suggest a better wording?

I don't know what the definition of "POD for the purposes of layout"
is, but if I was trying to define a better name for it I would start
by trying to understand how it is specified, instead of just throwing
existing terms together.


> Another issue, if I define
>
> 1. "class type".  A class type is a structure, union or C++ class.
> 2. "empty class type".  An empty class type is:
>a. A class type without member.  Or
>b. A class type with only members of empty class types.  Or
>c. An array of empty class types.
> ^
>
> Will it confuse people?

Yes :-)

But that was already confusing when you called it an "empty
collection" because an array isn't a collection.

If I understand correctly, your proposal says that given:

struct A { };  // empty class type
typedef A A2[2];  // array of empty class types

struct B { A a[2]; };  // empty record?

struct B is an empty record ... is that right?
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libcxx] r260115 - Clean up a test; get rid of hard-wired char/wchar_t code for template fns that take any char type. Prep work for PR#26503

[Marshall Clow via cfe-commits]

Author: marshall
Date: Mon Feb  8 11:38:23 2016
New Revision: 260115

URL: http://llvm.org/viewvc/llvm-project?rev=260115=rev
Log:
Clean up a test; get rid of hard-wired char/wchar_t code for template fns that 
take any char type. Prep work for PR#26503

Modified:

libcxx/trunk/test/std/input.output/iostream.format/quoted.manip/quoted.pass.cpp

Modified: 
libcxx/trunk/test/std/input.output/iostream.format/quoted.manip/quoted.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/input.output/iostream.format/quoted.manip/quoted.pass.cpp?rev=260115=260114=260115=diff
==
--- 
libcxx/trunk/test/std/input.output/iostream.format/quoted.manip/quoted.pass.cpp 
(original)
+++ 
libcxx/trunk/test/std/input.output/iostream.format/quoted.manip/quoted.pass.cpp 
Mon Feb  8 11:38:23 2016
@@ -16,79 +16,95 @@
 #include 
 #include 
 
-#if _LIBCPP_STD_VER > 11
-
-bool is_skipws ( const std::istream *is ) {
-return ( is->flags() & std::ios_base::skipws ) != 0;
-}
+#include "test_macros.h"
 
+#if TEST_STD_VER > 11
 
-bool is_skipws ( const std::wistream *is ) {
-return ( is->flags() & std::ios_base::skipws ) != 0;
+template 
+bool is_skipws ( const std::basic_istream& is ) {
+return ( is.flags() & std::ios_base::skipws ) != 0;
 }
 
-void both_ways ( const char *p ) {
-std::string str(p);
+template >
+void both_ways ( const CharT *p ) {
+std::basic_string str(p);
 auto q = std::quoted(str);
 
-std::stringstream ss;
-bool skippingws = is_skipws (  );
+std::basic_stringstream ss;
+bool skippingws = is_skipws ( ss );
 ss << q;
 ss >> q;
 }
 
-void round_trip ( const char *p ) {
-std::stringstream ss;
-bool skippingws = is_skipws (  );
+template >
+void round_trip ( const CharT *p ) {
+std::basic_stringstream ss;
+bool skippingws = is_skipws ( ss );
+
 ss << std::quoted(p);
-std::string s;
+std::basic_string s;
 ss >> std::quoted(s);
 assert ( s == p );
-assert ( skippingws == is_skipws (  ));
+assert ( skippingws == is_skipws ( ss ));
 }
 
-void round_trip_ws ( const char *p ) {
-std::stringstream ss;
+
+template >
+void round_trip_ws ( const CharT *p ) {
+std::basic_stringstream ss;
 std::noskipws ( ss );
-bool skippingws = is_skipws (  );
+bool skippingws = is_skipws ( ss );
+
 ss << std::quoted(p);
-std::string s;
+std::basic_string s;
 ss >> std::quoted(s);
 assert ( s == p );
-assert ( skippingws == is_skipws (  ));
+assert ( skippingws == is_skipws ( ss ));
 }
 
-void round_trip_d ( const char *p, char delim ) {
-std::stringstream ss;
-ss << std::quoted(p, delim);
-std::string s;
-ss >> std::quoted(s, delim);
+template >
+void round_trip_d ( const CharT *p, char delim ) {
+std::basic_stringstream ss;
+CharT d{delim};
+
+ss << std::quoted(p, d);
+std::basic_string s;
+ss >> std::quoted(s, d);
 assert ( s == p );
 }
 
-void round_trip_e ( const char *p, char escape ) {
-std::stringstream ss;
-ss << std::quoted(p, '"', escape );
-std::string s;
-ss >> std::quoted(s, '"', escape );
+template >
+void round_trip_e ( const CharT *p, char escape ) {
+std::basic_stringstream ss;
+CharT e{escape};
+
+ss << std::quoted(p, CharT('"'), e );
+std::basic_string s;
+ss >> std::quoted(s, CharT('"'), e );
 assert ( s == p );
 }
 
 
-
-std::string quote ( const char *p, char delim='"', char escape='\\' ) {
-std::stringstream ss;
-ss << std::quoted(p, delim, escape);
-std::string s;
+template >
+std::basic_string quote ( const CharT *p, char delim='"', char 
escape='\\' ) {
+std::basic_stringstream ss;
+CharT d{delim};
+CharT e{escape};
+ss << std::quoted(p, d, e);
+std::basic_string s;
 ss >> s;// no quote
 return s;
 }
 
-std::string unquote ( const char *p, char delim='"', char escape='\\' ) {
-std::stringstream ss;
+template >
+std::basic_string unquote ( const CharT *p, char delim='"', 
char escape='\\' ) {
+std::basic_stringstream ss;
 ss << p;
-std::string s;
-ss >> std::quoted(s, delim, escape);
+
+CharT d{delim};
+CharT e{escape};
+std::basic_string s;
+ss >> std::quoted(s, d, e);
 return s;
 }
 
@@ -107,61 +123,6 @@ void test_padding () {
 }
 
 
-void round_trip ( const wchar_t *p ) {
-std::wstringstream ss;
-bool skippingws = is_skipws (  );
-ss << std::quoted(p);
-std::wstring s;
-ss >> std::quoted(s);
-assert ( s == p );
-assert ( skippingws == is_skipws (  ));
-}
-
-
-void round_trip_ws ( const wchar_t *p ) {
-

Re: [PATCH] D16934: [Coverage] Fix crash in VisitIfStmt

[Justin Bogner via cfe-commits]

Vedant Kumar  writes:
> vsk created this revision.
> vsk added a reviewer: bogner.
> vsk added a subscriber: cfe-commits.
>
> When handling 'if' statements, we crash if the condition and the consequent
> branch are spanned by a single macro expansion.
>
> The crash occurs because of a sanity 'reset' in `popRegions()`: if an 
> expansion
> exactly spans an entire region, we set `MostRecentLocation` to the start of 
> the
> expansion (its 'include location').  This ensures we don't `handleFileExit()`
> ourselves out of the expansion before we're done processing all of the regions
> within it. This is tested in test/CoverageMapping/macro-expressions.c.
>
> This causes a problem when an expansion spans both the condition and the
> consequent branch of an 'if' statement. `MostRecentLocation` is updated to the
> start of the 'if' statement in `popRegions()`, so the file for the expansion
> isn't exited by the time we're done handling the statement. We then crash with
> 'fatal: File exit not handled before popRegions'.
>
> The fix for this is to detect these kinds of expansions, and conservatively
> update `MostRecentLocation` to the end of expansion region containing the
> conditional. I've added tests to make sure we don't have the same problem with
> other kinds of statements.

LGTM, with a question about generalising a bit below.

> rdar://problem/23630316
>
> http://reviews.llvm.org/D16934
>
> Files:
>   lib/CodeGen/CoverageMappingGen.cpp
>   test/CoverageMapping/macro-expressions.cpp
>
> Index: test/CoverageMapping/macro-expressions.cpp
> ===
> --- test/CoverageMapping/macro-expressions.cpp
> +++ test/CoverageMapping/macro-expressions.cpp
> @@ -12,6 +12,38 @@
>  #define PRIo64 PRI_64_LENGTH_MODIFIER "o"
>  #define PRIu64 PRI_64_LENGTH_MODIFIER "u"
>  
> +#define STMT(s) s
> +
> +void fn1() {
> +  STMT(if (1));
> +  STMT(while (1));
> +  STMT(for (;;));
> +  if (1)
> +STMT(if (1)) 0;
> +  if (1)
> +STMT(while (1)) 0;
> +  if (1)
> +STMT(for (;;)) 0;
> +  while (1)
> +STMT(if (1)) 0;
> +  while (1)
> +STMT(while (1)) 0;
> +  while (1)
> +STMT(for (;;)) 0;
> +  for (;;)
> +STMT(if (1)) 0;
> +  for (;;)
> +STMT(while (1)) 0;
> +  for (;;)
> +STMT(for (;;)) 0;
> +}
> +
> +void STMT(fn2()) {
> +}
> +
> +void STMT(fn3)() {
> +}
> +
>  // CHECK: foo
>  // CHECK-NEXT: File 0, [[@LINE+1]]:17 -> {{[0-9]+}}:2 = #0
>  void foo(int i) {
> Index: lib/CodeGen/CoverageMappingGen.cpp
> ===
> --- lib/CodeGen/CoverageMappingGen.cpp
> +++ lib/CodeGen/CoverageMappingGen.cpp
> @@ -807,6 +807,14 @@
>  // counter for the body when looking at the coverage.
>  propagateCounts(ParentCount, S->getCond());
>  
> +// The region containing the condition may be spanned by an expansion.
> +// Make sure we handle a file exit out of this expansion before handling
> +// the consequent branch.
> +if (SM.isBeforeInTranslationUnit(getStart(S->getCond()),
> + S->getCond()->getLocStart())) {
> +  MostRecentLocation = getEnd(S->getCond());
> +}

Can/should this be folded into propagateCounts? I can't think of a place
where that would be harmful, but I guess if it can't come up in other
situations this is fine here.

> +
>  extendRegion(S->getThen());
>  Counter OutCount = propagateCounts(ThenCount, S->getThen());
>  
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r260002 - Add a missing call to MDNode::deleteTemporary().

[Adrian Prantl via cfe-commits]

> On Feb 6, 2016, at 12:38 PM, Duncan P. N. Exon Smith  
> wrote:
> 
>> 
>> On 2016-Feb-06, at 10:39, Adrian Prantl via cfe-commits 
>>  wrote:
>> 
>> Author: adrian
>> Date: Sat Feb  6 12:39:34 2016
>> New Revision: 260002
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=260002=rev
>> Log:
>> Add a missing call to MDNode::deleteTemporary().
>> Follow-up to r259975. Kudos to the ASAN bots!
>> 
>> 
>> 
>> 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=260002=260001=260002=diff
>> ==
>> --- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
>> +++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Sat Feb  6 12:39:34 2016
>> @@ -2056,19 +2056,20 @@ llvm::DIType *CGDebugInfo::CreateEnumTyp
>>// It is possible for enums to be created as part of their own
>>// declcontext. We need to cache a placeholder to avoid the type being
>>// created twice before hitting the cache.
>> -llvm::DIScope *EDContext = DBuilder.createReplaceableCompositeType(
>> +llvm::DIScope *TmpContext = DBuilder.createReplaceableCompositeType(
> 
> If you change this to:
> ```
> llvm::TempDIScope TmpContext(DBuilder.create...())
> ```
> then the lifetime of `TmpContext` will get managed for you (it's a
> `std::unique_ptr`).
> 
> Really, `DIBuilder` should return this instead of a `DIScope*`, so
> that it's clear what the lifetime is.

That’s much better, thanks!

r260113

-- adrian


> 
>>  llvm::dwarf::DW_TAG_enumeration_type, "", TheCU, DefUnit, 0);
>> 
>>unsigned Line = getLineNumber(ED->getLocation());
>>StringRef EDName = ED->getName();
>>llvm::DIType *RetTy = DBuilder.createReplaceableCompositeType(
>> -llvm::dwarf::DW_TAG_enumeration_type, EDName, EDContext, DefUnit, 
>> Line,
>> +llvm::dwarf::DW_TAG_enumeration_type, EDName, TmpContext, DefUnit, 
>> Line,
>>0, Size, Align, llvm::DINode::FlagFwdDecl, FullName);
>> 
>>// Cache the enum type so it is available when building the declcontext
>>// and replace the declcontect with the real thing.
>>TypeCache[Ty].reset(RetTy);
>> -EDContext->replaceAllUsesWith(getDeclContextDescriptor(ED));
>> +TmpContext->replaceAllUsesWith(getDeclContextDescriptor(ED));
>> +llvm::MDNode::deleteTemporary(TmpContext);
>> 
>>ReplaceMap.emplace_back(
>>std::piecewise_construct, std::make_tuple(Ty),
>> 
>> 
>> ___
>> 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

r260113 - Use llvm::TempDIScope instead of manually deleting a temporary MDNode.

[Adrian Prantl via cfe-commits]

Author: adrian
Date: Mon Feb  8 11:03:28 2016
New Revision: 260113

URL: http://llvm.org/viewvc/llvm-project?rev=260113=rev
Log:
Use llvm::TempDIScope instead of manually deleting a temporary MDNode.

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=260113=260112=260113=diff
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Mon Feb  8 11:03:28 2016
@@ -2056,20 +2056,19 @@ llvm::DIType *CGDebugInfo::CreateEnumTyp
 // It is possible for enums to be created as part of their own
 // declcontext. We need to cache a placeholder to avoid the type being
 // created twice before hitting the cache.
-llvm::DIScope *TmpContext = DBuilder.createReplaceableCompositeType(
-  llvm::dwarf::DW_TAG_enumeration_type, "", TheCU, DefUnit, 0);
+llvm::TempDIScope TmpContext(DBuilder.createReplaceableCompositeType(
+llvm::dwarf::DW_TAG_enumeration_type, "", TheCU, DefUnit, 0));
 
 unsigned Line = getLineNumber(ED->getLocation());
 StringRef EDName = ED->getName();
 llvm::DIType *RetTy = DBuilder.createReplaceableCompositeType(
-llvm::dwarf::DW_TAG_enumeration_type, EDName, TmpContext, DefUnit, 
Line,
-0, Size, Align, llvm::DINode::FlagFwdDecl, FullName);
+llvm::dwarf::DW_TAG_enumeration_type, EDName, TmpContext.get(), 
DefUnit,
+Line, 0, Size, Align, llvm::DINode::FlagFwdDecl, FullName);
 
 // Cache the enum type so it is available when building the declcontext
 // and replace the declcontect with the real thing.
 TypeCache[Ty].reset(RetTy);
 TmpContext->replaceAllUsesWith(getDeclContextDescriptor(ED));
-llvm::MDNode::deleteTemporary(TmpContext);
 
 ReplaceMap.emplace_back(
 std::piecewise_construct, std::make_tuple(Ty),


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

[libclc] r260114 - math: Add frexp ported from amd-builtins

[Aaron Watry via cfe-commits]

Author: awatry
Date: Mon Feb  8 11:07:21 2016
New Revision: 260114

URL: http://llvm.org/viewvc/llvm-project?rev=260114=rev
Log:
math: Add frexp ported from amd-builtins

The float implementation is almost a direct port from the amd-builtins,
but instead of just having a scalar and float4 implementation, it has
a scalar and arbitrary width vector implementation.

The double scalar is also a direct port from AMD's builtin release.

The double vector implementation copies the logic in the float vector
implementation using the values from the double scalar version.

Both have been tested in piglit using tests sent to that project's
mailing list.

Signed-off-by: Aaron Watry 
Reviewed-by: Jan Vesely 

Added:
libclc/trunk/generic/include/clc/math/frexp.h
libclc/trunk/generic/include/clc/math/frexp.inc
libclc/trunk/generic/lib/math/frexp.cl
libclc/trunk/generic/lib/math/frexp.inc
Modified:
libclc/trunk/generic/include/clc/clc.h
libclc/trunk/generic/include/clc/math/gentype.inc
libclc/trunk/generic/lib/SOURCES

Modified: libclc/trunk/generic/include/clc/clc.h
URL: 
http://llvm.org/viewvc/llvm-project/libclc/trunk/generic/include/clc/clc.h?rev=260114=260113=260114=diff
==
--- libclc/trunk/generic/include/clc/clc.h (original)
+++ libclc/trunk/generic/include/clc/clc.h Mon Feb  8 11:07:21 2016
@@ -58,6 +58,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 

Added: libclc/trunk/generic/include/clc/math/frexp.h
URL: 
http://llvm.org/viewvc/llvm-project/libclc/trunk/generic/include/clc/math/frexp.h?rev=260114=auto
==
--- libclc/trunk/generic/include/clc/math/frexp.h (added)
+++ libclc/trunk/generic/include/clc/math/frexp.h Mon Feb  8 11:07:21 2016
@@ -0,0 +1,2 @@
+#define __CLC_BODY 
+#include 

Added: libclc/trunk/generic/include/clc/math/frexp.inc
URL: 
http://llvm.org/viewvc/llvm-project/libclc/trunk/generic/include/clc/math/frexp.inc?rev=260114=auto
==
--- libclc/trunk/generic/include/clc/math/frexp.inc (added)
+++ libclc/trunk/generic/include/clc/math/frexp.inc Mon Feb  8 11:07:21 2016
@@ -0,0 +1,3 @@
+_CLC_OVERLOAD _CLC_DECL __CLC_GENTYPE frexp(__CLC_GENTYPE x, global __CLC_INTN 
*iptr);
+_CLC_OVERLOAD _CLC_DECL __CLC_GENTYPE frexp(__CLC_GENTYPE x, local __CLC_INTN 
*iptr);
+_CLC_OVERLOAD _CLC_DECL __CLC_GENTYPE frexp(__CLC_GENTYPE x, private 
__CLC_INTN *iptr);

Modified: libclc/trunk/generic/include/clc/math/gentype.inc
URL: 
http://llvm.org/viewvc/llvm-project/libclc/trunk/generic/include/clc/math/gentype.inc?rev=260114=260113=260114=diff
==
--- libclc/trunk/generic/include/clc/math/gentype.inc (original)
+++ libclc/trunk/generic/include/clc/math/gentype.inc Mon Feb  8 11:07:21 2016
@@ -2,38 +2,50 @@
 #define __CLC_FPSIZE 32
 
 #define __CLC_GENTYPE float
+#define __CLC_INTN int
 #define __CLC_SCALAR
 #include __CLC_BODY
 #undef __CLC_GENTYPE
+#undef __CLC_INTN
 #undef __CLC_SCALAR
 
 #define __CLC_GENTYPE float2
 #define __CLC_INTN int2
+#define __CLC_VECSIZE 2
 #include __CLC_BODY
+#undef __CLC_VECSIZE
 #undef __CLC_GENTYPE
 #undef __CLC_INTN
 
 #define __CLC_GENTYPE float3
 #define __CLC_INTN int3
+#define __CLC_VECSIZE 3
 #include __CLC_BODY
+#undef __CLC_VECSIZE
 #undef __CLC_GENTYPE
 #undef __CLC_INTN
 
 #define __CLC_GENTYPE float4
 #define __CLC_INTN int4
+#define __CLC_VECSIZE 4
 #include __CLC_BODY
+#undef __CLC_VECSIZE
 #undef __CLC_GENTYPE
 #undef __CLC_INTN
 
 #define __CLC_GENTYPE float8
 #define __CLC_INTN int8
+#define __CLC_VECSIZE 8
 #include __CLC_BODY
+#undef __CLC_VECSIZE
 #undef __CLC_GENTYPE
 #undef __CLC_INTN
 
 #define __CLC_GENTYPE float16
 #define __CLC_INTN int16
+#define __CLC_VECSIZE 16
 #include __CLC_BODY
+#undef __CLC_VECSIZE
 #undef __CLC_GENTYPE
 #undef __CLC_INTN
 
@@ -47,37 +59,49 @@
 
 #define __CLC_SCALAR
 #define __CLC_GENTYPE double
+#define __CLC_INTN int
 #include __CLC_BODY
 #undef __CLC_GENTYPE
+#undef __CLC_INTN
 #undef __CLC_SCALAR
 
 #define __CLC_GENTYPE double2
 #define __CLC_INTN int2
+#define __CLC_VECSIZE 2
 #include __CLC_BODY
+#undef __CLC_VECSIZE
 #undef __CLC_GENTYPE
 #undef __CLC_INTN
 
 #define __CLC_GENTYPE double3
 #define __CLC_INTN int3
+#define __CLC_VECSIZE 3
 #include __CLC_BODY
+#undef __CLC_VECSIZE
 #undef __CLC_GENTYPE
 #undef __CLC_INTN
 
 #define __CLC_GENTYPE double4
 #define __CLC_INTN int4
+#define __CLC_VECSIZE 4
 #include __CLC_BODY
+#undef __CLC_VECSIZE
 #undef __CLC_GENTYPE
 #undef __CLC_INTN
 
 #define __CLC_GENTYPE double8
 #define __CLC_INTN int8
+#define __CLC_VECSIZE 8
 #include __CLC_BODY
+#undef __CLC_VECSIZE
 #undef __CLC_GENTYPE
 #undef __CLC_INTN
 
 #define __CLC_GENTYPE double16
 #define __CLC_INTN int16
+#define 

Re: [PATCH] D16947: [PGO] assignment operator does not get profile data

[David Li via cfe-commits]

davidxl updated this revision to Diff 47217.
davidxl added a comment.

Simplified test case suggested by Vedant.


http://reviews.llvm.org/D16947

Files:
  lib/CodeGen/CGClass.cpp
  test/Profile/def-assignop.cpp

Index: test/Profile/def-assignop.cpp
===
--- test/Profile/def-assignop.cpp
+++ test/Profile/def-assignop.cpp
@@ -0,0 +1,32 @@
+// RUN: %clang_cc1 -x c++ -std=c++11 %s -triple x86_64-unknown-linux-gnu 
-main-file-name def-assignop.cpp -o - -emit-llvm -fprofile-instrument=clang | 
FileCheck --check-prefix=PGOGEN %s
+// RUN: %clang_cc1 -x c++ -std=c++11 %s -triple x86_64-unknown-linux-gnu 
-main-file-name def-assignop.cpp -o - -emit-llvm -fprofile-instrument=clang 
-fcoverage-mapping | FileCheck --check-prefix=COVMAP %s
+
+struct B {
+  void operator=(const B ) {}
+  void operator=(const B &) {}
+};
+
+struct A {
+  A =(const A &) = default;
+  // PGOGEN: define {{.*}}@_ZN1AaSERKS_(
+  // PGOGEN: %pgocount = load {{.*}} @__profc__ZN1AaSERKS_
+  // PGOGEN: {{.*}}add{{.*}}%pgocount, 1
+  // PGOGEN: store{{.*}}@__profc__ZN1AaSERKS_
+  A =(A &&) = default;
+  // PGOGEN: define {{.*}}@_ZN1AaSEOS_
+  // PGOGEN: %pgocount = load {{.*}} @__profc__ZN1AaSEOS_
+  // PGOGEN: {{.*}}add{{.*}}%pgocount, 1
+  // PGOGEN: store{{.*}}@__profc__ZN1AaSEOS_
+
+  // Check that coverage mapping includes 6 function records including the
+  // defaulted copy and move operators: A::operator=
+  // COVMAP: @__llvm_coverage_mapping = {{.*}} { { i32, i32, i32, i32 }, [5 x 
<{{.*}}>],
+  B b;
+};
+
+int main() {
+  A a1, a2;
+  a1 = a2;
+  a2 = static_cast(a1);
+  return 0;
+}
Index: lib/CodeGen/CGClass.cpp
===
--- lib/CodeGen/CGClass.cpp
+++ lib/CodeGen/CGClass.cpp
@@ -1608,6 +1608,7 @@
 
   LexicalScope Scope(*this, RootCS->getSourceRange());
 
+  incrementProfileCounter(RootCS);
   AssignmentMemcpyizer AM(*this, AssignOp, Args);
   for (auto *I : RootCS->body())
 AM.emitAssignment(I);


Index: test/Profile/def-assignop.cpp
===
--- test/Profile/def-assignop.cpp
+++ test/Profile/def-assignop.cpp
@@ -0,0 +1,32 @@
+// RUN: %clang_cc1 -x c++ -std=c++11 %s -triple x86_64-unknown-linux-gnu -main-file-name def-assignop.cpp -o - -emit-llvm -fprofile-instrument=clang | FileCheck --check-prefix=PGOGEN %s
+// RUN: %clang_cc1 -x c++ -std=c++11 %s -triple x86_64-unknown-linux-gnu -main-file-name def-assignop.cpp -o - -emit-llvm -fprofile-instrument=clang -fcoverage-mapping | FileCheck --check-prefix=COVMAP %s
+
+struct B {
+  void operator=(const B ) {}
+  void operator=(const B &) {}
+};
+
+struct A {
+  A =(const A &) = default;
+  // PGOGEN: define {{.*}}@_ZN1AaSERKS_(
+  // PGOGEN: %pgocount = load {{.*}} @__profc__ZN1AaSERKS_
+  // PGOGEN: {{.*}}add{{.*}}%pgocount, 1
+  // PGOGEN: store{{.*}}@__profc__ZN1AaSERKS_
+  A =(A &&) = default;
+  // PGOGEN: define {{.*}}@_ZN1AaSEOS_
+  // PGOGEN: %pgocount = load {{.*}} @__profc__ZN1AaSEOS_
+  // PGOGEN: {{.*}}add{{.*}}%pgocount, 1
+  // PGOGEN: store{{.*}}@__profc__ZN1AaSEOS_
+
+  // Check that coverage mapping includes 6 function records including the
+  // defaulted copy and move operators: A::operator=
+  // COVMAP: @__llvm_coverage_mapping = {{.*}} { { i32, i32, i32, i32 }, [5 x <{{.*}}>],
+  B b;
+};
+
+int main() {
+  A a1, a2;
+  a1 = a2;
+  a2 = static_cast(a1);
+  return 0;
+}
Index: lib/CodeGen/CGClass.cpp
===
--- lib/CodeGen/CGClass.cpp
+++ lib/CodeGen/CGClass.cpp
@@ -1608,6 +1608,7 @@
 
   LexicalScope Scope(*this, RootCS->getSourceRange());
 
+  incrementProfileCounter(RootCS);
   AssignmentMemcpyizer AM(*this, AssignOp, Args);
   for (auto *I : RootCS->body())
 AM.emitAssignment(I);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D16947: [PGO] assignment operator does not get profile data

[Vedant Kumar via cfe-commits]

vsk added a comment.

Lgtm.


http://reviews.llvm.org/D16947



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

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[Jonathan Wakely via cfe-commits]

On 8 February 2016 at 17:58, H.J. Lu wrote:
> On Mon, Feb 8, 2016 at 7:59 AM, Jonathan Wakely  wrote:
 A type is a standard-layout type, or it isn't.
>>>
>>> How about "An empty record is standard-layout Plain Old Data (POD)
>>> type and ..."?
>>
>> That's redundant, all POD types are standard-layout types.
>>
>
> Apparently, not all standard-layout types are POD types.  GCC has
>
> /* Nonzero means that this class type is not POD for the purpose of layout
>(as defined in the ABI).  This is different from the language's POD.  */
> CLASSTYPE_NON_LAYOUT_POD_P
>
> and
>
> /* Nonzero means that this class type is a non-standard-layout class.  */
> #define CLASSTYPE_NON_STD_LAYOUT
>
> They aren't the same.
>
> struct A { };
> struct B { };
> struct C : A, B { };
>
> C is a standard-layout type, but not a standard-layout POD type.

As the comment says, "POD for the purposes of layout" is different
from the language's POD. All standard-layout types are POD types
according to the language.

So when you previously had "POD for the purposes of layout" that was
at least partially clear that you meant something other than what the
language means. But as pointed out, using a GCC-specific term is not
ideal.

When you changed it to "POD for the purpose of standard-layout" that
became a completely meaningless term. Where is that defined?

Your next suggestion was "standard-layout Plain Old Data (POD)" which
is even worse, now you're using two terms defined by the C++ language,
but you mean something different.

When you mean something that is the same as the language (like "class
type") it makes sense to use the same term.

When you mean something that is not the same as the language (like
"POD") it makes sense to use a different term, or clearly define how
you are using it.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu via cfe-commits]

On Mon, Feb 8, 2016 at 10:30 AM, Jonathan Wakely  wrote:
> On 8 February 2016 at 18:26, Jonathan Wakely  wrote:
>> On 8 February 2016 at 17:58, H.J. Lu wrote:
>>> On Mon, Feb 8, 2016 at 7:59 AM, Jonathan Wakely  
>>> wrote:
>> A type is a standard-layout type, or it isn't.
>
> How about "An empty record is standard-layout Plain Old Data (POD)
> type and ..."?

 That's redundant, all POD types are standard-layout types.

>>>
>>> Apparently, not all standard-layout types are POD types.  GCC has
>>>
>>> /* Nonzero means that this class type is not POD for the purpose of layout
>>>(as defined in the ABI).  This is different from the language's POD.  */
>>> CLASSTYPE_NON_LAYOUT_POD_P
>>>
>>> and
>>>
>>> /* Nonzero means that this class type is a non-standard-layout class.  */
>>> #define CLASSTYPE_NON_STD_LAYOUT
>>>
>>> They aren't the same.
>>>
>>> struct A { };
>>> struct B { };
>>> struct C : A, B { };
>>>
>>> C is a standard-layout type, but not a standard-layout POD type.
>>
>> As the comment says, "POD for the purposes of layout" is different
>> from the language's POD. All standard-layout types are POD types
>> according to the language.
>>
>> So when you previously had "POD for the purposes of layout" that was
>> at least partially clear that you meant something other than what the
>> language means. But as pointed out, using a GCC-specific term is not
>> ideal.
>>
>> When you changed it to "POD for the purpose of standard-layout" that
>> became a completely meaningless term. Where is that defined?
>>
>> Your next suggestion was "standard-layout Plain Old Data (POD)" which
>> is even worse, now you're using two terms defined by the C++ language,
>> but you mean something different.
>>
>> When you mean something that is the same as the language (like "class
>> type") it makes sense to use the same term.
>>
>> When you mean something that is not the same as the language (like
>> "POD") it makes sense to use a different term, or clearly define how
>> you are using it.
>
> To be clear: it's really confusing to take two terms defined by the
> language, "POD" and "standard-layout", and smash them together to mean
> something new.
>
> According to your proposal, struct C is a POD type, and  a
> standard-layout type, but not a "standard-layout POD type". That's
> just crazy.

Can you suggest a better wording?

Another issue, if I define

1. "class type".  A class type is a structure, union or C++ class.
2. "empty class type".  An empty class type is:
   a. A class type without member.  Or
   b. A class type with only members of empty class types.  Or
   c. An array of empty class types.
^

Will it confuse people?


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

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

[Nemanja Ivanovic via cfe-commits]

nemanjai updated this revision to Diff 47223.
nemanjai added a comment.

Fixed the naming, indentation and removed the use of dyn_cast for types.


Repository:
  rL LLVM

http://reviews.llvm.org/D15120

Files:
  bindings/python/clang/cindex.py
  include/clang-c/Index.h
  include/clang/AST/ASTContext.h
  include/clang/AST/BuiltinTypes.def
  include/clang/AST/Type.h
  include/clang/AST/TypeLoc.h
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Basic/Specifiers.h
  include/clang/Basic/TargetInfo.h
  include/clang/Basic/TokenKinds.def
  include/clang/Driver/Options.td
  include/clang/Lex/LiteralSupport.h
  include/clang/Sema/DeclSpec.h
  include/clang/Serialization/ASTBitCodes.h
  lib/AST/ASTContext.cpp
  lib/AST/ItaniumMangle.cpp
  lib/AST/MicrosoftMangle.cpp
  lib/AST/NSAPI.cpp
  lib/AST/StmtPrinter.cpp
  lib/AST/Type.cpp
  lib/AST/TypeLoc.cpp
  lib/Analysis/PrintfFormatString.cpp
  lib/Basic/TargetInfo.cpp
  lib/Basic/Targets.cpp
  lib/CodeGen/CGDebugInfo.cpp
  lib/CodeGen/CGExprScalar.cpp
  lib/CodeGen/CodeGenTypes.cpp
  lib/CodeGen/ItaniumCXXABI.cpp
  lib/Format/FormatToken.cpp
  lib/Frontend/InitPreprocessor.cpp
  lib/Index/USRGeneration.cpp
  lib/Lex/LiteralSupport.cpp
  lib/Parse/ParseDecl.cpp
  lib/Parse/ParseExpr.cpp
  lib/Parse/ParseExprCXX.cpp
  lib/Parse/ParseTentative.cpp
  lib/Sema/DeclSpec.cpp
  lib/Sema/SemaDecl.cpp
  lib/Sema/SemaExpr.cpp
  lib/Sema/SemaExprCXX.cpp
  lib/Sema/SemaLookup.cpp
  lib/Sema/SemaOverload.cpp
  lib/Sema/SemaTemplateVariadic.cpp
  lib/Sema/SemaType.cpp
  lib/Serialization/ASTCommon.cpp
  lib/Serialization/ASTReader.cpp
  test/CodeGenCXX/float128-declarations.cpp
  test/Preprocessor/init.c
  test/Sema/128bitfloat.cpp
  test/Sema/float128-ld-incompatibility.cpp
  test/SemaCXX/deleted-operator.cpp
  test/SemaCXX/overloaded-builtin-operators.cpp
  tools/libclang/CXType.cpp

Index: tools/libclang/CXType.cpp
===
--- tools/libclang/CXType.cpp
+++ tools/libclang/CXType.cpp
@@ -51,6 +51,7 @@
 BTCASE(Float);
 BTCASE(Double);
 BTCASE(LongDouble);
+BTCASE(Float128);
 BTCASE(NullPtr);
 BTCASE(Overload);
 BTCASE(Dependent);
@@ -466,6 +467,7 @@
 TKIND(Float);
 TKIND(Double);
 TKIND(LongDouble);
+TKIND(Float128);
 TKIND(NullPtr);
 TKIND(Overload);
 TKIND(Dependent);
Index: test/SemaCXX/overloaded-builtin-operators.cpp
===
--- test/SemaCXX/overloaded-builtin-operators.cpp
+++ test/SemaCXX/overloaded-builtin-operators.cpp
@@ -183,7 +183,7 @@
   // FIXME: lots of candidates here!
   (void)(1.0f * a); // expected-error{{ambiguous}} \
 // expected-note 4{{candidate}} \
-// expected-note {{remaining 117 candidates omitted; pass -fshow-overloads=all to show them}}
+// expected-note {{remaining 140 candidates omitted; pass -fshow-overloads=all to show them}}
 }
 
 // pr5432
Index: test/SemaCXX/deleted-operator.cpp
===
--- test/SemaCXX/deleted-operator.cpp
+++ test/SemaCXX/deleted-operator.cpp
@@ -9,7 +9,7 @@
   PR10757 a1;
   // FIXME: We get a ridiculous number of "built-in candidate" notes here...
   if(~a1) {} // expected-error {{overload resolution selected deleted operator}} expected-note 8 {{built-in candidate}}
-  if(a1==a1) {} // expected-error {{overload resolution selected deleted operator}} expected-note 121 {{built-in candidate}}
+  if(a1==a1) {} // expected-error {{overload resolution selected deleted operator}} expected-note 144 {{built-in candidate}}
 }
 
 struct DelOpDel {
Index: test/Sema/float128-ld-incompatibility.cpp
===
--- test/Sema/float128-ld-incompatibility.cpp
+++ test/Sema/float128-ld-incompatibility.cpp
@@ -0,0 +1,36 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c++11 \
+// RUN: -triple powerpc64le-unknown-linux-gnu -target-cpu pwr8 \
+// RUN: -target-feature +float128 %s
+
+__float128 qf();
+long double ldf();
+
+// FIXME: once operations between long double and __float128 are implemented for
+//targets where the types are different, these next two will change
+long double ld{qf()}; // expected-error {{cannot initialize a variable of type 'long double' with an rvalue of type '__float128'}}
+__float128 q{ldf()};  // expected-error {{cannot initialize a variable of type '__float128' with an rvalue of type 'long double'}}
+
+auto test1(__float128 q, long double ld) -> decltype(q + ld) { // expected-error {{invalid operands to binary expression ('__float128' and 'long double')}}
+  return q + ld;  // expected-error {{invalid operands to binary expression ('__float128' and 'long double')}}
+}
+
+auto test2(long double a, __float128 b) -> decltype(a + b) { // expected-error {{invalid operands to binary expression ('long double' and '__float128')}}
+  return a + b;  // 

Re: [PATCH] D16951: [MS ABI] dllimport'd class cannot have constexpr ctors

[Hans Wennborg via cfe-commits]

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

lgtm


http://reviews.llvm.org/D16951



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

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu via cfe-commits]

On Mon, Feb 8, 2016 at 10:46 AM, Jonathan Wakely  wrote:
> On 8 February 2016 at 18:31, H.J. Lu  wrote:
>> On Mon, Feb 8, 2016 at 10:30 AM, Jonathan Wakely  
>> wrote:
>>> On 8 February 2016 at 18:26, Jonathan Wakely  wrote:
 On 8 February 2016 at 17:58, H.J. Lu wrote:
> On Mon, Feb 8, 2016 at 7:59 AM, Jonathan Wakely  
> wrote:
 A type is a standard-layout type, or it isn't.
>>>
>>> How about "An empty record is standard-layout Plain Old Data (POD)
>>> type and ..."?
>>
>> That's redundant, all POD types are standard-layout types.
>>
>
> Apparently, not all standard-layout types are POD types.  GCC has
>
> /* Nonzero means that this class type is not POD for the purpose of layout
>(as defined in the ABI).  This is different from the language's POD.  
> */
> CLASSTYPE_NON_LAYOUT_POD_P
>
> and
>
> /* Nonzero means that this class type is a non-standard-layout class.  */
> #define CLASSTYPE_NON_STD_LAYOUT
>
> They aren't the same.
>
> struct A { };
> struct B { };
> struct C : A, B { };
>
> C is a standard-layout type, but not a standard-layout POD type.

 As the comment says, "POD for the purposes of layout" is different
 from the language's POD. All standard-layout types are POD types
 according to the language.

 So when you previously had "POD for the purposes of layout" that was
 at least partially clear that you meant something other than what the
 language means. But as pointed out, using a GCC-specific term is not
 ideal.

 When you changed it to "POD for the purpose of standard-layout" that
 became a completely meaningless term. Where is that defined?

 Your next suggestion was "standard-layout Plain Old Data (POD)" which
 is even worse, now you're using two terms defined by the C++ language,
 but you mean something different.

 When you mean something that is the same as the language (like "class
 type") it makes sense to use the same term.

 When you mean something that is not the same as the language (like
 "POD") it makes sense to use a different term, or clearly define how
 you are using it.
>>>
>>> To be clear: it's really confusing to take two terms defined by the
>>> language, "POD" and "standard-layout", and smash them together to mean
>>> something new.
>>>
>>> According to your proposal, struct C is a POD type, and  a
>>> standard-layout type, but not a "standard-layout POD type". That's
>>> just crazy.
>>
>> Can you suggest a better wording?
>
> I don't know what the definition of "POD for the purposes of layout"
> is, but if I was trying to define a better name for it I would start
> by trying to understand how it is specified, instead of just throwing
> existing terms together.
>
>
>> Another issue, if I define
>>
>> 1. "class type".  A class type is a structure, union or C++ class.
>> 2. "empty class type".  An empty class type is:
>>a. A class type without member.  Or
>>b. A class type with only members of empty class types.  Or
>>c. An array of empty class types.
>> ^
>>
>> Will it confuse people?
>
> Yes :-)
>
> But that was already confusing when you called it an "empty
> collection" because an array isn't a collection.
>
> If I understand correctly, your proposal says that given:
>
> struct A { };  // empty class type
> typedef A A2[2];  // array of empty class types
>
> struct B { A a[2]; };  // empty record?
>
> struct B is an empty record ... is that right?

Yes, struct B is an empty record.   And also in

struct A { };
struct B { };
struct C : A, B { };

C isn't an empty record.

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

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

[Tim Northover via cfe-commits]

Hi Eric,

On 6 February 2016 at 16:36, Eric Fiselier via cfe-commits
 wrote:
> Cleanup node-type handling in the unordered containers

This seems to have broken __gnu_cxx::hash_map (used by hash.cpp and
hash2.cpp in the test-suite). A smaller reproducer is:

#include 
typedef __gnu_cxx::hash_map > HM;
int foo(HM ) {
  return h["wibble"];
}

I don't suppose you could take a look? Or is that already planned and
what you're talking about with:

> This patch will be followed up shortly with fixes for various unordered_map
> fixes.

Cheers.

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