[clang] 028c103 - [Driver][BareMetal] Error if no matching multilib

[Michael Platings via cfe-commits]

Author: Michael Platings
Date: 2023-06-22T08:10:43+01:00
New Revision: 028c1033b1ed7b35beab736dd50053f80df02fa3

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

LOG: [Driver][BareMetal] Error if no matching multilib

Previously if no matching multilib was found then the user would
typically see an error like "fatal error: 'stdio.h' file not found"
which gives no indication as to the underlying problem.
With this change the user will instead see an error like
  clang: error: no multilib found matching flags: 
--target=thumbv7em-none-unknown-eabi -march=...
  clang: note: available multilibs are:
  --target=armv4t-none-unknown-eabi
  --target=thumbv6m-none-unknown-eabi -mfpu=none
  ...

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

Added: 


Modified: 
clang/include/clang/Basic/DiagnosticDriverKinds.td
clang/lib/Driver/ToolChains/BareMetal.cpp
clang/test/Driver/baremetal-multilib.yaml

Removed: 




diff  --git a/clang/include/clang/Basic/DiagnosticDriverKinds.td 
b/clang/include/clang/Basic/DiagnosticDriverKinds.td
index ff0f693061a39..635f6e755cdcb 100644
--- a/clang/include/clang/Basic/DiagnosticDriverKinds.td
+++ b/clang/include/clang/Basic/DiagnosticDriverKinds.td
@@ -733,4 +733,9 @@ def err_drv_loongarch_invalid_mfpu_EQ : Error<
 
 def err_drv_expand_response_file : Error<
   "failed to expand response file: %0">;
+
+def err_drv_no_matching_multilib : Error<
+  "no multilib found matching flags: %0">;
+def note_drv_available_multilibs : Note<
+  "available multilibs are:%0">;
 }

diff  --git a/clang/lib/Driver/ToolChains/BareMetal.cpp 
b/clang/lib/Driver/ToolChains/BareMetal.cpp
index 17fd1f88975b9..09cc72f03363d 100644
--- a/clang/lib/Driver/ToolChains/BareMetal.cpp
+++ b/clang/lib/Driver/ToolChains/BareMetal.cpp
@@ -23,6 +23,8 @@
 #include "llvm/Support/VirtualFileSystem.h"
 #include "llvm/Support/raw_ostream.h"
 
+#include 
+
 using namespace llvm::opt;
 using namespace clang;
 using namespace clang::driver;
@@ -158,20 +160,26 @@ static bool isRISCVBareMetal(const llvm::Triple &Triple) {
   return Triple.getEnvironmentName() == "elf";
 }
 
-static bool findMultilibsFromYAML(const ToolChain &TC, const Driver &D,
+static void findMultilibsFromYAML(const ToolChain &TC, const Driver &D,
   StringRef MultilibPath, const ArgList &Args,
   DetectedMultilibs &Result) {
   llvm::ErrorOr> MB =
   D.getVFS().getBufferForFile(MultilibPath);
   if (!MB)
-return false;
+return;
   Multilib::flags_list Flags = TC.getMultilibFlags(Args);
   llvm::ErrorOr ErrorOrMultilibSet =
   MultilibSet::parseYaml(*MB.get());
   if (ErrorOrMultilibSet.getError())
-return false;
+return;
   Result.Multilibs = ErrorOrMultilibSet.get();
-  return Result.Multilibs.select(Flags, Result.SelectedMultilibs);
+  if (Result.Multilibs.select(Flags, Result.SelectedMultilibs))
+return;
+  D.Diag(clang::diag::err_drv_no_matching_multilib) << llvm::join(Flags, " ");
+  std::stringstream ss;
+  for (const Multilib &Multilib : Result.Multilibs)
+ss << "\n" << llvm::join(Multilib.flags(), " ");
+  D.Diag(clang::diag::note_drv_available_multilibs) << ss.str();
 }
 
 static constexpr llvm::StringLiteral MultilibFilename = "multilib.yaml";

diff  --git a/clang/test/Driver/baremetal-multilib.yaml 
b/clang/test/Driver/baremetal-multilib.yaml
index 93fa61ce6adf0..e3281fa3b04b6 100644
--- a/clang/test/Driver/baremetal-multilib.yaml
+++ b/clang/test/Driver/baremetal-multilib.yaml
@@ -20,6 +20,16 @@
 # CHECK-SAME: "-lc" "-lm" "-lclang_rt.builtins"
 # CHECK-SAME: "-o" "{{.*}}.tmp.out"
 
+# RUN: %T/baremetal_multilib/bin/clang -no-canonical-prefixes -x c++ %s -### 
-o %t.out 2>&1 \
+# RUN: --target=thumbv7em-none-eabi -mfpu=fpv4-sp-d16 --sysroot= \
+# RUN:   | FileCheck --check-prefix=CHECK-NO-MATCH %s
+# CHECK-NO-MATCH: error: no multilib found matching flags:
+# CHECK-NO-MATCH-SAME: --target=thumbv7em-none-unknown-eabi
+# CHECK-NO-MATCH: note: available multilibs are:
+# CHECK-NO-MATCH: --target=thumbv6m-none-unknown-eabi -mfpu=none
+# CHECK-NO-MATCH: --target=thumbv7m-none-unknown-eabi -mfpu=none
+# CHECK-NO-MATCH: --target=thumbv7em-none-unknown-eabi -mfpu=none
+
 # RUN: %T/baremetal_multilib/bin/clang -no-canonical-prefixes 
-print-multi-directory 2>&1 \
 # RUN: --target=thumbv8m.main-none-eabihf --sysroot= \
 # RUN:   | FileCheck --check-prefix=CHECK-PRINT-MULTI-DIRECTORY %s
@@ -75,6 +85,9 @@ MultilibVersion: 1.0
 # multilib, layered on top of each other.
 
 Variants:
+- Dir: arm-none-eabi/arm/v4t
+  Flags: [--target=armv4t-none-unknown-eabi]
+
 - Dir: arm-none-eabi/thumb/v6-m/nofp
   Flags: [--target=thumbv6m-none-unknown-eabi, -mfpu=none]
 



___

[PATCH] D153292: [Driver][BareMetal] Error if no matching multilib

[Michael Platings via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG028c1033b1ed: [Driver][BareMetal] Error if no matching 
multilib (authored by michaelplatings).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153292

Files:
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/lib/Driver/ToolChains/BareMetal.cpp
  clang/test/Driver/baremetal-multilib.yaml


Index: clang/test/Driver/baremetal-multilib.yaml
===
--- clang/test/Driver/baremetal-multilib.yaml
+++ clang/test/Driver/baremetal-multilib.yaml
@@ -20,6 +20,16 @@
 # CHECK-SAME: "-lc" "-lm" "-lclang_rt.builtins"
 # CHECK-SAME: "-o" "{{.*}}.tmp.out"
 
+# RUN: %T/baremetal_multilib/bin/clang -no-canonical-prefixes -x c++ %s -### 
-o %t.out 2>&1 \
+# RUN: --target=thumbv7em-none-eabi -mfpu=fpv4-sp-d16 --sysroot= \
+# RUN:   | FileCheck --check-prefix=CHECK-NO-MATCH %s
+# CHECK-NO-MATCH: error: no multilib found matching flags:
+# CHECK-NO-MATCH-SAME: --target=thumbv7em-none-unknown-eabi
+# CHECK-NO-MATCH: note: available multilibs are:
+# CHECK-NO-MATCH: --target=thumbv6m-none-unknown-eabi -mfpu=none
+# CHECK-NO-MATCH: --target=thumbv7m-none-unknown-eabi -mfpu=none
+# CHECK-NO-MATCH: --target=thumbv7em-none-unknown-eabi -mfpu=none
+
 # RUN: %T/baremetal_multilib/bin/clang -no-canonical-prefixes 
-print-multi-directory 2>&1 \
 # RUN: --target=thumbv8m.main-none-eabihf --sysroot= \
 # RUN:   | FileCheck --check-prefix=CHECK-PRINT-MULTI-DIRECTORY %s
@@ -75,6 +85,9 @@
 # multilib, layered on top of each other.
 
 Variants:
+- Dir: arm-none-eabi/arm/v4t
+  Flags: [--target=armv4t-none-unknown-eabi]
+
 - Dir: arm-none-eabi/thumb/v6-m/nofp
   Flags: [--target=thumbv6m-none-unknown-eabi, -mfpu=none]
 
Index: clang/lib/Driver/ToolChains/BareMetal.cpp
===
--- clang/lib/Driver/ToolChains/BareMetal.cpp
+++ clang/lib/Driver/ToolChains/BareMetal.cpp
@@ -23,6 +23,8 @@
 #include "llvm/Support/VirtualFileSystem.h"
 #include "llvm/Support/raw_ostream.h"
 
+#include 
+
 using namespace llvm::opt;
 using namespace clang;
 using namespace clang::driver;
@@ -158,20 +160,26 @@
   return Triple.getEnvironmentName() == "elf";
 }
 
-static bool findMultilibsFromYAML(const ToolChain &TC, const Driver &D,
+static void findMultilibsFromYAML(const ToolChain &TC, const Driver &D,
   StringRef MultilibPath, const ArgList &Args,
   DetectedMultilibs &Result) {
   llvm::ErrorOr> MB =
   D.getVFS().getBufferForFile(MultilibPath);
   if (!MB)
-return false;
+return;
   Multilib::flags_list Flags = TC.getMultilibFlags(Args);
   llvm::ErrorOr ErrorOrMultilibSet =
   MultilibSet::parseYaml(*MB.get());
   if (ErrorOrMultilibSet.getError())
-return false;
+return;
   Result.Multilibs = ErrorOrMultilibSet.get();
-  return Result.Multilibs.select(Flags, Result.SelectedMultilibs);
+  if (Result.Multilibs.select(Flags, Result.SelectedMultilibs))
+return;
+  D.Diag(clang::diag::err_drv_no_matching_multilib) << llvm::join(Flags, " ");
+  std::stringstream ss;
+  for (const Multilib &Multilib : Result.Multilibs)
+ss << "\n" << llvm::join(Multilib.flags(), " ");
+  D.Diag(clang::diag::note_drv_available_multilibs) << ss.str();
 }
 
 static constexpr llvm::StringLiteral MultilibFilename = "multilib.yaml";
Index: clang/include/clang/Basic/DiagnosticDriverKinds.td
===
--- clang/include/clang/Basic/DiagnosticDriverKinds.td
+++ clang/include/clang/Basic/DiagnosticDriverKinds.td
@@ -733,4 +733,9 @@
 
 def err_drv_expand_response_file : Error<
   "failed to expand response file: %0">;
+
+def err_drv_no_matching_multilib : Error<
+  "no multilib found matching flags: %0">;
+def note_drv_available_multilibs : Note<
+  "available multilibs are:%0">;
 }


Index: clang/test/Driver/baremetal-multilib.yaml
===
--- clang/test/Driver/baremetal-multilib.yaml
+++ clang/test/Driver/baremetal-multilib.yaml
@@ -20,6 +20,16 @@
 # CHECK-SAME: "-lc" "-lm" "-lclang_rt.builtins"
 # CHECK-SAME: "-o" "{{.*}}.tmp.out"
 
+# RUN: %T/baremetal_multilib/bin/clang -no-canonical-prefixes -x c++ %s -### -o %t.out 2>&1 \
+# RUN: --target=thumbv7em-none-eabi -mfpu=fpv4-sp-d16 --sysroot= \
+# RUN:   | FileCheck --check-prefix=CHECK-NO-MATCH %s
+# CHECK-NO-MATCH: error: no multilib found matching flags:
+# CHECK-NO-MATCH-SAME: --target=thumbv7em-none-unknown-eabi
+# CHECK-NO-MATCH: note: available multilibs are:
+# CHECK-NO-MATCH: --target=thumbv6m-none-unknown-eabi -mfpu=none
+# CHECK-NO-MATCH: --target=thumbv7m-none-unknown-eabi -mfpu=none
+# CHECK-NO-MATCH: --target=thumbv7em-none-unknown-eabi -mfpu=none
+
 # RUN: %T/baremetal_multilib/bin/clang -no-canonical-prefi

[PATCH] D153430: Warn on invalid Arm or AArch64 baremetal target triple

[David Spickett via Phabricator via cfe-commits]

DavidSpickett added a comment.

Please tag the commit title with the subproject, `[clang]` in this case. If 
only to help your friendly neighborhood buildbot minder.

I'd maybe go with "Did you mean" instead of "try" but only because the first 
thing I think is well if I try it what will I get. Then again we're not going 
to fit an explanation of Arm triples into a warning message. I know elsewhere 
we already have "did you mean" but if "try" is already used too it's fine as is.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153430

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

[PATCH] D153510: [Clang] Check type support for local variable declaration

[Yueh-Ting (eop) Chen via Phabricator via cfe-commits]

eopXD created this revision.
eopXD added reviewers: craig.topper, aaron.ballman.
Herald added subscribers: luke, frasercrmck, luismarques, apazos, 
sameer.abuasal, s.egerton, Jim, jocewei, PkmX, the_o, brucehoult, 
MartinMosbeck, rogfer01, edward-jones, zzheng, jrtc27, niosHD, sabuasal, 
simoncook, johnrusso, rbar, asb.
Herald added a project: All.
eopXD requested review of this revision.
Herald added subscribers: cfe-commits, wangpc.
Herald added a project: clang.

The initial intention here is to guard local variable declarations for
RVV types, taking a step back we can reuse checkTypeSupport to avoid
code duplication.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D153510

Files:
  clang/lib/Sema/SemaDecl.cpp
  clang/test/Sema/riscv-types.c
  clang/test/Sema/riscv-vector-float16-check.c
  clang/test/Sema/riscv-vector-float32-check.c
  clang/test/Sema/riscv-vector-float64-check.c
  clang/test/Sema/riscv-vector-int64-check.c


Index: clang/test/Sema/riscv-vector-int64-check.c
===
--- clang/test/Sema/riscv-vector-int64-check.c
+++ clang/test/Sema/riscv-vector-int64-check.c
@@ -6,3 +6,7 @@
 
 vint64m1_t foo() { /* expected-error {{RISC-V type 'vint64m1_t' (aka 
'__rvv_int64m1_t') requires the 'zve64x' extension}} */
 } /* expected-warning {{non-void function does not return a value}}*/
+
+void bar(void) {
+  vint64m1_t i64m1; /* expected-error {{RISC-V type 'vint64m1_t' (aka 
'__rvv_int64m1_t') requires the 'zve64x' extension}} */
+}
Index: clang/test/Sema/riscv-vector-float64-check.c
===
--- clang/test/Sema/riscv-vector-float64-check.c
+++ clang/test/Sema/riscv-vector-float64-check.c
@@ -6,3 +6,7 @@
 
 vfloat64m1_t foo() { /* expected-error {{RISC-V type 'vfloat64m1_t' (aka 
'__rvv_float64m1_t') requires the 'zve64d' extension}} */
 } /* expected-warning {{non-void function does not return a value}}*/
+
+void bar(void) {
+  vfloat64m1_t f64m1; /* expected-error {{RISC-V type 'vfloat64m1_t' (aka 
'__rvv_float64m1_t') requires the 'zve64d' extension}} */
+}
Index: clang/test/Sema/riscv-vector-float32-check.c
===
--- clang/test/Sema/riscv-vector-float32-check.c
+++ clang/test/Sema/riscv-vector-float32-check.c
@@ -6,3 +6,7 @@
 
 vfloat32m1_t foo() { /* expected-error {{RISC-V type 'vfloat32m1_t' (aka 
'__rvv_float32m1_t') requires the 'zve32f' extension}} */
 } /* expected-warning {{non-void function does not return a value}}*/
+
+void bar(void) {
+  vfloat32m1_t f32m1; /* expected-error {{RISC-V type 'vfloat32m1_t' (aka 
'__rvv_float32m1_t') requires the 'zve32f' extension}} */
+}
Index: clang/test/Sema/riscv-vector-float16-check.c
===
--- clang/test/Sema/riscv-vector-float16-check.c
+++ clang/test/Sema/riscv-vector-float16-check.c
@@ -6,3 +6,7 @@
 
 vfloat16m1_t foo() { /* expected-error {{RISC-V type 'vfloat16m1_t' (aka 
'__rvv_float16m1_t') requires the 'zvfh' extension}} */
 } /* expected-warning {{non-void function does not return a value}}*/
+
+void bar(void) {
+  vfloat16m1_t f16m1; /* expected-error {{RISC-V type 'vfloat16m1_t' (aka 
'__rvv_float16m1_t') requires the 'zvfh' extension}} */
+}
Index: clang/test/Sema/riscv-types.c
===
--- clang/test/Sema/riscv-types.c
+++ clang/test/Sema/riscv-types.c
@@ -1,5 +1,5 @@
-// RUN: %clang_cc1 -triple riscv64 -target-feature +v -ast-print %s \
-// RUN:| FileCheck %s
+// RUN: %clang_cc1 -triple riscv64 -target-feature +v \
+// RUN: -target-feature +experimental-zvfh -ast-print %s | FileCheck %s
 
 void bar(void) {
   // CHECK: __rvv_int64m1_t x0;
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -8769,6 +8769,8 @@
   return;
 }
   }
+
+  checkTypeSupport(T, NewVD->getLocation(), cast(CurContext));
 }
 
 /// Perform semantic checking on a newly-created variable


Index: clang/test/Sema/riscv-vector-int64-check.c
===
--- clang/test/Sema/riscv-vector-int64-check.c
+++ clang/test/Sema/riscv-vector-int64-check.c
@@ -6,3 +6,7 @@
 
 vint64m1_t foo() { /* expected-error {{RISC-V type 'vint64m1_t' (aka '__rvv_int64m1_t') requires the 'zve64x' extension}} */
 } /* expected-warning {{non-void function does not return a value}}*/
+
+void bar(void) {
+  vint64m1_t i64m1; /* expected-error {{RISC-V type 'vint64m1_t' (aka '__rvv_int64m1_t') requires the 'zve64x' extension}} */
+}
Index: clang/test/Sema/riscv-vector-float64-check.c
===
--- clang/test/Sema/riscv-vector-float64-check.c
+++ clang/test/Sema/riscv-vector-float64-check.c
@@ -6,3 +6,7 @@
 
 vfloat64m1_t foo() { /* expected-error {

[PATCH] D153424: [clang][ASTImporter] Add import of CXXRewrittenBinaryOperator.

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

balazske added inline comments.



Comment at: 
clang/test/ASTMerge/cxx-rewritten-binary-operator/Inputs/std-compare.h:307
+
+#endif // STD_COMPARE_H

I do not like to add this file but could not find a better solution. The file 
is copied from other test, this file has already multiple copies in the tests.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153424

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

[clang-tools-extra] 3889c82 - [clang-tidy][NFC] Add missing argument comment to LexerUtils.cpp

[Piotr Zegar via cfe-commits]

Author: Piotr Zegar
Date: 2023-06-22T09:12:40Z
New Revision: 3889c8214d1b4fcaa54f18b0944faa026f97b8ba

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

LOG: [clang-tidy][NFC] Add missing argument comment to LexerUtils.cpp

D148697 post commit review change.

Added: 


Modified: 
clang-tools-extra/clang-tidy/utils/LexerUtils.cpp

Removed: 




diff  --git a/clang-tools-extra/clang-tidy/utils/LexerUtils.cpp 
b/clang-tools-extra/clang-tidy/utils/LexerUtils.cpp
index 218cf2f08a20d..95e0255b37fd6 100644
--- a/clang-tools-extra/clang-tidy/utils/LexerUtils.cpp
+++ b/clang-tools-extra/clang-tidy/utils/LexerUtils.cpp
@@ -269,8 +269,9 @@ SourceLocation getLocationForNoexceptSpecifier(const 
FunctionDecl *FuncDecl,
   const SourceLocation NoexceptLoc =
   FuncDecl->getParamDecl(FuncDecl->getNumParams() - 1)->getEndLoc();
   if (NoexceptLoc.isValid())
-return Lexer::findLocationAfterToken(NoexceptLoc, tok::r_paren, SM,
- LangOpts, true);
+return Lexer::findLocationAfterToken(
+NoexceptLoc, tok::r_paren, SM, LangOpts,
+/*SkipTrailingWhitespaceAndNewLine=*/true);
 
   return {};
 }



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

[PATCH] D153430: Warn on invalid Arm or AArch64 baremetal target triple

[Peter Smith via Phabricator via cfe-commits]

peter.smith added a comment.

I can confirm that we have seen several users of the LLVM Embedded Toolchain 
for Arm that work on both AArch64 and Arm make this mistake as it is easy to 
just alter an example triple by substituting the first element.

Given that this is a warning, invalid is perhaps a bit strong.

Perhaps "Unrecognized  for , did you mean 
--"


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153430

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

[PATCH] D153424: [clang][ASTImporter] Add import of CXXRewrittenBinaryOperator.

[Donát Nagy via Phabricator via cfe-commits]

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

LGTM, this is a straightforward fix and if the repo can survive three copies of 
std-compare.h, then it'll also survive four copies.

However I created a ticket (in our internal system) to refactor the handling of 
std-compare.h and eliminate its duplication. It'll be a good "do this when you 
are waiting for something else" task for somebody.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153424

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

[PATCH] D152788: [Clang] Show type in enum out of range diagnostic

[Dimitry Andric via Phabricator via cfe-commits]

dim added a comment.

In D152788#4439714 , @shafik wrote:

> Thank you for this improvement!

Well, it would still be nice to have the instantiation trace, as Aaron 
suggested. So that is probably one of those "exercise for the reader" things. :D


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D152788

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

[PATCH] D152879: [RISCV] Model vxrm control for vsmul, vssra, vssrl, vnclip, and vnclipu

[Jan Wassenberg via Phabricator via cfe-commits]

jan-wassenberg added a comment.

Is there a way to detect whether the compiler already includes this change, 
preferably via preprocessor?
I tried `#ifdef __RISCV_VXRM_RDN` and `#if __has_builtin(__RISCV_VXRM_RDN)`.

This is a breaking change for us. Updating code to the new required signature 
fails to compile on the older toolchain (which is still in use). Leaving the 
code in the old style (no extra VXRM argument) is also not an option because 
other users have already updated their LLVM.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D152879

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

[PATCH] D149716: clang: Use new frexp intrinsic for builtins and add f16 version

[Matt Arsenault via Phabricator via cfe-commits]

arsenm added a comment.

ping


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

https://reviews.llvm.org/D149716

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

[PATCH] D152879: [RISCV] Model vxrm control for vsmul, vssra, vssrl, vnclip, and vnclipu

[Yueh-Ting (eop) Chen via Phabricator via cfe-commits]

eopXD added a comment.

In D152879#4440356 , @jan-wassenberg 
wrote:

> Is there a way to detect whether the compiler already includes this change, 
> preferably via preprocessor?
> I tried `#ifdef __RISCV_VXRM_RDN` and `#if __has_builtin(__RISCV_VXRM_RDN)`.
>
> This is a breaking change for us. Updating code to the new required signature 
> fails to compile on the older toolchain (which is still in use). Leaving the 
> code in the old style (no extra VXRM argument) is also not an option because 
> other users have already updated their LLVM.

Hi Jan,

Thanks for checking. I was planning to bump the version number of the RVV 
intrinsics [0] in the next LLVM release for users to identify what version of 
intrinsics they are using. My fault for not being aware that projects may be 
using the trunk upstream compiler.

Temporarily, I can add an indicator for users to identify this breaking change, 
however the new LLVM branch out is coming on July 4th, so I personally think we 
should just bump the version number for the next LLVM release.

If this is a really urgent issue, lets discuss more.

[0] 
https://github.com/llvm/llvm-project/blob/main/clang/lib/Basic/Targets/RISCV.cpp#L200


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D152879

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

[PATCH] D153418: Adding iconv support to CharSetConverter class

[Corentin Jabot via Phabricator via cfe-commits]

cor3ntin added a comment.

In D153418#4438766 , @efriedma wrote:

> This doesn't really address the concerns from 
> https://discourse.llvm.org/t/rfc-adding-a-charset-converter-to-the-llvm-support-library/69795/17
>  about consistency.  It's bad if different hosts support a different set of 
> charsets/charset names, and it's really bad if a given charset name has 
> different meanings on different hosts.

I agree, in particular we know that the people most likely to use this feature 
are windows users, and iconv doesn't do anything for them.

> Can we use the existing conversion utilities in LLVM for UTF-16/UTF-32?

Not sure how useful this would be, UTF-16/UTF-32 facilities are used directly 
when they are needed, and utf-16 source input files are rare.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153418

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

[PATCH] D153430: Warn on invalid Arm or AArch64 baremetal target triple

[David Spickett via Phabricator via cfe-commits]

DavidSpickett added a comment.

> Perhaps "Unrecognized environment  for , did you mean 
> -none-"

I like explaining it like this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153430

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

[PATCH] D129635: [OpenMP] Update the default version of OpenMP to 5.1

[Animesh Kumar via Phabricator via cfe-commits]

animeshk-amd added a comment.

In D129635#4438970 , @h-vetinari 
wrote:

> Does https://clang.llvm.org/docs/OpenMPSupport.html need an update? It still 
> says "Clang fully supports OpenMP 4.5" (with many 5.0/5.1 features marked as 
> "worked on" / "unclaimed"), which would make it unusual to put the default on 
> a version that's (according to that status page) only ~30% implemented.

In the multi-company community meeting, the agreement was to move to the 5.1 
version assuming that these features are supported.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129635

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

[PATCH] D153236: [NFC] Fix potential dereferencing of nullptr.

[Aaron Ballman via Phabricator via cfe-commits]

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

LGTM!


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

https://reviews.llvm.org/D153236

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

[PATCH] D152946: [C++20][Modules] Implement P2615R1 revised export diagnostics.

[Iain Sandoe via Phabricator via cfe-commits]

iains updated this revision to Diff 533554.
iains added a comment.

rebased, addressed review comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D152946

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaModule.cpp
  clang/test/CXX/module/module.interface/p3.cpp
  clang/test/Modules/cxx20-10-2-ex1.cpp
  clang/test/Modules/cxx20-10-2-ex7.cpp
  clang/test/SemaCXX/modules.cppm

Index: clang/test/SemaCXX/modules.cppm
===
--- clang/test/SemaCXX/modules.cppm
+++ clang/test/SemaCXX/modules.cppm
@@ -34,11 +34,11 @@
 import foo; // expected-error {{imports must immediately follow the module declaration}}
 
 export {}
