[PATCH] D97915: [Coroutines] Handle overaligned frame allocation

[Yuanfang Chen via Phabricator via cfe-commits]

ychen updated this revision to Diff 345053.
ychen marked an inline comment as done.
ychen added a comment.

- Address feedbacks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97915

Files:
  clang/include/clang/AST/StmtCXX.h
  clang/lib/AST/StmtCXX.cpp
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/CodeGen/CGCoroutine.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/lib/Sema/SemaCoroutine.cpp
  clang/lib/Sema/TreeTransform.h
  clang/test/CodeGenCoroutines/coro-alloc.cpp
  clang/test/CodeGenCoroutines/coro-cleanup.cpp
  clang/test/CodeGenCoroutines/coro-gro.cpp

Index: clang/test/CodeGenCoroutines/coro-gro.cpp
===
--- clang/test/CodeGenCoroutines/coro-gro.cpp
+++ clang/test/CodeGenCoroutines/coro-gro.cpp
@@ -68,6 +68,7 @@
   // CHECK: call void @_ZNSt12experimental16coroutine_traitsIJiEE12promise_typeD1Ev(
   // CHECK: %[[Mem:.+]] = call i8* @llvm.coro.free(
   // CHECK: call void @_ZdlPv(i8* %[[Mem]])
+  // CHECK: call void @_ZdlPv(i8* %{{.*}})
 
   // Initialize retval from Gro and destroy Gro
 
Index: clang/test/CodeGenCoroutines/coro-cleanup.cpp
===
--- clang/test/CodeGenCoroutines/coro-cleanup.cpp
+++ clang/test/CodeGenCoroutines/coro-cleanup.cpp
@@ -78,12 +78,46 @@
 
   // CHECK: [[Cleanup]]:
   // CHECK: call void @_ZNSt12experimental16coroutine_traitsIJvEE12promise_typeD1Ev(
-  // CHECK: %[[Mem0:.+]] = call i8* @llvm.coro.free(
-  // CHECK: call void @_ZdlPv(i8* %[[Mem0]]
+  // CHECK: %[[MEM0:.+]] = call i8* @llvm.coro.free(
+  // CHECK: br i1 %{{.*}}, label %[[CheckAlignBB:.+]], label %[[Afterwards:.+]]
+
+  // CHECK: [[CheckAlignBB]]:
+  // CHECK: %[[ALIGN:.+]] = call i64 @llvm.coro.align.i64()
+  // CHECK: %[[CMP:.+]] = icmp ugt i64 %[[ALIGN]],
+  // CHECK: br i1 %[[CMP]], label %[[AlignedFreeBB:.+]], label %[[FreeBB:.+]]
+
+  // CHECK: [[FreeBB]]:
+  // CHECK: call void @_ZdlPv(i8* %[[MEM0]]
+  // CHECK: br label %[[Afterwards]]
+
+  // CHECK: [[AlignedFreeBB]]:
+  // CHECK-NEXT: %[[OFFSET:.+]] = call i32 @llvm.coro.raw.frame.ptr.offset.i32()
+  // CHECK-NEXT: %[[ADDR:.+]] = getelementptr inbounds i8, i8* %[[MEM0]], i32 %[[OFFSET]]
+  // CHECK-NEXT: %[[ADDR2:.+]] = bitcast i8* %[[ADDR]] to i8**
+  // CHECK-NEXT: %[[MEM:.+]] = load i8*, i8** %[[ADDR2]], align 8
+  // CHECK-NEXT: call void @_ZdlPv(i8* %[[MEM]])
+  // CHECK-NEXT: br label %[[Afterwards]]
 
   // CHECK: [[Dealloc]]:
-  // CHECK:   %[[Mem:.+]] = call i8* @llvm.coro.free(
-  // CHECK:   call void @_ZdlPv(i8* %[[Mem]])
+  // CHECK: %[[MEM0:.+]] = call i8* @llvm.coro.free(
+  // CHECK: br i1 %{{.*}}, label %[[CheckAlignBB:.+]], label %[[Afterwards:.+]]
+
+  // CHECK: [[CheckAlignBB]]:
+  // CHECK: %[[ALIGN:.+]] = call i64 @llvm.coro.align.i64()
+  // CHECK: %[[CMP:.+]] = icmp ugt i64 %[[ALIGN]],
+  // CHECK: br i1 %[[CMP]], label %[[AlignedFreeBB:.+]], label %[[FreeBB:.+]]
+
+  // CHECK: [[FreeBB]]:
+  // CHECK: call void @_ZdlPv(i8* %[[MEM0]]
+  // CHECK: br label %[[Afterwards]]
+
+  // CHECK: [[AlignedFreeBB]]:
+  // CHECK-NEXT: %[[OFFSET:.+]] = call i32 @llvm.coro.raw.frame.ptr.offset.i32()
+  // CHECK-NEXT: %[[ADDR:.+]] = getelementptr inbounds i8, i8* %[[MEM0]], i32 %[[OFFSET]]
+  // CHECK-NEXT: %[[ADDR2:.+]] = bitcast i8* %[[ADDR]] to i8**
+  // CHECK-NEXT: %[[MEM:.+]] = load i8*, i8** %[[ADDR2]], align 8
+  // CHECK-NEXT: call void @_ZdlPv(i8* %[[MEM]])
+  // CHECK-NEXT: br label %[[Afterwards]]
 
   co_return;
 }
