Re: [PATCH] D15805: [clang-tidy] Cleanup code in CERT module.

[Haojian Wu via cfe-commits]

hokein updated this revision to Diff 43870.
hokein added a comment.

Rename: 'CERT' => 'cert'


http://reviews.llvm.org/D15805

Files:
  clang-tidy/cert/CERTTidyModule.cpp
  clang-tidy/cert/SetLongJmpCheck.cpp
  clang-tidy/cert/SetLongJmpCheck.h
  clang-tidy/cert/StaticObjectExceptionCheck.cpp
  clang-tidy/cert/StaticObjectExceptionCheck.h
  clang-tidy/cert/ThrownExceptionTypeCheck.cpp
  clang-tidy/cert/ThrownExceptionTypeCheck.h
  clang-tidy/cert/VariadicFunctionDefCheck.cpp
  clang-tidy/cert/VariadicFunctionDefCheck.h

Index: clang-tidy/cert/VariadicFunctionDefCheck.h
===
--- clang-tidy/cert/VariadicFunctionDefCheck.h
+++ clang-tidy/cert/VariadicFunctionDefCheck.h
@@ -14,6 +14,7 @@
 
 namespace clang {
 namespace tidy {
+namespace cert {
 
 /// Guards against any C-style variadic function definitions (not declarations).
 ///
@@ -27,8 +28,8 @@
   void check(const ast_matchers::MatchFinder::MatchResult &Result) override;
 };
 
+} // namespace cert
 } // namespace tidy
 } // namespace clang
 
 #endif // LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_CERT_VARIADICFUNCTIONDEF_H
-
Index: clang-tidy/cert/VariadicFunctionDefCheck.cpp
===
--- clang-tidy/cert/VariadicFunctionDefCheck.cpp
+++ clang-tidy/cert/VariadicFunctionDefCheck.cpp
@@ -15,6 +15,7 @@
 
 namespace clang {
 namespace tidy {
+namespace cert {
 
 void VariadicFunctionDefCheck::registerMatchers(MatchFinder *Finder) {
   if (!getLangOpts().CPlusPlus)
@@ -36,6 +37,6 @@
"parameter pack or currying instead");
 }
 
+} // namespace cert
 } // namespace tidy
 } // namespace clang
-
Index: clang-tidy/cert/ThrownExceptionTypeCheck.h
===
--- clang-tidy/cert/ThrownExceptionTypeCheck.h
+++ clang-tidy/cert/ThrownExceptionTypeCheck.h
@@ -14,6 +14,7 @@
 
 namespace clang {
 namespace tidy {
+namespace cert {
 
 /// Checks whether a thrown object is nothrow copy constructible.
 ///
@@ -27,8 +28,8 @@
   void check(const ast_matchers::MatchFinder::MatchResult &Result) override;
 };
 
+} // namespace cert
 } // namespace tidy
 } // namespace clang
 
 #endif // LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_CERT_THROWNEXCEPTIONTYPECHECK_H
-
Index: clang-tidy/cert/ThrownExceptionTypeCheck.cpp
===
--- clang-tidy/cert/ThrownExceptionTypeCheck.cpp
+++ clang-tidy/cert/ThrownExceptionTypeCheck.cpp
@@ -16,6 +16,8 @@
 
 namespace clang {
 namespace tidy {
+namespace cert {
+
 void ThrownExceptionTypeCheck::registerMatchers(MatchFinder *Finder) {
   if (!getLangOpts().CPlusPlus)
 return;
@@ -34,6 +36,6 @@
"thrown exception type is not nothrow copy constructible");
 }
 
+} // namespace cert
 } // namespace tidy
 } // namespace clang
-
Index: clang-tidy/cert/StaticObjectExceptionCheck.h
===
--- clang-tidy/cert/StaticObjectExceptionCheck.h
+++ clang-tidy/cert/StaticObjectExceptionCheck.h
@@ -14,6 +14,7 @@
 
 namespace clang {
 namespace tidy {
+namespace cert {
 
 /// Checks whether the constructor for a static or thread_local object will
 /// throw.
@@ -28,8 +29,8 @@
   void check(const ast_matchers::MatchFinder::MatchResult &Result) override;
 };
 
+} // namespace cert
 } // namespace tidy
 } // namespace clang
 
 #endif // LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_CERT_ERR58_CPP_H
-
Index: clang-tidy/cert/StaticObjectExceptionCheck.cpp
===
--- clang-tidy/cert/StaticObjectExceptionCheck.cpp
+++ clang-tidy/cert/StaticObjectExceptionCheck.cpp
@@ -16,6 +16,7 @@
 
 namespace clang {
 namespace tidy {
+namespace cert {
 
 void StaticObjectExceptionCheck::registerMatchers(MatchFinder *Finder) {
   if (!getLangOpts().CPlusPlus)
@@ -44,6 +45,6 @@
DiagnosticIDs::Note);
 }
 
+} // namespace cert
 } // namespace tidy
 } // namespace clang
-
Index: clang-tidy/cert/SetLongJmpCheck.h
===
--- clang-tidy/cert/SetLongJmpCheck.h
+++ clang-tidy/cert/SetLongJmpCheck.h
@@ -14,6 +14,7 @@
 
 namespace clang {
 namespace tidy {
+namespace cert {
 
 /// Guards against use of setjmp/longjmp in C++ code
 ///
@@ -30,8 +31,8 @@
   static const char DiagWording[];
 };
 
+} // namespace cert
 } // namespace tidy
 } // namespace clang
 
 #endif // LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_SETLONGJMPCHECK_H
-
Index: clang-tidy/cert/SetLongJmpCheck.cpp
===
--- clang-tidy/cert/SetLongJmpCheck.cpp
+++ clang-tidy/cert/SetLongJmpCheck.cpp
@@ -18,6 +18,7 @@
 
 namespace clang {
 namespace tidy {
+namespace cert {
 
 const char SetLongJmpCheck::DiagWording[] =
 "do not call %0; consider using exception handling instead";
@@ -73,5 +74,6 @@
   diag(E->getExprLoc(), DiagWording) << cast(E->getCalleeDecl());
 }
 
+} // namespace 

Re: [PATCH] D15805: [clang-tidy] Cleanup code in CERT module.

[Haojian Wu via cfe-commits]

hokein added a comment.

> Yes, but just the namespaces as you do in this patch (not anything in user 
> documentation, for instance). This patch LG; if you need me to commit on your 
> behalf, I'm happy to do so.


Done. But My account has no write access to the code repo. Can I commit the 
patch by myself? If not, I'm happy you can land it on my behalf :)


http://reviews.llvm.org/D15805



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

Re: [PATCH] D15266: [clang-format] Handle \n the same way as std::endl with stream operator.

[Daniel Jasper via cfe-commits]

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

Looks good.


http://reviews.llvm.org/D15266



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

Re: [PATCH] D14484: Formatting constructor initializer lists by putting them always on different lines

[Daniel Jasper via cfe-commits]

djasper added a comment.

The Google and Unity style guides have explicit examples of using the one-line 
version. The other style guide (at least to me) isn't clear on forbidding what 
clang-format currently does.

My gut feeling is that it is not worth the cost of renaming and extending the 
current style option. If you are trying to convince ~70 people to use 
clang-format, there will be several things where it doesn't do 100% what the 
current practice is. However, this issue (like probably several of the others) 
is quite an infrequent issue with very limited impact on readability.



Comment at: unittests/Format/FormatTest.cpp:9753
@@ +9752,3 @@
+  CHECK_PARSE("ConstructorInitializer: false", ConstructorInitializer,
+  FormatStyle::CI_Compact);
+  CHECK_PARSE("ConstructorInitializer: true", ConstructorInitializer,

The reason we commonly accept true/false after migrating to an enum is so that 
the config files remain backwards compatible. If we rename the style attribute, 
however, more needs to be done to keep this backwards compatible. Setting the 
old name to true or false should set the corresponding value of the new name 
unless that one is explicitly set.


Repository:
  rL LLVM

http://reviews.llvm.org/D14484



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

Re: [PATCH] D14484: Formatting constructor initializer lists by putting them always on different lines

[Daniel Jasper via cfe-commits]

djasper added a comment.

I actually have more thoughts on this. If we go down this road, there are many 
more options that people might envision. Maybe they don't want to wrap the 
initializer list, if there is just one initializer. Maybe they want to align 
the initializers somewhere after the constructor parameters:

  Constructor() : aaa(aaa),
  bbb(bbb) {}

There are many options to do this, but really the difference in readability is 
quite small and I think it adds unnecessary complexity to clang-format.


Repository:
  rL LLVM

http://reviews.llvm.org/D14484



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

r256742 - Convert test/CXX/lex/lex.literal/lex.string/p4.cpp back to DOS line

[Dimitry Andric via cfe-commits]

Author: dim
Date: Mon Jan  4 04:17:48 2016
New Revision: 256742

URL: http://llvm.org/viewvc/llvm-project?rev=256742&view=rev
Log:
Convert test/CXX/lex/lex.literal/lex.string/p4.cpp back to DOS line
endings, since the file is supposed to have them, according to its
comments.  Also set its svn:eol-style property.  Noticed by Nico Weber.

Modified:
cfe/trunk/test/CXX/lex/lex.literal/lex.string/p4.cpp   (contents, props 
changed)

Modified: cfe/trunk/test/CXX/lex/lex.literal/lex.string/p4.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CXX/lex/lex.literal/lex.string/p4.cpp?rev=256742&r1=256741&r2=256742&view=diff
==
--- cfe/trunk/test/CXX/lex/lex.literal/lex.string/p4.cpp (original)
+++ cfe/trunk/test/CXX/lex/lex.literal/lex.string/p4.cpp Mon Jan  4 04:17:48 
2016
@@ -1,17 +1,17 @@
-// RUN: %clang_cc1 -fsyntax-only -std=c++11 -verify %s
-// expected-no-diagnostics
-
-// NOTE: This file intentionally uses DOS-style line endings to test
-// that we don't propagate them into string literals as per [lex.string]p4.
-
-constexpr const char* p = R"(a\
-b
-c)";
-
-static_assert(p[0] == 'a',  "");
-static_assert(p[1] == '\\', "");
-static_assert(p[2] == '\n', "");
-static_assert(p[3] == 'b',  "");
-static_assert(p[4] == '\n', "");
-static_assert(p[5] == 'c',  "");
-static_assert(p[6] == '\0', "");
+// RUN: %clang_cc1 -fsyntax-only -std=c++11 -verify %s
+// expected-no-diagnostics
+
+// NOTE: This file intentionally uses DOS-style line endings to test
+// that we don't propagate them into string literals as per [lex.string]p4.
+
+constexpr const char* p = R"(a\
+b
+c)";
+
+static_assert(p[0] == 'a',  "");
+static_assert(p[1] == '\\', "");
+static_assert(p[2] == '\n', "");
+static_assert(p[3] == 'b',  "");
+static_assert(p[4] == '\n', "");
+static_assert(p[5] == 'c',  "");
+static_assert(p[6] == '\0', "");

Propchange: cfe/trunk/test/CXX/lex/lex.literal/lex.string/p4.cpp
--
svn:eol-style = CRLF


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

Re: [PATCH] D15823: Support virtual-near-miss check.

[Cong Liu via cfe-commits]

congliu marked 20 inline comments as done.


Comment at: clang-tidy/misc/VirtualNearMissCheck.cpp:59
@@ +58,3 @@
+bool VirtualNearMissCheck::isOverrideMethod(const CXXMethodDecl *MD){
+  return MD->size_overridden_methods() > 0 || MD->hasAttr();
+}

alexfh wrote:
> Why is the `hasAttr()` part needed? Do you have an example of 
> code that results in `size_overridden_methods() == 0` and 
> `hasAttr() == true`?
I tried some cases, but haven't found an example for that case. 
I saw the same code in [[ 
https://cs.corp.google.com/#piper///depot/google3/third_party/llvm/llvm/tools/clang/include/clang/ASTMatchers/ASTMatchers.h&l=3500
 | AST_MATCHER(CXXMethodDecl, isOverride) ]]. 
I'm not sure why there is a "hasAttr". 


http://reviews.llvm.org/D15823



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

r256750 - clang-format: Fix corner case in builder-type call formatting.

[Daniel Jasper via cfe-commits]

Author: djasper
Date: Mon Jan  4 06:41:11 2016
New Revision: 256750

URL: http://llvm.org/viewvc/llvm-project?rev=256750&view=rev
Log:
clang-format: Fix corner case in builder-type call formatting.

Before:
  return .aaa(a,
  a)
  .(aa);

After:
  return 
  .aaa(a, a)
  .(aa);

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

