[PATCH] D141472: [clang][Interp] Add function pointers

2023-01-31 Thread Timm Bäder via Phabricator via cfe-commits
tbaeder added a comment.

In D141472#4091662 , @aaron.ballman 
wrote:

> Design question -- do you anticipate this class handling *all* function 
> pointers, including pointer to member functions that might be virtual: 
> https://godbolt.org/z/hT8fMY37n

I had to make a few adjustments but I have that example working locally now, of 
course no idea if that would work generally. Do you see any problem with the 
proposed `FunctionPointer` class?

According to https://clang.llvm.org/docs/ConstantInterpreter.html#pointers, 
there was a `MemberPointer` class that sounds related to this, but I don't know 
more about it. I guess, since you made `func()` virtual, that matters and 
becomes a bytecode-runtime decision instead of being known at compile-time, 
which seems to be the case in your example?


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

https://reviews.llvm.org/D141472

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


[PATCH] D142704: [C++20][Modules] Handle template declarations in header units.

2023-01-31 Thread Chuanqi Xu via Phabricator via cfe-commits
ChuanqiXu added a comment.

In D142704#4092724 , @iains wrote:

> I think we need to find a way to proceed - because this causes a regression 
> on the llvm-16 branch, and that should be resolved soon, if possible.
> What is your suggestion for a way forward?

Yeah, this is a pretty severe problem. Luckily clang16 is going to be released 
in early March. So we have roughly one month to solve this problem. Even if we 
failed to solve this in the last minute, I think it is not too bad to revert 
https://github.com/llvm/llvm-project/commit/335668b116439d13c7555616e126acdc608ce59e.




Comment at: clang/lib/Sema/SemaDecl.cpp:15265
   FD->getFormalLinkage() == Linkage::ExternalLinkage &&
