[PATCH] D124866: [CUDA][HIP] support __noinline__ as keyword

[Dan Liew via Phabricator via cfe-commits]

delcypher added inline comments.



Comment at: clang/lib/Basic/IdentifierTable.cpp:111
 KEYSYCL   = 0x100,
+KEYCUDA   = 0x200,
 KEYALLCXX = KEYCXX | KEYCXX11 | KEYCXX20,

yaxunl wrote:
> delcypher wrote:
> > @yaxunl Is it intentional that you didn't update `KEYALL` here? That means 
> > `KEYALL` doesn't include the bit for `KEYCUDA`.
> > 
> > If that was your intention then this will break if someone adds a new key. 
> > E.g.
> > 
> > ```
> > KEYCUDA = 0x200,
> > KEYSOMENEWTHING = 0x400,
> > // ...
> > // KEYALL now includes `KEYCUDA`, whereas it didn't before.
> > // KEYALL includes KEYSOMENEWTHING 
> > KEYALL = (0x7ff & ~KEYNOMS18 &
> >   ~KEYNOOPENCL) // KEYNOMS18 and KEYNOOPENCL are used to 
> > exclude.
> > ...
> > ```
> > 
> > 
> > 1. Updating the `0x1ff` constant to `0x3ff` so that `KEYALL` 
> > includes `KEYCUDA`
> > 2. If your intention **is** to not have `KEYCUDA`  set in `KEYALL` then 
> > amend `KEYALL` to be.
> > 
> > ```
> > KEYALL = (0x7ff & ~KEYNOMS18 &
> >   ~KEYNOOPENCL & ~KEYCUDA ) // KEYNOMS18 and KEYNOOPENCL are 
> > used to exclude.
> > // KEYCUDA is not included in KEYALL
> > ```
> My intention is not to include KEYCUDA in KEYALL.
> 
> Should I change KEYALL to
> 
> 
> ```
> KEYALL = (0x3ff & ~KEYNOMS18 &
>   ~KEYNOOPENCL & ~KEYCUDA ) // KEYNOMS18 and KEYNOOPENCL are used 
> to exclude.
> // KEYCUDA is not included in KEYALL
> ```
> 
> instead of 
> 
> 
> ```
> KEYALL = (0x7ff & ~KEYNOMS18 &
>   ~KEYNOOPENCL & ~KEYCUDA ) // KEYNOMS18 and KEYNOOPENCL are used 
> to exclude.
> // KEYCUDA is not included in KEYALL
> ```
> 
> since the current maximum mask is 0x3ff instead of 0x7ff
Oops, you're right it would be `0x3ff`. I wonder though if we should clean 
this up so we don't need to manually update the bit mask every time... what if 
it was written like this?

```lang=c++
 enum {
KEYC99= 0x1,
KEYCXX= 0x2,
KEYCXX11  = 0x4,

KEYSYCL   = 0x100,
KEYCUDA   = 0x200,
KEYMAX = KEYCUDA, // Must be set to the largest KEY enum value
KEYALLCXX = KEYCXX | KEYCXX11 | KEYCXX20,

// KEYNOMS18 and KEYNOOPENCL are used to exclude.
// KEYCUDA is not included in KEYALL because 
KEYALL = (((KEYMAX & (KEYMAX-1)) & ~KEYNOMS18 & ~KEYNOOPENCL & ~KEYCUDA)
};
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124866

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

[PATCH] D124038: [clang] Prevent folding of non-const compound expr

[serge via Phabricator via cfe-commits]

serge-sans-paille updated this revision to Diff 428562.
serge-sans-paille added a comment.

Update GCC manual quote


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

https://reviews.llvm.org/D124038

Files:
  clang/lib/AST/ExprConstant.cpp
  clang/test/SemaCXX/constant-expression-cxx11.cpp
  clang/test/SemaTemplate/constexpr-instantiate.cpp


Index: clang/test/SemaTemplate/constexpr-instantiate.cpp
===
--- clang/test/SemaTemplate/constexpr-instantiate.cpp
+++ clang/test/SemaTemplate/constexpr-instantiate.cpp
@@ -219,7 +219,9 @@
   static int n;
 };
 template struct B {};
-template constexpr int A::k = *(int[N]){N}; // expected-error 
1+{{negative}}
+template  constexpr int A::k = *(int[N]){N}; // expected-error 
1+{{negative}} expected-note 1+{{not valid in a constant expression}} 
expected-note 1+{{declared here}}
+// expected-error@-1 1+{{must be initialized by a constant expression}}
+
 template int A::n = *(int[N]){0};
 
 template  void f() {
@@ -230,9 +232,9 @@
 };
 
 decltype(A<-3>::k) d1 = 0; // ok
-decltype(char{A<-4>::k}) d2 = 0; // expected-note {{instantiation of }} 
expected-error {{narrow}} expected-note {{cast}}
-decltype(char{A<1>::k}) d3 = 0; // ok
-decltype(char{A<1 + (unsigned char)-1>::k}) d4 = 0; // expected-error 
{{narrow}} expected-note {{cast}}
+decltype(char{A<-4>::k}) d2 = 0;// expected-note 
1+{{instantiation of }} expected-error {{narrow}} expected-note {{cast}}
+decltype(char{A<1>::k}) d3 = 0; // expected-note 
1+{{instantiation of }} expected-error {{narrow}} expected-note {{cast}}
+decltype(char{A<1 + (unsigned char)-1>::k}) d4 = 0; // expected-error 
{{narrow}} expected-note {{cast}}  expected-note {{instantiation of}}
   }
 }
 
Index: clang/test/SemaCXX/constant-expression-cxx11.cpp
===
--- clang/test/SemaCXX/constant-expression-cxx11.cpp
+++ clang/test/SemaCXX/constant-expression-cxx11.cpp
@@ -1596,8 +1596,13 @@
   // Matching GCC, file-scope array compound literals initialized by constants
   // are lifetime-extended.
   constexpr int *p = (int*)(int[1]){3}; // expected-warning {{C99}}
-  static_assert(*p == 3, "");
+  static_assert(*p == 3, "");   // expected-error {{static_assert 
expression is not an integral constant expression}}
+// expected-note@-1 {{subexpression 
not valid}}
+// expected-note@-3 {{declared here}}
   static_assert((int[2]){1, 2}[1] == 2, ""); // expected-warning {{C99}}
+  // expected-error@-1 {{static_assert expression is not an integral constant 
expression}}
+  // expected-note@-2 {{subexpression not valid}}
+  // expected-note@-3 {{declared here}}
 
   // Other kinds are not.
   struct X { int a[2]; };
Index: clang/lib/AST/ExprConstant.cpp
===
--- clang/lib/AST/ExprConstant.cpp
+++ clang/lib/AST/ExprConstant.cpp
@@ -4259,9 +4259,28 @@
 Info.FFDiag(Conv);
 return false;
   }
+
   APValue Lit;
   if (!Evaluate(Lit, Info, CLE->getInitializer()))
 return false;
+
+  // According to GCC info page:
+  //
+  // 6.28 Compound Literals
+  //
+  // As an optimization, G++ sometimes gives array compound literals longer
+  // lifetimes: when the array either appears outside a function or has a
+  // const-qualified type. If foo and its initializer had elements of type
+  // char *const rather than char *, or if foo were a global variable, the
+  // array would have static storage duration. But it is probably safest
+  // just to avoid the use of array compound literals in C++ code.
+  //
+  // Obey that rule by checking constness for converted array types.
+  QualType CLETy = CLE->getType(); if (CLETy->isArrayType() &&
+  !Type->isArrayType()) { if (!CLETy.isConstant(Info.Ctx)) {
+Info.FFDiag(Conv); Info.Note(CLE->getExprLoc(), 
diag::note_declared_at);
+return false; } }
+
   CompleteObject LitObj(LVal.Base, , Base->getType());
   return extractSubobject(Info, Conv, LitObj, LVal.Designator, RVal, AK);
 } else if (isa(Base) || isa(Base)) {


Index: clang/test/SemaTemplate/constexpr-instantiate.cpp
===
--- clang/test/SemaTemplate/constexpr-instantiate.cpp
+++ clang/test/SemaTemplate/constexpr-instantiate.cpp
@@ -219,7 +219,9 @@
   static int n;
 };
 template struct B {};
-template constexpr int A::k = *(int[N]){N}; // expected-error 1+{{negative}}
+template  constexpr int A::k = *(int[N]){N}; // expected-error 1+{{negative}} expected-note 1+{{not valid in a constant expression}} expected-note 1+{{declared here}}
+// expected-error@-1 1+{{must be 

[PATCH] D125318: [analyzer] Add UnarySymExpr

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added a comment.

Looks great!

I suspect you'll catch a few crashes/assertion failures if you run this on 
real-world code, due to various parts of the static analyzer being startled by 
the new thing, so I really recommend doing this.




Comment at: 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/SymbolManager.h:338
+
+  void dumpToStream(raw_ostream ) const override;
+

`LLVM_DUMP_METHOD`?



Comment at: clang/lib/StaticAnalyzer/Core/SValBuilder.cpp:104
+   QualType type) {
+  assert(operand);
+  assert(!Loc::isLocType(type));

steakhal wrote:
> I think we should assert that we expect only `UO_Minus` (-), `UO_Not` (~).
> The rest of the `UO_*` doesn't seem to be relevant anyway: PostInc, PostDec, 
> PreInc, PreDec, AddrOf, Deref, Plus, LNot, Real, Imag, Extension, Coawait.
Actually, let's put such assertion in the constructor. The earlier we catch the 
problem the better.



Comment at: clang/lib/StaticAnalyzer/Core/SymbolManager.cpp:493
+  case SymExpr::UnarySymExprKind:
+KnownLive = isLive(cast(sym)->getOperand());
+break;

Excellent!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125318

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

[PATCH] D125350: [RFC][Clang] Add a check if the target supports atomicrmw instruction with specific operator and type

[Shilei Tian via Phabricator via cfe-commits]

tianshilei1992 added a comment.

As for the test, here is a simple code snippet:

  #pragma omp begin declare target device_type(nohost)
  void foo() {
double x, y;
  #pragma omp atomic update
x += y;
  }
  #pragma omp end declare target

`sm_35` doesn't support `FAdd` with `double` type, then it emits:

  define protected void @foo() #0 {
  entry:
%x = alloca double, align 8
%y = alloca double, align 8
%atomic-temp = alloca double, align 8
%0 = load double, ptr %y, align 8
%atomic-load = load atomic i64, ptr %x monotonic, align 8
br label %atomic_cont
  
  atomic_cont:  ; preds = %atomic_cont, 
%entry
%1 = phi i64 [ %atomic-load, %entry ], [ %5, %atomic_cont ]
%2 = bitcast i64 %1 to double
%add = fadd double %2, %0
store double %add, ptr %atomic-temp, align 8
%3 = load i64, ptr %atomic-temp, align 8
%4 = cmpxchg ptr %x, i64 %1, i64 %3 monotonic monotonic, align 8
%5 = extractvalue { i64, i1 } %4, 0
%6 = extractvalue { i64, i1 } %4, 1
br i1 %6, label %atomic_exit, label %atomic_cont
  
  atomic_exit:  ; preds = %atomic_cont
ret void
  }

Starting from `sm_60`, it is supported, now we emits:

  define protected void @foo() #0 {
  entry:
%x = alloca double, align 8
%y = alloca double, align 8
%0 = load double, ptr %y, align 8
%1 = atomicrmw fadd ptr %x, double %0 monotonic, align 8
ret void
  }


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125350

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

[PATCH] D125350: [PoC][Clang] Add a check if the target supports atomicrmw instruction with specific operator and type

[Shilei Tian via Phabricator via cfe-commits]

tianshilei1992 added inline comments.



Comment at: clang/lib/Basic/Targets/NVPTX.cpp:311
+}
+return false;
+  }

`llvm_unreachable` might be more appropriate here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125350

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

[PATCH] D125350: [PoC][Clang] Add a check if the target supports atomicrmw instruction with specific operator and type

[Shilei Tian via Phabricator via cfe-commits]

tianshilei1992 added a comment.

Feel free to add more reviewers


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125350

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

[PATCH] D125350: [PoC][Clang] Add a check if the target supports atomicrmw instruction with specific operator and type

[Shilei Tian via Phabricator via cfe-commits]

tianshilei1992 created this revision.
tianshilei1992 added reviewers: jdoerfert, ABataev.
Herald added subscribers: mattd, gchakrabarti, asavonic, jholewinski.
Herald added a project: All.
tianshilei1992 requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

With respect of `atomicrmw` instruction, different targets have different
backend support. The front end can always emit the intruction, but when it comes
to the backend, the compiler could crash at instruction selection because the
target doesn't support the instruction/operator at all. Currently we don't have
a way in the front end to tell if an `atomicrmw` with specific operator and type
is supported. This patch adds a virtual function `hasAtomicrmw` to the class
`TargetInfo` and it is expected to be implemented by all targets accordingly.
In this way, we can always try to emit `atomicrmw` first because it has better
performance than falling back to CAS loop. Currently at the PoC stage, I only 
make
it in NVPTX, but if the community is happy with this change, I'll add to all the
targets.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D125350

Files:
  clang/include/clang/Basic/TargetInfo.h
  clang/lib/Basic/Targets/NVPTX.cpp
  clang/lib/Basic/Targets/NVPTX.h
  clang/lib/CodeGen/CGStmtOpenMP.cpp

Index: clang/lib/CodeGen/CGStmtOpenMP.cpp
===
--- clang/lib/CodeGen/CGStmtOpenMP.cpp
+++ clang/lib/CodeGen/CGStmtOpenMP.cpp
@@ -5925,6 +5925,11 @@
   case BO_Comma:
 llvm_unreachable("Unsupported atomic update operation");
   }
+
+  if (!Context.getTargetInfo().hasAtomicrmw(RMWOp,
+X.getAddress(CGF).getElementType()))
+return std::make_pair(false, RValue::get(nullptr));
+
   llvm::Value *UpdateVal = Update.getScalarVal();
   if (auto *IC = dyn_cast(UpdateVal)) {
 if (IsInteger)
Index: clang/lib/Basic/Targets/NVPTX.h
===
--- clang/lib/Basic/Targets/NVPTX.h
+++ clang/lib/Basic/Targets/NVPTX.h
@@ -17,6 +17,7 @@
 #include "clang/Basic/TargetInfo.h"
 #include "clang/Basic/TargetOptions.h"
 #include "llvm/ADT/Triple.h"
+#include "llvm/IR/Instructions.h"
 #include "llvm/Support/Compiler.h"
 
 namespace clang {
@@ -176,6 +177,8 @@
   }
 
   bool hasBitIntType() const override { return true; }
+
+  bool hasAtomicrmw(llvm::AtomicRMWInst::BinOp, llvm::Type *) const override;
 };
 } // namespace targets
 } // namespace clang
Index: clang/lib/Basic/Targets/NVPTX.cpp
===
--- clang/lib/Basic/Targets/NVPTX.cpp
+++ clang/lib/Basic/Targets/NVPTX.cpp
@@ -273,3 +273,43 @@
   return llvm::makeArrayRef(BuiltinInfo, clang::NVPTX::LastTSBuiltin -
  Builtin::FirstTSBuiltin);
 }
+
+bool NVPTXTargetInfo::hasAtomicrmw(llvm::AtomicRMWInst::BinOp Op,
+   llvm::Type *Ty) const {
+  switch (Op) {
+  default:
+llvm_unreachable("bad binop");
+  case llvm::AtomicRMWInst::BinOp::FSub:
+  case llvm::AtomicRMWInst::BinOp::Nand:
+return false;
+  case llvm::AtomicRMWInst::BinOp::FAdd:
+assert(Ty->isFloatingPointTy());
+if (Ty->isFloatTy())
+  return true;
+if (Ty->isDoubleTy() && GPU >= CudaArch::SM_60)
+  return true;
+return false;
+  case llvm::AtomicRMWInst::BinOp::Add:
+  case llvm::AtomicRMWInst::BinOp::Sub:
+  case llvm::AtomicRMWInst::BinOp::Max:
+  case llvm::AtomicRMWInst::BinOp::Min:
+  case llvm::AtomicRMWInst::BinOp::UMax:
+  case llvm::AtomicRMWInst::BinOp::UMin:
+  case llvm::AtomicRMWInst::BinOp::Xchg:
+  case llvm::AtomicRMWInst::BinOp::And:
+  case llvm::AtomicRMWInst::BinOp::Or:
+  case llvm::AtomicRMWInst::BinOp::Xor:
+assert(Ty->isIntegerTy());
+switch (cast(Ty)->getBitWidth()) {
+case 32:
+  return true;
+case 64:
+  return true;
+default:
+  return false;
+}
+return false;
+  }
+
+  return false;
+}
Index: clang/include/clang/Basic/TargetInfo.h
===
--- clang/include/clang/Basic/TargetInfo.h
+++ clang/include/clang/Basic/TargetInfo.h
@@ -31,6 +31,7 @@
 #include "llvm/ADT/StringRef.h"
 #include "llvm/ADT/Triple.h"
 #include "llvm/Frontend/OpenMP/OMPGridValues.h"
+#include "llvm/IR/Instructions.h"
 #include "llvm/Support/DataTypes.h"
 #include "llvm/Support/Error.h"
 #include "llvm/Support/VersionTuple.h"
@@ -756,6 +757,12 @@
 llvm::isPowerOf2_64(AtomicSizeInBits / getCharWidth()));
   }
 
+  /// Returns true if the given target supports atomicrmw with given operator
+  /// and type.
+  virtual bool hasAtomicrmw(llvm::AtomicRMWInst::BinOp, llvm::Type *) const {
+llvm_unreachable("hasAtomicrmw not implemented on this target");
+  }
+
   /// Return the maximum vector alignment supported for the given target.
   unsigned getMaxVectorAlign() 

[PATCH] D124866: [CUDA][HIP] support __noinline__ as keyword

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl added inline comments.



Comment at: clang/lib/Basic/IdentifierTable.cpp:111
 KEYSYCL   = 0x100,
+KEYCUDA   = 0x200,
 KEYALLCXX = KEYCXX | KEYCXX11 | KEYCXX20,

delcypher wrote:
> @yaxunl Is it intentional that you didn't update `KEYALL` here? That means 
> `KEYALL` doesn't include the bit for `KEYCUDA`.
> 
> If that was your intention then this will break if someone adds a new key. 
> E.g.
> 
> ```
> KEYCUDA = 0x200,
> KEYSOMENEWTHING = 0x400,
> // ...
> // KEYALL now includes `KEYCUDA`, whereas it didn't before.
> // KEYALL includes KEYSOMENEWTHING 
> KEYALL = (0x7ff & ~KEYNOMS18 &
>   ~KEYNOOPENCL) // KEYNOMS18 and KEYNOOPENCL are used to exclude.
> ...
> ```
> 
> 
> 1. Updating the `0x1ff` constant to `0x3ff` so that `KEYALL` includes 
> `KEYCUDA`
> 2. If your intention **is** to not have `KEYCUDA`  set in `KEYALL` then amend 
> `KEYALL` to be.
> 
> ```
> KEYALL = (0x7ff & ~KEYNOMS18 &
>   ~KEYNOOPENCL & ~KEYCUDA ) // KEYNOMS18 and KEYNOOPENCL are used 
> to exclude.
> // KEYCUDA is not included in KEYALL
> ```
My intention is not to include KEYCUDA in KEYALL.

Should I change KEYALL to


```
KEYALL = (0x3ff & ~KEYNOMS18 &
  ~KEYNOOPENCL & ~KEYCUDA ) // KEYNOMS18 and KEYNOOPENCL are used 
to exclude.
// KEYCUDA is not included in KEYALL
```

instead of 


```
KEYALL = (0x7ff & ~KEYNOMS18 &
  ~KEYNOOPENCL & ~KEYCUDA ) // KEYNOMS18 and KEYNOOPENCL are used 
to exclude.
// KEYCUDA is not included in KEYALL
```

since the current maximum mask is 0x3ff instead of 0x7ff


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124866

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

[PATCH] D125323: [RISCV] Add the passthru operand for RVV unmasked segment load IR intrinsics.

[Craig Topper via Phabricator via cfe-commits]

craig.topper added inline comments.



Comment at: clang/include/clang/Basic/riscv_vector.td:879
+  // intrinsic: (passthru0, passthru1, ..., ptr, vl)
+  SmallVector Operands;
+  for (unsigned I = 0; I < NF; ++I)

Why 12? NF is at most 8 right? And then 2 additional operands?



Comment at: llvm/lib/Target/RISCV/RISCVISelDAGToDAG.cpp:314
 
+static bool IsAllUndef(ArrayRef Values) {
+  for (auto  : Values) {

IsAllUndef -> isAllUndef



Comment at: llvm/lib/Target/RISCV/RISCVISelDAGToDAG.cpp:315
+static bool IsAllUndef(ArrayRef Values) {
+  for (auto  : Values) {
+if (!Value->isUndef())

return llvm::all_of(Value, [](SDValue V) { return V->isUndef(); });



Comment at: llvm/lib/Target/RISCV/RISCVISelLowering.cpp:4920
 SDVTList VTs = DAG.getVTList(ContainerVTs);
+SmallVector Ops = {Load->getChain(), IntID};
+Ops.insert(Ops.end(), NF, DAG.getUNDEF(ContainerVT));

9 seems too low. Should be 12?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125323

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

[PATCH] D125203: [PowerPC] Fix PPCISD::STBRX selection issue on A2

[Ting Wang 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 rG289236d597a2: [PowerPC] Fix PPCISD::STBRX selection issue on 
A2 (authored by tingwang).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125203

Files:
  clang/lib/Basic/Targets/PPC.cpp
  clang/test/Driver/ppc-isa-features.cpp
  llvm/lib/Target/PowerPC/PPC.td
  llvm/test/CodeGen/PowerPC/bswap-load-store.ll

Index: llvm/test/CodeGen/PowerPC/bswap-load-store.ll
===
--- llvm/test/CodeGen/PowerPC/bswap-load-store.ll
+++ llvm/test/CodeGen/PowerPC/bswap-load-store.ll
@@ -3,6 +3,7 @@
 ; RUN: llc -ppc-asm-full-reg-names -verify-machineinstrs < %s -mtriple=ppc32-- -mcpu=pwr7  | FileCheck %s --check-prefixes=X32,PWR7_32
 ; RUN: llc -ppc-asm-full-reg-names -verify-machineinstrs < %s -mtriple=powerpc64-- -mcpu=ppc64 | FileCheck %s --check-prefixes=X64
 ; RUN: llc -ppc-asm-full-reg-names -verify-machineinstrs < %s -mtriple=powerpc64-- -mcpu=pwr7  | FileCheck %s --check-prefixes=PWR7_64
+; RUN: llc -ppc-asm-full-reg-names -verify-machineinstrs < %s -mtriple=powerpc64-- -mcpu=a2| FileCheck %s --check-prefixes=A2_64
 
 
 define void @STWBRX(i32 %i, i8* %ptr, i32 %off) {
@@ -22,6 +23,12 @@
 ; PWR7_64-NEXT:extsw r5, r5
 ; PWR7_64-NEXT:stwbrx r3, r4, r5
 ; PWR7_64-NEXT:blr
+;
+; A2_64-LABEL: STWBRX:
+; A2_64:   # %bb.0:
+; A2_64-NEXT:extsw r5, r5
+; A2_64-NEXT:stwbrx r3, r4, r5
+; A2_64-NEXT:blr
   %tmp1 = getelementptr i8, i8* %ptr, i32 %off
   %tmp1.upgrd.1 = bitcast i8* %tmp1 to i32*
   %tmp13 = tail call i32 @llvm.bswap.i32( i32 %i )
@@ -46,6 +53,12 @@
 ; PWR7_64-NEXT:extsw r4, r4
 ; PWR7_64-NEXT:lwbrx r3, r3, r4
 ; PWR7_64-NEXT:blr
+;
+; A2_64-LABEL: LWBRX:
+; A2_64:   # %bb.0:
+; A2_64-NEXT:extsw r4, r4
+; A2_64-NEXT:lwbrx r3, r3, r4
+; A2_64-NEXT:blr
   %tmp1 = getelementptr i8, i8* %ptr, i32 %off
   %tmp1.upgrd.2 = bitcast i8* %tmp1 to i32*
   %tmp = load i32, i32* %tmp1.upgrd.2
@@ -70,6 +83,12 @@
 ; PWR7_64-NEXT:extsw r5, r5
 ; PWR7_64-NEXT:sthbrx r3, r4, r5
 ; PWR7_64-NEXT:blr
+;
+; A2_64-LABEL: STHBRX:
+; A2_64:   # %bb.0:
+; A2_64-NEXT:extsw r5, r5
+; A2_64-NEXT:sthbrx r3, r4, r5
+; A2_64-NEXT:blr
   %tmp1 = getelementptr i8, i8* %ptr, i32 %off
   %tmp1.upgrd.3 = bitcast i8* %tmp1 to i16*
   %tmp5 = call i16 @llvm.bswap.i16( i16 %s )
@@ -94,6 +113,12 @@
 ; PWR7_64-NEXT:extsw r4, r4
 ; PWR7_64-NEXT:lhbrx r3, r3, r4
 ; PWR7_64-NEXT:blr
+;
+; A2_64-LABEL: LHBRX:
+; A2_64:   # %bb.0:
+; A2_64-NEXT:extsw r4, r4
+; A2_64-NEXT:lhbrx r3, r3, r4
+; A2_64-NEXT:blr
   %tmp1 = getelementptr i8, i8* %ptr, i32 %off
   %tmp1.upgrd.4 = bitcast i8* %tmp1 to i16*
   %tmp = load i16, i16* %tmp1.upgrd.4
@@ -133,6 +158,11 @@
 ; PWR7_64:   # %bb.0:
 ; PWR7_64-NEXT:stdbrx r3, r4, r5
 ; PWR7_64-NEXT:blr
+;
+; A2_64-LABEL: STDBRX:
+; A2_64:   # %bb.0:
+; A2_64-NEXT:stdbrx r3, r4, r5
+; A2_64-NEXT:blr
   %tmp1 = getelementptr i8, i8* %ptr, i64 %off
   %tmp1.upgrd.1 = bitcast i8* %tmp1 to i64*
   %tmp13 = tail call i64 @llvm.bswap.i64( i64 %i )
@@ -163,6 +193,11 @@
 ; PWR7_64:   # %bb.0:
 ; PWR7_64-NEXT:ldbrx r3, r3, r4
 ; PWR7_64-NEXT:blr
+;
+; A2_64-LABEL: LDBRX:
+; A2_64:   # %bb.0:
+; A2_64-NEXT:ldbrx r3, r3, r4
+; A2_64-NEXT:blr
   %tmp1 = getelementptr i8, i8* %ptr, i64 %off
   %tmp1.upgrd.2 = bitcast i8* %tmp1 to i64*
   %tmp = load i64, i64* %tmp1.upgrd.2
Index: llvm/lib/Target/PowerPC/PPC.td
===
--- llvm/lib/Target/PowerPC/PPC.td
+++ llvm/lib/Target/PowerPC/PPC.td
@@ -592,7 +592,8 @@
FeatureSTFIWX, FeatureLFIWAX,
FeatureFPRND, FeatureFPCVT, FeatureISEL,
FeatureSlowPOPCNTD, FeatureCMPB, FeatureLDBRX,
-   Feature64Bit /*, Feature64BitRegs */, FeatureMFTB]>;
+   Feature64Bit /*, Feature64BitRegs */, FeatureMFTB,
+   FeatureISA2_06]>;
 def : ProcessorModel<"pwr3", G5Model,
   [DirectivePwr3, FeatureAltivec,
FeatureFRES, FeatureFRSQRTE, FeatureMFOCRF,
Index: clang/test/Driver/ppc-isa-features.cpp
===
--- clang/test/Driver/ppc-isa-features.cpp
+++ clang/test/Driver/ppc-isa-features.cpp
@@ -1,4 +1,5 @@
 // RUN: %clang -target powerpc64-unknown-unknown -mcpu=pwr6 -S -emit-llvm %s -o - | FileCheck %s -check-prefix=CHECK-PWR6
+// RUN: %clang -target powerpc64-unknown-unknown -mcpu=a2 -S -emit-llvm %s -o - | FileCheck %s -check-prefix=CHECK-A2
 // RUN: %clang -target powerpc64-unknown-unknown -mcpu=pwr7 -S -emit-llvm %s -o - | FileCheck %s -check-prefix=CHECK-PWR7
 // RUN: %clang -target powerpc64le-unknown-unknown 

[clang] 289236d - [PowerPC] Fix PPCISD::STBRX selection issue on A2

[Ting Wang via cfe-commits]

Author: Ting Wang
Date: 2022-05-10T20:47:51-04:00
New Revision: 289236d597a228484dfd9607da6889603b9210a8

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

LOG: [PowerPC] Fix PPCISD::STBRX selection issue on A2

Enable FeatureISA2_06 on Power A2 target

Reviewed By: nemanjai

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

Added: 


Modified: 
clang/lib/Basic/Targets/PPC.cpp
clang/test/Driver/ppc-isa-features.cpp
llvm/lib/Target/PowerPC/PPC.td
llvm/test/CodeGen/PowerPC/bswap-load-store.ll

Removed: 




diff  --git a/clang/lib/Basic/Targets/PPC.cpp b/clang/lib/Basic/Targets/PPC.cpp
index a2e50f37d854f..dacb7eeea12a8 100644
--- a/clang/lib/Basic/Targets/PPC.cpp
+++ b/clang/lib/Basic/Targets/PPC.cpp
@@ -549,6 +549,7 @@ bool PPCTargetInfo::initFeatureMap(
   .Case("pwr9", true)
   .Case("pwr8", true)
   .Case("pwr7", true)
+  .Case("a2", true)
   .Default(false);
 
   Features["isa-v207-instructions"] = llvm::StringSwitch(CPU)

diff  --git a/clang/test/Driver/ppc-isa-features.cpp 
b/clang/test/Driver/ppc-isa-features.cpp
index 87a3a808e012f..92c5bc82f72b8 100644
--- a/clang/test/Driver/ppc-isa-features.cpp
+++ b/clang/test/Driver/ppc-isa-features.cpp
@@ -1,4 +1,5 @@
 // RUN: %clang -target powerpc64-unknown-unknown -mcpu=pwr6 -S -emit-llvm %s 
-o - | FileCheck %s -check-prefix=CHECK-PWR6
+// RUN: %clang -target powerpc64-unknown-unknown -mcpu=a2 -S -emit-llvm %s -o 
- | FileCheck %s -check-prefix=CHECK-A2
 // RUN: %clang -target powerpc64-unknown-unknown -mcpu=pwr7 -S -emit-llvm %s 
-o - | FileCheck %s -check-prefix=CHECK-PWR7
 // RUN: %clang -target powerpc64le-unknown-unknown -mcpu=pwr8 -S -emit-llvm %s 
-o - | FileCheck %s -check-prefix=CHECK-PWR8
 // RUN: %clang -target powerpc64-unknown-aix -mcpu=pwr9 -S -emit-llvm %s -o - 
| FileCheck %s -check-prefix=CHECK-PWR9
@@ -8,6 +9,10 @@
 // CHECK-PWR6: -isa-v207-instructions
 // CHECK-PWR6: -isa-v30-instructions
 
+// CHECK-A2: +isa-v206-instructions
+// CHECK-A2: -isa-v207-instructions
+// CHECK-A2: -isa-v30-instructions
+
 // CHECK-PWR7: +isa-v206-instructions
 // CHECK-PWR7: -isa-v207-instructions
 // CHECK-PWR7: -isa-v30-instructions

diff  --git a/llvm/lib/Target/PowerPC/PPC.td b/llvm/lib/Target/PowerPC/PPC.td
index 44a323df34614..15c149df5abeb 100644
--- a/llvm/lib/Target/PowerPC/PPC.td
+++ b/llvm/lib/Target/PowerPC/PPC.td
@@ -592,7 +592,8 @@ def : ProcessorModel<"a2", PPCA2Model,
FeatureSTFIWX, FeatureLFIWAX,
FeatureFPRND, FeatureFPCVT, FeatureISEL,
FeatureSlowPOPCNTD, FeatureCMPB, FeatureLDBRX,
-   Feature64Bit /*, Feature64BitRegs */, FeatureMFTB]>;
+   Feature64Bit /*, Feature64BitRegs */, FeatureMFTB,
+   FeatureISA2_06]>;
 def : ProcessorModel<"pwr3", G5Model,
   [DirectivePwr3, FeatureAltivec,
FeatureFRES, FeatureFRSQRTE, FeatureMFOCRF,

diff  --git a/llvm/test/CodeGen/PowerPC/bswap-load-store.ll 
b/llvm/test/CodeGen/PowerPC/bswap-load-store.ll
index 0c9b7a7094517..ecd29aa0d6317 100644
--- a/llvm/test/CodeGen/PowerPC/bswap-load-store.ll
+++ b/llvm/test/CodeGen/PowerPC/bswap-load-store.ll
@@ -3,6 +3,7 @@
 ; RUN: llc -ppc-asm-full-reg-names -verify-machineinstrs < %s -mtriple=ppc32-- 
-mcpu=pwr7  | FileCheck %s --check-prefixes=X32,PWR7_32
 ; RUN: llc -ppc-asm-full-reg-names -verify-machineinstrs < %s 
-mtriple=powerpc64-- -mcpu=ppc64 | FileCheck %s --check-prefixes=X64
 ; RUN: llc -ppc-asm-full-reg-names -verify-machineinstrs < %s 
-mtriple=powerpc64-- -mcpu=pwr7  | FileCheck %s --check-prefixes=PWR7_64
+; RUN: llc -ppc-asm-full-reg-names -verify-machineinstrs < %s 
-mtriple=powerpc64-- -mcpu=a2| FileCheck %s --check-prefixes=A2_64
 
 
 define void @STWBRX(i32 %i, i8* %ptr, i32 %off) {
@@ -22,6 +23,12 @@ define void @STWBRX(i32 %i, i8* %ptr, i32 %off) {
 ; PWR7_64-NEXT:extsw r5, r5
 ; PWR7_64-NEXT:stwbrx r3, r4, r5
 ; PWR7_64-NEXT:blr
+;
+; A2_64-LABEL: STWBRX:
+; A2_64:   # %bb.0:
+; A2_64-NEXT:extsw r5, r5
+; A2_64-NEXT:stwbrx r3, r4, r5
+; A2_64-NEXT:blr
   %tmp1 = getelementptr i8, i8* %ptr, i32 %off
   %tmp1.upgrd.1 = bitcast i8* %tmp1 to i32*
   %tmp13 = tail call i32 @llvm.bswap.i32( i32 %i )
@@ -46,6 +53,12 @@ define i32 @LWBRX(i8* %ptr, i32 %off) {
 ; PWR7_64-NEXT:extsw r4, r4
 ; PWR7_64-NEXT:lwbrx r3, r3, r4
 ; PWR7_64-NEXT:blr
+;
+; A2_64-LABEL: LWBRX:
+; A2_64:   # %bb.0:
+; A2_64-NEXT:extsw r4, r4
+; A2_64-NEXT:lwbrx r3, r3, r4
+; A2_64-NEXT:blr
   %tmp1 = getelementptr i8, i8* %ptr, i32 

[PATCH] D124866: [CUDA][HIP] support __noinline__ as keyword

[Dan Liew via Phabricator via cfe-commits]

delcypher added inline comments.



Comment at: clang/lib/Basic/IdentifierTable.cpp:111
 KEYSYCL   = 0x100,
+KEYCUDA   = 0x200,
 KEYALLCXX = KEYCXX | KEYCXX11 | KEYCXX20,

@yaxunl Is it intentional that you didn't update `KEYALL` here? That means 
`KEYALL` doesn't include the bit for `KEYCUDA`.

If that was your intention then this will break if someone adds a new key. E.g.

```
KEYCUDA = 0x200,
KEYSOMENEWTHING = 0x400,
// ...
// KEYALL now includes `KEYCUDA`, whereas it didn't before.
// KEYALL includes KEYSOMENEWTHING 
KEYALL = (0x7ff & ~KEYNOMS18 &
  ~KEYNOOPENCL) // KEYNOMS18 and KEYNOOPENCL are used to exclude.
...
```


1. Updating the `0x1ff` constant to `0x3ff` so that `KEYALL` includes 
`KEYCUDA`
2. If your intention **is** to not have `KEYCUDA`  set in `KEYALL` then amend 
`KEYALL` to be.

```
KEYALL = (0x7ff & ~KEYNOMS18 &
  ~KEYNOOPENCL & ~KEYCUDA ) // KEYNOMS18 and KEYNOOPENCL are used 
