[PATCH] D94382: [clangd] Avoid recursion in TargetFinder::add()

2021-01-11 Thread Nathan Ridge via Phabricator via cfe-commits
nridge updated this revision to Diff 316000.
nridge added a comment.

Address review comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94382

Files:
  clang-tools-extra/clangd/FindTarget.cpp
  clang-tools-extra/clangd/FindTarget.h
  clang-tools-extra/clangd/unittests/FindTargetTests.cpp


Index: clang-tools-extra/clangd/unittests/FindTargetTests.cpp
===
--- clang-tools-extra/clangd/unittests/FindTargetTests.cpp
+++ clang-tools-extra/clangd/unittests/FindTargetTests.cpp
@@ -787,6 +787,47 @@
"template  struct B");
 }
 
+TEST_F(TargetDeclTest, TypedefCascade) {
+  Code = R"cpp(
+struct C {
+  using type = int;
+};
+struct B {
+  using type = C::type;
+};
+struct A {
+  using type = B::type;
+};
+A::[[type]] waldo;
+  )cpp";
+  EXPECT_DECLS("TypedefTypeLoc",
+   {"using type = int", Rel::Alias | Rel::Underlying},
+   {"using type = C::type", Rel::Alias | Rel::Underlying},
+   {"using type = B::type", Rel::Alias});
+}
+
+TEST_F(TargetDeclTest, RecursiveTemplate) {
+  Flags.push_back("-std=c++20"); // the test case uses concepts
+
+  Code = R"cpp(
+template 
+concept Leaf = false;
+
+template 
+struct descend_left {
+  using type = typename descend_left::[[type]];
+};
+
+template 
+struct descend_left {
+  using type = typename Tree::value;
+};
+  )cpp";
+  EXPECT_DECLS("DependentNameTypeLoc",
+   {"using type = typename descend_left::type",
+Rel::Alias | Rel::Underlying});
+}
+
 TEST_F(TargetDeclTest, ObjC) {
   Flags = {"-xobjective-c"};
   Code = R"cpp(
Index: clang-tools-extra/clangd/FindTarget.h
===
--- clang-tools-extra/clangd/FindTarget.h
+++ clang-tools-extra/clangd/FindTarget.h
@@ -194,6 +194,9 @@
 S &= Other.S;
 return *this;
   }
+  bool contains(DeclRelationSet Other) const {
+return (S & Other.S) == Other.S;
+  }
   friend llvm::raw_ostream &operator<<(llvm::raw_ostream &, DeclRelationSet);
 };
 // The above operators can't be looked up if both sides are enums.
Index: clang-tools-extra/clangd/FindTarget.cpp
===
--- clang-tools-extra/clangd/FindTarget.cpp
+++ clang-tools-extra/clangd/FindTarget.cpp
@@ -330,6 +330,7 @@
   llvm::SmallDenseMap>
   Decls;
+  llvm::SmallDenseMap Seen;
   RelSet Flags;
 
   template  void debug(T &Node, RelSet Flags) {
@@ -359,6 +360,15 @@
 if (!D)
   return;
 debug(*D, Flags);
+
+// Avoid recursion (which can arise in the presence of heuristic
+// resolution of dependent names) by exiting early if we have
+// already seen this decl with all flags in Flags.
+auto Res = Seen.try_emplace(D);
+if (!Res.second && Res.first->second.contains(Flags))
+  return;
+Res.first->second |= Flags;
+
 if (const UsingDirectiveDecl *UDD = llvm::dyn_cast(D))
   D = UDD->getNominatedNamespaceAsWritten();
 


Index: clang-tools-extra/clangd/unittests/FindTargetTests.cpp
===
--- clang-tools-extra/clangd/unittests/FindTargetTests.cpp
+++ clang-tools-extra/clangd/unittests/FindTargetTests.cpp
@@ -787,6 +787,47 @@
"template  struct B");
 }
 
+TEST_F(TargetDeclTest, TypedefCascade) {
+  Code = R"cpp(
+struct C {
+  using type = int;
+};
+struct B {
+  using type = C::type;
+};
+struct A {
+  using type = B::type;
+};
+A::[[type]] waldo;
+  )cpp";
+  EXPECT_DECLS("TypedefTypeLoc",
+   {"using type = int", Rel::Alias | Rel::Underlying},
+   {"using type = C::type", Rel::Alias | Rel::Underlying},
+   {"using type = B::type", Rel::Alias});
+}
+
+TEST_F(TargetDeclTest, RecursiveTemplate) {
+  Flags.push_back("-std=c++20"); // the test case uses concepts
+
+  Code = R"cpp(
+template 
+concept Leaf = false;
+
+template 
+struct descend_left {
+  using type = typename descend_left::[[type]];
+};
+
+template 
+struct descend_left {
+  using type = typename Tree::value;
+};
+  )cpp";
+  EXPECT_DECLS("DependentNameTypeLoc",
+   {"using type = typename descend_left::type",
+Rel::Alias | Rel::Underlying});
+}
+
 TEST_F(TargetDeclTest, ObjC) {
   Flags = {"-xobjective-c"};
   Code = R"cpp(
Index: clang-tools-extra/clangd/FindTarget.h
===
--- clang-tools-extra/clangd/FindTarget.h
+++ clang-tools-extra/clangd/FindTarget.h
@@ -194,6 +194,9 @@
 S &= Other.S;
 return *thi

[PATCH] D93525: [OpenMP] Add unbundling of archives containing bundled object files into device specific archives

2021-01-11 Thread Saiyedul Islam via Phabricator via cfe-commits
saiislam added a comment.

Ping.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93525

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


[PATCH] D94466: [X86] merge "={eax}" and "~{eax}" into "=&eax" for MSInlineASM

2021-01-11 Thread Freddy, Ye via Phabricator via cfe-commits
FreddyYe added inline comments.



Comment at: clang/lib/CodeGen/CGStmt.cpp:2488
+  if (Clobber == "eax") {
+std::string::size_type position = Constraints.find("={eax}");
+if (position != std::string::npos) {

pengfei wrote:
> `={eax}` is set in `X86_32TargetCodeGenInfo::addReturnRegisterOutputs`, which 
> also handles `EAX:EDX` case by `=A`. I think it's better handle it in the 
> function to cover the other case as well.
THX for review. Agree. I'll update.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94466

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


[PATCH] D94337: Add cuda header type for cuh files

2021-01-11 Thread Ryan Greenblatt via Phabricator via cfe-commits
rgreenblatt added a comment.

In D94337#2491825 , @tra wrote:

> 'Works' is not exactly the same as 'works correctly'. This example makes 
> `a()` look like a regular host function, instead of the kernel, and that 
> affects how the rest of the TU get parsed.
> I.e. you'll have further errors if somewhere down below the file has 
> `a<<<1,1>>>()`. Similar story with ignoring `__host__` and `__device__` 
> attributes -- that may lead to various overload resolution errors, or 
> reporting conflicting redeclarations/redefinitions for the perfectly valid 
> host/device function overloads. The list goes on.

No, this part is definitely working, the full set of SDK headers is included. I 
have confirmed this by compiling a .cu and a .cuh file with `-E` and checking 
that the output is identical. Further, I have confirmed that `global<<<_, 
_>>>()` builds, that `__host__` only functions can't be used on the device, and 
that `__device__` functions can't be used on the host.

I decided to go ahead and understand exactly what is going on when building 
with -x cuda-header
Prior to the last update I made, when compling a cuda-header this was roughly 
what was happening:

- Preprocess the header in host mode with type `TY_CUDAHeader`
- For each cuda arch, build with type `TY_CUDA_DEVICE`. This builds the header 
as though it was a .cu src file and this is where the `#pragma once` warnings 
were occuring.
- if -f-syntax only was used, exit here
- try to construct a fat binary and violently explode in a crash because the 
host mode was compiled with type `TY_CUDAHeader` instead of `TY_CUDA`. 
`TY_CUDAHeader` attempts to generate a precompiled header rather than a binary.

To fix this, I added a new type `TY_CUDAHeader_DEVICE`. This type precompiles a 
header for a specific device architecture. 
This type is used in place of TY_CUDA_DEVICE in the appropriate case. 
I think having a header devicetype is the correct approach if a separate header 
type is used.
Now compilation looks like this:

- Preprocess the header in host mode with type `TY_CUDAHeader`
- For each cuda arch, build with type `TY_CUDAHeader_DEVICE`. This doesn't 
issue a warning for #pragma once - it is correctly (I think) considering the 
file as a header.
- if -f-syntax only was used, exit here
- Output precompiled headers for the host and each cuda arch. For example: 
file.cuh-cuda-nvptx64-nvidia-cuda-sm_60.gch, 
file.cuh-cuda-nvptx64-nvidia-cuda-sm_75.gch, file.cuh.gch

As far as I can tell this process is now working as expected. 
Of course, there is no way to use these precompiled headers right now, so I 
have no idea if they are at all valid.
Also, I haven't run this with assertions enabled yet (waiting a build), so it 
might trip something.

I have tested that everything works as expected using the following header file:

  #pragma once
  
  __device__ int device_only() {
__syncthreads();
return 0;
  }
  
  __host__ int host_only() { return 1; }
  
  __host__ __device__ void check_all_archs() {
  #ifdef __CUDA_ARCH__
  #if __CUDA_ARCH__ == 750
  #pragma message "sm_75"
// host_only();
  #elif __CUDA_ARCH__ == 600
  #pragma message "sm_60"
// host_only();
  #else
  #pragma message "other sm"
// host_only();
  #endif
  #else
  #pragma message "host"
// device_only();
  #endif
  }
  
  __global__ void global() {
int out_device = device_only();
// int host_error = host_only();
  }
  
  void f() {
check_all_archs();
global<<<1, 1>>>();
  }

@tra I am guessing you have already thought about this, but
one thing which is worth noting is that language servers 
only maintain a single AST per file (and this probably won't change).
This is the host AST of course.
For example, in the above program language servers
will only have a diagnostic for `#pragma message "host"`.
So, the values of `--cuda-gpu-arch` aren't relevant for language servers
beyond determining what the preprocessor includes.
However, the fact that the preprocessor includes depend on arch
means that the __clang_cuda_standalone_defs.h approach won't always be perfectly
correct.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94337

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


[PATCH] D93668: [clang] Override the Fuchsia platform ABI using the triple environment

2021-01-11 Thread Petr Hosek via Phabricator via cfe-commits
phosek added a comment.

I agree that if we want to allow selecting C++ ABI only, a flag like 
`-fc++abi=` with some additional checks to disallow invalid combinations is 
better. The question is whether we want to allow that in the first place? The 
motivation behind this change is to support generating code that's ABI 
compatible with the code generated by GCC. That could be expressed using the 
target triple (one idea is to use `*-*-fuchsia-gnu`), which would cover both 
C++ ABI as well as other aspects of the ABI (for example it could also disable 
SafeStack/ShadowCallStack) so developers don't need to concern themselves with 
all the details of the ABI, which could evolve over time expanding the set of 
flags you'd need to pass to the compiler to generate code that's ABI compatible 
with GCC.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93668

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


[PATCH] D94466: [X86] merge "={eax}" and "~{eax}" into "=&eax" for MSInlineASM

2021-01-11 Thread Pengfei Wang via Phabricator via cfe-commits
pengfei added inline comments.



Comment at: clang/lib/CodeGen/CGStmt.cpp:2488
+  if (Clobber == "eax") {
+std::string::size_type position = Constraints.find("={eax}");
+if (position != std::string::npos) {

`={eax}` is set in `X86_32TargetCodeGenInfo::addReturnRegisterOutputs`, which 
also handles `EAX:EDX` case by `=A`. I think it's better handle it in the 
function to cover the other case as well.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94466

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


[PATCH] D84673: [clang][cli] Port DiagnosticOpts to new option parsing system

2021-01-11 Thread Jordan Rupprecht via Phabricator via cfe-commits
rupprecht added a comment.

I ran into this commit when integrating commits today (specifically, 
97100646d1b4526de1eac3aacdb0b098739c6ec9 
) -- 
there's nothing wrong with this patch AFAICT, but I'm wondering if the error 
messaging/handling could be improved somehow.

tl;dr I reduced an example in D94468 

We have an internal user creating a ToolInvocation and attaching a 
DiagnosticConsumer to it. They were also using `-ferror-limit=-1`, which if I 
understand now, may be meaningless -- `-ferror-limit=0` is used to mean 
"unlimited error messages", which is probably what they meant.

Anyway, with the DiagnosticConsumer attached, the test crashed with an 
assertion failure `"Assertion 'SourceMgr && "SourceManager not set!"` failed.", 
which really wasn't helpful at all. After much longer than I care to admit, I 
thought to remove the `setDiagnosticConsumer`, and was able to find the 
`"invalid integral value '-1' in '-ferror-limit -1'"` error in the logs, and I 
was able to find the real issue pretty quickly after that.

I don't think the usage was out of the ordinary, so I created D94468 
 as an example if you have time to take a 
look, to save the next person that may run into this issue.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84673

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


[PATCH] D94468: [test] Demonstrate bad error message

2021-01-11 Thread Jordan Rupprecht via Phabricator via cfe-commits
rupprecht created this revision.
rupprecht requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This should not be committed, but demonstrates an issue with cascading errors 
after D84673 .


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D94468

Files:
  clang/unittests/Tooling/ToolingTest.cpp


Index: clang/unittests/Tooling/ToolingTest.cpp
===
--- clang/unittests/Tooling/ToolingTest.cpp
+++ clang/unittests/Tooling/ToolingTest.cpp
@@ -221,6 +221,54 @@
   EXPECT_TRUE(Invocation.run());
 }
 
+class LogDiagnosticConsumer : public DiagnosticConsumer {
+public:
+  LogDiagnosticConsumer() = default;
+
+  void HandleDiagnostic(clang::DiagnosticsEngine::Level,
+const clang::Diagnostic &info) override {
+llvm::SmallString<40> diagnostic_string;
+
+info.FormatDiagnostic(diagnostic_string);
+Diagnostics += diagnostic_string.str();
+
+// The next expression triggers:
+//   Assertion `SourceMgr && "SourceManager not set!"' failed.
+// When commented out, will log the diagnostic as normal, which is an
+// invalid flag:
+//   "invalid integral value '-1' in '-ferror-limit -1'"
+info.getSourceManager();
+  }
+  std::string Diagnostics;
+};
+
+TEST(ToolInvocation, DiagCallback) {
+  llvm::IntrusiveRefCntPtr OverlayFileSystem(
+  new llvm::vfs::OverlayFileSystem(llvm::vfs::getRealFileSystem()));
+  llvm::IntrusiveRefCntPtr InMemoryFileSystem(
+  new llvm::vfs::InMemoryFileSystem);
+  OverlayFileSystem->pushOverlay(InMemoryFileSystem);
+  llvm::IntrusiveRefCntPtr Files(
+  new FileManager(FileSystemOptions(), OverlayFileSystem));
+  std::vector Args;
+  Args.push_back("tool-executable");
+  // Note: intentional error; user probably meant -ferror-limit=0.
+  Args.push_back("-ferror-limit=-1");
+  Args.push_back("-fsyntax-only");
+  Args.push_back("test.cpp");
+  clang::tooling::ToolInvocation Invocation(
+  Args, std::make_unique(), Files.get());
+  InMemoryFileSystem->addFile(
+  "test.cpp", 0, llvm::MemoryBuffer::getMemBuffer("int main(){}\n"));
+
+  LogDiagnosticConsumer LDC;
+  Invocation.setDiagnosticConsumer(&LDC);
+
+  EXPECT_TRUE(Invocation.run());
+
+  EXPECT_EQ("", LDC.Diagnostics);
+}
+
 struct VerifyEndCallback : public SourceFileCallbacks {
   VerifyEndCallback() : BeginCalled(0), EndCalled(0), Matched(false) {}
   bool handleBeginSource(CompilerInstance &CI) override {


Index: clang/unittests/Tooling/ToolingTest.cpp
===
--- clang/unittests/Tooling/ToolingTest.cpp
+++ clang/unittests/Tooling/ToolingTest.cpp
@@ -221,6 +221,54 @@
   EXPECT_TRUE(Invocation.run());
 }
 
+class LogDiagnosticConsumer : public DiagnosticConsumer {
+public:
+  LogDiagnosticConsumer() = default;
+
+  void HandleDiagnostic(clang::DiagnosticsEngine::Level,
+const clang::Diagnostic &info) override {
+llvm::SmallString<40> diagnostic_string;
+
+info.FormatDiagnostic(diagnostic_string);
+Diagnostics += diagnostic_string.str();
+
+// The next expression triggers:
+//   Assertion `SourceMgr && "SourceManager not set!"' failed.
+// When commented out, will log the diagnostic as normal, which is an
+// invalid flag:
+//   "invalid integral value '-1' in '-ferror-limit -1'"
+info.getSourceManager();
+  }
+  std::string Diagnostics;
+};
+
+TEST(ToolInvocation, DiagCallback) {
+  llvm::IntrusiveRefCntPtr OverlayFileSystem(
+  new llvm::vfs::OverlayFileSystem(llvm::vfs::getRealFileSystem()));
+  llvm::IntrusiveRefCntPtr InMemoryFileSystem(
+  new llvm::vfs::InMemoryFileSystem);
+  OverlayFileSystem->pushOverlay(InMemoryFileSystem);
+  llvm::IntrusiveRefCntPtr Files(
+  new FileManager(FileSystemOptions(), OverlayFileSystem));
+  std::vector Args;
+  Args.push_back("tool-executable");
+  // Note: intentional error; user probably meant -ferror-limit=0.
+  Args.push_back("-ferror-limit=-1");
+  Args.push_back("-fsyntax-only");
+  Args.push_back("test.cpp");
+  clang::tooling::ToolInvocation Invocation(
+  Args, std::make_unique(), Files.get());
+  InMemoryFileSystem->addFile(
+  "test.cpp", 0, llvm::MemoryBuffer::getMemBuffer("int main(){}\n"));
+
+  LogDiagnosticConsumer LDC;
+  Invocation.setDiagnosticConsumer(&LDC);
+
+  EXPECT_TRUE(Invocation.run());
+
+  EXPECT_EQ("", LDC.Diagnostics);
+}
+
 struct VerifyEndCallback : public SourceFileCallbacks {
   VerifyEndCallback() : BeginCalled(0), EndCalled(0), Matched(false) {}
   bool handleBeginSource(CompilerInstance &CI) override {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D93822: [clang][Sema] Add diagnostics for implicit widening of multiplication result

2021-01-11 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ added a comment.

> this would be a great flow-sensitive check for the clang static analyzer

You could indeed use static analyzer's path sensitivity to get rid of these 
obvious false positives where the multiplication is performed pretty much 
immediately after a branch (or assert) that avoids overflow, where "pretty much 
immediately" requires the static analyzer to encounter the overflow check while 
interpreting the function that contains the potential overflow. It's still not 
going to be good enough to be a good on-by-default checker because such checks 
may be performed either before the function is invoked, or in a nested function 
call for which the body is not immediately available in the translation unit. A 
good on-by-default checker could be achieved if taint analysis is added to the 
mixture (i.e., only check for overflows of values that are known to definitely 
be arbitrary) but that'd limit the power of the checker dramatically because 
such knowledge is rarely available (you may add annotations for that but that's 
probably a lot of work in your code).

Warnings with false positives may still be useful when they define a clear 
coding convention that you want the users to follow. In your case such 
convention seems to be "always use integer types that are wide enough to avoid 
overflows" and it says nothing about overflow checks being made, so i guess you 
don't absolutely need to bother with flow/path sensitivity. I think the answer 
should be data-driven. Does your codebase already contain overflow checks that 
cause false positives all over the place? If so, static analyzer to the rescue. 
If most of your multiplications are unchecked and you already rely on the 
integer type to be wide enough then you're probably good as-is.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93822

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


[PATCH] D94466: [X86] merge "={eax}" and "~{eax}" into "=&eax" for MSInlineASM

2021-01-11 Thread Freddy, Ye via Phabricator via cfe-commits
FreddyYe created this revision.
FreddyYe requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D94466

Files:
  clang/lib/CodeGen/CGStmt.cpp
  clang/test/CodeGen/ms-inline-asm.c
  clang/test/CodeGenCXX/ms-inline-asm-return.cpp


Index: clang/test/CodeGenCXX/ms-inline-asm-return.cpp
===
--- clang/test/CodeGenCXX/ms-inline-asm-return.cpp
+++ clang/test/CodeGenCXX/ms-inline-asm-return.cpp
@@ -23,7 +23,7 @@
   }
 }
 // CHECK-LABEL: define dso_local i32 @f_i32()
-// CHECK: %[[r:[^ ]*]] = call i32 asm sideeffect inteldialect "mov eax, 
$$1\0A\09mov edx, $$1", "={eax},~{eax},{{.*}}"
+// CHECK: %[[r:[^ ]*]] = call i32 asm sideeffect inteldialect "mov eax, 
$$1\0A\09mov edx, $$1", "=&{eax},{{.*}}"
 // CHECK: ret i32 %[[r]]
 
 short f_i16() {
@@ -33,7 +33,7 @@
   }
 }
 // CHECK-LABEL: define dso_local signext i16 @f_i16()
-// CHECK: %[[r:[^ ]*]] = call i32 asm sideeffect inteldialect "mov eax, 
$$1\0A\09mov edx, $$1", "={eax},~{eax},{{.*}}"
+// CHECK: %[[r:[^ ]*]] = call i32 asm sideeffect inteldialect "mov eax, 
$$1\0A\09mov edx, $$1", "=&{eax},{{.*}}"
 // CHECK: %[[r_i16:[^ ]*]] = trunc i32 %[[r]] to i16
 // CHECK: ret i16 %[[r_i16]]
 
@@ -44,7 +44,7 @@
   }
 }
 // CHECK-LABEL: define dso_local signext i8 @f_i8()
-// CHECK: %[[r:[^ ]*]] = call i32 asm sideeffect inteldialect "mov eax, 
$$1\0A\09mov edx, $$1", "={eax},~{eax},{{.*}}"
+// CHECK: %[[r:[^ ]*]] = call i32 asm sideeffect inteldialect "mov eax, 
$$1\0A\09mov edx, $$1", "=&{eax},{{.*}}"
 // CHECK: %[[r_i8:[^ ]*]] = trunc i32 %[[r]] to i8
 // CHECK: ret i8 %[[r_i8]]
 
@@ -55,7 +55,7 @@
   }
 }
 // CHECK-LABEL: define dso_local zeroext i1 @f_i1()
-// CHECK: %[[r:[^ ]*]] = call i32 asm sideeffect inteldialect "mov eax, 
$$1\0A\09mov edx, $$1", "={eax},~{eax},{{.*}}"
+// CHECK: %[[r:[^ ]*]] = call i32 asm sideeffect inteldialect "mov eax, 
$$1\0A\09mov edx, $$1", "=&{eax},{{.*}}"
 // CHECK: %[[r_i8:[^ ]*]] = trunc i32 %[[r]] to i8
 // CHECK: store i8 %[[r_i8]], i8* %{{.*}}
 // CHECK: %[[r_i1:[^ ]*]] = load i1, i1* %{{.*}}
@@ -70,7 +70,7 @@
   }
 }
 // CHECK-LABEL: define dso_local i32 @f_s4()
-// CHECK: %[[r:[^ ]*]] = call i32 asm sideeffect inteldialect "mov eax, 
$$16843009", "={eax},~{eax},{{.*}}"
+// CHECK: %[[r:[^ ]*]] = call i32 asm sideeffect inteldialect "mov eax, 
$$16843009", "=&{eax},{{.*}}"
 // CHECK: store i32 %[[r]], i32* %{{.*}}
 // CHECK: %[[r_i32:[^ ]*]] = load i32, i32* %{{.*}}
 // CHECK: ret i32 %[[r_i32]]
@@ -96,5 +96,5 @@
   __asm xor eax, eax
 }
 // CHECK-LABEL: define dso_local i32 @main()
-// CHECK: %[[r:[^ ]*]] = call i32 asm sideeffect inteldialect "xor eax, eax", 
"={eax},{{.*}}"
+// CHECK: %[[r:[^ ]*]] = call i32 asm sideeffect inteldialect "xor eax, eax", 
"=&{eax},{{.*}}"
 // CHECK: ret i32 %[[r]]
Index: clang/test/CodeGen/ms-inline-asm.c
===
--- clang/test/CodeGen/ms-inline-asm.c
+++ clang/test/CodeGen/ms-inline-asm.c
@@ -114,7 +114,7 @@
 // CHECK: call i32 asm sideeffect inteldialect
 // CHECK-SAME: mov eax, $2
 // CHECK-SAME: mov $0, eax
-// CHECK-SAME: "=*m,={eax},*m,~{eax},~{dirflag},~{fpsr},~{flags}"(i32* 
%{{.*}}, i32* %{{.*}})
+// CHECK-SAME: "=*m,=&{eax},*m,~{dirflag},~{fpsr},~{flags}"(i32* %{{.*}}, i32* 
%{{.*}})
 // CHECK: [[RET:%[a-zA-Z0-9]+]] = load i32, i32* [[J]], align 4
 // CHECK: ret i32 [[RET]]
 }
@@ -140,7 +140,7 @@
 // CHECK-SAME: mov $0, eax
 // CHECK-SAME: mov eax, $4
 // CHECK-SAME: mov $1, eax
-// CHECK-SAME: "=*m,=*m,={eax},*m,*m,~{eax},~{dirflag},~{fpsr},~{flags}"(i32* 
%{{.*}}, i32* %{{.*}}, i32* %{{.*}}, i32* %{{.*}})
+// CHECK-SAME: "=*m,=*m,=&{eax},*m,*m,~{dirflag},~{fpsr},~{flags}"(i32* 
%{{.*}}, i32* %{{.*}}, i32* %{{.*}}, i32* %{{.*}})
 }
 
 void t13() {
Index: clang/lib/CodeGen/CGStmt.cpp
===
--- clang/lib/CodeGen/CGStmt.cpp
+++ clang/lib/CodeGen/CGStmt.cpp
@@ -2483,6 +2483,15 @@
   }
 }
 
+if (isa(&S)) {
+  if (Clobber == "eax") {
+std::string::size_type position = Constraints.find("={eax}");
+if (position != std::string::npos) {
+  Constraints.insert(position + 1, "&");
+  break;
+}
+  }
+}
 if (!Constraints.empty())
   Constraints += ',';
 


Index: clang/test/CodeGenCXX/ms-inline-asm-return.cpp
===
--- clang/test/CodeGenCXX/ms-inline-asm-return.cpp
+++ clang/test/CodeGenCXX/ms-inline-asm-return.cpp
@@ -23,7 +23,7 @@
   }
 }
 // CHECK-LABEL: define dso_local i32 @f_i32()
-// CHECK: %[[r:[^ ]*]] = call i32 asm sideeffect inteldialect "mov eax, $$1\0A\09mov edx, $$1", "={eax},~{eax},{{.*}}"
+// CHECK: %[[r:[^ ]*]] = call i32 asm sideeffect inteldialect "mov eax, $$1\0A\09mov edx, $$1", "=&{eax},{{.*}}"
 // CHECK: ret i32 %[[r]]
 
 short f_i16() {
@@ -33,7 +33

[PATCH] D94438: Fis for Assertion failure on dependent expression.

2021-01-11 Thread Sunil Srivastava via Phabricator via cfe-commits
Sunil_Srivastava marked an inline comment as done.
Sunil_Srivastava added inline comments.



Comment at: clang/test/Sema/builtin-returnaddress.c:3
 // RUN: %clang_cc1 -fsyntax-only -Wmost -verify %s
+// RUN: %clang_cc1 -x c++ -fsyntax-only -Wframe-address -verify %s
+// RUN: %clang_cc1 -x c++ -fsyntax-only -Wmost -verify %s

erichkeane wrote:
> I don't think the -Wmost test 'RUN' line is valuable for the C++ mode, it is 
> simply validating that this diagnostic is in Wmost mode (which running in C 
> mode is sufficient).
Good point. I will remove that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94438

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


[PATCH] D94337: Add cuda header type for cuh files

2021-01-11 Thread Ryan Greenblatt via Phabricator via cfe-commits
rgreenblatt updated this revision to Diff 315986.
rgreenblatt added a comment.

Added CUDAHeader_DEVICE to propery handle split compilation


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94337

Files:
  clang/include/clang/Driver/Types.def
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/Types.cpp
  clang/lib/Sema/SemaCodeComplete.cpp
  clang/lib/Tooling/InterpolatingCompilationDatabase.cpp

Index: clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
===
--- clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
+++ clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
@@ -116,6 +116,8 @@
 return types::TY_ObjCXX;
   case types::TY_CUDA:
   case types::TY_CUDA_DEVICE:
+  case types::TY_CUDAHeader:
+  case types::TY_CUDAHeader_DEVICE:
 return types::TY_CUDA;
   default:
 return types::TY_INVALID;
Index: clang/lib/Sema/SemaCodeComplete.cpp
===
--- clang/lib/Sema/SemaCodeComplete.cpp
+++ clang/lib/Sema/SemaCodeComplete.cpp
@@ -9317,6 +9317,7 @@
   if (!(Filename.endswith_lower(".h") ||
 Filename.endswith_lower(".hh") ||
 Filename.endswith_lower(".hpp") ||
+Filename.endswith_lower(".cuh") ||
 Filename.endswith_lower(".inc")))
 break;
 }
Index: clang/lib/Driver/Types.cpp
===
--- clang/lib/Driver/Types.cpp
+++ clang/lib/Driver/Types.cpp
@@ -97,13 +97,28 @@
 
 bool types::canTypeBeUserSpecified(ID Id) {
   static const clang::driver::types::ID kStaticLangageTypes[] = {
-  TY_CUDA_DEVICE,   TY_HIP_DEVICE,TY_PP_CHeader,
-  TY_PP_ObjCHeader, TY_PP_CXXHeader,  TY_PP_ObjCXXHeader,
-  TY_PP_CXXModule,  TY_LTO_IR,TY_LTO_BC,
-  TY_Plist, TY_RewrittenObjC, TY_RewrittenLegacyObjC,
-  TY_Remap, TY_PCH,   TY_Object,
-  TY_Image, TY_dSYM,  TY_Dependencies,
-  TY_CUDA_FATBIN,   TY_HIP_FATBIN};
+  TY_CUDA_DEVICE,
+  TY_CUDAHeader_DEVICE,
+  TY_HIP_DEVICE,
+  TY_PP_CHeader,
+  TY_PP_ObjCHeader,
+  TY_PP_CXXHeader,
+  TY_PP_ObjCXXHeader,
+  TY_PP_CUDAHeader,
+  TY_PP_CXXModule,
+  TY_LTO_IR,
+  TY_LTO_BC,
+  TY_Plist,
+  TY_RewrittenObjC,
+  TY_RewrittenLegacyObjC,
+  TY_Remap,
+  TY_PCH,
+  TY_Object,
+  TY_Image,
+  TY_dSYM,
+  TY_Dependencies,
+  TY_CUDA_FATBIN,
+  TY_HIP_FATBIN};
   return !llvm::is_contained(kStaticLangageTypes, Id);
 }
 
@@ -129,6 +144,9 @@
   case TY_CL:
   case TY_CUDA: case TY_PP_CUDA:
   case TY_CUDA_DEVICE:
+  case TY_CUDAHeader:
+  case TY_PP_CUDAHeader:
+  case TY_CUDAHeader_DEVICE:
   case TY_HIP:
   case TY_PP_HIP:
   case TY_HIP_DEVICE:
@@ -171,6 +189,9 @@
   case TY_ObjCXXHeader: case TY_PP_ObjCXXHeader:
   case TY_CXXModule: case TY_PP_CXXModule:
   case TY_CUDA: case TY_PP_CUDA: case TY_CUDA_DEVICE:
+  case TY_CUDAHeader:
+  case TY_PP_CUDAHeader:
+  case TY_CUDAHeader_DEVICE:
   case TY_HIP:
   case TY_PP_HIP:
   case TY_HIP_DEVICE:
@@ -199,6 +220,9 @@
   case TY_CUDA:
   case TY_PP_CUDA:
   case TY_CUDA_DEVICE:
+  case TY_CUDAHeader:
+  case TY_PP_CUDAHeader:
+  case TY_CUDAHeader_DEVICE:
 return true;
   }
 }
