[PATCH] D100739: [Coroutines] Handle overaligned frame allocation (2)

2021-04-23 Thread Yuanfang Chen via Phabricator via cfe-commits
ychen updated this revision to Diff 339902.
ychen added a comment.

Fix typo.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100739

Files:
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGenCoroutines/coro-alloc.cpp
  clang/test/CodeGenCoroutines/coro-builtins.c
  clang/test/CodeGenCoroutines/coro-gro.cpp
  llvm/docs/Coroutines.rst
  llvm/include/llvm/IR/Intrinsics.td
  llvm/lib/Transforms/Coroutines/CoroFrame.cpp
  llvm/lib/Transforms/Coroutines/CoroInstr.h
  llvm/lib/Transforms/Coroutines/CoroInternal.h
  llvm/lib/Transforms/Coroutines/CoroSplit.cpp
  llvm/lib/Transforms/Coroutines/Coroutines.cpp
  llvm/test/Transforms/Coroutines/coro-overalign.ll

Index: llvm/test/Transforms/Coroutines/coro-overalign.ll
===
--- /dev/null
+++ llvm/test/Transforms/Coroutines/coro-overalign.ll
@@ -0,0 +1,81 @@
+; Check that we will emit extra code to handle overaligned frame.
+; RUN: opt < %s -coro-split -S | FileCheck %s
+; RUN: opt < %s -passes=coro-split -S | FileCheck %s
+
+%PackedStruct = type <{ i64 }>
+
+declare void @consume(%PackedStruct*)
+
+define i8* @f() "coroutine.presplit"="1" {
+entry:
+  %data = alloca %PackedStruct, align 32
+  %id = call token @llvm.coro.id(i32 16, i8* null, i8* null, i8* null)
+  %size = call i32 @llvm.coro.size.alloc.i32()
+  %alloc = call i8* @malloc(i32 %size)
+  %hdl = call i8* @llvm.coro.begin(token %id, i8* %alloc)
+  call void @consume(%PackedStruct* %data)
+  %0 = call i8 @llvm.coro.suspend(token none, i1 false)
+  switch i8 %0, label %suspend [i8 0, label %resume
+i8 1, label %cleanup]
+resume:
+  call void @consume(%PackedStruct* %data)
+  br label %cleanup
+
+cleanup:
+  %mem = call i8* @llvm.coro.free(token %id, i8* %hdl)
+  call void @free(i8* %mem)
+  br label %suspend
+suspend:
+  call i1 @llvm.coro.end(i8* %hdl, i1 0)
+  ret i8* %hdl
+}
+
+; See if the frame pointer was inserted.
+; CHECK-LABEL: %f.Frame = type { void (%f.Frame*)*, void (%f.Frame*)*, i8*, i1, [7 x i8], %PackedStruct }
+
+; See if we over-allocate, adjust frame ptr start address and use a alloca to
+; save the raw frame pointer.
+; CHECK-LABEL: @f(
+;CHECK:  %alloc.frame.ptr = alloca i8*, align 8
+;CHECK:  %id = call token @llvm.coro.id(i32 16, i8* null, i8* null, i8* bitcast ([3 x void (%f.Frame*)*]* @f.resumers to i8*))
+;CHECK:  %alloc = call i8* @malloc(i32 56)
+;CHECK:  store i8* %alloc, i8** %alloc.frame.ptr, align 8
+;CHECK:  %intptr = ptrtoint i8* %alloc to i64
+;CHECK:  %over_boundary = add i64 %intptr, 31
+;CHECK:  %aligned_intptr = and i64 %over_boundary, -32
+;CHECK:  %diff = sub i64 %aligned_intptr, %intptr
+;CHECK:  %aligned_result = getelementptr i8, i8* %alloc, i64 %diff
+;CHECK:  call void @llvm.assume(i1 true) [ "align"(i8* %aligned_result, i64 32) ]
+;CHECK:  %hdl = call noalias nonnull i8* @llvm.coro.begin(token %id, i8* %aligned_result)
+
+; See if we emit correct deallocation code.
+
+; CHECK-LABEL: @f.resume(
+; CHECK:  %0 = getelementptr %f.Frame, %f.Frame* %FramePtr, i32 0, i32 2
+; CHECK-NEXT: %raw.frame.ptr = load i8*, i8** %0, align 8
+; CHECK-NEXT: call void @free(i8* %raw.frame.ptr)
+; CHECK-NEXT: ret void
+
+; CHECK-LABEL: @f.destroy(
+; CHECK:  %0 = getelementptr %f.Frame, %f.Frame* %FramePtr, i32 0, i32 2
+; CHECK-NEXT: %raw.frame.ptr = load i8*, i8** %0, align 8
+; CHECK-NEXT: call void @free(i8* %raw.frame.ptr)
+; CHECK-NEXT: ret void
+
+; CHECK-LABEL: @f.cleanup(
+; CHECK:  call void @free(i8* null)
+; CHECK-NEXT: ret void
+
+declare i8* @llvm.coro.free(token, i8*)
+declare i32 @llvm.coro.size.alloc.i32()
+declare i8  @llvm.coro.suspend(token, i1)
+declare void @llvm.coro.resume(i8*)
+declare void @llvm.coro.destroy(i8*)
+
+declare token @llvm.coro.id(i32, i8*, i8*, i8*)
+declare i1 @llvm.coro.alloc(token)
+declare i8* @llvm.coro.begin(token, i8*)
+declare i1 @llvm.coro.end(i8*, i1)
+
+declare noalias i8* @malloc(i32)
+declare void @free(i8*)
Index: llvm/lib/Transforms/Coroutines/Coroutines.cpp
===
--- llvm/lib/Transforms/Coroutines/Coroutines.cpp
+++ llvm/lib/Transforms/Coroutines/Coroutines.cpp
@@ -22,6 +22,7 @@
 #include "llvm/IR/Constants.h"
 #include "llvm/IR/DerivedTypes.h"
 #include "llvm/IR/Function.h"
+#include "llvm/IR/IRBuilder.h"
 #include "llvm/IR/InstIterator.h"
 #include "llvm/IR/Instructions.h"
 #include "llvm/IR/IntrinsicInst.h"
@@ -171,7 +172,7 @@
 
 // Replace all coro.frees associated with the provided CoroId either with 'null'
 // if Elide is true and with its frame parameter otherwise.
-void coro::replaceCoroFree(CoroIdInst *CoroId, bool Elide) {
+void coro::replaceCoroFree(CoroIdInst *CoroId, bool Elide, Shape *Shape) {
   SmallVector CoroFrees;
   for (User *U : CoroId->users())
 if (auto CF = dyn_cast(U))
@@ -180,9 +181,25 @@
   if (CoroFrees.empty())
 return;
 
-  Value *Replace

[clang-tools-extra] a46bbc1 - [cland] Dont emit missing newline warnings when building preamble

2021-04-23 Thread Kadir Cetinkaya via cfe-commits

Author: Kadir Cetinkaya
Date: 2021-04-23T08:56:32+02:00
New Revision: a46bbc14f004c06bd1317e6d7a486c29133f1c0b

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

LOG: [cland] Dont emit missing newline warnings when building preamble

When building preamble, clangd truncates file contents. This yielded
errnous warnings in some cases.

This patch fixes the issue by turning off no-newline-at-eof warnings whenever
the file has more contents than the preamble.

Fixes https://github.com/clangd/clangd/issues/744.

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

Added: 


Modified: 
clang-tools-extra/clangd/Preamble.cpp
clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/Preamble.cpp 
b/clang-tools-extra/clangd/Preamble.cpp
index 73b1c900cfa5a..e003af6e0dfa5 100644
--- a/clang-tools-extra/clangd/Preamble.cpp
+++ b/clang-tools-extra/clangd/Preamble.cpp
@@ -15,6 +15,7 @@
 #include "support/Trace.h"
 #include "clang/AST/DeclTemplate.h"
 #include "clang/Basic/Diagnostic.h"
+#include "clang/Basic/DiagnosticLex.h"
 #include "clang/Basic/LangOptions.h"
 #include "clang/Basic/SourceLocation.h"
 #include "clang/Basic/SourceManager.h"
@@ -341,6 +342,20 @@ buildPreamble(PathRef FileName, CompilerInvocation CI,
   llvm::IntrusiveRefCntPtr PreambleDiagsEngine =
   CompilerInstance::createDiagnostics(&CI.getDiagnosticOpts(),
   &PreambleDiagnostics, false);
+  PreambleDiagnostics.setLevelAdjuster(
+  [&](DiagnosticsEngine::Level DiagLevel, const clang::Diagnostic &Info) {
+switch (Info.getID()) {
+case diag::warn_no_newline_eof:
+case diag::warn_cxx98_compat_no_newline_eof:
+case diag::ext_no_newline_eof:
+  // If the preamble doesn't span the whole file, drop the no newline 
at
+  // eof warnings.
+  return Bounds.Size != ContentsBuffer->getBufferSize()
+ ? DiagnosticsEngine::Level::Ignored
+ : DiagLevel;
+}
+return DiagLevel;
+  });
 
   // Skip function bodies when building the preamble to speed up building
   // the preamble and make it smaller.

diff  --git a/clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp 
b/clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp
index d5096cba7e740..4aa9cb7d66105 100644
--- a/clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp
+++ b/clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp
@@ -1373,6 +1373,25 @@ TEST(ParsedASTTest, ModuleSawDiag) {
   EXPECT_THAT(*AST.getDiagnostics(),
   testing::Contains(Diag(Code.range(), KDiagMsg.str(;
 }
+
+TEST(Preamble, EndsOnNonEmptyLine) {
+  TestTU TU;
+  TU.ExtraArgs = {"-Wnewline-eof"};
+
+  {
+TU.Code = "#define FOO\n  void bar();\n";
+auto AST = TU.build();
+EXPECT_THAT(*AST.getDiagnostics(), IsEmpty());
+  }
+  {
+Annotations Code("#define FOO[[]]");
+TU.Code = Code.code().str();
+auto AST = TU.build();
+EXPECT_THAT(
+*AST.getDiagnostics(),
+testing::Contains(Diag(Code.range(), "no newline at end of file")));
+  }
+}
 } // namespace
 } // namespace clangd
 } // namespace clang



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


[PATCH] D100501: [cland] Dont emit missing newline warnings when building preamble

2021-04-23 Thread Kadir Cetinkaya 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 rGa46bbc14f004: [cland] Dont emit missing newline warnings 
when building preamble (authored by kadircet).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100501

Files:
  clang-tools-extra/clangd/Preamble.cpp
  clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp


Index: clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp
===
--- clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp
+++ clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp
@@ -1373,6 +1373,25 @@
   EXPECT_THAT(*AST.getDiagnostics(),
   testing::Contains(Diag(Code.range(), KDiagMsg.str(;
 }
+
+TEST(Preamble, EndsOnNonEmptyLine) {
+  TestTU TU;
+  TU.ExtraArgs = {"-Wnewline-eof"};
+
+  {
+TU.Code = "#define FOO\n  void bar();\n";
+auto AST = TU.build();
+EXPECT_THAT(*AST.getDiagnostics(), IsEmpty());
+  }
+  {
+Annotations Code("#define FOO[[]]");
+TU.Code = Code.code().str();
+auto AST = TU.build();
+EXPECT_THAT(
+*AST.getDiagnostics(),
+testing::Contains(Diag(Code.range(), "no newline at end of file")));
+  }
+}
 } // namespace
 } // namespace clangd
 } // namespace clang
Index: clang-tools-extra/clangd/Preamble.cpp
===
--- clang-tools-extra/clangd/Preamble.cpp
+++ clang-tools-extra/clangd/Preamble.cpp
@@ -15,6 +15,7 @@
 #include "support/Trace.h"
 #include "clang/AST/DeclTemplate.h"
 #include "clang/Basic/Diagnostic.h"
+#include "clang/Basic/DiagnosticLex.h"
 #include "clang/Basic/LangOptions.h"
 #include "clang/Basic/SourceLocation.h"
 #include "clang/Basic/SourceManager.h"
@@ -341,6 +342,20 @@
   llvm::IntrusiveRefCntPtr PreambleDiagsEngine =
   CompilerInstance::createDiagnostics(&CI.getDiagnosticOpts(),
   &PreambleDiagnostics, false);
+  PreambleDiagnostics.setLevelAdjuster(
+  [&](DiagnosticsEngine::Level DiagLevel, const clang::Diagnostic &Info) {
+switch (Info.getID()) {
+case diag::warn_no_newline_eof:
+case diag::warn_cxx98_compat_no_newline_eof:
+case diag::ext_no_newline_eof:
+  // If the preamble doesn't span the whole file, drop the no newline 
at
+  // eof warnings.
+  return Bounds.Size != ContentsBuffer->getBufferSize()
+ ? DiagnosticsEngine::Level::Ignored
+ : DiagLevel;
+}
+return DiagLevel;
+  });
 
   // Skip function bodies when building the preamble to speed up building
   // the preamble and make it smaller.


Index: clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp
===
--- clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp
+++ clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp
@@ -1373,6 +1373,25 @@
   EXPECT_THAT(*AST.getDiagnostics(),
   testing::Contains(Diag(Code.range(), KDiagMsg.str(;
 }
+
+TEST(Preamble, EndsOnNonEmptyLine) {
+  TestTU TU;
+  TU.ExtraArgs = {"-Wnewline-eof"};
+
+  {
+TU.Code = "#define FOO\n  void bar();\n";
+auto AST = TU.build();
+EXPECT_THAT(*AST.getDiagnostics(), IsEmpty());
+  }
+  {
+Annotations Code("#define FOO[[]]");
+TU.Code = Code.code().str();
+auto AST = TU.build();
+EXPECT_THAT(
+*AST.getDiagnostics(),
+testing::Contains(Diag(Code.range(), "no newline at end of file")));
+  }
+}
 } // namespace
 } // namespace clangd
 } // namespace clang
Index: clang-tools-extra/clangd/Preamble.cpp
===
--- clang-tools-extra/clangd/Preamble.cpp
+++ clang-tools-extra/clangd/Preamble.cpp
@@ -15,6 +15,7 @@
 #include "support/Trace.h"
 #include "clang/AST/DeclTemplate.h"
 #include "clang/Basic/Diagnostic.h"
+#include "clang/Basic/DiagnosticLex.h"
 #include "clang/Basic/LangOptions.h"
 #include "clang/Basic/SourceLocation.h"
 #include "clang/Basic/SourceManager.h"
@@ -341,6 +342,20 @@
   llvm::IntrusiveRefCntPtr PreambleDiagsEngine =
   CompilerInstance::createDiagnostics(&CI.getDiagnosticOpts(),
   &PreambleDiagnostics, false);
+  PreambleDiagnostics.setLevelAdjuster(
+  [&](DiagnosticsEngine::Level DiagLevel, const clang::Diagnostic &Info) {
+switch (Info.getID()) {
+case diag::warn_no_newline_eof:
+case diag::warn_cxx98_compat_no_newline_eof:
+case diag::ext_no_newline_eof:
+  // If the preamble doesn't span the whole file, drop the no newline at
+  // eof warnings.
+  return Bounds.Size != ContentsBuffer->getBufferSize()
+ ? DiagnosticsEngine::Level::Ignored
+ : DiagL

[PATCH] D100739: [Coroutines] Handle overaligned frame allocation (2)

2021-04-23 Thread Yuanfang Chen via Phabricator via cfe-commits
ychen updated this revision to Diff 339906.
ychen added a comment.

fix typo.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100739

Files:
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGenCoroutines/coro-alloc.cpp
  clang/test/CodeGenCoroutines/coro-builtins.c
  clang/test/CodeGenCoroutines/coro-gro.cpp
  llvm/docs/Coroutines.rst
  llvm/include/llvm/IR/Intrinsics.td
  llvm/lib/Transforms/Coroutines/CoroFrame.cpp
  llvm/lib/Transforms/Coroutines/CoroInstr.h
  llvm/lib/Transforms/Coroutines/CoroInternal.h
  llvm/lib/Transforms/Coroutines/CoroSplit.cpp
  llvm/lib/Transforms/Coroutines/Coroutines.cpp
  llvm/test/Transforms/Coroutines/coro-overalign.ll

Index: llvm/test/Transforms/Coroutines/coro-overalign.ll
===
--- /dev/null
+++ llvm/test/Transforms/Coroutines/coro-overalign.ll
@@ -0,0 +1,81 @@
+; Check that we will emit extra code to handle overaligned frame.
+; RUN: opt < %s -coro-split -S | FileCheck %s
+; RUN: opt < %s -passes=coro-split -S | FileCheck %s
+
+%PackedStruct = type <{ i64 }>
+
+declare void @consume(%PackedStruct*)
+
+define i8* @f() "coroutine.presplit"="1" {
+entry:
+  %data = alloca %PackedStruct, align 32
+  %id = call token @llvm.coro.id(i32 16, i8* null, i8* null, i8* null)
+  %size = call i32 @llvm.coro.size.aligned.i32()
+  %alloc = call i8* @malloc(i32 %size)
+  %hdl = call i8* @llvm.coro.begin(token %id, i8* %alloc)
+  call void @consume(%PackedStruct* %data)
+  %0 = call i8 @llvm.coro.suspend(token none, i1 false)
+  switch i8 %0, label %suspend [i8 0, label %resume
+i8 1, label %cleanup]
+resume:
+  call void @consume(%PackedStruct* %data)
+  br label %cleanup
+
+cleanup:
+  %mem = call i8* @llvm.coro.free(token %id, i8* %hdl)
+  call void @free(i8* %mem)
+  br label %suspend
+suspend:
+  call i1 @llvm.coro.end(i8* %hdl, i1 0)
+  ret i8* %hdl
+}
+
+; See if the frame pointer was inserted.
+; CHECK-LABEL: %f.Frame = type { void (%f.Frame*)*, void (%f.Frame*)*, i8*, i1, [7 x i8], %PackedStruct }
+
+; See if we over-allocate, adjust frame ptr start address and use a alloca to
+; save the raw frame pointer.
+; CHECK-LABEL: @f(
+;CHECK:  %alloc.frame.ptr = alloca i8*, align 8
+;CHECK:  %id = call token @llvm.coro.id(i32 16, i8* null, i8* null, i8* bitcast ([3 x void (%f.Frame*)*]* @f.resumers to i8*))
+;CHECK:  %alloc = call i8* @malloc(i32 56)
+;CHECK:  store i8* %alloc, i8** %alloc.frame.ptr, align 8
+;CHECK:  %intptr = ptrtoint i8* %alloc to i64
+;CHECK:  %over_boundary = add i64 %intptr, 31
+;CHECK:  %aligned_intptr = and i64 %over_boundary, -32
+;CHECK:  %diff = sub i64 %aligned_intptr, %intptr
+;CHECK:  %aligned_result = getelementptr i8, i8* %alloc, i64 %diff
+;CHECK:  call void @llvm.assume(i1 true) [ "align"(i8* %aligned_result, i64 32) ]
+;CHECK:  %hdl = call noalias nonnull i8* @llvm.coro.begin(token %id, i8* %aligned_result)
+
+; See if we emit correct deallocation code.
+
+; CHECK-LABEL: @f.resume(
+; CHECK:  %0 = getelementptr %f.Frame, %f.Frame* %FramePtr, i32 0, i32 2
+; CHECK-NEXT: %raw.frame.ptr = load i8*, i8** %0, align 8
+; CHECK-NEXT: call void @free(i8* %raw.frame.ptr)
+; CHECK-NEXT: ret void
+
+; CHECK-LABEL: @f.destroy(
+; CHECK:  %0 = getelementptr %f.Frame, %f.Frame* %FramePtr, i32 0, i32 2
+; CHECK-NEXT: %raw.frame.ptr = load i8*, i8** %0, align 8
+; CHECK-NEXT: call void @free(i8* %raw.frame.ptr)
+; CHECK-NEXT: ret void
+
+; CHECK-LABEL: @f.cleanup(
+; CHECK:  call void @free(i8* null)
+; CHECK-NEXT: ret void
+
+declare i8* @llvm.coro.free(token, i8*)
+declare i32 @llvm.coro.size.aligned.i32()
+declare i8  @llvm.coro.suspend(token, i1)
+declare void @llvm.coro.resume(i8*)
+declare void @llvm.coro.destroy(i8*)
+
+declare token @llvm.coro.id(i32, i8*, i8*, i8*)
+declare i1 @llvm.coro.alloc(token)
+declare i8* @llvm.coro.begin(token, i8*)
+declare i1 @llvm.coro.end(i8*, i1)
+
+declare noalias i8* @malloc(i32)
+declare void @free(i8*)
Index: llvm/lib/Transforms/Coroutines/Coroutines.cpp
===
--- llvm/lib/Transforms/Coroutines/Coroutines.cpp
+++ llvm/lib/Transforms/Coroutines/Coroutines.cpp
@@ -22,6 +22,7 @@
 #include "llvm/IR/Constants.h"
 #include "llvm/IR/DerivedTypes.h"
 #include "llvm/IR/Function.h"
+#include "llvm/IR/IRBuilder.h"
 #include "llvm/IR/InstIterator.h"
 #include "llvm/IR/Instructions.h"
 #include "llvm/IR/IntrinsicInst.h"
@@ -171,7 +172,7 @@
 
 // Replace all coro.frees associated with the provided CoroId either with 'null'
 // if Elide is true and with its frame parameter otherwise.
-void coro::replaceCoroFree(CoroIdInst *CoroId, bool Elide) {
+void coro::replaceCoroFree(CoroIdInst *CoroId, bool Elide, Shape *Shape) {
   SmallVector CoroFrees;
   for (User *U : CoroId->users())
 if (auto CF = dyn_cast(U))
@@ -180,9 +181,25 @@
   if (CoroFrees.empty())
 return;
 
-  Value *Rep

[PATCH] D100879: [Clang] Propagate guaranteed alignment for malloc and others

2021-04-23 Thread Dávid Bolvanský via Phabricator via cfe-commits
xbolva00 updated this revision to Diff 339912.
xbolva00 added a comment.

Updated comment for

  getNewAlign()


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

https://reviews.llvm.org/D100879

Files:
  clang/include/clang/Basic/TargetInfo.h
  clang/lib/CodeGen/CGCall.cpp
  clang/test/CodeGen/alloc-fns-alignment.c


Index: clang/test/CodeGen/alloc-fns-alignment.c
===
--- /dev/null
+++ clang/test/CodeGen/alloc-fns-alignment.c
@@ -0,0 +1,35 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm < %s | 
FileCheck %s --check-prefix=ALIGN16
+// RUN: %clang_cc1 -triple x86_64-windows-msvc  -emit-llvm < %s | 
FileCheck %s --check-prefix=ALIGN16
+// RUN: %clang_cc1 -triple i386-apple-darwin-emit-llvm < %s | 
FileCheck %s --check-prefix=ALIGN16
+// RUN: %clang_cc1 -triple i386-unknown-linux-gnu   -emit-llvm < %s | 
FileCheck %s --check-prefix=ALIGN8
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fno-builtin-malloc  
-emit-llvm < %s  | FileCheck %s --check-prefix=NOBUILTIN-MALLOC
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fno-builtin-calloc  
-emit-llvm < %s  | FileCheck %s --check-prefix=NOBUILTIN-CALLOC
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fno-builtin-realloc 
-emit-llvm < %s  | FileCheck %s --check-prefix=NOBUILTIN-REALLOC
+
+typedef __SIZE_TYPE__ size_t;
+
+void *malloc(size_t);
+void *calloc(size_t, size_t);
+void *realloc(void *, size_t);
+
+void *malloc_test(size_t n) {
+  return malloc(n);
+}
+
+void *calloc_test(size_t n) {
+  return calloc(1, n);
+}
+
+void *raalloc_test(void *p, size_t n) {
+  return realloc(p, n);
+}
+
+// ALIGN16: align 16 i8* @malloc
+// ALIGN16: align 16 i8* @calloc
+// ALIGN16: align 16 i8* @realloc
+// ALIGN8: align 8 i8* @malloc
+// ALIGN8: align 8 i8* @calloc
+// ALIGN8: align 8 i8* @realloc
+// NOBUILTIN-MALLOC: declare i8* @malloc
+// NOBUILTIN-CALLOC: declare i8* @calloc
+// NOBUILTIN-REALLOC: declare i8* @realloc
Index: clang/lib/CodeGen/CGCall.cpp
===
--- clang/lib/CodeGen/CGCall.cpp
+++ clang/lib/CodeGen/CGCall.cpp
@@ -2048,6 +2048,24 @@
   // allows it to work on indirect virtual function calls.
   if (AttrOnCallSite && TargetDecl->hasAttr())
 FuncAttrs.addAttribute(llvm::Attribute::NoMerge);
+
+  // Add known guaranteed alignment for allocation functions.
+  if (unsigned BuiltinID = Fn->getBuiltinID()) {
+switch (BuiltinID) {
+case Builtin::BIaligned_alloc:
+case Builtin::BIcalloc:
+case Builtin::BImalloc:
+case Builtin::BImemalign:
+case Builtin::BIrealloc:
+case Builtin::BIstrdup:
+case Builtin::BIstrndup:
+  RetAttrs.addAlignmentAttr(Context.getTargetInfo().getNewAlign() /
+Context.getTargetInfo().getCharWidth());
+  break;
+default:
+  break;
+}
+  }
 }
 
 // 'const', 'pure' and 'noalias' attributed functions are also nounwind.
Index: clang/include/clang/Basic/TargetInfo.h
===
--- clang/include/clang/Basic/TargetInfo.h
+++ clang/include/clang/Basic/TargetInfo.h
@@ -612,8 +612,8 @@
   }
 
   /// Return the largest alignment for which a suitably-sized allocation with
-  /// '::operator new(size_t)' is guaranteed to produce a correctly-aligned
-  /// pointer.
+  /// '::operator new(size_t)' or 'malloc' is guaranteed to produce a
+  /// correctly-aligned pointer.
   unsigned getNewAlign() const {
 return NewAlign ? NewAlign : std::max(LongDoubleAlign, LongLongAlign);
   }


Index: clang/test/CodeGen/alloc-fns-alignment.c
===
--- /dev/null
+++ clang/test/CodeGen/alloc-fns-alignment.c
@@ -0,0 +1,35 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm < %s | FileCheck %s --check-prefix=ALIGN16
+// RUN: %clang_cc1 -triple x86_64-windows-msvc  -emit-llvm < %s | FileCheck %s --check-prefix=ALIGN16
+// RUN: %clang_cc1 -triple i386-apple-darwin-emit-llvm < %s | FileCheck %s --check-prefix=ALIGN16
+// RUN: %clang_cc1 -triple i386-unknown-linux-gnu   -emit-llvm < %s | FileCheck %s --check-prefix=ALIGN8
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fno-builtin-malloc  -emit-llvm < %s  | FileCheck %s --check-prefix=NOBUILTIN-MALLOC
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fno-builtin-calloc  -emit-llvm < %s  | FileCheck %s --check-prefix=NOBUILTIN-CALLOC
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fno-builtin-realloc -emit-llvm < %s  | FileCheck %s --check-prefix=NOBUILTIN-REALLOC
+
+typedef __SIZE_TYPE__ size_t;
+
+void *malloc(size_t);
+void *calloc(size_t, size_t);
+void *realloc(void *, size_t);
+
+void *malloc_test(size_t n) {
+  return malloc(n);
+}
+
+void *calloc_test(size_t n) {
+  return calloc(1, n);
+}
+
+void *

[PATCH] D101143: [RISCV] [1/2] Add IR intrinsic for Zbe extension

2021-04-23 Thread LevyHsu via Phabricator via cfe-commits
LevyHsu created this revision.
LevyHsu added reviewers: craig.topper, kito-cheng, asb, jrtc27, Jim.
LevyHsu added projects: clang, LLVM.
Herald added subscribers: vkmr, frasercrmck, evandro, luismarques, apazos, 
sameer.abuasal, s.egerton, benna, psnobl, jocewei, PkmX, the_o, brucehoult, 
MartinMosbeck, rogfer01, edward-jones, zzheng, shiva0217, niosHD, sabuasal, 
simoncook, johnrusso, rbar, hiraditya.
LevyHsu requested review of this revision.
Herald added subscribers: llvm-commits, cfe-commits, MaskRay.

RV32/64:

  bcomress
  bdecompress

RV64 ONLY:

  bcomressw
  bdecompressw


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D101143

Files:
  clang/include/clang/Basic/BuiltinsRISCV.def
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/RISCV/rvb-intrinsics/riscv32-zbe.c
  clang/test/CodeGen/RISCV/rvb-intrinsics/riscv64-zbe.c
  llvm/include/llvm/IR/IntrinsicsRISCV.td
  llvm/lib/Target/RISCV/RISCVISelLowering.cpp
  llvm/lib/Target/RISCV/RISCVISelLowering.h
  llvm/lib/Target/RISCV/RISCVInstrInfoB.td
  llvm/test/CodeGen/RISCV/rv32zbe-intrinsic.ll
  llvm/test/CodeGen/RISCV/rv64zbe-intrinsic.ll

Index: llvm/test/CodeGen/RISCV/rv64zbe-intrinsic.ll
===
--- /dev/null
+++ llvm/test/CodeGen/RISCV/rv64zbe-intrinsic.ll
@@ -0,0 +1,69 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -mtriple=riscv64 -mattr=+experimental-b -verify-machineinstrs < %s \
+; RUN:   | FileCheck %s -check-prefix=RV64IB
+; RUN: llc -mtriple=riscv64 -mattr=+experimental-zbe -verify-machineinstrs < %s \
+; RUN:   | FileCheck %s -check-prefix=RV64IBE
+
+declare i32 @llvm.riscv.bcompress.i32(i32 %a, i32 %b)
+
+define signext i32 @bcompress32(i32 signext %a, i32 signext %b) nounwind {
+; RV64IB-LABEL: bcompress32:
+; RV64IB:   # %bb.0:
+; RV64IB-NEXT:bcompressw a0, a0, a1
+; RV64IB-NEXT:ret
+;
+; RV64IBE-LABEL: bcompress32:
+; RV64IBE:   # %bb.0:
+; RV64IBE-NEXT:bcompressw a0, a0, a1
+; RV64IBE-NEXT:ret
+  %tmp = call i32 @llvm.riscv.bcompress.i32(i32 %a, i32 %b)
+ ret i32 %tmp
+}
+
+declare i32 @llvm.riscv.bdecompress.i32(i32 %a, i32 %b)
+
+define signext i32 @bdecompress32(i32 signext %a, i32 signext %b) nounwind {
+; RV64IB-LABEL: bdecompress32:
+; RV64IB:   # %bb.0:
+; RV64IB-NEXT:bdecompressw a0, a0, a1
+; RV64IB-NEXT:ret
+;
+; RV64IBE-LABEL: bdecompress32:
+; RV64IBE:   # %bb.0:
+; RV64IBE-NEXT:bdecompressw a0, a0, a1
+; RV64IBE-NEXT:ret
+  %tmp = call i32 @llvm.riscv.bdecompress.i32(i32 %a, i32 %b)
+ ret i32 %tmp
+}
+
+declare i64 @llvm.riscv.bcompress.i64(i64 %a, i64 %b)
+
+define i64 @bcompress64(i64 %a, i64 %b) nounwind {
+; RV64IB-LABEL: bcompress64:
+; RV64IB:   # %bb.0:
+; RV64IB-NEXT:bcompress a0, a0, a1
+; RV64IB-NEXT:ret
+;
+; RV64IBE-LABEL: bcompress64:
+; RV64IBE:   # %bb.0:
+; RV64IBE-NEXT:bcompress a0, a0, a1
+; RV64IBE-NEXT:ret
+  %tmp = call i64 @llvm.riscv.bcompress.i64(i64 %a, i64 %b)
+ ret i64 %tmp
+}
+
+declare i64 @llvm.riscv.bdecompress.i64(i64 %a, i64 %b)
+
+define i64 @bdecompress64(i64 %a, i64 %b) nounwind {
+; RV64IB-LABEL: bdecompress64:
+; RV64IB:   # %bb.0:
+; RV64IB-NEXT:bdecompress a0, a0, a1
+; RV64IB-NEXT:ret
+;
+; RV64IBE-LABEL: bdecompress64:
+; RV64IBE:   # %bb.0:
+; RV64IBE-NEXT:bdecompress a0, a0, a1
+; RV64IBE-NEXT:ret
+  %tmp = call i64 @llvm.riscv.bdecompress.i64(i64 %a, i64 %b)
+ ret i64 %tmp
+}
Index: llvm/test/CodeGen/RISCV/rv32zbe-intrinsic.ll
===
--- /dev/null
+++ llvm/test/CodeGen/RISCV/rv32zbe-intrinsic.ll
@@ -0,0 +1,37 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-b -verify-machineinstrs < %s \
+; RUN:   | FileCheck %s -check-prefix=RV32IB
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zbe -verify-machineinstrs < %s \
+; RUN:   | FileCheck %s -check-prefix=RV32IBE
+
+declare i32 @llvm.riscv.bcompress.i32(i32 %a, i32 %b)
+
+define i32 @bcompress32(i32 %a, i32 %b) nounwind {
+; RV32IB-LABEL: bcompress32:
+; RV32IB:   # %bb.0:
+; RV32IB-NEXT:bcompress a0, a0, a1
+; RV32IB-NEXT:ret
+;
+; RV32IBE-LABEL: bcompress32:
+; RV32IBE:   # %bb.0:
+; RV32IBE-NEXT:bcompress a0, a0, a1
+; RV32IBE-NEXT:ret
+  %tmp = call i32 @llvm.riscv.bcompress.i32(i32 %a, i32 %b)
+ ret i32 %tmp
+}
+
+declare i32 @llvm.riscv.bdecompress.i32(i32 %a, i32 %b)
+
+define i32 @bdecompress32(i32 %a, i32 %b) nounwind {
+; RV32IB-LABEL: bdecompress32:
+; RV32IB:   # %bb.0:
+; RV32IB-NEXT:bdecompress a0, a0, a1
+; RV32IB-NEXT:ret
+;
+; RV32IBE-LABEL: bdecompress32:
+; RV32IBE:   # %bb.0:
+; RV32IBE-NEXT:bdecompress a0, a0, a1
+; RV32IBE-NEXT:ret
+  %tmp = call i32 @llvm.riscv.bdecompress.i32(i32 %a, i32 %b)
+ ret i32 %tmp
+}
Index: llvm/lib/Target/RISCV/RISCVInstrInfoB.td

[PATCH] D100879: [Clang] Propagate guaranteed alignment for malloc and others

2021-04-23 Thread John McCall via Phabricator via cfe-commits
rjmccall accepted this revision.
rjmccall added a comment.
This revision is now accepted and ready to land.

Thanks, LGTM.


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

https://reviews.llvm.org/D100879

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


[PATCH] D101144: [RISCV] [2/2] Add IR intrinsic for Zbe extension

2021-04-23 Thread LevyHsu via Phabricator via cfe-commits
LevyHsu created this revision.
LevyHsu added reviewers: craig.topper, jrtc27, Jim, asb, kito-cheng.
LevyHsu added projects: clang, LLVM.
Herald added subscribers: vkmr, frasercrmck, evandro, luismarques, apazos, 
sameer.abuasal, usaxena95, s.egerton, benna, psnobl, kadircet, jocewei, PkmX, 
arphaman, the_o, brucehoult, MartinMosbeck, rogfer01, edward-jones, zzheng, 
shiva0217, niosHD, sabuasal, simoncook, johnrusso, rbar, mgorny.
LevyHsu requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay.
Herald added a project: clang-tools-extra.

RV32/64:

  bcomress
  bdecompress

RV64 ONLY:

  bcomressw
  bdecompressw


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D101144

Files:
  clang-tools-extra/clang-include-fixer/find-all-symbols/STLPostfixHeaderMap.cpp
  clang-tools-extra/clangd/index/CanonicalIncludes.cpp
  clang/lib/Headers/CMakeLists.txt
  clang/lib/Headers/riscv_zbe_intrin.h
  clang/lib/Headers/rvintrin.h
  clang/test/CodeGen/RISCV/rvb-intrinsics/rvintrin.c

Index: clang/test/CodeGen/RISCV/rvb-intrinsics/rvintrin.c
===
--- /dev/null
+++ clang/test/CodeGen/RISCV/rvb-intrinsics/rvintrin.c
@@ -0,0 +1,6 @@
+// RUN: %clang_cc1 -triple riscv32 -fsyntax-only \
+// RUN:   -target-feature +experimental-zbe %s
+// RUN: %clang_cc1 -triple riscv64 -fsyntax-only \
+// RUN:   -target-feature +experimental-zbe %s
+
+#include 
Index: clang/lib/Headers/rvintrin.h
===
--- /dev/null
+++ clang/lib/Headers/rvintrin.h
@@ -0,0 +1,26 @@
+/*===-- rvintrin.h -===
+ *
+ * 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
+ *
+ *===---===
+ */
+
+#ifndef __RVINTRIN_H
+#define __RVINTRIN_H
+
+#define int_xlen_t long
+#define uint_xlen_t unsigned int_xlen_t
+
+#define __DEFAULT_FN_ATTRS \
+  __attribute__((__always_inline__, __artificial__, __nodebug__))
+
+#if defined(__riscv_zbe)
+#include "riscv_zbe_intrin.h"
+#endif
+
+#undef __DEFAULT_FN_ATTRS
+#undef uint_xlen_t
+#undef int_xlen_t
+#endif // __RVINTRIN_H
\ No newline at end of file
Index: clang/lib/Headers/riscv_zbe_intrin.h
===
--- /dev/null
+++ clang/lib/Headers/riscv_zbe_intrin.h
@@ -0,0 +1,51 @@
+/*=== riscv_zbe_intrin.h ---===
+ *
+ * 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
+ *
+ *===---===
+ */
+
+#ifndef __RVINTRIN_H
+#error "Never use  directly; include  instead."
+#endif
+
+#ifndef __RISCV_ZBE_INTRIN_H
+#define __RISCV_ZBE_INTRIN_H
+
+#include 
+
+#if defined(__cplusplus)
+extern "C" {
+#endif
+
+// Zbe
+static __inline__ int32_t __DEFAULT_FN_ATTRS _rv_bcompress_32(int32_t rs1,
+  int32_t rs2) {
+  return __builtin_riscv_bcompress_32(rs1, rs2);
+}
+
+static __inline__ int32_t __DEFAULT_FN_ATTRS _rv_bdecompress_32(int32_t rs1,
+int32_t rs2) {
+  return __builtin_riscv_bdecompress_32(rs1, rs2);
+}
+
+// RV64 ONLY
+#if __riscv_xlen == 64
+static __inline__ int64_t __DEFAULT_FN_ATTRS _rv_bcompress_64(int64_t rs1,
+  int64_t rs2) {
+  return __builtin_riscv_bcompress_64(rs1, rs2);
+}
+
+static __inline__ int64_t __DEFAULT_FN_ATTRS _rv_bdecompress_64(int64_t rs1,
+int64_t rs2) {
+  return __builtin_riscv_bdecompress_64(rs1, rs2);
+}
+#endif // if __riscv_xlen == 64
+
+#if defined(__cplusplus)
+}
+#endif // if defined(__cplusplus)
+
+#endif // __RISCV_ZBE_INTRIN_H
\ No newline at end of file
Index: clang/lib/Headers/CMakeLists.txt
===
--- clang/lib/Headers/CMakeLists.txt
+++ clang/lib/Headers/CMakeLists.txt
@@ -97,6 +97,8 @@
   ptwriteintrin.h
   rdseedintrin.h
   rtmintrin.h
+  rvintrin.h
+  riscv_zbe_intrin.h
   serializeintrin.h
   sgxintrin.h
   s390intrin.h
Index: clang-tools-extra/clangd/index/CanonicalIncludes.cpp
===
--- clang-tools-extra/clangd/index/CanonicalIncludes.cpp
+++ clang-tools-extra/clangd/index/CanonicalIncludes.cpp
@@ -152,6 +152,8 @@
   {"include/prfchwintrin.h", ""},
   {"include/rdseedintrin.h", ""},
   {"include/rtmintrin.h", ""},
+  {"includ

[PATCH] D100821: [RISCV] Implement the vmmv.m/vmnot.m builtin.

2021-04-23 Thread Roger Ferrer Ibanez via Phabricator via cfe-commits
rogfer01 added a comment.

In D100821#2710998 , @HsiangKai wrote:

> Rebase.

Thanks, I had missed that and my comment above was wrong.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100821

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


[PATCH] D100591: [Clang][AArch64] Disable rounding of return values for AArch64

2021-04-23 Thread Tim Northover via Phabricator via cfe-commits
t.p.northover added a comment.

On big-endian targets the rounding up to 64-bits (specified in the AAPCS) is 
significant; it means that structs get passed in the high bits of `x0` rather 
than low. E.g. https://godbolt.org/z/6v36oexsW. I think this patch would break 
that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100591

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


[PATCH] D101060: [Analyzer][StdLibraryFunctionsChecker] Describe arg constraints

2021-04-23 Thread Gabor Marton via Phabricator via cfe-commits
martong marked 3 inline comments as done.
martong added a comment.

Thanks for the review Valeriy!




Comment at: 
clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp:338-339
 }
+llvm_unreachable("The constraint must be either a concrete value or "
+ "encoded in an argument.");
   }();

vsavchenko wrote:
> Just a thought here, maybe we should assert `SizeArgN` instead then?
Absolutely, good point.



Comment at: 
clang/test/Analysis/std-c-library-functions-arg-constraints-notes.cpp:32
+__buf_size_arg_constraint_concrete(buf); // \
+// expected-note{{The size of the 0th arg should be equal to or less than 
the value of 10}} \
+// expected-warning{{}}

vsavchenko wrote:
> Oof, I do understand that we are devs and enumerate things starting from 0. 
> But this is supposed to be human-readable and humans start counting from 1.
I've been thinking a lot about this and I see your point. On the other hand, we 
report warnings to other developers/programmers who are all used to start the 
indexing from 0, they may find it odd to start from 1. 

Alas, the string `0th` makes it obvious that we are talking about the first 
argument, however the string `1st` is ambiguous, even if we start the indexing 
from 0 or from 1. In this sense, starting from 0 makes less confusion.



Comment at: clang/test/Analysis/std-c-library-functions-arg-constraints.c:33
   // report-warning{{Function argument constraint is not satisfied}} \
+  // report-note{{}} \
   // bugpath-warning{{Function argument constraint is not satisfied}} \

vsavchenko wrote:
> What's up with these?
The new explanation of the constraints is added as an extra 'note' tag, which 
is displayed alongside the warning.
In these tests I don't want to test for the note, that would make these tests 
overly specified. For testing the notes we have a separate, newly added test 
file `std-c-library-functions-arg-constraints-notes.cpp`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101060

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


[PATCH] D101060: [Analyzer][StdLibraryFunctionsChecker] Describe arg constraints

2021-04-23 Thread Gabor Marton via Phabricator via cfe-commits
martong updated this revision to Diff 339934.
martong marked 3 inline comments as done.
martong added a comment.

- Assert on SizeArgN


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101060

Files:
  clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
  clang/test/Analysis/std-c-library-functions-arg-constraints-notes.cpp
  clang/test/Analysis/std-c-library-functions-arg-constraints.c
  clang/test/Analysis/std-c-library-functions-arg-constraints.cpp

Index: clang/test/Analysis/std-c-library-functions-arg-constraints.cpp
===
--- clang/test/Analysis/std-c-library-functions-arg-constraints.cpp
+++ clang/test/Analysis/std-c-library-functions-arg-constraints.cpp
@@ -14,5 +14,6 @@
 
 void test_arg_constraint_on_fun_with_default_param() {
   __defaultparam(nullptr); // \
-  // expected-warning{{Function argument constraint is not satisfied}}
+  // expected-warning{{Function argument constraint is not satisfied}} \
+  // expected-note{{}}
 }
Index: clang/test/Analysis/std-c-library-functions-arg-constraints.c
===
--- clang/test/Analysis/std-c-library-functions-arg-constraints.c
+++ clang/test/Analysis/std-c-library-functions-arg-constraints.c
@@ -30,7 +30,9 @@
 void test_alnum_concrete(int v) {
   int ret = isalnum(256); // \
   // report-warning{{Function argument constraint is not satisfied}} \
+  // report-note{{}} \
   // bugpath-warning{{Function argument constraint is not satisfied}} \
+  // bugpath-note{{}} \
   // bugpath-note{{Function argument constraint is not satisfied}}
   (void)ret;
 }
@@ -54,7 +56,9 @@
 
 int ret = isalnum(x); // \
 // report-warning{{Function argument constraint is not satisfied}} \
+// report-note{{}} \
 // bugpath-warning{{Function argument constraint is not satisfied}} \
+// bugpath-note{{}} \
 // bugpath-note{{Function argument constraint is not satisfied}}
 
 (void)ret;
@@ -66,7 +70,9 @@
 void test_toupper_concrete(int v) {
   int ret = toupper(256); // \
   // report-warning{{Function argument constraint is not satisfied}} \
+  // report-note{{}} \
   // bugpath-warning{{Function argument constraint is not satisfied}} \
+  // bugpath-note{{}} \
   // bugpath-note{{Function argument constraint is not satisfied}}
   (void)ret;
 }
@@ -90,7 +96,9 @@
 
 int ret = toupper(x); // \
 // report-warning{{Function argument constraint is not satisfied}} \
+// report-note{{}} \
 // bugpath-warning{{Function argument constraint is not satisfied}} \
+// bugpath-note{{}} \
 // bugpath-note{{Function argument constraint is not satisfied}}
 
 (void)ret;
@@ -102,7 +110,9 @@
 void test_tolower_concrete(int v) {
   int ret = tolower(256); // \
   // report-warning{{Function argument constraint is not satisfied}} \
+  // report-note{{}} \
   // bugpath-warning{{Function argument constraint is not satisfied}} \
+  // bugpath-note{{}} \
   // bugpath-note{{Function argument constraint is not satisfied}}
   (void)ret;
 }
@@ -126,7 +136,9 @@
 
 int ret = tolower(x); // \
 // report-warning{{Function argument constraint is not satisfied}} \
+// report-note{{}} \
 // bugpath-warning{{Function argument constraint is not satisfied}} \
+// bugpath-note{{}} \
 // bugpath-note{{Function argument constraint is not satisfied}}
 
 (void)ret;
@@ -138,7 +150,9 @@
 void test_toascii_concrete(int v) {
   int ret = toascii(256); // \
   // report-warning{{Function argument constraint is not satisfied}} \
+  // report-note{{}} \
   // bugpath-warning{{Function argument constraint is not satisfied}} \
+  // bugpath-note{{}} \
   // bugpath-note{{Function argument constraint is not satisfied}}
   (void)ret;
 }
@@ -162,7 +176,9 @@
 
 int ret = toascii(x); // \
 // report-warning{{Function argument constraint is not satisfied}} \
+// report-note{{}} \
 // bugpath-warning{{Function argument constraint is not satisfied}} \
+// bugpath-note{{}} \
 // bugpath-note{{Function argument constraint is not satisfied}}
 
 (void)ret;
@@ -175,7 +191,9 @@
 void test_notnull_concrete(FILE *fp) {
   fread(0, sizeof(int), 10, fp); // \
   // report-warning{{Function argument constraint is not satisfied}} \
+  // report-note{{}} \
   // bugpath-warning{{Function argument constraint is not satisfied}} \
+  // bugpath-note{{}} \
   // bugpath-note{{Function argument constraint is not satisfied}}
 }
 void test_notnull_symbolic(FILE *fp, int *buf) {
@@ -191,7 +209,9 @@
 // bugpath-note{{Taking true branch}}
 fread(buf, sizeof(int), 10, fp); // \
 // report-warning{{Function argument constraint is not satisfied}} \
+// report-note{{}} \
 // bugpath-warning{{Function argument constraint is not satisfied}} \
+// bugpath-note{{}} \
 // bugpath-note{{Function argument constraint 

[PATCH] D91949: [clang-format] Add BeforeStructInitialization option in BraceWrapping configuration

2021-04-23 Thread Anastasiia Lukianenko via Phabricator via cfe-commits
anastasiia_lukianenko updated this revision to Diff 339943.
anastasiia_lukianenko marked an inline comment as not done.

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

https://reviews.llvm.org/D91949

Files:
  clang/docs/ClangFormatStyleOptions.rst
  clang/include/clang/Format/Format.h
  clang/lib/Format/Format.cpp
  clang/lib/Format/UnwrappedLineParser.cpp
  clang/unittests/Format/FormatTest.cpp

Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -5069,6 +5069,80 @@
 format(Input, Style));
 }
 
+TEST_F(FormatTest, BreakBeforeStructInitialization) {
+  FormatStyle Style = getLLVMStyle();
+  Style.ColumnLimit = 80;
+  Style.BreakBeforeBraces = FormatStyle::BS_Custom;
+  Style.BraceWrapping.BeforeStructInitialization = true;
+  Style.AlwaysBreakTemplateDeclarations = FormatStyle::BTDS_No;
+  verifyFormat("struct new_struct struct_name =\n"
+   "{a = 1};",
+   Style);
+  verifyFormat("struct new_struct struct_name =\n"
+   "{a = 1, b = 2};",
+   Style);
+  verifyFormat("struct new_struct struct_name =\n"
+   "{\n"
+   "a = 1,\n"
+   "b = 2,\n"
+   "};",
+   Style);
+  verifyFormat("typedef struct Foo =\n"
+   "{\n"
+   "a = 1,\n"
+   "b = 2,\n"
+   "};",
+   Style);
+  verifyFormat("static constexpr struct Foo =\n"
+   "{\n"
+   "a = 1,\n"
+   "b = 2,\n"
+   "};",
+   Style);
+  verifyFormat("template <> struct Foo =\n"
+   "{\n"
+   "a = 1,\n"
+   "b = 2,\n"
+   "};",
+   Style);
+  verifyFormat("struct =\n"
+   "{\n"
+   "a = 1,\n"
+   "b = 2,\n"
+   "};",
+   Style);
+  Style.BraceWrapping.BeforeStructInitialization = false;
+  verifyFormat("struct new_struct struct_name = {a = 1};",
+   Style);
+  verifyFormat("struct new_struct struct_name = {a = 1, b = 2};",
+   Style);
+  verifyFormat("struct new_struct struct_name = {\n"
+   "a = 1,\n"
+   "b = 2,\n"
+   "};",
+   Style);
+  verifyFormat("typedef struct Foo = {\n"
+   "a = 1,\n"
+   "b = 2,\n"
+   "};",
+   Style);
+  verifyFormat("static constexpr struct Foo = {\n"
+   "a = 1,\n"
+   "b = 2,\n"
+   "};",
+   Style);
+  verifyFormat("template <> struct Foo = {\n"
+   "a = 1,\n"
+   "b = 2,\n"
+   "};",
+   Style);
+  verifyFormat("struct = {\n"
+   "a = 1,\n"
+   "b = 2,\n"
+   "};",
+   Style);
+}
+
 TEST_F(FormatTest, BreakConstructorInitializersAfterColon) {
   FormatStyle Style = getLLVMStyle();
   Style.BreakConstructorInitializers = FormatStyle::BCIS_AfterColon;
@@ -16328,6 +16402,7 @@
   CHECK_PARSE_NESTED_BOOL(BraceWrapping, BeforeCatch);
   CHECK_PARSE_NESTED_BOOL(BraceWrapping, BeforeElse);
   CHECK_PARSE_NESTED_BOOL(BraceWrapping, BeforeLambdaBody);
+  CHECK_PARSE_NESTED_BOOL(BraceWrapping, BeforeStructInitialization);
   CHECK_PARSE_NESTED_BOOL(BraceWrapping, BeforeWhile);
   CHECK_PARSE_NESTED_BOOL(BraceWrapping, IndentBraces);
   CHECK_PARSE_NESTED_BOOL(BraceWrapping, SplitEmptyFunction);
Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -2702,7 +2702,12 @@
   nextToken();
 }
   }
-  if (FormatTok->Tok.is(tok::l_brace)) {
+  if (FormatTok->Tok.is(tok::equal)) {
+nextToken();
+if (Style.BraceWrapping.BeforeStructInitialization ) {
+  addUnwrappedLine();
+}
+  } else if (FormatTok->Tok.is(tok::l_brace)) {
 if (ParseAsExpr) {
   parseChildBlock();
 } else {
Index: clang/lib/Format/Format.cpp
===
--- clang/lib/Format/Format.cpp
+++ clang/lib/Format/Format.cpp
@@ -720,6 +720,8 @@
 IO.mapOptional("BeforeCatch", Wrapping.BeforeCatch);
 IO.mapOptional("BeforeElse", Wrapping.BeforeElse);
 IO.mapOptional("BeforeLambdaBody", Wrapping.BeforeLambdaBody);
+IO.mapOptional("BeforeStructInitialization",
+   Wrapping.BeforeStructInitialization);
 IO.mapOptional("BeforeWhile", Wrapping.BeforeWhile);
 IO.mapOptional("IndentBraces", Wrapping.IndentBraces);
 IO.mapOptional("SplitEmptyFunction", Wrapping.SplitEmptyFunction);
@@ -831,6 +833,7 @@
 /*BeforeCatch=*/false,

[PATCH] D101051: [clang][deps] Only generate absolute paths when asked to

2021-04-23 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 updated this revision to Diff 339944.
jansvoboda11 added a comment.

Improve naming


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101051

Files:
  clang/include/clang/Tooling/DependencyScanning/DependencyScanningTool.h
  clang/include/clang/Tooling/DependencyScanning/ModuleDepCollector.h
  clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp
  clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
  clang/test/ClangScanDeps/modules-full.cpp
  clang/tools/clang-scan-deps/ClangScanDeps.cpp

Index: clang/tools/clang-scan-deps/ClangScanDeps.cpp
===
--- clang/tools/clang-scan-deps/ClangScanDeps.cpp
+++ clang/tools/clang-scan-deps/ClangScanDeps.cpp
@@ -138,6 +138,31 @@
 llvm::cl::init(ScanningOutputFormat::Make),
 llvm::cl::cat(DependencyScannerCategory));
 
+// This mode is mostly useful for development of explicitly built modules.
+// Command lines will contain arguments specifying modulemap file paths and
+// absolute paths to PCM files in the module cache directory.
+//
+// Build tools that want to put the PCM files in a different location should use
+// the C++ APIs instead, of which there are two flavors:
+//
+// 1. APIs that generate arguments with paths to modulemap and PCM files via
+//callbacks provided by the client:
+// * ModuleDeps::getCanonicalCommandLine(LookupPCMPath, LookupModuleDeps)
+// * FullDependencies::getAdditionalArgs(LookupPCMPath, LookupModuleDeps)
+//
+// 2. APIs that don't generate arguments with paths to modulemap or PCM files
+//and instead expect the client to append them manually after the fact:
+// * ModuleDeps::getCanonicalCommandLineWithoutModulePaths()
+// * FullDependencies::getAdditionalArgsWithoutModulePaths()
+//
+static llvm::cl::opt GenerateModulesPathArgs(
+"generate-modules-path-args",
+llvm::cl::desc(
+"With '-format experimental-full', include arguments specifying "
+"modules-related paths in the generated command lines: "
+"'-fmodule-file=', '-o', '-fmodule-map-file='."),
+llvm::cl::init(false), llvm::cl::cat(DependencyScannerCategory));
+
 llvm::cl::opt
 NumThreads("j", llvm::cl::Optional,
llvm::cl::desc("Number of worker threads to use (default: use "
@@ -260,11 +285,14 @@
   Modules.insert(I, {{MD.ID, InputIndex}, std::move(MD)});
 }
 
-ID.AdditonalCommandLine = FD.getAdditionalCommandLine(
-[&](ModuleID MID) { return lookupPCMPath(MID); },
-[&](ModuleID MID) -> const ModuleDeps & {
-  return lookupModuleDeps(MID);
-});
+ID.AdditionalCommandLine =
+GenerateModulesPathArgs
+? FD.getAdditionalArgs(
+  [&](ModuleID MID) { return lookupPCMPath(MID); },
+  [&](ModuleID MID) -> const ModuleDeps & {
+return lookupModuleDeps(MID);
+  })
+: FD.getAdditionalArgsWithoutModulePaths();
 
 Inputs.push_back(std::move(ID));
   }
@@ -295,11 +323,14 @@
   {"file-deps", toJSONSorted(MD.FileDeps)},
   {"clang-module-deps", toJSONSorted(MD.ClangModuleDeps)},
   {"clang-modulemap-file", MD.ClangModuleMapFile},
-  {"command-line", MD.getFullCommandLine(
-   [&](ModuleID MID) { return lookupPCMPath(MID); },
-   [&](ModuleID MID) -> const ModuleDeps & {
- return lookupModuleDeps(MID);
-   })},
+  {"command-line",
+   GenerateModulesPathArgs
+   ? MD.getCanonicalCommandLine(
+ [&](ModuleID MID) { return lookupPCMPath(MID); },
+ [&](ModuleID MID) -> const ModuleDeps & {
+   return lookupModuleDeps(MID);
+ })
+   : MD.getCanonicalCommandLineWithoutModulePaths()},
   };
   OutModules.push_back(std::move(O));
 }
@@ -311,7 +342,7 @@
   {"clang-context-hash", I.ContextHash},
   {"file-deps", I.FileDeps},
   {"clang-module-deps", toJSONSorted(I.ModuleDeps)},
-  {"command-line", I.AdditonalCommandLine},
+  {"command-line", I.AdditionalCommandLine},
   };
   TUs.push_back(std::move(O));
 }
@@ -358,7 +389,7 @@
 std::string ContextHash;
 std::vector FileDeps;
 std::vector ModuleDeps;
-std::vector AdditonalCommandLine;
+std::vector AdditionalCommandLine;
   };
 
   std::mutex Lock;
Index: clang/test/ClangScanDeps/modules-full.cpp
===
--- clang/test/ClangScanDeps/modules-full.cpp
+++ clang/test/ClangScanDeps/modules-full.cpp
@@ -13,12 +13,17 @@
 // RUN: echo %t.dir > %t.result
 // RUN: clang-scan-deps -compilation-database %t.cdb -j 4 -format experimental-full \
 // RUN:   -mode 

[PATCH] D101060: [Analyzer][StdLibraryFunctionsChecker] Describe arg constraints

2021-04-23 Thread Valeriy Savchenko via Phabricator via cfe-commits
vsavchenko added inline comments.



Comment at: 
clang/test/Analysis/std-c-library-functions-arg-constraints-notes.cpp:32
+__buf_size_arg_constraint_concrete(buf); // \
+// expected-note{{The size of the 0th arg should be equal to or less than 
the value of 10}} \
+// expected-warning{{}}

martong wrote:
> vsavchenko wrote:
> > Oof, I do understand that we are devs and enumerate things starting from 0. 
> > But this is supposed to be human-readable and humans start counting from 1.
> I've been thinking a lot about this and I see your point. On the other hand, 
> we report warnings to other developers/programmers who are all used to start 
> the indexing from 0, they may find it odd to start from 1. 
> 
> Alas, the string `0th` makes it obvious that we are talking about the first 
> argument, however the string `1st` is ambiguous, even if we start the 
> indexing from 0 or from 1. In this sense, starting from 0 makes less 
> confusion.
I know that we are talking to developers, but no developers say that this is a 
0th argument. And IMO the vast majority of developers would think of the 
argument at index 0 when they read '1st' because most of people are not 
compiler engineers and don't think of the list of arguments as an array. 
But that is all opinions after all. What is most important is that clang 
already reports a ton of warnings pointing to a specific argument/parameter by 
its ordinal number.  Simply grep `DiagnosticsSemaKinds.td` for `ordinal` and 
see the examples in tests. As you can guess, they all use ordinals starting 
from **1st**.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101060

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


[PATCH] D101057: [clangd] Allow AST request without range

2021-04-23 Thread Christian Kandeler via Phabricator via cfe-commits
ckandeler updated this revision to Diff 339948.
ckandeler added a comment.
Herald added a subscriber: cfe-commits.

Addressed clang-tidy and clang-format comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101057

Files:
  clang-tools-extra/clangd/ClangdServer.cpp
  clang-tools-extra/clangd/ClangdServer.h
  clang-tools-extra/clangd/Protocol.h
  clang-tools-extra/clangd/test/ast-no-range.test
  clang-tools-extra/clangd/unittests/DumpASTTests.cpp

Index: clang-tools-extra/clangd/unittests/DumpASTTests.cpp
===
--- clang-tools-extra/clangd/unittests/DumpASTTests.cpp
+++ clang-tools-extra/clangd/unittests/DumpASTTests.cpp
@@ -157,6 +157,18 @@
   EXPECT_EQ(Node.children.front().range, Case.range("type"));
 }
 
+TEST(DumpASTTests, NoRange) {
+  ParsedAST AST = TestTU::withCode("int x;").build();
+  auto Node = dumpAST(
+  DynTypedNode::create(*AST.getASTContext().getTranslationUnitDecl()),
+  AST.getTokens(), AST.getASTContext());
+  EXPECT_THAT(Node.arcana, testing::StartsWith("TranslationUnitDecl "));
+  ASSERT_THAT(Node.children, SizeIs(testing::Ge(1u)))
+  << "Expected at least one child node";
+  ASSERT_FALSE(Node.range.hasValue())
+  << "Expected no range for translation unit";
+}
+
 TEST(DumpASTTests, Arcana) {
   ParsedAST AST = TestTU::withCode("int x;").build();
   auto Node = dumpAST(DynTypedNode::create(findDecl(AST, "x")), AST.getTokens(),
Index: clang-tools-extra/clangd/test/ast-no-range.test
===
--- /dev/null
+++ clang-tools-extra/clangd/test/ast-no-range.test
@@ -0,0 +1,53 @@
+# RUN: clangd -lit-test < %s | FileCheck %s
+{"jsonrpc":"2.0","id":0,"method":"initialize","params":{"processId":123,"rootPath":"clangd","capabilities":{},"trace":"off"}}
+---
+{"jsonrpc":"2.0","method":"textDocument/didOpen","params":{"textDocument":{"uri":"test:///simple.cpp","languageId":"cpp","version":1,"text":"int x;"}}}
+---
+{"jsonrpc":"2.0","id":1,"method":"textDocument/ast","params":{"textDocument":{"uri":"test:///simple.cpp"}}}
+#  CHECK:  "id": 1,
+# CHECK-NEXT:  "jsonrpc": "2.0",
+# CHECK-NEXT:  "result": {
+# CHECK-NEXT:"arcana": "{{TranslationUnitDecl.*}}"
+# CHECK-NEXT:"children": [
+# CHECK-NEXT:  {
+#  CHECK:"arcana": "VarDecl {{.*}} x 'int'",
+# CHECK-NEXT:"children": [
+# CHECK-NEXT:  {
+# CHECK-NEXT:"arcana": "QualType {{.*}} 'int' ",
+# CHECK-NEXT:"detail": "int",
+# CHECK-NEXT:"kind": "Builtin",
+# CHECK-NEXT:"range": {
+# CHECK-NEXT:  "end": {
+# CHECK-NEXT:"character": 3,
+# CHECK-NEXT:"line": 0
+# CHECK-NEXT:  },
+# CHECK-NEXT:  "start": {
+# CHECK-NEXT:"character": 0,
+# CHECK-NEXT:"line": 0
+# CHECK-NEXT:  }
+# CHECK-NEXT:},
+# CHECK-NEXT:"role": "type"
+# CHECK-NEXT:  }
+# CHECK-NEXT:],
+# CHECK-NEXT:"detail": "x",
+# CHECK-NEXT:"kind": "Var",
+# CHECK-NEXT:"range": {
+# CHECK-NEXT:  "end": {
+# CHECK-NEXT:"character": 5,
+# CHECK-NEXT:"line": 0
+# CHECK-NEXT:  },
+# CHECK-NEXT:  "start": {
+# CHECK-NEXT:"character": 0,
+# CHECK-NEXT:"line": 0
+# CHECK-NEXT:  }
+# CHECK-NEXT:},
+# CHECK-NEXT:"role": "declaration"
+# CHECK-NEXT:  }
+# CHECK-NEXT:],
+# CHECK-NEXT:"kind": "TranslationUnit",
+# CHECK-NEXT:"role": "declaration"
+# CHECK-NEXT:  }
+---
+{"jsonrpc":"2.0","id":2,"method":"shutdown"}
+---
+{"jsonrpc":"2.0","method":"exit"}
Index: clang-tools-extra/clangd/Protocol.h
===
--- clang-tools-extra/clangd/Protocol.h
+++ clang-tools-extra/clangd/Protocol.h
@@ -1725,7 +1725,9 @@
 
   /// The position of the node to be dumped.
   /// The highest-level node that entirely contains the range will be returned.
-  Range range;
+  /// If no range is given, the top-level translation unit node will be
+  /// returned.
+  llvm::Optional range;
 };
 bool fromJSON(const llvm::json::Value &, ASTParams &, llvm::json::Path);
 
Index: clang-tools-extra/clangd/ClangdServer.h
===
--- clang-tools-extra/clangd/ClangdServer.h
+++ clang-tools-extra/clangd/ClangdServer.h
@@ -344,7 +344,8 @@
   Callback>);
 
   /// Describe the AST subtree for a piece of code.
-  void getAST(PathRef File, Range R, Callback> CB);
+  void getAST(PathRef File, const llvm::Optional &R,
+  Callback> CB);
 
   /// Runs an arbitrary action that has access to the AST of the specified file.
   /// The action will execute on one of ClangdServer's internal threads.
Index: clang-tools-ex

[PATCH] D91950: [clang-format] Add BreakBeforeInlineASMColon configuration

2021-04-23 Thread Anastasiia Lukianenko via Phabricator via cfe-commits
anastasiia_lukianenko updated this revision to Diff 339951.

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

https://reviews.llvm.org/D91950

Files:
  clang/docs/ClangFormatStyleOptions.rst
  clang/include/clang/Format/Format.h
  clang/lib/Format/ContinuationIndenter.cpp
  clang/lib/Format/Format.cpp
  clang/lib/Format/TokenAnnotator.cpp
  clang/unittests/Format/FormatTest.cpp

Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -2666,12 +2666,16 @@
 TEST_F(FormatTest, FormatsInlineASM) {
   verifyFormat("asm(\"xyz\" : \"=a\"(a), \"=d\"(b) : \"a\"(data));");
   verifyFormat("asm(\"nop\" ::: \"memory\");");
+
+  FormatStyle Style = getLLVMStyle();
+  Style.BreakBeforeInlineASMColon = true;
   verifyFormat(
   "asm(\"movq\\t%%rbx, %%rsi\\n\\t\"\n"
   "\"cpuid\\n\\t\"\n"
   "\"xchgq\\t%%rbx, %%rsi\\n\\t\"\n"
   ": \"=a\"(*rEAX), \"=S\"(*rEBX), \"=c\"(*rECX), \"=d\"(*rEDX)\n"
-  ": \"a\"(value));");
+  ": \"a\"(value));",
+  Style);
   EXPECT_EQ(
   "void NS_InvokeByIndex(void *that, unsigned int methodIndex) {\n"
   "  __asm {\n"
@@ -5069,6 +5073,43 @@
 format(Input, Style));
 }
 
+TEST_F(FormatTest, BreakBeforeInlineASMColon) {
+  FormatStyle Style = getLLVMStyle();
+  Style.BreakStringLiterals = false;
+  Style.BreakBeforeInlineASMColon = false;
+  /* Test the behaviour with long lines */
+  Style.ColumnLimit = 40;
+  verifyFormat("asm volatile(\"lng\",\n"
+   " : : val);",
+   Style);
+  verifyFormat("asm volatile(\"lng\",\n"
+   " : val1 : val2);",
+   Style);
+  Style.ColumnLimit = 80;
+  verifyFormat("asm volatile(\"string\", : : val);", Style);
+  verifyFormat("asm volatile(\"string\", : val1 : val2);", Style);
+
+  Style.BreakBeforeInlineASMColon = true;
+  verifyFormat("asm volatile(\"string\",\n"
+   " :\n"
+   " : val);",
+   Style);
+  verifyFormat("asm volatile(\"string\",\n"
+   " : val1\n"
+   " : val2);",
+   Style);
+  /* Test the behaviour with long lines */
+  Style.ColumnLimit = 40;
+  verifyFormat("asm volatile(\"lng\",\n"
+   " :\n"
+   " : val);",
+   Style);
+  verifyFormat("asm volatile(\"lng\",\n"
+   " : val1\n"
+   " : val2);",
+   Style);
+}
+
 TEST_F(FormatTest, BreakConstructorInitializersAfterColon) {
   FormatStyle Style = getLLVMStyle();
   Style.BreakConstructorInitializers = FormatStyle::BCIS_AfterColon;
@@ -18420,15 +18461,18 @@
   // A list of several ASM symbolic names.
   verifyFormat(R"(asm("mov %[e], %[d]" : [d] "=rm"(d), [e] "rm"(*e));)");
 
+  // ASM symbolic names in inline ASM with no outputs.
+  verifyFormat(R"(asm("mov %[e], %[d]" : : [d] "=rm"(d), [e] "rm"(*e));)");
+
+  format::FormatStyle Style = format::getLLVMStyle();
+  Style.BreakBeforeInlineASMColon = true;
   // ASM symbolic names in inline ASM with inputs and outputs.
   verifyFormat(R"(//
 asm("cmoveq %1, %2, %[result]"
 : [result] "=r"(result)
 : "r"(test), "r"(new), "[result]"(old));
-)");
-
-  // ASM symbolic names in inline ASM with no outputs.
-  verifyFormat(R"(asm("mov %[e], %[d]" : : [d] "=rm"(d), [e] "rm"(*e));)");
+)",
+Style);
 }
 
 TEST_F(FormatTest, GuessedLanguageWithInlineAsmClobbers) {
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -3514,6 +3514,9 @@
   const FormatToken &Left = *Right.Previous;
   if (Right.NewlinesBefore > 1 && Style.MaxEmptyLinesToKeep > 0)
 return true;
+  if (Line.startsWith(tok::kw_asm) && Right.is(TT_InlineASMColon) &&
+  Style.BreakBeforeInlineASMColon)
+return true;
 
   if (Style.isCSharp()) {
 if (Right.is(TT_CSharpNamedArgumentColon) ||
Index: clang/lib/Format/Format.cpp
===
--- clang/lib/Format/Format.cpp
+++ clang/lib/Format/Format.cpp
@@ -554,6 +554,9 @@
 Style.BreakInheritanceList == FormatStyle::BILS_BeforeColon)
   Style.BreakInheritanceList = FormatStyle::BILS_BeforeComma;
 
+IO.mapOptional("BreakBeforeInlineASMColon",
+   Style.BreakBeforeInlineASMColon);
+
 IO.mapOptional("BreakBeforeTernaryOperators",
Style.BreakBeforeTernaryOperators);
 
@@ -940,6 +943,7 @@
   LLVMStyle.BinPackParameters = true;
   LLVMStyle.BreakBeforeBinaryOperators = FormatStyle::BOS_None;
   LLVMStyle.BreakBeforeConceptDeclarations = true;
+  LLVMStyle.BreakBeforeInlineASMColo

[PATCH] D100984: [OpenCL] Remove the need for subgroups extension pragma in enqueue kernel builtins

2021-04-23 Thread Anton Zabaznov via Phabricator via cfe-commits
azabaznov accepted this revision.
azabaznov added a comment.
This revision is now accepted and ready to land.

LGTM!


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

https://reviews.llvm.org/D100984

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


[PATCH] D100879: [Clang] Propagate guaranteed alignment for malloc and others

2021-04-23 Thread Dávid Bolvanský 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 rGc2297544c047: [Clang] Propagate guaranteed alignment for 
malloc and others (authored by xbolva00).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100879

Files:
  clang/include/clang/Basic/TargetInfo.h
  clang/lib/CodeGen/CGCall.cpp
  clang/test/CodeGen/alloc-fns-alignment.c


Index: clang/test/CodeGen/alloc-fns-alignment.c
===
--- /dev/null
+++ clang/test/CodeGen/alloc-fns-alignment.c
@@ -0,0 +1,35 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm < %s | 
FileCheck %s --check-prefix=ALIGN16
+// RUN: %clang_cc1 -triple x86_64-windows-msvc  -emit-llvm < %s | 
FileCheck %s --check-prefix=ALIGN16
+// RUN: %clang_cc1 -triple i386-apple-darwin-emit-llvm < %s | 
FileCheck %s --check-prefix=ALIGN16
+// RUN: %clang_cc1 -triple i386-unknown-linux-gnu   -emit-llvm < %s | 
FileCheck %s --check-prefix=ALIGN8
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fno-builtin-malloc  
-emit-llvm < %s  | FileCheck %s --check-prefix=NOBUILTIN-MALLOC
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fno-builtin-calloc  
-emit-llvm < %s  | FileCheck %s --check-prefix=NOBUILTIN-CALLOC
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fno-builtin-realloc 
-emit-llvm < %s  | FileCheck %s --check-prefix=NOBUILTIN-REALLOC
+
+typedef __SIZE_TYPE__ size_t;
+
+void *malloc(size_t);
+void *calloc(size_t, size_t);
+void *realloc(void *, size_t);
+
+void *malloc_test(size_t n) {
+  return malloc(n);
+}
+
+void *calloc_test(size_t n) {
+  return calloc(1, n);
+}
+
+void *raalloc_test(void *p, size_t n) {
+  return realloc(p, n);
+}
+
+// ALIGN16: align 16 i8* @malloc
+// ALIGN16: align 16 i8* @calloc
+// ALIGN16: align 16 i8* @realloc
+// ALIGN8: align 8 i8* @malloc
+// ALIGN8: align 8 i8* @calloc
+// ALIGN8: align 8 i8* @realloc
+// NOBUILTIN-MALLOC: declare i8* @malloc
+// NOBUILTIN-CALLOC: declare i8* @calloc
+// NOBUILTIN-REALLOC: declare i8* @realloc
Index: clang/lib/CodeGen/CGCall.cpp
===
--- clang/lib/CodeGen/CGCall.cpp
+++ clang/lib/CodeGen/CGCall.cpp
@@ -2048,6 +2048,24 @@
   // allows it to work on indirect virtual function calls.
   if (AttrOnCallSite && TargetDecl->hasAttr())
 FuncAttrs.addAttribute(llvm::Attribute::NoMerge);
+
+  // Add known guaranteed alignment for allocation functions.
+  if (unsigned BuiltinID = Fn->getBuiltinID()) {
+switch (BuiltinID) {
+case Builtin::BIaligned_alloc:
+case Builtin::BIcalloc:
+case Builtin::BImalloc:
+case Builtin::BImemalign:
+case Builtin::BIrealloc:
+case Builtin::BIstrdup:
+case Builtin::BIstrndup:
+  RetAttrs.addAlignmentAttr(Context.getTargetInfo().getNewAlign() /
+Context.getTargetInfo().getCharWidth());
+  break;
+default:
+  break;
+}
+  }
 }
 
 // 'const', 'pure' and 'noalias' attributed functions are also nounwind.
Index: clang/include/clang/Basic/TargetInfo.h
===
--- clang/include/clang/Basic/TargetInfo.h
+++ clang/include/clang/Basic/TargetInfo.h
@@ -612,8 +612,8 @@
   }
 
   /// Return the largest alignment for which a suitably-sized allocation with
-  /// '::operator new(size_t)' is guaranteed to produce a correctly-aligned
-  /// pointer.
+  /// '::operator new(size_t)' or 'malloc' is guaranteed to produce a
+  /// correctly-aligned pointer.
   unsigned getNewAlign() const {
 return NewAlign ? NewAlign : std::max(LongDoubleAlign, LongLongAlign);
   }


Index: clang/test/CodeGen/alloc-fns-alignment.c
===
--- /dev/null
+++ clang/test/CodeGen/alloc-fns-alignment.c
@@ -0,0 +1,35 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm < %s | FileCheck %s --check-prefix=ALIGN16
+// RUN: %clang_cc1 -triple x86_64-windows-msvc  -emit-llvm < %s | FileCheck %s --check-prefix=ALIGN16
+// RUN: %clang_cc1 -triple i386-apple-darwin-emit-llvm < %s | FileCheck %s --check-prefix=ALIGN16
+// RUN: %clang_cc1 -triple i386-unknown-linux-gnu   -emit-llvm < %s | FileCheck %s --check-prefix=ALIGN8
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fno-builtin-malloc  -emit-llvm < %s  | FileCheck %s --check-prefix=NOBUILTIN-MALLOC
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fno-builtin-calloc  -emit-llvm < %s  | FileCheck %s --check-prefix=NOBUILTIN-CALLOC
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fno-builtin-realloc -emit-llvm < %s  | FileCheck %s --check-prefix=NOBUILTIN-REALLOC
+
+typedef __SIZE_TYPE__ size_t;
+
+void *malloc(size_t);
+void *calloc

[clang] c229754 - [Clang] Propagate guaranteed alignment for malloc and others

2021-04-23 Thread Dávid Bolvanský via cfe-commits

Author: Dávid Bolvanský
Date: 2021-04-23T11:07:14+02:00
New Revision: c2297544c04764237cedc523083c7be2fb3833d4

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

LOG: [Clang] Propagate guaranteed alignment for malloc and others

LLVM should be smarter about *known* malloc's alignment and this knowledge may 
enable other optimizations.

Originally started as LLVM patch - https://reviews.llvm.org/D100862 but this 
logic should be really in Clang.

Reviewed By: rjmccall

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

Added: 
clang/test/CodeGen/alloc-fns-alignment.c

Modified: 
clang/include/clang/Basic/TargetInfo.h
clang/lib/CodeGen/CGCall.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/TargetInfo.h 
b/clang/include/clang/Basic/TargetInfo.h
index 3bcaaceb63d8..449c026639b9 100644
--- a/clang/include/clang/Basic/TargetInfo.h
+++ b/clang/include/clang/Basic/TargetInfo.h
@@ -612,8 +612,8 @@ class TargetInfo : public virtual TransferrableTargetInfo,
   }
 
   /// Return the largest alignment for which a suitably-sized allocation with