-  !FD->isInvalidDecl() && BodyKind != FnBodyKind::Delete &&
+  !FD->isInvalidDecl() && !IsFnTemplate && BodyKind != FnBodyKind::Delete 
&&
   BodyKind != FnBodyKind::Default && !FD->isInlined()) {

iains wrote:
> iains wrote:
> > ChuanqiXu wrote:
> > > iains wrote:
> > > > rsmith wrote:
> > > > > Would it make sense to use `!isa(D)` here 
> > > > > instead of adding `IsFnTemplate`?
> > > > > Would it make sense to use `!isa(D)` here 
> > > > > instead of adding `IsFnTemplate`?
> > > > 
> > > > I have changed this to use FD->isTemplated() to match the changes for 
> > > > VarDecls - where the template decl is not available.  Would it be 
> > > > better to use the isa<>() ?
> > > > 
> > > It looks not bad to me to use `isTemplated ()`. And it looks like 
> > > `!FD->isTemplateInstantiation()` is not tested? And it looks a little bit 
> > > odd since the instantiated template should be implicitly inline.
> > > It looks not bad to me to use `isTemplated ()`. 
> > 
> > Hmm. now I am not sure what you prefer; in a previous review there was an 
> > objection to not using the provided function in the decl class.  
> > 
> > What would be your suggestion here?
> > 
> > (we cannot use isa when testing the variables case because 
> > the caller pulls out the templated decl before we get to test it) - so it 
> > is more consistent (IMO) to use the same interface in both tests.
> > 
> > >And it looks like `!FD->isTemplateInstantiation()` is not tested?
> > 
> > Please could you expand a bit on what you mean here?
> >  (the test is clearly required, in practice)
> > 
> > > And it looks a little bit odd since the instantiated template should be 
> > > implicitly inline.
> > 
> > Did you see @dlaikie's comment on this topic above?
> > 
> > 
> 
> > Did you see @dlaikie's comment on this topic above?
> 
> sorry @dblaikie 's comment is in the PR 
> (https://github.com/llvm/llvm-project/issues/60079#issuecomment-1406856501)
> What would be your suggestion here?

I prefer `isTemplated ()` here. If I get things correct,  `isTemplated ()` will 
cover the case that a non-template function decl inside a function template. 
And `isa(D)` wouldn't handle the case. According to my 
understanding problem, we should avoid all the dependent cases.

> Please could you expand a bit on what you mean here?

I mean I didn't find function template instantiation in tests of this revision 
page.

> sorry @dblaikie 's comment is in the PR 
> (https://github.com/llvm/llvm-project/issues/60079#issuecomment-1406856501)

oh, this is because the inconsistent use of `inline` in different places.. this 
may be the price we need to pay.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142704

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


[PATCH] D142871: [clangd] Semantic highlighting for constrained-parameter

2023-01-31 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet added a subscriber: usaxena95.
kadircet added inline comments.



Comment at: clang-tools-extra/clangd/FindTarget.cpp:720
+  // Pick up the name via VisitNamedDecl
+  Base::VisitTemplateTypeParmDecl(D);
+}

nridge wrote:
> Am I using the API correctly here? It's a bit weird that `ConstDeclVisitor` 
> would work differently from `RecursiveASTVisitor` in that VisitXXX methods 
> for super-classes are not automatically called
right, non-recursive ast visitors are mere helpers for visiting most specific 
type of an ast node which is interesting to the visitor (i.e. visit method is 
overridden), and only that. they also don't traverse children of an entitie's 
entries.

which usually hints towards this being the wrong place to handle such 
constructs. we actually have an outer recursiveastvisitor, that tries to visit 
each children. but concept references seem to be missing from there.
taking a look at the RecursiveASTVisitor pieces around this piece, we actually 
do visit the children appropriately:
- 
https://github.com/llvm/llvm-project/blob/main/clang/include/clang/AST/RecursiveASTVisitor.h#L1931
 calls traverse on the constraint
- 
https://github.com/llvm/llvm-project/blob/main/clang/include/clang/AST/RecursiveASTVisitor.h#L1923
 jumps into type constraint
- 
https://github.com/llvm/llvm-project/blob/main/clang/include/clang/AST/RecursiveASTVisitor.h#L510
 some more indirection
- 
https://github.com/llvm/llvm-project/blob/main/clang/include/clang/AST/RecursiveASTVisitor.h#L547
 calls visit for the decl name
- 
https://github.com/llvm/llvm-project/blob/clang/include/clang/AST/RecursiveASTVisitor.h#L830
 unfortunately we stop here, because all we store is an identifier.

We should probably figure out how to properly visit type constraints inside the 
RecursiveASTVisitor (i guess we should actually be visiting TypeConstraints). 
@usaxena95 who's looking at C++20 features and their interactions with source 
tooling.

In the meanwhile, i think we should have this specialization at the outer 
layer, in `ExplicitReferenceCollector`, with something like:
```
bool TraverseTemplateTypeParamDeclConstraints(TemplateTypeParmDecl *TTPD) {
  if (auto *TC = TTPD->getTypeConstraint()) {
reportReference(ReferenceLoc{TC->getNestedNameSpecifierLoc(),
 TC->getConceptNameLoc(),
 /*IsDecl=*/false,
 {TC->getNamedConcept()}},
DynTypedNode::create(*TTPD));
return RecursiveASTVisitor::TraverseTypeConstraint(TC);
  }
  return true;
}
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142871

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


[PATCH] D142085: [1/3][Clang][RISCV] Add `__riscv_` prefix for vread, vwrite, vlenb, vsetvl, and vsetvlmax

2023-01-31 Thread Yueh-Ting (eop) Chen 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 rG54b40a1785e9: [1/3][Clang][RISCV] Add `__riscv_` prefix for 
vread, vwrite, vlenb, vsetvl, and… (authored by eopXD).

Changed prior to commit:
  https://reviews.llvm.org/D142085?vs=492474&id=493510#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142085

Files:
  clang/include/clang/Basic/riscv_vector.td
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vsetvl.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vsetvlmax.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/policy/non-overloaded/vsetvl.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/policy/non-overloaded/vsetvlmax.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-handcrafted/vread-csr.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-handcrafted/vwrite-csr.c

Index: clang/test/CodeGen/RISCV/rvv-intrinsics-handcrafted/vwrite-csr.c
===
--- clang/test/CodeGen/RISCV/rvv-intrinsics-handcrafted/vwrite-csr.c
+++ clang/test/CodeGen/RISCV/rvv-intrinsics-handcrafted/vwrite-csr.c
@@ -11,7 +11,7 @@
 // CHECK-NEXT:ret void
 //
 void vwrite_csr_vstart(unsigned long value) {
-  vwrite_csr(RVV_VSTART, value);
+  __riscv_vwrite_csr(RVV_VSTART, value);
 }
 
 // CHECK-LABEL: @vwrite_csr_vxsat(
@@ -20,7 +20,7 @@
 // CHECK-NEXT:ret void
 //
 void vwrite_csr_vxsat(unsigned long value) {
-  vwrite_csr(RVV_VXSAT, value);
+  __riscv_vwrite_csr(RVV_VXSAT, value);
 }
 
 // CHECK-LABEL: @vwrite_csr_vxrm(
@@ -29,7 +29,7 @@
 // CHECK-NEXT:ret void
 //
 void vwrite_csr_vxrm(unsigned long value) {
-  vwrite_csr(RVV_VXRM, value);
+  __riscv_vwrite_csr(RVV_VXRM, value);
 }
 
 // CHECK-LABEL: @vwrite_csr_vcsr(
@@ -38,5 +38,5 @@
 // CHECK-NEXT:ret void
 //
 void vwrite_csr_vcsr(unsigned long value) {
-  vwrite_csr(RVV_VCSR, value);
+  __riscv_vwrite_csr(RVV_VCSR, value);
 }
Index: clang/test/CodeGen/RISCV/rvv-intrinsics-handcrafted/vread-csr.c
===
--- clang/test/CodeGen/RISCV/rvv-intrinsics-handcrafted/vread-csr.c
+++ clang/test/CodeGen/RISCV/rvv-intrinsics-handcrafted/vread-csr.c
@@ -11,7 +11,7 @@
 // CHECK-NEXT:ret i64 [[TMP0]]
 //
 unsigned long vread_csr_vstart(void) {
-  return vread_csr(RVV_VSTART);
+  return __riscv_vread_csr(RVV_VSTART);
 }
 
 // CHECK-LABEL: @vread_csr_vxsat(
@@ -20,7 +20,7 @@
 // CHECK-NEXT:ret i64 [[TMP0]]
 //
 unsigned long vread_csr_vxsat(void) {
-  return vread_csr(RVV_VXSAT);
+  return __riscv_vread_csr(RVV_VXSAT);
 }
 
 // CHECK-LABEL: @vread_csr_vxrm(
@@ -29,7 +29,7 @@
 // CHECK-NEXT:ret i64 [[TMP0]]
 //
 unsigned long vread_csr_vxrm(void) {
-  return vread_csr(RVV_VXRM);
+  return __riscv_vread_csr(RVV_VXRM);
 }
 
 // CHECK-LABEL: @vread_csr_vcsr(
@@ -38,5 +38,5 @@
 // CHECK-NEXT:ret i64 [[TMP0]]
 //
 unsigned long vread_csr_vcsr(void) {
-  return vread_csr(RVV_VCSR);
+  return __riscv_vread_csr(RVV_VCSR);
 }
Index: clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/policy/non-overloaded/vsetvlmax.c
===
--- clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/policy/non-overloaded/vsetvlmax.c
+++ clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/policy/non-overloaded/vsetvlmax.c
@@ -12,7 +12,7 @@
 // CHECK-RV64-NEXT:ret i64 [[TMP0]]
 //
 size_t test_vsetvlmax_e8mf8() {
-  return vsetvlmax_e8mf8();
+  return __riscv_vsetvlmax_e8mf8();
 }
 
 // CHECK-RV64-LABEL: @test_vsetvlmax_e8mf4(
@@ -21,7 +21,7 @@
 // CHECK-RV64-NEXT:ret i64 [[TMP0]]
 //
 size_t test_vsetvlmax_e8mf4() {
-  return vsetvlmax_e8mf4();
+  return __riscv_vsetvlmax_e8mf4();
 }
 
 // CHECK-RV64-LABEL: @test_vsetvlmax_e8mf2(
@@ -30,7 +30,7 @@
 // CHECK-RV64-NEXT:ret i64 [[TMP0]]
 //
 size_t test_vsetvlmax_e8mf2() {
-  return vsetvlmax_e8mf2();
+  return __riscv_vsetvlmax_e8mf2();
 }
 
 // CHECK-RV64-LABEL: @test_vsetvlmax_e8m1(
@@ -39,7 +39,7 @@
 // CHECK-RV64-NEXT:ret i64 [[TMP0]]
 //
 size_t test_vsetvlmax_e8m1() {
-  return vsetvlmax_e8m1();
+  return __riscv_vsetvlmax_e8m1();
 }
 
 // CHECK-RV64-LABEL: @test_vsetvlmax_e8m2(
@@ -48,7 +48,7 @@
 // CHECK-RV64-NEXT:ret i64 [[TMP0]]
 //
 size_t test_vsetvlmax_e8m2() {
-  return vsetvlmax_e8m2();
+  return __riscv_vsetvlmax_e8m2();
 }
 
 // CHECK-RV64-LABEL: @test_vsetvlmax_e8m4(
@@ -57,7 +57,7 @@
 // CHECK-RV64-NEXT:ret i64 [[TMP0]]
 //
 size_t test_vsetvlmax_e8m4() {
-  return vsetvlmax_e8m4();
+  return __riscv_vsetvlmax_e8m4();
 }
 
 // CHECK-RV64-LABEL: @test_vsetvlmax_e8m8(
@@ -66,7 +66,7 @@
 // CHECK-RV64-NEXT:ret i64 [[TMP0]]
 //
 size_t test_vsetvlmax_e8m8() {
-  return vsetvlmax_e8m8();
+  return __riscv_vsetvlmax_e8m8();
 }
 
 // CHECK-RV64-LABEL: @test_vsetvlmax_

[clang] 54b40a1 - [1/3][Clang][RISCV] Add `__riscv_` prefix for vread, vwrite, vlenb, vsetvl, and vsetvlmax

2023-01-31 Thread via cfe-commits

Author: eopXD
Date: 2023-01-31T01:06:03-08:00
New Revision: 54b40a1785e9e7602fd69cd274cb46fc5746e029

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

LOG: [1/3][Clang][RISCV] Add `__riscv_` prefix for vread, vwrite, vlenb, 
vsetvl, and vsetvlmax

This commit adds prefix for intrinsics that are defined through
`HeaderCode` under `riscv_vector.td`.

This is the 1st commit of a patch-set to add `__riscv_` for all RVV
intrinsics.

This follows the naming guideline under riscv-c-api-doc to add the
`__riscv_` suffix for all RVV intrinsics.

Pull Request:
riscv-non-isa/riscv-c-api-doc#31
riscv-non-isa/rvv-intrinsic-doc#189

Depends on D142016.

Reviewed By: kito-cheng

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

Added: 


Modified: 
clang/include/clang/Basic/riscv_vector.td

clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vsetvl.c

clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vsetvlmax.c

clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/policy/non-overloaded/vsetvl.c

clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/policy/non-overloaded/vsetvlmax.c
clang/test/CodeGen/RISCV/rvv-intrinsics-handcrafted/vread-csr.c
clang/test/CodeGen/RISCV/rvv-intrinsics-handcrafted/vwrite-csr.c

Removed: 




diff  --git a/clang/include/clang/Basic/riscv_vector.td 
b/clang/include/clang/Basic/riscv_vector.td
index c63cba9aa459f..b23e26ecaa579 100644
--- a/clang/include/clang/Basic/riscv_vector.td
+++ b/clang/include/clang/Basic/riscv_vector.td
@@ -1539,7 +1539,7 @@ enum RVV_CSR {
 };
 
 static __inline__ __attribute__((__always_inline__, __nodebug__))
-unsigned long vread_csr(enum RVV_CSR __csr) {
+unsigned long __riscv_vread_csr(enum RVV_CSR __csr) {
   unsigned long __rv = 0;
   switch (__csr) {
 case RVV_VSTART:
@@ -1559,7 +1559,7 @@ unsigned long vread_csr(enum RVV_CSR __csr) {
 }
 
 static __inline__ __attribute__((__always_inline__, __nodebug__))
-void vwrite_csr(enum RVV_CSR __csr, unsigned long __value) {
+void __riscv_vwrite_csr(enum RVV_CSR __csr, unsigned long __value) {
   switch (__csr) {
 case RVV_VSTART:
   __asm__ __volatile__ ("csrw\tvstart, %z0" : : "rJ"(__value) : "memory");
@@ -1580,7 +1580,7 @@ def vread_vwrite_csr: RVVHeader;
 
 let HeaderCode =
 [{
-#define vlenb() __builtin_rvv_vlenb()
+#define __riscv_vlenb() __builtin_rvv_vlenb()
 }] in
 def vlenb_macro: RVVHeader;
 
@@ -1611,62 +1611,62 @@ let HasBuiltinAlias = false, HasVL = false, HasMasked = 
false,
 // and LMUL.
 let HeaderCode =
 [{
-#define vsetvl_e8mf4(avl) __builtin_rvv_vsetvli((size_t)(avl), 0, 6)
-#define vsetvl_e8mf2(avl) __builtin_rvv_vsetvli((size_t)(avl), 0, 7)
-#define vsetvl_e8m1(avl) __builtin_rvv_vsetvli((size_t)(avl), 0, 0)
-#define vsetvl_e8m2(avl) __builtin_rvv_vsetvli((size_t)(avl), 0, 1)
-#define vsetvl_e8m4(avl) __builtin_rvv_vsetvli((size_t)(avl), 0, 2)
-#define vsetvl_e8m8(avl) __builtin_rvv_vsetvli((size_t)(avl), 0, 3)
-
-#define vsetvl_e16mf2(avl) __builtin_rvv_vsetvli((size_t)(avl), 1, 7)
-#define vsetvl_e16m1(avl) __builtin_rvv_vsetvli((size_t)(avl), 1, 0)
-#define vsetvl_e16m2(avl) __builtin_rvv_vsetvli((size_t)(avl), 1, 1)
-#define vsetvl_e16m4(avl) __builtin_rvv_vsetvli((size_t)(avl), 1, 2)
-#define vsetvl_e16m8(avl) __builtin_rvv_vsetvli((size_t)(avl), 1, 3)
-
-#define vsetvl_e32m1(avl) __builtin_rvv_vsetvli((size_t)(avl), 2, 0)
-#define vsetvl_e32m2(avl) __builtin_rvv_vsetvli((size_t)(avl), 2, 1)
-#define vsetvl_e32m4(avl) __builtin_rvv_vsetvli((size_t)(avl), 2, 2)
-#define vsetvl_e32m8(avl) __builtin_rvv_vsetvli((size_t)(avl), 2, 3)
+#define __riscv_vsetvl_e8mf4(avl) __builtin_rvv_vsetvli((size_t)(avl), 0, 6)
+#define __riscv_vsetvl_e8mf2(avl) __builtin_rvv_vsetvli((size_t)(avl), 0, 7)
+#define __riscv_vsetvl_e8m1(avl) __builtin_rvv_vsetvli((size_t)(avl), 0, 0)
+#define __riscv_vsetvl_e8m2(avl) __builtin_rvv_vsetvli((size_t)(avl), 0, 1)
+#define __riscv_vsetvl_e8m4(avl) __builtin_rvv_vsetvli((size_t)(avl), 0, 2)
+#define __riscv_vsetvl_e8m8(avl) __builtin_rvv_vsetvli((size_t)(avl), 0, 3)
+
+#define __riscv_vsetvl_e16mf2(avl) __builtin_rvv_vsetvli((size_t)(avl), 1, 7)
+#define __riscv_vsetvl_e16m1(avl) __builtin_rvv_vsetvli((size_t)(avl), 1, 0)
+#define __riscv_vsetvl_e16m2(avl) __builtin_rvv_vsetvli((size_t)(avl), 1, 1)
+#define __riscv_vsetvl_e16m4(avl) __builtin_rvv_vsetvli((size_t)(avl), 1, 2)
+#define __riscv_vsetvl_e16m8(avl) __builtin_rvv_vsetvli((size_t)(avl), 1, 3)
+
+#define __riscv_vsetvl_e32m1(avl) __builtin_rvv_vsetvli((size_t)(avl), 2, 0)
+#define __riscv_vsetvl_e32m2(avl) __builtin_rvv_vsetvli((size_t)(avl), 2, 1)
+#define __riscv_vsetvl_e32m4(avl) __builtin_rvv_vsetvli((size_t)(avl), 2, 2)
+#define __riscv_vsetvl_e32m8(avl) __builtin_rvv_vsetvli((size_

[PATCH] D140011: [clang][compiler-rt] Support LLVM_ENABLE_PER_TARGET_RUNTIME_DIR on Arm Linux and BSD

2023-01-31 Thread David Spickett via Phabricator via cfe-commits
DavidSpickett updated this revision to Diff 493518.
DavidSpickett added a comment.

Remove the Armhf comment, rebase.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D140011

Files:
  clang/lib/Driver/ToolChain.cpp
  
clang/test/Driver/Inputs/arm_float_abi_runtime_path/lib/arm-pc-windows-msvc/.keep
  
clang/test/Driver/Inputs/arm_float_abi_runtime_path/lib/arm-unknown-linux-gnueabi/.keep
  
clang/test/Driver/Inputs/arm_float_abi_runtime_path/lib/arm-unknown-linux-gnueabihf/.keep
  
clang/test/Driver/Inputs/arm_float_abi_runtime_path/lib/armeb-unknown-linux-gnueabi/.keep
  
clang/test/Driver/Inputs/arm_float_abi_runtime_path/lib/armeb-unknown-linux-gnueabihf/.keep
  clang/test/Driver/arm-float-abi-runtime-path.c
  compiler-rt/cmake/Modules/CompilerRTUtils.cmake
  llvm/CMakeLists.txt

Index: llvm/CMakeLists.txt
===
--- llvm/CMakeLists.txt
+++ llvm/CMakeLists.txt
@@ -817,8 +817,7 @@
 set(LLVM_TARGET_TRIPLE_ENV CACHE STRING "The name of environment variable to override default target. Disabled by blank.")
 mark_as_advanced(LLVM_TARGET_TRIPLE_ENV)
 
-# Per target dir not yet supported on Arm 32 bit due to arm vs armhf handling
-if(CMAKE_SYSTEM_NAME MATCHES "BSD|Linux" AND NOT CMAKE_SYSTEM_PROCESSOR MATCHES "^arm")
+if(CMAKE_SYSTEM_NAME MATCHES "BSD|Linux")
   set(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR_default ON)
 else()
   set(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR_default OFF)
Index: compiler-rt/cmake/Modules/CompilerRTUtils.cmake
===
--- compiler-rt/cmake/Modules/CompilerRTUtils.cmake
+++ compiler-rt/cmake/Modules/CompilerRTUtils.cmake
@@ -433,6 +433,25 @@
 string(REGEX REPLACE "mipsisa64" "mipsisa32" triple_cpu_mips "${triple_cpu}")
 string(REGEX REPLACE "mips64" "mips" triple_cpu_mips "${triple_cpu_mips}")
 set(target "${triple_cpu_mips}${triple_suffix_gnu}")
+  elseif("${arch}" MATCHES "^arm")
+# Arch is arm, armhf, armv6m (anything else would come from using
+# COMPILER_RT_DEFAULT_TARGET_ONLY, which is checked above).
+if (${arch} STREQUAL "armhf")
+  # If we are building for hard float but our ABI is soft float.
+  if ("${triple_suffix}" MATCHES ".*eabi$")
+# Change "eabi" -> "eabihf"
+set(triple_suffix "${triple_suffix}hf")
+  endif()
+  # ABI is already set in the triple, don't repeat it in the architecture.
+  set(arch "arm")
+else ()
+  # If we are building for soft float, but the triple's ABI is hard float.
+  if ("${triple_suffix}" MATCHES ".*eabihf$")
+# Change "eabihf" -> "eabi"
+string(REGEX REPLACE "hf$" "" triple_suffix "${triple_suffix}")
+  endif()
+endif()
+set(target "${arch}${triple_suffix}")
   else()
 set(target "${arch}${triple_suffix}")
   endif()
Index: clang/test/Driver/arm-float-abi-runtime-path.c
===
--- /dev/null
+++ clang/test/Driver/arm-float-abi-runtime-path.c
@@ -0,0 +1,33 @@
+/// Check that libraries built with the per target runtime directory layout
+/// are selected correctly when using variations of Arm triples.
+
+// REQUIRES: arm-registered-target
+
+// RUN: %clang %s --target=arm-unknown-linux-gnueabihf -print-runtime-dir \
+// RUN:-resource-dir=%S/Inputs/arm_float_abi_runtime_path 2>&1 | FileCheck -check-prefix=ARMHF %s
+/// "armv7l" should be normalised to just "arm".
+// RUN: %clang %s --target=armv7l-unknown-linux-gnueabihf -print-runtime-dir \
+// RUN:-resource-dir=%S/Inputs/arm_float_abi_runtime_path 2>&1 | FileCheck -check-prefix=ARMHF %s
+
+// RUN: %clang %s --target=arm-unknown-linux-gnueabi -print-runtime-dir \
+// RUN:-resource-dir=%S/Inputs/arm_float_abi_runtime_path 2>&1 | FileCheck -check-prefix=ARM %s
+// RUN: %clang %s --target=armv7l-unknown-linux-gnueabi -print-runtime-dir \
+// RUN:-resource-dir=%S/Inputs/arm_float_abi_runtime_path 2>&1 | FileCheck -check-prefix=ARM %s
+
+/// armeb triples should be unmodified.
+// RUN: %clang %s --target=armeb-unknown-linux-gnueabihf -print-runtime-dir \
+// RUN:-resource-dir=%S/Inputs/arm_float_abi_runtime_path 2>&1 | FileCheck -check-prefix=ARMEBHF %s
+// RUN: %clang %s --target=armeb-unknown-linux-gnueabi -print-runtime-dir \
+// RUN:-resource-dir=%S/Inputs/arm_float_abi_runtime_path 2>&1 | FileCheck -check-prefix=ARMEB %s
+
+// RUN: %clang %s --target=arm-pc-windows-msvc -print-runtime-dir \
+// RUN:-resource-dir=%S/Inputs/arm_float_abi_runtime_path 2>&1 | FileCheck -check-prefix=WINDOWS %s
+/// armhf-pc... isn't recognised so just check that the float-abi option is ignored
+// RUN: %clang %s --target=arm-pc-windows-msvc -mfloat-abi=hard -print-runtime-dir \
+// RUN:-resource-dir=%S/Inputs/arm_float_abi_runtime_path 2>&1 | FileCheck -check-prefix=WINDOWS %s
+
+// ARMHF:   lib{{/|\\}

[PATCH] D141858: [clang][Interp] Fix Pointer::toAPValue() for expressions

2023-01-31 Thread Timm Bäder via Phabricator via cfe-commits
tbaeder added a comment.

Ping


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

https://reviews.llvm.org/D141858

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


[PATCH] D141591: [clang][Interp] Properly identify not-yet-defined functions

2023-01-31 Thread Timm Bäder via Phabricator via cfe-commits
tbaeder added a comment.

Ping


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

https://reviews.llvm.org/D141591

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


[PATCH] D140874: [clang][Interp] Support pointer types in compound assignment operations

2023-01-31 Thread Timm Bäder via Phabricator via cfe-commits
tbaeder added a comment.

Ping


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

https://reviews.llvm.org/D140874

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


[PATCH] D142914: [MLIR][OpenMP] Added OMPIRBuilder support for Target Data directives.

2023-01-31 Thread Kiran Chandramohan via Phabricator via cfe-commits
kiranchandramohan added a subscriber: raghavendhra.
kiranchandramohan added inline comments.



Comment at: 
mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp:1342-1382
+/// Create a constant string location from the MLIR Location information.
+static llvm::Constant *
+createSourceLocStrFromLocation(Location loc, llvm::OpenMPIRBuilder &builder,
+   StringRef name, uint32_t &strLen) {
+  if (auto fileLoc = loc.dyn_cast()) {
+StringRef fileName = fileLoc.getFilename();
+unsigned lineNo = fileLoc.getLine();

clementval wrote:
> Instead of copy pasting this from 
> `mlir/lib/Target/LLVMIR/Dialect/OpenACC/OpenACCToLLVMIRTranslation.cpp` can 
> you extract it and put it in a common shared file so bith translation can use 
> the same code without duplication?
@raghavendhra put up a patch some time back and he faced some issues. It might 
be good to check with him or may be he can comment here.
https://reviews.llvm.org/D127037
https://discourse.llvm.org/t/rfc-for-refactoring-common-code-for-openacc-and-openmp/63833


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142914

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


[PATCH] D142914: [MLIR][OpenMP] Added OMPIRBuilder support for Target Data directives.

2023-01-31 Thread Valentin Clement via Phabricator via cfe-commits
clementval added inline comments.



Comment at: 
mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp:1342-1382
+/// Create a constant string location from the MLIR Location information.
+static llvm::Constant *
+createSourceLocStrFromLocation(Location loc, llvm::OpenMPIRBuilder &builder,
+   StringRef name, uint32_t &strLen) {
+  if (auto fileLoc = loc.dyn_cast()) {
+StringRef fileName = fileLoc.getFilename();
+unsigned lineNo = fileLoc.getLine();

kiranchandramohan wrote:
> clementval wrote:
> > Instead of copy pasting this from 
> > `mlir/lib/Target/LLVMIR/Dialect/OpenACC/OpenACCToLLVMIRTranslation.cpp` can 
> > you extract it and put it in a common shared file so bith translation can 
> > use the same code without duplication?
> @raghavendhra put up a patch some time back and he faced some issues. It 
> might be good to check with him or may be he can comment here.
> https://reviews.llvm.org/D127037
> https://discourse.llvm.org/t/rfc-for-refactoring-common-code-for-openacc-and-openmp/63833
Just moving the three functions should be trivial. I'm not talking about the 
processMapOperand.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142914

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


[PATCH] D142644: [2/3][Clang][RISCV] Add `__riscv_` for non-overloaded intrinsics

2023-01-31 Thread Yueh-Ting (eop) Chen 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 rG2153544865a9: [2/3][Clang][RISCV] Add `__riscv_` for 
non-overloaded intrinsics (authored by eopXD).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142644

Files:
  clang/lib/Support/RISCVVIntrinsicUtils.cpp
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vaadd.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vaaddu.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vadc.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vadd.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vand.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vasub.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vasubu.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vcompress.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vcpop.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vdiv.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vdivu.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfabs.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfadd.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfclass.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfcvt.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfdiv.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfirst.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfmacc.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfmadd.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfmax.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfmerge.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfmin.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfmsac.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfmsub.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfmul.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfmv.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfncvt.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfneg.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfnmacc.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfnmadd.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfnmsac.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfnmsub.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfrdiv.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfrec7.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfredmax.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfredmin.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfredosum.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfredusum.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfrsqrt7.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfrsub.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfsgnj.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfsgnjn.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfsgnjx.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfslide1down.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfslide1up.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfsqrt.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfsub.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfwadd.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfwcvt.c
  
clang/test/CodeGen/RISCV/rvv-intrin

[PATCH] D140011: [clang][compiler-rt] Support LLVM_ENABLE_PER_TARGET_RUNTIME_DIR on Arm Linux and BSD

2023-01-31 Thread David Spickett 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 rGcd173cbd7cca: [clang][compiler-rt] Support 
LLVM_ENABLE_PER_TARGET_RUNTIME_DIR on Arm Linux… (authored by DavidSpickett).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D140011

Files:
  clang/lib/Driver/ToolChain.cpp
  
clang/test/Driver/Inputs/arm_float_abi_runtime_path/lib/arm-pc-windows-msvc/.keep
  
clang/test/Driver/Inputs/arm_float_abi_runtime_path/lib/arm-unknown-linux-gnueabi/.keep
  
clang/test/Driver/Inputs/arm_float_abi_runtime_path/lib/arm-unknown-linux-gnueabihf/.keep
  
clang/test/Driver/Inputs/arm_float_abi_runtime_path/lib/armeb-unknown-linux-gnueabi/.keep
  
clang/test/Driver/Inputs/arm_float_abi_runtime_path/lib/armeb-unknown-linux-gnueabihf/.keep
  clang/test/Driver/arm-float-abi-runtime-path.c
  compiler-rt/cmake/Modules/CompilerRTUtils.cmake
  llvm/CMakeLists.txt

Index: llvm/CMakeLists.txt
===
--- llvm/CMakeLists.txt
+++ llvm/CMakeLists.txt
@@ -817,8 +817,7 @@
 set(LLVM_TARGET_TRIPLE_ENV CACHE STRING "The name of environment variable to override default target. Disabled by blank.")
 mark_as_advanced(LLVM_TARGET_TRIPLE_ENV)
 
-# Per target dir not yet supported on Arm 32 bit due to arm vs armhf handling
-if(CMAKE_SYSTEM_NAME MATCHES "BSD|Linux" AND NOT CMAKE_SYSTEM_PROCESSOR MATCHES "^arm")
+if(CMAKE_SYSTEM_NAME MATCHES "BSD|Linux")
   set(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR_default ON)
 else()
   set(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR_default OFF)
Index: compiler-rt/cmake/Modules/CompilerRTUtils.cmake
===
--- compiler-rt/cmake/Modules/CompilerRTUtils.cmake
+++ compiler-rt/cmake/Modules/CompilerRTUtils.cmake
@@ -433,6 +433,25 @@
 string(REGEX REPLACE "mipsisa64" "mipsisa32" triple_cpu_mips "${triple_cpu}")
 string(REGEX REPLACE "mips64" "mips" triple_cpu_mips "${triple_cpu_mips}")
 set(target "${triple_cpu_mips}${triple_suffix_gnu}")
+  elseif("${arch}" MATCHES "^arm")
+# Arch is arm, armhf, armv6m (anything else would come from using
+# COMPILER_RT_DEFAULT_TARGET_ONLY, which is checked above).
+if (${arch} STREQUAL "armhf")
+  # If we are building for hard float but our ABI is soft float.
+  if ("${triple_suffix}" MATCHES ".*eabi$")
+# Change "eabi" -> "eabihf"
+set(triple_suffix "${triple_suffix}hf")
+  endif()
+  # ABI is already set in the triple, don't repeat it in the architecture.
+  set(arch "arm")
+else ()
+  # If we are building for soft float, but the triple's ABI is hard float.
+  if ("${triple_suffix}" MATCHES ".*eabihf$")
+# Change "eabihf" -> "eabi"
+string(REGEX REPLACE "hf$" "" triple_suffix "${triple_suffix}")
+  endif()
+endif()
+set(target "${arch}${triple_suffix}")
   else()
 set(target "${arch}${triple_suffix}")
   endif()
Index: clang/test/Driver/arm-float-abi-runtime-path.c
===
--- /dev/null
+++ clang/test/Driver/arm-float-abi-runtime-path.c
@@ -0,0 +1,33 @@
+/// Check that libraries built with the per target runtime directory layout
+/// are selected correctly when using variations of Arm triples.
+
+// REQUIRES: arm-registered-target
+
+// RUN: %clang %s --target=arm-unknown-linux-gnueabihf -print-runtime-dir \
+// RUN:-resource-dir=%S/Inputs/arm_float_abi_runtime_path 2>&1 | FileCheck -check-prefix=ARMHF %s
+/// "armv7l" should be normalised to just "arm".
+// RUN: %clang %s --target=armv7l-unknown-linux-gnueabihf -print-runtime-dir \
+// RUN:-resource-dir=%S/Inputs/arm_float_abi_runtime_path 2>&1 | FileCheck -check-prefix=ARMHF %s
+
+// RUN: %clang %s --target=arm-unknown-linux-gnueabi -print-runtime-dir \
+// RUN:-resource-dir=%S/Inputs/arm_float_abi_runtime_path 2>&1 | FileCheck -check-prefix=ARM %s
+// RUN: %clang %s --target=armv7l-unknown-linux-gnueabi -print-runtime-dir \
+// RUN:-resource-dir=%S/Inputs/arm_float_abi_runtime_path 2>&1 | FileCheck -check-prefix=ARM %s
+
+/// armeb triples should be unmodified.
+// RUN: %clang %s --target=armeb-unknown-linux-gnueabihf -print-runtime-dir \
+// RUN:-resource-dir=%S/Inputs/arm_float_abi_runtime_path 2>&1 | FileCheck -check-prefix=ARMEBHF %s
+// RUN: %clang %s --target=armeb-unknown-linux-gnueabi -print-runtime-dir \
+// RUN:-resource-dir=%S/Inputs/arm_float_abi_runtime_path 2>&1 | FileCheck -check-prefix=ARMEB %s
+
+// RUN: %clang %s --target=arm-pc-windows-msvc -print-runtime-dir \
+// RUN:-resource-dir=%S/Inputs/arm_float_abi_runtime_path 2>&1 | FileCheck -check-prefix=WINDOWS %s
+/// armhf-pc... isn't recognised so just check that the float-abi option is ignored
+// RUN: %clang %s --target=arm-pc-windows-msvc -mfloat-abi=hard -pr

[clang] cd173cb - [clang][compiler-rt] Support LLVM_ENABLE_PER_TARGET_RUNTIME_DIR on Arm Linux and BSD

2023-01-31 Thread David Spickett via cfe-commits

Author: David Spickett
Date: 2023-01-31T09:49:56Z
New Revision: cd173cbd7cca69c29df42cd4b42e60433435c29b

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

LOG: [clang][compiler-rt] Support LLVM_ENABLE_PER_TARGET_RUNTIME_DIR on Arm 
Linux and BSD

The orginal single folder layout produced libraries in the form:
lib/linux/-.a

That archname for Arm depended on whether you had hard or soft float.
This is sometimes shown as "arm" (soft) vs. "armhf" (hard).

If this is set in a triple we do it in the final portion, the ABI.
"gnueabi" for soft float, "gnueabihf" for hard float.

Meaning that the expected triple is:
arm-unknown-linux-gnueabihf
Not this:
armhf-unknown-linux-gnueabihf

For the per target layout I have decided to rely on the ABI portion
of the triple instead of the arch name used for the old layout
(doing that would produce the invalid triple above).

This means that building with triple:
armv8l-unknown-linux-gnueabihf
Will result in libraries in:
lib/arm-unknown-linux-gnueabihf/

And clang will now know to look for "arm" instead of "armv8l".
Meaning that we can share libraries between an armv8 and armv7 build
as we did with the previous layout. In addition to handling spelling
differences e.g. "armv8l" with an "l" on some Linux distros.

compiler-rt will autodetect that the "armhf" and/or "arm" architecture
can be built. We then replace the given triple's architecture with that.
Then if the triple's float ABI doesn't match, we change that. That new
triple is then used as the folder name.

If you select to build only the given triple, with 
COMPILER_RT_DEFAULT_TARGET_ONLY,
compiler-rt will not autodetect the architecture and for that I assume you
know what you're doing. In that case the library path will use the unomdified 
triple.

>From what I can tell, this is how most large builds e.g Android and
Arm's Embedded Toolchain for llvm do things. I assume that big endian "armeb"
builds would end up doing this too.

Bare metal builds will not be using per target runtime dirs so they
remain as they were.

Depends on D139536

Reviewed By: MaskRay, phosek

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

Added: 

clang/test/Driver/Inputs/arm_float_abi_runtime_path/lib/arm-pc-windows-msvc/.keep

clang/test/Driver/Inputs/arm_float_abi_runtime_path/lib/arm-unknown-linux-gnueabi/.keep

clang/test/Driver/Inputs/arm_float_abi_runtime_path/lib/arm-unknown-linux-gnueabihf/.keep

clang/test/Driver/Inputs/arm_float_abi_runtime_path/lib/armeb-unknown-linux-gnueabi/.keep

clang/test/Driver/Inputs/arm_float_abi_runtime_path/lib/armeb-unknown-linux-gnueabihf/.keep
clang/test/Driver/arm-float-abi-runtime-path.c

Modified: 
clang/lib/Driver/ToolChain.cpp
compiler-rt/cmake/Modules/CompilerRTUtils.cmake
llvm/CMakeLists.txt

Removed: 




diff  --git a/clang/lib/Driver/ToolChain.cpp b/clang/lib/Driver/ToolChain.cpp
index bc70205a6c01e..61cedea6cfe08 100644
--- a/clang/lib/Driver/ToolChain.cpp
+++ b/clang/lib/Driver/ToolChain.cpp
@@ -578,6 +578,27 @@ ToolChain::path_list ToolChain::getRuntimePaths() const {
 
   addPathForTriple(getTriple());
 
+  // When building with per target runtime directories, various ways of naming
+  // the Arm architecture may have been normalised to simply "arm".
+  // For example "armv8l" (Armv8 AArch32 little endian) is replaced with "arm".
+  // Since an armv8l system can use libraries built for earlier architecture
+  // versions assuming endian and float ABI match.
+  //
+  // Original triple: armv8l-unknown-linux-gnueabihf
+  //  Runtime triple: arm-unknown-linux-gnueabihf
+  //
+  // We do not do this for armeb (big endian) because doing so could make us
+  // select little endian libraries. In addition, all known armeb triples only
+  // use the "armeb" architecture name.
+  //
+  // M profile Arm is bare metal and we know they will not be using the per
+  // target runtime directory layout.
+  if (getTriple().getArch() == Triple::arm && !getTriple().isArmMClass()) {
+llvm::Triple ArmTriple = getTriple();
+ArmTriple.setArch(Triple::arm);
+addPathForTriple(ArmTriple);
+  }
+
   // Android targets may include an API level at the end. We still want to fall
   // back on a path without the API level.
   if (getTriple().isAndroid() &&

diff  --git 
a/clang/test/Driver/Inputs/arm_float_abi_runtime_path/lib/arm-pc-windows-msvc/.keep
 
b/clang/test/Driver/Inputs/arm_float_abi_runtime_path/lib/arm-pc-windows-msvc/.keep
new file mode 100644
index 0..e69de29bb2d1d

diff  --git 
a/clang/test/Driver/Inputs/arm_float_abi_runtime_path/lib/arm-unknown-linux-gnueabi/.keep
 
b/clang/test/Driver/Inputs/arm_float_abi_runtime_path/lib/arm-unknown-linux-gnueabi/.keep
new file mode 100644
index 0..e69de29bb2d1d


[PATCH] D142327: [clang][RISCV] Fix ABI handling of empty structs with hard FP calling conventions in C++

2023-01-31 Thread Alex Bradbury via Phabricator via cfe-commits
asb added a comment.

In D142327#4080044 , @asb wrote:

> Thanks Luis for the quick review. As an important part of this is trying to 
> align with gcc/g++ I'd really appreciate a review from @kito-cheng too if you 
> have the time (thanks in advance!).

Friendly ping to Kito as I spotted you mentioned you're back from vacation!


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

https://reviews.llvm.org/D142327

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


[clang] d708a18 - [Clang] Implement Change scope of lambda trailing-return-type

2023-01-31 Thread Corentin Jabot via cfe-commits

Author: Corentin Jabot
Date: 2023-01-31T11:06:14+01:00
New Revision: d708a186b6a9b050d09558163dd353d9f738c82d

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

LOG: [Clang] Implement Change scope of lambda trailing-return-type

This implements P2036R3 and P2579R0.
That is, explicit, int, and implicit capture become visible
at the start of the parameter head.

Reviewed By: aaron.ballman

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

Added: 
clang/test/SemaCXX/lambda-capture-type-deduction.cpp

Modified: 
clang/docs/ReleaseNotes.rst
clang/include/clang/AST/DeclCXX.h
clang/include/clang/Sema/Scope.h
clang/include/clang/Sema/ScopeInfo.h
clang/include/clang/Sema/Sema.h
clang/lib/Parse/ParseExprCXX.cpp
clang/lib/Sema/Scope.cpp
clang/lib/Sema/Sema.cpp
clang/lib/Sema/SemaCXXScopeSpec.cpp
clang/lib/Sema/SemaConcept.cpp
clang/lib/Sema/SemaExpr.cpp
clang/lib/Sema/SemaExprCXX.cpp
clang/lib/Sema/SemaLambda.cpp
clang/lib/Sema/SemaTemplateInstantiate.cpp
clang/lib/Sema/TreeTransform.h
clang/test/CXX/expr/expr.prim/expr.prim.lambda/p11-1y.cpp
clang/test/CXX/expr/expr.prim/expr.prim.lambda/p4.cpp
clang/test/SemaCXX/warn-shadow-in-lambdas.cpp
clang/www/cxx_status.html

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 94b466122a348..fe418d938650a 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -110,6 +110,11 @@ C++20 Feature Support
 C++2b Feature Support
 ^
 
+- Implemented `P2036R3: Change scope of lambda trailing-return-type 
`_
+  and `P2579R0 Mitigation strategies for P2036 `_.
+  This proposals modify how variables captured in lambdas can appear in 
trailing return type
+  expressions and how their types are deduced therein, in all C++ language 
versions.
+
 CUDA/HIP Language Changes in Clang
 --
 

diff  --git a/clang/include/clang/AST/DeclCXX.h 
b/clang/include/clang/AST/DeclCXX.h
index 11276c77490ce..ff8f8a1bb12d6 100644
--- a/clang/include/clang/AST/DeclCXX.h
+++ b/clang/include/clang/AST/DeclCXX.h
@@ -1092,6 +1092,11 @@ class CXXRecordDecl : public RecordDecl {
 
   unsigned capture_size() const { return getLambdaData().NumCaptures; }
 
+  const LambdaCapture *getCapture(unsigned I) const {
+assert(isLambda() && I < capture_size() && "invalid index for capture");
+return captures_begin() + I;
+  }
+
   using conversion_iterator = UnresolvedSetIterator;
 
   conversion_iterator conversion_begin() const {
@@ -1826,6 +1831,20 @@ class CXXRecordDecl : public RecordDecl {
 return getLambdaData().MethodTyInfo;
   }
 
+  void setLambdaTypeInfo(TypeSourceInfo *TS) {
+assert(DefinitionData && DefinitionData->IsLambda &&
+   "setting lambda property of non-lambda class");
+auto &DL = static_cast(*DefinitionData);
+DL.MethodTyInfo = TS;
+  }
+
+  void setLambdaIsGeneric(bool IsGeneric) {
+assert(DefinitionData && DefinitionData->IsLambda &&
+   "setting lambda property of non-lambda class");
+auto &DL = static_cast(*DefinitionData);
+DL.IsGenericLambda = IsGeneric;
+  }
+
   // Determine whether this type is an Interface Like type for
   // __interface inheritance purposes.
   bool isInterfaceLike() const;

diff  --git a/clang/include/clang/Sema/Scope.h 
b/clang/include/clang/Sema/Scope.h
index be5cdb62045b1..9e81706cd2aa1 100644
--- a/clang/include/clang/Sema/Scope.h
+++ b/clang/include/clang/Sema/Scope.h
@@ -145,6 +145,11 @@ class Scope {
 /// This is a scope of some OpenMP directive with
 /// order clause which specifies concurrent
 OpenMPOrderClauseScope = 0x400,
+/// This is the scope for a lambda, after the lambda introducer.
+/// Lambdas need two FunctionPrototypeScope scopes (because there is a
+/// template scope in between), the outer scope does not increase the
+/// depth of recursion.
+LambdaScope = 0x800,
   };
 
 private:

diff  --git a/clang/include/clang/Sema/ScopeInfo.h 
b/clang/include/clang/Sema/ScopeInfo.h
index 65fa18fbb2903..5888dee0a883d 100644
--- a/clang/include/clang/Sema/ScopeInfo.h
+++ b/clang/include/clang/Sema/ScopeInfo.h
@@ -838,6 +838,11 @@ class LambdaScopeInfo final :
   /// The lambda's compiler-generated \c operator().
   CXXMethodDecl *CallOperator = nullptr;
 
+  /// Indicate that we parsed the parameter list
+  /// at which point the mutability of the lambda
+  /// is known.
+  bool AfterParameterList = true;
+
   /// Source range covering the lambda introducer [...].
   SourceRange IntroducerRange;
 
@@ -849,8 +854,9 @@ class LambdaScopeInfo final :
   /// explicit captures.
   unsigned NumExplicitCaptures = 0

[PATCH] D124351: [Clang] Implement Change scope of lambda trailing-return-type

2023-01-31 Thread Corentin Jabot 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 rGd708a186b6a9: [Clang] Implement Change scope of lambda 
trailing-return-type (authored by cor3ntin).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124351

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/AST/DeclCXX.h
  clang/include/clang/Sema/Scope.h
  clang/include/clang/Sema/ScopeInfo.h
  clang/include/clang/Sema/Sema.h
  clang/lib/Parse/ParseExprCXX.cpp
  clang/lib/Sema/Scope.cpp
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaCXXScopeSpec.cpp
  clang/lib/Sema/SemaConcept.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/lib/Sema/SemaLambda.cpp
  clang/lib/Sema/SemaTemplateInstantiate.cpp
  clang/lib/Sema/TreeTransform.h
  clang/test/CXX/expr/expr.prim/expr.prim.lambda/p11-1y.cpp
  clang/test/CXX/expr/expr.prim/expr.prim.lambda/p4.cpp
  clang/test/SemaCXX/lambda-capture-type-deduction.cpp
  clang/test/SemaCXX/warn-shadow-in-lambdas.cpp
  clang/www/cxx_status.html

Index: clang/www/cxx_status.html
===
--- clang/www/cxx_status.html
+++ clang/www/cxx_status.html
@@ -1358,7 +1358,7 @@
 
   Change scope of lambda trailing-return-type
   https://wg21.link/P2036R3";>P2036R3
-  No
+  Clang 17
 
 
   https://wg21.link/P2579R0";>P2579R0
Index: clang/test/SemaCXX/warn-shadow-in-lambdas.cpp
===
--- clang/test/SemaCXX/warn-shadow-in-lambdas.cpp
+++ clang/test/SemaCXX/warn-shadow-in-lambdas.cpp
@@ -95,7 +95,7 @@
 #ifdef AVOID
   auto l4 = [var = param] (int param) { ; }; // no warning
 #else
-  auto l4 = [var = param] (int param) { ; }; // expected-warning {{declaration shadows a local variable}}
+  auto l4 = [var = param](int param) { ; }; // expected-warning 2{{declaration shadows a local variable}}
 #endif
 
   // Make sure that inner lambdas work as well.
Index: clang/test/SemaCXX/lambda-capture-type-deduction.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/lambda-capture-type-deduction.cpp
@@ -0,0 +1,243 @@
+// RUN: %clang_cc1 -std=c++2b -verify -fsyntax-only %s
+
+template 
+constexpr bool is_same = false;
+
+template 
+constexpr bool is_same = true;
+
+void f() {
+
+  int y;
+
+  static_assert(is_same decltype((x)) { return x; }())>);
+
+  static_assert(is_same decltype((x)) { return x; }())>);
+
+  static_assert(is_same decltype((y)) { return y; }())>);
+
+  static_assert(is_same decltype((y)) { return y; }())>);
+
+  static_assert(is_same decltype((y)) { return y; }())>);
+
+  static_assert(is_same decltype((y)) { return y; }())>);
+
+  auto ref = [&x = y](
+ decltype([&](decltype(x)) { return 0; }) y) {
+return x;
+  };
+}
+
+void test_noexcept() {
+
+  int y;
+
+  static_assert(noexcept([x = 1] noexcept(is_same) {}()));
+  static_assert(noexcept([x = 1] mutable noexcept(is_same) {}()));
+  static_assert(noexcept([y] noexcept(is_same) {}()));
+  static_assert(noexcept([y] mutable noexcept(is_same) {}()));
+  static_assert(noexcept([=] noexcept(is_same) {}()));
+  static_assert(noexcept([=] mutable noexcept(is_same) {}()));
+  static_assert(noexcept([&] noexcept(is_same) {}()));
+  static_assert(noexcept([&] mutable noexcept(is_same) {}()));
+}
+
+void test_requires() {
+
+  int x;
+
+  [x = 1]() requires is_same {}
+  ();
+  [x = 1]() mutable requires is_same {}
+  ();
+  [x]() requires is_same {}
+  ();
+  [x]() mutable requires is_same {}
+  ();
+  [=]() requires is_same {}
+  ();
+  [=]() mutable requires is_same {}
+  ();
+  [&]() requires is_same {}
+  ();
+  [&]() mutable requires is_same {}
+  ();
+  [&x]() requires is_same {}
+  ();
+  [&x]() mutable requires is_same {}
+  ();
+
+  [x = 1]() requires is_same {} ();
+  [x = 1]() mutable requires is_same {} ();
+}
+
+void err() {
+  int y, z;
+  (void)[x = 1]
+  requires(is_same) {};
+
+  (void)[x = 1]{};
+
+  (void)[=]{};
+
+  (void)[z]{};
+}
+
+void gnu_attributes() {
+  int y;
+  (void)[=]() __attribute__((diagnose_if(!is_same, "wrong type", "warning"))){}();
+  // expected-warning@-1 {{wrong type}} expected-note@-1{{'diagnose_if' attribute on 'operator()'}}
+  (void)[=]() __attribute__((diagnose_if(!is_same, "wrong type", "warning"))){}();
+
+  (void)[=]() __attribute__((diagnose_if(!is_same, "wrong type", "warning"))) mutable {}();
+  (void)[=]() __attribute__((diagnose_if(!is_same, "wrong type", "warning"))) mutable {}();
+  // expected-warning@-1 {{wrong type}} expected-note@-1{{'diagnose_if' attribute on 'operator()'}}
+
+
+  (void)[x=1]() __attribute__((diagnose_if(!is_same, "wrong type", "warning"))){}();
+  // expected-warning@-1 {{wrong type}} expected-note@-1{{'diagnose_if' attribute on 'operator()'}}
+  (void)[x=1]() __attribute__((di

[PATCH] D124351: [Clang] Implement Change scope of lambda trailing-return-type

2023-01-31 Thread Corentin Jabot via Phabricator via cfe-commits
cor3ntin added a comment.

@aaron.ballman Thanks for the review! I hope we won't find further issue with 
the paper this time :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124351

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


[PATCH] D142967: [clangd] Introduce source.organizeImports code action.

2023-01-31 Thread Haojian Wu via Phabricator via cfe-commits
hokein created this revision.
hokein added a reviewer: kadircet.
Herald added a subscriber: arphaman.
Herald added a project: All.
hokein requested review of this revision.
Herald added subscribers: MaskRay, ilya-biryukov.
Herald added a project: clang-tools-extra.

This would provide us a way to apply unused-includes fixts at once via
the right-click "Source Action" menu or "Organize imports" command
in VSCode.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D142967

Files:
  clang-tools-extra/clangd/ClangdLSPServer.cpp
  clang-tools-extra/clangd/Protocol.cpp
  clang-tools-extra/clangd/Protocol.h


Index: clang-tools-extra/clangd/Protocol.h
===
--- clang-tools-extra/clangd/Protocol.h
+++ clang-tools-extra/clangd/Protocol.h
@@ -1022,6 +1022,7 @@
   const static llvm::StringLiteral QUICKFIX_KIND;
   const static llvm::StringLiteral REFACTOR_KIND;
   const static llvm::StringLiteral INFO_KIND;
+  const static llvm::StringLiteral SOURCE_ORGANIZE_IMPORT;
 
   /// The diagnostics that this code action resolves.
   std::optional> diagnostics;
Index: clang-tools-extra/clangd/Protocol.cpp
===
--- clang-tools-extra/clangd/Protocol.cpp
+++ clang-tools-extra/clangd/Protocol.cpp
@@ -819,6 +819,7 @@
 const llvm::StringLiteral CodeAction::QUICKFIX_KIND = "quickfix";
 const llvm::StringLiteral CodeAction::REFACTOR_KIND = "refactor";
 const llvm::StringLiteral CodeAction::INFO_KIND = "info";
+const llvm::StringLiteral CodeAction::SOURCE_ORGANIZE_IMPORT = 
"source.organizeImports";
 
 llvm::json::Value toJSON(const CodeAction &CA) {
   auto CodeAction = llvm::json::Object{{"title", CA.title}};
Index: clang-tools-extra/clangd/ClangdLSPServer.cpp
===
--- clang-tools-extra/clangd/ClangdLSPServer.cpp
+++ clang-tools-extra/clangd/ClangdLSPServer.cpp
@@ -611,7 +611,8 @@
   ? llvm::json::Object{{"codeActionKinds",
 {CodeAction::QUICKFIX_KIND,
  CodeAction::REFACTOR_KIND,
- CodeAction::INFO_KIND}}}
+ CodeAction::INFO_KIND,
+ CodeAction::SOURCE_ORGANIZE_IMPORT}}}
   : llvm::json::Value(true);
 
 
@@ -988,6 +989,26 @@
   }
 }
   }
+  if (KindAllowed(CodeAction::SOURCE_ORGANIZE_IMPORT)) {
+std::lock_guard Lock(FixItsMutex);
+if (auto FileFixItsIter = FixItsMap.find(File.file());
+FileFixItsIter != FixItsMap.end()) {
+  std::vector Edits;
+  for (auto &[Diag, Fixes] : FileFixItsIter->second) {
+if (Diag.source == "clangd" && Diag.code == "unused-includes")
+  for (auto &F : Fixes)
+std::copy(F.Edits.begin(), F.Edits.end(),
+  std::back_inserter(Edits));
+  }
+  if (!Edits.empty()) {
+FixIts.emplace_back();
+FixIts.back().title = "remove unusded includes";
+FixIts.back().kind = std::string(CodeAction::SOURCE_ORGANIZE_IMPORT);
+FixIts.back().edit.emplace();
+FixIts.back().edit->changes[File.uri()] = std::move(Edits);
+  }
+}
+  }
 
   // Now enumerate the semantic code actions.
   auto ConsumeActions =


Index: clang-tools-extra/clangd/Protocol.h
===
--- clang-tools-extra/clangd/Protocol.h
+++ clang-tools-extra/clangd/Protocol.h
@@ -1022,6 +1022,7 @@
   const static llvm::StringLiteral QUICKFIX_KIND;
   const static llvm::StringLiteral REFACTOR_KIND;
   const static llvm::StringLiteral INFO_KIND;
+  const static llvm::StringLiteral SOURCE_ORGANIZE_IMPORT;
 
   /// The diagnostics that this code action resolves.
   std::optional> diagnostics;
Index: clang-tools-extra/clangd/Protocol.cpp
===
--- clang-tools-extra/clangd/Protocol.cpp
+++ clang-tools-extra/clangd/Protocol.cpp
@@ -819,6 +819,7 @@
 const llvm::StringLiteral CodeAction::QUICKFIX_KIND = "quickfix";
 const llvm::StringLiteral CodeAction::REFACTOR_KIND = "refactor";
 const llvm::StringLiteral CodeAction::INFO_KIND = "info";
+const llvm::StringLiteral CodeAction::SOURCE_ORGANIZE_IMPORT = "source.organizeImports";
 
 llvm::json::Value toJSON(const CodeAction &CA) {
   auto CodeAction = llvm::json::Object{{"title", CA.title}};
Index: clang-tools-extra/clangd/ClangdLSPServer.cpp
===
--- clang-tools-extra/clangd/ClangdLSPServer.cpp
+++ clang-tools-extra/clangd/ClangdLSPServer.cpp
@@ -611,7 +611,8 @@
   ? llvm::json::Object{{"codeActionKinds",
 {CodeAction::QUICKFIX_KIND,
  CodeAction::REFACTOR_KIND,
- CodeAction::INFO_KIND}}}
+ CodeAction::INFO_KIND,

[PATCH] D142644: [2/3][Clang][RISCV] Add `__riscv_` for non-overloaded intrinsics

2023-01-31 Thread Yueh-Ting (eop) Chen via Phabricator via cfe-commits
eopXD reopened this revision.
eopXD added a comment.
This revision is now accepted and ready to land.

Previous landing was reverted because of test case `Clang :: 
Sema/uninit-variables-riscv-vector.c` that was not updated, causing failure. 
Reopening to land this patch correctly.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142644

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


[PATCH] D142644: [2/3][Clang][RISCV] Add `__riscv_` for non-overloaded intrinsics

2023-01-31 Thread Yueh-Ting (eop) Chen via Phabricator via cfe-commits
eopXD updated this revision to Diff 493533.
eopXD added a comment.

Update test case `Sema/uninit-variables-riscv-vector.c`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142644

Files:
  clang/lib/Support/RISCVVIntrinsicUtils.cpp
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vaadd.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vaaddu.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vadc.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vadd.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vand.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vasub.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vasubu.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vcompress.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vcpop.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vdiv.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vdivu.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfabs.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfadd.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfclass.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfcvt.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfdiv.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfirst.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfmacc.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfmadd.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfmax.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfmerge.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfmin.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfmsac.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfmsub.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfmul.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfmv.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfncvt.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfneg.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfnmacc.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfnmadd.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfnmsac.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfnmsub.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfrdiv.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfrec7.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfredmax.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfredmin.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfredosum.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfredusum.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfrsqrt7.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfrsub.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfsgnj.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfsgnjn.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfsgnjx.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfslide1down.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfslide1up.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfsqrt.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfsub.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfwadd.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfwcvt.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfwmacc.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/n

[PATCH] D142644: [2/3][Clang][RISCV] Add `__riscv_` for non-overloaded intrinsics

2023-01-31 Thread Yueh-Ting (eop) Chen 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 rG013c7d1f3a13: [2/3][Clang][RISCV] Add `__riscv_` for 
non-overloaded intrinsics (authored by eopXD).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142644

Files:
  clang/lib/Support/RISCVVIntrinsicUtils.cpp
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vaadd.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vaaddu.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vadc.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vadd.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vand.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vasub.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vasubu.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vcompress.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vcpop.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vdiv.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vdivu.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfabs.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfadd.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfclass.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfcvt.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfdiv.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfirst.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfmacc.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfmadd.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfmax.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfmerge.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfmin.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfmsac.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfmsub.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfmul.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfmv.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfncvt.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfneg.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfnmacc.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfnmadd.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfnmsac.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfnmsub.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfrdiv.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfrec7.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfredmax.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfredmin.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfredosum.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfredusum.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfrsqrt7.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfrsub.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfsgnj.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfsgnjn.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfsgnjx.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfslide1down.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfslide1up.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfsqrt.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfsub.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfwadd.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/non-overloaded/vfwcvt.c
  
clang/test/CodeGen/RISCV/rvv-intrin

[clang] e4bc989 - [Clang] Fix typo in ReleaseNotes.rst

2023-01-31 Thread Corentin Jabot via cfe-commits

Author: Corentin Jabot
Date: 2023-01-31T11:19:44+01:00
New Revision: e4bc9898ddbeb70bc49d713bbf863f050f21e03f

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

LOG: [Clang] Fix typo in ReleaseNotes.rst

Added: 


Modified: 
clang/docs/ReleaseNotes.rst

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index fe418d938650..efa9fe076b41 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -112,7 +112,7 @@ C++2b Feature Support
 
 - Implemented `P2036R3: Change scope of lambda trailing-return-type 
`_
   and `P2579R0 Mitigation strategies for P2036 `_.
-  This proposals modify how variables captured in lambdas can appear in 
trailing return type
+  These proposals modify how variables captured in lambdas can appear in 
trailing return type
   expressions and how their types are deduced therein, in all C++ language 
versions.
 
 CUDA/HIP Language Changes in Clang



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


[PATCH] D91000: [clang-tidy] Add bugprone-unsafe-functions checker.

2023-01-31 Thread Whisperity via Phabricator via cfe-commits
whisperity added a comment.

Alright, the tests came back from the CI positively and there were no crashes 
on like 15 projects (about 50:50 C and C++). There are some nice results:

- In LLVM, in `LexPPMacroExpansion.cpp` `ExpandBuiltinMacro()` there is a hit 
for a call `Result = asctime(TM);`. The suggestion is `strftime` which is 
available in all C++ versions and >= C99, so this seems like a valid finding. 
`Result` is a `const char *` which is initialised by this call.
- In Bitcoin, **2** findings in `logging.cpp` doing `setbuf(out, nullptr);`. 
Not sure if these are legit findings because these seem to be only "resetting" 
some buffering, but the warning message is legible.
- In Postgres:
  - **2** findings in `isolationtester.c`, same `setbuf(stdout, NULL);` and 
`setbuf(stderr, NULL);`. `setvbuf/4` is available from C99 so this seems like a 
valid finding from a language version standpoint.
  - In `initdb.c`, a call to `rewind` with the comment preceding: //`/* now 
reprocess the file and store the lines */`//.
- In SQLite:
  - In `lemon.c`, a call to `rewind` [...]
  - In `shell.c`, **3** calls to `rewind` [...]
- In OpenSSL:
  - In `randfile.c` and `apps.c`, **2** `setbuf(fileptr, NULL);` calls [...]
- In Vim, **4** calls to `rewind()` in `xxd.c`, `tag.c`, and `term.c`.
  - The case in `term.c` is extra funny because directly following the 
`rewind(fd)` call there is a `while (!feof(fd)) ...`
- In MemcacheD, a `setbuf(stderr, NULL);` with the comment //`/* set stderr 
non-buffering ... */`//

It seems not many projects use Annex K at least from this test set. Note that 
we're primarily working on Linux, where Annex K isn't in the standard library. 
It has also been reported to not that useful 
, although it's 
good that the check uses them optionally. In general, we seem to have made a 
good enough framework for registering "unsafe standard APIs" later on with 
those stringswitches.

Regarding the performance, I did not see any meaningful slow-down. Most of the 
projects analysed in a few seconds or minutes, similar to other Tidy runs in 
the same infrastructure.


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

https://reviews.llvm.org/D91000

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


[clang] 5f01a62 - [ConstantFold] Fix inbounds inference on mismatching source element type

2023-01-31 Thread Nikita Popov via cfe-commits

Author: Nikita Popov
Date: 2023-01-31T11:33:00+01:00
New Revision: 5f01a626dd0615df49773d419c75aeb33666ee83

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

LOG: [ConstantFold] Fix inbounds inference on mismatching source element type

When inferring that a GEP of a global variable is inbounds because
there is no notional overindexing, we need to check that the
global value type and the GEP source element type match.

This was not necessary with typed pointers (because we would have
a bitcast in between), but is necessary with opaque pointers.

We should be able to recover some of the safe cases by performing
an offset based inbounds inference in DL-aware ConstantFolding.

Added: 


Modified: 
clang/test/CodeGenCXX/no-unique-address.cpp
llvm/lib/IR/ConstantFold.cpp
llvm/test/Assembler/opaque-ptr.ll
llvm/test/Transforms/InferAddressSpaces/AMDGPU/infer-getelementptr.ll
llvm/test/Transforms/InstCombine/getelementptr.ll
llvm/test/Transforms/InstCombine/memchr-9.ll
llvm/test/Transforms/InstCombine/wcslen-1.ll
llvm/test/Transforms/InstSimplify/compare.ll

Removed: 




diff  --git a/clang/test/CodeGenCXX/no-unique-address.cpp 
b/clang/test/CodeGenCXX/no-unique-address.cpp
index aa58b87555dcc..7b4bbbf2a05d5 100644
--- a/clang/test/CodeGenCXX/no-unique-address.cpp
+++ b/clang/test/CodeGenCXX/no-unique-address.cpp
@@ -64,7 +64,7 @@ FieldOverlap fo = {{}, {}, {}, {}, 1234};
 
 // CHECK-DAG: @e1 ={{.*}} constant ptr @fo
 Empty1 &e1 = fo.e1;
-// CHECK-DAG: @e2 ={{.*}} constant ptr getelementptr inbounds (i8, ptr @fo, 
i64 1)
+// CHECK-DAG: @e2 ={{.*}} constant ptr getelementptr (i8, ptr @fo, i64 1)
 Empty1 &e2 = fo.e2;
 
 // CHECK-LABEL: accessE1

diff  --git a/llvm/lib/IR/ConstantFold.cpp b/llvm/lib/IR/ConstantFold.cpp
index f84fe79b21be2..5fa56d30910e4 100644
--- a/llvm/lib/IR/ConstantFold.cpp
+++ b/llvm/lib/IR/ConstantFold.cpp
@@ -2280,7 +2280,8 @@ Constant *llvm::ConstantFoldGetElementPtr(Type 
*PointeeTy, Constant *C,
   // check for the "inbounds" property.
   if (!Unknown && !InBounds)
 if (auto *GV = dyn_cast(C))
-  if (!GV->hasExternalWeakLinkage() && isInBoundsIndices(Idxs))
+  if (!GV->hasExternalWeakLinkage() && GV->getValueType() == PointeeTy &&
+  isInBoundsIndices(Idxs))
 return ConstantExpr::getGetElementPtr(PointeeTy, C, Idxs,
   /*InBounds=*/true, InRangeIndex);
 

diff  --git a/llvm/test/Assembler/opaque-ptr.ll 
b/llvm/test/Assembler/opaque-ptr.ll
index f950708088f1a..e9e1496756888 100644
--- a/llvm/test/Assembler/opaque-ptr.ll
+++ b/llvm/test/Assembler/opaque-ptr.ll
@@ -4,7 +4,7 @@
 ; CHECK: @global = external global ptr
 @global = external global ptr
 
-; CHECK: @global_const_gep = global ptr getelementptr inbounds (i47, ptr 
@global, i64 1)
+; CHECK: @global_const_gep = global ptr getelementptr (i47, ptr @global, i64 1)
 @global_const_gep = global ptr getelementptr (i47, ptr @global, i64 1)
 
 ; CHECK: @fptr1 = external global ptr

diff  --git 
a/llvm/test/Transforms/InferAddressSpaces/AMDGPU/infer-getelementptr.ll 
b/llvm/test/Transforms/InferAddressSpaces/AMDGPU/infer-getelementptr.ll
index 3c3b5036eaa26..dc36e936fca54 100644
--- a/llvm/test/Transforms/InferAddressSpaces/AMDGPU/infer-getelementptr.ll
+++ b/llvm/test/Transforms/InferAddressSpaces/AMDGPU/infer-getelementptr.ll
@@ -94,7 +94,7 @@ define void @repeated_constexpr_gep_addrspacecast(i64 %idx0, 
i64 %idx1) {
 define void @unorder_constexpr_gep_bitcast() {
 ; CHECK-LABEL: @unorder_constexpr_gep_bitcast(
 ; CHECK-NEXT:[[X0:%.*]] = load i32, ptr addrspace(3) @lds, align 4
-; CHECK-NEXT:[[X1:%.*]] = load i32, ptr addrspace(3) getelementptr 
inbounds (i32, ptr addrspace(3) @lds, i32 1), align 4
+; CHECK-NEXT:[[X1:%.*]] = load i32, ptr addrspace(3) getelementptr (i32, 
ptr addrspace(3) @lds, i32 1), align 4
 ; CHECK-NEXT:call void @use(i32 [[X0]], i32 [[X1]])
 ; CHECK-NEXT:ret void
 ;

diff  --git a/llvm/test/Transforms/InstCombine/getelementptr.ll 
b/llvm/test/Transforms/InstCombine/getelementptr.ll
index e67f67c24d266..766abb5923407 100644
--- a/llvm/test/Transforms/InstCombine/getelementptr.ll
+++ b/llvm/test/Transforms/InstCombine/getelementptr.ll
@@ -1334,7 +1334,7 @@ define ptr @const_gep_global_di_i8_larger() {
 
 define ptr @const_gep_global_di_i64_larger() {
 ; CHECK-LABEL: @const_gep_global_di_i64_larger(
-; CHECK-NEXT:ret ptr getelementptr inbounds (i32, ptr @g_i32_di, i64 2)
+; CHECK-NEXT:ret ptr getelementptr (i32, ptr @g_i32_di, i64 2)
 ;
   ret ptr getelementptr (i64, ptr @g_i32_di, i64 1)
 }

diff  --git a/llvm/test/Transforms/InstCombine/memchr-9.ll 
b/llvm/test/Transforms/InstCombine/memchr-9.ll
index 00cc90688e2b7..e2c2e6839817c 100644
--- a/llvm/test/Transforms/InstCo

[PATCH] D142872: Honor the fwrapv option when generating the inbounds GEP .

2023-01-31 Thread Nikita Popov via Phabricator via cfe-commits
nikic added a comment.

@umesh.kalappa0 This issue should be fixed by 
https://github.com/llvm/llvm-project/commit/5f01a626dd0615df49773d419c75aeb33666ee83.
 Can you please give it another try?


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

https://reviews.llvm.org/D142872

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


[PATCH] D142384: [C++20] Fix a crash with modules.

2023-01-31 Thread Utkarsh Saxena via Phabricator via cfe-commits
usaxena95 updated this revision to Diff 493538.
usaxena95 added a comment.

Moved the use of definition where fields are accessed.
This now resolves several other C++20/Module related crashes as well.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142384

Files:
  clang/include/clang/AST/Decl.h
  clang/include/clang/AST/DeclCXX.h


Index: clang/include/clang/AST/DeclCXX.h
===
--- clang/include/clang/AST/DeclCXX.h
+++ clang/include/clang/AST/DeclCXX.h
@@ -554,6 +554,11 @@
 
   bool hasDefinition() const { return DefinitionData || dataPtr(); }
 
+  RecordDecl::field_iterator field_begin() const override {
+assert(hasDefinition() && "Definition not available to get fields.");
+return static_cast(getDefinition())->field_begin();
+  }
+
   static CXXRecordDecl *Create(const ASTContext &C, TagKind TK, DeclContext 
*DC,
SourceLocation StartLoc, SourceLocation IdLoc,
IdentifierInfo *Id,
Index: clang/include/clang/AST/Decl.h
===
--- clang/include/clang/AST/Decl.h
+++ clang/include/clang/AST/Decl.h
@@ -4220,7 +4220,7 @@
   using field_range = llvm::iterator_range>;
 
   field_range fields() const { return field_range(field_begin(), field_end()); 
}
-  field_iterator field_begin() const;
+  virtual field_iterator field_begin() const;
 
   field_iterator field_end() const {
 return field_iterator(decl_iterator());


Index: clang/include/clang/AST/DeclCXX.h
===
--- clang/include/clang/AST/DeclCXX.h
+++ clang/include/clang/AST/DeclCXX.h
@@ -554,6 +554,11 @@
 
   bool hasDefinition() const { return DefinitionData || dataPtr(); }
 
+  RecordDecl::field_iterator field_begin() const override {
+assert(hasDefinition() && "Definition not available to get fields.");
+return static_cast(getDefinition())->field_begin();
+  }
+
   static CXXRecordDecl *Create(const ASTContext &C, TagKind TK, DeclContext *DC,
SourceLocation StartLoc, SourceLocation IdLoc,
IdentifierInfo *Id,
Index: clang/include/clang/AST/Decl.h
===
--- clang/include/clang/AST/Decl.h
+++ clang/include/clang/AST/Decl.h
@@ -4220,7 +4220,7 @@
   using field_range = llvm::iterator_range>;
 
   field_range fields() const { return field_range(field_begin(), field_end()); }
-  field_iterator field_begin() const;
+  virtual field_iterator field_begin() const;
 
   field_iterator field_end() const {
 return field_iterator(decl_iterator());
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D142968: [NFC] Extract `CodeGenInstAlias` into its own *.h/*.cpp

2023-01-31 Thread Sergei Barannikov via Phabricator via cfe-commits
barannikov88 created this revision.
Herald added a subscriber: jeroen.dobbelaere.
Herald added a project: All.
barannikov88 requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D142968

Files:
  clang/docs/tools/clang-formatted-files.txt
  llvm/utils/TableGen/AsmMatcherEmitter.cpp
  llvm/utils/TableGen/AsmWriterEmitter.cpp
  llvm/utils/TableGen/CMakeLists.txt
  llvm/utils/TableGen/CodeGenInstAlias.cpp
  llvm/utils/TableGen/CodeGenInstAlias.h
  llvm/utils/TableGen/CodeGenInstruction.cpp
  llvm/utils/TableGen/CodeGenInstruction.h
  llvm/utils/gn/secondary/llvm/utils/TableGen/BUILD.gn

Index: llvm/utils/gn/secondary/llvm/utils/TableGen/BUILD.gn
===
--- llvm/utils/gn/secondary/llvm/utils/TableGen/BUILD.gn
+++ llvm/utils/gn/secondary/llvm/utils/TableGen/BUILD.gn
@@ -15,6 +15,7 @@
 "CodeEmitterGen.cpp",
 "CodeGenDAGPatterns.cpp",
 "CodeGenHwModes.cpp",
+"CodeGenInstAlias.cpp",
 "CodeGenInstruction.cpp",
 "CodeGenMapTable.cpp",
 "CodeGenRegisters.cpp",
Index: llvm/utils/TableGen/CodeGenInstruction.h
===
--- llvm/utils/TableGen/CodeGenInstruction.h
+++ llvm/utils/TableGen/CodeGenInstruction.h
@@ -23,8 +23,6 @@
 #include 
 
 namespace llvm {
-class SMLoc;
-template  class ArrayRef;
   class Record;
   class DagInit;
   class CodeGenTarget;
@@ -340,71 +338,6 @@
 bool isOperandImpl(StringRef OpListName, unsigned i,
StringRef PropertyName) const;
   };
-
-
-  /// CodeGenInstAlias - This represents an InstAlias definition.
-  class CodeGenInstAlias {
-  public:
-Record *TheDef;// The actual record defining this InstAlias.
-
-/// AsmString - The format string used to emit a .s file for the
-/// instruction.
-std::string AsmString;
-
-/// Result - The result instruction.
-DagInit *Result;
-
-/// ResultInst - The instruction generated by the alias (decoded from
-/// Result).
-CodeGenInstruction *ResultInst;
-
-
-struct ResultOperand {
-private:
-  std::string Name;
-  Record *R = nullptr;
-  int64_t Imm = 0;
-
-public:
-  enum {
-K_Record,
-K_Imm,
-K_Reg
-  } Kind;
-
-  ResultOperand(std::string N, Record *r)
-  : Name(std::move(N)), R(r), Kind(K_Record) {}
-  ResultOperand(int64_t I) : Imm(I), Kind(K_Imm) {}
-  ResultOperand(Record *r) : R(r), Kind(K_Reg) {}
-
-  bool isRecord() const { return Kind == K_Record; }
-  bool isImm() const { return Kind == K_Imm; }
-  bool isReg() const { return Kind == K_Reg; }
-
-  StringRef getName() const { assert(isRecord()); return Name; }
-  Record *getRecord() const { assert(isRecord()); return R; }
-  int64_t getImm() const { assert(isImm()); return Imm; }
-  Record *getRegister() const { assert(isReg()); return R; }
-
-  unsigned getMINumOperands() const;
-};
-
-/// ResultOperands - The decoded operands for the result instruction.
-std::vector ResultOperands;
-
-/// ResultInstOperandIndex - For each operand, this vector holds a pair of
-/// indices to identify the corresponding operand in the result
-/// instruction.  The first index specifies the operand and the second
-/// index specifies the suboperand.  If there are no suboperands or if all
-/// of them are matched by the operand, the second value should be -1.
-std::vector > ResultInstOperandIndex;
-
-CodeGenInstAlias(Record *R, CodeGenTarget &T);
-
-bool tryAliasOpMatch(DagInit *Result, unsigned AliasOpNo,
- Record *InstOpRec, bool hasSubOps, ArrayRef Loc,
- CodeGenTarget &T, ResultOperand &ResOp);
-  };
-}
+} // namespace llvm
 
 #endif
Index: llvm/utils/TableGen/CodeGenInstruction.cpp
===
--- llvm/utils/TableGen/CodeGenInstruction.cpp
+++ llvm/utils/TableGen/CodeGenInstruction.cpp
@@ -13,7 +13,6 @@
 #include "CodeGenInstruction.h"
 #include "CodeGenTarget.h"
 #include "llvm/ADT/StringExtras.h"
-#include "llvm/ADT/StringMap.h"
 #include "llvm/TableGen/Error.h"
 #include "llvm/TableGen/Record.h"
 #include 
@@ -592,266 +591,3 @@
   return Constraint->getDef()->isSubClassOf("TypedOperand") &&
  Constraint->getDef()->getValueAsBit(PropertyName);
 }
-
-//===--===//
-/// CodeGenInstAlias Implementation
-//===--===//
-
-/// tryAliasOpMatch - This is a helper function for the CodeGenInstAlias
-/// constructor.  It checks if an argument in an InstAlias pattern matches
-/// the corresponding operand of the instruction.  It returns true on a
-/// successful match, with ResOp 

[PATCH] D142704: [C++20][Modules] Handle template declarations in header units.

2023-01-31 Thread Iain Sandoe via Phabricator via cfe-commits
iains updated this revision to Diff 493546.
iains marked 2 inline comments as done.
iains added a comment.

rebased, added tests for instantiated variable/function templates.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142704

Files:
  clang/lib/Sema/SemaDecl.cpp
  clang/test/CXX/module/module.import/p6.cpp


Index: clang/test/CXX/module/module.import/p6.cpp
===
--- clang/test/CXX/module/module.import/p6.cpp
+++ clang/test/CXX/module/module.import/p6.cpp
@@ -22,6 +22,8 @@
 
 int bad_var_definition = 3;  // expected-error {{non-inline external 
definitions are not permitted in C++ header units}}
 
+/* The cases below should compile without diagnostics.  */
+
 class A {
 public:
 // This is a declaration instead of definition.
@@ -36,3 +38,32 @@
   S(S&);
 };
 S::S(S&) = default;
+
+template 
+_X tmpl_var_ok_0 = static_cast<_X>(-1);
+
+template 
+constexpr _T tmpl_var_ok_1 = static_cast<_T>(42);
+
+inline int a = tmpl_var_ok_1;
+
+template  class _T>
+constexpr int tmpl_var_ok_2 = _T<_Tp>::value ? 42 : 6174 ;
+
+template
+int tmpl_OK (_Ep) { return 0; }
+
+template 
+bool
+operator==(_T1& , _T1& ) { return false; }
+
+constexpr long one_k = 1000L;
+
+template 
+void* tmpl_fn_ok
+(_Args ...__args) { return nullptr; }
+
+inline int foo (int a) {
+  return tmpl_OK (a);
+}
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -13089,9 +13089,10 @@
   // C++ [module.import/6] external definitions are not permitted in header
   // units.
   if (getLangOpts().CPlusPlusModules && currentModuleIsHeaderUnit() &&
-  VDecl->isThisDeclarationADefinition() &&
+  !VDecl->isInvalidDecl() && VDecl->isThisDeclarationADefinition() &&
   VDecl->getFormalLinkage() == Linkage::ExternalLinkage &&
-  !VDecl->isInline()) {
+  !VDecl->isInline() && !VDecl->isTemplated() &&
+  !isa(VDecl)) {
 Diag(VDecl->getLocation(), diag::err_extern_def_in_header_unit);
 VDecl->setInvalidDecl();
   }
@@ -15260,9 +15261,10 @@
   // FIXME: Consider an alternate location for the test where the inlined()
   // state is complete.
   if (getLangOpts().CPlusPlusModules && currentModuleIsHeaderUnit() &&
+  !FD->isInvalidDecl() && !FD->isInlined() &&
+  BodyKind != FnBodyKind::Delete && BodyKind != FnBodyKind::Default &&
   FD->getFormalLinkage() == Linkage::ExternalLinkage &&
-  !FD->isInvalidDecl() && BodyKind != FnBodyKind::Delete &&
-  BodyKind != FnBodyKind::Default && !FD->isInlined()) {
+  !FD->isTemplated() && !FD->isTemplateInstantiation()) {
 assert(FD->isThisDeclarationADefinition());
 Diag(FD->getLocation(), diag::err_extern_def_in_header_unit);
 FD->setInvalidDecl();


Index: clang/test/CXX/module/module.import/p6.cpp
===
--- clang/test/CXX/module/module.import/p6.cpp
+++ clang/test/CXX/module/module.import/p6.cpp
@@ -22,6 +22,8 @@
 
 int bad_var_definition = 3;  // expected-error {{non-inline external definitions are not permitted in C++ header units}}
 
+/* The cases below should compile without diagnostics.  */
+
 class A {
 public:
 // This is a declaration instead of definition.
@@ -36,3 +38,32 @@
   S(S&);
 };
 S::S(S&) = default;
+
+template 
+_X tmpl_var_ok_0 = static_cast<_X>(-1);
+
+template 
+constexpr _T tmpl_var_ok_1 = static_cast<_T>(42);
+
+inline int a = tmpl_var_ok_1;
+
+template  class _T>
+constexpr int tmpl_var_ok_2 = _T<_Tp>::value ? 42 : 6174 ;
+
+template
+int tmpl_OK (_Ep) { return 0; }
+
+template 
+bool
+operator==(_T1& , _T1& ) { return false; }
+
+constexpr long one_k = 1000L;
+
+template 
+void* tmpl_fn_ok
+(_Args ...__args) { return nullptr; }
+
+inline int foo (int a) {
+  return tmpl_OK (a);
+}
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -13089,9 +13089,10 @@
   // C++ [module.import/6] external definitions are not permitted in header
   // units.
   if (getLangOpts().CPlusPlusModules && currentModuleIsHeaderUnit() &&
-  VDecl->isThisDeclarationADefinition() &&
+  !VDecl->isInvalidDecl() && VDecl->isThisDeclarationADefinition() &&
   VDecl->getFormalLinkage() == Linkage::ExternalLinkage &&
-  !VDecl->isInline()) {
+  !VDecl->isInline() && !VDecl->isTemplated() &&
+  !isa(VDecl)) {
 Diag(VDecl->getLocation(), diag::err_extern_def_in_header_unit);
 VDecl->setInvalidDecl();
   }
@@ -15260,9 +15261,10 @@
   // FIXME: Consider an alternate location for the test where the inlined()
   // state is complete.
   if (getLangOpts().CPlusPlusModules && currentModuleIsHeaderUnit() &&
+  !FD->isInvalidDecl() && !FD->isInlined() &&
+  BodyKind != FnBodyKind::Dele

[PATCH] D142704: [C++20][Modules] Handle template declarations in header units.

2023-01-31 Thread Iain Sandoe via Phabricator via cfe-commits
iains added inline comments.



Comment at: clang/lib/Sema/SemaDecl.cpp:15265
   FD->getFormalLinkage() == Linkage::ExternalLinkage &&
-  !FD->isInvalidDecl() && BodyKind != FnBodyKind::Delete &&
+  !FD->isInvalidDecl() && !IsFnTemplate && BodyKind != FnBodyKind::Delete 
&&
   BodyKind != FnBodyKind::Default && !FD->isInlined()) {

ChuanqiXu wrote:
> iains wrote:
> > iains wrote:
> > > ChuanqiXu wrote:
> > > > iains wrote:
> > > > > rsmith wrote:
> > > > > > Would it make sense to use `!isa(D)` here 
> > > > > > instead of adding `IsFnTemplate`?
> > > > > > Would it make sense to use `!isa(D)` here 
> > > > > > instead of adding `IsFnTemplate`?
> > > > > 
> > > > > I have changed this to use FD->isTemplated() to match the changes for 
> > > > > VarDecls - where the template decl is not available.  Would it be 
> > > > > better to use the isa<>() ?
> > > > > 
> > > > It looks not bad to me to use `isTemplated ()`. And it looks like 
> > > > `!FD->isTemplateInstantiation()` is not tested? And it looks a little 
> > > > bit odd since the instantiated template should be implicitly inline.
> > > > It looks not bad to me to use `isTemplated ()`. 
> > > 
> > > Hmm. now I am not sure what you prefer; in a previous review there was an 
> > > objection to not using the provided function in the decl class.  
> > > 
> > > What would be your suggestion here?
> > > 
> > > (we cannot use isa when testing the variables case 
> > > because the caller pulls out the templated decl before we get to test it) 
> > > - so it is more consistent (IMO) to use the same interface in both tests.
> > > 
> > > >And it looks like `!FD->isTemplateInstantiation()` is not tested?
> > > 
> > > Please could you expand a bit on what you mean here?
> > >  (the test is clearly required, in practice)
> > > 
> > > > And it looks a little bit odd since the instantiated template should be 
> > > > implicitly inline.
> > > 
> > > Did you see @dlaikie's comment on this topic above?
> > > 
> > > 
> > 
> > > Did you see @dlaikie's comment on this topic above?
> > 
> > sorry @dblaikie 's comment is in the PR 
> > (https://github.com/llvm/llvm-project/issues/60079#issuecomment-1406856501)
> > What would be your suggestion here?
> 
> I prefer `isTemplated ()` here. If I get things correct,  `isTemplated ()` 
> will cover the case that a non-template function decl inside a function 
> template. And `isa(D)` wouldn't handle the case. 
> According to my understanding problem, we should avoid all the dependent 
> cases.
> 
> > Please could you expand a bit on what you mean here?
> 
> I mean I didn't find function template instantiation in tests of this 
> revision page.
> 
> > sorry @dblaikie 's comment is in the PR 
> > (https://github.com/llvm/llvm-project/issues/60079#issuecomment-1406856501)
> 
> oh, this is because the inconsistent use of `inline` in different places.. 
> this may be the price we need to pay.

> > Please could you expand a bit on what you mean here?
> 
> I mean I didn't find function template instantiation in tests of this 
> revision page.

added.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142704

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


[PATCH] D142914: [MLIR][OpenMP] Added OMPIRBuilder support for Target Data directives.

2023-01-31 Thread Akash Banerjee via Phabricator via cfe-commits
TIFitis marked 2 inline comments as done.
TIFitis added inline comments.



Comment at: 
mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp:1342-1382
+/// Create a constant string location from the MLIR Location information.
+static llvm::Constant *
+createSourceLocStrFromLocation(Location loc, llvm::OpenMPIRBuilder &builder,
+   StringRef name, uint32_t &strLen) {
+  if (auto fileLoc = loc.dyn_cast()) {
+StringRef fileName = fileLoc.getFilename();
+unsigned lineNo = fileLoc.getLine();

clementval wrote:
> kiranchandramohan wrote:
> > clementval wrote:
> > > Instead of copy pasting this from 
> > > `mlir/lib/Target/LLVMIR/Dialect/OpenACC/OpenACCToLLVMIRTranslation.cpp` 
> > > can you extract it and put it in a common shared file so bith translation 
> > > can use the same code without duplication?
> > @raghavendhra put up a patch some time back and he faced some issues. It 
> > might be good to check with him or may be he can comment here.
> > https://reviews.llvm.org/D127037
> > https://discourse.llvm.org/t/rfc-for-refactoring-common-code-for-openacc-and-openmp/63833
> Just moving the three functions should be trivial. I'm not talking about the 
> processMapOperand.
I've moved `getSizeInBytes`.

The other two functions make use of `mlir::Location` and thus can't be moved 
trivially.

I can still try to move them by individually passing the elements of 
`mlir::Location` but that might not be ideal. Is that what you'd like?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142914

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


[PATCH] D142914: [MLIR][OpenMP] Added OMPIRBuilder support for Target Data directives.

2023-01-31 Thread Akash Banerjee via Phabricator via cfe-commits
TIFitis updated this revision to Diff 493549.
TIFitis marked an inline comment as done.
TIFitis added a comment.

Moved getSizeInBytes to OMPIRBuilder.cpp


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142914

Files:
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  llvm/include/llvm/Frontend/OpenMP/OMPConstants.h
  llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h
  llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp
  llvm/unittests/Frontend/OpenMPIRBuilderTest.cpp
  mlir/lib/Target/LLVMIR/Dialect/OpenACC/OpenACCToLLVMIRTranslation.cpp
  mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp

Index: mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp
===
--- mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp
+++ mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp
@@ -19,6 +19,7 @@
 
 #include "llvm/ADT/SetVector.h"
 #include "llvm/ADT/TypeSwitch.h"
+#include "llvm/Frontend/OpenMP/OMPConstants.h"
 #include "llvm/Frontend/OpenMP/OMPIRBuilder.h"
 #include "llvm/IR/DebugInfoMetadata.h"
 #include "llvm/IR/IRBuilder.h"
@@ -1338,6 +1339,216 @@
   return success();
 }
 
+/// Create a constant string location from the MLIR Location information.
+static llvm::Constant *
+createSourceLocStrFromLocation(Location loc, llvm::OpenMPIRBuilder &builder,
+   StringRef name, uint32_t &strLen) {
+  if (auto fileLoc = loc.dyn_cast()) {
+StringRef fileName = fileLoc.getFilename();
+unsigned lineNo = fileLoc.getLine();
+unsigned colNo = fileLoc.getColumn();
+return builder.getOrCreateSrcLocStr(name, fileName, lineNo, colNo, strLen);
+  }
+  std::string locStr;
+  llvm::raw_string_ostream locOS(locStr);
+  locOS << loc;
+  return builder.getOrCreateSrcLocStr(locOS.str(), strLen);
+}
+
+/// Create a constant string representing the mapping information extracted from
+/// the MLIR location information.
+static llvm::Constant *
+createMappingInformation(Location loc, llvm::OpenMPIRBuilder &builder) {
+  uint32_t strLen;
+  if (auto nameLoc = loc.dyn_cast()) {
+StringRef name = nameLoc.getName();
+return createSourceLocStrFromLocation(nameLoc.getChildLoc(), builder, name,
+  strLen);
+  }
+  return createSourceLocStrFromLocation(loc, builder, "unknown", strLen);
+}
+
+/// Process MapOperands for Target Data directives.
+static LogicalResult processMapOperand(
+llvm::IRBuilderBase &builder, LLVM::ModuleTranslation &moduleTranslation,
+const SmallVector &mapOperands, const ArrayAttr &mapTypes,
+SmallVector &mapTypeFlags,
+SmallVectorImpl &mapNames,
+struct llvm::OpenMPIRBuilder::MapperAllocas &mapperAllocas) {
+  auto numMapOperands = mapOperands.size();
+  llvm::OpenMPIRBuilder *ompBuilder = moduleTranslation.getOpenMPBuilder();
+  llvm::PointerType *i8PtrTy = builder.getInt8PtrTy();
+  llvm::ArrayType *arrI8PtrTy = llvm::ArrayType::get(i8PtrTy, numMapOperands);
+  llvm::IntegerType *i64Ty = builder.getInt64Ty();
+  llvm::ArrayType *arrI64Ty = llvm::ArrayType::get(i64Ty, numMapOperands);
+
+  unsigned index = 0;
+  for (const auto &mapOp : mapOperands) {
+const auto &mapTypeOp = mapTypes[index];
+
+llvm::Value *mapOpValue = moduleTranslation.lookupValue(mapOp);
+llvm::Value *mapOpPtrBase;
+llvm::Value *mapOpPtr;
+llvm::Value *mapOpSize;
+
+if (mapOp.getType().isa()) {
+  mapOpPtrBase = mapOpValue;
+  mapOpPtr = mapOpValue;
+  mapOpSize = ompBuilder->getSizeInBytes(mapOpValue);
+} else {
+  return failure();
+}
+
+// Store base pointer extracted from operand into the i-th position of
+// argBase.
+llvm::Value *ptrBaseGEP = builder.CreateInBoundsGEP(
+arrI8PtrTy, mapperAllocas.ArgsBase,
+{builder.getInt32(0), builder.getInt32(index)});
+llvm::Value *ptrBaseCast = builder.CreateBitCast(
+ptrBaseGEP, mapOpPtrBase->getType()->getPointerTo());
+builder.CreateStore(mapOpPtrBase, ptrBaseCast);
+
+// Store pointer extracted from operand into the i-th position of args.
+llvm::Value *ptrGEP = builder.CreateInBoundsGEP(
+arrI8PtrTy, mapperAllocas.Args,
+{builder.getInt32(0), builder.getInt32(index)});
+llvm::Value *ptrCast =
+builder.CreateBitCast(ptrGEP, mapOpPtr->getType()->getPointerTo());
+builder.CreateStore(mapOpPtr, ptrCast);
+
+// Store size extracted from operand into the i-th position of argSizes.
+llvm::Value *sizeGEP = builder.CreateInBoundsGEP(
+arrI64Ty, mapperAllocas.ArgSizes,
+{builder.getInt32(0), builder.getInt32(index)});
+builder.CreateStore(mapOpSize, sizeGEP);
+
+mapTypeFlags.push_back(mapTypeOp.dyn_cast().getInt());
+llvm::Constant *mapName =
+createMappingInformation(mapOp.getLoc(), *ompBuilder);
+mapNames.push_back(mapName);
+++index;
+  }

[PATCH] D142968: [NFC] Extract `CodeGenInstAlias` into its own *.h/*.cpp

2023-01-31 Thread Jay Foad via Phabricator via cfe-commits
foad added a comment.

Looks OK but what's the motivation for it?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142968

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


[PATCH] D142968: [NFC] Extract `CodeGenInstAlias` into its own *.h/*.cpp

2023-01-31 Thread Jay Foad via Phabricator via cfe-commits
foad added inline comments.



Comment at: clang/docs/tools/clang-formatted-files.txt:7421
 llvm/utils/not/not.cpp
+llvm/Utils/TableGen/CodeGenInstAlias.cpp
+llvm/Utils/TableGen/CodeGenInstAlias.h

Should come after CodeBeads in alphabetical order?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142968

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


[PATCH] D142697: [3/3][Clang][RISCV] Add `__riscv_` for overloaded intrinsics

2023-01-31 Thread Yueh-Ting (eop) Chen via Phabricator via cfe-commits
eopXD updated this revision to Diff 493551.
eopXD added a comment.

Update left-out test cases.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142697

Files:
  clang/lib/Support/RISCVVIntrinsicUtils.cpp
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vaadd.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vaaddu.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vadc.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vadd.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vand.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vasub.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vasubu.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vcompress.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vcpop.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vdiv.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vdivu.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfabs.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfadd.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfclass.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfcvt.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfdiv.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfirst.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfmacc.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfmadd.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfmax.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfmerge.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfmin.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfmsac.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfmsub.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfmul.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfmv.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfncvt.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfneg.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfnmacc.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfnmadd.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfnmsac.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfnmsub.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfrdiv.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfrec7.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfredmax.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfredmin.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfredosum.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfredusum.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfrsqrt7.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfrsub.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfsgnj.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfsgnjn.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfsgnjx.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfslide1down.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfslide1up.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfsqrt.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfsub.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfwadd.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfwcvt.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfwmacc.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfwmsac.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfwmul.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfwnmacc.c
  
clang/test/CodeGen/RISCV/rvv

[PATCH] D142697: [3/3][Clang][RISCV] Add `__riscv_` for overloaded intrinsics

2023-01-31 Thread Yueh-Ting (eop) Chen 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 rG1ec6c562: [3/3][Clang][RISCV] Add `__riscv_` for 
overloaded intrinsics (authored by eopXD).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142697

Files:
  clang/lib/Support/RISCVVIntrinsicUtils.cpp
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vaadd.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vaaddu.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vadc.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vadd.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vand.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vasub.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vasubu.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vcompress.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vcpop.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vdiv.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vdivu.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfabs.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfadd.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfclass.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfcvt.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfdiv.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfirst.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfmacc.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfmadd.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfmax.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfmerge.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfmin.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfmsac.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfmsub.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfmul.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfmv.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfncvt.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfneg.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfnmacc.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfnmadd.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfnmsac.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfnmsub.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfrdiv.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfrec7.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfredmax.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfredmin.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfredosum.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfredusum.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfrsqrt7.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfrsub.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfsgnj.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfsgnjn.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfsgnjx.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfslide1down.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfslide1up.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfsqrt.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfsub.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfwadd.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfwcvt.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfwmacc.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non-policy/overloaded/vfwmsac.c
  
clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/non

[PATCH] D142822: [clang] ASTImporter: Fix importing of va_list types and declarations

2023-01-31 Thread Vince Bridgers via Phabricator via cfe-commits
vabridgers updated this revision to Diff 493553.
vabridgers added a subscriber: balazske.
vabridgers added a comment.

Updates per suggestion from @balazske


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142822

Files:
  clang-tools-extra/clang-tidy/altera/StructPackAlignCheck.cpp
  clang-tools-extra/clang-tidy/cert/DontModifyStdNamespaceCheck.cpp
  clang-tools-extra/clang-tidy/utils/RenamerClangTidyCheck.cpp
  clang-tools-extra/test/clang-tidy/checkers/cert/dcl58-cpp.cpp
  clang/docs/ReleaseNotes.rst
  clang/lib/Frontend/ASTMerge.cpp
  clang/lib/Sema/Sema.cpp
  clang/test/AST/ast-dump-file-line-json.c
  clang/test/AST/ast-dump-overloaded-operators.cpp
  clang/test/AST/ast-dump-record-definition-data-json.cpp
  clang/test/AST/ast-dump-records-json.cpp
  clang/test/AST/ast-dump-records.cpp
  clang/test/AST/ast-dump-template-decls-json.cpp
  clang/test/AST/ast-dump-traits.cpp
  clang/test/AST/fixed_point.c
  clang/test/AST/float16.cpp
  clang/test/PCH/stmt-openmp_structured_block-bit.cpp
  clang/unittests/AST/ASTImporterTest.cpp

Index: clang/unittests/AST/ASTImporterTest.cpp
===
--- clang/unittests/AST/ASTImporterTest.cpp
+++ clang/unittests/AST/ASTImporterTest.cpp
@@ -1248,8 +1248,8 @@
 }
 )";
   Decl *FromTU = getTuDecl(Code, Lang_CXX03);
-  auto FromNs =
-  FirstDeclMatcher().match(FromTU, namespaceDecl());
+  auto FromNs = FirstDeclMatcher().match(
+  FromTU, namespaceDecl(hasName("x")));
   auto ToNs = cast(Import(FromNs, Lang_CXX03));
   ASSERT_TRUE(ToNs);
   auto From =
@@ -7561,7 +7561,14 @@
   }
   )",
   Lang_CXX14);
-  auto *FromFD = FirstDeclMatcher().match(FromTU, fieldDecl());
+
+  auto *FromF = FirstDeclMatcher().match(
+  FromTU, functionDecl(hasName("declToImport")));
+  CXXRecordDecl *FromLambda =
+  cast((cast(FromF->getBody())->body_back()))
+  ->getLambdaClass();
+
+  auto *FromFD = *FromLambda->field_begin();
   ASSERT_TRUE(FromFD);
   ASSERT_TRUE(FromFD->hasCapturedVLAType());
 
@@ -8137,6 +8144,24 @@
   EXPECT_FALSE(SharedStatePtr->isNewDecl(ToBar));
 }
 
+TEST_P(ASTImporterOptionSpecificTestBase, VaList) {
+  Decl *FromTU = getTuDecl(R"(typedef __builtin_va_list va_list;)", Lang_C99);
+
+  auto *FromVaList = FirstDeclMatcher().match(
+  FromTU, typedefDecl(hasName("va_list")));
+  ASSERT_TRUE(FromVaList);
+
+  auto *ToVaList = Import(FromVaList, Lang_C99);
+  ASSERT_TRUE(ToVaList);
+
+  auto *ToBuiltinVaList = FirstDeclMatcher().match(
+  ToAST->getASTContext().getTranslationUnitDecl(),
+  typedefDecl(hasName("__builtin_va_list")));
+
+  ASSERT_TRUE(ToAST->getASTContext().hasSameType(
+  ToVaList->getUnderlyingType(), ToBuiltinVaList->getUnderlyingType()));
+}
+
 INSTANTIATE_TEST_SUITE_P(ParameterizedTests, ASTImporterLookupTableTest,
  DefaultTestValuesForRunOptions);
 
Index: clang/test/PCH/stmt-openmp_structured_block-bit.cpp
===
--- clang/test/PCH/stmt-openmp_structured_block-bit.cpp
+++ clang/test/PCH/stmt-openmp_structured_block-bit.cpp
@@ -13,7 +13,7 @@
 // expected-no-diagnostics
 
 // CHECK: TranslationUnitDecl 0x{{.*}} <> 
-// CHECK: `-FunctionDecl 0x{{.*}} <{{.*}}stmt-openmp_structured_block-bit.cpp:8:1, line:11:1> line:8:6 {{(test|imported test)}} 'void ()'
+// CHECK:  -FunctionDecl 0x{{.*}} <{{.*}}stmt-openmp_structured_block-bit.cpp:8:1, line:11:1> line:8:6 {{(test|imported test)}} 'void ()'
 // CHECK-NEXT:   `-CompoundStmt 0x{{.*}} 
 // CHECK-NEXT: `-OMPParallelDirective 0x{{.*}} 
 // CHECK-NEXT:   `-CapturedStmt 0x{{.*}} 
Index: clang/test/AST/float16.cpp
===
--- clang/test/AST/float16.cpp
+++ clang/test/AST/float16.cpp
@@ -29,7 +29,7 @@
   }
 }
 