Modified: cfe/trunk/lib/Format/TokenAnnotator.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/TokenAnnotator.cpp?rev=256750&r1=256749&r2=256750&view=diff
==
--- cfe/trunk/lib/Format/TokenAnnotator.cpp (original)
+++ cfe/trunk/lib/Format/TokenAnnotator.cpp Mon Jan  4 06:41:11 2016
@@ -1769,7 +1769,7 @@ unsigned TokenAnnotator::splitPenalty(co
 // which might otherwise be blown up onto many lines. Here, clang-format
 // won't produce "hanging" indents anyway as there is no other trailing
 // call.
-return Right.LastOperator ? 150 : 40;
+return Right.LastOperator ? 150 : 35;
   }
 
   if (Right.is(TT_TrailingAnnotation) &&

Modified: cfe/trunk/unittests/Format/FormatTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Format/FormatTest.cpp?rev=256750&r1=256749&r2=256750&view=diff
==
--- cfe/trunk/unittests/Format/FormatTest.cpp (original)
+++ cfe/trunk/unittests/Format/FormatTest.cpp Mon Jan  4 06:41:11 2016
@@ -4165,6 +4165,10 @@ TEST_F(FormatTest, FormatsBuilderPattern
   "
->aaa(aaa)\n"
   "->(aaa);");
   verifyFormat(
+  "return \n"
+  ".aaa(a, a)\n"
+  ".(aa);");
+  verifyFormat(
   "aaa()->aa(b)->aaa( // break\n"
   "aa);");
   verifyFormat(


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

Re: [PATCH] D15805: [clang-tidy] Cleanup code in CERT module.

[Aaron Ballman via cfe-commits]

aaron.ballman added a comment.

In http://reviews.llvm.org/D15805#318624, @hokein wrote:

> > Yes, but just the namespaces as you do in this patch (not anything in user 
> > documentation, for instance). This patch LG; if you need me to commit on 
> > your behalf, I'm happy to do so.
>
>
> Done. But My account has no write access to the code repo. Can I commit the 
> patch by myself? If not, I'm happy you can land it on my behalf :)


You can ask Chris Lattner for commit privileges if you would like to commit 
this yourself 
(http://llvm.org/docs/DeveloperPolicy.html#obtaining-commit-access). Let me 
know if you want me to commit instead.


http://reviews.llvm.org/D15805



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

r256753 - clang-format: [JS] Improve empty array literal detection.

[Daniel Jasper via cfe-commits]

Author: djasper
Date: Mon Jan  4 07:11:41 2016
New Revision: 256753

URL: http://llvm.org/viewvc/llvm-project?rev=256753&view=rev
Log:
clang-format: [JS] Improve empty array literal detection.

Previously, the [] in the following example were recognized as an array
subscript leading to weird indentation.

Before:
  var  = a || // wrap
  [];

After:
  var  = a || // wrap
 [];

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

Modified: cfe/trunk/lib/Format/TokenAnnotator.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/TokenAnnotator.cpp?rev=256753&r1=256752&r2=256753&view=diff
==
--- cfe/trunk/lib/Format/TokenAnnotator.cpp (original)
+++ cfe/trunk/lib/Format/TokenAnnotator.cpp Mon Jan  4 07:11:41 2016
@@ -287,9 +287,9 @@ private:
 Left->Type = TT_JsComputedPropertyName;
   } else if (Style.Language == FormatStyle::LK_Proto ||
  (Parent &&
-  Parent->isOneOf(tok::at, tok::equal, tok::comma, 
tok::l_paren,
-  tok::l_square, tok::question, tok::colon,
-  tok::kw_return))) {
+  Parent->isOneOf(TT_BinaryOperator, tok::at, tok::comma,
+  tok::l_paren, tok::l_square, tok::question,
+  tok::colon, tok::kw_return))) {
 Left->Type = TT_ArrayInitializerLSquare;
   } else {
 BindingIncrease = 10;

Modified: cfe/trunk/unittests/Format/FormatTestJS.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Format/FormatTestJS.cpp?rev=256753&r1=256752&r2=256753&view=diff
==
--- cfe/trunk/unittests/Format/FormatTestJS.cpp (original)
+++ cfe/trunk/unittests/Format/FormatTestJS.cpp Mon Jan  4 07:11:41 2016
@@ -310,6 +310,8 @@ TEST_F(FormatTestJS, ArrayLiterals) {
"  ccc\n"
"],\n"
");");
+  verifyFormat("var  = a ||  // wrap\n"
+   "[];");
 
   verifyFormat("someFunction([], {a: a});");
 }


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

Re: [PATCH] D15686: PR25910: clang allows two var definitions with the same mangled name

[Andrey Bokhanko via cfe-commits]

andreybokhanko added a comment.

Ping!


http://reviews.llvm.org/D15686



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

Re: [PATCH] D15805: [clang-tidy] Cleanup code in CERT module.

[Haojian Wu via cfe-commits]

hokein added a comment.

In http://reviews.llvm.org/D15805#318646, @aaron.ballman wrote:

> In http://reviews.llvm.org/D15805#318624, @hokein wrote:
>
> > > Yes, but just the namespaces as you do in this patch (not anything in 
> > > user documentation, for instance). This patch LG; if you need me to 
> > > commit on your behalf, I'm happy to do so.
> >
> >
> > Done. But My account has no write access to the code repo. Can I commit the 
> > patch by myself? If not, I'm happy you can land it on my behalf :)
>
>
> You can ask Chris Lattner for commit privileges if you would like to commit 
> this yourself 
> (http://llvm.org/docs/DeveloperPolicy.html#obtaining-commit-access). Let me 
> know if you want me to commit instead.


Thanks for the link. Please commit for me this time :)


http://reviews.llvm.org/D15805



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

Re: [PATCH] D15710: [clang-tidy] Add non-inline function definition and variable definition check in header files.

[Haojian Wu via cfe-commits]

hokein added inline comments.


Comment at: clang-tidy/misc/DefinitionsInHeadersCheck.cpp:31
@@ +30,3 @@
+  // inline function with external linkage, class template, non-static function
+  // template, static data member of a class template, member function of a
+  // class template, or template specialization for which some template

@aaron, what do you mean the AST matcher here? Could you explain it a bit more? 


http://reviews.llvm.org/D15710



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

Re: [PATCH] D15710: [clang-tidy] Add non-inline function definition and variable definition check in header files.

[Aaron Ballman via cfe-commits]

aaron.ballman added inline comments.


Comment at: clang-tidy/misc/DefinitionsInHeadersCheck.cpp:31
@@ +30,3 @@
+  // inline function with external linkage, class template, non-static function
+  // template, static data member of a class template, member function of a
+  // class template, or template specialization for which some template

hokein wrote:
> @aaron, what do you mean the AST matcher here? Could you explain it a bit 
> more? 
Currently, your code checks whether something is in the header file as part of 
the check() callback and early returns out of it; I was suggesting making the 
header file check part of the AST matcher in registerMatchers() instead, so 
that check() isn't called on declarations that are outside of a header file at 
all. This makes the matcher declaratively more accurate, and it could have a 
(likely minor) positive performance impact.


http://reviews.llvm.org/D15710



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

Re: [PATCH] D15283: [ARMv8-M] Add Clang targeting for ARMv8-M Baseline/Mainline

[Bradley Smith via cfe-commits]

bsmith updated this revision to Diff 43884.
bsmith added a comment.

Rebase patch against latest changes made to ARMv8-M targeting, specifically the 
removal of 'B' as a profile.


Repository:
  rL LLVM

http://reviews.llvm.org/D15283

Files:
  lib/Basic/Targets.cpp
  lib/Driver/Tools.cpp
  test/Driver/arm-alignment.c
  test/Driver/arm-cortex-cpus.c
  test/Driver/arm-features.c
  test/Preprocessor/arm-target-features.c

Index: test/Preprocessor/arm-target-features.c
===
--- test/Preprocessor/arm-target-features.c
+++ test/Preprocessor/arm-target-features.c
@@ -95,6 +95,42 @@
 // THUMBV8A-EABI:#define __ARM_ARCH_EXT_IDIV__ 1
 // THUMBV8A-EABI: #define __ARM_FP 0xE
 
+// RUN: %clang -target armv8m.base-none-linux-gnu -x c -E -dM %s -o - | FileCheck --check-prefix=V8M_BASELINE %s
+// V8M_BASELINE: __ARM_ARCH 8
+// V8M_BASELINE: __ARM_ARCH_8M_BASE__ 1
+// V8M_BASELINE: __ARM_ARCH_EXT_IDIV__ 1
+// V8M_BASELINE-NOT: __ARM_ARCH_ISA_ARM
+// V8M_BASELINE: __ARM_ARCH_ISA_THUMB 1
+// V8M_BASELINE: __ARM_ARCH_PROFILE 'M'
+// V8M_BASELINE-NOT: __ARM_FEATURE_CRC32
+// V8M_BASELINE-NOT: __ARM_FEATURE_DSP
+// V8M_BASELINE-NOT: __ARM_FP 0x{{.*}}
+// V8M_BASELINE-NOT: __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1
+
+// RUN: %clang -target armv8m.main-none-linux-gnu -x c -E -dM %s -o - | FileCheck --check-prefix=V8M_MAINLINE %s
+// V8M_MAINLINE: __ARM_ARCH 8
+// V8M_MAINLINE: __ARM_ARCH_8M_MAIN__ 1
+// V8M_MAINLINE: __ARM_ARCH_EXT_IDIV__ 1
+// V8M_MAINLINE-NOT: __ARM_ARCH_ISA_ARM
+// V8M_MAINLINE: __ARM_ARCH_ISA_THUMB 2
+// V8M_MAINLINE: __ARM_ARCH_PROFILE 'M'
+// V8M_MAINLINE-NOT: __ARM_FEATURE_CRC32
+// V8M_MAINLINE-NOT: __ARM_FEATURE_DSP
+// V8M_MAINLINE: __ARM_FP 0xE
+// V8M_MAINLINE: __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1
+
+// RUN: %clang -target arm-none-linux-gnu -march=armv8-m.main+dsp -x c -E -dM %s -o - | FileCheck --check-prefix=V8M_MAINLINE_DSP %s
+// V8M_MAINLINE_DSP: __ARM_ARCH 8
+// V8M_MAINLINE_DSP: __ARM_ARCH_8M_MAIN__ 1
+// V8M_MAINLINE_DSP: __ARM_ARCH_EXT_IDIV__ 1
+// V8M_MAINLINE_DSP-NOT: __ARM_ARCH_ISA_ARM
+// V8M_MAINLINE_DSP: __ARM_ARCH_ISA_THUMB 2
+// V8M_MAINLINE_DSP: __ARM_ARCH_PROFILE 'M'
+// V8M_MAINLINE_DSP-NOT: __ARM_FEATURE_CRC32
+// V8M_MAINLINE_DSP: __ARM_FEATURE_DSP 1
+// V8M_MAINLINE_DSP: __ARM_FP 0xE
+// V8M_MAINLINE_DSP: __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1
+
 // RUN: %clang -target arm-none-linux-gnu -x c -E -dM %s -o - | FileCheck --check-prefix=CHECK-DEFS %s
 // CHECK-DEFS:#define __ARM_PCS 1
 // CHECK-DEFS:#define __ARM_SIZEOF_MINIMAL_ENUM 4
Index: test/Driver/arm-features.c
===
--- test/Driver/arm-features.c
+++ test/Driver/arm-features.c
@@ -4,10 +4,16 @@
 // RUN: %clang -target arm-none-none-eabi -mcpu=generic+crypto -march=armv8a -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-CRYPTO %s
 // RUN: %clang -target arm-none-none-eabi -mcpu=generic -march=armv8a+crypto -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-CRYPTO %s
 // CHECK-CRYPTO: "-cc1"{{.*}} "-triple" "armv8-{{.*}} "-target-cpu" "generic"{{.*}} "-target-feature" "+crypto"
+// RUN: %clang -target arm-none-none-eabi -mcpu=generic+dsp -march=armv8m.main -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-DSP %s
+// RUN: %clang -target arm-none-none-eabi -mcpu=generic -march=armv8m.main+dsp -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-DSP %s
+// CHECK-DSP: "-cc1"{{.*}} "-triple" "thumbv8m.main-{{.*}} "-target-cpu" "generic"{{.*}} "-target-feature" "+dsp"
 
 // RUN: %clang -target arm-none-none-eabi -mcpu=generic+nocrc -march=armv8a -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-NOCRC %s
 // RUN: %clang -target arm-none-none-eabi -mcpu=generic -march=armv8a+nocrc -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-NOCRC %s
 // CHECK-NOCRC: "-cc1"{{.*}} "-triple" "armv8-{{.*}} "-target-cpu" "generic"{{.*}} "-target-feature" "-crc"
 // RUN: %clang -target arm-none-none-eabi -mcpu=generic+nocrypto -march=armv8a -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-NOCRYPTO %s
 // RUN: %clang -target arm-none-none-eabi -mcpu=generic -march=armv8a+nocrypto -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-NOCRYPTO %s
 // CHECK-NOCRYPTO: "-cc1"{{.*}} "-triple" "armv8-{{.*}} "-target-cpu" "generic"{{.*}} "-target-feature" "-crypto"
+// RUN: %clang -target arm-none-none-eabi -mcpu=generic+nodsp -march=armv8m.main -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-NODSP %s
+// RUN: %clang -target arm-none-none-eabi -mcpu=generic -march=armv8m.main+nodsp -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-NODSP %s
+// CHECK-NODSP: "-cc1"{{.*}} "-triple" "thumbv8m.main-{{.*}} "-target-cpu" "generic"{{.*}} "-target-feature" "-dsp"
Index: test/Driver/arm-cortex-cpus.c
===
--- test/Driver/arm-cortex-cpus.c
+++ test/Driver/arm-cortex-cpus.c
@@ -230,6 +230,24 @@
 // RUN: %clang -target arm -march=armebv8.1-a -mbig-endian -mthumb -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-BE-V81A-

[clang-tools-extra] r256756 - Rename the CERT namespace to cert, and update some checkers to use this namespace consistently.

[Aaron Ballman via cfe-commits]

Author: aaronballman
Date: Mon Jan  4 08:31:14 2016
New Revision: 256756

URL: http://llvm.org/viewvc/llvm-project?rev=256756&view=rev
Log:
Rename the CERT namespace to cert, and update some checkers to use this 
namespace consistently.

Patch thanks to Haojian Wu!

Modified:
clang-tools-extra/trunk/clang-tidy/cert/CERTTidyModule.cpp
clang-tools-extra/trunk/clang-tidy/cert/SetLongJmpCheck.cpp
clang-tools-extra/trunk/clang-tidy/cert/SetLongJmpCheck.h
clang-tools-extra/trunk/clang-tidy/cert/StaticObjectExceptionCheck.cpp
clang-tools-extra/trunk/clang-tidy/cert/StaticObjectExceptionCheck.h
clang-tools-extra/trunk/clang-tidy/cert/ThrownExceptionTypeCheck.cpp
clang-tools-extra/trunk/clang-tidy/cert/ThrownExceptionTypeCheck.h
clang-tools-extra/trunk/clang-tidy/cert/VariadicFunctionDefCheck.cpp
clang-tools-extra/trunk/clang-tidy/cert/VariadicFunctionDefCheck.h

Modified: clang-tools-extra/trunk/clang-tidy/cert/CERTTidyModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/cert/CERTTidyModule.cpp?rev=256756&r1=256755&r2=256756&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/cert/CERTTidyModule.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/cert/CERTTidyModule.cpp Mon Jan  4 
08:31:14 2016
@@ -23,7 +23,7 @@
 
 namespace clang {
 namespace tidy {
-namespace CERT {
+namespace cert {
 
 class CERTModule : public ClangTidyModule {
 public:
@@ -60,10 +60,10 @@ public:
   }
 };
 
-} // namespace misc
+} // namespace cert
 
 // Register the MiscTidyModule using this statically initialized variable.
-static ClangTidyModuleRegistry::Add
+static ClangTidyModuleRegistry::Add
 X("cert-module",
   "Adds lint checks corresponding to CERT secure coding guidelines.");
 

Modified: clang-tools-extra/trunk/clang-tidy/cert/SetLongJmpCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/cert/SetLongJmpCheck.cpp?rev=256756&r1=256755&r2=256756&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/cert/SetLongJmpCheck.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/cert/SetLongJmpCheck.cpp Mon Jan  4 
08:31:14 2016
@@ -18,6 +18,7 @@ using namespace clang::ast_matchers;
 
 namespace clang {
 namespace tidy {
+namespace cert {
 
 const char SetLongJmpCheck::DiagWording[] =
 "do not call %0; consider using exception handling instead";
@@ -73,5 +74,6 @@ void SetLongJmpCheck::check(const MatchF
   diag(E->getExprLoc(), DiagWording) << cast(E->getCalleeDecl());
 }
 
+} // namespace cert
 } // namespace tidy
 } // namespace clang

Modified: clang-tools-extra/trunk/clang-tidy/cert/SetLongJmpCheck.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/cert/SetLongJmpCheck.h?rev=256756&r1=256755&r2=256756&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/cert/SetLongJmpCheck.h (original)
+++ clang-tools-extra/trunk/clang-tidy/cert/SetLongJmpCheck.h Mon Jan  4 
08:31:14 2016
@@ -14,6 +14,7 @@
 
 namespace clang {
 namespace tidy {
+namespace cert {
 
 /// Guards against use of setjmp/longjmp in C++ code
 ///
@@ -30,8 +31,8 @@ public:
   static const char DiagWording[];
 };
 
+} // namespace cert
 } // namespace tidy
 } // namespace clang
 
 #endif // LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_SETLONGJMPCHECK_H
-

Modified: clang-tools-extra/trunk/clang-tidy/cert/StaticObjectExceptionCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/cert/StaticObjectExceptionCheck.cpp?rev=256756&r1=256755&r2=256756&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/cert/StaticObjectExceptionCheck.cpp 
(original)
+++ clang-tools-extra/trunk/clang-tidy/cert/StaticObjectExceptionCheck.cpp Mon 
Jan  4 08:31:14 2016
@@ -16,6 +16,7 @@ using namespace clang::ast_matchers;
 
 namespace clang {
 namespace tidy {
+namespace cert {
 
 void StaticObjectExceptionCheck::registerMatchers(MatchFinder *Finder) {
   if (!getLangOpts().CPlusPlus)
@@ -44,6 +45,6 @@ void StaticObjectExceptionCheck::check(c
DiagnosticIDs::Note);
 }
 
+} // namespace cert
 } // namespace tidy
 } // namespace clang
-

Modified: clang-tools-extra/trunk/clang-tidy/cert/StaticObjectExceptionCheck.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/cert/StaticObjectExceptionCheck.h?rev=256756&r1=256755&r2=256756&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/cert/StaticObjectExceptionCheck.h 
(original)
+++ clang-tools-extra/trunk/clang-tidy/cert/StaticObjectExceptionCheck.h Mon 
Jan  4 08:31:14 2016
@@ -14,6 +14,7 @@
 
 namespace clang {
 namespace tidy {
+namespace cert {
 
 /// Checks whether the constructor for a static o

Re: [PATCH] D15710: [clang-tidy] Add non-inline function definition and variable definition check in header files.

[Haojian Wu via cfe-commits]

hokein updated this revision to Diff 43886.
hokein added a comment.

Move header file check to AST matcher.


http://reviews.llvm.org/D15710

Files:
  clang-tidy/misc/CMakeLists.txt
  clang-tidy/misc/DefinitionsInHeadersCheck.cpp
  clang-tidy/misc/DefinitionsInHeadersCheck.h
  clang-tidy/misc/MiscTidyModule.cpp
  docs/clang-tidy/checks/list.rst
  docs/clang-tidy/checks/misc-definitions-in-headers.rst
  test/clang-tidy/check_clang_tidy.py
  test/clang-tidy/misc-definitions-in-headers.hpp
  test/lit.cfg

Index: test/lit.cfg
===
--- test/lit.cfg
+++ test/lit.cfg
@@ -43,7 +43,8 @@
 config.test_format = lit.formats.ShTest(execute_external)
 
 # suffixes: A list of file extensions to treat as test files.
-config.suffixes = ['.c', '.cpp', '.m', '.mm', '.cu', '.ll', '.cl', '.s', '.modularize', '.module-map-checker']
+config.suffixes = ['.c', '.cpp', '.m', '.mm', '.cu', '.ll', '.cl', '.s',
+  '.modularize', '.module-map-checker', '.hpp']
 
 # Test-time dependencies located in directories called 'Inputs' are excluded
 # from test suites; there won't be any lit tests within them.
Index: test/clang-tidy/misc-definitions-in-headers.hpp
===
--- /dev/null
+++ test/clang-tidy/misc-definitions-in-headers.hpp
@@ -0,0 +1,131 @@
+// RUN: %check_clang_tidy %s misc-definitions-in-headers %t
+
+int f() {
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: function definition is not allowed in header file [misc-definitions-in-headers]
+// CHECK-FIXES: inline int f() {
+  return 1;
+}
+
+class CA {
+  void f1() {} // ok
+  void f2();
+  template
+  T f3() {  // ok
+T a = 1;
+return a;
+  }
+  template
+  struct CAA {
+struct CAB {
+  void f4(); // ok
+};
+  };
+  static void f4(); // ok
+};
+
+void CA::f2() { }
+// CHECK-MESSAGES: :[[@LINE-1]]:10: warning: function definition is not allowed in header file [misc-definitions-in-headers]
+// CHECK-FIXES: inline void CA::f2() {
+
+template <>
+int CA::f3() {
+// CHECK-MESSAGES: :[[@LINE-1]]:9: warning: function definition is not allowed in header file [misc-definitions-in-headers]
+  int a = 1;
+  return a;
+}
+
+template 
+void CA::CAA::CAB::f4() { // ok
+}
+
+template 
+struct CB {
+  void f1();
+  struct CCA {
+void f2(T a);
+  };
+  struct CCB;  // ok
+  static int a; // ok
+};
+
+template 
+void CB::f1() { // ok
+}
+
+template 
+void CB::CCA::f2(T a) { // ok
+}
+
+template 
+struct CB::CCB {
+  void f3();
+};
+
+template 
+void CB::CCB::f3() { // ok
+}
+
+template 
+int CB::a = 2; // ok;
+
+template 
+T tf() { // ok
+  T a;
+  return a;
+}
+
+
+namespace NA {
+  int f() { return 1; }
+// CHECK-MESSAGES: :[[@LINE-1]]:7: warning: function definition is not allowed in header file [misc-definitions-in-headers]
+// CHECK-FIXES: inline int f() { return 1; }
+}
+
+template 
+T f3() {
+  T a = 1;
+  return a;
+}
+
+template <>
+// CHECK-MESSAGES: :[[@LINE+1]]:5: warning: function definition is not allowed in header file [misc-definitions-in-headers]
+int f3() {
+  int a = 1;
+  return a;
+}
+
+int f5(); // ok
+inline int f6() { return 1; } // ok
+namespace {
+  int f7() { return 1; } // ok
+}
+
+int a = 1;
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: variable definition is not allowed in header file [misc-definitions-in-headers]
+CA a1;
+// CHECK-MESSAGES: :[[@LINE-1]]:4: warning: variable definition is not allowed in header file [misc-definitions-in-headers]
+
+namespace NB {
+  int b = 1;
+// CHECK-MESSAGES: :[[@LINE-1]]:7: warning: variable definition is not allowed in header file [misc-definitions-in-headers]
+  const int c = 1; // ok;
+}
+
+class CC {
+  static int d;
+};
+
+int CC::d = 1;
+// CHECK-MESSAGES: :[[@LINE-1]]:9: warning: variable definition is not allowed in header file [misc-definitions-in-headers]
+
+const char* ca = "foo";
+// CHECK-MESSAGES: :[[@LINE-1]]:13: warning: variable definition is not allowed in header file [misc-definitions-in-headers]
+
+namespace {
+  int e = 2; // ok
+}
+
+const char* const g = "foo"; // ok
+static int h = 1; // ok
+const int i = 1; // ok
+extern int j; // ok
Index: test/clang-tidy/check_clang_tidy.py
===
--- test/clang-tidy/check_clang_tidy.py
+++ test/clang-tidy/check_clang_tidy.py
@@ -52,6 +52,8 @@
   extension = '.cpp'
   if (input_file_name.endswith('.c')):
 extension = '.c'
+  if (input_file_name.endswith('.hpp')):
+extension = '.hpp'
   temp_file_name = temp_file_name + extension
 
   clang_tidy_extra_args = extra_args
Index: docs/clang-tidy/checks/misc-definitions-in-headers.rst
===
--- /dev/null
+++ docs/clang-tidy/checks/misc-definitions-in-headers.rst
@@ -0,0 +1,36 @@
+misc-definitions-in-headers
+===
+
+Finds non-extern non-inline function and variable definitions in header files, which can lead to potential ODR violations.
+

Re: [PATCH] D15805: [clang-tidy] Cleanup code in CERT module.

[Aaron Ballman via cfe-commits]

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

I've commit in r256756, thanks!


http://reviews.llvm.org/D15805



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

Re: [PATCH] D15223: [ARM] [AARCH64] Add CodeGen IR tests for {VS}QRDML{AS}H v8.1a intrinsics.

[Alexandros Lamprineas via cfe-commits]

labrinea updated the summary for this revision.
labrinea updated this revision to Diff 43885.
labrinea added a comment.

Disabled optimizers.


http://reviews.llvm.org/D15223

Files:
  test/CodeGen/aarch64-v8.1a-neon-intrinsics.c
  test/CodeGen/arm-v8.1a-neon-intrinsics.c

Index: test/CodeGen/arm-v8.1a-neon-intrinsics.c
===
--- test/CodeGen/arm-v8.1a-neon-intrinsics.c
+++ test/CodeGen/arm-v8.1a-neon-intrinsics.c
@@ -1,122 +1,187 @@
 // RUN: %clang_cc1 -triple armv8.1a-linux-gnu -target-feature +neon \
-// RUN:  -O3 -S -o - %s \
+// RUN:  -S -emit-llvm -o - %s \
 // RUN:  | FileCheck %s --check-prefix=CHECK --check-prefix=CHECK-ARM
+
 // RUN: %clang_cc1 -triple aarch64-linux-gnu -target-feature +neon \
-// RUN:  -target-feature +v8.1a -O3 -S -o - %s \
+// RUN:  -target-feature +v8.1a -S -emit-llvm -o - %s \
 // RUN:  | FileCheck %s --check-prefix=CHECK --check-prefix=CHECK-AARCH64
+
 // REQUIRES: arm-registered-target,aarch64-registered-target
 
 #include 
 
 // CHECK-LABEL: test_vqrdmlah_s16
 int16x4_t test_vqrdmlah_s16(int16x4_t a, int16x4_t b, int16x4_t c) {
-// CHECK-ARM: vqrdmlah.s16 d{{[0-9]+}}, d{{[0-9]+}}, d{{[0-9]+}}
-// CHECK-AARCH64: sqrdmlah {{v[0-9]+}}.4h, {{v[0-9]+}}.4h, {{v[0-9]+}}.4h
+// CHECK-ARM: call <4 x i16> @llvm.arm.neon.vqrdmulh.v4i16(<4 x i16> {{%.*}}, <4 x i16> {{%.*}})
+// CHECK-ARM: call <4 x i16> @llvm.arm.neon.vqadds.v4i16(<4 x i16> {{%.*}}, <4 x i16> {{%.*}})
+
+// CHECK-AARCH64: call <4 x i16> @llvm.aarch64.neon.sqrdmulh.v4i16(<4 x i16> {{%.*}}, <4 x i16> {{%.*}})
+// CHECK-AARCH64: call <4 x i16> @llvm.aarch64.neon.sqadd.v4i16(<4 x i16> {{%.*}}, <4 x i16> {{%.*}})
   return vqrdmlah_s16(a, b, c);
 }
 
 // CHECK-LABEL: test_vqrdmlah_s32
 int32x2_t test_vqrdmlah_s32(int32x2_t a, int32x2_t b, int32x2_t c) {
-// CHECK-ARM: vqrdmlah.s32 d{{[0-9]+}}, d{{[0-9]+}}, d{{[0-9]+}}
-// CHECK-AARCH64: sqrdmlah {{v[0-9]+}}.2s, {{v[0-9]+}}.2s, {{v[0-9]+}}.2s
+// CHECK-ARM: call <2 x i32> @llvm.arm.neon.vqrdmulh.v2i32(<2 x i32> {{%.*}}, <2 x i32> {{%.*}})
+// CHECK-ARM: call <2 x i32> @llvm.arm.neon.vqadds.v2i32(<2 x i32> {{%.*}}, <2 x i32> {{%.*}})
+
+// CHECK-AARCH64: call <2 x i32> @llvm.aarch64.neon.sqrdmulh.v2i32(<2 x i32> {{%.*}}, <2 x i32> {{%.*}})
+// CHECK-AARCH64: call <2 x i32> @llvm.aarch64.neon.sqadd.v2i32(<2 x i32> {{%.*}}, <2 x i32> {{%.*}})
   return vqrdmlah_s32(a, b, c);
 }
 
 // CHECK-LABEL: test_vqrdmlahq_s16
 int16x8_t test_vqrdmlahq_s16(int16x8_t a, int16x8_t b, int16x8_t c) {
-// CHECK-ARM: vqrdmlah.s16 q{{[0-9]+}}, q{{[0-9]+}}, q{{[0-9]+}}
-// CHECK-AARCH64: sqrdmlah {{v[0-9]+}}.8h, {{v[0-9]+}}.8h, {{v[0-9]+}}.8h
+// CHECK-ARM: call <8 x i16> @llvm.arm.neon.vqrdmulh.v8i16(<8 x i16> {{%.*}}, <8 x i16> {{%.*}})
+// CHECK-ARM: call <8 x i16> @llvm.arm.neon.vqadds.v8i16(<8 x i16> {{%.*}}, <8 x i16> {{%.*}})
+
+// CHECK-AARCH64: call <8 x i16> @llvm.aarch64.neon.sqrdmulh.v8i16(<8 x i16> {{%.*}}, <8 x i16> {{%.*}})
+// CHECK-AARCH64: call <8 x i16> @llvm.aarch64.neon.sqadd.v8i16(<8 x i16> {{%.*}}, <8 x i16> {{%.*}})
   return vqrdmlahq_s16(a, b, c);
 }
 
 // CHECK-LABEL: test_vqrdmlahq_s32
 int32x4_t test_vqrdmlahq_s32(int32x4_t a, int32x4_t b, int32x4_t c) {
-// CHECK-ARM: vqrdmlah.s32 q{{[0-9]+}}, q{{[0-9]+}}, q{{[0-9]+}}
-// CHECK-AARCH64: sqrdmlah {{v[0-9]+}}.4s, {{v[0-9]+}}.4s, {{v[0-9]+}}.4s
+// CHECK-ARM: call <4 x i32> @llvm.arm.neon.vqrdmulh.v4i32(<4 x i32> {{%.*}}, <4 x i32> {{%.*}})
+// CHECK-ARM: call <4 x i32> @llvm.arm.neon.vqadds.v4i32(<4 x i32> {{%.*}}, <4 x i32> {{%.*}})
+
+// CHECK-AARCH64: call <4 x i32> @llvm.aarch64.neon.sqrdmulh.v4i32(<4 x i32> {{%.*}}, <4 x i32> {{%.*}})
+// CHECK-AARCH64: call <4 x i32> @llvm.aarch64.neon.sqadd.v4i32(<4 x i32> {{%.*}}, <4 x i32> {{%.*}})
   return vqrdmlahq_s32(a, b, c);
 }
 
 // CHECK-LABEL: test_vqrdmlah_lane_s16
 int16x4_t test_vqrdmlah_lane_s16(int16x4_t a, int16x4_t b, int16x4_t c) {
-// CHECK-ARM: vqrdmlah.s16 d{{[0-9]+}}, d{{[0-9]+}}, d{{[0-9]+}}[3]
-// CHECK-AARCH64: sqrdmlah {{v[0-9]+}}.4h, {{v[0-9]+}}.4h, {{v[0-9]+}}.h[3]
+// CHECK-ARM: shufflevector <4 x i16> {{%.*}}, <4 x i16> {{%.*}}, <4 x i32> 
+// CHECK-ARM: call <4 x i16> @llvm.arm.neon.vqrdmulh.v4i16(<4 x i16> {{%.*}}, <4 x i16> {{%.*}})
+// CHECK-ARM: call <4 x i16> @llvm.arm.neon.vqadds.v4i16(<4 x i16> {{%.*}}, <4 x i16> {{%.*}})
+
+// CHECK-AARCH64: shufflevector <4 x i16> {{%.*}}, <4 x i16> {{%.*}}, <4 x i32> 
+// CHECK-AARCH64: call <4 x i16> @llvm.aarch64.neon.sqrdmulh.v4i16(<4 x i16> {{%.*}}, <4 x i16> {{%.*}})
+// CHECK-AARCH64: call <4 x i16> @llvm.aarch64.neon.sqadd.v4i16(<4 x i16> {{%.*}}, <4 x i16> {{%.*}})
   return vqrdmlah_lane_s16(a, b, c, 3);
 }
 
 // CHECK-LABEL: test_vqrdmlah_lane_s32
 int32x2_t test_vqrdmlah_lane_s32(int32x2_t a, int32x2_t b, int32x2_t c) {
-// CHECK-ARM: vqrdmlah.s32 d{{[0-9]+}}, d{{[0-9]+}}, d{{[0-9]+}}[1]
-// CHECK-AARCH64: sqrdmlah {{v[0-9]+}}.2s, {{v[0-9]+}}.2s, {{v[0-9]+}}.s[1]
+// CHECK-ARM: shufflevector <2 x i32> {{%.*}}, <2 x i32> {{%.*}}, <

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

[Ben Craig via cfe-commits]

bcraig added a comment.

Ping.
If desired, I could provide an alternative implementation where all the structs 
are allocated at global scope with their original padding.


http://reviews.llvm.org/D15539



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

Re: [PATCH] D15710: [clang-tidy] Add non-inline function definition and variable definition check in header files.

[Alexander Kornienko via cfe-commits]

alexfh added inline comments.


Comment at: clang-tidy/misc/DefinitionsInHeadersCheck.cpp:24
@@ +23,3 @@
+   .bind("name-decl"),
+  this);
+}

We're looking at the problem from different angles. My view is that a 
reasonable file naming convention (which at least makes interface header files, 
textual headers and main files distinguishable) is a widespread enough 
practice, and the benefits it brings outweigh the costs of enforcing it. 
However, the opposite point of view also has its right to exist, so we need a 
solution that fits both ;)

> Perhaps another solution to this is use isInMainFile() || 
> usesHeaderFileExtension().

You probably meant `!isInMainFile() || usesHeaderFileExtension()`. I guess, 
that will work for us. We could also make the list of header file extensions 
(or a regular expression pattern for header files) configurable, so that the 
`usesHeaderFileExtension()` part could be disabled, if needed.


http://reviews.llvm.org/D15710



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

Re: [PATCH] D15710: [clang-tidy] Add non-inline function definition and variable definition check in header files.

[Aaron Ballman via cfe-commits]

aaron.ballman added inline comments.


Comment at: clang-tidy/misc/DefinitionsInHeadersCheck.cpp:25
@@ +24,3 @@
+  SourceLocation ExpansionLoc = SM.getExpansionLoc(Node.getLocStart());
+  StringRef Filename = SM.getFilename(ExpansionLoc);
+  return Filename.endswith(".h") || Filename.endswith(".hh") ||

> We're looking at the problem from different angles. My view is that a 
> reasonable file naming convention (which at least makes interface header 
> files, textual headers and main files distinguishable) is a widespread enough 
> practice, and the benefits it brings outweigh the costs of enforcing it. 
> However, the opposite point of view also has its right to exist, so we need a 
> solution that fits both ;)
>> Perhaps another solution to this is use isInMainFile() || 
>> usesHeaderFileExtension().
>You probably meant !isInMainFile() || usesHeaderFileExtension(). I guess, that 
>will work for us. We could also make the list of header file extensions (or a 
>regular expression pattern for header files) configurable, so that the 
>usesHeaderFileExtension() part could be disabled, if needed.

Oops, you are correct, I meant !isInMainFile(). :-) I definitely agree that we 
should make the header file extensions configurable. Would it make sense if 
this were a global option that any checker can use? We have 3-4 other checkers 
that care about header files as well, and it would be nice if they all behaved 
consistently without the user having to write a lot of options for each checker.


http://reviews.llvm.org/D15710



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

Re: [PATCH] D15710: [clang-tidy] Add non-inline function definition and variable definition check in header files.

[Haojian Wu via cfe-commits]

hokein marked an inline comment as done.


Comment at: clang-tidy/misc/DefinitionsInHeadersCheck.cpp:25
@@ +24,3 @@
+  SourceLocation ExpansionLoc = SM.getExpansionLoc(Node.getLocStart());
+  StringRef Filename = SM.getFilename(ExpansionLoc);
+  return Filename.endswith(".h") || Filename.endswith(".hh") ||

aaron.ballman wrote:
> > We're looking at the problem from different angles. My view is that a 
> > reasonable file naming convention (which at least makes interface header 
> > files, textual headers and main files distinguishable) is a widespread 
> > enough practice, and the benefits it brings outweigh the costs of enforcing 
> > it. However, the opposite point of view also has its right to exist, so we 
> > need a solution that fits both ;)
> >> Perhaps another solution to this is use isInMainFile() || 
> >> usesHeaderFileExtension().
> >You probably meant !isInMainFile() || usesHeaderFileExtension(). I guess, 
> >that will work for us. We could also make the list of header file extensions 
> >(or a regular expression pattern for header files) configurable, so that the 
> >usesHeaderFileExtension() part could be disabled, if needed.
> 
> Oops, you are correct, I meant !isInMainFile(). :-) I definitely agree that 
> we should make the header file extensions configurable. Would it make sense 
> if this were a global option that any checker can use? We have 3-4 other 
> checkers that care about header files as well, and it would be nice if they 
> all behaved consistently without the user having to write a lot of options 
> for each checker.
I'm :+1 on making header file extensions configurable. I think we can do that 
in a new patch.