to exclude.
// KEYCUDA is not included in KEYALL
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124866

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

[PATCH] D123538: [symbolizer] Parse DW_TAG_variable DIs to show line info for globals

[Mitch Phillips via Phabricator via cfe-commits]

hctim added inline comments.



Comment at: llvm/test/tools/llvm-symbolizer/data-location.s:7
+
+# CHECK:  x
+# CHECK-NEXT: 14572 4

jhenderson wrote:
> hctim wrote:
> > jhenderson wrote:
> > > hctim wrote:
> > > > jhenderson wrote:
> > > > > It might be useful to add comments about what is special about each 
> > > > > of these cases (i.e. data/bss/function-static/string) or even name 
> > > > > the variables along those lines to directly imply their purpose. That 
> > > > > way, if the test is ever rewritten, it's easy to understand why each 
> > > > > example exists and what is important about it. That being said, is 
> > > > > there actually a difference between them for the testing purposes? 
> > > > > What do they actually exercise in the code changes? (I haven't looked 
> > > > > at the code changes to understand this).
> > > > Renamed them (and made the test less in need of massaging if things 
> > > > change). They're individually useful because they're different types of 
> > > > global variables, located in different places.
> > > > They're individually useful because they're different types of global 
> > > > variables, located in different places.
> > > 
> > > Right, but are they located in differenet places within the DWARF? In 
> > > other words, are any different code paths actually exercised this way?
> > > 
> > > Tangentially related: is one of the cases missing from the debug_aranges, 
> > > so that the fallback code is exercised?
> > > Right, but are they located in differenet places within the DWARF? In 
> > > other words, are any different code paths actually exercised this way?
> > 
> > No, `bss_global` and `data_global` are functionally here. The reason why I 
> > have them both here is because if you compile the source file to an object 
> > rather than a DSO, you end up with bad address lookups because bss_global 
> > and data_global are both at address 0x0 (just in different sections). I 
> > figured this would give some amount of posterity here about why it's a DSO, 
> > I know that I was pretty surprised there wasn't a great way to test it.
> > 
> > Maybe a comment is a better way to go about it. Let me know what you think.
> > 
> > > Tangentially related: is one of the cases missing from the debug_aranges, 
> > > so that the fallback code is exercised?
> > 
> > All of them are missing from the debug_aranges :)
> As things stand, if I came to this test, I'd consider dropping vataiables 
> that appear to be in the same place in the debug info, so a comment is 
> probably needed saying what coverage they provide.
Done, and also made this patch no longer depend on D123534.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123538

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

[PATCH] D123538: [symbolizer] Parse DW_TAG_variable DIs to show line info for globals

[Mitch Phillips via Phabricator via cfe-commits]

hctim updated this revision to Diff 428538.
hctim marked an inline comment as done.
hctim added a comment.

(comment)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123538

Files:
  llvm/include/llvm/DebugInfo/DIContext.h
  llvm/include/llvm/DebugInfo/DWARF/DWARFContext.h
  llvm/include/llvm/DebugInfo/DWARF/DWARFUnit.h
  llvm/include/llvm/DebugInfo/PDB/PDBContext.h
  llvm/lib/DebugInfo/DWARF/DWARFContext.cpp
  llvm/lib/DebugInfo/DWARF/DWARFUnit.cpp
  llvm/lib/DebugInfo/PDB/PDBContext.cpp
  llvm/lib/DebugInfo/Symbolize/DIPrinter.cpp
  llvm/lib/DebugInfo/Symbolize/SymbolizableObjectFile.cpp
  llvm/test/DebugInfo/Symbolize/ELF/data-command-symtab.yaml
  llvm/test/tools/llvm-symbolizer/data-location.yaml
  llvm/test/tools/llvm-symbolizer/data.s

Index: llvm/test/tools/llvm-symbolizer/data.s
===
--- llvm/test/tools/llvm-symbolizer/data.s
+++ llvm/test/tools/llvm-symbolizer/data.s
@@ -7,9 +7,12 @@
 
 # CHECK:  d1
 # CHECK-NEXT: 0 8
+# CHECK-NEXT: ??:?
 # CHECK-EMPTY:
 # CHECK-NEXT: d2
 # CHECK-NEXT: 8 4
+# CHECK-NEXT: ??:?
+# CHECK-EMPTY:
 
 d1:
 .quad 0x1122334455667788
Index: llvm/test/tools/llvm-symbolizer/data-location.yaml
===
--- /dev/null
+++ llvm/test/tools/llvm-symbolizer/data-location.yaml
@@ -0,0 +1,503 @@
+## Show that when "DATA" is used with an address, it forces the found location
+## to be symbolized as data, including the source information.
+
+# RUN: yaml2obj %s -o %t.so
+
+# RUN: llvm-symbolizer "DATA 0x38a4" "DATA 0x3868" "DATA 0x38a0" \
+# RUN:   --obj=%t.so | FileCheck %s
+
+# CHECK:  bss_global
+# CHECK-NEXT: {{[0-9]+}} 4
+# CHECK-NEXT: /tmp/file.c:1
+# CHECK-EMPTY:
+# CHECK-NEXT: data_global
+# CHECK-NEXT: {{[0-9]+}} 4
+# CHECK-NEXT: /tmp/file.c:2
+# CHECK-EMPTY:
+# CHECK-NEXT: f.function_global
+# CHECK-NEXT: {{[0-9]+}} 4
+# CHECK-NEXT: /tmp/file.c:4
+# CHECK-EMPTY:
+
+
+## File below was generated using:
+##   $ clang -g -fuse-ld=lld -shared /tmp/file.c -o out.so && obj2yaml out.so
+## ... with /tmp/file.c:
+##   1: int bss_global;
+##   2: int data_global = 2;
+##   3: void f() {
+##   4:   static int function_global;
+##   5: }
+##   6:
+## ... then, one can get the offsets using `nm`, like:
+##   $ nm out.so | grep bss_global
+## 38fc B bss_global
+##
+## Ideally, this would be tested by invoking clang directly on a C source file,
+## but unfortunately there's no way to do that for LLVM tests. The other option
+## is to compile IR to an objfile, but llvm-symbolizer doesn't understand that
+## two symbols can have the same address in different sections. In the code
+## above, for example, we'd have bss_global at .bss+0x0, and data_global at
+## .data+0x0, and so the symbolizer would only print one of them. Hence, we have
+## the ugly dso-to-yaml blob below.
+##
+## For now, constant strings don't have a debuginfo entry, and so can't be
+## symbolized correctly. In future (if D123534 gets merged), this can be updated
+## to include a check that llvm-symbolizer can also symbolize constant strings,
+## like `const char* string = "123456"` (and &"123456" should be symbolizable)
+## to the specific line. Then, you can find the address of the constant string
+## from the relocation:
+##   $ nm out.so | grep string
+## 38c0 D string
+##   $ llvm-objdump -R out.so | grep 38c0
+## 38c0 R_X86_64_RELATIVE *ABS*+0x4f8 # <-- 0x4f8
+
+
+--- !ELF
+FileHeader:
+  Class:   ELFCLASS64
+  Data:ELFDATA2LSB
+  Type:ET_DYN
+  Machine: EM_X86_64
+ProgramHeaders:
+  - Type:PT_PHDR
+Flags:   [ PF_R ]
+VAddr:   0x40
+Align:   0x8
+  - Type:PT_LOAD
+Flags:   [ PF_R ]
+FirstSec:.dynsym
+LastSec: .eh_frame
+Align:   0x1000
+  - Type:PT_LOAD
+Flags:   [ PF_X, PF_R ]
+FirstSec:.text
+LastSec: .plt
+VAddr:   0x1510
+Align:   0x1000
+  - Type:PT_LOAD
+Flags:   [ PF_W, PF_R ]
+FirstSec:.ctors
+LastSec: .got
+VAddr:   0x26D0
+Align:   0x1000
+  - Type:PT_LOAD
+Flags:   [ PF_W, PF_R ]
+FirstSec:.data
+LastSec: .bss
+VAddr:   0x3860
+Align:   0x1000
+  - Type:PT_DYNAMIC
+Flags:   [ PF_W, PF_R ]
+FirstSec:.dynamic
+LastSec: .dynamic
+VAddr:   0x26F0
+Align:   0x8
+  - Type:PT_GNU_RELRO
+Flags:   [ PF_R ]
+FirstSec:.ctors
+

[PATCH] D124974: [clang] Include clang config.h in LangStandards.cpp

[Cassie Jones via Phabricator via cfe-commits]

porglezomp added a comment.

Ah, so it'd be a test that passes pretty trivially on any bot that doesn't have 
a custom version of `CLANG_DEFAULT_STD_C` and `CLANG_DEFAULT_STD_CXX` like the 
default config, but could get caught by any other bots that do set it?

What's the best way to get the compiler to report the standard it's using for 
this test?

For C++ I can do:

  clang++ -xc++ -dM -E - < /dev/null | grep cplusplus

And it will print e.g.

  #define __cplusplus 199711L

But that requires quite some decoding to compare against 
`CLANG_DEFAULT_STD_CXX` which would look like `LangStandard::lang_gnucxx98`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124974

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

[PATCH] D125011: [MSVC] Add support for pragma alloc_text

[Stephen Long via Phabricator via cfe-commits]

steplong updated this revision to Diff 428536.
steplong added a comment.

- Added Sema tests
- Added checking of c linkage
- Changed some parsing logic in the parser handler e.g #pragma alloc_text(a, 
foo  without the right paren is only a warning


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125011

Files:
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Parse/Parser.h
  clang/include/clang/Sema/Sema.h
  clang/lib/Parse/ParsePragma.cpp
  clang/lib/Sema/SemaAttr.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/test/CodeGen/msvc_pragma_alloc_text.cpp
  clang/test/Sema/pragma-ms-alloc-text.cpp

Index: clang/test/Sema/pragma-ms-alloc-text.cpp
===
--- /dev/null
+++ clang/test/Sema/pragma-ms-alloc-text.cpp
@@ -0,0 +1,35 @@
+// RUN: %clang_cc1 -fms-extensions -fsyntax-only -verify %s
+
+#pragma alloc_text()// expected-warning {{expected a string literal for the section name in '#pragma alloc_text'}}
+#pragma alloc_text(a// expected-warning {{expected ',' in '#pragma alloc_text'}}
+#pragma alloc_text(a, a // expected-warning {{missing ')' after '#pragma alloc_text'}} expected-error {{use of undeclared a}}
+#pragma alloc_text(L"a", a) // expected-warning {{expected a string literal for the section name}}
+
+void foo();
+#pragma alloc_text(a, foo) // expected-error {{'#pragma alloc_text' is applicable only to functions with C linkage}}
+
+extern "C" void foo1();
+#pragma alloc_text(a, foo1)  // no-warning
+#pragma alloc_text(a, foo1) asdf // expected-warning {{extra tokens at end of '#pragma alloc_text'}}
+#pragma alloc_text(a, foo1   // expected-warning {{missing ')' after '#pragma alloc_text'}}
+
+namespace N {
+#pragma alloc_text(b, foo1) // no-warning
+}
+
+extern "C" {
+void foo2();
+#pragma alloc_text(a, foo2) // no-warning
+}
+
+void foo3() {
+#pragma alloc_text(a, foo1) // expected-error {{'#pragma alloc_text' can only appear at file scope}}
+}
+
+extern "C" void foo4();
+#pragma alloc_text(c, foo4) // no-warning
+void foo4() {}
+
+void foo5();// expected-note {{previous declaration is here}}
+#pragma alloc_text(c, foo5) // expected-error {{'#pragma alloc_text' is applicable only to functions with C linkage}}
+extern "C" void foo5() {}   // expected-error {{declaration of 'foo5' has a different language linkage}}
Index: clang/test/CodeGen/msvc_pragma_alloc_text.cpp
===
--- /dev/null
+++ clang/test/CodeGen/msvc_pragma_alloc_text.cpp
@@ -0,0 +1,26 @@
+// RUN: %clang_cc1 -fms-extensions -S -emit-llvm -o - %s | FileCheck %s
+
+extern "C" {
+
+void foo();
+void foo1();
+void foo2();
+void foo3();
+
+#pragma alloc_text("abc", foo, foo1)
+#pragma alloc_text("def", foo2)
+#pragma alloc_text("def", foo3)
+
+// CHECK-LABEL: define{{.*}} void @foo() {{.*}} section "abc"
+void foo() {}
+
+// CHECK-LABEL: define{{.*}} void @foo1() {{.*}} section "abc"
+void foo1() {}
+
+// CHECK-LABEL: define{{.*}} void @foo2() {{.*}} section "def"
+void foo2() {}
+
+// CHECK-LABEL: define{{.*}} void @foo3() {{.*}} section "def"
+void foo3() {}
+
+}
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -10220,8 +10220,10 @@
 
   // If this is a function definition, check if we have to apply optnone due to
   // a pragma.
-  if(D.isFunctionDefinition())
+  if(D.isFunctionDefinition()) {
 AddRangeBasedOptnone(NewFD);
+AddSectionMSAllocText(NewFD);
+  }
 
   // If this is the first declaration of an extern C variable, update
   // the map of such variables.
Index: clang/lib/Sema/SemaAttr.cpp
===
--- clang/lib/Sema/SemaAttr.cpp
+++ clang/lib/Sema/SemaAttr.cpp
@@ -741,6 +741,37 @@
   CurInitSegLoc = PragmaLocation;
 }
 
+void Sema::ActOnPragmaMSAllocText(
+SourceLocation PragmaLocation, StringRef Section,
+const SmallVector>
+) {
+  if (!CurContext->getRedeclContext()->isFileContext()) {
+Diag(PragmaLocation, diag::err_pragma_expected_file_scope) << "alloc_text";
+return;
+  }
+
+  for (auto  : Functions) {
+IdentifierInfo *II;
+SourceLocation Loc;
+std::tie(II, Loc) = Function;
+
+DeclarationName DN(II);
+NamedDecl *ND = LookupSingleName(TUScope, DN, Loc, LookupOrdinaryName);
+if (!ND) {
+  Diag(Loc, diag::err_undeclared_use) << II->getName();
+  return;
+}
+
+DeclContext *DC = ND->getDeclContext();
+if (!DC->isExternCContext()) {
+  Diag(Loc, diag::err_pragma_alloc_text_c_linkage);
+  return;
+}
+
+FunctionToSectionMap[II->getName()] = std::make_tuple(Section, Loc);
+  }
+}
+
 void Sema::ActOnPragmaUnused(const Token , Scope *curScope,
  

[PATCH] D124750: [MLIR] Add a utility to sort the operands of commutative ops

[Srishti Srivastava via Phabricator via cfe-commits]

srishti-pm added a comment.

**`Replying to the various comments given in this revision:`**

**1. Regarding string manipulation:**

> I need to look at the algorithm in more detail, but I'm not a fan of using a 
> string key. Concatenating strings to make compound keys is not very efficient 
> and potentially brittle. Can you assign unique IDs and use an array of IDs 
> instead?

Sure, I'm currently brainstorming to come up with a way to do this.

> +1 to Mehdi's question about just stable sorting based on based on 4 criteria 
> (3 buckets + ordering within (1)) and then we should be able to avoid all the 
> string mangling too as Jeff asked about.

Actually, that question of Mehdi is now obsolete (I think). It was based on my 
incorrect documentation of the "sorting rule". I have now corrected the 
documentation of the rule (in the revision summary, the commit summary, and the 
code comments). The rule was finalized in a recent RFC (refer to comments 
starting from here: 
https://discourse.llvm.org/t/mlir-pdl-extending-pdl-pdlinterp-bytecode-to-enable-commutative-matching/60798/19?u=srishtisrivastava).
 Does this sound okay?

**2. Regarding reversing non-constant-like op and block argument order:**

> I would have thought block-arguments would come first as we don't know their 
> values, while non-constant-like ops could be folded at some point and then 
> become constant-like. Meaning, they seem closer to constant than block 
> arguments.

Sure. This sounds much better actually. I think at some point during the 
implementation, I had also thought of the same :)
I'll do this. Thanks for the suggestion.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124750

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

[PATCH] D124750: [MLIR] Add a utility to sort the operands of commutative ops

[Srishti Srivastava via Phabricator via cfe-commits]

srishti-pm added a comment.

> Thanks for improving the doc! Are you moving this to be used in 
> canonicalization next?
> I think a first good step would be to make it a pattern and test it with a 
> pass that applies it in the greedy rewriter. I would land this first and then 
> try to enable this in the canonicalized.

Thanks! I hope it is unambiguous and clear now! Yes, I will do the "moving this 
to be used in canonicalization" now. Thanks for the suggestion. The plan sounds 
good.

> Also, have you thought already about how to get rid of string manipulation?

No, I haven't. I'm still thinking about this. Meanwhile, I'll also address the 
other comments given here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124750

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

[PATCH] D123810: [Cuda] Add initial support for wrapping CUDA images in the new driver.

[Artem Belevich via Phabricator via cfe-commits]

tra added inline comments.



Comment at: clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp:193
+  }
+  static unsigned getHashValue(const OffloadKind ) { return Val * 37U; }
+

jhuber6 wrote:
> tra wrote:
> > Is there a particular reason for multiplying by 37? Enum values by 
> > themselves should do the job just fine. 
> That's what LLVM does for the regular 
> `DenseMapInfo::getHashValue()` so I just copied it here.
It would make sense for mapping the full range of uint16_t into a much smaller 
set of entries. In this case we're already dealing with a very small densely 
packed set of values. For all practical purposes is a convenient overkill We 
could get by with just using a vector+direct indexing. We also don't care about 
hash collisions even if they happen.

Removing multiplication would not make much of a difference, but it would be 
one less question for the reader to ask, when they look at this code.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123810

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

[PATCH] D123812: [CUDA] Add wrapper code generation for registering CUDA images

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 added inline comments.



Comment at: clang/tools/clang-linker-wrapper/OffloadWrapper.cpp:351
+///   required for texture / surface / managed variables.
+Function *createRegisterGlobalsFunction(Module ) {
+  LLVMContext  = M.getContext();

tra wrote:
> jdoerfert wrote:
> > jhuber6 wrote:
> > > tra wrote:
> > > > jhuber6 wrote:
> > > > > tra wrote:
> > > > > > Do you think generation of the CUDA registration glue could be 
> > > > > > shared with the front-end?
> > > > > > 
> > > > > I was thinking about it, but ultimately decided to keep the noise 
> > > > > outside of the new driver to a minimum. Maybe if we move to the 
> > > > > offloading entries being a common format we can easily share this 
> > > > > code. Keeping it in Clang would have the advantage that it's easier 
> > > > > to test directly and ensures we don't de-sync if anything changes. 
> > > > > The only downside is that in the future I may want to push this 
> > > > > functionality to a linker plugin or similar, which would require 
> > > > > pulling it out of Clang again to prevent us needing to link in Clang 
> > > > > to build LLVM.
> > > > > 
> > > > > Also needing to do this all through the builder API isn't ideal, it 
> > > > > would be nice if we had some kind of runtime to call to do this for 
> > > > > us, but I didn't feel like adding yet another shared library for 
> > > > > CUDA. I considered putting it inside the cuda header wrappers as 
> > > > > well, but forcing every CUDA file to have some externally visible 
> > > > > weak registration blob didn't sit well with me.
> > > > Perhaps front-end is not the right place for it, indeed. LLVM itself 
> > > > may be a better choice. We already have some things there for somewhat 
> > > > similar purposes (like lib/WindowsManifest) so adding a helper function 
> > > > to generate runtime glue for CUDA should not be unreasonable.
> > > I think it's fine here for this patch, but I definitely want to move it 
> > > into LLVM in the future once I start generalizing more of this stuff.
> > I'm OK with it being here but the place to consider (IMHO) is 
> > `llvm/lib/Frontend`, maybe `/CUDA/Register.cpp`.
> OK. I'm fine keeping it all here for now.
> Please add a comment pointing towards the origin of this code. and, maybe, a 
> TODO item to consolidate and move it into a better place.
Will do, thanks for the reviews. I'll land these tomorrow morning and see if 
anything breaks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123812

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

[PATCH] D123812: [CUDA] Add wrapper code generation for registering CUDA images

[Artem Belevich via Phabricator via cfe-commits]

tra accepted this revision.
tra added inline comments.
This revision is now accepted and ready to land.



Comment at: clang/tools/clang-linker-wrapper/OffloadWrapper.cpp:351
+///   required for texture / surface / managed variables.
+Function *createRegisterGlobalsFunction(Module ) {
+  LLVMContext  = M.getContext();

jdoerfert wrote:
> jhuber6 wrote:
> > tra wrote:
> > > jhuber6 wrote:
> > > > tra wrote:
> > > > > Do you think generation of the CUDA registration glue could be shared 
> > > > > with the front-end?
> > > > > 
> > > > I was thinking about it, but ultimately decided to keep the noise 
> > > > outside of the new driver to a minimum. Maybe if we move to the 
> > > > offloading entries being a common format we can easily share this code. 
> > > > Keeping it in Clang would have the advantage that it's easier to test 
> > > > directly and ensures we don't de-sync if anything changes. The only 
> > > > downside is that in the future I may want to push this functionality to 
> > > > a linker plugin or similar, which would require pulling it out of Clang 
> > > > again to prevent us needing to link in Clang to build LLVM.
> > > > 
> > > > Also needing to do this all through the builder API isn't ideal, it 
> > > > would be nice if we had some kind of runtime to call to do this for us, 
> > > > but I didn't feel like adding yet another shared library for CUDA. I 
> > > > considered putting it inside the cuda header wrappers as well, but 
> > > > forcing every CUDA file to have some externally visible weak 
> > > > registration blob didn't sit well with me.
> > > Perhaps front-end is not the right place for it, indeed. LLVM itself may 
> > > be a better choice. We already have some things there for somewhat 
> > > similar purposes (like lib/WindowsManifest) so adding a helper function 
> > > to generate runtime glue for CUDA should not be unreasonable.
> > I think it's fine here for this patch, but I definitely want to move it 
> > into LLVM in the future once I start generalizing more of this stuff.
> I'm OK with it being here but the place to consider (IMHO) is 
> `llvm/lib/Frontend`, maybe `/CUDA/Register.cpp`.
OK. I'm fine keeping it all here for now.
Please add a comment pointing towards the origin of this code. and, maybe, a 
TODO item to consolidate and move it into a better place.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123812

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

[PATCH] D123810: [Cuda] Add initial support for wrapping CUDA images in the new driver.

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 added a comment.

Thanks for the review.




Comment at: clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp:193
+  }
+  static unsigned getHashValue(const OffloadKind ) { return Val * 37U; }
+

tra wrote:
> Is there a particular reason for multiplying by 37? Enum values by themselves 
> should do the job just fine. 
That's what LLVM does for the regular `DenseMapInfo::getHashValue()` 
so I just copied it here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123810

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

[PATCH] D123810: [Cuda] Add initial support for wrapping CUDA images in the new driver.

[Artem Belevich via Phabricator via cfe-commits]

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

Please add a TODO around the items that need further work, so we don't forget 
about them. Review comments tend to fade from memory.




Comment at: clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp:193
+  }
+  static unsigned getHashValue(const OffloadKind ) { return Val * 37U; }
+

Is there a particular reason for multiplying by 37? Enum values by themselves 
should do the job just fine. 



Comment at: clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp:726
+
+  if (Error Err = executeCommands(*FatBinaryPath, CmdArgs))
+return std::move(Err);

jhuber6 wrote:
> tra wrote:
> > We should have a way to pass extra options to fatbinary, too. E.g. we may 
> > want to use `--compress-all`. Also, we may need to pass through `-g` for 
> > debug builds.
> > 
> > Oh. Debug builds. Makes me wonder if cuda-gdb will be able to find GPU 
> > binaries packaged by the new driver. If it does not, it will be a rather 
> > serious problem. It would likely affect various profiling tools the same 
> > way, too. Can you give it a try?
> I was planning on implementing this stuff more generally when we get the new 
> binary tool in D125165 landed. That will allow me to more generally put any 
> number of command line arguments into the binary itself and fish it out here. 
> We already support a janky version for the -Xcuda-ptxas option here, but it's 
> a mess and I'm planning on getting rid of it. Is it okay to punt that into 
> the future? Debug builds are another sore point I don't handle super well 
> right now but will be addressed better with D125165. 
> 
> I haven't tested cuda-gdb, but I embed the fatbinary the same way that we do 
> in non-rdc mode. I can read them with cuobjdump in the final executable so 
> I'm assuming it's compatible.
>  I can read them with cuobjdump in the final executable so I'm assuming it's 
> compatible.

We should be OK then.



Comment at: clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp:726
+
+  if (Error Err = executeCommands(*FatBinaryPath, CmdArgs))
+return std::move(Err);

tra wrote:
> jhuber6 wrote:
> > tra wrote:
> > > We should have a way to pass extra options to fatbinary, too. E.g. we may 
> > > want to use `--compress-all`. Also, we may need to pass through `-g` for 
> > > debug builds.
> > > 
> > > Oh. Debug builds. Makes me wonder if cuda-gdb will be able to find GPU 
> > > binaries packaged by the new driver. If it does not, it will be a rather 
> > > serious problem. It would likely affect various profiling tools the same 
> > > way, too. Can you give it a try?
> > I was planning on implementing this stuff more generally when we get the 
> > new binary tool in D125165 landed. That will allow me to more generally put 
> > any number of command line arguments into the binary itself and fish it out 
> > here. We already support a janky version for the -Xcuda-ptxas option here, 
> > but it's a mess and I'm planning on getting rid of it. Is it okay to punt 
> > that into the future? Debug builds are another sore point I don't handle 
> > super well right now but will be addressed better with D125165. 
> > 
> > I haven't tested cuda-gdb, but I embed the fatbinary the same way that we 
> > do in non-rdc mode. I can read them with cuobjdump in the final executable 
> > so I'm assuming it's compatible.
> >  I can read them with cuobjdump in the final executable so I'm assuming 
> > it's compatible.
> 
> We should be OK then.
> Debug builds are another sore point I don't handle super well right now but 
> will be addressed better with D125165

OK. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123810

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

[PATCH] D119296: KCFI sanitizer

[Sami Tolvanen via Phabricator via cfe-commits]

samitolvanen updated this revision to Diff 428520.
samitolvanen added a comment.

Added a test for the Clang -O2 pipeline dropping unneeded checks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119296

Files:
  clang/docs/ClangCommandLineReference.rst
  clang/docs/ControlFlowIntegrity.rst
  clang/docs/UsersManual.rst
  clang/include/clang/Basic/Features.def
  clang/include/clang/Basic/Sanitizers.def
  clang/lib/CodeGen/CGExpr.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/CodeGen/CodeGenModule.h
  clang/lib/Driver/SanitizerArgs.cpp
  clang/lib/Driver/ToolChain.cpp
  clang/test/CodeGen/kcfi.c
  clang/test/Driver/fsanitize.c
  llvm/include/llvm/CodeGen/AsmPrinter.h
  llvm/include/llvm/IR/Intrinsics.td
  llvm/include/llvm/MC/MCObjectFileInfo.h
  llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp
  llvm/lib/MC/MCObjectFileInfo.cpp
  llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp
  llvm/lib/Target/AArch64/AArch64InstrInfo.td
  llvm/lib/Target/X86/X86AsmPrinter.cpp
  llvm/lib/Target/X86/X86AsmPrinter.h
  llvm/lib/Target/X86/X86InstrCompiler.td
  llvm/lib/Target/X86/X86MCInstLower.cpp
  llvm/lib/Transforms/InstCombine/InstCombineCalls.cpp
  llvm/test/CodeGen/AArch64/kcfi.ll
  llvm/test/CodeGen/X86/kcfi.ll
  llvm/test/Transforms/InstCombine/kcfi_check.ll