-//CHECK:  |-NamespaceDecl
+//CHECK:  |-NamespaceDecl {{.*}} <{{.*}}:22:1,
 //CHECK-NEXT: | |-VarDecl {{.*}} f1n '_Float16'
 //CHECK-NEXT: | |-VarDecl {{.*}} f2n '_Float16' cinit
 //CHECK-NEXT: | | `-FloatingLiteral {{.*}} '_Float16' 3.30e+01
Index: clang/test/AST/fixed_point.c
===
--- clang/test/AST/fixed_point.c
+++ clang/test/AST/fixed_point.c
@@ -402,5 +402,5 @@
 
 _Accum literallast = 1.0k;// One
 
-//CHECK-NEXT: `-VarDecl {{.*}} literallast '_Accum' cinit
+//CHECK-NEXT:  -VarDecl {{.*}} literallast '_Accum' cinit
 //CHECK-NEXT:   `-FixedPointLiteral {{.*}} '_Accum' 1.0
Index: clang/test/AST/ast-dump-traits.cpp
===
--- clang/test/AST/ast-dump-traits.cpp
+++ clang/test/AST/ast-dump-traits.cpp
@@ -52,7 +52,7 @@
 // CHECK-NEXT: | `-CompoundStmt {{.*}} 
 // CHECK-NEXT: |   `-CStyleCastExpr {{.*}}  'void' 
 // CHECK-NEXT: | `-ExpressionTraitExpr {{.*}}  'bool' __is_lvalue_expr
-// CHECK-NEXT: `-FunctionDecl

[PATCH] D142094: [Clang][Doc] Add release note for changes for the RVV intrinsics

2023-01-31 Thread Yueh-Ting (eop) Chen via Phabricator via cfe-commits
eopXD updated this revision to Diff 493555.
eopXD added a comment.

Address comment from Alex.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142094

Files:
  clang/docs/ReleaseNotes.rst


Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -142,6 +142,17 @@
 
 RISC-V Support in Clang
 ---