@@ -231,65 +255,67 @@
 
 types::ID types::lookupTypeForExtension(llvm::StringRef Ext) {
   return llvm::StringSwitch(Ext)
-   .Case("c", TY_C)
-   .Case("C", TY_CXX)
-   .Case("F", TY_Fortran)
-   .Case("f", TY_PP_Fortran)
-   .Case("h", TY_CHeader)
-   .Case("H", TY_CXXHeader)
-   .Case("i", TY_PP_C)
-   .Case("m", TY_ObjC)
-   .Case("M", TY_ObjCXX)
-   .Case("o", TY_Object)
-   .Case("S", TY_Asm)
-   .Case("s", TY_PP_Asm)
-   .Case("bc", TY_LLVM_BC)
-   .Case("cc", TY_CXX)
-   .Case("CC", TY_CXX)
-   .Case("cl", TY_CL)
-   .Case("cp", TY_CXX)
-   .Case("cu", TY_CUDA)
-   .Case("hh", TY_CXXHeader)
-   .Case("ii", TY_PP_CXX)
-   .Case("ll", TY_LLVM_IR)
-   .Case("mi", TY_PP_ObjC)
-   .Case("mm", TY_ObjCXX)
-   .Case("rs", TY_RenderScript)
-   .Case("adb", TY_Ada)
-   .Case("ads", TY_Ada)
-   .Case("asm", TY_PP_Asm)
-   .Case("ast", TY_AST)
-   .Case("ccm", TY_CXXModule)
-   .Case("cpp", TY_CXX)
-   .Case("CPP", TY_CXX)
-   .Case("c++", TY_CXX)
-   .Case("C++", TY_CXX)
-   .Case("cui", TY_PP_CUDA)
-   .Case("cxx", TY_CXX)
-   .Case("CXX", TY_CXX)
-   .Case("F90", TY_Fortran)
-   .Case("f90", TY_PP_Fortran)
-   .Case("F95", TY_Fortran)
-   .Case("f95", TY_PP_Fortran)
-   .Case("for", TY_PP_Fortran)
-   .Case("FOR

[PATCH] D35388: [libc++] Give extern templates default visibility on gcc

2021-01-11 Thread Tom Anderson via Phabricator via cfe-commits
thomasanderson added a comment.

We appear to still be carrying a patch for this in Chromium, so I think the 
issue still stands.
https://source.chromium.org/chromium/chromium/src/+/master:buildtools/third_party/libc++/BUILD.gn;drc=21272efa27e69622c6d174f29e4a73f1a6088cfc;l=135


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D35388

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


[PATCH] D94463: [Driver] Make -fcs-profile-generate require -fprofile-use

2021-01-11 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay created this revision.
MaskRay added a reviewer: xur.
MaskRay requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This adds some tests missing in D54176  and 
disallows `-fcs-profile-generate` without `-fprofile-use`.

If conflicting `-fprofile-generate -fcs-profile-generate` are used together,
there is currently an assertion failure. Fix the failure.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D94463

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/fcs-profile-generate.c


Index: clang/test/Driver/fcs-profile-generate.c
===
--- /dev/null
+++ clang/test/Driver/fcs-profile-generate.c
@@ -0,0 +1,12 @@
+// RUN: %clang -### -c -fprofile-use=a.profdata -fcs-profile-generate %s 2>&1 
| FileCheck %s
+// CHECK:  "-fprofile-instrument=csllvm" 
"-fprofile-instrument-use-path=a.profdata"
+
+// RUN: %clang -### -c -fprofile-use=a.profdata -fcs-profile-generate=dir %s 
2>&1 | FileCheck %s --check-prefix=CHECK1
+// CHECK1: "-fprofile-instrument=csllvm" 
"-fprofile-instrument-path=dir/default_%m.profraw" 
"-fprofile-instrument-use-path=a.profdata"
+
+// RUN: %clang -### -c -fcs-profile-generate %s 2>&1 | FileCheck %s 
--check-prefix=NOUSE
+// NOUSE: error: invalid argument '-fcs-profile-generate' only allowed with 
'-fprofile-use'
+
+// RUN: %clang -### -c -fprofile-generate -fcs-profile-generate %s 2>&1 | 
FileCheck %s --check-prefix=CONFLICT
+// CONFLICT: error: invalid argument '-fcs-profile-generate' not allowed with 
'-fprofile-generate'
+// CONFLICT: error: invalid argument '-fcs-profile-generate' only allowed with 
'-fprofile-use'
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -766,9 +766,14 @@
 D.Diag(diag::err_drv_argument_not_allowed_with)
 << ProfileGenerateArg->getSpelling() << ProfileUseArg->getSpelling();
 
-  if (CSPGOGenerateArg && PGOGenerateArg)
+  if (CSPGOGenerateArg && PGOGenerateArg) {
 D.Diag(diag::err_drv_argument_not_allowed_with)
 << CSPGOGenerateArg->getSpelling() << PGOGenerateArg->getSpelling();
+PGOGenerateArg = nullptr;
+  }
+  if (CSPGOGenerateArg && !ProfileUseArg)
+D.Diag(diag::err_drv_argument_only_allowed_with)
+<< CSPGOGenerateArg->getSpelling() << "-fprofile-use";
 
   if (ProfileGenerateArg) {
 if (ProfileGenerateArg->getOption().matches(


Index: clang/test/Driver/fcs-profile-generate.c
===
--- /dev/null
+++ clang/test/Driver/fcs-profile-generate.c
@@ -0,0 +1,12 @@
+// RUN: %clang -### -c -fprofile-use=a.profdata -fcs-profile-generate %s 2>&1 | FileCheck %s
+// CHECK:  "-fprofile-instrument=csllvm" "-fprofile-instrument-use-path=a.profdata"
+
+// RUN: %clang -### -c -fprofile-use=a.profdata -fcs-profile-generate=dir %s 2>&1 | FileCheck %s --check-prefix=CHECK1
+// CHECK1: "-fprofile-instrument=csllvm" "-fprofile-instrument-path=dir/default_%m.profraw" "-fprofile-instrument-use-path=a.profdata"
+
+// RUN: %clang -### -c -fcs-profile-generate %s 2>&1 | FileCheck %s --check-prefix=NOUSE
+// NOUSE: error: invalid argument '-fcs-profile-generate' only allowed with '-fprofile-use'
+
+// RUN: %clang -### -c -fprofile-generate -fcs-profile-generate %s 2>&1 | FileCheck %s --check-prefix=CONFLICT
+// CONFLICT: error: invalid argument '-fcs-profile-generate' not allowed with '-fprofile-generate'
+// CONFLICT: error: invalid argument '-fcs-profile-generate' only allowed with '-fprofile-use'
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -766,9 +766,14 @@
 D.Diag(diag::err_drv_argument_not_allowed_with)
 << ProfileGenerateArg->getSpelling() << ProfileUseArg->getSpelling();
 
-  if (CSPGOGenerateArg && PGOGenerateArg)
+  if (CSPGOGenerateArg && PGOGenerateArg) {
 D.Diag(diag::err_drv_argument_not_allowed_with)
 << CSPGOGenerateArg->getSpelling() << PGOGenerateArg->getSpelling();
+PGOGenerateArg = nullptr;
+  }
+  if (CSPGOGenerateArg && !ProfileUseArg)
+D.Diag(diag::err_drv_argument_only_allowed_with)
+<< CSPGOGenerateArg->getSpelling() << "-fprofile-use";
 
   if (ProfileGenerateArg) {
 if (ProfileGenerateArg->getOption().matches(
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D94337: Add cuda header type for cuh files

2021-01-11 Thread Artem Belevich via Phabricator via cfe-commits
tra added a comment.

In D94337#2491761 , @rgreenblatt wrote:

> For example consider the following header:
>
>   #pragma once
>   
>   __global__ void a() {
> unsigned block_idx = blockIdx.x;
> unsigned thread_idx = threadIdx.x;
>   
> __shfl_down_sync(1, 2, 1);
>   }
>
> When saved as a .cuh and compiled as `clang++ file.cuh -fsyntax-only 
> --cuda-gpu-arch=sm_75` (using clang++ built from this commit), this works 
> fine other than an invalid diagnostic for the #pragma once.

'Works' is not exactly the same as 'works correctly'. This example makes `a()` 
look like a regular host function, instead of the kernel, and that affects how 
the rest of the TU get parsed.
I.e. you'll have further errors if somewhere down below the file has 
`a<<<1,1>>>()`. Similar story with ignoring `__host__` and `__device__` 
attributes -- that may lead to various overload resolution errors, or reporting 
conflicting redeclarations/redefinitions for the perfectly valid host/device 
function overloads. The list goes on.

> Obviously there are several errors when building this with -x c++-header.
> The reason why this "works" is because of the change to Driver.cpp. This 
> change makes it so that -x cuda-header is handeled similarly (identically?) 
> to that of -x cuda.
> Further changes to Driver.cpp will need to happen to avoid warning about 
> #pragma once and (if desired) to actually output a precompiled header.

CUDA compilation in clang rather heavily depends on compiler understanding 
CUDA-related attributes and those come from the header files. You can make some 
things work without those attributes, but you will have more cases where you'll 
get wrong results ranging from slightly wrong to mostly wrong. :-/ If you're 
curious, search for CUDA in `lib/Sema/` and you'll see plenty of places where 
CUDA attributes affect how compiler interprets the sources.

>>> A secondary goal was to make it so that header tab completion recognizes 
>>> .cuh files.
>>> This change doesn't depend on the other changes - it only requires a minor 
>>> edit to clang/lib/Sema/SemaCodeComplete.cpp.
>
>
>
>> Maybe. It depends on how well clang can recover from the errors induced by 
>> the unexpanded CUDA macros. This could range from OK on simple code to 
>> rather badly if we fail to instantiate templated code.
>
> I am pretty sure that header tab completion is totally unrelated to the 
> syntactic validity of headers; it's just finding the list of files in the 
> include path which match the text entered so far and then filtering out files 
> without a accepted extension. This change just adds ".cuh" to the list of 
> acceptable extensions.

SGTM. I'm not against the change. It's just the patch does too much 
(automatically inferring thet .cuh is a CUDA file) and not enough (does not 
really handle stand-alone CUDA headers in consistent manner).
I'm fine adding CUDA header kind, but without automatic inference of the type 
via extension. E.g. assigning a `cuda-headers-are-not-really-supported-yet` as 
an extension would address my concern, while allowing the tools or interested 
users to use `-x cuda-header` if they need it.

>> We may not need the special CUDA header type after that. The tooling 
>> heuristic should be able to deal with detecting whether it deals with CUDA 
>> sources better than clang -- compilation database + user input should help. 
>> If/when tooling knows it deals with CUDA, it can tell so to clang with -x 
>> cuda.
>
> This seems like a decent approach to me, but this will result in incorrectly 
> issuing a diagnostic for #pragma once.

`#pragma once` has been biting me with tooling used on C++ headers, too, so I 
suspect it's not a CUDA-specific issue.

> This can of course be fixed by directly disabling the warning, but this does 
> seem a bit hacky. There may also be other header specific behavior, but I 
> can't think of any.
> On the whole, it does seem a bit gross for tooling to have to compile headers 
> as though they are main files.

I'm not sure if it should matter much if we only care about `-fsyntax-only`. 
The warning for `#pragma once` is a rather unusual case where the distinction 
does matter. Introducing a whole new file kind just to work around the warning 
looks even more hacky than silencing the warning to me. :-/
In any case, just adding a file kind is simple enough. I'm OK with it as long 
as we have a way not to expose it to the end-users by default until we can make 
clang's behavior for that data type sensible.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94337

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


[PATCH] D94337: Add cuda header type for cuh files

2021-01-11 Thread Ryan Greenblatt via Phabricator via cfe-commits
rgreenblatt added a comment.

In D94337#2491515 , @tra wrote:

> Does it make sense?

Yep, most of what your saying makes sense to me. Thanks for taking the time to 
review this.

A few notes:

> That would still require properly defined CUDA macros. CUDA in clang relies 
> on various CUDA attributes, currently wrapped in 
> `__{host|device|global|etc.}__` macros in order to compile the code. Without 
> them, `-fsyntax-only` will not be give you correct results on most of the 
> CUDA code.
> Most likely you'll see tons of errors when compiler sees `__device__` and has 
> no idea what to do with it. Hence my suggestion that clang needs at least a 
> minimum subset of CUDA headers to provide the critical subset of macros 
> sufficient to convey critical semantics of CUDA code.

Actually this already works (roughly) with the changes made so far. 
For example consider the following header:

  #pragma once
  
  __global__ void a() {
unsigned block_idx = blockIdx.x;
unsigned thread_idx = threadIdx.x;
  
__shfl_down_sync(1, 2, 1);
  }

When saved as a .cuh and compiled as `clang++ file.cuh -fsyntax-only 
--cuda-gpu-arch=sm_75` (using clang++ built from this commit), this works fine 
other than an invalid diagnostic for the #pragma once.
Obviously there are several errors when building this with -x c++-header.
The reason why this "works" is because of the change to Driver.cpp. This change 
makes it so that -x cuda-header is similar (identical?) to that of -x cuda.
Further changes to Driver.cpp will need to happen to avoid warning about 
#pragma once and (if desired) to actually output a precompiled header.

>> A secondary goal was to make it so that header tab completion recognizes 
>> .cuh files.
>> This change doesn't depend on the other changes - it only requires a minor 
>> edit to clang/lib/Sema/SemaCodeComplete.cpp.



> Maybe. It depends on how well clang can recover from the errors induced by 
> the unexpanded CUDA macros. This could range from OK on simple code to rather 
> badly if we fail to instantiate templated code.

I am pretty sure that header tab completion is totally unrelated to the 
syntactic validity of headers; it's just finding the list of files in the 
include path which match the text entered so far and then filtering out files 
without a accepted extension. This change just adds ".cuh" to the list of 
acceptable extensions.

> We may not need the special CUDA header type after that. The tooling 
> heuristic should be able to deal with detecting whether it deals with CUDA 
> sources better than clang -- compilation database + user input should help. 
> If/when tooling knows it deals with CUDA, it can tell so to clang with -x 
> cuda.

This seems like a decent approach to me, but this will result in incorrectly 
issuing a diagnostic for #pragma once.
This can of course be fixed by directly disabling the warning, but this does 
seem a bit hacky. There may also be other header specific behavior, but I can't 
think of any.
On the whole, it does seem a bit gross for tooling to have to compile headers 
as though they are main files.




Comment at: clang/lib/Driver/Driver.cpp:2466
 if (!(IA->getType() == types::TY_CUDA ||
+  IA->getType() == types::TY_CUDAHeader ||
   IA->getType() == types::TY_HIP ||

From my understanding this basically makes the treatment of TY_CUDAHeader 
(-xcuda-header)  identical to TY_CUDA (-xcuda).
Some changes will need to happen below this for correct handling of header 
files (for example not warning about using #pragma once).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94337

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


[PATCH] D93999: [clang] Fix message text for `-Wpointer-sign` to account for plain char

2021-01-11 Thread Hubert Tong via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGc6ffe4d76fbf: [clang] Fix message text for `-Wpointer-sign` 
to account for plain char (authored by hubert.reinterpretcast).

Changed prior to commit:
  https://reviews.llvm.org/D93999?vs=315648&id=315956#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93999

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaExpr.cpp
  clang/test/Sema/incompatible-sign.c
  clang/test/Sema/incompatible-sign.cpp
  clang/test/SemaObjC/objc-cf-audited-warning.m

Index: clang/test/SemaObjC/objc-cf-audited-warning.m
===
--- clang/test/SemaObjC/objc-cf-audited-warning.m
+++ clang/test/SemaObjC/objc-cf-audited-warning.m
@@ -20,5 +20,5 @@
 
 void saveImageToJPG(const char *filename)
 {
-CFURLRef url = CFURLCreateFromFileSystemRepresentation(kCFAllocatorDefault, filename, 10, 0); // expected-warning {{passing 'const char *' to parameter of type 'const UInt8 *' (aka 'const unsigned char *') converts between pointers to integer types with different sign}}
+CFURLRef url = CFURLCreateFromFileSystemRepresentation(kCFAllocatorDefault, filename, 10, 0); // expected-warning {{passing 'const char *' to parameter of type 'const UInt8 *' (aka 'const unsigned char *') converts between pointers to integer types where one is of the unique plain 'char' type and the other is not}}
 }
Index: clang/test/Sema/incompatible-sign.cpp
===
--- clang/test/Sema/incompatible-sign.cpp
+++ clang/test/Sema/incompatible-sign.cpp
@@ -4,11 +4,11 @@
 void plainToSigned() {
   extern char c;
   signed char *p;
-  p = &c; // expected-error {{converts between pointers to integer types with different sign}}
+  p = &c; // expected-error {{converts between pointers to integer types where one is of the unique plain 'char' type and the other is not}}
 }
 
 void unsignedToPlain() {
   extern unsigned char uc;
   char *p;
-  p = &uc; // expected-error {{converts between pointers to integer types with different sign}}
+  p = &uc; // expected-error {{converts between pointers to integer types where one is of the unique plain 'char' type and the other is not}}
 }
Index: clang/test/Sema/incompatible-sign.c
===
--- clang/test/Sema/incompatible-sign.c
+++ clang/test/Sema/incompatible-sign.c
@@ -6,18 +6,18 @@
 
 signed char *plainCharToSignedChar(signed char *arg) { // expected-note{{passing argument to parameter}}
   extern char c;
-  signed char *p = &c; // expected-warning {{converts between pointers to integer types with different sign}}
-  struct { signed char *p; } s = { &c }; // expected-warning {{converts between pointers to integer types with different sign}}
-  p = &c; // expected-warning {{converts between pointers to integer types with different sign}}
-  plainCharToSignedChar(&c); // expected-warning {{converts between pointers to integer types with different sign}}
-  return &c; // expected-warning {{converts between pointers to integer types with different sign}}
+  signed char *p = &c; // expected-warning {{converts between pointers to integer types where one is of the unique plain 'char' type and the other is not}}
+  struct { signed char *p; } s = { &c }; // expected-warning {{converts between pointers to integer types where one is of the unique plain 'char' type and the other is not}}
+  p = &c; // expected-warning {{converts between pointers to integer types where one is of the unique plain 'char' type and the other is not}}
+  plainCharToSignedChar(&c); // expected-warning {{converts between pointers to integer types where one is of the unique plain 'char' type and the other is not}}
+  return &c; // expected-warning {{converts between pointers to integer types where one is of the unique plain 'char' type and the other is not}}
 }
 
 char *unsignedCharToPlainChar(char *arg) { // expected-note{{passing argument to parameter}}
   extern unsigned char uc[];
-  char *p = uc; // expected-warning {{converts between pointers to integer types with different sign}}
-  (void) (char *[]){ [42] = uc }; // expected-warning {{converts between pointers to integer types with different sign}}
-  p = uc; // expected-warning {{converts between pointers to integer types with different sign}}
-  unsignedCharToPlainChar(uc); // expected-warning {{converts between pointers to integer types with different sign}}
-  return uc; // expected-warning {{converts between pointers to integer types with different sign}}
+  char *p = uc; // expected-warning {{converts between pointers to integer types where one is of the unique plain 'char' type and the other is not}}
+  (void) (char *[]){ [42] = uc }; // expected-warning {{converts between pointers to integer types where one is of the unique 

[clang] c6ffe4d - [clang] Fix message text for `-Wpointer-sign` to account for plain char

2021-01-11 Thread Hubert Tong via cfe-commits

Author: Hubert Tong
Date: 2021-01-11T18:41:14-05:00
New Revision: c6ffe4d76fbf6ae505c0abccaf29017414265e32

URL: 
https://github.com/llvm/llvm-project/commit/c6ffe4d76fbf6ae505c0abccaf29017414265e32
DIFF: 
https://github.com/llvm/llvm-project/commit/c6ffe4d76fbf6ae505c0abccaf29017414265e32.diff

LOG: [clang] Fix message text for `-Wpointer-sign` to account for plain char

The `-Wpointer-sign` warning text is inappropriate for describing the
incompatible pointer conversion between plain `char` and explicitly
`signed`/`unsigned` `char` (whichever plain `char` has the same range
as) and vice versa.

Specifically, in part, it reads "converts between pointers to integer
types with different sign". This patch changes that portion to read
instead as "converts between pointers to integer types where one is of
the unique plain 'char' type and the other is not" when one of the types
is plain `char`.

C17 subclause 6.5.16.1 indicates that the conversions resulting in
`-Wpointer-sign` warnings in assignment-like contexts are constraint
violations. This means that strict conformance requires a diagnostic for
the case where the message text is wrong before this patch. The lack of
an even more specialized warning group is consistent with GCC.

Reviewed By: aaron.ballman

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

Added: 


Modified: 
clang/include/clang/Basic/DiagnosticSemaKinds.td
clang/lib/Sema/SemaExpr.cpp
clang/test/Sema/incompatible-sign.c
clang/test/Sema/incompatible-sign.cpp
clang/test/SemaObjC/objc-cf-audited-warning.m

Removed: 




diff  --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index c048fc89813f..19b003398b02 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -7814,21 +7814,11 @@ def ext_typecheck_convert_incompatible_pointer_sign : 
ExtWarn<
   "|%
diff {sending $ to parameter of type $|"
   "sending to parameter of 
diff erent type}0,1"
   "|%
diff {casting $ to type $|casting between types}0,1}2"
-  " converts between pointers to integer types with 
diff erent sign">,
+  " converts between pointers to integer types %select{with 
diff erent sign|"
+  "where one is of the unique plain 'char' type and the other is not}3">,
   InGroup>;
-def err_typecheck_convert_incompatible_pointer_sign : Error<
-  "%select{%
diff {assigning to $ from $|assigning to 
diff erent types}0,1"
-  "|%
diff {passing $ to parameter of type $|"
-  "passing to parameter of 
diff erent type}0,1"
-  "|%
diff {returning $ from a function with result type $|"
-  "returning from function with 
diff erent return type}0,1"
-  "|%
diff {converting $ to type $|converting between types}0,1"
-  "|%
diff {initializing $ with an expression of type $|"
-  "initializing with expression of 
diff erent type}0,1"
-  "|%
diff {sending $ to parameter of type $|"
-  "sending to parameter of 
diff erent type}0,1"
-  "|%
diff {casting $ to type $|casting between types}0,1}2"
-  " converts between pointers to integer types with 
diff erent sign">;
+def err_typecheck_convert_incompatible_pointer_sign :
+  Error;
 def ext_typecheck_convert_incompatible_pointer : ExtWarn<
   "incompatible pointer types "
   "%select{%
diff {assigning to $ from $|assigning to 
diff erent types}0,1"

diff  --git a/clang/lib/Sema/SemaExpr.cpp b/clang/lib/Sema/SemaExpr.cpp
index da555c95eaf0..571c4fb091ab 100644
--- a/clang/lib/Sema/SemaExpr.cpp
+++ b/clang/lib/Sema/SemaExpr.cpp
@@ -15962,6 +15962,16 @@ bool Sema::DiagnoseAssignmentResult(AssignConvertType 
ConvTy,
   else
 FDiag << FirstType << SecondType << Action << SrcExpr->getSourceRange();
 
+  if (DiagKind == diag::ext_typecheck_convert_incompatible_pointer_sign ||
+  DiagKind == diag::err_typecheck_convert_incompatible_pointer_sign) {
+auto isPlainChar = [](const clang::Type *Type) {
+  return Type->isSpecificBuiltinType(BuiltinType::Char_S) ||
+ Type->isSpecificBuiltinType(BuiltinType::Char_U);
+};
+FDiag << (isPlainChar(FirstType->getPointeeOrArrayElementType()) ||
+  isPlainChar(SecondType->getPointeeOrArrayElementType()));
+  }
+
   // If we can fix the conversion, suggest the FixIts.
   if (!ConvHints.isNull()) {
 for (FixItHint &H : ConvHints.Hints)

diff  --git a/clang/test/Sema/incompatible-sign.c 
b/clang/test/Sema/incompatible-sign.c
index 74e8b5dcc1fc..64c93d1e5920 100644
--- a/clang/test/Sema/incompatible-sign.c
+++ b/clang/test/Sema/incompatible-sign.c
@@ -6,18 +6,18 @@ int b(unsigned* y) { return a(y); } // expected-warning 
{{passing 'unsigned int
 
 signed char *plainCharToSignedChar(signed char *arg) { // 
expected-note{{passing argument to parameter}}
   extern char c;
-  signed char *p = &c; // expected-warning {{converts between pointers to 
integer types with 
diff erent sign}}
-  struct { signed ch

[clang] f635bcd - NFC: Pre-commit test: -Wpointer-sign with plain char to [un]signed char

2021-01-11 Thread Hubert Tong via cfe-commits

Author: Hubert Tong
Date: 2021-01-11T18:41:14-05:00
New Revision: f635bcd16105a0a01eefa2c69a71cd103dedaddd

URL: 
https://github.com/llvm/llvm-project/commit/f635bcd16105a0a01eefa2c69a71cd103dedaddd
DIFF: 
https://github.com/llvm/llvm-project/commit/f635bcd16105a0a01eefa2c69a71cd103dedaddd.diff

LOG: NFC: Pre-commit test: -Wpointer-sign with plain char to [un]signed char

Add tests with bad message text for `-Wpointer-sign` and run them with
both signed and unsigned versions of plain `char`.

Added: 
clang/test/Sema/incompatible-sign.cpp

Modified: 
clang/test/Sema/incompatible-sign.c

Removed: 




diff  --git a/clang/test/Sema/incompatible-sign.c 
b/clang/test/Sema/incompatible-sign.c
index 6249feb6b1e7..74e8b5dcc1fc 100644
--- a/clang/test/Sema/incompatible-sign.c
+++ b/clang/test/Sema/incompatible-sign.c
@@ -1,5 +1,23 @@
 // RUN: %clang_cc1 %s -verify -fsyntax-only
+// RUN: %clang_cc1 %s -verify -fsyntax-only -fno-signed-char
 
 int a(int* x); // expected-note{{passing argument to parameter 'x' here}}
 int b(unsigned* y) { return a(y); } // expected-warning {{passing 'unsigned 
int *' to parameter of type 'int *' converts between pointers to integer types 
with 
diff erent sign}}
 
+signed char *plainCharToSignedChar(signed char *arg) { // 
expected-note{{passing argument to parameter}}
+  extern char c;
+  signed char *p = &c; // expected-warning {{converts between pointers to 
integer types with 
diff erent sign}}
+  struct { signed char *p; } s = { &c }; // expected-warning {{converts 
between pointers to integer types with 
diff erent sign}}
+  p = &c; // expected-warning {{converts between pointers to integer types 
with 
diff erent sign}}
+  plainCharToSignedChar(&c); // expected-warning {{converts between pointers 
to integer types with 
diff erent sign}}
+  return &c; // expected-warning {{converts between pointers to integer types 
with 
diff erent sign}}
+}
+
+char *unsignedCharToPlainChar(char *arg) { // expected-note{{passing argument 
to parameter}}
+  extern unsigned char uc[];
+  char *p = uc; // expected-warning {{converts between pointers to integer 
types with 
diff erent sign}}
+  (void) (char *[]){ [42] = uc }; // expected-warning {{converts between 
pointers to integer types with 
diff erent sign}}
+  p = uc; // expected-warning {{converts between pointers to integer types 
with 
diff erent sign}}
+  unsignedCharToPlainChar(uc); // expected-warning {{converts between pointers 
to integer types with 
diff erent sign}}
+  return uc; // expected-warning {{converts between pointers to integer types 
with 
diff erent sign}}
+}

diff  --git a/clang/test/Sema/incompatible-sign.cpp 
b/clang/test/Sema/incompatible-sign.cpp
new file mode 100644
index ..ebe7585b81e0
--- /dev/null
+++ b/clang/test/Sema/incompatible-sign.cpp
@@ -0,0 +1,14 @@
+// RUN: %clang_cc1 %s -verify -fsyntax-only
+// RUN: %clang_cc1 %s -verify -fsyntax-only -fno-signed-char
+
+void plainToSigned() {
+  extern char c;
+  signed char *p;
+  p = &c; // expected-error {{converts between pointers to integer types with 
diff erent sign}}
+}
+
+void unsignedToPlain() {
+  extern unsigned char uc;
+  char *p;
+  p = &uc; // expected-error {{converts between pointers to integer types with 
diff erent sign}}
+}



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


[PATCH] D93668: [clang] Override the Fuchsia platform ABI using the triple environment

2021-01-11 Thread Leonard Chan via Phabricator via cfe-commits
leonardchan updated this revision to Diff 315951.
leonardchan retitled this revision from "[clang] Add -ffuchsia-c++-abi flag to 
explicitly use the Fuchsia C++ ABI" to "[clang] Override the Fuchsia platform 
ABI using the triple environment".
leonardchan edited the summary of this revision.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93668

Files:
  clang/include/clang/AST/ASTContext.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/CodeGen/ItaniumCXXABI.cpp
  clang/test/CodeGenCXX/constructor-destructor-return-this.cpp

Index: clang/test/CodeGenCXX/constructor-destructor-return-this.cpp
===
--- clang/test/CodeGenCXX/constructor-destructor-return-this.cpp
+++ clang/test/CodeGenCXX/constructor-destructor-return-this.cpp
@@ -5,6 +5,8 @@
 //RUN:   | FileCheck --check-prefix=CHECKARM %s
 //RUN: %clang_cc1 %s -emit-llvm -o - -triple=x86_64-unknown-fuchsia | FileCheck --check-prefix=CHECKFUCHSIA %s
 //RUN: %clang_cc1 %s -emit-llvm -o - -triple=aarch64-unknown-fuchsia | FileCheck --check-prefix=CHECKFUCHSIA %s
+//RUN: %clang_cc1 %s -emit-llvm -o - -triple=x86_64-unknown-fuchsia-gnu | FileCheck --check-prefix=CHECKGEN_64 %s
+//RUN: %clang_cc1 %s -emit-llvm -o - -triple=aarch64-unknown-fuchsia-gnu | FileCheck --check-prefix=CHECKGEN_64 %s
 //RUN: %clang_cc1 %s -emit-llvm -o - -triple=i386-pc-win32 -fno-rtti | FileCheck --check-prefix=CHECKMS %s
 // FIXME: these tests crash on the bots when run with -triple=x86_64-pc-win32
 
@@ -52,6 +54,11 @@
 // CHECKFUCHSIA-LABEL: define{{.*}} %class.B* @_ZN1BD2Ev(%class.B* {{[^,]*}} returned {{[^,]*}} %this)
 // CHECKFUCHSIA-LABEL: define{{.*}} %class.B* @_ZN1BD1Ev(%class.B* {{[^,]*}} returned {{[^,]*}} %this)
 
+// CHECKGEN_64-LABEL: define{{.*}} void @_ZN1BC2EPi(%class.B* {{[^,]*}} %this, i32* %i)
+// CHECKGEN_64-LABEL: define{{.*}} void @_ZN1BC1EPi(%class.B* {{[^,]*}} %this, i32* %i)
+// CHECKGEN_64-LABEL: define{{.*}} void @_ZN1BD2Ev(%class.B* {{[^,]*}} %this)
+// CHECKGEN_64-LABEL: define{{.*}} void @_ZN1BD1Ev(%class.B* {{[^,]*}} %this)
+
 // CHECKMS-LABEL: define dso_local x86_thiscallcc %class.B* @"??0B@@QAE@PAH@Z"(%class.B* {{[^,]*}} returned {{[^,]*}} %this, i32* %i)
 // CHECKMS-LABEL: define dso_local x86_thiscallcc void @"??1B@@UAE@XZ"(%class.B* {{[^,]*}} %this)
 
@@ -98,6 +105,14 @@
 // CHECKFUCHSIA-LABEL: define{{.*}} void @_ZN1CD0Ev(%class.C* {{[^,]*}} %this)
 // CHECKFUCHSIA-LABEL: define{{.*}} void @_ZThn16_N1CD0Ev(%class.C* {{[^,]*}} %this)
 
+// CHECKGEN_64-LABEL: define{{.*}} void @_ZN1CC2EPiPc(%class.C* {{[^,]*}} %this, i32* %i, i8* %c)
+// CHECKGEN_64-LABEL: define{{.*}} void @_ZN1CC1EPiPc(%class.C* {{[^,]*}} %this, i32* %i, i8* %c)
+// CHECKGEN_64-LABEL: define{{.*}} void @_ZN1CD2Ev(%class.C* {{[^,]*}} %this)
+// CHECKGEN_64-LABEL: define{{.*}} void @_ZN1CD1Ev(%class.C* {{[^,]*}} %this)
+// CHECKGEN_64-LABEL: define{{.*}} void @_ZThn16_N1CD1Ev(%class.C* {{[^,]*}} %this)
+// CHECKGEN_64-LABEL: define{{.*}} void @_ZN1CD0Ev(%class.C* {{[^,]*}} %this)
+// CHECKGEN_64-LABEL: define{{.*}} void @_ZThn16_N1CD0Ev(%class.C* {{[^,]*}} %this)
+
 // CHECKMS-LABEL: define dso_local x86_thiscallcc %class.C* @"??0C@@QAE@PAHPAD@Z"(%class.C* {{[^,]*}} returned {{[^,]*}} %this, i32* %i, i8* %c)
 // CHECKMS-LABEL: define dso_local x86_thiscallcc void @"??1C@@UAE@XZ"(%class.C* {{[^,]*}} %this)
 
@@ -130,6 +145,11 @@
 // CHECKFUCHSIA-LABEL: define{{.*}} %class.D* @_ZN1DD2Ev(%class.D* {{[^,]*}} returned {{[^,]*}} %this, i8** %vtt)
 // CHECKFUCHSIA-LABEL: define{{.*}} %class.D* @_ZN1DD1Ev(%class.D* {{[^,]*}} returned {{[^,]*}} %this)
 
+// CHECKGEN_64-LABEL: define{{.*}} void @_ZN1DC2Ev(%class.D* {{[^,]*}} %this, i8** %vtt)
+// CHECKGEN_64-LABEL: define{{.*}} void @_ZN1DC1Ev(%class.D* {{[^,]*}} %this)
+// CHECKGEN_64-LABEL: define{{.*}} void @_ZN1DD2Ev(%class.D* {{[^,]*}} %this, i8** %vtt)
+// CHECKGEN_64-LABEL: define{{.*}} void @_ZN1DD1Ev(%class.D* {{[^,]*}} %this)
+
 // CHECKMS-LABEL: define dso_local x86_thiscallcc %class.D* @"??0D@@QAE@XZ"(%class.D* {{[^,]*}} returned {{[^,]*}} %this, i32 %is_most_derived)
 // CHECKMS-LABEL: define dso_local x86_thiscallcc void @"??1D@@UAE@XZ"(%class.D* {{[^,]*}} %this)
 