-export {  // expected-note {{begins here}}
-  ;   // expected-warning {{ISO C++20 does not permit an empty declaration to appear in an export block}}
+export {
+  ;   // No diagnostic after P2615R1 DR
 }
-export {   // expected-note {{begins here}}
-  static_assert(true); // expected-warning {{ISO C++20 does not permit a static_assert declaration to appear in an export block}}
+export {
+  static_assert(true); // No diagnostic after P2615R1 DR
 }
 
 int use_b = b; // expected-error{{use of undeclared identifier 'b'}}
Index: clang/test/Modules/cxx20-10-2-ex7.cpp
===
--- clang/test/Modules/cxx20-10-2-ex7.cpp
+++ clang/test/Modules/cxx20-10-2-ex7.cpp
@@ -2,8 +2,10 @@
 
 // RUN: %clang_cc1 -std=c++20 -emit-module-interface %s -verify -o %t
 
+// expected-no-diagnostics
+
 export module M;
 export namespace N {
 int x; // OK
-static_assert(1 == 1); // expected-error {{static_assert declaration cannot be exported}}
+static_assert(1 == 1); // No diagnostic after P2615R1 DR
 } // namespace N
Index: clang/test/Modules/cxx20-10-2-ex1.cpp
===
--- clang/test/Modules/cxx20-10-2-ex1.cpp
+++ clang/test/Modules/cxx20-10-2-ex1.cpp
@@ -17,9 +17,9 @@
 // expected-error@std-10-2-ex1.h:* {{export declaration can only be used within a module purview}}
 
 export module M1;
-export namespace {} // expected-error {{declaration does not introduce any names to be exported}}
-export namespace {
-int a1; // expected-error {{declaration of 'a1' with internal linkage cannot be exported}}
+export namespace {} // expected-error {{anonymous namespaces cannot be exported}}
+export namespace { // expected-error {{anonymous namespaces cannot be exported}}
+int a1;
 }
 namespace {// expected-note {{anonymous namespace begins here}}
 export int a2; // expected-error {{export declaration appears within anonymous namespace}}
@@ -28,4 +28,4 @@
 export int f();  // OK
 
 export namespace N {} // namespace N
-export using namespace N; // expected-error {{ISO C++20 does not permit using directive to be exported}}
+export using namespace N; // No diagnostic after P2615R1 DR
Index: clang/test/CXX/module/module.interface/p3.cpp
===
--- clang/test/CXX/module/module.interface/p3.cpp
+++ clang/test/CXX/module/module.interface/p3.cpp
@@ -1,18 +1,19 @@
-// RUN: %clang_cc1 -std=c++2a %s -verify -pedantic-errors
+// RUN: %clang_cc1 -std=c++20 %s -verify -pedantic-errors
 
+// As amended by P2615R1 applied as a DR against C++20.
 export module p3;
 
 namespace A { int ns_mem; } // expected-note 2{{target}}
 
 // An exported declaration shall declare at least one name.
-export; // expected-error {{empty declaration cannot be exported}}
-export static_assert(true); // expected-error {{static_assert declaration cannot be exported}}
-export using namespace A;   // expected-error {{ISO C++20 does not permit using directive to be exported}}
+export; // No diagnostic after P2615R1 DR
+export static_assert(true); // No diagnostic after P2615R1 DR
+export using namespace A;   // No diagnostic after P2615R1 DR
 
-export { // expected-note 3{{export block begins here}}
-  ; // expected-error {{ISO C++20 does not permit an empty declaration to appear in an export block}}
-  static_assert(true); // expected-error {{ISO C++20 does not permit a static_assert declaration to appear in an export block}}
-  using namespace A;   // expected-error {{ISO C++20 does not permit using directive to be exported}}
+export { // No diagnostic after P2615R1 DR
+  ; // No diagnostic after P2615R1 DR
+  static_assert(true); // No diagnostic after P2615R1 DR
+  using namespace A;   // No diagnostic after P2615R1 DR
 }
 
 export struct {}; // expected-error {{must be class member}} expected-error {{GNU extension}} expected-error {{does not declare anything}}
@@ -24,27 +25,28 @@
 export enum E : int;
 export typedef int; // expected-error {{typedef requires a name}}
 export static union {}; // expected-error {{does not declare anything}}
-export asm(""); // expected-error {{

[PATCH] D152946: [C++20][Modules] Implement P2615R1 revised export diagnostics.

[Iain Sandoe via Phabricator via cfe-commits]

iains marked 4 inline comments as done.
iains added a comment.

not sure why the debian CI is reported clang-format errors; I am not seeing 
them here.




Comment at: clang/lib/Sema/SemaModule.cpp:824-827
+  bool AllUnnamed = true;
+  for (auto *D : DC->decls())
+AllUnnamed &= checkExportedDecl(S, D, BlockStart);
+  return AllUnnamed;

ChuanqiXu wrote:
> 
(actually I just moved this code to place it closer to the use-point).

you change is more efficient, indeed, but it alters the behaviour of the 
diagnostics such that only the first occurrence is reported (which regresses 
module.interface/p5.cpp).

It seems to me to be more user-friendly to report all the errors at the same 
time rather than one by one.




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D152946

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

[PATCH] D153267: [clang][Diagnostics] Provide parameter source range to arity-mismatch notes

[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 modulo Chris' comment, but can you please add a release note for the fix?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153267

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

[PATCH] D152879: [RISCV] Model vxrm control for vsmul, vssra, vssrl, vnclip, and vnclipu

[Jan Wassenberg via Phabricator via cfe-commits]

jan-wassenberg added a comment.

Thanks for your quick reply. Yes, we are tracking trunk with a short lag, and 
unfortunately this is mostly beyond our control.
Now that I have updated the Highway code and toolchain reference in user code, 
we are fine for the moment.
Please do update the intrinsics version number when there is a breaking change, 
though :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D152879

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

[PATCH] D153510: [Clang] Check type support for local variable declaration

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

This checking already happens when the declaration is actually *used*, so I 
question whether we need to do the check at all (declared but unused variables 
seem like an edge case to me): https://godbolt.org/z/e4Y8qKMrW

What is the behavior of the example I linked with your patch? Do we now issue 
the diagnostic twice (once on the declaration and again on the use)?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153510

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

[PATCH] D153430: Warn on invalid Arm or AArch64 baremetal target triple

[Michael Platings via Phabricator via cfe-commits]

michaelplatings updated this revision to Diff 533566.
michaelplatings added a comment.

Apply @DavidSpickett's suggestions.

@peter.smith since the warning is only emitted in specific cases that we can be 
say with a high degree of confidence are incorrect I think it's accurate to say 
"invalid". I think it would be inaccurate to say "unrecognized" since the code 
specifically does recognise the elf and eabi* environments. Also the word 
invalid corresponds with the warning type (-Winvalid-command-line-argument). I 
thought about changing the wording to "invalid environment in target triple 
'...'" but I suspect most people wouldn't know that elf and eabi are 
"environments" and therefore the simpler message would be preferable. What do 
you think?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153430

Files:
  clang/include/clang/Basic/DiagnosticCommonKinds.td
  clang/lib/Driver/Driver.cpp
  clang/test/CodeGen/aapcs64-align.cpp
  clang/test/CodeGen/aarch64-sign-return-address.c
  clang/test/CodeGen/arm_acle.c
  clang/test/CodeGenCXX/float16-declarations.cpp
  clang/test/Driver/aarch64-cssc.c
  clang/test/Driver/aarch64-d128.c
  clang/test/Driver/aarch64-hbc.c
  clang/test/Driver/aarch64-ite.c
  clang/test/Driver/aarch64-lrcpc3.c
  clang/test/Driver/aarch64-ls64.c
  clang/test/Driver/aarch64-lse128.c
  clang/test/Driver/aarch64-mops.c
  clang/test/Driver/aarch64-mte.c
  clang/test/Driver/aarch64-perfmon.c
  clang/test/Driver/aarch64-predres.c
  clang/test/Driver/aarch64-rand.c
  clang/test/Driver/aarch64-ras.c
  clang/test/Driver/aarch64-rdm.c
  clang/test/Driver/aarch64-ssbs.c
  clang/test/Driver/aarch64-the.c
  clang/test/Driver/arm-matrix-multiply.c
  clang/test/Driver/arm-sb.c
  clang/test/Driver/constructors.c
  clang/test/Driver/unsupported-target-arch.c
  clang/test/Frontend/gnu-mcount.c
  clang/test/Headers/arm-fp16-header.c
  clang/test/Headers/arm-neon-header.c
  clang/test/Preprocessor/aarch64-target-features.c
  llvm/test/CodeGen/AArch64/andcompare.ll
  llvm/test/CodeGen/AArch64/andorbrcompare.ll
  llvm/test/CodeGen/AArch64/blockaddress.ll
  llvm/test/CodeGen/AArch64/extern-weak.ll
  llvm/test/CodeGen/AArch64/init-array.ll
  llvm/test/CodeGen/AArch64/literal_pools_float.ll
  llvm/test/CodeGen/AArch64/neg-selects.ll
  llvm/test/CodeGen/AArch64/qmovn.ll
  llvm/test/CodeGen/AArch64/select-constant-xor.ll
  llvm/test/MC/AArch64/armv8.9a-clrbhb.s

Index: llvm/test/MC/AArch64/armv8.9a-clrbhb.s
===
--- llvm/test/MC/AArch64/armv8.9a-clrbhb.s
+++ llvm/test/MC/AArch64/armv8.9a-clrbhb.s
@@ -2,37 +2,37 @@
 // Assembly is always permitted for instructions in the hint space.
 
 // Optional, off by default
-// RUN: llvm-mc -show-encoding -triple aarch64-none-none-eabi < %s | FileCheck %s --check-prefix=HINT_22
-// RUN: llvm-mc -show-encoding -triple aarch64-none-none-eabi -mattr=+v8a < %s | FileCheck %s --check-prefix=HINT_22
-// RUN: llvm-mc -show-encoding -triple aarch64-none-none-eabi -mattr=+v8.8a < %s | FileCheck %s --check-prefix=HINT_22
-// RUN: llvm-mc -show-encoding -triple aarch64-none-none-eabi -mattr=+v9a < %s | FileCheck %s --check-prefix=HINT_22
-// RUN: llvm-mc -show-encoding -triple aarch64-none-none-eabi -mattr=+v9.3a < %s | FileCheck %s --check-prefix=HINT_22
+// RUN: llvm-mc -show-encoding -triple aarch64-none-elf < %s | FileCheck %s --check-prefix=HINT_22
+// RUN: llvm-mc -show-encoding -triple aarch64-none-elf -mattr=+v8a < %s | FileCheck %s --check-prefix=HINT_22
+// RUN: llvm-mc -show-encoding -triple aarch64-none-elf -mattr=+v8.8a < %s | FileCheck %s --check-prefix=HINT_22
+// RUN: llvm-mc -show-encoding -triple aarch64-none-elf -mattr=+v9a < %s | FileCheck %s --check-prefix=HINT_22
+// RUN: llvm-mc -show-encoding -triple aarch64-none-elf -mattr=+v9.3a < %s | FileCheck %s --check-prefix=HINT_22
 
 // Optional, off by default, doubly disabled
-// RUN: llvm-mc -show-encoding -triple aarch64-none-none-eabi -mattr=-clrbhb < %s | FileCheck %s --check-prefix=HINT_22
-// RUN: llvm-mc -show-encoding -triple aarch64-none-none-eabi -mattr=+v8a,-clrbhb < %s | FileCheck %s --check-prefix=HINT_22
-// RUN: llvm-mc -show-encoding -triple aarch64-none-none-eabi -mattr=+v8.8a,-clrbhb < %s | FileCheck %s --check-prefix=HINT_22
-// RUN: llvm-mc -show-encoding -triple aarch64-none-none-eabi -mattr=+v9a,-clrbhb < %s | FileCheck %s --check-prefix=HINT_22
-// RUN: llvm-mc -show-encoding -triple aarch64-none-none-eabi -mattr=+v9.3a,-clrbhb < %s | FileCheck %s --check-prefix=HINT_22
+// RUN: llvm-mc -show-encoding -triple aarch64-none-elf -mattr=-clrbhb < %s | FileCheck %s --check-prefix=HINT_22
+// RUN: llvm-mc -show-encoding -triple aarch64-none-elf -mattr=+v8a,-clrbhb < %s | FileCheck %s --check-prefix=HINT_22
+// RUN: llvm-mc -show-encoding -triple aarch64-none-elf -mattr=+v8.8a,-clrbhb < %s | FileCheck %s --check-prefix=HINT_22
+// RUN: llvm-mc -show-encodi

[PATCH] D153536: [Clang] Implement P2169 A nice placeholder with no name

[Corentin Jabot via Phabricator via cfe-commits]

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

This is a C++ feature that allows the use of `_` to
declare multiple variable of that name in the same scope;
these variables can then not be refered to.

In addition, while P2169  does not extend to 
parameter \
declarations, we stop warning on unused parameters of that name,
for consistency.

The feature is backported to all C++ language modes.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D153536

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/AST/Decl.h
  clang/include/clang/AST/DeclBase.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/IdentifierTable.h
  clang/include/clang/Sema/Lookup.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/Decl.cpp
  clang/lib/Frontend/InitPreprocessor.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaLambda.cpp
  clang/lib/Sema/SemaLookup.cpp
  clang/test/Lexer/cxx-features.cpp
  clang/test/Lexer/unicode.c
  clang/test/SemaCXX/cxx2c-placeholder-vars.cpp
  clang/www/cxx_status.html

Index: clang/www/cxx_status.html
===
--- clang/www/cxx_status.html
+++ clang/www/cxx_status.html
@@ -145,7 +145,7 @@
  
   Placeholder variables with no name
   https://wg21.link/P2169R4";>P2169R4
-  No
+  Clang 17
  
 
 
Index: clang/test/SemaCXX/cxx2c-placeholder-vars.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/cxx2c-placeholder-vars.cpp
@@ -0,0 +1,98 @@
+// RUN: %clang -cc1 -fsyntax-only -verify -std=c++2c -Wunused-parameter -Wunused %s
+
+void static_var() {
+static int _; // expected-note {{previous definition is here}} \
+  // expected-note {{candidate}}
+static int _; // expected-error {{redefinition of '_'}}
+int _;// expected-warning {{placeholder variables are a C++2c extension}} \
+  // expected-note {{candidate}}
+_++; // expected-error{{reference to '_' is ambiguous}}
+}
+
+void static_var_2() {
+int _; // expected-note {{previous definition is here}}
+static int _; // expected-error {{redefinition of '_'}}
+}
+
+void bindings() {
+int arr[4] = {0, 1, 2, 3};
+auto [_, _, _, _] = arr; // expected-warning 3{{placeholder variables are a C++2c extension}} \
+ // expected-note 4{{placeholder declared here}}
+_ == 42; // expected-error {{referring to placeholder '_' is not allowed}}
+{
+auto [_, a, b, c] = arr;
+auto [_, _, _, _] = arr; // expected-warning 4{{placeholder variables are a C++2c extension}}
+}
+}
+
+void lambda() {
+(void)[_ = 0, _ = 1] { // expected-warning {{placeholder variables are a C++2c extension}} \
+   // expected-note 4{{placeholder declared here}} \\
+   // expected-warning 2{{placeholder variable has no side effect}}
+(void)_++; // expected-error {{referring to placeholder '_' is not allowed}}
+};
+}
+
+namespace global_var {
+int _; // expected-note {{previous definition is here}}
+int _; // expected-error {{redefinition of '_'}}
+}
+
+namespace global_fun {
+void _();
+void _();
+
+void _() {} // expected-note {{previous definition is here}}
+void _() {} // expected-error {{redefinition of '_'}}
+void _(int){};
+}
+
+void extern_test() {
+extern int _;
+extern int _; // expected-note {{candidate}}
+int _; //expected-note {{candidate}}
+_++; // expected-error {{reference to '_' is ambiguous}}
+}
+
+
+struct Members {
+int _; // expected-note {{placeholder declared here}}
+int _; // expected-warning{{placeholder variables are a C++2c extension}} \
+   // expected-note {{placeholder declared here}}
+void f() {
+_++; // expected-error {{referring to placeholder '_' is not allowed}}
+}
+};
+
+namespace using_ {
+int _; // expected-note {{target of using declaration}}
+void f() {
+int _; // expected-note {{conflicting declaration}}
+_ = 0;
+using using_::_; // expected-error {{target of using declaration conflicts with declaration already in scope}}
+}
+}
+
+
+void call(int);
+void test_param(int _) {}
+void test_params(int _, int _); // expected-error {{redefinition of parameter '_'}} \
+// expected-note {{previous declaration is here}}
+
+template  // expected-error {{declaration of '_' shadows template parameter}} \
+  // expected-note  {{template parameter is declared here}}
+auto i = 0;
+
+template 
+concept C = requires(T _, T _) {  // expected-error {{redefinition of parameter '_'}} \
+// expected-note {{previous declaration is here}}
+T{};
+};
+
+struct S {
+int a;
+};
+
+voi

[PATCH] D150803: Add a new `wasm_custom` clang attribute for marking functions.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/include/clang/Basic/AttrDocs.td:5608-5612
+Clang supports the ``__attribute__((wasm_async))``
+attribute for the WebAssembly target. This attribute may be attached to a
+function definition, which indicates the function will be used with JavaScript
+promise integration (JSPI). The attribute will cause the creation of a custom
+section named "async" that contains each wasm_async function's index value.

brendandahl wrote:
> aaron.ballman wrote:
> > aaron.ballman wrote:
> > > This could be my ignorance of web assembly showing, but the docs don't 
> > > really help me understand when you'd want to use this attribute. Perhaps 
> > > a link to what JSPI is and a code example would help a little bit? Or is 
> > > this more of a low-level implementation detail kind of attribute where 
> > > folks already know the domain?
> > Based on the documentation here, I'm wondering why the `annotate` attribute 
> > doesn't suffice? That attribute lets you specify custom information to 
> > associate with a declaration that then gets lowered such that passes can do 
> > whatever they want with the info, which seems to be a more generalized 
> > version of what this attribute is.
> > 
> > (FWIW, I'm back to having basically no idea when you'd use this attribute 
> > or what it would be used for, so my thoughts above might make no sense.)
> I was considering that, but it would require more machinery in the wasm 
> backend to store all the attribute values in the output. For now we only 
> really need a flag associated with function. I think if we find more uses for 
> the annotations in the future we could replace wasm_custom with it.
> I was considering that, but it would require more machinery in the wasm 
> backend to store all the attribute values in the output. For now we only 
> really need a flag associated with function. I think if we find more uses for 
> the annotations in the future we could replace wasm_custom with it.

More machinery in the backend is preferred to exposing a new attribute that is 
this general-purpose; the backend is what needs this functionality, the 
frontend basically does nothing with it. (I'm assuming this is an 
implementation detail attribute and not something you expect users to write. If 
I'm wrong about that, please let me know.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D150803

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

[PATCH] D150803: Add a new `wasm_custom` clang attribute for marking functions.

[Aaron Ballman via Phabricator via cfe-commits]

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

Marking as requested changes so it's clear there's more worth discussing, so we 
don't accidentally land this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D150803

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

[PATCH] D153296: [AST] Stop evaluate constant expression if the condition expression which in switch statement contains errors

[Erich Keane via Phabricator via cfe-commits]

erichkeane added inline comments.



Comment at: clang/lib/AST/ExprConstant.cpp:4988
+  if (SS->getCond()->containsErrors() ||
+  !EvaluateDependentExpr(SS->getCond(), Info))
 return ESR_Failed;

It seems to me that the 'better' solution is to make EvaluateDependentExpr (or 
one of its children) be RecoveryExpr aware, and result in a failed value 
instead.  That way we get this 'fix' for more than just switch statements.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153296

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

[clang-tools-extra] e339b07 - [include-cleaner] No need to overwrite the source file if there is no

[Haojian Wu via cfe-commits]

Author: Haojian Wu
Date: 2023-06-22T14:37:11+02:00
New Revision: e339b07944799ebd1692e8f7019690fe14a33257

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

LOG: [include-cleaner] No need to overwrite the source file if there is no
cleanups

Added: 


Modified: 
clang-tools-extra/include-cleaner/tool/IncludeCleaner.cpp

Removed: 




diff  --git a/clang-tools-extra/include-cleaner/tool/IncludeCleaner.cpp 
b/clang-tools-extra/include-cleaner/tool/IncludeCleaner.cpp
index 008da47164092..574023fda4968 100644
--- a/clang-tools-extra/include-cleaner/tool/IncludeCleaner.cpp
+++ b/clang-tools-extra/include-cleaner/tool/IncludeCleaner.cpp
@@ -148,7 +148,7 @@ class Action : public clang::ASTFrontendAction {
   }
 }
 
-if (Edit) {
+if (Edit && (!Results.Missing.empty() || !Results.Unused.empty())) {
   if (auto Err = llvm::writeToOutput(
   Path, [&](llvm::raw_ostream &OS) -> llvm::Error {
 OS << Final;



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

[PATCH] D152900: [clangd] Update symbol collector to use include-cleaner.

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet added inline comments.



Comment at: clang-tools-extra/clangd/ParsedAST.cpp:628
 CanonIncludes.addSystemHeadersMapping(Clang->getLangOpts());
-  std::unique_ptr IWYUHandler =
-  collectIWYUHeaderMaps(&CanonIncludes);

can you also add a FIXME here saying that we should attach PragmaInclude 
callbacks to main file ast build too?

this is not a recent regression as we were not doing it properly in previous 
version either. IWYU handler we attach only cares about private pragmas, which 
don't mean much inside the main file. but we actually need it for other pragmas 
like keep/export/no_include etc. (no need to do it in this patch as it's 
already getting quite big, let's do that as a follow up)



Comment at: clang-tools-extra/clangd/Preamble.h:83
 
-using PreambleParsedCallback = std::function;
+using PreambleParsedCallback =
+std::function FullPathMapping;
   /// A map from a suffix (one or components of a path) to a canonical path.

you can drop this one too, only `addMapping` would introduce mappings here, but 
that's going away too.



Comment at: clang-tools-extra/clangd/index/SymbolCollector.cpp:250
+  // of whether it's an otherwise-good header (header guards etc).
+  llvm::StringRef mapCanonical(FileID FID) {
+if (SysHeaderMapping) {

let's change the interface here to take in a `FileEntry` instead.



Comment at: clang-tools-extra/clangd/index/SymbolCollector.cpp:251
+  llvm::StringRef mapCanonical(FileID FID) {
+if (SysHeaderMapping) {
+  llvm::StringRef Canonical =

nit: early exits

```
if (!SysHeaderMapping)
  return "";
auto Canonical = ...;
if(Canonical.empty())
  return "";
...
```



Comment at: clang-tools-extra/clangd/index/SymbolCollector.cpp:258
+  return Canonical;
+return toURI(Canonical);
+  }

we should never hit this code path anymore. so feel free to convert the `if` 
above to an `assert`



Comment at: clang-tools-extra/clangd/index/SymbolCollector.cpp:412-413
+
+if (auto Verbatim = PI->getPublic(FileEntry); !Verbatim.empty())
+  return Verbatim;
+

let's move this logic into `mapCanonical` too.



Comment at: clang-tools-extra/clangd/index/SymbolCollector.cpp:415
+
+auto Canonical = mapCanonical(FID);
+if (!Canonical.empty())

nit: `if (auto Canonical = ...; !Canonical.empty()) return Canonical;`



Comment at: clang-tools-extra/clangd/index/SymbolCollector.cpp:846
+void SymbolCollector::setSymbolProviders(
+const Symbol &S, const llvm::SmallVector Headers) 
{
+  if (Opts.CollectIncludePath &&

what about merging this one and `setIncludeLocation` ?

e.g:
```
void SymbolCollector::setIncludeLocation(const Symbol &IdxS, SourceLocation 
DefLoc, const include_cleaner::Symbol &Sym) {
if (!Opts.CollectIncludePath ||
  shouldCollectIncludePath(S.SymInfo.Kind) == Symbol::Invalid)
  return;
IncludeFiles[SID] = ...;
SymbolProviders[SID] = headersForSymbol(...);
}
```



Comment at: clang-tools-extra/clangd/index/SymbolCollector.cpp:849
+  shouldCollectIncludePath(S.SymInfo.Kind) != Symbol::Invalid)
+SymbolProviders[S.ID] = std::move(Headers);
+}

because you're taking in `Headers` as `const`, this move is not actually moving.



Comment at: clang-tools-extra/clangd/index/SymbolCollector.cpp:877
   // We delay this until end of TU so header guards are all resolved.
   for (const auto &[SID, FID] : IncludeFiles) {
 if (const Symbol *S = Symbols.find(SID)) {

let's iterate over `SymbolProviders` instead, as `IncludeFiles` is a legacy 
struct now.



Comment at: clang-tools-extra/clangd/index/SymbolCollector.cpp:878
   for (const auto &[SID, FID] : IncludeFiles) {
 if (const Symbol *S = Symbols.find(SID)) {
+  // Determine if the FID is #include'd or #import'ed.

inside of this branch is getting crowded, maybe early exit instead?
```
const Symbol *S = Symbols.find(SID);
if(!S) continue;
...
```



Comment at: clang-tools-extra/clangd/index/SymbolCollector.cpp:908
+  {HeaderFileURIs->getIncludeHeader(FID), 1, Directives});
+Symbols.insert(NewSym);
+continue;

no need to call insert if we didn't modify `IncludeHeaders`, so maybe reflow to 
something like:
```
if (Directives & Import) {
  if(auto IncHeader = ..; !IncHeader.empty()) {
 auto NewSym = *S;
 NewSym.IncludeHeaders;
 Symbols.insert(NewSym);
  }
  // FIXME: Use providers from include-cleaner once it's polished for ObjC too.
  continue;
}
```



Comment at: clang-tools-extra/clangd/index/SymbolCollector.cpp:914
+  // library.
+  if (Directives == Symbol::Include) {
+auto It = SymbolProviders

[PATCH] D153430: [Clang][Driver] Warn on invalid Arm or AArch64 baremetal target triple

[Peter Smith via Phabricator via cfe-commits]

peter.smith added a comment.

My initial reactions to seeing Invalid target triple aarch64-none-eabi; try 
aarch64-none-elf [*] were:

- Why is it invalid?
- I assumed it was an error message, and was about to write a comment until I 
saw it was a warning.

[X] now did you mean (thanks for making that change).

An alternative suggestion:

   selects the fallback GCC toolchain driver; did you mean 


This isn't something I'm going to die on a hill for. Perhaps add some more 
reviewers to get some opinions, I'm happy to go with the consensus.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153430

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

[PATCH] D153542: [C++20][Modules] Implement P2615R1 exported specialization diagnostics.

[Iain Sandoe via Phabricator via cfe-commits]

iains created this revision.
Herald added a subscriber: ChuanqiXu.
Herald added a project: All.
iains added a reviewer: ChuanqiXu.
iains added subscribers: clang-modules, h-vetinari.
iains published this revision for review.
iains added a comment.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

I think it is a good idea to keep this part of P2615R1 separate from the 
unnamed exports diagnostics [the parent commit] - it seems likely that there 
will be more fallout from this (given that there were already PRs about the 
behaviour of exported specialisations).


P2615R1 introduces diagnostics for partial and explicit specializations in 
module export declarations. This is applied as a DR to C++20.

Two testcases are removed since they were testing behaviour of imported 
specialisations (which are no longer permitted as exports).
Three testcases are amended to remove exports of specialisations, but retain 
the remainder of the test.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D153542

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaModule.cpp
  clang/test/CXX/module/module.interface/p1-p2615r1.cpp
  clang/test/CXX/temp/temp.explicit/p2-p2615r1.cpp
  clang/test/Modules/merge-var-template-spec-cxx-modules.cppm
  clang/test/Modules/pr59780.cppm
  clang/test/Modules/pr60890.cppm
  clang/test/Modules/pr62796.cppm
  clang/test/Modules/template-function-specialization.cpp
  clang/unittests/Serialization/VarDeclConstantInitTest.cpp
  clang/www/cxx_status.html

Index: clang/www/cxx_status.html
===
--- clang/www/cxx_status.html
+++ clang/www/cxx_status.html
@@ -772,7 +772,7 @@
   

 https://wg21.link/P2615R1";>P2615R1 (DR)
-No
+Clang 17
   

 https://wg21.link/P2788R0";>P2788R0 (DR)
Index: clang/unittests/Serialization/VarDeclConstantInitTest.cpp
===
--- clang/unittests/Serialization/VarDeclConstantInitTest.cpp
+++ clang/unittests/Serialization/VarDeclConstantInitTest.cpp
@@ -86,7 +86,6 @@
 	template
 	constexpr unsigned long Cache = Compute(Number{}, Strategy{});
 
-  template constexpr unsigned long Cache<10ul>;
 }
   )cpp");
 
@@ -116,6 +115,7 @@
   std::unique_ptr AST = tooling::buildASTFromCodeWithArgs(
   R"cpp(
 import Fibonacci.Cache;
+template constexpr unsigned long Fibonacci::Cache<10ul>;
 )cpp",
   /*Args=*/{"-std=c++20", DepArg.c_str()});
 
Index: clang/test/Modules/template-function-specialization.cpp
===
--- clang/test/Modules/template-function-specialization.cpp
+++ clang/test/Modules/template-function-specialization.cpp
@@ -39,10 +39,6 @@
 void foo4() {
 }
 
-export template <>
-void foo4() {
-}
-
 //--- Use.cpp
 import foo;
 void use() {
Index: clang/test/Modules/pr62796.cppm
===
--- clang/test/Modules/pr62796.cppm
+++ clang/test/Modules/pr62796.cppm
@@ -38,8 +38,6 @@
 
 	template
 	constexpr unsigned long Cache = Compute(Number{}, Strategy{});
-
-template constexpr unsigned long Cache<10ul>;
 }
 
 //--- Use.cpp
Index: clang/test/Modules/pr60890.cppm
===
--- clang/test/Modules/pr60890.cppm
+++ clang/test/Modules/pr60890.cppm
@@ -18,8 +18,6 @@
 	void aaa() requires(true) {}
 };
 
-export template struct a;
-
 export template
 void foo(T) requires(true) {}
 
Index: clang/test/Modules/pr59780.cppm
===
--- clang/test/Modules/pr59780.cppm
+++ /dev/null
@@ -1,46 +0,0 @@
-// https://github.com/llvm/llvm-project/issues/59780
-//
-// RUN: rm -rf %t
-// RUN: mkdir %t
-// RUN: split-file %s %t
-//
-// RUN: %clang_cc1 -std=c++20 %t/a.cppm -triple %itanium_abi_triple -emit-module-interface -o %t/a.pcm
-// RUN: %clang_cc1 -std=c++20 %t/use.cpp -fprebuilt-module-path=%t -S \
-// RUN: -triple %itanium_abi_triple -emit-llvm -o - | FileCheck %t/use.cpp
-// RUN: %clang_cc1 -std=c++20 %t/a.pcm -triple %itanium_abi_triple -emit-llvm -o - | FileCheck %t/a.cppm
-
-//--- a.cppm
-export module a;
-
-export template
-int x = 0;
-
-export template<>
-int x = 0;
-
-export template
-struct Y {
-static int value;
-};
-
-template 
-int Y::value = 0;
-
-export template<>
-struct Y {
-static int value;
-};
-
-int Y::value = 0;
-
-// CHECK-NOT: @_ZW1a1xIiE = {{.*}}external{{.*}}global
-// CHECK-NOT: @_ZNW1a1YIiE5valueE = {{.*}}external{{.*}}global
-
-//--- use.cpp
-import a;
-int foo() {
-return x + Y::value;
-}
-
-// CHECK: @_ZW1a1xIiE = {{.*}}external{{.*}}global
-// CHECK: @_ZNW1a1YIiE5valueE = {{.*}}external{{.*}}global
Index: clang/test/Modules/merge-var-template-spec-cxx-modules.cppm
===
--- clang/test/Modules/merge-var-tem

[PATCH] D153493: [dataflow] avoid more accidental copies of Environment

[Sam McCall via Phabricator via cfe-commits]

sammccall added a comment.

BTW i thought this was just nice for debugging and saving copying a few maps, 
but Dmitri says that the way even trivial indirections like `(FC1 = FC2)`, 
`(FC2 = ...)` are expressed in the SAT solver means they can add significant 
cost there too...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153493

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

[PATCH] D153033: [CLANG]Fix potential null pointer dereference bugs

[Soumi Manna via Phabricator via cfe-commits]

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

ping @aaron.ballman


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

https://reviews.llvm.org/D153033

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

[PATCH] D153418: Adding iconv support to CharSetConverter class

[Abhina Sree via Phabricator via cfe-commits]

abhina.sreeskantharajan marked an inline comment as done.
abhina.sreeskantharajan added a comment.

Please correct me if I'm wrong, I'm not too familiar with icu4c, but I think 
adding support for ICU would be the better long-term solution since it seems to 
allow the same behaviour across different platforms. However, the issue on the 
z/OS platform is that there currently isn't support for this library so iconv 
seems to be the only solution we can use until we do get support. So would an 
alternative be to use iconv only on z/OS (and hopefully this is a temporary 
solution until icu is supported on z/OS) and use icu on all other platforms?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153418

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

[PATCH] D153462: [Headers][doc] Add various arith/logical intrinsic descriptions to avx2intrin.h

[Paul Robinson via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGbfa467bdc0e9: [Headers][doc] Add various arith/logical 
intrinsic descriptions to avx2intrin.h (authored by probinson).
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153462

Files:
  clang/lib/Headers/avx2intrin.h

Index: clang/lib/Headers/avx2intrin.h
===
--- clang/lib/Headers/avx2intrin.h
+++ clang/lib/Headers/avx2intrin.h
@@ -19,22 +19,112 @@
 #define __DEFAULT_FN_ATTRS128 __attribute__((__always_inline__, __nodebug__, __target__("avx2"), __min_vector_width__(128)))
 
 /* SSE4 Multiple Packed Sums of Absolute Difference.  */
+/// Computes sixteen sum of absolute difference (SAD) operations on sets of
+///four unsigned 8-bit integers from the 256-bit integer vectors \a X and
+///\a Y.
+///
+///Eight SAD results are computed using the lower half of the input
+///vectors, and another eight using the upper half. These 16-bit values
+///are returned in the lower and upper halves of the 256-bit result,
+///respectively.
+///
+///A single SAD operation selects four bytes from \a X and four bytes from
+///\a Y as input. It computes the differences between each \a X byte and
+///the corresponding \a Y byte, takes the absolute value of each
+///difference, and sums these four values to form one 16-bit result. The
+///intrinsic computes 16 of these results with different sets of input
+///bytes.
+///
+///For each set of eight results, the SAD operations use the same four
+///bytes from \a Y; the starting bit position for these four bytes is
+///specified by \a M[1:0] times 32. The eight operations use successive
+///sets of four bytes from \a X; the starting bit position for the first
+///set of four bytes is specified by \a M[2] times 32. These bit positions
+///are all relative to the 128-bit lane for each set of eight operations.
+///
+/// \code{.operation}
+/// r := 0
+/// FOR i := 0 TO 1
+///   j := i*3
+///   Ybase := M[j+1:j]*32 + i*128
+///   Xbase := M[j+2]*32 + i*128
+///   FOR k := 0 TO 3
+/// temp0 := ABS(X[Xbase+7:Xbase] - Y[Ybase+7:Ybase])
+/// temp1 := ABS(X[Xbase+15:Xbase+8] - Y[Ybase+15:Ybase+8])
+/// temp2 := ABS(X[Xbase+23:Xbase+16] - Y[Ybase+23:Ybase+16])
+/// temp3 := ABS(X[Xbase+31:Xbase+24] - Y[Ybase+31:Ybase+24])
+/// result[r+15:r] := temp0 + temp1 + temp2 + temp3
+/// Xbase := Xbase + 8
+/// r := r + 16
+///   ENDFOR
+/// ENDFOR
+/// \endcode
+///
+/// \headerfile 
+///
+/// \code
+/// __m256i _mm256_mpsadbw_epu8(__m256i X, __m256i Y, const int M);
+/// \endcode
+///
+/// This intrinsic corresponds to the \c VMPSADBW instruction.
+///
+/// \param X
+///A 256-bit integer vector containing one of the inputs.
+/// \param Y
+///A 256-bit integer vector containing one of the inputs.
+/// \param M
+/// An unsigned immediate value specifying the starting positions of the
+/// bytes to operate on.
+/// \returns A 256-bit vector of [16 x i16] containing the result.
 #define _mm256_mpsadbw_epu8(X, Y, M) \
   ((__m256i)__builtin_ia32_mpsadbw256((__v32qi)(__m256i)(X), \
   (__v32qi)(__m256i)(Y), (int)(M)))
 
+/// Computes the absolute value of each signed byte in the 256-bit integer
+///vector \a __a and returns each value in the corresponding byte of
+///the result.
+///
+/// \headerfile 
+///
+/// This intrinsic corresponds to the \c VPABSB instruction.
+///
+/// \param __a
+///A 256-bit integer vector.
+/// \returns A 256-bit integer vector containing the result.
 static __inline__ __m256i __DEFAULT_FN_ATTRS256
 _mm256_abs_epi8(__m256i __a)
 {
 return (__m256i)__builtin_elementwise_abs((__v32qs)__a);
 }
 
+/// Computes the absolute value of each signed 16-bit element in the 256-bit
+///vector of [16 x i16] in \a __a and returns each value in the
+///corresponding element of the result.
+///
+/// \headerfile 
+///
+/// This intrinsic corresponds to the \c VPABSW instruction.
+///
+/// \param __a
+///A 256-bit vector of [16 x i16].
+/// \returns A 256-bit vector of [16 x i16] containing the result.
 static __inline__ __m256i __DEFAULT_FN_ATTRS256
 _mm256_abs_epi16(__m256i __a)
 {
 return (__m256i)__builtin_elementwise_abs((__v16hi)__a);
 }
 
+/// Computes the absolute value of each signed 32-bit element in the 256-bit
+///vector of [8 x i32] in \a __a and returns each value in the
+///corresponding element of the result.
+///
+/// \headerfile 
+///
+/// This intrinsic corresponds to the \c VPABSD instruction.
+///
+/// \param __a
+///A 256-bit vector of [8 x i32].
+/// \returns A 256-bit vector of [8 x i32] containing the result.
 static __inline__ __m256i __DEFAULT_FN_ATTRS256
 _mm256_abs_epi32(__m256i __a)
 {
@@ -345,24 +435,88 @@
   (

[clang] bfa467b - [Headers][doc] Add various arith/logical intrinsic descriptions to avx2intrin.h

[Paul Robinson via cfe-commits]

Author: Paul Robinson
Date: 2023-06-22T06:32:28-07:00
New Revision: bfa467bdc0e900dbd44e2b896678d6fb77daacf4

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

LOG: [Headers][doc] Add various arith/logical intrinsic descriptions to 
avx2intrin.h

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

Added: 


Modified: 
clang/lib/Headers/avx2intrin.h

Removed: 




diff  --git a/clang/lib/Headers/avx2intrin.h b/clang/lib/Headers/avx2intrin.h
index 5346a0209928e..737cf9897d826 100644
--- a/clang/lib/Headers/avx2intrin.h
+++ b/clang/lib/Headers/avx2intrin.h
@@ -19,22 +19,112 @@
 #define __DEFAULT_FN_ATTRS128 __attribute__((__always_inline__, __nodebug__, 
__target__("avx2"), __min_vector_width__(128)))
 
 /* SSE4 Multiple Packed Sums of Absolute Difference.  */
+/// Computes sixteen sum of absolute 
diff erence (SAD) operations on sets of
+///four unsigned 8-bit integers from the 256-bit integer vectors \a X and
+///\a Y.
+///
+///Eight SAD results are computed using the lower half of the input
+///vectors, and another eight using the upper half. These 16-bit values
+///are returned in the lower and upper halves of the 256-bit result,
+///respectively.
+///
+///A single SAD operation selects four bytes from \a X and four bytes from
+///\a Y as input. It computes the 
diff erences between each \a X byte and
+///the corresponding \a Y byte, takes the absolute value of each
+///
diff erence, and sums these four values to form one 16-bit result. The
+///intrinsic computes 16 of these results with 
diff erent sets of input
+///bytes.
+///
+///For each set of eight results, the SAD operations use the same four
+///bytes from \a Y; the starting bit position for these four bytes is
+///specified by \a M[1:0] times 32. The eight operations use successive
+///sets of four bytes from \a X; the starting bit position for the first
+///set of four bytes is specified by \a M[2] times 32. These bit positions
+///are all relative to the 128-bit lane for each set of eight operations.
+///
+/// \code{.operation}
+/// r := 0
+/// FOR i := 0 TO 1
+///   j := i*3
+///   Ybase := M[j+1:j]*32 + i*128
+///   Xbase := M[j+2]*32 + i*128
+///   FOR k := 0 TO 3
+/// temp0 := ABS(X[Xbase+7:Xbase] - Y[Ybase+7:Ybase])
+/// temp1 := ABS(X[Xbase+15:Xbase+8] - Y[Ybase+15:Ybase+8])
+/// temp2 := ABS(X[Xbase+23:Xbase+16] - Y[Ybase+23:Ybase+16])
+/// temp3 := ABS(X[Xbase+31:Xbase+24] - Y[Ybase+31:Ybase+24])
+/// result[r+15:r] := temp0 + temp1 + temp2 + temp3
+/// Xbase := Xbase + 8
+/// r := r + 16
+///   ENDFOR
+/// ENDFOR
+/// \endcode
+///
+/// \headerfile 
+///
+/// \code
+/// __m256i _mm256_mpsadbw_epu8(__m256i X, __m256i Y, const int M);
+/// \endcode
+///
+/// This intrinsic corresponds to the \c VMPSADBW instruction.
+///
+/// \param X
+///A 256-bit integer vector containing one of the inputs.
+/// \param Y
+///A 256-bit integer vector containing one of the inputs.
+/// \param M
+/// An unsigned immediate value specifying the starting positions of the
+/// bytes to operate on.
+/// \returns A 256-bit vector of [16 x i16] containing the result.
 #define _mm256_mpsadbw_epu8(X, Y, M) \
   ((__m256i)__builtin_ia32_mpsadbw256((__v32qi)(__m256i)(X), \
   (__v32qi)(__m256i)(Y), (int)(M)))
 
+/// Computes the absolute value of each signed byte in the 256-bit integer
+///vector \a __a and returns each value in the corresponding byte of
+///the result.
+///
+/// \headerfile 
+///
+/// This intrinsic corresponds to the \c VPABSB instruction.
+///
+/// \param __a
+///A 256-bit integer vector.
+/// \returns A 256-bit integer vector containing the result.
 static __inline__ __m256i __DEFAULT_FN_ATTRS256
 _mm256_abs_epi8(__m256i __a)
 {
 return (__m256i)__builtin_elementwise_abs((__v32qs)__a);
 }
 
+/// Computes the absolute value of each signed 16-bit element in the 256-bit
+///vector of [16 x i16] in \a __a and returns each value in the
+///corresponding element of the result.
+///
+/// \headerfile 
+///
+/// This intrinsic corresponds to the \c VPABSW instruction.
+///
+/// \param __a
+///A 256-bit vector of [16 x i16].
+/// \returns A 256-bit vector of [16 x i16] containing the result.
 static __inline__ __m256i __DEFAULT_FN_ATTRS256
 _mm256_abs_epi16(__m256i __a)
 {
 return (__m256i)__builtin_elementwise_abs((__v16hi)__a);
 }
 
+/// Computes the absolute value of each signed 32-bit element in the 256-bit
+///vector of [8 x i32] in \a __a and returns each value in the
+///corresponding element of the result.
+///
+/// \headerfile 
+///
+/// This intrinsic corresponds to the \c VPABSD instruction.
+///
+/// \param __a
+///A 2

[PATCH] D153033: [CLANG]Fix potential null pointer dereference bugs

[Aaron Ballman via Phabricator via cfe-commits]

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

LGTM


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

https://reviews.llvm.org/D153033

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

[PATCH] D150931: [NFC][Clang] Fix Static Code Analysis Concerns with copy without assign

[Soumi Manna via Phabricator via cfe-commits]

Manna added a comment.

ping @tahonermann


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

https://reviews.llvm.org/D150931

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

[PATCH] D146148: [clang] Add a namespace for interesting identifiers.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam updated this revision to Diff 533583.

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

https://reviews.llvm.org/D146148

Files:
  clang/include/clang/Basic/IdentifierTable.h
  clang/include/clang/Basic/TokenKinds.def
  clang/include/clang/Basic/TokenKinds.h
  clang/lib/Basic/Builtins.cpp
  clang/lib/Basic/IdentifierTable.cpp
  clang/lib/Sema/SemaDecl.cpp

Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -6764,14 +6764,22 @@
   if (IdentifierInfo *II = NewTD->getIdentifier())
 if (!NewTD->isInvalidDecl() &&
 NewTD->getDeclContext()->getRedeclContext()->isTranslationUnit()) {
-  if (II->isStr("FILE"))
+  switch (II->getInterestingIdentifierID()) {
+  case tok::InterestingIdentifierKind::FILE:
 Context.setFILEDecl(NewTD);
-  else if (II->isStr("jmp_buf"))
+break;
+  case tok::InterestingIdentifierKind::jmp_buf:
 Context.setjmp_bufDecl(NewTD);
-  else if (II->isStr("sigjmp_buf"))
+break;
+  case tok::InterestingIdentifierKind::sigjmp_buf:
 Context.setsigjmp_bufDecl(NewTD);
-  else if (II->isStr("ucontext_t"))
+break;
+  case tok::InterestingIdentifierKind::ucontext_t:
 Context.setucontext_tDecl(NewTD);
+break;
+  default:
+break;
+  }
 }
 
   return NewTD;
Index: clang/lib/Basic/IdentifierTable.cpp
===
--- clang/lib/Basic/IdentifierTable.cpp
+++ clang/lib/Basic/IdentifierTable.cpp
@@ -279,6 +279,16 @@
   Table.get(Name).setObjCKeywordID(ObjCID);
 }
 
+static void AddInterestingIdentifier(StringRef Name,
+ tok::InterestingIdentifierKind BTID,
+ IdentifierTable &Table) {
+  // Don't add 'not_interesting' identifier.
+  if (BTID != tok::not_interesting) {
+IdentifierInfo &Info = Table.get(Name, tok::identifier);
+Info.setInterestingIdentifierID(BTID);
+  }
+}
+
 /// AddKeywords - Add all keywords to the symbol table.
 ///
 void IdentifierTable::AddKeywords(const LangOptions &LangOpts) {
@@ -295,6 +305,9 @@
 #define OBJC_AT_KEYWORD(NAME)  \
   if (LangOpts.ObjC)   \
 AddObjCKeyword(StringRef(#NAME), tok::objc_##NAME, *this);
+#define INTERESTING_IDENTIFIER(NAME)   \
+  AddInterestingIdentifier(StringRef(#NAME), tok::NAME, *this);
+
 #define TESTING_KEYWORD(NAME, FLAGS)
 #include "clang/Basic/TokenKinds.def"
 
Index: clang/lib/Basic/Builtins.cpp
===
--- clang/lib/Basic/Builtins.cpp
+++ clang/lib/Basic/Builtins.cpp
@@ -151,7 +151,7 @@
   unsigned ID = NameIt->second->getBuiltinID();
   if (ID != Builtin::NotBuiltin && isPredefinedLibFunction(ID) &&
   isInStdNamespace(ID) == InStdNamespace) {
-Table.get(Name).setBuiltinID(Builtin::NotBuiltin);
+NameIt->second->clearBuiltinID();
   }
 }
   }
Index: clang/include/clang/Basic/TokenKinds.h
===
--- clang/include/clang/Basic/TokenKinds.h
+++ clang/include/clang/Basic/TokenKinds.h
@@ -44,6 +44,14 @@
   NUM_OBJC_KEYWORDS
 };
 
+/// Provides a namespace for interesting identifers such as float_t and
+/// double_t.
+enum InterestingIdentifierKind {
+#define INTERESTING_IDENTIFIER(X) X,
+#include "clang/Basic/TokenKinds.def"
+  NUM_INTERESTING_IDENTIFIERS
+};
+
 /// Defines the possible values of an on-off-switch (C99 6.10.6p2).
 enum OnOffSwitch {
   OOS_ON, OOS_OFF, OOS_DEFAULT
Index: clang/include/clang/Basic/TokenKinds.def
===
--- clang/include/clang/Basic/TokenKinds.def
+++ clang/include/clang/Basic/TokenKinds.def
@@ -85,6 +85,9 @@
 #ifndef PRAGMA_ANNOTATION
 #define PRAGMA_ANNOTATION(X) ANNOTATION(X)
 #endif
+#ifndef INTERESTING_IDENTIFIER
+#define INTERESTING_IDENTIFIER(X)
+#endif
 
 //===--===//
 // Preprocessor keywords.
@@ -794,6 +797,15 @@
 OBJC_AT_KEYWORD(import)
 OBJC_AT_KEYWORD(available)
 
+//===--===//
+// Interesting idenitifiers.
+//===--===//
+INTERESTING_IDENTIFIER(not_interesting)
+INTERESTING_IDENTIFIER(FILE)
+INTERESTING_IDENTIFIER(jmp_buf)
+INTERESTING_IDENTIFIER(sigjmp_buf)
+INTERESTING_IDENTIFIER(ucontext_t)
+
 // TODO: What to do about context-sensitive keywords like:
 //   bycopy/byref/in/inout/oneway/out?
 
@@ -974,3 +986,4 @@
 #undef TOK
 #undef C99_KEYWORD
 #undef C2X_KEYWORD
+#undef INTERESTING_IDENTIFIER
Index: clang/include/clang/Basic/IdentifierTable.h
===
--- clang/include/clang/

[PATCH] D153340: [include-cleaner] Add an IgnoreHeaders flag to the command-line tool.

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet added inline comments.



Comment at: clang-tools-extra/include-cleaner/tool/IncludeCleaner.cpp:54
+"ignore-headers",
+cl::desc("A comma-separated list of headers to ignore."),
+cl::init(""),

`A comma-separated list of regexes to match against suffix of a header, and 
disable analysis if matched.`



Comment at: clang-tools-extra/include-cleaner/tool/IncludeCleaner.cpp:139
+  HeaderPattern, RegexError);
+return;
+  }

erroring out only after we performed all of our analysis and build a TU feels 
unfortunate. can we build these regexes and verify them at main and pass onto 
action instead? (in case the action is run on multiple files at once, we 
shouldn't compile/verify regexes over and over again)



Comment at: clang-tools-extra/include-cleaner/tool/IncludeCleaner.cpp:160
 auto Results =
 analyze(AST.Roots, PP.MacroReferences, PP.Includes, &PI, SM, HS);
 if (!Insert)

we actually want to perform filtering inside `analyze`. it's not enough to 
filter only when printing, we should also filter before applying fixes :D. but 
we should also be applying filtering to absolute paths in all cases, for 
missing includes this is being applied to spelling instead.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153340

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

[PATCH] D153366: [dataflow] Add dedicated representation of boolean formulas

[Martin Böhme via Phabricator via cfe-commits]

mboehme added a comment.

High-level comment: I like the separation of concerns that this introduces.

Would you like me to review https://reviews.llvm.org/D153469 or should we wait 
for this patch to converge first?




Comment at: clang/include/clang/Analysis/FlowSensitive/Formula.h:22
+namespace clang::dataflow {
+class Formula;
+

Put this right above the class definition below? (This is just needed for the 
`alignas(Formula *)`, right?)



Comment at: clang/include/clang/Analysis/FlowSensitive/Formula.h:38
+/// A boolean expression such as "true" or "V1 & !V2".
+/// Expressions may refer to boolean atomic variables, identified by number.
+///

Is this important to state? (It's an implementation detail of `Atom`, 
essentially?)



Comment at: clang/include/clang/Analysis/FlowSensitive/Formula.h:47
+/// trailing objects.
+class alignas(Formula *) Formula {
+public:

Do you need the `alignas` because the pointers to operands are stored as 
trailing objects? Can you add a short comment to that effect?



Comment at: clang/include/clang/Analysis/FlowSensitive/Formula.h:71
+  ArrayRef operands() const {
+return ArrayRef(reinterpret_cast(this + 1),
+numOperands(kind()));

Is this technically legal? (I've taken a look, but the definition of similar 
types makes my eyes glaze over.)

Why not use `TrailingObjects` instead? (I'm not really familiar with 
`TrailingObjects`, so there may be good reasons against it -- just asking 
because it seems like an obvious existing mechanism that could be used here.)



Comment at: clang/include/clang/Analysis/FlowSensitive/Formula.h:82
+ ArrayRef Operands,
+ unsigned Value = 0);
+

This looks like an "internal" API -- it's really only intended for use by 
`Arena`, right?

Maybe add a comment indicating that it's not intended to be used directly?



Comment at: clang/include/clang/Analysis/FlowSensitive/Formula.h:104
+  Kind FormulaKind;
+  unsigned Value;
+};

Why not give this type `Atom`?



Comment at: clang/lib/Analysis/FlowSensitive/WatchedLiteralsSolver.cpp:218
 
-  BooleanFormula Formula(NextVar - 1, std::move(Atomics));
+  BooleanFormula Form(NextVar - 1, std::move(Atomics));
   std::vector ProcessedSubVals(NextVar, false);

Now that we've added `Formula`, it's pretty confusing that we also have 
`BooleanFormula`.

I assume this is one of the renamings that you want to get to later? I guess 
`BooleanFormula` becomes something like `CnfFormula` (would like to do 
`3CnfFormula`, but you can't start with a digit... :( )


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153366

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

[PATCH] D153170: [RISCV] Sort the extensions in SupportedExtensions and SupportedExperimentalExtensions.

[Alex Bradbury via Phabricator via cfe-commits]

asb accepted this revision.
asb 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/D153170/new/

https://reviews.llvm.org/D153170

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

[PATCH] D153146: [CLANG] Fix potential integer overflow value in getRVVTypeSize()

[Soumi Manna via Phabricator via cfe-commits]

Manna updated this revision to Diff 533589.
Manna edited the summary of this revision.
Manna added a comment.

Thank you @erichkeane for review and comments. I have changed the types of 
variables MinElts and EltSize to uint64_t instead of the cast.


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

https://reviews.llvm.org/D153146

Files:
  clang/lib/AST/ASTContext.cpp


Index: clang/lib/AST/ASTContext.cpp
===
--- clang/lib/AST/ASTContext.cpp
+++ clang/lib/AST/ASTContext.cpp
@@ -9564,8 +9564,8 @@
 
   ASTContext::BuiltinVectorTypeInfo Info = 
Context.getBuiltinVectorTypeInfo(Ty);
 
-  unsigned EltSize = Context.getTypeSize(Info.ElementType);
-  unsigned MinElts = Info.EC.getKnownMinValue();
+  uint64_t EltSize = Context.getTypeSize(Info.ElementType);
+  uint64_t MinElts = Info.EC.getKnownMinValue();
   return VScale->first * MinElts * EltSize;
 }
 


Index: clang/lib/AST/ASTContext.cpp
===
--- clang/lib/AST/ASTContext.cpp
+++ clang/lib/AST/ASTContext.cpp
@@ -9564,8 +9564,8 @@
 
   ASTContext::BuiltinVectorTypeInfo Info = Context.getBuiltinVectorTypeInfo(Ty);
 
-  unsigned EltSize = Context.getTypeSize(Info.ElementType);
-  unsigned MinElts = Info.EC.getKnownMinValue();
+  uint64_t EltSize = Context.getTypeSize(Info.ElementType);
+  uint64_t MinElts = Info.EC.getKnownMinValue();
   return VScale->first * MinElts * EltSize;
 }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D153549: [clang][dataflow] Dump useful debugging information when we crash.

[Martin Böhme via Phabricator via cfe-commits]

mboehme created this revision.
Herald added subscribers: martong, xazax.hun.
Herald added a reviewer: NoQ.
Herald added a project: All.
mboehme requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

- The AST of the function we're currently analyzing
- The CFG
- The CFG element we're currently processing


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D153549

Files:
  clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp


Index: clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
===
--- clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
+++ clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
@@ -18,6 +18,7 @@
 #include 
 #include 
 
+#include "clang/AST/ASTDumper.h"
 #include "clang/AST/DeclCXX.h"
 #include "clang/AST/OperationKinds.h"
 #include "clang/AST/StmtVisitor.h"
@@ -179,6 +180,47 @@
   llvm::ArrayRef> BlockStates;
 };
 
+class PrettyStackTraceAnalysis : public llvm::PrettyStackTraceEntry {
+public:
+  PrettyStackTraceAnalysis(const ControlFlowContext &CFCtx, const char 
*Message)
+  : CFCtx(CFCtx), Message(Message) {}
+
+  void print(raw_ostream &OS) const override {
+OS << Message << "\n";
+OS << "Decl:\n";
+CFCtx.getDecl()->dump(OS);
+OS << "CFG:\n";
+CFCtx.getCFG().print(OS, LangOptions(), false);
+  }
+
+private:
+  const ControlFlowContext &CFCtx;
+  const char *Message;
+};
+
+class PrettyStackTraceCFGElement : public llvm::PrettyStackTraceEntry {
+public:
+  PrettyStackTraceCFGElement(const CFGElement &Element, int BlockIdx,
+ int ElementIdx, const char *Message)
+  : Element(Element), BlockIdx(BlockIdx), ElementIdx(ElementIdx),
+Message(Message) {}
+
+  void print(raw_ostream &OS) const override {
+OS << Message << ": Element [B" << BlockIdx << "." << ElementIdx << "]\n";
+if (auto Stmt = Element.getAs()) {
+  OS << "Stmt:\n";
+  ASTDumper Dumper(OS, false);
+  Dumper.Visit(Stmt->getStmt());
+}
+  }
+
+private:
+  const CFGElement ∈
+  int BlockIdx;
+  int ElementIdx;
+  const char *Message;
+};
+
 } // namespace
 
 /// Computes the input state for a given basic block by joining the output
@@ -357,7 +399,11 @@
   AC.Log.enterBlock(Block);
   auto State = computeBlockInputState(Block, AC);
   AC.Log.recordState(State);
+  int ElementIdx = 1;
   for (const auto &Element : Block) {
+PrettyStackTraceCFGElement CrashInfo(Element, Block.getBlockID(),
+ ElementIdx++, "transferCFGBlock");
+
 AC.Log.enterElement(Element);
 // Built-in analysis
 if (AC.Analysis.builtinOptions()) {
@@ -395,6 +441,8 @@
 std::function
 PostVisitCFG) {
+  PrettyStackTraceAnalysis CrashInfo(CFCtx, "runTypeErasedDataflowAnalysis");
+
   PostOrderCFGView POV(&CFCtx.getCFG());
   ForwardDataflowWorklist Worklist(CFCtx.getCFG(), &POV);
 


Index: clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
===
--- clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
+++ clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
@@ -18,6 +18,7 @@
 #include 
 #include 
 
+#include "clang/AST/ASTDumper.h"
 #include "clang/AST/DeclCXX.h"
 #include "clang/AST/OperationKinds.h"
 #include "clang/AST/StmtVisitor.h"
@@ -179,6 +180,47 @@
   llvm::ArrayRef> BlockStates;
 };
 
+class PrettyStackTraceAnalysis : public llvm::PrettyStackTraceEntry {
+public:
+  PrettyStackTraceAnalysis(const ControlFlowContext &CFCtx, const char *Message)
+  : CFCtx(CFCtx), Message(Message) {}
+
+  void print(raw_ostream &OS) const override {
+OS << Message << "\n";
+OS << "Decl:\n";
+CFCtx.getDecl()->dump(OS);
+OS << "CFG:\n";
+CFCtx.getCFG().print(OS, LangOptions(), false);
+  }
+
+private:
+  const ControlFlowContext &CFCtx;
+  const char *Message;
+};
+
+class PrettyStackTraceCFGElement : public llvm::PrettyStackTraceEntry {
+public:
+  PrettyStackTraceCFGElement(const CFGElement &Element, int BlockIdx,
+ int ElementIdx, const char *Message)
+  : Element(Element), BlockIdx(BlockIdx), ElementIdx(ElementIdx),
+Message(Message) {}
+
+  void print(raw_ostream &OS) const override {
+OS << Message << ": Element [B" << BlockIdx << "." << ElementIdx << "]\n";
+if (auto Stmt = Element.getAs()) {
+  OS << "Stmt:\n";
+  ASTDumper Dumper(OS, false);
+  Dumper.Visit(Stmt->getStmt());
+}
+  }
+
+private:
+  const CFGElement ∈
+  int BlockIdx;
+  int ElementIdx;
+  const char *Message;
+};
+
 } // namespace
 
 /// Computes the input state for a given basic block by joining the output
@@ -357,7 +399,11 @@
   AC.Log.enterBlock(Block);
   auto State = computeBlockInputState(Block, AC);
   AC.Log.recordState(State);
+  int ElementIdx = 1;
   for (const auto &Element : B

[PATCH] D153468: [clang][LTO] Add flag to run verifier after every pass

[Teresa Johnson via Phabricator via cfe-commits]

tejohnson added inline comments.



Comment at: clang/test/CodeGen/verify-each.c:5
+// RUN: %clang_cc1 -O2 -o /dev/null -triple x86_64-unknown-linux-gnu 
-emit-llvm-bc %s -fdebug-pass-manager 2>&1 | FileCheck %s --check-prefix=NO
+// NO-NOT: Verifying
+

Huh, really surprised we are never normally running the verifier through clang! 
How did we hit the verification error you used this to narrow down in the first 
place?



Comment at: clang/test/CodeGen/verify-each.c:14
+
+// CHECK: Verifying
+

Might be slightly more robust to check for one specific opt pass having a 
verifier run both before and after it, rather than for a single run of the 
verifier.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153468

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

[PATCH] D153259: [clangd] Store offsets in MacroOccurrence

[Kadir Cetinkaya via Phabricator via cfe-commits]

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

thanks, lgtm!




Comment at: clang-tools-extra/clangd/CollectMacros.cpp:37
   Out.Names.insert(Name);
-  auto Range = halfOpenToRange(
-  SM, CharSourceRange::getCharRange(Loc, MacroNameTok.getEndLoc()));
+  size_t Start = SM.getDecomposedSpellingLoc(Loc).second;
+  size_t End = SM.getDecomposedSpellingLoc(MacroNameTok.getEndLoc()).second;

nit: `SM.getFileOffset`



Comment at: clang-tools-extra/clangd/CollectMacros.h:26
 struct MacroOccurrence {
-  // Instead of storing SourceLocation, we have to store the token range 
because
-  // SourceManager from preamble is not available when we build the AST.
-  Range Rng;
+  // Represents an occurrence in main-file, a half-open range.
+  size_t StartOffset, EndOffset;

`Represents an occurrence in main-file` sounds like the documentation for the 
struct not for these fields.
what about `// Half-open range (end offset is exclusive) inside the main 
file.`. can you also move `EndOffset` to its own line?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153259

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

[PATCH] D153510: [Clang] Check type support for local variable declaration

[Yueh-Ting (eop) Chen via Phabricator via cfe-commits]

eopXD added a comment.

In D153510#4440784 , @aaron.ballman 
wrote:

> This checking already happens when the declaration is actually *used*, so I 
> question whether we need to do the check at all (declared but unused 
> variables seem like an edge case to me): https://godbolt.org/z/e4Y8qKMrW
>
> What is the behavior of the example I linked with your patch? Do we now issue 
> the diagnostic twice (once on the declaration and again on the use)?

Yes. The missing behavior here is the check when variables are declared and not 
used. This patch lets the compiler emit error upon declaration.

  $ cat test.c
  #include 
  
  void bar(void) {
vint64m1_t i64m1;
(void)i64m1;
  }
  
  
  eopc@sw02:/scratch/eopc/upstream-llvm-project2/build$ bin/clang 
-march=rv64g_zve32x test.c
  test.c:4:14: error: RISC-V type 'vint64m1_t' (aka '__rvv_int64m1_t') requires 
the 'zve64x' extension
  4 |   vint64m1_t i64m1;
|  ^
  test.c:5:9: error: RISC-V type 'vint64m1_t' (aka '__rvv_int64m1_t') requires 
the 'zve64x' extension
  5 |   (void)i64m1;
| ^
  2 errors generated.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153510

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

[PATCH] D153556: [OPENMP52] Initial support for doacross clause.

[Jennifer Yu via Phabricator via cfe-commits]

jyu2 created this revision.
jyu2 added reviewers: ABataev, jdoerfert, mikerice.
jyu2 added projects: OpenMP, clang.
Herald added subscribers: sunshaoce, arphaman, guansong, yaxunl.
Herald added a reviewer: kiranchandramohan.
Herald added projects: Flang, All.
jyu2 requested review of this revision.
Herald added subscribers: llvm-commits, cfe-commits, jplehr, sstefan1.
Herald added a project: LLVM.

Initial support for doacross clause in ordered directive. 
This is  intend to replace depend clause in ordered directive.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D153556

Files:
  clang/include/clang/AST/OpenMPClause.h
  clang/include/clang/AST/RecursiveASTVisitor.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/OpenMPKinds.def
  clang/include/clang/Basic/OpenMPKinds.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/OpenMPClause.cpp
  clang/lib/AST/StmtProfile.cpp
  clang/lib/Basic/OpenMPKinds.cpp
  clang/lib/Parse/ParseOpenMP.cpp
  clang/lib/Sema/SemaOpenMP.cpp
  clang/lib/Sema/TreeTransform.h
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/test/OpenMP/ordered_ast_print.cpp
  clang/test/OpenMP/ordered_messages.cpp
  clang/tools/libclang/CIndex.cpp
  flang/lib/Semantics/check-omp-structure.cpp
  llvm/include/llvm/Frontend/OpenMP/OMP.td

Index: llvm/include/llvm/Frontend/OpenMP/OMP.td
===
--- llvm/include/llvm/Frontend/OpenMP/OMP.td
+++ llvm/include/llvm/Frontend/OpenMP/OMP.td
@@ -444,6 +444,10 @@
   let flangClass = "ScalarIntExpr";
 }
 
+def OMPC_Doacross : Clause<"doacross"> {
+  let clangClass = "OMPDoacrossClause";
+}
+
 //===--===//
 // Definition of OpenMP directives
 //===--===//
@@ -604,7 +608,8 @@
 }
 def OMP_Ordered : Directive<"ordered"> {
   let allowedClauses = [
-VersionedClause
+VersionedClause,
+VersionedClause
   ];
   let allowedOnceClauses = [
 VersionedClause,
Index: flang/lib/Semantics/check-omp-structure.cpp
===
--- flang/lib/Semantics/check-omp-structure.cpp
+++ flang/lib/Semantics/check-omp-structure.cpp
@@ -1937,6 +1937,7 @@
 CHECK_SIMPLE_CLAUSE(Align, OMPC_align)
 CHECK_SIMPLE_CLAUSE(Compare, OMPC_compare)
 CHECK_SIMPLE_CLAUSE(CancellationConstructType, OMPC_cancellation_construct_type)
+CHECK_SIMPLE_CLAUSE(Doacross, OMPC_doacross)
 
 CHECK_REQ_SCALAR_INT_CLAUSE(Grainsize, OMPC_grainsize)
 CHECK_REQ_SCALAR_INT_CLAUSE(NumTasks, OMPC_num_tasks)
Index: clang/tools/libclang/CIndex.cpp
===
--- clang/tools/libclang/CIndex.cpp
+++ clang/tools/libclang/CIndex.cpp
@@ -2717,6 +2717,9 @@
   VisitOMPClauseWithPreInit(C);
   Visitor->AddStmt(C->getSize());
 }
+void OMPClauseEnqueue::VisitOMPDoacrossClause(const OMPDoacrossClause *C) {
+  VisitOMPClauseList(C);
+}
 
 } // namespace
 
Index: clang/test/OpenMP/ordered_messages.cpp
===
--- clang/test/OpenMP/ordered_messages.cpp
+++ clang/test/OpenMP/ordered_messages.cpp
@@ -1,6 +1,7 @@
 // RUN: %clang_cc1 -verify -fopenmp -ferror-limit 100 -o - %s -Wuninitialized
 // RUN: %clang_cc1 -verify -fopenmp -ferror-limit 100 -std=c++98 -o - %s -Wuninitialized
 // RUN: %clang_cc1 -verify -fopenmp -ferror-limit 100 -std=c++11 -o - %s -Wuninitialized
+// RUN: %clang_cc1 -verify=expected,omp52 -fopenmp -fopenmp-version=52 -ferror-limit 100 -o - %s -Wuninitialized
 
 // RUN: %clang_cc1 -verify -fopenmp-simd -ferror-limit 100 -o - %s -Wuninitialized
 // RUN: %clang_cc1 -verify -fopenmp-simd -ferror-limit 100 -std=c++98 -o - %s -Wuninitialized
@@ -135,12 +136,48 @@
   }
 #pragma omp parallel for ordered
   for (int i = 0; i < 10; ++i) {
+#if _OPENMP >= 202111
+#pragma omp ordered doacross(source:) // omp52-error {{'ordered' directive with 'doacross' clause cannot be closely nested inside ordered region without specified parameter}}
+#pragma omp ordered doacross(sink : i) // omp52-error {{'ordered' directive with 'doacross' clause cannot be closely nested inside ordered region without specified parameter}}
+#else
 #pragma omp ordered depend(source) // expected-error {{'ordered' directive with 'depend' clause cannot be closely nested inside ordered region without specified parameter}}
 #pragma omp ordered depend(sink : i) // expected-error {{'ordered' directive with 'depend' clause cannot be closely nested inside ordered region without specified parameter}}
+#endif
   }
 #pragma omp parallel for ordered(2) // expected-note 3 {{'ordered' clause with specified parameter}}
   for (int i = 0; i < 10; ++i) {
 for (int j = 0; j < 10; ++j) {
+#if _OPENMP >= 202111
+#pragma omp ordered doacross // omp52-error {{expected '(' after 'doacross'}} omp52-error {{'or

[PATCH] D143967: [DebugInfo][BPF] Add 'btf:type_tag' annotation in DWARF

[Eduard Zingerman via Phabricator via cfe-commits]

eddyz87 added a comment.

In D143967#4438815 , @dblaikie wrote:

> I haven't looked closely at this, but from a vague/quick reading, it sounds 
> like this is creating annotations on certain type DINodes, but then moving 
> them around to different types? It'd be nice if we could avoid that/create 
> them in the right place in the first place.

Hi @dblaikie, thank you for taking a look!

I assume you refer to the "placeholder" nodes created for annotated types.
I added these to handle the following example:

  #define __tag1 __attribute__((btf_type_tag("tag1")))
  
  struct st {
struct st __tag1 *self;
  } g;

Here I need to create two `DICompositeType` instances for `struct st`:

- one with `btf_type_tag` annotations;
- one without `btf_type_tag` annotations.

The AST for `struct st __tag1 *` looks as follows:

  PointerType 0x55c364ead270 'struct st  __attribute__((btf_type_tag("tag1")))*'
  `-BTFTagAttributedType 0x55c364ead210
'struct st __attribute__((btf_type_tag("tag1")))' sugar
`-ElaboratedType 0x55c364ead1a0 'struct st' sugar
  `-RecordType 0x55c364ead120 'struct st'
`-Record 0x55c364ead0a0 'st'

(Note the `BTFTagAttributedType` node).

W/o type tags this examples is processed as follows:

- `getOrCreateType()` is called for `struct st`
  - `CreateType(const RecordType *)` is called for `struct st`
- `CreateTypeDefinition(const RecordType *)` is called for `struct st`
  - `getOrCreateLimitedType(const RecordType *)` is called for `struct st`
- `CreateLimitedType(const RecordType *)` is called for `struct st`, 
which returns a `TempDICompositeType` (let's call it `T`)
- `TypeCache` for `struct st` is set to `T`
  - members of `struct st` are processed:
- `getOrCreateType()` is called for `struct st *`
  - `CreateType(const PointerType *)` is called for `struct st *`
- `getOrCreateType()` is called for `struct st`, which returns `T`, 
because of `TypeCache` state.
  - all uses of `T` are replaced by complete type.

With type tags processing is similar, but pointee type for `struct st *` is 
actually `(BTFTagAttributedType (RecordType 'struct st'))`.
The `CreateType(const BTFTagAttributedType *)` creates an instance of 
`TempDIDerivedType` with correct annotations (the placeholder) and base type 
corresponding to `struct st`.
Then, at `CGDebugInfo::finalize()` the placeholder is removed:

- the copy of the base type with correct annotations is created;
- all used of placeholder are replaced by this copy.

So, because at the point when `CreateType(BTFTagAttributedType *)` is called, 
the base type is not guaranteed to be complete yet there is a need to create 
some kind of temporary node.

An alternative to my current implementation would be creation of 
`TempDICompositeType` nodes, but this would require passing annotations down 
from `CreateType(BTFTagAttributedType *)` to `CreateLimitedType(const 
RecordType *)` via `getOrCreateType()` / `CreateTypeNode()`. But this seems 
very intrusive for the sake of a narrow feature used by a single backend.

Thus, I think that current implementation is better, because all `btf_decl_tag` 
annotations processing is grouped in two points:

- `CreateType(const BTFTagAttributedType *)`;
- `copyAnnotations()` called from `finalize()`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143967

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

[PATCH] D145302: [clangd] Add library for clangd main function

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet added a comment.

thanks LG and seems to be working in a couple build configurations I tried. but 
there might still be breakages in different configs, so please be on the 
watchout after landing this for breakages in https://lab.llvm.org/.

FWIW something like:

  # Needed by LLVM's CMake checks because this file defines multiple targets.
  set(LLVM_OPTIONAL_SOURCES ClangdToolMain.cpp)
  
  add_clang_library(clangdMain
Check.cpp
ClangdMain.cpp
)
  
  clang_target_link_libraries(clangdMain
PRIVATE
clangAST
clangBasic
clangDaemon
clangFormat
clangFrontend
clangLex
clangSema
clangTidy
clangTooling
clangToolingCore
clangToolingRefactoring
clangToolingSyntax
clangdRemoteIndex
clangdSupport
$
  )
  
  if(CLANGD_BUILD_XPC)
target_link_libraries(clangdMain
  PRIVATE
  clangdXpcJsonConversions
  clangdXpcTransport
  )
  endif()
  
  add_clang_tool(clangd
ClangdToolMain.cpp
)
  
  clang_target_link_libraries(clangd
PRIVATE
clangdMain
)

for the CMakeFile seem to cut it.




Comment at: clang-tools-extra/clangd/tool/CMakeLists.txt:11
+  ClangdToolMain.cpp
   $
   )

we should move this into `clangdMain` target now



Comment at: clang-tools-extra/clangd/tool/CMakeLists.txt:37
+
+target_link_libraries(clangdMain
+  PRIVATE

you can merge this with the previous rule



Comment at: clang-tools-extra/clangd/tool/CMakeLists.txt:48
   PRIVATE
+  clangdMain
   clangAST

it should be enough to have `clangdMain` here now.



Comment at: clang-tools-extra/clangd/tool/CMakeLists.txt:61
 
 target_link_libraries(clangd
   PRIVATE

you can get rid of this rule too


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145302

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

[PATCH] D153557: [clang][ExtractAPI] Add support for C++ classes

[Erick Velez via Phabricator via cfe-commits]

evelez7 created this revision.
evelez7 added a reviewer: dang.
Herald added a reviewer: ributzka.
Herald added a subscriber: ChuanqiXu.
Herald added a project: All.
evelez7 requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Add ExtractAPI support C++ classes, fields,  methods, and various qualifiers 
and specifiers


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D153557

Files:
  clang/include/clang/ExtractAPI/API.h
  clang/include/clang/ExtractAPI/DeclarationFragments.h
  clang/include/clang/ExtractAPI/ExtractAPIVisitor.h
  clang/include/clang/ExtractAPI/Serialization/SerializerBase.h
  clang/include/clang/ExtractAPI/Serialization/SymbolGraphSerializer.h
  clang/lib/ExtractAPI/API.cpp
  clang/lib/ExtractAPI/DeclarationFragments.cpp
  clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp

Index: clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp
===
--- clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp
+++ clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp
@@ -366,6 +366,38 @@
 Kind["identifier"] = AddLangPrefix("struct");
 Kind["displayName"] = "Structure";
 break;
+  case APIRecord::RK_CXXField:
+Kind["identifier"] = AddLangPrefix("property");
+Kind["displayName"] = "Instance Property";
+break;
+  case APIRecord::RK_Union:
+Kind["identifier"] = AddLangPrefix("union");
+Kind["displayName"] = "Union";
+break;
+  case APIRecord::RK_StaticField:
+Kind["identifier"] = AddLangPrefix("type.property");
+Kind["displayName"] = "Type Property";
+break;
+  case APIRecord::RK_CXXClass:
+Kind["identifier"] = AddLangPrefix("class");
+Kind["displayName"] = "Class";
+break;
+  case APIRecord::RK_CXXStaticMethod:
+Kind["identifier"] = AddLangPrefix("type.method");
+Kind["displayName"] = "Static Method";
+break;
+  case APIRecord::RK_CXXInstanceMethod:
+Kind["identifier"] = AddLangPrefix("method");
+Kind["displayName"] = "Instance Method";
+break;
+  case APIRecord::RK_CXXConstructorMethod:
+Kind["identifier"] = AddLangPrefix("method");
+Kind["displayName"] = "Constructor";
+break;
+  case APIRecord::RK_CXXDestructorMethod:
+Kind["identifier"] = AddLangPrefix("method");
+Kind["displayName"] = "Destructor";
+break;
   case APIRecord::RK_ObjCIvar:
 Kind["identifier"] = AddLangPrefix("ivar");
 Kind["displayName"] = "Instance Variable";
@@ -543,7 +575,6 @@
 
   return ParentContexts;
 }
-
 } // namespace
 
 /// Defines the format version emitted by SymbolGraphSerializer.
@@ -698,6 +729,28 @@
   serializeMembers(Record, Record.Fields);
 }
 
+void SymbolGraphSerializer::visitStaticFieldRecord(
+const StaticFieldRecord &Record) {
+  auto StaticField = serializeAPIRecord(Record);
+  if (!StaticField)
+return;
+  Symbols.emplace_back(std::move(*StaticField));
+  serializeRelationship(RelationshipKind::MemberOf, Record, Record.Context);
+}
+
+void SymbolGraphSerializer::visitCXXClassRecord(const CXXClassRecord &Record) {
+  auto Class = serializeAPIRecord(Record);
+  if (!Class)
+return;
+
+  Symbols.emplace_back(std::move(*Class));
+  serializeMembers(Record, Record.Fields);
+  serializeMembers(Record, Record.Methods);
+
+  for (const auto Base : Record.Bases)
+serializeRelationship(RelationshipKind::InheritsFrom, Record, Base);
+}
+
 void SymbolGraphSerializer::visitObjCContainerRecord(
 const ObjCContainerRecord &Record) {
   auto ObjCContainer = serializeAPIRecord(Record);
@@ -761,6 +814,12 @@
   case APIRecord::RK_Struct:
 visitStructRecord(*cast(Record));
 break;
+  case APIRecord::RK_StaticField:
+visitStaticFieldRecord(*cast(Record));
+break;
+  case APIRecord::RK_CXXClass:
+visitCXXClassRecord(*cast(Record));
+break;
   case APIRecord::RK_ObjCInterface:
 visitObjCContainerRecord(*cast(Record));
 break;
Index: clang/lib/ExtractAPI/DeclarationFragments.cpp
===
--- clang/lib/ExtractAPI/DeclarationFragments.cpp
+++ clang/lib/ExtractAPI/DeclarationFragments.cpp
@@ -12,8 +12,10 @@
 //===--===//
 
 #include "clang/ExtractAPI/DeclarationFragments.h"
+#include "clang/AST/DeclCXX.h"
 #include "clang/ExtractAPI/TypedefUnderlyingTypeResolver.h"
 #include "clang/Index/USRGeneration.h"
+#include "clang/Parse/Parser.h"
 #include "llvm/ADT/StringSwitch.h"
 
 using namespace clang::extractapi;
@@ -84,6 +86,43 @@
   .Default(DeclarationFragments::FragmentKind::None);
 }
 
+DeclarationFragments DeclarationFragments::getExceptionSpecificationString(
+ExceptionSpecificationType ExceptionSpec) {
+  DeclarationFragments Fragments;
+  switch (ExceptionSpec) {
+  case ExceptionSpecificationType::EST_BasicNoexcept:
+Fragments.append(" noexcept", DeclarationFragments::Fra

[PATCH] D152623: [clang-format] Indent Verilog struct literal on new line

[sstwcw via Phabricator via cfe-commits]

sstwcw added a comment.

> So I assume your `'` is a 'DictLiteral`?

The brace following the quote is a `DictLiteral`.  The quote is a 
`tok::identifier` and `TT_Unknown`.

> Does it have to be one?

The brace is set to this type when used this way in all other languages.  I 
don't want to make an exception.

> I don't know what else maybe a `DictLiteral` in what language and am not so 
> comfortable with this change.

I changed the patch to use the new behavior only for Verilog.

The `DictLiteral` type gets set on the braces and colons in literals where the 
field names and values are separated by colons in all languages that have them. 
 In addition, because the protocol buffer text format allows angular brackets 
as braces, the type is also set on those angular brackets for that language.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D152623

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

[PATCH] D152623: [clang-format] Indent Verilog struct literal on new line

[sstwcw via Phabricator via cfe-commits]

sstwcw updated this revision to Diff 533617.
sstwcw added a comment.

- limit change to Verilog


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D152623

Files:
  clang/lib/Format/ContinuationIndenter.cpp
  clang/unittests/Format/FormatTestVerilog.cpp


Index: clang/unittests/Format/FormatTestVerilog.cpp
===
--- clang/unittests/Format/FormatTestVerilog.cpp
+++ clang/unittests/Format/FormatTestVerilog.cpp
@@ -1172,6 +1172,15 @@
   verifyFormat("c = '{a : 0, b : 0.0, default : 0};", Style);
   verifyFormat("c = ab'{a : 0, b : 0.0};", Style);
   verifyFormat("c = ab'{cd : cd'{1, 1.0}, ef : ef'{2, 2.0}};", Style);
+
+  // It should be indented correctly when the line has to break.
+  verifyFormat("c = //\n"
+   "'{default: 0};");
+  Style = getDefaultStyle();
+  Style.ContinuationIndentWidth = 2;
+  verifyFormat("c = //\n"
+   "  '{default: 0};",
+   Style);
 }
 
 TEST_F(FormatTestVerilog, StructuredProcedure) {
Index: clang/lib/Format/ContinuationIndenter.cpp
===
--- clang/lib/Format/ContinuationIndenter.cpp
+++ clang/lib/Format/ContinuationIndenter.cpp
@@ -1172,7 +1172,15 @@
   }
   if (NextNonComment->is(TT_TemplateString) && NextNonComment->closesScope())
 return State.Stack[State.Stack.size() - 2].LastSpace;
+  // Field labels in a nested type should be aligned to the brace. For example
+  // in ProtoBuf:
+  //   optional int32 b = 2 [(foo_options) = {aaa: 123,
+  //  :"baz"}];
+  // For Verilog, a quote following a brace is treated as an identifier.  And
+  // Both braces and colons get annotated as TT_DictLiteral.  So we have to
+  // check.
   if (Current.is(tok::identifier) && Current.Next &&
+  (!Style.isVerilog() || Current.Next->is(tok::colon)) &&
   (Current.Next->is(TT_DictLiteral) ||
((Style.Language == FormatStyle::LK_Proto ||
  Style.Language == FormatStyle::LK_TextProto) &&


Index: clang/unittests/Format/FormatTestVerilog.cpp
===
--- clang/unittests/Format/FormatTestVerilog.cpp
+++ clang/unittests/Format/FormatTestVerilog.cpp
@@ -1172,6 +1172,15 @@
   verifyFormat("c = '{a : 0, b : 0.0, default : 0};", Style);
   verifyFormat("c = ab'{a : 0, b : 0.0};", Style);
   verifyFormat("c = ab'{cd : cd'{1, 1.0}, ef : ef'{2, 2.0}};", Style);
+
+  // It should be indented correctly when the line has to break.
+  verifyFormat("c = //\n"
+   "'{default: 0};");
+  Style = getDefaultStyle();
+  Style.ContinuationIndentWidth = 2;
+  verifyFormat("c = //\n"
+   "  '{default: 0};",
+   Style);
 }
 
 TEST_F(FormatTestVerilog, StructuredProcedure) {
Index: clang/lib/Format/ContinuationIndenter.cpp
===
--- clang/lib/Format/ContinuationIndenter.cpp
+++ clang/lib/Format/ContinuationIndenter.cpp
@@ -1172,7 +1172,15 @@
   }
   if (NextNonComment->is(TT_TemplateString) && NextNonComment->closesScope())
 return State.Stack[State.Stack.size() - 2].LastSpace;
+  // Field labels in a nested type should be aligned to the brace. For example
+  // in ProtoBuf:
+  //   optional int32 b = 2 [(foo_options) = {aaa: 123,
+  //  :"baz"}];
+  // For Verilog, a quote following a brace is treated as an identifier.  And
+  // Both braces and colons get annotated as TT_DictLiteral.  So we have to
+  // check.
   if (Current.is(tok::identifier) && Current.Next &&
+  (!Style.isVerilog() || Current.Next->is(tok::colon)) &&
   (Current.Next->is(TT_DictLiteral) ||
((Style.Language == FormatStyle::LK_Proto ||
  Style.Language == FormatStyle::LK_TextProto) &&
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D150860: [OpenMP] Change clang emitTargetDataCalls to use OMPIRBuilder

[Akash Banerjee via Phabricator via cfe-commits]

TIFitis updated this revision to Diff 533619.
TIFitis added a comment.

Moved device clause emition after if clause.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D150860

Files:
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/test/OpenMP/target_data_codegen.cpp
  clang/test/OpenMP/target_data_use_device_ptr_codegen.cpp
  llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h
  llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp

Index: llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp
===
--- llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp
+++ llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp
@@ -4084,7 +4084,9 @@
 function_ref GenMapInfoCB,
 omp::RuntimeFunction *MapperFunc,
 function_ref
-BodyGenCB) {
+BodyGenCB,
+function_ref DeviceAddrCB,
+function_ref CustomMapperCB) {
   if (!updateToLocation(Loc))
 return InsertPointTy();
 
@@ -4095,9 +4097,9 @@
   // arguments of the runtime call by reference because they are used in the
   // closing of the region.
   auto BeginThenGen = [&](InsertPointTy AllocaIP, InsertPointTy CodeGenIP) {
-emitOffloadingArrays(AllocaIP, Builder.saveIP(),
- GenMapInfoCB(Builder.saveIP()), Info,
- /*IsNonContiguous=*/true);
+emitOffloadingArrays(
+AllocaIP, Builder.saveIP(), GenMapInfoCB(Builder.saveIP()), Info,
+/*IsNonContiguous=*/true, DeviceAddrCB, CustomMapperCB);
 
 TargetDataRTArgs RTArgs;
 emitOffloadingArraysArgument(Builder, RTArgs, Info);
Index: llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h
===
--- llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h
+++ llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h
@@ -2032,6 +2032,10 @@
   /// \param Info Stores all information realted to the Target Data directive.
   /// \param GenMapInfoCB Callback that populates the MapInfos and returns.
   /// \param BodyGenCB Optional Callback to generate the region code.
+  /// \param DeviceAddrCB Optional callback to generate code related to
+  /// use_device_ptr and use_device_addr.
+  /// \param CustomMapperCB Optional callback to generate code related to
+  /// custom mappers.
   OpenMPIRBuilder::InsertPointTy createTargetData(
   const LocationDescription &Loc, InsertPointTy AllocaIP,
   InsertPointTy CodeGenIP, Value *DeviceID, Value *IfCond,
@@ -2040,7 +2044,9 @@
   omp::RuntimeFunction *MapperFunc = nullptr,
   function_ref
-  BodyGenCB = nullptr);
+  BodyGenCB = nullptr,
+  function_ref DeviceAddrCB = nullptr,
+  function_ref CustomMapperCB = nullptr);
 
   using TargetBodyGenCallbackTy = function_ref;
Index: clang/test/OpenMP/target_data_use_device_ptr_codegen.cpp
===
--- clang/test/OpenMP/target_data_use_device_ptr_codegen.cpp
+++ clang/test/OpenMP/target_data_use_device_ptr_codegen.cpp
@@ -131,7 +131,6 @@
 ++l;
   }
   // CK1: [[BEND]]:
-  // CK1: [[CMP:%.+]] = icmp ne ptr %{{.+}}, null
   // CK1: br i1 [[CMP]], label %[[BTHEN:.+]], label %[[BELSE:.+]]
 
   // CK1: [[BTHEN]]:
Index: clang/test/OpenMP/target_data_codegen.cpp
===
--- clang/test/OpenMP/target_data_codegen.cpp
+++ clang/test/OpenMP/target_data_codegen.cpp
@@ -63,9 +63,7 @@
 
   // CK1: %{{.+}} = add nsw i32 %{{[^,]+}}, 1
 
-  // CK1-DAG: call void @__tgt_target_data_end_mapper(ptr @{{.+}}, i64 [[DEV:%[^,]+]], i32 1, ptr [[GEPBP:%.+]], ptr [[GEPP:%.+]], ptr [[SIZE00]], ptr [[MTYPE00]], ptr null, ptr null)
-  // CK1-DAG: [[DEV]] = sext i32 [[DEVi32:%[^,]+]] to i64
-  // CK1-DAG: [[DEVi32]] = load i32, ptr %{{[^,]+}},
+  // CK1-DAG: call void @__tgt_target_data_end_mapper(ptr @{{.+}}, i64 [[DEV]], i32 1, ptr [[GEPBP:%.+]], ptr [[GEPP:%.+]], ptr [[SIZE00]], ptr [[MTYPE00]], ptr null, ptr null)
   // CK1-DAG: [[GEPBP]] = getelementptr inbounds {{.+}}[[BP]]
 // CK1-DAG: [[GEPP]] = getelementptr inbounds {{.+}}[[P]]
   #pragma omp target data if(1+3-5) device(arg) map(from: gc)
@@ -354,11 +352,11 @@
 }
 
 // Region 00
+// CK2-DAG: [[DEV:%[^,]+]] = sext i32 [[DEVi32:%[^,]+]] to i64
+// CK2-DAG: [[DEVi32]] = load i32, ptr %{{[^,]+}},
 // CK2: br i1 %{{[^,]+}}, label %[[IFTHEN:[^,]+]], label %[[IFELSE:[^,]+]]
 // CK2: [[IFTHEN]]
-// CK2-DAG: call void @__tgt_target_data_begin_mapper(ptr @{{.+}}, i64 [[DEV:%[^,]+]], i32 2, ptr [[GEPBP:%.+]], ptr [[GEPP:%.+]], ptr [[GEPS:%[^,]+]], ptr [[MTYPE00]], ptr null, ptr null)
-// CK2-DAG: [[DEV]] = sext i32 [[DEVi32:%[^,]+]] to i64
-// CK2-DAG: [[DEVi32]] = load i32, ptr %{{[^,]+}},
+// CK2-DAG: call void @__tgt_target_data_begin_mapper(ptr @{{.+}}, i64 [[DEV]], i32 2, ptr [[GEPBP:%.+]], ptr [[GEPP:%.+]], ptr [[GEPS:%[^,]+]], ptr [[MTYPE00]], ptr null, ptr null)
 // CK2-DAG: [[GEPBP]] = getelementptr inbounds [2

[PATCH] D150803: Add a new `wasm_custom` clang attribute for marking functions.

[Sam Clegg via Phabricator via cfe-commits]

sbc100 added inline comments.



Comment at: clang/include/clang/Basic/AttrDocs.td:5608-5612
+Clang supports the ``__attribute__((wasm_async))``
+attribute for the WebAssembly target. This attribute may be attached to a
+function definition, which indicates the function will be used with JavaScript
+promise integration (JSPI). The attribute will cause the creation of a custom
+section named "async" that contains each wasm_async function's index value.

aaron.ballman wrote:
> brendandahl wrote:
> > aaron.ballman wrote:
> > > aaron.ballman wrote:
> > > > This could be my ignorance of web assembly showing, but the docs don't 
> > > > really help me understand when you'd want to use this attribute. 
> > > > Perhaps a link to what JSPI is and a code example would help a little 
> > > > bit? Or is this more of a low-level implementation detail kind of 
> > > > attribute where folks already know the domain?
> > > Based on the documentation here, I'm wondering why the `annotate` 
> > > attribute doesn't suffice? That attribute lets you specify custom 
> > > information to associate with a declaration that then gets lowered such 
> > > that passes can do whatever they want with the info, which seems to be a 
> > > more generalized version of what this attribute is.
> > > 
> > > (FWIW, I'm back to having basically no idea when you'd use this attribute 
> > > or what it would be used for, so my thoughts above might make no sense.)
> > I was considering that, but it would require more machinery in the wasm 
> > backend to store all the attribute values in the output. For now we only 
> > really need a flag associated with function. I think if we find more uses 
> > for the annotations in the future we could replace wasm_custom with it.
> > I was considering that, but it would require more machinery in the wasm 
> > backend to store all the attribute values in the output. For now we only 
> > really need a flag associated with function. I think if we find more uses 
> > for the annotations in the future we could replace wasm_custom with it.
> 
> More machinery in the backend is preferred to exposing a new attribute that 
> is this general-purpose; the backend is what needs this functionality, the 
> frontend basically does nothing with it. (I'm assuming this is an 
> implementation detail attribute and not something you expect users to write. 
> If I'm wrong about that, please let me know.)
> Based on the documentation here, I'm wondering why the `annotate` attribute 
> doesn't suffice? 

I believe that was the original solution that was considered but Benden was 
told this was perhaps not an appropriate use of "annotate".   Brenden can you 
elaborate on why?   IIRC it was something like "the semantics of the program 
should not depend on annotate attributes but the attribute being added in this 
case is required for the program to run correctly".. is that about right?

FWIW, I think using the existing `annotate` attribute would make a lot of 
sense... if we can get away with it.



Comment at: clang/include/clang/Basic/AttrDocs.td:5608-5612
+Clang supports the ``__attribute__((wasm_async))``
+attribute for the WebAssembly target. This attribute may be attached to a
+function definition, which indicates the function will be used with JavaScript
+promise integration (JSPI). The attribute will cause the creation of a custom
+section named "async" that contains each wasm_async function's index value.

sbc100 wrote:
> aaron.ballman wrote:
> > brendandahl wrote:
> > > aaron.ballman wrote:
> > > > aaron.ballman wrote:
> > > > > This could be my ignorance of web assembly showing, but the docs 
> > > > > don't really help me understand when you'd want to use this 
> > > > > attribute. Perhaps a link to what JSPI is and a code example would 
> > > > > help a little bit? Or is this more of a low-level implementation 
> > > > > detail kind of attribute where folks already know the domain?
> > > > Based on the documentation here, I'm wondering why the `annotate` 
> > > > attribute doesn't suffice? That attribute lets you specify custom 
> > > > information to associate with a declaration that then gets lowered such 
> > > > that passes can do whatever they want with the info, which seems to be 
> > > > a more generalized version of what this attribute is.
> > > > 
> > > > (FWIW, I'm back to having basically no idea when you'd use this 
> > > > attribute or what it would be used for, so my thoughts above might make 
> > > > no sense.)
> > > I was considering that, but it would require more machinery in the wasm 
> > > backend to store all the attribute values in the output. For now we only 
> > > really need a flag associated with function. I think if we find more uses 
> > > for the annotations in the future we could replace wasm_custom with it.
> > > I was considering that, but it would require more machinery in the wasm 
> > > backend to store all the attribute valu

[clang] b81c507 - [flang] add -flang-experimental-polymorphism flag to flang-new

[David Truby via cfe-commits]

Author: David Truby
Date: 2023-06-22T16:21:09+01:00
New Revision: b81c5070d5451af127b2c9c2ae362ba1b0a96c01

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

LOG: [flang] add -flang-experimental-polymorphism flag to flang-new

This flag enables Fortran 2003 polymorphism. It is marked experimental
and not included in --help.

Reviewed By: tblah, awarzynski

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

Added: 
flang/test/Driver/flang-experimental-polymorphism-flag.f90

Modified: 
clang/include/clang/Driver/Options.td
clang/lib/Driver/ToolChains/Flang.cpp
flang/lib/Frontend/CompilerInvocation.cpp
flang/test/Driver/driver-help-hidden.f90
flang/test/Driver/frontend-forwarding.f90

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 69239e6cf296d..53c107b0f0fb0 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -5283,6 +5283,11 @@ def flang_experimental_hlfir : Flag<["-"], 
"flang-experimental-hlfir">,
   Flags<[FlangOption, FC1Option, FlangOnlyOption, NoXarchOption, HelpHidden]>,
   HelpText<"Use HLFIR lowering (experimental)">;
 
+def flang_experimental_polymorphism : Flag<["-"], 
"flang-experimental-polymorphism">,
+  Flags<[FlangOption, FC1Option, FlangOnlyOption, NoXarchOption, HelpHidden]>,
+  HelpText<"Enable Fortran 2003 polymorphism (experimental)">;
+  
+
 
//===--===//
 // FLangOption + CoreOption + NoXarchOption
 
//===--===//

diff  --git a/clang/lib/Driver/ToolChains/Flang.cpp 
b/clang/lib/Driver/ToolChains/Flang.cpp
index 9a2ddf777cd7f..75b9524a0c72e 100644
--- a/clang/lib/Driver/ToolChains/Flang.cpp
+++ b/clang/lib/Driver/ToolChains/Flang.cpp
@@ -140,6 +140,8 @@ void Flang::addCodegenOptions(const ArgList &Args,
 
   if (Args.hasArg(options::OPT_flang_experimental_hlfir))
 CmdArgs.push_back("-flang-experimental-hlfir");
+  if (Args.hasArg(options::OPT_flang_experimental_polymorphism))
+CmdArgs.push_back("-flang-experimental-polymorphism");
   if (shouldLoopVersion(Args))
 CmdArgs.push_back("-fversion-loops-for-stride");
 }

diff  --git a/flang/lib/Frontend/CompilerInvocation.cpp 
b/flang/lib/Frontend/CompilerInvocation.cpp
index 610f60c5899bb..f8a075ce5f949 100644
--- a/flang/lib/Frontend/CompilerInvocation.cpp
+++ b/flang/lib/Frontend/CompilerInvocation.cpp
@@ -920,6 +920,10 @@ bool CompilerInvocation::createFromArgs(
 res.loweringOpts.setLowerToHighLevelFIR(true);
   }
 
+  if 
(args.hasArg(clang::driver::options::OPT_flang_experimental_polymorphism)) {
+res.loweringOpts.setPolymorphicTypeImpl(true);
+  }
+
   success &= parseFrontendArgs(res.getFrontendOpts(), args, diags);
   parseTargetArgs(res.getTargetOpts(), args);
   parsePreprocessorArgs(res.getPreprocessorOpts(), args);

diff  --git a/flang/test/Driver/driver-help-hidden.f90 
b/flang/test/Driver/driver-help-hidden.f90
index d8b1a03d4c0d9..a3fe2f09c0703 100644
--- a/flang/test/Driver/driver-help-hidden.f90
+++ b/flang/test/Driver/driver-help-hidden.f90
@@ -41,6 +41,8 @@
 ! CHECK-NEXT:Specify where to find the compiled 
intrinsic modules
 ! CHECK-NEXT: -flang-experimental-hlfir
 ! CHECK-NEXT:Use HLFIR lowering (experimental)
+! CHECK-NEXT: -flang-experimental-polymorphism
+! CHECK-NEXT:Enable Fortran 2003 polymorphism 
(experimental)
 ! CHECK-NEXT: -flarge-sizes  Use INTEGER(KIND=8) for the result type 
in size-related intrinsics
 ! CHECK-NEXT: -flogical-abbreviations Enable logical abbreviations
 ! CHECK-NEXT: -flto= Set LTO mode

diff  --git a/flang/test/Driver/flang-experimental-polymorphism-flag.f90 
b/flang/test/Driver/flang-experimental-polymorphism-flag.f90
new file mode 100644
index 0..106e898149a18
--- /dev/null
+++ b/flang/test/Driver/flang-experimental-polymorphism-flag.f90
@@ -0,0 +1,10 @@
+! Test -flang-experimental-hlfir flag
+! RUN: %flang_fc1 -flang-experimental-polymorphism -emit-fir -o - %s | 
FileCheck %s
+! RUN: not %flang_fc1 -emit-fir -o - %s 2>&1 | FileCheck %s --check-prefix 
NO-POLYMORPHISM
+
+! CHECK: func.func @_QPtest(%{{.*}}: !fir.class {fir.bindc_name = 
"poly"})
+subroutine test(poly)
+  class(*) :: poly
+end subroutine test
+
+! NO-POLYMORPHISM: not yet implemented: support for polymorphic types

diff  --git a/flang/test/Driver/frontend-forwarding.f90 
b/flang/test/Driver/frontend-forwarding.f90
index ddee84bac106c..e953c957d2d00 100644
--- a/flang/test/Driver/frontend-forwarding.f90
+++ b/flang/test/Driver/frontend-forwarding.f90
@@ -16,7 +16,7 @@
 ! RUN: -freciprocal-math \
 ! RUN: -fpass-plu

[PATCH] D153281: [flang] add -flang-experimental-polymorphism flag to flang-new

[David Truby 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 rGb81c5070d545: [flang] add -flang-experimental-polymorphism 
flag to flang-new (authored by DavidTruby).

Changed prior to commit:
  https://reviews.llvm.org/D153281?vs=532658&id=533622#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153281

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Flang.cpp
  flang/lib/Frontend/CompilerInvocation.cpp
  flang/test/Driver/driver-help-hidden.f90
  flang/test/Driver/flang-experimental-polymorphism-flag.f90
  flang/test/Driver/frontend-forwarding.f90


Index: flang/test/Driver/frontend-forwarding.f90
===
--- flang/test/Driver/frontend-forwarding.f90
+++ flang/test/Driver/frontend-forwarding.f90
@@ -16,7 +16,7 @@
 ! RUN: -freciprocal-math \
 ! RUN: -fpass-plugin=Bye%pluginext \
 ! RUN: -fversion-loops-for-stride \
-! RUN: -mllvm -print-before-all\
+! RUN: -flang-experimental-polymorphism \
 ! RUN: -mllvm -print-before-all \
 ! RUN: -save-temps=obj \
 ! RUN: -P \
@@ -36,6 +36,7 @@
 ! CHECK: "-freciprocal-math"
 ! CHECK: "-fconvert=little-endian"
 ! CHECK: "-fpass-plugin=Bye
-! CHECK: "-fversion-loops-for-stride"  
+! CHECK: "-flang-experimental-polymorphism"
+! CHECK: "-fversion-loops-for-stride"
 ! CHECK: "-mllvm" "-print-before-all"
 ! CHECK: "-save-temps=obj"
Index: flang/test/Driver/flang-experimental-polymorphism-flag.f90
===
--- /dev/null
+++ flang/test/Driver/flang-experimental-polymorphism-flag.f90
@@ -0,0 +1,10 @@
+! Test -flang-experimental-hlfir flag
+! RUN: %flang_fc1 -flang-experimental-polymorphism -emit-fir -o - %s | 
FileCheck %s
+! RUN: not %flang_fc1 -emit-fir -o - %s 2>&1 | FileCheck %s --check-prefix 
NO-POLYMORPHISM
+
+! CHECK: func.func @_QPtest(%{{.*}}: !fir.class {fir.bindc_name = 
"poly"})
+subroutine test(poly)
+  class(*) :: poly
+end subroutine test
+
+! NO-POLYMORPHISM: not yet implemented: support for polymorphic types
Index: flang/test/Driver/driver-help-hidden.f90
===
--- flang/test/Driver/driver-help-hidden.f90
+++ flang/test/Driver/driver-help-hidden.f90
@@ -41,6 +41,8 @@
 ! CHECK-NEXT:Specify where to find the compiled 
intrinsic modules
 ! CHECK-NEXT: -flang-experimental-hlfir
 ! CHECK-NEXT:Use HLFIR lowering (experimental)
+! CHECK-NEXT: -flang-experimental-polymorphism
+! CHECK-NEXT:Enable Fortran 2003 polymorphism 
(experimental)
 ! CHECK-NEXT: -flarge-sizes  Use INTEGER(KIND=8) for the result type 
in size-related intrinsics
 ! CHECK-NEXT: -flogical-abbreviations Enable logical abbreviations
 ! CHECK-NEXT: -flto= Set LTO mode
Index: flang/lib/Frontend/CompilerInvocation.cpp
===
--- flang/lib/Frontend/CompilerInvocation.cpp
+++ flang/lib/Frontend/CompilerInvocation.cpp
@@ -920,6 +920,10 @@
 res.loweringOpts.setLowerToHighLevelFIR(true);
   }
 
+  if 
(args.hasArg(clang::driver::options::OPT_flang_experimental_polymorphism)) {
+res.loweringOpts.setPolymorphicTypeImpl(true);
+  }
+
   success &= parseFrontendArgs(res.getFrontendOpts(), args, diags);
   parseTargetArgs(res.getTargetOpts(), args);
   parsePreprocessorArgs(res.getPreprocessorOpts(), args);
Index: clang/lib/Driver/ToolChains/Flang.cpp
===
--- clang/lib/Driver/ToolChains/Flang.cpp
+++ clang/lib/Driver/ToolChains/Flang.cpp
@@ -140,6 +140,8 @@
 
   if (Args.hasArg(options::OPT_flang_experimental_hlfir))
 CmdArgs.push_back("-flang-experimental-hlfir");
+  if (Args.hasArg(options::OPT_flang_experimental_polymorphism))
+CmdArgs.push_back("-flang-experimental-polymorphism");
   if (shouldLoopVersion(Args))
 CmdArgs.push_back("-fversion-loops-for-stride");
 }
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -5283,6 +5283,11 @@
   Flags<[FlangOption, FC1Option, FlangOnlyOption, NoXarchOption, HelpHidden]>,
   HelpText<"Use HLFIR lowering (experimental)">;
 
+def flang_experimental_polymorphism : Flag<["-"], 
"flang-experimental-polymorphism">,
+  Flags<[FlangOption, FC1Option, FlangOnlyOption, NoXarchOption, HelpHidden]>,
+  HelpText<"Enable Fortran 2003 polymorphism (experimental)">;
+  
+
 
//===--===//
 // FLangOption + CoreOption + NoXarchOption
 
//===--===//


Index: flang/test/Driver/front

[PATCH] D152785: [COFF] Support -gsplit-dwarf for COFF on Windows

[Haohai, Wen via Phabricator via cfe-commits]

HaohaiWen updated this revision to Diff 533623.
HaohaiWen added a comment.

Remove CoreOption for dumpdir


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D152785

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/test/Driver/split-debug.c
  llvm/include/llvm/MC/MCWinCOFFObjectWriter.h
  llvm/lib/DebugInfo/DWARF/DWARFContext.cpp
  llvm/lib/MC/MCAsmBackend.cpp
  llvm/lib/MC/WinCOFFObjectWriter.cpp
  llvm/test/DebugInfo/COFF/dwarf-headers.ll
  llvm/test/DebugInfo/COFF/fission-cu.ll
  llvm/test/DebugInfo/COFF/fission-sections.ll

Index: llvm/test/DebugInfo/COFF/fission-sections.ll
===
--- /dev/null
+++ llvm/test/DebugInfo/COFF/fission-sections.ll
@@ -0,0 +1,42 @@
+; RUN: llc -split-dwarf-file=baz.dwo -split-dwarf-output=%t.dwo -O0 %s -mtriple=x86_64-unknown-windows-msvc -filetype=obj -o %t
+; RUN: llvm-objdump -h %t | FileCheck --check-prefix=OBJ %s
+; RUN: llvm-objdump -h %t.dwo | FileCheck --check-prefix=DWO %s
+
+; This test is derived from test/DebugInfo/X86/fission-cu.ll
+; But it checks that the output objects have the expected sections
+
+source_filename = "test/DebugInfo/X86/fission-cu.ll"
+
+@a = common global i32 0, align 4, !dbg !0
+
+!llvm.dbg.cu = !{!4}
+!llvm.module.flags = !{!7}
+
+!0 = !DIGlobalVariableExpression(var: !1, expr: !DIExpression())
+!1 = !DIGlobalVariable(name: "a", scope: null, file: !2, line: 1, type: !3, isLocal: false, isDefinition: true)
+!2 = !DIFile(filename: "baz.c", directory: "e:\\llvm-project\\tmp")
+!3 = !DIBasicType(name: "int", size: 32, align: 32, encoding: DW_ATE_signed)
+!4 = distinct !DICompileUnit(language: DW_LANG_C99, file: !2, producer: "clang version 3.3 (trunk 169021) (llvm/trunk 169020)", isOptimized: false, runtimeVersion: 0, splitDebugFilename: "baz.dwo", emissionKind: FullDebug, enums: !5, retainedTypes: !5, globals: !6, imports: !5)
+!5 = !{}
+!6 = !{!0}
+!7 = !{i32 1, !"Debug Info Version", i32 3}
+
+; CHECK-LABEL: Sections:
+
+; OBJ: Idx Name
+; OBJ-NEXT:  0 .text
+; OBJ-NEXT:  1 .data
+; OBJ-NEXT:  2 .bss
+; OBJ-NEXT:  3 .debug_abbrev
+; OBJ-NEXT:  4 .debug_info
+; OBJ-NEXT:  5 .debug_str
+; OBJ-NEXT:  6 .debug_addr
+; OBJ-NEXT:  7 .debug_pubnames
+; OBJ-NEXT:  8 .debug_pubtypes
+; OBJ-NEXT:  9 .debug_line
+
+; DWO:  Idx Name
+; DWO-NEXT:   0 .debug_str.dwo
+; DWO-NEXT:   1 .debug_str_offsets.dwo
+; DWO-NEXT:   2 .debug_info.dwo
+; DWO-NEXT:   3 .debug_abbrev.dwo
Index: llvm/test/DebugInfo/COFF/fission-cu.ll
===
--- /dev/null
+++ llvm/test/DebugInfo/COFF/fission-cu.ll
@@ -0,0 +1,120 @@
+; RUN: llc -split-dwarf-file=baz.dwo -O0 %s -mtriple=x86_64-unknown-windows-msvc -filetype=obj -o %t
+; RUN: llvm-dwarfdump -v -all %t | FileCheck %s
+; RUN: llvm-readobj --relocations %t | FileCheck --check-prefix=OBJ %s
+; RUN: llvm-objdump -h %t | FileCheck --check-prefix=HDR %s
+
+; This test is derived from test/DebugInfo/X86/fission-cu.ll
+
+source_filename = "test/DebugInfo/X86/fission-cu.ll"
+
+@a = common global i32 0, align 4, !dbg !0
+
+!llvm.dbg.cu = !{!4}
+!llvm.module.flags = !{!7}
+
+!0 = !DIGlobalVariableExpression(var: !1, expr: !DIExpression())
+!1 = !DIGlobalVariable(name: "a", scope: null, file: !2, line: 1, type: !3, isLocal: false, isDefinition: true)
+!2 = !DIFile(filename: "baz.c", directory: "e:\\llvm-project\\tmp")
+!3 = !DIBasicType(name: "int", size: 32, align: 32, encoding: DW_ATE_signed)
+!4 = distinct !DICompileUnit(language: DW_LANG_C99, file: !2, producer: "clang version 3.3 (trunk 169021) (llvm/trunk 169020)", isOptimized: false, runtimeVersion: 0, splitDebugFilename: "baz.dwo", emissionKind: FullDebug, enums: !5, retainedTypes: !5, globals: !6, imports: !5)
+!5 = !{}
+; Check that the skeleton compile unit contains the proper attributes:
+; This DIE has the following attributes: DW_AT_comp_dir, DW_AT_stmt_list,
+; DW_AT_low_pc, DW_AT_high_pc, DW_AT_ranges, DW_AT_dwo_name, DW_AT_dwo_id,
+; DW_AT_ranges_base, DW_AT_addr_base.
+
+; CHECK: .debug_abbrev contents:
+; CHECK: Abbrev table for offset: 0x
+; CHECK: [1] DW_TAG_compile_unit DW_CHILDREN_no
+; CHECK: DW_AT_stmt_list DW_FORM_sec_offset
+; CHECK: DW_AT_comp_dir  DW_FORM_strp
+; CHECK: DW_AT_GNU_dwo_name  DW_FORM_strp
+; CHECK: DW_AT_GNU_dwo_idDW_FORM_data8
+
+; Check that we're using the right forms.
+; CHECK: .debug_abbrev.dwo contents:
+; CHECK: Abbrev table for offset: 0x
+; CHECK: [1] DW_TAG_compile_unit DW_CHILDREN_yes
+; CHECK: DW_AT_producer  DW_FORM_GNU_str_index
+; CHECK: DW_AT_language  DW_FORM_data2
+; CHECK: DW_AT_name  DW_FORM_GNU_str_index
+; CHECK: DW_AT_GNU_dwo_name  DW_FORM_GNU_str_index
+; CHECK-NOT: DW_AT_low_pc
+; CHECK-NOT: DW_AT_stmt_list
+; CHECK-NOT: DW_AT_comp_dir
+; CHECK: DW_AT_GNU_dwo_id 

[PATCH] D150803: Add a new `wasm_custom` clang attribute for marking functions.

[Sam Clegg via Phabricator via cfe-commits]

sbc100 added inline comments.



Comment at: clang/include/clang/Basic/AttrDocs.td:5608-5612
+Clang supports the ``__attribute__((wasm_async))``
+attribute for the WebAssembly target. This attribute may be attached to a
+function definition, which indicates the function will be used with JavaScript
+promise integration (JSPI). The attribute will cause the creation of a custom
+section named "async" that contains each wasm_async function's index value.

sbc100 wrote:
> sbc100 wrote:
> > aaron.ballman wrote:
> > > brendandahl wrote:
> > > > aaron.ballman wrote:
> > > > > aaron.ballman wrote:
> > > > > > This could be my ignorance of web assembly showing, but the docs 
> > > > > > don't really help me understand when you'd want to use this 
> > > > > > attribute. Perhaps a link to what JSPI is and a code example would 
> > > > > > help a little bit? Or is this more of a low-level implementation 
> > > > > > detail kind of attribute where folks already know the domain?
> > > > > Based on the documentation here, I'm wondering why the `annotate` 
> > > > > attribute doesn't suffice? That attribute lets you specify custom 
> > > > > information to associate with a declaration that then gets lowered 
> > > > > such that passes can do whatever they want with the info, which seems 
> > > > > to be a more generalized version of what this attribute is.
> > > > > 
> > > > > (FWIW, I'm back to having basically no idea when you'd use this 
> > > > > attribute or what it would be used for, so my thoughts above might 
> > > > > make no sense.)
> > > > I was considering that, but it would require more machinery in the wasm 
> > > > backend to store all the attribute values in the output. For now we 
> > > > only really need a flag associated with function. I think if we find 
> > > > more uses for the annotations in the future we could replace 
> > > > wasm_custom with it.
> > > > I was considering that, but it would require more machinery in the wasm 
> > > > backend to store all the attribute values in the output. For now we 
> > > > only really need a flag associated with function. I think if we find 
> > > > more uses for the annotations in the future we could replace 
> > > > wasm_custom with it.
> > > 
> > > More machinery in the backend is preferred to exposing a new attribute 
> > > that is this general-purpose; the backend is what needs this 
> > > functionality, the frontend basically does nothing with it. (I'm assuming 
> > > this is an implementation detail attribute and not something you expect 
> > > users to write. If I'm wrong about that, please let me know.)
> > > Based on the documentation here, I'm wondering why the `annotate` 
> > > attribute doesn't suffice? 
> > 
> > I believe that was the original solution that was considered but Benden was 
> > told this was perhaps not an appropriate use of "annotate".   Brenden can 
> > you elaborate on why?   IIRC it was something like "the semantics of the 
> > program should not depend on annotate attributes but the attribute being 
> > added in this case is required for the program to run correctly".. is that 
> > about right?
> > 
> > FWIW, I think using the existing `annotate` attribute would make a lot of 
> > sense... if we can get away with it.
> > (I'm assuming this is an implementation detail attribute and not something 
> > you expect users to write. If I'm wrong about that, please let me know.)
> 
> IIUC user would indeed be specifying these attributes.   Kind of like they do 
> for "visibility" today.   The initial attribute that motivated this change is 
> "async" which tells the host runtime that a certain function import or export 
> behaves in an async manor (See https://v8.dev/blog/jspi for more details).
> > I was considering that, but it would require more machinery in the wasm 
> > backend to store all the attribute values in the output. For now we only 
> > really need a flag associated with function. I think if we find more uses 
> > for the annotations in the future we could replace wasm_custom with it.
> 
> More machinery in the backend is preferred to exposing a new attribute that 
> is this general-purpose; the backend is what needs this functionality, the 
> frontend basically does nothing with it. (I'm assuming this is an 
> implementation detail attribute and not something you expect users to write. 
> If I'm wrong about that, please let me know.)

I think perhaps there are two alternative implementations being proposed here, 
and I want to make sure we don't confuse them:

1. Use the existing `annotate` attribute.  
2. Make an even more complex custom attribute that hold key=value pairs rather 
than the current CL which proposes simply boolean custom attributes (e.g. 
key=true).

I think we would be happy with (1) if this usage is within scope.

IIUC the thing that would take a lot more work in the backend (and more complex 
custom section design in the binary format) is (2).   I don't think we need (2

[PATCH] D153560: [Clang] Allow C++11 style initialisation of SVE types.

[Paul Walker via Phabricator via cfe-commits]

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

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


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D153560

Files:
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/test/CodeGen/aarch64-sve.cpp

Index: clang/test/CodeGen/aarch64-sve.cpp
===
--- /dev/null
+++ clang/test/CodeGen/aarch64-sve.cpp
@@ -0,0 +1,167 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py UTC_ARGS: --version 2
+// RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve -emit-llvm -o - %s | FileCheck %s
+
+// CHECK-LABEL: define dso_local void @_Z11test_localsv
+// CHECK-SAME: () #[[ATTR0:[0-9]+]] {
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[S8:%.*]] = alloca , align 16
+// CHECK-NEXT:[[S16:%.*]] = alloca , align 16
+// CHECK-NEXT:[[S32:%.*]] = alloca , align 16
+// CHECK-NEXT:[[S64:%.*]] = alloca , align 16
+// CHECK-NEXT:[[U8:%.*]] = alloca , align 16
+// CHECK-NEXT:[[U16:%.*]] = alloca , align 16
+// CHECK-NEXT:[[U32:%.*]] = alloca , align 16
+// CHECK-NEXT:[[U64:%.*]] = alloca , align 16
+// CHECK-NEXT:[[F16:%.*]] = alloca , align 16
+// CHECK-NEXT:[[F32:%.*]] = alloca , align 16
+// CHECK-NEXT:[[F64:%.*]] = alloca , align 16
+// CHECK-NEXT:[[BF16:%.*]] = alloca , align 16
+// CHECK-NEXT:[[S8X2:%.*]] = alloca , align 16
+// CHECK-NEXT:[[S16X2:%.*]] = alloca , align 16
+// CHECK-NEXT:[[S32X2:%.*]] = alloca , align 16
+// CHECK-NEXT:[[X64X2:%.*]] = alloca , align 16
+// CHECK-NEXT:[[U8X2:%.*]] = alloca , align 16
+// CHECK-NEXT:[[U16X2:%.*]] = alloca , align 16
+// CHECK-NEXT:[[U32X2:%.*]] = alloca , align 16
+// CHECK-NEXT:[[U64X2:%.*]] = alloca , align 16
+// CHECK-NEXT:[[F16X2:%.*]] = alloca , align 16
+// CHECK-NEXT:[[F32X2:%.*]] = alloca , align 16
+// CHECK-NEXT:[[F64X2:%.*]] = alloca , align 16
+// CHECK-NEXT:[[BF16X2:%.*]] = alloca , align 16
+// CHECK-NEXT:[[S8X3:%.*]] = alloca , align 16
+// CHECK-NEXT:[[S16X3:%.*]] = alloca , align 16
+// CHECK-NEXT:[[S32X3:%.*]] = alloca , align 16
+// CHECK-NEXT:[[X64X3:%.*]] = alloca , align 16
+// CHECK-NEXT:[[U8X3:%.*]] = alloca , align 16
+// CHECK-NEXT:[[U16X3:%.*]] = alloca , align 16
+// CHECK-NEXT:[[U32X3:%.*]] = alloca , align 16
+// CHECK-NEXT:[[U64X3:%.*]] = alloca , align 16
+// CHECK-NEXT:[[F16X3:%.*]] = alloca , align 16
+// CHECK-NEXT:[[F32X3:%.*]] = alloca , align 16
+// CHECK-NEXT:[[F64X3:%.*]] = alloca , align 16
+// CHECK-NEXT:[[BF16X3:%.*]] = alloca , align 16
+// CHECK-NEXT:[[S8X4:%.*]] = alloca , align 16
+// CHECK-NEXT:[[S16X4:%.*]] = alloca , align 16
+// CHECK-NEXT:[[S32X4:%.*]] = alloca , align 16
+// CHECK-NEXT:[[X64X4:%.*]] = alloca , align 16
+// CHECK-NEXT:[[U8X4:%.*]] = alloca , align 16
+// CHECK-NEXT:[[U16X4:%.*]] = alloca , align 16
+// CHECK-NEXT:[[U32X4:%.*]] = alloca , align 16
+// CHECK-NEXT:[[U64X4:%.*]] = alloca , align 16
+// CHECK-NEXT:[[F16X4:%.*]] = alloca , align 16
+// CHECK-NEXT:[[F32X4:%.*]] = alloca , align 16
+// CHECK-NEXT:[[F64X4:%.*]] = alloca , align 16
+// CHECK-NEXT:[[BF16X4:%.*]] = alloca , align 16
+// CHECK-NEXT:[[B8:%.*]] = alloca , align 2
+// CHECK-NEXT:[[B8X2:%.*]] = alloca , align 2
+// CHECK-NEXT:[[B8X4:%.*]] = alloca , align 2
+// CHECK-NEXT:store  zeroinitializer, ptr [[S8]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[S16]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[S32]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[S64]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[U8]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[U16]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[U32]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[U64]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[F16]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[F32]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[F64]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[BF16]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[S8X2]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[S16X2]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[S32X2]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[X64X2]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[U8X2]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[U16X2]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[U32X2]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[U64X2]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[F16X2]], align 16
+// CHECK-NEXT:store  zeroinitialize

[PATCH] D153468: [clang][LTO] Add flag to run verifier after every pass

[Arthur Eubanks via Phabricator via cfe-commits]

aeubanks updated this revision to Diff 533627.
aeubanks marked an inline comment as done.
aeubanks added a comment.

update test


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153468

Files:
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/BackendUtil.cpp
  clang/test/CodeGen/verify-each.c
  llvm/include/llvm/LTO/Config.h
  llvm/lib/LTO/LTOBackend.cpp


Index: llvm/lib/LTO/LTOBackend.cpp
===
--- llvm/lib/LTO/LTOBackend.cpp
+++ llvm/lib/LTO/LTOBackend.cpp
@@ -259,7 +259,8 @@
   ModuleAnalysisManager MAM;
 
   PassInstrumentationCallbacks PIC;
-  StandardInstrumentations SI(Mod.getContext(), Conf.DebugPassManager);
+  StandardInstrumentations SI(Mod.getContext(), Conf.DebugPassManager,
+  Conf.VerifyEach);
   SI.registerCallbacks(PIC, &MAM);
   PassBuilder PB(TM, Conf.PTO, PGOOpt, &PIC);
 
Index: llvm/include/llvm/LTO/Config.h
===
--- llvm/include/llvm/LTO/Config.h
+++ llvm/include/llvm/LTO/Config.h
@@ -57,6 +57,7 @@
   CodeGenOpt::Level CGOptLevel = CodeGenOpt::Default;
   CodeGenFileType CGFileType = CGFT_ObjectFile;
   unsigned OptLevel = 2;
+  bool VerifyEach = false;
   bool DisableVerify = false;
 
   /// Use the standard optimization pipeline.
Index: clang/test/CodeGen/verify-each.c
===
--- /dev/null
+++ clang/test/CodeGen/verify-each.c
@@ -0,0 +1,19 @@
+// Test to ensure -llvm-verify-each works.
+// REQUIRES: x86-registered-target
+
+// RUN: %clang_cc1 -O2 -o /dev/null -triple x86_64-unknown-linux-gnu 
-emit-llvm-bc %s -fdebug-pass-manager 2>&1 | FileCheck %s --check-prefix=NO
+// NO-NOT: Verifying
+
+// RUN: %clang_cc1 -O2 -o /dev/null -triple x86_64-unknown-linux-gnu 
-emit-llvm-bc %s -fdebug-pass-manager -llvm-verify-each 2>&1 | FileCheck %s
+
+// RUN: %clang_cc1 -O2 -o %t.o -flto=thin -triple x86_64-unknown-linux-gnu 
-emit-llvm-bc %s -fdebug-pass-manager -llvm-verify-each 2>&1 | FileCheck %s
+// RUN: llvm-lto -thinlto -o %t %t.o
+
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-obj -O2 -o /dev/null 
-x ir %t.o -fthinlto-index=%t.thinlto.bc -fdebug-pass-manager -llvm-verify-each 
2>&1 | FileCheck %s
+
+// CHECK: Verifying function foo
+// CHECK: Running pass: InstCombinePass
+// CHECK: Verifying function foo
+
+void foo(void) {
+}
Index: clang/lib/CodeGen/BackendUtil.cpp
===
--- clang/lib/CodeGen/BackendUtil.cpp
+++ clang/lib/CodeGen/BackendUtil.cpp
@@ -839,7 +839,7 @@
   StandardInstrumentations SI(
   TheModule->getContext(),
   (CodeGenOpts.DebugPassManager || DebugPassStructure),
-  /*VerifyEach*/ false, PrintPassOpts);
+  CodeGenOpts.VerifyEach, PrintPassOpts);
   SI.registerCallbacks(PIC, &MAM);
   PassBuilder PB(TM.get(), PTO, PGOOpt, &PIC);
 
@@ -1192,6 +1192,7 @@
 
   Conf.ProfileRemapping = std::move(ProfileRemapping);
   Conf.DebugPassManager = CGOpts.DebugPassManager;
+  Conf.VerifyEach = CGOpts.VerifyEach;
   Conf.RemarksWithHotness = CGOpts.DiagnosticsWithHotness;
   Conf.RemarksFilename = CGOpts.OptRecordFile;
   Conf.RemarksPasses = CGOpts.OptRecordPasses;
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -5737,6 +5737,9 @@
 
 let Flags = [CC1Option, NoDriverOption] in {
 
+def llvm_verify_each : Flag<["-"], "llvm-verify-each">,
+  HelpText<"Run the LLVM verifier after every LLVM pass">,
+  MarshallingInfoFlag>;
 def disable_llvm_verifier : Flag<["-"], "disable-llvm-verifier">,
   HelpText<"Don't run the LLVM IR verifier pass">,
   MarshallingInfoNegativeFlag>;
Index: clang/include/clang/Basic/CodeGenOptions.def
===
--- clang/include/clang/Basic/CodeGenOptions.def
+++ clang/include/clang/Basic/CodeGenOptions.def
@@ -322,6 +322,8 @@
 
 CODEGENOPT(VerifyModule  , 1, 1) ///< Control whether the module should be 
run
  ///< through the LLVM Verifier.
+CODEGENOPT(VerifyEach, 1, 1) ///< Control whether the LLVM verifier
+ ///< should run after every pass.
 
 CODEGENOPT(StackRealignment  , 1, 0) ///< Control whether to force stack
  ///< realignment.


Index: llvm/lib/LTO/LTOBackend.cpp
===
--- llvm/lib/LTO/LTOBackend.cpp
+++ llvm/lib/LTO/LTOBackend.cpp
@@ -259,7 +259,8 @@
   ModuleAnalysisManager MAM;
 
   PassInstrumentationCallbacks PIC;
-  StandardInstrumentations SI(Mod.getContext(), Conf.DebugPassManager);
+  StandardInstrumentations SI(Mod.get

[PATCH] D153468: [clang][LTO] Add flag to run verifier after every pass

[Arthur Eubanks via Phabricator via cfe-commits]

aeubanks added inline comments.



Comment at: clang/test/CodeGen/verify-each.c:5
+// RUN: %clang_cc1 -O2 -o /dev/null -triple x86_64-unknown-linux-gnu 
-emit-llvm-bc %s -fdebug-pass-manager 2>&1 | FileCheck %s --check-prefix=NO
+// NO-NOT: Verifying
+

tejohnson wrote:
> Huh, really surprised we are never normally running the verifier through 
> clang! How did we hit the verification error you used this to narrow down in 
> the first place?
there is one, but that's a manual run of the verifier pass that doesn't output 
anything, as opposed to the verifier being run directly by pass instrumentation 
which does output something when debug logging is on


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153468

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

[PATCH] D153560: [Clang] Allow C++11 style initialisation of SVE types.

[Paul Walker via Phabricator via cfe-commits]

paulwalker-arm updated this revision to Diff 533629.
paulwalker-arm added a comment.

Moved C++ test into CodeGenCXX.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153560

Files:
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/test/CodeGenCXX/aarch64-sve.cpp

Index: clang/test/CodeGenCXX/aarch64-sve.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/aarch64-sve.cpp
@@ -0,0 +1,167 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py UTC_ARGS: --version 2
+// RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve -emit-llvm -o - %s | FileCheck %s
+
+// CHECK-LABEL: define dso_local void @_Z11test_localsv
+// CHECK-SAME: () #[[ATTR0:[0-9]+]] {
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[S8:%.*]] = alloca , align 16
+// CHECK-NEXT:[[S16:%.*]] = alloca , align 16
+// CHECK-NEXT:[[S32:%.*]] = alloca , align 16
+// CHECK-NEXT:[[S64:%.*]] = alloca , align 16
+// CHECK-NEXT:[[U8:%.*]] = alloca , align 16
+// CHECK-NEXT:[[U16:%.*]] = alloca , align 16
+// CHECK-NEXT:[[U32:%.*]] = alloca , align 16
+// CHECK-NEXT:[[U64:%.*]] = alloca , align 16
+// CHECK-NEXT:[[F16:%.*]] = alloca , align 16
+// CHECK-NEXT:[[F32:%.*]] = alloca , align 16
+// CHECK-NEXT:[[F64:%.*]] = alloca , align 16
+// CHECK-NEXT:[[BF16:%.*]] = alloca , align 16
+// CHECK-NEXT:[[S8X2:%.*]] = alloca , align 16
+// CHECK-NEXT:[[S16X2:%.*]] = alloca , align 16
+// CHECK-NEXT:[[S32X2:%.*]] = alloca , align 16
+// CHECK-NEXT:[[X64X2:%.*]] = alloca , align 16
+// CHECK-NEXT:[[U8X2:%.*]] = alloca , align 16
+// CHECK-NEXT:[[U16X2:%.*]] = alloca , align 16
+// CHECK-NEXT:[[U32X2:%.*]] = alloca , align 16
+// CHECK-NEXT:[[U64X2:%.*]] = alloca , align 16
+// CHECK-NEXT:[[F16X2:%.*]] = alloca , align 16
+// CHECK-NEXT:[[F32X2:%.*]] = alloca , align 16
+// CHECK-NEXT:[[F64X2:%.*]] = alloca , align 16
+// CHECK-NEXT:[[BF16X2:%.*]] = alloca , align 16
+// CHECK-NEXT:[[S8X3:%.*]] = alloca , align 16
+// CHECK-NEXT:[[S16X3:%.*]] = alloca , align 16
+// CHECK-NEXT:[[S32X3:%.*]] = alloca , align 16
+// CHECK-NEXT:[[X64X3:%.*]] = alloca , align 16
+// CHECK-NEXT:[[U8X3:%.*]] = alloca , align 16
+// CHECK-NEXT:[[U16X3:%.*]] = alloca , align 16
+// CHECK-NEXT:[[U32X3:%.*]] = alloca , align 16
+// CHECK-NEXT:[[U64X3:%.*]] = alloca , align 16
+// CHECK-NEXT:[[F16X3:%.*]] = alloca , align 16
+// CHECK-NEXT:[[F32X3:%.*]] = alloca , align 16
+// CHECK-NEXT:[[F64X3:%.*]] = alloca , align 16
+// CHECK-NEXT:[[BF16X3:%.*]] = alloca , align 16
+// CHECK-NEXT:[[S8X4:%.*]] = alloca , align 16
+// CHECK-NEXT:[[S16X4:%.*]] = alloca , align 16
+// CHECK-NEXT:[[S32X4:%.*]] = alloca , align 16
+// CHECK-NEXT:[[X64X4:%.*]] = alloca , align 16
+// CHECK-NEXT:[[U8X4:%.*]] = alloca , align 16
+// CHECK-NEXT:[[U16X4:%.*]] = alloca , align 16
+// CHECK-NEXT:[[U32X4:%.*]] = alloca , align 16
+// CHECK-NEXT:[[U64X4:%.*]] = alloca , align 16
+// CHECK-NEXT:[[F16X4:%.*]] = alloca , align 16
+// CHECK-NEXT:[[F32X4:%.*]] = alloca , align 16
+// CHECK-NEXT:[[F64X4:%.*]] = alloca , align 16
+// CHECK-NEXT:[[BF16X4:%.*]] = alloca , align 16
+// CHECK-NEXT:[[B8:%.*]] = alloca , align 2
+// CHECK-NEXT:[[B8X2:%.*]] = alloca , align 2
+// CHECK-NEXT:[[B8X4:%.*]] = alloca , align 2
+// CHECK-NEXT:store  zeroinitializer, ptr [[S8]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[S16]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[S32]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[S64]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[U8]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[U16]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[U32]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[U64]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[F16]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[F32]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[F64]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[BF16]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[S8X2]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[S16X2]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[S32X2]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[X64X2]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[U8X2]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[U16X2]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[U32X2]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[U64X2]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[F16X2]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[F32X2]], align 16
+// CHECK-NEXT:store

[PATCH] D153170: [RISCV] Sort the extensions in SupportedExtensions and SupportedExperimentalExtensions.

[Jessica Clarke via Phabricator via cfe-commits]

jrtc27 added a comment.

Can we have an expensive check that the table is sorted?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153170

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

[PATCH] D149443: [ARM] add Thumb-1 8-bit movs/adds relocations to LLVM

[Ties Stuij 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 rGdc49fbd2df7d: [ARM] add Thumb-1 8-bit movs/adds relocations 
to LLVM (authored by stuij).

Changed prior to commit:
  https://reviews.llvm.org/D149443?vs=533190&id=533630#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D149443

Files:
  llvm/include/llvm/BinaryFormat/ELFRelocs/ARM.def
  llvm/lib/Target/ARM/ARMInstrInfo.td
  llvm/lib/Target/ARM/ARMInstrThumb.td
  llvm/lib/Target/ARM/AsmParser/ARMAsmParser.cpp
  llvm/lib/Target/ARM/MCTargetDesc/ARMAsmBackend.cpp
  llvm/lib/Target/ARM/MCTargetDesc/ARMELFObjectWriter.cpp
  llvm/lib/Target/ARM/MCTargetDesc/ARMFixupKinds.h
  llvm/lib/Target/ARM/MCTargetDesc/ARMMCCodeEmitter.cpp
  llvm/lib/Target/ARM/MCTargetDesc/ARMMCExpr.cpp
  llvm/lib/Target/ARM/MCTargetDesc/ARMMCExpr.h
  llvm/test/MC/ARM/negative-immediates-thumb1-fail.s
  llvm/test/MC/ARM/thumb-8-bit-relocs.s
  llvm/test/MC/ARM/thumb-diagnostics.s
  llvm/test/MC/ARM/thumb-fixups.s

Index: llvm/test/MC/ARM/thumb-fixups.s
===
--- /dev/null
+++ llvm/test/MC/ARM/thumb-fixups.s
@@ -0,0 +1,25 @@
+@ RUN: llvm-mc -triple armv6m-unknown-unknown %s --show-encoding -o - | \
+@ RUN:   FileCheck %s
+
+movs r3, :upper8_15:_foo
+adds r3, :upper0_7:_foo
+adds r3, :lower8_15:_foo
+adds r3, :lower0_7:_foo
+
+@ CHECK:  movsr3, :upper8_15:_foo @ encoding: [A,0x23]
+@ CHECK-NEXT: @   fixup A - offset: 0, value: _foo, kind: fixup_arm_thumb_upper_8_15
+@ CHECK-NEXT: addsr3, :upper0_7:_foo  @ encoding: [A,0x33]
+@ CHECK-NEXT: @   fixup A - offset: 0, value: _foo, kind: fixup_arm_thumb_upper_0_7
+@ CHECK-NEXT: addsr3, :lower8_15:_foo @ encoding: [A,0x33]
+@ CHECK-NEXT: @   fixup A - offset: 0, value: _foo, kind: fixup_arm_thumb_lower_8_15
+@ CHECK-NEXT: addsr3, :lower0_7:_foo  @ encoding: [A,0x33]
+@ CHECK-NEXT: @   fixup A - offset: 0, value: _foo, kind: fixup_arm_thumb_lower_0_7
+
+@ GNU syntax variants:
+movs r3, #:upper8_15:#_foo
+movs r3, #:upper8_15:_foo
+
+@ CHECK:  movsr3, :upper8_15:_foo @ encoding: [A,0x23]
+@ CHECK-NEXT: @   fixup A - offset: 0, value: _foo, kind: fixup_arm_thumb_upper_8_15
+@ CHECK-NEXT: movsr3, :upper8_15:_foo @ encoding: [A,0x23]
+@ CHECK-NEXT: @   fixup A - offset: 0, value: _foo, kind: fixup_arm_thumb_upper_8_15
Index: llvm/test/MC/ARM/thumb-diagnostics.s
===
--- llvm/test/MC/ARM/thumb-diagnostics.s
+++ llvm/test/MC/ARM/thumb-diagnostics.s
@@ -195,6 +195,34 @@
 @ CHECK-ERRORS: note: operand must be an immediate in the range [0,31]
 @ CHECK-ERRORS: note: too many operands for instruction
 
+@ Out of range immediates for MOVS/ADDS instruction.
+movs r3, #-1
+adds r3, #256
+@ CHECK-ERRORS: error: invalid instruction, any one of the following would fix this:
+@ CHECK-ERRORS-NEXT: movs r3, #-1
+@ CHECK-ERRORS-NEXT: ^
+@ CHECK-ERRORS: note: operand must be an immediate in the range [0,255] or a relocatable expression
+@ CHECK-ERRORS-NEXT: movs r3, #-1
+@ CHECK-ERRORS-NEXT:  ^
+@ CHECK-ERRORS: note: operand must be a register in range [r0, r7]
+@ CHECK-ERRORS-NEXT: movs r3, #-1
+@ CHECK-ERRORS-NEXT:  ^
+@ CHECK-ERRORS: error: invalid instruction, any one of the following would fix this:
+@ CHECK-ERRORS-NEXT: adds r3, #256
+@ CHECK-ERRORS-NEXT: ^
+@ CHECK-ERRORS: note: instruction requires: thumb2
+@ CHECK-ERRORS-NEXT: adds r3, #256
+@ CHECK-ERRORS-NEXT: ^
+@ CHECK-ERRORS: note: invalid operand for instruction
+@ CHECK-ERRORS-NEXT: adds r3, #256
+@ CHECK-ERRORS-NEXT:  ^
+@ CHECK-ERRORS-NEXT: note: operand must be an immediate in the range [0,255] or a relocatable expression
+@ CHECK-ERRORS-NEXT: adds r3, #256
+@ CHECK-ERRORS-NEXT:  ^
+@ CHECK-ERRORS-NEXT: note: operand must be a register in range [r0, r7]
+@ CHECK-ERRORS-NEXT: adds r3, #256
+@ CHECK-ERRORS-NEXT:  ^
+
 @ Mismatched source/destination operands for MUL instruction.
 muls r1, r2, r3
 @ CHECK-ERRORS: error: destination register must match source register
Index: llvm/test/MC/ARM/thumb-8-bit-relocs.s
===
--- /dev/null
+++ llvm/test/MC/ARM/thumb-8-bit-relocs.s
@@ -0,0 +1,35 @@
+@ RUN: llvm-mc -triple thumbv6m-eabi -o - %s | FileCheck %s
+@ RUN: llvm-mc -triple thumbv6m-eabi -filetype obj -o - %s | llvm-readobj -r - \
+@ RUN:   | FileCheck -check-prefix CHECK-RELOCATIONS %s
+@ RUN: llvm-mc -triple thumbv7m-eabi -o - %s | FileCheck %s
+@ RUN: llvm-mc -triple thumbv7m-eabi -filetype obj -o - %s | llvm-readobj -r - \
+@ RUN:   | FileCheck -check-prefix CHECK-RELOCATIONS %s
+
+.syntax unified
+
+.type function,%function
+function:
+  bx lr
+
+.g

[PATCH] D153468: [clang][LTO] Add flag to run verifier after every pass

[Teresa Johnson via Phabricator via cfe-commits]

tejohnson accepted this revision.
tejohnson 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/D153468/new/

https://reviews.llvm.org/D153468

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

[PATCH] D153560: [Clang] Allow C++11 style initialisation of SVE types.

[Paul Walker via Phabricator via cfe-commits]

paulwalker-arm updated this revision to Diff 533631.
paulwalker-arm added a comment.

Renamed test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153560

Files:
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/test/CodeGenCXX/aarch64-sve-vector-init.cpp

Index: clang/test/CodeGenCXX/aarch64-sve-vector-init.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/aarch64-sve-vector-init.cpp
@@ -0,0 +1,167 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py UTC_ARGS: --version 2
+// RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve -emit-llvm -o - %s | FileCheck %s
+
+// CHECK-LABEL: define dso_local void @_Z11test_localsv
+// CHECK-SAME: () #[[ATTR0:[0-9]+]] {
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[S8:%.*]] = alloca , align 16
+// CHECK-NEXT:[[S16:%.*]] = alloca , align 16
+// CHECK-NEXT:[[S32:%.*]] = alloca , align 16
+// CHECK-NEXT:[[S64:%.*]] = alloca , align 16
+// CHECK-NEXT:[[U8:%.*]] = alloca , align 16
+// CHECK-NEXT:[[U16:%.*]] = alloca , align 16
+// CHECK-NEXT:[[U32:%.*]] = alloca , align 16
+// CHECK-NEXT:[[U64:%.*]] = alloca , align 16
+// CHECK-NEXT:[[F16:%.*]] = alloca , align 16
+// CHECK-NEXT:[[F32:%.*]] = alloca , align 16
+// CHECK-NEXT:[[F64:%.*]] = alloca , align 16
+// CHECK-NEXT:[[BF16:%.*]] = alloca , align 16
+// CHECK-NEXT:[[S8X2:%.*]] = alloca , align 16
+// CHECK-NEXT:[[S16X2:%.*]] = alloca , align 16
+// CHECK-NEXT:[[S32X2:%.*]] = alloca , align 16
+// CHECK-NEXT:[[X64X2:%.*]] = alloca , align 16
+// CHECK-NEXT:[[U8X2:%.*]] = alloca , align 16
+// CHECK-NEXT:[[U16X2:%.*]] = alloca , align 16
+// CHECK-NEXT:[[U32X2:%.*]] = alloca , align 16
+// CHECK-NEXT:[[U64X2:%.*]] = alloca , align 16
+// CHECK-NEXT:[[F16X2:%.*]] = alloca , align 16
+// CHECK-NEXT:[[F32X2:%.*]] = alloca , align 16
+// CHECK-NEXT:[[F64X2:%.*]] = alloca , align 16
+// CHECK-NEXT:[[BF16X2:%.*]] = alloca , align 16
+// CHECK-NEXT:[[S8X3:%.*]] = alloca , align 16
+// CHECK-NEXT:[[S16X3:%.*]] = alloca , align 16
+// CHECK-NEXT:[[S32X3:%.*]] = alloca , align 16
+// CHECK-NEXT:[[X64X3:%.*]] = alloca , align 16
+// CHECK-NEXT:[[U8X3:%.*]] = alloca , align 16
+// CHECK-NEXT:[[U16X3:%.*]] = alloca , align 16
+// CHECK-NEXT:[[U32X3:%.*]] = alloca , align 16
+// CHECK-NEXT:[[U64X3:%.*]] = alloca , align 16
+// CHECK-NEXT:[[F16X3:%.*]] = alloca , align 16
+// CHECK-NEXT:[[F32X3:%.*]] = alloca , align 16
+// CHECK-NEXT:[[F64X3:%.*]] = alloca , align 16
+// CHECK-NEXT:[[BF16X3:%.*]] = alloca , align 16
+// CHECK-NEXT:[[S8X4:%.*]] = alloca , align 16
+// CHECK-NEXT:[[S16X4:%.*]] = alloca , align 16
+// CHECK-NEXT:[[S32X4:%.*]] = alloca , align 16
+// CHECK-NEXT:[[X64X4:%.*]] = alloca , align 16
+// CHECK-NEXT:[[U8X4:%.*]] = alloca , align 16
+// CHECK-NEXT:[[U16X4:%.*]] = alloca , align 16
+// CHECK-NEXT:[[U32X4:%.*]] = alloca , align 16
+// CHECK-NEXT:[[U64X4:%.*]] = alloca , align 16
+// CHECK-NEXT:[[F16X4:%.*]] = alloca , align 16
+// CHECK-NEXT:[[F32X4:%.*]] = alloca , align 16
+// CHECK-NEXT:[[F64X4:%.*]] = alloca , align 16
+// CHECK-NEXT:[[BF16X4:%.*]] = alloca , align 16
+// CHECK-NEXT:[[B8:%.*]] = alloca , align 2
+// CHECK-NEXT:[[B8X2:%.*]] = alloca , align 2
+// CHECK-NEXT:[[B8X4:%.*]] = alloca , align 2
+// CHECK-NEXT:store  zeroinitializer, ptr [[S8]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[S16]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[S32]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[S64]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[U8]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[U16]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[U32]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[U64]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[F16]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[F32]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[F64]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[BF16]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[S8X2]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[S16X2]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[S32X2]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[X64X2]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[U8X2]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[U16X2]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[U32X2]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[U64X2]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[F16X2]], align 16
+// CHECK-NEXT:store  zeroinitializer, ptr [[F32X2]], align 16
+// CH

[PATCH] D153294: [clang] Do not create ExprWithCleanups while checking immediate invocation

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov added a comment.

In D153294#4437381 , @Fznamznon wrote:

> In fact, I can't come up with the test that this patch would break. Either 
> `ExprWithCleanups` is redundant or added by different parts of Sema.

Same here, maybe @rsmith can come up with something that breaks.
The AST does seem off for this example:

  struct A {
  int *p = new int(42);
  consteval int get() const {
  return *p;
  }
  constexpr ~A() {
  delete p;
  }
  };
  
  int k = A().get() + 1;

With the patch we get `ExprWithCleanups` under `VarDecl`:

  `-VarDecl 0x56375b44f7b0  col:5 k 'int' cinit
`-ExprWithCleanups 0x56375b44fef0  'int'
  `-BinaryOperator 0x56375b44fed0  'int' '+'
|-ConstantExpr 0x56375b44fe90  'int'
| `-CXXMemberCallExpr 0x56375b44fe58  'int'
|   `-MemberExpr 0x56375b44fe28  '' .get 0x56375b42f028
| `-ImplicitCastExpr 0x56375b44fe78  'const A' 
xvalue 
|   `-MaterializeTemporaryExpr 0x56375b44fe10  
'A':'A' xvalue
| `-CXXBindTemporaryExpr 0x56375b44fdf0  'A':'A' 
(CXXTemporary 0x56375b44fdf0)
|   `-CXXTemporaryObjectExpr 0x56375b44fdb8  
'A':'A' 'void () noexcept(false)' zeroing
`-IntegerLiteral 0x56375b44feb0  'int' 1

But per Richard's comments `ConstantExpr` is a full expression and the cleanups 
should be under it instead (see godbolt  
for what's happening today).
From playing around with it, I couldn't find anything where this affects either 
codegen or diagnostics.

I think that's because any temporaries produced must have constexpr or trivial 
destructors, so they don't produce any code. Additionally, there seems to be no 
way for those temporaries to escape the immediate invocation.

I would guess we are still not comfortable with moving `ExprWithCleanups` 
outside `ConstantExpr`, but let's wait for Richard's comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153294

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

[PATCH] D153510: [Clang] Check type support for local variable declaration

[Craig Topper via Phabricator via cfe-commits]

craig.topper added a comment.

@aaron.ballman The backend crashes at -O0 when scalable vector variables are 
declared because the stack frame code doesn't expect to see them when the 
vector extension isn't enabled.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153510

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

[clang] da7f212 - [clang][LTO] Add flag to run verifier after every pass

[Arthur Eubanks via cfe-commits]

Author: Arthur Eubanks
Date: 2023-06-22T08:51:29-07:00
New Revision: da7f212f4a7ac8d99c9368770b9af3b628fd4e9f

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

LOG: [clang][LTO] Add flag to run verifier after every pass

Helps with debugging issues caught by the verifier.

Plumbed through both normal clang compile and ThinLTO.

Reviewed By: tejohnson

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

Added: 
clang/test/CodeGen/verify-each.c

Modified: 
clang/include/clang/Basic/CodeGenOptions.def
clang/include/clang/Driver/Options.td
clang/lib/CodeGen/BackendUtil.cpp
llvm/include/llvm/LTO/Config.h
llvm/lib/LTO/LTOBackend.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/CodeGenOptions.def 
b/clang/include/clang/Basic/CodeGenOptions.def
index c45fb132685c2..5b18f45a04ab1 100644
--- a/clang/include/clang/Basic/CodeGenOptions.def
+++ b/clang/include/clang/Basic/CodeGenOptions.def
@@ -322,6 +322,8 @@ CODEGENOPT(UseRegisterSizedBitfieldAccess , 1, 0)
 
 CODEGENOPT(VerifyModule  , 1, 1) ///< Control whether the module should be 
run
  ///< through the LLVM Verifier.
+CODEGENOPT(VerifyEach, 1, 1) ///< Control whether the LLVM verifier
+ ///< should run after every pass.
 
 CODEGENOPT(StackRealignment  , 1, 0) ///< Control whether to force stack
  ///< realignment.

diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 53c107b0f0fb0..b90d6763d6f3c 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -5738,6 +5738,9 @@ def as_secure_log_file : Separate<["-"], 
"as-secure-log-file">,
 
 let Flags = [CC1Option, NoDriverOption] in {
 
+def llvm_verify_each : Flag<["-"], "llvm-verify-each">,
+  HelpText<"Run the LLVM verifier after every LLVM pass">,
+  MarshallingInfoFlag>;
 def disable_llvm_verifier : Flag<["-"], "disable-llvm-verifier">,
   HelpText<"Don't run the LLVM IR verifier pass">,
   MarshallingInfoNegativeFlag>;

diff  --git a/clang/lib/CodeGen/BackendUtil.cpp 
b/clang/lib/CodeGen/BackendUtil.cpp
index 73cd4a62f5d3e..f7a174a5fe462 100644
--- a/clang/lib/CodeGen/BackendUtil.cpp
+++ b/clang/lib/CodeGen/BackendUtil.cpp
@@ -839,7 +839,7 @@ void EmitAssemblyHelper::RunOptimizationPipeline(
   StandardInstrumentations SI(
   TheModule->getContext(),
   (CodeGenOpts.DebugPassManager || DebugPassStructure),
-  /*VerifyEach*/ false, PrintPassOpts);
+  CodeGenOpts.VerifyEach, PrintPassOpts);
   SI.registerCallbacks(PIC, &MAM);
   PassBuilder PB(TM.get(), PTO, PGOOpt, &PIC);
 
@@ -1192,6 +1192,7 @@ static void runThinLTOBackend(
 
   Conf.ProfileRemapping = std::move(ProfileRemapping);
   Conf.DebugPassManager = CGOpts.DebugPassManager;
+  Conf.VerifyEach = CGOpts.VerifyEach;
   Conf.RemarksWithHotness = CGOpts.DiagnosticsWithHotness;
   Conf.RemarksFilename = CGOpts.OptRecordFile;
   Conf.RemarksPasses = CGOpts.OptRecordPasses;

diff  --git a/clang/test/CodeGen/verify-each.c 
b/clang/test/CodeGen/verify-each.c
new file mode 100644
index 0..328b846508920
--- /dev/null
+++ b/clang/test/CodeGen/verify-each.c
@@ -0,0 +1,19 @@
+// Test to ensure -llvm-verify-each works.
+// REQUIRES: x86-registered-target
+
+// RUN: %clang_cc1 -O2 -o /dev/null -triple x86_64-unknown-linux-gnu 
-emit-llvm-bc %s -fdebug-pass-manager 2>&1 | FileCheck %s --check-prefix=NO
+// NO-NOT: Verifying
+
+// RUN: %clang_cc1 -O2 -o /dev/null -triple x86_64-unknown-linux-gnu 
-emit-llvm-bc %s -fdebug-pass-manager -llvm-verify-each 2>&1 | FileCheck %s
+
+// RUN: %clang_cc1 -O2 -o %t.o -flto=thin -triple x86_64-unknown-linux-gnu 
-emit-llvm-bc %s -fdebug-pass-manager -llvm-verify-each 2>&1 | FileCheck %s
+// RUN: llvm-lto -thinlto -o %t %t.o
+
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-obj -O2 -o /dev/null 
-x ir %t.o -fthinlto-index=%t.thinlto.bc -fdebug-pass-manager -llvm-verify-each 
2>&1 | FileCheck %s
+
+// CHECK: Verifying function foo
+// CHECK: Running pass: InstCombinePass
+// CHECK: Verifying function foo
+
+void foo(void) {
+}

diff  --git a/llvm/include/llvm/LTO/Config.h b/llvm/include/llvm/LTO/Config.h
index e3c25117a020f..5c23ba4f7ac49 100644
--- a/llvm/include/llvm/LTO/Config.h
+++ b/llvm/include/llvm/LTO/Config.h
@@ -57,6 +57,7 @@ struct Config {
   CodeGenOpt::Level CGOptLevel = CodeGenOpt::Default;
   CodeGenFileType CGFileType = CGFT_ObjectFile;
   unsigned OptLevel = 2;
+  bool VerifyEach = false;
   bool DisableVerify = false;
 
   /// Use the standard optimization pipeline.

diff  --git a/llvm/lib/LTO/LTOBackend.cpp b/llvm/lib/LTO/LTOBackend.cpp
index 667ebb0c43320..4d9077924c67d 100644
--- a/llvm/lib/LTO/LTOBackend.cpp
+++ 

[PATCH] D153468: [clang][LTO] Add flag to run verifier after every pass

[Arthur Eubanks 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 rGda7f212f4a7a: [clang][LTO] Add flag to run verifier after 
every pass (authored by aeubanks).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153468

Files:
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/BackendUtil.cpp
  clang/test/CodeGen/verify-each.c
  llvm/include/llvm/LTO/Config.h
  llvm/lib/LTO/LTOBackend.cpp


Index: llvm/lib/LTO/LTOBackend.cpp
===
--- llvm/lib/LTO/LTOBackend.cpp
+++ llvm/lib/LTO/LTOBackend.cpp
@@ -259,7 +259,8 @@
   ModuleAnalysisManager MAM;
 
   PassInstrumentationCallbacks PIC;
-  StandardInstrumentations SI(Mod.getContext(), Conf.DebugPassManager);
+  StandardInstrumentations SI(Mod.getContext(), Conf.DebugPassManager,
+  Conf.VerifyEach);
   SI.registerCallbacks(PIC, &MAM);
   PassBuilder PB(TM, Conf.PTO, PGOOpt, &PIC);
 
Index: llvm/include/llvm/LTO/Config.h
===
--- llvm/include/llvm/LTO/Config.h
+++ llvm/include/llvm/LTO/Config.h
@@ -57,6 +57,7 @@
   CodeGenOpt::Level CGOptLevel = CodeGenOpt::Default;
   CodeGenFileType CGFileType = CGFT_ObjectFile;
   unsigned OptLevel = 2;
+  bool VerifyEach = false;
   bool DisableVerify = false;
 
   /// Use the standard optimization pipeline.
Index: clang/test/CodeGen/verify-each.c
===
--- /dev/null
+++ clang/test/CodeGen/verify-each.c
@@ -0,0 +1,19 @@
+// Test to ensure -llvm-verify-each works.
+// REQUIRES: x86-registered-target
+
+// RUN: %clang_cc1 -O2 -o /dev/null -triple x86_64-unknown-linux-gnu 
-emit-llvm-bc %s -fdebug-pass-manager 2>&1 | FileCheck %s --check-prefix=NO
+// NO-NOT: Verifying
+
+// RUN: %clang_cc1 -O2 -o /dev/null -triple x86_64-unknown-linux-gnu 
-emit-llvm-bc %s -fdebug-pass-manager -llvm-verify-each 2>&1 | FileCheck %s
+
+// RUN: %clang_cc1 -O2 -o %t.o -flto=thin -triple x86_64-unknown-linux-gnu 
-emit-llvm-bc %s -fdebug-pass-manager -llvm-verify-each 2>&1 | FileCheck %s
+// RUN: llvm-lto -thinlto -o %t %t.o
+
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-obj -O2 -o /dev/null 
-x ir %t.o -fthinlto-index=%t.thinlto.bc -fdebug-pass-manager -llvm-verify-each 
2>&1 | FileCheck %s
+
+// CHECK: Verifying function foo
+// CHECK: Running pass: InstCombinePass
+// CHECK: Verifying function foo
+
+void foo(void) {
+}
Index: clang/lib/CodeGen/BackendUtil.cpp
===
--- clang/lib/CodeGen/BackendUtil.cpp
+++ clang/lib/CodeGen/BackendUtil.cpp
@@ -839,7 +839,7 @@
   StandardInstrumentations SI(
   TheModule->getContext(),
   (CodeGenOpts.DebugPassManager || DebugPassStructure),
-  /*VerifyEach*/ false, PrintPassOpts);
+  CodeGenOpts.VerifyEach, PrintPassOpts);
   SI.registerCallbacks(PIC, &MAM);
   PassBuilder PB(TM.get(), PTO, PGOOpt, &PIC);
 
@@ -1192,6 +1192,7 @@
 
   Conf.ProfileRemapping = std::move(ProfileRemapping);
   Conf.DebugPassManager = CGOpts.DebugPassManager;
+  Conf.VerifyEach = CGOpts.VerifyEach;
   Conf.RemarksWithHotness = CGOpts.DiagnosticsWithHotness;
   Conf.RemarksFilename = CGOpts.OptRecordFile;
   Conf.RemarksPasses = CGOpts.OptRecordPasses;
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -5738,6 +5738,9 @@
 
 let Flags = [CC1Option, NoDriverOption] in {
 
+def llvm_verify_each : Flag<["-"], "llvm-verify-each">,
+  HelpText<"Run the LLVM verifier after every LLVM pass">,
+  MarshallingInfoFlag>;
 def disable_llvm_verifier : Flag<["-"], "disable-llvm-verifier">,
   HelpText<"Don't run the LLVM IR verifier pass">,
   MarshallingInfoNegativeFlag>;
Index: clang/include/clang/Basic/CodeGenOptions.def
===
--- clang/include/clang/Basic/CodeGenOptions.def
+++ clang/include/clang/Basic/CodeGenOptions.def
@@ -322,6 +322,8 @@
 
 CODEGENOPT(VerifyModule  , 1, 1) ///< Control whether the module should be 
run
  ///< through the LLVM Verifier.
+CODEGENOPT(VerifyEach, 1, 1) ///< Control whether the LLVM verifier
+ ///< should run after every pass.
 
 CODEGENOPT(StackRealignment  , 1, 0) ///< Control whether to force stack
  ///< realignment.


Index: llvm/lib/LTO/LTOBackend.cpp
===
--- llvm/lib/LTO/LTOBackend.cpp
+++ llvm/lib/LTO/LTOBackend.cpp
@@ -259,7 +259,8 @@
   ModuleAnalysisManager MAM;
 
   PassInstrumentationCallbacks PIC

[PATCH] D152435: [analyzer][CStringChecker] Adjust the invalidation operation on the super region of the destination buffer during string copy

[Balázs Benics via Phabricator via cfe-commits]

steakhal added a comment.

In D152435#4433147 , @OikawaKirie 
wrote:

> BTW, what does the `Done` checkbox mean in the code comments?

"Done" means "Resolved" on GitHub - which is basically that some action was 
taken or the person who raised the issue withdrew.
In general, no revision/pull request should be merged with having 
open/unresolved discussions.
Usually, the patch author marks comments as "Done" and on the next update (by 
pressing the "Submit" button) all those threads will be closed automatically.




Comment at: clang/lib/StaticAnalyzer/Checkers/CStringChecker.cpp:286-287
+  SVal V,
+  std::function);
 

OikawaKirie wrote:
> steakhal wrote:
> > I'd highly suggest making this a template taking the functor that way.
> > Given that we modify these functions, we should make them comply with the 
> > lower camel case naming convention.
> > And their variables with upper camel case.
> > I'd highly suggest making this a template taking the functor that way.
> 
> Any examples?
> Do you mean
> ```
> template 
> static ProgramStateRef
> InvalidateBufferAux(CheckerContext &C, ProgramStateRef state, const Expr *Ex,
> SVal V, std::function CallBack);
> ```
My problem is that `std::function` owns the callback, and really likely to 
allocate for doing so.
And in this context a more lightweight approach would be also good.
What I had in mind was:
```lang=C++
template 
static ProgramStateRef
InvalidateBufferAux(CheckerContext &C, ProgramStateRef state, const Expr *Ex,
SVal V, Callback F);
...
bool asd = F(a, b);
```

But actually, `llvm::function_ref` would be probably even better, so use that 
instead.
Also, add some comments on what the callback's return type means etc.



Comment at: clang/lib/StaticAnalyzer/Checkers/CStringChecker.cpp:1054
+SVal SizeV, QualType SizeTy) {
+  return InvalidateBufferAux(
+  C, S, BufE, BufV,

OikawaKirie wrote:
> steakhal wrote:
> > Shouldn't we assert that `SizeV` is some known value or at least smaller 
> > than (or equal to) the extent of the buffer?
> The calls in `CStringChecker::evalCopyCommon` and 
> `CStringChecker::evalStrcpyCommon` seem to have chances able to pass an 
> unknown value. But I am not very sure about this.
> 
> If the `SizeV` is sure to be smaller or equal to the extent of the buffer, 
> the `IsFirstBufInBound` check seems useless.
> Maybe I need to dig deeper into the callers.
Indeed.



Comment at: clang/lib/StaticAnalyzer/Checkers/CStringChecker.cpp:1075-1077
+  [](RegionAndSymbolInvalidationTraits &, const MemRegion *R) {
+return MemRegion::FieldRegionKind == R->getKind();
+  });

OikawaKirie wrote:
> steakhal wrote:
> > The lambdas inline in the call look a bit messy. I would prefer declaring 
> > it and passing it as an argument separately.
> > This applies to the rest of the lambdas as well.
> > And their variables with upper camel case.
> 
> What about the variable names for the lambdas? Lower camel or upper camel?
> I cannot find the rules for named lambdas from the guidance 
> .
I think I asked the same question some time ago.
https://discourse.llvm.org/t/naming-lambdas-in-llvm-coding-standards/62689/3



Comment at: clang/test/Analysis/issue-55019.cpp:80-87
+  std::copy(p, p + 1, x.arr);
+
+  // FIXME: As we currently cannot know whether the copy overflows, the checker
+  // invalidates the entire `x` object. When the copy size through iterators
+  // can be correctly modeled, we can then update the verify direction from
+  // SymRegion to HeapSymRegion as this std::copy call never overflows and
+  // hence the pointer `x.ptr` shall not be invalidated.

OikawaKirie wrote:
> > So, you say that It should be `HeapSymRegion` instead because `x.arr` 
> > shouldn't be invalidated because the `std::copy` won't modify it. Right?
> 
> Yes, but just in this test case.
> 
> The size of `x.arr` is 4 and the copy length is 1, which means the call to 
> `std::copy` here never overflows.
> Therefore, we should not invalidate the super region `x` and keep `x.ptr` 
> still pointing to the original `HeapSymRegion` unchanged.
> However, the copy length computed through iterators is not modeled currently 
> in `CStringChecker::evalStdCopyCommon`, where 
> `InvalidateDestinationBufferAlwaysEscapeSuperRegion` is called.
> When it is modeled in the future, the function should call 
> `InvalidateDestinationBufferBySize` instead to make the invalidation of the 
> super region determined by the copy length to report potential leaks.
Makes sense. Thanks.


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

https://reviews.llvm.org/D152435

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

[PATCH] D153510: [Clang] Check type support for local variable declaration

[Craig Topper via Phabricator via cfe-commits]

craig.topper added inline comments.



Comment at: clang/lib/Sema/SemaDecl.cpp:8773
+
+  checkTypeSupport(T, NewVD->getLocation(), cast(CurContext));
 }

This feels heavy handed for not RISC-V vector types. Can we put the RISC-V code 
from checkTypeSupport in a function and call it?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153510

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

[PATCH] D152720: [clangd][ObjC] Support ObjC class rename from implementation decls

[David Goldman via Phabricator via cfe-commits]

dgoldman updated this revision to Diff 533640.
dgoldman added a comment.

Disable renaming categories


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D152720

Files:
  clang-tools-extra/clangd/FindTarget.cpp
  clang-tools-extra/clangd/SemanticHighlighting.cpp
  clang-tools-extra/clangd/refactor/Rename.cpp
  clang-tools-extra/clangd/unittests/RenameTests.cpp

Index: clang-tools-extra/clangd/unittests/RenameTests.cpp
===
--- clang-tools-extra/clangd/unittests/RenameTests.cpp
+++ clang-tools-extra/clangd/unittests/RenameTests.cpp
@@ -840,6 +840,20 @@
   foo('x');
 }
   )cpp",
+
+  // ObjC class with a category.
+  R"cpp(
+@interface [[Fo^o]]
+@end
+@implementation [[F^oo]]
+@end
+@interface [[Fo^o]] (Category)
+@end
+@implementation [[F^oo]] (Category)
+@end
+
+void func([[Fo^o]] *f) {}
+  )cpp",
   };
   llvm::StringRef NewName = "NewName";
   for (llvm::StringRef T : Tests) {
@@ -890,6 +904,14 @@
   )cpp",
"not a supported kind", HeaderFile},
 
+  {R"cpp(// disallow - category rename.
+@interface Foo
+@end
+@interface Foo (Cate^gory)
+@end
+  )cpp",
+   "not a supported kind", HeaderFile},
+
   {
   R"cpp(
  #define MACRO 1
@@ -1468,7 +1490,7 @@
 
 TEST(CrossFileRenameTests, WithUpToDateIndex) {
   MockCompilationDatabase CDB;
-  CDB.ExtraClangFlags = {"-xc++"};
+  CDB.ExtraClangFlags = {"-xobjective-c++"};
   // rename is runnning on all "^" points in FooH, and "[[]]" ranges are the
   // expected rename occurrences.
   struct Case {
@@ -1557,13 +1579,12 @@
 }
   )cpp",
   },
-  {
-  // virtual templated method
-  R"cpp(
+  {// virtual templated method
+   R"cpp(
 template  class Foo { virtual void [[m]](); };
 class Bar : Foo { void [[^m]]() override; };
   )cpp",
-  R"cpp(
+   R"cpp(
   #include "foo.h"
 
   template void Foo::[[m]]() {}
@@ -1571,8 +1592,7 @@
   // the canonical Foo::m().
   // https://github.com/clangd/clangd/issues/1325
   class Baz : Foo { void m() override; };
-)cpp"
-  },
+)cpp"},
   {
   // rename on constructor and destructor.
   R"cpp(
@@ -1677,6 +1697,20 @@
 }
   )cpp",
   },
+  {
+  // Objective-C classes.
+  R"cpp(
+@interface [[Fo^o]]
+@end
+  )cpp",
+  R"cpp(
+#include "foo.h"
+@implementation [[F^oo]]
+@end
+
+void func([[Foo]] *f) {}
+  )cpp",
+  },
   };
 
   trace::TestTracer Tracer;
Index: clang-tools-extra/clangd/refactor/Rename.cpp
===
--- clang-tools-extra/clangd/refactor/Rename.cpp
+++ clang-tools-extra/clangd/refactor/Rename.cpp
@@ -19,6 +19,7 @@
 #include "clang/AST/ASTTypeTraits.h"
 #include "clang/AST/Decl.h"
 #include "clang/AST/DeclCXX.h"
+#include "clang/AST/DeclObjC.h"
 #include "clang/AST/DeclTemplate.h"
 #include "clang/AST/ParentMapContext.h"
 #include "clang/AST/Stmt.h"
@@ -137,6 +138,10 @@
 if (const auto *TargetDecl = UD->getTargetDecl())
   return canonicalRenameDecl(TargetDecl);
   }
+  if (const auto *CD = dyn_cast(D)) {
+if (const auto CI = CD->getClassInterface())
+  return canonicalRenameDecl(CI);
+  }
   return dyn_cast(D->getCanonicalDecl());
 }
 
@@ -278,6 +283,10 @@
   if (Ref.Targets.empty())
 return;
   for (const auto *Target : Ref.Targets) {
+// Skip categories since we don't support renaming them, only
+// the interface(s) which they reference.
+if (isa(Target))
+  continue;
 if (canonicalRenameDecl(Target) == &ND) {
   Results.push_back(Ref.NameLoc);
   return;
@@ -773,6 +782,12 @@
   if (Invalid)
 return makeError(std::move(*Invalid));
 
+  // We don't support renaming the category name, only ObjC top level container
+  // names like class and protocol names.
+  if (const auto *CD = dyn_cast(&RenameDecl))
+if (CD->getName() != IdentifierToken->text(SM))
+  return makeError(ReasonToReject::UnsupportedSymbol);
+
   auto Reject =
   renameable(RenameDecl, RInputs.MainFilePath, RInputs.Index, Opts);
   if (Reject)
Index: clang-tools-extra/clangd/SemanticHighlighting.cpp
===
--- clang-tools-extra/clangd/SemanticHighlighting.cpp
+++ clang-tools-extra/clangd/SemanticHighlighting.cpp
@@ -128,7 +128,7 @@
 return HighlightingKind::Class;
   if (isa(D))
 return HighlightingKind::Interface;
-  if (isa(D))
+  if (isa(D))
 return HighlightingKind::Namespace;
   if (auto *MD = dyn_cast(D))

[PATCH] D153418: Adding iconv support to CharSetConverter class

[Eli Friedman via Phabricator via cfe-commits]

efriedma added a comment.

Even if we do decide we have to use platform-specific facilities because 
there's no suitable library, I think we should at least have a hardcoded set of 
encodings we recognize, so we aren't passing arbitrary encoding names directly 
from the command-line to the iconv() call.

Do you have a list of specific encodings you care about?

In D153418#4440420 , @cor3ntin wrote:

> In D153418#4438766 , @efriedma 
> wrote:
>
>> Can we use the existing conversion utilities in LLVM for UTF-16/UTF-32?
>
> Not sure how useful this would be, UTF-16/UTF-32 facilities are used directly 
> when they are needed, and utf-16 source input files are rare.

UTF-16 source files see some usage on Windows.  Not sure exactly how common it 
is, but I think certain versions of Visual Studio defaulted to UTF-16... 
obviously, people who know what they're doing avoid encoding their files that 
way.  I just noted it because some of the unit-tests were using UTF-16/UTF-32.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153418

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

[PATCH] D152263: [clang][CFG] Add support for partitioning CFG into intervals.

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

ymandel updated this revision to Diff 533641.
ymandel marked 2 inline comments as done.
ymandel added a comment.

responded to comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D152263

Files:
  clang/include/clang/Analysis/Analyses/IntervalPartition.h
  clang/lib/Analysis/CMakeLists.txt
  clang/lib/Analysis/IntervalPartition.cpp
  clang/unittests/Analysis/CMakeLists.txt
  clang/unittests/Analysis/IntervalPartitionTest.cpp

Index: clang/unittests/Analysis/IntervalPartitionTest.cpp
===
--- /dev/null
+++ clang/unittests/Analysis/IntervalPartitionTest.cpp
@@ -0,0 +1,164 @@
+//===- unittests/Analysis/IntervalPartitionTest.cpp ---===//
+//
+// 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 "clang/Analysis/Analyses/IntervalPartition.h"
+#include "CFGBuildResult.h"
+#include "gmock/gmock.h"
+#include "gtest/gtest.h"
+
+namespace clang {
+namespace analysis {
+namespace {
+
+TEST(BuildInterval, PartitionSimpleOneInterval) {
+
+  const char *Code = R"(void f() {
+  int x = 3;
+  int y = 7;
+  x = y + x;
+})";
+  BuildResult Result = BuildCFG(Code);
+  EXPECT_EQ(BuildResult::BuiltCFG, Result.getStatus());
+
+  CFG *cfg = Result.getCFG();
+
+  // Basic correctness checks.
+  ASSERT_EQ(cfg->size(), 3u);
+
+  auto &EntryBlock = cfg->getEntry();
+
+  CFGInterval I = buildInterval(EntryBlock);
+  EXPECT_EQ(I.Blocks.size(), 3u);
+}
+
+TEST(BuildInterval, PartitionIfThenOneInterval) {
+
+  const char *Code = R"(void f() {
+  int x = 3;
+  if (x > 3)
+x = 2;
+  else
+x = 7;
+  x = x + x;
+})";
+  BuildResult Result = BuildCFG(Code);
+  EXPECT_EQ(BuildResult::BuiltCFG, Result.getStatus());
+
+  CFG *cfg = Result.getCFG();
+
+  // Basic correctness checks.
+  ASSERT_EQ(cfg->size(), 6u);
+
+  auto &EntryBlock = cfg->getEntry();
+
+  CFGInterval I = buildInterval(EntryBlock);
+  EXPECT_EQ(I.Blocks.size(), 6u);
+}
+
+using ::testing::UnorderedElementsAre;
+
+TEST(BuildInterval, PartitionWhileMultipleIntervals) {
+
+  const char *Code = R"(void f() {
+  int x = 3;
+  while (x >= 3)
+--x;
+  x = x + x;
+})";
+  BuildResult Result = BuildCFG(Code);
+  ASSERT_EQ(BuildResult::BuiltCFG, Result.getStatus());
+
+  CFG *cfg = Result.getCFG();
+  ASSERT_EQ(cfg->size(), 7u);
+
+  auto *EntryBlock = &cfg->getEntry();
+  CFGBlock *InitXBlock = *EntryBlock->succ_begin();
+  CFGBlock *LoopHeadBlock = *InitXBlock->succ_begin();
+
+  CFGInterval I1 = buildInterval(*EntryBlock);
+  EXPECT_THAT(I1.Blocks, UnorderedElementsAre(EntryBlock, InitXBlock));
+
+  CFGInterval I2 = buildInterval(*LoopHeadBlock);
+  EXPECT_EQ(I2.Blocks.size(), 5u);
+}
+
+TEST(PartitionIntoIntervals, PartitionIfThenOneInterval) {
+  const char *Code = R"(void f() {
+  int x = 3;
+  if (x > 3)
+x = 2;
+  else
+x = 7;
+  x = x + x;
+})";
+  BuildResult Result = BuildCFG(Code);
+  ASSERT_EQ(BuildResult::BuiltCFG, Result.getStatus());
+
+  CFG *cfg = Result.getCFG();
+  ASSERT_EQ(cfg->size(), 6u);
+
+  auto Intervals = partitionIntoIntervals(*cfg);
+  EXPECT_EQ(Intervals.size(), 1u);
+}
+
+TEST(PartitionIntoIntervals, PartitionWhileTwoIntervals) {
+  const char *Code = R"(void f() {
+  int x = 3;
+  while (x >= 3)
+--x;
+  x = x + x;
+})";
+  BuildResult Result = BuildCFG(Code);
+  ASSERT_EQ(BuildResult::BuiltCFG, Result.getStatus());
+
+  CFG *cfg = Result.getCFG();
+  ASSERT_EQ(cfg->size(), 7u);
+
+  auto Intervals = partitionIntoIntervals(*cfg);
+  EXPECT_EQ(Intervals.size(), 2u);
+}
+
+TEST(PartitionIntoIntervals, PartitionNestedWhileThreeIntervals) {
+  const char *Code = R"(void f() {
+  int x = 3;
+  while (x >= 3) {
+--x;
+int y = x;
+while (y > 0) --y;
+  }
+  x = x + x;
+})";
+  BuildResult Result = BuildCFG(Code);
+  ASSERT_EQ(BuildResult::BuiltCFG, Result.getStatus(

[PATCH] D152263: [clang][CFG] Add support for partitioning CFG into intervals.

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

ymandel marked 2 inline comments as not done.
ymandel added inline comments.



Comment at: clang/lib/Analysis/IntervalPartition.cpp:26
+
+  std::queue Worklist;
+  for (const CFGBlock *S : Header.succs())

xazax.hun wrote:
> Is it possible we end up adding the same node to the queue multiple times? Is 
> that desirable or do we want to make sure we only have each node at most once?
Added an answer in comments, but repeating here in case you want to discuss 
further:

  // The worklist *may* contain duplicates. We guard against this possibility by
  // checking each popped element for completion (that is, presence in
  // `Partitioned`). We choose this approach over using a set because the queue
  // allows us to flexibly insert and delete elements while iterating through
  // the list. A set would require two separate phases for iterating and
  // mutation.



Comment at: clang/lib/Analysis/IntervalPartition.cpp:37
+  // successors.
+  std::vector MaybeSuccessors;
+

xazax.hun wrote:
> Same question here, is it possible we might end up adding the same nodes 
> multiple times? 
Added an answer in comments, but repeating here in case you want to discuss 
further:

  // It may contain duplicates -- ultimately, all relevant elements
  // are added to `Interval.Successors`, which is a set.



Comment at: clang/lib/Analysis/IntervalPartition.cpp:46-47
+
+// Check whether all predecessors are in the interval, in which case `B`
+// is included as well.
+bool AllInInterval = true;

xazax.hun wrote:
> I wonder if this approach is correct. Consider the following scenario:
> 
> ```
>A
>   / \
>  B   C
>  |   |
>  |   D
>   \ /
>E
> ```
> 
> In the BFS, we might visit: ABCED. Since we visit `E` before `D`, we might 
> not recognize that `E` is part of the interval. Do I miss something?
> I wonder if this approach is correct. Consider the following scenario:
> 
> ```
>A
>   / \
>  B   C
>  |   |
>  |   D
>   \ /
>E
> ```
> 
> In the BFS, we might visit: ABCED. Since we visit `E` before `D`, we might 
> not recognize that `E` is part of the interval. Do I miss something?

When we add `D` to the interval, we'll push `E` onto the queue again (lines 
58-59). The second time that `E` is considered it will have both successors in 
the interval and will be added as well.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D152263

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

[PATCH] D153430: [Clang][Driver] Warn on invalid Arm or AArch64 baremetal target triple

[Michael Platings via Phabricator via cfe-commits]

michaelplatings added a comment.

>selects the fallback GCC toolchain driver; did you mean 
> 

This is a correct description of the current behaviour, but I want to keep the 
freedom to change the behaviour in future. Therefore I'd like to avoid defining 
what behaviour an invalid target triple will cause.

> - Why is it invalid?

Fair question. I could rephrase to:

  clang: warning: mismatch between architecture and environment in target 
triple 'aarch64-none-eabi'; did you mean 'aarch64-none-elf'? 
[-Winvalid-command-line-argument]

Does that make it clearer? (I still suspect that people won't understand what 
is meant by "environment" here but I can't think of a better explanation).

> - I assumed it was an error message, and was about to write a comment until I 
> saw it was a warning.

It might not be clear in the code but `warning:` is automatically part of the 
output.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153430

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

[PATCH] D153228: [clang-format] Fixed bad performance with enabled qualifier fixer.

[Sedenion via Phabricator via cfe-commits]

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



Comment at: clang/lib/Format/Format.cpp:3571-3585
+  // Don't make replacements that replace nothing. This can affect e.g. the
+  // output of clang-format with the --output-replacements-xml option.
+  tooling::Replacements NonNoOpFixes;
+  for (const tooling::Replacement &Fix : Fixes) {
+StringRef OriginalCode = Code.substr(Fix.getOffset(), Fix.getLength());
+if (!OriginalCode.equals(Fix.getReplacementText())) {
+  auto Err = NonNoOpFixes.add(Fix);

owenpan wrote:
> You only need this for the `QualifierAlignment` passes as others (e.g. 
> `IntegerLiteralSeparatorFixer`) already skip no-op replacements.
Yes, in principle I need to do this only after all QualifierAlignment passes 
ran. The key point is that it needs to be done only after **all** 
QualifierAlignment passes ran. In other words, I cannot move this to 
`LeftRightQualifierAlignmentFixer::analyze()`; it would do nothing there. The 
non-no-op code exists so that if e.g. `const volatile` becomes `volatile const` 
in one pass and then again `const volatile` in another pass, we end up with no 
replacements.

I also cannot simply put all the QualifierAlignment passes into a simple 
dedicated loop that directly runs them after one another; the part with 
`applyAllReplacements()` etc (line 3554 till 3566 above) would be missing 
between the passes. I could, of course, extract lines 3554 till 3566 into a new 
function and call it in both places. Should I do that?

Or do you mean that I should wrap the NonNoOpFixes code in an `if 
(Style.QualifierAlignment != FormatStyle::QAS_Leave)`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153228

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

[clang] 08f1aa8 - [RISCV] Move Zca/Zcb/Zcd/Zcf/Zcmp/Zcmt out of experimental status.

[Craig Topper via cfe-commits]

Author: Craig Topper
Date: 2023-06-22T09:22:58-07:00
New Revision: 08f1aa87281f969bb5a46a780385819079067826

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

LOG: [RISCV] Move Zca/Zcb/Zcd/Zcf/Zcmp/Zcmt out of experimental status.

According to https://wiki.riscv.org/display/HOME/Recently+Ratified+Extensions
these were ratified in April 2023.

Reviewed By: VincentWu

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

Added: 


Modified: 
clang/test/Driver/riscv-arch.c
llvm/docs/RISCVUsage.rst
llvm/lib/Support/RISCVISAInfo.cpp
llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
llvm/lib/Target/RISCV/RISCVFeatures.td
llvm/test/CodeGen/RISCV/add-before-shl.ll
llvm/test/CodeGen/RISCV/attributes.ll
llvm/test/CodeGen/RISCV/cm_mvas_mvsa.ll
llvm/test/MC/RISCV/align.s
llvm/test/MC/RISCV/compress-rv32d.s
llvm/test/MC/RISCV/compress-rv32f.s
llvm/test/MC/RISCV/rv32c-aliases-valid.s
llvm/test/MC/RISCV/rv32c-invalid.s
llvm/test/MC/RISCV/rv32c-valid.s
llvm/test/MC/RISCV/rv32dc-valid.s
llvm/test/MC/RISCV/rv32fc-valid.s
llvm/test/MC/RISCV/rv32zcb-invalid.s
llvm/test/MC/RISCV/rv32zcb-valid.s
llvm/test/MC/RISCV/rv32zcmp-invalid.s
llvm/test/MC/RISCV/rv32zcmp-valid.s
llvm/test/MC/RISCV/rv32zcmt-invalid.s
llvm/test/MC/RISCV/rv32zcmt-valid.s
llvm/test/MC/RISCV/rv64c-aliases-valid.s
llvm/test/MC/RISCV/rv64c-hints-valid.s
llvm/test/MC/RISCV/rv64c-invalid.s
llvm/test/MC/RISCV/rv64c-valid.s
llvm/test/MC/RISCV/rv64dc-valid.s
llvm/test/MC/RISCV/rv64zcb-valid.s
llvm/test/MC/RISCV/rv64zcmp-invalid.s
llvm/test/MC/RISCV/rv64zcmp-valid.s
llvm/test/MC/RISCV/rvzcmt-user-csr-name.s

Removed: 




diff  --git a/clang/test/Driver/riscv-arch.c b/clang/test/Driver/riscv-arch.c
index 848fc14dc95e7..8929d88e92c23 100644
--- a/clang/test/Driver/riscv-arch.c
+++ b/clang/test/Driver/riscv-arch.c
@@ -373,24 +373,24 @@
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-ZFHMIN %s
 // RV32-ZFHMIN: "-target-feature" "+zfhmin"
 
-// RUN: %clang --target=riscv32-unknown-elf -march=rv32izca -### %s \
+// RUN: %clang --target=riscv32-unknown-elf -march=rv32izfa -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-EXPERIMENTAL-NOFLAG 
%s
-// RV32-EXPERIMENTAL-NOFLAG: error: invalid arch name 'rv32izca'
+// RV32-EXPERIMENTAL-NOFLAG: error: invalid arch name 'rv32izfa'
 // RV32-EXPERIMENTAL-NOFLAG: requires '-menable-experimental-extensions'
 
-// RUN: %clang --target=riscv32-unknown-elf -march=rv32izca 
-menable-experimental-extensions -### %s \
+// RUN: %clang --target=riscv32-unknown-elf -march=rv32izfa 
-menable-experimental-extensions -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-EXPERIMENTAL-NOVERS 
%s
-// RV32-EXPERIMENTAL-NOVERS: error: invalid arch name 'rv32izca'
+// RV32-EXPERIMENTAL-NOVERS: error: invalid arch name 'rv32izfa'
 // RV32-EXPERIMENTAL-NOVERS: experimental extension requires explicit version 
number
 
-// RUN: %clang --target=riscv32-unknown-elf -march=rv32izca0p1 
-menable-experimental-extensions -### %s \
+// RUN: %clang --target=riscv32-unknown-elf -march=rv32izfa0p1 
-menable-experimental-extensions -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-EXPERIMENTAL-BADVERS 
%s
-// RV32-EXPERIMENTAL-BADVERS: error: invalid arch name 'rv32izca0p1'
-// RV32-EXPERIMENTAL-BADVERS: unsupported version number 0.1 for experimental 
extension 'zca' (this compiler supports 1.0)
+// RV32-EXPERIMENTAL-BADVERS: error: invalid arch name 'rv32izfa0p1'
+// RV32-EXPERIMENTAL-BADVERS: unsupported version number 0.1 for experimental 
extension 'zfa' (this compiler supports 0.2)
 
-// RUN: %clang --target=riscv32-unknown-elf -march=rv32izca1p0 
-menable-experimental-extensions -### %s \
+// RUN: %clang --target=riscv32-unknown-elf -march=rv32izfa0p2 
-menable-experimental-extensions -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck 
-check-prefix=RV32-EXPERIMENTAL-GOODVERS %s
-// RV32-EXPERIMENTAL-GOODVERS: "-target-feature" "+experimental-zca"
+// RV32-EXPERIMENTAL-GOODVERS: "-target-feature" "+experimental-zfa"
 
 // RUN: %clang --target=riscv32-unknown-elf -march=rv32izbb1p0 -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-ZBB %s

diff  --git a/llvm/docs/RISCVUsage.rst b/llvm/docs/RISCVUsage.rst
index 5bf622cf44c06..4fcc5bc032b33 100644
--- a/llvm/docs/RISCVUsage.rst
+++ b/llvm/docs/RISCVUsage.rst
@@ -100,6 +100,12 @@ on support follow.
  ``Zbkc`` Supported
  ``Zbkx`` Supported (`See note <#riscv-scalar-crypto-note1>`__)
  ``Zbs``  Supported
+ ``Zca``  Supported
+ ``Zcb``  Supported
+ ``Zcd``  Supported
+ ``Zcf``  Supported
+ ``Zcmp`` 

[PATCH] D153161: [RISCV] Move Zca/Zcb/Zcd/Zcf/Zcmp/Zcmt out of experimental status.

[Craig Topper 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 rG08f1aa87281f: [RISCV] Move Zca/Zcb/Zcd/Zcf/Zcmp/Zcmt out of 
experimental status. (authored by craig.topper).

Changed prior to commit:
  https://reviews.llvm.org/D153161?vs=532257&id=533648#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153161

Files:
  clang/test/Driver/riscv-arch.c
  llvm/docs/RISCVUsage.rst
  llvm/lib/Support/RISCVISAInfo.cpp
  llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
  llvm/lib/Target/RISCV/RISCVFeatures.td
  llvm/test/CodeGen/RISCV/add-before-shl.ll
  llvm/test/CodeGen/RISCV/attributes.ll
  llvm/test/CodeGen/RISCV/cm_mvas_mvsa.ll
  llvm/test/MC/RISCV/align.s
  llvm/test/MC/RISCV/compress-rv32d.s
  llvm/test/MC/RISCV/compress-rv32f.s
  llvm/test/MC/RISCV/rv32c-aliases-valid.s
  llvm/test/MC/RISCV/rv32c-invalid.s
  llvm/test/MC/RISCV/rv32c-valid.s
  llvm/test/MC/RISCV/rv32dc-valid.s
  llvm/test/MC/RISCV/rv32fc-valid.s
  llvm/test/MC/RISCV/rv32zcb-invalid.s
  llvm/test/MC/RISCV/rv32zcb-valid.s
  llvm/test/MC/RISCV/rv32zcmp-invalid.s
  llvm/test/MC/RISCV/rv32zcmp-valid.s
  llvm/test/MC/RISCV/rv32zcmt-invalid.s
  llvm/test/MC/RISCV/rv32zcmt-valid.s
  llvm/test/MC/RISCV/rv64c-aliases-valid.s
  llvm/test/MC/RISCV/rv64c-hints-valid.s
  llvm/test/MC/RISCV/rv64c-invalid.s
  llvm/test/MC/RISCV/rv64c-valid.s
  llvm/test/MC/RISCV/rv64dc-valid.s
  llvm/test/MC/RISCV/rv64zcb-valid.s
  llvm/test/MC/RISCV/rv64zcmp-invalid.s
  llvm/test/MC/RISCV/rv64zcmp-valid.s
  llvm/test/MC/RISCV/rvzcmt-user-csr-name.s

Index: llvm/test/MC/RISCV/rvzcmt-user-csr-name.s
===
--- llvm/test/MC/RISCV/rvzcmt-user-csr-name.s
+++ llvm/test/MC/RISCV/rvzcmt-user-csr-name.s
@@ -1,13 +1,13 @@
-# RUN: llvm-mc %s -triple=riscv32 -riscv-no-aliases -mattr=+experimental-zcmt -show-encoding \
+# RUN: llvm-mc %s -triple=riscv32 -riscv-no-aliases -mattr=+zcmt -show-encoding \
 # RUN: | FileCheck -check-prefixes=CHECK-INST,CHECK-ENC %s
-# RUN: llvm-mc -filetype=obj -triple riscv32 -mattr=+experimental-zcmt < %s \
-# RUN: | llvm-objdump -d --mattr=+experimental-zcmt - \
+# RUN: llvm-mc -filetype=obj -triple riscv32 -mattr=+zcmt < %s \
+# RUN: | llvm-objdump -d --mattr=+zcmt - \
 # RUN: | FileCheck -check-prefix=CHECK-INST-ALIAS %s
 #
-# RUN: llvm-mc %s -triple=riscv64 -riscv-no-aliases -mattr=+experimental-zcmt -show-encoding \
+# RUN: llvm-mc %s -triple=riscv64 -riscv-no-aliases -mattr=+zcmt -show-encoding \
 # RUN: | FileCheck -check-prefixes=CHECK-INST,CHECK-ENC %s
-# RUN: llvm-mc -filetype=obj -triple riscv64 -mattr=+experimental-zcmt < %s \
-# RUN: | llvm-objdump -d --mattr=+experimental-zcmt - \
+# RUN: llvm-mc -filetype=obj -triple riscv64 -mattr=+zcmt < %s \
+# RUN: | llvm-objdump -d --mattr=+zcmt - \
 # RUN: | FileCheck -check-prefix=CHECK-INST-ALIAS %s
 
 ##
Index: llvm/test/MC/RISCV/rv64zcmp-valid.s
===
--- llvm/test/MC/RISCV/rv64zcmp-valid.s
+++ llvm/test/MC/RISCV/rv64zcmp-valid.s
@@ -1,7 +1,7 @@
-# RUN: llvm-mc %s -triple=riscv64 -mattr=experimental-zcmp -riscv-no-aliases -show-encoding \
+# RUN: llvm-mc %s -triple=riscv64 -mattr=zcmp -riscv-no-aliases -show-encoding \
 # RUN: | FileCheck -check-prefixes=CHECK-ASM,CHECK-ASM-AND-OBJ %s
-# RUN: llvm-mc -filetype=obj -triple=riscv64 -mattr=experimental-zcmp < %s \
-# RUN: | llvm-objdump --mattr=-c,experimental-zcmp -M no-aliases -d -r - \
+# RUN: llvm-mc -filetype=obj -triple=riscv64 -mattr=zcmp < %s \
+# RUN: | llvm-objdump --mattr=-c,zcmp -M no-aliases -d -r - \
 # RUN: | FileCheck --check-prefixes=CHECK-ASM-AND-OBJ %s
 
 # CHECK-ASM-AND-OBJ: cm.mvsa01 s1, s0
Index: llvm/test/MC/RISCV/rv64zcmp-invalid.s
===
--- llvm/test/MC/RISCV/rv64zcmp-invalid.s
+++ llvm/test/MC/RISCV/rv64zcmp-invalid.s
@@ -1,4 +1,4 @@
-# RUN: not llvm-mc -triple=riscv64 -mattr=experimental-zcmp -riscv-no-aliases -show-encoding < %s 2>&1 \
+# RUN: not llvm-mc -triple=riscv64 -mattr=zcmp -riscv-no-aliases -show-encoding < %s 2>&1 \
 # RUN: | FileCheck -check-prefixes=CHECK-ERROR %s
 
 # CHECK-ERROR: error: invalid operand for instruction
Index: llvm/test/MC/RISCV/rv64zcb-valid.s
===
--- llvm/test/MC/RISCV/rv64zcb-valid.s
+++ llvm/test/MC/RISCV/rv64zcb-valid.s
@@ -1,13 +1,13 @@
-# RUN: llvm-mc %s -triple=riscv64 -mattr=+m,+zbb,+zba,+experimental-zcb -riscv-no-aliases -show-encoding \
+# RUN: llvm-mc %s -triple=riscv64 -mattr=+m,+zbb,+zba,+zcb -riscv-no-aliases -show-encoding \
 # RUN: | FileCheck -check-prefixes=CHECK-ASM,CHECK-ASM-AND-OBJ %s
-# RUN: llvm-mc -filetype=obj -triple=riscv64 -mattr=+m,+zbb,+zba,+experimental-zcb <

[PATCH] D153568: [ClangPackager] Add an option to extract inputs to an archive

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 created this revision.
jhuber6 added reviewers: JonChesterfield, tra, yaxunl, jdoerfert, 
tianshilei1992, ronlieb, gregrodgers.
Herald added a project: All.
jhuber6 requested review of this revision.
Herald added subscribers: cfe-commits, jplehr, sstefan1.
Herald added a project: clang.

Currently we simply overwrite the output file if we get muliple matches
in the fatbinary. This patch introduces the `--archive` option which
allows us to combine all of the files into a static archive instead.
This is usefuly for creating a device specific static archive library
from a fatbinary.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D153568

Files:
  clang/test/Driver/offload-packager.c
  clang/tools/clang-offload-packager/ClangOffloadPackager.cpp

Index: clang/tools/clang-offload-packager/ClangOffloadPackager.cpp
===
--- clang/tools/clang-offload-packager/ClangOffloadPackager.cpp
+++ clang/tools/clang-offload-packager/ClangOffloadPackager.cpp
@@ -15,6 +15,7 @@
 #include "clang/Basic/Version.h"
 
 #include "llvm/BinaryFormat/Magic.h"
+#include "llvm/Object/ArchiveWriter.h"
 #include "llvm/Object/OffloadBinary.h"
 #include "llvm/Support/CommandLine.h"
 #include "llvm/Support/FileOutputBuffer.h"
@@ -49,6 +50,14 @@
  cl::value_desc("=,..."),
  cl::cat(ClangOffloadPackagerCategory));
 
+static cl::opt
+CreateArchive("archive",
+  cl::desc("Write extracted files to a static archive"),
+  cl::cat(ClangOffloadPackagerCategory));
+
+/// Path of the current binary.
+static const char *PackagerExecutable;
+
 static void PrintVersion(raw_ostream &OS) {
   OS << clang::getClangToolFullVersion("clang-offload-packager") << '\n';
 }
@@ -69,6 +78,18 @@
   return Args;
 }
 
+static Error writeFile(StringRef Filename, StringRef Data) {
+  Expected> OutputOrErr =
+  FileOutputBuffer::create(Filename, Data.size());
+  if (!OutputOrErr)
+return OutputOrErr.takeError();
+  std::unique_ptr Output = std::move(*OutputOrErr);
+  llvm::copy(Data, Output->getBufferStart());
+  if (Error E = Output->commit())
+return E;
+  return Error::success();
+}
+
 static Error bundleImages() {
   SmallVector BinaryData;
   raw_svector_ostream OS(BinaryData);
@@ -111,13 +132,8 @@
 OS << Buffer->getBuffer();
   }
 
-  Expected> OutputOrErr =
-  FileOutputBuffer::create(OutputFile, BinaryData.size());
-  if (!OutputOrErr)
-return OutputOrErr.takeError();
-  std::unique_ptr Output = std::move(*OutputOrErr);
-  std::copy(BinaryData.begin(), BinaryData.end(), Output->getBufferStart());
-  if (Error E = Output->commit())
+  if (Error E = writeFile(OutputFile,
+  StringRef(BinaryData.begin(), BinaryData.size(
 return E;
   return Error::success();
 }
@@ -145,8 +161,9 @@
 StringSaver Saver(Alloc);
 auto Args = getImageArguments(Image, Saver);
 
-for (uint64_t I = 0, E = Binaries.size(); I != E; ++I) {
-  const auto *Binary = Binaries[I].getBinary();
+SmallVector Extracted;
+for (const OffloadFile &File : Binaries) {
+  const auto *Binary = File.getBinary();
   // We handle the 'file' and 'kind' identifiers differently.
   bool Match = llvm::all_of(Args, [&](auto &Arg) {
 const auto [Key, Value] = Arg;
@@ -156,27 +173,45 @@
   return Binary->getOffloadKind() == getOffloadKind(Value);
 return Binary->getString(Key) == Value;
   });
-  if (!Match)
-continue;
-
-  // If the user did not provide a filename derive one from the input and
-  // image.
-  StringRef Filename =
-  !Args.count("file")
-  ? Saver.save(sys::path::stem(InputFile) + "-" +
-   Binary->getTriple() + "-" + Binary->getArch() + "." +
-   std::to_string(I) + "." +
-   getImageKindName(Binary->getImageKind()))
-  : Args["file"];
-
-  Expected> OutputOrErr =
-  FileOutputBuffer::create(Filename, Binary->getImage().size());
-  if (!OutputOrErr)
-return OutputOrErr.takeError();
-  std::unique_ptr Output = std::move(*OutputOrErr);
-  llvm::copy(Binary->getImage(), Output->getBufferStart());
-  if (Error E = Output->commit())
+  if (Match)
+Extracted.push_back(Binary);
+}
+
+if (Extracted.empty())
+  continue;
+
+if (CreateArchive) {
+  if (!Args.count("file"))
+return createStringError(inconvertibleErrorCode(),
+ "Image must have a 'file' argument.");
+
+  SmallVector Members;
+  for (const OffloadBinary *Binary : Extracted)
+Members.emplace_back(MemoryBufferRef(
+Binary->getImage(),
+Binary->getMemoryBufferRef().getBufferIdentifier()));
+
+  if (Error E = writeArchive(Args["file"], Members, true,
+ Archive::getDefaultKindFo

[PATCH] D152746: [C++20][Modules] Complete implementation of module.import p7.

[Iain Sandoe via Phabricator via cfe-commits]

iains updated this revision to Diff 533656.
iains added a comment.

rebased and fixed some formatting.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D152746

Files:
  clang/include/clang/Basic/Module.h
  clang/lib/Basic/Module.cpp
  clang/lib/Sema/SemaModule.cpp
  clang/test/CXX/module/basic/basic.def.odr/p6.cppm
  clang/test/CXX/module/module.import/p7.cpp

Index: clang/test/CXX/module/module.import/p7.cpp
===
--- /dev/null
+++ clang/test/CXX/module/module.import/p7.cpp
@@ -0,0 +1,49 @@
+// RUN: mkdir -p %t
+// RUN: split-file %s %t
+
+// All of the following should build without diagnostics.
+//
+// RUN: %clang_cc1 -std=c++20 %t/a.cpp  -emit-module-interface -o %t/a.pcm
+// R U N: %clang_cc1 -std=c++20 %t/a.pcm  -emit-obj -o %t/a.o
+//
+// RUN: %clang_cc1 -std=c++20 %t/b.cpp  -emit-module-interface -o %t/b.pcm \
+// RUN: -fprebuilt-module-path=%t 
+// R U N: %clang_cc1 -std=c++20 %t/b.pcm  -emit-obj -o %t/b.o
+//
+// RUN: %clang_cc1 -std=c++20 %t/b-impl.cpp -emit-obj -o %t/b-impl.o \
+// RUN: -fprebuilt-module-path=%t
+//
+// RUN: %clang_cc1 -std=c++20 %t/ab-main.cpp  -fsyntax-only \
+// RUN: -fprebuilt-module-path=%t
+
+//--- a.cpp
+
+export module a;
+
+export int foo() {
+   return 42;
+}
+
+//--- b.cpp
+
+export module b;
+import a;
+
+export int bar();
+
+//--- b-impl.cpp
+
+module b;
+
+int bar() {
+   return foo();
+}
+
+//--- ab-main.cpp
+
+import b;
+
+int main() {
+   return bar();
+}
+
Index: clang/test/CXX/module/basic/basic.def.odr/p6.cppm
===
--- clang/test/CXX/module/basic/basic.def.odr/p6.cppm
+++ clang/test/CXX/module/basic/basic.def.odr/p6.cppm
@@ -17,9 +17,8 @@
 //
 // RUN: %clang_cc1 -std=c++20 %t/module-vs-module.cpp -fmodule-file=M=%t/M.pcm -emit-module-interface -o %t/N.pcm -DMODULE_INTERFACE -DNO_ERRORS
 // RUN: %clang_cc1 -std=c++20 %t/module-vs-module.cpp -fmodule-file=M=%t/M.pcm -fmodule-file=N=%t/N.pcm -verify
-// FIXME: Once we start importing "import" declarations properly, this should
-// be rejected (-verify should be added to the following line).
-// RUN: %clang_cc1 -std=c++20 %t/module-vs-module.cpp -fmodule-file=M=%t/M.pcm -fmodule-file=N=%t/N.pcm -DNO_IMPORT
+//
+// RUN: %clang_cc1 -std=c++20 %t/module-vs-module.cpp -fmodule-file=M=%t/M.pcm -fmodule-file=N=%t/N.pcm -DNO_IMPORT -verify
 //
 // RUN: %clang_cc1 -std=c++20 %t/module-vs-module.cpp -fmodule-file=M=%t/M.pcm -emit-module-interface -o %t/N-no-M.pcm -DMODULE_INTERFACE -DNO_ERRORS -DNO_IMPORT
 // RUN: %clang_cc1 -std=c++20 %t/module-vs-module.cpp -fmodule-file=M=%t/M.pcm -fmodule-file=N=%t/N-no-M.pcm -verify
Index: clang/lib/Sema/SemaModule.cpp
===
--- clang/lib/Sema/SemaModule.cpp
+++ clang/lib/Sema/SemaModule.cpp
@@ -397,6 +397,7 @@
   if (Interface) {
 
 VisibleModules.setVisible(Interface, ModuleLoc);
+VisibleModules.makeTransitiveImportsVisible(Interface, ModuleLoc);
 
 // Make the import decl for the interface in the impl module.
 ImportDecl *Import = ImportDecl::Create(Context, CurContext, ModuleLoc,
Index: clang/lib/Basic/Module.cpp
===
--- clang/lib/Basic/Module.cpp
+++ clang/lib/Basic/Module.cpp
@@ -695,6 +695,14 @@
   VisitModule({M, nullptr});
 }
 
+void VisibleModuleSet::makeTransitiveImportsVisible(Module *M,
+SourceLocation Loc,
+VisibleCallback Vis,
+ConflictCallback Cb) {
+  for (auto *I : M->Imports)
+setVisible(I, Loc, Vis, Cb);
+}
+
 ASTSourceDescriptor::ASTSourceDescriptor(Module &M)
 : Signature(M.Signature), ClangModule(&M) {
   if (M.Directory)
Index: clang/include/clang/Basic/Module.h
===
--- clang/include/clang/Basic/Module.h
+++ clang/include/clang/Basic/Module.h
@@ -822,6 +822,11 @@
   ConflictCallback Cb = [](ArrayRef, Module *,
StringRef) {});
 
+  /// Make transitive imports visible for [module.import]/7.
+  void makeTransitiveImportsVisible(
+  Module *M, SourceLocation Loc, VisibleCallback Vis = [](Module *) {},
+  ConflictCallback Cb = [](ArrayRef, Module *, StringRef) {});
+
 private:
   /// Import locations for each visible module. Indexed by the module's
   /// VisibilityID.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D153170: [RISCV] Sort the extensions in SupportedExtensions and SupportedExperimentalExtensions.

[Craig Topper via Phabricator via cfe-commits]

craig.topper added a comment.

In D153170#4441462 , @jrtc27 wrote:

> Can we have an expensive check that the table is sorted?

Yeah. I was going to do it when I made use of the sorted property, but it makes 
more sense to be in this patch. I'll probably do it for asserts builds for a 
better chance of people catching the error before it goes to the build bots.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153170

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

[PATCH] D152858: OpenMP: Use generated checks and pragma declare target

[Matt Arsenault via Phabricator via cfe-commits]

arsenm added a comment.

ping


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

https://reviews.llvm.org/D152858

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

[PATCH] D152857: OpenMP: Don't use target regions in library function test

[Matt Arsenault via Phabricator via cfe-commits]

arsenm added a comment.

ping


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

https://reviews.llvm.org/D152857

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

[PATCH] D153366: [dataflow] Add dedicated representation of boolean formulas

[Sam McCall via Phabricator via cfe-commits]

sammccall added a comment.

> Would you like me to review https://reviews.llvm.org/D153469 or should we 
> wait for this patch to converge first?

Similarly it'd be great to get high-level feedback there: whether the design of 
FormulaBoolValue is right, whether the changes to use Atom/Formula more 
pervasively seem sensible etc.
For the details, probably better to wait until this one is stable to avoid 
churn...

Thanks!




Comment at: clang/include/clang/Analysis/FlowSensitive/Formula.h:71
+  ArrayRef operands() const {
+return ArrayRef(reinterpret_cast(this + 1),
+numOperands(kind()));

mboehme wrote:
> Is this technically legal? (I've taken a look, but the definition of similar 
> types makes my eyes glaze over.)
> 
> Why not use `TrailingObjects` instead? (I'm not really familiar with 
> `TrailingObjects`, so there may be good reasons against it -- just asking 
> because it seems like an obvious existing mechanism that could be used here.)
> Is this technically legal?

Yeah, it's OK: similar types etc is not relevant because these pointers are not 
pointing to objects of different types: there's an object of type Formula at 
one address that has a lifetime that begins at the constructor (but it's 
trivially destructible and never destroyed), and then objects of type 
`Formula*` at higher addresses - these don't overlap, and are both part of the 
chunks of memory provided by malloc.

> Why not use TrailingObjects instead? 

TrailingObjects is complicated and ugly - it *can* work for this, but I don't 
think it's actually easier to understand. (Do a code search for "this + 1" in 
LLVM - this is often done "by hand" instead of with TrailingObjects for simple 
cases like this one).

e.g. here we have a little magic in create() and a little in operands(). 
TrailingObjects equally needs ~2 pieces of magic, they're *slightly* less 
scary, but they also don't relate directly to the memory layout, and I don't 
think you can have a meaningful understanding of what this is for without also 
thinking about the memory layout.

TrailingObjects shines when the pointer arithmetic gets complicated, though...



Comment at: clang/include/clang/Analysis/FlowSensitive/Formula.h:104
+  Kind FormulaKind;
+  unsigned Value;
+};

mboehme wrote:
> Why not give this type `Atom`?
I don't think it should always be Atom, even when it's used

see D153485 where I add a "Literal" formula and use value to distinguish 
true/false



Comment at: clang/lib/Analysis/FlowSensitive/WatchedLiteralsSolver.cpp:218
 
-  BooleanFormula Formula(NextVar - 1, std::move(Atomics));
+  BooleanFormula Form(NextVar - 1, std::move(Atomics));
   std::vector ProcessedSubVals(NextVar, false);

mboehme wrote:
> Now that we've added `Formula`, it's pretty confusing that we also have 
> `BooleanFormula`.
> 
> I assume this is one of the renamings that you want to get to later? I guess 
> `BooleanFormula` becomes something like `CnfFormula` (would like to do 
> `3CnfFormula`, but you can't start with a digit... :( )
Agree this is an unfortunate conflict and we should probably rename this local 
one.
(Just because it's more important that the public type gets the good name)

CNFFormula or just CNF SGTM.
I'll leave this open and do it as a followup if that's OK, the patch is noisy 
as is.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153366

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

[PATCH] D153233: clang: Add __builtin_elementwise_rint and nearbyint

[Matt Arsenault via Phabricator via cfe-commits]

arsenm added inline comments.



Comment at: clang/lib/Sema/SemaChecking.cpp:18583
   << Callee << CallerTCB;
 }
   }

arsenm wrote:
> bob80905 wrote:
> > I don't believe you intended to remove all this code in your latest update, 
> > did you?
> I didn't delete any code?
Are you looking at a history diff? I see nothing deleted here


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

https://reviews.llvm.org/D153233

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

[PATCH] D153430: [Clang][Driver] Warn on invalid Arm or AArch64 baremetal target triple

[Peter Smith via Phabricator via cfe-commits]

peter.smith added a comment.

> clang: warning: mismatch between architecture and environment in target 
> triple 'aarch64-none-eabi'; did you mean 'aarch64-none-elf'? 
> [-Winvalid-command-line-argument]

That looks good to me. Would be happy with that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153430

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

[PATCH] D153370: [RISCV] Add support for custom instructions for Sifive S76.

[garvit gupta via Phabricator via cfe-commits]

garvitgupta08 updated this revision to Diff 533668.
garvitgupta08 added a comment.

Addressed the comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153370

Files:
  llvm/docs/RISCVUsage.rst
  llvm/docs/ReleaseNotes.rst
  llvm/lib/Support/RISCVISAInfo.cpp
  llvm/lib/Target/RISCV/Disassembler/RISCVDisassembler.cpp
  llvm/lib/Target/RISCV/RISCVFeatures.td
  llvm/lib/Target/RISCV/RISCVInstrInfoXSf.td
  llvm/lib/Target/RISCV/RISCVProcessors.td
  llvm/test/MC/RISCV/attribute-arch.s
  llvm/test/MC/RISCV/xsfcie-invalid.s
  llvm/test/MC/RISCV/xsfcie-valid.s

Index: llvm/test/MC/RISCV/xsfcie-valid.s
===
--- /dev/null
+++ llvm/test/MC/RISCV/xsfcie-valid.s
@@ -0,0 +1,42 @@
+# SCIE - SiFive S76 Custom Instructions and CSRs.
+# RUN: llvm-mc %s -triple=riscv32 -mattr=+xsfcie -riscv-no-aliases -show-encoding \
+# RUN: | FileCheck -check-prefixes=CHECK-ENC,CHECK-INST %s
+# RUN: llvm-mc %s -triple=riscv64 -mattr=+xsfcie -riscv-no-aliases -show-encoding \
+# RUN: | FileCheck -check-prefixes=CHECK-ENC,CHECK-INST %s
+# RUN: llvm-mc -filetype=obj -triple riscv32 -mattr=+xsfcie < %s \
+# RUN: | llvm-objdump --mattr=+xsfcie -M no-aliases -d - \
+# RUN: | FileCheck -check-prefix=CHECK-INST %s
+# RUN: llvm-mc -filetype=obj -triple riscv64 -mattr=+xsfcie < %s \
+# RUN: | llvm-objdump --mattr=+xsfcie -M no-aliases -d - \
+# RUN: | FileCheck -check-prefix=CHECK-INST %s
+# RUN: llvm-mc %s -triple=riscv64 -mcpu=sifive-s76 -riscv-no-aliases -show-encoding \
+# RUN: | FileCheck -check-prefixes=CHECK-ENC,CHECK-INST %s
+# RUN: llvm-mc -filetype=obj -triple riscv64 -mcpu=sifive-s76 < %s \
+# RUN: | llvm-objdump --mcpu=sifive-s76 -M no-aliases -d - \
+# RUN: | FileCheck -check-prefix=CHECK-INST %s
+
+# CHECK-INST: cflush.d.l1 zero
+# CHECK-ENC: encoding: [0x73,0x00,0x00,0xfc]
+# CHECK-INST: cflush.d.l1 zero
+# CHECK-ENC: encoding: [0x73,0x00,0x00,0xfc]
+cflush.d.l1 x0
+cflush.d.l1
+
+# CHECK-INST: cflush.d.l1 t2
+# CHECK-ENC: encoding: [0x73,0x80,0x03,0xfc]
+cflush.d.l1 x7
+
+# CHECK-INST: cdiscard.d.l1   zero
+# CHECK-ENC: encoding: [0x73,0x00,0x20,0xfc]
+# CHECK-INST: cdiscard.d.l1 zero
+# CHECK-ENC: encoding: [0x73,0x00,0x20,0xfc]
+cdiscard.d.l1 x0
+cdiscard.d.l1
+
+# CHECK-INST: cdiscard.d.l1   t2
+# CHECK-ENC: encoding: [0x73,0x80,0x23,0xfc]
+cdiscard.d.l1 x7
+
+# CHECK-INST: cease
+# CHECK-ENC: encoding: [0x73,0x00,0x50,0x30]
+cease
Index: llvm/test/MC/RISCV/xsfcie-invalid.s
===
--- /dev/null
+++ llvm/test/MC/RISCV/xsfcie-invalid.s
@@ -0,0 +1,25 @@
+# SCIE - SiFive S76 Custom Instructions and CSRs.
+# RUN: not llvm-mc -triple riscv32 -mattr=-xsfcie < %s 2>&1 | FileCheck %s
+# RUN: not llvm-mc -triple riscv64 -mattr=-xsfcie < %s 2>&1 | FileCheck %s
+
+cflush.d.l1 0x10 # CHECK: :[[@LINE]]:13: error: invalid operand for instruction
+
+cdiscard.d.l1 0x10 # CHECK: :[[@LINE]]:15: error: invalid operand for instruction
+
+cflush.d.l1 # CHECK: :[[@LINE]]:1: error: instruction requires the following: 'XSfcie' (SiFive Custom Instruction Extension SCIE for S76.)
+
+cdiscard.d.l1 # CHECK: :[[@LINE]]:1: error: instruction requires the following: 'XSfcie' (SiFive Custom Instruction Extension SCIE for S76.)
+
+cflush.d.l1 x0 # CHECK: :[[@LINE]]:1: error: instruction requires the following: 'XSfcie' (SiFive Custom Instruction Extension SCIE for S76.)
+
+cflush.d.l1 x7 # CHECK: :[[@LINE]]:1: error: instruction requires the following: 'XSfcie' (SiFive Custom Instruction Extension SCIE for S76.)
+
+cdiscard.d.l1 x0 # CHECK: :[[@LINE]]:1: error: instruction requires the following: 'XSfcie' (SiFive Custom Instruction Extension SCIE for S76.)
+
+cdiscard.d.l1 x7 # CHECK: :[[@LINE]]:1: error: instruction requires the following: 'XSfcie' (SiFive Custom Instruction Extension SCIE for S76.)
+
+cease x1 # CHECK: :[[@LINE]]:7: error: invalid operand for instruction
+
+cease 0x10 # CHECK: :[[@LINE]]:7: error: invalid operand for instruction
+
+cease # CHECK: :[[@LINE]]:1: error: instruction requires the following: 'XSfcie' (SiFive Custom Instruction Extension SCIE for S76.)
Index: llvm/test/MC/RISCV/attribute-arch.s
===
--- llvm/test/MC/RISCV/attribute-arch.s
+++ llvm/test/MC/RISCV/attribute-arch.s
@@ -278,3 +278,6 @@
 
 .attribute arch, "rv32i_zvfbfwma0p6"
 # CHECK: .attribute 5, "rv32i2p1_f2p2_zicsr2p0_zve32f1p0_zve32x1p0_zvfbfwma0p6_zvl32b1p0"
+
+.attribute arch, "rv64i_xsfcie"
+# CHECK: attribute  5, "rv64i2p1_xsfcie1p0"
Index: llvm/lib/Target/RISCV/RISCVProcessors.td
===
--- llvm/lib/Target/RISCV/RISCVProcessors.td
+++ llvm/lib/Target/RISCV/RISCVProcessors.td
@@ -142,7 +142,9 @@
   FeatureStdExtA,
  

[PATCH] D150803: Add a new `wasm_custom` clang attribute for marking functions.

[Brendan Dahl via Phabricator via cfe-commits]

brendandahl added inline comments.



Comment at: clang/include/clang/Basic/AttrDocs.td:5608-5612
+Clang supports the ``__attribute__((wasm_async))``
+attribute for the WebAssembly target. This attribute may be attached to a
+function definition, which indicates the function will be used with JavaScript
+promise integration (JSPI). The attribute will cause the creation of a custom
+section named "async" that contains each wasm_async function's index value.

sbc100 wrote:
> sbc100 wrote:
> > sbc100 wrote:
> > > aaron.ballman wrote:
> > > > brendandahl wrote:
> > > > > aaron.ballman wrote:
> > > > > > aaron.ballman wrote:
> > > > > > > This could be my ignorance of web assembly showing, but the docs 
> > > > > > > don't really help me understand when you'd want to use this 
> > > > > > > attribute. Perhaps a link to what JSPI is and a code example 
> > > > > > > would help a little bit? Or is this more of a low-level 
> > > > > > > implementation detail kind of attribute where folks already know 
> > > > > > > the domain?
> > > > > > Based on the documentation here, I'm wondering why the `annotate` 
> > > > > > attribute doesn't suffice? That attribute lets you specify custom 
> > > > > > information to associate with a declaration that then gets lowered 
> > > > > > such that passes can do whatever they want with the info, which 
> > > > > > seems to be a more generalized version of what this attribute is.
> > > > > > 
> > > > > > (FWIW, I'm back to having basically no idea when you'd use this 
> > > > > > attribute or what it would be used for, so my thoughts above might 
> > > > > > make no sense.)
> > > > > I was considering that, but it would require more machinery in the 
> > > > > wasm backend to store all the attribute values in the output. For now 
> > > > > we only really need a flag associated with function. I think if we 
> > > > > find more uses for the annotations in the future we could replace 
> > > > > wasm_custom with it.
> > > > > I was considering that, but it would require more machinery in the 
> > > > > wasm backend to store all the attribute values in the output. For now 
> > > > > we only really need a flag associated with function. I think if we 
> > > > > find more uses for the annotations in the future we could replace 
> > > > > wasm_custom with it.
> > > > 
> > > > More machinery in the backend is preferred to exposing a new attribute 
> > > > that is this general-purpose; the backend is what needs this 
> > > > functionality, the frontend basically does nothing with it. (I'm 
> > > > assuming this is an implementation detail attribute and not something 
> > > > you expect users to write. If I'm wrong about that, please let me know.)
> > > > Based on the documentation here, I'm wondering why the `annotate` 
> > > > attribute doesn't suffice? 
> > > 
> > > I believe that was the original solution that was considered but Benden 
> > > was told this was perhaps not an appropriate use of "annotate".   Brenden 
> > > can you elaborate on why?   IIRC it was something like "the semantics of 
> > > the program should not depend on annotate attributes but the attribute 
> > > being added in this case is required for the program to run correctly".. 
> > > is that about right?
> > > 
> > > FWIW, I think using the existing `annotate` attribute would make a lot of 
> > > sense... if we can get away with it.
> > > (I'm assuming this is an implementation detail attribute and not 
> > > something you expect users to write. If I'm wrong about that, please let 
> > > me know.)
> > 
> > IIUC user would indeed be specifying these attributes.   Kind of like they 
> > do for "visibility" today.   The initial attribute that motivated this 
> > change is "async" which tells the host runtime that a certain function 
> > import or export behaves in an async manor (See https://v8.dev/blog/jspi 
> > for more details).
> > > I was considering that, but it would require more machinery in the wasm 
> > > backend to store all the attribute values in the output. For now we only 
> > > really need a flag associated with function. I think if we find more uses 
> > > for the annotations in the future we could replace wasm_custom with it.
> > 
> > More machinery in the backend is preferred to exposing a new attribute that 
> > is this general-purpose; the backend is what needs this functionality, the 
> > frontend basically does nothing with it. (I'm assuming this is an 
> > implementation detail attribute and not something you expect users to 
> > write. If I'm wrong about that, please let me know.)
> 
> I think perhaps there are two alternative implementations being proposed 
> here, and I want to make sure we don't confuse them:
> 
> 1. Use the existing `annotate` attribute.  
> 2. Make an even more complex custom attribute that hold key=value pairs 
> rather than the current CL which proposes simply boolean custom attributes 
> (e.g. key=true).
> 
> I think we would be happy with

[clang] d2fafa7 - [NFC] Fix potential dereferencing of nullptr.

[Sindhu Chittireddy via cfe-commits]

Author: Sindhu Chittireddy
Date: 2023-06-22T09:53:28-07:00
New Revision: d2fafa79ef08f9ef9cd0108a6caa7fc61a31bdeb

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

LOG: [NFC] Fix potential dereferencing of nullptr.

Replace getAs with castAs and add assert if needed.
Differential revision: https://reviews.llvm.org/D153236

Added: 


Modified: 
clang/lib/Sema/SemaExprObjC.cpp
clang/lib/Sema/SemaObjCProperty.cpp
clang/lib/Sema/SemaType.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaExprObjC.cpp b/clang/lib/Sema/SemaExprObjC.cpp
index e8984d298a29c..5df830e5bee6d 100644
--- a/clang/lib/Sema/SemaExprObjC.cpp
+++ b/clang/lib/Sema/SemaExprObjC.cpp
@@ -2438,6 +2438,9 @@ ExprResult Sema::BuildClassMessageImplicit(QualType 
ReceiverType,
   if (!ReceiverType.isNull())
 receiverTypeInfo = Context.getTrivialTypeSourceInfo(ReceiverType);
 
+  assert(((isSuperReceiver && Loc.isValid()) || receiverTypeInfo) &&
+ "Either the super receiver location needs to be valid or the receiver 
"
+ "needs valid type source information");
   return BuildClassMessage(receiverTypeInfo, ReceiverType,
   /*SuperLoc=*/isSuperReceiver ? Loc : 
SourceLocation(),
Sel, Method, Loc, Loc, Loc, Args,

diff  --git a/clang/lib/Sema/SemaObjCProperty.cpp 
b/clang/lib/Sema/SemaObjCProperty.cpp
index 3317bfce41192..7e5dc3a71cbba 100644
--- a/clang/lib/Sema/SemaObjCProperty.cpp
+++ b/clang/lib/Sema/SemaObjCProperty.cpp
@@ -1363,10 +1363,9 @@ Decl *Sema::ActOnPropertyImplDecl(Scope *S,
 if (!Context.hasSameType(PropertyIvarType, IvarType)) {
   if (isa(PropertyIvarType)
   && isa(IvarType))
-compat =
-  Context.canAssignObjCInterfaces(
-  
PropertyIvarType->getAs(),
-  IvarType->getAs());
+compat = Context.canAssignObjCInterfaces(
+PropertyIvarType->castAs(),
+IvarType->castAs());
   else {
 compat = (CheckAssignmentConstraints(PropertyIvarLoc, PropertyIvarType,
  IvarType)

diff  --git a/clang/lib/Sema/SemaType.cpp b/clang/lib/Sema/SemaType.cpp
index 77a1ce866d5c7..838ec19fcb3be 100644
--- a/clang/lib/Sema/SemaType.cpp
+++ b/clang/lib/Sema/SemaType.cpp
@@ -2708,8 +2708,8 @@ QualType Sema::BuildVectorType(QualType CurType, Expr 
*SizeExpr,
 return QualType();
   }
   // Only support _BitInt elements with byte-sized power of 2 NumBits.
-  if (CurType->isBitIntType()) {
-unsigned NumBits = CurType->getAs()->getNumBits();
+  if (const auto *BIT = CurType->getAs()) {
+unsigned NumBits = BIT->getNumBits();
 if (!llvm::isPowerOf2_32(NumBits) || NumBits < 8) {
   Diag(AttrLoc, diag::err_attribute_invalid_bitint_vector_type)
   << (NumBits < 8);



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

[PATCH] D153236: [NFC] Fix potential dereferencing of nullptr.

[Sindhu Chittireddy via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGd2fafa79ef08: [NFC] Fix potential dereferencing of nullptr. 
(authored by schittir).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153236

Files:
  clang/lib/Sema/SemaExprObjC.cpp
  clang/lib/Sema/SemaObjCProperty.cpp
  clang/lib/Sema/SemaType.cpp


Index: clang/lib/Sema/SemaType.cpp
===
--- clang/lib/Sema/SemaType.cpp
+++ clang/lib/Sema/SemaType.cpp
@@ -2708,8 +2708,8 @@
 return QualType();
   }
   // Only support _BitInt elements with byte-sized power of 2 NumBits.
-  if (CurType->isBitIntType()) {
-unsigned NumBits = CurType->getAs()->getNumBits();
+  if (const auto *BIT = CurType->getAs()) {
+unsigned NumBits = BIT->getNumBits();
 if (!llvm::isPowerOf2_32(NumBits) || NumBits < 8) {
   Diag(AttrLoc, diag::err_attribute_invalid_bitint_vector_type)
   << (NumBits < 8);
Index: clang/lib/Sema/SemaObjCProperty.cpp
===
--- clang/lib/Sema/SemaObjCProperty.cpp
+++ clang/lib/Sema/SemaObjCProperty.cpp
@@ -1363,10 +1363,9 @@
 if (!Context.hasSameType(PropertyIvarType, IvarType)) {
   if (isa(PropertyIvarType)
   && isa(IvarType))
-compat =
-  Context.canAssignObjCInterfaces(
-  
PropertyIvarType->getAs(),
-  IvarType->getAs());
+compat = Context.canAssignObjCInterfaces(
+PropertyIvarType->castAs(),
+IvarType->castAs());
   else {
 compat = (CheckAssignmentConstraints(PropertyIvarLoc, PropertyIvarType,
  IvarType)
Index: clang/lib/Sema/SemaExprObjC.cpp
===
--- clang/lib/Sema/SemaExprObjC.cpp
+++ clang/lib/Sema/SemaExprObjC.cpp
@@ -2438,6 +2438,9 @@
   if (!ReceiverType.isNull())
 receiverTypeInfo = Context.getTrivialTypeSourceInfo(ReceiverType);
 
+  assert(((isSuperReceiver && Loc.isValid()) || receiverTypeInfo) &&
+ "Either the super receiver location needs to be valid or the receiver 
"
+ "needs valid type source information");
   return BuildClassMessage(receiverTypeInfo, ReceiverType,
   /*SuperLoc=*/isSuperReceiver ? Loc : 
SourceLocation(),
Sel, Method, Loc, Loc, Loc, Args,


Index: clang/lib/Sema/SemaType.cpp
===
--- clang/lib/Sema/SemaType.cpp
+++ clang/lib/Sema/SemaType.cpp
@@ -2708,8 +2708,8 @@
 return QualType();
   }
   // Only support _BitInt elements with byte-sized power of 2 NumBits.
-  if (CurType->isBitIntType()) {
-unsigned NumBits = CurType->getAs()->getNumBits();
+  if (const auto *BIT = CurType->getAs()) {
+unsigned NumBits = BIT->getNumBits();
 if (!llvm::isPowerOf2_32(NumBits) || NumBits < 8) {
   Diag(AttrLoc, diag::err_attribute_invalid_bitint_vector_type)
   << (NumBits < 8);
Index: clang/lib/Sema/SemaObjCProperty.cpp
===
--- clang/lib/Sema/SemaObjCProperty.cpp
+++ clang/lib/Sema/SemaObjCProperty.cpp
@@ -1363,10 +1363,9 @@
 if (!Context.hasSameType(PropertyIvarType, IvarType)) {
   if (isa(PropertyIvarType)
   && isa(IvarType))
-compat =
-  Context.canAssignObjCInterfaces(
-  PropertyIvarType->getAs(),
-  IvarType->getAs());
+compat = Context.canAssignObjCInterfaces(
+PropertyIvarType->castAs(),
+IvarType->castAs());
   else {
 compat = (CheckAssignmentConstraints(PropertyIvarLoc, PropertyIvarType,
  IvarType)
Index: clang/lib/Sema/SemaExprObjC.cpp
===
--- clang/lib/Sema/SemaExprObjC.cpp
+++ clang/lib/Sema/SemaExprObjC.cpp
@@ -2438,6 +2438,9 @@
   if (!ReceiverType.isNull())
 receiverTypeInfo = Context.getTrivialTypeSourceInfo(ReceiverType);
 
+  assert(((isSuperReceiver && Loc.isValid()) || receiverTypeInfo) &&
+ "Either the super receiver location needs to be valid or the receiver "
+ "needs valid type source information");
   return BuildClassMessage(receiverTypeInfo, ReceiverType,
   /*SuperLoc=*/isSuperReceiver ? Loc : SourceLocation(),
Sel, Method, Loc, Loc, Loc, Args,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D153236: [NFC] Fix potential dereferencing of nullptr.

[Sindhu Chittireddy via Phabricator via cfe-commits]

schittir added a comment.

Thank you @aaron.ballman and @Fznamznon for reviewing! I landed this patch with 
commit d2fafa79ef08f9ef9cd0108a6caa7fc61a31bdeb 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153236

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

[PATCH] D143241: [Clang] Reset FP options before function instantiations

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

Hmm.  Why are we clearing the FP pragma stack instead of saving the old context 
onto it and then restoring after instantiation?  I don't think semantic 
analysis ever depends on enclosing members of the stack, does it?

Clearing the entire stack might not matter much if we're at the end of the 
translation unit, which is the normal time to instantiate things, but it would 
matter if we're eagerly instantiating within the translation unit, which we 
have to do for various reasons, including explicit instantiation and 
`constexpr`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143241

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

[PATCH] D139837: [Clang] Implements CTAD for aggregates P1816R0 and P2082R1

[Yuanfang Chen via Phabricator via cfe-commits]

ychen updated this revision to Diff 533674.
ychen marked 7 inline comments as done.
ychen added a comment.

- address comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139837

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/AST/DeclBase.h
  clang/include/clang/AST/DeclCXX.h
  clang/include/clang/Sema/Sema.h
  clang/include/clang/Sema/TemplateDeduction.h
  clang/lib/AST/ASTImporter.cpp
  clang/lib/AST/Decl.cpp
  clang/lib/Frontend/FrontendActions.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaInit.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/lib/Sema/SemaTemplate.cpp
  clang/lib/Sema/SemaTemplateDeduction.cpp
  clang/lib/Sema/SemaTemplateInstantiate.cpp
  clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
  clang/lib/Serialization/ASTReaderDecl.cpp
  clang/lib/Serialization/ASTWriterDecl.cpp
  clang/test/SemaTemplate/aggregate-deduction-candidate.cpp
  clang/www/cxx_status.html

Index: clang/www/cxx_status.html
===
--- clang/www/cxx_status.html
+++ clang/www/cxx_status.html
@@ -1246,7 +1246,7 @@
 
   Class template argument deduction for aggregates
   https://wg21.link/p1816r0";>P1816R0
-  No
+  Clang 17
 

 https://wg21.link/p2082r1";>P2082R1
Index: clang/test/SemaTemplate/aggregate-deduction-candidate.cpp
===
--- /dev/null
+++ clang/test/SemaTemplate/aggregate-deduction-candidate.cpp
@@ -0,0 +1,364 @@
+// RUN: %clang_cc1 -std=c++20 -verify -ast-dump -ast-dump-decl-types -ast-dump-filter "deduction guide" %s | FileCheck %s --strict-whitespace
+
+namespace Basic {
+  template struct A {
+T x;
+T y;
+  };
+
+  A a1 = {3.0, 4.0};
+  A a2 = {.x = 3.0, .y = 4.0};
+
+  A a3(3.0, 4.0);
+
+  // CHECK-LABEL: Dumping Basic:::
+  // CHECK: FunctionTemplateDecl {{.*}} implicit 
+  // CHECK: |-TemplateTypeParmDecl {{.*}} referenced class depth 0 index 0 T
+  // CHECK: |-CXXDeductionGuideDecl {{.*}} implicit  'auto (T, T) -> A'
+  // CHECK: | |-ParmVarDecl {{.*}} 'T'
+  // CHECK: | `-ParmVarDecl {{.*}} 'T'
+  // CHECK: `-CXXDeductionGuideDecl {{.*}} implicit used  'auto (double, double) -> Basic::A'
+  // CHECK:   |-TemplateArgument type 'double'
+  // CHECK:   | `-BuiltinType {{.*}} 'double'
+  // CHECK:   |-ParmVarDecl {{.*}} 'double':'double'
+  // CHECK:   `-ParmVarDecl {{.*}} 'double':'double'
+  // CHECK: FunctionProtoType {{.*}} 'auto (T, T) -> A' dependent trailing_return cdecl
+  // CHECK: |-InjectedClassNameType {{.*}} 'A' dependent
+  // CHECK: | `-CXXRecord {{.*}} 'A'
+  // CHECK: |-TemplateTypeParmType {{.*}} 'T' dependent depth 0 index 0
+  // CHECK: | `-TemplateTypeParm {{.*}} 'T'
+  // CHECK: `-TemplateTypeParmType {{.*}} 'T' dependent depth 0 index 0
+  // CHECK:   `-TemplateTypeParm {{.*}} 'T'
+
+  template  struct S { // expected-note 2 {{candidate}}
+T x;
+T y;
+  };
+
+  template  struct C { // expected-note 10 {{candidate}}
+S s;
+T t;
+  };
+
+  template  struct D { // expected-note 6 {{candidate}}
+S s;
+T t;
+  };
+
+  C c1 = {1, 2}; // expected-error {{no viable}}
+  C c2 = {1, 2, 3}; // expected-error {{no viable}}
+  C c3 = {{1u, 2u}, 3};
+
+  C c4(1, 2);// expected-error {{no viable}}
+  C c5(1, 2, 3); // expected-error {{no viable}}
+  C c6({1u, 2u}, 3);
+
+  D d1 = {1, 2}; // expected-error {{no viable}}
+  D d2 = {1, 2, 3};
+
+  D d3(1, 2); // expected-error {{no viable}}
+  // CTAD succeed but brace elision is not allowed for parenthesized aggregate init. 
+  D d4(1, 2, 3); // expected-error {{no viable}}
+
+  // CHECK-LABEL: Dumping Basic:::
+  // CHECK: FunctionTemplateDecl {{.*}} implicit 
+  // CHECK: |-TemplateTypeParmDecl {{.*}} referenced typename depth 0 index 0 T
+  // CHECK: |-CXXDeductionGuideDecl {{.*}} implicit  'auto (S, T) -> C'
+  // CHECK: | |-ParmVarDecl {{.*}} 'S':'S'
+  // CHECK: | `-ParmVarDecl {{.*}} 'T'
+  // CHECK: `-CXXDeductionGuideDecl {{.*}} implicit used  'auto (S, int) -> Basic::C'
+  // CHECK:   |-TemplateArgument type 'int'
+  // CHECK:   | `-BuiltinType {{.*}} 'int'
+  // CHECK:   |-ParmVarDecl {{.*}} 'S':'Basic::S'
+  // CHECK:   `-ParmVarDecl {{.*}} 'int':'int'
+  // CHECK: FunctionProtoType {{.*}} 'auto (S, T) -> C' dependent trailing_return cdecl
+  // CHECK: |-InjectedClassNameType {{.*}} 'C' dependent
+  // CHECK: | `-CXXRecord {{.*}} 'C'
+  // CHECK: |-ElaboratedType {{.*}} 'S' sugar dependent
+  // CHECK: | `-TemplateSpecializationType {{.*}} 'S' dependent S
+  // CHECK: |   `-TemplateArgument type 'T'
+  // CHECK: | `-TemplateTypeParmType {{.*}} 'T' dependent depth 0 index 0
+  // CHECK: |   `-TemplateTypeParm {{.*}} 'T'
+  // CHECK: `-TemplateTypeParmType {{.*}} 'T' dependent depth 0 index 0
+  // CHECK:   `-TemplateTypeParm {{.*}} 'T'
+
+  // CHECK-LABEL: Dumping Basic:::
+  // CHECK: FunctionTemplateDecl {{.*}} implicit 
+  // C

[PATCH] D139837: [Clang] Implements CTAD for aggregates P1816R0 and P2082R1

[Yuanfang Chen via Phabricator via cfe-commits]

ychen added inline comments.



Comment at: clang/include/clang/AST/DeclCXX.h:1987
+  void setDeductionCandidateKind(DeductionCandidateKind K) {
+FunctionDeclBits.DeductionCandidateKind = static_cast(K);
   }

shafik wrote:
> aaron.ballman wrote:
> > Er, seems a bit odd to cast an 8-bit type to a 64-bit type only to shove it 
> > into a 2-bit bit-field. I think `DeductionCandidateKind` should be an enum 
> > class whose underlying type is `int` and we cast to/from `int` as needed.
> It feels a bit weird that we are taking an enum w/ an underlying type of 
> `unsigned char` casting it to `int` and then placing it in an unsigned 
> bit-field. I don't have a better suggestion ATM but I wish we had something 
> better. 
I've changed it to casting to underlying type of `DeductionCandidate` so it has 
one less step of conversion.



Comment at: clang/lib/Sema/SemaInit.cpp:15
 #include "clang/AST/DeclObjC.h"
+#include "clang/AST/Expr.h"
 #include "clang/AST/ExprCXX.h"

shafik wrote:
> I saw your adding headers. How did you figure out which ones were missing?
Added headers provide APIs for the new code. I guess many of them are included 
already indirectly (SmallVector for example). But I thought the best practice 
is not relying on that, so I added these.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139837

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

[PATCH] D153170: [RISCV] Sort the extensions in SupportedExtensions and SupportedExperimentalExtensions.

[Craig Topper via Phabricator via cfe-commits]

craig.topper updated this revision to Diff 533678.
craig.topper added a comment.

Verify the table is sorted. This uses the same pattern we use to check sorted 
tables in other places like X86InstrFMA3Info.cpp.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153170

Files:
  clang/test/Driver/riscv-march-mcpu-mtune.c
  llvm/lib/Support/RISCVISAInfo.cpp

Index: llvm/lib/Support/RISCVISAInfo.cpp
===
--- llvm/lib/Support/RISCVISAInfo.cpp
+++ llvm/lib/Support/RISCVISAInfo.cpp
@@ -16,6 +16,7 @@
 #include "llvm/Support/raw_ostream.h"
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -33,6 +34,10 @@
   const char *Name;
   /// Supported version.
   RISCVExtensionVersion Version;
+
+  bool operator<(const RISCVSupportedExtension &RHS) const {
+return StringRef(Name) < StringRef(RHS.Name);
+  }
 };
 
 } // end anonymous namespace
@@ -44,17 +49,45 @@
 };
 
 static const RISCVSupportedExtension SupportedExtensions[] = {
-{"i", RISCVExtensionVersion{2, 1}},
-{"e", RISCVExtensionVersion{2, 0}},
-{"m", RISCVExtensionVersion{2, 0}},
 {"a", RISCVExtensionVersion{2, 1}},
-{"f", RISCVExtensionVersion{2, 2}},
-{"d", RISCVExtensionVersion{2, 2}},
 {"c", RISCVExtensionVersion{2, 0}},
-
+{"d", RISCVExtensionVersion{2, 2}},
+{"e", RISCVExtensionVersion{2, 0}},
+{"f", RISCVExtensionVersion{2, 2}},
 {"h", RISCVExtensionVersion{1, 0}},
+{"i", RISCVExtensionVersion{2, 1}},
+{"m", RISCVExtensionVersion{2, 0}},
 
-{"zihintpause", RISCVExtensionVersion{2, 0}},
+{"svinval", RISCVExtensionVersion{1, 0}},
+{"svnapot", RISCVExtensionVersion{1, 0}},
+{"svpbmt", RISCVExtensionVersion{1, 0}},
+
+{"v", RISCVExtensionVersion{1, 0}},
+
+// vendor-defined ('X') extensions
+{"xsfvcp", RISCVExtensionVersion{1, 0}},
+{"xtheadba", RISCVExtensionVersion{1, 0}},
+{"xtheadbb", RISCVExtensionVersion{1, 0}},
+{"xtheadbs", RISCVExtensionVersion{1, 0}},
+{"xtheadcmo", RISCVExtensionVersion{1, 0}},
+{"xtheadcondmov", RISCVExtensionVersion{1, 0}},
+{"xtheadfmemidx", RISCVExtensionVersion{1, 0}},
+{"xtheadmac", RISCVExtensionVersion{1, 0}},
+{"xtheadmemidx", RISCVExtensionVersion{1, 0}},
+{"xtheadmempair", RISCVExtensionVersion{1, 0}},
+{"xtheadsync", RISCVExtensionVersion{1, 0}},
+{"xtheadvdot", RISCVExtensionVersion{1, 0}},
+{"xventanacondops", RISCVExtensionVersion{1, 0}},
+
+{"zawrs", RISCVExtensionVersion{1, 0}},
+
+{"zba", RISCVExtensionVersion{1, 0}},
+{"zbb", RISCVExtensionVersion{1, 0}},
+{"zbc", RISCVExtensionVersion{1, 0}},
+{"zbkb", RISCVExtensionVersion{1, 0}},
+{"zbkc", RISCVExtensionVersion{1, 0}},
+{"zbkx", RISCVExtensionVersion{1, 0}},
+{"zbs", RISCVExtensionVersion{1, 0}},
 
 {"zca", RISCVExtensionVersion{1, 0}},
 {"zcb", RISCVExtensionVersion{1, 0}},
@@ -63,101 +96,77 @@
 {"zcmp", RISCVExtensionVersion{1, 0}},
 {"zcmt", RISCVExtensionVersion{1, 0}},
 
-{"zfhmin", RISCVExtensionVersion{1, 0}},
-{"zfh", RISCVExtensionVersion{1, 0}},
+{"zdinx", RISCVExtensionVersion{1, 0}},
 
+{"zfh", RISCVExtensionVersion{1, 0}},
+{"zfhmin", RISCVExtensionVersion{1, 0}},
 {"zfinx", RISCVExtensionVersion{1, 0}},
-{"zdinx", RISCVExtensionVersion{1, 0}},
-{"zhinxmin", RISCVExtensionVersion{1, 0}},
+
 {"zhinx", RISCVExtensionVersion{1, 0}},
+{"zhinxmin", RISCVExtensionVersion{1, 0}},
 
-{"zba", RISCVExtensionVersion{1, 0}},
-{"zbb", RISCVExtensionVersion{1, 0}},
-{"zbc", RISCVExtensionVersion{1, 0}},
-{"zbs", RISCVExtensionVersion{1, 0}},
+{"zicbom", RISCVExtensionVersion{1, 0}},
+{"zicbop", RISCVExtensionVersion{1, 0}},
+{"zicboz", RISCVExtensionVersion{1, 0}},
+{"zicntr", RISCVExtensionVersion{1, 0}},
+{"zicsr", RISCVExtensionVersion{2, 0}},
+{"zifencei", RISCVExtensionVersion{2, 0}},
+{"zihintpause", RISCVExtensionVersion{2, 0}},
+{"zihpm", RISCVExtensionVersion{1, 0}},
 
-{"zbkb", RISCVExtensionVersion{1, 0}},
-{"zbkc", RISCVExtensionVersion{1, 0}},
-{"zbkx", RISCVExtensionVersion{1, 0}},
+{"zk", RISCVExtensionVersion{1, 0}},
+{"zkn", RISCVExtensionVersion{1, 0}},
 {"zknd", RISCVExtensionVersion{1, 0}},
 {"zkne", RISCVExtensionVersion{1, 0}},
 {"zknh", RISCVExtensionVersion{1, 0}},
-{"zksed", RISCVExtensionVersion{1, 0}},
-{"zksh", RISCVExtensionVersion{1, 0}},
 {"zkr", RISCVExtensionVersion{1, 0}},
-{"zkn", RISCVExtensionVersion{1, 0}},
 {"zks", RISCVExtensionVersion{1, 0}},
+{"zksed", RISCVExtensionVersion{1, 0}},
+{"zksh", RISCVExtensionVersion{1, 0}},
 {"zkt", RISCVExtensionVersion{1, 0}},
-{"zk", RISCVExtensionVersion{1, 0}},
 
 {"zmmul", RISCVExtensionVersion{1, 0}},
 
-{"v", RISCVExtensionVersion{1, 0}},
-{"zvl32b", RISCVExtensionVersion{1, 0}},
-{"zv

[PATCH] D139629: clang: Stop emitting "strictfp"

[Matt Arsenault via Phabricator via cfe-commits]

arsenm added a comment.

ping


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

https://reviews.llvm.org/D139629

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

[PATCH] D153233: clang: Add __builtin_elementwise_rint and nearbyint

[Joshua Batista via Phabricator via cfe-commits]

bob80905 added inline comments.



Comment at: clang/lib/Sema/SemaChecking.cpp:18583
   << Callee << CallerTCB;
 }
   }

arsenm wrote:
> arsenm wrote:
> > bob80905 wrote:
> > > I don't believe you intended to remove all this code in your latest 
> > > update, did you?
> > I didn't delete any code?
> Are you looking at a history diff? I see nothing deleted here
I am unsure what I was seeing prior, but I no longer see any deleted code, you 
can count this comment as resolved.


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

https://reviews.llvm.org/D153233

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

[clang] 9fc3b4a - [clang] Add a namespace for interesting identifiers.

[Zahira Ammarguellat via cfe-commits]

Author: Zahira Ammarguellat
Date: 2023-06-22T13:24:00-04:00
New Revision: 9fc3b4acbc920dc93f4b6eefb4e2b3f795fa9aac

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

LOG: [clang] Add a namespace for interesting identifiers.

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

Added: 


Modified: 
clang/include/clang/Basic/IdentifierTable.h
clang/include/clang/Basic/TokenKinds.def
clang/include/clang/Basic/TokenKinds.h
clang/lib/Basic/Builtins.cpp
clang/lib/Basic/IdentifierTable.cpp
clang/lib/Sema/SemaDecl.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/IdentifierTable.h 
b/clang/include/clang/Basic/IdentifierTable.h
index 1886b1d7ba620..2c7ce0e4b9753 100644
--- a/clang/include/clang/Basic/IdentifierTable.h
+++ b/clang/include/clang/Basic/IdentifierTable.h
@@ -76,6 +76,21 @@ enum { IdentifierInfoAlignment = 8 };
 
 static constexpr int ObjCOrBuiltinIDBits = 16;
 
+/// The "layout" of ObjCOrBuiltinID is:
+///  - The first value (0) represents "not a special identifier".
+///  - The next (NUM_OBJC_KEYWORDS - 1) values represent ObjCKeywordKinds (not
+///including objc_not_keyword).
+///  - The next (NUM_INTERESTING_IDENTIFIERS - 1) values represent
+///InterestingIdentifierKinds (not including not_interesting).
+///  - The rest of the values represent builtin IDs (not including NotBuiltin).
+static constexpr int FirstObjCKeywordID = 1;
+static constexpr int LastObjCKeywordID =
+FirstObjCKeywordID + tok::NUM_OBJC_KEYWORDS - 2;
+static constexpr int FirstInterestingIdentifierID = LastObjCKeywordID + 1;
+static constexpr int LastInterestingIdentifierID =
+FirstInterestingIdentifierID + tok::NUM_INTERESTING_IDENTIFIERS - 2;
+static constexpr int FirstBuiltinID = LastInterestingIdentifierID + 1;
+
 /// One of these records is kept for each identifier that
 /// is lexed.  This contains information about whether the token was 
\#define'd,
 /// is a language keyword, or if it is a front-end token of some sort (e.g. a
@@ -290,7 +305,9 @@ class alignas(IdentifierInfoAlignment) IdentifierInfo {
   ///
   /// For example, 'class' will return tok::objc_class if ObjC is enabled.
   tok::ObjCKeywordKind getObjCKeywordID() const {
-if (ObjCOrBuiltinID < tok::NUM_OBJC_KEYWORDS)
+static_assert(FirstObjCKeywordID == 1,
+  "hard-coding this assumption to simplify code");
+if (ObjCOrBuiltinID <= LastObjCKeywordID)
   return tok::ObjCKeywordKind(ObjCOrBuiltinID);
 else
   return tok::objc_not_keyword;
@@ -301,15 +318,30 @@ class alignas(IdentifierInfoAlignment) IdentifierInfo {
   ///
   /// 0 is not-built-in. 1+ are specific builtin functions.
   unsigned getBuiltinID() const {
-if (ObjCOrBuiltinID >= tok::NUM_OBJC_KEYWORDS)
-  return ObjCOrBuiltinID - tok::NUM_OBJC_KEYWORDS;
+if (ObjCOrBuiltinID >= FirstBuiltinID)
+  return 1 + (ObjCOrBuiltinID - FirstBuiltinID);
 else
   return 0;
   }
   void setBuiltinID(unsigned ID) {
-ObjCOrBuiltinID = ID + tok::NUM_OBJC_KEYWORDS;
-assert(ObjCOrBuiltinID - unsigned(tok::NUM_OBJC_KEYWORDS) == ID
-   && "ID too large for field!");
+assert(ID != 0);
+ObjCOrBuiltinID = FirstBuiltinID + (ID - 1);
+assert(getBuiltinID() == ID && "ID too large for field!");
+  }
+  void clearBuiltinID() { ObjCOrBuiltinID = 0; }
+
+  tok::InterestingIdentifierKind getInterestingIdentifierID() const {
+if (ObjCOrBuiltinID >= FirstInterestingIdentifierID &&
+ObjCOrBuiltinID <= LastInterestingIdentifierID)
+  return tok::InterestingIdentifierKind(
+  1 + (ObjCOrBuiltinID - FirstInterestingIdentifierID));
+else
+  return tok::not_interesting;
+  }
+  void setInterestingIdentifierID(unsigned ID) {
+assert(ID != tok::not_interesting);
+ObjCOrBuiltinID = FirstInterestingIdentifierID + (ID - 1);
+assert(getInterestingIdentifierID() == ID && "ID too large for field!");
   }
 
   unsigned getObjCOrBuiltinID() const { return ObjCOrBuiltinID; }

diff  --git a/clang/include/clang/Basic/TokenKinds.def 
b/clang/include/clang/Basic/TokenKinds.def
index cad973f5e5e93..8c0529fdb055b 100644
--- a/clang/include/clang/Basic/TokenKinds.def
+++ b/clang/include/clang/Basic/TokenKinds.def
@@ -85,6 +85,9 @@
 #ifndef PRAGMA_ANNOTATION
 #define PRAGMA_ANNOTATION(X) ANNOTATION(X)
 #endif
+#ifndef INTERESTING_IDENTIFIER
+#define INTERESTING_IDENTIFIER(X)
+#endif
 
 
//===--===//
 // Preprocessor keywords.
@@ -794,6 +797,15 @@ OBJC_AT_KEYWORD(dynamic)
 OBJC_AT_KEYWORD(import)
 OBJC_AT_KEYWORD(available)
 
+//===--===//
+// Interesting idenitifiers.
+//===--