+- An overall simplification of the RISC-V Vector intrinsics are done. The
+  simplification is based on
+  `riscv-non-isa/rvv-intrinsic-doc#186 
`_.
+- Intrinsics of `vcompress` and `vmerge` have been adjusted to have interfaces
+  be aligned among `vvm`, `vxm` intrinsics. The adjustment is base on
+  `riscv-non-isa/rvv-intrinsic-doc#185 
`_.
+- All RISC-V Vector intrinsics now share a `__riscv_` prefix, based on the
+  naming convention defined by
+  `riscv-non-isa/riscv-c-api-doc#31 
`_.
+- Note that the RISC-V Vector C intrinsics are still under development. The RVV
+  C Intrinsic Task Group is working towards a ratified v1.0.
 
 X86 Support in Clang
 


Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -142,6 +142,17 @@
 
 RISC-V Support in Clang
 ---
+- An overall simplification of the RISC-V Vector intrinsics are done. The
+  simplification is based on
+  `riscv-non-isa/rvv-intrinsic-doc#186 `_.
+- Intrinsics of `vcompress` and `vmerge` have been adjusted to have interfaces
+  be aligned among `vvm`, `vxm` intrinsics. The adjustment is base on
+  `riscv-non-isa/rvv-intrinsic-doc#185 `_.
+- All RISC-V Vector intrinsics now share a `__riscv_` prefix, based on the
+  naming convention defined by
+  `riscv-non-isa/riscv-c-api-doc#31 `_.
+- Note that the RISC-V Vector C intrinsics are still under development. The RVV
+  C Intrinsic Task Group is working towards a ratified v1.0.
 
 X86 Support in Clang
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D142914: [MLIR][OpenMP] Added OMPIRBuilder support for Target Data directives.

2023-01-31 Thread Valentin Clement via Phabricator via cfe-commits
clementval added inline comments.