-  /// '::operator new(size_t)' is guaranteed to produce a correctly-aligned
-  /// pointer.
+  /// '::operator new(size_t)' or 'malloc' is guaranteed to produce a
+  /// correctly-aligned pointer.
   unsigned getNewAlign() const {
 return NewAlign ? NewAlign : std::max(LongDoubleAlign, LongLongAlign);
   }

diff  --git a/clang/lib/CodeGen/CGCall.cpp b/clang/lib/CodeGen/CGCall.cpp
index 366c83eeb8e8..6c77f1889fb5 100644
--- a/clang/lib/CodeGen/CGCall.cpp
+++ b/clang/lib/CodeGen/CGCall.cpp
@@ -2048,6 +2048,24 @@ void CodeGenModule::ConstructAttributeList(
   // allows it to work on indirect virtual function calls.
   if (AttrOnCallSite && TargetDecl->hasAttr())
 FuncAttrs.addAttribute(llvm::Attribute::NoMerge);
+
+  // Add known guaranteed alignment for allocation functions.
+  if (unsigned BuiltinID = Fn->getBuiltinID()) {
+switch (BuiltinID) {
+case Builtin::BIaligned_alloc:
+case Builtin::BIcalloc:
+case Builtin::BImalloc:
+case Builtin::BImemalign:
+case Builtin::BIrealloc:
+case Builtin::BIstrdup:
+case Builtin::BIstrndup:
+  RetAttrs.addAlignmentAttr(Context.getTargetInfo().getNewAlign() /
+Context.getTargetInfo().getCharWidth());
+  break;
+default:
+  break;
+}
+  }
 }
 
 // 'const', 'pure' and 'noalias' attributed functions are also nounwind.