http://reviews.llvm.org/D15710



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

Re: [PATCH] D15710: [clang-tidy] Add non-inline function definition and variable definition check in header files.

[Alexander Kornienko via cfe-commits]

alexfh added inline comments.


Comment at: clang-tidy/misc/DefinitionsInHeadersCheck.cpp:25
@@ +24,3 @@
+  SourceLocation ExpansionLoc = SM.getExpansionLoc(Node.getLocStart());
+  StringRef Filename = SM.getFilename(ExpansionLoc);
+  return Filename.endswith(".h") || Filename.endswith(".hh") ||

hokein wrote:
> aaron.ballman wrote:
> > > We're looking at the problem from different angles. My view is that a 
> > > reasonable file naming convention (which at least makes interface header 
> > > files, textual headers and main files distinguishable) is a widespread 
> > > enough practice, and the benefits it brings outweigh the costs of 
> > > enforcing it. However, the opposite point of view also has its right to 
> > > exist, so we need a solution that fits both ;)
> > >> Perhaps another solution to this is use isInMainFile() || 
> > >> usesHeaderFileExtension().
> > >You probably meant !isInMainFile() || usesHeaderFileExtension(). I guess, 
> > >that will work for us. We could also make the list of header file 
> > >extensions (or a regular expression pattern for header files) 
> > >configurable, so that the usesHeaderFileExtension() part could be 
> > >disabled, if needed.
> > 
> > Oops, you are correct, I meant !isInMainFile(). :-) I definitely agree that 
> > we should make the header file extensions configurable. Would it make sense 
> > if this were a global option that any checker can use? We have 3-4 other 
> > checkers that care about header files as well, and it would be nice if they 
> > all behaved consistently without the user having to write a lot of options 
> > for each checker.
> I'm :+1 on making header file extensions configurable. I think we can do that 
> in a new patch.
Having to configure this in a single place would be convenient. OTOH, I can 
imagine corner-cases, where a single option would be undesired. One thing we 
could do is to allow global options that can be overridden for each check. 
Something along the lines of (modulo tests):

```
  std::string OptionsView::get(StringRef LocalName, std::string Default) const {
-   const auto &Iter = CheckOptions.find(NamePrefix + LocalName.str());
+   auto Iter = CheckOptions.find(NamePrefix + LocalName.str());
if (Iter != CheckOptions.end())
  return Iter->second;
+   // Fallback to global setting, if present.
+   Iter = CheckOptions.find(LocalName.str());
+   if (Iter != CheckOptions.end())
+ return Iter->second;
return Default;
  }
```

Alternatively, we could add another method (e.g. `getLocalOrGlobal`) to make 
the usage of the global setting explicit.

What do you think?


http://reviews.llvm.org/D15710



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

Re: [PATCH] D15710: [clang-tidy] Add non-inline function definition and variable definition check in header files.

[Alexander Kornienko via cfe-commits]

alexfh added inline comments.


Comment at: clang-tidy/misc/DefinitionsInHeadersCheck.cpp:25
@@ +24,3 @@
+  SourceLocation ExpansionLoc = SM.getExpansionLoc(Node.getLocStart());
+  StringRef Filename = SM.getFilename(ExpansionLoc);
+  return Filename.endswith(".h") || Filename.endswith(".hh") ||

alexfh wrote:
> hokein wrote:
> > aaron.ballman wrote:
> > > > We're looking at the problem from different angles. My view is that a 
> > > > reasonable file naming convention (which at least makes interface 
> > > > header files, textual headers and main files distinguishable) is a 
> > > > widespread enough practice, and the benefits it brings outweigh the 
> > > > costs of enforcing it. However, the opposite point of view also has its 
> > > > right to exist, so we need a solution that fits both ;)
> > > >> Perhaps another solution to this is use isInMainFile() || 
> > > >> usesHeaderFileExtension().
> > > >You probably meant !isInMainFile() || usesHeaderFileExtension(). I 
> > > >guess, that will work for us. We could also make the list of header file 
> > > >extensions (or a regular expression pattern for header files) 
> > > >configurable, so that the usesHeaderFileExtension() part could be 
> > > >disabled, if needed.
> > > 
> > > Oops, you are correct, I meant !isInMainFile(). :-) I definitely agree 
> > > that we should make the header file extensions configurable. Would it 
> > > make sense if this were a global option that any checker can use? We have 
> > > 3-4 other checkers that care about header files as well, and it would be 
> > > nice if they all behaved consistently without the user having to write a 
> > > lot of options for each checker.
> > I'm :+1 on making header file extensions configurable. I think we can do 
> > that in a new patch.
> Having to configure this in a single place would be convenient. OTOH, I can 
> imagine corner-cases, where a single option would be undesired. One thing we 
> could do is to allow global options that can be overridden for each check. 
> Something along the lines of (modulo tests):
> 
> ```
>   std::string OptionsView::get(StringRef LocalName, std::string Default) 
> const {
> -   const auto &Iter = CheckOptions.find(NamePrefix + LocalName.str());
> +   auto Iter = CheckOptions.find(NamePrefix + LocalName.str());
> if (Iter != CheckOptions.end())
>   return Iter->second;
> +   // Fallback to global setting, if present.
> +   Iter = CheckOptions.find(LocalName.str());
> +   if (Iter != CheckOptions.end())
> + return Iter->second;
> return Default;
>   }
> ```
> 
> Alternatively, we could add another method (e.g. `getLocalOrGlobal`) to make 
> the usage of the global setting explicit.
> 
> What do you think?
This should read "Having a way to configure this in a single place ..."


http://reviews.llvm.org/D15710



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

Re: [PATCH] D15710: [clang-tidy] Add non-inline function definition and variable definition check in header files.

[Alexander Kornienko via cfe-commits]

alexfh added inline comments.


Comment at: clang-tidy/misc/DefinitionsInHeadersCheck.cpp:25
@@ +24,3 @@
+  SourceLocation ExpansionLoc = SM.getExpansionLoc(Node.getLocStart());
+  StringRef Filename = SM.getFilename(ExpansionLoc);
+  return Filename.endswith(".h") || Filename.endswith(".hh") ||

alexfh wrote:
> alexfh wrote:
> > hokein wrote:
> > > aaron.ballman wrote:
> > > > > We're looking at the problem from different angles. My view is that a 
> > > > > reasonable file naming convention (which at least makes interface 
> > > > > header files, textual headers and main files distinguishable) is a 
> > > > > widespread enough practice, and the benefits it brings outweigh the 
> > > > > costs of enforcing it. However, the opposite point of view also has 
> > > > > its right to exist, so we need a solution that fits both ;)
> > > > >> Perhaps another solution to this is use isInMainFile() || 
> > > > >> usesHeaderFileExtension().
> > > > >You probably meant !isInMainFile() || usesHeaderFileExtension(). I 
> > > > >guess, that will work for us. We could also make the list of header 
> > > > >file extensions (or a regular expression pattern for header files) 
> > > > >configurable, so that the usesHeaderFileExtension() part could be 
> > > > >disabled, if needed.
> > > > 
> > > > Oops, you are correct, I meant !isInMainFile(). :-) I definitely agree 
> > > > that we should make the header file extensions configurable. Would it 
> > > > make sense if this were a global option that any checker can use? We 
> > > > have 3-4 other checkers that care about header files as well, and it 
> > > > would be nice if they all behaved consistently without the user having 
> > > > to write a lot of options for each checker.
> > > I'm :+1 on making header file extensions configurable. I think we can do 
> > > that in a new patch.
> > Having to configure this in a single place would be convenient. OTOH, I can 
> > imagine corner-cases, where a single option would be undesired. One thing 
> > we could do is to allow global options that can be overridden for each 
> > check. Something along the lines of (modulo tests):
> > 
> > ```
> >   std::string OptionsView::get(StringRef LocalName, std::string Default) 
> > const {
> > -   const auto &Iter = CheckOptions.find(NamePrefix + LocalName.str());
> > +   auto Iter = CheckOptions.find(NamePrefix + LocalName.str());
> > if (Iter != CheckOptions.end())
> >   return Iter->second;
> > +   // Fallback to global setting, if present.
> > +   Iter = CheckOptions.find(LocalName.str());
> > +   if (Iter != CheckOptions.end())
> > + return Iter->second;
> > return Default;
> >   }
> > ```
> > 
> > Alternatively, we could add another method (e.g. `getLocalOrGlobal`) to 
> > make the usage of the global setting explicit.
> > 
> > What do you think?
> This should read "Having a way to configure this in a single place ..."
> I'm :+1 on making header file extensions configurable. I think we can do that 
> in a new patch.

Yep, this is fine for a follow-up.


http://reviews.llvm.org/D15710



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

Re: [PATCH] D15710: [clang-tidy] Add non-inline function definition and variable definition check in header files.

[Haojian Wu via cfe-commits]

hokein updated this revision to Diff 43887.
hokein added a comment.

Add !inMainFile check.


http://reviews.llvm.org/D15710

Files:
  clang-tidy/misc/CMakeLists.txt
  clang-tidy/misc/DefinitionsInHeadersCheck.cpp
  clang-tidy/misc/DefinitionsInHeadersCheck.h
  clang-tidy/misc/MiscTidyModule.cpp
  docs/clang-tidy/checks/list.rst
  docs/clang-tidy/checks/misc-definitions-in-headers.rst
  test/clang-tidy/check_clang_tidy.py
  test/clang-tidy/misc-definitions-in-headers.hpp
  test/lit.cfg

Index: test/lit.cfg
===
--- test/lit.cfg
+++ test/lit.cfg
@@ -43,7 +43,8 @@
 config.test_format = lit.formats.ShTest(execute_external)
 
 # suffixes: A list of file extensions to treat as test files.
-config.suffixes = ['.c', '.cpp', '.m', '.mm', '.cu', '.ll', '.cl', '.s', '.modularize', '.module-map-checker']
+config.suffixes = ['.c', '.cpp', '.m', '.mm', '.cu', '.ll', '.cl', '.s',
+  '.modularize', '.module-map-checker', '.hpp']
 
 # Test-time dependencies located in directories called 'Inputs' are excluded
 # from test suites; there won't be any lit tests within them.
Index: test/clang-tidy/misc-definitions-in-headers.hpp
===
--- /dev/null
+++ test/clang-tidy/misc-definitions-in-headers.hpp
@@ -0,0 +1,131 @@
+// RUN: %check_clang_tidy %s misc-definitions-in-headers %t
+
+int f() {
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: function definition is not allowed in header file [misc-definitions-in-headers]
+// CHECK-FIXES: inline int f() {
+  return 1;
+}
+
+class CA {
+  void f1() {} // ok
+  void f2();
+  template
+  T f3() {  // ok
+T a = 1;
+return a;
+  }
+  template
+  struct CAA {
+struct CAB {
+  void f4(); // ok
+};
+  };
+  static void f4(); // ok
+};
+
+void CA::f2() { }
+// CHECK-MESSAGES: :[[@LINE-1]]:10: warning: function definition is not allowed in header file [misc-definitions-in-headers]
+// CHECK-FIXES: inline void CA::f2() {
+
+template <>
+int CA::f3() {
+// CHECK-MESSAGES: :[[@LINE-1]]:9: warning: function definition is not allowed in header file [misc-definitions-in-headers]
+  int a = 1;
+  return a;
+}
+
+template 
+void CA::CAA::CAB::f4() { // ok
+}
+
+template 
+struct CB {
+  void f1();
+  struct CCA {
+void f2(T a);
+  };
+  struct CCB;  // ok
+  static int a; // ok
+};
+
+template 
+void CB::f1() { // ok
+}
+
+template 
+void CB::CCA::f2(T a) { // ok
+}
+
+template 
+struct CB::CCB {
+  void f3();
+};
+
+template 
+void CB::CCB::f3() { // ok
+}
+
+template 
+int CB::a = 2; // ok;
+
+template 
+T tf() { // ok
+  T a;
+  return a;
+}
+
+
+namespace NA {
+  int f() { return 1; }
+// CHECK-MESSAGES: :[[@LINE-1]]:7: warning: function definition is not allowed in header file [misc-definitions-in-headers]
+// CHECK-FIXES: inline int f() { return 1; }
+}
+
+template 
+T f3() {
+  T a = 1;
+  return a;
+}
+
+template <>
+// CHECK-MESSAGES: :[[@LINE+1]]:5: warning: function definition is not allowed in header file [misc-definitions-in-headers]
+int f3() {
+  int a = 1;
+  return a;
+}
+
+int f5(); // ok
+inline int f6() { return 1; } // ok
+namespace {
+  int f7() { return 1; } // ok
+}
+
+int a = 1;
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: variable definition is not allowed in header file [misc-definitions-in-headers]
+CA a1;
+// CHECK-MESSAGES: :[[@LINE-1]]:4: warning: variable definition is not allowed in header file [misc-definitions-in-headers]
+
+namespace NB {
+  int b = 1;
+// CHECK-MESSAGES: :[[@LINE-1]]:7: warning: variable definition is not allowed in header file [misc-definitions-in-headers]
+  const int c = 1; // ok;
+}
+
+class CC {
+  static int d;
+};
+
+int CC::d = 1;
+// CHECK-MESSAGES: :[[@LINE-1]]:9: warning: variable definition is not allowed in header file [misc-definitions-in-headers]
+
+const char* ca = "foo";
+// CHECK-MESSAGES: :[[@LINE-1]]:13: warning: variable definition is not allowed in header file [misc-definitions-in-headers]
+
+namespace {
+  int e = 2; // ok
+}
+
+const char* const g = "foo"; // ok
+static int h = 1; // ok
+const int i = 1; // ok
+extern int j; // ok
Index: test/clang-tidy/check_clang_tidy.py
===
--- test/clang-tidy/check_clang_tidy.py
+++ test/clang-tidy/check_clang_tidy.py
@@ -52,6 +52,8 @@
   extension = '.cpp'
   if (input_file_name.endswith('.c')):
 extension = '.c'
+  if (input_file_name.endswith('.hpp')):
+extension = '.hpp'
   temp_file_name = temp_file_name + extension
 
   clang_tidy_extra_args = extra_args
Index: docs/clang-tidy/checks/misc-definitions-in-headers.rst
===
--- /dev/null
+++ docs/clang-tidy/checks/misc-definitions-in-headers.rst
@@ -0,0 +1,36 @@
+misc-definitions-in-headers
+===
+
+Finds non-extern non-inline function and variable definitions in header files, which can lead to potential ODR violations.
+
+.. code:: c++

Re: r256596 - Emit a -Wmicrosoft warning when treating ^Z as EOF in MS mode.

[Nico Weber via cfe-commits]

On Wed, Dec 30, 2015 at 12:28 PM, Joerg Sonnenberger via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> On Tue, Dec 29, 2015 at 11:17:28PM -, Nico Weber via cfe-commits wrote:
> > Author: nico
> > Date: Tue Dec 29 17:17:27 2015
> > New Revision: 256596
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=256596&view=rev
> > Log:
> > Emit a -Wmicrosoft warning when treating ^Z as EOF in MS mode.
>
> Do they really consider it as EOF for non-interactive use?
>

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

Re: [PATCH] D15710: [clang-tidy] Add non-inline function definition and variable definition check in header files.

[Haojian Wu via cfe-commits]

hokein marked an inline comment as done.


Comment at: docs/clang-tidy/checks/misc-definitions-in-headers.rst:19
@@ +18,3 @@
+   }
+
+   // error

About the internal linkage variable definition, how about only warning the 
variable in unnamed namespace?

The const/static variable definitions in header are used more widely (We also 
find there are a lot of such usages in Google code repo), and Google C++ code 
style doesn't explicitly give suggestions about such const/static usages.


http://reviews.llvm.org/D15710



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

r256758 - clang-format: [JS] Support ES6 exports of array literals.

[Daniel Jasper via cfe-commits]

Author: djasper
Date: Mon Jan  4 09:51:56 2016
New Revision: 256758

URL: http://llvm.org/viewvc/llvm-project?rev=256758&view=rev
Log:
clang-format: [JS] Support ES6 exports of array literals.

Before:
  export default[aaa,
 bb];
  export default[];

After:
  export default [
aaa,
bb
  ];
  export default [];

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

