date:20191016

[PATCH] D69022: [coroutines] Remove assert on CoroutineParameterMoves in Sema::buildCoroutineParameterMoves

2019-10-16 Thread JunMa via Phabricator via cfe-commits

junparser created this revision.
junparser added reviewers: modocache, GorNishanov.
Herald added subscribers: cfe-commits, EricWF.
Herald added a project: clang.

The assertion of CoroutineParameterMoves happens when build coroutine function 
with arguments  multiple time while fails to build promise type.

Fix: use return false instead.

Test Plan: check-clang


Repository:
  rC Clang

https://reviews.llvm.org/D69022

Files:
  lib/Sema/SemaCoroutine.cpp
  test/SemaCXX/coroutines.cpp


Index: test/SemaCXX/coroutines.cpp
===
--- test/SemaCXX/coroutines.cpp
+++ test/SemaCXX/coroutines.cpp
@@ -87,6 +87,11 @@
   co_await a;
 }
 
+int no_promise_type_2(int a) { // expected-error {{this function cannot be a 
coroutine: 'std::experimental::coroutine_traits' has no member named 
'promise_type'}}
+  co_await a;
+  co_await a;
+}
+
 template <>
 struct std::experimental::coroutine_traits { typedef int 
promise_type; };
 double bad_promise_type(double) { // expected-error {{this function cannot be 
a coroutine: 'experimental::coroutine_traits::promise_type' 
(aka 'int') is not a class}}
Index: lib/Sema/SemaCoroutine.cpp
===
--- lib/Sema/SemaCoroutine.cpp
+++ lib/Sema/SemaCoroutine.cpp
@@ -1526,8 +1526,8 @@
   auto *FD = cast(CurContext);
 
   auto *ScopeInfo = getCurFunction();
-  assert(ScopeInfo->CoroutineParameterMoves.empty() &&
- "Should not build parameter moves twice");
+  if (!ScopeInfo->CoroutineParameterMoves.empty())
+return false;
 
   for (auto *PD : FD->parameters()) {
 if (PD->getType()->isDependentType())


Index: test/SemaCXX/coroutines.cpp
===
--- test/SemaCXX/coroutines.cpp
+++ test/SemaCXX/coroutines.cpp
@@ -87,6 +87,11 @@
   co_await a;
 }
 
+int no_promise_type_2(int a) { // expected-error {{this function cannot be a coroutine: 'std::experimental::coroutine_traits' has no member named 'promise_type'}}
+  co_await a;
+  co_await a;
+}
+
 template <>
 struct std::experimental::coroutine_traits { typedef int promise_type; };
 double bad_promise_type(double) { // expected-error {{this function cannot be a coroutine: 'experimental::coroutine_traits::promise_type' (aka 'int') is not a class}}
Index: lib/Sema/SemaCoroutine.cpp
===
--- lib/Sema/SemaCoroutine.cpp
+++ lib/Sema/SemaCoroutine.cpp
@@ -1526,8 +1526,8 @@
   auto *FD = cast(CurContext);
 
   auto *ScopeInfo = getCurFunction();
-  assert(ScopeInfo->CoroutineParameterMoves.empty() &&
- "Should not build parameter moves twice");
+  if (!ScopeInfo->CoroutineParameterMoves.empty())
+return false;
 
   for (auto *PD : FD->parameters()) {
 if (PD->getType()->isDependentType())
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D53137: Scalable vector core instruction support + size queries

2019-10-16 Thread Diana Picus via cfe-commits

Hi Graham,

It seems you forgot to push the last round of fixes. Just saying :)

Cheers,
Diana

On Tue, 8 Oct 2019 at 16:01, Graham Hunter via Phabricator
 wrote:
>
> huntergr added a comment.
>
> Hmm, forgot to add the last round of minor fixes before committing. Sorry 
> about that, will push them as well.
>
>
> Repository:
>   rG LLVM Github Monorepo
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D53137/new/
>
> https://reviews.llvm.org/D53137
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D69011: Replace platform-dependent `stat` with `llvm::sys::fs::status`. NFC intended.

2019-10-16 Thread Sam McCall via Phabricator via cfe-commits

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

Watching for regressions in stat calls sounds really useful.

This change is trivially equivalent on linux, but the code path is quite 
different on windows (I have no idea how ::stat works on windows, but our 
implementation of fs::status does lots of things).
I don't imagine it'll matter here though, and the original commits don't seem 
to have avoided fs::status on purpose.


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

https://reviews.llvm.org/D69011



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

[PATCH] D68977: [clangd] Report declaration references in findExplicitReferences.

2019-10-16 Thread Ilya Biryukov via Phabricator via cfe-commits

ilya-biryukov added a comment.

Mostly LG, but please take a look at the NITs and the implementation-related 
comments.




Comment at: clang-tools-extra/clangd/FindTarget.cpp:415
 
 Optional refInDecl(const Decl *D) {
   struct Visitor : ConstDeclVisitor {

This should return `SmallVector` now, some declarations can 
have both decl and non-decl references.



Comment at: clang-tools-extra/clangd/FindTarget.cpp:418
 llvm::Optional Ref;
-
+bool DeclRef = true;
 void VisitUsingDirectiveDecl(const UsingDirectiveDecl *D) {

We don't need this flag, in every case we now whether a reference points to a 
decl or not.



Comment at: clang-tools-extra/clangd/FindTarget.cpp:439
+
+void VisitTagDecl(const TagDecl *ND) {
+  Ref =

Similar to `DeclaratorDecl`, let's handle this in `VisitNamedDecl`



Comment at: clang-tools-extra/clangd/FindTarget.cpp:444
+
+void VisitDeclaratorDecl(const DeclaratorDecl *ND) {
+  Ref =

This should be handled in `VisitNamedDecl`, we should use a helper similar to 
`getQualifier` from `AST.h` to get the qualifier loc instead.



Comment at: clang-tools-extra/clangd/FindTarget.cpp:464
 llvm::Optional Ref;
-
+bool NotDeclRef = false;
 void VisitDeclRefExpr(const DeclRefExpr *E) {

NIT: don't use negative flags, they are hard to read. Prefer `IsDeclRef`



Comment at: clang-tools-extra/clangd/FindTarget.cpp:468
+ E->getNameInfo().getLoc(),
+ NotDeclRef,
+ {E->getFoundDecl()}};

Why do we need this in the first place?
Expressions never declare anything, just pass `false` here



Comment at: clang-tools-extra/clangd/FindTarget.cpp:495
 llvm::Optional Ref;
-
+bool NotDeclRef = false;
 void VisitElaboratedTypeLoc(ElaboratedTypeLoc L) {

Same here: types don't declare anything normally, remove this field and use 
`false` directly instead.



Comment at: clang-tools-extra/clangd/FindTarget.cpp:669
   CCI->getMemberLocation(),
+  false,
   {CCI->getAnyMember()}};

NIT: please add `/*IsDecl=*/` comment here and in other places to make reading 
the code simpler.



Comment at: clang-tools-extra/clangd/FindTarget.cpp:756
+  if (R.IsDecl)
+OS << ", decl ref";
   return OS;

NIT: maybe use `declaration` instead?
`ref` is definitely redundant, we know we're printing a reference.



Comment at: clang-tools-extra/clangd/FindTarget.h:90
+  /// True if the reference is a declaration or definition;
+  bool IsDecl;
   // FIXME: add info about template arguments.

Initialize to make sure we can't ever have UB when using this struct.



Comment at: clang-tools-extra/clangd/unittests/FindTargetTests.cpp:528
+  /// AST.
+  AllRefs annotateReferencesInMainAST(llvm::StringRef Code) {
+TestTU TU;

Why do we need this? Can't we test everything we do by putting into `foo`?

The original idea was to avoid too much output in the tests by letting the 
setup code live outside the function that's being annotated.
Any reason why we have to do the full file here?

I know it's a weird limitation, but that's one that was already made and I'd 
keep it this way if it's possible.



Comment at: clang-tools-extra/clangd/unittests/FindTargetTests.cpp:613
 )cpp",
-   "0: targets = {ns}\n"
-   "1: targets = {alias}\n"},
+   "0: targets = {ns}, decl ref\n"
+   "1: targets = {alias}, decl ref\n"},

We should keep these non-declaration references.
The actual `using namespace` declaration does not have a name, so we don't 
report a `declaration` there


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68977



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

[PATCH] D68937: [clangd] Add parameter renaming to define-inline code action

2019-10-16 Thread Ilya Biryukov via Phabricator via cfe-commits

ilya-biryukov added a comment.

An alternative approach I'm thinking of:
After D68977  lands, we could try using 
`findExplicitReferences` to produce all of these edits:

1. we collect locations of all references and declaration of relevant 
parameters and template parameters.
2. find the ones where the name differs and produce the changes.

That would handle not only references in the default argument, but also all 
references in the body and should be less code overall.
IMO it's worth exploring this approach right away, e.g. you could layer your 
patch on top of the current version of D68977 




Comment at: clang-tools-extra/clangd/refactor/tweaks/DefineInline.cpp:229
 
+/// Generates a replacement that renames \p Dest to \p Source.
+llvm::Error rewriteParameterName(tooling::Replacements &Replacements,

We only need name from the `Source`. Why not accept it as a `StringRef Name` 
directly?
Would allow to call this function even if `Source` is not a `NamedDecl`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68937



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

[PATCH] D69025: [Driver,ARM] Make -mfloat-abi=soft turn off MVE.

2019-10-16 Thread Simon Tatham via Phabricator via cfe-commits

simon_tatham created this revision.
simon_tatham added a reviewer: dmgreen.
Herald added subscribers: cfe-commits, kristof.beyls.
Herald added a project: clang.

Since `-mfloat-abi=soft` is taken to mean turning off all uses of the
FP registers, it should turn off the MVE vector instructions as well
as NEON and scalar FP. But it wasn't doing so.

So the options `-march=armv8.1-m.main+mve.fp+fp.dp -mfloat-abi=soft`
would cause the underlying LLVM to //not// support MVE (because it
knows the real target feature relationships and turned off MVE when
the `fpregs` feature was removed), but the clang layer still thought
it //was// supported, and would misleadingly define the feature macro
`__ARM_FEATURE_MVE`.

The ARM driver code already has a long list of feature names to turn
off when `-mfloat-abi=soft` is selected. The fix is to add the missing
entries `mve` and `mve.fp` to that list.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D69025

Files:
  clang/lib/Driver/ToolChains/Arch/ARM.cpp
  clang/test/Driver/arm-mfpu.c


Index: clang/test/Driver/arm-mfpu.c
===
--- clang/test/Driver/arm-mfpu.c
+++ clang/test/Driver/arm-mfpu.c
@@ -397,3 +397,9 @@
 // CHECK-ARM7-ANDROID-FP-D16-NOT: "-target-feature" "+fp-armv8"
 // CHECK-ARM7-ANDROID-FP-D16-NOT: "-target-feature" "+neon"
 // CHECK-ARM7-ANDROID-FP-D16-NOT: "-target-feature" "+crypto"
+
+// RUN: %clang -target arm-none-none-eabi %s 
-march=armv8.1-m.main+mve.fp+fp.dp -mfloat-abi=soft -### -c 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-SOFTFLOATABI-INHIBITS-MVE %s
+// CHECK-SOFTFLOATABI-INHIBITS-MVE-NOT: "-target-feature" "+mve"
+// CHECK-SOFTFLOATABI-INHIBITS-MVE-DAG: "-target-feature" "-mve"
+// CHECK-SOFTFLOATABI-INHIBITS-MVE-DAG: "-target-feature" "-mve.fp"
Index: clang/lib/Driver/ToolChains/Arch/ARM.cpp
===
--- clang/lib/Driver/ToolChains/Arch/ARM.cpp
+++ clang/lib/Driver/ToolChains/Arch/ARM.cpp
@@ -465,6 +465,7 @@
 "vfp4", "vfp4sp", "vfp4d16", "vfp4d16sp",
 "fp-armv8", "fp-armv8sp", "fp-armv8d16", "fp-armv8d16sp",
 "fullfp16", "neon", "crypto", "dotprod", "fp16fml",
+"mve", "mve.fp",
 "fp64", "d32", "fpregs"})
   Features.push_back(Args.MakeArgString("-" + Feature));
   }


Index: clang/test/Driver/arm-mfpu.c
===
--- clang/test/Driver/arm-mfpu.c
+++ clang/test/Driver/arm-mfpu.c
@@ -397,3 +397,9 @@
 // CHECK-ARM7-ANDROID-FP-D16-NOT: "-target-feature" "+fp-armv8"
 // CHECK-ARM7-ANDROID-FP-D16-NOT: "-target-feature" "+neon"
 // CHECK-ARM7-ANDROID-FP-D16-NOT: "-target-feature" "+crypto"
+
+// RUN: %clang -target arm-none-none-eabi %s -march=armv8.1-m.main+mve.fp+fp.dp -mfloat-abi=soft -### -c 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-SOFTFLOATABI-INHIBITS-MVE %s
+// CHECK-SOFTFLOATABI-INHIBITS-MVE-NOT: "-target-feature" "+mve"
+// CHECK-SOFTFLOATABI-INHIBITS-MVE-DAG: "-target-feature" "-mve"
+// CHECK-SOFTFLOATABI-INHIBITS-MVE-DAG: "-target-feature" "-mve.fp"
Index: clang/lib/Driver/ToolChains/Arch/ARM.cpp
===
--- clang/lib/Driver/ToolChains/Arch/ARM.cpp
+++ clang/lib/Driver/ToolChains/Arch/ARM.cpp
@@ -465,6 +465,7 @@
 "vfp4", "vfp4sp", "vfp4d16", "vfp4d16sp",
 "fp-armv8", "fp-armv8sp", "fp-armv8d16", "fp-armv8d16sp",
 "fullfp16", "neon", "crypto", "dotprod", "fp16fml",
+"mve", "mve.fp",
 "fp64", "d32", "fpregs"})
   Features.push_back(Args.MakeArgString("-" + Feature));
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D68562: [clangd] Add RemoveUsingNamespace tweak.

2019-10-16 Thread UTKARSH SAXENA via Phabricator via cfe-commits

usaxena95 updated this revision to Diff 225183.
usaxena95 marked 11 inline comments as done.
usaxena95 added a comment.

Addressed comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68562

Files:
  clang-tools-extra/clangd/AST.cpp
  clang-tools-extra/clangd/AST.h
  clang-tools-extra/clangd/refactor/tweaks/CMakeLists.txt
  clang-tools-extra/clangd/refactor/tweaks/RemoveUsingNamespace.cpp
  clang-tools-extra/clangd/unittests/TweakTests.cpp

Index: clang-tools-extra/clangd/unittests/TweakTests.cpp
===
--- clang-tools-extra/clangd/unittests/TweakTests.cpp
+++ clang-tools-extra/clangd/unittests/TweakTests.cpp
@@ -69,7 +69,8 @@
   EXPECT_EQ(apply("^if (true) {return 100;} else {continue;}"),
 "if (true) {continue;} else {return 100;}");
   EXPECT_EQ(apply("^if () {return 100;} else {continue;}"),
-"if () {continue;} else {return 100;}") << "broken condition";
+"if () {continue;} else {return 100;}")
+  << "broken condition";
   EXPECT_AVAILABLE("^i^f^^(^t^r^u^e^) { return 100; } ^e^l^s^e^ { continue; }");
   EXPECT_UNAVAILABLE("if (true) {^return ^100;^ } else { ^continue^;^ }");
   // Available in subexpressions of the condition;
@@ -100,7 +101,7 @@
   EXPECT_UNAVAILABLE(R"cpp(R"(multi )" ^"token " u8"str\ning")cpp"); // nonascii
   EXPECT_UNAVAILABLE(R"cpp(^R^"^(^multi )" "token " "str\ning")cpp"); // raw
   EXPECT_UNAVAILABLE(R"cpp(^"token\n" __FILE__)cpp"); // chunk is macro
-  EXPECT_UNAVAILABLE(R"cpp(^"a\r\n";)cpp"); // forbidden escape char
+  EXPECT_UNAVAILABLE(R"cpp(^"a\r\n";)cpp");   // forbidden escape char
 
   const char *Input = R"cpp(R"(multi
 token)" "\nst^ring\n" "literal")cpp";
@@ -286,11 +287,11 @@
  void f(int a) {
int y = PLUS([[1+a]]);
  })cpp",
-  /*FIXME: It should be extracted like this.
-   R"cpp(#define PLUS(x) x++
- void f(int a) {
-   auto dummy = 1+a; int y = PLUS(dummy);
- })cpp"},*/
+   /*FIXME: It should be extracted like this.
+R"cpp(#define PLUS(x) x++
+  void f(int a) {
+auto dummy = 1+a; int y = PLUS(dummy);
+  })cpp"},*/
R"cpp(#define PLUS(x) x++
  void f(int a) {
auto dummy = PLUS(1+a); int y = dummy;
@@ -301,13 +302,13 @@
if(1)
 LOOP(5 + [[3]])
  })cpp",
-  /*FIXME: It should be extracted like this. SelectionTree needs to be
-* fixed for macros.
-   R"cpp(#define LOOP(x) while (1) {a = x;}
-   void f(int a) {
- auto dummy = 3; if(1)
-  LOOP(5 + dummy)
-   })cpp"},*/
+   /*FIXME: It should be extracted like this. SelectionTree needs to be
+ * fixed for macros.
+R"cpp(#define LOOP(x) while (1) {a = x;}
+void f(int a) {
+  auto dummy = 3; if(1)
+   LOOP(5 + dummy)
+})cpp"},*/
R"cpp(#define LOOP(x) while (1) {a = x;}
  void f(int a) {
auto dummy = LOOP(5 + 3); if(1)
@@ -403,8 +404,8 @@
  void f() {
auto dummy = S(2) + S(3) + S(4); S x = S(1) + dummy + S(5);
  })cpp"},
-   // Don't try to analyze across macro boundaries
-   // FIXME: it'd be nice to do this someday (in a safe way)
+  // Don't try to analyze across macro boundaries
+  // FIXME: it'd be nice to do this someday (in a safe way)
   {R"cpp(#define ECHO(X) X
  void f() {
int x = 1 + [[ECHO(2 + 3) + 4]] + 5;
@@ -519,7 +520,7 @@
   StartsWith("fail: Could not expand type of lambda expression"));
   // inline namespaces
   EXPECT_EQ(apply("au^to x = inl_ns::Visible();"),
-  "Visible x = inl_ns::Visible();");
+"Visible x = inl_ns::Visible();");
   // local class
   EXPECT_EQ(apply("namespace x { void y() { struct S{}; ^auto z = S(); } }"),
 "namespace x { void y() { struct S{}; S z = S(); } }");
@@ -663,6 +664,222 @@
   EXPECT_THAT(apply(" for(;;) { [[while(1) break; break;]] }"),
   StartsWith("fail"));
 }
