[PATCH] D65227: clang-format: Support `if CONSTEXPR` if CONSTEXPR is a macro.

[Phabricator via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL367167: clang-format: Support `if CONSTEXPR` if CONSTEXPR is 
a macro. (authored by nico, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D65227?vs=211554&id=212039#toc

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65227/new/

https://reviews.llvm.org/D65227

Files:
  cfe/trunk/lib/Format/ContinuationIndenter.cpp
  cfe/trunk/lib/Format/FormatToken.h
  cfe/trunk/lib/Format/TokenAnnotator.cpp
  cfe/trunk/lib/Format/UnwrappedLineParser.cpp
  cfe/trunk/unittests/Format/FormatTest.cpp

Index: cfe/trunk/lib/Format/TokenAnnotator.cpp
===
--- cfe/trunk/lib/Format/TokenAnnotator.cpp
+++ cfe/trunk/lib/Format/TokenAnnotator.cpp
@@ -175,9 +175,9 @@
   Contexts.back().IsExpression = false;
 } else if (Left->Previous &&
(Left->Previous->isOneOf(tok::kw_static_assert, tok::kw_decltype,
-tok::kw_if, tok::kw_while, tok::l_paren,
+tok::kw_while, tok::l_paren,
 tok::comma) ||
-Left->Previous->endsSequence(tok::kw_constexpr, tok::kw_if) ||
+Left->Previous->isIf() ||
 Left->Previous->is(TT_BinaryOperator))) {
   // static_assert, if and while usually contain expressions.
   Contexts.back().IsExpression = true;
@@ -825,8 +825,9 @@
   break;
 case tok::kw_if:
 case tok::kw_while:
+  assert(!Line.startsWith(tok::hash));
   if (Tok->is(tok::kw_if) && CurrentToken &&
-  CurrentToken->is(tok::kw_constexpr))
+  CurrentToken->isOneOf(tok::kw_constexpr, tok::identifier))
 next();
   if (CurrentToken && CurrentToken->is(tok::l_paren)) {
 next();
@@ -1078,6 +1079,7 @@
 case tok::pp_if:
 case tok::pp_elif:
   Contexts.back().IsExpression = true;
+  next();
   parseLine();
   break;
 default:
@@ -2409,8 +2411,7 @@
   Style.AlignAfterOpenBracket != FormatStyle::BAS_DontAlign)
 return 100;
   if (Left.is(tok::l_paren) && Left.Previous &&
-  (Left.Previous->isOneOf(tok::kw_if, tok::kw_for) ||
-   Left.Previous->endsSequence(tok::kw_constexpr, tok::kw_if)))
+  (Left.Previous->is(tok::kw_for) || Left.Previous->isIf()))
 return 1000;
   if (Left.is(tok::equal) && InFunctionDecl)
 return 110;
@@ -2611,10 +2612,10 @@
   return true;
 return Line.Type == LT_ObjCDecl || Left.is(tok::semi) ||