diff  --git a/clang/test/CodeGen/alloc-fns-alignment.c 
b/clang/test/CodeGen/alloc-fns-alignment.c
new file mode 100644
index ..d2f9b467196a
--- /dev/null
+++ b/clang/test/CodeGen/alloc-fns-alignment.c
@@ -0,0 +1,35 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm < %s | 
FileCheck %s --check-prefix=ALIGN16
+// RUN: %clang_cc1 -triple x86_64-windows-msvc  -emit-llvm < %s | 
FileCheck %s --check-prefix=ALIGN16
+// RUN: %clang_cc1 -triple i386-apple-darwin-emit-llvm < %s | 
FileCheck %s --check-prefix=ALIGN16
+// RUN: %clang_cc1 -triple i386-unknown-linux-gnu   -emit-llvm < %s | 
FileCheck %s --check-prefix=ALIGN8
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fno-builtin-malloc  
-emit-llvm < %s  | FileCheck %s --check-prefix=NOBUILTIN-MALLOC
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fno-builtin-calloc  
-emit-llvm < %s  | FileCheck %s --check-prefix=NOBUILTIN-CALLOC
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fno-builtin-realloc 
-emit-llvm < %s  | FileCheck %s --check-prefix=NOBUILTIN-REALLOC
+
+typedef __SIZE_TYPE__ size_t;
+
+void *malloc(size_t);
+void *calloc(size_t, size_t);
+void *realloc(void *, size_t);
+
+void *malloc_test(size_t n) {
+  return malloc(n);
+}
+
+void *calloc_test(size_t n) {
+  return calloc(1, n);
+}
+
+void *raalloc_test(void *p, size_t n) {
+  return realloc(p, n);
+}
+
+// ALIGN16: align 16 i8* @malloc
+// ALIGN16: align 16 i8* @calloc
+// ALIGN16: align 16 i8* @realloc
+// ALIGN8: align 8 i8* @malloc
+// ALIGN8: align 8 i8* @calloc
+// ALIGN8: align 8 i8* @realloc
+// NOBUILTIN-MALLOC: declare i8* @malloc
+// NOBUILTIN-CALLOC: declare i8* @calloc
+// NOBUILTIN-REALLOC: declare i8* @realloc



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


[PATCH] D100985: [OpenCL] Remove pragma requirement for functions from Arm dot extension

2021-04-23 Thread Marco Antognini via Phabricator via cfe-commits
mantognini accepted this revision.
mantognini added a comment.

Feels appropriate to remove this indeed.


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

https://reviews.llvm.org/D100985

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


[PATCH] D100984: [OpenCL] Remove the need for subgroups extension pragma in enqueue kernel builtins

2021-04-23 Thread Marco Antognini via Phabricator via cfe-commits
mantognini accepted this revision.
mantognini added a comment.

Thanks, I believe this goes in the right direction.


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

https://reviews.llvm.org/D100984

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


[PATCH] D100980: [OpenCL] Allow use of double type without extension pragma

2021-04-23 Thread Anton Zabaznov via Phabricator via cfe-commits
azabaznov added a comment.

> do you think it is valuable to keep this behavior at all?

As I said, I would be happy too if we remove pragma extension as it will really 
simplify the codebase of OpenCL in clang and the usage of optional 
functionality itself. Maybe we should add a diagnostic that pragma is ignored?


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

https://reviews.llvm.org/D100980

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


[clang] 6914a0e - Revert "[Clang] Propagate guaranteed alignment for malloc and others"

2021-04-23 Thread Dávid Bolvanský via cfe-commits

Author: Dávid Bolvanský
Date: 2021-04-23T11:33:33+02:00
New Revision: 6914a0ed2b30924b188968e59a83efa07ac5fe57

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

LOG: Revert "[Clang] Propagate guaranteed alignment for malloc and others"

This reverts commit c2297544c04764237cedc523083c7be2fb3833d4. Some buildbots 
are broken.

Added: 


Modified: 
clang/include/clang/Basic/TargetInfo.h
clang/lib/CodeGen/CGCall.cpp

Removed: 
clang/test/CodeGen/alloc-fns-alignment.c



diff  --git a/clang/include/clang/Basic/TargetInfo.h 
b/clang/include/clang/Basic/TargetInfo.h
index 449c026639b9..3bcaaceb63d8 100644
--- a/clang/include/clang/Basic/TargetInfo.h
+++ b/clang/include/clang/Basic/TargetInfo.h
@@ -612,8 +612,8 @@ class TargetInfo : public virtual TransferrableTargetInfo,
   }
 
   /// Return the largest alignment for which a suitably-sized allocation with
-  /// '::operator new(size_t)' or 'malloc' is guaranteed to produce a
-  /// correctly-aligned pointer.
+  /// '::operator new(size_t)' is guaranteed to produce a correctly-aligned
+  /// pointer.
   unsigned getNewAlign() const {
 return NewAlign ? NewAlign : std::max(LongDoubleAlign, LongLongAlign);
   }

diff  --git a/clang/lib/CodeGen/CGCall.cpp b/clang/lib/CodeGen/CGCall.cpp
index 6c77f1889fb5..366c83eeb8e8 100644
--- a/clang/lib/CodeGen/CGCall.cpp
+++ b/clang/lib/CodeGen/CGCall.cpp
@@ -2048,24 +2048,6 @@ void CodeGenModule::ConstructAttributeList(
   // allows it to work on indirect virtual function calls.
   if (AttrOnCallSite && TargetDecl->hasAttr())
 FuncAttrs.addAttribute(llvm::Attribute::NoMerge);
-
-  // Add known guaranteed alignment for allocation functions.
-  if (unsigned BuiltinID = Fn->getBuiltinID()) {
-switch (BuiltinID) {
-case Builtin::BIaligned_alloc:
-case Builtin::BIcalloc:
-case Builtin::BImalloc:
-case Builtin::BImemalign:
-case Builtin::BIrealloc:
-case Builtin::BIstrdup:
-case Builtin::BIstrndup:
-  RetAttrs.addAlignmentAttr(Context.getTargetInfo().getNewAlign() /
-Context.getTargetInfo().getCharWidth());
-  break;
-default:
-  break;
-}
-  }
 }
 
 // 'const', 'pure' and 'noalias' attributed functions are also nounwind.

diff  --git a/clang/test/CodeGen/alloc-fns-alignment.c 
b/clang/test/CodeGen/alloc-fns-alignment.c
deleted file mode 100644
index d2f9b467196a..
--- a/clang/test/CodeGen/alloc-fns-alignment.c
+++ /dev/null
@@ -1,35 +0,0 @@
-// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm < %s | 
FileCheck %s --check-prefix=ALIGN16
-// RUN: %clang_cc1 -triple x86_64-windows-msvc  -emit-llvm < %s | 
FileCheck %s --check-prefix=ALIGN16
-// RUN: %clang_cc1 -triple i386-apple-darwin-emit-llvm < %s | 
FileCheck %s --check-prefix=ALIGN16
-// RUN: %clang_cc1 -triple i386-unknown-linux-gnu   -emit-llvm < %s | 
FileCheck %s --check-prefix=ALIGN8
-// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fno-builtin-malloc  
-emit-llvm < %s  | FileCheck %s --check-prefix=NOBUILTIN-MALLOC
-// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fno-builtin-calloc  
-emit-llvm < %s  | FileCheck %s --check-prefix=NOBUILTIN-CALLOC
-// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fno-builtin-realloc 
-emit-llvm < %s  | FileCheck %s --check-prefix=NOBUILTIN-REALLOC
-
-typedef __SIZE_TYPE__ size_t;
-
-void *malloc(size_t);
-void *calloc(size_t, size_t);
-void *realloc(void *, size_t);
-
-void *malloc_test(size_t n) {
-  return malloc(n);
-}
-
-void *calloc_test(size_t n) {
-  return calloc(1, n);
-}
-
-void *raalloc_test(void *p, size_t n) {
-  return realloc(p, n);
-}
-
-// ALIGN16: align 16 i8* @malloc
-// ALIGN16: align 16 i8* @calloc
-// ALIGN16: align 16 i8* @realloc
-// ALIGN8: align 8 i8* @malloc
-// ALIGN8: align 8 i8* @calloc
-// ALIGN8: align 8 i8* @realloc
-// NOBUILTIN-MALLOC: declare i8* @malloc
-// NOBUILTIN-CALLOC: declare i8* @calloc
-// NOBUILTIN-REALLOC: declare i8* @realloc



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


[PATCH] D101057: [clangd] Allow AST request without range

2021-04-23 Thread Sam McCall via Phabricator via cfe-commits
sammccall added inline comments.



