[PATCH] D118322: [clangd] Fix a selection tree crash for unmatched-bracket code.

[Sam McCall via Phabricator via cfe-commits]

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

Wow, nice find!

I'd argue the bug is probably rather in 
`TokenBuffer::expandedTokens(SourceRange)` that produced this span. The idea 
that it might *rarely* include the EOF token seems like a magnet for bugs like 
these.

(Of course it's a special case of a more general "recovery location points at 
an unrelated token" problem)...

Even if we want to fix it in TokenBuffer, doing it right before the release cut 
might be risky. So:

- fix it here
- or fix it in TokenBuffer
- or fix it here and then change after the branch cut

I'm happy with any of these options, up to you.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118322

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

[PATCH] D116638: [clang-format] Fix ignoring JavaScriptWrapImport when ColumnWidth: 0

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added a comment.

please mark your review comments as done when done so we know its a complete 
review


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

https://reviews.llvm.org/D116638

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

[PATCH] D118224: [clang-tidy] bugprone-signal-handler improvements: display call chain

[Balázs Kéri via Phabricator via cfe-commits]

balazske updated this revision to Diff 403528.
balazske marked an inline comment as done.
balazske added a comment.

Added assert, added test with function pointer, improved text message 
generation.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118224

Files:
  clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.h
  clang-tools-extra/test/clang-tidy/checkers/bugprone-signal-handler.c

Index: clang-tools-extra/test/clang-tidy/checkers/bugprone-signal-handler.c
===
--- clang-tools-extra/test/clang-tidy/checkers/bugprone-signal-handler.c
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone-signal-handler.c
@@ -13,62 +13,121 @@
 typedef void (*sighandler_t)(int);
 sighandler_t signal(int signum, sighandler_t handler);
 
-void handler_abort(int) {
-  abort();
-}
+void f_extern();
 
-void handler_other(int) {
+void handler_printf(int) {
   printf("1234");
-  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: 'printf' may not be asynchronous-safe; calling it from a signal handler may be dangerous [bugprone-signal-handler]
+  // CHECK-NOTES: :[[@LINE-1]]:3: warning: 'printf' may not be asynchronous-safe; calling it from a signal handler may be dangerous [bugprone-signal-handler]
+  // CHECK-NOTES: :[[@LINE-2]]:3: note: function 'printf' called here from 'handler_printf'
+  // CHECK-NOTES: :[[@LINE+4]]:18: note: function 'handler_printf' registered here as signal handler
 }
 
-void handler_signal(int) {
-  // FIXME: It is only OK to call signal with the current signal number.
-  signal(0, SIG_DFL);
+void test_printf() {
+  signal(SIGINT, handler_printf);
 }
 
-void f_ok() {
-  abort();
+void handler_extern(int) {
+  f_extern();
+  // CHECK-NOTES: :[[@LINE-1]]:3: warning: 'f_extern' may not be asynchronous-safe; calling it from a signal handler may be dangerous [bugprone-signal-handler]
+  // CHECK-NOTES: :[[@LINE-2]]:3: note: function 'f_extern' called here from 'handler_extern'
+  // CHECK-NOTES: :[[@LINE+4]]:18: note: function 'handler_extern' registered here as signal handler
 }
 
-void f_bad() {
-  printf("1234");
-  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: 'printf' may not be asynchronous-safe; calling it from a signal handler may be dangerous [bugprone-signal-handler]
+void test_extern() {
+  signal(SIGINT, handler_extern);
 }
 
-void f_extern();
+void f_ok() {
+  abort();
+}
 
 void handler_ok(int) {
   f_ok();
 }
 
+void test_ok() {
+  signal(SIGINT, handler_ok);
+}
+
+void f_bad() {
+  printf("1234");
+  // CHECK-NOTES: :[[@LINE-1]]:3: warning: 'printf' may not be asynchronous-safe; calling it from a signal handler may be dangerous [bugprone-signal-handler]
+  // CHECK-NOTES: :[[@LINE-2]]:3: note: function 'printf' called here from 'f_bad'
+  // CHECK-NOTES: :[[@LINE+5]]:3: note: function 'f_bad' called here from 'handler_bad'
+  // CHECK-NOTES: :[[@LINE+8]]:18: note: function 'handler_bad' registered here as signal handler
+}
+
 void handler_bad(int) {
   f_bad();
 }
 
-void handler_extern(int) {
-  f_extern();
-  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: 'f_extern' may not be asynchronous-safe; calling it from a signal handler may be dangerous [bugprone-signal-handler]
+void test_bad() {
+  signal(SIGINT, handler_bad);
+}
+
+void f_bad1() {
+  printf("1234");
+  // CHECK-NOTES: :[[@LINE-1]]:3: warning: 'printf' may not be asynchronous-safe; calling it from a signal handler may be dangerous [bugprone-signal-handler]
+  // CHECK-NOTES: :[[@LINE-2]]:3: note: function 'printf' called here from 'f_bad1'
+  // CHECK-NOTES: :[[@LINE+6]]:3: note: function 'f_bad1' called here from 'f_bad2'
+  // CHECK-NOTES: :[[@LINE+9]]:3: note: function 'f_bad2' called here from 'handler_bad1'
+  // CHECK-NOTES: :[[@LINE+13]]:18: note: function 'handler_bad1' registered here as signal handler
+}
+
+void f_bad2() {
+  f_bad1();
+}
+
+void handler_bad1(int) {
+  f_bad2();
+  f_bad1();
+}
+
+void test_bad1() {
+  signal(SIGINT, handler_bad1);
 }
 
-void test_false_condition(int) {
+void handler_abort(int) {
+  abort();
+}
+
+void handler_signal(int) {
+  // FIXME: It is only OK to call signal with the current signal number.
+  signal(0, SIG_DFL);
+}
+
+void handler_false_condition(int) {
   if (0)
 printf("1234");
-  // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: 'printf' may not be asynchronous-safe; calling it from a signal handler may be dangerous [bugprone-signal-handler]
+  // CHECK-NOTES: :[[@LINE-1]]:5: warning: 'printf' may not be asynchronous-safe; calling it from a signal handler may be dangerous [bugprone-signal-handler]
+  // CHECK-NOTES: :[[@LINE-2]]:5: note: function 'printf' called here from 'handler_false_condition'
+  // CHECK-NOTES: :[[@LINE+4]]:18: note: function 'handler_false_condition' registered here as signal handler
+}
+
+void test_false_condition() {
+  signal(SIGINT, handler_false_con

[PATCH] D118211: Add missing namespace to PPCLinux.cpp

[Sylvestre Ledru 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 rGfd71493ff060: Add missing namespace to PPCLinux.cpp 
(authored by glandium, committed by sylvestre.ledru).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118211

Files:
  clang/lib/Driver/ToolChains/PPCLinux.cpp


Index: clang/lib/Driver/ToolChains/PPCLinux.cpp
===
--- clang/lib/Driver/ToolChains/PPCLinux.cpp
+++ clang/lib/Driver/ToolChains/PPCLinux.cpp
@@ -13,6 +13,7 @@
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/Path.h"
 
+using namespace clang::driver;
 using namespace clang::driver::toolchains;
 using namespace llvm::opt;
 using namespace llvm::sys;


Index: clang/lib/Driver/ToolChains/PPCLinux.cpp
===
--- clang/lib/Driver/ToolChains/PPCLinux.cpp
+++ clang/lib/Driver/ToolChains/PPCLinux.cpp
@@ -13,6 +13,7 @@
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/Path.h"
 
+using namespace clang::driver;
 using namespace clang::driver::toolchains;
 using namespace llvm::opt;
 using namespace llvm::sys;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] fd71493 - Add missing namespace to PPCLinux.cpp

[Sylvestre Ledru via cfe-commits]

Author: Mike Hommey
Date: 2022-01-27T09:26:46+01:00
New Revision: fd71493ff0602d7d81763263df2f2074fe0db094

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

LOG: Add missing namespace to PPCLinux.cpp

This fixes a build failure with MSVC introduced in
https://reviews.llvm.org/D112906

Reviewed By: nemanjai

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

Added: 


Modified: 
clang/lib/Driver/ToolChains/PPCLinux.cpp

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/PPCLinux.cpp 
b/clang/lib/Driver/ToolChains/PPCLinux.cpp
index e5e1aa06f4b1d..e480d8bd8703c 100644
--- a/clang/lib/Driver/ToolChains/PPCLinux.cpp
+++ b/clang/lib/Driver/ToolChains/PPCLinux.cpp
@@ -13,6 +13,7 @@
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/Path.h"
 
+using namespace clang::driver;
 using namespace clang::driver::toolchains;
 using namespace llvm::opt;
 using namespace llvm::sys;



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

[PATCH] D118169: [NFC][CodeGen] Use llvm::DenseMap for DeferredDecls

[Dawid Jurczak via Phabricator via cfe-commits]

yurai007 added a comment.

Thank you all for review!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118169

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

[PATCH] D112774: Support k-ext clang intrinsics

[Liao Chunyu via Phabricator via cfe-commits]

liaolucy added a comment.
Herald added a subscriber: pcwang-thead.

The scalar crypto v1.0 builtins/intrinsics 
  is still under 
discussion. Maybe we should wait for the final results？


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112774

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

[PATCH] D118313: [Driver] Remove -fno-experimental-new-pass-manager

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

So this just forces you to change `-fno-experimental-new-pass-manager` to 
`-flegacy-pass-manager`? I'm not sure I see the point.

Note that removal of middle-end LegacyPM functionality is currently blocked on 
https://reviews.llvm.org/D98481 landing, which prevents NewPM deployment in the 
Rust ecosystem.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118313

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

[PATCH] D118313: [Driver] Remove -fno-experimental-new-pass-manager

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added a comment.

In D118313#3275059 , @nikic wrote:

> So this just forces you to change `-fno-experimental-new-pass-manager` to 
> `-flegacy-pass-manager`? I'm not sure I see the point.
>
> Note that removal of middle-end LegacyPM functionality is currently blocked 
> on https://reviews.llvm.org/D98481 landing, which prevents NewPM deployment 
> in the Rust ecosystem.

-flegacy-pass-manager is a new option added in 13.0.0. It did not exist in 
older releases.
So by making -fno-experimental-new-pass-manager non-functional, it forces the 
remaining users to migrate.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118313

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

[PATCH] D115634: [clangd] Cleanup of readability-identifier-naming

[Christian Kühnel via Phabricator via cfe-commits]

kuhnel updated this revision to Diff 403538.
kuhnel added a comment.
Herald added a subscriber: aheejin.

Re-created the patch as there were too many changes in the repo.

Excluding gtest Matchers from naming checks as gtest convention does not match
LLVM convention.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115634

Files:
  .clang-tidy
  clang-tools-extra/clangd/ClangdLSPServer.cpp
  clang-tools-extra/clangd/SourceCode.cpp
  clang-tools-extra/clangd/TUScheduler.cpp
  clang-tools-extra/clangd/XRefs.cpp
  clang-tools-extra/clangd/benchmarks/IndexBenchmark.cpp
  clang-tools-extra/clangd/fuzzer/clangd-fuzzer.cpp
  clang-tools-extra/clangd/index/YAMLSerialization.cpp
  clang-tools-extra/clangd/unittests/BackgroundIndexTests.cpp
  clang-tools-extra/clangd/unittests/CallHierarchyTests.cpp
  clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
  clang-tools-extra/clangd/unittests/ConfigYAMLTests.cpp
  clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp
  clang-tools-extra/clangd/unittests/ExpectedTypeTest.cpp
  clang-tools-extra/clangd/unittests/FileIndexTests.cpp
  clang-tools-extra/clangd/unittests/FindSymbolsTests.cpp
  clang-tools-extra/clangd/unittests/HeadersTests.cpp
  clang-tools-extra/clangd/unittests/IndexActionTests.cpp
  clang-tools-extra/clangd/unittests/JSONTransportTests.cpp
  clang-tools-extra/clangd/unittests/QualityTests.cpp
  clang-tools-extra/clangd/unittests/SerializationTests.cpp
  clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp
  clang-tools-extra/clangd/unittests/SymbolInfoTests.cpp
  clang-tools-extra/clangd/unittests/TestIndex.cpp
  clang-tools-extra/clangd/unittests/TypeHierarchyTests.cpp
  clang-tools-extra/clangd/unittests/XRefsTests.cpp
  clang-tools-extra/clangd/unittests/support/ThreadingTests.cpp
  clang-tools-extra/clangd/unittests/support/TraceTests.cpp

Index: clang-tools-extra/clangd/unittests/support/TraceTests.cpp
===
--- clang-tools-extra/clangd/unittests/support/TraceTests.cpp
+++ clang-tools-extra/clangd/unittests/support/TraceTests.cpp
@@ -39,7 +39,7 @@
 
 // Checks that N is a Mapping (JS object) with the expected scalar properties.
 // The object must have all the Expected properties, but may have others.
-bool VerifyObject(llvm::yaml::Node &N,
+bool VerifyObject(llvm::yaml::Node &N, // NOLINT(readability-identifier-naming)
   std::map Expected) {
   auto *M = llvm::dyn_cast(&N);
   if (!M) {
Index: clang-tools-extra/clangd/unittests/support/ThreadingTests.cpp
===
--- clang-tools-extra/clangd/unittests/support/ThreadingTests.cpp
+++ clang-tools-extra/clangd/unittests/support/ThreadingTests.cpp
@@ -29,7 +29,7 @@
   int Counter(0); /* GUARDED_BY(Mutex) */
   {
 AsyncTaskRunner Tasks;
-auto scheduleIncrements = [&]() {
+auto ScheduleIncrements = [&]() {
   for (int TaskI = 0; TaskI < TasksCnt; ++TaskI) {
 Tasks.runAsync("task", [&Counter, &Mutex, IncrementsPerTask]() {
   for (int Increment = 0; Increment < IncrementsPerTask; ++Increment) {
@@ -44,7 +44,7 @@
   // Make sure runAsync is not running tasks synchronously on the same
   // thread by locking the Mutex used for increments.
   std::lock_guard Lock(Mutex);
-  scheduleIncrements();
+  ScheduleIncrements();
 }
 
 Tasks.wait();
@@ -56,7 +56,7 @@
 {
   std::lock_guard Lock(Mutex);
   Counter = 0;
-  scheduleIncrements();
+  ScheduleIncrements();
 }
   }
   // Check that destructor has waited for tasks to finish.
Index: clang-tools-extra/clangd/unittests/XRefsTests.cpp
===
--- clang-tools-extra/clangd/unittests/XRefsTests.cpp
+++ clang-tools-extra/clangd/unittests/XRefsTests.cpp
@@ -60,6 +60,7 @@
 // Extracts ranges from an annotated example, and constructs a matcher for a
 // highlight set. Ranges should be named $read/$write as appropriate.
 Matcher &>
+// NOLINTNEXTLINE(readability-identifier-naming)
 HighlightsFrom(const Annotations &Test) {
   std::vector Expected;
   auto Add = [&](const Range &R, DocumentHighlightKind K) {
Index: clang-tools-extra/clangd/unittests/TypeHierarchyTests.cpp
===
--- clang-tools-extra/clangd/unittests/TypeHierarchyTests.cpp
+++ clang-tools-extra/clangd/unittests/TypeHierarchyTests.cpp
@@ -39,11 +39,13 @@
 MATCHER_P(WithKind, Kind, "") { return arg.kind == Kind; }
 MATCHER_P(SelectionRangeIs, R, "") { return arg.selectionRange == R; }
 template 
+// NOLINTNEXTLINE(readability-identifier-naming)
 ::testing::Matcher Parents(ParentMatchers... ParentsM) {
   return Field(&TypeHierarchyItem::parents,
HasValue(UnorderedElementsAre(ParentsM...)));
 }
 template 
+// NOLINTNEXTLINE(readability-identifier-naming)
 ::test

[PATCH] D116395: [Clang] Emit warning for -x option without effects

[Qiu Chaofan via Phabricator via cfe-commits]

qiucf added a comment.

gentle ping


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116395

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

[PATCH] D109611: Fix CLANG_ENABLE_STATIC_ANALYZER=OFF building all analyzer source

[Timm Bäder via Phabricator via cfe-commits]

tbaeder added a comment.

I just noticed this as well. @arichardson, has there been any work towards a 
working solution?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109611

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

[clang] 52fddcd - [clang-format] Format ParseOpenMP.cpp changes

[Saiyedul Islam via cfe-commits]

Author: Saiyedul Islam
Date: 2022-01-27T09:00:34Z
New Revision: 52fddcdd9c90a550d7a50cbc2013be3314f91d08

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

LOG: [clang-format] Format ParseOpenMP.cpp changes

Properly format D116549.

Added: 


Modified: 
clang/lib/Parse/ParseOpenMP.cpp

Removed: 




diff  --git a/clang/lib/Parse/ParseOpenMP.cpp b/clang/lib/Parse/ParseOpenMP.cpp
index de3d58baf84c9..8ad5edb1bcd63 100644
--- a/clang/lib/Parse/ParseOpenMP.cpp
+++ b/clang/lib/Parse/ParseOpenMP.cpp
@@ -2210,12 +2210,12 @@ Parser::DeclGroupPtrTy 
Parser::ParseOpenMPDeclarativeDirectiveWithExtDecl(
 VariantMatchInfo VMI;
 TI.getAsVariantMatchInfo(ASTCtx, VMI);
 
-std::function DiagUnknownTrait = [this, Loc](
-  StringRef ISATrait) {
-  // TODO Track the selector locations in a way that is accessible here to
-  // improve the diagnostic location.
-  Diag(Loc, diag::warn_unknown_declare_variant_isa_trait) << ISATrait;
-};
+std::function DiagUnknownTrait =
+[this, Loc](StringRef ISATrait) {
+  // TODO Track the selector locations in a way that is accessible here
+  // to improve the diagnostic location.
+  Diag(Loc, diag::warn_unknown_declare_variant_isa_trait) << ISATrait;
+};
 TargetOMPContext OMPCtx(
 ASTCtx, std::move(DiagUnknownTrait),
 /* CurrentFunctionDecl */ nullptr,
@@ -2551,12 +2551,12 @@ 
Parser::ParseOpenMPDeclarativeOrExecutableDirective(ParsedStmtContext StmtCtx) {
 TPA.Revert();
 // End of the first iteration. Parser is reset to the start of 
metadirective
 
-std::function DiagUnknownTrait = [this, Loc](
-  StringRef ISATrait) {
-  // TODO Track the selector locations in a way that is accessible here to
-  // improve the diagnostic location.
-  Diag(Loc, diag::warn_unknown_declare_variant_isa_trait) << ISATrait;
-};
+std::function DiagUnknownTrait =
+[this, Loc](StringRef ISATrait) {
+  // TODO Track the selector locations in a way that is accessible here
+  // to improve the diagnostic location.
+  Diag(Loc, diag::warn_unknown_declare_variant_isa_trait) << ISATrait;
+};
 TargetOMPContext OMPCtx(ASTContext, std::move(DiagUnknownTrait),
 /* CurrentFunctionDecl */ nullptr,
 ArrayRef());



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

[PATCH] D115634: [clangd] Cleanup of readability-identifier-naming

[Christian Kühnel via Phabricator via cfe-commits]

kuhnel updated this revision to Diff 403539.
kuhnel marked an inline comment as done.
kuhnel added a comment.

addressed review comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115634

Files:
  .clang-tidy
  clang-tools-extra/clangd/ClangdLSPServer.cpp
  clang-tools-extra/clangd/SourceCode.cpp
  clang-tools-extra/clangd/TUScheduler.cpp
  clang-tools-extra/clangd/XRefs.cpp
  clang-tools-extra/clangd/benchmarks/IndexBenchmark.cpp
  clang-tools-extra/clangd/fuzzer/clangd-fuzzer.cpp
  clang-tools-extra/clangd/index/YAMLSerialization.cpp
  clang-tools-extra/clangd/unittests/BackgroundIndexTests.cpp
  clang-tools-extra/clangd/unittests/CallHierarchyTests.cpp
  clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
  clang-tools-extra/clangd/unittests/ConfigYAMLTests.cpp
  clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp
  clang-tools-extra/clangd/unittests/ExpectedTypeTest.cpp
  clang-tools-extra/clangd/unittests/FileIndexTests.cpp
  clang-tools-extra/clangd/unittests/FindSymbolsTests.cpp
  clang-tools-extra/clangd/unittests/HeadersTests.cpp
  clang-tools-extra/clangd/unittests/IndexActionTests.cpp
  clang-tools-extra/clangd/unittests/JSONTransportTests.cpp
  clang-tools-extra/clangd/unittests/QualityTests.cpp
  clang-tools-extra/clangd/unittests/SerializationTests.cpp
  clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp
  clang-tools-extra/clangd/unittests/SymbolInfoTests.cpp
  clang-tools-extra/clangd/unittests/TestIndex.cpp
  clang-tools-extra/clangd/unittests/TypeHierarchyTests.cpp
  clang-tools-extra/clangd/unittests/XRefsTests.cpp
  clang-tools-extra/clangd/unittests/support/ThreadingTests.cpp
  clang-tools-extra/clangd/unittests/support/TraceTests.cpp

Index: clang-tools-extra/clangd/unittests/support/TraceTests.cpp
===
--- clang-tools-extra/clangd/unittests/support/TraceTests.cpp
+++ clang-tools-extra/clangd/unittests/support/TraceTests.cpp
@@ -39,7 +39,7 @@
 
 // Checks that N is a Mapping (JS object) with the expected scalar properties.
 // The object must have all the Expected properties, but may have others.
-bool VerifyObject(llvm::yaml::Node &N,
+bool VerifyObject(llvm::yaml::Node &N, // NOLINT(readability-identifier-naming)
   std::map Expected) {
   auto *M = llvm::dyn_cast(&N);
   if (!M) {
Index: clang-tools-extra/clangd/unittests/support/ThreadingTests.cpp
===
--- clang-tools-extra/clangd/unittests/support/ThreadingTests.cpp
+++ clang-tools-extra/clangd/unittests/support/ThreadingTests.cpp
@@ -29,7 +29,7 @@
   int Counter(0); /* GUARDED_BY(Mutex) */
   {
 AsyncTaskRunner Tasks;
-auto scheduleIncrements = [&]() {
+auto ScheduleIncrements = [&]() {
   for (int TaskI = 0; TaskI < TasksCnt; ++TaskI) {
 Tasks.runAsync("task", [&Counter, &Mutex, IncrementsPerTask]() {
   for (int Increment = 0; Increment < IncrementsPerTask; ++Increment) {
@@ -44,7 +44,7 @@
   // Make sure runAsync is not running tasks synchronously on the same
   // thread by locking the Mutex used for increments.
   std::lock_guard Lock(Mutex);
-  scheduleIncrements();
+  ScheduleIncrements();
 }
 
 Tasks.wait();
@@ -56,7 +56,7 @@
 {
   std::lock_guard Lock(Mutex);
   Counter = 0;
-  scheduleIncrements();
+  ScheduleIncrements();
 }
   }
   // Check that destructor has waited for tasks to finish.
Index: clang-tools-extra/clangd/unittests/XRefsTests.cpp
===
--- clang-tools-extra/clangd/unittests/XRefsTests.cpp
+++ clang-tools-extra/clangd/unittests/XRefsTests.cpp
@@ -60,6 +60,7 @@
 // Extracts ranges from an annotated example, and constructs a matcher for a
 // highlight set. Ranges should be named $read/$write as appropriate.
 Matcher &>
+// NOLINTNEXTLINE(readability-identifier-naming)
 HighlightsFrom(const Annotations &Test) {
   std::vector Expected;
   auto Add = [&](const Range &R, DocumentHighlightKind K) {
Index: clang-tools-extra/clangd/unittests/TypeHierarchyTests.cpp
===
--- clang-tools-extra/clangd/unittests/TypeHierarchyTests.cpp
+++ clang-tools-extra/clangd/unittests/TypeHierarchyTests.cpp
@@ -39,11 +39,13 @@
 MATCHER_P(WithKind, Kind, "") { return arg.kind == Kind; }
 MATCHER_P(SelectionRangeIs, R, "") { return arg.selectionRange == R; }
 template 
+// NOLINTNEXTLINE(readability-identifier-naming)
 ::testing::Matcher Parents(ParentMatchers... ParentsM) {
   return Field(&TypeHierarchyItem::parents,
HasValue(UnorderedElementsAre(ParentsM...)));
 }
 template 
+// NOLINTNEXTLINE(readability-identifier-naming)
 ::testing::Matcher Children(ChildMatchers... ChildrenM) {
   return Field(&TypeHierarchyItem::children,
HasValue(Unordere

[PATCH] D115634: [clangd] Cleanup of readability-identifier-naming

[Christian Kühnel via Phabricator via cfe-commits]

kuhnel marked 6 inline comments as done.
kuhnel added inline comments.



Comment at: clang-tools-extra/clangd/fuzzer/FuzzerClangdMain.cpp:15
 
+// NOLINTNEXTLINE(readability-identifier-naming)
 extern "C" int LLVMFuzzerTestOneInput(const uint8_t *Data, size_t Size);

sammccall wrote:
> This name is always exempt, and should rather be excluded by config: 
> https://clang.llvm.org/extra/clang-tidy/checks/readability-identifier-naming.html#cmdoption-arg-functionignoredregexp
I tried a couple of variations of the config in the global `.clang-tidy` file, 
however none of them actually ignored the function:

```yaml
  - key: readability-identifier-naming.FunctionIgnoredRegexp
value:   "LLVMFuzzerTest.*"
```

Any idea what I'm doing wrong?



Comment at: clang-tools-extra/clangd/unittests/BackgroundIndexTests.cpp:39
 ::testing::Matcher
-RefsAre(std::vector<::testing::Matcher> Matchers) {
+refsAre(std::vector<::testing::Matcher> Matchers) {
   return ElementsAre(::testing::Pair(_, UnorderedElementsAreArray(Matchers)));

sammccall wrote:
> Note that `MATCHER_P(FileURI, F, "") { ... ]` above also defines a function 
> returning a `Matcher`.
> 
> I think it's OK for our functions to have different case than matcher 
> functions from the upstream gtest (different libraries have different 
> styles), but I don't think it's OK for matcher functions to have different 
> case depending on whether `MATCHER_P` was used or not.
> 
> And I agree that `//NOLINT` everywhere is not a good option.
> 
> So as far as I'm concerned:
> - OK: change these functions and also all the MATCHER, MATCHER_P etc 
> instances to lowerCamelCase
> - OK: ignore this style rule and check results for matcher names
> - Not OK: follow the rule for explicitly-defined function but ignore it for 
> `MATCHER_P`s
> - Not OK: ignore the rule and add // NOLINT to enough exceptions to silence 
> the checker
> - Bonus: teach the tidy check to flag violations introduced through macros 
> (probably with an allowlist of macro names)
> 
> (I'm not quite sure how our convention of using UpperCamelCase for matcher 
> factory functions got started, but I suspect it's from following upstream 
> recipes without thinking hard about whether the new symbol is a function or a 
> type).
My proposal here is to stick with the gtest naming convention for more 
consistency in the naming: Matchers start with upper case letters.

Thus I added //NOLINT to all matchers I encountered.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115634

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

[PATCH] D118104: Make run-clang-tidy.py print the configured checks correctly

[Jesko Appelfeller via Phabricator via cfe-commits]

JesApp updated this revision to Diff 403541.
JesApp marked 2 inline comments as done.
JesApp added a comment.

Resubmitting the same changes after rebasing onto current main.


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

https://reviews.llvm.org/D118104

Files:
  clang-tools-extra/clang-tidy/tool/run-clang-tidy.py


Index: clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
===
--- clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
+++ clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
@@ -254,12 +254,12 @@
 build_path = find_compilation_database(db_path)
 
   try:
-invocation = [args.clang_tidy_binary, '-list-checks']
-if args.allow_enabling_alpha_checkers:
-  invocation.append('-allow-enabling-analyzer-alpha-checkers')
-invocation.append('-p=' + build_path)
-if args.checks:
-  invocation.append('-checks=' + args.checks)
+invocation = get_tidy_invocation("", args.clang_tidy_binary, args.checks,
+ None, build_path, args.header_filter,
+ args.allow_enabling_alpha_checkers,
+ args.extra_arg, args.extra_arg_before,
+ args.quiet, args.config, args.line_filter)
+invocation.append('-list-checks')
 invocation.append('-')
 if args.quiet:
   # Even with -quiet we still want to check if we can call clang-tidy.


Index: clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
===
--- clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
+++ clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
@@ -254,12 +254,12 @@
 build_path = find_compilation_database(db_path)
 
   try:
-invocation = [args.clang_tidy_binary, '-list-checks']
-if args.allow_enabling_alpha_checkers:
-  invocation.append('-allow-enabling-analyzer-alpha-checkers')
-invocation.append('-p=' + build_path)
-if args.checks:
-  invocation.append('-checks=' + args.checks)
+invocation = get_tidy_invocation("", args.clang_tidy_binary, args.checks,
+ None, build_path, args.header_filter,
+ args.allow_enabling_alpha_checkers,
+ args.extra_arg, args.extra_arg_before,
+ args.quiet, args.config, args.line_filter)
+invocation.append('-list-checks')
 invocation.append('-')
 if args.quiet:
   # Even with -quiet we still want to check if we can call clang-tidy.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D118333: [RISCV] Update computeTargetABI implementation.

[Zakk Chen via Phabricator via cfe-commits]

khchen created this revision.
khchen added reviewers: craig.topper, jrtc27, frasercrmck, kito-cheng, arcbbb, 
monkchiang, eopXD.
Herald added subscribers: VincentWu, luke957, achieveartificialintelligence, 
armkevincheng, eric-k256, vkmr, dexonsmith, evandro, luismarques, apazos, 
sameer.abuasal, s.egerton, Jim, benna, psnobl, jocewei, PkmX, the_o, 
brucehoult, MartinMosbeck, rogfer01, edward-jones, zzheng, niosHD, sabuasal, 
simoncook, johnrusso, rbar, asb, hiraditya, qcolombet.
Herald added a reviewer: sjarus.
khchen requested review of this revision.
Herald added subscribers: llvm-commits, cfe-commits, pcwang-thead, MaskRay.
Herald added projects: clang, LLVM.

I think it's good to have one logic to get the default
target-abi if no explicit ABI is given, because currently
we have two different logic in front-end and back-end.

The front-end is defautl to the ilp32/ilp32e/lp64 ABI, and
ilp32d/lp64d when hardware support for extension D.
The backend is default to the ilp32/ilp32e/lp64 ABI.

Due to the default target-abi had changed, I update some tests
by specific the target-abi with old default value to make the
expected result unchanged.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D118333

Files:
  clang/lib/Basic/Targets/RISCV.cpp
  clang/lib/Driver/ToolChains/Arch/RISCV.cpp
  llvm/include/llvm/Support/RISCVISAInfo.h
  llvm/include/llvm/Support/TargetParser.h
  llvm/lib/Support/RISCVISAInfo.cpp
  llvm/lib/Support/TargetParser.cpp
  llvm/lib/Target/RISCV/MCTargetDesc/RISCVBaseInfo.cpp
  llvm/lib/Target/RISCV/MCTargetDesc/RISCVBaseInfo.h
  llvm/lib/Target/RISCV/MCTargetDesc/RISCVTargetStreamer.cpp
  llvm/test/CodeGen/RISCV/callee-saved-fpr64s.ll
  llvm/test/CodeGen/RISCV/double-bitmanip-dagcombines.ll
  llvm/test/CodeGen/RISCV/double-calling-conv.ll
  llvm/test/CodeGen/RISCV/double-imm.ll
  llvm/test/CodeGen/RISCV/double-mem.ll
  llvm/test/CodeGen/RISCV/double-previous-failure.ll
  llvm/test/CodeGen/RISCV/double-stack-spill-restore.ll
  llvm/test/CodeGen/RISCV/fastcc-float.ll
  llvm/test/CodeGen/RISCV/float-bit-preserving-dagcombines.ll
  llvm/test/CodeGen/RISCV/fpclamptosat.ll
  llvm/test/CodeGen/RISCV/fpclamptosat_vec.ll
  llvm/test/CodeGen/RISCV/frm-dependency.ll
  llvm/test/CodeGen/RISCV/inline-asm-clobbers.ll
  llvm/test/CodeGen/RISCV/inline-asm-d-constraint-f.ll
  llvm/test/CodeGen/RISCV/inline-asm-f-constraint-f.ll
  llvm/test/CodeGen/RISCV/mattr-invalid-combination.ll
  llvm/test/CodeGen/RISCV/rv64d-double-convert-strict.ll
  llvm/test/CodeGen/RISCV/rv64d-double-convert.ll
  llvm/test/CodeGen/RISCV/rvv/fixed-vectors-emergency-slot.mir
  llvm/test/CodeGen/RISCV/rvv/fixed-vectors-fp-bitcast.ll
  llvm/test/CodeGen/RISCV/rvv/large-rvv-stack-size.mir
  llvm/test/CodeGen/RISCV/rvv/sink-splat-operands.ll
  llvm/test/CodeGen/RISCV/rvv/vmfeq-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vmfeq-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vmfge-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vmfge-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vmfgt-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vmfgt-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vmfle-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vmfle-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vmflt-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vmflt-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vmfne-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vmfne-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vsetvli-insert-crossbb.ll
  llvm/test/CodeGen/RISCV/rvv/vsetvli-insert.ll
  llvm/test/CodeGen/RISCV/select-const.ll
  llvm/test/CodeGen/RISCV/select-optimize-multiple.ll
  llvm/test/CodeGen/RISCV/spill-fpr-scalar.ll

Index: llvm/test/CodeGen/RISCV/spill-fpr-scalar.ll
===
--- llvm/test/CodeGen/RISCV/spill-fpr-scalar.ll
+++ llvm/test/CodeGen/RISCV/spill-fpr-scalar.ll
@@ -1,5 +1,5 @@
 ; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
-; RUN: llc -mtriple=riscv64 -mattr=+v,+d,+zfh \
+; RUN: llc -mtriple=riscv64 -mattr=+v,+d,+zfh -target-abi=lp64 \
 ; RUN:   -verify-machineinstrs < %s \
 ; RUN:   | FileCheck %s
 
Index: llvm/test/CodeGen/RISCV/select-optimize-multiple.ll
===
--- llvm/test/CodeGen/RISCV/select-optimize-multiple.ll
+++ llvm/test/CodeGen/RISCV/select-optimize-multiple.ll
@@ -1,11 +1,11 @@
 ; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
-; RUN: llc -mtriple=riscv32 -mattr=+d -verify-machineinstrs < %s \
+; RUN: llc -mtriple=riscv32 -mattr=+d -target-abi=ilp32 -verify-machineinstrs < %s \
 ; RUN:   | FileCheck %s -check-prefix=RV32I
-; RUN: llc -mtriple=riscv32 -mattr=+d,+experimental-zbt -verify-machineinstrs < %s \
+; RUN: llc -mtriple=riscv32 -mattr=+d,+experimental-zbt -target-abi=ilp32 -verify-machineinstrs < %s \
 ; RUN:   | FileCheck %s -check-prefix=RV32IBT
-; RUN: llc -mtriple=riscv64 -mattr=+d -verify-machineinstrs < %s \
+; RUN: llc -mtriple=riscv64 -mattr=+d -target-abi=lp64 -verify-machineinstrs < %s \
 ; RUN:   | FileCheck %s -che

[PATCH] D117744: [Driver] Remove obsoleted -gz=zlib-gnu

[Pavel Labath via Phabricator via cfe-commits]

labath added a comment.

This (unsurprisingly) broke an lldb test for the gnu style compression. You 
didn't get the notification because the bot was already red at the time. I've 
already fixed the situation by converting the test to yaml, but I thought you 
may want to know what happened.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117744

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

[PATCH] D118260: [clangd][Hover] Suppress initializers with many tokens

[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/Hover.cpp:131
+const syntax::TokenBuffer &TB) {
+  if (auto *VD = llvm::dyn_cast(D)) {
+if (auto *IE = VD->getInit()) {

Explain why


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118260

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

[clang] b88ca61 - [NFC][CodeGen] Use llvm::DenseMap for DeferredDecls

[Dawid Jurczak via cfe-commits]

Author: Dawid Jurczak
Date: 2022-01-27T10:57:48+01:00
New Revision: b88ca619d33bc74e1776d879e43c6fc812ac4ff5

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

LOG: [NFC][CodeGen] Use llvm::DenseMap for DeferredDecls

CodeGenModule::DeferredDecls std::map::operator[] seem to be hot especially 
while code generating huge compilation units.
In such cases using DenseMap instead gives observable compile time improvement. 
Patch was tested on Linux build with default config acting as benchmark.
Build was performed on isolated CPU cores in silent x86-64 Linux environment 
following: https://llvm.org/docs/Benchmarking.html#linux rules.
Compile time statistics diff produced by perf and time before and after change 
are following:
instructions -0.15%, cycles -0.7%, max-rss +0.65%.
Using StringMap instead DenseMap doesn't bring any visible gains.

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

Added: 


Modified: 
clang/lib/CodeGen/CodeGenModule.h

Removed: 




diff  --git a/clang/lib/CodeGen/CodeGenModule.h 
b/clang/lib/CodeGen/CodeGenModule.h
index 9ae9d624b925d..e803022508a4c 100644
--- a/clang/lib/CodeGen/CodeGenModule.h
+++ b/clang/lib/CodeGen/CodeGenModule.h
@@ -335,7 +335,7 @@ class CodeGenModule : public CodeGenTypeCache {
   /// for emission and therefore should only be output if they are actually
   /// used. If a decl is in this, then it is known to have not been referenced
   /// yet.
-  std::map DeferredDecls;
+  llvm::DenseMap DeferredDecls;
 
   /// This is a list of deferred decls which we have seen that *are* actually
   /// referenced. These get code generated when the module is done.



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

[PATCH] D118169: [NFC][CodeGen] Use llvm::DenseMap for DeferredDecls

[Dawid Jurczak 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 rGb88ca619d33b: [NFC][CodeGen] Use llvm::DenseMap for 
DeferredDecls (authored by yurai007).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118169

Files:
  clang/lib/CodeGen/CodeGenModule.h


Index: clang/lib/CodeGen/CodeGenModule.h
===
--- clang/lib/CodeGen/CodeGenModule.h
+++ clang/lib/CodeGen/CodeGenModule.h
@@ -335,7 +335,7 @@
   /// for emission and therefore should only be output if they are actually
   /// used. If a decl is in this, then it is known to have not been referenced
   /// yet.
-  std::map DeferredDecls;
+  llvm::DenseMap DeferredDecls;
 
   /// This is a list of deferred decls which we have seen that *are* actually
   /// referenced. These get code generated when the module is done.


Index: clang/lib/CodeGen/CodeGenModule.h
===
--- clang/lib/CodeGen/CodeGenModule.h
+++ clang/lib/CodeGen/CodeGenModule.h
@@ -335,7 +335,7 @@
   /// for emission and therefore should only be output if they are actually
   /// used. If a decl is in this, then it is known to have not been referenced
   /// yet.
-  std::map DeferredDecls;
+  llvm::DenseMap DeferredDecls;
 
   /// This is a list of deferred decls which we have seen that *are* actually
   /// referenced. These get code generated when the module is done.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D118259: [AArch64] Adjust aarch64-neon-intrinsics-constrained test and un-XFAIL

[Florian Hahn via Phabricator via cfe-commits]

fhahn added a comment.

Does this clang test actually need to check the generated assembly? Shouldn't 
it be enough to check that the correct intrinsics are generated?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118259

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

[clang] 792a409 - [CMake][Fuchsia] Only build iossim runtimes for arm64

[Petr Hosek via cfe-commits]

Author: Petr Hosek
Date: 2022-01-27T02:28:13-08:00
New Revision: 792a4095c5514c89330571e764e8981b484bd6ca

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

LOG: [CMake][Fuchsia] Only build iossim runtimes for arm64

x86_64 isn't supported with the recent Xcode SDK.

Added: 


Modified: 
clang/cmake/caches/Fuchsia-stage2.cmake

Removed: 




diff  --git a/clang/cmake/caches/Fuchsia-stage2.cmake 
b/clang/cmake/caches/Fuchsia-stage2.cmake
index bc60b0df6d4af..8c593e4c6310c 100644
--- a/clang/cmake/caches/Fuchsia-stage2.cmake
+++ b/clang/cmake/caches/Fuchsia-stage2.cmake
@@ -71,7 +71,7 @@ if(APPLE)
   set(LIBCXX_ENABLE_STATIC_ABI_LIBRARY ON CACHE BOOL "")
   set(LIBCXX_ABI_VERSION 2 CACHE STRING "")
   set(DARWIN_ios_ARCHS arm64 CACHE STRING "")
-  set(DARWIN_iossim_ARCHS arm64;x86_64 CACHE STRING "")
+  set(DARWIN_iossim_ARCHS arm64 CACHE STRING "")
   set(DARWIN_osx_ARCHS arm64;x86_64 CACHE STRING "")
 endif()
 



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

[clang] 35fff20 - [OpenCL] opencl-c.h: add missing read_write image guards

[Sven van Haastregt via cfe-commits]

Author: Sven van Haastregt
Date: 2022-01-27T10:33:12Z
New Revision: 35fff208cad6f271410800998447dc0dd2704085

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

LOG: [OpenCL] opencl-c.h: add missing read_write image guards

The get_image_num_mip_levels overloads that take a read_write image
parameter were missing the __opencl_c_read_write_images guard.

Added: 


Modified: 
clang/lib/Headers/opencl-c.h

Removed: 




diff  --git a/clang/lib/Headers/opencl-c.h b/clang/lib/Headers/opencl-c.h
index e65e3634d010d..f7a85f6578858 100644
--- a/clang/lib/Headers/opencl-c.h
+++ b/clang/lib/Headers/opencl-c.h
@@ -15688,7 +15688,7 @@ half4 __purefn __ovld read_imageh(read_write 
image1d_array_t image, int2 coord);
 half4 __purefn __ovld read_imageh(read_write image2d_array_t image, int4 
coord);
 half4 __purefn __ovld read_imageh(read_write image1d_buffer_t image, int 
coord);
 #endif //cl_khr_fp16
-#endif //defined(__opencl_c_read_write_images
+#endif //defined(__opencl_c_read_write_images)
 
 /**
  * Write color value to location specified by coordinate
@@ -16049,9 +16049,11 @@ int __ovld get_image_num_mip_levels(write_only 
image2d_t image);
 int __ovld get_image_num_mip_levels(write_only image3d_t image);
 #endif
 
+#if defined(__opencl_c_read_write_images)
 int __ovld get_image_num_mip_levels(read_write image1d_t image);
 int __ovld get_image_num_mip_levels(read_write image2d_t image);
 int __ovld get_image_num_mip_levels(read_write image3d_t image);
+#endif //defined(__opencl_c_read_write_images)
 
 int __ovld get_image_num_mip_levels(read_only image1d_array_t image);
 int __ovld get_image_num_mip_levels(read_only image2d_array_t image);
@@ -16063,10 +16065,12 @@ int __ovld get_image_num_mip_levels(write_only 
image2d_array_t image);
 int __ovld get_image_num_mip_levels(write_only image2d_array_depth_t image);
 int __ovld get_image_num_mip_levels(write_only image2d_depth_t image);
 
+#if defined(__opencl_c_read_write_images)
 int __ovld get_image_num_mip_levels(read_write image1d_array_t image);
 int __ovld get_image_num_mip_levels(read_write image2d_array_t image);
 int __ovld get_image_num_mip_levels(read_write image2d_array_depth_t image);
 int __ovld get_image_num_mip_levels(read_write image2d_depth_t image);
+#endif //defined(__opencl_c_read_write_images)
 
 #endif //cl_khr_mipmap_image
 #endif //defined(__OPENCL_CPP_VERSION__) || (__OPENCL_C_VERSION__ >= 
CL_VERSION_2_0)



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

[PATCH] D118337: [clang-format] Fix AllowShortFunctionsOnASingleLine: InlineOnly with wrapping after record.

[Marek Kurdej via Phabricator via cfe-commits]

curdeius created this revision.
curdeius added reviewers: MyDeveloperDay, HazardyKnusperkeks, owenpan.
curdeius requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Fixes https://github.com/llvm/llvm-project/issues/53430.

Initially, I had a quick and dirty approach, but it led to a myriad of special 
cases handling comments (that may add unwrapped lines).
So I added TT_RecordLBrace type annotations and it seems like a much nicer 
solution.
I think that in the future it will allow us to clean up some convoluted code 
that detects records.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D118337

Files:
  clang/lib/Format/FormatToken.h
  clang/lib/Format/TokenAnnotator.cpp
  clang/lib/Format/UnwrappedLineFormatter.cpp
  clang/lib/Format/UnwrappedLineParser.cpp
  clang/unittests/Format/FormatTest.cpp
  clang/unittests/Format/TokenAnnotatorTest.cpp

Index: clang/unittests/Format/TokenAnnotatorTest.cpp
===
--- clang/unittests/Format/TokenAnnotatorTest.cpp
+++ clang/unittests/Format/TokenAnnotatorTest.cpp
@@ -67,6 +67,30 @@
   EXPECT_TOKEN(Tokens[11], tok::star, TT_PointerOrReference);
 }
 
+TEST_F(TokenAnnotatorTest, UnderstandsClasses) {
+  auto Tokens = annotate("class C {};");
+  EXPECT_EQ(Tokens.size(), 6u) << Tokens;
+  EXPECT_TOKEN(Tokens[2], tok::l_brace, TT_RecordLBrace);
+}
+
+TEST_F(TokenAnnotatorTest, UnderstandsStructs) {
+  auto Tokens = annotate("struct S {};");
+  EXPECT_EQ(Tokens.size(), 6u) << Tokens;
+  EXPECT_TOKEN(Tokens[2], tok::l_brace, TT_RecordLBrace);
+}
+
+TEST_F(TokenAnnotatorTest, UnderstandsUnions) {
+  auto Tokens = annotate("union U {};");
+  EXPECT_EQ(Tokens.size(), 6u) << Tokens;
+  EXPECT_TOKEN(Tokens[2], tok::l_brace, TT_RecordLBrace);
+}
+
+TEST_F(TokenAnnotatorTest, UnderstandsEnums) {
+  auto Tokens = annotate("enum E {};");
+  EXPECT_EQ(Tokens.size(), 6u) << Tokens;
+  EXPECT_TOKEN(Tokens[2], tok::l_brace, TT_RecordLBrace);
+}
+
 } // namespace
 } // namespace format
 } // namespace clang
Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -12316,6 +12316,48 @@
"  int f() {}\n"
"};",
MergeInlineOnly);
+
+  MergeInlineOnly.BraceWrapping.AfterClass = true;
+  MergeInlineOnly.BraceWrapping.AfterStruct = true;
+  verifyFormat("class C\n"
+   "{\n"
+   "  int f() { return 42; }\n"
+   "};",
+   MergeInlineOnly);
+  verifyFormat("struct C\n"
+   "{\n"
+   "  int f() { return 42; }\n"
+   "};",
+   MergeInlineOnly);
+  verifyFormat("int f()\n"
+   "{\n"
+   "  return 42;\n"
+   "}",
+   MergeInlineOnly);
+  verifyFormat("int f() {}", MergeInlineOnly);
+  verifyFormat("class C\n"
+   "{\n"
+   "  int f() { return 42; }\n"
+   "};",
+   MergeInlineOnly);
+  verifyFormat("struct C\n"
+   "{\n"
+   "  int f() { return 42; }\n"
+   "};",
+   MergeInlineOnly);
+  verifyFormat("struct C\n"
+   "// comment\n"
+   "/* comment */\n"
+   "// comment\n"
+   "{\n"
+   "  int f() { return 42; }\n"
+   "};",
+   MergeInlineOnly);
+  verifyFormat("/* comment */ struct C\n"
+   "{\n"
+   "  int f() { return 42; }\n"
+   "};",
+   MergeInlineOnly);
 }
 
 TEST_F(FormatTest, PullInlineOnlyFunctionDefinitionsIntoSingleLine) {
Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -2482,7 +2482,8 @@
 parseParens();
   } else {
 while (FormatTok->isOneOf(tok::identifier, tok::coloncolon, tok::kw_inline,
-  tok::l_square, tok::period)) {
+  tok::l_square, tok::period) ||
+   (Style.isCSharp() && FormatTok->is(tok::kw_union))) {
   if (FormatTok->is(tok::l_square))
 parseSquare();
   else
@@ -2868,6 +2869,7 @@
   // Just a declaration or something is wrong.
   if (FormatTok->isNot(tok::l_brace))
 return true;
+  FormatTok->setType(TT_RecordLBrace);
   FormatTok->setBlockKind(BK_Block);
 
   if (Style.Language == FormatStyle::LK_Java) {
@@ -3108,6 +3110,7 @@
 }
   }
   if (FormatTok->Tok.is(tok::l_brace)) {
+FormatTok->setType(TT_RecordLBrace);
 if (ParseAsExpr) {
   parseChildBlock();
 } else {
Index: clang/lib/Format/UnwrappedLineFormatter.cpp
===
--- clang/lib/Format/UnwrappedLineFormatte

[PATCH] D115640: [OpenCL] Add support of __opencl_c_device_enqueue feature macro.

[Anastasia Stulova via Phabricator via cfe-commits]

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

LGTM! Thanks


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115640

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

[PATCH] D118253: [RISCV] Add the passthru operand for some RVV nomask unary and nullary intrinsics.

[Fraser Cormack via Phabricator via cfe-commits]

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

LGTM, thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118253

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

[PATCH] D118337: [clang-format] Fix AllowShortFunctionsOnASingleLine: InlineOnly with wrapping after record.

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added inline comments.



Comment at: clang/lib/Format/UnwrappedLineFormatter.cpp:280
+if (Style.isJavaScript() && (*I)->Last->is(TT_FunctionLBrace))
+  return true;
+

we didn't need this anymore?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118337

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

[PATCH] D114639: Raise the minimum Visual Studio version to VS2019

[Simon Pilgrim via Phabricator via cfe-commits]

RKSimon updated this revision to Diff 403574.
RKSimon added a comment.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

update lldb docs as well


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114639

Files:
  clang/docs/ClangFormatStyleOptions.rst
  clang/docs/UsersManual.rst
  lldb/docs/resources/build.rst
  lldb/docs/resources/test.rst
  llvm/cmake/modules/CheckCompilerVersion.cmake
  llvm/docs/CMake.rst
  llvm/docs/GettingStarted.rst
  llvm/docs/GettingStartedVS.rst
  llvm/docs/ReleaseNotes.rst
  llvm/include/llvm/Support/Compiler.h

Index: llvm/include/llvm/Support/Compiler.h
===
--- llvm/include/llvm/Support/Compiler.h
+++ llvm/include/llvm/Support/Compiler.h
@@ -77,12 +77,21 @@
 /// * 1916: VS2017, version 15.9
 /// * 1920: VS2019, version 16.0
 /// * 1921: VS2019, version 16.1
+/// * 1922: VS2019, version 16.2
+/// * 1923: VS2019, version 16.3
+/// * 1924: VS2019, version 16.4
+/// * 1925: VS2019, version 16.5
+/// * 1926: VS2019, version 16.6
+/// * 1927: VS2019, version 16.7
+/// * 1928: VS2019, version 16.8 + 16.9
+/// * 1929: VS2019, version 16.10 + 16.11
+/// * 1930: VS2022, version 17.0
 #ifdef _MSC_VER
 #define LLVM_MSC_PREREQ(version) (_MSC_VER >= (version))
 
-// We require at least MSVC 2017.
-#if !LLVM_MSC_PREREQ(1910)
-#error LLVM requires at least MSVC 2017.
+// We require at least VS 2019.
+#if !LLVM_MSC_PREREQ(1920)
+#error LLVM requires at least VS 2019.
 #endif
 
 #else
@@ -94,12 +103,8 @@
 /// Sadly, this is separate from just rvalue reference support because GCC
 /// and MSVC implemented this later than everything else. This appears to be
 /// corrected in MSVC 2019 but not MSVC 2017.
-#if __has_feature(cxx_rvalue_references) || defined(__GNUC__) ||   \
-LLVM_MSC_PREREQ(1920)
+/// FIXME: Remove LLVM_HAS_RVALUE_REFERENCE_THIS macro
 #define LLVM_HAS_RVALUE_REFERENCE_THIS 1
-#else
-#define LLVM_HAS_RVALUE_REFERENCE_THIS 0
-#endif
 
 /// Expands to '&' if ref-qualifiers for *this are supported.
 ///
Index: llvm/docs/ReleaseNotes.rst
===
--- llvm/docs/ReleaseNotes.rst
+++ llvm/docs/ReleaseNotes.rst
@@ -65,7 +65,7 @@
 Changes to building LLVM
 
 
-* ...
+* Building LLVM with Visual Studio now requires version 2019 or later.
 
 Changes to TableGen
 ---
Index: llvm/docs/GettingStartedVS.rst
===
--- llvm/docs/GettingStartedVS.rst
+++ llvm/docs/GettingStartedVS.rst
@@ -36,7 +36,7 @@
 
 Hardware
 
-Any system that can adequately run Visual Studio 2017 is fine. The LLVM
+Any system that can adequately run Visual Studio 2019 is fine. The LLVM
 source tree including the git index consumes approximately 3GB.
 Object files, libraries and executables consume approximately 5GB in
 Release mode and much more in Debug mode. SSD drive and >16GB RAM are
@@ -45,13 +45,14 @@
 
 Software
 
-You will need `Visual Studio `_ 2017 or
-higher, with the latest Update installed. Visual Studio Community Edition
+You will need `Visual Studio `_ 2019 or
+later, with the latest Update installed. Visual Studio Community Edition
 suffices.
 
 You will also need the `CMake `_ build system since it
 generates the project files you will use to build with. CMake is bundled with
-Visual Studio 2019 so separate installation is not required.
+Visual Studio 2019 so separate installation is not required. If you do install
+CMake separately, Visual Studio 2022 will require CMake Version 3.21 or later.
 
 If you would like to run the LLVM tests you will need `Python
 `_. Version 3.6 and newer are known to work. You can
Index: llvm/docs/GettingStarted.rst
===
--- llvm/docs/GettingStarted.rst
+++ llvm/docs/GettingStarted.rst
@@ -238,7 +238,7 @@
 * Clang 3.5
 * Apple Clang 6.0
 * GCC 5.1
-* Visual Studio 2017
+* Visual Studio 2019
 
 Anything older than these toolchains *may* work, but will require forcing the
 build system with a special option and is not really a supported host platform.
@@ -273,8 +273,8 @@
 This section mostly applies to Linux and older BSDs. On macOS, you should
 have a sufficiently modern Xcode, or you will likely need to upgrade until you
 do. Windows does not have a "system compiler", so you must install either Visual
-Studio 2017 or a recent version of mingw64. FreeBSD 10.0 and newer have a modern
-Clang as the system compiler.
+Studio 2019 (or later), or a recent version of mingw64. FreeBSD 10.0 and newer
+have a modern Clang as the system compiler.
 
 However, some Linux distributions and some other or older BSDs sometimes have
 extremely old versions of G

[clang] a5de66c - [OpenCL] Add support of __opencl_c_device_enqueue feature macro.

[Anton Zabaznov via cfe-commits]

Author: Anton Zabaznov
Date: 2022-01-27T14:25:59+03:00
New Revision: a5de66c4c50b5dec085ffbcd2afefd47f3f18d7f

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

LOG: [OpenCL] Add support of __opencl_c_device_enqueue feature macro.

This feature requires support of __opencl_c_generic_address_space and
__opencl_c_program_scope_global_variables so diagnostics for that is provided 
as well.

Reviewed By: Anastasia

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

Added: 
clang/test/SemaOpenCL/invalid-device-enqueue-types-cl3.0.cl

Modified: 
clang/include/clang/Basic/DiagnosticSemaKinds.td
clang/include/clang/Basic/OpenCLOptions.h
clang/lib/Basic/OpenCLOptions.cpp
clang/lib/Basic/TargetInfo.cpp
clang/lib/Headers/opencl-c-base.h
clang/lib/Headers/opencl-c.h
clang/lib/Sema/Sema.cpp
clang/test/CodeGenOpenCL/address-spaces-mangling.cl
clang/test/CodeGenOpenCL/address-spaces.cl
clang/test/CodeGenOpenCL/blocks.cl
clang/test/CodeGenOpenCL/pipe_types.cl
clang/test/CodeGenOpenCL/pipe_types_mangling.cl
clang/test/CodeGenOpenCLCXX/addrspace-constructors.clcpp
clang/test/Frontend/opencl.cl
clang/test/Misc/opencl-c-3.0.incorrect_options.cl
clang/test/SemaOpenCL/invalid-block.cl
clang/test/SemaOpenCL/invalid-pipes-cl1.2.cl
clang/test/SemaOpenCL/invalid-pipes-cl2.0.cl
clang/test/SemaOpenCL/storageclass.cl
clang/test/SemaOpenCLCXX/remove-address-space.clcpp

Removed: 




diff  --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index 735d92d79d27c..a8cf00c1263ff 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -9556,7 +9556,8 @@ def err_generic_sel_multi_match : Error<
 
 // Blocks
 def err_blocks_disable : Error<"blocks support disabled - compile with 
-fblocks"
-  " or %select{pick a deployment target that supports them|for OpenCL 2.0}0">;
+  " or %select{pick a deployment target that supports them|for OpenCL C 2.0"
+  " or OpenCL C 3.0 with __opencl_c_device_enqueue feature}0">;
 def err_block_returning_array_function : Error<
   "block cannot return %select{array|function}0 type %1">;
 

diff  --git a/clang/include/clang/Basic/OpenCLOptions.h 
b/clang/include/clang/Basic/OpenCLOptions.h
index d6cb1a210519d..512bcb1e6ef10 100644
--- a/clang/include/clang/Basic/OpenCLOptions.h
+++ b/clang/include/clang/Basic/OpenCLOptions.h
@@ -212,6 +212,15 @@ class OpenCLOptions {
   bool isEnabled(llvm::StringRef Ext) const;
 
   OpenCLOptionInfoMap OptMap;
+
+  // First feature in a pair requires the second one to be supported.
+  using FeatureDepEntry = std::pair;
+  using FeatureDepList = llvm::SmallVector;
+
+  static const FeatureDepList DependentFeaturesList;
+
+  // Extensions and equivalent feature pairs.
+  static const llvm::StringMap FeatureExtensionMap;
 };
 
 } // end namespace clang

diff  --git a/clang/lib/Basic/OpenCLOptions.cpp 
b/clang/lib/Basic/OpenCLOptions.cpp
index b7408f39bdab4..7e89b3f1b804d 100644
--- a/clang/lib/Basic/OpenCLOptions.cpp
+++ b/clang/lib/Basic/OpenCLOptions.cpp
@@ -12,6 +12,17 @@
 
 namespace clang {
 
+const OpenCLOptions::FeatureDepList OpenCLOptions::DependentFeaturesList = {
+{"__opencl_c_read_write_images", "__opencl_c_images"},
+{"__opencl_c_3d_image_writes", "__opencl_c_images"},
+{"__opencl_c_pipes", "__opencl_c_generic_address_space"},
+{"__opencl_c_device_enqueue", "__opencl_c_generic_address_space"},
+{"__opencl_c_device_enqueue", 
"__opencl_c_program_scope_global_variables"}};
+
+const llvm::StringMap OpenCLOptions::FeatureExtensionMap = {
+{"cl_khr_fp64", "__opencl_c_fp64"},
+{"cl_khr_3d_image_writes", "__opencl_c_3d_image_writes"}};
+
 bool OpenCLOptions::isKnown(llvm::StringRef Ext) const {
   return OptMap.find(Ext) != OptMap.end();
 }
@@ -108,33 +119,23 @@ void OpenCLOptions::disableAll() {
 
 bool OpenCLOptions::diagnoseUnsupportedFeatureDependencies(
 const TargetInfo &TI, DiagnosticsEngine &Diags) {
-  // Feature pairs. First feature in a pair requires the second one to be
-  // supported.
-  static const llvm::StringMap DependentFeaturesMap = {
-  {"__opencl_c_read_write_images", "__opencl_c_images"},
-  {"__opencl_c_3d_image_writes", "__opencl_c_images"},
-  {"__opencl_c_pipes", "__opencl_c_generic_address_space"}};
-
   auto OpenCLFeaturesMap = TI.getSupportedOpenCLOpts();
 
   bool IsValid = true;
-  for (auto &FeaturePair : DependentFeaturesMap)
-if (TI.hasFeatureEnabled(OpenCLFeaturesMap, FeaturePair.getKey()) &&
-!TI.hasFeatureEnabled(OpenCLFeaturesMap, FeaturePair.getValue())) {
+  for (auto &FeaturePair : DependentFeaturesList) {
+auto Feature = FeaturePair.first;
+auto 

[PATCH] D115640: [OpenCL] Add support of __opencl_c_device_enqueue feature macro.

[Anton Zabaznov 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 rGa5de66c4c50b: [OpenCL] Add support of 
__opencl_c_device_enqueue feature macro. (authored by azabaznov).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115640

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/OpenCLOptions.h
  clang/lib/Basic/OpenCLOptions.cpp
  clang/lib/Basic/TargetInfo.cpp
  clang/lib/Headers/opencl-c-base.h
  clang/lib/Headers/opencl-c.h
  clang/lib/Sema/Sema.cpp
  clang/test/CodeGenOpenCL/address-spaces-mangling.cl
  clang/test/CodeGenOpenCL/address-spaces.cl
  clang/test/CodeGenOpenCL/blocks.cl
  clang/test/CodeGenOpenCL/pipe_types.cl
  clang/test/CodeGenOpenCL/pipe_types_mangling.cl
  clang/test/CodeGenOpenCLCXX/addrspace-constructors.clcpp
  clang/test/Frontend/opencl.cl
  clang/test/Misc/opencl-c-3.0.incorrect_options.cl
  clang/test/SemaOpenCL/invalid-block.cl
  clang/test/SemaOpenCL/invalid-device-enqueue-types-cl3.0.cl
  clang/test/SemaOpenCL/invalid-pipes-cl1.2.cl
  clang/test/SemaOpenCL/invalid-pipes-cl2.0.cl
  clang/test/SemaOpenCL/storageclass.cl
  clang/test/SemaOpenCLCXX/remove-address-space.clcpp

Index: clang/test/SemaOpenCLCXX/remove-address-space.clcpp
===
--- clang/test/SemaOpenCLCXX/remove-address-space.clcpp
+++ clang/test/SemaOpenCLCXX/remove-address-space.clcpp
@@ -1,6 +1,6 @@
 // RUN: %clang_cc1 %s -cl-std=clc++1.0 -triple spir-unknown-unknown -fdeclare-opencl-builtins -finclude-default-header -verify
 // RUN: %clang_cc1 %s -cl-std=clc++2021 -triple spir-unknown-unknown -fdeclare-opencl-builtins -finclude-default-header -verify
-// RUN: %clang_cc1 %s -cl-std=clc++2021 -cl-ext=-__opencl_c_generic_address_space,-__opencl_c_pipes -triple spir-unknown-unknown -fdeclare-opencl-builtins -finclude-default-header -verify
+// RUN: %clang_cc1 %s -cl-std=clc++2021 -cl-ext=-__opencl_c_device_enqueue,-__opencl_c_generic_address_space,-__opencl_c_pipes -triple spir-unknown-unknown -fdeclare-opencl-builtins -finclude-default-header -verify
 
 // expected-no-diagnostics
 
Index: clang/test/SemaOpenCL/storageclass.cl
===
--- clang/test/SemaOpenCL/storageclass.cl
+++ clang/test/SemaOpenCL/storageclass.cl
@@ -1,12 +1,12 @@
 // RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=CL1.2
-// RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=CL3.0 -cl-ext=-__opencl_c_program_scope_global_variables,-__opencl_c_generic_address_space,-__opencl_c_pipes
-// RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=CL3.0 -cl-ext=+__opencl_c_program_scope_global_variables,-__opencl_c_generic_address_space,-__opencl_c_pipes
-// RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=CL3.0 -cl-ext=-__opencl_c_program_scope_global_variables,+__opencl_c_generic_address_space
-// RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=CL3.0 -cl-ext=+__opencl_c_program_scope_global_variables,+__opencl_c_generic_address_space
-// RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=clc++2021 -cl-ext=-__opencl_c_program_scope_global_variables,-__opencl_c_generic_address_space,-__opencl_c_pipes
-// RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=clc++2021 -cl-ext=+__opencl_c_program_scope_global_variables,-__opencl_c_generic_address_space,-__opencl_c_pipes
-// RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=clc++2021 -cl-ext=-__opencl_c_program_scope_global_variables,+__opencl_c_generic_address_space
-// RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=clc++2021 -cl-ext=+__opencl_c_program_scope_global_variables,+__opencl_c_generic_address_space
+// RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=CL3.0 -cl-ext=-all
+// RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=CL3.0 -cl-ext=-all,+__opencl_c_program_scope_global_variables
+// RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=CL3.0 -cl-ext=-all,+__opencl_c_generic_address_space
+// RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=CL3.0 -cl-ext=-all,+__opencl_c_program_scope_global_variables,+__opencl_c_generic_address_space
+// RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=clc++2021 -cl-ext=-all
+// RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=clc++2021 -cl-ext=-all,+__opencl_c_program_scope_global_variables
+// RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=clc++2021 -cl-ext=-all,+__opencl_c_generic_address_space
+// RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=clc++2021 -cl-ext=-all,+__opencl_c_program_scope_global_variables,+__opencl_c_generic_address_space
 static constant int G1 = 0;
 constant int G2 = 0;
 
Index: clang/test/SemaOpenCL/invalid-pipes-cl2.0.cl

[PATCH] D118337: [clang-format] Fix AllowShortFunctionsOnASingleLine: InlineOnly with wrapping after record.

[Marek Kurdej via Phabricator via cfe-commits]

curdeius added inline comments.



Comment at: clang/lib/Format/UnwrappedLineFormatter.cpp:280
+if (Style.isJavaScript() && (*I)->Last->is(TT_FunctionLBrace))
+  return true;
+

MyDeveloperDay wrote:
> we didn't need this anymore?
Before it was handled in:
```
if (Style.isJavaScript() && RecordTok->is(Keywords.kw_function))
  return true;
```



Comment at: clang/unittests/Format/FormatTest.cpp:12348-12360
+  verifyFormat("struct C\n"
+   "// comment\n"
+   "/* comment */\n"
+   "// comment\n"
+   "{\n"
+   "  int f() { return 42; }\n"
+   "};",

I know that some of these tests look weird but these were failing cases with a 
previous approach.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118337

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

[PATCH] D118260: [clangd][Hover] Suppress initializers with many tokens

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet updated this revision to Diff 403583.
kadircet added a comment.

- Add comments about why we suppress initializer printing


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118260

Files:
  clang-tools-extra/clangd/Hover.cpp
  clang-tools-extra/clangd/unittests/HoverTests.cpp


Index: clang-tools-extra/clangd/unittests/HoverTests.cpp
===
--- clang-tools-extra/clangd/unittests/HoverTests.cpp
+++ clang-tools-extra/clangd/unittests/HoverTests.cpp
@@ -3172,6 +3172,20 @@
   EXPECT_EQ(H->Type, HoverInfo::PrintedType("m_int"));
 }
 
+TEST(Hover, HideBigInitializers) {
+  Annotations T(R"cpp(
+  #define A(x) x, x, x, x
+  #define B(x) A(A(A(A(x
+  int a^rr[] = {B(0)};
+  )cpp");
+
+  TestTU TU = TestTU::withCode(T.code());
+  auto AST = TU.build();
+  auto H = getHover(AST, T.point(), format::getLLVMStyle(), nullptr);
+
+  ASSERT_TRUE(H);
+  EXPECT_EQ(H->Definition, "int arr[]");
+}
 } // namespace
 } // namespace clangd
 } // namespace clang
Index: clang-tools-extra/clangd/Hover.cpp
===
--- clang-tools-extra/clangd/Hover.cpp
+++ clang-tools-extra/clangd/Hover.cpp
@@ -126,7 +126,17 @@
   return "";
 }
 
-std::string printDefinition(const Decl *D, const PrintingPolicy &PP) {
+std::string printDefinition(const Decl *D, PrintingPolicy PP,
+const syntax::TokenBuffer &TB) {
+  if (auto *VD = llvm::dyn_cast(D)) {
+if (auto *IE = VD->getInit()) {
+  // Initializers might be huge and result in lots of memory allocations in
+  // some catostrophic cases. Such long lists are not useful in hover cards
+  // anyway.
+  if (200 < TB.expandedTokens(IE->getSourceRange()).size())
+PP.SuppressInitializers = true;
+}
+  }
   std::string Definition;
   llvm::raw_string_ostream OS(Definition);
   D->print(OS, PP);
@@ -568,7 +578,8 @@
 
 /// Generate a \p Hover object given the declaration \p D.
 HoverInfo getHoverContents(const NamedDecl *D, const PrintingPolicy &PP,
-   const SymbolIndex *Index) {
+   const SymbolIndex *Index,
+   const syntax::TokenBuffer &TB) {
   HoverInfo HI;
   const ASTContext &Ctx = D->getASTContext();
 
@@ -630,7 +641,7 @@
   HI.Value = toString(ECD->getInitVal(), 10);
   }
 
-  HI.Definition = printDefinition(D, PP);
+  HI.Definition = printDefinition(D, PP, TB);
   return HI;
 }
 
@@ -1029,7 +1040,7 @@
   auto Decls = explicitReferenceTargets(N->ASTNode, DeclRelation::Alias,
 AST.getHeuristicResolver());
   if (!Decls.empty()) {
-HI = getHoverContents(Decls.front(), PP, Index);
+HI = getHoverContents(Decls.front(), PP, Index, TB);
 // Layout info only shown when hovering on the field/class itself.
 if (Decls.front() == N->ASTNode.get())
   addLayoutInfo(*Decls.front(), *HI);


Index: clang-tools-extra/clangd/unittests/HoverTests.cpp
===
--- clang-tools-extra/clangd/unittests/HoverTests.cpp
+++ clang-tools-extra/clangd/unittests/HoverTests.cpp
@@ -3172,6 +3172,20 @@
   EXPECT_EQ(H->Type, HoverInfo::PrintedType("m_int"));
 }
 
+TEST(Hover, HideBigInitializers) {
+  Annotations T(R"cpp(
+  #define A(x) x, x, x, x
+  #define B(x) A(A(A(A(x
+  int a^rr[] = {B(0)};
+  )cpp");
+
+  TestTU TU = TestTU::withCode(T.code());
+  auto AST = TU.build();
+  auto H = getHover(AST, T.point(), format::getLLVMStyle(), nullptr);
+
+  ASSERT_TRUE(H);
+  EXPECT_EQ(H->Definition, "int arr[]");
+}
 } // namespace
 } // namespace clangd
 } // namespace clang
Index: clang-tools-extra/clangd/Hover.cpp
===
--- clang-tools-extra/clangd/Hover.cpp
+++ clang-tools-extra/clangd/Hover.cpp
@@ -126,7 +126,17 @@
   return "";
 }
 
-std::string printDefinition(const Decl *D, const PrintingPolicy &PP) {
+std::string printDefinition(const Decl *D, PrintingPolicy PP,
+const syntax::TokenBuffer &TB) {
+  if (auto *VD = llvm::dyn_cast(D)) {
+if (auto *IE = VD->getInit()) {
+  // Initializers might be huge and result in lots of memory allocations in
+  // some catostrophic cases. Such long lists are not useful in hover cards
+  // anyway.
+  if (200 < TB.expandedTokens(IE->getSourceRange()).size())
+PP.SuppressInitializers = true;
+}
+  }
   std::string Definition;
   llvm::raw_string_ostream OS(Definition);
   D->print(OS, PP);
@@ -568,7 +578,8 @@
 
 /// Generate a \p Hover object given the declaration \p D.
 HoverInfo getHoverContents(const NamedDecl *D, const PrintingPolicy &PP,
-   const SymbolIndex *Index) {
+   const SymbolIndex *Index,
+  

[clang-tools-extra] c4e6895 - [clangd][Hover] Suppress initializers with many tokens

[Kadir Cetinkaya via cfe-commits]

Author: Kadir Cetinkaya
Date: 2022-01-27T13:01:55+01:00
New Revision: c4e68953f6443b9854ce3ec1dc8756789beafcc1

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

LOG: [clangd][Hover] Suppress initializers with many tokens

This results in excessive memory usage and eats a lot of screen estate.
Especially in the cases with lots of nested macro calls.

This patch tries to remedy it before the release cut by suppressing the
initializers. For better UX we should probably update the expression printer to
truncate those (behind some policy).

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

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

Added: 


Modified: 
clang-tools-extra/clangd/Hover.cpp
clang-tools-extra/clangd/unittests/HoverTests.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/Hover.cpp 
b/clang-tools-extra/clangd/Hover.cpp
index c5cb5cd3df53a..d1d8142f53cb6 100644
--- a/clang-tools-extra/clangd/Hover.cpp
+++ b/clang-tools-extra/clangd/Hover.cpp
@@ -126,7 +126,17 @@ std::string getNamespaceScope(const Decl *D) {
   return "";
 }
 
-std::string printDefinition(const Decl *D, const PrintingPolicy &PP) {
+std::string printDefinition(const Decl *D, PrintingPolicy PP,
+const syntax::TokenBuffer &TB) {
+  if (auto *VD = llvm::dyn_cast(D)) {
+if (auto *IE = VD->getInit()) {
+  // Initializers might be huge and result in lots of memory allocations in
+  // some catostrophic cases. Such long lists are not useful in hover cards
+  // anyway.
+  if (200 < TB.expandedTokens(IE->getSourceRange()).size())
+PP.SuppressInitializers = true;
+}
+  }
   std::string Definition;
   llvm::raw_string_ostream OS(Definition);
   D->print(OS, PP);
@@ -568,7 +578,8 @@ std::string synthesizeDocumentation(const NamedDecl *ND) {
 
 /// Generate a \p Hover object given the declaration \p D.
 HoverInfo getHoverContents(const NamedDecl *D, const PrintingPolicy &PP,
-   const SymbolIndex *Index) {
+   const SymbolIndex *Index,
+   const syntax::TokenBuffer &TB) {
   HoverInfo HI;
   const ASTContext &Ctx = D->getASTContext();
 
@@ -630,7 +641,7 @@ HoverInfo getHoverContents(const NamedDecl *D, const 
PrintingPolicy &PP,
   HI.Value = toString(ECD->getInitVal(), 10);
   }
 
-  HI.Definition = printDefinition(D, PP);
+  HI.Definition = printDefinition(D, PP, TB);
   return HI;
 }
 
@@ -1029,7 +1040,7 @@ llvm::Optional getHover(ParsedAST &AST, 
Position Pos,
   auto Decls = explicitReferenceTargets(N->ASTNode, DeclRelation::Alias,
 AST.getHeuristicResolver());
   if (!Decls.empty()) {
-HI = getHoverContents(Decls.front(), PP, Index);
+HI = getHoverContents(Decls.front(), PP, Index, TB);
 // Layout info only shown when hovering on the field/class itself.
 if (Decls.front() == N->ASTNode.get())
   addLayoutInfo(*Decls.front(), *HI);

diff  --git a/clang-tools-extra/clangd/unittests/HoverTests.cpp 
b/clang-tools-extra/clangd/unittests/HoverTests.cpp
index 6f5f6ba7b2669..b0974d99f0ac4 100644
--- a/clang-tools-extra/clangd/unittests/HoverTests.cpp
+++ b/clang-tools-extra/clangd/unittests/HoverTests.cpp
@@ -3172,6 +3172,20 @@ TEST(Hover, DisableShowAKA) {
   EXPECT_EQ(H->Type, HoverInfo::PrintedType("m_int"));
 }
 
+TEST(Hover, HideBigInitializers) {
+  Annotations T(R"cpp(
+  #define A(x) x, x, x, x
+  #define B(x) A(A(A(A(x
+  int a^rr[] = {B(0)};
+  )cpp");
+
+  TestTU TU = TestTU::withCode(T.code());
+  auto AST = TU.build();
+  auto H = getHover(AST, T.point(), format::getLLVMStyle(), nullptr);
+
+  ASSERT_TRUE(H);
+  EXPECT_EQ(H->Definition, "int arr[]");
+}
 } // 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] D118260: [clangd][Hover] Suppress initializers with many tokens

[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 rGc4e68953f644: [clangd][Hover] Suppress initializers with 
many tokens (authored by kadircet).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118260

Files:
  clang-tools-extra/clangd/Hover.cpp
  clang-tools-extra/clangd/unittests/HoverTests.cpp


Index: clang-tools-extra/clangd/unittests/HoverTests.cpp
===
--- clang-tools-extra/clangd/unittests/HoverTests.cpp
+++ clang-tools-extra/clangd/unittests/HoverTests.cpp
@@ -3172,6 +3172,20 @@
   EXPECT_EQ(H->Type, HoverInfo::PrintedType("m_int"));
 }
 
+TEST(Hover, HideBigInitializers) {
+  Annotations T(R"cpp(
+  #define A(x) x, x, x, x
+  #define B(x) A(A(A(A(x
+  int a^rr[] = {B(0)};
+  )cpp");
+
+  TestTU TU = TestTU::withCode(T.code());
+  auto AST = TU.build();
+  auto H = getHover(AST, T.point(), format::getLLVMStyle(), nullptr);
+
+  ASSERT_TRUE(H);
+  EXPECT_EQ(H->Definition, "int arr[]");
+}
 } // namespace
 } // namespace clangd
 } // namespace clang
Index: clang-tools-extra/clangd/Hover.cpp
===
--- clang-tools-extra/clangd/Hover.cpp
+++ clang-tools-extra/clangd/Hover.cpp
@@ -126,7 +126,17 @@
   return "";
 }
 
-std::string printDefinition(const Decl *D, const PrintingPolicy &PP) {
+std::string printDefinition(const Decl *D, PrintingPolicy PP,
+const syntax::TokenBuffer &TB) {
+  if (auto *VD = llvm::dyn_cast(D)) {
+if (auto *IE = VD->getInit()) {
+  // Initializers might be huge and result in lots of memory allocations in
+  // some catostrophic cases. Such long lists are not useful in hover cards
+  // anyway.
+  if (200 < TB.expandedTokens(IE->getSourceRange()).size())
+PP.SuppressInitializers = true;
+}
+  }
   std::string Definition;
   llvm::raw_string_ostream OS(Definition);
   D->print(OS, PP);
@@ -568,7 +578,8 @@
 
 /// Generate a \p Hover object given the declaration \p D.
 HoverInfo getHoverContents(const NamedDecl *D, const PrintingPolicy &PP,
-   const SymbolIndex *Index) {
+   const SymbolIndex *Index,
+   const syntax::TokenBuffer &TB) {
   HoverInfo HI;
   const ASTContext &Ctx = D->getASTContext();
 
@@ -630,7 +641,7 @@
   HI.Value = toString(ECD->getInitVal(), 10);
   }
 
-  HI.Definition = printDefinition(D, PP);
+  HI.Definition = printDefinition(D, PP, TB);
   return HI;
 }
 
@@ -1029,7 +1040,7 @@
   auto Decls = explicitReferenceTargets(N->ASTNode, DeclRelation::Alias,
 AST.getHeuristicResolver());
   if (!Decls.empty()) {
-HI = getHoverContents(Decls.front(), PP, Index);
+HI = getHoverContents(Decls.front(), PP, Index, TB);
 // Layout info only shown when hovering on the field/class itself.
 if (Decls.front() == N->ASTNode.get())
   addLayoutInfo(*Decls.front(), *HI);


Index: clang-tools-extra/clangd/unittests/HoverTests.cpp
===
--- clang-tools-extra/clangd/unittests/HoverTests.cpp
+++ clang-tools-extra/clangd/unittests/HoverTests.cpp
@@ -3172,6 +3172,20 @@
   EXPECT_EQ(H->Type, HoverInfo::PrintedType("m_int"));
 }
 
+TEST(Hover, HideBigInitializers) {
+  Annotations T(R"cpp(
+  #define A(x) x, x, x, x
+  #define B(x) A(A(A(A(x
+  int a^rr[] = {B(0)};
+  )cpp");
+
+  TestTU TU = TestTU::withCode(T.code());
+  auto AST = TU.build();
+  auto H = getHover(AST, T.point(), format::getLLVMStyle(), nullptr);
+
+  ASSERT_TRUE(H);
+  EXPECT_EQ(H->Definition, "int arr[]");
+}
 } // namespace
 } // namespace clangd
 } // namespace clang
Index: clang-tools-extra/clangd/Hover.cpp
===
--- clang-tools-extra/clangd/Hover.cpp
+++ clang-tools-extra/clangd/Hover.cpp
@@ -126,7 +126,17 @@
   return "";
 }
 
-std::string printDefinition(const Decl *D, const PrintingPolicy &PP) {
+std::string printDefinition(const Decl *D, PrintingPolicy PP,
+const syntax::TokenBuffer &TB) {
+  if (auto *VD = llvm::dyn_cast(D)) {
+if (auto *IE = VD->getInit()) {
+  // Initializers might be huge and result in lots of memory allocations in
+  // some catostrophic cases. Such long lists are not useful in hover cards
+  // anyway.
+  if (200 < TB.expandedTokens(IE->getSourceRange()).size())
+PP.SuppressInitializers = true;
+}
+  }
   std::string Definition;
   llvm::raw_string_ostream OS(Definition);
   D->print(OS, PP);
@@ -568,7 +578,8 @@
 
 /// Generate a \p Hover object given the declaration \p D.
 HoverInfo getHoverContents(const NamedDecl *D, const PrintingPolicy &PP,
-  

[PATCH] D114439: [Annotation] Allow parameter pack expansions and initializer lists in annotate attribute

[Steffen Larsen via Phabricator via cfe-commits]

steffenlarsen updated this revision to Diff 403578.
steffenlarsen retitled this revision from "[Annotation] Allow parameter pack 
expansions in annotate attribute" to "[Annotation] Allow parameter pack 
expansions and initializer lists in annotate attribute".
steffenlarsen edited the summary of this revision.

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

https://reviews.llvm.org/D114439

Files:
  clang/include/clang/AST/Attr.h
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/include/clang/Parse/Parser.h
  clang/include/clang/Sema/Sema.h
  clang/lib/Parse/ParseDecl.cpp
  clang/lib/Parse/ParseExpr.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
  clang/test/Parser/cxx0x-attributes.cpp
  clang/test/SemaTemplate/attributes.cpp
  clang/utils/TableGen/ClangAttrEmitter.cpp

Index: clang/utils/TableGen/ClangAttrEmitter.cpp
===
--- clang/utils/TableGen/ClangAttrEmitter.cpp
+++ clang/utils/TableGen/ClangAttrEmitter.cpp
@@ -2138,6 +2138,11 @@
   }
 }
 
+static bool isTypeArgument(const Record *Arg) {
+  return !Arg->getSuperClasses().empty() &&
+ Arg->getSuperClasses().back().first->getName() == "TypeArgument";
+}
+
 /// Emits the first-argument-is-type property for attributes.
 static void emitClangAttrTypeArgList(RecordKeeper &Records, raw_ostream &OS) {
   OS << "#if defined(CLANG_ATTR_TYPE_ARG_LIST)\n";
@@ -2149,7 +2154,7 @@
 if (Args.empty())
   continue;
 
-if (Args[0]->getSuperClasses().back().first->getName() != "TypeArgument")
+if (!isTypeArgument(Args[0]))
   continue;
 
 // All these spellings take a single type argument.
@@ -2179,7 +2184,7 @@
   OS << "#endif // CLANG_ATTR_ARG_CONTEXT_LIST\n\n";
 }
 
-static bool isIdentifierArgument(Record *Arg) {
+static bool isIdentifierArgument(const Record *Arg) {
   return !Arg->getSuperClasses().empty() &&
 llvm::StringSwitch(Arg->getSuperClasses().back().first->getName())
 .Case("IdentifierArgument", true)
@@ -2188,7 +2193,7 @@
 .Default(false);
 }
 
-static bool isVariadicIdentifierArgument(Record *Arg) {
+static bool isVariadicIdentifierArgument(const Record *Arg) {
   return !Arg->getSuperClasses().empty() &&
  llvm::StringSwitch(
  Arg->getSuperClasses().back().first->getName())
@@ -2264,6 +2269,26 @@
   OS << "#endif // CLANG_ATTR_THIS_ISA_IDENTIFIER_ARG_LIST\n\n";
 }
 
+static void emitClangAttrAcceptsExprPack(RecordKeeper &Records,
+ raw_ostream &OS) {
+  OS << "#if defined(CLANG_ATTR_ACCEPTS_EXPR_PACK)\n";
+  ParsedAttrMap Attrs = getParsedAttrList(Records);
+  for (const auto &I : Attrs) {
+const Record &Attr = *I.second;
+
+if (!Attr.getValueAsBit("AcceptsExprPack"))
+  continue;
+
+// All these spellings take are parsed unevaluated.
+forEachUniqueSpelling(Attr, [&](const FlattenedSpelling &S) {
+  OS << ".Case(\"" << S.name() << "\", "
+ << "true"
+ << ")\n";
+});
+  }
+  OS << "#endif // CLANG_ATTR_ACCEPTS_EXPR_PACK\n\n";
+}
+
 static void emitAttributes(RecordKeeper &Records, raw_ostream &OS,
bool Header) {
   std::vector Attrs = Records.getAllDerivedDefinitions("Attr");
@@ -2320,6 +2345,17 @@
 std::vector> Args;
 Args.reserve(ArgRecords.size());
 
+bool AttrAcceptsExprPack = Attr->getValueAsBit("AcceptsExprPack");
+assert((!AttrAcceptsExprPack ||
+std::none_of(ArgRecords.begin(), ArgRecords.end(),
+ [&](const Record *ArgR) {
+   return isIdentifierArgument(ArgR) ||
+  isVariadicIdentifierArgument(ArgR) ||
+  isTypeArgument(ArgR);
+ })) &&
+   "Attributes accepting packs cannot also have identifier or type "
+   "arguments.");
+
 bool HasOptArg = false;
 bool HasFakeArg = false;
 for (const auto *ArgRecord : ArgRecords) {
@@ -2611,6 +2647,7 @@
   OS << "  A->Inherited = Inherited;\n";
   OS << "  A->IsPackExpansion = IsPackExpansion;\n";
   OS << "  A->setImplicit(Implicit);\n";
+  OS << "  A->setArgsDelayed(ArgsDelayed);\n";
   OS << "  return A;\n}\n\n";
 
   writePrettyPrintFunction(R, Args, OS);
@@ -2936,6 +2973,7 @@
   OS << "bool isInherited = Record.readInt();\n";
 OS << "bool isImplicit = Record.readInt();\n";
 OS << "bool isPackExpansion = Record.readInt();\n";
+OS << "bool areArgsDelayed = Record.readInt();\n";
 ArgRecords = R.getValueAsListOfDefs("Args");
 Args.clear();
 for (const auto *Arg : ArgRecords) {
@@ -2952,6 +2990,7 @@
   OS << "cast(New)->setInherited(isInherited);\n";
 OS << "New->setImplicit(isImplicit);\n";
 OS << "New->setPackExpansion(isPackExpansion);\n";
+OS << "New->setArgsDelayed(areArgsDelaye

[PATCH] D114439: [Annotation] Allow parameter pack expansions and initializer lists in annotate attribute

[Steffen Larsen via Phabricator via cfe-commits]

steffenlarsen added a comment.

Upon offline sync with @aaron.ballman and @erichkeane  I have changed the 
strategy of this patch to lift the restriction of pack expansion not spanning 
argument boundaries. This is implemented in `clang::annotate` by delaying 
arguments to after template-instantiation if any of the arguments are value 
dependent.


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

https://reviews.llvm.org/D114439

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

[PATCH] D118350: [AIX][PowerPC] Emit byval alignment warning only when struct member is passed to a function

[Zarko Todorovski via Phabricator via cfe-commits]

ZarkoCA created this revision.
ZarkoCA added reviewers: hubert.reinterpretcast, sfertile, cebowleratibm, 
stevewan, Jake-Egan, aaron.ballman, tmatheson, dnsampaio.
ZarkoCA added projects: clang, PowerPC.
Herald added subscribers: shchenz, nemanjai.
ZarkoCA requested review of this revision.
Herald added a subscriber: cfe-commits.

Previous warning went on whenever a struct with a struct member with alignment 
=> 16 was declared.
This led to too many false positives and led to diagnostic lit failures due to 
it being emitted
too frequently. Only emit the warning when such an argument is passed to a 
caller function since
this is where the potential binary compatibility issue with XL 16.1.0 and older 
exists.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D118350

Files:
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/Sema/aix-attr-align.c

Index: clang/test/Sema/aix-attr-align.c
===
--- clang/test/Sema/aix-attr-align.c
+++ clang/test/Sema/aix-attr-align.c
@@ -6,17 +6,31 @@
 // RUN: %clang_cc1 -triple powerpc64le-unknown-linux -verify=off -fsyntax-only %s
 
 struct S {
-  int a[8] __attribute__((aligned(8))); // no-warning
+  int a[8] __attribute__((aligned(8)));  // no-warning
+  int b[8] __attribute__((aligned(16))); // no-warning
+  int c[2] __attribute__((aligned(32))); // no-warning
 };
 
 struct T {
-  int a[4] __attribute__((aligned(16))); // expected-warning {{requesting an alignment of 16 bytes or greater for struct members is not binary compatible with IBM XL C/C++ for AIX 16.1.0 and older}}
+  int a[4] __attribute__((aligned(16))); // no-warning
 };
 
 struct U {
-  int a[2] __attribute__((aligned(32))); // expected-warning {{requesting an alignment of 16 bytes or greater for struct members is not binary compatible with IBM XL C/C++ for AIX 16.1.0 and older}}
+  int a[2] __attribute__((aligned(32))); // no-warning
 };
 
 int a[8] __attribute__((aligned(8)));  // no-warning
 int b[4] __attribute__((aligned(16))); // no-warning
 int c[2] __attribute__((aligned(32))); // no-warning
+
+void baz(int *);
+void foo(int p1, int p2, int p3, int p4, int p5, int p6, int p7, int p8,
+ struct S s) {
+  baz(s.a); // no-warning
+  baz(s.b); // expected-warning {{requesting an alignment of 16 bytes or greater for struct members is not binary compatible with IBM XL C/C++ for AIX 16.1.0 and older}}
+  baz(s.c); // expected-warning {{requesting an alignment of 16 bytes or greater for struct members is not binary compatible with IBM XL C/C++ for AIX 16.1.0 and older}}
+
+  baz(a); // no-warning
+  baz(b); // no-warning
+  baz(c); // no-warning
+}
Index: clang/lib/Sema/SemaDeclAttr.cpp
===
--- clang/lib/Sema/SemaDeclAttr.cpp
+++ clang/lib/Sema/SemaDeclAttr.cpp
@@ -4320,13 +4320,6 @@
 return;
 
   uint64_t AlignVal = Alignment.getZExtValue();
-  // 16 byte ByVal alignment not due to a vector member is not honoured by XL
-  // on AIX. Emit a warning here that users are generating binary incompatible
-  // code to be safe.
-  if (AlignVal >= 16 && isa(D) &&
-  Context.getTargetInfo().getTriple().isOSAIX())
-Diag(AttrLoc, diag::warn_not_xl_compatible) << E->getSourceRange();
-
   // C++11 [dcl.align]p2:
   //   -- if the constant expression evaluates to zero, the alignment
   //  specifier shall have no effect
Index: clang/lib/Sema/SemaChecking.cpp
===
--- clang/lib/Sema/SemaChecking.cpp
+++ clang/lib/Sema/SemaChecking.cpp
@@ -5207,7 +5207,37 @@
 /// calling functions defined in terms of the original type.
 void Sema::CheckArgAlignment(SourceLocation Loc, NamedDecl *FDecl,
  StringRef ParamName, QualType ArgTy,
- QualType ParamTy) {
+ QualType ParamTy, const Expr* Arg) {
+
+  // 16 byte ByVal alignment not due to a vector member is not honoured by XL
+  // on AIX. Emit a warning here that users are generating binary incompatible
+  // code to be safe.
+  // Here we try to get information about the alignment of the struct member
+  // argument passed to function.
+  if (Context.getTargetInfo().getTriple().isOSAIX()) {
+if (Arg->IgnoreParens()) {
+  // Using AArg so as to not modify Arg for the rest of the function.
+  const Expr *AArg = Arg->IgnoreParens();
+  if (AArg->getStmtClass() == Stmt::ImplicitCastExprClass) {
+const ImplicitCastExpr *ICE = dyn_cast(AArg);
+AArg = ICE->getSubExpr();
+if (AArg->getStmtClass() == Stmt::MemberExprClass) {
+  const auto *ME = dyn_cast(AArg);
+  ValueDecl *MD = ME->getMemberDecl();
+  auto *FD = dyn_cast(MD);
+  if (FD) {
+if (FD->hasAttr()) {
+  auto *AA = FD->getAttr();
+  unsigned Aligned = AA->getA

[PATCH] D114639: Raise the minimum Visual Studio version to VS2019

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.
Herald added a subscriber: JDevlieghere.

In D114639#3273831 , @RKSimon wrote:

> In D114639#3273761 , 
> @stella.stamenova wrote:
>
>> Can we update the lldb instructions as part of this change to also point to 
>> VS2019? Alternatively, I can send a separate change for that.
>
> I'll add it to this patch - are people happy for me to get this in before the 
> 14.x branch?

I'm fine with that (we can always roll it back in the branch if it turns out to 
be a burden).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114639

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

[PATCH] D118021: [Driver] Use libatomic for 32-bit SPARC atomics support

[Rainer Orth via Phabricator via cfe-commits]

ro updated this revision to Diff 403604.
ro added a comment.
Herald added a project: Sanitizers.
Herald added a subscriber: Sanitizers.

- Clarify comment.
- Use `__ATOMIC_SEQ_CST`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118021

Files:
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/lib/Driver/ToolChains/CommonArgs.h
  clang/lib/Driver/ToolChains/Solaris.cpp
  compiler-rt/lib/sanitizer_common/sanitizer_atomic_clang.h


Index: compiler-rt/lib/sanitizer_common/sanitizer_atomic_clang.h
===
--- compiler-rt/lib/sanitizer_common/sanitizer_atomic_clang.h
+++ compiler-rt/lib/sanitizer_common/sanitizer_atomic_clang.h
@@ -74,13 +74,8 @@
 inline bool atomic_compare_exchange_strong(volatile T *a, typename T::Type 
*cmp,
typename T::Type xchg,
memory_order mo) {
-  typedef typename T::Type Type;
-  Type cmpv = *cmp;
-  Type prev;
-  prev = __sync_val_compare_and_swap(&a->val_dont_use, cmpv, xchg);
-  if (prev == cmpv) return true;
-  *cmp = prev;
-  return false;
+  return __atomic_compare_exchange(&a->val_dont_use, cmp, &xchg, false, mo,
+   __ATOMIC_SEQ_CST);
 }
 
 template
Index: clang/lib/Driver/ToolChains/Solaris.cpp
===
--- clang/lib/Driver/ToolChains/Solaris.cpp
+++ clang/lib/Driver/ToolChains/Solaris.cpp
@@ -132,6 +132,13 @@
   CmdArgs.push_back("-lssp_nonshared");
   CmdArgs.push_back("-lssp");
 }
+// LLVM support for atomics on 32-bit SPARC V8+ is incomplete, so
+// forcibly link with libatomic as a workaround.
+if (getToolChain().getTriple().getArch() == llvm::Triple::sparc) {
+  CmdArgs.push_back(getAsNeededOption(getToolChain(), true));
+  CmdArgs.push_back("-latomic");
+  CmdArgs.push_back(getAsNeededOption(getToolChain(), false));
+}
 CmdArgs.push_back("-lgcc_s");
 CmdArgs.push_back("-lc");
 if (!Args.hasArg(options::OPT_shared)) {
Index: clang/lib/Driver/ToolChains/CommonArgs.h
===
--- clang/lib/Driver/ToolChains/CommonArgs.h
+++ clang/lib/Driver/ToolChains/CommonArgs.h
@@ -114,6 +114,8 @@
   bool ForceStaticHostRuntime = false,
   bool IsOffloadingHost = false, bool GompNeedsRT = false);
 
+const char *getAsNeededOption(const ToolChain &TC, bool as_needed);
+
 llvm::opt::Arg *getLastProfileUseArg(const llvm::opt::ArgList &Args);
 llvm::opt::Arg *getLastProfileSampleUseArg(const llvm::opt::ArgList &Args);
 
Index: clang/lib/Driver/ToolChains/CommonArgs.cpp
===
--- clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -737,7 +737,7 @@
   return false;
 }
 
-static const char *getAsNeededOption(const ToolChain &TC, bool as_needed) {
+const char *tools::getAsNeededOption(const ToolChain &TC, bool as_needed) {
   assert(!TC.getTriple().isOSAIX() &&
  "AIX linker does not support any form of --as-needed option yet.");
 


Index: compiler-rt/lib/sanitizer_common/sanitizer_atomic_clang.h
===
--- compiler-rt/lib/sanitizer_common/sanitizer_atomic_clang.h
+++ compiler-rt/lib/sanitizer_common/sanitizer_atomic_clang.h
@@ -74,13 +74,8 @@
 inline bool atomic_compare_exchange_strong(volatile T *a, typename T::Type *cmp,
typename T::Type xchg,
memory_order mo) {
-  typedef typename T::Type Type;
-  Type cmpv = *cmp;
-  Type prev;
-  prev = __sync_val_compare_and_swap(&a->val_dont_use, cmpv, xchg);
-  if (prev == cmpv) return true;
-  *cmp = prev;
-  return false;
+  return __atomic_compare_exchange(&a->val_dont_use, cmp, &xchg, false, mo,
+   __ATOMIC_SEQ_CST);
 }
 
 template
Index: clang/lib/Driver/ToolChains/Solaris.cpp
===
--- clang/lib/Driver/ToolChains/Solaris.cpp
+++ clang/lib/Driver/ToolChains/Solaris.cpp
@@ -132,6 +132,13 @@
   CmdArgs.push_back("-lssp_nonshared");
   CmdArgs.push_back("-lssp");
 }
+// LLVM support for atomics on 32-bit SPARC V8+ is incomplete, so
+// forcibly link with libatomic as a workaround.
+if (getToolChain().getTriple().getArch() == llvm::Triple::sparc) {
+  CmdArgs.push_back(getAsNeededOption(getToolChain(), true));
+  CmdArgs.push_back("-latomic");
+  CmdArgs.push_back(getAsNeededOption(getToolChain(), false));
+}
 CmdArgs.push_back("-lgcc_s");
 CmdArgs.push_back("-lc");
 if (!Args.hasArg(options::OPT_shared)) {
Index: clang/lib/Driver/ToolChains/CommonArgs.h

[PATCH] D118021: [Driver] Use libatomic for 32-bit SPARC atomics support

[Rainer Orth via Phabricator via cfe-commits]

ro updated this revision to Diff 403607.
ro marked an inline comment as done.
ro added a comment.

Omit `sanitizer_atomic_clang.h` part, belongs to D118021 
.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118021

Files:
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/lib/Driver/ToolChains/CommonArgs.h
  clang/lib/Driver/ToolChains/Solaris.cpp


Index: clang/lib/Driver/ToolChains/Solaris.cpp
===
--- clang/lib/Driver/ToolChains/Solaris.cpp
+++ clang/lib/Driver/ToolChains/Solaris.cpp
@@ -132,6 +132,13 @@
   CmdArgs.push_back("-lssp_nonshared");
   CmdArgs.push_back("-lssp");
 }
+// LLVM support for atomics on 32-bit SPARC V8+ is incomplete, so
+// forcibly link with libatomic as a workaround.
+if (getToolChain().getTriple().getArch() == llvm::Triple::sparc) {
+  CmdArgs.push_back(getAsNeededOption(getToolChain(), true));
+  CmdArgs.push_back("-latomic");
+  CmdArgs.push_back(getAsNeededOption(getToolChain(), false));
+}
 CmdArgs.push_back("-lgcc_s");
 CmdArgs.push_back("-lc");
 if (!Args.hasArg(options::OPT_shared)) {
Index: clang/lib/Driver/ToolChains/CommonArgs.h
===
--- clang/lib/Driver/ToolChains/CommonArgs.h
+++ clang/lib/Driver/ToolChains/CommonArgs.h
@@ -114,6 +114,8 @@
   bool ForceStaticHostRuntime = false,
   bool IsOffloadingHost = false, bool GompNeedsRT = false);
 
+const char *getAsNeededOption(const ToolChain &TC, bool as_needed);
+
 llvm::opt::Arg *getLastProfileUseArg(const llvm::opt::ArgList &Args);
 llvm::opt::Arg *getLastProfileSampleUseArg(const llvm::opt::ArgList &Args);
 
Index: clang/lib/Driver/ToolChains/CommonArgs.cpp
===
--- clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -737,7 +737,7 @@
   return false;
 }
 
-static const char *getAsNeededOption(const ToolChain &TC, bool as_needed) {
+const char *tools::getAsNeededOption(const ToolChain &TC, bool as_needed) {
   assert(!TC.getTriple().isOSAIX() &&
  "AIX linker does not support any form of --as-needed option yet.");
 


Index: clang/lib/Driver/ToolChains/Solaris.cpp
===
--- clang/lib/Driver/ToolChains/Solaris.cpp
+++ clang/lib/Driver/ToolChains/Solaris.cpp
@@ -132,6 +132,13 @@
   CmdArgs.push_back("-lssp_nonshared");
   CmdArgs.push_back("-lssp");
 }
+// LLVM support for atomics on 32-bit SPARC V8+ is incomplete, so
+// forcibly link with libatomic as a workaround.
+if (getToolChain().getTriple().getArch() == llvm::Triple::sparc) {
+  CmdArgs.push_back(getAsNeededOption(getToolChain(), true));
+  CmdArgs.push_back("-latomic");
+  CmdArgs.push_back(getAsNeededOption(getToolChain(), false));
+}
 CmdArgs.push_back("-lgcc_s");
 CmdArgs.push_back("-lc");
 if (!Args.hasArg(options::OPT_shared)) {
Index: clang/lib/Driver/ToolChains/CommonArgs.h
===
--- clang/lib/Driver/ToolChains/CommonArgs.h
+++ clang/lib/Driver/ToolChains/CommonArgs.h
@@ -114,6 +114,8 @@
   bool ForceStaticHostRuntime = false,
   bool IsOffloadingHost = false, bool GompNeedsRT = false);
 
+const char *getAsNeededOption(const ToolChain &TC, bool as_needed);
+
 llvm::opt::Arg *getLastProfileUseArg(const llvm::opt::ArgList &Args);
 llvm::opt::Arg *getLastProfileSampleUseArg(const llvm::opt::ArgList &Args);
 
Index: clang/lib/Driver/ToolChains/CommonArgs.cpp
===
--- clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -737,7 +737,7 @@
   return false;
 }
 
-static const char *getAsNeededOption(const ToolChain &TC, bool as_needed) {
+const char *tools::getAsNeededOption(const ToolChain &TC, bool as_needed) {
   assert(!TC.getTriple().isOSAIX() &&
  "AIX linker does not support any form of --as-needed option yet.");
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D117416: [clang-format] Handle C variables with name that matches c++ access specifier

[Marek Kurdej via Phabricator via cfe-commits]

curdeius added a comment.

Have you updated the diff? I still see `std::set` and not a sorted vector.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117416

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

[PATCH] D117753: [AArch64] Support for memset tagged intrinsic

[Dave Green via Phabricator via cfe-commits]

dmgreen added inline comments.



Comment at: clang/lib/Headers/arm_acle.h:734
+/* Memory Operations Intrinsics */
+#if __ARM_FEATURE_MOPS && __ARM_FEATURE_MEMORY_TAGGING
+#define __arm_mops_memset_tag(tagged_address, value, size) 
\

tyb0807 wrote:
> SjoerdMeijer wrote:
> > Why does this also need MTE? I think the ACLE specifies this intrinsic to 
> > be available when __ARM_FEATURE_MOPS is defined?
> Yes you are right, thanks for spotting this.
Hmm. These map to SETMG, and those instructions require MTE. It wouldn't make 
sense to have an intrinsic that cannot be emitted to a valid instruction. I 
think the spec might be wrong, to be honest.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117753

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

[PATCH] D117795: [AArch64] Add some missing strict FP vector lowering

[John Brawn via Phabricator via cfe-commits]

john.brawn updated this revision to Diff 403614.
john.brawn retitled this revision from "[AArch64] Fixes for strict FP vector 
instructions" to "[AArch64] Add some missing strict FP vector lowering".
john.brawn edited the summary of this revision.
john.brawn added a comment.

The other parts of this have been split off into D118257 
, D118258 , 
and D118259 . I've also added some extra 
testing, as the clang test aarch64-neon-intrinsics-constrained wasn't actually 
testing all of the changes here.


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

https://reviews.llvm.org/D117795

Files:
  llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
  llvm/test/CodeGen/AArch64/fp-intrinsics-vector.ll

Index: llvm/test/CodeGen/AArch64/fp-intrinsics-vector.ll
===
--- /dev/null
+++ llvm/test/CodeGen/AArch64/fp-intrinsics-vector.ll
@@ -0,0 +1,886 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -mtriple=aarch64-none-eabi %s -disable-strictnode-mutation -o - | FileCheck %s
+; RUN: llc -mtriple=aarch64-none-eabi -global-isel=true -global-isel-abort=2 -disable-strictnode-mutation %s -o - | FileCheck %s
+
+; Check that constrained fp vector intrinsics are correctly lowered.
+
+
+; Single-precision intrinsics
+
+define <4 x float> @add_v4f32(<4 x float> %x, <4 x float> %y) #0 {
+; CHECK-LABEL: add_v4f32:
+; CHECK:   // %bb.0:
+; CHECK-NEXT:fadd v0.4s, v0.4s, v1.4s
+; CHECK-NEXT:ret
+  %val = call <4 x float> @llvm.experimental.constrained.fadd.v4f32(<4 x float> %x, <4 x float> %y, metadata !"round.tonearest", metadata !"fpexcept.strict") #0
+  ret <4 x float> %val
+}
+
+define <4 x float> @sub_v4f32(<4 x float> %x, <4 x float> %y) #0 {
+; CHECK-LABEL: sub_v4f32:
+; CHECK:   // %bb.0:
+; CHECK-NEXT:fsub v0.4s, v0.4s, v1.4s
+; CHECK-NEXT:ret
+  %val = call <4 x float> @llvm.experimental.constrained.fsub.v4f32(<4 x float> %x, <4 x float> %y, metadata !"round.tonearest", metadata !"fpexcept.strict") #0
+  ret <4 x float> %val
+}
+
+define <4 x float> @mul_v4f32(<4 x float> %x, <4 x float> %y) #0 {
+; CHECK-LABEL: mul_v4f32:
+; CHECK:   // %bb.0:
+; CHECK-NEXT:fmul v0.4s, v0.4s, v1.4s
+; CHECK-NEXT:ret
+  %val = call <4 x float> @llvm.experimental.constrained.fmul.v4f32(<4 x float> %x, <4 x float> %y, metadata !"round.tonearest", metadata !"fpexcept.strict") #0
+  ret <4 x float> %val
+}
+
+define <4 x float> @div_v4f32(<4 x float> %x, <4 x float> %y) #0 {
+; CHECK-LABEL: div_v4f32:
+; CHECK:   // %bb.0:
+; CHECK-NEXT:fdiv v0.4s, v0.4s, v1.4s
+; CHECK-NEXT:ret
+  %val = call <4 x float> @llvm.experimental.constrained.fdiv.v4f32(<4 x float> %x, <4 x float> %y, metadata !"round.tonearest", metadata !"fpexcept.strict") #0
+  ret <4 x float> %val
+}
+
+define <4 x float> @fma_v4f32(<4 x float> %x, <4 x float> %y, <4 x float> %z) #0 {
+; CHECK-LABEL: fma_v4f32:
+; CHECK:   // %bb.0:
+; CHECK-NEXT:fmla v2.4s, v1.4s, v0.4s
+; CHECK-NEXT:mov v0.16b, v2.16b
+; CHECK-NEXT:ret
+  %val = call <4 x float> @llvm.experimental.constrained.fma.v4f32(<4 x float> %x, <4 x float> %y, <4 x float> %z, metadata !"round.tonearest", metadata !"fpexcept.strict") #0
+  ret <4 x float> %val
+}
+
+define <4 x i32> @fptosi_v4i32_v4f32(<4 x float> %x) #0 {
+; CHECK-LABEL: fptosi_v4i32_v4f32:
+; CHECK:   // %bb.0:
+; CHECK-NEXT:fcvtzs v0.4s, v0.4s
+; CHECK-NEXT:ret
+  %val = call <4 x i32> @llvm.experimental.constrained.fptosi.v4i32.v4f32(<4 x float> %x, metadata !"fpexcept.strict") #0
+  ret <4 x i32> %val
+}
+
+define <4 x i32> @fptoui_v4i32_v4f32(<4 x float> %x) #0 {
+; CHECK-LABEL: fptoui_v4i32_v4f32:
+; CHECK:   // %bb.0:
+; CHECK-NEXT:fcvtzu v0.4s, v0.4s
+; CHECK-NEXT:ret
+  %val = call <4 x i32> @llvm.experimental.constrained.fptoui.v4i32.v4f32(<4 x float> %x, metadata !"fpexcept.strict") #0
+  ret <4 x i32> %val
+}
+
+define <4 x i64> @fptosi_v4i64_v4f32(<4 x float> %x) #0 {
+; CHECK-LABEL: fptosi_v4i64_v4f32:
+; CHECK:   // %bb.0:
+; CHECK-NEXT:ext v1.16b, v0.16b, v0.16b, #8
+; CHECK-NEXT:fcvtl v0.2d, v0.2s
+; CHECK-NEXT:fcvtl v1.2d, v1.2s
+; CHECK-NEXT:fcvtzs v0.2d, v0.2d
+; CHECK-NEXT:fcvtzs v1.2d, v1.2d
+; CHECK-NEXT:ret
+  %val = call <4 x i64> @llvm.experimental.constrained.fptosi.v4i64.v4f32(<4 x float> %x, metadata !"fpexcept.strict") #0
+  ret <4 x i64> %val
+}
+
+define <4 x i64> @fptoui_v4i64_v4f32(<4 x float> %x) #0 {
+; CHECK-LABEL: fptoui_v4i64_v4f32:
+; CHECK:   // %bb.0:
+; CHECK-NEXT:ext v1.16b, v0.16b, v0.16b, #8
+; CHECK-NEXT:fcvtl v0.2d, v0.2s
+; CHECK-NEXT:fcvtl v1.2d, v1.2s
+; CHECK-NEXT:fcvtzu v0.2d, v0.2d
+; CHECK-NEXT:fcvtzu v1.2d, v1.2d
+; CHECK-NEXT:ret
+  %val = call <4 x i64> @llvm.experimental.constrained.fptoui.v4i64.v4f32(<4 x float> %x, metadata !"fpexcept.s

[PATCH] D118337: [clang-format] Fix AllowShortFunctionsOnASingleLine: InlineOnly with wrapping after record.

[Zhihao Yuan via Phabricator via cfe-commits]

lichray added a comment.

Looks nice, and works for me.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118337

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

[PATCH] D115232: [clangd] Indexing of standard library

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet added a comment.

thanks LG, mostly nits and a couple of questions




Comment at: clang-tools-extra/clangd/ClangdServer.cpp:91
+if (Tasks)
+  Tasks->runAsync("IndexStdlib", std::move(Task));
+else

I suppose this should be rare hence won't bite us in practice, but might worth 
having a comment mentioning this creates tasks with no barriers.



Comment at: clang-tools-extra/clangd/index/StdLib.cpp:44
+  }
+  return L == CXX ? llvm::StringLiteral("vector") : "stdio.h";
+}

`llvm_uncreachable` instead?



Comment at: clang-tools-extra/clangd/index/StdLib.cpp:49
+  if (LO.CPlusPlus) {
+return !LO.CPlusPlus11   ? LangStandard::lang_cxx98
+   : !LO.CPlusPlus14 ? LangStandard::lang_cxx11

nit: this feels a little bit hard to read, what about:
```
if(2b) return 2b;
if(20) return 20;
...
return 98;
```



Comment at: clang-tools-extra/clangd/index/StdLib.cpp:56
+  }
+  return !LO.C11 ? LangStandard::lang_c99
+ // C17 has no new features, so treat C14 as C17.

same here



Comment at: clang-tools-extra/clangd/index/StdLib.cpp:92
+  // The umbrella header is the same for all versions of each language.
+  // Headers that are unsupported in old lang versions are usually guarded by
+  // #if. Some headers may be not present in old stdlib versions, the umbrella

maybe move second half of this comment into `buildUmbrella` ?



Comment at: clang-tools-extra/clangd/index/StdLib.cpp:121
+// We want to drop these, they're a bit tricky to identify:
+//  - we don't want to limit to symbols our our list, as our list has only
+//top-level symbols (and there may be legitimate stdlib extensions).

s/our our/to our/



Comment at: clang-tools-extra/clangd/index/StdLib.cpp:131
+// another header that defines a symbol from our stdlib list.
+static SymbolSlab filter(SymbolSlab Slab, const StdLibLocation &Loc) {
+  SymbolSlab::Builder Result;

drop static, and move into previous anonymous namespace ?



Comment at: clang-tools-extra/clangd/index/StdLib.cpp:142
+ })
+  Set->insert(Name);
+return Set;

s/Name/Header/ ?



Comment at: clang-tools-extra/clangd/index/StdLib.cpp:160
+if (!S.IncludeHeaders.empty() &&
+StandardHeaders.contains(S.IncludeHeaders.front().IncludeHeader)) {
+  GoodHeader[S.CanonicalDeclaration.FileURI] = true;

`StandardHeaders` are always in verbatim format, but are we sure if that holds 
for the `IncludeHeader` ?

I suppose that should be the case since we map known path suffixes back to a 
verbatim umbrella header, I just wonder how exhaustive the list is. (it might 
be nice to manually check no implementation detail headers falls out of cracks)



Comment at: clang-tools-extra/clangd/index/StdLib.cpp:177
+  }
+  for (const auto &Good : GoodHeader)
+if (Good.second)

seems like debugging artifact, either drop or put in `#ifndef NDEBUG`



Comment at: clang-tools-extra/clangd/index/StdLib.cpp:204
+  !CI->getPreprocessorOpts().ImplicitPCHInclude.empty()) {
+elog("Indexing standard library failed: bad CompilerInvocation");
+assert(false && "indexing stdlib with a dubious CompilerInvocation!");

why log if we think we can't hit this case?



Comment at: clang-tools-extra/clangd/index/StdLib.cpp:216
+  IgnoreDiagnostics IgnoreDiags;
+  CI->getPreprocessorOpts().clearRemappedFiles();
+  auto Clang = prepareCompilerInstance(

why are we doing this exactly? once we override the same file multiple times, I 
believe the last one takes precedence. it's definitely safer to clear the 
remapped files here rather than relying on that fact, but I am afraid of losing 
other mappings, possibly set outside of clangd's knowledge (e.g. through flags 
like `-remap-file`?)



Comment at: clang-tools-extra/clangd/index/StdLib.cpp:233
+  // Sadly we can't use IndexOpts.FileFilter to restrict indexing scope.
+  // Files from outside the location may define true std symbols anyway.
+  // We end up "blessing" such headers, and can only do that by indexing

what does `the location` refer to here? I think we should also stress the fact 
that even when indexing the same file, we have a good chance of seeing 
different symbols due to PP directives (and different std versions)



Comment at: clang-tools-extra/clangd/index/StdLib.cpp:237
+
+  // Refs, relations, containers in the stdlib mostly aren't useful.
+  auto Action = createStaticIndexingAction(

s/containers/include graph



Comment at: clang-tools-extra/clangd/index/StdLib.cpp:256
+  if (HadErrors) {
+log("Errors when generating the sta

[PATCH] D118355: Add -mmanual-endbr switch to allow manual selection of control-flow protection

[Gabriel F. T. Gomes via Phabricator via cfe-commits]

gftg created this revision.
gftg added reviewers: xiangzhangllvm, pengfei, erichkeane, joaomoreira.
Herald added subscribers: ormris, dexonsmith, dang, jdoerfert, steven_wu, 
martong, hiraditya.
Herald added a reviewer: aaron.ballman.
gftg requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

GCC has plans [1] to add a new switch that enables finer-grained control
of the insertion of CET stuff in generated code. This patch duplicates
their implementation within LLVM, in the hope that it can also be used
by Xen maintainers.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102953

---8<---
With -fcf-protection=branch, clang automatically adds control-flow
protection to indirect calls and jumps. On X86, this translates to ENDBR
instructions being added to the prologues of functions.

This patch adds a new switch, '-mmanual-endbr', which tells the compiler
that, even though -fcf-protection is in use, functions should not get
the instrumentation automatically. Instead, it allows users to manually
add the new attribute, 'cf_check', to functions that require it.

When -mmanual-endbr is set, llvm refrains from automatically adding
ENDBR instructions to functions' prologues, which would have been
automatically added by -fcf-protection=branch. Although this works
correctly, missing ENDBR instructions where they are actually needed
could lead to broken binaries, which would fail only in running time.

Thus, when the backend detects that a function could be reached from an
indirect jump (e.g. when it has its address taken, or belongs to the
exported set of functions), a diagnostic warning is emitted, which
should help developers find missing occurrences of the 'cf_check'
attribute.

Depends on D118052 .


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D118355

Files:
  clang/include/clang/AST/Type.h
  clang/include/clang/AST/TypeProperties.td
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/CodeGen/CGFunctionInfo.h
  clang/include/clang/Driver/Options.td
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/ASTStructuralEquivalence.cpp
  clang/lib/AST/TypePrinter.cpp
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/lib/Sema/SemaType.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/test/CodeGen/X86/x86-mmanual-endbr.c
  clang/test/CodeGen/attributes.c
  clang/test/Misc/pragma-attribute-supported-attributes-list.test
  clang/test/Sema/attr-cf_check.c
  clang/test/Sema/attr-cf_check.cpp
  clang/test/Sema/cf_check_attr_not_allowed.c
  llvm/bindings/go/llvm/ir_test.go
  llvm/docs/BitCodeFormat.rst
  llvm/docs/LangRef.rst
  llvm/include/llvm/AsmParser/LLToken.h
  llvm/include/llvm/Bitcode/LLVMBitCodes.h
  llvm/include/llvm/IR/Attributes.td
  llvm/include/llvm/IR/Function.h
  llvm/include/llvm/IR/InstrTypes.h
  llvm/lib/AsmParser/LLLexer.cpp
  llvm/lib/Bitcode/Reader/BitcodeReader.cpp
  llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
  llvm/lib/Target/X86/X86ISelLowering.cpp
  llvm/lib/Target/X86/X86IndirectBranchTracking.cpp
  llvm/lib/Transforms/Utils/CodeExtractor.cpp
  llvm/test/CodeGen/X86/cf_check.ll
  llvm/test/CodeGen/X86/missing_cf_check.ll

Index: llvm/test/CodeGen/X86/missing_cf_check.ll
===
--- /dev/null
+++ llvm/test/CodeGen/X86/missing_cf_check.ll
@@ -0,0 +1,71 @@
+; RUN: llc -mtriple=x86_64-unknown-unknown -x86-indirect-branch-tracking < %s 2>&1 | FileCheck %s
+
+
+;; Test that the compiler generates diagnostic messages for function pointer  ;;
+;; assignments in -mmanual-endbr mode.;;
+;; This program has been generated from the following source: ;;
+;;;;
+;; __attribute__((nocf_check)) void foo(void) {}  ;;
+;; __attribute__((cf_check)) void bar(void) {};;
+;; void baz(void) {}  ;;
+;;;;
+;; void foobar(void) {;;
+;;   void (*fooptr)(void) = &foo; /* Should always warn. */   ;;
+;;   void (*barptr)(void) = &bar; /* Should never warn. */;;
+;;   void (*bazptr)(void) = &baz; /* Should warn with -mmanual-endbr. */  ;;
+;;   (*fooptr)(); ;;
+;;   (*barptr)();

[PATCH] D118355: Add -mmanual-endbr switch to allow manual selection of control-flow protection

[Gabriel F. T. Gomes via Phabricator via cfe-commits]

gftg added a comment.

This patch as-is doesn't build. To build it needs another change that I know is 
wrong, so I'm posting it below to ask for your help:

  [RFC] How to add more bits to the Type class?
  
  After reading https://reviews.llvm.org/D50630, I learned that keeping
  the size of the 'Type' class to a minimum (currently 24 bytes, where 8
  bytes are due to the various Bit Field classes) is desired. However,
  while trying to add a new function attribute (see the precious patches
  in this series), the new bit caused FunctionTypeBitfields to become 4
  bytes larger (previously 8 bytes), which becomes the larger member of
  the Bit Field union. The whole Type class increased in size to 32 bytes
  up from 24 (an 8-byte increase).
  
  This patch does the easy workaround of letting the size of the Type
  class grow to 32 bytes. However, I would like to know how to avoid this
  while still being able to add the new function attribute. I know it's a
  lot to ask, but could somebody teach me how to do this "the proper way"?
  
  Cheers,
  Gabriel
  
  diff --git a/clang/include/clang/AST/Type.h b/clang/include/clang/AST/Type.h
  index 7a00c7d2be8c..4d359d08a522 100644
  --- a/clang/include/clang/AST/Type.h
  +++ b/clang/include/clang/AST/Type.h
  @@ -1824,7 +1824,7 @@ protected:
 Type(TypeClass tc, QualType canon, TypeDependence Dependence)
 : ExtQualsTypeCommonBase(this,
  canon.isNull() ? QualType(this_(), 0) : 
canon) {
  -static_assert(sizeof(*this) <= 8 + sizeof(ExtQualsTypeCommonBase),
  +static_assert(sizeof(*this) <= 16 + sizeof(ExtQualsTypeCommonBase),
 "changing bitfields changed sizeof(Type)!");
   static_assert(alignof(decltype(*this)) % sizeof(void *) == 0,
 "Insufficient alignment!");

I realize that sending extra diffs here is probably not how this community 
works, but please bear with me while I get used to it (I'm a newcomer).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118355

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

[PATCH] D118333: [RISCV] Update computeTargetABI implementation.

[Jessica Clarke via Phabricator via cfe-commits]

jrtc27 added a comment.

I think this is the same idea as D118333 ? 
Other than being a cleaner way of achieving the same goal. I've not looked to 
see if there are any functional differences between the two.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118333

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

[PATCH] D118333: [RISCV] Update computeTargetABI implementation.

[Jessica Clarke via Phabricator via cfe-commits]

jrtc27 added a comment.

Uh D113959  even


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118333

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

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

[Valentin Clement via Phabricator via cfe-commits]

clementval added inline comments.



Comment at: flang/include/flang/Frontend/CompilerInvocation.h:89
+  /// These values are found in the preprocessor options.
+  void setFortranOpts();
 };

@awarzynski I was looking at this file recently and I was wondering why we have 
different case style? Is there a particular reason? 



Comment at: flang/include/flang/Frontend/PreprocessorOptions.h:29
+#endif // LLVM_FLANG_PREPROCESSOROPTIONS_H
\ No newline at end of file


You have a couple of these on your patch. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93401

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

[PATCH] D107290: [RISCV] Add support for the vscale_range attribute

[Fraser Cormack via Phabricator via cfe-commits]

frasercrmck added a comment.

In D107290#3268949 , @paulwalker-arm 
wrote:

> Does this mean `RISCVTTIImpl::getMaxVScale()` can be removed?

Good question. I'm unsure at this stage. At hinted at in the description, 
`getMaxVScale` can make use of backend-specific flags to hone the maximum down 
a bit, whereas relying on the attribute basically reduces us to the one value 
which the frontend will ever likely produce. So as it stands, the 
`vscale_range` attribute is not at feature parity with this TTI method. I think 
we'd have to come to a decision that this outcome is okay.




Comment at: llvm/test/CodeGen/RISCV/rvv/fixed-vectors-vscale-range.ll:162
+
+attributes #0 = { vscale_range(2,1024) }
+attributes #1 = { vscale_range(4,1024) }

khchen wrote:
> frasercrmck wrote:
> > khchen wrote:
> > > I'm thinking do we need to test zvl and vscale_range in the same 
> > > attribute?
> > > ex. `attributes #0 = { vscale_range(2,1024) "target-features"="+zvl512b" 
> > > }`
> > Perhaps yeah. Just to check - what exactly for? Because we need `zvl` in 
> > the attributes for correctness, or in order to test the combination of 
> > `zvl` architecture and `vscale_range` to test what happens when they 
> > disagree?
> Just test for they disagree.
> Do you know what's expected value for different `vscale_range` value in two 
> function after function inlining? If they are always have the same minimum 
> value for VLEN, I think we don't need a check.
Good idea.

As for inlining, I can't see anything that would //prevent// inlining of 
functions with different `vscale_range` attributes, per se. However, I was 
looking at `TTI::areInlineCompatible` and the default implementation checks 
whether CPU/Feature Strings are equivalent. The frontend should ensure that 
`vscale_range` attributes match up 1:1 with our `+zvl` feature strings so I 
think in practice we won't inline functions with different `zvl` values in 
clang-generated C/C++ code. But users could write IR with different 
`vscale_range` attributes and we'd happily inline them, which sounds fishy. 
What do you think?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107290

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

[PATCH] D117939: [clang-tidy] Add more documentation about check development

[Aaron Ballman via Phabricator via cfe-commits]

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

LGTM, thank you for these fantastic improvements to the docs!


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

https://reviews.llvm.org/D117939

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

[PATCH] D118337: [clang-format] Fix AllowShortFunctionsOnASingleLine: InlineOnly with wrapping after record.

[Björn Schäpers via Phabricator via cfe-commits]

HazardyKnusperkeks accepted this revision.
HazardyKnusperkeks added a comment.

+1 for the TokenAnnotatorTests, I think we need more of those instead of 
testing the formatted output.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118337

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

[PATCH] D118361: clang-format: [JS] sort import aliases.

[Martin Probst via Phabricator via cfe-commits]

mprobst created this revision.
mprobst added a reviewer: krasimir.
Herald added a subscriber: jeroen.dobbelaere.
mprobst requested review of this revision.
Herald added a project: clang.

Users can define aliases for long symbols using import aliases:

  import X = A.B.C;

Previously, these were unhandled and would terminate import sorting.
With this change, aliases sort as their own group, coming last after all
other imports.

Aliases are not sorted within their group, as they may reference each
other, so order is significant. Aliases sort before ES module exports,
as exports may reference aliases.

  import {A} from 'foo';
  
  import X = A.B.C;
  
  export {X};


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D118361

Files:
  clang/lib/Format/SortJavaScriptImports.cpp
  clang/unittests/Format/SortImportsTestJS.cpp

Index: clang/unittests/Format/SortImportsTestJS.cpp
===
--- clang/unittests/Format/SortImportsTestJS.cpp
+++ clang/unittests/Format/SortImportsTestJS.cpp
@@ -446,6 +446,25 @@
  "const x =   1;");
 }
 
+TEST_F(SortImportsTestJS, ImportEqAliases) {
+  verifySort("import {B} from 'bar';\n"
+ "import {A} from 'foo';\n"
+ "\n"
+ "import C = A.C;\n"
+ "import Z = B.C.Z;\n"
+ "\n"
+ "export {C};\n"
+ "\n"
+ "console.log(Z);\n",
+ "import {A} from 'foo';\n"
+ "import C = A.C;\n"
+ "export {C};\n"
+ "import {B} from 'bar';\n"
+ "import Z = B.C.Z;\n"
+ "\n"
+ "console.log(Z);\n");
+}
+
 } // end namespace
 } // end namespace format
 } // end namespace clang
Index: clang/lib/Format/SortJavaScriptImports.cpp
===
--- clang/lib/Format/SortJavaScriptImports.cpp
+++ clang/lib/Format/SortJavaScriptImports.cpp
@@ -71,8 +71,14 @@
 // required for sorting module references.
 struct JsModuleReference {
   bool FormattingOff = false;
-  bool IsExport = false;
-  // Module references are sorted into these categories, in order.
+  // Module references are sorted coarsely into these three groups, in order.
+  enum ReferenceKind {
+IMPORT,  // import ... from or side-effect imports.
+ALIAS,   // import A = B.C;
+EXPORT,  // export ...
+  };
+  ReferenceKind Kind = ReferenceKind::IMPORT;
+  // Module references are then sorted by these categories, in order.
   enum ReferenceCategory {
 SIDE_EFFECT, // "import 'something';"
 ABSOLUTE,// from 'something'
@@ -101,14 +107,16 @@
 };
 
 bool operator<(const JsModuleReference &LHS, const JsModuleReference &RHS) {
-  if (LHS.IsExport != RHS.IsExport)
-return LHS.IsExport < RHS.IsExport;
+  if (LHS.Kind != RHS.Kind)
+return LHS.Kind < RHS.Kind;
   if (LHS.Category != RHS.Category)
 return LHS.Category < RHS.Category;
-  if (LHS.Category == JsModuleReference::ReferenceCategory::SIDE_EFFECT)
-// Side effect imports might be ordering sensitive. Consider them equal so
-// that they maintain their relative order in the stable sort below.
-// This retains transitivity because LHS.Category == RHS.Category here.
+  if (LHS.Category == JsModuleReference::ReferenceCategory::SIDE_EFFECT ||
+  LHS.Kind == JsModuleReference::ReferenceKind::ALIAS)
+// Side effect imports and aliases might be ordering sensitive. Consider
+// them equal so that they maintain their relative order in the stable sort
+// below. This retains transitivity because LHS.Category == RHS.Category
+// here.
 return false;
   // Empty URLs sort *last* (for export {...};).
   if (LHS.URL.empty() != RHS.URL.empty())
@@ -162,9 +170,10 @@
 // Insert breaks between imports and exports.
 ReferencesText += "\n";
 // Separate imports groups with two line breaks, but keep all exports
-// in a single group.
-if (!Reference.IsExport &&
-(Reference.IsExport != References[I + 1].IsExport ||
+// and aliases in a single group.
+// NB: exports sort last, so there is no need to check the next.
+if (Reference.Kind != JsModuleReference::ReferenceKind::EXPORT &&
+(Reference.Kind != References[I + 1].Kind ||
  Reference.Category != References[I + 1].Category))
   ReferencesText += "\n";
   }
@@ -298,7 +307,7 @@
   //   mismatching
   if (Reference->Category == JsModuleReference::SIDE_EFFECT ||
   PreviousReference->Category == JsModuleReference::SIDE_EFFECT ||
-  Reference->IsExport != PreviousReference->IsExport ||
+  Reference->Kind != PreviousReference->Kind ||
   !PreviousReference->Prefix.empty() || !Reference->Prefix.empty() ||
   !PreviousReference->DefaultImport.empty() ||
   !Reference->DefaultImport.empty() || Reference->Symbols.empty() ||
@@ -398,6 +407,8 @

[PATCH] D118363: clang-format: [JS] sort import aliases.

[Martin Probst via Phabricator via cfe-commits]

mprobst created this revision.
mprobst added a reviewer: krasimir.
Herald added a subscriber: jeroen.dobbelaere.
mprobst requested review of this revision.
Herald added a project: clang.

Users can define aliases for long symbols using import aliases:

  import X = A.B.C;

Previously, these were unhandled and would terminate import sorting.
With this change, aliases sort as their own group, coming last after all
other imports.

Aliases are not sorted within their group, as they may reference each
other, so order is significant.

Revision URI: https://reviews.llvm.org/D118361


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D118363

Files:
  clang/lib/Format/SortJavaScriptImports.cpp
  clang/unittests/Format/SortImportsTestJS.cpp


Index: clang/unittests/Format/SortImportsTestJS.cpp
===
--- clang/unittests/Format/SortImportsTestJS.cpp
+++ clang/unittests/Format/SortImportsTestJS.cpp
@@ -446,6 +446,25 @@
  "const x =   1;");
 }
 
+TEST_F(SortImportsTestJS, ImportEqAliases) {
+  verifySort("import {B} from 'bar';\n"
+ "import {A} from 'foo';\n"
+ "\n"
+ "import C = A.C;\n"
+ "import Z = B.C.Z;\n"
+ "\n"
+ "export {C};\n"
+ "\n"
+ "console.log(Z);\n",
+ "import {A} from 'foo';\n"
+ "import C = A.C;\n"
+ "export {C};\n"
+ "import {B} from 'bar';\n"
+ "import Z = B.C.Z;\n"
+ "\n"
+ "console.log(Z);\n");
+}
+
 } // end namespace
 } // end namespace format
 } // end namespace clang
Index: clang/lib/Format/SortJavaScriptImports.cpp
===
--- clang/lib/Format/SortJavaScriptImports.cpp
+++ clang/lib/Format/SortJavaScriptImports.cpp
@@ -78,6 +78,7 @@
 ABSOLUTE,// from 'something'
 RELATIVE_PARENT, // from '../*'
 RELATIVE,// from './*'
+ALIAS,   // import X = A.B;
   };
   ReferenceCategory Category = ReferenceCategory::SIDE_EFFECT;
   // The URL imported, e.g. `import .. from 'url';`. Empty for `export {a, 
b};`.
@@ -105,10 +106,12 @@
 return LHS.IsExport < RHS.IsExport;
   if (LHS.Category != RHS.Category)
 return LHS.Category < RHS.Category;
-  if (LHS.Category == JsModuleReference::ReferenceCategory::SIDE_EFFECT)
-// Side effect imports might be ordering sensitive. Consider them equal so
-// that they maintain their relative order in the stable sort below.
-// This retains transitivity because LHS.Category == RHS.Category here.
+  if (LHS.Category == JsModuleReference::ReferenceCategory::SIDE_EFFECT ||
+  LHS.Category == JsModuleReference::ReferenceCategory::ALIAS)
+// Side effect imports and aliases might be ordering sensitive. Consider
+// them equal so that they maintain their relative order in the stable sort
+// below. This retains transitivity because LHS.Category == RHS.Category
+// here.
 return false;
   // Empty URLs sort *last* (for export {...};).
   if (LHS.URL.empty() != RHS.URL.empty())
@@ -398,6 +401,8 @@
   JsModuleReference Reference;
   Reference.FormattingOff = FormattingOff;
   Reference.Range.setBegin(Start);
+  // References w/o a URL, e.g. export {A}, groups with RELATIVE.
+  Reference.Category = JsModuleReference::ReferenceCategory::RELATIVE;
   if (!parseModuleReference(Keywords, Reference)) {
 if (!FirstNonImportLine)
   FirstNonImportLine = Line; // if no comment before.
@@ -463,9 +468,6 @@
 Reference.Category = JsModuleReference::ReferenceCategory::RELATIVE;
   else
 Reference.Category = JsModuleReference::ReferenceCategory::ABSOLUTE;
-} else {
-  // w/o URL groups with "empty".
-  Reference.Category = JsModuleReference::ReferenceCategory::RELATIVE;
 }
 return true;
   }
@@ -501,6 +503,21 @@
   nextToken();
   if (Current->is(Keywords.kw_from))
 return true;
+  // import X = A.B.C;
+  if (Current->is(tok::equal)) {
+Reference.Category = JsModuleReference::ReferenceCategory::ALIAS;
+nextToken();
+while (Current->is(tok::identifier)) {
+  nextToken();
+  if (Current->is(tok::semi)) {
+nextToken();
+return true;
+  }
+  if (!Current->is(tok::period))
+return false;
+  nextToken();
+}
+  }
   if (Current->isNot(tok::comma))
 return false;
   nextToken(); // eat comma.


Index: clang/unittests/Format/SortImportsTestJS.cpp
===
--- clang/unittests/Format/SortImportsTestJS.cpp
+++ clang/unittests/Format/SortImportsTestJS.cpp
@@ -446,6 +446,25 @@
  "const x =   1;");
 }
 
+TEST_F(SortImportsTestJS, ImportEqAliases) {
+  verifySort("import {B} from 'bar';\n"
+ "import {A

[PATCH] D118361: clang-format: [JS] sort import aliases.

[Martin Probst via Phabricator via cfe-commits]

mprobst abandoned this revision.
mprobst added a comment.

Superseded by https://reviews.llvm.org/D118363 (sorry for the diff confusion).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118361

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

[PATCH] D117753: [AArch64] Support for memset tagged intrinsic

[Sjoerd Meijer via Phabricator via cfe-commits]

SjoerdMeijer added inline comments.



Comment at: clang/lib/Headers/arm_acle.h:734
+/* Memory Operations Intrinsics */
+#if __ARM_FEATURE_MOPS && __ARM_FEATURE_MEMORY_TAGGING
+#define __arm_mops_memset_tag(tagged_address, value, size) 
\

dmgreen wrote:
> tyb0807 wrote:
> > SjoerdMeijer wrote:
> > > Why does this also need MTE? I think the ACLE specifies this intrinsic to 
> > > be available when __ARM_FEATURE_MOPS is defined?
> > Yes you are right, thanks for spotting this.
> Hmm. These map to SETMG, and those instructions require MTE. It wouldn't make 
> sense to have an intrinsic that cannot be emitted to a valid instruction. I 
> think the spec might be wrong, to be honest.
Ah yeah, thanks Dave.  These are the tag setting variants, I didn't look 
careful enough, then probably got confused about the ACLE which I agree must be 
wrong. Would be good to double check that first.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117753

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

[PATCH] D117753: [AArch64] Support for memset tagged intrinsic

[Dave Green via Phabricator via cfe-commits]

dmgreen added inline comments.



Comment at: clang/lib/Headers/arm_acle.h:734
+/* Memory Operations Intrinsics */
+#if __ARM_FEATURE_MOPS && __ARM_FEATURE_MEMORY_TAGGING
+#define __arm_mops_memset_tag(tagged_address, value, size) 
\

SjoerdMeijer wrote:
> dmgreen wrote:
> > tyb0807 wrote:
> > > SjoerdMeijer wrote:
> > > > Why does this also need MTE? I think the ACLE specifies this intrinsic 
> > > > to be available when __ARM_FEATURE_MOPS is defined?
> > > Yes you are right, thanks for spotting this.
> > Hmm. These map to SETMG, and those instructions require MTE. It wouldn't 
> > make sense to have an intrinsic that cannot be emitted to a valid 
> > instruction. I think the spec might be wrong, to be honest.
> Ah yeah, thanks Dave.  These are the tag setting variants, I didn't look 
> careful enough, then probably got confused about the ACLE which I agree must 
> be wrong. Would be good to double check that first.
Yep - Apparently it is getting fixed in 
https://github.com/ARM-software/acle/pull/161 thanks to Lucas


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117753

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

[PATCH] D118361: clang-format: [JS] sort import aliases.

[Martin Probst via Phabricator via cfe-commits]

mprobst updated this revision to Diff 403646.
mprobst added a comment.

- make test break if we used alphasort


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118361

Files:
  clang/unittests/Format/SortImportsTestJS.cpp


Index: clang/unittests/Format/SortImportsTestJS.cpp
===
--- clang/unittests/Format/SortImportsTestJS.cpp
+++ clang/unittests/Format/SortImportsTestJS.cpp
@@ -450,17 +450,17 @@
   verifySort("import {B} from 'bar';\n"
  "import {A} from 'foo';\n"
  "\n"
- "import C = A.C;\n"
- "import Z = B.C.Z;\n"
+ "import Z = A.C;\n"
+ "import Y = B.C.Z;\n"
  "\n"
- "export {C};\n"
+ "export {Z};\n"
  "\n"
  "console.log(Z);\n",
  "import {A} from 'foo';\n"
- "import C = A.C;\n"
- "export {C};\n"
+ "import Z = A.C;\n"
+ "export {Z};\n"
  "import {B} from 'bar';\n"
- "import Z = B.C.Z;\n"
+ "import Y = B.C.Z;\n"
  "\n"
  "console.log(Z);\n");
 }


Index: clang/unittests/Format/SortImportsTestJS.cpp
===
--- clang/unittests/Format/SortImportsTestJS.cpp
+++ clang/unittests/Format/SortImportsTestJS.cpp
@@ -450,17 +450,17 @@
   verifySort("import {B} from 'bar';\n"
  "import {A} from 'foo';\n"
  "\n"
- "import C = A.C;\n"
- "import Z = B.C.Z;\n"
+ "import Z = A.C;\n"
+ "import Y = B.C.Z;\n"
  "\n"
- "export {C};\n"
+ "export {Z};\n"
  "\n"
  "console.log(Z);\n",
  "import {A} from 'foo';\n"
- "import C = A.C;\n"
- "export {C};\n"
+ "import Z = A.C;\n"
+ "export {Z};\n"
  "import {B} from 'bar';\n"
- "import Z = B.C.Z;\n"
+ "import Y = B.C.Z;\n"
  "\n"
  "console.log(Z);\n");
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] c6d5efb - clang-format: [JS] sort import aliases.

[Martin Probst via cfe-commits]

Author: Martin Probst
Date: 2022-01-27T16:16:37+01:00
New Revision: c6d5efb5d98093c4bd7578b2ea52c9032d20dea3

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

LOG: clang-format: [JS] sort import aliases.

Users can define aliases for long symbols using import aliases:

import X = A.B.C;

Previously, these were unhandled and would terminate import sorting.
With this change, aliases sort as their own group, coming last after all
other imports.

Aliases are not sorted within their group, as they may reference each
other, so order is significant.

Revision URI: https://reviews.llvm.org/D118361

Added: 


Modified: 
clang/lib/Format/SortJavaScriptImports.cpp
clang/unittests/Format/SortImportsTestJS.cpp

Removed: 




diff  --git a/clang/lib/Format/SortJavaScriptImports.cpp 
b/clang/lib/Format/SortJavaScriptImports.cpp
index 37e79bb15b58..e4107525a7ff 100644
--- a/clang/lib/Format/SortJavaScriptImports.cpp
+++ b/clang/lib/Format/SortJavaScriptImports.cpp
@@ -78,6 +78,7 @@ struct JsModuleReference {
 ABSOLUTE,// from 'something'
 RELATIVE_PARENT, // from '../*'
 RELATIVE,// from './*'
+ALIAS,   // import X = A.B;
   };
   ReferenceCategory Category = ReferenceCategory::SIDE_EFFECT;
   // The URL imported, e.g. `import .. from 'url';`. Empty for `export {a, 
b};`.
@@ -105,10 +106,12 @@ bool operator<(const JsModuleReference &LHS, const 
JsModuleReference &RHS) {
 return LHS.IsExport < RHS.IsExport;
   if (LHS.Category != RHS.Category)
 return LHS.Category < RHS.Category;
-  if (LHS.Category == JsModuleReference::ReferenceCategory::SIDE_EFFECT)
-// Side effect imports might be ordering sensitive. Consider them equal so
-// that they maintain their relative order in the stable sort below.
-// This retains transitivity because LHS.Category == RHS.Category here.
+  if (LHS.Category == JsModuleReference::ReferenceCategory::SIDE_EFFECT ||
+  LHS.Category == JsModuleReference::ReferenceCategory::ALIAS)
+// Side effect imports and aliases might be ordering sensitive. Consider
+// them equal so that they maintain their relative order in the stable sort
+// below. This retains transitivity because LHS.Category == RHS.Category
+// here.
 return false;
   // Empty URLs sort *last* (for export {...};).
   if (LHS.URL.empty() != RHS.URL.empty())
@@ -398,6 +401,8 @@ class JavaScriptImportSorter : public TokenAnalyzer {
   JsModuleReference Reference;
   Reference.FormattingOff = FormattingOff;
   Reference.Range.setBegin(Start);
+  // References w/o a URL, e.g. export {A}, groups with RELATIVE.
+  Reference.Category = JsModuleReference::ReferenceCategory::RELATIVE;
   if (!parseModuleReference(Keywords, Reference)) {
 if (!FirstNonImportLine)
   FirstNonImportLine = Line; // if no comment before.
@@ -463,9 +468,6 @@ class JavaScriptImportSorter : public TokenAnalyzer {
 Reference.Category = JsModuleReference::ReferenceCategory::RELATIVE;
   else
 Reference.Category = JsModuleReference::ReferenceCategory::ABSOLUTE;
-} else {
-  // w/o URL groups with "empty".
-  Reference.Category = JsModuleReference::ReferenceCategory::RELATIVE;
 }
 return true;
   }
@@ -501,6 +503,21 @@ class JavaScriptImportSorter : public TokenAnalyzer {
   nextToken();
   if (Current->is(Keywords.kw_from))
 return true;
+  // import X = A.B.C;
+  if (Current->is(tok::equal)) {
+Reference.Category = JsModuleReference::ReferenceCategory::ALIAS;
+nextToken();
+while (Current->is(tok::identifier)) {
+  nextToken();
+  if (Current->is(tok::semi)) {
+nextToken();
+return true;
+  }
+  if (!Current->is(tok::period))
+return false;
+  nextToken();
+}
+  }
   if (Current->isNot(tok::comma))
 return false;
   nextToken(); // eat comma.

diff  --git a/clang/unittests/Format/SortImportsTestJS.cpp 
b/clang/unittests/Format/SortImportsTestJS.cpp
index 6fe8bba53549..1c7e50863036 100644
--- a/clang/unittests/Format/SortImportsTestJS.cpp
+++ b/clang/unittests/Format/SortImportsTestJS.cpp
@@ -446,6 +446,25 @@ TEST_F(SortImportsTestJS, 
RespectsClangFormatOffInNamedImports) {
  "const x =   1;");
 }
 
+TEST_F(SortImportsTestJS, ImportEqAliases) {
+  verifySort("import {B} from 'bar';\n"
+ "import {A} from 'foo';\n"
+ "\n"
+ "import Z = A.C;\n"
+ "import Y = B.C.Z;\n"
+ "\n"
+ "export {Z};\n"
+ "\n"
+ "console.log(Z);\n",
+ "import {A} from 'foo';\n"
+ "import Z = A.C;\n"
+ "export {Z};\n"

[PATCH] D118363: clang-format: [JS] sort import aliases.

[Martin Probst via Phabricator via cfe-commits]

mprobst closed this revision.
mprobst added a comment.

Landed in 
https://github.com/llvm/llvm-project/commit/c6d5efb5d98093c4bd7578b2ea52c9032d20dea3


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118363

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

[PATCH] D118370: [clang-tidy] bugprone-signal-handler: Code refactor (NFC)

[Balázs Kéri via Phabricator via cfe-commits]

balazske created this revision.
Herald added subscribers: carlosgalvezp, steakhal, martong, gamesh411, 
Szelethus, dkrupp, xazax.hun.
balazske requested review of this revision.
Herald added a project: clang-tools-extra.
Herald added a subscriber: cfe-commits.

Another change of the code design.
Code simplified again, now there is a single place to check
a handler function and less functions for bug report emitting.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D118370

Files:
  clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.h


Index: clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.h
===
--- clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.h
+++ clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.h
@@ -33,14 +33,12 @@
   void check(const ast_matchers::MatchFinder::MatchResult &Result) override;
 
 private:
+  bool checkFunction(const FunctionDecl *FD, const Expr *CallOrRef);
   bool isFunctionAsyncSafe(const FunctionDecl *FD) const;
   bool isSystemCallAsyncSafe(const FunctionDecl *FD) const;
-  void reportBug(const FunctionDecl *CalledFunction, const Expr *CallOrRef,
- bool DirectHandler);
-  void reportHandlerCommon(llvm::df_iterator Itr,
-   const CallExpr *SignalCall,
-   const FunctionDecl *HandlerDecl,
-   const Expr *HandlerRef);
+  void reportHandlerChain(const llvm::df_iterator &Itr,
+  const FunctionDecl *HandlerDecl,
+  const Expr *HandlerRef);
 
   clang::CallGraph CG;
 
Index: clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp
===
--- clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp
+++ clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp
@@ -142,30 +142,41 @@
"There should be at least one function added to call graph.");
   }
 
-  // Check for special case when the signal handler itself is an unsafe 
external
-  // function.
-  if (!isFunctionAsyncSafe(HandlerDecl)) {
-reportBug(HandlerDecl, HandlerExpr, /*DirectHandler=*/true);
+  if (!HandlerDecl->hasBody()) {
+checkFunction(HandlerDecl, HandlerExpr);
 return;
   }
 
   CallGraphNode *HandlerNode = CG.getNode(HandlerDecl);
-  // Signal handler can be external but not unsafe, no call graph in this case.
-  if (!HandlerNode)
-return;
+  assert(HandlerNode &&
+ "Handler has body, should be present in the call graph.");
   // Start from signal handler and visit every function call.
   for (auto Itr = llvm::df_begin(HandlerNode), ItrE = 
llvm::df_end(HandlerNode);
Itr != ItrE; ++Itr) {
 const auto *CallF = dyn_cast((*Itr)->getDecl());
-if (CallF && !isFunctionAsyncSafe(CallF)) {
-  assert(Itr.getPathLength() >= 2);
-  reportBug(CallF, findCallExpr(Itr.getPath(Itr.getPathLength() - 2), 
*Itr),
-/*DirectHandler=*/false);
-  reportHandlerCommon(Itr, SignalCall, HandlerDecl, HandlerExpr);
+if (CallF && CallF != HandlerDecl) {
+  if (checkFunction(
+  CallF, findCallExpr(Itr.getPath(Itr.getPathLength() - 2), *Itr)))
+reportHandlerChain(Itr, HandlerDecl, HandlerExpr);
 }
   }
 }
 
+bool SignalHandlerCheck::checkFunction(const FunctionDecl *FD,
+   const Expr *CallOrRef) {
+  const bool FunctionIsCalled = isa(CallOrRef);
+
+  if (!isFunctionAsyncSafe(FD)) {
+diag(CallOrRef->getBeginLoc(), "%0 may not be asynchronous-safe; "
+   "%select{using it as|calling it from}1 "
+   "a signal handler may be dangerous")
+<< FD << FunctionIsCalled;
+return true;
+  }
+
+  return false;
+}
+
 bool SignalHandlerCheck::isFunctionAsyncSafe(const FunctionDecl *FD) const {
   if (isSystemCall(FD))
 return isSystemCallAsyncSafe(FD);
@@ -186,16 +197,8 @@
   return false;
 }
 
-void SignalHandlerCheck::reportBug(const FunctionDecl *CalledFunction,
-   const Expr *CallOrRef, bool DirectHandler) {
-  diag(CallOrRef->getBeginLoc(),
-   "%0 may not be asynchronous-safe; %select{calling it from|using it as}1 
"
-   "a signal handler may be dangerous")
-  << CalledFunction << DirectHandler;
-}
-
-void SignalHandlerCheck::reportHandlerCommon(
-llvm::df_iterator Itr, const CallExpr *SignalCall,
+void SignalHandlerCheck::reportHandlerChain(
+const llvm::df_iterator &Itr,
 const FunctionDecl *HandlerDecl, const Expr *HandlerRef) {
   int CallLevel = Itr.getPathLength() - 2;
   assert(CallLevel >= -1 && "Empty iterator?");


Index: clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.h
===
--- clang-tools-extra/clang-tidy/bugprone/Si

[PATCH] D116395: [Clang] Emit warning for -x option without effects

[Hans Wennborg via Phabricator via cfe-commits]

hans added inline comments.



Comment at: clang/lib/Driver/Driver.cpp:2416
   }
+  if (Inputs.size() == InputsBeforeOptX && InputTypeArg != nullptr)
+Diag(diag::warn_drv_ignored_option_x) << InputTypeArg->getValue(0);

Could we end up here in clang-cl mode with InputTypeArg pointing to a '/TC' or 
'/TP' option? (Set near the top of the function.) In that case, emitting a 
diagnostic that talks about -x would be misleading.

What if you initialized InputsBeforeOptX to a sentinel value instead (e.g. 
SIZE_MAX)? Could the if statement then be simplified to just

```
if (Inputs.size() == InputsBeforeX)
```

?



Comment at: clang/test/Driver/redundant-args.c:2
+// RUN: %clang -target x86_64-apple-darwin10 -Werror -x c -x c -fsyntax-only %s
+// RUN: %clang -target x86_64-apple-darwin10 %s -### -x c 2>&1 | FileCheck %s
+

These two lines seem to test pretty different things (and I find the first test 
a bit confusing). Maybe there's a better test to add the new warning to, or it 
could go in its own file?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116395

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

[PATCH] D118044: [ARM] Undeprecate complex IT blocks

[Dave Green via Phabricator via cfe-commits]

dmgreen added a reviewer: samparker.
dmgreen added inline comments.



Comment at: 
llvm/test/CodeGen/ARM/hoist-and-by-const-from-lshr-in-eqcmp-zero.ll:498
+; THUMB8-NEXT:it pl
+; THUMB8-NEXT:lslpl.w r1, r0, r
 ; THUMB8-NEXT:lsl.w r0, r0, r2

Can you make sure you run update_ll_test_checks on this file? It should fill in 
all these check lines for you.



Comment at: llvm/test/CodeGen/ARM/ifcvt-branch-weight.ll:22
+; CHECK: bb.1.bb2:
+; CHECK: successors: %bb.2(0x4000)
 

I'm not sure this is still checking anything useful. How has the full output 
changed? Is there not a block with two outputs anymore?



Comment at: llvm/test/CodeGen/ARM/speculation-hardening-sls.ll:38
 ; NOHARDENARM: {{bxgt lr$}}
-; NOHARDENTHUMB:   {{bx lr$}}
 ; ISBDSB-NEXT: dsb sy

What happened to this check line? Should it be bxgt lr now?



Comment at: llvm/test/CodeGen/ARM/speculation-hardening-sls.ll:50
+; CHECK:   sdiv
+; CHECK:   sdiv
 ; CHECK:   {{bx lr$}}

Why are these removed?



Comment at: llvm/test/CodeGen/Thumb2/v8_IT_3.ll:4
 ; RUN: llc < %s -mtriple=thumbv8 -arm-atomic-cfg-tidy=0 -relocation-model=pic 
| FileCheck %s --check-prefix=CHECK-PIC
-; RUN: llc < %s -mtriple=thumbv7 -arm-atomic-cfg-tidy=0 -arm-restrict-it 
-relocation-model=pic | FileCheck %s --check-prefix=CHECK-PIC
+; RUN: llc < %s -mtriple=thumbv7 -arm-atomic-cfg-tidy=0 -arm-restrict-it 
-relocation-model=pic | FileCheck %s --check-prefix=CHECK-PIC-RESTRICT-IT 
--check-prefix=CHECK-RESTRICT-IT
 

I'm not sure what this test is doing. Can you just remove -arm-restrict-it and 
update the check lines?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118044

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

[PATCH] D118044: [ARM] Undeprecate complex IT blocks

[David Spickett via Phabricator via cfe-commits]

DavidSpickett added inline comments.



Comment at: llvm/docs/ReleaseNotes.rst:87
 * Added support for the Armv8.1-M PACBTI-M extension.
+* Removed the deprecation of ARMv8-A T32 Complex IT blocks. Such blocks
+  are now enabled by default, but may be turned off if required. No

I would mention the name of the option that changed default here. E.g.

"No deprecation warnings will be generated and `-mrestrict-it` is now always 
off by default. Previously it was on by default for Armv8 and off for all other 
architecture versions."

If I'm a user scanning release notes then I can grep my project makefiles and 
not have to care what Complex IT blocks even means if it's something I haven't 
specifically set.



Comment at: llvm/lib/Target/ARM/ARMSubtarget.cpp:62
cl::values(clEnumValN(DefaultIT, "arm-default-it",
- "Generate IT block based on arch"),
+ "Generate normal IT blocks"),
   clEnumValN(RestrictedIT, "arm-restrict-it",

This implies the two are the same:
DefaultIT: normal IT blocks
RestrictedIT: IT blocks minus complex IT blocks, so, normal IT blocks?

Like if someone said oh here's the box of normal puzzles I wouldn't expect to 
find a complex one in there.

Perhaps "Generate any type of IT block"? Then the second one is more obviously 
the first minus complex.





Comment at: llvm/lib/Target/ARM/AsmParser/ARMAsmParser.cpp:10962
 { // processInstruction() updates inITBlock state, we need to save it away
   bool wasInITBlock = inITBlock();
 

This is now unused.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118044

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

[PATCH] D118224: [clang-tidy] bugprone-signal-handler improvements: display call chain

[Aaron Ballman via Phabricator via cfe-commits]

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

LGTM!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118224

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

[PATCH] D118333: [RISCV] Update computeTargetABI implementation.

[Zakk Chen via Phabricator via cfe-commits]

khchen added a comment.

In D118333#3275940 , @jrtc27 wrote:

> I think this is the same idea as D118333 ? 
> Other than being a cleaner way of achieving the same goal. I've not looked to 
> see if there are any functional differences between the two.

The goal of this patch is making llvm and clang have same way to get default 
target-abi.

D113959  only changes the llvm part and it 
still not same with clang.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118333

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

[PATCH] D116395: [Clang] Emit warning for -x option without effects

[Andrzej Warzynski via Phabricator via cfe-commits]

awarzynski added inline comments.



Comment at: clang/test/Driver/redundant-args.c:2
+// RUN: %clang -target x86_64-apple-darwin10 -Werror -x c -x c -fsyntax-only %s
+// RUN: %clang -target x86_64-apple-darwin10 %s -### -x c 2>&1 | FileCheck %s
+

hans wrote:
> These two lines seem to test pretty different things (and I find the first 
> test a bit confusing). Maybe there's a better test to add the new warning to, 
> or it could go in its own file?
I second @hans here - this is confusing. I suggest the following:
```
// RUN: %clang  -Werror -x c -fsyntax-only %s
// RUN: not %clang  -Werror %s -x c -fsyntax-only  2>&1 | FileCheck %s
```

Basically:
* IIUC, `-target` is not relevant here
* `-x -c` and `-x -c -x -c` are identical (so `-x -c` should be sufficient)
* both lines should be almost identical and the difference triggering the 
warning should be made clear


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116395

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

[PATCH] D118044: [ARM] Undeprecate complex IT blocks

[John Brawn via Phabricator via cfe-commits]

john.brawn added inline comments.



Comment at: llvm/test/CodeGen/ARM/2013-05-05-IfConvertBug.ll:1-4
 ; RUN: llc < %s -mtriple=thumbv7-apple-ios -mcpu=cortex-a8 | FileCheck %s
 ; RUN: llc < %s -mtriple=thumbv8 | FileCheck -check-prefix=CHECK-V8 %s
-; RUN: llc < %s -mtriple=thumbv7 -arm-restrict-it | FileCheck 
-check-prefix=CHECK-V8 %s
+; RUN: llc < %s -mtriple=thumbv8 -arm-restrict-it | FileCheck 
-check-prefix=CHECK-RESTRICT-IT %s
+; RUN: llc < %s -mtriple=thumbv7 -arm-restrict-it | FileCheck 
-check-prefix=CHECK-RESTRICT-IT %s

The code generated for -mtriple=thumbv7-apple-ios and -mtriple=thumbv8 is 
almost the same, so instead of changing the CHECK-V8 lines and adding new 
CHECK-RESTRICT-IT lines, you could instead rename all of the current CHECK-V8 
lines to CHECK-RESTRICT-IT and instead have -mtriple=thumbv8 check the CHECK 
lines, i.e.
; RUN: llc < %s -mtriple=thumbv8 | FileCheck %s




Comment at: llvm/test/CodeGen/ARM/arm-and-tst-peephole.ll:42-62
 ; V8-LABEL: %tailrecurse.switch
 ; V8: cmp
+; V8-NEXT: it ne
+; V8-NEXT: bxne lr
+; V8-NEXT: @
+; V8-NEXT: @
+; V8-NEXT: orr.w

The checks here are kind of a mess, in that if we look at the generated code it 
looks like

```
.LBB0_1:@ %tailrecurse.switch
@   in Loop: Header=BB0_3 Depth=1
cmp r3, #1
it  ne
bxnelr
.LBB0_2:@ %sw.bb
@   in Loop: Header=BB0_3 Depth=1
orr.w   r1, r3, r1, lsl #1
addsr2, #4
add.w   r12, r12, #1
.LBB0_3:@ %tailrecurse
@ =>This Inner Loop Header: Depth=1
ldr r3, [r2, #-4]
andsr3, r3, #3
beq .LBB0_2
@ %bb.4:@ %tailrecurse.switch
@   in Loop: Header=BB0_3 Depth=1
cmp r3, #3
itt eq
moveq   r0, r2
bxeqlr
.LBB0_5:@ %tailrecurse.switch
@   in Loop: Header=BB0_3 Depth=1
cmp r3, #2
bne .LBB0_1
@ %bb.6:@ %sw.bb8
add r1, r12
add.w   r0, r0, r1
```
We have a load of V8-NEXT lines where it's variously: checking the instruction 
opcode; checking the entire instruction; checking for some text that appears in 
a comment (e.g. V8-NEXT: %tailrecurse.switch); checking that a comment appears 
but not what's in it (e.g. V8-NEXT: @).

I think it would make more sense to restructure so it's a sequence of
```
; V8-LABEL: @ %llvm_ir_name_in_a_comment
; V8: first_instruction_in_block
; V8-NEXT: next_instruction
; v8-NEXT: etc.
```



Comment at: llvm/test/CodeGen/ARM/arm-bf16-pcs.ll:190
 ; BASE-THUMB-NEXT:strh.w r0, [sp, #6]
+; BASE-THUMB-NEXT:uxth r1, r0
 ; BASE-THUMB-NEXT:mov r0, r5

This, and the cases in other tests where we have a uxth/uxtb that moves, looks 
rather strange and not something I'd expect given that there's no IT here. Do 
you know what's going on here?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118044

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

[clang] ccce1a0 - Don't trigger unused-parameter warnings on naked functions

[Aaron Ballman via cfe-commits]

Author: MuAlphaOmegaEpsilon
Date: 2022-01-27T11:40:08-05:00
New Revision: ccce1a03c9ce9c3917b310097c89e39bb68527e2

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

LOG: Don't trigger unused-parameter warnings on naked functions

This commit checks if a function is marked with the naked attribute
and, if it is, will silence the emission of any unused-parameter
warning.

Inside a naked function only the usage of basic ASM instructions is
expected. In this context the parameters can actually be used by
fetching them according to the underlying ABI. Since parameters might
be used through ASM instructions, the linter and the compiler will have
a hard time understanding if one of those is unused or not, therefore
no unused-parameter warning should ever be triggered whenever a
function is marked naked.

Added: 


Modified: 
clang-tools-extra/clang-tidy/misc/UnusedParametersCheck.cpp
clang-tools-extra/test/clang-tidy/checkers/misc-unused-parameters-strict.cpp
clang-tools-extra/test/clang-tidy/checkers/misc-unused-parameters.c
clang-tools-extra/test/clang-tidy/checkers/misc-unused-parameters.cpp
clang/lib/Sema/SemaDecl.cpp
clang/test/Sema/warn-unused-parameters.c
clang/test/SemaCXX/warn-unused-parameters.cpp

Removed: 




diff  --git a/clang-tools-extra/clang-tidy/misc/UnusedParametersCheck.cpp 
b/clang-tools-extra/clang-tidy/misc/UnusedParametersCheck.cpp
index ee2ca87ab011b..149d63ff1e62f 100644
--- a/clang-tools-extra/clang-tidy/misc/UnusedParametersCheck.cpp
+++ b/clang-tools-extra/clang-tidy/misc/UnusedParametersCheck.cpp
@@ -31,10 +31,11 @@ bool isOverrideMethod(const FunctionDecl *Function) {
 } // namespace
 
 void UnusedParametersCheck::registerMatchers(MatchFinder *Finder) {
-  Finder->addMatcher(
-  functionDecl(isDefinition(), hasBody(stmt()), hasAnyParameter(decl()))
-  .bind("function"),
-  this);
+  Finder->addMatcher(functionDecl(isDefinition(), hasBody(stmt()),
+  hasAnyParameter(decl()),
+  unless(hasAttr(attr::Kind::Naked)))
+ .bind("function"),
+ this);
 }
 
 template 

diff  --git 
a/clang-tools-extra/test/clang-tidy/checkers/misc-unused-parameters-strict.cpp 
b/clang-tools-extra/test/clang-tidy/checkers/misc-unused-parameters-strict.cpp
index f45f9defa7ece..0b4fc8f446954 100644
--- 
a/clang-tools-extra/test/clang-tidy/checkers/misc-unused-parameters-strict.cpp
+++ 
b/clang-tools-extra/test/clang-tidy/checkers/misc-unused-parameters-strict.cpp
@@ -22,4 +22,8 @@ class F {
 // CHECK-MESSAGES: :[[@LINE-1]]:9: warning: parameter 'j' is unused
 // CHECK-FIXES: {{^}}  F(int  /*j*/) : i() {}{{$}}
 };
+
+// Do not warn on naked functions.
+[[gnu::naked]] int nakedFunction(int a, float b, const char *c) { ; }
+__attribute__((naked)) void nakedFunction(int a, int b) { ; }
 }

diff  --git 
a/clang-tools-extra/test/clang-tidy/checkers/misc-unused-parameters.c 
b/clang-tools-extra/test/clang-tidy/checkers/misc-unused-parameters.c
index 1f4527a2ec8f1..67e9a3be9692c 100644
--- a/clang-tools-extra/test/clang-tidy/checkers/misc-unused-parameters.c
+++ b/clang-tools-extra/test/clang-tidy/checkers/misc-unused-parameters.c
@@ -15,3 +15,5 @@ static void b(int i) {;}
 // ===
 void h(i, c, d) int i; char *c, *d; {} // Don't mess with K&R style
 
+// Do not warn on naked functions.
+__attribute__((naked)) void nakedFunction(int a, int b) { ; }

diff  --git 
a/clang-tools-extra/test/clang-tidy/checkers/misc-unused-parameters.cpp 
b/clang-tools-extra/test/clang-tidy/checkers/misc-unused-parameters.cpp
index 52f9675bffa10..a3fcf30f273ef 100644
--- a/clang-tools-extra/test/clang-tidy/checkers/misc-unused-parameters.cpp
+++ b/clang-tools-extra/test/clang-tidy/checkers/misc-unused-parameters.cpp
@@ -286,3 +286,7 @@ void test() {
   f([](int I) { return; });
 }
 } // namespace lambda
+
+// Do not warn on naked functions.
+[[gnu::naked]] int nakedFunction(int a, float b, const char *c) { ; }
+__attribute__((naked)) void nakedFunction(int a, int b) { ; }

diff  --git a/clang/lib/Sema/SemaDecl.cpp b/clang/lib/Sema/SemaDecl.cpp
index 7c5f6b318e973..3252671991b70 100644
--- a/clang/lib/Sema/SemaDecl.cpp
+++ b/clang/lib/Sema/SemaDecl.cpp
@@ -14694,8 +14694,10 @@ Decl *Sema::ActOnFinishFunctionBody(Decl *dcl, Stmt 
*Body,
 Diag(FD->getLocation(), diag::ext_pure_function_definition);
 
   if (!FD->isInvalidDecl()) {
-// Don't diagnose unused parameters of defaulted or deleted functions.
-if (!FD->isDeleted() && !FD->isDefaulted() && !FD->hasSkippedBody())
+// Don't diagnose unused parameters of defaulted, deleted or naked
+// functions.
+if (!FD->isDeleted() && !FD->isDefaulted() && !FD->hasSki

[PATCH] D116778: [clang-tidy][clang] Don't trigger unused-parameter warnings on naked functions

[Aaron Ballman via Phabricator via cfe-commits]

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

In D116778#3259189 , 
@MuAlphaOmegaEpsilon wrote:

> In D116778#3255414 , @aaron.ballman 
> wrote:
>
>> LGTM! The CI failure is finally down to just an unrelated one (yay?). Do you 
>> need someone to commit on your behalf? If so, what name and email address 
>> would you like used for patch attribution?
>
> Great! 🎉
> I've never committed on the LLVM repository, so I don't know the 
> requirements. If it doesn't bother you, feel free to commit on my behalf 
> using the following: 
> MuAlphaOmegaEpsilon 
>
> Thank you very much Aaron! 😀

Sorry about the delay in getting this landed (it slipped beneath my radar). 
I've commit on your behalf in ccce1a03c9ce9c3917b310097c89e39bb68527e2 
. Thank 
you for the fix!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116778

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

[PATCH] D118044: [ARM] Undeprecate complex IT blocks

[David Spickett via Phabricator via cfe-commits]

DavidSpickett added a comment.

FWIW, a 2 stage build on armv8 with `-mthumb` didn't turn up any codegen 
Gremlins. (that's how I saw the unused var)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118044

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

[PATCH] D108032: [analyzer] Retrieve a character from CompoundLiteralExpr as an initializer for constant arrays.

[Denys Petrov via Phabricator via cfe-commits]

ASDenysPetrov abandoned this revision.
ASDenysPetrov added a comment.

Paused for a while.


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

https://reviews.llvm.org/D108032

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

[clang-tools-extra] 8ce99da - [clang-tidy] Add more documentation about check development (NFC)

[via cfe-commits]

Author: Richard
Date: 2022-01-27T09:44:09-07:00
New Revision: 8ce99dadb007dd0dbbf1ddbe4090e9ff43e780c5

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

LOG: [clang-tidy] Add more documentation about check development (NFC)

- Mention pp-trace
- CMake configuration
- Overriding registerPPCallbacks
- Overriding isLanguageVersionSupported
- Check development tips
  - Guide to useful documentation
  - Using the Transformer library
  - Developing your check incrementally
  - Creating private matchers
  - Unit testing helper code
  - Making your check robust
  - Documenting your check
- Describe the Inputs test folder

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

Added: 


Modified: 
clang-tools-extra/docs/clang-tidy/Contributing.rst

Removed: 




diff  --git a/clang-tools-extra/docs/clang-tidy/Contributing.rst 
b/clang-tools-extra/docs/clang-tidy/Contributing.rst
index 7ebfac3123603..b9eb0e7627cc1 100644
--- a/clang-tools-extra/docs/clang-tidy/Contributing.rst
+++ b/clang-tools-extra/docs/clang-tidy/Contributing.rst
@@ -22,6 +22,8 @@ There are a few tools particularly useful when developing 
clang-tidy checks:
 check, it will create the check, update the CMake file and create a test;
   * ``rename_check.py`` does what the script name suggests, renames an existing
 check;
+  * :program:`pp-trace` logs method calls on `PPCallbacks` for a source file
+and is invaluable in understanding the preprocessor mechanism;
   * :program:`clang-query` is invaluable for interactive prototyping of AST
 matchers and exploration of the Clang AST;
   * `clang-check`_ with the ``-ast-dump`` (and optionally ``-ast-dump-filter``)
@@ -70,6 +72,14 @@ let's start!
 .. _Using Clang Tools: https://clang.llvm.org/docs/ClangTools.html
 .. _How To Setup Clang Tooling For LLVM: 
https://clang.llvm.org/docs/HowToSetupToolingForLLVM.html
 
+When you `configure the CMake build 
`_,
+make sure that you enable the ``clang`` and ``clang-tools-extra`` projects to
+build :program:`clang-tidy`.
+Because your new check will have associated documentation, you will also want 
to install
+`Sphinx `_ and enable it in the CMake 
configuration.
+To save build time of the core Clang libraries you may want to only enable the 
``X86``
+target in the CMake configuration.
+
 
 The Directory Structure
 ---
@@ -215,11 +225,215 @@ can further inspect them and report diagnostics.
 and `clang-tidy/google/ExplicitConstructorCheck.cpp
 `_).
 
+If you need to interact with macros or preprocessor directives, you will want 
to
+override the method ``registerPPCallbacks``.  The ``add_new_check.py`` script
+does not generate an override for this method in the starting point for your
+new check.
+
+If your check applies only under a specific set of language options, be sure
+to override the method ``isLanguageVersionSupported`` to reflect that.
+
+Check development tips
+--
+
+Writing your first check can be a daunting task, particularly if you are 
unfamiliar
+with the LLVM and Clang code bases.  Here are some suggestions for orienting 
yourself
+in the codebase and working on your check incrementally.
+
+Guide to useful documentation
+^
+
+Many of the support classes created for LLVM are used by Clang, such as 
`StringRef
+`_
+and `SmallVector 
`_.
+These and other commonly used classes are described in the `Important and 
useful LLVM APIs
+`_
 and
+`Picking the Right Data Structure for the Task
+`_
+sections of the `LLVM Programmer's Manual
+`_.  You don't need to memorize 
all the
+details of these classes; the generated `doxygen documentation 
`_
+has everything if you need it.  In the header `LLVM/ADT/STLExtras.h
+`_ you'll find useful versions of 
the STL
+algorithms that operate on LLVM containers, such as `llvm::all_of
+`_.
+
+Clang is implemented on top of LLVM and introduces its own set of classes that 
you
+will interact with while writing your check.  When a check issues diagnostics 
and
+fix-its, these are associated with locations in the source co

[PATCH] D117939: [clang-tidy] Add more documentation about check development

[Richard via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG8ce99dadb007: [clang-tidy] Add more documentation about 
check development (NFC) (authored by LegalizeAdulthood).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117939

Files:
  clang-tools-extra/docs/clang-tidy/Contributing.rst

Index: clang-tools-extra/docs/clang-tidy/Contributing.rst
===
--- clang-tools-extra/docs/clang-tidy/Contributing.rst
+++ clang-tools-extra/docs/clang-tidy/Contributing.rst
@@ -22,6 +22,8 @@
 check, it will create the check, update the CMake file and create a test;
   * ``rename_check.py`` does what the script name suggests, renames an existing
 check;
+  * :program:`pp-trace` logs method calls on `PPCallbacks` for a source file
+and is invaluable in understanding the preprocessor mechanism;
   * :program:`clang-query` is invaluable for interactive prototyping of AST
 matchers and exploration of the Clang AST;
   * `clang-check`_ with the ``-ast-dump`` (and optionally ``-ast-dump-filter``)
@@ -70,6 +72,14 @@
 .. _Using Clang Tools: https://clang.llvm.org/docs/ClangTools.html
 .. _How To Setup Clang Tooling For LLVM: https://clang.llvm.org/docs/HowToSetupToolingForLLVM.html
 
+When you `configure the CMake build `_,
+make sure that you enable the ``clang`` and ``clang-tools-extra`` projects to
+build :program:`clang-tidy`.
+Because your new check will have associated documentation, you will also want to install
+`Sphinx `_ and enable it in the CMake configuration.
+To save build time of the core Clang libraries you may want to only enable the ``X86``
+target in the CMake configuration.
+
 
 The Directory Structure
 ---
@@ -215,11 +225,215 @@
 and `clang-tidy/google/ExplicitConstructorCheck.cpp
 `_).
 
+If you need to interact with macros or preprocessor directives, you will want to
+override the method ``registerPPCallbacks``.  The ``add_new_check.py`` script
+does not generate an override for this method in the starting point for your
+new check.
+
+If your check applies only under a specific set of language options, be sure
+to override the method ``isLanguageVersionSupported`` to reflect that.
+
+Check development tips
+--
+
+Writing your first check can be a daunting task, particularly if you are unfamiliar
+with the LLVM and Clang code bases.  Here are some suggestions for orienting yourself
+in the codebase and working on your check incrementally.
+
+Guide to useful documentation
+^
+
+Many of the support classes created for LLVM are used by Clang, such as `StringRef
+`_
+and `SmallVector `_.
+These and other commonly used classes are described in the `Important and useful LLVM APIs
+`_ and
+`Picking the Right Data Structure for the Task
+`_
+sections of the `LLVM Programmer's Manual
+`_.  You don't need to memorize all the
+details of these classes; the generated `doxygen documentation `_
+has everything if you need it.  In the header `LLVM/ADT/STLExtras.h
+`_ you'll find useful versions of the STL
+algorithms that operate on LLVM containers, such as `llvm::all_of
+`_.
+
+Clang is implemented on top of LLVM and introduces its own set of classes that you
+will interact with while writing your check.  When a check issues diagnostics and
+fix-its, these are associated with locations in the source code.  Source code locations,
+source files, ranges of source locations and the `SourceManager
+`_ class provide
+the mechanisms for describing such locations.  These and
+other topics are described in the `"Clang" CFE Internals Manual
+`_.  Whereas the doxygen generated
+documentation serves as a reference to the internals of Clang, this document serves
+as a guide to other developers.  Topics in that manual of interest to a check developer
+are:
+
+- `The Clang "Basic" Library
+  `_ for
+  information about diagnostics, fix-it hints and source locations.
+- `The Lexer and Preprocessor Library

[PATCH] D118380: Add info on PACBTI-M to the Clang release notes

[Ties Stuij via Phabricator via cfe-commits]

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

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D118380

Files:
  clang/docs/ReleaseNotes.rst


Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -77,6 +77,9 @@
 
 - Clang plugin arguments can now be passed through the compiler driver via
   ``-fplugin-arg-pluginname-arg``, similar to GCC's ``-fplugin-arg``.
+- The ``-mno-bti-at-return-twice`` flag will make sure a BTI instruction won't
+  be added after a setjmp or possible other return-twice construct (ARM backend
+  only).
 
 Deprecated Compiler Flags
 -
@@ -279,6 +282,11 @@
   GNU driver. Programs that depend on clang invoking GCC as the linker driver
   should use GCC as the linker in the build system.
 
+- The ``-mbranch-protection`` flag will now also work for the ARM backend.
+
+- The ``attribute((target("branch-protection=...)))`` attributes will now also
+  work for the ARM backend.
+
 Floating Point Support in Clang
 ---
 - The default setting of FP contraction (FMA) is now -ffp-contract=on (for


Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -77,6 +77,9 @@
 
 - Clang plugin arguments can now be passed through the compiler driver via
   ``-fplugin-arg-pluginname-arg``, similar to GCC's ``-fplugin-arg``.
+- The ``-mno-bti-at-return-twice`` flag will make sure a BTI instruction won't
+  be added after a setjmp or possible other return-twice construct (ARM backend
+  only).
 
 Deprecated Compiler Flags
 -
@@ -279,6 +282,11 @@
   GNU driver. Programs that depend on clang invoking GCC as the linker driver
   should use GCC as the linker in the build system.
 
+- The ``-mbranch-protection`` flag will now also work for the ARM backend.
+
+- The ``attribute((target("branch-protection=...)))`` attributes will now also
+  work for the ARM backend.
+
 Floating Point Support in Clang
 ---
 - The default setting of FP contraction (FMA) is now -ffp-contract=on (for
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D118070: Add /winsysroot support to lld

[Peter Kasting via Phabricator via cfe-commits]

pkasting updated this revision to Diff 403679.
pkasting added a comment.
Herald added subscribers: hiraditya, mgorny.

Refactored to share code with clang-cl.  Still no tests.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118070

Files:
  clang/docs/tools/clang-formatted-files.txt
  clang/lib/Driver/ToolChains/MSVC.cpp
  clang/lib/Driver/ToolChains/MSVC.h
  clang/lib/Driver/ToolChains/MSVCSetupApi.h
  lld/COFF/Driver.cpp
  lld/COFF/Driver.h
  lld/COFF/Options.td
  lld/COFF/SymbolTable.cpp
  llvm/include/llvm/Support/MSVCPaths.h
  llvm/include/llvm/Support/MSVCSetupApi.h
  llvm/lib/Support/CMakeLists.txt
  llvm/lib/Support/MSVCPaths.cpp
  llvm/utils/gn/secondary/llvm/lib/Support/BUILD.gn
  utils/bazel/llvm-project-overlay/clang/BUILD.bazel

Index: utils/bazel/llvm-project-overlay/clang/BUILD.bazel
===
--- utils/bazel/llvm-project-overlay/clang/BUILD.bazel
+++ utils/bazel/llvm-project-overlay/clang/BUILD.bazel
@@ -1309,9 +1309,6 @@
 "lib/Driver/ToolChains/Arch/*.cpp",
 "lib/Driver/ToolChains/Arch/*.h",
 ],
-exclude = [
-"lib/Driver/ToolChains/MSVCSetupApi.h",
-],
 ),
 hdrs = glob([
 "include/clang/Driver/*.h",
Index: llvm/utils/gn/secondary/llvm/lib/Support/BUILD.gn
===
--- llvm/utils/gn/secondary/llvm/lib/Support/BUILD.gn
+++ llvm/utils/gn/secondary/llvm/lib/Support/BUILD.gn
@@ -98,6 +98,7 @@
 "MD5.cpp",
 "MSP430AttributeParser.cpp",
 "MSP430Attributes.cpp",
+"MSVCPaths.cpp",
 "ManagedStatic.cpp",
 "MathExtras.cpp",
 "MemAlloc.cpp",
Index: llvm/lib/Support/MSVCPaths.cpp
===
--- /dev/null
+++ llvm/lib/Support/MSVCPaths.cpp
@@ -0,0 +1,589 @@
+//===-- MSVCPaths.cpp - MSVC path-parsing helpers -===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "llvm/Support/MSVCPaths.h"
+#include "llvm/ADT/Optional.h"
+#include "llvm/ADT/SmallString.h"
+#include "llvm/ADT/SmallVector.h"
+#include "llvm/ADT/StringExtras.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/ADT/Twine.h"
+#include "llvm/Option/Arg.h"
+#include "llvm/Option/ArgList.h"
+#include "llvm/Support/ConvertUTF.h"
+#include "llvm/Support/Path.h"
+#include "llvm/Support/Process.h"
+#include "llvm/Support/Program.h"
+#include "llvm/Support/VersionTuple.h"
+#include "llvm/Support/VirtualFileSystem.h"
+#include 
+
+#ifdef _WIN32
+#define WIN32_LEAN_AND_MEAN
+#define NOGDI
+#ifndef NOMINMAX
+#define NOMINMAX
+#endif
+#include 
+#endif
+
+#ifdef _MSC_VER
+// Don't support SetupApi on MinGW.
+#define USE_MSVC_SETUP_API
+
+// Make sure this comes before MSVCSetupApi.h
+#include 
+
+#include "llvm/Support/COM.h"
+#ifdef __clang__
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wnon-virtual-dtor"
+#endif
+#include "llvm/Support/MSVCSetupApi.h"
+#ifdef __clang__
+#pragma clang diagnostic pop
+#endif
+_COM_SMARTPTR_TYPEDEF(ISetupConfiguration, __uuidof(ISetupConfiguration));
+_COM_SMARTPTR_TYPEDEF(ISetupConfiguration2, __uuidof(ISetupConfiguration2));
+_COM_SMARTPTR_TYPEDEF(ISetupHelper, __uuidof(ISetupHelper));
+_COM_SMARTPTR_TYPEDEF(IEnumSetupInstances, __uuidof(IEnumSetupInstances));
+_COM_SMARTPTR_TYPEDEF(ISetupInstance, __uuidof(ISetupInstance));
+_COM_SMARTPTR_TYPEDEF(ISetupInstance2, __uuidof(ISetupInstance2));
+#endif
+
+static std::string
+getHighestNumericTupleInDirectory(llvm::vfs::FileSystem &VFS,
+  llvm::StringRef Directory) {
+  std::string Highest;
+  llvm::VersionTuple HighestTuple;
+
+  std::error_code EC;
+  for (llvm::vfs::directory_iterator DirIt = VFS.dir_begin(Directory, EC),
+ DirEnd;
+   !EC && DirIt != DirEnd; DirIt.increment(EC)) {
+auto Status = VFS.status(DirIt->path());
+if (!Status || !Status->isDirectory())
+  continue;
+llvm::StringRef CandidateName = llvm::sys::path::filename(DirIt->path());
+llvm::VersionTuple Tuple;
+if (Tuple.tryParse(CandidateName)) // tryParse() returns true on error.
+  continue;
+if (Tuple > HighestTuple) {
+  HighestTuple = Tuple;
+  Highest = CandidateName.str();
+}
+  }
+
+  return Highest;
+}
+
+static bool getWindows10SDKVersionFromPath(llvm::vfs::FileSystem &VFS,
+   const std::string &SDKPath,
+   std::string &SDKVersion) {
+  llvm::SmallString<128> IncludePath(SDKPath);
+  llvm::sys::path::append(IncludePath, "Include");
+  SDKVersion = g

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

[Andrzej Warzynski via Phabricator via cfe-commits]

awarzynski added inline comments.



Comment at: flang/include/flang/Frontend/CompilerInvocation.h:89
+  /// These values are found in the preprocessor options.
+  void setFortranOpts();
 };

clementval wrote:
> @awarzynski I was looking at this file recently and I was wondering why we 
> have different case style? Is there a particular reason? 
Thanks for pointing this out! See:https://reviews.llvm.org/D118381

>  Is there a particular reason?

Tl;Dr This is a typo - I blame the reviewers :)

**A bit longer discussion**
The driver strives to follow Flang's [[ 
https://github.com/llvm/llvm-project/blob/main/flang/docs/C%2B%2Bstyle.md | C++ 
style ]]. That was pretty much the only style used/available in LLVM Flang when 
the driver was introduced. Basically, it looked like the only available option. 
I didn't realise that in lowering and code-gen people decided to use the MLIR 
style. In hindsight, the driver should follow that too (to be better aligned 
with the rest of LLVM).

Flang's C++ style is very different to LLVM's, Clang's or MLIR's coding styles. 
Since the driver  "glues" these projects together, it effectively needs to keep 
switching between the styles (i.e. LLVM and Clang's APIs fallow their style, 
MLIR's APIs fallow MLIR style, and Flang's parser/sema APIs follow Flang's 
style). To me personally, this has been very confusing and a major pain point.

I think that it would be good for the overall health of the project if the 
driver was refactored to follow the MLIR style. What are you thoughts?



Comment at: flang/include/flang/Frontend/PreprocessorOptions.h:29
+#endif // LLVM_FLANG_PREPROCESSOROPTIONS_H
\ No newline at end of file


clementval wrote:
> You have a couple of these on your patch. 
Fixed in https://reviews.llvm.org/D97080



Comment at: flang/test/Flang-Driver/macro_def_undef.f90:39
+end
\ No newline at end of file


@clementval Fixed in https://reviews.llvm.org/D99292


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93401

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

[PATCH] D117753: [AArch64] Support for memset tagged intrinsic

[Son Tuan Vu via Phabricator via cfe-commits]

tyb0807 updated this revision to Diff 403686.
tyb0807 marked an inline comment as done.
tyb0807 added a comment.

Update accordingly to change from ACLE specification:
`__builtin_arm_mops_memset_tag` required _both_ MOPS and MTE features


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117753

Files:
  clang/include/clang/Basic/BuiltinsAArch64.def
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Headers/arm_acle.h
  clang/test/CodeGen/aarch64-mops.c
  llvm/include/llvm/IR/IntrinsicsAArch64.td

Index: llvm/include/llvm/IR/IntrinsicsAArch64.td
===
--- llvm/include/llvm/IR/IntrinsicsAArch64.td
+++ llvm/include/llvm/IR/IntrinsicsAArch64.td
@@ -890,6 +890,14 @@
 [IntrWriteMem, IntrArgMemOnly, NoCapture>, WriteOnly>]>;
 }
 
+//===--===//
+// Memory Operations (MOPS) Intrinsics
+let TargetPrefix = "aarch64" in {
+  // Sizes are chosen to correspond to the llvm.memset intrinsic: ptr, i8, i64
+  def int_aarch64_mops_memset_tag : DefaultAttrsIntrinsic<[llvm_ptr_ty], [llvm_ptr_ty, llvm_i8_ty, llvm_i64_ty],
+  [IntrWriteMem, IntrArgMemOnly, NoCapture>, WriteOnly>]>;
+}
+
 // Transactional Memory Extension (TME) Intrinsics
 let TargetPrefix = "aarch64" in {
 def int_aarch64_tstart  : GCCBuiltin<"__builtin_arm_tstart">,
Index: clang/test/CodeGen/aarch64-mops.c
===
--- /dev/null
+++ clang/test/CodeGen/aarch64-mops.c
@@ -0,0 +1,153 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+
+// RUN: %clang_cc1 -triple aarch64-arm-unknown-eabi -target-feature +mops -target-feature +mte -S -emit-llvm -o - %s  | FileCheck %s
+
+#define __ARM_FEATURE_MOPS 1
+#include 
+#include 
+
+// CHECK-LABEL: @bzero_0(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[DST_ADDR:%.*]] = alloca i8*, align 8
+// CHECK-NEXT:store i8* [[DST:%.*]], i8** [[DST_ADDR]], align 8
+// CHECK-NEXT:[[TMP0:%.*]] = load i8*, i8** [[DST_ADDR]], align 8
+// CHECK-NEXT:[[TMP1:%.*]] = call i8* @llvm.aarch64.mops.memset.tag(i8* [[TMP0]], i8 0, i64 0)
+// CHECK-NEXT:ret i8* [[TMP1]]
+//
+void *bzero_0(void *dst) {
+  return __arm_mops_memset_tag(dst, 0, 0);
+}
+
+// CHECK-LABEL: @bzero_1(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[DST_ADDR:%.*]] = alloca i8*, align 8
+// CHECK-NEXT:store i8* [[DST:%.*]], i8** [[DST_ADDR]], align 8
+// CHECK-NEXT:[[TMP0:%.*]] = load i8*, i8** [[DST_ADDR]], align 8
+// CHECK-NEXT:[[TMP1:%.*]] = call i8* @llvm.aarch64.mops.memset.tag(i8* [[TMP0]], i8 0, i64 1)
+// CHECK-NEXT:ret i8* [[TMP1]]
+//
+void *bzero_1(void *dst) {
+  return __arm_mops_memset_tag(dst, 0, 1);
+}
+
+// CHECK-LABEL: @bzero_10(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[DST_ADDR:%.*]] = alloca i8*, align 8
+// CHECK-NEXT:store i8* [[DST:%.*]], i8** [[DST_ADDR]], align 8
+// CHECK-NEXT:[[TMP0:%.*]] = load i8*, i8** [[DST_ADDR]], align 8
+// CHECK-NEXT:[[TMP1:%.*]] = call i8* @llvm.aarch64.mops.memset.tag(i8* [[TMP0]], i8 0, i64 10)
+// CHECK-NEXT:ret i8* [[TMP1]]
+//
+void *bzero_10(void *dst) {
+  return __arm_mops_memset_tag(dst, 0, 10);
+}
+
+// CHECK-LABEL: @bzero_1(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[DST_ADDR:%.*]] = alloca i8*, align 8
+// CHECK-NEXT:store i8* [[DST:%.*]], i8** [[DST_ADDR]], align 8
+// CHECK-NEXT:[[TMP0:%.*]] = load i8*, i8** [[DST_ADDR]], align 8
+// CHECK-NEXT:[[TMP1:%.*]] = call i8* @llvm.aarch64.mops.memset.tag(i8* [[TMP0]], i8 0, i64 1)
+// CHECK-NEXT:ret i8* [[TMP1]]
+//
+void *bzero_1(void *dst) {
+  return __arm_mops_memset_tag(dst, 0, 1);
+}
+
+// CHECK-LABEL: @bzero_n(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[DST_ADDR:%.*]] = alloca i8*, align 8
+// CHECK-NEXT:[[SIZE_ADDR:%.*]] = alloca i64, align 8
+// CHECK-NEXT:store i8* [[DST:%.*]], i8** [[DST_ADDR]], align 8
+// CHECK-NEXT:store i64 [[SIZE:%.*]], i64* [[SIZE_ADDR]], align 8
+// CHECK-NEXT:[[TMP0:%.*]] = load i8*, i8** [[DST_ADDR]], align 8
+// CHECK-NEXT:[[TMP1:%.*]] = load i64, i64* [[SIZE_ADDR]], align 8
+// CHECK-NEXT:[[TMP2:%.*]] = call i8* @llvm.aarch64.mops.memset.tag(i8* [[TMP0]], i8 0, i64 [[TMP1]])
+// CHECK-NEXT:ret i8* [[TMP2]]
+//
+void *bzero_n(void *dst, size_t size) {
+  return __arm_mops_memset_tag(dst, 0, size);
+}
+
+// CHECK-LABEL: @memset_0(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[DST_ADDR:%.*]] = alloca i8*, align 8
+// CHECK-NEXT:[[VALUE_ADDR:%.*]] = alloca i32, align 4
+// CHECK-NEXT:store i8* [[DST:%.*]], i8** [[DST_ADDR]], align 8
+// CHECK-NEXT:store i32 [[VALUE:%.*]], i32* [[VALUE_ADDR]], align 4
+// CHECK-NEXT:[[TMP0:%.*]] = load i8*, i8** [[DST_ADDR]], align 8
+// CHECK-NEXT:[[TMP1:%.*]] = load i32, i32* [[VALUE_ADDR]], align 4
+// CHECK-NEXT:[[TMP2:%.*]] = trunc i32 [[TMP1]] to i8
+// CHECK-N

[PATCH] D118370: [clang-tidy] bugprone-signal-handler: Code refactor (NFC)

[Richard via Phabricator via cfe-commits]

LegalizeAdulthood added inline comments.



Comment at: clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp:146
+  if (!HandlerDecl->hasBody()) {
+checkFunction(HandlerDecl, HandlerExpr);
 return;

Why do we ignore the return value of `checkFunction` here?

Also, the name doesn't reveal to me why the result is true
or false, e.g. it acts like a predicate but its name doesn't ask
a question.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118370

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

[PATCH] D117753: [AArch64] Support for memset tagged intrinsic

[Son Tuan Vu via Phabricator via cfe-commits]

tyb0807 updated this revision to Diff 403687.
tyb0807 marked 3 inline comments as done.
tyb0807 edited the summary of this revision.
tyb0807 added a comment.

Update link to the relevant section of ACLE specification


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117753

Files:
  clang/include/clang/Basic/BuiltinsAArch64.def
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Headers/arm_acle.h
  clang/test/CodeGen/aarch64-mops.c
  llvm/include/llvm/IR/IntrinsicsAArch64.td

Index: llvm/include/llvm/IR/IntrinsicsAArch64.td
===
--- llvm/include/llvm/IR/IntrinsicsAArch64.td
+++ llvm/include/llvm/IR/IntrinsicsAArch64.td
@@ -890,6 +890,14 @@
 [IntrWriteMem, IntrArgMemOnly, NoCapture>, WriteOnly>]>;
 }
 
+//===--===//
+// Memory Operations (MOPS) Intrinsics
+let TargetPrefix = "aarch64" in {
+  // Sizes are chosen to correspond to the llvm.memset intrinsic: ptr, i8, i64
+  def int_aarch64_mops_memset_tag : DefaultAttrsIntrinsic<[llvm_ptr_ty], [llvm_ptr_ty, llvm_i8_ty, llvm_i64_ty],
+  [IntrWriteMem, IntrArgMemOnly, NoCapture>, WriteOnly>]>;
+}
+
 // Transactional Memory Extension (TME) Intrinsics
 let TargetPrefix = "aarch64" in {
 def int_aarch64_tstart  : GCCBuiltin<"__builtin_arm_tstart">,
Index: clang/test/CodeGen/aarch64-mops.c
===
--- /dev/null
+++ clang/test/CodeGen/aarch64-mops.c
@@ -0,0 +1,153 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+
+// RUN: %clang_cc1 -triple aarch64-arm-unknown-eabi -target-feature +mops -target-feature +mte -S -emit-llvm -o - %s  | FileCheck %s
+
+#define __ARM_FEATURE_MOPS 1
+#include 
+#include 
+
+// CHECK-LABEL: @bzero_0(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[DST_ADDR:%.*]] = alloca i8*, align 8
+// CHECK-NEXT:store i8* [[DST:%.*]], i8** [[DST_ADDR]], align 8
+// CHECK-NEXT:[[TMP0:%.*]] = load i8*, i8** [[DST_ADDR]], align 8
+// CHECK-NEXT:[[TMP1:%.*]] = call i8* @llvm.aarch64.mops.memset.tag(i8* [[TMP0]], i8 0, i64 0)
+// CHECK-NEXT:ret i8* [[TMP1]]
+//
+void *bzero_0(void *dst) {
+  return __arm_mops_memset_tag(dst, 0, 0);
+}
+
+// CHECK-LABEL: @bzero_1(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[DST_ADDR:%.*]] = alloca i8*, align 8
+// CHECK-NEXT:store i8* [[DST:%.*]], i8** [[DST_ADDR]], align 8
+// CHECK-NEXT:[[TMP0:%.*]] = load i8*, i8** [[DST_ADDR]], align 8
+// CHECK-NEXT:[[TMP1:%.*]] = call i8* @llvm.aarch64.mops.memset.tag(i8* [[TMP0]], i8 0, i64 1)
+// CHECK-NEXT:ret i8* [[TMP1]]
+//
+void *bzero_1(void *dst) {
+  return __arm_mops_memset_tag(dst, 0, 1);
+}
+
+// CHECK-LABEL: @bzero_10(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[DST_ADDR:%.*]] = alloca i8*, align 8
+// CHECK-NEXT:store i8* [[DST:%.*]], i8** [[DST_ADDR]], align 8
+// CHECK-NEXT:[[TMP0:%.*]] = load i8*, i8** [[DST_ADDR]], align 8
+// CHECK-NEXT:[[TMP1:%.*]] = call i8* @llvm.aarch64.mops.memset.tag(i8* [[TMP0]], i8 0, i64 10)
+// CHECK-NEXT:ret i8* [[TMP1]]
+//
+void *bzero_10(void *dst) {
+  return __arm_mops_memset_tag(dst, 0, 10);
+}
+
+// CHECK-LABEL: @bzero_1(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[DST_ADDR:%.*]] = alloca i8*, align 8
+// CHECK-NEXT:store i8* [[DST:%.*]], i8** [[DST_ADDR]], align 8
+// CHECK-NEXT:[[TMP0:%.*]] = load i8*, i8** [[DST_ADDR]], align 8
+// CHECK-NEXT:[[TMP1:%.*]] = call i8* @llvm.aarch64.mops.memset.tag(i8* [[TMP0]], i8 0, i64 1)
+// CHECK-NEXT:ret i8* [[TMP1]]
+//
+void *bzero_1(void *dst) {
+  return __arm_mops_memset_tag(dst, 0, 1);
+}
+
+// CHECK-LABEL: @bzero_n(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[DST_ADDR:%.*]] = alloca i8*, align 8
+// CHECK-NEXT:[[SIZE_ADDR:%.*]] = alloca i64, align 8
+// CHECK-NEXT:store i8* [[DST:%.*]], i8** [[DST_ADDR]], align 8
+// CHECK-NEXT:store i64 [[SIZE:%.*]], i64* [[SIZE_ADDR]], align 8
+// CHECK-NEXT:[[TMP0:%.*]] = load i8*, i8** [[DST_ADDR]], align 8
+// CHECK-NEXT:[[TMP1:%.*]] = load i64, i64* [[SIZE_ADDR]], align 8
+// CHECK-NEXT:[[TMP2:%.*]] = call i8* @llvm.aarch64.mops.memset.tag(i8* [[TMP0]], i8 0, i64 [[TMP1]])
+// CHECK-NEXT:ret i8* [[TMP2]]
+//
+void *bzero_n(void *dst, size_t size) {
+  return __arm_mops_memset_tag(dst, 0, size);
+}
+
+// CHECK-LABEL: @memset_0(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[DST_ADDR:%.*]] = alloca i8*, align 8
+// CHECK-NEXT:[[VALUE_ADDR:%.*]] = alloca i32, align 4
+// CHECK-NEXT:store i8* [[DST:%.*]], i8** [[DST_ADDR]], align 8
+// CHECK-NEXT:store i32 [[VALUE:%.*]], i32* [[VALUE_ADDR]], align 4
+// CHECK-NEXT:[[TMP0:%.*]] = load i8*, i8** [[DST_ADDR]], align 8
+// CHECK-NEXT:[[TMP1:%.*]] = load i32, i32* [[VALUE_ADDR]], align 4
+// CHECK-NEXT:[[TMP2:%.*]] = trunc i32 [[TMP1]] to i8
+// CHECK-NEXT:[[TMP3:%.*]] 

[PATCH] D118385: [NFC] Optimize FoldingSet usage where it matters

[Dawid Jurczak via Phabricator via cfe-commits]

yurai007 created this revision.
yurai007 added reviewers: nikic, xbolva00, aeubanks, ChuanqiXu, v.g.vassilev, 
serge-sans-paille, rsmith.
Herald added subscribers: dexonsmith, pengfei, hiraditya.
yurai007 requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

While building huge code bases it's not uncommon to see perf reports with 
following FoldingSet items:

  
  1.56% 0.47%  clang  clang-14  [.] 
llvm::FoldingSetBase::FindNodeOrInsertPos
  0.30% 0.01%  clang  clang-14  [.] 
llvm::ContextualFoldingSet::NodeEquals
  0.25% 0.02%  clang  clang-14  [.] llvm::FoldingSetBase::InsertNode
  0.23% 0.12%  clang  clang-14  [.] llvm::FoldingSetBase::GrowBucketCount
  0.22% 0.21%  clang  clang-14  [.] llvm::FoldingSetNodeID::AddPointer
  0.47% 0.06%  clang  clang-14  [.] llvm::FoldingSetBase::InsertNode
  
  or
  
  1.12% 0.75%  clang++   libLLVM-13.so[.] 
llvm::FoldingSetBase::GrowBucketCount
  0.49% 0.48%  clang++   libLLVM-13.so[.] 
llvm::FoldingSetNodeID::AddPointer
  0.41% 0.09%  clang++   libLLVM-13.so[.] 
llvm::FoldingSetNodeID::operator==
  
  etc.
  

Among many FoldingSet users most notable seem to be ASTContext and CodeGenTypes.
The reasons that we spend not-so-tiny amount of time in FoldingSet calls from 
there, are following:

  
  1. Default FoldingSet capacity for 2^6 items very often is not enough.
 For PointerTypes/ElaboratedTypes/ParenTypes it's not unlikely to observe 
growing it to 256 or 512 items.
 FunctionProtoTypes can easily exceed 1k items capacity growing up to 4k or 
even 8k size.
  
  2. FoldingSetBase::GrowBucketCount cost itself is not very bad (pure 
reallocations are rather cheap thanks to BumpPtrAllocator)
 What matters is high collision rate when lot of items end up in same 
bucket slowing down FoldingSetBase::FindNodeOrInsertPos and trashing CPU cache
 (as items with same hash are organized in intrusive linked list which need 
to be traversed).
  
  3. Lack of AddInteger/AddPointer and computeHash inlining slows down 
NodeEquals/Profile/:operator== calls.
 Inlining makes FunctionProtoTypes/PointerTypes/ElaboratedTypes/ParenTypes 
Profile functions faster but
 since NodeEquals is still called indirectly through function pointer from 
FindNodeOrInsertPos
 there is room for further inlining improvements.


After addressing above issues I built Linux (with default config) on isolated 
CPU cores in silent x86-64 Linux environment.
Compile time statistics diff produced by perf before and after change are 
following:
instructions -0.4%, cycles -0.9%
size-text change of output Clang binary is below +0.1%.

  

Similarly like in: https://reviews.llvm.org/D118169 for code bases containing 
smaller translation units
it's expected to get less significant speedup with this patch.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D118385

Files:
  clang/include/clang/AST/ASTContext.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/CodeGen/CodeGenTypes.h
  llvm/include/llvm/ADT/FoldingSet.h
  llvm/lib/Support/FoldingSet.cpp

Index: llvm/lib/Support/FoldingSet.cpp
===
--- llvm/lib/Support/FoldingSet.cpp
+++ llvm/lib/Support/FoldingSet.cpp
@@ -12,7 +12,6 @@
 //===--===//
 
 #include "llvm/ADT/FoldingSet.h"
-#include "llvm/ADT/Hashing.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/Support/Allocator.h"
 #include "llvm/Support/ErrorHandling.h"
@@ -25,12 +24,6 @@
 //===--===//
 // FoldingSetNodeIDRef Implementation
 
-/// ComputeHash - Compute a strong hash value for this FoldingSetNodeIDRef,
-/// used to lookup the node in the FoldingSetBase.
-unsigned FoldingSetNodeIDRef::ComputeHash() const {
-  return static_cast(hash_combine_range(Data, Data+Size));
-}
-
 bool FoldingSetNodeIDRef::operator==(FoldingSetNodeIDRef RHS) const {
   if (Size != RHS.Size) return false;
   return memcmp(Data, RHS.Data, Size*sizeof(*Data)) == 0;
@@ -49,41 +42,6 @@
 
 /// Add* - Add various data types to Bit data.
 ///
-void FoldingSetNodeID::AddPointer(const void *Ptr) {
-  // Note: this adds pointers to the hash using sizes and endianness that
-  // depend on the host. It doesn't matter, however, because hashing on
-  // pointer values is inherently unstable. Nothing should depend on the
-  // ordering of nodes in the folding set.
-  static_assert(sizeof(uintptr_t) <= sizeof(unsigned long long),
-"unexpected pointer size");
-  AddInteger(reinterpret_cast(Ptr));
-}
-void FoldingSetNodeID::AddInteger(signed I) {
-  Bits.push_back(I);
-}
-void FoldingSetNodeID::AddInteger(unsigned I) {
-  Bits.push_back(I);
-}
-void FoldingSetNodeID::AddInteger(long I) {
-  AddInteger((unsigned long)I);
-}
-void FoldingSet

[PATCH] D118383: [OpenMP] Enable inoutset dependency-type in depend clause.

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added a comment.

Is it a new mode from OpenMP 5.2? Or 5.1? Can you add a check for OpenMP 
version, if so?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118383

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

[clang] 36622c4 - [clang-format] Fix AllowShortFunctionsOnASingleLine: InlineOnly with wrapping after record.

[Marek Kurdej via cfe-commits]

Author: Marek Kurdej
Date: 2022-01-27T18:06:31+01:00
New Revision: 36622c4e1a48cd02209524592abb9d929fff1e22

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

LOG: [clang-format] Fix AllowShortFunctionsOnASingleLine: InlineOnly with 
wrapping after record.

Fixes https://github.com/llvm/llvm-project/issues/53430.

Initially, I had a quick and dirty approach, but it led to a myriad of special 
cases handling comments (that may add unwrapped lines).
So I added TT_RecordLBrace type annotations and it seems like a much nicer 
solution.
I think that in the future it will allow us to clean up some convoluted code 
that detects records.

Reviewed By: MyDeveloperDay, HazardyKnusperkeks

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

Added: 


Modified: 
clang/lib/Format/FormatToken.h
clang/lib/Format/TokenAnnotator.cpp
clang/lib/Format/UnwrappedLineFormatter.cpp
clang/lib/Format/UnwrappedLineParser.cpp
clang/unittests/Format/FormatTest.cpp
clang/unittests/Format/TokenAnnotatorTest.cpp

Removed: 




diff  --git a/clang/lib/Format/FormatToken.h b/clang/lib/Format/FormatToken.h
index 7cc090cb77de..a64329802ee3 100644
--- a/clang/lib/Format/FormatToken.h
+++ b/clang/lib/Format/FormatToken.h
@@ -96,6 +96,7 @@ namespace format {
   TYPE(PointerOrReference) 
\
   TYPE(PureVirtualSpecifier)   
\
   TYPE(RangeBasedForLoopColon) 
\
+  TYPE(RecordLBrace)   
\
   TYPE(RegexLiteral)   
\
   TYPE(SelectorName)   
\
   TYPE(StartOfName)
\

diff  --git a/clang/lib/Format/TokenAnnotator.cpp 
b/clang/lib/Format/TokenAnnotator.cpp
index a8cd1e30f74e..9d130dbb02eb 100644
--- a/clang/lib/Format/TokenAnnotator.cpp
+++ b/clang/lib/Format/TokenAnnotator.cpp
@@ -1423,7 +1423,8 @@ class AnnotatingParser {
 TT_LambdaArrow, TT_NamespaceMacro, TT_OverloadedOperator,
 TT_RegexLiteral, TT_TemplateString, TT_ObjCStringLiteral,
 TT_UntouchableMacroFunc, TT_ConstraintJunctions,
-TT_StatementAttributeLikeMacro, 
TT_FunctionLikeOrFreestandingMacro))
+TT_StatementAttributeLikeMacro, TT_FunctionLikeOrFreestandingMacro,
+TT_RecordLBrace))
   CurrentToken->setType(TT_Unknown);
 CurrentToken->Role.reset();
 CurrentToken->MatchingParen = nullptr;

diff  --git a/clang/lib/Format/UnwrappedLineFormatter.cpp 
b/clang/lib/Format/UnwrappedLineFormatter.cpp
index 293a693fd481..0172a224335c 100644
--- a/clang/lib/Format/UnwrappedLineFormatter.cpp
+++ b/clang/lib/Format/UnwrappedLineFormatter.cpp
@@ -276,6 +276,9 @@ class LineJoiner {
   FormatStyle::SFS_InlineOnly) {
 // Just checking TheLine->Level != 0 is not enough, because it
 // provokes treating functions inside indented namespaces as short.
+if (Style.isJavaScript() && (*I)->Last->is(TT_FunctionLBrace))
+  return true;
+
 if ((*I)->Level != 0) {
   if (I == B)
 return false;
@@ -288,23 +291,10 @@ class LineJoiner {
   break;
 
   // Check if the found line starts a record.
-  auto *RecordTok = (*J)->First;
-  while (RecordTok) {
-// TODO: Refactor to isRecord(RecordTok).
-if (RecordTok->isOneOf(tok::kw_class, tok::kw_struct))
-  return true;
-if (Style.isCpp() && RecordTok->is(tok::kw_union))
-  return true;
-if (Style.isCSharp() && RecordTok->is(Keywords.kw_interface))
-  return true;
-if (Style.Language == FormatStyle::LK_Java &&
-RecordTok->is(tok::kw_enum))
-  return true;
-if (Style.isJavaScript() && 
RecordTok->is(Keywords.kw_function))
-  return true;
-
-RecordTok = RecordTok->Next;
-  }
+  for (const FormatToken *RecordTok = (*J)->Last; RecordTok;
+   RecordTok = RecordTok->Previous)
+if (RecordTok->is(tok::l_brace))
+  return RecordTok->is(TT_RecordLBrace);
 
   return false;
 }

diff  --git a/clang/lib/Format/UnwrappedLineParser.cpp 
b/clang/lib/Format/UnwrappedLineParser.cpp
index b0588d92ab00..35be2fa3eb62 100644
--- a/clang/lib/Format/UnwrappedLineParser.cpp
+++ b/clang/lib/Format/UnwrappedLineParser.cpp
@@ -2482,7 +2482,8 @@ void Un

[PATCH] D118337: [clang-format] Fix AllowShortFunctionsOnASingleLine: InlineOnly with wrapping after record.

[Marek Kurdej 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 rG36622c4e1a48: [clang-format] Fix 
AllowShortFunctionsOnASingleLine: InlineOnly with wrapping… (authored by 
curdeius).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118337

Files:
  clang/lib/Format/FormatToken.h
  clang/lib/Format/TokenAnnotator.cpp
  clang/lib/Format/UnwrappedLineFormatter.cpp
  clang/lib/Format/UnwrappedLineParser.cpp
  clang/unittests/Format/FormatTest.cpp
  clang/unittests/Format/TokenAnnotatorTest.cpp

Index: clang/unittests/Format/TokenAnnotatorTest.cpp
===
--- clang/unittests/Format/TokenAnnotatorTest.cpp
+++ clang/unittests/Format/TokenAnnotatorTest.cpp
@@ -67,6 +67,30 @@
   EXPECT_TOKEN(Tokens[11], tok::star, TT_PointerOrReference);
 }
 
+TEST_F(TokenAnnotatorTest, UnderstandsClasses) {
+  auto Tokens = annotate("class C {};");
+  EXPECT_EQ(Tokens.size(), 6u) << Tokens;
+  EXPECT_TOKEN(Tokens[2], tok::l_brace, TT_RecordLBrace);
+}
+
+TEST_F(TokenAnnotatorTest, UnderstandsStructs) {
+  auto Tokens = annotate("struct S {};");
+  EXPECT_EQ(Tokens.size(), 6u) << Tokens;
+  EXPECT_TOKEN(Tokens[2], tok::l_brace, TT_RecordLBrace);
+}
+
+TEST_F(TokenAnnotatorTest, UnderstandsUnions) {
+  auto Tokens = annotate("union U {};");
+  EXPECT_EQ(Tokens.size(), 6u) << Tokens;
+  EXPECT_TOKEN(Tokens[2], tok::l_brace, TT_RecordLBrace);
+}
+
+TEST_F(TokenAnnotatorTest, UnderstandsEnums) {
+  auto Tokens = annotate("enum E {};");
+  EXPECT_EQ(Tokens.size(), 6u) << Tokens;
+  EXPECT_TOKEN(Tokens[2], tok::l_brace, TT_RecordLBrace);
+}
+
 } // namespace
 } // namespace format
 } // namespace clang
Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -12316,6 +12316,48 @@
"  int f() {}\n"
"};",
MergeInlineOnly);
+
+  MergeInlineOnly.BraceWrapping.AfterClass = true;
+  MergeInlineOnly.BraceWrapping.AfterStruct = true;
+  verifyFormat("class C\n"
+   "{\n"
+   "  int f() { return 42; }\n"
+   "};",
+   MergeInlineOnly);
+  verifyFormat("struct C\n"
+   "{\n"
+   "  int f() { return 42; }\n"
+   "};",
+   MergeInlineOnly);
+  verifyFormat("int f()\n"
+   "{\n"
+   "  return 42;\n"
+   "}",
+   MergeInlineOnly);
+  verifyFormat("int f() {}", MergeInlineOnly);
+  verifyFormat("class C\n"
+   "{\n"
+   "  int f() { return 42; }\n"
+   "};",
+   MergeInlineOnly);
+  verifyFormat("struct C\n"
+   "{\n"
+   "  int f() { return 42; }\n"
+   "};",
+   MergeInlineOnly);
+  verifyFormat("struct C\n"
+   "// comment\n"
+   "/* comment */\n"
+   "// comment\n"
+   "{\n"
+   "  int f() { return 42; }\n"
+   "};",
+   MergeInlineOnly);
+  verifyFormat("/* comment */ struct C\n"
+   "{\n"
+   "  int f() { return 42; }\n"
+   "};",
+   MergeInlineOnly);
 }
 
 TEST_F(FormatTest, PullInlineOnlyFunctionDefinitionsIntoSingleLine) {
Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -2482,7 +2482,8 @@
 parseParens();
   } else {
 while (FormatTok->isOneOf(tok::identifier, tok::coloncolon, tok::kw_inline,
-  tok::l_square, tok::period)) {
+  tok::l_square, tok::period) ||
+   (Style.isCSharp() && FormatTok->is(tok::kw_union))) {
   if (FormatTok->is(tok::l_square))
 parseSquare();
   else
@@ -2868,6 +2869,7 @@
   // Just a declaration or something is wrong.
   if (FormatTok->isNot(tok::l_brace))
 return true;
+  FormatTok->setType(TT_RecordLBrace);
   FormatTok->setBlockKind(BK_Block);
 
   if (Style.Language == FormatStyle::LK_Java) {
@@ -3108,6 +3110,7 @@
 }
   }
   if (FormatTok->Tok.is(tok::l_brace)) {
+FormatTok->setType(TT_RecordLBrace);
 if (ParseAsExpr) {
   parseChildBlock();
 } else {
Index: clang/lib/Format/UnwrappedLineFormatter.cpp
===
--- clang/lib/Format/UnwrappedLineFormatter.cpp
+++ clang/lib/Format/UnwrappedLineFormatter.cpp
@@ -276,6 +276,9 @@
   FormatStyle::SFS_InlineOnly) {
 // Just checking TheLine->Level != 0 is not enough, because it
 // provokes treating functions inside indented namespace

[PATCH] D118370: [clang-tidy] bugprone-signal-handler: Code refactor (NFC)

[Balázs Kéri via Phabricator via cfe-commits]

balazske added inline comments.



Comment at: clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp:146
+  if (!HandlerDecl->hasBody()) {
+checkFunction(HandlerDecl, HandlerExpr);
 return;

LegalizeAdulthood wrote:
> Why do we ignore the return value of `checkFunction` here?
> 
> Also, the name doesn't reveal to me why the result is true
> or false, e.g. it acts like a predicate but its name doesn't ask
> a question.
The function returns if a problem (warning) was found. At the next call site it 
is used to display additional notes, but here it is not needed. A better name 
can be `isFunctionValidSignalHandler` but the function checks not only a fact, 
it generates the warnings too.



Comment at: clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp:151
   CallGraphNode *HandlerNode = CG.getNode(HandlerDecl);
-  // Signal handler can be external but not unsafe, no call graph in this case.
-  if (!HandlerNode)
-return;
+  assert(HandlerNode &&
+ "Handler has body, should be present in the call graph.");

There are problems with this approach in C++ code.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118370

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

[PATCH] D118386: [Support][NFC] Fix generic `ChildrenGetterTy` of `IDFCalculatorBase`

[Markus Böck via Phabricator via cfe-commits]

zero9178 created this revision.
zero9178 added reviewers: Szelethus, jmorse, kuhar.
Herald added subscribers: Chia-hungDuan, dexonsmith, rriddle, hiraditya.
zero9178 requested review of this revision.
Herald added subscribers: llvm-commits, cfe-commits, stephenneuendorffer.
Herald added projects: clang, LLVM.

Both `IDFCalculatorBase` and its accompanying `DominatorTreeBase` only supports 
pointer nodes. The template argument is the block type itself and any uses of 
`GraphTraits` is therefore done via a pointer to the node type. 
However, the `ChildrenGetterTy` type of `IDFCalculatorBase` has a use on just 
the node type instead of a pointer to the node type. Various parts of the 
monorepo has worked around this issue by providing specializations of 
`GraphTraits` for the node type directly, or not been affected by using 
specializations instead of the generic case. These are unnecessary however and 
instead the generic code should be fixed instead.

An example from within Tree is eg. A use of IDFCalculatorBase in 
InstrRefBasedImpl.cpp. It basically instantiates a 
`IDFCalculatorBase` but due to the bug above then 
goes on to specialize `GraphTraits` although 
`GraphTraits` exists (and should be used instead).

Similar dead code exists in clang which defines redundant GraphTraits to work 
around this bug.

This patch fixes both the original issue and removes the dead code that was 
used to work around the issue.

As a side node, my own motivation was when using MLIR and using `mlir::Block`s 
as nodes. As MLIR correctly only provides `GraphTraits` I was not 
able to use `IDFCalculatorBase`.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D118386

Files:
  clang/include/clang/Analysis/Analyses/Dominators.h
  clang/include/clang/Analysis/CFG.h
  llvm/include/llvm/Support/GenericIteratedDominanceFrontier.h
  llvm/lib/CodeGen/LiveDebugValues/InstrRefBasedImpl.cpp

Index: llvm/lib/CodeGen/LiveDebugValues/InstrRefBasedImpl.cpp
===
--- llvm/lib/CodeGen/LiveDebugValues/InstrRefBasedImpl.cpp
+++ llvm/lib/CodeGen/LiveDebugValues/InstrRefBasedImpl.cpp
@@ -2212,40 +2212,6 @@
   // redundant PHIs.
 }
 
-// Boilerplate for feeding MachineBasicBlocks into IDF calculator. Provide
-// template specialisations for graph traits and a successor enumerator.
-namespace llvm {
-template <> struct GraphTraits {
-  using NodeRef = MachineBasicBlock *;
-  using ChildIteratorType = MachineBasicBlock::succ_iterator;
-
-  static NodeRef getEntryNode(MachineBasicBlock *BB) { return BB; }
-  static ChildIteratorType child_begin(NodeRef N) { return N->succ_begin(); }
-  static ChildIteratorType child_end(NodeRef N) { return N->succ_end(); }
-};
-
-template <> struct GraphTraits {
-  using NodeRef = const MachineBasicBlock *;
-  using ChildIteratorType = MachineBasicBlock::const_succ_iterator;
-
-  static NodeRef getEntryNode(const MachineBasicBlock *BB) { return BB; }
-  static ChildIteratorType child_begin(NodeRef N) { return N->succ_begin(); }
-  static ChildIteratorType child_end(NodeRef N) { return N->succ_end(); }
-};
-
-using MachineDomTreeBase = DomTreeBase::NodeType;
-using MachineDomTreeChildGetter =
-typename IDFCalculatorDetail::ChildrenGetterTy;
-
-namespace IDFCalculatorDetail {
-template <>
-typename MachineDomTreeChildGetter::ChildrenTy
-MachineDomTreeChildGetter::get(const NodeRef &N) {
-  return {N->succ_begin(), N->succ_end()};
-}
-} // namespace IDFCalculatorDetail
-} // namespace llvm
-
 void InstrRefBasedLDV::BlockPHIPlacement(
 const SmallPtrSetImpl &AllBlocks,
 const SmallPtrSetImpl &DefBlocks,
@@ -2253,8 +2219,7 @@
   // Apply IDF calculator to the designated set of location defs, storing
   // required PHIs into PHIBlocks. Uses the dominator tree stored in the
   // InstrRefBasedLDV object.
-  IDFCalculatorDetail::ChildrenGetterTy foo;
-  IDFCalculatorBase IDF(DomTree->getBase(), foo);
+  IDFCalculatorBase IDF(DomTree->getBase());
 
   IDF.setLiveInBlocks(AllBlocks);
   IDF.setDefiningBlocks(DefBlocks);
Index: llvm/include/llvm/Support/GenericIteratedDominanceFrontier.h
===
--- llvm/include/llvm/Support/GenericIteratedDominanceFrontier.h
+++ llvm/include/llvm/Support/GenericIteratedDominanceFrontier.h
@@ -37,7 +37,7 @@
 /// May be specialized if, for example, one wouldn't like to return nullpointer
 /// successors.
 template  struct ChildrenGetterTy {
-  using NodeRef = typename GraphTraits::NodeRef;
+  using NodeRef = typename GraphTraits::NodeRef;
   using ChildrenTy = SmallVector;
 
   ChildrenTy get(const NodeRef &N);
Index: clang/include/clang/Analysis/CFG.h
===
--- clang/include/clang/Analysis/CFG.h
+++ clang/include/clang/Analysis/CFG.h
@@ -1494,9 +1494,6 @@
   static ChildIteratorType child_end(NodeRef N) { return N->succ_end(); }
 };
 
-template <> struct GraphTraits
-: GraphTraits

[PATCH] D118385: [NFC] Optimize FoldingSet usage where it matters

[serge via Phabricator via cfe-commits]

serge-sans-paille added inline comments.



Comment at: clang/include/clang/AST/ASTContext.h:214
   mutable llvm::FoldingSet ComplexTypes;
-  mutable llvm::FoldingSet PointerTypes;
+  mutable llvm::FoldingSet PointerTypes{9};
   mutable llvm::FoldingSet AdjustedTypes;

It's probably good to give that value a meaningful ( and `constexpr`) variable 
name as it's used at several point. 



Comment at: clang/lib/AST/ASTContext.cpp:976
Builtin::Context &builtins, TranslationUnitKind TUKind)
-: ConstantArrayTypes(this_()), FunctionProtoTypes(this_()),
+: ConstantArrayTypes(this_(), 8), FunctionProtoTypes(this_(), 12),
   TemplateSpecializationTypes(this_()),

same here, that's a lot of magic values :-)



Comment at: clang/lib/CodeGen/CodeGenTypes.h:79
   /// Hold memoized CGFunctionInfo results.
-  llvm::FoldingSet FunctionInfos;
+  llvm::FoldingSet FunctionInfos{9};
 

And here



Comment at: llvm/include/llvm/ADT/FoldingSet.h:328
   /// Add* - Add various data types to Bit data.
-  void AddPointer(const void *Ptr);
-  void AddInteger(signed I);
-  void AddInteger(unsigned I);
-  void AddInteger(long I);
-  void AddInteger(unsigned long I);
-  void AddInteger(long long I);
-  void AddInteger(unsigned long long I);
+  void AddPointer(const void *Ptr) {
+// Note: this adds pointers to the hash using sizes and endianness that

Concerning that inlined part, I expect LTO to close the gap instead of moving 
everything to headers. Do we have a policy on that topic?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118385

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

[PATCH] D118370: [clang-tidy] bugprone-signal-handler: Code refactor (NFC)

[Nathan James via Phabricator via cfe-commits]

njames93 added inline comments.



Comment at: clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp:167
+   const Expr *CallOrRef) {
+  const bool FunctionIsCalled = isa(CallOrRef);
+

This can probably just be inlined into its only use.



Comment at: clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.h:36
 private:
+  bool checkFunction(const FunctionDecl *FD, const Expr *CallOrRef);
   bool isFunctionAsyncSafe(const FunctionDecl *FD) const;

This isn't a very descriptive name, and the bool return value conveys no 
meaning. Probably could do with some documentation.



Comment at: clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.h:46-49
   llvm::StringSet<> &ConformingFunctions;
 
   static llvm::StringSet<> MinimalConformingFunctions;
   static llvm::StringSet<> POSIXConformingFunctions;

While you're refactoring, those static StringSets really belong in the 
implementation file, and the ConformingFunctions should be a const ref.

However global destructores are kind of a taboo thing, Maybe there is case to 
change them into a sorted array and binary search them to see if a function is 
conforming.
Probably wouldn't advise using TableGens StringMatcher to build this 
functionality as that maybe a little too far.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118370

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

[PATCH] D118383: [OpenMP] Enable inoutset dependency-type in depend clause.

[David Pagan via Phabricator via cfe-commits]

ddpagan added a comment.

> Is it a new mode from OpenMP 5.2? Or 5.1? Can you add a check for OpenMP 
> version, if so?

Thanks for catching this, Alexey. It is new in OpenMP 5.1. I'll add a check for 
this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118383

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

[PATCH] D107769: [OpenCL] Make generic addrspace optional for -fdeclare-opencl-builtins

[Sven van Haastregt via Phabricator via cfe-commits]

svenvh updated this revision to Diff 403705.
svenvh edited the summary of this revision.
svenvh added a comment.

Make use of the `__opencl_c_named_address_space_builtins` internal feature 
added by D118158 .  This should avoid 
affecting OpenCL 2.0.


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

https://reviews.llvm.org/D107769

Files:
  clang/lib/Sema/OpenCLBuiltins.td
  clang/test/CodeGenOpenCL/fdeclare-opencl-builtins.cl
  clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl

Index: clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
===
--- clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
+++ clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
@@ -70,12 +70,15 @@
 
 // Enable extensions that are enabled in opencl-c-base.h.
 #if (defined(__OPENCL_CPP_VERSION__) || __OPENCL_C_VERSION__ >= 200)
+#define __opencl_c_generic_address_space 1
 #define cl_khr_subgroup_extended_types 1
 #define cl_khr_subgroup_ballot 1
 #define cl_khr_subgroup_non_uniform_arithmetic 1
 #define cl_khr_subgroup_clustered_reduce 1
 #define __opencl_c_read_write_images 1
 #endif
+
+#define __opencl_c_named_address_space_builtins 1
 #endif
 
 kernel void test_pointers(volatile global void *global_p, global const int4 *a) {
Index: clang/test/CodeGenOpenCL/fdeclare-opencl-builtins.cl
===
--- clang/test/CodeGenOpenCL/fdeclare-opencl-builtins.cl
+++ clang/test/CodeGenOpenCL/fdeclare-opencl-builtins.cl
@@ -1,5 +1,12 @@
-// RUN: %clang_cc1 -emit-llvm -o - -O0 -triple spir-unknown-unknown -cl-std=CL1.2 -finclude-default-header %s | FileCheck %s
-// RUN: %clang_cc1 -emit-llvm -o - -O0 -triple spir-unknown-unknown -cl-std=CL1.2 -fdeclare-opencl-builtins -finclude-default-header %s | FileCheck %s
+// RUN: %clang_cc1 -emit-llvm -o - -O0 -triple spir-unknown-unknown -cl-std=CL1.2 -finclude-default-header %s \
+// RUN: | FileCheck %s --check-prefixes CHECK,CHECK-NOGAS
+// RUN: %clang_cc1 -emit-llvm -o - -O0 -triple spir-unknown-unknown -cl-std=CL1.2 -fdeclare-opencl-builtins -finclude-default-header %s \
+// RUN: | FileCheck %s --check-prefixes CHECK,CHECK-NOGAS
+// RUN: %clang_cc1 -emit-llvm -o - -O0 -triple spir-unknown-unknown -cl-std=CL3.0 -fdeclare-opencl-builtins -finclude-default-header %s \
+// RUN: | FileCheck %s --check-prefixes CHECK,CHECK-GAS
+// RUN: %clang_cc1 -emit-llvm -o - -O0 -triple spir-unknown-unknown -cl-std=CL3.0 -fdeclare-opencl-builtins -finclude-default-header \
+// RUN: -cl-ext=-__opencl_c_generic_address_space,-__opencl_c_pipes,-__opencl_c_device_enqueue %s \
+// RUN: | FileCheck %s --check-prefixes CHECK,CHECK-NOGAS
 
 // Test that mix is correctly defined.
 // CHECK-LABEL: @test_float
@@ -32,6 +39,15 @@
   size_t lid = get_local_id(0);
 }
 
+// Test that the correct builtin is called depending on the generic address
+// space feature availability.
+// CHECK-LABEL: @test_generic_optionality
+// CHECK-GAS: call spir_func float @_Z5fractfPU3AS4f
+// CHECK-NOGAS: call spir_func float @_Z5fractfPf
+void test_generic_optionality(float a, float *b) {
+  float res = fract(a, b);
+}
+
 // CHECK: attributes [[ATTR_CONST]] =
 // CHECK-SAME: readnone
 // CHECK: attributes [[ATTR_PURE]] =
Index: clang/lib/Sema/OpenCLBuiltins.td
===
--- clang/lib/Sema/OpenCLBuiltins.td
+++ clang/lib/Sema/OpenCLBuiltins.td
@@ -85,6 +85,8 @@
 def FuncExtKhrGlMsaaSharing  : FunctionExtension<"cl_khr_gl_msaa_sharing">;
 def FuncExtKhrGlMsaaSharingReadWrite : FunctionExtension<"cl_khr_gl_msaa_sharing __opencl_c_read_write_images">;
 
+def FuncExtOpenCLCGenericAddressSpace: FunctionExtension<"__opencl_c_generic_address_space">;
+def FuncExtOpenCLCNamedAddressSpaceBuiltins : FunctionExtension<"__opencl_c_named_address_space_builtins">;
 def FuncExtOpenCLCPipes  : FunctionExtension<"__opencl_c_pipes">;
 def FuncExtOpenCLCWGCollectiveFunctions  : FunctionExtension<"__opencl_c_work_group_collective_functions">;
 def FuncExtOpenCLCReadWriteImages: FunctionExtension<"__opencl_c_read_write_images">;
@@ -591,10 +593,10 @@
   }
 }
 
-let MaxVersion = CL20 in {
+let Extension = FuncExtOpenCLCNamedAddressSpaceBuiltins in {
   defm : MathWithPointer<[GlobalAS, LocalAS, PrivateAS]>;
 }
-let MinVersion = CL20 in {
+let Extension = FuncExtOpenCLCGenericAddressSpace in {
   defm : MathWithPointer<[GenericAS]>;
 }
 
@@ -840,10 +842,10 @@
   }
 }
 
-let MaxVersion = CL20 in {
+let Extension = FuncExtOpenCLCNamedAddressSpaceBuiltins in {
   defm : VloadVstore<[GlobalAS, LocalAS, PrivateAS], 1>;
 }
-let MinVersion = CL20 in {
+let Extension = FuncExtOpenCLCGenericAddressSpace in {
   defm : VloadVstore<[GenericAS], 1>;
 }
 // vload with constant address space is available regardless of version.
@@ -874,10 +876,10 @@
   }
 }
 
-let MaxVersion = CL20 in {
+let Extension = FuncExtOpenCLCNamedAd

[PATCH] D117929: [XRay] Add support for RISCV

[Ashwin Poduval via Phabricator via cfe-commits]

ashwin98 updated this revision to Diff 403707.
ashwin98 added a comment.

Fixed another lint issue, they should all be done for now hopefully.

@dberris Sorry, I'm a little confused, do you mean I need to update some of the 
clang tests for XRay instrumentation to test compilation and linking, or add 
new ones for the llvm-xray tool under llvm/test/tools?


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

https://reviews.llvm.org/D117929

Files:
  clang/lib/Driver/XRayArgs.cpp
  compiler-rt/cmake/Modules/AllSupportedArchDefs.cmake
  compiler-rt/lib/xray/CMakeLists.txt
  compiler-rt/lib/xray/xray_interface.cpp
  compiler-rt/lib/xray/xray_riscv.cpp
  compiler-rt/lib/xray/xray_trampoline_riscv32.S
  compiler-rt/lib/xray/xray_trampoline_riscv64.S
  compiler-rt/lib/xray/xray_tsc.h
  llvm/lib/CodeGen/XRayInstrumentation.cpp
  llvm/lib/Target/RISCV/RISCVAsmPrinter.cpp
  llvm/lib/Target/RISCV/RISCVSubtarget.h
  llvm/test/CodeGen/RISCV/xray-attribute-instrumentation.ll

Index: llvm/test/CodeGen/RISCV/xray-attribute-instrumentation.ll
===
--- /dev/null
+++ llvm/test/CodeGen/RISCV/xray-attribute-instrumentation.ll
@@ -0,0 +1,70 @@
+; RUN: llc -mtriple=riscv32-unknown-elf -mattr=+d -verify-machineinstrs < %s | FileCheck --check-prefix=CHECK %s
+; RUN: llc -mtriple=riscv32-unknown-linux-gnu -mattr=+d -verify-machineinstrs < %s | FileCheck --check-prefix=CHECK %s
+; RUN: llc -mtriple=riscv64-unknown-elf -mattr=+d -verify-machineinstrs < %s | FileCheck --check-prefix=CHECK --check-prefix=CHECK-RISCV64 %s
+; RUN: llc -mtriple=riscv64-unknown-linux-gnu -mattr=+d -verify-machineinstrs < %s | FileCheck --check-prefix=CHECK --check-prefix=CHECK-RISCV64 %s
+
+define i32 @foo() nounwind "function-instrument"="xray-always" {
+; CHECK:.p2align 2
+; CHECK-LABEL:  .Lxray_sled_0:
+; CHECK-NEXT:   j .Ltmp0
+; CHECK-NEXT:   nop
+; CHECK-NEXT:   nop
+; CHECK-NEXT:   nop
+; CHECK-NEXT:   nop
+; CHECK-NEXT:   nop
+; CHECK-NEXT:   nop
+; CHECK-NEXT:   nop
+; CHECK-NEXT:   nop
+; CHECK-NEXT:   nop
+; CHECK-NEXT:   nop
+; CHECK-NEXT:   nop
+; CHECK-NEXT:   nop
+; CHECK-NEXT:   nop
+; CHECK-NEXT:   nop
+; CHECK-RISCV64:nop
+; CHECK-RISCV64:nop
+; CHECK-RISCV64:nop
+; CHECK-RISCV64:nop
+; CHECK-RISCV64:nop
+; CHECK-RISCV64:nop
+; CHECK-RISCV64:nop
+; CHECK-RISCV64:nop
+; CHECK-RISCV64:nop
+; CHECK-RISCV64:nop
+; CHECK-LABEL:  .Ltmp0:
+  ret i32 0
+; CHECK:.p2align 2
+; CHECK-LABEL:  .Lxray_sled_1:
+; CHECK-NEXT:   j .Ltmp1
+; CHECK-NEXT:   nop
+; CHECK-NEXT:   nop
+; CHECK-NEXT:   nop
+; CHECK-NEXT:   nop
+; CHECK-NEXT:   nop
+; CHECK-NEXT:   nop
+; CHECK-NEXT:   nop
+; CHECK-NEXT:   nop
+; CHECK-NEXT:   nop
+; CHECK-NEXT:   nop
+; CHECK-NEXT:   nop
+; CHECK-NEXT:   nop
+; CHECK-NEXT:   nop
+; CHECK-NEXT:   nop
+; CHECK-RISCV64:nop
+; CHECK-RISCV64:nop
+; CHECK-RISCV64:nop
+; CHECK-RISCV64:nop
+; CHECK-RISCV64:nop
+; CHECK-RISCV64:nop
+; CHECK-RISCV64:nop
+; CHECK-RISCV64:nop
+; CHECK-RISCV64:nop
+; CHECK-RISCV64:nop
+; CHECK-LABEL:  .Ltmp1:
+; CHECK-NEXT:   ret
+}
+; CHECK:.section xray_instr_map,"ao",@progbits,foo
+; CHECK-LABEL:  .Lxray_sleds_start0:
+; CHECK:.Lxray_sled_0-.Ltmp2
+; CHECK:.Lxray_sled_1-.Ltmp3
+; CHECK-LABEL:  .Lxray_sleds_end0:
Index: llvm/lib/Target/RISCV/RISCVSubtarget.h
===
--- llvm/lib/Target/RISCV/RISCVSubtarget.h
+++ llvm/lib/Target/RISCV/RISCVSubtarget.h
@@ -187,6 +187,11 @@
   unsigned getMaxInterleaveFactor() const {
 return hasVInstructions() ? MaxInterleaveFactor : 1;
   }
+  // Add XRay support - needs double precision floats at present and does not
+  // support compressed instructions
+  bool isXRaySupported() const override {
+return hasStdExtD() && !hasStdExtC();
+  }
 
 protected:
   // GlobalISel related APIs.
Index: llvm/lib/Target/RISCV/RISCVAsmPrinter.cpp
===
--- llvm/lib/Target/RISCV/RISCVAsmPrinter.cpp
+++ llvm/lib/Target/RISCV/RISCVAsmPrinter.cpp
@@ -15,6 +15,7 @@
 #include "MCTargetDesc/RISCVMCExpr.h"
 #include "MCTargetDesc/RISCVTargetStreamer.h"
 #include "RISCV.h"
+#include "RISCVSubtarget.h"
 #include "RISCVTargetMachine.h"
 #include "TargetInfo/RISCVTargetInfo.h"
 #include "llvm/ADT/Statistic.h"
@@ -25,10 +26,12 @@
 #include "llvm/CodeGen/MachineModuleInfo.h"
 #include "llvm/MC/MCAsmInfo.h"
 #include "llvm/MC/MCInst.h"
+#include "llvm/MC/MCInstBuilder.h"

[PATCH] D118153: [CUDA][HIP] Do not treat host var address as constant in device compilation

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl updated this revision to Diff 403706.
yaxunl added a comment.

Fix the regression in lit tests.

Basically in device compilation we still evaluate constant expression for host 
functions or host template instantiation. If we just disallow host variable in 
any constant expressions we will get errors in template class instantiation 
which use host variables as non-type template arguments.

Therefore we should only disallow host variables in constant expressions in 
situations when we are sure that allowing them will lead to issues, e.g. when 
promoting const variables.

A CUDAConstantEvaluationContext is introduced in ASTContext to control this.


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

https://reviews.llvm.org/D118153

Files:
  clang/include/clang/AST/ASTContext.h
  clang/lib/AST/ExprConstant.cpp
  clang/lib/Sema/SemaCUDA.cpp
  clang/test/CodeGenCUDA/const-var.cu
  clang/test/SemaCUDA/const-var.cu

Index: clang/test/SemaCUDA/const-var.cu
===
--- /dev/null
+++ clang/test/SemaCUDA/const-var.cu
@@ -0,0 +1,57 @@
+// RUN: %clang_cc1 -triple amdgcn-amd-amdhsa -fcuda-is-device -x hip %s \
+// RUN:   -fsyntax-only -verify
+
+#include "Inputs/cuda.h"
+
+// Test const var initialized with address of a const var.
+// Both are promoted to device side.
+
+namespace Test1 {
+const int a = 1;
+
+struct B {
+static const int *const p;
+__device__ static const int *const p2;
+};
+const int *const B::p = &a;
+__device__ const int *const B::p2 = &a;
+
+__device__ void f() {
+  int y = a;
+  const int *x = B::p;
+  const int *z = B::p2;
+}
+}
+
+// Test const var initialized with address of a non-cost var.
+// Neither is promoted to device side.
+
+namespace Test2 {
+int a = 1;
+// expected-note@-1{{host variable declared here}}
+
+struct B {
+static int *const p;
+};
+int *const B::p = &a;
+// expected-note@-1{{const variable cannot be emitted on device side due to dynamic initialization}}
+
+__device__ void f() {
+  int y = a;
+  // expected-error@-1{{reference to __host__ variable 'a' in __device__ function}}
+  const int *x = B::p;
+  // expected-error@-1{{reference to __host__ variable 'p' in __device__ function}}
+}
+}
+
+// Test device var initialized with address of a non-const host var.
+
+namespace Test3 {
+int a = 1;
+
+struct B {
+__device__ static int *const p;
+};
+__device__ int *const B::p = &a;
+// expected-error@-1{{dynamic initialization is not supported for __device__, __constant__, __shared__, and __managed__ variables}}
+}
Index: clang/test/CodeGenCUDA/const-var.cu
===
--- /dev/null
+++ clang/test/CodeGenCUDA/const-var.cu
@@ -0,0 +1,45 @@
+// REQUIRES: amdgpu-registered-target
+// RUN: %clang_cc1 -triple amdgcn-amd-amdhsa -fcuda-is-device -x hip %s \
+// RUN:   -emit-llvm -o - | FileCheck -check-prefix=DEV %s
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -x hip %s \
+// RUN:   -emit-llvm -o - | FileCheck -check-prefix=HOST %s
+
+// Negative tests.
+
+// RUN: %clang_cc1 -triple amdgcn-amd-amdhsa -fcuda-is-device -x hip %s \
+// RUN:   -emit-llvm -o - | FileCheck -check-prefix=DEV-NEG %s
+
+#include "Inputs/cuda.h"
+
+// Test const var initialized with address of a const var.
+// Both are promoted to device side.
+
+// DEV-DAG: @_ZN5Test1L1aE = internal addrspace(4) constant i32 1
+// DEV-DAG: @_ZN5Test11B1pE = addrspace(4) externally_initialized constant i32* addrspacecast (i32 addrspace(4)* @_ZN5Test1L1aE to i32*)
+// HOST-DAG: @_ZN5Test1L1aE = internal constant i32 1
+// HOST-DAG: @_ZN5Test11B1pE = constant i32* @_ZN5Test1L1aE
+namespace Test1 {
+const int a = 1;
+
+struct B {
+static const int *const p;
+};
+const int *const B::p = &a;
+}
+
+// Test const var initialized with address of a non-cost var.
+// Neither is promoted to device side.
+
+// DEV-NEG-NOT: @_ZN5Test2L1aE
+// DEV-NEG-NOT: @_ZN5Test21B1pE
+// HOST-DAG: @_ZN5Test21aE = global i32 1
+// HOST-DAG: @_ZN5Test21B1pE = constant i32* @_ZN5Test21aE
+
+namespace Test2 {
+int a = 1;
+
+struct B {
+static int *const p;
+};
+int *const B::p = &a;
+}
Index: clang/lib/Sema/SemaCUDA.cpp
===
--- clang/lib/Sema/SemaCUDA.cpp
+++ clang/lib/Sema/SemaCUDA.cpp
@@ -590,6 +590,8 @@
   };
   auto IsConstantInit = [&](const Expr *Init) {
 assert(Init);
+ASTContext::CUDAConstantEvalContextRAII EvalCtx(S.Context,
+/*NoWronSidedVars=*/true);
 return Init->isConstantInitializer(S.Context,
VD->getType()->isReferenceType());
   };
Index: clang/lib/AST/ExprConstant.cpp
===
--- clang/lib/AST/ExprConstant.cpp
+++ clang/lib/AST/ExprConstant.cpp
@@ -983,6 +983,8 @@
   discardCleanups();
 }
 
+ASTContext &getCtx() const override { return Ctx; 

[PATCH] D107290: [RISCV] Add support for the vscale_range attribute

[Zakk Chen via Phabricator via cfe-commits]

khchen added inline comments.



Comment at: llvm/lib/Target/RISCV/RISCVTargetMachine.cpp:99
+  if (VScaleRangeAttr.isValid()) {
+RVVBitsMin = VScaleRangeAttr.getVScaleRangeMin() * RISCV::RVVBitsPerBlock;
+if (VScaleRangeAttr.getVScaleRangeMax().hasValue())

Could we have an assertion to prevent RVVBitsMin and Zvl are different?




Comment at: llvm/lib/Target/RISCV/RISCVTargetMachine.cpp:105
+  RVVBitsMax = RISCV::RVVVLENBitsMax;
+  }
+  // Allow user options to override these.

For forward compatibility, if there is no VScaleRangeAttr, maybe we could 
initialize the RVVBitsMin as zvl*b if it is present?
I guess maybe some exist IRs have zvl with no VScaleRangeAttr?



Comment at: llvm/test/CodeGen/RISCV/rvv/fixed-vectors-vscale-range.ll:162
+
+attributes #0 = { vscale_range(2,1024) }
+attributes #1 = { vscale_range(4,1024) }

frasercrmck wrote:
> khchen wrote:
> > frasercrmck wrote:
> > > khchen wrote:
> > > > I'm thinking do we need to test zvl and vscale_range in the same 
> > > > attribute?
> > > > ex. `attributes #0 = { vscale_range(2,1024) 
> > > > "target-features"="+zvl512b" }`
> > > Perhaps yeah. Just to check - what exactly for? Because we need `zvl` in 
> > > the attributes for correctness, or in order to test the combination of 
> > > `zvl` architecture and `vscale_range` to test what happens when they 
> > > disagree?
> > Just test for they disagree.
> > Do you know what's expected value for different `vscale_range` value in two 
> > function after function inlining? If they are always have the same minimum 
> > value for VLEN, I think we don't need a check.
> Good idea.
> 
> As for inlining, I can't see anything that would //prevent// inlining of 
> functions with different `vscale_range` attributes, per se. However, I was 
> looking at `TTI::areInlineCompatible` and the default implementation checks 
> whether CPU/Feature Strings are equivalent. The frontend should ensure that 
> `vscale_range` attributes match up 1:1 with our `+zvl` feature strings so I 
> think in practice we won't inline functions with different `zvl` values in 
> clang-generated C/C++ code. But users could write IR with different 
> `vscale_range` attributes and we'd happily inline them, which sounds fishy. 
> What do you think?
Thanks for investigation!!! 
I think we can postpone this inline issue until we really need to fix it. 
at least the function would keep the feature string, which may include zvl*b, 
right?

BTW, could you please try the C code in https://godbolt.org/z/6hfTaxTj5 to see 
what's `vscale_range` value for function `vadd256` and `vadd512`? Are they 
expected value?




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107290

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

[PATCH] D117898: [Clang] Add elementwise saturated add/sub builtins

[Simon Pilgrim via Phabricator via cfe-commits]

RKSimon added a comment.

ping?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117898

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

[PATCH] D115393: [InstrProf][NFC] Refactor Profile kind into a bitset enum.

[Ellis Hoag via Phabricator via cfe-commits]

ellis added inline comments.



Comment at: llvm/include/llvm/ProfileData/InstrProf.h:281-282
 
+/// An enum describing the attributes of an instrumented profile.
+enum class InstrProfKind {
+  Unknown = 0x0,

I've been working on a new coverage instrumentation in D116180 that I guess 
would need to be added this this enum. The plan was to first add function entry 
coverage, then basic block coverage.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115393

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

[clang] 1fec215 - [ARM][AArch64] Cleanup and autogenerate v8.1a vqdrmlah tests. NFC

[David Green via cfe-commits]

Author: David Green
Date: 2022-01-27T18:43:06Z
New Revision: 1fec2154b29f84b53dd578b9f87f34e255630771

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

LOG: [ARM][AArch64] Cleanup and autogenerate v8.1a vqdrmlah tests. NFC

Added: 


Modified: 
clang/test/CodeGen/aarch64-v8.1a-neon-intrinsics.c
clang/test/CodeGen/arm-v8.1a-neon-intrinsics.c
llvm/test/CodeGen/AArch64/arm64-neon-v8.1a.ll
llvm/test/CodeGen/ARM/neon-v8.1a.ll

Removed: 




diff  --git a/clang/test/CodeGen/aarch64-v8.1a-neon-intrinsics.c 
b/clang/test/CodeGen/aarch64-v8.1a-neon-intrinsics.c
index 7abfa3bda7281..ac583eddaecaa 100644
--- a/clang/test/CodeGen/aarch64-v8.1a-neon-intrinsics.c
+++ b/clang/test/CodeGen/aarch64-v8.1a-neon-intrinsics.c
@@ -1,198 +1,275 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
 // RUN: %clang_cc1 -triple aarch64-linux-gnu -target-feature +neon \
-// RUN:  -target-feature +v8.1a -S -emit-llvm -o - %s | FileCheck %s
+// RUN:  -target-feature +v8.1a -S -emit-llvm -disable-O0-optnone -o - %s | 
opt -mem2reg -dce -S | FileCheck %s
 
 // REQUIRES: aarch64-registered-target
 
  #include 
 
-// CHECK-LABEL: test_vqrdmlah_laneq_s16
+// CHECK-LABEL: @test_vqrdmlah_laneq_s16(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[TMP0:%.*]] = bitcast <8 x i16> [[V:%.*]] to <16 x i8>
+// CHECK-NEXT:[[TMP1:%.*]] = bitcast <16 x i8> [[TMP0]] to <8 x i16>
+// CHECK-NEXT:[[LANE:%.*]] = shufflevector <8 x i16> [[TMP1]], <8 x i16> 
[[TMP1]], <4 x i32> 
+// CHECK-NEXT:[[VQRDMULH_V2_I:%.*]] = call <4 x i16> 
@llvm.aarch64.neon.sqrdmulh.v4i16(<4 x i16> [[B:%.*]], <4 x i16> [[LANE]]) 
#[[ATTR4:[0-9]+]]
+// CHECK-NEXT:[[VQADD_V2_I:%.*]] = call <4 x i16> 
@llvm.aarch64.neon.sqadd.v4i16(<4 x i16> [[A:%.*]], <4 x i16> 
[[VQRDMULH_V2_I]]) #[[ATTR4]]
+// CHECK-NEXT:ret <4 x i16> [[VQADD_V2_I]]
+//
 int16x4_t test_vqrdmlah_laneq_s16(int16x4_t a, int16x4_t b, int16x8_t v) {
-// CHECK: shufflevector <8 x i16> {{%.*}}, <8 x i16> {{%.*}}, <4 x i32> 
-// CHECK: call <4 x i16> @llvm.aarch64.neon.sqrdmulh.v4i16(<4 x i16> {{%.*}}, 
<4 x i16> {{%.*}})
-// CHECK: call <4 x i16> @llvm.aarch64.neon.sqadd.v4i16(<4 x i16> {{%.*}}, <4 
x i16> {{%.*}})
   return vqrdmlah_laneq_s16(a, b, v, 7);
 }
 
-// CHECK-LABEL: test_vqrdmlah_laneq_s32
+// CHECK-LABEL: @test_vqrdmlah_laneq_s32(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[TMP0:%.*]] = bitcast <4 x i32> [[V:%.*]] to <16 x i8>
+// CHECK-NEXT:[[TMP1:%.*]] = bitcast <16 x i8> [[TMP0]] to <4 x i32>
+// CHECK-NEXT:[[LANE:%.*]] = shufflevector <4 x i32> [[TMP1]], <4 x i32> 
[[TMP1]], <2 x i32> 
+// CHECK-NEXT:[[VQRDMULH_V2_I:%.*]] = call <2 x i32> 
@llvm.aarch64.neon.sqrdmulh.v2i32(<2 x i32> [[B:%.*]], <2 x i32> [[LANE]]) 
#[[ATTR4]]
+// CHECK-NEXT:[[VQADD_V2_I:%.*]] = call <2 x i32> 
@llvm.aarch64.neon.sqadd.v2i32(<2 x i32> [[A:%.*]], <2 x i32> 
[[VQRDMULH_V2_I]]) #[[ATTR4]]
+// CHECK-NEXT:ret <2 x i32> [[VQADD_V2_I]]
+//
 int32x2_t test_vqrdmlah_laneq_s32(int32x2_t a, int32x2_t b, int32x4_t v) {
-// CHECK: shufflevector <4 x i32> {{%.*}}, <4 x i32> {{%.*}}, <2 x i32> 
-// CHECK: call <2 x i32> @llvm.aarch64.neon.sqrdmulh.v2i32(<2 x i32> {{%.*}}, 
<2 x i32> {{%.*}})
-// CHECK: call <2 x i32> @llvm.aarch64.neon.sqadd.v2i32(<2 x i32> {{%.*}}, <2 
x i32> {{%.*}})
   return vqrdmlah_laneq_s32(a, b, v, 3);
 }
 
-// CHECK-LABEL: test_vqrdmlahq_laneq_s16
+// CHECK-LABEL: @test_vqrdmlahq_laneq_s16(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[TMP0:%.*]] = bitcast <8 x i16> [[V:%.*]] to <16 x i8>
+// CHECK-NEXT:[[TMP1:%.*]] = bitcast <16 x i8> [[TMP0]] to <8 x i16>
+// CHECK-NEXT:[[LANE:%.*]] = shufflevector <8 x i16> [[TMP1]], <8 x i16> 
[[TMP1]], <8 x i32> 
+// CHECK-NEXT:[[VQRDMULHQ_V2_I:%.*]] = call <8 x i16> 
@llvm.aarch64.neon.sqrdmulh.v8i16(<8 x i16> [[B:%.*]], <8 x i16> [[LANE]]) 
#[[ATTR4]]
+// CHECK-NEXT:[[VQADDQ_V2_I:%.*]] = call <8 x i16> 
@llvm.aarch64.neon.sqadd.v8i16(<8 x i16> [[A:%.*]], <8 x i16> 
[[VQRDMULHQ_V2_I]]) #[[ATTR4]]
+// CHECK-NEXT:ret <8 x i16> [[VQADDQ_V2_I]]
+//
 int16x8_t test_vqrdmlahq_laneq_s16(int16x8_t a, int16x8_t b, int16x8_t v) {
-// CHECK: shufflevector <8 x i16> {{%.*}}, <8 x i16> {{%.*}}, <8 x i32> 
-// CHECK: call <8 x i16> @llvm.aarch64.neon.sqrdmulh.v8i16(<8 x i16> {{%.*}}, 
<8 x i16> {{%.*}})
-// CHECK: call <8 x i16> @llvm.aarch64.neon.sqadd.v8i16(<8 x i16> {{%.*}}, <8 
x i16> {{%.*}})
   return vqrdmlahq_laneq_s16(a, b, v, 7);
 }
 
-// CHECK-LABEL: test_vqrdmlahq_laneq_s32
+// CHECK-LABEL: @test_vqrdmlahq_laneq_s32(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[TMP0:%.*]] = bitcast <4 x i32> [[V:%.*]] to <16 x i8>
+// CHECK-NEXT:[[TMP1:%.*]] = bitcast <16 x i8> [[TMP0]] to <4 x i32>
+// CHECK-NEXT:[[LANE:%.*]] = shufflevector <4 x i32> [[TMP1]]

[PATCH] D115393: [InstrProf][NFC] Refactor Profile kind into a bitset enum.

[Snehasish Kumar via Phabricator via cfe-commits]

snehasish added inline comments.



Comment at: llvm/include/llvm/ProfileData/InstrProf.h:281-282
 
+/// An enum describing the attributes of an instrumented profile.
+enum class InstrProfKind {
+  Unknown = 0x0,

ellis wrote:
> I've been working on a new coverage instrumentation in D116180 that I guess 
> would need to be added this this enum. The plan was to first add function 
> entry coverage, then basic block coverage.
Yes this makes the enum composable and brings it in line with the Variant mask 
encoding in the indexed profile header. Let me go ahead and submit this (after 
rebasing and testing) so that you can rebase your changes. Thanks for the heads 
up!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115393

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

[PATCH] D117616: GCC ABI Compatibility: Preserve alignment of non-pod members in packed structs

[Reid Kleckner via Phabricator via cfe-commits]

rnk added inline comments.



Comment at: clang/lib/AST/RecordLayoutBuilder.cpp:1890
 
-  bool FieldPacked = Packed || D->hasAttr();
+  llvm::Triple Target = Context.getTargetInfo().getTriple();
+  bool FieldPacked = (Packed && (!FieldClass || FieldClass->isPOD() ||

I think GCC implements this by ignoring the packed attribute on classes with 
such non-C++98-pod fields. See this case for example:
https://gcc.godbolt.org/z/fe8x1ne7o
```
class NonPod {
void method();
int x;
};
struct __attribute__((packed)) PackedNonPod {
char a;
NonPod b;
char c;
int d;
};
PackedNonPod gv;

static_assert(sizeof(PackedNonPod) == 4 * 4, "drop packed");
```
-->
```
:7:12: warning: ignoring packed attribute because of unpacked non-POD 
field 'NonPod PackedNonPod::b'
7 | NonPod b;
```

So, in this case, the entire record is unpacked. `d` appears at offset 12, and 
the overall size is 16. Your code, as I understand it, handles each field 
individually, which isn't quite the same.

I think the fix is in Sema somewhere to drop the attribute.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117616

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