Modified: cfe/trunk/lib/Format/TokenAnnotator.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/TokenAnnotator.cpp?rev=256758&r1=256757&r2=256758&view=diff
==
--- cfe/trunk/lib/Format/TokenAnnotator.cpp (original)
+++ cfe/trunk/lib/Format/TokenAnnotator.cpp Mon Jan  4 09:51:56 2016
@@ -289,7 +289,9 @@ private:
  (Parent &&
   Parent->isOneOf(TT_BinaryOperator, tok::at, tok::comma,
   tok::l_paren, tok::l_square, tok::question,
-  tok::colon, tok::kw_return))) {
+  tok::colon, tok::kw_return,
+  // Should only be relevant to JavaScript:
+  tok::kw_default))) {
 Left->Type = TT_ArrayInitializerLSquare;
   } else {
 BindingIncrease = 10;
@@ -1999,6 +2001,8 @@ bool TokenAnnotator::spaceRequiredBefore
 if (Left.isOneOf(Keywords.kw_let, Keywords.kw_var, TT_JsFatArrow,
  Keywords.kw_in))
   return true;
+if (Left.is(tok::kw_default) && Right.is(TT_ArrayInitializerLSquare))
+  return true; // For "export default [];".
 if (Left.is(Keywords.kw_is) && Right.is(tok::l_brace))
   return true;
 if (Right.isOneOf(TT_JsTypeColon, TT_JsTypeOptionalQuestion))

Modified: cfe/trunk/unittests/Format/FormatTestJS.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Format/FormatTestJS.cpp?rev=256758&r1=256757&r2=256758&view=diff
==
--- cfe/trunk/unittests/Format/FormatTestJS.cpp (original)
+++ cfe/trunk/unittests/Format/FormatTestJS.cpp Mon Jan  4 09:51:56 2016
@@ -865,6 +865,11 @@ TEST_F(FormatTestJS, Modules) {
"  // adsdasd\n"
"  BAZ\n"
"}");
+  verifyFormat("export default [\n"
+   "  aaa,\n"
+   "  bb\n"
+   "];");
+  verifyFormat("export default [];");
 }
 
 TEST_F(FormatTestJS, TemplateStrings) {


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

Re: [PATCH] D15710: [clang-tidy] Add non-inline function definition and variable definition check in header files.

[Alexander Kornienko via cfe-commits]

alexfh added inline comments.


Comment at: clang-tidy/misc/DefinitionsInHeadersCheck.cpp:52
@@ +51,3 @@
+
+  // Internal linkage variable and function definitions are allowed:
+  //   const int a = 1;

I'd say "ignored for now" instead of "allowed". We might want to flag them in 
the future, but these are used quite frequently, so we don't warn on these now 
to keep the number of warnings under control.

Maybe there should be an option for these cases.


Comment at: docs/clang-tidy/checks/misc-definitions-in-headers.rst:8
@@ +7,3 @@
+   // Foo.h
+   int a = 1; // error
+   static int b = 1; // ok

nit: It's a warning, not error. Also, please use proper capitalization and 
punctuation:

```
int a = 1; // Warning.
```

or maybe even include the message:

```
int a = 1; // Warning: "variable definition is not allowed in header file".
```

Same holds for `// ok`: They should either be `// OK.` or maybe explain why 
certain patterns don't generate a warning.


Comment at: test/clang-tidy/misc-definitions-in-headers.hpp:10
@@ +9,3 @@
+class CA {
+  void f1() {} // ok
+  void f2();

The `// ok` comments add no new information. Either explain why are these OK, 
or just remove the comments.


Comment at: test/clang-tidy/misc-definitions-in-headers.hpp:27
@@ +26,3 @@
+void CA::f2() { }
+// CHECK-MESSAGES: :[[@LINE-1]]:10: warning: function definition is not 
allowed in header file [misc-definitions-in-headers]
+// CHECK-FIXES: inline void CA::f2() {

We usually leave each distinct warning message full once and truncate the other 
CHECK-MESSAGES patterns to fit to the 80 characters limit (e.g. here I'd remove 
the `in header file [misc-definitions-in-headers]` part).


Comment at: test/lit.cfg:46
@@ -45,2 +45,3 @@
 # suffixes: A list of file extensions to treat as test files.
-config.suffixes = ['.c', '.cpp', '.m', '.mm', '.cu', '.ll', '.cl', '.s', 
'.modularize', '.module-map-checker']
+config.suffixes = ['.c', '.cpp', '.m', '.mm', '.cu', '.ll', '.cl', '.s',
+  '.modularize', '.module-map-checker', '.hpp']

Please place the new extension after '.cpp' - it seems to be most relevant 
there.


http://reviews.llvm.org/D15710



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

Re: [PATCH] D15710: [clang-tidy] Add non-inline function definition and variable definition check in header files.

[Alexander Kornienko via cfe-commits]

alexfh added inline comments.


Comment at: docs/clang-tidy/checks/misc-definitions-in-headers.rst:19
@@ +18,3 @@
+   }
+
+   // error

hokein wrote:
> About the internal linkage variable definition, how about only warning the 
> variable in unnamed namespace?
> 
> The const/static variable definitions in header are used more widely (We also 
> find there are a lot of such usages in Google code repo), and Google C++ code 
> style doesn't explicitly give suggestions about such const/static usages.
I suggest that we ignore these for now and maybe add an option later.


http://reviews.llvm.org/D15710



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

r256759 - clang-format: [JS] Support more ES6 default exports.

[Daniel Jasper via cfe-commits]

Author: djasper
Date: Mon Jan  4 10:10:36 2016
New Revision: 256759

URL: http://llvm.org/viewvc/llvm-project?rev=256759&view=rev
Log:
clang-format: [JS] Support more ES6 default exports.

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

Modified: cfe/trunk/lib/Format/TokenAnnotator.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/TokenAnnotator.cpp?rev=256759&r1=256758&r2=256759&view=diff
==
--- cfe/trunk/lib/Format/TokenAnnotator.cpp (original)
+++ cfe/trunk/lib/Format/TokenAnnotator.cpp Mon Jan  4 10:10:36 2016
@@ -2001,8 +2001,9 @@ bool TokenAnnotator::spaceRequiredBefore
 if (Left.isOneOf(Keywords.kw_let, Keywords.kw_var, TT_JsFatArrow,
  Keywords.kw_in))
   return true;
-if (Left.is(tok::kw_default) && Right.is(TT_ArrayInitializerLSquare))
-  return true; // For "export default [];".
+if (Left.is(tok::kw_default) && Left.Previous &&
+Left.Previous->is(tok::kw_export))
+  return true;
 if (Left.is(Keywords.kw_is) && Right.is(tok::l_brace))
   return true;
 if (Right.isOneOf(TT_JsTypeColon, TT_JsTypeOptionalQuestion))

Modified: cfe/trunk/unittests/Format/FormatTestJS.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Format/FormatTestJS.cpp?rev=256759&r1=256758&r2=256759&view=diff
==
--- cfe/trunk/unittests/Format/FormatTestJS.cpp (original)
+++ cfe/trunk/unittests/Format/FormatTestJS.cpp Mon Jan  4 10:10:36 2016
@@ -870,6 +870,7 @@ TEST_F(FormatTestJS, Modules) {
"  bb\n"
"];");
   verifyFormat("export default [];");
+  verifyFormat("export default () => {};");
 }
 
 TEST_F(FormatTestJS, TemplateStrings) {


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

Re: [PATCH] D15823: Support virtual-near-miss check.

[Alexander Kornienko via cfe-commits]

alexfh added a comment.

Looks like you've forgotten to upload a new patch.


http://reviews.llvm.org/D15823



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

r256762 - Add some overlooked optnone tests, and tighten up an existing test.

[Paul Robinson via cfe-commits]

Author: probinson
Date: Mon Jan  4 11:03:58 2016
New Revision: 256762

URL: http://llvm.org/viewvc/llvm-project?rev=256762&view=rev
Log:
Add some overlooked optnone tests, and tighten up an existing test.

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

Added:
cfe/trunk/test/CodeGenCXX/optnone-and-attributes.cpp
cfe/trunk/test/CodeGenCXX/optnone-class-members.cpp
cfe/trunk/test/CodeGenCXX/optnone-templates.cpp
Modified:
cfe/trunk/test/CodeGenCXX/optnone-def-decl.cpp

Added: cfe/trunk/test/CodeGenCXX/optnone-and-attributes.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/optnone-and-attributes.cpp?rev=256762&view=auto
==
--- cfe/trunk/test/CodeGenCXX/optnone-and-attributes.cpp (added)
+++ cfe/trunk/test/CodeGenCXX/optnone-and-attributes.cpp Mon Jan  4 11:03:58 
2016
@@ -0,0 +1,82 @@
+// RUN: %clang_cc1 < %s -triple i386-mingw32 -fms-extensions -emit-llvm -x c++ 
| FileCheck %s
+
+// optnone wins over inlinehint.
+// Test that both func1 and func2 are marked optnone and noinline.
+
+// Definition with both optnone and inlinehint.
+__attribute__((optnone))
+inline int func1(int a) {
+  return a + a + a + a;
+}
+// CHECK: @_Z5func1i({{.*}}) [[OPTNONE:#[0-9]+]]
+
+// optnone declaration, inlinehint definition.
+__attribute__((optnone))
+int func2(int a);
+
+inline int func2(int a) {
+  return a + a + a + a;
+}
+// CHECK: @_Z5func2i({{.*}}) [[OPTNONE]]
+
+// Keep alive the definitions of func1 and func2.
+int foo() {
+  int val = func1(1);
+  return val + func2(2);
+}
+
+// optnone wins over minsize.
+__attribute__((optnone))
+int func3(int a);
+
+__attribute__((minsize))
+int func3(int a) {
+  return a + a + a + a;
+}
+// Same attribute set as everything else, therefore no 'minsize'.
+// CHECK: @_Z5func3i({{.*}}) [[OPTNONE]]
+
+
+// Verify that noreturn is compatible with optnone.
+__attribute__((noreturn))
+extern void exit_from_function();
+
+__attribute__((noreturn)) __attribute((optnone))
+extern void noreturn_function(int a) { exit_from_function(); }
+// CHECK: @_Z17noreturn_functioni({{.*}}) [[NORETURN:#[0-9]+]]
+
+
+// Verify that __declspec(noinline) is compatible with optnone.
+__declspec(noinline) __attribute__((optnone))
+void func4() { return; }
+// CHECK: @_Z5func4v() [[OPTNONE]]
+
+__declspec(noinline)
+extern void func5();
+
+__attribute__((optnone))
+void func5() { return; }
+// CHECK: @_Z5func5v() [[OPTNONE]]
+
+
+// Verify also that optnone can be used on dllexport functions.
+// Adding attribute optnone on a dllimport function has no effect.
+
+__attribute__((dllimport))
+__attribute__((optnone))
+int imported_optnone_func(int a);
+
+__attribute__((dllexport))
+__attribute__((optnone))
+int exported_optnone_func(int a) {
+  return imported_optnone_func(a); // use of imported func
+}
+// CHECK: @_Z21exported_optnone_funci({{.*}}) [[OPTNONE]]
+// CHECK: declare dllimport {{.*}} @_Z21imported_optnone_funci({{.*}}) 
[[DLLIMPORT:#[0-9]+]]
+
+
+// CHECK: attributes [[OPTNONE]] = { noinline {{.*}} optnone
+// CHECK: attributes [[NORETURN]] = { noinline noreturn {{.*}} optnone
+
+// CHECK: attributes [[DLLIMPORT]] =
+// CHECK-SAME-NOT: optnone

Added: cfe/trunk/test/CodeGenCXX/optnone-class-members.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/optnone-class-members.cpp?rev=256762&view=auto
==
--- cfe/trunk/test/CodeGenCXX/optnone-class-members.cpp (added)
+++ cfe/trunk/test/CodeGenCXX/optnone-class-members.cpp Mon Jan  4 11:03:58 2016
@@ -0,0 +1,164 @@
+// RUN: %clang_cc1 < %s -triple %itanium_abi_triple -fms-extensions -emit-llvm 
-x c++ | FileCheck %s
+
+// Test attribute 'optnone' on methods:
+//  -- member functions;
+//  -- static member functions.
+
+// Verify that all methods of struct A are associated to the same attribute 
set.
+// The attribute set shall contain attributes 'noinline' and 'optnone'.
+
+struct A {
+  // Definition of an optnone static method.
+  __attribute__((optnone))
+  static int static_optnone_method(int a) {
+return a + a;
+  }
+  // CHECK: @_ZN1A21static_optnone_methodEi({{.*}}) [[OPTNONE:#[0-9]+]]
+
+  // Definition of an optnone normal method.
+  __attribute__((optnone))
+  int optnone_method(int a) {
+return a + a + a + a;
+  }
+  // CHECK: @_ZN1A14optnone_methodEi({{.*}}) [[OPTNONE]]
+
+  // Declaration of an optnone method with out-of-line definition
+  // that doesn't say optnone.
+  __attribute__((optnone))
+  int optnone_decl_method(int a);
+
+  // Methods declared without attribute optnone; the definitions will
+  // have attribute optnone, and we verify optnone wins.
+  __forceinline static int static_forceinline_method(int a);
+  __attribute__((always_inline)) int alwaysinline_method(int a);
+  __attribute__((noinline)) int noinline_method(int a);
+  __attribute__((minsize)) int minsize_method(int a);
+};
+
+void foo() {
+  A a;
+

Re: [PATCH] D15704: Add some overlooked optnone tests, and tighten up an existing test

[Paul Robinson via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL256762: Add some overlooked optnone tests, and tighten up an 
existing test. (authored by probinson).

Changed prior to commit:
  http://reviews.llvm.org/D15704?vs=43416&id=43891#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D15704

Files:
  cfe/trunk/test/CodeGenCXX/optnone-and-attributes.cpp
  cfe/trunk/test/CodeGenCXX/optnone-class-members.cpp
  cfe/trunk/test/CodeGenCXX/optnone-def-decl.cpp
  cfe/trunk/test/CodeGenCXX/optnone-templates.cpp

Index: cfe/trunk/test/CodeGenCXX/optnone-and-attributes.cpp
===
--- cfe/trunk/test/CodeGenCXX/optnone-and-attributes.cpp
+++ cfe/trunk/test/CodeGenCXX/optnone-and-attributes.cpp
@@ -0,0 +1,82 @@
+// RUN: %clang_cc1 < %s -triple i386-mingw32 -fms-extensions -emit-llvm -x c++ | FileCheck %s
+
+// optnone wins over inlinehint.
+// Test that both func1 and func2 are marked optnone and noinline.
+
+// Definition with both optnone and inlinehint.
+__attribute__((optnone))
+inline int func1(int a) {
+  return a + a + a + a;
+}
+// CHECK: @_Z5func1i({{.*}}) [[OPTNONE:#[0-9]+]]
+
+// optnone declaration, inlinehint definition.
+__attribute__((optnone))
+int func2(int a);
+
+inline int func2(int a) {
+  return a + a + a + a;
+}
+// CHECK: @_Z5func2i({{.*}}) [[OPTNONE]]
+
+// Keep alive the definitions of func1 and func2.
+int foo() {
+  int val = func1(1);
+  return val + func2(2);
+}
+
+// optnone wins over minsize.
+__attribute__((optnone))
+int func3(int a);
+
+__attribute__((minsize))
+int func3(int a) {
+  return a + a + a + a;
+}
+// Same attribute set as everything else, therefore no 'minsize'.
+// CHECK: @_Z5func3i({{.*}}) [[OPTNONE]]
+
+
+// Verify that noreturn is compatible with optnone.
+__attribute__((noreturn))
+extern void exit_from_function();
+
+__attribute__((noreturn)) __attribute((optnone))
+extern void noreturn_function(int a) { exit_from_function(); }
+// CHECK: @_Z17noreturn_functioni({{.*}}) [[NORETURN:#[0-9]+]]
+
+
+// Verify that __declspec(noinline) is compatible with optnone.
+__declspec(noinline) __attribute__((optnone))
+void func4() { return; }
+// CHECK: @_Z5func4v() [[OPTNONE]]
+
+__declspec(noinline)
+extern void func5();
+
+__attribute__((optnone))
+void func5() { return; }
+// CHECK: @_Z5func5v() [[OPTNONE]]
+
+
+// Verify also that optnone can be used on dllexport functions.
+// Adding attribute optnone on a dllimport function has no effect.
+
+__attribute__((dllimport))
+__attribute__((optnone))
+int imported_optnone_func(int a);
+
+__attribute__((dllexport))
+__attribute__((optnone))
+int exported_optnone_func(int a) {
+  return imported_optnone_func(a); // use of imported func
+}
+// CHECK: @_Z21exported_optnone_funci({{.*}}) [[OPTNONE]]
+// CHECK: declare dllimport {{.*}} @_Z21imported_optnone_funci({{.*}}) [[DLLIMPORT:#[0-9]+]]
+
+
+// CHECK: attributes [[OPTNONE]] = { noinline {{.*}} optnone
+// CHECK: attributes [[NORETURN]] = { noinline noreturn {{.*}} optnone
+
+// CHECK: attributes [[DLLIMPORT]] =
+// CHECK-SAME-NOT: optnone
Index: cfe/trunk/test/CodeGenCXX/optnone-def-decl.cpp
===
--- cfe/trunk/test/CodeGenCXX/optnone-def-decl.cpp
+++ cfe/trunk/test/CodeGenCXX/optnone-def-decl.cpp
@@ -90,5 +90,6 @@
 // CHECK: @_Z28forceinline_optnone_functionii({{.*}}) [[OPTNONE]]
 
 // CHECK: attributes [[OPTNONE]] = { noinline nounwind optnone {{.*}} }
-// CHECK: attributes [[NORMAL]] = { nounwind {{.*}} }
-
+// CHECK: attributes [[NORMAL]] =
+// CHECK-SAME-NOT: noinline
+// CHECK-SAME-NOT: optnone
Index: cfe/trunk/test/CodeGenCXX/optnone-class-members.cpp
===
--- cfe/trunk/test/CodeGenCXX/optnone-class-members.cpp
+++ cfe/trunk/test/CodeGenCXX/optnone-class-members.cpp
@@ -0,0 +1,164 @@
+// RUN: %clang_cc1 < %s -triple %itanium_abi_triple -fms-extensions -emit-llvm -x c++ | FileCheck %s
+
+// Test attribute 'optnone' on methods:
+//  -- member functions;
+//  -- static member functions.
+
+// Verify that all methods of struct A are associated to the same attribute set.
+// The attribute set shall contain attributes 'noinline' and 'optnone'.
+
+struct A {
+  // Definition of an optnone static method.
+  __attribute__((optnone))
+  static int static_optnone_method(int a) {
+return a + a;
+  }
+  // CHECK: @_ZN1A21static_optnone_methodEi({{.*}}) [[OPTNONE:#[0-9]+]]
+
+  // Definition of an optnone normal method.
+  __attribute__((optnone))
+  int optnone_method(int a) {
+return a + a + a + a;
+  }
+  // CHECK: @_ZN1A14optnone_methodEi({{.*}}) [[OPTNONE]]
+
+  // Declaration of an optnone method with out-of-line definition
+  // that doesn't say optnone.
+  __attribute__((optnone))
+  int optnone_decl_method(int a);
+
+  // Methods declared without attribute optnone; the definitions will
+  // have attribute optnone, and we verify optnone wins.
+  __for

Re: [PATCH] D8149: Add hasUnderlyingType narrowing matcher for TypedefDecls, functionProtoType matcher for FunctionProtoType nodes, extend parameterCountIs to FunctionProtoType nodes

[Richard via cfe-commits]

LegalizeAdulthood added inline comments.


Comment at: unittests/ASTMatchers/ASTMatchersTest.cpp:4990
@@ +4989,3 @@
+  EXPECT_TRUE(matches("typedef int hasUnderlyingTypeTest;",
+  typedefDecl(hasUnderlyingType(asString("int");
+  EXPECT_TRUE(

aaron.ballman wrote:
> I would expect hasUnderlyingType to look through all of the type sugar, not 
> just the top layer of it (since existing matchers can implement the current 
> behavior by using hasType, I believe). I think the correct approach is to get 
> the underlying type, then loop to see whether that type matches, and if not, 
> strip off a layer of sugar and try again. Terminate the loop when there's no 
> more sugar to strip. The following should all match:
> ```
> EXPECT_TRUE(
>   matches("typedef int foo; typedef foo bar; typedef bar baz;",
>   typedefDecl(hasUnderlyingType(asString("int")), 
> hasName("bar";
> EXPECT_TRUE(
>   matches("typedef int foo; typedef foo bar; typedef bar baz;",
>   typedefDecl(hasUnderlyingType(asString("foo")), 
> hasName("baz";
> EXPECT_TRUE(
>   matches("typedef int foo; typedef foo bar; typedef bar baz;",
>   typedefDecl(hasUnderlyingType(asString("int")), 
> hasName("baz";
> ```
> The other question I have is about qualifiers. Should this match?
> ```
> EXPECT_TRUE(
>   matches("typedef const int foo;",
>   typedefDecl(hasUnderlyingType(asString("int")), 
> hasName("foo";
> ```
> Or should it require `asString("const int")`?
> (Regardless of the answer, we should document the behavior and add a test 
> with qualifiers.)
I'm happy to make the improvement, but I don't know how.  I simply call the 
`Node.underlyingType()`, just like `hasType` calls `Node.getType()`.  I don't 
know why they are different.


http://reviews.llvm.org/D8149



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

Re: [PATCH] D15721: [Sema] Fix ICE on casting a vector of bools to a vector of T

[George Burgess IV via cfe-commits]

george.burgess.iv added a comment.

Ping :)


http://reviews.llvm.org/D15721



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

Re: [PATCH] D15721: [Sema] Fix ICE on casting a vector of bools to a vector of T

[George Burgess IV via cfe-commits]

george.burgess.iv added a comment.

Ping :)


http://reviews.llvm.org/D15721



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

Re: [PATCH] D14877: Fix ICE on lowering of constexpr vector splats

[George Burgess IV via cfe-commits]

george.burgess.iv added a comment.

Ping :)


http://reviews.llvm.org/D14877



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

[PATCH] D15858: Warn undeclared identifiers in CUDA kernel calls

[Jason Henline via cfe-commits]

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

Value, type, and instantiation dependence were not being handled
correctly for CUDAKernelCallExpr AST nodes. As a result, if an undeclared
identifier was used in the triple-angle-bracket kernel call configuration,
there would be no error during parsing, and there would be a crash during code
gen.  This patch makes sure that an error will be issued during parsing in this
case, just as there would be for any other use of an undeclared identifier in
C++.

http://reviews.llvm.org/D15858

Files:
  include/clang/AST/ExprCXX.h
  test/SemaCUDA/kernel-call.cu

Index: test/SemaCUDA/kernel-call.cu
===
--- test/SemaCUDA/kernel-call.cu
+++ test/SemaCUDA/kernel-call.cu
@@ -23,4 +23,6 @@
 
   int (*fp)(int) = h2;
   fp<<<1, 1>>>(42); // expected-error {{must have void return type}}
+
+  g1<<>>(42); // expected-error {{use of undeclared identifier 
'undeclared'}}
 }
Index: include/clang/AST/ExprCXX.h
===
--- include/clang/AST/ExprCXX.h
+++ include/clang/AST/ExprCXX.h
@@ -171,7 +171,15 @@
 return cast_or_null(getPreArg(CONFIG));
   }
   CallExpr *getConfig() { return cast_or_null(getPreArg(CONFIG)); }
-  void setConfig(CallExpr *E) { setPreArg(CONFIG, E); }
+  void setConfig(CallExpr *E) {
+setPreArg(CONFIG, E);
+setValueDependent(isValueDependent() || E->isValueDependent());
+setTypeDependent(isTypeDependent() || E->isTypeDependent());
+setInstantiationDependent(isInstantiationDependent() ||
+  E->isInstantiationDependent());
+setContainsUnexpandedParameterPack(containsUnexpandedParameterPack() ||
+   E->containsUnexpandedParameterPack());
+  }
 
   static bool classof(const Stmt *T) {
 return T->getStmtClass() == CUDAKernelCallExprClass;


Index: test/SemaCUDA/kernel-call.cu
===
--- test/SemaCUDA/kernel-call.cu
+++ test/SemaCUDA/kernel-call.cu
@@ -23,4 +23,6 @@
 
   int (*fp)(int) = h2;
   fp<<<1, 1>>>(42); // expected-error {{must have void return type}}
+
+  g1<<>>(42); // expected-error {{use of undeclared identifier 'undeclared'}}
 }
Index: include/clang/AST/ExprCXX.h
===
--- include/clang/AST/ExprCXX.h
+++ include/clang/AST/ExprCXX.h
@@ -171,7 +171,15 @@
 return cast_or_null(getPreArg(CONFIG));
   }
   CallExpr *getConfig() { return cast_or_null(getPreArg(CONFIG)); }
-  void setConfig(CallExpr *E) { setPreArg(CONFIG, E); }
+  void setConfig(CallExpr *E) {
+setPreArg(CONFIG, E);
+setValueDependent(isValueDependent() || E->isValueDependent());
+setTypeDependent(isTypeDependent() || E->isTypeDependent());
+setInstantiationDependent(isInstantiationDependent() ||
+  E->isInstantiationDependent());
+setContainsUnexpandedParameterPack(containsUnexpandedParameterPack() ||
+   E->containsUnexpandedParameterPack());
+  }
 
   static bool classof(const Stmt *T) {
 return T->getStmtClass() == CUDAKernelCallExprClass;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D15266: [clang-format] Handle \n the same way as std::endl with stream operator.

[Jean-Philippe Dufraigne via cfe-commits]

jeanphilippeD added a comment.

Thanks,
Would you be happy to commit it for me since i do not have commit access.


http://reviews.llvm.org/D15266



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

Re: [clang-tools-extra] r256562 - [clang-tidy] Fix a use-after-free bug found by asan

[Kostya Serebryany via cfe-commits]

Nice!
is a fuzzer for clang-tidy possible/desirable?
similar to what we have for clang and clang-format
(tools/clang-format/fuzzer, ./tools/clang-fuzzer)


On Tue, Dec 29, 2015 at 8:14 AM, Alexander Kornienko via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: alexfh
> Date: Tue Dec 29 10:14:38 2015
> New Revision: 256562
>
> URL: http://llvm.org/viewvc/llvm-project?rev=256562&view=rev
> Log:
> [clang-tidy] Fix a use-after-free bug found by asan
>
> Modified:
>
> clang-tools-extra/trunk/clang-tidy/readability/SimplifyBooleanExprCheck.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=256562&r1=256561&r2=256562&view=diff
>
> ==
> ---
> clang-tools-extra/trunk/clang-tidy/readability/SimplifyBooleanExprCheck.cpp
> (original)
> +++
> clang-tools-extra/trunk/clang-tidy/readability/SimplifyBooleanExprCheck.cpp
> Tue Dec 29 10:14:38 2015
> @@ -491,9 +491,10 @@ void SimplifyBooleanExprCheck::check(con
>  bool containsDiscardedTokens(
>  const ast_matchers::MatchFinder::MatchResult &Result,
>  CharSourceRange CharRange) {
> -  StringRef ReplacementText =
> +  std::string ReplacementText =
>Lexer::getSourceText(CharRange, *Result.SourceManager,
> -   Result.Context->getLangOpts()).str();
> +   Result.Context->getLangOpts())
> +  .str();
>Lexer Lex(CharRange.getBegin(), Result.Context->getLangOpts(),
>  ReplacementText.data(), ReplacementText.data(),
>  ReplacementText.data() + ReplacementText.size());
>
>
> ___
> 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] D15590: [Bugfix] Disqualify unaddressable overload candidates when a function is directly called indirectly.

[George Burgess IV via cfe-commits]

george.burgess.iv updated this revision to Diff 43900.
george.burgess.iv added a comment.

Rebased


http://reviews.llvm.org/D15590

Files:
  include/clang/Sema/Overload.h
  include/clang/Sema/Sema.h
  lib/Sema/SemaExpr.cpp
  lib/Sema/SemaOverload.cpp
  test/CodeGenCXX/pass-object-size.cpp
  test/Sema/pass-object-size.c
  test/SemaCXX/pass-object-size.cpp

Index: test/SemaCXX/pass-object-size.cpp
===
--- test/SemaCXX/pass-object-size.cpp
+++ test/SemaCXX/pass-object-size.cpp
@@ -120,3 +120,17 @@
   (void)+[](void *const p __attribute__((pass_object_size(0 {}; //expected-error-re{{invalid argument type '(lambda at {{.*}})' to unary expression}}
 }
 }
+
+namespace ovlbug {
+// Directly calling an address-of function expression (e.g. in (&foo)(args...))
+// doesn't go through regular address-of-overload logic. This caused the above
+// code to generate an ICE.
+void DirectAddrOf(void *__attribute__((pass_object_size(0;
+void DirectAddrOfOvl(void *__attribute__((pass_object_size(0;
+void DirectAddrOfOvl(int *);
+
+void Test() {
+  (&DirectAddrOf)(nullptr); //expected-error{{cannot take address of function 'DirectAddrOf' because parameter 1 has pass_object_size attribute}}
+  (&DirectAddrOfOvl)((char*)nullptr); //expected-error{{no matching function}} expected-note@129{{candidate address cannot be taken because parameter 1 has pass_object_size attribute}} expected-note@130{{candidate function not viable: no known conversion from 'char *' to 'int *' for 1st argument}}
+}
+}
Index: test/Sema/pass-object-size.c
===
--- test/Sema/pass-object-size.c
+++ test/Sema/pass-object-size.c
@@ -33,7 +33,7 @@
 
 void NotOverloaded(void *p PS(0));
 void IsOverloaded(void *p PS(0)) overloaded;
-void IsOverloaded(char *p) overloaded;
+void IsOverloaded(char *p) overloaded; // char* inestead of void* is intentional
 void FunctionPtrs() {
   void (*p)(void *) = NotOverloaded; //expected-error{{cannot take address of function 'NotOverloaded' because parameter 1 has pass_object_size attribute}}
   void (*p2)(void *) = &NotOverloaded; //expected-error{{cannot take address of function 'NotOverloaded' because parameter 1 has pass_object_size attribute}}
@@ -49,4 +49,8 @@
 
   TakeFnOvl(NotOverloaded); //expected-error{{cannot take address of function 'NotOverloaded' because parameter 1 has pass_object_size attribute}}
   TakeFnOvl(&NotOverloaded); //expected-error{{cannot take address of function 'NotOverloaded' because parameter 1 has pass_object_size attribute}}
+
+  int P;
+  (&NotOverloaded)(&P); //expected-error{{cannot take address of function 'NotOverloaded' because parameter 1 has pass_object_size attribute}}
+  (&IsOverloaded)(&P); //expected-error{{no matching function}} expected-note@35{{candidate address cannot be taken because parameter 1 has pass_object_size attribute}} expected-note@36{{candidate function not viable: no known conversion from 'int *' to 'char *' for 1st argument}}
 }
Index: test/CodeGenCXX/pass-object-size.cpp
===
--- test/CodeGenCXX/pass-object-size.cpp
+++ test/CodeGenCXX/pass-object-size.cpp
@@ -25,3 +25,21 @@
 // CHECK-DAG: define internal i64 @"_ZZN7lambdas7LambdasEPcENK3$_1clEPvU17pass_object_size0"
 // CHECK-NOT: call i64 @llvm.objectsize
 }
+
+// This is here instead of in Sema/ because we need to check to make sure the
+// proper function is called. If it's not, we'll end up with assertion errors.
+namespace addrof {
+void OvlFoo(void *const __attribute__((pass_object_size(0 {}
+void OvlFoo(int *const) {}
+
+// CHECK: define void @_ZN6addrof4TestEv
+void Test() {
+  // Treating parens-only calls as though they were direct is consistent with
+  // how we handle other implicitly unaddressable functions (e.g. builtins).
+  // CHECK: call void @_ZN6addrof6OvlFooEPvU17pass_object_size0
+  (OvlFoo)(nullptr);
+
+  // CHECK: call void @_ZN6addrof6OvlFooEPi
+  (&OvlFoo)(nullptr);
+}
+}
Index: lib/Sema/SemaOverload.cpp
===
--- lib/Sema/SemaOverload.cpp
+++ lib/Sema/SemaOverload.cpp
@@ -9643,6 +9643,13 @@
 
   case ovl_fail_enable_if:
 return DiagnoseFailedEnableIfAttr(S, Cand);
+
+  case ovl_fail_addr_not_available: {
+bool Available = checkAddressOfCandidateIsAvailable(S, Cand->Function);
+(void)Available;
+assert(!Available);
+break;
+  }
   }
 }
 
@@ -11245,6 +11252,17 @@
   return ExprError();
 }
 
+static void markUnaddressableCandidatesUnviable(Sema &S,
+OverloadCandidateSet &CS) {
+  for (auto I = CS.begin(), E = CS.end(); I != E; ++I) {
+if (I->Viable &&
+!S.checkAddressOfFunctionIsAvailable(I->Function, /*Complain=*/false)) {
+  I->Viable = false;
+  I->FailureKind = ovl_fail_addr_not_available;
+}
+  }
+}
+
 /// BuildOverloadedCallExpr - G

Re: [PATCH] D15603: [OpenCL] Pipe type support

[Anastasia Stulova via cfe-commits]

Anastasia added inline comments.


Comment at: lib/AST/ASTContext.cpp:3121
@@ +3120,3 @@
+QualType ASTContext::getPipeType(QualType T) const {
+  // Unique pointers, to guarantee there is only one pointer of a particular
+  // structure.

Could we update the comment here or otherwise I think it's best to be removed!


Comment at: lib/CodeGen/CGOpenCLRuntime.cpp:108
@@ +107,3 @@
+PipeTy = llvm::PointerType::get(llvm::StructType::create(
+  CGM.getLLVMContext(), "opencl.pipe_t"), PipeAddrSpc);
+  }

pxli168 wrote:
> pekka.jaaskelainen wrote:
> > pxli168 wrote:
> > > pekka.jaaskelainen wrote:
> > > > I'm not sure if touching the built-in fingerprints for this is a good 
> > > > idea. It might lead to problems and confusion. Cannot one pass pipes as 
> > > > arguments to user functions too? Are the fingerprints of those 
> > > > functions then modified accordingly? It might become messy.
> > > > 
> > > > Because the packet size is known at host side, the pipes can be 
> > > > implemented as structs which holds the packet size as one of the member 
> > > > variables. The problem with this approach is how to exploit wider 
> > > > reads/writes instead of a scalar read/write loop + unpack/pack in case 
> > > > of vector datatypes. 
> > > > 
> > > > If the size is known only at runtime, one cannot easily generate vector 
> > > > reads/writes even if the element is a vector datatype and it would be 
> > > > efficient to keep the packet in a vector register as long as possible. 
> > > > For helping this I'd add a metadata which can be utilized at compile 
> > > > time to make reading/writing from the pipe faster.  But in a way that 
> > > > is already an optimization, not a requirement, to make pipes work.
> > > > 
> > > > The reading itself is platform dependent as the pipe can be even a 
> > > > hardware FIFO accessed using special instructions.
> > > This is what I'm worry about, I don't think we need to give much 
> > > information about an opaque type in OpenCL.
> > > 
> > > Actually we can get the element type from the metadata, and I think we 
> > > can leave the optimization to the backend and let platform to choose 
> > > which way to use for read/write pipe.
> > > 
> > > And I think the built-in function support for the pipe in OpenCL-C is not 
> > > necessary in the clang, what do you think? Though it can do some check in 
> > > Sema check, they can also be done in some llvm pass in backend. If the 
> > > built-in is really needed, I will send another patch based on this 
> > > included built-in support for pipe.
> > > 
> > > Thank you.
> > As far as I've understood, no there's no need to add built-in function 
> > awareness to the frontend for this case. Sema checking/diagnostics is 
> > needed to ensure pipes are used only as function arguments, not local 
> > variables, for example. Is this patch missing it?
> I think there are a lot of Sema checking about OpenCL2.0 are missing, the 
> pipe could not be a local variable is just one, there are also some check are 
> missing for reserve_id_t in my tests these days. 
> My plan is to use a patch to cover all these missing Sema check for OpenCL. 
> That would be a hard work with the OpenCL Specification and would take a lot 
> of time and may delay this patch, so could you accept this patch first and 
> let me to finish the missing Sema check later to make sure cover more missing 
> part.
I am Ok with not adding everything in one commit. We can revisit/modify things 
later on.


Comment at: test/SemaOpenCL/invalid-pipes-cl2.0.cl:3
@@ +2,3 @@
+
+void test(read_only pipe int *p){// expected-error {{pipes packet types cannot 
be of reference type}}
+}

I can see more than one diagnostic being added in this patch, but the test 
covers only one.


http://reviews.llvm.org/D15603



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

Re: [PATCH] D15589: [PPC] Add long long/double support for vec_cts, vec_ctu and vec_ctf.

[Tim Shen via cfe-commits]

timshen added a comment.

Ping?


http://reviews.llvm.org/D15589



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

[libcxx] r256772 - [libcxx] Fix typo in darwin target_info.py introduced by r256621.

[Ahmed Bougacha via cfe-commits]

Author: ab
Date: Mon Jan  4 13:35:40 2016
New Revision: 256772

URL: http://llvm.org/viewvc/llvm-project?rev=256772&view=rev
Log:
[libcxx] Fix typo in darwin target_info.py introduced by r256621.

Modified:
libcxx/trunk/test/libcxx/test/target_info.py

Modified: libcxx/trunk/test/libcxx/test/target_info.py
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/libcxx/test/target_info.py?rev=256772&r1=256771&r2=256772&view=diff
==
--- libcxx/trunk/test/libcxx/test/target_info.py (original)
+++ libcxx/trunk/test/libcxx/test/target_info.py Mon Jan  4 13:35:40 2016
@@ -62,7 +62,7 @@ class DarwinLocalTI(DefaultTargetInfo):
 super(DarwinLocalTI, self).__init__(full_config)
 
 def add_locale_features(self, features):
-add_common_locales(feature, self.full_config.lit_config)
+add_common_locales(features, self.full_config.lit_config)
 
 def add_cxx_compile_flags(self, flags):
 try:


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

[PATCH] D15862: A possible direction for fixing https://llvm.org/bugs/show_bug.cgi?id=25973.

[Marshall Clow via cfe-commits]

mclow.lists created this revision.
mclow.lists added reviewers: howard.hinnant, EricWF, rsmith.
mclow.lists added a subscriber: cfe-commits.

libc++'s basic_string class assumes that iterator operations on the iterators 
that are passed to it don't throw.  This is wrong, and means that we don't meet 
the strong exception guarantees in the standard.  

A general solution is to do all the work in a temporary string, and then 
merge/swap the result into the destination in the end.
However, this is wasteful (extra allocations and copying) when the iterator 
operations can't throw.

Here I introduce some scaffolding to support detecting these iterators.
I took an old name from `` that was no longer used: 
`__libcpp_is_trivial_iterator` as the basis.
A trivial iterator is a pointer, or one of libc++'s wrapper around another 
iterator: `move_iterator`, `reverse_iterator` and `__wrap_iterator` (when the 
wrapped iterator is trivial).  These are assumed to never throw on indirection, 
next/prev, comparison and assignment.   

Then I add a string-specific type trait: 
`__libcpp_string_gets_noexcept_iterator`, which is either a trivial iterator or 
something that has noexcept increment, dereference and comparison. When I get a 
non-input iterator where `__libcpp_string_gets_noexcept_iterator::value` 
is true, I do the algorithm in-place.

Note that this diff is just for `assign`; there are several other cases to deal 
with in ``.

I'm looking for feedback on the general direction.
 

http://reviews.llvm.org/D15862

Files:
  include/algorithm
  include/iterator
  include/string

Index: include/string
===
--- include/string
+++ include/string
@@ -1201,6 +1201,24 @@
 #pragma warning( pop )
 #endif // _LIBCPP_MSVC
 
+#ifdef _LIBCPP_HAS_NO_NOEXCEPT
+struct __libcpp_string_gets_noexcept_iterator_impl : public _LIBCPP_BOOL_CONSTANT(false) {};
+#else
+template 
+struct __libcpp_string_gets_noexcept_iterator_impl : public _LIBCPP_BOOL_CONSTANT((
+	__is_forward_iterator<_Iter>::value && 
+// 	noexcept(declval<_Iter>().operator++()) && 
+// 	noexcept(++(declval<_Iter>())) && 
+	noexcept(declval<_Iter>() == declval<_Iter>()) && 
+	noexcept(*declval<_Iter>())
+)) {};
+#endif
+
+
+template 
+struct __libcpp_string_gets_noexcept_iterator
+	: public _LIBCPP_BOOL_CONSTANT(__libcpp_is_trivial_iterator<_Iter>::value || __libcpp_string_gets_noexcept_iterator_impl<_Iter>::value) {};
+
 #ifdef _LIBCPP_ABI_ALTERNATE_STRING_LAYOUT
 
 template 
@@ -1535,15 +1553,16 @@
 template
 typename enable_if
 <
- __is_input_iterator  <_InputIterator>::value &&
-!__is_forward_iterator<_InputIterator>::value,
+   __is_exactly_input_iterator<_InputIterator>::value
+|| !__libcpp_string_gets_noexcept_iterator<_InputIterator>::value,
 basic_string&
 >::type
 assign(_InputIterator __first, _InputIterator __last);
 template
 typename enable_if
 <
-__is_forward_iterator<_ForwardIterator>::value,
+__is_forward_iterator<_ForwardIterator>::value
+ && __libcpp_string_gets_noexcept_iterator<_ForwardIterator>::value,
 basic_string&
 >::type
 assign(_ForwardIterator __first, _ForwardIterator __last);
@@ -2494,15 +2513,15 @@
 template
 typename enable_if
 <
- __is_input_iterator  <_InputIterator>::value &&
-!__is_forward_iterator<_InputIterator>::value,
+ __is_exactly_input_iterator <_InputIterator>::value
+  || !__libcpp_string_gets_noexcept_iterator<_InputIterator>::value,
 basic_string<_CharT, _Traits, _Allocator>&
 >::type
 basic_string<_CharT, _Traits, _Allocator>::assign(_InputIterator __first, _InputIterator __last)
 {
-clear();
-for (; __first != __last; ++__first)
-push_back(*__first);
+	call_input();
+	basic_string temp(__first, __last);
+this->swap(temp);
 return *this;
 }
 
@@ -2510,11 +2529,13 @@
 template
 typename enable_if
 <
-__is_forward_iterator<_ForwardIterator>::value,
+__is_forward_iterator<_ForwardIterator>::value
+ && __libcpp_string_gets_noexcept_iterator<_ForwardIterator>::value,
 basic_string<_CharT, _Traits, _Allocator>&
 >::type
 basic_string<_CharT, _Traits, _Allocator>::assign(_ForwardIterator __first, _ForwardIterator __last)
 {
+	call_forward();
 size_type __n = static_cast(_VSTD::distance(__first, __last));
 size_type __cap = capacity();
 if (__cap < __n)
Index: include/iterator
===
--- include/iterator
+++ include/iterator
@@ -437,6 +437,10 @@
 template 
 struct __is_random_access_iterator : public __has_iterator_category_convertible_to<_Tp, random_access_iterator_tag> {};
 
+template 
+struct __is_exactly_input_iterator 
+	: integral_constant::iterator_category, input_iterator_tag>::value> {};
+
 template
 struct _LIBCPP_TYPE_VIS_ONLY iterator
@@ -1

Re: [PATCH] D15862: A possible direction for fixing https://llvm.org/bugs/show_bug.cgi?id=25973.

[Marshall Clow via cfe-commits]

mclow.lists added inline comments.


Comment at: include/string:1211
@@ +1210,3 @@
+// noexcept(declval<_Iter>().operator++()) && 
+// noexcept(++(declval<_Iter>())) && 
+   noexcept(declval<_Iter>() == declval<_Iter>()) && 

This is not quite right yet. I need to check for assignment, and the two 
commented out lines attempt to check for increment.

However, the first one fails when the iterator type is a pointer, and the 
second just fails.



Comment at: include/string:1556
@@ -1537,3 +1555,3 @@
 <
- __is_input_iterator  <_InputIterator>::value &&
-!__is_forward_iterator<_InputIterator>::value,
+   __is_exactly_input_iterator<_InputIterator>::value
+|| 
!__libcpp_string_gets_noexcept_iterator<_InputIterator>::value,

Drive-by improvement. I got tired of all the `__is_input_iterator  
<_InputIterator>::value && !__is_forward_iterator<_InputIterator>::value`, so I 
added `__is_exactly_input_iterator`


Comment at: include/string:2522
@@ -2502,4 +2521,3 @@
 {
-clear();
-for (; __first != __last; ++__first)
-push_back(*__first);
+   call_input();
+   basic_string temp(__first, __last);

This is just test scaffolding so that I can be sure that the correct overload 
is getting called.
Will be removed before checkin.



Comment at: include/string:2538
@@ -2517,2 +2537,3 @@
 {
+   call_forward();
 size_type __n = static_cast(_VSTD::distance(__first, __last));

Same as #2522


http://reviews.llvm.org/D15862



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

Re: Getting fully qualified names of random qualtypes

[Sterling Augustine via cfe-commits]

I've finally had time to circle back to this, and just sent a version of
this through reviews.llvm.org.

It is highly edited, and we may as well start from scratch. In particular,
my usecase has no need for all the desugaring, so I have removed it all. So
no std::vector special casing, and no desugaring code even exists to
simplify.

Take a look if you get a chance.

http://reviews.llvm.org/D15861


On Mon, Oct 26, 2015 at 6:03 AM, Benjamin Kramer 
wrote:

> Some high level style comments:
>
> 1. Please convert the file to LLVM style for the things that
> clang-format doesn't change. In particular PascalCase for all
> variables and cameCase for all function names.
> 2. We don't do author attribution in file comments, sorry.
> 3. Try to avoid commented out/#if 0'd code.
> 4. I'd really prefer to review this on reviews.llvm.org, makes things
> easier.
>
> On the functional side:
> 1. Why is std::vector and friends handled in a special case, don't we
> want this for all default arguments?
> 2. Can the desugaring code be simplified somehow? it feels extremely
> repetitive and the corresponding code in Type.cpp looks much simpler?
> Where is the additional complexity coming from?
>
> - Ben
>
>
> On Sat, Oct 24, 2015 at 12:29 AM, Sterling Augustine via cfe-commits
>  wrote:
> > As requested on cfe-dev, enclosed is a patch (that needs some
> > style-related work) to calculate the complete fully qualified name of
> > arbitrary Qualtypes, including recursively expanding template
> > parameters and subtypes.
> >
> > Seems to me like it follows most of the conventions described here:
> >
> > http://llvm.org/docs/CodingStandards.html
> >
> > but I'm told it needs more work. Happy to oblige.
> >
> > ___
> > 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] D15862: A possible direction for fixing https://llvm.org/bugs/show_bug.cgi?id=25973.

[Marshall Clow via cfe-commits]

mclow.lists marked an inline comment as done.
mclow.lists added a comment.

http://reviews.llvm.org/D15862



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

Re: [PATCH] D15862: A possible direction for fixing https://llvm.org/bugs/show_bug.cgi?id=25973.

[Marshall Clow via cfe-commits]

mclow.lists updated this revision to Diff 43906.
mclow.lists added a comment.

Howard suggested a fix for the "is incremental" problem in the type trait. I 
also added assignable.


http://reviews.llvm.org/D15862

Files:
  include/algorithm
  include/iterator
  include/string

Index: include/string
===
--- include/string
+++ include/string
@@ -1201,6 +1201,24 @@
 #pragma warning( pop )
 #endif // _LIBCPP_MSVC
 
+#ifdef _LIBCPP_HAS_NO_NOEXCEPT
+struct __libcpp_string_gets_noexcept_iterator_impl : public _LIBCPP_BOOL_CONSTANT(false) {};
+#else
+template 
+struct __libcpp_string_gets_noexcept_iterator_impl : public _LIBCPP_BOOL_CONSTANT((
+	__is_forward_iterator<_Iter>::value && 
+	noexcept(++(declval<_Iter&>())) && 
+ 	is_nothrow_assignable<_Iter&, _Iter>::value && 
+	noexcept(declval<_Iter>() == declval<_Iter>()) && 
+	noexcept(*declval<_Iter>())
+)) {};
+#endif
+
+
+template 
+struct __libcpp_string_gets_noexcept_iterator
+	: public _LIBCPP_BOOL_CONSTANT(__libcpp_is_trivial_iterator<_Iter>::value || __libcpp_string_gets_noexcept_iterator_impl<_Iter>::value) {};
+
 #ifdef _LIBCPP_ABI_ALTERNATE_STRING_LAYOUT
 
 template 
@@ -1535,15 +1553,16 @@
 template
 typename enable_if
 <
- __is_input_iterator  <_InputIterator>::value &&
-!__is_forward_iterator<_InputIterator>::value,
+   __is_exactly_input_iterator<_InputIterator>::value
+|| !__libcpp_string_gets_noexcept_iterator<_InputIterator>::value,
 basic_string&
 >::type
 assign(_InputIterator __first, _InputIterator __last);
 template
 typename enable_if
 <
-__is_forward_iterator<_ForwardIterator>::value,
+__is_forward_iterator<_ForwardIterator>::value
+ && __libcpp_string_gets_noexcept_iterator<_ForwardIterator>::value,
 basic_string&
 >::type
 assign(_ForwardIterator __first, _ForwardIterator __last);
@@ -2494,15 +2513,15 @@
 template
 typename enable_if
 <
- __is_input_iterator  <_InputIterator>::value &&
-!__is_forward_iterator<_InputIterator>::value,
+ __is_exactly_input_iterator <_InputIterator>::value
+  || !__libcpp_string_gets_noexcept_iterator<_InputIterator>::value,
 basic_string<_CharT, _Traits, _Allocator>&
 >::type
 basic_string<_CharT, _Traits, _Allocator>::assign(_InputIterator __first, _InputIterator __last)
 {
-clear();
-for (; __first != __last; ++__first)
-push_back(*__first);
+	call_input();
+	basic_string temp(__first, __last);
+this->swap(temp);
 return *this;
 }
 
@@ -2510,11 +2529,13 @@
 template
 typename enable_if
 <
-__is_forward_iterator<_ForwardIterator>::value,
+__is_forward_iterator<_ForwardIterator>::value
+ && __libcpp_string_gets_noexcept_iterator<_ForwardIterator>::value,
 basic_string<_CharT, _Traits, _Allocator>&
 >::type
 basic_string<_CharT, _Traits, _Allocator>::assign(_ForwardIterator __first, _ForwardIterator __last)
 {
+	call_forward();
 size_type __n = static_cast(_VSTD::distance(__first, __last));
 size_type __cap = capacity();
 if (__cap < __n)
Index: include/iterator
===
--- include/iterator
+++ include/iterator
@@ -437,6 +437,10 @@
 template 
 struct __is_random_access_iterator : public __has_iterator_category_convertible_to<_Tp, random_access_iterator_tag> {};
 
+template 
+struct __is_exactly_input_iterator 
+	: integral_constant::iterator_category, input_iterator_tag>::value> {};
+
 template
 struct _LIBCPP_TYPE_VIS_ONLY iterator
@@ -1404,6 +1408,23 @@
 return __x;
 }
 
+template 
+struct __libcpp_is_trivial_iterator
+	: public _LIBCPP_BOOL_CONSTANT(is_pointer<_Iter>::value) {};
+	
+template 
+struct __libcpp_is_trivial_iterator >
+	: public _LIBCPP_BOOL_CONSTANT(__libcpp_is_trivial_iterator<_Iter>::value) {};
+
+template 
+struct __libcpp_is_trivial_iterator >
+	: public _LIBCPP_BOOL_CONSTANT(__libcpp_is_trivial_iterator<_Iter>::value) {};
+
+template 
+struct __libcpp_is_trivial_iterator<__wrap_iter<_Iter> >
+	: public _LIBCPP_BOOL_CONSTANT(__libcpp_is_trivial_iterator<_Iter>::value) {};
+
+
 template 
 inline _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_AFTER_CXX11
 _Tp*
Index: include/algorithm
===
--- include/algorithm
+++ include/algorithm
@@ -1687,26 +1687,7 @@
 }
 
 // copy
-
 template 
-struct __libcpp_is_trivial_iterator
-{
-static const bool value = is_pointer<_Iter>::value;
-};
-
-template 
-struct __libcpp_is_trivial_iterator >
-{
-static const bool value = is_pointer<_Iter>::value;
-};
-
-template 
-struct __libcpp_is_trivial_iterator<__wrap_iter<_Iter> >
-{
-static const bool value = is_pointer<_Iter>::value;
-};
-
-template 
 inline _LIBCPP_INLINE_VISIBILITY
 _Iter
 __unwrap_iter(_Iter __i)
__

Re: [PATCH] D15121: A new clang-tidy module to find calls to `std::swap`, and change them to use ADL

[Marshall Clow via cfe-commits]

mclow.lists added a comment.

ping?


http://reviews.llvm.org/D15121



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

Re: [PATCH] D15862: A possible direction for fixing https://llvm.org/bugs/show_bug.cgi?id=25973.

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

> On 2016-Jan-04, at 12:02, Marshall Clow via cfe-commits 
>  wrote:
> 
> mclow.lists updated this revision to Diff 43906.
> mclow.lists added a comment.
> 
> Howard suggested a fix for the "is incremental" problem in the type trait. I 
> also added assignable.
> 
> 
> http://reviews.llvm.org/D15862
> 
> Files:
>  include/algorithm
>  include/iterator
>  include/string
> 

Direction seems reasonable to me FWIW.  One comment on the latest patch:

> ___


> Index: include/string
> ===
> --- include/string
> +++ include/string
> @@ -1201,6 +1201,24 @@
>  #pragma warning( pop )
>  #endif // _LIBCPP_MSVC
>  
> +#ifdef _LIBCPP_HAS_NO_NOEXCEPT
> +struct __libcpp_string_gets_noexcept_iterator_impl : public 
> _LIBCPP_BOOL_CONSTANT(false) {};
> +#else
> +template 
> +struct __libcpp_string_gets_noexcept_iterator_impl : public 
> _LIBCPP_BOOL_CONSTANT((
> + __is_forward_iterator<_Iter>::value && 
> + noexcept(++(declval<_Iter&>())) && 
> + is_nothrow_assignable<_Iter&, _Iter>::value && 
> + noexcept(declval<_Iter>() == declval<_Iter>()) && 
> + noexcept(*declval<_Iter>())
> +)) {};
> +#endif
> +
> +
> +template 
> +struct __libcpp_string_gets_noexcept_iterator
> + : public 
> _LIBCPP_BOOL_CONSTANT(__libcpp_is_trivial_iterator<_Iter>::value || 
> __libcpp_string_gets_noexcept_iterator_impl<_Iter>::value) {};

This seems unnecessarily complicated.  Can you do the following now that
you're not calling `.operator++()`?
```
#ifdef _LIBCPP_HAS_NO_NOEXCEPT
struct __libcpp_string_gets_noexcept_iterator_impl
: public _LIBCPP_BOOL_CONSTANT(__libcpp_is_trivial_iterator<_Iter>::value) 
{};
#else
// ...__libcpp_string_gets_noexcept_iterator_impl as in your patch...
#endif

template 
struct __libcpp_string_gets_noexcept_iterator
: public 
_LIBCPP_BOOL_CONSTANT(__libcpp_string_gets_noexcept_iterator_impl<_Iter>::value)
 {};
```

This avoids instantiating __libcpp_is_trivial_iterator in the
!_LIBCPP_HAS_NO_NOEXCEPT case.

> +
>  #ifdef _LIBCPP_ABI_ALTERNATE_STRING_LAYOUT
>  
> 

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

Re: [libcxx] [PATCH] unordered_map: Avoid unnecessary mallocs when no insert occurs

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

ping

> On 2015-Dec-17, at 13:56, Duncan P. N. Exon Smith  
> wrote:
> 
> 
>> On 2015-Dec-16, at 14:42, Duncan P. N. Exon Smith  
>> wrote:
>> 
>> This is a follow-up to r239666: "Fix PR12999 - unordered_set::insert
>> calls operator new when no insert occurs".  That fix didn't apply to
>> `unordered_map` because unordered_map::value_type gets packed inside:
>> --
>> union __value_type {
>> pair __nc;   // Only C++11 or higher.
>> pair __cc; // Always.
>> // Constructors...
>> };
>> --
>> and the underlying __hash_table only knows about __value_type.
> 
> Sorry for the quick ping, but I realized this morning that my approach
> was still leaving mallocs on the table.
> 
> I've attached a new patch that handles more cases.
> 
> This patch should avoid unnecessary mallocs whenever the caller passes
> in a pair such that T is trivially convertible to key_type.
> 
> Since __hash_table's value_type is really *never* a pair (for
> unordered_map, it's a union of two pairs) the static dispatch is all in
> unordered_map.  It's doing this:
>  - If the argument isn't a pair<>, alloc.
>  - If argument.first can be referenced as const key_type&, don't alloc.
>  - If argument.first can be trivially converted to key_type, don't
>alloc.
>  - Else alloc.
> 
> In the pre-C++11 world the caller has already converted to
> unordered_map::value_type.  We can always avoid the alloc.
> 
> To support all of this:
>  - In C++03, __unordered_map_equal and __unordered_map_hasher need to
>handle unordered_map::value_type.
>  - In C++03, __hash_table::__insert_unique_value() now takes its
>argument by template.
>  - In C++11, __hash_table::__insert_unique_value() is now a one-liner
>that forwards to __insert_unique_key_value() for the real work.
>  - The versions of __hash_table::__construct_node() that take a
>pre-computed hash have been renamed to __construct_node_hash(), and
>these versions use perfect forwarding.
> 
> Most of the following still apply:
> 
>> This is one of my first patches for libc++, and I'm not sure of a few
>> things:
>> - Did I successfully match the coding style?  (I'm kind of lost
>>   without clang-format TBH.)
>> - Should I separate the change to __construct_node_hash() into a
>>   separate prep commit?  (I would if this were LLVM, but I'm not sure
>>   if the common practice is different for libc++.)
>> - Most of the overloads I added to __unordered_map_hasher and
>>   __unordered_map_equal aren't actually used by
>>   __hash_table::__insert_unique_value().  Should I omit the unused
>>   ones?  (Again, for LLVM I would have omitted them.)
> 
> (For the updated patch, I went with the LLVM approach of only adding
> the used API.  It seems more appropriate in this case.)
> 
>> After this I'll fix the same performance issue in std::map (and I
>> assume std::set?).



0001-unordered_map-Avoid-unnecessary-mallocs-when-no-i-v2.patch
Description: Binary data
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D15866: Warn when using `defined` in a macro definition.

[Nico Weber via cfe-commits]

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

As far as I can tell, doing

#define HAVE_FOO_BAR defined(FOO) && defined(BAR)
#if HAVE_FOO
...
#endif

has undefined behavior per [cpp.cond]p4. In practice, it can have different 
behavior in gcc and Visual Studio – see the comment in PPExpressions.cpp. So we 
should warn on this.

One problem is that this also applies to function-like macros. While the 
example above can be written like

#if defined(FOO) && defined(BAR)
#defined HAVE_FOO 1
#else
#define HAVE_FOO 0
#endif

there is no easy way to rewrite a function-like macro like `#define FOO(x) 
(defined __foo_##x && __foo_##x)`. Function-like macros like this are used in 
practice, and compilers seem to not have differing behavior in that case. So 
maybe this should be a Warning only for object-like macros and an Extension for 
function-like macros? But it's undefined behavior in both cases as far as I can 
tell.

http://reviews.llvm.org/D15866

Files:
  include/clang/Basic/DiagnosticLexKinds.td
  lib/Lex/PPExpressions.cpp
  test/Lexer/cxx-features.cpp
  test/Preprocessor/expr_define_expansion.c

Index: test/Lexer/cxx-features.cpp
===
--- test/Lexer/cxx-features.cpp
+++ test/Lexer/cxx-features.cpp
@@ -1,11 +1,12 @@
-// RUN: %clang_cc1 -std=c++98 -verify %s
-// RUN: %clang_cc1 -std=c++11 -verify %s
-// RUN: %clang_cc1 -std=c++1y -fsized-deallocation -verify %s
-// RUN: %clang_cc1 -std=c++1y -fsized-deallocation -fconcepts-ts 
-DCONCEPTS_TS=1 -verify %s
-// RUN: %clang_cc1 -fcoroutines -DCOROUTINES -verify %s
+// RUN: %clang_cc1 -Wno-expansion-to-defined -std=c++98 -verify %s
+// RUN: %clang_cc1 -Wno-expansion-to-defined -std=c++11 -verify %s
+// RUN: %clang_cc1 -Wno-expansion-to-defined -std=c++1y -fsized-deallocation 
-verify %s
+// RUN: %clang_cc1 -Wno-expansion-to-defined -std=c++1y -fsized-deallocation 
-fconcepts-ts -DCONCEPTS_TS=1 -verify %s
+// RUN: %clang_cc1 -Wno-expansion-to-defined -fcoroutines -DCOROUTINES -verify 
%s
 
 // expected-no-diagnostics
 
+// FIXME using `defined` in a macro has undefined behavior.
 #if __cplusplus < 201103L
 #define check(macro, cxx98, cxx11, cxx1y) cxx98 == 0 ? defined(__cpp_##macro) 
: __cpp_##macro != cxx98
 #elif __cplusplus < 201304L
Index: lib/Lex/PPExpressions.cpp
===
--- lib/Lex/PPExpressions.cpp
+++ lib/Lex/PPExpressions.cpp
@@ -82,6 +82,28 @@
 static bool EvaluateDefined(PPValue &Result, Token &PeekTok, DefinedTracker 
&DT,
 bool ValueLive, Preprocessor &PP) {
   SourceLocation beginLoc(PeekTok.getLocation());
+
+  // [cpp.cond]p4:
+  //   Prior to evaluation, macro invocations in the list of preprocessing
+  //   tokens that will become the controlling constant expression are replaced
+  //   (except for those macro names modified by the 'defined' unary operator),
+  //   just as in normal text. If the token 'defined' is generated as a result
+  //   of this replacement process or use of the 'defined' unary operator does
+  //   not match one of the two specified forms prior to macro replacement, the
+  //   behavior is undefined.
+  // This isn't an idle threat, consider this program:
+  //   #define FOO
+  //   #define BAR defined(FOO)
+  //   #if BAR
+  //   ...
+  //   #else
+  //   ...
+  //   #endif
+  // clang and gcc will pick the #if branch while Visual Studio will take the
+  // #else branch.  Emit a warning about this undefined behavior.
+  if (beginLoc.isMacroID())
+PP.Diag(beginLoc, diag::warn_defined_in_macro);
+
   Result.setBegin(beginLoc);
 
   // Get the next token, don't expand it.
Index: include/clang/Basic/DiagnosticLexKinds.td
===
--- include/clang/Basic/DiagnosticLexKinds.td
+++ include/clang/Basic/DiagnosticLexKinds.td
@@ -656,6 +656,10 @@
 def note_header_guard : Note<
   "%0 is defined here; did you mean %1?">;
 
+def warn_defined_in_macro : Warning<
+  "macro expansion producing 'defined' has undefined behavior">,
+  InGroup>;
+
 let CategoryName = "Nullability Issue" in {
 
 def err_pp_assume_nonnull_syntax : Error<"expected 'begin' or 'end'">;
Index: test/Preprocessor/expr_define_expansion.c
===
--- test/Preprocessor/expr_define_expansion.c
+++ test/Preprocessor/expr_define_expansion.c
@@ -1,6 +1,10 @@
 // RUN: %clang_cc1 %s -E -CC -pedantic -verify
-// expected-no-diagnostics
 
 #define FOO && 1
 #if defined FOO FOO
 #endif
+
+#define A
+#define B defined(A)
+#if B // expected-warning{{macro expansion producing 'defined' has undefined 
behavior}}
+#endif


Index: test/Lexer/cxx-features.cpp
===
--- test/Lexer/cxx-features.cpp
+++ test/Lexer/cxx-features.cpp
@@ -1,11 +1,12 @@
-// RUN: %clang

Re: [PATCH] D15861: Support fully-qualified names for all QualTypes

[Nick Lewycky via cfe-commits]

nlewycky added a subscriber: nlewycky.
nlewycky added a comment.

(I'm not doing a full review, I just happened to notice a couple things when 
skimming.)



Comment at: lib/Tooling/Core/QualTypeNames.cpp:250
@@ +249,3 @@
+// There are probably other cases ...
+if (const TagType *TagDeclType = llvm::dyn_cast_or_null(TypePtr))
+  Decl = TagDeclType->getDecl();

s/dyn_cast_or_null/dyn_cast/

You've already checked !TypePtr above, so it can't be null here.


Comment at: lib/Tooling/Core/QualTypeNames.cpp:306
@@ +305,3 @@
+  // In case of myType& we need to strip the reference first, fully
+  // qualifiy and attach the reference once again.
+  if (llvm::isa(QT.getTypePtr())) {

s/qualifiy/qualify/


http://reviews.llvm.org/D15861



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

[clang-tools-extra] r256780 - Fix typo.

[Eugene Zelenko via cfe-commits]

Author: eugenezelenko
Date: Mon Jan  4 15:25:10 2016
New Revision: 256780

URL: http://llvm.org/viewvc/llvm-project?rev=256780&view=rev
Log:
Fix typo.

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

Modified: clang-tools-extra/trunk/docs/index.rst
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/docs/index.rst?rev=256780&r1=256779&r2=256780&view=diff
==
--- clang-tools-extra/trunk/docs/index.rst (original)
+++ clang-tools-extra/trunk/docs/index.rst Mon Jan  4 15:25:10 2016
@@ -7,7 +7,7 @@
 
 Introduction
 
-Welcome to the clang-tools-exta project which contains extra tools built using
+Welcome to the clang-tools-extra project which contains extra tools built using
 Clang's tooling API's.
 
 


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

Re: [PATCH] D15862: A possible direction for fixing https://llvm.org/bugs/show_bug.cgi?id=25973.

[Tim Song via cfe-commits]

tcanens added a subscriber: tcanens.


Comment at: include/string:2523
@@ +2522,3 @@
+   call_input();
+   basic_string temp(__first, __last);
+this->swap(temp);

This default constructs the allocator, but the allocator may not be default 
constructible.


http://reviews.llvm.org/D15862



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

Re: [PATCH] D15223: [ARM] [AARCH64] Add CodeGen IR tests for {VS}QRDML{AS}H v8.1a intrinsics.

[Eric Christopher via cfe-commits]

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

LGTM, and thanks for all of the iteration.

-eric


http://reviews.llvm.org/D15223



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

Buildbot numbers for week of 12/27/2015 - 1/2/2016

[Galina Kistanova via cfe-commits]

Hello everyone,

Below are some buildbot numbers for the last week of 12/27/2015 -
01/02/2016.

Thanks

Galina



Number of commits by project:

 project   |   commits
---+---
 llvm  |   102
 cfe   |81
 clang-tools-extra |12
 libcxx|11
 compiler-rt   | 7
 lld   | 3
 polly | 2
 lldb  | 2
 openmp| 1
---
   221



Number of completed builds, failed builds and average build time for
successful builds per active builder:

 buildername   | completed  |
failed | time
---+++
 clang-aarch64-lnt | 44
|  1 |  02:36:03
 clang-atom-d525-fedora| 15
|  1 |  08:54:33
 clang-atom-d525-fedora-rel| 43
|  3 |  02:20:37
 clang-bpf-build   |153
| 12 |  00:04:52
 clang-cmake-aarch64-42vma |124
|  5 |  00:25:43
 clang-cmake-aarch64-full  | 33
|  1 |  03:37:05
 clang-cmake-aarch64-quick |112
|  7 |  00:35:07
 clang-cmake-armv7-a15 |102
|  1 |  00:43:54
 clang-cmake-armv7-a15-full| 38
|  4 |  01:13:42
 clang-cmake-armv7-a15-selfhost| 26
|  1 |  04:40:14
 clang-cmake-armv7-a15-selfhost-neon   | 19
||  06:34:03
 clang-cmake-mips  | 65
|  4 |  01:33:37
 clang-cmake-mipsel| 13
||  09:14:49
 clang-cmake-thumbv7-a15   |102
|  4 |  00:42:12
 clang-cmake-thumbv7-a15-full-sh   | 17
||  07:18:35
 clang-hexagon-elf |143
| 14 |  00:13:59
 clang-native-aarch64-full |  1
||  08:20:03
 clang-native-arm-lnt  | 66
|  4 |  01:36:30
 clang-native-arm-lnt-perf | 12
||  10:46:18
 clang-ppc64-elf-linux | 78
| 14 |  01:11:02
 clang-ppc64-elf-linux2|117
|  6 |  00:29:59
 clang-sphinx-docs | 76
||  00:00:20
 clang-x64-ninja-win7  |115
| 73 |  00:37:18
 clang-x86-win2008-selfhost| 90
| 43 |  01:14:40
 clang-x86_64-darwin13-cross-arm   |137
|  6 |  00:18:34
 clang-x86_64-darwin13-cross-mingw32   |132
|  6 |  00:21:53
 clang-x86_64-debian-fast  | 90
|  1 |  00:14:08
 clang-x86_64-linux-abi-test   |158
|  4 |  00:09:44
 clang-x86_64-linux-selfhost-modules   |139
||  00:17:08
 clang-x86_64-ubuntu-gdb-75| 89
| 11 |  01:00:57
 libcxx-libcxxabi-arm-linux|  7
|  3 |  01:07:37
 libcxx-libcxxabi-singlethreaded-x86_64-linux-debian   |  4
||  00:08:54
 libcxx-libcxxabi-x86_64-linux-debian  |  4
||  00:09:30
 libcxx-libcxxabi-x86_64-linux-debian-noexceptions |  4
||  00:09:03
 libcxx-libcxxabi-x86_64-linux-ubuntu-asan | 10
|  4 |  00:05:24
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03|  9
|  1 |  00:03:50
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx11| 10
|  1 |  00:04:15
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx14| 10
|  1 |  00:04:26
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx1z| 10
|  1 |  00:04:26
 libcxx-libcxxabi-x86_64-linux-ubuntu-msan | 10
|  4 |  00:11:39
 libcxx-libcxxabi-x86_64-linux-ubuntu-tsan | 10
|  2 |  00:11:30
 libcxx-libcxxabi-x86_64-linux-ubuntu-unstable-abi | 10
|  1 |  00:04:54
 libcxx-sphinx-docs| 10
||  00:00:12
 libomp-clang-x86_64-linux-debian   

Re: r255371 - Error on redeclaring with a conflicting asm label and on redeclaring with an asm label after the first ODR-use. Detects problems like the one in PR22830 where gcc and clang both compiled

[Nick Lewycky via cfe-commits]

On 01/04/2016 01:40 PM, Kostya Serebryany wrote:



On Thu, Dec 17, 2015 at 5:03 PM, Richard Smith mailto:rich...@metafoo.co.uk>> wrote:

On Thu, Dec 17, 2015 at 3:59 PM, Nick Lewycky via cfe-commits
mailto:cfe-commits@lists.llvm.org>> wrote:

On 12/17/2015 10:47 AM, Kostya Serebryany wrote:

I am now observing this error message when building glibc
with clang
(from trunk):
../include/string.h:101:28: error: cannot apply asm label to
function
after its first use
libc_hidden_builtin_proto (memcpy)
(many more instances)


Do you think this is a bug in glibc code, or the error
message could be
more relaxed?


Could you email me a .i copy of a failing build? That will help
me decide whether it's a bug in the error or in glibc.


[sorry for delay,]
here is the preprocessed source file from glibc:
% clang  ~/tmp/a.i 2>&1 | grep error:
../include/sys/stat.h:16:28: error: cannot apply asm label to function
after its first use
../include/sys/stat.h:17:30: error: cannot apply asm label to function
after its first use
../include/sys/stat.h:18:28: error: cannot apply asm label to function
after its first use
../include/sys/stat.h:19:30: error: cannot apply asm label to function
after its first use
...


Also PR22830 comment 1 seems relevant here.


Probably, but since this is a very recent regression in clang I thought
I should report it.


This looks like it's WAI:

3783extern int __fxstat (int __ver, int __fildes, struct stat 
*__stat_buf)

3784 __attribute__ ((__nothrow__ )) ;
...
3827extern __inline int
3828__attribute__ ((__nothrow__ )) fstat (int __fd, struct stat 
*__statbuf)

3829{
3830  return __fxstat (1, __fd, __statbuf);
3831}
...
3910extern __typeof (__fxstat) __fxstat __asm__ ("" "__GI___fxstat") 
__attribute__ ((visibility ("hidden")));


This is exactly the situation where GCC and Clang will emit a different 
.o file.


Nick


On Fri, Dec 11, 2015 at 1:28 PM, Nick Lewycky via cfe-commits
mailto:cfe-commits@lists.llvm.org>
>> wrote:

 Author: nicholas
 Date: Fri Dec 11 15:28:55 2015
 New Revision: 255371

 URL:
http://llvm.org/viewvc/llvm-project?rev=255371&view=rev
 Log:
 Error on redeclaring with a conflicting asm label and
on redeclaring
 with an asm label after the first ODR-use. Detects
problems like the
 one in PR22830 where gcc and clang both compiled the
file but with
 different behaviour.

 Added:
  cfe/trunk/test/Sema/asm-label.c
 Modified:
  cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
  cfe/trunk/lib/Sema/SemaDecl.cpp

 Modified:
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
 URL:

http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=255371&r1=255370&r2=255371&view=diff


==
 ---
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
 +++
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Fri Dec 11
 15:28:55 2015
 @@ -4259,6 +4259,9 @@ def err_tag_definition_of_typedef
: Erro
   def err_conflicting_types : Error<"conflicting types
for %0">;
   def err_different_pass_object_size_params : Error<
 "conflicting pass_object_size attributes on
parameters">;
 +def err_late_asm_label_name : Error<
 +  "cannot apply asm label to
%select{variable|function}0 after its
 first use">;
 +def err_different_asm_label : Error<"conflicting asm
label">;
   def err_nested_redefinition : Error<"nested
redefinition of %0">;
   def err_use_with_wrong_tag : Error<
 "use of %0 with tag type that does not match
previous declaration">;

 Modified: cfe/trunk/lib/Sema/SemaDecl.cpp
 URL:

http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDecl.cpp?rev=255371&r1=255370&r2=255371&view=diff


==
 --- cfe/trunk/lib/Sema/SemaDecl.cpp (original)
 +++ cfe/trunk/lib/Sema/SemaDecl.cpp Fri Dec 11 15:28:55
2015
 

Re: [PATCH] D15456: [PATCH] New diagnostic for non-idiomatic copy or move operations (v2)

[Aaron Ballman via cfe-commits]

aaron.ballman added a comment.

Ping now that the holidays are somewhat over-ish.


http://reviews.llvm.org/D15456



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

r256793 - Remove setting of inlinehint and cold attributes based on profile data

[Easwaran Raman via cfe-commits]

Author: eraman
Date: Mon Jan  4 17:32:28 2016
New Revision: 256793

URL: http://llvm.org/viewvc/llvm-project?rev=256793&view=rev
Log:
Remove setting of inlinehint and cold attributes based on profile data

NFC. These hints are only used for inlining and the inliner now uses
the same criteria to identify hot and cold callees and set appropriate
thresholds without relying on these hints. Hence this removed code is
superfluous.

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


Removed:
cfe/trunk/test/Profile/c-attributes.c
Modified:
cfe/trunk/lib/CodeGen/CodeGenPGO.cpp
cfe/trunk/test/Profile/func-entry.c

Modified: cfe/trunk/lib/CodeGen/CodeGenPGO.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenPGO.cpp?rev=256793&r1=256792&r2=256793&view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenPGO.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenPGO.cpp Mon Jan  4 17:32:28 2016
@@ -721,17 +721,7 @@ CodeGenPGO::applyFunctionAttributes(llvm
   if (!haveRegionCounts())
 return;
 
-  uint64_t MaxFunctionCount = PGOReader->getMaximumFunctionCount();
   uint64_t FunctionCount = getRegionCount(nullptr);
-  if (FunctionCount >= (uint64_t)(0.3 * (double)MaxFunctionCount))
-// Turn on InlineHint attribute for hot functions.
-// FIXME: 30% is from preliminary tuning on SPEC, it may not be optimal.
-Fn->addFnAttr(llvm::Attribute::InlineHint);
-  else if (FunctionCount <= (uint64_t)(0.01 * (double)MaxFunctionCount))
-// Turn on Cold attribute for cold functions.
-// FIXME: 1% is from preliminary tuning on SPEC, it may not be optimal.
-Fn->addFnAttr(llvm::Attribute::Cold);
-
   Fn->setEntryCount(FunctionCount);
 }
 

Removed: cfe/trunk/test/Profile/c-attributes.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Profile/c-attributes.c?rev=256792&view=auto
==
--- cfe/trunk/test/Profile/c-attributes.c (original)
+++ cfe/trunk/test/Profile/c-attributes.c (removed)
@@ -1,48 +0,0 @@
-// Test that instrumentation based profiling sets function attributes 
correctly.
-
-// RUN: llvm-profdata merge %S/Inputs/c-attributes.proftext -o %t.profdata
-// RUN: %clang %s -o - -mllvm -disable-llvm-optzns -emit-llvm -S 
-fprofile-instr-use=%t.profdata | FileCheck %s
-
-extern int atoi(const char *);
-
-// CHECK: hot_100_percent(i32{{.*}}%i) [[HOT:#[0-9]+]]
-void hot_100_percent(int i) {
-  while (i > 0)
-i--;
-}
-
-// CHECK: hot_40_percent(i32{{.*}}%i) [[HOT]]
-void hot_40_percent(int i) {
-  while (i > 0)
-i--;
-}
-
-// CHECK: normal_func(i32{{.*}}%i) [[NORMAL:#[0-9]+]]
-void normal_func(int i) {
-  while (i > 0)
-i--;
-}
-
-// CHECK: cold_func(i32{{.*}}%i) [[COLD:#[0-9]+]]
-void cold_func(int i) {
-  while (i > 0)
-i--;
-}
-
-// CHECK: attributes [[HOT]] = { inlinehint nounwind {{.*}} }
-// CHECK: attributes [[NORMAL]] = { nounwind {{.*}} }
-// CHECK: attributes [[COLD]] = { cold nounwind {{.*}} }
-
-int main(int argc, const char *argv[]) {
-  int max = atoi(argv[1]);
-  int i;
-  for (i = 0; i < max; i++)
-hot_100_percent(i);
-  for (i = 0; i < max * 4 / 10; i++)
-hot_40_percent(i);
-  for (i = 0; i < max * 2 / 10; i++)
-normal_func(i);
-  for (i = 0; i < max / 200; i++)
-cold_func(i);
-  return 0;
-}

Modified: cfe/trunk/test/Profile/func-entry.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Profile/func-entry.c?rev=256793&r1=256792&r2=256793&view=diff
==
--- cfe/trunk/test/Profile/func-entry.c (original)
+++ cfe/trunk/test/Profile/func-entry.c Mon Jan  4 17:32:28 2016
@@ -5,10 +5,10 @@
 
 void foo(void);
 
-// CHECK: @foo() #0 !prof [[FOO:![0-9]+]]
+// CHECK: @foo() #{{[0-9]}} !prof [[FOO:![0-9]+]]
 void foo() { return; }
 
-// CHECK: @main() #1 !prof [[MAIN:![0-9]+]]
+// CHECK: @main() #{{[0-9]}} !prof [[MAIN:![0-9]+]]
 int main() {
   int i;
   for (i = 0; i < 1; i++) foo();


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

Re: [PATCH] D15726: Remove setting of inlinehint and cold attributes based on profile data

[Easwaran Raman via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL256793: Remove setting of inlinehint and cold attributes 
based on profile data (authored by eraman).

Changed prior to commit:
  http://reviews.llvm.org/D15726?vs=43479&id=43937#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D15726

Files:
  cfe/trunk/lib/CodeGen/CodeGenPGO.cpp
  cfe/trunk/test/Profile/c-attributes.c
  cfe/trunk/test/Profile/func-entry.c

Index: cfe/trunk/test/Profile/func-entry.c
===
--- cfe/trunk/test/Profile/func-entry.c
+++ cfe/trunk/test/Profile/func-entry.c
@@ -5,10 +5,10 @@
 
 void foo(void);
 
-// CHECK: @foo() #0 !prof [[FOO:![0-9]+]]
+// CHECK: @foo() #{{[0-9]}} !prof [[FOO:![0-9]+]]
 void foo() { return; }
 
-// CHECK: @main() #1 !prof [[MAIN:![0-9]+]]
+// CHECK: @main() #{{[0-9]}} !prof [[MAIN:![0-9]+]]
 int main() {
   int i;
   for (i = 0; i < 1; i++) foo();
Index: cfe/trunk/test/Profile/c-attributes.c
===
--- cfe/trunk/test/Profile/c-attributes.c
+++ cfe/trunk/test/Profile/c-attributes.c
@@ -1,48 +0,0 @@
-// Test that instrumentation based profiling sets function attributes 
correctly.
-
-// RUN: llvm-profdata merge %S/Inputs/c-attributes.proftext -o %t.profdata
-// RUN: %clang %s -o - -mllvm -disable-llvm-optzns -emit-llvm -S 
-fprofile-instr-use=%t.profdata | FileCheck %s
-
-extern int atoi(const char *);
-
-// CHECK: hot_100_percent(i32{{.*}}%i) [[HOT:#[0-9]+]]
-void hot_100_percent(int i) {
-  while (i > 0)
-i--;
-}
-
-// CHECK: hot_40_percent(i32{{.*}}%i) [[HOT]]
-void hot_40_percent(int i) {
-  while (i > 0)
-i--;
-}
-
-// CHECK: normal_func(i32{{.*}}%i) [[NORMAL:#[0-9]+]]
-void normal_func(int i) {
-  while (i > 0)
-i--;
-}
-
-// CHECK: cold_func(i32{{.*}}%i) [[COLD:#[0-9]+]]
-void cold_func(int i) {
-  while (i > 0)
-i--;
-}
-
-// CHECK: attributes [[HOT]] = { inlinehint nounwind {{.*}} }
-// CHECK: attributes [[NORMAL]] = { nounwind {{.*}} }
-// CHECK: attributes [[COLD]] = { cold nounwind {{.*}} }
-
-int main(int argc, const char *argv[]) {
-  int max = atoi(argv[1]);
-  int i;
-  for (i = 0; i < max; i++)
-hot_100_percent(i);
-  for (i = 0; i < max * 4 / 10; i++)
-hot_40_percent(i);
-  for (i = 0; i < max * 2 / 10; i++)
-normal_func(i);
-  for (i = 0; i < max / 200; i++)
-cold_func(i);
-  return 0;
-}
Index: cfe/trunk/lib/CodeGen/CodeGenPGO.cpp
===
--- cfe/trunk/lib/CodeGen/CodeGenPGO.cpp
+++ cfe/trunk/lib/CodeGen/CodeGenPGO.cpp
@@ -721,17 +721,7 @@
   if (!haveRegionCounts())
 return;
 
-  uint64_t MaxFunctionCount = PGOReader->getMaximumFunctionCount();
   uint64_t FunctionCount = getRegionCount(nullptr);
-  if (FunctionCount >= (uint64_t)(0.3 * (double)MaxFunctionCount))
-// Turn on InlineHint attribute for hot functions.
-// FIXME: 30% is from preliminary tuning on SPEC, it may not be optimal.
-Fn->addFnAttr(llvm::Attribute::InlineHint);
-  else if (FunctionCount <= (uint64_t)(0.01 * (double)MaxFunctionCount))
-// Turn on Cold attribute for cold functions.
-// FIXME: 1% is from preliminary tuning on SPEC, it may not be optimal.
-Fn->addFnAttr(llvm::Attribute::Cold);
-
   Fn->setEntryCount(FunctionCount);
 }
 


Index: cfe/trunk/test/Profile/func-entry.c
===
--- cfe/trunk/test/Profile/func-entry.c
+++ cfe/trunk/test/Profile/func-entry.c
@@ -5,10 +5,10 @@
 
 void foo(void);
 
-// CHECK: @foo() #0 !prof [[FOO:![0-9]+]]
+// CHECK: @foo() #{{[0-9]}} !prof [[FOO:![0-9]+]]
 void foo() { return; }
 
-// CHECK: @main() #1 !prof [[MAIN:![0-9]+]]
+// CHECK: @main() #{{[0-9]}} !prof [[MAIN:![0-9]+]]
 int main() {
   int i;
   for (i = 0; i < 1; i++) foo();
Index: cfe/trunk/test/Profile/c-attributes.c
===
--- cfe/trunk/test/Profile/c-attributes.c
+++ cfe/trunk/test/Profile/c-attributes.c
@@ -1,48 +0,0 @@
-// Test that instrumentation based profiling sets function attributes correctly.
-
-// RUN: llvm-profdata merge %S/Inputs/c-attributes.proftext -o %t.profdata
-// RUN: %clang %s -o - -mllvm -disable-llvm-optzns -emit-llvm -S -fprofile-instr-use=%t.profdata | FileCheck %s
-
-extern int atoi(const char *);
-
-// CHECK: hot_100_percent(i32{{.*}}%i) [[HOT:#[0-9]+]]
-void hot_100_percent(int i) {
-  while (i > 0)
-i--;
-}
-
-// CHECK: hot_40_percent(i32{{.*}}%i) [[HOT]]
-void hot_40_percent(int i) {
-  while (i > 0)
-i--;
-}
-
-// CHECK: normal_func(i32{{.*}}%i) [[NORMAL:#[0-9]+]]
-void normal_func(int i) {
-  while (i > 0)
-i--;
-}
-
-// CHECK: cold_func(i32{{.*}}%i) [[COLD:#[0-9]+]]
-void cold_func(int i) {
-  while (i > 0)
-i--;
-}
-
-// CHECK: attributes [[HOT]] = { inlinehint nounwind {{.*}} }
-// CHECK: attributes [[NORMAL]] = { nounwind {{.*}} }
-// CHECK: attributes [[COLD]] 

Re: r255371 - Error on redeclaring with a conflicting asm label and on redeclaring with an asm label after the first ODR-use. Detects problems like the one in PR22830 where gcc and clang both compiled

[Kostya Serebryany via cfe-commits]

Thanks for checking, Nick!
+Roland, FYI (recent changes in clang break compilation of all of the
glibc),
similar to https://llvm.org/bugs/show_bug.cgi?id=22830#c1

On Mon, Jan 4, 2016 at 3:21 PM, Nick Lewycky  wrote:

> On 01/04/2016 01:40 PM, Kostya Serebryany wrote:
>
>>
>>
>> On Thu, Dec 17, 2015 at 5:03 PM, Richard Smith > > wrote:
>>
>> On Thu, Dec 17, 2015 at 3:59 PM, Nick Lewycky via cfe-commits
>> mailto:cfe-commits@lists.llvm.org>>
>> wrote:
>>
>> On 12/17/2015 10:47 AM, Kostya Serebryany wrote:
>>
>> I am now observing this error message when building glibc
>> with clang
>> (from trunk):
>> ../include/string.h:101:28: error: cannot apply asm label to
>> function
>> after its first use
>> libc_hidden_builtin_proto (memcpy)
>> (many more instances)
>>
>>
>> Do you think this is a bug in glibc code, or the error
>> message could be
>> more relaxed?
>>
>>
>> Could you email me a .i copy of a failing build? That will help
>> me decide whether it's a bug in the error or in glibc.
>>
>>
>> [sorry for delay,]
>> here is the preprocessed source file from glibc:
>> % clang  ~/tmp/a.i 2>&1 | grep error:
>> ../include/sys/stat.h:16:28: error: cannot apply asm label to function
>> after its first use
>> ../include/sys/stat.h:17:30: error: cannot apply asm label to function
>> after its first use
>> ../include/sys/stat.h:18:28: error: cannot apply asm label to function
>> after its first use
>> ../include/sys/stat.h:19:30: error: cannot apply asm label to function
>> after its first use
>> ...
>>
>>
>> Also PR22830 comment 1 seems relevant here.
>>
>>
>> Probably, but since this is a very recent regression in clang I thought
>> I should report it.
>>
>
> This looks like it's WAI:
>
> 3783extern int __fxstat (int __ver, int __fildes, struct stat
> *__stat_buf)
> 3784 __attribute__ ((__nothrow__ )) ;
> ...
> 3827extern __inline int
> 3828__attribute__ ((__nothrow__ )) fstat (int __fd, struct stat
> *__statbuf)
> 3829{
> 3830  return __fxstat (1, __fd, __statbuf);
> 3831}
> ...
> 3910extern __typeof (__fxstat) __fxstat __asm__ ("" "__GI___fxstat")
> __attribute__ ((visibility ("hidden")));
>
> This is exactly the situation where GCC and Clang will emit a different .o
> file.
>
> Nick
>
> On Fri, Dec 11, 2015 at 1:28 PM, Nick Lewycky via cfe-commits
>> > 
>> >
>> >> wrote:
>>
>>  Author: nicholas
>>  Date: Fri Dec 11 15:28:55 2015
>>  New Revision: 255371
>>
>>  URL:
>> http://llvm.org/viewvc/llvm-project?rev=255371&view=rev
>>  Log:
>>  Error on redeclaring with a conflicting asm label and
>> on redeclaring
>>  with an asm label after the first ODR-use. Detects
>> problems like the
>>  one in PR22830 where gcc and clang both compiled the
>> file but with
>>  different behaviour.
>>
>>  Added:
>>   cfe/trunk/test/Sema/asm-label.c
>>  Modified:
>>   cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
>>   cfe/trunk/lib/Sema/SemaDecl.cpp
>>
>>  Modified:
>> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
>>  URL:
>>
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=255371&r1=255370&r2=255371&view=diff
>>
>>
>> ==
>>  ---
>> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
>> (original)
>>  +++
>> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Fri Dec
>> 11
>>  15:28:55 2015
>>  @@ -4259,6 +4259,9 @@ def err_tag_definition_of_typedef
>> : Erro
>>def err_conflicting_types : Error<"conflicting types
>> for %0">;
>>def err_different_pass_object_size_params : Error<
>>  "conflicting pass_object_size attributes on
>> parameters">;
>>  +def err_late_asm_label_name : Error<
>>  +  "cannot apply asm label to
>> %select{variable|function}0 after its
>>  first use">;
>>  +def err_different_asm_label : Error<"conflicting asm
>> label">;
>>def err_nested_redefinition : Error<"nested
>> redefinition of %0">;
>>def err_use_with_wrong_tag : Error<
>>   

r256795 - [ms-inline-asm] Handle dependent identifiers in inline asm

[David Majnemer via cfe-commits]

Author: majnemer
Date: Mon Jan  4 17:51:15 2016
New Revision: 256795

URL: http://llvm.org/viewvc/llvm-project?rev=256795&view=rev
Log:
[ms-inline-asm] Handle dependent identifiers in inline asm

Build up a dependent expression for MS-style inline assembly if the
identifier's type is dependent.

This fixes PR26001.

Modified:
cfe/trunk/lib/Sema/SemaStmtAsm.cpp
cfe/trunk/test/CodeGenCXX/ms-inline-asm-fields.cpp

Modified: cfe/trunk/lib/Sema/SemaStmtAsm.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaStmtAsm.cpp?rev=256795&r1=256794&r2=256795&view=diff
==
--- cfe/trunk/lib/Sema/SemaStmtAsm.cpp (original)
+++ cfe/trunk/lib/Sema/SemaStmtAsm.cpp Mon Jan  4 17:51:15 2016
@@ -589,10 +589,8 @@ ExprResult Sema::LookupInlineAsmIdentifi
 
   QualType T = Result.get()->getType();
 
-  // For now, reject dependent types.
   if (T->isDependentType()) {
-Diag(Id.getLocStart(), diag::err_asm_incomplete_type) << T;
-return ExprError();
+return Result;
   }
 
   // Any sort of function type is fine.
@@ -679,7 +677,18 @@ Sema::LookupInlineAsmVarDeclField(Expr *
   SourceLocation AsmLoc) {
   Info.clear();
 
-  const RecordType *RT = E->getType()->getAs();
+  QualType T = E->getType();
+  if (T->isDependentType()) {
+DeclarationNameInfo NameInfo;
+NameInfo.setLoc(AsmLoc);
+NameInfo.setName(&Context.Idents.get(Member));
+return CXXDependentScopeMemberExpr::Create(
+Context, E, T, /*IsArrow=*/false, AsmLoc, NestedNameSpecifierLoc(),
+SourceLocation(),
+/*FirstQualifierInScope=*/nullptr, NameInfo, /*TemplateArgs=*/nullptr);
+  }
+
+  const RecordType *RT = T->getAs();
   // FIXME: Diagnose this as field access into a scalar type.
   if (!RT)
 return ExprResult();

Modified: cfe/trunk/test/CodeGenCXX/ms-inline-asm-fields.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/ms-inline-asm-fields.cpp?rev=256795&r1=256794&r2=256795&view=diff
==
--- cfe/trunk/test/CodeGenCXX/ms-inline-asm-fields.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/ms-inline-asm-fields.cpp Mon Jan  4 17:51:15 2016
@@ -29,3 +29,28 @@ extern "C" int test_namespace_global() {
   __asm mov eax, asdf::a_global.a3.b2
 }
 
+template 
+struct make_storage_type {
+  struct type {
+struct B {
+  int a;
+  int x;
+} b;
+  };
+};
+
+template 
+struct msvc_dcas_x86 {
+  typedef typename make_storage_type::type storage_type;
+  void store() __asm("PR26001") {
+storage_type p;
+__asm mov edx, p.b.x;
+  }
+};
+
+template void msvc_dcas_x86::store();
+// CHECK: define weak_odr void @"\01PR26001"(
+// CHECK: %[[P:.*]] = alloca %"struct.make_storage_type::type", align 4
+// CHECK: %[[B:.*]] = getelementptr inbounds 
%"struct.make_storage_type::type", 
%"struct.make_storage_type::type"* %[[P]], i32 0, i32 0
+// CHECK: %[[X:.*]] = getelementptr inbounds 
%"struct.make_storage_type::type::B", 
%"struct.make_storage_type::type::B"* %[[B]], i32 0, i32 1
+// CHECK: call void asm sideeffect inteldialect "mov edx, dword ptr $0", 
"*m,~{edx},~{dirflag},~{fpsr},~{flags}"(i32* %[[X]])


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

Re: [PATCH] D15861: Support fully-qualified names for all QualTypes

[Richard Smith via cfe-commits]

rsmith added inline comments.


Comment at: include/clang/Tooling/Core/QualTypeNames.h:32
@@ +31,3 @@
+namespace TypeName {
+///\brief Convert the type into one with fully qualified template
+/// arguments.

Please ensure there's a space between each `/// ` and the content.


Comment at: include/clang/Tooling/Core/QualTypeNames.h:32-33
@@ +31,4 @@
+namespace TypeName {
+///\brief Convert the type into one with fully qualified template
+/// arguments.
+///\param[in] QT - the type for which the fully qualified type will be

rsmith wrote:
> Please ensure there's a space between each `/// ` and the content.
What do you mean by "fully qualified template arguments" here? Let me give you 
some examples:

namespace A {
  struct X {};
}
using A::X;
namespace B {
  using std::tuple;
  typedef typle TX;
  TX t;
  struct A { typedef int X; };
}

What is the fully-qualified name of `B::t`'s type? Is it `B::TX` or 
`std::tuple` or `std::tuple<::A::X>`? Note that if you want to redeclare 
`t` from within namespace `B`, `std::tuple` will name the wrong type.


Why does this only affect template arguments? Its name suggests it should 
affect the type as a whole (for instance, in the above case it should produce 
`std::tuple<...>`, not `tuple<...>`).


Generally, I think this interface needs to specify where the produced names can 
be used as a name for the specified type, otherwise I don't see how it can ever 
be reliable. For instance:

> "Generates a name for a type that can be used to name the same type if used 
> at the end of the current translation unit." (eg, `B::TX` or `std::tuple`)

or:

> "Generates a maximally-explicit name for a type that can be used in any 
> context where all the relevant components have been declared. In such a 
> context, this name will either name the intended type or produce an ambiguity 
> error." (eg, `::std::tuple<::A::X>`)

You should also specify what happens when it's not possible to generate such a 
name. For instance, given:

void f() {
  struct X {} x;
}

... there's no way to name the type of `x` from outside `f` (which makes 
certain refactoring operations impossible unless you also move the definition 
of `struct X`).


I think the ideal interface here would allow you to specify a location where 
you wish to insert the name, and would produce a "best possible" name for that 
type for that location, avoiding adding explicit qualification / desugaring 
wherever possible, but the interface should at least take the 
context-sensitivity of names into account.


Comment at: include/clang/Tooling/Core/QualTypeNames.h:37
@@ +36,3 @@
+///\param[in] Ctx - the ASTContext to be used.
+clang::QualType getFullyQualifiedType(clang::QualType QT,
+  const clang::ASTContext &Ctx);

Remove the `clang::`s; you're already in namespace `clang`.


Comment at: include/clang/Tooling/Core/QualTypeNames.h:49-79
@@ +48,33 @@
+
+///\brief Create a NestedNameSpecifier for Namesp and its enclosing
+/// scopes.
+///
+///\param[in] Ctx - the AST Context to be used.
+///\param[in] Namesp - the NamespaceDecl for which a NestedNameSpecifier
+/// is requested.
+clang::NestedNameSpecifier *createNestedNameSpecifier(
+const clang::ASTContext &Ctx, const clang::NamespaceDecl *Namesp);
+
+///\brief Create a NestedNameSpecifier for TagDecl and its enclosing
+/// scopes.
+///
+///\param[in] Ctx - the AST Context to be used.
+///\param[in] TD - the TagDecl for which a NestedNameSpecifier is
+/// requested.
+///\param[in] FullyQualify - Convert all template arguments into fully
+/// qualified names.
+clang::NestedNameSpecifier *createNestedNameSpecifier(
+const clang::ASTContext &Ctx, const clang::TagDecl *TD, bool FullyQualify);
+
+///\brief Create a NestedNameSpecifier for TypedefDecl and its enclosing
+/// scopes.
+///
+///\param[in] Ctx - the AST Context to be used.
+///\param[in] TD - the TypedefDecl for which a NestedNameSpecifier is
+/// requested.
+///\param[in] FullyQualify - Convert all template arguments (of possible
+/// parent scopes) into fully qualified names.
+clang::NestedNameSpecifier *createNestedNameSpecifier(
+const clang::ASTContext &Ctx, const clang::TypedefNameDecl *TD,
+bool FullyQualify);
+

Is it useful to expose the intermediary functionality to generate 
fully-qualified `QualType`s and `NestedNameSpecifier`s rather than only 
exposing functionality to generate `string`s? What are the intended uses of 
these functions?


Comment at: lib/Tooling/Core/QualTypeNames.cpp:341-343
@@ +340,5 @@
+  llvm::dyn_cast(QT.getTypePtr())) {
+// Intentionally, we do not care about the other compononent of
+// the elaborated type (the keyword) as part of the name
+// normalization is to remove it.
+Prefix = ETypeInput->getQualifier();
-

r256797 - Remove an unused parameter

[David Majnemer via cfe-commits]

Author: majnemer
Date: Mon Jan  4 18:08:41 2016
New Revision: 256797

URL: http://llvm.org/viewvc/llvm-project?rev=256797&view=rev
Log:
Remove an unused parameter

No functionality change is intended

Modified:
cfe/trunk/include/clang/Sema/Sema.h
cfe/trunk/lib/Parse/ParseStmtAsm.cpp
cfe/trunk/lib/Sema/SemaStmtAsm.cpp

Modified: cfe/trunk/include/clang/Sema/Sema.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=256797&r1=256796&r2=256797&view=diff
==
--- cfe/trunk/include/clang/Sema/Sema.h (original)
+++ cfe/trunk/include/clang/Sema/Sema.h Mon Jan  4 18:08:41 2016
@@ -3416,7 +3416,6 @@ public:
   bool LookupInlineAsmField(StringRef Base, StringRef Member,
 unsigned &Offset, SourceLocation AsmLoc);
   ExprResult LookupInlineAsmVarDeclField(Expr *RefExpr, StringRef Member,
- unsigned &Offset,
  llvm::InlineAsmIdentifierInfo &Info,
  SourceLocation AsmLoc);
   StmtResult ActOnMSAsmStmt(SourceLocation AsmLoc, SourceLocation LBraceLoc,

Modified: cfe/trunk/lib/Parse/ParseStmtAsm.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/ParseStmtAsm.cpp?rev=256797&r1=256796&r2=256797&view=diff
==
--- cfe/trunk/lib/Parse/ParseStmtAsm.cpp (original)
+++ cfe/trunk/lib/Parse/ParseStmtAsm.cpp Mon Jan  4 18:08:41 2016
@@ -241,9 +241,8 @@ ExprResult Parser::ParseMSAsmIdentifier(
 ConsumeToken(); // Consume the period.
 IdentifierInfo *Id = Tok.getIdentifierInfo();
 ConsumeToken(); // Consume the identifier.
-unsigned OffsetUnused;
-Result = Actions.LookupInlineAsmVarDeclField(
-Result.get(), Id->getName(), OffsetUnused, Info, Tok.getLocation());
+Result = Actions.LookupInlineAsmVarDeclField(Result.get(), Id->getName(),
+ Info, Tok.getLocation());
   }
 
   // Figure out how many tokens we are into LineToks.

Modified: cfe/trunk/lib/Sema/SemaStmtAsm.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaStmtAsm.cpp?rev=256797&r1=256796&r2=256797&view=diff
==
--- cfe/trunk/lib/Sema/SemaStmtAsm.cpp (original)
+++ cfe/trunk/lib/Sema/SemaStmtAsm.cpp Mon Jan  4 18:08:41 2016
@@ -672,7 +672,7 @@ bool Sema::LookupInlineAsmField(StringRe
 }
 
 ExprResult
-Sema::LookupInlineAsmVarDeclField(Expr *E, StringRef Member, unsigned &Offset,
+Sema::LookupInlineAsmVarDeclField(Expr *E, StringRef Member,
   llvm::InlineAsmIdentifierInfo &Info,
   SourceLocation AsmLoc) {
   Info.clear();
@@ -706,9 +706,6 @@ Sema::LookupInlineAsmVarDeclField(Expr *
   if (!FD)
 return ExprResult();
 
-  Offset = (unsigned)Context.toCharUnitsFromBits(Context.getFieldOffset(FD))
-   .getQuantity();
-
   // Make an Expr to thread through OpDecl.
   ExprResult Result = BuildMemberReferenceExpr(
   E, E->getType(), AsmLoc, /*IsArrow=*/false, CXXScopeSpec(),


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

Re: r255371 - Error on redeclaring with a conflicting asm label and on redeclaring with an asm label after the first ODR-use. Detects problems like the one in PR22830 where gcc and clang both compiled

[Roland McGrath via cfe-commits]

Kostya, do you remember the exact original case in glibc for 22830 and
what glibc change fixed it?
I vaguely recall the case, but not enough to find the actual change
and compare it to the new scenarios.
I suspect that the original case was easy to fix because it was just
that the hidden_proto magic had been put in the wrong place.

The fstat/__fxstat case is harder.  The original declaration of
__fxstat and the extern inline (that is, 'extern __inline
__attribute__ ((__gnu_inline__))') definition of fstat (which calls
__fxstat) is in the installed header, while the hidden_proto (i.e.
redeclaration with asm label) is in the wrapper header (and
necessarily must come after the #include of the installed header).

A GNU extern inline case is one where the rationale I mentioned in
https://llvm.org/bugs/show_bug.cgi?id=22830#c1 for Clang not being
able to match GCC's semantics might not really apply: you never need
to emit the code for fstat before the redeclaration, because you only
ever inline it and never emit an actual function.

Perhaps there is a defensible reason that Clang really cannot match
the GNU semantics even for this case.  Regardless, Clang really needs
to thoroughly document its semantics for every language extension when
its semantics are not completely identical to the GNU language
extension's semantics.

If Clang's asm labels extension persists in having semantics
incompatible with the original semantics of the asm labels extension
invented by GNU, we might be able to work around it adequately in the
glibc build just by making sure __USE_EXTERN_INLINES is not defined
during the build.


On Mon, Jan 4, 2016 at 3:39 PM, Kostya Serebryany  wrote:
> Thanks for checking, Nick!
> +Roland, FYI (recent changes in clang break compilation of all of the
> glibc),
> similar to https://llvm.org/bugs/show_bug.cgi?id=22830#c1
>
> On Mon, Jan 4, 2016 at 3:21 PM, Nick Lewycky  wrote:
>>
>> On 01/04/2016 01:40 PM, Kostya Serebryany wrote:
>>>
>>>
>>>
>>> On Thu, Dec 17, 2015 at 5:03 PM, Richard Smith >> > wrote:
>>>
>>> On Thu, Dec 17, 2015 at 3:59 PM, Nick Lewycky via cfe-commits
>>> mailto:cfe-commits@lists.llvm.org>>
>>> wrote:
>>>
>>> On 12/17/2015 10:47 AM, Kostya Serebryany wrote:
>>>
>>> I am now observing this error message when building glibc
>>> with clang
>>> (from trunk):
>>> ../include/string.h:101:28: error: cannot apply asm label to
>>> function
>>> after its first use
>>> libc_hidden_builtin_proto (memcpy)
>>> (many more instances)
>>>
>>>
>>> Do you think this is a bug in glibc code, or the error
>>> message could be
>>> more relaxed?
>>>
>>>
>>> Could you email me a .i copy of a failing build? That will help
>>> me decide whether it's a bug in the error or in glibc.
>>>
>>>
>>> [sorry for delay,]
>>> here is the preprocessed source file from glibc:
>>> % clang  ~/tmp/a.i 2>&1 | grep error:
>>> ../include/sys/stat.h:16:28: error: cannot apply asm label to function
>>> after its first use
>>> ../include/sys/stat.h:17:30: error: cannot apply asm label to function
>>> after its first use
>>> ../include/sys/stat.h:18:28: error: cannot apply asm label to function
>>> after its first use
>>> ../include/sys/stat.h:19:30: error: cannot apply asm label to function
>>> after its first use
>>> ...
>>>
>>>
>>> Also PR22830 comment 1 seems relevant here.
>>>
>>>
>>> Probably, but since this is a very recent regression in clang I thought
>>> I should report it.
>>
>>
>> This looks like it's WAI:
>>
>> 3783extern int __fxstat (int __ver, int __fildes, struct stat
>> *__stat_buf)
>> 3784 __attribute__ ((__nothrow__ )) ;
>> ...
>> 3827extern __inline int
>> 3828__attribute__ ((__nothrow__ )) fstat (int __fd, struct stat
>> *__statbuf)
>> 3829{
>> 3830  return __fxstat (1, __fd, __statbuf);
>> 3831}
>> ...
>> 3910extern __typeof (__fxstat) __fxstat __asm__ ("" "__GI___fxstat")
>> __attribute__ ((visibility ("hidden")));
>>
>> This is exactly the situation where GCC and Clang will emit a different .o
>> file.
>>
>> Nick
>>
>>> On Fri, Dec 11, 2015 at 1:28 PM, Nick Lewycky via cfe-commits
>>> >> 
>>> >>
>>> >> wrote:
>>>
>>>  Author: nicholas
>>>  Date: Fri Dec 11 15:28:55 2015
>>>  New Revision: 255371
>>>
>>>  URL:
>>> http://llvm.org/viewvc/llvm-project?rev=255371&view=rev
>>>  Log:
>>>  Error on redeclaring with a conflicting asm label and
>>> on redeclaring
>>>  with an asm label after the first ODR-use. Detects
>>> problems like the
>>>  one in PR228

Re: r255371 - Error on redeclaring with a conflicting asm label and on redeclaring with an asm label after the first ODR-use. Detects problems like the one in PR22830 where gcc and clang both compiled

[Kostya Serebryany via cfe-commits]

On Mon, Jan 4, 2016 at 4:04 PM, Roland McGrath  wrote:

> Kostya, do you remember the exact original case in glibc for 22830 and
> what glibc change fixed it?
>
Sadly, no.
I only know that the code was reduced from the code that was setting these
attributes for strtol.


I vaguely recall the case, but not enough to find the actual change
> and compare it to the new scenarios.
> I suspect that the original case was easy to fix because it was just
> that the hidden_proto magic had been put in the wrong place.
>
> The fstat/__fxstat case is harder.  The original declaration of
> __fxstat and the extern inline (that is, 'extern __inline
> __attribute__ ((__gnu_inline__))') definition of fstat (which calls
> __fxstat) is in the installed header, while the hidden_proto (i.e.
> redeclaration with asm label) is in the wrapper header (and
> necessarily must come after the #include of the installed header).
>
> A GNU extern inline case is one where the rationale I mentioned in
> https://llvm.org/bugs/show_bug.cgi?id=22830#c1 for Clang not being
> able to match GCC's semantics might not really apply: you never need
> to emit the code for fstat before the redeclaration, because you only
> ever inline it and never emit an actual function.
>
> Perhaps there is a defensible reason that Clang really cannot match
> the GNU semantics even for this case.  Regardless, Clang really needs
> to thoroughly document its semantics for every language extension when
> its semantics are not completely identical to the GNU language
> extension's semantics.
>
> If Clang's asm labels extension persists in having semantics
> incompatible with the original semantics of the asm labels extension
> invented by GNU, we might be able to work around it adequately in the
> glibc build just by making sure __USE_EXTERN_INLINES is not defined
> during the build.
>
>
> On Mon, Jan 4, 2016 at 3:39 PM, Kostya Serebryany  wrote:
> > Thanks for checking, Nick!
> > +Roland, FYI (recent changes in clang break compilation of all of the
> > glibc),
> > similar to https://llvm.org/bugs/show_bug.cgi?id=22830#c1
> >
> > On Mon, Jan 4, 2016 at 3:21 PM, Nick Lewycky  wrote:
> >>
> >> On 01/04/2016 01:40 PM, Kostya Serebryany wrote:
> >>>
> >>>
> >>>
> >>> On Thu, Dec 17, 2015 at 5:03 PM, Richard Smith  >>> > wrote:
> >>>
> >>> On Thu, Dec 17, 2015 at 3:59 PM, Nick Lewycky via cfe-commits
> >>> mailto:cfe-commits@lists.llvm.org>>
> >>> wrote:
> >>>
> >>> On 12/17/2015 10:47 AM, Kostya Serebryany wrote:
> >>>
> >>> I am now observing this error message when building glibc
> >>> with clang
> >>> (from trunk):
> >>> ../include/string.h:101:28: error: cannot apply asm label
> to
> >>> function
> >>> after its first use
> >>> libc_hidden_builtin_proto (memcpy)
> >>> (many more instances)
> >>>
> >>>
> >>> Do you think this is a bug in glibc code, or the error
> >>> message could be
> >>> more relaxed?
> >>>
> >>>
> >>> Could you email me a .i copy of a failing build? That will help
> >>> me decide whether it's a bug in the error or in glibc.
> >>>
> >>>
> >>> [sorry for delay,]
> >>> here is the preprocessed source file from glibc:
> >>> % clang  ~/tmp/a.i 2>&1 | grep error:
> >>> ../include/sys/stat.h:16:28: error: cannot apply asm label to function
> >>> after its first use
> >>> ../include/sys/stat.h:17:30: error: cannot apply asm label to function
> >>> after its first use
> >>> ../include/sys/stat.h:18:28: error: cannot apply asm label to function
> >>> after its first use
> >>> ../include/sys/stat.h:19:30: error: cannot apply asm label to function
> >>> after its first use
> >>> ...
> >>>
> >>>
> >>> Also PR22830 comment 1 seems relevant here.
> >>>
> >>>
> >>> Probably, but since this is a very recent regression in clang I thought
> >>> I should report it.
> >>
> >>
> >> This looks like it's WAI:
> >>
> >> 3783extern int __fxstat (int __ver, int __fildes, struct stat
> >> *__stat_buf)
> >> 3784 __attribute__ ((__nothrow__ )) ;
> >> ...
> >> 3827extern __inline int
> >> 3828__attribute__ ((__nothrow__ )) fstat (int __fd, struct stat
> >> *__statbuf)
> >> 3829{
> >> 3830  return __fxstat (1, __fd, __statbuf);
> >> 3831}
> >> ...
> >> 3910extern __typeof (__fxstat) __fxstat __asm__ ("" "__GI___fxstat")
> >> __attribute__ ((visibility ("hidden")));
> >>
> >> This is exactly the situation where GCC and Clang will emit a different
> .o
> >> file.
> >>
> >> Nick
> >>
> >>> On Fri, Dec 11, 2015 at 1:28 PM, Nick Lewycky via
> cfe-commits
> >>>  >>> 
> >>>  >>>
> >>> >> wrote:
> >>>
> >>>  Author: nicholas
> >>>  Date: Fri Dec 11 15:28:55 2015

Re: [PATCH] D15705: Adding a scripted test for PR25717

[Yunzhong Gao via cfe-commits]

ygao added a comment.

> What I would suggest is:

> 

>   Check that this test fails at least on windows with your patch

> 

> reverted. If so, commit it. BTW, don't you need to drop the "|

>  FileCheck" to cause a crash?


Hmm, even with the pipe removed, I still have difficulty reproducing the crash 
within lit. I was doing:
C:\llvm\build>python ..\llvm\utils\lit\lit.py -v --no-progress-bar --param 
build_mode=Release tools\clang\test\Preprocessor\macro.c
But the test is passing. And the run line is simply:
// RUN: %clang_cc1 -E -x c %s

And, if I use the RUN line directly on a command-prompt, the test crashes as 
expected.


http://reviews.llvm.org/D15705



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

Re: [PATCH] D15686: PR25910: clang allows two var definitions with the same mangled name

[Artem Belevich via cfe-commits]

tra added inline comments.


Comment at: lib/CodeGen/CodeGenModule.cpp:1235-1236
@@ -1235,8 +1234,4 @@
 // different type.
-// FIXME: Support for variables is not implemented yet.
-if (isa(D.getDecl()))
-  GV = cast(GetAddrOfGlobal(D, 
/*IsForDefinition=*/true));
-else
-  if (!GV)
-GV = GetGlobalValue(getMangledName(D));
+llvm::GlobalValue *GV =
+cast(GetAddrOfGlobal(D, /*IsForDefinition=*/true));
 

andreybokhanko wrote:
> Artem, to address your concern (from http://reviews.llvm.org/rL254195#39417): 
> if IsForDefinition equals to true, it is guaranteed that we get GlobalValue 
> here. We specifically call GetAddrOfGlobal to create (or get) a global with 
> required type, not cast from a declaration with a different type.
Empirical evidence suggests that it's possible to get non GlobalValue from 
GetAddrOfGlobal.
For instance, you may get llvm::UnaryConstantExpr which would be the case when 
GetAddrOfGlobal returns an addrspacecast which may happen during CUDA or OpenCL 
compilation.

If you want to reproduce the problem, apply my pending patch 
http://reviews.llvm.org/D15305 which has to defer emitting some variables. Run 
clang tests and you will see a lot of CUDA test cases crashing with assertion 
on this cast.



http://reviews.llvm.org/D15686



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

r256803 - Avoid walking all the declarations in the TU when a tag is declared in function

[Richard Smith via cfe-commits]

Author: rsmith
Date: Mon Jan  4 19:21:53 2016
New Revision: 256803

URL: http://llvm.org/viewvc/llvm-project?rev=256803&view=rev
Log:
Avoid walking all the declarations in the TU when a tag is declared in function
prototype scope in a function definition.

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

Modified: cfe/trunk/lib/Sema/SemaDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDecl.cpp?rev=256803&r1=256802&r2=256803&view=diff
==
--- cfe/trunk/lib/Sema/SemaDecl.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDecl.cpp Mon Jan  4 19:21:53 2016
@@ -10911,12 +10911,8 @@ Decl *Sema::ActOnStartOfFunctionDef(Scop
   // from the translation unit and reattach to the current context.
   if (D->getLexicalDeclContext() == Context.getTranslationUnitDecl()) {
 // Is the decl actually in the context?
-for (const auto *DI : Context.getTranslationUnitDecl()->decls()) {
-  if (DI == D) {  
-Context.getTranslationUnitDecl()->removeDecl(D);
-break;
-  }
-}
+if (Context.getTranslationUnitDecl()->containsDecl(D))
+  Context.getTranslationUnitDecl()->removeDecl(D);
 // Either way, reassign the lexical decl context to our FunctionDecl.
 D->setLexicalDeclContext(CurContext);
   }


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

[PATCH] D15881: [DWARF] Omitting the explicit import of an anonymous namespace is a debugger-tuning decision, not a target decision.

[Paul Robinson via cfe-commits]

probinson created this revision.
probinson added reviewers: echristo, dblaikie, aprantl.
probinson added a subscriber: cfe-commits.

GDB and LLDB don't mind if we omit the explicit import of an anonymous 
namespace.


http://reviews.llvm.org/D15881

Files:
  lib/Frontend/CompilerInvocation.cpp
  test/CodeGenCXX/debug-info-anon-namespace.cpp

Index: test/CodeGenCXX/debug-info-anon-namespace.cpp
===
--- test/CodeGenCXX/debug-info-anon-namespace.cpp
+++ test/CodeGenCXX/debug-info-anon-namespace.cpp
@@ -1,5 +1,7 @@
-// RUN: %clang_cc1 -emit-llvm -debug-info-kind=limited -triple x86_64-scei-ps4 
-O0 %s -o - | FileCheck --check-prefix=PS4 %s
-// RUN: %clang_cc1 -emit-llvm -debug-info-kind=limited -triple 
x86_64-unknown-linux-gnu -O0 %s -o - | FileCheck --check-prefix=NON-PS4 %s
+// RUN: %clang_cc1 -emit-llvm -triple %itanium_abi_triple 
-debug-info-kind=limited -debugger-tuning=gdb -O0 %s -o - | FileCheck 
--check-prefix=NOIMPORT %s
+// RUN: %clang_cc1 -emit-llvm -triple %itanium_abi_triple 
-debug-info-kind=limited -debugger-tuning=lldb -O0 %s -o - | FileCheck 
--check-prefix=NOIMPORT %s
+// RUN: %clang_cc1 -emit-llvm -triple %itanium_abi_triple 
-debug-info-kind=limited -debugger-tuning=sce -O0 %s -o - | FileCheck 
--check-prefix=IMPORT %s
+// RUN: %clang_cc1 -emit-llvm -triple %itanium_abi_triple 
-debug-info-kind=limited -O0 %s -o - | FileCheck --check-prefix=IMPORT %s
 
 namespace
 {
@@ -18,9 +20,9 @@
 int *b2 = &a2;
 
 
-// PS4:  [[NS:![0-9]+]] = !DINamespace
-// PS4:  [[NS2:![0-9]+]] = !DINamespace
-// PS4: !DIImportedEntity(tag: DW_TAG_imported_module, scope: !0, entity: 
[[NS]])
-// PS4: !DIImportedEntity(tag: DW_TAG_imported_module, scope: [[NS]], entity: 
[[NS2]], line: {{[0-9]+}})
-// NON-PS4-NOT: !DIImportedEntity
+// IMPORT:  [[NS:![0-9]+]] = !DINamespace
+// IMPORT:  [[NS2:![0-9]+]] = !DINamespace
+// IMPORT: !DIImportedEntity(tag: DW_TAG_imported_module, scope: !0, entity: 
[[NS]])
+// IMPORT: !DIImportedEntity(tag: DW_TAG_imported_module, scope: [[NS]], 
entity: [[NS2]], line: {{[0-9]+}})
+// NOIMPORT-NOT: !DIImportedEntity
 
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -360,6 +360,14 @@
   }
 }
 
+// Convenience functions for debugger tuning.
+static bool tuneForGDB(CodeGenOptions &Opts) {
+  return Opts.getDebuggerTuning() == CodeGenOptions::DebuggerKindGDB;
+}
+static bool tuneForLLDB(CodeGenOptions &Opts) {
+  return Opts.getDebuggerTuning() == CodeGenOptions::DebuggerKindLLDB;
+}
+
 static bool ParseCodeGenArgs(CodeGenOptions &Opts, ArgList &Args, InputKind IK,
  DiagnosticsEngine &Diags,
  const TargetOptions &TargetOpts) {
@@ -417,7 +425,7 @@
   Opts.EmitCodeView = Args.hasArg(OPT_gcodeview);
   Opts.SplitDwarfFile = Args.getLastArgValue(OPT_split_dwarf_file);
   Opts.DebugTypeExtRefs = Args.hasArg(OPT_dwarf_ext_refs);
-  Opts.DebugExplicitImport = Triple.isPS4CPU(); 
+  Opts.DebugExplicitImport = !tuneForGDB(Opts) && !tuneForLLDB(Opts);
 
   for (const auto &Arg : Args.getAllArgValues(OPT_fdebug_prefix_map_EQ))
 Opts.DebugPrefixMap.insert(StringRef(Arg).split('='));


Index: test/CodeGenCXX/debug-info-anon-namespace.cpp
===
--- test/CodeGenCXX/debug-info-anon-namespace.cpp
+++ test/CodeGenCXX/debug-info-anon-namespace.cpp
@@ -1,5 +1,7 @@
-// RUN: %clang_cc1 -emit-llvm -debug-info-kind=limited -triple x86_64-scei-ps4 -O0 %s -o - | FileCheck --check-prefix=PS4 %s
-// RUN: %clang_cc1 -emit-llvm -debug-info-kind=limited -triple x86_64-unknown-linux-gnu -O0 %s -o - | FileCheck --check-prefix=NON-PS4 %s
+// RUN: %clang_cc1 -emit-llvm -triple %itanium_abi_triple -debug-info-kind=limited -debugger-tuning=gdb -O0 %s -o - | FileCheck --check-prefix=NOIMPORT %s
+// RUN: %clang_cc1 -emit-llvm -triple %itanium_abi_triple -debug-info-kind=limited -debugger-tuning=lldb -O0 %s -o - | FileCheck --check-prefix=NOIMPORT %s
+// RUN: %clang_cc1 -emit-llvm -triple %itanium_abi_triple -debug-info-kind=limited -debugger-tuning=sce -O0 %s -o - | FileCheck --check-prefix=IMPORT %s
+// RUN: %clang_cc1 -emit-llvm -triple %itanium_abi_triple -debug-info-kind=limited -O0 %s -o - | FileCheck --check-prefix=IMPORT %s
 
 namespace
 {
@@ -18,9 +20,9 @@
 int *b2 = &a2;
 
 
-// PS4:  [[NS:![0-9]+]] = !DINamespace
-// PS4:  [[NS2:![0-9]+]] = !DINamespace
-// PS4: !DIImportedEntity(tag: DW_TAG_imported_module, scope: !0, entity: [[NS]])
-// PS4: !DIImportedEntity(tag: DW_TAG_imported_module, scope: [[NS]], entity: [[NS2]], line: {{[0-9]+}})
-// NON-PS4-NOT: !DIImportedEntity
+// IMPORT:  [[NS:![0-9]+]] = !DINamespace
+// IMPORT:  [[NS2:![0-9]+]] = !DINamespace
+// IMPORT: !DIImportedEntity(tag: DW_TAG_imported_module, scope: !0, entity: [[NS]])
+// IMPORT: !DIImportedEntity(tag: DW_TAG_importe

Re: [PATCH] D15603: [OpenCL] Pipe type support

[Xiuli PAN via cfe-commits]

pxli168 added inline comments.


Comment at: lib/AST/ASTContext.cpp:3121
@@ +3120,3 @@
+QualType ASTContext::getPipeType(QualType T) const {
+  // Unique pointers, to guarantee there is only one pointer of a particular
+  // structure.

Anastasia wrote:
> Could we update the comment here or otherwise I think it's best to be removed!
OK, just removed the copy paste one


Comment at: lib/CodeGen/CGOpenCLRuntime.cpp:108
@@ +107,3 @@
+PipeTy = llvm::PointerType::get(llvm::StructType::create(
+  CGM.getLLVMContext(), "opencl.pipe_t"), PipeAddrSpc);
+  }

Anastasia wrote:
> pxli168 wrote:
> > pekka.jaaskelainen wrote:
> > > pxli168 wrote:
> > > > pekka.jaaskelainen wrote:
> > > > > I'm not sure if touching the built-in fingerprints for this is a good 
> > > > > idea. It might lead to problems and confusion. Cannot one pass pipes 
> > > > > as arguments to user functions too? Are the fingerprints of those 
> > > > > functions then modified accordingly? It might become messy.
> > > > > 
> > > > > Because the packet size is known at host side, the pipes can be 
> > > > > implemented as structs which holds the packet size as one of the 
> > > > > member variables. The problem with this approach is how to exploit 
> > > > > wider reads/writes instead of a scalar read/write loop + unpack/pack 
> > > > > in case of vector datatypes. 
> > > > > 
> > > > > If the size is known only at runtime, one cannot easily generate 
> > > > > vector reads/writes even if the element is a vector datatype and it 
> > > > > would be efficient to keep the packet in a vector register as long as 
> > > > > possible. For helping this I'd add a metadata which can be utilized 
> > > > > at compile time to make reading/writing from the pipe faster.  But in 
> > > > > a way that is already an optimization, not a requirement, to make 
> > > > > pipes work.
> > > > > 
> > > > > The reading itself is platform dependent as the pipe can be even a 
> > > > > hardware FIFO accessed using special instructions.
> > > > This is what I'm worry about, I don't think we need to give much 
> > > > information about an opaque type in OpenCL.
> > > > 
> > > > Actually we can get the element type from the metadata, and I think we 
> > > > can leave the optimization to the backend and let platform to choose 
> > > > which way to use for read/write pipe.
> > > > 
> > > > And I think the built-in function support for the pipe in OpenCL-C is 
> > > > not necessary in the clang, what do you think? Though it can do some 
> > > > check in Sema check, they can also be done in some llvm pass in 
> > > > backend. If the built-in is really needed, I will send another patch 
> > > > based on this included built-in support for pipe.
> > > > 
> > > > Thank you.
> > > As far as I've understood, no there's no need to add built-in function 
> > > awareness to the frontend for this case. Sema checking/diagnostics is 
> > > needed to ensure pipes are used only as function arguments, not local 
> > > variables, for example. Is this patch missing it?
> > I think there are a lot of Sema checking about OpenCL2.0 are missing, the 
> > pipe could not be a local variable is just one, there are also some check 
> > are missing for reserve_id_t in my tests these days. 
> > My plan is to use a patch to cover all these missing Sema check for OpenCL. 
> > That would be a hard work with the OpenCL Specification and would take a 
> > lot of time and may delay this patch, so could you accept this patch first 
> > and let me to finish the missing Sema check later to make sure cover more 
> > missing part.
> I am Ok with not adding everything in one commit. We can revisit/modify 
> things later on.
Do you think we need the make the read/write_pipe as a builtin in clang? Since 
these function need the pipe element type to be the same with the pointer 
pointee type. I find it hard to handle this in a backend.


Comment at: test/SemaOpenCL/invalid-pipes-cl2.0.cl:3
@@ +2,3 @@
+
+void test(read_only pipe int *p){// expected-error {{pipes packet types cannot 
be of reference type}}
+}

Anastasia wrote:
> I can see more than one diagnostic being added in this patch, but the test 
> covers only one.
It seems the auto related diagnostic is not necessary, since auto can not be 
used in OpenCL.

And the  "err_missing_actual_pipe_type" seems is used in a wrong place, it 
could not handle something like 
```pipe p
```
This will case "warning: type specifier missing, defaults to 'int'"

But something like

```
int pipe p
```
will has  "error: missing actual type specifier for pipe"
It seems this should be call “cannot combine with previous 'int' declaration 
specifier”
And the "error: missing actual type specifier for pipe" should be placed 
somewhere else.


http://reviews.llvm.org/D15603



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.

[PATCH] D15882: Avoid assert failure on some invalid cc1 options.

[Douglas Katzman via cfe-commits]

dougk created this revision.
dougk added reviewers: thakis, probinson.
dougk added a subscriber: cfe-commits.

Something like this was suggested in http://reviews.llvm.org/D13221


http://reviews.llvm.org/D15882

Files:
  lib/Frontend/CompilerInvocation.cpp
  test/Driver/debug-options.c

Index: test/Driver/debug-options.c
===
--- test/Driver/debug-options.c
+++ test/Driver/debug-options.c
@@ -169,3 +169,8 @@
 // NOCI-NOT: "-dwarf-column-info"
 //
 // GEXTREFS: "-dwarf-ext-refs" "-fmodule-format=obj" 
"-debug-info-kind={{standalone|limited}}"
+
+// RUN: not %clang -cc1 -debug-info-kind=watkind 2>&1 | FileCheck 
-check-prefix=BADSTRING1 %s
+// BADSTRING1: error: invalid value 'watkind' in '-debug-info-kind=watkind'
+// RUN: not %clang -cc1 -debugger-tuning=gmodal 2>&1 | FileCheck 
-check-prefix=BADSTRING2 %s
+// BADSTRING2: error: invalid value 'gmodal' in '-debugger-tuning=gmodal'
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -399,18 +399,29 @@
   }
 
   if (Arg *A = Args.getLastArg(OPT_debug_info_kind_EQ)) {
-Opts.setDebugInfo(
-llvm::StringSwitch(A->getValue())
+unsigned Val =
+llvm::StringSwitch(A->getValue())
 .Case("line-tables-only", CodeGenOptions::DebugLineTablesOnly)
 .Case("limited", CodeGenOptions::LimitedDebugInfo)
-.Case("standalone", CodeGenOptions::FullDebugInfo));
+.Case("standalone", CodeGenOptions::FullDebugInfo)
+.Default(~0U);
+if (Val == ~0U)
+  Diags.Report(diag::err_drv_invalid_value) << A->getAsString(Args)
+<< A->getValue();
+else
+  Opts.setDebugInfo(static_cast(Val));
   }
   if (Arg *A = Args.getLastArg(OPT_debugger_tuning_EQ)) {
-Opts.setDebuggerTuning(
-llvm::StringSwitch(A->getValue())
-.Case("gdb", CodeGenOptions::DebuggerKindGDB)
-.Case("lldb", CodeGenOptions::DebuggerKindLLDB)
-.Case("sce", CodeGenOptions::DebuggerKindSCE));
+unsigned Val = llvm::StringSwitch(A->getValue())
+   .Case("gdb", CodeGenOptions::DebuggerKindGDB)
+   .Case("lldb", CodeGenOptions::DebuggerKindLLDB)
+   .Case("sce", CodeGenOptions::DebuggerKindSCE)
+   .Default(~0U);
+if (Val == ~0U)
+  Diags.Report(diag::err_drv_invalid_value) << A->getAsString(Args)
+<< A->getValue();
+else
+  Opts.setDebuggerTuning(static_cast(Val));
   }
   Opts.DwarfVersion = getLastArgIntValue(Args, OPT_dwarf_version_EQ, 0, Diags);
   Opts.DebugColumnInfo = Args.hasArg(OPT_dwarf_column_info);


Index: test/Driver/debug-options.c
===
--- test/Driver/debug-options.c
+++ test/Driver/debug-options.c
@@ -169,3 +169,8 @@
 // NOCI-NOT: "-dwarf-column-info"
 //
 // GEXTREFS: "-dwarf-ext-refs" "-fmodule-format=obj" "-debug-info-kind={{standalone|limited}}"
+
+// RUN: not %clang -cc1 -debug-info-kind=watkind 2>&1 | FileCheck -check-prefix=BADSTRING1 %s
+// BADSTRING1: error: invalid value 'watkind' in '-debug-info-kind=watkind'
+// RUN: not %clang -cc1 -debugger-tuning=gmodal 2>&1 | FileCheck -check-prefix=BADSTRING2 %s
+// BADSTRING2: error: invalid value 'gmodal' in '-debugger-tuning=gmodal'
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -399,18 +399,29 @@
   }
 
   if (Arg *A = Args.getLastArg(OPT_debug_info_kind_EQ)) {
-Opts.setDebugInfo(
-llvm::StringSwitch(A->getValue())
+unsigned Val =
+llvm::StringSwitch(A->getValue())
 .Case("line-tables-only", CodeGenOptions::DebugLineTablesOnly)
 .Case("limited", CodeGenOptions::LimitedDebugInfo)
-.Case("standalone", CodeGenOptions::FullDebugInfo));
+.Case("standalone", CodeGenOptions::FullDebugInfo)
+.Default(~0U);
+if (Val == ~0U)
+  Diags.Report(diag::err_drv_invalid_value) << A->getAsString(Args)
+<< A->getValue();
+else
+  Opts.setDebugInfo(static_cast(Val));
   }
   if (Arg *A = Args.getLastArg(OPT_debugger_tuning_EQ)) {
-Opts.setDebuggerTuning(
-llvm::StringSwitch(A->getValue())
-.Case("gdb", CodeGenOptions::DebuggerKindGDB)
-.Case("lldb", CodeGenOptions::DebuggerKindLLDB)
-.Case("sce", CodeGenOptions::DebuggerKindSCE));
+unsigned Val = llvm::StringSwitch(A->getValue())
+   .Case("gdb", CodeGenOptions::DebuggerKindGDB)
+   .Case("lldb", CodeGenOptions::DebuggerKindLLDB)
+   .Cas