(Style.SpaceBeforeParens != FormatStyle::SBPO_Never &&
-(Left.isOneOf(tok::kw_if, tok::pp_elif, tok::kw_for, tok::kw_while,
+(Left.isOneOf(tok::pp_elif, tok::kw_for, tok::kw_while,
   tok::kw_switch, tok::kw_case, TT_ForEachMacro,
   TT_ObjCForIn) ||
- Left.endsSequence(tok::kw_constexpr, tok::kw_if) ||
+ Left.isIf(Line.Type != LT_PreprocessorDirective) ||
  (Left.isOneOf(tok::kw_try, Keywords.kw___except, tok::kw_catch,
tok::kw_new, tok::kw_delete) &&
   (!Left.Previous || Left.Previous->isNot(tok::period) ||
Index: cfe/trunk/lib/Format/ContinuationIndenter.cpp
===
--- cfe/trunk/lib/Format/ContinuationIndenter.cpp
+++ cfe/trunk/lib/Format/ContinuationIndenter.cpp
@@ -676,8 +676,7 @@
   State.Column += Spaces;
   if (Current.isNot(tok::comment) && Previous.is(tok::l_paren) &&
   Previous.Previous &&
-  (Previous.Previous->isOneOf(tok::kw_if, tok::kw_for) ||
-   Previous.Previous->endsSequence(tok::kw_constexpr, tok::kw_if))) {
+  (Previous.Previous->is(tok::kw_for) || Previous.Previous->isIf())) {
 // Treat the condition inside an if as if it was a second function
 // parameter, i.e. let nested calls have a continuation indent.
 State.Stack.back().LastSpace = State.Column;
Index: cfe/trunk/lib/Format/FormatToken.h
===
--- cfe/trunk/lib/Format/FormatToken.h
+++ cfe/trunk/lib/Format/FormatToken.h
@@ -327,6 +327,11 @@
   }
   template  bool isNot(T Kind) const { return !is(Kind); }
 
+  bool isIf(bool AllowConstexprMacro = true) const {
+return is(tok::kw_if) || endsSequence(tok::kw_constexpr, tok::kw_if) ||
+   (endsSequence(tok::identifier, tok::kw_if) && AllowConstexprMacro);
+  }
+
   bool closesScopeAfterBlock() const {
 if (BlockKind == BK_Block)
   return true;
@@ -344,6 +349,10 @@
 
   /// \c true if this token ends a sequence with the given tokens in order,
   /// following the ``Previous`` pointers, ignoring comments.
+  /// For example, given tokens [T1, T2, T3], the function returns true if
+  /// 3 tokens ending at this (ignoring

[PATCH] D65227: clang-format: Support `if CONSTEXPR` if CONSTEXPR is a macro.

[Nico Weber via Phabricator via cfe-commits]

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

Thanks, landing with your suggestion applied.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65227/new/

https://reviews.llvm.org/D65227



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

r367167 - clang-format: Support `if CONSTEXPR` if CONSTEXPR is a macro.

[Nico Weber via cfe-commits]

Author: nico
Date: Fri Jul 26 19:41:40 2019
New Revision: 367167

URL: http://llvm.org/viewvc/llvm-project?rev=367167&view=rev
Log:
clang-format: Support `if CONSTEXPR` if CONSTEXPR is a macro.

This is like r305666 (which added support for `if constexpr`) except
that it allows a macro name after the if.

This is slightly tricky for two reasons:

1. r305666 didn't add test coverage for all cases where it added a
   kw_constexpr, so I had to figure out what all the added cases were
   for. I now added tests for all `if constexpr` bits that didn't have
   tests. (This took a while, see e.g. https://reviews.llvm.org/D65223)

2. Parsing `if  (` as an if means that `#if defined(` and
   `#if __has_include(` parse as ifs too. Add some special-case code
   to prevent this from happening where it's incorrect.

Fixes PR39248.

Differential Revision: https://reviews.llvm.org/D65227

Modified:
cfe/trunk/lib/Format/ContinuationIndenter.cpp
cfe/trunk/lib/Format/FormatToken.h
cfe/trunk/lib/Format/TokenAnnotator.cpp
cfe/trunk/lib/Format/UnwrappedLineParser.cpp
cfe/trunk/unittests/Format/FormatTest.cpp

Modified: cfe/trunk/lib/Format/ContinuationIndenter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/ContinuationIndenter.cpp?rev=367167&r1=367166&r2=367167&view=diff
==
--- cfe/trunk/lib/Format/ContinuationIndenter.cpp (original)
+++ cfe/trunk/lib/Format/ContinuationIndenter.cpp Fri Jul 26 19:41:40 2019
@@ -676,8 +676,7 @@ void ContinuationIndenter::addTokenOnCur
   State.Column += Spaces;
   if (Current.isNot(tok::comment) && Previous.is(tok::l_paren) &&
   Previous.Previous &&
-  (Previous.Previous->isOneOf(tok::kw_if, tok::kw_for) ||
-   Previous.Previous->endsSequence(tok::kw_constexpr, tok::kw_if))) {
+  (Previous.Previous->is(tok::kw_for) || Previous.Previous->isIf())) {
 // Treat the condition inside an if as if it was a second function
 // parameter, i.e. let nested calls have a continuation indent.
 State.Stack.back().LastSpace = State.Column;

Modified: cfe/trunk/lib/Format/FormatToken.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/FormatToken.h?rev=367167&r1=367166&r2=367167&view=diff
==
--- cfe/trunk/lib/Format/FormatToken.h (original)
+++ cfe/trunk/lib/Format/FormatToken.h Fri Jul 26 19:41:40 2019
@@ -327,6 +327,11 @@ struct FormatToken {
   }
   template  bool isNot(T Kind) const { return !is(Kind); }
 
+  bool isIf(bool AllowConstexprMacro = true) const {
+return is(tok::kw_if) || endsSequence(tok::kw_constexpr, tok::kw_if) ||
+   (endsSequence(tok::identifier, tok::kw_if) && AllowConstexprMacro);
+  }
+
   bool closesScopeAfterBlock() const {
 if (BlockKind == BK_Block)
   return true;
@@ -344,6 +349,10 @@ struct FormatToken {
 
   /// \c true if this token ends a sequence with the given tokens in order,
   /// following the ``Previous`` pointers, ignoring comments.
+  /// For example, given tokens [T1, T2, T3], the function returns true if
+  /// 3 tokens ending at this (ignoring comments) are [T3, T2, T1]. In other
+  /// words, the tokens passed to this function need to the reverse of the
+  /// order the tokens appear in code.
   template 
   bool endsSequence(A K1, Ts... Tokens) const {
 return endsSequenceInternal(K1, Tokens...);

Modified: cfe/trunk/lib/Format/TokenAnnotator.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/TokenAnnotator.cpp?rev=367167&r1=367166&r2=367167&view=diff
==
--- cfe/trunk/lib/Format/TokenAnnotator.cpp (original)
+++ cfe/trunk/lib/Format/TokenAnnotator.cpp Fri Jul 26 19:41:40 2019
@@ -175,9 +175,9 @@ private:
   Contexts.back().IsExpression = false;
 } else if (Left->Previous &&
(Left->Previous->isOneOf(tok::kw_static_assert, 
tok::kw_decltype,
-tok::kw_if, tok::kw_while, 
tok::l_paren,
+tok::kw_while, tok::l_paren,
 tok::comma) ||
-Left->Previous->endsSequence(tok::kw_constexpr, tok::kw_if) ||
+Left->Previous->isIf() ||
 Left->Previous->is(TT_BinaryOperator))) {
   // static_assert, if and while usually contain expressions.
   Contexts.back().IsExpression = true;
@@ -825,8 +825,9 @@ private:
   break;
 case tok::kw_if:
 case tok::kw_while:
+  assert(!Line.startsWith(tok::hash));
   if (Tok->is(tok::kw_if) && CurrentToken &&
-  CurrentToken->is(tok::kw_constexpr))
+  CurrentToken->isOneOf(tok::kw_constexpr, tok::identifier))
 next();
   if (CurrentToken && CurrentToken->is(tok::l_paren)) {
 next();
@@ -1078,6 +1079,7 @@ private:
 case tok::pp_if:
 case tok::pp_elif:
 

[PATCH] D64301: Use `ln -n` to prevent forming a symlink cycle, instead of rm'ing the source

[Hubert Tong via Phabricator via cfe-commits]

hubert.reinterpretcast added a comment.

In D64301#1603499 , @thakis wrote:

> Which platforms doesn't it work on?


`ln -n` means something different on AIX: 
https://www.ibm.com/support/knowledgecenter/en/ssw_aix_72/l_commands/ln.html
`-n` is not documented as a standard option for the `ln` utility by 
POSIX.1-2017: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/ln.html


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64301/new/

https://reviews.llvm.org/D64301



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

[PATCH] D64301: Use `ln -n` to prevent forming a symlink cycle, instead of rm'ing the source

[Nico Weber via Phabricator via cfe-commits]

thakis added a comment.

In D64301#1602660 , 
@hubert.reinterpretcast wrote:

> `ln -n` is not a standard option that is portably supported. I'll be 
> restoring the use of `rm` (with `-f` instead of `-rf`) and the associated 
> comment for removing `%t.fake`.


Which platforms doesn't it work on?


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64301/new/

https://reviews.llvm.org/D64301



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

[PATCH] D65000: [ARM] Set default alignment to 64bits

[Petr Hosek via Phabricator via cfe-commits]

phosek added a comment.

Reverted in rL367166 .


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65000/new/

https://reviews.llvm.org/D65000



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

r367166 - Revert "[ARM] Set default alignment to 64bits"

[Petr Hosek via cfe-commits]

Author: phosek
Date: Fri Jul 26 18:59:23 2019
New Revision: 367166

URL: http://llvm.org/viewvc/llvm-project?rev=367166&view=rev
Log:
Revert "[ARM] Set default alignment to 64bits"

This reverts commit r367119.

This broke several bots:

http://lab.llvm.org:8011/builders/clang-atom-d525-fedora-rel/builds/26891/steps/ninja%20check%201/logs/FAIL%3A%20Clang%3A%3Aexception-alignment.cpp
http://green.lab.llvm.org/green/job/clang-stage1-cmake-RA-incremental/245/consoleFull

Removed:
cfe/trunk/test/CodeGen/ARM/
Modified:
cfe/trunk/lib/Basic/Targets/ARM.cpp
cfe/trunk/test/SemaCXX/warn-overaligned-type-thrown.cpp

Modified: cfe/trunk/lib/Basic/Targets/ARM.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets/ARM.cpp?rev=367166&r1=367165&r2=367166&view=diff
==
--- cfe/trunk/lib/Basic/Targets/ARM.cpp (original)
+++ cfe/trunk/lib/Basic/Targets/ARM.cpp Fri Jul 26 18:59:23 2019
@@ -309,9 +309,8 @@ ARMTargetInfo::ARMTargetInfo(const llvm:
   setAtomic();
 
   // Maximum alignment for ARM NEON data types should be 64-bits (AAPCS)
-  // as well the default alignment
   if (IsAAPCS && (Triple.getEnvironment() != llvm::Triple::Android))
-DefaultAlignForAttributeAligned = MaxVectorAlign = 64;
+MaxVectorAlign = 64;
 
   // Do force alignment of members that follow zero length bitfields.  If
   // the alignment of the zero-length bitfield is greater than the member

Modified: cfe/trunk/test/SemaCXX/warn-overaligned-type-thrown.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/warn-overaligned-type-thrown.cpp?rev=367166&r1=367165&r2=367166&view=diff
==
--- cfe/trunk/test/SemaCXX/warn-overaligned-type-thrown.cpp (original)
+++ cfe/trunk/test/SemaCXX/warn-overaligned-type-thrown.cpp Fri Jul 26 18:59:23 
2019
@@ -2,12 +2,11 @@
 // RUN: %clang_cc1 -triple arm64-apple-ios10 -verify -fsyntax-only -std=c++11 
-fcxx-exceptions -fexceptions -DUNDERALIGNED %s
 // RUN: %clang_cc1 -triple arm64-apple-tvos10 -verify -fsyntax-only -std=c++11 
-fcxx-exceptions -fexceptions -DUNDERALIGNED %s
 // RUN: %clang_cc1 -triple arm64-apple-watchos4 -verify -fsyntax-only 
-std=c++11 -fcxx-exceptions -fexceptions -DUNDERALIGNED %s
-// RUN: %clang_cc1 -triple arm-linux-gnueabi -verify -fsyntax-only -std=c++11 
-fcxx-exceptions -fexceptions  -DUNDERALIGNED %s
 // RUN: %clang_cc1 -triple x86_64-apple-macosx10.14 -verify -fsyntax-only 
-std=c++11 -fcxx-exceptions -fexceptions %s
 // RUN: %clang_cc1 -triple arm64-apple-ios12 -verify -fsyntax-only -std=c++11 
-fcxx-exceptions -fexceptions %s
 // RUN: %clang_cc1 -triple arm64-apple-tvos12 -verify -fsyntax-only -std=c++11 
-fcxx-exceptions -fexceptions %s
 // RUN: %clang_cc1 -triple arm64-apple-watchos5 -verify -fsyntax-only 
-std=c++11 -fcxx-exceptions -fexceptions %s
-// RUN: %clang_cc1 -triple arm-linux-androideabi -verify -fsyntax-only 
-std=c++11 -fcxx-exceptions -fexceptions %s
+// RUN: %clang_cc1 -triple arm-linux-gnueabi -verify -fsyntax-only -std=c++11 
-fcxx-exceptions -fexceptions %s
 // RUN: %clang_cc1 -triple aarch64-linux-gnueabi -verify -fsyntax-only 
-std=c++11 -fcxx-exceptions -fexceptions %s
 // RUN: %clang_cc1 -triple mipsel-linux-gnu -verify -fsyntax-only -std=c++11 
-fcxx-exceptions -fexceptions %s
 // RUN: %clang_cc1 -triple mips64el-linux-gnu -verify -fsyntax-only -std=c++11 
-fcxx-exceptions -fexceptions %s


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

[PATCH] D65361: [analyzer] Trust global initializers when analyzing main().

[Artem Dergachev via Phabricator via cfe-commits]

NoQ updated this revision to Diff 212035.
NoQ added a comment.

Actually add the logic for C++.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65361/new/

https://reviews.llvm.org/D65361

Files:
  clang/lib/StaticAnalyzer/Core/RegionStore.cpp
  clang/test/Analysis/main.c
  clang/test/Analysis/main.cpp

Index: clang/test/Analysis/main.cpp
===
--- /dev/null
+++ clang/test/Analysis/main.cpp
@@ -0,0 +1,22 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,debug.ExprInspection -verify %s
+
+int x = 1;
+
+struct {
+  int a, b;
+} s = {2, 3};
+
+int arr[] = {4, 5, 6};
+
+void clang_analyzer_eval(int);
+
+int main() {
+  // Do not trust global initializers in C++.
+  clang_analyzer_eval(x == 1); // expected-warning{{TRUE}} // expected-warning{{FALSE}}
+  clang_analyzer_eval(s.a == 2); // expected-warning{{TRUE}} // expected-warning{{FALSE}}
+  clang_analyzer_eval(s.b == 3); // expected-warning{{TRUE}} // expected-warning{{FALSE}}
+  clang_analyzer_eval(arr[0] == 4); // expected-warning{{TRUE}} // expected-warning{{FALSE}}
+  clang_analyzer_eval(arr[1] == 5); // expected-warning{{TRUE}} // expected-warning{{FALSE}}
+  clang_analyzer_eval(arr[2] == 6); // expected-warning{{TRUE}} // expected-warning{{FALSE}}
+  return 0;
+}
Index: clang/test/Analysis/main.c
===
--- /dev/null
+++ clang/test/Analysis/main.c
@@ -0,0 +1,21 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,debug.ExprInspection -verify %s
+
+int x = 1;
+
+struct {
+  int a, b;
+} s = {2, 3};
+
+int arr[] = {4, 5, 6};
+
+void clang_analyzer_eval(int);
+
+int main() {
+  clang_analyzer_eval(x == 1); // expected-warning{{TRUE}}
+  clang_analyzer_eval(s.a == 2); // expected-warning{{TRUE}}
+  clang_analyzer_eval(s.b == 3); // expected-warning{{TRUE}}
+  clang_analyzer_eval(arr[0] == 4); // expected-warning{{TRUE}}
+  clang_analyzer_eval(arr[1] == 5); // expected-warning{{TRUE}}
+  clang_analyzer_eval(arr[2] == 6); // expected-warning{{TRUE}}
+  return 0;
+}
Index: clang/lib/StaticAnalyzer/Core/RegionStore.cpp
===
--- clang/lib/StaticAnalyzer/Core/RegionStore.cpp
+++ clang/lib/StaticAnalyzer/Core/RegionStore.cpp
@@ -154,6 +154,7 @@
 class RegionBindingsRef : public llvm::ImmutableMapRef {
   ClusterBindings::Factory *CBFactory;
+  bool IsMainAnalysis;
 
 public:
   typedef llvm::ImmutableMapRef
@@ -161,22 +162,25 @@
 
   RegionBindingsRef(ClusterBindings::Factory &CBFactory,
 const RegionBindings::TreeTy *T,
-RegionBindings::TreeTy::Factory *F)
+RegionBindings::TreeTy::Factory *F,
+bool IsMainAnalysis)
   : llvm::ImmutableMapRef(T, F),
-CBFactory(&CBFactory) {}
+CBFactory(&CBFactory), IsMainAnalysis(IsMainAnalysis) {}
 
-  RegionBindingsRef(const ParentTy &P, ClusterBindings::Factory &CBFactory)
+  RegionBindingsRef(const ParentTy &P,
+ClusterBindings::Factory &CBFactory,
+bool IsMainAnalysis)
   : llvm::ImmutableMapRef(P),
-CBFactory(&CBFactory) {}
+CBFactory(&CBFactory), IsMainAnalysis(IsMainAnalysis) {}
 
   RegionBindingsRef add(key_type_ref K, data_type_ref D) const {
 return RegionBindingsRef(static_cast(this)->add(K, D),
- *CBFactory);
+ *CBFactory, IsMainAnalysis);
   }
 
   RegionBindingsRef remove(key_type_ref K) const {
 return RegionBindingsRef(static_cast(this)->remove(K),
- *CBFactory);
+ *CBFactory, IsMainAnalysis);
   }
 
   RegionBindingsRef addBinding(BindingKey K, SVal V) const;
@@ -206,7 +210,14 @@
 
   /// Return the internal tree as a Store.
   Store asStore() const {
-return asImmutableMap().getRootWithoutRetain();
+static_assert(alignof(decltype(*asImmutableMap().getRootWithoutRetain())) > 1,
+  "No room for the flag!");
+return (Store)((uintptr_t)(asImmutableMap().getRootWithoutRetain()) |
+   (uintptr_t)(IsMainAnalysis));
+  }
+
+  bool isMainAnalysis() const {
+return IsMainAnalysis;
   }
 
   void printJson(raw_ostream &Out, const char *NL = "\n",
@@ -382,7 +393,12 @@
   SVal ArrayToPointer(Loc Array, QualType ElementTy) override;
 
   StoreRef getInitialStore(const LocationContext *InitLoc) override {
-return StoreRef(RBFactory.getEmptyMap().getRootWithoutRetain(), *this);
+bool IsMainAnalysis = false;
+if (const auto *FD = dyn_cast(InitLoc->getDecl()))
+  IsMainAnalysis = FD->isMain() && !Ctx.getLangOpts().CPlusPlus;
+return StoreRef(RegionBindingsRef(
+RegionBindingsRef::ParentTy(RBFactory.getEmptyMap(), RBFactory),
+CBFactory, IsMainAnalysis).asStore(), *this);
   }
 
   //===---===//
@@ -608,9 +624,10 @@

[PATCH] D65361: [analyzer] Trust global initializers when analyzing main().

[Artem Dergachev via Phabricator via cfe-commits]

NoQ marked an inline comment as done.
NoQ added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/RegionStore.cpp:157
   ClusterBindings::Factory *CBFactory;
+  bool IsMainAnalysis;
 

We could have put this flag into `RegionStoreManager` instead - after all, it 
doesn't change for the whole duration of the analysis. It would have made it 
easier to handle (avoid weird bitwise logic) and probably cheaper, but it'll 
make the manager needlessly stateful (which wouldn't really hurt at all right 
now, just looks ugly).


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65361/new/

https://reviews.llvm.org/D65361



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

[PATCH] D65361: [analyzer] Trust global initializers when analyzing main().

[Artem Dergachev via Phabricator via cfe-commits]

NoQ created this revision.
NoQ added reviewers: dcoughlin, xazax.hun, a_sidorin, rnkovacs, Szelethus, 
baloghadamsoftware, Charusso.
Herald added subscribers: cfe-commits, dkrupp, donat.nagy, mikhail.ramalho, 
a.sidorin, JDevlieghere, szepet.
Herald added a project: clang.

This is inspired by https://bugs.llvm.org/show_bug.cgi?id=42780, even though it 
doesn't fix the bug.

If the global variable has an initializer, we'll ignore it because we're 
normally not analyzing the program from the beginning. This means that a global 
variable may have changed before we start our analysis.

However when we're analyzing main() as the top-level function, we can rely on 
global initializers to still be valid. At least in C; in C++ we have global 
constructors for breaking this logic. In C we can also have global constructors 
as a GNU extension, but i'd rather not worry about that.

In this patch i don't try to evaluate global initializers; the patch only 
covers the case when they're constants. This is the reason why we don't cover 
https://bugs.llvm.org/show_bug.cgi?id=42780, however we could cover it if 
`SValBuilder.getConstantVal()` was a bit more feature-rich (namely, we need to 
be able to constant-evaluate expressions like `&var.field` where `var` is a 
global variable; it's a concrete region (i.e., without symbolic base) value in 
our model, so we can make `getConstantVal()` powerful enough to emit it).

For initializers of fields and elements i'm piggybacking on @r.stahl's work to 
cover global constant initializers (D45774 ).

The main benefit of this patch is to make it harder for people to send us false 
positive reproducers that don't actually reproduce the false positive that 
they're having :)


Repository:
  rC Clang

https://reviews.llvm.org/D65361

Files:
  clang/lib/StaticAnalyzer/Core/RegionStore.cpp
  clang/test/Analysis/main.c

Index: clang/test/Analysis/main.c
===
--- /dev/null
+++ clang/test/Analysis/main.c
@@ -0,0 +1,22 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,debug.ExprInspection \
+// RUN:-verify %s
+
+int x = 1;
+
+struct {
+  int a, b;
+} s = {2, 3};
+
+int arr[] = {4, 5, 6};
+
+void clang_analyzer_eval(int);
+
+int main() {
+  clang_analyzer_eval(x == 1); // expected-warning{{TRUE}}
+  clang_analyzer_eval(s.a == 2); // expected-warning{{TRUE}}
+  clang_analyzer_eval(s.b == 3); // expected-warning{{TRUE}}
+  clang_analyzer_eval(arr[0] == 4); // expected-warning{{TRUE}}
+  clang_analyzer_eval(arr[1] == 5); // expected-warning{{TRUE}}
+  clang_analyzer_eval(arr[2] == 6); // expected-warning{{TRUE}}
+  return 0;
+}
Index: clang/lib/StaticAnalyzer/Core/RegionStore.cpp
===
--- clang/lib/StaticAnalyzer/Core/RegionStore.cpp
+++ clang/lib/StaticAnalyzer/Core/RegionStore.cpp
@@ -154,6 +154,7 @@
 class RegionBindingsRef : public llvm::ImmutableMapRef {
   ClusterBindings::Factory *CBFactory;
+  bool IsMainAnalysis;
 
 public:
   typedef llvm::ImmutableMapRef
@@ -161,22 +162,25 @@
 
   RegionBindingsRef(ClusterBindings::Factory &CBFactory,
 const RegionBindings::TreeTy *T,
-RegionBindings::TreeTy::Factory *F)
+RegionBindings::TreeTy::Factory *F,
+bool IsMainAnalysis)
   : llvm::ImmutableMapRef(T, F),
-CBFactory(&CBFactory) {}
+CBFactory(&CBFactory), IsMainAnalysis(IsMainAnalysis) {}
 
-  RegionBindingsRef(const ParentTy &P, ClusterBindings::Factory &CBFactory)
+  RegionBindingsRef(const ParentTy &P,
+ClusterBindings::Factory &CBFactory,
+bool IsMainAnalysis)
   : llvm::ImmutableMapRef(P),
-CBFactory(&CBFactory) {}
+CBFactory(&CBFactory), IsMainAnalysis(IsMainAnalysis) {}
 
   RegionBindingsRef add(key_type_ref K, data_type_ref D) const {
 return RegionBindingsRef(static_cast(this)->add(K, D),
- *CBFactory);
+ *CBFactory, IsMainAnalysis);
   }
 
   RegionBindingsRef remove(key_type_ref K) const {
 return RegionBindingsRef(static_cast(this)->remove(K),
- *CBFactory);
+ *CBFactory, IsMainAnalysis);
   }
 
   RegionBindingsRef addBinding(BindingKey K, SVal V) const;
@@ -206,7 +210,14 @@
 
   /// Return the internal tree as a Store.
   Store asStore() const {
-return asImmutableMap().getRootWithoutRetain();
+static_assert(alignof(decltype(*asImmutableMap().getRootWithoutRetain())) > 1,
+  "No room for the flag!");
+return (Store)((uintptr_t)(asImmutableMap().getRootWithoutRetain()) |
+   (uintptr_t)(IsMainAnalysis));
+  }
+
+  bool isMainAnalysis() const {
+return IsMainAnalysis;
   }
 
   void printJson(raw_ostream &Out, const char *NL = "\n",
@@ -382,7 +393,12 @@
   SVal ArrayToPointer(Loc

r367165 - driver: Don't warn about assembler flags being unused when not assembling; different approach

[Nico Weber via cfe-commits]

Author: nico
Date: Fri Jul 26 18:13:00 2019
New Revision: 367165

URL: http://llvm.org/viewvc/llvm-project?rev=367165&view=rev
Log:
driver: Don't warn about assembler flags being unused when not assembling; 
different approach

This morally relands r365703 (and r365714), originally reviewed at
https://reviews.llvm.org/D64527, but with a different implementation.

Relanding the same approach with a fix for the revert reason got a bit
involved (see https://reviews.llvm.org/D65108) so use a simpler approach
with a more localized implementation (that in return duplicates code
a bit more).

This approach also doesn't validate flags for the integrated assembler
if the assembler step doesn't run.

Fixes PR42066.

Differential Revision: https://reviews.llvm.org/D65233

Modified:
cfe/trunk/lib/Driver/ToolChains/Clang.cpp
cfe/trunk/test/Driver/as-options.s

Modified: cfe/trunk/lib/Driver/ToolChains/Clang.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Clang.cpp?rev=367165&r1=367164&r2=367165&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Clang.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Clang.cpp Fri Jul 26 18:13:00 2019
@@ -2079,6 +2079,9 @@ static void CollectArgsForIntegratedAsse
 break;
   }
 
+  // If you add more args here, also add them to the block below that
+  // starts with "// If CollectArgsForIntegratedAssembler() isn't called 
below".
+
   // When passing -I arguments to the assembler we sometimes need to
   // unconditionally take the next argument.  For example, when parsing
   // '-Wa,-I -Wa,foo' we need to accept the -Wa,foo arg after seeing the
@@ -3543,6 +3546,35 @@ void Clang::ConstructJob(Compilation &C,
   // Select the appropriate action.
   RewriteKind rewriteKind = RK_None;
 
+  // If CollectArgsForIntegratedAssembler() isn't called below, claim the args
+  // it claims when not running an assembler. Otherwise, clang would emit
+  // "argument unused" warnings for assembler flags when e.g. adding "-E" to
+  // flags while debugging something. That'd be somewhat inconvenient, and it's
+  // also inconsistent with most other flags -- we don't warn on
+  // -ffunction-sections not being used in -E mode either for example, even
+  // though it's not really used either.
+  if (!isa(JA)) {
+// The args claimed here should match the args used in
+// CollectArgsForIntegratedAssembler().
+if (TC.useIntegratedAs()) {
+  Args.ClaimAllArgs(options::OPT_mrelax_all);
+  Args.ClaimAllArgs(options::OPT_mno_relax_all);
+  Args.ClaimAllArgs(options::OPT_mincremental_linker_compatible);
+  Args.ClaimAllArgs(options::OPT_mno_incremental_linker_compatible);
+  switch (C.getDefaultToolChain().getArch()) {
+  case llvm::Triple::arm:
+  case llvm::Triple::armeb:
+  case llvm::Triple::thumb:
+  case llvm::Triple::thumbeb:
+Args.ClaimAllArgs(options::OPT_mimplicit_it_EQ);
+  default:
+break;
+  }
+}
+Args.ClaimAllArgs(options::OPT_Wa_COMMA);
+Args.ClaimAllArgs(options::OPT_Xassembler);
+  }
+
   if (isa(JA)) {
 assert(JA.getType() == types::TY_Plist && "Invalid output type.");
 CmdArgs.push_back("-analyze");

Modified: cfe/trunk/test/Driver/as-options.s
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/as-options.s?rev=367165&r1=367164&r2=367165&view=diff
==
--- cfe/trunk/test/Driver/as-options.s (original)
+++ cfe/trunk/test/Driver/as-options.s Fri Jul 26 18:13:00 2019
@@ -35,3 +35,51 @@
 // RUN:   | FileCheck %s
 
 // CHECK: "-I" "foo_dir"
+
+// Test that assembler options don't cause warnings when there's no assembler
+// stage.
+
+// RUN: %clang -mincremental-linker-compatible -E \
+// RUN:   -o /dev/null -x c++ %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=NOWARN --allow-empty %s
+// RUN: %clang -mincremental-linker-compatible -E \
+// RUN:   -o /dev/null -x assembler-with-cpp %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=NOWARN --allow-empty %s
+// RUN: %clang -mimplicit-it=always -target armv7-linux-gnueabi -E \
+// RUN:   -o /dev/null -x c++ %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=NOWARN --allow-empty %s
+// RUN: %clang -mimplicit-it=always -target armv7-linux-gnueabi -E \
+// RUN:   -o /dev/null -x assembler-with-cpp %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=NOWARN --allow-empty %s
+// RUN: %clang -Wa,-mbig-obj -target i386-pc-windows -E \
+// RUN:   -o /dev/null -x c++ %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=NOWARN --allow-empty %s
+// RUN: %clang -Wa,-mbig-obj -target i386-pc-windows -E \
+// RUN:   -o /dev/null -x assembler-with-cpp %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=NOWARN --allow-empty %s
+// RUN: %clang -Xassembler -mbig-obj -target i386-pc-windows -E \
+// RUN:   -o /dev/null -x c++ %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=NOWARN --allow-empty %s
+// R

[PATCH] D65108: Reland "driver: Don't warn about assembler flags being unused when not assembling"

[Nico Weber via Phabricator via cfe-commits]

thakis abandoned this revision.
thakis added a comment.

We're going with D65233  instead.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65108/new/

https://reviews.llvm.org/D65108



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

[PATCH] D65249: [NFC] use C++11 in AlignOf.h

[Billy Robert O'Neal III via Phabricator via cfe-commits]

BillyONeal added a comment.

(In fact I observe many patterns in this review like:

enum { Foo = alignof(void*); }
aligned_storage_t<1234, Foo> x;

and then a bunch of casting to treat it as a char buffer; if it was just born 
as a char buffer you can remove both the casts and the enum hack:

alignas(void*) char x[1234];


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65249/new/

https://reviews.llvm.org/D65249



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

[PATCH] D65249: [NFC] use C++11 in AlignOf.h

[Billy Robert O'Neal III via Phabricator via cfe-commits]

BillyONeal added a comment.

In D65249#1603335 , @jfb wrote:

> @rnk: how about I add a bit of code that wraps `aligned_storage` on all 
> platforms except MSVC (where I'd implement it as Billy suggests). That would 
> mean updating all the uses of `aligned_storage` to this LLVM one, but that's 
> not a big deal.


Why not just always use the alignas version? Or even better, not involve a 
library for something you can say in the core language at all?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65249/new/

https://reviews.llvm.org/D65249



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

[PATCH] D64671: [clang-tidy] New check: misc-init-local-variables

[Alexander Kornienko via Phabricator via cfe-commits]

alexfh added a comment.

A general comment: "misc" is a sort of a heap of checks that otherwise don't 
have a good home. This one would probably better go to bugprone (or maybe 
there's a relevant CERT or C++ Core Guidelines rule?).


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64671/new/

https://reviews.llvm.org/D64671



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

[PATCH] D65065: [clang-tidy] Possibility of displaying duplicate warnings

[Alexander Kornienko via Phabricator via cfe-commits]

alexfh added a comment.

I think it will be a strict improvement to include the check name into the 
deduplication key (probably after the file and offset and before the message). 
I don't see any reason to hide this behind a flag or otherwise retain the old 
behavior. As for expanding the key to include notes and fixes - it's probably 
good to do this either, and this may help uncover incorrect behavior of some 
checks. I'd suggest to start with the check name though.


Repository:
  rCTE Clang Tools Extra

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65065/new/

https://reviews.llvm.org/D65065



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

[PATCH] D60943: Delay diagnosing asm constraints that require immediates until after inlining

[Bill Wendling via Phabricator via cfe-commits]

void added a comment.

That was intentional. We want to do this for more than just the `n` constraint.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D60943/new/

https://reviews.llvm.org/D60943



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

[PATCH] D64146: [ConstExprPreter][WIP] Initial patch for the constexpr interpreter

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added a comment.

How do you intend to represent pointers cast to integer types? Allocating 64 
bits of state for a 64-bit integer is insufficient to model that case.




Comment at: clang/include/clang/AST/ASTContext.h:583-584
 
+  /// Returns the constexpr VM context.
+  vm::Context &getConstexprCtx();
+

You have too many names for the same thing (`vm`, `ExprVM`, ConstExprPreter, 
and `ConstexprCtx` here -- and `ExprVM` is a bad choice of name since a lot of 
the purpose is to evaluate statements rather than expressions). Please pick a 
single name and apply it consistently.

Suggestion: use namespace `clang::interp`, in `{include/clang,lib}/AST/Interp`, 
and generally refer to this implementation as "the Clang interpreter". This 
function should be called `getInterpContext` or similar. (If you prefer, use VM 
intead of Interp, but I'd be concerned about confusion with LLVM.)



Comment at: clang/include/clang/Basic/DiagnosticASTKinds.td:231-234
+def err_constexpr_compilation_failed : Error<
+  "constexpr cannot be compiled by the experimental interpreter">;
+def err_constexpr_interp_failed : Error<
+  "constexpr cannot be evaluated by the experimental interpreter">;

`constexpr` is an adjective; this sentence doesn't parse. Do you mean "this 
constexpr function" or something like that?



Comment at: clang/include/clang/Driver/Options.td:838-839
+  HelpText<"Enable the experimental constexpr interpreter">, 
Flags<[CC1Option]>;
+def fexperimental_constexpr_force_interpreter : Flag<["-"], 
"fexperimental-constexpr-force-interpreter">, Group,
+  HelpText<"Force the use of the experimental constexpr interpreter, failing 
on missing features">, Flags<[CC1Option]>;
 def fconstexpr_backtrace_limit_EQ : Joined<["-"], 
"fconstexpr-backtrace-limit=">,

If the name we're presenting to users is "the experimental constexpr 
interpreter", then "force" shouldn't appear part way through that name. 
`-fforce-experimental-constexpr-interpreter` maybe?



Comment at: clang/lib/AST/CMakeLists.txt:85
   LINK_LIBS
+  clangExpr
   clangBasic

What is the `clangExpr` library? Should this say `clangExprVM` (modulo 
renaming)?



Comment at: clang/lib/AST/ExprConstant.cpp:691-696
+/// Force the use of the constexpr interpreter, bailing out with an error
+/// if a feature is unsupported.
+bool ForceInterp;
+
+/// Enable the constexpr interpreter.
+bool EnableInterp;

These comments don't make sense: `ExprConstant.cpp` is a constexpr interpreter 
too. Maybe "the new interpreter"?



Comment at: clang/lib/AST/ExprVM/CMakeLists.txt:4
+
+add_clang_library(clangExpr
+  Compiler.cpp

This is not a reasonable name for this library.



Comment at: clang/lib/AST/ExprVM/Compiler.cpp:79-82
+  for (auto *ParamDecl : F->parameters()) {
+if (auto T = Ctx.classify(ParamDecl->getType())) {
+  auto Size = primSize(*T);
+  auto Desc = llvm::make_unique(ParamDecl, Size, Size, *T,

You are overusing `auto` here. The types of at least `T` and `Size` are 
non-obvious, and should be written explicitly.



Comment at: clang/lib/AST/ExprVM/Compiler.cpp:88
+  Params.insert({ParamDecl, ParamOffset});
+  ParamOffset += align(Size);
+  Args.push_back(*T);

What happens if this overflows (due to many large local variables)?



Comment at: clang/lib/AST/ExprVM/Compiler.cpp:99
+Start = P.getOffset();
+if (auto E = compile(F->getBody()))
+  return std::move(E);

Don't use `auto` here. The code would be much clearer if you explicitly write 
`llvm::Error`.

(I'm not going to call out further overuse of `auto`; generally [the rule we 
want to 
follow](http://llvm.org/docs/CodingStandards.html#use-auto-type-deduction-to-make-code-more-readable)
 is "Use auto if and only if it makes the code more readable or easier to 
maintain.", which many of the uses of `auto` here do not.)



Comment at: clang/lib/AST/ExprVM/Compiler.cpp:144
+  } else {
+return discard(static_cast(S));
+  }

Use `E` here rather than casting `S` again.



Comment at: clang/lib/AST/ExprVM/Compiler.cpp:168-169
+  if (!VD->hasLocalStorage()) {
+// TODO: implement non-local variables.
+return bail(DS);
+  }

Non-local variables should not require any code generation, since they can't 
have dynamic initialization or destruction. (You can just return 
`Error::success()`.)



Comment at: clang/lib/AST/ExprVM/Compiler.cpp:321-339
+if (auto T = Ctx.classify(CE->getType())) {
+  if (auto *DE = dyn_cast(SubExpr)) {
+bool IsReference = DE->getDecl()->getType()->isReferenceType();
+if (!IsReference) {
+  if (auto *P

[PATCH] D65359: [Sema] Map from a variable template specialization in a pattern to a variable template specialization in an instantiation properly

[Erik Pilkington via Phabricator via cfe-commits]

erik.pilkington created this revision.
erik.pilkington added a reviewer: rsmith.
Herald added subscribers: dexonsmith, jkorous.

Previously, when instantiating `S::mf` below, we would emit a reference to 
the declaration of S::v, when we really ought to make a new 
declaration for `v` in the template instantiation. This caused a variety of 
problems, since the variable template specialization that we were using was in 
a dependent context. The fix is to teach FindInstantiatedDecl to map the 
variable instantiation from the pattern to the instantiation.

Fixes llvm.org/PR42779.

  template 
  struct S {
template 
static constexpr int v = 0;
  
void mf() { v; }
  };
  
  S x;

Thanks for taking a look!
Erik


https://reviews.llvm.org/D65359

Files:
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/SemaExprMember.cpp
  clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
  clang/test/SemaCXX/cxx1y-variable-templates_in_class.cpp

Index: clang/test/SemaCXX/cxx1y-variable-templates_in_class.cpp
===
--- clang/test/SemaCXX/cxx1y-variable-templates_in_class.cpp
+++ clang/test/SemaCXX/cxx1y-variable-templates_in_class.cpp
@@ -426,3 +426,32 @@
 }
 }
 #endif
+
+#ifndef PRECXX11
+namespace template_vars_in_template {
+template  struct TakesInt {};
+
+template 
+struct S {
+  template 
+  static constexpr int v = 42;
+
+  template 
+  void mf() {
+constexpr int val = v;
+  }
+
+  void mf2() {
+constexpr int val = v;
+TakesInt ti;
+(void)ti.x; // expected-error{{no member named 'x' in 'template_vars_in_template::TakesInt<42>'}}
+  }
+};
+
+void useit() {
+  S x;
+  x.mf();
+  x.mf2(); // expected-note{{in instantiation of member function 'template_vars_in_template::S::mf2' requested here}}
+}
+}
+#endif
Index: clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
===
--- clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
+++ clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
@@ -5217,11 +5217,11 @@
 /// template struct X;
 /// \endcode
 ///
-/// In the instantiation of X::getKind(), we need to map the
-/// \p EnumConstantDecl for \p KnownValue (which refers to
-/// XKnownValue) to its instantiation
-/// (XKnownValue). \p FindInstantiatedDecl performs
-/// this mapping from within the instantiation of X.
+/// In the instantiation of X::getKind(), we need to map the \p
+/// EnumConstantDecl for \p KnownValue (which refers to
+/// XKnownValue) to its instantiation (XKnownValue).
+/// \p FindInstantiatedDecl performs this mapping from within the instantiation
+/// of X.
 NamedDecl *Sema::FindInstantiatedDecl(SourceLocation Loc, NamedDecl *D,
   const MultiLevelTemplateArgumentList &TemplateArgs,
   bool FindingInstantiatedContext) {
@@ -5312,20 +5312,6 @@
 return cast(Inst);
   }
 
-  // For variable template specializations, update those that are still
-  // type-dependent.
-  if (VarTemplateSpecializationDecl *VarSpec =
-  dyn_cast(D)) {
-bool InstantiationDependent = false;
-const TemplateArgumentListInfo &VarTemplateArgs =
-VarSpec->getTemplateArgsInfo();
-if (TemplateSpecializationType::anyDependentTemplateArguments(
-VarTemplateArgs, InstantiationDependent))
-  D = cast(
-  SubstDecl(D, VarSpec->getDeclContext(), TemplateArgs));
-return D;
-  }
-
   if (CXXRecordDecl *Record = dyn_cast(D)) {
 if (!Record->isDependentContext())
   return D;
@@ -5450,11 +5436,23 @@
 // find it. Does that ever matter?
 if (auto Name = D->getDeclName()) {
   DeclarationNameInfo NameInfo(Name, D->getLocation());
-  Name = SubstDeclarationNameInfo(NameInfo, TemplateArgs).getName();
+  DeclarationNameInfo NewNameInfo =
+  SubstDeclarationNameInfo(NameInfo, TemplateArgs);
+  Name = NewNameInfo.getName();
   if (!Name)
 return nullptr;
   DeclContext::lookup_result Found = ParentDC->lookup(Name);
-  Result = findInstantiationOf(Context, D, Found.begin(), Found.end());
+
+  if (auto *VTSD = dyn_cast(D)) {
+VarTemplateDecl *Templ = cast_or_null(
+findInstantiationOf(Context, VTSD->getSpecializedTemplate(),
+Found.begin(), Found.end()));
+if (!Templ)
+  return nullptr;
+Result = getVarTemplateSpecialization(
+Templ, &VTSD->getTemplateArgsInfo(), NewNameInfo, SourceLocation());
+  } else
+Result = findInstantiationOf(Context, D, Found.begin(), Found.end());
 } else {
   // Since we don't have a name for the entity we're looking for,
   // our only option is to walk through all of the declarations to
Index: clang/lib/Sema/SemaExprMember.cpp
===
--- clang/lib/Sema/SemaExprMember.cpp
+++ clang/lib/Sema/SemaExprMember.cpp
@@ -934,18 +934,18 @@
   return false;

[PATCH] D65000: [ARM] Set default alignment to 64bits

[Petr Hosek via Phabricator via cfe-commits]

phosek added inline comments.



Comment at: cfe/trunk/test/CodeGen/ARM/exception-alignment.cpp:9
+// A16-NEXT: store <2 x i64> , <2 x i64>* [[BC]], align 16
+#include 
+

thegameg wrote:
> thakis wrote:
> > This fails on some bots:
> > 
> > http://lab.llvm.org:8011/builders/clang-atom-d525-fedora-rel/builds/26891/steps/ninja%20check%201/logs/FAIL%3A%20Clang%3A%3Aexception-alignment.cpp
> > 
> > ```
> > In file included from 
> > /export/users/atombot/llvm/clang-atom-d525-fedora-rel/llvm/tools/clang/test/CodeGen/ARM/exception-alignment.cpp:9:
> > In file included from 
> > /export/users/atombot/llvm/clang-atom-d525-fedora-rel/stage1/lib/clang/10.0.0/include/arm_neon.h:31:
> > In file included from 
> > /export/users/atombot/llvm/clang-atom-d525-fedora-rel/stage1/lib/clang/10.0.0/include/stdint.h:52:
> > In file included from /usr/include/stdint.h:26:
> > In file included from /usr/include/bits/libc-header-start.h:33:
> > In file included from /usr/include/features.h:452:
> > /usr/include/gnu/stubs.h:7:11: fatal error: 'gnu/stubs-32.h' file not found
> > # include 
> >   ^~~~
> > 1 error generated.
> > FileCheck error: '-' is empty.
> > FileCheck command line:  
> > /export/users/atombot/llvm/clang-atom-d525-fedora-rel/stage1/bin/FileCheck 
> > --check-prefixes=CHECK,A16 
> > /export/users/atombot/llvm/clang-atom-d525-fedora-rel/llvm/tools/clang/test/CodeGen/ARM/exception-alignment.cpp
> > 
> > --
> > ```
> It also fails on Darwin:
> 
> http://green.lab.llvm.org/green/job/clang-stage1-cmake-RA-incremental/245/consoleFull
> 
> ```
> Command Output (stderr):
> --
> In file included from 
> /Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/llvm-project/clang/test/CodeGen/ARM/exception-alignment.cpp:9:
> In file included from 
> /Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/clang-build/lib/clang/10.0.0/include/arm_neon.h:31:
> In file included from 
> /Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/clang-build/lib/clang/10.0.0/include/stdint.h:52:
> In file included from /usr/include/stdint.h:52:
> In file included from /usr/include/sys/_types.h:32:
> /usr/include/sys/cdefs.h:763:2: error: Unsupported architecture
> #error Unsupported architecture
>  ^
> In file included from 
> /Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/llvm-project/clang/test/CodeGen/ARM/exception-alignment.cpp:9:
> In file included from 
> /Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/clang-build/lib/clang/10.0.0/include/arm_neon.h:31:
> In file included from 
> /Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/clang-build/lib/clang/10.0.0/include/stdint.h:52:
> In file included from /usr/include/stdint.h:52:
> In file included from /usr/include/sys/_types.h:33:
> /usr/include/machine/_types.h:34:2: error: architecture not supported
> #error architecture not supported
>  ^
> ```
We're seeing yet another failure:
```
 TEST 'Clang :: CodeGen/ARM/exception-alignment.cpp' FAILED 

Script:
--
: 'RUN: at line 3';   
/b/s/w/ir/k/recipe_cleanup/clang3ZiJj1/llvm_build_dir/bin/clang 
--target=arm-arm-none-eabi -march=armv8-a -S -emit-llvm -Os -o - 
/b/s/w/ir/k/llvm-project/clang/test/CodeGen/ARM/exception-alignment.cpp | 
/b/s/w/ir/k/recipe_cleanup/clang3ZiJj1/llvm_build_dir/bin/FileCheck 
--check-prefixes=CHECK,A8 
/b/s/w/ir/k/llvm-project/clang/test/CodeGen/ARM/exception-alignment.cpp
: 'RUN: at line 4';   
/b/s/w/ir/k/recipe_cleanup/clang3ZiJj1/llvm_build_dir/bin/clang 
--target=arm-linux-androideabi -march=armv8-a -S -emit-llvm -Os -o - 
/b/s/w/ir/k/llvm-project/clang/test/CodeGen/ARM/exception-alignment.cpp | 
/b/s/w/ir/k/recipe_cleanup/clang3ZiJj1/llvm_build_dir/bin/FileCheck 
--check-prefixes=CHECK,A16 
/b/s/w/ir/k/llvm-project/clang/test/CodeGen/ARM/exception-alignment.cpp
--
Exit Code: 2

Command Output (stderr):
--
In file included from 
/b/s/w/ir/k/llvm-project/clang/test/CodeGen/ARM/exception-alignment.cpp:9:
In file included from 
/b/s/w/ir/k/recipe_cleanup/clang3ZiJj1/llvm_build_dir/lib/clang/10.0.0/include/arm_neon.h:31:
In file included from 
/b/s/w/ir/k/recipe_cleanup/clang3ZiJj1/llvm_build_dir/bin/../include/c++/v1/stdint.h:106:
In file included from 
/b/s/w/ir/k/recipe_cleanup/clang3ZiJj1/llvm_build_dir/bin/../include/c++/v1/__config:254:
/usr/include/features.h:364:12: fatal error: 'sys/cdefs.h' file not found
#  include 
   ^
1 error generated.
FileCheck error: '-' is empty.
FileCheck command line:  
/b/s/w/ir/k/recipe_cleanup/clang3ZiJj1/llvm_build_dir/bin/FileCheck 
--check-prefixes=CHECK,A16 
/b/s/w/ir/k/llvm-project/clang/test/CodeGen/ARM/exception-alignment.cpp

--
```
Can we revert this change?


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65000/new/

https://reviews.llvm.org/D65000



___
cfe-commits mai

[PATCH] D65022: [Sema] Always instantiate the initializer of a variable template with undeduced type (8.0 regression)

[Erik Pilkington via Phabricator via cfe-commits]

erik.pilkington updated this revision to Diff 212026.
erik.pilkington added a comment.

Fix the type of the MemberExpr/DeclRefExpr after instantiating the variable 
initializer.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65022/new/

https://reviews.llvm.org/D65022

Files:
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaExprMember.cpp
  clang/test/SemaCXX/cxx1y-variable-templates_in_class.cpp


Index: clang/test/SemaCXX/cxx1y-variable-templates_in_class.cpp
===
--- clang/test/SemaCXX/cxx1y-variable-templates_in_class.cpp
+++ clang/test/SemaCXX/cxx1y-variable-templates_in_class.cpp
@@ -395,3 +395,34 @@
   }
   int &t = B::template n; // expected-error {{use of variable template 'n' 
requires template arguments}}
 }
+
+#ifndef PRECXX11
+namespace auto_variable_instantiate_initializer {
+template  struct S {
+  template  static constexpr auto v = 1;
+  template  static constexpr auto v2 = T{};
+
+  template >
+  void implicit() {
+double d = v2;
+int i2 = v;
+  }
+
+  void implicit_nondep() {
+int i = v;
+double d = v2;
+  }
+};
+
+void useit() {
+  S x;
+  // We used to fail to instantiate the initializer, leading to an auto type
+  // leaking through here.
+  int i = x.v;
+  float j = x.v2;
+
+  x.implicit();
+  x.implicit_nondep();
+}
+}
+#endif
Index: clang/lib/Sema/SemaExprMember.cpp
===
--- clang/lib/Sema/SemaExprMember.cpp
+++ clang/lib/Sema/SemaExprMember.cpp
@@ -1160,11 +1160,17 @@
   }
   if (VarTemplateDecl *VarTempl = dyn_cast(MemberDecl)) {
 if (VarDecl *Var = getVarTemplateSpecialization(
-*this, VarTempl, TemplateArgs, MemberNameInfo, TemplateKWLoc))
-  return BuildMemberExpr(
+*this, VarTempl, TemplateArgs, MemberNameInfo, TemplateKWLoc)) {
+  MemberExpr *ME = BuildMemberExpr(
   BaseExpr, IsArrow, OpLoc, &SS, TemplateKWLoc, Var, FoundDecl,
   /*HadMultipleCandidates=*/false, MemberNameInfo,
   Var->getType().getNonReferenceType(), VK_LValue, OK_Ordinary);
+
+  // BuildMemberExpr may have deduced an auto variable's type. Patch back
+  // that type to avoid forming an expression with undeduced type.
+  ME->setType(Var->getType().getNonReferenceType());
+  return ME;
+}
 return ExprError();
   }
 
Index: clang/lib/Sema/SemaExpr.cpp
===
--- clang/lib/Sema/SemaExpr.cpp
+++ clang/lib/Sema/SemaExpr.cpp
@@ -3163,9 +3163,15 @@
   break;
 }
 
-return BuildDeclRefExpr(VD, type, valueKind, NameInfo, &SS, FoundD,
-/*FIXME: TemplateKWLoc*/ SourceLocation(),
-TemplateArgs);
+DeclRefExpr *DRE = BuildDeclRefExpr(
+VD, type, valueKind, NameInfo, &SS, FoundD,
+/*FIXME: TemplateKWLoc*/ SourceLocation(), TemplateArgs);
+
+// BuildDeclRefExpr may have deduced an auto variable's type. Patch back
+// that type to avoid forming an expression with undeduced type.
+if (isa(VD))
+  DRE->setType(VD->getType().getNonReferenceType());
+return DRE;
   }
 }
 


Index: clang/test/SemaCXX/cxx1y-variable-templates_in_class.cpp
===
--- clang/test/SemaCXX/cxx1y-variable-templates_in_class.cpp
+++ clang/test/SemaCXX/cxx1y-variable-templates_in_class.cpp
@@ -395,3 +395,34 @@
   }
   int &t = B::template n; // expected-error {{use of variable template 'n' requires template arguments}}
 }
+
+#ifndef PRECXX11
+namespace auto_variable_instantiate_initializer {
+template  struct S {
+  template  static constexpr auto v = 1;
+  template  static constexpr auto v2 = T{};
+
+  template >
+  void implicit() {
+double d = v2;
+int i2 = v;
+  }
+
+  void implicit_nondep() {
+int i = v;
+double d = v2;
+  }
+};
+
+void useit() {
+  S x;
+  // We used to fail to instantiate the initializer, leading to an auto type
+  // leaking through here.
+  int i = x.v;
+  float j = x.v2;
+
+  x.implicit();
+  x.implicit_nondep();
+}
+}
+#endif
Index: clang/lib/Sema/SemaExprMember.cpp
===
--- clang/lib/Sema/SemaExprMember.cpp
+++ clang/lib/Sema/SemaExprMember.cpp
@@ -1160,11 +1160,17 @@
   }
   if (VarTemplateDecl *VarTempl = dyn_cast(MemberDecl)) {
 if (VarDecl *Var = getVarTemplateSpecialization(
-*this, VarTempl, TemplateArgs, MemberNameInfo, TemplateKWLoc))
-  return BuildMemberExpr(
+*this, VarTempl, TemplateArgs, MemberNameInfo, TemplateKWLoc)) {
+  MemberExpr *ME = BuildMemberExpr(
   BaseExpr, IsArrow, OpLoc, &SS, TemplateKWLoc, Var, FoundDecl,
   /*HadMultipleCandidates=*/false, MemberNameInfo,
   Var->getType().getNonReferenceType(), VK_LValue, OK_Ordinary);
+
+  // BuildMemberExpr may have deduced an auto variable's type. Patch back
+  

Buildbot numbers for the week of 07/14/2019 - 07/20/2019

[Galina Kistanova via cfe-commits]

Hello everyone,

Below are some buildbot numbers for the last week of 07/14/2019 -
07/20/2019.

Please see the same data in attached csv files:

The longest time each builder was red during the week;
"Status change ratio" by active builder (percent of builds that changed the
builder status from greed to red or from red to green);
Count of commits by project;
Number of completed builds, failed builds and average build time for
successful builds per active builder;
Average waiting time for a revision to get build result per active builder
(response time).

Thanks

Galina


The longest time each builder was red during the week:
  buildername  |  was_red
---+--
 clang-native-arm-lnt-perf | 147:13:55
 netbsd-amd64  | 94:07:17
 sanitizer-x86_64-linux-bootstrap-ubsan| 61:51:16
 clang-with-thin-lto-ubuntu| 60:17:51
 clang-with-lto-ubuntu | 60:01:17
 sanitizer-x86_64-linux| 58:29:11
 sanitizer-x86_64-linux-bootstrap  | 44:49:30
 sanitizer-x86_64-linux-android| 40:05:40
 clang-ppc64le-linux-lnt   | 39:11:53
 sanitizer-x86_64-linux-bootstrap-msan | 39:06:55
 sanitizer-x86_64-linux-autoconf   | 38:59:30
 sanitizer-x86_64-linux-fast   | 38:31:41
 clang-cmake-aarch64-lld   | 34:01:34
 clang-cmake-armv8-lld | 26:37:11
 ppc64le-lld-multistage-test   | 17:18:00
 clang-lld-x86_64-2stage   | 17:16:04
 polly-amd64-linux | 13:31:58
 reverse-iteration | 13:20:41
 polly-arm-linux   | 12:29:29
 clang-cmake-aarch64-full  | 11:04:17
 sanitizer-x86_64-linux-gn | 10:30:19
 clang-cmake-armv7-selfhost| 09:59:23
 clang-ppc64le-linux   | 09:14:44
 clang-cmake-armv7-full| 08:40:39
 sanitizer-ppc64le-linux   | 08:10:01
 sanitizer-ppc64be-linux   | 07:38:45
 clang-cmake-thumbv7-full-sh   | 07:32:49
 clang-cmake-thumbv8-full-sh   | 07:26:52
 clang-cmake-x86_64-avx2-linux-perf| 06:49:42
 clang-ppc64be-linux-lnt   | 06:08:13
 clang-ppc64be-linux   | 05:45:41
 clang-ppc64be-linux-multistage| 05:28:49
 clang-cmake-armv8-full| 05:28:45
 lld-x86_64-win7   | 05:24:06
 libcxx-libcxxabi-libunwind-aarch64-linux-noexceptions | 05:17:40
 libcxx-libcxxabi-libunwind-aarch64-linux  | 05:17:39
 libcxx-libcxxabi-libunwind-armv8-linux| 05:14:20
 libcxx-libcxxabi-libunwind-armv8-linux-noexceptions   | 05:13:20
 clang-s390x-linux | 04:37:18
 clang-s390x-linux-lnt | 04:36:04
 llvm-clang-x86_64-expensive-checks-win| 04:34:52
 clang-cmake-armv8-selfhost-neon   | 04:09:36
 clang-cmake-aarch64-quick | 03:26:31
 clang-cmake-armv7-quick   | 03:24:01
 libcxx-libcxxabi-x86_64-linux-ubuntu-32bit| 03:19:31
 lldb-x64-windows-ninja| 03:13:41
 clang-cmake-aarch64-global-isel   | 03:10:14
 clang-cmake-armv8-global-isel | 03:06:26
 llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast  | 02:40:09
 clang-cmake-armv8-lnt | 02:33:41
 llvm-clang-x86_64-win-fast| 02:30:12
 clang-x64-windows-msvc| 02:26:39
 clang-cuda-build  | 02:10:55
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03| 02:08:25
 libcxx-libcxxabi-x86_64-linux-ubuntu-msan | 02:04:55
 lld-x86_64-ubuntu-fast| 02:03:56
 libcxx-libcxxabi-libunwind-x86_64-linux-ubuntu| 02:03:55
 libcxx-libcxxabi-x86_64-linux-ubuntu-asan | 02:03:46
 libcxx-libcxxabi-x86_64-linux-ubuntu-tsan | 02:02:39
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx14| 02:02:00
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx17| 02:01:53
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx11| 02:00:41
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx2a| 01:59:16
 libcxx-libcxxabi-libunwind-armv7-linux-noexceptions   | 01:52:12
 clang-c

Buildbot numbers for the week of 07/07/2019 - 07/13/2019

[Galina Kistanova via cfe-commits]

Hello everyone,

Below are some buildbot numbers for the week of 07/07/2019 - 07/13/2019.

Please see the same data in attached csv files:

The longest time each builder was red during the week;
"Status change ratio" by active builder (percent of builds that changed the
builder status from greed to red or from red to green);
Count of commits by project;
Number of completed builds, failed builds and average build time for
successful builds per active builder;
Average waiting time for a revision to get build result per active builder
(response time).

Thanks

Galina


The longest time each builder was red during the week:
  buildername  |  was_red
---+--
 libcxx-libcxxabi-libunwind-x86_64-linux-debian| 103:50:25
 libcxx-libcxxabi-x86_64-linux-debian-noexceptions | 103:50:23
 clang-cmake-aarch64-lld   | 102:12:55
 clang-cmake-aarch64-full  | 95:49:48
 libcxx-libcxxabi-libunwind-aarch64-linux  | 75:06:28
 libcxx-libcxxabi-libunwind-armv8-linux| 75:04:44
 libcxx-libcxxabi-libunwind-aarch64-linux-noexceptions | 75:03:31
 libcxx-libcxxabi-libunwind-armv8-linux-noexceptions   | 75:02:24
 libcxx-libcxxabi-libunwind-armv7-linux| 74:25:30
 libcxx-libcxxabi-libunwind-armv7-linux-noexceptions   | 74:14:44
 polly-amd64-linux | 71:06:12
 libcxx-libcxxabi-x86_64-linux-ubuntu-msan | 57:07:57
 libcxx-libcxxabi-x86_64-linux-ubuntu-ubsan| 57:04:46
 libcxx-libcxxabi-x86_64-linux-ubuntu-tsan | 56:43:43
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx11| 56:41:18
 libcxx-libcxxabi-x86_64-linux-ubuntu-asan | 56:40:12
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03| 56:34:35
 libcxx-libcxxabi-x86_64-linux-ubuntu-32bit| 56:33:19
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx2a| 56:32:51
 libcxx-libcxxabi-libunwind-x86_64-linux-ubuntu| 56:31:14
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx17| 56:31:06
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx14| 56:30:35
 lldb-x64-windows-ninja| 51:12:47
 sanitizer-x86_64-linux-bootstrap-ubsan| 50:33:17
 sanitizer-x86_64-linux-fast   | 49:42:57
 netbsd-amd64  | 33:32:40
 clang-x64-windows-msvc| 31:28:05
 clang-ppc64le-linux-multistage| 29:45:24
 sanitizer-x86_64-linux-bootstrap  | 29:16:31
 clang-cmake-thumbv8-full-sh   | 27:49:18
 sanitizer-ppc64le-linux   | 27:44:27
 clang-ppc64be-linux-lnt   | 27:17:43
 clang-cmake-aarch64-quick | 25:59:09
 clang-cmake-thumbv7-full-sh   | 25:47:03
 sanitizer-x86_64-linux-gn | 25:30:45
 clang-s390x-linux-multistage  | 23:17:27
 clang-lld-x86_64-2stage   | 22:13:14
 sanitizer-windows | 21:44:34
 llvm-clang-x86_64-expensive-checks-win| 20:14:40
 clang-ppc64le-linux   | 20:12:36
 clang-ppc64le-linux-lnt   | 20:01:36
 clang-s390x-linux-lnt | 20:00:17
 llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast  | 19:55:04
 clang-cmake-armv7-full| 19:17:28
 sanitizer-ppc64be-linux   | 18:53:02
 sanitizer-x86_64-linux| 18:34:56
 clang-ppc64be-linux-multistage| 18:31:43
 clang-cmake-armv8-full| 18:18:20
 sanitizer-x86_64-linux-android| 18:13:50
 clang-ppc64be-linux   | 18:10:24
 llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast| 17:57:52
 sanitizer-x86_64-linux-bootstrap-msan | 16:47:15
 clang-cmake-armv7-selfhost| 16:06:33
 clang-cmake-armv7-global-isel | 15:47:24
 clang-cmake-armv8-selfhost-neon   | 15:44:33
 clang-cmake-armv8-lld | 15:30:22
 clang-cmake-armv7-selfhost-neon   | 15:30:08
 ppc64le-lld-multistage-test   | 11:02:37
 clang-with-lto-ubuntu | 08:50:59
 clang-with-thin-lto-ubuntu| 08:08:54
 clang-cmake-armv7-quick   | 06:51:25
 clang-atom-d525-fedora-rel| 06:45:54
 clang-cmake-aarch64-global-isel   | 06:41:28
 clang-cuda-build  | 06:38:09
 clang-cmak

[PATCH] D65249: [NFC] use C++11 in AlignOf.h

[JF Bastien via Phabricator via cfe-commits]

jfb added a comment.

In D65249#1603278 , @BillyONeal wrote:

> > @BillyONeal do you know if 19.11 has the aligned_storage issue on x86?
>
> aligned_storage is still capped at what the library can fake with unions. It 
> would be an ABI break to change it to use alignas, so things where the x86 
> stack temporarily breaks T's usual alignment rules will affect it (and for 
> all releases using VS2015's ABI). We recommend customers use `alignas(T) 
> unsigned char space[sizeof(T)]` if they can't tolerate such limitations.


Thanks!

@rnk: how about I add a bit of code that wraps `aligned_storage` on all 
platforms except MSVC (where I'd implement it as Billy suggests). That would 
mean updating all the uses of `aligned_storage` to this LLVM one, but that's 
not a big deal.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65249/new/

https://reviews.llvm.org/D65249



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

[PATCH] D50256: [Analyzer] Basic support for multiplication and division in the constraint manager (for == and != only)

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added inline comments.



Comment at: test/Analysis/multiplicative-folding.c:140-142
+clang_analyzer_eval(n == -1); //expected-warning{{FALSE}}
+clang_analyzer_eval(n == 0); //expected-warning{{TRUE}}
+clang_analyzer_eval(n == 1); //expected-warning{{FALSE}}

Something's not right here. All three can potentially be true, because both 
`1/2 == 0` and `(-1)/2 == 0`.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D50256/new/

https://reviews.llvm.org/D50256



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

[PATCH] D58164: Block+lambda: allow reference capture

[Akira Hatanaka via Phabricator via cfe-commits]

ahatanak updated this revision to Diff 212016.
ahatanak added a comment.

Rebase.

I think the fix is correct. When the lambda expression for the generic lambda 
is built, `BuildLambdaExpr` passes a `Capture` object in 
`LambdaScopeInfo::Captures` to `BuildCaptureField` to build the closure class 
field for the capture, so it should be okay to read the type of the field and 
pass it to `LambdaScopeInfo::addCapture` when rebuilding the lambda scope info.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58164/new/

https://reviews.llvm.org/D58164

Files:
  lib/Sema/SemaDecl.cpp
  test/CodeGenObjCXX/block-nested-in-lambda.mm

Index: test/CodeGenObjCXX/block-nested-in-lambda.mm
===
--- test/CodeGenObjCXX/block-nested-in-lambda.mm
+++ test/CodeGenObjCXX/block-nested-in-lambda.mm
@@ -1,6 +1,9 @@
-// RUN: %clang_cc1 -triple=x86_64-apple-darwin10 -emit-llvm -std=c++11 -fblocks -fobjc-arc -o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple=x86_64-apple-darwin10 -emit-llvm -std=c++14 -fblocks -fobjc-arc -o - %s | FileCheck %s
 
 // CHECK: %[[STRUCT_BLOCK_DESCRIPTOR:.*]] = type { i64, i64 }
+// CHECK: %[[S:.*]] = type { i32 }
+// CHECK: %[[CLASS_ANON_2:.*]] = type { %[[S]]* }
+// CHECK: %[[CLASS_ANON_3:.*]] = type { %[[S]] }
 
 // CHECK: %[[BLOCK_CAPTURED0:.*]] = getelementptr inbounds <{ i8*, i32, i32, i8*, %struct.__block_descriptor*, i32*, i32* }>, <{ i8*, i32, i32, i8*, %struct.__block_descriptor*, i32*, i32* }>* %[[BLOCK:.*]], i32 0, i32 5
 // CHECK: %[[V0:.*]] = getelementptr inbounds %[[LAMBDA_CLASS:.*]], %[[LAMBDA_CLASS]]* %[[THIS:.*]], i32 0, i32 0
@@ -33,7 +36,7 @@
 // reference.
 
 // CHECK-LABEL: define void @_ZN18CaptureByReference5test0Ev(
-// CHECK-LABEL: define internal void @"_ZZN18CaptureByReference5test0EvENK3$_1clEv"(
+// CHECK-LABEL: define internal void @"_ZZN18CaptureByReference5test0EvENK3$_3clEv"(
 // CHECK: %[[BLOCK_DESCRIPTOR:.*]] = getelementptr inbounds <{ i8*, i32, i32, i8*, %[[STRUCT_BLOCK_DESCRIPTOR]]*, i8** }>, <{ i8*, i32, i32, i8*, %[[STRUCT_BLOCK_DESCRIPTOR]]*, i8** }>* %{{.*}}, i32 0, i32 4
 // CHECK: store %[[STRUCT_BLOCK_DESCRIPTOR]]* bitcast ({ i64, i64, i8*, i64 }* @"__block_descriptor_40_e5_v8\01?0ls32l8" to %[[STRUCT_BLOCK_DESCRIPTOR]]*), %[[STRUCT_BLOCK_DESCRIPTOR]]** %[[BLOCK_DESCRIPTOR]], align 8
 
@@ -46,10 +49,60 @@
 // is captured by reference.
 
 // CHECK-LABEL: define void @_ZN18CaptureByReference5test1Ev(
-// CHECK-LABEL: define internal void @"_ZZN18CaptureByReference5test1EvENK3$_2clEv"(
+// CHECK-LABEL: define internal void @"_ZZN18CaptureByReference5test1EvENK3$_4clEv"(
 // CHECK: %[[BLOCK_DESCRIPTOR:.*]] = getelementptr inbounds <{ i8*, i32, i32, i8*, %[[STRUCT_BLOCK_DESCRIPTOR]]*, i8*, i8*, i8** }>, <{ i8*, i32, i32, i8*, %[[STRUCT_BLOCK_DESCRIPTOR]]*, i8*, i8*, i8** }>* %{{.*}}, i32 0, i32 4
 // CHECK: store %[[STRUCT_BLOCK_DESCRIPTOR]]* bitcast ({ i64, i64, i8*, i8*, i8*, i64 }* @"__block_descriptor_56_8_32s40s_e5_v8\01?0l" to %[[STRUCT_BLOCK_DESCRIPTOR]]*), %[[STRUCT_BLOCK_DESCRIPTOR]]** %[[BLOCK_DESCRIPTOR]], align 8
 
+void test1() {
+  id a = getObj(), b = getObj(), c = getObj();
+  [&a, b, c]{ ^{ a = 0; use(b); use(c); }(); }();
+}
+
+struct S {
+  int val() const;
+  int a;
+  S();
+  S(const S&);
+  S &operator=(const S&);
+  S(S&&);
+  S &operator=(S&&);
+};
+
+S getS();
+
+// CHECK: define internal i32 @"_ZZN18CaptureByReference5test2EvENK3$_1clIiEEDaT_"(%[[CLASS_ANON_2]]* %{{.*}}, i32 %{{.*}})
+// CHECK: %[[BLOCK:.*]] = alloca <{ i8*, i32, i32, i8*, %{{.*}}, %[[S]]* }>, align 8
+// CHECK: %[[BLOCK_CAPTURED:.*]] = getelementptr inbounds <{ i8*, i32, i32, i8*, %{{.*}}, %[[S]]* }>, <{ i8*, i32, i32, i8*, %{{.*}}, %[[S]]* }>* %[[BLOCK]], i32 0, i32 5
+// CHECK: %[[V0:.*]] = getelementptr inbounds %[[CLASS_ANON_2]], %[[CLASS_ANON_2]]* %{{.*}}, i32 0, i32 0
+// CHECK: %[[V1:.*]] = load %[[S]]*, %[[S]]** %[[V0]], align 8
+// CHECK: store %[[S]]* %[[V1]], %[[S]]** %[[BLOCK_CAPTURED]], align 8
+
+int test2() {
+  S s;
+  auto fn = [&](const auto a){
+return ^{
+  return s.val();
+}();
+  };
+  return fn(123);
+}
+
+// CHECK: define internal i32 @"_ZZN18CaptureByReference5test3EvENK3$_2clIiEEDaT_"(%[[CLASS_ANON_3]]* %{{.*}}, i32 %{{.*}})
+// CHECK: %[[BLOCK:.*]] = alloca <{ i8*, i32, i32, i8*, %{{.*}}*, %[[S]] }>, align 8
+// CHECK: %[[BLOCK_CAPTURED:.*]] = getelementptr inbounds <{ i8*, i32, i32, i8*, %{{.*}}*, %[[S]] }>, <{ i8*, i32, i32, i8*, %{{.*}}*, %[[S]] }>* %[[BLOCK]], i32 0, i32 5
+// CHECK: %[[V0:.*]] = getelementptr inbounds %[[CLASS_ANON_3]], %[[CLASS_ANON_3]]* %{{.*}}, i32 0, i32 0
+// CHECK: call void @_ZN18CaptureByReference1SC1ERKS0_(%[[S]]* %[[BLOCK_CAPTURED]], %[[S]]* {{.*}} %[[V0]])
+
+int test3() {
+  const S &s = getS();
+  auto fn = [=](const auto a){
+return ^{
+  return s.val();
+}();
+  };
+  return fn(123);
+}
+
 // CHECK-LABEL: define linkonce_odr hidden void @__copy_helper_block_8_32s40s(
 // CHECK-NOT: call void 

[PATCH] D65249: [NFC] use C++11 in AlignOf.h

[Billy Robert O'Neal III via Phabricator via cfe-commits]

BillyONeal added a comment.

> @BillyONeal do you know if 19.11 has the aligned_storage issue on x86?

aligned_storage is still capped at what the library can fake with unions. It 
would be an ABI break to change it to use alignas, so things where the x86 
stack temporarily breaks T's usual alignment rules will affect it (and for all 
releases using VS2015's ABI). We recommend customers use `alignas(T) unsigned 
char space[sizeof(T)]` if they can't tolerate such limitations.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65249/new/

https://reviews.llvm.org/D65249



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

[PATCH] D64666: [Sema] Enable -Wimplicit-float-conversion for integral to floating point precision loss

[Ziang Wan via Phabricator via cfe-commits]

ziangwan updated this revision to Diff 212015.
ziangwan added a comment.

Fix typos.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64666/new/

https://reviews.llvm.org/D64666

Files:
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaChecking.cpp
  clang/test/Sema/conversion.c
  clang/test/Sema/ext_vector_casts.c
  clang/test/Sema/implicit-int-float-conversion.c
  clang/test/Sema/implicit-int-float-narrowing.cpp

Index: clang/test/Sema/implicit-int-float-narrowing.cpp
===
--- /dev/null
+++ clang/test/Sema/implicit-int-float-narrowing.cpp
@@ -0,0 +1,10 @@
+// RUN: %clang_cc1 %s -verify -Wno-conversion -Wno-c++11-narrowing -Wimplicit-int-float-conversion
+
+void testNoWarningOnNarrowing() {
+  // Test that we do not issue duplicated warnings for
+  // C++11 narrowing.
+  float a = {L}; // expected-no-diagnostics
+
+  long b = L;
+  float c = {b}; // expected-no-diagnostics
+}
Index: clang/test/Sema/implicit-int-float-conversion.c
===
--- /dev/null
+++ clang/test/Sema/implicit-int-float-conversion.c
@@ -0,0 +1,53 @@
+// RUN: %clang_cc1 %s -verify -Wno-conversion -Wimplicit-int-float-conversion
+
+long testReturn(long a, float b) {
+  return a + b; // expected-warning {{implicit conversion from 'long' to 'float' may lose precision}}
+}
+
+void testAssignment() {
+  float f = 22;
+  double b = L;
+
+#ifndef __ILP32__
+  float ff = L;// expected-warning {{implicit conversion from 'long' to 'float' changes value from  to 1312}}
+  float  = UL; // expected-warning {{implicit conversion from 'unsigned long' to 'float' changes value from  to 1312}}
+#else
+  float ff = L;// expected-warning {{implicit conversion from 'long long' to 'float' changes value from  to 1312}}
+  float  = UL; // expected-warning {{implicit conversion from 'unsigned long long' to 'float' changes value from  to 1312}}
+#endif
+
+  long l = L;
+  float fff = l; // expected-warning {{implicit conversion from 'long' to 'float' may lose precision}}
+}
+
+void testExpression() {
+  float a = 0.0f;
+
+#ifndef __ILP32__
+  float b = L + a; // expected-warning {{implicit conversion from 'long' to 'float' changes value from  to 1312}}
+#else
+  float b = L + a; // expected-warning {{implicit conversion from 'long long' to 'float' changes value from  to 1312}}
+#endif
+
+  float g =  + ;
+  float c =  + 2223; // expected-warning {{implicit conversion from 'int' to 'float' changes value from 4445 to }}
+
+  int i = 0;
+  float d = i + a; // expected-warning {{implicit conversion from 'int' to 'float' may lose precision}}
+
+  double e = 0.0;
+  double f = i + e;
+}
+
+void testCNarrowing() {
+  // Since this is a C file. C++11 narrowing is not in effect.
+  // In this case, we should issue warnings.
+#ifndef __ILP32__
+  float a = {L}; // expected-warning {{implicit conversion from 'long' to 'float' changes value from  to 1312}}
+#else
+  float a = {L};   // expected-warning {{implicit conversion from 'long long' to 'float' changes value from  to 1312}}
+#endif
+
+  long b = L;
+  float c = {b}; // expected-warning {{implicit conversion from 'long' to 'float' may lose precision}}
+}
Index: clang/test/Sema/ext_vector_casts.c
===
--- clang/test/Sema/ext_vector_casts.c
+++ clang/test/Sema/ext_vector_casts.c
@@ -115,12 +115,12 @@
   vl = vl + t; // expected-warning {{implicit conversion loses integer precision}}
   
   vf = 1 + vf;
-  vf = l + vf;
+  vf = l + vf; // expected-warning {{implicit conversion from 'long' to 'float2' (vector of 2 'float' values) may lose precision}}
   vf = 2.0 + vf;
   vf = d + vf; // expected-warning {{implicit conversion loses floating-point precision}}
-  vf = vf + 0x;
+  vf = vf + 0x; // expected-warning {{implicit conversion from 'unsigned int' to 'float2' (vector of 2 'float' values) changes value from 4294967295 to 4294967296}}
   vf = vf + 2.1; // expected-warning {{implicit conversion loses floating-point precision}}
-  
-  vd = l + vd;
-  vd = vd + t;
+
+  vd = l + vd; // expected-warning {{implicit conversion from 'long' to 'double2' (vector of 2 'double' values) may lose precision}}
+  vd = vd + t; // expected-warning {{implicit conversion from '__uint128_t' (aka 'unsigned __int128') to 'double2' (vector of 2 'double' values) may lose precision}}
 }
Index: clang/test/Sema/conversion.c
===
--- clang/test/

[PATCH] D64838: [Attr] Support _attribute__ ((fallthrough))

[Nathan Huckleberry via Phabricator via cfe-commits]

Nathan-Huckleberry updated this revision to Diff 212012.
Nathan-Huckleberry added a comment.
Herald added a subscriber: arphaman.

- Rework attribute parsing


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64838/new/

https://reviews.llvm.org/D64838

Files:
  clang/include/clang/Basic/Attr.td
  clang/lib/Parse/ParseStmt.cpp
  clang/lib/Sema/AnalysisBasedWarnings.cpp
  clang/test/Index/blocks.c
  clang/test/Index/load-exprs.c
  clang/test/Sema/fallthrough-attr.c
  clang/test/SemaCXX/switch-implicit-fallthrough.cpp
  clang/test/SemaCXX/warn-unused-label-error.cpp

Index: clang/test/SemaCXX/warn-unused-label-error.cpp
===
--- clang/test/SemaCXX/warn-unused-label-error.cpp
+++ clang/test/SemaCXX/warn-unused-label-error.cpp
@@ -18,9 +18,9 @@
   }
 
   void h() {
-D: // expected-warning {{unused label 'D'}}
+D:
   #pragma weak unused_local_static
-  __attribute__((unused))  // expected-warning {{declaration does not declare anything}}
+  __attribute__((unused))  // expected-error {{'unused' attribute cannot be applied to a statement}}
   ;
   }
 }
Index: clang/test/SemaCXX/switch-implicit-fallthrough.cpp
===
--- clang/test/SemaCXX/switch-implicit-fallthrough.cpp
+++ clang/test/SemaCXX/switch-implicit-fallthrough.cpp
@@ -329,3 +329,15 @@
   }
   return n;
 }
+
+int fallthrough_attribute_spelling(int n) {
+  switch (n) {
+  case 0:
+n++;
+__attribute__((fallthrough));
+  case 1:
+n++;
+break;
+  }
+  return n;
+}
Index: clang/test/Sema/fallthrough-attr.c
===
--- /dev/null
+++ clang/test/Sema/fallthrough-attr.c
@@ -0,0 +1,46 @@
+// RUN: %clang_cc1 -fsyntax-only -std=gnu89 -verify -Wimplicit-fallthrough %s
+
+int foo(int x) {
+  int a = 0;
+
+  switch (x) {
+  case 0:
+a++;
+  case 1:
+// expected-warning@-1{{unannotated fall-through between switch labels}}
+//expected-note@-2{{insert 'break;' to avoid fall-through}}
+a--;
+  case 2:
+// expected-warning@-1{{unannotated fall-through between switch labels}}
+// expected-note@-2{{insert 'break;' to avoid fall-through}}
+break;
+  default:
+a = 1;
+  }
+
+  return 0;
+}
+
+int bar(int x) {
+  int a = 0;
+
+  switch (x) {
+  case 0:
+a++;
+__attribute__((fallthrough));
+  case 1:
+a--;
+__attribute__((fallthrough));
+  case 2:
+break;
+  default:
+a = 1;
+  }
+
+  return 0;
+}
+
+__attribute__((fallthrough)); // expected-warning {{declaration does not declare anything}}
+void baz(int x) {
+  __attribute__((fallthrough)); // expected-error {{fallthrough annotation is outside switch statement}}
+}
Index: clang/test/Index/load-exprs.c
===
--- clang/test/Index/load-exprs.c
+++ clang/test/Index/load-exprs.c
@@ -52,7 +52,7 @@
 // CHECK: load-exprs.c:7:23: DeclRefExpr=x:6:12 Extent=[7:23 - 7:24]
 // CHECK: load-exprs.c:10:5: FunctionDecl=test_blocks:10:5 (Definition) Extent=[10:1 - 21:2]
 // CHECK: load-exprs.c:10:21: ParmDecl=x:10:21 (Definition) Extent=[10:17 - 10:22]
-// CHECK: load-exprs.c:11:15: VarDecl=y:11:15 (Definition) Extent=[11:3 - 11:20]
+// CHECK: load-exprs.c:11:15: VarDecl=y:11:15 (Definition) Extent=[11:11 - 11:20]
 // CHECK: load-exprs.c:11:19: DeclRefExpr=x:10:21 Extent=[11:19 - 11:20]
 // CHECK: load-exprs.c:12:3: CallExpr= Extent=[12:3 - 19:7]
 // CHECK: load-exprs.c:13:17: VarDecl=z:13:17 (Definition) Extent=[13:6 - 13:22]
Index: clang/test/Index/blocks.c
===
--- clang/test/Index/blocks.c
+++ clang/test/Index/blocks.c
@@ -14,7 +14,7 @@
 // CHECK: blocks.c:7:3: DeclStmt= Extent=[7:3 - 7:26]
 // CHECK: blocks.c:7:21: VarDecl=_foo:7:21 (Definition) Extent=[7:3 - 7:25]
 // CHECK: blocks.c:7:17: TypeRef=struct foo:4:8 Extent=[7:17 - 7:20]
-// CHECK: blocks.c:8:11: VarDecl=i:8:11 (Definition) Extent=[8:3 - 8:16]
+// CHECK: blocks.c:8:11: VarDecl=i:8:11 (Definition) Extent=[8:11 - 8:16]
 // CHECK: blocks.c:8:15: IntegerLiteral= Extent=[8:15 - 8:16]
 // CHECK: blocks.c:9:3: CallExpr= Extent=[9:3 - 9:65]
 // CHECK: blocks.c:9:3: BlockExpr= Extent=[9:3 - 9:58]
Index: clang/lib/Sema/AnalysisBasedWarnings.cpp
===
--- clang/lib/Sema/AnalysisBasedWarnings.cpp
+++ clang/lib/Sema/AnalysisBasedWarnings.cpp
@@ -1215,7 +1215,7 @@
 tok::r_square, tok::r_square
   };
 
-  bool PreferClangAttr = !PP.getLangOpts().CPlusPlus17;
+  bool PreferClangAttr = !PP.getLangOpts().CPlusPlus17 && !PP.getLangOpts().C2x;
 
   StringRef MacroName;
   if (PreferClangAttr)
@@ -1224,24 +1224,19 @@
 MacroName = PP.getLastMacroWithSpelling(Loc, FallthroughTokens);
   if (MacroName.empty() && !PreferClangAttr)
 MacroName = PP.getLastMacroWithSpelling(Loc, ClangFallthrou

[PATCH] D64838: [Attr] Support _attribute__ ((fallthrough))

[Nathan Huckleberry via Phabricator via cfe-commits]

Nathan-Huckleberry updated this revision to Diff 212014.
Nathan-Huckleberry added a comment.

- Formatting fixes


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64838/new/

https://reviews.llvm.org/D64838

Files:
  clang/include/clang/Basic/Attr.td
  clang/lib/Parse/ParseStmt.cpp
  clang/lib/Sema/AnalysisBasedWarnings.cpp
  clang/test/Index/blocks.c
  clang/test/Index/load-exprs.c
  clang/test/Sema/fallthrough-attr.c
  clang/test/SemaCXX/switch-implicit-fallthrough.cpp
  clang/test/SemaCXX/warn-unused-label-error.cpp

Index: clang/test/SemaCXX/warn-unused-label-error.cpp
===
--- clang/test/SemaCXX/warn-unused-label-error.cpp
+++ clang/test/SemaCXX/warn-unused-label-error.cpp
@@ -18,9 +18,9 @@
   }
 
   void h() {
-D: // expected-warning {{unused label 'D'}}
-  #pragma weak unused_local_static
-  __attribute__((unused))  // expected-warning {{declaration does not declare anything}}
-  ;
+  D:
+#pragma weak unused_local_static
+__attribute__((unused)) // expected-error {{'unused' attribute cannot be applied to a statement}}
+;
   }
 }
Index: clang/test/SemaCXX/switch-implicit-fallthrough.cpp
===
--- clang/test/SemaCXX/switch-implicit-fallthrough.cpp
+++ clang/test/SemaCXX/switch-implicit-fallthrough.cpp
@@ -329,3 +329,15 @@
   }
   return n;
 }
+
+int fallthrough_attribute_spelling(int n) {
+  switch (n) {
+  case 0:
+n++;
+__attribute__((fallthrough));
+  case 1:
+n++;
+break;
+  }
+  return n;
+}
Index: clang/test/Sema/fallthrough-attr.c
===
--- /dev/null
+++ clang/test/Sema/fallthrough-attr.c
@@ -0,0 +1,46 @@
+// RUN: %clang_cc1 -fsyntax-only -std=gnu89 -verify -Wimplicit-fallthrough %s
+
+int foo(int x) {
+  int a = 0;
+
+  switch (x) {
+  case 0:
+a++;
+  case 1:
+// expected-warning@-1{{unannotated fall-through between switch labels}}
+//expected-note@-2{{insert 'break;' to avoid fall-through}}
+a--;
+  case 2:
+// expected-warning@-1{{unannotated fall-through between switch labels}}
+// expected-note@-2{{insert 'break;' to avoid fall-through}}
+break;
+  default:
+a = 1;
+  }
+
+  return 0;
+}
+
+int bar(int x) {
+  int a = 0;
+
+  switch (x) {
+  case 0:
+a++;
+__attribute__((fallthrough));
+  case 1:
+a--;
+__attribute__((fallthrough));
+  case 2:
+break;
+  default:
+a = 1;
+  }
+
+  return 0;
+}
+
+__attribute__((fallthrough)); // expected-warning {{declaration does not declare anything}}
+void baz(int x) {
+  __attribute__((fallthrough)); // expected-error {{fallthrough annotation is outside switch statement}}
+}
Index: clang/test/Index/load-exprs.c
===
--- clang/test/Index/load-exprs.c
+++ clang/test/Index/load-exprs.c
@@ -52,7 +52,7 @@
 // CHECK: load-exprs.c:7:23: DeclRefExpr=x:6:12 Extent=[7:23 - 7:24]
 // CHECK: load-exprs.c:10:5: FunctionDecl=test_blocks:10:5 (Definition) Extent=[10:1 - 21:2]
 // CHECK: load-exprs.c:10:21: ParmDecl=x:10:21 (Definition) Extent=[10:17 - 10:22]
-// CHECK: load-exprs.c:11:15: VarDecl=y:11:15 (Definition) Extent=[11:3 - 11:20]
+// CHECK: load-exprs.c:11:15: VarDecl=y:11:15 (Definition) Extent=[11:11 - 11:20]
 // CHECK: load-exprs.c:11:19: DeclRefExpr=x:10:21 Extent=[11:19 - 11:20]
 // CHECK: load-exprs.c:12:3: CallExpr= Extent=[12:3 - 19:7]
 // CHECK: load-exprs.c:13:17: VarDecl=z:13:17 (Definition) Extent=[13:6 - 13:22]
@@ -78,4 +78,3 @@
 // CHECK: load-exprs.c:31:32: MemberRef=array:24:12 Extent=[31:32 - 31:37]
 // CHECK: load-exprs.c:31:38: DeclRefExpr=StartIndex:27:8 Extent=[31:38 - 31:48]
 // CHECK: load-exprs.c:31:50: MemberRef=b:2:19 Extent=[31:50 - 31:51]
-
Index: clang/test/Index/blocks.c
===
--- clang/test/Index/blocks.c
+++ clang/test/Index/blocks.c
@@ -14,7 +14,7 @@
 // CHECK: blocks.c:7:3: DeclStmt= Extent=[7:3 - 7:26]
 // CHECK: blocks.c:7:21: VarDecl=_foo:7:21 (Definition) Extent=[7:3 - 7:25]
 // CHECK: blocks.c:7:17: TypeRef=struct foo:4:8 Extent=[7:17 - 7:20]
-// CHECK: blocks.c:8:11: VarDecl=i:8:11 (Definition) Extent=[8:3 - 8:16]
+// CHECK: blocks.c:8:11: VarDecl=i:8:11 (Definition) Extent=[8:11 - 8:16]
 // CHECK: blocks.c:8:15: IntegerLiteral= Extent=[8:15 - 8:16]
 // CHECK: blocks.c:9:3: CallExpr= Extent=[9:3 - 9:65]
 // CHECK: blocks.c:9:3: BlockExpr= Extent=[9:3 - 9:58]
@@ -31,4 +31,3 @@
 // CHECK: blocks.c:9:54: DeclRefExpr=i:8:11 Extent=[9:54 - 9:55]
 // CHECK: blocks.c:9:59: UnaryOperator= Extent=[9:59 - 9:64]
 // CHECK: blocks.c:9:60: DeclRefExpr=_foo:7:21 Extent=[9:60 - 9:64]
-
Index: clang/lib/Sema/AnalysisBasedWarnings.cpp
===
--- clang/lib/Sema/AnalysisBasedWarnings.cpp
+++ clang/lib/Sema/AnalysisBasedWarnings.cpp

[PATCH] D65341: [OpenMP] Add support for close map modifier in Clang

[Gheorghe-Teodor Bercea via Phabricator via cfe-commits]

gtbercea updated this revision to Diff 212011.
gtbercea added a comment.

- Improve test.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65341/new/

https://reviews.llvm.org/D65341

Files:
  lib/CodeGen/CGOpenMPRuntime.cpp
  test/OpenMP/target_data_codegen.cpp


Index: test/OpenMP/target_data_codegen.cpp
===
--- test/OpenMP/target_data_codegen.cpp
+++ test/OpenMP/target_data_codegen.cpp
@@ -283,4 +283,34 @@
   {++arg;}
 }
 #endif
+///==///
+ RUN: %clang_cc1 -DCK4 -verify -fopenmp -x c++ -triple 
powerpc64le-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm %s 
-o - | FileCheck %s --check-prefix CK4
+#ifdef CK4
+void test_close_modifier(int arg) {
+  // CK4: private unnamed_addr constant [1 x i64] [i64 1059]
+  #pragma omp target data map(close,tofrom: arg)
+  {++arg;}
+}
+#endif
+///==///
+ RUN: %clang_cc1 -DCK5 -verify -fopenmp -x c++ -triple 
powerpc64le-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm %s 
-o - | FileCheck %s --check-prefix CK5
+#ifdef CK5
+
+struct S1 {
+  int i;
+};
+struct S2 {
+  S1 s;
+  struct S2 *ps;
+};
+
+void test_close_modifier(int arg) {
+  S2 *ps;
+  // CK5: private unnamed_addr constant [5 x i64] [i64 1059, i64 32, {{.*}}, 
i64 16, i64 1043]
+  #pragma omp target data map(close,tofrom: arg, ps->ps->ps->ps->s)
+  {
+++(arg);
+  }
+}
+#endif
 #endif
Index: lib/CodeGen/CGOpenMPRuntime.cpp
===
--- lib/CodeGen/CGOpenMPRuntime.cpp
+++ lib/CodeGen/CGOpenMPRuntime.cpp
@@ -7087,6 +7087,9 @@
 OMP_MAP_LITERAL = 0x100,
 /// Implicit map
 OMP_MAP_IMPLICIT = 0x200,
+/// Close is a hint to the runtime to allocate memory close to
+/// the target device.
+OMP_MAP_CLOSE = 0x400,
 /// The 16 MSBs of the flags indicate whether the entry is member of some
 /// struct/class.
 OMP_MAP_MEMBER_OF = 0x,
@@ -7255,6 +7258,9 @@
 if (llvm::find(MapModifiers, OMPC_MAP_MODIFIER_always)
 != MapModifiers.end())
   Bits |= OMP_MAP_ALWAYS;
+if (llvm::find(MapModifiers, OMPC_MAP_MODIFIER_close)
+!= MapModifiers.end())
+  Bits |= OMP_MAP_CLOSE;
 return Bits;
   }
 
@@ -7683,10 +7689,10 @@
 
   if (!IsExpressionFirstInfo) {
 // If we have a PTR_AND_OBJ pair where the OBJ is a pointer as 
well,
-// then we reset the TO/FROM/ALWAYS/DELETE flags.
+// then we reset the TO/FROM/ALWAYS/DELETE/CLOSE flags.
 if (IsPointer)
   Flags &= ~(OMP_MAP_TO | OMP_MAP_FROM | OMP_MAP_ALWAYS |
- OMP_MAP_DELETE);
+ OMP_MAP_DELETE | OMP_MAP_CLOSE);
 
 if (ShouldBeMemberOf) {
   // Set placeholder value MEMBER_OF= to indicate that the flag


Index: test/OpenMP/target_data_codegen.cpp
===
--- test/OpenMP/target_data_codegen.cpp
+++ test/OpenMP/target_data_codegen.cpp
@@ -283,4 +283,34 @@
   {++arg;}
 }
 #endif
+///==///
+ RUN: %clang_cc1 -DCK4 -verify -fopenmp -x c++ -triple powerpc64le-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm %s -o - | FileCheck %s --check-prefix CK4
+#ifdef CK4
+void test_close_modifier(int arg) {
+  // CK4: private unnamed_addr constant [1 x i64] [i64 1059]
+  #pragma omp target data map(close,tofrom: arg)
+  {++arg;}
+}
+#endif
+///==///
+ RUN: %clang_cc1 -DCK5 -verify -fopenmp -x c++ -triple powerpc64le-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm %s -o - | FileCheck %s --check-prefix CK5
+#ifdef CK5
+
+struct S1 {
+  int i;
+};
+struct S2 {
+  S1 s;
+  struct S2 *ps;
+};
+
+void test_close_modifier(int arg) {
+  S2 *ps;
+  // CK5: private unnamed_addr constant [5 x i64] [i64 1059, i64 32, {{.*}}, i64 16, i64 1043]
+  #pragma omp target data map(close,tofrom: arg, ps->ps->ps->ps->s)
+  {
+++(arg);
+  }
+}
+#endif
 #endif
Index: lib/CodeGen/CGOpenMPRuntime.cpp
===
--- lib/CodeGen/CGOpenMPRuntime.cpp
+++ lib/CodeGen/CGOpenMPRuntime.cpp
@@ -7087,6 +7087,9 @@
 OMP_MAP_LITERAL = 0x100,
 /// Implicit map
 OMP_MAP_IMPLICIT = 0x200,
+/// Close is a hint to the runtime to allocate memory close to
+/// the target device.
+OMP_MAP_CLOSE = 0x400,
 /// The 16 MSBs of the flags indicate whether the entry is member of some
 /// struct/class.
 OMP_MAP_MEMBER_OF = 0x,
@@ -7255,6 +7258,9 @@
 if (llvm::find(MapModifiers, OMPC_MAP_MODIFIER_always)
 != MapModifiers.end())
   Bits |=

[PATCH] D65343: [clang-tidy] Fix the documentation for linuxkernel-must-use-errs.

[Tom Roeder via Phabricator via cfe-commits]

tmroeder added a comment.

Apologies about D59963 ; I should have waited 
longer to make sure things were resolved. My submission raced with a flip from 
being approved to land to not approved to land.

I'll wait longer next time to make sure comments and approvals are stable.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65343/new/

https://reviews.llvm.org/D65343



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

[PATCH] D59963: [clang-tidy] Add a module for the Linux kernel.

[Tom Roeder via Phabricator via cfe-commits]

tmroeder marked an inline comment as done.
tmroeder added inline comments.



Comment at: clang-tools-extra/clang-tidy/linuxkernel/MustCheckErrsCheck.cpp:12
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+#include 
+

tmroeder wrote:
> nickdesaulniers wrote:
> > tmroeder wrote:
> > > lebedev.ri wrote:
> > > > This looks wrong
> > > Yeah, I'm not sure where that came from. I'll remove it.
> > Hard to tell, but I don't think this `using` statement was ever removed as 
> > requested?
> It's not the "using" statement that was requested to be removed in the 
> initial diff, but rather "#include ", which I did 
> remove.
> 
> I'm not sure why the "This looks wrong" gets attached to the "using" 
> statement in later diffs.
Nick, can you confirm that this addresses your comment?


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59963/new/

https://reviews.llvm.org/D59963



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

[PATCH] D65302: [clang][docs][release notes] mention asm goto support

[Hans Wennborg via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL367158: [clang][docs][release notes] mention asm goto 
support (authored by hans, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D65302?vs=212002&id=212007#toc

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65302/new/

https://reviews.llvm.org/D65302

Files:
  cfe/branches/release_90/docs/ReleaseNotes.rst


Index: cfe/branches/release_90/docs/ReleaseNotes.rst
===
--- cfe/branches/release_90/docs/ReleaseNotes.rst
+++ cfe/branches/release_90/docs/ReleaseNotes.rst
@@ -111,6 +111,12 @@
   in all C-family languages. This macro is similar to ``__FILE__`` except it
   will always provide the last path component when possible.
 
+- Initial support for ``asm goto`` statements (a GNU C extension) has been
+  added for control flow from inline assembly to labels. The main consumers of
+  this construct are the Linux kernel (CONFIG_JUMP_LABEL=y) and glib. There are
+  still a few unsupported corner cases in Clang's integrated assembler and
+  IfConverter. Please file bugs for any issues you run into.
+
 - ...
 
 C11 Feature Support
@@ -242,6 +248,33 @@
 Significant Known Problems
 ==
 
+Linux Kernel
+
+
+With support for asm goto, the mainline Linux kernel for x86_64 is now 
buildable
+(and bootable) with Clang 9.  Other architectures that don't require
+CONFIG_JUMP_LABEL=y such as arm, aarch64, ppc32, ppc64le, (and possibly mips)
+have been supported with older releases of Clang (Clang 4 was first used with
+aarch64).
+
+The Android and ChromeOS Linux distributions have moved to building their Linux
+kernels with Clang, and Google is currently testing Clang built kernels for
+their production Linux kernels.
+
+Further, LLD, llvm-objcopy, llvm-ar, llvm-nm, llvm-objdump can all be used to
+build a working Linux kernel.
+
+More information about building Linux kernels with Clang can be found:
+
+- `ClangBuiltLinux web page `_.
+- `Issue Tracker `_.
+- `Wiki `_.
+- `Mailing List `_.
+- `Bi-weekly Meeting 
`_.
+- #clangbuiltlinux on Freenode.
+- `Clang Meta bug `_.
+- `Continuous Integration 
`_.
+
 Additional Information
 ==
 


Index: cfe/branches/release_90/docs/ReleaseNotes.rst
===
--- cfe/branches/release_90/docs/ReleaseNotes.rst
+++ cfe/branches/release_90/docs/ReleaseNotes.rst
@@ -111,6 +111,12 @@
   in all C-family languages. This macro is similar to ``__FILE__`` except it
   will always provide the last path component when possible.
 
+- Initial support for ``asm goto`` statements (a GNU C extension) has been
+  added for control flow from inline assembly to labels. The main consumers of
+  this construct are the Linux kernel (CONFIG_JUMP_LABEL=y) and glib. There are
+  still a few unsupported corner cases in Clang's integrated assembler and
+  IfConverter. Please file bugs for any issues you run into.
+
 - ...
 
 C11 Feature Support
@@ -242,6 +248,33 @@
 Significant Known Problems
 ==
 
+Linux Kernel
+
+
+With support for asm goto, the mainline Linux kernel for x86_64 is now buildable
+(and bootable) with Clang 9.  Other architectures that don't require
+CONFIG_JUMP_LABEL=y such as arm, aarch64, ppc32, ppc64le, (and possibly mips)
+have been supported with older releases of Clang (Clang 4 was first used with
+aarch64).
+
+The Android and ChromeOS Linux distributions have moved to building their Linux
+kernels with Clang, and Google is currently testing Clang built kernels for
+their production Linux kernels.
+
+Further, LLD, llvm-objcopy, llvm-ar, llvm-nm, llvm-objdump can all be used to
+build a working Linux kernel.
+
+More information about building Linux kernels with Clang can be found:
+
+- `ClangBuiltLinux web page `_.
+- `Issue Tracker `_.
+- `Wiki `_.
+- `Mailing List `_.
+- `Bi-weekly Meeting `_.
+- #clangbuiltlinux on Freenode.
+- `Clang Meta bug `_.
+- `Continuous Integration `_.
+
 Additional Information
 ==
 
___
cfe-

[PATCH] D65302: [clang][docs][release notes] mention asm goto support

[Hans Wennborg via Phabricator via cfe-commits]

hans added a comment.

> I don't have an SVN checkout; would you be so kind as to please merge this on 
> my behalf?

Committed in r367158.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65302/new/

https://reviews.llvm.org/D65302



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

[PATCH] D65302: [clang][docs][release notes] mention asm goto support

[Nick Desaulniers via Phabricator via cfe-commits]

nickdesaulniers added a comment.

> Go ahead and commit directly to the branch (I think it can only be done with 
> SVN still), or let me know if you'd like me to do it.

Thanks again for the review and tips.  I was going to ask how does committing 
work now...

I don't have an SVN checkout; would you be so kind as to please merge this on 
my behalf?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65302/new/

https://reviews.llvm.org/D65302



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

[PATCH] D64666: [Sema] Enable -Wimplicit-float-conversion for integral to floating point precision loss

[Dávid Bolvanský via Phabricator via cfe-commits]

xbolva00 added a comment.

(But please wait for @aaron.ballman)


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64666/new/

https://reviews.llvm.org/D64666



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

[PATCH] D64666: [Sema] Enable -Wimplicit-float-conversion for integral to floating point precision loss

[Dávid Bolvanský via Phabricator via cfe-commits]

xbolva00 added inline comments.



Comment at: clang/lib/Sema/SemaChecking.cpp:11653
+  // Propagate whether we are in a c++ list initialization expression.
+  // If so, we do not issue warnings for implicit int-flaot conversion
+  // precision loss because c++11 narrowing already handles it.

Typo



Comment at: clang/lib/Sema/SemaChecking.cpp:11654
+  // If so, we do not issue warnings for implicit int-flaot conversion
+  // precision loss because c++11 narrowing already handles it.
+  IsListInit =

C++11


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64666/new/

https://reviews.llvm.org/D64666



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

[PATCH] D65302: [clang][docs][release notes] mention asm goto support

[Hans Wennborg via Phabricator via cfe-commits]

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

Looks great!

Go ahead and commit directly to the branch (I think it can only be done with 
SVN still), or let me know if you'd like me to do it.




Comment at: clang/docs/ReleaseNotes.rst:255
+With support for asm goto, the mainline Linux kernel for x86_64 is now 
buildable
+(and bootable) with Clang-9.  Other architectures that don't require
+CONFIG_JUMP_LABEL=y such as arm, aarch64, ppc32, ppc64le, (and possibly mips)

nit: I'd prefer "Clang 9" without the hyphen.



Comment at: clang/docs/ReleaseNotes.rst:257
+CONFIG_JUMP_LABEL=y such as arm, aarch64, ppc32, ppc64le, (and possibly mips)
+have been supported with older releases of Clang (clang-4 was first used with
+aarch64).

Clang 4


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65302/new/

https://reviews.llvm.org/D65302



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

[PATCH] D65110: [NewPM] Run avx*-builtins.c tests under the new pass manager only

[Leonard Chan via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL367157: [NewPM] Run avx*-builtins.c tests under the new pass 
manager only (authored by leonardchan, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D65110?vs=211572&id=212006#toc

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65110/new/

https://reviews.llvm.org/D65110

Files:
  cfe/trunk/test/CodeGen/avx512-reduceMinMaxIntrin.c
  cfe/trunk/test/CodeGen/avx512f-builtins.c
  cfe/trunk/test/CodeGen/avx512vl-builtins.c
  cfe/trunk/test/CodeGen/avx512vlbw-builtins.c

Index: cfe/trunk/test/CodeGen/avx512f-builtins.c
===
--- cfe/trunk/test/CodeGen/avx512f-builtins.c
+++ cfe/trunk/test/CodeGen/avx512f-builtins.c
@@ -1,5 +1,5 @@
-// RUN: %clang_cc1 -ffreestanding %s -triple=x86_64-apple-darwin -target-feature +avx512f -emit-llvm -o - -Wall -Werror | FileCheck %s
-// RUN: %clang_cc1 -fms-extensions -fms-compatibility -ffreestanding %s -triple=x86_64-windows-msvc -target-feature +avx512f -emit-llvm -o - -Wall -Werror | FileCheck %s
+// RUN: %clang_cc1 -fexperimental-new-pass-manager -ffreestanding %s -triple=x86_64-apple-darwin -target-feature +avx512f -emit-llvm -o - -Wall -Werror | FileCheck %s
+// RUN: %clang_cc1 -fexperimental-new-pass-manager -fms-extensions -fms-compatibility -ffreestanding %s -triple=x86_64-windows-msvc -target-feature +avx512f -emit-llvm -o - -Wall -Werror | FileCheck %s
 
 #include 
 
@@ -10480,20 +10480,24 @@
 
 __m512i test_mm512_mask_abs_epi32 (__m512i __W, __mmask16 __U, __m512i __A)
 {
-  // CHECK-LABEL: @test_mm512_mask_abs_epi32 
+  // CHECK-LABEL: @test_mm512_mask_abs_epi32
   // CHECK: [[SUB:%.*]] = sub <16 x i32> zeroinitializer, [[A:%.*]]
   // CHECK: [[CMP:%.*]] = icmp sgt <16 x i32> [[A]], zeroinitializer
   // CHECK: [[SEL:%.*]] = select <16 x i1> [[CMP]], <16 x i32> [[A]], <16 x i32> [[SUB]]
+  // CHECK: [[TMP:%.*]] = bitcast <16 x i32> [[SEL]] to <8 x i64>
+  // CHECK: [[SEL:%.*]] = bitcast <8 x i64> [[TMP]] to <16 x i32>
   // CHECK: select <16 x i1> %{{.*}}, <16 x i32> [[SEL]], <16 x i32> %{{.*}}
   return _mm512_mask_abs_epi32 (__W,__U,__A);
 }
 
 __m512i test_mm512_maskz_abs_epi32 (__mmask16 __U, __m512i __A)
 {
-  // CHECK-LABEL: @test_mm512_maskz_abs_epi32 
+  // CHECK-LABEL: @test_mm512_maskz_abs_epi32
   // CHECK: [[SUB:%.*]] = sub <16 x i32> zeroinitializer, [[A:%.*]]
   // CHECK: [[CMP:%.*]] = icmp sgt <16 x i32> [[A]], zeroinitializer
   // CHECK: [[SEL:%.*]] = select <16 x i1> [[CMP]], <16 x i32> [[A]], <16 x i32> [[SUB]]
+  // CHECK: [[TMP:%.*]] = bitcast <16 x i32> [[SEL]] to <8 x i64>
+  // CHECK: [[SEL:%.*]] = bitcast <8 x i64> [[TMP]] to <16 x i32>
   // CHECK: select <16 x i1> %{{.*}}, <16 x i32> [[SEL]], <16 x i32> %{{.*}}
   return _mm512_maskz_abs_epi32 (__U,__A);
 }
Index: cfe/trunk/test/CodeGen/avx512-reduceMinMaxIntrin.c
===
--- cfe/trunk/test/CodeGen/avx512-reduceMinMaxIntrin.c
+++ cfe/trunk/test/CodeGen/avx512-reduceMinMaxIntrin.c
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -ffreestanding %s -O0 -triple=x86_64-apple-darwin -target-cpu skylake-avx512 -emit-llvm -o - -Wall -Werror | FileCheck %s
+// RUN: %clang_cc1 -fexperimental-new-pass-manager -ffreestanding %s -O0 -triple=x86_64-apple-darwin -target-cpu skylake-avx512 -emit-llvm -o - -Wall -Werror | FileCheck %s
 
 #include 
 
@@ -27,10 +27,10 @@
 // CHECK-NEXT:store <8 x i64> [[SHUFFLE_I]], <8 x i64>* [[__T1_I]], align 64
 // CHECK-NEXT:[[TMP3:%.*]] = load <8 x i64>, <8 x i64>* [[__V_ADDR_I]], align 64
 // CHECK-NEXT:[[TMP4:%.*]] = load <8 x i64>, <8 x i64>* [[__T1_I]], align 64
-// CHECK-NEXT:store <8 x i64> [[TMP3]], <8 x i64>* [[__A_ADDR_I_I]], align 64
-// CHECK-NEXT:store <8 x i64> [[TMP4]], <8 x i64>* [[__B_ADDR_I_I]], align 64
-// CHECK-NEXT:[[TMP5:%.*]] = load <8 x i64>, <8 x i64>* [[__A_ADDR_I_I]], align 64
-// CHECK-NEXT:[[TMP6:%.*]] = load <8 x i64>, <8 x i64>* [[__B_ADDR_I_I]], align 64
+// CHECK-NEXT:store <8 x i64> [[TMP3]], <8 x i64>* [[__A_ADDR_I7_I]], align 64
+// CHECK-NEXT:store <8 x i64> [[TMP4]], <8 x i64>* [[__B_ADDR_I8_I]], align 64
+// CHECK-NEXT:[[TMP5:%.*]] = load <8 x i64>, <8 x i64>* [[__A_ADDR_I7_I]], align 64
+// CHECK-NEXT:[[TMP6:%.*]] = load <8 x i64>, <8 x i64>* [[__B_ADDR_I8_I]], align 64
 // CHECK-NEXT:[[TMP7:%.*]] = icmp sgt <8 x i64> [[TMP5]], [[TMP6]]
 // CHECK-NEXT:[[TMP8:%.*]] = select <8 x i1> [[TMP7]], <8 x i64> [[TMP5]], <8 x i64> [[TMP6]]
 // CHECK-NEXT:store <8 x i64> [[TMP8]], <8 x i64>* [[__T2_I]], align 64
@@ -40,10 +40,10 @@
 // CHECK-NEXT:store <8 x i64> [[SHUFFLE1_I]], <8 x i64>* [[__T3_I]], align 64
 // CHECK-NEXT:[[TMP11:%.*]] = load <8 x i64>, <8 x i64>* [[__T2_I]], align 64
 // CHECK-NEXT:[[TMP12:%.*]] = load <8 x i64>, <8 x i64>* [[__T3_I]], al

r367157 - [NewPM] Run avx*-builtins.c tests under the new pass manager only

[Leonard Chan via cfe-commits]

Author: leonardchan
Date: Fri Jul 26 14:19:37 2019
New Revision: 367157

URL: http://llvm.org/viewvc/llvm-project?rev=367157&view=rev
Log:
[NewPM] Run avx*-builtins.c tests under the new pass manager only

This patch changes the following tests to run under the new pass manager only:

```
Clang :: CodeGen/avx512-reduceMinMaxIntrin.c (1 of 4)
Clang :: CodeGen/avx512vl-builtins.c (2 of 4)
Clang :: CodeGen/avx512vlbw-builtins.c (3 of 4)
Clang :: CodeGen/avx512f-builtins.c (4 of 4)
```

The new PM added extra bitcasts that weren't checked before. For
reduceMinMaxIntrin.c, the issue was mostly the alloca's being in a different
order. Other changes involved extra bitcasts, and differently ordered loads and
stores, but the logic should still be the same.

Differential revision: https://reviews.llvm.org/D65110

Modified:
cfe/trunk/test/CodeGen/avx512-reduceMinMaxIntrin.c
cfe/trunk/test/CodeGen/avx512f-builtins.c
cfe/trunk/test/CodeGen/avx512vl-builtins.c
cfe/trunk/test/CodeGen/avx512vlbw-builtins.c

Modified: cfe/trunk/test/CodeGen/avx512-reduceMinMaxIntrin.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/avx512-reduceMinMaxIntrin.c?rev=367157&r1=367156&r2=367157&view=diff
==
--- cfe/trunk/test/CodeGen/avx512-reduceMinMaxIntrin.c (original)
+++ cfe/trunk/test/CodeGen/avx512-reduceMinMaxIntrin.c Fri Jul 26 14:19:37 2019
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -ffreestanding %s -O0 -triple=x86_64-apple-darwin 
-target-cpu skylake-avx512 -emit-llvm -o - -Wall -Werror | FileCheck %s
+// RUN: %clang_cc1 -fexperimental-new-pass-manager -ffreestanding %s -O0 
-triple=x86_64-apple-darwin -target-cpu skylake-avx512 -emit-llvm -o - -Wall 
-Werror | FileCheck %s
 
 #include 
 
@@ -27,10 +27,10 @@
 // CHECK-NEXT:store <8 x i64> [[SHUFFLE_I]], <8 x i64>* [[__T1_I]], align 
64
 // CHECK-NEXT:[[TMP3:%.*]] = load <8 x i64>, <8 x i64>* [[__V_ADDR_I]], 
align 64
 // CHECK-NEXT:[[TMP4:%.*]] = load <8 x i64>, <8 x i64>* [[__T1_I]], align 
64
-// CHECK-NEXT:store <8 x i64> [[TMP3]], <8 x i64>* [[__A_ADDR_I_I]], align 
64
-// CHECK-NEXT:store <8 x i64> [[TMP4]], <8 x i64>* [[__B_ADDR_I_I]], align 
64
-// CHECK-NEXT:[[TMP5:%.*]] = load <8 x i64>, <8 x i64>* [[__A_ADDR_I_I]], 
align 64
-// CHECK-NEXT:[[TMP6:%.*]] = load <8 x i64>, <8 x i64>* [[__B_ADDR_I_I]], 
align 64
+// CHECK-NEXT:store <8 x i64> [[TMP3]], <8 x i64>* [[__A_ADDR_I7_I]], 
align 64
+// CHECK-NEXT:store <8 x i64> [[TMP4]], <8 x i64>* [[__B_ADDR_I8_I]], 
align 64
+// CHECK-NEXT:[[TMP5:%.*]] = load <8 x i64>, <8 x i64>* [[__A_ADDR_I7_I]], 
align 64
+// CHECK-NEXT:[[TMP6:%.*]] = load <8 x i64>, <8 x i64>* [[__B_ADDR_I8_I]], 
align 64
 // CHECK-NEXT:[[TMP7:%.*]] = icmp sgt <8 x i64> [[TMP5]], [[TMP6]]
 // CHECK-NEXT:[[TMP8:%.*]] = select <8 x i1> [[TMP7]], <8 x i64> [[TMP5]], 
<8 x i64> [[TMP6]]
 // CHECK-NEXT:store <8 x i64> [[TMP8]], <8 x i64>* [[__T2_I]], align 64
@@ -40,10 +40,10 @@
 // CHECK-NEXT:store <8 x i64> [[SHUFFLE1_I]], <8 x i64>* [[__T3_I]], align 
64
 // CHECK-NEXT:[[TMP11:%.*]] = load <8 x i64>, <8 x i64>* [[__T2_I]], align 
64
 // CHECK-NEXT:[[TMP12:%.*]] = load <8 x i64>, <8 x i64>* [[__T3_I]], align 
64
-// CHECK-NEXT:store <8 x i64> [[TMP11]], <8 x i64>* [[__A_ADDR_I7_I]], 
align 64
-// CHECK-NEXT:store <8 x i64> [[TMP12]], <8 x i64>* [[__B_ADDR_I8_I]], 
align 64
-// CHECK-NEXT:[[TMP13:%.*]] = load <8 x i64>, <8 x i64>* 
[[__A_ADDR_I7_I]], align 64
-// CHECK-NEXT:[[TMP14:%.*]] = load <8 x i64>, <8 x i64>* 
[[__B_ADDR_I8_I]], align 64
+// CHECK-NEXT:store <8 x i64> [[TMP11]], <8 x i64>* [[__A_ADDR_I5_I]], 
align 64
+// CHECK-NEXT:store <8 x i64> [[TMP12]], <8 x i64>* [[__B_ADDR_I6_I]], 
align 64
+// CHECK-NEXT:[[TMP13:%.*]] = load <8 x i64>, <8 x i64>* 
[[__A_ADDR_I5_I]], align 64
+// CHECK-NEXT:[[TMP14:%.*]] = load <8 x i64>, <8 x i64>* 
[[__B_ADDR_I6_I]], align 64
 // CHECK-NEXT:[[TMP15:%.*]] = icmp sgt <8 x i64> [[TMP13]], [[TMP14]]
 // CHECK-NEXT:[[TMP16:%.*]] = select <8 x i1> [[TMP15]], <8 x i64> 
[[TMP13]], <8 x i64> [[TMP14]]
 // CHECK-NEXT:store <8 x i64> [[TMP16]], <8 x i64>* [[__T4_I]], align 64
@@ -53,10 +53,10 @@
 // CHECK-NEXT:store <8 x i64> [[SHUFFLE3_I]], <8 x i64>* [[__T5_I]], align 
64
 // CHECK-NEXT:[[TMP19:%.*]] = load <8 x i64>, <8 x i64>* [[__T4_I]], align 
64
 // CHECK-NEXT:[[TMP20:%.*]] = load <8 x i64>, <8 x i64>* [[__T5_I]], align 
64
-// CHECK-NEXT:store <8 x i64> [[TMP19]], <8 x i64>* [[__A_ADDR_I5_I]], 
align 64
-// CHECK-NEXT:store <8 x i64> [[TMP20]], <8 x i64>* [[__B_ADDR_I6_I]], 
align 64
-// CHECK-NEXT:[[TMP21:%.*]] = load <8 x i64>, <8 x i64>* 
[[__A_ADDR_I5_I]], align 64
-// CHECK-NEXT:[[TMP22:%.*]] = load <8 x i64>, <8 x i64>* 
[[__B_ADDR_I6_I]], align 64
+// CHECK-NEXT:store <8 x i64> [[TMP19]], <8 x i64>* [[__A_ADDR_I_I]], 
align 64
+// CHECK-NEXT:store <8 x i64> [[TMP

[PATCH] D65110: [NewPM] Run avx*-builtins.c tests under the new pass manager only

[Craig Topper via Phabricator via cfe-commits]

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

LGTM


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65110/new/

https://reviews.llvm.org/D65110



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

[PATCH] D65270: [CMake] Fix source path generation for install in multi-config (MSBuild)

[Chris Bieneman via Phabricator via cfe-commits]

beanz requested changes to this revision.
beanz added inline comments.
This revision now requires changes to proceed.



Comment at: clang/lib/Headers/CMakeLists.txt:190
 
+if(CMAKE_CONFIGURATION_TYPES)
+  string(REPLACE "${CMAKE_CFG_INTDIR}" "$" output_dir "${output_dir}")

I think this will break Xcode


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65270/new/

https://reviews.llvm.org/D65270



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

[PATCH] D65349: [analyzer] Be more careful with destructors of non-regions.

[Artem Dergachev via Phabricator via cfe-commits]

NoQ created this revision.
NoQ added reviewers: dcoughlin, xazax.hun, a_sidorin, rnkovacs, Szelethus, 
baloghadamsoftware, Charusso.
Herald added subscribers: cfe-commits, dkrupp, donat.nagy, mikhail.ramalho, 
a.sidorin, szepet.
Herald added a project: clang.

It turns out that we crash all over the place when we try to evaluate 
destructors over concrete-int-but-not-null locations.

Add some defensive code.


Repository:
  rC Clang

https://reviews.llvm.org/D65349

Files:
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h
  clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
  clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
  clang/test/Analysis/dtor.cpp

Index: clang/test/Analysis/dtor.cpp
===
--- clang/test/Analysis/dtor.cpp
+++ clang/test/Analysis/dtor.cpp
@@ -540,3 +540,33 @@
   clang_analyzer_eval(__alignof(NonTrivial) > 0); // expected-warning{{TRUE}}
 }
 }
+
+namespace dtor_over_loc_concrete_int {
+struct A {
+  ~A() {}
+};
+
+struct B {
+  A a;
+  ~B() {}
+};
+
+struct C : A {
+  ~C() {}
+};
+
+void testB() {
+  B *b = (B *)-1;
+  b->~B(); // no-crash
+}
+
+void testC() {
+  C *c = (C *)-1;
+  c->~C(); // no-crash
+}
+
+void testAutoDtor() {
+  const A &a = *(A *)-1;
+  // no-crash
+}
+} // namespace dtor_over_loc_concrete_int
Index: clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
===
--- clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
+++ clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
@@ -603,7 +603,7 @@
 bool IsBaseDtor,
 ExplodedNode *Pred,
 ExplodedNodeSet &Dst,
-const EvalCallOptions &CallOpts) {
+EvalCallOptions &CallOpts) {
   assert(S && "A destructor without a trigger!");
   const LocationContext *LCtx = Pred->getLocationContext();
   ProgramStateRef State = Pred->getState();
@@ -611,7 +611,6 @@
   const CXXRecordDecl *RecordDecl = ObjectType->getAsCXXRecordDecl();
   assert(RecordDecl && "Only CXXRecordDecls should have destructors");
   const CXXDestructorDecl *DtorDecl = RecordDecl->getDestructor();
-
   // FIXME: There should always be a Decl, otherwise the destructor call
   // shouldn't have been added to the CFG in the first place.
   if (!DtorDecl) {
@@ -625,9 +624,22 @@
 return;
   }
 
+  if (!Dest) {
+CallOpts.IsCtorOrDtorWithImproperlyModeledTargetRegion = true;
+if (const Expr *E = dyn_cast_or_null(S)) {
+  Dest = MRMgr.getCXXTempObjectRegion(E, Pred->getLocationContext());
+} else {
+  static SimpleProgramPointTag T("ExprEngine", "SkipInvalidDestructor");
+  NodeBuilder Bldr(Pred, Dst, *currBldrCtx);
+  Bldr.generateSink(Pred->getLocation().withTag(&T),
+Pred->getState(), Pred);
+  return;
+}
+  }
+
   CallEventManager &CEMgr = getStateManager().getCallEventManager();
   CallEventRef Call =
-CEMgr.getCXXDestructorCall(DtorDecl, S, Dest, IsBaseDtor, State, LCtx);
+  CEMgr.getCXXDestructorCall(DtorDecl, S, Dest, IsBaseDtor, State, LCtx);
 
   PrettyStackTraceLoc CrashInfo(getContext().getSourceManager(),
 Call->getSourceRange().getBegin(),
Index: clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
===
--- clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
+++ clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
@@ -977,8 +977,8 @@
   Region = makeZeroElementRegion(state, loc::MemRegionVal(Region), varType,
  CallOpts.IsArrayCtorOrDtor).getAsRegion();
 
-  VisitCXXDestructor(varType, Region, Dtor.getTriggerStmt(), /*IsBase=*/ false,
- Pred, Dst, CallOpts);
+  VisitCXXDestructor(varType, Region, Dtor.getTriggerStmt(),
+ /*IsBase=*/false, Pred, Dst, CallOpts);
 }
 
 void ExprEngine::ProcessDeleteDtor(const CFGDeleteDtor Dtor,
@@ -1036,8 +1036,9 @@
   SVal BaseVal = getStoreManager().evalDerivedToBase(ThisVal, BaseTy,
  Base->isVirtual());
 
-  VisitCXXDestructor(BaseTy, BaseVal.castAs().getRegion(),
- CurDtor->getBody(), /*IsBase=*/ true, Pred, Dst, {});
+  EvalCallOptions CallOpts;
+  VisitCXXDestructor(BaseTy, BaseVal.getAsRegion(), CurDtor->getBody(),
+ /*IsBase=*/true, Pred, Dst, CallOpts);
 }
 
 void ExprEngine::ProcessMemberDtor(const CFGMemberDtor D,
@@ -1050,18 +1051,18 @@
   const auto *CurDtor = cast(LCtx->getDecl());
   Loc ThisVal = getSValBuilder().getCXXThis(CurDtor,
 LCtx->getStackFrame());
-  SVal FieldVal =
-  State->getLValue(Member, State->getSVal(ThisVal).castAs());
+  Loc ThisLoc = State->getSVal(ThisVal).castAs();
+  SVal FieldLoc = State->getLValue(Member, ThisLoc);
 
   // FIXME: We need to 

[PATCH] D64666: [Sema] Enable -Wimplicit-float-conversion for integral to floating point precision loss

[Dávid Bolvanský via Phabricator via cfe-commits]

xbolva00 accepted this revision.
xbolva00 added a comment.

Nice simple fix :) thanks


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64666/new/

https://reviews.llvm.org/D64666



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

[PATCH] D65345: [analyzer] exploded-graph-rewriter: Implement manual graph trimming.

[Csaba Dabis via Phabricator via cfe-commits]

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

It is a great idea, thanks!




Comment at: clang/utils/analyzer/exploded-graph-rewriter.py:918
+# TargetedTrimmer keeps paths that lead to specific nodes and discards all
+# other paths. Useful when you cannot use -trim-egraph (eg., when debugging
+# a crash).

Extra comma at `(eg.,`



Comment at: clang/utils/analyzer/exploded-graph-rewriter.py:989
+parser.add_argument('--to', type=str, default=None,
+help='display only execution paths from the root '
+ 'to the given comma-separated list of nodes '

`only display` for consistency with the above arguments.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65345/new/

https://reviews.llvm.org/D65345



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

[PATCH] D65302: [clang][docs][release notes] mention asm goto support

[Nick Desaulniers via Phabricator via cfe-commits]

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

Thanks for the tips, how does that look @hans ?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65302/new/

https://reviews.llvm.org/D65302



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

[PATCH] D65302: [clang][docs][release notes] mention asm goto support

[Nick Desaulniers via Phabricator via cfe-commits]

nickdesaulniers updated this revision to Diff 212002.
nickdesaulniers added a comment.
Herald added a reviewer: alexshap.

- add details about ClangBuiltLinux


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65302/new/

https://reviews.llvm.org/D65302

Files:
  clang/docs/ReleaseNotes.rst


Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -111,6 +111,12 @@
   in all C-family languages. This macro is similar to ``__FILE__`` except it
   will always provide the last path component when possible.
 
+- Initial support for ``asm goto`` statements (a GNU C extension) has been
+  added for control flow from inline assembly to labels. The main consumers of
+  this construct are the Linux kernel (CONFIG_JUMP_LABEL=y) and glib. There are
+  still a few unsupported corner cases in Clang's integrated assembler and
+  IfConverter. Please file bugs for any issues you run into.
+
 - ...
 
 C11 Feature Support
@@ -242,6 +248,33 @@
 Significant Known Problems
 ==
 
+Linux Kernel
+
+
+With support for asm goto, the mainline Linux kernel for x86_64 is now 
buildable
+(and bootable) with Clang-9.  Other architectures that don't require
+CONFIG_JUMP_LABEL=y such as arm, aarch64, ppc32, ppc64le, (and possibly mips)
+have been supported with older releases of Clang (clang-4 was first used with
+aarch64).
+
+The Android and ChromeOS Linux distributions have moved to building their Linux
+kernels with Clang, and Google is currently testing Clang built kernels for
+their production Linux kernels.
+
+Further, LLD, llvm-objcopy, llvm-ar, llvm-nm, llvm-objdump can all be used to
+build a working Linux kernel.
+
+More information about building Linux kernels with Clang can be found:
+
+- `ClangBuiltLinux web page `_.
+- `Issue Tracker `_.
+- `Wiki `_.
+- `Mailing List `_.
+- `Bi-weekly Meeting 
`_.
+- #clangbuiltlinux on Freenode.
+- `Clang Meta bug `_.
+- `Continuous Integration 
`_.
+
 Additional Information
 ==
 


Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -111,6 +111,12 @@
   in all C-family languages. This macro is similar to ``__FILE__`` except it
   will always provide the last path component when possible.
 
+- Initial support for ``asm goto`` statements (a GNU C extension) has been
+  added for control flow from inline assembly to labels. The main consumers of
+  this construct are the Linux kernel (CONFIG_JUMP_LABEL=y) and glib. There are
+  still a few unsupported corner cases in Clang's integrated assembler and
+  IfConverter. Please file bugs for any issues you run into.
+
 - ...
 
 C11 Feature Support
@@ -242,6 +248,33 @@
 Significant Known Problems
 ==
 
+Linux Kernel
+
+
+With support for asm goto, the mainline Linux kernel for x86_64 is now buildable
+(and bootable) with Clang-9.  Other architectures that don't require
+CONFIG_JUMP_LABEL=y such as arm, aarch64, ppc32, ppc64le, (and possibly mips)
+have been supported with older releases of Clang (clang-4 was first used with
+aarch64).
+
+The Android and ChromeOS Linux distributions have moved to building their Linux
+kernels with Clang, and Google is currently testing Clang built kernels for
+their production Linux kernels.
+
+Further, LLD, llvm-objcopy, llvm-ar, llvm-nm, llvm-objdump can all be used to
+build a working Linux kernel.
+
+More information about building Linux kernels with Clang can be found:
+
+- `ClangBuiltLinux web page `_.
+- `Issue Tracker `_.
+- `Wiki `_.
+- `Mailing List `_.
+- `Bi-weekly Meeting `_.
+- #clangbuiltlinux on Freenode.
+- `Clang Meta bug `_.
+- `Continuous Integration `_.
+
 Additional Information
 ==
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D65249: [NFC] use C++11 in AlignOf.h

[JF Bastien via Phabricator via cfe-commits]

jfb added a subscriber: BillyONeal.
jfb added a comment.

In D65249#1603133 , @rnk wrote:

> I still think this concern applies:
>  https://reviews.llvm.org/D64417#1576675
>
> I'm not sure how to track down an 19.11 release to test if we can pass 
> std::aligned_storage values through function calls on x86. We might be better 
> off raising the minimum to 19.14, which is a more recent MSVC release in the 
> 2017 track. I don't think it's too much to ask developers to use the most 
> recent version of the 2017 compiler, they won't have to change IDEs.


@BillyONeal do you know if 19.11 has the `aligned_storage` issue on x86?

If it does then indeed we should raise the minimum version, I'll send an RFC.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65249/new/

https://reviews.llvm.org/D65249



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

[PATCH] D65000: [ARM] Set default alignment to 64bits

[Francis Visoiu Mistrih via Phabricator via cfe-commits]

thegameg added inline comments.



Comment at: cfe/trunk/test/CodeGen/ARM/exception-alignment.cpp:9
+// A16-NEXT: store <2 x i64> , <2 x i64>* [[BC]], align 16
+#include 
+

thakis wrote:
> This fails on some bots:
> 
> http://lab.llvm.org:8011/builders/clang-atom-d525-fedora-rel/builds/26891/steps/ninja%20check%201/logs/FAIL%3A%20Clang%3A%3Aexception-alignment.cpp
> 
> ```
> In file included from 
> /export/users/atombot/llvm/clang-atom-d525-fedora-rel/llvm/tools/clang/test/CodeGen/ARM/exception-alignment.cpp:9:
> In file included from 
> /export/users/atombot/llvm/clang-atom-d525-fedora-rel/stage1/lib/clang/10.0.0/include/arm_neon.h:31:
> In file included from 
> /export/users/atombot/llvm/clang-atom-d525-fedora-rel/stage1/lib/clang/10.0.0/include/stdint.h:52:
> In file included from /usr/include/stdint.h:26:
> In file included from /usr/include/bits/libc-header-start.h:33:
> In file included from /usr/include/features.h:452:
> /usr/include/gnu/stubs.h:7:11: fatal error: 'gnu/stubs-32.h' file not found
> # include 
>   ^~~~
> 1 error generated.
> FileCheck error: '-' is empty.
> FileCheck command line:  
> /export/users/atombot/llvm/clang-atom-d525-fedora-rel/stage1/bin/FileCheck 
> --check-prefixes=CHECK,A16 
> /export/users/atombot/llvm/clang-atom-d525-fedora-rel/llvm/tools/clang/test/CodeGen/ARM/exception-alignment.cpp
> 
> --
> ```
It also fails on Darwin:

http://green.lab.llvm.org/green/job/clang-stage1-cmake-RA-incremental/245/consoleFull

```
Command Output (stderr):
--
In file included from 
/Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/llvm-project/clang/test/CodeGen/ARM/exception-alignment.cpp:9:
In file included from 
/Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/clang-build/lib/clang/10.0.0/include/arm_neon.h:31:
In file included from 
/Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/clang-build/lib/clang/10.0.0/include/stdint.h:52:
In file included from /usr/include/stdint.h:52:
In file included from /usr/include/sys/_types.h:32:
/usr/include/sys/cdefs.h:763:2: error: Unsupported architecture
#error Unsupported architecture
 ^
In file included from 
/Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/llvm-project/clang/test/CodeGen/ARM/exception-alignment.cpp:9:
In file included from 
/Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/clang-build/lib/clang/10.0.0/include/arm_neon.h:31:
In file included from 
/Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/clang-build/lib/clang/10.0.0/include/stdint.h:52:
In file included from /usr/include/stdint.h:52:
In file included from /usr/include/sys/_types.h:33:
/usr/include/machine/_types.h:34:2: error: architecture not supported
#error architecture not supported
 ^
```


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65000/new/

https://reviews.llvm.org/D65000



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

[PATCH] D64666: [Sema] Enable -Wimplicit-float-conversion for integral to floating point precision loss

[Ziang Wan via Phabricator via cfe-commits]

ziangwan updated this revision to Diff 212001.
ziangwan added a comment.

Update diff.

1. Silence the warning when C++11 narrowing is in effect on intialization-list 
expression.
2. Add test cases to test "no duplicated warnings for c++11 narrowing"
3. Updated test cases to handle 32-bit host machine.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64666/new/

https://reviews.llvm.org/D64666

Files:
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaChecking.cpp
  clang/test/Sema/conversion.c
  clang/test/Sema/ext_vector_casts.c
  clang/test/Sema/implicit-int-float-conversion.c
  clang/test/Sema/implicit-int-float-narrowing.cpp

Index: clang/test/Sema/implicit-int-float-narrowing.cpp
===
--- /dev/null
+++ clang/test/Sema/implicit-int-float-narrowing.cpp
@@ -0,0 +1,10 @@
+// RUN: %clang_cc1 %s -verify -Wno-conversion -Wno-c++11-narrowing -Wimplicit-int-float-conversion
+
+void testNoWarningOnNarrowing() {
+  // Test that we do not issue duplicated warnings for
+  // C++11 narrowing.
+  float a = {L}; // expected-no-diagnostics
+
+  long b = L;
+  float c = {b}; // expected-no-diagnostics
+}
Index: clang/test/Sema/implicit-int-float-conversion.c
===
--- /dev/null
+++ clang/test/Sema/implicit-int-float-conversion.c
@@ -0,0 +1,53 @@
+// RUN: %clang_cc1 %s -verify -Wno-conversion -Wimplicit-int-float-conversion
+
+long testReturn(long a, float b) {
+  return a + b; // expected-warning {{implicit conversion from 'long' to 'float' may lose precision}}
+}
+
+void testAssignment() {
+  float f = 22;
+  double b = L;
+
+#ifndef __ILP32__
+  float ff = L;// expected-warning {{implicit conversion from 'long' to 'float' changes value from  to 1312}}
+  float  = UL; // expected-warning {{implicit conversion from 'unsigned long' to 'float' changes value from  to 1312}}
+#else
+  float ff = L;// expected-warning {{implicit conversion from 'long long' to 'float' changes value from  to 1312}}
+  float  = UL; // expected-warning {{implicit conversion from 'unsigned long long' to 'float' changes value from  to 1312}}
+#endif
+
+  long l = L;
+  float fff = l; // expected-warning {{implicit conversion from 'long' to 'float' may lose precision}}
+}
+
+void testExpression() {
+  float a = 0.0f;
+
+#ifndef __ILP32__
+  float b = L + a; // expected-warning {{implicit conversion from 'long' to 'float' changes value from  to 1312}}
+#else
+  float b = L + a; // expected-warning {{implicit conversion from 'long long' to 'float' changes value from  to 1312}}
+#endif
+
+  float g =  + ;
+  float c =  + 2223; // expected-warning {{implicit conversion from 'int' to 'float' changes value from 4445 to }}
+
+  int i = 0;
+  float d = i + a; // expected-warning {{implicit conversion from 'int' to 'float' may lose precision}}
+
+  double e = 0.0;
+  double f = i + e;
+}
+
+void testCNarrowing() {
+  // Since this is a C file. C++11 narrowing is not in effect.
+  // In this case, we should issue warnings.
+#ifndef __ILP32__
+  float a = {L}; // expected-warning {{implicit conversion from 'long' to 'float' changes value from  to 1312}}
+#else
+  float a = {L};   // expected-warning {{implicit conversion from 'long long' to 'float' changes value from  to 1312}}
+#endif
+
+  long b = L;
+  float c = {b}; // expected-warning {{implicit conversion from 'long' to 'float' may lose precision}}
+}
Index: clang/test/Sema/ext_vector_casts.c
===
--- clang/test/Sema/ext_vector_casts.c
+++ clang/test/Sema/ext_vector_casts.c
@@ -115,12 +115,12 @@
   vl = vl + t; // expected-warning {{implicit conversion loses integer precision}}
   
   vf = 1 + vf;
-  vf = l + vf;
+  vf = l + vf; // expected-warning {{implicit conversion from 'long' to 'float2' (vector of 2 'float' values) may lose precision}}
   vf = 2.0 + vf;
   vf = d + vf; // expected-warning {{implicit conversion loses floating-point precision}}
-  vf = vf + 0x;
+  vf = vf + 0x; // expected-warning {{implicit conversion from 'unsigned int' to 'float2' (vector of 2 'float' values) changes value from 4294967295 to 4294967296}}
   vf = vf + 2.1; // expected-warning {{implicit conversion loses floating-point precision}}
-  
-  vd = l + vd;
-  vd = vd + t;
+
+  vd = l + vd; // expected-warning {{implicit conversion from 'long' to 'double2' (vector of 2 'double' values) may lose precision}}
+  vd = vd + t; // expected-warning {{implicit conversion from '__uint

Re: r367134 - [Sema] Fix -Wuninitialized for struct assignment from GNU C statement expression

[Hans Wennborg via cfe-commits]

Merged to release_90 in r367150.

On Fri, Jul 26, 2019 at 10:28 AM Nathan Huckleberry via cfe-commits
 wrote:
>
> Author: nathan-huckleberry
> Date: Fri Jul 26 10:29:35 2019
> New Revision: 367134
>
> URL: http://llvm.org/viewvc/llvm-project?rev=367134&view=rev
> Log:
> [Sema] Fix -Wuninitialized for struct assignment from GNU C statement 
> expression
>
> Summary:
> Do not automatically report self references of structs in statement expression
> as warnings. Instead wait for uninitialized cfg analysis.
> https://bugs.llvm.org/show_bug.cgi?id=42604
>
> Reviewers: aaron.ballman, rsmith, nickdesaulniers
>
> Reviewed By: aaron.ballman, nickdesaulniers
>
> Subscribers: nathanchance, cfe-commits
>
> Tags: #clang
>
> Differential Revision: https://reviews.llvm.org/D64678
>
> Added:
> cfe/trunk/test/Sema/warn-uninitialized-statement-expression.c
> 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=367134&r1=367133&r2=367134&view=diff
> ==
> --- cfe/trunk/lib/Sema/SemaDecl.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaDecl.cpp Fri Jul 26 10:29:35 2019
> @@ -11257,9 +11257,12 @@ void Sema::AddInitializerToDecl(Decl *Re
>// Check for self-references within variable initializers.
>// Variables declared within a function/method body (except for references)
>// are handled by a dataflow analysis.
> -  if (!VDecl->hasLocalStorage() || VDecl->getType()->isRecordType() ||
> -  VDecl->getType()->isReferenceType()) {
> -CheckSelfReference(*this, RealDecl, Init, DirectInit);
> +  // This is undefined behavior in C++, but valid in C.
> +  if (getLangOpts().CPlusPlus) {
> +if (!VDecl->hasLocalStorage() || VDecl->getType()->isRecordType() ||
> +VDecl->getType()->isReferenceType()) {
> +  CheckSelfReference(*this, RealDecl, Init, DirectInit);
> +}
>}
>
>// If the type changed, it means we had an incomplete type that was
>
> Added: cfe/trunk/test/Sema/warn-uninitialized-statement-expression.c
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/warn-uninitialized-statement-expression.c?rev=367134&view=auto
> ==
> --- cfe/trunk/test/Sema/warn-uninitialized-statement-expression.c (added)
> +++ cfe/trunk/test/Sema/warn-uninitialized-statement-expression.c Fri Jul 26 
> 10:29:35 2019
> @@ -0,0 +1,56 @@
> +// RUN: %clang_cc1 -fsyntax-only -Wuninitialized -verify %s
> +
> +void init(int *);
> +
> +void foo(void) {
> +  int i = ({
> +init(&i);
> +i;
> +  });
> +}
> +
> +void foo_bad(void) {
> +  int i = ({
> +int z = i; // expected-warning{{variable 'i' is uninitialized when used 
> within its own initialization}}
> +init(&i);
> +i;
> +  });
> +}
> +
> +struct widget {
> +  int x, y;
> +};
> +void init2(struct widget *);
> +
> +void bar(void) {
> +  struct widget my_widget = ({
> +init2(&my_widget);
> +my_widget;
> +  });
> +  struct widget a = (init2(&a), a);
> +}
> +
> +void bar_bad(void) {
> +  struct widget my_widget = ({
> +struct widget z = my_widget; // expected-warning{{variable 'my_widget' 
> is uninitialized when used within its own initialization}}
> +int x = my_widget.x; //FIXME: There should be an uninitialized 
> warning here
> +init2(&my_widget);
> +my_widget;
> +  });
> +}
> +
> +void baz(void) {
> +  struct widget a = ({
> +struct widget b = ({
> +  b = a; // expected-warning{{variable 'a' is uninitialized when used 
> within its own initialization}}
> +});
> +a;
> +  });
> +}
> +
> +void f(void) {
> +  struct widget *a = ({
> +init2(a); // expected-warning{{variable 'a' is uninitialized when used 
> within its own initialization}}
> +a;
> +  });
> +}
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Alexey Bataev via Phabricator via cfe-commits]

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

Looks good in general, but commit the runtime part at first.




Comment at: test/OpenMP/declare_mapper_codegen.cpp:44-48
+// CK0-DAG: store i8* %0, i8** [[HANDLEADDR:%[^,]+]]
+// CK0-DAG: store i8* %1, i8** [[BPTRADDR:%[^,]+]]
+// CK0-DAG: store i8* %2, i8** [[VPTRADDR:%[^,]+]]
+// CK0-DAG: store i64 %3, i{{64|32}}* [[SIZEADDR:%[^,]+]]
+// CK0-DAG: store i64 %4, i64* [[TYPEADDR:%[^,]+]]

I would not rely on the predetermined indices here, better to use some kind of 
patterns here just like in other places.



Comment at: test/OpenMP/declare_mapper_codegen.cpp:289-293
+// CK1-DAG: store i8* %0, i8** [[HANDLEADDR:%[^,]+]]
+// CK1-DAG: store i8* %1, i8** [[BPTRADDR:%[^,]+]]
+// CK1-DAG: store i8* %2, i8** [[VPTRADDR:%[^,]+]]
+// CK1-DAG: store i64 %3, i{{64|32}}* [[SIZEADDR:%[^,]+]]
+// CK1-DAG: store i64 %4, i64* [[TYPEADDR:%[^,]+]]

Same here


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59474/new/

https://reviews.llvm.org/D59474



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

[PATCH] D65249: [NFC] use C++11 in AlignOf.h

[Reid Kleckner via Phabricator via cfe-commits]

rnk added a comment.

I still think this concern applies:
https://reviews.llvm.org/D64417#1576675

I'm not sure how to track down an 19.11 release to test if we can pass 
std::aligned_storage values through function calls on x86. We might be better 
off raising the minimum to 19.14, which is a more recent MSVC release in the 
2017 track. I don't think it's too much to ask developers to use the most 
recent version of the 2017 compiler, they won't have to change IDEs.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65249/new/

https://reviews.llvm.org/D65249



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

r367149 - [CodeGen] fix test that broke with rL367146

[Sanjay Patel via cfe-commits]

Author: spatel
Date: Fri Jul 26 13:36:57 2019
New Revision: 367149

URL: http://llvm.org/viewvc/llvm-project?rev=367149&view=rev
Log:
[CodeGen] fix test that broke with rL367146

This should be fixed properly to not depend on LLVM (so much).

Modified:
cfe/trunk/test/CodeGen/complex-math.c

Modified: cfe/trunk/test/CodeGen/complex-math.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/complex-math.c?rev=367149&r1=367148&r2=367149&view=diff
==
--- cfe/trunk/test/CodeGen/complex-math.c (original)
+++ cfe/trunk/test/CodeGen/complex-math.c Fri Jul 26 13:36:57 2019
@@ -1,3 +1,5 @@
+// FIXME: This file should not be using -O1; that makes it depend on the 
entire LLVM IR optimizer.
+
 // RUN: %clang_cc1 %s -O1 -fno-experimental-new-pass-manager -emit-llvm 
-triple x86_64-unknown-unknown -o - | FileCheck %s --check-prefix=X86
 // RUN: %clang_cc1 %s -O1 -fno-experimental-new-pass-manager -emit-llvm 
-triple x86_64-pc-win64 -o - | FileCheck %s --check-prefix=X86
 // RUN: %clang_cc1 %s -O1 -fno-experimental-new-pass-manager -emit-llvm 
-triple i686-unknown-unknown -o - | FileCheck %s --check-prefix=X86
@@ -147,10 +149,9 @@ float _Complex div_float_rc(float a, flo
   //
   // BC = 0
   // AARCH64-FASTMATH: [[AD:%.*]] = fmul fast float [[D]], %a
-  // AARCH64-FASTMATH: [[BCmAD:%.*]] = fsub fast float -0.00e+00, [[AD]]
-  //
-  // AARCH64-FASTMATH: fdiv fast float [[AC]], [[CCpDD]]
-  // AARCH64-FASTMATH: fdiv fast float [[BCmAD]], [[CCpDD]]
+  // AARCH64-FASTMATH: [[BCmAD:%.*]] = fdiv fast float [[AC]], [[CCpDD]]
+  // AARCH64-FASTMATH: [[DIV:%.*]] = fdiv fast float [[AD]], [[CCpDD]]
+  // AARCH64-FASTMATH: fsub fast float -0.00e+00, [[DIV]]
   // AARCH64-FASTMATH: ret
   return a / b;
 }
@@ -325,10 +326,9 @@ double _Complex div_double_rc(double a,
   //
   // BC = 0
   // AARCH64-FASTMATH: [[AD:%.*]] = fmul fast double [[D]], %a
-  // AARCH64-FASTMATH: [[BCmAD:%.*]] = fsub fast double -0.00e+00, [[AD]]
-  //
-  // AARCH64-FASTMATH: fdiv fast double [[AC]], [[CCpDD]]
-  // AARCH64-FASTMATH: fdiv fast double [[BCmAD]], [[CCpDD]]
+  // AARCH64-FASTMATH: [[BCmAD:%.*]] = fdiv fast double [[AC]], [[CCpDD]]
+  // AARCH64-FASTMATH: [[DIV:%.*]] = fdiv fast double [[AD]], [[CCpDD]]
+  // AARCH64-FASTMATH: fsub fast double -0.00e+00, [[DIV]]
   // AARCH64-FASTMATH: ret
   return a / b;
 }
@@ -521,10 +521,9 @@ long double _Complex div_long_double_rc(
   //
   // BC = 0
   // AARCH64-FASTMATH: [[AD:%.*]] = fmul fast fp128 [[D]], %a
-  // AARCH64-FASTMATH: [[BCmAD:%.*]] = fsub fast fp128 
0xL8000, [[AD]]
-  //
-  // AARCH64-FASTMATH: fdiv fast fp128 [[AC]], [[CCpDD]]
-  // AARCH64-FASTMATH: fdiv fast fp128 [[BCmAD]], [[CCpDD]]
+  // AARCH64-FASTMATH: [[BCmAD:%.*]] = fdiv fast fp128 [[AC]], [[CCpDD]]
+  // AARCH64-FASTMATH: [[DIV:%.*]] = fdiv fast fp128 [[AD]], [[CCpDD]]
+  // AARCH64-FASTMATH: fsub fast fp128 0xL8000, 
[[DIV]]
   // AARCH64-FASTMATH: ret
   return a / b;
 }


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

[PATCH] D65343: [clang-tidy] Fix the documentation for linuxkernel-must-use-errs.

[Eugene Zelenko via Phabricator via cfe-commits]

Eugene.Zelenko added a comment.

Sorry, I didn't notice that D59963  was 
committed. In general it's not good idea to commit changes when patch was not 
approved.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65343/new/

https://reviews.llvm.org/D65343



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

r367147 - Partially revert rC365414; `ln -n` is not portable

[Hubert Tong via cfe-commits]

Author: hubert.reinterpretcast
Date: Fri Jul 26 13:09:37 2019
New Revision: 367147

URL: http://llvm.org/viewvc/llvm-project?rev=367147&view=rev
Log:
Partially revert rC365414; `ln -n` is not portable

This restores the use of `rm` instead of the non-portable `ln -n`. Such
use being the status quo for the 12-month period between rC334972 and
rC365414.

Modified:
cfe/trunk/test/Driver/no-canonical-prefixes.c

Modified: cfe/trunk/test/Driver/no-canonical-prefixes.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/no-canonical-prefixes.c?rev=367147&r1=367146&r2=367147&view=diff
==
--- cfe/trunk/test/Driver/no-canonical-prefixes.c (original)
+++ cfe/trunk/test/Driver/no-canonical-prefixes.c Fri Jul 26 13:09:37 2019
@@ -4,10 +4,11 @@
 // RUN: cd %t.real
 // RUN: ln -sf %clang test-clang
 // RUN: cd ..
-// If %.fake already is a symlink to %t.real when `ln -sf %t.real %t.fake`
-// runs, then that would symlink %t.real to itself, forming a cycle.
-// The `-n` flag prevents this.
-// RUN: ln -sfn %t.real %t.fake
+// Important to remove %t.fake: If it already is a symlink to %t.real when
+// `ln -sf %t.real %t.fake` runs, then that would symlink %t.real to itself,
+// forming a cycle.
+// RUN: rm -f %t.fake
+// RUN: ln -sf %t.real %t.fake
 // RUN: cd %t.fake
 // RUN: ./test-clang -v -S %s 2>&1 | FileCheck --check-prefix=CANONICAL %s
 // RUN: ./test-clang -v -S %s -no-canonical-prefixes 2>&1 | FileCheck 
--check-prefix=NON-CANONICAL %s


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

[PATCH] D65343: [clang-tidy] Fix the documentation for linuxkernel-must-use-errs.

[Eugene Zelenko via Phabricator via cfe-commits]

Eugene.Zelenko added a comment.

Looks OK, but please make this changes in D59963 
.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65343/new/

https://reviews.llvm.org/D65343



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

[PATCH] D65250: [analyzer] exploded-graph-rewriter: Improve user-friendliness.

[Csaba Dabis via Phabricator via cfe-commits]

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

I like the HTML output, thanks!




Comment at: clang/utils/analyzer/exploded-graph-rewriter.py:846
+print('  $ dot -Tsvg input.dot -o output.svg')
+print()
+write_temp_file('.dot', self.output())

Why we need multiple prints to print one message? According to the Stack 
Overflow:
```
print("""
Line1
Line2
""")
```

Link: 
https://stackoverflow.com/questions/34980251/how-to-print-multiple-lines-of-text-with-python



Comment at: clang/utils/analyzer/exploded-graph-rewriter.py:953
+ 'displaying it, dump the rewritten dot file '
+ 'to stdout')
 args = parser.parse_args()

This flag is a little-bit too long and does not really emphasize what it 
suppose to do. What about just `--dump` or `--stdout`?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65250/new/

https://reviews.llvm.org/D65250



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

[PATCH] D65344: [analyzer] exploded-graph-rewriter: NFC: Replace explorers with trimmers.

[Artem Dergachev via Phabricator via cfe-commits]

NoQ updated this revision to Diff 211992.
NoQ added a comment.

Fxd.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65344/new/

https://reviews.llvm.org/D65344

Files:
  clang/test/Analysis/exploded-graph-rewriter/explorers.dot
  clang/test/Analysis/exploded-graph-rewriter/trimmers.dot
  clang/utils/analyzer/exploded-graph-rewriter.py


Index: clang/utils/analyzer/exploded-graph-rewriter.py
===
--- clang/utils/analyzer/exploded-graph-rewriter.py
+++ clang/utils/analyzer/exploded-graph-rewriter.py
@@ -882,37 +882,36 @@
 visitor.visit_end_of_graph()
 
 
-# SinglePathExplorer traverses only a single path - the leftmost path
-# from the root. Useful when the trimmed graph is still too large
-# due to a large amount of equivalent reports.
-class SinglePathExplorer(object):
-def __init__(self):
-super(SinglePathExplorer, self).__init__()
+#===---===#
+# Trimmers cut out parts of the ExplodedGraph so that to focus on other parts.
+# Trimmers can be combined together by applying them sequentially.
+#===---===#
 
-def explore(self, graph, visitor):
-visitor.visit_begin_graph(graph)
 
-# Keep track of visited nodes in order to avoid loops.
-visited = set()
+# SinglePathTrimmer keeps only a single path - the leftmost path from the root.
+# Useful when the trimmed graph is still too large.
+class SinglePathTrimmer(object):
+def __init__(self):
+super(SinglePathTrimmer, self).__init__()
+
+def trim(self, graph):
+visited_nodes = set()
 node_id = graph.root_id
 while True:
-visited.add(node_id)
+visited_nodes.add(node_id)
 node = graph.nodes[node_id]
-logging.debug('Visiting ' + node_id)
-visitor.visit_node(node)
-if len(node.successors) == 0:
-break
-
-succ_id = node.successors[0]
-succ = graph.nodes[succ_id]
-logging.debug('Visiting edge: %s -> %s ' % (node_id, succ_id))
-visitor.visit_edge(node, succ)
-if succ_id in visited:
+if len(node.successors) > 0:
+succ_id = node.successors[0]
+succ = graph.nodes[succ_id]
+node.successors = [succ_id]
+succ.predecessors = [node_id]
+if succ_id in visited_nodes:
+break
+node_id = succ_id
+else:
 break
-
-node_id = succ_id
-
-visitor.visit_end_of_graph()
+graph.nodes = {node_id: graph.nodes[node_id]
+   for node_id in visited_nodes}
 
 
 #===---===#
@@ -960,10 +959,18 @@
 raw_line = raw_line.strip()
 graph.add_raw_line(raw_line)
 
-explorer = SinglePathExplorer() if args.single_path else BasicExplorer()
+trimmers = []
+if args.single_path:
+trimmers.append(SinglePathTrimmer())
+
+explorer = BasicExplorer()
+
 visitor = DotDumpVisitor(args.diff, args.dark, args.gray, args.topology,
  args.rewrite_only)
 
+for trimmer in trimmers:
+trimmer.trim(graph)
+
 explorer.explore(graph, visitor)
 
 


Index: clang/utils/analyzer/exploded-graph-rewriter.py
===
--- clang/utils/analyzer/exploded-graph-rewriter.py
+++ clang/utils/analyzer/exploded-graph-rewriter.py
@@ -882,37 +882,36 @@
 visitor.visit_end_of_graph()
 
 
-# SinglePathExplorer traverses only a single path - the leftmost path
-# from the root. Useful when the trimmed graph is still too large
-# due to a large amount of equivalent reports.
-class SinglePathExplorer(object):
-def __init__(self):
-super(SinglePathExplorer, self).__init__()
+#===---===#
+# Trimmers cut out parts of the ExplodedGraph so that to focus on other parts.
+# Trimmers can be combined together by applying them sequentially.
+#===---===#
 
-def explore(self, graph, visitor):
-visitor.visit_begin_graph(graph)
 
-# Keep track of visited nodes in order to avoid loops.
-visited = set()
+# SinglePathTrimmer keeps only a single path - the leftmost path from the root.
+# Useful when the trimmed graph is still too large.
+class SinglePathTrimmer(object):
+def __init__(self):
+super(SinglePathTrimmer, self).__init__()
+
+def trim(self, graph):
+visited_nodes = set()
 node_id = graph.root_id
 while True:
-visited.add(node_id)
+visited_nodes.add(node_id)
 n

[PATCH] D65344: [analyzer] exploded-graph-rewriter: NFC: Replace explorers with trimmers.

[Csaba Dabis via Phabricator via cfe-commits]

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

In my mind an explorer would trim me a graph so I like the new abstraction to 
differentiate the two. Thanks!




Comment at: clang/utils/analyzer/exploded-graph-rewriter.py:892
+# SinglePathTrimmer keeps only a single path - the leftmost path from the root.
+# from the root. Useful when the trimmed graph is still too large.
+class SinglePathTrimmer(object):

`from the root.` duplicated from the above line.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65344/new/

https://reviews.llvm.org/D65344



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

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh updated this revision to Diff 211991.
lildmh added a comment.

Make `emitUDMapperArrayInitOrDel` private


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59474/new/

https://reviews.llvm.org/D59474

Files:
  include/clang/AST/GlobalDecl.h
  lib/AST/ASTContext.cpp
  lib/CodeGen/CGDecl.cpp
  lib/CodeGen/CGOpenMPRuntime.cpp
  lib/CodeGen/CGOpenMPRuntime.h
  lib/CodeGen/ModuleBuilder.cpp
  test/OpenMP/declare_mapper_codegen.cpp

Index: test/OpenMP/declare_mapper_codegen.cpp
===
--- test/OpenMP/declare_mapper_codegen.cpp
+++ test/OpenMP/declare_mapper_codegen.cpp
@@ -1,92 +1,414 @@
-///==///
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap %s
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap %s
-
-// RUN: %clang_cc1 -verify -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -verify -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-
 // SIMD-ONLY0-NOT: {{__kmpc|__tgt}}
 
 // expected-no-diagnostics
 #ifndef HEADER
 #define HEADER
 
+///==///
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix CK0 --check-prefix CK0-64 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -femit-all-decls -disable-llvm-passes -include-pch %t -verify %s -emit-llvm -o - | FileCheck --check-prefix CK0 --check-prefix CK0-64 %s
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix CK0 --check-prefix CK0-32 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -femit-all-decls -disable-llvm-passes -include-pch %t -verify %s -emit-llvm -o - | FileCheck --check-prefix CK0 --check-prefix CK0-32 %s
+
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix SIMD-ONLY0 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopenmp-simd -fopenmp-tar

[PATCH] D65270: [CMake] Fix source path generation for install in multi-config (MSBuild)

[Petr Hosek via Phabricator via cfe-commits]

phosek added a comment.

LGTM, @beanz and @smeenai do you have any further comments?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65270/new/

https://reviews.llvm.org/D65270



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

[PATCH] D64380: Add 'require_designated_init' and 'required' attribute to clang

[Emmett Neyman via Phabricator via cfe-commits]

emmettneyman updated this revision to Diff 211988.
emmettneyman marked 6 inline comments as done.
emmettneyman added a comment.

Addressed comments and feedback


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64380/new/

https://reviews.llvm.org/D64380

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/Misc/pragma-attribute-supported-attributes-list.test
  clang/test/SemaCXX/attr-requires-designator.cpp
  clang/test/SemaCXX/attr-requires-init.cpp

Index: clang/test/SemaCXX/attr-requires-init.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/attr-requires-init.cpp
@@ -0,0 +1,86 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+
+[[clang::requires_init]] int x;// expected-warning{{'requires_init' attribute only applies to non-static data members}}
+[[clang::requires_init]] void fun(int x) { // expected-warning{{'requires_init' attribute only applies to non-static data members}}
+  return;
+}
+struct [[clang::requires_init]] Foo { // expected-warning{{'requires_init' attribute only applies to non-static data members}}
+  int x;
+};
+
+// Struct with one required field
+struct Bar {
+  [[clang::requires_init]] int y; // expected-note 0+ {{enforced by 'requires_init' attribute here}}
+};
+
+// The following are invalid ways of initializing instances of this struct.
+Bar b1;// expected-warning{{initializer for variable b1 must explicitly initialize field y}}
+Bar b2{};  // expected-warning{{initializer for variable b2 must explicitly initialize field y}}
+Bar b3{1}; // expected-warning{{initializer for variable b3 must explicitly initialize field y}}
+
+// The following are valid ways of initializing instances of this struct.
+Bar b6{.y = 1};
+
+// Struct with multiple required fields
+struct Baz {
+  [[clang::requires_init]] int x; // expected-note 0+ {{enforced by 'requires_init' attribute here}}
+  int y;
+  [[clang::requires_init]] int z; // expected-note 0+ {{enforced by 'requires_init' attribute here}}
+};
+
+// The following are invalid ways of initializing instances of this struct.
+Baz z1; // expected-warning{{initializer for variable z1 must explicitly initialize field x}} expected-warning{{initializer for variable z1 must explicitly initialize field z}}
+Baz z2{};   // expected-warning{{initializer for variable z2 must explicitly initialize field x}} expected-warning{{initializer for variable z2 must explicitly initialize field z}}
+Baz z3{1, 2};   // expected-warning{{initializer for variable z3 must explicitly initialize field x}} expected-warning{{initializer for variable z3 must explicitly initialize field z}}
+Baz z4{1, 2, 3};// expected-warning{{initializer for variable z4 must explicitly initialize field x}} expected-warning{{initializer for variable z4 must explicitly initialize field z}}
+Baz z5{.x = 1, 2};  // expected-warning{{initializer for variable z5 must explicitly initialize field z}}
+Baz z6{.x = 1, .y = 2}; // expected-warning{{initializer for variable z6 must explicitly initialize field z}}
+
+// The following are valid ways of initializing instances of this struct.
+Baz z7{.x = 1, .y = 2, .z = 3};
+Baz z8{.x = 1, .z = 3};
+Baz z9{.x = 1, 2, .z = 3};
+
+// The requires_init attribute can also be applied to public fields of classes.
+class Cla {
+public:
+  [[clang::requires_init]] int x; // expected-note 0+ {{enforced by 'requires_init' attribute here}}
+  int y;
+};
+
+// The following are invalid ways of initializing instances of this class.
+Cla c1;// expected-warning{{initializer for variable c1 must explicitly initialize field x}}
+Cla c2{};  // expected-warning{{initializer for variable c2 must explicitly initialize field x}}
+Cla c3{1}; // expected-warning{{initializer for variable c3 must explicitly initialize field x}}
+Cla c4{1, 2};  // expected-warning{{initializer for variable c4 must explicitly initialize field x}}
+Cla c5{1, .y = 2}; // expected-warning{{initializer for variable c5 must explicitly initialize field x}}
+
+// The following are valid ways of initializing instances of this class.
+Cla c6{.x = 1};
+Cla c7{.x = 1, .y = 2};
+Cla c8{.x = 1, 2};
+
+// This attribute cannot be applied to fields of a union.
+union Uni {
+  [[clang::requires_init]] int x; // expected-warning{{'requires_init' attribute ignored}}
+  int y;
+};
+
+// If any of the fields in the record are non-public all requires_init
+// attributes in the record are ignored.
+struct PriMems {
+  [[clang::requires_init]] int x; // expected-warning{{'requires_init' attribute ignored}}
+private:
+  int y;
+};
+PriMems pm1;
+PriMems pm2();
+
+class PriClass {
+  int x;
+public:
+  [[clang::requires_in

[PATCH] D65345: [analyzer] exploded-graph-rewriter: Implement manual graph trimming.

[Artem Dergachev via Phabricator via cfe-commits]

NoQ created this revision.
NoQ added reviewers: dcoughlin, xazax.hun, a_sidorin, rnkovacs, Szelethus, 
baloghadamsoftware, Charusso.
Herald added subscribers: cfe-commits, dkrupp, donat.nagy, mikhail.ramalho, 
a.sidorin, szepet.
Herald added a project: clang.
NoQ added a parent revision: D65344: [analyzer] exploded-graph-rewriter: NFC: 
Replace explorers with trimmers..

When `-trim-egraph` is unavailable (say, when you're debugging a crash on a 
real-world code that takes too long to reduce), it makes sense to view the 
untrimmed graph up to the crashing node's predecessor, then dump the ID (or a 
pointer) of the node in the attached debugger, and then trim the dumped graph 
in order to keep only paths from the root to the node.

Implement the last part of that plan. Now you can do:

  $ exploded-graph-rewriter.py ExprEngine.dot --to 0x12229acd0

And it'll chop out the unnecessary chunks of the graph. You can also specify 
multiple nodes and you can specify nodes by stable IDs rather than by pointers.


Repository:
  rC Clang

https://reviews.llvm.org/D65345

Files:
  clang/test/Analysis/exploded-graph-rewriter/trimmers.dot
  clang/utils/analyzer/exploded-graph-rewriter.py

Index: clang/utils/analyzer/exploded-graph-rewriter.py
===
--- clang/utils/analyzer/exploded-graph-rewriter.py
+++ clang/utils/analyzer/exploded-graph-rewriter.py
@@ -914,6 +914,52 @@
for node_id in visited_nodes}
 
 
+# TargetedTrimmer keeps paths that lead to specific nodes and discards all
+# other paths. Useful when you cannot use -trim-egraph (eg., when debugging
+# a crash).
+class TargetedTrimmer(object):
+def __init__(self, target_nodes):
+super(TargetedTrimmer, self).__init__()
+self._target_nodes = target_nodes
+
+@staticmethod
+def parse_target_node(node, graph):
+if node.startswith('0x'):
+ret = 'Node' + node
+assert ret in graph.nodes
+return ret
+else:
+for other_id in graph.nodes:
+other = graph.nodes[other_id]
+if other.node_id == int(node):
+return other_id
+
+@staticmethod
+def parse_target_nodes(target_nodes, graph):
+return [TargetedTrimmer.parse_target_node(node, graph)
+for node in target_nodes.split(',')]
+
+def trim(self, graph):
+queue = self._target_nodes
+visited_nodes = set()
+
+while len(queue) > 0:
+node_id = queue.pop()
+visited_nodes.add(node_id)
+node = graph.nodes[node_id]
+for pred_id in node.predecessors:
+if pred_id not in visited_nodes:
+queue.append(pred_id)
+graph.nodes = {node_id: graph.nodes[node_id]
+   for node_id in visited_nodes}
+for node_id in graph.nodes:
+node = graph.nodes[node_id]
+node.successors = [succ_id for succ_id in node.successors
+   if succ_id in visited_nodes]
+node.predecessors = [succ_id for succ_id in node.predecessors
+ if succ_id in visited_nodes]
+
+
 #===---===#
 # The entry point to the script.
 #===---===#
@@ -939,6 +985,11 @@
 help='only display the leftmost path in the graph '
  '(useful for trimmed graphs that still '
  'branch too much)')
+parser.add_argument('--to', type=str, default=None,
+help='display only execution paths from the root '
+ 'to the given comma-separated list of nodes '
+ 'identified by a pointer or a stable ID; '
+ 'compatible with --single-path')
 parser.add_argument('--dark', action='store_const', dest='dark',
 const=True, default=False,
 help='dark mode')
@@ -960,6 +1011,9 @@
 graph.add_raw_line(raw_line)
 
 trimmers = []
+if args.to is not None:
+trimmers.append(TargetedTrimmer(
+TargetedTrimmer.parse_target_nodes(args.to, graph)))
 if args.single_path:
 trimmers.append(SinglePathTrimmer())
 
Index: clang/test/Analysis/exploded-graph-rewriter/trimmers.dot
===
--- clang/test/Analysis/exploded-graph-rewriter/trimmers.dot
+++ clang/test/Analysis/exploded-graph-rewriter/trimmers.dot
@@ -1,7 +1,17 @@
 // RUN: %exploded_graph_rewriter %s \
-// RUN: | FileCheck %s -check-prefixes=CHECK,BASIC
+// RUN: | FileCheck %s -check-prefixes=ONE,TWO,THREE,FOUR
 // RUN: %exploded_graph_rewriter -s %s \
-// RUN: | FileCheck %s -check-prefixes=CHECK,SINGLE
+// R

[PATCH] D64380: Add 'require_designated_init' and 'required' attribute to clang

[Emmett Neyman via Phabricator via cfe-commits]

emmettneyman marked 16 inline comments as done.
emmettneyman added inline comments.



Comment at: clang/include/clang/Basic/Attr.td:1948
+def RequiresDesignator : InheritableAttr {
+  let Spellings = [Clang<"requires_designator">, GCC<"designated_init">];
+  let Subjects = SubjectList<[Record]>;

aaron.ballman wrote:
> Why does this have a `Clang` spelling in addition to the `GCC` spelling? I 
> think it only needs the `GCC` spelling.
I kept the `Clang` spelling so that there's naming consistency between the two 
attributes (`requires_designator` and `requires_init`). I can remove it if it's 
redundant/unnecessary, let me know.



Comment at: clang/include/clang/Basic/AttrDocs.td:1484-1485
+requires designated initializers be used rather than positional initializers.
+This attribute additionally has a stronger restriction that declarations must 
be
+brace-initialized (which is why ``Foo foo;`` is considered invalid above. The
+final way this attribute differs from GCC's ``designated_init`` attribute is

aaron.ballman wrote:
> Why is it valuable to differ from GCC's behavior in this regard?
The motivation behind GCC's attribute seems to be to avoid using positional 
arguments:
> The intent of this attribute is to allow the programmer to indicate that a 
> structure’s layout may change, and that therefore relying on positional 
> initialization will result in future breakage.

The motivation behind this attribute is a little bit different. Instead of 
avoiding the use of positional arguments, the goal of this attribute is to 
bring ObjC-style named parameters to C/C++ and to be able to enforce their use 
in certain situations. In line with this goal, we wanted to forbid the 
following pattern:
```
Foo foo;
foo.x = 42;
foo.y = 36;
```
That's why this attribute enforces that all declarations be brace-initialized.



Comment at: clang/include/clang/Basic/AttrDocs.td:1487
+final way this attribute differs from GCC's ``designated_init`` attribute is
+that it can be applied to union and class types, as well as struct types.
+  }];

aaron.ballman wrote:
> Given that it can be added to class types, I wonder what the behavior should 
> be for code like:
> ```
> struct Foo {
>   int a = 1;
>   int b, c;
>   int d = 4;
> };
> 
> Foo foo = {...};
> ```
> Does the initializer for `foo` have to specify `.a` and `.d`?
The `requires_designator` attribute doesn't require that any of the fields have 
to be specified, only that designated initializer syntax has to be used. So, 
for the struct definition above, any of the following are valid:
```
Foo foo {};
Foo foo {.a = 1, .b = 2, .c = 3, .d = 4};
Foo foo {.b = 2, .c = 3};
```
Any of the fields can be left out and default-initialized. I've added this 
example to the lit tests for the attribute.



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:3537
+def note_declared_requires_designator_here : Note<
+  "required by 'requires_designator' attribute here">;
+def warn_requires_init_failed : Warning<

aaron.ballman wrote:
> This attribute spelling seems wrong, it should be `designated_init`, no?
Does it make more sense to use `designated_init` or `requires_designator` as 
the primary spelling for this attribute? I chose to use the 
`requires_designator` spelling so that the two attributes have consistent and 
similar spellings. Let me know if you think it should be the other way around 
(or if you want the `Clang` spelling removed entirely).



Comment at: clang/lib/Sema/SemaDecl.cpp:11216
+// If the type of the declaration is a struct/class and that type has the
+// require_designated_init attribute, check that the initializer has
+// the proper designated initializer syntax.

aaron.ballman wrote:
> Attribute spelling is stale in this comment.
See comments above about keeping this spelling.



Comment at: clang/lib/Sema/SemaDecl.cpp:15314
 
+  // If this TagDecl has any non-public fields, all requires_designator and
+  // requires_init attributes should be ignored.

aaron.ballman wrote:
> Attribute name is stale in this comment.
> 
> This is the wrong place to do this work -- it should be done from 
> SemaDeclAttr.cpp when processing the attribute. We should avoid adding the 
> attribute in the first place rather than adding the attribute and then later 
> removing it.
See question above regarding attribute spelling.

I thought about this a lot because I agree, it feels wrong to remove the 
attribute once it is already added to a field, struct, etc. However I could not 
think of any other way or any other place to do this check. Since all fields of 
the struct need to have been processed already in order to check whether there 
are any non-public members, it seems like the only place to do this check is at 
the end of handling the entire `TagDecl`. When the struct-

[PATCH] D64454: [clang-tidy] Adding static analyzer check to list of clang-tidy checks

[Nathan Huckleberry via Phabricator via cfe-commits]

Nathan-Huckleberry updated this revision to Diff 211987.
Nathan-Huckleberry added a comment.

- Order swap and elif


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64454/new/

https://reviews.llvm.org/D64454

Files:
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-core.CallAndMessage.rst
  clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-core.DivideZero.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-core.DynamicTypePropagation.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-core.NonNullParamChecker.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-core.NullDereference.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-core.StackAddressEscape.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-core.UndefinedBinaryOperatorResult.rst
  clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-core.VLASize.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-core.uninitialized.ArraySubscript.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-core.uninitialized.Assign.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-core.uninitialized.Branch.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-core.uninitialized.CapturedBlockVariable.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-core.uninitialized.UndefReturn.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-cplusplus.InnerPointer.rst
  clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-cplusplus.Move.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-cplusplus.NewDelete.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-cplusplus.NewDeleteLeaks.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-deadcode.DeadStores.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-nullability.NullPassedToNonnull.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-nullability.NullReturnedFromNonnull.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-nullability.NullableDereferenced.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-nullability.NullablePassedToNonnull.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-nullability.NullableReturnedFromNonnull.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-optin.cplusplus.UninitializedObject.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-optin.cplusplus.VirtualCall.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-optin.mpi.MPI-Checker.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-optin.osx.OSObjectCStyleCast.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-optin.osx.cocoa.localizability.EmptyLocalizationContextChecker.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-optin.osx.cocoa.localizability.NonLocalizedStringChecker.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-optin.performance.GCDAntipattern.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-optin.performance.Padding.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-optin.portability.UnixAPI.rst
  clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-osx.API.rst
  clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-osx.MIG.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-osx.NumberObjectConversion.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-osx.OSObjectRetainCount.rst
  clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-osx.ObjCProperty.rst
  clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-osx.SecKeychainAPI.rst
  clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-osx.cocoa.AtSync.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-osx.cocoa.AutoreleaseWrite.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-osx.cocoa.ClassRelease.rst
  clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-osx.cocoa.Dealloc.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-osx.cocoa.IncompatibleMethodTypes.rst
  clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-osx.cocoa.Loops.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-osx.cocoa.MissingSuperCall.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-osx.cocoa.NSAutoreleasePool.rst
  clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-osx.cocoa.NSError.rst
  clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-osx.cocoa.NilArg.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-osx.cocoa.NonNilReturnValue.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-osx.cocoa.ObjCGenerics.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-osx.cocoa.RetainCount.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-osx.cocoa.RunLoopAutoreleaseLeak.rst
  clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-osx.cocoa.SelfInit.rst
  
clang-tools-ex

[PATCH] D65308: [NFC][clang] Refactor getCompilationPhases()+Types.def step 3.

[Aaron Ballman via Phabricator via cfe-commits]

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

LGTM!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65308/new/

https://reviews.llvm.org/D65308



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

[PATCH] D62731: [RFC] Add support for options -fp-model= and -fp-speculation= : specify floating point behavior

[Kevin P. Neal via Phabricator via cfe-commits]

kpn added a comment.

I actually don't have much of an opinion on what the command line argument form 
should be. It may be helpful for it to be the same as one of the commonly 
deployed compilers. The worst I think would be pretty close but with subtle 
differences. So if it can be made to work like Intel's compiler I'm fine with 
that. But I'm hoping that more people in the community chime in since having a 
consensus would be best. Personally, I'm not yet giving any final sign-offs to 
tickets since I don't think I've been here long enough.

As far as the rounding metadata argument, the language reference says this:

> For values other than “round.dynamic” optimization passes may assume that the 
> actual runtime rounding mode (as defined in a target-specific manner) matches 
> the specified rounding mode, but this is not guaranteed. Using a specific 
> non-dynamic rounding mode which does not match the actual rounding mode at 
> runtime results in undefined behavior.

Be aware that currently neither of the metadata arguments does anything. They 
get dropped when llvm reaches the SelectionDAG. And none of the optimization 
passes that run before that know anything about constrained intrinsics at all. 
This means they treat code that has them conservatively. Preserving and using 
that metadata in the optimization passes and getting it down and used by the MI 
layer is planned but hasn't happened yet. So the full set of arguments may not 
make sense yet, but an on/off switch for strict mode hopefully does.




Comment at: llvm/lib/IR/FPState.cpp:78
+  }
+
+  Builder.setIsFPConstrained(IsConstrainedExcept || IsConstrainedRounding);

mibintc wrote:
> kpn wrote:
> > The IRBuilder already has defaults for exception behavior and rounding. Is 
> > it a good idea to duplicate that knowledge here? Worse, what's here is 
> > different from what's in the IRBuilder. Why not ask the IRBuilder what its 
> > current setting is and use that?
> > 
> > Would it make sense to have setters/getters, and then have a separate 
> > updateBuilder() method? We still don't have a good way to get the #pragma 
> > down to the lower levels of clang. The current, unfinished, attempt doesn't 
> > work for C++ templates and I'm told other cases as well. An updateBuilder() 
> > method could be helpful when moving from one scope to another. But keep in 
> > mind that if any constrained fp math is used in a function then the entire 
> > function has to be constrained.
> > 
> > Given that last bit, it may make more sense to have the support somewhere 
> > higher level than as a wrapper around the IRBuilder. Maybe in 
> > CodeGenFunction or CodeGenModule? I've not spent much time in clang so I'm 
> > not sure if that makes sense or not.
> Yes I absolutely don't want to duplicate, and I will submit another version 
> of this patch and i'll be removing fpstate*.  I do want to be able to make 
> the fp-model options match the same behavior as icc is using.  One reason i 
> wanted to keep track of the state within a separate object is because i was 
> uncertain if stuff would be going on in the IR builder which would be 
> changing the settings, for whatever reason, and i'd want to put them back 
> into settings specified by the command line options before creating the 
> constrained intrinsics in clang/codegen. 
> 
> let me work on this patch more, i just did a quick update to the latest 
> before sending this up.
> 
> As far as pragmas versus templates, this is a concern.  Is there something I 
> can read to learn more about the issue?  Pragma's are used in OpenMP so there 
> must be a way to have pragma's interact politely with templates?  Knowing 
> very little, I thought that the pragma would be held as a _Pragma, sort of 
> like a function call, within the intermediate representation e.g. as opposed 
> to a token stream from the preprocessor and I didn't think there would be a 
> problem with templates per se. I'll check with other folks here at Intel. 
> There was  a concern about inlining constrained intrinsics into a function 
> because of your rule about whole function body but nobody mentioned a problem 
> with templates.
See "https://reviews.llvm.org/D52839";, "Inform AST's UnaryOperator of 
FENV_ACCESS". It was there that Richard Smith brought up the issue of 
templates. I've been prioritizing work on the llvm end and haven't had a chance 
to get to understand how the relevant parts on the clang side work myself. My 
hope is that maybe command line arguments can go in to enable strict FP on a 
compilation-wide basis, with support for the #pragma coming later. But I don't 
know if it will work out that way.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D62731/new/

https://reviews.llvm.org/D62731



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

[PATCH] D65344: [analyzer] exploded-graph-rewriter: NFC: Replace explorers with trimmers.

[Artem Dergachev via Phabricator via cfe-commits]

NoQ created this revision.
NoQ added a reviewer: Charusso.
Herald added subscribers: cfe-commits, dkrupp, donat.nagy, Szelethus, 
mikhail.ramalho, a.sidorin, szepet, baloghadamsoftware, xazax.hun.
Herald added a project: clang.

Explorers aren't the right abstraction. For the purposes of displaying svg 
files we don't care in which order do we explore the nodes. We may care about 
this for other analyses, but we're not there yet.

The function of cutting out chunks of the graph is performed poorly by the 
explorers, because querying predecessors/successors on the explored nodes 
yields original successors/predecessors even if they aren't being explored.

Introduce a new entity, "trimmers", that do one thing but to it right: cut out 
chunks of the graph. Trimmers mutate the graph, so stale edges aren't even 
visible to their consumers in the pipeline. Additionally, trimmers are 
intrinsically composable: multiple trimmers can be applied to the graph 
sequentially.

Refactor the single-path explorer into the single-path trimmer. Rename the test 
file for consistency.


Repository:
  rC Clang

https://reviews.llvm.org/D65344

Files:
  clang/test/Analysis/exploded-graph-rewriter/explorers.dot
  clang/test/Analysis/exploded-graph-rewriter/trimmers.dot
  clang/utils/analyzer/exploded-graph-rewriter.py


Index: clang/utils/analyzer/exploded-graph-rewriter.py
===
--- clang/utils/analyzer/exploded-graph-rewriter.py
+++ clang/utils/analyzer/exploded-graph-rewriter.py
@@ -882,37 +882,36 @@
 visitor.visit_end_of_graph()
 
 
-# SinglePathExplorer traverses only a single path - the leftmost path
-# from the root. Useful when the trimmed graph is still too large
-# due to a large amount of equivalent reports.
-class SinglePathExplorer(object):
-def __init__(self):
-super(SinglePathExplorer, self).__init__()
+#===---===#
+# Trimmers cut out parts of the ExplodedGraph so that to focus on other parts.
+# Trimmers can be combined together by applying them sequentially.
+#===---===#
 
-def explore(self, graph, visitor):
-visitor.visit_begin_graph(graph)
 
-# Keep track of visited nodes in order to avoid loops.
-visited = set()
+# SinglePathTrimmer keeps only a single path - the leftmost path from the root.
+# from the root. Useful when the trimmed graph is still too large.
+class SinglePathTrimmer(object):
+def __init__(self):
+super(SinglePathTrimmer, self).__init__()
+
+def trim(self, graph):
+visited_nodes = set()
 node_id = graph.root_id
 while True:
-visited.add(node_id)
+visited_nodes.add(node_id)
 node = graph.nodes[node_id]
-logging.debug('Visiting ' + node_id)
-visitor.visit_node(node)
-if len(node.successors) == 0:
-break
-
-succ_id = node.successors[0]
-succ = graph.nodes[succ_id]
-logging.debug('Visiting edge: %s -> %s ' % (node_id, succ_id))
-visitor.visit_edge(node, succ)
-if succ_id in visited:
+if len(node.successors) > 0:
+succ_id = node.successors[0]
+succ = graph.nodes[succ_id]
+node.successors = [succ_id]
+succ.predecessors = [node_id]
+if succ_id in visited_nodes:
+break
+node_id = succ_id
+else:
 break
-
-node_id = succ_id
-
-visitor.visit_end_of_graph()
+graph.nodes = {node_id: graph.nodes[node_id]
+   for node_id in visited_nodes}
 
 
 #===---===#
@@ -960,10 +959,18 @@
 raw_line = raw_line.strip()
 graph.add_raw_line(raw_line)
 
-explorer = SinglePathExplorer() if args.single_path else BasicExplorer()
+trimmers = []
+if args.single_path:
+trimmers.append(SinglePathTrimmer())
+
+explorer = BasicExplorer()
+
 visitor = DotDumpVisitor(args.diff, args.dark, args.gray, args.topology,
  args.rewrite_only)
 
+for trimmer in trimmers:
+trimmer.trim(graph)
+
 explorer.explore(graph, visitor)
 
 


Index: clang/utils/analyzer/exploded-graph-rewriter.py
===
--- clang/utils/analyzer/exploded-graph-rewriter.py
+++ clang/utils/analyzer/exploded-graph-rewriter.py
@@ -882,37 +882,36 @@
 visitor.visit_end_of_graph()
 
 
-# SinglePathExplorer traverses only a single path - the leftmost path
-# from the root. Useful when the trimmed graph is still too large
-# due to a large amount of equivalent reports.
-class SinglePathExplorer(object):
-def __init__(self)

[PATCH] D65341: [OpenMP] Add support for close map modifier in Clang

[Gheorghe-Teodor Bercea via Phabricator via cfe-commits]

gtbercea marked 2 inline comments as done.
gtbercea added inline comments.



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:7695
   Flags &= ~(OMP_MAP_TO | OMP_MAP_FROM | OMP_MAP_ALWAYS |
- OMP_MAP_DELETE);
+ OMP_MAP_DELETE | OMP_MAP_CLOSE);
 

ABataev wrote:
> Why?
If the pointee has been mapped as TO/FROM/etc already no need to map it 
TO/FROM/etc again.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65341/new/

https://reviews.llvm.org/D65341



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

[PATCH] D64958: [clang-doc] Fix link generation

[Diego Astiazarán via Phabricator via cfe-commits]

DiegoAstiazaran updated this revision to Diff 211979.
DiegoAstiazaran edited the summary of this revision.
DiegoAstiazaran added a comment.

Change attribute used to check special case of global namespace; IsPathValid 
changed to IsInGlobalNamespace. This attribute is true when its first parent is 
the global namespace or if the info is the global namespace,


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64958/new/

https://reviews.llvm.org/D64958

Files:
  clang-tools-extra/clang-doc/BitcodeReader.cpp
  clang-tools-extra/clang-doc/BitcodeWriter.cpp
  clang-tools-extra/clang-doc/BitcodeWriter.h
  clang-tools-extra/clang-doc/HTMLGenerator.cpp
  clang-tools-extra/clang-doc/Representation.h
  clang-tools-extra/clang-doc/YAMLGenerator.cpp
  clang-tools-extra/unittests/clang-doc/YAMLGeneratorTest.cpp

Index: clang-tools-extra/unittests/clang-doc/YAMLGeneratorTest.cpp
===
--- clang-tools-extra/unittests/clang-doc/YAMLGeneratorTest.cpp
+++ clang-tools-extra/unittests/clang-doc/YAMLGeneratorTest.cpp
@@ -80,7 +80,8 @@
   I.Members.emplace_back("int", "path/to/int", "X",
  AccessSpecifier::AS_private);
   I.TagType = TagTypeKind::TTK_Class;
-  I.Parents.emplace_back(EmptySID, "F", InfoType::IT_record, "path/to/F");
+  I.Parents.emplace_back(EmptySID, "F", InfoType::IT_record,
+ ""); // F is in the global namespace
   I.VirtualParents.emplace_back(EmptySID, "G", InfoType::IT_record,
 "path/to/G");
 
@@ -120,7 +121,7 @@
 Parents:
   - Type:Record
 Name:'F'
-Path:'path/to/F'
+IsInGlobalNamespace: true
 VirtualParents:
   - Type:Record
 Name:'G'
Index: clang-tools-extra/clang-doc/YAMLGenerator.cpp
===
--- clang-tools-extra/clang-doc/YAMLGenerator.cpp
+++ clang-tools-extra/clang-doc/YAMLGenerator.cpp
@@ -156,6 +156,7 @@
 IO.mapOptional("Name", Ref.Name, SmallString<16>());
 IO.mapOptional("USR", Ref.USR, SymbolID());
 IO.mapOptional("Path", Ref.Path, SmallString<128>());
+IO.mapOptional("IsInGlobalNamespace", Ref.IsInGlobalNamespace, false);
   }
 };
 
Index: clang-tools-extra/clang-doc/Representation.h
===
--- clang-tools-extra/clang-doc/Representation.h
+++ clang-tools-extra/clang-doc/Representation.h
@@ -114,11 +114,17 @@
 struct Reference {
   Reference() = default;
   Reference(llvm::StringRef Name) : Name(Name) {}
-  Reference(llvm::StringRef Name, StringRef Path) : Name(Name), Path(Path) {}
+  // An empty path means the info is in the globalnamespace because the path is
+  // a composite of the parent namespaces.
+  Reference(llvm::StringRef Name, StringRef Path)
+  : Name(Name), Path(Path), IsInGlobalNamespace(Path.empty()) {}
   Reference(SymbolID USR, StringRef Name, InfoType IT)
   : USR(USR), Name(Name), RefType(IT) {}
+  // An empty path means the info is in the globalnamespace because the path is
+  // a composite of the parent namespaces.
   Reference(SymbolID USR, StringRef Name, InfoType IT, StringRef Path)
-  : USR(USR), Name(Name), RefType(IT), Path(Path) {}
+  : USR(USR), Name(Name), RefType(IT), Path(Path),
+IsInGlobalNamespace(Path.empty()) {}
 
   bool operator==(const Reference &Other) const {
 return std::tie(USR, Name, RefType) ==
@@ -130,8 +136,12 @@
   InfoType RefType = InfoType::IT_default; // Indicates the type of this
// Reference (namespace, record,
// function, enum, default).
-  llvm::SmallString<128> Path; // Path of directory where the clang-doc
-   // generated file will be saved
+  llvm::SmallString<128>
+  Path; // Path of directory where the clang-doc generated file will be
+// saved (possibly unresolved)
+  bool IsInGlobalNamespace =
+  false; // Indicates if the info's parent is the global namespace, or if
+ // the info is the global namespace
 };
 
 // A base struct for TypeInfos
Index: clang-tools-extra/clang-doc/HTMLGenerator.cpp
===
--- clang-tools-extra/clang-doc/HTMLGenerator.cpp
+++ clang-tools-extra/clang-doc/HTMLGenerator.cpp
@@ -245,7 +245,7 @@
 
 static std::unique_ptr genTypeReference(const Reference &Type,
   StringRef CurrentDirectory) {
-  if (Type.Path.empty())
+  if (Type.Path.empty() && !Type.IsInGlobalNamespace)
 return llvm::make_unique(Type.Name);
   llvm::SmallString<128> Path =
   computeRelativePath(Type.Path, CurrentDirectory);
Index: clang-tools-extra/clang-doc/BitcodeWriter.h
===
--- clang-tools-extra/clang-doc/BitcodeWriter.h
+++ cl

[PATCH] D65308: [NFC][clang] Refactor getCompilationPhases()+Types.def step 3.

[Puyan Lotfi via Phabricator via cfe-commits]

plotfi updated this revision to Diff 211981.
plotfi marked an inline comment as done.
plotfi added a comment.

addressing @compnerd 's feedback


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65308/new/

https://reviews.llvm.org/D65308

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

Index: clang/lib/Driver/Types.cpp
===
--- clang/lib/Driver/Types.cpp
+++ clang/lib/Driver/Types.cpp
@@ -18,15 +18,14 @@
 
 struct TypeInfo {
   const char *Name;
-  const char *Flags;
   const char *TempSuffix;
   ID PreprocessedType;
   const llvm::SmallVector Phases;
 };
 
 static const TypeInfo TypeInfos[] = {
-#define TYPE(NAME, ID, PP_TYPE, TEMP_SUFFIX, FLAGS, ...) \
-  { NAME, FLAGS, TEMP_SUFFIX, TY_##PP_TYPE, { __VA_ARGS__ }, },
+#define TYPE(NAME, ID, PP_TYPE, TEMP_SUFFIX, ...) \
+  { NAME, TEMP_SUFFIX, TY_##PP_TYPE, { __VA_ARGS__ }, },
 #include "clang/Driver/Types.def"
 #undef TYPE
 };
@@ -90,7 +89,15 @@
 }
 
 bool types::canTypeBeUserSpecified(ID Id) {
-  return strchr(getInfo(Id).Flags, 'u');
+  static const clang::driver::types::ID kStaticLangageTypes[] = {
+  TY_CUDA_DEVICE,   TY_HIP_DEVICE,TY_PP_CHeader,
+  TY_PP_ObjCHeader, TY_PP_CXXHeader,  TY_ObjCXXHeader,
+  TY_PP_CXXModule,  TY_LTO_IR,TY_LTO_BC,
+  TY_Plist, TY_RewrittenObjC, TY_RewrittenLegacyObjC,
+  TY_Remap, TY_PCH,   TY_Object,
+  TY_Image, TY_dSYM,  TY_Dependencies,
+  TY_CUDA_FATBIN,   TY_HIP_FATBIN};
+  return !llvm::is_contained(kStaticLangageTypes, Id);
 }
 
 bool types::appendSuffixForType(ID Id) {
Index: clang/include/clang/Driver/Types.h
===
--- clang/include/clang/Driver/Types.h
+++ clang/include/clang/Driver/Types.h
@@ -20,7 +20,7 @@
 namespace types {
   enum ID {
 TY_INVALID,
-#define TYPE(NAME, ID, PP_TYPE, TEMP_SUFFIX, FLAGS, ...) TY_##ID,
+#define TYPE(NAME, ID, PP_TYPE, TEMP_SUFFIX, ...) TY_##ID,
 #include "clang/Driver/Types.def"
 #undef TYPE
 TY_LAST
Index: clang/include/clang/Driver/Types.def
===
--- clang/include/clang/Driver/Types.def
+++ clang/include/clang/Driver/Types.def
@@ -29,76 +29,73 @@
 // The fourth value is the suffix to use when creating temporary files
 // of this type, or null if unspecified.
 
-// The fifth value is a string containing option flags. Valid values:
-//  u - The type can be user specified (with -x).
-
-// The sixth value is a variadic list of phases for each type. Eventually the
+// The final value is a variadic list of phases for each type. Eventually the
 // options flag string will be replaced with this variadic list.
 // Most of the options in Flags have been removed in favor of subsuming their
 // meaning from the phases list.
 
 // C family source language (with and without preprocessing).
-TYPE("cpp-output",   PP_C, INVALID, "i", "u", phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("c",C,PP_C,"c", "u", phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("cl",   CL,   PP_C,"cl","u", phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("cuda-cpp-output",  PP_CUDA,  INVALID, "cui",   "u", phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("cuda", CUDA, PP_CUDA, "cu","u", phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("cuda", CUDA_DEVICE,  PP_CUDA, "cu","" , phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("hip-cpp-output",   PP_HIP,   INVALID, "cui",   "u", phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("hip",  HIP,  PP_HIP,  "cu","u", phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("hip",  HIP_DEVICE,   PP_HIP,  "cu","" , phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("objective-c-cpp-output",   PP_ObjC,  INVALID, "mi","u", phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("objc-cpp-output",  PP_ObjC_Alias, INVALID,"mi","u", phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("objective-c",  ObjC, PP_ObjC, "m", "u", phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("c++-cpp-output",   PP_CXX,   INVALID, "ii","u", ph

[PATCH] D59963: [clang-tidy] Add a module for the Linux kernel.

[Tom Roeder via Phabricator via cfe-commits]

tmroeder marked an inline comment as done.
tmroeder added inline comments.



Comment at: clang-tools-extra/docs/ReleaseNotes.rst:77
+
+  This is important in the Linux kernel because ``ERR_PTR``, ``PTR_ERR``,
+  ``IS_ERR``, ``IS_ERR_OR_NULL``, ``ERR_CAST``, and ``PTR_ERR_OR_ZERO`` return

tmroeder wrote:
> Eugene.Zelenko wrote:
> > tmroeder wrote:
> > > Eugene.Zelenko wrote:
> > > > Release Notes should include short description. One sentence is enough, 
> > > > but it'll good idea to keep it same as first statement of documentation.
> > > Would you like me to submit a patch that removes the second paragraph of 
> > > this description, then?
> > Yes. Documentation is created for details. But you still need to make its 
> > first sentence same as in Release Notes. See other checks and their Release 
> > Notes as example (in previous release branches).
> I'm sorry, I don't understand. What's the referent of "it" in "you still need 
> to make its first sentence same as in Release Notes"? What first sentence 
> needs to match the first sentence of the Release Notes?
> 
> If it's the header file documentation (MustCheckErrs.h), then as far as I can 
> tell, the first paragraph of Release Notes is identical to the first 
> paragraph of the .h file documentation, other than the double backquotes, 
> which I didn't think belonged in a .h file comment.
> 
> What am I missing?
I have looked back, and I think that https://reviews.llvm.org/D65343 should 
address the comment here. Please take a look at let me know.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59963/new/

https://reviews.llvm.org/D59963



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

[PATCH] D65343: [clang-tidy] Fix the documentation for linuxkernel-must-use-errs.

[Tom Roeder via Phabricator via cfe-commits]

tmroeder created this revision.
tmroeder added a reviewer: Eugene.Zelenko.
Herald added a subscriber: xazax.hun.
Herald added a project: clang.

This changes ReleaseNotes.txt to have the first sentence of the full
documentation from linuxkernel-must-use-errs.rst.

This addresses a comment from the review of rL367071 
 in
https://reviews.llvm.org/D59963.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D65343

Files:
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/linuxkernel-must-use-errs.rst


Index: clang-tools-extra/docs/clang-tidy/checks/linuxkernel-must-use-errs.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/linuxkernel-must-use-errs.rst
+++ clang-tools-extra/docs/clang-tidy/checks/linuxkernel-must-use-errs.rst
@@ -3,14 +3,16 @@
 linuxkernel-must-use-errs
 =
 
-Checks for cases where the kernel error functions ``ERR_PTR``,
-``PTR_ERR``, ``IS_ERR``, ``IS_ERR_OR_NULL``, ``ERR_CAST``, and
-``PTR_ERR_OR_ZERO`` are called but the results are not used. These
-functions are marked with ``__attribute__((warn_unused_result))``, but
-the compiler warning for this attribute is not always enabled.
-
-This also checks for unused values returned by functions that return
-``ERR_PTR``.
+Checks Linux kernel code to see if it uses the results from the functions in
+``linux/err.h``. Also checks to see if code uses the results from functions 
that
+directly return a value from one of these error functions.
+
+This is important in the Linux kernel because ``ERR_PTR``, ``PTR_ERR``,
+``IS_ERR``, ``IS_ERR_OR_NULL``, ``ERR_CAST``, and ``PTR_ERR_OR_ZERO`` return
+values must be checked, since positive pointers and negative error codes are
+being used in the same context. These functions are marked with
+``__attribute__((warn_unused_result))``, but some kernel versions do not have
+this warning enabled for clang.
 
 Examples:
 
Index: clang-tools-extra/docs/ReleaseNotes.rst
===
--- clang-tools-extra/docs/ReleaseNotes.rst
+++ clang-tools-extra/docs/ReleaseNotes.rst
@@ -71,15 +71,7 @@
   ` check.
 
   Checks Linux kernel code to see if it uses the results from the functions in
-  ``linux/err.h``. Also checks to see if code uses the results from functions 
that
-  directly return a value from one of these error functions.
-
-  This is important in the Linux kernel because ``ERR_PTR``, ``PTR_ERR``,
-  ``IS_ERR``, ``IS_ERR_OR_NULL``, ``ERR_CAST``, and ``PTR_ERR_OR_ZERO`` return
-  values must be checked, since positive pointers and negative error codes are
-  being used in the same context. These functions are marked with
-  ``__attribute__((warn_unused_result))``, but some kernel versions do not have
-  this warning enabled for clang.
+  ``linux/err.h``.
 
 Improvements to include-fixer
 -


Index: clang-tools-extra/docs/clang-tidy/checks/linuxkernel-must-use-errs.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/linuxkernel-must-use-errs.rst
+++ clang-tools-extra/docs/clang-tidy/checks/linuxkernel-must-use-errs.rst
@@ -3,14 +3,16 @@
 linuxkernel-must-use-errs
 =
 
-Checks for cases where the kernel error functions ``ERR_PTR``,
-``PTR_ERR``, ``IS_ERR``, ``IS_ERR_OR_NULL``, ``ERR_CAST``, and
-``PTR_ERR_OR_ZERO`` are called but the results are not used. These
-functions are marked with ``__attribute__((warn_unused_result))``, but
-the compiler warning for this attribute is not always enabled.
-
-This also checks for unused values returned by functions that return
-``ERR_PTR``.
+Checks Linux kernel code to see if it uses the results from the functions in
+``linux/err.h``. Also checks to see if code uses the results from functions that
+directly return a value from one of these error functions.
+
+This is important in the Linux kernel because ``ERR_PTR``, ``PTR_ERR``,
+``IS_ERR``, ``IS_ERR_OR_NULL``, ``ERR_CAST``, and ``PTR_ERR_OR_ZERO`` return
+values must be checked, since positive pointers and negative error codes are
+being used in the same context. These functions are marked with
+``__attribute__((warn_unused_result))``, but some kernel versions do not have
+this warning enabled for clang.
 
 Examples:
 
Index: clang-tools-extra/docs/ReleaseNotes.rst
===
--- clang-tools-extra/docs/ReleaseNotes.rst
+++ clang-tools-extra/docs/ReleaseNotes.rst
@@ -71,15 +71,7 @@
   ` check.
 
   Checks Linux kernel code to see if it uses the results from the functions in
-  ``linux/err.h``. Also checks to see if code uses the results from functions that
-  directly return a value from one of these error functions.
-
-  This is important in the Linux kernel because ``ERR_PTR``, ``PTR_ERR``,
-  ``IS_ERR``, ``IS_ERR_OR_NULL``, ``ER

[PATCH] D64838: [Attr] Support _attribute__ ((fallthrough))

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added a comment.

In D64838#1602840 , 
@Nathan-Huckleberry wrote:

> I agree that parsing according to attribute name/type is not a good solution.
>
> It sounds like we have narrowed it down to two choices:
>  Do we want to follow the gcc method of parsing once and falling back if 
> parsing fails?
>  Do we want to parse attributes first and then wait until we see a 
> decl-specifier (breaking the implicit int case)?


I don't think so. A GCC attribute is a decl-specifier, so should trigger 
implicit-int in the languages that have it.

Option 1: teach the statement/declaration disambiguation code that an initial 
GNU attribute does not resolve the ambiguity and that it needs to disambiguate 
past one.

Option 2: parse the attributes and then call the disambiguation code and tell 
it that we've already consumed a decl-specifier.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64838/new/

https://reviews.llvm.org/D64838



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

[PATCH] D62731: [RFC] Add support for options -fp-model= and -fp-speculation= : specify floating point behavior

[Melanie Blower via Phabricator via cfe-commits]

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

Thanks for your review >>! In D62731#1601408 
, @kpn wrote:

> In D62731#1601310 , @mibintc wrote:
> 
>> I think it would be convenient to have an "unset" setting for the different 
>> constrained modes, otherwise you need a boolean that says "no value was 
>> provided for this option".  But i'm a frontend person so I may need to have 
>> my attitude adjusted.
> 
> 
> What "different constrained modes"? The IRBuilder is either in constrained 
> mode or it isn't. In constrained mode the exception behavior and rounding 
> mode both have defaults, and those defaults can be changed individually 
> without affecting the other setting. The current defaults can also be 
> retrieved if you need something for a function call where you don't want to 
> change it but need an argument anyway. When do you need this "no value 
> provided" setting?

I'm going to rewrite this

> Oh, I'd check the tools/clang/CODE_OWNERS.txt file and add additional 
> appropriate reviewers. Perhaps John McCall and Richard Smith? I don't know 
> who has opinions on how command line options should be handled.

I'd like to fix it more before I add more reviewers

> Do we want the Unix driver to be compatible with gcc? Maybe, maybe not. 
> Opinions, anyone?

Oh, I think you mean something more like the gnuish -fno-except or maybe 
-fp-model=no-except? instead of -fp-model=except- ok we can get that sorted.

> The documentation request from lebedev.ri isn't in this ticket yet.
> 
> Also, for future historical research purposes I'd cut and paste the relevant 
> portions of outside web pages (like intel.com's) and post them somewhere 
> llvm-ish where they are findable. This ticket, for example, is a good place. 
> Web sites gets reorganized or vanish in full or in part. It's helpful to have 
> some insulation from that over time. I've had to fix compiler bugs that 
> actually were 25 years old before. Yes, 25 years old. Being able to do the 
> research is very helpful.

That's a good idea thanks

> Oh, it may be useful to know that constrained floating point and the 
> FastMathFlags are not mutually exclusive. I don't know if that matters here 
> or not, but you did mention FastMathFlags.

Yes i'm not sure how the fast math command line optoins should interact with 
the fp-model options, i'll have to dig into that.




Comment at: llvm/lib/IR/FPState.cpp:1
+#include "llvm/IR/FPState.h"
+#include "llvm/IR/IRBuilder.h"

arsenm wrote:
> Missing license header
Thanks @arsenm in the end i believe i won't be adding this file



Comment at: llvm/lib/IR/FPState.cpp:73
+  if (IsConstrainedExcept && !IsConstrainedRounding) {
+// If the rounding mode isn't set explicitly above, then use ebToNearest
+// as the value when the constrained intrinsic is created

arsenm wrote:
> eb?
I mean, if the user requested constrained exception via the option 
-fp-model=except but no rounding mode has been requested (again via command 
line options) then the rounding mode should be set to "round to nearest".  I'm 
following a description of how the icc compiler works. I'm afraid that your 
concise comment "eb?" doesn't convey enough information for me to understand 
what you mean.  With these further remarks is it clear now? 



Comment at: llvm/lib/IR/FPState.cpp:78
+  }
+
+  Builder.setIsFPConstrained(IsConstrainedExcept || IsConstrainedRounding);

kpn wrote:
> The IRBuilder already has defaults for exception behavior and rounding. Is it 
> a good idea to duplicate that knowledge here? Worse, what's here is different 
> from what's in the IRBuilder. Why not ask the IRBuilder what its current 
> setting is and use that?
> 
> Would it make sense to have setters/getters, and then have a separate 
> updateBuilder() method? We still don't have a good way to get the #pragma 
> down to the lower levels of clang. The current, unfinished, attempt doesn't 
> work for C++ templates and I'm told other cases as well. An updateBuilder() 
> method could be helpful when moving from one scope to another. But keep in 
> mind that if any constrained fp math is used in a function then the entire 
> function has to be constrained.
> 
> Given that last bit, it may make more sense to have the support somewhere 
> higher level than as a wrapper around the IRBuilder. Maybe in CodeGenFunction 
> or CodeGenModule? I've not spent much time in clang so I'm not sure if that 
> makes sense or not.
Yes I absolutely don't want to duplicate, and I will submit another version of 
this patch and i'll be removing fpstate*.  I do want to be able to make the 
fp-model options match the same behavior as icc is using.  One reason i wanted 
to keep track of the state within a separate object is because i was uncertain 
if stuff would be going on in the IR builder

[PATCH] D64811: Warn when NumParams overflows

[John McCall via Phabricator via cfe-commits]

rjmccall added inline comments.



Comment at: clang/lib/Parse/ParseDecl.cpp:6673
+  // Avoid exceeding the maximum function parameters
+  // See https://bugs.llvm.org/show_bug.cgi?id=19607
+  if (ParamInfo.size() > Type::getMaxNumParams()) {

rjmccall wrote:
> We don't usually cite bugs like this in the main source code except as 
> "there's a bug with this, here's where we tracking fixing it".  The comment 
> explains the purpose of the diagnostic well enough (but please include a 
> period).
> 
> Can you just drop the excess arguments here instead of cutting off parsing?
Or actually — let's move this out of the parser entirely, because (unlike 
prototype scope depth) we actually need to diagnose it in Sema as well because 
of variadic templates.  `Sema::BuildFunctionType` seems like the right place.

Also, can you `static_assert` that function declarations support at least as 
many parameter declarations as we allow in types?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64811/new/

https://reviews.llvm.org/D64811



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

[PATCH] D64454: [clang-tidy] Adding static analyzer check to list of clang-tidy checks

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

When I run the script locally, I still get issues with `subprocess.run()`.

  c:\llvm\tools\clang\tools\extra\docs\clang-tidy\checks>python 
gen-static-analyzer-docs.py
  Traceback (most recent call last):
File "gen-static-analyzer-docs.py", line 148, in 
  main()
File "gen-static-analyzer-docs.py", line 137, in main
  checkers = get_checkers(file_path)
File "gen-static-analyzer-docs.py", line 22, in get_checkers
  result = subprocess.run(["llvm-tblgen", "--dump-json", "-I",
  AttributeError: 'module' object has no attribute 'run'




Comment at: 
clang-tools-extra/docs/clang-tidy/checks/gen-static-analyzer-docs.py:120-123
+  if(os.path.exists(default_path_in_tree)):
+default_path = default_path_in_tree
+  if(os.path.exists(default_path_monorepo)):
+default_path = default_path_monorepo

Swap the order of these and use an `elif` so we don't set the path and then 
overwrite it?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64454/new/

https://reviews.llvm.org/D64454



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

[PATCH] D65234: [CodeGen]: don't treat structures returned in registers as memory inputs

[Eli Friedman via Phabricator via cfe-commits]

efriedma added inline comments.



Comment at: clang/test/CodeGen/PR42672.c:50
+  struct {
+long long int v1, v2, v3, v4;
+  } str;

glider wrote:
> The acceptable size actually depends on the target platform. Not sure we can 
> test for all of them, and we'll probably need to restrict this test to e.g. 
> x86
The interesting case for a 32-byte struct would actually be something like 
`"=x"(str)`... which currently passes the clang frontend, since 32 is a legal 
size for that constraint (although it eventually fails in the backend).



Comment at: clang/test/CodeGen/PR42672.c:3
+// RUN: %clang_cc1 -USTRUCT -emit-llvm %s -o - | FileCheck %s 
--check-prefix=CHECK-NOSTRUCT
+// RUN: %clang_cc1 -triple=x86_64-unknown-linux-gnu -DIMPOSSIBLE -emit-llvm %s 
-o - 2> %t || true
+// RUN: grep "impossible constraint in asm" %t

Might as well just make all these tests use an x86 triple; I don't really want 
to speculate how an unknown target will react to any specific size.



Comment at: clang/test/CodeGen/PR42672.c:40
+unsigned short first;
+unsigned char second;
+  } str;

This isn't a three-byte struct; it's a four-byte struct where one of the bytes 
is only used for padding. 


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65234/new/

https://reviews.llvm.org/D65234



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

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added inline comments.



Comment at: lib/CodeGen/CGOpenMPRuntime.h:815
+  /// code generation.
+  void emitUDMapperArrayInitOrDel(CodeGenFunction &MapperCGF,
+  llvm::Value *Handle, llvm::Value *BasePtr,

lildmh wrote:
> ABataev wrote:
> > Seems to me, this function is used only in `emitUserDefinedMapper`. I think 
> > you can make it static local in the CGOpenMPRuntime.cpp and do not expose 
> > it in the interface.
> `emitUserDefinedMapper` needs to call `createRuntimeFunction` of 
> `CGOpenMPRuntime`, which is private.
> 
> Which one do you think is better, make `createRuntimeFunction` public, or 
> have `emitUserDefinedMapper` not defined in `CGOpenMPRuntime`? It seems to me 
> that they are similar
Then make `emitUDMapperArrayInitOrDel` private instead.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59474/new/

https://reviews.llvm.org/D59474



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

[PATCH] D61466: [Rewrite][NFC] Add FIXMEs and tests for RemoveLineIfEmpty bug

[Joel E. Denny via Phabricator via cfe-commits]

jdenny added a comment.

In D61466#1602917 , @jkorous wrote:

> Hi @jdenny, thanks for the warning!


Hi.  Thanks for the review.

> I think having the test disabled is fine - the main upside I see is that we 
> won't check it fails over and over on our CI systems.

In an inline comment, you also mentioned the alternative of replacing 
`EXPECT_EQ` with `EXPECT_NE`.  Neither solution is the XFAIL I'm used to (from 
lit for example).

I chose disabling purely because I saw some other unit tests do this.  What do 
people normally recommend for llvm unit tests?

> Could you please mention the test/reproducer in those FIXMEs?

Will do.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D61466/new/

https://reviews.llvm.org/D61466



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

[PATCH] D64811: Warn when NumParams overflows

[John McCall via Phabricator via cfe-commits]

rjmccall added inline comments.



Comment at: clang/include/clang/AST/Type.h:1523
 
+  enum { NumParamsBits = 16 };
+

This should probably go in `FunctionTypeBitfields`.



Comment at: clang/lib/Parse/ParseDecl.cpp:6673
+  // Avoid exceeding the maximum function parameters
+  // See https://bugs.llvm.org/show_bug.cgi?id=19607
+  if (ParamInfo.size() > Type::getMaxNumParams()) {

We don't usually cite bugs like this in the main source code except as "there's 
a bug with this, here's where we tracking fixing it".  The comment explains the 
purpose of the diagnostic well enough (but please include a period).

Can you just drop the excess arguments here instead of cutting off parsing?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64811/new/

https://reviews.llvm.org/D64811



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

[PATCH] D64932: [Parser] Emit descriptive diagnostic for misplaced pragma

[John McCall via Phabricator via cfe-commits]

rjmccall added inline comments.



Comment at: clang/lib/Basic/TokenKinds.cpp:55
+return std::strncmp(#X, "pragma_", sizeof("pragma_") - 1) == 0;
+#include "clang/Basic/TokenKinds.def"
+  default:

The right way to do this is to make a `PRAGMA_ANNOTATION` macro in 
`TokenKinds.def` that defaults to `ANNOTATION`, like that file already does 
with e.g. `CXX11_KEYWORD`.  But for future reference, there's also a 
`StringRef::startsWith`.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64932/new/

https://reviews.llvm.org/D64932



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

[PATCH] D65000: [ARM] Set default alignment to 64bits

[Nico Weber via Phabricator via cfe-commits]

thakis added inline comments.



Comment at: cfe/trunk/test/CodeGen/ARM/exception-alignment.cpp:9
+// A16-NEXT: store <2 x i64> , <2 x i64>* [[BC]], align 16
+#include 
+

This fails on some bots:

http://lab.llvm.org:8011/builders/clang-atom-d525-fedora-rel/builds/26891/steps/ninja%20check%201/logs/FAIL%3A%20Clang%3A%3Aexception-alignment.cpp

```
In file included from 
/export/users/atombot/llvm/clang-atom-d525-fedora-rel/llvm/tools/clang/test/CodeGen/ARM/exception-alignment.cpp:9:
In file included from 
/export/users/atombot/llvm/clang-atom-d525-fedora-rel/stage1/lib/clang/10.0.0/include/arm_neon.h:31:
In file included from 
/export/users/atombot/llvm/clang-atom-d525-fedora-rel/stage1/lib/clang/10.0.0/include/stdint.h:52:
In file included from /usr/include/stdint.h:26:
In file included from /usr/include/bits/libc-header-start.h:33:
In file included from /usr/include/features.h:452:
/usr/include/gnu/stubs.h:7:11: fatal error: 'gnu/stubs-32.h' file not found
# include 
  ^~~~
1 error generated.
FileCheck error: '-' is empty.
FileCheck command line:  
/export/users/atombot/llvm/clang-atom-d525-fedora-rel/stage1/bin/FileCheck 
--check-prefixes=CHECK,A16 
/export/users/atombot/llvm/clang-atom-d525-fedora-rel/llvm/tools/clang/test/CodeGen/ARM/exception-alignment.cpp

--
```


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65000/new/

https://reviews.llvm.org/D65000



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

[PATCH] D61104: [clang][ASTContext] Try to avoid sorting comments for code completion

[Jan Korous via Phabricator via cfe-commits]

jkorous abandoned this revision.
jkorous added a comment.

Abandoned in favor of
https://reviews.llvm.org/D65301


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D61104/new/

https://reviews.llvm.org/D61104



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

[PATCH] D61103: [clang] Add tryToAttachCommentsToDecls method to ASTContext

[Jan Korous via Phabricator via cfe-commits]

jkorous abandoned this revision.
jkorous added a comment.

Abandoned in favor of https://reviews.llvm.org/D65301


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D61103/new/

https://reviews.llvm.org/D61103



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

[PATCH] D61466: [Rewrite][NFC] Add FIXMEs and tests for RemoveLineIfEmpty bug

[Jan Korous via Phabricator via cfe-commits]

jkorous added a comment.

Hi @jdenny, thanks for the warning! I think having the test disabled is fine - 
the main upside I see is that we won't check it fails over and over on our CI 
systems.
Could you please mention the test/reproducer in those FIXMEs?
Otherwise LGTM.




Comment at: clang/unittests/Rewrite/RewriteBufferTest.cpp:17
 
+#define EXPECT_OUTPUT(Buf, Output) EXPECT_EQ(Output, writeOutput(Buf))
+

I think in case you really wanted to have an "XFAIL", you could have just used 
`EXPECT_NE` here.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D61466/new/

https://reviews.llvm.org/D61466



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

[PATCH] D65309: [clang-format] Fix style of css file paths

[Diego Astiazarán via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL367137: [clang-format] Fix style of css file paths (authored 
by DiegoAstiazaran, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D65309?vs=211971&id=211972#toc

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65309/new/

https://reviews.llvm.org/D65309

Files:
  clang-tools-extra/trunk/clang-doc/HTMLGenerator.cpp
  clang-tools-extra/trunk/unittests/clang-doc/HTMLGeneratorTest.cpp


Index: clang-tools-extra/trunk/unittests/clang-doc/HTMLGeneratorTest.cpp
===
--- clang-tools-extra/trunk/unittests/clang-doc/HTMLGeneratorTest.cpp
+++ clang-tools-extra/trunk/unittests/clang-doc/HTMLGeneratorTest.cpp
@@ -110,34 +110,23 @@
   ClangDocContext CDCtx = getClangDocContext();
   auto Err = G->generateDocForInfo(&I, Actual, CDCtx);
   assert(!Err);
-  SmallString<16> PathToF;
-  llvm::sys::path::native("../../../path/to/F.html", PathToF);
-  SmallString<16> PathToInt;
-  llvm::sys::path::native("../int.html", PathToInt);
-  SmallString<16> PathToSylesheet;
-  llvm::sys::path::native("../../../clang-doc-default-stylesheet.css",
-  PathToSylesheet);
   std::string Expected = R"raw(
 
 class r
-
+
 
   class r
   Defined at line 10 of test.cpp
   
 Inherits from 
-F
+F
 , G
   
   Members
   
 
   private 
-  int
+  int
X
 
   
Index: clang-tools-extra/trunk/clang-doc/HTMLGenerator.cpp
===
--- clang-tools-extra/trunk/clang-doc/HTMLGenerator.cpp
+++ clang-tools-extra/trunk/clang-doc/HTMLGenerator.cpp
@@ -231,6 +231,8 @@
 SmallString<128> StylesheetPath = computeRelativePath("", InfoPath);
 llvm::sys::path::append(StylesheetPath,
 llvm::sys::path::filename(FilePath));
+// Paths in HTML must be in posix-style
+llvm::sys::path::native(StylesheetPath, llvm::sys::path::Style::posix);
 LinkNode->Attributes.try_emplace("href", StylesheetPath);
 Out.emplace_back(std::move(LinkNode));
   }


Index: clang-tools-extra/trunk/unittests/clang-doc/HTMLGeneratorTest.cpp
===
--- clang-tools-extra/trunk/unittests/clang-doc/HTMLGeneratorTest.cpp
+++ clang-tools-extra/trunk/unittests/clang-doc/HTMLGeneratorTest.cpp
@@ -110,34 +110,23 @@
   ClangDocContext CDCtx = getClangDocContext();
   auto Err = G->generateDocForInfo(&I, Actual, CDCtx);
   assert(!Err);
-  SmallString<16> PathToF;
-  llvm::sys::path::native("../../../path/to/F.html", PathToF);
-  SmallString<16> PathToInt;
-  llvm::sys::path::native("../int.html", PathToInt);
-  SmallString<16> PathToSylesheet;
-  llvm::sys::path::native("../../../clang-doc-default-stylesheet.css",
-  PathToSylesheet);
   std::string Expected = R"raw(
 
 class r
-
+
 
   class r
   Defined at line 10 of test.cpp
   
 Inherits from 
-F
+F
 , G
   
   Members
   
 
   private 
-  int
+  int
X
 
   
Index: clang-tools-extra/trunk/clang-doc/HTMLGenerator.cpp
===
--- clang-tools-extra/trunk/clang-doc/HTMLGenerator.cpp
+++ clang-tools-extra/trunk/clang-doc/HTMLGenerator.cpp
@@ -231,6 +231,8 @@
 SmallString<128> StylesheetPath = computeRelativePath("", InfoPath);
 llvm::sys::path::append(StylesheetPath,
 llvm::sys::path::filename(FilePath));
+// Paths in HTML must be in posix-style
+llvm::sys::path::native(StylesheetPath, llvm::sys::path::Style::posix);
 LinkNode->Attributes.try_emplace("href", StylesheetPath);
 Out.emplace_back(std::move(LinkNode));
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh marked an inline comment as done.
lildmh added inline comments.



Comment at: lib/CodeGen/CGOpenMPRuntime.h:815
+  /// code generation.
+  void emitUDMapperArrayInitOrDel(CodeGenFunction &MapperCGF,
+  llvm::Value *Handle, llvm::Value *BasePtr,

ABataev wrote:
> Seems to me, this function is used only in `emitUserDefinedMapper`. I think 
> you can make it static local in the CGOpenMPRuntime.cpp and do not expose it 
> in the interface.
`emitUserDefinedMapper` needs to call `createRuntimeFunction` of 
`CGOpenMPRuntime`, which is private.

Which one do you think is better, make `createRuntimeFunction` public, or have 
`emitUserDefinedMapper` not defined in `CGOpenMPRuntime`? It seems to me that 
they are similar


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59474/new/

https://reviews.llvm.org/D59474



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

[clang-tools-extra] r367137 - [clang-format] Fix style of css file paths

[Diego Astiazaran via cfe-commits]

Author: diegoastiazaran
Date: Fri Jul 26 11:02:42 2019
New Revision: 367137

URL: http://llvm.org/viewvc/llvm-project?rev=367137&view=rev
Log:
[clang-format] Fix style of css file paths

CSS files included in HTML should have a path in posix style, it should
not be different for Windows.

Differential Revision: https://reviews.llvm.org/D65309

Modified:
clang-tools-extra/trunk/clang-doc/HTMLGenerator.cpp
clang-tools-extra/trunk/unittests/clang-doc/HTMLGeneratorTest.cpp

Modified: clang-tools-extra/trunk/clang-doc/HTMLGenerator.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-doc/HTMLGenerator.cpp?rev=367137&r1=367136&r2=367137&view=diff
==
--- clang-tools-extra/trunk/clang-doc/HTMLGenerator.cpp (original)
+++ clang-tools-extra/trunk/clang-doc/HTMLGenerator.cpp Fri Jul 26 11:02:42 2019
@@ -231,6 +231,8 @@ genStylesheetsHTML(StringRef InfoPath, c
 SmallString<128> StylesheetPath = computeRelativePath("", InfoPath);
 llvm::sys::path::append(StylesheetPath,
 llvm::sys::path::filename(FilePath));
+// Paths in HTML must be in posix-style
+llvm::sys::path::native(StylesheetPath, llvm::sys::path::Style::posix);
 LinkNode->Attributes.try_emplace("href", StylesheetPath);
 Out.emplace_back(std::move(LinkNode));
   }

Modified: clang-tools-extra/trunk/unittests/clang-doc/HTMLGeneratorTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/unittests/clang-doc/HTMLGeneratorTest.cpp?rev=367137&r1=367136&r2=367137&view=diff
==
--- clang-tools-extra/trunk/unittests/clang-doc/HTMLGeneratorTest.cpp (original)
+++ clang-tools-extra/trunk/unittests/clang-doc/HTMLGeneratorTest.cpp Fri Jul 
26 11:02:42 2019
@@ -110,34 +110,23 @@ TEST(HTMLGeneratorTest, emitRecordHTML)
   ClangDocContext CDCtx = getClangDocContext();
   auto Err = G->generateDocForInfo(&I, Actual, CDCtx);
   assert(!Err);
-  SmallString<16> PathToF;
-  llvm::sys::path::native("../../../path/to/F.html", PathToF);
-  SmallString<16> PathToInt;
-  llvm::sys::path::native("../int.html", PathToInt);
-  SmallString<16> PathToSylesheet;
-  llvm::sys::path::native("../../../clang-doc-default-stylesheet.css",
-  PathToSylesheet);
   std::string Expected = R"raw(
 
 class r
-
+
 
   class r
   Defined at line 10 of test.cpp
   
 Inherits from 
-F
+F
 , G
   
   Members
   
 
   private 
-  int
+  int
X
 
   


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

[PATCH] D65309: [clang-format] Fix style of css file paths

[Diego Astiazarán via Phabricator via cfe-commits]

DiegoAstiazaran updated this revision to Diff 211971.
DiegoAstiazaran added a comment.

Add comment.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65309/new/

https://reviews.llvm.org/D65309

Files:
  clang-tools-extra/clang-doc/HTMLGenerator.cpp
  clang-tools-extra/unittests/clang-doc/HTMLGeneratorTest.cpp


Index: clang-tools-extra/unittests/clang-doc/HTMLGeneratorTest.cpp
===
--- clang-tools-extra/unittests/clang-doc/HTMLGeneratorTest.cpp
+++ clang-tools-extra/unittests/clang-doc/HTMLGeneratorTest.cpp
@@ -110,34 +110,23 @@
   ClangDocContext CDCtx = getClangDocContext();
   auto Err = G->generateDocForInfo(&I, Actual, CDCtx);
   assert(!Err);
-  SmallString<16> PathToF;
-  llvm::sys::path::native("../../../path/to/F.html", PathToF);
-  SmallString<16> PathToInt;
-  llvm::sys::path::native("../int.html", PathToInt);
-  SmallString<16> PathToSylesheet;
-  llvm::sys::path::native("../../../clang-doc-default-stylesheet.css",
-  PathToSylesheet);
   std::string Expected = R"raw(
 
 class r
-
+
 
   class r
   Defined at line 10 of test.cpp
   
 Inherits from 
-F
+F
 , G
   
   Members
   
 
   private 
-  int
+  int
X
 
   
Index: clang-tools-extra/clang-doc/HTMLGenerator.cpp
===
--- clang-tools-extra/clang-doc/HTMLGenerator.cpp
+++ clang-tools-extra/clang-doc/HTMLGenerator.cpp
@@ -231,6 +231,8 @@
 SmallString<128> StylesheetPath = computeRelativePath("", InfoPath);
 llvm::sys::path::append(StylesheetPath,
 llvm::sys::path::filename(FilePath));
+// Paths in HTML must be in posix-style
+llvm::sys::path::native(StylesheetPath, llvm::sys::path::Style::posix);
 LinkNode->Attributes.try_emplace("href", StylesheetPath);
 Out.emplace_back(std::move(LinkNode));
   }


Index: clang-tools-extra/unittests/clang-doc/HTMLGeneratorTest.cpp
===
--- clang-tools-extra/unittests/clang-doc/HTMLGeneratorTest.cpp
+++ clang-tools-extra/unittests/clang-doc/HTMLGeneratorTest.cpp
@@ -110,34 +110,23 @@
   ClangDocContext CDCtx = getClangDocContext();
   auto Err = G->generateDocForInfo(&I, Actual, CDCtx);
   assert(!Err);
-  SmallString<16> PathToF;
-  llvm::sys::path::native("../../../path/to/F.html", PathToF);
-  SmallString<16> PathToInt;
-  llvm::sys::path::native("../int.html", PathToInt);
-  SmallString<16> PathToSylesheet;
-  llvm::sys::path::native("../../../clang-doc-default-stylesheet.css",
-  PathToSylesheet);
   std::string Expected = R"raw(
 
 class r
-
+
 
   class r
   Defined at line 10 of test.cpp
   
 Inherits from 
-F
+F
 , G
   
   Members
   
 
   private 
-  int
+  int
X
 
   
Index: clang-tools-extra/clang-doc/HTMLGenerator.cpp
===
--- clang-tools-extra/clang-doc/HTMLGenerator.cpp
+++ clang-tools-extra/clang-doc/HTMLGenerator.cpp
@@ -231,6 +231,8 @@
 SmallString<128> StylesheetPath = computeRelativePath("", InfoPath);
 llvm::sys::path::append(StylesheetPath,
 llvm::sys::path::filename(FilePath));
+// Paths in HTML must be in posix-style
+llvm::sys::path::native(StylesheetPath, llvm::sys::path::Style::posix);
 LinkNode->Attributes.try_emplace("href", StylesheetPath);
 Out.emplace_back(std::move(LinkNode));
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D65341: [OpenMP] Add support for close map modifier in Clang

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added inline comments.



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:7695
   Flags &= ~(OMP_MAP_TO | OMP_MAP_FROM | OMP_MAP_ALWAYS |
- OMP_MAP_DELETE);
+ OMP_MAP_DELETE | OMP_MAP_CLOSE);
 

Why?


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65341/new/

https://reviews.llvm.org/D65341



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

[PATCH] D65184: [Sema] Thread Safety Analysis: Fix negative capability's LockKind representation.

[Ziang Wan via Phabricator via cfe-commits]

ziangwan marked 4 inline comments as done.
ziangwan added inline comments.



Comment at: clang/lib/Analysis/ThreadSafety.cpp:2188-2190
+/// shared + exclusive = exclusive
+/// generic + exclusive = exclusive
+/// generic + shared = shared

aaronpuchert wrote:
> What do these lines mean? That we accept if a lock is shared in one branch 
> and exclusive in the other, and that we make it exclusive after the merge 
> point?
Yes. If at CFG merge point, one path holds type1 lock and the other path holds 
type2 lock.

We do a type1 + type2 = merged_type and issue warnings if we are doing shared + 
exclusive merge.



Comment at: clang/lib/Analysis/ThreadSafety.cpp:2219-2221
+if (LDat1->kind() == LK_Generic || LDat2->kind() == LK_Generic) {
+  // No warning is issued in this case.
+  if (Modify && LDat1->kind() == LK_Generic) {

nickdesaulniers wrote:
> The double check of `LDat1->kind() == LK_Generic` is fishy to me.  
> Particularly the case where `LDat1->kind() == LK_Generic` is false but 
> `LDat2->kind() == LK_Generic` is true.
> 
> This might be clearer as:
> ```
> if (LDat2->kind() == LK_Generic)
>   continue;
> else if (LDat1->kind() == LK_Generic && Modify)
>   *Iter1 = Fact;
> else {
>   ...
> ```
> Or is there something else to this logic I'm missing?
I think your suggestion is to refactor the if statements. What I am thinking is 
that there are two cases.
1. One of the two locks is generic
  * If so, then take the type of the other non-generic lock (shared or 
exclusive).
2. Neither of the two locks is generic.

My if statement is trying express that. I am afraid the refactoring is going to 
lose the logic (as stated in my comment above).



Comment at: clang/test/SemaCXX/thread-safety-annotations.h:47
+// Enable thread safety attributes only with clang.
+// The attributes can be safely erased when compiling with other compilers.
+#if defined(__clang__) && (!defined(SWIG))

nickdesaulniers wrote:
> Is this test suite run with other compilers? If not, I think we can remove 
> the case?
Yeah, you are right. I just copied the header definitions from clang thread 
safety analysis doc.



Comment at: clang/test/SemaCXX/warn-thread-safety-negative.cpp:135-140
+  if (condition) {
+assertNotHeld(); // expected-warning {{mutex '!mu' is acquired exclusively 
and shared in the same scope}}
+  } else {
+mu.Lock();
+mu.Unlock(); // expected-warning {{the other acquisition of mutex '!mu' is 
here}}
+  }

aaronpuchert wrote:
> Why would I want these warnings here? This code seems fine to me.
> 
> However, I don't see why we don't get `acquiring mutex 'mu' requires negative 
> capability '!mu'` at line 138, or does that disappear because of the 
> assertion?
Showing `acquiring mutex 'mu' requires negative capability '!mu'` is not in the 
scope of this patch. Please notice thread safety analysis is still under 
development.

The reason is that, in one path we have `ASSERT_SHARED_CAPABILITY(!mu)`, and in 
the other path we have `RELEASE(mu)`. The assertion leads to negative shared 
capability but the release leads to negative exclusive capability. A merge of 
the two capabilities (merging "I am not trying to read" versus "I am not trying 
to write") leads to a warning.

Without my patch, clang will issue a warning for the merge point in test1() but 
not the merge point in test2().


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65184/new/

https://reviews.llvm.org/D65184



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

[PATCH] D65341: [OpenMP] Add support for close map modifier in Clang

[Gheorghe-Teodor Bercea via Phabricator via cfe-commits]

gtbercea created this revision.
gtbercea added reviewers: ABataev, caomhin.
Herald added subscribers: cfe-commits, guansong.
Herald added a reviewer: jdoerfert.
Herald added a project: clang.

This patch adds support for the close map modifier in Clang.

This ensures that the new map type is marked and passed to the OpenMP runtime 
appropriately.


Repository:
  rC Clang

https://reviews.llvm.org/D65341

Files:
  lib/CodeGen/CGOpenMPRuntime.cpp
  test/OpenMP/target_data_codegen.cpp


Index: test/OpenMP/target_data_codegen.cpp
===
--- test/OpenMP/target_data_codegen.cpp
+++ test/OpenMP/target_data_codegen.cpp
@@ -283,4 +283,13 @@
   {++arg;}
 }
 #endif
+///==///
+ RUN: %clang_cc1 -DCK4 -verify -fopenmp -x c++ -triple 
powerpc64le-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm %s 
-o - | FileCheck %s --check-prefix CK4
+#ifdef CK4
+void test_close_modifier(int arg) {
+  // CK4: private unnamed_addr constant [1 x i64] [i64 1059]
+  #pragma omp target data map(close,tofrom: arg)
+  {++arg;}
+}
+#endif
 #endif
Index: lib/CodeGen/CGOpenMPRuntime.cpp
===
--- lib/CodeGen/CGOpenMPRuntime.cpp
+++ lib/CodeGen/CGOpenMPRuntime.cpp
@@ -7087,6 +7087,9 @@
 OMP_MAP_LITERAL = 0x100,
 /// Implicit map
 OMP_MAP_IMPLICIT = 0x200,
+/// Close is a hint to the runtime to allocate memory close to
+/// the target device.
+OMP_MAP_CLOSE = 0x400,
 /// The 16 MSBs of the flags indicate whether the entry is member of some
 /// struct/class.
 OMP_MAP_MEMBER_OF = 0x,
@@ -7255,6 +7258,9 @@
 if (llvm::find(MapModifiers, OMPC_MAP_MODIFIER_always)
 != MapModifiers.end())
   Bits |= OMP_MAP_ALWAYS;
+if (llvm::find(MapModifiers, OMPC_MAP_MODIFIER_close)
+!= MapModifiers.end())
+  Bits |= OMP_MAP_CLOSE;
 return Bits;
   }
 
@@ -7686,7 +7692,7 @@
 // then we reset the TO/FROM/ALWAYS/DELETE flags.
 if (IsPointer)
   Flags &= ~(OMP_MAP_TO | OMP_MAP_FROM | OMP_MAP_ALWAYS |
- OMP_MAP_DELETE);
+ OMP_MAP_DELETE | OMP_MAP_CLOSE);
 
 if (ShouldBeMemberOf) {
   // Set placeholder value MEMBER_OF= to indicate that the flag


Index: test/OpenMP/target_data_codegen.cpp
===
--- test/OpenMP/target_data_codegen.cpp
+++ test/OpenMP/target_data_codegen.cpp
@@ -283,4 +283,13 @@
   {++arg;}
 }
 #endif
+///==///
+ RUN: %clang_cc1 -DCK4 -verify -fopenmp -x c++ -triple powerpc64le-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm %s -o - | FileCheck %s --check-prefix CK4
+#ifdef CK4
+void test_close_modifier(int arg) {
+  // CK4: private unnamed_addr constant [1 x i64] [i64 1059]
+  #pragma omp target data map(close,tofrom: arg)
+  {++arg;}
+}
+#endif
 #endif
Index: lib/CodeGen/CGOpenMPRuntime.cpp
===
--- lib/CodeGen/CGOpenMPRuntime.cpp
+++ lib/CodeGen/CGOpenMPRuntime.cpp
@@ -7087,6 +7087,9 @@
 OMP_MAP_LITERAL = 0x100,
 /// Implicit map
 OMP_MAP_IMPLICIT = 0x200,
+/// Close is a hint to the runtime to allocate memory close to
+/// the target device.
+OMP_MAP_CLOSE = 0x400,
 /// The 16 MSBs of the flags indicate whether the entry is member of some
 /// struct/class.
 OMP_MAP_MEMBER_OF = 0x,
@@ -7255,6 +7258,9 @@
 if (llvm::find(MapModifiers, OMPC_MAP_MODIFIER_always)
 != MapModifiers.end())
   Bits |= OMP_MAP_ALWAYS;
+if (llvm::find(MapModifiers, OMPC_MAP_MODIFIER_close)
+!= MapModifiers.end())
+  Bits |= OMP_MAP_CLOSE;
 return Bits;
   }
 
@@ -7686,7 +7692,7 @@
 // then we reset the TO/FROM/ALWAYS/DELETE flags.
 if (IsPointer)
   Flags &= ~(OMP_MAP_TO | OMP_MAP_FROM | OMP_MAP_ALWAYS |
- OMP_MAP_DELETE);
+ OMP_MAP_DELETE | OMP_MAP_CLOSE);
 
 if (ShouldBeMemberOf) {
   // Set placeholder value MEMBER_OF= to indicate that the flag
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D65030: [clang-doc] Add second index for sections within info's content

[Diego Astiazarán via Phabricator via cfe-commits]

DiegoAstiazaran added inline comments.



Comment at: clang-tools-extra/unittests/clang-doc/HTMLGeneratorTest.cpp:47-52
+
+  Namespaces
+  Records
+  Functions
+  OneFunction
+

juliehockett wrote:
> Formatting is a bit weird for sublists
Fixed by D65005. It will be properly formatted after rebasing.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65030/new/

https://reviews.llvm.org/D65030



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

[PATCH] D65110: [NewPM] Run avx*-builtins.c tests under the new pass manager only

[Leonard Chan via Phabricator via cfe-commits]

leonardchan added a comment.

*ping*


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65110/new/

https://reviews.llvm.org/D65110



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

[PATCH] D64454: [clang-tidy] Adding static analyzer check to list of clang-tidy checks

[Nathan Huckleberry via Phabricator via cfe-commits]

Nathan-Huckleberry updated this revision to Diff 211967.
Nathan-Huckleberry added a comment.

- Add in-tree as possible default location


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64454/new/

https://reviews.llvm.org/D64454

Files:
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-core.CallAndMessage.rst
  clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-core.DivideZero.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-core.DynamicTypePropagation.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-core.NonNullParamChecker.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-core.NullDereference.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-core.StackAddressEscape.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-core.UndefinedBinaryOperatorResult.rst
  clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-core.VLASize.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-core.uninitialized.ArraySubscript.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-core.uninitialized.Assign.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-core.uninitialized.Branch.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-core.uninitialized.CapturedBlockVariable.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-core.uninitialized.UndefReturn.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-cplusplus.InnerPointer.rst
  clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-cplusplus.Move.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-cplusplus.NewDelete.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-cplusplus.NewDeleteLeaks.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-deadcode.DeadStores.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-nullability.NullPassedToNonnull.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-nullability.NullReturnedFromNonnull.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-nullability.NullableDereferenced.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-nullability.NullablePassedToNonnull.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-nullability.NullableReturnedFromNonnull.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-optin.cplusplus.UninitializedObject.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-optin.cplusplus.VirtualCall.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-optin.mpi.MPI-Checker.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-optin.osx.OSObjectCStyleCast.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-optin.osx.cocoa.localizability.EmptyLocalizationContextChecker.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-optin.osx.cocoa.localizability.NonLocalizedStringChecker.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-optin.performance.GCDAntipattern.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-optin.performance.Padding.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-optin.portability.UnixAPI.rst
  clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-osx.API.rst
  clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-osx.MIG.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-osx.NumberObjectConversion.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-osx.OSObjectRetainCount.rst
  clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-osx.ObjCProperty.rst
  clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-osx.SecKeychainAPI.rst
  clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-osx.cocoa.AtSync.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-osx.cocoa.AutoreleaseWrite.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-osx.cocoa.ClassRelease.rst
  clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-osx.cocoa.Dealloc.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-osx.cocoa.IncompatibleMethodTypes.rst
  clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-osx.cocoa.Loops.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-osx.cocoa.MissingSuperCall.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-osx.cocoa.NSAutoreleasePool.rst
  clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-osx.cocoa.NSError.rst
  clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-osx.cocoa.NilArg.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-osx.cocoa.NonNilReturnValue.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-osx.cocoa.ObjCGenerics.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-osx.cocoa.RetainCount.rst
  
clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-osx.cocoa.RunLoopAutoreleaseLeak.rst
  clang-tools-extra/docs/clang-tidy/checks/clang-analyzer-osx.cocoa.SelfInit.

Re: [clang-tools-extra] r367112 - [clangd] Fix background index not triggering on windows due to case mismatch.

[Hans Wennborg via cfe-commits]

Merged to release_90 in r367135.

On Fri, Jul 26, 2019 at 7:06 AM Sam McCall via cfe-commits
 wrote:
>
> Author: sammccall
> Date: Fri Jul 26 07:07:11 2019
> New Revision: 367112
>
> URL: http://llvm.org/viewvc/llvm-project?rev=367112&view=rev
> Log:
> [clangd] Fix background index not triggering on windows due to case mismatch.
>
> Summary:
> This isn't a general fix to all paths where we assume case-sensitivity, it's
> a minimally-invasive fix targeting the llvm 9 branch.
>
> Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, cfe-commits
>
> Tags: #clang
>
> Differential Revision: https://reviews.llvm.org/D65320
>
> Modified:
> clang-tools-extra/trunk/clangd/GlobalCompilationDatabase.cpp
> clang-tools-extra/trunk/clangd/GlobalCompilationDatabase.h
>
> Modified: clang-tools-extra/trunk/clangd/GlobalCompilationDatabase.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/GlobalCompilationDatabase.cpp?rev=367112&r1=367111&r2=367112&view=diff
> ==
> --- clang-tools-extra/trunk/clangd/GlobalCompilationDatabase.cpp (original)
> +++ clang-tools-extra/trunk/clangd/GlobalCompilationDatabase.cpp Fri Jul 26 
> 07:07:11 2019
> @@ -117,20 +117,41 @@ DirectoryBasedGlobalCompilationDatabase:
>return None;
>  }
>
> -std::pair
> +// For platforms where paths are case-insensitive (but case-preserving),
> +// we need to do case-insensitive comparisons and use lowercase keys.
> +// FIXME: Make Path a real class with desired semantics instead.
> +//This class is not the only place this problem exists.
> +// FIXME: Mac filesystems default to case-insensitive, but may be sensitive.
> +
> +static std::string maybeCaseFoldPath(PathRef Path) {
> +#if defined(_WIN32) || defined(__APPLE__)
> +  return Path.lower();
> +#else
> +  return Path;
> +#endif
> +}
> +
> +static bool pathEqual(PathRef A, PathRef B) {
> +#if defined(_WIN32) || defined(__APPLE__)
> +  return A.equals_lower(B);
> +#else
> +  return A == B;
> +#endif
> +}
> +
> +DirectoryBasedGlobalCompilationDatabase::CachedCDB &
>  DirectoryBasedGlobalCompilationDatabase::getCDBInDirLocked(PathRef Dir) 
> const {
>// FIXME(ibiryukov): Invalidate cached compilation databases on changes
> -  auto CachedIt = CompilationDatabases.find(Dir);
> -  if (CachedIt != CompilationDatabases.end())
> -return {CachedIt->second.CDB.get(), CachedIt->second.SentBroadcast};
> -  std::string Error = "";
> -
> -  CachedCDB Entry;
> -  Entry.CDB = tooling::CompilationDatabase::loadFromDirectory(Dir, Error);
> -  auto Result = Entry.CDB.get();
> -  CompilationDatabases[Dir] = std::move(Entry);
> -
> -  return {Result, false};
> +  // FIXME(sammccall): this function hot, avoid copying key when hitting 
> cache.
> +  auto Key = maybeCaseFoldPath(Dir);
> +  auto R = CompilationDatabases.try_emplace(Key);
> +  if (R.second) { // Cache miss, try to load CDB.
> +CachedCDB &Entry = R.first->second;
> +std::string Error = "";
> +Entry.CDB = tooling::CompilationDatabase::loadFromDirectory(Dir, Error);
> +Entry.Path = Dir;
> +  }
> +  return R.first->second;
>  }
>
>  llvm::Optional
> @@ -139,38 +160,41 @@ DirectoryBasedGlobalCompilationDatabase:
>assert(llvm::sys::path::is_absolute(Request.FileName) &&
>   "path must be absolute");
>
> +  bool ShouldBroadcast = false;
>CDBLookupResult Result;
> -  bool SentBroadcast = false;
>
>{
>  std::lock_guard Lock(Mutex);
> +CachedCDB *Entry = nullptr;
>  if (CompileCommandsDir) {
> -  std::tie(Result.CDB, SentBroadcast) =
> -  getCDBInDirLocked(*CompileCommandsDir);
> -  Result.PI.SourceRoot = *CompileCommandsDir;
> +  Entry = &getCDBInDirLocked(*CompileCommandsDir);
>  } else {
>// Traverse the canonical version to prevent false positives. i.e.:
>// src/build/../a.cc can detect a CDB in /src/build if not 
> canonicalized.
> +  // FIXME(sammccall): this loop is hot, use a union-find-like structure.
>actOnAllParentDirectories(removeDots(Request.FileName),
> -[this, &SentBroadcast, &Result](PathRef 
> Path) {
> -  std::tie(Result.CDB, SentBroadcast) =
> -  getCDBInDirLocked(Path);
> -  Result.PI.SourceRoot = Path;
> -  return Result.CDB != nullptr;
> +[&](PathRef Path) {
> +  Entry = &getCDBInDirLocked(Path);
> +  return Entry->CDB != nullptr;
>  });
>  }
>
> -if (!Result.CDB)
> +if (!Entry || !Entry->CDB)
>return llvm::None;
>
>  // Mark CDB as broadcasted to make sure discovery is performed once.
> -if (Request.ShouldBroadcast && !SentBroadcast)
> -  CompilationDatabases[Result.PI.SourceRoot].SentBroadcast 

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added inline comments.



Comment at: lib/CodeGen/CGOpenMPRuntime.h:815
+  /// code generation.
+  void emitUDMapperArrayInitOrDel(CodeGenFunction &MapperCGF,
+  llvm::Value *Handle, llvm::Value *BasePtr,

Seems to me, this function is used only in `emitUserDefinedMapper`. I think you 
can make it static local in the CGOpenMPRuntime.cpp and do not expose it in the 
interface.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59474/new/

https://reviews.llvm.org/D59474



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