Comment at: 
mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp:1342-1382
+/// Create a constant string location from the MLIR Location information.
+static llvm::Constant *
+createSourceLocStrFromLocation(Location loc, llvm::OpenMPIRBuilder &builder,
+   StringRef name, uint32_t &strLen) {
+  if (auto fileLoc = loc.dyn_cast()) {
+StringRef fileName = fileLoc.getFilename();
+unsigned lineNo = fileLoc.getLine();

TIFitis wrote:
> clementval wrote:
> > kiranchandramohan wrote:
> > > clementval wrote:
> > > > Instead of copy pasting this from 
> > > > `mlir/lib/Target/LLVMIR/Dialect/OpenACC/OpenACCToLLVMIRTranslation.cpp` 
> > > > can you extract it and put it in a common shared file so bith 
> > > > translation can use the same code without duplication?
> > > @raghavendhra put up a patch some time back and he faced some issues. It 
> > > might be good to check with him or may be he can comment here.
> > > https://reviews.llvm.org/D127037
> > > https://discourse.llvm.org/t/rfc-for-refactoring-common-code-for-openacc-and-openmp/63833
> > Just moving the three functions should be trivial. I'm not talking about 
> > the processMapOperand.
> I've moved `getSizeInBytes`.
> 
> The other two functions make use of `mlir::Location` and thus can't be moved 
> trivially.
> 
> I can still try to move them by individually passing the elements of 
> `mlir::Location` but that might not be ideal. Is that what you'd like?
What about a new header file in `mlir/include/mlir/Target/LLVMIR/Dialect/**` 
shared by 
`mlir/lib/Target/LLVMIR/Dialect/OpenACC/OpenACCToLLVMIRTranslation.cpp` and 
`mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp`. That 
should be doable. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142914

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


[PATCH] D142637: A slightly more concise AST dump :)

2023-01-31 Thread Dani Ferreira Franco Moura via Phabricator via cfe-commits
merrymeerkat updated this revision to Diff 493557.
merrymeerkat added a comment.

Addressing review comments (improve tests)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142637

Files:
  clang/include/clang/AST/ASTNodeTraverser.h
  clang/test/AST/ast-dump-attr-type.cpp
  clang/test/AST/ast-dump-types-json.cpp


Index: clang/test/AST/ast-dump-types-json.cpp
===
--- clang/test/AST/ast-dump-types-json.cpp
+++ clang/test/AST/ast-dump-types-json.cpp
@@ -203,32 +203,6 @@
 // CHECK-NEXT:]
 // CHECK-NEXT:   }
 // CHECK-NEXT:  ]
-// CHECK-NEXT: },
-// CHECK-NEXT: {
-// CHECK-NEXT:  "id": "0x{{.*}}",
-// CHECK-NEXT:  "kind": "ParenType",
-// CHECK-NEXT:  "type": {
-// CHECK-NEXT:   "qualType": "void ()"
-// CHECK-NEXT:  },
-// CHECK-NEXT:  "inner": [
-// CHECK-NEXT:   {
-// CHECK-NEXT:"id": "0x{{.*}}",
-// CHECK-NEXT:"kind": "FunctionProtoType",
-// CHECK-NEXT:"type": {
-// CHECK-NEXT: "qualType": "void ()"
-// CHECK-NEXT:},
-// CHECK-NEXT:"cc": "cdecl",
-// CHECK-NEXT:"inner": [
-// CHECK-NEXT: {
-// CHECK-NEXT:  "id": "0x{{.*}}",
-// CHECK-NEXT:  "kind": "BuiltinType",
-// CHECK-NEXT:  "type": {
-// CHECK-NEXT:   "qualType": "void"
-// CHECK-NEXT:  }
-// CHECK-NEXT: }
-// CHECK-NEXT:]
-// CHECK-NEXT:   }
-// CHECK-NEXT:  ]
 // CHECK-NEXT: }
 // CHECK-NEXT:]
 // CHECK-NEXT:   }
Index: clang/test/AST/ast-dump-attr-type.cpp
===
--- /dev/null
+++ clang/test/AST/ast-dump-attr-type.cpp
@@ -0,0 +1,24 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -fsyntax-only -ast-dump %s | 
FileCheck %s
+
+int * _Nonnull x;
+using Ty = decltype(x);
+
+// CHECK: TypeAliasDecl 0x{{[^ ]*}}   col:7 Ty 
'decltype(x)':'int *'
+// CHECK-NEXT:  `-DecltypeType 0x{{[^ ]*}} 'decltype(x)' sugar
+// CHECK-NEXT: |-DeclRefExpr 0x{{[^ ]*}}  'int * _Nonnull':'int *' 
lvalue Var 0x{{[^ ]*}} 'x' 'int * _Nonnull':'int *' non_odr_use_unevaluated
+// CHECK-NEXT:`-AttributedType 0x{{[^ ]*}} 'int * _Nonnull' sugar
+// CHECK-NEXT:  `-PointerType 0x{{[^ ]*}} 'int *'
+// CHECK-NEXT:`-BuiltinType 0x{{[^ ]*}} 'int'
+// CHECK-NOT:   `-PointerType
+
+[[clang::address_space(3)]] int *y;
+using Ty1 = decltype(y);
+
+// CHECK: TypeAliasDecl 0x{{[^ ]*}}  col:7 Ty1 
'decltype(y)':'__attribute__((address_space(3))) int *'
+// CHECK-NEXT: `-DecltypeType 0x{{[^ ]*}} 'decltype(y)' sugar
+// CHECK-NEXT:   |-DeclRefExpr 0x{{[^ ]*}}  
'__attribute__((address_space(3))) int *' lvalue Var 0x{{[^ ]*}} 'y' 
'__attribute__((address_space(3))) int *' non_odr_use_unevaluated
+// CHECK-NEXT: `-PointerType 0x{{[^ ]*}} 
'__attribute__((address_space(3))) int *'
+// CHECK-NEXT:   `-AttributedType 0x{{[^ ]*}} 
'__attribute__((address_space(3))) int' sugar
+// CHECK-NEXT  |-BuiltinType 0x{{[^ ]*}} 'int'
+// CHECK-NEXT  `-QualType 0x{{[^ ]*}} 
'__attribute__((address_space(3))) int' __attribute__((address_space(3)))
+// CHECK-NEXT`-BuiltinType 0x{{[^ ]*}} 'int'
Index: clang/include/clang/AST/ASTNodeTraverser.h
===
--- clang/include/clang/AST/ASTNodeTraverser.h
+++ clang/include/clang/AST/ASTNodeTraverser.h
@@ -384,7 +384,8 @@
   }
   void VisitAttributedType(const AttributedType *T) {
 // FIXME: AttrKind
-Visit(T->getModifiedType());
+if (T->getModifiedType() != T->getEquivalentType())
+  Visit(T->getModifiedType());
   }
   void VisitBTFTagAttributedType(const BTFTagAttributedType *T) {
 Visit(T->getWrappedType());


Index: clang/test/AST/ast-dump-types-json.cpp
===
--- clang/test/AST/ast-dump-types-json.cpp
+++ clang/test/AST/ast-dump-types-json.cpp
@@ -203,32 +203,6 @@
 // CHECK-NEXT:]
 // CHECK-NEXT:   }
 // CHECK-NEXT:  ]
-// CHECK-NEXT: },
-// CHECK-NEXT: {
-// CHECK-NEXT:  "id": "0x{{.*}}",
-// CHECK-NEXT:  "kind": "ParenType",
-// CHECK-NEXT:  "type": {
-// CHECK-NEXT:   "qualType": "void ()"
-// CHECK-NEXT:  },
-// CHECK-NEXT:  "inner": [
-// CHECK-NEXT:   {
-// CHECK-NEXT:"id": "0x{{.*}}",
-// CHECK-NEXT:"kind": "FunctionProtoType",
-// CHECK-NEXT:"type": {
-// CHECK-NEXT: "qualType": "void ()"
-// CHECK-NEXT:},
-// CHECK-NEXT:"cc": "cdecl",
-// CHECK-NEXT:"inner": [
-// CHECK-NEXT: {
-// CHECK-NEXT:  "id": "0x{{.*}}",
-// CHECK-NEXT:  

[PATCH] D142968: [NFC] Extract `CodeGenInstAlias` into its own *.h/*.cpp

2023-01-31 Thread Sergei Barannikov via Phabricator via cfe-commits
barannikov88 added a comment.

I intent to make make InstAlias with "complex" operands (non-empty 
MIOperandInfo) more robust (stricter syntax).
The change will clobber most of the code here, and I thought it is a good time 
to move the class to a dedicated file.
Another weak point is that this class is only used in AsmMatcherEmitter and 
AsmWriterEmitter, while CodeGenInstruction.h is included everywhere.
The class does not have long history; there were only a few functional changes 
since initial commit.

That is, no strong motivation.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142968

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


[PATCH] D142637: A slightly more concise AST dump :)

2023-01-31 Thread Dani Ferreira Franco Moura via Phabricator via cfe-commits
merrymeerkat marked 3 inline comments as done.
merrymeerkat added a comment.

thank you @sammccall @gribozavr2 for spotting these issues!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142637

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


[PATCH] D142092: [include-mapping] Allow multiple headers for the same symbol. Choose the first header of available ones.

2023-01-31 Thread Viktoriia Bakalova via Phabricator via cfe-commits
VitaNuo updated this revision to Diff 493564.
VitaNuo marked 2 inline comments as done.
VitaNuo added a comment.

Remove all special-casing, skip all variant pages.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142092

Files:
  clang/include/clang/Tooling/Inclusions/CSymbolMap.inc
  clang/include/clang/Tooling/Inclusions/StdSymbolMap.inc
  clang/lib/Tooling/Inclusions/Stdlib/StandardLibrary.cpp
  clang/tools/include-mapping/cppreference_parser.py
  clang/tools/include-mapping/gen_std.py
  clang/tools/include-mapping/test.py

Index: clang/tools/include-mapping/test.py
===
--- clang/tools/include-mapping/test.py
+++ clang/tools/include-mapping/test.py
@@ -53,7 +53,7 @@
   
 
 """
-self.assertEqual(_ParseSymbolPage(html, 'foo'), set(['']))
+self.assertEqual(_ParseSymbolPage(html, 'foo', ""), set(['']))
 
 
   def testParseSymbolPage_MulHeaders(self):
@@ -94,7 +94,7 @@
   
 
 """
-self.assertEqual(_ParseSymbolPage(html, "foo"),
+self.assertEqual(_ParseSymbolPage(html, "foo", ""),
  set(['', '']))
 
 
@@ -121,7 +121,7 @@
 
 
 """
-self.assertEqual(_ParseSymbolPage(html, "foo"),
+self.assertEqual(_ParseSymbolPage(html, "foo", ""),
  set(['', '']))
 
   def testParseSymbolPage_MulSymbolsInSameTd(self):
@@ -145,9 +145,9 @@
 
 
 """
-self.assertEqual(_ParseSymbolPage(html, "int8_t"),
+self.assertEqual(_ParseSymbolPage(html, "int8_t", ""),
  set(['']))
-self.assertEqual(_ParseSymbolPage(html, "int16_t"),
+self.assertEqual(_ParseSymbolPage(html, "int16_t", ""),
  set(['']))
 
 
Index: clang/tools/include-mapping/gen_std.py
===
--- clang/tools/include-mapping/gen_std.py
+++ clang/tools/include-mapping/gen_std.py
@@ -14,10 +14,7 @@
 The generated files are located in clang/include/Tooling/Inclusions.
 
 Caveats and FIXMEs:
-  - only symbols directly in "std" namespace are added, we should also add std's
-subnamespace symbols (e.g. chrono).
-  - symbols with multiple variants or defined in multiple headers aren't added,
-e.g. std::move, std::swap
+  - symbols with multiple variants aren't added, e.g., std::move
 
 Usage:
   1. Install BeautifulSoup dependency, see instruction:
@@ -109,18 +106,15 @@
   cppreference_modified_date = datetime.datetime.fromtimestamp(
 os.stat(index_page_path).st_mtime).strftime('%Y-%m-%d')
   print(CODE_PREFIX % (args.symbols.upper(), cppreference_modified_date))
+  # FIXME: take care of overloads
   for symbol in symbols:
-if len(symbol.headers) == 1:
-  # SYMBOL(unqualified_name, namespace, header)
-  print("SYMBOL(%s, %s, %s)" % (symbol.name, symbol.namespace,
-symbol.headers[0]))
-elif len(symbol.headers) == 0:
+if len(symbol.headers) == 0:
   sys.stderr.write("No header found for symbol %s\n" % symbol.name)
 else:
-  # FIXME: support symbols with multiple headers (e.g. std::move).
-  sys.stderr.write("Ambiguous header for symbol %s: %s\n" % (
-  symbol.name, ', '.join(symbol.headers)))
-
-
+  symbol.headers = sorted(symbol.headers)
+  for header in symbol.headers:
+# SYMBOL(unqualified_name, namespace, header)
+print("SYMBOL(%s, %s, %s)" % (symbol.name, symbol.namespace,
+  header))
 if __name__ == '__main__':
   main()
Index: clang/tools/include-mapping/cppreference_parser.py
===
--- clang/tools/include-mapping/cppreference_parser.py
+++ clang/tools/include-mapping/cppreference_parser.py
@@ -47,7 +47,7 @@
 
   Returns a list of headers.
   """
-  headers = set()
+  symbol_headers = set()
   all_headers = set()
 
   soup = BeautifulSoup(symbol_page_html, "html.parser")
@@ -58,32 +58,48 @@
   #   Defined in header   .t-dsc-header
   #   decl2.t-dcl
   for table in soup.select('table.t-dcl-begin, table.t-dsc-begin'):
-current_headers = []
-was_decl = False
-for row in table.select('tr'):
-  if _HasClass(row, 't-dcl', 't-dsc'):
-was_decl = True
-# Symbols are in the first cell.
-found_symbols = row.find('td').stripped_strings
-if not symbol_name in found_symbols:
-  continue
-headers.update(current_headers)
-  elif _HasClass(row, 't-dsc-header'):
-# If we saw a decl since the last header, this is a new block of headers
-# for a new block of decls.
-if was_decl:
-  current_headers = []
-was_decl = False
+rows = table.select('tr')
+i = 0
+while i < len(rows):
+  start = i
+  current_headers = set()
+  while i < len(rows) and _HasClass(rows[i], 't-dsc-header'):
+row = rows[i]
 #

[PATCH] D142092: [include-mapping] Allow multiple headers for the same symbol. Choose the first header of available ones.

2023-01-31 Thread Viktoriia Bakalova via Phabricator via cfe-commits
VitaNuo added a comment.

Thanks for the comments!




Comment at: clang/tools/include-mapping/cppreference_parser.py:196
+  "std::remove$": "algorithm",
+  "std::atomic.*": "atomic",
+

kadircet wrote:
> there's no variant of "std::atomic.*" called "atomic", in 
> https://en.cppreference.com/w/cpp/symbol_index. is it something in 2018 
> version of the html book? otherwise there's only the unnamed variant and 
> std::shared_ptr variant, and we should be preferring unnamed variant.
This is obsolete. As discussed offline, I've removed all the special-casing 
logic. All the variants are skipped now without exceptions.



Comment at: clang/tools/include-mapping/cppreference_parser.py:107
+  # FIXME: only consider first symbol, assume further symbols are overloads
+  all_headers = sorted(list(all_headers))
+  if len(all_headers) > 0:

kadircet wrote:
> VitaNuo wrote:
> > hokein wrote:
> > > why sort the headers?
> > This was a hack to make the generator return `atomic` rather than `memory` 
> > for `std::atomic.*` symbols. But I've noticed now that this adds some 
> > trouble to the C symbol map. I think now that cutting `all_headers` to the 
> > first element is wrong.
> > I will special-case the `std::atomic.*` symbols instead, because so far I 
> > don't see a way to solve this programmatically without other collateral 
> > effects.
> > 
> > Note that the problem is not `std::atomic` itself (for which Kadir 
> > extensively described the solution in some of the other comments), but 
> > rather `atomic_bool`, `atomic_char` etc. mentioned further in the page. The 
> > headers for them come from `all_headers` rather than `symbol_headers`, and 
> > there seems to be no way to limit them to `` without other 
> > collateral effects.
> > I think now that cutting all_headers to the first element is wrong.
> 
> What's exactly breaking once you do that? (I guess by `first element` you 
> still mean "all the headers we've seen until the first declaration in the 
> page")
> 
> >  but rather atomic_bool, atomic_char etc. mentioned further in the page. 
> > The headers for them come from all_headers rather than symbol_headers, and 
> > there seems to be no way to limit them to  without other collateral 
> > effects.
> 
> I guess this is happening because we're trying to find headers that are for 
> the declaration block containing the interesting symbol name. Any idea if 
> that logic is winning us anything? e.g. if we dropped the `if 
> symbol_name in found_symbols:` what does change?
> I guess by first element you still mean "all the headers we've seen until the 
> first declaration in the page"

No, I mean the first element of the `all_headers` collection. `all_headers` is 
a collection that collects _all_ the headers in the page and, in case a symbol 
is not defined in a table with an individual header block, `all_headers` in the 
page are returned as an approximation.

> What's exactly breaking once you do that?
It is essentially arbitrary to limit `all_headers` to the first element (at the 
moment it would be the first element alphabetically). E.g., for the `INT8_C` 
and other constants [here](https://en.cppreference.com/w/cpp/types/integer), 
the result would be `inttypes.h` and `stdint.h` would be cut, so this result 
doesn't make sense.

> if we dropped the  `if symbol_name in found_symbols` what does change?
Then all the headers in the table will be attributed to all the symbols in the 
table. Consider [this 
page](https://en.cppreference.com/w/cpp/numeric/math/div): `std::imaxdiv` would 
be reported as defined both in `cstdlib` and `cinttypes`, which is wrong. 

> I guess this is happening because we're trying to find headers that are for 
> the declaration block containing the interesting symbol name.

Not really.  Headers for `atomic_bool`, `atomic_char` etc. come from 
`all_headers` rather than `symbol_headers`. The reason for that is they are 
defined in a table which doesn't have its own header block, so we are trying to 
approximate the headers by naming all the headers in the file.



Comment at: clang/tools/include-mapping/cppreference_parser.py:165
   # FIXME: use these as a fallback rather than ignoring entirely.
-  variants_for_symbol = variants_to_accept.get(
-  (namespace or "") + symbol_name, ())
-  if variant and variant not in variants_for_symbol:
+  header_to_accept = variants_to_accept.get(
+  (namespace or "") + symbol_name, "")

kadircet wrote:
> VitaNuo wrote:
> > kadircet wrote:
> > > `variant` is not necessarily the `header`, eg:
> > > ```
> > > acos()
> > > acos<>() (std::complex) (since C++11)
> > > acos<>() (std::valarray)
> > > ```
> > > 
> > > in this case variants are `std::complex` and `std::valarray`. 
> > > 
> > > hence we're not trying to "infer" the header we want to preserve but 
> > > rather decide on which symbol page we want to par

[PATCH] D142092: [include-mapping] Allow multiple headers for the same symbol. Choose the first header of available ones.

2023-01-31 Thread Viktoriia Bakalova via Phabricator via cfe-commits
VitaNuo updated this revision to Diff 493565.
VitaNuo added a comment.

Remove a FIXME.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142092

Files:
  clang/include/clang/Tooling/Inclusions/CSymbolMap.inc
  clang/include/clang/Tooling/Inclusions/StdSymbolMap.inc
  clang/lib/Tooling/Inclusions/Stdlib/StandardLibrary.cpp
  clang/tools/include-mapping/cppreference_parser.py
  clang/tools/include-mapping/gen_std.py
  clang/tools/include-mapping/test.py

Index: clang/tools/include-mapping/test.py
===
--- clang/tools/include-mapping/test.py
+++ clang/tools/include-mapping/test.py
@@ -53,7 +53,7 @@
   
 
 """
-self.assertEqual(_ParseSymbolPage(html, 'foo'), set(['']))
+self.assertEqual(_ParseSymbolPage(html, 'foo', ""), set(['']))
 
 
   def testParseSymbolPage_MulHeaders(self):
@@ -94,7 +94,7 @@
   
 
 """
-self.assertEqual(_ParseSymbolPage(html, "foo"),
+self.assertEqual(_ParseSymbolPage(html, "foo", ""),
  set(['', '']))
 
 
@@ -121,7 +121,7 @@
 
 
 """
-self.assertEqual(_ParseSymbolPage(html, "foo"),
+self.assertEqual(_ParseSymbolPage(html, "foo", ""),
  set(['', '']))
 
   def testParseSymbolPage_MulSymbolsInSameTd(self):
@@ -145,9 +145,9 @@
 
 
 """
-self.assertEqual(_ParseSymbolPage(html, "int8_t"),
+self.assertEqual(_ParseSymbolPage(html, "int8_t", ""),
  set(['']))
-self.assertEqual(_ParseSymbolPage(html, "int16_t"),
+self.assertEqual(_ParseSymbolPage(html, "int16_t", ""),
  set(['']))
 
 
Index: clang/tools/include-mapping/gen_std.py
===
--- clang/tools/include-mapping/gen_std.py
+++ clang/tools/include-mapping/gen_std.py
@@ -14,10 +14,7 @@
 The generated files are located in clang/include/Tooling/Inclusions.
 
 Caveats and FIXMEs:
-  - only symbols directly in "std" namespace are added, we should also add std's
-subnamespace symbols (e.g. chrono).
-  - symbols with multiple variants or defined in multiple headers aren't added,
-e.g. std::move, std::swap
+  - symbols with multiple variants aren't added, e.g., std::move
 
 Usage:
   1. Install BeautifulSoup dependency, see instruction:
@@ -110,17 +107,13 @@
 os.stat(index_page_path).st_mtime).strftime('%Y-%m-%d')
   print(CODE_PREFIX % (args.symbols.upper(), cppreference_modified_date))
   for symbol in symbols:
-if len(symbol.headers) == 1:
-  # SYMBOL(unqualified_name, namespace, header)
-  print("SYMBOL(%s, %s, %s)" % (symbol.name, symbol.namespace,
-symbol.headers[0]))
-elif len(symbol.headers) == 0:
+if len(symbol.headers) == 0:
   sys.stderr.write("No header found for symbol %s\n" % symbol.name)
 else:
-  # FIXME: support symbols with multiple headers (e.g. std::move).
-  sys.stderr.write("Ambiguous header for symbol %s: %s\n" % (
-  symbol.name, ', '.join(symbol.headers)))
-
-
+  symbol.headers = sorted(symbol.headers)
+  for header in symbol.headers:
+# SYMBOL(unqualified_name, namespace, header)
+print("SYMBOL(%s, %s, %s)" % (symbol.name, symbol.namespace,
+  header))
 if __name__ == '__main__':
   main()
Index: clang/tools/include-mapping/cppreference_parser.py
===
--- clang/tools/include-mapping/cppreference_parser.py
+++ clang/tools/include-mapping/cppreference_parser.py
@@ -47,7 +47,7 @@
 
   Returns a list of headers.
   """
-  headers = set()
+  symbol_headers = set()
   all_headers = set()
 
   soup = BeautifulSoup(symbol_page_html, "html.parser")
@@ -58,32 +58,48 @@
   #   Defined in header   .t-dsc-header
   #   decl2.t-dcl
   for table in soup.select('table.t-dcl-begin, table.t-dsc-begin'):
-current_headers = []
-was_decl = False
-for row in table.select('tr'):
-  if _HasClass(row, 't-dcl', 't-dsc'):
-was_decl = True
-# Symbols are in the first cell.
-found_symbols = row.find('td').stripped_strings
-if not symbol_name in found_symbols:
-  continue
-headers.update(current_headers)
-  elif _HasClass(row, 't-dsc-header'):
-# If we saw a decl since the last header, this is a new block of headers
-# for a new block of decls.
-if was_decl:
-  current_headers = []
-was_decl = False
+rows = table.select('tr')
+i = 0
+while i < len(rows):
+  start = i
+  current_headers = set()
+  while i < len(rows) and _HasClass(rows[i], 't-dsc-header'):
+row = rows[i]
 # There are also .t-dsc-header for "defined in namespace".
 if not "Defined in header " in row.text:
+  i = i + 1
   continue
 # The interesting h

[PATCH] D142823: Intrinsics: Allow tablegen to mark parameters with dereferenceable

2023-01-31 Thread Matt Arsenault via Phabricator via cfe-commits
arsenm updated this revision to Diff 493566.
arsenm added a comment.

Revert implicitarg.ptr changes since not-HSA has different alignment for no 
reason. Also with the size differences between amdhsa and different CO versions 
we're already wrong for emitting 256 unconditionally


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

https://reviews.llvm.org/D142823

Files:
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGenCUDA/amdgpu-workgroup-size.cu
  clang/test/CodeGenCUDA/builtins-amdgcn.cu
  clang/test/CodeGenOpenCL/builtins-amdgcn.cl
  llvm/include/llvm/IR/Intrinsics.td
  llvm/include/llvm/IR/IntrinsicsAMDGPU.td
  llvm/test/CodeGen/AMDGPU/implicit-arg-v5-opt.ll
  llvm/unittests/CodeGen/GlobalISel/KnownBitsTest.cpp
  llvm/utils/TableGen/CodeGenIntrinsics.h
  llvm/utils/TableGen/CodeGenTarget.cpp
  llvm/utils/TableGen/IntrinsicEmitter.cpp

Index: llvm/utils/TableGen/IntrinsicEmitter.cpp
===
--- llvm/utils/TableGen/IntrinsicEmitter.cpp
+++ llvm/utils/TableGen/IntrinsicEmitter.cpp
@@ -726,6 +726,10 @@
   OS << "  Attribute::get(C, Attribute::Alignment, "
  << Attr.Value << "),\n";
   break;
+case CodeGenIntrinsic::Dereferenceable:
+  OS << "  Attribute::get(C, Attribute::Dereferenceable, "
+ << Attr.Value << "),\n";
+  break;
 }
   }
   OS << "});\n";
Index: llvm/utils/TableGen/CodeGenTarget.cpp
===
--- llvm/utils/TableGen/CodeGenTarget.cpp
+++ llvm/utils/TableGen/CodeGenTarget.cpp
@@ -923,6 +923,10 @@
 unsigned ArgNo = R->getValueAsInt("ArgNo");
 uint64_t Align = R->getValueAsInt("Align");
 addArgAttribute(ArgNo, Alignment, Align);
+  } else if (R->isSubClassOf("Dereferenceable")) {
+unsigned ArgNo = R->getValueAsInt("ArgNo");
+uint64_t Bytes = R->getValueAsInt("Bytes");
+addArgAttribute(ArgNo, Dereferenceable, Bytes);
   } else
 llvm_unreachable("Unknown property!");
 }
Index: llvm/utils/TableGen/CodeGenIntrinsics.h
===
--- llvm/utils/TableGen/CodeGenIntrinsics.h
+++ llvm/utils/TableGen/CodeGenIntrinsics.h
@@ -119,7 +119,8 @@
 WriteOnly,
 ReadNone,
 ImmArg,
-Alignment
+Alignment,
+Dereferenceable
   };
 
   struct ArgAttribute {
Index: llvm/unittests/CodeGen/GlobalISel/KnownBitsTest.cpp
===
--- llvm/unittests/CodeGen/GlobalISel/KnownBitsTest.cpp
+++ llvm/unittests/CodeGen/GlobalISel/KnownBitsTest.cpp
@@ -1012,8 +1012,8 @@
 
   GISelKnownBits Info(*MF);
 
-  EXPECT_EQ(Align(4), Info.computeKnownAlignment(CopyDispatchPtr));
-  EXPECT_EQ(Align(4), Info.computeKnownAlignment(CopyQueuePtr));
+  EXPECT_EQ(Align(8), Info.computeKnownAlignment(CopyDispatchPtr));
+  EXPECT_EQ(Align(8), Info.computeKnownAlignment(CopyQueuePtr));
   EXPECT_EQ(Align(4), Info.computeKnownAlignment(CopyKernargSegmentPtr));
   EXPECT_EQ(Align(4), Info.computeKnownAlignment(CopyImplicitArgPtr));
   EXPECT_EQ(Align(4), Info.computeKnownAlignment(CopyImplicitBufferPtr));
Index: llvm/test/CodeGen/AMDGPU/implicit-arg-v5-opt.ll
===
--- llvm/test/CodeGen/AMDGPU/implicit-arg-v5-opt.ll
+++ llvm/test/CodeGen/AMDGPU/implicit-arg-v5-opt.ll
@@ -47,7 +47,7 @@
 ; GCN-LABEL: @get_local_size_z(
 ; GCN-NEXT:[[IMPLICITARG_PTR:%.*]] = tail call ptr addrspace(4) @llvm.amdgcn.implicitarg.ptr()
 ; GCN-NEXT:[[GEP_LOCAL_SIZE:%.*]] = getelementptr inbounds i8, ptr addrspace(4) [[IMPLICITARG_PTR]], i64 16
-; GCN-NEXT:[[LOCAL_SIZE:%.*]] = load i16, ptr addrspace(4) [[GEP_LOCAL_SIZE]], align 4
+; GCN-NEXT:[[LOCAL_SIZE:%.*]] = load i16, ptr addrspace(4) [[GEP_LOCAL_SIZE]], align 8
 ; GCN-NEXT:store i16 [[LOCAL_SIZE]], ptr addrspace(1) [[OUT:%.*]], align 2
 ; GCN-NEXT:ret void
 ;
@@ -139,7 +139,7 @@
 ; GCN-LABEL: @get_work_group_size_z(
 ; GCN-NEXT:[[IMPLICITARG_PTR:%.*]] = tail call ptr addrspace(4) @llvm.amdgcn.implicitarg.ptr()
 ; GCN-NEXT:[[GEP_Z:%.*]] = getelementptr inbounds i8, ptr addrspace(4) [[IMPLICITARG_PTR]], i64 16
-; GCN-NEXT:[[GROUP_SIZE_Z:%.*]] = load i16, ptr addrspace(4) [[GEP_Z]], align 4
+; GCN-NEXT:[[GROUP_SIZE_Z:%.*]] = load i16, ptr addrspace(4) [[GEP_Z]], align 8
 ; GCN-NEXT:store i16 [[GROUP_SIZE_Z]], ptr addrspace(1) [[OUT:%.*]], align 2
 ; GCN-NEXT:ret void
 ;
Index: llvm/include/llvm/IR/IntrinsicsAMDGPU.td
===
--- llvm/include/llvm/IR/IntrinsicsAMDGPU.td
+++ llvm/include/llvm/IR/IntrinsicsAMDGPU.td
@@ -141,8 +141,10 @@
<"__builtin_amdgcn_workgroup_id">;
 
 def int_amdgcn_dispatch_ptr :
+  ClangBuiltin<"__builtin_amdgcn_dispatch_ptr">,
   DefaultAttrsIntrinsic<[LLVMQualPointerType], [],
-  [Align, IntrNoMem, IntrSpeculata

[PATCH] D142823: Intrinsics: Allow tablegen to mark parameters with dereferenceable

2023-01-31 Thread Jay Foad via Phabricator via cfe-commits
foad added a comment.

I think the tablegen functionality should be a separate patch from the amdgpu 
changes.


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

https://reviews.llvm.org/D142823

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


[PATCH] D142968: [NFC] Extract `CodeGenInstAlias` into its own *.h/*.cpp

2023-01-31 Thread Jay Foad via Phabricator via cfe-commits
foad accepted this revision.
foad added a comment.
This revision is now accepted and ready to land.

Seems reasonable.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142968

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


[PATCH] D142823: Intrinsics: Allow tablegen to mark parameters with dereferenceable

2023-01-31 Thread Matt Arsenault via Phabricator via cfe-commits
arsenm added a comment.

In D142823#4093357 , @foad wrote:

> I think the tablegen functionality should be a separate patch from the amdgpu 
> changes.

Maybe, but then it’s untested in the patch which adds it


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

https://reviews.llvm.org/D142823

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


[PATCH] D142823: Intrinsics: Allow tablegen to mark parameters with dereferenceable

2023-01-31 Thread Jay Foad via Phabricator via cfe-commits
foad added a comment.

In D142823#4093363 , @arsenm wrote:

> In D142823#4093357 , @foad wrote:
>
>> I think the tablegen functionality should be a separate patch from the 
>> amdgpu changes.
>
> Maybe, but then it’s untested in the patch which adds it

Not if you add a test. There are some already like test/TableGen/immarg.td and 
test/TableGen/intrin-side-effects.td.


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

https://reviews.llvm.org/D142823

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


[PATCH] D141472: [clang][Interp] Add function pointers

2023-01-31 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D141472#4092745 , @tbaeder wrote:

> In D141472#4091662 , @aaron.ballman 
> wrote:
>
>> Design question -- do you anticipate this class handling *all* function 
>> pointers, including pointer to member functions that might be virtual: 
>> https://godbolt.org/z/hT8fMY37n
>
> I had to make a few adjustments but I have that example working locally now, 
> of course no idea if that would work generally. Do you see any problem with 
> the proposed `FunctionPointer` class?
>
> According to https://clang.llvm.org/docs/ConstantInterpreter.html#pointers, 
> there was a `MemberPointer` class that sounds related to this, but I don't 
> know more about it. I guess, since you made `func()` virtual, that matters 
> and becomes a bytecode-runtime decision instead of being known at 
> compile-time, which seems to be the case in your example?

Member pointers (for functions or for data) are weird in that they're not the 
typical pointer width. They're actually a pointer and between one-to-three 
other fields in a trenchcoat, depending on the circumstances. You generally 
need the function pointer, but you also may need various offsets (to this, to 
the vtable, etc). There's some more information about how it's done in MSVC 
(which is different from Itanium ABI, but we can do what we want for the 
constant expression interpreter): https://rants.vastheman.com/2021/09/21/msvc/

I don't think there's a problem with `FunctionPointer` per se, I'm more 
wondering are you planning to also add a `MemberPointer` type or are you 
planning to reuse `FunctionPointer` to handle function members (and presumably 
something else for data members)?

As for virtual functions in general, the standard has rules: 
http://eel.is/c++draft/expr.const#5.6 and http://eel.is/c++draft/expr.const#7


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

https://reviews.llvm.org/D141472

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


[PATCH] D142384: [C++20] Fix a crash with modules.

2023-01-31 Thread Ilya Biryukov via Phabricator via cfe-commits
ilya-biryukov added a reviewer: rsmith.
ilya-biryukov added a comment.

This fix looks very sensible to me and @rsmith confirmed this pattern that we 
are seeing might happen (seeing members of something that was demoted from 
declaration to a definition).
@rsmith could you confirm the update version looks good to you?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142384

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


[PATCH] D140874: [clang][Interp] Support pointer types in compound assignment operations

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

LGTM


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

https://reviews.llvm.org/D140874

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


[PATCH] D142914: [MLIR][OpenMP] Added OMPIRBuilder support for Target Data directives.

2023-01-31 Thread Akash Banerjee via Phabricator via cfe-commits
TIFitis marked an inline comment as done.
TIFitis added inline comments.



Comment at: 
mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp:1342-1382
+/// Create a constant string location from the MLIR Location information.
+static llvm::Constant *
+createSourceLocStrFromLocation(Location loc, llvm::OpenMPIRBuilder &builder,
+   StringRef name, uint32_t &strLen) {
+  if (auto fileLoc = loc.dyn_cast()) {
+StringRef fileName = fileLoc.getFilename();
+unsigned lineNo = fileLoc.getLine();

clementval wrote:
> TIFitis wrote:
> > clementval wrote:
> > > kiranchandramohan wrote:
> > > > clementval wrote:
> > > > > Instead of copy pasting this from 
> > > > > `mlir/lib/Target/LLVMIR/Dialect/OpenACC/OpenACCToLLVMIRTranslation.cpp`
> > > > >  can you extract it and put it in a common shared file so bith 
> > > > > translation can use the same code without duplication?
> > > > @raghavendhra put up a patch some time back and he faced some issues. 
> > > > It might be good to check with him or may be he can comment here.
> > > > https://reviews.llvm.org/D127037
> > > > https://discourse.llvm.org/t/rfc-for-refactoring-common-code-for-openacc-and-openmp/63833
> > > Just moving the three functions should be trivial. I'm not talking about 
> > > the processMapOperand.
> > I've moved `getSizeInBytes`.
> > 
> > The other two functions make use of `mlir::Location` and thus can't be 
> > moved trivially.
> > 
> > I can still try to move them by individually passing the elements of 
> > `mlir::Location` but that might not be ideal. Is that what you'd like?
> What about a new header file in `mlir/include/mlir/Target/LLVMIR/Dialect/**` 
> shared by 
> `mlir/lib/Target/LLVMIR/Dialect/OpenACC/OpenACCToLLVMIRTranslation.cpp` and 
> `mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp`. That 
> should be doable. 
`mlir/lib/Target/LLVMIR/Dialect/OpenACC/OpenACCToLLVMIRTranslation.cpp` and 
`mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp` already 
have access to the common `mlir::Location` type.

Problem is that `OMPIRBuilder.cpp` is the only common file between them  where 
I can move the two functions to. Currently there are no `mlir/**` include files 
in `OMPIRBuilder.cpp` and it seems to me like a strict design choice to have it 
that way.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142914

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


[PATCH] D141591: [clang][Interp] Properly identify not-yet-defined functions

2023-01-31 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/test/AST/Interp/functions.cpp:158-174
+struct F {
+  constexpr bool ok() const {
+return okRecurse();
+  }
+  constexpr bool okRecurse() const {
+return true;
+  }

Should we have some similar tests involving free functions as well?

Also, how does `BodylessMemberFunction` differ from `F`? They both look to be 
testing the same thing aside from return types.

Should we have a test that involves a defaulted special member function that is 
called explicitly? e.g., https://godbolt.org/z/nzjEcPMKG (Clang is correct 
here, GCC fails to catch the UB).


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

https://reviews.llvm.org/D141591

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


[PATCH] D141858: [clang][Interp] Fix Pointer::toAPValue() for expressions

2023-01-31 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

Test coverage?


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

https://reviews.llvm.org/D141858

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


[PATCH] D142757: [clang][driver] Emit an error for `/clang:-x`

2023-01-31 Thread Mariya Podchishchaeva via Phabricator via cfe-commits
Fznamznon updated this revision to Diff 493576.
Fznamznon added a comment.

Apply suggestions


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142757

Files:
  clang/docs/ReleaseNotes.rst
  clang/lib/Driver/Driver.cpp
  clang/test/ClangScanDeps/Inputs/modules_cdb_clangcl_by_mod_name.json
  clang/test/Driver/x-args.c


Index: clang/test/Driver/x-args.c
===
--- clang/test/Driver/x-args.c
+++ clang/test/Driver/x-args.c
@@ -5,3 +5,9 @@
 // RUN: %clang -fsyntax-only -xc %s -xc++ -fsyntax-only 2>&1 | FileCheck %s
 // RUN: %clang -fsyntax-only %s -xc %s -xc++ -fsyntax-only 2>&1 | FileCheck %s
 // CHECK: '-x c++' after last input file has no effect
+
+// RUN: not %clang_cl /WX /clang:-xc /clang:-E /clang:-dM %s 2>&1 | FileCheck 
-check-prefix=CL %s
+// RUN: not %clang_cl /WX /clang:-E /clang:-dM %s /clang:-xc 2>&1 | FileCheck 
-check-prefix=CL %s
+// RUN: not %clang_cl /TC /WX /clang:-xc /clang:-E /clang:-dM %s 2>&1 | 
FileCheck -check-prefix=CL %s
+// CL-NOT: '-x c' after last input file has no effect
+// CL: error: unsupported option '-x c'; did you mean '/TC' or '/TP'?
Index: clang/test/ClangScanDeps/Inputs/modules_cdb_clangcl_by_mod_name.json
===
--- clang/test/ClangScanDeps/Inputs/modules_cdb_clangcl_by_mod_name.json
+++ clang/test/ClangScanDeps/Inputs/modules_cdb_clangcl_by_mod_name.json
@@ -1,12 +1,12 @@
 [
 {
   "directory": "DIR",
-  "command": "clang-cl /E /IInputs /D INCLUDE_HEADER2 /clang:-MD /clang:-MF 
/clang:DIR/modules_cdb2_clangcl.d /clang:-fmodules /clang:-fcxx-modules 
/clang:-fmodules-cache-path=DIR/module-cache_clangcl /clang:-fimplicit-modules 
/clang:-fimplicit-module-maps /clang:-x /clang:c++ --",
+  "command": "clang-cl /E /IInputs /D INCLUDE_HEADER2 /clang:-MD /clang:-MF 
/clang:DIR/modules_cdb2_clangcl.d /clang:-fmodules /clang:-fcxx-modules 
/clang:-fmodules-cache-path=DIR/module-cache_clangcl /clang:-fimplicit-modules 
/clang:-fimplicit-module-maps /TP --",
   "file": ""
 },
 {
   "directory": "DIR",
-  "command": "clang-cl /E /IInputs /clang:-fmodules /clang:-fcxx-modules 
/clang:-fmodules-cache-path=DIR/module-cache_clangcl /clang:-fimplicit-modules 
/clang:-fimplicit-module-maps /clang:-x /clang:c++ --",
+  "command": "clang-cl /E /IInputs /clang:-fmodules /clang:-fcxx-modules 
/clang:-fmodules-cache-path=DIR/module-cache_clangcl /clang:-fimplicit-modules 
/clang:-fimplicit-module-maps /TP --",
   "file": ""
 },
 ]
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -2566,17 +2566,21 @@
 }
 if (ShowNote)
   Diag(clang::diag::note_drv_t_option_is_global);
-
-// No driver mode exposes -x and /TC or /TP; we don't support mixing them.
-assert(!Args.hasArg(options::OPT_x) && "-x and /TC or /TP is not allowed");
   }
 
   // Warn -x after last input file has no effect
-  {
+  if (!IsCLMode()) {
 Arg *LastXArg = Args.getLastArgNoClaim(options::OPT_x);
 Arg *LastInputArg = Args.getLastArgNoClaim(options::OPT_INPUT);
-if (LastXArg && LastInputArg && LastInputArg->getIndex() < 
LastXArg->getIndex())
+if (LastXArg && LastInputArg &&
+LastInputArg->getIndex() < LastXArg->getIndex())
   Diag(clang::diag::warn_drv_unused_x) << LastXArg->getValue();
+  } else {
+// In CL mode suggest /TC or /TP since -x doesn't make sense if passed via
+// /clang:.
+if (auto *A = Args.getLastArg(options::OPT_x))
+  Diag(diag::err_drv_unsupported_opt_with_suggestion)
+  << A->getAsString(Args) << "/TC' or '/TP";
   }
 
   for (Arg *A : Args) {
Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -60,6 +60,10 @@
 - Fix crash when diagnosing incorrect usage of ``_Nullable`` involving alias
   templates. This fixes
   `Issue 60344 `_.
+- Fix confusing warning message when ``/clang:-x`` is passed in ``clang-cl``
+  driver mode and emit an error which suggests using ``/TC`` or ``/TP``
+  ``clang-cl`` options instead. This fixes
+  `Issue 59307 `_.
 
 Improvements to Clang's diagnostics
 ^^^


Index: clang/test/Driver/x-args.c
===
--- clang/test/Driver/x-args.c
+++ clang/test/Driver/x-args.c
@@ -5,3 +5,9 @@
 // RUN: %clang -fsyntax-only -xc %s -xc++ -fsyntax-only 2>&1 | FileCheck %s
 // RUN: %clang -fsyntax-only %s -xc %s -xc++ -fsyntax-only 2>&1 | FileCheck %s
 // CHECK: '-x c++' after last input file has no effect
+
+// RUN: not %clang_cl /WX /clang:-xc /clang:-E /clang:-dM %s 2>&1 | FileCheck -check-prefix=CL %s
+

[PATCH] D142914: [MLIR][OpenMP] Added OMPIRBuilder support for Target Data directives.

2023-01-31 Thread Valentin Clement via Phabricator via cfe-commits
clementval added inline comments.



Comment at: 
mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp:1342-1382
+/// Create a constant string location from the MLIR Location information.
+static llvm::Constant *
+createSourceLocStrFromLocation(Location loc, llvm::OpenMPIRBuilder &builder,
+   StringRef name, uint32_t &strLen) {
+  if (auto fileLoc = loc.dyn_cast()) {
+StringRef fileName = fileLoc.getFilename();
+unsigned lineNo = fileLoc.getLine();

TIFitis wrote:
> clementval wrote:
> > TIFitis wrote:
> > > clementval wrote:
> > > > kiranchandramohan wrote:
> > > > > clementval wrote:
> > > > > > Instead of copy pasting this from 
> > > > > > `mlir/lib/Target/LLVMIR/Dialect/OpenACC/OpenACCToLLVMIRTranslation.cpp`
> > > > > >  can you extract it and put it in a common shared file so bith 
> > > > > > translation can use the same code without duplication?
> > > > > @raghavendhra put up a patch some time back and he faced some issues. 
> > > > > It might be good to check with him or may be he can comment here.
> > > > > https://reviews.llvm.org/D127037
> > > > > https://discourse.llvm.org/t/rfc-for-refactoring-common-code-for-openacc-and-openmp/63833
> > > > Just moving the three functions should be trivial. I'm not talking 
> > > > about the processMapOperand.
> > > I've moved `getSizeInBytes`.
> > > 
> > > The other two functions make use of `mlir::Location` and thus can't be 
> > > moved trivially.
> > > 
> > > I can still try to move them by individually passing the elements of 
> > > `mlir::Location` but that might not be ideal. Is that what you'd like?
> > What about a new header file in 
> > `mlir/include/mlir/Target/LLVMIR/Dialect/**` shared by 
> > `mlir/lib/Target/LLVMIR/Dialect/OpenACC/OpenACCToLLVMIRTranslation.cpp` and 
> > `mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp`. That 
> > should be doable. 
> `mlir/lib/Target/LLVMIR/Dialect/OpenACC/OpenACCToLLVMIRTranslation.cpp` and 
> `mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp` already 
> have access to the common `mlir::Location` type.
> 
> Problem is that `OMPIRBuilder.cpp` is the only common file between them  
> where I can move the two functions to. Currently there are no `mlir/**` 
> include files in `OMPIRBuilder.cpp` and it seems to me like a strict design 
> choice to have it that way.
The functions can be header only. Why do you need to put them in the 
OMPIRBuilder.cpp? I think it is better than duplicate the exact same code over. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142914

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


[PATCH] D142757: [clang][driver] Emit an error for `/clang:-x`

2023-01-31 Thread Mariya Podchishchaeva via Phabricator via cfe-commits
Fznamznon added inline comments.



Comment at: clang/lib/Driver/Driver.cpp:2571
 // No driver mode exposes -x and /TC or /TP; we don't support mixing them.
 assert(!Args.hasArg(options::OPT_x) && "-x and /TC or /TP is not allowed");
   }

MaskRay wrote:
> Fznamznon wrote:
> > MaskRay wrote:
> > > ```
> > > -assert(!Args.hasArg(options::OPT_x) && "-x and /TC or /TP is not 
> > > allowed");
> > > +if (auto *A = Args.getLastArg(options::OPT_x))
> > > +  Diag(diag::err_drv_unsupported_opt_with_suggestion)
> > > +  << A->getAsString(Args) << "/TC' or '/TP";
> > > ```
> > Thank you, the suggestion seems reasonable to me. Although, the concrete 
> > place doesn't.
> > The suggested line to change is under if (we have /TC or /TP argument), so 
> > if I put error emission there it won't be emitted if no /TC or /TP was 
> > passed and the original problem reported in 
> > https://github.com/llvm/llvm-project/issues/59307 won't be resolved. People 
> > will still be confused by the warning saying `-x c` passed after last input 
> > when in fact they passed `/clang:-x` before the input.
> > 
> > Also, the whole function doesn't return even if diagnostic is emitted, so I 
> > put error emission in a way to not emit a warning saying that -x is passed 
> > after last input together with it, because both errors emitted like this:
> > 
> > error: '-x c' after last input file has no effect
> > error: unsupported option '-x c'; did you mean '/TC' or '/TP'?
> > 
> > look confusing.
> You need to remove `assert(!Args.hasArg(options::OPT_x) && "-x and /TC or /TP 
> is not allowed");` as otherwise `/clang:-x /TC` leads to a crash in an assert 
> build of clang (`LLVM_ENABLE_ASSERTIONS=on`).
Ok, removed the assert. Verified there is no crash in the test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142757

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


[PATCH] D142976: [clang][CGCall] Remove header file not used. [NFCI]

2023-01-31 Thread Francesco Petrogalli via Phabricator via cfe-commits
fpetrogalli created this revision.
Herald added a project: All.
fpetrogalli requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D142976

Files:
  clang/lib/CodeGen/CGCall.cpp


Index: clang/lib/CodeGen/CGCall.cpp
===
--- clang/lib/CodeGen/CGCall.cpp
+++ clang/lib/CodeGen/CGCall.cpp
@@ -25,7 +25,6 @@
 #include "clang/AST/DeclCXX.h"
 #include "clang/AST/DeclObjC.h"
 #include "clang/Basic/CodeGenOptions.h"
-#include "clang/Basic/TargetBuiltins.h"
 #include "clang/Basic/TargetInfo.h"
 #include "clang/CodeGen/CGFunctionInfo.h"
 #include "clang/CodeGen/SwiftCallingConv.h"


Index: clang/lib/CodeGen/CGCall.cpp
===
--- clang/lib/CodeGen/CGCall.cpp
+++ clang/lib/CodeGen/CGCall.cpp
@@ -25,7 +25,6 @@
 #include "clang/AST/DeclCXX.h"
 #include "clang/AST/DeclObjC.h"
 #include "clang/Basic/CodeGenOptions.h"
-#include "clang/Basic/TargetBuiltins.h"
 #include "clang/Basic/TargetInfo.h"
 #include "clang/CodeGen/CGFunctionInfo.h"
 #include "clang/CodeGen/SwiftCallingConv.h"
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D142826: [Clang] Add -Wtype-limits to -Wextra for GCC compatibility

2023-01-31 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/docs/ReleaseNotes.rst:45-46
 
+- -Wtype-limits added to -Wextra for GCC compatibility. This fixes
+  `Issue 58375 `_.
+

I'd move this into bug fixes as I don't think this is enough of a potential 
disruption to warrant putting it here. If we get user feedback about surprises, 
we might move it back to here later.



Comment at: clang/test/Sema/tautological-constant-compare.c:7-8
 // RUN: %clang_cc1 -triple x86_64-linux-gnu -fsyntax-only -Wtype-limits -DTEST 
-verify -x c++ %s
-// RUN: %clang_cc1 -triple x86_64-linux-gnu -fsyntax-only -Wextra 
-Wno-sign-compare -verify=silent %s
-// RUN: %clang_cc1 -triple x86_64-linux-gnu -fsyntax-only -Wextra 
-Wno-sign-compare -verify=silent -x c++ %s
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -fsyntax-only -Wextra 
-Wno-sign-compare -Wno-type-limits -verify=silent %s
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -fsyntax-only -Wextra 
-Wno-sign-compare -Wno-type-limits -verify=silent -x c++ %s
 // RUN: %clang_cc1 -triple x86_64-linux-gnu -fsyntax-only -Wall -verify=silent 
%s

I'd change this the other way; this way we demonstrate that `-Wextra` is what 
enabled `-Wtype-limits`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142826

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


[PATCH] D139926: [clangd] Add semantic token for angle brackets

2023-01-31 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet added inline comments.



Comment at: clang-tools-extra/clangd/SemanticHighlighting.cpp:382
+
+// For the inner element of a nested template instantiation with no space
+// between the '>' characters, TemplateSpecializationLocInfo::RAngleLoc has

i am actually having a hard time following the logic here. it feels like what 
you really want is map `>` back to its file location, possibly to a `>>` token, 
and deal with second case specially.
so maybe something like:
```
// RLoc might be pointing at a virtual buffer when it's part of a `>>` token.
RLoc = SM.getFileLoc(RLoc);
// Make sure token is part of the main file.
RLoc = getHighlightableSpellingToken(RLoc);
if(!RLoc.isValid())
  return;

const auto *RTok = TB.spelledTokenAt(RLoc);
// Handle `>>`. RLoc is always pointing at the right location, just change
// the end to be offset by 1.
// We'll either point at the beginning of `>>`, hence get a proper spelled
// or point in the middle of `>>` hence get no spelled tok.
if (!RTok || RTok->kind() == tok::greatergreater) {
  Position Begin = sourceLocToPosition(SourceMgr, RLoc);
  Position End = sourceLocToPosition(SourceMgr, RLoc.getLocWithOffset(1));
  addToken(*LRange, HighlightingKind::Bracket);
  addToken({Begin, End}, HighlightingKind::Bracket);
  return;
}

// Easy case, we have the `>` token directly available.
if (RTok->kind() == tok::greater) {
  if (auto RRange = getRangeForSourceLocation(RLoc)) {
addToken(*LRange, HighlightingKind::Bracket);
addToken(*RRange, HighlightingKind::Bracket);
  }
  return;
}
```

This should also make sure you're handling line continuations properly.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139926

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


[PATCH] D142871: [clangd] Semantic highlighting for constrained-parameter

2023-01-31 Thread Sam McCall via Phabricator via cfe-commits
sammccall added inline comments.



Comment at: clang-tools-extra/clangd/FindTarget.cpp:720
+  // Pick up the name via VisitNamedDecl
+  Base::VisitTemplateTypeParmDecl(D);
+}

kadircet wrote:
> nridge wrote:
> > Am I using the API correctly here? It's a bit weird that `ConstDeclVisitor` 
> > would work differently from `RecursiveASTVisitor` in that VisitXXX methods 
> > for super-classes are not automatically called
> right, non-recursive ast visitors are mere helpers for visiting most specific 
> type of an ast node which is interesting to the visitor (i.e. visit method is 
> overridden), and only that. they also don't traverse children of an entitie's 
> entries.
> 
> which usually hints towards this being the wrong place to handle such 
> constructs. we actually have an outer recursiveastvisitor, that tries to 
> visit each children. but concept references seem to be missing from there.
> taking a look at the RecursiveASTVisitor pieces around this piece, we 
> actually do visit the children appropriately:
> - 
> https://github.com/llvm/llvm-project/blob/main/clang/include/clang/AST/RecursiveASTVisitor.h#L1931
>  calls traverse on the constraint
> - 
> https://github.com/llvm/llvm-project/blob/main/clang/include/clang/AST/RecursiveASTVisitor.h#L1923
>  jumps into type constraint
> - 
> https://github.com/llvm/llvm-project/blob/main/clang/include/clang/AST/RecursiveASTVisitor.h#L510
>  some more indirection
> - 
> https://github.com/llvm/llvm-project/blob/main/clang/include/clang/AST/RecursiveASTVisitor.h#L547
>  calls visit for the decl name
> - 
> https://github.com/llvm/llvm-project/blob/clang/include/clang/AST/RecursiveASTVisitor.h#L830
>  unfortunately we stop here, because all we store is an identifier.
> 
> We should probably figure out how to properly visit type constraints inside 
> the RecursiveASTVisitor (i guess we should actually be visiting 
> TypeConstraints). @usaxena95 who's looking at C++20 features and their 
> interactions with source tooling.
> 
> In the meanwhile, i think we should have this specialization at the outer 
> layer, in `ExplicitReferenceCollector`, with something like:
> ```
> bool TraverseTemplateTypeParamDeclConstraints(TemplateTypeParmDecl *TTPD) {
>   if (auto *TC = TTPD->getTypeConstraint()) {
> reportReference(ReferenceLoc{TC->getNestedNameSpecifierLoc(),
>  TC->getConceptNameLoc(),
>  /*IsDecl=*/false,
>  {TC->getNamedConcept()}},
> DynTypedNode::create(*TTPD));
> return RecursiveASTVisitor::TraverseTypeConstraint(TC);
>   }
>   return true;
> }
> ```
> https://github.com/llvm/llvm-project/blob/clang/include/clang/AST/RecursiveASTVisitor.h#L830
>  unfortunately we stop here, because all we store is an identifier.

This isn't unfortunate, this is where we would handle things internal to the 
name (e.g. if the name was `operator vector()`) rather than what the name 
is used for.

The right level to handle this seems to be a missing 
`TraverseConceptReference()` which observes the lexical reference to a concept 
(we don't care here that it's a type constraint specifically).
Unfortunately this doesn't exist: we have `TraverseConceptReferenceHelper()` 
which is private and called nonpolymorphically.

Renaming this to `TraverseConceptReference()` and making it CRTP-overridable 
seems like the principled solution at the RAV level. Maybe there's some reason 
it wasn't done this way to start with though.

Failing that, overriding `TraverseTypeConstraint()` in our RAV subclass seems 
like it fits the pattern more neatly (there's no VisitTypeConstraint, so we 
have to override Traverse and call Base::Traverse). We're going to have to 
handle the other ways concepts can be referenced of course, but changing RAV vs 
working around its limitations is always a tradeoff of practicality.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142871

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


[PATCH] D142976: [clang][CGCall] Remove header file not used. [NFCI]

2023-01-31 Thread Francesco Petrogalli via Phabricator via cfe-commits
fpetrogalli accepted this revision.
fpetrogalli added a comment.
This revision is now accepted and ready to land.

Self approving a non-controversial trivial change.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142976

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


[PATCH] D142014: [clangd] fix wrong CalleeArgInfo in the hover

2023-01-31 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet added inline comments.



Comment at: clang-tools-extra/clangd/Hover.cpp:994
   HI.CalleeArgInfo.emplace(toHoverInfoParam(PVD, PP));
+  PassType.PassBy = getPassMode(PVD->getType());
+}

v1nh1shungry wrote:
> kadircet wrote:
> > v1nh1shungry wrote:
> > > kadircet wrote:
> > > > v1nh1shungry wrote:
> > > > > kadircet wrote:
> > > > > > sorry for showing up late to the party but instead of changing rest 
> > > > > > of the code, can we apply this logic only when there are no 
> > > > > > implicit casts/conversions between the arg and callexpr (i.e `N == 
> > > > > > &OuterNode`)?
> > > > > To make sure I understand it correctly, do you mean I should give up 
> > > > > any other code changes I made but keep this logic, and put this logic 
> > > > > into the `N == &OuterNode` branch?
> > > > > 
> > > > > Sorry if I misunderstood anything! Shame for not being a good reader 
> > > > > :(
> > > > > To make sure I understand it correctly, do you mean I should give up 
> > > > > any other code changes I made but keep this logic, and put this logic 
> > > > > into the N == &OuterNode branch?
> > > > 
> > > > Somewhat.
> > > > 
> > > > Basically this code had the assumption that if we don't see any 
> > > > casts/conversions between the expression creating the argument and the 
> > > > expression getting passed to the callexpr, it must be passed by 
> > > > reference, and this was wrong. Even before the patch that added 
> > > > handling for literals.
> > > > 
> > > > The rest of the handling for casts/conversions/constructors in between 
> > > > have been working so far and was constructed based on what each 
> > > > particular cast does, not for specific cases hence they're easier (for 
> > > > the lack of a better word) to reason about. Hence I'd rather keep them 
> > > > as is, especially the changes in handling `MaterializeTemporaryExpr` 
> > > > don't sound right. I can see the example you've at hand, but we 
> > > > shouldn't be producing "converted" results for it anyway (the AST 
> > > > should have a NoOp implicit cast to `const int` and then a 
> > > > `MaterializeTemporaryExpr`, which shouldn't generated any converted 
> > > > signals with the existing code already).
> > > > 
> > > > Hence the my proposal is getting rid of the assumption around "if we 
> > > > don't see any casts/conversions between the expression creating the 
> > > > argument and the expression getting passed to the callexpr, it must be 
> > > > passed by reference", and use the type information in `ParmVarDecl` 
> > > > directly when we don't have any implicit nodes in between to infer 
> > > > `PassBy`.
> > > > This should imply also getting rid of the special case for literals 
> > > > (`if (isLiteral(E) && N->Parent == OuterNode.Parent)`).
> > > > 
> > > > Does that make sense?
> > > Thanks for the detailed explanation! But before we go ahead here, what do 
> > > you think about the new test case I'm talking about above? Do you agree 
> > > with my conclusion?
> > i suppose you mean:
> > 
> > ```
> > void foobar(const float &);
> > int main() {
> >   foobar(0);
> >   ^
> > }
> > ```
> > 
> > first of all the version of the patch that i propose doesn't involve any 
> > changes in behaviour here (as we actually have an implicit cast in between, 
> > and i am suggesting finding out passby based on type of the parmvardecl 
> > only when there are no casts in between).
> > 
> > i can see @nridge 's reasoning about indicating copies by saying pass by 
> > value vs ref, which unfortunately doesn't align with C++ semantics directly 
> > (as what we have here is a prvalue, and it is indeed passed by value, 
> > without any copies to the callee).
> > 
> > it isn't very obvious anywhere but the main functionality we wanted to 
> > provide to the developer was help them figure out if a function call can 
> > mutate a parameter they were passing in, therefore it didn't prioritise 
> > literals at all. we probably should've made better wording choices in the 
> > UI and talked about "immutability". hence from functionality point of view 
> > calling this pass by `value` vs `const ref` doesn't make a huge difference 
> > (but that's probably only in my mind and people are already using it to 
> > infer other things like whether we're going to trigger copies).
> > 
> > so i'd actually leave this case as-is, and think about what we're actually 
> > trying to provide by showing arg info on literals. as it's currently trying 
> > to overload the meaning of `passby` and causing confusions. since the 
> > initial intent was to just convey "immutability" one suggestion would be to 
> > just hide the `passby` information for literals.
> > otherwise from value categories point of view, these are always passed by 
> > value, but this is going to create confusion for people that are using it 
> > to infer "copies" and getting that right, while preserving the semantics 
> > around "is this mutab

[clang] c3bc61d - [clang-format][NFC] Pull FormatTokenSource into its own header.

2023-01-31 Thread Manuel Klimek via cfe-commits

Author: Manuel Klimek
Date: 2023-01-31T14:32:31Z
New Revision: c3bc61d72f8da9a2b45e610ee3c2ccfc5f884f69

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

LOG: [clang-format][NFC] Pull FormatTokenSource into its own header.

Prepare getting FormatTokenSource under unit testing.

Added: 
clang/lib/Format/FormatTokenSource.h

Modified: 
clang/lib/Format/FormatToken.h
clang/lib/Format/UnwrappedLineParser.cpp

Removed: 




diff  --git a/clang/lib/Format/FormatToken.h b/clang/lib/Format/FormatToken.h
index 9d055efd80075..f3349a4dc2dfa 100644
--- a/clang/lib/Format/FormatToken.h
+++ b/clang/lib/Format/FormatToken.h
@@ -1803,6 +1803,25 @@ struct AdditionalKeywords {
   std::unordered_set VerilogExtraKeywords;
 };
 
+inline bool isLineComment(const FormatToken &FormatTok) {
+  return FormatTok.is(tok::comment) && !FormatTok.TokenText.startswith("/*");
+}
+
+// Checks if \p FormatTok is a line comment that continues the line comment
+// \p Previous. The original column of \p MinColumnToken is used to determine
+// whether \p FormatTok is indented enough to the right to continue \p 
Previous.
+inline bool continuesLineComment(const FormatToken &FormatTok,
+ const FormatToken *Previous,
+ const FormatToken *MinColumnToken) {
+  if (!Previous || !MinColumnToken)
+return false;
+  unsigned MinContinueColumn =
+  MinColumnToken->OriginalColumn + (isLineComment(*MinColumnToken) ? 0 : 
1);
+  return isLineComment(FormatTok) && FormatTok.NewlinesBefore == 1 &&
+ isLineComment(*Previous) &&
+ FormatTok.OriginalColumn >= MinContinueColumn;
+}
+
 } // namespace format
 } // namespace clang
 

diff  --git a/clang/lib/Format/FormatTokenSource.h 
b/clang/lib/Format/FormatTokenSource.h
new file mode 100644
index 0..11c735d368647
--- /dev/null
+++ b/clang/lib/Format/FormatTokenSource.h
@@ -0,0 +1,132 @@
+
+//===--- FormatTokenSource.h - Format C++ code --*- C++ 
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+///
+/// \file
+/// This file defines the \c TokenSource interface, which provides a token
+/// stream as well as the ability to manipulate the token stream.
+///
+//===--===//
+
+#ifndef LLVM_CLANG_LIB_FORMAT_FORMATTOKENSOURCE_H
+#define LLVM_CLANG_LIB_FORMAT_FORMATTOKENSOURCE_H
+
+#include "FormatToken.h"
+#include "UnwrappedLineParser.h"
+
+#define DEBUG_TYPE "format-token-source"
+
+namespace clang {
+namespace format {
+
+class FormatTokenSource {
+public:
+  virtual ~FormatTokenSource() {}
+
+  // Returns the next token in the token stream.
+  virtual FormatToken *getNextToken() = 0;
+
+  // Returns the token preceding the token returned by the last call to
+  // getNextToken() in the token stream, or nullptr if no such token exists.
+  virtual FormatToken *getPreviousToken() = 0;
+
+  // Returns the token that would be returned by the next call to
+  // getNextToken().
+  virtual FormatToken *peekNextToken(bool SkipComment = false) = 0;
+
+  // Returns whether we are at the end of the file.
+  // This can be 
diff erent from whether getNextToken() returned an eof token
+  // when the FormatTokenSource is a view on a part of the token stream.
+  virtual bool isEOF() = 0;
+
+  // Gets the current position in the token stream, to be used by 
setPosition().
+  virtual unsigned getPosition() = 0;
+
+  // Resets the token stream to the state it was in when getPosition() returned
+  // Position, and return the token at that position in the stream.
+  virtual FormatToken *setPosition(unsigned Position) = 0;
+};
+
+class ScopedMacroState : public FormatTokenSource {
+public:
+  ScopedMacroState(UnwrappedLine &Line, FormatTokenSource *&TokenSource,
+   FormatToken *&ResetToken)
+  : Line(Line), TokenSource(TokenSource), ResetToken(ResetToken),
+PreviousLineLevel(Line.Level), PreviousTokenSource(TokenSource),
+Token(nullptr), PreviousToken(nullptr) {
+FakeEOF.Tok.startToken();
+FakeEOF.Tok.setKind(tok::eof);
+TokenSource = this;
+Line.Level = 0;
+Line.InPPDirective = true;
+// InMacroBody gets set after the `#define x` part.
+  }
+
+  ~ScopedMacroState() override {
+TokenSource = PreviousTokenSource;
+ResetToken = Token;
+Line.InPPDirective = false;
+Line.InMacroBody = false;
+Line.Level = PreviousLineLevel;
+  }
+
+  FormatToken *getNextToken() override {
+// The \c UnwrappedLinePa

[PATCH] D122215: [WebAssembly] Initial support for reference type externref in clang

2023-01-31 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

Aside from a nit about comments, I don't have any further concerns. LGTM!




Comment at: clang/include/clang/Basic/WebAssemblyReferenceTypes.def:16
+//
+//  - Name is the name of the builtin type.  MangledName is the mangled name.
+//

pmatos wrote:
> aaron.ballman wrote:
> > aaron.ballman wrote:
> > > What kind of mangling is this name? Itanium? Microsoft? Something else?
> > Still wondering about this.
> This is just a generic name to base the actual mangling on tbh.
Can you clarify the comment then? I'd expect `MangledName` to be an actual 
mangling, otherwise, and that's why I was wondering "which mangling?".


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122215

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


[PATCH] D122215: [WebAssembly] Initial support for reference type externref in clang

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

Oops, it helps to actually accept it in Phab. :-D


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122215

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


[PATCH] D139926: [clangd] Add semantic token for angle brackets

2023-01-31 Thread Christian Kandeler via Phabricator via cfe-commits
ckandeler updated this revision to Diff 493594.
ckandeler marked an inline comment as done.
ckandeler added a comment.

Improved implementation as per review comment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139926

Files:
  clang-tools-extra/clangd/SemanticHighlighting.cpp
  clang-tools-extra/clangd/SemanticHighlighting.h
  clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp

Index: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
===
--- clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
+++ clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
@@ -130,17 +130,17 @@
 )cpp",
   R"cpp(
   namespace $Namespace_decl[[abc]] {
-template
+template$Bracket[[<]]typename $TemplateParameter_def[[T]]$Bracket[[>]]
 struct $Class_def[[A]] {
   $TemplateParameter[[T]] $Field_decl[[t]];
 };
   }