Index: clang/test/CodeGenCoroutines/coro-alloc.cpp
===
--- clang/test/CodeGenCoroutines/coro-alloc.cpp
+++ clang/test/CodeGenCoroutines/coro-alloc.cpp
@@ -57,24 +57,55 @@
 extern "C" void f0(global_new_delete_tag) {
   // CHECK: %[[ID:.+]] = call token @llvm.coro.id(i32 16
   // CHECK: %[[NeedAlloc:.+]] = call i1 @llvm.coro.alloc(token %[[ID]])
-  // CHECK: br i1 %[[NeedAlloc]], label %[[AllocBB:.+]], label %[[InitBB:.+]]
+  // CHECK: br i1 %[[NeedAlloc]], label %[[CheckAlignBB:.+]], label %[[InitBB:.+]]
+
+  // CHECK: [[CheckAlignBB]]:
+  // CHECK: %[[ALIGN:.+]] = call i64 @llvm.coro.align.i64()
+  // CHECK: %[[CMP:.+]] = icmp ugt i64 %[[ALIGN]], 16
+  // CHECK: br i1 %[[CMP]], label %[[AlignAllocBB:.+]], label %[[AllocBB:.+]]
 
   // CHECK: [[AllocBB]]:
+  // CHECK-NEXT: %[[SIZE:.+]] = call i64 @llvm.coro.size.i64()
+  // CHECK-NEXT: %[[MEM:.+]] = call noalias nonnull i8* @_Znwm(i64 %[[SIZE]])
+  // CHECK-NEXT: br label %[[InitBB:.+]]
+
+  // CHECK: [[AlignAllocBB]]:
   // CHECK: %[[SIZE:.+]] = call i64 @llvm.coro.size.i64()
-  // CHECK: %[[MEM:.+]] = call noalias nonnull i8* @_Znwm(i64 %[[SIZE]])
+  // CHECK: %[[ALIGN:.+]] = call i64 @llvm.coro.align.i64()
+  // CHECK: %[[PAD:.+]] = sub nsw i64 %[[ALIGN]], 16
+  // CHECK: %[[NEWSIZE:.+]] = add i64 %[[SIZE]], %[[PAD]]
+  // CHECK: %[[MEM2:.+]] = call noalias nonnull i8* @_Znwm(i64 

[PATCH] D97915: [Coroutines] Handle overaligned frame allocation

[Yuanfang Chen via Phabricator via cfe-commits]

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



Comment at: clang/include/clang/AST/StmtCXX.h:356-359
 Expr *Allocate = nullptr;
 Expr *Deallocate = nullptr;
+Expr *AlignedAllocate = nullptr;
+Expr *AlignedDeallocate = nullptr;

ChuanqiXu wrote:
> Can't we merge these?
I'm not sure about the "merge" here. Could you be more explicit?



Comment at: clang/lib/CodeGen/CGCoroutine.cpp:445-483
+void emitDynamicAlignedDealloc(CodeGenFunction ,
+   llvm::BasicBlock *AlignedFreeBB,
+   llvm::CallInst *CoroFree) {
+  llvm::CallInst *Dealloc = nullptr;
+  for (llvm::User *U : CoroFree->users()) {
+if (auto *CI = dyn_cast(U))
+  if (CI->getParent() == CGF.Builder.GetInsertBlock())

ChuanqiXu wrote:
> This code would only work if we use `::operator new(size_t, align_val_t)`, 
> which is implemented in another patch. I would suggest to move this into that 
> one.
It handles both aligned and normal new/delete.



Comment at: clang/lib/CodeGen/CGCoroutine.cpp:528-547
 CGF.EmitBlock(FreeBB);
 CGF.EmitStmt(Deallocate);
-
-auto *AfterFreeBB = CGF.createBasicBlock("after.coro.free");
-CGF.EmitBlock(AfterFreeBB);
+CGF.Builder.CreateBr(AfterFreeBB);
 
 // We should have captured coro.free from the emission of deallocate.
 auto *CoroFree = CGF.CurCoro.Data->LastCoroFree;
+CGF.CurCoro.Data->LastCoroFreeUsedForDealloc = true;

ChuanqiXu wrote:
> It looks like it would emit a `deallocate` first, and emit an 
> `alignedDeallocate`, which is very odd. Although I can find that the second 
> `deallocate` wouldn't be emitted due to the check 
> `LastCoroFreeUsedForDealloc`, it is still very odd to me. If the second 
> `deallocate` wouldn't come up all the way, what's the reason we need to write 
> `emit(deallocate)` twice?
Agree that `LastCoroFreeUsedForDealloc` is a bit confusing. It makes sure 
deallocation and aligned deallocation share one `coro.free`. Otherwise, AFAIK, 
there would be two `coro.free` get codegen'd.
```
%mem = llvm.coro.free()
br i1  , label , label 

aligend-dealloc:
use %mem

dealloc:
use %mem
```


> what's the reason we need to write emit(deallocate) twice?
John wrote a code snippet here: https://reviews.llvm.org/D100739#2717582. I 
think it would be helpful to look at the changed tests below to see the 
patterns.

Basically, for allocation, it looks like below; for deallocation, it would be 
similar.
```
void *rawFrame =nullptr;
...
if (llvm.coro.alloc()) {
  size_t size = llvm.coro.size(), align = llvm.coro.align();
  if (align > NEW_ALIGN) {
#if 
size += align - NEW_ALIGN + sizeof(void*);
frame = operator new(size);
rawFrame = frame;
frame = (frame + align - 1) & ~(align - 1);
#else
// If an aligned allocation function is selected.
frame = operator new(size, align);
#endif
  } else {
frame = operator new(size);
  }
}
```
The true branch of the #if directive is equivalent to "coro.alloc.align" block 
(and "coro.alloc.align2" if `get_return_object_on_allocation_failure` is 
defined), the false branch is equivalent to "coro.alloc" block.
The above pattern handles both aligned/normal allocation/deallocation so it is 
independent of D102147.



Comment at: clang/lib/CodeGen/CGCoroutine.cpp:700
+  auto *AlignedAllocateCall = EmitScalarExpr(S.getAlignedAllocate());
+  bool HasAlignArg = hasAlignArg(cast(AlignedAllocateCall));
+

ChuanqiXu wrote:
> Since `hasAlignArg` is called only once, I suggested to make it a lambda here 
> which would make the code more easy to read.
will do



Comment at: clang/lib/CodeGen/CGCoroutine.cpp:702-704
+  if (!HasAlignArg)
+overAllocateFrame(*this, cast(AlignedAllocateCall),
+  /*IsAlloc*/ true);

ChuanqiXu wrote:
> I recommend to add a detailed comment here to tell the story why we need to 
> over allocate the frame. It is really hard to understand for people who are 
> new to this code. Otherwise, I think they need to use `git blame` to find the 
> commit id and this review page to figure the reasons out.
will do.



Comment at: clang/lib/CodeGen/CGCoroutine.cpp:878
+if (CurCoro.Data && CurCoro.Data->LastCoroFreeUsedForDealloc)
+  return RValue::get(CurCoro.Data->LastCoroFree);
+

ChuanqiXu wrote:
> Is it possible that it would return a nullptr value?
Not that I know of. Because there is an early return 
```
if (!CoroFree) {
  CGF.CGM.Error(Deallocate->getBeginLoc(),
"Deallocation expressoin does not refer to coro.free");
  return;
}
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97915

___
cfe-commits mailing list

[clang] f690715 - Revert "[clang-repl] Land initial infrastructure for incremental parsing"

[Vassil Vassilev via cfe-commits]

Author: Vassil Vassilev
Date: 2021-05-13T04:44:19Z
New Revision: f6907152db3d70606817ffe28274c6a90b331bbc

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

LOG: Revert "[clang-repl] Land initial infrastructure for incremental parsing"

This reverts commit 44a4000181e1a25027e87f2ae4e71cb876a7a275.

We are seeing build failures due to missing dependency to libSupport and
CMake Error at tools/clang/tools/clang-repl/cmake_install.cmake
file INSTALL cannot find

Added: 
clang/unittests/CodeGen/IncrementalProcessingTest.cpp

Modified: 
clang/include/clang/CodeGen/CodeGenAction.h
clang/include/clang/Frontend/FrontendAction.h
clang/lib/CMakeLists.txt
clang/lib/CodeGen/CodeGenAction.cpp
clang/lib/Frontend/FrontendAction.cpp
clang/test/CMakeLists.txt
clang/test/lit.cfg.py
clang/tools/CMakeLists.txt
clang/unittests/CMakeLists.txt
clang/unittests/CodeGen/CMakeLists.txt

Removed: 
clang/include/clang/Interpreter/Interpreter.h
clang/include/clang/Interpreter/Transaction.h
clang/lib/Interpreter/CMakeLists.txt
clang/lib/Interpreter/IncrementalExecutor.cpp
clang/lib/Interpreter/IncrementalExecutor.h
clang/lib/Interpreter/IncrementalParser.cpp
clang/lib/Interpreter/IncrementalParser.h
clang/lib/Interpreter/Interpreter.cpp
clang/test/Interpreter/execute.cpp
clang/test/Interpreter/sanity.c
clang/tools/clang-repl/CMakeLists.txt
clang/tools/clang-repl/ClangRepl.cpp
clang/unittests/Interpreter/CMakeLists.txt
clang/unittests/Interpreter/IncrementalProcessingTest.cpp
clang/unittests/Interpreter/InterpreterTest.cpp



diff  --git a/clang/include/clang/CodeGen/CodeGenAction.h 
b/clang/include/clang/CodeGen/CodeGenAction.h
index b5721344046d..1db904ea974c 100644
--- a/clang/include/clang/CodeGen/CodeGenAction.h
+++ b/clang/include/clang/CodeGen/CodeGenAction.h
@@ -19,7 +19,6 @@ namespace llvm {
 
 namespace clang {
 class BackendConsumer;
-class CodeGenerator;
 
 class CodeGenAction : public ASTFrontendAction {
 private:
@@ -78,8 +77,6 @@ class CodeGenAction : public ASTFrontendAction {
   /// Take the LLVM context used by this action.
   llvm::LLVMContext *takeLLVMContext();
 
-  CodeGenerator *getCodeGenerator() const;
-
   BackendConsumer *BEConsumer;
 };
 

diff  --git a/clang/include/clang/Frontend/FrontendAction.h 
b/clang/include/clang/Frontend/FrontendAction.h
index dfefddfb4527..319b3bc62cc4 100644
--- a/clang/include/clang/Frontend/FrontendAction.h
+++ b/clang/include/clang/Frontend/FrontendAction.h
@@ -234,7 +234,7 @@ class FrontendAction {
 
   /// Perform any per-file post processing, deallocate per-file
   /// objects, and run statistics and output file cleanup code.
-  virtual void EndSourceFile();
+  void EndSourceFile();
 
   /// @}
 };
@@ -302,16 +302,15 @@ class PreprocessorFrontendAction : public FrontendAction {
 /// some existing action's behavior. It implements every virtual method in
 /// the FrontendAction interface by forwarding to the wrapped action.
 class WrapperFrontendAction : public FrontendAction {
-protected:
   std::unique_ptr WrappedAction;
 
+protected:
   bool PrepareToExecuteAction(CompilerInstance ) override;
   std::unique_ptr CreateASTConsumer(CompilerInstance ,
  StringRef InFile) override;
   bool BeginInvocation(CompilerInstance ) override;
   bool BeginSourceFileAction(CompilerInstance ) override;
   void ExecuteAction() override;
-  void EndSourceFile() override;
   void EndSourceFileAction() override;
   bool shouldEraseOutputFiles() override;
 

diff  --git a/clang/include/clang/Interpreter/Interpreter.h 
b/clang/include/clang/Interpreter/Interpreter.h
deleted file mode 100644
index d4dd8731da18..
--- a/clang/include/clang/Interpreter/Interpreter.h
+++ /dev/null
@@ -1,71 +0,0 @@
-//===--- Interpreter.h - Incremental Compilation and Execution---*- C++ 
-*-===//
-//
-// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
-// See https://llvm.org/LICENSE.txt for license information.
-// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
-//
-//===--===//
-//
-// This file defines the component which performs incremental code
-// compilation and execution.
-//
-//===--===//
-
-#ifndef LLVM_CLANG_INTERPRETER_INTERPRETER_H
-#define LLVM_CLANG_INTERPRETER_INTERPRETER_H
-
-#include "clang/Interpreter/Transaction.h"
-
-#include "llvm/Support/Error.h"
-
-#include 
-#include 
-
-namespace llvm {
-namespace orc {
-class ThreadSafeContext;
-}
-class Module;
-} // namespace llvm
-
-namespace clang {
-
-class CompilerInstance;
-class DeclGroupRef;
-class 

[PATCH] D96033: [clang-repl] Land initial infrastructure for incremental parsing

[Vassil Vassilev via Phabricator via cfe-commits]

v.g.vassilev added a comment.

Thanks everybody for reviewing and help making this patch better!!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96033

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

[clang] 44a4000 - [clang-repl] Land initial infrastructure for incremental parsing

[Vassil Vassilev via cfe-commits]

Author: Vassil Vassilev
Date: 2021-05-13T04:23:24Z
New Revision: 44a4000181e1a25027e87f2ae4e71cb876a7a275

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

LOG: [clang-repl] Land initial infrastructure for incremental parsing

In http://lists.llvm.org/pipermail/llvm-dev/2020-July/143257.html we have
mentioned our plans to make some of the incremental compilation facilities
available in llvm mainline.

This patch proposes a minimal version of a repl, clang-repl, which enables
interpreter-like interaction for C++. For instance:

./bin/clang-repl
clang-repl> int i = 42;
clang-repl> extern "C" int printf(const char*,...);
clang-repl> auto r1 = printf("i=%d\n", i);
i=42
clang-repl> quit

The patch allows very limited functionality, for example, it crashes on invalid
C++. The design of the proposed patch follows closely the design of cling. The
idea is to gather feedback and gradually evolve both clang-repl and cling to
what the community agrees upon.

The IncrementalParser class is responsible for driving the clang parser and
codegen and allows the compiler infrastructure to process more than one input.
Every input adds to the “ever-growing” translation unit. That model is enabled
by an IncrementalAction which prevents teardown when HandleTranslationUnit.

The IncrementalExecutor class hides some of the underlying implementation
details of the concrete JIT infrastructure. It exposes the minimal set of
functionality required by our incremental compiler/interpreter.

The Transaction class keeps track of the AST and the LLVM IR for each
incremental input. That tracking information will be later used to implement
error recovery.

The Interpreter class orchestrates the IncrementalParser and the
IncrementalExecutor to model interpreter-like behavior. It provides the public
API which can be used (in future) when using the interpreter library.

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

Added: 
clang/include/clang/Interpreter/Interpreter.h
clang/include/clang/Interpreter/Transaction.h
clang/lib/Interpreter/CMakeLists.txt
clang/lib/Interpreter/IncrementalExecutor.cpp
clang/lib/Interpreter/IncrementalExecutor.h
clang/lib/Interpreter/IncrementalParser.cpp
clang/lib/Interpreter/IncrementalParser.h
clang/lib/Interpreter/Interpreter.cpp
clang/test/Interpreter/execute.cpp
clang/test/Interpreter/sanity.c
clang/tools/clang-repl/CMakeLists.txt
clang/tools/clang-repl/ClangRepl.cpp
clang/unittests/Interpreter/CMakeLists.txt
clang/unittests/Interpreter/IncrementalProcessingTest.cpp
clang/unittests/Interpreter/InterpreterTest.cpp

Modified: 
clang/include/clang/CodeGen/CodeGenAction.h
clang/include/clang/Frontend/FrontendAction.h
clang/lib/CMakeLists.txt
clang/lib/CodeGen/CodeGenAction.cpp
clang/lib/Frontend/FrontendAction.cpp
clang/test/CMakeLists.txt
clang/test/lit.cfg.py
clang/tools/CMakeLists.txt
clang/unittests/CMakeLists.txt
clang/unittests/CodeGen/CMakeLists.txt

Removed: 
clang/unittests/CodeGen/IncrementalProcessingTest.cpp



diff  --git a/clang/include/clang/CodeGen/CodeGenAction.h 
b/clang/include/clang/CodeGen/CodeGenAction.h
index 1db904ea974c..b5721344046d 100644
--- a/clang/include/clang/CodeGen/CodeGenAction.h
+++ b/clang/include/clang/CodeGen/CodeGenAction.h
@@ -19,6 +19,7 @@ namespace llvm {
 
 namespace clang {
 class BackendConsumer;
+class CodeGenerator;
 
 class CodeGenAction : public ASTFrontendAction {
 private:
@@ -77,6 +78,8 @@ class CodeGenAction : public ASTFrontendAction {
   /// Take the LLVM context used by this action.
   llvm::LLVMContext *takeLLVMContext();
 
+  CodeGenerator *getCodeGenerator() const;
+
   BackendConsumer *BEConsumer;
 };
 

diff  --git a/clang/include/clang/Frontend/FrontendAction.h 
b/clang/include/clang/Frontend/FrontendAction.h
index 319b3bc62cc4..dfefddfb4527 100644
--- a/clang/include/clang/Frontend/FrontendAction.h
+++ b/clang/include/clang/Frontend/FrontendAction.h
@@ -234,7 +234,7 @@ class FrontendAction {
 
   /// Perform any per-file post processing, deallocate per-file
   /// objects, and run statistics and output file cleanup code.
-  void EndSourceFile();
+  virtual void EndSourceFile();
 
   /// @}
 };
@@ -302,15 +302,16 @@ class PreprocessorFrontendAction : public FrontendAction {
 /// some existing action's behavior. It implements every virtual method in
 /// the FrontendAction interface by forwarding to the wrapped action.
 class WrapperFrontendAction : public FrontendAction {
+protected:
   std::unique_ptr WrappedAction;
 
-protected:
   bool PrepareToExecuteAction(CompilerInstance ) override;
   std::unique_ptr CreateASTConsumer(CompilerInstance ,
  StringRef InFile) override;
   

[PATCH] D96033: [clang-repl] Land initial infrastructure for incremental parsing

[Vassil Vassilev via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG44a4000181e1: [clang-repl] Land initial infrastructure for 
incremental parsing (authored by v.g.vassilev).
Herald added a project: clang.

Changed prior to commit:
  https://reviews.llvm.org/D96033?vs=344941=345037#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96033

Files:
  clang/include/clang/CodeGen/CodeGenAction.h
  clang/include/clang/Frontend/FrontendAction.h
  clang/include/clang/Interpreter/Interpreter.h
  clang/include/clang/Interpreter/Transaction.h
  clang/lib/CMakeLists.txt
  clang/lib/CodeGen/CodeGenAction.cpp
  clang/lib/Frontend/FrontendAction.cpp
  clang/lib/Interpreter/CMakeLists.txt
  clang/lib/Interpreter/IncrementalExecutor.cpp
  clang/lib/Interpreter/IncrementalExecutor.h
  clang/lib/Interpreter/IncrementalParser.cpp
  clang/lib/Interpreter/IncrementalParser.h
  clang/lib/Interpreter/Interpreter.cpp
  clang/test/CMakeLists.txt
  clang/test/Interpreter/execute.cpp
  clang/test/Interpreter/sanity.c
  clang/test/lit.cfg.py
  clang/tools/CMakeLists.txt
  clang/tools/clang-repl/CMakeLists.txt
  clang/tools/clang-repl/ClangRepl.cpp
  clang/unittests/CMakeLists.txt
  clang/unittests/CodeGen/CMakeLists.txt
  clang/unittests/CodeGen/IncrementalProcessingTest.cpp
  clang/unittests/Interpreter/CMakeLists.txt
  clang/unittests/Interpreter/IncrementalProcessingTest.cpp
  clang/unittests/Interpreter/InterpreterTest.cpp

Index: clang/unittests/Interpreter/InterpreterTest.cpp
===
--- /dev/null
+++ clang/unittests/Interpreter/InterpreterTest.cpp
@@ -0,0 +1,122 @@
+//===- unittests/Interpreter/InterpreterTest.cpp --- Interpreter tests ===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// Unit tests for Clang's Interpreter library.
+//
+//===--===//
+
+#include "clang/Interpreter/Interpreter.h"
+
+#include "clang/AST/Decl.h"
+#include "clang/AST/DeclGroup.h"
+#include "clang/Frontend/CompilerInstance.h"
+#include "clang/Frontend/TextDiagnosticPrinter.h"
+
+#include "llvm/ADT/ArrayRef.h"
+
+#include "gmock/gmock.h"
+#include "gtest/gtest.h"
+
+using namespace clang;
+
+namespace {
+using Args = std::vector;
+static std::unique_ptr
+createInterpreter(const Args  = {},
+  DiagnosticConsumer *Client = nullptr) {
+  Args ClangArgs = {"-Xclang", "-emit-llvm-only"};
+  ClangArgs.insert(ClangArgs.end(), ExtraArgs.begin(), ExtraArgs.end());
+  auto CI = cantFail(clang::IncrementalCompilerBuilder::create(ClangArgs));
+  if (Client)
+CI->getDiagnostics().setClient(Client, /*ShouldOwnClient=*/false);
+  return cantFail(clang::Interpreter::create(std::move(CI)));
+}
+
+TEST(InterpreterTest, Sanity) {
+  std::unique_ptr Interp = createInterpreter();
+  Transaction (cantFail(Interp->Parse("void g(); void g() {}")));
+  EXPECT_EQ(2U, R1.Decls.size());
+
+  Transaction (cantFail(Interp->Parse("int i;")));
+  EXPECT_EQ(1U, R2.Decls.size());
+}
+
+static std::string DeclToString(DeclGroupRef DGR) {
+  return llvm::cast(DGR.getSingleDecl())->getQualifiedNameAsString();
+}
+
+TEST(InterpreterTest, IncrementalInputTopLevelDecls) {
+  std::unique_ptr Interp = createInterpreter();
+  auto R1OrErr = Interp->Parse("int var1 = 42; int f() { return var1; }");
+  // gtest doesn't expand into explicit bool conversions.
+  EXPECT_TRUE(!!R1OrErr);
+  auto R1 = R1OrErr->Decls;
+  EXPECT_EQ(2U, R1.size());
+  EXPECT_EQ("var1", DeclToString(R1[0]));
+  EXPECT_EQ("f", DeclToString(R1[1]));
+
+  auto R2OrErr = Interp->Parse("int var2 = f();");
+  EXPECT_TRUE(!!R2OrErr);
+  auto R2 = R2OrErr->Decls;
+  EXPECT_EQ(1U, R2.size());
+  EXPECT_EQ("var2", DeclToString(R2[0]));
+}
+
+TEST(InterpreterTest, Errors) {
+  Args ExtraArgs = {"-Xclang", "-diagnostic-log-file", "-Xclang", "-"};
+
+  // Create the diagnostic engine with unowned consumer.
+  std::string DiagnosticOutput;
+  llvm::raw_string_ostream DiagnosticsOS(DiagnosticOutput);
+  auto DiagPrinter = std::make_unique(
+  DiagnosticsOS, new DiagnosticOptions());
+
+  auto Interp = createInterpreter(ExtraArgs, DiagPrinter.get());
+  auto Err = Interp->Parse("intentional_error v1 = 42; ").takeError();
+  using ::testing::HasSubstr;
+  EXPECT_THAT(DiagnosticsOS.str(),
+  HasSubstr("error: unknown type name 'intentional_error'"));
+  EXPECT_EQ("Parsing failed.", llvm::toString(std::move(Err)));
+
+#ifdef GTEST_HAS_DEATH_TEST
+  EXPECT_DEATH((void)Interp->Parse("int var1 = 42;"), "");
+#endif
+}
+
+// Here we test whether the user can mix 

[PATCH] D99459: [OpenMP] Implement '#pragma omp unroll'.

[Michael Kruse via Phabricator via cfe-commits]

Meinersbur added a comment.

Removed [WIP] flag; ready to review.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99459

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

[PATCH] D102180: [Clang][OpenMP] Emit dependent PreInits before directive.

[Michael Kruse via Phabricator via cfe-commits]

Meinersbur updated this revision to Diff 345029.
Meinersbur added a comment.

- Preserve relative order between OriginalInits and interleaved 
transformation's PreInits


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102180

Files:
  clang/include/clang/AST/StmtOpenMP.h
  clang/lib/AST/StmtOpenMP.cpp
  clang/lib/CodeGen/CGStmtOpenMP.cpp
  clang/lib/Sema/SemaOpenMP.cpp
  clang/test/OpenMP/tile_codegen.cpp
  clang/test/OpenMP/tile_codegen_for_dependent.cpp
  clang/test/OpenMP/tile_codegen_tile_for.cpp

Index: clang/test/OpenMP/tile_codegen_tile_for.cpp
===
--- /dev/null
+++ clang/test/OpenMP/tile_codegen_tile_for.cpp
@@ -0,0 +1,253 @@
+// Check code generation
+// RUN: %clang_cc1 -verify -triple x86_64-pc-linux-gnu -fopenmp -fopenmp-version=51 -emit-llvm %s -o - | FileCheck %s --check-prefix=IR
+
+// Check same results after serialization round-trip
+// RUN: %clang_cc1 -verify -triple x86_64-pc-linux-gnu -fopenmp -fopenmp-version=51 -emit-pch -o %t %s
+// RUN: %clang_cc1 -verify -triple x86_64-pc-linux-gnu -fopenmp -fopenmp-version=51 -include-pch %t -emit-llvm %s -o - | FileCheck %s --check-prefix=IR
+// expected-no-diagnostics
+
+// Account for multiple transformations of a loop before consumed by
+// #pragma omp for.
+
+#ifndef HEADER
+#define HEADER
+
+// placeholder for loop body code.
+extern "C" void body(...) {}
+
+
+// IR-LABEL: @func(
+// IR-NEXT:  [[ENTRY:.*]]:
+// IR-NEXT:%[[START_ADDR:.+]] = alloca i32, align 4
+// IR-NEXT:%[[END_ADDR:.+]] = alloca i32, align 4
+// IR-NEXT:%[[STEP_ADDR:.+]] = alloca i32, align 4
+// IR-NEXT:%[[DOTOMP_IV:.+]] = alloca i32, align 4
+// IR-NEXT:%[[TMP:.+]] = alloca i32, align 4
+// IR-NEXT:%[[I:.+]] = alloca i32, align 4
+// IR-NEXT:%[[DOTCAPTURE_EXPR_:.+]] = alloca i32, align 4
+// IR-NEXT:%[[DOTCAPTURE_EXPR_1:.+]] = alloca i32, align 4
+// IR-NEXT:%[[DOTCAPTURE_EXPR_2:.+]] = alloca i32, align 4
+// IR-NEXT:%[[DOTCAPTURE_EXPR_3:.+]] = alloca i32, align 4
+// IR-NEXT:%[[DOTFLOOR_0_IV_I:.+]] = alloca i32, align 4
+// IR-NEXT:%[[DOTCAPTURE_EXPR_6:.+]] = alloca i32, align 4
+// IR-NEXT:%[[DOTCAPTURE_EXPR_8:.+]] = alloca i32, align 4
+// IR-NEXT:%[[DOTCAPTURE_EXPR_12:.+]] = alloca i32, align 4
+// IR-NEXT:%[[DOTCAPTURE_EXPR_14:.+]] = alloca i32, align 4
+// IR-NEXT:%[[DOTFLOOR_0_IV__FLOOR_0_IV_I:.+]] = alloca i32, align 4
+// IR-NEXT:%[[DOTOMP_LB:.+]] = alloca i32, align 4
+// IR-NEXT:%[[DOTOMP_UB:.+]] = alloca i32, align 4
+// IR-NEXT:%[[DOTOMP_STRIDE:.+]] = alloca i32, align 4
+// IR-NEXT:%[[DOTOMP_IS_LAST:.+]] = alloca i32, align 4
+// IR-NEXT:%[[DOTFLOOR_0_IV__FLOOR_0_IV_I18:.+]] = alloca i32, align 4
+// IR-NEXT:%[[DOTTILE_0_IV__FLOOR_0_IV_I:.+]] = alloca i32, align 4
+// IR-NEXT:%[[DOTTILE_0_IV_I:.+]] = alloca i32, align 4
+// IR-NEXT:%[[TMP0:.+]] = call i32 @__kmpc_global_thread_num(%struct.ident_t* @2)
+// IR-NEXT:store i32 %[[START:.+]], i32* %[[START_ADDR]], align 4
+// IR-NEXT:store i32 %[[END:.+]], i32* %[[END_ADDR]], align 4
+// IR-NEXT:store i32 %[[STEP:.+]], i32* %[[STEP_ADDR]], align 4
+// IR-NEXT:%[[TMP1:.+]] = load i32, i32* %[[START_ADDR]], align 4
+// IR-NEXT:store i32 %[[TMP1]], i32* %[[I]], align 4
+// IR-NEXT:%[[TMP2:.+]] = load i32, i32* %[[START_ADDR]], align 4
+// IR-NEXT:store i32 %[[TMP2]], i32* %[[DOTCAPTURE_EXPR_]], align 4
+// IR-NEXT:%[[TMP3:.+]] = load i32, i32* %[[END_ADDR]], align 4
+// IR-NEXT:store i32 %[[TMP3]], i32* %[[DOTCAPTURE_EXPR_1]], align 4
+// IR-NEXT:%[[TMP4:.+]] = load i32, i32* %[[STEP_ADDR]], align 4
+// IR-NEXT:store i32 %[[TMP4]], i32* %[[DOTCAPTURE_EXPR_2]], align 4
+// IR-NEXT:%[[TMP5:.+]] = load i32, i32* %[[DOTCAPTURE_EXPR_1]], align 4
+// IR-NEXT:%[[TMP6:.+]] = load i32, i32* %[[DOTCAPTURE_EXPR_]], align 4
+// IR-NEXT:%[[SUB:.+]] = sub i32 %[[TMP5]], %[[TMP6]]
+// IR-NEXT:%[[SUB4:.+]] = sub i32 %[[SUB]], 1
+// IR-NEXT:%[[TMP7:.+]] = load i32, i32* %[[DOTCAPTURE_EXPR_2]], align 4
+// IR-NEXT:%[[ADD:.+]] = add i32 %[[SUB4]], %[[TMP7]]
+// IR-NEXT:%[[TMP8:.+]] = load i32, i32* %[[DOTCAPTURE_EXPR_2]], align 4
+// IR-NEXT:%[[DIV:.+]] = udiv i32 %[[ADD]], %[[TMP8]]
+// IR-NEXT:%[[SUB5:.+]] = sub i32 %[[DIV]], 1
+// IR-NEXT:store i32 %[[SUB5]], i32* %[[DOTCAPTURE_EXPR_3]], align 4
+// IR-NEXT:store i32 0, i32* %[[DOTFLOOR_0_IV_I]], align 4
+// IR-NEXT:%[[TMP9:.+]] = load i32, i32* %[[DOTCAPTURE_EXPR_3]], align 4
+// IR-NEXT:%[[ADD7:.+]] = add i32 %[[TMP9]], 1
+// IR-NEXT:store i32 %[[ADD7]], i32* %[[DOTCAPTURE_EXPR_6]], align 4
+// IR-NEXT:%[[TMP10:.+]] = load i32, i32* %[[DOTCAPTURE_EXPR_6]], align 4
+// IR-NEXT:%[[SUB9:.+]] = sub i32 %[[TMP10]], -3
+// IR-NEXT:%[[DIV10:.+]] = udiv i32 %[[SUB9]], 4
+// IR-NEXT:%[[SUB11:.+]] = sub i32 %[[DIV10]], 1
+// IR-NEXT:   

[clang] a0ca4c4 - [Debug-Info] add -gstrict-dwarf support in backend

[Chen Zheng via cfe-commits]

Author: Chen Zheng
Date: 2021-05-12T23:00:52-04:00
New Revision: a0ca4c46ca35957a38a6023fa84afda2fc9ba0ec

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

LOG: [Debug-Info] add -gstrict-dwarf support in backend

Reviewed By: dblaikie, probinson

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

Added: 
llvm/test/DebugInfo/PowerPC/strict-dwarf.ll

Modified: 
clang/lib/CodeGen/BackendUtil.cpp
llvm/include/llvm/CodeGen/CommandFlags.h
llvm/include/llvm/Target/TargetOptions.h
llvm/lib/CodeGen/CommandFlags.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/BackendUtil.cpp 
b/clang/lib/CodeGen/BackendUtil.cpp
index 2be0b1a3280d..e2799f6aba4c 100644
--- a/clang/lib/CodeGen/BackendUtil.cpp
+++ b/clang/lib/CodeGen/BackendUtil.cpp
@@ -598,6 +598,7 @@ static bool initTargetOptions(DiagnosticsEngine ,
   Entry.IgnoreSysRoot ? Entry.Path : HSOpts.Sysroot + Entry.Path);
   Options.MCOptions.Argv0 = CodeGenOpts.Argv0;
   Options.MCOptions.CommandLineArgs = CodeGenOpts.CommandLineArgs;
+  Options.DebugStrictDwarf = CodeGenOpts.DebugStrictDwarf;
 
   return true;
 }

diff  --git a/llvm/include/llvm/CodeGen/CommandFlags.h 
b/llvm/include/llvm/CodeGen/CommandFlags.h
index a12733801213..f4555c34585e 100644
--- a/llvm/include/llvm/CodeGen/CommandFlags.h
+++ b/llvm/include/llvm/CodeGen/CommandFlags.h
@@ -140,6 +140,8 @@ bool getForceDwarfFrameSection();
 
 bool getXRayOmitFunctionIndex();
 
+bool getDebugStrictDwarf();
+
 /// Create this object with static storage to register codegen-related command
 /// line options.
 struct RegisterCodeGenFlags {

diff  --git a/llvm/include/llvm/Target/TargetOptions.h 
b/llvm/include/llvm/Target/TargetOptions.h
index cad356edacec..09c8cf59f4ab 100644
--- a/llvm/include/llvm/Target/TargetOptions.h
+++ b/llvm/include/llvm/Target/TargetOptions.h
@@ -137,6 +137,7 @@ namespace llvm {
   SupportsDebugEntryValues(false), EnableDebugEntryValues(false),
   PseudoProbeForProfiling(false), 
ValueTrackingVariableLocations(false),
   ForceDwarfFrameSection(false), XRayOmitFunctionIndex(false),
+  DebugStrictDwarf(false),
   FPDenormalMode(DenormalMode::IEEE, DenormalMode::IEEE) {}
 
 /// DisableFramePointerElim - This returns true if frame pointer 
elimination
@@ -327,6 +328,10 @@ namespace llvm {
 /// Emit XRay Function Index section
 unsigned XRayOmitFunctionIndex : 1;
 
+/// When set to true, don't use DWARF extensions in later DWARF versions.
+/// By default, it is set to false.
+unsigned DebugStrictDwarf : 1;
+
 /// Stack protector guard offset to use.
 int StackProtectorGuardOffset = INT_MAX;
 

diff  --git a/llvm/lib/CodeGen/CommandFlags.cpp 
b/llvm/lib/CodeGen/CommandFlags.cpp
index 4c6c5950117f..b8f1ca154f6c 100644
--- a/llvm/lib/CodeGen/CommandFlags.cpp
+++ b/llvm/lib/CodeGen/CommandFlags.cpp
@@ -97,6 +97,7 @@ CGOPT(bool, PseudoProbeForProfiling)
 CGOPT(bool, ValueTrackingVariableLocations)
 CGOPT(bool, ForceDwarfFrameSection)
 CGOPT(bool, XRayOmitFunctionIndex)
+CGOPT(bool, DebugStrictDwarf)
 
 codegen::RegisterCodeGenFlags::RegisterCodeGenFlags() {
 #define CGBINDOPT(NAME)
\
@@ -471,6 +472,10 @@ codegen::RegisterCodeGenFlags::RegisterCodeGenFlags() {
   cl::init(false));
   CGBINDOPT(XRayOmitFunctionIndex);
 
+  static cl::opt DebugStrictDwarf(
+  "strict-dwarf", cl::desc("use strict dwarf"), cl::init(false));
+  CGBINDOPT(DebugStrictDwarf);
+
 #undef CGBINDOPT
 
   mc::RegisterMCTargetOptionsFlags();
@@ -567,6 +572,7 @@ codegen::InitTargetOptionsFromCodeGenFlags(const Triple 
) {
   Options.ValueTrackingVariableLocations = getValueTrackingVariableLocations();
   Options.ForceDwarfFrameSection = getForceDwarfFrameSection();
   Options.XRayOmitFunctionIndex = getXRayOmitFunctionIndex();
+  Options.DebugStrictDwarf = getDebugStrictDwarf();
 
   Options.MCOptions = mc::InitMCTargetOptionsFromFlags();
 

diff  --git a/llvm/test/DebugInfo/PowerPC/strict-dwarf.ll 
b/llvm/test/DebugInfo/PowerPC/strict-dwarf.ll
new file mode 100644
index ..b64fd426e8ea
--- /dev/null
+++ b/llvm/test/DebugInfo/PowerPC/strict-dwarf.ll
@@ -0,0 +1,60 @@
+; RUN: llc -filetype=obj -mtriple=powerpc64le-unknown-linux-gnu < %s | \
+; RUN:   llvm-dwarfdump -debug-info - | FileCheck %s
+; RUN: llc -filetype=obj -mtriple=powerpc64le-unknown-linux-gnu \
+; RUN:   -strict-dwarf=true < %s | llvm-dwarfdump -debug-info - | \
+; RUN:   FileCheck %s
+
+; FIXME: when -strict-dwarf=true is specified, we should check "STRICT" to tell
+; that with DWARF 4, we should not generate DWARF 5 attribute DW_AT_noreturn 
and
+; DW_AT_alignment.
+
+; CHECK: DW_AT_alignment
+; CHECK: DW_AT_noreturn
+; STRICT-NOT: DW_AT_noreturn
+; STRICT-NOT: 

[PATCH] D102064: Parse vector bool when stdbool.h and altivec.h are included

[Hubert Tong via Phabricator via cfe-commits]

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

LGTM with comment.




Comment at: clang/test/Parser/altivec-zvector-bool.c:20-23
+__vector _Bool char Bc;
+__vector _Bool short Bsh;
+__vector _Bool short int Bshi;
+__vector _Bool int Bi;

I think having these as declarations of the names used above is beneficial 
because it confirms that the types formed using the `bool` spelling are 
compatible with the same using the `_Bool` spelling.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102064

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

[PATCH] D102213: [ASTMatchers] Add forCallable(), a generalization of forFunction().

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added a comment.

Additionally, `forCallable(functionDecl())` is not equivalent to 
`forFunction()` (the former silently matches less stuff). So anybody who had 
`functionDecl()` spelled out explicitly in their code will observe a silent 
change in behavior. I think that most of the time the difference was a footgun 
(i.e., most of the time when people wrote `forFunction()` they actually 
expected it to behave like `forCallable(functionDecl())`) but I can't be 100% 
sure.


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

https://reviews.llvm.org/D102213

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

[PATCH] D102294: [clang-tidy] bugprone-infinite-loop: React to ObjC ivars and messages in condition.

[Artem Dergachev via Phabricator via cfe-commits]

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

We do actually have variadic `isa<>`!


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

https://reviews.llvm.org/D102294

Files:
  clang-tools-extra/clang-tidy/bugprone/InfiniteLoopCheck.cpp
  clang-tools-extra/test/clang-tidy/checkers/bugprone-infinite-loop.mm

Index: clang-tools-extra/test/clang-tidy/checkers/bugprone-infinite-loop.mm
===
--- clang-tools-extra/test/clang-tidy/checkers/bugprone-infinite-loop.mm
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone-infinite-loop.mm
@@ -1,9 +1,21 @@
 // RUN: %check_clang_tidy %s bugprone-infinite-loop %t -- -- -fblocks
+// RUN: %check_clang_tidy %s bugprone-infinite-loop %t -- -- -fblocks -fobjc-arc
+
+typedef __typeof(sizeof(int)) NSUInteger;
+
+@interface NSArray
++(instancetype)alloc;
+-(instancetype)init;
+@property(readonly) NSUInteger count;
+-(void)addObject: (id)anObject;
+@end
 
 @interface I
 -(void) instanceMethod;
 +(void) classMethod;
 +(int &) hiddenReferenceTo: (int &)x;
++(instancetype)alloc;
+-(instancetype)init;
 @end
 
 void plainCFunction() {
@@ -47,3 +59,81 @@
   return x;
 }
 @end
+
+void testArrayCount() {
+  NSArray *arr = [[NSArray alloc] init];
+  NSUInteger max_count = 10;
+  while ([arr count] < max_count) {
+// No warning. Array count is updated on every iteration.
+[arr addObject: [[I alloc] init]];
+  }
+}
+
+void testArrayCountWithConstant() {
+  NSArray *arr = [[NSArray alloc] init];
+  while ([arr count] < 10) {
+// No warning. Array count is updated on every iteration.
+[arr addObject: [[I alloc] init]];
+  }
+}
+
+void testArrayCountProperty() {
+  NSArray *arr = [[NSArray alloc] init];
+  NSUInteger max_count = 10;
+  while (arr.count < max_count) {
+// No warning. Array count is updated on every iteration.
+[arr addObject: [[I alloc] init]];
+  }
+}
+
+void testArrayCountPropertyWithConstant() {
+  NSArray *arr = [[NSArray alloc] init];
+  while (arr.count < 10) {
+// No warning. Array count is updated on every iteration.
+[arr addObject: [[I alloc] init]];
+  }
+}
+
+@interface MyArray {
+  @public NSUInteger _count;
+}
++(instancetype)alloc;
+-(instancetype)init;
+-(void)addObject: (id)anObject;
+
+-(void)populate;
+@end
+
+@implementation MyArray
+-(void)populate {
+  NSUInteger max_count = 10;
+  while (_count < max_count) {
+// No warning. Array count is updated on every iteration.
+[self addObject: [[I alloc] init]];
+  }
+}
+
+-(void)populateWithConstant {
+  while (_count < 10) {
+// No warning. Array count is updated on every iteration.
+[self addObject: [[I alloc] init]];
+  }
+}
+@end
+
+void testArrayCountIvar() {
+  MyArray *arr = [[MyArray alloc] init];
+  NSUInteger max_count = 10;
+  while (arr->_count < max_count) {
+// No warning. Array count is updated on every iteration.
+[arr addObject: [[I alloc] init]];
+  }
+}
+
+void testArrayCountIvarWithConstant() {
+  MyArray *arr = [[MyArray alloc] init];
+  while (arr->_count < 10) {
+// No warning. Array count is updated on every iteration.
+[arr addObject: [[I alloc] init]];
+  }
+}
Index: clang-tools-extra/clang-tidy/bugprone/InfiniteLoopCheck.cpp
===
--- clang-tools-extra/clang-tidy/bugprone/InfiniteLoopCheck.cpp
+++ clang-tools-extra/clang-tidy/bugprone/InfiniteLoopCheck.cpp
@@ -61,7 +61,8 @@
  isChanged(LoopStmt, Var, Context);
   // FIXME: Track references.
 }
-  } else if (isa(Cond) || isa(Cond)) {
+  } else if (isa(Cond)) {
 // FIXME: Handle MemberExpr.
 return true;
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] ce6cc87 - [clang] Minor fix for MarkVarDeclODRUsed

[Yaxun Liu via cfe-commits]

Author: Yaxun (Sam) Liu
Date: 2021-05-12T22:32:10-04:00
New Revision: ce6cc87ce9e96eaa5e5ef0c1f5dc07b41381996d

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

LOG: [clang] Minor fix for MarkVarDeclODRUsed

Merge two if as follow up of https://reviews.llvm.org/D102270

Added: 


Modified: 
clang/lib/Sema/SemaExpr.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaExpr.cpp b/clang/lib/Sema/SemaExpr.cpp
index b8be6732b758..6e20eb5b99dd 100644
--- a/clang/lib/Sema/SemaExpr.cpp
+++ b/clang/lib/Sema/SemaExpr.cpp
@@ -17126,7 +17126,7 @@ MarkVarDeclODRUsed(VarDecl *Var, SourceLocation Loc, 
Sema ,
 CaptureType, DeclRefType,
 FunctionScopeIndexToStopAt);
 
-  if (SemaRef.LangOpts.CUDA) {
+  if (SemaRef.LangOpts.CUDA && Var && Var->hasGlobalStorage()) {
 auto *FD = dyn_cast_or_null(SemaRef.CurContext);
 auto Target = SemaRef.IdentifyCUDATarget(FD);
 auto IsEmittedOnDeviceSide = [](VarDecl *Var) {
@@ -17142,28 +17142,26 @@ MarkVarDeclODRUsed(VarDecl *Var, SourceLocation Loc, 
Sema ,
   }
   return false;
 };
-if (Var && Var->hasGlobalStorage()) {
-  if (!IsEmittedOnDeviceSide(Var)) {
-// Diagnose ODR-use of host global variables in device functions.
-// Reference of device global variables in host functions is allowed
-// through shadow variables therefore it is not diagnosed.
-if (SemaRef.LangOpts.CUDAIsDevice)
-  SemaRef.targetDiag(Loc, diag::err_ref_bad_target)
-  << /*host*/ 2 << /*variable*/ 1 << Var << Target;
-  } else if ((Target == Sema::CFT_Host || Target == Sema::CFT_HostDevice) 
&&
- !Var->hasExternalStorage()) {
-// Record a CUDA/HIP device side variable if it is ODR-used
-// by host code. This is done conservatively, when the variable is
-// referenced in any of the following contexts:
-//   - a non-function context
-//   - a host function
-//   - a host device function
-// This makes the ODR-use of the device side variable by host code to
-// be visible in the device compilation for the compiler to be able to
-// emit template variables instantiated by host code only and to
-// externalize the static device side variable ODR-used by host code.
-SemaRef.getASTContext().CUDADeviceVarODRUsedByHost.insert(Var);
-  }
+if (!IsEmittedOnDeviceSide(Var)) {
+  // Diagnose ODR-use of host global variables in device functions.
+  // Reference of device global variables in host functions is allowed
+  // through shadow variables therefore it is not diagnosed.
+  if (SemaRef.LangOpts.CUDAIsDevice)
+SemaRef.targetDiag(Loc, diag::err_ref_bad_target)
+<< /*host*/ 2 << /*variable*/ 1 << Var << Target;
+} else if ((Target == Sema::CFT_Host || Target == Sema::CFT_HostDevice) &&
+   !Var->hasExternalStorage()) {
+  // Record a CUDA/HIP device side variable if it is ODR-used
+  // by host code. This is done conservatively, when the variable is
+  // referenced in any of the following contexts:
+  //   - a non-function context
+  //   - a host function
+  //   - a host device function
+  // This makes the ODR-use of the device side variable by host code to
+  // be visible in the device compilation for the compiler to be able to
+  // emit template variables instantiated by host code only and to
+  // externalize the static device side variable ODR-used by host code.
+  SemaRef.getASTContext().CUDADeviceVarODRUsedByHost.insert(Var);
 }
   }
 



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

[clang] e1aa528 - Handle unexpanded packs appearing in type-constraints.

[Richard Smith via cfe-commits]

Author: Richard Smith
Date: 2021-05-12T18:45:34-07:00
New Revision: e1aa528d3aaf5fcf9c50d1e34b39dbde1e63801d

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

LOG: Handle unexpanded packs appearing in type-constraints.

For a type-constraint in a lambda signature, this makes the lambda
contain an unexpanded pack; for requirements in a requires-expressions
it makes the requires-expression contain an unexpanded pack; otherwise
it's invalid.

Added: 


Modified: 
clang/include/clang/AST/DeclTemplate.h
clang/include/clang/AST/RecursiveASTVisitor.h
clang/include/clang/Sema/Sema.h
clang/lib/AST/DeclTemplate.cpp
clang/lib/AST/Type.cpp
clang/lib/Sema/SemaExprCXX.cpp
clang/lib/Sema/SemaTemplate.cpp
clang/lib/Sema/SemaType.cpp
clang/test/SemaTemplate/concepts.cpp

Removed: 




diff  --git a/clang/include/clang/AST/DeclTemplate.h 
b/clang/include/clang/AST/DeclTemplate.h
index 0cd8f00c623b..cbaa287f225a 100644
--- a/clang/include/clang/AST/DeclTemplate.h
+++ b/clang/include/clang/AST/DeclTemplate.h
@@ -160,9 +160,7 @@ class TemplateParameterList final
 
   /// Determine whether this template parameter list contains an
   /// unexpanded parameter pack.
-  bool containsUnexpandedParameterPack() const {
-return ContainsUnexpandedParameterPack;
-  }
+  bool containsUnexpandedParameterPack() const;
 
   /// Determine whether this template parameter list contains a parameter pack.
   bool hasParameterPack() const {

diff  --git a/clang/include/clang/AST/RecursiveASTVisitor.h 
b/clang/include/clang/AST/RecursiveASTVisitor.h
index 9499564e46e0..4770a2fd42a2 100644
--- a/clang/include/clang/AST/RecursiveASTVisitor.h
+++ b/clang/include/clang/AST/RecursiveASTVisitor.h
@@ -481,6 +481,8 @@ template  class RecursiveASTVisitor {
   template 
   bool TraverseDeclTemplateParameterLists(T *D);
 
+  bool TraverseTemplateTypeParamDeclConstraints(const TemplateTypeParmDecl *D);
+
   bool TraverseTemplateArgumentLocsHelper(const TemplateArgumentLoc *TAL,
   unsigned Count);
   bool TraverseArrayTypeLocHelper(ArrayTypeLoc TL);
@@ -658,8 +660,14 @@ bool RecursiveASTVisitor::TraverseDecl(Decl *D) {
 
   // As a syntax visitor, by default we want to ignore declarations for
   // implicit declarations (ones not typed explicitly by the user).
-  if (!getDerived().shouldVisitImplicitCode() && D->isImplicit())
+  if (!getDerived().shouldVisitImplicitCode() && D->isImplicit()) {
+// For an implicit template type parameter, its type constraints are not
+// implicit and are not represented anywhere else. We still need to visit
+// them.
+if (auto *TTPD = dyn_cast(D))
+  return TraverseTemplateTypeParamDeclConstraints(TTPD);
 return true;
+  }
 
   switch (D->getKind()) {
 #define ABSTRACT_DECL(DECL)
@@ -1779,10 +1787,9 @@ DEF_TRAVERSE_DECL(BuiltinTemplateDecl, {
   TRY_TO(TraverseTemplateParameterListHelper(D->getTemplateParameters()));
 })
 
-DEF_TRAVERSE_DECL(TemplateTypeParmDecl, {
-  // D is the "T" in something like "template class vector;"
-  if (D->getTypeForDecl())
-TRY_TO(TraverseType(QualType(D->getTypeForDecl(), 0)));
+template 
+bool RecursiveASTVisitor::TraverseTemplateTypeParamDeclConstraints(
+const TemplateTypeParmDecl *D) {
   if (const auto *TC = D->getTypeConstraint()) {
 if (Expr *IDC = TC->getImmediatelyDeclaredConstraint()) {
   TRY_TO(TraverseStmt(IDC));
@@ -1794,6 +1801,14 @@ DEF_TRAVERSE_DECL(TemplateTypeParmDecl, {
   TRY_TO(TraverseConceptReference(*TC));
 }
   }
+  return true;
+}
+
+DEF_TRAVERSE_DECL(TemplateTypeParmDecl, {
+  // D is the "T" in something like "template class vector;"
+  if (D->getTypeForDecl())
+TRY_TO(TraverseType(QualType(D->getTypeForDecl(), 0)));
+  TRY_TO(TraverseTemplateTypeParamDeclConstraints(D));
   if (D->hasDefaultArgument() && !D->defaultArgumentWasInherited())
 TRY_TO(TraverseTypeLoc(D->getDefaultArgumentInfo()->getTypeLoc()));
 })

diff  --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
index 53ff0f1e634d..135da703c4df 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -7455,6 +7455,11 @@ class Sema final {
TemplateIdAnnotation *TypeConstraint,
TemplateTypeParmDecl *ConstrainedParameter,
SourceLocation EllipsisLoc);
+  bool BuildTypeConstraint(const CXXScopeSpec ,
+   TemplateIdAnnotation *TypeConstraint,
+   TemplateTypeParmDecl *ConstrainedParameter,
+   SourceLocation EllipsisLoc,
+   bool AllowUnexpandedPack);
 
   bool AttachTypeConstraint(NestedNameSpecifierLoc NS,

[clang] 2f9d8b0 - PR50306: When instantiating a generic lambda with a constrained 'auto',

[Richard Smith via cfe-commits]

Author: Richard Smith
Date: 2021-05-12T18:45:33-07:00
New Revision: 2f9d8b08ea658b612065cbf7d4b0fbd7f28bb36a

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

LOG: PR50306: When instantiating a generic lambda with a constrained 'auto',
properly track that it has constraints.

Previously an instantiation of a constrained generic lambda would behave
as if unconstrained because we incorrectly cached a "has no constraints"
value that we computed before the constraints from 'auto' parameters
were attached.

Added: 


Modified: 
clang/lib/AST/DeclTemplate.cpp
clang/test/SemaTemplate/concepts.cpp

Removed: 




diff  --git a/clang/lib/AST/DeclTemplate.cpp b/clang/lib/AST/DeclTemplate.cpp
index 4b3a4062d642..ba4a5359f937 100644
--- a/clang/lib/AST/DeclTemplate.cpp
+++ b/clang/lib/AST/DeclTemplate.cpp
@@ -68,12 +68,21 @@ TemplateParameterList::TemplateParameterList(const 
ASTContext& C,
   if (!IsPack &&
   TTP->getTemplateParameters()->containsUnexpandedParameterPack())
 ContainsUnexpandedParameterPack = true;
-} else if (const TypeConstraint *TC =
-cast(P)->getTypeConstraint()) {
-  if (TC->getImmediatelyDeclaredConstraint()
-  ->containsUnexpandedParameterPack())
-ContainsUnexpandedParameterPack = true;
-  HasConstrainedParameters = true;
+} else if (const auto *TTP = dyn_cast(P)) {
+  // FIXME: The type parameter might have a constraint that has not been
+  // attached yet. If so, we can compute the wrong value for
+  // 'ContainsUnexpandedParameterPack' here. Note that this only happens
+  // for implicit parameters, for which the ParmVarDecl will correctly
+  // track that it contains an unexpanded parameter pack, so this should
+  // not be problematic in practice.
+  if (const TypeConstraint *TC = TTP->getTypeConstraint()) {
+if (TC->getImmediatelyDeclaredConstraint()
+->containsUnexpandedParameterPack())
+  ContainsUnexpandedParameterPack = true;
+  }
+  HasConstrainedParameters = TTP->hasTypeConstraint();
+} else {
+  llvm_unreachable("unexpcted template parameter type");
 }
 // FIXME: If a default argument contains an unexpanded parameter pack, the
 // template parameter list does too.

diff  --git a/clang/test/SemaTemplate/concepts.cpp 
b/clang/test/SemaTemplate/concepts.cpp
index 2a46dec5afb7..753a84c35e1f 100644
--- a/clang/test/SemaTemplate/concepts.cpp
+++ b/clang/test/SemaTemplate/concepts.cpp
@@ -65,3 +65,12 @@ namespace P0857R0 {
   template requires C struct Y {};
   X xy; // expected-error {{no template named 'X'}}
 }
+
+namespace PR50306 {
+  template concept NotInt = sizeof(T) != sizeof(int); // 
expected-note {{because}}
+  template void f() {
+[](NotInt auto) {}(T()); // expected-error {{no matching function}} 
expected-note {{constraints not satisfied}} expected-note {{because}}
+  }
+  template void f(); // OK
+  template void f(); // expected-note {{in instantiation of}}
+}



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

[clang] e0acfed - Clean up handling of constrained parameters in lambdas.

[Richard Smith via cfe-commits]

Author: Richard Smith
Date: 2021-05-12T18:45:33-07:00
New Revision: e0acfed7ed5173b437868f75fc394084487e390a

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

LOG: Clean up handling of constrained parameters in lambdas.

No functionality change intended.

Added: 


Modified: 
clang/lib/AST/TypePrinter.cpp
clang/lib/Sema/SemaTemplateInstantiate.cpp
clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
clang/lib/Sema/TreeTransform.h

Removed: 




diff  --git a/clang/lib/AST/TypePrinter.cpp b/clang/lib/AST/TypePrinter.cpp
index 59549dbfba2b..748a48f8eca4 100644
--- a/clang/lib/AST/TypePrinter.cpp
+++ b/clang/lib/AST/TypePrinter.cpp
@@ -1125,7 +1125,9 @@ void TypePrinter::printAutoBefore(const AutoType *T, 
raw_ostream ) {
 printBefore(T->getDeducedType(), OS);
   } else {
 if (T->isConstrained()) {
-  OS << T->getTypeConstraintConcept()->getName();
+  // FIXME: Track a TypeConstraint as type sugar, so that we can print the
+  // type as it was written.
+  T->getTypeConstraintConcept()->getDeclName().print(OS, Policy);
   auto Args = T->getTypeConstraintArguments();
   if (!Args.empty())
 printTemplateArgumentList(

diff  --git a/clang/lib/Sema/SemaTemplateInstantiate.cpp 
b/clang/lib/Sema/SemaTemplateInstantiate.cpp
index a4cbb2e8e9d5..cfafd423fa5f 100644
--- a/clang/lib/Sema/SemaTemplateInstantiate.cpp
+++ b/clang/lib/Sema/SemaTemplateInstantiate.cpp
@@ -2386,10 +2386,10 @@ ParmVarDecl *Sema::SubstParmVarDecl(ParmVarDecl 
*OldParm,
 }
 if (AttachTypeConstraint(
 TC->getNestedNameSpecifierLoc(), TC->getConceptNameInfo(),
-TC->getNamedConcept(), , Inst,
+TC->getNamedConcept(), TemplArgInfo ?  : nullptr, 
Inst,
 TTP->isParameterPack()
 ? cast(TC->getImmediatelyDeclaredConstraint())
-->getEllipsisLoc()
+  ->getEllipsisLoc()
 : SourceLocation()))
   return nullptr;
   }

diff  --git a/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp 
b/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
index 1d572054e5fb..cbd29701496b 100644
--- a/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
+++ b/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
@@ -2581,7 +2581,6 @@ Decl 
*TemplateDeclInstantiator::VisitParmVarDecl(ParmVarDecl *D) {
 
 Decl *TemplateDeclInstantiator::VisitTemplateTypeParmDecl(
 TemplateTypeParmDecl *D) {
-  // TODO: don't always clone when decls are refcounted.
   assert(D->getTypeForDecl()->isTemplateTypeParmType());
 
   Optional NumExpanded;

diff  --git a/clang/lib/Sema/TreeTransform.h b/clang/lib/Sema/TreeTransform.h
index 5a2013bd53a7..18864e731f17 100644
--- a/clang/lib/Sema/TreeTransform.h
+++ b/clang/lib/Sema/TreeTransform.h
@@ -6515,11 +6515,9 @@ QualType 
TreeTransform::TransformAutoType(TypeLocBuilder ,
   ConceptDecl *NewCD = nullptr;
   TemplateArgumentListInfo NewTemplateArgs;
   NestedNameSpecifierLoc NewNestedNameSpec;
-  if (TL.getTypePtr()->isConstrained()) {
-NewCD = cast_or_null(
-getDerived().TransformDecl(
-TL.getConceptNameLoc(),
-TL.getTypePtr()->getTypeConstraintConcept()));
+  if (T->isConstrained()) {
+NewCD = cast_or_null(getDerived().TransformDecl(
+TL.getConceptNameLoc(), T->getTypeConstraintConcept()));
 
 NewTemplateArgs.setLAngleLoc(TL.getLAngleLoc());
 NewTemplateArgs.setRAngleLoc(TL.getRAngleLoc());
@@ -6541,7 +6539,8 @@ QualType 
TreeTransform::TransformAutoType(TypeLocBuilder ,
 
   QualType Result = TL.getType();
   if (getDerived().AlwaysRebuild() || NewDeduced != OldDeduced ||
-  T->isDependentType()) {
+  T->isDependentType() || T->isConstrained()) {
+// FIXME: Maybe don't rebuild if all template arguments are the same.
 llvm::SmallVector NewArgList;
 NewArgList.reserve(NewArgList.size());
 for (const auto  : NewTemplateArgs.arguments())



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

[clang] 4c88cfb - Add test for substitutability of variable templates in closure type

[Richard Smith via cfe-commits]

Author: Richard Smith
Date: 2021-05-12T18:45:33-07:00
New Revision: 4c88cfb1dc79227be78f8dade966934384914e5e

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

LOG: Add test for substitutability of variable templates in closure type
mangling.

Added: 


Modified: 
clang/test/CodeGenCXX/mangle-lambdas.cpp

Removed: 




diff  --git a/clang/test/CodeGenCXX/mangle-lambdas.cpp 
b/clang/test/CodeGenCXX/mangle-lambdas.cpp
index 7d236b4685a5..66ce8a856851 100644
--- a/clang/test/CodeGenCXX/mangle-lambdas.cpp
+++ b/clang/test/CodeGenCXX/mangle-lambdas.cpp
@@ -44,6 +44,9 @@ template auto var_template = [] {
 
 int *use_var_template = var_template();
 
+// CHECK-LABEL: define {{.*}} 
@_Z29use_var_template_substitutionN12var_templateIiEMUlvE_ENS_IfEMUlvE_E
+void use_var_template_substitution(decltype(var_template), 
decltype(var_template)) {}
+
 struct S {
   void f(int = []{return 1;}()
  + []{return 2;}(),



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

[PATCH] D102339: [clang] On Windows, ignore case and separators when discarding duplicate dependency file paths.

[Nico Weber via Phabricator via cfe-commits]

thakis added a comment.

We share obj files built on linux and on windows. So that's a goal for us.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102339

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

[clang] 10c779d - [AMDGPU][OpenMP] Emit textual IR for -emit-llvm -S

[Pushpinder Singh via cfe-commits]

Author: Pushpinder Singh
Date: 2021-05-13T01:34:03Z
New Revision: 10c779d2065f7e216660f1687244269afcee13b1

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

LOG: [AMDGPU][OpenMP] Emit textual IR for -emit-llvm -S

Previously clang would print a binary blob into the bundled file
for amdgcn. With this patch, it will instead print textual IR as
expected.

Reviewed By: JonChesterfield, ronlieb

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

Change-Id: I10c0127ab7357787769fdf9a2edd4b3071e790a1

Added: 


Modified: 
clang/lib/Driver/ToolChains/Clang.cpp
clang/test/Driver/amdgpu-openmp-toolchain.c

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index 1b2c5b0de73da..061b578cc6ff7 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -4394,7 +4394,13 @@ void Clang::ConstructJob(Compilation , const JobAction 
,
   CmdArgs.push_back("-emit-llvm");
 } else if (JA.getType() == types::TY_LLVM_BC ||
JA.getType() == types::TY_LTO_BC) {
-  CmdArgs.push_back("-emit-llvm-bc");
+  // Emit textual llvm IR for AMDGPU offloading for -emit-llvm -S
+  if (Triple.isAMDGCN() && IsOpenMPDevice && Args.hasArg(options::OPT_S) &&
+  Args.hasArg(options::OPT_emit_llvm)) {
+CmdArgs.push_back("-emit-llvm");
+  } else {
+CmdArgs.push_back("-emit-llvm-bc");
+  }
 } else if (JA.getType() == types::TY_IFS ||
JA.getType() == types::TY_IFS_CPP) {
   StringRef ArgStr =

diff  --git a/clang/test/Driver/amdgpu-openmp-toolchain.c 
b/clang/test/Driver/amdgpu-openmp-toolchain.c
index 5f2bdff549607..cee9797af281a 100644
--- a/clang/test/Driver/amdgpu-openmp-toolchain.c
+++ b/clang/test/Driver/amdgpu-openmp-toolchain.c
@@ -6,7 +6,7 @@
 // verify the tools invocations
 // CHECK: clang{{.*}}"-cc1" "-triple" "x86_64-unknown-linux-gnu"{{.*}}"-x" 
"c"{{.*}}
 // CHECK: clang{{.*}}"-cc1" "-triple" "x86_64-unknown-linux-gnu"{{.*}}"-x" 
"ir"{{.*}}
-// CHECK: clang{{.*}}"-cc1"{{.*}}"-triple" 
"amdgcn-amd-amdhsa"{{.*}}"-target-cpu" "gfx906" "-fcuda-is-device" 
"-mlink-builtin-bitcode"{{.*}}libomptarget-amdgcn-gfx906.bc"{{.*}}
+// CHECK: clang{{.*}}"-cc1"{{.*}}"-triple" 
"amdgcn-amd-amdhsa"{{.*}}"-emit-llvm-bc"{{.*}}"-target-cpu" "gfx906" 
"-fcuda-is-device"{{.*}}"-mlink-builtin-bitcode"{{.*}}libomptarget-amdgcn-gfx906.bc"{{.*}}
 // CHECK: llvm-link{{.*}}"-o" 
"{{.*}}amdgpu-openmp-toolchain-{{.*}}-gfx906-linked-{{.*}}.bc"
 // CHECK: llc{{.*}}amdgpu-openmp-toolchain-{{.*}}-gfx906-linked-{{.*}}.bc" 
"-mtriple=amdgcn-amd-amdhsa" "-mcpu=gfx906" "-filetype=obj" 
"-o"{{.*}}amdgpu-openmp-toolchain-{{.*}}-gfx906-{{.*}}.o"
 // CHECK: lld{{.*}}"-flavor" "gnu" "--no-undefined" "-shared" 
"-o"{{.*}}amdgpu-openmp-toolchain-{{.*}}.out" 
"{{.*}}amdgpu-openmp-toolchain-{{.*}}-gfx906-{{.*}}.o"
@@ -71,3 +71,6 @@
 // CHECK-C: "x86_64-unknown-linux-gnu" - "clang"
 // CHECK-C: "x86_64-unknown-linux-gnu" - "clang::as"
 // CHECK-C: "x86_64-unknown-linux-gnu" - "offload bundler"
+
+// RUN:   %clang -### --target=x86_64-unknown-linux-gnu -emit-llvm -S -fopenmp 
-fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target=amdgcn-amd-amdhsa 
-march=gfx803 -nogpulib %s 2>&1 | FileCheck %s --check-prefix=CHECK-EMIT-LLVM-IR
+// CHECK-EMIT-LLVM-IR: clang{{.*}}"-cc1"{{.*}}"-triple" 
"amdgcn-amd-amdhsa"{{.*}}"-emit-llvm"



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

[PATCH] D102065: [AMDGPU][OpenMP] Emit textual IR for -emit-llvm -S

[Pushpinder Singh via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG10c779d2065f: [AMDGPU][OpenMP] Emit textual IR for 
-emit-llvm -S (authored by pdhaliwal).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102065

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/amdgpu-openmp-toolchain.c


Index: clang/test/Driver/amdgpu-openmp-toolchain.c
===
--- clang/test/Driver/amdgpu-openmp-toolchain.c
+++ clang/test/Driver/amdgpu-openmp-toolchain.c
@@ -6,7 +6,7 @@
 // verify the tools invocations
 // CHECK: clang{{.*}}"-cc1" "-triple" "x86_64-unknown-linux-gnu"{{.*}}"-x" 
"c"{{.*}}
 // CHECK: clang{{.*}}"-cc1" "-triple" "x86_64-unknown-linux-gnu"{{.*}}"-x" 
"ir"{{.*}}
-// CHECK: clang{{.*}}"-cc1"{{.*}}"-triple" 
"amdgcn-amd-amdhsa"{{.*}}"-target-cpu" "gfx906" "-fcuda-is-device" 
"-mlink-builtin-bitcode"{{.*}}libomptarget-amdgcn-gfx906.bc"{{.*}}
+// CHECK: clang{{.*}}"-cc1"{{.*}}"-triple" 
"amdgcn-amd-amdhsa"{{.*}}"-emit-llvm-bc"{{.*}}"-target-cpu" "gfx906" 
"-fcuda-is-device"{{.*}}"-mlink-builtin-bitcode"{{.*}}libomptarget-amdgcn-gfx906.bc"{{.*}}
 // CHECK: llvm-link{{.*}}"-o" 
"{{.*}}amdgpu-openmp-toolchain-{{.*}}-gfx906-linked-{{.*}}.bc"
 // CHECK: llc{{.*}}amdgpu-openmp-toolchain-{{.*}}-gfx906-linked-{{.*}}.bc" 
"-mtriple=amdgcn-amd-amdhsa" "-mcpu=gfx906" "-filetype=obj" 
"-o"{{.*}}amdgpu-openmp-toolchain-{{.*}}-gfx906-{{.*}}.o"
 // CHECK: lld{{.*}}"-flavor" "gnu" "--no-undefined" "-shared" 
"-o"{{.*}}amdgpu-openmp-toolchain-{{.*}}.out" 
"{{.*}}amdgpu-openmp-toolchain-{{.*}}-gfx906-{{.*}}.o"
@@ -71,3 +71,6 @@
 // CHECK-C: "x86_64-unknown-linux-gnu" - "clang"
 // CHECK-C: "x86_64-unknown-linux-gnu" - "clang::as"
 // CHECK-C: "x86_64-unknown-linux-gnu" - "offload bundler"
+
+// RUN:   %clang -### --target=x86_64-unknown-linux-gnu -emit-llvm -S -fopenmp 
-fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target=amdgcn-amd-amdhsa 
-march=gfx803 -nogpulib %s 2>&1 | FileCheck %s --check-prefix=CHECK-EMIT-LLVM-IR
+// CHECK-EMIT-LLVM-IR: clang{{.*}}"-cc1"{{.*}}"-triple" 
"amdgcn-amd-amdhsa"{{.*}}"-emit-llvm"
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -4394,7 +4394,13 @@
   CmdArgs.push_back("-emit-llvm");
 } else if (JA.getType() == types::TY_LLVM_BC ||
JA.getType() == types::TY_LTO_BC) {
-  CmdArgs.push_back("-emit-llvm-bc");
+  // Emit textual llvm IR for AMDGPU offloading for -emit-llvm -S
+  if (Triple.isAMDGCN() && IsOpenMPDevice && Args.hasArg(options::OPT_S) &&
+  Args.hasArg(options::OPT_emit_llvm)) {
+CmdArgs.push_back("-emit-llvm");
+  } else {
+CmdArgs.push_back("-emit-llvm-bc");
+  }
 } else if (JA.getType() == types::TY_IFS ||
JA.getType() == types::TY_IFS_CPP) {
   StringRef ArgStr =


Index: clang/test/Driver/amdgpu-openmp-toolchain.c
===
--- clang/test/Driver/amdgpu-openmp-toolchain.c
+++ clang/test/Driver/amdgpu-openmp-toolchain.c
@@ -6,7 +6,7 @@
 // verify the tools invocations
 // CHECK: clang{{.*}}"-cc1" "-triple" "x86_64-unknown-linux-gnu"{{.*}}"-x" "c"{{.*}}
 // CHECK: clang{{.*}}"-cc1" "-triple" "x86_64-unknown-linux-gnu"{{.*}}"-x" "ir"{{.*}}
-// CHECK: clang{{.*}}"-cc1"{{.*}}"-triple" "amdgcn-amd-amdhsa"{{.*}}"-target-cpu" "gfx906" "-fcuda-is-device" "-mlink-builtin-bitcode"{{.*}}libomptarget-amdgcn-gfx906.bc"{{.*}}
+// CHECK: clang{{.*}}"-cc1"{{.*}}"-triple" "amdgcn-amd-amdhsa"{{.*}}"-emit-llvm-bc"{{.*}}"-target-cpu" "gfx906" "-fcuda-is-device"{{.*}}"-mlink-builtin-bitcode"{{.*}}libomptarget-amdgcn-gfx906.bc"{{.*}}
 // CHECK: llvm-link{{.*}}"-o" "{{.*}}amdgpu-openmp-toolchain-{{.*}}-gfx906-linked-{{.*}}.bc"
 // CHECK: llc{{.*}}amdgpu-openmp-toolchain-{{.*}}-gfx906-linked-{{.*}}.bc" "-mtriple=amdgcn-amd-amdhsa" "-mcpu=gfx906" "-filetype=obj" "-o"{{.*}}amdgpu-openmp-toolchain-{{.*}}-gfx906-{{.*}}.o"
 // CHECK: lld{{.*}}"-flavor" "gnu" "--no-undefined" "-shared" "-o"{{.*}}amdgpu-openmp-toolchain-{{.*}}.out" "{{.*}}amdgpu-openmp-toolchain-{{.*}}-gfx906-{{.*}}.o"
@@ -71,3 +71,6 @@
 // CHECK-C: "x86_64-unknown-linux-gnu" - "clang"
 // CHECK-C: "x86_64-unknown-linux-gnu" - "clang::as"
 // CHECK-C: "x86_64-unknown-linux-gnu" - "offload bundler"
+
+// RUN:   %clang -### --target=x86_64-unknown-linux-gnu -emit-llvm -S -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target=amdgcn-amd-amdhsa -march=gfx803 -nogpulib %s 2>&1 | FileCheck %s --check-prefix=CHECK-EMIT-LLVM-IR
+// CHECK-EMIT-LLVM-IR: clang{{.*}}"-cc1"{{.*}}"-triple" "amdgcn-amd-amdhsa"{{.*}}"-emit-llvm"
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- 

[PATCH] D102361: [OpenMP] Add Module metadata for OpenMP compilation

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert added a comment.

tests missing.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102361

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

[PATCH] D102288: [HWASan] Add -fsanitize=lam flag and enable HWASan to use it.

[Evgenii Stepanov via Phabricator via cfe-commits]

eugenis added inline comments.



Comment at: clang/include/clang/Basic/Sanitizers.def:55-59
+// Utilize Intel LAM in sanitizers.  Currently only used in combination with
+// -fsanitize=hwaddress.  This is an experimental flag which may be removed in
+// the future.
+// TODO: Use -mlam instead, if/when it is supported by clang.
+SANITIZER("lam", LAM)

vitalybuka wrote:
> morehouse wrote:
> > vitalybuka wrote:
> > > if it's experimental, why not just "-fsanitize=hwaddress -mllvm 
> > > -havasan-lam=1" ?
> > Well, `-mllvm` indicates a flag for LLVM, but we need to change the Clang 
> > behavior to link with the LAM-enabled HWASan runtime.  It seems to me that 
> > we should use a flag directed to Clang for this.
> > 
> > Maybe it's possible to parse the `-mllvm` flag before the point where we 
> > need to choose a runtime (I'm not sure), but it seems simpler to do it this 
> > way.
> I see, I expected you convince you to keep same runtime lib, but I see your 
> reasoning on the another patch.
> 
> What do you thing about still keeping it hwasan and add hwasan internal flag 
> like we added for asan
> e.g. -fsanitize-hwasan-use-lam=1. Later when -mlam is available we will drop 
> this flag.
> 
I agree, this is not a new "sanitizer", just a different kind of hwasan.

Can we simply add "-mlam" right now, with the single purpose of selecting the 
new hwasan mode? It can grow more functionality later.



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102288

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

[PATCH] D102374: [clang][Fuchsia] Turn on relative-vtables by default for Fuchsia

[Leonard Chan via Phabricator via cfe-commits]

leonardchan created this revision.
leonardchan added a project: clang.
Herald added subscribers: dang, phosek.
leonardchan requested review of this revision.

All fuchsia targets will now use the relative-vtables ABI by default.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D102374

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/CodeGenCXX/RelativeVTablesABI/available_externally-vtable.cpp
  
clang/test/CodeGenCXX/RelativeVTablesABI/child-inheritted-from-parent-in-comdat.cpp
  clang/test/CodeGenCXX/RelativeVTablesABI/child-vtable-in-comdat.cpp
  clang/test/CodeGenCXX/RelativeVTablesABI/cross-translation-unit-1.cpp
  clang/test/CodeGenCXX/RelativeVTablesABI/cross-translation-unit-2.cpp
  clang/test/CodeGenCXX/RelativeVTablesABI/diamond-inheritance.cpp
  clang/test/CodeGenCXX/RelativeVTablesABI/diamond-virtual-inheritance.cpp
  clang/test/CodeGenCXX/RelativeVTablesABI/dynamic-cast.cpp
  clang/test/CodeGenCXX/RelativeVTablesABI/inheritted-virtual-function.cpp
  clang/test/CodeGenCXX/RelativeVTablesABI/inlined-key-function.cpp
  clang/test/CodeGenCXX/RelativeVTablesABI/member-function-pointer.cpp
  clang/test/CodeGenCXX/RelativeVTablesABI/multiple-inheritance.cpp
  clang/test/CodeGenCXX/RelativeVTablesABI/no-alias-when-dso-local.cpp
  clang/test/CodeGenCXX/RelativeVTablesABI/override-pure-virtual-method.cpp
  clang/test/CodeGenCXX/RelativeVTablesABI/overriden-virtual-function.cpp
  clang/test/CodeGenCXX/RelativeVTablesABI/relative-vtables-flag.cpp
  clang/test/CodeGenCXX/RelativeVTablesABI/simple-vtable-definition.cpp
  clang/test/CodeGenCXX/RelativeVTablesABI/thunk-mangling.cpp
  clang/test/CodeGenCXX/RelativeVTablesABI/type-info.cpp
  clang/test/CodeGenCXX/RelativeVTablesABI/vbase-offset.cpp
  clang/test/CodeGenCXX/RelativeVTablesABI/virtual-function-call.cpp
  clang/test/CodeGenCXX/RelativeVTablesABI/vtable-hidden-when-in-comdat.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
@@ -151,8 +151,10 @@
 
 // Verify that virtual calls to destructors are not marked with a 'returned'
 // this parameter at the call site...
-// CHECKARM,CHECKFUCHSIA: [[VFN:%.*]] = getelementptr inbounds %class.E* (%class.E*)*, %class.E* (%class.E*)**
-// CHECKARM,CHECKFUCHSIA: [[THUNK:%.*]] = load %class.E* (%class.E*)*, %class.E* (%class.E*)** [[VFN]]
+// CHECKARM: [[VFN:%.*]] = getelementptr inbounds %class.E* (%class.E*)*, %class.E* (%class.E*)**
+// CHECKARM: [[THUNK:%.*]] = load %class.E* (%class.E*)*, %class.E* (%class.E*)** [[VFN]]
+// CHECKFUCHSIA: [[THUNK_I8:%.*]] = call i8* @llvm.load.relative.i32(i8* {{.*}}, i32 0)
+// CHECKFUCHSIA: [[THUNK:%.*]] = bitcast i8* [[THUNK_I8]] to %class.E* (%class.E*)*
 // CHECKARM,CHECKFUCHSIA: call %class.E* [[THUNK]](%class.E* {{[^,]*}} %
 
 // ...but static calls create declarations with 'returned' this
Index: clang/test/CodeGenCXX/RelativeVTablesABI/vtable-hidden-when-in-comdat.cpp
===
--- clang/test/CodeGenCXX/RelativeVTablesABI/vtable-hidden-when-in-comdat.cpp
+++ clang/test/CodeGenCXX/RelativeVTablesABI/vtable-hidden-when-in-comdat.cpp
@@ -2,7 +2,7 @@
 // is not dso_local. The vtable will need to be hidden and not private so it can
 // be used as acomdat key signature.
 
-// RUN: %clang_cc1 %s -triple=aarch64-unknown-fuchsia -S -o - -emit-llvm -fexperimental-relative-c++-abi-vtables | FileCheck %s
+// RUN: %clang_cc1 %s -triple=aarch64-unknown-fuchsia -S -o - -emit-llvm | FileCheck %s
 
 // CHECK: @_ZTV1B.local = linkonce_odr hidden unnamed_addr constant
 // CHECK: @_ZTV1B = linkonce_odr unnamed_addr alias { [3 x i32] }, { [3 x i32] }* @_ZTV1B.local
Index: clang/test/CodeGenCXX/RelativeVTablesABI/virtual-function-call.cpp
===
--- clang/test/CodeGenCXX/RelativeVTablesABI/virtual-function-call.cpp
+++ clang/test/CodeGenCXX/RelativeVTablesABI/virtual-function-call.cpp
@@ -1,6 +1,6 @@
 // Check that we call llvm.load.relative() on a vtable function call.
 
-// RUN: %clang_cc1 %s -triple=aarch64-unknown-fuchsia -O3 -S -o - -emit-llvm -fexperimental-relative-c++-abi-vtables | FileCheck %s
+// RUN: %clang_cc1 %s -triple=aarch64-unknown-fuchsia -O3 -S -o - -emit-llvm | FileCheck %s
 
 // CHECK:  define{{.*}} void @_Z5A_fooP1A(%class.A* %a) local_unnamed_addr
 // CHECK-NEXT: entry:
Index: clang/test/CodeGenCXX/RelativeVTablesABI/vbase-offset.cpp
===
--- clang/test/CodeGenCXX/RelativeVTablesABI/vbase-offset.cpp
+++ clang/test/CodeGenCXX/RelativeVTablesABI/vbase-offset.cpp
@@ -1,7 +1,7 @@
 // Check that the pointer adjustment from the virtual base 

[PATCH] D102339: [clang] On Windows, ignore case and separators when discarding duplicate dependency file paths.

[Alexandre Ganea via Phabricator via cfe-commits]

aganea added inline comments.



Comment at: clang/lib/Frontend/DependencyFile.cpp:145
+  StringRef SearchPath;
+#ifdef _WIN32
+  // Make the search insensitive to case and separators.

amccarth wrote:
> rnk wrote:
> > I feel like this should somehow be a property of the input virtual 
> > filesystem: we should be able to ask the VFS to do the path 
> > canonicalization for us, or ask if the FS is case insensitive and do the 
> > lower-casing if so.
> Additional complication:
> 
> Windows NTFS partitions can have case-sensitivity enabled on a per-directory 
> basis, so there is no single answer for the filesystem or even the host OS.  
> Granted, this is not yet a commonly used feature.
> 
> I wonder about the (also rarely used) case of cross compiling for a Linux 
> target on a Windows build machine.
> Windows NTFS partitions can have case-sensitivity enabled on a per-directory 
> basis, so there is no single answer for the filesystem or even the host OS. 
> Granted, this is not yet a commonly used feature.
I think case-sensitiveness was added for WSL, I'm not sure that feature would 
be used outside of that context. This would otherwise require quering the 
filesystem for the case of each directory component.

> I wonder about the (also rarely used) case of cross compiling for a Linux 
> target on a Windows build machine.
It's not that rare :) We do cross-compile all of our platforms from Windows, 
most of them are POSIX/Linux variants. This could become a problem although if 
we decided to share the dependency list accross systems, for example if we 
shared the cache artefacts (.OBJ files) between Windows and Linux bots. In 
which case a path renormalization would be necessary. The easiest solution for 
that purpose could be a case-insensitive FS on Linux and always execute the 
code that @saudi added in this patch. But that's not the goal right now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102339

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

[PATCH] D102288: [HWASan] Add -fsanitize=lam flag and enable HWASan to use it.

[Vitaly Buka via Phabricator via cfe-commits]

vitalybuka added inline comments.



Comment at: clang/include/clang/Basic/Sanitizers.def:55-59
+// Utilize Intel LAM in sanitizers.  Currently only used in combination with
+// -fsanitize=hwaddress.  This is an experimental flag which may be removed in
+// the future.
+// TODO: Use -mlam instead, if/when it is supported by clang.
+SANITIZER("lam", LAM)

morehouse wrote:
> vitalybuka wrote:
> > if it's experimental, why not just "-fsanitize=hwaddress -mllvm 
> > -havasan-lam=1" ?
> Well, `-mllvm` indicates a flag for LLVM, but we need to change the Clang 
> behavior to link with the LAM-enabled HWASan runtime.  It seems to me that we 
> should use a flag directed to Clang for this.
> 
> Maybe it's possible to parse the `-mllvm` flag before the point where we need 
> to choose a runtime (I'm not sure), but it seems simpler to do it this way.
I see, I expected you convince you to keep same runtime lib, but I see your 
reasoning on the another patch.

What do you thing about still keeping it hwasan and add hwasan internal flag 
like we added for asan
e.g. -fsanitize-hwasan-use-lam=1. Later when -mlam is available we will drop 
this flag.



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102288

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

[PATCH] D102339: [clang] On Windows, ignore case and separators when discarding duplicate dependency file paths.

[Adrian McCarthy via Phabricator via cfe-commits]

amccarth added inline comments.



Comment at: clang/lib/Frontend/DependencyFile.cpp:145
+  StringRef SearchPath;
+#ifdef _WIN32
+  // Make the search insensitive to case and separators.

rnk wrote:
> I feel like this should somehow be a property of the input virtual 
> filesystem: we should be able to ask the VFS to do the path canonicalization 
> for us, or ask if the FS is case insensitive and do the lower-casing if so.
Additional complication:

Windows NTFS partitions can have case-sensitivity enabled on a per-directory 
basis, so there is no single answer for the filesystem or even the host OS.  
Granted, this is not yet a commonly used feature.

I wonder about the (also rarely used) case of cross compiling for a Linux 
target on a Windows build machine.



Comment at: clang/lib/Frontend/DependencyFile.cpp:149
+  std::replace(TmpPath.begin(), TmpPath.end(), '/', '\\');
+  std::transform(TmpPath.begin(), TmpPath.end(), TmpPath.begin(), ::tolower);
+  SearchPath = TmpPath.str();

If `::tolower` is the same as `std::tolower` (e.g., if the header declared it 
in both the `std` and global namespaces), and if the locale is the default "C" 
locale, then this downcases just the 26 ASCII capital letters.  Windows 
considers more characters when it's wearing its case-blinding glasses. 
 For example, the pre-composed `U+00C1 LATIN CAPITAL LETTER A WITH ACUTE 
ACCENT` and `U+00E1 LATIN SMALL LETTER A WITH ACUTE ACCENT` characters match in 
case-blind file names.

I'll concede that this is probably an existing problem elsewhere in LLVM, so it 
may not be a high enough priority to worry about right now.  It just 
underscores the need for better centralized handling of paths and file names, 
so that we'll have a handle these sorts of problems if/when we ever accept that 
Windows is not Posix with backward slashes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102339

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

[PATCH] D102369: [ASTMatchers][NFC] Remove runtime checks where compile time is sufficient

[Nathan James via Phabricator via cfe-commits]

njames93 created this revision.
njames93 added reviewers: klimek, aaron.ballman, alexfh.
njames93 requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Some polymorphic matchers use dyn_cast in cases where we know the type from the 
TemplateParameter.
Using type_traits we can remove the need for dyn_cast and let the template 
instantiation handle everything.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D102369

Files:
  clang/include/clang/ASTMatchers/ASTMatchers.h

Index: clang/include/clang/ASTMatchers/ASTMatchers.h
===
--- clang/include/clang/ASTMatchers/ASTMatchers.h
+++ clang/include/clang/ASTMatchers/ASTMatchers.h
@@ -3167,8 +3167,9 @@
 AST_POLYMORPHIC_SUPPORTED_TYPES(CXXRecordDecl, ObjCInterfaceDecl),
 internal::Matcher, Base) {
   // Check if the node is a C++ struct/union/class.
-  if (const auto *RD = dyn_cast())
-return Finder->classIsDerivedFrom(RD, Base, Builder, /*Directly=*/false);
+  if (std::is_convertible::value)
+return Finder->classIsDerivedFrom(cast(), Base, Builder,
+  /*Directly=*/false);
 
   // The node must be an Objective-C class.
   const auto *InterfaceDecl = cast();
@@ -3186,8 +3187,9 @@
 
   const auto M = isDerivedFrom(hasName(BaseName));
 
-  if (const auto *RD = dyn_cast())
-return Matcher(M).matches(*RD, Finder, Builder);
+  if (std::is_convertible::value)
+return Matcher(M).matches(cast(Node), Finder,
+ Builder);
 
   const auto *InterfaceDecl = cast();
   return Matcher(M).matches(*InterfaceDecl, Finder, Builder);
@@ -3241,8 +3243,9 @@
 internal::Matcher, Base, 0) {
   const auto M = anyOf(Base, isDerivedFrom(Base));
 
-  if (const auto *RD = dyn_cast())
-return Matcher(M).matches(*RD, Finder, Builder);
+  if (std::is_convertible::value)
+return Matcher(M).matches(cast(Node), Finder,
+ Builder);
 
   const auto *InterfaceDecl = cast();
   return Matcher(M).matches(*InterfaceDecl, Finder, Builder);
@@ -3259,8 +3262,9 @@
 
   const auto M = isSameOrDerivedFrom(hasName(BaseName));
 
-  if (const auto *RD = dyn_cast())
-return Matcher(M).matches(*RD, Finder, Builder);
+  if (std::is_convertible::value)
+return Matcher(M).matches(cast(Node), Finder,
+ Builder);
 
   const auto *InterfaceDecl = cast();
   return Matcher(M).matches(*InterfaceDecl, Finder, Builder);
@@ -3292,8 +3296,9 @@
 AST_POLYMORPHIC_SUPPORTED_TYPES(CXXRecordDecl, ObjCInterfaceDecl),
 internal::Matcher, Base, 0) {
   // Check if the node is a C++ struct/union/class.
-  if (const auto *RD = dyn_cast())
-return Finder->classIsDerivedFrom(RD, Base, Builder, /*Directly=*/true);
+  if (std::is_convertible::value)
+return Finder->classIsDerivedFrom(cast(), Base, Builder,
+  /*Directly=*/true);
 
   // The node must be an Objective-C class.
   const auto *InterfaceDecl = cast();
@@ -3310,8 +3315,9 @@
 return false;
   const auto M = isDirectlyDerivedFrom(hasName(BaseName));
 
-  if (const auto *RD = dyn_cast())
-return Matcher(M).matches(*RD, Finder, Builder);
+  if (std::is_convertible::value)
+return Matcher(M).matches(cast(Node), Finder,
+ Builder);
 
   const auto *InterfaceDecl = cast();
   return Matcher(M).matches(*InterfaceDecl, Finder, Builder);
@@ -6179,12 +6185,14 @@
 AST_POLYMORPHIC_SUPPORTED_TYPES(MemberExpr, UnresolvedMemberExpr,
 CXXDependentScopeMemberExpr),
 internal::Matcher, InnerMatcher) {
-  if (const auto *E = dyn_cast())
-if (E->isImplicitAccess())
+  if (std::is_convertible::value) {
+if (cast()->isImplicitAccess())
   return false;
-  if (const auto *E = dyn_cast())
-if (E->isImplicitAccess())
+  } else if (std::is_convertible::value) {
+if (cast()->isImplicitAccess())
   return false;
+  }
   return InnerMatcher.matches(*Node.getBase(), Finder, Builder);
 }
 
@@ -7345,10 +7353,10 @@
 FunctionDecl)) {
   // This is required because the spelling of the function used to determine
   // whether inline is specified or not differs between the polymorphic types.
-  if (const auto *FD = dyn_cast())
-return FD->isInlineSpecified();
-  else if (const auto *NSD = dyn_cast())
-return NSD->isInline();
+  if (std::is_convertible::value)
+return cast()->isInlineSpecified();
+  else if (std::is_convertible::value)
+return cast()->isInline();
   llvm_unreachable("Not a valid polymorphic type");
 }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D101156: [Clang] Support a user-defined __dso_handle

[Andrew Savonichev via Phabricator via cfe-commits]

asavonic added a comment.

In D101156#2724789 , @rjmccall wrote:

> What's the crash exactly/  Is IRGen just unhappy about processing the user 
> definition when we've generated a declaration with a different type?  Because 
> we're already supposed to be being cautious about this.

Hi John. Sorry for the late reply.

  class a {
  public:
~a();
  } b;
  void *__dso_handle = &__dso_handle;

This code code causes a crash because the compiler first generates a
__dso_handle with i8 type:

  @__dso_handle = external dso_local global i8

... and then reaches the explicit definition of it with a pointer type and a
pointer initializer, and tries to generate this instead:

  @__dso_handle = hidden global i8* bitcast (i8** @__dso_handle to i8*), align 8

Since __dso_handle already exists in the module, it must be replaced because the
initializer has an incompatible type.

There is indeed some handling for this case in EmitGlobalVarDefinition, but it
does not work correctly when the initializer is a pointer to the variable
itself. Specifically, the Init variable in EmitGlobalVarDefinition becomes
stale:

  p Init->dump()
   = hidden global i8 

The current patch avoids this problem by having two distinct globals, but maybe
it is better to fix EmitGlobalVarDefinition instead? Is it supposed to handle
such case?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101156

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

[PATCH] D102270: [CUDA][HIP] Fix device template variables

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl closed this revision.
yaxunl marked an inline comment as done.
yaxunl added inline comments.



Comment at: clang/lib/Sema/SemaExpr.cpp:17145
 };
-if (Var && Var->hasGlobalStorage() && !IsEmittedOnDeviceSide(Var)) {
-  SemaRef.targetDiag(Loc, diag::err_ref_bad_target)
-  << /*host*/ 2 << /*variable*/ 1 << Var << Target;
+if (Var && Var->hasGlobalStorage()) {
+  if (!IsEmittedOnDeviceSide(Var)) {

tra wrote:
> Revisiting my comment from https://reviews.llvm.org/D102237#inline-967732
> 
> I think this can be combined with the `if (SemaRef.LangOpts.CUDA)` above.
> 
> Unless I'm missing something obvious, what we have now is
> ```
> if (SemaRef.LangOpts.CUDA) {
>   
>   if (Var && Var->hasGlobalStorage()) {
> 
>   }
> }
> ```
> 
> You've mentioned that they can't be combined because of an `else`, but 
> there's no else in the `if (Var && Var->hasGlobalStorage()) ` as far as I can 
> see, and `` could be moved inside it.
> 
You are right. I missed `if (Var && Var->hasGlobalStorage())`. The patch has 
been committed. Will make the change by a commit directly. Thanks.


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

https://reviews.llvm.org/D102270

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

[PATCH] D99683: [HIP] Support ThinLTO

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl updated this revision to Diff 344949.
yaxunl marked an inline comment as done.
yaxunl added a comment.

Revised by Teresa's comments


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

https://reviews.llvm.org/D99683

Files:
  clang/include/clang/Driver/Driver.h
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/HIP.cpp
  clang/test/Driver/hip-options.hip
  llvm/lib/Transforms/IPO/FunctionImport.cpp
  llvm/test/Transforms/FunctionImport/Inputs/funcimport.ll
  llvm/test/Transforms/FunctionImport/Inputs/noinline.ll
  llvm/test/Transforms/FunctionImport/adjustable_threshold.ll
  llvm/test/Transforms/FunctionImport/funcimport.ll
  llvm/test/Transforms/FunctionImport/noinline.ll

Index: llvm/test/Transforms/FunctionImport/noinline.ll
===
--- /dev/null
+++ llvm/test/Transforms/FunctionImport/noinline.ll
@@ -0,0 +1,23 @@
+; Do setup work for all below tests: generate bitcode and combined index
+; RUN: opt -module-summary %s -o %t.main.bc
+; RUN: opt -module-summary %p/Inputs/noinline.ll -o %t.inputs.noinline.bc
+; RUN: llvm-lto -thinlto -o %t.summary %t.main.bc %t.inputs.noinline.bc
+
+; Attempt the import now, ensure below that file containing noinline
+; is not imported by default but imported with -force-import-all.
+
+; RUN: opt -function-import -summary-file %t.summary.thinlto.bc %t.main.bc -S 2>&1 \
+; RUN:   | FileCheck -check-prefix=NOIMPORT %s
+; RUN: opt -function-import -force-import-all -summary-file %t.summary.thinlto.bc \
+; RUN:   %t.main.bc -S 2>&1 | FileCheck -check-prefix=IMPORT %s
+
+define i32 @main() #0 {
+entry:
+  %f = alloca i64, align 8
+  call void @foo(i64* %f)
+  ret i32 0
+}
+
+; NOIMPORT: declare void @foo(i64*)
+; IMPORT: define available_externally void @foo
+declare void @foo(i64*) #1
Index: llvm/test/Transforms/FunctionImport/funcimport.ll
===
--- llvm/test/Transforms/FunctionImport/funcimport.ll
+++ llvm/test/Transforms/FunctionImport/funcimport.ll
@@ -1,3 +1,5 @@
+; REQUIRES: x86-registered-target
+
 ; Do setup work for all below tests: generate bitcode and combined index
 ; RUN: opt -module-summary %s -o %t.bc
 ; RUN: opt -module-summary %p/Inputs/funcimport.ll -o %t2.bc
@@ -15,6 +17,13 @@
 ; RUN: opt -function-import -enable-import-metadata  -summary-file %t3.thinlto.bc %t.bc -import-instr-limit=5 -S | FileCheck %s --check-prefix=CHECK --check-prefix=INSTLIM5
 ; INSTLIM5-NOT: @staticfunc.llvm.
 
+; Test force import all
+; RUN: llvm-lto -thinlto-action=run -force-import-all %t.bc %t2.bc 2>&1 \
+; RUN:  | FileCheck %s --check-prefix=IMPORTALL
+; IMPORTALL-DAG: Error importing module: Failed to import function weakalias due to InterposableLinkage
+
+target datalayout = "e-m:o-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
+target triple = "x86_64-apple-macosx10.11.0"
 
 define i32 @main() #0 {
 entry:
Index: llvm/test/Transforms/FunctionImport/adjustable_threshold.ll
===
--- llvm/test/Transforms/FunctionImport/adjustable_threshold.ll
+++ llvm/test/Transforms/FunctionImport/adjustable_threshold.ll
@@ -11,7 +11,15 @@
 ; RUN: opt -function-import -summary-file %t3.thinlto.bc %t.bc -import-instr-limit=10 -import-instr-evolution-factor=0.5 -S | FileCheck %s --check-prefix=INSTLIM-PROGRESSIVE
 ; INSTLIM-PROGRESSIVE-NOT: call void @staticfunc
 
-
+; Test force import all
+; RUN: opt -function-import -summary-file %t3.thinlto.bc %t.bc \
+; RUN:  -import-instr-limit=1 -force-import-all -S \
+; RUN:  | FileCheck %s --check-prefix=IMPORTALL
+; IMPORTALL-DAG: define available_externally void @globalfunc1()
+; IMPORTALL-DAG: define available_externally void @trampoline()
+; IMPORTALL-DAG: define available_externally void @largefunction()
+; IMPORTALL-DAG: define available_externally hidden void @staticfunc2.llvm.0()
+; IMPORTALL-DAG: define available_externally void @globalfunc2()
 
 declare void @globalfunc1()
 declare void @globalfunc2()
Index: llvm/test/Transforms/FunctionImport/Inputs/noinline.ll
===
--- /dev/null
+++ llvm/test/Transforms/FunctionImport/Inputs/noinline.ll
@@ -0,0 +1,8 @@
+define void @foo(i64* %v) #0 {
+entry:
+  %v.addr = alloca i64*, align 8
+  store i64* %v, i64** %v.addr, align 8
+  ret void
+}
+
+attributes #0 = { noinline }
\ No newline at end of file
Index: llvm/test/Transforms/FunctionImport/Inputs/funcimport.ll
===
--- llvm/test/Transforms/FunctionImport/Inputs/funcimport.ll
+++ llvm/test/Transforms/FunctionImport/Inputs/funcimport.ll
@@ -1,3 +1,6 @@
+target datalayout = "e-m:o-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
+target triple = "x86_64-apple-macosx10.11.0"
+
 @globalvar = global i32 1, 

[PATCH] D99683: [HIP] Support ThinLTO

[Yaxun Liu via Phabricator via cfe-commits]

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



Comment at: llvm/lib/Transforms/IPO/FunctionImport.cpp:496
 dbgs() << "ignored! No qualifying callee with summary found.\n");
 continue;
   }

tejohnson wrote:
> yaxunl wrote:
> > tejohnson wrote:
> > > Probably better to issue an error here with the import failure reason?
> > My understanding is that the import failure reason is only available if 
> > PrintImportFailures is enabled. Also it can only print the GUID and can not 
> > print the failed callee name since it is not available, therefore the 
> > information is cryptic. It seems to me the current error msg at line 1332 
> > is more suitable for common users. For compiler developers, they can enable 
> > PrintImportFailures and see the reason of failed imports.
> selectCallee always sets the Reason. And we have the name in addition to the 
> GUID in normal circumstances (linking from modules). It would only not be 
> available in certain debugging situations (e.g. linking from an existing 
> combined module with llvm-lto). Also, by failing here, you don't need to wait 
> until the LTO backends to issue the error, so it fails a little earlier.
I see. Will do.


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

https://reviews.llvm.org/D99683

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

[PATCH] D101640: [clang][patch] Add support for option -fextend-arguments={32,64}: widen integer arguments to int64 in unprototyped function calls

[Melanie Blower via Phabricator via cfe-commits]

mibintc added inline comments.



Comment at: clang/test/CodeGen/extend-arg-64.c:19
+
+int vararg(int, ...);
+

aaron.ballman wrote:
> Can you also add a test for K C functions? e.g., `int knr();` `sum = 
> knr(sum, u32, s32, u16, s16, u8, s8);`
> 
> Also, can you show what happens when passing a `long long` and an `_ExtInt`
Yes I can add those tests.  BTW the _ExtInt types are not "promotable" 
therefore the UsualUnaryConversions have no effect. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101640

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

[PATCH] D97085: [OpenMP] libomp: implement OpenMP 5.1 inoutset task dependence type

[Andrey Churbanov via Phabricator via cfe-commits]

AndreyChurbanov updated this revision to Diff 344939.
AndreyChurbanov added a comment.

Addressed review comments.
Fixed tests.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97085

Files:
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/test/OpenMP/depobj_codegen.cpp
  clang/test/OpenMP/target_enter_data_depend_codegen.cpp
  clang/test/OpenMP/target_exit_data_depend_codegen.cpp
  clang/test/OpenMP/target_update_depend_codegen.cpp
  clang/test/OpenMP/task_codegen.c
  clang/test/OpenMP/task_codegen.cpp
  openmp/runtime/src/kmp.h
  openmp/runtime/src/kmp_taskdeps.cpp
  openmp/runtime/src/kmp_taskdeps.h
  openmp/runtime/test/tasking/bug_nested_proxy_task.c
  openmp/runtime/test/tasking/bug_proxy_task_dep_waiting.c
  openmp/runtime/test/tasking/hidden_helper_task/common.h
  openmp/runtime/test/tasking/hidden_helper_task/depend.cpp
  openmp/runtime/test/tasking/hidden_helper_task/gtid.cpp
  openmp/runtime/test/tasking/omp51_task_dep_inoutset.c

Index: openmp/runtime/test/tasking/omp51_task_dep_inoutset.c
===
--- /dev/null
+++ openmp/runtime/test/tasking/omp51_task_dep_inoutset.c
@@ -0,0 +1,258 @@
+// RUN: %libomp-compile-and-run
+// RUN: %libomp-cxx-compile-and-run
+// UNSUPPORTED: gcc
+
+// Tests OMP 5.0 task dependences "mutexinoutset" and 5.1 "inoutset",
+// emulates compiler codegen for new dep kinds
+// Mutually exclusive tasks get same input dependency info array
+//
+// Task tree created:
+//  task0 - task1 (in)
+// \
+//task2 - task3 (inoutset)
+// /
+//  task3 - task4 (in)
+//   /
+//  task6 <-->task7  (mutexinoutset)
+//   \/
+//   task8 (in)
+//
+#include 
+#include 
+
+#ifdef _WIN32
+#include 
+#define mysleep(n) Sleep(n)
+#else
+#include 
+#define mysleep(n) usleep((n)*1000)
+#endif
+
+// to check the # of concurrent tasks (must be 1 for MTX, <3 for other kinds)
+static int volatile checker = 0;
+static int err = 0;
+#ifndef DELAY
+#define DELAY 100
+#endif
+
+// ---
+// internal data to emulate compiler codegen
+typedef struct DEP {
+  size_t addr;
+  size_t len;
+  int flags;
+} dep;
+typedef struct task {
+  void** shareds;
+  void* entry;
+  int part_id;
+  void* destr_thunk;
+  int priority;
+  long long device_id;
+  int f_priv;
+} task_t;
+#define TIED 1
+typedef int(*entry_t)(int, task_t*);
+typedef struct ID {
+  int reserved_1;
+  int flags;
+  int reserved_2;
+  int reserved_3;
+  char *psource;
+} id;
+// thunk routine for tasks with MTX dependency
+int thunk_m(int gtid, task_t* ptask) {
+  int th = omp_get_thread_num();
+  #pragma omp atomic
+++checker;
+  printf("task _%d, th %d\n", ptask->f_priv, th);
+  if (checker != 1) { // no more than 1 task at a time
+err++;
+printf("Error1, checker %d != 1\n", checker);
+  }
+  mysleep(DELAY);
+  if (checker != 1) { // no more than 1 task at a time
+err++;
+printf("Error2, checker %d != 1\n", checker);
+  }
+  #pragma omp atomic
+--checker;
+  return 0;
+}
+// thunk routine for tasks with inoutset dependency
+int thunk_s(int gtid, task_t* ptask) {
+  int th = omp_get_thread_num();
+  #pragma omp atomic
+++checker;
+  printf("task _%d, th %d\n", ptask->f_priv, th);
+  if (checker > 2) { // no more than 2 tasks concurrently
+err++;
+printf("Error1, checker %d > 2\n", checker);
+  }
+  mysleep(DELAY);
+  if (checker > 2) { // no more than 2 tasks concurrently
+err++;
+printf("Error2, checker %d > 2\n", checker);
+  }
+  #pragma omp atomic
+--checker;
+  return 0;
+}
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+int __kmpc_global_thread_num(id*);
+extern task_t* __kmpc_omp_task_alloc(id *loc, int gtid, int flags,
+ size_t sz, size_t shar, entry_t rtn);
+int
+__kmpc_omp_task_with_deps(id *loc, int gtid, task_t *task, int nd, dep *dep_lst,
+  int nd_noalias, dep *noalias_dep_lst);
+static id loc = {0, 2, 0, 0, ";file;func;0;0;;"};
+#ifdef __cplusplus
+} // extern "C"
+#endif
+// End of internal data
+// ---
+
+int main()
+{
+  int i1,i2,i3;
+  omp_set_num_threads(4);
+  omp_set_dynamic(0);
+  #pragma omp parallel
+  {
+#pragma omp single nowait
+{
+  dep sdep[2];
+  task_t *ptr;
+  int gtid = __kmpc_global_thread_num();
+  int t = omp_get_thread_num();
+  #pragma omp task depend(in: i1, i2)
+  { int th = omp_get_thread_num();
+printf("task 0_%d, th %d\n", t, th);
+#pragma omp atomic
+  ++checker;
+if (checker > 2) { // no more than 2 tasks concurrently
+  err++;
+  printf("Error1, checker %d > 2\n", checker);
+}
+mysleep(DELAY);
+if (checker > 2) { // no more than 2 tasks concurrently
+  

[PATCH] D96033: [clang-repl] Land initial infrastructure for incremental parsing

[Vassil Vassilev via Phabricator via cfe-commits]

v.g.vassilev updated this revision to Diff 344941.
v.g.vassilev added a comment.

clang-tidy and clang-format


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

https://reviews.llvm.org/D96033

Files:
  clang/include/clang/CodeGen/CodeGenAction.h
  clang/include/clang/Frontend/FrontendAction.h
  clang/include/clang/Interpreter/Interpreter.h
  clang/include/clang/Interpreter/Transaction.h
  clang/lib/CMakeLists.txt
  clang/lib/CodeGen/CodeGenAction.cpp
  clang/lib/Frontend/FrontendAction.cpp
  clang/lib/Interpreter/CMakeLists.txt
  clang/lib/Interpreter/IncrementalExecutor.cpp
  clang/lib/Interpreter/IncrementalExecutor.h
  clang/lib/Interpreter/IncrementalParser.cpp
  clang/lib/Interpreter/IncrementalParser.h
  clang/lib/Interpreter/Interpreter.cpp
  clang/test/CMakeLists.txt
  clang/test/Interpreter/execute.cpp
  clang/test/Interpreter/sanity.c
  clang/test/lit.cfg.py
  clang/tools/CMakeLists.txt
  clang/tools/clang-repl/CMakeLists.txt
  clang/tools/clang-repl/ClangRepl.cpp
  clang/unittests/CMakeLists.txt
  clang/unittests/CodeGen/CMakeLists.txt
  clang/unittests/CodeGen/IncrementalProcessingTest.cpp
  clang/unittests/Interpreter/CMakeLists.txt
  clang/unittests/Interpreter/IncrementalProcessingTest.cpp
  clang/unittests/Interpreter/InterpreterTest.cpp

Index: clang/unittests/Interpreter/InterpreterTest.cpp
===
--- /dev/null
+++ clang/unittests/Interpreter/InterpreterTest.cpp
@@ -0,0 +1,122 @@
+//===- unittests/Interpreter/InterpreterTest.cpp --- Interpreter tests ===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// Unit tests for Clang's Interpreter library.
+//
+//===--===//
+
+#include "clang/Interpreter/Interpreter.h"
+
+#include "clang/AST/Decl.h"
+#include "clang/AST/DeclGroup.h"
+#include "clang/Frontend/CompilerInstance.h"
+#include "clang/Frontend/TextDiagnosticPrinter.h"
+
+#include "llvm/ADT/ArrayRef.h"
+
+#include "gmock/gmock.h"
+#include "gtest/gtest.h"
+
+using namespace clang;
+
+namespace {
+using Args = std::vector;
+static std::unique_ptr
+createInterpreter(const Args  = {},
+  DiagnosticConsumer *Client = nullptr) {
+  Args ClangArgs = {"-Xclang", "-emit-llvm-only"};
+  ClangArgs.insert(ClangArgs.end(), ExtraArgs.begin(), ExtraArgs.end());
+  auto CI = cantFail(clang::IncrementalCompilerBuilder::create(ClangArgs));
+  if (Client)
+CI->getDiagnostics().setClient(Client, /*ShouldOwnClient=*/false);
+  return cantFail(clang::Interpreter::create(std::move(CI)));
+}
+
+TEST(InterpreterTest, Sanity) {
+  std::unique_ptr Interp = createInterpreter();
+  Transaction (cantFail(Interp->Parse("void g(); void g() {}")));
+  EXPECT_EQ(2U, R1.Decls.size());
+
+  Transaction (cantFail(Interp->Parse("int i;")));
+  EXPECT_EQ(1U, R2.Decls.size());
+}
+
+static std::string DeclToString(DeclGroupRef DGR) {
+  return llvm::cast(DGR.getSingleDecl())->getQualifiedNameAsString();
+}
+
+TEST(InterpreterTest, IncrementalInputTopLevelDecls) {
+  std::unique_ptr Interp = createInterpreter();
+  auto R1OrErr = Interp->Parse("int var1 = 42; int f() { return var1; }");
+  // gtest doesn't expand into explicit bool conversions.
+  EXPECT_TRUE(!!R1OrErr);
+  auto R1 = R1OrErr->Decls;
+  EXPECT_EQ(2U, R1.size());
+  EXPECT_EQ("var1", DeclToString(R1[0]));
+  EXPECT_EQ("f", DeclToString(R1[1]));
+
+  auto R2OrErr = Interp->Parse("int var2 = f();");
+  EXPECT_TRUE(!!R2OrErr);
+  auto R2 = R2OrErr->Decls;
+  EXPECT_EQ(1U, R2.size());
+  EXPECT_EQ("var2", DeclToString(R2[0]));
+}
+
+TEST(InterpreterTest, Errors) {
+  Args ExtraArgs = {"-Xclang", "-diagnostic-log-file", "-Xclang", "-"};
+
+  // Create the diagnostic engine with unowned consumer.
+  std::string DiagnosticOutput;
+  llvm::raw_string_ostream DiagnosticsOS(DiagnosticOutput);
+  auto DiagPrinter = std::make_unique(
+  DiagnosticsOS, new DiagnosticOptions());
+
+  auto Interp = createInterpreter(ExtraArgs, DiagPrinter.get());
+  auto Err = Interp->Parse("intentional_error v1 = 42; ").takeError();
+  using ::testing::HasSubstr;
+  EXPECT_THAT(DiagnosticsOS.str(),
+  HasSubstr("error: unknown type name 'intentional_error'"));
+  EXPECT_EQ("Parsing failed.", llvm::toString(std::move(Err)));
+
+#ifdef GTEST_HAS_DEATH_TEST
+  EXPECT_DEATH((void)Interp->Parse("int var1 = 42;"), "");
+#endif
+}
+
+// Here we test whether the user can mix declarations and statements. The
+// interpreter should be smart enough to recognize the declarations from the
+// statements and wrap the latter into a declaration, producing valid code.
+TEST(InterpreterTest, DeclsAndStatements) {
+  Args ExtraArgs = {"-Xclang", "-diagnostic-log-file", "-Xclang", 

[PATCH] D102337: [clang-tidy] Fix test that requires Windows platofrm

[Nathan James via Phabricator via cfe-commits]

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

LGTM.


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

https://reviews.llvm.org/D102337

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

[PATCH] D101968: Fix bad mangling of for a closure in the initializer of a variable at global namespace scope.

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

This revision was automatically updated to reflect the committed changes.
Closed by commit rG5bb7e81c64bd: Fix bad mangling of data-member-prefix 
for a closure in the initializer of a… (authored by rsmith).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101968

Files:
  clang/include/clang/Basic/CodeGenOptions.h
  clang/include/clang/Basic/LangOptions.h
  clang/lib/AST/ItaniumMangle.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/CodeGenCXX/clang-abi-compat.cpp
  clang/test/CodeGenCXX/lambda-expressions-nested-linkage.cpp
  clang/test/CodeGenCXX/mangle-lambda-explicit-template-params.cpp

Index: clang/test/CodeGenCXX/mangle-lambda-explicit-template-params.cpp
===
--- clang/test/CodeGenCXX/mangle-lambda-explicit-template-params.cpp
+++ clang/test/CodeGenCXX/mangle-lambda-explicit-template-params.cpp
@@ -38,7 +38,7 @@
 inline auto pack = [](T (&...)[N]) {};
 int arr1[] = {1};
 int arr2[] = {1, 2};
-// CHECK: @_ZNK4packMUlTpTyTpTnT_DpRAT0__S_E_clIJiiEJLi1ELi2DaS2_(
+// CHECK: @_ZNK4packMUlTpTyTpTnT_DpRAT0__S0_E_clIJiiEJLi1ELi2DaS3_(
 void use_pack() { pack(arr1, arr2); }
 
 inline void collision() {
Index: clang/test/CodeGenCXX/lambda-expressions-nested-linkage.cpp
===
--- clang/test/CodeGenCXX/lambda-expressions-nested-linkage.cpp
+++ clang/test/CodeGenCXX/lambda-expressions-nested-linkage.cpp
@@ -22,6 +22,13 @@
   L l; 
 }
 
+// It's important that this is not in a namespace; we're testing the mangling
+// of lambdas in top-level inline variables here.
+inline auto lambda_in_inline_variable = [] {};
+template struct Wrap {};
+// CHECK-LABEL: define {{.*}} @_Z30test_lambda_in_inline_variable4WrapIN25lambda_in_inline_variableMUlvE_EE
+void test_lambda_in_inline_variable(Wrap) {}
+
 namespace lambdas_in_NSDMIs_template_class {
 template
 struct L {
Index: clang/test/CodeGenCXX/clang-abi-compat.cpp
===
--- clang/test/CodeGenCXX/clang-abi-compat.cpp
+++ clang/test/CodeGenCXX/clang-abi-compat.cpp
@@ -13,11 +13,13 @@
 // RUN: %clang_cc1 -std=c++17 -triple x86_64-linux-gnu -fenable-matrix -fclang-abi-compat=11 %s -emit-llvm -o - \
 // RUN: | FileCheck --check-prefixes=CHECK,V39,V5,PRE12,PRE12-CXX17 %s
 // RUN: %clang_cc1 -std=c++20 -triple x86_64-linux-gnu -fenable-matrix -fclang-abi-compat=11 %s -emit-llvm -o - \
-// RUN: | FileCheck --check-prefixes=CHECK,V39,V5,PRE12,PRE12-CXX17,PRE12-CXX20 %s
+// RUN: | FileCheck --check-prefixes=CHECK,V39,V5,PRE12,PRE12-CXX17,PRE12-CXX20,PRE13-CXX20 %s
+// RUN: %clang_cc1 -std=c++20 -triple x86_64-linux-gnu -fenable-matrix -fclang-abi-compat=12 %s -emit-llvm -o - \
+// RUN: | FileCheck --check-prefixes=CHECK,V39,V5,V12,V12-CXX17,V12-CXX20,PRE13-CXX20 %s
 // RUN: %clang_cc1 -std=c++98 -triple x86_64-linux-gnu -fenable-matrix -fclang-abi-compat=latest %s -emit-llvm -o - -Wno-c++11-extensions \
 // RUN: | FileCheck --check-prefixes=CHECK,V39,V5,V12 %s
 // RUN: %clang_cc1 -std=c++20 -triple x86_64-linux-gnu -fenable-matrix -fclang-abi-compat=latest %s -emit-llvm -o - \
-// RUN: | FileCheck --check-prefixes=CHECK,V39,V5,V12,V12-CXX17,V12-CXX20 %s
+// RUN: | FileCheck --check-prefixes=CHECK,V39,V5,V12,V12-CXX17,V12-CXX20,V13-CXX20 %s
 
 typedef __attribute__((vector_size(8))) long long v1xi64;
 void clang39(v1xi64) {}
@@ -136,3 +138,12 @@
 void test9(void) __attribute__((enable_if(1, ""))) {}
 
 }
+
+#if __cplusplus >= 202002L
+// PRE13-CXX20: @_Z15observe_lambdasI17inline_var_lambdaMUlvE_17inline_var_lambdaMUlvE0_PiS2_S0_S1_EiT_T0_T1_T2_
+// V13-CXX20: @_Z15observe_lambdasIN17inline_var_lambdaMUlvE_ENS0_UlvE0_EPiS3_S1_S2_EiT_T0_T1_T2_
+template 
+int observe_lambdas(T, U, V, W) { return 0; }
+inline auto inline_var_lambda = observe_lambdas([]{}, []{}, (int*)0, (int*)0);
+int use_inline_var_lambda() { return inline_var_lambda; }
+#endif
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -3509,6 +3509,8 @@
 GenerateArg(Args, OPT_fclang_abi_compat_EQ, "9.0", SA);
   else if (Opts.getClangABICompat() == LangOptions::ClangABI::Ver11)
 GenerateArg(Args, OPT_fclang_abi_compat_EQ, "11.0", SA);
+  else if (Opts.getClangABICompat() == LangOptions::ClangABI::Ver12)
+GenerateArg(Args, OPT_fclang_abi_compat_EQ, "12.0", SA);
 
   if (Opts.getSignReturnAddressScope() ==
   LangOptions::SignReturnAddressScopeKind::All)
@@ -3970,6 +3972,8 @@
 Opts.setClangABICompat(LangOptions::ClangABI::Ver9);
   else if (Major <= 11)
 Opts.setClangABICompat(LangOptions::ClangABI::Ver11);
+  else if (Major <= 12)
+Opts.setClangABICompat(LangOptions::ClangABI::Ver12);
 } else if (Ver 

[clang] 5bb7e81 - Fix bad mangling of for a closure in the initializer of a variable at global namespace scope.

[Richard Smith via cfe-commits]

Author: Richard Smith
Date: 2021-05-12T13:13:21-07:00
New Revision: 5bb7e81c64bd29edd1c9ebadd4e4717919def0bf

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

LOG: Fix bad mangling of  for a closure in the initializer 
of a variable at global namespace scope.

This implements the direction proposed in
https://github.com/itanium-cxx-abi/cxx-abi/pull/126.

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

Added: 


Modified: 
clang/include/clang/Basic/CodeGenOptions.h
clang/include/clang/Basic/LangOptions.h
clang/lib/AST/ItaniumMangle.cpp
clang/lib/Frontend/CompilerInvocation.cpp
clang/test/CodeGenCXX/clang-abi-compat.cpp
clang/test/CodeGenCXX/lambda-expressions-nested-linkage.cpp
clang/test/CodeGenCXX/mangle-lambda-explicit-template-params.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/CodeGenOptions.h 
b/clang/include/clang/Basic/CodeGenOptions.h
index 8f75886d84d51..3f06dd3a3f821 100644
--- a/clang/include/clang/Basic/CodeGenOptions.h
+++ b/clang/include/clang/Basic/CodeGenOptions.h
@@ -75,23 +75,6 @@ class CodeGenOptions : public CodeGenOptionsBase {
 LocalExecTLSModel
   };
 
-  /// Clang versions with 
diff erent platform ABI conformance.
-  enum class ClangABI {
-/// Attempt to be ABI-compatible with code generated by Clang 3.8.x
-/// (SVN r257626). This causes <1 x long long> to be passed in an
-/// integer register instead of an SSE register on x64_64.
-Ver3_8,
-
-/// Attempt to be ABI-compatible with code generated by Clang 4.0.x
-/// (SVN r291814). This causes move operations to be ignored when
-/// determining whether a class type can be passed or returned directly.
-Ver4,
-
-/// Conform to the underlying platform's C and C++ ABIs as closely
-/// as we can.
-Latest
-  };
-
   enum StructReturnConventionKind {
 SRCK_Default,  // No special option was passed.
 SRCK_OnStack,  // Small structs on the stack (-fpcc-struct-return).

diff  --git a/clang/include/clang/Basic/LangOptions.h 
b/clang/include/clang/Basic/LangOptions.h
index 5ccac6367a5f3..524b79b138140 100644
--- a/clang/include/clang/Basic/LangOptions.h
+++ b/clang/include/clang/Basic/LangOptions.h
@@ -164,13 +164,18 @@ class LangOptions : public LangOptionsBase {
 Ver9,
 
 /// Attempt to be ABI-compatible with code generated by Clang 11.0.x
-/// (git  2e10b7a39b93). This causes clang to pass unions with a 256-bit
+/// (git 2e10b7a39b93). This causes clang to pass unions with a 256-bit
 /// vector member on the stack instead of using registers, to not properly
 /// mangle substitutions for template names in some cases, and to mangle
 /// declaration template arguments without a cast to the parameter type
 /// even when that can lead to mangling collisions.
 Ver11,
 
+/// Attempt to be ABI-compatible with code generated by Clang 12.0.x
+/// (git 8e464dd76bef). This causes clang to mangle lambdas within
+/// global-scope inline variables incorrectly.
+Ver12,
+
 /// Conform to the underlying platform's C and C++ ABIs as closely
 /// as we can.
 Latest

diff  --git a/clang/lib/AST/ItaniumMangle.cpp b/clang/lib/AST/ItaniumMangle.cpp
index 7420103213db2..65e04f1d55ca3 100644
--- a/clang/lib/AST/ItaniumMangle.cpp
+++ b/clang/lib/AST/ItaniumMangle.cpp
@@ -539,11 +539,16 @@ class CXXNameMangler {
   void mangleNestedName(const TemplateDecl *TD,
 const TemplateArgument *TemplateArgs,
 unsigned NumTemplateArgs);
+  void mangleNestedNameWithClosurePrefix(GlobalDecl GD,
+ const NamedDecl *PrefixND,
+ const AbiTagList *AdditionalAbiTags);
   void manglePrefix(NestedNameSpecifier *qualifier);
   void manglePrefix(const DeclContext *DC, bool NoFunction=false);
   void manglePrefix(QualType type);
   void mangleTemplatePrefix(GlobalDecl GD, bool NoFunction=false);
   void mangleTemplatePrefix(TemplateName Template);
+  const NamedDecl *getClosurePrefix(const Decl *ND);
+  void mangleClosurePrefix(const NamedDecl *ND, bool NoFunction = false);
   bool mangleUnresolvedTypeOrSimpleId(QualType DestroyedType,
   StringRef Prefix = "");
   void mangleOperatorName(DeclarationName Name, unsigned Arity);
@@ -983,6 +988,13 @@ void CXXNameMangler::mangleNameWithAbiTags(GlobalDecl GD,
 if (Module *M = ND->getOwningModuleForLinkage())
   mangleModuleName(M);
 
+  // Closures can require a nested-name mangling even if they're semantically
+  // in the global namespace.
+  if (const NamedDecl *PrefixND = getClosurePrefix(ND)) {
+mangleNestedNameWithClosurePrefix(GD, PrefixND, AdditionalAbiTags);
+return;
+  

[PATCH] D102361: [OpenMP] Add Module metadata for OpenMP compilation

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 created this revision.
jhuber6 added a reviewer: jdoerfert.
Herald added subscribers: guansong, yaxunl.
jhuber6 requested review of this revision.
Herald added subscribers: cfe-commits, sstefan1.
Herald added a project: clang.

This patch adds a module level metadata flag indicating that the module
was compiled with the `-fopenmp` flag. This will make it easier for
passes like OpenMPOpt to determine if it should be run.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D102361

Files:
  clang/lib/CodeGen/CodeGenModule.cpp


Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -697,6 +697,10 @@
   llvm::DenormalMode::IEEE);
   }
 
+  // Indicate whether this Module was compiled with -fopenmp
+  if (getLangOpts().OpenMP && !getLangOpts().OpenMPSimd)
+getModule().addModuleFlag(llvm::Module::Max, "openmp", LangOpts.OpenMP);
+
   // Emit OpenCL specific module metadata: OpenCL/SPIR version.
   if (LangOpts.OpenCL) {
 EmitOpenCLMetadata();


Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -697,6 +697,10 @@
   llvm::DenormalMode::IEEE);
   }
 
+  // Indicate whether this Module was compiled with -fopenmp
+  if (getLangOpts().OpenMP && !getLangOpts().OpenMPSimd)
+getModule().addModuleFlag(llvm::Module::Max, "openmp", LangOpts.OpenMP);
+
   // Emit OpenCL specific module metadata: OpenCL/SPIR version.
   if (LangOpts.OpenCL) {
 EmitOpenCLMetadata();
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D100388: [BROKEN][clang] Try to fix thunk function types

[Eli Friedman via Phabricator via cfe-commits]

efriedma added inline comments.



Comment at: clang/lib/CodeGen/CGVTables.cpp:467
+  if (!CalleeMD->isDefined()) {
+CGM.ErrorUnsupported(ThunkGD.getDecl(), "thunk for forward declaration");
+return;

lebedev.ri wrote:
> efriedma wrote:
> > "IsUnprototyped" means that we have to generate a thunk, but we don't have 
> > the proper types. We emit some special IR with known incorrect types, and 
> > mark it with the "thunk" attribute to let the optimizer know what we're 
> > doing.
> > 
> > It should be fine to continue using a fake type on the IsUnprototyped 
> > codepath.
> `IsUnprototyped` is false here for that test though..
Oh, hmm, right.  My comment still holds, but doesn't apply to that test.

In that test, the derived class method is defined, but the base class method 
isn't.  You should be able to compute the LLVM function type for the base class 
method in that case.  The types have to be the same, barring pointer variance, 
so being able to compute the type of the derived class method implies you can 
compute the type of the base class method.

So I'm not sure why you'd need to error out in that case; the computation 
should work the same way whether or not we can see the definition of the base 
class method.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100388

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

[PATCH] D100388: [BROKEN][clang] Try to fix thunk function types

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri added inline comments.



Comment at: clang/lib/CodeGen/CGVTables.cpp:467
+  if (!CalleeMD->isDefined()) {
+CGM.ErrorUnsupported(ThunkGD.getDecl(), "thunk for forward declaration");
+return;

efriedma wrote:
> "IsUnprototyped" means that we have to generate a thunk, but we don't have 
> the proper types. We emit some special IR with known incorrect types, and 
> mark it with the "thunk" attribute to let the optimizer know what we're doing.
> 
> It should be fine to continue using a fake type on the IsUnprototyped 
> codepath.
`IsUnprototyped` is false here for that test though..


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100388

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

[PATCH] D102251: Suppress Deferred Diagnostics in discarded statements.

[Erich Keane via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG08ba9ce1ef72: Suppress Deferred Diagnostics in discarded 
statements. (authored by erichkeane).

Changed prior to commit:
  https://reviews.llvm.org/D102251?vs=344813=344920#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102251

Files:
  clang/include/clang/AST/EvaluatedExprVisitor.h
  clang/include/clang/AST/Stmt.h
  clang/lib/AST/Stmt.cpp
  clang/lib/Sema/Sema.cpp
  clang/test/SemaCUDA/deferred-diags.cu

Index: clang/test/SemaCUDA/deferred-diags.cu
===
--- clang/test/SemaCUDA/deferred-diags.cu
+++ clang/test/SemaCUDA/deferred-diags.cu
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fcxx-exceptions -fcuda-is-device -fsyntax-only -verify %s
+// RUN: %clang_cc1 -fcxx-exceptions -fcuda-is-device -fsyntax-only -std=c++17 -verify %s
 
 #include "Inputs/cuda.h"
 
@@ -8,29 +8,55 @@
   // expected-error@-1 2{{cannot use 'throw' in __host__ __device__ function}}
 }
 
+inline __host__ __device__ void hasInvalid2() {
+  throw NULL;
+  // expected-error@-1 2{{cannot use 'throw' in __host__ __device__ function}}
+}
+
+inline __host__ __device__ void hasInvalidDiscarded() {
+  // This is only used in the discarded statements below, so this should not diagnose.
+  throw NULL;
+}
+
 static __device__ void use0() {
   hasInvalid(); // expected-note {{called by 'use0'}}
   hasInvalid(); // expected-note {{called by 'use0'}}
+
+  if constexpr (true) {
+hasInvalid2(); // expected-note {{called by 'use0'}}
+  } else {
+hasInvalidDiscarded();
+  }
+
+  if constexpr (false) {
+hasInvalidDiscarded();
+  } else {
+hasInvalid2(); // expected-note {{called by 'use0'}}
+  }
+
+  if constexpr (false) {
+hasInvalidDiscarded();
+  }
 }
 
 // To avoid excessive diagnostic messages, deferred diagnostics are only
 // emitted the first time a function is called.
 static __device__ void use1() {
-  use0(); // expected-note 2{{called by 'use1'}}
+  use0(); // expected-note 4{{called by 'use1'}}
   use0();
 }
 
 static __device__ void use2() {
-  use1(); // expected-note 2{{called by 'use2'}}
+  use1(); // expected-note 4{{called by 'use2'}}
   use1();
 }
 
 static __device__ void use3() {
-  use2(); // expected-note 2{{called by 'use3'}}
+  use2(); // expected-note 4{{called by 'use3'}}
   use2();
 }
 
 __global__ void use4() {
-  use3(); // expected-note 2{{called by 'use4'}}
+  use3(); // expected-note 4{{called by 'use4'}}
   use3();
 }
Index: clang/lib/Sema/Sema.cpp
===
--- clang/lib/Sema/Sema.cpp
+++ clang/lib/Sema/Sema.cpp
@@ -1569,6 +1569,8 @@
   DeferredDiagnosticsEmitter(Sema )
   : Inherited(S), ShouldEmitRootNode(false), InOMPDeviceContext(0) {}
 
+  bool shouldVisitDiscardedStmt() const { return false; }
+
   void VisitOMPTargetDirective(OMPTargetDirective *Node) {
 ++InOMPDeviceContext;
 Inherited::VisitOMPTargetDirective(Node);
Index: clang/lib/AST/Stmt.cpp
===
--- clang/lib/AST/Stmt.cpp
+++ clang/lib/AST/Stmt.cpp
@@ -989,12 +989,20 @@
   return isa(getCond());
 }
 
-Optional IfStmt::getNondiscardedCase(const ASTContext ) const {
+Optional IfStmt::getNondiscardedCase(const ASTContext ) {
   if (!isConstexpr() || getCond()->isValueDependent())
 return None;
   return !getCond()->EvaluateKnownConstInt(Ctx) ? getElse() : getThen();
 }
 
+Optional
+IfStmt::getNondiscardedCase(const ASTContext ) const {
+  if (Optional Result =
+  const_cast(this)->getNondiscardedCase(Ctx))
+return *Result;
+  return None;
+}
+
 ForStmt::ForStmt(const ASTContext , Stmt *Init, Expr *Cond, VarDecl *condVar,
  Expr *Inc, Stmt *Body, SourceLocation FL, SourceLocation LP,
  SourceLocation RP)
Index: clang/include/clang/AST/Stmt.h
===
--- clang/include/clang/AST/Stmt.h
+++ clang/include/clang/AST/Stmt.h
@@ -2080,6 +2080,7 @@
   /// If this is an 'if constexpr', determine which substatement will be taken.
   /// Otherwise, or if the condition is value-dependent, returns None.
   Optional getNondiscardedCase(const ASTContext ) const;
+  Optional getNondiscardedCase(const ASTContext );
 
   bool isObjCAvailabilityCheck() const;
 
Index: clang/include/clang/AST/EvaluatedExprVisitor.h
===
--- clang/include/clang/AST/EvaluatedExprVisitor.h
+++ clang/include/clang/AST/EvaluatedExprVisitor.h
@@ -32,6 +32,9 @@
   const ASTContext 
 
 public:
+  // Return whether this visitor should recurse into discarded statements for a
+  // 'constexpr-if'.
+  bool shouldVisitDiscardedStmt() const { return true; }
 #define PTR(CLASS) typename Ptr::type
 
   explicit EvaluatedExprVisitorBase(const ASTContext ) : 

[clang] 08ba9ce - Suppress Deferred Diagnostics in discarded statements.

[Erich Keane via cfe-commits]

Author: Erich Keane
Date: 2021-05-12T12:48:47-07:00
New Revision: 08ba9ce1ef7214623d4104e72d817c73644a0884

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

LOG: Suppress Deferred Diagnostics in discarded statements.

It doesn't really make sense to emit language specific diagnostics
in a discarded statement, and suppressing these diagnostics results in a
programming pattern that many users will feel is quite useful.

Basically, this makes sure we only emit errors from the 'true' side of a
'constexpr if'.

It does this by making the ExprEvaluatorBase type have an opt-in option
as to whether it should visit discarded cases.

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

Added: 


Modified: 
clang/include/clang/AST/EvaluatedExprVisitor.h
clang/include/clang/AST/Stmt.h
clang/lib/AST/Stmt.cpp
clang/lib/Sema/Sema.cpp
clang/test/SemaCUDA/deferred-diags.cu

Removed: 




diff  --git a/clang/include/clang/AST/EvaluatedExprVisitor.h 
b/clang/include/clang/AST/EvaluatedExprVisitor.h
index 2f6c314b41119..2991f2859ac4e 100644
--- a/clang/include/clang/AST/EvaluatedExprVisitor.h
+++ b/clang/include/clang/AST/EvaluatedExprVisitor.h
@@ -32,6 +32,9 @@ class EvaluatedExprVisitorBase : public StmtVisitorBase {
   const ASTContext 
 
 public:
+  // Return whether this visitor should recurse into discarded statements for a
+  // 'constexpr-if'.
+  bool shouldVisitDiscardedStmt() const { return true; }
 #define PTR(CLASS) typename Ptr::type
 
   explicit EvaluatedExprVisitorBase(const ASTContext ) : 
Context(Context) { }
@@ -83,7 +86,7 @@ class EvaluatedExprVisitorBase : public StmtVisitorBase {
 
   void VisitCallExpr(PTR(CallExpr) CE) {
 if (!CE->isUnevaluatedBuiltinCall(Context))
-  return static_cast(this)->VisitExpr(CE);
+  return getDerived().VisitExpr(CE);
   }
 
   void VisitLambdaExpr(PTR(LambdaExpr) LE) {
@@ -103,6 +106,20 @@ class EvaluatedExprVisitorBase : public 
StmtVisitorBase {
 this->Visit(SubStmt);
   }
 
+  void VisitIfStmt(PTR(IfStmt) If) {
+if (!getDerived().shouldVisitDiscardedStmt()) {
+  if (auto SubStmt = If->getNondiscardedCase(Context)) {
+if (*SubStmt)
+  this->Visit(*SubStmt);
+return;
+  }
+}
+
+getDerived().VisitStmt(If);
+  }
+
+  ImplClass () { return *static_cast(this); }
+
 #undef PTR
 };
 

diff  --git a/clang/include/clang/AST/Stmt.h b/clang/include/clang/AST/Stmt.h
index 97cd903f3d6f4..258b17e83b881 100644
--- a/clang/include/clang/AST/Stmt.h
+++ b/clang/include/clang/AST/Stmt.h
@@ -2080,6 +2080,7 @@ class IfStmt final
   /// If this is an 'if constexpr', determine which substatement will be taken.
   /// Otherwise, or if the condition is value-dependent, returns None.
   Optional getNondiscardedCase(const ASTContext ) const;
+  Optional getNondiscardedCase(const ASTContext );
 
   bool isObjCAvailabilityCheck() const;
 

diff  --git a/clang/lib/AST/Stmt.cpp b/clang/lib/AST/Stmt.cpp
index 2ceee614cf98f..d30df296dbd57 100644
--- a/clang/lib/AST/Stmt.cpp
+++ b/clang/lib/AST/Stmt.cpp
@@ -989,12 +989,20 @@ bool IfStmt::isObjCAvailabilityCheck() const {
   return isa(getCond());
 }
 
-Optional IfStmt::getNondiscardedCase(const ASTContext ) const 
{
+Optional IfStmt::getNondiscardedCase(const ASTContext ) {
   if (!isConstexpr() || getCond()->isValueDependent())
 return None;
   return !getCond()->EvaluateKnownConstInt(Ctx) ? getElse() : getThen();
 }
 
+Optional
+IfStmt::getNondiscardedCase(const ASTContext ) const {
+  if (Optional Result =
+  const_cast(this)->getNondiscardedCase(Ctx))
+return *Result;
+  return None;
+}
+
 ForStmt::ForStmt(const ASTContext , Stmt *Init, Expr *Cond, VarDecl *condVar,
  Expr *Inc, Stmt *Body, SourceLocation FL, SourceLocation LP,
  SourceLocation RP)

diff  --git a/clang/lib/Sema/Sema.cpp b/clang/lib/Sema/Sema.cpp
index b23140b4589c3..72e2ee613cbf4 100644
--- a/clang/lib/Sema/Sema.cpp
+++ b/clang/lib/Sema/Sema.cpp
@@ -1569,6 +1569,8 @@ class DeferredDiagnosticsEmitter
   DeferredDiagnosticsEmitter(Sema )
   : Inherited(S), ShouldEmitRootNode(false), InOMPDeviceContext(0) {}
 
+  bool shouldVisitDiscardedStmt() const { return false; }
+
   void VisitOMPTargetDirective(OMPTargetDirective *Node) {
 ++InOMPDeviceContext;
 Inherited::VisitOMPTargetDirective(Node);

diff  --git a/clang/test/SemaCUDA/deferred-diags.cu 
b/clang/test/SemaCUDA/deferred-diags.cu
index 856a5e06a58ff..125ddea95b996 100644
--- a/clang/test/SemaCUDA/deferred-diags.cu
+++ b/clang/test/SemaCUDA/deferred-diags.cu
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fcxx-exceptions -fcuda-is-device -fsyntax-only -verify %s
+// RUN: %clang_cc1 -fcxx-exceptions -fcuda-is-device -fsyntax-only -std=c++17 
-verify %s
 
 #include 

[PATCH] D101976: [OpenMP] Unified entry point for SPMD & generic kernels in the device RTL

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert updated this revision to Diff 344918.
jdoerfert added a comment.
Herald added a subscriber: jvesely.

Update tests


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101976

Files:
  clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
  clang/lib/CodeGen/CGOpenMPRuntimeGPU.h
  clang/test/OpenMP/amdgcn_target_codegen.cpp
  clang/test/OpenMP/assumes_include_nvptx.cpp
  clang/test/OpenMP/declare_target_codegen_globalization.cpp
  clang/test/OpenMP/nvptx_SPMD_codegen.cpp
  clang/test/OpenMP/nvptx_data_sharing.cpp
  clang/test/OpenMP/nvptx_distribute_parallel_generic_mode_codegen.cpp
  clang/test/OpenMP/nvptx_force_full_runtime_SPMD_codegen.cpp
  clang/test/OpenMP/nvptx_lambda_capturing.cpp
  clang/test/OpenMP/nvptx_multi_target_parallel_codegen.cpp
  clang/test/OpenMP/nvptx_nested_parallel_codegen.cpp
  clang/test/OpenMP/nvptx_parallel_codegen.cpp
  clang/test/OpenMP/nvptx_parallel_for_codegen.cpp
  clang/test/OpenMP/nvptx_target_codegen.cpp
  clang/test/OpenMP/nvptx_target_firstprivate_codegen.cpp
  clang/test/OpenMP/nvptx_target_parallel_codegen.cpp
  clang/test/OpenMP/nvptx_target_parallel_num_threads_codegen.cpp
  clang/test/OpenMP/nvptx_target_parallel_proc_bind_codegen.cpp
  clang/test/OpenMP/nvptx_target_parallel_reduction_codegen.cpp
  clang/test/OpenMP/nvptx_target_parallel_reduction_codegen_tbaa_PR46146.cpp
  clang/test/OpenMP/nvptx_target_printf_codegen.c
  clang/test/OpenMP/nvptx_target_simd_codegen.cpp
  clang/test/OpenMP/nvptx_target_teams_codegen.cpp
  clang/test/OpenMP/nvptx_target_teams_distribute_codegen.cpp
  clang/test/OpenMP/nvptx_target_teams_distribute_parallel_for_codegen.cpp
  
clang/test/OpenMP/nvptx_target_teams_distribute_parallel_for_generic_mode_codegen.cpp
  clang/test/OpenMP/nvptx_target_teams_distribute_parallel_for_simd_codegen.cpp
  clang/test/OpenMP/nvptx_target_teams_distribute_simd_codegen.cpp
  clang/test/OpenMP/nvptx_teams_codegen.cpp
  clang/test/OpenMP/nvptx_teams_reduction_codegen.cpp
  clang/test/OpenMP/remarks_parallel_in_multiple_target_state_machines.c
  clang/test/OpenMP/remarks_parallel_in_target_state_machine.c
  clang/test/OpenMP/target_parallel_debug_codegen.cpp
  clang/test/OpenMP/target_parallel_for_debug_codegen.cpp
  llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h
  llvm/include/llvm/Frontend/OpenMP/OMPKinds.def
  llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp
  openmp/libomptarget/deviceRTLs/common/include/target.h
  openmp/libomptarget/deviceRTLs/common/src/omptarget.cu
  openmp/libomptarget/deviceRTLs/common/src/parallel.cu
  openmp/libomptarget/deviceRTLs/interface.h
  openmp/libomptarget/deviceRTLs/nvptx/src/target_impl.cu

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

[PATCH] D102356: [UniqueLinkageName] Use exsiting GlobalDecl object instead of reconstructing one.

[Hongtao Yu via Phabricator via cfe-commits]

hoy created this revision.
Herald added a subscriber: wenlei.
hoy requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

C++ constructors/destructors need to go through a different constructor to 
construct a GlobalDecl object in order to retrieve their linkage type. This 
causes an assert failure in the default constructor of GlobalDecl. I'm chaning 
it to using the exsiting GlobalDecl object.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D102356

Files:
  clang/lib/CodeGen/CGCall.cpp
  clang/test/CodeGen/unique-internal-linkage-names.cpp


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
@@ -42,6 +42,16 @@
   return mver();
 }
 
+class A {
+public:
+  A() {}
+  ~A() {}
+};
+
+void test() {
+  A a;
+}
+
 // PLAIN: @_ZL4glob = internal global
 // PLAIN: @_ZZ8retAnonMvE5fGlob = internal global
 // PLAIN: @_ZN12_GLOBAL__N_16anon_mE = internal global
Index: clang/lib/CodeGen/CGCall.cpp
===
--- clang/lib/CodeGen/CGCall.cpp
+++ clang/lib/CodeGen/CGCall.cpp
@@ -2171,7 +2171,8 @@
   // functions with -funique-internal-linkage-names.
   if (TargetDecl && CodeGenOpts.UniqueInternalLinkageNames) {
 if (auto *Fn = dyn_cast(TargetDecl)) {
-  if (this->getFunctionLinkage(Fn) == llvm::GlobalValue::InternalLinkage)
+  if (this->getFunctionLinkage(CalleeInfo.getCalleeDecl()) ==
+  llvm::GlobalValue::InternalLinkage)
 FuncAttrs.addAttribute("sample-profile-suffix-elision-policy",
"selected");
 }


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
@@ -42,6 +42,16 @@
   return mver();
 }
 
+class A {
+public:
+  A() {}
+  ~A() {}
+};
+
+void test() {
+  A a;
+}
+
 // PLAIN: @_ZL4glob = internal global
 // PLAIN: @_ZZ8retAnonMvE5fGlob = internal global
 // PLAIN: @_ZN12_GLOBAL__N_16anon_mE = internal global
Index: clang/lib/CodeGen/CGCall.cpp
===
--- clang/lib/CodeGen/CGCall.cpp
+++ clang/lib/CodeGen/CGCall.cpp
@@ -2171,7 +2171,8 @@
   // functions with -funique-internal-linkage-names.
   if (TargetDecl && CodeGenOpts.UniqueInternalLinkageNames) {
 if (auto *Fn = dyn_cast(TargetDecl)) {
-  if (this->getFunctionLinkage(Fn) == llvm::GlobalValue::InternalLinkage)
+  if (this->getFunctionLinkage(CalleeInfo.getCalleeDecl()) ==
+  llvm::GlobalValue::InternalLinkage)
 FuncAttrs.addAttribute("sample-profile-suffix-elision-policy",
"selected");
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D102213: [ASTMatchers] Add forCallable(), a generalization of forFunction().

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added a comment.

I'm also mildly worried that Function is not the technically correct term. 
Maybe we should mark the old matcher as deprecated instead?


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

https://reviews.llvm.org/D102213

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

[PATCH] D101976: [OpenMP] Unified entry point for SPMD & generic kernels in the device RTL

[Jon Chesterfield via Phabricator via cfe-commits]

JonChesterfield added inline comments.



Comment at: openmp/libomptarget/deviceRTLs/common/src/omptarget.cu:195
+
+EXTERN __attribute__((weak))
+int32_t __kmpc_target_init(ident_t *Ident, bool IsSPMD,

jdoerfert wrote:
> JonChesterfield wrote:
> > why are these weak?
> So we do not perform IPO but will inline them. If we perform IPO we 
> specialize the arguments even though we still want to do potentially change 
> the mode from non-SPMD to SPMD.
as discussed offline, weak_odr or drop the weak


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101976

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

[PATCH] D101976: [OpenMP] Unified entry point for SPMD & generic kernels in the device RTL

[Jon Chesterfield via Phabricator via cfe-commits]

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

I'm not certain what this 'aligned' limitation for nvptx syncthreads is, but 
can't think of a corresponding one for amdgcn. So we may not need the LDS 
barrier construction, and it'll be much faster if we don't.

This was reported working on amdgpu by a third party against an earlier trunk 
build, but sadly the current trunk seems to have regressed (debugging offline). 
So I have no reason to believe this doesn't work, and some reason to believe it 
will do. Objection withdrawn.

The code itself always looked fine, was only nervous about the changes to 
concurrency primitives in nvptx.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101976

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

[PATCH] D102213: [ASTMatchers] Add forCallable(), a generalization of forFunction().

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added a comment.

The breakage is loud; the code will no longer compile when the intermediate 
`decl()` (or `namedDecl()`, or whatever) is not present. The more annoying part 
is that when you add `namedDecl()` back (or if you had it spelled out this way 
from the start, which doesn't make much sense but is valid and shorter than 
spelling out `functionDecl()`), your `Node.get()` in the match 
callback will silently start returning null (on anything that isn't a 
`functionDecl()`) which may lead to unexpected crashes (previously there was no 
match at all, now there's a match but the node isn't of the expected type). So 
a relatively distant piece of code will require manual audit in order to 
address the potential breakage.


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

https://reviews.llvm.org/D102213

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

[PATCH] D101139: Create install targets for scan-build-py.

[Yu Shan via Phabricator via cfe-commits]

aabbaabb updated this revision to Diff 344904.
aabbaabb marked 3 inline comments as done.

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

https://reviews.llvm.org/D101139

Files:
  clang/cmake/caches/Fuchsia-stage2.cmake
  clang/tools/CMakeLists.txt
  clang/tools/scan-build-py/CMakeLists.txt
  clang/tools/scan-build-py/bin/analyze-build
  clang/tools/scan-build-py/bin/analyze-c++
  clang/tools/scan-build-py/bin/analyze-cc
  clang/tools/scan-build-py/bin/intercept-build
  clang/tools/scan-build-py/bin/intercept-c++
  clang/tools/scan-build-py/bin/intercept-cc
  clang/tools/scan-build-py/bin/scan-build
  clang/tools/scan-build-py/libear/__init__.py
  clang/tools/scan-build-py/libear/config.h.in
  clang/tools/scan-build-py/libear/ear.c
  clang/tools/scan-build-py/libexec/libear/__init__.py
  clang/tools/scan-build-py/libexec/libear/config.h.in
  clang/tools/scan-build-py/libexec/libear/ear.c
  clang/tools/scan-build-py/libexec/libscanbuild/__init__.py
  clang/tools/scan-build-py/libexec/libscanbuild/analyze.py
  clang/tools/scan-build-py/libexec/libscanbuild/arguments.py
  clang/tools/scan-build-py/libexec/libscanbuild/clang.py
  clang/tools/scan-build-py/libexec/libscanbuild/compilation.py
  clang/tools/scan-build-py/libexec/libscanbuild/intercept.py
  clang/tools/scan-build-py/libexec/libscanbuild/report.py
  clang/tools/scan-build-py/libexec/libscanbuild/resources/scanview.css
  clang/tools/scan-build-py/libexec/libscanbuild/resources/selectable.js
  clang/tools/scan-build-py/libexec/libscanbuild/resources/sorttable.js
  clang/tools/scan-build-py/libexec/libscanbuild/shell.py
  clang/tools/scan-build-py/libscanbuild/__init__.py
  clang/tools/scan-build-py/libscanbuild/analyze.py
  clang/tools/scan-build-py/libscanbuild/arguments.py
  clang/tools/scan-build-py/libscanbuild/clang.py
  clang/tools/scan-build-py/libscanbuild/compilation.py
  clang/tools/scan-build-py/libscanbuild/intercept.py
  clang/tools/scan-build-py/libscanbuild/report.py
  clang/tools/scan-build-py/libscanbuild/resources/scanview.css
  clang/tools/scan-build-py/libscanbuild/resources/selectable.js
  clang/tools/scan-build-py/libscanbuild/resources/sorttable.js
  clang/tools/scan-build-py/libscanbuild/shell.py
  clang/tools/scan-build-py/tests/__init__.py
  clang/tools/scan-build-py/tests/unit/test_analyze.py

Index: clang/tools/scan-build-py/tests/unit/test_analyze.py
===
--- clang/tools/scan-build-py/tests/unit/test_analyze.py
+++ clang/tools/scan-build-py/tests/unit/test_analyze.py
@@ -18,9 +18,9 @@
 # scan-build can be easily matched up to compare results.
 def test_directory_name_comparison(self):
 with libear.TemporaryDirectory() as tmpdir, \
- sut.report_directory(tmpdir, False) as report_dir1, \
- sut.report_directory(tmpdir, False) as report_dir2, \
- sut.report_directory(tmpdir, False) as report_dir3:
+ sut.report_directory(tmpdir, False, 'html') as report_dir1, \
+ sut.report_directory(tmpdir, False, 'html') as report_dir2, \
+ sut.report_directory(tmpdir, False, 'html') as report_dir3:
 self.assertLess(report_dir1, report_dir2)
 self.assertLess(report_dir2, report_dir3)
 
Index: clang/tools/scan-build-py/tests/__init__.py
===
--- clang/tools/scan-build-py/tests/__init__.py
+++ clang/tools/scan-build-py/tests/__init__.py
@@ -3,6 +3,12 @@
 # See https://llvm.org/LICENSE.txt for license information.
 # SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 
+import os
+import sys
+
+this_dir = os.path.dirname(os.path.realpath(__file__))
+sys.path.append(os.path.join(os.path.dirname(this_dir), 'libexec'))
+
 import unittest
 
 import tests.unit
Index: clang/tools/scan-build-py/libscanbuild/resources/sorttable.js
===
--- clang/tools/scan-build-py/libscanbuild/resources/sorttable.js
+++ /dev/null
@@ -1,492 +0,0 @@
-/*
-  SortTable
-  version 2
-  7th April 2007
-  Stuart Langridge, http://www.kryogenix.org/code/browser/sorttable/
-
-  Instructions:
-  Download this file
-  Add  to your HTML
-  Add class="sortable" to any table you'd like to make sortable
-  Click on the headers to sort
-
-  Thanks to many, many people for contributions and suggestions.
-  Licenced as X11: http://www.kryogenix.org/code/browser/licence.html
-  This basically means: do what you want with it.
-*/
-
-
-var stIsIE = /*@cc_on!@*/false;
-
-sorttable = {
-  init: function() {
-// quit if this function has already been called
-if (arguments.callee.done) return;
-// flag this function so we don't do the same thing twice
-arguments.callee.done = true;
-// kill the timer
-if (_timer) clearInterval(_timer);
-
-if (!document.createElement || !document.getElementsByTagName) return;
-
-sorttable.DATE_RE = 

[PATCH] D102251: Suppress Deferred Diagnostics in discarded statements.

[Erich Keane via Phabricator via cfe-commits]

erichkeane added inline comments.



Comment at: clang/include/clang/AST/EvaluatedExprVisitor.h:37
+  // 'constexpr-if'.
+  bool shouldVisitDiscardedCase() const { return true; }
 #define PTR(CLASS) typename Ptr::type

rsmith wrote:
> Maybe `shouldVisitDiscardedStmt` would be more obvious, since "discarded 
> statement" is the standard terminology.
Yep, agreed.  I'll do that as a part of the commit.


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

https://reviews.llvm.org/D102251

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

[PATCH] D98798: Produce warning for performing pointer arithmetic on a null pointer.

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

rsmith added inline comments.



Comment at: clang/test/Sema/pointer-addition.cpp:5-6
+  char *f = (char*)0;
+  f = (char*)((char*)0 - f); // expected-warning {{performing pointer 
arithmetic on a null pointer has undefined behavior}}
+  f = (char*)(f - (char*)0); // expected-warning {{performing pointer 
arithmetic on a null pointer has undefined behavior}}
+  f = (char*)((char*)0 - (char*)0); // valid in C++

These two warnings are wrong -- their claim about these expressions having 
undefined behavior is incorrect. We can't prove that `f` is not null (and in 
fact it is null here), so we should not be producing a warning that says the 
code has undefined behavior. If you want to warn in the cases where you can 
prove the other pointer is non-null, and say that that case has undefined 
behavior, that seems fine, but please fix the diagnostic message to be 
technically correct (eg, "computing difference of a null pointer and a non-null 
pointer has undefined behavior").

Perhaps a better approach would be to use the same logic to decide whether to 
warn in C and C++, but produce different warning text. For example, you could 
say "[...] has undefined behavior" in C, but in C++ just say "warning: 
performing pointer arithmetic on a null pointer" without making 
potentially-inaccurate claims about UB? The code is still *suspicious* in C++ 
even if it's not UB.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98798

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

[PATCH] D102168: Use an allow list on reserved macro identifiers

[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!


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

https://reviews.llvm.org/D102168

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

[clang-tools-extra] 99d63cc - Add type information to integral template argument if required.

[Vassil Vassilev via cfe-commits]

Author: Pratyush Das
Date: 2021-05-12T19:00:08Z
New Revision: 99d63ccff04b672694f8a2b3eed024b873dc163d

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

LOG: Add type information to integral template argument if required.

Non-comprehensive list of cases:
 * Dumping template arguments;
 * Corresponding parameter contains a deduced type;
 * Template arguments are for a DeclRefExpr that hadMultipleCandidates()

Type information is added in the form of prefixes (u8, u, U, L),
suffixes (U, L, UL, LL, ULL) or explicit casts to printed integral template
argument, if MSVC codeview mode is disabled.

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

Added: 
clang/test/CXX/lex/lex.literal/lex.ext/p13.cpp
clang/test/CXX/lex/lex.literal/lex.ext/p14.cpp
clang/test/CodeGenCXX/debug-info-codeview-template-literal.cpp
clang/test/CodeGenCXX/debug-info-codeview-template-type.cpp
clang/test/SemaCXX/cxx1z-ast-print.cpp
clang/test/SemaTemplate/default-arguments-ast-print.cpp

Modified: 
clang-tools-extra/clangd/Hover.cpp
clang/include/clang/AST/DeclTemplate.h
clang/include/clang/AST/Expr.h
clang/include/clang/AST/StmtDataCollectors.td
clang/include/clang/AST/TemplateBase.h
clang/lib/AST/ASTTypeTraits.cpp
clang/lib/AST/DeclPrinter.cpp
clang/lib/AST/DeclTemplate.cpp
clang/lib/AST/Expr.cpp
clang/lib/AST/NestedNameSpecifier.cpp
clang/lib/AST/StmtPrinter.cpp
clang/lib/AST/TemplateBase.cpp
clang/lib/AST/TypePrinter.cpp
clang/lib/Analysis/PathDiagnostic.cpp
clang/lib/Sema/SemaDeclCXX.cpp
clang/lib/Sema/SemaTemplate.cpp
clang/lib/Sema/SemaTemplateDeduction.cpp
clang/lib/Sema/SemaTemplateInstantiate.cpp
clang/test/Analysis/eval-predefined-exprs.cpp
clang/test/CXX/lex/lex.literal/lex.ext/p12.cpp
clang/test/SemaCXX/builtin-align-cxx.cpp
clang/test/SemaCXX/cxx11-ast-print.cpp
clang/test/SemaCXX/matrix-type-builtins.cpp
clang/test/SemaCXX/matrix-type-operators.cpp
clang/test/SemaTemplate/address_space-dependent.cpp
clang/test/SemaTemplate/delegating-constructors.cpp
clang/test/SemaTemplate/matrix-type.cpp
clang/test/SemaTemplate/temp_arg_enum_printing.cpp
clang/test/SemaTemplate/temp_arg_nontype.cpp
clang/test/SemaTemplate/temp_arg_nontype_cxx1z.cpp
clang/tools/libclang/CIndex.cpp

clang/unittests/Tooling/RecursiveASTVisitorTests/TemplateArgumentLocTraverser.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/Hover.cpp 
b/clang-tools-extra/clangd/Hover.cpp
index c58dab22f8a3e..3651a3446fed4 100644
--- a/clang-tools-extra/clangd/Hover.cpp
+++ b/clang-tools-extra/clangd/Hover.cpp
@@ -223,7 +223,8 @@ fetchTemplateParameters(const TemplateParameterList *Params,
   if (TTPD->hasDefaultArgument()) {
 P.Default.emplace();
 llvm::raw_string_ostream Out(*P.Default);
-TTPD->getDefaultArgument().getArgument().print(PP, Out);
+TTPD->getDefaultArgument().getArgument().print(PP, Out,
+   /*IncludeType*/ false);
   }
 }
 TempParameters.push_back(std::move(P));

diff  --git a/clang/include/clang/AST/DeclTemplate.h 
b/clang/include/clang/AST/DeclTemplate.h
index 7fbf6294970eb..0cd8f00c623b7 100644
--- a/clang/include/clang/AST/DeclTemplate.h
+++ b/clang/include/clang/AST/DeclTemplate.h
@@ -204,6 +204,9 @@ class TemplateParameterList final
  bool OmitTemplateKW = false) const;
   void print(raw_ostream , const ASTContext ,
  const PrintingPolicy , bool OmitTemplateKW = false) const;
+
+  static bool shouldIncludeTypeForArgument(const TemplateParameterList *TPL,
+   unsigned Idx);
 };
 
 /// Stores a list of template parameters and the associated

diff  --git a/clang/include/clang/AST/Expr.h b/clang/include/clang/AST/Expr.h
index a44d06967431a..589199dbcdcaf 100644
--- a/clang/include/clang/AST/Expr.h
+++ b/clang/include/clang/AST/Expr.h
@@ -1615,6 +1615,8 @@ class CharacterLiteral : public Expr {
 return T->getStmtClass() == CharacterLiteralClass;
   }
 
+  static void print(unsigned val, CharacterKind Kind, raw_ostream );
+
   // Iterators
   child_range children() {
 return child_range(child_iterator(), child_iterator());

diff  --git a/clang/include/clang/AST/StmtDataCollectors.td 
b/clang/include/clang/AST/StmtDataCollectors.td
index 7cb9f16fbce26..922dd2a20d59c 100644
--- a/clang/include/clang/AST/StmtDataCollectors.td
+++ b/clang/include/clang/AST/StmtDataCollectors.td
@@ -51,7 +51,7 @@ class CallExpr {
 // Print all template arguments into ArgString
 llvm::raw_string_ostream OS(ArgString);
 for (unsigned i = 0; i < Args->size(); ++i) {
-  

[PATCH] D77598: Integral template argument suffix and cast printing

[Vassil Vassilev via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG99d63ccff04b: Add type information to integral template 
argument if required. (authored by reikdas, committed by v.g.vassilev).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77598

Files:
  clang-tools-extra/clangd/Hover.cpp
  clang/include/clang/AST/DeclTemplate.h
  clang/include/clang/AST/Expr.h
  clang/include/clang/AST/StmtDataCollectors.td
  clang/include/clang/AST/TemplateBase.h
  clang/lib/AST/ASTTypeTraits.cpp
  clang/lib/AST/DeclPrinter.cpp
  clang/lib/AST/DeclTemplate.cpp
  clang/lib/AST/Expr.cpp
  clang/lib/AST/NestedNameSpecifier.cpp
  clang/lib/AST/StmtPrinter.cpp
  clang/lib/AST/TemplateBase.cpp
  clang/lib/AST/TypePrinter.cpp
  clang/lib/Analysis/PathDiagnostic.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaTemplate.cpp
  clang/lib/Sema/SemaTemplateDeduction.cpp
  clang/lib/Sema/SemaTemplateInstantiate.cpp
  clang/test/Analysis/eval-predefined-exprs.cpp
  clang/test/CXX/lex/lex.literal/lex.ext/p12.cpp
  clang/test/CXX/lex/lex.literal/lex.ext/p13.cpp
  clang/test/CXX/lex/lex.literal/lex.ext/p14.cpp
  clang/test/CodeGenCXX/debug-info-codeview-template-literal.cpp
  clang/test/CodeGenCXX/debug-info-codeview-template-type.cpp
  clang/test/SemaCXX/builtin-align-cxx.cpp
  clang/test/SemaCXX/cxx11-ast-print.cpp
  clang/test/SemaCXX/cxx1z-ast-print.cpp
  clang/test/SemaCXX/matrix-type-builtins.cpp
  clang/test/SemaCXX/matrix-type-operators.cpp
  clang/test/SemaTemplate/address_space-dependent.cpp
  clang/test/SemaTemplate/default-arguments-ast-print.cpp
  clang/test/SemaTemplate/delegating-constructors.cpp
  clang/test/SemaTemplate/matrix-type.cpp
  clang/test/SemaTemplate/temp_arg_enum_printing.cpp
  clang/test/SemaTemplate/temp_arg_nontype.cpp
  clang/test/SemaTemplate/temp_arg_nontype_cxx1z.cpp
  clang/tools/libclang/CIndex.cpp
  
clang/unittests/Tooling/RecursiveASTVisitorTests/TemplateArgumentLocTraverser.cpp

Index: clang/unittests/Tooling/RecursiveASTVisitorTests/TemplateArgumentLocTraverser.cpp
===
--- clang/unittests/Tooling/RecursiveASTVisitorTests/TemplateArgumentLocTraverser.cpp
+++ clang/unittests/Tooling/RecursiveASTVisitorTests/TemplateArgumentLocTraverser.cpp
@@ -20,7 +20,7 @@
 llvm::raw_string_ostream Stream(ArgStr);
 const TemplateArgument  = ArgLoc.getArgument();
 
-Arg.print(Context->getPrintingPolicy(), Stream);
+Arg.print(Context->getPrintingPolicy(), Stream, /*IncludeType*/ true);
 Match(Stream.str(), ArgLoc.getLocation());
 return ExpectedLocationVisitor::
   TraverseTemplateArgumentLoc(ArgLoc);
Index: clang/tools/libclang/CIndex.cpp
===
--- clang/tools/libclang/CIndex.cpp
+++ clang/tools/libclang/CIndex.cpp
@@ -5185,8 +5185,9 @@
 SmallString<128> Str;
 llvm::raw_svector_ostream OS(Str);
 OS << *ClassSpec;
-printTemplateArgumentList(OS, ClassSpec->getTemplateArgs().asArray(),
-  Policy);
+printTemplateArgumentList(
+OS, ClassSpec->getTemplateArgs().asArray(), Policy,
+ClassSpec->getSpecializedTemplate()->getTemplateParameters());
 return cxstring::createDup(OS.str());
   }
 
Index: clang/test/SemaTemplate/temp_arg_nontype_cxx1z.cpp
===
--- clang/test/SemaTemplate/temp_arg_nontype_cxx1z.cpp
+++ clang/test/SemaTemplate/temp_arg_nontype_cxx1z.cpp
@@ -528,3 +528,33 @@
 x1.f(x2);
   }
 }
+
+namespace TypeSuffix {
+  template  struct A {};
+  template <> struct A<1> { using type = int; }; // expected-note {{'A<1>::type' declared here}}
+  A<1L>::type a; // expected-error {{no type named 'type' in 'TypeSuffix::A<1L>'; did you mean 'A<1>::type'?}}
+
+  template  struct B {};
+  template <> struct B<1> { using type = int; }; // expected-note {{'B<1>::type' declared here}}
+  B<2>::type b;  // expected-error {{no type named 'type' in 'TypeSuffix::B<2>'; did you mean 'B<1>::type'?}}
+
+  template  struct C {};
+  template <> struct C<'a'> { using type = signed char; }; // expected-note {{'C<'a'>::type' declared here}}
+  C<(signed char)'a'>::type c; // expected-error {{no type named 'type' in 'TypeSuffix::C<(signed char)'a'>'; did you mean 'C<'a'>::type'?}}
+
+  template  struct D {};
+  template <> struct D<'a'> { using type = signed char; }; // expected-note {{'D<'a'>::type' declared here}}
+  D<'b'>::type d;  // expected-error {{no type named 'type' in 'TypeSuffix::D<'b'>'; did you mean 'D<'a'>::type'?}}
+
+  template  struct E {};
+  template <> struct E<'a'> { using type = unsigned char; }; // expected-note 

[PATCH] D101640: [clang][patch] Add support for option -fextend-arguments={32,64}: widen integer arguments to int64 in unprototyped function calls

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/include/clang/Basic/LangOptions.h:262-264
+/// Unprototyped integer arguments are extended to 32 bits.
+ExtendTo32,
+/// Unprototyped integer arguments are extended to 64 bits.

The comments aren't quite right as this matters in functions with prototypes as 
well (due to variadic arguments). How about "integer arguments are sign or zero 
extended to 32/64 bits during default argument promotions."?



Comment at: clang/include/clang/Basic/TargetInfo.h:1415
 
+  virtual bool supportsExtendIntArgs() const { return false; }
+

This should get a comment explaining what it does. The name is a bit generic 
too (esp given that there's an `_ExtInt` type that sounds like an "extended 
int").

Is there anything truly target-specific about the functionality? It seems like 
this behavior would be plausibly useful regardless of target architecture. 



Comment at: clang/include/clang/Driver/Options.td:1432-1433
+  Flags<[CC1Option, NoArgumentUnused]>,
+  HelpText<"Controls how scalar integer arguments are extended in calls"
+   " to unprototyped and varargs functions">,
+  Values<"32,64">,

It's a bit more conventional to use a trailing whitespace in adjacent string 
literals.



Comment at: clang/test/CodeGen/extend-arg-64.c:19
+
+int vararg(int, ...);
+

Can you also add a test for K C functions? e.g., `int knr();` `sum = knr(sum, 
u32, s32, u16, s16, u8, s8);`

Also, can you show what happens when passing a `long long` and an `_ExtInt`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101640

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

[PATCH] D98798: Produce warning for performing pointer arithmetic on a null pointer.

[Nico Weber via Phabricator via cfe-commits]

thakis added a comment.

Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98798

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

[clang] d8c227b - Revert "Produce warning for performing pointer arithmetic on a null pointer."

[Nico Weber via cfe-commits]

Author: Nico Weber
Date: 2021-05-12T14:53:50-04:00
New Revision: d8c227ba05d065046bdb8671f1df73dabaffa222

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

LOG: Revert "Produce warning for performing pointer arithmetic on a null 
pointer."

This reverts commit dfc1e31d49fe1380c9bab43373995df5fed15e6d.
See discussion on https://reviews.llvm.org/D98798

Added: 


Modified: 
clang/lib/Sema/SemaExpr.cpp
clang/test/Sema/pointer-addition.c

Removed: 
clang/test/Sema/pointer-addition.cpp



diff  --git a/clang/lib/Sema/SemaExpr.cpp b/clang/lib/Sema/SemaExpr.cpp
index 719161fb9ba1e..b8be6732b758f 100644
--- a/clang/lib/Sema/SemaExpr.cpp
+++ b/clang/lib/Sema/SemaExpr.cpp
@@ -10779,17 +10779,7 @@ QualType Sema::CheckSubtractionOperands(ExprResult 
, ExprResult ,
LHS.get(), RHS.get()))
 return QualType();
 
-  bool LHSIsNullPtr = LHS.get()->IgnoreParenCasts()->isNullPointerConstant(
-  Context, Expr::NPC_ValueDependentIsNotNull);
-  bool RHSIsNullPtr = RHS.get()->IgnoreParenCasts()->isNullPointerConstant(
-  Context, Expr::NPC_ValueDependentIsNotNull);
-
-  // Subtracting nullptr or from nullptr should produce
-  // a warning expect nullptr - nullptr is valid in C++ [expr.add]p7
-  if (LHSIsNullPtr && (!getLangOpts().CPlusPlus || !RHSIsNullPtr))
-diagnoseArithmeticOnNullPointer(*this, Loc, LHS.get(), false);
-  if (RHSIsNullPtr && (!getLangOpts().CPlusPlus || !LHSIsNullPtr))
-diagnoseArithmeticOnNullPointer(*this, Loc, RHS.get(), false);
+  // FIXME: Add warnings for nullptr - ptr.
 
   // The pointee type may have zero size.  As an extension, a structure or
   // union may have zero size or an array may have zero length.  In this

diff  --git a/clang/test/Sema/pointer-addition.c 
b/clang/test/Sema/pointer-addition.c
index ab641bd132363..562f05340f7cb 100644
--- a/clang/test/Sema/pointer-addition.c
+++ b/clang/test/Sema/pointer-addition.c
@@ -29,7 +29,4 @@ void a(S* b, void* c) {
   // Cases that don't match the GNU inttoptr idiom get a 
diff erent warning.
   f = (char*)0 - i; // expected-warning {{performing pointer arithmetic on a 
null pointer has undefined behavior}}
   int *g = (int*)0 + i; // expected-warning {{performing pointer arithmetic on 
a null pointer has undefined behavior}}
-  f = (char*)((char*)0 - f); // expected-warning {{performing pointer 
arithmetic on a null pointer has undefined behavior}}
-  f = (char*)(f - (char*)0); // expected-warning {{performing pointer 
arithmetic on a null pointer has undefined behavior}}
-  f = (char*)((char*)0 - (char*)0); // expected-warning {{performing pointer 
arithmetic on a null pointer has undefined behavior}} expected-warning 
{{performing pointer arithmetic on a null pointer has undefined behavior}}
 }

diff  --git a/clang/test/Sema/pointer-addition.cpp 
b/clang/test/Sema/pointer-addition.cpp
deleted file mode 100644
index 5e09034ed9651..0
--- a/clang/test/Sema/pointer-addition.cpp
+++ /dev/null
@@ -1,8 +0,0 @@
-// RUN: %clang_cc1 %s -fsyntax-only -verify -pedantic -Wextra -std=c++11
-
-void a() {
-  char *f = (char*)0;
-  f = (char*)((char*)0 - f); // expected-warning {{performing pointer 
arithmetic on a null pointer has undefined behavior}}
-  f = (char*)(f - (char*)0); // expected-warning {{performing pointer 
arithmetic on a null pointer has undefined behavior}}
-  f = (char*)((char*)0 - (char*)0); // valid in C++
-}



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

[PATCH] D99543: [clang-tidy] Allow opt-in or out of some commonly occuring patterns in NarrowingConversionsCheck.

[Haojian Wu via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG211761332e43: [clang-tidy] Allow opt-in or out of some 
commonly occuring patterns in… (authored by Stephen, committed by hokein).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99543

Files:
  clang-tools-extra/clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.cpp
  clang-tools-extra/clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.h
  
clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-narrowing-conversions.rst
  
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-narrowing-conversions-equivalentbitwidth-option.cpp
  
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-narrowing-conversions-ignoreconversionfromtypes-option.cpp
  
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-narrowing-conversions-intemplates-option.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-narrowing-conversions-intemplates-option.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-narrowing-conversions-intemplates-option.cpp
@@ -0,0 +1,35 @@
+// RUN: %check_clang_tidy -check-suffix=DEFAULT %s \
+// RUN: cppcoreguidelines-narrowing-conversions %t -- \
+// RUN: -config='{CheckOptions: [ \
+// RUN: ]}'
+
+// RUN: %check_clang_tidy -check-suffix=WARN %s \
+// RUN: cppcoreguidelines-narrowing-conversions %t -- \
+// RUN: -config='{CheckOptions: [ \
+// RUN:   {key: cppcoreguidelines-narrowing-conversions.WarnWithinTemplateInstantiation, value: 1} \
+// RUN: ]}'
+
+template 
+void assign_in_template(OrigType jj) {
+  int ii;
+  ii = jj;
+  // DEFAULT: Warning disabled because WarnWithinTemplateInstantiation=0.
+  // CHECK-MESSAGES-WARN: :[[@LINE-2]]:8: warning: narrowing conversion from 'long long' to signed type 'int' is implementation-defined [cppcoreguidelines-narrowing-conversions]
+}
+
+void narrow_inside_template_not_ok() {
+  long long j = 123;
+  assign_in_template(j);
+}
+
+void assign_outside_template(long long jj) {
+  int ii;
+  ii = jj;
+  // CHECK-MESSAGES-DEFAULT: :[[@LINE-1]]:8: warning: narrowing conversion from 'long long' to signed type 'int' is implementation-defined [cppcoreguidelines-narrowing-conversions]
+  // CHECK-MESSAGES-WARN: :[[@LINE-2]]:8: warning: narrowing conversion from 'long long' to signed type 'int' is implementation-defined [cppcoreguidelines-narrowing-conversions]
+}
+
+void narrow_outside_template_not_ok() {
+  long long j = 123;
+  assign_outside_template(j);
+}
Index: clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-narrowing-conversions-ignoreconversionfromtypes-option.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-narrowing-conversions-ignoreconversionfromtypes-option.cpp
@@ -0,0 +1,76 @@
+// RUN: %check_clang_tidy -check-suffix=DEFAULT %s \
+// RUN: cppcoreguidelines-narrowing-conversions %t -- \
+// RUN: -config='{CheckOptions: [ \
+// RUN: ]}'
+
+// RUN: %check_clang_tidy -check-suffix=IGNORED %s \
+// RUN: cppcoreguidelines-narrowing-conversions %t -- \
+// RUN: -config='{CheckOptions: [ \
+// RUN:   {key: cppcoreguidelines-narrowing-conversions.IgnoreConversionFromTypes, value: "global_size_t;nested_size_type"} \
+// RUN: ]}'
+
+// We use global_size_t instead of 'size_t' because windows predefines size_t.
+typedef long long global_size_t;
+
+struct vector {
+  typedef long long nested_size_type;
+
+  global_size_t size() const { return 0; }
+};
+
+void narrowing_global_size_t() {
+  int i;
+  global_size_t j;
+  i = j;
+  // CHECK-MESSAGES-DEFAULT: :[[@LINE-1]]:7: warning: narrowing conversion from 'global_size_t' (aka 'long long') to signed type 'int' is implementation-defined [cppcoreguidelines-narrowing-conversions]
+  // IGNORED: Warning is disabled with IgnoreConversionFromTypes=global_size_t.
+}
+
+void narrowing_size_type() {
+  int i;
+  vector::nested_size_type j;
+  i = j;
+  // CHECK-MESSAGES-DEFAULT: :[[@LINE-1]]:7: warning: narrowing conversion from 'vector::nested_size_type' (aka 'long long') to signed type 'int' is implementation-defined [cppcoreguidelines-narrowing-conversions]
+  // IGNORED: Warning is disabled with IgnoreConversionFromTypes=nested_size_type.
+}
+
+void narrowing_size_method() {
+  vector v;
+  int i, j;
+  i = v.size();
+  // CHECK-MESSAGES-DEFAULT: :[[@LINE-1]]:7: warning: narrowing conversion from 'global_size_t' (aka 'long long') to signed type 'int' is implementation-defined [cppcoreguidelines-narrowing-conversions]
+  // IGNORED: Warning is disabled with IgnoreConversionFromTypes=global_size_t.
+
+  i = j + v.size();
+  // CHECK-MESSAGES-DEFAULT: :[[@LINE-1]]:7: warning: narrowing conversion from 'long long' to signed type 'int' is implementation-defined 

[clang-tools-extra] 2117613 - [clang-tidy] Allow opt-in or out of some commonly occuring patterns in NarrowingConversionsCheck.

[Haojian Wu via cfe-commits]

Author: Stephen Concannon
Date: 2021-05-12T20:51:25+02:00
New Revision: 211761332e4381c37edd91be7c59fc048014ff4e

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

LOG: [clang-tidy] Allow opt-in or out of some commonly occuring patterns in 
NarrowingConversionsCheck.

Within clang-tidy's NarrowingConversionsCheck.
* Allow opt-out of some common occurring patterns, such as:
  - Implicit casts between types of equivalent bit widths.
  - Implicit casts occurring from the return of a ::size() method.
  - Implicit casts on size_type and difference_type.
* Allow opt-in of errors within template instantiations.

This will help projects adopt these guidelines iteratively.
Developed in conjunction with Yitzhak Mandelbaum (ymandel).

Patch by Stephen Concannon!

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

Added: 

clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-narrowing-conversions-equivalentbitwidth-option.cpp

clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-narrowing-conversions-ignoreconversionfromtypes-option.cpp

clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-narrowing-conversions-intemplates-option.cpp

Modified: 
clang-tools-extra/clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.cpp
clang-tools-extra/clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.h

clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-narrowing-conversions.rst

Removed: 




diff  --git 
a/clang-tools-extra/clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.cpp 
b/clang-tools-extra/clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.cpp
index 86371fd67c533..8ce9afc8f926e 100644
--- 
a/clang-tools-extra/clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.cpp
+++ 
b/clang-tools-extra/clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.cpp
@@ -7,9 +7,12 @@
 
//===--===//
 
 #include "NarrowingConversionsCheck.h"
+#include "../utils/OptionsUtils.h"
 #include "clang/AST/ASTContext.h"
+#include "clang/AST/Expr.h"
 #include "clang/AST/Type.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/ASTMatchers/ASTMatchers.h"
 #include "llvm/ADT/APSInt.h"
 #include "llvm/ADT/SmallString.h"
 #include "llvm/ADT/SmallVector.h"
@@ -21,18 +24,33 @@ using namespace clang::ast_matchers;
 namespace clang {
 namespace tidy {
 namespace cppcoreguidelines {
+namespace {
+auto hasAnyListedName(const std::string ) {
+  const std::vector NameList =
+  utils::options::parseStringList(Names);
+  return hasAnyName(std::vector(NameList.begin(), NameList.end()));
+}
+} // namespace
 
 NarrowingConversionsCheck::NarrowingConversionsCheck(StringRef Name,
  ClangTidyContext *Context)
 : ClangTidyCheck(Name, Context),
   WarnOnFloatingPointNarrowingConversion(
   Options.get("WarnOnFloatingPointNarrowingConversion", true)),
+  WarnWithinTemplateInstantiation(
+  Options.get("WarnWithinTemplateInstantiation", false)),
+  WarnOnEquivalentBitWidth(Options.get("WarnOnEquivalentBitWidth", true)),
+  IgnoreConversionFromTypes(Options.get("IgnoreConversionFromTypes", "")),
   PedanticMode(Options.get("PedanticMode", false)) {}
 
 void NarrowingConversionsCheck::storeOptions(
 ClangTidyOptions::OptionMap ) {
   Options.store(Opts, "WarnOnFloatingPointNarrowingConversion",
 WarnOnFloatingPointNarrowingConversion);
+  Options.store(Opts, "WarnWithinTemplateInstantiation",
+WarnWithinTemplateInstantiation);
+  Options.store(Opts, "WarnOnEquivalentBitWidth", WarnOnEquivalentBitWidth);
+  Options.store(Opts, "IgnoreConversionFromTypes", IgnoreConversionFromTypes);
   Options.store(Opts, "PedanticMode", PedanticMode);
 }
 
@@ -42,6 +60,24 @@ void NarrowingConversionsCheck::registerMatchers(MatchFinder 
*Finder) {
   const auto IsCeilFloorCallExpr = expr(callExpr(callee(functionDecl(
   hasAnyName("::ceil", "::std::ceil", "::floor", "::std::floor");
 
+  // We may want to exclude other types from the checks, such as `size_type`
+  // and `
diff erence_type`. These are often used to count elements, represented
+  // in 64 bits and assigned to `int`. Rarely are people counting >2B elements.
+  const auto IsConversionFromIgnoredType =
+  hasType(namedDecl(hasAnyListedName(IgnoreConversionFromTypes)));
+
+  // `IsConversionFromIgnoredType` will ignore narrowing calls from those 
types,
+  // but not expressions that are promoted to `int64` due to a binary 
expression
+  // with one of those types. For example, it will continue to reject:
+  // `int narrowed = int_value + container.size()`.
+  // We attempt to address common incidents of compound 

[PATCH] D100388: [BROKEN][clang] Try to fix thunk function types

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri added a comment.

In D100388#2754872 , @efriedma wrote:

>> Would it be reasonable to instead start with a stopgap measure of not adding 
>> attributes for this/return of thunks?
>
> You mean, add align attributes to "this" on regular methods, but not thunks?

Yes, just so the rG6270b3a1eafaba4279e021418c5a2c5a35abc002 
 can be 
reverted.
Unless of course we can get this going..

> I can't see how that could do any harm.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100388

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

[PATCH] D102339: [clang] On Windows, ignore case and separators when discarding duplicate dependency file paths.

[Reid Kleckner via Phabricator via cfe-commits]

rnk added inline comments.



Comment at: clang/lib/Frontend/DependencyFile.cpp:145
+  StringRef SearchPath;
+#ifdef _WIN32
+  // Make the search insensitive to case and separators.

I feel like this should somehow be a property of the input virtual filesystem: 
we should be able to ask the VFS to do the path canonicalization for us, or ask 
if the FS is case insensitive and do the lower-casing if so.



Comment at: clang/lib/Frontend/DependencyFile.cpp:148
+  llvm::SmallString<256> TmpPath = Filename;
+  std::replace(TmpPath.begin(), TmpPath.end(), '/', '\\');
+  std::transform(TmpPath.begin(), TmpPath.end(), TmpPath.begin(), ::tolower);

nit: using `sys::path::native` here seems nicer. It replaces `~` with the home 
dir, but that doesn't seem important.



Comment at: clang/test/Frontend/dependency-gen-windows-duplicates.c:12
+// CHECK-NEXT: \test.c
+// CHECK-NEXT: \subdir\x.h
+// File x.h must appear only once (case insensitive check).

Please reorder the includes and adjust the test to look for SubDir/X.h with 
capitalization to verify that clang isn't simply producing all lower case 
output. Your code does this correctly, it canonicalizes the path to check for 
duplicates, and then prints the filename as written, I just want the test case 
to reflect that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102339

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

[PATCH] D100388: [BROKEN][clang] Try to fix thunk function types

[Eli Friedman via Phabricator via cfe-commits]

efriedma added a comment.

> Would it be reasonable to instead start with a stopgap measure of not adding 
> attributes for this/return of thunks?

You mean, add align attributes to "this" on regular methods, but not thunks?  I 
can't see how that could do any harm.




Comment at: clang/lib/CodeGen/CGVTables.cpp:467
+  if (!CalleeMD->isDefined()) {
+CGM.ErrorUnsupported(ThunkGD.getDecl(), "thunk for forward declaration");
+return;

"IsUnprototyped" means that we have to generate a thunk, but we don't have the 
proper types. We emit some special IR with known incorrect types, and mark it 
with the "thunk" attribute to let the optimizer know what we're doing.

It should be fine to continue using a fake type on the IsUnprototyped codepath.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100388

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

[PATCH] D102213: [ASTMatchers] Add forCallable(), a generalization of forFunction().

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D102213#2754495 , @NoQ wrote:

> I totally agree that changing `forFunction()` to work correctly is the right 
> solution but backwards compatibility breakage is very real because 
> `forFunction()` accepts a `Matcher` whereas `forCallable()` 
> accepts `Matcher` which is a smaller set of matchers. Eg., 
> `forFunction(hasName())` is valid code but `forCallable(hasName())` is not 
> because `BlockDecl` isn't a `NamedDecl`. So, like, I suspect that not a lot 
> of code expects this to be **//the//** function, but a lot of code expects it 
> to be **//a//** function. See how much types did I have to change just to get 
> the infinite loop checker to compile in D102214 
> .
>
> If we're ok with such compatibility breakage then i'm all for it.

That's a fair point. We try to not let changes break existing code, but we also 
don't make any stability guarantees that prevent us from doing so when that's 
the right answer. Would this breakage be loud for users of the C++ interface, 
or would the behavior silently change so that anyone who fails to add a 
`namedDecl()` in the right place stops getting expected results?


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

https://reviews.llvm.org/D102213

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

[PATCH] D99543: [clang-tidy] Allow opt-in or out of some commonly occuring patterns in NarrowingConversionsCheck.

[Haojian Wu via Phabricator via cfe-commits]

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

thanks, looks good. Sorry for the delay.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99543

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

[PATCH] D98798: Produce warning for performing pointer arithmetic on a null pointer.

[Jamie Schmeiser via Phabricator via cfe-commits]

jamieschmeiser added a comment.

If this is a problem for you, please revert it and I will take a look when I 
return.  Thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98798

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

[PATCH] D98798: Produce warning for performing pointer arithmetic on a null pointer.

[Eli Friedman via Phabricator via cfe-commits]

efriedma added a comment.

@thakis if this is an issue for you, please revert; like you said, we can 
figure out the issues later.

Looking at the warning you showed, we might want to consider suppressing that 
specific pattern, in addition to (or instead of?) suppressing it in system 
headers. The null pointer subtraction is the least of the problems in 
`(char*)&((struct S*)0)->member - (char*)0`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98798

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

[PATCH] D98799: [UniqueLinkageName] Use consistent checks when mangling symbo linkage name and debug linkage name.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/test/CodeGen/unique-internal-linkage-names-dwarf.c:34-39
+static int go(a) int a;
+{
+  return glob + a;
+}
+
+

hoy wrote:
> aaron.ballman wrote:
> > hoy wrote:
> > > aaron.ballman wrote:
> > > > dblaikie wrote:
> > > > > hoy wrote:
> > > > > > dblaikie wrote:
> > > > > > > hoy wrote:
> > > > > > > > dblaikie wrote:
> > > > > > > > > aaron.ballman wrote:
> > > > > > > > > > dblaikie wrote:
> > > > > > > > > > > aaron.ballman wrote:
> > > > > > > > > > > > dblaikie wrote:
> > > > > > > > > > > > > hoy wrote:
> > > > > > > > > > > > > > dblaikie wrote:
> > > > > > > > > > > > > > > dblaikie wrote:
> > > > > > > > > > > > > > > > hoy wrote:
> > > > > > > > > > > > > > > > > dblaikie wrote:
> > > > > > > > > > > > > > > > > > hoy wrote:
> > > > > > > > > > > > > > > > > > > dblaikie wrote:
> > > > > > > > > > > > > > > > > > > > hoy wrote:
> > > > > > > > > > > > > > > > > > > > > dblaikie wrote:
> > > > > > > > > > > > > > > > > > > > > > hoy wrote:
> > > > > > > > > > > > > > > > > > > > > > > dblaikie wrote:
> > > > > > > > > > > > > > > > > > > > > > > > hoy wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > dblaikie wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > > hoy wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > > > dblaikie wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Does this need to be 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > down here? Or would the 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > code be a well 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > exercised if it was up 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > next to the go 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > declaration above?
> > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, it needs to be here. 
> > > > > > > > > > > > > > > > > > > > > > > > > > > Otherwise it will just 
> > > > > > > > > > > > > > > > > > > > > > > > > > > like the function `bar` 
> > > > > > > > > > > > > > > > > > > > > > > > > > > above that doesn't get a 
> > > > > > > > > > > > > > > > > > > > > > > > > > > uniquefied name. I think 
> > > > > > > > > > > > > > > > > > > > > > > > > > > moving the definition up 
> > > > > > > > > > > > > > > > > > > > > > > > > > > to right after the 
> > > > > > > > > > > > > > > > > > > > > > > > > > > declaration hides the 
> > > > > > > > > > > > > > > > > > > > > > > > > > > declaration.
> > > > > > > > > > > > > > > > > > > > > > > > > > Not sure I follow - do you 
> > > > > > > > > > > > > > > > > > > > > > > > > > mean that if the go 
> > > > > > > > > > > > > > > > > > > > > > > > > > declaration and go 
> > > > > > > > > > > > > > > > > > > > > > > > > > definition were next to 
> > > > > > > > > > > > > > > > > > > > > > > > > > each other, this test would 
> > > > > > > > > > > > > > > > > > > > > > > > > > (mechanically speaking) not 
> > > > > > > > > > > > > > > > > > > > > > > > > > validate what the patch? Or 
> > > > > > > > > > > > > > > > > > > > > > > > > > that it would be less 
> > > > > > > > > > > > > > > > > > > > > > > > > > legible, but still 
> > > > > > > > > > > > > > > > > > > > > > > > > > mechanically correct?
> > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > I think it would be 
> > > > > > > > > > > > > > > > > > > > > > > > > > (assuming it's still 
> > > > > > > > > > > > > > > > > > > > > > > > > > mechanically correct) more 
> > > > > > > > > > > > > > > > > > > > > > > > > > legible to put the 
> > > > > > > > > > > > > > > > > > > > > > > > > > declaration next to the 
> > > > > > > > > > > > > > > > > > > > > > > > > > definition - the comment 
> > > > > > > > > > > > > > > > > > > > > > > > > > describes why the 
> > > > > > > > > > > > > > > > > > > > > > > > > > declaration is 
> > > > > > > > > > > > > > > > > > > > > > > > > > significant/why the 
> > > > > > > > > > > > > > > > > > > > > > > > > > definition is weird, and 
> > > > > > > > > > > > > > > > > > > > > > > > > > seeing all that together 
> > > > > > > > > > > > > > > > > > > > > > > > > > would be clearer to me than 
> > > > > > > > > > > > > > > > > > > > > > > > > > spreading it out/having to 
> > > > > > > > > > > > > > > > > > > > > > > > > > look further away to see 
> > > > > > > > > > > > > > > > > > > > > > > > > > what's going on.
> > > > > > > > > > > > > > > > > > > > > > > > > When the `go` declaration and 
> > > > > > > > > > > > > > > > > > > > > > > > > `go` definition were next to 
> > > > > > > > > > > > > > > > > > > > > > > > > each other, the go function 
> > > > > > > > > > > > > > > > > > > > > > > > > won't get a uniqufied name at 
> > > > > > > > > > > > > > > > > > > > > > > > > all. The declaration will be 
> > > > > > > > > > > > > > > > > > > > > > > > > overwritten by the 
> > > > > > > > > > > > > > > > > > > > > > > > > 

[clang] 56f7e5a - [cmake] Add support for multiple distributions

[Shoaib Meenai via cfe-commits]

Author: Shoaib Meenai
Date: 2021-05-12T11:13:18-07:00
New Revision: 56f7e5a822b43578e086c40d063af2a2c0d214ee

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

LOG: [cmake] Add support for multiple distributions

LLVM's build system contains support for configuring a distribution, but
it can often be useful to be able to configure multiple distributions
(e.g. if you want separate distributions for the tools and the
libraries). Add this support to the build system, along with
documentation and usage examples.

Reviewed By: phosek

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

Added: 
clang/cmake/caches/MultiDistributionExample.cmake

Modified: 
clang/cmake/modules/AddClang.cmake
clang/cmake/modules/CMakeLists.txt
clang/cmake/modules/ClangConfig.cmake.in
flang/cmake/modules/AddFlang.cmake
flang/cmake/modules/CMakeLists.txt
flang/cmake/modules/FlangConfig.cmake.in
lld/cmake/modules/AddLLD.cmake
lld/cmake/modules/CMakeLists.txt
lld/cmake/modules/LLDConfig.cmake.in
llvm/cmake/modules/AddLLVM.cmake
llvm/cmake/modules/CMakeLists.txt
llvm/cmake/modules/LLVMConfig.cmake.in
llvm/cmake/modules/LLVMDistributionSupport.cmake
llvm/docs/BuildingADistribution.rst
llvm/docs/ReleaseNotes.rst
mlir/cmake/modules/AddMLIR.cmake
mlir/cmake/modules/CMakeLists.txt
mlir/cmake/modules/MLIRConfig.cmake.in

Removed: 




diff  --git a/clang/cmake/caches/MultiDistributionExample.cmake 
b/clang/cmake/caches/MultiDistributionExample.cmake
new file mode 100644
index 0..0c97611e252b4
--- /dev/null
+++ b/clang/cmake/caches/MultiDistributionExample.cmake
@@ -0,0 +1,74 @@
+# This file sets up a CMakeCache for a simple build with multiple 
distributions.
+# Note that for a real distribution, you likely want to perform a boostrap
+# build; see clang/cmake/caches/DistributionExample.cmake and the
+# BuildingADistribution documentation for details. This cache file doesn't
+# demonstrate bootstrapping so it can focus on the configuration details
+# specific to multiple distributions instead.
+
+# Build an optimized toolchain for an example set of targets.
+set(CMAKE_BUILD_TYPE Release CACHE STRING "")
+set(LLVM_TARGETS_TO_BUILD
+  AArch64
+  ARM
+  X86
+CACHE STRING "")
+
+# Enable the LLVM projects and runtimes.
+set(LLVM_ENABLE_PROJECTS
+  clang
+  lld
+CACHE STRING "")
+set(LLVM_ENABLE_RUNTIMES
+  compiler-rt
+  libcxx
+  libcxxabi
+CACHE STRING "")
+
+# We'll build two distributions: Toolchain, which just holds the tools
+# (intended for most end users), and Development, which has libraries (for end
+# users who wish to develop their own tooling using those libraries). This will
+# produce the install-toolchain-distribution and 
install-development-distribution
+# targets to install the distributions.
+set(LLVM_DISTRIBUTIONS
+  Toolchain
+  Development
+CACHE STRING "")
+
+# We want to include the C++ headers in our distribution.
+set(LLVM_RUNTIME_DISTRIBUTION_COMPONENTS
+  cxx-headers
+CACHE STRING "")
+
+# You likely want more tools; this is just an example :) Note that we need to
+# include cxx-headers explicitly here (in addition to it being added to
+# LLVM_RUNTIME_DISTRIBUTION_COMPONENTS above).
+set(LLVM_Toolchain_DISTRIBUTION_COMPONENTS
+  builtins
+  clang
+  clang-resource-headers
+  cxx-headers
+  lld
+  llvm-objdump
+CACHE STRING "")
+
+# Note that we need to include the CMake exports targets for the distribution
+# (development-cmake-exports and clang-development-cmake-exports), as well as
+# the general CMake exports target for each project (cmake-exports and
+# clang-cmake-exports), in our list of targets. The distribution CMake exports
+# targets just install the CMake exports file for the distribution's targets,
+# whereas the project CMake exports targets install the rest of the project's
+# CMake exports (which are needed in order to import the project from other
+# CMake_projects via find_package, and include the distribution's CMake exports
+# file to get the exported targets).
+set(LLVM_Development_DISTRIBUTION_COMPONENTS
+  # LLVM
+  cmake-exports
+  development-cmake-exports
+  llvm-headers
+  llvm-libraries
+  # Clang
+  clang-cmake-exports
+  clang-development-cmake-exports
+  clang-headers
+  clang-libraries
+CACHE STRING "")

diff  --git a/clang/cmake/modules/AddClang.cmake 
b/clang/cmake/modules/AddClang.cmake
index 704278a0e93bf..5752f4277444e 100644
--- a/clang/cmake/modules/AddClang.cmake
+++ b/clang/cmake/modules/AddClang.cmake
@@ -1,3 +1,5 @@
+include(LLVMDistributionSupport)
+
 function(clang_tablegen)
   # Syntax:
   # clang_tablegen output-file 

[PATCH] D89177: [cmake] Add support for multiple distributions

[Shoaib Meenai via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG56f7e5a822b4: [cmake] Add support for multiple distributions 
(authored by smeenai).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89177

Files:
  clang/cmake/caches/MultiDistributionExample.cmake
  clang/cmake/modules/AddClang.cmake
  clang/cmake/modules/CMakeLists.txt
  clang/cmake/modules/ClangConfig.cmake.in
  flang/cmake/modules/AddFlang.cmake
  flang/cmake/modules/CMakeLists.txt
  flang/cmake/modules/FlangConfig.cmake.in
  lld/cmake/modules/AddLLD.cmake
  lld/cmake/modules/CMakeLists.txt
  lld/cmake/modules/LLDConfig.cmake.in
  llvm/cmake/modules/AddLLVM.cmake
  llvm/cmake/modules/CMakeLists.txt
  llvm/cmake/modules/LLVMConfig.cmake.in
  llvm/cmake/modules/LLVMDistributionSupport.cmake
  llvm/docs/BuildingADistribution.rst
  llvm/docs/ReleaseNotes.rst
  mlir/cmake/modules/AddMLIR.cmake
  mlir/cmake/modules/CMakeLists.txt
  mlir/cmake/modules/MLIRConfig.cmake.in

Index: mlir/cmake/modules/MLIRConfig.cmake.in
===
--- mlir/cmake/modules/MLIRConfig.cmake.in
+++ mlir/cmake/modules/MLIRConfig.cmake.in
@@ -20,7 +20,7 @@
 set_property(GLOBAL PROPERTY MLIR_TRANSLATION_LIBS "@MLIR_TRANSLATION_LIBS@")
 
 # Provide all our library targets to users.
-include("@MLIR_CONFIG_EXPORTS_FILE@")
+@MLIR_CONFIG_INCLUDE_EXPORTS@
 
 # By creating these targets here, subprojects that depend on MLIR's
 # tablegen-generated headers can always depend on these targets whether building
Index: mlir/cmake/modules/CMakeLists.txt
===
--- mlir/cmake/modules/CMakeLists.txt
+++ mlir/cmake/modules/CMakeLists.txt
@@ -1,3 +1,5 @@
+include(LLVMDistributionSupport)
+
 # Generate a list of CMake library targets so that other CMake projects can
 # link against them. LLVM calls its version of this file LLVMExports.cmake, but
 # the usual CMake convention seems to be ${Project}Targets.cmake.
@@ -19,7 +21,7 @@
 # Generate MlirConfig.cmake for the build tree.
 set(MLIR_CONFIG_CMAKE_DIR "${mlir_cmake_builddir}")
 set(MLIR_CONFIG_LLVM_CMAKE_DIR "${llvm_cmake_builddir}")
-set(MLIR_CONFIG_EXPORTS_FILE "\${MLIR_CMAKE_DIR}/MLIRTargets.cmake")
+set(MLIR_CONFIG_INCLUDE_EXPORTS "include(\"\${MLIR_CMAKE_DIR}/MLIRTargets.cmake\")")
 set(MLIR_CONFIG_INCLUDE_DIRS
   "${MLIR_SOURCE_DIR}/include"
   "${MLIR_BINARY_DIR}/include"
@@ -30,7 +32,6 @@
   @ONLY)
 set(MLIR_CONFIG_CMAKE_DIR)
 set(MLIR_CONFIG_LLVM_CMAKE_DIR)
-set(MLIR_CONFIG_EXPORTS_FILE)
 set(MLIR_CONFIG_INCLUDE_DIRS)
 
 # For compatibility with projects that include(MLIRConfig)
@@ -55,7 +56,7 @@
 endforeach(p)
 set(MLIR_CONFIG_CMAKE_DIR "\${MLIR_INSTALL_PREFIX}/${MLIR_INSTALL_PACKAGE_DIR}")
 set(MLIR_CONFIG_LLVM_CMAKE_DIR "\${MLIR_INSTALL_PREFIX}/${LLVM_INSTALL_PACKAGE_DIR}")
-set(MLIR_CONFIG_EXPORTS_FILE "\${MLIR_CMAKE_DIR}/MLIRTargets.cmake")
+get_config_exports_includes(MLIR MLIR_CONFIG_INCLUDE_EXPORTS)
 set(MLIR_CONFIG_INCLUDE_DIRS
   "\${MLIR_INSTALL_PREFIX}/include"
   )
@@ -66,17 +67,12 @@
 set(MLIR_CONFIG_CODE)
 set(MLIR_CONFIG_CMAKE_DIR)
 set(MLIR_CONFIG_LLVM_CMAKE_DIR)
-set(MLIR_CONFIG_EXPORTS_FILE)
 set(MLIR_CONFIG_INCLUDE_DIRS)
 
 if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY)
   # Not TOOLCHAIN ONLY, so install the MLIR parts as well
   # Include the cmake files so other tools can use mlir-tblgen, etc.
-  get_property(mlir_has_exports GLOBAL PROPERTY MLIR_HAS_EXPORTS)
-  if(mlir_has_exports)
-install(EXPORT MLIRTargets DESTINATION ${MLIR_INSTALL_PACKAGE_DIR}
-COMPONENT mlir-cmake-exports)
-  endif()
+  install_distribution_exports(MLIR)
 
   install(FILES
 ${CMAKE_CURRENT_BINARY_DIR}/CMakeFiles/MLIRConfig.cmake
Index: mlir/cmake/modules/AddMLIR.cmake
===
--- mlir/cmake/modules/AddMLIR.cmake
+++ mlir/cmake/modules/AddMLIR.cmake
@@ -1,3 +1,5 @@
+include(LLVMDistributionSupport)
+
 function(mlir_tablegen ofn)
   tablegen(MLIR ${ARGV})
   set(TABLEGEN_OUTPUT ${TABLEGEN_OUTPUT} ${CMAKE_CURRENT_BINARY_DIR}/${ofn}
@@ -141,14 +143,7 @@
 # where non-standard library builds can be installed.
 function(add_mlir_library_install name)
   if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY)
-  set(export_to_mlirtargets)
-  if (${name} IN_LIST LLVM_DISTRIBUTION_COMPONENTS OR
-  "mlir-libraries" IN_LIST LLVM_DISTRIBUTION_COMPONENTS OR
-  NOT LLVM_DISTRIBUTION_COMPONENTS)
-  set(export_to_mlirtargets EXPORT MLIRTargets)
-set_property(GLOBAL PROPERTY MLIR_HAS_EXPORTS True)
-  endif()
-
+  get_target_export_arg(${name} MLIR export_to_mlirtargets UMBRELLA mlir-libraries)
   install(TARGETS ${name}
 COMPONENT ${name}
 ${export_to_mlirtargets}
Index: llvm/docs/ReleaseNotes.rst
===
--- llvm/docs/ReleaseNotes.rst

[PATCH] D102343: [clang][patch][FPEnv} Initialization of C++ globals not strictfp aware

[Melanie Blower via Phabricator via cfe-commits]

mibintc added inline comments.



Comment at: clang/lib/CodeGen/CodeGenFunction.cpp:700
   CurCodeDecl = D;
-  if (const auto *FD = dyn_cast_or_null(D))
-if (FD->usesSEHTry())
-  CurSEHParent = FD;
+  const FunctionDecl *FD = dyn_cast_or_null(D);
+  if (FD && FD->usesSEHTry())

there's a whole bunch of places in this func that creates FD, I changed them 
into a single place. hope that's OK, or i could pull it out as a pre-patch if 
you prefer


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102343

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

[PATCH] D102343: [clang][patch][FPEnv} Initialization of C++ globals not strictfp aware

[Melanie Blower via Phabricator via cfe-commits]

mibintc created this revision.
mibintc added reviewers: kpn, rjmccall, aaron.ballman, pcc.
Herald added a subscriber: martong.
Herald added a reviewer: shafik.
mibintc requested review of this revision.
Herald added a project: clang.

In the proposed patch https://reviews.llvm.org/D81178 @kpn pointed out that the 
global variable initialization functions didn't have the "strictfp" metadata 
set correctly, and @rjmccall said that there was buggy code in SetFPModel and 
StartFunction, this patch is to solve those problems. When Sema creates a 
FunctionDecl, it sets the FunctionDeclBits.UsesFPIntrin to "true" if the 
lexical FP settings (i.e. a combination of command line options and #pragma 
float_control settings) correspond to ConstrainedFP mode.  That bit is used 
when CodeGen starts codegen for a llvm function, and it translates into the 
"strictfp" function attribute.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D102343

Files:
  clang/include/clang/AST/Decl.h
  clang/include/clang/AST/DeclCXX.h
  clang/lib/AST/ASTImporter.cpp
  clang/lib/AST/Decl.cpp
  clang/lib/AST/DeclCXX.cpp
  clang/lib/CodeGen/CGBlocks.cpp
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/CodeGen/CGNonTrivialStruct.cpp
  clang/lib/CodeGen/CGObjC.cpp
  clang/lib/CodeGen/CGStmtOpenMP.cpp
  clang/lib/CodeGen/CodeGenFunction.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/lib/CodeGen/ItaniumCXXABI.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/lib/Sema/SemaLambda.cpp
  clang/lib/Sema/SemaLookup.cpp
  clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
  clang/test/CodeGen/fp-floatcontrol-class.cpp
  clang/test/CodeGen/fp-floatcontrol-stack.cpp
  clang/unittests/Sema/ExternalSemaSourceTest.cpp

Index: clang/unittests/Sema/ExternalSemaSourceTest.cpp
===
--- clang/unittests/Sema/ExternalSemaSourceTest.cpp
+++ clang/unittests/Sema/ExternalSemaSourceTest.cpp
@@ -163,7 +163,8 @@
   CurrentSema->getPreprocessor().getIdentifierInfo(CorrectTo);
   auto *NewFunction = FunctionDecl::Create(
   Context, DestContext, SourceLocation(), SourceLocation(), ToIdent,
-  Context.getFunctionType(Context.VoidTy, {}, {}), nullptr, SC_Static);
+  Context.getFunctionType(Context.VoidTy, {}, {}), nullptr, SC_Static,
+  /*UsesFPIntrin*/ false);
   DestContext->addDecl(NewFunction);
   TypoCorrection Correction(ToIdent);
   Correction.addCorrectionDecl(NewFunction);
Index: clang/test/CodeGen/fp-floatcontrol-stack.cpp
===
--- clang/test/CodeGen/fp-floatcontrol-stack.cpp
+++ clang/test/CodeGen/fp-floatcontrol-stack.cpp
@@ -6,6 +6,10 @@
 #define FUN(n) \
   (float z) { return n * z + n; }
 
+// CHECK-DDEFAULT Function Attrs: noinline nounwind optnone mustprogress
+// CHECK-DEBSTRICT Function Attrs: noinline nounwind optnone strictfp mustprogress
+// CHECK-FAST: Function Attrs: noinline nounwind optnone mustprogress
+// CHECK-NOHONOR Function Attrs: noinline nounwind optnone mustprogress
 float fun_default FUN(1)
 //CHECK-LABEL: define {{.*}} @_Z11fun_defaultf{{.*}}
 #if DEFAULT
@@ -28,6 +32,10 @@
 // Rule: precise must be enabled
 #pragma float_control(except, on)
 #endif
+// CHECK-FAST: Function Attrs: noinline nounwind optnone mustprogress
+// CHECK-DDEFAULT Function Attrs: noinline nounwind optnone strictfp mustprogress
+// CHECK-DEBSTRICT Function Attrs: noinline nounwind optnone strictfp mustprogress
+// CHECK-NOHONOR Function Attrs: noinline nounwind optnone strictfp mustprogress
 float exc_on FUN(2)
 //CHECK-LABEL: define {{.*}} @_Z6exc_onf{{.*}}
 #if DEFAULT
@@ -46,7 +54,11 @@
 #endif
 
 #pragma float_control(pop)
-float exc_pop FUN(5)
+// CHECK-DDEFAULT Function Attrs: noinline nounwind optnone mustprogress
+// CHECK-DEBSTRICT Function Attrs: noinline nounwind optnone strictfp mustprogress
+// CHECK-FAST: Function Attrs: noinline nounwind optnone mustprogress
+// CHECK-NOHONOR Function Attrs: noinline nounwind optnone mustprogress
+float exc_pop FUN(5)
 //CHECK-LABEL: define {{.*}} @_Z7exc_popf{{.*}}
 #if DEFAULT
 //CHECK-DDEFAULT: call float @llvm.fmuladd{{.*}}
@@ -63,7 +75,7 @@
 #endif
 
 #pragma float_control(except, off)
-float exc_off FUN(5)
+float exc_off FUN(5)
 //CHECK-LABEL: define {{.*}} @_Z7exc_offf{{.*}}
 #if DEFAULT
 //CHECK-DDEFAULT: call float @llvm.fmuladd{{.*}}
@@ -80,7 +92,7 @@
 #endif
 
 #pragma float_control(precise, on, push)
-float precise_on FUN(3)
+float precise_on FUN(3)
 //CHECK-LABEL: define {{.*}} @_Z10precise_onf{{.*}}
 #if DEFAULT
 //CHECK-DDEFAULT: float {{.*}}llvm.fmuladd{{.*}}
@@ -97,7 +109,7 @@
 #endif
 
 #pragma float_control(pop)
-float precise_pop FUN(3)
+float precise_pop 

[PATCH] D102251: Suppress Deferred Diagnostics in discarded statements.

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

rsmith accepted this revision.
rsmith added inline comments.



Comment at: clang/include/clang/AST/EvaluatedExprVisitor.h:37
+  // 'constexpr-if'.
+  bool shouldVisitDiscardedCase() const { return true; }
 #define PTR(CLASS) typename Ptr::type

Maybe `shouldVisitDiscardedStmt` would be more obvious, since "discarded 
statement" is the standard terminology.


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

https://reviews.llvm.org/D102251

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

[PATCH] D100388: [BROKEN][clang] Try to fix thunk function types

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri updated this revision to Diff 344877.
lebedev.ri marked 2 inline comments as done.
lebedev.ri added a comment.

In D100388#2749115 , @efriedma wrote:

> Made a couple suggestions to make this easier to review.
>
> The test changes you've made so far seem reasonable.
>
> Is there some specific section of the code you want feedback on?

Thank you for taking a look!
Basically, i'm not sure this is right, and i'm not sure what is going wrong.
For example

  $ ./bin/llvm-lit 
/repositories/llvm-project/clang/test/CodeGen/available-externally-hidden.cpp -v
  llvm-lit: /repositories/llvm-project/llvm/utils/lit/lit/llvm/config.py:428: 
note: using clang: /builddirs/llvm-project/build-Clang12/bin/clang
  -- Testing: 1 tests, 1 workers --
  FAIL: Clang :: CodeGen/available-externally-hidden.cpp (1 of 1)
   TEST 'Clang :: CodeGen/available-externally-hidden.cpp' 
FAILED 
  Script:
  --
  : 'RUN: at line 1';   /builddirs/llvm-project/build-Clang12/bin/clang -cc1 
-internal-isystem 
/builddirs/llvm-project/build-Clang12/lib/clang/13.0.0/include -nostdsysteminc 
-O2 -fvisibility hidden -std=c++11 -emit-llvm -o - -triple 
x86_64-apple-darwin10 
/repositories/llvm-project/clang/test/CodeGen/available-externally-hidden.cpp | 
/builddirs/llvm-project/build-Clang12/bin/FileCheck 
/repositories/llvm-project/clang/test/CodeGen/available-externally-hidden.cpp
  --
  Exit Code: 2
  
  Command Output (stderr):
  --
  
/repositories/llvm-project/clang/test/CodeGen/available-externally-hidden.cpp:14:16:
 error: cannot compile this thunk for forward declaration yet
virtual bool Send(Message* msg) = 0;
 ^
  1 error generated.
  FileCheck error: '' is empty.
  FileCheck command line:  /builddirs/llvm-project/build-Clang12/bin/FileCheck 
/repositories/llvm-project/clang/test/CodeGen/available-externally-hidden.cpp
  
  --
  
  
  
  Failed Tests (1):
Clang :: CodeGen/available-externally-hidden.cpp
  
  
  Testing Time: 0.18s
Failed: 1

Would it be reasonable to instead start with a stopgap measure of not adding 
attributes for `this`/return of thunks?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100388

Files:
  clang/include/clang/AST/VTableBuilder.h
  clang/include/clang/Basic/Thunk.h
  clang/lib/AST/MicrosoftMangle.cpp
  clang/lib/AST/VTableBuilder.cpp
  clang/lib/CodeGen/CGVTables.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/lib/CodeGen/MicrosoftCXXABI.cpp
  clang/test/CodeGen/available-externally-hidden.cpp
  clang/test/CodeGenCXX/RelativeVTablesABI/diamond-inheritance.cpp
  clang/test/CodeGenCXX/RelativeVTablesABI/multiple-inheritance.cpp
  clang/test/CodeGenCXX/thunk-linkonce-odr.cpp
  clang/test/CodeGenCXX/thunk-returning-memptr.cpp
  clang/test/CodeGenCXX/thunk-wrong-return-type.cpp
  clang/test/CodeGenCXX/thunk-wrong-this.cpp
  clang/test/CodeGenCXX/thunks.cpp

Index: clang/test/CodeGenCXX/thunks.cpp
===
--- clang/test/CodeGenCXX/thunks.cpp
+++ clang/test/CodeGenCXX/thunks.cpp
@@ -410,7 +410,7 @@
   // CHECK: getelementptr inbounds i8, i8* {{.*}}, i64 -32
   // CHECK: getelementptr inbounds i8, i8* {{.*}}, i64 -24
   // CHECK: getelementptr inbounds i8, i8* {{.*}}, i64 8
-  // CHECK: ret %"struct.Test13::D"*
+  // CHECK: ret %"struct.Test13::B1"*
 
   // WIN64-LABEL: define weak_odr dso_local nonnull align 8 dereferenceable(8) %"struct.Test13::D"* @"?foo1@D@Test13@@$4PPPE@A@EAAAEAUB1@2@XZ"(
   //This adjustment.
Index: clang/test/CodeGenCXX/thunk-wrong-this.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/thunk-wrong-this.cpp
@@ -0,0 +1,21 @@
+// RUN: %clang_cc1 -emit-llvm-only -triple %itanium_abi_triple %s -emit-llvm -o - %s | FileCheck %s
+
+class Base1 {
+  virtual void Foo1();
+};
+
+class Base2 {
+  virtual void Foo2();
+};
+
+class alignas(16) Obj : public Base1, public Base2 {
+  void Foo1() override;
+  void Foo2() override;
+  ~Obj();
+};
+
+void Obj::Foo1() {}
+void Obj::Foo2() {}
+
+// CHECK: define dso_local void @_ZThn8_N3Obj4Foo2Ev(%class.Base2.2* nonnull dereferenceable(8) %this) #1 align 2 {
+// CHECK: tail call void @_ZN3Obj4Foo2Ev(%class.Obj.0* nonnull dereferenceable(16) %3)
Index: clang/test/CodeGenCXX/thunk-wrong-return-type.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/thunk-wrong-return-type.cpp
@@ -0,0 +1,25 @@
+// RUN: %clang_cc1 -emit-llvm-only -triple %itanium_abi_triple %s -emit-llvm -o - %s | FileCheck %s
+
+struct A {};
+struct alignas(32) B : virtual A {
+  char c[32];
+};
+struct Pad {
+  char c[7];
+};
+struct C : B, Pad, virtual A {};
+
+struct X {
+  virtual A ();
+};
+struct U {
+  virtual ~U();
+};
+C c;
+struct Y : U, X {
+  virtual B () 

Re: [clang] 1470b85 - Remove AST inclusion from Basic include

[Roman Lebedev via cfe-commits]

Thanks!

On Wed, May 12, 2021 at 8:56 PM Benjamin Kramer via cfe-commits
 wrote:
>
>
> Author: Benjamin Kramer
> Date: 2021-05-12T19:51:21+02:00
> New Revision: 1470b8587f6fdc357163c2258747b77ae9ad6d7a
>
> URL: 
> https://github.com/llvm/llvm-project/commit/1470b8587f6fdc357163c2258747b77ae9ad6d7a
> DIFF: 
> https://github.com/llvm/llvm-project/commit/1470b8587f6fdc357163c2258747b77ae9ad6d7a.diff
>
> LOG: Remove AST inclusion from Basic include
>
> That's a cyclic dependency. NFC.
>
> Added:
>
>
> Modified:
> clang/include/clang/Basic/Thunk.h
>
> Removed:
>
>
>
> 
> diff  --git a/clang/include/clang/Basic/Thunk.h 
> b/clang/include/clang/Basic/Thunk.h
> index 7f3c4b24ec6d..91088be6ae73 100644
> --- a/clang/include/clang/Basic/Thunk.h
> +++ b/clang/include/clang/Basic/Thunk.h
> @@ -15,10 +15,13 @@
>  #ifndef LLVM_CLANG_BASIC_THUNK_H
>  #define LLVM_CLANG_BASIC_THUNK_H
>
> -#include "clang/AST/GlobalDecl.h"
> +#include 
> +#include 
>
>  namespace clang {
>
> +class CXXMethodDecl;
> +
>  /// A return adjustment.
>  struct ReturnAdjustment {
>/// The non-virtual adjustment from the derived object to its
>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D102244: [llvm][AsmPrinter] Restore source location to register clobber warning

[Yuanfang Chen via Phabricator via cfe-commits]

ychen added a comment.

Looks good except for one suggestion and the patch need rebasing on an upstream 
commit.




Comment at: llvm/include/llvm/IR/LLVMContext.h:300
+  /// with "warning: " and should not end with a ".".
+  void emitWarning(unsigned LocCookie, const Twine );
+

It would be best to avoid adding these two methods for single-use since 
`LLVMContext.h` is included everywhere. We could add them once it turns out to 
be needed in other places. Could we use `LLVMContext::diagnose` instead?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102244

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

[PATCH] D102339: [clang] On Windows, ignore case and separators when discarding duplicate dependency file paths.

[Sylvain Audi via Phabricator via cfe-commits]

saudi created this revision.
saudi added reviewers: rnk, thakis, dexonsmith, Bigcheese.
saudi added a project: clang.
saudi requested review of this revision.
Herald added a subscriber: cfe-commits.

We noticed that the dependency collectors of `clang` may report duplicate paths 
under Windows, when the differences are only in casing or separators (`/` vs 
`\`)
This problem affects the correctness of the information output by 
`clang-scan-deps`, which in turn, affects our integration with the `Fastbuild` 
cache.

For separators, it can happen as clang internally computes the full path of a 
header from an `#include` directive using native separator.

Example with argument `-I C:\includes`:
 `#include `  -> internally represented in the `FileManager` 
as `C:\includes\subdir/header.h`
 `#include "header.h"` from another header in `subdir` folder  -> 
`C:\includes\subdir\header.h`

The same applies with casing discrepancies that can be found sometimes in 
headers from external SDKs.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D102339

Files:
  clang/lib/Frontend/DependencyFile.cpp
  clang/test/Frontend/dependency-gen-windows-duplicates.c


Index: clang/test/Frontend/dependency-gen-windows-duplicates.c
===
--- /dev/null
+++ clang/test/Frontend/dependency-gen-windows-duplicates.c
@@ -0,0 +1,27 @@
+// REQUIRES: system-windows
+
+// RUN: rm -rf %t.dir
+// RUN: mkdir -p %t.dir/subdir
+// RUN: echo > %t.dir/subdir/x.h
+// RUN: cp %s %t.dir/test.c
+// RUN: cd %t.dir
+
+// RUN: %clang -MD -MF - %t.dir/test.c -fsyntax-only -I %t.dir/subdir | 
FileCheck --ignore-case %s
+// CHECK: test.o:
+// CHECK-NEXT: \test.c
+// CHECK-NEXT: \subdir\x.h
+// File x.h must appear only once (case insensitive check).
+// CHECK-NOT: x.h
+
+// Include x.h several times, with different casing and separators.
+// Since all paths are passed to clang as absolute, all dependencies are 
absolute paths.
+// We expect the output dependencies to contain only one line for file x.h
+
+// Test case sensitivity.
+#include "subdir/x.h"
+#include "SubDir/X.h"
+
+// Test separator sensitivity:
+// clang will internally concatenates x.h paths using the Windows native 
separator.
+#include 
+
Index: clang/lib/Frontend/DependencyFile.cpp
===
--- clang/lib/Frontend/DependencyFile.cpp
+++ clang/lib/Frontend/DependencyFile.cpp
@@ -141,7 +141,18 @@
 }
 
 bool DependencyCollector::addDependency(StringRef Filename) {
-  if (Seen.insert(Filename).second) {
+  StringRef SearchPath;
+#ifdef _WIN32
+  // Make the search insensitive to case and separators.
+  llvm::SmallString<256> TmpPath = Filename;
+  std::replace(TmpPath.begin(), TmpPath.end(), '/', '\\');
+  std::transform(TmpPath.begin(), TmpPath.end(), TmpPath.begin(), ::tolower);
+  SearchPath = TmpPath.str();
+#else
+  SearchPath = Filename;
+#endif
+
+  if (Seen.insert(SearchPath).second) {
 Dependencies.push_back(std::string(Filename));
 return true;
   }


Index: clang/test/Frontend/dependency-gen-windows-duplicates.c
===
--- /dev/null
+++ clang/test/Frontend/dependency-gen-windows-duplicates.c
@@ -0,0 +1,27 @@
+// REQUIRES: system-windows
+
+// RUN: rm -rf %t.dir
+// RUN: mkdir -p %t.dir/subdir
+// RUN: echo > %t.dir/subdir/x.h
+// RUN: cp %s %t.dir/test.c
+// RUN: cd %t.dir
+
+// RUN: %clang -MD -MF - %t.dir/test.c -fsyntax-only -I %t.dir/subdir | FileCheck --ignore-case %s
+// CHECK: test.o:
+// CHECK-NEXT: \test.c
+// CHECK-NEXT: \subdir\x.h
+// File x.h must appear only once (case insensitive check).
+// CHECK-NOT: x.h
+
+// Include x.h several times, with different casing and separators.
+// Since all paths are passed to clang as absolute, all dependencies are absolute paths.
+// We expect the output dependencies to contain only one line for file x.h
+
+// Test case sensitivity.
+#include "subdir/x.h"
+#include "SubDir/X.h"
+
+// Test separator sensitivity:
+// clang will internally concatenates x.h paths using the Windows native separator.
+#include 
+
Index: clang/lib/Frontend/DependencyFile.cpp
===
--- clang/lib/Frontend/DependencyFile.cpp
+++ clang/lib/Frontend/DependencyFile.cpp
@@ -141,7 +141,18 @@
 }
 
 bool DependencyCollector::addDependency(StringRef Filename) {
-  if (Seen.insert(Filename).second) {
+  StringRef SearchPath;
+#ifdef _WIN32
+  // Make the search insensitive to case and separators.
+  llvm::SmallString<256> TmpPath = Filename;
+  std::replace(TmpPath.begin(), TmpPath.end(), '/', '\\');
+  std::transform(TmpPath.begin(), TmpPath.end(), TmpPath.begin(), ::tolower);
+  SearchPath = TmpPath.str();
+#else
+  SearchPath = Filename;
+#endif
+
+  if (Seen.insert(SearchPath).second) {
 Dependencies.push_back(std::string(Filename));
 return true;
   }

[clang] 1470b85 - Remove AST inclusion from Basic include

[Benjamin Kramer via cfe-commits]

Author: Benjamin Kramer
Date: 2021-05-12T19:51:21+02:00
New Revision: 1470b8587f6fdc357163c2258747b77ae9ad6d7a

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

LOG: Remove AST inclusion from Basic include

That's a cyclic dependency. NFC.

Added: 


Modified: 
clang/include/clang/Basic/Thunk.h

Removed: 




diff  --git a/clang/include/clang/Basic/Thunk.h 
b/clang/include/clang/Basic/Thunk.h
index 7f3c4b24ec6d..91088be6ae73 100644
--- a/clang/include/clang/Basic/Thunk.h
+++ b/clang/include/clang/Basic/Thunk.h
@@ -15,10 +15,13 @@
 #ifndef LLVM_CLANG_BASIC_THUNK_H
 #define LLVM_CLANG_BASIC_THUNK_H
 
-#include "clang/AST/GlobalDecl.h"
+#include 
+#include 
 
 namespace clang {
 
+class CXXMethodDecl;
+
 /// A return adjustment.
 struct ReturnAdjustment {
   /// The non-virtual adjustment from the derived object to its



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

[PATCH] D102338: [Sema] Always search the full function scope context if a potential availability violation is encountered

[Logan Smith via Phabricator via cfe-commits]

logan-5 created this revision.
logan-5 added reviewers: erik.pilkington, rsmith, arphaman.
logan-5 added a project: clang.
logan-5 requested review of this revision.
Herald added a subscriber: cfe-commits.

Always search the full function scope context if a potential availability 
violation is encountered. This fixes both 
https://bugs.llvm.org/show_bug.cgi?id=50309 and 
https://bugs.llvm.org/show_bug.cgi?id=50310.

Previously, lambdas inside functions would mark their own bodies for later 
analysis when encountering a potentially unavailable decl, without taking into 
consideration that the entire lambda itself might be correctly guarded inside 
an `@available` check. The same applied to inner class member functions. Blocks 
happened to work as expected already, since `Sema::getEnclosingFunction()` 
skips through block scopes.

This patch instead simply and conservatively marks the entire outermost 
function scope for search, and removes some special-case logic that prevented 
`DiagnoseUnguardedAvailabilityViolations` from traversing down into lambdas and 
nested functions. This correctly accounts for arbitrarily nested lambdas, inner 
classes, and blocks that may be inside appropriate `@available` checks at any 
ancestor level. It also treats all potential availability violations inside 
functions consistently, without being overly sensitive to the current 
DeclContext, which previously caused issues where e.g. nested struct members 
were warned about twice.

`DiagnoseUnguardedAvailabilityViolations` now has more work to do in some 
cases, particularly in functions with many (possibly deeply) nested lambdas and 
classes, but the big-O is the same, and the simplicity of the approach and the 
fact that it fixes at least two bugs feels like a strong win IMO.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D102338

Files:
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/SemaAvailability.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/test/SemaObjC/unguarded-availability.m

Index: clang/test/SemaObjC/unguarded-availability.m
===
--- clang/test/SemaObjC/unguarded-availability.m
+++ clang/test/SemaObjC/unguarded-availability.m
@@ -125,6 +125,14 @@
   (void) ^{
 func_10_12(); // expected-warning{{'func_10_12' is only available on macOS 10.12 or newer}} expected-note{{@available}}
   };
+
+  if (@available(macos 10.12, *))
+(void) ^{
+  func_10_12();
+  (void) ^{
+func_10_12();
+  };
+};
 }
 
 void test_params(int_10_12 x); // expected-warning {{'int_10_12' is only available on macOS 10.12 or newer}} expected-note{{annotate 'test_params' with an availability attribute to silence this warning}}
@@ -233,6 +241,36 @@
   (void)(^ {
 func_10_12(); // expected-warning{{'func_10_12' is only available on macOS 10.12 or newer}} expected-note{{@available}}
   });
+
+  if (@available(macos 10.12, *)) {
+void([]() {
+  func_10_12();
+  void([] () {
+func_10_12();
+  });
+  struct DontWarn {
+void f() {
+  func_10_12();
+}
+  };
+});
+  }
+
+  if (@available(macos 10.12, *)) {
+struct DontWarn {
+  void f() {
+func_10_12();
+void([] () {
+  func_10_12();
+});
+struct DontWarn2 {
+  void f() {
+func_10_12();
+  }
+};
+  }
+};
+  }
 }
 
 #endif
@@ -259,9 +297,14 @@
 @end
 
 void with_local_struct() {
-  struct local { // expected-note{{annotate 'local' with an availability attribute}}
-new_int x; // expected-warning{{'new_int' is only available}}
+  struct local { 
+new_int x; // expected-warning{{'new_int' is only available}} expected-note{{enclose 'new_int' in an @available check}}
   };
+  if (@available(macos 10.12, *)) {
+struct DontWarn {
+  new_int x;
+};
+  }
 }
 
 // rdar://33156429:
Index: clang/lib/Sema/SemaExpr.cpp
===
--- clang/lib/Sema/SemaExpr.cpp
+++ clang/lib/Sema/SemaExpr.cpp
@@ -19653,12 +19653,10 @@
   if (Spec != AvailSpecs.end())
 Version = Spec->getVersion();
 
-  // The use of `@available` in the enclosing function should be analyzed to
+  // The use of `@available` in the enclosing context should be analyzed to
   // warn when it's used inappropriately (i.e. not if(@available)).
-  if (getCurFunctionOrMethodDecl())
-getEnclosingFunction()->HasPotentialAvailabilityViolations = true;
-  else if (getCurBlock() || getCurLambda())
-getCurFunction()->HasPotentialAvailabilityViolations = true;
+  if (FunctionScopeInfo *Context = getCurFunctionAvailabilityContext())
+Context->HasPotentialAvailabilityViolations = true;
 
   return new (Context)
   ObjCAvailabilityCheckExpr(Version, AtLoc, RParen, Context.BoolTy);
Index: clang/lib/Sema/SemaAvailability.cpp
===
--- 

[PATCH] D98798: Produce warning for performing pointer arithmetic on a null pointer.

[Nico Weber via Phabricator via cfe-commits]

thakis added a comment.

(Now completed the reply, see phab.)

In D98798#2754635 , @xbolva00 wrote:

> You dont have to use -Wno-…
>
> You can use pragma to disable this warning for certain location in the code, 
> eg include of commctrl.h.

commctrl.h is included by other system headers too though.

I don't think requiring users to add pragmas in all files that transitively 
include a random subset of windows headers is great :) I'm fine with not 
reverting if a fix for this will happen soon, but it sounds like the author is 
away for a few days. Reverts are cheap.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98798

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

[PATCH] D98798: Produce warning for performing pointer arithmetic on a null pointer.

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

xbolva00 added a comment.

You dont have to use -Wno-…

You can use pragma to disable this warning for certain location in the code.

-1 for revert just because of this reason.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98798

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

[PATCH] D98798: Produce warning for performing pointer arithmetic on a null pointer.

[Nico Weber via Phabricator via cfe-commits]

thakis added a comment.

(sorry, accidentally hit cmd-enter, not actually done writing)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98798

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

[PATCH] D98798: Produce warning for performing pointer arithmetic on a null pointer.

[Nico Weber via Phabricator via cfe-commits]

thakis added a comment.

In D98798#2754449 , @jamieschmeiser 
wrote:

> @thakis, I have some questions about your comments.
> Are you sure this is coming from a system header?  The path that you gave has 
> third_party as a directory in the path.

Yes. `third_party\depot_tools\win_toolchain\vs_files\20d5f2553f\Windows 
Kits\10\Include\10.0.19041.0\um\commctrl.h` is a hermetic system directory used 
via `/winsysrootthird_party\depot_tools\win_toolchain\vs_files\20d5f2553f`.

> If the warning were being triggered by code in a system header, I would have 
> expected it to fire on something in the windows build bots but they appear to 
> be clean.

I don't think LLVM uses a lot of code from the windows system headers. The 
compiler doesn't contain any UI :) (commctrl.h is a UI header).

> I don't know if it is possible to suppress a warning based on whether the 
> source is in a system header, or from a macro expansion that is defined in a 
> system header; are you aware about whether or not this is possible?



> If it is, I suspect it would already be in force as a general setting, again 
> making me question whether this is a system header...and if it isn't a system 
> header, that wouldn't help you in any case.
> If I understand your second point correctly, you have a system that 
> previously compiled cleanly with warnings being treated as errors and you are 
> concerned that if you use the existing options to suppress this particular 
> warning, you are concerned that something could creep in.  Therefore you are 
> proposing a different warning group that would be a subgroup of the existing 
> one so that if you set it, you would set both but you would still be able to 
> set the specific one.  I don't know if this is possible or not.  Either way, 
> I suspect that it would require using a different warning for the subtraction 
> case, which would also require significantly changing these changes. Am I 
> understanding correctly?  If so, this implies that you have access to a 
> workaround for your problem, although it may not be the best solution.
> I do not have access to a windows setup to test any of these proposed 
> changes; in particular, given that I suspect that the affected files are 
> specific to some third party vendor from which you have purchased code, I do 
> not have means of investigating the actual problems/solutions.  If it would 
> be helpful, I would be happy to review any changes that you might like to 
> make to remedy the situation.
> I will be on vacation for the next few days so please excuse my delayed 
> responses.




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98798

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

[clang] 2d84195 - [NFCI][clang][Codegen] CodeGenVTables::addVTableComponent(): use getGlobalDecl

[Roman Lebedev via cfe-commits]

Author: Roman Lebedev
Date: 2021-05-12T20:39:54+03:00
New Revision: 2d84195d60b0cb5ea43b18ab8f6770a84bf32da4

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

LOG: [NFCI][clang][Codegen] CodeGenVTables::addVTableComponent(): use 
getGlobalDecl

It does the same thing.
Split off from https://reviews.llvm.org/D100388

Added: 


Modified: 
clang/lib/CodeGen/CGVTables.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGVTables.cpp b/clang/lib/CodeGen/CGVTables.cpp
index bef9a293b7ed5..a8e3a669353c3 100644
--- a/clang/lib/CodeGen/CGVTables.cpp
+++ b/clang/lib/CodeGen/CGVTables.cpp
@@ -727,22 +727,7 @@ void 
CodeGenVTables::addVTableComponent(ConstantArrayBuilder ,
   case VTableComponent::CK_FunctionPointer:
   case VTableComponent::CK_CompleteDtorPointer:
   case VTableComponent::CK_DeletingDtorPointer: {
-GlobalDecl GD;
-
-// Get the right global decl.
-switch (component.getKind()) {
-default:
-  llvm_unreachable("Unexpected vtable component kind");
-case VTableComponent::CK_FunctionPointer:
-  GD = component.getFunctionDecl();
-  break;
-case VTableComponent::CK_CompleteDtorPointer:
-  GD = GlobalDecl(component.getDestructorDecl(), Dtor_Complete);
-  break;
-case VTableComponent::CK_DeletingDtorPointer:
-  GD = GlobalDecl(component.getDestructorDecl(), Dtor_Deleting);
-  break;
-}
+GlobalDecl GD = component.getGlobalDecl();
 
 if (CGM.getLangOpts().CUDA) {
   // Emit NULL for methods we can't codegen on this



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

[clang] 81f56a2 - [NFC][clang][Codegen] Split ThunkInfo into it's own header

[Roman Lebedev via cfe-commits]

Author: Roman Lebedev
Date: 2021-05-12T20:39:54+03:00
New Revision: 81f56a2eb3797eb5be61d65a8f7d7e19456e67d1

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

LOG: [NFC][clang][Codegen] Split ThunkInfo into it's own header

Otherwise we'll have issues with forward definition of GlobalDecl.

Split off from https://reviews.llvm.org/D100388

Added: 
clang/include/clang/Basic/Thunk.h

Modified: 
clang/include/clang/AST/VTableBuilder.h
clang/include/clang/Basic/ABI.h
clang/lib/AST/ItaniumMangle.cpp

Removed: 




diff  --git a/clang/include/clang/AST/VTableBuilder.h 
b/clang/include/clang/AST/VTableBuilder.h
index 241dd13f903e5..e451f3f861b79 100644
--- a/clang/include/clang/AST/VTableBuilder.h
+++ b/clang/include/clang/AST/VTableBuilder.h
@@ -18,6 +18,7 @@
 #include "clang/AST/GlobalDecl.h"
 #include "clang/AST/RecordLayout.h"
 #include "clang/Basic/ABI.h"
+#include "clang/Basic/Thunk.h"
 #include "llvm/ADT/DenseMap.h"
 #include 
 #include 

diff  --git a/clang/include/clang/Basic/ABI.h b/clang/include/clang/Basic/ABI.h
index 2401ffa20494e..231bad799a42c 100644
--- a/clang/include/clang/Basic/ABI.h
+++ b/clang/include/clang/Basic/ABI.h
@@ -37,174 +37,6 @@ enum CXXDtorType {
 Dtor_Comdat///< The COMDAT used for dtors
 };
 
-/// A return adjustment.
-struct ReturnAdjustment {
-  /// The non-virtual adjustment from the derived object to its
-  /// nearest virtual base.
-  int64_t NonVirtual;
-
-  /// Holds the ABI-specific information about the virtual return
-  /// adjustment, if needed.
-  union VirtualAdjustment {
-// Itanium ABI
-struct {
-  /// The offset (in bytes), relative to the address point
-  /// of the virtual base class offset.
-  int64_t VBaseOffsetOffset;
-} Itanium;
-
-// Microsoft ABI
-struct {
-  /// The offset (in bytes) of the vbptr, relative to the beginning
-  /// of the derived class.
-  uint32_t VBPtrOffset;
-
-  /// Index of the virtual base in the vbtable.
-  uint32_t VBIndex;
-} Microsoft;
-
-VirtualAdjustment() {
-  memset(this, 0, sizeof(*this));
-}
-
-bool Equals(const VirtualAdjustment ) const {
-  return memcmp(this, , sizeof(Other)) == 0;
-}
-
-bool isEmpty() const {
-  VirtualAdjustment Zero;
-  return Equals(Zero);
-}
-
-bool Less(const VirtualAdjustment ) const {
-  return memcmp(this, , sizeof(RHS)) < 0;
-}
-  } Virtual;
-
-  ReturnAdjustment() : NonVirtual(0) {}
-
-  bool isEmpty() const { return !NonVirtual && Virtual.isEmpty(); }
-
-  friend bool operator==(const ReturnAdjustment ,
- const ReturnAdjustment ) {
-return LHS.NonVirtual == RHS.NonVirtual && LHS.Virtual.Equals(RHS.Virtual);
-  }
-
-  friend bool operator!=(const ReturnAdjustment , const ReturnAdjustment 
) {
-return !(LHS == RHS);
-  }
-
-  friend bool operator<(const ReturnAdjustment ,
-const ReturnAdjustment ) {
-if (LHS.NonVirtual < RHS.NonVirtual)
-  return true;
-
-return LHS.NonVirtual == RHS.NonVirtual && LHS.Virtual.Less(RHS.Virtual);
-  }
-};
-
-/// A \c this pointer adjustment.
-struct ThisAdjustment {
-  /// The non-virtual adjustment from the derived object to its
-  /// nearest virtual base.
-  int64_t NonVirtual;
-
-  /// Holds the ABI-specific information about the virtual this
-  /// adjustment, if needed.
-  union VirtualAdjustment {
-// Itanium ABI
-struct {
-  /// The offset (in bytes), relative to the address point,
-  /// of the virtual call offset.
-  int64_t VCallOffsetOffset;
-} Itanium;
-
-struct {
-  /// The offset of the vtordisp (in bytes), relative to the ECX.
-  int32_t VtordispOffset;
-
-  /// The offset of the vbptr of the derived class (in bytes),
-  /// relative to the ECX after vtordisp adjustment.
-  int32_t VBPtrOffset;
-
-  /// The offset (in bytes) of the vbase offset in the vbtable.
-  int32_t VBOffsetOffset;
-} Microsoft;
-
-VirtualAdjustment() {
-  memset(this, 0, sizeof(*this));
-}
-
-bool Equals(const VirtualAdjustment ) const {
-  return memcmp(this, , sizeof(Other)) == 0;
-}
-
-bool isEmpty() const {
-  VirtualAdjustment Zero;
-  return Equals(Zero);
-}
-
-bool Less(const VirtualAdjustment ) const {
-  return memcmp(this, , sizeof(RHS)) < 0;
-}
-  } Virtual;
-
-  ThisAdjustment() : NonVirtual(0) { }
-
-  bool isEmpty() const { return !NonVirtual && Virtual.isEmpty(); }
-
-  friend bool operator==(const ThisAdjustment ,
- const ThisAdjustment ) {
-return LHS.NonVirtual == RHS.NonVirtual && LHS.Virtual.Equals(RHS.Virtual);
-  }
-
-  friend bool operator!=(const ThisAdjustment , const ThisAdjustment ) 
{
-

[PATCH] D102322: [clang-tidy] Add '-target' CLI option to override target triple

[Georgy Komarov via Phabricator via cfe-commits]

jubnzv abandoned this revision.
jubnzv added a comment.

Thank you, I didn't know that it is possible to set the target triple using 
`--extra-arg`. I created a new revision with this fix: 
https://reviews.llvm.org/D102337.
For some reasons, the `--target=unknown-windows` doesn't work for me with the 
following error: `error: unknown target triple 
'unknown-unknown-windows-msvc19.11.0', please use -triple or -arch 
[clang-diagnostic-error]`.
But `--target=x86_64-windows` works fine.


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

https://reviews.llvm.org/D102322

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

[PATCH] D102090: [CMake][ELF] Add -fno-semantic-interposition and -Bsymbolic-functions

[Fangrui Song via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG3bf1acab5b45: [CMake][ELF] Add -fno-semantic-interposition 
and -Bsymbolic-functions (authored by MaskRay).

Changed prior to commit:
  https://reviews.llvm.org/D102090?vs=343758=344866#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102090

Files:
  clang/tools/clang-shlib/CMakeLists.txt
  llvm/cmake/modules/HandleLLVMOptions.cmake
  llvm/tools/llvm-shlib/CMakeLists.txt


Index: llvm/tools/llvm-shlib/CMakeLists.txt
===
--- llvm/tools/llvm-shlib/CMakeLists.txt
+++ llvm/tools/llvm-shlib/CMakeLists.txt
@@ -50,6 +50,9 @@
   # Solaris ld does not accept global: *; so there is no way to version 
*all* global symbols
   set(LIB_NAMES 
-Wl,--version-script,${LLVM_LIBRARY_DIR}/tools/llvm-shlib/simple_version_script.map
 ${LIB_NAMES})
 endif()
+# Optimize function calls and global variable access for default visibility
+# definitions to avoid PLT and reduce dynamic relocations.
+target_link_options(LLVM PRIVATE LINKER:-Bsymbolic-functions)
   elseif("${CMAKE_SYSTEM_NAME}" STREQUAL "Darwin")
 set(LIB_NAMES -Wl,-all_load ${LIB_NAMES})
   endif()
Index: llvm/cmake/modules/HandleLLVMOptions.cmake
===
--- llvm/cmake/modules/HandleLLVMOptions.cmake
+++ llvm/cmake/modules/HandleLLVMOptions.cmake
@@ -305,6 +305,7 @@
 # On Windows all code is PIC. MinGW warns if -fPIC is used.
   else()
 add_flag_or_print_warning("-fPIC" FPIC)
+add_flag_if_supported("-fno-semantic-interposition" 
FNO_SEMANTIC_INTERPOSITION)
   endif()
   # GCC for MIPS can miscompile LLVM due to PR37701.
   if(CMAKE_COMPILER_IS_GNUCXX AND LLVM_NATIVE_ARCH STREQUAL "Mips" AND
Index: clang/tools/clang-shlib/CMakeLists.txt
===
--- clang/tools/clang-shlib/CMakeLists.txt
+++ clang/tools/clang-shlib/CMakeLists.txt
@@ -48,3 +48,8 @@
   ${_OBJECTS}
   LINK_LIBS
   ${_DEPS})
+# Optimize function calls and global variable access for default visibility
+# definitions to avoid PLT and reduce dynamic relocations.
+if (NOT APPLE)
+  target_link_options(clang-cpp PRIVATE LINKER:-Bsymbolic-functions)
+endif()


Index: llvm/tools/llvm-shlib/CMakeLists.txt
===
--- llvm/tools/llvm-shlib/CMakeLists.txt
+++ llvm/tools/llvm-shlib/CMakeLists.txt
@@ -50,6 +50,9 @@
   # Solaris ld does not accept global: *; so there is no way to version *all* global symbols
   set(LIB_NAMES -Wl,--version-script,${LLVM_LIBRARY_DIR}/tools/llvm-shlib/simple_version_script.map ${LIB_NAMES})
 endif()
+# Optimize function calls and global variable access for default visibility
+# definitions to avoid PLT and reduce dynamic relocations.
+target_link_options(LLVM PRIVATE LINKER:-Bsymbolic-functions)
   elseif("${CMAKE_SYSTEM_NAME}" STREQUAL "Darwin")
 set(LIB_NAMES -Wl,-all_load ${LIB_NAMES})
   endif()
Index: llvm/cmake/modules/HandleLLVMOptions.cmake
===
--- llvm/cmake/modules/HandleLLVMOptions.cmake
+++ llvm/cmake/modules/HandleLLVMOptions.cmake
@@ -305,6 +305,7 @@
 # On Windows all code is PIC. MinGW warns if -fPIC is used.
   else()
 add_flag_or_print_warning("-fPIC" FPIC)
+add_flag_if_supported("-fno-semantic-interposition" FNO_SEMANTIC_INTERPOSITION)
   endif()
   # GCC for MIPS can miscompile LLVM due to PR37701.
   if(CMAKE_COMPILER_IS_GNUCXX AND LLVM_NATIVE_ARCH STREQUAL "Mips" AND
Index: clang/tools/clang-shlib/CMakeLists.txt
===
--- clang/tools/clang-shlib/CMakeLists.txt
+++ clang/tools/clang-shlib/CMakeLists.txt
@@ -48,3 +48,8 @@
   ${_OBJECTS}
   LINK_LIBS
   ${_DEPS})
+# Optimize function calls and global variable access for default visibility
+# definitions to avoid PLT and reduce dynamic relocations.
+if (NOT APPLE)
+  target_link_options(clang-cpp PRIVATE LINKER:-Bsymbolic-functions)
+endif()
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 3bf1aca - [CMake][ELF] Add -fno-semantic-interposition and -Bsymbolic-functions

[Fangrui Song via cfe-commits]

Author: Fangrui Song
Date: 2021-05-12T10:34:31-07:00
New Revision: 3bf1acab5b454ad7fb2074b34663108b53620695

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

LOG: [CMake][ELF] Add -fno-semantic-interposition and -Bsymbolic-functions

llvm-dev message: https://lists.llvm.org/pipermail/llvm-dev/2021-May/150465.html

In an ELF shared object, a default visibility defined symbol is preemptible by 
default.
This creates some missed optimization opportunities. 
-fno-semantic-interposition can optimize -fPIC:

* in Clang: avoid GOT/PLT cost for variable access/function calls to external 
linkage definition in the same TU
* in GCC: enable interprocedural optimizations (including inlining) and avoid 
PLT

See https://gist.github.com/MaskRay/2d4dfcfc897341163f734afb59f689c6 for more 
information.

-Bsymbolic-functions is more aggressive than -fvisibility-inlines-hidden 
(present since 2012) as it applies
to all function definitions.  It can

* avoid PLT for cross-TU function calls && reduce dynamic symbol lookup
* reduce dynamic symbol lookup for taking function addresses and optimize out 
GOT/TOC on x86-64/ppc64

With both options, the libLLVM.so and libclang-cpp.so performance should
be closer to PIE binary linking against `libLLVM*.a` and `libclang*.a`

(In a -DLLVM_TARGETS_TO_BUILD=X86 build, the number of JUMP_SLOT decreases from 
12716 to 1628, and the number of GLOB_DAT decreases from 1918 to 1313
The built clang with `-DLLVM_LINK_LLVM_DYLIB=on -DCLANG_LINK_CLANG_DYLIB=on` is 
significantly faster.
See the Linux kernel build result https://bugs.archlinux.org/task/70697
)

Some implication:

Interposing a subset of functions is no longer supported.
(This is fragile anyway and cannot really be supported. For Mach-O we don't use
`ld -interpose`, so interposition is not supported on Mach-O at all.)

Compiling a program which takes the address of any LLVM function with
`{gcc,clang} -fno-pic` and expects the address to equal to the address taken
from libLLVM.so or libclang-cpp.so is unsupported. I am fairly confident that
llvm-project shouldn't have different behaviors depending on such pointer
equality (as we've been using -fvisibility-inlines-hidden which applies to
inline functions for a long time), but if we accidentally do, users should be
aware that they should not make assumption on pointer equality in `-fno-pic`
mode.

Reviewed By: phosek

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

Added: 


Modified: 
clang/tools/clang-shlib/CMakeLists.txt
llvm/cmake/modules/HandleLLVMOptions.cmake
llvm/tools/llvm-shlib/CMakeLists.txt

Removed: 




diff  --git a/clang/tools/clang-shlib/CMakeLists.txt 
b/clang/tools/clang-shlib/CMakeLists.txt
index 5949223fc8e34..73e806c495556 100644
--- a/clang/tools/clang-shlib/CMakeLists.txt
+++ b/clang/tools/clang-shlib/CMakeLists.txt
@@ -48,3 +48,8 @@ add_clang_library(clang-cpp
   ${_OBJECTS}
   LINK_LIBS
   ${_DEPS})
+# Optimize function calls and global variable access for default visibility
+# definitions to avoid PLT and reduce dynamic relocations.
+if (NOT APPLE)
+  target_link_options(clang-cpp PRIVATE LINKER:-Bsymbolic-functions)
+endif()

diff  --git a/llvm/cmake/modules/HandleLLVMOptions.cmake 
b/llvm/cmake/modules/HandleLLVMOptions.cmake
index a64644a08e599..81f46cf116cf6 100644
--- a/llvm/cmake/modules/HandleLLVMOptions.cmake
+++ b/llvm/cmake/modules/HandleLLVMOptions.cmake
@@ -305,6 +305,7 @@ if( LLVM_ENABLE_PIC )
 # On Windows all code is PIC. MinGW warns if -fPIC is used.
   else()
 add_flag_or_print_warning("-fPIC" FPIC)
+add_flag_if_supported("-fno-semantic-interposition" 
FNO_SEMANTIC_INTERPOSITION)
   endif()
   # GCC for MIPS can miscompile LLVM due to PR37701.
   if(CMAKE_COMPILER_IS_GNUCXX AND LLVM_NATIVE_ARCH STREQUAL "Mips" AND

diff  --git a/llvm/tools/llvm-shlib/CMakeLists.txt 
b/llvm/tools/llvm-shlib/CMakeLists.txt
index b0ee19049e6fa..7259ba2636581 100644
--- a/llvm/tools/llvm-shlib/CMakeLists.txt
+++ b/llvm/tools/llvm-shlib/CMakeLists.txt
@@ -50,6 +50,9 @@ if(LLVM_BUILD_LLVM_DYLIB)
   # Solaris ld does not accept global: *; so there is no way to version 
*all* global symbols
   set(LIB_NAMES 
-Wl,--version-script,${LLVM_LIBRARY_DIR}/tools/llvm-shlib/simple_version_script.map
 ${LIB_NAMES})
 endif()
+# Optimize function calls and global variable access for default visibility
+# definitions to avoid PLT and reduce dynamic relocations.
+target_link_options(LLVM PRIVATE LINKER:-Bsymbolic-functions)
   elseif("${CMAKE_SYSTEM_NAME}" STREQUAL "Darwin")
 set(LIB_NAMES -Wl,-all_load ${LIB_NAMES})
   endif()



___
cfe-commits mailing list
cfe-commits@lists.llvm.org

[PATCH] D102337: [clang-tidy] Fix test that requires Windows platofrm

[Georgy Komarov via Phabricator via cfe-commits]

jubnzv created this revision.
jubnzv added reviewers: aaron.ballman, njames93.
jubnzv added a project: clang-tools-extra.
Herald added subscribers: kbarton, xazax.hun, nemanjai.
jubnzv requested review of this revision.

This commit fixes the `cppcoreguidelines-pro-type-vararg` test when it  runs on 
a Windows host, but the toolchain is targeted a non-Windows platform.
See the description of the problem with this test here: 
https://reviews.llvm.org/D101259#2739466


https://reviews.llvm.org/D102337

Files:
  
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-pro-type-vararg-ms.cpp


Index: 
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-pro-type-vararg-ms.cpp
===
--- 
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-pro-type-vararg-ms.cpp
+++ 
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-pro-type-vararg-ms.cpp
@@ -2,9 +2,7 @@
 // Ensure that the 'cppcoreguidelines-pro-type-vararg' check works with the
 // built-in va_list on Windows systems.
 
-// REQUIRES: system-windows
-
-// RUN: %check_clang_tidy %s cppcoreguidelines-pro-type-vararg %t
+// RUN: %check_clang_tidy %s cppcoreguidelines-pro-type-vararg %t -- 
--extra-arg=--target=x86_64-windows
 
 void test_ms_va_list(int a, ...) {
   __builtin_ms_va_list ap;


Index: clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-pro-type-vararg-ms.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-pro-type-vararg-ms.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-pro-type-vararg-ms.cpp
@@ -2,9 +2,7 @@
 // Ensure that the 'cppcoreguidelines-pro-type-vararg' check works with the
 // built-in va_list on Windows systems.
 
-// REQUIRES: system-windows
-
-// RUN: %check_clang_tidy %s cppcoreguidelines-pro-type-vararg %t
+// RUN: %check_clang_tidy %s cppcoreguidelines-pro-type-vararg %t -- --extra-arg=--target=x86_64-windows
 
 void test_ms_va_list(int a, ...) {
   __builtin_ms_va_list ap;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D101139: Create install targets for scan-build-py.

[Petr Hosek via Phabricator via cfe-commits]

phosek added inline comments.



Comment at: clang/tools/scan-build-py/CMakeLists.txt:1-7
+set (BinFiles
+ "analyze-build"
+ "analyze-c++"
+ "analyze-cc"
+ "intercept-build"
+ "intercept-c++"
+ "intercept-cc")

Shouldn't this list also contain `scan-build`?



Comment at: clang/tools/scan-build-py/CMakeLists.txt:9
+
+set (LibScanbuilds
+ "__init__.py"





Comment at: clang/tools/scan-build-py/CMakeLists.txt:21
+# compiler.
+set (LibEars
+ "__init__.py"




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

https://reviews.llvm.org/D101139

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

[PATCH] D86671: [clang-tidy] Add new case type to check variables with Hungarian notation

[Nathan James via Phabricator via cfe-commits]

njames93 added a comment.

I think the best method is to

In D86671#2750957 , @dougpuob wrote:

> Hi @njames93:
> Could you do me a favor? Because it is my first patch, something I'm not 
> sure. I'm confused about can I land this patch now? I read the "LLVM 
> Code-Review Policy and Practices" document, it said patches can be landed if 
> received a LGTM, but seems you are still reviewing.

If you have made significant changes (excluding what a reviewer asks when 
giving an LGTM) Its best to get those further changes also reviewed.




Comment at: 
clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp:348
+getFileStyleFromOptions(const ClangTidyCheck::OptionsView ,
+ClangTidyContext ) {
+  IdentifierNamingCheck::HungarianNotationOption HNOption;

Rather than passing the ClangTidyContext, Make this function a method of 
IdentifierNamingCheck. Then you call create the Diag without worrying about the 
Context.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86671

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

[PATCH] D102270: [CUDA][HIP] Fix device template variables

[Artem Belevich via Phabricator via cfe-commits]

tra accepted this revision.
tra added inline comments.



Comment at: clang/lib/Sema/SemaExpr.cpp:17145
 };
-if (Var && Var->hasGlobalStorage() && !IsEmittedOnDeviceSide(Var)) {
-  SemaRef.targetDiag(Loc, diag::err_ref_bad_target)
-  << /*host*/ 2 << /*variable*/ 1 << Var << Target;
+if (Var && Var->hasGlobalStorage()) {
+  if (!IsEmittedOnDeviceSide(Var)) {

Revisiting my comment from https://reviews.llvm.org/D102237#inline-967732

I think this can be combined with the `if (SemaRef.LangOpts.CUDA)` above.

Unless I'm missing something obvious, what we have now is
```
if (SemaRef.LangOpts.CUDA) {
  
  if (Var && Var->hasGlobalStorage()) {

  }
}
```

You've mentioned that they can't be combined because of an `else`, but there's 
no else in the `if (Var && Var->hasGlobalStorage()) ` as far as I can see, and 
`` could be moved inside it.



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

https://reviews.llvm.org/D102270

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

[PATCH] D102213: [ASTMatchers] Add forCallable(), a generalization of forFunction().

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added a comment.

I totally agree that changing `forFunction()` to work correctly is the right 
solution but backwards compatibility breakage is very real because 
`forFunction()` accepts a `Matcher` whereas `forCallable()` 
accepts `Matcher` which is a smaller set of matchers. Eg., 
`forFunction(hasName())` is valid code bug `forCallable(hasName())` is not 
because `BlockDecl` isn't a `NamedDecl`. So, like, I suspect that not a lot of 
code expects this to be **//the//** function, but a lot of code expects it to 
be **//a//** function. See how much types did I have to change just to get the 
infinite loop checker to compile in D102214 .

If we're ok with such compatibility breakage then i'm all for it.


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

https://reviews.llvm.org/D102213

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

[PATCH] D98799: [UniqueLinkageName] Use consistent checks when mangling symbo linkage name and debug linkage name.

[Hongtao Yu via Phabricator via cfe-commits]

hoy added inline comments.



Comment at: clang/test/CodeGen/unique-internal-linkage-names-dwarf.c:34-39
+static int go(a) int a;
+{
+  return glob + a;
+}
+
+

aaron.ballman wrote:
> hoy wrote:
> > aaron.ballman wrote:
> > > dblaikie wrote:
> > > > hoy wrote:
> > > > > dblaikie wrote:
> > > > > > hoy wrote:
> > > > > > > dblaikie wrote:
> > > > > > > > aaron.ballman wrote:
> > > > > > > > > dblaikie wrote:
> > > > > > > > > > aaron.ballman wrote:
> > > > > > > > > > > dblaikie wrote:
> > > > > > > > > > > > hoy wrote:
> > > > > > > > > > > > > dblaikie wrote:
> > > > > > > > > > > > > > dblaikie wrote:
> > > > > > > > > > > > > > > hoy wrote:
> > > > > > > > > > > > > > > > dblaikie wrote:
> > > > > > > > > > > > > > > > > hoy wrote:
> > > > > > > > > > > > > > > > > > dblaikie wrote:
> > > > > > > > > > > > > > > > > > > hoy wrote:
> > > > > > > > > > > > > > > > > > > > dblaikie wrote:
> > > > > > > > > > > > > > > > > > > > > hoy wrote:
> > > > > > > > > > > > > > > > > > > > > > dblaikie wrote:
> > > > > > > > > > > > > > > > > > > > > > > hoy wrote:
> > > > > > > > > > > > > > > > > > > > > > > > dblaikie wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > hoy wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > > dblaikie wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > > > Does this need to be down 
> > > > > > > > > > > > > > > > > > > > > > > > > > > here? Or would the code 
> > > > > > > > > > > > > > > > > > > > > > > > > > > be a well exercised if it 
> > > > > > > > > > > > > > > > > > > > > > > > > > > was up next to the go 
> > > > > > > > > > > > > > > > > > > > > > > > > > > declaration above?
> > > > > > > > > > > > > > > > > > > > > > > > > > Yes, it needs to be here. 
> > > > > > > > > > > > > > > > > > > > > > > > > > Otherwise it will just like 
> > > > > > > > > > > > > > > > > > > > > > > > > > the function `bar` above 
> > > > > > > > > > > > > > > > > > > > > > > > > > that doesn't get a 
> > > > > > > > > > > > > > > > > > > > > > > > > > uniquefied name. I think 
> > > > > > > > > > > > > > > > > > > > > > > > > > moving the definition up to 
> > > > > > > > > > > > > > > > > > > > > > > > > > right after the declaration 
> > > > > > > > > > > > > > > > > > > > > > > > > > hides the declaration.
> > > > > > > > > > > > > > > > > > > > > > > > > Not sure I follow - do you 
> > > > > > > > > > > > > > > > > > > > > > > > > mean that if the go 
> > > > > > > > > > > > > > > > > > > > > > > > > declaration and go definition 
> > > > > > > > > > > > > > > > > > > > > > > > > were next to each other, this 
> > > > > > > > > > > > > > > > > > > > > > > > > test would (mechanically 
> > > > > > > > > > > > > > > > > > > > > > > > > speaking) not validate what 
> > > > > > > > > > > > > > > > > > > > > > > > > the patch? Or that it would 
> > > > > > > > > > > > > > > > > > > > > > > > > be less legible, but still 
> > > > > > > > > > > > > > > > > > > > > > > > > mechanically correct?
> > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > I think it would be (assuming 
> > > > > > > > > > > > > > > > > > > > > > > > > it's still mechanically 
> > > > > > > > > > > > > > > > > > > > > > > > > correct) more legible to put 
> > > > > > > > > > > > > > > > > > > > > > > > > the declaration next to the 
> > > > > > > > > > > > > > > > > > > > > > > > > definition - the comment 
> > > > > > > > > > > > > > > > > > > > > > > > > describes why the declaration 
> > > > > > > > > > > > > > > > > > > > > > > > > is significant/why the 
> > > > > > > > > > > > > > > > > > > > > > > > > definition is weird, and 
> > > > > > > > > > > > > > > > > > > > > > > > > seeing all that together 
> > > > > > > > > > > > > > > > > > > > > > > > > would be clearer to me than 
> > > > > > > > > > > > > > > > > > > > > > > > > spreading it out/having to 
> > > > > > > > > > > > > > > > > > > > > > > > > look further away to see 
> > > > > > > > > > > > > > > > > > > > > > > > > what's going on.
> > > > > > > > > > > > > > > > > > > > > > > > When the `go` declaration and 
> > > > > > > > > > > > > > > > > > > > > > > > `go` definition were next to 
> > > > > > > > > > > > > > > > > > > > > > > > each other, the go function 
> > > > > > > > > > > > > > > > > > > > > > > > won't get a uniqufied name at 
> > > > > > > > > > > > > > > > > > > > > > > > all. The declaration will be 
> > > > > > > > > > > > > > > > > > > > > > > > overwritten by the definition. 
> > > > > > > > > > > > > > > > > > > > > > > > Only when the declaration is 
> > > > > > > > > > > > > > > > > > > > > > > > seen by others, such the 
> > > > > > > > > > > > > > > > > > > > > > > > callsite in `baz`, the 
> > > > > > > > > > > > > > > > > > > > > > > > declaration makes a difference 
> > > > > > > > > > > > > > > > > > > > > > > > by having the callsite use a 
> > > > > > > > > > > > > > > > > > > > > > > > uniqufied name.
> > > > > > > > > > > > 

[PATCH] D98798: Produce warning for performing pointer arithmetic on a null pointer.

[Jamie Schmeiser via Phabricator via cfe-commits]

jamieschmeiser added a comment.

@thakis, I have some questions about your comments.
Are you sure this is coming from a system header?  The path that you gave has 
third_party as a directory in the path.  If the warning were being triggered by 
code in a system header, I would have expected it to fire on something in the 
windows build bots but they appear to be clean.
I don't know if it is possible to suppress a warning based on whether the 
source is in a system header, or from a macro expansion that is defined in a 
system header; are you aware about whether or not this is possible?  If it is, 
I suspect it would already be in force as a general setting, again making me 
question whether this is a system header...and if it isn't a system header, 
that wouldn't help you in any case.
If I understand your second point correctly, you have a system that previously 
compiled cleanly with warnings being treated as errors and you are concerned 
that if you use the existing options to suppress this particular warning, you 
are concerned that something could creep in.  Therefore you are proposing a 
different warning group that would be a subgroup of the existing one so that if 
you set it, you would set both but you would still be able to set the specific 
one.  I don't know if this is possible or not.  Either way, I suspect that it 
would require using a different warning for the subtraction case, which would 
also require significantly changing these changes. Am I understanding 
correctly?  If so, this implies that you have access to a workaround for your 
problem, although it may not be the best solution.
I do not have access to a windows setup to test any of these proposed changes; 
in particular, given that I suspect that the affected files are specific to 
some third party vendor from which you have purchased code, I do not have means 
of investigating the actual problems/solutions.  If it would be helpful, I 
would be happy to review any changes that you might like to make to remedy the 
situation.
I will be on vacation for the next few days so please excuse my delayed 
responses.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98798

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

[PATCH] D102134: [docs]Updated the AMD GPU Attributes documentation

[Shivam Gupta via Phabricator via cfe-commits]

xgupta resigned from this revision.
xgupta added a comment.

I am really an idol reviewer for this patch -:) don't know anything about 
AMDGPU.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102134

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

[PATCH] D98799: [UniqueLinkageName] Use consistent checks when mangling symbo linkage name and debug linkage name.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/test/CodeGen/unique-internal-linkage-names-dwarf.c:34-39
+static int go(a) int a;
+{
+  return glob + a;
+}
+
+

hoy wrote:
> aaron.ballman wrote:
> > dblaikie wrote:
> > > hoy wrote:
> > > > dblaikie wrote:
> > > > > hoy wrote:
> > > > > > dblaikie wrote:
> > > > > > > aaron.ballman wrote:
> > > > > > > > dblaikie wrote:
> > > > > > > > > aaron.ballman wrote:
> > > > > > > > > > dblaikie wrote:
> > > > > > > > > > > hoy wrote:
> > > > > > > > > > > > dblaikie wrote:
> > > > > > > > > > > > > dblaikie wrote:
> > > > > > > > > > > > > > hoy wrote:
> > > > > > > > > > > > > > > dblaikie wrote:
> > > > > > > > > > > > > > > > hoy wrote:
> > > > > > > > > > > > > > > > > dblaikie wrote:
> > > > > > > > > > > > > > > > > > hoy wrote:
> > > > > > > > > > > > > > > > > > > dblaikie wrote:
> > > > > > > > > > > > > > > > > > > > hoy wrote:
> > > > > > > > > > > > > > > > > > > > > dblaikie wrote:
> > > > > > > > > > > > > > > > > > > > > > hoy wrote:
> > > > > > > > > > > > > > > > > > > > > > > dblaikie wrote:
> > > > > > > > > > > > > > > > > > > > > > > > hoy wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > dblaikie wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > > Does this need to be down 
> > > > > > > > > > > > > > > > > > > > > > > > > > here? Or would the code be 
> > > > > > > > > > > > > > > > > > > > > > > > > > a well exercised if it was 
> > > > > > > > > > > > > > > > > > > > > > > > > > up next to the go 
> > > > > > > > > > > > > > > > > > > > > > > > > > declaration above?
> > > > > > > > > > > > > > > > > > > > > > > > > Yes, it needs to be here. 
> > > > > > > > > > > > > > > > > > > > > > > > > Otherwise it will just like 
> > > > > > > > > > > > > > > > > > > > > > > > > the function `bar` above that 
> > > > > > > > > > > > > > > > > > > > > > > > > doesn't get a uniquefied 
> > > > > > > > > > > > > > > > > > > > > > > > > name. I think moving the 
> > > > > > > > > > > > > > > > > > > > > > > > > definition up to right after 
> > > > > > > > > > > > > > > > > > > > > > > > > the declaration hides the 
> > > > > > > > > > > > > > > > > > > > > > > > > declaration.
> > > > > > > > > > > > > > > > > > > > > > > > Not sure I follow - do you mean 
> > > > > > > > > > > > > > > > > > > > > > > > that if the go declaration and 
> > > > > > > > > > > > > > > > > > > > > > > > go definition were next to each 
> > > > > > > > > > > > > > > > > > > > > > > > other, this test would 
> > > > > > > > > > > > > > > > > > > > > > > > (mechanically speaking) not 
> > > > > > > > > > > > > > > > > > > > > > > > validate what the patch? Or 
> > > > > > > > > > > > > > > > > > > > > > > > that it would be less legible, 
> > > > > > > > > > > > > > > > > > > > > > > > but still mechanically correct?
> > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > I think it would be (assuming 
> > > > > > > > > > > > > > > > > > > > > > > > it's still mechanically 
> > > > > > > > > > > > > > > > > > > > > > > > correct) more legible to put 
> > > > > > > > > > > > > > > > > > > > > > > > the declaration next to the 
> > > > > > > > > > > > > > > > > > > > > > > > definition - the comment 
> > > > > > > > > > > > > > > > > > > > > > > > describes why the declaration 
> > > > > > > > > > > > > > > > > > > > > > > > is significant/why the 
> > > > > > > > > > > > > > > > > > > > > > > > definition is weird, and seeing 
> > > > > > > > > > > > > > > > > > > > > > > > all that together would be 
> > > > > > > > > > > > > > > > > > > > > > > > clearer to me than spreading it 
> > > > > > > > > > > > > > > > > > > > > > > > out/having to look further away 
> > > > > > > > > > > > > > > > > > > > > > > > to see what's going on.
> > > > > > > > > > > > > > > > > > > > > > > When the `go` declaration and 
> > > > > > > > > > > > > > > > > > > > > > > `go` definition were next to each 
> > > > > > > > > > > > > > > > > > > > > > > other, the go function won't get 
> > > > > > > > > > > > > > > > > > > > > > > a uniqufied name at all. The 
> > > > > > > > > > > > > > > > > > > > > > > declaration will be overwritten 
> > > > > > > > > > > > > > > > > > > > > > > by the definition. Only when the 
> > > > > > > > > > > > > > > > > > > > > > > declaration is seen by others, 
> > > > > > > > > > > > > > > > > > > > > > > such the callsite in `baz`, the 
> > > > > > > > > > > > > > > > > > > > > > > declaration makes a difference by 
> > > > > > > > > > > > > > > > > > > > > > > having the callsite use a 
> > > > > > > > > > > > > > > > > > > > > > > uniqufied name.
> > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > Ah! Interesting, good to know. 
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > Is that worth supporting, I wonder? 
> > > > > > > > > > > > > > > > 

[PATCH] D70401: [WIP][RISCV] Implement ilp32e ABI

[Alex Bradbury via Phabricator via cfe-commits]

asb added a comment.

In D70401#2733003 , @khchen wrote:

> Hi, I would like to add ilp32e ABI support in llvm
> Is there anyone working on this?
> It seem the one thing missed is ilp32e ABI should disallow D ISA extension.
> Is there anything else?

Nobody is currently working on this on the lowRISC side, so please do pick this 
up if you're interested. I can't quite recall the open issues I'm afraid.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70401

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

[PATCH] D98799: [UniqueLinkageName] Use consistent checks when mangling symbo linkage name and debug linkage name.

[Hongtao Yu via Phabricator via cfe-commits]

hoy added inline comments.



Comment at: clang/test/CodeGen/unique-internal-linkage-names-dwarf.c:34-39
+static int go(a) int a;
+{
+  return glob + a;
+}
+
+

aaron.ballman wrote:
> dblaikie wrote:
> > hoy wrote:
> > > dblaikie wrote:
> > > > hoy wrote:
> > > > > dblaikie wrote:
> > > > > > aaron.ballman wrote:
> > > > > > > dblaikie wrote:
> > > > > > > > aaron.ballman wrote:
> > > > > > > > > dblaikie wrote:
> > > > > > > > > > hoy wrote:
> > > > > > > > > > > dblaikie wrote:
> > > > > > > > > > > > dblaikie wrote:
> > > > > > > > > > > > > hoy wrote:
> > > > > > > > > > > > > > dblaikie wrote:
> > > > > > > > > > > > > > > hoy wrote:
> > > > > > > > > > > > > > > > dblaikie wrote:
> > > > > > > > > > > > > > > > > hoy wrote:
> > > > > > > > > > > > > > > > > > dblaikie wrote:
> > > > > > > > > > > > > > > > > > > hoy wrote:
> > > > > > > > > > > > > > > > > > > > dblaikie wrote:
> > > > > > > > > > > > > > > > > > > > > hoy wrote:
> > > > > > > > > > > > > > > > > > > > > > dblaikie wrote:
> > > > > > > > > > > > > > > > > > > > > > > hoy wrote:
> > > > > > > > > > > > > > > > > > > > > > > > dblaikie wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > Does this need to be down 
> > > > > > > > > > > > > > > > > > > > > > > > > here? Or would the code be a 
> > > > > > > > > > > > > > > > > > > > > > > > > well exercised if it was up 
> > > > > > > > > > > > > > > > > > > > > > > > > next to the go declaration 
> > > > > > > > > > > > > > > > > > > > > > > > > above?
> > > > > > > > > > > > > > > > > > > > > > > > Yes, it needs to be here. 
> > > > > > > > > > > > > > > > > > > > > > > > Otherwise it will just like the 
> > > > > > > > > > > > > > > > > > > > > > > > function `bar` above that 
> > > > > > > > > > > > > > > > > > > > > > > > doesn't get a uniquefied name. 
> > > > > > > > > > > > > > > > > > > > > > > > I think moving the definition 
> > > > > > > > > > > > > > > > > > > > > > > > up to right after the 
> > > > > > > > > > > > > > > > > > > > > > > > declaration hides the 
> > > > > > > > > > > > > > > > > > > > > > > > declaration.
> > > > > > > > > > > > > > > > > > > > > > > Not sure I follow - do you mean 
> > > > > > > > > > > > > > > > > > > > > > > that if the go declaration and go 
> > > > > > > > > > > > > > > > > > > > > > > definition were next to each 
> > > > > > > > > > > > > > > > > > > > > > > other, this test would 
> > > > > > > > > > > > > > > > > > > > > > > (mechanically speaking) not 
> > > > > > > > > > > > > > > > > > > > > > > validate what the patch? Or that 
> > > > > > > > > > > > > > > > > > > > > > > it would be less legible, but 
> > > > > > > > > > > > > > > > > > > > > > > still mechanically correct?
> > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > I think it would be (assuming 
> > > > > > > > > > > > > > > > > > > > > > > it's still mechanically correct) 
> > > > > > > > > > > > > > > > > > > > > > > more legible to put the 
> > > > > > > > > > > > > > > > > > > > > > > declaration next to the 
> > > > > > > > > > > > > > > > > > > > > > > definition - the comment 
> > > > > > > > > > > > > > > > > > > > > > > describes why the declaration is 
> > > > > > > > > > > > > > > > > > > > > > > significant/why the definition is 
> > > > > > > > > > > > > > > > > > > > > > > weird, and seeing all that 
> > > > > > > > > > > > > > > > > > > > > > > together would be clearer to me 
> > > > > > > > > > > > > > > > > > > > > > > than spreading it out/having to 
> > > > > > > > > > > > > > > > > > > > > > > look further away to see what's 
> > > > > > > > > > > > > > > > > > > > > > > going on.
> > > > > > > > > > > > > > > > > > > > > > When the `go` declaration and `go` 
> > > > > > > > > > > > > > > > > > > > > > definition were next to each other, 
> > > > > > > > > > > > > > > > > > > > > > the go function won't get a 
> > > > > > > > > > > > > > > > > > > > > > uniqufied name at all. The 
> > > > > > > > > > > > > > > > > > > > > > declaration will be overwritten by 
> > > > > > > > > > > > > > > > > > > > > > the definition. Only when the 
> > > > > > > > > > > > > > > > > > > > > > declaration is seen by others, such 
> > > > > > > > > > > > > > > > > > > > > > the callsite in `baz`, the 
> > > > > > > > > > > > > > > > > > > > > > declaration makes a difference by 
> > > > > > > > > > > > > > > > > > > > > > having the callsite use a uniqufied 
> > > > > > > > > > > > > > > > > > > > > > name.
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > Ah! Interesting, good to know. 
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > Is that worth supporting, I wonder? I 
> > > > > > > > > > > > > > > > > > > > > guess it falls out for free/without 
> > > > > > > > > > > > > > > > > > > > > significant additional complexity. I 
> > > > > > > > > > > > > > > > > > > > > 

[PATCH] D102313: [docs] Fix documentation for bugprone-dangling-handle

[Malcolm Parsons via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG5389a05836e7: [docs] Fix documentation for 
bugprone-dangling-handle (authored by malcolm.parsons).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102313

Files:
  clang-tools-extra/docs/clang-tidy/checks/bugprone-dangling-handle.rst


Index: clang-tools-extra/docs/clang-tidy/checks/bugprone-dangling-handle.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/bugprone-dangling-handle.rst
+++ clang-tools-extra/docs/clang-tidy/checks/bugprone-dangling-handle.rst
@@ -3,8 +3,7 @@
 bugprone-dangling-handle
 
 
-Detect dangling references in value handles like
-``std::experimental::string_view``.
+Detect dangling references in value handles like ``std::string_view``.
 These dangling references can be a result of constructing handles from 
temporary
 values, where the temporary is destroyed soon after the handle is created.
 
@@ -35,4 +34,5 @@
 .. option:: HandleClasses
 
A semicolon-separated list of class names that should be treated as handles.
-   By default only ``std::experimental::basic_string_view`` is considered.
+   By default only ``std::basic_string_view`` and
+   ``std::experimental::basic_string_view`` are considered.


Index: clang-tools-extra/docs/clang-tidy/checks/bugprone-dangling-handle.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/bugprone-dangling-handle.rst
+++ clang-tools-extra/docs/clang-tidy/checks/bugprone-dangling-handle.rst
@@ -3,8 +3,7 @@
 bugprone-dangling-handle
 
 
-Detect dangling references in value handles like
-``std::experimental::string_view``.
+Detect dangling references in value handles like ``std::string_view``.
 These dangling references can be a result of constructing handles from temporary
 values, where the temporary is destroyed soon after the handle is created.
 
@@ -35,4 +34,5 @@
 .. option:: HandleClasses
 
A semicolon-separated list of class names that should be treated as handles.
-   By default only ``std::experimental::basic_string_view`` is considered.
+   By default only ``std::basic_string_view`` and
+   ``std::experimental::basic_string_view`` are considered.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] 5389a05 - [docs] Fix documentation for bugprone-dangling-handle

[Malcolm Parsons via cfe-commits]

Author: Malcolm Parsons
Date: 2021-05-12T17:20:15+01:00
New Revision: 5389a05836e74e3acab6dbda7e80ea43e3bc6304

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

LOG: [docs] Fix documentation for bugprone-dangling-handle

string_view isn't experimental anymore.
This check has always handled both forms.

Reviewed By: aaron.ballman

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

Added: 


Modified: 
clang-tools-extra/docs/clang-tidy/checks/bugprone-dangling-handle.rst

Removed: 




diff  --git 
a/clang-tools-extra/docs/clang-tidy/checks/bugprone-dangling-handle.rst 
b/clang-tools-extra/docs/clang-tidy/checks/bugprone-dangling-handle.rst
index 8c2c316c090da..701b67d77acaa 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/bugprone-dangling-handle.rst
+++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone-dangling-handle.rst
@@ -3,8 +3,7 @@
 bugprone-dangling-handle
 
 
-Detect dangling references in value handles like
-``std::experimental::string_view``.
+Detect dangling references in value handles like ``std::string_view``.
 These dangling references can be a result of constructing handles from 
temporary
 values, where the temporary is destroyed soon after the handle is created.
 
@@ -35,4 +34,5 @@ Options
 .. option:: HandleClasses
 
A semicolon-separated list of class names that should be treated as handles.
-   By default only ``std::experimental::basic_string_view`` is considered.
+   By default only ``std::basic_string_view`` and
+   ``std::experimental::basic_string_view`` are considered.



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