Index: clang/lib/CodeGen/ItaniumCXXABI.cpp
===
--- clang/lib/CodeGen/ItaniumCXXABI.cpp
+++ clang/lib/CodeGen/ItaniumCXXABI.cpp
@@ -543,7 +543,7 @@
 }
 
 CodeGen::CGCXXABI *CodeGen::CreateItaniumCXXABI(CodeGenModule &CGM) {
-  switch (CGM.getTarget().getCXXABI().getKind()) {
+  switch (CGM.getContext().getCXXABIKind()) {
   // For IR-generation purposes, there's no significant difference
   // between the ARM and iOS ABIs.
   case TargetCXXABI::GenericARM:
Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/Code

[PATCH] D35388: [libc++] Give extern templates default visibility on gcc

2021-01-11 Thread Shoaib Meenai via Phabricator via cfe-commits
smeenai added a comment.

Sorry, I seem to have somehow blanked out on this diff entirely. Is it still 
relevant?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D35388

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


[PATCH] D50739: Clean up macros to detect underling C library functionality

2021-01-11 Thread Louis Dionne via Phabricator via cfe-commits
ldionne commandeered this revision.
ldionne edited reviewers, added: mclow.lists; removed: ldionne.
ldionne added a comment.
This revision now requires review to proceed.
Herald added a subscriber: jkorous.

Commandeering to close as I don't think this applies anymore.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D50739

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


[PATCH] D94337: Add cuda header type for cuh files

2021-01-11 Thread Artem Belevich via Phabricator via cfe-commits
tra added a comment.

In D94337#2491269 , @rgreenblatt wrote:

> My primary goal for this change was to allow for language servers and other 
> tooling to properly handle cuda header files. From my understanding the way 
> that language servers handle c++ header files is by compiling them with 
> -xc++-header and -fsyntax-only. This is certainly true for ccls and it seems 
> to be true for clangd.
> So this can be accomplished without actually able to produce preprocessed 
> output for cuda headers - it only requires handling the "-fsyntax-only" use 
> case.

That would still require properly defined CUDA macros. CUDA in clang relies on 
various CUDA attributes, currently wrapped in `__{host|device|global|etc.}__` 
macros in order to compile the code. Without them, `-fsyntax-only` will not be 
give you correct results on most of the CUDA code.
Most likely you'll see tons of errors when compiler sees `__device__` and has 
no idea what to do with it. Hence my suggestion that clang needs at least a 
minimum subset of CUDA headers to provide the critical subset of macros 
sufficient to convey critical semantics of CUDA code.

> A secondary goal was to make it so that header tab completion recognizes .cuh 
> files.
> This change doesn't depend on the other changes - it only requires a minor 
> edit to clang/lib/Sema/SemaCodeComplete.cpp.

Maybe. It depends on how well clang can recover from the errors induced by the 
unexpanded CUDA macros. This could range from OK on simple code to rather badly 
if we fail to instantiate templated code.

> From my limited testing, the changes made so far are sufficient to allow for 
> language servers to handle cuda headers.

Trivial CUDA headers -- maybe. I have doubts that it would work on something 
more interesting. E.g. try using it on https://github.com/NVIDIA/cutlass.

> clangd seems to just work (but I haven't tested it much), if --cuda-gpu-arch 
> is supplied (and --cuda-path if needed) via compile_flags.txt.

Yes, if you provide the flags and use it on complete .cu file, then clang 
driver takes care of the CUDA magic, pre-includes the right headers so the file 
parses correctly.

If the flags are supplied, then the same process will work for the header 
files, too. You could be able to process them with `-x cuda` which will apply 
the same magic pre-include. 
However, applying the same magic to everything that has CUDA header extension 
as the input is not the right thing to do, IMO, as that would not be what the 
end user expect.
In other words, the magic would be OK for tooling, but not for the general use 
by default.

>> Also, AFAICT, there's no such thing as a canonical CUDA header file 
>> extension. Some projects use `.cuh`, some use `.cu.h`, some use just `.h` 
>> and other C++ extensions, so this change would only help with a subset of 
>> the headers.
>
> The way things are setup in Types.def, defining a new file type requires an 
> extension. I think cuh is the best choice for this extension.

I'm OK with this part, if it's necessary in the end.

> Not having a canonical CUDA header file extension is unfortunate, but this 
> could be addressed at the tooling level if desired. For example, one could 
> imagine designating a subset of headers to be built with -xcuda-header via a 
> regex or whitelist.
> As far as I know, ccls and clangd don't currently have a nice way of doing 
> additional header specific compile commands, but I can't imagine this would 
> be particularly difficult to implement. Another option would be to add 
> -xcuda-header as a compiler flag for all headers as c++ headers should 
> generally be valid cuda.

Addressing it by the tooling looks like a good place to do it. Applying CUDA 
magic to all C++ sources by default is probably not a good idea as all the 
extra stuff will be observable and some C++ headers that may have checks for 
CUDA-specific things may get confused. I can't think of a good way to tell if 
particular source uses CUDA extensions or not, other than by trying to compile 
it. But then, again, what it it works for both CUDA and C++ mode. We would not 
know which mode user intended without them explicitly telling us. We may need 
some sort of knob what to assume if we can't figure it out some other way.

>> In general, `--cuda-path` should probably be treated as a required argument. 
>> I do not see a practical way to make `properly handle cuh files without 
>> additional arguments` work reliably. For that we'd need Clang to carry all 
>> required CUDA headers and that's not going to happen any time soon. That 
>> said, it may be worth considering implementing a `stand-alone` CUDA 
>> compilation mode which would provide the bare minimum of CUDA headers 
>> without having to include CUDA SDK headers. **That** would be useful for 
>> various tooling scenarios where we may need to deal with CUDA 
>> sources/headers but where we do not have CUDA SDK available and/or do not 
>> have 

[PATCH] D94442: clang: Always pass PowerPC endian information to GNU as

2021-01-11 Thread Nick Desaulniers via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG0a23fbd28c75: clang: Always pass PowerPC endian information 
to GNU as (authored by nathanchance, committed by nickdesaulniers).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94442

Files:
  clang/lib/Driver/ToolChains/Gnu.cpp
  clang/test/Driver/ppc-features.cpp


Index: clang/test/Driver/ppc-features.cpp
===
--- clang/test/Driver/ppc-features.cpp
+++ clang/test/Driver/ppc-features.cpp
@@ -156,14 +156,25 @@
 // CHECK-NOSPE: "-target-feature" "-spe"
 
 // Assembler features
-// RUN: %clang -target powerpc64-unknown-linux-gnu %s -### -o %t.o 
-no-integrated-as 2>&1 | FileCheck -check-prefix=CHECK_BE_AS_ARGS %s
-// CHECK_BE_AS_ARGS: "-mppc64"
-// CHECK_BE_AS_ARGS: "-many"
-
-// RUN: %clang -target powerpc64le-unknown-linux-gnu %s -### -o %t.o 
-no-integrated-as 2>&1 | FileCheck -check-prefix=CHECK_LE_AS_ARGS %s
-// CHECK_LE_AS_ARGS: "-mppc64"
-// CHECK_LE_AS_ARGS: "-mlittle-endian"
-// CHECK_LE_AS_ARGS: "-mpower8"
+// RUN: %clang -target powerpc-unknown-linux-gnu %s -### -o %t.o 
-no-integrated-as 2>&1 | FileCheck -check-prefix=CHECK_32_BE_AS_ARGS %s
+// CHECK_32_BE_AS_ARGS: "-mppc"
+// CHECK_32_BE_AS_ARGS-SAME: "-mbig-endian"
+// CHECK_32_BE_AS_ARGS-SAME: "-many"
+
+// RUN: %clang -target powerpcle-unknown-linux-gnu %s -### -o %t.o 
-no-integrated-as 2>&1 | FileCheck -check-prefix=CHECK_32_LE_AS_ARGS %s
+// CHECK_32_LE_AS_ARGS: "-mppc"
+// CHECK_32_LE_AS_ARGS-SAME: "-mlittle-endian"
+// CHECK_32_LE_AS_ARGS-SAME: "-many"
+
+// RUN: %clang -target powerpc64-unknown-linux-gnu %s -### -o %t.o 
-no-integrated-as 2>&1 | FileCheck -check-prefix=CHECK_64_BE_AS_ARGS %s
+// CHECK_64_BE_AS_ARGS: "-mppc64"
+// CHECK_64_BE_AS_ARGS-SAME: "-mbig-endian"
+// CHECK_64_BE_AS_ARGS-SAME: "-many"
+
+// RUN: %clang -target powerpc64le-unknown-linux-gnu %s -### -o %t.o 
-no-integrated-as 2>&1 | FileCheck -check-prefix=CHECK_64_LE_AS_ARGS %s
+// CHECK_64_LE_AS_ARGS: "-mppc64"
+// CHECK_64_LE_AS_ARGS-SAME: "-mlittle-endian"
+// CHECK_64_LE_AS_ARGS-SAME: "-mpower8"
 
 // OpenMP features
 // RUN: %clang -target powerpc-unknown-linux-gnu %s -### -fopenmp=libomp -o 
%t.o 2>&1 | FileCheck -check-prefix=CHECK_OPENMP_TLS %s
Index: clang/lib/Driver/ToolChains/Gnu.cpp
===
--- clang/lib/Driver/ToolChains/Gnu.cpp
+++ clang/lib/Driver/ToolChains/Gnu.cpp
@@ -731,6 +731,7 @@
   case llvm::Triple::ppc: {
 CmdArgs.push_back("-a32");
 CmdArgs.push_back("-mppc");
+CmdArgs.push_back("-mbig-endian");
 CmdArgs.push_back(
   ppc::getPPCAsmModeForCPU(getCPUName(Args, getToolChain().getTriple(;
 break;
@@ -746,6 +747,7 @@
   case llvm::Triple::ppc64: {
 CmdArgs.push_back("-a64");
 CmdArgs.push_back("-mppc64");
+CmdArgs.push_back("-mbig-endian");
 CmdArgs.push_back(
   ppc::getPPCAsmModeForCPU(getCPUName(Args, getToolChain().getTriple(;
 break;


Index: clang/test/Driver/ppc-features.cpp
===
--- clang/test/Driver/ppc-features.cpp
+++ clang/test/Driver/ppc-features.cpp
@@ -156,14 +156,25 @@
 // CHECK-NOSPE: "-target-feature" "-spe"
 
 // Assembler features
-// RUN: %clang -target powerpc64-unknown-linux-gnu %s -### -o %t.o -no-integrated-as 2>&1 | FileCheck -check-prefix=CHECK_BE_AS_ARGS %s
-// CHECK_BE_AS_ARGS: "-mppc64"
-// CHECK_BE_AS_ARGS: "-many"
-
-// RUN: %clang -target powerpc64le-unknown-linux-gnu %s -### -o %t.o -no-integrated-as 2>&1 | FileCheck -check-prefix=CHECK_LE_AS_ARGS %s
-// CHECK_LE_AS_ARGS: "-mppc64"
-// CHECK_LE_AS_ARGS: "-mlittle-endian"
-// CHECK_LE_AS_ARGS: "-mpower8"
+// RUN: %clang -target powerpc-unknown-linux-gnu %s -### -o %t.o -no-integrated-as 2>&1 | FileCheck -check-prefix=CHECK_32_BE_AS_ARGS %s
+// CHECK_32_BE_AS_ARGS: "-mppc"
+// CHECK_32_BE_AS_ARGS-SAME: "-mbig-endian"
+// CHECK_32_BE_AS_ARGS-SAME: "-many"
+
+// RUN: %clang -target powerpcle-unknown-linux-gnu %s -### -o %t.o -no-integrated-as 2>&1 | FileCheck -check-prefix=CHECK_32_LE_AS_ARGS %s
+// CHECK_32_LE_AS_ARGS: "-mppc"
+// CHECK_32_LE_AS_ARGS-SAME: "-mlittle-endian"
+// CHECK_32_LE_AS_ARGS-SAME: "-many"
+
+// RUN: %clang -target powerpc64-unknown-linux-gnu %s -### -o %t.o -no-integrated-as 2>&1 | FileCheck -check-prefix=CHECK_64_BE_AS_ARGS %s
+// CHECK_64_BE_AS_ARGS: "-mppc64"
+// CHECK_64_BE_AS_ARGS-SAME: "-mbig-endian"
+// CHECK_64_BE_AS_ARGS-SAME: "-many"
+
+// RUN: %clang -target powerpc64le-unknown-linux-gnu %s -### -o %t.o -no-integrated-as 2>&1 | FileCheck -check-prefix=CHECK_64_LE_AS_ARGS %s
+// CHECK_64_LE_AS_ARGS: "-mppc64"
+// CHECK_64_LE_AS_ARGS-SAME: "-mlittle-endian"
+// CHECK_64_LE_AS_ARGS-SAME: "-mpower8"
 
 // OpenMP features
 // RUN: %clang -target powerpc-

[clang] 0a23fbd - clang: Always pass PowerPC endian information to GNU as

2021-01-11 Thread Nick Desaulniers via cfe-commits

Author: Nathan Chancellor
Date: 2021-01-11T14:50:28-08:00
New Revision: 0a23fbd28c7509f2f980946091e6055bf27164d2

URL: 
https://github.com/llvm/llvm-project/commit/0a23fbd28c7509f2f980946091e6055bf27164d2
DIFF: 
https://github.com/llvm/llvm-project/commit/0a23fbd28c7509f2f980946091e6055bf27164d2.diff

LOG: clang: Always pass PowerPC endian information to GNU as

When building a 64-bit big endian PowerPC Linux kernel with a 64-bit
little endian PowerPC target, the 32-bit vDSO errors:

```
$ make ARCH=powerpc CC=clang CROSS_COMPILE=powerpc64le-linux-gnu- \
   pseries_defconfig arch/powerpc/kernel/vdso32/
ld.lld: error: arch/powerpc/kernel/vdso32/sigtramp.o is incompatible with 
elf32-powerpc
ld.lld: error: arch/powerpc/kernel/vdso32/gettimeofday.o is incompatible with 
elf32-powerpc
ld.lld: error: arch/powerpc/kernel/vdso32/datapage.o is incompatible with 
elf32-powerpc
ld.lld: error: arch/powerpc/kernel/vdso32/cacheflush.o is incompatible with 
elf32-powerpc
ld.lld: error: arch/powerpc/kernel/vdso32/note.o is incompatible with 
elf32-powerpc
ld.lld: error: arch/powerpc/kernel/vdso32/getcpu.o is incompatible with 
elf32-powerpc
ld.lld: error: arch/powerpc/kernel/vdso32/vgettimeofday.o is incompatible with 
elf32-powerpc
...
```

This happens because the endian information is missing from the call to
the assembler, even though it was explicitly passed to clang. See the
below example.

```
$ echo | clang --target=powerpc64le-linux-gnu \
   --prefix=/usr/bin/powerpc64le-linux-gnu- \
   -no-integrated-as -m32 -mbig-endian -### -x c -c -
 ".../clang-12" "-cc1" "-triple" "powerpc-unknown-linux-gnu" ...
...
  "/usr/bin/powerpc64le-linux-gnu-as" "-a32" "-mppc" "-many" "-o" "-.o" 
"/tmp/--e69e28.s"
```

clang sets the right target with -m32 and -mbig-endian but -mbig-endian
does not make it to the assembler, resulting in a 32-bit little endian
binary. This differs from the little endian targets, which always pass
-mlittle-endian.

```
$ echo | clang --target=powerpc64-linux-gnu \
   --prefix=/usr/bin/powerpc64-linux-gnu- \
   -no-integrated-as -m32 -mlittle-endian -### -x c -c -
 ".../clang-12" "-cc1" "-triple" "powerpcle-unknown-linux-gnu" ...
...
 "/usr/bin/powerpc64-linux-gnu-as" "-a32" "-mppc" "-mlittle-endian" "-many" 
"-o" "-.o" "/tmp/--405dbd.s"
```

Do the same thing for the big endian targets so that there is no more
error. This matches GCC's behavior, where -mbig and -mlittle are always
passed along to GNU as.

```
$ echo | powerpc64-linux-gcc -### -x c -c -
...
.../powerpc64-linux/bin/as -a64 -mpower4 -many -mbig -o -.o /tmp/ccVn7NAm.s
...

$ echo | powerpc64le-linux-gcc -### -x c -c -
...
.../powerpc64le-linux/bin/as -a64 -mpower8 -many -mlittle -o -.o /tmp/ccPN9ato.s
...
```

Reviewed By: nickdesaulniers, MaskRay

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

Added: 


Modified: 
clang/lib/Driver/ToolChains/Gnu.cpp
clang/test/Driver/ppc-features.cpp

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Gnu.cpp 
b/clang/lib/Driver/ToolChains/Gnu.cpp
index 164cf6e7..1d8a3cdce92a 100644
--- a/clang/lib/Driver/ToolChains/Gnu.cpp
+++ b/clang/lib/Driver/ToolChains/Gnu.cpp
@@ -731,6 +731,7 @@ void tools::gnutools::Assembler::ConstructJob(Compilation 
&C,
   case llvm::Triple::ppc: {
 CmdArgs.push_back("-a32");
 CmdArgs.push_back("-mppc");
+CmdArgs.push_back("-mbig-endian");
 CmdArgs.push_back(
   ppc::getPPCAsmModeForCPU(getCPUName(Args, getToolChain().getTriple(;
 break;
@@ -746,6 +747,7 @@ void tools::gnutools::Assembler::ConstructJob(Compilation 
&C,
   case llvm::Triple::ppc64: {
 CmdArgs.push_back("-a64");
 CmdArgs.push_back("-mppc64");
+CmdArgs.push_back("-mbig-endian");
 CmdArgs.push_back(
   ppc::getPPCAsmModeForCPU(getCPUName(Args, getToolChain().getTriple(;
 break;

diff  --git a/clang/test/Driver/ppc-features.cpp 
b/clang/test/Driver/ppc-features.cpp
index 05d71b95dba7..85060951aa16 100644
--- a/clang/test/Driver/ppc-features.cpp
+++ b/clang/test/Driver/ppc-features.cpp
@@ -156,14 +156,25 @@
 // CHECK-NOSPE: "-target-feature" "-spe"
 
 // Assembler features
-// RUN: %clang -target powerpc64-unknown-linux-gnu %s -### -o %t.o 
-no-integrated-as 2>&1 | FileCheck -check-prefix=CHECK_BE_AS_ARGS %s
-// CHECK_BE_AS_ARGS: "-mppc64"
-// CHECK_BE_AS_ARGS: "-many"
-
-// RUN: %clang -target powerpc64le-unknown-linux-gnu %s -### -o %t.o 
-no-integrated-as 2>&1 | FileCheck -check-prefix=CHECK_LE_AS_ARGS %s
-// CHECK_LE_AS_ARGS: "-mppc64"
-// CHECK_LE_AS_ARGS: "-mlittle-endian"
-// CHECK_LE_AS_ARGS: "-mpower8"
+// RUN: %clang -target powerpc-unknown-linux-gnu %s -### -o %t.o 
-no-integrated-as 2>&1 | FileCheck -check-prefix=CHECK_32_BE_AS_ARGS %s
+// CHECK_32_BE_AS_ARGS: "-mppc"
+// CHECK_32_BE_AS_ARGS-SAME: "-mbig-endian"
+// CHECK_32_BE_AS_ARGS-SAME: "-many"
+
+// RUN: %clang -target powerpcle-u

[PATCH] D94453: [libTooling] Add function to Transformer for creating a diagnostic-only rule.

2021-01-11 Thread Yitzhak Mandelbaum via Phabricator via cfe-commits
ymandel created this revision.
ymandel added a reviewer: tdl-g.
ymandel requested review of this revision.
Herald added a project: clang.

Adds a convenience function for creating a rule that only generates a
diagnostic, without any correpsonding edits.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D94453

Files:
  clang-tools-extra/unittests/clang-tidy/TransformerClangTidyCheckTest.cpp
  clang/include/clang/Tooling/Transformer/RewriteRule.h
  clang/unittests/Tooling/TransformerTest.cpp

Index: clang/unittests/Tooling/TransformerTest.cpp
===
--- clang/unittests/Tooling/TransformerTest.cpp
+++ clang/unittests/Tooling/TransformerTest.cpp
@@ -26,6 +26,7 @@
 using ::clang::transformer::before;
 using ::clang::transformer::cat;
 using ::clang::transformer::changeTo;
+using ::clang::transformer::makeDiagnosticRule;
 using ::clang::transformer::makeRule;
 using ::clang::transformer::member;
 using ::clang::transformer::name;
@@ -1531,7 +1532,7 @@
 // of the expanded text. That is, the edit would have to be applied to the
 // macro's definition to succeed and editing the expansion point would not
 // suffice.
-TEST_F(TransformerTest, NoPartialRewriteOMacroExpansion) {
+TEST_F(TransformerTest, NoPartialRewriteOfMacroExpansion) {
   std::string Input = R"cc(
 #define ZERO_PLUS 0 + 3
 int f(string s) { return ZERO_PLUS; })cc";
@@ -1638,4 +1639,19 @@
   << "Could not update code: " << llvm::toString(UpdatedCode.takeError());
   EXPECT_EQ(format(*UpdatedCode), format(Header));
 }
+
+// The Transformer engine doesn't use the `Explanation` field of rules, so at
+// most we can check that the rule doesn't make any changes. If/when it starts
+// handling that field, we should expand these tests appropriately.
+TEST_F(TransformerTest, DiagnosticRule) {
+  std::string Input = "int f(int x) { return x; }";
+  testRule(makeDiagnosticRule(returnStmt(), cat("message")), Input, Input);
+}
+
+TEST_F(TransformerTest, DiagnosticRuleWithAnchor) {
+  std::string Input = "int f(int x) { return x; }";
+  testRule(makeDiagnosticRule(returnStmt(hasReturnValue(expr().bind("e"))),
+  node("e"), cat("message")),
+   Input, Input);
+}
 } // namespace
Index: clang/include/clang/Tooling/Transformer/RewriteRule.h
===
--- clang/include/clang/Tooling/Transformer/RewriteRule.h
+++ clang/include/clang/Tooling/Transformer/RewriteRule.h
@@ -305,6 +305,21 @@
   return makeRule(std::move(M), edit(std::move(Edit)), std::move(Explanation));
 }
 
+/// Constructs a diagnostic \c RewriteRule. That is, a rule that only prints a
+/// diagnostic, without generating an edit. The two-argument version locates the
+/// diagnostic at the beginning of the code matched by \p M. To specify a
+/// different source range, pass \p Anchor in the three-argument version.
+inline RewriteRule makeDiagnosticRule(ast_matchers::internal::DynTypedMatcher M,
+  TextGenerator Explanation) {
+  return makeRule(std::move(M), noopEdit(node(RootID)), std::move(Explanation));
+}
+inline RewriteRule makeDiagnosticRule(ast_matchers::internal::DynTypedMatcher M,
+  RangeSelector Anchor,
+  TextGenerator Explanation) {
+  return makeRule(std::move(M), noopEdit(std::move(Anchor)),
+  std::move(Explanation));
+}
+
 /// For every case in Rule, adds an include directive for the given header. The
 /// common use is assumed to be a rule with only one case. For example, to
 /// replace a function call and add headers corresponding to the new code, one
Index: clang-tools-extra/unittests/clang-tidy/TransformerClangTidyCheckTest.cpp
===
--- clang-tools-extra/unittests/clang-tidy/TransformerClangTidyCheckTest.cpp
+++ clang-tools-extra/unittests/clang-tidy/TransformerClangTidyCheckTest.cpp
@@ -12,6 +12,7 @@
 #include "clang/Tooling/Transformer/RangeSelector.h"
 #include "clang/Tooling/Transformer/Stencil.h"
 #include "clang/Tooling/Transformer/Transformer.h"
+#include "gmock/gmock.h"
 #include "gtest/gtest.h"
 
 namespace clang {
@@ -68,6 +69,45 @@
   EXPECT_EQ(Expected, test::runCheckOnCode(Input));
 }
 
+TEST(TransformerClangTidyCheckTest, MakeDiagnosticRule) {
+  class DiagOnlyCheck : public TransformerClangTidyCheck {
+  public:
+DiagOnlyCheck(StringRef Name, ClangTidyContext *Context)
+: TransformerClangTidyCheck(
+  makeDiagnosticRule(returnStmt(), cat("message")), Name, Context) {
+}
+  };
+  std::string Input = "int h() { return 5; }";
+  std::vector Errors;
+  EXPECT_EQ(Input, test::runCheckOnCode(Input, &Errors));
+  EXPECT_EQ(Errors.size(), 1U);
+  EXPECT_EQ(Errors[0].Message.Message, "message");
+  EXPECT_THAT(Errors[0].Ranges, testing::IsEmpty());
+
+  // The diagnostic is anchored to the m

[PATCH] D91913: Suppress non-conforming GNU paste extension in all standard-conforming modes

2021-01-11 Thread Harald van Dijk via Phabricator via cfe-commits
hvdijk added a comment.

Ping 3


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91913

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


[PATCH] D93747: Rename debug linkage name with -funique-internal-linkage-names

2021-01-11 Thread Hongtao Yu via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG32bcfcda4e28: Rename debug linkage name with 
-funique-internal-linkage-names (authored by hoy).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93747

Files:
  llvm/include/llvm/IR/DebugInfoMetadata.h
  llvm/lib/Transforms/Utils/UniqueInternalLinkageNames.cpp
  
llvm/test/Transforms/UniqueInternalLinkageNames/unique-internal-linkage-names.ll
  llvm/test/Transforms/UniqueLinkageNames/unique-internal-linkage-names.ll

Index: llvm/test/Transforms/UniqueLinkageNames/unique-internal-linkage-names.ll
===
--- llvm/test/Transforms/UniqueLinkageNames/unique-internal-linkage-names.ll
+++ /dev/null
@@ -1,24 +0,0 @@
-; RUN: opt -S -passes='default' -new-pm-pseudo-probe-for-profiling -new-pm-unique-internal-linkage-names -debug-pass-manager < %s 2>&1 | FileCheck %s --check-prefix=O0 --check-prefix=UNIQUE
-; RUN: opt -S -passes='default' -new-pm-pseudo-probe-for-profiling -new-pm-unique-internal-linkage-names -debug-pass-manager < %s 2>&1 | FileCheck %s --check-prefix=O2 --check-prefix=UNIQUE
-; RUN: opt -S -passes='default' -new-pm-pseudo-probe-for-profiling -new-pm-unique-internal-linkage-names -debug-pass-manager < %s 2>&1 | FileCheck %s --check-prefix=O2 --check-prefix=UNIQUE
-; RUN: opt -S -passes='thinlto-pre-link' -new-pm-pseudo-probe-for-profiling -new-pm-unique-internal-linkage-names -debug-pass-manager < %s 2>&1 | FileCheck %s --check-prefix=O2 --check-prefix=UNIQUE
-; RUN: opt -S -passes='thinlto-pre-link' -new-pm-pseudo-probe-for-profiling -new-pm-unique-internal-linkage-names -debug-pass-manager < %s 2>&1 | FileCheck %s --check-prefix=O2 --check-prefix=UNIQUE
-
-define internal i32 @foo() {
-entry:
-  ret i32 0
-}
-
-define dso_local i32 (...)* @bar() {
-entry:
-  ret i32 (...)* bitcast (i32 ()* @foo to i32 (...)*)
-}
-
-; O0: Running pass: UniqueInternalLinkageNamesPass
-
-;; Check UniqueInternalLinkageNamesPass is scheduled before SampleProfileProbePass.
-; O2: Running pass: UniqueInternalLinkageNamesPass
-; O2: Running pass: SampleProfileProbePass
-
-; UNIQUE: define internal i32 @foo.__uniq.{{[0-9a-f]+}}()
-; UNIQUE: ret {{.*}} @foo.__uniq.{{[0-9a-f]+}} {{.*}}
Index: llvm/test/Transforms/UniqueInternalLinkageNames/unique-internal-linkage-names.ll
===
--- /dev/null
+++ llvm/test/Transforms/UniqueInternalLinkageNames/unique-internal-linkage-names.ll
@@ -0,0 +1,50 @@
+; RUN: opt -S -passes='default' -new-pm-pseudo-probe-for-profiling -new-pm-unique-internal-linkage-names -debug-pass-manager < %s 2>&1 | FileCheck %s --check-prefix=O0 --check-prefix=UNIQUE
+; RUN: opt -S -passes='default' -new-pm-pseudo-probe-for-profiling -new-pm-unique-internal-linkage-names -debug-pass-manager < %s 2>&1 | FileCheck %s --check-prefix=O2 --check-prefix=UNIQUE
+; RUN: opt -S -passes='default' -new-pm-pseudo-probe-for-profiling -new-pm-unique-internal-linkage-names -debug-pass-manager < %s 2>&1 | FileCheck %s --check-prefix=O2 --check-prefix=UNIQUE
+; RUN: opt -S -passes='thinlto-pre-link' -new-pm-pseudo-probe-for-profiling -new-pm-unique-internal-linkage-names -debug-pass-manager < %s 2>&1 | FileCheck %s --check-prefix=O2 --check-prefix=UNIQUE
+; RUN: opt -S -passes='thinlto-pre-link' -new-pm-pseudo-probe-for-profiling -new-pm-unique-internal-linkage-names -debug-pass-manager < %s 2>&1 | FileCheck %s --check-prefix=O2 --check-prefix=UNIQUE
+; RUN: opt -S -passes=unique-internal-linkage-names < %s -o - | FileCheck %s --check-prefix=DBG
+
+define internal i32 @foo() !dbg !15 {
+entry:
+  ret i32 0
+}
+
+define dso_local i32 (...)* @bar() {
+entry:
+  ret i32 (...)* bitcast (i32 ()* @foo to i32 (...)*)
+}
+
+define internal i32 @go() !dbg !19 {
+entry:
+  ret i32 0
+}
+
+!llvm.dbg.cu = !{!0}
+!llvm.module.flags = !{!3, !4, !5}
+
+!0 = distinct !DICompileUnit(language: DW_LANG_C99, file: !1, enums: !2)
+!1 = !DIFile(filename: "test.c", directory: "")
+!2 = !{}
+!3 = !{i32 7, !"Dwarf Version", i32 4}
+!4 = !{i32 2, !"Debug Info Version", i32 3}
+!5 = !{i32 1, !"wchar_size", i32 4}
+!13 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
+!15 = distinct !DISubprogram(name: "foo", linkageName: "foo", scope: !1, file: !1, line: 5, type: !16, scopeLine: 5, spFlags: DISPFlagLocalToUnit | DISPFlagDefinition, unit: !0, declaration: !18, retainedNodes: !2)
+!16 = !DISubroutineType(types: !17)
+!17 = !{!13}
+!18 = !DISubprogram(name: "foo", linkageName: "foo", scope: !1, isDefinition: false, flags: DIFlagPrototyped, spFlags: DISPFlagOptimized)
+!19 = distinct !DISubprogram(name: "go", scope: !1, file: !1, line: 5, type: !16, scopeLine: 5, spFlags: DISPFlagLocalToUnit | DISPFlagDefinition, unit: !0, declaration: !18, retainedNodes: !2)
+
+; O0: Running pass: UniqueInternalLinkageNamesPass
+
+;; Check UniqueInternalLinkageNamesPa

[clang] b88c8f1 - CGDebugInfo: Delete unused parameters

2021-01-11 Thread Fangrui Song via cfe-commits

Author: Fangrui Song
Date: 2021-01-11T13:39:03-08:00
New Revision: b88c8f1aab527f1aebe612ab6c50a418bff88584

URL: 
https://github.com/llvm/llvm-project/commit/b88c8f1aab527f1aebe612ab6c50a418bff88584
DIFF: 
https://github.com/llvm/llvm-project/commit/b88c8f1aab527f1aebe612ab6c50a418bff88584.diff

LOG: CGDebugInfo: Delete unused parameters

Added: 


Modified: 
clang/lib/CodeGen/CGDebugInfo.cpp
clang/lib/CodeGen/CGDebugInfo.h
clang/lib/CodeGen/CodeGenFunction.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGDebugInfo.cpp 
b/clang/lib/CodeGen/CGDebugInfo.cpp
index 2beb80b2ab6c..881ee24546c2 100644
--- a/clang/lib/CodeGen/CGDebugInfo.cpp
+++ b/clang/lib/CodeGen/CGDebugInfo.cpp
@@ -2109,8 +2109,7 @@ StringRef CGDebugInfo::getDynamicInitializerName(const 
VarDecl *VD,
 }
 
 void CGDebugInfo::CollectVTableInfo(const CXXRecordDecl *RD, llvm::DIFile 
*Unit,
-SmallVectorImpl &EltTys,
-llvm::DICompositeType *RecordTy) {
+SmallVectorImpl &EltTys) 
{
   // If this class is not dynamic then there is not any vtable info to collect.
   if (!RD->isDynamicClass())
 return;
@@ -2428,7 +2427,7 @@ llvm::DIType *CGDebugInfo::CreateTypeDefinition(const 
RecordType *Ty) {
   const auto *CXXDecl = dyn_cast(RD);
   if (CXXDecl) {
 CollectCXXBases(CXXDecl, DefUnit, EltTys, FwdDecl);
-CollectVTableInfo(CXXDecl, DefUnit, EltTys, FwdDecl);
+CollectVTableInfo(CXXDecl, DefUnit, EltTys);
   }
 
   // Collect data fields (including static variables and any initializers).
@@ -3794,11 +3793,9 @@ llvm::DISubroutineType 
*CGDebugInfo::getOrCreateFunctionType(const Decl *D,
   return cast(getOrCreateType(FnType, F));
 }
 
-void CGDebugInfo::EmitFunctionStart(GlobalDecl GD, SourceLocation Loc,
+void CGDebugInfo::emitFunctionStart(GlobalDecl GD, SourceLocation Loc,
 SourceLocation ScopeLoc, QualType FnType,
-llvm::Function *Fn, bool CurFuncIsThunk,
-CGBuilderTy &Builder) {
-
+llvm::Function *Fn, bool CurFuncIsThunk) {
   StringRef Name;
   StringRef LinkageName;
 

diff  --git a/clang/lib/CodeGen/CGDebugInfo.h b/clang/lib/CodeGen/CGDebugInfo.h
index 31fdd6b8ed18..afd5b50c182a 100644
--- a/clang/lib/CodeGen/CGDebugInfo.h
+++ b/clang/lib/CodeGen/CGDebugInfo.h
@@ -324,8 +324,7 @@ class CGDebugInfo {
   /// If the C++ class has vtable info then insert appropriate debug
   /// info entry in EltTys vector.
   void CollectVTableInfo(const CXXRecordDecl *Decl, llvm::DIFile *F,
- SmallVectorImpl &EltTys,
- llvm::DICompositeType *RecordTy);
+ SmallVectorImpl &EltTys);
   /// @}
 
   /// Create a new lexical block node and push it on the stack.
@@ -413,10 +412,9 @@ class CGDebugInfo {
   /// start of a new function.
   /// \param Loc   The location of the function header.
   /// \param ScopeLoc  The location of the function body.
-  void EmitFunctionStart(GlobalDecl GD, SourceLocation Loc,
+  void emitFunctionStart(GlobalDecl GD, SourceLocation Loc,
  SourceLocation ScopeLoc, QualType FnType,
- llvm::Function *Fn, bool CurFnIsThunk,
- CGBuilderTy &Builder);
+ llvm::Function *Fn, bool CurFnIsThunk);
 
   /// Start a new scope for an inlined function.
   void EmitInlineFunctionStart(CGBuilderTy &Builder, GlobalDecl GD);

diff  --git a/clang/lib/CodeGen/CodeGenFunction.cpp 
b/clang/lib/CodeGen/CodeGenFunction.cpp
index 49f13323297c..2c302ae48d61 100644
--- a/clang/lib/CodeGen/CodeGenFunction.cpp
+++ b/clang/lib/CodeGen/CodeGenFunction.cpp
@@ -977,8 +977,7 @@ void CodeGenFunction::StartFunction(GlobalDecl GD, QualType 
RetTy,
   ArgTypes.push_back(VD->getType());
 QualType FnType = getContext().getFunctionType(
 RetTy, ArgTypes, FunctionProtoType::ExtProtoInfo(CC));
-DI->EmitFunctionStart(GD, Loc, StartLoc, FnType, CurFn, CurFuncIsThunk,
-  Builder);
+DI->emitFunctionStart(GD, Loc, StartLoc, FnType, CurFn, CurFuncIsThunk);
   }
 
   if (ShouldInstrumentFunction()) {



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


[PATCH] D94224: [clang][AST] Get rid of an alignment hack in DeclObjC.h [NFCI]

2021-01-11 Thread Adrian Prantl via Phabricator via cfe-commits
aprantl accepted this revision.
aprantl added a comment.
This revision is now accepted and ready to land.

That's even better!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94224

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


[PATCH] D94337: Add cuda header type for cuh files

2021-01-11 Thread Ryan Greenblatt via Phabricator via cfe-commits
rgreenblatt added a comment.

In D94337#2490828 , @tra wrote:

> The problem is that just telling compiler that the header is a CUDA source is 
> not sufficient. Clang relies on a lot of CUDA SDK headers in order to make 
> the standard CUDA things like `__host__`, '__device__', `threadIdx`, etc 
> work. For the CUDA source files clang pre-includes a lot of headers. I'm not 
> quite sure what clang would be supposed to do when it's given a `.cuh` as an 
> input. If we pre-include the CUDA headers as we do for `.cu` compilation, 
> we'll get way more of the preprocessed output than the user would likely 
> expect. If we do not pre-include CUDA headers, we'll not get CUDA macros 
> expanded and the output would not be suitable to pass on to the further 
> compilation. On one hand it does not make things worse. On the other, it does 
> not make them better, either. If anything, Clang not recognizing CUDA headers 
> on their own is probably better than accepting them and producing invalid 
> output.
>
> Perhaps I'm missing something. Do you have specific use case in mind for this 
> change?

My primary goal for this change was to allow for language servers and other 
tooling to properly handle cuda header files. From my understanding the way 
that language servers handle c++ header files is by compiling them with 
-xc++-header and -fsyntax-only. This is certainly true for ccls and it seems to 
be true for clangd.
So this can be accomplished without actually able to produce preprocessed 
output for cuda headers - it only requires handling the "-fsyntax-only" use 
case.

A secondary goal was to make it so that header tab completion recognizes .cuh 
files.
This change doesn't depend on the other changes - it only requires a minor edit 
to clang/lib/Sema/SemaCodeComplete.cpp.

So, as I mentioned before, one approach would be to avoid all the issues with 
preprocessed output for now by only allowing for compiling with -xcuda-header 
if -fsyntax-only is enabled.
Actually generating precompiled header output could be implemented later or not 
at all.

From my limited testing, the changes made so far are sufficient to allow for 
language servers to handle cuda headers.
clangd seems to just work (but I haven't tested it much), if --cuda-gpu-arch is 
supplied (and --cuda-path if needed) via compile_flags.txt.
I have a branch of ccls with a few minor changes working as well: 
https://github.com/rgreenblatt/ccls/tree/cuh_support.

> Also, AFAICT, there's no such thing as a canonical CUDA header file 
> extension. Some projects use `.cuh`, some use `.cu.h`, some use just `.h` and 
> other C++ extensions, so this change would only help with a subset of the 
> headers.

This is unfortunate, but this could be addressed at the tooling level if 
desired. For example, one could imagine designating a subset of headers to be 
built with -xcuda-header via a regex or whitelist. 
As far as I know, ccls and clangd don't currently have a nice way of doing 
additional header specific compile commands, but I can't imagine this would be 
particularly difficult to implement. Another option would be to add 
-xcuda-header as a compiler flag for all headers as c++ headers should 
generally be valid cuda.

> In general, `--cuda-path` should probably be treated as a required argument. 
> I do not see a practical way to make `properly handle cuh files without 
> additional arguments` work reliably. For that we'd need Clang to carry all 
> required CUDA headers and that's not going to happen any time soon. That 
> said, it may be worth considering implementing a `stand-alone` CUDA 
> compilation mode which would provide the bare minimum of CUDA headers without 
> having to include CUDA SDK headers. **That** would be useful for various 
> tooling scenarios where we may need to deal with CUDA sources/headers but 
> where we do not have CUDA SDK available and/or do not have access to correct 
> `--cuda-path`.

For the language server use case this isn't necessary much of a problem.
ccls allows for configuring cuda specific arguments.
If a compile_commands.json is used, figuring out the correct compiler flags for 
any type of header file is in general non-trivial.
I think ccls tries to find the closest match in filename using some sort of 
metric. 
One could imagine trying to match cuda headers with cuda source file to get the 
correct values for --cuda-path and --cuda-gpu-arch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94337

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


[clang] f4cec70 - Add an assert to CGDebugInfo::getTypeOrNull

2021-01-11 Thread Fangrui Song via cfe-commits

Author: Fangrui Song
Date: 2021-01-11T13:25:20-08:00
New Revision: f4cec703ec8452f9d8b04fae171ba459adf38123

URL: 
https://github.com/llvm/llvm-project/commit/f4cec703ec8452f9d8b04fae171ba459adf38123
DIFF: 
https://github.com/llvm/llvm-project/commit/f4cec703ec8452f9d8b04fae171ba459adf38123.diff

LOG: Add an assert to CGDebugInfo::getTypeOrNull

Added: 


Modified: 
clang/lib/CodeGen/CGDebugInfo.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGDebugInfo.cpp 
b/clang/lib/CodeGen/CGDebugInfo.cpp
index 7dc6457d08d0..2beb80b2ab6c 100644
--- a/clang/lib/CodeGen/CGDebugInfo.cpp
+++ b/clang/lib/CodeGen/CGDebugInfo.cpp
@@ -3132,6 +3132,7 @@ static QualType UnwrapTypeForDebugInfo(QualType T, const 
ASTContext &C) {
 }
 
 llvm::DIType *CGDebugInfo::getTypeOrNull(QualType Ty) {
+  assert(Ty == UnwrapTypeForDebugInfo(Ty, CGM.getContext()));
   auto It = TypeCache.find(Ty.getAsOpaquePtr());
   if (It != TypeCache.end()) {
 // Verify that the debug info still exists.



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


[clang] 9b222b1 - [c++20] Don't consider string literal operator templates for numeric

2021-01-11 Thread Richard Smith via cfe-commits

Author: Richard Smith
Date: 2021-01-11T13:19:00-08:00
New Revision: 9b222b108a2e37eb45d3156ec8554d148d658a8a

URL: 
https://github.com/llvm/llvm-project/commit/9b222b108a2e37eb45d3156ec8554d148d658a8a
DIFF: 
https://github.com/llvm/llvm-project/commit/9b222b108a2e37eb45d3156ec8554d148d658a8a.diff

LOG: [c++20] Don't consider string literal operator templates for numeric
literals.

A literal interpretation of the standard wording allows this, but it was
never intended that string literal operator templates would be used for
anything other than user-defined string literals.

Added: 


Modified: 
clang/lib/Sema/SemaLookup.cpp
clang/test/SemaCXX/cxx2a-user-defined-literals.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaLookup.cpp b/clang/lib/Sema/SemaLookup.cpp
index 16dd8f5105961..29038ab9fe1ca 100644
--- a/clang/lib/Sema/SemaLookup.cpp
+++ b/clang/lib/Sema/SemaLookup.cpp
@@ -3384,6 +3384,13 @@ Sema::LookupLiteralOperator(Scope *S, LookupResult &R,
   TemplateParameterList *Params = FD->getTemplateParameters();
   if (Params->size() == 1) {
 IsTemplate = true;
+if (!Params->getParam(0)->isTemplateParameterPack() && !StringLit) {
+  // Implied but not stated: user-defined integer and floating literals
+  // only ever use numeric literal operator templates, not templates
+  // taking a parameter of class type.
+  F.erase();
+  continue;
+}
 
 // A string literal template is only considered if the string literal
 // is a well-formed template argument for the template parameter.

diff  --git a/clang/test/SemaCXX/cxx2a-user-defined-literals.cpp 
b/clang/test/SemaCXX/cxx2a-user-defined-literals.cpp
index d730eba741a88..12f672ff640a9 100644
--- a/clang/test/SemaCXX/cxx2a-user-defined-literals.cpp
+++ b/clang/test/SemaCXX/cxx2a-user-defined-literals.cpp
@@ -24,4 +24,33 @@ chrono::day bin_d = 0b011d;
 // expected-note@9{{candidate constructor (the implicit move constructor)}}
 chrono::day hex_d = 0x44d;
 chrono::year y  = 10y;
+
+namespace ignore_class_udl_for_numeric_literals {
+  struct A { constexpr A(const char*) {} };
+  struct B { constexpr B(char); };
+  struct C { constexpr C(int); };
+  template void operator""_a();
+  template void operator""_b();
+  template void operator""_c();
+  void test_class_udl_1() {
+1_a; // expected-error {{no matching}}
+1_b; // expected-error {{no matching}}
+1_c; // expected-error {{no matching}}
+"1"_a;
+"1"_b; // expected-error {{no matching}}
+"1"_c; // expected-error {{no matching}}
+  }
+  template void operator""_a();
+  template void operator""_b();
+  template void operator""_c();
+  void test_class_udl_2() {
+1_a;
+// FIXME: The standard appears to say these two are ambiguous!
+1_b;
+1_c;
+"1"_a;
+"1"_b; // expected-error {{no matching}}
+"1"_c; // expected-error {{no matching}}
+  }
+}
 #endif



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


[PATCH] D94391: CGDebugInfo: Drop Loc.isInvalid() special case from getLineNumber

2021-01-11 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added a comment.

In D94391#2491178 , @dblaikie wrote:

> Any particular bug you're trying to fix? (this looks like it changes the 
> debug locations, so it would need tests)
>
> Not necessarily clear that these are better debug locations?

No particular bug. `CGDebugInfo::getLineNumber` returning CurLoc just looks 
strange. (The CurLoc may be far below (irrelevant) when getLineNumber is 
called.)

This patch is hopefully NFC. Dropping `CurLoc` from 
`getLineNumber(RD->getLocation().isValid() ? RD->getLocation() : CurLoc)` will 
cause a difference, which may reveal missing `SourceLocation` information in 
ObjC constructs.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94391

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


[PATCH] D93769: RFC [clang] Add support for option -ffp-eval-method and extend #pragma float_control similarly

2021-01-11 Thread Melanie Blower via Phabricator via cfe-commits
mibintc added a comment.

@rjmccall Hoping you can take a look at this patch


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93769

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


[PATCH] D94391: CGDebugInfo: Drop Loc.isInvalid() special case from getLineNumber

2021-01-11 Thread David Blaikie via Phabricator via cfe-commits
dblaikie added a comment.

Any particular bug you're trying to fix? (this looks like it changes the debug 
locations, so it would need tests)

Not necessarily clear that these are better debug locations?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94391

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


[PATCH] D92751: [clang][aarch64] Precondition isHomogeneousAggregate on isCXX14Aggregate

2021-01-11 Thread Peter Waller via Phabricator via cfe-commits
peterwaller-arm accepted this revision.
peterwaller-arm added inline comments.



Comment at: llvm/test/CodeGen/AArch64/arm64-windows-calls.ll:117
+  ret %struct.Pod %x1
+; CHECK: ldp d0, d1, [x0]
+}

rnk wrote:
> peterwaller-arm wrote:
> > rnk wrote:
> > > Please use CHECK-LABEL directives to ensure that these assembly checks 
> > > are from the function you intend to match.
> > @DavidTruby I think the intent here is:
> > 
> > CHECK-LABEL: < something matching the first line of the function definition 
> > >
> > CHECK: 
> > 
> > CHECK-LABEL: 
> > 
> > Such that if by some fluke some other function in the interim produces 
> > , it won't be allowed to match something produced in 
> > the subsequent function. This also renders the code safe against this 
> > problem if functions are added or moved around. I suggest having a 
> > CHECK-LABEL on each function heading, and the code within those functions 
> > should be CHECK/CHECK-NEXT as appropriate.
> Yep. I think you could still go further by adding a trailing colon. FileCheck 
> matches for substrings of a line, so as written, this could match "call 
> copy_pod", which wouldn't be what you want. The risk of that in this test is 
> low, but it's a good best practice.
To echo @rnk, ideally your CHECK-LABEL statements should match the function 
header, and typically they're placed immediately above the function header, 
since that's logically what they're matching. The existence of the CHECK-LABEL 
primitive on every function header constrains the checks to only match within 
their intended function between the 'bracket' of two CHECK-LABEL statements.

```

; CHECK-LABEL: define {{.*}}thing
void thing() {
; CHECK: some codegen in thing
// ... do codegen here.
}
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92751

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


[PATCH] D77056: [Sema] Allow non-member operators for sizeless SVE types

2021-01-11 Thread Richard Sandiford via Phabricator via cfe-commits
rsandifo-arm added a comment.

In D77056#2487754 , @rsmith wrote:

> In D77056#2465936 , @rsandifo-arm 
> wrote:
>
>> Either way, I realise this isn't great style.  It just seems like a 
>> practical compromise between the rock of classes having a constant size and 
>> the hard place of vectors having a variable length.
>
> I don't think this is just a question of style; it's a severe limitation to 
> language functionality. In a very broad sense, you would not be able to use 
> these types with templates. For example, even if you define an `operator<` 
> between `svint8_t`, you can't use `std::min` between two `svint8_t`'s. And 
> people are going to try to work around that by defining the operators first, 
> then `#include`ing the algorithms in question, which will lead to ODR issues, 
> will break when C++ modules is enabled, and so on.

I agree that, even after disallowing definitions in the global namespace, the 
feature could still be abused to cause ODR violations.  If that's a showstopper 
then I guess the patch can't go forward.  But it seems like the feature would 
have legitimate uses too.

> It's also a little unclear to me what the motivation for this is. Do you 
> really want to permit (for example) an `operator+` between sizeless vectors 
> that does something other than element-wise addition? If not, then why do we 
> not instead directly provide built-in support for these operators, as we do 
> for all our other vector types?

The aim of the patch is to allow SIMD frameworks like 
https://github.com/google/highway to be ported to SVE.

Most C++ SIMD wrappers are class based, using member functions (including 
member operator functions) for most operations.  `std::simd` is an obvious 
example of this.  This style of framework can't be ported to length-agnostic 
SVE because classes must be a constant size.  But frameworks like Highway 
instead use non-member functions and non-member operator overloads.  That 
approach is compatible with sizeless types.

We'd also like to maintain the current separation between the SIMD library and 
the underlying architecture support.  At it's heart, the SVE ACLE is just a set 
of low-level, machine-specific intrinsic functions.  t's not supposed to be a 
new generic language extension.

I agree the separation between the compiler and the library isn't too important 
for things like `operator+` on uniform types, since the operation only has one 
sensible implementation.  But some areas do provide an element of choice.  E.g.:

- Should `operator&` be defined for float vectors?
- Should `operator%` be implemented, even though it's not a native operation?
- What operators should be defined for `bfloat16_t` vectors?  At the moment, 
even scalar `bfloat16_t` supports very few “native” operations, but SIMD 
frameworks might want to provide more (now or in the future).
- Should `operator[]` be defined for `svbool_t`, and if so, what type should it 
return when applied to lvalues?
- Should mixtures of float and integer types be supported?

Leaving these decisions to the library means that the library can provide a 
consistent interface for multiple targets.  If we pick one behaviour for SVE, 
the library would need to pick the same behaviour for other vector 
architectures or force users to live with the inconsistency.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77056

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


[PATCH] D93747: Rename debug linkage name with -funique-internal-linkage-names

2021-01-11 Thread Hongtao Yu via Phabricator via cfe-commits
hoy updated this revision to Diff 315908.
hoy added a comment.

Rebasing.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93747

Files:
  llvm/include/llvm/IR/DebugInfoMetadata.h
  llvm/lib/Transforms/Utils/UniqueInternalLinkageNames.cpp
  
llvm/test/Transforms/UniqueInternalLinkageNames/unique-internal-linkage-names.ll
  llvm/test/Transforms/UniqueLinkageNames/unique-internal-linkage-names.ll

Index: llvm/test/Transforms/UniqueLinkageNames/unique-internal-linkage-names.ll
===
--- llvm/test/Transforms/UniqueLinkageNames/unique-internal-linkage-names.ll
+++ /dev/null
@@ -1,24 +0,0 @@
-; RUN: opt -S -passes='default' -new-pm-pseudo-probe-for-profiling -new-pm-unique-internal-linkage-names -debug-pass-manager < %s 2>&1 | FileCheck %s --check-prefix=O0 --check-prefix=UNIQUE
-; RUN: opt -S -passes='default' -new-pm-pseudo-probe-for-profiling -new-pm-unique-internal-linkage-names -debug-pass-manager < %s 2>&1 | FileCheck %s --check-prefix=O2 --check-prefix=UNIQUE
-; RUN: opt -S -passes='default' -new-pm-pseudo-probe-for-profiling -new-pm-unique-internal-linkage-names -debug-pass-manager < %s 2>&1 | FileCheck %s --check-prefix=O2 --check-prefix=UNIQUE
-; RUN: opt -S -passes='thinlto-pre-link' -new-pm-pseudo-probe-for-profiling -new-pm-unique-internal-linkage-names -debug-pass-manager < %s 2>&1 | FileCheck %s --check-prefix=O2 --check-prefix=UNIQUE
-; RUN: opt -S -passes='thinlto-pre-link' -new-pm-pseudo-probe-for-profiling -new-pm-unique-internal-linkage-names -debug-pass-manager < %s 2>&1 | FileCheck %s --check-prefix=O2 --check-prefix=UNIQUE
-
-define internal i32 @foo() {
-entry:
-  ret i32 0
-}
-
-define dso_local i32 (...)* @bar() {
-entry:
-  ret i32 (...)* bitcast (i32 ()* @foo to i32 (...)*)
-}
-
-; O0: Running pass: UniqueInternalLinkageNamesPass
-
-;; Check UniqueInternalLinkageNamesPass is scheduled before SampleProfileProbePass.
-; O2: Running pass: UniqueInternalLinkageNamesPass
-; O2: Running pass: SampleProfileProbePass
-
-; UNIQUE: define internal i32 @foo.__uniq.{{[0-9a-f]+}}()
-; UNIQUE: ret {{.*}} @foo.__uniq.{{[0-9a-f]+}} {{.*}}
Index: llvm/test/Transforms/UniqueInternalLinkageNames/unique-internal-linkage-names.ll
===
--- /dev/null
+++ llvm/test/Transforms/UniqueInternalLinkageNames/unique-internal-linkage-names.ll
@@ -0,0 +1,50 @@
+; RUN: opt -S -passes='default' -new-pm-pseudo-probe-for-profiling -new-pm-unique-internal-linkage-names -debug-pass-manager < %s 2>&1 | FileCheck %s --check-prefix=O0 --check-prefix=UNIQUE
+; RUN: opt -S -passes='default' -new-pm-pseudo-probe-for-profiling -new-pm-unique-internal-linkage-names -debug-pass-manager < %s 2>&1 | FileCheck %s --check-prefix=O2 --check-prefix=UNIQUE
+; RUN: opt -S -passes='default' -new-pm-pseudo-probe-for-profiling -new-pm-unique-internal-linkage-names -debug-pass-manager < %s 2>&1 | FileCheck %s --check-prefix=O2 --check-prefix=UNIQUE
+; RUN: opt -S -passes='thinlto-pre-link' -new-pm-pseudo-probe-for-profiling -new-pm-unique-internal-linkage-names -debug-pass-manager < %s 2>&1 | FileCheck %s --check-prefix=O2 --check-prefix=UNIQUE
+; RUN: opt -S -passes='thinlto-pre-link' -new-pm-pseudo-probe-for-profiling -new-pm-unique-internal-linkage-names -debug-pass-manager < %s 2>&1 | FileCheck %s --check-prefix=O2 --check-prefix=UNIQUE
+; RUN: opt -S -passes=unique-internal-linkage-names < %s -o - | FileCheck %s --check-prefix=DBG
+
+define internal i32 @foo() !dbg !15 {
+entry:
+  ret i32 0
+}
+
+define dso_local i32 (...)* @bar() {
+entry:
+  ret i32 (...)* bitcast (i32 ()* @foo to i32 (...)*)
+}
+
+define internal i32 @go() !dbg !19 {
+entry:
+  ret i32 0
+}
+
+!llvm.dbg.cu = !{!0}
+!llvm.module.flags = !{!3, !4, !5}
+
+!0 = distinct !DICompileUnit(language: DW_LANG_C99, file: !1, enums: !2)
+!1 = !DIFile(filename: "test.c", directory: "")
+!2 = !{}
+!3 = !{i32 7, !"Dwarf Version", i32 4}
+!4 = !{i32 2, !"Debug Info Version", i32 3}
+!5 = !{i32 1, !"wchar_size", i32 4}
+!13 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
+!15 = distinct !DISubprogram(name: "foo", linkageName: "foo", scope: !1, file: !1, line: 5, type: !16, scopeLine: 5, spFlags: DISPFlagLocalToUnit | DISPFlagDefinition, unit: !0, declaration: !18, retainedNodes: !2)
+!16 = !DISubroutineType(types: !17)
+!17 = !{!13}
+!18 = !DISubprogram(name: "foo", linkageName: "foo", scope: !1, isDefinition: false, flags: DIFlagPrototyped, spFlags: DISPFlagOptimized)
+!19 = distinct !DISubprogram(name: "go", scope: !1, file: !1, line: 5, type: !16, scopeLine: 5, spFlags: DISPFlagLocalToUnit | DISPFlagDefinition, unit: !0, declaration: !18, retainedNodes: !2)
+
+; O0: Running pass: UniqueInternalLinkageNamesPass
+
+;; Check UniqueInternalLinkageNamesPass is scheduled before SampleProfileProbePass.
+; O2: Running pass: UniqueInternalLinkageNamesPass
+; O2: Running p

[PATCH] D92751: [clang][aarch64] Precondition isHomogeneousAggregate on isCXX14Aggregate

2021-01-11 Thread Reid Kleckner via Phabricator via cfe-commits
rnk accepted this revision.
rnk added a comment.
This revision is now accepted and ready to land.

lgtm, thanks




Comment at: llvm/test/CodeGen/AArch64/arm64-windows-calls.ll:117
+  ret %struct.Pod %x1
+; CHECK: ldp d0, d1, [x0]
+}

peterwaller-arm wrote:
> rnk wrote:
> > Please use CHECK-LABEL directives to ensure that these assembly checks are 
> > from the function you intend to match.
> @DavidTruby I think the intent here is:
> 
> CHECK-LABEL: < something matching the first line of the function definition >
> CHECK: 
> 
> CHECK-LABEL: 
> 
> Such that if by some fluke some other function in the interim produces  to be checked>, it won't be allowed to match something produced in the 
> subsequent function. This also renders the code safe against this problem if 
> functions are added or moved around. I suggest having a CHECK-LABEL on each 
> function heading, and the code within those functions should be 
> CHECK/CHECK-NEXT as appropriate.
Yep. I think you could still go further by adding a trailing colon. FileCheck 
matches for substrings of a line, so as written, this could match "call 
copy_pod", which wouldn't be what you want. The risk of that in this test is 
low, but it's a good best practice.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92751

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


[PATCH] D94390: [clangd] Extend find-refs to include overrides.

2021-01-11 Thread Nathan James via Phabricator via cfe-commits
njames93 added a comment.

Should we be providing virtual method overrides when querying definitions, 
surely that's what query implementations is for?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94390

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


[PATCH] D92808: [ObjC][ARC] Annotate calls with attributes instead of emitting retainRV or claimRV calls in the IR

2021-01-11 Thread Akira Hatanaka via Phabricator via cfe-commits
ahatanak updated this revision to Diff 315886.
ahatanak added a comment.

Rebase and fix a few bugs in the patch.

- In the loop in `DeadArgumentEliminationPass::SurveyFunction` that visits the 
uses of a function, continue instead of break so that the function is marked 
live when a function is used by something that isn't a `CallBase`.

- Make `ObjCARCOpt::OptimizeIndividualCallImpl` return early if the instruction 
is a retainRV/claimRV that was temporarily inserted after a call annotated with 
a retainRV/claimRV attribute. This fixes the first assertion in 
`ObjCARCOpt::OptimizeRetainRVCall`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92808

Files:
  clang/lib/CodeGen/CGObjC.cpp
  clang/test/CodeGenObjC/arc-rv-attr.m
  clang/test/CodeGenObjC/arc-unsafeclaim.m
  llvm/include/llvm/Analysis/ObjCARCRVAttr.h
  llvm/lib/IR/Instruction.cpp
  llvm/lib/Transforms/IPO/DeadArgumentElimination.cpp
  llvm/lib/Transforms/ObjCARC/ARCRuntimeEntryPoints.h
  llvm/lib/Transforms/ObjCARC/ObjCARC.cpp
  llvm/lib/Transforms/ObjCARC/ObjCARC.h
  llvm/lib/Transforms/ObjCARC/ObjCARCContract.cpp
  llvm/lib/Transforms/ObjCARC/ObjCARCOpts.cpp
  llvm/lib/Transforms/ObjCARC/PtrState.cpp
  llvm/lib/Transforms/ObjCARC/PtrState.h
  llvm/lib/Transforms/Utils/InlineFunction.cpp
  llvm/test/Transforms/DeadArgElim/deadretval.ll
  llvm/test/Transforms/Inline/inline-retainRV-call.ll
  llvm/test/Transforms/ObjCARC/contract-marker-funclet.ll
  llvm/test/Transforms/ObjCARC/contract-rv-attr.ll
  llvm/test/Transforms/ObjCARC/rv.ll

Index: llvm/test/Transforms/ObjCARC/rv.ll
===
--- llvm/test/Transforms/ObjCARC/rv.ll
+++ llvm/test/Transforms/ObjCARC/rv.ll
@@ -452,6 +452,28 @@
   ret i8* %v3
 }
 
+; Remove attributes and the autoreleaseRV call if the call is a tail call.
+
+; CHECK-LABEL: define i8* @test31(
+; CHECK: %[[CALL:.*]] = tail call i8* @returner()
+; CHECK: ret i8* %[[CALL]]
+
+define i8* @test31() {
+  %call = tail call "retainRV" "rv_marker" i8* @returner()
+  %1 = call i8* @llvm.objc.autoreleaseReturnValue(i8* %call)
+  ret i8* %1
+}
+
+; CHECK-LABEL: define i8* @test32(
+; CHECK: %[[CALL:.*]] = call "retainRV" "rv_marker" i8* @returner()
+; CHECK: call i8* @llvm.objc.autoreleaseReturnValue(i8* %[[CALL]])
+
+define i8* @test32() {
+  %call = call "retainRV" "rv_marker" i8* @returner()
+  %1 = call i8* @llvm.objc.autoreleaseReturnValue(i8* %call)
+  ret i8* %1
+}
+
 !0 = !{}
 
 ; CHECK: attributes [[NUW]] = { nounwind }
Index: llvm/test/Transforms/ObjCARC/contract-rv-attr.ll
===
--- /dev/null
+++ llvm/test/Transforms/ObjCARC/contract-rv-attr.ll
@@ -0,0 +1,63 @@
+; RUN: opt -objc-arc-contract -S < %s | FileCheck %s
+; RUN: opt -passes=objc-arc-contract -S < %s | FileCheck %s
+
+; CHECK-LABEL: define void @test0() {
+; CHECK: %[[CALL:.*]] = notail call "rv_marker" i8* @foo()
+; CHECK: call i8* @llvm.objc.retainAutoreleasedReturnValue(i8* %[[CALL]])
+
+define void @test0() {
+  %call1 = call "retainRV" "rv_marker" i8* @foo()
+  ret void
+}
+
+; CHECK-LABEL: define void @test1() {
+; CHECK: %[[CALL:.*]] = notail call "rv_marker" i8* @foo()
+; CHECK: call i8* @llvm.objc.unsafeClaimAutoreleasedReturnValue(i8* %[[CALL]])
+
+define void @test1() {
+  %call1 = call "claimRV" "rv_marker" i8* @foo()
+  ret void
+}
+
+; CHECK-LABEL:define i8* @test2(
+; CHECK: %[[CALL1:.*]] = invoke "rv_marker" i8* @foo()
+
+; CHECK: %[[V0:.*]] = call i8* @llvm.objc.retainAutoreleasedReturnValue(i8* %[[CALL1]])
+; CHECK-NEXT: br
+
+; CHECK: %[[CALL3:.*]] = invoke "rv_marker" i8* @foo()
+
+; CHECK: %[[V2:.*]] = call i8* @llvm.objc.retainAutoreleasedReturnValue(i8* %[[CALL3]])
+; CHECK-NEXT: br
+
+; CHECK: %[[RETVAL:.*]] = phi i8* [ %[[V0]], {{.*}} ], [ %[[V2]], {{.*}} ]
+; CHECK: ret i8* %[[RETVAL]]
+
+define i8* @test2(i1 zeroext %b) personality i8* bitcast (i32 (...)* @__gxx_personality_v0 to i8*) {
+entry:
+  br i1 %b, label %if.then, label %if.end
+
+if.then:
+  %call1 = invoke "retainRV" "rv_marker" i8* @foo()
+  to label %cleanup unwind label %lpad
+
+lpad:
+  %0 = landingpad { i8*, i32 }
+  cleanup
+  resume { i8*, i32 } undef
+
+if.end:
+  %call3 = invoke "retainRV" "rv_marker" i8* @foo()
+  to label %cleanup unwind label %lpad
+
+cleanup:
+  %retval.0 = phi i8* [ %call1, %if.then ], [ %call3, %if.end ]
+  ret i8* %retval.0
+}
+
+declare i8* @foo()
+declare i32 @__gxx_personality_v0(...)
+
+!llvm.module.flags = !{!0}
+
+!0 = !{i32 1, !"clang.arc.retainAutoreleasedReturnValueMarker", !"mov\09fp, fp\09\09// marker for objc_retainAutoreleaseReturnValue"}
Index: llvm/test/Transforms/ObjCARC/contract-marker-funclet.ll
===
--- llvm/test/Transforms/ObjCARC/contract-marker-funclet.ll
+++ llvm/test/Transforms/ObjCARC/contract-marker-funclet.ll
@@ -10,6 +10,16 @@
 ;   

[PATCH] D94390: [clangd] Extend find-refs to include overrides.

2021-01-11 Thread Utkarsh Saxena via Phabricator via cfe-commits
usaxena95 accepted this revision.
usaxena95 added a comment.
This revision is now accepted and ready to land.

LG. Thanks!




Comment at: clang-tools-extra/clangd/XRefs.cpp:1324
+
+llvm::DenseSet OverrideSymbols;
+if (Index) {

nit: s/OverrideSymbols/Overrides




Comment at: clang-tools-extra/clangd/unittests/XRefsTests.cpp:1834
 
+TEST(FindReferences, IncludeOverrides) {
+  llvm::StringRef Test =

nit: May be include tests for CRTP too.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94390

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


[PATCH] D94438: Fis for Assertion failure on dependent expression.

2021-01-11 Thread Erich Keane via Phabricator via cfe-commits
erichkeane accepted this revision.
erichkeane added a comment.
This revision is now accepted and ready to land.

Fix looks fine, I'm on the fence about how to handle the test, whether it is 
valuable to convert it to a C++ test and omit the #ifdef/extra run line, or 
leave it as it is (without the 2nd run with Wmost).

I'll leave the opinion here to other reviewers/submitter to deal with before 
commit.




Comment at: clang/test/Sema/builtin-returnaddress.c:3
 // RUN: %clang_cc1 -fsyntax-only -Wmost -verify %s
+// RUN: %clang_cc1 -x c++ -fsyntax-only -Wframe-address -verify %s
+// RUN: %clang_cc1 -x c++ -fsyntax-only -Wmost -verify %s

I don't think the -Wmost test 'RUN' line is valuable for the C++ mode, it is 
simply validating that this diagnostic is in Wmost mode (which running in C 
mode is sufficient).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94438

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


[PATCH] D94438: Fis for Assertion failure on dependent expression.

2021-01-11 Thread Sunil Srivastava via Phabricator via cfe-commits
Sunil_Srivastava created this revision.
Sunil_Srivastava added reviewers: jstenglein, erichkeane.
Sunil_Srivastava requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

The check for the value passed to __buildtin_return_address needs to be guarded 
by check for the Dependent context, or else it runs into an assertion failure 
in the test case given below.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D94438

Files:
  clang/lib/Sema/SemaChecking.cpp
  clang/test/Sema/builtin-returnaddress.c


Index: clang/test/Sema/builtin-returnaddress.c
===
--- clang/test/Sema/builtin-returnaddress.c
+++ clang/test/Sema/builtin-returnaddress.c
@@ -1,5 +1,7 @@
 // RUN: %clang_cc1 -fsyntax-only -Wframe-address -verify %s
 // RUN: %clang_cc1 -fsyntax-only -Wmost -verify %s
+// RUN: %clang_cc1 -x c++ -fsyntax-only -Wframe-address -verify %s
+// RUN: %clang_cc1 -x c++ -fsyntax-only -Wmost -verify %s
 
 void* a(unsigned x) {
 return __builtin_return_address(0);
@@ -17,3 +19,14 @@
 return __builtin_frame_address(1); // expected-warning{{calling 
'__builtin_frame_address' with a nonzero argument is unsafe}}
 }
 
+#ifdef __cplusplus
+template void *RA()
+{
+  return __builtin_return_address(N); // expected-warning{{calling 
'__builtin_return_address' with a nonzero argument is unsafe}}
+}
+
+void *foo()
+{
+ return RA<2>(); // expected-note{{in instantiation of function template 
specialization 'RA<2>' requested here}}
+}
+#endif
Index: clang/lib/Sema/SemaChecking.cpp
===
--- clang/lib/Sema/SemaChecking.cpp
+++ clang/lib/Sema/SemaChecking.cpp
@@ -1942,7 +1942,8 @@
 // -Wframe-address warning if non-zero passed to builtin
 // return/frame address.
 Expr::EvalResult Result;
-if (TheCall->getArg(0)->EvaluateAsInt(Result, getASTContext()) &&
+if (!TheCall->getArg(0)->isValueDependent() &&
+TheCall->getArg(0)->EvaluateAsInt(Result, getASTContext()) &&
 Result.Val.getInt() != 0)
   Diag(TheCall->getBeginLoc(), diag::warn_frame_address)
   << ((BuiltinID == Builtin::BI__builtin_return_address)


Index: clang/test/Sema/builtin-returnaddress.c
===
--- clang/test/Sema/builtin-returnaddress.c
+++ clang/test/Sema/builtin-returnaddress.c
@@ -1,5 +1,7 @@
 // RUN: %clang_cc1 -fsyntax-only -Wframe-address -verify %s
 // RUN: %clang_cc1 -fsyntax-only -Wmost -verify %s
+// RUN: %clang_cc1 -x c++ -fsyntax-only -Wframe-address -verify %s
+// RUN: %clang_cc1 -x c++ -fsyntax-only -Wmost -verify %s
 
 void* a(unsigned x) {
 return __builtin_return_address(0);
@@ -17,3 +19,14 @@
 return __builtin_frame_address(1); // expected-warning{{calling '__builtin_frame_address' with a nonzero argument is unsafe}}
 }
 
+#ifdef __cplusplus
+template void *RA()
+{
+  return __builtin_return_address(N); // expected-warning{{calling '__builtin_return_address' with a nonzero argument is unsafe}}
+}
+
+void *foo()
+{
+ return RA<2>(); // expected-note{{in instantiation of function template specialization 'RA<2>' requested here}}
+}
+#endif
Index: clang/lib/Sema/SemaChecking.cpp
===
--- clang/lib/Sema/SemaChecking.cpp
+++ clang/lib/Sema/SemaChecking.cpp
@@ -1942,7 +1942,8 @@
 // -Wframe-address warning if non-zero passed to builtin
 // return/frame address.
 Expr::EvalResult Result;
-if (TheCall->getArg(0)->EvaluateAsInt(Result, getASTContext()) &&
+if (!TheCall->getArg(0)->isValueDependent() &&
+TheCall->getArg(0)->EvaluateAsInt(Result, getASTContext()) &&
 Result.Val.getInt() != 0)
   Diag(TheCall->getBeginLoc(), diag::warn_frame_address)
   << ((BuiltinID == Builtin::BI__builtin_return_address)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D94364: [clang] Allow specifying the aapcs and aapcs-vfp for windows on arm

2021-01-11 Thread Martin Storsjö via Phabricator via cfe-commits
mstorsjo added a comment.

In D94364#2490743 , @compnerd wrote:

> Can you please add some more context around the motivation for this change?  
> It seems ... unnecessary as everything is already AAPCS/AAPCS-VFP.

Yeah it's a redundant attribute, but I don't think we'd need to warn about it, 
but could accept it as well. Aapcs-vfp would be a no-op while plain aapcs would 
pass floats in gprs.

The reason for the patch is from wine; wine uses 
`__attribute__((pcs("aapcs-vfp")))` (within an `#ifdef __GNUC__`) to get the 
right hardfloat calling convention when building for linux with a softfloat ABI 
(like e.g. the android userspace). If using those headers for targeting mingw, 
it triggers warnings with clang - and I didn't see why one shouldn't accept 
these attributes even on that target. I could try making wine stop using the 
redundant attribute when actully building code for a mingw target too, though.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94364

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


[PATCH] D94154: Unique Internal Linkage Name suffixes must be demangler friendly

2021-01-11 Thread Sriraman Tallam via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGd8c6d24359f1: -funique-internal-linkage-names appends a hex 
md5hash suffix to the symbol name… (authored by tmsriram).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94154

Files:
  clang/test/CodeGen/unique-internal-linkage-names.cpp
  llvm/lib/Transforms/Utils/UniqueInternalLinkageNames.cpp
  llvm/test/Transforms/UniqueInternalLinkageNames/unique_symbol_names.ll


Index: llvm/test/Transforms/UniqueInternalLinkageNames/unique_symbol_names.ll
===
--- llvm/test/Transforms/UniqueInternalLinkageNames/unique_symbol_names.ll
+++ llvm/test/Transforms/UniqueInternalLinkageNames/unique_symbol_names.ll
@@ -10,5 +10,5 @@
   ret i32 0
 }
 
-; CHECK: @glob.__uniq.6ae72bb15a7d1834b42ae042a58f7a4d = internal global
-; CHECK: define internal i32 @foo.__uniq.6ae72bb15a7d1834b42ae042a58f7a4d()
+; CHECK: @glob.__uniq.14209847432252523067699167782238157 = internal global
+; CHECK: define internal i32 
@foo.__uniq.14209847432252523067699167782238157()
Index: llvm/lib/Transforms/Utils/UniqueInternalLinkageNames.cpp
===
--- llvm/lib/Transforms/Utils/UniqueInternalLinkageNames.cpp
+++ llvm/lib/Transforms/Utils/UniqueInternalLinkageNames.cpp
@@ -27,9 +27,12 @@
   Md5.final(R);
   SmallString<32> Str;
   llvm::MD5::stringifyResult(R, Str);
+  // Convert MD5hash to Decimal. Demangler suffixes can either contain numbers
+  // or characters but not both.
+  APInt IntHash = APInt(128, Str.str(), 16);
   // Prepend "__uniq" before the hash for tools like profilers to understand 
that
   // this symbol is of internal linkage type.
-  std::string ModuleNameHash = (Twine(".__uniq.") + Twine(Str)).str();
+  std::string ModuleNameHash = (Twine(".__uniq.") + Twine(IntHash.toString(10, 
false))).str();
   bool Changed = false;
 
   // Append the module hash to all internal linkage functions.
Index: clang/test/CodeGen/unique-internal-linkage-names.cpp
===
--- clang/test/CodeGen/unique-internal-linkage-names.cpp
+++ clang/test/CodeGen/unique-internal-linkage-names.cpp
@@ -53,15 +53,15 @@
 // PLAIN: define weak_odr i32 ()* @_ZL4mverv.resolver()
 // PLAIN: define internal i32 @_ZL4mverv()
 // PLAIN: define internal i32 @_ZL4mverv.sse4.2()
-// UNIQUE: @_ZL4glob.__uniq.{{[0-9a-f]+}} = internal global
-// UNIQUE: @_ZZ8retAnonMvE5fGlob.__uniq.{{[0-9a-f]+}} = internal global
-// UNIQUE: @_ZN12_GLOBAL__N_16anon_mE.__uniq.{{[0-9a-f]+}} = internal global
-// UNIQUE: define internal i32 @_ZL3foov.__uniq.{{[0-9a-f]+}}()
-// UNIQUE: define internal i32 @_ZN12_GLOBAL__N_14getMEv.__uniq.{{[0-9a-f]+}}
+// UNIQUE: @_ZL4glob.__uniq.{{[0-9]+}} = internal global
+// UNIQUE: @_ZZ8retAnonMvE5fGlob.__uniq.{{[0-9]+}} = internal global
+// UNIQUE: @_ZN12_GLOBAL__N_16anon_mE.__uniq.{{[0-9]+}} = internal global
+// UNIQUE: define internal i32 @_ZL3foov.__uniq.{{[0-9]+}}()
+// UNIQUE: define internal i32 @_ZN12_GLOBAL__N_14getMEv.__uniq.{{[0-9]+}}
 // UNIQUE: define weak_odr i32 ()* @_ZL4mverv.resolver()
-// UNIQUE: define internal i32 @_ZL4mverv.__uniq.{{[0-9a-f]+}}()
-// UNIQUE: define internal i32 @_ZL4mverv.sse4.2.__uniq.{{[0-9a-f]+}}
-// UNIQUEO1: define internal i32 @_ZL3foov.__uniq.{{[0-9a-f]+}}()
+// UNIQUE: define internal i32 @_ZL4mverv.__uniq.{{[0-9]+}}()
+// UNIQUE: define internal i32 @_ZL4mverv.sse4.2.__uniq.{{[0-9]+}}
+// UNIQUEO1: define internal i32 @_ZL3foov.__uniq.{{[0-9]+}}()
 // UNIQUEO1: define weak_odr i32 ()* @_ZL4mverv.resolver()
-// UNIQUEO1: define internal i32 @_ZL4mverv.__uniq.{{[0-9a-f]+}}()
-// UNIQUEO1: define internal i32 @_ZL4mverv.sse4.2.__uniq.{{[0-9a-f]+}}
+// UNIQUEO1: define internal i32 @_ZL4mverv.__uniq.{{[0-9]+}}()
+// UNIQUEO1: define internal i32 @_ZL4mverv.sse4.2.__uniq.{{[0-9]+}}


Index: llvm/test/Transforms/UniqueInternalLinkageNames/unique_symbol_names.ll
===
--- llvm/test/Transforms/UniqueInternalLinkageNames/unique_symbol_names.ll
+++ llvm/test/Transforms/UniqueInternalLinkageNames/unique_symbol_names.ll
@@ -10,5 +10,5 @@
   ret i32 0
 }
 
-; CHECK: @glob.__uniq.6ae72bb15a7d1834b42ae042a58f7a4d = internal global
-; CHECK: define internal i32 @foo.__uniq.6ae72bb15a7d1834b42ae042a58f7a4d()
+; CHECK: @glob.__uniq.14209847432252523067699167782238157 = internal global
+; CHECK: define internal i32 @foo.__uniq.14209847432252523067699167782238157()
Index: llvm/lib/Transforms/Utils/UniqueInternalLinkageNames.cpp
===
--- llvm/lib/Transforms/Utils/UniqueInternalLinkageNames.cpp
+++ llvm/lib/Transforms/Utils/UniqueInternalLinkageNames.cpp
@@ -27,9 +27,12 @@

[clang] d8c6d24 - -funique-internal-linkage-names appends a hex md5hash suffix to the symbol name which is not demangler friendly, convert it to decimal.

2021-01-11 Thread Sriraman Tallam via cfe-commits

Author: Sriraman Tallam
Date: 2021-01-11T11:10:29-08:00
New Revision: d8c6d24359f17c55a8966231ef74e8f4b03ad282

URL: 
https://github.com/llvm/llvm-project/commit/d8c6d24359f17c55a8966231ef74e8f4b03ad282
DIFF: 
https://github.com/llvm/llvm-project/commit/d8c6d24359f17c55a8966231ef74e8f4b03ad282.diff

LOG: -funique-internal-linkage-names appends a hex md5hash suffix to the symbol 
name which is not demangler friendly, convert it to decimal.

Please see D93747 for more context which tries to make linkage names of internal
linkage functions to be the uniqueified names. This causes a problem with gdb
because breaking using the demangled function name will not work if the new
uniqueified name cannot be demangled. The problem is the generated suffix which
is a mix of integers and letters which do not demangle. The demangler accepts
either all numbers or all letters. This patch simply converts the hash to 
decimal.

There is no loss of uniqueness by doing this as the precision is maintained.
The symbol names get longer by a few characters though.

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

Added: 


Modified: 
clang/test/CodeGen/unique-internal-linkage-names.cpp
llvm/lib/Transforms/Utils/UniqueInternalLinkageNames.cpp
llvm/test/Transforms/UniqueInternalLinkageNames/unique_symbol_names.ll

Removed: 




diff  --git a/clang/test/CodeGen/unique-internal-linkage-names.cpp 
b/clang/test/CodeGen/unique-internal-linkage-names.cpp
index 3ad3bdc9f1bbb..b731ed07f4a76 100644
--- a/clang/test/CodeGen/unique-internal-linkage-names.cpp
+++ b/clang/test/CodeGen/unique-internal-linkage-names.cpp
@@ -53,15 +53,15 @@ int mver_call() {
 // PLAIN: define weak_odr i32 ()* @_ZL4mverv.resolver()
 // PLAIN: define internal i32 @_ZL4mverv()
 // PLAIN: define internal i32 @_ZL4mverv.sse4.2()
-// UNIQUE: @_ZL4glob.__uniq.{{[0-9a-f]+}} = internal global
-// UNIQUE: @_ZZ8retAnonMvE5fGlob.__uniq.{{[0-9a-f]+}} = internal global
-// UNIQUE: @_ZN12_GLOBAL__N_16anon_mE.__uniq.{{[0-9a-f]+}} = internal global
-// UNIQUE: define internal i32 @_ZL3foov.__uniq.{{[0-9a-f]+}}()
-// UNIQUE: define internal i32 @_ZN12_GLOBAL__N_14getMEv.__uniq.{{[0-9a-f]+}}
+// UNIQUE: @_ZL4glob.__uniq.{{[0-9]+}} = internal global
+// UNIQUE: @_ZZ8retAnonMvE5fGlob.__uniq.{{[0-9]+}} = internal global
+// UNIQUE: @_ZN12_GLOBAL__N_16anon_mE.__uniq.{{[0-9]+}} = internal global
+// UNIQUE: define internal i32 @_ZL3foov.__uniq.{{[0-9]+}}()
+// UNIQUE: define internal i32 @_ZN12_GLOBAL__N_14getMEv.__uniq.{{[0-9]+}}
 // UNIQUE: define weak_odr i32 ()* @_ZL4mverv.resolver()
-// UNIQUE: define internal i32 @_ZL4mverv.__uniq.{{[0-9a-f]+}}()
-// UNIQUE: define internal i32 @_ZL4mverv.sse4.2.__uniq.{{[0-9a-f]+}}
-// UNIQUEO1: define internal i32 @_ZL3foov.__uniq.{{[0-9a-f]+}}()
+// UNIQUE: define internal i32 @_ZL4mverv.__uniq.{{[0-9]+}}()
+// UNIQUE: define internal i32 @_ZL4mverv.sse4.2.__uniq.{{[0-9]+}}
+// UNIQUEO1: define internal i32 @_ZL3foov.__uniq.{{[0-9]+}}()
 // UNIQUEO1: define weak_odr i32 ()* @_ZL4mverv.resolver()
-// UNIQUEO1: define internal i32 @_ZL4mverv.__uniq.{{[0-9a-f]+}}()
-// UNIQUEO1: define internal i32 @_ZL4mverv.sse4.2.__uniq.{{[0-9a-f]+}}
+// UNIQUEO1: define internal i32 @_ZL4mverv.__uniq.{{[0-9]+}}()
+// UNIQUEO1: define internal i32 @_ZL4mverv.sse4.2.__uniq.{{[0-9]+}}

diff  --git a/llvm/lib/Transforms/Utils/UniqueInternalLinkageNames.cpp 
b/llvm/lib/Transforms/Utils/UniqueInternalLinkageNames.cpp
index 385bf8bb429ae..29ad0b6fcae50 100644
--- a/llvm/lib/Transforms/Utils/UniqueInternalLinkageNames.cpp
+++ b/llvm/lib/Transforms/Utils/UniqueInternalLinkageNames.cpp
@@ -27,9 +27,12 @@ static bool uniqueifyInternalLinkageNames(Module &M) {
   Md5.final(R);
   SmallString<32> Str;
   llvm::MD5::stringifyResult(R, Str);
+  // Convert MD5hash to Decimal. Demangler suffixes can either contain numbers
+  // or characters but not both.
+  APInt IntHash = APInt(128, Str.str(), 16);
   // Prepend "__uniq" before the hash for tools like profilers to understand 
that
   // this symbol is of internal linkage type.
-  std::string ModuleNameHash = (Twine(".__uniq.") + Twine(Str)).str();
+  std::string ModuleNameHash = (Twine(".__uniq.") + Twine(IntHash.toString(10, 
false))).str();
   bool Changed = false;
 
   // Append the module hash to all internal linkage functions.

diff  --git 
a/llvm/test/Transforms/UniqueInternalLinkageNames/unique_symbol_names.ll 
b/llvm/test/Transforms/UniqueInternalLinkageNames/unique_symbol_names.ll
index bf15daebda383..492c716a0bb11 100644
--- a/llvm/test/Transforms/UniqueInternalLinkageNames/unique_symbol_names.ll
+++ b/llvm/test/Transforms/UniqueInternalLinkageNames/unique_symbol_names.ll
@@ -10,5 +10,5 @@ entry:
   ret i32 0
 }
 
-; CHECK: @glob.__uniq.6ae72bb15a7d1834b42ae042a58f7a4d = internal global
-; CHECK: define internal i32 @foo.__uniq.6ae72bb15a7d1834b42ae042a58f7a4d()
+; CHECK: @glob.__uniq.142098474322525230676991677

[PATCH] D94337: Add cuda header type for cuh files

2021-01-11 Thread Artem Belevich via Phabricator via cfe-commits
tra added a comment.

> This adds a cuda header type with file extension "cuh". The output type file
> extension is "cuhi" - not sure if this is a good choice. This allows
> language servers to properly handle cuh files without additional arguments.

CUDA compilation is ... odd. While I don't have strong objections to this 
change, I'm also not convinced that it's particularly useful, either.

The problem is that just telling compiler that the header is a CUDA source is 
not sufficient. Clang relies on a lot of CUDA SDK headers in order to make the 
standard CUDA things like `__host__`, '__device__', `threadIdx`, etc work. For 
the CUDA source files clang pre-includes a lot of headers. I'm not quite sure 
what clang would be supposed to do when it's given a `.cuh` as an input. If we 
pre-include the CUDA headers as we do for `.cu` compilation, we'll get way more 
of the preprocessed output than the user would likely expect. If we do not 
pre-include CUDA headers, we'll not get CUDA macros expanded and the output 
would not be suitable to pass on to the further compilation. On one hand it 
does not make things worse. On the other, it does not make them better, either. 
If anything, Clang not recognizing CUDA headers on their own is probably better 
than accepting them and producing invalid output.

Perhaps I'm missing something. Do you have specific use case in mind for this 
change?

Also, AFAICT, there's no such thing as a canonical CUDA header file extension. 
Some projects use `.cuh`, some use `.cu.h`, some use just `.h` and other C++ 
extensions, so this change would only help with a subset of the headers.

Then there's the fact that for CUDA compilation clang needs the headers from 
CUDA SDK. You can't just take a CUDA header and preprocess it with the default 
flags. If you want the preprocessed file content to match what would be seen in 
a real compilation when the header is included from the CUDA source file, you 
must ensure that the header was preprocesses with exactly the same CUDA SDK as 
the source file it would be included from. In general, `--cuda-path` should 
probably be treated as a required argument. I do not see a practical way to 
make `properly handle cuh files without additional arguments` work reliably. 
For that we'd need Clang to carry all required CUDA headers and that's not 
going to happen any time soon. That said, it may be worth considering 
implementing a `stand-alone` CUDA compilation mode which would provide the bare 
minimum of CUDA headers without having to include CUDA SDK headers. **That** 
would be useful for various tooling scenarios where we may need to deal with 
CUDA sources/headers but where we do not have CUDA SDK available and/or do not 
have access to correct `--cuda-path`. That would probably need to be 
implemented first. Once it's in place, preprocessing a CUDA header may make 
more sense as we'll be able to produce preprocessed output that would be closer 
to what would be expected from a preprocessor -- something compileable without 
too much extra stuff.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94337

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


[PATCH] D93703: [libTooling] Change `addInclude` to use expansion locs.

2021-01-11 Thread Yitzhak Mandelbaum via Phabricator via cfe-commits
ymandel added a comment.

Gentle ping...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93703

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


[PATCH] D87702: [Frontend] Add pragma align natural and sort out pragma pack stack effect

2021-01-11 Thread Xiangling Liao via Phabricator via cfe-commits
Xiangling_L updated this revision to Diff 315855.
Xiangling_L marked 4 inline comments as done.
Xiangling_L added a comment.

Rebased on latest master;
Addressed the comments;


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

https://reviews.llvm.org/D87702

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Driver/Options.td
  clang/include/clang/Sema/Sema.h
  clang/include/clang/Serialization/ASTReader.h
  clang/include/clang/Serialization/ASTWriter.h
  clang/lib/AST/RecordLayoutBuilder.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/lib/Parse/ParsePragma.cpp
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaAttr.cpp
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/test/Driver/aix-pragma-pack.c
  clang/test/Layout/aix-double-struct-member.cpp
  clang/test/Layout/aix-power-natural-interaction.cpp
  clang/test/PCH/aix-pragma-pack.c
  clang/test/Sema/aix-pragma-pack-and-align.c

Index: clang/test/Sema/aix-pragma-pack-and-align.c
===
--- /dev/null
+++ clang/test/Sema/aix-pragma-pack-and-align.c
@@ -0,0 +1,231 @@
+// RUN: %clang_cc1 -triple powerpc-ibm-aix-xcoff -fdump-record-layouts \
+// RUN: -fxl-pragma-pack -verify -fsyntax-only -x c++ %s | \
+// RUN:   FileCheck %s
+
+// RUN: %clang_cc1 -triple powerpc64-ibm-aix-xcoff -fdump-record-layouts \
+// RUN: -fxl-pragma-pack -verify -fsyntax-only -x c++ %s | \
+// RUN:   FileCheck %s
+
+namespace test1 {
+#pragma align(natural)
+#pragma pack(4)
+#pragma pack(2)
+struct A {
+  int i;
+  double d;
+};
+
+int a = sizeof(A);
+#pragma pack()
+#pragma pack(show) // expected-warning {{value of #pragma pack(show) == 4}}
+#pragma pack(pop)
+#pragma pack(show) // expected-warning {{value of #pragma pack(show) == 8}}
+struct B {
+  int i;
+  double d;
+};
+#pragma align(reset)
+
+int b = sizeof(B);
+
+// CHECK:  *** Dumping AST Record Layout
+// CHECK-NEXT:  0 | struct test1::A
+// CHECK-NEXT:  0 |   int i
+// CHECK-NEXT:  4 |   double d
+// CHECK-NEXT:| [sizeof=12, dsize=12, align=2, preferredalign=2,
+// CHECK-NEXT:|  nvsize=12, nvalign=2, preferrednvalign=2]
+
+// CHECK:  *** Dumping AST Record Layout
+// CHECK-NEXT:  0 | struct test1::B
+// CHECK-NEXT:  0 |   int i
+// CHECK-NEXT:  8 |   double d
+// CHECK-NEXT:| [sizeof=16, dsize=16, align=4, preferredalign=8,
+// CHECK-NEXT:|  nvsize=16, nvalign=4, preferrednvalign=8]
+
+} // namespace test1
+
+namespace test2 {
+#pragma align(natural)
+#pragma pack(2)
+struct A {
+  int i;
+  double d;
+};
+
+int a = sizeof(A);
+#pragma align(reset)
+
+struct B {
+  int i;
+  double d;
+};
+
+int b = sizeof(B);
+
+// CHECK:  *** Dumping AST Record Layout
+// CHECK-NEXT:  0 | struct test2::A
+// CHECK-NEXT:  0 |   int i
+// CHECK-NEXT:  4 |   double d
+// CHECK-NEXT:| [sizeof=12, dsize=12, align=2, preferredalign=2,
+// CHECK-NEXT:|  nvsize=12, nvalign=2, preferrednvalign=2]
+
+// CHECK:  *** Dumping AST Record Layout
+// CHECK-NEXT:  0 | struct test2::B
+// CHECK-NEXT:  0 |   int i
+// CHECK-NEXT:  4 |   double d
+// CHECK-NEXT:| [sizeof=12, dsize=12, align=4, preferredalign=4,
+// CHECK-NEXT:|  nvsize=12, nvalign=4, preferrednvalign=4]
+
+} // namespace test2
+
+namespace test3 {
+#pragma pack(2)
+#pragma align(natural)
+struct A {
+  double d;
+};
+#pragma align(reset)
+#pragma pack(pop)
+
+int a = sizeof(A);
+
+// CHECK:  *** Dumping AST Record Layout
+// CHECK-NEXT:  0 | struct test3::A
+// CHECK-NEXT:  0 |   double d
+// CHECK-NEXT:| [sizeof=8, dsize=8, align=4, preferredalign=8,
+// CHECK-NEXT:|  nvsize=8, nvalign=4, preferrednvalign=8]
+
+} // namespace test3
+
+namespace test4 {
+#pragma pack(2)
+#pragma align(natural)
+#pragma pack(pop)
+
+struct A {
+  int i;
+  double d;
+} a;
+#pragma align(reset)
+#pragma pack(pop)
+
+int i = sizeof(A);
+
+// CHECK:  *** Dumping AST Record Layout
+// CHECK-NEXT:  0 | struct test4::A
+// CHECK-NEXT:  0 |   int i
+// CHECK-NEXT:  8 |   double d
+// CHECK-NEXT:| [sizeof=16, dsize=16, align=4, preferredalign=8,
+// CHECK-NEXT:|  nvsize=16, nvalign=4, preferrednvalign=8]
+
+} // namespace test4
+
+namespace test5 {
+#pragma align(power)
+#pragma align(natural)
+#pragma pack(2)
+#pragma align(reset)
+struct A {
+  int i;
+  double d;
+};
+#pragma align(reset)
+
+int a = sizeof(A);
+
+// CHECK:  *** Dumping AST Record Layout
+// CHECK-NEXT:  0 | struct test5::A
+// CHECK-NEXT:  0 |   int i
+// CHECK-NEXT:  4 |   double d
+// CHECK-NEXT:| [sizeof=12, dsize=12, align=4, preferreda

[PATCH] D94364: [clang] Allow specifying the aapcs and aapcs-vfp for windows on arm

2021-01-11 Thread Saleem Abdulrasool via Phabricator via cfe-commits
compnerd added a comment.

Can you please add some more context around the motivation for this change?  It 
seems ... unnecessary as everything is already AAPCS/AAPCS-VFP.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94364

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


[clang] 35c9baa - [attributes] Add a facility for enforcing a Trusted Computing Base.

2021-01-11 Thread Artem Dergachev via cfe-commits

Author: Sean Dooher
Date: 2021-01-11T10:20:51-08:00
New Revision: 35c9baa11e4be6ae570674eec2de8bd928639b18

URL: 
https://github.com/llvm/llvm-project/commit/35c9baa11e4be6ae570674eec2de8bd928639b18
DIFF: 
https://github.com/llvm/llvm-project/commit/35c9baa11e4be6ae570674eec2de8bd928639b18.diff

LOG: [attributes]  Add a facility for enforcing a Trusted Computing Base.

Introduce a function attribute 'enforce_tcb' that prevents the function
from calling other functions without the same attribute. This allows
isolating code that's considered to be somehow privileged so that it could not
use its privileges to exhibit arbitrary behavior.

Introduce an on-by-default warning '-Wtcb-enforcement' that warns
about violations of the above rule.

Introduce a function attribute 'enforce_tcb_leaf' that suppresses
the new warning within the function it is attached to. Such leaf functions
may implement common functionality between the trusted and the untrusted code
but they require extra careful audit with respect to their capabilities.

Fixes after a revert in 419ef38a50293c58078f830517f5e305068dbee6:
Fix a test.
Add workaround for GCC bug (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67274).
Attribute the patch appropriately!

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

Added: 
clang/test/Sema/attr-enforce-tcb-errors.cpp
clang/test/Sema/attr-enforce-tcb.c
clang/test/Sema/attr-enforce-tcb.cpp

Modified: 
clang/include/clang/Basic/Attr.td
clang/include/clang/Basic/AttrDocs.td
clang/include/clang/Basic/DiagnosticSemaKinds.td
clang/include/clang/Sema/Sema.h
clang/lib/Sema/SemaChecking.cpp
clang/lib/Sema/SemaDecl.cpp
clang/lib/Sema/SemaDeclAttr.cpp
clang/test/Misc/pragma-attribute-supported-attributes-list.test

Removed: 




diff  --git a/clang/include/clang/Basic/Attr.td 
b/clang/include/clang/Basic/Attr.td
index 248409946123e..c51e95fa6fa87 100644
--- a/clang/include/clang/Basic/Attr.td
+++ b/clang/include/clang/Basic/Attr.td
@@ -3653,3 +3653,19 @@ def Builtin : InheritableAttr {
   let SemaHandler = 0;
   let Documentation = [Undocumented];
 }
+
+def EnforceTCB : InheritableAttr {
+  let Spellings = [Clang<"enforce_tcb">];
+  let Subjects = SubjectList<[Function]>;
+  let Args = [StringArgument<"TCBName">];
+  let Documentation = [EnforceTCBDocs];
+  bit InheritEvenIfAlreadyPresent = 1;
+}
+
+def EnforceTCBLeaf : InheritableAttr {
+  let Spellings = [Clang<"enforce_tcb_leaf">];
+  let Subjects = SubjectList<[Function]>;
+  let Args = [StringArgument<"TCBName">];
+  let Documentation = [EnforceTCBLeafDocs];
+  bit InheritEvenIfAlreadyPresent = 1;
+}

diff  --git a/clang/include/clang/Basic/AttrDocs.td 
b/clang/include/clang/Basic/AttrDocs.td
index 9cf0c59e07bba..fffede41db1e8 100644
--- a/clang/include/clang/Basic/AttrDocs.td
+++ b/clang/include/clang/Basic/AttrDocs.td
@@ -5725,3 +5725,28 @@ Attribute docs`_, and `the GCC Inline docs`_.
 }];
   let Heading = "always_inline, __force_inline";
 }
+
+def EnforceTCBDocs : Documentation {
+  let Category = DocCatFunction;
+  let Content = [{
+  The ``enforce_tcb`` attribute can be placed on functions to enforce that a
+  trusted compute base (TCB) does not call out of the TCB. This generates a
+  warning every time a function not marked with an ``enforce_tcb`` attribute is
+  called from a function with the ``enforce_tcb`` attribute. A function may be 
a
+  part of multiple TCBs. Invocations through function pointers are currently
+  not checked. Builtins are considered to a part of every TCB.
+
+  - ``enforce_tcb(Name)`` indicates that this function is a part of the TCB 
named ``Name``
+  }];
+}
+
+def EnforceTCBLeafDocs : Documentation {
+  let Category = DocCatFunction;
+  let Content = [{
+  The ``enforce_tcb_leaf`` attribute satisfies the requirement enforced by
+  ``enforce_tcb`` for the marked function to be in the named TCB but does not
+  continue to check the functions called from within the leaf function.
+
+  - ``enforce_tcb_leaf(Name)`` indicates that this function is a part of the 
TCB named ``Name``
+  }];
+}

diff  --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index 0405195912b23..c048fc89813f8 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -6,4 +6,11 @@ def err_probability_not_constant_float : Error<
 def err_probability_out_of_range : Error<
"probability argument to __builtin_expect_with_probability is outside the "
"range [0.0, 1.0]">;
+
+// TCB warnings
+def err_tcb_conflicting_attributes : Error<
+  "attributes '%0(\"%2\")' and '%1(\"%2\")' are mutually exclusive">;
+def warn_tcb_enforcement_violation : Warning<
+  "calling %0 is a violation of trusted computing base '%1'">,
+  InGroup>;
 } // end of sema component.

diff  --git a/clang/include/clang/Sema/Sema.h b/clan

[PATCH] D93873: [clangd] Cache preambles of closed files

2021-01-11 Thread Quentin Chateau via Phabricator via cfe-commits
qchateau added a comment.

Hey, don't worry about the delay, I won't have as much time on my hands anymore 
anyway.

- we can definitely make this opt-in
- MB instead of # is an idea, it's probably closer to what the user want to 
configure - if he does - but it would also probably give a worse default value. 
Your call !
- I mean why not, but this diff was more about bringing the feature in than 
making it perfect. The heuristic to decide how to evict preambles can be made 
very complicated if we want to optimize it
- we can do as you suggest, it related to the previous point
- Ah ! What would you recommend ? No forget it, I'll just make it opt-it for now

I've also tried to keep the ASTWorkers alive in a different branch. The result 
is very different: ASTWorkers always use RAM so we can't keep as many, but 
keeping them alive makes is even better (15s with no cache, 2s with preamble 
cache, virtually 0s with ASTWorker cache). I'd say both features are nice but 
they give different results for a different cost.
Also it would be great to stop the ASTWorker threads when they are just in 
cache, but the class needs a rework to be able to stop/restart it


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93873

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


[PATCH] D94374: [CMake] Remove dead code setting policies to NEW

2021-01-11 Thread Raul Tambre via Phabricator via cfe-commits
tambre updated this revision to Diff 315847.
tambre added a comment.

Don't modify third-party checked-in libraries.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94374

Files:
  clang/CMakeLists.txt
  compiler-rt/CMakeLists.txt
  flang/CMakeLists.txt
  libcxx/CMakeLists.txt
  libcxx/utils/ci/runtimes/CMakeLists.txt
  libcxxabi/CMakeLists.txt
  libunwind/CMakeLists.txt
  lldb/CMakeLists.txt
  llvm/CMakeLists.txt
  mlir/examples/standalone/CMakeLists.txt

Index: mlir/examples/standalone/CMakeLists.txt
===
--- mlir/examples/standalone/CMakeLists.txt
+++ mlir/examples/standalone/CMakeLists.txt
@@ -1,20 +1,8 @@
 cmake_minimum_required(VERSION 3.13.4)
-
-if(POLICY CMP0068)
-  cmake_policy(SET CMP0068 NEW)
-  set(CMAKE_BUILD_WITH_INSTALL_NAME_DIR ON)
-endif()
-
-if(POLICY CMP0075)
-  cmake_policy(SET CMP0075 NEW)
-endif()
-
-if(POLICY CMP0077)
-  cmake_policy(SET CMP0077 NEW)
-endif()
-
 project(standalone-dialect LANGUAGES CXX C)
 
+set(CMAKE_BUILD_WITH_INSTALL_NAME_DIR ON)
+
 set(CMAKE_CXX_STANDARD 14 CACHE STRING "C++ standard to conform to")
 
 find_package(MLIR REQUIRED CONFIG)
Index: llvm/CMakeLists.txt
===
--- llvm/CMakeLists.txt
+++ llvm/CMakeLists.txt
@@ -2,18 +2,7 @@
 
 cmake_minimum_required(VERSION 3.13.4)
 
-if(POLICY CMP0068)
-  cmake_policy(SET CMP0068 NEW)
-  set(CMAKE_BUILD_WITH_INSTALL_NAME_DIR ON)
-endif()
-
-if(POLICY CMP0075)
-  cmake_policy(SET CMP0075 NEW)
-endif()
-
-if(POLICY CMP0077)
-  cmake_policy(SET CMP0077 NEW)
-endif()
+set(CMAKE_BUILD_WITH_INSTALL_NAME_DIR ON)
 
 if(NOT DEFINED LLVM_VERSION_MAJOR)
   set(LLVM_VERSION_MAJOR 12)
Index: lldb/CMakeLists.txt
===
--- lldb/CMakeLists.txt
+++ lldb/CMakeLists.txt
@@ -1,13 +1,5 @@
 cmake_minimum_required(VERSION 3.13.4)
 
-if(POLICY CMP0075)
-  cmake_policy(SET CMP0075 NEW)
-endif()
-
-if(POLICY CMP0077)
-  cmake_policy(SET CMP0077 NEW)
-endif()
-
 # Add path for custom modules.
 set(CMAKE_MODULE_PATH
   ${CMAKE_MODULE_PATH}
Index: libunwind/CMakeLists.txt
===
--- libunwind/CMakeLists.txt
+++ libunwind/CMakeLists.txt
@@ -8,10 +8,6 @@
 
 cmake_minimum_required(VERSION 3.13.4)
 
-if (POLICY CMP0042)
-  cmake_policy(SET CMP0042 NEW) # Set MACOSX_RPATH=YES by default
-endif()
-
 # Add path for custom modules
 set(CMAKE_MODULE_PATH
   "${CMAKE_CURRENT_SOURCE_DIR}/cmake"
Index: libcxxabi/CMakeLists.txt
===
--- libcxxabi/CMakeLists.txt
+++ libcxxabi/CMakeLists.txt
@@ -10,10 +10,6 @@
 
 cmake_minimum_required(VERSION 3.13.4)
 
-if(POLICY CMP0042)
-  cmake_policy(SET CMP0042 NEW) # Set MACOSX_RPATH=YES by default
-endif()
-
 # Add path for custom modules
 set(CMAKE_MODULE_PATH
   "${CMAKE_CURRENT_SOURCE_DIR}/cmake"
Index: libcxx/utils/ci/runtimes/CMakeLists.txt
===
--- libcxx/utils/ci/runtimes/CMakeLists.txt
+++ libcxx/utils/ci/runtimes/CMakeLists.txt
@@ -1,20 +1,8 @@
 cmake_minimum_required(VERSION 3.13.4)
-
-if(POLICY CMP0068)
-  cmake_policy(SET CMP0068 NEW)
-  set(CMAKE_BUILD_WITH_INSTALL_NAME_DIR ON)
-endif()
-
-if(POLICY CMP0075)
-  cmake_policy(SET CMP0075 NEW)
-endif()
-
-if(POLICY CMP0077)
-  cmake_policy(SET CMP0077 NEW)
-endif()
-
 project(LLVM_RUNTIMES)
 
+set(CMAKE_BUILD_WITH_INSTALL_NAME_DIR ON)
+
 find_package(Python3 COMPONENTS Interpreter)
 if(NOT Python3_Interpreter_FOUND)
   message(WARNING "Python3 not found, using python2 as a fallback")
Index: libcxx/CMakeLists.txt
===
--- libcxx/CMakeLists.txt
+++ libcxx/CMakeLists.txt
@@ -10,16 +10,7 @@
 #===
 cmake_minimum_required(VERSION 3.13.4)
 
-if(POLICY CMP0042)
-  cmake_policy(SET CMP0042 NEW) # Set MACOSX_RPATH=YES by default
-endif()
-if(POLICY CMP0022)
-  cmake_policy(SET CMP0022 NEW) # Required when interacting with LLVM and Clang
-endif()
-if(POLICY CMP0068)
-  cmake_policy(SET CMP0068 NEW)
-  set(CMAKE_BUILD_WITH_INSTALL_NAME_DIR ON)
-endif()
+set(CMAKE_BUILD_WITH_INSTALL_NAME_DIR ON)
 
 # Add path for custom modules
 set(CMAKE_MODULE_PATH
Index: flang/CMakeLists.txt
===
--- flang/CMakeLists.txt
+++ flang/CMakeLists.txt
@@ -1,20 +1,6 @@
 cmake_minimum_required(VERSION 3.13.4)
 
-# RPATH settings on macOS do not affect INSTALL_NAME.
-if (POLICY CMP0068)
-  cmake_policy(SET CMP0068 NEW)
-  set(CMAKE_BUILD_WITH_INSTALL_NAME_DIR ON)
-endif()
-
-# Include file check macros honor CMAKE_REQUIRED_LIBRARIES.
-if(POLICY CMP0075)
-  cmake_policy(SET CMP0075 NEW)
-endif()
-
-# option() honors normal variables.
-if (POLICY CMP0

[PATCH] D94374: [CMake] Remove dead code setting policies to NEW

2021-01-11 Thread Raul Tambre via Phabricator via cfe-commits
tambre marked an inline comment as done.
tambre added inline comments.



Comment at: libcxx/utils/google-benchmark/CMakeLists.txt:3
-
-project (benchmark)
-

ldionne wrote:
> I don't think we want to change this. It's a third-party project (which is 
> inconveniently checked-in as-is into our tree..).
Good catch. Did the same for `llvm/utils/benchmark/CMakeLists.txt`, though that 
one seems to have the `cmake_minimum_required(VERSION)` updated to 3.13.4 
unlike this one.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94374

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


[PATCH] D92024: [clang] Implement P0692R1 from C++20 (access checking on specializations and instantiations)

2021-01-11 Thread Alex Orlov via Phabricator via cfe-commits
aorlov added inline comments.



Comment at: clang/test/CXX/class.access/class.friend/p1.cpp:290
   A::I f2(A::I i = A::x) {} // expected-error 3 {{is a private member of}}
-  template A::I g2(A::I i) { // expected-error 2 {{is a private 
member of}}
+  template  A::I g2(A::I i) { // expected-error {{is a private 
member of}}
 T t;

Quuxplusone wrote:
> This whitespace diff is gratuitous.
This is done by clang-format. I think we should keep it here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92024

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


[PATCH] D92024: [clang] Implement P0692R1 from C++20 (access checking on specializations and instantiations)

2021-01-11 Thread Alex Orlov via Phabricator via cfe-commits
aorlov updated this revision to Diff 315840.
aorlov added a comment.

@Quuxplusone 
Thank you for your comments. I updated the patch according to your suggestions.
Does anyone else from the review list want to waste some time to look at this 
patch? I would appreciate this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92024

Files:
  clang/include/clang/Sema/DelayedDiagnostic.h
  clang/lib/Parse/ParseDecl.cpp
  clang/lib/Parse/ParseDeclCXX.cpp
  clang/lib/Parse/ParseTemplate.cpp
  clang/test/CXX/class.access/class.friend/p1.cpp
  clang/test/CXX/drs/dr1xx.cpp
  clang/test/CXX/temp/temp.spec/func.spec.cpp
  clang/test/CXX/temp/temp.spec/part.spec.cpp

Index: clang/test/CXX/temp/temp.spec/part.spec.cpp
===
--- /dev/null
+++ clang/test/CXX/temp/temp.spec/part.spec.cpp
@@ -0,0 +1,477 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+
+// C++20 [temp.class.spec] 17.6.5/10:
+//   The usual access checking rules do not apply to non-dependent names used
+//   to specify template arguments of the simple-template-id of the partial
+//   specialization.
+
+// TODO: add test cases for `enum`
+
+// class for tests
+class TestClass {
+public:
+  class PublicClass {};
+  template  class TemplatePublicClass {};
+
+  using AliasPublicClass = unsigned char;
+
+  void publicFunc();
+  void publicFuncOverloaded();
+  void publicFuncOverloaded(int);
+
+  static void publicStaticFunc();
+  static void publicStaticFuncOverloaded();
+  static void publicStaticFuncOverloaded(int);
+
+  static constexpr int publicStaticInt = 42;
+
+protected:
+  // expected-note@+1 8{{declared protected here}}
+  class ProtectedClass {};
+  template  class TemplateProtectedClass {};
+
+  // expected-note@+1 2{{declared protected here}}
+  using AliasProtectedClass = const char;
+
+  // expected-note@+1 3{{declared protected here}}
+  void protectedFunc();
+  void protectedFuncOverloaded();
+  void protectedFuncOverloaded(int);
+
+  // expected-note@+1 2{{declared protected here}}
+  static void protectedStaticFunc();
+  // expected-note@+1 2{{declared protected here}}
+  static void protectedStaticFuncOverloaded();
+  static void protectedStaticFuncOverloaded(int);
+
+  // expected-note@+1 2{{declared protected here}}
+  static constexpr int protectedStaticInt = 43;
+
+private:
+  // expected-note@+1 10{{declared private here}}
+  class PrivateClass {};
+  // expected-note@+1 {{declared private here}}
+  template  class TemplatePrivateClass {};
+
+  using AliasPrivateClass = char *;
+
+  void privateFunc();
+  void privateFuncOverloaded();
+  void privateFuncOverloaded(int);
+
+  static void privateStaticFunc();
+  static void privateStaticFuncOverloaded();
+  static void privateStaticFuncOverloaded(int);
+
+  static constexpr int privateStaticInt = 44;
+};
+
+void globalFunction() {}
+
+//--//
+
+// template declarations for explicit instantiations
+template  class IT1 {};
+template  class IT2 {};
+template  class IT3 {};
+template  class IT4 {};
+template  class IT5 {};
+template  class IT6 {
+  template  class NIT1 {};
+};
+template  class IT7 {};
+template  class IT8 {};
+template  class IT9 {};
+
+// explicit instantiations
+
+// public
+template class IT1;
+template struct IT1>;
+template class IT1;
+template struct IT2;
+template class IT3;
+template struct IT4<&TestClass::publicFunc>;
+template class IT4<&TestClass::publicFuncOverloaded>;
+template class IT5<&TestClass::publicStaticFunc>;
+template class IT5<&TestClass::publicStaticFuncOverloaded>;
+template class IT5<&globalFunction>;
+template class IT6::template NIT1;
+template class IT7;
+template struct IT7>;
+template class IT8<&TestClass::publicFunc, TestClass::publicStaticInt>;
+template class IT8<&TestClass::publicFuncOverloaded, TestClass::publicStaticInt>;
+template class IT9;
+template class IT9;
+template class IT9;
+
+// protected
+template class IT1;
+template struct IT1>;
+template class IT1;
+template struct IT2;
+template class IT3;
+template struct IT4<&TestClass::protectedFunc>;
+template class IT4<&TestClass::protectedFuncOverloaded>;
+template class IT5<&TestClass::protectedStaticFunc>;
+template class IT5<&TestClass::protectedStaticFuncOverloaded>;
+template class IT6::template NIT1;
+template class IT7;
+template struct IT7>;
+template class IT8<&TestClass::protectedFunc, TestClass::protectedStaticInt>;
+template class IT8<&TestClass::protectedFuncOverloaded, TestClass::protectedStaticInt>;
+template class IT9;
+template class IT9;
+template class IT9;
+
+// private
+template class IT1;
+template struct IT1>;
+template class IT1;
+template struct IT2;
+template class IT3;
+template struct IT4<&TestClass::privateFunc>;
+template class IT4<&TestClass::privateFuncOverloaded>;
+template class IT5<&TestClass::privateStaticFunc>;
+template class IT5<&TestClass::privateSt

[PATCH] D94424: [clangd] Make AST-based signals available to runWithPreamble.

2021-01-11 Thread Utkarsh Saxena via Phabricator via cfe-commits
usaxena95 updated this revision to Diff 315839.
usaxena95 added a comment.

Documentation change.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94424

Files:
  clang-tools-extra/clangd/TUScheduler.cpp
  clang-tools-extra/clangd/TUScheduler.h
  clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp

Index: clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp
===
--- clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp
+++ clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp
@@ -14,6 +14,7 @@
 #include "Preamble.h"
 #include "TUScheduler.h"
 #include "TestFS.h"
+#include "TestIndex.h"
 #include "support/Cancellation.h"
 #include "support/Context.h"
 #include "support/Path.h"
@@ -42,12 +43,14 @@
 namespace clangd {
 namespace {
 
+using ::testing::_;
 using ::testing::AnyOf;
 using ::testing::Each;
 using ::testing::ElementsAre;
 using ::testing::Eq;
 using ::testing::Field;
 using ::testing::IsEmpty;
+using ::testing::Pair;
 using ::testing::Pointee;
 using ::testing::SizeIs;
 using ::testing::UnorderedElementsAre;
@@ -696,6 +699,70 @@
   });
 }
 
+TEST_F(TUSchedulerTests, ASTSignals) {
+  TUScheduler S(CDB, optsForTest());
+  auto Foo = testPath("foo.cpp");
+  auto Header = testPath("foo.h");
+
+  FS.Files[Header] = R"cpp(
+  #define ADD(x, y, z) (x + y + z)
+  namespace tar {  // A related namespace.
+  int kConst = 5;
+  int foo();
+  void bar();
+  class X {
+public: int Y;
+  };
+  } // namespace bar
+  )cpp";
+  const char *Contents = R"cpp(
+  #include "foo.h"
+  namespace ns1 {
+  namespace ns2 {
+void func() {
+  tar::X a;
+  tar::X b;
+  a.Y = 1;
+  b.Y = ADD(tar::kConst, a.Y, tar::foo());
+}
+  } // namespace ns2
+  } // namespace ns1
+  )cpp";
+  // Update the file which results in an empty preamble.
+  S.update(Foo, getInputs(Foo, Contents), WantDiagnostics::Yes);
+  // Wait for the preamble is being built.
+  ASSERT_TRUE(S.blockUntilIdle(timeoutSeconds(10)));
+  Notification TaskRun;
+  S.runWithPreamble(
+  "ASTSignals", Foo, TUScheduler::Stale,
+  [&](Expected IP) {
+ASSERT_FALSE(!IP);
+std::vector> NS;
+for (const auto &P : IP->Signals->RelatedNamespaces)
+  NS.emplace_back(P.getKey(), P.getValue());
+EXPECT_THAT(NS, UnorderedElementsAre(Pair("ns1::", 1),
+ Pair("ns1::ns2::", 1),
+ Pair("tar::", 4)));
+
+std::vector> Sym;
+for (const auto &P : IP->Signals->Symbols)
+  Sym.emplace_back(P.getFirst(), P.getSecond());
+EXPECT_THAT(
+Sym,
+UnorderedElementsAre(
+Pair(ns("tar").ID, 4), Pair(ns("ns1").ID, 1),
+Pair(ns("ns1::ns2").ID, 1), Pair(func("ns1::ns2::func").ID, 1),
+Pair(cls("tar::X").ID, 2), Pair(var("tar::kConst").ID, 1),
+Pair(func("tar::foo").ID, 1),
+Pair(sym("Y", index::SymbolKind::Variable, "@N@tar@S@X@FI@\\0")
+ .ID,
+ 3),
+Pair(_ /*a*/, 3), Pair(_ /*b*/, 2)));
+TaskRun.notify();
+  });
+  TaskRun.wait();
+}
+
 TEST_F(TUSchedulerTests, RunWaitsForPreamble) {
   // Testing strategy: we update the file and schedule a few preamble reads at
   // the same time. All reads should get the same non-null preamble.
Index: clang-tools-extra/clangd/TUScheduler.h
===
--- clang-tools-extra/clangd/TUScheduler.h
+++ clang-tools-extra/clangd/TUScheduler.h
@@ -13,10 +13,12 @@
 #include "Diagnostics.h"
 #include "GlobalCompilationDatabase.h"
 #include "index/CanonicalIncludes.h"
+#include "index/SymbolID.h"
 #include "support/Function.h"
 #include "support/MemoryTree.h"
 #include "support/Path.h"
 #include "support/Threading.h"
+#include "llvm/ADT/DenseMap.h"
 #include "llvm/ADT/Optional.h"
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/StringMap.h"
@@ -33,6 +35,14 @@
 /// synchronously).
 unsigned getDefaultAsyncThreadsCount();
 
+/// Signals derived from a valid AST of a file.
+struct ASTSignals {
+  /// Number of occurrences of each Symbol present in the file.
+  llvm::DenseMap Symbols;
+  /// Number of Symbols belonging to each namespace present in the file.
+  llvm::StringMap RelatedNamespaces;
+};
+
 struct InputsAndAST {
   const ParseInputs &Inputs;
   ParsedAST &AST;
@@ -43,6 +53,8 @@
   const tooling::CompileCommand &Command;
   // This can be nullptr if no preamble is available.
   const PreambleData *Preamble;
+  // This can be nullptr if no ASTSignals are available.
+  const ASTSignals *Signals;
 };
 
 /// Determines whether diagnostics should be generated for a file snapshot.
Index: clang-tools-extra/clangd/TUScheduler.cpp
===
--

[PATCH] D94338: [Clang][Docs] Fix ambiguity in clang-offload-bundler docs

2021-01-11 Thread Scott Linder via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGc15b0e2229ea: [Clang][Docs] Fix ambiguity in 
clang-offload-bundler docs (authored by scott.linder).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94338

Files:
  clang/docs/ClangOffloadBundler.rst


Index: clang/docs/ClangOffloadBundler.rst
===
--- clang/docs/ClangOffloadBundler.rst
+++ clang/docs/ClangOffloadBundler.rst
@@ -44,7 +44,7 @@
 Field   TypeSize in BytesDescription
 === ===  
===
 Magic Stringstring  24   
``__CLANG_OFFLOAD_BUNDLE__``
-Number Of Code Objects  integer 8Number od 
bundled code objects.
+Number Of Bundle Entriesinteger 8Number of 
bundle entries.
 1st Bundle Entry Code Object Offset integer 8Byte offset 
from beginning of
  bundled code 
object to 1st code
  object.
@@ -208,4 +208,4 @@
   features `_
   supported.
 
-Most other targets do not support target IDs.
\ No newline at end of file
+Most other targets do not support target IDs.


Index: clang/docs/ClangOffloadBundler.rst
===
--- clang/docs/ClangOffloadBundler.rst
+++ clang/docs/ClangOffloadBundler.rst
@@ -44,7 +44,7 @@
 Field   TypeSize in BytesDescription
 === ===  ===
 Magic Stringstring  24   ``__CLANG_OFFLOAD_BUNDLE__``
-Number Of Code Objects  integer 8Number od bundled code objects.
+Number Of Bundle Entriesinteger 8Number of bundle entries.
 1st Bundle Entry Code Object Offset integer 8Byte offset from beginning of
  bundled code object to 1st code
  object.
@@ -208,4 +208,4 @@
   features `_
   supported.
 
-Most other targets do not support target IDs.
\ No newline at end of file
+Most other targets do not support target IDs.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] c15b0e2 - [Clang][Docs] Fix ambiguity in clang-offload-bundler docs

2021-01-11 Thread Scott Linder via cfe-commits

Author: Scott Linder
Date: 2021-01-11T17:23:24Z
New Revision: c15b0e2229ea04d1c36fafaa1f717f433a995e9a

URL: 
https://github.com/llvm/llvm-project/commit/c15b0e2229ea04d1c36fafaa1f717f433a995e9a
DIFF: 
https://github.com/llvm/llvm-project/commit/c15b0e2229ea04d1c36fafaa1f717f433a995e9a.diff

LOG: [Clang][Docs] Fix ambiguity in clang-offload-bundler docs

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

Added: 


Modified: 
clang/docs/ClangOffloadBundler.rst

Removed: 




diff  --git a/clang/docs/ClangOffloadBundler.rst 
b/clang/docs/ClangOffloadBundler.rst
index 050925be993b..68c5116b235f 100644
--- a/clang/docs/ClangOffloadBundler.rst
+++ b/clang/docs/ClangOffloadBundler.rst
@@ -44,7 +44,7 @@ The layout of a bundled code object is defined by the 
following table:
 Field   TypeSize in BytesDescription
 === ===  
===
 Magic Stringstring  24   
``__CLANG_OFFLOAD_BUNDLE__``
-Number Of Code Objects  integer 8Number od 
bundled code objects.
+Number Of Bundle Entriesinteger 8Number of 
bundle entries.
 1st Bundle Entry Code Object Offset integer 8Byte offset 
from beginning of
  bundled code 
object to 1st code
  object.
@@ -208,4 +208,4 @@ Target specific information is available for the following:
   features `_
   supported.
 
-Most other targets do not support target IDs.
\ No newline at end of file
+Most other targets do not support target IDs.



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


[PATCH] D94424: [clangd] Make AST-based signals available to runWithPreamble.

2021-01-11 Thread Utkarsh Saxena via Phabricator via cfe-commits
usaxena95 created this revision.
Herald added subscribers: kadircet, arphaman, javed.absar.
usaxena95 requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay, ilya-biryukov.
Herald added a project: clang.

Many useful signals can be derived from a valid AST which is regularly updated 
by
the ASTWorker. `runWithPreamble` does not have access to the ParsedAST
but it can be provided access to some signals derived from a (possibly
stale) AST.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D94424

Files:
  clang-tools-extra/clangd/TUScheduler.cpp
  clang-tools-extra/clangd/TUScheduler.h
  clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp

Index: clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp
===
--- clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp
+++ clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp
@@ -14,6 +14,7 @@
 #include "Preamble.h"
 #include "TUScheduler.h"
 #include "TestFS.h"
+#include "TestIndex.h"
 #include "support/Cancellation.h"
 #include "support/Context.h"
 #include "support/Path.h"
@@ -42,12 +43,14 @@
 namespace clangd {
 namespace {
 
+using ::testing::_;
 using ::testing::AnyOf;
 using ::testing::Each;
 using ::testing::ElementsAre;
 using ::testing::Eq;
 using ::testing::Field;
 using ::testing::IsEmpty;
+using ::testing::Pair;
 using ::testing::Pointee;
 using ::testing::SizeIs;
 using ::testing::UnorderedElementsAre;
@@ -696,6 +699,70 @@
   });
 }
 
+TEST_F(TUSchedulerTests, ASTSignals) {
+  TUScheduler S(CDB, optsForTest());
+  auto Foo = testPath("foo.cpp");
+  auto Header = testPath("foo.h");
+
+  FS.Files[Header] = R"cpp(
+  #define ADD(x, y, z) (x + y + z)
+  namespace tar {  // A related namespace.
+  int kConst = 5;
+  int foo();
+  void bar();
+  class X {
+public: int Y;
+  };
+  } // namespace bar
+  )cpp";
+  const char *Contents = R"cpp(
+  #include "foo.h"
+  namespace ns1 {
+  namespace ns2 {
+void func() {
+  tar::X a;
+  tar::X b;
+  a.Y = 1;
+  b.Y = ADD(tar::kConst, a.Y, tar::foo());
+}
+  } // namespace ns2
+  } // namespace ns1
+  )cpp";
+  // Update the file which results in an empty preamble.
+  S.update(Foo, getInputs(Foo, Contents), WantDiagnostics::Yes);
+  // Wait for the preamble is being built.
+  ASSERT_TRUE(S.blockUntilIdle(timeoutSeconds(10)));
+  Notification TaskRun;
+  S.runWithPreamble(
+  "ASTSignals", Foo, TUScheduler::Stale,
+  [&](Expected IP) {
+ASSERT_FALSE(!IP);
+std::vector> NS;
+for (const auto &P : IP->Signals->RelatedNamespaces)
+  NS.emplace_back(P.getKey(), P.getValue());
+EXPECT_THAT(NS, UnorderedElementsAre(Pair("ns1::", 1),
+ Pair("ns1::ns2::", 1),
+ Pair("tar::", 4)));
+
+std::vector> Sym;
+for (const auto &P : IP->Signals->Symbols)
+  Sym.emplace_back(P.getFirst(), P.getSecond());
+EXPECT_THAT(
+Sym,
+UnorderedElementsAre(
+Pair(ns("tar").ID, 4), Pair(ns("ns1").ID, 1),
+Pair(ns("ns1::ns2").ID, 1), Pair(func("ns1::ns2::func").ID, 1),
+Pair(cls("tar::X").ID, 2), Pair(var("tar::kConst").ID, 1),
+Pair(func("tar::foo").ID, 1),
+Pair(sym("Y", index::SymbolKind::Variable, "@N@tar@S@X@FI@\\0")
+ .ID,
+ 3),
+Pair(_ /*a*/, 3), Pair(_ /*b*/, 2)));
+TaskRun.notify();
+  });
+  TaskRun.wait();
+}
+
 TEST_F(TUSchedulerTests, RunWaitsForPreamble) {
   // Testing strategy: we update the file and schedule a few preamble reads at
   // the same time. All reads should get the same non-null preamble.
Index: clang-tools-extra/clangd/TUScheduler.h
===
--- clang-tools-extra/clangd/TUScheduler.h
+++ clang-tools-extra/clangd/TUScheduler.h
@@ -13,10 +13,12 @@
 #include "Diagnostics.h"
 #include "GlobalCompilationDatabase.h"
 #include "index/CanonicalIncludes.h"
+#include "index/SymbolID.h"
 #include "support/Function.h"
 #include "support/MemoryTree.h"
 #include "support/Path.h"
 #include "support/Threading.h"
+#include "llvm/ADT/DenseMap.h"
 #include "llvm/ADT/Optional.h"
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/StringMap.h"
@@ -33,6 +35,14 @@
 /// synchronously).
 unsigned getDefaultAsyncThreadsCount();
 
+/// Signals derived from a valid AST of a file.
+struct ASTSignals {
+  /// Number of occurrences of each Symbol present in the file.
+  llvm::DenseMap Symbols;
+  /// Number of Symbols belonging to each namespace present in the file.
+  llvm::StringMap RelatedNamespaces;
+};
+
 struct InputsAndAST {
   const ParseInputs &Inputs;
   ParsedAST &AST;
@@ -43,6 +53,8 @@
   const tooling::CompileCommand &Command;
   // This can be nullptr if no preamble is available.
   const Preamble

[PATCH] D94374: [CMake] Remove dead code setting policies to NEW

2021-01-11 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.

Except for the google-benchmark nit, LGTM. Thanks a lot for the cleanup!




Comment at: libcxx/utils/google-benchmark/CMakeLists.txt:3
-
-project (benchmark)
-

I don't think we want to change this. It's a third-party project (which is 
inconveniently checked-in as-is into our tree..).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94374

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


[PATCH] D94359: [clangd] Remove ScratchFS from tests

2021-01-11 Thread Nathan James via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG31732e6f52c8: [clangd] Remove ScratchFS from tests (authored 
by njames93).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94359

Files:
  clang-tools-extra/clangd/unittests/GlobalCompilationDatabaseTests.cpp

Index: clang-tools-extra/clangd/unittests/GlobalCompilationDatabaseTests.cpp
===
--- clang-tools-extra/clangd/unittests/GlobalCompilationDatabaseTests.cpp
+++ clang-tools-extra/clangd/unittests/GlobalCompilationDatabaseTests.cpp
@@ -169,48 +169,6 @@
"-DFallback", "-DAdjust_baz.cc"));
 }
 
-// Allows placement of files for tests and cleans them up after.
-// FIXME: GlobalCompilationDatabase is mostly VFS-clean now, switch to MockFS?
-class ScratchFS {
-  llvm::SmallString<128> Root;
-
-public:
-  ScratchFS() {
-EXPECT_FALSE(llvm::sys::fs::createUniqueDirectory("clangd-cdb-test", Root))
-<< "Failed to create unique directory";
-  }
-
-  ~ScratchFS() {
-EXPECT_FALSE(llvm::sys::fs::remove_directories(Root))
-<< "Failed to cleanup " << Root;
-  }
-
-  llvm::StringRef root() const { return Root; }
-
-  void write(PathRef RelativePath, llvm::StringRef Contents) {
-std::string AbsPath = path(RelativePath);
-EXPECT_FALSE(llvm::sys::fs::create_directories(
-llvm::sys::path::parent_path(AbsPath)))
-<< "Failed to create directories for: " << AbsPath;
-
-std::error_code EC;
-llvm::raw_fd_ostream OS(AbsPath, EC);
-EXPECT_FALSE(EC) << "Failed to open " << AbsPath << " for writing";
-OS << llvm::formatv(Contents.data(),
-llvm::sys::path::convert_to_slash(Root));
-OS.close();
-
-EXPECT_FALSE(OS.has_error());
-  }
-
-  std::string path(PathRef RelativePath) const {
-llvm::SmallString<128> AbsPath(Root);
-llvm::sys::path::append(AbsPath, RelativePath);
-llvm::sys::path::native(AbsPath);
-return AbsPath.str().str();
-  }
-};
-
 TEST(GlobalCompilationDatabaseTest, DiscoveryWithNestedCDBs) {
   const char *const CDBOuter =
   R"cdb(
@@ -242,34 +200,35 @@
 }
   ]
   )cdb";
-  ScratchFS FS;
-  RealThreadsafeFS TFS;
-  FS.write("compile_commands.json", CDBOuter);
-  FS.write("build/compile_commands.json", CDBInner);
+  MockFS FS;
+  FS.Files[testPath("compile_commands.json")] =
+  llvm::formatv(CDBOuter, llvm::sys::path::convert_to_slash(testRoot()));
+  FS.Files[testPath("build/compile_commands.json")] =
+  llvm::formatv(CDBInner, llvm::sys::path::convert_to_slash(testRoot()));
 
   // Note that gen2.cc goes missing with our following model, not sure this
   // happens in practice though.
   {
-DirectoryBasedGlobalCompilationDatabase DB(TFS);
+DirectoryBasedGlobalCompilationDatabase DB(FS);
 std::vector DiscoveredFiles;
 auto Sub =
 DB.watch([&DiscoveredFiles](const std::vector Changes) {
   DiscoveredFiles = Changes;
 });
 
-DB.getCompileCommand(FS.path("build/../a.cc"));
+DB.getCompileCommand(testPath("build/../a.cc"));
 EXPECT_THAT(DiscoveredFiles, UnorderedElementsAre(AllOf(
  EndsWith("a.cc"), Not(HasSubstr("..");
 DiscoveredFiles.clear();
 
-DB.getCompileCommand(FS.path("build/gen.cc"));
+DB.getCompileCommand(testPath("build/gen.cc"));
 EXPECT_THAT(DiscoveredFiles, UnorderedElementsAre(EndsWith("gen.cc")));
   }
 
   // With a custom compile commands dir.
   {
-DirectoryBasedGlobalCompilationDatabase::Options Opts(TFS);
-Opts.CompileCommandsDir = FS.root().str();
+DirectoryBasedGlobalCompilationDatabase::Options Opts(FS);
+Opts.CompileCommandsDir = testRoot();
 DirectoryBasedGlobalCompilationDatabase DB(Opts);
 std::vector DiscoveredFiles;
 auto Sub =
@@ -277,24 +236,23 @@
   DiscoveredFiles = Changes;
 });
 
-DB.getCompileCommand(FS.path("a.cc"));
+DB.getCompileCommand(testPath("a.cc"));
 EXPECT_THAT(DiscoveredFiles,
 UnorderedElementsAre(EndsWith("a.cc"), EndsWith("gen.cc"),
  EndsWith("gen2.cc")));
 DiscoveredFiles.clear();
 
-DB.getCompileCommand(FS.path("build/gen.cc"));
+DB.getCompileCommand(testPath("build/gen.cc"));
 EXPECT_THAT(DiscoveredFiles, IsEmpty());
   }
 }
 
 TEST(GlobalCompilationDatabaseTest, BuildDir) {
-  ScratchFS FS;
-  RealThreadsafeFS TFS;
+  MockFS FS;
   auto Command = [&](llvm::StringRef Relative) {
-DirectoryBasedGlobalCompilationDatabase::Options Opts(TFS);
+DirectoryBasedGlobalCompilationDatabase::Options Opts(FS);
 return DirectoryBasedGlobalCompilationDatabase(Opts)
-.getCompileCommand(FS.path(Relative))
+.getCompileCommand(testPath(Relative))
 .getValueOr(tooling::CompileCommand())
 .CommandLine;

[clang-tools-extra] 31732e6 - [clangd] Remove ScratchFS from tests

2021-01-11 Thread Nathan James via cfe-commits

Author: Nathan James
Date: 2021-01-11T16:14:26Z
New Revision: 31732e6f52c8e5e722d3e4cca053db793dae3b8c

URL: 
https://github.com/llvm/llvm-project/commit/31732e6f52c8e5e722d3e4cca053db793dae3b8c
DIFF: 
https://github.com/llvm/llvm-project/commit/31732e6f52c8e5e722d3e4cca053db793dae3b8c.diff

LOG: [clangd] Remove ScratchFS from tests

This can lead to issues if files in the tmp directory we don't care about / 
control are found.
This was partially addressed in D94321, but this is a more permanent fix.
Fixes https://github.com/clangd/clangd/issues/354

Reviewed By: adamcz, sammccall

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

Added: 


Modified: 
clang-tools-extra/clangd/unittests/GlobalCompilationDatabaseTests.cpp

Removed: 




diff  --git 
a/clang-tools-extra/clangd/unittests/GlobalCompilationDatabaseTests.cpp 
b/clang-tools-extra/clangd/unittests/GlobalCompilationDatabaseTests.cpp
index 12c986572d8b..63b1b731656a 100644
--- a/clang-tools-extra/clangd/unittests/GlobalCompilationDatabaseTests.cpp
+++ b/clang-tools-extra/clangd/unittests/GlobalCompilationDatabaseTests.cpp
@@ -169,48 +169,6 @@ TEST_F(OverlayCDBTest, Adjustments) {
"-DFallback", "-DAdjust_baz.cc"));
 }
 
-// Allows placement of files for tests and cleans them up after.
-// FIXME: GlobalCompilationDatabase is mostly VFS-clean now, switch to MockFS?
-class ScratchFS {
-  llvm::SmallString<128> Root;
-
-public:
-  ScratchFS() {
-EXPECT_FALSE(llvm::sys::fs::createUniqueDirectory("clangd-cdb-test", Root))
-<< "Failed to create unique directory";
-  }
-
-  ~ScratchFS() {
-EXPECT_FALSE(llvm::sys::fs::remove_directories(Root))
-<< "Failed to cleanup " << Root;
-  }
-
-  llvm::StringRef root() const { return Root; }
-
-  void write(PathRef RelativePath, llvm::StringRef Contents) {
-std::string AbsPath = path(RelativePath);
-EXPECT_FALSE(llvm::sys::fs::create_directories(
-llvm::sys::path::parent_path(AbsPath)))
-<< "Failed to create directories for: " << AbsPath;
-
-std::error_code EC;
-llvm::raw_fd_ostream OS(AbsPath, EC);
-EXPECT_FALSE(EC) << "Failed to open " << AbsPath << " for writing";
-OS << llvm::formatv(Contents.data(),
-llvm::sys::path::convert_to_slash(Root));
-OS.close();
-
-EXPECT_FALSE(OS.has_error());
-  }
-
-  std::string path(PathRef RelativePath) const {
-llvm::SmallString<128> AbsPath(Root);
-llvm::sys::path::append(AbsPath, RelativePath);
-llvm::sys::path::native(AbsPath);
-return AbsPath.str().str();
-  }
-};
-
 TEST(GlobalCompilationDatabaseTest, DiscoveryWithNestedCDBs) {
   const char *const CDBOuter =
   R"cdb(
@@ -242,34 +200,35 @@ TEST(GlobalCompilationDatabaseTest, 
DiscoveryWithNestedCDBs) {
 }
   ]
   )cdb";
-  ScratchFS FS;
-  RealThreadsafeFS TFS;
-  FS.write("compile_commands.json", CDBOuter);
-  FS.write("build/compile_commands.json", CDBInner);
+  MockFS FS;
+  FS.Files[testPath("compile_commands.json")] =
+  llvm::formatv(CDBOuter, llvm::sys::path::convert_to_slash(testRoot()));
+  FS.Files[testPath("build/compile_commands.json")] =
+  llvm::formatv(CDBInner, llvm::sys::path::convert_to_slash(testRoot()));
 
   // Note that gen2.cc goes missing with our following model, not sure this
   // happens in practice though.
   {
-DirectoryBasedGlobalCompilationDatabase DB(TFS);
+DirectoryBasedGlobalCompilationDatabase DB(FS);
 std::vector DiscoveredFiles;
 auto Sub =
 DB.watch([&DiscoveredFiles](const std::vector Changes) {
   DiscoveredFiles = Changes;
 });
 
-DB.getCompileCommand(FS.path("build/../a.cc"));
+DB.getCompileCommand(testPath("build/../a.cc"));
 EXPECT_THAT(DiscoveredFiles, UnorderedElementsAre(AllOf(
  EndsWith("a.cc"), Not(HasSubstr("..");
 DiscoveredFiles.clear();
 
-DB.getCompileCommand(FS.path("build/gen.cc"));
+DB.getCompileCommand(testPath("build/gen.cc"));
 EXPECT_THAT(DiscoveredFiles, UnorderedElementsAre(EndsWith("gen.cc")));
   }
 
   // With a custom compile commands dir.
   {
-DirectoryBasedGlobalCompilationDatabase::Options Opts(TFS);
-Opts.CompileCommandsDir = FS.root().str();
+DirectoryBasedGlobalCompilationDatabase::Options Opts(FS);
+Opts.CompileCommandsDir = testRoot();
 DirectoryBasedGlobalCompilationDatabase DB(Opts);
 std::vector DiscoveredFiles;
 auto Sub =
@@ -277,24 +236,23 @@ TEST(GlobalCompilationDatabaseTest, 
DiscoveryWithNestedCDBs) {
   DiscoveredFiles = Changes;
 });
 
-DB.getCompileCommand(FS.path("a.cc"));
+DB.getCompileCommand(testPath("a.cc"));
 EXPECT_THAT(DiscoveredFiles,
 UnorderedElementsAre(EndsWith("a.cc"), EndsWith("gen.cc"),
  EndsWith("gen2.cc")));
 DiscoveredFiles.

[PATCH] D93822: [clang][Sema] Add diagnostics for implicit widening of multiplication result

2021-01-11 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added subscribers: NoQ, Szelethus.
aaron.ballman added a comment.

In D93822#2474475 , @dblaikie wrote:

> In D93822#2474355 , @lebedev.ri 
> wrote:
>
>> I'm open to input here, but it would be good to have this at least in 
>> `-Wextra` (`-Weverything` always being a last resort option).
>
> Yeah, not sure how @rsmith, @rtrieu, or @aaron.ballman feel about what the 
> bar for warnings is these days - used to be a bit more hardcore about the "if 
> it can't be on by default it shouldn't be in clang" than we are these days, I 
> think. I'd guess -Wextra might be suitable.

I'd like to see data before making a determination, but my gut instinct is that 
this diagnostic will be far too chatty to be in Clang (even in `-Wextra`) but 
that this would be a great flow-sensitive check for the clang static analyzer 
(I've added some analyzer folks to the thread for their input). Static 
analyzers frequently implement this functionality because they can more easily 
notice things that limit the range of values possible for a given object and 
use that extra information when deciding whether overflow is likely or not. 
e.g., if the analyzer encounters `if (foo > 10) return;` in a method then it 
can understand that subsequent uses of `foo` after that statement are bounded 
such that `foo <= 10`. I think we'll ultimately need this flow sensitivity to 
reduce the false positive rate to something more useful for math-heavy code 
bases.

Assuming that the data shows a high false positive rate, if you don't have the 
appetite to work on the robust check in the static analyzer, another option 
would be to implement this functionality in clang-tidy (which is allowed to be 
more chatty than the Clang frontend or the static analyzer in terms of false 
positives). However, I still think we eventually will want the static analyzer 
check and so my preference is for that approach (so that we don't wind up 
needing to carry around two implementations of effectively the same check).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93822

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


[PATCH] D93873: [clangd] Cache preambles of closed files

2021-01-11 Thread Sam McCall via Phabricator via cfe-commits
sammccall added a reviewer: kadircet.
sammccall added a comment.

Thanks! This is a really good idea, but not without its risks :-) Sorry for not 
getting to this for a while!

My only *really* high-level design question is: I wonder what the tradeoffs are 
in keeping just the preamble vs the whole ASTWorker. I'd *expect* this approach 
gets almost all the benefit without complicating the basic assumptions around 
ASTWorker, so it's probably the right way to go. Haven't thought about it much 
though...

---

I've got a bit of cognitive load because there's a few preamble-related ideas 
we've had, and I'm trying to work out how they interact. Let's start by writing 
them down...

1. a *persistent* cache so closing+reopening clangd loses less state. (This is 
complicated because only the PCH is easily serializable, the rest of the 
PreambleData struct isn't)
2. building caches of preambles while background-indexing (this would be great 
for modules but is probably way too big for whole preambles)
3. reusing the "wrong" preamble initially when you open a new file, to give 
some basic functionality (using existing preamble patching logic, just in a 
more aggressive scenario)
4. having the disk-based storage unlink the file preemptively, to eliminate any 
chance of leaking the *.pch

1&2 are both big projects, so I'm not really worried about the overlap or at 
least not going to try to predict how it'd be resolved.

3 is actually made *easier* by this patch I think: having a central repository 
of preambles makes it more natural to grab some "other" preamble.

4 I think doesn't really interact at all: the PreambleData object would own a 
file descriptor instead of a file, but it's all much the same.

So I think in summary there's not really any conflict to resolve with these 
ideas. cc @kadircet though who's done more thinking about #1 and #3 than I have.

---

I think we need to be fairly careful about policies around this cache. 
Preambles are large (we frequently see several hundred MB). Some workflows 
involve opening many files at a time. Some workflows end up running multiple 
copies of clangd on the same files. Some configurations keep them in memory 
rather than on disk. So a too-large cache could waste quite a lot of resources.

So, some pointy questions:

- landing so close to the 12 release, should we conservatively default this to 
0, and require opt-in?
- is MB or #preambles a better limit to the cache size?
- should we take size into account when deciding what to evict? (my guess is 
no, cost scales with size, and value scales with size * probability of reuse, 
so we should purely optimize for probability of reuse)
- can we do better than LRU? The cache is accessed so infrequently and misses 
are so horrendously expensive that we could certainly affort to e.g. track 
usage history of every file ever opened, if it would help performance and not 
add too much complexity.
- not a question, but I can say for sure that 1000 with no size limit isn't a 
safe default for disk :-(




Comment at: clang-tools-extra/clangd/TUScheduler.cpp:193
+  /// Get the preamble associated with a \p Key, removing
+  /// it from the cache
+  std::shared_ptr take(llvm::StringRef Key) {

we might instead consider keeping "active" preambles in the cache, and simply 
considering their cost to be 0/ineligible for eviction if the 
shared_ptr::usage_count > 1. 
This allows this cache to be a "registry" so we can try using a preamble from a 
different TU as mentioned above.

(but this could also be done later, or could be done with a separate table of 
weak_ptrs. No change needed for this patch, just thinking out loud)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93873

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


[PATCH] D94411: [clangd] Fix -check mode doesn't respect any tidy configs.

2021-01-11 Thread Haojian Wu via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGa2dbf3443af7: [clangd] Fix -check mode doesn't respect 
any tidy configs. (authored by hokein).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94411

Files:
  clang-tools-extra/clangd/tool/Check.cpp


Index: clang-tools-extra/clangd/tool/Check.cpp
===
--- clang-tools-extra/clangd/tool/Check.cpp
+++ clang-tools-extra/clangd/tool/Check.cpp
@@ -123,6 +123,7 @@
 std::vector CC1Args;
 Inputs.CompileCommand = Cmd;
 Inputs.TFS = &TFS;
+Inputs.ClangTidyProvider = Opts.ClangTidyProvider;
 if (Contents.hasValue()) {
   Inputs.Contents = *Contents;
   log("Imaginary source file contents:\n{0}", Inputs.Contents);


Index: clang-tools-extra/clangd/tool/Check.cpp
===
--- clang-tools-extra/clangd/tool/Check.cpp
+++ clang-tools-extra/clangd/tool/Check.cpp
@@ -123,6 +123,7 @@
 std::vector CC1Args;
 Inputs.CompileCommand = Cmd;
 Inputs.TFS = &TFS;
+Inputs.ClangTidyProvider = Opts.ClangTidyProvider;
 if (Contents.hasValue()) {
   Inputs.Contents = *Contents;
   log("Imaginary source file contents:\n{0}", Inputs.Contents);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang-tools-extra] a2dbf34 - [clangd] Fix -check mode doesn't respect any tidy configs.

2021-01-11 Thread Haojian Wu via cfe-commits

Author: Haojian Wu
Date: 2021-01-11T16:43:33+01:00
New Revision: a2dbf3443af79426c80e8a808821236c5a2b305e

URL: 
https://github.com/llvm/llvm-project/commit/a2dbf3443af79426c80e8a808821236c5a2b305e
DIFF: 
https://github.com/llvm/llvm-project/commit/a2dbf3443af79426c80e8a808821236c5a2b305e.diff

LOG: [clangd] Fix -check mode doesn't respect any tidy configs.

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

Added: 


Modified: 
clang-tools-extra/clangd/tool/Check.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/tool/Check.cpp 
b/clang-tools-extra/clangd/tool/Check.cpp
index 18d2837b89c2..e42596bb4bf4 100644
--- a/clang-tools-extra/clangd/tool/Check.cpp
+++ b/clang-tools-extra/clangd/tool/Check.cpp
@@ -123,6 +123,7 @@ class Checker {
 std::vector CC1Args;
 Inputs.CompileCommand = Cmd;
 Inputs.TFS = &TFS;
+Inputs.ClangTidyProvider = Opts.ClangTidyProvider;
 if (Contents.hasValue()) {
   Inputs.Contents = *Contents;
   log("Imaginary source file contents:\n{0}", Inputs.Contents);



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


[PATCH] D94403: [RISCV] Implement new architecture extension macros

2021-01-11 Thread Simon Cook via Phabricator via cfe-commits
simoncook updated this revision to Diff 315805.
simoncook added a comment.

Correct constant used in macros, 2.0 should be 200 not 2000


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94403

Files:
  clang/lib/Basic/Targets/RISCV.cpp
  clang/test/Preprocessor/riscv-target-features.c

Index: clang/test/Preprocessor/riscv-target-features.c
===
--- clang/test/Preprocessor/riscv-target-features.c
+++ clang/test/Preprocessor/riscv-target-features.c
@@ -18,6 +18,7 @@
 // RUN: %clang -target riscv64-unknown-linux-gnu -march=rv64im -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-M-EXT %s
 // CHECK-M-EXT: __riscv_div 1
+// CHECK-M-EXT: __riscv_m 200
 // CHECK-M-EXT: __riscv_mul 1
 // CHECK-M-EXT: __riscv_muldiv 1
 
@@ -25,12 +26,14 @@
 // RUN: -o - | FileCheck --check-prefix=CHECK-A-EXT %s
 // RUN: %clang -target riscv64-unknown-linux-gnu -march=rv64ia -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-A-EXT %s
+// CHECK-A-EXT: __riscv_a 200
 // CHECK-A-EXT: __riscv_atomic 1
 
 // RUN: %clang -target riscv32-unknown-linux-gnu -march=rv32if -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-F-EXT %s
 // RUN: %clang -target riscv64-unknown-linux-gnu -march=rv64if -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-F-EXT %s
+// CHECK-F-EXT: __riscv_f 200
 // CHECK-F-EXT: __riscv_fdiv 1
 // CHECK-F-EXT: __riscv_flen 32
 // CHECK-F-EXT: __riscv_fsqrt 1
@@ -39,6 +42,7 @@
 // RUN: -o - | FileCheck --check-prefix=CHECK-D-EXT %s
 // RUN: %clang -target riscv64-unknown-linux-gnu -march=rv64ifd -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-D-EXT %s
+// CHECK-D-EXT: __riscv_d 200
 // CHECK-D-EXT: __riscv_fdiv 1
 // CHECK-D-EXT: __riscv_flen 64
 // CHECK-D-EXT: __riscv_fsqrt 1
@@ -47,12 +51,14 @@
 // RUN: -o - | FileCheck --check-prefix=CHECK-C-EXT %s
 // RUN: %clang -target riscv64-unknown-linux-gnu -march=rv64ic -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-C-EXT %s
+// CHECK-C-EXT: __riscv_c 200
 // CHECK-C-EXT: __riscv_compressed 1
 
 // RUN: %clang -target riscv32-unknown-linux-gnu -menable-experimental-extensions -march=rv32ib0p92 -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-B-EXT %s
 // RUN: %clang -target riscv64-unknown-linux-gnu -menable-experimental-extensions -march=rv64ib0p92 -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-B-EXT %s
+// CHECK-B-EXT: __riscv_b 92000
 // CHECK-B-EXT: __riscv_bitmanip 1
 
 // RUN: %clang -target riscv32-unknown-linux-gnu -march=rv32ifd -mabi=ilp32 -x c -E -dM %s \
@@ -85,10 +91,11 @@
 // RUN: %clang -target riscv64-unknown-linux-gnu -menable-experimental-extensions \
 // RUN:   -march=rv64iv0p9 -x c -E -dM %s \
 // RUN:   -o - | FileCheck --check-prefix=CHECK-V-EXT %s
+// CHECK-V-EXT: __riscv_v 9000
 // CHECK-V-EXT: __riscv_vector 1
 //
 // RUN: %clang -target riscv32-unknown-linux-gnu -menable-experimental-extensions -march=rv32izfh0p1 -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-ZFH-EXT %s
 // RUN: %clang -target riscv64-unknown-linux-gnu -menable-experimental-extensions -march=rv64izfh0p1 -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-ZFH-EXT %s
-// CHECK-ZFH-EXT: __riscv_zfh 1
+// CHECK-ZFH-EXT: __riscv_zfh 1000
Index: clang/lib/Basic/Targets/RISCV.cpp
===
--- clang/lib/Basic/Targets/RISCV.cpp
+++ clang/lib/Basic/Targets/RISCV.cpp
@@ -109,13 +109,18 @@
   if (ABIName == "ilp32e")
 Builder.defineMacro("__riscv_abi_rve");
 
+  Builder.defineMacro("__riscv_arch_test");
+  Builder.defineMacro("__riscv_i", "200");
+
   if (HasM) {
+Builder.defineMacro("__riscv_m", "200");
 Builder.defineMacro("__riscv_mul");
 Builder.defineMacro("__riscv_div");
 Builder.defineMacro("__riscv_muldiv");
   }
 
   if (HasA) {
+Builder.defineMacro("__riscv_a", "200");
 Builder.defineMacro("__riscv_atomic");
 Builder.defineMacro("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_1");
 Builder.defineMacro("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_2");
@@ -125,22 +130,32 @@
   }
 
   if (HasF || HasD) {
+Builder.defineMacro("__riscv_f", "200");
 Builder.defineMacro("__riscv_flen", HasD ? "64" : "32");
 Builder.defineMacro("__riscv_fdiv");
 Builder.defineMacro("__riscv_fsqrt");
   }
 
-  if (HasC)
+  if (HasD)
+Builder.defineMacro("__riscv_d", "200");
+
+  if (HasC) {
+Builder.defineMacro("__riscv_c", "200");
 Builder.defineMacro("__riscv_compressed");
+  }
 
-  if (HasB)
+  if (HasB) {
+Builder.defineMacro("__riscv_b", "92000");
 Builder.defineMacro("__riscv_bitmanip");
+  }
 
-  if (HasV)
+  if (HasV) {
+Builder.defineMacro("__riscv_v", "9000");
 Builder.defineMacro("__riscv_vector");
+  }
 
   if (HasZfh)
-Builder.defineMacro("__risc

[PATCH] D91898: [attributes] Add a facility for defining and enforcing a Trusted Computing Base.

2021-01-11 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ added a comment.

Yup, i'm sorry. I even saw this failure locally but was like "this test doesn't 
look familiar, probably someone else broke it" which i wouldn't have said if i 
looked at it for more than 1 second as it's strikingly obvious. My bad.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91898

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


Re: [clang] 419ef38 - Revert "[attributes] Add a facility for enforcing a Trusted Computing Base."

2021-01-11 Thread Artem Dergachev via cfe-commits

Uh-oh, missed the test. Thanks!

The compile error looks like a gcc bug; i'll add a workaround. 
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67274; fixed in gcc 7.1 
but this buildbot uses gcc 6.3)


On 1/11/21 6:51 AM, Nico Weber via cfe-commits wrote:

Author: Nico Weber
Date: 2021-01-11T09:51:06-05:00
New Revision: 419ef38a50293c58078f830517f5e305068dbee6

URL: 
https://github.com/llvm/llvm-project/commit/419ef38a50293c58078f830517f5e305068dbee6
DIFF: 
https://github.com/llvm/llvm-project/commit/419ef38a50293c58078f830517f5e305068dbee6.diff

LOG: Revert "[attributes]  Add a facility for enforcing a Trusted Computing 
Base."

This reverts commit c163aae45ef6b7f3bd99601195d3ce4aad5850c6.
Doesn't compile on some bots
(http://lab.llvm.org:8011/#/builders/98/builds/3387/steps/9/logs/stdio),
breaks tests on bots where it does compile
(http://45.33.8.238/linux/36843/step_7.txt).

Added:
 


Modified:
 clang/include/clang/Basic/Attr.td
 clang/include/clang/Basic/AttrDocs.td
 clang/include/clang/Basic/DiagnosticSemaKinds.td
 clang/include/clang/Sema/Sema.h
 clang/lib/Sema/SemaChecking.cpp
 clang/lib/Sema/SemaDecl.cpp
 clang/lib/Sema/SemaDeclAttr.cpp

Removed:
 clang/test/Sema/attr-enforce-tcb-errors.cpp
 clang/test/Sema/attr-enforce-tcb.c
 clang/test/Sema/attr-enforce-tcb.cpp



diff  --git a/clang/include/clang/Basic/Attr.td 
b/clang/include/clang/Basic/Attr.td
index c51e95fa6fa8..248409946123 100644
--- a/clang/include/clang/Basic/Attr.td
+++ b/clang/include/clang/Basic/Attr.td
@@ -3653,19 +3653,3 @@ def Builtin : InheritableAttr {
let SemaHandler = 0;
let Documentation = [Undocumented];
  }
-
-def EnforceTCB : InheritableAttr {
-  let Spellings = [Clang<"enforce_tcb">];
-  let Subjects = SubjectList<[Function]>;
-  let Args = [StringArgument<"TCBName">];
-  let Documentation = [EnforceTCBDocs];
-  bit InheritEvenIfAlreadyPresent = 1;
-}
-
-def EnforceTCBLeaf : InheritableAttr {
-  let Spellings = [Clang<"enforce_tcb_leaf">];
-  let Subjects = SubjectList<[Function]>;
-  let Args = [StringArgument<"TCBName">];
-  let Documentation = [EnforceTCBLeafDocs];
-  bit InheritEvenIfAlreadyPresent = 1;
-}

diff  --git a/clang/include/clang/Basic/AttrDocs.td 
b/clang/include/clang/Basic/AttrDocs.td
index fffede41db1e..9cf0c59e07bb 100644
--- a/clang/include/clang/Basic/AttrDocs.td
+++ b/clang/include/clang/Basic/AttrDocs.td
@@ -5725,28 +5725,3 @@ Attribute docs`_, and `the GCC Inline docs`_.
  }];
let Heading = "always_inline, __force_inline";
  }
-
-def EnforceTCBDocs : Documentation {
-  let Category = DocCatFunction;
-  let Content = [{
-  The ``enforce_tcb`` attribute can be placed on functions to enforce that a
-  trusted compute base (TCB) does not call out of the TCB. This generates a
-  warning every time a function not marked with an ``enforce_tcb`` attribute is
-  called from a function with the ``enforce_tcb`` attribute. A function may be 
a
-  part of multiple TCBs. Invocations through function pointers are currently
-  not checked. Builtins are considered to a part of every TCB.
-
-  - ``enforce_tcb(Name)`` indicates that this function is a part of the TCB 
named ``Name``
-  }];
-}
-
-def EnforceTCBLeafDocs : Documentation {
-  let Category = DocCatFunction;
-  let Content = [{
-  The ``enforce_tcb_leaf`` attribute satisfies the requirement enforced by
-  ``enforce_tcb`` for the marked function to be in the named TCB but does not
-  continue to check the functions called from within the leaf function.
-
-  - ``enforce_tcb_leaf(Name)`` indicates that this function is a part of the 
TCB named ``Name``
-  }];
-}

diff  --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index c048fc89813f..0405195912b2 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -6,11 +6,4 @@ def err_probability_not_constant_float : Error<
  def err_probability_out_of_range : Error<
 "probability argument to __builtin_expect_with_probability is outside the "
 "range [0.0, 1.0]">;
-
-// TCB warnings
-def err_tcb_conflicting_attributes : Error<
-  "attributes '%0(\"%2\")' and '%1(\"%2\")' are mutually exclusive">;
-def warn_tcb_enforcement_violation : Warning<
-  "calling %0 is a violation of trusted computing base '%1'">,
-  InGroup>;
  } // end of sema component.

diff  --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
index 4de3b962c660..1d79e5716ef7 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -3210,9 +3210,6 @@ class Sema final {
Decl *D, const WebAssemblyImportNameAttr &AL);
WebAssemblyImportModuleAttr *mergeImportModuleAttr(
Decl *D, const WebAssemblyImportModuleAttr &AL);
-  EnforceTCBAttr *mergeEnforceTCBAttr(Decl *D, const EnforceTCBAttr &AL);
-  EnforceTCBLeafAttr *mer

[PATCH] D94411: [clangd] Fix -check mode doesn't respect any tidy configs.

2021-01-11 Thread Haojian Wu via Phabricator via cfe-commits
hokein added a comment.

no test added -- it is not easy, since we don't emit tidy warnings in check 
mode (maybe we should?), I confirmed that it worked (with manual test).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94411

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


[PATCH] D94131: [clang-tidy] Use new mapAnyOf matcher

2021-01-11 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.

In D94131#2481804 , @njames93 wrote:

> Theres a few compile errors here in the pre merge. Is this patch based 
> against trunk or some local branch?

It's a patch series but for some reason Phab isn't aware of that, hence the 
lint errors and seemingly odd use of things not already landed.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94131

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


[PATCH] D94127: [ASTMatchers] Add mapAnyOf matcher

2021-01-11 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!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94127

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


[PATCH] D94129: [ASTMatchers] Add binaryOperation matcher

2021-01-11 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/include/clang/ASTMatchers/ASTMatchers.h:2739
 
+/// Matches nodes which can be used with binary operators
+///





Comment at: clang/include/clang/ASTMatchers/ASTMatchers.h:2785
+internal::BindableMatcher
+binaryOperation(InnerMatcherType &&... Matchers) {
+  return mapAnyOf(binaryOperator, cxxOperatorCallExpr).with(Matchers...);

Missing changes to Registry.cpp to expose this to clang-query?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94129

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


[PATCH] D91898: [attributes] Add a facility for defining and enforcing a Trusted Computing Base.

2021-01-11 Thread Nico Weber via Phabricator via cfe-commits
thakis added a comment.

Hi, this broke check-clang everywhere as far as I can tell. Please run tests 
before committing. I've reverted this for now in 
419ef38a50293c58078f830517f5e305068dbee6 
.

For some host compilers, it also broke the build: 
http://lab.llvm.org:8011/#/builders/98/builds/3387/steps/9/logs/stdio (But 
that's impossible to know in advance.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91898

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


[clang] 419ef38 - Revert "[attributes] Add a facility for enforcing a Trusted Computing Base."

2021-01-11 Thread Nico Weber via cfe-commits

Author: Nico Weber
Date: 2021-01-11T09:51:06-05:00
New Revision: 419ef38a50293c58078f830517f5e305068dbee6

URL: 
https://github.com/llvm/llvm-project/commit/419ef38a50293c58078f830517f5e305068dbee6
DIFF: 
https://github.com/llvm/llvm-project/commit/419ef38a50293c58078f830517f5e305068dbee6.diff

LOG: Revert "[attributes]  Add a facility for enforcing a Trusted Computing 
Base."

This reverts commit c163aae45ef6b7f3bd99601195d3ce4aad5850c6.
Doesn't compile on some bots
(http://lab.llvm.org:8011/#/builders/98/builds/3387/steps/9/logs/stdio),
breaks tests on bots where it does compile
(http://45.33.8.238/linux/36843/step_7.txt).

Added: 


Modified: 
clang/include/clang/Basic/Attr.td
clang/include/clang/Basic/AttrDocs.td
clang/include/clang/Basic/DiagnosticSemaKinds.td
clang/include/clang/Sema/Sema.h
clang/lib/Sema/SemaChecking.cpp
clang/lib/Sema/SemaDecl.cpp
clang/lib/Sema/SemaDeclAttr.cpp

Removed: 
clang/test/Sema/attr-enforce-tcb-errors.cpp
clang/test/Sema/attr-enforce-tcb.c
clang/test/Sema/attr-enforce-tcb.cpp



diff  --git a/clang/include/clang/Basic/Attr.td 
b/clang/include/clang/Basic/Attr.td
index c51e95fa6fa8..248409946123 100644
--- a/clang/include/clang/Basic/Attr.td
+++ b/clang/include/clang/Basic/Attr.td
@@ -3653,19 +3653,3 @@ def Builtin : InheritableAttr {
   let SemaHandler = 0;
   let Documentation = [Undocumented];
 }
-
-def EnforceTCB : InheritableAttr {
-  let Spellings = [Clang<"enforce_tcb">];
-  let Subjects = SubjectList<[Function]>;
-  let Args = [StringArgument<"TCBName">];
-  let Documentation = [EnforceTCBDocs];
-  bit InheritEvenIfAlreadyPresent = 1;
-}
-
-def EnforceTCBLeaf : InheritableAttr {
-  let Spellings = [Clang<"enforce_tcb_leaf">];
-  let Subjects = SubjectList<[Function]>;
-  let Args = [StringArgument<"TCBName">];
-  let Documentation = [EnforceTCBLeafDocs];
-  bit InheritEvenIfAlreadyPresent = 1;
-}

diff  --git a/clang/include/clang/Basic/AttrDocs.td 
b/clang/include/clang/Basic/AttrDocs.td
index fffede41db1e..9cf0c59e07bb 100644
--- a/clang/include/clang/Basic/AttrDocs.td
+++ b/clang/include/clang/Basic/AttrDocs.td
@@ -5725,28 +5725,3 @@ Attribute docs`_, and `the GCC Inline docs`_.
 }];
   let Heading = "always_inline, __force_inline";
 }
-
-def EnforceTCBDocs : Documentation {
-  let Category = DocCatFunction;
-  let Content = [{
-  The ``enforce_tcb`` attribute can be placed on functions to enforce that a
-  trusted compute base (TCB) does not call out of the TCB. This generates a
-  warning every time a function not marked with an ``enforce_tcb`` attribute is
-  called from a function with the ``enforce_tcb`` attribute. A function may be 
a
-  part of multiple TCBs. Invocations through function pointers are currently
-  not checked. Builtins are considered to a part of every TCB.
-
-  - ``enforce_tcb(Name)`` indicates that this function is a part of the TCB 
named ``Name``
-  }];
-}
-
-def EnforceTCBLeafDocs : Documentation {
-  let Category = DocCatFunction;
-  let Content = [{
-  The ``enforce_tcb_leaf`` attribute satisfies the requirement enforced by
-  ``enforce_tcb`` for the marked function to be in the named TCB but does not
-  continue to check the functions called from within the leaf function.
-
-  - ``enforce_tcb_leaf(Name)`` indicates that this function is a part of the 
TCB named ``Name``
-  }];
-}

diff  --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index c048fc89813f..0405195912b2 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -6,11 +6,4 @@ def err_probability_not_constant_float : Error<
 def err_probability_out_of_range : Error<
"probability argument to __builtin_expect_with_probability is outside the "
"range [0.0, 1.0]">;
-
-// TCB warnings
-def err_tcb_conflicting_attributes : Error<
-  "attributes '%0(\"%2\")' and '%1(\"%2\")' are mutually exclusive">;
-def warn_tcb_enforcement_violation : Warning<
-  "calling %0 is a violation of trusted computing base '%1'">,
-  InGroup>;
 } // end of sema component.

diff  --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
index 4de3b962c660..1d79e5716ef7 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -3210,9 +3210,6 @@ class Sema final {
   Decl *D, const WebAssemblyImportNameAttr &AL);
   WebAssemblyImportModuleAttr *mergeImportModuleAttr(
   Decl *D, const WebAssemblyImportModuleAttr &AL);
-  EnforceTCBAttr *mergeEnforceTCBAttr(Decl *D, const EnforceTCBAttr &AL);
-  EnforceTCBLeafAttr *mergeEnforceTCBLeafAttr(Decl *D,
-  const EnforceTCBLeafAttr &AL);
 
   void mergeDeclAttributes(NamedDecl *New, Decl *Old,
AvailabilityMergeKind AMK = AMK_Redeclaration);
@@ -12430,8 +12427,6 @@ class Sema fin

[PATCH] D90976: [NFC] Fixed an issue where diagnostics printed expressions in a roundabout way

2021-01-11 Thread Hans Wennborg via Phabricator via cfe-commits
hans added inline comments.



Comment at: clang/lib/AST/TemplateBase.cpp:485
   case TemplateArgument::Expression: {
-// This shouldn't actually ever happen, so it's okay that we're
-// regurgitating an expression here.

This code looks like a very special case, and the LangOptions comments suggests 
it's a bit hacky.
Because of that I'm not sure it makes sense to promote it to what looks like a 
general-purpose operator<< for Expr. What's the motivation for that?



Comment at: clang/lib/Sema/SemaTemplateDeduction.cpp:463
   .get();
+  TemplateArgument TV(Value);
   return DeduceNonTypeTemplateArgument(S, TemplateParams, NTTP,

nit: I guess TV is tor template value, but maybe TA would be a better name?


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

https://reviews.llvm.org/D90976

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


[PATCH] D94411: [clangd] Fix -check mode doesn't respect any tidy configs.

2021-01-11 Thread Haojian Wu via Phabricator via cfe-commits
hokein created this revision.
hokein added a reviewer: sammccall.
Herald added subscribers: usaxena95, kadircet, arphaman.
hokein requested review of this revision.
Herald added subscribers: MaskRay, ilya-biryukov.
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D94411

Files:
  clang-tools-extra/clangd/tool/Check.cpp


Index: clang-tools-extra/clangd/tool/Check.cpp
===
--- clang-tools-extra/clangd/tool/Check.cpp
+++ clang-tools-extra/clangd/tool/Check.cpp
@@ -123,6 +123,7 @@
 std::vector CC1Args;
 Inputs.CompileCommand = Cmd;
 Inputs.TFS = &TFS;
+Inputs.ClangTidyProvider = Opts.ClangTidyProvider;
 if (Contents.hasValue()) {
   Inputs.Contents = *Contents;
   log("Imaginary source file contents:\n{0}", Inputs.Contents);


Index: clang-tools-extra/clangd/tool/Check.cpp
===
--- clang-tools-extra/clangd/tool/Check.cpp
+++ clang-tools-extra/clangd/tool/Check.cpp
@@ -123,6 +123,7 @@
 std::vector CC1Args;
 Inputs.CompileCommand = Cmd;
 Inputs.TFS = &TFS;
+Inputs.ClangTidyProvider = Opts.ClangTidyProvider;
 if (Contents.hasValue()) {
   Inputs.Contents = *Contents;
   log("Imaginary source file contents:\n{0}", Inputs.Contents);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D94130: [ASTMatchers] Add support for CXXRewrittenBinaryOperator

2021-01-11 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/include/clang/ASTMatchers/ASTMatchers.h:2000
+   CXXRewrittenBinaryOperator>
+cxxRewrittenBinaryOperator;
+

Missing changes to Registry.cpp to expose this to clang-query?



Comment at: clang/include/clang/ASTMatchers/ASTMatchers.h:5346
+AST_POLYMORPHIC_SUPPORTED_TYPES(BinaryOperator, CXXOperatorCallExpr,
+CXXRewrittenBinaryOperator)) {
   return Node.isAssignmentOp();

This change surprises me -- aren't rewritten binary operators *always* 
comparison operations? I don't know of a time when they'd ever be an assignment 
operator.



Comment at: clang/lib/ASTMatchers/ASTMatchFinder.cpp:260
+
+auto DCF = Node->getDecomposedForm();
+if (!match(*DCF.LHS) || !match(*DCF.RHS))

Please spell out this use of `auto`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94130

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


[PATCH] D91898: [attributes] Add a facility for defining and enforcing a Trusted Computing Base.

2021-01-11 Thread Artem Dergachev via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGc163aae45ef6: [attributes]  Add a facility for enforcing a 
Trusted Computing Base. (authored by dergachev.a).
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91898

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/Sema/attr-enforce-tcb-errors.cpp
  clang/test/Sema/attr-enforce-tcb.c
  clang/test/Sema/attr-enforce-tcb.cpp

Index: clang/test/Sema/attr-enforce-tcb.cpp
===
--- /dev/null
+++ clang/test/Sema/attr-enforce-tcb.cpp
@@ -0,0 +1,70 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+
+#define PLACE_IN_TCB(NAME) [[clang::enforce_tcb(NAME)]]
+#define PLACE_IN_TCB_LEAF(NAME) [[clang::enforce_tcb_leaf(NAME)]]
+
+PLACE_IN_TCB("foo") void in_tcb_foo();
+void not_in_tcb();
+
+// Test behavior on classes and methods.
+class C {
+  void bar();
+
+  PLACE_IN_TCB("foo")
+  void foo() {
+// TODO: Figure out if we want to support methods at all.
+// Does it even make sense to isolate individual methods into a TCB?
+// Maybe a per-class attribute would make more sense?
+bar(); // expected-warning{{calling 'bar' is a violation of trusted computing base 'foo'}}
+  }
+};
+
+// Test behavior on templates.
+template 
+PLACE_IN_TCB("foo")
+void foo_never_instantiated() {
+  not_in_tcb(); // expected-warning{{calling 'not_in_tcb' is a violation of trusted computing base 'foo'}}
+  in_tcb_foo(); // no-warning
+}
+
+template 
+PLACE_IN_TCB("foo")
+void foo_specialized();
+
+template<>
+void foo_specialized() {
+  not_in_tcb(); // expected-warning{{calling 'not_in_tcb' is a violation of trusted computing base 'foo'}}
+  in_tcb_foo(); // no-warning
+}
+
+PLACE_IN_TCB("foo")
+void call_template_good() {
+  foo_specialized(); // no-warning
+}
+PLACE_IN_TCB("bar")
+void call_template_bad() {
+  foo_specialized(); // expected-warning{{calling 'foo_specialized' is a violation of trusted computing base 'bar'}}
+}
+
+template
+void foo_specialization_in_tcb();
+
+template<>
+PLACE_IN_TCB("foo")
+void foo_specialization_in_tcb() {
+  not_in_tcb(); //expected-warning{{calling 'not_in_tcb' is a violation of trusted computing base 'foo'}}
+  in_tcb_foo(); // no-warning
+}
+
+template<>
+void foo_specialization_in_tcb() {
+  not_in_tcb(); // no-warning
+  in_tcb_foo(); // no-warning
+}
+
+PLACE_IN_TCB("foo")
+void call_specialization_in_tcb() {
+  foo_specialization_in_tcb(); // no-warning
+  foo_specialization_in_tcb(); // expected-warning{{calling 'foo_specialization_in_tcb' is a violation of trusted computing base 'foo'}}
+  foo_specialization_in_tcb(); // expected-warning{{'foo_specialization_in_tcb' is a violation of trusted computing base 'foo'}}
+}
Index: clang/test/Sema/attr-enforce-tcb.c
===
--- /dev/null
+++ clang/test/Sema/attr-enforce-tcb.c
@@ -0,0 +1,65 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+
+#define PLACE_IN_TCB(NAME) __attribute__ ((enforce_tcb(NAME)))
+#define PLACE_IN_TCB_LEAF(NAME) __attribute__ ((enforce_tcb_leaf(NAME)))
+
+void foo1 (void) PLACE_IN_TCB("bar");
+void foo2 (void) PLACE_IN_TCB("bar");
+void foo3 (void); // not in any TCB
+void foo4 (void) PLACE_IN_TCB("bar2");
+void foo5 (void) PLACE_IN_TCB_LEAF("bar");
+void foo6 (void) PLACE_IN_TCB("bar2") PLACE_IN_TCB("bar");
+void foo7 (void) PLACE_IN_TCB("bar3");
+void foo8 (void) PLACE_IN_TCB("bar") PLACE_IN_TCB("bar2");
+void foo9 (void);
+
+void foo1() {
+foo2(); // OK - function in same TCB
+foo3(); // expected-warning {{calling 'foo3' is a violation of trusted computing base 'bar'}}
+foo4(); // expected-warning {{calling 'foo4' is a violation of trusted computing base 'bar'}}
+foo5(); // OK - in leaf node
+foo6(); // OK - in multiple TCBs, one of which is the same
+foo7(); // expected-warning {{calling 'foo7' is a violation of trusted computing base 'bar'}}
+(void) __builtin_clz(5); // OK - builtins are excluded
+}
+
+// Normal use without any attributes works
+void foo3() {
+foo9(); // no-warning
+}
+
+void foo5() {
+// all calls should be okay, function in TCB leaf
+foo2(); // no-warning
+foo3(); // no-warning
+foo4(); // no-warning
+}
+
+void foo6() {
+foo1(); // expected-warning {{calling 'foo1' is a violation of trusted computing base 'bar2'}}
+foo4(); // expected-warning {{calling 'foo4' is a violation of trusted computing base 'bar'}}
+foo8(); // no-warning
+foo7(); // #1
+// expected-warning@#1 {{calling 'foo7' is a violation of trusted computing base 'bar2'}}
+// expected-warning@#1 {{calling 'foo7' is

[clang] c163aae - [attributes] Add a facility for enforcing a Trusted Computing Base.

2021-01-11 Thread Artem Dergachev via cfe-commits

Author: Artem Dergachev
Date: 2021-01-11T06:39:42-08:00
New Revision: c163aae45ef6b7f3bd99601195d3ce4aad5850c6

URL: 
https://github.com/llvm/llvm-project/commit/c163aae45ef6b7f3bd99601195d3ce4aad5850c6
DIFF: 
https://github.com/llvm/llvm-project/commit/c163aae45ef6b7f3bd99601195d3ce4aad5850c6.diff

LOG: [attributes]  Add a facility for enforcing a Trusted Computing Base.

Introduce a function attribute 'enforce_tcb' that prevents the function
from calling other functions without the same attribute. This allows
isolating code that's considered to be somehow privileged so that it could not
use its privileges to exhibit arbitrary behavior.

Introduce an on-by-default warning '-Wtcb-enforcement' that warns
about violations of the above rule.

Introduce a function attribute 'enforce_tcb_leaf' that suppresses
the new warning within the function it is attached to. Such leaf functions
may implement common functionality between the trusted and the untrusted code
but they require extra careful audit with respect to their capabilities.

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

Added: 
clang/test/Sema/attr-enforce-tcb-errors.cpp
clang/test/Sema/attr-enforce-tcb.c
clang/test/Sema/attr-enforce-tcb.cpp

Modified: 
clang/include/clang/Basic/Attr.td
clang/include/clang/Basic/AttrDocs.td
clang/include/clang/Basic/DiagnosticSemaKinds.td
clang/include/clang/Sema/Sema.h
clang/lib/Sema/SemaChecking.cpp
clang/lib/Sema/SemaDecl.cpp
clang/lib/Sema/SemaDeclAttr.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/Attr.td 
b/clang/include/clang/Basic/Attr.td
index 248409946123..c51e95fa6fa8 100644
--- a/clang/include/clang/Basic/Attr.td
+++ b/clang/include/clang/Basic/Attr.td
@@ -3653,3 +3653,19 @@ def Builtin : InheritableAttr {
   let SemaHandler = 0;
   let Documentation = [Undocumented];
 }
+
+def EnforceTCB : InheritableAttr {
+  let Spellings = [Clang<"enforce_tcb">];
+  let Subjects = SubjectList<[Function]>;
+  let Args = [StringArgument<"TCBName">];
+  let Documentation = [EnforceTCBDocs];
+  bit InheritEvenIfAlreadyPresent = 1;
+}
+
+def EnforceTCBLeaf : InheritableAttr {
+  let Spellings = [Clang<"enforce_tcb_leaf">];
+  let Subjects = SubjectList<[Function]>;
+  let Args = [StringArgument<"TCBName">];
+  let Documentation = [EnforceTCBLeafDocs];
+  bit InheritEvenIfAlreadyPresent = 1;
+}

diff  --git a/clang/include/clang/Basic/AttrDocs.td 
b/clang/include/clang/Basic/AttrDocs.td
index 9cf0c59e07bb..fffede41db1e 100644
--- a/clang/include/clang/Basic/AttrDocs.td
+++ b/clang/include/clang/Basic/AttrDocs.td
@@ -5725,3 +5725,28 @@ Attribute docs`_, and `the GCC Inline docs`_.
 }];
   let Heading = "always_inline, __force_inline";
 }
+
+def EnforceTCBDocs : Documentation {
+  let Category = DocCatFunction;
+  let Content = [{
+  The ``enforce_tcb`` attribute can be placed on functions to enforce that a
+  trusted compute base (TCB) does not call out of the TCB. This generates a
+  warning every time a function not marked with an ``enforce_tcb`` attribute is
+  called from a function with the ``enforce_tcb`` attribute. A function may be 
a
+  part of multiple TCBs. Invocations through function pointers are currently
+  not checked. Builtins are considered to a part of every TCB.
+
+  - ``enforce_tcb(Name)`` indicates that this function is a part of the TCB 
named ``Name``
+  }];
+}
+
+def EnforceTCBLeafDocs : Documentation {
+  let Category = DocCatFunction;
+  let Content = [{
+  The ``enforce_tcb_leaf`` attribute satisfies the requirement enforced by
+  ``enforce_tcb`` for the marked function to be in the named TCB but does not
+  continue to check the functions called from within the leaf function.
+
+  - ``enforce_tcb_leaf(Name)`` indicates that this function is a part of the 
TCB named ``Name``
+  }];
+}

diff  --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index 0405195912b2..c048fc89813f 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -6,4 +6,11 @@ def err_probability_not_constant_float : Error<
 def err_probability_out_of_range : Error<
"probability argument to __builtin_expect_with_probability is outside the "
"range [0.0, 1.0]">;
+
+// TCB warnings
+def err_tcb_conflicting_attributes : Error<
+  "attributes '%0(\"%2\")' and '%1(\"%2\")' are mutually exclusive">;
+def warn_tcb_enforcement_violation : Warning<
+  "calling %0 is a violation of trusted computing base '%1'">,
+  InGroup>;
 } // end of sema component.

diff  --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
index 1d79e5716ef7..4de3b962c660 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -3210,6 +3210,9 @@ class Sema final {
   Decl *D, const WebAssemblyImportNameAttr &AL);
   WebAssemblyImportModule

[PATCH] D94128: [ASTMatchers] Make cxxOperatorCallExpr matchers API-compatible with n-ary operators

2021-01-11 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/include/clang/ASTMatchers/ASTMatchersInternal.h:1994
+  return None;
+return FD->getNumParams() > 0 ? UO_PostInc : UO_PreInc;
+  }

Not certain how much we want to care about it, but I think we need to check 
whether there's exactly one parameter of type `int` to meet the language rules 
for these to be replacement APIs: http://eel.is/c++draft/over.inc#1

e.g., the user could do something rather unlikely like: `int 
operator++(float);` for their overload and we're report it as being equivalent 
when it really isn't.



Comment at: clang/include/clang/ASTMatchers/ASTMatchersInternal.h:2142-2150
+  auto optBinaryOpcode = equivalentBinaryOperator(Node);
+  if (!optBinaryOpcode) {
+auto optUnaryOpcode = equivalentUnaryOperator(Node);
+if (!optUnaryOpcode) {
+  return false;
+}
+return Name == UnaryOperator::getOpcodeStr(*optUnaryOpcode);

Can we reuse the implementation from `getOpName()` to simplify this?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94128

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


[PATCH] D92751: [clang][aarch64] Precondition isHomogeneousAggregate on isCXX14Aggregate

2021-01-11 Thread David Truby via Phabricator via cfe-commits
DavidTruby updated this revision to Diff 315788.
DavidTruby marked an inline comment as done.
DavidTruby added a comment.

Fix tests to use check-label correctly and add proper precondition on aarch64


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92751

Files:
  clang/lib/CodeGen/CGCXXABI.h
  clang/lib/CodeGen/MicrosoftCXXABI.cpp
  clang/lib/CodeGen/TargetInfo.cpp
  clang/test/CodeGenCXX/homogeneous-aggregates.cpp
  llvm/test/CodeGen/AArch64/arm64-windows-calls.ll

Index: llvm/test/CodeGen/AArch64/arm64-windows-calls.ll
===
--- llvm/test/CodeGen/AArch64/arm64-windows-calls.ll
+++ llvm/test/CodeGen/AArch64/arm64-windows-calls.ll
@@ -98,3 +98,80 @@
   %this1 = load %class.C*, %class.C** %this.addr, align 8
   ret void
 }
+
+; The following tests correspond to tests in
+; clang/test/CodeGenCXX/microsoft-abi-sret-and-byval.cpp
+
+; Pod is a trivial HFA
+%struct.Pod = type { [2 x double] }
+; Not an aggregate according to C++14 spec => not HFA according to MSVC
+%struct.NotCXX14Aggregate  = type { %struct.Pod }
+; NotPod is a C++14 aggregate. But not HFA, because it contains
+; NotCXX14Aggregate (which itself is not HFA because it's not a C++14
+; aggregate).
+%struct.NotPod = type { %struct.NotCXX14Aggregate }
+
+define dso_local %struct.Pod @copy_pod(%struct.Pod* %x) {
+  %x1 = load %struct.Pod, %struct.Pod* %x, align 8
+  ret %struct.Pod %x1
+  ; CHECK-LABEL: copy_pod
+  ; CHECK: ldp d0, d1, [x0]
+}
+
+declare void @llvm.memcpy.p0i8.p0i8.i64(i8* noalias nocapture writeonly, i8* noalias nocapture readonly, i64, i1 immarg)
+
+define dso_local void
+@copy_notcxx14aggregate(%struct.NotCXX14Aggregate* inreg noalias sret(%struct.NotCXX14Aggregate) align 8 %agg.result,
+%struct.NotCXX14Aggregate* %x) {
+  %1 = bitcast %struct.NotCXX14Aggregate* %agg.result to i8*
+  %2 = bitcast %struct.NotCXX14Aggregate* %x to i8*
+  call void @llvm.memcpy.p0i8.p0i8.i64(i8* align 8 %1, i8* align 8 %2, i64 16, i1 false)
+  ret void
+  ; CHECK-LABEL: copy_notcxx14aggregate
+  ; CHECK: str q0, [x0]
+}
+
+define dso_local [2 x i64] @copy_notpod(%struct.NotPod* %x) {
+  %x1 = bitcast %struct.NotPod* %x to [2 x i64]*
+  %x2 = load [2 x i64], [2 x i64]* %x1
+  ret [2 x i64] %x2
+  ; CHECK-LABEL: copy_notpod
+  ; CHECK: ldp x8, x1, [x0]
+  ; CHECK: mov x0, x8
+}
+
+@Pod = external global %struct.Pod
+
+define void @call_copy_pod() {
+  %x = call %struct.Pod @copy_pod(%struct.Pod* @Pod)
+  store %struct.Pod %x, %struct.Pod* @Pod
+  ret void
+  ; CHECK-LABEL: call_copy_pod
+  ; CHECK: bl copy_pod
+  ; CHECK-NEXT: stp d0, d1, [{{.*}}]
+}
+
+@NotCXX14Aggregate = external global %struct.NotCXX14Aggregate
+
+define void @call_copy_notcxx14aggregate() {
+  %x = alloca %struct.NotCXX14Aggregate
+  call void @copy_notcxx14aggregate(%struct.NotCXX14Aggregate* %x, %struct.NotCXX14Aggregate* @NotCXX14Aggregate)
+  %x1 = load %struct.NotCXX14Aggregate, %struct.NotCXX14Aggregate* %x
+  store %struct.NotCXX14Aggregate %x1, %struct.NotCXX14Aggregate* @NotCXX14Aggregate
+  ret void
+  ; CHECK-LABEL: call_copy_notcxx14aggregate
+  ; CHECK: bl copy_notcxx14aggregate
+  ; CHECK-NEXT: ldp {{.*}}, {{.*}}, [sp]
+}
+
+@NotPod = external global %struct.NotPod
+
+define void @call_copy_notpod() {
+  %x = call [2 x i64] @copy_notpod(%struct.NotPod* @NotPod)
+  %notpod = bitcast %struct.NotPod* @NotPod to [2 x i64]*
+  store [2 x i64] %x, [2 x i64]* %notpod
+  ret void
+  ; CHECK-LABEL: call_copy_notpod
+  ; CHECK: bl copy_notpod
+  ; CHECK-NEXT: stp x0, x1, [{{.*}}]
+}
Index: clang/test/CodeGenCXX/homogeneous-aggregates.cpp
===
--- clang/test/CodeGenCXX/homogeneous-aggregates.cpp
+++ clang/test/CodeGenCXX/homogeneous-aggregates.cpp
@@ -2,6 +2,7 @@
 // RUN: %clang_cc1 -mfloat-abi hard -triple armv7-unknown-linux-gnueabi -emit-llvm -o - %s | FileCheck %s --check-prefix=ARM32
 // RUN: %clang_cc1 -mfloat-abi hard -triple aarch64-unknown-linux-gnu -emit-llvm -o - %s | FileCheck %s --check-prefix=ARM64
 // RUN: %clang_cc1 -mfloat-abi hard -triple x86_64-unknown-windows-gnu -emit-llvm -o - %s | FileCheck %s --check-prefix=X64
+// RUN: %clang_cc1 -mfloat-abi hard -triple aarch64-unknown-windows-msvc -emit-llvm -o - %s | FileCheck %s --check-prefix=WOA64
 
 #if defined(__x86_64__)
 #define CC __attribute__((vectorcall))
@@ -104,3 +105,71 @@
 // ARM32: define arm_aapcs_vfpcc void @_Z19with_empty_bitfield20HVAWithEmptyBitField(%struct.HVAWithEmptyBitField %a.coerce)
 // X64: define dso_local x86_vectorcallcc void @"\01_Z19with_empty_bitfield20HVAWithEmptyBitField@@16"(%struct.HVAWithEmptyBitField inreg %a.coerce)
 void CC with_empty_bitfield(HVAWithEmptyBitField a) {}
+
+namespace pr47611 {
+// MSVC on Arm includes "isCXX14Aggregate" as part of its definition of
+// Homogeneous Floating-point Aggregate (HFA). Additionally, it has a different

[PATCH] D93999: [clang] Fix message text for `-Wpointer-sign` to account for plain char

2021-01-11 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 aside from some very minor nits.




Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:7784
+  " converts between pointers to integer types %select{with different sign|"
+  "where one is of the unique plain char type and the other is not}3">,
   InGroup>;





Comment at: clang/lib/Sema/SemaExpr.cpp:15967
+  DiagKind == diag::err_typecheck_convert_incompatible_pointer_sign) {
+const auto isPlainChar = [](const clang::Type *Type) {
+  return Type->isSpecificBuiltinType(BuiltinType::Char_S) ||

We don't typically use top-level `const` on value types for local variables.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93999

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


[PATCH] D93630: [Attr] Apply GNU-style attributes to expression statements

2021-01-11 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D93630#2486574 , @aaron.ballman 
wrote:

> I'm going to see if I can run the patch against our internal corpus here at 
> work to see if it shakes out any breakages to real world code. I've not tried 
> this before, so I have no idea how long it will take before I get results 
> back, but I'll let you know when I have them.

The tests finally finished over the weekend and came back with no new failures 
-- that gives me a lot more confidence that this doesn't accidentally change 
behavior in cases users are likely to hit (at least in C and C++). I think the 
next steps are to clean up the tests and then coordinate with the GCC folks to 
ensure they don't have any strong objections we should be aware of.




Comment at: clang/test/Parser/stmt-attributes.c:5
+
+  __attribute__((unknown_attribute));// expected-warning {{unknown 
attribute 'unknown_attribute' ignored}}
+  __attribute__((unknown_attribute)) {}  // expected-warning {{unknown 
attribute 'unknown_attribute' ignored}}

Given that these are parser tests, I think you can drop the attribute name 
itself except in the cases where you explicitly want to test that an unknown 
attribute introduces the start of a declaration (or things where the attribute 
identifier matters for some reason). This will reduce the amount of 
`expected-warning` comments we need to add.

Also, because this change impacts C++ and ObjC/C++ as well, I think we should 
have some tests for language-specific constructs like lambdas, range-based for 
loops, blocks, etc.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93630

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


[PATCH] D93585: [AArch64] Enable out-of-line atomics by default.

2021-01-11 Thread Tim Northover via Phabricator via cfe-commits
t.p.northover added inline comments.



Comment at: clang/include/clang/Driver/ToolChain.h:460
+  /// Test whether this toolchain supports outline atomics by default.
+  virtual bool IsOADefault(const llvm::opt::ArgList &Args) const {
+return false;

This is a pretty niche feature, so it might be better to spell out the full 
name. Maybe even throw "AArch64" in there so more people know they can ignore 
it.



Comment at: clang/lib/Driver/ToolChains/Linux.cpp:840
+bool Linux::IsOADefault(const ArgList &Args) const {
+  if (!getTriple().isAndroid() && !getTriple().isOSLinux()) {
+return false;

Can this be an assertion? How does a non-Linux triple end up in 
`Linux::IsOADefault`? Also, I think the `isAndroid` check is redundant: Android 
is Linux (both in reality and in valid `llvm::Triple`s).



Comment at: llvm/lib/Target/AArch64/AArch64.td:1087
  FeatureNEON,
+ FeatureOutlineAtomics,
  FeaturePerfMon,

I think this still enables it more widely than we want. Clang overrides it with 
`-outline-atomics`, but other front-ends don't.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93585

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


[PATCH] D94169: [clang][driver] Restore the original help text for `-I`

2021-01-11 Thread Andrzej Warzynski via Phabricator via cfe-commits
awarzynski updated this revision to Diff 315765.
awarzynski added a comment.

Implement SUGGESTION 1

I haven't updated the patch description yet - I'd rather keep it as is while 
the actual direction for this patch is being discussed.

Also, I regenerated ClangCommandLineReference.rst and discovered that many 
options are out-of-sync with Options.td. In order not to digress, I've only 
updated the description for `-I`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94169

Files:
  clang/docs/ClangCommandLineReference.rst
  clang/include/clang/Driver/Options.td


Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -649,12 +649,12 @@
  "remove current directory from include path">;
 def I : JoinedOrSeparate<["-"], "I">, Group,
 Flags<[CC1Option,CC1AsOption]>, MetaVarName<"">,
-HelpText<"Add directory to include search path. If there are multiple -I "
- "options, these directories are searched in the order they are "
- "given before the standard system directories are searched. "
- "If the same directory is in the SYSTEM include search paths, for 
"
- "example if also specified with -isystem, the -I option will be "
- "ignored">;
+HelpText<"Add directory to include search path. In Clang drivers, if "
+ "there are multiple -I options, these directories are searched "
+ "in the order they are given before the standard system directories "
+ "are searched. If the same directory is in the SYSTEM include search "
+ "paths, for example if also specified with -isystem, the -I option "
+ "will be ignored">;
 def L : JoinedOrSeparate<["-"], "L">, Flags<[RenderJoined]>, Group,
 MetaVarName<"">, HelpText<"Add directory to library search path">;
 def MD : Flag<["-"], "MD">, Group,
Index: clang/docs/ClangCommandLineReference.rst
===
--- clang/docs/ClangCommandLineReference.rst
+++ clang/docs/ClangCommandLineReference.rst
@@ -1016,7 +1016,7 @@
 
 .. option:: -I, --include-directory , --include-directory=
 
-Add directory to include search path. If there are multiple -I options, these 
directories are searched in the order they are given before the standard system 
directories are searched. If the same directory is in the SYSTEM include search 
paths, for example if also specified with -isystem, the -I option will be 
ignored
+Add directory to include search path. In Clang drivers, if there are multiple 
-I options, these directories are searched in the order they are given before 
the standard system directories are searched. If the same directory is in the 
SYSTEM include search paths, for example if also specified with -isystem, the 
-I option will be ignored
 
 .. option:: -I-, --include-barrier
 


Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -649,12 +649,12 @@
  "remove current directory from include path">;
 def I : JoinedOrSeparate<["-"], "I">, Group,
 Flags<[CC1Option,CC1AsOption]>, MetaVarName<"">,
-HelpText<"Add directory to include search path. If there are multiple -I "
- "options, these directories are searched in the order they are "
- "given before the standard system directories are searched. "
- "If the same directory is in the SYSTEM include search paths, for "
- "example if also specified with -isystem, the -I option will be "
- "ignored">;
+HelpText<"Add directory to include search path. In Clang drivers, if "
+ "there are multiple -I options, these directories are searched "
+ "in the order they are given before the standard system directories "
+ "are searched. If the same directory is in the SYSTEM include search "
+ "paths, for example if also specified with -isystem, the -I option "
+ "will be ignored">;
 def L : JoinedOrSeparate<["-"], "L">, Flags<[RenderJoined]>, Group,
 MetaVarName<"">, HelpText<"Add directory to library search path">;
 def MD : Flag<["-"], "MD">, Group,
Index: clang/docs/ClangCommandLineReference.rst
===
--- clang/docs/ClangCommandLineReference.rst
+++ clang/docs/ClangCommandLineReference.rst
@@ -1016,7 +1016,7 @@
 
 .. option:: -I, --include-directory , --include-directory=
 
-Add directory to include search path. If there are multiple -I options, these directories are searched in the order they are given before the standard system directories are searched. If the same directory is in the SYSTEM include search paths, 

[PATCH] D94403: [RISCV] Implement new architecture extension macros

2021-01-11 Thread Simon Cook via Phabricator via cfe-commits
simoncook created this revision.
simoncook added reviewers: asb, luismarques, kito-cheng.
Herald added subscribers: frasercrmck, NickHung, evandro, apazos, 
sameer.abuasal, pzheng, s.egerton, lenary, Jim, benna, psnobl, jocewei, PkmX, 
the_o, brucehoult, MartinMosbeck, rogfer01, edward-jones, zzheng, jrtc27, 
shiva0217, niosHD, sabuasal, johnrusso, rbar.
simoncook requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay.
Herald added a project: clang.

This adds support for the new architecture extension test macros as
defined in the C-API Document:
https://github.com/riscv/riscv-c-api-doc/blob/master/riscv-c-api.md

Extension versions have been taken from what are used in
RISCVTargetStreamer for ratified extensions, and the -march parser
for experimental extensions.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D94403

Files:
  clang/lib/Basic/Targets/RISCV.cpp
  clang/test/Preprocessor/riscv-target-features.c

Index: clang/test/Preprocessor/riscv-target-features.c
===
--- clang/test/Preprocessor/riscv-target-features.c
+++ clang/test/Preprocessor/riscv-target-features.c
@@ -18,6 +18,7 @@
 // RUN: %clang -target riscv64-unknown-linux-gnu -march=rv64im -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-M-EXT %s
 // CHECK-M-EXT: __riscv_div 1
+// CHECK-M-EXT: __riscv_m 2000
 // CHECK-M-EXT: __riscv_mul 1
 // CHECK-M-EXT: __riscv_muldiv 1
 
@@ -25,12 +26,14 @@
 // RUN: -o - | FileCheck --check-prefix=CHECK-A-EXT %s
 // RUN: %clang -target riscv64-unknown-linux-gnu -march=rv64ia -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-A-EXT %s
+// CHECK-A-EXT: __riscv_a 2000
 // CHECK-A-EXT: __riscv_atomic 1
 
 // RUN: %clang -target riscv32-unknown-linux-gnu -march=rv32if -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-F-EXT %s
 // RUN: %clang -target riscv64-unknown-linux-gnu -march=rv64if -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-F-EXT %s
+// CHECK-F-EXT: __riscv_f 2000
 // CHECK-F-EXT: __riscv_fdiv 1
 // CHECK-F-EXT: __riscv_flen 32
 // CHECK-F-EXT: __riscv_fsqrt 1
@@ -39,6 +42,7 @@
 // RUN: -o - | FileCheck --check-prefix=CHECK-D-EXT %s
 // RUN: %clang -target riscv64-unknown-linux-gnu -march=rv64ifd -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-D-EXT %s
+// CHECK-D-EXT: __riscv_d 2000
 // CHECK-D-EXT: __riscv_fdiv 1
 // CHECK-D-EXT: __riscv_flen 64
 // CHECK-D-EXT: __riscv_fsqrt 1
@@ -47,12 +51,14 @@
 // RUN: -o - | FileCheck --check-prefix=CHECK-C-EXT %s
 // RUN: %clang -target riscv64-unknown-linux-gnu -march=rv64ic -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-C-EXT %s
+// CHECK-C-EXT: __riscv_c 2000
 // CHECK-C-EXT: __riscv_compressed 1
 
 // RUN: %clang -target riscv32-unknown-linux-gnu -menable-experimental-extensions -march=rv32ib0p92 -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-B-EXT %s
 // RUN: %clang -target riscv64-unknown-linux-gnu -menable-experimental-extensions -march=rv64ib0p92 -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-B-EXT %s
+// CHECK-B-EXT: __riscv_b 92000
 // CHECK-B-EXT: __riscv_bitmanip 1
 
 // RUN: %clang -target riscv32-unknown-linux-gnu -march=rv32ifd -mabi=ilp32 -x c -E -dM %s \
@@ -85,10 +91,11 @@
 // RUN: %clang -target riscv64-unknown-linux-gnu -menable-experimental-extensions \
 // RUN:   -march=rv64iv0p9 -x c -E -dM %s \
 // RUN:   -o - | FileCheck --check-prefix=CHECK-V-EXT %s
+// CHECK-V-EXT: __riscv_v 9000
 // CHECK-V-EXT: __riscv_vector 1
 //
 // RUN: %clang -target riscv32-unknown-linux-gnu -menable-experimental-extensions -march=rv32izfh0p1 -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-ZFH-EXT %s
 // RUN: %clang -target riscv64-unknown-linux-gnu -menable-experimental-extensions -march=rv64izfh0p1 -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-ZFH-EXT %s
-// CHECK-ZFH-EXT: __riscv_zfh 1
+// CHECK-ZFH-EXT: __riscv_zfh 1000
Index: clang/lib/Basic/Targets/RISCV.cpp
===
--- clang/lib/Basic/Targets/RISCV.cpp
+++ clang/lib/Basic/Targets/RISCV.cpp
@@ -109,13 +109,18 @@
   if (ABIName == "ilp32e")
 Builder.defineMacro("__riscv_abi_rve");
 
+  Builder.defineMacro("__riscv_arch_test");
+  Builder.defineMacro("__riscv_i", "2000");
+
   if (HasM) {
+Builder.defineMacro("__riscv_m", "2000");
 Builder.defineMacro("__riscv_mul");
 Builder.defineMacro("__riscv_div");
 Builder.defineMacro("__riscv_muldiv");
   }
 
   if (HasA) {
+Builder.defineMacro("__riscv_a", "2000");
 Builder.defineMacro("__riscv_atomic");
 Builder.defineMacro("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_1");
 Builder.defineMacro("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_2");
@@ -125,22 +130,32 @@
   }
 
   if (HasF || HasD) {
+Builder.defineMacro("__riscv_f", "2000");
 Builder.defineMacro("__riscv_flen", HasD ? "64"

[PATCH] D94237: [clang] Use SourceLocations in unions [NFCI]

2021-01-11 Thread Mikhail Maltsev via Phabricator via cfe-commits
miyuki updated this revision to Diff 315759.
miyuki added a comment.

Fixed a typo in the word "implicit"


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94237

Files:
  clang/include/clang/AST/DependentDiagnostic.h
  clang/include/clang/AST/Expr.h
  clang/include/clang/AST/TemplateBase.h
  clang/include/clang/Sema/DeclSpec.h
  clang/include/clang/Sema/Designator.h
  clang/include/clang/Sema/Initialization.h
  clang/lib/AST/Expr.cpp
  clang/lib/AST/TemplateBase.cpp
  clang/lib/Parse/ParseDeclCXX.cpp
  clang/lib/Sema/DeclSpec.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaType.cpp

Index: clang/lib/Sema/SemaType.cpp
===
--- clang/lib/Sema/SemaType.cpp
+++ clang/lib/Sema/SemaType.cpp
@@ -3125,11 +3125,11 @@
   diag::warn_qual_return_type,
   PTI.TypeQuals,
   SourceLocation(),
-  SourceLocation::getFromRawEncoding(PTI.ConstQualLoc),
-  SourceLocation::getFromRawEncoding(PTI.VolatileQualLoc),
-  SourceLocation::getFromRawEncoding(PTI.RestrictQualLoc),
-  SourceLocation::getFromRawEncoding(PTI.AtomicQualLoc),
-  SourceLocation::getFromRawEncoding(PTI.UnalignedQualLoc));
+  PTI.ConstQualLoc,
+  PTI.VolatileQualLoc,
+  PTI.RestrictQualLoc,
+  PTI.AtomicQualLoc,
+  PTI.UnalignedQualLoc);
   return;
 }
 
@@ -6086,7 +6086,7 @@
   }
 
   // Finally fill in MemberPointerLocInfo fields.
-  TL.setStarLoc(SourceLocation::getFromRawEncoding(Chunk.Mem.StarLoc));
+  TL.setStarLoc(Chunk.Mem.StarLoc);
   TL.setClassTInfo(ClsTInfo);
 }
 void VisitLValueReferenceTypeLoc(LValueReferenceTypeLoc TL) {
@@ -6163,7 +6163,7 @@
 llvm_unreachable("cannot be _Atomic qualified");
 
   case DeclaratorChunk::Pointer:
-Loc = SourceLocation::getFromRawEncoding(Chunk.Ptr.AtomicQualLoc);
+Loc = Chunk.Ptr.AtomicQualLoc;
 break;
 
   case DeclaratorChunk::BlockPointer:
Index: clang/lib/Sema/SemaExpr.cpp
===
--- clang/lib/Sema/SemaExpr.cpp
+++ clang/lib/Sema/SemaExpr.cpp
@@ -2851,8 +2851,7 @@
   // turn this into Self->ivar, just return a BareIVarExpr or something.
   IdentifierInfo &II = Context.Idents.get("self");
   UnqualifiedId SelfName;
-  SelfName.setIdentifier(&II, SourceLocation());
-  SelfName.setKind(UnqualifiedIdKind::IK_ImplicitSelfParam);
+  SelfName.setImplicitSelfParam(&II);
   CXXScopeSpec SelfScopeSpec;
   SourceLocation TemplateKWLoc;
   ExprResult SelfExpr =
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -5340,8 +5340,8 @@
   case UnqualifiedIdKind::IK_OperatorFunctionId:
 NameInfo.setName(Context.DeclarationNames.getCXXOperatorName(
Name.OperatorFunctionId.Operator));
-NameInfo.getInfo().CXXOperatorName.BeginOpNameLoc
-  = Name.OperatorFunctionId.SymbolLocations[0];
+NameInfo.getInfo().CXXOperatorName.BeginOpNameLoc =
+Name.OperatorFunctionId.SymbolLocations[0].getRawEncoding();
 NameInfo.getInfo().CXXOperatorName.EndOpNameLoc
   = Name.EndLocation.getRawEncoding();
 return NameInfo;
Index: clang/lib/Sema/DeclSpec.cpp
===
--- clang/lib/Sema/DeclSpec.cpp
+++ clang/lib/Sema/DeclSpec.cpp
@@ -191,28 +191,29 @@
   I.Kind= Function;
   I.Loc = LocalRangeBegin;
   I.EndLoc  = LocalRangeEnd;
+  new (&I.Fun) FunctionTypeInfo;
   I.Fun.hasPrototype= hasProto;
   I.Fun.isVariadic  = EllipsisLoc.isValid();
   I.Fun.isAmbiguous = isAmbiguous;
-  I.Fun.LParenLoc   = LParenLoc.getRawEncoding();
-  I.Fun.EllipsisLoc = EllipsisLoc.getRawEncoding();
-  I.Fun.RParenLoc   = RParenLoc.getRawEncoding();
+  I.Fun.LParenLoc   = LParenLoc;
+  I.Fun.EllipsisLoc = EllipsisLoc;
+  I.Fun.RParenLoc   = RParenLoc;
   I.Fun.DeleteParams= false;
   I.Fun.NumParams   = NumParams;
   I.Fun.Params  = nullptr;
   I.Fun.RefQualifierIsLValueRef = RefQualifierIsLvalueRef;
-  I.Fun.RefQualifierLoc = RefQualifierLoc.getRawEncoding();
-  I.Fun.MutableLoc  = MutableLoc.getRawEncoding();
+  I.Fun.RefQualifierLoc = RefQualifierLoc;
+  I.Fun.MutableLoc  = MutableLoc;
   I.Fun.ExceptionSpecType   = ESpecType;
-  I.Fun.ExceptionSpecLocBeg = ESpecRange.getBegin().getRawEncoding();
-  I.Fun.ExceptionSpecLocEnd = ESpecRange.getEnd().getRawEncoding();
+  I.Fun.ExceptionSpecLocBeg = ESpecRange.getBegin();
+  I.Fun.ExceptionSpecLocEnd = ESpecRange.

[PATCH] D94374: [CMake] Remove dead code setting policies to NEW

2021-01-11 Thread Raul Tambre via Phabricator via cfe-commits
tambre added a reviewer: ldionne.
tambre added a comment.

ldionne: for libc++ review


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94374

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


[PATCH] D94374: [CMake] Remove dead code setting policies to NEW

2021-01-11 Thread Petr Hosek via Phabricator via cfe-commits
phosek accepted this revision.
phosek added a comment.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94374

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


[PATCH] D94374: [CMake] Remove dead code setting policies to NEW

2021-01-11 Thread Jonas Devlieghere via Phabricator via cfe-commits
JDevlieghere added a comment.

LGTM for LLDB


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94374

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


[PATCH] D94374: [CMake] Remove dead code setting policies to NEW

2021-01-11 Thread Raul Tambre via Phabricator via cfe-commits
tambre created this revision.
tambre added a reviewer: phosek.
Herald added subscribers: libcxx-commits, teijeong, rdzhabarov, tatianashp, 
msifontes, jurahul, Kayjukh, grosul1, Joonsoo, liufengdb, aartbik, lucyrfox, 
mgester, arpith-jacob, antiagainst, shauheen, rriddle, mehdi_amini, lebedev.ri, 
arichardson, mgorny.
Herald added a reviewer: lebedev.ri.
Herald added a project: libunwind.
Herald added a reviewer: libunwind.
tambre requested review of this revision.
Herald added subscribers: llvm-commits, lldb-commits, Sanitizers, cfe-commits, 
stephenneuendorffer, nicolasvasilache.
Herald added projects: clang, Sanitizers, LLDB, libc++, libc++abi, MLIR, LLVM.
Herald added a reviewer: libc++.
Herald added a reviewer: libc++abi.

cmake_minimum_required(VERSION) calls cmake_policy(VERSION),
which sets all policies up to VERSION to NEW.
LLVM started requiring CMake 3.13 last year, so we can remove
a bunch of code setting policies prior to 3.13 to NEW as it
no longer has any effect.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D94374

Files:
  clang/CMakeLists.txt
  compiler-rt/CMakeLists.txt
  flang/CMakeLists.txt
  libcxx/CMakeLists.txt
  libcxx/utils/ci/runtimes/CMakeLists.txt
  libcxx/utils/google-benchmark/CMakeLists.txt
  libcxxabi/CMakeLists.txt
  libunwind/CMakeLists.txt
  lldb/CMakeLists.txt
  llvm/CMakeLists.txt
  llvm/utils/benchmark/CMakeLists.txt
  mlir/examples/standalone/CMakeLists.txt

Index: mlir/examples/standalone/CMakeLists.txt
===
--- mlir/examples/standalone/CMakeLists.txt
+++ mlir/examples/standalone/CMakeLists.txt
@@ -1,20 +1,8 @@
 cmake_minimum_required(VERSION 3.13.4)
-
-if(POLICY CMP0068)
-  cmake_policy(SET CMP0068 NEW)
-  set(CMAKE_BUILD_WITH_INSTALL_NAME_DIR ON)
-endif()
-
-if(POLICY CMP0075)
-  cmake_policy(SET CMP0075 NEW)
-endif()
-
-if(POLICY CMP0077)
-  cmake_policy(SET CMP0077 NEW)
-endif()
-
 project(standalone-dialect LANGUAGES CXX C)
 
+set(CMAKE_BUILD_WITH_INSTALL_NAME_DIR ON)
+
 set(CMAKE_CXX_STANDARD 14 CACHE STRING "C++ standard to conform to")
 
 find_package(MLIR REQUIRED CONFIG)
Index: llvm/utils/benchmark/CMakeLists.txt
===
--- llvm/utils/benchmark/CMakeLists.txt
+++ llvm/utils/benchmark/CMakeLists.txt
@@ -1,22 +1,5 @@
 cmake_minimum_required(VERSION 3.13.4)
-
-# Tell cmake 3.0+ that it's safe to clear the PROJECT_VERSION variable in the
-# call to project() below.
-if(POLICY CMP0048)
-  cmake_policy(SET CMP0048 NEW)
-endif()
-
-project (benchmark)
-
-foreach(p
-CMP0054 # CMake 3.1
-CMP0056 # export EXE_LINKER_FLAGS to try_run
-CMP0057 # Support no if() IN_LIST operator
-)
-  if(POLICY ${p})
-cmake_policy(SET ${p} NEW)
-  endif()
-endforeach()
+project(benchmark)
 
 option(BENCHMARK_ENABLE_TESTING "Enable testing of the benchmark library." ON)
 option(BENCHMARK_ENABLE_EXCEPTIONS "Enable the use of exceptions in the benchmark library." ON)
Index: llvm/CMakeLists.txt
===
--- llvm/CMakeLists.txt
+++ llvm/CMakeLists.txt
@@ -2,18 +2,7 @@
 
 cmake_minimum_required(VERSION 3.13.4)
 
-if(POLICY CMP0068)
-  cmake_policy(SET CMP0068 NEW)
-  set(CMAKE_BUILD_WITH_INSTALL_NAME_DIR ON)
-endif()
-
-if(POLICY CMP0075)
-  cmake_policy(SET CMP0075 NEW)
-endif()
-
-if(POLICY CMP0077)
-  cmake_policy(SET CMP0077 NEW)
-endif()
+set(CMAKE_BUILD_WITH_INSTALL_NAME_DIR ON)
 
 if(NOT DEFINED LLVM_VERSION_MAJOR)
   set(LLVM_VERSION_MAJOR 12)
Index: lldb/CMakeLists.txt
===
--- lldb/CMakeLists.txt
+++ lldb/CMakeLists.txt
@@ -1,13 +1,5 @@
 cmake_minimum_required(VERSION 3.13.4)
 
-if(POLICY CMP0075)
-  cmake_policy(SET CMP0075 NEW)
-endif()
-
-if(POLICY CMP0077)
-  cmake_policy(SET CMP0077 NEW)
-endif()
-
 # Add path for custom modules.
 set(CMAKE_MODULE_PATH
   ${CMAKE_MODULE_PATH}
Index: libunwind/CMakeLists.txt
===
--- libunwind/CMakeLists.txt
+++ libunwind/CMakeLists.txt
@@ -8,10 +8,6 @@
 
 cmake_minimum_required(VERSION 3.13.4)
 
-if (POLICY CMP0042)
-  cmake_policy(SET CMP0042 NEW) # Set MACOSX_RPATH=YES by default
-endif()
-
 # Add path for custom modules
 set(CMAKE_MODULE_PATH
   "${CMAKE_CURRENT_SOURCE_DIR}/cmake"
Index: libcxxabi/CMakeLists.txt
===
--- libcxxabi/CMakeLists.txt
+++ libcxxabi/CMakeLists.txt
@@ -10,10 +10,6 @@
 
 cmake_minimum_required(VERSION 3.13.4)
 
-if(POLICY CMP0042)
-  cmake_policy(SET CMP0042 NEW) # Set MACOSX_RPATH=YES by default
-endif()
-
 # Add path for custom modules
 set(CMAKE_MODULE_PATH
   "${CMAKE_CURRENT_SOURCE_DIR}/cmake"
Index: libcxx/utils/google-benchmark/CMakeLists.txt
===
--- libcxx/utils/google-benchmark/CMakeLists.txt
+++ libcxx/utils/google-benchmark/CMakeLists.txt

[PATCH] D94290: [clang][AArch64][SVE] Avoid going through memory for coerced VLST return values

2021-01-11 Thread Joe Ellis via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG8ea72b388734: [clang][AArch64][SVE] Avoid going through 
memory for coerced VLST return values (authored by joechrisellis).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94290

Files:
  clang/lib/CodeGen/CGCall.cpp
  clang/test/CodeGen/aarch64-sve-acle-__ARM_FEATURE_SVE_VECTOR_OPERATORS.cpp
  clang/test/CodeGen/attr-arm-sve-vector-bits-call.c
  clang/test/CodeGen/attr-arm-sve-vector-bits-cast.c
  clang/test/CodeGen/attr-arm-sve-vector-bits-codegen.c

Index: clang/test/CodeGen/attr-arm-sve-vector-bits-codegen.c
===
--- clang/test/CodeGen/attr-arm-sve-vector-bits-codegen.c
+++ clang/test/CodeGen/attr-arm-sve-vector-bits-codegen.c
@@ -17,7 +17,6 @@
 // CHECK-NEXT:[[PRED_ADDR:%.*]] = alloca , align 2
 // CHECK-NEXT:[[VEC_ADDR:%.*]] = alloca , align 16
 // CHECK-NEXT:[[PG:%.*]] = alloca , align 2
-// CHECK-NEXT:[[RETVAL_COERCE:%.*]] = alloca , align 16
 // CHECK-NEXT:store  [[PRED:%.*]], * [[PRED_ADDR]], align 2
 // CHECK-NEXT:store  [[VEC:%.*]], * [[VEC_ADDR]], align 16
 // CHECK-NEXT:[[TMP0:%.*]] = load , * [[PRED_ADDR]], align 2
@@ -35,11 +34,9 @@
 // CHECK-NEXT:[[TMP10:%.*]] = call  @llvm.aarch64.sve.add.nxv4i32( [[TMP9]],  [[CASTSCALABLESVE]],  [[TMP8]])
 // CHECK-NEXT:[[CASTFIXEDSVE:%.*]] = call <16 x i32> @llvm.experimental.vector.extract.v16i32.nxv4i32( [[TMP10]], i64 0)
 // CHECK-NEXT:store <16 x i32> [[CASTFIXEDSVE]], <16 x i32>* [[RETVAL]], align 16
-// CHECK-NEXT:[[TMP11:%.*]] = bitcast * [[RETVAL_COERCE]] to i8*
-// CHECK-NEXT:[[TMP12:%.*]] = bitcast <16 x i32>* [[RETVAL]] to i8*
-// CHECK-NEXT:call void @llvm.memcpy.p0i8.p0i8.i64(i8* align 16 [[TMP11]], i8* align 16 [[TMP12]], i64 64, i1 false)
-// CHECK-NEXT:[[TMP13:%.*]] = load , * [[RETVAL_COERCE]], align 16
-// CHECK-NEXT:ret  [[TMP13]]
+// CHECK-NEXT:[[TMP11:%.*]] = load <16 x i32>, <16 x i32>* [[RETVAL]], align 16
+// CHECK-NEXT:[[CASTSCALABLESVE1:%.*]] = call  @llvm.experimental.vector.insert.nxv4i32.v16i32( undef, <16 x i32> [[TMP11]], i64 0)
+// CHECK-NEXT:ret  [[CASTSCALABLESVE1]]
 //
 fixed_int32_t foo(svbool_t pred, svint32_t vec) {
   svbool_t pg = svand_z(pred, global_pred, global_pred);
@@ -50,16 +47,13 @@
 // CHECK-NEXT:  entry:
 // CHECK-NEXT:[[RETVAL:%.*]] = alloca <16 x i32>, align 16
 // CHECK-NEXT:[[GLOBAL_VEC_PTR:%.*]] = alloca <16 x i32>*, align 8
-// CHECK-NEXT:[[RETVAL_COERCE:%.*]] = alloca , align 16
 // CHECK-NEXT:store <16 x i32>* @global_vec, <16 x i32>** [[GLOBAL_VEC_PTR]], align 8
 // CHECK-NEXT:[[TMP0:%.*]] = load <16 x i32>*, <16 x i32>** [[GLOBAL_VEC_PTR]], align 8
 // CHECK-NEXT:[[TMP1:%.*]] = load <16 x i32>, <16 x i32>* [[TMP0]], align 16
 // CHECK-NEXT:store <16 x i32> [[TMP1]], <16 x i32>* [[RETVAL]], align 16
-// CHECK-NEXT:[[TMP2:%.*]] = bitcast * [[RETVAL_COERCE]] to i8*
-// CHECK-NEXT:[[TMP3:%.*]] = bitcast <16 x i32>* [[RETVAL]] to i8*
-// CHECK-NEXT:call void @llvm.memcpy.p0i8.p0i8.i64(i8* align 16 [[TMP2]], i8* align 16 [[TMP3]], i64 64, i1 false)
-// CHECK-NEXT:[[TMP4:%.*]] = load , * [[RETVAL_COERCE]], align 16
-// CHECK-NEXT:ret  [[TMP4]]
+// CHECK-NEXT:[[TMP2:%.*]] = load <16 x i32>, <16 x i32>* [[RETVAL]], align 16
+// CHECK-NEXT:[[CASTSCALABLESVE:%.*]] = call  @llvm.experimental.vector.insert.nxv4i32.v16i32( undef, <16 x i32> [[TMP2]], i64 0)
+// CHECK-NEXT:ret  [[CASTSCALABLESVE]]
 //
 fixed_int32_t test_ptr_to_global() {
   fixed_int32_t *global_vec_ptr;
@@ -73,17 +67,14 @@
 // CHECK-NEXT:  entry:
 // CHECK-NEXT:[[RETVAL:%.*]] = alloca <16 x i32>, align 16
 // CHECK-NEXT:[[ARR_ADDR:%.*]] = alloca <16 x i32>*, align 8
-// CHECK-NEXT:[[RETVAL_COERCE:%.*]] = alloca , align 16
 // CHECK-NEXT:store <16 x i32>* [[ARR:%.*]], <16 x i32>** [[ARR_ADDR]], align 8
 // CHECK-NEXT:[[TMP0:%.*]] = load <16 x i32>*, <16 x i32>** [[ARR_ADDR]], align 8
 // CHECK-NEXT:[[ARRAYIDX:%.*]] = getelementptr inbounds <16 x i32>, <16 x i32>* [[TMP0]], i64 0
 // CHECK-NEXT:[[TMP1:%.*]] = load <16 x i32>, <16 x i32>* [[ARRAYIDX]], align 16
 // CHECK-NEXT:store <16 x i32> [[TMP1]], <16 x i32>* [[RETVAL]], align 16
-// CHECK-NEXT:[[TMP2:%.*]] = bitcast * [[RETVAL_COERCE]] to i8*
-// CHECK-NEXT:[[TMP3:%.*]] = bitcast <16 x i32>* [[RETVAL]] to i8*
-// CHECK-NEXT:call void @llvm.memcpy.p0i8.p0i8.i64(i8* align 16 [[TMP2]], i8* align 16 [[TMP3]], i64 64, i1 false)
-// CHECK-NEXT:[[TMP4:%.*]] = load , * [[RETVAL_COERCE]], align 16
-// CHECK-NEXT:ret  [[TMP4]]
+// CHECK-NEXT:[[TMP2:%.*]] = load <16 x i32>, <16 x i32>* [[RETVAL]], align 16
+// CHECK-NEXT:[[CASTSCALABLESVE:%.*]] = call  @llvm.experimental.vector.insert.nxv4i32.v16i32( undef, <16 x i32> [[TMP2]], i64 0)
+// CHECK-NEXT:ret  [[CASTSCALABLESV

[clang] 8ea72b3 - [clang][AArch64][SVE] Avoid going through memory for coerced VLST return values

2021-01-11 Thread Joe Ellis via cfe-commits

Author: Joe Ellis
Date: 2021-01-11T12:10:59Z
New Revision: 8ea72b388734ce660f861e0dfbe53d203e94876a

URL: 
https://github.com/llvm/llvm-project/commit/8ea72b388734ce660f861e0dfbe53d203e94876a
DIFF: 
https://github.com/llvm/llvm-project/commit/8ea72b388734ce660f861e0dfbe53d203e94876a.diff

LOG: [clang][AArch64][SVE] Avoid going through memory for coerced VLST return 
values

VLST return values are coerced to VLATs in the function epilog for
consistency with the VLAT ABI. Previously, this coercion was done
through memory. It is preferable to use the
llvm.experimental.vector.insert intrinsic to avoid going through memory
here.

Reviewed By: c-rhodes

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

Added: 


Modified: 
clang/lib/CodeGen/CGCall.cpp
clang/test/CodeGen/aarch64-sve-acle-__ARM_FEATURE_SVE_VECTOR_OPERATORS.cpp
clang/test/CodeGen/attr-arm-sve-vector-bits-call.c
clang/test/CodeGen/attr-arm-sve-vector-bits-cast.c
clang/test/CodeGen/attr-arm-sve-vector-bits-codegen.c

Removed: 




diff  --git a/clang/lib/CodeGen/CGCall.cpp b/clang/lib/CodeGen/CGCall.cpp
index f1987408165b..2cc7203d1194 100644
--- a/clang/lib/CodeGen/CGCall.cpp
+++ b/clang/lib/CodeGen/CGCall.cpp
@@ -1265,6 +1265,21 @@ static llvm::Value *CreateCoercedLoad(Address Src, 
llvm::Type *Ty,
 return CGF.Builder.CreateLoad(Src);
   }
 
+  // If coercing a fixed vector to a scalable vector for ABI compatibility, and
+  // the types match, use the llvm.experimental.vector.insert intrinsic to
+  // perform the conversion.
+  if (auto *ScalableDst = dyn_cast(Ty)) {
+if (auto *FixedSrc = dyn_cast(SrcTy)) {
+  if (ScalableDst->getElementType() == FixedSrc->getElementType()) {
+auto *Load = CGF.Builder.CreateLoad(Src);
+auto *UndefVec = llvm::UndefValue::get(ScalableDst);
+auto *Zero = llvm::Constant::getNullValue(CGF.CGM.Int64Ty);
+return CGF.Builder.CreateInsertVector(ScalableDst, UndefVec, Load, 
Zero,
+  "castScalableSve");
+  }
+}
+  }
+
   // Otherwise do coercion through memory. This is stupid, but simple.
   Address Tmp =
   CreateTempAllocaForCoercion(CGF, Ty, Src.getAlignment(), Src.getName());

diff  --git 
a/clang/test/CodeGen/aarch64-sve-acle-__ARM_FEATURE_SVE_VECTOR_OPERATORS.cpp 
b/clang/test/CodeGen/aarch64-sve-acle-__ARM_FEATURE_SVE_VECTOR_OPERATORS.cpp
index 6fafc2ca2db9..a808d50884ea 100644
--- a/clang/test/CodeGen/aarch64-sve-acle-__ARM_FEATURE_SVE_VECTOR_OPERATORS.cpp
+++ b/clang/test/CodeGen/aarch64-sve-acle-__ARM_FEATURE_SVE_VECTOR_OPERATORS.cpp
@@ -48,14 +48,11 @@ void test02() {
 // CHECK-SAME:[[#VBITS]]
 // CHECK-SAME:EES_( %x.coerce,  
%y.coerce)
 // CHECK-NEXT: entry:
-// CHECK-NEXT:   [[RETVAL_COERCE:%.*]] = alloca , align 16
 // CHECK-NEXT:   [[X:%.*]] = call <[[#div(VBITS, 32)]] x i32> 
@llvm.experimental.vector.extract.v[[#div(VBITS, 32)]]i32.nxv4i32( [[X_COERCE:%.*]], i64 0)
 // CHECK-NEXT:   [[Y:%.*]] = call <[[#div(VBITS, 32)]] x i32> 
@llvm.experimental.vector.extract.v[[#div(VBITS, 32)]]i32.nxv4i32( [[X_COERCE1:%.*]], i64 0)
 // CHECK-NEXT:   [[ADD:%.*]] = add <[[#div(VBITS, 32)]] x i32> [[Y]], [[X]]
-// CHECK-NEXT:   [[RETVAL_0__SROA_CAST:%.*]] = bitcast * 
[[RETVAL_COERCE]] to <[[#div(VBITS, 32)]] x i32>*
-// CHECK-NEXT:   store <[[#div(VBITS, 32)]] x i32> [[ADD]], <[[#div(VBITS, 
32)]] x i32>* [[RETVAL_0__SROA_CAST]], align 16
-// CHECK-NEXT:   [[TMP0:%.*]] = load , * 
[[RETVAL_COERCE]], align 16
-// CHECK-NEXT:   ret  [[TMP0]]
+// CHECK-NEXT:   [[CASTSCALABLESVE:%.*]] = call  
@llvm.experimental.vector.insert.nxv4i32.v[[#div(VBITS, 32)]]i32( undef, <[[#div(VBITS, 32)]] x i32> [[ADD]], i64 0)
+// CHECK-NEXT:   ret  [[CASTSCALABLESVE]]
 typedef svint32_t vec __attribute__((arm_sve_vector_bits(N)));
 auto f(vec x, vec y) { return x + y; } // Returns a vec.
 #endif

diff  --git a/clang/test/CodeGen/attr-arm-sve-vector-bits-call.c 
b/clang/test/CodeGen/attr-arm-sve-vector-bits-call.c
index f909b7164622..f988d54bacd4 100644
--- a/clang/test/CodeGen/attr-arm-sve-vector-bits-call.c
+++ b/clang/test/CodeGen/attr-arm-sve-vector-bits-call.c
@@ -24,14 +24,11 @@ svint32_t sizeless_callee(svint32_t x) {
 
 // CHECK-LABEL: @fixed_caller(
 // CHECK-NEXT:  entry:
-// CHECK-NEXT:[[RETVAL_COERCE:%.*]] = alloca , align 16
 // CHECK-NEXT:[[X:%.*]] = call <16 x i32> 
@llvm.experimental.vector.extract.v16i32.nxv4i32( 
[[X_COERCE:%.*]], i64 0)
 // CHECK-NEXT:[[CASTSCALABLESVE:%.*]] = call  
@llvm.experimental.vector.insert.nxv4i32.v16i32( undef, <16 x 
i32> [[X]], i64 0)
 // CHECK-NEXT:[[CASTFIXEDSVE:%.*]] = call <16 x i32> 
@llvm.experimental.vector.extract.v16i32.nxv4i32( 
[[CASTSCALABLESVE]], i64 0)
-// CHECK-NEXT:[[RETVAL_0__SROA_CAST:%.*]] = bitcast * 
[[RETVAL_COERCE]] to <16 x i32>*
-// CHECK-NEXT:store <16 x i32> [[CASTFIXEDSVE]], <16 x i32>* 
[[RETVAL_0__SROA_CAST]], align 16
-// C

[PATCH] D93401: [flang][driver] Add support for `-D`, `-U`

2021-01-11 Thread Faris via Phabricator via cfe-commits
FarisRehman added inline comments.



Comment at: flang/test/Flang-Driver/driver-help.f90:22
 ! HELP-NEXT: -###   Print (but do not run) the commands to run 
for this compilation
+! HELP-NEXT: -D = Define  to  (or 1 if  
omitted)
 ! HELP-NEXT: -E Only run the preprocessor

sameeranjoshi wrote:
> I see below crash report, when omitting the  but not omitting the `=` 
> symbol.
> Not sure if that's correct way of running hence instead of filing bug 
> reporting here.
> 
> ```
> ./bin/flang-new -E -DX= test.f90
> ```
> 
> ```
> PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash 
> backtrace.
> Stack dump:
> 0.  Program arguments: 
> /home/amd/f18_git/final_test/driver_build/bin/flang-new -fc1 -E -D X= -o - 
> test.f90
>  #0 0x7f26185d0bc1 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) 
> (/home/amd/f18_git/final_test/driver_build/bin/../lib/libLLVMSupport.so.12git+0x1a4bc1)
>  #1 0x7f26185ce9a4 llvm::sys::RunSignalHandlers() 
> (/home/amd/f18_git/final_test/driver_build/bin/../lib/libLLVMSupport.so.12git+0x1a29a4)
>  #2 0x7f26185ceb10 SignalHandler(int) 
> (/home/amd/f18_git/final_test/driver_build/bin/../lib/libLLVMSupport.so.12git+0x1a2b10)
>  #3 0x7f2617749470 (/lib/x86_64-linux-gnu/libc.so.6+0x46470)
>  #4 0x7f2617443498 
> Fortran::parser::OffsetToProvenanceMappings::Map(unsigned long) const 
> (/home/amd/f18_git/final_test/driver_build/bin/../lib/../lib/libFortranParser.so.12git+0x571498)
>  #5 0x7f261744adf2 Fortran::parser::TokenSequence::GetProvenanceRange() 
> const 
> (/home/amd/f18_git/final_test/driver_build/bin/../lib/../lib/libFortranParser.so.12git+0x578df2)
>  #6 0x7f26173dd334 
> Fortran::parser::Preprocessor::MacroReplacement(Fortran::parser::TokenSequence
>  const&, Fortran::parser::Prescanner&) (.localalias) 
> (/home/amd/f18_git/final_test/driver_build/bin/../lib/../lib/libFortranParser.so.12git+0x50b334)
>  #7 0x7f26173e9dc1 Fortran::parser::Prescanner::Statement() (.localalias) 
> (/home/amd/f18_git/final_test/driver_build/bin/../lib/../lib/libFortranParser.so.12git+0x517dc1)
>  #8 0x7f26173ea888 
> Fortran::parser::Prescanner::Prescan(Fortran::common::Interval)
>  (.localalias) 
> (/home/amd/f18_git/final_test/driver_build/bin/../lib/../lib/libFortranParser.so.12git+0x51)
>  #9 0x7f26173d480b 
> Fortran::parser::Parsing::Prescan(std::__cxx11::basic_string std::char_traits, std::allocator > const&, 
> Fortran::parser::Options) 
> (/home/amd/f18_git/final_test/driver_build/bin/../lib/../lib/libFortranParser.so.12git+0x50280b)
> #10 0x7f2618424ddd Fortran::frontend::FrontendAction::Execute() 
> (/home/amd/f18_git/final_test/driver_build/bin/../lib/libflangFrontend.so.12git+0x)
> #11 0x7f261841fa5e 
> Fortran::frontend::CompilerInstance::ExecuteAction(Fortran::frontend::FrontendAction&)
>  
> (/home/amd/f18_git/final_test/driver_build/bin/../lib/libflangFrontend.so.12git+0x8a5e)
> #12 0x7f26184132fc 
> Fortran::frontend::ExecuteCompilerInvocation(Fortran::frontend::CompilerInstance*)
>  
> (/home/amd/f18_git/final_test/driver_build/bin/../lib/libflangFrontendTool.so.12git+0x12fc)
> #13 0x55bad4081c20 fc1_main(llvm::ArrayRef, char const*) 
> (/home/amd/f18_git/final_test/driver_build/bin/flang-new+0x3c20)
> #14 0x55bad4080e59 main 
> (/home/amd/f18_git/final_test/driver_build/bin/flang-new+0x2e59)
> #15 0x7f261772a1e3 __libc_start_main 
> /build/glibc-5mDdLG/glibc-2.30/csu/../csu/libc-start.c:342:3
> #16 0x55bad4080eae _start 
> (/home/amd/f18_git/final_test/driver_build/bin/flang-new+0x2eae)
> flang-new: error: unable to execute command: Segmentation fault (core dumped)
> flang-new: error: flang frontend command failed due to signal (use -v to see 
> invocation)
> flang-new version 12.0.0 (https://github.com/llvm/llvm-project.git 
> 2f9cb090cc6db1be5bf524eb0a32537503b3e786)
> Target: x86_64-unknown-linux-gnu
> Thread model: posix
> InstalledDir: /home/amd/f18_git/final_test/driver_build/bin
> flang-new: note: diagnostic msg: Error generating preprocessed source(s) - no 
> preprocessable inputs.
> 
> ```
> 
Thanks for reporting this!
I was able to reproduce this error running:
  - flang-new -DX= file.f
  - flang-new -E -DX= file.f
  - flang-new -fc1 -E -DX= file.f
  - f18 -E -DX= file.f
However I did not receive an error when running: `flang-new -fc1 -DX= file.f`
I suspect this may be an issue in the frontend and I will look into this 
further.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93401

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


[PATCH] D94224: [clang][AST] Get rid of an alignment hack in DeclObjC.h [NFCI]

2021-01-11 Thread Mikhail Maltsev via Phabricator via cfe-commits
miyuki added inline comments.



Comment at: clang/include/clang/AST/DeclObjC.h:660
+  /// Location of the left and right angle brackets.
+  alignas(ObjCTypeParamDecl *) SourceRange Brackets;
   /// The number of parameters in the list, which are tail-allocated.

aprantl wrote:
> Can you add a comment here explaining why the alignas is needed here? It's 
> not obvious from the context.
Actually, `alignas` is not needed here. I've removed it and updated the commit 
message to explain why.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94224

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


[PATCH] D94382: [clangd] Avoid recursion in TargetFinder::add()

2021-01-11 Thread Sam McCall via Phabricator via cfe-commits
sammccall added a comment.

Doh, I really thought we'd get away without an explicit recursion guard here.
But the example is compelling, so this seems like the right approach. 
Unfortunately, I think we're going to end up needing to add allocations too...




Comment at: clang-tools-extra/clangd/FindTarget.cpp:333
   Decls;
+  const Decl *CurrentlyProcessing = nullptr;
   RelSet Flags;

I don't think a single pointer is going to cut it here - can't we construct a 
mutually-recursive example so that the "wrong" decl is on always on top of the 
stack and we never bail out?

We probably want a `SmallDenseMap Seen` or something? (And then we no longer 
need to look up in the actual result set).

Couple of related refinements:
 - Currently when we reach the same node via multiple flag paths, we take the 
union of the flags. (I'm not sure this is *great* behavior, but the API is 
pretty limiting). To be consistent with that here, we should store the flags 
for `seen` too, and union them when updating, and only bail out if we added no 
new flags. (This will almost never matter in practice, but it'd be nice not to 
worry)
 - You could consider making the key type `void*` instead of `decl*` and also 
break loops with no decls in them. But this can certainly wait until we find 
such a loop!



Comment at: clang-tools-extra/clangd/FindTarget.cpp:333
   Decls;
+  const Decl *CurrentlyProcessing = nullptr;
   RelSet Flags;

nridge wrote:
> njames93 wrote:
> > Whats the purpose in tracking this? Is the Decls lookup not enough?
> No, because the possibly-recursive call is 
> [here](https://searchfox.org/llvm/rev/9f2d9364b04c4d9651b1ec8612a3968b969fe71d/clang-tools-extra/clangd/FindTarget.cpp#366),
>  but we only insert into `Decls` 
> [here](https://searchfox.org/llvm/rev/9f2d9364b04c4d9651b1ec8612a3968b969fe71d/clang-tools-extra/clangd/FindTarget.cpp#417).
> No, because the possibly-recursive call is here, but we only insert into 
> Decls here.

This is just for implementation convenience, we could reverse the order by 
rearranging the code somehow. However this seems fragile to me - I'm thinking 
about the cases where we reassign D in the function of the body here, and so 
end up reporting some other declaration instead (which may not be in the cycle).
So I think I like the solution in this patch better.



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94382

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


  1   2   >