+
+TWEAK_TEST(RemoveUsingNamespace);
+TEST_F(RemoveUsingNamespaceTest, All) {
+  std::pair Cases[] = {
+  {// Remove all occurrences of ns. Qualify only unqualified.
+   R"cpp(
+  namespace ns1 { struct vector {}; }
+  namespace ns2 { struct map {}; }
+  using namespace n^s1;
+  using namespace ns2;
+  using namespace ns1;
+  int main() {
+ns1::vector v1;
+vector v2;
+map m1;
+  }
+)cpp",
+   R"cpp(
+  namespace ns1 { struct vector {}; }
+  namespace

[clang-tools-extra] r374982 - [clangd] Add RemoveUsingNamespace tweak.

2019-10-16 Thread Utkarsh Saxena via cfe-commits

Author: usaxena95
Date: Wed Oct 16 02:53:59 2019
New Revision: 374982

URL: http://llvm.org/viewvc/llvm-project?rev=374982&view=rev
Log:
[clangd] Add RemoveUsingNamespace tweak.

Summary:
Removes the 'using namespace' under the cursor and qualifies all accesses in 
the current file.
E.g.:
  using namespace std;
  vector foo(std::map);
Would become:
  std::vector foo(std::map);

Subscribers: mgorny, ilya-biryukov, MaskRay, jkorous, mgrang, arphaman, 
kadircet, cfe-commits

Tags: #clang

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

Added:
clang-tools-extra/trunk/clangd/refactor/tweaks/RemoveUsingNamespace.cpp
Modified:
clang-tools-extra/trunk/clangd/AST.cpp
clang-tools-extra/trunk/clangd/AST.h
clang-tools-extra/trunk/clangd/refactor/tweaks/CMakeLists.txt
clang-tools-extra/trunk/clangd/unittests/TweakTests.cpp

Modified: clang-tools-extra/trunk/clangd/AST.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/AST.cpp?rev=374982&r1=374981&r2=374982&view=diff
==
--- clang-tools-extra/trunk/clangd/AST.cpp (original)
+++ clang-tools-extra/trunk/clangd/AST.cpp Wed Oct 16 02:53:59 2019
@@ -115,6 +115,18 @@ static NestedNameSpecifier *getQualifier
   return nullptr;
 }
 
+std::string printUsingNamespaceName(const ASTContext &Ctx,
+const UsingDirectiveDecl &D) {
+  PrintingPolicy PP(Ctx.getLangOpts());
+  std::string Name;
+  llvm::raw_string_ostream Out(Name);
+
+  if (auto *Qual = D.getQualifier())
+Qual->print(Out, PP);
+  D.getNominatedNamespaceAsWritten()->printName(Out);
+  return Out.str();
+}
+
 std::string printName(const ASTContext &Ctx, const NamedDecl &ND) {
   std::string Name;
   llvm::raw_string_ostream Out(Name);

Modified: clang-tools-extra/trunk/clangd/AST.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/AST.h?rev=374982&r1=374981&r2=374982&view=diff
==
--- clang-tools-extra/trunk/clangd/AST.h (original)
+++ clang-tools-extra/trunk/clangd/AST.h Wed Oct 16 02:53:59 2019
@@ -42,6 +42,12 @@ std::string printQualifiedName(const Nam
 /// Returns the first enclosing namespace scope starting from \p DC.
 std::string printNamespaceScope(const DeclContext &DC);
 
+/// Returns the name of the namespace inside the 'using namespace' directive, 
as
+/// written in the code. E.g., passing 'using namespace ::std' will result in
+/// '::std'.
+std::string printUsingNamespaceName(const ASTContext &Ctx,
+const UsingDirectiveDecl &D);
+
 /// Prints unqualified name of the decl for the purpose of displaying it to the
 /// user. Anonymous decls return names of the form "(anonymous {kind})", e.g.
 /// "(anonymous struct)" or "(anonymous namespace)".

Modified: clang-tools-extra/trunk/clangd/refactor/tweaks/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/refactor/tweaks/CMakeLists.txt?rev=374982&r1=374981&r2=374982&view=diff
==
--- clang-tools-extra/trunk/clangd/refactor/tweaks/CMakeLists.txt (original)
+++ clang-tools-extra/trunk/clangd/refactor/tweaks/CMakeLists.txt Wed Oct 16 
02:53:59 2019
@@ -19,6 +19,7 @@ add_clang_library(clangDaemonTweaks OBJE
   ExtractFunction.cpp
   ExtractVariable.cpp
   RawStringLiteral.cpp
+  RemoveUsingNamespace.cpp
   SwapIfBranches.cpp
 
   LINK_LIBS

Added: clang-tools-extra/trunk/clangd/refactor/tweaks/RemoveUsingNamespace.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/refactor/tweaks/RemoveUsingNamespace.cpp?rev=374982&view=auto
==
--- clang-tools-extra/trunk/clangd/refactor/tweaks/RemoveUsingNamespace.cpp 
(added)
+++ clang-tools-extra/trunk/clangd/refactor/tweaks/RemoveUsingNamespace.cpp Wed 
Oct 16 02:53:59 2019
@@ -0,0 +1,206 @@
+//===--- RemoveUsingNamespace.cpp *- 
C++-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+#include "AST.h"
+#include "FindTarget.h"
+#include "Selection.h"
+#include "SourceCode.h"
+#include "refactor/Tweak.h"
+#include "clang/AST/Decl.h"
+#include "clang/AST/DeclBase.h"
+#include "clang/AST/DeclCXX.h"
+#include "clang/AST/RecursiveASTVisitor.h"
+#include "clang/Basic/SourceLocation.h"
+#include "clang/Tooling/Core/Replacement.h"
+#include "clang/Tooling/Refactoring/RecursiveSymbolVisitor.h"
+#include "llvm/ADT/ScopeExit.h"
+
+namespace clang {
+namespace clangd {
+namespace {
+/// Removes the 'using namespace' under the cursor and qualifies all accesses

[PATCH] D68562: [clangd] Add RemoveUsingNamespace tweak.

2019-10-16 Thread UTKARSH SAXENA via Phabricator via cfe-commits

usaxena95 added inline comments.



Comment at: 
clang-tools-extra/clangd/refactor/tweaks/RemoveUsingNamespace.cpp:139
+  SourceLocation FirstUsingDirectiveLoc =
+  SM.getLocForEndOfFile(SM.getMainFileID());
+  for (auto *D : AllDirectives) {

ilya-biryukov wrote:
> I'm not 100% certain this is considered to be the end location, as there 
> macros, etc.
> Could we instead start with an invalid source location
Replaced it with uninitialized (which is invalid) SourceLocation. Makes it 
simpler. 



Comment at: clang-tools-extra/clangd/unittests/TweakTests.cpp:810
+  using namespace a::[[b]];
+  using namespace b;
+  int main() { Foo F;}

ilya-biryukov wrote:
> What happens if we remove this one?
> Will it still qualify as `a::b` or as `b::`?
> 
> Could we add a test just to document the behavior?
It qualifies as `b::`. Added a test for it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68562



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

[PATCH] D68562: [clangd] Add RemoveUsingNamespace tweak.

2019-10-16 Thread UTKARSH SAXENA via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rGb62b45412168: [clangd] Add RemoveUsingNamespace tweak. 
(authored by usaxena95).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68562

Files:
  clang-tools-extra/clangd/AST.cpp
  clang-tools-extra/clangd/AST.h
  clang-tools-extra/clangd/refactor/tweaks/CMakeLists.txt
  clang-tools-extra/clangd/refactor/tweaks/RemoveUsingNamespace.cpp
  clang-tools-extra/clangd/unittests/TweakTests.cpp

Index: clang-tools-extra/clangd/unittests/TweakTests.cpp
===
--- clang-tools-extra/clangd/unittests/TweakTests.cpp
+++ clang-tools-extra/clangd/unittests/TweakTests.cpp
@@ -69,7 +69,8 @@
   EXPECT_EQ(apply("^if (true) {return 100;} else {continue;}"),
 "if (true) {continue;} else {return 100;}");
   EXPECT_EQ(apply("^if () {return 100;} else {continue;}"),
-"if () {continue;} else {return 100;}") << "broken condition";
+"if () {continue;} else {return 100;}")
+  << "broken condition";
   EXPECT_AVAILABLE("^i^f^^(^t^r^u^e^) { return 100; } ^e^l^s^e^ { continue; }");
   EXPECT_UNAVAILABLE("if (true) {^return ^100;^ } else { ^continue^;^ }");
   // Available in subexpressions of the condition;
@@ -100,7 +101,7 @@
   EXPECT_UNAVAILABLE(R"cpp(R"(multi )" ^"token " u8"str\ning")cpp"); // nonascii
   EXPECT_UNAVAILABLE(R"cpp(^R^"^(^multi )" "token " "str\ning")cpp"); // raw
   EXPECT_UNAVAILABLE(R"cpp(^"token\n" __FILE__)cpp"); // chunk is macro
-  EXPECT_UNAVAILABLE(R"cpp(^"a\r\n";)cpp"); // forbidden escape char
+  EXPECT_UNAVAILABLE(R"cpp(^"a\r\n";)cpp");   // forbidden escape char
 
   const char *Input = R"cpp(R"(multi
 token)" "\nst^ring\n" "literal")cpp";
@@ -286,11 +287,11 @@
  void f(int a) {
int y = PLUS([[1+a]]);
  })cpp",
-  /*FIXME: It should be extracted like this.
-   R"cpp(#define PLUS(x) x++
- void f(int a) {
-   auto dummy = 1+a; int y = PLUS(dummy);
- })cpp"},*/
+   /*FIXME: It should be extracted like this.
+R"cpp(#define PLUS(x) x++
+  void f(int a) {
+auto dummy = 1+a; int y = PLUS(dummy);
+  })cpp"},*/
R"cpp(#define PLUS(x) x++
  void f(int a) {
auto dummy = PLUS(1+a); int y = dummy;
@@ -301,13 +302,13 @@
if(1)
 LOOP(5 + [[3]])
  })cpp",
-  /*FIXME: It should be extracted like this. SelectionTree needs to be
-* fixed for macros.
-   R"cpp(#define LOOP(x) while (1) {a = x;}
-   void f(int a) {
- auto dummy = 3; if(1)
-  LOOP(5 + dummy)
-   })cpp"},*/
+   /*FIXME: It should be extracted like this. SelectionTree needs to be
+ * fixed for macros.
+R"cpp(#define LOOP(x) while (1) {a = x;}
+void f(int a) {
+  auto dummy = 3; if(1)
+   LOOP(5 + dummy)
+})cpp"},*/
R"cpp(#define LOOP(x) while (1) {a = x;}
  void f(int a) {
auto dummy = LOOP(5 + 3); if(1)
@@ -403,8 +404,8 @@
  void f() {
auto dummy = S(2) + S(3) + S(4); S x = S(1) + dummy + S(5);
  })cpp"},
-   // Don't try to analyze across macro boundaries
-   // FIXME: it'd be nice to do this someday (in a safe way)
+  // Don't try to analyze across macro boundaries
+  // FIXME: it'd be nice to do this someday (in a safe way)
   {R"cpp(#define ECHO(X) X
  void f() {
int x = 1 + [[ECHO(2 + 3) + 4]] + 5;
@@ -519,7 +520,7 @@
   StartsWith("fail: Could not expand type of lambda expression"));
   // inline namespaces
   EXPECT_EQ(apply("au^to x = inl_ns::Visible();"),
-  "Visible x = inl_ns::Visible();");
+"Visible x = inl_ns::Visible();");
   // local class
   EXPECT_EQ(apply("namespace x { void y() { struct S{}; ^auto z = S(); } }"),
 "namespace x { void y() { struct S{}; S z = S(); } }");
@@ -663,6 +664,222 @@
   EXPECT_THAT(apply(" for(;;) { [[while(1) break; break;]] }"),
   StartsWith("fail"));
 }
+
+TWEAK_TEST(RemoveUsingNamespace);
+TEST_F(RemoveUsingNamespaceTest, All) {
+  std::pair Cases[] = {
+  {// Remove all occurrences of ns. Qualify only unqualified.
+   R"cpp(
+  namespace ns1 { struct vector {}; }
+  namespace ns2 { struct map {}; }
+  using namespace n^s1;
+  using namespace ns2;
+  using namespace ns1;
+  int main() {
+ns1::vector v1;
+vector v2;
+map m1;
+  }
+)cpp",
+   R"cpp(
+  namespace ns1 { stru

[PATCH] D68838: [ARM] Fix arm_neon.h with -flax-vector-conversions=none, part 3

2019-10-16 Thread Sjoerd Meijer via Phabricator via cfe-commits

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

Yep, thanks again!


Repository:
  rC Clang

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

https://reviews.llvm.org/D68838



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

[PATCH] D41569: [Concepts] Constraint enforcement and diagnostics

2019-10-16 Thread Nico Weber via Phabricator via cfe-commits

thakis added a comment.

The mangling test fails on Windows:
http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/15944

It also fails on ppc64le:
http://lab.llvm.org:8011/builders/clang-ppc64le-linux-lnt/builds/21092

Please watch http://lab.llvm.org:8011/console for a bit after landing changes.


Repository:
  rC Clang

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

https://reviews.llvm.org/D41569



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

[PATCH] D68969: [clang-format] Remove the dependency on frontend

2019-10-16 Thread Manuel Klimek via Phabricator via cfe-commits

klimek added a comment.

In D68969#1709696 , @MyDeveloperDay 
wrote:

> In D68969#1709321 , @klimek wrote:
>
> > My intuitive solution would have been to get the char* for the start and 
> > end-location and then search forward and backwards for \n.
>
>
> I may need to, it feels slow for large files which I suspect is in the 
> splitting, which will be mostly unnecessary.


It's a weird trade-off: for lots of lines, the inside-out algorithm will be 
better, but if we have a very very long line with lots of warnings, the 
inside-out algorithm will be quadratic.


Repository:
  rC Clang

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

https://reviews.llvm.org/D68969



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

r374985 - Revert 374967 "[Concepts] ConceptSpecializationExprs mangling"

2019-10-16 Thread Nico Weber via cfe-commits

Author: nico
Date: Wed Oct 16 03:23:53 2019
New Revision: 374985

URL: http://llvm.org/viewvc/llvm-project?rev=374985&view=rev
Log:
Revert 374967 "[Concepts] ConceptSpecializationExprs mangling"

This reverts commit 5e34ad109ced8dbdea9500ee28180315b2aeba3d.

The mangling test fails on Windows:
http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/15944

It also fails on ppc64le:
http://lab.llvm.org:8011/builders/clang-ppc64le-linux-lnt/builds/21092

Also revert follow-up  374971 "Fix failing mangle-concept.cpp test."
(it did not help on Win/ppc64le).

Removed:
cfe/trunk/test/CodeGenCXX/mangle-concept.cpp
Modified:
cfe/trunk/lib/AST/ItaniumMangle.cpp
cfe/trunk/lib/Sema/SemaTemplate.cpp

Modified: cfe/trunk/lib/AST/ItaniumMangle.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ItaniumMangle.cpp?rev=374985&r1=374984&r2=374985&view=diff
==
--- cfe/trunk/lib/AST/ItaniumMangle.cpp (original)
+++ cfe/trunk/lib/AST/ItaniumMangle.cpp Wed Oct 16 03:23:53 2019
@@ -969,7 +969,7 @@ void CXXNameMangler::mangleUnscopedTempl
 assert(!AdditionalAbiTags &&
"template template param cannot have abi tags");
 mangleTemplateParameter(TTP->getDepth(), TTP->getIndex());
-  } else if (isa(ND) || isa(ND)) {
+  } else if (isa(ND)) {
 mangleUnscopedName(ND, AdditionalAbiTags);
   } else {
 mangleUnscopedName(ND->getTemplatedDecl(), AdditionalAbiTags);
@@ -1890,7 +1890,7 @@ void CXXNameMangler::mangleTemplatePrefi
 mangleTemplateParameter(TTP->getDepth(), TTP->getIndex());
   } else {
 manglePrefix(getEffectiveDeclContext(ND), NoFunction);
-if (isa(ND) || isa(ND))
+if (isa(ND))
   mangleUnqualifiedName(ND, nullptr);
 else
   mangleUnqualifiedName(ND->getTemplatedDecl(), nullptr);
@@ -3658,6 +3658,7 @@ recurse:
   case Expr::ConvertVectorExprClass:
   case Expr::StmtExprClass:
   case Expr::TypeTraitExprClass:
+  case Expr::ConceptSpecializationExprClass:
   case Expr::ArrayTypeTraitExprClass:
   case Expr::ExpressionTraitExprClass:
   case Expr::VAArgExprClass:
@@ -4167,18 +4168,6 @@ recurse:
 mangleExpression(cast(E)->getSubExpr(), Arity);
 break;
 
-
-  case Expr::ConceptSpecializationExprClass: {
-//   ::= L  E # external name
-Out << "L_Z";
-auto *CSE = cast(E);
-mangleTemplateName(CSE->getNamedConcept(),
-   CSE->getTemplateArguments().data(),
-   CSE->getTemplateArguments().size());
-Out << 'E';
-break;
-  }
-
   case Expr::DeclRefExprClass:
 mangleDeclRefExpr(cast(E)->getDecl());
 break;

Modified: cfe/trunk/lib/Sema/SemaTemplate.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaTemplate.cpp?rev=374985&r1=374984&r2=374985&view=diff
==
--- cfe/trunk/lib/Sema/SemaTemplate.cpp (original)
+++ cfe/trunk/lib/Sema/SemaTemplate.cpp Wed Oct 16 03:23:53 2019
@@ -4302,7 +4302,7 @@ ExprResult Sema::BuildTemplateIdExpr(con
   TemplateKWLoc, TemplateArgs);
   }
 
-  if (R.getAsSingle()) {
+  if (R.getAsSingle() && !AnyDependentArguments()) {
 return CheckConceptTemplateId(SS, TemplateKWLoc,
   R.getLookupNameInfo().getBeginLoc(),
   R.getFoundDecl(),

Removed: cfe/trunk/test/CodeGenCXX/mangle-concept.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/mangle-concept.cpp?rev=374984&view=auto
==
--- cfe/trunk/test/CodeGenCXX/mangle-concept.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/mangle-concept.cpp (removed)
@@ -1,16 +0,0 @@
-// RUN: %clang_cc1 -verify -Wno-return-type -Wno-main -std=c++2a -fconcepts-ts 
-emit-llvm -triple %itanium_abi_triple -o - %s | FileCheck %s
-// expected-no-diagnostics
-
-namespace test1 {
-template  struct S {};
-template  concept C = true;
-template  S> f0() { return S>{}; }
-template S> f0<>();
-// CHECK: void @_ZN5test12f0IiEENS_1SIXL_ZNS_1CIT_EEv(
-}
-
-template  struct S {};
-template  concept C = true;
-template  S> f0() { return S>{}; }
-template S> f0<>();
-// CHECK: void @_Z2f0IiE1SIXL_Z1CIT_v(


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

[PATCH] D41569: [Concepts] Constraint enforcement and diagnostics

2019-10-16 Thread Nico Weber via Phabricator via cfe-commits

thakis added a comment.

reverted in r374985, it wasn't obvious to me how to unbreak the test. Sorry!


Repository:
  rC Clang

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

https://reviews.llvm.org/D41569



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

r374988 - CGExprConstant - silence static analyzer getAs<> null dereference warning. NFCI.

2019-10-16 Thread Simon Pilgrim via cfe-commits

Author: rksimon
Date: Wed Oct 16 03:38:40 2019
New Revision: 374988

URL: http://llvm.org/viewvc/llvm-project?rev=374988&view=rev
Log:
CGExprConstant - silence static analyzer getAs<> null dereference warning. NFCI.

The static analyzer is warning about a potential null dereference, but in these 
cases we should be able to use castAs<> directly and if not assert will fire 
for us.

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

Modified: cfe/trunk/lib/CodeGen/CGExprConstant.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGExprConstant.cpp?rev=374988&r1=374987&r2=374988&view=diff
==
--- cfe/trunk/lib/CodeGen/CGExprConstant.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGExprConstant.cpp Wed Oct 16 03:38:40 2019
@@ -1269,8 +1269,8 @@ public:
   return nullptr;
 
 // FIXME: We should not have to call getBaseElementType here.
-const RecordType *RT =
-  CGM.getContext().getBaseElementType(Ty)->getAs();
+const auto *RT =
+CGM.getContext().getBaseElementType(Ty)->castAs();
 const CXXRecordDecl *RD = cast(RT->getDecl());
 
 // If the class doesn't have a trivial destructor, we can't emit it as a


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

r374987 - CGBuiltin - silence static analyzer getAs<> null dereference warnings. NFCI.

2019-10-16 Thread Simon Pilgrim via cfe-commits

Author: rksimon
Date: Wed Oct 16 03:38:32 2019
New Revision: 374987

URL: http://llvm.org/viewvc/llvm-project?rev=374987&view=rev
Log:
CGBuiltin - silence static analyzer getAs<> null dereference warnings. NFCI.

The static analyzer is warning about potential null dereferences, but in these 
cases we should be able to use castAs<> directly and if not assert will fire 
for us.

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

Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBuiltin.cpp?rev=374987&r1=374986&r2=374987&view=diff
==
--- cfe/trunk/lib/CodeGen/CGBuiltin.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp Wed Oct 16 03:38:32 2019
@@ -1396,9 +1396,8 @@ EmitCheckedMixedSignMultiply(CodeGenFunc
 static llvm::Value *dumpRecord(CodeGenFunction &CGF, QualType RType,
Value *&RecordPtr, CharUnits Align,
llvm::FunctionCallee Func, int Lvl) {
-  const auto *RT = RType->getAs();
   ASTContext &Context = CGF.getContext();
-  RecordDecl *RD = RT->getDecl()->getDefinition();
+  RecordDecl *RD = RType->castAs()->getDecl()->getDefinition();
   std::string Pad = std::string(Lvl * 4, ' ');
 
   Value *GString =
@@ -3693,13 +3692,13 @@ RValue CodeGenFunction::EmitBuiltinExpr(
   case Builtin::BIget_pipe_num_packets:
   case Builtin::BIget_pipe_max_packets: {
 const char *BaseName;
-const PipeType *PipeTy = E->getArg(0)->getType()->getAs();
+const auto *PipeTy = E->getArg(0)->getType()->castAs();
 if (BuiltinID == Builtin::BIget_pipe_num_packets)
   BaseName = "__get_pipe_num_packets";
 else
   BaseName = "__get_pipe_max_packets";
-auto Name = std::string(BaseName) +
-std::string(PipeTy->isReadOnly() ? "_ro" : "_wo");
+std::string Name = std::string(BaseName) +
+   std::string(PipeTy->isReadOnly() ? "_ro" : "_wo");
 
 // Building the generic function prototype.
 Value *Arg0 = EmitScalarExpr(E->getArg(0));


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

r374989 - CGDebugInfo - silence static analyzer dyn_cast<> null dereference warnings. NFCI.

2019-10-16 Thread Simon Pilgrim via cfe-commits

Author: rksimon
Date: Wed Oct 16 03:38:49 2019
New Revision: 374989

URL: http://llvm.org/viewvc/llvm-project?rev=374989&view=rev
Log:
CGDebugInfo - silence static analyzer dyn_cast<> null dereference warnings. 
NFCI.

The static analyzer is warning about potential null dereferences, but in these 
cases we should be able to use cast<> directly and if not assert will fire for 
us.

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

Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=374989&r1=374988&r2=374989&view=diff
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Wed Oct 16 03:38:49 2019
@@ -1791,6 +1791,7 @@ CGDebugInfo::CollectTemplateParams(const
   CGM.getContext().toCharUnitsFromBits((int64_t)fieldOffset);
   V = CGM.getCXXABI().EmitMemberDataPointer(MPT, chars);
 }
+assert(V && "Failed to find template parameter pointer");
 V = V->stripPointerCasts();
   }
   TemplateParams.push_back(DBuilder.createTemplateValueParameter(
@@ -3327,13 +3328,13 @@ llvm::DISubprogram *CGDebugInfo::getFunc
   unsigned Line = getLineNumber(Loc);
   collectFunctionDeclProps(GD, Unit, Name, LinkageName, DContext, TParamsArray,
Flags);
-  auto *FD = dyn_cast(GD.getDecl());
+  auto *FD = cast(GD.getDecl());
 
   // Build function type.
   SmallVector ArgTypes;
-  if (FD)
-for (const ParmVarDecl *Parm : FD->parameters())
-  ArgTypes.push_back(Parm->getType());
+  for (const ParmVarDecl *Parm : FD->parameters())
+ArgTypes.push_back(Parm->getType());
+
   CallingConv CC = FD->getType()->castAs()->getCallConv();
   QualType FnType = CGM.getContext().getFunctionType(
   FD->getReturnType(), ArgTypes, FunctionProtoType::ExtProtoInfo(CC));


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

r374991 - RewriteModernObjC - silence static analyzer getAs<> null dereference warnings. NFCI.

2019-10-16 Thread Simon Pilgrim via cfe-commits

Author: rksimon
Date: Wed Oct 16 03:50:06 2019
New Revision: 374991

URL: http://llvm.org/viewvc/llvm-project?rev=374991&view=rev
Log:
RewriteModernObjC - silence static analyzer getAs<> null dereference warnings. 
NFCI.

The static analyzer is warning about potential null dereferences, but in these 
cases we should be able to use castAs<> directly and if not assert will fire 
for us.

Modified:
cfe/trunk/lib/Frontend/Rewrite/RewriteModernObjC.cpp

Modified: cfe/trunk/lib/Frontend/Rewrite/RewriteModernObjC.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/Rewrite/RewriteModernObjC.cpp?rev=374991&r1=374990&r2=374991&view=diff
==
--- cfe/trunk/lib/Frontend/Rewrite/RewriteModernObjC.cpp (original)
+++ cfe/trunk/lib/Frontend/Rewrite/RewriteModernObjC.cpp Wed Oct 16 03:50:06 
2019
@@ -505,7 +505,7 @@ namespace {
 /// otherwise.
 bool convertBlockPointerToFunctionPointer(QualType &T) {
   if (isTopLevelBlockPointerType(T)) {
-const BlockPointerType *BPT = T->getAs();
+const auto *BPT = T->castAs();
 T = Context->getPointerType(BPT->getPointeeType());
 return true;
   }
@@ -856,8 +856,7 @@ RewriteModernObjC::getIvarAccessString(O
 RD = RD->getDefinition();
 if (RD && !RD->getDeclName().getAsIdentifierInfo()) {
   // decltype(((Foo_IMPL*)0)->bar) *
-  ObjCContainerDecl *CDecl =
-  dyn_cast(D->getDeclContext());
+  auto *CDecl = cast(D->getDeclContext());
   // ivar in class extensions requires special treatment.
   if (ObjCCategoryDecl *CatDecl = dyn_cast(CDecl))
 CDecl = CatDecl->getClassInterface();
@@ -1332,6 +1331,7 @@ void RewriteModernObjC::RewriteObjCMetho
 void RewriteModernObjC::RewriteImplementationDecl(Decl *OID) {
   ObjCImplementationDecl *IMD = dyn_cast(OID);
   ObjCCategoryImplDecl *CID = dyn_cast(OID);
+  assert((IMD || CID) && "Unknown implementation type");
 
   if (IMD) {
 if (IMD->getIvarRBraceLoc().isValid()) {
@@ -2103,8 +2103,7 @@ RewriteModernObjC::SynthesizeCallToFunct
 ImplicitCastExpr::Create(*Context, pToFunc, CK_FunctionToPointerDecay,
  DRE, nullptr, VK_RValue);
 
-  const FunctionType *FT = msgSendType->getAs();
-
+  const auto *FT = msgSendType->castAs();
   CallExpr *Exp = CallExpr::Create(
   *Context, ICE, Args, FT->getCallResultType(*Context), VK_RValue, EndLoc);
   return Exp;


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

[PATCH] D68362: [libunwind][RISCV] Add 64-bit RISC-V support

2019-10-16 Thread Sam Elliott via Phabricator via cfe-commits

lenary added inline comments.

Comment at: libunwind/src/Registers.hpp:3756
+inline double Registers_riscv::getFloatRegister(int regNum) const {
+#ifdef __riscv_float_abi_double
+  assert(validFloatRegister(regNum));

mhorne wrote:
> lenary wrote:
> > Is this an ABI or an architecture issue? I'm not sure what other libunwind 
> > "backends" do for similar cases.
> > 
> > The difference is, if I compile libunwind with `-march=rv64g -mabi=lp64`, 
> > `__riscv_float_abi_double` is not defined (because you're using a 
> > soft-float ABI), but `__riscv_flen == 64` (because the machine does have 
> > hardware floating-point registers).
> > 
> > I'm not sure what the intended behaviour of libunwind is in this case.
> > 
> > `__riscv_float_abi_double` implies `__riscv_flen >= 64`.
> An ABI issue, in my opinion. The unwind frame will always contain space for 
> the float registers, but accessing them should be disallowed for soft-float 
> configurations as the intent of soft-float is that the FPRs will not be used 
> at all. I'd say there is precedent for this in the MIPS implementation, since 
> it checks for `defined(__mips_hard_float) && __mips_fpr == 64`.
I had a discussion with @asb about this. The ISA vs ABI issue in RISC-V is 
complex. The TL;DR is we both think you need to be using `__riscv_flen == 64` 
here.

The reason for this is that if you compile with `-march=rv64imfd` but 
`-mabi=lp64`, the architecture still has floating point registers, it just does 
not use the floating-point calling convention. This means there are still 
`D`-extension instructions in the stream of instructions, just that "No 
floating-point registers, if present, are preserved across calls." (see [[ 
https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md#integer-calling-convention
 | psABI Integer Calling Convention ]]) This effectively means that with this 
combination, `f0-f31` are treated exactly the same as `t0-t6`, and so should be 
able to be restored when unwinding. It is not necessarily the case that with a 
soft float ABI, `f0-f31` are not used at all. This is similar to ARM's `soft` 
vs `softfp` calling conventions.

The expectation is that if you are compiling your programs with a specific 
`-march`, then you should be compiling your runtime libraries with the same 
`-march`. Eventually there should be enough details in the ELF file to allow 
you to ensure both `-march` and `-mabi` match when linking programs, but 
support for this is not widespread.

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

https://reviews.llvm.org/D68362

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

[PATCH] D69025: [Driver,ARM] Make -mfloat-abi=soft turn off MVE.

2019-10-16 Thread Dave Green via Phabricator via cfe-commits

dmgreen added a comment.

I do not know this code super well. What happens to the preprocessor in such 
cases? Does it disable the relevant macros automatically because we've turned 
off the mve and mve.fp features?

Could you add a test?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69025



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

[PATCH] D56612: [clangd] A code action to remove 'using namespace'

2019-10-16 Thread Ilya Biryukov via Phabricator via cfe-commits

ilya-biryukov abandoned this revision.
ilya-biryukov added a comment.

This was finalized and landed as D68562 


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

https://reviews.llvm.org/D56612



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

[PATCH] D68818: [hip][cuda] Fix the extended lambda name mangling issue.

2019-10-16 Thread Michael Liao via Phabricator via cfe-commits

hliao added a comment.

PING for review


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68818



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

[PATCH] D67827: [clangd] Simplify name qualification in DefineInline

2019-10-16 Thread Ilya Biryukov via Phabricator via cfe-commits

ilya-biryukov abandoned this revision.
ilya-biryukov added a comment.

D66647  was updated to use 
`findExplicitReferences`, abandoning this revision.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67827



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

[PATCH] D69025: [Driver,ARM] Make -mfloat-abi=soft turn off MVE.

2019-10-16 Thread Simon Tatham via Phabricator via cfe-commits

simon_tatham added a comment.

Yes: this change is in the driver, and causes those features to be disabled on 
the command line to cc1, which responds by not defining `__ARM_FEATURE_MVE`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69025



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

[PATCH] D69025: [Driver,ARM] Make -mfloat-abi=soft turn off MVE.

2019-10-16 Thread Simon Tatham via Phabricator via cfe-commits

simon_tatham added a comment.

So, as for adding a test ... the test I //have// added here ensures that this 
combination of driver options leads to `-target-feature -mve` and `-mve.fp` on 
the cc1 command line, and the existing test 
`Preprocessor/arm-target-features.c` checks that that in turn leads to 
`__ARM_FEATURE_MVE` not being defined.

A single end-to-end test that proves that //these// driver args lead to 
//that// preprocessor definition (or not) doesn't really have a place to live.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69025



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

[PATCH] D68362: [libunwind][RISCV] Add 64-bit RISC-V support

2019-10-16 Thread Luís Marques via Phabricator via cfe-commits

luismarques added inline comments.



Comment at: libunwind/src/Registers.hpp:3756
+inline double Registers_riscv::getFloatRegister(int regNum) const {
+#ifdef __riscv_float_abi_double
+  assert(validFloatRegister(regNum));

lenary wrote:
> mhorne wrote:
> > lenary wrote:
> > > Is this an ABI or an architecture issue? I'm not sure what other 
> > > libunwind "backends" do for similar cases.
> > > 
> > > The difference is, if I compile libunwind with `-march=rv64g -mabi=lp64`, 
> > > `__riscv_float_abi_double` is not defined (because you're using a 
> > > soft-float ABI), but `__riscv_flen == 64` (because the machine does have 
> > > hardware floating-point registers).
> > > 
> > > I'm not sure what the intended behaviour of libunwind is in this case.
> > > 
> > > `__riscv_float_abi_double` implies `__riscv_flen >= 64`.
> > An ABI issue, in my opinion. The unwind frame will always contain space for 
> > the float registers, but accessing them should be disallowed for soft-float 
> > configurations as the intent of soft-float is that the FPRs will not be 
> > used at all. I'd say there is precedent for this in the MIPS 
> > implementation, since it checks for `defined(__mips_hard_float) && 
> > __mips_fpr == 64`.
> I had a discussion with @asb about this. The ISA vs ABI issue in RISC-V is 
> complex. The TL;DR is we both think you need to be using `__riscv_flen == 64` 
> here.
> 
> The reason for this is that if you compile with `-march=rv64imfd` but 
> `-mabi=lp64`, the architecture still has floating point registers, it just 
> does not use the floating-point calling convention. This means there are 
> still `D`-extension instructions in the stream of instructions, just that "No 
> floating-point registers, if present, are preserved across calls." (see [[ 
> https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md#integer-calling-convention
>  | psABI Integer Calling Convention ]]) This effectively means that with this 
> combination, `f0-f31` are treated exactly the same as `t0-t6`, and so should 
> be able to be restored when unwinding. It is not necessarily the case that 
> with a soft float ABI, `f0-f31` are not used at all. This is similar to ARM's 
> `soft` vs `softfp` calling conventions.
> 
> The expectation is that if you are compiling your programs with a specific 
> `-march`, then you should be compiling your runtime libraries with the same 
> `-march`. Eventually there should be enough details in the ELF file to allow 
> you to ensure both `-march` and `-mabi` match when linking programs, but 
> support for this is not widespread.
A soft-float *ABI* doesn't mean that FPRs aren't used at all, it means that 
floating-point arguments aren't passed in the floating-point registers. From a 
quick Google search I got the impression that `__mips_hard_float` was used for 
a mips softfloat target (i.e. without hardware floating-point support, not for 
a soft-float ABI), so that's probably not a comparable example.


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

https://reviews.llvm.org/D68362



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

[PATCH] D69025: [Driver,ARM] Make -mfloat-abi=soft turn off MVE.

2019-10-16 Thread Dave Green via Phabricator via cfe-commits

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

Yeah, OK. That makes sense.

LGTM!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69025



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

r375001 - [Driver,ARM] Make -mfloat-abi=soft turn off MVE.

2019-10-16 Thread Simon Tatham via cfe-commits

Author: statham
Date: Wed Oct 16 06:23:39 2019
New Revision: 375001

URL: http://llvm.org/viewvc/llvm-project?rev=375001&view=rev
Log:
[Driver,ARM] Make -mfloat-abi=soft turn off MVE.

Since `-mfloat-abi=soft` is taken to mean turning off all uses of the
FP registers, it should turn off the MVE vector instructions as well
as NEON and scalar FP. But it wasn't doing so.

So the options `-march=armv8.1-m.main+mve.fp+fp.dp -mfloat-abi=soft`
would cause the underlying LLVM to //not// support MVE (because it
knows the real target feature relationships and turned off MVE when
the `fpregs` feature was removed), but the clang layer still thought
it //was// supported, and would misleadingly define the feature macro
`__ARM_FEATURE_MVE`.

The ARM driver code already has a long list of feature names to turn
off when `-mfloat-abi=soft` is selected. The fix is to add the missing
entries `mve` and `mve.fp` to that list.

Reviewers: dmgreen

Subscribers: kristof.beyls, cfe-commits

Tags: #clang

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

Modified:
cfe/trunk/lib/Driver/ToolChains/Arch/ARM.cpp
cfe/trunk/test/Driver/arm-mfpu.c

Modified: cfe/trunk/lib/Driver/ToolChains/Arch/ARM.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Arch/ARM.cpp?rev=375001&r1=375000&r2=375001&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Arch/ARM.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Arch/ARM.cpp Wed Oct 16 06:23:39 2019
@@ -465,6 +465,7 @@ fp16_fml_fallthrough:
 "vfp4", "vfp4sp", "vfp4d16", "vfp4d16sp",
 "fp-armv8", "fp-armv8sp", "fp-armv8d16", "fp-armv8d16sp",
 "fullfp16", "neon", "crypto", "dotprod", "fp16fml",
+"mve", "mve.fp",
 "fp64", "d32", "fpregs"})
   Features.push_back(Args.MakeArgString("-" + Feature));
   }

Modified: cfe/trunk/test/Driver/arm-mfpu.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/arm-mfpu.c?rev=375001&r1=375000&r2=375001&view=diff
==
--- cfe/trunk/test/Driver/arm-mfpu.c (original)
+++ cfe/trunk/test/Driver/arm-mfpu.c Wed Oct 16 06:23:39 2019
@@ -397,3 +397,9 @@
 // CHECK-ARM7-ANDROID-FP-D16-NOT: "-target-feature" "+fp-armv8"
 // CHECK-ARM7-ANDROID-FP-D16-NOT: "-target-feature" "+neon"
 // CHECK-ARM7-ANDROID-FP-D16-NOT: "-target-feature" "+crypto"
+
+// RUN: %clang -target arm-none-none-eabi %s 
-march=armv8.1-m.main+mve.fp+fp.dp -mfloat-abi=soft -### -c 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-SOFTFLOATABI-INHIBITS-MVE %s
+// CHECK-SOFTFLOATABI-INHIBITS-MVE-NOT: "-target-feature" "+mve"
+// CHECK-SOFTFLOATABI-INHIBITS-MVE-DAG: "-target-feature" "-mve"
+// CHECK-SOFTFLOATABI-INHIBITS-MVE-DAG: "-target-feature" "-mve.fp"


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

[PATCH] D69025: [Driver,ARM] Make -mfloat-abi=soft turn off MVE.

2019-10-16 Thread Simon Tatham via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rGfdccf28697e5: [Driver,ARM] Make -mfloat-abi=soft turn off 
MVE. (authored by simon_tatham).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69025

Files:
  clang/lib/Driver/ToolChains/Arch/ARM.cpp
  clang/test/Driver/arm-mfpu.c


Index: clang/test/Driver/arm-mfpu.c
===
--- clang/test/Driver/arm-mfpu.c
+++ clang/test/Driver/arm-mfpu.c
@@ -397,3 +397,9 @@
 // CHECK-ARM7-ANDROID-FP-D16-NOT: "-target-feature" "+fp-armv8"
 // CHECK-ARM7-ANDROID-FP-D16-NOT: "-target-feature" "+neon"
 // CHECK-ARM7-ANDROID-FP-D16-NOT: "-target-feature" "+crypto"
+
+// RUN: %clang -target arm-none-none-eabi %s 
-march=armv8.1-m.main+mve.fp+fp.dp -mfloat-abi=soft -### -c 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-SOFTFLOATABI-INHIBITS-MVE %s
+// CHECK-SOFTFLOATABI-INHIBITS-MVE-NOT: "-target-feature" "+mve"
+// CHECK-SOFTFLOATABI-INHIBITS-MVE-DAG: "-target-feature" "-mve"
+// CHECK-SOFTFLOATABI-INHIBITS-MVE-DAG: "-target-feature" "-mve.fp"
Index: clang/lib/Driver/ToolChains/Arch/ARM.cpp
===
--- clang/lib/Driver/ToolChains/Arch/ARM.cpp
+++ clang/lib/Driver/ToolChains/Arch/ARM.cpp
@@ -465,6 +465,7 @@
 "vfp4", "vfp4sp", "vfp4d16", "vfp4d16sp",
 "fp-armv8", "fp-armv8sp", "fp-armv8d16", "fp-armv8d16sp",
 "fullfp16", "neon", "crypto", "dotprod", "fp16fml",
+"mve", "mve.fp",
 "fp64", "d32", "fpregs"})
   Features.push_back(Args.MakeArgString("-" + Feature));
   }


Index: clang/test/Driver/arm-mfpu.c
===
--- clang/test/Driver/arm-mfpu.c
+++ clang/test/Driver/arm-mfpu.c
@@ -397,3 +397,9 @@
 // CHECK-ARM7-ANDROID-FP-D16-NOT: "-target-feature" "+fp-armv8"
 // CHECK-ARM7-ANDROID-FP-D16-NOT: "-target-feature" "+neon"
 // CHECK-ARM7-ANDROID-FP-D16-NOT: "-target-feature" "+crypto"
+
+// RUN: %clang -target arm-none-none-eabi %s -march=armv8.1-m.main+mve.fp+fp.dp -mfloat-abi=soft -### -c 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-SOFTFLOATABI-INHIBITS-MVE %s
+// CHECK-SOFTFLOATABI-INHIBITS-MVE-NOT: "-target-feature" "+mve"
+// CHECK-SOFTFLOATABI-INHIBITS-MVE-DAG: "-target-feature" "-mve"
+// CHECK-SOFTFLOATABI-INHIBITS-MVE-DAG: "-target-feature" "-mve.fp"
Index: clang/lib/Driver/ToolChains/Arch/ARM.cpp
===
--- clang/lib/Driver/ToolChains/Arch/ARM.cpp
+++ clang/lib/Driver/ToolChains/Arch/ARM.cpp
@@ -465,6 +465,7 @@
 "vfp4", "vfp4sp", "vfp4d16", "vfp4d16sp",
 "fp-armv8", "fp-armv8sp", "fp-armv8d16", "fp-armv8d16sp",
 "fullfp16", "neon", "crypto", "dotprod", "fp16fml",
+"mve", "mve.fp",
 "fp64", "d32", "fpregs"})
   Features.push_back(Args.MakeArgString("-" + Feature));
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D69033: [clangd] Improve symbol qualification in DefineInline code action

2019-10-16 Thread Kadir Cetinkaya via Phabricator via cfe-commits

kadircet created this revision.
kadircet added a reviewer: ilya-biryukov.
Herald added subscribers: cfe-commits, usaxena95, arphaman, jkorous, MaskRay.
Herald added a project: clang.

Currently define inline action fully qualifies any names in the
function body, which is not optimal and definitely natural.

This patch tries to improve the situation by dropping any name specifiers shared
by function and names spelled in the body. For example if you are moving
definition of a function in namespace clang::clangd, and body has any decl's
coming from clang or clang::clangd namespace, those qualifications won't be
added since they are redundant.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D69033

Files:
  clang-tools-extra/clangd/refactor/tweaks/DefineInline.cpp
  clang-tools-extra/clangd/unittests/TweakTests.cpp

Index: clang-tools-extra/clangd/unittests/TweakTests.cpp
===
--- clang-tools-extra/clangd/unittests/TweakTests.cpp
+++ clang-tools-extra/clangd/unittests/TweakTests.cpp
@@ -1402,6 +1402,95 @@
 template <> inline void foo(){})cpp")));
 }
 
+TEST_F(DefineInlineTest, DropCommonNamespecifiers) {
+  EXPECT_EQ(apply(R"cpp(
+  namespace a { namespace b { void aux(); } }
+  namespace ns1 {
+  void foo();
+  namespace qq { void test(); }
+  namespace ns2 {
+  void bar();
+  namespace ns3 { void baz(); }
+  }
+  }
+
+  using namespace a;
+  using namespace a::b;
+  using namespace ns1::qq;
+  void ns1::ns2::ns3::b^az() {
+foo();
+bar();
+baz();
+ns1::ns2::ns3::baz();
+aux();
+test();
+  })cpp"),
+R"cpp(
+  namespace a { namespace b { void aux(); } }
+  namespace ns1 {
+  void foo();
+  namespace qq { void test(); }
+  namespace ns2 {
+  void bar();
+  namespace ns3 { void baz(){
+foo();
+bar();
+baz();
+ns1::ns2::ns3::baz();
+a::b::aux();
+qq::test();
+  } }
+  }
+  }
+
+  using namespace a;
+  using namespace a::b;
+  using namespace ns1::qq;
+  )cpp");
+
+  EXPECT_EQ(apply(R"cpp(
+  namespace ns1 {
+  namespace qq { struct Foo { struct Bar {}; }; using B = Foo::Bar; }
+  namespace ns2 { void baz(); }
+  }
+
+  using namespace ns1::qq;
+  void ns1::ns2::b^az() { Foo f; B b; })cpp"),
+R"cpp(
+  namespace ns1 {
+  namespace qq { struct Foo { struct Bar {}; }; using B = Foo::Bar; }
+  namespace ns2 { void baz(){ qq::Foo f; qq::B b; } }
+  }
+
+  using namespace ns1::qq;
+  )cpp");
+
+  EXPECT_EQ(apply(R"cpp(
+  namespace ns1 {
+  namespace qq {
+template struct Foo { template  struct Bar {}; };
+template
+using B = typename Foo::template Bar;
+  }
+  namespace ns2 { void baz(); }
+  }
+
+  using namespace ns1::qq;
+  void ns1::ns2::b^az() { B b; })cpp"),
+R"cpp(
+  namespace ns1 {
+  namespace qq {
+template struct Foo { template  struct Bar {}; };
+template
+using B = typename Foo::template Bar;
+  }
+  namespace ns2 { void baz(){ qq::B b; } }
+  }
+
+  using namespace ns1::qq;
+  )cpp");
+}
+
 } // namespace
 } // namespace clangd
 } // namespace clang
Index: clang-tools-extra/clangd/refactor/tweaks/DefineInline.cpp
===
--- clang-tools-extra/clangd/refactor/tweaks/DefineInline.cpp
+++ clang-tools-extra/clangd/refactor/tweaks/DefineInline.cpp
@@ -143,8 +143,48 @@
   return true;
 }
 
-// Rewrites body of FD to fully-qualify all of the decls inside.
-llvm::Expected qualifyAllDecls(const FunctionDecl *FD) {
+// Gets the nested name specifiers necessary for spelling a name from
+// SourceContext in DestContext. Drops any shared nested name specifiers between
+// CurContext and SourceContext, doesn't take using declarations and directives
+// into account.
+NestedNameSpecifier *getQualification(ASTContext &Context,
+  const DeclContext *DestContext,
+  const DeclContext *SourceContext) {
+  // Goes over all parents of SourceContext until we find a comman ancestor
+  // between Dest and Source. Any qualifier including and above common ancestor
+  // is redundant, therefore we stop at lowest common ancestor.
+  std::vector SourceParents;
+  for (const DeclContext *Context = SourceContext; Context;
+   Context = Context->getLookupParent()) {
+// Stop once we reach a common ancestor.
+if (Context->Encloses(DestContext))
+  break;
+// Inline namespace names are not spelled while qualifying a name, so skip
+// those.
+if (Context->isInlineNamespace())
+  continue;
+
+auto *NSD = llvm::dyn_cast(Context);
+assert(NSD && "Non-namespace decl context found.");
+// Again, ananoymous namespaces are not spelled while qualifying a name.
+if (NSD->isAnonymousNamespace())
+  continue;
+
+SourceParents.push_back(NSD);
+  }
+
+  // Go over name-specifiers in reverse order to create necessary qualification,
+  // since we stored i

[PATCH] D68362: [libunwind][RISCV] Add 64-bit RISC-V support

2019-10-16 Thread Luís Marques via Phabricator via cfe-commits

luismarques added inline comments.



Comment at: libunwind/src/Registers.hpp:3545
+  void  setSP(uint64_t value) { _registers[2] = value; }
+  uint64_t  getIP() const { return _registers[1]; }
+  void  setIP(uint64_t value) { _registers[1] = value; }

`x1` is the return address. Is this the the `IP` to which we unwind to? How do 
we get the original `ra` value at that unwind point?
I vaguely recall seeing this IP/x1 pattern in another unwind library, so it's 
probably correct, but it would be good to confirm and document such details.



Comment at: libunwind/src/Registers.hpp:3756
+inline double Registers_riscv::getFloatRegister(int regNum) const {
+#ifdef __riscv_float_abi_double
+  assert(validFloatRegister(regNum));

luismarques wrote:
> lenary wrote:
> > mhorne wrote:
> > > lenary wrote:
> > > > Is this an ABI or an architecture issue? I'm not sure what other 
> > > > libunwind "backends" do for similar cases.
> > > > 
> > > > The difference is, if I compile libunwind with `-march=rv64g 
> > > > -mabi=lp64`, `__riscv_float_abi_double` is not defined (because you're 
> > > > using a soft-float ABI), but `__riscv_flen == 64` (because the machine 
> > > > does have hardware floating-point registers).
> > > > 
> > > > I'm not sure what the intended behaviour of libunwind is in this case.
> > > > 
> > > > `__riscv_float_abi_double` implies `__riscv_flen >= 64`.
> > > An ABI issue, in my opinion. The unwind frame will always contain space 
> > > for the float registers, but accessing them should be disallowed for 
> > > soft-float configurations as the intent of soft-float is that the FPRs 
> > > will not be used at all. I'd say there is precedent for this in the MIPS 
> > > implementation, since it checks for `defined(__mips_hard_float) && 
> > > __mips_fpr == 64`.
> > I had a discussion with @asb about this. The ISA vs ABI issue in RISC-V is 
> > complex. The TL;DR is we both think you need to be using `__riscv_flen == 
> > 64` here.
> > 
> > The reason for this is that if you compile with `-march=rv64imfd` but 
> > `-mabi=lp64`, the architecture still has floating point registers, it just 
> > does not use the floating-point calling convention. This means there are 
> > still `D`-extension instructions in the stream of instructions, just that 
> > "No floating-point registers, if present, are preserved across calls." (see 
> > [[ 
> > https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md#integer-calling-convention
> >  | psABI Integer Calling Convention ]]) This effectively means that with 
> > this combination, `f0-f31` are treated exactly the same as `t0-t6`, and so 
> > should be able to be restored when unwinding. It is not necessarily the 
> > case that with a soft float ABI, `f0-f31` are not used at all. This is 
> > similar to ARM's `soft` vs `softfp` calling conventions.
> > 
> > The expectation is that if you are compiling your programs with a specific 
> > `-march`, then you should be compiling your runtime libraries with the same 
> > `-march`. Eventually there should be enough details in the ELF file to 
> > allow you to ensure both `-march` and `-mabi` match when linking programs, 
> > but support for this is not widespread.
> A soft-float *ABI* doesn't mean that FPRs aren't used at all, it means that 
> floating-point arguments aren't passed in the floating-point registers. From 
> a quick Google search I got the impression that `__mips_hard_float` was used 
> for a mips softfloat target (i.e. without hardware floating-point support, 
> not for a soft-float ABI), so that's probably not a comparable example.
I just saw @lenary's reply. I agree with his more detailed analysis.


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

https://reviews.llvm.org/D68362



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

[PATCH] D68937: [clangd] Add parameter renaming to define-inline code action

2019-10-16 Thread Kadir Cetinkaya via Phabricator via cfe-commits

kadircet added a comment.

In D68937#1710634 , @ilya-biryukov 
wrote:

> An alternative approach I'm thinking of:
>  After D68977  lands, we could try using 
> `findExplicitReferences` to produce all of these edits:
>
> 1. we collect locations of all references and declaration of relevant 
> parameters and template parameters.
> 2. find the ones where the name differs and produce the changes.
>
>   That would handle not only references in the default argument, but also all 
> references in the body and should be less code overall. IMO it's worth 
> exploring this approach right away, e.g. you could layer your patch on top of 
> the current version of D68977 

I totally agree that the solution you proposed would also work, but don't think 
it would be any less code. Since one needs to correlate
parameters between two different declarations, and `findExplicitReferences` 
doesn't really provide a nice way to achieve that. One
would have to rely on `SourceLocation` ordering or in the order callback was 
issued(which implicitly relies on AST traversal order).

It would be nice to unify the rewrite parameter name/type/defaultarg logics, 
but not sure if it is worth.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68937

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

[PATCH] D68937: [clangd] Add parameter renaming to define-inline code action

2019-10-16 Thread Kadir Cetinkaya via Phabricator via cfe-commits

kadircet updated this revision to Diff 225209.
kadircet marked an inline comment as done.
kadircet added a comment.

- Accept StringRef for Source in rewriteParameterName instead of a NamedDecl


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68937

Files:
  clang-tools-extra/clangd/refactor/tweaks/DefineInline.cpp
  clang-tools-extra/clangd/unittests/TweakTests.cpp

Index: clang-tools-extra/clangd/unittests/TweakTests.cpp
===
--- clang-tools-extra/clangd/unittests/TweakTests.cpp
+++ clang-tools-extra/clangd/unittests/TweakTests.cpp
@@ -1290,6 +1290,44 @@
 )cpp");
 }
 
+TEST_F(DefineInlineTest, TransformParamNames) {
+  EXPECT_EQ(apply(R"cpp(
+void foo(int, bool b);
+
+void ^foo(int f, bool x) {})cpp"), R"cpp(
+void foo(int f, bool x){}
+
+)cpp");
+}
+
+TEST_F(DefineInlineTest, TransformTemplParamNames) {
+  EXPECT_EQ(apply(R"cpp(
+struct Foo {
+  struct Bar {
+template  class, template class Y,
+  int, int Z>
+void foo(X, Y, int W = 5 * Z + 2);
+  };
+};
+
+template  class V, template class W,
+  int X, int Y>
+void Foo::Bar::f^oo(U, W, int Q) {})cpp"),
+R"cpp(
+struct Foo {
+  struct Bar {
+template  class V, template class W,
+  int X, int Y>
+void foo(U, W, int Q = 5 * Y + 2){}
+  };
+};
+
+)cpp");
+}
+
 TEST_F(DefineInlineTest, TransformInlineNamespaces) {
   EXPECT_EQ(apply(R"cpp(
 namespace a { inline namespace b { namespace { struct Foo{}; } } }
Index: clang-tools-extra/clangd/refactor/tweaks/DefineInline.cpp
===
--- clang-tools-extra/clangd/refactor/tweaks/DefineInline.cpp
+++ clang-tools-extra/clangd/refactor/tweaks/DefineInline.cpp
@@ -226,6 +226,176 @@
   return QualifiedFunc->substr(BodyBegin, BodyEnd - BodyBegin + 1);
 }
 
+/// Generates a replacement that renames \p Dest to \p Source.
+llvm::Error rewriteParameterName(tooling::Replacements &Replacements,
+ const NamedDecl *Dest,
+ llvm::StringRef SourceName) {
+  auto &SM = Dest->getASTContext().getSourceManager();
+  llvm::StringRef DestName = Dest->getName();
+  if (DestName == SourceName)
+return llvm::Error::success();
+  if (auto Err = Replacements.add(tooling::Replacement(
+  SM, Dest->getLocation(), DestName.size(),
+  // If \p Dest is unnamed, we need to insert a space before current
+  // name.
+  ((DestName.empty() ? " " : "") + SourceName).str( {
+return Err;
+  }
+  return llvm::Error::success();
+}
+
+/// Returns a mapping from template names in \p Dest to \p Source, so that they
+/// can be updated in other places like parameter types and default arguments.
+llvm::Expected>
+renameTemplateParameters(tooling::Replacements &Replacements,
+ const FunctionDecl *Dest, const FunctionDecl *Source) {
+  llvm::DenseMap TemplParamNameDestToSource;
+
+  auto *DestTempl = Dest->getDescribedFunctionTemplate();
+  auto *SourceTempl = Source->getDescribedFunctionTemplate();
+  assert(bool(DestTempl) == bool(SourceTempl));
+  if (DestTempl) {
+const auto *DestTPL = DestTempl->getTemplateParameters();
+const auto *SourceTPL = SourceTempl->getTemplateParameters();
+assert(DestTPL->size() == SourceTPL->size());
+
+for (size_t I = 0, EP = DestTPL->size(); I != EP; ++I) {
+  if (auto Err = rewriteParameterName(Replacements, DestTPL->getParam(I),
+  SourceTPL->getParam(I)->getName()))
+return std::move(Err);
+  TemplParamNameDestToSource[DestTPL->getParam(I)->getName()] =
+  SourceTPL->getParam(I)->getName();
+}
+  }
+
+  return TemplParamNameDestToSource;
+}
+
+/// Generates replacements for rewriting dependent types in \p DestParam to the
+/// matching template name in \p TemplParamNameDestToSource.
+llvm::Error
+rewriteParameterType(tooling::Replacements &Replacements,
+ const ParmVarDecl *DestParam,
+ const llvm::DenseMap
+ &TemplParamNameDestToSource) {
+  auto *DestTSI = DestParam->getTypeSourceInfo();
+  if (!DestTSI)
+return llvm::Error::success();
+  const SourceManager &SM = DestParam->getASTContext().getSourceManager();
+
+  // Update paramater types if they are template template or type template.
+  auto DestTL = DestTSI->getTypeLoc();
+  if (auto DestTPTL = DestTL.getAs()) {
+if (auto Err = Replacements.add(tooling::Replacement(
+SM, CharSourceRange(DestTPTL.getSourceRange(), /*ITR=*/true),
+TemplParamNameDestToSource.lookup(
+DestTPTL.getDecl()->getDeclName().getAsString() {
+  return Err;
+}
+  } else if (auto DestTTSL = DestTL.getAs()) {
+

[PATCH] D69033: [clangd] Improve symbol qualification in DefineInline code action

2019-10-16 Thread Ilya Biryukov via Phabricator via cfe-commits

ilya-biryukov added a comment.

We seem to have trouble only in presence of using declarations and using 
namespace directives.
I wonder how complicated it would be to take them into account instead. That 
would clearly be easier to read, as we'll hit right into the center of the 
problem.

Could you describe why handling using declarations and using namespace 
directives looks too complicated?




Comment at: clang-tools-extra/clangd/refactor/tweaks/DefineInline.cpp:149
+// CurContext and SourceContext, doesn't take using declarations and directives
+// into account.
+NestedNameSpecifier *getQualification(ASTContext &Context,

Could you add an example to the description?



Comment at: clang-tools-extra/clangd/refactor/tweaks/DefineInline.cpp:152
+  const DeclContext *DestContext,
+  const DeclContext *SourceContext) {
+  // Goes over all parents of SourceContext until we find a comman ancestor

Maybe accept a NamedDecl we need to qualify instead of `SourceContext`?
This would help with avoiding confusion with two parameters of the same type 
and I believe we'll need it if we ever want to support using declarations in 
the same function.





Comment at: clang-tools-extra/clangd/refactor/tweaks/DefineInline.cpp:168
+auto *NSD = llvm::dyn_cast(Context);
+assert(NSD && "Non-namespace decl context found.");
+// Again, ananoymous namespaces are not spelled while qualifying a name.

It might be possible to have non-namespace contexts here:
```
namespace ns {
struct X {
  void foo();

  static void target_struct();
};
void target_ns();
}


void ns::X::foo() {
  // we start with non-namespace context.
  target_struct();
  target_ns(); 
}
```

Not sure if we run in those cases, though



Comment at: clang-tools-extra/clangd/unittests/TweakTests.cpp:1417
+
+  using namespace a;
+  using namespace a::b;

We don't support `using namespace` and yet we choose to use them in the tests 
here.
Is there a case where we need to qualify without using namespace directive and 
using declarations?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69033



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

[PATCH] D69036: [libTooling] Fix r374962: add more Transformer forwarding decls.

2019-10-16 Thread Yitzhak Mandelbaum via Phabricator via cfe-commits

ymandel created this revision.
ymandel added a reviewer: alexfh.
Herald added a project: clang.

The move to a new, single namespace in r374962 left out some type definitions
from the old namespace and resulted in one naming conflict (`text`).  This
revision adds aliases for those definitions and removes one of the `text`
functions from the new namespace.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D69036

Files:
  clang/include/clang/Tooling/Transformer/RangeSelector.h
  clang/include/clang/Tooling/Transformer/RewriteRule.h
  clang/include/clang/Tooling/Transformer/Stencil.h
  clang/unittests/Tooling/TransformerTest.cpp


Index: clang/unittests/Tooling/TransformerTest.cpp
===
--- clang/unittests/Tooling/TransformerTest.cpp
+++ clang/unittests/Tooling/TransformerTest.cpp
@@ -21,7 +21,6 @@
 namespace {
 using ::testing::IsEmpty;
 using transformer::RewriteRule;
-using transformer::text;
 
 constexpr char KHeaderContents[] = R"cc(
   struct string {
Index: clang/include/clang/Tooling/Transformer/Stencil.h
===
--- clang/include/clang/Tooling/Transformer/Stencil.h
+++ clang/include/clang/Tooling/Transformer/Stencil.h
@@ -195,9 +195,11 @@
 } // namespace transformer
 
 namespace tooling {
-namespace stencil {
 // DEPRECATED: These are temporary aliases supporting client migration to the
 // `transformer` namespace.
+using Stencil = transformer::Stencil;
+using StencilPart = transformer::StencilPart;
+namespace stencil {
 using transformer::access;
 using transformer::addressOf;
 using transformer::cat;
Index: clang/include/clang/Tooling/Transformer/RewriteRule.h
===
--- clang/include/clang/Tooling/Transformer/RewriteRule.h
+++ clang/include/clang/Tooling/Transformer/RewriteRule.h
@@ -31,11 +31,6 @@
 namespace clang {
 namespace transformer {
 using TextGenerator = MatchConsumer;
-/// Wraps a string as a TextGenerator.
-inline TextGenerator text(std::string M) {
-  return [M](const ast_matchers::MatchFinder::MatchResult &)
- -> Expected { return M; };
-}
 
 // Description of a source-code edit, expressed in terms of an AST node.
 // Includes: an ID for the (bound) node, a selector for source related to the
@@ -221,7 +216,9 @@
 
 /// Removes the source selected by \p S.
 inline ASTEdit remove(RangeSelector S) {
-  return change(std::move(S), text(""));
+  return change(std::move(S),
+[](const ast_matchers::MatchFinder::MatchResult &)
+-> Expected { return ""; });
 }
 
 /// The following three functions are a low-level part of the RewriteRule
@@ -286,6 +283,14 @@
 namespace tooling {
 // DEPRECATED: These are temporary aliases supporting client migration to the
 // `transformer` namespace.
+/// Wraps a string as a TextGenerator.
+using TextGenerator = transformer::TextGenerator;
+
+inline TextGenerator text(std::string M) {
+  return [M](const ast_matchers::MatchFinder::MatchResult &)
+ -> Expected { return M; };
+}
+
 using transformer::addInclude;
 using transformer::applyFirst;
 using transformer::change;
@@ -293,7 +298,6 @@
 using transformer::insertBefore;
 using transformer::makeRule;
 using transformer::remove;
-using transformer::text;
 using transformer::RewriteRule;
 using transformer::IncludeFormat;
 namespace detail {
Index: clang/include/clang/Tooling/Transformer/RangeSelector.h
===
--- clang/include/clang/Tooling/Transformer/RangeSelector.h
+++ clang/include/clang/Tooling/Transformer/RangeSelector.h
@@ -92,6 +92,8 @@
 namespace tooling {
 // DEPRECATED: These are temporary aliases supporting client migration to the
 // `transformer` namespace.
+using RangeSelector = transformer::RangeSelector;
+
 using transformer::after;
 using transformer::before;
 using transformer::callArgs;


Index: clang/unittests/Tooling/TransformerTest.cpp
===
--- clang/unittests/Tooling/TransformerTest.cpp
+++ clang/unittests/Tooling/TransformerTest.cpp
@@ -21,7 +21,6 @@
 namespace {
 using ::testing::IsEmpty;
 using transformer::RewriteRule;
-using transformer::text;
 
 constexpr char KHeaderContents[] = R"cc(
   struct string {
Index: clang/include/clang/Tooling/Transformer/Stencil.h
===
--- clang/include/clang/Tooling/Transformer/Stencil.h
+++ clang/include/clang/Tooling/Transformer/Stencil.h
@@ -195,9 +195,11 @@
 } // namespace transformer
 
 namespace tooling {
-namespace stencil {
 // DEPRECATED: These are temporary aliases supporting client migration to the
 // `transformer` namespace.
+using Stencil = transformer::Stencil;
+using StencilPart = transformer::StencilPart;
+namespace stencil {
 using transformer::access;
 using transformer::addressOf;
 using trans

[libunwind] r374969 - [libunwind][Android] Improve workaround for PIE zero-dlpi_addr bug

2019-10-16 Thread Ryan Prichard via cfe-commits

Author: rprichard
Date: Tue Oct 15 19:38:47 2019
New Revision: 374969

URL: http://llvm.org/viewvc/llvm-project?rev=374969&view=rev
Log:
[libunwind][Android] Improve workaround for PIE zero-dlpi_addr bug

Summary:
The workaround added in https://reviews.llvm.org/rL299575 appears to be
working around a bug in Android JB 4.1.x and 4.2.x (API 16 and 17).

Starting in API 16, Android added support for PIE binaries, but the
dynamic linker failed to initialize dlpi_addr to the address that the
executable was loaded at. The bug was fixed in Android JB 4.3.x (API 18).

Improve the true load bias calculation:

 * The code was assuming that the first segment would be the PT_PHDR
   segment. I think it's better to be explicit and search for PT_PHDR. (It
   will be almost as fast in practice.)

 * It's more correct to use p_vaddr rather than p_offset. If a PIE
   executable is linked with a non-zero image base (e.g. lld's
   -Wl,--image-base=), then we must use p_vaddr here.

The "phdr->p_vaddr < image_base" condition seems unnecessary and maybe
slightly wrong. If the OS were to load a binary at an address smaller than
a vaddr in the binary, we would still want to do this workaround.

The workaround is safe when the linker bug isn't present, because it
should calculate an image_base equal to dlpi_addr. Note that with API 21
and up, this workaround should never activate for dynamically-linked
objects, because non-PIE executables aren't allowed.

Consolidate the fix into a single block of code that calculates the true
image base, and make it clear that the fix no longer applies after API 18.

See https://github.com/android/ndk/issues/505 for details.

Reviewers: mclow.lists, srhines, danalbert, compnerd

Reviewed By: compnerd

Subscribers: srhines, krytarowski, christof, libcxx-commits

Tags: #libc

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

Modified:
libunwind/trunk/src/AddressSpace.hpp

Modified: libunwind/trunk/src/AddressSpace.hpp
URL: 
http://llvm.org/viewvc/llvm-project/libunwind/trunk/src/AddressSpace.hpp?rev=374969&r1=374968&r2=374969&view=diff
==
--- libunwind/trunk/src/AddressSpace.hpp (original)
+++ libunwind/trunk/src/AddressSpace.hpp Tue Oct 15 19:38:47 2019
@@ -497,32 +497,40 @@ inline bool LocalAddressSpace::findUnwin
 #if !defined(Elf_Phdr)
 typedef ElfW(Phdr) Elf_Phdr;
 #endif
+#if !defined(Elf_Addr)
+typedef ElfW(Addr) Elf_Addr;
+#endif
+
+Elf_Addr image_base = pinfo->dlpi_addr;
+
+#if defined(__ANDROID__) && __ANDROID_API__ < 18
+if (image_base == 0) {
+  // Normally, an image base of 0 indicates a non-PIE executable. On
+  // versions of Android prior to API 18, the dynamic linker reported a
+  // dlpi_addr of 0 for PIE executables. Compute the true image base
+  // using the PT_PHDR segment.
+  // See https://github.com/android/ndk/issues/505.
+  for (Elf_Half i = 0; i < pinfo->dlpi_phnum; i++) {
+const Elf_Phdr *phdr = &pinfo->dlpi_phdr[i];
+if (phdr->p_type == PT_PHDR) {
+  image_base = reinterpret_cast(pinfo->dlpi_phdr) -
+  phdr->p_vaddr;
+  break;
+}
+  }
+}
+#endif
 
  #if defined(_LIBUNWIND_SUPPORT_DWARF_UNWIND)
   #if !defined(_LIBUNWIND_SUPPORT_DWARF_INDEX)
#error "_LIBUNWIND_SUPPORT_DWARF_UNWIND requires 
_LIBUNWIND_SUPPORT_DWARF_INDEX on this platform."
   #endif
 size_t object_length;
-#if defined(__ANDROID__)
-#if !defined(Elf_Addr)
-typedef ElfW(Addr) Elf_Addr;
-#endif
-Elf_Addr image_base =
-pinfo->dlpi_phnum
-? reinterpret_cast(pinfo->dlpi_phdr) -
-  reinterpret_cast(pinfo->dlpi_phdr)
-  ->p_offset
-: 0;
-#endif
 
 for (Elf_Half i = 0; i < pinfo->dlpi_phnum; i++) {
   const Elf_Phdr *phdr = &pinfo->dlpi_phdr[i];
   if (phdr->p_type == PT_LOAD) {
-uintptr_t begin = pinfo->dlpi_addr + phdr->p_vaddr;
-#if defined(__ANDROID__)
-if (pinfo->dlpi_addr == 0 && phdr->p_vaddr < image_base)
-  begin = begin + image_base;
-#endif
+uintptr_t begin = image_base + phdr->p_vaddr;
 uintptr_t end = begin + phdr->p_memsz;
 if (cbdata->targetAddr >= begin && cbdata->targetAddr < end) {
   cbdata->sects->dso_base = begin;
@@ -531,11 +539,7 @@ inline bool LocalAddressSpace::findUnwin
 }
   } else if (phdr->p_type == PT_GNU_EH_FRAME) {
 EHHeaderParser::EHHeaderInfo hdrInfo;
-uintptr_t eh_frame_hdr_start = pinfo->dlpi_addr + phdr->p_vaddr;
-#if defined(__ANDROID__)
-if (pinfo->dlpi_addr == 0 && phdr->p_vaddr < image_base)
-  eh_frame_hdr_start = eh_frame_hdr_start + image_base;
-#endif
+uintptr_t eh_frame_hdr_start = image_base + phdr->p_vaddr;

[PATCH] D69036: [libTooling] Fix r374962: add more Transformer forwarding decls.

2019-10-16 Thread Alexander Kornienko via Phabricator via cfe-commits

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

LG.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69036



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

r375003 - [libTooling] Fix r374962: add more Transformer forwarding decls.

2019-10-16 Thread Yitzhak Mandelbaum via cfe-commits

Author: ymandel
Date: Wed Oct 16 07:26:20 2019
New Revision: 375003

URL: http://llvm.org/viewvc/llvm-project?rev=375003&view=rev
Log:
[libTooling] Fix r374962: add more Transformer forwarding decls.

Summary:
The move to a new, single namespace in r374962 left out some type definitions
from the old namespace and resulted in one naming conflict (`text`).  This
revision adds aliases for those definitions and removes one of the `text`
functions from the new namespace.

Reviewers: alexfh

Subscribers: cfe-commits

Tags: #clang

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

Modified:
cfe/trunk/include/clang/Tooling/Transformer/RangeSelector.h
cfe/trunk/include/clang/Tooling/Transformer/RewriteRule.h
cfe/trunk/include/clang/Tooling/Transformer/Stencil.h
cfe/trunk/unittests/Tooling/TransformerTest.cpp

Modified: cfe/trunk/include/clang/Tooling/Transformer/RangeSelector.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Tooling/Transformer/RangeSelector.h?rev=375003&r1=375002&r2=375003&view=diff
==
--- cfe/trunk/include/clang/Tooling/Transformer/RangeSelector.h (original)
+++ cfe/trunk/include/clang/Tooling/Transformer/RangeSelector.h Wed Oct 16 
07:26:20 2019
@@ -92,6 +92,8 @@ RangeSelector expansion(RangeSelector S)
 namespace tooling {
 // DEPRECATED: These are temporary aliases supporting client migration to the
 // `transformer` namespace.
+using RangeSelector = transformer::RangeSelector;
+
 using transformer::after;
 using transformer::before;
 using transformer::callArgs;

Modified: cfe/trunk/include/clang/Tooling/Transformer/RewriteRule.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Tooling/Transformer/RewriteRule.h?rev=375003&r1=375002&r2=375003&view=diff
==
--- cfe/trunk/include/clang/Tooling/Transformer/RewriteRule.h (original)
+++ cfe/trunk/include/clang/Tooling/Transformer/RewriteRule.h Wed Oct 16 
07:26:20 2019
@@ -31,11 +31,6 @@
 namespace clang {
 namespace transformer {
 using TextGenerator = MatchConsumer;
-/// Wraps a string as a TextGenerator.
-inline TextGenerator text(std::string M) {
-  return [M](const ast_matchers::MatchFinder::MatchResult &)
- -> Expected { return M; };
-}
 
 // Description of a source-code edit, expressed in terms of an AST node.
 // Includes: an ID for the (bound) node, a selector for source related to the
@@ -221,7 +216,9 @@ inline ASTEdit insertAfter(RangeSelector
 
 /// Removes the source selected by \p S.
 inline ASTEdit remove(RangeSelector S) {
-  return change(std::move(S), text(""));
+  return change(std::move(S),
+[](const ast_matchers::MatchFinder::MatchResult &)
+-> Expected { return ""; });
 }
 
 /// The following three functions are a low-level part of the RewriteRule
@@ -286,6 +283,14 @@ translateEdits(const ast_matchers::Match
 namespace tooling {
 // DEPRECATED: These are temporary aliases supporting client migration to the
 // `transformer` namespace.
+/// Wraps a string as a TextGenerator.
+using TextGenerator = transformer::TextGenerator;
+
+inline TextGenerator text(std::string M) {
+  return [M](const ast_matchers::MatchFinder::MatchResult &)
+ -> Expected { return M; };
+}
+
 using transformer::addInclude;
 using transformer::applyFirst;
 using transformer::change;
@@ -293,7 +298,6 @@ using transformer::insertAfter;
 using transformer::insertBefore;
 using transformer::makeRule;
 using transformer::remove;
-using transformer::text;
 using transformer::RewriteRule;
 using transformer::IncludeFormat;
 namespace detail {

Modified: cfe/trunk/include/clang/Tooling/Transformer/Stencil.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Tooling/Transformer/Stencil.h?rev=375003&r1=375002&r2=375003&view=diff
==
--- cfe/trunk/include/clang/Tooling/Transformer/Stencil.h (original)
+++ cfe/trunk/include/clang/Tooling/Transformer/Stencil.h Wed Oct 16 07:26:20 
2019
@@ -195,9 +195,11 @@ StencilPart dPrint(llvm::StringRef Id);
 } // namespace transformer
 
 namespace tooling {
-namespace stencil {
 // DEPRECATED: These are temporary aliases supporting client migration to the
 // `transformer` namespace.
+using Stencil = transformer::Stencil;
+using StencilPart = transformer::StencilPart;
+namespace stencil {
 using transformer::access;
 using transformer::addressOf;
 using transformer::cat;

Modified: cfe/trunk/unittests/Tooling/TransformerTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Tooling/TransformerTest.cpp?rev=375003&r1=375002&r2=375003&view=diff
==
--- cfe/trunk/unittests/Tooling/TransformerTest.cpp (original)
+++ cfe/trunk/unittests/Tooling/TransformerTest.cpp Wed Oct 16 07:26:20 2019
@@ -21,

[PATCH] D68694: [clang-tidy] hicpp-signed-bitwise: Do not show "use of a signed integer operand with a binary bitwise operator" for positive integer operands

2019-10-16 Thread Aaron Ballman via Phabricator via cfe-commits

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

LGTM aside from a small nit.




Comment at: clang-tools-extra/docs/ReleaseNotes.rst:174
+- The :doc:`hicpp-signed-bitwise
+  ` now supports 
`IgnorePositiveIntegerLiterals`
+  option.

`IgnorePositiveIntegerLiterals` should use two backticks instead of one.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D68694



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

[PATCH] D69036: [libTooling] Fix r374962: add more Transformer forwarding decls.

2019-10-16 Thread Yitzhak Mandelbaum via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rGc14f1ea25e05: [libTooling] Fix r374962: add more Transformer 
forwarding decls. (authored by ymandel).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69036

Files:
  clang/include/clang/Tooling/Transformer/RangeSelector.h
  clang/include/clang/Tooling/Transformer/RewriteRule.h
  clang/include/clang/Tooling/Transformer/Stencil.h
  clang/unittests/Tooling/TransformerTest.cpp


Index: clang/unittests/Tooling/TransformerTest.cpp
===
--- clang/unittests/Tooling/TransformerTest.cpp
+++ clang/unittests/Tooling/TransformerTest.cpp
@@ -21,7 +21,6 @@
 namespace {
 using ::testing::IsEmpty;
 using transformer::RewriteRule;
-using transformer::text;
 
 constexpr char KHeaderContents[] = R"cc(
   struct string {
Index: clang/include/clang/Tooling/Transformer/Stencil.h
===
--- clang/include/clang/Tooling/Transformer/Stencil.h
+++ clang/include/clang/Tooling/Transformer/Stencil.h
@@ -195,9 +195,11 @@
 } // namespace transformer
 
 namespace tooling {
-namespace stencil {
 // DEPRECATED: These are temporary aliases supporting client migration to the
 // `transformer` namespace.
+using Stencil = transformer::Stencil;
+using StencilPart = transformer::StencilPart;
+namespace stencil {
 using transformer::access;
 using transformer::addressOf;
 using transformer::cat;
Index: clang/include/clang/Tooling/Transformer/RewriteRule.h
===
--- clang/include/clang/Tooling/Transformer/RewriteRule.h
+++ clang/include/clang/Tooling/Transformer/RewriteRule.h
@@ -31,11 +31,6 @@
 namespace clang {
 namespace transformer {
 using TextGenerator = MatchConsumer;
-/// Wraps a string as a TextGenerator.
-inline TextGenerator text(std::string M) {
-  return [M](const ast_matchers::MatchFinder::MatchResult &)
- -> Expected { return M; };
-}
 
 // Description of a source-code edit, expressed in terms of an AST node.
 // Includes: an ID for the (bound) node, a selector for source related to the
@@ -221,7 +216,9 @@
 
 /// Removes the source selected by \p S.
 inline ASTEdit remove(RangeSelector S) {
-  return change(std::move(S), text(""));
+  return change(std::move(S),
+[](const ast_matchers::MatchFinder::MatchResult &)
+-> Expected { return ""; });
 }
 
 /// The following three functions are a low-level part of the RewriteRule
@@ -286,6 +283,14 @@
 namespace tooling {
 // DEPRECATED: These are temporary aliases supporting client migration to the
 // `transformer` namespace.
+/// Wraps a string as a TextGenerator.
+using TextGenerator = transformer::TextGenerator;
+
+inline TextGenerator text(std::string M) {
+  return [M](const ast_matchers::MatchFinder::MatchResult &)
+ -> Expected { return M; };
+}
+
 using transformer::addInclude;
 using transformer::applyFirst;
 using transformer::change;
@@ -293,7 +298,6 @@
 using transformer::insertBefore;
 using transformer::makeRule;
 using transformer::remove;
-using transformer::text;
 using transformer::RewriteRule;
 using transformer::IncludeFormat;
 namespace detail {
Index: clang/include/clang/Tooling/Transformer/RangeSelector.h
===
--- clang/include/clang/Tooling/Transformer/RangeSelector.h
+++ clang/include/clang/Tooling/Transformer/RangeSelector.h
@@ -92,6 +92,8 @@
 namespace tooling {
 // DEPRECATED: These are temporary aliases supporting client migration to the
 // `transformer` namespace.
+using RangeSelector = transformer::RangeSelector;
+
 using transformer::after;
 using transformer::before;
 using transformer::callArgs;


Index: clang/unittests/Tooling/TransformerTest.cpp
===
--- clang/unittests/Tooling/TransformerTest.cpp
+++ clang/unittests/Tooling/TransformerTest.cpp
@@ -21,7 +21,6 @@
 namespace {
 using ::testing::IsEmpty;
 using transformer::RewriteRule;
-using transformer::text;
 
 constexpr char KHeaderContents[] = R"cc(
   struct string {
Index: clang/include/clang/Tooling/Transformer/Stencil.h
===
--- clang/include/clang/Tooling/Transformer/Stencil.h
+++ clang/include/clang/Tooling/Transformer/Stencil.h
@@ -195,9 +195,11 @@
 } // namespace transformer
 
 namespace tooling {
-namespace stencil {
 // DEPRECATED: These are temporary aliases supporting client migration to the
 // `transformer` namespace.
+using Stencil = transformer::Stencil;
+using StencilPart = transformer::StencilPart;
+namespace stencil {
 using transformer::access;
 using transformer::addressOf;
 using transformer::cat;
Index: clang/include/clang/Tooling/Transformer/RewriteRule.h
===

[PATCH] D68028: [clang] Add no_builtin attribute

2019-10-16 Thread Aaron Ballman via Phabricator via cfe-commits

aaron.ballman added a comment.

In D68028#1707931 , @gchatelet wrote:

> A gentle ping @aaron.ballman

Sorry for the delay, I was traveling for last week.

Comment at: clang/include/clang/Basic/AttrDocs.td:4402
+The ``__attribute__((no_builtin))`` is similar to the ``-fno-builtin`` flag
+except it is specific to the body of a function.
+

I'd appreciate a blurb in here to the effect: `The attribute may also be 
applied to a virtual function but has no effect on the behavior of overriding 
functions in a derived class.`

Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:3600
   "attribute">;
+def err_attribute_no_builtin_invalid_builtin_name : Error<
+  "'%0' is not a valid builtin name for %1">;

I think this should be a warning rather than an error.

Imagine the situation where the user uses Clang 11 to write their code and they 
disable a Clang 11-specific builtin from being used, but then they try to 
compile the code in Clang 10 which doesn't know about the builtin.

Rather than err, it seems reasonable to warn about the unknown builtin name 
(under a new warning flag group under `-Wattributes`) and then just ignore the 
attribute. Because the builtin is unknown anyway, we won't transform any 
constructs to use it.

Comment at: clang/lib/Sema/SemaDecl.cpp:9508
+  // definition.
+  // FIXME: We should really be doing this in SemaDeclAttr.cpp::handleNoBuiltin
+  // but there is a bug with FunctionDecl::isThisDeclarationADefinition() which

handleNoBuiltin -> handleNoBuiltinAttr

Comment at: clang/lib/Sema/SemaDeclAttr.cpp:1072
+NoBuiltinAttr *
+Sema::mergeNoBuiltinAttr(Decl *D, const AttributeCommonInfo &CI,
+ llvm::ArrayRef BuiltinNames) {

Sorry for the code churn, but we realized we wanted this only on definitions 
after we started down the declaration merging path. I think we do not need 
`mergeNoBuiltinAttr()` any longer and can remove most of this logic entirely -- 
you cannot re-define functions, so we don't have any attributes to merge 
together. e.g., we no longer have this situation:
```
void whatever() __attribute__((no_builtin("memcpy")));
void whatever() __attribute__((no_builtin("memmove"))) {} // Should ignore both 
memcpy and memmove
```
I think the only part that needs to move over to `handleNoBuiltinAttr()` is the 
part diagnosing a combination of wildcard and non-wildcard arguments.

As a thought for a future patch (not requesting this be done now, unless you 
want to), should we fix-it (or possibly support) this situation?
```
void whatever() __attribute__((no_builtin("memcpy, memmove"))) {} // Note that 
it's only one string literal
```

Comment at: clang/lib/Sema/SemaDeclAttr.cpp:1103
+
+static void handleNoBuiltin(Sema &S, Decl *D, const ParsedAttr &AL) {
+  if (!checkAttributeAtLeastNumArgs(S, AL, 1))

Can you rename this to `handleNoBuiltinAttr` for consistency?

Comment at: clang/test/CodeGen/no-builtin.c:20
+void separate_attrs_ordering() __attribute__((no_builtin("memcpy"))) 
__attribute__((no_builtin("memset"))) {}
+
+// CHECK: attributes #0 = {{{.*}}"no-builtin-memcpy"{{.*}}}

I'd like to see a codegen case that ensures we don't do bad things with virtual 
function overrides:
```
struct S {
  virtual void foo() __attribute__((no_builtin("memcpy"))) {}
};

struct D : S {
  void foo() __attribute__((no_builtin("memmove"))) {}
};
```
We should ensure that `S::foo()` only prohibits `memcpy` and `D::foo()` only 
prohibits `memmove`.

Comment at: clang/test/Sema/no-builtin.c:1
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -S -emit-llvm -o - -verify %s
+

aaron.ballman wrote:
> This should not be emitting LLVM -- it should be `-fsyntax-only`, however.
This still has `-S -emit-llvm -o -`; that should be removed, no?

Comment at: clang/test/Sema/no-builtin.c:26
+int __attribute__((no_builtin("*"))) variable;
+// expected-warning@-1 {{'no_builtin' attribute only applies to functions}}

You should probably add another test case for this situation:
```
void whatever() __attribute__((no_builtin("*", "*"))) {}
```
and for member functions in C++ as well:
```
struct S {
  void whatever() __attribute__((no_builtin("memcpy"))) {}
  virtual void intentional() __attribute__((no_builtin("memcpy"))) {}
};
```

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68028

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

[PATCH] D68581: Include leading attributes in DeclStmt's SourceRange

2019-10-16 Thread 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, assuming the requested test changes are as successful as I expect they 
will be (doesn't need additional review if the tests pass).




Comment at: clang/test/AST/sourceranges.cpp:155
+
+#if __cplusplus >= 201703L
+  void cpp17() {

Why is this guarded on C++17? `[[maybe_unused]]` is supported in every language 
mode used by this test (it generates a warning, but we're FileCheck'ing so 
that's fine -- but you could use `[[deprecated("")]]` instead if you want).

Additionally, I'd appreciate one more test case testing a `__declspec` 
attribute as well, to make sure we're handling that properly as well.


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

https://reviews.llvm.org/D68581



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

[PATCH] D69043: [RFC] Adding time-trace to LLD?

2019-10-16 Thread Russell Gallop via Phabricator via cfe-commits

russell.gallop created this revision.
russell.gallop added reviewers: ruiu, pcc, anton-afanasyev.
Herald added subscribers: cfe-commits, dexonsmith, MaskRay, hiraditya, 
arichardson, mehdi_amini, emaste.
Herald added a reviewer: espindola.
Herald added projects: clang, LLVM.

The clang -ftime-trace feature is useful for analysing build time in compiles. 
I've been experimenting with adding time-trace support to LLD for analysing 
link times.

Adding the option -time-trace produces a .json file alongside the output ELF 
file (just ELF so far). This works for LTO and ThinLTO, picking up the relevant 
markers from LLVM. Example ThinLTO build:
F10284608: ThinLTOTimeTrace.PNG 

This is still work in progress so shouldn't be submitted in its present state. 
There are a few things that still need doing:

- Improve how events are collected. (The current method combines multiple 
threads (ThinLTO) in one stack with a mutex which won't scale well. Making this 
thread local would probably be better.)
- Adding test(s)
- Re-enable the assertion for monotonically increasing times which I don't have 
working yet.

Do people think that this will be useful/worth pursuing?


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D69043

Files:
  clang/tools/driver/cc1_main.cpp
  lld/ELF/Driver.cpp
  lld/ELF/ICF.cpp
  lld/ELF/MarkLive.cpp
  lld/ELF/Options.td
  lld/ELF/Writer.cpp
  llvm/include/llvm/Support/TimeProfiler.h
  llvm/lib/Support/TimeProfiler.cpp

Index: llvm/lib/Support/TimeProfiler.cpp
===
--- llvm/lib/Support/TimeProfiler.cpp
+++ llvm/lib/Support/TimeProfiler.cpp
@@ -13,8 +13,9 @@
 #include "llvm/Support/TimeProfiler.h"
 #include "llvm/ADT/StringMap.h"
 #include "llvm/Support/CommandLine.h"
-#include "llvm/Support/FileSystem.h"
 #include "llvm/Support/JSON.h"
+#include "llvm/Support/Path.h"
+#include "llvm/Support/Threading.h"
 #include 
 #include 
 #include 
@@ -37,10 +38,11 @@
   TimePointType End;
   std::string Name;
   std::string Detail;
+  uint64_t Tid;
 
   Entry(TimePointType &&S, TimePointType &&E, std::string &&N, std::string &&Dt)
   : Start(std::move(S)), End(std::move(E)), Name(std::move(N)),
-Detail(std::move(Dt)){};
+Detail(std::move(Dt)), Tid(llvm::get_threadid()){};
 
   // Calculate timings for FlameGraph. Cast time points to microsecond precision
   // rather than casting duration. This avoid truncation issues causing inner
@@ -59,26 +61,47 @@
 };
 
 struct TimeTraceProfiler {
-  TimeTraceProfiler() {
+  TimeTraceProfiler(StringRef ProgName) {
 StartTime = steady_clock::now();
+this->ProgName = ProgName;
   }
 
   void begin(std::string Name, llvm::function_ref Detail) {
+std::lock_guard Lock(Mu);
 Stack.emplace_back(steady_clock::now(), TimePointType(), std::move(Name),
Detail());
   }
 
   void end() {
+std::lock_guard Lock(Mu);
+uint64_t Tid = llvm::get_threadid();
+
 assert(!Stack.empty() && "Must call begin() first");
-auto &E = Stack.back();
+
+// Find the latest entry from this thread on the stack.
+auto LatestEvent =
+std::find_if(Stack.rbegin(), Stack.rend(),
+ [&](const Entry &Val) { return Val.Tid == Tid; });
+// Should always be able to find a stack entry on this thread.
+assert(LatestEvent != Stack.rend() &&
+   "end() without begin() found on thread");
+
+// Get reference from iterator.
+auto &E = *LatestEvent;
+
 E.End = steady_clock::now();
 
 // Check that end times monotonically increase.
-assert((Entries.empty() ||
-(E.getFlameGraphStartUs(StartTime) + E.getFlameGraphDurUs() >=
- Entries.back().getFlameGraphStartUs(StartTime) +
- Entries.back().getFlameGraphDurUs())) &&
-   "TimeProfiler scope ended earlier than previous scope");
+//auto LastEntryOnThreadIter = std::find_if(Entries.rbegin(),
+//Entries.rend(), [&](const Entry &Val) {
+//  return Val.Tid == Tid;
+//});
+//auto &LastEntryOnThread = *LastEntryOnThreadIter;
+//assert((Entries.empty() ||
+//(E.getFlameGraphStartUs(StartTime) + E.getFlameGraphDurUs() >=
+// LastEntryOnThread.getFlameGraphStartUs(StartTime) +
+// LastEntryOnThread.getFlameGraphDurUs())) &&
+//   "TimeProfiler scope ended earlier than previous scope");
 
 // Calculate duration at full precision for overall counts.
 DurationType Duration = E.End - E.Start;
@@ -92,18 +115,21 @@
 // templates from within, we only want to add the topmost one. "topmost"
 // happens to be the ones that don't have any currently open entries above
 // itself.
-if (std::find_if(++Stack.rbegin(), Stack.rend(), [&](const Entry &Val) {
-  return Val.Name == E.Name;
-}) == Stack.rend()) {
+if (std::find_if(std::next(

[PATCH] D62686: [RISCV] Add support for save/restore of callee-saved registers via libcalls

2019-10-16 Thread Lewis Revill via Phabricator via cfe-commits

lewis-revill updated this revision to Diff 225230.
lewis-revill added a comment.

Disable the save/restore optimization when a function contains tail calls. 
Address various miscellaneous concerns with the patch. Update tests to include 
less redundant code when checking cases where save/restore libcalls are not 
used.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62686

Files:
  clang/lib/Driver/ToolChains/Arch/RISCV.cpp
  clang/test/Driver/riscv-features.c
  llvm/lib/Target/RISCV/RISCV.td
  llvm/lib/Target/RISCV/RISCVFrameLowering.cpp
  llvm/lib/Target/RISCV/RISCVFrameLowering.h
  llvm/lib/Target/RISCV/RISCVMachineFunctionInfo.h
  llvm/lib/Target/RISCV/RISCVRegisterInfo.cpp
  llvm/lib/Target/RISCV/RISCVRegisterInfo.h
  llvm/lib/Target/RISCV/RISCVSubtarget.h
  llvm/test/CodeGen/RISCV/saverestore.ll

Index: llvm/test/CodeGen/RISCV/saverestore.ll
===
--- /dev/null
+++ llvm/test/CodeGen/RISCV/saverestore.ll
@@ -0,0 +1,299 @@
+; RUN: llc -mtriple=riscv32 < %s | FileCheck %s -check-prefix=RV32I
+; RUN: llc -mtriple=riscv64 < %s | FileCheck %s -check-prefix=RV64I
+; RUN: llc -mtriple=riscv32 -mattr=+save-restore < %s | FileCheck %s -check-prefix=RV32I-SR
+; RUN: llc -mtriple=riscv64 -mattr=+save-restore < %s | FileCheck %s -check-prefix=RV64I-SR
+; RUN: llc -mtriple=riscv32 -mattr=+f,+save-restore -target-abi=ilp32f < %s | FileCheck %s -check-prefix=RV32I-FP-SR
+; RUN: llc -mtriple=riscv64 -mattr=+f,+d,+save-restore -target-abi=lp64d < %s | FileCheck %s -check-prefix=RV64I-FP-SR
+
+; Check that the correct save/restore libcalls are generated.
+
+@var0 = global [18 x i32] zeroinitializer
+@var1 = global [24 x i32] zeroinitializer
+@var2 = global [30 x i32] zeroinitializer
+
+define void @callee_saved0() nounwind {
+; RV32I-LABEL: callee_saved0:
+; RV32I-NOT: call t0, __riscv_save
+; RV32I-NOT: tail __riscv_restore
+;
+; RV64I-LABEL: callee_saved0:
+; RV64I-NOT: call t0, __riscv_save
+; RV64I-NOT: tail __riscv_restore
+;
+; RV32I-SR-LABEL: callee_saved0:
+; RV32I-SR: call t0, __riscv_save_5
+; RV32I-SR: tail __riscv_restore_5
+;
+; RV64I-SR-LABEL: callee_saved0:
+; RV64I-SR: call t0, __riscv_save_5
+; RV64I-SR: tail __riscv_restore_5
+;
+; RV32I-FP-SR-LABEL: callee_saved0:
+; RV32I-FP-SR: call t0, __riscv_save_5
+; RV32I-FP-SR: tail __riscv_restore_5
+;
+; RV64I-FP-SR-LABEL: callee_saved0:
+; RV64I-FP-SR: call t0, __riscv_save_5
+; RV64I-FP-SR: tail __riscv_restore_5
+  %val = load [18 x i32], [18 x i32]* @var0
+  store volatile [18 x i32] %val, [18 x i32]* @var0
+  ret void
+}
+
+define void @callee_saved1() nounwind {
+; RV32I-LABEL: callee_saved1:
+; RV32I-NOT: call t0, __riscv_save
+; RV32I-NOT: tail __riscv_restore
+;
+; RV64I-LABEL: callee_saved1:
+; RV64I-NOT: call t0, __riscv_save
+; RV64I-NOT: tail __riscv_restore
+;
+; RV32I-SR-LABEL: callee_saved1:
+; RV32I-SR: call t0, __riscv_save_11
+; RV32I-SR: tail __riscv_restore_11
+;
+; RV64I-SR-LABEL: callee_saved1:
+; RV64I-SR: call t0, __riscv_save_11
+; RV64I-SR: tail __riscv_restore_11
+;
+; RV32I-FP-SR-LABEL: callee_saved1:
+; RV32I-FP-SR: call t0, __riscv_save_11
+; RV32I-FP-SR: tail __riscv_restore_11
+;
+; RV64I-FP-SR-LABEL: callee_saved1:
+; RV64I-FP-SR: call t0, __riscv_save_11
+; RV64I-FP-SR: tail __riscv_restore_11
+  %val = load [24 x i32], [24 x i32]* @var1
+  store volatile [24 x i32] %val, [24 x i32]* @var1
+  ret void
+}
+
+define void @callee_saved2() nounwind {
+; RV32I-LABEL: callee_saved2:
+; RV32I-NOT: call t0, __riscv_save
+; RV32I-NOT: tail __riscv_restore
+;
+; RV64I-LABEL: callee_saved2:
+; RV64I-NOT: call t0, __riscv_save
+; RV64I-NOT: tail __riscv_restore
+;
+; RV32I-SR-LABEL: callee_saved2:
+; RV32I-SR: call t0, __riscv_save_12
+; RV32I-SR: tail __riscv_restore_12
+;
+; RV64I-SR-LABEL: callee_saved2:
+; RV64I-SR: call t0, __riscv_save_12
+; RV64I-SR: tail __riscv_restore_12
+;
+; RV32I-FP-SR-LABEL: callee_saved2:
+; RV32I-FP-SR: call t0, __riscv_save_12
+; RV32I-FP-SR: tail __riscv_restore_12
+;
+; RV64I-FP-SR-LABEL: callee_saved2:
+; RV64I-FP-SR: call t0, __riscv_save_12
+; RV64I-FP-SR: tail __riscv_restore_12
+  %val = load [30 x i32], [30 x i32]* @var2
+  store volatile [30 x i32] %val, [30 x i32]* @var2
+  ret void
+}
+
+; Check that floating point callee saved registers are still manually saved and
+; restored.
+
+define void @callee_saved_fp() nounwind {
+; RV32I-LABEL: callee_saved_fp:
+; RV32I-NOT: call t0, __riscv_save
+; RV32I-NOT: tail __riscv_restore
+;
+; RV64I-LABEL: callee_saved_fp:
+; RV64I-NOT: call t0, __riscv_save
+; RV64I-NOT: tail __riscv_restore
+;
+; RV32I-SR-LABEL: callee_saved_fp:
+; RV32I-SR: call t

[PATCH] D68117: [DWARF-5] Support for C++11 defaulted, deleted member functions.

2019-10-16 Thread Paul Robinson via Phabricator via cfe-commits

probinson added a comment.

In D68117#1710295 , @dblaikie wrote:

> I think the existing feature's perhaps a bit misspecified - because where you 
> put the DEFAULTED_{in_class,out_of_class} would communicate that without 
> needing the two values - if you put it on an out of line function definition, 
> it's defaulted out of line, if you put it on the in-class declaration then 
> it's defaulted inline.
>
> But spec'd the way it is, if we want to implement this at all/if there's some 
> actual user need (admittedly the noreturn attribute has gone in recently 
> without a discussion of usage... so I'm not the only gatekeeper here & other 
> people have other opinions, and that's OK - if someone (@probinson @aprantl 
> etc) want to tell me I'm being unreasonable here & we should just put it in - 
> it's only a bit here or there & not likely to make a huge difference to DWARF 
> size & possibly enable some scenarios we haven't imagined yet and avoid the 
> chicken-and-egg problem for the future implementer of such features, that's 
> OK) - I'd essentially implement it that way. Put DEFAULTED_out_of_class on 
> the member function definition DIE if it's defaulted there, and put 
> DEFAULTED_in_class on the declaration DIE if it's defaulted there.
>
> And I'd probably only spend one bit of flags on this, if possible - "not 
> defaulted (0/assumed for all subprograms) or defaulted (1)" and translate it 
> into one of the two values (in_class or out_of_class) in the backend based on 
> which subprogram DIE it's attached to.

That seems reasonable too.  Of course if we're already spending a bit on 
Deleted, and the same subprogram can't be both Deleted and Defaulted, it costs 
no extra DISP bits to represent the 4 cases (defaulted-in-class, 
defaulted-out-of-class, deleted, none-of-the-above).

@SouraVX I would say we should never emit DEFAULTED_no.  If the compiler 
organized its internal data differently, and had a canned abbreviation for 
ctors/dtors that included DW_AT_defaulted, then we'd need to fill that in; but 
that's not how LLVM handles DWARF, it creates abbreviations on demand.  So, 
doing nothing in the none-of-the-above case would be best here.

(@dblaikie Aside regarding noreturn, the original DWARF proposal was for a 
debugger wanting to know a given function will not return.  As a flag, in the 
DWARF it costs an extra abbrev entry but no space in .debug_info.  Cheap enough 
for me.)

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

https://reviews.llvm.org/D68117

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

[PATCH] D68876: [libTooling] Put all Transformer declarations in a single namespace.

2019-10-16 Thread Adrian Prantl via Phabricator via cfe-commits

aprantl added a comment.

This broke the modular build since some symbols are now ambiguous within the 
same Clang module.'

http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/2646/consoleFull#25217323649ba4694-19c4-4d7e-bec5-911270d8a58c

  FAILED: 
tools/clang/lib/Tooling/CMakeFiles/obj.clangTooling.dir/AllTUsExecution.cpp.o 
  /Users/buildslave/jenkins/workspace/lldb-cmake/host-compiler/bin/clang++  
-DGTEST_HAS_RTTI=0 -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS 
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Itools/clang/lib/Tooling 
-I/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/clang/lib/Tooling 
-I/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/clang/include 
-Itools/clang/include 
-I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/libxml2
 -Iinclude 
-I/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/include 
-Wdocumentation -fPIC -fvisibility-inlines-hidden -Werror=date-time 
-Werror=unguarded-availability-new -std=c++14 -fmodules 
-fmodules-cache-path=/Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/module.cache
 -fcxx-modules -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual 
-Wmissing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough 
-Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor 
-Wdelete-non-virtual-dtor -Wstring-conversion -fdiagnostics-color -fno-common 
-Woverloaded-virtual -Wno-nested-anon-types -O3  -isysroot 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk
   -UNDEBUG  -fno-exceptions -fno-rtti -MD -MT 
tools/clang/lib/Tooling/CMakeFiles/obj.clangTooling.dir/AllTUsExecution.cpp.o 
-MF 
tools/clang/lib/Tooling/CMakeFiles/obj.clangTooling.dir/AllTUsExecution.cpp.o.d 
-o 
tools/clang/lib/Tooling/CMakeFiles/obj.clangTooling.dir/AllTUsExecution.cpp.o 
-c 
/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/clang/lib/Tooling/AllTUsExecution.cpp
  While building module 'Clang_Tooling' imported from 
/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/clang/lib/Tooling/AllTUsExecution.cpp:9:
  In file included from :44:
  In file included from 
/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/clang/include/clang/Tooling/Transformer/Transformer.h:14:
  
/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/clang/include/clang/Tooling/Transformer/RewriteRule.h:224:31:
 error: call to 'text' is ambiguous
return change(std::move(S), text(""));
^~~~
  
/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/clang/include/clang/Tooling/Transformer/Stencil.h:145:13:
 note: candidate function
  StencilPart text(llvm::StringRef Text);
  ^
  
/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/clang/include/clang/Tooling/Transformer/RewriteRule.h:35:22:
 note: candidate function
  inline TextGenerator text(std::string M) {
   ^
  
/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/clang/lib/Tooling/AllTUsExecution.cpp:9:10:
 fatal error: could not build module 'Clang_Tooling'
  #include "clang/Tooling/AllTUsExecution.h"
   ^
  2 errors generated.

Can you please fix and/or revert?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68876



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

[PATCH] D23934: Add a -ffixed-date-time= flag that sets the initial value of DATE, TIME, TIMESTAMP

2019-10-16 Thread Alexander Belopolsky via Phabricator via cfe-commits

Alexander added a comment.

What is the status of this issue?


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

https://reviews.llvm.org/D23934



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

[PATCH] D69033: [clangd] Improve symbol qualification in DefineInline code action

2019-10-16 Thread Christian Kühnel via Phabricator via cfe-commits

kuhnel added a comment.

Build failed during patching:

  00:03:00.433 [Phabricator] $ arc patch --diff 225207 --nocommit --nobranch 
--conduit-uri=https://reviews.llvm.org 
  00:03:01.736  INFO  Base commit is not in local repository; trying to fetch.
  00:03:02.694 
  00:03:02.694 
  00:03:02.695 This diff is against commit 
48ec5c8b81c23061eac4fe6f3a14e2e876b8d265, but
  00:03:02.695 the commit is nowhere in the working copy. Try to apply it 
against the
  00:03:02.695 current working copy state? 
(fdccf28697e5debe861247d218cbbecf9fd4323e)
  00:03:02.695 [Y/n]  Exception 
  00:03:02.695 The program is attempting to read user input, but stdin is being 
piped from some other source (not a TTY).
  00:03:02.695 (Run with `--trace` for a full exception trace.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69033



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

[PATCH] D68937: [clangd] Add parameter renaming to define-inline code action

2019-10-16 Thread Christian Kühnel via Phabricator via cfe-commits

kuhnel added a comment.

Build failed as patch failed to apply:

  00:00:06.098 Checking patch clang-tools-extra/trunk/clangd/FindTarget.h...
  00:00:06.100 error: clang-tools-extra/trunk/clangd/FindTarget.h: does not 
exist in index
  00:00:06.100 Checking patch clang-tools-extra/trunk/clangd/FindTarget.cpp...
  00:00:06.100 error: clang-tools-extra/trunk/clangd/FindTarget.cpp: does not 
exist in index
  00:00:06.101 
  00:00:06.101  Patch Failed! 
  00:00:06.101 Usage Exception: Unable to apply patch!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68937



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

r375012 - [DWARF5] Added support for DW_AT_noreturn attribute to be emitted for

2019-10-16 Thread Adrian Prantl via cfe-commits

Author: adrian
Date: Wed Oct 16 09:30:38 2019
New Revision: 375012

URL: http://llvm.org/viewvc/llvm-project?rev=375012&view=rev
Log:
[DWARF5] Added support for DW_AT_noreturn attribute to be emitted for
C++ class member functions.

Patch by Sourabh Singh Tomar!

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

Added:
cfe/trunk/test/CodeGenCXX/debug-info-noreturn.cpp
Modified:
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp

Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=375012&r1=375011&r2=375012&view=diff
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Wed Oct 16 09:30:38 2019
@@ -1605,6 +1605,8 @@ llvm::DISubprogram *CGDebugInfo::CreateC
 ContainingType = RecordTy;
   }
 
+  if (Method->isNoReturn())
+Flags |= llvm::DINode::FlagNoReturn;
   if (Method->isStatic())
 Flags |= llvm::DINode::FlagStaticMember;
   if (Method->isImplicit())

Added: cfe/trunk/test/CodeGenCXX/debug-info-noreturn.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/debug-info-noreturn.cpp?rev=375012&view=auto
==
--- cfe/trunk/test/CodeGenCXX/debug-info-noreturn.cpp (added)
+++ cfe/trunk/test/CodeGenCXX/debug-info-noreturn.cpp Wed Oct 16 09:30:38 2019
@@ -0,0 +1,19 @@
+// RUN: %clang_cc1 -std=c++11 -emit-llvm -fcxx-exceptions 
-debug-info-kind=standalone  %s -o - | FileCheck %s
+// Test for NoReturn flags in debug info.
+
+// CHECK: DISubprogram(name: "f", {{.*}}, flags: DIFlagPrototyped | 
DIFlagNoReturn, spFlags: DISPFlagDefinition
+// CHECK: DISubprogram(name: "foo_member", {{.*}}, flags: DIFlagPrototyped | 
DIFlagNoReturn, spFlags: 0
+// CHECK-NOT: DISubprogram(name: "func",{{.*}}, flags: DIFlagPrototyped | 
DIFlagNoReturn, spFlags: DISPFlagDefinition
+
+class foo {
+
+  [[noreturn]] void foo_member() { throw 1; }
+};
+
+[[noreturn]] void f() {
+  throw 1;
+}
+
+void func() {
+  foo object;
+}


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

[PATCH] D23934: Add a -ffixed-date-time= flag that sets the initial value of DATE, TIME, TIMESTAMP

2019-10-16 Thread Alexander Belopolsky via Phabricator via cfe-commits

Alexander added inline comments.



Comment at: lib/Frontend/CompilerInvocation.cpp:2252
+  TM.tm_isdst = -1;
+  mktime(&TM);
+  Opts.FixedDateTime = TM;

efriedma wrote:
> Does using mktime like this depend on the local timezone?
Since the return value of mktime() is ignored here, its dependence on the local 
timezone should not matter.  The main effect of this call is to fill in 
tm_isdst flag with the best guess.  This may result in unexpected results if 
fixed-date-time is set inside the "spring forward" hour for the local timezone, 
but this issue is inherent in the ISO 8601 format.


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

https://reviews.llvm.org/D23934



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

[PATCH] D68697: [DWARF5] Added support for DW_AT_noreturn attribute to be emitted for C++ class member functions.

2019-10-16 Thread Adrian Prantl via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rGa9cfde1f6ab5: [DWARF5] Added support for DW_AT_noreturn 
attribute to be emitted for C++ class… (authored by aprantl).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68697

Files:
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/test/CodeGenCXX/debug-info-noreturn.cpp
  llvm/test/DebugInfo/X86/noreturn_cpp11.ll

Index: llvm/test/DebugInfo/X86/noreturn_cpp11.ll
===
--- llvm/test/DebugInfo/X86/noreturn_cpp11.ll
+++ llvm/test/DebugInfo/X86/noreturn_cpp11.ll
@@ -2,56 +2,88 @@
 ; REQUIRES: object-emission
 
 ; Generated by clang++ -S -c -std=c++11 --emit-llvm -g from the following C++11 source:
-; [[ noreturn ]] void f() {
-;   throw 1;
-; }
+;class foo {
+;[[noreturn]] void foo_member(){throw 1;}
+;};
+;
+;[[ noreturn ]] void f() {
+;throw 1;
+;}
+;
+;void func(){
+;foo object;
+;}
 
 ; CHECK: DW_TAG_subprogram
 ; CHECK-NOT: DW_TAG
 ; CHECK: DW_AT_name{{.*}}"f"
 ; CHECK-NOT: DW_TAG
 ; CHECK: DW_AT_noreturn
-
+; CHECK: DW_TAG_class_type
+; CHECK: DW_TAG_subprogram
+; CHECK: DW_AT_name{{.*}}"foo_member"
+; CHECK: DW_AT_noreturn
 ; ModuleID = 'test.cpp'
-source_filename = "test.cpp"
-target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
+
+source_filename = "noreturn1.cpp"
+target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
 target triple = "x86_64-unknown-linux-gnu"
 
-@_ZTIi = external constant i8*
+%class.foo = type { i8 }
 
-; Function Attrs: noreturn
-define void @_Z1fv() #0 !dbg !6 {
-entry:
-  %exception = call i8* @__cxa_allocate_exception(i64 4) #1, !dbg !9
-  %0 = bitcast i8* %exception to i32*, !dbg !9
-  store i32 1, i32* %0, align 16, !dbg !9
-  call void @__cxa_throw(i8* %exception, i8* bitcast (i8** @_ZTIi to i8*), i8* null) #2, !dbg !10
-  unreachable, !dbg !9
+@_ZTIi = external dso_local constant i8*
 
-return:   ; No predecessors!
-  ret void, !dbg !12
+; Function Attrs: noinline noreturn optnone uwtable
+define dso_local void @_Z1fv() #0 !dbg !7 {
+  %1 = call i8* @__cxa_allocate_exception(i64 4) #3, !dbg !10
+  %2 = bitcast i8* %1 to i32*, !dbg !10
+  store i32 1, i32* %2, align 16, !dbg !10
+  call void @__cxa_throw(i8* %1, i8* bitcast (i8** @_ZTIi to i8*), i8* null) #4, !dbg !10
+  unreachable, !dbg !10
 }
 
-declare i8* @__cxa_allocate_exception(i64)
+declare dso_local i8* @__cxa_allocate_exception(i64)
+
+declare dso_local void @__cxa_throw(i8*, i8*, i8*)
+
+; Function Attrs: noinline nounwind optnone uwtable
+define dso_local void @_Z4funcv() #1 !dbg !11 {
+  %1 = alloca %class.foo, align 1
+  call void @llvm.dbg.declare(metadata %class.foo* %1, metadata !12, metadata !DIExpression()), !dbg !19
+  ret void, !dbg !20
+}
 
-declare void @__cxa_throw(i8*, i8*, i8*)
+; Function Attrs: nounwind readnone speculatable willreturn
+declare void @llvm.dbg.declare(metadata, metadata, metadata) #2
 
-attributes #0 = { noreturn }
+attributes #0 = { noinline noreturn optnone uwtable }
+attributes #1 = { noinline nounwind optnone uwtable }
+attributes #2 = { nounwind readnone speculatable willreturn }
+attributes #3 = { nounwind }
+attributes #4 = { noreturn }
 
 !llvm.dbg.cu = !{!0}
-!llvm.module.flags = !{!3, !4}
-!llvm.ident = !{!5}
+!llvm.module.flags = !{!3, !4, !5}
+!llvm.ident = !{!6}
 
-!0 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus, file: !1, producer: "clang version 4.0.0", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, enums: !2)
-!1 = !DIFile(filename: "test.cpp", directory: "/home/del/test")
+!0 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus_11, file: !1, producer: "clang version 10.0.0 (https://github.com/llvm/llvm-project.git 3fcdd25ad5566114ac3322dcbf71d3c38bfec1ed)", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, enums: !2, nameTableKind: None)
+!1 = !DIFile(filename: "test.cpp", directory: "/home/sourabh/work/dwarf/c_c++/c++11")
 !2 = !{}
 !3 = !{i32 2, !"Dwarf Version", i32 4}
 !4 = !{i32 2, !"Debug Info Version", i32 3}
-!5 = !{!"clang version 4.0.0"}
-!6 = distinct !DISubprogram(name: "f", linkageName: "_Z1fv", scope: !1, file: !1, line: 1, type: !7, isLocal: false, isDefinition: true, scopeLine: 1, flags: DIFlagPrototyped | DIFlagNoReturn, isOptimized: false, unit: !0, retainedNodes: !2)
-!7 = !DISubroutineType(types: !8)
-!8 = !{null}
-!9 = !DILocation(line: 2, column: 5, scope: !6)
-!10 = !DILocation(line: 2, column: 5, scope: !11)
-!11 = !DILexicalBlockFile(scope: !6, file: !1, discriminator: 1)
-!12 = !DILocation(line: 3, column: 1, scope: !6)
+!5 = !{i32 1, !"wchar_size", i32 4}
+!6 = !{!"clang version 10.0.0 (https://github.com/llvm/llvm-project.git 3fcdd25ad5566114ac3322dcbf71d3c38bfec1ed)"}
+!7 = distinct !DISubprogram(name: "f", linkageName: "_Z1fv", scope: !1, file: !1, line: 5, type: !8, sc

[PATCH] D68876: [libTooling] Put all Transformer declarations in a single namespace.

2019-10-16 Thread Yitzhak Mandelbaum via Phabricator via cfe-commits

ymandel added a comment.

This should be fixed by r375003. Please let me know if that's not the case.

In D68876#1711227 , @aprantl wrote:

> This broke the modular build since some symbols are now ambiguous within the 
> same Clang module.'
>
> http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/2646/consoleFull#25217323649ba4694-19c4-4d7e-bec5-911270d8a58c
>
>   FAILED: 
> tools/clang/lib/Tooling/CMakeFiles/obj.clangTooling.dir/AllTUsExecution.cpp.o 
>   /Users/buildslave/jenkins/workspace/lldb-cmake/host-compiler/bin/clang++  
> -DGTEST_HAS_RTTI=0 -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS 
> -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Itools/clang/lib/Tooling 
> -I/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/clang/lib/Tooling
>  -I/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/clang/include 
> -Itools/clang/include 
> -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/libxml2
>  -Iinclude 
> -I/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/include 
> -Wdocumentation -fPIC -fvisibility-inlines-hidden -Werror=date-time 
> -Werror=unguarded-availability-new -std=c++14 -fmodules 
> -fmodules-cache-path=/Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/module.cache
>  -fcxx-modules -Wall -Wextra -Wno-unused-parameter -Wwrite-strings 
> -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long 
> -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type 
> -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion 
> -fdiagnostics-color -fno-common -Woverloaded-virtual -Wno-nested-anon-types 
> -O3  -isysroot 
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk
>-UNDEBUG  -fno-exceptions -fno-rtti -MD -MT 
> tools/clang/lib/Tooling/CMakeFiles/obj.clangTooling.dir/AllTUsExecution.cpp.o 
> -MF 
> tools/clang/lib/Tooling/CMakeFiles/obj.clangTooling.dir/AllTUsExecution.cpp.o.d
>  -o 
> tools/clang/lib/Tooling/CMakeFiles/obj.clangTooling.dir/AllTUsExecution.cpp.o 
> -c 
> /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/clang/lib/Tooling/AllTUsExecution.cpp
>   While building module 'Clang_Tooling' imported from 
> /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/clang/lib/Tooling/AllTUsExecution.cpp:9:
>   In file included from :44:
>   In file included from 
> /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/clang/include/clang/Tooling/Transformer/Transformer.h:14:
>   
> /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/clang/include/clang/Tooling/Transformer/RewriteRule.h:224:31:
>  error: call to 'text' is ambiguous
> return change(std::move(S), text(""));
> ^~~~
>   
> /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/clang/include/clang/Tooling/Transformer/Stencil.h:145:13:
>  note: candidate function
>   StencilPart text(llvm::StringRef Text);
>   ^
>   
> /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/clang/include/clang/Tooling/Transformer/RewriteRule.h:35:22:
>  note: candidate function
>   inline TextGenerator text(std::string M) {
>^
>   
> /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/clang/lib/Tooling/AllTUsExecution.cpp:9:10:
>  fatal error: could not build module 'Clang_Tooling'
>   #include "clang/Tooling/AllTUsExecution.h"
>^
>   2 errors generated.
>
>
> Can you please fix and/or revert?





Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68876



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

r375017 - [OPENMP]Use different addresses for zeroed thread_id/bound_id.

2019-10-16 Thread Alexey Bataev via cfe-commits

Author: abataev
Date: Wed Oct 16 09:59:01 2019
New Revision: 375017

URL: http://llvm.org/viewvc/llvm-project?rev=375017&view=rev
Log:
[OPENMP]Use different addresses for zeroed thread_id/bound_id.

When the parallel region is called directly in the sequential region,
the zeroed tid/bound id are used. But they must point to the different
memory locations as the parameters are marked as noalias.

Modified:
cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
cfe/trunk/test/OpenMP/nvptx_target_codegen.cpp
cfe/trunk/test/OpenMP/nvptx_teams_reduction_codegen.cpp
cfe/trunk/test/OpenMP/parallel_if_codegen.cpp

Modified: cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp?rev=375017&r1=375016&r2=375017&view=diff
==
--- cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp Wed Oct 16 09:59:01 2019
@@ -3075,14 +3075,18 @@ void CGOpenMPRuntime::emitParallelCall(C
 CGF.EmitRuntimeCall(
 RT.createRuntimeFunction(OMPRTL__kmpc_serialized_parallel), Args);
 
-// OutlinedFn(>id, &zero, CapturedStruct);
+// OutlinedFn(&zero, &zero_bound, CapturedStruct);
 Address ZeroAddr = CGF.CreateDefaultAlignTempAlloca(CGF.Int32Ty,
-/*Name*/ ".zero.addr");
+/*Name=*/".zero.addr");
 CGF.InitTempAlloca(ZeroAddr, CGF.Builder.getInt32(/*C*/ 0));
+Address ZeroAddrBound =
+CGF.CreateDefaultAlignTempAlloca(CGF.Int32Ty,
+ /*Name=*/".bound.zero.addr");
+CGF.InitTempAlloca(ZeroAddrBound, CGF.Builder.getInt32(/*C*/ 0));
 llvm::SmallVector OutlinedFnArgs;
 // ThreadId for serialized parallels is 0.
 OutlinedFnArgs.push_back(ZeroAddr.getPointer());
-OutlinedFnArgs.push_back(ZeroAddr.getPointer());
+OutlinedFnArgs.push_back(ZeroAddrBound.getPointer());
 OutlinedFnArgs.append(CapturedVars.begin(), CapturedVars.end());
 RT.emitOutlinedFunctionCall(CGF, Loc, OutlinedFn, OutlinedFnArgs);
 

Modified: cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp?rev=375017&r1=375016&r2=375017&view=diff
==
--- cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp Wed Oct 16 09:59:01 2019
@@ -2459,9 +2459,8 @@ void CGOpenMPRuntimeNVPTX::emitTeamsCall
   if (!CGF.HaveInsertPoint())
 return;
 
-  Address ZeroAddr = CGF.CreateMemTemp(
-  CGF.getContext().getIntTypeForBitwidth(/*DestWidth=*/32, /*Signed=*/1),
-  /*Name*/ ".zero.addr");
+  Address ZeroAddr = CGF.CreateDefaultAlignTempAlloca(CGF.Int32Ty,
+  /*Name=*/".zero.addr");
   CGF.InitTempAlloca(ZeroAddr, CGF.Builder.getInt32(/*C*/ 0));
   llvm::SmallVector OutlinedFnArgs;
   OutlinedFnArgs.push_back(emitThreadIDAddress(CGF, Loc).getPointer());
@@ -2490,16 +2489,19 @@ void CGOpenMPRuntimeNVPTX::emitNonSPMDPa
   // Force inline this outlined function at its call site.
   Fn->setLinkage(llvm::GlobalValue::InternalLinkage);
 
-  Address ZeroAddr = CGF.CreateMemTemp(CGF.getContext().getIntTypeForBitwidth(
-   /*DestWidth=*/32, /*Signed=*/1),
-   ".zero.addr");
+  Address ZeroAddr = CGF.CreateDefaultAlignTempAlloca(CGF.Int32Ty,
+  /*Name=*/".zero.addr");
   CGF.InitTempAlloca(ZeroAddr, CGF.Builder.getInt32(/*C*/ 0));
   // ThreadId for serialized parallels is 0.
   Address ThreadIDAddr = ZeroAddr;
-  auto &&CodeGen = [this, Fn, CapturedVars, Loc, ZeroAddr, &ThreadIDAddr](
+  auto &&CodeGen = [this, Fn, CapturedVars, Loc, &ThreadIDAddr](
CodeGenFunction &CGF, PrePostActionTy &Action) {
 Action.Enter(CGF);
 
+Address ZeroAddr =
+CGF.CreateDefaultAlignTempAlloca(CGF.Int32Ty,
+ /*Name=*/".bound.zero.addr");
+CGF.InitTempAlloca(ZeroAddr, CGF.Builder.getInt32(/*C*/ 0));
 llvm::SmallVector OutlinedFnArgs;
 OutlinedFnArgs.push_back(ThreadIDAddr.getPointer());
 OutlinedFnArgs.push_back(ZeroAddr.getPointer());
@@ -2656,17 +2658,19 @@ void CGOpenMPRuntimeNVPTX::emitSPMDParal
   //
   llvm::SmallVector OutlinedFnArgs;
 
-  Address ZeroAddr = CGF.CreateMemTemp(CGF.getContext().getIntTypeForBitwidth(
-   /*DestWidth=*/32, /*Signed=*/1),
-   ".zero.addr");
+  Address ZeroAddr = CGF.CreateDefaultAlignTempAlloca(CGF.Int32Ty,
+  /*Name=*/".zero.addr");

[PATCH] D63131: arm64_32: implement the desired ABI for the ILP32 triple.

2019-10-16 Thread Tim Northover via Phabricator via cfe-commits

t.p.northover updated this revision to Diff 225259.
t.p.northover added a comment.

Updating diff. How target features are handled changed slightly upstream.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63131

Files:
  clang/lib/Basic/Targets.cpp
  clang/lib/Basic/Targets/AArch64.cpp
  clang/lib/Basic/Targets/AArch64.h
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/CodeGen/TargetInfo.cpp
  clang/lib/Driver/ToolChain.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/lib/Driver/ToolChains/Darwin.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/CodeGen/arm64_32-vaarg.c
  clang/test/CodeGen/arm64_32.c
  clang/test/CodeGen/builtins-arm64.c
  clang/test/CodeGen/target-data.c
  clang/test/CodeGenCXX/armv7k.cpp
  clang/test/Driver/aarch64-cpus.c
  clang/test/Driver/arm64_32-link.c
  clang/test/Preprocessor/aarch64-target-features.c
  clang/test/Preprocessor/arm64_32.c
  clang/test/Preprocessor/init-v7k-compat.c
  clang/test/Preprocessor/stdint.c
  clang/test/Sema/aarch64-neon-vector-types.c
  clang/test/Sema/types.c

Index: clang/test/Sema/types.c
===
--- clang/test/Sema/types.c
+++ clang/test/Sema/types.c
@@ -2,6 +2,7 @@
 // RUN: %clang_cc1 %s -fblocks -pedantic -verify -triple=mips64-linux-gnu
 // RUN: %clang_cc1 %s -fblocks -pedantic -verify -triple=x86_64-unknown-linux
 // RUN: %clang_cc1 %s -fblocks -pedantic -verify -triple=x86_64-unknown-linux-gnux32
+// RUN: %clang_cc1 %s -fblocks -pedantic -pedantic -verify -triple=arm64_32-apple-ios7.0
 
 // rdar://6097662
 typedef int (*T)[2];
Index: clang/test/Sema/aarch64-neon-vector-types.c
===
--- clang/test/Sema/aarch64-neon-vector-types.c
+++ clang/test/Sema/aarch64-neon-vector-types.c
@@ -3,6 +3,8 @@
 // RUN: %clang_cc1 %s -triple arm64-none-linux-gnu -target-feature +neon -fsyntax-only -verify
 // RUN: %clang_cc1 %s -triple arm64-none-linux-gnu -target-feature +neon -DUSE_LONG -fsyntax-only -verify
 
+// RUN: %clang_cc1 %s -triple arm64_32-apple-ios -target-feature +neon -fsyntax-only -verify
+
 typedef float float32_t;
 typedef unsigned char poly8_t;
 typedef unsigned short poly16_t;
Index: clang/test/Preprocessor/stdint.c
===
--- clang/test/Preprocessor/stdint.c
+++ clang/test/Preprocessor/stdint.c
@@ -105,6 +105,113 @@
 // ARM:INTMAX_C_(0) 0LL
 // ARM:UINTMAX_C_(0) 0ULL
 //
+// RUN: %clang_cc1 -E -ffreestanding -triple=arm64_32-apple-ios7.0 %s | FileCheck -check-prefix ARM64_32 %s
+//
+// ARM64_32:typedef long long int int64_t;
+// ARM64_32:typedef long long unsigned int uint64_t;
+// ARM64_32:typedef int64_t int_least64_t;
+// ARM64_32:typedef uint64_t uint_least64_t;
+// ARM64_32:typedef int64_t int_fast64_t;
+// ARM64_32:typedef uint64_t uint_fast64_t;
+//
+// ARM64_32:typedef int int32_t;
+// ARM64_32:typedef unsigned int uint32_t;
+// ARM64_32:typedef int32_t int_least32_t;
+// ARM64_32:typedef uint32_t uint_least32_t;
+// ARM64_32:typedef int32_t int_fast32_t;
+// ARM64_32:typedef uint32_t uint_fast32_t;
+// 
+// ARM64_32:typedef short int16_t;
+// ARM64_32:typedef unsigned short uint16_t;
+// ARM64_32:typedef int16_t int_least16_t;
+// ARM64_32:typedef uint16_t uint_least16_t;
+// ARM64_32:typedef int16_t int_fast16_t;
+// ARM64_32:typedef uint16_t uint_fast16_t;
+//
+// ARM64_32:typedef signed char int8_t;
+// ARM64_32:typedef unsigned char uint8_t;
+// ARM64_32:typedef int8_t int_least8_t;
+// ARM64_32:typedef uint8_t uint_least8_t;
+// ARM64_32:typedef int8_t int_fast8_t;
+// ARM64_32:typedef uint8_t uint_fast8_t;
+//
+// ARM64_32:typedef long int intptr_t;
+// ARM64_32:typedef long unsigned int uintptr_t;
+// 
+// ARM64_32:typedef long long int intmax_t;
+// ARM64_32:typedef long long unsigned int uintmax_t;
+//
+// ARM64_32:INT8_MAX_ 127
+// ARM64_32:INT8_MIN_ (-127 -1)
+// ARM64_32:UINT8_MAX_ 255
+// ARM64_32:INT_LEAST8_MIN_ (-127 -1)
+// ARM64_32:INT_LEAST8_MAX_ 127
+// ARM64_32:UINT_LEAST8_MAX_ 255
+// ARM64_32:INT_FAST8_MIN_ (-127 -1)
+// ARM64_32:INT_FAST8_MAX_ 127
+// ARM64_32:UINT_FAST8_MAX_ 255
+//
+// ARM64_32:INT16_MAX_ 32767
+// ARM64_32:INT16_MIN_ (-32767 -1)
+// ARM64_32:UINT16_MAX_ 65535
+// ARM64_32:INT_LEAST16_MIN_ (-32767 -1)
+// ARM64_32:INT_LEAST16_MAX_ 32767
+// ARM64_32:UINT_LEAST16_MAX_ 65535
+// ARM64_32:INT_FAST16_MIN_ (-32767 -1)
+// ARM64_32:INT_FAST16_MAX_ 32767
+// ARM64_32:UINT_FAST16_MAX_ 65535
+//
+// ARM64_32:INT32_MAX_ 2147483647
+// ARM64_32:INT32_MIN_ (-2147483647 -1)
+// ARM64_32:UINT32_MAX_ 4294967295U
+// ARM64_32:INT_LEAST32_MIN_ (-2147483647 -1)
+// ARM64_32:INT_LEAST32_MAX_ 2147483647
+// ARM64_32:UINT_LEAST32_MAX_ 4294967295U
+// ARM64_32:INT_FAST32_MIN_ (-2147483647 -1)
+// ARM64_32:INT_FAST32_MAX_ 2147483647
+// ARM64_32:UINT_FAST32_MAX_ 4294967295U
+//

[PATCH] D69017: Include sanitize blacklist and other extra deps as part of scan-deps output

2019-10-16 Thread Michael Spencer via Phabricator via cfe-commits

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

lgtm. Jan may want to take a look as I believe he was looking at a related 
issue.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69017



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

r375022 - Tag CFI-generated data structures with "#pragma clang section" attributes.

2019-10-16 Thread Dmitry Mikulin via cfe-commits

Author: dmikulin
Date: Wed Oct 16 10:51:40 2019
New Revision: 375022

URL: http://llvm.org/viewvc/llvm-project?rev=375022&view=rev
Log:
Tag CFI-generated data structures with "#pragma clang section" attributes.

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

Added:
cfe/trunk/test/CodeGen/cfi-pragma-section.c
Modified:
cfe/trunk/lib/CodeGen/CGExpr.cpp
cfe/trunk/lib/CodeGen/CodeGenModule.cpp
cfe/trunk/lib/CodeGen/CodeGenModule.h
cfe/trunk/lib/Sema/SemaDecl.cpp

Modified: cfe/trunk/lib/CodeGen/CGExpr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGExpr.cpp?rev=375022&r1=375021&r2=375022&view=diff
==
--- cfe/trunk/lib/CodeGen/CGExpr.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGExpr.cpp Wed Oct 16 10:51:40 2019
@@ -2821,6 +2821,7 @@ llvm::Constant *CodeGenFunction::EmitChe
   CGM.getModule(), Descriptor->getType(),
   /*isConstant=*/true, llvm::GlobalVariable::PrivateLinkage, Descriptor);
   GV->setUnnamedAddr(llvm::GlobalValue::UnnamedAddr::Global);
+  CGM.setPragmaSectionAttributes(CurFuncDecl, GV);
   CGM.getSanitizerMetadata()->disableSanitizerForGlobal(GV);
 
   // Remember the descriptor for this type.
@@ -2900,6 +2901,7 @@ llvm::Constant *CodeGenFunction::EmitChe
 }
 
 auto FilenameGV = CGM.GetAddrOfConstantCString(FilenameString, ".src");
+CGM.setPragmaSectionAttributes(CurFuncDecl, 
cast(FilenameGV.getPointer()));
 CGM.getSanitizerMetadata()->disableSanitizerForGlobal(
   cast(FilenameGV.getPointer()));
 Filename = FilenameGV.getPointer();
@@ -3073,6 +3075,7 @@ void CodeGenFunction::EmitCheck(
   new llvm::GlobalVariable(CGM.getModule(), Info->getType(), false,
llvm::GlobalVariable::PrivateLinkage, Info);
   InfoPtr->setUnnamedAddr(llvm::GlobalValue::UnnamedAddr::Global);
+  CGM.setPragmaSectionAttributes(CurFuncDecl, InfoPtr);
   CGM.getSanitizerMetadata()->disableSanitizerForGlobal(InfoPtr);
   Args.push_back(Builder.CreateBitCast(InfoPtr, Int8PtrTy));
   ArgTypes.push_back(Int8PtrTy);

Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp?rev=375022&r1=375021&r2=375022&view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Wed Oct 16 10:51:40 2019
@@ -1699,11 +1699,8 @@ bool CodeGenModule::GetCPUAndFeaturesAtt
   return AddedAttr;
 }
 
-void CodeGenModule::setNonAliasAttributes(GlobalDecl GD,
-  llvm::GlobalObject *GO) {
-  const Decl *D = GD.getDecl();
-  SetCommonAttributes(GD, GO);
-
+void CodeGenModule::setPragmaSectionAttributes(const Decl *D,
+  llvm::GlobalObject *GO) {
   if (D) {
 if (auto *GV = dyn_cast(GO)) {
   if (auto *SA = D->getAttr())
@@ -1721,6 +1718,26 @@ void CodeGenModule::setNonAliasAttribute
 if (!D->getAttr())
   F->addFnAttr("implicit-section-name", SA->getName());
 
+  if (auto *SA = D->getAttr())
+F->addFnAttr("bss-section", SA->getName());
+  if (auto *SA = D->getAttr())
+F->addFnAttr("data-section", SA->getName());
+  if (auto *SA = D->getAttr())
+F->addFnAttr("rodata-section", SA->getName());
+  if (auto *SA = D->getAttr())
+F->addFnAttr("relro-section", SA->getName());
+}
+  }
+}
+
+void CodeGenModule::setNonAliasAttributes(GlobalDecl GD,
+  llvm::GlobalObject *GO) {
+  const Decl *D = GD.getDecl();
+  SetCommonAttributes(GD, GO);
+  setPragmaSectionAttributes(D, GO);
+
+  if (D) {
+if (auto *F = dyn_cast(GO)) {
   llvm::AttrBuilder Attrs;
   if (GetCPUAndFeaturesAttributes(GD, Attrs)) {
 // We know that GetCPUAndFeaturesAttributes will always have the

Modified: cfe/trunk/lib/CodeGen/CodeGenModule.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.h?rev=375022&r1=375021&r2=375022&view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenModule.h (original)
+++ cfe/trunk/lib/CodeGen/CodeGenModule.h Wed Oct 16 10:51:40 2019
@@ -1347,6 +1347,11 @@ public:
   /// \param QT is the clang QualType of the null pointer.
   llvm::Constant *getNullPointer(llvm::PointerType *T, QualType QT);
 
+  /// Set section attributes requested by "#pragma clang section"
+  ///  \param D is the declaration to read semantic attributes from.
+  ///  \param GO is the global object to set section attributes.
+  void setPragmaSectionAttributes(const Decl *D, llvm::GlobalObject *GO);
+
 private:
   llvm::Constant *GetOrCreateLLVMFunction(
   StringRef MangledName, llvm::Type *Ty, GlobalDecl D, bool ForVTable,

Modified: cfe/trunk/lib/Sema/Sema

[PATCH] D68410: [AttrDocs] document always_inline

2019-10-16 Thread Roman Lebedev via Phabricator via cfe-commits

lebedev.ri requested changes to this revision.
lebedev.ri added a comment.
This revision now requires changes to proceed.

I think partial (but not wrong!) docs is better than no docs whatsoever, so i'd 
be inclined to proceed with this.
I, too, not really convinced that actual explicit rules should be spelled out.
Some nits, LG otherwise to me.




Comment at: clang/include/clang/Basic/AttrDocs.td:4401
+disabled. Does not guarantee that inline substitution actually occurs.
+}];
+  let Heading = "always_inline";

jdoerfert wrote:
> It is more than that. This would imply that with optimizations enabled there 
> is no effect. I would mention that the inline heuristic is disabled and 
> inlining is always attempted, w/ or w/o optimizations.
This comment wasn't addressed.



Comment at: clang/include/clang/Basic/AttrDocs.td:4398
+  let Content = [{
+Inline heuristics are disabled and inlining is always attempted regardless of
+optimization level.

s/Inline/Inlining/


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68410



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

[PATCH] D68808: Tag CFI-generated data structures with "#pragma clang section" attributes.

2019-10-16 Thread Dmitry Mikulin via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rGe2692b3bc032: Tag CFI-generated data structures with 
"#pragma clang section" attributes. (authored by dmikulin).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68808

Files:
  clang/lib/CodeGen/CGExpr.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/CodeGen/CodeGenModule.h
  clang/lib/Sema/SemaDecl.cpp
  clang/test/CodeGen/cfi-pragma-section.c

Index: clang/test/CodeGen/cfi-pragma-section.c
===
--- /dev/null
+++ clang/test/CodeGen/cfi-pragma-section.c
@@ -0,0 +1,32 @@
+// Check that CFI-generated data structures are tagged with
+// "#pragma clang section" attributes
+
+// RUN: %clang_cc1 -triple x86_64-unknown-linux -fsanitize=cfi-icall \
+// RUN: -fno-sanitize-trap=cfi-icall -emit-llvm -o - %s | FileCheck %s
+
+// CHECK-DAG: attributes [[ATTR:#[0-9]+]]{{.*}}bss-section{{.*}}data-section{{.*}}rodata-section
+// CHECK-DAG: @.src = private unnamed_addr constant{{.*}}cfi-pragma-section.c{{.*}}[[ATTR]]
+// CHECK-DAG: @{{[0-9]+}} = private unnamed_addr constant{{.*}}int (int){{.*}}[[ATTR]]
+// CHECK-DAG: @{{[0-9]+}} = private unnamed_addr global{{.*}}@.src{{.*}}[[ATTR]]
+
+typedef int (*int_arg_fn)(int);
+
+static int int_arg1(int arg) {
+return 0;
+}
+
+static int int_arg2(int arg) {
+return 1;
+}
+
+int_arg_fn int_funcs[2] = {int_arg1, int_arg2};
+
+#pragma clang section bss = ".bss.mycfi"
+#pragma clang section data = ".data.mycfi"
+#pragma clang section rodata = ".rodata.mycfi"
+
+int main(int argc, const char *argv[]) {
+
+int idx = argv[1][0] - '0';
+return int_funcs[argc](idx);
+}
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -9062,6 +9062,25 @@
 Context, PragmaClangTextSection.SectionName,
 PragmaClangTextSection.PragmaLocation, AttributeCommonInfo::AS_Pragma));
 
+  if (D.isFunctionDefinition()) {
+if (PragmaClangBSSSection.Valid)
+  NewFD->addAttr(PragmaClangBSSSectionAttr::CreateImplicit(
+  Context, PragmaClangBSSSection.SectionName,
+  PragmaClangBSSSection.PragmaLocation));
+if (PragmaClangDataSection.Valid)
+  NewFD->addAttr(PragmaClangDataSectionAttr::CreateImplicit(
+  Context, PragmaClangDataSection.SectionName,
+  PragmaClangDataSection.PragmaLocation));
+if (PragmaClangRodataSection.Valid)
+  NewFD->addAttr(PragmaClangRodataSectionAttr::CreateImplicit(
+  Context, PragmaClangRodataSection.SectionName,
+  PragmaClangRodataSection.PragmaLocation));
+if (PragmaClangRelroSection.Valid)
+  NewFD->addAttr(PragmaClangRelroSectionAttr::CreateImplicit(
+  Context, PragmaClangRelroSection.SectionName,
+  PragmaClangRelroSection.PragmaLocation));
+  }
+
   // Apply an implicit SectionAttr if #pragma code_seg is active.
   if (CodeSegStack.CurrentValue && D.isFunctionDefinition() &&
   !NewFD->hasAttr()) {
Index: clang/lib/CodeGen/CodeGenModule.h
===
--- clang/lib/CodeGen/CodeGenModule.h
+++ clang/lib/CodeGen/CodeGenModule.h
@@ -1347,6 +1347,11 @@
   /// \param QT is the clang QualType of the null pointer.
   llvm::Constant *getNullPointer(llvm::PointerType *T, QualType QT);
 
+  /// Set section attributes requested by "#pragma clang section"
+  ///  \param D is the declaration to read semantic attributes from.
+  ///  \param GO is the global object to set section attributes.
+  void setPragmaSectionAttributes(const Decl *D, llvm::GlobalObject *GO);
+
 private:
   llvm::Constant *GetOrCreateLLVMFunction(
   StringRef MangledName, llvm::Type *Ty, GlobalDecl D, bool ForVTable,
Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -1699,11 +1699,8 @@
   return AddedAttr;
 }
 
-void CodeGenModule::setNonAliasAttributes(GlobalDecl GD,
-  llvm::GlobalObject *GO) {
-  const Decl *D = GD.getDecl();
-  SetCommonAttributes(GD, GO);
-
+void CodeGenModule::setPragmaSectionAttributes(const Decl *D,
+	   llvm::GlobalObject *GO) {
   if (D) {
 if (auto *GV = dyn_cast(GO)) {
   if (auto *SA = D->getAttr())
@@ -1721,6 +1718,26 @@
 if (!D->getAttr())
   F->addFnAttr("implicit-section-name", SA->getName());
 
+  if (auto *SA = D->getAttr())
+F->addFnAttr("bss-section", SA->getName());
+  if (auto *SA = D->getAttr())
+F->addFnAttr("data-section", SA->getName());
+  if (auto *SA = D->getAttr())
+F->addFnAttr("rodata-section", SA->getName());
+

r375026 - [OPENMP]Allow priority clause in combined task-based directives.

2019-10-16 Thread Alexey Bataev via cfe-commits

Author: abataev
Date: Wed Oct 16 11:09:37 2019
New Revision: 375026

URL: http://llvm.org/viewvc/llvm-project?rev=375026&view=rev
Log:
[OPENMP]Allow priority clause in combined task-based directives.

The expression of the priority clause must be captured in the combined
task-based directives, like 'parallel master taskloop' directive.

Modified:
cfe/trunk/include/clang/AST/OpenMPClause.h
cfe/trunk/include/clang/AST/RecursiveASTVisitor.h
cfe/trunk/lib/AST/OpenMPClause.cpp
cfe/trunk/lib/AST/StmtProfile.cpp
cfe/trunk/lib/Sema/SemaOpenMP.cpp
cfe/trunk/lib/Serialization/ASTReader.cpp
cfe/trunk/lib/Serialization/ASTWriter.cpp
cfe/trunk/test/OpenMP/parallel_master_taskloop_codegen.cpp

Modified: cfe/trunk/include/clang/AST/OpenMPClause.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/OpenMPClause.h?rev=375026&r1=375025&r2=375026&view=diff
==
--- cfe/trunk/include/clang/AST/OpenMPClause.h (original)
+++ cfe/trunk/include/clang/AST/OpenMPClause.h Wed Oct 16 11:09:37 2019
@@ -5206,7 +5206,7 @@ public:
 /// \endcode
 /// In this example directive '#pragma omp teams' has clause 'priority' with
 /// single expression 'n'.
-class OMPPriorityClause : public OMPClause {
+class OMPPriorityClause : public OMPClause, public OMPClauseWithPreInit {
   friend class OMPClauseReader;
 
   /// Location of '('.
@@ -5223,18 +5223,25 @@ class OMPPriorityClause : public OMPClau
 public:
   /// Build 'priority' clause.
   ///
-  /// \param E Expression associated with this clause.
+  /// \param Priority Expression associated with this clause.
+  /// \param HelperPriority Helper priority for the construct.
+  /// \param CaptureRegion Innermost OpenMP region where expressions in this
+  /// clause must be captured.
   /// \param StartLoc Starting location of the clause.
   /// \param LParenLoc Location of '('.
   /// \param EndLoc Ending location of the clause.
-  OMPPriorityClause(Expr *E, SourceLocation StartLoc, SourceLocation LParenLoc,
-SourceLocation EndLoc)
-  : OMPClause(OMPC_priority, StartLoc, EndLoc), LParenLoc(LParenLoc),
-Priority(E) {}
+  OMPPriorityClause(Expr *Priority, Stmt *HelperPriority,
+OpenMPDirectiveKind CaptureRegion, SourceLocation StartLoc,
+SourceLocation LParenLoc, SourceLocation EndLoc)
+  : OMPClause(OMPC_priority, StartLoc, EndLoc), OMPClauseWithPreInit(this),
+LParenLoc(LParenLoc), Priority(Priority) {
+setPreInitStmt(HelperPriority, CaptureRegion);
+  }
 
   /// Build an empty clause.
   OMPPriorityClause()
-  : OMPClause(OMPC_priority, SourceLocation(), SourceLocation()) {}
+  : OMPClause(OMPC_priority, SourceLocation(), SourceLocation()),
+OMPClauseWithPreInit(this) {}
 
   /// Sets the location of '('.
   void setLParenLoc(SourceLocation Loc) { LParenLoc = Loc; }
@@ -5254,11 +5261,10 @@ public:
 return const_child_range(&Priority, &Priority + 1);
   }
 
-  child_range used_children() {
-return child_range(child_iterator(), child_iterator());
-  }
+  child_range used_children();
   const_child_range used_children() const {
-return const_child_range(const_child_iterator(), const_child_iterator());
+auto Children = const_cast(this)->used_children();
+return const_child_range(Children.begin(), Children.end());
   }
 
   static bool classof(const OMPClause *T) {

Modified: cfe/trunk/include/clang/AST/RecursiveASTVisitor.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/RecursiveASTVisitor.h?rev=375026&r1=375025&r2=375026&view=diff
==
--- cfe/trunk/include/clang/AST/RecursiveASTVisitor.h (original)
+++ cfe/trunk/include/clang/AST/RecursiveASTVisitor.h Wed Oct 16 11:09:37 2019
@@ -3277,6 +3277,7 @@ bool RecursiveASTVisitor::Visit
 template 
 bool RecursiveASTVisitor::VisitOMPPriorityClause(
 OMPPriorityClause *C) {
+  TRY_TO(VisitOMPClauseWithPreInit(C));
   TRY_TO(TraverseStmt(C->getPriority()));
   return true;
 }

Modified: cfe/trunk/lib/AST/OpenMPClause.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/OpenMPClause.cpp?rev=375026&r1=375025&r2=375026&view=diff
==
--- cfe/trunk/lib/AST/OpenMPClause.cpp (original)
+++ cfe/trunk/lib/AST/OpenMPClause.cpp Wed Oct 16 11:09:37 2019
@@ -90,6 +90,8 @@ const OMPClauseWithPreInit *OMPClauseWit
 return static_cast(C);
   case OMPC_final:
 return static_cast(C);
+  case OMPC_priority:
+return static_cast(C);
   case OMPC_default:
   case OMPC_proc_bind:
   case OMPC_safelen:
@@ -117,7 +119,6 @@ const OMPClauseWithPreInit *OMPClauseWit
   case OMPC_threads:
   case OMPC_simd:
   case OMPC_map:
-  case OMPC_priority:
   case OMPC_nogroup:
   case OMPC_hint:
   case OMPC_defaultmap:
@@ -255,6 +256,12 @@ OMPClause::child

r375027 - Fix darwin-ld-lto test for some speical path

2019-10-16 Thread Steven Wu via cfe-commits

Author: steven_wu
Date: Wed Oct 16 11:12:41 2019
New Revision: 375027

URL: http://llvm.org/viewvc/llvm-project?rev=375027&view=rev
Log:
Fix darwin-ld-lto test for some speical path

Fix the test by not assuming the prefix path of the temp directory can
be matched by a regex.

rdar://problem/56259195

Modified:
cfe/trunk/test/Driver/darwin-ld-lto.c

Modified: cfe/trunk/test/Driver/darwin-ld-lto.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/darwin-ld-lto.c?rev=375027&r1=375026&r2=375027&view=diff
==
--- cfe/trunk/test/Driver/darwin-ld-lto.c (original)
+++ cfe/trunk/test/Driver/darwin-ld-lto.c Wed Oct 16 11:12:41 2019
@@ -23,8 +23,10 @@
 // RUN: %clang -target x86_64-apple-darwin10 %s -flto=full -### 2>&1 | \
 // RUN:   FileCheck -check-prefix=FULL_LTO_OBJECT_PATH %s
 // FULL_LTO_OBJECT_PATH: {{ld(.exe)?"}}
-// FULL_LTO_OBJECT_PATH-SAME: "-object_path_lto" 
"{{[a-zA-Z0-9_\/]+\/cc\-[a-zA-Z0-9_]+.o}}"
+// FULL_LTO_OBJECT_PATH-SAME: "-object_path_lto"
+// FULL_LTO_OBJECT_PATH-SAME: {{cc\-[a-zA-Z0-9_]+.o}}"
 // RUN: %clang -target x86_64-apple-darwin10 %s -flto=thin -### 2>&1 | \
 // RUN:   FileCheck -check-prefix=THIN_LTO_OBJECT_PATH %s
 // THIN_LTO_OBJECT_PATH: {{ld(.exe)?"}}
-// THIN_LTO_OBJECT_PATH-SAME: "-object_path_lto" 
"{{[a-zA-Z0-9_\/]+\/thinlto\-[a-zA-Z0-9_]+}}"
+// THIN_LTO_OBJECT_PATH-SAME: "-object_path_lto"
+// THIN_LTO_OBJECT_PATH-SAME: {{thinlto\-[a-zA-Z0-9_]+}}


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

[PATCH] D69060: [Sema][Typo Correction] Fix another infinite loop on ambiguity

2019-10-16 Thread David Goldman via Phabricator via cfe-commits

dgoldman created this revision.
dgoldman added a reviewer: rsmith.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

See also: D67515 

- For the given call expression we would end up repeatedly trying to transform 
the same expression over and over again

- Fix is to keep the old TransformCache when checking for ambiguity


Repository:
  rC Clang

https://reviews.llvm.org/D69060

Files:
  lib/Sema/SemaExprCXX.cpp
  test/Sema/typo-correction-ambiguity.c


Index: test/Sema/typo-correction-ambiguity.c
===
--- /dev/null
+++ test/Sema/typo-correction-ambiguity.c
@@ -0,0 +1,14 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+
+// Check the following typo correction behavior in C:
+// - no typos are diagnosed when a call expression has ambiguous (multiple) 
corrections
+
+int v_63;
+
+void v_2_0(int v_452, int v_454) {}
+
+int v_3_0() {
+   for (int v_345 = 0 ; v_63;)
+   v_2_0(v_195,  // expected-error {{use of undeclared identifier 'v_195'}}
+ v_231);  // expected-error {{use of undeclared identifier 
'v_231'}}
+}
Index: lib/Sema/SemaExprCXX.cpp
===
--- lib/Sema/SemaExprCXX.cpp
+++ lib/Sema/SemaExprCXX.cpp
@@ -7779,8 +7779,8 @@
 
 // If we found a valid result, double check to make sure it's not 
ambiguous.
 if (!IsAmbiguous && !Res.isInvalid() && !AmbiguousTypoExprs.empty()) {
-  auto SavedTransformCache = std::move(TransformCache);
-  TransformCache.clear();
+  auto SavedTransformCache = llvm::SmallDenseMap(TransformCache);
+
   // Ensure none of the TypoExprs have multiple typo correction candidates
   // with the same edit length that pass all the checks and filters.
   while (!AmbiguousTypoExprs.empty()) {


Index: test/Sema/typo-correction-ambiguity.c
===
--- /dev/null
+++ test/Sema/typo-correction-ambiguity.c
@@ -0,0 +1,14 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+
+// Check the following typo correction behavior in C:
+// - no typos are diagnosed when a call expression has ambiguous (multiple) corrections
+
+int v_63;
+
+void v_2_0(int v_452, int v_454) {}
+
+int v_3_0() {
+   for (int v_345 = 0 ; v_63;)
+   v_2_0(v_195,  // expected-error {{use of undeclared identifier 'v_195'}}
+ v_231);  // expected-error {{use of undeclared identifier 'v_231'}}
+}
Index: lib/Sema/SemaExprCXX.cpp
===
--- lib/Sema/SemaExprCXX.cpp
+++ lib/Sema/SemaExprCXX.cpp
@@ -7779,8 +7779,8 @@
 
 // If we found a valid result, double check to make sure it's not ambiguous.
 if (!IsAmbiguous && !Res.isInvalid() && !AmbiguousTypoExprs.empty()) {
-  auto SavedTransformCache = std::move(TransformCache);
-  TransformCache.clear();
+  auto SavedTransformCache = llvm::SmallDenseMap(TransformCache);
+
   // Ensure none of the TypoExprs have multiple typo correction candidates
   // with the same edit length that pass all the checks and filters.
   while (!AmbiguousTypoExprs.empty()) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D66712: [Driver] Enable ShadowCallStack, not SafeStack, by default on AArch64 Fuchsia

2019-10-16 Thread Roland McGrath via Phabricator via cfe-commits

mcgrathr added a comment.

It's time to land this now.  Can one of you commit it for me?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66712



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

[PATCH] D67545: [clang-tidy] Added DefaultOperatorNewCheck.

2019-10-16 Thread Roman Lebedev via Phabricator via cfe-commits

lebedev.ri requested changes to this revision.
lebedev.ri added a comment.
This revision now requires changes to proceed.

(outstanding unaddressed review notes)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67545



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

[PATCH] D66712: [Driver] Enable ShadowCallStack, not SafeStack, by default on AArch64 Fuchsia

2019-10-16 Thread Roland McGrath via Phabricator via cfe-commits

mcgrathr updated this revision to Diff 225273.
mcgrathr added a comment.

rebased


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66712

Files:
  clang/lib/Driver/ToolChains/Fuchsia.cpp
  clang/test/Driver/fuchsia.c


Index: clang/test/Driver/fuchsia.c
===
--- clang/test/Driver/fuchsia.c
+++ clang/test/Driver/fuchsia.c
@@ -13,7 +13,8 @@
 // CHECK: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
 // CHECK: "-isysroot" "[[SYSROOT:[^"]+]]"
 // CHECK: "-internal-externc-isystem" "[[SYSROOT]]{{/|}}include"
-// CHECK: "-fsanitize=safe-stack"
+// CHECK-AARCH64: "-fsanitize=shadow-call-stack"
+// CHECK-X86_64: "-fsanitize=safe-stack"
 // CHECK: "-stack-protector" "2"
 // CHECK: "-fno-common"
 // CHECK: {{.*}}ld.lld{{.*}}" "-z" "rodynamic" "-z" 
"separate-loadable-segments"
@@ -102,7 +103,7 @@
 // RUN: -fuse-ld=lld \
 // RUN: | FileCheck %s -check-prefix=CHECK-ASAN-AARCH64
 // CHECK-ASAN-AARCH64: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
-// CHECK-ASAN-AARCH64: "-fsanitize=address"
+// CHECK-ASAN-AARCH64: "-fsanitize=address,shadow-call-stack"
 // CHECK-ASAN-AARCH64: "-fsanitize-address-globals-dead-stripping"
 // CHECK-ASAN-AARCH64: "-dynamic-linker" "asan/ld.so.1"
 // CHECK-ASAN-AARCH64: 
"[[RESOURCE_DIR]]{{/|}}lib{{/|}}aarch64-fuchsia{{/|}}libclang_rt.asan.so"
@@ -134,7 +135,7 @@
 // RUN: -fuse-ld=lld \
 // RUN: | FileCheck %s -check-prefix=CHECK-FUZZER-AARCH64
 // CHECK-FUZZER-AARCH64: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
-// CHECK-FUZZER-AARCH64: "-fsanitize=fuzzer,fuzzer-no-link,safe-stack"
+// CHECK-FUZZER-AARCH64: "-fsanitize=fuzzer,fuzzer-no-link,shadow-call-stack"
 // CHECK-FUZZER-AARCH64: 
"[[RESOURCE_DIR]]{{/|}}lib{{/|}}aarch64-fuchsia{{/|}}libclang_rt.fuzzer.a"
 
 // RUN: %clang %s -### --target=x86_64-fuchsia \
@@ -153,7 +154,7 @@
 // RUN: -fuse-ld=lld \
 // RUN: | FileCheck %s -check-prefix=CHECK-SCUDO-AARCH64
 // CHECK-SCUDO-AARCH64: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
-// CHECK-SCUDO-AARCH64: "-fsanitize=safe-stack,scudo"
+// CHECK-SCUDO-AARCH64: "-fsanitize=shadow-call-stack,scudo"
 // CHECK-SCUDO-AARCH64: "-pie"
 // CHECK-SCUDO-AARCH64: 
"[[RESOURCE_DIR]]{{/|}}lib{{/|}}aarch64-fuchsia{{/|}}libclang_rt.scudo.so"
 
Index: clang/lib/Driver/ToolChains/Fuchsia.cpp
===
--- clang/lib/Driver/ToolChains/Fuchsia.cpp
+++ clang/lib/Driver/ToolChains/Fuchsia.cpp
@@ -343,5 +343,10 @@
 }
 
 SanitizerMask Fuchsia::getDefaultSanitizers() const {
-  return SanitizerKind::SafeStack;
+  SanitizerMask Res;
+  if (getTriple().getArch() == llvm::Triple::aarch64)
+Res |= SanitizerKind::ShadowCallStack;
+  else
+Res |= SanitizerKind::SafeStack;
+  return Res;
 }


Index: clang/test/Driver/fuchsia.c
===
--- clang/test/Driver/fuchsia.c
+++ clang/test/Driver/fuchsia.c
@@ -13,7 +13,8 @@
 // CHECK: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
 // CHECK: "-isysroot" "[[SYSROOT:[^"]+]]"
 // CHECK: "-internal-externc-isystem" "[[SYSROOT]]{{/|}}include"
-// CHECK: "-fsanitize=safe-stack"
+// CHECK-AARCH64: "-fsanitize=shadow-call-stack"
+// CHECK-X86_64: "-fsanitize=safe-stack"
 // CHECK: "-stack-protector" "2"
 // CHECK: "-fno-common"
 // CHECK: {{.*}}ld.lld{{.*}}" "-z" "rodynamic" "-z" "separate-loadable-segments"
@@ -102,7 +103,7 @@
 // RUN: -fuse-ld=lld \
 // RUN: | FileCheck %s -check-prefix=CHECK-ASAN-AARCH64
 // CHECK-ASAN-AARCH64: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
-// CHECK-ASAN-AARCH64: "-fsanitize=address"
+// CHECK-ASAN-AARCH64: "-fsanitize=address,shadow-call-stack"
 // CHECK-ASAN-AARCH64: "-fsanitize-address-globals-dead-stripping"
 // CHECK-ASAN-AARCH64: "-dynamic-linker" "asan/ld.so.1"
 // CHECK-ASAN-AARCH64: "[[RESOURCE_DIR]]{{/|}}lib{{/|}}aarch64-fuchsia{{/|}}libclang_rt.asan.so"
@@ -134,7 +135,7 @@
 // RUN: -fuse-ld=lld \
 // RUN: | FileCheck %s -check-prefix=CHECK-FUZZER-AARCH64
 // CHECK-FUZZER-AARCH64: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
-// CHECK-FUZZER-AARCH64: "-fsanitize=fuzzer,fuzzer-no-link,safe-stack"
+// CHECK-FUZZER-AARCH64: "-fsanitize=fuzzer,fuzzer-no-link,shadow-call-stack"
 // CHECK-FUZZER-AARCH64: "[[RESOURCE_DIR]]{{/|}}lib{{/|}}aarch64-fuchsia{{/|}}libclang_rt.fuzzer.a"
 
 // RUN: %clang %s -### --target=x86_64-fuchsia \
@@ -153,7 +154,7 @@
 // RUN: -fuse-ld=lld \
 // RUN: | FileCheck %s -check-prefix=CHECK-SCUDO-AARCH64
 // CHECK-SCUDO-AARCH64: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
-// CHECK-SCUDO-AARCH64: "-fsanitize=safe-stack,scudo"
+// CHECK-SCUDO-AARCH64: "-fsanitize=shadow-call-stack,scudo"
 // CHECK-SCUDO-AARCH64: "-pie"
 // CHECK-SCUDO-AARCH64: "[[RESOURCE_DIR]]{{/|}}lib{{/|}}aarch64-fuchsia{{/|}}libclang_rt.scudo.so"
 
Index: clang/lib/Driver/ToolChains/Fuchsia.cpp
==

[PATCH] D68876: [libTooling] Put all Transformer declarations in a single namespace.

2019-10-16 Thread Adrian Prantl via Phabricator via cfe-commits

aprantl added a comment.

It looks like it's still failing: 
http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/2649/console


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68876



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

[PATCH] D69062: Resolve LWG issue 2426

2019-10-16 Thread Zoe Carver via Phabricator via cfe-commits

zoecarver created this revision.
zoecarver added reviewers: mclow.lists, EricWF, ldionne, rsmith.
Herald added subscribers: libcxx-commits, cfe-commits, dexonsmith, christof.
Herald added projects: clang, libc++.

This patch checks that `expected` is loaded before it is used. Libc++ already 
does this.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D69062

Files:
  clang/test/CodeGen/atomic-ops.c
  libcxx/www/cxx1z_status.html


Index: libcxx/www/cxx1z_status.html
===
--- libcxx/www/cxx1z_status.html
+++ libcxx/www/cxx1z_status.html
@@ -318,7 +318,7 @@
https://wg21.link/LWG2328";>2328Rvalue 
stream extraction should use perfect 
forwardingOuluComplete
https://wg21.link/LWG2393";>2393std::function's Callable 
definition is brokenOuluComplete
https://wg21.link/LWG2422";>2422std::numeric_limits::is_modulo
 description: "most machines" errataOuluComplete
-   https://wg21.link/LWG2426";>2426Issue 
about compare_exchangeOulu
+   https://wg21.link/LWG2426";>2426Issue 
about compare_exchangeOuluComplete
https://wg21.link/LWG2436";>2436Comparators for associative 
containers should always be 
CopyConstructibleOuluComplete
https://wg21.link/LWG2441";>2441Exact-width atomic typedefs 
should be providedOuluComplete
https://wg21.link/LWG2451";>2451[fund.ts.v2] optional should 
'forward' T's implicit conversionsOuluNothing to do
Index: clang/test/CodeGen/atomic-ops.c
===
--- clang/test/CodeGen/atomic-ops.c
+++ clang/test/CodeGen/atomic-ops.c
@@ -466,6 +466,8 @@
   // CHECK: cmpxchg i32* {{%[0-9A-Za-z._]+}}, i32 {{%[0-9A-Za-z._]+}}, i32 
{{%[0-9A-Za-z_.]+}} acquire monotonic
 
   __c11_atomic_compare_exchange_weak(ptr, ptr2, 43, memory_order_seq_cst, 
memory_order_acquire);
+  // CHECK: load i32, i32* {{%[0-9A-Za-z._]+}}, align 4
+  // CHECK: load i32, i32* {{%[0-9A-Za-z._]+}}, align 4
   // CHECK: cmpxchg weak i32* {{%[0-9A-Za-z._]+}}, i32 {{%[0-9A-Za-z._]+}}, 
i32 {{%[0-9A-Za-z_.]+}} seq_cst acquire
 
   // Unknown ordering: conservatively pick strongest valid option (for now!).


Index: libcxx/www/cxx1z_status.html
===
--- libcxx/www/cxx1z_status.html
+++ libcxx/www/cxx1z_status.html
@@ -318,7 +318,7 @@
 	https://wg21.link/LWG2328";>2328Rvalue stream extraction should use perfect forwardingOuluComplete
 	https://wg21.link/LWG2393";>2393std::function's Callable definition is brokenOuluComplete
 	https://wg21.link/LWG2422";>2422std::numeric_limits::is_modulo description: "most machines" errataOuluComplete
-	https://wg21.link/LWG2426";>2426Issue about compare_exchangeOulu
+	https://wg21.link/LWG2426";>2426Issue about compare_exchangeOuluComplete
 	https://wg21.link/LWG2436";>2436Comparators for associative containers should always be CopyConstructibleOuluComplete
 	https://wg21.link/LWG2441";>2441Exact-width atomic typedefs should be providedOuluComplete
 	https://wg21.link/LWG2451";>2451[fund.ts.v2] optional should 'forward' T's implicit conversionsOuluNothing to do
Index: clang/test/CodeGen/atomic-ops.c
===
--- clang/test/CodeGen/atomic-ops.c
+++ clang/test/CodeGen/atomic-ops.c
@@ -466,6 +466,8 @@
   // CHECK: cmpxchg i32* {{%[0-9A-Za-z._]+}}, i32 {{%[0-9A-Za-z._]+}}, i32 {{%[0-9A-Za-z_.]+}} acquire monotonic
 
   __c11_atomic_compare_exchange_weak(ptr, ptr2, 43, memory_order_seq_cst, memory_order_acquire);
+  // CHECK: load i32, i32* {{%[0-9A-Za-z._]+}}, align 4
+  // CHECK: load i32, i32* {{%[0-9A-Za-z._]+}}, align 4
   // CHECK: cmpxchg weak i32* {{%[0-9A-Za-z._]+}}, i32 {{%[0-9A-Za-z._]+}}, i32 {{%[0-9A-Za-z_.]+}} seq_cst acquire
 
   // Unknown ordering: conservatively pick strongest valid option (for now!).
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D69062: Resolve LWG issue 2426

2019-10-16 Thread Louis Dionne via Phabricator via cfe-commits

ldionne requested changes to this revision.
ldionne added a comment.
This revision now requires changes to proceed.

If we want to mark the LWG issue as being resolved for libc++, I think the test 
should be moved to the libc++ test suite. Otherwise, we're only assessing that 
libc++ implements LWG2426 __on Clang__.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69062



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

[PATCH] D68876: [libTooling] Put all Transformer declarations in a single namespace.

2019-10-16 Thread Yitzhak Mandelbaum via Phabricator via cfe-commits

ymandel added a comment.

In D68876#1711576 , @aprantl wrote:

> It looks like it's still failing: 
> http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/2649/console


That line was fixed in the revision I mentioned: 
https://reviews.llvm.org/rL375003
Could it be that the bot hasn't picked up the revision yet?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68876



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

[PATCH] D68914: [clang-format] Remove duplciate code from Invalid BOM detection

2019-10-16 Thread Duncan P. N. Exon Smith via Phabricator via cfe-commits

dexonsmith added a comment.

In D68914#1710407 , @owenpan wrote:

> I did a quick search of the LLVM code base and found dozens of `const 
> StringRef &`, including the `Twine` API 
> .

`Twine` is "special", don't be influenced by that.  Most of the others are 
probably mistakes.  It's idiomatic to pass `StringRef` by value.

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

https://reviews.llvm.org/D68914

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

r375031 - Replace platform-dependent `stat` with `llvm::sys::fs::status`. NFC intended.

2019-10-16 Thread Volodymyr Sapsai via cfe-commits

Author: vsapsai
Date: Wed Oct 16 12:12:34 2019
New Revision: 375031

URL: http://llvm.org/viewvc/llvm-project?rev=375031&view=rev
Log:
Replace platform-dependent `stat` with `llvm::sys::fs::status`. NFC intended.

Reviewers: bruno, sammccall

Reviewed By: sammccall

Subscribers: jkorous, dexonsmith, arphaman, ributzka, cfe-commits

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

Modified:
cfe/trunk/lib/Frontend/CompilerInstance.cpp
cfe/trunk/tools/libclang/CIndexCodeCompletion.cpp

Modified: cfe/trunk/lib/Frontend/CompilerInstance.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/CompilerInstance.cpp?rev=375031&r1=375030&r2=375031&view=diff
==
--- cfe/trunk/lib/Frontend/CompilerInstance.cpp (original)
+++ cfe/trunk/lib/Frontend/CompilerInstance.cpp Wed Oct 16 12:12:34 2019
@@ -50,8 +50,6 @@
 #include "llvm/Support/TimeProfiler.h"
 #include "llvm/Support/Timer.h"
 #include "llvm/Support/raw_ostream.h"
-#include 
-#include 
 #include 
 #include 
 
@@ -1389,16 +1387,16 @@ static void writeTimestampFile(StringRef
 /// Prune the module cache of modules that haven't been accessed in
 /// a long time.
 static void pruneModuleCache(const HeaderSearchOptions &HSOpts) {
-  struct stat StatBuf;
+  llvm::sys::fs::file_status StatBuf;
   llvm::SmallString<128> TimestampFile;
   TimestampFile = HSOpts.ModuleCachePath;
   assert(!TimestampFile.empty());
   llvm::sys::path::append(TimestampFile, "modules.timestamp");
 
   // Try to stat() the timestamp file.
-  if (::stat(TimestampFile.c_str(), &StatBuf)) {
+  if (std::error_code EC = llvm::sys::fs::status(TimestampFile, StatBuf)) {
 // If the timestamp file wasn't there, create one now.
-if (errno == ENOENT) {
+if (EC == std::errc::no_such_file_or_directory) {
   writeTimestampFile(TimestampFile);
 }
 return;
@@ -1406,7 +1404,8 @@ static void pruneModuleCache(const Heade
 
   // Check whether the time stamp is older than our pruning interval.
   // If not, do nothing.
-  time_t TimeStampModTime = StatBuf.st_mtime;
+  time_t TimeStampModTime =
+  llvm::sys::toTimeT(StatBuf.getLastModificationTime());
   time_t CurrentTime = time(nullptr);
   if (CurrentTime - TimeStampModTime <= 
time_t(HSOpts.ModuleCachePruneInterval))
 return;
@@ -1438,11 +1437,11 @@ static void pruneModuleCache(const Heade
 
   // Look at this file. If we can't stat it, there's nothing interesting
   // there.
-  if (::stat(File->path().c_str(), &StatBuf))
+  if (llvm::sys::fs::status(File->path(), StatBuf))
 continue;
 
   // If the file has been used recently enough, leave it there.
-  time_t FileAccessTime = StatBuf.st_atime;
+  time_t FileAccessTime = 
llvm::sys::toTimeT(StatBuf.getLastAccessedTime());
   if (CurrentTime - FileAccessTime <=
   time_t(HSOpts.ModuleCachePruneAfter)) {
 continue;

Modified: cfe/trunk/tools/libclang/CIndexCodeCompletion.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/libclang/CIndexCodeCompletion.cpp?rev=375031&r1=375030&r2=375031&view=diff
==
--- cfe/trunk/tools/libclang/CIndexCodeCompletion.cpp (original)
+++ cfe/trunk/tools/libclang/CIndexCodeCompletion.cpp Wed Oct 16 12:12:34 2019
@@ -803,8 +803,8 @@ clang_codeCompleteAt_Impl(CXTranslationU
   os << arg << ".pth";
 }
 pchName.push_back('\0');
-struct stat stat_results;
-if (stat(pchName.str().c_str(), &stat_results) == 0)
+llvm::sys::fs::file_status stat_results;
+if (!llvm::sys::fs::status(pchName, stat_results))
   usesPCH = true;
 continue;
   }


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

[PATCH] D69011: Replace platform-dependent `stat` with `llvm::sys::fs::status`. NFC intended.

2019-10-16 Thread Volodymyr Sapsai via Phabricator via cfe-commits

vsapsai added a comment.

Thanks for the review! If `fs::status` behaviour is sufficiently different on 
Windows, it is worth fixing because I believe majority of non-Windows 
developers expect them to work in the same way.


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

https://reviews.llvm.org/D69011



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

[PATCH] D69011: Replace platform-dependent `stat` with `llvm::sys::fs::status`. NFC intended.

2019-10-16 Thread Volodymyr Sapsai via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rG930ada91ce8f: Replace platform-dependent `stat` with 
`llvm::sys::fs::status`. NFC intended. (authored by vsapsai).
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69011

Files:
  clang/lib/Frontend/CompilerInstance.cpp
  clang/tools/libclang/CIndexCodeCompletion.cpp


Index: clang/tools/libclang/CIndexCodeCompletion.cpp
===
--- clang/tools/libclang/CIndexCodeCompletion.cpp
+++ clang/tools/libclang/CIndexCodeCompletion.cpp
@@ -803,8 +803,8 @@
   os << arg << ".pth";
 }
 pchName.push_back('\0');
-struct stat stat_results;
-if (stat(pchName.str().c_str(), &stat_results) == 0)
+llvm::sys::fs::file_status stat_results;
+if (!llvm::sys::fs::status(pchName, stat_results))
   usesPCH = true;
 continue;
   }
Index: clang/lib/Frontend/CompilerInstance.cpp
===
--- clang/lib/Frontend/CompilerInstance.cpp
+++ clang/lib/Frontend/CompilerInstance.cpp
@@ -50,8 +50,6 @@
 #include "llvm/Support/TimeProfiler.h"
 #include "llvm/Support/Timer.h"
 #include "llvm/Support/raw_ostream.h"
-#include 
-#include 
 #include 
 #include 
 
@@ -1389,16 +1387,16 @@
 /// Prune the module cache of modules that haven't been accessed in
 /// a long time.
 static void pruneModuleCache(const HeaderSearchOptions &HSOpts) {
-  struct stat StatBuf;
+  llvm::sys::fs::file_status StatBuf;
   llvm::SmallString<128> TimestampFile;
   TimestampFile = HSOpts.ModuleCachePath;
   assert(!TimestampFile.empty());
   llvm::sys::path::append(TimestampFile, "modules.timestamp");
 
   // Try to stat() the timestamp file.
-  if (::stat(TimestampFile.c_str(), &StatBuf)) {
+  if (std::error_code EC = llvm::sys::fs::status(TimestampFile, StatBuf)) {
 // If the timestamp file wasn't there, create one now.
-if (errno == ENOENT) {
+if (EC == std::errc::no_such_file_or_directory) {
   writeTimestampFile(TimestampFile);
 }
 return;
@@ -1406,7 +1404,8 @@
 
   // Check whether the time stamp is older than our pruning interval.
   // If not, do nothing.
-  time_t TimeStampModTime = StatBuf.st_mtime;
+  time_t TimeStampModTime =
+  llvm::sys::toTimeT(StatBuf.getLastModificationTime());
   time_t CurrentTime = time(nullptr);
   if (CurrentTime - TimeStampModTime <= 
time_t(HSOpts.ModuleCachePruneInterval))
 return;
@@ -1438,11 +1437,11 @@
 
   // Look at this file. If we can't stat it, there's nothing interesting
   // there.
-  if (::stat(File->path().c_str(), &StatBuf))
+  if (llvm::sys::fs::status(File->path(), StatBuf))
 continue;
 
   // If the file has been used recently enough, leave it there.
-  time_t FileAccessTime = StatBuf.st_atime;
+  time_t FileAccessTime = 
llvm::sys::toTimeT(StatBuf.getLastAccessedTime());
   if (CurrentTime - FileAccessTime <=
   time_t(HSOpts.ModuleCachePruneAfter)) {
 continue;


Index: clang/tools/libclang/CIndexCodeCompletion.cpp
===
--- clang/tools/libclang/CIndexCodeCompletion.cpp
+++ clang/tools/libclang/CIndexCodeCompletion.cpp
@@ -803,8 +803,8 @@
   os << arg << ".pth";
 }
 pchName.push_back('\0');
-struct stat stat_results;
-if (stat(pchName.str().c_str(), &stat_results) == 0)
+llvm::sys::fs::file_status stat_results;
+if (!llvm::sys::fs::status(pchName, stat_results))
   usesPCH = true;
 continue;
   }
Index: clang/lib/Frontend/CompilerInstance.cpp
===
--- clang/lib/Frontend/CompilerInstance.cpp
+++ clang/lib/Frontend/CompilerInstance.cpp
@@ -50,8 +50,6 @@
 #include "llvm/Support/TimeProfiler.h"
 #include "llvm/Support/Timer.h"
 #include "llvm/Support/raw_ostream.h"
-#include 
-#include 
 #include 
 #include 
 
@@ -1389,16 +1387,16 @@
 /// Prune the module cache of modules that haven't been accessed in
 /// a long time.
 static void pruneModuleCache(const HeaderSearchOptions &HSOpts) {
-  struct stat StatBuf;
+  llvm::sys::fs::file_status StatBuf;
   llvm::SmallString<128> TimestampFile;
   TimestampFile = HSOpts.ModuleCachePath;
   assert(!TimestampFile.empty());
   llvm::sys::path::append(TimestampFile, "modules.timestamp");
 
   // Try to stat() the timestamp file.
-  if (::stat(TimestampFile.c_str(), &StatBuf)) {
+  if (std::error_code EC = llvm::sys::fs::status(TimestampFile, StatBuf)) {
 // If the timestamp file wasn't there, create one now.
-if (errno == ENOENT) {
+if (EC == std::errc::no_such_file_or_directory) {
   writeTimestampFile(TimestampFile);
 }
 return;
@@ -1406,7 +1404,8 @@
 
   // Check whether

[PATCH] D47111: : Implement monotonic_buffer_resource.

2019-10-16 Thread Arthur O'Dwyer via Phabricator via cfe-commits

Quuxplusone marked 11 inline comments as done.
Quuxplusone added inline comments.



Comment at: include/experimental/memory_resource:427
+static _LIBCPP_CONSTEXPR const size_t __default_buffer_capacity = 1024;
+static _LIBCPP_CONSTEXPR const size_t __default_buffer_alignment = 16;
+

strager wrote:
> Nit: Why isn't `__default_buffer_alignment` set to `alignof(max_align_t)` 
> (which I think is 16)? I think `alignof(max_align_t)` is a good, portable 
> default.
Will users be more upset if `__default_buffer_alignment` is 16-instead-of-`???` 
on exotic platform `???`; or more upset if `__default_buffer_alignment` is 
//usually// 16 but then sometimes is `???`-instead-of-16 on exotic platforms? I 
tend to think that "usually 16, sometimes something else" is worse behavior 
software-engineering-wise than "always 16, even when something else might 
arguably be better on exotic platform `???`."



Comment at: include/experimental/memory_resource:431-432
+__chunk_header *__next_;
+char *__start_;
+char *__cur_;
+size_t __align_;

strager wrote:
> Nit: Would it make sense to use `std::byte` instead of `char`?
IMHO "strong no"; `char` is the standard core-language type that takes up one 
byte. `std::byte` is an enum type that we'd have to drag in from a header 
(cost), and otherwise behaves just like `char` (no benefit). But it's certainly 
a non-functional nit and I would not put up a fight if libc++ wanted it that 
way. :)



Comment at: include/experimental/memory_resource:433
+char *__cur_;
+size_t __align_;
+size_t __allocation_size() {

strager wrote:
> > Eric suggests replacing size_t __align_ with uint8_t __log2_align_. I'm 
> > amenable to this idea, but I'd want to know what's the best way to compute 
> > the log2 of a user-supplied number.
> 
> Perhaps `std::log2p1` could help: 
> https://en.cppreference.com/w/cpp/numeric/log2p1
Yes, but that's C++2a; I imagine some fiddliness would be needed to use it in 
C++17 library code (which in turn is actually compiled as C++11 or '14, I 
forget).



Comment at: 
test/libcxx/experimental/memory/memory.resource.monotonic.buffer/monotonic.buffer.mem/allocate_in_geometric_progression.pass.cpp:32
+assert(globalMemCounter.checkOutstandingNewEq(0));
+}
+

strager wrote:
> Nit: This test is named allocate_in_geometric_progression. I don't see any 
> multiplication or anything happening in this test case. Did you mean to call 
> this test something else, like release_deletes_upstream_memory?
Prior to the resolution of [LWG 
3120](https://cplusplus.github.io/LWG/issue3120), this test had tested 
something else. I guess now it //should// be more like 
"release_resets_initial_buffer.pass.cpp".



Comment at: 
test/std/experimental/memory/memory.resource.monotonic.buffer/monotonic.buffer.mem/allocate_deallocate.pass.cpp:28
+std::experimental::pmr::monotonic_buffer_resource 
mono1(std::experimental::pmr::new_delete_resource());
+std::experimental::pmr::memory_resource & r1 = mono1;
+

strager wrote:
> Nit: What is the purpose of the `r1` variable? Why not use `mono1` everywhere 
> instead (and rename `mono1` to `r1` if you like `r1` better than `mono1` as a 
> name)?
`r1` has a different static type. For example, here it's testing that 
`r1.allocate(50)` actually makes a virtual call to 
`monotonic_buffer_resource::do_allocate`. But I guess it doesn't really matter; 
I could use `mono1` for everything just as well.



Comment at: 
test/std/experimental/memory/memory.resource.monotonic.buffer/monotonic.buffer.mem/allocate_exception_safety.pass.cpp:48-49
+void *res = r1.allocate(64, 16);
+assert(res == buffer);
+assert(globalMemCounter.checkNewCalledEq(0));
+

strager wrote:
> Nit: These assertions look unrelated to exception safety to me. (The test is 
> named allocate_exception_safety.) I'd delete these assertions.
Depends on your test-overfitting philosophy. These assertions are still 
expected to pass 100% of the time — if they fail, then something is definitely 
wrong. And they're cheap to execute. So IMHO they might as well be there, as 
"self-documenting code."



Comment at: 
test/std/experimental/memory/memory.resource.monotonic.buffer/monotonic.buffer.mem/allocate_exception_safety.pass.cpp:67-68
+
+upstream.which = std::experimental::pmr::new_delete_resource();
+res = r1.allocate(last_new_size, 16);
+assert(res != buffer);

strager wrote:
> Question about the intended behavior of `monotonic_buffer_resource`:
> 
> If line 68 instead allocated 1 byte, and the byte could fit in the original 
> heap allocation (line 51), should `monotonic_buffer_resource` return a byte 
> from that original resource? In other words, should the following t

[PATCH] D68818: [hip][cuda] Fix the extended lambda name mangling issue.

2019-10-16 Thread Richard Smith - zygoloid via Phabricator via cfe-commits

rsmith added a comment.

Broadly, I think it's reasonable to number additional lambda expressions in 
CUDA compilations. However:

- This is (in theory) an ABI break on the host side, as it changes the lambda 
numbering in inline functions and function templates and the like. That could 
be mitigated by using a different numbering sequence for the lambdas that are 
only numbered for this reason.
- Depending on whether the call operator is a device function is unstable. If I 
understand the CUDA rules correctly, then in practice, because `constexpr` 
functions are implicitly `host device`, all lambdas will get numbered in CUDA 
on C++14 onwards but not in CUDA on C++11, and we generally want those modes to 
be ABI-compatible. I'd suggest you simplify and stabilize this by simply 
numbering all lambdas in CUDA mode.




Comment at: clang/lib/Sema/SemaLambda.cpp:477
+  // mangled name. But, the mangler needs informing those re-numbered lambdas
+  // still have `internal` linkage.
+  if (getLangOpts().CUDA && Method->hasAttr()) {

What happens if there are other enclosing constructs that would give the lambda 
internal linkage (eg, an anonymous namespace or static function that might 
collide with one in another translation unit, or a declaration involving a type 
with internal linkage)? Presumably you can still suffer from mangling 
collisions in those cases, at least if you link together multiple translation 
units containing device code. Do we need (something like) unique identifiers 
for device code TUs to use in manglings of ostensibly internal linkage entities?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68818



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

[PATCH] D68117: [DWARF-5] Support for C++11 defaulted, deleted member functions.

2019-10-16 Thread David Blaikie via Phabricator via cfe-commits

dblaikie added a comment.

In D68117#1711154 , @probinson wrote:

> In D68117#1710295 , @dblaikie wrote:
>
> > I think the existing feature's perhaps a bit misspecified - because where 
> > you put the DEFAULTED_{in_class,out_of_class} would communicate that 
> > without needing the two values - if you put it on an out of line function 
> > definition, it's defaulted out of line, if you put it on the in-class 
> > declaration then it's defaulted inline.
> >
> > But spec'd the way it is, if we want to implement this at all/if there's 
> > some actual user need (admittedly the noreturn attribute has gone in 
> > recently without a discussion of usage... so I'm not the only gatekeeper 
> > here & other people have other opinions, and that's OK - if someone 
> > (@probinson @aprantl etc) want to tell me I'm being unreasonable here & we 
> > should just put it in - it's only a bit here or there & not likely to make 
> > a huge difference to DWARF size & possibly enable some scenarios we haven't 
> > imagined yet and avoid the chicken-and-egg problem for the future 
> > implementer of such features, that's OK) - I'd essentially implement it 
> > that way. Put DEFAULTED_out_of_class on the member function definition DIE 
> > if it's defaulted there, and put DEFAULTED_in_class on the declaration DIE 
> > if it's defaulted there.
> >
> > And I'd probably only spend one bit of flags on this, if possible - "not 
> > defaulted (0/assumed for all subprograms) or defaulted (1)" and translate 
> > it into one of the two values (in_class or out_of_class) in the backend 
> > based on which subprogram DIE it's attached to.
>
>
> That seems reasonable too.  Of course if we're already spending a bit on 
> Deleted, and the same subprogram can't be both Deleted and Defaulted, it 
> costs no extra DISP bits to represent the 4 cases (defaulted-in-class, 
> defaulted-out-of-class, deleted, none-of-the-above).


Understood - though I think it's probably technically better to only store 
defaulted on/off to remove possible incorrect representations at the IR level 
at least:

Since out of line defaulted can't be reliably provided on the in-class 
declaration of the special member, it'd be unreliable to put it on that 
declaration even if one translation unit did see the out of line definition. 
And it'd be questionable to put it on the out of line definition if it's 
defaulted inline? (though I guess one could argue that would be consistent - 
always attaching it to the definition, never the declaration?)

But I still come back to: Why do we/anyone want this? Is anyone planning on 
using this information for any purpose? DWARF doesn't require us to emit 
everything - it just says we can if it's useful.

> @SouraVX I would say we should never emit DEFAULTED_no.  If the compiler 
> organized its internal data differently, and had a canned abbreviation for 
> ctors/dtors that included DW_AT_defaulted, then we'd need to fill that in; 
> but that's not how LLVM handles DWARF, it creates abbreviations on demand.  
> So, doing nothing in the none-of-the-above case would be best here.
> 
> (@dblaikie Aside regarding noreturn, the original DWARF proposal was for a 
> debugger wanting to know a given function will not return.

I'd still be curious to know which consumer, if they're still interested, what 
feature they're trying to build with it, if they're using Clang/LLVM's output, 
etc.

> As a flag, in the DWARF it costs an extra abbrev entry but no space in 
> .debug_info.  Cheap enough for me.)

Oh, sure - I don't think the output cost is high here or there - but it's more 
feature surface area, the time spent designing, code reviewing, supporting, 
etc, another place for bugs, etc. So I'd generally like to have some 
justification beyond "the spec says we can" - ideally, I'd like a DWARF 
consumer that's actively trying to build a feature that they can't without this 
new information.


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

https://reviews.llvm.org/D68117



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

[clang-tools-extra] r375039 - [clangd] Add the missing dependency on `clangLex`.

2019-10-16 Thread Michael Liao via cfe-commits

Author: hliao
Date: Wed Oct 16 13:22:54 2019
New Revision: 375039

URL: http://llvm.org/viewvc/llvm-project?rev=375039&view=rev
Log:
[clangd] Add the missing dependency on `clangLex`.

Modified:
clang-tools-extra/trunk/clangd/refactor/tweaks/CMakeLists.txt
clang-tools-extra/trunk/clangd/tool/CMakeLists.txt

Modified: clang-tools-extra/trunk/clangd/refactor/tweaks/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/refactor/tweaks/CMakeLists.txt?rev=375039&r1=375038&r2=375039&view=diff
==
--- clang-tools-extra/trunk/clangd/refactor/tweaks/CMakeLists.txt (original)
+++ clang-tools-extra/trunk/clangd/refactor/tweaks/CMakeLists.txt Wed Oct 16 
13:22:54 2019
@@ -26,6 +26,7 @@ add_clang_library(clangDaemonTweaks OBJE
   clangAST
   clangBasic
   clangDaemon
+  clangLex
   clangToolingCore
   clangToolingRefactoring
   clangToolingSyntax

Modified: clang-tools-extra/trunk/clangd/tool/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/tool/CMakeLists.txt?rev=375039&r1=375038&r2=375039&view=diff
==
--- clang-tools-extra/trunk/clangd/tool/CMakeLists.txt (original)
+++ clang-tools-extra/trunk/clangd/tool/CMakeLists.txt Wed Oct 16 13:22:54 2019
@@ -21,6 +21,7 @@ clang_target_link_libraries(clangd
   clangBasic
   clangFormat
   clangFrontend
+  clangLex
   clangSema
   clangTooling
   clangToolingCore


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

[PATCH] D68818: [hip][cuda] Fix the extended lambda name mangling issue.

2019-10-16 Thread Michael Liao via Phabricator via cfe-commits

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

In D68818#1711698 , @rsmith wrote:

> Broadly, I think it's reasonable to number additional lambda expressions in 
> CUDA compilations. However:
>
> - This is (in theory) an ABI break on the host side, as it changes the lambda 
> numbering in inline functions and function templates and the like. That could 
> be mitigated by using a different numbering sequence for the lambdas that are 
> only numbered for this reason.
> - Depending on whether the call operator is a device function is unstable. If 
> I understand the CUDA rules correctly, then in practice, because `constexpr` 
> functions are implicitly `host device`, all lambdas will get numbered in CUDA 
> on C++14 onwards but not in CUDA on C++11, and we generally want those modes 
> to be ABI-compatible. I'd suggest you simplify and stabilize this by simply 
> numbering all lambdas in CUDA mode.


I vote for the numbering of all lambdas in the CUDA mode once addressed in 
(D63164  as long as we decouple the numbering 
from the linkage. As long as all lambdas are numbered, the first one is also 
mitigated. I will prepare the changes forcing all lambdas to be numbered under 
CUDA/HIP mode.




Comment at: clang/lib/Sema/SemaLambda.cpp:477
+  // mangled name. But, the mangler needs informing those re-numbered lambdas
+  // still have `internal` linkage.
+  if (getLangOpts().CUDA && Method->hasAttr()) {

rsmith wrote:
> What happens if there are other enclosing constructs that would give the 
> lambda internal linkage (eg, an anonymous namespace or static function that 
> might collide with one in another translation unit, or a declaration 
> involving a type with internal linkage)? Presumably you can still suffer from 
> mangling collisions in those cases, at least if you link together multiple 
> translation units containing device code. Do we need (something like) unique 
> identifiers for device code TUs to use in manglings of ostensibly internal 
> linkage entities?
Those unnamed ones will be addressed in late patches as, currently, we only 
have lambda numbering issues from real workloads. I am preparing changes to 
address other unnamed types, namespaces, and etc.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68818



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

[PATCH] D53768: Add VerboseOutputStream to CompilerInstance

2019-10-16 Thread Matt Arsenault via Phabricator via cfe-commits

arsenm accepted this revision.
arsenm added a comment.
This revision is now accepted and ready to land.
Herald added a subscriber: wdng.

LGTM


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

https://reviews.llvm.org/D53768



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

[PATCH] D64943: [Clang][OpenMP offload] Eliminate use of OpenMP linker script

2019-10-16 Thread Sergey Dmitriev via Phabricator via cfe-commits

sdmitriev abandoned this revision.
sdmitriev added a comment.

All three parts have been committed, so I am abandoning the original patch.


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

https://reviews.llvm.org/D64943



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

[PATCH] D31130: B32239 clang-tidy should not warn about array to pointer decay on system macros

2019-10-16 Thread fiesh via Phabricator via cfe-commits

fiesh added a comment.
Herald added a subscriber: wuzish.

Ping!  Am I correct in that basically everything's done here and this has been 
lingering ever since?  It would be great if the change could make it.


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

https://reviews.llvm.org/D31130



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

[PATCH] D62686: [RISCV] Add support for save/restore of callee-saved registers via libcalls

2019-10-16 Thread Ana Pazos via Phabricator via cfe-commits

apazos added a comment.

Thanks Lewis, the runs are looking good, no failures, and good code size 
savings (average 3%)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62686



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

[PATCH] D31130: B32239 clang-tidy should not warn about array to pointer decay on system macros

2019-10-16 Thread Roman Lebedev via Phabricator via cfe-commits

lebedev.ri added a comment.

The description only says what the patch does, not why this is the desired 
behavior.
Also, this is now under a wrong license.


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

https://reviews.llvm.org/D31130



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

[PATCH] D68028: [clang] Add no_builtin attribute

2019-10-16 Thread Richard Smith - zygoloid via Phabricator via cfe-commits

rsmith added inline comments.



Comment at: clang/lib/Sema/SemaDecl.cpp:9508-9510
+  // FIXME: We should really be doing this in SemaDeclAttr.cpp::handleNoBuiltin
+  // but there is a bug with FunctionDecl::isThisDeclarationADefinition() which
+  // always returns false before Sema::ActOnStartOfFunctionDef is called.

aaron.ballman wrote:
> handleNoBuiltin -> handleNoBuiltinAttr
I am not convinced that this is a bug -- the function declaration does not 
become a definition until the parser reaches the definition.

In any case, I don't think the predicate you want is "is this declaration a 
definition?". Rather, I think what you want is, "does this declaration 
introduce an explicit function body?". In particular, we should not permit uses 
of this attribute on defaulted or deleted functions, nor on functions that have 
a definition by virtue of using `__attribute__((alias))`. So it probably should 
be a syntactic check on the form of the declarator (that is, the check you're 
perrforming here), and the check should probably be 
`D.getFunctionDefinitionKind() == FDK_Definition`. (A custom diagnostic for 
using the attribute on a defaulted or deleted function would be nice too, since 
the existing diagnostic text isn't really accurate in those cases.)



Comment at: clang/test/Sema/no-builtin.c:7
+
+void no_builtin_no_argument() __attribute__((no_builtin)) {}
+// expected-error@-1 {{'no_builtin' attribute takes at least 1 argument}}

I find this surprising. I would expect this to work, and to mean the same as 
`-fno-builtin` for the function (that is, same as the `*` form).

I think might be a better design to remove the magical `"*"` form entirely, and 
use an empty argument list to mean "all builtins". Have you considered that? 
(That would better mirror how `-fno-builtin` vs `-fno-builtin-foo` works.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68028



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

[PATCH] D68028: [clang] Add no_builtin attribute

2019-10-16 Thread Aaron Ballman via Phabricator via cfe-commits

aaron.ballman added inline comments.



Comment at: clang/lib/Sema/SemaDecl.cpp:9508-9510
+  // FIXME: We should really be doing this in SemaDeclAttr.cpp::handleNoBuiltin
+  // but there is a bug with FunctionDecl::isThisDeclarationADefinition() which
+  // always returns false before Sema::ActOnStartOfFunctionDef is called.

rsmith wrote:
> aaron.ballman wrote:
> > handleNoBuiltin -> handleNoBuiltinAttr
> I am not convinced that this is a bug -- the function declaration does not 
> become a definition until the parser reaches the definition.
> 
> In any case, I don't think the predicate you want is "is this declaration a 
> definition?". Rather, I think what you want is, "does this declaration 
> introduce an explicit function body?". In particular, we should not permit 
> uses of this attribute on defaulted or deleted functions, nor on functions 
> that have a definition by virtue of using `__attribute__((alias))`. So it 
> probably should be a syntactic check on the form of the declarator (that is, 
> the check you're perrforming here), and the check should probably be 
> `D.getFunctionDefinitionKind() == FDK_Definition`. (A custom diagnostic for 
> using the attribute on a defaulted or deleted function would be nice too, 
> since the existing diagnostic text isn't really accurate in those cases.)
> In particular, we should not permit uses of this attribute on defaulted or 
> deleted functions

Deleted functions, sure. Defaulted functions... not so sure. I could sort of 
imagine wanting to instruct a defaulted assignment operator that does 
memberwise copy that it's not allowed to use a builtin memcpy, for instance. Or 
is this a bad idea for some reason I'm not thinking of?



Comment at: clang/test/Sema/no-builtin.c:7
+
+void no_builtin_no_argument() __attribute__((no_builtin)) {}
+// expected-error@-1 {{'no_builtin' attribute takes at least 1 argument}}

rsmith wrote:
> I find this surprising. I would expect this to work, and to mean the same as 
> `-fno-builtin` for the function (that is, same as the `*` form).
> 
> I think might be a better design to remove the magical `"*"` form entirely, 
> and use an empty argument list to mean "all builtins". Have you considered 
> that? (That would better mirror how `-fno-builtin` vs `-fno-builtin-foo` 
> works.)
> I think might be a better design to remove the magical "*" form entirely, and 
> use an empty argument list to mean "all builtins".

I like this approach.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68028



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

[PATCH] D68117: [DWARF-5] Support for C++11 defaulted, deleted member functions.

2019-10-16 Thread Paul Robinson via Phabricator via cfe-commits

probinson added a comment.

In D68117#1711714 , @dblaikie wrote:

> In D68117#1711154 , @probinson wrote:
>
> > (@dblaikie Aside regarding noreturn, the original DWARF proposal was for a 
> > debugger wanting to know a given function will not return.
>
>
> I'd still be curious to know which consumer, if they're still interested, 
> what feature they're trying to build with it, if they're using Clang/LLVM's 
> output, etc.


DW_AT_noreturn (http://dwarfstd.org/ShowIssue.php?issue=140331.1) was requested 
by Mark Wielaard, who AFAICT works for Red Hat.  Now you know as much as I do.

>> As a flag, in the DWARF it costs an extra abbrev entry but no space in 
>> .debug_info.  Cheap enough for me.)
> 
> Oh, sure - I don't think the output cost is high here or there - but it's 
> more feature surface area, the time spent designing, code reviewing, 
> supporting, etc, another place for bugs, etc. So I'd generally like to have 
> some justification beyond "the spec says we can" - ideally, I'd like a DWARF 
> consumer that's actively trying to build a feature that they can't without 
> this new information.

Fair.


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

https://reviews.llvm.org/D68117



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

[PATCH] D68835: [clang-scan-deps] Add basic support for Clang modules.

2019-10-16 Thread Michael Spencer via Phabricator via cfe-commits

Bigcheese updated this revision to Diff 225311.
Bigcheese added a comment.

Added .i, .ii, .mi, and .mmi as files to minimize.


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

https://reviews.llvm.org/D68835

Files:
  lib/Tooling/DependencyScanning/DependencyScanningFilesystem.cpp
  test/ClangScanDeps/Inputs/module.modulemap
  test/ClangScanDeps/Inputs/modules_cdb.json
  test/ClangScanDeps/modules.cpp

Index: test/ClangScanDeps/modules.cpp
===
--- /dev/null
+++ test/ClangScanDeps/modules.cpp
@@ -0,0 +1,41 @@
+// RUN: rm -rf %t.dir
+// RUN: rm -rf %t.cdb
+// RUN: rm -rf %t.module-cache
+// RUN: mkdir -p %t.dir
+// RUN: cp %s %t.dir/modules_cdb_input.cpp
+// RUN: cp %s %t.dir/modules_cdb_input2.cpp
+// RUN: mkdir %t.dir/Inputs
+// RUN: cp %S/Inputs/header.h %t.dir/Inputs/header.h
+// RUN: cp %S/Inputs/header2.h %t.dir/Inputs/header2.h
+// RUN: cp %S/Inputs/module.modulemap %t.dir/Inputs/module.modulemap
+// RUN: sed -e "s|DIR|%/t.dir|g" %S/Inputs/modules_cdb.json > %t.cdb
+//
+// RUN: clang-scan-deps -compilation-database %t.cdb -j 1 -mode preprocess-minimized-sources | \
+// RUN:   FileCheck --check-prefixes=CHECK1,CHECK2,CHECK2NO %s
+//
+// The output order is non-deterministic when using more than one thread,
+// so check the output using two runs. Note that the 'NOT' check is not used
+// as it might fail if the results for `modules_cdb_input.cpp` are reported before
+// `modules_cdb_input2.cpp`.
+//
+// RUN: clang-scan-deps -compilation-database %t.cdb -j 2 -mode preprocess-minimized-sources | \
+// RUN:   FileCheck --check-prefix=CHECK1 %s
+// RUN: clang-scan-deps -compilation-database %t.cdb -j 2 -mode preprocess | \
+// RUN:   FileCheck --check-prefix=CHECK1 %s
+// RUN: clang-scan-deps -compilation-database %t.cdb -j 2 -mode preprocess-minimized-sources | \
+// RUN:   FileCheck --check-prefix=CHECK2 %s
+// RUN: clang-scan-deps -compilation-database %t.cdb -j 2 -mode preprocess | \
+// RUN:   FileCheck --check-prefix=CHECK2 %s
+
+#include "header.h"
+
+// CHECK1: modules_cdb_input2.cpp
+// CHECK1-NEXT: modules_cdb_input2.cpp
+// CHECK1-NEXT: Inputs{{/|\\}}module.modulemap
+// CHECK1-NEXT: Inputs{{/|\\}}header2.h
+// CHECK1: Inputs{{/|\\}}header.h
+
+// CHECK2: modules_cdb_input.cpp
+// CHECK2-NEXT: Inputs{{/|\\}}module.modulemap
+// CHECK2-NEXT: Inputs{{/|\\}}header.h
+// CHECK2NO-NOT: header2
Index: test/ClangScanDeps/Inputs/modules_cdb.json
===
--- /dev/null
+++ test/ClangScanDeps/Inputs/modules_cdb.json
@@ -0,0 +1,13 @@
+[
+{
+  "directory": "DIR",
+  "command": "clang -E -fsyntax-only DIR/modules_cdb_input2.cpp -IInputs -D INCLUDE_HEADER2 -MD -MF DIR/modules_cdb2.d -fmodules -fmodules-cache-path=DIR/module-cache -fimplicit-modules -fimplicit-module-maps",
+  "file": "DIR/modules_cdb_input2.cpp"
+},
+{
+  "directory": "DIR",
+  "command": "clang -E DIR/modules_cdb_input.cpp -IInputs -fmodules -fmodules-cache-path=DIR/module-cache -fimplicit-modules -fimplicit-module-maps",
+  "file": "DIR/modules_cdb_input.cpp"
+}
+]
+
Index: test/ClangScanDeps/Inputs/module.modulemap
===
--- /dev/null
+++ test/ClangScanDeps/Inputs/module.modulemap
@@ -0,0 +1,7 @@
+module header1 {
+  header "header.h"
+}
+
+module header2 {
+header "header2.h"
+}
Index: lib/Tooling/DependencyScanning/DependencyScanningFilesystem.cpp
===
--- lib/Tooling/DependencyScanning/DependencyScanningFilesystem.cpp
+++ lib/Tooling/DependencyScanning/DependencyScanningFilesystem.cpp
@@ -122,6 +122,32 @@
   return It.first->getValue();
 }
 
+/// Whitelist file extensions that should be minimized, treating no extension as
+/// a source file that should be minimized.
+///
+/// This is kinda hacky, it would be better if we knew what kind of file Clang
+/// was expecting instead.
+static bool shouldMinimize(StringRef Filename) {
+  StringRef Ext = llvm::sys::path::extension(Filename);
+  if (Ext.empty())
+return true; // C++ standard library
+  return llvm::StringSwitch(Ext)
+.CasesLower(".c", ".cc", ".cpp", ".c++", ".cxx", true)
+.CasesLower(".h", ".hh", ".hpp", ".h++", ".hxx", true)
+.CasesLower(".m", ".mm", true)
+.CasesLower(".i", ".ii", ".mi", ".mmi", true)
+.CasesLower(".def", ".inc", true)
+.Default(false);
+}
+
+
+static bool shouldCacheStatFailures(StringRef Filename) {
+  StringRef Ext = llvm::sys::path::extension(Filename);
+  if (Ext.empty())
+return false; // This may be the module cache directory.
+  return shouldMinimize(Filename); // Only cache stat failures on source files.
+}
+
 llvm::ErrorOr
 DependencyScanningWorkerFilesystem::getOrCreateFileSystemEntry(
 const StringRef Filename) {
@@ -132,7 +158,8 @@
   // FIXME: Handle PCM/PCH files.
   // FIXME: Handle module map files.
 
-  bool KeepOriginalSource = IgnoredFiles.co

[PATCH] D68818: [hip][cuda] Fix the extended lambda name mangling issue.

2019-10-16 Thread John McCall via Phabricator via cfe-commits

rjmccall added a comment.

I agree with Richard's suggestion of just numbering all the lambdas in both 
modes if that's viable.




Comment at: clang/include/clang/AST/DeclCXX.h:587-590
+unsigned NumExplicitCaptures : 12;
+
+/// Has known `internal` linkage.
+unsigned HasKnownInternalLinkage : 1;

hliao wrote:
> Try to avoid inflating memory footprint by borrowing one bit from 
> `NumExplicitCaptures`. It seems to me that we won't have that large number 
> (8192) of *explicit* capture.
If this field is necessary, please borrow its space from `ManglingNumber` below 
rather than the number of explicit captures.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68818



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

[PATCH] D62731: Add support for options -frounding-math, ftrapping-math, -fp-model=, and -fp-exception-behavior=, : Specify floating point behavior

2019-10-16 Thread John McCall via Phabricator via cfe-commits

rjmccall added inline comments.



Comment at: clang/include/clang/Basic/LangOptions.h:203
+   // Floating point exceptions are not handled: fp exceptions are masked.
+   FPEB_Ignore,  // This is the default
+   // Optimizer will avoid transformations that may raise exceptions that would

mibintc wrote:
> -fno-trapping-math implemented by selecting -ffp-exception-behavior=ignore 
> and -ftrapping-math is implemented by selecting 
> -ffp-exception-behavior=strict.   What do you think about making 
> ftrapping-math a Driver only option, so that Driver converts the values like 
> this. Otherwise let's make fp-exception-behavior take precedence, in llvm, 
> over ftrapping-math (trapping math is t/f but exception behavior, in the llvm 
> Constrained Floating Point Intrinsics, can take 3 values)
If your new option subsumes existing ones, I think making it the frontend 
option is sensible.


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] D69072: [OpenCL] Added doc to describe OpenCL support

2019-10-16 Thread Anastasia Stulova via Phabricator via cfe-commits

Anastasia created this revision.
Anastasia added reviewers: svenvh, mantognini, neil.hickey.
Herald added subscribers: ebevhan, yaxunl.

https://reviews.llvm.org/D69072

Files:
  clang/docs/OpenCLSupport.rst


Index: clang/docs/OpenCLSupport.rst
===
--- /dev/null
+++ clang/docs/OpenCLSupport.rst
@@ -0,0 +1,47 @@
+.. raw:: html
+
+  
+.none { background-color: #FF }
+.partial { background-color: #99 }
+.good { background-color: #CCFF99 }
+  
+
+.. role:: none
+.. role:: partial
+.. role:: good
+
+.. contents::
+   :local:
+
+==
+OpenCL Support
+==
+
+Clang fully supports all OpenCL C versions from 1.1 to 2.0.
+
+Please refer to `Bugzilla
+`_
+for the most up to date bugs report.
+
+
+C++ for OpenCL Implementation Status
+
+
+Bugzilla bugs for this functionality are typically prefixed
+with '[C++]'.
+
+Differences to OpenCL C
+---
+
+TODO!
+
+Missing features or with limited support
+
+
+- Use of ObjC blocks is disabled.
+
+- Global destructor invocation is not generated correctly.
+
+- Initialization of objects in `__constant` addr spaces is not guaranteed to 
work.
+
+- `addrspace_cast` operator is not supported.


Index: clang/docs/OpenCLSupport.rst
===
--- /dev/null
+++ clang/docs/OpenCLSupport.rst
@@ -0,0 +1,47 @@
+.. raw:: html
+
+  
+.none { background-color: #FF }
+.partial { background-color: #99 }
+.good { background-color: #CCFF99 }
+  
+
+.. role:: none
+.. role:: partial
+.. role:: good
+
+.. contents::
+   :local:
+
+==
+OpenCL Support
+==
+
+Clang fully supports all OpenCL C versions from 1.1 to 2.0.
+
+Please refer to `Bugzilla
+`_
+for the most up to date bugs report.
+
+
+C++ for OpenCL Implementation Status
+
+
+Bugzilla bugs for this functionality are typically prefixed
+with '[C++]'.
+
+Differences to OpenCL C
+---
+
+TODO!
+
+Missing features or with limited support
+
+
+- Use of ObjC blocks is disabled.
+
+- Global destructor invocation is not generated correctly.
+
+- Initialization of objects in `__constant` addr spaces is not guaranteed to work.
+
+- `addrspace_cast` operator is not supported.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D68554: [clang-format] Proposal for clang-format to give compiler style warnings

2019-10-16 Thread MyDeveloperDay via Phabricator via cfe-commits

MyDeveloperDay added a subscriber: hans.
MyDeveloperDay added a comment.

In D68554#1709316 , @sylvestre.ledru 
wrote:

> @MyDeveloperDay I think it should be added to the release notes. it is a 
> great new changes for clang format (it would have made my life at Mozilla 
> much easier ;)

I am super honoured you think this is a good change, to be honest in using it 
this week, I've spent so much time typing `find . -name '*.cpp' ...` I am even 
more convinced we need a  recursive -r option something like D29039: 
[clang-format] Proposal for clang-format -r option 
 so plan to pursue that more.

I can't wait for @hans next Windows Snapshot, this is my gate for rolling into 
our builds and CI system, after that, I'm gonna catch every single person who 
tries to build/check in unclang-formatted.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68554

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

[PATCH] D68969: [clang-format] Remove the dependency on frontend

2019-10-16 Thread MyDeveloperDay via Phabricator via cfe-commits

MyDeveloperDay updated this revision to Diff 225320.
MyDeveloperDay added a comment.

Remove need to split lines or search for `\n`

General Algorithm

1. take Location of Replacement line and column
2. make a new SourceLocation of line and column =0 (beginning of that 
replacement line)
3. make a new SourceLocation of line+1 and column = 0   (beginning of the next 
line)
4. use `getCharacterData()` to get pointers to beginning of each line
5. make a String from those begin and end ptrs

Seems very much faster when run over clang source tree (removal of noticeable 
pauses on large files)

That should equal the line


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

https://reviews.llvm.org/D68969

Files:
  clang/tools/clang-format/CMakeLists.txt
  clang/tools/clang-format/ClangFormat.cpp


Index: clang/tools/clang-format/ClangFormat.cpp
===
--- clang/tools/clang-format/ClangFormat.cpp
+++ clang/tools/clang-format/ClangFormat.cpp
@@ -18,8 +18,8 @@
 #include "clang/Basic/SourceManager.h"
 #include "clang/Basic/Version.h"
 #include "clang/Format/Format.h"
-#include "clang/Frontend/TextDiagnosticPrinter.h"
 #include "clang/Rewrite/Core/Rewriter.h"
+#include "llvm/Demangle/StringView.h"
 #include "llvm/Support/CommandLine.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/InitLLVM.h"
@@ -325,12 +325,9 @@
   IntrusiveRefCntPtr DiagOpts = new DiagnosticOptions();
   DiagOpts->ShowColors = (ShowColors && !NoShowColors);
 
-  TextDiagnosticPrinter *DiagsBuffer =
-  new TextDiagnosticPrinter(llvm::errs(), &*DiagOpts, false);
-
   IntrusiveRefCntPtr DiagID(new DiagnosticIDs());
   IntrusiveRefCntPtr Diags(
-  new DiagnosticsEngine(DiagID, &*DiagOpts, DiagsBuffer));
+  new DiagnosticsEngine(DiagID, &*DiagOpts));
 
   IntrusiveRefCntPtr InMemoryFileSystem(
   new llvm::vfs::InMemoryFileSystem);
@@ -339,24 +336,41 @@
   FileID FileID = createInMemoryFile(AssumedFileName, Code.get(), Sources,
  Files, InMemoryFileSystem.get());
 
-  const unsigned ID = Diags->getCustomDiagID(
-  WarningsAsErrors ? clang::DiagnosticsEngine::Error
-   : clang::DiagnosticsEngine::Warning,
-  "code should be clang-formatted [-Wclang-format-violations]");
+  FileManager &FileMgr = Sources.getFileManager();
+  llvm::ErrorOr FileEntryPtr =
+  FileMgr.getFile(AssumedFileName);
 
   unsigned Errors = 0;
-  DiagsBuffer->BeginSourceFile(LangOptions(), nullptr);
   if (WarnFormat && !NoWarnFormat) {
+ArrayRef> Ranges;
 for (const auto &R : Replaces) {
-  Diags->Report(
-  Sources.getLocForStartOfFile(FileID).getLocWithOffset(R.getOffset()),
-  ID);
+  PresumedLoc PLoc = Sources.getPresumedLoc(
+  
Sources.getLocForStartOfFile(FileID).getLocWithOffset(R.getOffset()));
+
+  SourceLocation LineBegin = Sources.translateFileLineCol(
+  FileEntryPtr.get(), PLoc.getLine() - 1, 0);
+  SourceLocation NextLineBegin =
+  Sources.translateFileLineCol(FileEntryPtr.get(), PLoc.getLine(), 0);
+
+  const char *StartBuf = Sources.getCharacterData(LineBegin);
+  const char *EndBuf = Sources.getCharacterData(NextLineBegin);
+
+  StringRef Line(StartBuf, (EndBuf - StartBuf));
+
+  SMDiagnostic Diags(
+  llvm::SourceMgr(), SMLoc(), AssumedFileName, PLoc.getLine(),
+  PLoc.getColumn() - 1,
+  WarningsAsErrors ? SourceMgr::DiagKind::DK_Error
+   : SourceMgr::DiagKind::DK_Warning,
+  "code should be clang-formatted [-Wclang-format-violations]", Line,
+  ArrayRef>());
+
+  Diags.print(nullptr, llvm::errs(), (ShowColors && !NoShowColors));
   Errors++;
   if (ErrorLimit && Errors >= ErrorLimit)
 break;
 }
   }
-  DiagsBuffer->EndSourceFile();
   return WarningsAsErrors;
 }
 
Index: clang/tools/clang-format/CMakeLists.txt
===
--- clang/tools/clang-format/CMakeLists.txt
+++ clang/tools/clang-format/CMakeLists.txt
@@ -7,7 +7,6 @@
 set(CLANG_FORMAT_LIB_DEPS
   clangBasic
   clangFormat
-  clangFrontend
   clangRewrite
   clangToolingCore
   )


Index: clang/tools/clang-format/ClangFormat.cpp
===
--- clang/tools/clang-format/ClangFormat.cpp
+++ clang/tools/clang-format/ClangFormat.cpp
@@ -18,8 +18,8 @@
 #include "clang/Basic/SourceManager.h"
 #include "clang/Basic/Version.h"
 #include "clang/Format/Format.h"
-#include "clang/Frontend/TextDiagnosticPrinter.h"
 #include "clang/Rewrite/Core/Rewriter.h"
+#include "llvm/Demangle/StringView.h"
 #include "llvm/Support/CommandLine.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/InitLLVM.h"
@@ -325,12 +325,9 @@
   IntrusiveRefCntPtr DiagOpts = new DiagnosticOptions();
   DiagOpts->ShowColors = (ShowColors && !NoShowColors);
 
-  TextDiagnosticPrinter *Diag

[PATCH] D68028: [clang] Add no_builtin attribute

2019-10-16 Thread Richard Smith - zygoloid via Phabricator via cfe-commits

rsmith added inline comments.



Comment at: clang/lib/Sema/SemaDecl.cpp:9508-9510
+  // FIXME: We should really be doing this in SemaDeclAttr.cpp::handleNoBuiltin
+  // but there is a bug with FunctionDecl::isThisDeclarationADefinition() which
+  // always returns false before Sema::ActOnStartOfFunctionDef is called.

aaron.ballman wrote:
> rsmith wrote:
> > aaron.ballman wrote:
> > > handleNoBuiltin -> handleNoBuiltinAttr
> > I am not convinced that this is a bug -- the function declaration does not 
> > become a definition until the parser reaches the definition.
> > 
> > In any case, I don't think the predicate you want is "is this declaration a 
> > definition?". Rather, I think what you want is, "does this declaration 
> > introduce an explicit function body?". In particular, we should not permit 
> > uses of this attribute on defaulted or deleted functions, nor on functions 
> > that have a definition by virtue of using `__attribute__((alias))`. So it 
> > probably should be a syntactic check on the form of the declarator (that 
> > is, the check you're perrforming here), and the check should probably be 
> > `D.getFunctionDefinitionKind() == FDK_Definition`. (A custom diagnostic for 
> > using the attribute on a defaulted or deleted function would be nice too, 
> > since the existing diagnostic text isn't really accurate in those cases.)
> > In particular, we should not permit uses of this attribute on defaulted or 
> > deleted functions
> 
> Deleted functions, sure. Defaulted functions... not so sure. I could sort of 
> imagine wanting to instruct a defaulted assignment operator that does 
> memberwise copy that it's not allowed to use a builtin memcpy, for instance. 
> Or is this a bad idea for some reason I'm not thinking of?
`-fno-builtin` does not turn off using `llvm.memcpy` for copying memory, and it 
doesn't turn off `llvm.memcpy` being lowered to a call to `memcpy`. Allowing 
this for defaulted functions would only give a false sense of security, at 
least for now (though I could imagine we might find some way to change that in 
the future).

Also, trivial defaulted functions (where we're most likely to end up with 
`memcpy` calls) are often not emitted at all, instead being directly inlined by 
the frontend, so there's nowhere to attach a `no-builtin-memcpy` LLVM attribute 
(we'd need to put the attribute on all callers of those functions) even if LLVM 
learned to not emit calls to `memcpy` to implement `llvm.memcpy` when operating 
under a `no-builtin-memcpy` constraint.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68028



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

[PATCH] D68528: [Implicit Modules] Add -cc1 option -fmodules-strict-hash which includes search paths and diagnostics.

2019-10-16 Thread Michael Spencer via Phabricator via cfe-commits

Bigcheese updated this revision to Diff 225326.
Bigcheese marked an inline comment as done.
Bigcheese added a comment.

Fixed spelling and updated comment.


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

https://reviews.llvm.org/D68528

Files:
  include/clang/Driver/CC1Options.td
  include/clang/Lex/HeaderSearchOptions.h
  lib/Frontend/CompilerInvocation.cpp
  test/Modules/context-hash.c

Index: test/Modules/context-hash.c
===
--- /dev/null
+++ test/Modules/context-hash.c
@@ -0,0 +1,33 @@
+// RUN: rm -rf %t
+// RUN: %clang_cc1 -fsyntax-only -internal-isystem \
+// RUN:   %S/Inputs/System/usr/include -fmodules -fimplicit-module-maps \
+// RUN:   -fmodules-cache-path=%t %s -Rmodule-build 2> %t1
+// RUN: rm -rf %t
+// RUN: %clang_cc1 -fsyntax-only -internal-isystem \
+// RUN:   %S/Inputs/System/usr/include -internal-isystem %S -fmodules \
+// RUN:   -fimplicit-module-maps -fmodules-cache-path=%t %s -Rmodule-build 2> \
+// RUN:   %t2
+// RUN: rm -rf %t
+// RUN: %clang_cc1 -fsyntax-only -internal-isystem \
+// RUN:   %S/Inputs/System/usr/include -internal-isystem %S -fmodules \
+// RUN:   -fimplicit-module-maps -fmodules-cache-path=%t %s \
+// RUN:   -fmodules-strict-hash -Rmodule-build 2> %t3
+// RUN: rm -rf %t
+// RUN: %clang_cc1 -fsyntax-only -Weverything -internal-isystem \
+// RUN:   %S/Inputs/System/usr/include -fmodules -fmodules-strict-hash \
+// RUN:   -fimplicit-module-maps -fmodules-cache-path=%t %s -Rmodule-build 2> \
+// RUN:   %t4
+// RUN: echo %t | cat - %t1 %t2 %t3 %t4 | FileCheck %s
+
+// This test verifies that only strict hashing includes search paths and
+// diagnostics in the module context hash.
+
+#include 
+
+// CHECK: [[PREFIX:(.*[/\\])+[a-zA-Z0-9.-]+]]
+// CHECK: building module 'cstd' as '[[PREFIX]]{{[/\\]}}[[CONTEXT_HASH:[A-Z0-9]+]]{{[/\\]}}cstd-[[AST_HASH:[A-Z0-9]+]].pcm'
+// CHECK: building module 'cstd' as '{{.*[/\\]}}[[CONTEXT_HASH]]{{[/\\]}}cstd-[[AST_HASH]].pcm'
+// CHECK-NOT: building module 'cstd' as '{{.*[/\\]}}[[CONTEXT_HASH]]{{[/\\]}}
+// CHECK: cstd-[[AST_HASH]].pcm'
+// CHECK-NOT: building module 'cstd' as '{{.*[/\\]}}[[CONTEXT_HASH]]{{[/\\]}}
+// CHECK: cstd-[[AST_HASH]].pcm'
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -2065,6 +2065,7 @@
 Opts.AddPrebuiltModulePath(A->getValue());
   Opts.DisableModuleHash = Args.hasArg(OPT_fdisable_module_hash);
   Opts.ModulesHashContent = Args.hasArg(OPT_fmodules_hash_content);
+  Opts.ModulesStrictHash = Args.hasArg(OPT_fmodules_strict_hash);
   Opts.ModulesValidateDiagnosticOptions =
   !Args.hasArg(OPT_fmodules_disable_diagnostic_validation);
   Opts.ImplicitModuleMaps = Args.hasArg(OPT_fimplicit_module_maps);
@@ -3544,6 +3545,7 @@
   using llvm::hash_code;
   using llvm::hash_value;
   using llvm::hash_combine;
+  using llvm::hash_combine_range;
 
   // Start the signature with the compiler version.
   // FIXME: We'd rather use something more cryptographically sound than
@@ -3598,6 +3600,24 @@
   hsOpts.ModulesValidateDiagnosticOptions);
   code = hash_combine(code, hsOpts.ResourceDir);
 
+  if (hsOpts.ModulesStrictHash) {
+hash_code SHPC = hash_combine_range(hsOpts.SystemHeaderPrefixes.begin(),
+hsOpts.SystemHeaderPrefixes.end());
+hash_code UEC = hash_combine_range(hsOpts.UserEntries.begin(),
+   hsOpts.UserEntries.end());
+code = hash_combine(code, hsOpts.SystemHeaderPrefixes.size(), SHPC,
+hsOpts.UserEntries.size(), UEC);
+
+const DiagnosticOptions &diagOpts = getDiagnosticOpts();
+#define DIAGOPT(Name, Bits, Default) \
+  code = hash_combine(code, diagOpts.Name);
+#define ENUM_DIAGOPT(Name, Type, Bits, Default) \
+  code = hash_combine(code, diagOpts.get##Name());
+#include "clang/Basic/DiagnosticOptions.def"
+#undef DIAGOPT
+#undef ENUM_DIAGOPT
+  }
+
   // Extend the signature with the user build path.
   code = hash_combine(code, hsOpts.ModuleUserBuildPath);
 
Index: include/clang/Lex/HeaderSearchOptions.h
===
--- include/clang/Lex/HeaderSearchOptions.h
+++ include/clang/Lex/HeaderSearchOptions.h
@@ -11,6 +11,7 @@
 
 #include "clang/Basic/LLVM.h"
 #include "llvm/ADT/CachedHashString.h"
+#include "llvm/ADT/Hashing.h"
 #include "llvm/ADT/SetVector.h"
 #include "llvm/ADT/StringRef.h"
 #include 
@@ -206,6 +207,13 @@
 
   unsigned ModulesHashContent : 1;
 
+  /// Whether we should include all things that could impact the module in the
+  /// hash.
+  ///
+  /// This includes things like the full header search path, and enabled
+  /// diagnostics.
+  unsigned ModulesStrictHash : 1;
+
   HeaderSearchOptions(StringRef _Sysroot = "/")
   : Sysroot(_Sysroot), ModuleF

[PATCH] D69017: Include sanitize blacklist and other extra deps as part of scan-deps output

2019-10-16 Thread Jan Korous via Phabricator via cfe-commits

jkorous accepted this revision.
jkorous added a comment.

Looks great! Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69017



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

[clang-tools-extra] r375058 - [lit] Fix another test case that r374652 missed

2019-10-16 Thread Joel E. Denny via cfe-commits

Author: jdenny
Date: Wed Oct 16 16:58:58 2019
New Revision: 375058

URL: http://llvm.org/viewvc/llvm-project?rev=375058&view=rev
Log:
[lit] Fix another test case that r374652 missed

Modified:
clang-tools-extra/trunk/test/clang-include-fixer/merge.test

Modified: clang-tools-extra/trunk/test/clang-include-fixer/merge.test
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-include-fixer/merge.test?rev=375058&r1=375057&r2=375058&view=diff
==
--- clang-tools-extra/trunk/test/clang-include-fixer/merge.test (original)
+++ clang-tools-extra/trunk/test/clang-include-fixer/merge.test Wed Oct 16 
16:58:58 2019
@@ -1,6 +1,6 @@
 # RUN: find-all-symbols -merge-dir=%S/Inputs/merge %t.merged
 # RUN: sed '/^#/d' %s > %t.golden
-# RUN: diff -u %t.golden %t.merged
+# RUN: diff --strip-trailing-cr -u %t.golden %t.merged
 ---
 Name:bar
 Contexts:


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

[PATCH] D66827: Add support for MS qualifiers ptr32, ptr64, sptr, uptr.

2019-10-16 Thread Amy Huang via Phabricator via cfe-commits

akhuang added a comment.

@DarkShadow44 Thanks for finding this bug! I haven't had time to look at this 
for a while but will start working on it soon.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66827



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

r375063 - [Concepts] ConceptSpecializationExprs mangling

2019-10-16 Thread Saar Raz via cfe-commits

Author: saar.raz
Date: Wed Oct 16 17:16:01 2019
New Revision: 375063

URL: http://llvm.org/viewvc/llvm-project?rev=375063&view=rev
Log:
[Concepts] ConceptSpecializationExprs mangling

Implement mangling for CSEs to match regular template-ids.
Reviewed as part of D41569 .

Re-commit fixing failing test.


Added:
cfe/trunk/test/CodeGenCXX/mangle-concept.cpp
Modified:
cfe/trunk/lib/AST/ItaniumMangle.cpp
cfe/trunk/lib/Sema/SemaTemplate.cpp

Modified: cfe/trunk/lib/AST/ItaniumMangle.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ItaniumMangle.cpp?rev=375063&r1=375062&r2=375063&view=diff
==
--- cfe/trunk/lib/AST/ItaniumMangle.cpp (original)
+++ cfe/trunk/lib/AST/ItaniumMangle.cpp Wed Oct 16 17:16:01 2019
@@ -969,7 +969,7 @@ void CXXNameMangler::mangleUnscopedTempl
 assert(!AdditionalAbiTags &&
"template template param cannot have abi tags");
 mangleTemplateParameter(TTP->getDepth(), TTP->getIndex());
-  } else if (isa(ND)) {
+  } else if (isa(ND) || isa(ND)) {
 mangleUnscopedName(ND, AdditionalAbiTags);
   } else {
 mangleUnscopedName(ND->getTemplatedDecl(), AdditionalAbiTags);
@@ -1890,7 +1890,7 @@ void CXXNameMangler::mangleTemplatePrefi
 mangleTemplateParameter(TTP->getDepth(), TTP->getIndex());
   } else {
 manglePrefix(getEffectiveDeclContext(ND), NoFunction);
-if (isa(ND))
+if (isa(ND) || isa(ND))
   mangleUnqualifiedName(ND, nullptr);
 else
   mangleUnqualifiedName(ND->getTemplatedDecl(), nullptr);
@@ -3658,7 +3658,6 @@ recurse:
   case Expr::ConvertVectorExprClass:
   case Expr::StmtExprClass:
   case Expr::TypeTraitExprClass:
-  case Expr::ConceptSpecializationExprClass:
   case Expr::ArrayTypeTraitExprClass:
   case Expr::ExpressionTraitExprClass:
   case Expr::VAArgExprClass:
@@ -4168,6 +4167,18 @@ recurse:
 mangleExpression(cast(E)->getSubExpr(), Arity);
 break;
 
+
+  case Expr::ConceptSpecializationExprClass: {
+//   ::= L  E # external name
+Out << "L_Z";
+auto *CSE = cast(E);
+mangleTemplateName(CSE->getNamedConcept(),
+   CSE->getTemplateArguments().data(),
+   CSE->getTemplateArguments().size());
+Out << 'E';
+break;
+  }
+
   case Expr::DeclRefExprClass:
 mangleDeclRefExpr(cast(E)->getDecl());
 break;

Modified: cfe/trunk/lib/Sema/SemaTemplate.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaTemplate.cpp?rev=375063&r1=375062&r2=375063&view=diff
==
--- cfe/trunk/lib/Sema/SemaTemplate.cpp (original)
+++ cfe/trunk/lib/Sema/SemaTemplate.cpp Wed Oct 16 17:16:01 2019
@@ -4302,7 +4302,7 @@ ExprResult Sema::BuildTemplateIdExpr(con
   TemplateKWLoc, TemplateArgs);
   }
 
-  if (R.getAsSingle() && !AnyDependentArguments()) {
+  if (R.getAsSingle()) {
 return CheckConceptTemplateId(SS, TemplateKWLoc,
   R.getLookupNameInfo().getBeginLoc(),
   R.getFoundDecl(),

Added: cfe/trunk/test/CodeGenCXX/mangle-concept.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/mangle-concept.cpp?rev=375063&view=auto
==
--- cfe/trunk/test/CodeGenCXX/mangle-concept.cpp (added)
+++ cfe/trunk/test/CodeGenCXX/mangle-concept.cpp Wed Oct 16 17:16:01 2019
@@ -0,0 +1,16 @@
+// RUN: %clang_cc1 -verify -Wno-return-type -Wno-main -std=c++2a -fconcepts-ts 
-emit-llvm -triple %itanium_abi_triple -o - %s | FileCheck %s
+// expected-no-diagnostics
+
+namespace test1 {
+template  struct S {};
+template  concept C = true;
+template  S> f0() { return S>{}; }
+template S> f0<>();
+// CHECK: @_ZN5test12f0IiEENS_1SIXL_ZNS_1CIT_EEv(
+}
+
+template  struct S {};
+template  concept C = true;
+template  S> f0() { return S>{}; }
+template S> f0<>();
+// CHECK: @_Z2f0IiE1SIXL_Z1CIT_v(


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

[PATCH] D67321: Respect CLANG_LINK_CLANG_DYLIB=ON in libclang and c-index-test

2019-10-16 Thread Aaron Puchert via Phabricator via cfe-commits

aaronpuchert added a comment.

@beanz Could you have a look again?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67321



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

1 2 >

1 - 100 of 113 matches

Mail list logo