Index: llvm/test/Transforms/InstCombine/kcfi_check.ll
===
--- /dev/null
+++ llvm/test/Transforms/InstCombine/kcfi_check.ll
@@ -0,0 +1,35 @@
+; RUN: opt < %s -passes=instcombine -S | FileCheck %s
+
+define void @f1() #0 prefix i32 10 {
+  ret void
+}
+
+declare void @f2() #0 prefix i32 11
+
+define internal void @f3() {
+  ret void
+}
+
+define void @g(ptr noundef %x) {
+  ; CHECK: call void @llvm.kcfi.check(ptr %x, i32 10)
+  call void @llvm.kcfi.check(ptr %x, i32 10)
+
+  ; CHECK-NOT: call void @llvm.kcfi.check(ptr nonnull @f1, i32 10)
+  ; CHECK: call void @llvm.kcfi.check(ptr nonnull @f1, i32 11)
+  call void @llvm.kcfi.check(ptr nonnull @f1, i32 10)
+  call void @llvm.kcfi.check(ptr nonnull @f1, i32 11)
+
+  ; CHECK: call void @llvm.kcfi.check(ptr nonnull @f2, i32 10)
+  ; CHECK-NOT: call void @llvm.kcfi.check(ptr nonnull @f2, i32 11)
+  call void @llvm.kcfi.check(ptr nonnull @f2, i32 10)
+  call void @llvm.kcfi.check(ptr nonnull @f2, i32 11)
+
+  ; CHECK: call void @llvm.kcfi.check(ptr nonnull @f3, i32 10)
+  call void @llvm.kcfi.check(ptr nonnull @f3, i32 10)
+  ret void
+}
+
+; CHECK: declare void @llvm.kcfi.check(ptr, i32 immarg)
+declare void @llvm.kcfi.check(ptr, i32 immarg)
+
+attributes #0 = { "kcfi" }
Index: llvm/test/CodeGen/X86/kcfi.ll
===
--- /dev/null
+++ llvm/test/CodeGen/X86/kcfi.ll
@@ -0,0 +1,39 @@
+; RUN: llc -mtriple=x86_64-unknown-linux-gnu < %s | FileCheck %s
+; RUN: llc -mtriple=x86_64-unknown-linux-gnu -stop-before=finalize-isel < %s | FileCheck %s --check-prefix=ISEL
+
+; CHECK:   .type __cfi_f1,@function
+; CHECK-LABEL: __cfi_f1:
+; CHECK-NEXT:int3
+; CHECK-NEXT:int3
+; CHECK-NEXT:movl $12345678, %eax
+; CHECK-NEXT:int3
+; CHECK-NEXT:int3
+; CHECK-LABEL: .L__cfi_func_end0:
+; CHECK-NEXT:  .size   __cfi_f1, .L__cfi_func_end0-__cfi_f1
+define void @f1(ptr noundef %x) #0 prefix i32 12345678 {
+
+; CHECK-LABEL: f1:
+; CHECK:   # %bb.0:
+; CHECK: cmpl $12345678, -6(%rdi) # imm = 0xBC614E
+; CHECK-NEXT:je .Ltmp0
+; CHECK-NEXT:  .Ltmp1:
+; CHECK-NEXT:ud2
+; CHECK-NEXT:.section .kcfi_traps,"awo",@progbits,.text
+; CHECK-NEXT:.quad .Ltmp1
+; CHECK-NEXT:.text
+; CHECK-NEXT:  .Ltmp0:
+; CHECK-NEXT:callq *%rdi
+
+; ISEL: name: f1
+; ISEL: body:
+; ISEL: KCFI_CHECK %[[#CALL:]], 12345678, implicit-def dead $eflags
+; ISEL: CALL64r %[[#CALL]], csr_64, implicit $rsp, implicit $ssp, implicit-def $rsp, implicit-def $ssp
+
+  call void @llvm.kcfi.check(ptr %x, i32 12345678)
+  call void %x()
+  ret void
+}
+
+declare void @llvm.kcfi.check(ptr, i32 immarg)
+
+attributes #0 = { "kcfi" }
Index: llvm/test/CodeGen/AArch64/kcfi.ll
===
--- /dev/null
+++ llvm/test/CodeGen/AArch64/kcfi.ll
@@ -0,0 +1,30 @@
+; RUN: llc -mtriple=aarch64-- < %s | FileCheck %s
+; RUN: llc -mtriple=aarch64-- -stop-before=finalize-isel < %s | FileCheck %s --check-prefix=ISEL
+
+; CHECK:   .word 12345678
+define void @f1(ptr noundef %x) #0 prefix i32 12345678 {
+
+; CHECK-LABEL: f1:
+; CHECK:   // %bb.0:
+; CHECK: ldur w16, [x0, #-4]
+; CHECK-NEXT:movk w17, #24910
+; CHECK-NEXT:movk w17, #188, lsl #16
+; CHECK-NEXT:cmp w16, w17
+; CHECK-NEXT:b.eq .Ltmp0
+; CHECK-NEXT:brk #0x8220
+; CHECK-NEXT:  .Ltmp0:
+; CHECK-NEXT:blr x0
+
+; ISEL: name: f1
+; ISEL: body:
+; ISEL: KCFI_CHECK %[[#CALL:]], 12345678, implicit-def dead $x16, implicit-def dead $x17, implicit-def dead $nzcv
+; ISEL: 

[PATCH] D125165: [Clang] Introduce clang-offload-packager tool to bundle device files

[Artem Belevich via Phabricator via cfe-commits]

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

OK.  LGTM.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125165

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

[PATCH] D123810: [Cuda] Add initial support for wrapping CUDA images in the new driver.

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 updated this revision to Diff 428517.
jhuber6 added a comment.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Addressing comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123810

Files:
  clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
  clang/tools/clang-linker-wrapper/OffloadWrapper.cpp
  clang/tools/clang-linker-wrapper/OffloadWrapper.h
  llvm/include/llvm/Object/OffloadBinary.h

Index: llvm/include/llvm/Object/OffloadBinary.h
===
--- llvm/include/llvm/Object/OffloadBinary.h
+++ llvm/include/llvm/Object/OffloadBinary.h
@@ -31,6 +31,7 @@
   OFK_OpenMP,
   OFK_Cuda,
   OFK_HIP,
+  OFK_LAST,
 };
 
 /// The type of contents the offloading image contains.
@@ -41,6 +42,7 @@
   IMG_Cubin,
   IMG_Fatbinary,
   IMG_PTX,
+  IMG_LAST,
 };
 
 /// A simple binary serialization of an offloading file. We use this format to
Index: clang/tools/clang-linker-wrapper/OffloadWrapper.h
===
--- clang/tools/clang-linker-wrapper/OffloadWrapper.h
+++ clang/tools/clang-linker-wrapper/OffloadWrapper.h
@@ -1,4 +1,4 @@
-//===- OffloadWrapper.h ---*- C++ -*-===//
+//===- OffloadWrapper.h --r-*- C++ -*-===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
@@ -12,9 +12,13 @@
 #include "llvm/ADT/ArrayRef.h"
 #include "llvm/IR/Module.h"
 
-/// Wrap the input device images into the module \p M as global symbols and
+/// Wraps the input device images into the module \p M as global symbols and
 /// registers the images with the OpenMP Offloading runtime libomptarget.
-llvm::Error wrapBinaries(llvm::Module ,
- llvm::ArrayRef> Images);
+llvm::Error wrapOpenMPBinaries(llvm::Module ,
+   llvm::ArrayRef> Images);
+
+/// Wraps the input fatbinary image into the module \p M as global symbols and
+/// registers the images with the CUDA runtime.
+llvm::Error wrapCudaBinary(llvm::Module , llvm::ArrayRef Images);
 
 #endif
Index: clang/tools/clang-linker-wrapper/OffloadWrapper.cpp
===
--- clang/tools/clang-linker-wrapper/OffloadWrapper.cpp
+++ clang/tools/clang-linker-wrapper/OffloadWrapper.cpp
@@ -257,7 +257,7 @@
 
 } // namespace
 
-Error wrapBinaries(Module , ArrayRef> Images) {
+Error wrapOpenMPBinaries(Module , ArrayRef> Images) {
   GlobalVariable *Desc = createBinDesc(M, Images);
   if (!Desc)
 return createStringError(inconvertibleErrorCode(),
@@ -266,3 +266,8 @@
   createUnregisterFunction(M, Desc);
   return Error::success();
 }
+
+llvm::Error wrapCudaBinary(llvm::Module , llvm::ArrayRef Images) {
+  // TODO: Implement this.
+  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
@@ -166,12 +166,12 @@
 
 /// Information for a device offloading file extracted from the host.
 struct DeviceFile {
-  DeviceFile(StringRef Kind, StringRef TheTriple, StringRef Arch,
+  DeviceFile(OffloadKind Kind, StringRef TheTriple, StringRef Arch,
  StringRef Filename, bool IsLibrary = false)
   : Kind(Kind), TheTriple(TheTriple), Arch(Arch), Filename(Filename),
 IsLibrary(IsLibrary) {}
 
-  std::string Kind;
+  OffloadKind Kind;
   std::string TheTriple;
   std::string Arch;
   std::string Filename;
@@ -183,15 +183,28 @@
 /// assume device files with matching architectures and triples but different
 /// offloading kinds should be handlded together, this may not be true in the
 /// future.
+
+// Provide DenseMapInfo for OffloadKind.
+template <> struct DenseMapInfo {
+  static inline OffloadKind getEmptyKey() { return OFK_LAST; }
+  static inline OffloadKind getTombstoneKey() {
+return static_cast(OFK_LAST + 1);
+  }
+  static unsigned getHashValue(const OffloadKind ) { return Val * 37U; }
+
+  static bool isEqual(const OffloadKind , const OffloadKind ) {
+return LHS == RHS;
+  }
+};
 template <> struct DenseMapInfo {
   static DeviceFile getEmptyKey() {
-return {DenseMapInfo::getEmptyKey(),
+return {DenseMapInfo::getEmptyKey(),
 DenseMapInfo::getEmptyKey(),
 DenseMapInfo::getEmptyKey(),
 DenseMapInfo::getEmptyKey()};
   }
   static DeviceFile getTombstoneKey() {
-return {DenseMapInfo::getTombstoneKey(),
+return {DenseMapInfo::getTombstoneKey(),
 DenseMapInfo::getTombstoneKey(),
 DenseMapInfo::getTombstoneKey(),
 DenseMapInfo::getTombstoneKey()};
@@ -233,7 +246,7 @@
   auto 

[PATCH] D123534: [dwarf] Emit a DIGlobalVariable for constant strings.

[Reid Kleckner via Phabricator via cfe-commits]

rnk added a comment.

This seems reasonable, but I worry about the consequences of creating lots of 
unnamed global variables. What will gdb do with so many unnamed globals? What 
will the PDB linker do with all these unnamed globals? I can't answer these 
questions, and you're welcome to try and find out, but I predict there will be 
problems, so just be aware of that possibility.

Looking at the S_GDATA32 record format, there is no place for the file & line 
info:
https://github.com/microsoft/microsoft-pdb/blob/master/include/cvinfo.h#L3629
It's just type info & name, really, so there's not much point in creating these 
when emitting codeview. It's probably best to filter these unnamed globals out 
in AsmPrinter/CodeViewDebug.cpp rather than changing the IR clang generates.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123534

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

[PATCH] D125142: [clang][auto-init] Remove -enable flag for "zero" mode

[Kees Cook via Phabricator via cfe-commits]

kees added a comment.

This is marked "needs revision", but I think it just needs wider review?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125142

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

[PATCH] D123810: [Cuda] Add initial support for wrapping CUDA images in the new driver.

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 added inline comments.



Comment at: clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp:726
+
+  if (Error Err = executeCommands(*FatBinaryPath, CmdArgs))
+return std::move(Err);

tra wrote:
> We should have a way to pass extra options to fatbinary, too. E.g. we may 
> want to use `--compress-all`. Also, we may need to pass through `-g` for 
> debug builds.
> 
> Oh. Debug builds. Makes me wonder if cuda-gdb will be able to find GPU 
> binaries packaged by the new driver. If it does not, it will be a rather 
> serious problem. It would likely affect various profiling tools the same way, 
> too. Can you give it a try?
I was planning on implementing this stuff more generally when we get the new 
binary tool in D125165 landed. That will allow me to more generally put any 
number of command line arguments into the binary itself and fish it out here. 
We already support a janky version for the -Xcuda-ptxas option here, but it's a 
mess and I'm planning on getting rid of it. Is it okay to punt that into the 
future? Debug builds are another sore point I don't handle super well right now 
but will be addressed better with D125165. 

I haven't tested cuda-gdb, but I embed the fatbinary the same way that we do in 
non-rdc mode. I can read them with cuobjdump in the final executable so I'm 
assuming it's compatible.



Comment at: clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp:1192
 // Run LTO on any bitcode files and replace the input with the result.
-if (Error Err = linkBitcodeFiles(LinkerInput.getSecond(), TheTriple,
- File.Arch, WholeProgram))
+if (Error Err = linkBitcodeFiles(LinkerInputFiles, TheTriple, File.Arch,
+ WholeProgram))

tra wrote:
> Nit. We should think of changing `linkBitcodeFiles` to return 
> `llvm::ErrorOr` so we can return `WholeArchive` value, instead of 
> modifying it as an argument.
That's a good idea, I'm planning on cleaning a lot of this stuff up later.



Comment at: clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp:1200
+  LinkedImages.emplace_back(OFK_OpenMP, TheTriple.getTriple(), File.Arch,
+LinkerInputFiles.front());
   continue;

tra wrote:
> What's expected to happen if we have more than one input?
> If only one is ever expected, I'd add an assert.
This isn't used right now since JIT hasn't made it in. It should probably be a 
proper error honestly.



Comment at: clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp:1206
 // CUDA in non-RDC mode.
 if (WholeProgram && TheTriple.isNVPTX()) {
+  assert(!LinkerInputFiles.empty() && "No non-RDC image to embed");

tra wrote:
> Should `EmbedBitcode` be mutually exclusive vs `WholeArchive`? 
> 
> Can we ever end up with both unset? 
`EmbedBitcode` might need to require `WholeArchive` considering that it's 
supposed to be a completely linked image that can be sent to a JIT engine. 



Comment at: clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp:1347
+
+auto FileOrErr = compileModule(M);
+if (!FileOrErr)

tra wrote:
> The `M` contains generated registration glue at this point, right? It may be 
> worth a comment to explain what is it that we're compiling here.
Sure.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123810

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

[PATCH] D124750: [MLIR] Add a utility to sort the operands of commutative ops

[Mehdi AMINI via Phabricator via cfe-commits]

mehdi_amini added a comment.

Thanks for improving the doc! Are you moving this to be used in 
canonicalization next?
I think a first good step would be to make it a pattern and test it with a pass 
that applies it in the greedy rewriter. I would land this first and then try to 
enable this in the canonicalized.

Also, have you thought already about how to get rid of string manipulation?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124750

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

[PATCH] D125340: [clang][NFC][AST] rename the ImportError to ASTImportError

[Shivam Rajput via Phabricator via cfe-commits]

phyBrackets created this revision.
Herald added a subscriber: martong.
Herald added a reviewer: a.sidorin.
Herald added a reviewer: shafik.
Herald added a project: All.
phyBrackets requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

this patch is the continuation of my previous patch regarding the ImportError 
in ASTImportError.h


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D125340

Files:
  clang/include/clang/AST/ASTImportError.h
  clang/include/clang/AST/ASTImporter.h
  clang/include/clang/AST/ASTImporterSharedState.h
  clang/lib/AST/ASTImporter.cpp
  clang/lib/CrossTU/CrossTranslationUnit.cpp
  clang/unittests/AST/ASTImporterFixtures.h
  clang/unittests/AST/ASTImporterODRStrategiesTest.cpp
  clang/unittests/AST/ASTImporterTest.cpp

Index: clang/unittests/AST/ASTImporterTest.cpp
===
--- clang/unittests/AST/ASTImporterTest.cpp
+++ clang/unittests/AST/ASTImporterTest.cpp
@@ -3178,8 +3178,8 @@
 
   auto ToBlockOrError = importOrError(FromBlock, Lang_CXX03);
 
-  const auto ExpectUnsupportedConstructError = [](const ImportError ) {
-EXPECT_EQ(ImportError::UnsupportedConstruct, Error.Error);
+  const auto ExpectUnsupportedConstructError = [](const ASTImportError ) {
+EXPECT_EQ(ASTImportError::UnsupportedConstruct, Error.Error);
   };
   llvm::handleAllErrors(ToBlockOrError.takeError(),
 ExpectUnsupportedConstructError);
@@ -5435,9 +5435,9 @@
 
   // But an error is set to the counterpart in the "from" context.
   ASTImporter *Importer = findFromTU(FromSpec)->Importer.get();
-  Optional OptErr = Importer->getImportDeclErrorIfAny(FromSpec);
+  Optional OptErr = Importer->getImportDeclErrorIfAny(FromSpec);
   ASSERT_TRUE(OptErr);
-  EXPECT_EQ(OptErr->Error, ImportError::NameConflict);
+  EXPECT_EQ(OptErr->Error, ASTImportError::NameConflict);
 }
 
 // Check a case when a new AST node is created but not linked to the AST before
@@ -5459,9 +5459,9 @@
   0u);
 
   ASTImporter *Importer = findFromTU(FromFoo)->Importer.get();
-  Optional OptErr = Importer->getImportDeclErrorIfAny(FromFoo);
+  Optional OptErr = Importer->getImportDeclErrorIfAny(FromFoo);
   ASSERT_TRUE(OptErr);
-  EXPECT_EQ(OptErr->Error, ImportError::UnsupportedConstruct);
+  EXPECT_EQ(OptErr->Error, ASTImportError::UnsupportedConstruct);
 }
 
 // Check a case when a new AST node is created and linked to the AST before
@@ -5492,12 +5492,13 @@
   // An error is set to the counterpart in the "from" context both for the fwd
   // decl and the definition.
   ASTImporter *Importer = findFromTU(FromProto)->Importer.get();
-  Optional OptErr = Importer->getImportDeclErrorIfAny(FromProto);
+  Optional OptErr =
+  Importer->getImportDeclErrorIfAny(FromProto);
   ASSERT_TRUE(OptErr);
-  EXPECT_EQ(OptErr->Error, ImportError::UnsupportedConstruct);
+  EXPECT_EQ(OptErr->Error, ASTImportError::UnsupportedConstruct);
   OptErr = Importer->getImportDeclErrorIfAny(FromDef);
   ASSERT_TRUE(OptErr);
-  EXPECT_EQ(OptErr->Error, ImportError::UnsupportedConstruct);
+  EXPECT_EQ(OptErr->Error, ASTImportError::UnsupportedConstruct);
 }
 
 // An error should be set for a class if we cannot import one member.
@@ -5517,16 +5518,16 @@
   // An error is set for X.
   EXPECT_FALSE(ImportedX);
   ASTImporter *Importer = findFromTU(FromX)->Importer.get();
-  Optional OptErr = Importer->getImportDeclErrorIfAny(FromX);
+  Optional OptErr = Importer->getImportDeclErrorIfAny(FromX);
   ASSERT_TRUE(OptErr);
-  EXPECT_EQ(OptErr->Error, ImportError::UnsupportedConstruct);
+  EXPECT_EQ(OptErr->Error, ASTImportError::UnsupportedConstruct);
 
   // An error is set for f().
   auto *FromF = FirstDeclMatcher().match(
   FromTU, cxxMethodDecl(hasName("f")));
   OptErr = Importer->getImportDeclErrorIfAny(FromF);
   ASSERT_TRUE(OptErr);
-  EXPECT_EQ(OptErr->Error, ImportError::UnsupportedConstruct);
+  EXPECT_EQ(OptErr->Error, ASTImportError::UnsupportedConstruct);
   // And any subsequent import should fail.
   CXXMethodDecl *ImportedF = Import(FromF, Lang_CXX03);
   EXPECT_FALSE(ImportedF);
@@ -5584,7 +5585,7 @@
 
   // An error is set to the templated CXXRecordDecl of F.
   ASTImporter *Importer = findFromTU(FromFRD)->Importer.get();
-  Optional OptErr = Importer->getImportDeclErrorIfAny(FromFRD);
+  Optional OptErr = Importer->getImportDeclErrorIfAny(FromFRD);
   EXPECT_TRUE(OptErr);
 
   // An error is set to A.
@@ -5642,7 +5643,7 @@
   // There is no error set for X.
   EXPECT_TRUE(ImportedX);
   ASTImporter *Importer = findFromTU(FromX)->Importer.get();
-  Optional OptErr = Importer->getImportDeclErrorIfAny(FromX);
+  Optional OptErr = Importer->getImportDeclErrorIfAny(FromX);
   ASSERT_FALSE(OptErr);
 
   // An error is set for f().
@@ -5650,7 +5651,7 @@
   FromTU, functionDecl(hasName("f")));
   OptErr = Importer->getImportDeclErrorIfAny(FromF);
   ASSERT_TRUE(OptErr);
-  EXPECT_EQ(OptErr->Error, 

[PATCH] D123810: [Cuda] Add initial support for wrapping CUDA images in the new driver.

[Artem Belevich via Phabricator via cfe-commits]

tra added inline comments.



Comment at: clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp:188
+  static inline OffloadKind getEmptyKey() {
+return static_cast(0x);
+  }

Extend `enum OffloadKind` to include these special kinds. 



Comment at: clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp:201
   static DeviceFile getEmptyKey() {
-return {DenseMapInfo::getEmptyKey(),
+return {static_cast(DenseMapInfo::getEmptyKey()),
 DenseMapInfo::getEmptyKey(),

Why do we limit ourselves to uint16_t here? Can't we just use `OffloadKind` 
itself and get rid of these casts?



Comment at: clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp:726
+
+  if (Error Err = executeCommands(*FatBinaryPath, CmdArgs))
+return std::move(Err);

We should have a way to pass extra options to fatbinary, too. E.g. we may want 
to use `--compress-all`. Also, we may need to pass through `-g` for debug 
builds.

Oh. Debug builds. Makes me wonder if cuda-gdb will be able to find GPU binaries 
packaged by the new driver. If it does not, it will be a rather serious 
problem. It would likely affect various profiling tools the same way, too. Can 
you give it a try?



Comment at: clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp:1192
 // Run LTO on any bitcode files and replace the input with the result.
-if (Error Err = linkBitcodeFiles(LinkerInput.getSecond(), TheTriple,
- File.Arch, WholeProgram))
+if (Error Err = linkBitcodeFiles(LinkerInputFiles, TheTriple, File.Arch,
+ WholeProgram))

Nit. We should think of changing `linkBitcodeFiles` to return 
`llvm::ErrorOr` so we can return `WholeArchive` value, instead of 
modifying it as an argument.



Comment at: clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp:1200
+  LinkedImages.emplace_back(OFK_OpenMP, TheTriple.getTriple(), File.Arch,
+LinkerInputFiles.front());
   continue;

What's expected to happen if we have more than one input?
If only one is ever expected, I'd add an assert.



Comment at: clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp:1206
 // CUDA in non-RDC mode.
 if (WholeProgram && TheTriple.isNVPTX()) {
+  assert(!LinkerInputFiles.empty() && "No non-RDC image to embed");

Should `EmbedBitcode` be mutually exclusive vs `WholeArchive`? 

Can we ever end up with both unset? 



Comment at: clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp:1210
+LinkedImages.emplace_back(Kind, TheTriple.getTriple(), File.Arch,
+  LinkerInputFiles.front());
   continue;

ditto about the assert on the number of inputs.



Comment at: clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp:1347
+
+auto FileOrErr = compileModule(M);
+if (!FileOrErr)

The `M` contains generated registration glue at this point, right? It may be 
worth a comment to explain what is it that we're compiling here.



Comment at: clang/tools/clang-linker-wrapper/OffloadWrapper.cpp:271
+llvm::Error wrapCudaBinary(llvm::Module , llvm::ArrayRef Images) {
+  return Error::success();
+}

A "not-implemented-yet/TODO" comment would be appropriate here.



Comment at: clang/tools/clang-linker-wrapper/OffloadWrapper.h:20
+
+/// Wrap the input fatbinary image into the module \p M as global symbols and
+/// registers the images with the CUDA runtime.

It should be either "Wraps/registers" or "Wrap/register".


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123810

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

[PATCH] D124750: [MLIR] Add a utility to sort the operands of commutative ops

[Srishti Srivastava via Phabricator via cfe-commits]

srishti-pm updated this revision to Diff 428502.
srishti-pm added a comment.

Fixing a minor typo.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124750

Files:
  clang/docs/tools/clang-formatted-files.txt
  mlir/include/mlir/Transforms/CommutativityUtils.h
  mlir/lib/Transforms/Utils/CMakeLists.txt
  mlir/lib/Transforms/Utils/CommutativityUtils.cpp
  mlir/test/Transforms/test-commutativity-utils.mlir
  mlir/test/lib/Dialect/Test/TestOps.td
  mlir/test/lib/Transforms/CMakeLists.txt
  mlir/test/lib/Transforms/TestCommutativityUtils.cpp
  mlir/tools/mlir-opt/mlir-opt.cpp

Index: mlir/tools/mlir-opt/mlir-opt.cpp
===
--- mlir/tools/mlir-opt/mlir-opt.cpp
+++ mlir/tools/mlir-opt/mlir-opt.cpp
@@ -56,6 +56,7 @@
 void registerVectorizerTestPass();
 
 namespace test {
+void registerCommutativityUtils();
 void registerConvertCallOpPass();
 void registerInliner();
 void registerMemRefBoundCheck();
@@ -146,6 +147,7 @@
   registerVectorizerTestPass();
   registerTosaTestQuantUtilAPIPass();
 
+  mlir::test::registerCommutativityUtils();
   mlir::test::registerConvertCallOpPass();
   mlir::test::registerInliner();
   mlir::test::registerMemRefBoundCheck();
Index: mlir/test/lib/Transforms/TestCommutativityUtils.cpp
===
--- /dev/null
+++ mlir/test/lib/Transforms/TestCommutativityUtils.cpp
@@ -0,0 +1,67 @@
+//===- TestCommutativityUtils.cpp - Pass to test the commutativity utility-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This pass tests the functionality of the commutativity utility.
+//
+//===--===//
+
+#include "mlir/Transforms/CommutativityUtils.h"
+
+#include "TestDialect.h"
+#include "mlir/Pass/Pass.h"
+#include "mlir/Transforms/GreedyPatternRewriteDriver.h"
+
+using namespace mlir;
+using namespace test;
+
+namespace {
+
+struct SmallPattern : public OpRewritePattern {
+  using OpRewritePattern::OpRewritePattern;
+  LogicalResult matchAndRewrite(TestCommutativeOp testCommOp,
+PatternRewriter ) const override {
+sortCommutativeOperands(testCommOp.getOperation(), rewriter);
+return success();
+  }
+};
+
+struct LargePattern : public OpRewritePattern {
+  using OpRewritePattern::OpRewritePattern;
+  LogicalResult matchAndRewrite(TestLargeCommutativeOp testLargeCommOp,
+PatternRewriter ) const override {
+sortCommutativeOperands(testLargeCommOp.getOperation(), rewriter);
+return success();
+  }
+};
+
+struct CommutativityUtils
+: public PassWrapper> {
+  MLIR_DEFINE_EXPLICIT_INTERNAL_INLINE_TYPE_ID(CommutativityUtils)
+
+  StringRef getArgument() const final { return "test-commutativity-utils"; }
+  StringRef getDescription() const final {
+return "Test the functionality of the commutativity utility";
+  }
+
+  void runOnOperation() override {
+auto func = getOperation();
+auto *context = ();
+
+RewritePatternSet patterns(context);
+patterns.add(context);
+
+(void)applyPatternsAndFoldGreedily(func, std::move(patterns));
+  }
+};
+} // namespace
+
+namespace mlir {
+namespace test {
+void registerCommutativityUtils() { PassRegistration(); }
+} // namespace test
+} // namespace mlir
Index: mlir/test/lib/Transforms/CMakeLists.txt
===
--- mlir/test/lib/Transforms/CMakeLists.txt
+++ mlir/test/lib/Transforms/CMakeLists.txt
@@ -1,5 +1,6 @@
 # Exclude tests from libMLIR.so
 add_mlir_library(MLIRTestTransforms
+  TestCommutativityUtils.cpp
   TestConstantFold.cpp
   TestControlFlowSink.cpp
   TestInlining.cpp
Index: mlir/test/lib/Dialect/Test/TestOps.td
===
--- mlir/test/lib/Dialect/Test/TestOps.td
+++ mlir/test/lib/Dialect/Test/TestOps.td
@@ -1101,11 +1101,21 @@
   let hasFolder = 1;
 }
 
+def TestAddIOp : TEST_Op<"addi"> {
+  let arguments = (ins I32:$op1, I32:$op2);
+  let results = (outs I32);
+}
+
 def TestCommutativeOp : TEST_Op<"op_commutative", [Commutative]> {
   let arguments = (ins I32:$op1, I32:$op2, I32:$op3, I32:$op4);
   let results = (outs I32);
 }
 
+def TestLargeCommutativeOp : TEST_Op<"op_large_commutative", [Commutative]> {
+  let arguments = (ins I32:$op1, I32:$op2, I32:$op3, I32:$op4, I32:$op5, I32:$op6, I32:$op7);
+  let results = (outs I32);
+}
+
 def TestCommutative2Op : TEST_Op<"op_commutative2", [Commutative]> {
   let arguments = (ins I32:$op1, I32:$op2);
   let results = (outs I32);
Index: 

[PATCH] D124534: [clang] Add a diagnostic for line directive of a gnu extension

[Ken Matsui via Phabricator via cfe-commits]

ken-matsui added a comment.

In D124534#3504610 , @aaron.ballman 
wrote:

> LGTM, thank you for all the hard work on this! I assume you need me to land 
> this on your behalf -- if so, can you let me know what name and email address 
> you would like me to use for patch attribution?

Thank you so much for your support and approval!

Yes, I do not have commit access; could you please use the following info for 
this patch?

Name: Ken Matsui
Email: 26405363+ken-mat...@users.noreply.github.com

(I use this info for every commit on GitHub, but is this what you expected? 
Please let me know if you need an email where you can be reached out.)

> I think we should add a release note for this to let folks know about the new 
> warning group (there's a "Improvements to Clang's diagnostics" in 
> clang/docs/ReleaseNotes.rst). You can either add one to this patch, or I can 
> add one for you when I go to land, I'm fine either way.

Could you please add it to this patch for this time?
I would like to add one next time by referring to how you do.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124534

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

[PATCH] D125338: [HLSL] add -D option for dxc mode.

[Xiang Li via Phabricator via cfe-commits]

python3kgae created this revision.
python3kgae added reviewers: amccarth, craig.topper, hans, rnk, 
stefan_reinalter, beanz, pow2clk, aaron.ballman.
Herald added subscribers: Anastasia, StephenFan.
Herald added a project: All.
python3kgae requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay.
Herald added a project: clang.

Create dxc_D as alias to option D which Define  to  (or 1 if 
 omitted).


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D125338

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/dxc_D.hlsl


Index: clang/test/Driver/dxc_D.hlsl
===
--- /dev/null
+++ clang/test/Driver/dxc_D.hlsl
@@ -0,0 +1,5 @@
+// RUN: %clang_dxc -DTEST=2 foo.hlsl -### %s 2>&1 | FileCheck %s
+
+// Make sure -D send to cc1.
+// CHECK:"-D" "TEST=2"
+
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -3471,9 +3471,9 @@
 
 static void RenderHLSLOptions(const ArgList , ArgStringList ,
   types::ID InputType) {
-  const unsigned ForwardedArguments[] = {options::OPT_dxil_validator_version,
- options::OPT_S, 
options::OPT_emit_llvm,
- options::OPT_disable_llvm_passes};
+  const unsigned ForwardedArguments[] = {
+  options::OPT_dxil_validator_version, options::OPT_D, options::OPT_S,
+  options::OPT_emit_llvm, options::OPT_disable_llvm_passes};
 
   for (const auto  : ForwardedArguments)
 if (const auto *A = Args.getLastArg(Arg))
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -6758,6 +6758,8 @@
  "lib_6_3, lib_6_4, lib_6_5, lib_6_6, lib_6_7, lib_6_x,"
  "ms_6_5, ms_6_6, ms_6_7,"
  "as_6_5, as_6_6, as_6_7">;
+def dxc_D : Option<["--", "/", "-"], "D", KIND_JOINED_OR_SEPARATE>,
+  Group, Flags<[DXCOption, NoXarchOption]>, Alias;
 def emit_pristine_llvm : DXCFlag<"emit-pristine-llvm">,
   HelpText<"Emit pristine LLVM IR from the frontend by not running any LLVM 
passes at all."
"Same as -S + -emit-llvm + -disable-llvm-passes.">;


Index: clang/test/Driver/dxc_D.hlsl
===
--- /dev/null
+++ clang/test/Driver/dxc_D.hlsl
@@ -0,0 +1,5 @@
+// RUN: %clang_dxc -DTEST=2 foo.hlsl -### %s 2>&1 | FileCheck %s
+
+// Make sure -D send to cc1.
+// CHECK:"-D" "TEST=2"
+
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -3471,9 +3471,9 @@
 
 static void RenderHLSLOptions(const ArgList , ArgStringList ,
   types::ID InputType) {
-  const unsigned ForwardedArguments[] = {options::OPT_dxil_validator_version,
- options::OPT_S, options::OPT_emit_llvm,
- options::OPT_disable_llvm_passes};
+  const unsigned ForwardedArguments[] = {
+  options::OPT_dxil_validator_version, options::OPT_D, options::OPT_S,
+  options::OPT_emit_llvm, options::OPT_disable_llvm_passes};
 
   for (const auto  : ForwardedArguments)
 if (const auto *A = Args.getLastArg(Arg))
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -6758,6 +6758,8 @@
  "lib_6_3, lib_6_4, lib_6_5, lib_6_6, lib_6_7, lib_6_x,"
  "ms_6_5, ms_6_6, ms_6_7,"
  "as_6_5, as_6_6, as_6_7">;
+def dxc_D : Option<["--", "/", "-"], "D", KIND_JOINED_OR_SEPARATE>,
+  Group, Flags<[DXCOption, NoXarchOption]>, Alias;
 def emit_pristine_llvm : DXCFlag<"emit-pristine-llvm">,
   HelpText<"Emit pristine LLVM IR from the frontend by not running any LLVM passes at all."
"Same as -S + -emit-llvm + -disable-llvm-passes.">;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D124750: [MLIR] Add a utility to sort the operands of commutative ops

[Srishti Srivastava via Phabricator via cfe-commits]

srishti-pm updated this revision to Diff 428498.
srishti-pm added a comment.

Improving the documentation of the functionality of this utility to make it 
more clear.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124750

Files:
  clang/docs/tools/clang-formatted-files.txt
  mlir/include/mlir/Transforms/CommutativityUtils.h
  mlir/lib/Transforms/Utils/CMakeLists.txt
  mlir/lib/Transforms/Utils/CommutativityUtils.cpp
  mlir/test/Transforms/test-commutativity-utils.mlir
  mlir/test/lib/Dialect/Test/TestOps.td
  mlir/test/lib/Transforms/CMakeLists.txt
  mlir/test/lib/Transforms/TestCommutativityUtils.cpp
  mlir/tools/mlir-opt/mlir-opt.cpp

Index: mlir/tools/mlir-opt/mlir-opt.cpp
===
--- mlir/tools/mlir-opt/mlir-opt.cpp
+++ mlir/tools/mlir-opt/mlir-opt.cpp
@@ -56,6 +56,7 @@
 void registerVectorizerTestPass();
 
 namespace test {
+void registerCommutativityUtils();
 void registerConvertCallOpPass();
 void registerInliner();
 void registerMemRefBoundCheck();
@@ -146,6 +147,7 @@
   registerVectorizerTestPass();
   registerTosaTestQuantUtilAPIPass();
 
+  mlir::test::registerCommutativityUtils();
   mlir::test::registerConvertCallOpPass();
   mlir::test::registerInliner();
   mlir::test::registerMemRefBoundCheck();
Index: mlir/test/lib/Transforms/TestCommutativityUtils.cpp
===
--- /dev/null
+++ mlir/test/lib/Transforms/TestCommutativityUtils.cpp
@@ -0,0 +1,67 @@
+//===- TestCommutativityUtils.cpp - Pass to test the commutativity utility-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This pass tests the functionality of the commutativity utility.
+//
+//===--===//
+
+#include "mlir/Transforms/CommutativityUtils.h"
+
+#include "TestDialect.h"
+#include "mlir/Pass/Pass.h"
+#include "mlir/Transforms/GreedyPatternRewriteDriver.h"
+
+using namespace mlir;
+using namespace test;
+
+namespace {
+
+struct SmallPattern : public OpRewritePattern {
+  using OpRewritePattern::OpRewritePattern;
+  LogicalResult matchAndRewrite(TestCommutativeOp testCommOp,
+PatternRewriter ) const override {
+sortCommutativeOperands(testCommOp.getOperation(), rewriter);
+return success();
+  }
+};
+
+struct LargePattern : public OpRewritePattern {
+  using OpRewritePattern::OpRewritePattern;
+  LogicalResult matchAndRewrite(TestLargeCommutativeOp testLargeCommOp,
+PatternRewriter ) const override {
+sortCommutativeOperands(testLargeCommOp.getOperation(), rewriter);
+return success();
+  }
+};
+
+struct CommutativityUtils
+: public PassWrapper> {
+  MLIR_DEFINE_EXPLICIT_INTERNAL_INLINE_TYPE_ID(CommutativityUtils)
+
+  StringRef getArgument() const final { return "test-commutativity-utils"; }
+  StringRef getDescription() const final {
+return "Test the functionality of the commutativity utility";
+  }
+
+  void runOnOperation() override {
+auto func = getOperation();
+auto *context = ();
+
+RewritePatternSet patterns(context);
+patterns.add(context);
+
+(void)applyPatternsAndFoldGreedily(func, std::move(patterns));
+  }
+};
+} // namespace
+
+namespace mlir {
+namespace test {
+void registerCommutativityUtils() { PassRegistration(); }
+} // namespace test
+} // namespace mlir
Index: mlir/test/lib/Transforms/CMakeLists.txt
===
--- mlir/test/lib/Transforms/CMakeLists.txt
+++ mlir/test/lib/Transforms/CMakeLists.txt
@@ -1,5 +1,6 @@
 # Exclude tests from libMLIR.so
 add_mlir_library(MLIRTestTransforms
+  TestCommutativityUtils.cpp
   TestConstantFold.cpp
   TestControlFlowSink.cpp
   TestInlining.cpp
Index: mlir/test/lib/Dialect/Test/TestOps.td
===
--- mlir/test/lib/Dialect/Test/TestOps.td
+++ mlir/test/lib/Dialect/Test/TestOps.td
@@ -1101,11 +1101,21 @@
   let hasFolder = 1;
 }
 
+def TestAddIOp : TEST_Op<"addi"> {
+  let arguments = (ins I32:$op1, I32:$op2);
+  let results = (outs I32);
+}
+
 def TestCommutativeOp : TEST_Op<"op_commutative", [Commutative]> {
   let arguments = (ins I32:$op1, I32:$op2, I32:$op3, I32:$op4);
   let results = (outs I32);
 }
 
+def TestLargeCommutativeOp : TEST_Op<"op_large_commutative", [Commutative]> {
+  let arguments = (ins I32:$op1, I32:$op2, I32:$op3, I32:$op4, I32:$op5, I32:$op6, I32:$op7);
+  let results = (outs I32);
+}
+
 def TestCommutative2Op : TEST_Op<"op_commutative2", [Commutative]> {
   let arguments = (ins I32:$op1, I32:$op2);
   let 

[PATCH] D124534: [clang] Add a diagnostic for line directive of a gnu extension

[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, thank you for all the hard work on this! I assume you need me to land 
this on your behalf -- if so, can you let me know what name and email address 
you would like me to use for patch attribution?

I think we should add a release note for this to let folks know about the new 
warning group (there's a "Improvements to Clang's diagnostics" in 
clang/docs/ReleaseNotes.rst). You can either add one to this patch, or I can 
add one for you when I go to land, I'm fine either way.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124534

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

[PATCH] D125330: [OpenMP] Fix mangling for linear modifiers with variable stride

[Mike Rice 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 rG0dbaef61b56f: [OpenMP] Fix mangling for linear modifiers 
with variable stride (authored by mikerice).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125330

Files:
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/test/OpenMP/declare_simd_codegen.cpp

Index: clang/test/OpenMP/declare_simd_codegen.cpp
===
--- clang/test/OpenMP/declare_simd_codegen.cpp
+++ clang/test/OpenMP/declare_simd_codegen.cpp
@@ -144,6 +144,17 @@
   return a;
 }
 
+// Test reference parameters with variable stride.
+#pragma omp declare simd simdlen(4) uniform(a)   \
+ linear(b:2) linear(c:a) \
+ linear(val(d):4) linear(val(e):a)   \
+ linear(uval(f):8) linear(uval(g):a) \
+ linear(ref(h):16) linear(ref(i):a)
+double Five(int a, short , short , short , short , short , short ,
+short , short ) {
+  return a + int(b);
+}
+
 // CHECK-DAG: define {{.+}}@_Z5add_1Pf(
 // CHECK-DAG: define {{.+}}@_Z1hIiEvPT_S1_S1_S1_(
 // CHECK-DAG: define {{.+}}@_Z1hIfEvPT_S1_S1_S1_(
@@ -162,6 +173,11 @@
 // CHECK-DAG: define {{.+}}@_Z3food(
 // CHECK-DAG: declare {{.+}}@_Z5add_2Pf(
 // CHECK-DAG: define {{.+}}@_Z11constlineari(
+// CHECK-DAG: define {{.+}}@_Z3OneRiPiiS_S0_i
+// CHECK-DAG: define {{.+}}@_Z3TwoRiPiiS_S0_i
+// CHECK-DAG: define {{.+}}@_Z5ThreeRiS_
+// CHECK-DAG: define {{.+}}@_Z4FourRiS_
+// CHECK-DAG: define {{.+}}@_Z4FiveiRsS_S_S_S_S_S_S_
 
 // CHECK-DAG: "_ZGVbM4l32__Z5add_1Pf"
 // CHECK-DAG: "_ZGVbN4l32__Z5add_1Pf"
@@ -381,6 +397,8 @@
 // CHECK-DAG: "_ZGVbN4U2U__Z5ThreeRiS_"
 // CHECK-DAG: "_ZGVbM4R8R4__Z4FourRiS_"
 // CHECK-DAG: "_ZGVbN4R8R4__Z4FourRiS_"
+// CHECK-DAG: "_ZGVbM4uL2Ls0L4Ls0U8Us0R32Rs0__Z4FiveiRsS_S_S_S_S_S_S_"
+// CHECK-DAG: "_ZGVbN4uL2Ls0L4Ls0U8Us0R32Rs0__Z4FiveiRsS_S_S_S_S_S_S_"
 
 // CHECK-NOT: "_ZGV{{.+}}__Z1fRA_i
 
Index: clang/lib/CodeGen/CGOpenMPRuntime.cpp
===
--- clang/lib/CodeGen/CGOpenMPRuntime.cpp
+++ clang/lib/CodeGen/CGOpenMPRuntime.cpp
@@ -11405,7 +11405,6 @@
 namespace {
   /// Kind of parameter in a function with 'declare simd' directive.
 enum ParamKindTy {
-  LinearWithVarStride,
   Linear,
   LinearRef,
   LinearUVal,
@@ -11418,6 +11417,7 @@
   ParamKindTy Kind = Vector;
   llvm::APSInt StrideOrArg;
   llvm::APSInt Alignment;
+  bool HasVarStride = false;
 };
 } // namespace
 
@@ -11481,9 +11481,6 @@
   llvm::raw_svector_ostream Out(Buffer);
   for (const auto  : ParamAttrs) {
 switch (ParamAttr.Kind) {
-case LinearWithVarStride:
-  Out << "ls" << ParamAttr.StrideOrArg;
-  break;
 case Linear:
   Out << 'l';
   break;
@@ -11503,8 +11500,10 @@
   Out << 'v';
   break;
 }
-if (ParamAttr.Kind == Linear || ParamAttr.Kind == LinearRef ||
-ParamAttr.Kind == LinearUVal || ParamAttr.Kind == LinearVal) {
+if (ParamAttr.HasVarStride)
+  Out << "s" << ParamAttr.StrideOrArg;
+else if (ParamAttr.Kind == Linear || ParamAttr.Kind == LinearRef ||
+ ParamAttr.Kind == LinearUVal || ParamAttr.Kind == LinearVal) {
   // Don't print the step value if it is not present or if it is
   // equal to 1.
   if (ParamAttr.StrideOrArg != 1)
@@ -11579,11 +11578,7 @@
 // available at
 // https://developer.arm.com/products/software-development-tools/hpc/arm-compiler-for-hpc/vector-function-abi.
 
-/// Maps To Vector (MTV), as defined in 3.1.1 of the AAVFABI.
-///
-/// TODO: Need to implement the behavior for reference marked with a
-/// var or no linear modifiers (1.b in the section). For this, we
-/// need to extend ParamKindTy to support the linear modifiers.
+/// Maps To Vector (MTV), as defined in 4.1.1 of the AAVFABI (2021Q1).
 static bool getAArch64MTV(QualType QT, ParamKindTy Kind) {
   QT = QT.getCanonicalType();
 
@@ -11593,12 +11588,11 @@
   if (Kind == ParamKindTy::Uniform)
 return false;
 
-  if (Kind == ParamKindTy::Linear)
+  if (Kind == ParamKindTy::LinearUVal || ParamKindTy::LinearRef)
 return false;
 
-  // TODO: Handle linear references with modifiers
-
-  if (Kind == ParamKindTy::LinearWithVarStride)
+  if ((Kind == ParamKindTy::Linear || Kind == ParamKindTy::LinearVal) &&
+  !QT->isReferenceType())
 return false;
 
   return true;
@@ -11949,7 +11943,7 @@
 cast((*SI)->IgnoreParenImpCasts())) {
   if (const auto *StridePVD =
   dyn_cast(DRE->getDecl())) {
-ParamAttr.Kind = LinearWithVarStride;
+ParamAttr.HasVarStride = true;
 auto It = 

[clang] 0dbaef6 - [OpenMP] Fix mangling for linear modifiers with variable stride

[Mike Rice via cfe-commits]

Author: Mike Rice
Date: 2022-05-10T14:12:44-07:00
New Revision: 0dbaef61b56f0ef0ab0cf38ea92ffc1f35bee3ff

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

LOG: [OpenMP] Fix mangling for linear modifiers with variable stride

This adds support for variable stride with the val, uval, and ref linear
modifiers.  Previously only the no modifer type ls was supported.

  val  -> Ls
  uval -> Us
  ref  -> Rs

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

Added: 


Modified: 
clang/lib/CodeGen/CGOpenMPRuntime.cpp
clang/test/OpenMP/declare_simd_codegen.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGOpenMPRuntime.cpp 
b/clang/lib/CodeGen/CGOpenMPRuntime.cpp
index d938bda157f9d..52f6ca4cfb3d0 100644
--- a/clang/lib/CodeGen/CGOpenMPRuntime.cpp
+++ b/clang/lib/CodeGen/CGOpenMPRuntime.cpp
@@ -11405,7 +11405,6 @@ void CGOpenMPRuntime::emitTargetDataStandAloneCall(
 namespace {
   /// Kind of parameter in a function with 'declare simd' directive.
 enum ParamKindTy {
-  LinearWithVarStride,
   Linear,
   LinearRef,
   LinearUVal,
@@ -11418,6 +11417,7 @@ struct ParamAttrTy {
   ParamKindTy Kind = Vector;
   llvm::APSInt StrideOrArg;
   llvm::APSInt Alignment;
+  bool HasVarStride = false;
 };
 } // namespace
 
@@ -11481,9 +11481,6 @@ static std::string 
mangleVectorParameters(ArrayRef ParamAttrs) {
   llvm::raw_svector_ostream Out(Buffer);
   for (const auto  : ParamAttrs) {
 switch (ParamAttr.Kind) {
-case LinearWithVarStride:
-  Out << "ls" << ParamAttr.StrideOrArg;
-  break;
 case Linear:
   Out << 'l';
   break;
@@ -11503,8 +11500,10 @@ static std::string 
mangleVectorParameters(ArrayRef ParamAttrs) {
   Out << 'v';
   break;
 }
-if (ParamAttr.Kind == Linear || ParamAttr.Kind == LinearRef ||
-ParamAttr.Kind == LinearUVal || ParamAttr.Kind == LinearVal) {
+if (ParamAttr.HasVarStride)
+  Out << "s" << ParamAttr.StrideOrArg;
+else if (ParamAttr.Kind == Linear || ParamAttr.Kind == LinearRef ||
+ ParamAttr.Kind == LinearUVal || ParamAttr.Kind == LinearVal) {
   // Don't print the step value if it is not present or if it is
   // equal to 1.
   if (ParamAttr.StrideOrArg != 1)
@@ -11579,11 +11578,7 @@ emitX86DeclareSimdFunction(const FunctionDecl *FD, 
llvm::Function *Fn,
 // available at
 // 
https://developer.arm.com/products/software-development-tools/hpc/arm-compiler-for-hpc/vector-function-abi.
 
-/// Maps To Vector (MTV), as defined in 3.1.1 of the AAVFABI.
-///
-/// TODO: Need to implement the behavior for reference marked with a
-/// var or no linear modifiers (1.b in the section). For this, we
-/// need to extend ParamKindTy to support the linear modifiers.
+/// Maps To Vector (MTV), as defined in 4.1.1 of the AAVFABI (2021Q1).
 static bool getAArch64MTV(QualType QT, ParamKindTy Kind) {
   QT = QT.getCanonicalType();
 
@@ -11593,12 +11588,11 @@ static bool getAArch64MTV(QualType QT, ParamKindTy 
Kind) {
   if (Kind == ParamKindTy::Uniform)
 return false;
 
-  if (Kind == ParamKindTy::Linear)
+  if (Kind == ParamKindTy::LinearUVal || ParamKindTy::LinearRef)
 return false;
 
-  // TODO: Handle linear references with modifiers
-
-  if (Kind == ParamKindTy::LinearWithVarStride)
+  if ((Kind == ParamKindTy::Linear || Kind == ParamKindTy::LinearVal) &&
+  !QT->isReferenceType())
 return false;
 
   return true;
@@ -11949,7 +11943,7 @@ void CGOpenMPRuntime::emitDeclareSimdFunction(const 
FunctionDecl *FD,
 cast((*SI)->IgnoreParenImpCasts())) {
   if (const auto *StridePVD =
   dyn_cast(DRE->getDecl())) {
-ParamAttr.Kind = LinearWithVarStride;
+ParamAttr.HasVarStride = true;
 auto It = ParamPositions.find(StridePVD->getCanonicalDecl());
 assert(It != ParamPositions.end() &&
"Function parameter not found");
@@ -11963,7 +11957,8 @@ void CGOpenMPRuntime::emitDeclareSimdFunction(const 
FunctionDecl *FD,
 // If we are using a linear clause on a pointer, we need to
 // rescale the value of linear_step with the byte size of the
 // pointee type.
-if (ParamAttr.Kind == Linear || ParamAttr.Kind == LinearRef)
+if (!ParamAttr.HasVarStride &&
+(ParamAttr.Kind == Linear || ParamAttr.Kind == LinearRef))
   ParamAttr.StrideOrArg = ParamAttr.StrideOrArg * PtrRescalingFactor;
 ++SI;
 ++MI;

diff  --git a/clang/test/OpenMP/declare_simd_codegen.cpp 
b/clang/test/OpenMP/declare_simd_codegen.cpp
index 5a5df239f870a..fa0be2acc192f 100644
--- a/clang/test/OpenMP/declare_simd_codegen.cpp
+++ b/clang/test/OpenMP/declare_simd_codegen.cpp
@@ -144,6 +144,17 @@ double Four(int& a, int ) {
   

[PATCH] D124038: [clang] Prevent folding of non-const compound expr

[Eli Friedman via Phabricator via cfe-commits]

efriedma added a comment.

I think so, yes.


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

https://reviews.llvm.org/D124038

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

[PATCH] D123534: [dwarf] Emit a DIGlobalVariable for constant strings.

[Mitch Phillips via Phabricator via cfe-commits]

hctim added a comment.

In D123534#3489262 , @dblaikie wrote:

> @rnk @aprantl @probinson: this looks plausible to me to take as a general 
> change to the emitted DWARF, but I'm open to ideas/suggestions if folks find 
> this to be too much growth for not enough benefit & that it should be behind 
> a flag?

Friendly ping @rnk @aprantl @probinson, do you folks have any feedback?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123534

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

[clang] 0376c0f - Revert "[utils] Avoid hardcoding metadata ids in update_cc_test_checks"

[Jan Korous via cfe-commits]

Author: Jan Korous
Date: 2022-05-10T14:04:19-07:00
New Revision: 0376c0f271398147b3df79ab20ffb2f375e47215

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

LOG: Revert "[utils] Avoid hardcoding metadata ids in update_cc_test_checks"

This reverts commit ce583b14b2ec37b1c168bb92020680cb452502b3.

Added: 


Modified: 
llvm/utils/UpdateTestChecks/common.py

Removed: 
clang/test/utils/update_cc_test_checks/Inputs/annotation-id.c
clang/test/utils/update_cc_test_checks/Inputs/annotation-id.expected
clang/test/utils/update_cc_test_checks/Inputs/nosanitize-id.c
clang/test/utils/update_cc_test_checks/Inputs/nosanitize-id.expected
clang/test/utils/update_cc_test_checks/Inputs/srcloc-id.c
clang/test/utils/update_cc_test_checks/Inputs/srcloc-id.expected
clang/test/utils/update_cc_test_checks/Inputs/tbaa-id.c
clang/test/utils/update_cc_test_checks/Inputs/tbaa-id.expected
clang/test/utils/update_cc_test_checks/Inputs/tbaa-struct-id.c
clang/test/utils/update_cc_test_checks/Inputs/tbaa-struct-id.expected
clang/test/utils/update_cc_test_checks/annotation-id.test
clang/test/utils/update_cc_test_checks/nosanitize-id.test
clang/test/utils/update_cc_test_checks/srcloc-id.test
clang/test/utils/update_cc_test_checks/tbaa-id.test
clang/test/utils/update_cc_test_checks/tbaa-struct-id.test



diff  --git a/clang/test/utils/update_cc_test_checks/Inputs/annotation-id.c 
b/clang/test/utils/update_cc_test_checks/Inputs/annotation-id.c
deleted file mode 100644
index 49c7c58375db5..0
--- a/clang/test/utils/update_cc_test_checks/Inputs/annotation-id.c
+++ /dev/null
@@ -1,5 +0,0 @@
-// RUN: %clang_cc1 -ftrivial-auto-var-init=zero 
-triple=x86_64-unknown-linux-gnu -O1 -disable-llvm-passes -emit-llvm -o - %s | 
FileCheck %s
-
-void foo_ptr_to_scalar() {
-  unsigned long long* a[100];
-}

diff  --git 
a/clang/test/utils/update_cc_test_checks/Inputs/annotation-id.expected 
b/clang/test/utils/update_cc_test_checks/Inputs/annotation-id.expected
deleted file mode 100644
index d28469eb920dc..0
--- a/clang/test/utils/update_cc_test_checks/Inputs/annotation-id.expected
+++ /dev/null
@@ -1,17 +0,0 @@
-// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
-// RUN: %clang_cc1 -ftrivial-auto-var-init=zero 
-triple=x86_64-unknown-linux-gnu -O1 -disable-llvm-passes -emit-llvm -o - %s | 
FileCheck %s
-
-// CHECK-LABEL: @foo_ptr_to_scalar(
-// CHECK-NEXT:  entry:
-// CHECK-NEXT:[[A:%.*]] = alloca [100 x i64*], align 16
-// CHECK-NEXT:[[TMP0:%.*]] = bitcast [100 x i64*]* [[A]] to i8*
-// CHECK-NEXT:call void @llvm.lifetime.start.p0i8(i64 800, i8* [[TMP0]]) 
#[[ATTR3:[0-9]+]]
-// CHECK-NEXT:[[TMP1:%.*]] = bitcast [100 x i64*]* [[A]] to i8*
-// CHECK-NEXT:call void @llvm.memset.p0i8.i64(i8* align 16 [[TMP1]], i8 0, 
i64 800, i1 false), !annotation [[ANNT2:![0-9]+]]
-// CHECK-NEXT:[[TMP2:%.*]] = bitcast [100 x i64*]* [[A]] to i8*
-// CHECK-NEXT:call void @llvm.lifetime.end.p0i8(i64 800, i8* [[TMP2]]) 
#[[ATTR3]]
-// CHECK-NEXT:ret void
-//
-void foo_ptr_to_scalar() {
-  unsigned long long* a[100];
-}

diff  --git a/clang/test/utils/update_cc_test_checks/Inputs/nosanitize-id.c 
b/clang/test/utils/update_cc_test_checks/Inputs/nosanitize-id.c
deleted file mode 100644
index d136a861b4214..0
--- a/clang/test/utils/update_cc_test_checks/Inputs/nosanitize-id.c
+++ /dev/null
@@ -1,5 +0,0 @@
-// RUN: %clang_cc1 -fsanitize=shift-exponent,shift-base 
-triple=x86_64-unknown-linux-gnu -O1 -disable-llvm-passes -emit-llvm -o - %s | 
FileCheck %s
-
-void foo(int* c, int* shamt) {
-  *c = 1 << (*c << *shamt);
-}

diff  --git 
a/clang/test/utils/update_cc_test_checks/Inputs/nosanitize-id.expected 
b/clang/test/utils/update_cc_test_checks/Inputs/nosanitize-id.expected
deleted file mode 100644
index e8e1c74e46bc6..0
--- a/clang/test/utils/update_cc_test_checks/Inputs/nosanitize-id.expected
+++ /dev/null
@@ -1,55 +0,0 @@
-// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
-// RUN: %clang_cc1 -fsanitize=shift-exponent,shift-base 
-triple=x86_64-unknown-linux-gnu -O1 -disable-llvm-passes -emit-llvm -o - %s | 
FileCheck %s
-
-// CHECK-LABEL: @foo(
-// CHECK-NEXT:  entry:
-// CHECK-NEXT:[[C_ADDR:%.*]] = alloca i32*, align 8
-// CHECK-NEXT:[[SHAMT_ADDR:%.*]] = alloca i32*, align 8
-// CHECK-NEXT:store i32* [[C:%.*]], i32** [[C_ADDR]], align 8, !tbaa 
[[TBAA2:![0-9]+]]
-// CHECK-NEXT:store i32* [[SHAMT:%.*]], i32** [[SHAMT_ADDR]], align 8, 
!tbaa [[TBAA2]]
-// CHECK-NEXT:[[TMP0:%.*]] = load i32*, i32** [[C_ADDR]], align 8, !tbaa 
[[TBAA2]]
-// CHECK-NEXT:[[TMP1:%.*]] = load i32, i32* [[TMP0]], align 4, !tbaa 
[[TBAA6:![0-9]+]]
-// CHECK-NEXT:

[PATCH] D123273: [utils] Avoid hardcoding metadata ids in update_cc_test_checks

[Jan Korous via Phabricator via cfe-commits]

jkorous added a comment.

Reverting for now. Will take a look.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123273

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

[PATCH] D124038: [clang] Prevent folding of non-const compound expr

[serge via Phabricator via cfe-commits]

serge-sans-paille added a comment.

In D124038#3504371 , @efriedma wrote:

> I think you're looking at old documentation?  Here's what the current page 
> (https://gcc.gnu.org/onlinedocs/gcc/Compound-Literals.html) has to say:

Indeed! I was looking at my local Info Page. thanks for the extra pointer.

>> As an optimization, G++ sometimes gives array compound literals longer 
>> lifetimes: when the array either appears outside a function or has a 
>> const-qualified type. If foo and its initializer had elements of type char 
>> *const rather than char *, or if foo were a global variable, the array would 
>> have static storage duration. But it is probably safest just to avoid the 
>> use of array compound literals in C++ code.

I can quote that part instead. I don't think this invalidates the actual code, 
right? At least with that commit the observable behavior gets closer to GCC, 
and it fixes https://github.com/llvm/llvm-project/issues/39324


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

https://reviews.llvm.org/D124038

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

[PATCH] D123273: [utils] Avoid hardcoding metadata ids in update_cc_test_checks

[Jake Egan via Phabricator via cfe-commits]

Jake-Egan added a comment.

4 of the tests fail on AIX also: 
https://lab.llvm.org/buildbot/#/builders/214/builds/1207


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123273

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

[clang] eadeabb - [NFC] Replace not-null and not-isa check with a not-isa_and_nonnull

[Erich Keane via cfe-commits]

Author: Erich Keane
Date: 2022-05-10T13:34:07-07:00
New Revision: eadeabbe10f5096b12e488e7bd8e2292429b5e08

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

LOG: [NFC] Replace not-null and not-isa check with a not-isa_and_nonnull

Added: 


Modified: 
clang/lib/Sema/AnalysisBasedWarnings.cpp

Removed: 




diff  --git a/clang/lib/Sema/AnalysisBasedWarnings.cpp 
b/clang/lib/Sema/AnalysisBasedWarnings.cpp
index bf282bbb400dc..164fea6a449b5 100644
--- a/clang/lib/Sema/AnalysisBasedWarnings.cpp
+++ b/clang/lib/Sema/AnalysisBasedWarnings.cpp
@@ -1272,7 +1272,7 @@ static void DiagnoseSwitchLabelsFallthrough(Sema , 
AnalysisDeclContext ,
   for (const CFGBlock *B : llvm::reverse(*Cfg)) {
 const Stmt *Label = B->getLabel();
 
-if (!Label || !isa(Label))
+if (!isa_and_nonnull(Label))
   continue;
 
 int AnnotatedCnt;



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

[PATCH] D124874: [clang] add -fmodule-file-home-is-cwd

[Richard Howell via Phabricator via cfe-commits]

rmaz updated this revision to Diff 428483.
rmaz added a comment.

Refactor branch into existing case


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124874

Files:
  clang/include/clang/Driver/Options.td
  clang/include/clang/Lex/HeaderSearchOptions.h
  clang/lib/Serialization/ASTWriter.cpp
  clang/test/Modules/module-file-home-is-cwd.m


Index: clang/test/Modules/module-file-home-is-cwd.m
===
--- /dev/null
+++ clang/test/Modules/module-file-home-is-cwd.m
@@ -0,0 +1,8 @@
+// RUN: cd %S
+// RUN: %clang_cc1 -fmodules -fno-implicit-modules -fmodule-file-home-is-cwd 
-fmodule-name=libA -emit-module Inputs/normal-module-map/module.map -o 
%t/mod.pcm
+// RUN: llvm-bcanalyzer --dump --disable-histogram %t/mod.pcm | FileCheck %s
+
+// CHECK:  blob data = 
'Inputs{{/|\\}}normal-module-map{{/|\\}}a1.h'
+// CHECK:  blob data = 
'Inputs{{/|\\}}normal-module-map{{/|\\}}a2.h'
+// CHECK:  blob data = 
'Inputs{{/|\\}}normal-module-map{{/|\\}}module.map'
+// CHECK-NOT: MODULE_DIRECTORY
Index: clang/lib/Serialization/ASTWriter.cpp
===
--- clang/lib/Serialization/ASTWriter.cpp
+++ clang/lib/Serialization/ASTWriter.cpp
@@ -1224,15 +1224,24 @@
   }
 
   if (WritingModule && WritingModule->Directory) {
-SmallString<128> BaseDir(WritingModule->Directory->getName());
+SmallString<128> BaseDir;
+if (PP.getHeaderSearchInfo().getHeaderSearchOpts().ModuleFileHomeIsCwd) {
+  // Use the current working directory as the base path for all inputs.
+  auto *CWD =
+  Context.getSourceManager().getFileManager().getDirectory(".").get();
+  BaseDir.assign(CWD->getName());
+} else {
+  BaseDir.assign(WritingModule->Directory->getName());
+}
 cleanPathForOutput(Context.getSourceManager().getFileManager(), BaseDir);
 
 // If the home of the module is the current working directory, then we
 // want to pick up the cwd of the build process loading the module, not
 // our cwd, when we load this module.
-if (!PP.getHeaderSearchInfo()
- .getHeaderSearchOpts()
- .ModuleMapFileHomeIsCwd ||
+if (!(PP.getHeaderSearchInfo()
+  .getHeaderSearchOpts()
+  .ModuleMapFileHomeIsCwd ||
+  PP.getHeaderSearchInfo().getHeaderSearchOpts().ModuleFileHomeIsCwd) 
||
 WritingModule->Directory->getName() != StringRef(".")) {
   // Module directory.
   auto Abbrev = std::make_shared();
Index: clang/include/clang/Lex/HeaderSearchOptions.h
===
--- clang/include/clang/Lex/HeaderSearchOptions.h
+++ clang/include/clang/Lex/HeaderSearchOptions.h
@@ -143,6 +143,12 @@
   /// file.
   unsigned ModuleMapFileHomeIsCwd : 1;
 
+  /// Set the base path of a built module file to be the current working
+  /// directory. This is useful for sharing module files across machines
+  /// that build with different paths without having to rewrite all
+  /// modulemap files to have working directory relative paths.
+  unsigned ModuleFileHomeIsCwd : 1;
+
   /// Also search for prebuilt implicit modules in the prebuilt module cache
   /// path.
   unsigned EnablePrebuiltImplicitModules : 1;
@@ -222,9 +228,9 @@
   HeaderSearchOptions(StringRef _Sysroot = "/")
   : Sysroot(_Sysroot), ModuleFormat("raw"), DisableModuleHash(false),
 ImplicitModuleMaps(false), ModuleMapFileHomeIsCwd(false),
-EnablePrebuiltImplicitModules(false), UseBuiltinIncludes(true),
-UseStandardSystemIncludes(true), UseStandardCXXIncludes(true),
-UseLibcxx(false), Verbose(false),
+ModuleFileHomeIsCwd(false), EnablePrebuiltImplicitModules(false),
+UseBuiltinIncludes(true), UseStandardSystemIncludes(true),
+UseStandardCXXIncludes(true), UseLibcxx(false), Verbose(false),
 ModulesValidateOncePerBuildSession(false),
 ModulesValidateSystemHeaders(false),
 ValidateASTInputFilesContent(false), UseDebugInfo(false),
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -5609,6 +5609,10 @@
   HelpText<"Use the current working directory as the home directory of "
"module maps specified by -fmodule-map-file=">,
   MarshallingInfoFlag>;
+def fmodule_file_home_is_cwd : Flag<["-"], "fmodule-file-home-is-cwd">,
+  HelpText<"Use the current working directory as the base directory of "
+   "compiled module files.">,
+  MarshallingInfoFlag>;
 def fmodule_feature : Separate<["-"], "fmodule-feature">,
   MetaVarName<"">,
   HelpText<"Enable  in module map requires declarations">,


Index: clang/test/Modules/module-file-home-is-cwd.m
===

[PATCH] D125006: [pseudo] Support parsing variant target symbols.

[Haojian Wu via Phabricator via cfe-commits]

hokein marked 3 inline comments as done.
hokein added inline comments.



Comment at: clang-tools-extra/pseudo/include/clang-pseudo/GLR.h:125
 };
-// Parse the given token stream with the GLR algorithm, and return a forest 
node
-// of the start symbol.

sammccall wrote:
> From the caller's perspective, is "target symbol" really a clearer name than 
> "start symbol"? The latter seems like more common terminology.
I'd like to call it `start symbol` as well, it is clearer.

The only downside is that we're diverging from the standard LR literature (`_` 
is the start symbol of the augmented grammar). We need a name for the symbol 
`_`, I rename the `Grammar::startSymbol` to `Grammar::underscore` (or even 
`_`?), please take a look on this patch again.



Comment at: clang-tools-extra/pseudo/include/clang-pseudo/Grammar.h:188
+// Name must be a valid nonterminal symbol name in the grammar.
+SymbolID findNonterminal(llvm::StringRef Name,
+ const clang::pseudo::GrammarTable );

it is unfortunate that we put this function in the Grammar.h. This could be 
avoided when we have the generated enum grammar type, but we are not there 
yet...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125006

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

[PATCH] D125006: [pseudo] Support parsing variant target symbols.

[Haojian Wu via Phabricator via cfe-commits]

hokein updated this revision to Diff 428479.
hokein marked 3 inline comments as done.
hokein added a comment.

- adress comments
- rename TargetSymbol -> StartSymbol
- don't use StartSymbol for "_", rename and update a few occurrences
- move findNonterminal to Grammar.h since it is used in various places


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125006

Files:
  clang-tools-extra/pseudo/benchmarks/Benchmark.cpp
  clang-tools-extra/pseudo/fuzzer/Fuzzer.cpp
  clang-tools-extra/pseudo/include/clang-pseudo/GLR.h
  clang-tools-extra/pseudo/include/clang-pseudo/Grammar.h
  clang-tools-extra/pseudo/include/clang-pseudo/LRGraph.h
  clang-tools-extra/pseudo/include/clang-pseudo/LRTable.h
  clang-tools-extra/pseudo/lib/GLR.cpp
  clang-tools-extra/pseudo/lib/Grammar.cpp
  clang-tools-extra/pseudo/lib/LRGraph.cpp
  clang-tools-extra/pseudo/lib/LRTable.cpp
  clang-tools-extra/pseudo/lib/LRTableBuild.cpp
  clang-tools-extra/pseudo/lib/cxx.bnf
  clang-tools-extra/pseudo/test/glr-variant-start.cpp
  clang-tools-extra/pseudo/tool/ClangPseudo.cpp
  clang-tools-extra/pseudo/unittests/GLRTest.cpp
  clang-tools-extra/pseudo/unittests/GrammarTest.cpp

Index: clang-tools-extra/pseudo/unittests/GrammarTest.cpp
===
--- clang-tools-extra/pseudo/unittests/GrammarTest.cpp
+++ clang-tools-extra/pseudo/unittests/GrammarTest.cpp
@@ -112,7 +112,7 @@
 b := a
   )cpp");
 
-  EXPECT_EQ(G->startSymbol(), id("_"));
+  EXPECT_EQ(G->underscore(), id("_"));
   EXPECT_THAT(Diags, UnorderedElementsAre(
  "Rule '_ := ,_opt' has a nullable RHS",
  "Rule 'null := ' has a nullable RHS",
Index: clang-tools-extra/pseudo/unittests/GLRTest.cpp
===
--- clang-tools-extra/pseudo/unittests/GLRTest.cpp
+++ clang-tools-extra/pseudo/unittests/GLRTest.cpp
@@ -344,7 +344,8 @@
   const TokenStream  = cook(lex("{ abc", LOptions), LOptions);
   auto LRTable = LRTable::buildSLR(*G);
 
-  const ForestNode  = glrParse(Tokens, {*G, LRTable, Arena, GSStack});
+  const ForestNode  =
+  glrParse(Tokens, {*G, LRTable, Arena, GSStack}, id("test"));
   // Verify that there is no duplicated sequence node of `expr := IDENTIFIER`
   // in the forest, see the `#1` and `=#1` in the dump string.
   EXPECT_EQ(Parsed.dumpRecursive(*G),
@@ -381,7 +382,8 @@
   const TokenStream  = cook(lex("IDENTIFIER", LOptions), LOptions);
   auto LRTable = LRTable::buildSLR(*G);
 
-  const ForestNode  = glrParse(Tokens, {*G, LRTable, Arena, GSStack});
+  const ForestNode  =
+  glrParse(Tokens, {*G, LRTable, Arena, GSStack}, id("test"));
   EXPECT_EQ(Parsed.dumpRecursive(*G),
 "[  0, end) test := \n"
 "[  0, end) ├─test := IDENTIFIER\n"
Index: clang-tools-extra/pseudo/tool/ClangPseudo.cpp
===
--- clang-tools-extra/pseudo/tool/ClangPseudo.cpp
+++ clang-tools-extra/pseudo/tool/ClangPseudo.cpp
@@ -43,6 +43,9 @@
 desc("Strip directives and select conditional sections"));
 static opt PrintStatistics("print-statistics", desc("Print GLR parser statistics"));
 static opt PrintForest("print-forest", desc("Print parse forest"));
+static opt StartSymbol("start-symbol",
+desc("specify the start symbol to parse"),
+init("translation-unit"));
 
 static std::string readOrDie(llvm::StringRef Path) {
   llvm::ErrorOr> Text =
@@ -110,9 +113,9 @@
 if (ParseableStream) {
   clang::pseudo::ForestArena Arena;
   clang::pseudo::GSS GSS;
-  auto  =
-  glrParse(*ParseableStream,
-   clang::pseudo::ParseParams{*G, LRTable, Arena, GSS});
+  auto  = glrParse(
+  *ParseableStream, clang::pseudo::ParseParams{*G, LRTable, Arena, GSS},
+  clang::pseudo::findNonterminal(StartSymbol, G->table()));
   if (PrintForest)
 llvm::outs() << Root.dumpRecursive(*G, /*Abbreviated=*/true);
 
Index: clang-tools-extra/pseudo/test/glr-variant-start.cpp
===
--- /dev/null
+++ clang-tools-extra/pseudo/test/glr-variant-start.cpp
@@ -0,0 +1,9 @@
+// RUN: clang-pseudo -grammar=%cxx-bnf-file -source=%s --start-symbol=statement-seq --print-forest | FileCheck %s
+
+a + a;
+// CHECK:  statement-seq~expression-statement := expression ;
+// CHECK-NEXT: ├─expression~additive-expression := additive-expression + multiplicative-expression
+// CHECK-NEXT: │ ├─additive-expression~IDENTIFIER :=
+// CHECK-NEXT: │ ├─+ :=
+// CHECK-NEXT: │ └─multiplicative-expression~IDENTIFIER :=
+// CHECK-NEXT: └─; :=
Index: clang-tools-extra/pseudo/lib/cxx.bnf
===
--- 

[PATCH] D124341: [clang-tidy][NFC] Replace many instances of std::string where a StringRef would suffice.

[Nathan James via Phabricator via cfe-commits]

njames93 added a comment.

In D124341#3502659 , @uabelho wrote:

> Hi,
>
> I noticed that this patch isn't NFC.

Whoops, good catch. I left in some debugging code, fixed in rGa308a55720249749 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124341

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

[clang-tools-extra] a308a55 - [clang-tidy] Fix unintended change left in 12cb540529e

[Nathan James via cfe-commits]

Author: Nathan James
Date: 2022-05-10T21:07:31+01:00
New Revision: a308a557202497495c10355279b5b9975bbee98e

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

LOG: [clang-tidy] Fix unintended change left in 12cb540529e

Added: 


Modified: 
clang-tools-extra/clang-tidy/readability/SuspiciousCallArgumentCheck.cpp

Removed: 




diff  --git 
a/clang-tools-extra/clang-tidy/readability/SuspiciousCallArgumentCheck.cpp 
b/clang-tools-extra/clang-tidy/readability/SuspiciousCallArgumentCheck.cpp
index d7066fa6ca1c5..f2d8fe51707bb 100644
--- a/clang-tools-extra/clang-tidy/readability/SuspiciousCallArgumentCheck.cpp
+++ b/clang-tools-extra/clang-tidy/readability/SuspiciousCallArgumentCheck.cpp
@@ -529,7 +529,6 @@ SuspiciousCallArgumentCheck::SuspiciousCallArgumentCheck(
   for (StringRef Abbreviation : optutils::parseStringList(
Options.get("Abbreviations", DefaultAbbreviations))) {
 auto KeyAndValue = Abbreviation.split("=");
-llvm::errs() << "'" << Abbreviation << "'\n";
 assert(!KeyAndValue.first.empty() && !KeyAndValue.second.empty());
 AbbreviationDictionary.insert(
 std::make_pair(KeyAndValue.first, KeyAndValue.second.str()));



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

[PATCH] D125165: [Clang] Introduce clang-offload-packager tool to bundle device files

[Tom Stellard via Phabricator via cfe-commits]

tstellar added a comment.

In D125165#3504252 , @tra wrote:

> LGTM in principle.
>
> Given that we're introducing a new tool dependency we may want to get a stamp 
> from someone dealing with build and release. 
> @tstellar -- do we need to change anything else for the new binary to ship 
> with clang releases?

If the tools is built by default, then the test-release.sh build script will 
include it in the release binaries.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125165

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

[PATCH] D125333: [OpenMP] Use the new OpenMP device static library when doing LTO

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 created this revision.
jhuber6 added reviewers: jdoerfert, tianshilei1992, JonChesterfield, ABataev.
Herald added subscribers: guansong, inglorion, yaxunl.
Herald added a project: All.
jhuber6 requested review of this revision.
Herald added subscribers: cfe-commits, sstefan1, MaskRay.
Herald added a project: clang.

The previous patches allowed us to create a static library containing
all the device code. This patch uses that library to perform the device
runtime linking late when performing LTO. This in addition to
simplifying the libraries, allows us to transparently handle the runtime
library as-needed without needing Clang to manually pass the necessary
library in the linker wrapper job.

Depends on D125315 


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D125333

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/test/Driver/openmp-offload-gpu-new.c


Index: clang/test/Driver/openmp-offload-gpu-new.c
===
--- clang/test/Driver/openmp-offload-gpu-new.c
+++ clang/test/Driver/openmp-offload-gpu-new.c
@@ -89,3 +89,8 @@
 // RUN:   %clang -### --target=x86_64-unknown-linux-gnu -ccc-print-bindings 
-fopenmp -fopenmp-targets=nvptx64-nvidia-cuda \
 // RUN: --offload-device-only -E -nogpulib %s 2>&1 | FileCheck %s 
--check-prefix=CHECK-DEVICE-ONLY-PP
 // CHECK-DEVICE-ONLY-PP: "nvptx64-nvidia-cuda" - "clang", inputs: 
["[[INPUT:.*]]"], output: "-"
+
+// RUN:   %clang -### --target=x86_64-unknown-linux-gnu -fopenmp 
--offload-arch=sm_52 -nogpulib \
+// RUN: -foffload-lto %s 2>&1 | FileCheck --check-prefix=CHECK-LTO-LIBRARY 
%s
+
+// CHECK-LTO-LIBRARY: {{.*}}-lomptarget{{.*}}-lomptarget.devicertl
Index: clang/lib/Driver/ToolChains/CommonArgs.cpp
===
--- clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -736,6 +736,9 @@
   if (IsOffloadingHost)
 CmdArgs.push_back("-lomptarget");
 
+  if (IsOffloadingHost && TC.getDriver().isUsingLTO(/* IsOffload */ true))
+CmdArgs.push_back("-lomptarget.devicertl");
+
   addArchSpecificRPath(TC, Args, CmdArgs);
 
   if (RTKind == Driver::OMPRT_OMP)
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -8301,28 +8301,6 @@
"=" + *(FeatureIt + 1)));
 }
 
-// Pass in the bitcode library to be linked during LTO.
-for (auto  :
- llvm::make_range(OpenMPTCRange.first, OpenMPTCRange.second)) {
-  const ToolChain *TC = I.second;
-  if (!(TC->getTriple().isNVPTX() || TC->getTriple().isAMDGPU()))
-continue;
-
-  const Driver  = TC->getDriver();
-  const ArgList  = C.getArgsForToolChain(TC, "", 
Action::OFK_OpenMP);
-  StringRef Arch = TCArgs.getLastArgValue(options::OPT_march_EQ);
-
-  ArgStringList BitcodeLibrary;
-  addOpenMPDeviceRTL(TCDriver, TCArgs, BitcodeLibrary, Arch,
- TC->getTriple());
-
-  if (!BitcodeLibrary.empty())
-CmdArgs.push_back(Args.MakeArgString(
-"-target-library=" +
-Action::GetOffloadKindName(Action::OFK_OpenMP) + "-" +
-TC->getTripleString() + "-" + Arch + "=" + BitcodeLibrary.back()));
-}
-
 // Pass in the optimization level to use for LTO.
 if (const Arg *A = Args.getLastArg(options::OPT_O_Group)) {
   StringRef OOpt;


Index: clang/test/Driver/openmp-offload-gpu-new.c
===
--- clang/test/Driver/openmp-offload-gpu-new.c
+++ clang/test/Driver/openmp-offload-gpu-new.c
@@ -89,3 +89,8 @@
 // RUN:   %clang -### --target=x86_64-unknown-linux-gnu -ccc-print-bindings -fopenmp -fopenmp-targets=nvptx64-nvidia-cuda \
 // RUN: --offload-device-only -E -nogpulib %s 2>&1 | FileCheck %s --check-prefix=CHECK-DEVICE-ONLY-PP
 // CHECK-DEVICE-ONLY-PP: "nvptx64-nvidia-cuda" - "clang", inputs: ["[[INPUT:.*]]"], output: "-"
+
+// RUN:   %clang -### --target=x86_64-unknown-linux-gnu -fopenmp --offload-arch=sm_52 -nogpulib \
+// RUN: -foffload-lto %s 2>&1 | FileCheck --check-prefix=CHECK-LTO-LIBRARY %s
+
+// CHECK-LTO-LIBRARY: {{.*}}-lomptarget{{.*}}-lomptarget.devicertl
Index: clang/lib/Driver/ToolChains/CommonArgs.cpp
===
--- clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -736,6 +736,9 @@
   if (IsOffloadingHost)
 CmdArgs.push_back("-lomptarget");
 
+  if (IsOffloadingHost && TC.getDriver().isUsingLTO(/* IsOffload */ true))
+CmdArgs.push_back("-lomptarget.devicertl");
+
   addArchSpecificRPath(TC, Args, CmdArgs);
 
   if (RTKind == Driver::OMPRT_OMP)
Index: clang/lib/Driver/ToolChains/Clang.cpp

[PATCH] D124726: Suggest typoed directives in preprocessor conditionals

[Ken Matsui via Phabricator via cfe-commits]

ken-matsui added inline comments.



Comment at: clang/test/Preprocessor/suggest-typoed-directive.c:10
+// expected-warning@+11 {{'#elfidef' directive not found, did you mean 
'#elifdef'?}}
+// expected-warning@+11 {{'#elfindef' directive not found, did you mean 
'#elifdef'?}}
+// expected-warning@+11 {{'#elsi' directive not found, did you mean '#else'?}}

aaron.ballman wrote:
> erichkeane wrote:
> > aaron.ballman wrote:
> > > ken-matsui wrote:
> > > > aaron.ballman wrote:
> > > > > ken-matsui wrote:
> > > > > > aaron.ballman wrote:
> > > > > > > ken-matsui wrote:
> > > > > > > > aaron.ballman wrote:
> > > > > > > > > It's interesting that this one suggested `#elifdef` instead 
> > > > > > > > > of `#elifndef` -- is there anything that can be done for that?
> > > > > > > > > 
> > > > > > > > > Also, one somewhat interesting question is whether we want to 
> > > > > > > > > recommend `#elifdef` and `#elifndef` outside of C2x/C++2b 
> > > > > > > > > mode. Those directives only exist in the latest language 
> > > > > > > > > standard, but Clang supports them as a conforming extension 
> > > > > > > > > in all language modes. Given that this diagnostic is about 
> > > > > > > > > typos, I think I'm okay suggesting the directives even in 
> > > > > > > > > older language modes. That's as likely to be a correct 
> > > > > > > > > suggestion as not, IMO.
> > > > > > > > > It's interesting that this one suggested `#elifdef` instead 
> > > > > > > > > of `#elifndef` -- is there anything that can be done for that?
> > > > > > > > 
> > > > > > > > I found I have to use `std::min_element` instead of 
> > > > > > > > `std::max_element` because we are finding the nearest (most 
> > > > > > > > minimum distance) string. Meanwhile, `#elfindef` has 2 distance 
> > > > > > > > with both `#elifdef` and `#elifndef`. After replacing 
> > > > > > > > `std::max_element` with `std::min_element`, I could suggest 
> > > > > > > > `#elifndef` from `#elfinndef`.
> > > > > > > > 
> > > > > > > > > Also, one somewhat interesting question is whether we want to 
> > > > > > > > > recommend `#elifdef` and `#elifndef` outside of C2x/C++2b 
> > > > > > > > > mode. Those directives only exist in the latest language 
> > > > > > > > > standard, but Clang supports them as a conforming extension 
> > > > > > > > > in all language modes. Given that this diagnostic is about 
> > > > > > > > > typos, I think I'm okay suggesting the directives even in 
> > > > > > > > > older language modes. That's as likely to be a correct 
> > > > > > > > > suggestion as not, IMO.
> > > > > > > > 
> > > > > > > > I agree with you because Clang implements those directives, and 
> > > > > > > > the suggested code will also be compilable. I personally think 
> > > > > > > > only not compilable suggestions should be avoided. (Or, we 
> > > > > > > > might place additional info for outside of C2x/C++2b mode like 
> > > > > > > > `this is a C2x/C++2b feature but compilable on Clang`?)
> > > > > > > > 
> > > > > > > > ---
> > > > > > > > 
> > > > > > > > According to the algorithm of `std::min_element`, we only get 
> > > > > > > > an iterator of the first element even if there is another 
> > > > > > > > element that has the same distance. So, `#elfindef` only 
> > > > > > > > suggests `#elifdef` in accordance with the order of 
> > > > > > > > `Candidates`, and I don't think it is beautiful to depend on 
> > > > > > > > the order of candidates. I would say that we can suggest all 
> > > > > > > > the same distance like the following, but I'm not sure this is 
> > > > > > > > preferable:
> > > > > > > > 
> > > > > > > > ```
> > > > > > > > #elfindef // diag: unknown directive, did you mean #elifdef or 
> > > > > > > > #elifndef?
> > > > > > > > ```
> > > > > > > > 
> > > > > > > > I agree with you because Clang implements those directives, and 
> > > > > > > > the suggested code will also be compilable. I personally think 
> > > > > > > > only not compilable suggestions should be avoided. (Or, we 
> > > > > > > > might place additional info for outside of C2x/C++2b mode like 
> > > > > > > > this is a C2x/C++2b feature but compilable on Clang?)
> > > > > > > 
> > > > > > > I may be changing my mind on this a bit. I now see we don't issue 
> > > > > > > an extension warning when using `#elifdef` or `#elifndef` in 
> > > > > > > older language modes. That means suggesting those will be correct 
> > > > > > > but only for Clang, and the user won't have any other diagnostics 
> > > > > > > to tell them about the portability issue. And those particular 
> > > > > > > macros are reasonably likely to be used in a header where the 
> > > > > > > user is trying to aim for portability. So I'm starting to think 
> > > > > > > we should only suggest those two in C2x mode (and we should 
> > > > > > > probably add a portability warning for #elifdef and #elifndef, so 
> > > > > > > I filed: https://github.com/llvm/llvm-project/issues/55306)
> > > > 

[PATCH] D111548: [Clang] Add the `annotate_type` attribute

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

rsmith added inline comments.



Comment at: clang/test/SemaCXX/annotate-type.cpp:2
+// RUN: %clang_cc1 %s -std=c++17 -fsyntax-only -verify
+
+struct S1 {

mboehme wrote:
> rsmith wrote:
> > mboehme wrote:
> > > aaron.ballman wrote:
> > > > mboehme wrote:
> > > > > aaron.ballman wrote:
> > > > > > mboehme wrote:
> > > > > > > aaron.ballman wrote:
> > > > > > > > mboehme wrote:
> > > > > > > > > aaron.ballman wrote:
> > > > > > > > > > mboehme wrote:
> > > > > > > > > > > aaron.ballman wrote:
> > > > > > > > > > > > mboehme wrote:
> > > > > > > > > > > > > aaron.ballman wrote:
> > > > > > > > > > > > > > Can you also add some test coverage for applying 
> > > > > > > > > > > > > > the attribute to a declaration instead of a type or 
> > > > > > > > > > > > > > not giving it any arguments? Also, should test 
> > > > > > > > > > > > > > arguments which are not a constant expression.
> > > > > > > > > > > > > I've added tests as you suggested, though I put most 
> > > > > > > > > > > > > of them in Sema/annotate-type.c, as they're not 
> > > > > > > > > > > > > specific to C++.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Thanks for prompting me to do this -- the tests 
> > > > > > > > > > > > > caused me to notice and fix a number of bugs.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I haven't managed to diagnose the case when the 
> > > > > > > > > > > > > attribute appears at the beginning of the 
> > > > > > > > > > > > > declaration. It seems to me that, at the point where 
> > > > > > > > > > > > > I've added the check, this case is indistinguishable 
> > > > > > > > > > > > > from an attribute that appears on the type. In both 
> > > > > > > > > > > > > cases, the `TAL` is `TAL_DeclSpec`, and the attribute 
> > > > > > > > > > > > > is contained in `DeclSpec::getAttributes()`. This is 
> > > > > > > > > > > > > because `Parser::ParseSimpleDeclaration` forwards the 
> > > > > > > > > > > > > declaration attributes to the `DeclSpec`:
> > > > > > > > > > > > > 
> > > > > > > > > > > > > https://github.com/llvm/llvm-project/blob/main/clang/lib/Parse/ParseDecl.cpp#L1851
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I believe if I wanted to prohibit this case, I would 
> > > > > > > > > > > > > need to add a check to 
> > > > > > > > > > > > > `Parser::ParseStatementOrDeclaration` and prohibit 
> > > > > > > > > > > > > any occurrences of `annotate_type` there. However, 
> > > > > > > > > > > > > this seems the wrong place to do this because it 
> > > > > > > > > > > > > doesn't contain any specific processing for other 
> > > > > > > > > > > > > attributes.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I've noticed that Clang also doesn't prohibit other 
> > > > > > > > > > > > > type attributes (even ones with C++ 11 syntax) from 
> > > > > > > > > > > > > being applied to declarations. For example: 
> > > > > > > > > > > > > https://godbolt.org/z/Yj1zWY7nn
> > > > > > > > > > > > > 
> > > > > > > > > > > > > How do you think I should proceed here? I think the 
> > > > > > > > > > > > > underlying issue is that Clang doesn't always 
> > > > > > > > > > > > > distinguish cleanly between declaration attributes 
> > > > > > > > > > > > > and type attributes, and fixing this might be 
> > > > > > > > > > > > > nontrivial.
> > > > > > > > > > > > > How do you think I should proceed here? I think the 
> > > > > > > > > > > > > underlying issue is that Clang doesn't always 
> > > > > > > > > > > > > distinguish cleanly between declaration attributes 
> > > > > > > > > > > > > and type attributes, and fixing this might be 
> > > > > > > > > > > > > nontrivial.
> > > > > > > > > > > > 
> > > > > > > > > > > > This is a general issue with attribute processing. I 
> > > > > > > > > > > > would imagine that SemaDeclAttr.cpp should be able to 
> > > > > > > > > > > > diagnose that case when the attribute only applies to 
> > > > > > > > > > > > types and not declarations, but it'd take some 
> > > > > > > > > > > > investigation for me to be sure.
> > > > > > > > > > > > 
> > > > > > > > > > > > Because this issue isn't new to your situation, I'd 
> > > > > > > > > > > > recommend filing an issue about the general problem and 
> > > > > > > > > > > > then we can solve that later.
> > > > > > > > > > > I've done some more investigation myself, and I think 
> > > > > > > > > > > I've come up with a solution; actually, two potential 
> > > > > > > > > > > solutions. I have draft patches for both of these; I 
> > > > > > > > > > > wanted to run these by you here first, so I haven't 
> > > > > > > > > > > opened a bug yet.
> > > > > > > > > > > 
> > > > > > > > > > > I'd appreciate your input on how you'd prefer me to 
> > > > > > > > > > > proceed with this. I do think it makes sense to do this 
> > > > > > > > > > > work now because otherwise, people will start putting 
> > > > > > > > > > > `annotate_type` in places where it doesn't belong, and 
> > > > > > > 

[PATCH] D125137: [clang-format] Don't remove braces if a 1-statement body would wrap

[Owen Pan via Phabricator via cfe-commits]

owenpan updated this revision to Diff 428468.
owenpan added a comment.

Added saving/restoring the children of `UnwrappedLineNode` and addressed review 
comments.


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

https://reviews.llvm.org/D125137

Files:
  clang/lib/Format/UnwrappedLineParser.cpp
  clang/lib/Format/UnwrappedLineParser.h
  clang/unittests/Format/FormatTest.cpp

Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -25351,8 +25351,6 @@
"}",
Style);
 
-  // FIXME: See https://github.com/llvm/llvm-project/issues/53543.
-#if 0
   Style.ColumnLimit = 65;
 
   verifyFormat("if (condition) {\n"
@@ -25366,6 +25364,15 @@
 
   Style.ColumnLimit = 20;
 
+  verifyFormat("int ab = [](int i) {\n"
+   "  if (i > 0) {\n"
+   "i = 12345678 -\n"
+   "i;\n"
+   "  }\n"
+   "  return i;\n"
+   "};",
+   Style);
+
   verifyFormat("if (a) {\n"
"  b = c + // 1 -\n"
"  d;\n"
@@ -25380,9 +25387,6 @@
"  b = c >= 0 ? d : e;\n"
"}",
Style);
-#endif
-
-  Style.ColumnLimit = 20;
 
   verifyFormat("if (a)\n"
"  b = c > 0 ? d : e;",
Index: clang/lib/Format/UnwrappedLineParser.h
===
--- clang/lib/Format/UnwrappedLineParser.h
+++ clang/lib/Format/UnwrappedLineParser.h
@@ -95,6 +95,7 @@
   bool parseLevel(bool HasOpeningBrace, bool CanContainBracedList,
   IfStmtKind *IfKind = nullptr,
   TokenType NextLBracesType = TT_Unknown);
+  bool mightFitOnOneLine(UnwrappedLine ) const;
   IfStmtKind parseBlock(bool MustBeDeclaration = false, unsigned AddLevels = 1u,
 bool MunchSemi = true,
 bool UnindentWhitesmithsBraces = false,
Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -14,6 +14,7 @@
 
 #include "UnwrappedLineParser.h"
 #include "FormatToken.h"
+#include "TokenAnnotator.h"
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/Support/Debug.h"
 #include "llvm/Support/raw_ostream.h"
@@ -460,6 +461,7 @@
   return Previous && Previous->is(tok::comment) &&
  (Previous->IsMultiline || Previous->NewlinesBefore > 0);
 }
+
 /// \brief Parses a level, that is ???.
 /// \param HasOpeningBrace If that level is started by an opening brace.
 /// \param CanContainBracedList If the content can contain (at any level) a
@@ -751,6 +753,50 @@
   return h;
 }
 
+// Checks whether \p ParsedLine might fit on a single line. We must clone the
+// tokens of \p ParsedLine before running the token annotator on it so that we
+// can restore them afterward.
+bool UnwrappedLineParser::mightFitOnOneLine(UnwrappedLine ) const {
+  const auto ColumnLimit = Style.ColumnLimit;
+  if (ColumnLimit == 0)
+return true;
+
+  auto  = ParsedLine.Tokens;
+  assert(!Tokens.empty());
+  const auto *LastToken = Tokens.back().Tok;
+  assert(LastToken);
+
+  SmallVector SavedTokens(Tokens.size());
+
+  int Index = 0;
+  for (const auto  : Tokens) {
+assert(Token.Tok);
+auto  = SavedTokens[Index++];
+SavedToken.Tok = new FormatToken;
+SavedToken.Tok->copyFrom(*Token.Tok);
+SavedToken.Children = std::move(Token.Children);
+  }
+
+  AnnotatedLine Line(ParsedLine);
+  assert(Line.Last == LastToken);
+
+  TokenAnnotator Annotator(Style, Keywords);
+  Annotator.annotate(Line);
+  Annotator.calculateFormattingInformation(Line);
+
+  const int Length = LastToken->TotalLength;
+
+  Index = 0;
+  for (auto  : Tokens) {
+const auto  = SavedTokens[Index++];
+Token.Tok->copyFrom(*SavedToken.Tok);
+Token.Children = std::move(SavedToken.Children);
+delete SavedToken.Tok;
+  }
+
+  return Line.Level * Style.IndentWidth + Length <= ColumnLimit;
+}
+
 UnwrappedLineParser::IfStmtKind
 UnwrappedLineParser::parseBlock(bool MustBeDeclaration, unsigned AddLevels,
 bool MunchSemi, bool UnindentWhitesmithsBraces,
@@ -813,8 +859,11 @@
 const FormatToken *Previous = Tokens->getPreviousToken();
 assert(Previous);
 if (Previous->isNot(tok::r_brace) || Previous->Optional) {
-  Tok->MatchingParen = FormatTok;
-  FormatTok->MatchingParen = Tok;
+  assert(!CurrentLines->empty());
+  if (mightFitOnOneLine(CurrentLines->back())) {
+Tok->MatchingParen = FormatTok;
+FormatTok->MatchingParen = Tok;
+  }
 }
   }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D123471: [CUDA] Create offloading entries when using the new driver

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 added a comment.

Is this with D123810  and D123812 
 good to land? It would be nice to be able to 
test this upstream.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123471

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

[PATCH] D124038: [clang] Prevent folding of non-const compound expr

[Eli Friedman via Phabricator via cfe-commits]

efriedma added a comment.

I think you're looking at old documentation?  Here's what the current page 
(https://gcc.gnu.org/onlinedocs/gcc/Compound-Literals.html) has to say:

  In C, a compound literal designates an unnamed object with static or 
automatic storage duration. In C++, a compound literal designates a temporary 
object that only lives until the end of its full-expression. As a result, 
well-defined C code that takes the address of a subobject of a compound literal 
can be undefined in C++, so G++ rejects the conversion of a temporary array to 
a pointer. For instance, if the array compound literal example above appeared 
inside a function, any subsequent use of foo in C++ would have undefined 
behavior because the lifetime of the array ends after the declaration of foo.
  
  As an optimization, G++ sometimes gives array compound literals longer 
lifetimes: when the array either appears outside a function or has a 
const-qualified type. If foo and its initializer had elements of type char 
*const rather than char *, or if foo were a global variable, the array would 
have static storage duration. But it is probably safest just to avoid the use 
of array compound literals in C++ code.


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

https://reviews.llvm.org/D124038

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

[PATCH] D124726: Suggest typoed directives in preprocessor conditionals

[Ken Matsui via Phabricator via cfe-commits]

ken-matsui updated this revision to Diff 428471.
ken-matsui added a comment.

Set `AllowReplacements` to `true`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124726

Files:
  clang/include/clang/Basic/DiagnosticLexKinds.td
  clang/include/clang/Lex/Preprocessor.h
  clang/lib/Lex/PPDirectives.cpp
  clang/test/Preprocessor/suggest-typoed-directive.c
  llvm/include/llvm/ADT/StringRef.h
  llvm/lib/Support/StringRef.cpp
  llvm/unittests/ADT/StringRefTest.cpp

Index: llvm/unittests/ADT/StringRefTest.cpp
===
--- llvm/unittests/ADT/StringRefTest.cpp
+++ llvm/unittests/ADT/StringRefTest.cpp
@@ -566,6 +566,13 @@
 }
 
 TEST(StringRefTest, EditDistance) {
+  EXPECT_EQ(0U, StringRef("").edit_distance(""));
+  EXPECT_EQ(1U, StringRef("").edit_distance("aaab"));
+  EXPECT_EQ(2U, StringRef("aabc").edit_distance("aacb"));
+  EXPECT_EQ(2U, StringRef("aabc").edit_distance("abca"));
+  EXPECT_EQ(3U, StringRef("aabc").edit_distance("adef"));
+  EXPECT_EQ(4U, StringRef("abcd").edit_distance("efgh"));
+
   StringRef Hello("hello");
   EXPECT_EQ(2U, Hello.edit_distance("hill"));
 
@@ -584,6 +591,40 @@
"people soiled our green "));
 }
 
+TEST(StringRefTest, FindSimilarStr) {
+  {
+std::vector Candidates{"aaab", "aaac"};
+EXPECT_EQ(std::string("aaab"), StringRef("").find_similar_str(Candidates));
+  }
+  {
+std::vector Candidates{"aab", "aac"};
+EXPECT_EQ(std::string("aab"), StringRef("aaa").find_similar_str(Candidates));
+  }
+  {
+std::vector Candidates{"ab", "ac"};
+EXPECT_EQ(std::string("ab"), StringRef("aa").find_similar_str(Candidates));
+  }
+  {
+std::vector Candidates{"b", "c"};
+EXPECT_EQ(None, StringRef("a").find_similar_str(Candidates));
+  }
+  { // macros
+std::vector Candidates{
+"if", "ifdef", "ifndef", "elif", "elifdef", "elifndef", "else", "endif"
+};
+EXPECT_EQ(std::string("elifdef"), StringRef("elfidef").find_similar_str(Candidates));
+EXPECT_EQ(std::string("elifdef"), StringRef("elifdef").find_similar_str(Candidates));
+EXPECT_EQ(None, StringRef("special_compiler_directive").find_similar_str(Candidates));
+  }
+  { // case-insensitive
+std::vector Candidates{
+"if", "ifdef", "ifndef", "elif", "elifdef", "elifndef", "else", "endif"
+};
+EXPECT_EQ(std::string("elifdef"), StringRef("elifdef").find_similar_str(Candidates));
+EXPECT_EQ(std::string("elifdef"), StringRef("ELIFDEF").find_similar_str(Candidates));
+  }
+}
+
 TEST(StringRefTest, Misc) {
   std::string Storage;
   raw_string_ostream OS(Storage);
Index: llvm/lib/Support/StringRef.cpp
===
--- llvm/lib/Support/StringRef.cpp
+++ llvm/lib/Support/StringRef.cpp
@@ -98,6 +98,43 @@
   AllowReplacements, MaxEditDistance);
 }
 
+// Find a similar string in `Candidates`.
+Optional StringRef::find_similar_str(const std::vector , size_t Dist) const {
+  // We need to check if `rng` has the exact case-insensitive string because the Levenshtein distance match does not
+  // care about it.
+  for (StringRef C : Candidates) {
+if (equals_insensitive(C)) {
+  return C.str();
+}
+  }
+
+  // Keep going with the Levenshtein distance match.
+  // If dist is given, use the dist for maxDist; otherwise, if the LHS size is less than 3, use the LHS size minus 1
+  // and if not, use the LHS size divided by 3.
+  size_t MaxDist = Dist != 0? Dist
+   : Length < 3 ? Length - 1
+: Length / 3;
+
+  std::vector> Cand;
+  for (StringRef C : Candidates) {
+size_t CurDist = edit_distance(C, true);
+if (CurDist <= MaxDist) {
+  Cand.emplace_back(C, CurDist);
+}
+  }
+
+  if (Cand.empty()) {
+return None;
+  } else if (Cand.size() == 1) {
+return Cand[0].first;
+  } else {
+auto SimilarStr = std::min_element(
+Cand.cbegin(), Cand.cend(),
+[](const auto , const auto ) { return A.second < B.second; });
+return SimilarStr->first;
+  }
+}
+
 //===--===//
 // String Operations
 //===--===//
Index: llvm/include/llvm/ADT/StringRef.h
===
--- llvm/include/llvm/ADT/StringRef.h
+++ llvm/include/llvm/ADT/StringRef.h
@@ -10,6 +10,7 @@
 #define LLVM_ADT_STRINGREF_H
 
 #include "llvm/ADT/DenseMapInfo.h"
+#include "llvm/ADT/Optional.h"
 #include "llvm/ADT/STLFunctionalExtras.h"
 #include "llvm/ADT/iterator_range.h"
 #include "llvm/Support/Compiler.h"
@@ -24,6 +25,7 @@
 #endif
 #include 
 #include 
+#include 
 
 // Declare the __builtin_strlen intrinsic for MSVC so it can be used in
 // constexpr context.
@@ -240,6 +242,23 @@
 unsigned 

[clang] b6572ad - [NFC] Add missing 'break' in a switch case

[Erich Keane via cfe-commits]

Author: Erich Keane
Date: 2022-05-10T12:48:08-07:00
New Revision: b6572ad504753c6c27ba49c2ed595a091c977dcd

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

LOG: [NFC] Add missing 'break' in a switch case

Added: 


Modified: 
clang/lib/AST/TypePrinter.cpp

Removed: 




diff  --git a/clang/lib/AST/TypePrinter.cpp b/clang/lib/AST/TypePrinter.cpp
index d2feb1c10f06..43183e1e5dd6 100644
--- a/clang/lib/AST/TypePrinter.cpp
+++ b/clang/lib/AST/TypePrinter.cpp
@@ -283,6 +283,7 @@ bool TypePrinter::canPrefixQualifiers(const Type *T,
   // address_space attribute.
   const auto *AttrTy = cast(UnderlyingType);
   CanPrefixQualifiers = AttrTy->getAttrKind() == attr::AddressSpace;
+  break;
 }
   }
 



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

[PATCH] D120727: [libc++] Overhaul how we select the ABI library

[Martin Storsjö via Phabricator via cfe-commits]

mstorsjo added a comment.

I gave it a quick readthrough, but I don't think I can give a qualified review 
of the bulk of it... I noticed a couple minor details though.




Comment at: libcxx/CMakeLists.txt:260
   else()
-set(LIBCXX_CXX_ABI_LIBNAME "default")
+set(LIBCXX_CXX_ABI "libcxxabi")
   endif()

Couldn't these lines be replaced with just a `set(LIBCXX_CXX_ABI 
${LIBCXX_DEFAULT_ABI_LIBRARY})`?



Comment at: libcxxabi/CMakeLists.txt:201
 endif()
+message(STATUS "Using libc++abi testing configuration: 
${LIBCXXABI_TEST_CONFIG}")
 set(LIBCXXABI_TEST_PARAMS "" CACHE STRING

Unrelated to the rest of the patch?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120727

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

[PATCH] D123273: [utils] Avoid hardcoding metadata ids in update_cc_test_checks

[Nico Weber via Phabricator via cfe-commits]

thakis added a comment.

Also fails on linux: https://lab.llvm.org/buildbot/#/builders/109/builds/38285

And on mac: http://45.33.8.238/macm1/35024/step_7.txt

(On some platforms, the bot redness was masked by D124552 
 breaking the bots first.)

But yes, please fix or revert.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123273

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

[clang] 508d2b4 - [NFC]Add Missing Break in switch that we didn't notice because it was

[Erich Keane via cfe-commits]

Author: Erich Keane
Date: 2022-05-10T12:27:45-07:00
New Revision: 508d2b4e13c05388a19173e5bd98ac06b9dd9b98

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

LOG: [NFC]Add Missing Break in switch that we didn't notice because it was
last.

Added: 


Modified: 
clang/lib/AST/ASTStructuralEquivalence.cpp

Removed: 




diff  --git a/clang/lib/AST/ASTStructuralEquivalence.cpp 
b/clang/lib/AST/ASTStructuralEquivalence.cpp
index b15036a11ad92..d80fc3ce72928 100644
--- a/clang/lib/AST/ASTStructuralEquivalence.cpp
+++ b/clang/lib/AST/ASTStructuralEquivalence.cpp
@@ -1236,6 +1236,7 @@ static bool 
IsStructurallyEquivalent(StructuralEquivalenceContext ,
 !IsStructurallyEquivalent(Context, Int1->getNumBitsExpr(),
   Int2->getNumBitsExpr()))
   return false;
+break;
   }
   } // end switch
 



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

[PATCH] D125312: [pseudo] benchmark cleanups. NFC

[Haojian Wu via Phabricator via cfe-commits]

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

Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125312

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

[PATCH] D125162: [clang-format] fix alignment w/o binpacked args

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

HazardyKnusperkeks added inline comments.



Comment at: clang/unittests/Format/FormatTest.cpp:17286
+  // BinPackArguments.
+  // See https://github.com/llvm/llvm-project/issues/55360
+  Alignment = getLLVMStyleWithColumns(50);

I'd drop that, or at least replace it with https://llvm.org/PR55360.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125162

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

[PATCH] D124702: [MSVC] Add support for pragma function

[Stephen Long via Phabricator via cfe-commits]

steplong updated this revision to Diff 428456.
steplong added a comment.

- Changed pragma-ms-functions.c to only check that the no-builtin attributes 
are added to the functions
- Moved pragma handler to Parser
- Changed scope check to only file scope. MSVC accepts stuff like that we don't:

  struct S {
int a;
  #pragma function(memset)
  };


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124702

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Parse/Parser.h
  clang/include/clang/Sema/Sema.h
  clang/lib/Parse/ParsePragma.cpp
  clang/lib/Sema/SemaAttr.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/test/CodeGen/pragma-ms-function.c
  clang/test/Preprocessor/pragma_microsoft.c

Index: clang/test/Preprocessor/pragma_microsoft.c
===
--- clang/test/Preprocessor/pragma_microsoft.c
+++ clang/test/Preprocessor/pragma_microsoft.c
@@ -201,6 +201,26 @@
 #pragma clang diagnostic pop
 #pragma intrinsic(asdf) // expected-warning {{'asdf' is not a recognized builtin; consider including }}
 
+// Test pragma function
+#pragma function(memset) // no-warning
+#pragma function(memcpy, strlen, strlen) // no-warning
+#pragma function()   // no-warning
+#pragma function(asdf)   // expected-warning {{'asdf' is not a recognized builtin; consider including }}
+#pragma function(main)   // expected-warning {{'main' is not a recognized builtin; consider including }}
+#pragma function(// expected-warning {{missing ')' after}}
+#pragma function(int)// expected-warning {{missing ')' after}}
+#pragma function(strcmp) asdf// expected-warning {{extra tokens at end}}
+
+#define __INTRIN_H   // there should be no notes after defining __INTRIN_H
+#pragma function(asdf)   // expected-warning-re {{'asdf' is not a recognized builtin{{$
+#pragma function(memset) // no-warning
+#undef __INTRIN_H
+#pragma function(asdf) // expected-warning {{'asdf' is not a recognized builtin; consider including }}
+
+void pragma_function_foo() {
+#pragma function(memset) // expected-error {{'#pragma function' can only appear at file scope}}
+}
+
 #pragma optimize  // expected-warning{{missing '(' after '#pragma optimize'}}
 #pragma optimize( // expected-warning{{expected string literal in '#pragma optimize'}}
 #pragma optimize(a// expected-warning{{expected string literal in '#pragma optimize'}}
Index: clang/test/CodeGen/pragma-ms-function.c
===
--- /dev/null
+++ clang/test/CodeGen/pragma-ms-function.c
@@ -0,0 +1,38 @@
+// RUN: %clang_cc1 -emit-llvm -fms-extensions -o - %s | FileCheck %s
+
+typedef typeof(sizeof(0)) size_t;
+
+void bar(char *s);
+void *memset(void *s, int c, size_t n);
+void *memcpy(void *d, const void *s, size_t n);
+
+// CHECK: define{{.*}} void @foo1({{.*}}) #[[NO_NOBUILTIN:[0-9]+]]
+void foo1(char *s, char *d, size_t n) {
+  bar(s);
+  memset(s, 0, n);
+  memcpy(d, s, n);
+}
+
+#pragma function(strlen, memset)
+
+// CHECK: define{{.*}} void @foo2({{.*}}) #[[NOBUILTIN_MEMSET:[0-9]+]]
+void foo2(char *s, char *d, size_t n) {
+  bar(s);
+  memset(s, 1, n);
+  memcpy(d, s, n);
+}
+
+#pragma function(memcpy)
+
+// CHECK: define{{.*}} void @foo3({{.*}}) #[[NOBUILTIN_MEMSET_MEMCPY:[0-9]+]]
+void foo3(char *s, char *d, size_t n) {
+  bar(s);
+  memset(s, 2, n);
+  memcpy(d, s, n);
+}
+
+// CHECK-NOT: attributes #[[NO_NOBUILTIN]] = {{{.*}}"no-builtin-memset"{{.*}}}
+// CHECK-NOT: attributes #[[NO_NOBUILTIN]] = {{{.*}}"no-builtin-memcpy"{{.*}}"no-builtin-memset"{{.*}}}
+// CHECK: attributes #[[NOBUILTIN_MEMSET]] = {{{.*}}"no-builtin-memset"{{.*}}}
+// CHECK-NOT: attributes #[[NOBUILTIN_MEMSET]] = {{{.*}}"no-builtin-memcpy"{{.*}}"no-builtin-memset"{{.*}}}
+// CHECK: attributes #[[NOBUILTIN_MEMSET_MEMCPY]] = {{{.*}}"no-builtin-memcpy"{{.*}}"no-builtin-memset"{{.*}}}
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -10218,10 +10218,12 @@
   // marking the function.
   AddCFAuditedAttribute(NewFD);
 
-  // If this is a function definition, check if we have to apply optnone due to
-  // a pragma.
-  if(D.isFunctionDefinition())
+  // If this is a function definition, check if we have to apply any
+  // attributes (i.e. optnone and no_builtin) due to a pragma.
+  if (D.isFunctionDefinition()) {
 AddRangeBasedOptnone(NewFD);
+AddRangeBasedNoBuiltin(NewFD);
+  }
 
   // If this is the first declaration of an extern C variable, update
   // the map of such variables.
Index: clang/lib/Sema/SemaAttr.cpp
===
--- clang/lib/Sema/SemaAttr.cpp
+++ clang/lib/Sema/SemaAttr.cpp
@@ 

[clang] 180a853 - Fix indentation in ReleaseNotes.rst

[Yaxun Liu via cfe-commits]

Author: Yaxun (Sam) Liu
Date: 2022-05-10T14:56:28-04:00
New Revision: 180a8536cec8e5e13e86863b17982daf95f2038a

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

LOG: Fix indentation in ReleaseNotes.rst

Added: 


Modified: 
clang/docs/ReleaseNotes.rst

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index ff7b4285b7d71..9841ae5c52973 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -355,7 +355,7 @@ CUDA/HIP Language Changes in Clang
 --
 
 - Added `__noinline__` as a keyword to avoid diagnostics due to usage of
- `__attribute__((__noinline__))` in CUDA/HIP programs.
+  `__attribute__((__noinline__))` in CUDA/HIP programs.
 
 Objective-C Language Changes in Clang
 -



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

[PATCH] D125165: [Clang] Introduce clang-offload-packager tool to bundle device files

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 added a comment.

In D125165#3504252 , @tra wrote:

> LGTM in principle.
>
> Given that we're introducing a new tool dependency we may want to get a stamp 
> from someone dealing with build and release. 
> @tstellar -- do we need to change anything else for the new binary to ship 
> with clang releases?

We did break ABI with LLVM 14 seeing as we supported `-fopenmp-new-driver` in 
the release. This used a different method of encoding which isn't compatible 
with this one. But since that functionality was hidden behind an opt-in 
experimental flag I would think it's okay to change it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125165

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

[PATCH] D125165: [Clang] Introduce clang-offload-packager tool to bundle device files

[Artem Belevich via Phabricator via cfe-commits]

tra added a subscriber: tstellar.
tra added a comment.

LGTM in principle.

Given that we're introducing a new tool dependency we may want to get a stamp 
from someone dealing with build and release. 
@tstellar -- do we need to change anything else for the new binary to ship with 
clang releases?




Comment at: clang/docs/ClangOffloadBinary.rst:42
+  
+  clang-offload-binary options:
+  

jhuber6 wrote:
> tra wrote:
> > This appears to be a one-way process. How one would examine what's in the 
> > binary and unpack/extract specific component from it?
> This is done by the linker wrapper, but I think it would be good to teach 
> `llvm-objdump` how to handle these. Then we could basically just treat it the 
> same way as `cuobjdump`.
SGTM. That may be a good motivation for someone to write a proper disassembler 
for NVIDIA's GPU binaries. Or we could teach it to invoke nvdisasm or cuobjdump 
if it sees an NVIDIA ELF file.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125165

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

[PATCH] D124534: [clang] Add a diagnostic for line directive of a gnu extension

[Ken Matsui via Phabricator via cfe-commits]

ken-matsui updated this revision to Diff 428450.
ken-matsui added a comment.

Fix the test as reviewed


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124534

Files:
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticLexKinds.td
  clang/lib/Lex/PPDirectives.cpp
  clang/test/Preprocessor/line-directive-system-headers.c
  clang/test/Preprocessor/line-directive.c
  clang/test/SemaCXX/constexpr-string.cpp

Index: clang/test/SemaCXX/constexpr-string.cpp
===
--- clang/test/SemaCXX/constexpr-string.cpp
+++ clang/test/SemaCXX/constexpr-string.cpp
@@ -7,7 +7,7 @@
 // RUN: %clang_cc1 %s -triple armebv7-unknown-linux -std=c++2a -fsyntax-only -verify -pedantic -Wno-vla-extension -fno-signed-char
 // RUN: %clang_cc1 %s -triple armebv7-unknown-linux -std=c++2a -fsyntax-only -verify -pedantic -Wno-vla-extension -fno-wchar -DNO_PREDEFINED_WCHAR_T
 
-# 9 "/usr/include/string.h" 1 3 4
+# 9 "/usr/include/string.h" 1 3 4  // expected-warning {{this style of line directive is a GNU extension}}
 extern "C" {
   typedef decltype(sizeof(int)) size_t;
 
@@ -29,7 +29,7 @@
 }
 # 25 "SemaCXX/constexpr-string.cpp" 2
 
-# 27 "/usr/include/wchar.h" 1 3 4
+# 27 "/usr/include/wchar.h" 1 3 4  // expected-warning {{this style of line directive is a GNU extension}}
 extern "C" {
 #if NO_PREDEFINED_WCHAR_T
   typedef decltype(L'0') wchar_t;
Index: clang/test/Preprocessor/line-directive.c
===
--- clang/test/Preprocessor/line-directive.c
+++ clang/test/Preprocessor/line-directive.c
@@ -9,8 +9,8 @@
 # 20 "" 2
 
 // a push/pop before any other line control
-# 10 "enter-0" 1
-# 11 "" 2 // pop to main file
+# 10 "enter-0" 1 // expected-warning {{this style of line directive is a GNU extension}}
+# 11 "" 2 // pop to main file: expected-warning {{this style of line directive is a GNU extension}}
 #error MAIN7
 // expected-error@-1{{MAIN7}}
 
@@ -27,13 +27,15 @@
 #define A 42 "foo"
 #line A
 
-# 42
-# 42 "foo"
+# 42 // expected-warning {{this style of line directive is a GNU extension}}
+# 42 "foo" // expected-warning {{this style of line directive is a GNU extension}}
 # 42 "foo" 2 // expected-error {{invalid line marker flag '2': cannot pop empty include stack}}
+// The next two lines do not get diagnosed because they are considered to be
+// within the system header, where diagnostics are suppressed.
 # 42 "foo" 1 3  // enter
 # 42 "foo" 2 3  // exit
 # 42 "foo" 2 3 4 // expected-error {{invalid line marker flag '2': cannot pop empty include stack}}
-# 42 "foo" 3 4
+# 42 "foo" 3 4 // expected-warning {{this style of line directive is a GNU extension}}
 
 # 'a'// expected-error {{invalid preprocessing directive}}
 # 42 'f' // expected-error {{invalid filename for line marker directive}}
@@ -54,7 +56,7 @@
 
 // Verify that linemarker diddling of the system header flag works.
 
-# 192 "glomp.h" // not a system header.
+# 192 "glomp.h" // not a system header.: expected-warning {{this style of line directive is a GNU extension}}
 typedef int x;  // expected-note {{previous definition is here}}
 typedef int x;  // expected-warning {{redefinition of typedef 'x' is a C11 feature}}
 
@@ -97,7 +99,7 @@
 #line 010  // expected-warning {{#line directive interprets number as decimal, not octal}}
 extern int array[__LINE__ == 10 ? 1:-1];
 
-# 020  // expected-warning {{GNU line marker directive interprets number as decimal, not octal}}
+# 020  // expected-warning {{GNU line marker directive interprets number as decimal, not octal}} expected-warning {{this style of line directive is a GNU extension}}
 extern int array_gnuline[__LINE__ == 20 ? 1:-1];
 
 /* PR3917 */
@@ -106,7 +108,7 @@
 _\
 _LINE__ == 42 ? 1: -1];  /* line marker is location of first _ */
 
-# 51
+# 51 // expected-warning {{this style of line directive is a GNU extension}}
 extern char array2_gnuline[\
 _\
 _LINE__ == 52 ? 1: -1];  /* line marker is location of first _ */
@@ -115,12 +117,12 @@
 #line 0 "line-directive.c" // expected-warning {{#line directive with zero argument is a GNU extension}}
 undefined t; // expected-error {{unknown type name 'undefined'}}
 
-# 115 "main"
-# 116 "enter-1" 1
-# 117 "enter-2" 1
-# 118 "" 2 // pop to enter-1
+# 115 "main" // expected-warning {{this style of line directive is a GNU extension}}
+# 116 "enter-1" 1 // expected-warning {{this style of line directive is a GNU extension}}
+# 117 "enter-2" 1 // expected-warning {{this style of line directive is a GNU extension}}
+# 118 "" 2 // pop to enter-1: expected-warning {{this style of line directive is a GNU extension}}
 #error ENTER1
 // expected-error@-1{{ENTER1}}
-# 121 "" 2 // pop to "main"
+# 121 "" 2 // pop to "main": expected-warning {{this style of line directive is a GNU extension}}
 #error MAIN2
 // expected-error@-1{{MAIN2}}

[PATCH] D123273: [utils] Avoid hardcoding metadata ids in update_cc_test_checks

[Douglas Yung via Phabricator via cfe-commits]

dyung added a comment.

Hi @jkorous, 4 of the tests you added seem to be failing on the PS4 linux and 
Window buildbots, can you take a look, and revert if it might take a while to 
investigate?

https://lab.llvm.org/buildbot/#/builders/139/builds/21573
https://lab.llvm.org/buildbot/#/builders/216/builds/4167


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123273

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

[PATCH] D124866: [CUDA][HIP] support __noinline__ as keyword

[Yaxun Liu via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
yaxunl marked an inline comment as done.
Closed by commit rGafc9d674fe5a: [CUDA][HIP] support __noinline__ as keyword 
(authored by yaxunl).
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124866

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/Features.def
  clang/include/clang/Basic/TokenKinds.def
  clang/include/clang/Parse/Parser.h
  clang/lib/Basic/IdentifierTable.cpp
  clang/lib/Parse/ParseDecl.cpp
  clang/test/CodeGenCUDA/noinline.cu
  clang/test/Lexer/has_feature.cu
  clang/test/SemaCUDA/noinline.cu

Index: clang/test/SemaCUDA/noinline.cu
===
--- /dev/null
+++ clang/test/SemaCUDA/noinline.cu
@@ -0,0 +1,19 @@
+// RUN: %clang_cc1 -fsyntax-only -verify=cuda %s
+// RUN: %clang_cc1 -fsyntax-only -verify=cuda -pedantic %s
+// RUN: %clang_cc1 -fsyntax-only -verify=cpp -x c++ %s
+
+// cuda-no-diagnostics
+
+__noinline__ void fun1() { } // cpp-error {{unknown type name '__noinline__'}}
+
+__attribute__((noinline)) void fun2() { }
+__attribute__((__noinline__)) void fun3() { }
+[[gnu::__noinline__]] void fun4() { }
+
+#define __noinline__ __attribute__((__noinline__))
+__noinline__ void fun5() {}
+
+#undef __noinline__
+#10 "cuda.h" 3
+#define __noinline__ __attribute__((__noinline__))
+__noinline__ void fun6() {}
Index: clang/test/Lexer/has_feature.cu
===
--- /dev/null
+++ clang/test/Lexer/has_feature.cu
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 -E -triple x86_64-linux-gnu %s -o - | FileCheck %s
+
+// CHECK: has_noinline_keyword
+#if __has_feature(cuda_noinline_keyword)
+int has_noinline_keyword();
+#else
+int no_noinine_keyword();
+#endif
Index: clang/test/CodeGenCUDA/noinline.cu
===
--- /dev/null
+++ clang/test/CodeGenCUDA/noinline.cu
@@ -0,0 +1,34 @@
+// Uses -O2 since the defalt -O0 option adds noinline to all functions.
+
+// RUN: %clang_cc1 -triple nvptx-nvidia-cuda -fcuda-is-device \
+// RUN: -O2 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s
+
+// RUN: %clang_cc1 -triple amdgcn-amd-amdhsa -fcuda-is-device \
+// RUN: -O2 -disable-llvm-passes -emit-llvm -o - -x hip %s | FileCheck %s
+
+// RUN: %clang_cc1 -triple x86_64-unknown-gnu-linux \
+// RUN: -O2 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s
+
+#include "Inputs/cuda.h"
+
+__noinline__ __device__ __host__ void fun1() {}
+
+__attribute__((noinline)) __device__ __host__ void fun2() {}
+
+__attribute__((__noinline__)) __device__ __host__ void fun3() {}
+
+[[gnu::__noinline__]] __device__ __host__ void fun4() {}
+
+#define __noinline__ __attribute__((__noinline__))
+__noinline__ __device__ __host__ void fun5() {}
+
+__device__ __host__ void fun6() {}
+
+// CHECK: define{{.*}}@_Z4fun1v{{.*}}#[[ATTR1:[0-9]*]]
+// CHECK: define{{.*}}@_Z4fun2v{{.*}}#[[ATTR1:[0-9]*]]
+// CHECK: define{{.*}}@_Z4fun3v{{.*}}#[[ATTR1:[0-9]*]]
+// CHECK: define{{.*}}@_Z4fun4v{{.*}}#[[ATTR1:[0-9]*]]
+// CHECK: define{{.*}}@_Z4fun5v{{.*}}#[[ATTR1:[0-9]*]]
+// CHECK: define{{.*}}@_Z4fun6v{{.*}}#[[ATTR2:[0-9]*]]
+// CHECK: attributes #[[ATTR1]] = {{.*}}noinline
+// CHECK-NOT: attributes #[[ATTR2]] = {{.*}}noinline
Index: clang/lib/Parse/ParseDecl.cpp
===
--- clang/lib/Parse/ParseDecl.cpp
+++ clang/lib/Parse/ParseDecl.cpp
@@ -897,6 +897,15 @@
   }
 }
 
+void Parser::ParseCUDAFunctionAttributes(ParsedAttributes ) {
+  while (Tok.is(tok::kw___noinline__)) {
+IdentifierInfo *AttrName = Tok.getIdentifierInfo();
+SourceLocation AttrNameLoc = ConsumeToken();
+attrs.addNew(AttrName, AttrNameLoc, nullptr, AttrNameLoc, nullptr, 0,
+ ParsedAttr::AS_Keyword);
+  }
+}
+
 void Parser::ParseOpenCLQualifiers(ParsedAttributes ) {
   IdentifierInfo *AttrName = Tok.getIdentifierInfo();
   SourceLocation AttrNameLoc = Tok.getLocation();
@@ -3690,6 +3699,11 @@
   ParseOpenCLKernelAttributes(DS.getAttributes());
   continue;
 
+// CUDA/HIP single token adornments.
+case tok::kw___noinline__:
+  ParseCUDAFunctionAttributes(DS.getAttributes());
+  continue;
+
 // Nullability type specifiers.
 case tok::kw__Nonnull:
 case tok::kw__Nullable:
Index: clang/lib/Basic/IdentifierTable.cpp
===
--- clang/lib/Basic/IdentifierTable.cpp
+++ clang/lib/Basic/IdentifierTable.cpp
@@ -108,6 +108,7 @@
 KEYOPENCLCXX  = 0x40,
 KEYMSCOMPAT   = 0x80,
 KEYSYCL   = 0x100,
+KEYCUDA   = 0x200,
 KEYALLCXX = KEYCXX | KEYCXX11 | KEYCXX20,
 KEYALL = 

[clang] afc9d67 - [CUDA][HIP] support __noinline__ as keyword

[Yaxun Liu via cfe-commits]

Author: Yaxun (Sam) Liu
Date: 2022-05-10T14:32:27-04:00
New Revision: afc9d674fe5a14b95c50a38d8605a159c2460427

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

LOG: [CUDA][HIP] support __noinline__ as keyword

CUDA/HIP programs use __noinline__ like a keyword e.g.
__noinline__ void foo() {} since __noinline__ is defined
as a macro __attribute__((noinline)) in CUDA/HIP runtime
header files.

However, gcc and clang supports __attribute__((__noinline__))
the same as __attribute__((noinline)). Some C++ libraries
use __attribute__((__noinline__)) in their header files.
When CUDA/HIP programs include such header files,
clang will emit error about invalid attributes.

This patch fixes this issue by supporting __noinline__ as
a keyword, so that CUDA/HIP runtime could remove
the macro definition.

Reviewed by: Aaron Ballman, Artem Belevich

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

Added: 
clang/test/CodeGenCUDA/noinline.cu
clang/test/Lexer/has_feature.cu
clang/test/SemaCUDA/noinline.cu

Modified: 
clang/docs/ReleaseNotes.rst
clang/include/clang/Basic/Attr.td
clang/include/clang/Basic/AttrDocs.td
clang/include/clang/Basic/Features.def
clang/include/clang/Basic/TokenKinds.def
clang/include/clang/Parse/Parser.h
clang/lib/Basic/IdentifierTable.cpp
clang/lib/Parse/ParseDecl.cpp

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index c3605ab9bda3..ff7b4285b7d7 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -351,8 +351,11 @@ C++2b Feature Support
 - Implemented `P0849R8: auto(x): decay-copy in the language 
`_.
 - Implemented `P2242R3: Non-literal variables (and labels and gotos) in 
constexpr functions`_.
 
-CUDA Language Changes in Clang
---
+CUDA/HIP Language Changes in Clang
+--
+
+- Added `__noinline__` as a keyword to avoid diagnostics due to usage of
+ `__attribute__((__noinline__))` in CUDA/HIP programs.
 
 Objective-C Language Changes in Clang
 -

diff  --git a/clang/include/clang/Basic/Attr.td 
b/clang/include/clang/Basic/Attr.td
index eb896fe210f9..39359f414ae7 100644
--- a/clang/include/clang/Basic/Attr.td
+++ b/clang/include/clang/Basic/Attr.td
@@ -1775,8 +1775,9 @@ def Convergent : InheritableAttr {
 }
 
 def NoInline : DeclOrStmtAttr {
-  let Spellings = [GCC<"noinline">, CXX11<"clang", "noinline">,
-   C2x<"clang", "noinline">, Declspec<"noinline">];
+  let Spellings = [Keyword<"__noinline__">, GCC<"noinline">,
+   CXX11<"clang", "noinline">, C2x<"clang", "noinline">,
+   Declspec<"noinline">];
   let Accessors = [Accessor<"isClangNoInline", [CXX11<"clang", "noinline">,
 C2x<"clang", "noinline">]>];
   let Documentation = [NoInlineDocs];

diff  --git a/clang/include/clang/Basic/AttrDocs.td 
b/clang/include/clang/Basic/AttrDocs.td
index 02b6031fd5aa..c7ef52f67afa 100644
--- a/clang/include/clang/Basic/AttrDocs.td
+++ b/clang/include/clang/Basic/AttrDocs.td
@@ -538,6 +538,10 @@ spellings of the attribute are not supported on 
statements. If a statement is
 marked ``[[clang::noinline]]`` and contains calls, those calls inside the
 statement will not be inlined by the compiler.
 
+``__noinline__`` can be used as a keyword in CUDA/HIP languages. This is to
+avoid diagnostics due to usage of ``__attribute__((__noinline__))``
+with ``__noinline__`` defined as a macro as ``__attribute__((noinline))``.
+
 .. code-block:: c
 
   int example(void) {

diff  --git a/clang/include/clang/Basic/Features.def 
b/clang/include/clang/Basic/Features.def
index fbaa6174f9bf..c3f3fe79770d 100644
--- a/clang/include/clang/Basic/Features.def
+++ b/clang/include/clang/Basic/Features.def
@@ -270,5 +270,8 @@ EXTENSION(cxx_attributes_on_using_declarations, 
LangOpts.CPlusPlus11)
 
 FEATURE(cxx_abi_relative_vtable, LangOpts.CPlusPlus && 
LangOpts.RelativeCXXABIVTables)
 
+// CUDA/HIP Features
+FEATURE(cuda_noinline_keyword, LangOpts.CUDA)
+
 #undef EXTENSION
 #undef FEATURE

diff  --git a/clang/include/clang/Basic/TokenKinds.def 
b/clang/include/clang/Basic/TokenKinds.def
index 093389615c26..7b65a1537805 100644
--- a/clang/include/clang/Basic/TokenKinds.def
+++ b/clang/include/clang/Basic/TokenKinds.def
@@ -599,6 +599,9 @@ KEYWORD(pipe, KEYOPENCLC | 
KEYOPENCLCXX)
 // C++ for OpenCL s2.3.1: addrspace_cast operator
 KEYWORD(addrspace_cast  , KEYOPENCLCXX)
 
+// CUDA/HIP function attributes
+KEYWORD(__noinline__, KEYCUDA)
+
 // OpenMP Type Traits
 

[PATCH] D125165: [Clang] Introduce clang-offload-packager tool to bundle device files

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 updated this revision to Diff 428443.
jhuber6 added a comment.

Adding some extra documentation.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125165

Files:
  clang/docs/ClangOffloadPackager.rst
  clang/include/clang/Basic/CodeGenOptions.h
  clang/include/clang/Driver/Action.h
  clang/include/clang/Driver/ToolChain.h
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/Driver/Action.cpp
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChain.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/Clang.h
  clang/test/Driver/amdgpu-openmp-toolchain-new.c
  clang/test/Driver/cuda-openmp-driver.cu
  clang/test/Driver/cuda-phases.cu
  clang/test/Driver/linker-wrapper-image.c
  clang/test/Driver/linker-wrapper.c
  clang/test/Driver/openmp-offload-gpu-new.c
  clang/test/Driver/openmp-offload-infer.c
  clang/test/Frontend/embed-object.c
  clang/test/Frontend/embed-object.ll
  clang/test/lit.cfg.py
  clang/tools/CMakeLists.txt
  clang/tools/clang-offload-packager/CMakeLists.txt
  clang/tools/clang-offload-packager/ClangOffloadPackager.cpp

Index: clang/tools/clang-offload-packager/ClangOffloadPackager.cpp
===
--- /dev/null
+++ clang/tools/clang-offload-packager/ClangOffloadPackager.cpp
@@ -0,0 +1,114 @@
+//===-- clang-offload-packager/ClangOffloadPackager.cpp - file bundler ---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===-===//
+//
+// This tool takes several device object files and bundles them into a single
+// binary image using a custom binary format. This is intended to be used to
+// embed many device files into an application to create a fat binary.
+//
+//===-===//
+
+#include "clang/Basic/Version.h"
+
+#include "llvm/Object/Binary.h"
+#include "llvm/Object/ObjectFile.h"
+#include "llvm/Object/OffloadBinary.h"
+#include "llvm/Support/CommandLine.h"
+#include "llvm/Support/FileOutputBuffer.h"
+#include "llvm/Support/MemoryBuffer.h"
+#include "llvm/Support/Path.h"
+#include "llvm/Support/Signals.h"
+#include "llvm/Support/WithColor.h"
+
+using namespace llvm;
+using namespace llvm::object;
+
+static cl::opt Help("h", cl::desc("Alias for -help"), cl::Hidden);
+
+static cl::OptionCategory
+ClangOffloadPackagerCategory("clang-offload-packager options");
+
+static cl::opt OutputFile("o", cl::Required,
+   cl::desc("Write output to ."),
+   cl::value_desc("file"),
+   cl::cat(ClangOffloadPackagerCategory));
+
+static cl::list
+DeviceImages("image", cl::ZeroOrMore,
+ cl::desc("List of key and value arguments. Required keywords "
+  "are 'file' and 'triple'."),
+ cl::value_desc("=,..."),
+ cl::cat(ClangOffloadPackagerCategory));
+
+static void PrintVersion(raw_ostream ) {
+  OS << clang::getClangToolFullVersion("clang-offload-packager") << '\n';
+}
+
+int main(int argc, const char **argv) {
+  sys::PrintStackTraceOnErrorSignal(argv[0]);
+  cl::HideUnrelatedOptions(ClangOffloadPackagerCategory);
+  cl::SetVersionPrinter(PrintVersion);
+  cl::ParseCommandLineOptions(
+  argc, argv,
+  "A utility for bundling several object files into a single binary.\n"
+  "The output binary can then be embedded into the host section table\n"
+  "to create a fatbinary containing offloading code.\n");
+
+  if (Help) {
+cl::PrintHelpMessage();
+return EXIT_SUCCESS;
+  }
+
+  auto reportError = [argv](Error E) {
+logAllUnhandledErrors(std::move(E), WithColor::error(errs(), argv[0]));
+return EXIT_FAILURE;
+  };
+
+  SmallVector BinaryData;
+  raw_svector_ostream OS(BinaryData);
+  for (StringRef Image : DeviceImages) {
+StringMap Args;
+for (StringRef Arg : llvm::split(Image, ","))
+  Args.insert(Arg.split("="));
+
+if (!Args.count("triple") || !Args.count("file"))
+  return reportError(createStringError(
+  inconvertibleErrorCode(),
+  "'file' and 'triple' are required image arguments"));
+
+OffloadBinary::OffloadingImage ImageBinary{};
+std::unique_ptr DeviceImage;
+for (const auto  : Args) {
+  StringRef Key = KeyAndValue.getKey();
+  if (Key == "file") {
+llvm::ErrorOr> ObjectOrErr =
+llvm::MemoryBuffer::getFileOrSTDIN(KeyAndValue.getValue());
+if (std::error_code EC = ObjectOrErr.getError())
+  return reportError(errorCodeToError(EC));
+DeviceImage = std::move(*ObjectOrErr);
+ImageBinary.Image = *DeviceImage;
+

[PATCH] D124974: [clang] Include clang config.h in LangStandards.cpp

[Duncan P. N. Exon Smith via Phabricator via cfe-commits]

dexonsmith added a comment.

In D124974#3494374 , @sammccall wrote:

> In D124974#3494279 , @dexonsmith 
> wrote:
>
>> Can we add a test for this?
>
> I think the problem with testing it is that this variable comes from the 
> CMake config, and in the default configuration (as used by all the bots) it's 
> not set.

Maybe you could use the same CMake config to set a lit variable, and use that 
lit variable to test that we get the configured default language variant.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124974

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

[PATCH] D124816: [LibTooling] use ToolFileManager to store file managers for each CWD

[Duncan P. N. Exon Smith via Phabricator via cfe-commits]

dexonsmith added a comment.

This looks mostly correct to me, but perhaps pessimistic enough it'll regress 
performance unnecessarily. A few comments inline.




Comment at: 
clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp:169-170
 ScanInstance.getFrontendOpts().UseGlobalModuleIndex = false;
-
+auto FileMgr = ToolFileMgr->getOrCreateFileManager().get();
 FileMgr->getFileSystemOpts().WorkingDir = std::string(WorkingDirectory);
 ScanInstance.setFileManager(FileMgr);

Should `WorkingDirectory` be an argument to `getOrCreateFileManager()` here?



Comment at: 
clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp:171-172
 FileMgr->getFileSystemOpts().WorkingDir = std::string(WorkingDirectory);
 ScanInstance.setFileManager(FileMgr);
 ScanInstance.createSourceManager(*FileMgr);
 

Do these need to be moved lower, after the FileMgr/VFS might change?



Comment at: 
clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp:202-203
   // filesystem.
-  FileMgr->setVirtualFileSystem(createVFSFromCompilerInvocation(
+  ToolFileMgr->setVirtualFileSystem(createVFSFromCompilerInvocation(
   ScanInstance.getInvocation(), ScanInstance.getDiagnostics(), DepFS));
 

I don't see how calling this on `ToolFileMgr` threads through to updating the 
`FileMgr` in use, which has already been sent to `ScanInstance`.

Note that `createVFSFromCompilerInvocation()` *always* returns a new VFS, even 
if it's equivalent to the one used before (same DepFS options and same 
`-ivfsoverlay`s from `ScanInstance.getInvocation()`). Threading it through 
would mean that `FileMgr` is never reused.

IMO, never-reuse-the-filemanager is the right/correct behaviour for 
clang-scan-deps, since DepFS provides caching for things that can be cached 
soundly, but probably better to explicitly stop reusing the FileMgr (in a 
separate patch ahead of time) rather than leaving code that looks like it might 
get reused.



Comment at: clang/lib/Tooling/Tooling.cpp:447-448
   appendArgumentsAdjuster(getClangStripDependencyFileAdjuster());
   if (Files)
 Files->setVirtualFileSystem(OverlayFileSystem);
 }

This will *never* reuse the file manager, since it's *always* a new VFS.
- Maybe that's correct, since we want to inject different things into 
InMemoryFS?
- Or, maybe that's overly pessimistic, and we should pass BaseFS into the 
filemanager if `appendArgumentsAdjuster()` never added anything to InMemoryFS?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124816

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

[PATCH] D124534: [clang] Add a diagnostic for line directive of a gnu extension

[Ken Matsui via Phabricator via cfe-commits]

ken-matsui added a comment.

Thank you for your review! I'm going to fix them :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124534

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

[PATCH] D125078: Implement a feature to show line numbers in diagnostics

[Ken Matsui via Phabricator via cfe-commits]

ken-matsui added a comment.

Thank you all so much :)))


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125078

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

[PATCH] D125142: [clang][auto-init] Remove -enable flag for "zero" mode

[Kees Cook via Phabricator via cfe-commits]

kees added a comment.

In D125142#3502732 , @MaskRay wrote:

> This cannot be committed as is. In particular, @rsmith's "We do not want to 
> create or encourage the creation of language dialects and non-portable code," 
> concern on 
> https://discourse.llvm.org/t/making-ftrivial-auto-var-init-zero-a-first-class-option/55143/2
>  (shared by someone else) will be affected, I'd like to see that they lift 
> their concerns.

FWIW, I think this concern was addressed back when `-ftrivial-auto-var-init` 
was added: uninitialized variables are considered UB, and the compiler would 
warn about them with `-Wuninitialized`. The coverage of `-Wuninitialized` was 
expressly not changed, so code will still warn about the uninitialized variable 
usage (but the actual contents of that variable is now at least constant). The 
point being, the dialect remains unchanged and the portability remains 
unchanged; it is only the safety of the resulting binary that is now improved. 
i.e. the UB still exists (the logic of the code may not match the content of 
the variable), but it's predictable now, instead of being potentially 
controllable by external factors (i.e. the prior stack contents, which may be 
controllable across privilege boundaries 
).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125142

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

[PATCH] D124866: [CUDA][HIP] support __noinline__ as keyword

[Artem Belevich via Phabricator via cfe-commits]

tra added inline comments.



Comment at: clang/test/SemaCUDA/noinline.cu:8
+__attribute__((noinline)) void fun2() { }
+__attribute__((__noinline__)) void fun3() { }

aaron.ballman wrote:
> yaxunl wrote:
> > aaron.ballman wrote:
> > > yaxunl wrote:
> > > > aaron.ballman wrote:
> > > > > yaxunl wrote:
> > > > > > aaron.ballman wrote:
> > > > > > > yaxunl wrote:
> > > > > > > > aaron.ballman wrote:
> > > > > > > > > I think there should also be a test like:
> > > > > > > > > ```
> > > > > > > > > [[gnu::__noinline__]] void fun4() {}
> > > > > > > > > ```
> > > > > > > > > to verify that the double square bracket syntax also 
> > > > > > > > > correctly handles this being a keyword now (I expect the test 
> > > > > > > > > to pass).
> > > > > > > > will do
> > > > > > > Ah, I just noticed we also have no tests for the behavior of the 
> > > > > > > keyword in the presence of the macro being defined. e.g.,
> > > > > > > ```
> > > > > > > #define __noinline__ __attribute__((__noinline__))
> > > > > > > __noinline__ void fun5() {}
> > > > > > > ```
> > > > > > will do
> > > > > I missed an important detail -- I think this is now going to generate 
> > > > > a warning in `-pedantic` mode (through `-Wkeyword-macro`) when 
> > > > > compiling for CUDA; is that going to be a problem for CUDA headers, 
> > > > > or are those always included as a system header (and so the 
> > > > > diagnostics will be suppressed)?
> > > > I could not find how clang driver adds CUDA include path
> > > > 
> > > > https://github.com/llvm/llvm-project/blob/main/clang/lib/Driver/ToolChains/Cuda.cpp#L284
> > > > 
> > > > @tra do you know how CUDA include path is added? is it done by CMake? 
> > > > 
> > > > For HIP the HIP include path is added as a system include path by clang 
> > > > driver.
> > > Whatever we find out, we can emulate its behavior here in the test file 
> > > to see what the diagnostic behavior will be (you can use GNU linemarkers 
> > > to convince the compiler parts of the source are in a system header).
> > will add tests for that.
> > 
> > It seems no matter it is system header or normal header, no warnings are 
> > emitted even with -pedantic.
> Excellent, thank you!
CUDA includes are added via `-internal-isystem` here: 
https://github.com/llvm/llvm-project/blob/main/clang/lib/Driver/ToolChains/Cuda.cpp#L892


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

https://reviews.llvm.org/D124866

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

[PATCH] D125178: Warn if using `elifdef` & `elifndef` in not C2x & C++2b mode

[Ken Matsui via Phabricator via cfe-commits]

ken-matsui updated this revision to Diff 428435.
ken-matsui added a comment.

Fix failed tests


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125178

Files:
  clang/include/clang/Basic/DiagnosticLexKinds.td
  clang/lib/Lex/PPDirectives.cpp
  clang/test/Lexer/Inputs/unsafe-macro-2.h
  clang/test/Lexer/deprecate-macro.c
  clang/test/Preprocessor/elifdef.c
  clang/test/Preprocessor/ext-c2x-pp-directive.c
  clang/test/Preprocessor/ext-cpp2b-pp-directive.cpp
  clang/test/Preprocessor/if_warning.c
  clang/test/Preprocessor/ifdef-recover.c
  clang/test/Preprocessor/macro_misc.c
  clang/test/Preprocessor/macro_vaopt_check.cpp

Index: clang/test/Preprocessor/macro_vaopt_check.cpp
===
--- clang/test/Preprocessor/macro_vaopt_check.cpp
+++ clang/test/Preprocessor/macro_vaopt_check.cpp
@@ -1,6 +1,6 @@
-// RUN: %clang_cc1 %s -Eonly -verify -Wno-all -pedantic -std=c++20
-// RUN: %clang_cc1 %s -Eonly -verify -Wno-all -pedantic -std=c++11
-// RUN: %clang_cc1 -x c %s -Eonly -verify -Wno-all -pedantic -std=c99
+// RUN: %clang_cc1 %s -Eonly -verify -Wno-all -Wno-c++2b-extensions -pedantic -std=c++20
+// RUN: %clang_cc1 %s -Eonly -verify -Wno-all -Wno-c++2b-extensions -pedantic -std=c++11
+// RUN: %clang_cc1 -x c %s -Eonly -verify -Wno-all -Wno-c2x-extensions -pedantic -std=c99
 
 //expected-error@+1{{missing '('}}
 #define V1(...) __VA_OPT__  
Index: clang/test/Preprocessor/macro_misc.c
===
--- clang/test/Preprocessor/macro_misc.c
+++ clang/test/Preprocessor/macro_misc.c
@@ -4,6 +4,7 @@
 #ifdef defined
 #elifdef defined
 #endif
+// expected-warning@-2 {{use of a '#elifdef' directive is a C2x extension}}
 
 
 
Index: clang/test/Preprocessor/ifdef-recover.c
===
--- clang/test/Preprocessor/ifdef-recover.c
+++ clang/test/Preprocessor/ifdef-recover.c
@@ -19,12 +19,14 @@
 #if f(2
 #endif
 
-/* expected-error@+2 {{macro name missing}} */
+/* expected-error@+3 {{macro name missing}} */
+// expected-warning@+2 {{use of a '#elifdef' directive is a C2x extension}}
 #ifdef FOO
 #elifdef
 #endif
 
-/* expected-error@+2 {{macro name must be an identifier}} */
+/* expected-error@+3 {{macro name must be an identifier}} */
+// expected-warning@+2 {{use of a '#elifdef' directive is a C2x extension}}
 #ifdef FOO
 #elifdef !
 #endif
Index: clang/test/Preprocessor/if_warning.c
===
--- clang/test/Preprocessor/if_warning.c
+++ clang/test/Preprocessor/if_warning.c
@@ -5,6 +5,7 @@
 #if foo   // expected-error {{'foo' is not defined, evaluates to 0}}
 #endif
 
+// expected-warning@+2 {{use of a '#elifdef' directive is a C2x extension}}
 #ifdef foo
 #elifdef foo
 #endif
@@ -14,6 +15,7 @@
 
 
 // PR3938
+// expected-warning@+3 {{use of a '#elifdef' directive is a C2x extension}}
 #if 0
 #ifdef D
 #elifdef D
Index: clang/test/Preprocessor/ext-cpp2b-pp-directive.cpp
===
--- /dev/null
+++ clang/test/Preprocessor/ext-cpp2b-pp-directive.cpp
@@ -0,0 +1,31 @@
+// RUN: %clang_cc1 -x c++ -fsyntax-only -verify=pre-cpp2b-pedantic -pedantic %s
+// RUN: %clang_cc1 -x c++ -std=c++2b -fsyntax-only -verify=pre-cpp2b-compat -Wpre-c++2b-compat %s
+// RUN: not %clang_cc1 -x c++ -fsyntax-only -verify %s
+// RUN: not %clang_cc1 -x c++ -std=c++2b -fsyntax-only -verify -pedantic %s
+// RUN: not %clang_cc1 -x c++ -std=c++2b -fsyntax-only -verify %s
+
+int x;
+
+#if 1
+#elifdef A // #1
+#endif
+// pre-cpp2b-pedantic-warning@#1 {{use of a '#elifdef' directive is a C++2b extension}}
+// pre-cpp2b-compat-warning@#1 {{use of a '#elifdef' directive is incompatible with C++ standards before C++2b}}
+
+#if 1
+#elifndef B // #2
+#endif
+// pre-cpp2b-pedantic-warning@#2 {{use of a '#elifndef' directive is a C++2b extension}}
+// pre-cpp2b-compat-warning@#2 {{use of a '#elifndef' directive is incompatible with C++ standards before C++2b}}
+
+#if 0
+#elifdef C
+#endif
+// pre-cpp2b-pedantic-warning@-2 {{use of a '#elifdef' directive is a C++2b extension}}
+// pre-cpp2b-compat-warning@-3 {{use of a '#elifdef' directive is incompatible with C++ standards before C++2b}}
+
+#if 0
+#elifndef D
+#endif
+// pre-cpp2b-pedantic-warning@-2 {{use of a '#elifndef' directive is a C++2b extension}}
+// pre-cpp2b-compat-warning@-3 {{use of a '#elifndef' directive is incompatible with C++ standards before C++2b}}
Index: clang/test/Preprocessor/ext-c2x-pp-directive.c
===
--- /dev/null
+++ clang/test/Preprocessor/ext-c2x-pp-directive.c
@@ -0,0 +1,31 @@
+// RUN: %clang_cc1 -std=c99 -fsyntax-only -verify=c99-pedantic -pedantic %s
+// RUN: %clang_cc1 -std=c2x -fsyntax-only -verify=pre-c2x-compat -Wpre-c2x-compat %s
+// RUN: not %clang_cc1 

[PATCH] D125272: [clang] Add -fcheck-new support

[Pedro Falcato via Phabricator via cfe-commits]

heatd updated this revision to Diff 428433.
heatd added a comment.

Adjusted the driver code to use addOptInFlag, adjusted the test, fixed the 
comment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125272

Files:
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Basic/LangOptions.h
  clang/include/clang/Driver/Options.td
  clang/lib/AST/ExprCXX.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/test/CodeGenCXX/fcheck-new.cpp
  clang/test/Driver/clang_f_opts.c

Index: clang/test/Driver/clang_f_opts.c
===
--- clang/test/Driver/clang_f_opts.c
+++ clang/test/Driver/clang_f_opts.c
@@ -298,7 +298,6 @@
 // RUN: -fno-reorder-blocks -freorder-blocks  \
 // RUN: -fno-schedule-insns2 -fschedule-insns2\
 // RUN: -fno-stack-check  \
-// RUN: -fno-check-new -fcheck-new\
 // RUN: -ffriend-injection\
 // RUN: -fno-implement-inlines -fimplement-inlines\
 // RUN: -fstack-check \
Index: clang/test/CodeGenCXX/fcheck-new.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/fcheck-new.cpp
@@ -0,0 +1,12 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// RUN: %clang_cc1 -fcheck-new -triple x86_64-linux-gnu -S -disable-O0-optnone \
+// RUN: -emit-llvm -o - %s | opt -S -mem2reg | FileCheck %s
+
+// CHECK-LABEL: @_Z5test0v(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[CALL:%.*]] = call noalias noundef ptr @_Znwm(i64 noundef 4) #[[ATTR2:[0-9]+]]
+// CHECK-NEXT:ret ptr [[CALL]]
+//
+int *test0() {
+  return new int;
+}
Index: clang/lib/Sema/SemaExprCXX.cpp
===
--- clang/lib/Sema/SemaExprCXX.cpp
+++ clang/lib/Sema/SemaExprCXX.cpp
@@ -3104,7 +3104,8 @@
 // Global allocation functions should always be visible.
 Alloc->setVisibleDespiteOwningModule();
 
-if (HasBadAllocExceptionSpec && getLangOpts().NewInfallible)
+if (HasBadAllocExceptionSpec && getLangOpts().NewInfallible &&
+!getLangOpts().CheckNew)
   Alloc->addAttr(
   ReturnsNonNullAttr::CreateImplicit(Context, Alloc->getLocation()));
 
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -15436,7 +15436,11 @@
   //   indicates failure by returning a null pointer value. Any other allocation
   //   function never returns a null pointer value and indicates failure only by
   //   throwing an exception [...]
-  if (!IsNothrow && !FD->hasAttr())
+  //
+  // However, -fcheck-new invalidates this possible assumption, so don't add
+  // NonNull when that is enabled.
+  if (!IsNothrow && !FD->hasAttr() &&
+  !getLangOpts().CheckNew)
 FD->addAttr(ReturnsNonNullAttr::CreateImplicit(Context, FD->getLocation()));
 
   // C++2a [basic.stc.dynamic.allocation]p2:
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -4113,6 +4113,9 @@
   if (const Arg *A = Args.getLastArg(OPT_frandomize_layout_seed_EQ))
 Opts.RandstructSeed = A->getValue(0);
 
+  if (const Arg *A = Args.getLastArg(OPT_fcheck_new))
+Opts.CheckNew = true;
+
   return Diags.getNumErrors() == NumErrorsBefore;
 }
 
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -5981,6 +5981,9 @@
   options::OPT_fno_emulated_tls);
   Args.AddLastArg(CmdArgs, options::OPT_fzero_call_used_regs_EQ);
 
+  Args.addOptInFlag(CmdArgs, options::OPT_fcheck_new,
+options::OPT_fno_check_new);
+
   if (Arg *A = Args.getLastArg(options::OPT_fzero_call_used_regs_EQ)) {
 // FIXME: There's no reason for this to be restricted to X86. The backend
 // code needs to be changed to include the appropriate function calls
Index: clang/lib/AST/ExprCXX.cpp
===
--- clang/lib/AST/ExprCXX.cpp
+++ clang/lib/AST/ExprCXX.cpp
@@ -275,6 +275,8 @@
 }
 
 bool CXXNewExpr::shouldNullCheckAllocation() const {
+  if (getOperatorNew()->getLangOpts().CheckNew)
+return true;
   return !getOperatorNew()->hasAttr() &&
  getOperatorNew()
  ->getType()
Index: 

[clang] 0456654 - [OpenMP] Fix embedding offload code when there is no offloading toolchain

[Joseph Huber via cfe-commits]

Author: Joseph Huber
Date: 2022-05-10T13:33:20-04:00
New Revision: 045665423e6e893ee168368dab10469c8d3168c5

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

LOG: [OpenMP] Fix embedding offload code when there is no offloading toolchain

Summary:
We use the `--offload-new-driver` option to enable offload code
embedding. The check for when to do this was flawed and was enabling it
too early in the case of OpenMP, causing a segfault when dereferencing
the offloading toolchain.

Added: 


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

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index 4fc126353475..6934b8dd2d6c 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -4405,8 +4405,10 @@ void Clang::ConstructJob(Compilation , const JobAction 
,
   (JA.isHostOffloading(Action::OFK_OpenMP) &&
Args.hasFlag(options::OPT_fopenmp_new_driver,
 options::OPT_no_offload_new_driver, true)) ||
-  Args.hasFlag(options::OPT_offload_new_driver,
-   options::OPT_no_offload_new_driver, false);
+  (JA.isHostOffloading(C.getActiveOffloadKinds()) &&
+   Args.hasFlag(options::OPT_offload_new_driver,
+options::OPT_no_offload_new_driver, false));
+
   bool IsUsingLTO = D.isUsingLTO(IsDeviceOffloadAction);
   auto LTOMode = D.getLTOMode(IsDeviceOffloadAction);
 



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

[PATCH] D125078: Implement a feature to show line numbers in diagnostics

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

xbolva00 added a comment.

In D125078#3503921 , @cjdb wrote:

> I support turning it on by default. I'm simply passing on the message.

+1, I support on by default as well.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125078

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

[PATCH] D124750: [MLIR] Add a utility to sort the operands of commutative ops

[River Riddle via Phabricator via cfe-commits]

rriddle added a comment.

+1 on all of the other comments, especially related to the use of strings.

In D124750#3503607 , @Mogball wrote:

> On the matter of whether this should be a canonicalization, my concern with 
> this is that if an operation has its own preferred ordering of operands that 
> conflicts with the sort, then this will cause canonicalization to loop 
> infinitely.
>
> It's not actually the canonicalizer pass that moves constants to the right 
> hand size. It's the folder. And it probably shouldn't be the folder that does 
> this. So I'm open to making this part of canonicalization IF the sorted 
> operand order produced by this utility is the canonical order of operands for 
> commutative operations, so that conflicts are not possible.

We can decide whatever we want the canonical ordering of operands to be for the 
Commutative trait. We don't have to leave things up to operations if it doesn't 
make sense.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124750

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

[PATCH] D123273: [utils] Avoid hardcoding metadata ids in update_cc_test_checks

[Jan Korous 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 rGce583b14b2ec: [utils] Avoid hardcoding metadata ids in 
update_cc_test_checks (authored by jkorous).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123273

Files:
  clang/test/utils/update_cc_test_checks/Inputs/annotation-id.c
  clang/test/utils/update_cc_test_checks/Inputs/annotation-id.expected
  clang/test/utils/update_cc_test_checks/Inputs/nosanitize-id.c
  clang/test/utils/update_cc_test_checks/Inputs/nosanitize-id.expected
  clang/test/utils/update_cc_test_checks/Inputs/srcloc-id.c
  clang/test/utils/update_cc_test_checks/Inputs/srcloc-id.expected
  clang/test/utils/update_cc_test_checks/Inputs/tbaa-id.c
  clang/test/utils/update_cc_test_checks/Inputs/tbaa-id.expected
  clang/test/utils/update_cc_test_checks/Inputs/tbaa-struct-id.c
  clang/test/utils/update_cc_test_checks/Inputs/tbaa-struct-id.expected
  clang/test/utils/update_cc_test_checks/annotation-id.test
  clang/test/utils/update_cc_test_checks/nosanitize-id.test
  clang/test/utils/update_cc_test_checks/srcloc-id.test
  clang/test/utils/update_cc_test_checks/tbaa-id.test
  clang/test/utils/update_cc_test_checks/tbaa-struct-id.test
  llvm/utils/UpdateTestChecks/common.py

Index: llvm/utils/UpdateTestChecks/common.py
===
--- llvm/utils/UpdateTestChecks/common.py
+++ llvm/utils/UpdateTestChecks/common.py
@@ -616,11 +616,15 @@
 NamelessValue(r'GLOB' , '@' , None   , r'@', r'[a-zA-Z0-9_$"\\.-]+' , None , r'.+', True)  ,
 NamelessValue(r'DBG'  , '!' , r'!dbg '   , None, None   , r'![0-9]+'   , None , False) ,
 NamelessValue(r'PROF' , '!' , r'!prof '  , None, None   , r'![0-9]+'   , None , False) ,
-NamelessValue(r'TBAA' , '!' , r'!tbaa '  , None, None   , r'![0-9]+'   , None , False) ,
 NamelessValue(r'RNG'  , '!' , r'!range ' , None, None   , r'![0-9]+'   , None , False) ,
 NamelessValue(r'LOOP' , '!' , r'!llvm.loop ' , None, None   , r'![0-9]+'   , None , False) ,
 NamelessValue(r'META' , '!' , r'metadata '   , None, None   , r'![0-9]+'   , None , False) ,
 NamelessValue(r'META' , '!' , None   , r'' , r'![0-9]+' , None , r'(?:distinct |)!.*' , False) ,
+NamelessValue(r'TBAA' , '!' , r'!tbaa '  , None, None   , r'![0-9]+'   , None , False) ,
+NamelessValue(r'TBAAST' , '!' , r'!tbaa.struct ', None, None   , r'![0-9]+'   , None , False) ,
+NamelessValue(r'ANNT'   , '!' , r'!annotation ' , None, None   , r'![0-9]+'   , None , False) ,
+NamelessValue(r'SRCLOC' , '!' , r'!srcloc ' , None, None   , r'![0-9]+'   , None , False) ,
+NamelessValue(r'NOSAN'  , '!' , r'!nosanitize ' , None, None   , r'![0-9]+'   , None , False) ,
 ]
 
 def createOrRegexp(old, new):
Index: clang/test/utils/update_cc_test_checks/tbaa-struct-id.test
===
--- /dev/null
+++ clang/test/utils/update_cc_test_checks/tbaa-struct-id.test
@@ -0,0 +1,7 @@
+## Test that CHECK lines are generated before the definion and not the declaration
+
+# RUN: cp %S/Inputs/tbaa-struct-id.c %t.c && %update_cc_test_checks %t.c
+# RUN: diff -u %S/Inputs/tbaa-struct-id.expected %t.c
+## Check that re-running update_cc_test_checks doesn't change the output
+# RUN: %update_cc_test_checks %t.c
+# RUN: diff -u %S/Inputs/tbaa-struct-id.expected %t.c
Index: clang/test/utils/update_cc_test_checks/tbaa-id.test
===
--- /dev/null
+++ clang/test/utils/update_cc_test_checks/tbaa-id.test
@@ -0,0 +1,7 @@
+## Test that CHECK lines are generated before the definion and not the declaration
+
+# RUN: cp %S/Inputs/tbaa-id.c %t.c && %update_cc_test_checks %t.c
+# RUN: diff -u %S/Inputs/tbaa-id.expected %t.c
+## Check that re-running update_cc_test_checks doesn't change the output
+# RUN: %update_cc_test_checks %t.c
+# RUN: diff -u %S/Inputs/tbaa-id.expected %t.c
Index: clang/test/utils/update_cc_test_checks/srcloc-id.test
===
--- /dev/null
+++ clang/test/utils/update_cc_test_checks/srcloc-id.test
@@ -0,0 +1,7 @@
+## Test that CHECK lines are 

[clang] ce583b1 - [utils] Avoid hardcoding metadata ids in update_cc_test_checks

[Jan Korous via cfe-commits]

Author: Jan Korous
Date: 2022-05-10T10:17:45-07:00
New Revision: ce583b14b2ec37b1c168bb92020680cb452502b3

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

LOG: [utils] Avoid hardcoding metadata ids in update_cc_test_checks

Specifically for: !tbaa, !tbaa.struct, !annotation, !srcloc, !nosanitize.

The goal is to avoid test brittleness caused by hardcoded values.

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

Added: 
clang/test/utils/update_cc_test_checks/Inputs/annotation-id.c
clang/test/utils/update_cc_test_checks/Inputs/annotation-id.expected
clang/test/utils/update_cc_test_checks/Inputs/nosanitize-id.c
clang/test/utils/update_cc_test_checks/Inputs/nosanitize-id.expected
clang/test/utils/update_cc_test_checks/Inputs/srcloc-id.c
clang/test/utils/update_cc_test_checks/Inputs/srcloc-id.expected
clang/test/utils/update_cc_test_checks/Inputs/tbaa-id.c
clang/test/utils/update_cc_test_checks/Inputs/tbaa-id.expected
clang/test/utils/update_cc_test_checks/Inputs/tbaa-struct-id.c
clang/test/utils/update_cc_test_checks/Inputs/tbaa-struct-id.expected
clang/test/utils/update_cc_test_checks/annotation-id.test
clang/test/utils/update_cc_test_checks/nosanitize-id.test
clang/test/utils/update_cc_test_checks/srcloc-id.test
clang/test/utils/update_cc_test_checks/tbaa-id.test
clang/test/utils/update_cc_test_checks/tbaa-struct-id.test

Modified: 
llvm/utils/UpdateTestChecks/common.py

Removed: 




diff  --git a/clang/test/utils/update_cc_test_checks/Inputs/annotation-id.c 
b/clang/test/utils/update_cc_test_checks/Inputs/annotation-id.c
new file mode 100644
index 0..49c7c58375db5
--- /dev/null
+++ b/clang/test/utils/update_cc_test_checks/Inputs/annotation-id.c
@@ -0,0 +1,5 @@
+// RUN: %clang_cc1 -ftrivial-auto-var-init=zero 
-triple=x86_64-unknown-linux-gnu -O1 -disable-llvm-passes -emit-llvm -o - %s | 
FileCheck %s
+
+void foo_ptr_to_scalar() {
+  unsigned long long* a[100];
+}

diff  --git 
a/clang/test/utils/update_cc_test_checks/Inputs/annotation-id.expected 
b/clang/test/utils/update_cc_test_checks/Inputs/annotation-id.expected
new file mode 100644
index 0..d28469eb920dc
--- /dev/null
+++ b/clang/test/utils/update_cc_test_checks/Inputs/annotation-id.expected
@@ -0,0 +1,17 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// RUN: %clang_cc1 -ftrivial-auto-var-init=zero 
-triple=x86_64-unknown-linux-gnu -O1 -disable-llvm-passes -emit-llvm -o - %s | 
FileCheck %s
+
+// CHECK-LABEL: @foo_ptr_to_scalar(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[A:%.*]] = alloca [100 x i64*], align 16
+// CHECK-NEXT:[[TMP0:%.*]] = bitcast [100 x i64*]* [[A]] to i8*
+// CHECK-NEXT:call void @llvm.lifetime.start.p0i8(i64 800, i8* [[TMP0]]) 
#[[ATTR3:[0-9]+]]
+// CHECK-NEXT:[[TMP1:%.*]] = bitcast [100 x i64*]* [[A]] to i8*
+// CHECK-NEXT:call void @llvm.memset.p0i8.i64(i8* align 16 [[TMP1]], i8 0, 
i64 800, i1 false), !annotation [[ANNT2:![0-9]+]]
+// CHECK-NEXT:[[TMP2:%.*]] = bitcast [100 x i64*]* [[A]] to i8*
+// CHECK-NEXT:call void @llvm.lifetime.end.p0i8(i64 800, i8* [[TMP2]]) 
#[[ATTR3]]
+// CHECK-NEXT:ret void
+//
+void foo_ptr_to_scalar() {
+  unsigned long long* a[100];
+}

diff  --git a/clang/test/utils/update_cc_test_checks/Inputs/nosanitize-id.c 
b/clang/test/utils/update_cc_test_checks/Inputs/nosanitize-id.c
new file mode 100644
index 0..d136a861b4214
--- /dev/null
+++ b/clang/test/utils/update_cc_test_checks/Inputs/nosanitize-id.c
@@ -0,0 +1,5 @@
+// RUN: %clang_cc1 -fsanitize=shift-exponent,shift-base 
-triple=x86_64-unknown-linux-gnu -O1 -disable-llvm-passes -emit-llvm -o - %s | 
FileCheck %s
+
+void foo(int* c, int* shamt) {
+  *c = 1 << (*c << *shamt);
+}

diff  --git 
a/clang/test/utils/update_cc_test_checks/Inputs/nosanitize-id.expected 
b/clang/test/utils/update_cc_test_checks/Inputs/nosanitize-id.expected
new file mode 100644
index 0..e8e1c74e46bc6
--- /dev/null
+++ b/clang/test/utils/update_cc_test_checks/Inputs/nosanitize-id.expected
@@ -0,0 +1,55 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// RUN: %clang_cc1 -fsanitize=shift-exponent,shift-base 
-triple=x86_64-unknown-linux-gnu -O1 -disable-llvm-passes -emit-llvm -o - %s | 
FileCheck %s
+
+// CHECK-LABEL: @foo(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[C_ADDR:%.*]] = alloca i32*, align 8
+// CHECK-NEXT:[[SHAMT_ADDR:%.*]] = alloca i32*, align 8
+// CHECK-NEXT:store i32* [[C:%.*]], i32** [[C_ADDR]], align 8, !tbaa 
[[TBAA2:![0-9]+]]
+// CHECK-NEXT:store i32* [[SHAMT:%.*]], i32** [[SHAMT_ADDR]], align 8, 
!tbaa [[TBAA2]]
+// CHECK-NEXT:[[TMP0:%.*]] = load i32*, i32** [[C_ADDR]], align 8, !tbaa 
[[TBAA2]]
+// 

[PATCH] D124866: [CUDA][HIP] support __noinline__ as keyword

[Yaxun Liu via Phabricator via cfe-commits]

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

make it a feature, add tests for pedantic, fix release notes and doecumentation


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

https://reviews.llvm.org/D124866

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/Features.def
  clang/include/clang/Basic/TokenKinds.def
  clang/include/clang/Parse/Parser.h
  clang/lib/Basic/IdentifierTable.cpp
  clang/lib/Parse/ParseDecl.cpp
  clang/test/CodeGenCUDA/noinline.cu
  clang/test/Lexer/has_feature.cu
  clang/test/SemaCUDA/noinline.cu

Index: clang/test/SemaCUDA/noinline.cu
===
--- /dev/null
+++ clang/test/SemaCUDA/noinline.cu
@@ -0,0 +1,19 @@
+// RUN: %clang_cc1 -fsyntax-only -verify=cuda %s
+// RUN: %clang_cc1 -fsyntax-only -verify=cuda -pedantic %s
+// RUN: %clang_cc1 -fsyntax-only -verify=cpp -x c++ %s
+
+// cuda-no-diagnostics
+
+__noinline__ void fun1() { } // cpp-error {{unknown type name '__noinline__'}}
+
+__attribute__((noinline)) void fun2() { }
+__attribute__((__noinline__)) void fun3() { }
+[[gnu::__noinline__]] void fun4() { }
+
+#define __noinline__ __attribute__((__noinline__))
+__noinline__ void fun5() {}
+
+#undef __noinline__
+#10 "cuda.h" 3
+#define __noinline__ __attribute__((__noinline__))
+__noinline__ void fun6() {}
Index: clang/test/Lexer/has_feature.cu
===
--- /dev/null
+++ clang/test/Lexer/has_feature.cu
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 -E -triple x86_64-linux-gnu %s -o - | FileCheck %s
+
+// CHECK: has_noinline_keyword
+#if __has_feature(cuda_noinline_keyword)
+int has_noinline_keyword();
+#else
+int no_noinine_keyword();
+#endif
Index: clang/test/CodeGenCUDA/noinline.cu
===
--- /dev/null
+++ clang/test/CodeGenCUDA/noinline.cu
@@ -0,0 +1,34 @@
+// Uses -O2 since the defalt -O0 option adds noinline to all functions.
+
+// RUN: %clang_cc1 -triple nvptx-nvidia-cuda -fcuda-is-device \
+// RUN: -O2 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s
+
+// RUN: %clang_cc1 -triple amdgcn-amd-amdhsa -fcuda-is-device \
+// RUN: -O2 -disable-llvm-passes -emit-llvm -o - -x hip %s | FileCheck %s
+
+// RUN: %clang_cc1 -triple x86_64-unknown-gnu-linux \
+// RUN: -O2 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s
+
+#include "Inputs/cuda.h"
+
+__noinline__ __device__ __host__ void fun1() {}
+
+__attribute__((noinline)) __device__ __host__ void fun2() {}
+
+__attribute__((__noinline__)) __device__ __host__ void fun3() {}
+
+[[gnu::__noinline__]] __device__ __host__ void fun4() {}
+
+#define __noinline__ __attribute__((__noinline__))
+__noinline__ __device__ __host__ void fun5() {}
+
+__device__ __host__ void fun6() {}
+
+// CHECK: define{{.*}}@_Z4fun1v{{.*}}#[[ATTR1:[0-9]*]]
+// CHECK: define{{.*}}@_Z4fun2v{{.*}}#[[ATTR1:[0-9]*]]
+// CHECK: define{{.*}}@_Z4fun3v{{.*}}#[[ATTR1:[0-9]*]]
+// CHECK: define{{.*}}@_Z4fun4v{{.*}}#[[ATTR1:[0-9]*]]
+// CHECK: define{{.*}}@_Z4fun5v{{.*}}#[[ATTR1:[0-9]*]]
+// CHECK: define{{.*}}@_Z4fun6v{{.*}}#[[ATTR2:[0-9]*]]
+// CHECK: attributes #[[ATTR1]] = {{.*}}noinline
+// CHECK-NOT: attributes #[[ATTR2]] = {{.*}}noinline
Index: clang/lib/Parse/ParseDecl.cpp
===
--- clang/lib/Parse/ParseDecl.cpp
+++ clang/lib/Parse/ParseDecl.cpp
@@ -897,6 +897,15 @@
   }
 }
 
+void Parser::ParseCUDAFunctionAttributes(ParsedAttributes ) {
+  while (Tok.is(tok::kw___noinline__)) {
+IdentifierInfo *AttrName = Tok.getIdentifierInfo();
+SourceLocation AttrNameLoc = ConsumeToken();
+attrs.addNew(AttrName, AttrNameLoc, nullptr, AttrNameLoc, nullptr, 0,
+ ParsedAttr::AS_Keyword);
+  }
+}
+
 void Parser::ParseOpenCLQualifiers(ParsedAttributes ) {
   IdentifierInfo *AttrName = Tok.getIdentifierInfo();
   SourceLocation AttrNameLoc = Tok.getLocation();
@@ -3690,6 +3699,11 @@
   ParseOpenCLKernelAttributes(DS.getAttributes());
   continue;
 
+// CUDA/HIP single token adornments.
+case tok::kw___noinline__:
+  ParseCUDAFunctionAttributes(DS.getAttributes());
+  continue;
+
 // Nullability type specifiers.
 case tok::kw__Nonnull:
 case tok::kw__Nullable:
Index: clang/lib/Basic/IdentifierTable.cpp
===
--- clang/lib/Basic/IdentifierTable.cpp
+++ clang/lib/Basic/IdentifierTable.cpp
@@ -108,6 +108,7 @@
 KEYOPENCLCXX  = 0x40,
 KEYMSCOMPAT   = 0x80,
 KEYSYCL   = 0x100,
+KEYCUDA   = 0x200,
 KEYALLCXX = KEYCXX | KEYCXX11 | KEYCXX20,
 KEYALL = (0x1ff & ~KEYNOMS18 &
   ~KEYNOOPENCL) // KEYNOMS18 and KEYNOOPENCL are used to exclude.
@@ -158,6 +159,8 @@
 return KS_Future;
   if 

[PATCH] D124866: [CUDA][HIP] support __noinline__ as keyword

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/test/SemaCUDA/noinline.cu:8
+__attribute__((noinline)) void fun2() { }
+__attribute__((__noinline__)) void fun3() { }

yaxunl wrote:
> aaron.ballman wrote:
> > yaxunl wrote:
> > > aaron.ballman wrote:
> > > > yaxunl wrote:
> > > > > aaron.ballman wrote:
> > > > > > yaxunl wrote:
> > > > > > > aaron.ballman wrote:
> > > > > > > > I think there should also be a test like:
> > > > > > > > ```
> > > > > > > > [[gnu::__noinline__]] void fun4() {}
> > > > > > > > ```
> > > > > > > > to verify that the double square bracket syntax also correctly 
> > > > > > > > handles this being a keyword now (I expect the test to pass).
> > > > > > > will do
> > > > > > Ah, I just noticed we also have no tests for the behavior of the 
> > > > > > keyword in the presence of the macro being defined. e.g.,
> > > > > > ```
> > > > > > #define __noinline__ __attribute__((__noinline__))
> > > > > > __noinline__ void fun5() {}
> > > > > > ```
> > > > > will do
> > > > I missed an important detail -- I think this is now going to generate a 
> > > > warning in `-pedantic` mode (through `-Wkeyword-macro`) when compiling 
> > > > for CUDA; is that going to be a problem for CUDA headers, or are those 
> > > > always included as a system header (and so the diagnostics will be 
> > > > suppressed)?
> > > I could not find how clang driver adds CUDA include path
> > > 
> > > https://github.com/llvm/llvm-project/blob/main/clang/lib/Driver/ToolChains/Cuda.cpp#L284
> > > 
> > > @tra do you know how CUDA include path is added? is it done by CMake? 
> > > 
> > > For HIP the HIP include path is added as a system include path by clang 
> > > driver.
> > Whatever we find out, we can emulate its behavior here in the test file to 
> > see what the diagnostic behavior will be (you can use GNU linemarkers to 
> > convince the compiler parts of the source are in a system header).
> will add tests for that.
> 
> It seems no matter it is system header or normal header, no warnings are 
> emitted even with -pedantic.
Excellent, thank you!


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

https://reviews.llvm.org/D124866

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

[PATCH] D124866: [CUDA][HIP] support __noinline__ as keyword

[Yaxun Liu via Phabricator via cfe-commits]

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



Comment at: clang/test/SemaCUDA/noinline.cu:8
+__attribute__((noinline)) void fun2() { }
+__attribute__((__noinline__)) void fun3() { }

aaron.ballman wrote:
> yaxunl wrote:
> > aaron.ballman wrote:
> > > yaxunl wrote:
> > > > aaron.ballman wrote:
> > > > > yaxunl wrote:
> > > > > > aaron.ballman wrote:
> > > > > > > I think there should also be a test like:
> > > > > > > ```
> > > > > > > [[gnu::__noinline__]] void fun4() {}
> > > > > > > ```
> > > > > > > to verify that the double square bracket syntax also correctly 
> > > > > > > handles this being a keyword now (I expect the test to pass).
> > > > > > will do
> > > > > Ah, I just noticed we also have no tests for the behavior of the 
> > > > > keyword in the presence of the macro being defined. e.g.,
> > > > > ```
> > > > > #define __noinline__ __attribute__((__noinline__))
> > > > > __noinline__ void fun5() {}
> > > > > ```
> > > > will do
> > > I missed an important detail -- I think this is now going to generate a 
> > > warning in `-pedantic` mode (through `-Wkeyword-macro`) when compiling 
> > > for CUDA; is that going to be a problem for CUDA headers, or are those 
> > > always included as a system header (and so the diagnostics will be 
> > > suppressed)?
> > I could not find how clang driver adds CUDA include path
> > 
> > https://github.com/llvm/llvm-project/blob/main/clang/lib/Driver/ToolChains/Cuda.cpp#L284
> > 
> > @tra do you know how CUDA include path is added? is it done by CMake? 
> > 
> > For HIP the HIP include path is added as a system include path by clang 
> > driver.
> Whatever we find out, we can emulate its behavior here in the test file to 
> see what the diagnostic behavior will be (you can use GNU linemarkers to 
> convince the compiler parts of the source are in a system header).
will add tests for that.

It seems no matter it is system header or normal header, no warnings are 
emitted even with -pedantic.


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

https://reviews.llvm.org/D124866

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

[PATCH] D124534: [clang] Add a diagnostic for line directive of a gnu extension

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/test/Preprocessor/line-directive-system-headers.c:1-2
+// RUN: %clang_cc1 -std=c99 -fsyntax-only -pedantic -verify %s
+// RUN: %clang_cc1 -std=c99 -fsyntax-only -pedantic -verify=system 
-Wsystem-headers %s
+

There's nothing specific to C99 that I can see in the test, so I think these 
can be dropped.



Comment at: clang/test/Preprocessor/line-directive-system-headers.c:19-21
+# 42 "foo" 2 3 4
+// expected-error@-1 {{invalid line marker flag '2': cannot pop empty include 
stack}}
+// system-error@-2 {{invalid line marker flag '2': cannot pop empty include 
stack}}

Might as well make this consistent with the other parts of the test and use 
`@#6` instead of `@-1`. Same applies elsewhere.



Comment at: clang/test/Preprocessor/line-directive-system-headers.c:40-50
+// no expected warning.
+// system-warning@#8 {{this style of line directive is a GNU extension}}
+typedef int y;
+// no expected warning.
+// system-note@-2 {{previous definition is here}}
+typedef int y;
+// no expected warning.

Let's change "no expected warning" into "Warnings silenced when 
-Wsystem-headers isn't passed." so it sounds less like "we don't expect the 
warning directly below this comment to happen".


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124534

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

[PATCH] D124726: Suggest typoed directives in preprocessor conditionals

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/test/Preprocessor/suggest-typoed-directive.c:3
+
+// id:   not suggested to '#if'
+// ifd:  expected-warning@+11 {{invalid preprocessing directive, did you 
mean '#if'?}}

erichkeane wrote:
> aaron.ballman wrote:
> > This still suggests that something's wrong as I would imagine this would 
> > have an edit distance of 1. Oh, interesting... setting the replacement 
> > option to `false` may have made things better for the `elfindef` case but 
> > worse for the `id` case?
> > 
> > This is tricky because we want to identify things that are most likely 
> > simple typos but exclude things that may reasonably not be a typo but a 
> > custom preprocessor directive. Based on that, I *think* setting the 
> > replacement option to `true` gives the more conservative answer (it treats 
> > a replacement as 1 edit rather than 2). @erichkeane -- do you have thoughts?
> Not particularly.  I don't have a good hold of how much we want to suggest 
> with the 'did you mean'.  Line 9 and line 10 here are unfortunate, I would 
> hope those would happen?  Its unfortunate we don't have a way to figure out 
> these common typos.
Yeah, ideally I want this to "do what I'm thinking" and make all three 
situations work. :-D



Comment at: clang/test/Preprocessor/suggest-typoed-directive.c:10
+// expected-warning@+11 {{'#elfidef' directive not found, did you mean 
'#elifdef'?}}
+// expected-warning@+11 {{'#elfindef' directive not found, did you mean 
'#elifdef'?}}
+// expected-warning@+11 {{'#elsi' directive not found, did you mean '#else'?}}

erichkeane wrote:
> aaron.ballman wrote:
> > ken-matsui wrote:
> > > aaron.ballman wrote:
> > > > ken-matsui wrote:
> > > > > aaron.ballman wrote:
> > > > > > ken-matsui wrote:
> > > > > > > aaron.ballman wrote:
> > > > > > > > It's interesting that this one suggested `#elifdef` instead of 
> > > > > > > > `#elifndef` -- is there anything that can be done for that?
> > > > > > > > 
> > > > > > > > Also, one somewhat interesting question is whether we want to 
> > > > > > > > recommend `#elifdef` and `#elifndef` outside of C2x/C++2b mode. 
> > > > > > > > Those directives only exist in the latest language standard, 
> > > > > > > > but Clang supports them as a conforming extension in all 
> > > > > > > > language modes. Given that this diagnostic is about typos, I 
> > > > > > > > think I'm okay suggesting the directives even in older language 
> > > > > > > > modes. That's as likely to be a correct suggestion as not, IMO.
> > > > > > > > It's interesting that this one suggested `#elifdef` instead of 
> > > > > > > > `#elifndef` -- is there anything that can be done for that?
> > > > > > > 
> > > > > > > I found I have to use `std::min_element` instead of 
> > > > > > > `std::max_element` because we are finding the nearest (most 
> > > > > > > minimum distance) string. Meanwhile, `#elfindef` has 2 distance 
> > > > > > > with both `#elifdef` and `#elifndef`. After replacing 
> > > > > > > `std::max_element` with `std::min_element`, I could suggest 
> > > > > > > `#elifndef` from `#elfinndef`.
> > > > > > > 
> > > > > > > > Also, one somewhat interesting question is whether we want to 
> > > > > > > > recommend `#elifdef` and `#elifndef` outside of C2x/C++2b mode. 
> > > > > > > > Those directives only exist in the latest language standard, 
> > > > > > > > but Clang supports them as a conforming extension in all 
> > > > > > > > language modes. Given that this diagnostic is about typos, I 
> > > > > > > > think I'm okay suggesting the directives even in older language 
> > > > > > > > modes. That's as likely to be a correct suggestion as not, IMO.
> > > > > > > 
> > > > > > > I agree with you because Clang implements those directives, and 
> > > > > > > the suggested code will also be compilable. I personally think 
> > > > > > > only not compilable suggestions should be avoided. (Or, we might 
> > > > > > > place additional info for outside of C2x/C++2b mode like `this is 
> > > > > > > a C2x/C++2b feature but compilable on Clang`?)
> > > > > > > 
> > > > > > > ---
> > > > > > > 
> > > > > > > According to the algorithm of `std::min_element`, we only get an 
> > > > > > > iterator of the first element even if there is another element 
> > > > > > > that has the same distance. So, `#elfindef` only suggests 
> > > > > > > `#elifdef` in accordance with the order of `Candidates`, and I 
> > > > > > > don't think it is beautiful to depend on the order of candidates. 
> > > > > > > I would say that we can suggest all the same distance like the 
> > > > > > > following, but I'm not sure this is preferable:
> > > > > > > 
> > > > > > > ```
> > > > > > > #elfindef // diag: unknown directive, did you mean #elifdef or 
> > > > > > > #elifndef?
> > > > > > > ```
> > > > > > > 
> > > > > > > I agree with you because Clang implements those directives, and 
> > > > > > > the 

[PATCH] D125228: [clangd] Support for standard inlayHint protocol

[Kadir Cetinkaya via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG3137ca80b9ef: [clangd] Support for standard inlayHint 
protocol (authored by kadircet).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125228

Files:
  clang-tools-extra/clangd/ClangdLSPServer.cpp
  clang-tools-extra/clangd/ClangdLSPServer.h
  clang-tools-extra/clangd/InlayHints.cpp
  clang-tools-extra/clangd/Protocol.cpp
  clang-tools-extra/clangd/Protocol.h
  clang-tools-extra/clangd/test/initialize-params.test
  clang-tools-extra/clangd/test/inlayHints.test
  clang-tools-extra/clangd/unittests/InlayHintTests.cpp

Index: clang-tools-extra/clangd/unittests/InlayHintTests.cpp
===
--- clang-tools-extra/clangd/unittests/InlayHintTests.cpp
+++ clang-tools-extra/clangd/unittests/InlayHintTests.cpp
@@ -13,6 +13,7 @@
 #include "TestWorkspace.h"
 #include "XRefs.h"
 #include "support/Context.h"
+#include "llvm/ADT/StringRef.h"
 #include "llvm/Support/ScopedPrinter.h"
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
@@ -53,8 +54,11 @@
 };
 
 MATCHER_P2(HintMatcher, Expected, Code, llvm::to_string(Expected)) {
-  if (arg.label != Expected.Label) {
-*result_listener << "label is " << arg.label;
+  llvm::StringRef ExpectedView(Expected.Label);
+  if (arg.label != ExpectedView.trim(" ") ||
+  arg.paddingLeft != ExpectedView.startswith(" ") ||
+  arg.paddingRight != ExpectedView.endswith(" ")) {
+*result_listener << "label is '" << arg.label << "'";
 return false;
   }
   if (arg.range != Code.range(Expected.RangeName)) {
@@ -99,14 +103,14 @@
 void assertParameterHints(llvm::StringRef AnnotatedSource,
   ExpectedHints... Expected) {
   ignore(Expected.Side = Left...);
-  assertHints(InlayHintKind::ParameterHint, AnnotatedSource, Expected...);
+  assertHints(InlayHintKind::Parameter, AnnotatedSource, Expected...);
 }
 
 template 
 void assertTypeHints(llvm::StringRef AnnotatedSource,
  ExpectedHints... Expected) {
   ignore(Expected.Side = Right...);
-  assertHints(InlayHintKind::TypeHint, AnnotatedSource, Expected...);
+  assertHints(InlayHintKind::Type, AnnotatedSource, Expected...);
 }
 
 template 
@@ -115,7 +119,7 @@
   Config Cfg;
   Cfg.InlayHints.Designators = true;
   WithContextValue WithCfg(Config::Key, std::move(Cfg));
-  assertHints(InlayHintKind::DesignatorHint, AnnotatedSource, Expected...);
+  assertHints(InlayHintKind::Designator, AnnotatedSource, Expected...);
 }
 
 TEST(ParameterHints, Smoke) {
@@ -570,7 +574,7 @@
   ASSERT_TRUE(bool(AST));
 
   // Ensure the hint for the call in foo.inc is NOT materialized in foo.cc.
-  EXPECT_EQ(hintsOfKind(*AST, InlayHintKind::ParameterHint).size(), 0u);
+  EXPECT_EQ(hintsOfKind(*AST, InlayHintKind::Parameter).size(), 0u);
 }
 
 TEST(TypeHints, Smoke) {
@@ -818,7 +822,7 @@
   TU.ExtraArgs.push_back("-xc");
   auto AST = TU.build();
 
-  EXPECT_THAT(hintsOfKind(AST, InlayHintKind::TypeHint), IsEmpty());
+  EXPECT_THAT(hintsOfKind(AST, InlayHintKind::Type), IsEmpty());
 }
 
 TEST(DesignatorHints, Basic) {
Index: clang-tools-extra/clangd/test/inlayHints.test
===
--- clang-tools-extra/clangd/test/inlayHints.test
+++ clang-tools-extra/clangd/test/inlayHints.test
@@ -39,6 +39,29 @@
 # CHECK-NEXT:  ]
 # CHECK-NEXT:}
 ---
+{"jsonrpc":"2.0","id":2,"method":"textDocument/inlayHint","params":{
+  "textDocument":{"uri":"test:///main.cpp"},
+  "range":{
+"start": {"line":1,"character":0},
+"end": {"line":2,"character":0}
+  }
+}}
+#  CHECK:  "id": 2,
+# CHECK-NEXT:  "jsonrpc": "2.0",
+# CHECK-NEXT:  "result": [
+# CHECK-NEXT:{
+# CHECK-NEXT:  "kind": 2,
+# CHECK-NEXT:  "label": "bar:",
+# CHECK-NEXT:  "paddingLeft": false,
+# CHECK-NEXT:  "paddingRight": true,
+# CHECK-NEXT:  "position": {
+# CHECK-NEXT:"character": 12,
+# CHECK-NEXT:"line": 1
+# CHECK-NEXT:  }
+# CHECK-NEXT:}
+# CHECK-NEXT:  ]
+# CHECK-NEXT:}
+---
 {"jsonrpc":"2.0","id":100,"method":"shutdown"}
 ---
 {"jsonrpc":"2.0","method":"exit"}
Index: clang-tools-extra/clangd/test/initialize-params.test
===
--- clang-tools-extra/clangd/test/initialize-params.test
+++ clang-tools-extra/clangd/test/initialize-params.test
@@ -74,6 +74,7 @@
 # CHECK-NEXT:  },
 # CHECK-NEXT:  "hoverProvider": true,
 # CHECK-NEXT:  "implementationProvider": true,
+# CHECK-NEXT:  "inlayHintProvider": true,
 # CHECK-NEXT:  "memoryUsageProvider": true,
 # CHECK-NEXT:  "referencesProvider": true,
 # CHECK-NEXT:  "renameProvider": true,
Index: clang-tools-extra/clangd/Protocol.h
===
--- 

[clang-tools-extra] 3137ca8 - [clangd] Support for standard inlayHint protocol

[Kadir Cetinkaya via cfe-commits]

Author: Kadir Cetinkaya
Date: 2022-05-10T18:59:15+02:00
New Revision: 3137ca80b9ef99359a4adf77512925c2edc461b9

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

LOG: [clangd] Support for standard inlayHint protocol

- Make clangd's internal representation more aligned with the standard.
  We keep range and extra inlayhint kinds around, but don't serialize
  them on standard version.
- Have custom serialization for extension (ugly, but going to go away).
- Support both versions until clangd-17.
- Don't advertise extension if client has support for standard
  implementation.
- Log a warning at startup about extension being deprecated, if client
  doesn't have support.

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

Added: 


Modified: 
clang-tools-extra/clangd/ClangdLSPServer.cpp
clang-tools-extra/clangd/ClangdLSPServer.h
clang-tools-extra/clangd/InlayHints.cpp
clang-tools-extra/clangd/Protocol.cpp
clang-tools-extra/clangd/Protocol.h
clang-tools-extra/clangd/test/initialize-params.test
clang-tools-extra/clangd/test/inlayHints.test
clang-tools-extra/clangd/unittests/InlayHintTests.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/ClangdLSPServer.cpp 
b/clang-tools-extra/clangd/ClangdLSPServer.cpp
index 9b826bb373159..49c882e6c8d4b 100644
--- a/clang-tools-extra/clangd/ClangdLSPServer.cpp
+++ b/clang-tools-extra/clangd/ClangdLSPServer.cpp
@@ -29,6 +29,7 @@
 #include "llvm/ADT/Optional.h"
 #include "llvm/ADT/ScopeExit.h"
 #include "llvm/ADT/StringRef.h"
+#include "llvm/ADT/Twine.h"
 #include "llvm/Support/Allocator.h"
 #include "llvm/Support/Error.h"
 #include "llvm/Support/FormatVariadic.h"
@@ -574,6 +575,7 @@ void ClangdLSPServer::onInitialize(const InitializeParams 
,
llvm::json::Object{{"automaticReload", true}}},
   {"callHierarchyProvider", true},
   {"clangdInlayHintsProvider", true},
+  {"inlayHintProvider", true},
   };
 
   {
@@ -1207,8 +1209,41 @@ void ClangdLSPServer::onCallHierarchyIncomingCalls(
   Server->incomingCalls(Params.item, std::move(Reply));
 }
 
-void ClangdLSPServer::onInlayHints(const InlayHintsParams ,
-   Callback> Reply) {
+void ClangdLSPServer::onClangdInlayHints(const InlayHintsParams ,
+ Callback Reply) {
+  // Our extension has a 
diff erent representation on the wire than the standard.
+  // We have a "range" property and "kind" is represented as a string, not as 
an
+  // enum value.
+  // https://clangd.llvm.org/extensions#inlay-hints
+  auto Serialize = [Reply = std::move(Reply)](
+   llvm::Expected> Hints) mutable {
+if (!Hints) {
+  Reply(Hints.takeError());
+  return;
+}
+llvm::json::Array Result;
+Result.reserve(Hints->size());
+for (auto  : *Hints) {
+  Result.emplace_back(llvm::json::Object{
+  {"kind", llvm::to_string(Hint.kind)},
+  {"range", Hint.range},
+  {"position", Hint.position},
+  // Extension doesn't have paddingLeft/Right so adjust the label
+  // accordingly.
+  {"label",
+   ((Hint.paddingLeft ? " " : "") + llvm::StringRef(Hint.label) +
+(Hint.paddingRight ? " " : ""))
+   .str()},
+  });
+}
+Reply(std::move(Result));
+  };
+  Server->inlayHints(Params.textDocument.uri.file(), Params.range,
+ std::move(Serialize));
+}
+
+void ClangdLSPServer::onInlayHint(const InlayHintsParams ,
+  Callback> Reply) {
   Server->inlayHints(Params.textDocument.uri.file(), Params.range,
  std::move(Reply));
 }
@@ -1491,7 +1526,8 @@ void ClangdLSPServer::bindMethods(LSPBinder ,
   Bind.method("textDocument/documentLink", this, 
::onDocumentLink);
   Bind.method("textDocument/semanticTokens/full", this, 
::onSemanticTokens);
   Bind.method("textDocument/semanticTokens/full/delta", this, 
::onSemanticTokensDelta);
-  Bind.method("clangd/inlayHints", this, ::onInlayHints);
+  Bind.method("clangd/inlayHints", this, ::onClangdInlayHints);
+  Bind.method("textDocument/inlayHint", this, ::onInlayHint);
   Bind.method("$/memoryUsage", this, ::onMemoryUsage);
   if (Opts.FoldingRanges)
 Bind.method("textDocument/foldingRange", this, 
::onFoldingRange);

diff  --git a/clang-tools-extra/clangd/ClangdLSPServer.h 
b/clang-tools-extra/clangd/ClangdLSPServer.h
index 1c52ebfe97c92..562f8e060161f 100644
--- a/clang-tools-extra/clangd/ClangdLSPServer.h
+++ b/clang-tools-extra/clangd/ClangdLSPServer.h
@@ -144,7 +144,9 @@ class ClangdLSPServer : private ClangdServer::Callbacks,
   void onCallHierarchyOutgoingCalls(
   const CallHierarchyOutgoingCallsParams &,
   Callback>);
-  void onInlayHints(const 

[PATCH] D125269: [OpenMP] Add mangling support for linear modifiers (ref, uval, val)

[Mike Rice 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 rG1a02519bc504: [OpenMP] Add mangling support for linear 
modifiers (ref,uval,val) (authored by mikerice).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Changed prior to commit:
  https://reviews.llvm.org/D125269?vs=428200=428416#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125269

Files:
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/test/OpenMP/declare_simd_codegen.cpp

Index: clang/test/OpenMP/declare_simd_codegen.cpp
===
--- clang/test/OpenMP/declare_simd_codegen.cpp
+++ clang/test/OpenMP/declare_simd_codegen.cpp
@@ -117,6 +117,33 @@
 #pragma omp declare simd notinbranch linear(i)
 double constlinear(const int i) { return 0.0; }
 
+// Test linear modifiers
+// linear(x) cases
+#pragma omp declare simd simdlen(4) linear(a:2) linear(b:4) linear(c:8) \
+linear(d,e,f)
+double One(int , int *b, int c, int , int *e, int f) {
+  return a + *b + c;
+}
+
+// linear(val(x)) cases
+#pragma omp declare simd simdlen(4) linear(val(a):2) linear(val(b):4) \
+linear(val(c):8) linear(val(d,e,f))
+double Two(int , int *b, int c, int , int *e, int f) {
+  return a + *b + c;
+}
+
+// linear(uval(x) case
+#pragma omp declare simd simdlen(4) linear(uval(a):2) linear(uval(b))
+double Three(int , int ) {
+  return a;
+}
+
+// linear(ref(x) case
+#pragma omp declare simd simdlen(4) linear(ref(a):2) linear(ref(b))
+double Four(int& a, int ) {
+  return a;
+}
+
 // CHECK-DAG: define {{.+}}@_Z5add_1Pf(
 // CHECK-DAG: define {{.+}}@_Z1hIiEvPT_S1_S1_S1_(
 // CHECK-DAG: define {{.+}}@_Z1hIfEvPT_S1_S1_S1_(
@@ -188,32 +215,32 @@
 // CHECK-DAG: "_ZGVeM8va16va16vv__Z1hIfEvPT_S1_S1_S1_"
 // CHECK-DAG: "_ZGVeN8va16va16vv__Z1hIfEvPT_S1_S1_S1_"
 
-// CHECK-DAG: "_ZGVbM4uus1__ZN2VV3addEii"
-// CHECK-DAG: "_ZGVbN4uus1__ZN2VV3addEii"
-// CHECK-DAG: "_ZGVcM8uus1__ZN2VV3addEii"
-// CHECK-DAG: "_ZGVcN8uus1__ZN2VV3addEii"
-// CHECK-DAG: "_ZGVdM8uus1__ZN2VV3addEii"
-// CHECK-DAG: "_ZGVdN8uus1__ZN2VV3addEii"
-// CHECK-DAG: "_ZGVeM16uus1__ZN2VV3addEii"
-// CHECK-DAG: "_ZGVeN16uus1__ZN2VV3addEii"
-
-// CHECK-DAG: "_ZGVbM4ll4a16l4a4__ZN2VV6taddpfEPfRS0_"
-// CHECK-DAG: "_ZGVbN4ll4a16l4a4__ZN2VV6taddpfEPfRS0_"
-// CHECK-DAG: "_ZGVcM8ll4a16l4a4__ZN2VV6taddpfEPfRS0_"
-// CHECK-DAG: "_ZGVcN8ll4a16l4a4__ZN2VV6taddpfEPfRS0_"
-// CHECK-DAG: "_ZGVdM8ll4a16l4a4__ZN2VV6taddpfEPfRS0_"
-// CHECK-DAG: "_ZGVdN8ll4a16l4a4__ZN2VV6taddpfEPfRS0_"
-// CHECK-DAG: "_ZGVeM16ll4a16l4a4__ZN2VV6taddpfEPfRS0_"
-// CHECK-DAG: "_ZGVeN16ll4a16l4a4__ZN2VV6taddpfEPfRS0_"
-
-// CHECK-DAG: "_ZGVbM4vvl8__ZN2VV4taddERA_iRi"
-// CHECK-DAG: "_ZGVbN4vvl8__ZN2VV4taddERA_iRi"
-// CHECK-DAG: "_ZGVcM8vvl8__ZN2VV4taddERA_iRi"
-// CHECK-DAG: "_ZGVcN8vvl8__ZN2VV4taddERA_iRi"
-// CHECK-DAG: "_ZGVdM8vvl8__ZN2VV4taddERA_iRi"
-// CHECK-DAG: "_ZGVdN8vvl8__ZN2VV4taddERA_iRi"
-// CHECK-DAG: "_ZGVeM16vvl8__ZN2VV4taddERA_iRi"
-// CHECK-DAG: "_ZGVeN16vvl8__ZN2VV4taddERA_iRi"
+// CHECK-DAG: "_ZGVbM4uuls1__ZN2VV3addEii"
+// CHECK-DAG: "_ZGVbN4uuls1__ZN2VV3addEii"
+// CHECK-DAG: "_ZGVcM8uuls1__ZN2VV3addEii"
+// CHECK-DAG: "_ZGVcN8uuls1__ZN2VV3addEii"
+// CHECK-DAG: "_ZGVdM8uuls1__ZN2VV3addEii"
+// CHECK-DAG: "_ZGVdN8uuls1__ZN2VV3addEii"
+// CHECK-DAG: "_ZGVeM16uuls1__ZN2VV3addEii"
+// CHECK-DAG: "_ZGVeN16uuls1__ZN2VV3addEii"
+
+// CHECK-DAG: "_ZGVbM4l40l4a16R32a4__ZN2VV6taddpfEPfRS0_"
+// CHECK-DAG: "_ZGVbN4l40l4a16R32a4__ZN2VV6taddpfEPfRS0_"
+// CHECK-DAG: "_ZGVcM8l40l4a16R32a4__ZN2VV6taddpfEPfRS0_"
+// CHECK-DAG: "_ZGVcN8l40l4a16R32a4__ZN2VV6taddpfEPfRS0_"
+// CHECK-DAG: "_ZGVdM8l40l4a16R32a4__ZN2VV6taddpfEPfRS0_"
+// CHECK-DAG: "_ZGVdN8l40l4a16R32a4__ZN2VV6taddpfEPfRS0_"
+// CHECK-DAG: "_ZGVeM16l40l4a16R32a4__ZN2VV6taddpfEPfRS0_"
+// CHECK-DAG: "_ZGVeN16l40l4a16R32a4__ZN2VV6taddpfEPfRS0_"
+
+// CHECK-DAG: "_ZGVbM4vvU8__ZN2VV4taddERA_iRi"
+// CHECK-DAG: "_ZGVbN4vvU8__ZN2VV4taddERA_iRi"
+// CHECK-DAG: "_ZGVcM8vvU8__ZN2VV4taddERA_iRi"
+// CHECK-DAG: "_ZGVcN8vvU8__ZN2VV4taddERA_iRi"
+// CHECK-DAG: "_ZGVdM8vvU8__ZN2VV4taddERA_iRi"
+// CHECK-DAG: "_ZGVdN8vvU8__ZN2VV4taddERA_iRi"
+// CHECK-DAG: "_ZGVeM16vvU8__ZN2VV4taddERA_iRi"
+// CHECK-DAG: "_ZGVeN16vvU8__ZN2VV4taddERA_iRi"
 // CHECK-DAG: "_ZGVbM4vva8v__ZN2VV4taddERA_iRi"
 // CHECK-DAG: "_ZGVbN4vva8v__ZN2VV4taddERA_iRi"
 // CHECK-DAG: "_ZGVcM8vva8v__ZN2VV4taddERA_iRi"
@@ -223,14 +250,14 @@
 // CHECK-DAG: "_ZGVeM16vva8v__ZN2VV4taddERA_iRi"
 // CHECK-DAG: "_ZGVeN16vva8v__ZN2VV4taddERA_iRi"
 
-// CHECK-DAG: "_ZGVbM4vva32l16a16__ZN3TVVILi16EfE6taddpfEPfRS1_"
-// CHECK-DAG: "_ZGVbN4vva32l16a16__ZN3TVVILi16EfE6taddpfEPfRS1_"
-// CHECK-DAG: "_ZGVcM8vva32l16a16__ZN3TVVILi16EfE6taddpfEPfRS1_"
-// CHECK-DAG: "_ZGVcN8vva32l16a16__ZN3TVVILi16EfE6taddpfEPfRS1_"
-// CHECK-DAG: 

[clang] 1a02519 - [OpenMP] Add mangling support for linear modifiers (ref,uval,val)

[Mike Rice via cfe-commits]

Author: Mike Rice
Date: 2022-05-10T09:56:55-07:00
New Revision: 1a02519bc504a12a12ba875db29c9e5901ed9bef

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

LOG: [OpenMP] Add mangling support for linear modifiers (ref,uval,val)

Add mangling for linear parameters specified with ref, uval, and val
for 'omp declare simd' vector functions.

Add missing stride for linear this parameters.

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

Added: 


Modified: 
clang/lib/CodeGen/CGOpenMPRuntime.cpp
clang/test/OpenMP/declare_simd_codegen.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGOpenMPRuntime.cpp 
b/clang/lib/CodeGen/CGOpenMPRuntime.cpp
index aa8aa7d0bd5f8..d938bda157f9d 100644
--- a/clang/lib/CodeGen/CGOpenMPRuntime.cpp
+++ b/clang/lib/CodeGen/CGOpenMPRuntime.cpp
@@ -11404,13 +11404,21 @@ void CGOpenMPRuntime::emitTargetDataStandAloneCall(
 
 namespace {
   /// Kind of parameter in a function with 'declare simd' directive.
-  enum ParamKindTy { LinearWithVarStride, Linear, Uniform, Vector };
-  /// Attribute set of the parameter.
-  struct ParamAttrTy {
-ParamKindTy Kind = Vector;
-llvm::APSInt StrideOrArg;
-llvm::APSInt Alignment;
-  };
+enum ParamKindTy {
+  LinearWithVarStride,
+  Linear,
+  LinearRef,
+  LinearUVal,
+  LinearVal,
+  Uniform,
+  Vector,
+};
+/// Attribute set of the parameter.
+struct ParamAttrTy {
+  ParamKindTy Kind = Vector;
+  llvm::APSInt StrideOrArg;
+  llvm::APSInt Alignment;
+};
 } // namespace
 
 static unsigned evaluateCDTSize(const FunctionDecl *FD,
@@ -11465,6 +11473,51 @@ static unsigned evaluateCDTSize(const FunctionDecl *FD,
   return C.getTypeSize(CDT);
 }
 
+/// Mangle the parameter part of the vector function name according to
+/// their OpenMP classification. The mangling function is defined in
+/// section 4.5 of the AAVFABI(2021Q1).
+static std::string mangleVectorParameters(ArrayRef ParamAttrs) {
+  SmallString<256> Buffer;
+  llvm::raw_svector_ostream Out(Buffer);
+  for (const auto  : ParamAttrs) {
+switch (ParamAttr.Kind) {
+case LinearWithVarStride:
+  Out << "ls" << ParamAttr.StrideOrArg;
+  break;
+case Linear:
+  Out << 'l';
+  break;
+case LinearRef:
+  Out << 'R';
+  break;
+case LinearUVal:
+  Out << 'U';
+  break;
+case LinearVal:
+  Out << 'L';
+  break;
+case Uniform:
+  Out << 'u';
+  break;
+case Vector:
+  Out << 'v';
+  break;
+}
+if (ParamAttr.Kind == Linear || ParamAttr.Kind == LinearRef ||
+ParamAttr.Kind == LinearUVal || ParamAttr.Kind == LinearVal) {
+  // Don't print the step value if it is not present or if it is
+  // equal to 1.
+  if (ParamAttr.StrideOrArg != 1)
+Out << ParamAttr.StrideOrArg;
+}
+
+if (!!ParamAttr.Alignment)
+  Out << 'a' << ParamAttr.Alignment;
+  }
+
+  return std::string(Out.str());
+}
+
 static void
 emitX86DeclareSimdFunction(const FunctionDecl *FD, llvm::Function *Fn,
const llvm::APSInt ,
@@ -11513,26 +11566,7 @@ emitX86DeclareSimdFunction(const FunctionDecl *FD, 
llvm::Function *Fn,
   } else {
 Out << VLENVal;
   }
-  for (const ParamAttrTy  : ParamAttrs) {
-switch (ParamAttr.Kind){
-case LinearWithVarStride:
-  Out << 's' << ParamAttr.StrideOrArg;
-  break;
-case Linear:
-  Out << 'l';
-  if (ParamAttr.StrideOrArg != 1)
-Out << ParamAttr.StrideOrArg;
-  break;
-case Uniform:
-  Out << 'u';
-  break;
-case Vector:
-  Out << 'v';
-  break;
-}
-if (!!ParamAttr.Alignment)
-  Out << 'a' << ParamAttr.Alignment;
-  }
+  Out << mangleVectorParameters(ParamAttrs);
   Out << '_' << Fn->getName();
   Fn->addFnAttr(Out.str());
 }
@@ -11645,39 +11679,6 @@ getNDSWDS(const FunctionDecl *FD, 
ArrayRef ParamAttrs) {
  OutputBecomesInput);
 }
 
-/// Mangle the parameter part of the vector function name according to
-/// their OpenMP classification. The mangling function is defined in
-/// section 3.5 of the AAVFABI.
-static std::string mangleVectorParameters(ArrayRef ParamAttrs) {
-  SmallString<256> Buffer;
-  llvm::raw_svector_ostream Out(Buffer);
-  for (const auto  : ParamAttrs) {
-switch (ParamAttr.Kind) {
-case LinearWithVarStride:
-  Out << "ls" << ParamAttr.StrideOrArg;
-  break;
-case Linear:
-  Out << 'l';
-  // Don't print the step value if it is not present or if it is
-  // equal to 1.
-  if (ParamAttr.StrideOrArg != 1)
-Out << ParamAttr.StrideOrArg;
-  break;
-case Uniform:
-  Out << 'u';
-  break;
-case Vector:
-  Out << 'v';

[PATCH] D125078: Implement a feature to show line numbers in diagnostics

[Ken Matsui via Phabricator via cfe-commits]

ken-matsui added a comment.

Thank you :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125078

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

[PATCH] D125228: [clangd] Support for standard inlayHint protocol

[Kadir Cetinkaya via Phabricator via cfe-commits]

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

- Default initialize paddingLeft/Right
- Don't serialize kind when its null
- Run in vscode, seems to be working.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125228

Files:
  clang-tools-extra/clangd/ClangdLSPServer.cpp
  clang-tools-extra/clangd/ClangdLSPServer.h
  clang-tools-extra/clangd/InlayHints.cpp
  clang-tools-extra/clangd/Protocol.cpp
  clang-tools-extra/clangd/Protocol.h
  clang-tools-extra/clangd/test/initialize-params.test
  clang-tools-extra/clangd/test/inlayHints.test
  clang-tools-extra/clangd/unittests/InlayHintTests.cpp

Index: clang-tools-extra/clangd/unittests/InlayHintTests.cpp
===
--- clang-tools-extra/clangd/unittests/InlayHintTests.cpp
+++ clang-tools-extra/clangd/unittests/InlayHintTests.cpp
@@ -13,6 +13,7 @@
 #include "TestWorkspace.h"
 #include "XRefs.h"
 #include "support/Context.h"
+#include "llvm/ADT/StringRef.h"
 #include "llvm/Support/ScopedPrinter.h"
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
@@ -53,8 +54,11 @@
 };
 
 MATCHER_P2(HintMatcher, Expected, Code, llvm::to_string(Expected)) {
-  if (arg.label != Expected.Label) {
-*result_listener << "label is " << arg.label;
+  llvm::StringRef ExpectedView(Expected.Label);
+  if (arg.label != ExpectedView.trim(" ") ||
+  arg.paddingLeft != ExpectedView.startswith(" ") ||
+  arg.paddingRight != ExpectedView.endswith(" ")) {
+*result_listener << "label is '" << arg.label << "'";
 return false;
   }
   if (arg.range != Code.range(Expected.RangeName)) {
@@ -99,14 +103,14 @@
 void assertParameterHints(llvm::StringRef AnnotatedSource,
   ExpectedHints... Expected) {
   ignore(Expected.Side = Left...);
-  assertHints(InlayHintKind::ParameterHint, AnnotatedSource, Expected...);
+  assertHints(InlayHintKind::Parameter, AnnotatedSource, Expected...);
 }
 
 template 
 void assertTypeHints(llvm::StringRef AnnotatedSource,
  ExpectedHints... Expected) {
   ignore(Expected.Side = Right...);
-  assertHints(InlayHintKind::TypeHint, AnnotatedSource, Expected...);
+  assertHints(InlayHintKind::Type, AnnotatedSource, Expected...);
 }
 
 template 
@@ -115,7 +119,7 @@
   Config Cfg;
   Cfg.InlayHints.Designators = true;
   WithContextValue WithCfg(Config::Key, std::move(Cfg));
-  assertHints(InlayHintKind::DesignatorHint, AnnotatedSource, Expected...);
+  assertHints(InlayHintKind::Designator, AnnotatedSource, Expected...);
 }
 
 TEST(ParameterHints, Smoke) {
@@ -570,7 +574,7 @@
   ASSERT_TRUE(bool(AST));
 
   // Ensure the hint for the call in foo.inc is NOT materialized in foo.cc.
-  EXPECT_EQ(hintsOfKind(*AST, InlayHintKind::ParameterHint).size(), 0u);
+  EXPECT_EQ(hintsOfKind(*AST, InlayHintKind::Parameter).size(), 0u);
 }
 
 TEST(TypeHints, Smoke) {
@@ -818,7 +822,7 @@
   TU.ExtraArgs.push_back("-xc");
   auto AST = TU.build();
 
-  EXPECT_THAT(hintsOfKind(AST, InlayHintKind::TypeHint), IsEmpty());
+  EXPECT_THAT(hintsOfKind(AST, InlayHintKind::Type), IsEmpty());
 }
 
 TEST(DesignatorHints, Basic) {
Index: clang-tools-extra/clangd/test/inlayHints.test
===
--- clang-tools-extra/clangd/test/inlayHints.test
+++ clang-tools-extra/clangd/test/inlayHints.test
@@ -39,6 +39,29 @@
 # CHECK-NEXT:  ]
 # CHECK-NEXT:}
 ---
+{"jsonrpc":"2.0","id":2,"method":"textDocument/inlayHint","params":{
+  "textDocument":{"uri":"test:///main.cpp"},
+  "range":{
+"start": {"line":1,"character":0},
+"end": {"line":2,"character":0}
+  }
+}}
+#  CHECK:  "id": 2,
+# CHECK-NEXT:  "jsonrpc": "2.0",
+# CHECK-NEXT:  "result": [
+# CHECK-NEXT:{
+# CHECK-NEXT:  "kind": 2,
+# CHECK-NEXT:  "label": "bar:",
+# CHECK-NEXT:  "paddingLeft": false,
+# CHECK-NEXT:  "paddingRight": true,
+# CHECK-NEXT:  "position": {
+# CHECK-NEXT:"character": 12,
+# CHECK-NEXT:"line": 1
+# CHECK-NEXT:  }
+# CHECK-NEXT:}
+# CHECK-NEXT:  ]
+# CHECK-NEXT:}
+---
 {"jsonrpc":"2.0","id":100,"method":"shutdown"}
 ---
 {"jsonrpc":"2.0","method":"exit"}
Index: clang-tools-extra/clangd/test/initialize-params.test
===
--- clang-tools-extra/clangd/test/initialize-params.test
+++ clang-tools-extra/clangd/test/initialize-params.test
@@ -74,6 +74,7 @@
 # CHECK-NEXT:  },
 # CHECK-NEXT:  "hoverProvider": true,
 # CHECK-NEXT:  "implementationProvider": true,
+# CHECK-NEXT:  "inlayHintProvider": true,
 # CHECK-NEXT:  "memoryUsageProvider": true,
 # CHECK-NEXT:  "referencesProvider": true,
 # CHECK-NEXT:  "renameProvider": true,
Index: clang-tools-extra/clangd/Protocol.h
===
--- clang-tools-extra/clangd/Protocol.h
+++ clang-tools-extra/clangd/Protocol.h

[PATCH] D124702: [MSVC] Add support for pragma function

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/lib/Sema/SemaAttr.cpp:1070
+SourceLocation Loc, const llvm::SmallSetVector ) {
+  if (!CurContext->getRedeclContext()->isFileContext()) {
+Diag(Loc, diag::err_pragma_intrinsic_function_scope);

steplong wrote:
> aaron.ballman wrote:
> > steplong wrote:
> > > aaron.ballman wrote:
> > > > steplong wrote:
> > > > > aaron.ballman wrote:
> > > > > > What is `CurContext` when this gets called for your .c test file? I 
> > > > > > would have expected it to be the `TranslationUnitDecl` which should 
> > > > > > be a file context (getting the redecl context shouldn't do anything 
> > > > > > in the cases I've seen).
> > > > > It looks like it's a `FunctionDecl`
> > > > Wha? That seems rather surprising -- which function does it think the 
> > > > pragma is scoped to?
> > > > 
> > > > You might consider putting breakpoints in `PushDeclContext()` and 
> > > > `PopDeclContext()` to see what's going on (or search for other places 
> > > > where we assign to `CurContext` and break on those).
> > > This is what I see when I run it on pragma-ms-function.c:
> > > ```
> > > PUSHING TranslationUnit
> > > PUSHING Function foo1
> > > FOUND PRAGMA FUNCTION
> > > POPPING Function foo1
> > > PUSHING TranslationUnit
> > > PUSHING Function foo2
> > > FOUND PRAGMA FUNCTION
> > > POPPING Function foo2
> > > PUSHING TranslationUnit
> > > PUSHING Function foo3
> > > POPPING Function foo3
> > > PUSHING TranslationUnit
> > > ```
> > > I'm logging the swap in `PopDeclContext()` with POPPING and PUSHING and 
> > > the push in `PushDeclContext()` with just PUSHING.
> > > I'm also logging FOUND PRAGMA in the pragma handler
> > Huh. For fun, can you try changing the test to:
> > ```
> > void foo1(char *s, char *d, size_t n) {
> >   bar(s);
> >   memset(s, 0, n);
> >   memcpy(d, s, n);
> > }
> > 
> > int i; // Now there's a declaration here
> > 
> > #pragma function(strlen, memset)
> > ```
> > and see if you get different results? I'm wondering if what's happening is 
> > that the `CurContext` is being updated after we've lexed the next token 
> > from the preprocessor, which means we're still in the context of `foo1` 
> > until after we've processed the pragma due to it being a preprocessing 
> > token. It still wouldn't make much sense to me, because I think we should 
> > hit that on the `}` for `foo1()`, but it's a shot in the dark.
> It looks like you're right. The `int i` makes the pragma show up after the 
> `TranslationUnit` is pushed.
> 
> ```
> PUSHING TranslationUnit
> PUSHING Function foo1
> POPPING Function foo1
> PUSHING TranslationUnit
> FOUND PRAGMA FUNCTION
> PUSHING Function foo2
> POPPING Function foo2
> PUSHING TranslationUnit
> FOUND PRAGMA FUNCTION
> PUSHING Function foo3
> POPPING Function foo3
> PUSHING TranslationUnit
> ```
> 
> I really appreciate the review and you helping me debug this
Uh I was hoping I was wrong because I think the solution requires some 
experimentation that may or may not pan out.

The way the pragma is currently being handled is: we parse everything at 
preprocessing time (`PragmaMSFunctionHandler::HandlePragma()`) and then call 
directly into Sema (`Actions.ActOnPragmaMSFunction()`).

The way I think we may have to handle the pragma is: identify the pragma at 
preprocessing time, emit an annotated token stream, parse that token stream 
from the parser, and then call Sema from there. e.g., more like:

https://github.com/llvm/llvm-project/blob/main/clang/lib/Parse/ParsePragma.cpp#L2698
https://github.com/llvm/llvm-project/blob/main/clang/lib/Parse/Parser.cpp#L830
https://github.com/llvm/llvm-project/blob/main/clang/lib/Parse/ParsePragma.cpp#L894
 (you would call `ActOnPragmaMSFunction()` from here)

This way, the appropriate parsing contexts are all updated (hopefully)!

> I really appreciate the review and you helping me debug this

I'm very happy to help!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124702

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

[PATCH] D124726: Suggest typoed directives in preprocessor conditionals

[Erich Keane via Phabricator via cfe-commits]

erichkeane added inline comments.



Comment at: clang/test/Preprocessor/suggest-typoed-directive.c:3
+
+// id:   not suggested to '#if'
+// ifd:  expected-warning@+11 {{invalid preprocessing directive, did you 
mean '#if'?}}

aaron.ballman wrote:
> This still suggests that something's wrong as I would imagine this would have 
> an edit distance of 1. Oh, interesting... setting the replacement option to 
> `false` may have made things better for the `elfindef` case but worse for the 
> `id` case?
> 
> This is tricky because we want to identify things that are most likely simple 
> typos but exclude things that may reasonably not be a typo but a custom 
> preprocessor directive. Based on that, I *think* setting the replacement 
> option to `true` gives the more conservative answer (it treats a replacement 
> as 1 edit rather than 2). @erichkeane -- do you have thoughts?
Not particularly.  I don't have a good hold of how much we want to suggest with 
the 'did you mean'.  Line 9 and line 10 here are unfortunate, I would hope 
those would happen?  Its unfortunate we don't have a way to figure out these 
common typos.



Comment at: clang/test/Preprocessor/suggest-typoed-directive.c:10
+// expected-warning@+11 {{'#elfidef' directive not found, did you mean 
'#elifdef'?}}
+// expected-warning@+11 {{'#elfindef' directive not found, did you mean 
'#elifdef'?}}
+// expected-warning@+11 {{'#elsi' directive not found, did you mean '#else'?}}

aaron.ballman wrote:
> ken-matsui wrote:
> > aaron.ballman wrote:
> > > ken-matsui wrote:
> > > > aaron.ballman wrote:
> > > > > ken-matsui wrote:
> > > > > > aaron.ballman wrote:
> > > > > > > It's interesting that this one suggested `#elifdef` instead of 
> > > > > > > `#elifndef` -- is there anything that can be done for that?
> > > > > > > 
> > > > > > > Also, one somewhat interesting question is whether we want to 
> > > > > > > recommend `#elifdef` and `#elifndef` outside of C2x/C++2b mode. 
> > > > > > > Those directives only exist in the latest language standard, but 
> > > > > > > Clang supports them as a conforming extension in all language 
> > > > > > > modes. Given that this diagnostic is about typos, I think I'm 
> > > > > > > okay suggesting the directives even in older language modes. 
> > > > > > > That's as likely to be a correct suggestion as not, IMO.
> > > > > > > It's interesting that this one suggested `#elifdef` instead of 
> > > > > > > `#elifndef` -- is there anything that can be done for that?
> > > > > > 
> > > > > > I found I have to use `std::min_element` instead of 
> > > > > > `std::max_element` because we are finding the nearest (most minimum 
> > > > > > distance) string. Meanwhile, `#elfindef` has 2 distance with both 
> > > > > > `#elifdef` and `#elifndef`. After replacing `std::max_element` with 
> > > > > > `std::min_element`, I could suggest `#elifndef` from `#elfinndef`.
> > > > > > 
> > > > > > > Also, one somewhat interesting question is whether we want to 
> > > > > > > recommend `#elifdef` and `#elifndef` outside of C2x/C++2b mode. 
> > > > > > > Those directives only exist in the latest language standard, but 
> > > > > > > Clang supports them as a conforming extension in all language 
> > > > > > > modes. Given that this diagnostic is about typos, I think I'm 
> > > > > > > okay suggesting the directives even in older language modes. 
> > > > > > > That's as likely to be a correct suggestion as not, IMO.
> > > > > > 
> > > > > > I agree with you because Clang implements those directives, and the 
> > > > > > suggested code will also be compilable. I personally think only not 
> > > > > > compilable suggestions should be avoided. (Or, we might place 
> > > > > > additional info for outside of C2x/C++2b mode like `this is a 
> > > > > > C2x/C++2b feature but compilable on Clang`?)
> > > > > > 
> > > > > > ---
> > > > > > 
> > > > > > According to the algorithm of `std::min_element`, we only get an 
> > > > > > iterator of the first element even if there is another element that 
> > > > > > has the same distance. So, `#elfindef` only suggests `#elifdef` in 
> > > > > > accordance with the order of `Candidates`, and I don't think it is 
> > > > > > beautiful to depend on the order of candidates. I would say that we 
> > > > > > can suggest all the same distance like the following, but I'm not 
> > > > > > sure this is preferable:
> > > > > > 
> > > > > > ```
> > > > > > #elfindef // diag: unknown directive, did you mean #elifdef or 
> > > > > > #elifndef?
> > > > > > ```
> > > > > > 
> > > > > > I agree with you because Clang implements those directives, and the 
> > > > > > suggested code will also be compilable. I personally think only not 
> > > > > > compilable suggestions should be avoided. (Or, we might place 
> > > > > > additional info for outside of C2x/C++2b mode like this is a 
> > > > > > C2x/C++2b feature but compilable on Clang?)
> > > > > 
> > > > > I