-  template
-  struct $Class_def[[C]] : $Namespace[[abc]]::$Class[[A]]<$TemplateParameter[[T]]> {
+  template$Bracket[[<]]typename $TemplateParameter_def[[T]]$Bracket[[>]]
+  struct $Class_def[[C]] : $Namespace[[abc]]::$Class[[A]]$Bracket[[<]]$TemplateParameter[[T]]$Bracket[[>]] {
 typename $TemplateParameter[[T]]::$Type_dependentName[[A]]* $Field_decl[[D]];
   };
-  $Namespace[[abc]]::$Class[[A]] $Variable_def[[AA]];
-  typedef $Namespace[[abc]]::$Class[[A]] $Class_decl[[AAA]];
+  $Namespace[[abc]]::$Class[[A]]$Bracket[[<]]int$Bracket[[>]] $Variable_def[[AA]];
+  typedef $Namespace[[abc]]::$Class[[A]]$Bracket[[<]]int$Bracket[[>]] $Class_decl[[AAA]];
   struct $Class_def[[B]] {
 $Class_decl_constrDestr[[B]]();
 ~$Class_decl_constrDestr[[B]]();
@@ -243,36 +243,36 @@
   typedef float $Primitive_decl[[F]];
 )cpp",
   R"cpp(
-  template
+  template$Bracket[[<]]typename $TemplateParameter_def[[T]], typename = void$Bracket[[>]]
   class $Class_def[[A]] {
 $TemplateParameter[[T]] $Field_decl[[AA]];
 $TemplateParameter[[T]] $Method_decl[[foo]]();
   };
-  template
+  template$Bracket[[<]]class $TemplateParameter_def[[TT]]$Bracket[[>]]
   class $Class_def[[B]] {
-$Class[[A]]<$TemplateParameter[[TT]]> $Field_decl[[AA]];
+$Class[[A]]$Bracket[[<]]$TemplateParameter[[TT]]$Bracket[[>]] $Field_decl[[AA]];
   };
-  template
+  template$Bracket[[<]]class $TemplateParameter_def[[TT]], class $TemplateParameter_def[[GG]]$Bracket[[>]]
   class $Class_def[[BB]] {};
-  template
-  class $Class_def[[BB]]<$TemplateParameter[[T]], int> {};
-  template
-  class $Class_def[[BB]]<$TemplateParameter[[T]], $TemplateParameter[[T]]*> {};
+  template$Bracket[[<]]class $TemplateParameter_def[[T]]$Bracket[[>]]
+  class $Class_def[[BB]]$Bracket[[<]]$TemplateParameter[[T]], int$Bracket[[>]] {};
+  template$Bracket[[<]]class $TemplateParameter_def[[T]]$Bracket[[>]]
+  class $Class_def[[BB]]$Bracket[[<]]$TemplateParameter[[T]], $TemplateParameter[[T]]*$Bracket[[>]] {};
 
-  template class $TemplateParameter_def[[T]], class $TemplateParameter_def[[C]]>
-  $TemplateParameter[[T]]<$TemplateParameter[[C]]> $Function_decl[[f]]();
+  template$Bracket[[<]]template$Bracket[[<]]class$Bracket[[>]] class $TemplateParameter_def[[T]], class $TemplateParameter_def[[C]]$Bracket[[>]]
+  $TemplateParameter[[T]]$Bracket[[<]]$TemplateParameter[[C]]$Bracket[[>]] $Function_decl[[f]]();
 
-  template
+  template$Bracket[[<]]typename$Bracket[[>]]
   class $Class_def[[Foo]] {};
 
-  template
+  template$Bracket[[<]]typename $TemplateParameter_def[[T]]$Bracket[[>]]
   void $Function_decl[[foo]]($TemplateParameter[[T]] ...);
 )cpp",
   R"cpp(
-  template 
+  template $Bracket[[<]]class $TemplateParameter_def[[T]]$Bracket[[>]]
   struct $Class_def[[Tmpl]] {$TemplateParameter[[T]] $Field_decl[[x]] = 0;};
-  extern template struct $Class_def[[Tmpl]];
-  template struct $Class_def[[Tmpl]];
+  extern template struct $Class_def[[Tmpl]]$Bracket[[<]]float$Bracket[[>]];
+  template struct $Class_def[[Tmpl]]$Bracket[[<]]double$Bracket[[>]];
 )cpp",
   // This test is to guard against highlightings disappearing when using
   // conversion operators as their behaviour in the clang AST differ from
@@ -335,17 +335,17 @@
 )cpp",
   R"cpp(
   class $Class_def[[G]] {};
-  template<$Class[[G]] *$TemplateParameter_def_readonly[[U]]>
+  template$Bracket[[<]]$Class[[G]] *$TemplateParameter_def_readonly[[U]]$Bracket[[>]]
   class $Class_def[[GP]] {};
-  template<$Class[[G]] &$TemplateParameter_def_readonly[[U]]>
+  template$Bracket[[<]]$Class[[G]] &$TemplateParameter_def_readonly[[U]]$Bracket[[>]]
   class $Class_def[[GR]] {};
-  template
+  t

[PATCH] D139926: [clangd] Add semantic token for angle brackets

2023-01-31 Thread Christian Kandeler via Phabricator via cfe-commits
ckandeler added inline comments.



Comment at: clang-tools-extra/clangd/SemanticHighlighting.cpp:382
+
+// For the inner element of a nested template instantiation with no space
+// between the '>' characters, TemplateSpecializationLocInfo::RAngleLoc has

kadircet wrote:
> i am actually having a hard time following the logic here. it feels like what 
> you really want is map `>` back to its file location, possibly to a `>>` 
> token, and deal with second case specially.
> so maybe something like:
> ```
> // RLoc might be pointing at a virtual buffer when it's part of a `>>` token.
> RLoc = SM.getFileLoc(RLoc);
> // Make sure token is part of the main file.
> RLoc = getHighlightableSpellingToken(RLoc);
> if(!RLoc.isValid())
>   return;
> 
> const auto *RTok = TB.spelledTokenAt(RLoc);
> // Handle `>>`. RLoc is always pointing at the right location, just change
> // the end to be offset by 1.
> // We'll either point at the beginning of `>>`, hence get a proper spelled
> // or point in the middle of `>>` hence get no spelled tok.
> if (!RTok || RTok->kind() == tok::greatergreater) {
>   Position Begin = sourceLocToPosition(SourceMgr, RLoc);
>   Position End = sourceLocToPosition(SourceMgr, RLoc.getLocWithOffset(1));
>   addToken(*LRange, HighlightingKind::Bracket);
>   addToken({Begin, End}, HighlightingKind::Bracket);
>   return;
> }
> 
> // Easy case, we have the `>` token directly available.
> if (RTok->kind() == tok::greater) {
>   if (auto RRange = getRangeForSourceLocation(RLoc)) {
> addToken(*LRange, HighlightingKind::Bracket);
> addToken(*RRange, HighlightingKind::Bracket);
>   }
>   return;
> }
> ```
> 
> This should also make sure you're handling line continuations properly.
Indeed, thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139926

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


[PATCH] D142981: [clangd] Support include paths relative to .clangd config file

2023-01-31 Thread Frederik Magnus Johansen Vestre via Phabricator via cfe-commits
freqmod created this revision.
Herald added subscribers: kadircet, arphaman.
Herald added a project: All.
freqmod requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay, ilya-biryukov.
Herald added a project: clang-tools-extra.

This addresses the use case in https://github.com/clangd/clangd/issues/1038 
where 
a user wants to make a .clangd file that is applicable for several 
subdirectories with
relative paths to the .clangd file (instead of the individual c-files). It does 
this by 
replacing any occurrances of ${CURRENT_FILE_PATH} with the directory of the 
.clangd file.

The syntax for the text to be replaced is up for discussion.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D142981

Files:
  clang-tools-extra/clangd/ConfigFragment.h
  clang-tools-extra/clangd/ConfigProvider.cpp
  clang-tools-extra/clangd/ConfigYAML.cpp
  clang-tools-extra/clangd/unittests/ConfigYAMLTests.cpp

Index: clang-tools-extra/clangd/unittests/ConfigYAMLTests.cpp
===
--- clang-tools-extra/clangd/unittests/ConfigYAMLTests.cpp
+++ clang-tools-extra/clangd/unittests/ConfigYAMLTests.cpp
@@ -70,7 +70,7 @@
   example-check.ExampleOption: 0
   UnusedIncludes: Strict
   )yaml";
-  auto Results = Fragment::parseYAML(YAML, "config.yaml", Diags.callback());
+  auto Results = Fragment::parseYAML(YAML, "config.yaml", "", Diags.callback());
   EXPECT_THAT(Diags.Diagnostics, IsEmpty());
   EXPECT_THAT(Diags.Files, ElementsAre("config.yaml"));
   ASSERT_EQ(Results.size(), 4u);
@@ -89,6 +89,22 @@
   EXPECT_EQ("Strict", **Results[3].Diagnostics.UnusedIncludes);
 }
 
+TEST(ParseYAML, IncludesFileRelative) {
+  CapturedDiags Diags;
+  /* Annotations cannot be used here as it interprets the $ and {} special
+   * characters */
+  StringRef RawYAML(R"yaml(
+  CompileFlags:
+Add: ["-I${CURRENT_FILE_PATH}test.h"]
+  )yaml");
+  auto Results = Fragment::parseYAML(RawYAML, "config.yaml", "/tmp/testpath/",
+ Diags.callback());
+  ASSERT_THAT(Diags.Diagnostics, IsEmpty());
+  ASSERT_EQ(Results.size(), 1u);
+  EXPECT_THAT(Results[0].CompileFlags.Add,
+  ElementsAre(val("-I/tmp/testpath/test.h")));
+}
+
 TEST(ParseYAML, Locations) {
   CapturedDiags Diags;
   Annotations YAML(R"yaml(
@@ -96,7 +112,7 @@
   PathMatch: [['???bad***regex(((']]
   )yaml");
   auto Results =
-  Fragment::parseYAML(YAML.code(), "config.yaml", Diags.callback());
+  Fragment::parseYAML(YAML.code(), "config.yaml", "", Diags.callback());
   EXPECT_THAT(Diags.Diagnostics, IsEmpty());
   ASSERT_EQ(Results.size(), 1u);
   ASSERT_NE(Results.front().Source.Manager, nullptr);
@@ -116,7 +132,7 @@
 CompileFlags: {$unexpected^
 )yaml");
   auto Results =
-  Fragment::parseYAML(YAML.code(), "config.yaml", Diags.callback());
+  Fragment::parseYAML(YAML.code(), "config.yaml", "", Diags.callback());
 
   ASSERT_THAT(
   Diags.Diagnostics,
@@ -144,7 +160,7 @@
 ---
 - 1
   )yaml";
-  auto Results = Fragment::parseYAML(YAML, "config.yaml", Diags.callback());
+  auto Results = Fragment::parseYAML(YAML, "config.yaml", "", Diags.callback());
   EXPECT_THAT(Diags.Diagnostics,
   ElementsAre(diagMessage("If should be a dictionary"),
   diagMessage("Config should be a dictionary")));
@@ -158,7 +174,7 @@
   External: None
   )yaml");
   auto Results =
-  Fragment::parseYAML(YAML.code(), "config.yaml", Diags.callback());
+  Fragment::parseYAML(YAML.code(), "config.yaml", "", Diags.callback());
   ASSERT_THAT(Diags.Diagnostics, IsEmpty());
   ASSERT_EQ(Results.size(), 1u);
   ASSERT_TRUE(Results[0].Index.External);
@@ -178,7 +194,7 @@
 MountPoint: "baz"
   )yaml");
   auto Results =
-  Fragment::parseYAML(YAML.code(), "config.yaml", Diags.callback());
+  Fragment::parseYAML(YAML.code(), "config.yaml", "", Diags.callback());
   ASSERT_EQ(Results.size(), 1u);
   ASSERT_TRUE(Results[0].Index.External);
   EXPECT_THAT(*(*Results[0].Index.External)->File, val("foo"));
@@ -194,7 +210,7 @@
   AllScopes: True
   )yaml");
   auto Results =
-  Fragment::parseYAML(YAML.code(), "config.yaml", Diags.callback());
+  Fragment::parseYAML(YAML.code(), "config.yaml", "", Diags.callback());
   ASSERT_THAT(Diags.Diagnostics, IsEmpty());
   ASSERT_EQ(Results.size(), 1u);
   EXPECT_THAT(Results[0].Completion.AllScopes, llvm::ValueIs(val(true)));
@@ -207,7 +223,7 @@
   AllScopes: $diagrange[[Truex]]
   )yaml");
   auto Results =
-  Fragment::parseYAML(YAML.code(), "config.yaml", Diags.callback());
+  Fragment::parseYAML(YAML.code(), "config.yaml", "", Diags.callback());
   EXPECT_THAT(Diags.Diagnostics,
   ElementsAre(AllOf(diagMessage("AllScopes should be a boolean"),
 diagKind(llvm::SourceMgr::DK_Warning),
@@ -224,7 +240,7 @@
   ShowAKA: True
   )yaml");
   auto Results =
-  Fragment::parseYAML(YAML.code(), "config.yaml", Diag

[clang] ab0116e - [Clang] Improve error message for violations of -fmodules-decluse.

2023-01-31 Thread James Y Knight via cfe-commits

Author: James Y Knight
Date: 2023-01-31T09:57:23-05:00
New Revision: ab0116e2f05c6156c4bc3d35986de1e98cc27016

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

LOG: [Clang] Improve error message for violations of -fmodules-decluse.

Now it reports the name of the indirectly-used module which is
missing.

Reviewed By: ChuanqiXu

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

Added: 


Modified: 
clang/include/clang/Basic/DiagnosticLexKinds.td
clang/lib/Lex/ModuleMap.cpp
clang/test/Modules/Inputs/declare-use/h.h
clang/test/Modules/declare-use-textual.cpp
clang/test/Modules/declare-use1.cpp
clang/test/Modules/declare-use2.cpp
clang/test/Modules/declare-use3.cpp
clang/test/Modules/strict-decluse.cpp
clang/test/Modules/string_names.cpp
clang/test/Modules/textual-headers.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/DiagnosticLexKinds.td 
b/clang/include/clang/Basic/DiagnosticLexKinds.td
index 3b1b466e7602b..0fb8d196dd6a5 100644
--- a/clang/include/clang/Basic/DiagnosticLexKinds.td
+++ b/clang/include/clang/Basic/DiagnosticLexKinds.td
@@ -888,6 +888,8 @@ def warn_use_of_private_header_outside_module : Warning<
   InGroup>, DefaultError;
 def err_undeclared_use_of_module : Error<
   "module %0 does not depend on a module exporting '%1'">;
+def err_undeclared_use_of_module_indirect : Error<
+  "module %0 does not directly depend on a module exporting '%1', which is 
part of indirectly-used module %2">;
 def warn_non_modular_include_in_framework_module : Warning<
   "include of non-modular header inside framework module '%0': '%1'">,
   InGroup, DefaultIgnore;

diff  --git a/clang/lib/Lex/ModuleMap.cpp b/clang/lib/Lex/ModuleMap.cpp
index ee2cca4e0814e..15f4377541b48 100644
--- a/clang/lib/Lex/ModuleMap.cpp
+++ b/clang/lib/Lex/ModuleMap.cpp
@@ -528,8 +528,9 @@ void ModuleMap::diagnoseHeaderInclusion(Module 
*RequestingModule,
 
   // We have found a module, but we don't use it.
   if (NotUsed) {
-Diags.Report(FilenameLoc, diag::err_undeclared_use_of_module)
-<< RequestingModule->getTopLevelModule()->Name << Filename;
+Diags.Report(FilenameLoc, diag::err_undeclared_use_of_module_indirect)
+<< RequestingModule->getTopLevelModule()->Name << Filename
+<< NotUsed->Name;
 return;
   }
 

diff  --git a/clang/test/Modules/Inputs/declare-use/h.h 
b/clang/test/Modules/Inputs/declare-use/h.h
index 8984727c565e7..4f63ec24cf8e9 100644
--- a/clang/test/Modules/Inputs/declare-use/h.h
+++ b/clang/test/Modules/Inputs/declare-use/h.h
@@ -1,7 +1,7 @@
 #ifndef H_H
 #define H_H
 #include "c.h"
-#include "d.h" // expected-error {{module XH does not depend on a module 
exporting}}
+#include "d.h" // expected-error {{module XH does not directly depend on a 
module exporting 'd.h', which is part of indirectly-used module XD}}
 #include "h1.h"
 const int h1 = aux_h*c*7*d;
 #endif

diff  --git a/clang/test/Modules/declare-use-textual.cpp 
b/clang/test/Modules/declare-use-textual.cpp
index 0cb8c4b18275c..a8b01702794f7 100644
--- a/clang/test/Modules/declare-use-textual.cpp
+++ b/clang/test/Modules/declare-use-textual.cpp
@@ -2,5 +2,5 @@
 // RUN: %clang_cc1 -fimplicit-module-maps -fmodules-cache-path=%t 
-fmodules-decluse -fmodule-name=Textual -I %S/Inputs/declare-use %s -verify
 // RUN: %clang_cc1 -fimplicit-module-maps -fmodules-cache-path=%t 
-fmodules-decluse -fmodule-name=Textual -I %S/Inputs/declare-use %s 
-fno-modules-validate-textual-header-includes
 
-// expected-error@textual.h:* {{module Textual does not depend on a module 
exporting 'a.h'}}
+// expected-error@textual.h:* {{module Textual does not directly depend on a 
module exporting 'a.h', which is part of indirectly-used module XA}}
 #include "textual.h"

diff  --git a/clang/test/Modules/declare-use1.cpp 
b/clang/test/Modules/declare-use1.cpp
index 58eb317afc09b..0c8a01be36e4f 100644
--- a/clang/test/Modules/declare-use1.cpp
+++ b/clang/test/Modules/declare-use1.cpp
@@ -6,7 +6,7 @@
 
 #include "g.h"
 #include "e.h"
-#include "f.h" // expected-error {{module XG does not depend on a module 
exporting 'f.h'}}
+#include "f.h" // expected-error {{module XG does not directly depend on a 
module exporting 'f.h', which is part of indirectly-used module XF}}
 #include "i.h"
 #include "sub.h"
 const int g2 = g1 + e + f + aux_i + sub;

diff  --git a/clang/test/Modules/declare-use2.cpp 
b/clang/test/Modules/declare-use2.cpp
index 12689e9d9683e..1999224fcfa06 100644
--- a/clang/test/Modules/declare-use2.cpp
+++ b/clang/test/Modules/declare-use2.cpp
@@ -3,5 +3,5 @@
 
 #include "h.h"
 #include "e.h"
-#include "f.h" // expected-error {{module XH does not depend on a module 
exporting 'f.h'}}
+#include "f.h" // expected-error {{module XH does not directly depend on a 
modul

[PATCH] D142925: [Clang] Improve error message for violations of -fmodules-decluse.

2023-01-31 Thread James Y Knight 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 rGab0116e2f05c: [Clang] Improve error message for violations 
of -fmodules-decluse. (authored by jyknight).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142925

Files:
  clang/include/clang/Basic/DiagnosticLexKinds.td
  clang/lib/Lex/ModuleMap.cpp
  clang/test/Modules/Inputs/declare-use/h.h
  clang/test/Modules/declare-use-textual.cpp
  clang/test/Modules/declare-use1.cpp
  clang/test/Modules/declare-use2.cpp
  clang/test/Modules/declare-use3.cpp
  clang/test/Modules/strict-decluse.cpp
  clang/test/Modules/string_names.cpp
  clang/test/Modules/textual-headers.cpp

Index: clang/test/Modules/textual-headers.cpp
===
--- clang/test/Modules/textual-headers.cpp
+++ clang/test/Modules/textual-headers.cpp
@@ -6,9 +6,9 @@
 #include "k.h"
 
 #define GIMME_AN_L
-#include "l.h" // expected-error {{module XG does not depend on a module exporting 'l.h'}}
+#include "l.h" // expected-error {{module XG does not directly depend on a module exporting 'l.h', which is part of indirectly-used module XL}}
 
-#include "m2.h" // expected-error {{module XG does not depend on a module exporting 'm2.h'}}
+#include "m2.h" // expected-error {{module XG does not directly depend on a module exporting 'm2.h', which is part of indirectly-used module XM}}
 const int use_m = m; // expected-error {{undeclared identifier}}
 
 #define GIMME_AN_M
Index: clang/test/Modules/string_names.cpp
===
--- clang/test/Modules/string_names.cpp
+++ clang/test/Modules/string_names.cpp
@@ -6,5 +6,5 @@
 // RUN: %clang_cc1 -fmodules -fimplicit-module-maps -fmodules-decluse -I %S/Inputs/string_names %t/test.ii -fmodule-name="my/module-a"
 
 #include "a.h"
-#include "b.h" // expected-error {{does not depend on a module exporting}}
+#include "b.h" // expected-error {{module my/module-a does not directly depend on a module exporting 'b.h', which is part of indirectly-used module my/module-b}}
 #include "c.h"
Index: clang/test/Modules/strict-decluse.cpp
===
--- clang/test/Modules/strict-decluse.cpp
+++ clang/test/Modules/strict-decluse.cpp
@@ -3,7 +3,7 @@
 
 #include "g.h"
 #include "e.h"
-#include "f.h" // expected-error {{module XG does not depend on a module exporting 'f.h'}}
+#include "f.h" // expected-error {{module XG does not directly depend on a module exporting 'f.h', which is part of indirectly-used module XF}}
 #include "i.h" // expected-error {{module XG does not depend on a module exporting 'i.h'}}
 
 const int g2 = g1 + e + f + aux_i;
Index: clang/test/Modules/declare-use3.cpp
===
--- clang/test/Modules/declare-use3.cpp
+++ clang/test/Modules/declare-use3.cpp
@@ -1,4 +1,4 @@
 // RUN: rm -rf %t
 // RUN: %clang_cc1 -include "g.h" -include "e.h" -include "f.h" -include "i.h" -fimplicit-module-maps -fmodules-cache-path=%t -fmodules-decluse -fmodule-name=XG -I %S/Inputs/declare-use %s -verify
-// expected-error {{module XG does not depend on a module exporting 'f.h'}}
+// expected-error {{module XG does not directly depend on a module exporting 'f.h', which is part of indirectly-used module XF}}
 const int g2 = g1 + e + f + aux_i;
Index: clang/test/Modules/declare-use2.cpp
===
--- clang/test/Modules/declare-use2.cpp
+++ clang/test/Modules/declare-use2.cpp
@@ -3,5 +3,5 @@
 
 #include "h.h"
 #include "e.h"
-#include "f.h" // expected-error {{module XH does not depend on a module exporting 'f.h'}}
+#include "f.h" // expected-error {{module XH does not directly depend on a module exporting 'f.h', which is part of indirectly-used module XF}}
 const int h2 = h1+e+f;
Index: clang/test/Modules/declare-use1.cpp
===
--- clang/test/Modules/declare-use1.cpp
+++ clang/test/Modules/declare-use1.cpp
@@ -6,7 +6,7 @@
 
 #include "g.h"
 #include "e.h"
-#include "f.h" // expected-error {{module XG does not depend on a module exporting 'f.h'}}
+#include "f.h" // expected-error {{module XG does not directly depend on a module exporting 'f.h', which is part of indirectly-used module XF}}
 #include "i.h"
 #include "sub.h"
 const int g2 = g1 + e + f + aux_i + sub;
Index: clang/test/Modules/declare-use-textual.cpp
===
--- clang/test/Modules/declare-use-textual.cpp
+++ clang/test/Modules/declare-use-textual.cpp
@@ -2,5 +2,5 @@
 // RUN: %clang_cc1 -fimplicit-module-maps -fmodules-cache-path=%t -fmodules-decluse -fmodule-name=Textual -I %S/Inputs/declare-use %s -verify
 // RUN: %clang_cc1 -fimplicit-module-maps -fmo

[PATCH] D142800: [Clang][Diagnostic] Add `-Wcomparison-op-parentheses` to warn on chained comparisons

2023-01-31 Thread Takuya Shimizu via Phabricator via cfe-commits
hazohelet added inline comments.