Comment at: clang-tools-extra/clangd/ClangdServer.cpp:895
+  auto Node = DynTypedNode::create(
+*Inputs->AST.getASTContext().getTranslationUnitDecl());
+  return CB(dumpAST(Node, Inputs->AST.getTokens(),

Ooh, there's a problem here...

TraverseDecl(TranslationUnitDecl) is going to deserialize the whole preamble 
and try to return the AST for every decl in every included header.
Apart from a huge amount of data, it's going to be extremely slow, we try to 
avoid ever doing this.

I think this should be observable in a unit test: if you set TestTU.Code and 
TestTU.HeaderCode, we want decls from the latter not to be visible in the 
dumped tree.

---

Instead, dumpAST should call DumpVisitor.TraverseAST(), which runs over the 
TraversalScope forest (i.e. all the top-level decls of the current file). But 
we still need the TranslationUnitDecl in order to have a single root.

Therefore I think we need this logic for "full tree" dumping:
```
DumpVisitor.traverseNode("declaration", TUDecl, [&] { DumpVisitor.TraverseAST() 
});
```

I think it's OK to keep the dumpAST signature as-is (i.e. pass a DynTypedNode 
with TUDecl in it as you're doing now) and just override 
TraverseTranslationUnitDecl with this special case. However both dumpAST() and 
the callsite should have a comment saying that TranslationUnitDecl is safe/has 
these special semantics, as that's not typical in clangd.

---

(The previous version of this patch had this problem too, it was just less 
obvious. Sorry for not catching it in the first round!)



Comment at: clang-tools-extra/clangd/ClangdServer.h:347
   /// Describe the AST subtree for a piece of code.
-  void getAST(PathRef File, Range R, Callback> CB);
+  void getAST(PathRef File, const llvm::Optional &R,
+  Callback> CB);

Nit: we tend to pass Range etc by value rather than const ref.
I actually have no idea why! But probably best to be consistent and if we clean 
this up we can do it everywhere at once.



Comment at: clang-tools-extra/clangd/Protocol.h:1728
   /// The highest-level node that entirely contains the range will be returned.
-  Range range;
+  /// If no range is given, the top-level translation unit node will be
+  /// returned.

nit: top-level->root
(We usually use "top-level" to mean children of TUDecl)



Comment at: clang-tools-extra/clangd/unittests/DumpASTTests.cpp:160
 
+TEST(DumpASTTests, NoRange) {
+  ParsedAST AST = TestTU::withCode("int x;").build();

as mentioned, this test should have decls in the header file too (HeaderCode, 
which is implicitly included) to make sure that we're not returning those


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101057

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


[PATCH] D91054: [Clang][OpenMP] Frontend work for sections - D89671

2021-04-23 Thread Fady Ghanim via Phabricator via cfe-commits
fghanim added a comment.



> This is generally fine with me, @fghanim @Meinersbur any concerns?

I have none. All good for me


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91054

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


[PATCH] D101066: [clangd] Dont index deeply nested symbols

2021-04-23 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet updated this revision to Diff 339960.
kadircet added a comment.
Herald added a subscriber: cfe-commits.

- Revert unrelated changes in tests


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101066

Files:
  clang-tools-extra/clangd/index/IndexAction.cpp
  clang-tools-extra/clangd/unittests/IndexActionTests.cpp


Index: clang-tools-extra/clangd/unittests/IndexActionTests.cpp
===
--- clang-tools-extra/clangd/unittests/IndexActionTests.cpp
+++ clang-tools-extra/clangd/unittests/IndexActionTests.cpp
@@ -281,6 +281,36 @@
   EXPECT_THAT(Ref.Location.FileURI, EndsWith("good.h"));
 }
 
+TEST_F(IndexActionTest, SkipNestedSymbols) {
+  std::string MainFilePath = testPath("main.cpp");
+  addFile(MainFilePath, R"cpp(
+  namespace ns1 {
+  namespace ns2 {
+  namespace ns3 {
+  namespace ns4 {
+  namespace ns5 {
+  namespace ns6 {
+  namespace ns7 {
+  namespace ns8 {
+  namespace ns9 {
+  class Bar {};
+  void foo() {
+class Baz {};
+  }
+  }
+  }
+  }
+  }
+  }
+  }
+  }
+  }
+  })cpp");
+  IndexFileIn IndexFile = runIndexingAction(MainFilePath, {"-std=c++14"});
+  EXPECT_THAT(*IndexFile.Symbols, testing::Contains(HasName("foo")));
+  EXPECT_THAT(*IndexFile.Symbols, testing::Contains(HasName("Bar")));
+  EXPECT_THAT(*IndexFile.Symbols, Not(testing::Contains(HasName("Baz";
+}
 } // namespace
 } // namespace clangd
 } // namespace clang
Index: clang-tools-extra/clangd/index/IndexAction.cpp
===
--- clang-tools-extra/clangd/index/IndexAction.cpp
+++ clang-tools-extra/clangd/index/IndexAction.cpp
@@ -21,6 +21,7 @@
 #include "clang/Index/IndexingOptions.h"
 #include "clang/Tooling/Tooling.h"
 #include "llvm/ADT/STLExtras.h"
+#include 
 #include 
 #include 
 #include 
@@ -138,6 +139,19 @@
 Includes(std::move(Includes)), Opts(Opts),
 PragmaHandler(collectIWYUHeaderMaps(this->Includes.get())) {
 this->Opts.ShouldTraverseDecl = [this](const Decl *D) {
+  // Many operations performed during indexing is linear in terms of depth
+  // of the decl (USR generation, name lookups, figuring out role of a
+  // reference are some examples). Since we index all the decls nested
+  // inside, it becomes quadratic.
+  // So we give up on symbols nested more than a certain level to keep
+  // indexing time reasonable.
+  static constexpr size_t MaxContextDepth = 10;
+  size_t ContextDepth = 0;
+  for (auto *Ctx = D->getDeclContext(); Ctx && !Ctx->isTranslationUnit();
+   Ctx = Ctx->getParent()) {
+if (++ContextDepth == MaxContextDepth)
+  return false;
+  }
   auto &SM = D->getASTContext().getSourceManager();
   auto FID = SM.getFileID(SM.getExpansionLoc(D->getLocation()));
   if (!FID.isValid())


Index: clang-tools-extra/clangd/unittests/IndexActionTests.cpp
===
--- clang-tools-extra/clangd/unittests/IndexActionTests.cpp
+++ clang-tools-extra/clangd/unittests/IndexActionTests.cpp
@@ -281,6 +281,36 @@
   EXPECT_THAT(Ref.Location.FileURI, EndsWith("good.h"));
 }
 
+TEST_F(IndexActionTest, SkipNestedSymbols) {
+  std::string MainFilePath = testPath("main.cpp");
+  addFile(MainFilePath, R"cpp(
+  namespace ns1 {
+  namespace ns2 {
+  namespace ns3 {
+  namespace ns4 {
+  namespace ns5 {
+  namespace ns6 {
+  namespace ns7 {
+  namespace ns8 {
+  namespace ns9 {
+  class Bar {};
+  void foo() {
+class Baz {};
+  }
+  }
+  }
+  }
+  }
+  }
+  }
+  }
+  }
+  })cpp");
+  IndexFileIn IndexFile = runIndexingAction(MainFilePath, {"-std=c++14"});
+  EXPECT_THAT(*IndexFile.Symbols, testing::Contains(HasName("foo")));
+  EXPECT_THAT(*IndexFile.Symbols, testing::Contains(HasName("Bar")));
+  EXPECT_THAT(*IndexFile.Symbols, Not(testing::Contains(HasName("Baz";
+}
 } // namespace
 } // namespace clangd
 } // namespace clang
Index: clang-tools-extra/clangd/index/IndexAction.cpp
===
--- clang-tools-extra/clangd/index/IndexAction.cpp
+++ clang-tools-extra/clangd/index/IndexAction.cpp
@@ -21,6 +21,7 @@
 #include "clang/Index/IndexingOptions.h"
 #include "clang/Tooling/Tooling.h"
 #include "llvm/ADT/STLExtras.h"
+#include 
 #include 
 #include 
 #include 
@@ -138,6 +139,19 @@
 Includes(std::move(Includes)), Opts(Opts),
 PragmaHandler(collectIWYUHeaderMaps(this->Includes.get())) {
 this->Opts.ShouldTraverseDecl = [this](const Decl *D) {
+  // Many operations performed during indexing is linear in terms of depth
+  // of the decl (USR generation, name lookups, figuring out role of a
+  // reference are some examples). Since we index all the decls nested
+  // inside, it becomes quadratic.
+  // So we give up on symbols nested more than a certain level to keep
+  

[PATCH] D100739: [Coroutines] Handle overaligned frame allocation (2)

2021-04-23 Thread Chuanqi Xu via Phabricator via cfe-commits
ChuanqiXu added a comment.

> This is an alternative to D97915  which 
> missed proper deallocation of the over-allocated frame. This patch handles 
> both allocations and deallocations.

If D97915  is not needed, we should abandon it.

For the example shows in D97915 , it says:

  #include 
  #include 
  #include 
  #include 
  #include 
  
  struct task{
struct alignas(64) promise_type {
  task get_return_object() { return {}; }
  std::experimental::suspend_never initial_suspend() { return {}; }
  std::experimental::suspend_never final_suspend() noexcept { return {}; }
  void return_void() {}
  void unhandled_exception() {}
};
using handle = std::experimental::coroutine_handle;
  };
  
  auto switch_to_new_thread() {
struct awaitable {
  bool await_ready() { return false; }
  void await_suspend(task::handle h) {
auto i = reinterpret_cast(&h.promise());
std::cout << i << std::endl;
assert(i % 64 == 0);
  }
  void await_resume() {}
};
return awaitable{};
  }
  
  task resuming_on_new_thread() {
co_await switch_to_new_thread();
  }
  
  int main() {
resuming_on_new_thread();
  }

The assertion would fail. If this is the root problem, I think we could adjust 
the align for the promise alloca like:

  %promise = alloca %promise_type, align 8

into

  %promise = alloca %promise_type, align 128

In other words, if this the problem we need to solve, I think we could make it 
in a simpler way.

The I looked into the document you give in the summary. The issue#3 says the 
frontend can't do some work in the process of template instantiation due to the 
frontend doesn't know about the align and size of the coroutine. But from the 
implementation, it looks like not the problem this patch wants to solve.

I am really confused about the problem. Could you please restate your problem 
more in more detail? For example, would it make the alignment incorrect like 
the example above? Or does we want the frontend to get alignment information? 
Then what would be affected? From the title, I can guess the size of frame 
would get bigger. But how big would it be? Who would control and determine the 
final size?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100739

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


[PATCH] D101066: [clangd] Dont index deeply nested symbols

2021-04-23 Thread Sam McCall via Phabricator via cfe-commits
sammccall accepted this revision.
sammccall added inline comments.
This revision is now accepted and ready to land.



Comment at: clang-tools-extra/clangd/index/IndexAction.cpp:142
 this->Opts.ShouldTraverseDecl = [this](const Decl *D) {
+  // Many operations performed during indexing is linear in terms of depth
+  // of the decl (USR generation, name lookups, figuring out role of a

I'd consider pulling the logic out into `isDeeplyNested(unsigned MaxDepth=10)` 
in AST.h, to keep this readable & policy-oriented and as we may well want to 
apply this in other places where we use SymbolCollector (or other traversals)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101066

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


[PATCH] D100980: [OpenCL] Allow use of double type without extension pragma

2021-04-23 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia added a comment.

In D100980#2711588 , @azabaznov wrote:

>> do you think it is valuable to keep this behavior at all?
>
> As I said, I would be happy too if we remove pragma extension as it will 
> really simplify the codebase of OpenCL in clang and the usage of optional 
> functionality itself. Maybe we should add a diagnostic that pragma is ignored?

For `cl_khr_fp64` I still want to keep the pragma for the other use case - to 
convert double literal into single-precision 
(https://github.com/KhronosGroup/OpenCL-Docs/issues/578). The reason why I 
think it could be useful is that the precision change might lead to a different 
result depending on the precision of the calculation. So I think pragmas could 
be useful to control whether double literal is single-precision or not to avoid 
this problem occur when code is compiled for different targets?

When we parse the pragma we don't know what it is used for in the code so it 
won't be possible to emit the warning conditionally.


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

https://reviews.llvm.org/D100980

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


[PATCH] D69498: IR: Invert convergent attribute handling

2021-04-23 Thread Matt Arsenault via Phabricator via cfe-commits
arsenm added a comment.

In D69498#2709218 , @sameerds wrote:

> 1. It is actually okay add control dependences to a convergent function as 
> long as the new branches are uniform.
> 2. Some times we hack a transform to avoid doing things that cannot be 
> described as "add new control dependence", and still talk about the function 
> having the above named attribute.
>
> There is another important bug that obfuscates the whole discussion: most 
> places that use "isConvergent()" should in fact first check if it really 
> matters to the surrounding control flow. There is too much loaded onto that 
> one attribute, without sufficient context. The definition of "noconvergent" 
> that I am proposing starts out by first fixing the definition of convergent 
> itself. This definition is independent of target, and only talks about the 
> properties of the control flow that reach the callsite. To repeat, this does 
> not reinterpret the IR in a target-defined way. Like I said, in the new 
> definition, all function calls are convergent even on CPUs, so I don't see 
> where the target comes in. If you still insist on talking about 
> interpretation of core attributes, please start by deconstructing the 
> definition that I propose so I can see what I am missing.

Yes, the current concept of convergent is broken. I think this whole recent 
burst of conversation has been too focused on the current convergent situation 
and this patch in particular. I think we need to conceptually rebase this into 
the world that D85603  creates. The expected 
convergence behavior is not only a target property, but of the source language. 
The frontend ultimately has to express the intended semantics of these cross 
lane regions, and the convergence tokens gives this ability.

My point about not making this target dependent is we shouldn't be trying to 
shoehorn in TTI checks around convergent operations just to save frontends from 
the inconvenience of adding another attribute to function declarations. We can 
interprocedurally infer noconvergent like any other attribute most of the time. 
The convergent calls and their tokens should be interpreted the same even if 
the target CPU doesn't really have cross lane behavior.


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

https://reviews.llvm.org/D69498

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


[PATCH] D100826: [Debug-Info][NFC] add -gstrict-dwarf support in backend

2021-04-23 Thread ChenZheng via Phabricator via cfe-commits
shchenz updated this revision to Diff 339840.
shchenz added a comment.

1: put test cases in single file


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100826

Files:
  clang/lib/CodeGen/BackendUtil.cpp
  llvm/include/llvm/CodeGen/CommandFlags.h
  llvm/include/llvm/Target/TargetOptions.h
  llvm/lib/CodeGen/CommandFlags.cpp
  llvm/test/DebugInfo/PowerPC/strict-dwarf.ll

Index: llvm/test/DebugInfo/PowerPC/strict-dwarf.ll
===
--- /dev/null
+++ 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: DW_AT_alignment
+
+@_ZL3var = internal global i32 0, align 16, !dbg !0
+
+; Function Attrs: noinline noreturn optnone uwtable mustprogress
+define dso_local void @_Z1fv() #0 !dbg !12 {
+entry:
+  call void @_Z4exitv(), !dbg !15
+  ret void, !dbg !16
+}
+
+declare void @_Z4exitv()
+
+; Function Attrs: noinline nounwind optnone uwtable mustprogress
+define dso_local signext i32 @_Z3foov() !dbg !17 {
+entry:
+  %0 = load i32, i32* @_ZL3var, align 16, !dbg !21
+  ret i32 %0, !dbg !22
+}
+
+!llvm.dbg.cu = !{!2}
+!llvm.module.flags = !{!7, !8, !9, !10}
+!llvm.ident = !{!11}
+
+!0 = !DIGlobalVariableExpression(var: !1, expr: !DIExpression())
+!1 = distinct !DIGlobalVariable(name: "var", linkageName: "_ZL3var", scope: !2, file: !3, line: 2, type: !6, isLocal: true, isDefinition: true, align: 128)
+!2 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus, file: !3, producer: "clang version 13.0.0", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, enums: !4, globals: !5, splitDebugInlining: false, nameTableKind: None)
+!3 = !DIFile(filename: "t.cpp", directory: "./")
+!4 = !{}
+!5 = !{!0}
+!6 = !DIBasicType(name: "unsigned int", size: 32, encoding: DW_ATE_unsigned)
+!7 = !{i32 7, !"Dwarf Version", i32 4}
+!8 = !{i32 2, !"Debug Info Version", i32 3}
+!9 = !{i32 1, !"wchar_size", i32 4}
+!10 = !{i32 7, !"uwtable", i32 1}
+!11 = !{!"clang version 13.0.0"}
+!12 = distinct !DISubprogram(name: "f", linkageName: "_Z1fv", scope: !3, file: !3, line: 4, type: !13, scopeLine: 4, flags: DIFlagPrototyped | DIFlagNoReturn, spFlags: DISPFlagDefinition, unit: !2, retainedNodes: !4)
+!13 = !DISubroutineType(types: !14)
+!14 = !{null}
+!15 = !DILocation(line: 5, column: 1, scope: !12)
+!16 = !DILocation(line: 7, column: 1, scope: !12)
+!17 = distinct !DISubprogram(name: "foo", linkageName: "_Z3foov", scope: !3, file: !3, line: 10, type: !18, scopeLine: 11, flags: DIFlagPrototyped, spFlags: DISPFlagDefinition, unit: !2, retainedNodes: !4)
+!18 = !DISubroutineType(types: !19)
+!19 = !{!20}
+!20 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
+!21 = !DILocation(line: 12, column: 18, scope: !17)
+!22 = !DILocation(line: 12, column: 11, scope: !17)
Index: llvm/lib/CodeGen/CommandFlags.cpp
===
--- llvm/lib/CodeGen/CommandFlags.cpp
+++ llvm/lib/CodeGen/CommandFlags.cpp
@@ -97,6 +97,7 @@
 CGOPT(bool, ValueTrackingVariableLocations)
 CGOPT(bool, ForceDwarfFrameSection)
 CGOPT(bool, XRayOmitFunctionIndex)
+CGOPT(bool, DebugStrictDwarf)
 
 codegen::RegisterCodeGenFlags::RegisterCodeGenFlags() {
 #define CGBINDOPT(NAME)\
@@ -471,6 +472,10 @@
   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 @@
   Options.ValueTrackingVariableLocations = getValueTrackingVariableLocations();
   Options.ForceDwarfFrameSection = getForceDwarfFrameSection();
   Options.XRayOmitFunctionIndex = getXRayOmitFunctionIndex();
+  Options.DebugStrictDwarf = getDebugStrictDwarf();
 
   Options.MCOptions = mc::InitMCTargetOptionsFromFlags();
 
Index: llvm/include/llvm/Target/TargetOptions.h
===
--- llvm/include/llvm/Target/TargetOptions.h
+++ llvm/include/llvm/Target/TargetOptions.h
@@ -141,6 +141,7 @@
   SupportsDebugEntryValues(false), EnableDebugEntryValues(false),
   PseudoProbeForProfiling(false), ValueTrackingVariableLocations(false),
   ForceDwarfFrameSection(false), XRayOmitFunctionIndex(false),
+   

[PATCH] D69498: IR: Invert convergent attribute handling

2021-04-23 Thread Sameer Sahasrabuddhe via Phabricator via cfe-commits
sameerds added a comment.

In D69498#2710675 , @arsenm wrote:

> In D69498#2709218 , @sameerds wrote:
>
>> 1. It is actually okay add control dependences to a convergent function as 
>> long as the new branches are uniform.
>> 2. Some times we hack a transform to avoid doing things that cannot be 
>> described as "add new control dependence", and still talk about the function 
>> having the above named attribute.
>>
>> There is another important bug that obfuscates the whole discussion: most 
>> places that use "isConvergent()" should in fact first check if it really 
>> matters to the surrounding control flow. There is too much loaded onto that 
>> one attribute, without sufficient context. The definition of "noconvergent" 
>> that I am proposing starts out by first fixing the definition of convergent 
>> itself. This definition is independent of target, and only talks about the 
>> properties of the control flow that reach the callsite. To repeat, this does 
>> not reinterpret the IR in a target-defined way. Like I said, in the new 
>> definition, all function calls are convergent even on CPUs, so I don't see 
>> where the target comes in. If you still insist on talking about 
>> interpretation of core attributes, please start by deconstructing the 
>> definition that I propose so I can see what I am missing.
>
> Yes, the current concept of convergent is broken. I think this whole recent 
> burst of conversation has been too focused on the current convergent 
> situation and this patch in particular. I think we need to conceptually 
> rebase this into the world that D85603  
> creates.

Actually that is exactly what this current conversation is doing. My definition 
of `noconvergent` first rebases the definition of `convergent` into what D85603 
 does. My wording is no different than the one 
you see here: https://reviews.llvm.org/D85603#change-WRNH9XUSSoR8

> The expected convergence behavior is not only a target property, but of the 
> source language. The frontend ultimately has to express the intended 
> semantics of these cross lane regions, and the convergence tokens gives this 
> ability.

That is true, and it is covered by the simple fact that we both agree that 
`convergent` needs to be the default unless specified by the frontend using 
`noconvergent`.

> My point about not making this target dependent is we shouldn't be trying to 
> shoehorn in TTI checks around convergent operations just to save frontends 
> from the inconvenience of adding another attribute to function declarations. 
> We can interprocedurally infer noconvergent like any other attribute most of 
> the time. The convergent calls and their tokens should be interpreted the 
> same even if the target CPU doesn't really have cross lane behavior.

This is not an attempt to shoehorn TTI checks for mere convenience. You missed 
the part about how the current use of `CallInst::isConvergent()` is broken. 
This is where the wording in D85603  inherits 
a major fault from the existing definition of convergent. It is wrong to say 
that optimizations are plain forbidden by the mere knowledge/assumption that 
some call is convergent. Those optimizations are forbidden only if divergent 
control flow is involved. The definition of `convergent` needs to refrain from 
being prescriptive about what the compiler can and cannot do. See the 
definition of `nosync` for comparison.

The convergent property merely says that the call is special, and then it is up 
to each optimization to decide what happens. That decision is based on whether 
the optimization affects divergent control flow incident on the call, and 
whether that effect is relevant to a convergent function. Now that's where the 
following reasoning comes into play:

1. Every use of isConvergent() needs to be tempered with knowledge of the 
control flow incident on it.
2. The only way to check for divergent control flow is to call on divergence 
analysis.
3. When divergence analysis is called on a target with no divergence, it 
returns `nullptr`, which is treated as equivalent to returning `uniform` for 
every query. This is not hypothetical, it's already happening whenever a 
transform does `if (!DA) { ... }`.
4. Pending an attempt to actually call DA at each of these places, a correct 
simplification is to assume uniform control flow when the target does not have 
divergence, and assume divergent control flow otherwise.

That's all there is to this. Like I keep saying, this is not a 
reinterpretation, nor is it a hack. From my first comment on the thread, it is 
an attempt to recast the whole question o be one about combining optimizations 
with target-specific information. Now before you balk at yet another use of the 
phrase "target-specific", please note that DA is totally target-specific. The 
"sources 

[PATCH] D69498: IR: Invert convergent attribute handling

2021-04-23 Thread Jay Foad via Phabricator via cfe-commits
foad added a comment.

In D69498#2705441 , @sameerds wrote:

> I would propose refining the definition of the `noconvergent` attribute as 
> follows:
>
>> noconvergent:
>>
>> Some targets with a parallel execution model provide cross-thread operations 
>> whose outcome is affected by the presence of divergent control flow. We call 
>> such operations convergent. Optimizations that change control flow may 
>> affect the correctness of a program that uses convergent operations. In the 
>> presence of divergent control flow, such optimizations conservatively treat 
>> every call/invoke instruction as convergent by default. The noconvergent 
>> attribute relaxes this constraint as follows:
>>
>> - The noconvergent attribute can be added to a call/invoke to indicate that 
>> it is not affected by changes to the control flow that reaches it.
>> - The noconvergent attribute can be added to a function to indicate that it 
>> does not execute any convergent operations. A call/invoke automatically 
>> inherits the noconvergent attribute if it is set on the callee.

I don't have much to add to the conversation except to point out that this 
definition defines `noconvergent` in terms of divergent control flow, but the 
langref itself doesn't define what divergent control flow //is//, which makes 
it an incomplete spec. (Perhaps I'm just restating @arsenm's objections.) This 
seems unsatisfactory to me but I have no idea what to do about it. I agree with 
@sameerds that the current definition of `convergent` is too restrictive 
because in practice we really do want to be able to move convergent calls past 
uniform control flow.


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

https://reviews.llvm.org/D69498

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


[PATCH] D89909: [SYCL] Implement SYCL address space attributes handling

2021-04-23 Thread Alexey Bader via Phabricator via cfe-commits
bader updated this revision to Diff 339973.
bader marked an inline comment as done.
bader added a comment.

Generalize getStringLiteralAddressSpace to GetGlobalConstantAddressSpace

Rebased on ToT.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89909

Files:
  clang/include/clang/AST/Type.h
  clang/include/clang/Basic/AddressSpaces.h
  clang/include/clang/Sema/ParsedAttr.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/ItaniumMangle.cpp
  clang/lib/AST/TypePrinter.cpp
  clang/lib/Basic/Targets/AMDGPU.cpp
  clang/lib/Basic/Targets/NVPTX.h
  clang/lib/Basic/Targets/SPIR.h
  clang/lib/Basic/Targets/TCE.h
  clang/lib/Basic/Targets/X86.h
  clang/lib/CodeGen/CGDecl.cpp
  clang/lib/CodeGen/CGExpr.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/CodeGen/CodeGenModule.h
  clang/lib/CodeGen/TargetInfo.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/CodeGenSYCL/address-space-conversions.cpp
  clang/test/CodeGenSYCL/address-space-deduction.cpp
  clang/test/CodeGenSYCL/address-space-mangling.cpp
  clang/test/SemaSYCL/address-space-conversions.cpp
  clang/test/SemaTemplate/address_space-dependent.cpp

Index: clang/test/SemaTemplate/address_space-dependent.cpp
===
--- clang/test/SemaTemplate/address_space-dependent.cpp
+++ clang/test/SemaTemplate/address_space-dependent.cpp
@@ -43,7 +43,7 @@
 
 template 
 void tooBig() {
-  __attribute__((address_space(I))) int *bounds; // expected-error {{address space is larger than the maximum supported (8388593)}}
+  __attribute__((address_space(I))) int *bounds; // expected-error {{address space is larger than the maximum supported (8388590)}}
 }
 
 template 
@@ -101,7 +101,7 @@
   car<1, 2, 3>(); // expected-note {{in instantiation of function template specialization 'car<1, 2, 3>' requested here}}
   HasASTemplateFields<1> HASTF;
   neg<-1>(); // expected-note {{in instantiation of function template specialization 'neg<-1>' requested here}}
-  correct<0x71>();
+  correct<0x7FFFED>();
   tooBig<8388650>(); // expected-note {{in instantiation of function template specialization 'tooBig<8388650>' requested here}}
 
   __attribute__((address_space(1))) char *x;
Index: clang/test/SemaSYCL/address-space-conversions.cpp
===
--- /dev/null
+++ clang/test/SemaSYCL/address-space-conversions.cpp
@@ -0,0 +1,64 @@
+// RUN: %clang_cc1 -fsycl-is-device -verify -fsyntax-only %s
+
+void bar(int &Data) {}
+void bar2(int &Data) {}
+void bar(__attribute__((opencl_private)) int &Data) {}
+void foo(int *Data) {}
+void foo2(int *Data) {}
+void foo(__attribute__((opencl_private)) int *Data) {}
+void baz(__attribute__((opencl_private)) int *Data) {} // expected-note {{candidate function not viable: cannot pass pointer to generic address space as a pointer to address space '__private' in 1st argument}}
+
+template 
+void tmpl(T *t) {}
+
+void usages() {
+  __attribute__((opencl_global)) int *GLOB;
+  __attribute__((opencl_private)) int *PRIV;
+  __attribute__((opencl_local)) int *LOC;
+  int *NoAS;
+
+  GLOB = PRIV; // expected-error {{assigning '__private int *' to '__global int *' changes address space of pointer}}
+  GLOB = LOC; // expected-error {{assigning '__local int *' to '__global int *' changes address space of pointer}}
+  PRIV = static_cast<__attribute__((opencl_private)) int *>(GLOB); // expected-error {{static_cast from '__global int *' to '__private int *' is not allowed}}
+  PRIV = static_cast<__attribute__((opencl_private)) int *>(LOC); // expected-error {{static_cast from '__local int *' to '__private int *' is not allowed}}
+  NoAS = GLOB + PRIV; // expected-error {{invalid operands to binary expression ('__global int *' and '__private int *')}}
+  NoAS = GLOB + LOC; // expected-error {{invalid operands to binary expression ('__global int *' and '__local int *')}}
+  NoAS += GLOB; // expected-error {{invalid operands to binary expression ('int *' and '__global int *')}}
+
+  bar(*GLOB);
+  bar2(*GLOB);
+
+  bar(*PRIV);
+  bar2(*PRIV);
+
+  bar(*NoAS);
+  bar2(*NoAS);
+
+  bar(*LOC);
+  bar2(*LOC);
+
+  foo(GLOB);
+  foo2(GLOB);
+  foo(PRIV);
+  foo2(PRIV);
+  foo(NoAS);
+  foo2(NoAS);
+  foo(LOC);
+  foo2(LOC);
+
+  tmpl(GLOB);
+  tmpl(PRIV);
+  tmpl(NoAS);
+  tmpl(LOC);
+
+  // Implicit casts to named address space are disallowed
+  baz(NoAS); // expected-error {{no matching function for call to 'baz'}}
+  __attribute__((opencl_local)) int *l = NoAS; // expected-error {{cannot initialize a variable of type '__local int *' with an lvalue of type 'int *'}}
+
+  (void)static_cast(GLOB);
+  (void)static_cast(GLOB);
+  int *i = GLOB;
+  void *v = GLOB;
+  (void)i;
+  (void)v;
+}
Index: clang/test/CodeGenSYCL/address-space-mangling.cpp
===
--- /dev/null
+++ clang/test/CodeGenSYCL/address-space-mangling.cpp
@@ -0,

[PATCH] D100860: [C++4OpenCL] Add missing OpenCL specific diagnostics in templates

2021-04-23 Thread Ole Strohm via Phabricator via cfe-commits
olestrohm updated this revision to Diff 339976.
olestrohm added a comment.

I noticed that I could move the new check above the diagnostic for program 
scope variables, and the check during parsing can then be removed, while 
maintaining good diagnostics.

This does change the diagnostic for `event_t` mentioned above, however it's not 
a bad diagnostic, and actually matches what happens in non-kernel functions, so 
I think it's okay.
I would prefer the previous diagnostic for `event_t`, but that originates in 
the other branch of the same if statement as the program scope diagnostic, so 
it's not easy to separate them out and then insert the new check between them.


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

https://reviews.llvm.org/D100860

Files:
  clang/lib/Sema/SemaDecl.cpp
  clang/test/SemaOpenCL/clk_event_t.cl
  clang/test/SemaOpenCL/event_t.cl
  clang/test/SemaOpenCL/sampler_t.cl
  clang/test/SemaOpenCLCXX/template-opencl-types.clcpp

Index: clang/test/SemaOpenCLCXX/template-opencl-types.clcpp
===
--- /dev/null
+++ clang/test/SemaOpenCLCXX/template-opencl-types.clcpp
@@ -0,0 +1,26 @@
+// RUN: %clang_cc1 %s -pedantic -verify -fsyntax-only
+
+template
+T global_variable; // expected-error{{the '__global clk_event_t' type cannot be used to declare a program scope variable}}
+
+clk_event_t global_event; // expected-error{{the '__global clk_event_t' type cannot be used to declare a program scope variable}}
+
+template
+void templ() {
+  T loc;
+  // expected-error@-1{{type '__private __read_only image1d_t' can only be used as a function parameter in OpenCL}}
+  // expected-error@-2{{declaring variable of type '__private half' is not allowed}}
+  // expected-error@-3{{the event_t type can only be used with __private address space qualifier}}
+}
+
+void foo() {
+  templ(); // expected-note{{in instantiation of function template specialization 'templ<__read_only image1d_t>' requested here}}
+  templ(); // expected-note{{in instantiation of function template specialization 'templ' requested here}}
+  templ<__local event_t>(); // expected-note{{in instantiation of function template specialization 'templ<__local event_t>' requested here}}
+
+  image1d_t img; // expected-error{{type '__private __read_only image1d_t' can only be used as a function parameter in OpenCL}}
+  half h; // expected-error{{declaring variable of type '__private half' is not allowed}}
+  __local event_t e; // expected-error{{the event_t type can only be used with __private address space qualifier}}
+
+  (void) global_variable; // expected-note{{in instantiation of variable template specialization 'global_variable' requested here}}
+}
Index: clang/test/SemaOpenCL/sampler_t.cl
===
--- clang/test/SemaOpenCL/sampler_t.cl
+++ clang/test/SemaOpenCL/sampler_t.cl
@@ -48,9 +48,6 @@
 sampler_t bad(void); //expected-error{{declaring function return value of type 'sampler_t' is not allowed}}
 
 sampler_t global_nonconst_smp = 0; // expected-error {{global sampler requires a const or constant address space qualifier}}
-#ifdef CHECK_SAMPLER_VALUE
-// expected-warning@-2{{sampler initializer has invalid Filter Mode bits}}
-#endif
 
 const sampler_t glb_smp10 = CLK_ADDRESS_CLAMP_TO_EDGE | CLK_NORMALIZED_COORDS_TRUE | CLK_FILTER_LINEAR;
 const constant sampler_t glb_smp11 = CLK_ADDRESS_CLAMP_TO_EDGE | CLK_NORMALIZED_COORDS_TRUE | CLK_FILTER_LINEAR;
Index: clang/test/SemaOpenCL/event_t.cl
===
--- clang/test/SemaOpenCL/event_t.cl
+++ clang/test/SemaOpenCL/event_t.cl
@@ -1,6 +1,6 @@
 // RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only
 
-event_t glb_evt; // expected-error {{the '__private event_t' type cannot be used to declare a program scope variable}} expected-error{{program scope variable must reside in constant address space}}
+event_t glb_evt; // expected-error {{the '__private event_t' type cannot be used to declare a program scope variable}}
 
 constant struct evt_s {
   event_t evt; // expected-error {{the 'event_t' type cannot be used to declare a structure or union field}}
@@ -10,7 +10,7 @@
 
 void kernel ker(event_t argevt) { // expected-error {{'__private event_t' cannot be used as the type of a kernel parameter}}
   event_t e;
-  constant event_t const_evt; // expected-error {{the event_t type can only be used with __private address space qualifier}} expected-error{{variable in constant address space must be initialized}}
+  constant event_t const_evt; // expected-error{{the '__constant event_t' type cannot be used to declare a program scope variable}}
   foo(e);
   foo(0);
   foo(5); // expected-error {{passing 'int' to parameter of incompatible type 'event_t'}}
Index: clang/test/SemaOpenCL/clk_event_t.cl
===
--- clang/test/SemaOpenCL/clk_event_t.cl
+++ clang/test/S

[PATCH] D85802: [clang] Add -fc++-abi= flag for specifying which C++ ABI to use

2021-04-23 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 accepted this revision.
jansvoboda11 added a comment.
This revision is now accepted and ready to land.

In D85802#2709832 , @leonardchan wrote:

> I added `cc1` invocations to the test and an extra one to assert that the 
> flag is actually making it to codegen.

My point wasn't that you were using `%clang` in your tests instead of 
`%clang_cc1`. My point was that you were only checking that the driver accepts 
correct arguments and rejects invalid arguments, but were **not** checking that 
the argument actually influences codegen. This LGTM now though.

In D85802#2709832 , @leonardchan wrote:

> I'm still unsure though how `GenerateLangArgs` should work though.

There are use-cases in the compiler (e.g. dependency scanning), where we need 
to generate command-line from an instance of `CompilerInvocation`. This means 
that each function parsing command-line arguments (`ParseLangArgs`) needs to 
have a counterpart that does the opposite (`GenerateLangArgs`).

We ensure all -cc1 options can be generated this way by doing a round-trip in 
assert builds: `command-line => ParseLangArgs => CompilerInvocation => 
GenerateLangArgs => command-line => ParseLangArgs => CompilerInvocation`.

If some option doesn't get generated in `GenerateLangArgs`, it won't make it to 
the second `CompilerInvocation` which is used by the rest of the compiler. If 
we have good tests that verify the option actually does what it's supposed to, 
they will fail and we can fix the omission.

In D85802#2709832 , @leonardchan wrote:

> Prior to this, I was still able to assert through both a driver and cc1 
> invocation that I get the desired behavior in a debug build with assertions 
> enabled.

That's odd. Does your `CMakeCache.txt` file have 
`CLANG_ROUND_TRIP_CC1_ARGS:BOOL=OFF` by any chance? It's possible it didn't get 
switched to `ON` when D97462  landed.

With the way the tests are written now, I'd expect them to fail in assert build 
without the code generating `-fcxx-abi=`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85802

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


[clang] ddfbdbf - [clang] Do not crash on template specialization following a fatal error

2021-04-23 Thread Adam Czachorowski via cfe-commits

Author: Adam Czachorowski
Date: 2021-04-23T13:34:05+02:00
New Revision: ddfbdbfefae04ea71391a38ed5e9cb6975f6630b

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

LOG: [clang] Do not crash on template specialization following a fatal error

There was a missing isInvalid() check leading to an attempt to
instantiate template with an empty instantiation stack.

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

Added: 
clang/test/SemaCXX/template-specialization-fatal.cpp

Modified: 
clang/lib/Sema/SemaTemplateDeduction.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaTemplateDeduction.cpp 
b/clang/lib/Sema/SemaTemplateDeduction.cpp
index d755696c698c6..7d548e4f8dee1 100644
--- a/clang/lib/Sema/SemaTemplateDeduction.cpp
+++ b/clang/lib/Sema/SemaTemplateDeduction.cpp
@@ -5466,6 +5466,9 @@ static bool isAtLeastAsSpecializedAs(Sema &S, QualType 
T1, QualType T2,
Deduced.end());
   Sema::InstantiatingTemplate Inst(S, Info.getLocation(), P2, DeducedArgs,
Info);
+  if (Inst.isInvalid())
+return false;
+
   auto *TST1 = T1->castAs();
   bool AtLeastAsSpecialized;
   S.runWithSufficientStackSpace(Info.getLocation(), [&] {

diff  --git a/clang/test/SemaCXX/template-specialization-fatal.cpp 
b/clang/test/SemaCXX/template-specialization-fatal.cpp
new file mode 100644
index 0..2191e54c8f162
--- /dev/null
+++ b/clang/test/SemaCXX/template-specialization-fatal.cpp
@@ -0,0 +1,11 @@
+// RUN: %clang_cc1 -verify -fsyntax-only %s
+// Verify clang doesn't assert()-fail on template specialization happening 
after
+// fatal error.
+
+#include "not_found.h" // expected-error {{'not_found.h' file not found}}
+
+template 
+struct foo {};
+
+template 
+struct foo(0)(static_cast(0)()))> {};



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


[PATCH] D100675: [clang] Do not crash on template specialization following a fatal error

2021-04-23 Thread Adam Czachorowski via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGddfbdbfefae0: [clang] Do not crash on template 
specialization following a fatal error (authored by adamcz).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100675

Files:
  clang/lib/Sema/SemaTemplateDeduction.cpp
  clang/test/SemaCXX/template-specialization-fatal.cpp


Index: clang/test/SemaCXX/template-specialization-fatal.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/template-specialization-fatal.cpp
@@ -0,0 +1,11 @@
+// RUN: %clang_cc1 -verify -fsyntax-only %s
+// Verify clang doesn't assert()-fail on template specialization happening 
after
+// fatal error.
+
+#include "not_found.h" // expected-error {{'not_found.h' file not found}}
+
+template 
+struct foo {};
+
+template 
+struct foo(0)(static_cast(0)()))> {};
Index: clang/lib/Sema/SemaTemplateDeduction.cpp
===
--- clang/lib/Sema/SemaTemplateDeduction.cpp
+++ clang/lib/Sema/SemaTemplateDeduction.cpp
@@ -5466,6 +5466,9 @@
Deduced.end());
   Sema::InstantiatingTemplate Inst(S, Info.getLocation(), P2, DeducedArgs,
Info);
+  if (Inst.isInvalid())
+return false;
+
   auto *TST1 = T1->castAs();
   bool AtLeastAsSpecialized;
   S.runWithSufficientStackSpace(Info.getLocation(), [&] {


Index: clang/test/SemaCXX/template-specialization-fatal.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/template-specialization-fatal.cpp
@@ -0,0 +1,11 @@
+// RUN: %clang_cc1 -verify -fsyntax-only %s
+// Verify clang doesn't assert()-fail on template specialization happening after
+// fatal error.
+
+#include "not_found.h" // expected-error {{'not_found.h' file not found}}
+
+template 
+struct foo {};
+
+template 
+struct foo(0)(static_cast(0)()))> {};
Index: clang/lib/Sema/SemaTemplateDeduction.cpp
===
--- clang/lib/Sema/SemaTemplateDeduction.cpp
+++ clang/lib/Sema/SemaTemplateDeduction.cpp
@@ -5466,6 +5466,9 @@
Deduced.end());
   Sema::InstantiatingTemplate Inst(S, Info.getLocation(), P2, DeducedArgs,
Info);
+  if (Inst.isInvalid())
+return false;
+
   auto *TST1 = T1->castAs();
   bool AtLeastAsSpecialized;
   S.runWithSufficientStackSpace(Info.getLocation(), [&] {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D79714: [Diagnostics] Restore -Wdeprecated warning when user-declared copy assignment operator is defined as deleted (PR45634)

2021-04-23 Thread Mikael Holmén via Phabricator via cfe-commits
uabelho added a comment.

Hi,

With this commit I get failures in the following testcases when building 
check-runtimes on trunk:

  Failed Tests (29):
libc++ :: libcxx/debug/containers/db_sequence_container_iterators.pass.cpp
libc++ :: libcxx/gdb/gdb_pretty_printer_test.sh.cpp
libc++ :: std/containers/sequences/vector.bool/assign_copy.pass.cpp
libc++ :: std/containers/sequences/vector.bool/assign_move.pass.cpp
libc++ :: std/containers/sequences/vector.bool/copy.pass.cpp
libc++ :: std/containers/sequences/vector.bool/copy_alloc.pass.cpp
libc++ :: std/containers/sequences/vector.bool/emplace.pass.cpp
libc++ :: std/containers/sequences/vector.bool/erase_iter.pass.cpp
libc++ :: std/containers/sequences/vector.bool/erase_iter_iter.pass.cpp
libc++ :: 
std/containers/sequences/vector.bool/insert_iter_initializer_list.pass.cpp
libc++ :: 
std/containers/sequences/vector.bool/insert_iter_iter_iter.pass.cpp
libc++ :: 
std/containers/sequences/vector.bool/insert_iter_size_value.pass.cpp
libc++ :: std/containers/sequences/vector.bool/insert_iter_value.pass.cpp
libc++ :: std/containers/sequences/vector.bool/iterators.pass.cpp
libc++ :: std/containers/sequences/vector.bool/move.pass.cpp
libc++ :: std/containers/sequences/vector.bool/move_alloc.pass.cpp
libc++ :: std/containers/sequences/vector.bool/resize_size.pass.cpp
libc++ :: std/containers/sequences/vector.bool/resize_size_value.pass.cpp
libc++ :: std/containers/sequences/vector.bool/shrink_to_fit.pass.cpp
libc++ :: std/containers/sequences/vector.bool/size.pass.cpp
libc++ :: std/containers/sequences/vector/vector.cons/deduct.pass.cpp
libc++ :: std/utilities/template.bitset/bitset.members/left_shift.pass.cpp
libc++ :: std/utilities/template.bitset/bitset.members/op_eq_eq.pass.cpp
libc++ :: std/utilities/template.bitset/bitset.members/right_shift.pass.cpp
libc++ :: std/utilities/template.bitset/bitset.members/to_ullong.pass.cpp
libc++ :: std/utilities/template.bitset/bitset.members/to_ulong.pass.cpp
libc++ :: std/utilities/template.bitset/bitset.operators/op_and.pass.cpp
libc++ :: std/utilities/template.bitset/bitset.operators/op_not.pass.cpp
libc++ :: std/utilities/template.bitset/bitset.operators/op_or.pass.cpp

They all get -Wdeprecated-copy warnigns and then with -Werror they fail.
Is this something you've seen or considered?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79714

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


[PATCH] D101087: [OpenCL] Introduce new method for validating OpenCL target

2021-04-23 Thread Anton Zabaznov via Phabricator via cfe-commits
azabaznov updated this revision to Diff 339983.
azabaznov added a comment.
Herald added a reviewer: aaron.ballman.

Addressed comments, did some more refactoring. Is it OK to have "2.0" 
diagnostics for C++ for OpenCL?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101087

Files:
  clang/include/clang/Basic/DiagnosticCommonKinds.td
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/include/clang/Basic/OpenCLOptions.h
  clang/include/clang/Basic/TargetInfo.h
  clang/lib/Basic/OpenCLOptions.cpp
  clang/lib/Basic/Targets.cpp
  clang/lib/Basic/Targets/X86.cpp
  clang/lib/Frontend/CompilerInstance.cpp
  clang/lib/Frontend/InitPreprocessor.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/Misc/nvptx.unsupported_core.cl
  clang/test/Misc/r600.unsupported_core.cl

Index: clang/test/Misc/r600.unsupported_core.cl
===
--- /dev/null
+++ clang/test/Misc/r600.unsupported_core.cl
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -cl-std=CL2.0 -triple r600-unknown-unknown -Wpedantic-core-features %s 2> %t
+// RUN: FileCheck < %t %s
+
+// CHECK: cl_khr_byte_addressable_store is a core feature in OpenCL C 2.0 but not supported on this target
+// CHECK: cl_khr_global_int32_base_atomics is a core feature in OpenCL C 2.0 but not supported on this target
+// CHECK: cl_khr_global_int32_extended_atomics is a core feature in OpenCL C 2.0 but not supported on this target
+// CHECK: cl_khr_local_int32_base_atomics is a core feature in OpenCL C 2.0 but not supported on this target
+// CHECK: cl_khr_local_int32_extended_atomics is a core feature in OpenCL C 2.0 but not supported on this target
+// CHECK: cl_khr_3d_image_writes is a core feature in OpenCL C 2.0 but not supported on this target
Index: clang/test/Misc/nvptx.unsupported_core.cl
===
--- /dev/null
+++ clang/test/Misc/nvptx.unsupported_core.cl
@@ -0,0 +1,4 @@
+// RUN: %clang_cc1 -cl-std=CL2.0 -triple nvptx-unknown-unknown -Wpedantic-core-features %s 2> %t
+// RUN: FileCheck < %t %s
+
+// CHECK: cl_khr_3d_image_writes is a core feature in OpenCL C 2.0 but not supported on this target
Index: clang/lib/Sema/SemaDeclAttr.cpp
===
--- clang/lib/Sema/SemaDeclAttr.cpp
+++ clang/lib/Sema/SemaDeclAttr.cpp
@@ -7278,12 +7278,13 @@
 }
 
 static void handleOpenCLNoSVMAttr(Sema &S, Decl *D, const ParsedAttr &AL) {
+  auto OCL20VersionString = clang::getOpenCLVersionStringFromCode(200);
   if (S.LangOpts.OpenCLVersion != 200)
 S.Diag(AL.getLoc(), diag::err_attribute_requires_opencl_version)
-<< AL << "2.0" << 0;
+<< AL << OCL20VersionString << 0;
   else
-S.Diag(AL.getLoc(), diag::warn_opencl_attr_deprecated_ignored) << AL
-   << "2.0";
+S.Diag(AL.getLoc(), diag::warn_opencl_attr_deprecated_ignored)
+<< AL << OCL20VersionString;
 }
 
 static void handleOpenCLAccessAttr(Sema &S, Decl *D, const ParsedAttr &AL) {
Index: clang/lib/Frontend/InitPreprocessor.cpp
===
--- clang/lib/Frontend/InitPreprocessor.cpp
+++ clang/lib/Frontend/InitPreprocessor.cpp
@@ -601,6 +601,29 @@
 Builder.defineMacro("__cpp_coroutines", "201703L");
 }
 
+/// InitializeOpenCLFeatureTestMacros - Define OpenCL macros based on target
+/// settings and language version
+void InitializeOpenCLFeatureTestMacros(const TargetInfo &TI,
+   const LangOptions &Opts,
+   MacroBuilder &Builder) {
+  const llvm::StringMap &OpenCLFeaturesMap = TI.getSupportedOpenCLOpts();
+  // FIXME: OpenCL options which affect language semantics/syntax
+  // should be moved into LangOptions.
+  auto defineOpenCLExtMacro = [&](llvm::StringRef Name, auto... OptArgs) {
+// Check if extension is supported by target and is available in this
+// OpenCL version
+if (TI.hasFeatureEnabled(OpenCLFeaturesMap, Name) &&
+OpenCLOptions::isOpenCLOptionAvailableIn(Opts, OptArgs...))
+  Builder.defineMacro(Name);
+  };
+#define OPENCL_GENERIC_EXTENSION(Ext, ...) \
+  defineOpenCLExtMacro(#Ext, __VA_ARGS__);
+#include "clang/Basic/OpenCLExtensions.def"
+
+  // Assume compiling for FULL profile
+  Builder.defineMacro("__opencl_c_int64");
+}
+
 static void InitializePredefinedMacros(const TargetInfo &TI,
const LangOptions &LangOpts,
const FrontendOptions &FEOpts,
@@ -1138,7 +1161,7 @@
 
   // OpenCL definitions.
   if (LangOpts.OpenCL) {
-TI.getOpenCLFeatureDefines(LangOpts, Builder);
+InitializeOpenCLFeatureTestMacros(TI, LangOpts, Builder);
 
 if (TI.getTriple().isSPI

[clang] 2cae702 - Reland "[Clang] Propagate guaranteed alignment for malloc and others"

2021-04-23 Thread Dávid Bolvanský via cfe-commits

Author: Dávid Bolvanský
Date: 2021-04-23T14:05:57+02:00
New Revision: 2cae7025c1d9e83d971f670c9a66497a8c1094ec

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

LOG: Reland "[Clang] Propagate guaranteed alignment for malloc and others"

This relands commit 6914a0ed2b30924b188968e59a83efa07ac5fe57. Crash in 
InstCombine was fixed.

Added: 
clang/test/CodeGen/alloc-fns-alignment.c

Modified: 
clang/include/clang/Basic/TargetInfo.h
clang/lib/CodeGen/CGCall.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/TargetInfo.h 
b/clang/include/clang/Basic/TargetInfo.h
index 3bcaaceb63d8e..449c026639b90 100644
--- a/clang/include/clang/Basic/TargetInfo.h
+++ b/clang/include/clang/Basic/TargetInfo.h
@@ -612,8 +612,8 @@ class TargetInfo : public virtual TransferrableTargetInfo,
   }
 
   /// Return the largest alignment for which a suitably-sized allocation with
-  /// '::operator new(size_t)' is guaranteed to produce a correctly-aligned
-  /// pointer.
+  /// '::operator new(size_t)' or 'malloc' is guaranteed to produce a
+  /// correctly-aligned pointer.
   unsigned getNewAlign() const {
 return NewAlign ? NewAlign : std::max(LongDoubleAlign, LongLongAlign);
   }

diff  --git a/clang/lib/CodeGen/CGCall.cpp b/clang/lib/CodeGen/CGCall.cpp
index 366c83eeb8e89..6c77f1889fb52 100644
--- a/clang/lib/CodeGen/CGCall.cpp
+++ b/clang/lib/CodeGen/CGCall.cpp
@@ -2048,6 +2048,24 @@ void CodeGenModule::ConstructAttributeList(
   // allows it to work on indirect virtual function calls.
   if (AttrOnCallSite && TargetDecl->hasAttr())
 FuncAttrs.addAttribute(llvm::Attribute::NoMerge);
+
+  // Add known guaranteed alignment for allocation functions.
+  if (unsigned BuiltinID = Fn->getBuiltinID()) {
+switch (BuiltinID) {
+case Builtin::BIaligned_alloc:
+case Builtin::BIcalloc:
+case Builtin::BImalloc:
+case Builtin::BImemalign:
+case Builtin::BIrealloc:
+case Builtin::BIstrdup:
+case Builtin::BIstrndup:
+  RetAttrs.addAlignmentAttr(Context.getTargetInfo().getNewAlign() /
+Context.getTargetInfo().getCharWidth());
+  break;
+default:
+  break;
+}
+  }
 }
 
 // 'const', 'pure' and 'noalias' attributed functions are also nounwind.

diff  --git a/clang/test/CodeGen/alloc-fns-alignment.c 
b/clang/test/CodeGen/alloc-fns-alignment.c
new file mode 100644
index 0..d2f9b467196a7
--- /dev/null
+++ b/clang/test/CodeGen/alloc-fns-alignment.c
@@ -0,0 +1,35 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm < %s | 
FileCheck %s --check-prefix=ALIGN16
+// RUN: %clang_cc1 -triple x86_64-windows-msvc  -emit-llvm < %s | 
FileCheck %s --check-prefix=ALIGN16
+// RUN: %clang_cc1 -triple i386-apple-darwin-emit-llvm < %s | 
FileCheck %s --check-prefix=ALIGN16
+// RUN: %clang_cc1 -triple i386-unknown-linux-gnu   -emit-llvm < %s | 
FileCheck %s --check-prefix=ALIGN8
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fno-builtin-malloc  
-emit-llvm < %s  | FileCheck %s --check-prefix=NOBUILTIN-MALLOC
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fno-builtin-calloc  
-emit-llvm < %s  | FileCheck %s --check-prefix=NOBUILTIN-CALLOC
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fno-builtin-realloc 
-emit-llvm < %s  | FileCheck %s --check-prefix=NOBUILTIN-REALLOC
+
+typedef __SIZE_TYPE__ size_t;
+
+void *malloc(size_t);
+void *calloc(size_t, size_t);
+void *realloc(void *, size_t);
+
+void *malloc_test(size_t n) {
+  return malloc(n);
+}
+
+void *calloc_test(size_t n) {
+  return calloc(1, n);
+}
+
+void *raalloc_test(void *p, size_t n) {
+  return realloc(p, n);
+}
+
+// ALIGN16: align 16 i8* @malloc
+// ALIGN16: align 16 i8* @calloc
+// ALIGN16: align 16 i8* @realloc
+// ALIGN8: align 8 i8* @malloc
+// ALIGN8: align 8 i8* @calloc
+// ALIGN8: align 8 i8* @realloc
+// NOBUILTIN-MALLOC: declare i8* @malloc
+// NOBUILTIN-CALLOC: declare i8* @calloc
+// NOBUILTIN-REALLOC: declare i8* @realloc



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


[PATCH] D100821: [RISCV] Implement the vmmv.m/vmnot.m builtin.

2021-04-23 Thread Hsiangkai Wang via Phabricator via cfe-commits
HsiangKai added a comment.

In D100821#2711395 , @rogfer01 wrote:

> In D100821#2710998 , @HsiangKai 
> wrote:
>
>> Rebase.
>
> Thanks, I had missed that and my comment above was wrong.

That's fine. Thanks for your review.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100821

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


[PATCH] D79714: [Diagnostics] Restore -Wdeprecated warning when user-declared copy assignment operator is defined as deleted (PR45634)

2021-04-23 Thread Dávid Bolvanský via Phabricator via cfe-commits
xbolva00 added a comment.

In D79714#2711871 , @uabelho wrote:

> Hi,
>
> With this commit I get failures in the following testcases when building 
> check-runtimes on trunk:
>
>   Failed Tests (29):
> libc++ :: libcxx/debug/containers/db_sequence_container_iterators.pass.cpp
> libc++ :: libcxx/gdb/gdb_pretty_printer_test.sh.cpp
> libc++ :: std/containers/sequences/vector.bool/assign_copy.pass.cpp
> libc++ :: std/containers/sequences/vector.bool/assign_move.pass.cpp
> libc++ :: std/containers/sequences/vector.bool/copy.pass.cpp
> libc++ :: std/containers/sequences/vector.bool/copy_alloc.pass.cpp
> libc++ :: std/containers/sequences/vector.bool/emplace.pass.cpp
> libc++ :: std/containers/sequences/vector.bool/erase_iter.pass.cpp
> libc++ :: std/containers/sequences/vector.bool/erase_iter_iter.pass.cpp
> libc++ :: 
> std/containers/sequences/vector.bool/insert_iter_initializer_list.pass.cpp
> libc++ :: 
> std/containers/sequences/vector.bool/insert_iter_iter_iter.pass.cpp
> libc++ :: 
> std/containers/sequences/vector.bool/insert_iter_size_value.pass.cpp
> libc++ :: std/containers/sequences/vector.bool/insert_iter_value.pass.cpp
> libc++ :: std/containers/sequences/vector.bool/iterators.pass.cpp
> libc++ :: std/containers/sequences/vector.bool/move.pass.cpp
> libc++ :: std/containers/sequences/vector.bool/move_alloc.pass.cpp
> libc++ :: std/containers/sequences/vector.bool/resize_size.pass.cpp
> libc++ :: std/containers/sequences/vector.bool/resize_size_value.pass.cpp
> libc++ :: std/containers/sequences/vector.bool/shrink_to_fit.pass.cpp
> libc++ :: std/containers/sequences/vector.bool/size.pass.cpp
> libc++ :: std/containers/sequences/vector/vector.cons/deduct.pass.cpp
> libc++ :: std/utilities/template.bitset/bitset.members/left_shift.pass.cpp
> libc++ :: std/utilities/template.bitset/bitset.members/op_eq_eq.pass.cpp
> libc++ :: 
> std/utilities/template.bitset/bitset.members/right_shift.pass.cpp
> libc++ :: std/utilities/template.bitset/bitset.members/to_ullong.pass.cpp
> libc++ :: std/utilities/template.bitset/bitset.members/to_ulong.pass.cpp
> libc++ :: std/utilities/template.bitset/bitset.operators/op_and.pass.cpp
> libc++ :: std/utilities/template.bitset/bitset.operators/op_not.pass.cpp
> libc++ :: std/utilities/template.bitset/bitset.operators/op_or.pass.cpp
>
> They all get -Wdeprecated-copy warnigns and then with -Werror they fail.
> Is this something you've seen or considered?

Can you try this fix?

  diff --git a/libcxx/utils/libcxx/test/params.py 
b/libcxx/utils/libcxx/test/params.py
  index ddf277dea246..abf712e78a61 100644
  --- a/libcxx/utils/libcxx/test/params.py
  +++ b/libcxx/utils/libcxx/test/params.py
  @@ -12,6 +12,7 @@ from libcxx.test.features import _isMSVC
   _warningFlags = [
 '-Werror',
 '-Wall',
  +  '-Wno-deprecated-copy',
 '-Wextra',
 '-Wshadow',
 '-Wundef',


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79714

___
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

2021-04-23 Thread Andrew Savonichev via Phabricator via cfe-commits
asavonic created this revision.
asavonic requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This fixes PR49198: Wrong usage of __dso_handle in user code leads to a compiler
crash.

`__dso_handle` variable is now created with a prefix to avoid a conflict with
the user-defined one which can be emitted later. Once all globals are emitted,
it is renamed back or replaced with a user-defined `__dso_handle`.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D101156

Files:
  clang/lib/CodeGen/ItaniumCXXABI.cpp
  clang/test/CodeGenCXX/dso-handle-custom.cpp


Index: clang/test/CodeGenCXX/dso-handle-custom.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/dso-handle-custom.cpp
@@ -0,0 +1,17 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -fexceptions %s 
-o - | FileCheck %s
+
+class A {
+public:
+  ~A();
+} a;
+
+// CHECK: @__dso_handle = hidden global i8* bitcast (i8** @__dso_handle to 
i8*), align 8
+// CHECK: define internal void @__cxx_global_var_init()
+// CHECK:   call i32 @__cxa_atexit({{.*}}, {{.*}}, i8* bitcast (i8** 
@__dso_handle to i8*))
+
+void *__dso_handle = &__dso_handle;
+
+void use(void *);
+void use_dso_handle() {
+  use(__dso_handle);
+}
Index: clang/lib/CodeGen/ItaniumCXXABI.cpp
===
--- clang/lib/CodeGen/ItaniumCXXABI.cpp
+++ clang/lib/CodeGen/ItaniumCXXABI.cpp
@@ -2531,7 +2531,7 @@
 
   // Create a variable that binds the atexit to this shared object.
   llvm::Constant *handle =
-  CGF.CGM.CreateRuntimeVariable(CGF.Int8Ty, "__dso_handle");
+  CGF.CGM.CreateRuntimeVariable(CGF.Int8Ty, "$__dso_handle");
   auto *GV = cast(handle->stripPointerCasts());
   GV->setVisibility(llvm::GlobalValue::HiddenVisibility);
 
@@ -2685,6 +2685,26 @@
 
   if (getCXXABI().useSinitAndSterm())
 unregisterGlobalDtorsWithUnAtExit();
+
+  // Prefer user-defined __dso_handle over the compiler generated one
+  if (llvm::GlobalValue *GeneratedDSOHandle = GetGlobalValue("$__dso_handle")) 
{
+llvm::GlobalValue *CustomDSOHandle = GetGlobalValue("__dso_handle");
+if (!CustomDSOHandle) {
+  GeneratedDSOHandle->setName("__dso_handle");
+} else {
+  if (!isa(CustomDSOHandle))
+llvm_unreachable("__dso_handle must be a global variable");
+
+  setDSOLocal(CustomDSOHandle);
+  CustomDSOHandle->setLinkage(llvm::GlobalValue::ExternalLinkage);
+  CustomDSOHandle->setVisibility(llvm::GlobalValue::HiddenVisibility);
+
+  llvm::Constant *DSOHandle = llvm::ConstantExpr::getBitCast(
+  CustomDSOHandle, GeneratedDSOHandle->getType());
+  GeneratedDSOHandle->replaceAllUsesWith(DSOHandle);
+  GeneratedDSOHandle->eraseFromParent();
+}
+  }
 }
 
 /// Register a global destructor as best as we know how.


Index: clang/test/CodeGenCXX/dso-handle-custom.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/dso-handle-custom.cpp
@@ -0,0 +1,17 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -fexceptions %s -o - | FileCheck %s
+
+class A {
+public:
+  ~A();
+} a;
+
+// CHECK: @__dso_handle = hidden global i8* bitcast (i8** @__dso_handle to i8*), align 8
+// CHECK: define internal void @__cxx_global_var_init()
+// CHECK:   call i32 @__cxa_atexit({{.*}}, {{.*}}, i8* bitcast (i8** @__dso_handle to i8*))
+
+void *__dso_handle = &__dso_handle;
+
+void use(void *);
+void use_dso_handle() {
+  use(__dso_handle);
+}
Index: clang/lib/CodeGen/ItaniumCXXABI.cpp
===
--- clang/lib/CodeGen/ItaniumCXXABI.cpp
+++ clang/lib/CodeGen/ItaniumCXXABI.cpp
@@ -2531,7 +2531,7 @@
 
   // Create a variable that binds the atexit to this shared object.
   llvm::Constant *handle =
-  CGF.CGM.CreateRuntimeVariable(CGF.Int8Ty, "__dso_handle");
+  CGF.CGM.CreateRuntimeVariable(CGF.Int8Ty, "$__dso_handle");
   auto *GV = cast(handle->stripPointerCasts());
   GV->setVisibility(llvm::GlobalValue::HiddenVisibility);
 
@@ -2685,6 +2685,26 @@
 
   if (getCXXABI().useSinitAndSterm())
 unregisterGlobalDtorsWithUnAtExit();
+
+  // Prefer user-defined __dso_handle over the compiler generated one
+  if (llvm::GlobalValue *GeneratedDSOHandle = GetGlobalValue("$__dso_handle")) {
+llvm::GlobalValue *CustomDSOHandle = GetGlobalValue("__dso_handle");
+if (!CustomDSOHandle) {
+  GeneratedDSOHandle->setName("__dso_handle");
+} else {
+  if (!isa(CustomDSOHandle))
+llvm_unreachable("__dso_handle must be a global variable");
+
+  setDSOLocal(CustomDSOHandle);
+  CustomDSOHandle->setLinkage(llvm::GlobalValue::ExternalLinkage);
+  CustomDSOHandle->setVisibility(llvm::GlobalValue::HiddenVisibility);
+
+  llvm::Constant *DSOHandle = llvm::ConstantExpr::getBitCast(
+  CustomDSOHandle, GeneratedDSOHandle->getType());
+  

[PATCH] D101033: [clang-format] fix indent in alignChainedConditionals

2021-04-23 Thread Sam McCall via Phabricator via cfe-commits
sammccall accepted this revision.
sammccall added a comment.
This revision is now accepted and ready to land.

Can't say I really understand this (either the before/after state).

It seems like we're trying to vertically-align a bunch of operands to a ?: 
chain, and this patch stops aligning the ones that follow a ? in certain cases. 
But I don't understand why this is correct, and what the point is of aligning 
(only) the ones following `:`.

Is there an intuitive explanation?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101033

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


[PATCH] D101057: [clangd] Allow AST request without range

2021-04-23 Thread Christian Kandeler via Phabricator via cfe-commits
ckandeler updated this revision to Diff 339994.
ckandeler added a comment.

Fixed TU traversal


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101057

Files:
  clang-tools-extra/clangd/ClangdServer.cpp
  clang-tools-extra/clangd/ClangdServer.h
  clang-tools-extra/clangd/DumpAST.cpp
  clang-tools-extra/clangd/Protocol.h
  clang-tools-extra/clangd/test/ast-no-range.test
  clang-tools-extra/clangd/unittests/DumpASTTests.cpp

Index: clang-tools-extra/clangd/unittests/DumpASTTests.cpp
===
--- clang-tools-extra/clangd/unittests/DumpASTTests.cpp
+++ clang-tools-extra/clangd/unittests/DumpASTTests.cpp
@@ -16,8 +16,12 @@
 namespace clang {
 namespace clangd {
 namespace {
+using testing::Contains;
+using testing::Not;
 using testing::SizeIs;
 
+MATCHER_P(WithDetail, str, "") { return arg.detail == str; }
+
 TEST(DumpASTTests, BasicInfo) {
   std::pair Cases[] = {
   {R"cpp(
@@ -157,6 +161,20 @@
   EXPECT_EQ(Node.children.front().range, Case.range("type"));
 }
 
+TEST(DumpASTTests, NoRange) {
+  auto TU = TestTU::withHeaderCode("void funcFromHeader();");
+  TU.Code = "int varFromSource;";
+  ParsedAST AST = TU.build();
+  auto Node = dumpAST(
+  DynTypedNode::create(*AST.getASTContext().getTranslationUnitDecl()),
+  AST.getTokens(), AST.getASTContext());
+  ASSERT_THAT(Node.children, Contains(WithDetail("varFromSource")));
+  ASSERT_THAT(Node.children, Not(Contains(WithDetail("funcFromHeader";
+  EXPECT_THAT(Node.arcana, testing::StartsWith("TranslationUnitDecl "));
+  ASSERT_FALSE(Node.range.hasValue())
+  << "Expected no range for translation unit";
+}
+
 TEST(DumpASTTests, Arcana) {
   ParsedAST AST = TestTU::withCode("int x;").build();
   auto Node = dumpAST(DynTypedNode::create(findDecl(AST, "x")), AST.getTokens(),
Index: clang-tools-extra/clangd/test/ast-no-range.test
===
--- /dev/null
+++ clang-tools-extra/clangd/test/ast-no-range.test
@@ -0,0 +1,53 @@
+# RUN: clangd -lit-test < %s | FileCheck %s
+{"jsonrpc":"2.0","id":0,"method":"initialize","params":{"processId":123,"rootPath":"clangd","capabilities":{},"trace":"off"}}
+---
+{"jsonrpc":"2.0","method":"textDocument/didOpen","params":{"textDocument":{"uri":"test:///simple.cpp","languageId":"cpp","version":1,"text":"int x;"}}}
+---
+{"jsonrpc":"2.0","id":1,"method":"textDocument/ast","params":{"textDocument":{"uri":"test:///simple.cpp"}}}
+#  CHECK:  "id": 1,
+# CHECK-NEXT:  "jsonrpc": "2.0",
+# CHECK-NEXT:  "result": {
+# CHECK-NEXT:"arcana": "{{TranslationUnitDecl.*}}"
+# CHECK-NEXT:"children": [
+# CHECK-NEXT:  {
+#  CHECK:"arcana": "VarDecl {{.*}} x 'int'",
+# CHECK-NEXT:"children": [
+# CHECK-NEXT:  {
+# CHECK-NEXT:"arcana": "QualType {{.*}} 'int' ",
+# CHECK-NEXT:"detail": "int",
+# CHECK-NEXT:"kind": "Builtin",
+# CHECK-NEXT:"range": {
+# CHECK-NEXT:  "end": {
+# CHECK-NEXT:"character": 3,
+# CHECK-NEXT:"line": 0
+# CHECK-NEXT:  },
+# CHECK-NEXT:  "start": {
+# CHECK-NEXT:"character": 0,
+# CHECK-NEXT:"line": 0
+# CHECK-NEXT:  }
+# CHECK-NEXT:},
+# CHECK-NEXT:"role": "type"
+# CHECK-NEXT:  }
+# CHECK-NEXT:],
+# CHECK-NEXT:"detail": "x",
+# CHECK-NEXT:"kind": "Var",
+# CHECK-NEXT:"range": {
+# CHECK-NEXT:  "end": {
+# CHECK-NEXT:"character": 5,
+# CHECK-NEXT:"line": 0
+# CHECK-NEXT:  },
+# CHECK-NEXT:  "start": {
+# CHECK-NEXT:"character": 0,
+# CHECK-NEXT:"line": 0
+# CHECK-NEXT:  }
+# CHECK-NEXT:},
+# CHECK-NEXT:"role": "declaration"
+# CHECK-NEXT:  }
+# CHECK-NEXT:],
+# CHECK-NEXT:"kind": "TranslationUnit",
+# CHECK-NEXT:"role": "declaration"
+# CHECK-NEXT:  }
+---
+{"jsonrpc":"2.0","id":2,"method":"shutdown"}
+---
+{"jsonrpc":"2.0","method":"exit"}
Index: clang-tools-extra/clangd/Protocol.h
===
--- clang-tools-extra/clangd/Protocol.h
+++ clang-tools-extra/clangd/Protocol.h
@@ -1725,7 +1725,9 @@
 
   /// The position of the node to be dumped.
   /// The highest-level node that entirely contains the range will be returned.
-  Range range;
+  /// If no range is given, the top-level translation unit node will be
+  /// returned.
+  llvm::Optional range;
 };
 bool fromJSON(const llvm::json::Value &, ASTParams &, llvm::json::Path);
 
Index: clang-tools-extra/clangd/DumpAST.cpp
===
--- clang-tools-extra/clangd/DumpAST.cpp
+++ clang-tools-extra/clangd/DumpAST.cpp
@@ -335,6 +335,11 @@
 
   // Override traversal to record the nodes 

[PATCH] D101057: [clangd] Allow AST request without range

2021-04-23 Thread Christian Kandeler via Phabricator via cfe-commits
ckandeler updated this revision to Diff 339995.
ckandeler marked 2 inline comments as done.
ckandeler added a comment.

"top-level" -> "root"


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101057

Files:
  clang-tools-extra/clangd/ClangdServer.cpp
  clang-tools-extra/clangd/ClangdServer.h
  clang-tools-extra/clangd/DumpAST.cpp
  clang-tools-extra/clangd/Protocol.h
  clang-tools-extra/clangd/test/ast-no-range.test
  clang-tools-extra/clangd/unittests/DumpASTTests.cpp

Index: clang-tools-extra/clangd/unittests/DumpASTTests.cpp
===
--- clang-tools-extra/clangd/unittests/DumpASTTests.cpp
+++ clang-tools-extra/clangd/unittests/DumpASTTests.cpp
@@ -16,8 +16,12 @@
 namespace clang {
 namespace clangd {
 namespace {
+using testing::Contains;
+using testing::Not;
 using testing::SizeIs;
 
+MATCHER_P(WithDetail, str, "") { return arg.detail == str; }
+
 TEST(DumpASTTests, BasicInfo) {
   std::pair Cases[] = {
   {R"cpp(
@@ -157,6 +161,20 @@
   EXPECT_EQ(Node.children.front().range, Case.range("type"));
 }
 
+TEST(DumpASTTests, NoRange) {
+  auto TU = TestTU::withHeaderCode("void funcFromHeader();");
+  TU.Code = "int varFromSource;";
+  ParsedAST AST = TU.build();
+  auto Node = dumpAST(
+  DynTypedNode::create(*AST.getASTContext().getTranslationUnitDecl()),
+  AST.getTokens(), AST.getASTContext());
+  ASSERT_THAT(Node.children, Contains(WithDetail("varFromSource")));
+  ASSERT_THAT(Node.children, Not(Contains(WithDetail("funcFromHeader";
+  EXPECT_THAT(Node.arcana, testing::StartsWith("TranslationUnitDecl "));
+  ASSERT_FALSE(Node.range.hasValue())
+  << "Expected no range for translation unit";
+}
+
 TEST(DumpASTTests, Arcana) {
   ParsedAST AST = TestTU::withCode("int x;").build();
   auto Node = dumpAST(DynTypedNode::create(findDecl(AST, "x")), AST.getTokens(),
Index: clang-tools-extra/clangd/test/ast-no-range.test
===
--- /dev/null
+++ clang-tools-extra/clangd/test/ast-no-range.test
@@ -0,0 +1,53 @@
+# RUN: clangd -lit-test < %s | FileCheck %s
+{"jsonrpc":"2.0","id":0,"method":"initialize","params":{"processId":123,"rootPath":"clangd","capabilities":{},"trace":"off"}}
+---
+{"jsonrpc":"2.0","method":"textDocument/didOpen","params":{"textDocument":{"uri":"test:///simple.cpp","languageId":"cpp","version":1,"text":"int x;"}}}
+---
+{"jsonrpc":"2.0","id":1,"method":"textDocument/ast","params":{"textDocument":{"uri":"test:///simple.cpp"}}}
+#  CHECK:  "id": 1,
+# CHECK-NEXT:  "jsonrpc": "2.0",
+# CHECK-NEXT:  "result": {
+# CHECK-NEXT:"arcana": "{{TranslationUnitDecl.*}}"
+# CHECK-NEXT:"children": [
+# CHECK-NEXT:  {
+#  CHECK:"arcana": "VarDecl {{.*}} x 'int'",
+# CHECK-NEXT:"children": [
+# CHECK-NEXT:  {
+# CHECK-NEXT:"arcana": "QualType {{.*}} 'int' ",
+# CHECK-NEXT:"detail": "int",
+# CHECK-NEXT:"kind": "Builtin",
+# CHECK-NEXT:"range": {
+# CHECK-NEXT:  "end": {
+# CHECK-NEXT:"character": 3,
+# CHECK-NEXT:"line": 0
+# CHECK-NEXT:  },
+# CHECK-NEXT:  "start": {
+# CHECK-NEXT:"character": 0,
+# CHECK-NEXT:"line": 0
+# CHECK-NEXT:  }
+# CHECK-NEXT:},
+# CHECK-NEXT:"role": "type"
+# CHECK-NEXT:  }
+# CHECK-NEXT:],
+# CHECK-NEXT:"detail": "x",
+# CHECK-NEXT:"kind": "Var",
+# CHECK-NEXT:"range": {
+# CHECK-NEXT:  "end": {
+# CHECK-NEXT:"character": 5,
+# CHECK-NEXT:"line": 0
+# CHECK-NEXT:  },
+# CHECK-NEXT:  "start": {
+# CHECK-NEXT:"character": 0,
+# CHECK-NEXT:"line": 0
+# CHECK-NEXT:  }
+# CHECK-NEXT:},
+# CHECK-NEXT:"role": "declaration"
+# CHECK-NEXT:  }
+# CHECK-NEXT:],
+# CHECK-NEXT:"kind": "TranslationUnit",
+# CHECK-NEXT:"role": "declaration"
+# CHECK-NEXT:  }
+---
+{"jsonrpc":"2.0","id":2,"method":"shutdown"}
+---
+{"jsonrpc":"2.0","method":"exit"}
Index: clang-tools-extra/clangd/Protocol.h
===
--- clang-tools-extra/clangd/Protocol.h
+++ clang-tools-extra/clangd/Protocol.h
@@ -1725,7 +1725,8 @@
 
   /// The position of the node to be dumped.
   /// The highest-level node that entirely contains the range will be returned.
-  Range range;
+  /// If no range is given, the root translation unit node will be returned.
+  llvm::Optional range;
 };
 bool fromJSON(const llvm::json::Value &, ASTParams &, llvm::json::Path);
 
Index: clang-tools-extra/clangd/DumpAST.cpp
===
--- clang-tools-extra/clangd/DumpAST.cpp
+++ clang-tools-extra/clangd/DumpAST.cpp
@@ -335,6 +335,11 @@
 
   // Over

[PATCH] D101122: introduce flag -fsanitize-address-detect-stack-use-after-return-mode. No functional change.

2021-04-23 Thread Joerg Sonnenberger via Phabricator via cfe-commits
joerg added a comment.

There are two approaches that work for reviewing: starting from clang and going 
down or starting from compiler-rt and going up the layers. I'd prefer to do the 
latter as it means meaningful testing can be done easier. There are two natural 
steps here: clang flag+IR generation is one, llvm codegen and compiler-rt is 
the other. The clang step should include tests that ensure that proper IR is 
generated for the different flag combination (including documentation for the 
IR changes). The LLVM step should ensure that the different attributes (either 
function or module scope) are correctly lowered in the instrumentation pass and 
unit tests on the compiler-rt side to do functional testing. The unit testing 
might also be done as a third step if it goes the full way from C to binary 
code.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101122

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


[PATCH] D100980: [OpenCL] Allow use of double type without extension pragma

2021-04-23 Thread Anton Zabaznov via Phabricator via cfe-commits
azabaznov added a comment.

> For cl_khr_fp64 I still want to keep the pragma for the other use case - to 
> convert double literal into single-precision 
> (https://github.com/KhronosGroup/OpenCL-Docs/issues/578). The reason why I 
> think it could be useful is that the precision change might lead to a 
> different result depending on the precision of the calculation. So I think 
> pragmas could be useful to control whether double literal is single-precision 
> or not to avoid this problem occur when code is compiled for different 
> targets?

Yeah, then we should  use 
`S.getOpenCLOptions().isAvailableOption("cl_khr_fp64", S.getLangOpts())` to 
check for enabled pragma. And do I understand correctly that the pragma is not 
needed in OpenCL C 1.2+ since extension became core?


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

https://reviews.llvm.org/D100980

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


[PATCH] D101057: [clangd] Allow AST request without range

2021-04-23 Thread Sam McCall via Phabricator via cfe-commits
sammccall accepted this revision.
sammccall added a comment.
This revision is now accepted and ready to land.

Fantastic, thank you! Just a couple of nits.

Want me to land this for you?




Comment at: clang-tools-extra/clangd/DumpAST.cpp:339
+
+  bool TraverseTUDecl(TranslationUnitDecl *TU) {
+return traverseNode("declaration", TU, [&] {

The naming causes a bit of confusion over whether this is a (CRTP) override of 
a RecursiveASTVisitor method. (It's not, as that method is called 
TraverseTranslationUnitDecl).

I'd suggest either:
 - (trivial) rename to traverseTUDecl, and move this away from the comment 
above that says this is overriding traversal
 - (maybe more elegant) instead of this function change the lambda inside 
TraverseDecl to be `if (is TUDecl) TraverseAST() else Base::TraverseDecl(D)`. 
Then I don't think the special case in `dumpAST()` is needed at all.



Comment at: clang-tools-extra/clangd/DumpAST.cpp:405
 
+// Note: It's safe for N to be a TranslationUnitDecl, as this function
+//   does not deserialize the preamble.

this comment should rather go in the .h file


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101057

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


[PATCH] D101060: [Analyzer][StdLibraryFunctionsChecker] Describe arg constraints

2021-04-23 Thread Gabor Marton via Phabricator via cfe-commits
martong marked an inline comment as done.
martong added inline comments.



Comment at: 
clang/test/Analysis/std-c-library-functions-arg-constraints-notes.cpp:32
+__buf_size_arg_constraint_concrete(buf); // \
+// expected-note{{The size of the 0th arg should be equal to or less than 
the value of 10}} \
+// expected-warning{{}}

vsavchenko wrote:
> martong wrote:
> > vsavchenko wrote:
> > > Oof, I do understand that we are devs and enumerate things starting from 
> > > 0. But this is supposed to be human-readable and humans start counting 
> > > from 1.
> > I've been thinking a lot about this and I see your point. On the other 
> > hand, we report warnings to other developers/programmers who are all used 
> > to start the indexing from 0, they may find it odd to start from 1. 
> > 
> > Alas, the string `0th` makes it obvious that we are talking about the first 
> > argument, however the string `1st` is ambiguous, even if we start the 
> > indexing from 0 or from 1. In this sense, starting from 0 makes less 
> > confusion.
> I know that we are talking to developers, but no developers say that this is 
> a 0th argument. And IMO the vast majority of developers would think of the 
> argument at index 0 when they read '1st' because most of people are not 
> compiler engineers and don't think of the list of arguments as an array. 
> But that is all opinions after all. What is most important is that clang 
> already reports a ton of warnings pointing to a specific argument/parameter 
> by its ordinal number.  Simply grep `DiagnosticsSemaKinds.td` for `ordinal` 
> and see the examples in tests. As you can guess, they all use ordinals 
> starting from **1st**.
Fair enough. It would be inconsistent to start from 0 if the Sema warnings 
already start from 1. I've changed it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101060

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


[PATCH] D101060: [Analyzer][StdLibraryFunctionsChecker] Describe arg constraints

2021-04-23 Thread Gabor Marton via Phabricator via cfe-commits
martong updated this revision to Diff 33.
martong marked an inline comment as done.
martong added a comment.

- Start arg index display from 1.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101060

Files:
  clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
  clang/test/Analysis/std-c-library-functions-arg-constraints-notes.cpp
  clang/test/Analysis/std-c-library-functions-arg-constraints.c
  clang/test/Analysis/std-c-library-functions-arg-constraints.cpp

Index: clang/test/Analysis/std-c-library-functions-arg-constraints.cpp
===
--- clang/test/Analysis/std-c-library-functions-arg-constraints.cpp
+++ clang/test/Analysis/std-c-library-functions-arg-constraints.cpp
@@ -14,5 +14,6 @@
 
 void test_arg_constraint_on_fun_with_default_param() {
   __defaultparam(nullptr); // \
-  // expected-warning{{Function argument constraint is not satisfied}}
+  // expected-warning{{Function argument constraint is not satisfied}} \
+  // expected-note{{}}
 }
Index: clang/test/Analysis/std-c-library-functions-arg-constraints.c
===
--- clang/test/Analysis/std-c-library-functions-arg-constraints.c
+++ clang/test/Analysis/std-c-library-functions-arg-constraints.c
@@ -30,7 +30,9 @@
 void test_alnum_concrete(int v) {
   int ret = isalnum(256); // \
   // report-warning{{Function argument constraint is not satisfied}} \
+  // report-note{{}} \
   // bugpath-warning{{Function argument constraint is not satisfied}} \
+  // bugpath-note{{}} \
   // bugpath-note{{Function argument constraint is not satisfied}}
   (void)ret;
 }
@@ -54,7 +56,9 @@
 
 int ret = isalnum(x); // \
 // report-warning{{Function argument constraint is not satisfied}} \
+// report-note{{}} \
 // bugpath-warning{{Function argument constraint is not satisfied}} \
+// bugpath-note{{}} \
 // bugpath-note{{Function argument constraint is not satisfied}}
 
 (void)ret;
@@ -66,7 +70,9 @@
 void test_toupper_concrete(int v) {
   int ret = toupper(256); // \
   // report-warning{{Function argument constraint is not satisfied}} \
+  // report-note{{}} \
   // bugpath-warning{{Function argument constraint is not satisfied}} \
+  // bugpath-note{{}} \
   // bugpath-note{{Function argument constraint is not satisfied}}
   (void)ret;
 }
@@ -90,7 +96,9 @@
 
 int ret = toupper(x); // \
 // report-warning{{Function argument constraint is not satisfied}} \
+// report-note{{}} \
 // bugpath-warning{{Function argument constraint is not satisfied}} \
+// bugpath-note{{}} \
 // bugpath-note{{Function argument constraint is not satisfied}}
 
 (void)ret;
@@ -102,7 +110,9 @@
 void test_tolower_concrete(int v) {
   int ret = tolower(256); // \
   // report-warning{{Function argument constraint is not satisfied}} \
+  // report-note{{}} \
   // bugpath-warning{{Function argument constraint is not satisfied}} \
+  // bugpath-note{{}} \
   // bugpath-note{{Function argument constraint is not satisfied}}
   (void)ret;
 }
@@ -126,7 +136,9 @@
 
 int ret = tolower(x); // \
 // report-warning{{Function argument constraint is not satisfied}} \
+// report-note{{}} \
 // bugpath-warning{{Function argument constraint is not satisfied}} \
+// bugpath-note{{}} \
 // bugpath-note{{Function argument constraint is not satisfied}}
 
 (void)ret;
@@ -138,7 +150,9 @@
 void test_toascii_concrete(int v) {
   int ret = toascii(256); // \
   // report-warning{{Function argument constraint is not satisfied}} \
+  // report-note{{}} \
   // bugpath-warning{{Function argument constraint is not satisfied}} \
+  // bugpath-note{{}} \
   // bugpath-note{{Function argument constraint is not satisfied}}
   (void)ret;
 }
@@ -162,7 +176,9 @@
 
 int ret = toascii(x); // \
 // report-warning{{Function argument constraint is not satisfied}} \
+// report-note{{}} \
 // bugpath-warning{{Function argument constraint is not satisfied}} \
+// bugpath-note{{}} \
 // bugpath-note{{Function argument constraint is not satisfied}}
 
 (void)ret;
@@ -175,7 +191,9 @@
 void test_notnull_concrete(FILE *fp) {
   fread(0, sizeof(int), 10, fp); // \
   // report-warning{{Function argument constraint is not satisfied}} \
+  // report-note{{}} \
   // bugpath-warning{{Function argument constraint is not satisfied}} \
+  // bugpath-note{{}} \
   // bugpath-note{{Function argument constraint is not satisfied}}
 }
 void test_notnull_symbolic(FILE *fp, int *buf) {
@@ -191,7 +209,9 @@
 // bugpath-note{{Taking true branch}}
 fread(buf, sizeof(int), 10, fp); // \
 // report-warning{{Function argument constraint is not satisfied}} \
+// report-note{{}} \
 // bugpath-warning{{Function argument constraint is not satisfied}} \
+// bugpath-note{{}} \
 // bugpath-note{{Function argumen

[PATCH] D100980: [OpenCL] Allow use of double type without extension pragma

2021-04-23 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia added a comment.

In D100980#2711963 , @azabaznov wrote:

>> For cl_khr_fp64 I still want to keep the pragma for the other use case - to 
>> convert double literal into single-precision 
>> (https://github.com/KhronosGroup/OpenCL-Docs/issues/578). The reason why I 
>> think it could be useful is that the precision change might lead to a 
>> different result depending on the precision of the calculation. So I think 
>> pragmas could be useful to control whether double literal is 
>> single-precision or not to avoid this problem occur when code is compiled 
>> for different targets?
>
> Yeah, then we should  use 
> `S.getOpenCLOptions().isAvailableOption("cl_khr_fp64", S.getLangOpts())` to 
> check for enabled pragma.

Just to be clear, we already use `isAvailableOption` in other cases, for 
example this:
https://clang.llvm.org/doxygen/SemaExpr_8cpp_source.html#l00816

My idea was to simplify only one particular case when the data types are being 
used because I don't find the pragma useful for it and it is also inconsistent.

We could of course keep it just for this particular case of doubles, but even 
half is allowed in certain circumstances without the pragma and it is still an 
extension.
https://godbolt.org/z/K34sP81nx

So I personally don't see a big value to keep it just for the particular case 
of doubles.

> And do I understand correctly that the pragma is not needed in OpenCL C 1.2+ 
> since extension became core?

To be honest I don't really know. In the unified spec there is nothing about 
the pragmas. For now I just want to address the use cases that don't cause 
backward compatibility issues.


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

https://reviews.llvm.org/D100980

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


[PATCH] D101159: Show why clang analyzer could not be executed

2021-04-23 Thread Ramin Moussavi via Phabricator via cfe-commits
Ramin created this revision.
Ramin added a reviewer: clang-tools-extra.
Herald added subscribers: steakhal, ASDenysPetrov, dkrupp, donat.nagy, 
Szelethus, a.sidorin, baloghadamsoftware.
Ramin requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

when an unknown paramater is used when running scan-build

it just prints "could not find clang line"

this patch shows the error message


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D101159

Files:
  clang/tools/scan-build/libexec/ccc-analyzer


Index: clang/tools/scan-build/libexec/ccc-analyzer
===
--- clang/tools/scan-build/libexec/ccc-analyzer
+++ clang/tools/scan-build/libexec/ccc-analyzer
@@ -39,11 +39,19 @@
 
   # Invoke 'system', STDOUT and STDERR are output to a temporary file.
   system $Command, @_;
+  my $ret = $?;
 
   # Restore STDOUT and STDERR.
   open STDOUT, ">&", \*OLDOUT;
   open STDERR, ">&", \*OLDERR;
 
+  if ($ret != 0) {
+print "failed to run $Command \n";
+while(<$TmpFH>){
+   print $_;
+}
+  }
+
   return $TmpFH;
 }
 


Index: clang/tools/scan-build/libexec/ccc-analyzer
===
--- clang/tools/scan-build/libexec/ccc-analyzer
+++ clang/tools/scan-build/libexec/ccc-analyzer
@@ -39,11 +39,19 @@
 
   # Invoke 'system', STDOUT and STDERR are output to a temporary file.
   system $Command, @_;
+  my $ret = $?;
 
   # Restore STDOUT and STDERR.
   open STDOUT, ">&", \*OLDOUT;
   open STDERR, ">&", \*OLDERR;
 
+  if ($ret != 0) {
+print "failed to run $Command \n";
+while(<$TmpFH>){
+   print $_;
+}
+  }
+
   return $TmpFH;
 }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D101060: [Analyzer][StdLibraryFunctionsChecker] Describe arg constraints

2021-04-23 Thread Valeriy Savchenko via Phabricator via cfe-commits
vsavchenko added a comment.

Awesome, thanks!

LGTM now!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101060

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


[PATCH] D99949: [AMDGPU][OpenMP] Add amdgpu-arch tool to list AMD GPUs installed

2021-04-23 Thread David Zarzycki via Phabricator via cfe-commits
davezarzycki added a comment.

It's still failing but I can disable HSA on this machine for now. FYI --

  FAILED: 
tools/clang/tools/amdgpu-arch/CMakeFiles/amdgpu-arch.dir/AMDGPUArch.cpp.o
  /p/tllvm/bin/clang++ -DGTEST_HAS_RTTI=0 -D_GNU_SOURCE 
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
-Itools/clang/tools/amdgpu-arch -I/home/dave/ro_s/lp/clang/tools/amdgpu-arch 
-I/home/dave/ro_s/lp/clang/include -Itools/clang/include -Iinclude 
-I/home/dave/ro_s/lp/llvm/include -Werror=switch -Wno-deprecated-copy 
-stdlib=libc++ -fPIC -fvisibility-inlines-hidden -Werror=date-time 
-Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter 
-Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic 
-Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough 
-Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor 
-Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion 
-fdiagnostics-color -ffunction-sections -fdata-sections -fno-common 
-Woverloaded-virtual -Wno-nested-anon-types -O2 -DNDEBUG  -march=skylake 
-fno-vectorize -fno-slp-vectorize -fno-tree-slp-vectorize -fno-exceptions 
-fno-rtti -std=c++14 -MD -MT 
tools/clang/tools/amdgpu-arch/CMakeFiles/amdgpu-arch.dir/AMDGPUArch.cpp.o -MF 
tools/clang/tools/amdgpu-arch/CMakeFiles/amdgpu-arch.dir/AMDGPUArch.cpp.o.d -o 
tools/clang/tools/amdgpu-arch/CMakeFiles/amdgpu-arch.dir/AMDGPUArch.cpp.o -c 
/home/dave/ro_s/lp/clang/tools/amdgpu-arch/AMDGPUArch.cpp
  /home/dave/ro_s/lp/clang/tools/amdgpu-arch/AMDGPUArch.cpp:14:10: fatal error: 
'hsa.h' file not found
  #include 
   ^~~
  1 error generated.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99949

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


[clang] fcb45b5 - [OpenCL] Fix typo in the test.

2021-04-23 Thread Anastasia Stulova via cfe-commits

Author: Anastasia Stulova
Date: 2021-04-23T14:36:36+01:00
New Revision: fcb45b544d3da87e0aab895eaac7903197a6c58c

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

LOG: [OpenCL] Fix typo in the test.

Added: 


Modified: 
clang/test/SemaOpenCL/func.cl

Removed: 




diff  --git a/clang/test/SemaOpenCL/func.cl b/clang/test/SemaOpenCL/func.cl
index bcac30b67e372..d4a6ec6170616 100644
--- a/clang/test/SemaOpenCL/func.cl
+++ b/clang/test/SemaOpenCL/func.cl
@@ -1,6 +1,6 @@
 // RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -triple 
spir-unknown-unknown
 // RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -triple 
spir-unknown-unknown -DFUNCPTREXT
-// RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -triple 
spir-unknown-unknown -DVARARG
+// RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -triple 
spir-unknown-unknown -DVARARGEXT
 
 #ifdef FUNCPTREXT
 #pragma OPENCL EXTENSION __cl_clang_function_pointers : enable



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


[PATCH] D101030: [OpenMP] Overhaul `declare target` handling

2021-04-23 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev added inline comments.



Comment at: clang/lib/Parse/ParseOpenMP.cpp:2134-2151
+Sema::DeclareTargetContextInfo *DTCI =
+new Sema::DeclareTargetContextInfo(DKind, DTLoc);
+if (HasClauses)
+  ParseOMPDeclareTargetClauses(*DTCI);
 
 // Skip the last annot_pragma_openmp_end.
 ConsumeAnyToken();

jdoerfert wrote:
> ABataev wrote:
> > Add a RAII to control these new/delete or just create local var
> Local variable and RAII do not always work, there is a delete in the 
> `end_declare_target` below as well.
> 
> 
But here you have new/delete pair within a single block. Either you can put the 
ar into stack/RAII or some extra checks are missing. Maybe must be something 
like this:
```
if (DKind == OMPD_declare_target)
  delete DTCI;
```
?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101030

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


[PATCH] D101130: [PowerPC] Provide XL-compatible builtins in altivec.h

2021-04-23 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm accepted this revision.
cebowleratibm added inline comments.
This revision is now accepted and ready to land.



Comment at: clang/test/CodeGen/builtins-ppc-xlcompat.c:2
+// REQUIRES: powerpc-registered-target
+// RUN: %clang_cc1 -target-feature +altivec -target-feature +vsx \
+  // RUN:   -triple powerpc64-unknown-unknown -emit-llvm %s -o - \

Suggest adding an explicit -mcpu.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101130

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


[PATCH] D99488: [SYCL][Doc] Add address space handling section to SYCL documentation

2021-04-23 Thread Alexey Bader via Phabricator via cfe-commits
bader updated this revision to Diff 340011.
bader added a comment.

Incorporate https://reviews.llvm.org/D89909 review feedback.

Allow one way implicit conversion only for now.
>From named address space to default.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99488

Files:
  clang/docs/SYCLSupport.rst


Index: clang/docs/SYCLSupport.rst
===
--- clang/docs/SYCLSupport.rst
+++ clang/docs/SYCLSupport.rst
@@ -219,3 +219,94 @@
 
 Additional details of kernel parameter passing may be found in the document
 `SYCL Kernel Parameter Handling and Array Support 
`_.
+
+Address space handling
+^^
+
+The SYCL specification represents pointers to disjoint memory regions using C++
+wrapper classes on an accelerator to enable compilation with a standard C++
+toolchain and a SYCL compiler toolchain. Section 3.8.2 of SYCL 2020
+specification defines
+`memory model 
`_\
 ,
+section 4.7.7 - `address space classes 
`_
+and section 5.9 covers `address space deduction 
`_.
+The SYCL specification allows two modes of address space deduction: "generic as
+default address space" (see section 5.9.3) and "inferred address space" (see
+section 5.9.4). Current implementation supports only "generic as default 
address
+space" mode.
+
+SYCL borrows its memory model from OpenCL however SYCL doesn't perform
+the address space qualifier inference as detailed in
+`OpenCL C v3.0 6.7.8 
`_.
+
+The default address space is "generic-memory", which is a virtual address space
+that overlaps the global, local, and private address spaces. SYCL mode enables
+explicit conversions to/from the default address space from/to the address
+space-attributed type and implicit conversions from the address 
space-attributed
+type to the default address space. All named address spaces are disjoint and
+sub-sets of default address space.
+
+The SPIR target allocates SYCL namespace scope variables in the global address
+space.
+
+Pointers to default address space should get lowered into a pointer to a 
generic
+address space (or flat to reuse more general terminology). But depending on the
+allocation context, the default address space of a non-pointer type is assigned
+to a specific address space. This is described in
+`common address space deduction rules 
`_
+section.
+
+This is also in line with the behaviour of CUDA (`small example
+`_).
+
+``multi_ptr`` class implementation example:
+
+.. code-block:: C++
+
+   // check that SYCL mode is ON and we can use non-standard decorations
+   #if defined(__SYCL_DEVICE_ONLY__)
+   // GPU/accelerator implementation
+   template  class multi_ptr {
+ // DecoratedType applies corresponding address space attribute to the 
type T
+ // DecoratedType::type == 
"__attribute__((opencl_global)) T"
+ // See sycl/include/CL/sycl/access/access.hpp for more details
+ using pointer_t = typename DecoratedType::type *;
+
+ pointer_t m_Pointer;
+ public:
+ pointer_t get() { return m_Pointer; }
+ T& operator* () { return *reinterpret_cast(m_Pointer); }
+   }
+   #else
+   // CPU/host implementation
+   template  class multi_ptr {
+ T *m_Pointer; // regular undecorated pointer
+ public:
+ T *get() { return m_Pointer; }
+ T& operator* () { return *m_Pointer; }
+   }
+   #endif
+
+Depending on the compiler mode, ``multi_ptr`` will either decorate its internal
+data with the address space attribute or not.
+
+To utilize clang's existing functionality, we reuse the following OpenCL 
address
+space attributes for pointers:
+
+.. list-table::
+   :header-rows: 1
+
+   * - Address space attribute
+ - SYCL address_space enumeration
+   * - ``__attribute__((opencl_global))``
+ - global_space, constant_space
+   * - ``__attribute__((opencl_local))``
+ - local_space
+   * - ``__attribute__((opencl_private))``
+ - private_space
+
+
+.. code-block::
+
+   TODO: add support for `__attribute__((opencl_global_host))` and
+   `__attribute__((opencl_global_device))`.


Index: clang/docs/SYCLSupport.rst
===
--- clang/docs/SYCLSupport.rst
+++ clang/docs/SYCLSupport.rst
@@ -219,3 +219,94 @@
 
 Additional details of kernel parameter passing may be found in the document

[PATCH] D89909: [SYCL] Implement SYCL address space attributes handling

2021-04-23 Thread Alexey Bader via Phabricator via cfe-commits
bader marked 5 inline comments as done.
bader added a comment.

@Anastasia, I've updated https://reviews.llvm.org/D99488 and refactored 
`getStringLiteralAddressSpace` to handle non-string constants as well. Please, 
take a look.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89909

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


[PATCH] D101033: [clang-format] fix indent in alignChainedConditionals

2021-04-23 Thread Krasimir Georgiev via Phabricator via cfe-commits
krasimir added a comment.

I also have a limited understanding based on the original patch 
https://github.com/llvm/llvm-project/commit/4db94094b469b4715d08ef37f1799bf3ea7ca8ea
 together with examining affected test cases.
I believe the intention of this section is to handle, e.g., the alignment of 
`ee` and `` and `` in cases 
like this, where the previous toke is the `:`:

  return  ? (a ? bb :
 c ? dd :
 ee) :
  ?  :
;

The check for `tok::question` that I remove in this context seems superfluous 
in the first place.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101033

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


[PATCH] D101057: [clangd] Allow AST request without range

2021-04-23 Thread Christian Kandeler via Phabricator via cfe-commits
ckandeler updated this revision to Diff 340014.
ckandeler added a comment.

Fixed remaining issues


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101057

Files:
  clang-tools-extra/clangd/ClangdServer.cpp
  clang-tools-extra/clangd/ClangdServer.h
  clang-tools-extra/clangd/DumpAST.cpp
  clang-tools-extra/clangd/DumpAST.h
  clang-tools-extra/clangd/Protocol.h
  clang-tools-extra/clangd/test/ast-no-range.test
  clang-tools-extra/clangd/unittests/DumpASTTests.cpp

Index: clang-tools-extra/clangd/unittests/DumpASTTests.cpp
===
--- clang-tools-extra/clangd/unittests/DumpASTTests.cpp
+++ clang-tools-extra/clangd/unittests/DumpASTTests.cpp
@@ -16,8 +16,12 @@
 namespace clang {
 namespace clangd {
 namespace {
+using testing::Contains;
+using testing::Not;
 using testing::SizeIs;
 
+MATCHER_P(WithDetail, str, "") { return arg.detail == str; }
+
 TEST(DumpASTTests, BasicInfo) {
   std::pair Cases[] = {
   {R"cpp(
@@ -157,6 +161,20 @@
   EXPECT_EQ(Node.children.front().range, Case.range("type"));
 }
 
+TEST(DumpASTTests, NoRange) {
+  auto TU = TestTU::withHeaderCode("void funcFromHeader();");
+  TU.Code = "int varFromSource;";
+  ParsedAST AST = TU.build();
+  auto Node = dumpAST(
+  DynTypedNode::create(*AST.getASTContext().getTranslationUnitDecl()),
+  AST.getTokens(), AST.getASTContext());
+  ASSERT_THAT(Node.children, Contains(WithDetail("varFromSource")));
+  ASSERT_THAT(Node.children, Not(Contains(WithDetail("funcFromHeader";
+  EXPECT_THAT(Node.arcana, testing::StartsWith("TranslationUnitDecl "));
+  ASSERT_FALSE(Node.range.hasValue())
+  << "Expected no range for translation unit";
+}
+
 TEST(DumpASTTests, Arcana) {
   ParsedAST AST = TestTU::withCode("int x;").build();
   auto Node = dumpAST(DynTypedNode::create(findDecl(AST, "x")), AST.getTokens(),
Index: clang-tools-extra/clangd/test/ast-no-range.test
===
--- /dev/null
+++ clang-tools-extra/clangd/test/ast-no-range.test
@@ -0,0 +1,53 @@
+# RUN: clangd -lit-test < %s | FileCheck %s
+{"jsonrpc":"2.0","id":0,"method":"initialize","params":{"processId":123,"rootPath":"clangd","capabilities":{},"trace":"off"}}
+---
+{"jsonrpc":"2.0","method":"textDocument/didOpen","params":{"textDocument":{"uri":"test:///simple.cpp","languageId":"cpp","version":1,"text":"int x;"}}}
+---
+{"jsonrpc":"2.0","id":1,"method":"textDocument/ast","params":{"textDocument":{"uri":"test:///simple.cpp"}}}
+#  CHECK:  "id": 1,
+# CHECK-NEXT:  "jsonrpc": "2.0",
+# CHECK-NEXT:  "result": {
+# CHECK-NEXT:"arcana": "{{TranslationUnitDecl.*}}"
+# CHECK-NEXT:"children": [
+# CHECK-NEXT:  {
+#  CHECK:"arcana": "VarDecl {{.*}} x 'int'",
+# CHECK-NEXT:"children": [
+# CHECK-NEXT:  {
+# CHECK-NEXT:"arcana": "QualType {{.*}} 'int' ",
+# CHECK-NEXT:"detail": "int",
+# CHECK-NEXT:"kind": "Builtin",
+# CHECK-NEXT:"range": {
+# CHECK-NEXT:  "end": {
+# CHECK-NEXT:"character": 3,
+# CHECK-NEXT:"line": 0
+# CHECK-NEXT:  },
+# CHECK-NEXT:  "start": {
+# CHECK-NEXT:"character": 0,
+# CHECK-NEXT:"line": 0
+# CHECK-NEXT:  }
+# CHECK-NEXT:},
+# CHECK-NEXT:"role": "type"
+# CHECK-NEXT:  }
+# CHECK-NEXT:],
+# CHECK-NEXT:"detail": "x",
+# CHECK-NEXT:"kind": "Var",
+# CHECK-NEXT:"range": {
+# CHECK-NEXT:  "end": {
+# CHECK-NEXT:"character": 5,
+# CHECK-NEXT:"line": 0
+# CHECK-NEXT:  },
+# CHECK-NEXT:  "start": {
+# CHECK-NEXT:"character": 0,
+# CHECK-NEXT:"line": 0
+# CHECK-NEXT:  }
+# CHECK-NEXT:},
+# CHECK-NEXT:"role": "declaration"
+# CHECK-NEXT:  }
+# CHECK-NEXT:],
+# CHECK-NEXT:"kind": "TranslationUnit",
+# CHECK-NEXT:"role": "declaration"
+# CHECK-NEXT:  }
+---
+{"jsonrpc":"2.0","id":2,"method":"shutdown"}
+---
+{"jsonrpc":"2.0","method":"exit"}
Index: clang-tools-extra/clangd/Protocol.h
===
--- clang-tools-extra/clangd/Protocol.h
+++ clang-tools-extra/clangd/Protocol.h
@@ -1725,7 +1725,8 @@
 
   /// The position of the node to be dumped.
   /// The highest-level node that entirely contains the range will be returned.
-  Range range;
+  /// If no range is given, the root translation unit node will be returned.
+  llvm::Optional range;
 };
 bool fromJSON(const llvm::json::Value &, ASTParams &, llvm::json::Path);
 
Index: clang-tools-extra/clangd/DumpAST.h
===
--- clang-tools-extra/clangd/DumpAST.h
+++ clang-tools-extra/clangd/DumpAST.h
@@ -39,6 +39,8 @@
 } // namespace syntax
 nam

[PATCH] D101057: [clangd] Allow AST request without range

2021-04-23 Thread Christian Kandeler via Phabricator via cfe-commits
ckandeler added a comment.

In D101057#2711997 , @sammccall wrote:

> Want me to land this for you?

Yes, please. I don't have push privileges. Thanks for the prompt and helpful 
review.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101057

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


[PATCH] D101087: [OpenCL] Introduce new method for validating OpenCL target

2021-04-23 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia added inline comments.



Comment at: clang/include/clang/Basic/DiagnosticCommonKinds.td:365
+def warn_opencl_unsupported_core_feature : Warning<
+  "%0 is a core feature in OpenCL C %1 but not supported on this target">,
+  InGroup, DefaultIgnore;

I would prefer:

`OpenCL C` -> `OpenCL version`

then it should cover better C++ for OpenCL as it is aligned with OpenCL 
versions. This is also more consistent with how we report most of the 
diagnostics with language versions.

But in the future, I want to refactor the diagnostics to have wording about 
OpenCL C and C++ for OpenCL separately, like we already do in 
`err_opencl_unknown_type_specifier` that uses the following helper 
https://clang.llvm.org/doxygen/classclang_1_1LangOptions.html#a730c1c883221b87b7c3aaec4327b814b

We definitely need a separate pass over diagnostic wording and how we report 
OpenCL language versions. 



Comment at: clang/include/clang/Basic/OpenCLOptions.h:179
+  static bool isOpenCLOptionCoreIn(const LangOptions &LO, Args &&... args) {
+return OpenCLOptionInfo(std::forward(args)...).isCoreIn(LO);
+  }

Do you think we could avoid constructing the temporary objects somehow?

I.e. could we just check the condition `CLVer >= Avail` that is used in the 
non-static member function directly?

We could then use these helpers in the non-static members perhaps to avoid 
duplication.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101087

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


[PATCH] D101166: This commit tries to revert Clang commit 40beb1f84a to see if that's the cause of failures in the Runtimes build.

2021-04-23 Thread Louis Dionne via Phabricator via cfe-commits
ldionne created this revision.
Herald added a subscriber: arichardson.
ldionne requested review of this revision.
Herald added projects: clang, libc++.
Herald added subscribers: libcxx-commits, cfe-commits.
Herald added a reviewer: libc++.

I'm creating a Phab review for this to take advantage of the beefy CI
machines to do the heavy lifting for me.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D101166

Files:
  clang/lib/Sema/SemaOverload.cpp
  clang/test/CXX/drs/dr14xx.cpp
  clang/test/CXX/drs/dr20xx.cpp
  libcxx/utils/ci/buildkite-pipeline.yml

Index: libcxx/utils/ci/buildkite-pipeline.yml
===
--- libcxx/utils/ci/buildkite-pipeline.yml
+++ libcxx/utils/ci/buildkite-pipeline.yml
@@ -18,294 +18,6 @@
 #
 
 steps:
-  #
-  # Light pre-commit tests for things like formatting or when people forget
-  # to update generated files.
-  #
-  - label: "Format"
-command: "libcxx/utils/ci/run-buildbot check-format"
-artifact_paths:
-  - "**/clang-format.patch"
-agents:
-  queue: "libcxx-builders"
-retry:
-  automatic:
-- exit_status: -1  # Agent was lost
-  limit: 2
-soft_fail:
-- exit_status: 1
-
-  - label: "Generated output"
-command: "libcxx/utils/ci/run-buildbot check-generated-output"
-artifact_paths:
-  - "**/generated_output.patch"
-agents:
-  queue: "libcxx-builders"
-retry:
-  automatic:
-- exit_status: -1  # Agent was lost
-  limit: 2
-
-  #
-  # General testing with the default configuration, under all the supported
-  # Standard modes, with Clang and GCC. This catches most issues upfront.
-  # The goal of this step is to catch most issues while being very fast.
-  #
-  - wait
-
-  - label: "C++03"
-command: "libcxx/utils/ci/run-buildbot generic-cxx03"
-artifact_paths:
-  - "**/test-results.xml"
-  - "**/*.abilist"
-agents:
-  queue: "libcxx-builders"
-retry:
-  automatic:
-- exit_status: -1  # Agent was lost
-  limit: 2
-
-  - label: "C++11"
-command: "libcxx/utils/ci/run-buildbot generic-cxx11"
-artifact_paths:
-  - "**/test-results.xml"
-  - "**/*.abilist"
-agents:
-  queue: "libcxx-builders"
-retry:
-  automatic:
-- exit_status: -1  # Agent was lost
-  limit: 2
-
-  - label: "C++14"
-command: "libcxx/utils/ci/run-buildbot generic-cxx14"
-artifact_paths:
-  - "**/test-results.xml"
-  - "**/*.abilist"
-agents:
-  queue: "libcxx-builders"
-retry:
-  automatic:
-- exit_status: -1  # Agent was lost
-  limit: 2
-
-  - label: "C++17"
-command: "libcxx/utils/ci/run-buildbot generic-cxx17"
-artifact_paths:
-  - "**/test-results.xml"
-  - "**/*.abilist"
-agents:
-  queue: "libcxx-builders"
-retry:
-  automatic:
-- exit_status: -1  # Agent was lost
-  limit: 2
-
-  - label: "C++20"
-command: "libcxx/utils/ci/run-buildbot generic-cxx20"
-artifact_paths:
-  - "**/test-results.xml"
-  - "**/*.abilist"
-agents:
-  queue: "libcxx-builders"
-retry:
-  automatic:
-- exit_status: -1  # Agent was lost
-  limit: 2
-
-  - label: "C++2b"
-command: "libcxx/utils/ci/run-buildbot generic-cxx2b"
-artifact_paths:
-  - "**/test-results.xml"
-  - "**/*.abilist"
-agents:
-  queue: "libcxx-builders"
-retry:
-  automatic:
-- exit_status: -1  # Agent was lost
-  limit: 2
-
-  - label: "GCC/C++20"
-command: "libcxx/utils/ci/run-buildbot generic-gcc"
-artifact_paths:
-  - "**/test-results.xml"
-agents:
-  queue: "libcxx-builders"
-retry:
-  automatic:
-- exit_status: -1  # Agent was lost
-  limit: 2
-
-  #
-  # All other supported configurations of libc++.
-  #
-  - wait
-
-  - label: "-fno-exceptions"
-command: "libcxx/utils/ci/run-buildbot generic-noexceptions"
-artifact_paths:
-  - "**/test-results.xml"
-agents:
-  queue: "libcxx-builders"
-retry:
-  automatic:
-- exit_status: -1  # Agent was lost
-  limit: 2
-
-  - label: "Static libraries"
-command: "libcxx/utils/ci/run-buildbot generic-static"
-artifact_paths:
-  - "**/test-results.xml"
-agents:
-  queue: "libcxx-builders"
-retry:
-  automatic:
-- exit_status: -1  # Agent was lost
-  limit: 2
-
-  - label: "ASAN"
-command: "libcxx/utils/ci/run-buildbot generic-asan"
-artifact_paths:
-  - "**/test-results.xml"
-agents:
-  queue: "libcxx-builders"
-retry:
-  automatic:
-- exit_status: -1  # Agent was lost
-  limit: 2
-
-  - label: "TSAN"
-command: "libcxx/utils/ci/run-buildbot generic-tsan"
-artifact_paths:
-  - "**/test-results.xml"
-agents:
-  queue: "libcxx-builders"
-retry:
-  automatic:
-- exit_status: -1  #

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

2021-04-23 Thread Andrew Savonichev via Phabricator via cfe-commits
asavonic added a comment.

John, can you please review this patch?
I originally wanted to add a diagnostic to prevent the crash in CG (PR49198), 
but the case seems easy enough to support.


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] D101130: [PowerPC] Provide XL-compatible builtins in altivec.h

2021-04-23 Thread Bardia Mahjour via Phabricator via cfe-commits
bmahjour added a comment.

LGTM




Comment at: clang/test/CodeGen/builtins-ppc-xlcompat.c:6
+// RUN: %clang_cc1 -target-feature +altivec -target-feature +vsx \
+  // RUN:   -triple powerpc64le-unknown-unknown -emit-llvm %s -o - \
+// RUN:   -D__XL_COMPAT_ALTIVEC__ | FileCheck %s

[nit] remove extra space


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101130

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


[PATCH] D101041: [analyzer] Find better description for tracked symbolic values

2021-04-23 Thread Gabor Marton via Phabricator via cfe-commits
martong added a comment.

Awesome!




Comment at: clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp:1529
+  // b = a;
+  // c = foo(b);
+  //

I'd rather use `identity` here (and at line 1509) instead of `foo`, I think 
that could make this explanation easier to follow.



Comment at: clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp:1532
+  // Telling the user that the value of 'a' is assigned to 'c', while
+  // correct, can be confusing.
+  StoreManager::FindUniqueBinding FB(V.getAsLocSymbol());

So here, we have two or three bindings attached to `c`? `foo(b)` and `a` (and 
`b` as well) ?
What is the guarantee that `FindUniqueBinding` will return with the correct one 
`foo(b)`? Seems like we iterate through an ImmutableMap (AVL tree) with 
`MemRegion*` keys. And the order of the iteration depends on pointer values. 
What I want to express, is that I don't see how do we find the correct binding, 
seems like we just find one, which might be the one we look for if we are lucky.

Perhaps we could have a lit test for this example?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101041

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


[PATCH] D101041: [analyzer] Find better description for tracked symbolic values

2021-04-23 Thread Valeriy Savchenko via Phabricator via cfe-commits
vsavchenko added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp:1529
+  // b = a;
+  // c = foo(b);
+  //

martong wrote:
> I'd rather use `identity` here (and at line 1509) instead of `foo`, I think 
> that could make this explanation easier to follow.
Good idea!



Comment at: clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp:1532
+  // Telling the user that the value of 'a' is assigned to 'c', while
+  // correct, can be confusing.
+  StoreManager::FindUniqueBinding FB(V.getAsLocSymbol());

martong wrote:
> So here, we have two or three bindings attached to `c`? `foo(b)` and `a` (and 
> `b` as well) ?
> What is the guarantee that `FindUniqueBinding` will return with the correct 
> one `foo(b)`? Seems like we iterate through an ImmutableMap (AVL tree) with 
> `MemRegion*` keys. And the order of the iteration depends on pointer values. 
> What I want to express, is that I don't see how do we find the correct 
> binding, seems like we just find one, which might be the one we look for if 
> we are lucky.
> 
> Perhaps we could have a lit test for this example?
Good idea, I should a test for that!
`FindUniqueBinding` does not only have a region, it also carries a flag 
checking if there are more than one binding.  `operator bool` then checks for 
both, thus guaranteeing that we won't choose random binding out of more than 1 
- we won't choose at all.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101041

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


[PATCH] D100739: [Coroutines] Handle overaligned frame allocation (2)

2021-04-23 Thread Xun Li via Phabricator via cfe-commits
lxfind added a comment.

> Sorry for the confusion. I think either overaligned or under-aligned could be 
> used here to describe the problem: either "Handle overaligned frame" or "Fix 
> under-aligned frame". Since c++ spec defines the former but not the later 
> (https://en.cppreference.com/w/cpp/language/object#Alignment), my first 
> intuition was to use the term "overalign". Under-aligned is the undesired 
> outcome that should be fixed (probably too late to handle I assume). Also the 
> overaligned is a static property whereas 'under-aligned" is a runtime 
> property. From the compiler's perspective, I think overaligned should be 
> preferred. With that said, I don't feel strongly about this. I could switch 
> to use "overaligned" if that feels more intuitive.

"Handle" is probably not the right word to be used here. What follows "handle" 
is typically a legit situation that already occurred but not current handled 
properly. Here "overaligned frame" doesn't already occur. From what I 
understand, you really just want to support promise object alignment. So why 
not just say that directly?
To add on that, I do think you need to describe the problem in more detail in 
the description. It's indeed still confusing.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100739

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


[PATCH] D100860: [C++4OpenCL] Add missing OpenCL specific diagnostics in templates

2021-04-23 Thread Sven van Haastregt via Phabricator via cfe-commits
svenvh accepted this revision.
svenvh added a comment.

LGTM, thanks!

Please make sure that the commit message corresponds to the new shape of your 
patch: you might want to update the description of this review.


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

https://reviews.llvm.org/D100860

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


[PATCH] D101130: [PowerPC] Provide XL-compatible builtins in altivec.h

2021-04-23 Thread Jinsong Ji via Phabricator via cfe-commits
jsji added inline comments.



Comment at: clang/lib/Headers/altivec.h:3055
 
+#ifdef __XL_COMPAT_ALTIVEC__
+/* vec_ctf */

This only affects __VSX__ version right? If so, can we move `#ifdef 
__XL_COMPAT_ALTIVEC__` into `#ifdef __VSX__`?
Or even better only into the part of affected types, eg: vector unsinged long 
long?



Comment at: clang/lib/Headers/altivec.h:3065
+   (__b)), 
\
+ vector unsigned long long 
\
+   : (__builtin_vsx_xvcvuxdsp((vector unsigned long long)(__a)) *  
\

Can we also add comments about what is the major difference with and without 
`__XL_COMPAT_ALTIVEC__` , for long term maintenance?



Comment at: clang/test/CodeGen/builtins-ppc-xlcompat.c:8
+// RUN:   -D__XL_COMPAT_ALTIVEC__ | FileCheck %s
+#include 
+vector double vd = { 3.4e22, 1.8e-3 };

Can we add a RUN line to test that novsx are not affected?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101130

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


[PATCH] D101130: [PowerPC] Provide XL-compatible builtins in altivec.h

2021-04-23 Thread Jinsong Ji via Phabricator via cfe-commits
jsji added inline comments.



Comment at: clang/lib/Headers/altivec.h:3065
+   (__b)), 
\
+ vector unsigned long long 
\
+   : (__builtin_vsx_xvcvuxdsp((vector unsigned long long)(__a)) *  
\

jsji wrote:
> Can we also add comments about what is the major difference with and without 
> `__XL_COMPAT_ALTIVEC__` , for long term maintenance?
> Can we also add comments about what is the major difference with and without 
> `__XL_COMPAT_ALTIVEC__` , for long term maintenance?

I know they are in commit message, but I think comments in source code would be 
more helpful than in commit message. Thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101130

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


[PATCH] D101089: [OpenCL] Document legacy atomics with generic address space

2021-04-23 Thread Sven van Haastregt via Phabricator via cfe-commits
svenvh accepted this revision.
svenvh added a comment.
This revision is now accepted and ready to land.

Nitpick to make the sentence read more smoothly; otherwise LGTM!




Comment at: clang/docs/LanguageExtensions.rst:1819
+
+Clang allows use of atomic functions from earlier than OpenCL 2.0
+standard with generic address space pointer in C++ for OpenCL mode. 

"from earlier than OpenCL 2.0 standard" -> "from the OpenCL 1.x standards"


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

https://reviews.llvm.org/D101089

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


[PATCH] D100501: [cland] Dont emit missing newline warnings when building preamble

2021-04-23 Thread Sam McCall via Phabricator via cfe-commits
sammccall added a comment.

A too-late drive-by - maybe we'd be better detecting these in clang never 
emitting these


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100501

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


[PATCH] D100501: [cland] Dont emit missing newline warnings when building preamble

2021-04-23 Thread Sam McCall via Phabricator via cfe-commits
sammccall added a comment.

Hit send too soon. But IIRC PP knows whether it's building a preamble.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100501

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


[PATCH] D101054: [AST] Sort introspection results without instantiating other data

2021-04-23 Thread Nathan James via Phabricator via cfe-commits
njames93 accepted this revision.
njames93 added a comment.
This revision is now accepted and ready to land.

This I suppose is a good fast way to sort these.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101054

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


[PATCH] D101168: [C++4OpenCL] Add clang extension for unsafe kernel parameters

2021-04-23 Thread Ole Strohm via Phabricator via cfe-commits
olestrohm created this revision.
olestrohm added reviewers: Anastasia, svenvh.
olestrohm added a project: clang.
Herald added subscribers: ldrumm, kerbowa, jfb, yaxunl, nhaehnle, jvesely, 
jholewinski.
olestrohm requested review of this revision.
Herald added a subscriber: cfe-commits.

This feature allows using non-portable types as kernel parameters. This allows 
bypassing the portability guarantees from the restrictions specified
in C++ for OpenCL v1.0 s2.4 
.

Currently this only disables the restrictions related to layout, as a 
programmer using the same compiler for host and device should get the same 
representation.
This could be extended to other things (like `size_t`) if desired in the 
future, but I think it's unlikely that someone would want that.

Previous discussion about the extension in 
https://bugs.llvm.org/show_bug.cgi?id=50081


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D101168

Files:
  clang/docs/LanguageExtensions.rst
  clang/include/clang/Basic/OpenCLExtensions.def
  clang/lib/Basic/Targets/AMDGPU.h
  clang/lib/Basic/Targets/NVPTX.h
  clang/lib/Sema/SemaDecl.cpp
  clang/test/Misc/amdgcn.languageOptsOpenCL.cl
  clang/test/Misc/nvptx.languageOptsOpenCL.cl
  clang/test/Misc/r600.languageOptsOpenCL.cl
  clang/test/SemaOpenCLCXX/invalid-kernel.clcpp

Index: clang/test/SemaOpenCLCXX/invalid-kernel.clcpp
===
--- clang/test/SemaOpenCLCXX/invalid-kernel.clcpp
+++ clang/test/SemaOpenCLCXX/invalid-kernel.clcpp
@@ -1,4 +1,9 @@
-// RUN: %clang_cc1 %s -pedantic -verify -fsyntax-only
+// RUN: %clang_cc1 %s -pedantic -verify -fsyntax-only -triple spir-unknown-unknown
+// RUN: %clang_cc1 %s -pedantic -verify -fsyntax-only -triple spir-unknown-unknown -DUNSAFEKERNELPARAMETER
+
+#ifdef UNSAFEKERNELPARAMETER
+#pragma OPENCL EXTENSION __cl_clang_allow_unsafe_kernel_parameters: enable
+#endif
 
 struct C {
   kernel void m(); //expected-error{{kernel functions cannot be class members}}
@@ -24,8 +29,10 @@
 kernel void int_p_r(__global int *__global &in);
 kernel void int_p_p_r(__global int *__global *__global &in);
 
-// expected-error@+1{{'__private atomic_int' (aka '__private _Atomic(int)') cannot be used as the type of a kernel parameter}}
 kernel void k_atomic_v(atomic_int in);
+#ifndef UNSAFEKERNELPARAMETER
+// expected-error@-2{{'__private atomic_int' (aka '__private _Atomic(int)') cannot be used as the type of a kernel parameter}}
+#endif
 kernel void k_atomic_p(__global atomic_int *in);
 kernel void k_atomic_r(__global atomic_int &in);
 
@@ -56,7 +63,10 @@
   StandardLayout(int a, int b) : a(a), b(b) {}
 };
 
-kernel void standard_v(StandardLayout in) {} //expected-error{{'__private StandardLayout' cannot be used as the type of a kernel parameter}}
+kernel void standard_v(StandardLayout in) {}
+#ifndef UNSAFEKERNELPARAMETER
+//expected-error@-2{{'__private StandardLayout' cannot be used as the type of a kernel parameter}}
+#endif
 kernel void standard_p(__global StandardLayout *in) {}
 kernel void standard_p_p(__global StandardLayout *__global *in) {}
 kernel void standard_r(__global StandardLayout &in) {}
@@ -67,7 +77,19 @@
   int b;
 };
 
-kernel void trivial_v(Trivial in) {} //expected-error{{'__private Trivial' cannot be used as the type of a kernel parameter}}
-kernel void trivial_p(__global Trivial *in) {} //expected-error{{'__global Trivial *__private' cannot be used as the type of a kernel parameter}}
-kernel void trivial_p_p(__global Trivial *__global *in) {} //expected-error{{'__global Trivial *__global *__private' cannot be used as the type of a kernel parameter}}
-kernel void trivial_r(__global Trivial &in) {} //expected-error{{'__global Trivial &__private' cannot be used as the type of a kernel parameter}}
+kernel void trivial_v(Trivial in) {}
+#ifndef UNSAFEKERNELPARAMETER
+//expected-error@-2{{'__private Trivial' cannot be used as the type of a kernel parameter}}
+#endif
+kernel void trivial_p(__global Trivial *in) {}
+#ifndef UNSAFEKERNELPARAMETER
+//expected-error@-2{{'__global Trivial *__private' cannot be used as the type of a kernel parameter}}
+#endif
+kernel void trivial_p_p(__global Trivial *__global *in) {}
+#ifndef UNSAFEKERNELPARAMETER
+//expected-error@-2{{'__global Trivial *__global *__private' cannot be used as the type of a kernel parameter}}
+#endif
+kernel void trivial_r(__global Trivial &in) {}
+#ifndef UNSAFEKERNELPARAMETER
+//expected-error@-2{{'__global Trivial &__private' cannot be used as the type of a kernel parameter}}
+#endif
Index: clang/test/Misc/r600.languageOptsOpenCL.cl
===
--- clang/test/Misc/r600.languageOptsOpenCL.cl
+++ clang/test/Misc/r600.languageOptsOpenCL.cl
@@ -34,6 +34,11 @@
 #endif
 #pragma OPENCL EXTENSION __cl_clang_variadic_functions : enable
 
+#ifndef __cl_clang_allow_unsafe_kernel_parameters
+#error "Missing __cl_c

[PATCH] D101049: [AST] Add DeclarationNameInfo to node introspection

2021-04-23 Thread Nathan James via Phabricator via cfe-commits
njames93 added inline comments.



Comment at: clang/include/clang/Tooling/NodeIntrospection.h:29
 class CXXBaseSpecifier;
+class DeclarationNameInfo;
 

Please fix this lint warning.



Comment at: clang/lib/Tooling/DumpTool/generate_cxx_src_locs.py:394-398
 cladeName not in [
   'NestedNameSpecifierLoc',
+  'DeclarationNameInfo',
   'TemplateArgumentLoc',
   'TypeLoc'])

Kind of unrelated, but can these not be replaced with `cladeName not in 
RefClades`?



Comment at: clang/unittests/Introspection/IntrospectionTest.cpp:1431-1433
+  if (Result.LocationAccessors.empty() && Result.RangeAccessors.empty()) {
+return;
+  }

Can this be replace with a 
```lang=c++
  if (!NodeIntrospection::hasIntrospectionSupport())
return;
```
Check at the start of the test?

Same goes for the rest of the tests added here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101049

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


[PATCH] D101054: [AST] Sort introspection results without instantiating other data

2021-04-23 Thread Stephen Kelly 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 rG35918bcb6f50: [AST] Sort introspection results without 
instantiating other data (authored by stephenkelly).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101054

Files:
  clang/lib/Tooling/NodeIntrospection.cpp


Index: clang/lib/Tooling/NodeIntrospection.cpp
===
--- clang/lib/Tooling/NodeIntrospection.cpp
+++ clang/lib/Tooling/NodeIntrospection.cpp
@@ -41,6 +41,23 @@
 }
 
 namespace internal {
+
+static bool locationCallLessThan(const LocationCall *LHS,
+ const LocationCall *RHS) {
+  if (!LHS && !RHS)
+return false;
+  if (LHS && !RHS)
+return true;
+  if (!LHS && RHS)
+return false;
+  auto compareResult = LHS->name().compare(RHS->name());
+  if (compareResult < 0)
+return true;
+  if (compareResult > 0)
+return false;
+  return locationCallLessThan(LHS->on(), RHS->on());
+}
+
 bool RangeLessThan::operator()(
 std::pair const &LHS,
 std::pair const &RHS) const {
@@ -54,15 +71,13 @@
   else if (LHS.first.getEnd() != RHS.first.getEnd())
 return false;
 
-  return LocationCallFormatterCpp::format(*LHS.second) <
- LocationCallFormatterCpp::format(*RHS.second);
+  return locationCallLessThan(LHS.second.get(), RHS.second.get());
 }
 bool RangeLessThan::operator()(
 std::pair const &LHS,
 std::pair const &RHS) const {
   if (LHS.first == RHS.first)
-return LocationCallFormatterCpp::format(*LHS.second) <
-   LocationCallFormatterCpp::format(*RHS.second);
+return locationCallLessThan(LHS.second.get(), RHS.second.get());
   return LHS.first < RHS.first;
 }
 } // namespace internal


Index: clang/lib/Tooling/NodeIntrospection.cpp
===
--- clang/lib/Tooling/NodeIntrospection.cpp
+++ clang/lib/Tooling/NodeIntrospection.cpp
@@ -41,6 +41,23 @@
 }
 
 namespace internal {
+
+static bool locationCallLessThan(const LocationCall *LHS,
+ const LocationCall *RHS) {
+  if (!LHS && !RHS)
+return false;
+  if (LHS && !RHS)
+return true;
+  if (!LHS && RHS)
+return false;
+  auto compareResult = LHS->name().compare(RHS->name());
+  if (compareResult < 0)
+return true;
+  if (compareResult > 0)
+return false;
+  return locationCallLessThan(LHS->on(), RHS->on());
+}
+
 bool RangeLessThan::operator()(
 std::pair const &LHS,
 std::pair const &RHS) const {
@@ -54,15 +71,13 @@
   else if (LHS.first.getEnd() != RHS.first.getEnd())
 return false;
 
-  return LocationCallFormatterCpp::format(*LHS.second) <
- LocationCallFormatterCpp::format(*RHS.second);
+  return locationCallLessThan(LHS.second.get(), RHS.second.get());
 }
 bool RangeLessThan::operator()(
 std::pair const &LHS,
 std::pair const &RHS) const {
   if (LHS.first == RHS.first)
-return LocationCallFormatterCpp::format(*LHS.second) <
-   LocationCallFormatterCpp::format(*RHS.second);
+return locationCallLessThan(LHS.second.get(), RHS.second.get());
   return LHS.first < RHS.first;
 }
 } // namespace internal
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 35918bc - [AST] Sort introspection results without instantiating other data

2021-04-23 Thread Stephen Kelly via cfe-commits

Author: Stephen Kelly
Date: 2021-04-23T16:21:01+01:00
New Revision: 35918bcb6f507cb3d28f80ab4408125ba292400c

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

LOG: [AST] Sort introspection results without instantiating other data

Avoid string allocation in particular, but also avoid attempting to
impose any particular ordering based on formatted results.

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

Added: 


Modified: 
clang/lib/Tooling/NodeIntrospection.cpp

Removed: 




diff  --git a/clang/lib/Tooling/NodeIntrospection.cpp 
b/clang/lib/Tooling/NodeIntrospection.cpp
index 8e2d446c3efec..f01bb1cb9c3ca 100644
--- a/clang/lib/Tooling/NodeIntrospection.cpp
+++ b/clang/lib/Tooling/NodeIntrospection.cpp
@@ -41,6 +41,23 @@ std::string LocationCallFormatterCpp::format(const 
LocationCall &Call) {
 }
 
 namespace internal {
+
+static bool locationCallLessThan(const LocationCall *LHS,
+ const LocationCall *RHS) {
+  if (!LHS && !RHS)
+return false;
+  if (LHS && !RHS)
+return true;
+  if (!LHS && RHS)
+return false;
+  auto compareResult = LHS->name().compare(RHS->name());
+  if (compareResult < 0)
+return true;
+  if (compareResult > 0)
+return false;
+  return locationCallLessThan(LHS->on(), RHS->on());
+}
+
 bool RangeLessThan::operator()(
 std::pair const &LHS,
 std::pair const &RHS) const {
@@ -54,15 +71,13 @@ bool RangeLessThan::operator()(
   else if (LHS.first.getEnd() != RHS.first.getEnd())
 return false;
 
-  return LocationCallFormatterCpp::format(*LHS.second) <
- LocationCallFormatterCpp::format(*RHS.second);
+  return locationCallLessThan(LHS.second.get(), RHS.second.get());
 }
 bool RangeLessThan::operator()(
 std::pair const &LHS,
 std::pair const &RHS) const {
   if (LHS.first == RHS.first)
-return LocationCallFormatterCpp::format(*LHS.second) <
-   LocationCallFormatterCpp::format(*RHS.second);
+return locationCallLessThan(LHS.second.get(), RHS.second.get());
   return LHS.first < RHS.first;
 }
 } // namespace internal



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


[PATCH] D101092: [OpenCL][Docs] Misc updates about C++ for OpenCL and offline compilation

2021-04-23 Thread Sven van Haastregt via Phabricator via cfe-commits
svenvh accepted this revision.
svenvh added a comment.
This revision is now accepted and ready to land.

LGTM.


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

https://reviews.llvm.org/D101092

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


[PATCH] D101041: [analyzer] Find better description for tracked symbolic values

2021-04-23 Thread Gabor Marton via Phabricator via cfe-commits
martong added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp:1532
+  // Telling the user that the value of 'a' is assigned to 'c', while
+  // correct, can be confusing.
+  StoreManager::FindUniqueBinding FB(V.getAsLocSymbol());

vsavchenko wrote:
> martong wrote:
> > So here, we have two or three bindings attached to `c`? `foo(b)` and `a` 
> > (and `b` as well) ?
> > What is the guarantee that `FindUniqueBinding` will return with the correct 
> > one `foo(b)`? Seems like we iterate through an ImmutableMap (AVL tree) with 
> > `MemRegion*` keys. And the order of the iteration depends on pointer 
> > values. What I want to express, is that I don't see how do we find the 
> > correct binding, seems like we just find one, which might be the one we 
> > look for if we are lucky.
> > 
> > Perhaps we could have a lit test for this example?
> Good idea, I should a test for that!
> `FindUniqueBinding` does not only have a region, it also carries a flag 
> checking if there are more than one binding.  `operator bool` then checks for 
> both, thus guaranteeing that we won't choose random binding out of more than 
> 1 - we won't choose at all.
Yeah, I missed that about `FindUniqueBinding`. 

It's just side questions then: Could we handle multiple bindings by finding the 
'last' binding and tracking that back?
And in this example, what are the bindings for `c`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101041

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


[PATCH] D79714: [Diagnostics] Restore -Wdeprecated warning when user-declared copy assignment operator is defined as deleted (PR45634)

2021-04-23 Thread Mikael Holmén via Phabricator via cfe-commits
uabelho added a comment.

In D79714#2711898 , @xbolva00 wrote:

> Can you try this fix?
>
>   diff --git a/libcxx/utils/libcxx/test/params.py 
> b/libcxx/utils/libcxx/test/params.py
>   index ddf277dea246..abf712e78a61 100644
>   --- a/libcxx/utils/libcxx/test/params.py
>   +++ b/libcxx/utils/libcxx/test/params.py
>   @@ -12,6 +12,7 @@ from libcxx.test.features import _isMSVC
>_warningFlags = [
>  '-Werror',
>  '-Wall',
>   +  '-Wno-deprecated-copy',
>  '-Wextra',
>  '-Wshadow',
>  '-Wundef',

The above doesn't help but if I add it in the list after -Wextra the warning 
goes away. Can you submit something like that?
Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79714

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


[clang] a7cb951 - [Analyzer][StdLibraryFunctionsChecker] Describe arg constraints

2021-04-23 Thread Gabor Marton via cfe-commits

Author: Gabor Marton
Date: 2021-04-23T17:27:54+02:00
New Revision: a7cb951fa40df14d98c51059194ae42855b96a08

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

LOG: [Analyzer][StdLibraryFunctionsChecker] Describe arg constraints

In this patch, I provide a detailed explanation for each argument
constraint. This explanation is added in an extra 'note' tag, which is
displayed alongside the warning.
Since these new notes describe clearly the constraint, there is no need
to provide the number of the argument (e.g. 'Arg3') within the warning.
However, I decided to keep the name of the constraint in the warning (but
this could be a subject of discussion) in order to be able to identify
the different kind of constraint violations easily in a bug database
(e.g. CodeChecker).

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

Added: 
clang/test/Analysis/std-c-library-functions-arg-constraints-notes.cpp

Modified: 
clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
clang/test/Analysis/std-c-library-functions-arg-constraints.c
clang/test/Analysis/std-c-library-functions-arg-constraints.cpp

Removed: 




diff  --git a/clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp 
b/clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
index cbb45347a6afe..a2409b028fb0c 100644
--- a/clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
+++ b/clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
@@ -57,6 +57,10 @@
 #include "clang/StaticAnalyzer/Core/PathSensitive/CheckerContext.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/CheckerHelpers.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/DynamicExtent.h"
+#include "llvm/ADT/SmallString.h"
+#include "llvm/ADT/StringExtras.h"
+
+#include 
 
 using namespace clang;
 using namespace clang::ento;
@@ -87,6 +91,10 @@ class StdLibraryFunctionsChecker
   typedef uint32_t ArgNo;
   static const ArgNo Ret;
 
+  /// Returns the string representation of an argument index.
+  /// E.g.: (1) -> '1st arg', (2) - > '2nd arg'
+  static SmallString<8> getArgDesc(ArgNo);
+
   class ValueConstraint;
 
   // Pointer to the ValueConstraint. We need a copyable, polymorphic and
@@ -128,6 +136,16 @@ class StdLibraryFunctionsChecker
 
 virtual StringRef getName() const = 0;
 
+// Give a description that explains the constraint to the user. Used when
+// the bug is reported.
+virtual std::string describe(ProgramStateRef State,
+ const Summary &Summary) const {
+  // There are some descendant classes that are not used as argument
+  // constraints, e.g. ComparisonConstraint. In that case we can safely
+  // ignore the implementation of this function.
+  llvm_unreachable("Not implemented");
+}
+
   protected:
 ArgNo ArgN; // Argument to which we apply the constraint.
 
@@ -158,6 +176,9 @@ class StdLibraryFunctionsChecker
 RangeConstraint(ArgNo ArgN, RangeKind Kind, const IntRangeVector &Ranges)
 : ValueConstraint(ArgN), Kind(Kind), Ranges(Ranges) {}
 
+std::string describe(ProgramStateRef State,
+ const Summary &Summary) const override;
+
 const IntRangeVector &getRanges() const { return Ranges; }
 
   private:
@@ -225,6 +246,8 @@ class StdLibraryFunctionsChecker
 bool CannotBeNull = true;
 
   public:
+std::string describe(ProgramStateRef State,
+ const Summary &Summary) const override;
 StringRef getName() const override { return "NonNull"; }
 ProgramStateRef apply(ProgramStateRef State, const CallEvent &Call,
   const Summary &Summary,
@@ -286,6 +309,9 @@ class StdLibraryFunctionsChecker
 : ValueConstraint(Buffer), SizeArgN(BufSize),
   SizeMultiplierArgN(BufSizeMultiplier) {}
 
+std::string describe(ProgramStateRef State,
+ const Summary &Summary) const override;
+
 ProgramStateRef apply(ProgramStateRef State, const CallEvent &Call,
   const Summary &Summary,
   CheckerContext &C) const override {
@@ -297,20 +323,18 @@ class StdLibraryFunctionsChecker
   const SVal SizeV = [this, &State, &Call, &Summary, &SvalBuilder]() {
 if (ConcreteSize) {
   return SVal(SvalBuilder.makeIntVal(*ConcreteSize));
-} else if (SizeArgN) {
-  // The size argument.
-  SVal SizeV = getArgSVal(Call, *SizeArgN);
-  // Multiply with another argument if given.
-  if (SizeMultiplierArgN) {
-SVal SizeMulV = getArgSVal(Call, *SizeMultiplierArgN);
-SizeV = SvalBuilder.evalBinOp(State, BO_Mul, SizeV, SizeMulV,
-  Summary.getArgType

[PATCH] D101060: [Analyzer][StdLibraryFunctionsChecker] Describe arg constraints

2021-04-23 Thread Gabor Marton via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGa7cb951fa40d: [Analyzer][StdLibraryFunctionsChecker] 
Describe arg constraints (authored by martong).

Changed prior to commit:
  https://reviews.llvm.org/D101060?vs=33&id=340048#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101060

Files:
  clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
  clang/test/Analysis/std-c-library-functions-arg-constraints-notes.cpp
  clang/test/Analysis/std-c-library-functions-arg-constraints.c
  clang/test/Analysis/std-c-library-functions-arg-constraints.cpp

Index: clang/test/Analysis/std-c-library-functions-arg-constraints.cpp
===
--- clang/test/Analysis/std-c-library-functions-arg-constraints.cpp
+++ clang/test/Analysis/std-c-library-functions-arg-constraints.cpp
@@ -14,5 +14,6 @@
 
 void test_arg_constraint_on_fun_with_default_param() {
   __defaultparam(nullptr); // \
-  // expected-warning{{Function argument constraint is not satisfied}}
+  // expected-warning{{Function argument constraint is not satisfied}} \
+  // expected-note{{}}
 }
Index: clang/test/Analysis/std-c-library-functions-arg-constraints.c
===
--- clang/test/Analysis/std-c-library-functions-arg-constraints.c
+++ clang/test/Analysis/std-c-library-functions-arg-constraints.c
@@ -30,7 +30,9 @@
 void test_alnum_concrete(int v) {
   int ret = isalnum(256); // \
   // report-warning{{Function argument constraint is not satisfied}} \
+  // report-note{{}} \
   // bugpath-warning{{Function argument constraint is not satisfied}} \
+  // bugpath-note{{}} \
   // bugpath-note{{Function argument constraint is not satisfied}}
   (void)ret;
 }
@@ -54,7 +56,9 @@
 
 int ret = isalnum(x); // \
 // report-warning{{Function argument constraint is not satisfied}} \
+// report-note{{}} \
 // bugpath-warning{{Function argument constraint is not satisfied}} \
+// bugpath-note{{}} \
 // bugpath-note{{Function argument constraint is not satisfied}}
 
 (void)ret;
@@ -66,7 +70,9 @@
 void test_toupper_concrete(int v) {
   int ret = toupper(256); // \
   // report-warning{{Function argument constraint is not satisfied}} \
+  // report-note{{}} \
   // bugpath-warning{{Function argument constraint is not satisfied}} \
+  // bugpath-note{{}} \
   // bugpath-note{{Function argument constraint is not satisfied}}
   (void)ret;
 }
@@ -90,7 +96,9 @@
 
 int ret = toupper(x); // \
 // report-warning{{Function argument constraint is not satisfied}} \
+// report-note{{}} \
 // bugpath-warning{{Function argument constraint is not satisfied}} \
+// bugpath-note{{}} \
 // bugpath-note{{Function argument constraint is not satisfied}}
 
 (void)ret;
@@ -102,7 +110,9 @@
 void test_tolower_concrete(int v) {
   int ret = tolower(256); // \
   // report-warning{{Function argument constraint is not satisfied}} \
+  // report-note{{}} \
   // bugpath-warning{{Function argument constraint is not satisfied}} \
+  // bugpath-note{{}} \
   // bugpath-note{{Function argument constraint is not satisfied}}
   (void)ret;
 }
@@ -126,7 +136,9 @@
 
 int ret = tolower(x); // \
 // report-warning{{Function argument constraint is not satisfied}} \
+// report-note{{}} \
 // bugpath-warning{{Function argument constraint is not satisfied}} \
+// bugpath-note{{}} \
 // bugpath-note{{Function argument constraint is not satisfied}}
 
 (void)ret;
@@ -138,7 +150,9 @@
 void test_toascii_concrete(int v) {
   int ret = toascii(256); // \
   // report-warning{{Function argument constraint is not satisfied}} \
+  // report-note{{}} \
   // bugpath-warning{{Function argument constraint is not satisfied}} \
+  // bugpath-note{{}} \
   // bugpath-note{{Function argument constraint is not satisfied}}
   (void)ret;
 }
@@ -162,7 +176,9 @@
 
 int ret = toascii(x); // \
 // report-warning{{Function argument constraint is not satisfied}} \
+// report-note{{}} \
 // bugpath-warning{{Function argument constraint is not satisfied}} \
+// bugpath-note{{}} \
 // bugpath-note{{Function argument constraint is not satisfied}}
 
 (void)ret;
@@ -175,7 +191,9 @@
 void test_notnull_concrete(FILE *fp) {
   fread(0, sizeof(int), 10, fp); // \
   // report-warning{{Function argument constraint is not satisfied}} \
+  // report-note{{}} \
   // bugpath-warning{{Function argument constraint is not satisfied}} \
+  // bugpath-note{{}} \
   // bugpath-note{{Function argument constraint is not satisfied}}
 }
 void test_notnull_symbolic(FILE *fp, int *buf) {
@@ -191,7 +209,9 @@
 // bugpath-note{{Taking true branch}}
 fread(buf, sizeof(int), 10, fp); // \
 // report-warning{{Function argument constraint is not satisfied}} \
+// report-note{{}} \
 // b

[PATCH] D101049: [AST] Add DeclarationNameInfo to node introspection

2021-04-23 Thread Stephen Kelly via Phabricator via cfe-commits
steveire updated this revision to Diff 340049.
steveire added a comment.

Update


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101049

Files:
  clang/include/clang/Tooling/NodeIntrospection.h
  clang/lib/Tooling/DumpTool/APIData.h
  clang/lib/Tooling/DumpTool/ASTSrcLocProcessor.cpp
  clang/lib/Tooling/DumpTool/generate_cxx_src_locs.py
  clang/lib/Tooling/EmptyNodeIntrospection.inc.in
  clang/unittests/Introspection/IntrospectionTest.cpp

Index: clang/unittests/Introspection/IntrospectionTest.cpp
===
--- clang/unittests/Introspection/IntrospectionTest.cpp
+++ clang/unittests/Introspection/IntrospectionTest.cpp
@@ -216,6 +216,9 @@
 STRING_LOCATION_STDPAIR(MethodDecl, getEndLoc()),
 STRING_LOCATION_STDPAIR(MethodDecl, getInnerLocStart()),
 STRING_LOCATION_STDPAIR(MethodDecl, getLocation()),
+STRING_LOCATION_STDPAIR(MethodDecl, getNameInfo().getBeginLoc()),
+STRING_LOCATION_STDPAIR(MethodDecl, getNameInfo().getEndLoc()),
+STRING_LOCATION_STDPAIR(MethodDecl, getNameInfo().getLoc()),
 STRING_LOCATION_STDPAIR(MethodDecl, getOuterLocStart()),
 STRING_LOCATION_STDPAIR(MethodDecl, getQualifierLoc().getBeginLoc()),
 STRING_LOCATION_STDPAIR(MethodDecl, getQualifierLoc().getEndLoc()),
@@ -305,6 +308,7 @@
 llvm::makeArrayRef(ExpectedRanges),
   (ArrayRef>{
 STRING_LOCATION_STDPAIR(MethodDecl, getExceptionSpecSourceRange()),
+STRING_LOCATION_STDPAIR(MethodDecl, getNameInfo().getSourceRange()),
 STRING_LOCATION_STDPAIR(MethodDecl, getParametersSourceRange()),
 STRING_LOCATION_STDPAIR(MethodDecl, getQualifierLoc().getLocalSourceRange()),
 STRING_LOCATION_STDPAIR(MethodDecl, getQualifierLoc().getPrefix().getLocalSourceRange()),
@@ -1395,3 +1399,142 @@
   TL, getAs().getParensRange(;
 }
 #endif
+
+TEST(Introspection, SourceLocations_DeclarationNameInfo_Dtor) {
+  if (!NodeIntrospection::hasIntrospectionSupport())
+return;
+  auto AST =
+  buildASTFromCode(R"cpp(
+class Foo
+{
+  ~Foo() {}
+};
+)cpp",
+   "foo.cpp", std::make_shared());
+  auto &Ctx = AST->getASTContext();
+  auto &TU = *Ctx.getTranslationUnitDecl();
+
+  auto BoundNodes = ast_matchers::match(
+  decl(hasDescendant(cxxDestructorDecl(hasName("~Foo")).bind("dtor"))), TU,
+  Ctx);
+
+  EXPECT_EQ(BoundNodes.size(), 1u);
+
+  const auto *Dtor = BoundNodes[0].getNodeAs("dtor");
+  auto NI = Dtor->getNameInfo();
+  auto Result = NodeIntrospection::GetLocations(NI);
+
+  auto ExpectedLocations =
+  FormatExpected(Result.LocationAccessors);
+
+  llvm::sort(ExpectedLocations);
+
+  // clang-format off
+  EXPECT_EQ(
+  llvm::makeArrayRef(ExpectedLocations),
+  (ArrayRef>{
+  STRING_LOCATION_STDPAIR((&NI), getBeginLoc()),
+  STRING_LOCATION_STDPAIR((&NI), getEndLoc()),
+  STRING_LOCATION_STDPAIR((&NI), getLoc()),
+  STRING_LOCATION_STDPAIR((&NI),
+getNamedTypeInfo()->getTypeLoc().getAs().getNameLoc()),
+  STRING_LOCATION_STDPAIR(
+  (&NI), getNamedTypeInfo()->getTypeLoc().getBeginLoc()),
+  STRING_LOCATION_STDPAIR(
+  (&NI), getNamedTypeInfo()->getTypeLoc().getEndLoc())}));
+  // clang-format on
+
+  auto ExpectedRanges = FormatExpected(Result.RangeAccessors);
+
+  EXPECT_THAT(
+  ExpectedRanges,
+  UnorderedElementsAre(
+  STRING_LOCATION_PAIR(
+  (&NI), getNamedTypeInfo()->getTypeLoc().getLocalSourceRange()),
+  STRING_LOCATION_PAIR(
+  (&NI), getNamedTypeInfo()->getTypeLoc().getSourceRange()),
+  STRING_LOCATION_PAIR((&NI), getSourceRange(;
+}
+
+TEST(Introspection, SourceLocations_DeclarationNameInfo_ConvOp) {
+  if (!NodeIntrospection::hasIntrospectionSupport())
+return;
+  auto AST =
+  buildASTFromCode(R"cpp(
+class Foo
+{
+  bool operator==(const Foo&) const { return false; }
+};
+)cpp",
+   "foo.cpp", std::make_shared());
+  auto &Ctx = AST->getASTContext();
+  auto &TU = *Ctx.getTranslationUnitDecl();
+
+  auto BoundNodes = ast_matchers::match(
+  decl(hasDescendant(cxxMethodDecl().bind("opeq"))), TU, Ctx);
+
+  EXPECT_EQ(BoundNodes.size(), 1u);
+
+  const auto *Opeq = BoundNodes[0].getNodeAs("opeq");
+  auto NI = Opeq->getNameInfo();
+  auto Result = NodeIntrospection::GetLocations(NI);
+
+  auto ExpectedLocations =
+  FormatExpected(Result.LocationAccessors);
+
+  llvm::sort(ExpectedLocations);
+
+  EXPECT_EQ(llvm::makeArrayRef(ExpectedLocations),
+(ArrayRef>{
+STRING_LOCATION_STDPAIR((&NI), getBeginLoc()),
+STRING_LOCATION_STDPAIR((&NI), getEndLoc()),
+STRING_LOCATION_STDPAIR((&NI), getLoc())}));
+
+  auto ExpectedRanges = FormatExpected(Result.RangeAccessors);
+
+  EXPECT_THAT(ExpectedRanges,
+  UnorderedElementsAre(
+  STRING_LOCATION_PAIR((&NI), getSourceRange()),
+   

[PATCH] D101166: This commit tries to revert Clang commit 40beb1f84a to see if that's the cause of failures in the Runtimes build.

2021-04-23 Thread Louis Dionne via Phabricator via cfe-commits
ldionne updated this revision to Diff 340050.
ldionne added a comment.

Try running a full bisect


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101166

Files:
  libcxx/utils/ci/buildkite-pipeline.yml
  libcxx/utils/ci/do-bisect

Index: libcxx/utils/ci/do-bisect
===
--- /dev/null
+++ libcxx/utils/ci/do-bisect
@@ -0,0 +1,18 @@
+#!/usr/bin/env bash
+#===--===##
+#
+# 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
+#
+#===--===##
+
+set -ex
+set -o pipefail
+
+MONOREPO_ROOT="$(git rev-parse --show-toplevel)"
+
+git bisect start
+git bisect bad
+git bisect good 167da6c9e826b9befc27b6f5a6c540f7f28b7d5a
+git bisect run "${MONOREPO_ROOT}/libcxx/utils/ci/run-buildbot" runtimes-build
Index: libcxx/utils/ci/buildkite-pipeline.yml
===
--- libcxx/utils/ci/buildkite-pipeline.yml
+++ libcxx/utils/ci/buildkite-pipeline.yml
@@ -18,285 +18,8 @@
 #
 
 steps:
-  #
-  # Light pre-commit tests for things like formatting or when people forget
-  # to update generated files.
-  #
-  - label: "Format"
-command: "libcxx/utils/ci/run-buildbot check-format"
-artifact_paths:
-  - "**/clang-format.patch"
-agents:
-  queue: "libcxx-builders"
-retry:
-  automatic:
-- exit_status: -1  # Agent was lost
-  limit: 2
-soft_fail:
-- exit_status: 1
-
-  - label: "Generated output"
-command: "libcxx/utils/ci/run-buildbot check-generated-output"
-artifact_paths:
-  - "**/generated_output.patch"
-agents:
-  queue: "libcxx-builders"
-retry:
-  automatic:
-- exit_status: -1  # Agent was lost
-  limit: 2
-
-  #
-  # General testing with the default configuration, under all the supported
-  # Standard modes, with Clang and GCC. This catches most issues upfront.
-  # The goal of this step is to catch most issues while being very fast.
-  #
-  - wait
-
-  - label: "C++03"
-command: "libcxx/utils/ci/run-buildbot generic-cxx03"
-artifact_paths:
-  - "**/test-results.xml"
-  - "**/*.abilist"
-agents:
-  queue: "libcxx-builders"
-retry:
-  automatic:
-- exit_status: -1  # Agent was lost
-  limit: 2
-
-  - label: "C++11"
-command: "libcxx/utils/ci/run-buildbot generic-cxx11"
-artifact_paths:
-  - "**/test-results.xml"
-  - "**/*.abilist"
-agents:
-  queue: "libcxx-builders"
-retry:
-  automatic:
-- exit_status: -1  # Agent was lost
-  limit: 2
-
-  - label: "C++14"
-command: "libcxx/utils/ci/run-buildbot generic-cxx14"
-artifact_paths:
-  - "**/test-results.xml"
-  - "**/*.abilist"
-agents:
-  queue: "libcxx-builders"
-retry:
-  automatic:
-- exit_status: -1  # Agent was lost
-  limit: 2
-
-  - label: "C++17"
-command: "libcxx/utils/ci/run-buildbot generic-cxx17"
-artifact_paths:
-  - "**/test-results.xml"
-  - "**/*.abilist"
-agents:
-  queue: "libcxx-builders"
-retry:
-  automatic:
-- exit_status: -1  # Agent was lost
-  limit: 2
-
-  - label: "C++20"
-command: "libcxx/utils/ci/run-buildbot generic-cxx20"
-artifact_paths:
-  - "**/test-results.xml"
-  - "**/*.abilist"
-agents:
-  queue: "libcxx-builders"
-retry:
-  automatic:
-- exit_status: -1  # Agent was lost
-  limit: 2
-
-  - label: "C++2b"
-command: "libcxx/utils/ci/run-buildbot generic-cxx2b"
-artifact_paths:
-  - "**/test-results.xml"
-  - "**/*.abilist"
-agents:
-  queue: "libcxx-builders"
-retry:
-  automatic:
-- exit_status: -1  # Agent was lost
-  limit: 2
-
-  - label: "GCC/C++20"
-command: "libcxx/utils/ci/run-buildbot generic-gcc"
-artifact_paths:
-  - "**/test-results.xml"
-agents:
-  queue: "libcxx-builders"
-retry:
-  automatic:
-- exit_status: -1  # Agent was lost
-  limit: 2
-
-  #
-  # All other supported configurations of libc++.
-  #
-  - wait
-
-  - label: "-fno-exceptions"
-command: "libcxx/utils/ci/run-buildbot generic-noexceptions"
-artifact_paths:
-  - "**/test-results.xml"
-agents:
-  queue: "libcxx-builders"
-retry:
-  automatic:
-- exit_status: -1  # Agent was lost
-  limit: 2
-
-  - label: "Static libraries"
-command: "libcxx/utils/ci/run-buildbot generic-static"
-artifact_paths:
-  - "**/test-results.xml"
-agents:
-  queue: "libcxx-builders"
-retry:
-  automatic:
-- exit_status:

[PATCH] D101041: [analyzer] Find better description for tracked symbolic values

2021-04-23 Thread Valeriy Savchenko via Phabricator via cfe-commits
vsavchenko added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp:1532
+  // Telling the user that the value of 'a' is assigned to 'c', while
+  // correct, can be confusing.
+  StoreManager::FindUniqueBinding FB(V.getAsLocSymbol());

martong wrote:
> vsavchenko wrote:
> > martong wrote:
> > > So here, we have two or three bindings attached to `c`? `foo(b)` and `a` 
> > > (and `b` as well) ?
> > > What is the guarantee that `FindUniqueBinding` will return with the 
> > > correct one `foo(b)`? Seems like we iterate through an ImmutableMap (AVL 
> > > tree) with `MemRegion*` keys. And the order of the iteration depends on 
> > > pointer values. What I want to express, is that I don't see how do we 
> > > find the correct binding, seems like we just find one, which might be the 
> > > one we look for if we are lucky.
> > > 
> > > Perhaps we could have a lit test for this example?
> > Good idea, I should a test for that!
> > `FindUniqueBinding` does not only have a region, it also carries a flag 
> > checking if there are more than one binding.  `operator bool` then checks 
> > for both, thus guaranteeing that we won't choose random binding out of more 
> > than 1 - we won't choose at all.
> Yeah, I missed that about `FindUniqueBinding`. 
> 
> It's just side questions then: Could we handle multiple bindings by finding 
> the 'last' binding and tracking that back?
> And in this example, what are the bindings for `c`?
Can you please elaborate on what you mean by 'last', like 'last used'?
As for `c`, you can see above that I'm looking for a node where 'c' is not 
bound to that value.  So, we start with the node where 'a', 'b', and 'c' all 
bound to symbolic value... let's say 'x'. I go up the graph to the point where 
'c' is not bound to 'x' and there I look for unique binding for 'x'.  In that 
example, we won't find it because it has two: 'a' and 'b'.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101041

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


[PATCH] D93325: Add srcloc output to clang-query

2021-04-23 Thread Nathan James via Phabricator via cfe-commits
njames93 added inline comments.



Comment at: clang-tools-extra/clang-query/Query.cpp:106-108
+  if (Scout->first == CommonEntry) {
+++Iter;
+  }

nit: Elide braces.



Comment at: clang-tools-extra/clang-query/Query.cpp:122
+
+TextDiagnostic TD(OS, Ctx.getLangOpts(), &Diags.getDiagnosticOptions());
+TD.emitDiagnostic(FullSourceLoc(Iter->first, SM), DiagnosticsEngine::Note,

Can this be brought out the loop and re-used for each of the 3 loops?



Comment at: clang-tools-extra/clang-query/QueryParser.cpp:128
+  case OK_SrcLoc:
+return new QueryType(&QuerySession::SrcLocOutput);
   }

Can worry about detecting Introspection support in a follow-up


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93325

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


[PATCH] D91949: [clang-format] Add BeforeStructInitialization option in BraceWrapping configuration

2021-04-23 Thread Björn Schäpers via Phabricator via cfe-commits
HazardyKnusperkeks requested changes to this revision.
HazardyKnusperkeks added a comment.
This revision now requires changes to proceed.

Looks okay for me, but please fix the formatting notes.


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

https://reviews.llvm.org/D91949

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


[PATCH] D99949: [AMDGPU][OpenMP] Add amdgpu-arch tool to list AMD GPUs installed

2021-04-23 Thread Jon Chesterfield via Phabricator via cfe-commits
JonChesterfield added a comment.

None of those include paths look like the result of find_package locating a hsa 
so I'd guess this some quirk of cmake. It seems it is setting 
hsa-runtime64_FOUND but not doing the include path setup to match. I don't know 
how to debug that. @pdhaliwal?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99949

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


[PATCH] D91950: [clang-format] Add BreakBeforeInlineASMColon configuration

2021-04-23 Thread Björn Schäpers via Phabricator via cfe-commits
HazardyKnusperkeks accepted this revision.
HazardyKnusperkeks added a comment.

LGTM but please wait for @MyDeveloperDay opinion.


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

https://reviews.llvm.org/D91950

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


[PATCH] D101087: [OpenCL] Introduce new method for validating OpenCL target

2021-04-23 Thread Anton Zabaznov via Phabricator via cfe-commits
azabaznov updated this revision to Diff 340053.
azabaznov added a comment.

Use `LangOptions::getOpenCLVersionTuple()` to provide diagnostics of OpenCL 
version


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101087

Files:
  clang/include/clang/Basic/DiagnosticCommonKinds.td
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/include/clang/Basic/OpenCLOptions.h
  clang/include/clang/Basic/TargetInfo.h
  clang/lib/Basic/OpenCLOptions.cpp
  clang/lib/Basic/Targets.cpp
  clang/lib/Basic/Targets/X86.cpp
  clang/lib/Frontend/CompilerInstance.cpp
  clang/lib/Frontend/InitPreprocessor.cpp
  clang/test/Misc/nvptx.unsupported_core.cl
  clang/test/Misc/r600.unsupported_core.cl

Index: clang/test/Misc/r600.unsupported_core.cl
===
--- /dev/null
+++ clang/test/Misc/r600.unsupported_core.cl
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -cl-std=CL2.0 -triple r600-unknown-unknown -Wpedantic-core-features %s 2> %t
+// RUN: FileCheck < %t %s
+
+// CHECK: cl_khr_byte_addressable_store is a core feature in OpenCL C version 2.0 but not supported on this target
+// CHECK: cl_khr_global_int32_base_atomics is a core feature in OpenCL C version 2.0 but not supported on this target
+// CHECK: cl_khr_global_int32_extended_atomics is a core feature in OpenCL C version 2.0 but not supported on this target
+// CHECK: cl_khr_local_int32_base_atomics is a core feature in OpenCL C version 2.0 but not supported on this target
+// CHECK: cl_khr_local_int32_extended_atomics is a core feature in OpenCL C version 2.0 but not supported on this target
+// CHECK: cl_khr_3d_image_writes is a core feature in OpenCL C version 2.0 but not supported on this target
Index: clang/test/Misc/nvptx.unsupported_core.cl
===
--- /dev/null
+++ clang/test/Misc/nvptx.unsupported_core.cl
@@ -0,0 +1,4 @@
+// RUN: %clang_cc1 -cl-std=CL2.0 -triple nvptx-unknown-unknown -Wpedantic-core-features %s 2> %t
+// RUN: FileCheck < %t %s
+
+// CHECK: cl_khr_3d_image_writes is a core feature in OpenCL C version 2.0 but not supported on this target
Index: clang/lib/Frontend/InitPreprocessor.cpp
===
--- clang/lib/Frontend/InitPreprocessor.cpp
+++ clang/lib/Frontend/InitPreprocessor.cpp
@@ -601,6 +601,29 @@
 Builder.defineMacro("__cpp_coroutines", "201703L");
 }
 
+/// InitializeOpenCLFeatureTestMacros - Define OpenCL macros based on target
+/// settings and language version
+void InitializeOpenCLFeatureTestMacros(const TargetInfo &TI,
+   const LangOptions &Opts,
+   MacroBuilder &Builder) {
+  const llvm::StringMap &OpenCLFeaturesMap = TI.getSupportedOpenCLOpts();
+  // FIXME: OpenCL options which affect language semantics/syntax
+  // should be moved into LangOptions.
+  auto defineOpenCLExtMacro = [&](llvm::StringRef Name, auto... OptArgs) {
+// Check if extension is supported by target and is available in this
+// OpenCL version
+if (TI.hasFeatureEnabled(OpenCLFeaturesMap, Name) &&
+OpenCLOptions::isOpenCLOptionAvailableIn(Opts, OptArgs...))
+  Builder.defineMacro(Name);
+  };
+#define OPENCL_GENERIC_EXTENSION(Ext, ...) \
+  defineOpenCLExtMacro(#Ext, __VA_ARGS__);
+#include "clang/Basic/OpenCLExtensions.def"
+
+  // Assume compiling for FULL profile
+  Builder.defineMacro("__opencl_c_int64");
+}
+
 static void InitializePredefinedMacros(const TargetInfo &TI,
const LangOptions &LangOpts,
const FrontendOptions &FEOpts,
@@ -1138,7 +1161,7 @@
 
   // OpenCL definitions.
   if (LangOpts.OpenCL) {
-TI.getOpenCLFeatureDefines(LangOpts, Builder);
+InitializeOpenCLFeatureTestMacros(TI, LangOpts, Builder);
 
 if (TI.getTriple().isSPIR())
   Builder.defineMacro("__IMAGE_SUPPORT__");
Index: clang/lib/Frontend/CompilerInstance.cpp
===
--- clang/lib/Frontend/CompilerInstance.cpp
+++ clang/lib/Frontend/CompilerInstance.cpp
@@ -133,6 +133,11 @@
 // FIXME: can we disable FEnvAccess?
   }
 
+  // We should do it here because target knows nothing about
+  // language options when it's being created.
+  if (getLangOpts().OpenCL)
+getTarget().validateOpenCLTarget(getLangOpts(), getDiagnostics());
+
   // Inform the target of the language options.
   // FIXME: We shouldn't need to do this, the target should be immutable once
   // created. This complexity should be lifted elsewhere.
Index: clang/lib/Basic/Targets/X86.cpp
===
--- clang/lib/Basic/Targets/X86.cpp
+++ clang/lib/Basic/Targets/X86.cpp
@@ -1398,13 +1398,13

[PATCH] D79714: [Diagnostics] Restore -Wdeprecated warning when user-declared copy assignment operator is defined as deleted (PR45634)

2021-04-23 Thread Dávid Bolvanský via Phabricator via cfe-commits
xbolva00 added a comment.

In D79714#2712393 , @uabelho wrote:

> In D79714#2711898 , @xbolva00 wrote:
>
>> Can you try this fix?
>>
>>   diff --git a/libcxx/utils/libcxx/test/params.py 
>> b/libcxx/utils/libcxx/test/params.py
>>   index ddf277dea246..abf712e78a61 100644
>>   --- a/libcxx/utils/libcxx/test/params.py
>>   +++ b/libcxx/utils/libcxx/test/params.py
>>   @@ -12,6 +12,7 @@ from libcxx.test.features import _isMSVC
>>_warningFlags = [
>>  '-Werror',
>>  '-Wall',
>>   +  '-Wno-deprecated-copy',
>>  '-Wextra',
>>  '-Wshadow',
>>  '-Wundef',
>
> The above doesn't help but if I add it in the list after -Wextra the warning 
> goes away. Can you submit something like that?
> Thanks!

Yes, I can. Thanks


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79714

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


[PATCH] D101087: [OpenCL] Introduce new method for validating OpenCL target

2021-04-23 Thread Anton Zabaznov via Phabricator via cfe-commits
azabaznov added inline comments.



Comment at: clang/include/clang/Basic/OpenCLOptions.h:179
+  static bool isOpenCLOptionCoreIn(const LangOptions &LO, Args &&... args) {
+return OpenCLOptionInfo(std::forward(args)...).isCoreIn(LO);
+  }

Anastasia wrote:
> Do you think we could avoid constructing the temporary objects somehow?
> 
> I.e. could we just check the condition `CLVer >= Avail` that is used in the 
> non-static member function directly?
> 
> We could then use these helpers in the non-static members perhaps to avoid 
> duplication.
In future I would like to have a file scope variable to to something like:

```
extern llvm::StringMap OpenCLOptionsKV = {
#include "OpenCLExtensions.inc"
};
```

where `OpenCLExtensions.inc` will be generated from TableGen file. This 
file-scope variable will be initialized once and contain all the information 
about OpenCL options. As for now I think using variadics and creating a 
temporary variable is much more simple than obtaining a full list of arguments 
and choosing the proper one to call `CLVer >= Avail` and even for checking core 
:)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101087

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


[PATCH] D101030: [OpenMP] Overhaul `declare target` handling

2021-04-23 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert added inline comments.



Comment at: clang/lib/Parse/ParseOpenMP.cpp:2134-2151
+Sema::DeclareTargetContextInfo *DTCI =
+new Sema::DeclareTargetContextInfo(DKind, DTLoc);
+if (HasClauses)
+  ParseOMPDeclareTargetClauses(*DTCI);
 
 // Skip the last annot_pragma_openmp_end.
 ConsumeAnyToken();

ABataev wrote:
> jdoerfert wrote:
> > ABataev wrote:
> > > Add a RAII to control these new/delete or just create local var
> > Local variable and RAII do not always work, there is a delete in the 
> > `end_declare_target` below as well.
> > 
> > 
> But here you have new/delete pair within a single block. Either you can put 
> the ar into stack/RAII or some extra checks are missing. Maybe must be 
> something like this:
> ```
> if (DKind == OMPD_declare_target)
>   delete DTCI;
> ```
> ?
If this is a directive without implicit mappings, the DTCI will be deleted 
right away. It is just used to collect the clauses (which include explicit 
mappings). If this is a directive with implicit mappings, which we cannot tell 
from the DKind alone, the DTCI will be stored in Sema until we reach the 
corresponding end directive. For the former case we could do stack/RAII, but 
not for the latter case, the scope is left and DTCI survives. I'll look into 
this again and try to avoid new/delete, feel free to look at the rest of the 
patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101030

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


[PATCH] D93325: Add srcloc output to clang-query

2021-04-23 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman accepted this revision.
aaron.ballman added a comment.
This revision is now accepted and ready to land.

LGTM aside from the nits from @njames93 and I.




Comment at: clang-tools-extra/clang-query/Query.cpp:96
+
+  auto printLocations = [](auto &OS, auto Iter, auto End) {
+auto CommonEntry = Iter->first;




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93325

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


  1   2   3   >