Comment at: clang/lib/Sema/SemaExpr.cpp:15548
+
+  SuggestParentheses(Self, Bop->getOperatorLoc(),
+ Self.PDiag(diag::note_precedence_silence)

erichkeane wrote:
> I find myself wondering if we could provide a better 'suggested fix' here.  
> Aaron is better with the diagnostics than I am, but I would think that 
> someone doing:
> 
> `a < b < c` PROBABLY doesn't mean that, they probably mean: `a < b && b < c`.
> 
> Also, is the mistake the 'same' when they do something like `a > b != c` ?  
> It would seem to me that mixing operators might make it something either more 
> intentional/meaningful.  ADDITIONALLY, in the case where they are booleans, 
> these end up being overly noisy.  The pattern of the  == c (where 'c' is 
> bool, or convertible to bool) is probably intentional.
> 
> I think the logic here needs to be more complicated than just "Comparison 
> within Comparison", however I don't have a fully formed idea of when to 
> diagnose.
> 
> @tahonermann : Do you perhaps have a good idea?
> I find myself wondering if we could provide a better 'suggested fix' here.  
> Aaron is better with the diagnostics than I am, but I would think that 
> someone doing:
> 
> `a < b < c` PROBABLY doesn't mean that, they probably mean: `a < b && b < c`.

Yes. We could provide a better fix-it hint.
My idea:
- In the case of chained relational operators (`<`, `>`, `<=`, `>=`), clang 
suggests adding `&&`.
- In other cases, clang suggests parentheses.
How about doing it this way? It's similar to how Rust handles chained 
comparisons.

> Also, is the mistake the 'same' when they do something like `a > b != c` ?  
> It would seem to me that mixing operators might make it something either more 
> intentional/meaningful.  ADDITIONALLY, in the case where they are booleans, 
> these end up being overly noisy.  The pattern of the  == c (where 'c' is 
> bool, or convertible to bool) is probably intentional.
> 
> I think the logic here needs to be more complicated than just "Comparison 
> within Comparison", however I don't have a fully formed idea of when to 
> diagnose.

I have a differing perspective on suppressing the warning for boolean and 
boolean-convertible values.
There are two possible programmer mistakes in chained comparisons.
1. `a > b != c` misunderstood as `a > b && b != c`
2. `a > b != c` misunderstood as `a > (b != c)`
While the latter is considered rare in this scenario, the former could be 
likely to happen due to other languages, such as Python handling chained 
comparisons in the former manner.




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

https://reviews.llvm.org/D142800

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


[PATCH] D142907: LangRef: Add "dynamic" option to "denormal-fp-math"

2023-01-31 Thread Matt Arsenault via Phabricator via cfe-commits
arsenm marked 2 inline comments as done.
arsenm added inline comments.



Comment at: clang/lib/CodeGen/CGCall.cpp:2059-2061
+  F.removeFnAttrs(AttrsToRemove);
+  addDenormalModeAttrs(Merged, MergedF32, FuncAttrs);
+  F.addFnAttrs(FuncAttrs);

tra wrote:
> IIUIC, this changes denorm mode attributes on the functions with dynamic 
> denorm mode that we link in.
> Will that be a problem if the same function, when linked into different 
> modules, would end up with different attributes? E.g. if a function is 
> externally visible and is intended to be common'ed across multiple modules. 
> Should dynamic denorm mode be restricted to the functions private to the 
> module only? We do typically internalize linked bitcode for CUDA, but I don't 
> think it's something we can always implicitly assume.
> 
The whole point of -mlink-builtin-bitcode is to apply the attributes for the 
current compilation to what's linked in. The linked functions are always 
internalized. The only case where we might not want to internalize is for weak 
symbols (but it looks like we do internalize those today, but this is something 
I've thought about changing). I'll add a test with a weak library function

In the weak case the right thing to do is probably to not change from dynamic, 
simply because this linking process is outside of the user's control.





Comment at: clang/test/CodeGenCUDA/link-builtin-bitcode-denormal-fp-mode.cu:15
+// RUN:   %S/Inputs/ocml-sample.cl -o %t.dynamic.full.bc
+
+

tra wrote:
> Do we want to verify that the compiled samples have the correct function 
> attributes?
Maybe, but that's already tested separately. This test is a bit complex as it 
is (and could maybe use a few more combinations)



Comment at: clang/test/CodeGenCUDA/link-builtin-bitcode-denormal-fp-mode.cu:77
+
+// CHECK: kernel_f32({{.*}}) #[[$KERNELATTR:[0-9]+]]
+__global__ void kernel_f32(float* out, float* a, float* b, float* c) {

tra wrote:
> Nit: CHECK-LABEL ?
 error: found 'CHECK-LABEL:' with variable definition or use




Comment at: clang/test/CodeGenCUDA/link-builtin-bitcode-denormal-fp-mode.cu:94
+// We should not be littering call sites with the attribute
+// CHECK-NOT: denormal-fp-math
+

tra wrote:
> I'm not sure whether it does what it's intended to. 
> AFAICT, at this point we will be past the call sites, so if it's intended to 
> check the call sites in kernel_*, it will likely always succeed, even if we 
> do litter call sites with unwanted attributes.
> 
> It's also possible that I have a wrong idea about what the expected IR looks 
> like. If you could post it for reference, that would be helpful.
I can drop this, I later added the -implicit-check-not=denormal-fp-math to all 
the FileChecks


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

https://reviews.llvm.org/D142907

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


[PATCH] D142800: [Clang][Diagnostic] Add `-Wcomparison-op-parentheses` to warn on chained comparisons

2023-01-31 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added inline comments.



Comment at: clang/lib/Sema/SemaExpr.cpp:15548
+
+  SuggestParentheses(Self, Bop->getOperatorLoc(),
+ Self.PDiag(diag::note_precedence_silence)

hazohelet wrote:
> erichkeane wrote:
> > I find myself wondering if we could provide a better 'suggested fix' here.  
> > Aaron is better with the diagnostics than I am, but I would think that 
> > someone doing:
> > 
> > `a < b < c` PROBABLY doesn't mean that, they probably mean: `a < b && b < 
> > c`.
> > 
> > Also, is the mistake the 'same' when they do something like `a > b != c` ?  
> > It would seem to me that mixing operators might make it something either 
> > more intentional/meaningful.  ADDITIONALLY, in the case where they are 
> > booleans, these end up being overly noisy.  The pattern of the  == c (where 
> > 'c' is bool, or convertible to bool) is probably intentional.
> > 
> > I think the logic here needs to be more complicated than just "Comparison 
> > within Comparison", however I don't have a fully formed idea of when to 
> > diagnose.
> > 
> > @tahonermann : Do you perhaps have a good idea?
> > I find myself wondering if we could provide a better 'suggested fix' here.  
> > Aaron is better with the diagnostics than I am, but I would think that 
> > someone doing:
> > 
> > `a < b < c` PROBABLY doesn't mean that, they probably mean: `a < b && b < 
> > c`.
> 
> Yes. We could provide a better fix-it hint.
> My idea:
> - In the case of chained relational operators (`<`, `>`, `<=`, `>=`), clang 
> suggests adding `&&`.
> - In other cases, clang suggests parentheses.
> How about doing it this way? It's similar to how Rust handles chained 
> comparisons.
> 
> > Also, is the mistake the 'same' when they do something like `a > b != c` ?  
> > It would seem to me that mixing operators might make it something either 
> > more intentional/meaningful.  ADDITIONALLY, in the case where they are 
> > booleans, these end up being overly noisy.  The pattern of the  == c (where 
> > 'c' is bool, or convertible to bool) is probably intentional.
> > 
> > I think the logic here needs to be more complicated than just "Comparison 
> > within Comparison", however I don't have a fully formed idea of when to 
> > diagnose.
> 
> I have a differing perspective on suppressing the warning for boolean and 
> boolean-convertible values.
> There are two possible programmer mistakes in chained comparisons.
> 1. `a > b != c` misunderstood as `a > b && b != c`
> 2. `a > b != c` misunderstood as `a > (b != c)`
> While the latter is considered rare in this scenario, the former could be 
> likely to happen due to other languages, such as Python handling chained 
> comparisons in the former manner.
> 
> 
I'd be interested to see the fixit-hints for the first bit, also to see how 
others feel about it here.


IMO, `a > b != c` to mean `(a > b) != c` is a reasonably common pattern I 
suspect we won't want to be noisy on.


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

https://reviews.llvm.org/D142800

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


[clang] be31f2c - [clang-format][NFC] Move IndexedTokenSource to FormatTokenSource header.

2023-01-31 Thread Manuel Klimek via cfe-commits

Author: Manuel Klimek
Date: 2023-01-31T15:06:20Z
New Revision: be31f2c11d47d3eca28d922a06de181d6e23b355

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

LOG: [clang-format][NFC] Move IndexedTokenSource to FormatTokenSource header.

Finish refactoring of the token sources towards a single location.

Added: 


Modified: 
clang/lib/Format/FormatTokenSource.h
clang/lib/Format/UnwrappedLineParser.cpp

Removed: 




diff  --git a/clang/lib/Format/FormatTokenSource.h 
b/clang/lib/Format/FormatTokenSource.h
index 11c735d36864..e14f72b7d1f4 100644
--- a/clang/lib/Format/FormatTokenSource.h
+++ b/clang/lib/Format/FormatTokenSource.h
@@ -52,6 +52,71 @@ class FormatTokenSource {
   virtual FormatToken *setPosition(unsigned Position) = 0;
 };
 
+class IndexedTokenSource : public FormatTokenSource {
+public:
+  IndexedTokenSource(ArrayRef Tokens)
+  : Tokens(Tokens), Position(-1) {}
+
+  FormatToken *getNextToken() override {
+if (Position >= 0 && isEOF()) {
+  LLVM_DEBUG({
+llvm::dbgs() << "Next ";
+dbgToken(Position);
+  });
+  return Tokens[Position];
+}
+++Position;
+LLVM_DEBUG({
+  llvm::dbgs() << "Next ";
+  dbgToken(Position);
+});
+return Tokens[Position];
+  }
+
+  FormatToken *getPreviousToken() override {
+return Position > 0 ? Tokens[Position - 1] : nullptr;
+  }
+
+  FormatToken *peekNextToken(bool SkipComment) override {
+int Next = Position + 1;
+if (SkipComment)
+  while (Tokens[Next]->is(tok::comment))
+++Next;
+LLVM_DEBUG({
+  llvm::dbgs() << "Peeking ";
+  dbgToken(Next);
+});
+return Tokens[Next];
+  }
+
+  bool isEOF() override { return Tokens[Position]->is(tok::eof); }
+
+  unsigned getPosition() override {
+LLVM_DEBUG(llvm::dbgs() << "Getting Position: " << Position << "\n");
+assert(Position >= 0);
+return Position;
+  }
+
+  FormatToken *setPosition(unsigned P) override {
+LLVM_DEBUG(llvm::dbgs() << "Setting Position: " << P << "\n");
+Position = P;
+return Tokens[Position];
+  }
+
+  void reset() { Position = -1; }
+
+private:
+  void dbgToken(int Position, llvm::StringRef Indent = "") {
+FormatToken *Tok = Tokens[Position];
+llvm::dbgs() << Indent << "[" << Position
+ << "] Token: " << Tok->Tok.getName() << " / " << 
Tok->TokenText
+ << ", Macro: " << !!Tok->MacroCtx << "\n";
+  }
+
+  ArrayRef Tokens;
+  int Position;
+};
+
 class ScopedMacroState : public FormatTokenSource {
 public:
   ScopedMacroState(UnwrappedLine &Line, FormatTokenSource *&TokenSource,

diff  --git a/clang/lib/Format/UnwrappedLineParser.cpp 
b/clang/lib/Format/UnwrappedLineParser.cpp
index 9d90e5390bb8..c211c0ceb067 100644
--- a/clang/lib/Format/UnwrappedLineParser.cpp
+++ b/clang/lib/Format/UnwrappedLineParser.cpp
@@ -143,75 +143,6 @@ class CompoundStatementIndenter {
   unsigned OldLineLevel;
 };
 
-namespace {
-
-class IndexedTokenSource : public FormatTokenSource {
-public:
-  IndexedTokenSource(ArrayRef Tokens)
-  : Tokens(Tokens), Position(-1) {}
-
-  FormatToken *getNextToken() override {
-if (Position >= 0 && isEOF()) {
-  LLVM_DEBUG({
-llvm::dbgs() << "Next ";
-dbgToken(Position);
-  });
-  return Tokens[Position];
-}
-++Position;
-LLVM_DEBUG({
-  llvm::dbgs() << "Next ";
-  dbgToken(Position);
-});
-return Tokens[Position];
-  }
-
-  FormatToken *getPreviousToken() override {
-return Position > 0 ? Tokens[Position - 1] : nullptr;
-  }
-
-  FormatToken *peekNextToken(bool SkipComment) override {
-int Next = Position + 1;
-if (SkipComment)
-  while (Tokens[Next]->is(tok::comment))
-++Next;
-LLVM_DEBUG({
-  llvm::dbgs() << "Peeking ";
-  dbgToken(Next);
-});
-return Tokens[Next];
-  }
-
-  bool isEOF() override { return Tokens[Position]->is(tok::eof); }
-
-  unsigned getPosition() override {
-LLVM_DEBUG(llvm::dbgs() << "Getting Position: " << Position << "\n");
-assert(Position >= 0);
-return Position;
-  }
-
-  FormatToken *setPosition(unsigned P) override {
-LLVM_DEBUG(llvm::dbgs() << "Setting Position: " << P << "\n");
-Position = P;
-return Tokens[Position];
-  }
-
-  void reset() { Position = -1; }
-
-private:
-  void dbgToken(int Position, llvm::StringRef Indent = "") {
-FormatToken *Tok = Tokens[Position];
-llvm::dbgs() << Indent << "[" << Position
- << "] Token: " << Tok->Tok.getName() << " / " << 
Tok->TokenText
- << ", Macro: " << !!Tok->MacroCtx << "\n";
-  }
-
-  ArrayRef Tokens;
-  int Position;
-};
-
-} // end anonymous namespace
-
 UnwrappedLineParser::UnwrappedLineParser(const FormatStyle &Style,
   

[clang] 20f3ebd - [clang][CGCall] Remove header file not used. [NFCI]

2023-01-31 Thread Francesco Petrogalli via cfe-commits

Author: Francesco Petrogalli
Date: 2023-01-31T16:12:46+01:00
New Revision: 20f3ebd258851e801cb5c2baf92e895c72695858

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

LOG: [clang][CGCall] Remove header file not used. [NFCI]

Reviewed By: fpetrogalli

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

Added: 


Modified: 
clang/lib/CodeGen/CGCall.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGCall.cpp b/clang/lib/CodeGen/CGCall.cpp
index dfa552161d7ca..9518017c403d3 100644
--- a/clang/lib/CodeGen/CGCall.cpp
+++ b/clang/lib/CodeGen/CGCall.cpp
@@ -25,7 +25,6 @@
 #include "clang/AST/DeclCXX.h"
 #include "clang/AST/DeclObjC.h"
 #include "clang/Basic/CodeGenOptions.h"
-#include "clang/Basic/TargetBuiltins.h"
 #include "clang/Basic/TargetInfo.h"
 #include "clang/CodeGen/CGFunctionInfo.h"
 #include "clang/CodeGen/SwiftCallingConv.h"



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


[PATCH] D142976: [clang][CGCall] Remove header file not used. [NFCI]

2023-01-31 Thread Francesco Petrogalli 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 rG20f3ebd25885: [clang][CGCall] Remove header file not used. 
[NFCI] (authored by fpetrogalli).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142976

Files:
  clang/lib/CodeGen/CGCall.cpp


Index: clang/lib/CodeGen/CGCall.cpp
===
--- clang/lib/CodeGen/CGCall.cpp
+++ clang/lib/CodeGen/CGCall.cpp
@@ -25,7 +25,6 @@
 #include "clang/AST/DeclCXX.h"
 #include "clang/AST/DeclObjC.h"
 #include "clang/Basic/CodeGenOptions.h"
-#include "clang/Basic/TargetBuiltins.h"
 #include "clang/Basic/TargetInfo.h"
 #include "clang/CodeGen/CGFunctionInfo.h"
 #include "clang/CodeGen/SwiftCallingConv.h"


Index: clang/lib/CodeGen/CGCall.cpp
===
--- clang/lib/CodeGen/CGCall.cpp
+++ clang/lib/CodeGen/CGCall.cpp
@@ -25,7 +25,6 @@
 #include "clang/AST/DeclCXX.h"
 #include "clang/AST/DeclObjC.h"
 #include "clang/Basic/CodeGenOptions.h"
-#include "clang/Basic/TargetBuiltins.h"
 #include "clang/Basic/TargetInfo.h"
 #include "clang/CodeGen/CGFunctionInfo.h"
 #include "clang/CodeGen/SwiftCallingConv.h"
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D141858: [clang][Interp] Fix Pointer::toAPValue() for expressions

2023-01-31 Thread Timm Bäder via Phabricator via cfe-commits
tbaeder added a comment.

It's a bit involved since without working `MaterializeTemporaryExpr`s, this 
code is a no-op, but without this code, the MTEs don't properly work, usually.


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

https://reviews.llvm.org/D141858

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


[PATCH] D139926: [clangd] Add semantic token for angle brackets

2023-01-31 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet accepted this revision.
kadircet added a comment.
This revision is now accepted and ready to land.

In D139926#4091990 , @nridge wrote:

> but it sounds like you've looked at that

well i did now :P

---

thanks a lot to you both, let's ship it!




Comment at: clang-tools-extra/clangd/SemanticHighlighting.cpp:408
+addToken(*RRange, HighlightingKind::Bracket);
+  }
+}

nit: i'd actually keep the `return;` here to make sure we don't fall into 
handling of other cases implicitly in the future.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139926

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


[PATCH] D142934: clang: Use ptrmask for pointer alignment

2023-01-31 Thread Florian Hahn via Phabricator via cfe-commits
fhahn added a comment.

Using `ptrmask` here looks good to me, but it looks like a couple of tests need 
still updating;


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

https://reviews.llvm.org/D142934

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


[PATCH] D142907: LangRef: Add "dynamic" option to "denormal-fp-math"

2023-01-31 Thread Matt Arsenault via Phabricator via cfe-commits
arsenm marked an inline comment as done.
arsenm added inline comments.



Comment at: clang/lib/CodeGen/CGCall.cpp:2059-2061
+  F.removeFnAttrs(AttrsToRemove);
+  addDenormalModeAttrs(Merged, MergedF32, FuncAttrs);
+  F.addFnAttrs(FuncAttrs);

arsenm wrote:
> tra wrote:
> > IIUIC, this changes denorm mode attributes on the functions with dynamic 
> > denorm mode that we link in.
> > Will that be a problem if the same function, when linked into different 
> > modules, would end up with different attributes? E.g. if a function is 
> > externally visible and is intended to be common'ed across multiple modules. 
> > Should dynamic denorm mode be restricted to the functions private to the 
> > module only? We do typically internalize linked bitcode for CUDA, but I 
> > don't think it's something we can always implicitly assume.
> > 
> The whole point of -mlink-builtin-bitcode is to apply the attributes for the 
> current compilation to what's linked in. The linked functions are always 
> internalized. The only case where we might not want to internalize is for 
> weak symbols (but it looks like we do internalize those today, but this is 
> something I've thought about changing). I'll add a test with a weak library 
> function
> 
> In the weak case the right thing to do is probably to not change from 
> dynamic, simply because this linking process is outside of the user's control.
> 
> 
It turns out we apply attributes prior to internalization. As a separate patch, 
we can either:

  # Skip functions that start as interposable, which has an observable change 
in the IR as it is
  # Move the link and internalize before setting attributes. This would be 
unobservable but would catch it if the internalization behavior ever changed




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

https://reviews.llvm.org/D142907

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


[PATCH] D142757: [clang][driver] Emit an error for `/clang:-x`

2023-01-31 Thread Mariya Podchishchaeva via Phabricator via cfe-commits
Fznamznon added inline comments.



Comment at: clang/docs/ReleaseNotes.rst:60
   `Issue 59446 `_.
+- Fix confusing warning message when `/clang:-x` is passed in clang-cl driver
+  mode and emit an error which suggests using `/TC` or `/TP` clang-cl options

MaskRay wrote:
> Double backtick
> 
> `LLVM_ENABLE_SPHINX=on` and run `ninja docs-clang-html` to check whether the 
> docs build is good.
Ok fixed and verified.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142757

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


[PATCH] D142757: [clang][driver] Emit an error for `/clang:-x`

2023-01-31 Thread Mariya Podchishchaeva via Phabricator via cfe-commits
Fznamznon added a comment.

@MaskRay , thanks for the suggestions. Applied. Please let me know that it is 
ok now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142757

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


[PATCH] D139926: [clangd] Add semantic token for angle brackets

2023-01-31 Thread Christian Kandeler via Phabricator via cfe-commits
ckandeler updated this revision to Diff 493610.
ckandeler added a comment.

Incorporated review comment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139926

Files:
  clang-tools-extra/clangd/SemanticHighlighting.cpp
  clang-tools-extra/clangd/SemanticHighlighting.h
  clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp

Index: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
===
--- clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
+++ clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
@@ -130,17 +130,17 @@
 )cpp",
   R"cpp(
   namespace $Namespace_decl[[abc]] {
-template
+template$Bracket[[<]]typename $TemplateParameter_def[[T]]$Bracket[[>]]
 struct $Class_def[[A]] {
   $TemplateParameter[[T]] $Field_decl[[t]];
 };
   }
-  template
-  struct $Class_def[[C]] : $Namespace[[abc]]::$Class[[A]]<$TemplateParameter[[T]]> {
+  template$Bracket[[<]]typename $TemplateParameter_def[[T]]$Bracket[[>]]
+  struct $Class_def[[C]] : $Namespace[[abc]]::$Class[[A]]$Bracket[[<]]$TemplateParameter[[T]]$Bracket[[>]] {
 typename $TemplateParameter[[T]]::$Type_dependentName[[A]]* $Field_decl[[D]];
   };
-  $Namespace[[abc]]::$Class[[A]] $Variable_def[[AA]];
-  typedef $Namespace[[abc]]::$Class[[A]] $Class_decl[[AAA]];
+  $Namespace[[abc]]::$Class[[A]]$Bracket[[<]]int$Bracket[[>]] $Variable_def[[AA]];
+  typedef $Namespace[[abc]]::$Class[[A]]$Bracket[[<]]int$Bracket[[>]] $Class_decl[[AAA]];
   struct $Class_def[[B]] {
 $Class_decl_constrDestr[[B]]();
 ~$Class_decl_constrDestr[[B]]();
@@ -243,36 +243,36 @@
   typedef float $Primitive_decl[[F]];
 )cpp",
   R"cpp(
-  template
+  template$Bracket[[<]]typename $TemplateParameter_def[[T]], typename = void$Bracket[[>]]
   class $Class_def[[A]] {
 $TemplateParameter[[T]] $Field_decl[[AA]];
 $TemplateParameter[[T]] $Method_decl[[foo]]();
   };
-  template
+  template$Bracket[[<]]class $TemplateParameter_def[[TT]]$Bracket[[>]]
   class $Class_def[[B]] {
-$Class[[A]]<$TemplateParameter[[TT]]> $Field_decl[[AA]];
+$Class[[A]]$Bracket[[<]]$TemplateParameter[[TT]]$Bracket[[>]] $Field_decl[[AA]];
   };
-  template
+  template$Bracket[[<]]class $TemplateParameter_def[[TT]], class $TemplateParameter_def[[GG]]$Bracket[[>]]
   class $Class_def[[BB]] {};
-  template
-  class $Class_def[[BB]]<$TemplateParameter[[T]], int> {};
-  template
-  class $Class_def[[BB]]<$TemplateParameter[[T]], $TemplateParameter[[T]]*> {};
+  template$Bracket[[<]]class $TemplateParameter_def[[T]]$Bracket[[>]]
+  class $Class_def[[BB]]$Bracket[[<]]$TemplateParameter[[T]], int$Bracket[[>]] {};
+  template$Bracket[[<]]class $TemplateParameter_def[[T]]$Bracket[[>]]
+  class $Class_def[[BB]]$Bracket[[<]]$TemplateParameter[[T]], $TemplateParameter[[T]]*$Bracket[[>]] {};
 
-  template class $TemplateParameter_def[[T]], class $TemplateParameter_def[[C]]>
-  $TemplateParameter[[T]]<$TemplateParameter[[C]]> $Function_decl[[f]]();
+  template$Bracket[[<]]template$Bracket[[<]]class$Bracket[[>]] class $TemplateParameter_def[[T]], class $TemplateParameter_def[[C]]$Bracket[[>]]
+  $TemplateParameter[[T]]$Bracket[[<]]$TemplateParameter[[C]]$Bracket[[>]] $Function_decl[[f]]();
 
-  template
+  template$Bracket[[<]]typename$Bracket[[>]]
   class $Class_def[[Foo]] {};
 
-  template
+  template$Bracket[[<]]typename $TemplateParameter_def[[T]]$Bracket[[>]]
   void $Function_decl[[foo]]($TemplateParameter[[T]] ...);
 )cpp",
   R"cpp(
-  template 
+  template $Bracket[[<]]class $TemplateParameter_def[[T]]$Bracket[[>]]
   struct $Class_def[[Tmpl]] {$TemplateParameter[[T]] $Field_decl[[x]] = 0;};
-  extern template struct $Class_def[[Tmpl]];
-  template struct $Class_def[[Tmpl]];
+  extern template struct $Class_def[[Tmpl]]$Bracket[[<]]float$Bracket[[>]];
+  template struct $Class_def[[Tmpl]]$Bracket[[<]]double$Bracket[[>]];
 )cpp",
   // This test is to guard against highlightings disappearing when using
   // conversion operators as their behaviour in the clang AST differ from
@@ -335,17 +335,17 @@
 )cpp",
   R"cpp(
   class $Class_def[[G]] {};
-  template<$Class[[G]] *$TemplateParameter_def_readonly[[U]]>
+  template$Bracket[[<]]$Class[[G]] *$TemplateParameter_def_readonly[[U]]$Bracket[[>]]
   class $Class_def[[GP]] {};
-  template<$Class[[G]] &$TemplateParameter_def_readonly[[U]]>
+  template$Bracket[[<]]$Class[[G]] &$TemplateParameter_def_readonly[[U]]$Bracket[[>]]
   class $Class_def[[GR]] {};
-  template
+  template$Bracket[[<]]int *$TemplateParameter_def_readonly[[U]]$

[PATCH] D142872: Honor the fwrapv option when generating the inbounds GEP .

2023-01-31 Thread Umesh Kalappa via Phabricator via cfe-commits
umesh.kalappa0 updated this revision to Diff 493612.

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

https://reviews.llvm.org/D142872

Files:
  clang/lib/CodeGen/CGExpr.cpp
  clang/test/CodeGen/inbounds.c
  llvm/include/llvm/IR/ConstantFold.h
  llvm/lib/IR/ConstantFold.cpp


Index: llvm/lib/IR/ConstantFold.cpp
===
--- llvm/lib/IR/ConstantFold.cpp
+++ llvm/lib/IR/ConstantFold.cpp
@@ -347,6 +347,14 @@
   }
 }
 
+bool llvm::getSignedWrap() {
+  return llvm::SignedWrap;
+}
+
+void llvm::setSignedWrap(bool sWrap) {
+  llvm::SignedWrap=sWrap;
+}
+
 Constant *llvm::ConstantFoldCastInstruction(unsigned opc, Constant *V,
 Type *DestTy) {
   if (isa(V))
Index: llvm/include/llvm/IR/ConstantFold.h
===
--- llvm/include/llvm/IR/ConstantFold.h
+++ llvm/include/llvm/IR/ConstantFold.h
@@ -26,10 +26,15 @@
 
 namespace llvm {
   template  class ArrayRef;
+  inline bool SignedWrap = false;
+
   class Value;
   class Constant;
   class Type;
 
+  bool getSignedWrap(void);
+  void setSignedWrap(bool Wrap);
+
   // Constant fold various types of instruction...
   Constant *ConstantFoldCastInstruction(
 unsigned opcode, ///< The opcode of the cast
Index: clang/test/CodeGen/inbounds.c
===
--- /dev/null
+++ clang/test/CodeGen/inbounds.c
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fwrapv -emit-llvm -o - %s 
| FileCheck %s 
+
+extern char base[];
+
+char *test() {
+return base + 1;
+}
+
+// CHECK: ret ptr getelementptr   (i8, ptr @base, i64 1)
Index: clang/lib/CodeGen/CGExpr.cpp
===
--- clang/lib/CodeGen/CGExpr.cpp
+++ clang/lib/CodeGen/CGExpr.cpp
@@ -3613,7 +3613,16 @@
   if (!E->getType()->isVariableArrayType()) {
 assert(isa(Addr.getElementType()) &&
"Expected pointer to array");
-Addr = Builder.CreateConstArrayGEP(Addr, 0, "arraydecay");
+
+if (getLangOpts().isSignedOverflowDefined()) {
+  llvm::setSignedWrap(true);
+  llvm::dbgs()<<"Test\n";
+  Addr = Builder.CreateConstGEP(Addr, 0, "arraydecay");
+}
+else {
+  Addr = Builder.CreateConstArrayGEP(Addr, 0, "arraydecay");
+}
+
   }
 
   // The result of this decay conversion points to an array element within the


Index: llvm/lib/IR/ConstantFold.cpp
===
--- llvm/lib/IR/ConstantFold.cpp
+++ llvm/lib/IR/ConstantFold.cpp
@@ -347,6 +347,14 @@
   }
 }
 
+bool llvm::getSignedWrap() {
+  return llvm::SignedWrap;
+}
+
+void llvm::setSignedWrap(bool sWrap) {
+  llvm::SignedWrap=sWrap;
+}
+
 Constant *llvm::ConstantFoldCastInstruction(unsigned opc, Constant *V,
 Type *DestTy) {
   if (isa(V))
Index: llvm/include/llvm/IR/ConstantFold.h
===
--- llvm/include/llvm/IR/ConstantFold.h
+++ llvm/include/llvm/IR/ConstantFold.h
@@ -26,10 +26,15 @@
 
 namespace llvm {
   template  class ArrayRef;
+  inline bool SignedWrap = false;
+
   class Value;
   class Constant;
   class Type;
 
+  bool getSignedWrap(void);
+  void setSignedWrap(bool Wrap);
+
   // Constant fold various types of instruction...
   Constant *ConstantFoldCastInstruction(
 unsigned opcode, ///< The opcode of the cast
Index: clang/test/CodeGen/inbounds.c
===
--- /dev/null
+++ clang/test/CodeGen/inbounds.c
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fwrapv -emit-llvm -o - %s | FileCheck %s 
+
+extern char base[];
+
+char *test() {
+return base + 1;
+}
+
+// CHECK: ret ptr getelementptr   (i8, ptr @base, i64 1)
Index: clang/lib/CodeGen/CGExpr.cpp
===
--- clang/lib/CodeGen/CGExpr.cpp
+++ clang/lib/CodeGen/CGExpr.cpp
@@ -3613,7 +3613,16 @@
   if (!E->getType()->isVariableArrayType()) {
 assert(isa(Addr.getElementType()) &&
"Expected pointer to array");
-Addr = Builder.CreateConstArrayGEP(Addr, 0, "arraydecay");
+
+if (getLangOpts().isSignedOverflowDefined()) {
+  llvm::setSignedWrap(true);
+  llvm::dbgs()<<"Test\n";
+  Addr = Builder.CreateConstGEP(Addr, 0, "arraydecay");
+}
+else {
+  Addr = Builder.CreateConstArrayGEP(Addr, 0, "arraydecay");
+}
+
   }
 
   // The result of this decay conversion points to an array element within the
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D142872: Honor the fwrapv option when generating the inbounds GEP .

2023-01-31 Thread Umesh Kalappa via Phabricator via cfe-commits
umesh.kalappa0 added a comment.

In D142872#4093093 , @nikic wrote:

> @umesh.kalappa0 This issue should be fixed by 
> https://github.com/llvm/llvm-project/commit/5f01a626dd0615df49773d419c75aeb33666ee83.
>  Can you please give it another try?

Thank you @nikic  for the quick changes ,and updated the review


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

https://reviews.llvm.org/D142872

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


[PATCH] D142914: [MLIR][OpenMP] Added OMPIRBuilder support for Target Data directives.

2023-01-31 Thread Akash Banerjee via Phabricator via cfe-commits
TIFitis updated this revision to Diff 493615.
TIFitis marked an inline comment as done.
TIFitis added a comment.

Added new header file mlir/include/mlir/Target/LLVMIR/Dialect/Utils.h, moved 
two common functions to the new file.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142914

Files:
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  llvm/include/llvm/Frontend/OpenMP/OMPConstants.h
  llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h
  llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp
  llvm/unittests/Frontend/OpenMPIRBuilderTest.cpp
  mlir/include/mlir/Target/LLVMIR/Dialect/Utils.h
  mlir/lib/Target/LLVMIR/Dialect/OpenACC/OpenACCToLLVMIRTranslation.cpp
  mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp

Index: mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp
===
--- mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp
+++ mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp
@@ -15,10 +15,12 @@
 #include "mlir/IR/IRMapping.h"
 #include "mlir/IR/Operation.h"
 #include "mlir/Support/LLVM.h"
+#include "mlir/Target/LLVMIR/Dialect/Utils.h"
 #include "mlir/Target/LLVMIR/ModuleTranslation.h"
 
 #include "llvm/ADT/SetVector.h"
 #include "llvm/ADT/TypeSwitch.h"
+#include "llvm/Frontend/OpenMP/OMPConstants.h"
 #include "llvm/Frontend/OpenMP/OMPIRBuilder.h"
 #include "llvm/IR/DebugInfoMetadata.h"
 #include "llvm/IR/IRBuilder.h"
@@ -1338,6 +1340,187 @@
   return success();
 }
 
+/// Process MapOperands for Target Data directives.
+static LogicalResult processMapOperand(
+llvm::IRBuilderBase &builder, LLVM::ModuleTranslation &moduleTranslation,
+const SmallVector &mapOperands, const ArrayAttr &mapTypes,
+SmallVector &mapTypeFlags,
+SmallVectorImpl &mapNames,
+struct llvm::OpenMPIRBuilder::MapperAllocas &mapperAllocas) {
+  auto numMapOperands = mapOperands.size();
+  llvm::OpenMPIRBuilder *ompBuilder = moduleTranslation.getOpenMPBuilder();
+  llvm::PointerType *i8PtrTy = builder.getInt8PtrTy();
+  llvm::ArrayType *arrI8PtrTy = llvm::ArrayType::get(i8PtrTy, numMapOperands);
+  llvm::IntegerType *i64Ty = builder.getInt64Ty();
+  llvm::ArrayType *arrI64Ty = llvm::ArrayType::get(i64Ty, numMapOperands);
+
+  unsigned index = 0;
+  for (const auto &mapOp : mapOperands) {
+const auto &mapTypeOp = mapTypes[index];
+
+llvm::Value *mapOpValue = moduleTranslation.lookupValue(mapOp);
+llvm::Value *mapOpPtrBase;
+llvm::Value *mapOpPtr;
+llvm::Value *mapOpSize;
+
+if (mapOp.getType().isa()) {
+  mapOpPtrBase = mapOpValue;
+  mapOpPtr = mapOpValue;
+  mapOpSize = ompBuilder->getSizeInBytes(mapOpValue);
+} else {
+  return failure();
+}
+
+// Store base pointer extracted from operand into the i-th position of
+// argBase.
+llvm::Value *ptrBaseGEP = builder.CreateInBoundsGEP(
+arrI8PtrTy, mapperAllocas.ArgsBase,
+{builder.getInt32(0), builder.getInt32(index)});
+llvm::Value *ptrBaseCast = builder.CreateBitCast(
+ptrBaseGEP, mapOpPtrBase->getType()->getPointerTo());
+builder.CreateStore(mapOpPtrBase, ptrBaseCast);
+
+// Store pointer extracted from operand into the i-th position of args.
+llvm::Value *ptrGEP = builder.CreateInBoundsGEP(
+arrI8PtrTy, mapperAllocas.Args,
+{builder.getInt32(0), builder.getInt32(index)});
+llvm::Value *ptrCast =
+builder.CreateBitCast(ptrGEP, mapOpPtr->getType()->getPointerTo());
+builder.CreateStore(mapOpPtr, ptrCast);
+
+// Store size extracted from operand into the i-th position of argSizes.
+llvm::Value *sizeGEP = builder.CreateInBoundsGEP(
+arrI64Ty, mapperAllocas.ArgSizes,
+{builder.getInt32(0), builder.getInt32(index)});
+builder.CreateStore(mapOpSize, sizeGEP);
+
+mapTypeFlags.push_back(mapTypeOp.dyn_cast().getInt());
+llvm::Constant *mapName =
+mlir::utils::createMappingInformation(mapOp.getLoc(), *ompBuilder);
+mapNames.push_back(mapName);
+++index;
+  }
+
+  return success();
+}
+
+static LogicalResult
+convertOmpTargetData(Operation *op, llvm::IRBuilderBase &builder,
+ LLVM::ModuleTranslation &moduleTranslation) {
+  unsigned numMapOperands;
+  llvm::Function *mapperFunc;
+  llvm::Value *ifCond = nullptr;
+  int64_t deviceID = llvm::omp::OMP_DEVICEID_UNDEF;
+  SmallVector mapOperands;
+  ArrayAttr mapTypes;
+
+  llvm::OpenMPIRBuilder *ompBuilder = moduleTranslation.getOpenMPBuilder();
+
+  LogicalResult result =
+  llvm::TypeSwitch(op)
+  .Case([&](omp::DataOp dataOp) {
+if (auto ifExprVar = dataOp.getIfExpr())
+  ifCond = moduleTranslation.lookupValue(ifExprVar);
+
+if (auto devId = dataOp.getDevice())
+  if (auto constOp = mlir::dyn_cast(
+  devId.getDefiningOp()))
+if (auto i

[PATCH] D142914: [MLIR][OpenMP] Added OMPIRBuilder support for Target Data directives.

2023-01-31 Thread Akash Banerjee via Phabricator via cfe-commits
TIFitis marked an inline comment as done.
TIFitis added inline comments.



Comment at: 
mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp:1342-1382
+/// Create a constant string location from the MLIR Location information.
+static llvm::Constant *
+createSourceLocStrFromLocation(Location loc, llvm::OpenMPIRBuilder &builder,
+   StringRef name, uint32_t &strLen) {
+  if (auto fileLoc = loc.dyn_cast()) {
+StringRef fileName = fileLoc.getFilename();
+unsigned lineNo = fileLoc.getLine();

clementval wrote:
> TIFitis wrote:
> > clementval wrote:
> > > TIFitis wrote:
> > > > clementval wrote:
> > > > > kiranchandramohan wrote:
> > > > > > clementval wrote:
> > > > > > > Instead of copy pasting this from 
> > > > > > > `mlir/lib/Target/LLVMIR/Dialect/OpenACC/OpenACCToLLVMIRTranslation.cpp`
> > > > > > >  can you extract it and put it in a common shared file so bith 
> > > > > > > translation can use the same code without duplication?
> > > > > > @raghavendhra put up a patch some time back and he faced some 
> > > > > > issues. It might be good to check with him or may be he can comment 
> > > > > > here.
> > > > > > https://reviews.llvm.org/D127037
> > > > > > https://discourse.llvm.org/t/rfc-for-refactoring-common-code-for-openacc-and-openmp/63833
> > > > > Just moving the three functions should be trivial. I'm not talking 
> > > > > about the processMapOperand.
> > > > I've moved `getSizeInBytes`.
> > > > 
> > > > The other two functions make use of `mlir::Location` and thus can't be 
> > > > moved trivially.
> > > > 
> > > > I can still try to move them by individually passing the elements of 
> > > > `mlir::Location` but that might not be ideal. Is that what you'd like?
> > > What about a new header file in 
> > > `mlir/include/mlir/Target/LLVMIR/Dialect/**` shared by 
> > > `mlir/lib/Target/LLVMIR/Dialect/OpenACC/OpenACCToLLVMIRTranslation.cpp` 
> > > and 
> > > `mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp`. 
> > > That should be doable. 
> > `mlir/lib/Target/LLVMIR/Dialect/OpenACC/OpenACCToLLVMIRTranslation.cpp` and 
> > `mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp` 
> > already have access to the common `mlir::Location` type.
> > 
> > Problem is that `OMPIRBuilder.cpp` is the only common file between them  
> > where I can move the two functions to. Currently there are no `mlir/**` 
> > include files in `OMPIRBuilder.cpp` and it seems to me like a strict design 
> > choice to have it that way.
> The functions can be header only. Why do you need to put them in the 
> OMPIRBuilder.cpp? I think it is better than duplicate the exact same code 
> over. 
Sorry, I misunderstood you earlier.
I've added a new header file `mlir/include/mlir/Target/LLVMIR/Dialect/Utils.h`, 
this is my first attempt at adding a new header file, please let me know if you 
find any issues.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142914

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


[PATCH] D142985: [LinkerWrapper] Fix memory issues due to unguarded accesses to global state

2023-01-31 Thread Joseph Huber via Phabricator via cfe-commits
jhuber6 created this revision.
jhuber6 added a reviewer: uabelho.
Herald added a project: All.
jhuber6 requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

There were intemittent errors in the linker wrapper when using the
sanitizers in parallel. First, this is because the `TempFiles` global
was not guarded when creating a new file. Second, even though the `Args`
list is passed as const, the internal state is mutable when adding a
string. So that needs to be guarded too.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D142985

Files:
  clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp


Index: clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
===
--- clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
+++ clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
@@ -77,6 +77,9 @@
 /// Binary path for the CUDA installation.
 static std::string CudaBinaryPath;
 
+/// Mutex lock to protect writes to shared TempFiles in parallel.
+static std::mutex TempFilesMutex;
+
 /// Temporary files created by the linker wrapper.
 static std::list> TempFiles;
 
@@ -200,6 +203,7 @@
 
 /// Get a temporary filename suitable for output.
 Expected createOutputFile(const Twine &Prefix, StringRef Extension) 
{
+  std::scoped_lock Lock(TempFilesMutex);
   SmallString<128> OutputFile;
   if (SaveTemps) {
 (Prefix + "." + Extension).toNullTerminatedStringRef(OutputFile);
@@ -1047,6 +1051,7 @@
   return createFileError(*OutputOrErr, EC);
   }
 
+  std::scoped_lock Guard(ImageMtx);
   OffloadingImage TheImage{};
   TheImage.TheImageKind =
   Args.hasArg(OPT_embed_bitcode) ? IMG_Bitcode : IMG_Object;
@@ -1058,7 +1063,6 @@
Args.MakeArgString(LinkerArgs.getLastArgValue(OPT_arch_EQ))}};
   TheImage.Image = std::move(*FileOrErr);
 
-  std::lock_guard Guard(ImageMtx);
   Images[Kind].emplace_back(std::move(TheImage));
 }
 return Error::success();


Index: clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
===
--- clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
+++ clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
@@ -77,6 +77,9 @@
 /// Binary path for the CUDA installation.
 static std::string CudaBinaryPath;
 
+/// Mutex lock to protect writes to shared TempFiles in parallel.
+static std::mutex TempFilesMutex;
+
 /// Temporary files created by the linker wrapper.
 static std::list> TempFiles;
 
@@ -200,6 +203,7 @@
 
 /// Get a temporary filename suitable for output.
 Expected createOutputFile(const Twine &Prefix, StringRef Extension) {
+  std::scoped_lock Lock(TempFilesMutex);
   SmallString<128> OutputFile;
   if (SaveTemps) {
 (Prefix + "." + Extension).toNullTerminatedStringRef(OutputFile);
@@ -1047,6 +1051,7 @@
   return createFileError(*OutputOrErr, EC);
   }
 
+  std::scoped_lock Guard(ImageMtx);
   OffloadingImage TheImage{};
   TheImage.TheImageKind =
   Args.hasArg(OPT_embed_bitcode) ? IMG_Bitcode : IMG_Object;
@@ -1058,7 +1063,6 @@
Args.MakeArgString(LinkerArgs.getLastArgValue(OPT_arch_EQ))}};
   TheImage.Image = std::move(*FileOrErr);
 
-  std::lock_guard Guard(ImageMtx);
   Images[Kind].emplace_back(std::move(TheImage));
 }
 return Error::success();
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D142985: [LinkerWrapper] Fix memory issues due to unguarded accesses to global state

2023-01-31 Thread Joseph Huber via Phabricator via cfe-commits
jhuber6 added a comment.

If this fixes the issues on your side, please open a bug so it can be 
backported.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142985

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


[PATCH] D142986: Enable multilib.yaml in the BareMetal ToolChain

2023-01-31 Thread Michael Platings via Phabricator via cfe-commits
michaelplatings created this revision.
michaelplatings added a reviewer: phosek.
Herald added subscribers: abidh, kristof.beyls.
Herald added a project: All.
michaelplatings requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay.
Herald added a project: clang.

The default location for multilib.yaml is lib/clang-runtimes, without
any target-specific suffix. This will allow multilibs for different
architectures to share a common include directory.

To avoid breaking the arm-execute-only.c CHECK-NO-EXECUTE-ONLY-ASM
test, add a GetExecuteOnly argument to getARMTargetFeatures.

Since the presence of multilib.yaml can change the exact location of a
library, relax the baremetal.cpp test.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D142986

Files:
  clang/lib/Driver/ToolChain.cpp
  clang/lib/Driver/ToolChains/Arch/ARM.cpp
  clang/lib/Driver/ToolChains/Arch/ARM.h
  clang/lib/Driver/ToolChains/BareMetal.cpp
  clang/test/Driver/Inputs/baremetal_multilib/multilib.yaml
  clang/test/Driver/baremetal-multilib.cpp
  clang/test/Driver/baremetal.cpp

Index: clang/test/Driver/baremetal.cpp
===
--- clang/test/Driver/baremetal.cpp
+++ clang/test/Driver/baremetal.cpp
@@ -118,9 +118,9 @@
 // Verify that the bare metal driver does not include any host system paths:
 // CHECK-AARCH64-NO-HOST-INC: InstalledDir: [[INSTALLEDDIR:.+]]
 // CHECK-AARCH64-NO-HOST-INC: "-resource-dir" "[[RESOURCE:[^"]+]]"
-// CHECK-AARCH64-NO-HOST-INC-SAME: "-internal-isystem" "[[INSTALLEDDIR]]{{[/\\]+}}..{{[/\\]+}}lib{{[/\\]+}}clang-runtimes{{[/\\]+}}aarch64-none-elf{{[/\\]+}}include{{[/\\]+}}c++{{[/\\]+}}v1"
+// CHECK-AARCH64-NO-HOST-INC-SAME: "-internal-isystem" "[[INSTALLEDDIR]]{{[/\\]+}}..{{[/\\]+}}lib{{[/\\]+}}clang-runtimes{{[/\\]+[^"]*}}include{{[/\\]+}}c++{{[/\\]+}}v1"
 // CHECK-AARCH64-NO-HOST-INC-SAME: "-internal-isystem" "[[RESOURCE]]{{[/\\]+}}include"
-// CHECK-AARCH64-NO-HOST-INC-SAME: "-internal-isystem" "[[INSTALLEDDIR]]{{[/\\]+}}..{{[/\\]+}}lib{{[/\\]+}}clang-runtimes{{[/\\]+}}aarch64-none-elf{{[/\\]+}}include"
+// CHECK-AARCH64-NO-HOST-INC-SAME: "-internal-isystem" "[[INSTALLEDDIR]]{{[/\\]+}}..{{[/\\]+}}lib{{[/\\]+}}clang-runtimes{{[/\\]+[^"]*}}include"
 
 // RUN: %clang %s -### --target=riscv64-unknown-elf -o %t.out -L some/directory/user/asked/for \
 // RUN: --sysroot=%S/Inputs/basic_riscv64_tree/riscv64-unknown-elf 2>&1 \
Index: clang/test/Driver/baremetal-multilib.cpp
===
--- /dev/null
+++ clang/test/Driver/baremetal-multilib.cpp
@@ -0,0 +1,45 @@
+// REQUIRES: shell
+// UNSUPPORTED: system-windows
+
+// RUN: rm -rf %T/baremetal_multilib
+// RUN: mkdir -p %T/baremetal_multilib/bin
+// RUN: mkdir -p %T/baremetal_multilib/lib/clang-runtimes/arm-none-eabi/thumb/v8-m.main/fp/lib
+// RUN: touch %T/baremetal_multilib/lib/clang-runtimes/arm-none-eabi/thumb/v8-m.main/fp/lib/libclang_rt.builtins.a
+// RUN: ln -s %clang %T/baremetal_multilib/bin/clang
+// RUN: ln -s %S/Inputs/baremetal_multilib/multilib.yaml %T/baremetal_multilib/lib/clang-runtimes/multilib.yaml
+
+// RUN: %T/baremetal_multilib/bin/clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
+// RUN: --target=thumbv8m.main-none-eabihf --sysroot= \
+// RUN:   | FileCheck %s
+// CHECK: "{{.*}}clang{{.*}}" "-cc1" "-triple" "thumbv8m.main-none-unknown-eabihf"
+// CHECK-SAME: "-internal-isystem" "{{.*}}/baremetal_multilib/bin/../lib/clang-runtimes/arm-none-eabi/thumb/v8-m.main/fp/include/c++/v1"
+// CHECK-SAME: "-internal-isystem" "{{.*}}/baremetal_multilib/bin/../lib/clang-runtimes/arm-none-eabi/thumb/v8-m.main/fp/include"
+// CHECK-SAME: "-x" "c++" "{{.*}}/baremetal-multilib.cpp"
+// CHECK-NEXT: "{{[^"]*}}ld{{(\.(lld|bfd|gold))?}}{{(\.exe)?}}" "{{.*}}.o" "-Bstatic"
+// CHECK-SAME: "-L{{.*}}/baremetal_multilib/bin/../lib/clang-runtimes/arm-none-eabi/thumb/v8-m.main/fp/lib"
+// CHECK-SAME: "-lc" "-lm" "-lclang_rt.builtins"
+// CHECK-SAME: "-o" "{{.*}}.o"
+
+// 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
+// CHECK-PRINT-MULTI-DIRECTORY: arm-none-eabi/thumb/v8-m.main/fp
+
+// RUN: %T/baremetal_multilib/bin/clang -no-canonical-prefixes -print-multi-lib 2>&1 \
+// RUN: --target=arm-none-eabi --sysroot= \
+// RUN:   | FileCheck --check-prefix=CHECK-PRINT-MULTI-LIB %s
+// CHECK-PRINT-MULTI-LIB: arm-none-eabi/thumb/v6-m/nofp;@-target=thumbv6m-none-eabi@mfloat-abi=soft
+// CHECK-PRINT-MULTI-LIB: arm-none-eabi/thumb/v7-m/nofp;@-target=thumbv7m-none-eabi@mfloat-abi=soft
+// CHECK-PRINT-MULTI-LIB: arm-none-eabi/thumb/v7e-m/nofp;@-target=thumbv7em-none-eabi@mfloat-abi=soft@mfpu=none
+// CHECK-PRINT-MULTI-LIB: arm-none-eabi/thumb/v8-m.main/nofp;@-target=arm-none-eabi@mfloat-abi=soft@march=armv8m.main+nofp
+// CHECK-PRINT-MULTI-LIB: arm-none-eabi/

[clang] 40d8c06 - [flang][driver] Add support for -embed-offload-object flag in flang

2023-01-31 Thread Jan Sjodin via cfe-commits

Author: Jan Sjodin
Date: 2023-01-31T10:56:45-05:00
New Revision: 40d8c0666f19599c16e5345abee371d016409c12

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

LOG: [flang][driver] Add support for -embed-offload-object flag in flang

This patch adds support for the -embed-offload-object flag to embed offloading
binaries in host code. This flag is identical to the clang flag with the same 
name.

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

Reviewed By: awarzynski, jhuber6

Added: 
flang/test/Driver/embed-error.f90
flang/test/Driver/embed.f90

Modified: 
clang/include/clang/Driver/Options.td
flang/include/flang/Frontend/CodeGenOptions.h
flang/include/flang/Frontend/FrontendActions.h
flang/lib/Frontend/CompilerInvocation.cpp
flang/lib/Frontend/FrontendActions.cpp
flang/test/Driver/driver-help.f90

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 23752823e88f6..9aef70321d525 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -1224,7 +1224,7 @@ defm experimental_library : 
BoolFOption<"experimental-library",
   NegFlag>;
 
 def fembed_offload_object_EQ : Joined<["-"], "fembed-offload-object=">,
-  Group, Flags<[NoXarchOption, CC1Option]>,
+  Group, Flags<[NoXarchOption, CC1Option, FC1Option]>,
   HelpText<"Embed Offloading device-side binary into host object file as a 
section.">,
   MarshallingInfoStringVector>;
 def fembed_bitcode_EQ : Joined<["-"], "fembed-bitcode=">,

diff  --git a/flang/include/flang/Frontend/CodeGenOptions.h 
b/flang/include/flang/Frontend/CodeGenOptions.h
index 7bb10d4b0f3c8..8de150cdfb158 100644
--- a/flang/include/flang/Frontend/CodeGenOptions.h
+++ b/flang/include/flang/Frontend/CodeGenOptions.h
@@ -49,6 +49,10 @@ class CodeGenOptions : public CodeGenOptionsBase {
   /// The paths to the pass plugins that were registered using -fpass-plugin.
   std::vector LLVMPassPlugins;
 
+  /// List of filenames passed in using the -fembed-offload-object option. 
These
+  /// are offloading binaries containing device images and metadata.
+  std::vector OffloadObjects;
+
   // Define accessors/mutators for code generation options of enumeration type.
 #define CODEGENOPT(Name, Bits, Default)
 #define ENUM_CODEGENOPT(Name, Type, Bits, Default) 
\

diff  --git a/flang/include/flang/Frontend/FrontendActions.h 
b/flang/include/flang/Frontend/FrontendActions.h
index eb9dda75c516c..7a5042b814a14 100644
--- a/flang/include/flang/Frontend/FrontendActions.h
+++ b/flang/include/flang/Frontend/FrontendActions.h
@@ -221,6 +221,9 @@ class CodeGenAction : public FrontendAction {
   std::unique_ptr llvmCtx;
   std::unique_ptr llvmModule;
 
+  /// Embeds offload objects given with specified with -fembed-offload-object
+  void embedOffloadObjects();
+
   /// Generates an LLVM IR module from CodeGenAction::mlirModule and saves it
   /// in CodeGenAction::llvmModule.
   void generateLLVMIR();

diff  --git a/flang/lib/Frontend/CompilerInvocation.cpp 
b/flang/lib/Frontend/CompilerInvocation.cpp
index 0e9e94503ad89..9ab7030da940d 100644
--- a/flang/lib/Frontend/CompilerInvocation.cpp
+++ b/flang/lib/Frontend/CompilerInvocation.cpp
@@ -129,6 +129,11 @@ static void 
parseCodeGenArgs(Fortran::frontend::CodeGenOptions &opts,
   for (auto *a : args.filtered(clang::driver::options::OPT_fpass_plugin_EQ))
 opts.LLVMPassPlugins.push_back(a->getValue());
 
+  // -fembed-offload-object option
+  for (auto *a :
+   args.filtered(clang::driver::options::OPT_fembed_offload_object_EQ))
+opts.OffloadObjects.push_back(a->getValue());
+
   // -mrelocation-model option.
   if (const llvm::opt::Arg *A =
   args.getLastArg(clang::driver::options::OPT_mrelocation_model)) {

diff  --git a/flang/lib/Frontend/FrontendActions.cpp 
b/flang/lib/Frontend/FrontendActions.cpp
index 7e41565a602ce..7cb352a85e0c1 100644
--- a/flang/lib/Frontend/FrontendActions.cpp
+++ b/flang/lib/Frontend/FrontendActions.cpp
@@ -47,12 +47,14 @@
 #include "llvm/IR/Verifier.h"
 #include "llvm/IRReader/IRReader.h"
 #include "llvm/MC/TargetRegistry.h"
+#include "llvm/Object/OffloadBinary.h"
 #include "llvm/Passes/PassBuilder.h"
 #include "llvm/Passes/PassPlugin.h"
 #include "llvm/Passes/StandardInstrumentations.h"
 #include "llvm/Support/ErrorHandling.h"
 #include "llvm/Support/SourceMgr.h"
 #include "llvm/Target/TargetMachine.h"
+#include "llvm/Transforms/Utils/ModuleUtils.h"
 #include 
 
 using namespace Fortran::frontend;
@@ -727,6 +729,25 @@ void 
CodeGenAction::runOptimizationPipeline(llvm::raw_pwrite_stream &os) {
   mpm.run(*llvmModule, mam);
 }
 
+void CodeGenAction::embedOffloadObjects() {
+  CompilerInstance &ci = this->getInstance();
+  const auto

[PATCH] D142244: [flang][driver] Add support for -embed-offload-object flag in flang -fc1

2023-01-31 Thread Jan Sjödin 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 rG40d8c0666f19: [flang][driver] Add support for 
-embed-offload-object flag in flang (authored by jsjodin).
Herald added projects: clang, Flang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142244

Files:
  clang/include/clang/Driver/Options.td
  flang/include/flang/Frontend/CodeGenOptions.h
  flang/include/flang/Frontend/FrontendActions.h
  flang/lib/Frontend/CompilerInvocation.cpp
  flang/lib/Frontend/FrontendActions.cpp
  flang/test/Driver/driver-help.f90
  flang/test/Driver/embed-error.f90
  flang/test/Driver/embed.f90

Index: flang/test/Driver/embed.f90
===
--- /dev/null
+++ flang/test/Driver/embed.f90
@@ -0,0 +1,20 @@
+
+!--
+! RUN lines
+!--
+! Embed something that can be easily checked
+! RUN: %flang_fc1 -emit-llvm -o - -fembed-offload-object=%S/Inputs/hello.f90 %s 2>&1 | FileCheck %s
+
+! RUN: %flang_fc1 -emit-llvm-bc -o %t.bc %s 2>&1
+! RUN: %flang_fc1 -emit-llvm -o - -fembed-offload-object=%S/Inputs/hello.f90 %t.bc 2>&1 | FileCheck %s
+
+! CHECK: @[[OBJECT_1:.+]] = private constant [61 x i8] c"program hello\0A  write(*,*), \22Hello world!\22\0Aend program hello\0A", section ".llvm.offloading", align 8, !exclude !0
+! CHECK: @llvm.compiler.used = appending global [1 x ptr] [ptr @[[OBJECT_1]]], section "llvm.metadata"
+
+
+! CHECK: !llvm.embedded.objects = !{![[METADATA_1:[0-9]+]]}
+! CHECK: ![[METADATA_1]] = !{ptr @[[OBJECT_1]], !".llvm.offloading"}
+
+parameter(i=1)
+integer :: j
+end program
Index: flang/test/Driver/embed-error.f90
===
--- /dev/null
+++ flang/test/Driver/embed-error.f90
@@ -0,0 +1,12 @@
+
+!--
+! RUN lines
+!--
+! Try to embed missing file
+! RUN: not %flang_fc1 -emit-llvm -o - -fembed-offload-object=%S/Inputs/missing.f90 %s 2>&1 | FileCheck %s --check-prefix=ERROR
+
+! ERROR: error: could not open
+
+parameter(i=1)
+integer :: j
+end program
Index: flang/test/Driver/driver-help.f90
===
--- flang/test/Driver/driver-help.f90
+++ flang/test/Driver/driver-help.f90
@@ -109,6 +109,8 @@
 ! HELP-FC1-NEXT: -fdefault-double-8  Set the default double precision kind to an 8 byte wide type
 ! HELP-FC1-NEXT: -fdefault-integer-8 Set the default integer kind to an 8 byte wide type
 ! HELP-FC1-NEXT: -fdefault-real-8Set the default real kind to an 8 byte wide type
+! HELP-FC1-NEXT: -fembed-offload-object=
+! HELP-FC1-NEXT:Embed Offloading device-side binary into host object file as a section.
 ! HELP-FC1-NEXT: -ffast-mathAllow aggressive, lossy floating-point optimizations
 ! HELP-FC1-NEXT: -ffixed-form   Process source files in fixed form
 ! HELP-FC1-NEXT: -ffixed-line-length=
Index: flang/lib/Frontend/FrontendActions.cpp
===
--- flang/lib/Frontend/FrontendActions.cpp
+++ flang/lib/Frontend/FrontendActions.cpp
@@ -47,12 +47,14 @@
 #include "llvm/IR/Verifier.h"
 #include "llvm/IRReader/IRReader.h"
 #include "llvm/MC/TargetRegistry.h"
+#include "llvm/Object/OffloadBinary.h"
 #include "llvm/Passes/PassBuilder.h"
 #include "llvm/Passes/PassPlugin.h"
 #include "llvm/Passes/StandardInstrumentations.h"
 #include "llvm/Support/ErrorHandling.h"
 #include "llvm/Support/SourceMgr.h"
 #include "llvm/Target/TargetMachine.h"
+#include "llvm/Transforms/Utils/ModuleUtils.h"
 #include 
 
 using namespace Fortran::frontend;
@@ -727,6 +729,25 @@
   mpm.run(*llvmModule, mam);
 }
 
+void CodeGenAction::embedOffloadObjects() {
+  CompilerInstance &ci = this->getInstance();
+  const auto &cgOpts = ci.getInvocation().getCodeGenOpts();
+
+  for (llvm::StringRef offloadObject : cgOpts.OffloadObjects) {
+llvm::ErrorOr> objectOrErr =
+llvm::MemoryBuffer::getFileOrSTDIN(offloadObject);
+if (std::error_code ec = objectOrErr.getError()) {
+  auto diagID = ci.getDiagnostics().getCustomDiagID(
+  clang::DiagnosticsEngine::Error, "could not open '%0' for embedding");
+  ci.getDiagnostics().Report(diagID) << offloadObject;
+  return;
+}
+llvm::embedBufferInModule(
+*llvmModule, **objectOrErr, ".llvm.offloading",
+llvm::Align(llvm::object::OffloadBinary::getAlignment()));
+  }
+}
+
 void CodeGenAction::executeAction() {
   CompilerInstance &ci = this->getInstance();
 
@@ -774,12 +795,17 @@
 ci.getDiagnostics().Report(clang::diag::warn_fe_override_module)
 << theTriple;
   }
+
   // Always set the triple and data layout, to make sure they match and are set.
   // Note that this overwrites any datalayout stored in the LLVM-IR. This avoids
   // an assert for in

[PATCH] D142872: Honor the fwrapv option when generating the inbounds GEP .

2023-01-31 Thread Umesh Kalappa via Phabricator via cfe-commits
umesh.kalappa0 updated this revision to Diff 493623.

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

https://reviews.llvm.org/D142872

Files:
  clang/lib/CodeGen/CGExpr.cpp
  clang/test/CodeGen/inbounds.c
  llvm/include/llvm/IR/ConstantFold.h
  llvm/lib/IR/ConstantFold.cpp


Index: llvm/lib/IR/ConstantFold.cpp
===
--- llvm/lib/IR/ConstantFold.cpp
+++ llvm/lib/IR/ConstantFold.cpp
@@ -347,6 +347,14 @@
   }
 }
 
+bool llvm::getSignedWrap() {
+  return llvm::SignedWrap;
+}
+
+void llvm::setSignedWrap(bool sWrap) {
+  llvm::SignedWrap=sWrap;
+}
+
 Constant *llvm::ConstantFoldCastInstruction(unsigned opc, Constant *V,
 Type *DestTy) {
   if (isa(V))
Index: llvm/include/llvm/IR/ConstantFold.h
===
--- llvm/include/llvm/IR/ConstantFold.h
+++ llvm/include/llvm/IR/ConstantFold.h
@@ -26,10 +26,15 @@
 
 namespace llvm {
   template  class ArrayRef;
+  inline bool SignedWrap = false;
+
   class Value;
   class Constant;
   class Type;
 
+  bool getSignedWrap(void);
+  void setSignedWrap(bool Wrap);
+
   // Constant fold various types of instruction...
   Constant *ConstantFoldCastInstruction(
 unsigned opcode, ///< The opcode of the cast
Index: clang/test/CodeGen/inbounds.c
===
--- /dev/null
+++ clang/test/CodeGen/inbounds.c
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fwrapv -emit-llvm -o - %s 
| FileCheck %s 
+
+extern char base[];
+
+char *test() {
+return base + 1;
+}
+
+// CHECK: ret ptr getelementptr   (i8, ptr @base, i64 1)
Index: clang/lib/CodeGen/CGExpr.cpp
===
--- clang/lib/CodeGen/CGExpr.cpp
+++ clang/lib/CodeGen/CGExpr.cpp
@@ -3613,7 +3613,15 @@
   if (!E->getType()->isVariableArrayType()) {
 assert(isa(Addr.getElementType()) &&
"Expected pointer to array");
-Addr = Builder.CreateConstArrayGEP(Addr, 0, "arraydecay");
+
+if (getLangOpts().isSignedOverflowDefined()) {
+  llvm::setSignedWrap(true);
+  Addr = Builder.CreateConstGEP(Addr, 0, "arraydecay");
+}
+else {
+  Addr = Builder.CreateConstArrayGEP(Addr, 0, "arraydecay");
+}
+
   }
 
   // The result of this decay conversion points to an array element within the


Index: llvm/lib/IR/ConstantFold.cpp
===
--- llvm/lib/IR/ConstantFold.cpp
+++ llvm/lib/IR/ConstantFold.cpp
@@ -347,6 +347,14 @@
   }
 }
 
+bool llvm::getSignedWrap() {
+  return llvm::SignedWrap;
+}
+
+void llvm::setSignedWrap(bool sWrap) {
+  llvm::SignedWrap=sWrap;
+}
+
 Constant *llvm::ConstantFoldCastInstruction(unsigned opc, Constant *V,
 Type *DestTy) {
   if (isa(V))
Index: llvm/include/llvm/IR/ConstantFold.h
===
--- llvm/include/llvm/IR/ConstantFold.h
+++ llvm/include/llvm/IR/ConstantFold.h
@@ -26,10 +26,15 @@
 
 namespace llvm {
   template  class ArrayRef;
+  inline bool SignedWrap = false;
+
   class Value;
   class Constant;
   class Type;
 
+  bool getSignedWrap(void);
+  void setSignedWrap(bool Wrap);
+
   // Constant fold various types of instruction...
   Constant *ConstantFoldCastInstruction(
 unsigned opcode, ///< The opcode of the cast
Index: clang/test/CodeGen/inbounds.c
===
--- /dev/null
+++ clang/test/CodeGen/inbounds.c
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fwrapv -emit-llvm -o - %s | FileCheck %s 
+
+extern char base[];
+
+char *test() {
+return base + 1;
+}
+
+// CHECK: ret ptr getelementptr   (i8, ptr @base, i64 1)
Index: clang/lib/CodeGen/CGExpr.cpp
===
--- clang/lib/CodeGen/CGExpr.cpp
+++ clang/lib/CodeGen/CGExpr.cpp
@@ -3613,7 +3613,15 @@
   if (!E->getType()->isVariableArrayType()) {
 assert(isa(Addr.getElementType()) &&
"Expected pointer to array");
-Addr = Builder.CreateConstArrayGEP(Addr, 0, "arraydecay");
+
+if (getLangOpts().isSignedOverflowDefined()) {
+  llvm::setSignedWrap(true);
+  Addr = Builder.CreateConstGEP(Addr, 0, "arraydecay");
+}
+else {
+  Addr = Builder.CreateConstArrayGEP(Addr, 0, "arraydecay");
+}
+
   }
 
   // The result of this decay conversion points to an array element within the
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 04ed86f - [clang-format][NFC] Bring FormatTokenSource under test.

2023-01-31 Thread Manuel Klimek via cfe-commits

Author: Manuel Klimek
Date: 2023-01-31T16:06:46Z
New Revision: 04ed86ff1b7272faf8e62fa32da4acaa2d3c6add

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

LOG: [clang-format][NFC] Bring FormatTokenSource under test.

Add tests for FormatTokenSource and harden it against edge cases.

Added: 
clang/unittests/Format/FormatTokenSourceTest.cpp

Modified: 
clang/lib/Format/FormatTokenSource.h
clang/unittests/Format/CMakeLists.txt

Removed: 




diff  --git a/clang/lib/Format/FormatTokenSource.h 
b/clang/lib/Format/FormatTokenSource.h
index e14f72b7d1f44..359e0e52878bb 100644
--- a/clang/lib/Format/FormatTokenSource.h
+++ b/clang/lib/Format/FormatTokenSource.h
@@ -77,7 +77,9 @@ class IndexedTokenSource : public FormatTokenSource {
 return Position > 0 ? Tokens[Position - 1] : nullptr;
   }
 
-  FormatToken *peekNextToken(bool SkipComment) override {
+  FormatToken *peekNextToken(bool SkipComment = false) override {
+if (isEOF())
+  return Tokens[Position];
 int Next = Position + 1;
 if (SkipComment)
   while (Tokens[Next]->is(tok::comment))
@@ -89,7 +91,9 @@ class IndexedTokenSource : public FormatTokenSource {
 return Tokens[Next];
   }
 
-  bool isEOF() override { return Tokens[Position]->is(tok::eof); }
+  bool isEOF() override {
+return Position == -1 ? false : Tokens[Position]->is(tok::eof);
+  }
 
   unsigned getPosition() override {
 LLVM_DEBUG(llvm::dbgs() << "Getting Position: " << Position << "\n");

diff  --git a/clang/unittests/Format/CMakeLists.txt 
b/clang/unittests/Format/CMakeLists.txt
index 09457c105ca30..1db1f602415bb 100644
--- a/clang/unittests/Format/CMakeLists.txt
+++ b/clang/unittests/Format/CMakeLists.txt
@@ -21,6 +21,7 @@ add_clang_unittest(FormatTests
   FormatTestTableGen.cpp
   FormatTestTextProto.cpp
   FormatTestVerilog.cpp
+  FormatTokenSourceTest.cpp
   IntegerLiteralSeparatorTest.cpp
   MacroCallReconstructorTest.cpp
   MacroExpanderTest.cpp

diff  --git a/clang/unittests/Format/FormatTokenSourceTest.cpp 
b/clang/unittests/Format/FormatTokenSourceTest.cpp
new file mode 100644
index 0..3c2f317adf5c3
--- /dev/null
+++ b/clang/unittests/Format/FormatTokenSourceTest.cpp
@@ -0,0 +1,75 @@
+//===- unittest/Format/FormatTokenSourceTest.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 "../../lib/Format/FormatTokenSource.h"
+#include "TestLexer.h"
+#include "clang/Basic/TokenKinds.h"
+#include "gtest/gtest.h"
+
+namespace clang {
+namespace format {
+namespace {
+
+class IndexedTokenSourceTest : public ::testing::Test {
+protected:
+  TokenList lex(llvm::StringRef Code,
+const FormatStyle &Style = getLLVMStyle()) {
+return TestLexer(Allocator, Buffers, Style).lex(Code);
+  }
+  llvm::SpecificBumpPtrAllocator Allocator;
+  std::vector> Buffers;
+};
+
+#define EXPECT_TOKEN_KIND(FormatTok, Kind) 
\
+  do { 
\
+FormatToken *Tok = FormatTok;  
\
+EXPECT_EQ((Tok)->Tok.getKind(), Kind) << *(Tok);   
\
+  } while (false);
+
+TEST_F(IndexedTokenSourceTest, EmptyInput) {
+  IndexedTokenSource Source(lex(""));
+  EXPECT_FALSE(Source.isEOF());
+  EXPECT_TOKEN_KIND(Source.getNextToken(), tok::eof);
+  EXPECT_TRUE(Source.isEOF());
+  EXPECT_TOKEN_KIND(Source.getNextToken(), tok::eof);
+  EXPECT_TRUE(Source.isEOF());
+  EXPECT_TOKEN_KIND(Source.peekNextToken(/*SkipComment=*/false), tok::eof);
+  EXPECT_TOKEN_KIND(Source.peekNextToken(/*SkipComment=*/true), tok::eof);
+  EXPECT_EQ(Source.getPreviousToken(), nullptr);
+  EXPECT_TRUE(Source.isEOF());
+}
+
+TEST_F(IndexedTokenSourceTest, NavigateTokenStream) {
+  IndexedTokenSource Source(lex("int a;"));
+  EXPECT_TOKEN_KIND(Source.peekNextToken(), tok::kw_int);
+  EXPECT_TOKEN_KIND(Source.getNextToken(), tok::kw_int);
+  EXPECT_EQ(Source.getPreviousToken(), nullptr);
+  EXPECT_TOKEN_KIND(Source.peekNextToken(), tok::identifier);
+  EXPECT_TOKEN_KIND(Source.getNextToken(), tok::identifier);
+  EXPECT_TOKEN_KIND(Source.getPreviousToken(), tok::kw_int);
+  EXPECT_TOKEN_KIND(Source.peekNextToken(), tok::semi);
+  EXPECT_TOKEN_KIND(Source.getNextToken(), tok::semi);
+  EXPECT_TOKEN_KIND(Source.getPreviousToken(), tok::identifier);
+  EXPECT_TOKEN_KIND(Source.peekNextToken(), tok::eof);
+  EXPECT_TOKEN_KIND(Source.getNextToken(), tok::eof);
+  EXPECT_TOKEN_KIND(Source.getPreviousToken(), tok::sem

[PATCH] D142014: [clangd] fix wrong CalleeArgInfo in the hover

2023-01-31 Thread Vincent Hong via Phabricator via cfe-commits
v1nh1shungry added inline comments.



Comment at: clang-tools-extra/clangd/Hover.cpp:994
   HI.CalleeArgInfo.emplace(toHoverInfoParam(PVD, PP));
+  PassType.PassBy = getPassMode(PVD->getType());
+}

kadircet wrote:
> v1nh1shungry wrote:
> > kadircet wrote:
> > > v1nh1shungry wrote:
> > > > kadircet wrote:
> > > > > v1nh1shungry wrote:
> > > > > > kadircet wrote:
> > > > > > > sorry for showing up late to the party but instead of changing 
> > > > > > > rest of the code, can we apply this logic only when there are no 
> > > > > > > implicit casts/conversions between the arg and callexpr (i.e `N 
> > > > > > > == &OuterNode`)?
> > > > > > To make sure I understand it correctly, do you mean I should give 
> > > > > > up any other code changes I made but keep this logic, and put this 
> > > > > > logic into the `N == &OuterNode` branch?
> > > > > > 
> > > > > > Sorry if I misunderstood anything! Shame for not being a good 
> > > > > > reader :(
> > > > > > To make sure I understand it correctly, do you mean I should give 
> > > > > > up any other code changes I made but keep this logic, and put this 
> > > > > > logic into the N == &OuterNode branch?
> > > > > 
> > > > > Somewhat.
> > > > > 
> > > > > Basically this code had the assumption that if we don't see any 
> > > > > casts/conversions between the expression creating the argument and 
> > > > > the expression getting passed to the callexpr, it must be passed by 
> > > > > reference, and this was wrong. Even before the patch that added 
> > > > > handling for literals.
> > > > > 
> > > > > The rest of the handling for casts/conversions/constructors in 
> > > > > between have been working so far and was constructed based on what 
> > > > > each particular cast does, not for specific cases hence they're 
> > > > > easier (for the lack of a better word) to reason about. Hence I'd 
> > > > > rather keep them as is, especially the changes in handling 
> > > > > `MaterializeTemporaryExpr` don't sound right. I can see the example 
> > > > > you've at hand, but we shouldn't be producing "converted" results for 
> > > > > it anyway (the AST should have a NoOp implicit cast to `const int` 
> > > > > and then a `MaterializeTemporaryExpr`, which shouldn't generated any 
> > > > > converted signals with the existing code already).
> > > > > 
> > > > > Hence the my proposal is getting rid of the assumption around "if we 
> > > > > don't see any casts/conversions between the expression creating the 
> > > > > argument and the expression getting passed to the callexpr, it must 
> > > > > be passed by reference", and use the type information in 
> > > > > `ParmVarDecl` directly when we don't have any implicit nodes in 
> > > > > between to infer `PassBy`.
> > > > > This should imply also getting rid of the special case for literals 
> > > > > (`if (isLiteral(E) && N->Parent == OuterNode.Parent)`).
> > > > > 
> > > > > Does that make sense?
> > > > Thanks for the detailed explanation! But before we go ahead here, what 
> > > > do you think about the new test case I'm talking about above? Do you 
> > > > agree with my conclusion?
> > > i suppose you mean:
> > > 
> > > ```
> > > void foobar(const float &);
> > > int main() {
> > >   foobar(0);
> > >   ^
> > > }
> > > ```
> > > 
> > > first of all the version of the patch that i propose doesn't involve any 
> > > changes in behaviour here (as we actually have an implicit cast in 
> > > between, and i am suggesting finding out passby based on type of the 
> > > parmvardecl only when there are no casts in between).
> > > 
> > > i can see @nridge 's reasoning about indicating copies by saying pass by 
> > > value vs ref, which unfortunately doesn't align with C++ semantics 
> > > directly (as what we have here is a prvalue, and it is indeed passed by 
> > > value, without any copies to the callee).
> > > 
> > > it isn't very obvious anywhere but the main functionality we wanted to 
> > > provide to the developer was help them figure out if a function call can 
> > > mutate a parameter they were passing in, therefore it didn't prioritise 
> > > literals at all. we probably should've made better wording choices in the 
> > > UI and talked about "immutability". hence from functionality point of 
> > > view calling this pass by `value` vs `const ref` doesn't make a huge 
> > > difference (but that's probably only in my mind and people are already 
> > > using it to infer other things like whether we're going to trigger 
> > > copies).
> > > 
> > > so i'd actually leave this case as-is, and think about what we're 
> > > actually trying to provide by showing arg info on literals. as it's 
> > > currently trying to overload the meaning of `passby` and causing 
> > > confusions. since the initial intent was to just convey "immutability" 
> > > one suggestion would be to just hide the `passby` information for 
> > > literals.
> > > otherwise from value categories point of view, th

[PATCH] D142014: [clangd] fix wrong CalleeArgInfo in the hover

2023-01-31 Thread Vincent Hong via Phabricator via cfe-commits
v1nh1shungry updated this revision to Diff 493626.
v1nh1shungry added a comment.

- restore code changes
- add test cases


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142014

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

Index: clang-tools-extra/clangd/unittests/HoverTests.cpp
===
--- clang-tools-extra/clangd/unittests/HoverTests.cpp
+++ clang-tools-extra/clangd/unittests/HoverTests.cpp
@@ -900,6 +900,27 @@
  HI.CalleeArgInfo->Type = "int &";
  HI.CallPassType = HoverInfo::PassType{PassMode::Ref, false};
}},
+  {
+  R"cpp(
+  void foobar(const float &arg);
+  int main() {
+int a = 0;
+foobar([[^a]]);
+  }
+  )cpp",
+  [](HoverInfo &HI) {
+HI.Name = "a";
+HI.Kind = index::SymbolKind::Variable;
+HI.NamespaceScope = "";
+HI.Definition = "int a = 0";
+HI.LocalScope = "main::";
+HI.Value = "0";
+HI.Type = "int";
+HI.CalleeArgInfo.emplace();
+HI.CalleeArgInfo->Name = "arg";
+HI.CalleeArgInfo->Type = "const float &";
+HI.CallPassType = HoverInfo::PassType{PassMode::Value, true};
+  }},
   {// Literal passed to function call
R"cpp(
   void fun(int arg_a, const int &arg_b) {};
@@ -934,6 +955,38 @@
  HI.CalleeArgInfo->Type = "const int &";
  HI.CallPassType = HoverInfo::PassType{PassMode::ConstRef, false};
}},
+  {
+  R"cpp(
+int add(int lhs, int rhs);
+int main() {
+  add(1 [[^+]] 2, 3);
+}
+)cpp",
+  [](HoverInfo &HI) {
+HI.Name = "expression";
+HI.Kind = index::SymbolKind::Unknown;
+HI.Type = "int";
+HI.Value = "3";
+HI.CalleeArgInfo.emplace();
+HI.CalleeArgInfo->Name = "lhs";
+HI.CalleeArgInfo->Type = "int";
+HI.CallPassType = HoverInfo::PassType{PassMode::Value, false};
+  }},
+  {
+  R"cpp(
+void foobar(const float &arg);
+int main() {
+  foobar([[^0]]);
+}
+)cpp",
+  [](HoverInfo &HI) {
+HI.Name = "literal";
+HI.Kind = index::SymbolKind::Unknown;
+HI.CalleeArgInfo.emplace();
+HI.CalleeArgInfo->Name = "arg";
+HI.CalleeArgInfo->Type = "const float &";
+HI.CallPassType = HoverInfo::PassType{PassMode::Value, true};
+  }},
   {// Extra info for method call.
R"cpp(
   class C {
@@ -960,6 +1013,29 @@
  HI.CalleeArgInfo->Default = "3";
  HI.CallPassType = HoverInfo::PassType{PassMode::Value, false};
}},
+  {
+  R"cpp(
+  struct Foo {
+Foo(const int &);
+  };
+  void foo(Foo);
+  void bar() {
+const int x = 0;
+foo([[^x]]);
+  }
+   )cpp",
+  [](HoverInfo &HI) {
+HI.Name = "x";
+HI.Kind = index::SymbolKind::Variable;
+HI.NamespaceScope = "";
+HI.Definition = "const int x = 0";
+HI.LocalScope = "bar::";
+HI.Value = "0";
+HI.Type = "const int";
+HI.CalleeArgInfo.emplace();
+HI.CalleeArgInfo->Type = "Foo";
+HI.CallPassType = HoverInfo::PassType{PassMode::ConstRef, true};
+  }},
   {// Dont crash on invalid decl
R"cpp(
 // error-ok
@@ -1673,8 +1749,8 @@
   }},
   {
   R"cpp(// Function definition via using declaration
-namespace ns { 
-  void foo(); 
+namespace ns {
+  void foo();
 }
 int main() {
   using ns::foo;
Index: clang-tools-extra/clangd/Hover.cpp
===
--- clang-tools-extra/clangd/Hover.cpp
+++ clang-tools-extra/clangd/Hover.cpp
@@ -952,6 +952,15 @@
   }
 }
 
+HoverInfo::PassType::PassMode getPassMode(QualType ParmType) {
+  if (ParmType->isReferenceType()) {
+if (ParmType->getPointeeType().isConstQualified())
+  return HoverInfo::PassType::ConstRef;
+return HoverInfo::PassType::Ref;
+  }
+  return HoverInfo::PassType::Value;
+}
+
 // If N is passed as argument to a function, fill HI.CalleeArgInfo with
 // information about that argument.
 void maybeAddCalleeArgInfo(const SelectionTree::Node *N, HoverInfo &HI,
@@ -972,14 +981,19 @@
   if (!FD || FD->isOverloadedOperator() || FD->isVariadic())
 return;
 
+  HoverInfo::PassType PassType;
+
   // Find argument index for N.
   for (unsigned I = 0; I < CE->getNumArgs() && I < FD->getNumParams(); ++I) {
 if (CE->getArg(I) 

[PATCH] D124351: [Clang] Implement Change scope of lambda trailing-return-type

2023-01-31 Thread Nikita Popov via Phabricator via cfe-commits
nikic added a comment.

FYI this causes a minor compile-time regression (around 0.35% on 7zip at `O0`): 
http://llvm-compile-time-tracker.com/compare.php?from=cd173cbd7cca69c29df42cd4b42e60433435c29b&to=d708a186b6a9b050d09558163dd353d9f738c82d&stat=instructions%3Au

Just wanted to check whether that's expected.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124351

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


  1   2   3   >