[PATCH] D99556: Add support to -Wa,--version in clang

[Jian Cai via Phabricator via cfe-commits]

jcai19 added a comment.

We can probably remove the -fno-integraetd-as case.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99556

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

[PATCH] D99592: [PoC][Clang] Use TypeSize instead of uint64_t for getTypeAllocSize().

[Hsiangkai Wang via Phabricator via cfe-commits]

HsiangKai updated this revision to Diff 334590.
HsiangKai added a comment.

Address comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99592

Files:
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/CodeGen/CGRecordLayoutBuilder.cpp

Index: clang/lib/CodeGen/CGRecordLayoutBuilder.cpp
===
--- clang/lib/CodeGen/CGRecordLayoutBuilder.cpp
+++ clang/lib/CodeGen/CGRecordLayoutBuilder.cpp
@@ -159,7 +159,8 @@
 return Context.toCharUnitsFromBits(BitOffset);
   }
   CharUnits getSize(llvm::Type *Type) {
-return CharUnits::fromQuantity(DataLayout.getTypeAllocSize(Type));
+return CharUnits::fromQuantity(
+DataLayout.getTypeAllocSize(Type).getKnownMinValue());
   }
   CharUnits getAlignment(llvm::Type *Type) {
 return CharUnits::fromQuantity(DataLayout.getABITypeAlignment(Type));
@@ -929,7 +930,8 @@
   const ASTRecordLayout  = getContext().getASTRecordLayout(D);
 
   uint64_t TypeSizeInBits = getContext().toBits(Layout.getSize());
-  assert(TypeSizeInBits == getDataLayout().getTypeAllocSizeInBits(Ty) &&
+  assert(TypeSizeInBits ==
+ getDataLayout().getTypeAllocSizeInBits(Ty).getKnownMinValue() &&
  "Type size mismatch!");
 
   if (BaseTy) {
@@ -938,9 +940,10 @@
 uint64_t AlignedNonVirtualTypeSizeInBits =
   getContext().toBits(NonVirtualSize);
 
-assert(AlignedNonVirtualTypeSizeInBits ==
-   getDataLayout().getTypeAllocSizeInBits(BaseTy) &&
-   "Type size mismatch!");
+assert(
+AlignedNonVirtualTypeSizeInBits ==
+getDataLayout().getTypeAllocSizeInBits(BaseTy).getKnownMinValue() &&
+"Type size mismatch!");
   }
 
   // Verify that the LLVM and AST field offsets agree.
@@ -960,7 +963,8 @@
 // AST offset.
 if (!FD->isBitField()) {
   unsigned FieldNo = RL->getLLVMFieldNo(FD);
-  assert(AST_RL.getFieldOffset(i) == SL->getElementOffsetInBits(FieldNo) &&
+  assert(AST_RL.getFieldOffset(i) ==
+ SL->getElementOffsetInBits(FieldNo).getKnownMinSize() &&
  "Invalid field offset!");
   continue;
 }
Index: clang/lib/CodeGen/CGCall.cpp
===
--- clang/lib/CodeGen/CGCall.cpp
+++ clang/lib/CodeGen/CGCall.cpp
@@ -2848,12 +2848,13 @@
   llvm::StructType *STy = dyn_cast(ArgI.getCoerceToType());
   if (ArgI.isDirect() && ArgI.getCanBeFlattened() && STy &&
   STy->getNumElements() > 1) {
-uint64_t SrcSize = CGM.getDataLayout().getTypeAllocSize(STy);
+llvm::TypeSize SrcSize = CGM.getDataLayout().getTypeAllocSize(STy);
 llvm::Type *DstTy = Ptr.getElementType();
-uint64_t DstSize = CGM.getDataLayout().getTypeAllocSize(DstTy);
+llvm::TypeSize DstSize = CGM.getDataLayout().getTypeAllocSize(DstTy);
 
 Address AddrToStoreInto = Address::invalid();
-if (SrcSize <= DstSize) {
+assert(SrcSize.isScalable() == DstSize.isScalable());
+if (llvm::TypeSize::isKnownLE(SrcSize, DstSize)) {
   AddrToStoreInto = Builder.CreateElementBitCast(Ptr, STy);
 } else {
   AddrToStoreInto =
@@ -2878,7 +2879,7 @@
   }
 }
 
-if (SrcSize > DstSize) {
+if (llvm::TypeSize::isKnownGT(SrcSize, DstSize)) {
   Builder.CreateMemCpy(Ptr, AddrToStoreInto, DstSize);
 }
 
@@ -4915,18 +4916,18 @@
 dyn_cast(ArgInfo.getCoerceToType());
   if (STy && ArgInfo.isDirect() && ArgInfo.getCanBeFlattened()) {
 llvm::Type *SrcTy = Src.getElementType();
-uint64_t SrcSize = CGM.getDataLayout().getTypeAllocSize(SrcTy);
-uint64_t DstSize = CGM.getDataLayout().getTypeAllocSize(STy);
+llvm::TypeSize SrcSize = CGM.getDataLayout().getTypeAllocSize(SrcTy);
+llvm::TypeSize DstSize = CGM.getDataLayout().getTypeAllocSize(STy);
 
 // If the source type is smaller than the destination type of the
 // coerce-to logic, copy the source value into a temp alloca the size
 // of the destination type to allow loading all of it. The bits past
 // the source value are left undef.
-if (SrcSize < DstSize) {
+if (llvm::TypeSize::isKnownLT(SrcSize, DstSize)) {
   Address TempAlloca
 = CreateTempAlloca(STy, Src.getAlignment(),
Src.getName() + ".coerce");
-  Builder.CreateMemCpy(TempAlloca, Src, SrcSize);
+  Builder.CreateMemCpy(TempAlloca, Src, SrcSize.getFixedSize());
   Src = TempAlloca;
 } else {
   Src = Builder.CreateBitCast(Src,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] bfcd218 - [debug-info] support new tuning debugger type DBX for XCOFF DWARF

[Chen Zheng via cfe-commits]

Author: Chen Zheng
Date: 2021-04-01T00:11:30-04:00
New Revision: bfcd21876adc3498065e4da92799f613e730d475

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

LOG: [debug-info] support new tuning debugger type DBX for XCOFF DWARF

Based on this debugger type, for now, we plan to:
1: use inline string by default for XCOFF DWARF
2: generate no column info for debug line table.

Reviewed By: aprantl

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

Added: 


Modified: 
clang/docs/UsersManual.rst
clang/include/clang/Basic/CodeGenOptions.def
clang/include/clang/Driver/Options.td
clang/lib/Driver/ToolChains/AIX.h
clang/lib/Driver/ToolChains/Clang.cpp
clang/lib/Driver/ToolChains/CommonArgs.cpp
clang/test/Driver/debug-options.c
llvm/include/llvm/Target/TargetOptions.h

Removed: 




diff  --git a/clang/docs/UsersManual.rst b/clang/docs/UsersManual.rst
index 6c8d297e618fc..c7b7f580ad933 100644
--- a/clang/docs/UsersManual.rst
+++ b/clang/docs/UsersManual.rst
@@ -2573,13 +2573,12 @@ While Clang generally emits standard DWARF debug info 
(http://dwarfstd.org),
 
diff erent debuggers may know how to take advantage of 
diff erent specific DWARF
 features. You can "tune" the debug info for one of several 
diff erent debuggers.
 
-.. option:: -ggdb, -glldb, -gsce
-
-  Tune the debug info for the ``gdb``, ``lldb``, or Sony PlayStation\ |reg|
-  debugger, respectively. Each of these options implies **-g**. (Therefore, if
-  you want both **-gline-tables-only** and debugger tuning, the tuning option
-  must come first.)
+.. option:: -ggdb, -glldb, -gsce, -gdbx
 
+  Tune the debug info for the ``gdb``, ``lldb``, Sony PlayStation\ |reg|
+  debugger, or ``dbx``, respectively. Each of these options implies **-g**.
+  (Therefore, if you want both **-gline-tables-only** and debugger tuning, the
+  tuning option must come first.)
 
 Controlling LLVM IR Output
 --

diff  --git a/clang/include/clang/Basic/CodeGenOptions.def 
b/clang/include/clang/Basic/CodeGenOptions.def
index 4c354734dff87..900e61eb828b5 100644
--- a/clang/include/clang/Basic/CodeGenOptions.def
+++ b/clang/include/clang/Basic/CodeGenOptions.def
@@ -340,7 +340,7 @@ ENUM_CODEGENOPT(DebugInfo, codegenoptions::DebugInfoKind, 
4, codegenoptions::NoD
 CODEGENOPT(MacroDebugInfo, 1, 0)
 
 /// Tune the debug info for this debugger.
-ENUM_CODEGENOPT(DebuggerTuning, llvm::DebuggerKind, 2,
+ENUM_CODEGENOPT(DebuggerTuning, llvm::DebuggerKind, 3,
 llvm::DebuggerKind::Default)
 
 /// Dwarf version. Version zero indicates to LLVM that no DWARF should be

diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 8ee3ebf7f2af9..58af122993255 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -2722,6 +2722,7 @@ def ggdb2 : Flag<["-"], "ggdb2">, Group;
 def ggdb3 : Flag<["-"], "ggdb3">, Group;
 def glldb : Flag<["-"], "glldb">, Group;
 def gsce : Flag<["-"], "gsce">, Group;
+def gdbx : Flag<["-"], "gdbx">, Group;
 // Equivalent to our default dwarf version. Forces usual dwarf emission when
 // CodeView is enabled.
 def gdwarf : Flag<["-"], "gdwarf">, Group, Flags<[CoreOption]>,
@@ -4612,8 +4613,8 @@ def default_function_attr : Separate<["-"], 
"default-function-attr">,
 def dwarf_version_EQ : Joined<["-"], "dwarf-version=">,
   MarshallingInfoInt>;
 def debugger_tuning_EQ : Joined<["-"], "debugger-tuning=">,
-  Values<"gdb,lldb,sce">,
-  NormalizedValuesScope<"llvm::DebuggerKind">, NormalizedValues<["GDB", 
"LLDB", "SCE"]>,
+  Values<"gdb,lldb,sce,dbx">,
+  NormalizedValuesScope<"llvm::DebuggerKind">, NormalizedValues<["GDB", 
"LLDB", "SCE", "DBX"]>,
   MarshallingInfoEnum, "Default">;
 def dwarf_debug_flags : Separate<["-"], "dwarf-debug-flags">,
   HelpText<"The string to embed in the Dwarf debug flags record.">,

diff  --git a/clang/lib/Driver/ToolChains/AIX.h 
b/clang/lib/Driver/ToolChains/AIX.h
index c6aac09ddfac3..1534af950c88f 100644
--- a/clang/lib/Driver/ToolChains/AIX.h
+++ b/clang/lib/Driver/ToolChains/AIX.h
@@ -77,6 +77,10 @@ class LLVM_LIBRARY_VISIBILITY AIX : public ToolChain {
   // Set default DWARF version to 3 for now as latest AIX OS supports version 
3.
   unsigned GetDefaultDwarfVersion() const override { return 3; }
 
+  llvm::DebuggerKind getDefaultDebuggerTuning() const override {
+return llvm::DebuggerKind::DBX;
+  }
+
 protected:
   Tool *buildAssembler() const override;
   Tool *buildLinker() const override;

diff  --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index 804f528838c58..c9b44aa76b6ba 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -1051,6 +1051,9 @@ static void 

[PATCH] D91327: [NewPM] Redesign of PreserveCFG Checker

[Yevgeny Rouban via Phabricator via cfe-commits]

yrouban added a comment.

@skatkov, @fedor.sergeev, could you please review. During the long time this 
features is on the reconstruction we introduced a new bug in the LoopFlatten 
pass. See the comment https://reviews.llvm.org/D90940#inline-938253.


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

https://reviews.llvm.org/D91327

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

[PATCH] D99689: [OPENMP]Add option -fopenmp-cuda-const-firstprivate to control address space of the corresponding global.

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert added a comment.

In D99689#2662860 , @ABataev wrote:

> In D99689#2662856 , @jdoerfert wrote:
>
>> In D99689#2662852 , @ABataev wrote:
>>
>>> In D99689#2662848 , @jdoerfert 
>>> wrote:
>>>
 Can you please show me a test case or explain to me when/how this global 
 is actually used.
>>>
>>> It is passed as an argument to the target region. When libomptarget 
>>> requests the memory for the firstprivate, it returns the pointer to this 
>>> const global, which then passed as argument to the kernel.
>>
>> So if we use it, why would we disable it?
>
> With this  new option you can control how to handle it. You can either 
> dynamically allocate memory using libomptarget memmanager (default for this 
> option) or use preallocated constant memory, if you're not going to remove 
> the var constantness.

I get what the new option does, what I want to know is why we would ever want 
to disable the constant memory usage. Is it potentially slower or otherwise 
problematic?
Also, I am not sure but I imagine the generated code would be better if we 
would use the constant global directly, or, add the address space to the 
corresponding kernel argument.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99689

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

[PATCH] D99590: [Clang] Do not use memcpy for scalable struct copy.

[Hsiangkai Wang via Phabricator via cfe-commits]

HsiangKai updated this revision to Diff 334579.
HsiangKai added a comment.

Address comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99590

Files:
  clang/include/clang/AST/Type.h
  clang/lib/AST/Type.cpp
  clang/lib/CodeGen/CGExprAgg.cpp


Index: clang/lib/CodeGen/CGExprAgg.cpp
===
--- clang/lib/CodeGen/CGExprAgg.cpp
+++ clang/lib/CodeGen/CGExprAgg.cpp
@@ -2077,6 +2077,23 @@
 }
   }
 
+  // Aggregate assignment turns into element-by-element copy.
+  if (const RecordType *RecordTy = Ty->getAs()) {
+if (RecordTy->hasSizelessFields()) {
+  RecordDecl *Record = RecordTy->getDecl();
+  llvm::Value *SrcAgg = Builder.CreateLoad(SrcPtr);
+  llvm::Value *DestAgg = llvm::UndefValue::get(ConvertType(Ty));
+  unsigned FieldCount =
+  getContext().getASTRecordLayout(Record).getFieldCount();
+  for (unsigned I = 0; I < FieldCount; ++I) {
+llvm::Value *Vec = Builder.CreateExtractValue(SrcAgg, I);
+DestAgg = Builder.CreateInsertValue(DestAgg, Vec, I);
+  }
+  Builder.CreateStore(DestAgg, DestPtr);
+  return;
+}
+  }
+
   // Aggregate assignment turns into llvm.memcpy.  This is almost valid per
   // C99 6.5.16.1p3, which states "If the value being stored in an object is
   // read from another object that overlaps in anyway the storage of the first
Index: clang/lib/AST/Type.cpp
===
--- clang/lib/AST/Type.cpp
+++ clang/lib/AST/Type.cpp
@@ -3510,6 +3510,28 @@
   return false;
 }
 
+bool RecordType::hasSizelessFields() const {
+  std::vector RecordTypeList;
+  RecordTypeList.push_back(this);
+  unsigned NextToCheckIndex = 0;
+
+  while (RecordTypeList.size() > NextToCheckIndex) {
+for (FieldDecl *FD :
+ RecordTypeList[NextToCheckIndex]->getDecl()->fields()) {
+  QualType FieldTy = FD->getType();
+  if (FieldTy.getTypePtr()->isSizelessType())
+return true;
+  FieldTy = FieldTy.getCanonicalType();
+  if (const auto *FieldRecTy = FieldTy->getAs()) {
+if (llvm::find(RecordTypeList, FieldRecTy) == RecordTypeList.end())
+  RecordTypeList.push_back(FieldRecTy);
+  }
+}
+++NextToCheckIndex;
+  }
+  return false;
+}
+
 bool AttributedType::isQualifier() const {
   // FIXME: Generate this with TableGen.
   switch (getAttrKind()) {
Index: clang/include/clang/AST/Type.h
===
--- clang/include/clang/AST/Type.h
+++ clang/include/clang/AST/Type.h
@@ -4623,6 +4623,10 @@
   /// is declared const, return true. Otherwise, return false.
   bool hasConstFields() const;
 
+  /// Recursively check all fields in the record for sizeless. If any field
+  /// is a sizeless type, return true. Otherwise, return false.
+  bool hasSizelessFields() const;
+
   bool isSugared() const { return false; }
   QualType desugar() const { return QualType(this, 0); }
 


Index: clang/lib/CodeGen/CGExprAgg.cpp
===
--- clang/lib/CodeGen/CGExprAgg.cpp
+++ clang/lib/CodeGen/CGExprAgg.cpp
@@ -2077,6 +2077,23 @@
 }
   }
 
+  // Aggregate assignment turns into element-by-element copy.
+  if (const RecordType *RecordTy = Ty->getAs()) {
+if (RecordTy->hasSizelessFields()) {
+  RecordDecl *Record = RecordTy->getDecl();
+  llvm::Value *SrcAgg = Builder.CreateLoad(SrcPtr);
+  llvm::Value *DestAgg = llvm::UndefValue::get(ConvertType(Ty));
+  unsigned FieldCount =
+  getContext().getASTRecordLayout(Record).getFieldCount();
+  for (unsigned I = 0; I < FieldCount; ++I) {
+llvm::Value *Vec = Builder.CreateExtractValue(SrcAgg, I);
+DestAgg = Builder.CreateInsertValue(DestAgg, Vec, I);
+  }
+  Builder.CreateStore(DestAgg, DestPtr);
+  return;
+}
+  }
+
   // Aggregate assignment turns into llvm.memcpy.  This is almost valid per
   // C99 6.5.16.1p3, which states "If the value being stored in an object is
   // read from another object that overlaps in anyway the storage of the first
Index: clang/lib/AST/Type.cpp
===
--- clang/lib/AST/Type.cpp
+++ clang/lib/AST/Type.cpp
@@ -3510,6 +3510,28 @@
   return false;
 }
 
+bool RecordType::hasSizelessFields() const {
+  std::vector RecordTypeList;
+  RecordTypeList.push_back(this);
+  unsigned NextToCheckIndex = 0;
+
+  while (RecordTypeList.size() > NextToCheckIndex) {
+for (FieldDecl *FD :
+ RecordTypeList[NextToCheckIndex]->getDecl()->fields()) {
+  QualType FieldTy = FD->getType();
+  if (FieldTy.getTypePtr()->isSizelessType())
+return true;
+  FieldTy = FieldTy.getCanonicalType();
+  if (const auto *FieldRecTy = FieldTy->getAs()) {
+if (llvm::find(RecordTypeList, FieldRecTy) == 

[PATCH] D99482: [PoC][Clang][CodeGen] Do not use getelementptr for scalable struct.

[Hsiangkai Wang via Phabricator via cfe-commits]

HsiangKai updated this revision to Diff 334578.
HsiangKai added a comment.

Address comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99482

Files:
  clang/lib/CodeGen/CGCall.cpp


Index: clang/lib/CodeGen/CGCall.cpp
===
--- clang/lib/CodeGen/CGCall.cpp
+++ clang/lib/CodeGen/CGCall.cpp
@@ -1296,12 +1296,16 @@
 // FIXME: Do we need to recurse here?
 void CodeGenFunction::EmitAggregateStore(llvm::Value *Val, Address Dest,
  bool DestIsVolatile) {
-  // Prefer scalar stores to first-class aggregate stores.
   if (llvm::StructType *STy = dyn_cast(Val->getType())) {
-for (unsigned i = 0, e = STy->getNumElements(); i != e; ++i) {
-  Address EltPtr = Builder.CreateStructGEP(Dest, i);
-  llvm::Value *Elt = Builder.CreateExtractValue(Val, i);
-  Builder.CreateStore(Elt, EltPtr, DestIsVolatile);
+if (STy->containsScalableVectorType())
+  Builder.CreateStore(Val, Dest, DestIsVolatile);
+else {
+  // Prefer scalar stores to first-class aggregate stores.
+  for (unsigned i = 0, e = STy->getNumElements(); i != e; ++i) {
+Address EltPtr = Builder.CreateStructGEP(Dest, i);
+llvm::Value *Elt = Builder.CreateExtractValue(Val, i);
+Builder.CreateStore(Elt, EltPtr, DestIsVolatile);
+  }
 }
   } else {
 Builder.CreateStore(Val, Dest, DestIsVolatile);
@@ -2857,11 +2861,21 @@
 }
 
 assert(STy->getNumElements() == NumIRArgs);
-for (unsigned i = 0, e = STy->getNumElements(); i != e; ++i) {
-  auto AI = Fn->getArg(FirstIRArg + i);
-  AI->setName(Arg->getName() + ".coerce" + Twine(i));
-  Address EltPtr = Builder.CreateStructGEP(AddrToStoreInto, i);
-  Builder.CreateStore(AI, EltPtr);
+if (STy->containsScalableVectorType()) {
+  llvm::Value *Val = llvm::UndefValue::get(STy);
+  for (unsigned i = 0, e = STy->getNumElements(); i != e; ++i) {
+auto AI = Fn->getArg(FirstIRArg + i);
+AI->setName(Arg->getName() + ".coerce" + Twine(i));
+Val = Builder.CreateInsertValue(Val, AI, i);
+  }
+  Builder.CreateStore(Val, AddrToStoreInto);
+} else {
+  for (unsigned i = 0, e = STy->getNumElements(); i != e; ++i) {
+auto AI = Fn->getArg(FirstIRArg + i);
+AI->setName(Arg->getName() + ".coerce" + Twine(i));
+Address EltPtr = Builder.CreateStructGEP(AddrToStoreInto, i);
+Builder.CreateStore(AI, EltPtr);
+  }
 }
 
 if (SrcSize > DstSize) {
@@ -4920,10 +4934,18 @@
 }
 
 assert(NumIRArgs == STy->getNumElements());
-for (unsigned i = 0, e = STy->getNumElements(); i != e; ++i) {
-  Address EltPtr = Builder.CreateStructGEP(Src, i);
-  llvm::Value *LI = Builder.CreateLoad(EltPtr);
-  IRCallArgs[FirstIRArg + i] = LI;
+if (STy->containsScalableVectorType()) {
+  llvm::Value *Val = Builder.CreateLoad(Src);
+  for (unsigned i = 0, e = STy->getNumElements(); i != e; ++i) {
+llvm::Value *LI = Builder.CreateExtractValue(Val, i);
+IRCallArgs[FirstIRArg + i] = LI;
+  }
+} else {
+  for (unsigned i = 0, e = STy->getNumElements(); i != e; ++i) {
+Address EltPtr = Builder.CreateStructGEP(Src, i);
+llvm::Value *LI = Builder.CreateLoad(EltPtr);
+IRCallArgs[FirstIRArg + i] = LI;
+  }
 }
   } else {
 // In the simple case, just pass the coerced loaded value.


Index: clang/lib/CodeGen/CGCall.cpp
===
--- clang/lib/CodeGen/CGCall.cpp
+++ clang/lib/CodeGen/CGCall.cpp
@@ -1296,12 +1296,16 @@
 // FIXME: Do we need to recurse here?
 void CodeGenFunction::EmitAggregateStore(llvm::Value *Val, Address Dest,
  bool DestIsVolatile) {
-  // Prefer scalar stores to first-class aggregate stores.
   if (llvm::StructType *STy = dyn_cast(Val->getType())) {
-for (unsigned i = 0, e = STy->getNumElements(); i != e; ++i) {
-  Address EltPtr = Builder.CreateStructGEP(Dest, i);
-  llvm::Value *Elt = Builder.CreateExtractValue(Val, i);
-  Builder.CreateStore(Elt, EltPtr, DestIsVolatile);
+if (STy->containsScalableVectorType())
+  Builder.CreateStore(Val, Dest, DestIsVolatile);
+else {
+  // Prefer scalar stores to first-class aggregate stores.
+  for (unsigned i = 0, e = STy->getNumElements(); i != e; ++i) {
+Address EltPtr = Builder.CreateStructGEP(Dest, i);
+llvm::Value *Elt = Builder.CreateExtractValue(Val, i);
+Builder.CreateStore(Elt, EltPtr, DestIsVolatile);
+  }
 }
   } else {
 Builder.CreateStore(Val, Dest, DestIsVolatile);
@@ -2857,11 +2861,21 @@
 

[PATCH] D99482: [PoC][Clang][CodeGen] Do not use getelementptr for scalable struct.

[Hsiangkai Wang via Phabricator via cfe-commits]

HsiangKai added a comment.

In D99482#2661334 , @frasercrmck wrote:

> Are there any tests for this?

The only scalable struct types are Zvlsseg types in Clang. We have use cases in 
D99593 . I have no separate test cases in this 
commit.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99482

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

[PATCH] D99689: [OPENMP]Add option -fopenmp-cuda-const-firstprivate to control address space of the corresponding global.

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added a comment.

In D99689#2662856 , @jdoerfert wrote:

> In D99689#2662852 , @ABataev wrote:
>
>> In D99689#2662848 , @jdoerfert 
>> wrote:
>>
>>> Can you please show me a test case or explain to me when/how this global is 
>>> actually used.
>>
>> It is passed as an argument to the target region. When libomptarget requests 
>> the memory for the firstprivate, it returns the pointer to this const 
>> global, which then passed as argument to the kernel.
>
> So if we use it, why would we disable it?

With this  new option you can control how to handle it. You can either 
dynamically allocate memory using libomptarget memmanager (default for this 
option) or use preallocated constant memory, if you're not going to remove the 
var constantness.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99689

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

[PATCH] D99689: [OPENMP]Add option -fopenmp-cuda-const-firstprivate to control address space of the corresponding global.

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert added a comment.

In D99689#2662852 , @ABataev wrote:

> In D99689#2662848 , @jdoerfert wrote:
>
>> Can you please show me a test case or explain to me when/how this global is 
>> actually used.
>
> It is passed as an argument to the target region. When libomptarget requests 
> the memory for the firstprivate, it returns the pointer to this const global, 
> which then passed as argument to the kernel.

So if we use it, why would we disable it?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99689

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

[PATCH] D99689: [OPENMP]Add option -fopenmp-cuda-const-firstprivate to control address space of the corresponding global.

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added a comment.

In D99689#2662848 , @jdoerfert wrote:

> Can you please show me a test case or explain to me when/how this global is 
> actually used.

It is passed as an argument to the target region. When libomptarget requests 
the memory for the firstprivate, it returns the pointer to this const global, 
which then passed as argument to the kernel.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99689

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

[PATCH] D99689: [OPENMP]Add option -fopenmp-cuda-const-firstprivate to control address space of the corresponding global.

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert added a comment.

Can you please show me a test case or explain to me when/how this global is 
actually used.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99689

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

[PATCH] D91327: [NewPM] Redesign of PreserveCFG Checker

[Yevgeny Rouban via Phabricator via cfe-commits]

yrouban added inline comments.



Comment at: llvm/include/llvm/Passes/StandardInstrumentations.h:422
+  // Register all the standard instrumentation callbacks. If \p FAM is nullptr
+  // then PreservedCFGChecker is not registeredenabled.
+  void registerCallbacks(PassInstrumentationCallbacks ,

fix registeredenabled


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

https://reviews.llvm.org/D91327

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

[clang] a821999 - [clang][APINotes] Fix -Wunused-function warning (NFC)

[Yang Fan via cfe-commits]

Author: Yang Fan
Date: 2021-04-01T09:52:43+08:00
New Revision: a8219991d0245db8f31a923ba7f24e6beda345b0

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

LOG: [clang][APINotes] Fix -Wunused-function warning (NFC)

GCC warning:
```
/llvm-project/clang/lib/APINotes/APINotesYAMLCompiler.cpp:574:23: warning: 
‘void {anonymous}::Module::dump()’ defined but not used [-Wunused-function]
  574 | LLVM_DUMP_METHOD void Module::dump() {
  |   ^~
```

Added: 


Modified: 
clang/lib/APINotes/APINotesYAMLCompiler.cpp

Removed: 




diff  --git a/clang/lib/APINotes/APINotesYAMLCompiler.cpp 
b/clang/lib/APINotes/APINotesYAMLCompiler.cpp
index cf50e26b1c87a..75100fde59b84 100644
--- a/clang/lib/APINotes/APINotesYAMLCompiler.cpp
+++ b/clang/lib/APINotes/APINotesYAMLCompiler.cpp
@@ -551,7 +551,9 @@ struct Module {
 
   llvm::Optional SwiftInferImportAsMember = {llvm::None};
 
-  void dump() /*const*/;
+#if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)
+  LLVM_DUMP_METHOD void dump() /*const*/;
+#endif
 };
 } // namespace
 
@@ -571,10 +573,12 @@ template <> struct MappingTraits {
 } // namespace yaml
 } // namespace llvm
 
+#if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)
 LLVM_DUMP_METHOD void Module::dump() {
   llvm::yaml::Output OS(llvm::errs());
   OS << *this;
 }
+#endif
 
 namespace {
 bool parseAPINotes(StringRef YI, Module , llvm::SourceMgr::DiagHandlerTy 
Diag,



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

[PATCH] D99696: [clang] WIP: NRVO: Improvements and handling of more cases.

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov updated this revision to Diff 334575.
mizvekov added a comment.

fix clang-tidy warning.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99696

Files:
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaCoroutine.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/lib/Sema/SemaStmt.cpp
  clang/lib/Sema/SemaTemplateInstantiateDecl.cpp

Index: clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
===
--- clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
+++ clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
@@ -1052,9 +1052,20 @@
  StartingScope, InstantiatingVarTemplate);
 
   if (D->isNRVOVariable()) {
-QualType ReturnType = cast(DC)->getReturnType();
-if (SemaRef.isCopyElisionCandidate(ReturnType, Var, Sema::CES_Strict))
-  Var->setNRVOVariable(true);
+Sema::NRVOResult Res = SemaRef.getNRVOResult(Var);
+
+QualType ReturnType;
+if (auto *F = dyn_cast(DC))
+  ReturnType = F->getReturnType();
+else if (auto *F = dyn_cast(DC))
+  // FIXME: get the return type here somehow...
+  ReturnType = SemaRef.Context.getAutoDeductType();
+else
+  assert(false && "Unknown context type");
+
+if (!ReturnType->isUndeducedType())
+  SemaRef.updNRVOResultWithRetType(Res, ReturnType);
+Var->setNRVOVariable(Res.isCopyElidable());
   }
 
   Var->setImplicit(D->isImplicit());
Index: clang/lib/Sema/SemaStmt.cpp
===
--- clang/lib/Sema/SemaStmt.cpp
+++ clang/lib/Sema/SemaStmt.cpp
@@ -3026,99 +3026,128 @@
   return new (Context) BreakStmt(BreakLoc);
 }
 
-/// Determine whether the given expression is a candidate for
-/// copy elision in either a return statement or a throw expression.
-///
-/// \param ReturnType If we're determining the copy elision candidate for
-/// a return statement, this is the return type of the function. If we're
-/// determining the copy elision candidate for a throw expression, this will
-/// be a NULL type.
+static void downgradeNRVOResult(Sema::NRVOResult , bool CanMove) {
+  Res.S = CanMove ? std::min(Res.S, Sema::NRVOResult::MoveEligible)
+  : Sema::NRVOResult::None;
+}
+
+/// Determine whether the given NRVO candidate variable is move-eligible or
+/// copy-elision eligible, without considering function return type.
 ///
-/// \param E The expression being returned from the function or block, or
-/// being thrown.
+/// \param VD The NRVO candidate variable.
 ///
-/// \param CESK Whether we allow function parameters or
-/// id-expressions that could be moved out of the function to be considered NRVO
-/// candidates. C++ prohibits these for NRVO itself, but we re-use this logic to
-/// determine whether we should try to move as part of a return or throw (which
-/// does allow function parameters).
+/// \param ForceCXX20 Overrides detection of current language mode
+/// and uses the rules for C++20.
 ///
-/// \returns The NRVO candidate variable, if the return statement may use the
-/// NRVO, or NULL if there is no such candidate.
-VarDecl *Sema::getCopyElisionCandidate(QualType ReturnType, Expr *E,
-   CopyElisionSemanticsKind CESK) {
-  // - in a return statement in a function [where] ...
-  // ... the expression is the name of a non-volatile automatic object ...
-  DeclRefExpr *DR = dyn_cast(E->IgnoreParens());
-  if (!DR || DR->refersToEnclosingVariableOrCapture())
-return nullptr;
-  VarDecl *VD = dyn_cast(DR->getDecl());
+/// \returns An aggregate which contains the Candidate and isMoveEligible
+/// and isCopyElidable methods. If Candidate is non-null, it means
+/// isMoveEligible() would be true under the most permissive language standard.
+Sema::NRVOResult Sema::getNRVOResult(const VarDecl *VD, bool ForceCXX20) {
   if (!VD)
-return nullptr;
+return NRVOResult();
 
-  if (isCopyElisionCandidate(ReturnType, VD, CESK))
-return VD;
-  return nullptr;
-}
+  bool hasCXX11 = getLangOpts().CPlusPlus11 || ForceCXX20,
+   hasCXX20 = getLangOpts().CPlusPlus20 || ForceCXX20;
+  NRVOResult Res{VD, NRVOResult::MoveEligibleAndCopyElidable};
 
-bool Sema::isCopyElisionCandidate(QualType ReturnType, const VarDecl *VD,
-  CopyElisionSemanticsKind CESK) {
-  QualType VDType = VD->getType();
-  // - in a return statement in a function with ...
-  // ... a class return type ...
-  if (!ReturnType.isNull() && !ReturnType->isDependentType()) {
-if (!ReturnType->isRecordType())
-  return false;
-// ... the same cv-unqualified type as the function return type ...
-// When considering moving this expression out, allow dissimilar types.
-if (!(CESK & CES_AllowDifferentTypes) && !VDType->isDependentType() &&
-!Context.hasSameUnqualifiedType(ReturnType, VDType))
-  return 

[PATCH] D99556: Add support to -Wa,--version in clang

[Douglas Yung via Phabricator via cfe-commits]

dyung added a comment.

It also fails with the PS4 triple because we default to an external assembler 
that isn't present: 
https://lab.llvm.org/buildbot/#/builders/139/builds/2161/steps/6/logs/FAIL__Clang__as-version_s


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99556

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

[PATCH] D99696: [clang] WIP: NRVO: Improvements and handling of more cases.

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov added a comment.

In D99696#2662816 , @Quuxplusone wrote:

> Wow, nice catches. For posterity, here's the missed-optimization being 
> addressed IIUC: https://godbolt.org/z/MEoKGs7cE

Thanks! And again thank you for providing test cases, it's what I planned to 
start doing next :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99696

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

[PATCH] D99696: [clang] WIP: NRVO: Improvements and handling of more cases.

[Arthur O'Dwyer via Phabricator via cfe-commits]

Quuxplusone added a comment.

Wow, nice catches. For posterity, here's the missed-optimization being 
addressed IIUC: https://godbolt.org/z/MEoKGs7cE


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99696

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

[PATCH] D99668: [RISCV][Clang] Add some RVV Floating-Point intrinsic functions.

[Craig Topper via Phabricator via cfe-commits]

craig.topper requested changes to this revision.
craig.topper added inline comments.
This revision now requires changes to proceed.



Comment at: clang/include/clang/Basic/riscv_vector.td:761
+defm vfdiv : RVVFloatingBinBuiltinSet;
+defm vfrdiv : RVVFloatingBinBuiltinSet;
+

Shouldn't this be the same as vfrsub?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99668

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

[PATCH] D99696: [clang] WIP: NRVO: Improvements and handling of more cases.

[Matheus Izvekov via Phabricator via cfe-commits]

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

This expands NRVO propagation for more cases:

Parse analysis improvement:

  Lambdas and Blocks with dependent return type can have their variables marked 
as
  NRVO Candidates.

Variable instantiation improvement:

  Functions, Lambdas, and Blocks which have auto return type have their
  variables' NRVO status propagated. For Blocks with non-auto return type,
  as a limitation, this propagation does not consider the actual return
  type.

Signed-off-by: Matheus Izvekov 


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D99696

Files:
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaCoroutine.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/lib/Sema/SemaStmt.cpp
  clang/lib/Sema/SemaTemplateInstantiateDecl.cpp

Index: clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
===
--- clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
+++ clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
@@ -1052,9 +1052,20 @@
  StartingScope, InstantiatingVarTemplate);
 
   if (D->isNRVOVariable()) {
-QualType ReturnType = cast(DC)->getReturnType();
-if (SemaRef.isCopyElisionCandidate(ReturnType, Var, Sema::CES_Strict))
-  Var->setNRVOVariable(true);
+Sema::NRVOResult Res = SemaRef.getNRVOResult(Var);
+
+QualType ReturnType;
+if (auto *F = dyn_cast(DC))
+  ReturnType = F->getReturnType();
+else if (auto *F = dyn_cast(DC))
+  // FIXME: get the return type here somehow...
+  ReturnType = SemaRef.Context.getAutoDeductType();
+else
+  assert(false && "Unknown context type");
+
+if (!ReturnType->isUndeducedType())
+  SemaRef.updNRVOResultWithRetType(Res, ReturnType);
+Var->setNRVOVariable(Res.isCopyElidable());
   }
 
   Var->setImplicit(D->isImplicit());
Index: clang/lib/Sema/SemaStmt.cpp
===
--- clang/lib/Sema/SemaStmt.cpp
+++ clang/lib/Sema/SemaStmt.cpp
@@ -3026,99 +3026,128 @@
   return new (Context) BreakStmt(BreakLoc);
 }
 
-/// Determine whether the given expression is a candidate for
-/// copy elision in either a return statement or a throw expression.
-///
-/// \param ReturnType If we're determining the copy elision candidate for
-/// a return statement, this is the return type of the function. If we're
-/// determining the copy elision candidate for a throw expression, this will
-/// be a NULL type.
+static void downgradeNRVOResult(Sema::NRVOResult , bool CanMove) {
+  Res.S = CanMove ? std::min(Res.S, Sema::NRVOResult::MoveEligible)
+  : Sema::NRVOResult::None;
+}
+
+/// Determine whether the given NRVO candidate variable is move-eligible or
+/// copy-elision eligible, without considering function return type.
 ///
-/// \param E The expression being returned from the function or block, or
-/// being thrown.
+/// \param VD The NRVO candidate variable.
 ///
-/// \param CESK Whether we allow function parameters or
-/// id-expressions that could be moved out of the function to be considered NRVO
-/// candidates. C++ prohibits these for NRVO itself, but we re-use this logic to
-/// determine whether we should try to move as part of a return or throw (which
-/// does allow function parameters).
+/// \param ForceCXX20 Overrides detection of current language mode
+/// and uses the rules for C++20.
 ///
-/// \returns The NRVO candidate variable, if the return statement may use the
-/// NRVO, or NULL if there is no such candidate.
-VarDecl *Sema::getCopyElisionCandidate(QualType ReturnType, Expr *E,
-   CopyElisionSemanticsKind CESK) {
-  // - in a return statement in a function [where] ...
-  // ... the expression is the name of a non-volatile automatic object ...
-  DeclRefExpr *DR = dyn_cast(E->IgnoreParens());
-  if (!DR || DR->refersToEnclosingVariableOrCapture())
-return nullptr;
-  VarDecl *VD = dyn_cast(DR->getDecl());
+/// \returns An aggregate which contains the Candidate and isMoveEligible
+/// and isCopyElidable methods. If Candidate is non-null, it means
+/// isMoveEligible() would be true under the most permissive language standard.
+Sema::NRVOResult Sema::getNRVOResult(const VarDecl *VD, bool ForceCXX20) {
   if (!VD)
-return nullptr;
+return NRVOResult();
 
-  if (isCopyElisionCandidate(ReturnType, VD, CESK))
-return VD;
-  return nullptr;
-}
+  bool hasCXX11 = getLangOpts().CPlusPlus11 || ForceCXX20,
+   hasCXX20 = getLangOpts().CPlusPlus20 || ForceCXX20;
+  NRVOResult Res{VD, NRVOResult::MoveEligibleAndCopyElidable};
 
-bool Sema::isCopyElisionCandidate(QualType ReturnType, const VarDecl *VD,
-  CopyElisionSemanticsKind CESK) {
-  QualType VDType = VD->getType();
-  // - in a 

[PATCH] D98912: Fix -Winteger-overflow to diagnose regardless of the top-level syntactic form.

[Volodymyr Sapsai via Phabricator via cfe-commits]

vsapsai added a comment.

Looks good to me. Have a few clarification questions.




Comment at: clang/lib/AST/ExprConstant.cpp:972-973
 
+// Determine if we might warn that the given expression exhibits undefined
+// behavior.
+bool mightWarnOnUndefinedBehavior(const Expr *E) {

I'm not entirely sure but it can be useful to make it explicit in the comment 
the method doesn't deal with all the subexpressions recursively. Not convinced 
it is useful because don't have a good wording and you can get that information 
from the short method implementation. It is possible my suggestion is caused by 
checking the patch top-to-bottom without seeing how 
`mightWarnOnUndefinedBehavior` is used first, but that's not how developers 
would read the code later.



Comment at: clang/lib/AST/ExprConstant.cpp:8398-8399
 bool LValueExprEvaluator::VisitUnaryPreIncDec(const UnaryOperator *UO) {
-  if (!Info.getLangOpts().CPlusPlus14 && !Info.keepEvaluatingAfterFailure())
-return Error(UO);
 

Just to confirm my understanding. There is no point in checking 
`keepEvaluatingAfterFailure` here because we are not short-circuiting anymore 
but can evaluate the expression in `VisitExpr(UO)`. And we still check 
`keepEvaluatingAfterFailure` in `SubexpressionVisitor::Run` in 
`EvaluateForDiagnostics`.



Comment at: clang/lib/Sema/SemaExpr.cpp:7125-7126
   << DestTy;
-  return CK_IntegralCast;
+  Src = ExprError();
+  return CK_Dependent;
 case Type::STK_CPointer:

What is the purpose of these changes to return `CK_Dependent`? Tests are 
passing without them and it's not obvious to me why do you need to change 
`CK_IntegralCast` to `CK_Dependent`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98912

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

[PATCH] D99556: Add support to -Wa,--version in clang

[Nick Desaulniers via Phabricator via cfe-commits]

nickdesaulniers added a comment.

ah, sorry, I think we're missing a `// REQUIRES: linux` in the newly added 
test? I've pushed a revert for now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99556

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

[clang] bf2479c - Revert "Add support to -Wa,--version in clang"

[Nick Desaulniers via cfe-commits]

Author: Nick Desaulniers
Date: 2021-03-31T17:02:13-07:00
New Revision: bf2479c347c8ca88fefdb144d8bae0a7a4231e2a

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

LOG: Revert "Add support to -Wa,--version in clang"

This reverts commit 3cc3c0f8352ec33ca2f2636f94cb1d85fc57ac16.

Breaks non-linux platforms.

https://reviews.llvm.org/D99556#2662706
Signed-off-by: Nick Desaulniers 

Added: 


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

Removed: 
clang/test/Driver/as-version.s



diff  --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index 9d3c725198f4d..804f528838c58 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -2549,8 +2549,6 @@ static void CollectArgsForIntegratedAssembler(Compilation 
,
 // -fdebug-compilation-dir (without '=') here.
 CmdArgs.push_back("-fdebug-compilation-dir");
 CmdArgs.push_back(Value.data());
-  } else if (Value == "--version") {
-D.PrintVersion(C, llvm::outs());
   } else {
 D.Diag(diag::err_drv_unsupported_option_argument)
 << A->getOption().getName() << Value;

diff  --git a/clang/test/Driver/as-version.s b/clang/test/Driver/as-version.s
deleted file mode 100644
index 9d2801e4ee379..0
--- a/clang/test/Driver/as-version.s
+++ /dev/null
@@ -1,9 +0,0 @@
-// Test version information.
-
-// RUN: %clang -Wa,--version -c -fintegrated-as %s -o /dev/null \
-// RUN:   | FileCheck --check-prefix=IAS %s
-// IAS: clang version
-
-// RUN: %clang -Wa,--version -c -fno-integrated-as %s -o /dev/null \
-// RUN:   | FileCheck --check-prefix=GAS %s
-// GAS-NOT: clang



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

[PATCH] D99556: Add support to -Wa,--version in clang

[Nico Weber via Phabricator via cfe-commits]

thakis added a comment.

Different error on windows: http://45.33.8.238/win/36132/step_7.txt


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99556

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

[PATCH] D99556: Add support to -Wa,--version in clang

[Nico Weber via Phabricator via cfe-commits]

thakis added a comment.

Looks like the test fails on non-linux:
http://45.33.8.238/macm1/6631/step_6.txt

Please take a look and revert for now if it takes a while to fix.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99556

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

[PATCH] D99668: [RISCV][Clang] Add some RVV Floating-Point intrinsic functions.

[Liao Chunyu via Phabricator via cfe-commits]

liaolucy added a comment.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99668

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

[PATCH] D99526: [RISCV][Clang] Add RVV Widening Integer Add/Subtract intrinsic functions.

[Craig Topper via Phabricator via cfe-commits]

craig.topper added inline comments.



Comment at: clang/include/clang/Basic/riscv_vector.td:282
+}
+// Encode vx/wx in the sufffix of mangled name
+let Name = NAME # "_" # vx_suffixes_prototype[0],

sufffix->suffix



Comment at: clang/include/clang/Basic/riscv_vector.td:302
+}
+// Encode vx/wx in the sufffix of mangled name
+let Name = NAME # "_" # vx_suffixes_prototype[0],

sufffix->suffix



Comment at: clang/include/clang/Basic/riscv_vector.td:312
+
+multiclass RVVSignedWidenBinBuiltinSet {
+  if has_widden_op then {

widden->widen



Comment at: clang/include/clang/Basic/riscv_vector.td:312
+
+multiclass RVVSignedWidenBinBuiltinSet {
+  if has_widden_op then {

craig.topper wrote:
> widden->widen
I'm not sure having a multiclass that takes a bool is better than just having 2 
different multiclasses.



Comment at: clang/include/clang/Basic/riscv_vector.td:325
+multiclass RVVUnsignedWidenBinBuiltinSet {
+  if has_widden_op then {
+defm "" : RVVWidenBuiltinSetwiden



Comment at: clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vwadd.c:35
+vint16mf4_t test_vwadd_vx_i16mf4(vint8mf8_t op1, int8_t op2, size_t vl) {
+  return vwadd_vx(op1, op2, vl);
+}

Why do scalars require _wx or _vx, but vector don't need a suffix?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99526

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

[PATCH] D99556: Add support to -Wa,--version in clang

[Jian Cai via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
jcai19 marked an inline comment as done.
Closed by commit rG3cc3c0f8352e: Add support to -Wa,--version in clang 
(authored by jcai19).

Changed prior to commit:
  https://reviews.llvm.org/D99556?vs=334315=334558#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99556

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/as-version.s


Index: clang/test/Driver/as-version.s
===
--- /dev/null
+++ clang/test/Driver/as-version.s
@@ -0,0 +1,9 @@
+// Test version information.
+
+// RUN: %clang -Wa,--version -c -fintegrated-as %s -o /dev/null \
+// RUN:   | FileCheck --check-prefix=IAS %s
+// IAS: clang version
+
+// RUN: %clang -Wa,--version -c -fno-integrated-as %s -o /dev/null \
+// RUN:   | FileCheck --check-prefix=GAS %s
+// GAS-NOT: clang
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -2549,6 +2549,8 @@
 // -fdebug-compilation-dir (without '=') here.
 CmdArgs.push_back("-fdebug-compilation-dir");
 CmdArgs.push_back(Value.data());
+  } else if (Value == "--version") {
+D.PrintVersion(C, llvm::outs());
   } else {
 D.Diag(diag::err_drv_unsupported_option_argument)
 << A->getOption().getName() << Value;


Index: clang/test/Driver/as-version.s
===
--- /dev/null
+++ clang/test/Driver/as-version.s
@@ -0,0 +1,9 @@
+// Test version information.
+
+// RUN: %clang -Wa,--version -c -fintegrated-as %s -o /dev/null \
+// RUN:   | FileCheck --check-prefix=IAS %s
+// IAS: clang version
+
+// RUN: %clang -Wa,--version -c -fno-integrated-as %s -o /dev/null \
+// RUN:   | FileCheck --check-prefix=GAS %s
+// GAS-NOT: clang
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -2549,6 +2549,8 @@
 // -fdebug-compilation-dir (without '=') here.
 CmdArgs.push_back("-fdebug-compilation-dir");
 CmdArgs.push_back(Value.data());
+  } else if (Value == "--version") {
+D.PrintVersion(C, llvm::outs());
   } else {
 D.Diag(diag::err_drv_unsupported_option_argument)
 << A->getOption().getName() << Value;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 3cc3c0f - Add support to -Wa,--version in clang

[Jian Cai via cfe-commits]

Author: Jian Cai
Date: 2021-03-31T16:29:02-07:00
New Revision: 3cc3c0f8352ec33ca2f2636f94cb1d85fc57ac16

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

LOG: Add support to -Wa,--version in clang

Clang currently only supports -Wa,--version when -no-integrated-as is
used. This adds support to -Wa,--version with -integrated-as.

Link:
https://github.com/ClangBuiltLinux/linux/issues/1320

Reviewed By: nickdesaulniers, MaskRay

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

Added: 
clang/test/Driver/as-version.s

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 804f528838c58..9d3c725198f4d 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -2549,6 +2549,8 @@ static void CollectArgsForIntegratedAssembler(Compilation 
,
 // -fdebug-compilation-dir (without '=') here.
 CmdArgs.push_back("-fdebug-compilation-dir");
 CmdArgs.push_back(Value.data());
+  } else if (Value == "--version") {
+D.PrintVersion(C, llvm::outs());
   } else {
 D.Diag(diag::err_drv_unsupported_option_argument)
 << A->getOption().getName() << Value;

diff  --git a/clang/test/Driver/as-version.s b/clang/test/Driver/as-version.s
new file mode 100644
index 0..9d2801e4ee379
--- /dev/null
+++ b/clang/test/Driver/as-version.s
@@ -0,0 +1,9 @@
+// Test version information.
+
+// RUN: %clang -Wa,--version -c -fintegrated-as %s -o /dev/null \
+// RUN:   | FileCheck --check-prefix=IAS %s
+// IAS: clang version
+
+// RUN: %clang -Wa,--version -c -fno-integrated-as %s -o /dev/null \
+// RUN:   | FileCheck --check-prefix=GAS %s
+// GAS-NOT: clang



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

[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

[Harald van Dijk via Phabricator via cfe-commits]

hvdijk updated this revision to Diff 334557.
hvdijk edited the summary of this revision.
hvdijk added a comment.

I have also updated the summary to provide a more complete explanation of the 
changes, and hope the revised summary will answer @MaskRay's questions.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D52050

Files:
  clang/lib/Driver/ToolChains/Gnu.cpp
  
clang/test/Driver/Inputs/basic_cross_linux_tree/usr/lib/gcc/i386-unknown-linux-gnu/10.2.0/crtbegin.o
  
clang/test/Driver/Inputs/basic_cross_linux_tree/usr/lib/gcc/i386-unknown-linux-gnu/4.6.0/crtbegin.o
  
clang/test/Driver/Inputs/basic_cross_linux_tree/usr/lib/gcc/x86_64-unknown-linux-gnu/10.2.0/crtbegin.o
  
clang/test/Driver/Inputs/basic_cross_linux_tree/usr/lib/gcc/x86_64-unknown-linux-gnu/10.2.0/crtbeginT.o
  
clang/test/Driver/Inputs/basic_cross_linux_tree/usr/lib/gcc/x86_64-unknown-linux-gnu/10.2.0/crtfastmath.o
  
clang/test/Driver/Inputs/basic_cross_linux_tree/usr/lib/gcc/x86_64-unknown-linux-gnu/10.2.0/x32/crtbegin.o
  
clang/test/Driver/Inputs/basic_cross_linux_tree/usr/lib/gcc/x86_64-unknown-linux-gnu/10.2.0/x32/crtbeginT.o
  
clang/test/Driver/Inputs/basic_cross_linux_tree/usr/lib/gcc/x86_64-unknown-linux-gnu/10.2.0/x32/crtfastmath.o
  
clang/test/Driver/Inputs/basic_cross_linux_tree/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/crtbegin.o
  
clang/test/Driver/Inputs/basic_cross_linux_tree/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/crtbeginT.o
  
clang/test/Driver/Inputs/basic_cross_linux_tree/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/crtfastmath.o
  
clang/test/Driver/Inputs/basic_linux_tree/usr/lib/gcc/i386-unknown-linux/10.2.0/crtbegin.o
  
clang/test/Driver/Inputs/basic_linux_tree/usr/lib/gcc/i386-unknown-linux/4.6.0/crtbegin.o
  
clang/test/Driver/Inputs/basic_linux_tree/usr/lib/gcc/i686-unknown-linux/10.2.0/crtbegin.o
  
clang/test/Driver/Inputs/basic_linux_tree/usr/lib/gcc/i686-unknown-linux/4.6.0/crtbegin.o
  
clang/test/Driver/Inputs/basic_linux_tree/usr/lib/gcc/x86_64-unknown-linux/10.2.0/crtbegin.o
  
clang/test/Driver/Inputs/basic_linux_tree/usr/lib/gcc/x86_64-unknown-linux/10.2.0/crtbeginT.o
  
clang/test/Driver/Inputs/basic_linux_tree/usr/lib/gcc/x86_64-unknown-linux/10.2.0/crtfastmath.o
  
clang/test/Driver/Inputs/basic_linux_tree/usr/lib/gcc/x86_64-unknown-linux/4.6.0/crtbegin.o
  
clang/test/Driver/Inputs/basic_linux_tree/usr/lib/gcc/x86_64-unknown-linux/4.6.0/crtbeginT.o
  
clang/test/Driver/Inputs/basic_linux_tree/usr/lib/gcc/x86_64-unknown-linux/4.6.0/crtfastmath.o
  
clang/test/Driver/Inputs/multilib_32bit_linux_tree/usr/lib/gcc/i386-unknown-linux/10.2.0/64/crtbegin.o
  
clang/test/Driver/Inputs/multilib_32bit_linux_tree/usr/lib/gcc/i386-unknown-linux/10.2.0/crtbegin.o
  
clang/test/Driver/Inputs/multilib_32bit_linux_tree/usr/lib/gcc/i386-unknown-linux/4.6.0/64/crtbegin.o
  
clang/test/Driver/Inputs/multilib_32bit_linux_tree/usr/lib/gcc/i386-unknown-linux/4.6.0/crtbegin.o
  
clang/test/Driver/Inputs/multilib_64bit_linux_tree/usr/lib/gcc/x86_64-unknown-linux/10.2.0/32/crtbegin.o
  
clang/test/Driver/Inputs/multilib_64bit_linux_tree/usr/lib/gcc/x86_64-unknown-linux/10.2.0/crtbegin.o
  
clang/test/Driver/Inputs/multilib_64bit_linux_tree/usr/lib/gcc/x86_64-unknown-linux/10.2.0/x32/crtbegin.o
  
clang/test/Driver/Inputs/multilib_64bit_linux_tree/usr/lib/gcc/x86_64-unknown-linux/4.6.0/32/crtbegin.o
  
clang/test/Driver/Inputs/multilib_64bit_linux_tree/usr/lib/gcc/x86_64-unknown-linux/4.6.0/crtbegin.o
  
clang/test/Driver/Inputs/multilib_64bit_linux_tree/usr/lib/gcc/x86_64-unknown-linux/4.6.0/x32/crtbegin.o
  clang/test/Driver/baremetal.cpp
  clang/test/Driver/cl-options.c
  clang/test/Driver/cross-linux.c
  clang/test/Driver/env.c
  clang/test/Driver/linux-ld.c
  clang/test/Preprocessor/iwithprefix.c

Index: clang/test/Preprocessor/iwithprefix.c
===
--- clang/test/Preprocessor/iwithprefix.c
+++ clang/test/Preprocessor/iwithprefix.c
@@ -9,8 +9,6 @@
 
 // CHECK: #include <...> search starts here:
 // CHECK: {{.*}}.tmps/first
-// CHECK: {{/|\\}}lib{{(32|64)?}}{{/|\\}}clang{{/|\\}}{{[.0-9]+}}{{/|\\}}include
+// CHECK: {{/|\\}}clang{{/|\\}}{{[.0-9]+}}{{/|\\}}include
 // CHECK: {{.*}}.tmps/second
 // CHECK-NOT: {{.*}}.tmps
-
-
Index: clang/test/Driver/linux-ld.c
===
--- clang/test/Driver/linux-ld.c
+++ clang/test/Driver/linux-ld.c
@@ -9,9 +9,9 @@
 // RUN:   | FileCheck --check-prefix=CHECK-LD-32 %s
 // CHECK-LD-32-NOT: warning:
 // CHECK-LD-32: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
-// CHECK-LD-32: "{{.*}}/usr/lib/gcc/i386-unknown-linux/4.6.0{{/|}}crtbegin.o"
-// CHECK-LD-32: "-L[[SYSROOT]]/usr/lib/gcc/i386-unknown-linux/4.6.0"
-// CHECK-LD-32: "-L[[SYSROOT]]/usr/lib/gcc/i386-unknown-linux/4.6.0/../../../../i386-unknown-linux/lib"
+// CHECK-LD-32: 

[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

[Harald van Dijk via Phabricator via cfe-commits]

hvdijk added a comment.

In D52050#2662570 , @glaubitz wrote:

> Since I am a big fan of consistency, I would rather leave it as is (4.6) and 
> then bump to 10.2.0 in a follow-up commit.

You are right that including the bump in this commit would either force an 
inconsistency with basic_linux_tree, multilib_32bit_linux_tree, and 
multilib_64bit_linux_tree, or include more changes in here that are not related 
to x32. However, since we have been testing for x32 support against a pretend 
installation of GCC 4.6, and GCC 4.6 actually never supported x32 (initial 
support was added in GCC 4.7), leaving it at 4.6.0 means we are testing an 
impossible scenario. I am aware that we already were doing that before as well, 
but I do not think that changes much. Personally, I am not very happy with any 
of the options here.

I am also a fan of consistency, so to me the least bad option seems to be to 
update all four at the same time, provided this does not result in an 
excessively large diff. It looks large-ish but not too bad to me; I will 
include it in the next update so that we know what sort of size we are dealing 
with. If you and @MaskRay think it is too large I can easily take it out again.

> Debian actually has a /libx32 folder, but it contains the dynamic loader only 
> which makes sense because the path to the dynamic loader is baked into the 
> executable if I remember correctly.

Right, it has a /libx32 directory for exactly that reason. 
/libx32/ld-linux-x32.so.2 only exists as a compatibility symlink though, the 
dynamic loader is really stored in /lib/x86_64-linux-gnux32.




Comment at: clang/lib/Driver/ToolChains/Gnu.cpp:2110
+  static const char *const X32Triples[] = {"x86_64-linux-gnux32",
+   "x86_64-unknown-linux-gnux32",
+   "x86_64-pc-linux-gnux32"};

glaubitz wrote:
> hvdijk wrote:
> > MaskRay wrote:
> > > Personally I'd defer adding a triplet until it is proven to be used on a 
> > > system.
> > > 
> > > This is not free, for every x86-64 user (even if they don't use multilib 
> > > or x32), their clang driver runs need to stat the directory under lib/gcc 
> > > or lib/gcc-cross.
> > For the first and last I know for a fact they are used as the GCC triple; 
> > /usr/lib/gcc/x86_64-linux-gnux32 and /usr/lib/gcc/x86_64-pc-linux-gnux32 
> > definitely both exist in the wild. For the middle, 
> > x86_64-unknown-linux-gnux32, I do know for a fact this is used as a triple 
> > (it is the only valid x32 triple for Rust), but it is possible it is not 
> > used as the GCC triple anywhere, so unless someone speaks up that this is 
> > already in use somewhere, I will take that one out.
> Isn't Rust going to use `x86_64-unknown-linux-gnux32` when invoking the C++ 
> compiler itself? I would prefer keeping it for consistency with x86_64 and to 
> avoid issues with distributions that may use that triplet.
Thankfully, Rust does not require external triples to match its own strict 
naming rules. It does not accept `x86_64-linux-gnu` or `x86_64-pc-linux-gnu` as 
a valid targets either, only `x86_64-unknown-linux-gnu`, but it still works 
fine on systems where GCC does use any of the other triple names.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D52050

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

[PATCH] D99517: Implemented [[clang::musttail]] attribute for guaranteed tail calls.

[Josh Haberman via Phabricator via cfe-commits]

haberman added a comment.

I addressed nearly all of the comments. I have just a few more test cases to 
add: Obj-C blocks and ARC.

I left one comment open re: a "regular" function. I'll dig into that more when 
I am adding the last few test cases.




Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:2832
+def err_musttail_only_from_function : Error<
+  "%0 attribute can only be used from a regular function.">;
+def err_musttail_return_type_mismatch : Error<

aaron.ballman wrote:
> What is a "regular function?"
I may have been trying to distinguish between blocks, or lambdas, I can't 
exactly remember.

I think I still need to add tests for blocks and Obj-C refcounts. I'm going to 
leave this comment open for now as a reminder to revisit this.



Comment at: clang/lib/CodeGen/CGCall.cpp:5315-5317
+// TODO(haberman): insert checks/assertions to verify that this early exit
+// is safe. We tried to verify this in Sema but we should double-check
+// here.

aaron.ballman wrote:
> Are you planning to handle this TODO in the patch? If not, can you switch to 
> a FIXME without a name associated with it?
I am interested in feedback on the best way to proceed here.

  - Is my assessment correct that we should have an assertion that validates 
this?
  - Is such an assertion reasonably feasible to implement?
  - Is it ok to defer with FIXME, or should I try to fix it in this patch?

I've changed it to a FIXME for now.



Comment at: clang/lib/Sema/SemaStmt.cpp:561-568
+  for (const auto *A : Attrs) {
+if (A->getKind() == attr::MustTail) {
+  if (!checkMustTailAttr(SubStmt, *A)) {
+return SubStmt;
+  }
+  setFunctionHasMustTail();
+}

aaron.ballman wrote:
> This functionality belongs in SemaStmtAttr.cpp, I think.
That is where I had originally put it, but that didn't work for templates. The 
semantic checks can only be performed at instantiation time. 
`ActOnAttributedStmt` seems to be the right hook point where I can evaluate the 
semantic checks for both template and non-template functions (with template 
functions getting checked at instantiation time).



Comment at: clang/lib/Sema/SemaStmt.cpp:620
+const CXXMethodDecl *CMD = dyn_cast(mem->getMemberDecl());
+assert(CMD && !CMD->isStatic());
+CalleeThis = CMD->getThisType()->getPointeeType();

aaron.ballman wrote:
> Is this assertion valid? Consider:
> ```
> struct S {
>   static int foo();
> };
> 
> int bar() {
>   S s;
>   [[clang::musttail]] return s.foo();
> }
> ```
I have a test for that in `CodeGen/attr-musttail.cpp` (see `Func4()`). It 
appears that this goes through `FunctionToPointerDecay` and ends up getting 
handled by the function case below.



Comment at: clang/lib/Sema/SemaStmt.cpp:665-666
+ArrayRef caller_params = CallerDecl->parameters();
+size_t n = CallerDecl->param_size();
+for (size_t i = 0; i < n; i++) {
+  if (!TypesMatch(callee_params[i], caller_params[i]->getType())) {

aaron.ballman wrote:
> How do you want to handle variadic function calls?
I added a check to disallow variadic function calls.



Comment at: clang/test/Sema/attr-musttail.cpp:17
+long g(int x);
+int h(long x);
+

aaron.ballman wrote:
> I'd appreciate a test of promotion behavior:
> ```
> int i(int x);
> int s(short x);
> 
> int whatever1(int x) {
>   [[clang::musttail]] return s(x);
> }
> 
> int whatever2(short x) {
>   [[clang::musttail]] return i(x);
> }
> ```
Done (my understanding is that these should both fail, since they would violate 
the LLVM rules that the caller and callee prototypes must match).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99517

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

[PATCH] D99517: Implemented [[clang::musttail]] attribute for guaranteed tail calls.

[Josh Haberman via Phabricator via cfe-commits]

haberman updated this revision to Diff 334556.
haberman marked 37 inline comments as done.
haberman added a comment.

- Expanded and refined the semantic checks for musttail, per CR feedback.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99517

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/ScopeInfo.h
  clang/include/clang/Sema/Sema.h
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/CodeGen/CGExpr.cpp
  clang/lib/CodeGen/CGStmt.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/lib/Sema/JumpDiagnostics.cpp
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaStmt.cpp
  clang/lib/Sema/SemaStmtAttr.cpp
  clang/test/CodeGen/attr-musttail.cpp
  clang/test/Sema/attr-musttail.c
  clang/test/Sema/attr-musttail.cpp

Index: clang/test/Sema/attr-musttail.cpp
===
--- /dev/null
+++ clang/test/Sema/attr-musttail.cpp
@@ -0,0 +1,129 @@
+// RUN: %clang_cc1 -verify -fsyntax-only %s
+
+int ReturnsInt1();
+int Func1() {
+  [[clang::musttail]] ReturnsInt1();   // expected-error {{'musttail' attribute only applies to return statements}}
+  [[clang::musttail(1, 2)]] return ReturnsInt1(); // expected-error {{'musttail' attribute takes no arguments}}
+  [[clang::musttail]] return 5;// expected-error {{'musttail' attribute requires that the return value is the result of a function call}}
+  [[clang::musttail]] return ReturnsInt1();
+}
+
+[[clang::musttail]] static int int_val = ReturnsInt1(); // expected-error {{'musttail' attribute cannot be applied to a declaration}}
+
+void NoParams(); // expected-note {{target function has different number of parameters (expected 1 but has 0)}}
+void TestParamArityMismatch(int x) {
+  [[clang::musttail]] return NoParams(); // expected-error {{'musttail' attribute requires that caller and callee have compatible function signatures}}
+}
+
+void LongParam(long x); // expected-note {{target function has type mismatch at 1st parameter (expected 'long' but has 'int')}}
+void TestParamTypeMismatch(int x) {
+  [[clang::musttail]] return LongParam(x); // expected-error {{'musttail' attribute requires that caller and callee have compatible function signatures}}
+}
+
+long ReturnsLong(); // expected-note {{target function has different return type ('int' expected but has 'long')}}
+int TestReturnTypeMismatch() {
+  [[clang::musttail]] return ReturnsLong(); // expected-error {{'musttail' attribute requires that caller and callee have compatible function signatures}}
+}
+
+struct Struct1 {
+  void MemberFunction(); // expected-note {{target function has different class (expected 'void' but has 'Struct1')}}
+};
+void TestNonMemberToMember() {
+  Struct1 st;
+  [[clang::musttail]] return st.MemberFunction(); // expected-error {{'musttail' attribute requires that caller and callee have compatible function signatures}}
+}
+
+void ReturnsVoid(); // expected-note {{target function has different class (expected 'Struct2' but has 'void')}}
+struct Struct2 {
+  void TestMemberToNonMember() {
+[[clang::musttail]] return ReturnsVoid(); // expected-error{{'musttail' attribute requires that caller and callee have compatible function signatures}}
+  }
+};
+
+class HasNonTrivialDestructor {
+public:
+  ~HasNonTrivialDestructor() {}
+};
+
+void ReturnsVoid2();
+void TestNonTrivialDestructorInScope() {
+  HasNonTrivialDestructor foo;  // expected-note {{jump exits scope of variable with non-trivial destructor}}
+  [[clang::musttail]] return ReturnsVoid(); // expected-error {{'musttail' attribute requires that all variables in scope are trivially destructible}}
+}
+
+int NonTrivialParam(HasNonTrivialDestructor x);
+int TestNonTrivialParam(HasNonTrivialDestructor x) {
+  [[clang::musttail]] return NonTrivialParam(x); // expected-error {{'musttail' attribute requires that the return type and all arguments are trivially destructible}}
+}
+
+HasNonTrivialDestructor ReturnsNonTrivialValue();
+HasNonTrivialDestructor TestReturnsNonTrivialValue() {
+  [[clang::musttail]] return ReturnsNonTrivialValue(); // expected-error {{'musttail' attribute requires that the return type and all arguments are trivially destructible}}
+}
+
+struct UsesPointerToMember {
+  void (UsesPointerToMember::*p_mem)();
+};
+void TestUsesPointerToMember(UsesPointerToMember *foo) {
+  // "this" pointer cannot double as first parameter.
+  [[clang::musttail]] return (foo->*(foo->p_mem))(); // expected-error {{'musttail' attribute requires that caller and callee have compatible function signatures}} expected-note{{target function has different class (expected 'void' but has 'UsesPointerToMember')}}
+}
+
+void ReturnsVoid2();
+void TestNestedClass() {
+  HasNonTrivialDestructor foo;
+  class Nested {
+__attribute__((noinline)) static void NestedMethod() {
+  // Outer non-trivial 

[PATCH] D99661: [SemaObjC] Fix a -Wbridge-cast false-positive

[Akira Hatanaka via Phabricator via cfe-commits]

ahatanak added a comment.

I see a warning when I compile the following (contrived) example:

  typedef const struct __attribute__((objc_bridge(NSError))) __CFString * 
CFStringRef;
  
  extern "C" {
typedef const struct __attribute__((objc_bridge(NSString))) __CFString * 
CFStringRef;
  }
  
  @interface NSString @end
  @interface NSError @end
  
  void CFStringGetLength(CFStringRef theString);
  
  int main() {
CFStringGetLength((__bridge CFStringRef)(NSString *)0);
  }

Should we try to restore the behavior prior to 
https://reviews.llvm.org/rG09abecef7bbfda18d34f046954eaa4d491062839 as much as 
we can? Or that's not important?


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

https://reviews.llvm.org/D99661

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

[PATCH] D89013: [libcxx] Support per-target __config_site in per-target runtime build

[Petr Hosek via Phabricator via cfe-commits]

phosek added inline comments.



Comment at: clang/lib/Driver/ToolChains/Fuchsia.cpp:379
+
+// Second add the generic one.
+P.assign(Path);

ldionne wrote:
> Doesn't that break `#include_next` if both directories exist? Generally 
> speaking, I think you only ever want to have a single directory containing 
> the libc++ headers on your header search path.
See my comment, the per-target include path will only contain `__config_site` 
whereas the generic one contains all the headers other than `__config_site` so 
this works fine. It would even work if you had another copy of `__config_site` 
in the generic one which may be useful on platforms that don't currently 
support the multiarch layout like Darwin.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89013

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

[PATCH] D89013: [libcxx] Support per-target __config_site in per-target runtime build

[Petr Hosek via Phabricator via cfe-commits]

phosek added a comment.

In D89013#2662434 , @ldionne wrote:

> I'm personally not so concerned with the Clang driver side of things, but 
> primarily with adding more complexity to the libc++ build. Shouldn't we be 
> driving things from the runtimes build and setting a different 
> `CMAKE_INSTALL_PREFIX` to install stuff to the right location instead? Then 
> you can run N builds of libc++ for N targets, each setting the appropriate 
> install path.

We could do that but problem with the approach is that we would end up 
duplicating all headers across targets. Since all headers except 
`__config_site` should be the same, we only want to have per-target version of 
that header which is what this change is doing. The final directory layout you 
end up with:

  include/
c++/
  v1/

x86_64-linux-gnu/
  c++/
v1/
  __config_site


This is the most optimal layout but I don't think it's something we can achieve 
purely with `CMAKE_INSTALL_PREFIX` without additional build support.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89013

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

[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added inline comments.



Comment at: clang/lib/Driver/ToolChains/Gnu.cpp:2110
+  static const char *const X32Triples[] = {"x86_64-linux-gnux32",
+   "x86_64-unknown-linux-gnux32",
+   "x86_64-pc-linux-gnux32"};

hvdijk wrote:
> MaskRay wrote:
> > Personally I'd defer adding a triplet until it is proven to be used on a 
> > system.
> > 
> > This is not free, for every x86-64 user (even if they don't use multilib or 
> > x32), their clang driver runs need to stat the directory under lib/gcc or 
> > lib/gcc-cross.
> For the first and last I know for a fact they are used as the GCC triple; 
> /usr/lib/gcc/x86_64-linux-gnux32 and /usr/lib/gcc/x86_64-pc-linux-gnux32 
> definitely both exist in the wild. For the middle, 
> x86_64-unknown-linux-gnux32, I do know for a fact this is used as a triple 
> (it is the only valid x32 triple for Rust), but it is possible it is not used 
> as the GCC triple anywhere, so unless someone speaks up that this is already 
> in use somewhere, I will take that one out.
Isn't Rust going to use `x86_64-unknown-linux-gnux32` when invoking the C++ 
compiler itself? I would prefer keeping it for consistency with x86_64 and to 
avoid issues with distributions that may use that triplet.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D52050

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

[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

In D52050#2662440 , @hvdijk wrote:

> In D52050#2662372 , @MaskRay wrote:
>
>> Mostly looks good.
>>
>>> `clang/test/Driver/Inputs/basic_cross_linux_tree/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/x32/crtbegin.o`
>>
>> Worth bumping the version. 4.6 is quite old and as a host compiler 
>> llvm-project has stopped supporting it. The distributions having 4.6 are all 
>> end-of-life.
>> Using a new version (matching your reality) can give impression that the 
>> user who contributed the original code may still need it for a while (say 5 
>> years).
>
> Sure, there should be no harm in renaming 4.6.0 to the current version, 
> 10.2.0, will do that and re-test.

Since I am a big fan of consistency, I would rather leave it as is (4.6) and 
then bump to 10.2.0 in a follow-up commit.

>> I still don't quite understand this. Shouldn't a native x32 port use 
>> `x86_64-unknown-linux-gnux32`? Why does it use the multilib style `/x32` 
>> suffix?
>
> Apologies for the confusion, that is my fault. @glaubitz opened this change 
> to make things work for Debian, which uses `lib/x86_64-linux-gnux32`, but I 
> am testing both Debian and non-Debian. Non-Debian uses `libx32`, similarly to 
> how x86_64-linux-gnu uses `lib64` regardless of whether any 32-bit libraries 
> are installed. (Edit: I may have misunderstood your comment. There's also the 
> `/x32` subdirectory inside GCC installs, but these are not used for native 
> x32 systems. This is only used for i*86-linux-gnu and x86_64-linux-gnu 
> compilers with multilib support for x32, both on Debian and on non-Debian 
> systems, and is covered by existing tests.)

Debian actually has a /libx32 folder, but it contains the dynamic loader only 
which makes sense because the path to the dynamic loader is baked into the 
executable if I remember correctly.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D52050

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

[PATCH] D89013: [libcxx] Support per-target __config_site in per-target runtime build

[Petr Hosek via Phabricator via cfe-commits]

phosek updated this revision to Diff 334550.
Herald added subscribers: frasercrmck, luismarques, apazos, sameer.abuasal, 
Jim, jocewei, PkmX, the_o, brucehoult, MartinMosbeck, rogfer01, edward-jones, 
zzheng, jrtc27, niosHD, sabuasal, johnrusso, rbar, asb.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89013

Files:
  clang/lib/Driver/ToolChains/Fuchsia.cpp
  clang/lib/Driver/ToolChains/Gnu.cpp
  
clang/test/Driver/Inputs/basic_fuchsia_tree/include/aarch64-unknown-fuchsia/c++/v1/.keep
  
clang/test/Driver/Inputs/basic_fuchsia_tree/include/riscv64-unknown-fuchsia/c++/v1/.keep
  
clang/test/Driver/Inputs/basic_fuchsia_tree/include/x86_64-unknown-fuchsia/c++/v1/.keep
  
clang/test/Driver/Inputs/basic_linux_libcxx_tree/usr/include/x86_64-linux-gnu/c++/v1/.keep
  
clang/test/Driver/Inputs/basic_linux_libcxxv2_tree/usr/include/x86_64-linux-gnu/c++/v2/.keep
  
clang/test/Driver/Inputs/basic_linux_libstdcxx_libcxxv2_tree/usr/include/x86_64-linux-gnu/c++/v2/.keep
  clang/test/Driver/fuchsia.cpp
  clang/test/Driver/linux-header-search.cpp
  libcxx/CMakeLists.txt
  libcxx/benchmarks/CMakeLists.txt
  libcxx/include/CMakeLists.txt

Index: libcxx/include/CMakeLists.txt
===
--- libcxx/include/CMakeLists.txt
+++ libcxx/include/CMakeLists.txt
@@ -191,9 +191,9 @@
   wctype.h
   )
 
-configure_file("__config_site.in" "${LIBCXX_GENERATED_INCLUDE_DIR}/__config_site" @ONLY)
+configure_file("__config_site.in" "${LIBCXX_GENERATED_INCLUDE_TARGET_DIR}/__config_site" @ONLY)
 
-set(_all_includes "${LIBCXX_GENERATED_INCLUDE_DIR}/__config_site")
+set(_all_includes "${LIBCXX_GENERATED_INCLUDE_TARGET_DIR}/__config_site")
 foreach(f ${files})
   set(src "${CMAKE_CURRENT_SOURCE_DIR}/${f}")
   set(dst "${LIBCXX_GENERATED_INCLUDE_DIR}/${f}")
@@ -210,24 +210,26 @@
 add_dependencies(cxx-headers generate-cxx-headers ${LIBCXX_CXX_ABI_HEADER_TARGET})
 # TODO: Use target_include_directories once we figure out why that breaks the runtimes build
 if("${CMAKE_CXX_COMPILER_ID}" STREQUAL "MSVC" OR "${CMAKE_CXX_SIMULATE_ID}" STREQUAL "MSVC")
-  target_compile_options(cxx-headers INTERFACE /I "${LIBCXX_GENERATED_INCLUDE_DIR}")
+  target_compile_options(cxx-headers INTERFACE /I "${LIBCXX_GENERATED_INCLUDE_DIR}"
+ INTERFACE /I "${LIBCXX_GENERATED_INCLUDE_TARGET_DIR}")
 else()
-  target_compile_options(cxx-headers INTERFACE -I "${LIBCXX_GENERATED_INCLUDE_DIR}")
+  target_compile_options(cxx-headers INTERFACE -I${LIBCXX_GENERATED_INCLUDE_DIR}
+ INTERFACE -I${LIBCXX_GENERATED_INCLUDE_TARGET_DIR})
 endif()
 
 if (LIBCXX_INSTALL_HEADERS)
   foreach(file ${files})
 get_filename_component(dir ${file} DIRECTORY)
 install(FILES ${file}
-  DESTINATION ${LIBCXX_INSTALL_HEADER_PREFIX}include/c++/v1/${dir}
+  DESTINATION ${LIBCXX_INSTALL_HEADER_PREFIX}${LIBCXX_INSTALL_HEADER_DIR}/${dir}
   COMPONENT cxx-headers
   PERMISSIONS OWNER_READ OWNER_WRITE GROUP_READ WORLD_READ
 )
   endforeach()
 
   # Install the generated __config_site.
-  install(FILES ${LIBCXX_GENERATED_INCLUDE_DIR}/__config_site
-DESTINATION ${LIBCXX_INSTALL_HEADER_PREFIX}include/c++/v1
+  install(FILES ${LIBCXX_GENERATED_INCLUDE_TARGET_DIR}/__config_site
+DESTINATION ${LIBCXX_INSTALL_HEADER_PREFIX}${LIBCXX_INSTALL_INCLUDE_TARGET_DIR}
 PERMISSIONS OWNER_READ OWNER_WRITE GROUP_READ WORLD_READ
 COMPONENT cxx-headers)
 
Index: libcxx/benchmarks/CMakeLists.txt
===
--- libcxx/benchmarks/CMakeLists.txt
+++ libcxx/benchmarks/CMakeLists.txt
@@ -15,6 +15,10 @@
 -Wl,-rpath,${LIBCXX_LIBRARY_DIR}
 ${SANITIZER_FLAGS}
 )
+if(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR AND NOT APPLE)
+  list(APPEND BENCHMARK_LIBCXX_COMPILE_FLAGS
+-isystem "${LIBCXX_GENERATED_INCLUDE_TARGET_DIR}")
+endif()
 if (DEFINED LIBCXX_CXX_ABI_LIBRARY_PATH)
   list(APPEND BENCHMARK_LIBCXX_COMPILE_FLAGS
   -L${LIBCXX_CXX_ABI_LIBRARY_PATH}
Index: libcxx/CMakeLists.txt
===
--- libcxx/CMakeLists.txt
+++ libcxx/CMakeLists.txt
@@ -408,7 +408,10 @@
 if(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR AND NOT APPLE)
   set(LIBCXX_LIBRARY_DIR ${LLVM_LIBRARY_OUTPUT_INTDIR}/${LLVM_DEFAULT_TARGET_TRIPLE}/c++)
   set(LIBCXX_GENERATED_INCLUDE_DIR "${LLVM_BINARY_DIR}/include/c++/v1")
+  set(LIBCXX_GENERATED_INCLUDE_TARGET_DIR "${LLVM_BINARY_DIR}/include/${LLVM_DEFAULT_TARGET_TRIPLE}/c++/v1")
   set(LIBCXX_INSTALL_LIBRARY_DIR lib${LLVM_LIBDIR_SUFFIX}/${LLVM_DEFAULT_TARGET_TRIPLE}/c++)
+  set(LIBCXX_INSTALL_INCLUDE_DIR "include/c++/v1")
+  set(LIBCXX_INSTALL_INCLUDE_TARGET_DIR "include/${LLVM_DEFAULT_TARGET_TRIPLE}/c++/v1")
   if(LIBCXX_LIBDIR_SUBDIR)
 string(APPEND LIBCXX_LIBRARY_DIR /${LIBCXX_LIBDIR_SUBDIR})
 string(APPEND LIBCXX_INSTALL_LIBRARY_DIR 

[PATCH] D99689: [OPENMP]Add option -fopenmp-cuda-const-firstprivate to control address space of the corresponding global.

[Alexey Bataev via Phabricator via cfe-commits]

ABataev created this revision.
ABataev added a reviewer: jdoerfert.
Herald added subscribers: jansvoboda11, dexonsmith, dang, guansong, yaxunl.
ABataev requested review of this revision.
Herald added a subscriber: sstefan1.
Herald added a project: clang.

Added options -f-[no]openmp-cuda-const-firstprivate to control the
address space of the the corresponding global variable, created for the
target firstprivate variable. Disabled by default.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D99689

Files:
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/lib/CodeGen/CGStmtOpenMP.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/Driver/openmp-offload-gpu.c
  clang/test/OpenMP/nvptx_target_firstprivate_codegen.cpp

Index: clang/test/OpenMP/nvptx_target_firstprivate_codegen.cpp
===
--- clang/test/OpenMP/nvptx_target_firstprivate_codegen.cpp
+++ clang/test/OpenMP/nvptx_target_firstprivate_codegen.cpp
@@ -1,8 +1,10 @@
 // Test target codegen - host bc file has to be created first.
 // RUN: %clang_cc1 -verify -fopenmp -x c++ -triple powerpc64le-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm-bc %s -o %t-ppc-host.bc
-// RUN: %clang_cc1 -debug-info-kind=limited -verify -fopenmp -x c++ -triple nvptx64-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm %s -fopenmp-is-device -fopenmp-host-ir-file-path %t-ppc-host.bc -o - | FileCheck %s --check-prefix TCHECK --check-prefix TCHECK-64
+// RUN: %clang_cc1 -debug-info-kind=limited -verify -fopenmp -x c++ -triple nvptx64-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm %s -fopenmp-is-device -fopenmp-host-ir-file-path %t-ppc-host.bc -o - | FileCheck %s --check-prefix TCHECK --check-prefix TCHECK-64 --check-prefix TCHECK-NONCONST
+// RUN: %clang_cc1 -debug-info-kind=limited -verify -fopenmp -x c++ -triple nvptx64-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm %s -fopenmp-is-device -fopenmp-cuda-const-firstprivate -fopenmp-host-ir-file-path %t-ppc-host.bc -o - | FileCheck %s --check-prefix TCHECK --check-prefix TCHECK-64 --check-prefix TCHECK-CONST
 // RUN: %clang_cc1 -verify -fopenmp -x c++ -triple i386-unknown-unknown -fopenmp-targets=nvptx-nvidia-cuda -emit-llvm-bc %s -o %t-x86-host.bc
-// RUN: %clang_cc1 -debug-info-kind=limited -verify -fopenmp -x c++ -triple nvptx-unknown-unknown -fopenmp-targets=nvptx-nvidia-cuda -emit-llvm %s -fopenmp-is-device -fopenmp-host-ir-file-path %t-x86-host.bc -o - | FileCheck %s --check-prefix TCHECK --check-prefix TCHECK-32
+// RUN: %clang_cc1 -debug-info-kind=limited -verify -fopenmp -x c++ -triple nvptx-unknown-unknown -fopenmp-targets=nvptx-nvidia-cuda -emit-llvm %s -fopenmp-is-device -fopenmp-host-ir-file-path %t-x86-host.bc -o - | FileCheck %s --check-prefix TCHECK --check-prefix TCHECK-32 --check-prefix TCHECK-NONCONST
+// RUN: %clang_cc1 -debug-info-kind=limited -verify -fopenmp -x c++ -triple nvptx-unknown-unknown -fopenmp-targets=nvptx-nvidia-cuda -emit-llvm %s -fopenmp-is-device -fopenmp-cuda-const-firstprivate -fopenmp-host-ir-file-path %t-x86-host.bc -o - | FileCheck %s --check-prefix TCHECK --check-prefix TCHECK-32 --check-prefix TCHECK-CONST
 // expected-no-diagnostics
 #ifndef HEADER
 #define HEADER
@@ -17,7 +19,8 @@
 // TCHECK-DAG:  [[TTII:%.+]] = type { i32, i32 }
 // TCHECK-DAG:  [[S1:%.+]] = type { double }
 
-// TCHECK: @__omp_offloading_firstprivate__{{.+}}_e_l27 = internal addrspace(4) global [[TTII]] zeroinitializer
+// TCHECK-NONCONST-NOT: @__omp_offloading_firstprivate__{{.+}}_e_l30
+// TCHECK-CONST:@__omp_offloading_firstprivate__{{.+}}_e_l30 = internal addrspace(4) global [[TTII]] zeroinitializer
 int foo(int n, double *ptr) {
   int a = 0;
   short aa = 0;
@@ -36,7 +39,8 @@
   // TCHECK:  define {{.*}}void @__omp_offloading_{{.+}}([10 x float] addrspace(1)* noalias [[B_IN:%.+]], i{{[0-9]+}} [[A_IN:%.+]], [[TTII]]* noalias [[E_IN:%.+]])
   // TCHECK-NOT: alloca [[TTII]],
   // TCHECK:  [[A_ADDR:%.+]] = alloca i{{[0-9]+}},
-  // TCHECK-NOT: alloca [[TTII]],
+  // TCHECK-NONCONST: alloca [[TTII]],
+  // TCHECK-CONST-NOT: alloca [[TTII]],
   // TCHECK-NOT: alloca i{{[0-9]+}},
   // TCHECK-64:  call void @llvm.dbg.declare(metadata [10 x float] addrspace(1)** %{{.+}}, metadata !{{[0-9]+}}, metadata !DIExpression())
   // TCHECK:  store i{{[0-9]+}} [[A_IN]], i{{[0-9]+}}* [[A_ADDR]],
Index: clang/test/Driver/openmp-offload-gpu.c
===
--- clang/test/Driver/openmp-offload-gpu.c
+++ clang/test/Driver/openmp-offload-gpu.c
@@ -281,6 +281,26 @@
 // RUN:   | FileCheck -check-prefix=NO_CUDA_MODE %s
 // NO_CUDA_MODE-NOT: "-{{fno-|f}}openmp-cuda-mode"
 
+// RUN:   %clang -### -no-canonical-prefixes -fopenmp=libomp -fopenmp-targets=nvptx64-nvidia-cuda -Xopenmp-target -march=sm_60 %s 

[PATCH] D99688: [CUDA][HIP] rename -fcuda-flush-denormals-to-zero

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl created this revision.
yaxunl added a reviewer: tra.
Herald added subscribers: jansvoboda11, dang, kerbowa, nhaehnle, jvesely.
yaxunl requested review of this revision.

Rename it to -fgpu-flush-denormals-to-zero


https://reviews.llvm.org/D99688

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/AMDGPU.cpp
  clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
  clang/lib/Driver/ToolChains/Cuda.cpp
  clang/lib/Driver/ToolChains/HIP.cpp
  clang/test/CodeGenCUDA/flush-denormals.cu
  clang/test/Driver/cuda-flush-denormals-to-zero.cu
  clang/test/Driver/hip-device-libs.hip

Index: clang/test/Driver/hip-device-libs.hip
===
--- clang/test/Driver/hip-device-libs.hip
+++ clang/test/Driver/hip-device-libs.hip
@@ -24,7 +24,7 @@
 // Test explicit flag, opposite of target default.
 // RUN: %clang -### -target x86_64-linux-gnu \
 // RUN:   --cuda-gpu-arch=gfx900 \
-// RUN:   -fcuda-flush-denormals-to-zero \
+// RUN:   -fgpu-flush-denormals-to-zero \
 // RUN:   --rocm-path=%S/Inputs/rocm \
 // RUN:   %S/Inputs/hip_multiple_inputs/b.hip \
 // RUN: 2>&1 | FileCheck %s --check-prefixes=ALL,FLUSHD
@@ -33,7 +33,7 @@
 // Test explicit flag, opposite of target default.
 // RUN: %clang -### -target x86_64-linux-gnu \
 // RUN:   --cuda-gpu-arch=gfx803 \
-// RUN:   -fno-cuda-flush-denormals-to-zero \
+// RUN:   -fno-gpu-flush-denormals-to-zero \
 // RUN:   --rocm-path=%S/Inputs/rocm \
 // RUN:   %S/Inputs/hip_multiple_inputs/b.hip \
 // RUN: 2>&1 | FileCheck %s --check-prefixes=ALL,NOFLUSHD
@@ -42,7 +42,7 @@
 // Test explicit flag, same as target default.
 // RUN: %clang -### -target x86_64-linux-gnu \
 // RUN:   --cuda-gpu-arch=gfx900 \
-// RUN:   -fno-cuda-flush-denormals-to-zero \
+// RUN:   -fno-gpu-flush-denormals-to-zero \
 // RUN:   --rocm-path=%S/Inputs/rocm \
 // RUN:   %S/Inputs/hip_multiple_inputs/b.hip \
 // RUN: 2>&1 | FileCheck %s --check-prefixes=ALL,NOFLUSHD
@@ -51,7 +51,7 @@
 // Test explicit flag, same as target default.
 // RUN: %clang -### -target x86_64-linux-gnu \
 // RUN:   --cuda-gpu-arch=gfx803 \
-// RUN:   -fcuda-flush-denormals-to-zero \
+// RUN:   -fgpu-flush-denormals-to-zero \
 // RUN:   --rocm-path=%S/Inputs/rocm \
 // RUN:   %S/Inputs/hip_multiple_inputs/b.hip \
 // RUN: 2>&1 | FileCheck %s --check-prefixes=ALL,FLUSHD
@@ -60,7 +60,7 @@
 // Test last flag wins, not flushing
 // RUN: %clang -### -target x86_64-linux-gnu \
 // RUN:   --cuda-gpu-arch=gfx803 \
-// RUN:   -fcuda-flush-denormals-to-zero -fno-cuda-flush-denormals-to-zero \
+// RUN:   -fgpu-flush-denormals-to-zero -fno-gpu-flush-denormals-to-zero \
 // RUN:   --rocm-path=%S/Inputs/rocm \
 // RUN:   %S/Inputs/hip_multiple_inputs/b.hip \
 // RUN: 2>&1 | FileCheck %s --check-prefixes=ALL,NOFLUSHD
@@ -68,7 +68,7 @@
 
 // RUN: %clang -### -target x86_64-linux-gnu \
 // RUN:   --cuda-gpu-arch=gfx900 \
-// RUN:   -fcuda-flush-denormals-to-zero -fno-cuda-flush-denormals-to-zero \
+// RUN:   -fgpu-flush-denormals-to-zero -fno-gpu-flush-denormals-to-zero \
 // RUN:   --rocm-path=%S/Inputs/rocm   \
 // RUN:   %S/Inputs/hip_multiple_inputs/b.hip \
 // RUN: 2>&1 | FileCheck %s --check-prefixes=ALL,NOFLUSHD
@@ -76,7 +76,7 @@
 
 // RUN: %clang -### -target x86_64-linux-gnu \
 // RUN:   --cuda-gpu-arch=gfx900 \
-// RUN:   -fno-cuda-flush-denormals-to-zero -fcuda-flush-denormals-to-zero \
+// RUN:   -fno-gpu-flush-denormals-to-zero -fgpu-flush-denormals-to-zero \
 // RUN:   --rocm-path=%S/Inputs/rocm   \
 // RUN:   %S/Inputs/hip_multiple_inputs/b.hip \
 // RUN: 2>&1 | FileCheck %s --check-prefixes=ALL,FLUSHD
@@ -84,7 +84,7 @@
 
 // RUN: %clang -### -target x86_64-linux-gnu \
 // RUN:   --cuda-gpu-arch=gfx803 \
-// RUN:   -fno-cuda-flush-denormals-to-zero -fcuda-flush-denormals-to-zero \
+// RUN:   -fno-gpu-flush-denormals-to-zero -fgpu-flush-denormals-to-zero \
 // RUN:   --rocm-path=%S/Inputs/rocm \
 // RUN:   %S/Inputs/hip_multiple_inputs/b.hip \
 // RUN: 2>&1 | FileCheck %s --check-prefixes=ALL,FLUSHD
Index: clang/test/Driver/cuda-flush-denormals-to-zero.cu
===
--- clang/test/Driver/cuda-flush-denormals-to-zero.cu
+++ clang/test/Driver/cuda-flush-denormals-to-zero.cu
@@ -1,22 +1,22 @@
 // Checks that cuda compilation does the right thing when passed
-// -fcuda-flush-denormals-to-zero. This should be translated to
+// -fgpu-flush-denormals-to-zero. This should be translated to
 // -fdenormal-fp-math-f32=preserve-sign
 
-// RUN: %clang -no-canonical-prefixes -### -target x86_64-linux-gnu -c -march=haswell --cuda-gpu-arch=sm_20 -fcuda-flush-denormals-to-zero -nocudainc -nocudalib %s 2>&1 | FileCheck -check-prefix=FTZ %s
-// RUN: %clang -no-canonical-prefixes -### -target x86_64-linux-gnu -c -march=haswell --cuda-gpu-arch=sm_20 -fno-cuda-flush-denormals-to-zero -nocudainc -nocudalib %s 2>&1 | FileCheck -check-prefix=NOFTZ %s
-// RUN: %clang -no-canonical-prefixes -### -target x86_64-linux-gnu -c 

[PATCH] D99646: [clang-tidy] misc-std-stream-objects-outside-main: a new check

[Eugene Zelenko via Phabricator via cfe-commits]

Eugene.Zelenko added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/misc/StdStreamObjectsOutsideMainCheck.h:30
+return LangOpts.CPlusPlus;
+  };
+

Semicolon is not needed and should cause `-Wextra-semi` warnings.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99646

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

[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

[Harald van Dijk via Phabricator via cfe-commits]

hvdijk added a comment.

In D52050#2662372 , @MaskRay wrote:

> Mostly looks good.
>
>> `clang/test/Driver/Inputs/basic_cross_linux_tree/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/x32/crtbegin.o`
>
> Worth bumping the version. 4.6 is quite old and as a host compiler 
> llvm-project has stopped supporting it. The distributions having 4.6 are all 
> end-of-life.
> Using a new version (matching your reality) can give impression that the user 
> who contributed the original code may still need it for a while (say 5 years).

Sure, there should be no harm in renaming 4.6.0 to the current version, 10.2.0, 
will do that and re-test.

> I still don't quite understand this. Shouldn't a native x32 port use 
> `x86_64-unknown-linux-gnux32`? Why does it use the multilib style `/x32` 
> suffix?

Apologies for the confusion, that is my fault. @glaubitz opened this change to 
make things work for Debian, which uses `lib/x86_64-linux-gnux32`, but I am 
testing both Debian and non-Debian. Non-Debian uses `libx32`, similarly to how 
x86_64-linux-gnu uses `lib64` regardless of whether any 32-bit libraries are 
installed.




Comment at: clang/lib/Driver/ToolChains/Gnu.cpp:2110
+  static const char *const X32Triples[] = {"x86_64-linux-gnux32",
+   "x86_64-unknown-linux-gnux32",
+   "x86_64-pc-linux-gnux32"};

MaskRay wrote:
> Personally I'd defer adding a triplet until it is proven to be used on a 
> system.
> 
> This is not free, for every x86-64 user (even if they don't use multilib or 
> x32), their clang driver runs need to stat the directory under lib/gcc or 
> lib/gcc-cross.
For the first and last I know for a fact they are used as the GCC triple; 
/usr/lib/gcc/x86_64-linux-gnux32 and /usr/lib/gcc/x86_64-pc-linux-gnux32 
definitely both exist in the wild. For the middle, x86_64-unknown-linux-gnux32, 
I do know for a fact this is used as a triple (it is the only valid x32 triple 
for Rust), but it is possible it is not used as the GCC triple anywhere, so 
unless someone speaks up that this is already in use somewhere, I will take 
that one out.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D52050

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

[PATCH] D89013: [libcxx] Support per-target __config_site in per-target runtime build

[Louis Dionne via Phabricator via cfe-commits]

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

I'm personally not so concerned with the Clang driver side of things, but 
primarily with adding more complexity to the libc++ build. Shouldn't we be 
driving things from the runtimes build and setting a different 
`CMAKE_INSTALL_PREFIX` to install stuff to the right location instead? Then you 
can run N builds of libc++ for N targets, each setting the appropriate install 
path.




Comment at: clang/lib/Driver/ToolChains/Fuchsia.cpp:379
+
+// Second add the generic one.
+P.assign(Path);

Doesn't that break `#include_next` if both directories exist? Generally 
speaking, I think you only ever want to have a single directory containing the 
libc++ headers on your header search path.


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

https://reviews.llvm.org/D89013

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

[PATCH] D99037: [Matrix] Implement explicit type conversions for matrix types

[Florian Hahn via Phabricator via cfe-commits]

fhahn added a comment.

In D99037#2659477 , @SaurabhJha wrote:

>> What code do you want to get out of this?  Are there e.g. vectorized 
>> float->double conversions we can use, or is the operation basically doomed 
>> to break the matrix apart and put it back together again?
>
> I think because matrices are vectors underneath, we should try vectorised 
> conversions.

I think there should be vector versions of common conversions in most modern 
vector instruction sets, e.g. both ARM64 and X86 (with varying levels of 
support, depending on the supported vector extensions) have vector instructions 
for sign extend i32 -> i64 and floating point extension float -> double: 
https://godbolt.org/z/jx4Ya4PP5. John, please let me know if you were referring 
to something else, but IIUC then it would be best to emit vector conversion for 
the full vector (that should also be the easiest in terms of codegen).

More recent instruction set versions also have specialized instructions for 
things like dot-products, that also extend/truncate some of their operands 
and/or results., which we could also make use of easily if we have the vector 
conversions.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99037

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

[PATCH] D99646: [clang-tidy] misc-std-stream-objects-outside-main: a new check

[Marco Gartmann via Phabricator via cfe-commits]

mgartmann updated this revision to Diff 334527.
mgartmann marked 4 inline comments as done.
mgartmann added a comment.

Refactored the code and documentation files according to the feedback received 
on the first diff.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99646

Files:
  clang-tools-extra/clang-tidy/misc/CMakeLists.txt
  clang-tools-extra/clang-tidy/misc/MiscTidyModule.cpp
  clang-tools-extra/clang-tidy/misc/StdStreamObjectsOutsideMainCheck.cpp
  clang-tools-extra/clang-tidy/misc/StdStreamObjectsOutsideMainCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  
clang-tools-extra/docs/clang-tidy/checks/misc-std-stream-objects-outside-main.rst
  
clang-tools-extra/test/clang-tidy/checkers/misc-std-stream-objects-outside-main.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/misc-std-stream-objects-outside-main.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/misc-std-stream-objects-outside-main.cpp
@@ -0,0 +1,53 @@
+// RUN: %check_clang_tidy %s misc-std-stream-objects-outside-main %t
+
+namespace std {
+struct string {
+  string(const char *);
+  ~string();
+};
+
+struct Ostream {
+  Ostream <<(string Message);
+};
+
+struct Istream {
+  Istream >>(string Message);
+};
+
+Ostream cout{}, wcout{}, cerr{}, wcerr{};
+Istream cin{}, wcin{};
+
+} // namespace std
+
+void problematic() {
+  // CHECK-MESSAGES: :[[@LINE+1]]:8: warning: predefined standard stream objects should not be used outside the main function [misc-std-stream-objects-outside-main]
+  std::cout << "This should trigger the check";
+
+  // CHECK-MESSAGES: :[[@LINE+1]]:8: warning: predefined standard stream objects should not be used outside the main function [misc-std-stream-objects-outside-main]
+  std::wcout << "This should trigger the check";
+
+  // CHECK-MESSAGES: :[[@LINE+1]]:8: warning: predefined standard stream objects should not be used outside the main function [misc-std-stream-objects-outside-main]
+  std::cerr << "This should trigger the check";
+
+  // CHECK-MESSAGES: :[[@LINE+1]]:8: warning: predefined standard stream objects should not be used outside the main function [misc-std-stream-objects-outside-main]
+  std::wcerr << "This should trigger the check";
+
+  std::string Foo{"bar"};
+
+  // CHECK-MESSAGES: :[[@LINE+1]]:8: warning: predefined standard stream objects should not be used outside the main function [misc-std-stream-objects-outside-main]
+  std::cin >> Foo;
+
+  // CHECK-MESSAGES: :[[@LINE+1]]:8: warning: predefined standard stream objects should not be used outside the main function [misc-std-stream-objects-outside-main]
+  std::wcin >> Foo;
+}
+
+int main() {
+  std::cout << "This should not trigger the check";  // OK
+  std::wcout << "This should not trigger the check"; // OK
+  std::cerr << "This should not trigger the check";  // OK
+  std::wcerr << "This should not trigger the check"; // OK
+
+  std::string Foo{"bar"};
+  std::cin >> Foo;  // OK
+  std::wcin >> Foo; // OK
+}
Index: clang-tools-extra/docs/clang-tidy/checks/misc-std-stream-objects-outside-main.rst
===
--- /dev/null
+++ clang-tools-extra/docs/clang-tidy/checks/misc-std-stream-objects-outside-main.rst
@@ -0,0 +1,45 @@
+.. title:: clang-tidy - misc-std-stream-objects-outside-main
+
+misc-std-stream-objects-outside-main
+=
+
+Diagnoses if a predefined standard stream object (``cin``, ``wcin``,
+``cout``, ``wcout``, ``cerr`` or ``wcerr``) is used outside the ``main`` function.
+
+For instance, in the following code, the use of ``std::cout`` outside of ``main()`` would get
+flagged whereas the use of ``std::cout`` inside ``main()`` is not flagged:
+
+.. code-block:: c++
+
+  #include 
+
+  void some_function() {
+std::cout << "This triggers the check.";
+ 
+  }
+
+  int main() {
+std::cout << "This does not trigger the check.";
+  }
+
+Since the predefined standard stream objects are global objects, their use outside of ``main()`` worsens a
+program's testability and is thus discouraged. Instead, those objects should only be used inside ``main()``.
+They can then be passed as arguments to other functions like so:
+
+.. code-block:: c++
+
+  #include 
+
+  void some_function(std::istream & in, std::ostream & out) {
+out << "This does not trigger the check.";
+
+int i{0};
+in >> i;
+  }
+
+  int main() {
+some_function(std::cin, std::cout);
+  }
+
+In contrast to using ``std::cin`` and ``std::cout`` directly, in the above example, it is possible to inject 
+mocked stream objects into ``some_function()`` during testing.
Index: clang-tools-extra/docs/clang-tidy/checks/list.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/list.rst
+++ 

[PATCH] D99646: [clang-tidy] misc-std-stream-objects-outside-main: a new check

[Eugene Zelenko via Phabricator via cfe-commits]

Eugene.Zelenko added a comment.

It looks like new patch was not uploaded.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99646

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

[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added a comment.

Mostly looks good.

> `clang/test/Driver/Inputs/basic_cross_linux_tree/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/x32/crtbegin.o`

Worth bumping the version. 4.6 is quite old and as a host compiler llvm-project 
has stopped supporting it. The distributions having 4.6 are all end-of-life.
Using a new version (matching your reality) can give impression that the user 
who contributed the original code may still need it for a while (say 5 years).

> Currently, support for the x32 ABI is handled as an extension to the x86_64 
> target only.

As a multilib to the x86_64 target.

> However, Debian has a full self-hosting x32 port which is treated as a 
> separate architecture with its own architecture triplets as well as search 
> paths.

I still don't quite understand this. Shouldn't a native x32 port use 
`x86_64-unknown-linux-gnux32`? Why does it use the multilib style `/x32` suffix?




Comment at: clang/lib/Driver/ToolChains/Gnu.cpp:2110
+  static const char *const X32Triples[] = {"x86_64-linux-gnux32",
+   "x86_64-unknown-linux-gnux32",
+   "x86_64-pc-linux-gnux32"};

Personally I'd defer adding a triplet until it is proven to be used on a system.

This is not free, for every x86-64 user (even if they don't use multilib or 
x32), their clang driver runs need to stat the directory under lib/gcc or 
lib/gcc-cross.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D52050

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

[PATCH] D99152: [AMX] Prototype for vector and amx bitcast.

[Florian Hahn via Phabricator via cfe-commits]

fhahn added a comment.

In D99152#2661296 , @LuoYuanke wrote:

>> Unfortunately this is not possible to use an opaque type with the AMX 
>> intrinsics at the moment, because of the way they are define. It is possible 
>> to use opaque types with intrinsics in general though, e.g. see 
>> https://llvm.godbolt.org/z/Ezhf6535c
>>
>> My point is, you should be able to adjust the definitions of the AMX 
>> intrinsics and then just replace all occurrences of `x86_amx` in your 
>> examples with a opaque type you define in the module. But as I said 
>> initially, you don't need to do everything at once (and you probably 
>> shouldn't). I'd start with addressing the bitcast issue and tackle the 
>> `x86_amx` type itself once that is done.
>>
>> (And I am also not saying that it definitely needs to be removed, only that 
>> if it should be kept in the long run, it would be good to specify it in the 
>> LangRef and should have a good justification, especially if there are no 
>> instructions that do anything meaningful with values of the type other than 
>> take it as arguments and return values. Opaque types are a suggestion for an 
>> alternative that *may* be viable without a dedicated first-class type)
>
> Thank you for the suggestion. So here is my plan.
>
> 1. specify x86_amx in LangRef.
> 2. Add llvm.x86.tile.cast intrinsic.
> 3. Optimize some of llvm.x86.tile.cast code as bitcast does, and transform 
> llvm.x86.tile.cast to amx intrinsic if it can't be eliminated.
> 4. After the above 3 items are finished, replace bitcast with 
> llvm.x86.tile.cast in front-end when generate IR for amx builtin.
> 5. After some time for stabilization, remove bitcast transform code from LLVM.
> 6. After all of the llvm.x86.tile.cast work is finished, let's discuss about 
> opaque type.
>
> Does that looks good to you?

Sounds good to me, but it might be good to also share this in the thread on 
llvm-dev, as there might be additional feedback :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99152

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

[PATCH] D99646: [clang-tidy] misc-std-stream-objects-outside-main: a new check

[Marco Gartmann via Phabricator via cfe-commits]

mgartmann marked 10 inline comments as done.
mgartmann added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/misc/StdStreamObjectsOutsideMainCheck.cpp:25
+  .bind("match"),
+  this);
+}

riccibruno wrote:
> Will this match `my_namespace::cin`?
Yes, at the moment this would be matched as well.



Comment at: 
clang-tools-extra/clang-tidy/misc/StdStreamObjectsOutsideMainCheck.cpp:42
+
+bool StdStreamObjectsOutsideMainCheck::isInsideMainFunction(
+const MatchFinder::MatchResult , const DynTypedNode ) {

njames93 wrote:
> This all seems unnecessary, you can add `unless(forFunction(isMain()))` to 
> your declRefExpr matcher instead.
Thanks for pointing this out to me. `forFunction()` is exactly what I was 
initially looking for. Unfortunately, I did not find it. 

I now refactored the code to use this matcher instead.

I guess `isMain()` would not match if a MSVCRT entry point (see @riccibruno's 
answer on line 47) is used, is it? Do you think it makes sense to also match 
this kind of entry point? How could this be done? I was not able to find 
anything related in the [[ 
https://clang.llvm.org/docs/LibASTMatchersReference.html | AST Matcher 
Reference ]].



Comment at: 
clang-tools-extra/clang-tidy/misc/StdStreamObjectsOutsideMainCheck.cpp:47
+  if (AsFunctionDecl && AsFunctionDecl->getIdentifier() &&
+  AsFunctionDecl->getName().equals("main")) {
+return true;

riccibruno wrote:
> You can use `FunctionDecl::isMain`. Additionally you might want to also use 
> `FunctionDecl::isMSVCRTEntryPoint` for the Windows-specific main functions.
Due to @njames93's suggestion to use a `unless(forFunction(isMain()))` matcher, 
this function is not needed anymore.

Thank you anyways for pointing this out to me. 



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/misc-std-stream-objects-outside-main.cpp:1
+// RUN: %check_clang_tidy -std=c++14-or-later %s 
misc-std-stream-objects-outside-main %t
+

njames93 wrote:
> Why won't this work in c++11 mode?
When not specifying C++14 as the standard, the corresponding tests failed.
Some errors in the test output pointed out that e.g.,// auto return without 
trailing return types// is a C++14 extension.

I created a [[ 
https://gist.github.com/mgartmann/f8a876ebbed6f7c1b8e7a9c901f36508 | gist 
(click me) ]] which contains the test ouput of this clang-tidy check. There, 
all occured errors can be seen.

IMHO, those errors seem to come from the directly or indirectly included header 
files rather than from this check. Please correct me if I am wrong.

After adding `-std=c++14-or-later`, no errors occured anymore. That is the 
reason why I added it.

Anyways, I now refactored the test file, creating a `std` namespace and adding 
my own "mocked" stream objects. I adpoted this approach from existing tests 
(e.g., `readability-string-compare`).

Thus, no include is needed anymore and `-std=c++14-or-later` can be omitted.

If I overlooked something, I would be glad if you could point this out.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99646

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

[PATCH] D94355: [Passes] Add relative lookup table converter pass

[Arthur Eubanks via Phabricator via cfe-commits]

aeubanks added inline comments.



Comment at: llvm/test/Other/opt-O3-pipeline-enable-matrix.ll:322-323
 ; CHECK-NEXT:   Simplify the CFG
+; CHECK-NEXT: Relative Lookup Table Converter
+; CHECK-NEXT: FunctionPass Manager
 ; CHECK-NEXT:   Annotation Remarks

rnk wrote:
> Putting a ModulePass in the middle of the CodeGen pass pipeline creates a 
> "pass barrier": now instead of applying every pass to each function in turn, 
> the old pass manager will stop, run this whole-module pass, and then run 
> subseqeunt passes in the next function pass manager on each function in turn. 
> This isn't ideal. @aeubanks, can you follow-up to make sure this is addressed?
> 
> We had the same issues with the SymbolRewriter pass, which if you grep for 
> "Rewrite Symbols" you can see has the same issue. I remember writing a patch 
> to fix it, but I guess I never landed it.
I see "Rewrite Symbols" in the codegen pipeline and yeah it's splitting the 
function pass manager.

For this patch, can we just not add the pass to the legacy PM pipeline? It's 
deprecated and the new PM is already the default for the optimization pipeline.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94355

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

[PATCH] D99683: [HIP] Support ThinLTO

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl created this revision.
yaxunl added reviewers: tra, ashi1, scchan.
Herald added subscribers: jansvoboda11, dang, hiraditya, inglorion.
yaxunl requested review of this revision.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

https://reviews.llvm.org/D99683

Files:
  clang/include/clang/Driver/Driver.h
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/HIP.cpp
  clang/test/Driver/hip-options.hip
  llvm/lib/Transforms/IPO/FunctionImport.cpp
  llvm/test/Transforms/FunctionImport/Inputs/noinline.ll
  llvm/test/Transforms/FunctionImport/noinline.ll

Index: llvm/test/Transforms/FunctionImport/noinline.ll
===
--- /dev/null
+++ llvm/test/Transforms/FunctionImport/noinline.ll
@@ -0,0 +1,23 @@
+; Do setup work for all below tests: generate bitcode and combined index
+; RUN: opt -module-summary %s -o %t.bc
+; RUN: opt -module-summary %p/Inputs/noinline.ll -o %t2.bc
+; RUN: llvm-lto -thinlto -o %t3 %t.bc %t2.bc
+
+; Attempt the import now, ensure below that file containing noinline
+; is not imported by default but imported with -import-noinline.
+
+; RUN: opt -function-import -summary-file %t3.thinlto.bc %t.bc -S 2>&1 \
+; RUN:   | FileCheck -check-prefix=NOIMPORT %s
+; RUN: opt -function-import -import-noinline -summary-file %t3.thinlto.bc \
+; RUN:   %t.bc -S 2>&1 | FileCheck -check-prefix=IMPORT %s
+
+define i32 @main() #0 {
+entry:
+  %f = alloca i64, align 8
+  call void @foo(i64* %f)
+  ret i32 0
+}
+
+; NOIMPORT: declare void @foo(i64*)
+; IMPORT: define available_externally void @foo
+declare void @foo(i64*) #1
Index: llvm/test/Transforms/FunctionImport/Inputs/noinline.ll
===
--- /dev/null
+++ llvm/test/Transforms/FunctionImport/Inputs/noinline.ll
@@ -0,0 +1,8 @@
+define void @foo(i64* %v) #0 {
+entry:
+  %v.addr = alloca i64*, align 8
+  store i64* %v, i64** %v.addr, align 8
+  ret void
+}
+
+attributes #0 = { noinline }
\ No newline at end of file
Index: llvm/lib/Transforms/IPO/FunctionImport.cpp
===
--- llvm/lib/Transforms/IPO/FunctionImport.cpp
+++ llvm/lib/Transforms/IPO/FunctionImport.cpp
@@ -84,6 +84,10 @@
 "import-cutoff", cl::init(-1), cl::Hidden, cl::value_desc("N"),
 cl::desc("Only import first N functions if N>=0 (default -1)"));
 
+static cl::opt
+ImportNoInline("import-noinline", cl::init(false), cl::Hidden,
+   cl::desc("Import functions with noinline attribute"));
+
 static cl::opt
 ImportInstrFactor("import-instr-evolution-factor", cl::init(0.7),
   cl::Hidden, cl::value_desc("x"),
@@ -240,7 +244,7 @@
 }
 
 // Don't bother importing if we can't inline it anyway.
-if (Summary->fflags().NoInline) {
+if (Summary->fflags().NoInline && !ImportNoInline) {
   Reason = FunctionImporter::ImportFailureReason::NoInline;
   return false;
 }
Index: clang/test/Driver/hip-options.hip
===
--- clang/test/Driver/hip-options.hip
+++ clang/test/Driver/hip-options.hip
@@ -51,3 +51,12 @@
 // RUN:   --cuda-gpu-arch=gfx906  %s 2>&1 | FileCheck -check-prefix=CTA %s
 // CTA: clang{{.*}} "-triple" "x86_64-unknown-linux-gnu" {{.*}} "-mconstructor-aliases"
 // CTA-NOT: clang{{.*}} "-triple" "amdgcn-amd-amdhsa" {{.*}} "-mconstructor-aliases"
+
+// Check -foffload-lto=thin translated correctly.
+
+// RUN: %clang -### -target x86_64-unknown-linux-gnu -nogpuinc -nogpulib \
+// RUN:   --cuda-gpu-arch=gfx906 -fgpu-rdc -foffload-lto=thin %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=THINLTO %s
+// THINLTO-NOT: clang{{.*}} "-triple" "x86_64-unknown-linux-gnu" {{.*}} "-flto-unit"
+// THINLTO: clang{{.*}} "-triple" "amdgcn-amd-amdhsa" {{.*}} "-flto-unit"
+// THINLTO: lld{{.*}}"-plugin-opt=mcpu=gfx906" "-plugin-opt=thinlto" "-plugin-opt=-import-instr-limit=10" "-plugin-opt=-import-noinline"
Index: clang/lib/Driver/ToolChains/HIP.cpp
===
--- clang/lib/Driver/ToolChains/HIP.cpp
+++ clang/lib/Driver/ToolChains/HIP.cpp
@@ -50,8 +50,8 @@
   auto  = getToolChain();
   auto  = TC.getDriver();
   assert(!Inputs.empty() && "Must have at least one input.");
-  addLTOOptions(TC, Args, LldArgs, Output, Inputs[0],
-D.getLTOMode() == LTOK_Thin);
+  bool IsThinLTO = D.getLTOMode(/*IsOffload=*/true) == LTOK_Thin;
+  addLTOOptions(TC, Args, LldArgs, Output, Inputs[0], IsThinLTO);
 
   // Extract all the -m options
   std::vector Features;
@@ -67,6 +67,14 @@
   if (!Features.empty())
 LldArgs.push_back(Args.MakeArgString(MAttrString));
 
+  // ToDo: Remove these options after AMDGPU backend supports ISA-level linking.
+  // Since AMDGPU backend currently does not support ISA-level 

[PATCH] D99190: WIP: [SYCL] Add design document for SYCL mode

[Ronan Keryell via Phabricator via cfe-commits]

keryell added inline comments.



Comment at: clang/docs/SYCLSupport.md:73
+the integration header is used (included) by the SYCL runtime implementation, 
so
+the header must be available before the host compilation starts.*
+

bader wrote:
> Naghasan wrote:
> > > First, it must be possible to use any host compiler
> > 
> > I don't understand the link with the integration header. SYCL being 
> > implementable as a library is a design principle of the specs but it 
> > doesn't means the clang host compiler has to remain a vanilla C++ compiler.
> > 
> > > information provided in the integration header is used (included) by the 
> > > SYCL runtime implementation, so the header must be available before the 
> > > host compilation starts
> > 
> > Another approach to the integration header would be for clang as the host 
> > compiler to generate the used type traits.
> > > First, it must be possible to use any host compiler
> > 
> > I don't understand the link with the integration header. SYCL being 
> > implementable as a library is a design principle of the specs but it 
> > doesn't means the clang host compiler has to remain a vanilla C++ compiler.
> > 
> > > information provided in the integration header is used (included) by the 
> > > SYCL runtime implementation, so the header must be available before the 
> > > host compilation starts
> > 
> > Another approach to the integration header would be for clang as the host 
> > compiler to generate the used type traits.
> 
> If there are no objections from @keryell, I'd like to prototype this approach 
> for SYCL first to make sure there are no blocking issues.
> This option seems to be worth to explore considering integration header 
> approach disadvantages.
> > > First, it must be possible to use any host compiler
> > 
> > I don't understand the link with the integration header. SYCL being 
> > implementable as a library is a design principle of the specs but it 
> > doesn't means the clang host compiler has to remain a vanilla C++ compiler.
> > 
> > > information provided in the integration header is used (included) by the 
> > > SYCL runtime implementation, so the header must be available before the 
> > > host compilation starts
> > 
> > Another approach to the integration header would be for clang as the host 
> > compiler to generate the used type traits.

Type traits are somehow misleading and probably implementation details.
I guess what this means is a meta-representation of the kernels and their 
API/ABI.

> If there are no objections from @keryell, I'd like to prototype this approach 
> for SYCL first to make sure there are no blocking issues.
> This option seems to be worth to explore considering integration header 
> approach disadvantages.

No objection.
triSYCL did not have this integration header since we were using Clang as the 
host compiler and were able to generate directly the kernel call on the host 
https://github.com/triSYCL/llvm/blob/sycl/master/lib/SYCL/SYCLSerializeArguments.cpp
 and the kernel stub on device 
https://github.com/triSYCL/llvm/blob/sycl/master/lib/SYCL/SYCLSerializeArgumentsInside.cpp

Obviously, it was in the context of late outlining in LLVM but it can work with 
early outlining in Clang.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99190

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

[PATCH] D98237: [clang-format] Option for empty lines after an access modifier.

[Max Sagebaum via Phabricator via cfe-commits]

Max_S updated this revision to Diff 334523.
Max_S marked 7 inline comments as done.
Max_S added a comment.

Addressed last minor remarks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98237

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

Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -9179,6 +9179,554 @@
Style);
 }
 
+TEST_F(FormatTest, FormatsAfterAccessModifiers) {
+
+  FormatStyle Style = getLLVMStyle();
+  EXPECT_EQ(Style.EmptyLineAfterAccessModifier, FormatStyle::ELAAMS_Never);
+  verifyFormat("struct foo {\n"
+   "private:\n"
+   "  void f() {}\n"
+   "\n"
+   "private:\n"
+   "  int i;\n"
+   "\n"
+   "protected:\n"
+   "  int j;\n"
+   "};\n",
+   Style);
+
+  // Check if lines are removed.
+  verifyFormat("struct foo {\n"
+   "private:\n"
+   "  void f() {}\n"
+   "\n"
+   "private:\n"
+   "  int i;\n"
+   "\n"
+   "protected:\n"
+   "  int j;\n"
+   "};\n",
+   "struct foo {\n"
+   "private:\n"
+   "\n"
+   "  void f() {}\n"
+   "\n"
+   "private:\n"
+   "\n"
+   "  int i;\n"
+   "\n"
+   "protected:\n"
+   "\n"
+   "  int j;\n"
+   "};\n",
+   Style);
+
+  Style.EmptyLineAfterAccessModifier = FormatStyle::ELAAMS_Always;
+  verifyFormat("struct foo {\n"
+   "private:\n"
+   "\n"
+   "  void f() {}\n"
+   "\n"
+   "private:\n"
+   "\n"
+   "  int i;\n"
+   "\n"
+   "protected:\n"
+   "\n"
+   "  int j;\n"
+   "};\n",
+   Style);
+
+  // Check if lines are added.
+  verifyFormat("struct foo {\n"
+   "private:\n"
+   "\n"
+   "  void f() {}\n"
+   "\n"
+   "private:\n"
+   "\n"
+   "  int i;\n"
+   "\n"
+   "protected:\n"
+   "\n"
+   "  int j;\n"
+   "};\n",
+   "struct foo {\n"
+   "private:\n"
+   "  void f() {}\n"
+   "\n"
+   "private:\n"
+   "  int i;\n"
+   "\n"
+   "protected:\n"
+   "  int j;\n"
+   "};\n",
+   Style);
+
+  // Leave tests rely on the code layout, test::messUp can not be used.
+  Style.EmptyLineAfterAccessModifier = FormatStyle::ELAAMS_Leave;
+  Style.MaxEmptyLinesToKeep = 0u;
+  EXPECT_EQ("struct foo {\n"
+"private:\n"
+"  void f() {}\n"
+"private:\n"
+"  int i;\n"
+"protected:\n"
+"  int j;\n"
+"};\n",
+format("struct foo {\n"
+   "private:\n"
+   "  void f() {}\n"
+   "\n"
+   "private:\n"
+   "  int i;\n"
+   "\n"
+   "protected:\n"
+   "  int j;\n"
+   "};\n",
+   Style));
+
+  // Check if MaxEmptyLinesToKeep is respected.
+  EXPECT_EQ("struct foo {\n"
+"private:\n"
+"  void f() {}\n"
+"private:\n"
+"  int i;\n"
+"protected:\n"
+"  int j;\n"
+"};\n",
+format("struct foo {\n"
+   "private:\n"
+   "\n\n\n"
+   "  void f() {}\n"
+   "\n"
+   "private:\n"
+   "\n\n\n"
+   "  int i;\n"
+   "\n"
+   "protected:\n"
+   "\n\n\n"
+   "  int j;\n"
+   "};\n",
+   Style));
+
+  Style.MaxEmptyLinesToKeep = 1u;
+  EXPECT_EQ("struct foo {\n"
+"private:\n"
+"\n"
+"  void f() {}\n"
+"\n"
+"private:\n"
+"\n"
+"  int i;\n"
+"\n"
+"protected:\n"
+"\n"
+"  int j;\n"
+"};\n",
+format("struct foo {\n"
+   "private:\n"
+   "\n"
+   "  void f() {}\n"
+   "\n"
+   

[PATCH] D99190: WIP: [SYCL] Add design document for SYCL mode

[Ronan Keryell via Phabricator via cfe-commits]

keryell added a comment.

In D99190#2659571 , @tschuett wrote:

> The OMPIRBuilder is the modern version of late outlining:
> https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h
> You may consider to go that way with SYCL as well.

triSYCL had a late outlining version, giving different trade-offs. 
https://github.com/triSYCL/llvm/blob/sycl/master/lib/SYCL/SYCLKernelFilter.cpp
Now we are just using the early outliner of oneAPI DPC++ because there are 
quite more developers working on it. :-)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99190

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

[PATCH] D94355: [Passes] Add relative lookup table converter pass

[Reid Kleckner via Phabricator via cfe-commits]

rnk added subscribers: aeubanks, rnk.
rnk added inline comments.



Comment at: llvm/test/Other/opt-O3-pipeline-enable-matrix.ll:322-323
 ; CHECK-NEXT:   Simplify the CFG
+; CHECK-NEXT: Relative Lookup Table Converter
+; CHECK-NEXT: FunctionPass Manager
 ; CHECK-NEXT:   Annotation Remarks

Putting a ModulePass in the middle of the CodeGen pass pipeline creates a "pass 
barrier": now instead of applying every pass to each function in turn, the old 
pass manager will stop, run this whole-module pass, and then run subseqeunt 
passes in the next function pass manager on each function in turn. This isn't 
ideal. @aeubanks, can you follow-up to make sure this is addressed?

We had the same issues with the SymbolRewriter pass, which if you grep for 
"Rewrite Symbols" you can see has the same issue. I remember writing a patch to 
fix it, but I guess I never landed it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94355

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

[PATCH] D99521: [OPENMP]Fix PR48885: Crash in passing firstprivate args to tasks on Apple M1.

[Alexey Bataev via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGa28e835e9494: [OPENMP]Fix PR48885: Crash in passing 
firstprivate args to tasks on Apple M1. (authored by ABataev).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99521

Files:
  clang/lib/CodeGen/CGStmtOpenMP.cpp
  clang/test/OpenMP/declare_mapper_codegen.cpp
  clang/test/OpenMP/master_taskloop_firstprivate_codegen.cpp
  clang/test/OpenMP/master_taskloop_in_reduction_codegen.cpp
  clang/test/OpenMP/master_taskloop_lastprivate_codegen.cpp
  clang/test/OpenMP/master_taskloop_private_codegen.cpp
  clang/test/OpenMP/master_taskloop_simd_firstprivate_codegen.cpp
  clang/test/OpenMP/master_taskloop_simd_in_reduction_codegen.cpp
  clang/test/OpenMP/master_taskloop_simd_lastprivate_codegen.cpp
  clang/test/OpenMP/master_taskloop_simd_private_codegen.cpp
  clang/test/OpenMP/nvptx_param_translate.c
  clang/test/OpenMP/parallel_master_taskloop_firstprivate_codegen.cpp
  clang/test/OpenMP/parallel_master_taskloop_lastprivate_codegen.cpp
  clang/test/OpenMP/parallel_master_taskloop_private_codegen.cpp
  clang/test/OpenMP/parallel_master_taskloop_simd_firstprivate_codegen.cpp
  clang/test/OpenMP/parallel_master_taskloop_simd_lastprivate_codegen.cpp
  clang/test/OpenMP/parallel_master_taskloop_simd_private_codegen.cpp
  clang/test/OpenMP/target_codegen.cpp
  clang/test/OpenMP/target_depend_codegen.cpp
  clang/test/OpenMP/target_enter_data_codegen.cpp
  clang/test/OpenMP/target_enter_data_depend_codegen.cpp
  clang/test/OpenMP/target_exit_data_codegen.cpp
  clang/test/OpenMP/target_exit_data_depend_codegen.cpp
  clang/test/OpenMP/target_parallel_depend_codegen.cpp
  clang/test/OpenMP/target_parallel_for_codegen.cpp
  clang/test/OpenMP/target_parallel_for_depend_codegen.cpp
  clang/test/OpenMP/target_parallel_for_simd_depend_codegen.cpp
  clang/test/OpenMP/target_simd_depend_codegen.cpp
  clang/test/OpenMP/target_teams_codegen.cpp
  clang/test/OpenMP/target_teams_depend_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_depend_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_depend_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_simd_depend_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_simd_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_simd_depend_codegen.cpp
  clang/test/OpenMP/target_update_codegen.cpp
  clang/test/OpenMP/target_update_depend_codegen.cpp
  clang/test/OpenMP/task_codegen.cpp
  clang/test/OpenMP/task_firstprivate_codegen.cpp
  clang/test/OpenMP/task_in_reduction_codegen.cpp
  clang/test/OpenMP/task_private_codegen.cpp
  clang/test/OpenMP/taskloop_firstprivate_codegen.cpp
  clang/test/OpenMP/taskloop_in_reduction_codegen.cpp
  clang/test/OpenMP/taskloop_lastprivate_codegen.cpp
  clang/test/OpenMP/taskloop_private_codegen.cpp
  clang/test/OpenMP/taskloop_simd_firstprivate_codegen.cpp
  clang/test/OpenMP/taskloop_simd_in_reduction_codegen.cpp
  clang/test/OpenMP/taskloop_simd_lastprivate_codegen.cpp
  clang/test/OpenMP/taskloop_simd_private_codegen.cpp
  clang/test/OpenMP/taskloop_with_atomic_codegen.cpp

Index: clang/test/OpenMP/taskloop_with_atomic_codegen.cpp
===
--- clang/test/OpenMP/taskloop_with_atomic_codegen.cpp
+++ clang/test/OpenMP/taskloop_with_atomic_codegen.cpp
@@ -27,6 +27,7 @@
 // Check that occupanices var is firstprivatized.
 // CHECK-DAG: atomicrmw add i32* [[FP_OCCUP:%.+]], i32 1 monotonic, align 4
 // CHECK-DAG: [[FP_OCCUP]] = load i32*, i32** [[FP_OCCUP_ADDR:%[^,]+]],
-// CHECK-DAG: call void (i8*, ...) %{{.+}}(i8* %{{.+}}, i32** [[FP_OCCUP_ADDR]])
+// CHECK-DAG: [[FN:%.+]] = bitcast void (i8*, ...)* %{{.*}} to void (i8*,
+// CHECK-DAG: call void [[FN]](i8* %{{.+}}, i32** [[FP_OCCUP_ADDR]])
 
 #endif
Index: clang/test/OpenMP/taskloop_simd_private_codegen.cpp
===
--- clang/test/OpenMP/taskloop_simd_private_codegen.cpp
+++ clang/test/OpenMP/taskloop_simd_private_codegen.cpp
@@ -230,7 +230,8 @@
 // CHECK: [[PRIV_SIVAR_ADDR:%.+]] = alloca i32*,
 // CHECK: store void (i8*, ...)* bitcast (void ([[PRIVATES_MAIN_TY]]*, [[S_DOUBLE_TY]]**, i32**, [2 x [[S_DOUBLE_TY]]]**, [2 x i32]**, i32**)* [[PRIVATES_MAP_FN]] to void (i8*, ...)*), void (i8*, ...)** [[MAP_FN_ADDR:%.+]],
 // CHECK: [[MAP_FN:%.+]] = load void (i8*, ...)*, void (i8*, ...)** [[MAP_FN_ADDR]],
-// CHECK: call void (i8*, ...) [[MAP_FN]](i8* %{{.+}}, [[S_DOUBLE_TY]]** [[PRIV_VAR_ADDR]], i32** [[PRIV_T_VAR_ADDR]], [2 x [[S_DOUBLE_TY]]]** [[PRIV_S_ARR_ADDR]], [2 x i32]** [[PRIV_VEC_ADDR]], i32** [[PRIV_SIVAR_ADDR]])
+// CHECK: [[FN:%.+]] = bitcast void (i8*, ...)* [[MAP_FN]] to void (i8*,
+// CHECK: call void [[FN]](i8* %{{.+}}, [[S_DOUBLE_TY]]** [[PRIV_VAR_ADDR]], i32** [[PRIV_T_VAR_ADDR]], [2 x [[S_DOUBLE_TY]]]** 

[clang] a28e835 - [OPENMP]Fix PR48885: Crash in passing firstprivate args to tasks on Apple M1.

[Alexey Bataev via cfe-commits]

Author: Alexey Bataev
Date: 2021-03-31T13:00:58-07:00
New Revision: a28e835e9494af058bcbad667906271eec5da83b

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

LOG: [OPENMP]Fix PR48885: Crash in passing firstprivate args to tasks on Apple 
M1.

Need to bitcast the function pointer passed as a parameter to the real
type to avoid possible problem with calling conventions.

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

Added: 


Modified: 
clang/lib/CodeGen/CGStmtOpenMP.cpp
clang/test/OpenMP/declare_mapper_codegen.cpp
clang/test/OpenMP/master_taskloop_firstprivate_codegen.cpp
clang/test/OpenMP/master_taskloop_in_reduction_codegen.cpp
clang/test/OpenMP/master_taskloop_lastprivate_codegen.cpp
clang/test/OpenMP/master_taskloop_private_codegen.cpp
clang/test/OpenMP/master_taskloop_simd_firstprivate_codegen.cpp
clang/test/OpenMP/master_taskloop_simd_in_reduction_codegen.cpp
clang/test/OpenMP/master_taskloop_simd_lastprivate_codegen.cpp
clang/test/OpenMP/master_taskloop_simd_private_codegen.cpp
clang/test/OpenMP/nvptx_param_translate.c
clang/test/OpenMP/parallel_master_taskloop_firstprivate_codegen.cpp
clang/test/OpenMP/parallel_master_taskloop_lastprivate_codegen.cpp
clang/test/OpenMP/parallel_master_taskloop_private_codegen.cpp
clang/test/OpenMP/parallel_master_taskloop_simd_firstprivate_codegen.cpp
clang/test/OpenMP/parallel_master_taskloop_simd_lastprivate_codegen.cpp
clang/test/OpenMP/parallel_master_taskloop_simd_private_codegen.cpp
clang/test/OpenMP/target_codegen.cpp
clang/test/OpenMP/target_depend_codegen.cpp
clang/test/OpenMP/target_enter_data_codegen.cpp
clang/test/OpenMP/target_enter_data_depend_codegen.cpp
clang/test/OpenMP/target_exit_data_codegen.cpp
clang/test/OpenMP/target_exit_data_depend_codegen.cpp
clang/test/OpenMP/target_parallel_depend_codegen.cpp
clang/test/OpenMP/target_parallel_for_codegen.cpp
clang/test/OpenMP/target_parallel_for_depend_codegen.cpp
clang/test/OpenMP/target_parallel_for_simd_depend_codegen.cpp
clang/test/OpenMP/target_simd_depend_codegen.cpp
clang/test/OpenMP/target_teams_codegen.cpp
clang/test/OpenMP/target_teams_depend_codegen.cpp
clang/test/OpenMP/target_teams_distribute_codegen.cpp
clang/test/OpenMP/target_teams_distribute_depend_codegen.cpp
clang/test/OpenMP/target_teams_distribute_parallel_for_depend_codegen.cpp

clang/test/OpenMP/target_teams_distribute_parallel_for_simd_depend_codegen.cpp
clang/test/OpenMP/target_teams_distribute_simd_codegen.cpp
clang/test/OpenMP/target_teams_distribute_simd_depend_codegen.cpp
clang/test/OpenMP/target_update_codegen.cpp
clang/test/OpenMP/target_update_depend_codegen.cpp
clang/test/OpenMP/task_codegen.cpp
clang/test/OpenMP/task_firstprivate_codegen.cpp
clang/test/OpenMP/task_in_reduction_codegen.cpp
clang/test/OpenMP/task_private_codegen.cpp
clang/test/OpenMP/taskloop_firstprivate_codegen.cpp
clang/test/OpenMP/taskloop_in_reduction_codegen.cpp
clang/test/OpenMP/taskloop_lastprivate_codegen.cpp
clang/test/OpenMP/taskloop_private_codegen.cpp
clang/test/OpenMP/taskloop_simd_firstprivate_codegen.cpp
clang/test/OpenMP/taskloop_simd_in_reduction_codegen.cpp
clang/test/OpenMP/taskloop_simd_lastprivate_codegen.cpp
clang/test/OpenMP/taskloop_simd_private_codegen.cpp
clang/test/OpenMP/taskloop_with_atomic_codegen.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGStmtOpenMP.cpp 
b/clang/lib/CodeGen/CGStmtOpenMP.cpp
index 285836989602..02d4f6b3c315 100644
--- a/clang/lib/CodeGen/CGStmtOpenMP.cpp
+++ b/clang/lib/CodeGen/CGStmtOpenMP.cpp
@@ -4139,8 +4139,6 @@ void CodeGenFunction::EmitOMPTaskBasedDirective(
 llvm::SmallVector, 16> 
FirstprivatePtrs;
 if (!Data.PrivateVars.empty() || !Data.FirstprivateVars.empty() ||
 !Data.LastprivateVars.empty() || !Data.PrivateLocals.empty()) {
-  llvm::FunctionType *CopyFnTy = llvm::FunctionType::get(
-  CGF.Builder.getVoidTy(), {CGF.Builder.getInt8PtrTy()}, true);
   enum { PrivatesParam = 2, CopyFnParam = 3 };
   llvm::Value *CopyFn = CGF.Builder.CreateLoad(
   CGF.GetAddrOfLocalVar(CS->getCapturedDecl()->getParam(CopyFnParam)));
@@ -4149,13 +4147,16 @@ void CodeGenFunction::EmitOMPTaskBasedDirective(
   // Map privates.
   llvm::SmallVector, 16> PrivatePtrs;
   llvm::SmallVector CallArgs;
+  llvm::SmallVector ParamTypes;
   CallArgs.push_back(PrivatesPtr);
+  ParamTypes.push_back(PrivatesPtr->getType());
   for (const Expr *E : Data.PrivateVars) {
 const auto *VD = cast(cast(E)->getDecl());
 Address PrivatePtr = CGF.CreateMemTemp(
 

[PATCH] D99433: [Matrix] Including __builtin_matrix_multiply_add for the matrix type extension.

[Everton Constantino via Phabricator via cfe-commits]

everton.constantino added a comment.

In D99433#2662259 , @fhahn wrote:

> In D99433#2661919 , 
> @everton.constantino wrote:
>
>> @fhahn Ok I see what you mean now, this sounds like a doable path and might 
>> be able to cover architectures with specialized matrix multiplication 
>> instructions as well .
>>
>> Just to see if I understand correctly I can add a matrix_add intrinsic, do a 
>> travesal looking for matrix_multiply and fuse both changing  
>> `LowerMatrixMultiplyFused` to support pre-loading the accumulator. Is that 
>> correct?
>
> Yes that sounds like a good path forward! I think at the moment, adding a 
> matrix_mul_add intrinsic may be a bit premature, as we can just match & lower 
> directly in place, as we already do in `LowerMatrixMultiplyFused`. Once we 
> add more and more such transforms, it may really help to have additional 
> intrinsics (or we could just create our own dummy declarations which are just 
> used during the matrix lowering, to avoid adding too many intrinsics). But 
> for now I think can move along faster without adding a new intrinsic.

Great, Ill update the patch then. Thanks for the comments!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99433

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

[PATCH] D99681: [OpenMP] Pass mapping names to add components in a user defined mapper

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 created this revision.
jhuber6 added a reviewer: jdoerfert.
Herald added subscribers: guansong, yaxunl.
jhuber6 requested review of this revision.
Herald added subscribers: cfe-commits, sstefan1.
Herald added a project: clang.

Currently the mapping names are not passed to the mapper components that set up
the array region. This means array mappings will not have their names availible
in the runtime. This patch fixes this by passing the argument name to the region
correctly. This means that the mapped variable's name will be the declared
mapper that placed it on the device.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D99681

Files:
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/lib/CodeGen/CGOpenMPRuntime.h


Index: clang/lib/CodeGen/CGOpenMPRuntime.h
===
--- clang/lib/CodeGen/CGOpenMPRuntime.h
+++ clang/lib/CodeGen/CGOpenMPRuntime.h
@@ -824,7 +824,8 @@
   void emitUDMapperArrayInitOrDel(CodeGenFunction ,
   llvm::Value *Handle, llvm::Value *BasePtr,
   llvm::Value *Ptr, llvm::Value *Size,
-  llvm::Value *MapType, CharUnits ElementSize,
+  llvm::Value *MapType, llvm::Value *MapName,
+  CharUnits ElementSize,
   llvm::BasicBlock *ExitBB, bool IsInit);
 
   struct TaskResultTy {
Index: clang/lib/CodeGen/CGOpenMPRuntime.cpp
===
--- clang/lib/CodeGen/CGOpenMPRuntime.cpp
+++ clang/lib/CodeGen/CGOpenMPRuntime.cpp
@@ -9263,7 +9263,6 @@
 SrcLocStr = OMPBuilder.getOrCreateSrcLocStr(FileName, ExprName.c_str(),
 Line, Column);
   }
-
   return SrcLocStr;
 }
 
@@ -9741,12 +9740,15 @@
   llvm::Value *MapType = MapperCGF.EmitLoadOfScalar(
   MapperCGF.GetAddrOfLocalVar(), /*Volatile=*/false,
   C.getPointerType(Int64Ty), Loc);
+  llvm::Value *MapName = MapperCGF.EmitLoadOfScalar(
+  MapperCGF.GetAddrOfLocalVar(),
+  /*Volatile=*/false, C.getPointerType(C.VoidPtrTy), Loc);
 
   // Emit array initiation if this is an array section and \p MapType indicates
   // that memory allocation is required.
   llvm::BasicBlock *HeadBB = MapperCGF.createBasicBlock("omp.arraymap.head");
   emitUDMapperArrayInitOrDel(MapperCGF, Handle, BaseIn, BeginIn, Size, MapType,
- ElementSize, HeadBB, /*IsInit=*/true);
+ MapName, ElementSize, HeadBB, /*IsInit=*/true);
 
   // Emit a for loop to iterate through SizeArg of elements and map all of 
them.
 
@@ -9903,7 +9905,7 @@
   // Emit array deletion if this is an array section and \p MapType indicates
   // that deletion is required.
   emitUDMapperArrayInitOrDel(MapperCGF, Handle, BaseIn, BeginIn, Size, MapType,
- ElementSize, DoneBB, /*IsInit=*/false);
+ MapName, ElementSize, DoneBB, /*IsInit=*/false);
 
   // Emit the function exit block.
   MapperCGF.EmitBlock(DoneBB, /*IsFinished=*/true);
@@ -9924,7 +9926,8 @@
 void CGOpenMPRuntime::emitUDMapperArrayInitOrDel(
 CodeGenFunction , llvm::Value *Handle, llvm::Value *Base,
 llvm::Value *Begin, llvm::Value *Size, llvm::Value *MapType,
-CharUnits ElementSize, llvm::BasicBlock *ExitBB, bool IsInit) {
+llvm::Value *MapName, CharUnits ElementSize, llvm::BasicBlock *ExitBB,
+bool IsInit) {
   StringRef Prefix = IsInit ? ".init" : ".del";
 
   // Evaluate if this is an array section.
@@ -9970,12 +9973,11 @@
   MapperCGF.Builder.getInt64(~(MappableExprsHandler::OMP_MAP_TO |
MappableExprsHandler::OMP_MAP_FROM |
MappableExprsHandler::OMP_MAP_MEMBER_OF)));
-  llvm::Value *MapNameArg = llvm::ConstantPointerNull::get(CGM.VoidPtrTy);
 
   // Call the runtime API __tgt_push_mapper_component to fill up the runtime
   // data structure.
   llvm::Value *OffloadingArgs[] = {Handle,Base,   Begin,
-   ArraySize, MapTypeArg, MapNameArg};
+   ArraySize, MapTypeArg, MapName};
   MapperCGF.EmitRuntimeCall(
   OMPBuilder.getOrCreateRuntimeFunction(CGM.getModule(),
 
OMPRTL___tgt_push_mapper_component),


Index: clang/lib/CodeGen/CGOpenMPRuntime.h
===
--- clang/lib/CodeGen/CGOpenMPRuntime.h
+++ clang/lib/CodeGen/CGOpenMPRuntime.h
@@ -824,7 +824,8 @@
   void emitUDMapperArrayInitOrDel(CodeGenFunction ,
   llvm::Value *Handle, llvm::Value *BasePtr,
   llvm::Value *Ptr, llvm::Value *Size,
-  llvm::Value *MapType, CharUnits ElementSize,
+  llvm::Value 

[PATCH] D99433: [Matrix] Including __builtin_matrix_multiply_add for the matrix type extension.

[Florian Hahn via Phabricator via cfe-commits]

fhahn added a comment.

In D99433#2661919 , 
@everton.constantino wrote:

> @fhahn Ok I see what you mean now, this sounds like a doable path and might 
> be able to cover architectures with specialized matrix multiplication 
> instructions as well .
>
> Just to see if I understand correctly I can add a matrix_add intrinsic, do a 
> travesal looking for matrix_multiply and fuse both changing  
> `LowerMatrixMultiplyFused` to support pre-loading the accumulator. Is that 
> correct?

Yes that sounds like a good path forward! I think at the moment, adding a 
matrix_mul_add intrinsic may be a bit premature, as we can just match & lower 
directly in place, as we already do in `LowerMatrixMultiplyFused`. Once we add 
more and more such transforms, it may really help to have additional intrinsics 
(or we could just create our own dummy declarations which are just used during 
the matrix lowering, to avoid adding too many intrinsics). But for now I think 
can move along faster without adding a new intrinsic.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99433

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

[PATCH] D89013: [libcxx] Support per-target __config_site in per-target runtime build

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added a comment.

In D89013#2662167 , @phosek wrote:

> In D89013#2660407 , @MaskRay wrote:
>
>> Regarding
>>
>>   /usr/include/x86_64-unknown-linux-gnu/c++/v1
>>   /usr/include/c++/v1
>>
>> With GCC multiarch, some `include` search paths are preceded by 
>> machine-os-env specific suffix directories.
>> Note: 'vendor' is not there. So you may see `.../include/x86_64-linux-gnu` 
>> but there is no `.../include/x86_64-{pc,unknown}-linux-gnu`
>>
>>   /usr/local/include/x86_64-linux-gnu # affected by sysroot, 
>> multiarch, usually nonexistent
>>   /usr/local/include  # affected by sysroot
>>   /tmp/opt/gcc-debug/include
>>   /tmp/opt/gcc-debug/lib/gcc/x86_64-pc-linux-gnu/11.0.1/include-fixed
>>   
>> /tmp/opt/gcc-debug/lib/gcc/x86_64-pc-linux-gnu/11.0.1/../../../../x86_64-pc-linux-gnu/include
>>   /usr/include/x86_64-linux-gnu   # affected by sysroot, 
>> multiarch
>>   /usr/include# affected by sysroot
>>
>> On Debian x86_64, `/usr/include/x86_64-linux-gnu/` exists. Adding 
>> `x86_64-pc-linux-gnu` (an possible value of `LLVM_DEFAULT_TARGET_TRIPLE`) 
>> may add more confusion.
>
> This was already discussed pretty extensively in the past, but I'll try to 
> give a summary.
>
> In the case of GCC, compiler can only compile binaries for a single target 
> that's set at configuration time. For example if you configured GCC with 
> `--target=x86_64-acme-linux-gnu`,  the build links the binary as 
> `x86_64-acme-linux-gnu-gcc` and that binary would look for headers in 
> `/usr/include/x86_64-acme-linux-gnu` and libraries in 
> `/usr/lib/x86_64-acme-linux-gnu` (among other paths) so there's little 
> ambiguity.

I'd love if vendor is in the multiarch string, i.e. 
`/usr/include/x86_64-acme-linux-gnu` and `/usr/lib/x86_64-acme-linux-gnu`, but 
unfortunately that is not the case.  See my previous dump with a GCC configured 
with `x86_64-pc-linux-gnu`. Note that some paths are derived from the GCC 
installation, which has vendor part, while others are derived from 
`$multiarch`, which has no vendor part.

> In the case of Clang, the situation is a bit more difficult because a single 
> compiler supports multiple targets via `--target=` option and there are 
> different ways to spell the same target triple. For example, 
> `x86_64-linux-gnu` and `x86_64-unknown-linux-gnu` are considered equivalent, 
> the latter is a normalized version of the former (since you can omit emit 
> components). The question then is where to look for headers and libraries. 
> Currently, we always look in two locations: (1) we use `--target= specified by the user and (2) normalized version of that target. For example 
> if the user passes `--target=x86_64-linux-gnu`, we would first check 
> `/lib/x86_64-linux-gnu` and then 
> `/lib/x86_64-unknown-linux-gnu`.

`x86_64-linux-gnu` and `x86_64-unknown-linux-gnu` are mostly equivalent, but 
they matter for the driver constructed paths from GCC installation (see the 
`../../..` path components in 
`/tmp/opt/gcc-debug/lib/gcc/x86_64-pc-linux-gnu/11.0.1/../../../../lib64`).

I think it makes sense to use un-normalized paths for both 
`lib/gcc/x86_64-pc-linux-gnu/11.0.1` derived paths and `/usr/include/$triple` 
and `/usr/lib/$triple` and likely make our rules more reasonable.
We can then drop `clang/lib/Driver/ToolChains/Linux.cpp 
Linux::getMultiarchTriple`.
But as it stands, `Linux::getMultiarchTriple` constructed triples have no 
vendor part, so this patch `/usr/include/c++/$triple/c++/v1` will introduce 
some inconsistency.

The change will look like breaking but it actually works on Debian/Ubuntu and 
their derivatives. Because their GCC installation paths have no vendor: 
`lib/gcc/x86_64-linux-gnu`.

> In Fuchsia, we always prefer using normalized triples because that's less 
> error prone. For example, in the past we would install libraries in 
> `/lib/x86_64-fuchsia` which works fine if you invoke the compiler 
> with `--target=x86_64-fuchsia`, but if you instead use 
> `--target=x86_64-unknown-fuchsia` (which some build systems would do), 
> compiler would fail to find libraries because it doesn't know how to 
> denormalize the triple. Using normalized triples addresses the issue because 
> we can always normalize the triple to get a canonical spelling.




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

https://reviews.llvm.org/D89013

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

[PATCH] D99611: [OPENMP]Fix PR48658: [OpenMP 5.0] Compiler crash when OpenMP atomic sync hints used.

[Alexey Bataev via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG66da4f6fc9c1: [OPENMP]Fix PR48658: [OpenMP 5.0] Compiler 
crash when OpenMP atomic sync hints… (authored by ABataev).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99611

Files:
  clang/lib/CodeGen/CGStmtOpenMP.cpp
  clang/test/OpenMP/atomic_codegen.cpp


Index: clang/test/OpenMP/atomic_codegen.cpp
===
--- clang/test/OpenMP/atomic_codegen.cpp
+++ clang/test/OpenMP/atomic_codegen.cpp
@@ -58,7 +58,7 @@
   // CHECK: {{invoke|call}} void @_ZN2StD1Ev(%struct.St* {{[^,]*}} 
[[TEMP_ST_ADDR]])
 #pragma omp atomic
   St().get() %= b;
-#pragma omp atomic
+#pragma omp atomic hint(6)
   s.field++;
   // CHECK: invoke void @_ZN2StC1Ev(%struct.St* {{[^,]*}} 
[[TEMP_ST_ADDR:%.+]])
   // CHECK: [[SCALAR_ADDR:%.+]] = invoke nonnull align 4 
dereferenceable(4) i32* @_ZN2St3getEv(%struct.St* {{[^,]*}} [[TEMP_ST_ADDR]])
Index: clang/lib/CodeGen/CGStmtOpenMP.cpp
===
--- clang/lib/CodeGen/CGStmtOpenMP.cpp
+++ clang/lib/CodeGen/CGStmtOpenMP.cpp
@@ -5594,7 +5594,11 @@
   case OMPC_exclusive:
   case OMPC_uses_allocators:
   case OMPC_affinity:
-  default:
+  case OMPC_init:
+  case OMPC_inbranch:
+  case OMPC_notinbranch:
+  case OMPC_link:
+  case OMPC_use:
 llvm_unreachable("Clause is not allowed in 'omp atomic'.");
   }
 }
@@ -5626,7 +5630,7 @@
 C->getClauseKind() != OMPC_acq_rel &&
 C->getClauseKind() != OMPC_acquire &&
 C->getClauseKind() != OMPC_release &&
-C->getClauseKind() != OMPC_relaxed) {
+C->getClauseKind() != OMPC_relaxed && C->getClauseKind() != OMPC_hint) 
{
   Kind = C->getClauseKind();
   break;
 }


Index: clang/test/OpenMP/atomic_codegen.cpp
===
--- clang/test/OpenMP/atomic_codegen.cpp
+++ clang/test/OpenMP/atomic_codegen.cpp
@@ -58,7 +58,7 @@
   // CHECK: {{invoke|call}} void @_ZN2StD1Ev(%struct.St* {{[^,]*}} [[TEMP_ST_ADDR]])
 #pragma omp atomic
   St().get() %= b;
-#pragma omp atomic
+#pragma omp atomic hint(6)
   s.field++;
   // CHECK: invoke void @_ZN2StC1Ev(%struct.St* {{[^,]*}} [[TEMP_ST_ADDR:%.+]])
   // CHECK: [[SCALAR_ADDR:%.+]] = invoke nonnull align 4 dereferenceable(4) i32* @_ZN2St3getEv(%struct.St* {{[^,]*}} [[TEMP_ST_ADDR]])
Index: clang/lib/CodeGen/CGStmtOpenMP.cpp
===
--- clang/lib/CodeGen/CGStmtOpenMP.cpp
+++ clang/lib/CodeGen/CGStmtOpenMP.cpp
@@ -5594,7 +5594,11 @@
   case OMPC_exclusive:
   case OMPC_uses_allocators:
   case OMPC_affinity:
-  default:
+  case OMPC_init:
+  case OMPC_inbranch:
+  case OMPC_notinbranch:
+  case OMPC_link:
+  case OMPC_use:
 llvm_unreachable("Clause is not allowed in 'omp atomic'.");
   }
 }
@@ -5626,7 +5630,7 @@
 C->getClauseKind() != OMPC_acq_rel &&
 C->getClauseKind() != OMPC_acquire &&
 C->getClauseKind() != OMPC_release &&
-C->getClauseKind() != OMPC_relaxed) {
+C->getClauseKind() != OMPC_relaxed && C->getClauseKind() != OMPC_hint) {
   Kind = C->getClauseKind();
   break;
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 66da4f6 - [OPENMP]Fix PR48658: [OpenMP 5.0] Compiler crash when OpenMP atomic sync hints used.

[Alexey Bataev via cfe-commits]

Author: Alexey Bataev
Date: 2021-03-31T12:58:24-07:00
New Revision: 66da4f6fc9c1cd2a63f089b9888729292f0709f8

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

LOG: [OPENMP]Fix PR48658: [OpenMP 5.0] Compiler crash when OpenMP atomic sync 
hints used.

No need to consider hint clause kind as the main atomic clause kind at the
codegen.

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

Added: 


Modified: 
clang/lib/CodeGen/CGStmtOpenMP.cpp
clang/test/OpenMP/atomic_codegen.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGStmtOpenMP.cpp 
b/clang/lib/CodeGen/CGStmtOpenMP.cpp
index 5373805f0e1ca..2858369896026 100644
--- a/clang/lib/CodeGen/CGStmtOpenMP.cpp
+++ b/clang/lib/CodeGen/CGStmtOpenMP.cpp
@@ -5594,7 +5594,11 @@ static void emitOMPAtomicExpr(CodeGenFunction , 
OpenMPClauseKind Kind,
   case OMPC_exclusive:
   case OMPC_uses_allocators:
   case OMPC_affinity:
-  default:
+  case OMPC_init:
+  case OMPC_inbranch:
+  case OMPC_notinbranch:
+  case OMPC_link:
+  case OMPC_use:
 llvm_unreachable("Clause is not allowed in 'omp atomic'.");
   }
 }
@@ -5626,7 +5630,7 @@ void CodeGenFunction::EmitOMPAtomicDirective(const 
OMPAtomicDirective ) {
 C->getClauseKind() != OMPC_acq_rel &&
 C->getClauseKind() != OMPC_acquire &&
 C->getClauseKind() != OMPC_release &&
-C->getClauseKind() != OMPC_relaxed) {
+C->getClauseKind() != OMPC_relaxed && C->getClauseKind() != OMPC_hint) 
{
   Kind = C->getClauseKind();
   break;
 }

diff  --git a/clang/test/OpenMP/atomic_codegen.cpp 
b/clang/test/OpenMP/atomic_codegen.cpp
index 47ab0b4e18043..ada47d44cc5d2 100644
--- a/clang/test/OpenMP/atomic_codegen.cpp
+++ b/clang/test/OpenMP/atomic_codegen.cpp
@@ -58,7 +58,7 @@ void parallel_atomic_ewc() {
   // CHECK: {{invoke|call}} void @_ZN2StD1Ev(%struct.St* {{[^,]*}} 
[[TEMP_ST_ADDR]])
 #pragma omp atomic
   St().get() %= b;
-#pragma omp atomic
+#pragma omp atomic hint(6)
   s.field++;
   // CHECK: invoke void @_ZN2StC1Ev(%struct.St* {{[^,]*}} 
[[TEMP_ST_ADDR:%.+]])
   // CHECK: [[SCALAR_ADDR:%.+]] = invoke nonnull align 4 
dereferenceable(4) i32* @_ZN2St3getEv(%struct.St* {{[^,]*}} [[TEMP_ST_ADDR]])



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

[PATCH] D99679: [OPENMP51]Initial support for novariants clause

[Jennifer Yu via Phabricator via cfe-commits]

jyu2 created this revision.
jyu2 added reviewers: mikerice, ABataev, jdoerfert.
jyu2 added projects: LLVM, clang.
Herald added subscribers: arphaman, guansong, yaxunl.
Herald added a reviewer: sscalpone.
jyu2 requested review of this revision.
Herald added a subscriber: sstefan1.

Added basic parsing/sema/serialization support for the 'novariants' clause.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D99679

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

Index: llvm/include/llvm/Frontend/OpenMP/OMP.td
===
--- llvm/include/llvm/Frontend/OpenMP/OMP.td
+++ llvm/include/llvm/Frontend/OpenMP/OMP.td
@@ -276,6 +276,10 @@
 def OMPC_Destroy : Clause<"destroy"> {
   let clangClass = "OMPDestroyClause";
 }
+def OMPC_Novariants : Clause<"novariants"> {
+  let clangClass = "OMPNovariantsClause";
+  let flangClass = "ScalarLogicalExpr";
+}
 def OMPC_Detach : Clause<"detach"> {
   let clangClass = "OMPDetachClause";
 }
@@ -1660,7 +1664,8 @@
 VersionedClause,
 VersionedClause,
 VersionedClause,
-VersionedClause
+VersionedClause,
+VersionedClause
   ];
 }
 def OMP_Unknown : Directive<"unknown"> {
Index: flang/lib/Semantics/check-omp-structure.cpp
===
--- flang/lib/Semantics/check-omp-structure.cpp
+++ flang/lib/Semantics/check-omp-structure.cpp
@@ -729,6 +729,7 @@
 CHECK_SIMPLE_CLAUSE(Write, OMPC_write)
 CHECK_SIMPLE_CLAUSE(Init, OMPC_init)
 CHECK_SIMPLE_CLAUSE(Use, OMPC_use)
+CHECK_SIMPLE_CLAUSE(Novariants, OMPC_novariants)
 
 CHECK_REQ_SCALAR_INT_CLAUSE(Allocator, OMPC_allocator)
 CHECK_REQ_SCALAR_INT_CLAUSE(Grainsize, OMPC_grainsize)
Index: clang/tools/libclang/CIndex.cpp
===
--- clang/tools/libclang/CIndex.cpp
+++ clang/tools/libclang/CIndex.cpp
@@ -2291,6 +2291,10 @@
 Visitor->AddStmt(C->getInteropVar());
 }
 
+void OMPClauseEnqueue::VisitOMPNovariantsClause(const OMPNovariantsClause *C) {
+  Visitor->AddStmt(C->getCondition());
+}
+
 void OMPClauseEnqueue::VisitOMPUnifiedAddressClause(
 const OMPUnifiedAddressClause *) {}
 
Index: clang/test/OpenMP/dispatch_messages.cpp
===
--- clang/test/OpenMP/dispatch_messages.cpp
+++ clang/test/OpenMP/dispatch_messages.cpp
@@ -28,6 +28,24 @@
   // expected-error@+1 {{cannot contain more than one 'nowait' clause}}
   #pragma omp dispatch nowait device(dnum) nowait
   disp_call();
+
+  // expected-error@+1 {{expected '(' after 'novariants'}}
+  #pragma omp dispatch novariants
+  disp_call();
+
+  // expected-error@+3 {{expected expression}}
+  // expected-error@+2 {{expected ')'}}
+  // expected-note@+1 {{to match this '('}}
+  #pragma omp dispatch novariants (
+  disp_call();
+
+  // expected-error@+1 {{cannot contain more than one 'novariants' clause}}
+  #pragma omp dispatch novariants(dnum> 4) novariants(3)
+  disp_call();
+
+  // expected-error@+1 {{use of undeclared identifier 'x'}}
+  #pragma omp dispatch novariants(x)
+  disp_call();
 }
 
 void testit_two() {
Index: clang/test/OpenMP/dispatch_ast_print.cpp
===
--- clang/test/OpenMP/dispatch_ast_print.cpp
+++ clang/test/OpenMP/dispatch_ast_print.cpp
@@ -51,20 +51,22 @@
 void test_one()
 {
   int aaa, bbb, var;
-  //PRINT: #pragma omp dispatch depend(in : var) nowait
+  //PRINT: #pragma omp dispatch depend(in : var) nowait novariants(aaa > 5)
   //DUMP: OMPDispatchDirective
   //DUMP: OMPDependClause
   //DUMP: OMPNowaitClause
-  #pragma omp dispatch depend(in:var) nowait
+  //DUMP: OMPNovariantsClause
+  #pragma omp dispatch depend(in:var) nowait novariants(aaa > 5)
   foo(aaa, );
 
   int *dp = get_device_ptr();
   int dev = get_device();
-  //PRINT: #pragma omp dispatch device(dev) is_device_ptr(dp)
+  //PRINT: #pragma omp dispatch device(dev) is_device_ptr(dp) novariants(dev > 10)
   //DUMP: OMPDispatchDirective
   //DUMP: OMPDeviceClause
   //DUMP: OMPIs_device_ptrClause
-  #pragma omp dispatch device(dev) is_device_ptr(dp)
+  //DUMP: OMPNovariantsClause
+  #pragma omp dispatch device(dev) is_device_ptr(dp) novariants(dev > 10)
   foo(aaa, dp);
 
   //PRINT: #pragma omp dispatch
Index: clang/lib/Serialization/ASTWriter.cpp
===
--- 

[PATCH] D89013: [libcxx] Support per-target __config_site in per-target runtime build

[Petr Hosek via Phabricator via cfe-commits]

phosek added a comment.

In D89013#2660407 , @MaskRay wrote:

> Regarding
>
>   /usr/include/x86_64-unknown-linux-gnu/c++/v1
>   /usr/include/c++/v1
>
> With GCC multiarch, some `include` search paths are preceded by 
> machine-os-env specific suffix directories.
> Note: 'vendor' is not there. So you may see `.../include/x86_64-linux-gnu` 
> but there is no `.../include/x86_64-{pc,unknown}-linux-gnu`
>
>   /usr/local/include/x86_64-linux-gnu # affected by sysroot, 
> multiarch, usually nonexistent
>   /usr/local/include  # affected by sysroot
>   /tmp/opt/gcc-debug/include
>   /tmp/opt/gcc-debug/lib/gcc/x86_64-pc-linux-gnu/11.0.1/include-fixed
>   
> /tmp/opt/gcc-debug/lib/gcc/x86_64-pc-linux-gnu/11.0.1/../../../../x86_64-pc-linux-gnu/include
>   /usr/include/x86_64-linux-gnu   # affected by sysroot, multiarch
>   /usr/include# affected by sysroot
>
> On Debian x86_64, `/usr/include/x86_64-linux-gnu/` exists. Adding 
> `x86_64-pc-linux-gnu` (an possible value of `LLVM_DEFAULT_TARGET_TRIPLE`) may 
> add more confusion.

This was already discussed pretty extensively in the past, but I'll try to give 
a summary.

In the case of GCC, compiler can only compile binaries for a single target 
that's set at configuration time. For example if you configured GCC with 
`--target=x86_64-acme-linux-gnu`,  the build links the binary as 
`x86_64-acme-linux-gnu-gcc` and that binary would look for headers in 
`/usr/include/x86_64-acme-linux-gnu` and libraries in 
`/usr/lib/x86_64-acme-linux-gnu` (among other paths) so there's little 
ambiguity.

In the case of Clang, the situation is a bit more difficult because a single 
compiler supports multiple targets via `--target=` option and there are 
different ways to spell the same target triple. For example, `x86_64-linux-gnu` 
and `x86_64-unknown-linux-gnu` are considered equivalent, the latter is a 
normalized version of the former (since you can omit emit components). The 
question then is where to look for headers and libraries. Currently, we always 
look in two locations: (1) we use `--target=/lib/x86_64-linux-gnu` and then 
`/lib/x86_64-unknown-linux-gnu`.

In Fuchsia, we always prefer using normalized triples because that's less error 
prone. For example, in the past we would install libraries in 
`/lib/x86_64-fuchsia` which works fine if you invoke the compiler with 
`--target=x86_64-fuchsia`, but if you instead use 
`--target=x86_64-unknown-fuchsia` (which some build systems would do), compiler 
would fail to find libraries because it doesn't know how to denormalize the 
triple. Using normalized triples addresses the issue because we can always 
normalize the triple to get a canonical spelling.


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

https://reviews.llvm.org/D89013

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

[PATCH] D89013: [libcxx] Support per-target __config_site in per-target runtime build

[Petr Hosek via Phabricator via cfe-commits]

phosek updated this revision to Diff 334506.

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

https://reviews.llvm.org/D89013

Files:
  clang/lib/Driver/ToolChains/Fuchsia.cpp
  clang/lib/Driver/ToolChains/Gnu.cpp
  clang/test/Driver/fuchsia.cpp
  clang/test/Driver/linux-header-search.cpp
  libcxx/CMakeLists.txt
  libcxx/benchmarks/CMakeLists.txt
  libcxx/include/CMakeLists.txt

Index: libcxx/include/CMakeLists.txt
===
--- libcxx/include/CMakeLists.txt
+++ libcxx/include/CMakeLists.txt
@@ -191,9 +191,9 @@
   wctype.h
   )
 
-configure_file("__config_site.in" "${LIBCXX_GENERATED_INCLUDE_DIR}/__config_site" @ONLY)
+configure_file("__config_site.in" "${LIBCXX_GENERATED_INCLUDE_TARGET_DIR}/__config_site" @ONLY)
 
-set(_all_includes "${LIBCXX_GENERATED_INCLUDE_DIR}/__config_site")
+set(_all_includes "${LIBCXX_GENERATED_INCLUDE_TARGET_DIR}/__config_site")
 foreach(f ${files})
   set(src "${CMAKE_CURRENT_SOURCE_DIR}/${f}")
   set(dst "${LIBCXX_GENERATED_INCLUDE_DIR}/${f}")
@@ -210,24 +210,26 @@
 add_dependencies(cxx-headers generate-cxx-headers ${LIBCXX_CXX_ABI_HEADER_TARGET})
 # TODO: Use target_include_directories once we figure out why that breaks the runtimes build
 if("${CMAKE_CXX_COMPILER_ID}" STREQUAL "MSVC" OR "${CMAKE_CXX_SIMULATE_ID}" STREQUAL "MSVC")
-  target_compile_options(cxx-headers INTERFACE /I "${LIBCXX_GENERATED_INCLUDE_DIR}")
+  target_compile_options(cxx-headers INTERFACE /I "${LIBCXX_GENERATED_INCLUDE_DIR}"
+ INTERFACE /I "${LIBCXX_GENERATED_INCLUDE_TARGET_DIR}")
 else()
-  target_compile_options(cxx-headers INTERFACE -I "${LIBCXX_GENERATED_INCLUDE_DIR}")
+  target_compile_options(cxx-headers INTERFACE -I${LIBCXX_GENERATED_INCLUDE_DIR}
+ INTERFACE -I${LIBCXX_GENERATED_INCLUDE_TARGET_DIR})
 endif()
 
 if (LIBCXX_INSTALL_HEADERS)
   foreach(file ${files})
 get_filename_component(dir ${file} DIRECTORY)
 install(FILES ${file}
-  DESTINATION ${LIBCXX_INSTALL_HEADER_PREFIX}include/c++/v1/${dir}
+  DESTINATION ${LIBCXX_INSTALL_HEADER_PREFIX}${LIBCXX_INSTALL_HEADER_DIR}/${dir}
   COMPONENT cxx-headers
   PERMISSIONS OWNER_READ OWNER_WRITE GROUP_READ WORLD_READ
 )
   endforeach()
 
   # Install the generated __config_site.
-  install(FILES ${LIBCXX_GENERATED_INCLUDE_DIR}/__config_site
-DESTINATION ${LIBCXX_INSTALL_HEADER_PREFIX}include/c++/v1
+  install(FILES ${LIBCXX_GENERATED_INCLUDE_TARGET_DIR}/__config_site
+DESTINATION ${LIBCXX_INSTALL_HEADER_PREFIX}${LIBCXX_INSTALL_INCLUDE_TARGET_DIR}
 PERMISSIONS OWNER_READ OWNER_WRITE GROUP_READ WORLD_READ
 COMPONENT cxx-headers)
 
Index: libcxx/benchmarks/CMakeLists.txt
===
--- libcxx/benchmarks/CMakeLists.txt
+++ libcxx/benchmarks/CMakeLists.txt
@@ -15,6 +15,10 @@
 -Wl,-rpath,${LIBCXX_LIBRARY_DIR}
 ${SANITIZER_FLAGS}
 )
+if(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR AND NOT APPLE)
+  list(APPEND BENCHMARK_LIBCXX_COMPILE_FLAGS
+-isystem "${LIBCXX_GENERATED_INCLUDE_TARGET_DIR}")
+endif()
 if (DEFINED LIBCXX_CXX_ABI_LIBRARY_PATH)
   list(APPEND BENCHMARK_LIBCXX_COMPILE_FLAGS
   -L${LIBCXX_CXX_ABI_LIBRARY_PATH}
Index: libcxx/CMakeLists.txt
===
--- libcxx/CMakeLists.txt
+++ libcxx/CMakeLists.txt
@@ -408,7 +408,10 @@
 if(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR AND NOT APPLE)
   set(LIBCXX_LIBRARY_DIR ${LLVM_LIBRARY_OUTPUT_INTDIR}/${LLVM_DEFAULT_TARGET_TRIPLE}/c++)
   set(LIBCXX_GENERATED_INCLUDE_DIR "${LLVM_BINARY_DIR}/include/c++/v1")
+  set(LIBCXX_GENERATED_INCLUDE_TARGET_DIR "${LLVM_BINARY_DIR}/include/${LLVM_DEFAULT_TARGET_TRIPLE}/c++/v1")
   set(LIBCXX_INSTALL_LIBRARY_DIR lib${LLVM_LIBDIR_SUFFIX}/${LLVM_DEFAULT_TARGET_TRIPLE}/c++)
+  set(LIBCXX_INSTALL_INCLUDE_DIR "include/c++/v1")
+  set(LIBCXX_INSTALL_INCLUDE_TARGET_DIR "include/${LLVM_DEFAULT_TARGET_TRIPLE}/c++/v1")
   if(LIBCXX_LIBDIR_SUBDIR)
 string(APPEND LIBCXX_LIBRARY_DIR /${LIBCXX_LIBDIR_SUBDIR})
 string(APPEND LIBCXX_INSTALL_LIBRARY_DIR /${LIBCXX_LIBDIR_SUBDIR})
@@ -416,11 +419,17 @@
 elseif(LLVM_LIBRARY_OUTPUT_INTDIR)
   set(LIBCXX_LIBRARY_DIR ${LLVM_LIBRARY_OUTPUT_INTDIR})
   set(LIBCXX_GENERATED_INCLUDE_DIR "${LLVM_BINARY_DIR}/include/c++/v1")
+  set(LIBCXX_GENERATED_INCLUDE_TARGET_DIR "${LIBCXX_GENERATED_INCLUDE_DIR}")
   set(LIBCXX_INSTALL_LIBRARY_DIR lib${LIBCXX_LIBDIR_SUFFIX})
+  set(LIBCXX_INSTALL_INCLUDE_DIR "include/c++/v1")
+  set(LIBCXX_INSTALL_INCLUDE_TARGET_DIR "${LIBCXX_INSTALL_INCLUDE_DIR}")
 else()
   set(LIBCXX_LIBRARY_DIR ${CMAKE_BINARY_DIR}/lib${LIBCXX_LIBDIR_SUFFIX})
   set(LIBCXX_GENERATED_INCLUDE_DIR "${CMAKE_BINARY_DIR}/include/c++/v1")
+  set(LIBCXX_GENERATED_INCLUDE_TARGET_DIR "${LIBCXX_GENERATED_INCLUDE_DIR}")
   set(LIBCXX_INSTALL_LIBRARY_DIR lib${LIBCXX_LIBDIR_SUFFIX})
+  set(LIBCXX_INSTALL_INCLUDE_DIR "include/c++/v1")
+  

[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

[Harald van Dijk via Phabricator via cfe-commits]

hvdijk updated this revision to Diff 334505.
hvdijk retitled this revision from "WIP: [Driver] Fix architecture triplets and 
search paths for Linux x32" to "[Driver] Fix architecture triplets and search 
paths for Linux x32".
hvdijk added a comment.

Tests now updated differently, avoiding the need to explicitly list libx32 as 
an allowed libdir. In clang/test/Preprocessor/iwithprefix.c's case, for the 
purposes of the test, it is not necessary to look at what appears before 
/clang/. In the other tests, it is possible to capture the -resource-dir string 
and use that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D52050

Files:
  clang/lib/Driver/ToolChains/Gnu.cpp
  
clang/test/Driver/Inputs/basic_cross_linux_tree/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/x32/crtbegin.o
  
clang/test/Driver/Inputs/basic_cross_linux_tree/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/x32/crtbeginT.o
  
clang/test/Driver/Inputs/basic_cross_linux_tree/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/x32/crtfastmath.o
  clang/test/Driver/baremetal.cpp
  clang/test/Driver/cl-options.c
  clang/test/Preprocessor/iwithprefix.c

Index: clang/test/Preprocessor/iwithprefix.c
===
--- clang/test/Preprocessor/iwithprefix.c
+++ clang/test/Preprocessor/iwithprefix.c
@@ -9,8 +9,6 @@
 
 // CHECK: #include <...> search starts here:
 // CHECK: {{.*}}.tmps/first
-// CHECK: {{/|\\}}lib{{(32|64)?}}{{/|\\}}clang{{/|\\}}{{[.0-9]+}}{{/|\\}}include
+// CHECK: {{/|\\}}clang{{/|\\}}{{[.0-9]+}}{{/|\\}}include
 // CHECK: {{.*}}.tmps/second
 // CHECK-NOT: {{.*}}.tmps
-
-
Index: clang/test/Driver/cl-options.c
===
--- clang/test/Driver/cl-options.c
+++ clang/test/Driver/cl-options.c
@@ -118,7 +118,8 @@
 // RUN: %clang_cl /imsvcmyincludedir -### -- %s 2>&1 | FileCheck -check-prefix=SLASH_imsvc %s
 // RUN: %clang_cl /imsvc myincludedir -### -- %s 2>&1 | FileCheck -check-prefix=SLASH_imsvc %s
 // Clang's resource header directory should be first:
-// SLASH_imsvc: "-internal-isystem" "{{[^"]*}}lib{{(64)?/|}}clang{{[^"]*}}include"
+// SLASH_imsvc: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
+// SLASH_imsvc: "-internal-isystem" "[[RESOURCE_DIR]]{{[/\\]+}}include"
 // SLASH_imsvc: "-internal-isystem" "myincludedir"
 
 // RUN: %clang_cl /J -### -- %s 2>&1 | FileCheck -check-prefix=J %s
Index: clang/test/Driver/baremetal.cpp
===
--- clang/test/Driver/baremetal.cpp
+++ clang/test/Driver/baremetal.cpp
@@ -33,8 +33,9 @@
 // RUN: -target armv6m-none-eabi \
 // RUN: --sysroot=%S/Inputs/baremetal_arm \
 // RUN:   | FileCheck --check-prefix=CHECK-V6M-DEFAULTCXX %s
+// CHECK-V6M-DEFAULTCXX: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
 // CHECK-V6M-DEFAULTCXX: "{{[^"]*}}ld{{(\.(lld|bfd|gold))?}}{{(\.exe)?}}" "{{.*}}.o" "-Bstatic"
-// CHECK-V6M-DEFAULTCXX-SAME: "-L{{[^"]*}}{{[/\\]+}}lib{{(64)?}}{{[/\\]+}}clang{{[/\\]+}}{{.*}}{{[/\\]+}}lib{{[/\\]+}}baremetal"
+// CHECK-V6M-DEFAULTCXX-SAME: "-L[[RESOURCE_DIR]]{{[/\\]+}}lib{{[/\\]+}}baremetal"
 // CHECK-V6M-DEFAULTCXX-SAME: "-L{{[^"]*}}{{[/\\]+}}Inputs{{[/\\]+}}baremetal_arm{{[/\\]+}}lib"
 // CHECK-V6M-DEFAULTCXX-SAME: "-lc++" "-lc++abi" "-lunwind"
 // CHECK-V6M-DEFAULTCXX-SAME: "-lc" "-lm" "-lclang_rt.builtins-armv6m"
@@ -45,10 +46,11 @@
 // RUN: --sysroot=%S/Inputs/baremetal_arm \
 // RUN: -stdlib=libc++ \
 // RUN:   | FileCheck --check-prefix=CHECK-V6M-LIBCXX %s
+// CHECK-V6M-LIBCXX: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
 // CHECK-V6M-LIBCXX-NOT: "-internal-isystem" "{{[^"]+}}{{[/\\]+}}include{{[/\\]+}}c++{{[/\\]+}}{{[^v].*}}"
-// CHECK-V6M-LIBCXX: "-internal-isystem" "{{[^"]+}}{{[/\\]+}}include{{[/\\]+}}c++{{[/\\]+}}v1"
+// CHECK-V6M-LIBCXX-SAME: "-internal-isystem" "{{[^"]+}}{{[/\\]+}}include{{[/\\]+}}c++{{[/\\]+}}v1"
 // CHECK-V6M-LIBCXX: "{{[^"]*}}ld{{(\.(lld|bfd|gold))?}}{{(\.exe)?}}" "{{.*}}.o" "-Bstatic"
-// CHECK-V6M-LIBCXX-SAME: "-L{{[^"]*}}{{[/\\]+}}lib{{(64)?}}{{[/\\]+}}clang{{[/\\]+}}{{.*}}{{[/\\]+}}lib{{[/\\]+}}baremetal"
+// CHECK-V6M-LIBCXX-SAME: "-L[[RESOURCE_DIR]]{{[/\\]+}}lib{{[/\\]+}}baremetal"
 // CHECK-V6M-LIBCXX-SAME: "-L{{[^"]*}}{{[/\\]+}}Inputs{{[/\\]+}}baremetal_arm{{[/\\]+}}lib"
 // CHECK-V6M-LIBCXX-SAME: "-lc++" "-lc++abi" "-lunwind"
 // CHECK-V6M-LIBCXX-SAME: "-lc" "-lm" "-lclang_rt.builtins-armv6m"
@@ -59,10 +61,11 @@
 // RUN: --sysroot=%S/Inputs/baremetal_arm \
 // RUN: -stdlib=libstdc++ \
 // RUN:   | FileCheck --check-prefix=CHECK-V6M-LIBSTDCXX %s
+// CHECK-V6M-LIBSTDCXX: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
 // CHECK-V6M-LIBSTDCXX-NOT: "-internal-isystem" "{{[^"]+}}{{[/\\]+}}include{{[/\\]+}}c++{{[/\\]+}}v1"
-// CHECK-V6M-LIBSTDCXX: "-internal-isystem" "{{[^"]+}}{{[/\\]+}}include{{[/\\]+}}c++{{[/\\]+}}6.0.0"
+// CHECK-V6M-LIBSTDCXX-SAME: "-internal-isystem" 

[PATCH] D99675: RFC [llvm][clang] Create new intrinsic llvm.arith.fence to control FP optimization at expression level

[Melanie Blower via Phabricator via cfe-commits]

mibintc created this revision.
mibintc added reviewers: andrew.w.kaylor, pengfei, kbsmith1.
Herald added subscribers: dexonsmith, jfb, hiraditya.
mibintc requested review of this revision.
Herald added a subscriber: jdoerfert.
Herald added a project: LLVM.

This is a proposal to add a new llvm intrinsic, llvm.arith.fence.  The purpose 
is to provide fine control, at the expression level, over floating point 
optimization when -ffast-math (-ffp-model=fast) is enabled.  We are also 
proposing a new clang builtin that provides access to this intrinsic, as well 
as a new clang command line option `-fprotect-parens` that will be implemented 
using this intrinsic.

This patch is authored by @pengfei

Rationale
-

Some expression transformations that are mathematically correct, such as 
reassociation and distribution, may be incorrect when dealing with finite 
precision floating point.  For example, these two expressions,

  (a + b) + c
  a + (b + c)

are equivalent mathematically in integer arithmetic, but not in floating point. 
 In some floating point (FP) models, the compiler is allowed to make these 
value-unsafe transformations for performance reasons, even when the programmer 
uses parentheses explicitly.  But the compiler must always honor the 
parentheses implied by llvm.arith.fence, regardless of the FP model settings.

Under `–ffp-model=fast`, llvm.arith.fence provides a way to partially enforce 
ordering in an FP expression.

| Original expression   | Transformed expression | Permitted? |
| - | -- | -- |
| (a + b) + c   | a + (b + c)| Yes!   |
| llvm.arith.fence((a + b) + c) | a + (b + c)| No!|
|



NOTE: The llvm.arith.fence serves no purpose in value-safe FP modes like 
`–ffp-model=precise`:  FP expressions are already strictly ordered.

The new llvm intrinsic also enables the implementation of the option 
`-fprotect-parens` which is available in gfortran as well as the Intel C++ and 
Fortran compilers: icc and ifort.

Proposed llvm IR changes


Requirements for llvm.arith.fence:

- There is one operand. The input to the intrinsic is an llvm::Value and must 
be scalar floating point or vector floating point.
- The return type is the same as the operand type.
- The return value is equivalent to the operand.

Optimizing llvm.arith.fence
---

- Constant folding may substitute the constant value of the llvm.arith.fence 
operand for the value of fence itself in the case where the operand is constant.
- CSE Detection: No special changes needed: if E1 and E2 are CSE, then 
llvm.arith.fence(E1) and llvm.arith.fence(E2) are CSE.
- FMA transformation should be enabled, at least in the -ffp-model=fast case.
  - The expression “llvm.arith.fence(a * b) + c” means that “a * b” must happen 
before “+ c” and FMA guarantees that, but to prevent later optimizations from 
unpacking the FMA the correct transformation needs to be:

  llvm.arith.fence(a * b) + c  →  llvm.arith.fence(FMA(a, b, c)) 



- In the ffp-model=fast case, FMA formation doesn’t happen until Isel, so we 
just need to add the llvm.arith.fence cases to ISel pattern matching.
- There are some choices around the FMA optimization. For this example:

  %t1 = fmul double %x, %y
  %t2 = call double @llvm.arith.fence.f64(double %t1)
  %t3 = fadd contract double %t2, %z

  1. FMA is allowed across an arith.fence if and only if the FMF `contract` 
flag is set for the llvm.arith.fence operand. //We are recommending this 
choice.//
  2. FMA is not allowed across a fence
  3. The FMF `contract` flag should be set on the llvm.arith.fence intrinsic 
call if contraction should be enabled
- Fast Math Optimization:
  - The result of a llvm.arith.fence can participate in fast math 
optimizations.  For example:

  // This transformation is legal:
  w + llvm.arith.fence(x + y) + z   →   w + z + llvm.arith.fence(x + y)

- The operand of a llvm.arith.fence can participate in fast math optimizations. 
 For example:

  // This transformation is legal:
  llvm.arith.fence((x+y)+z) --> llvm.arith.fence(x+(y+z))



NOTE: We want fast-math optimization within the fence, but not across the fence.



- MIR Optimization:
  - The use of a pseudo-operation in the MIR serves the same purpose as the 
intrinsic in the IR,  since all the optimizations are based on patterns 
matching from known DAGs/MIs.
  - Backend simply respects the llvm.arith.fence intrinsic, builds 
llvm.arith.fence node during DAG/ISel and emits pseudo arithmetic_fence MI 
after it.
  - The pseudo arithmetic_fence MI turns into a comment when emitting assembly.

Other llvm changes needed -- utility functions
--

The ValueTracking utilities will need to be taught to handle the new intrinsic. 
For example, there are utility functions like `isKnownNeverNaN()` and 
`CannotBeOrderedLessThanZero()` that will 

[PATCH] D75041: [clang-tidy] Extend 'bugprone-easily-swappable-parameters' with mixability because of implicit conversions

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.cpp:203
+SmallVector Ret;
+const auto  = [](QualType QT) {
+  if (QT.isNull())





Comment at: 
clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.cpp:207
+
+  LLVM_DEBUG(QT.dump());
+

whisperity wrote:
> Actually this is one of those debug prints that should be removed and 
> remained in here by accident.
Agreed, this one should be removed.


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

https://reviews.llvm.org/D75041

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

[PATCH] D99622: [OpenMP51] Accept `primary` as proc bind affinity policy in Clang

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added inline comments.



Comment at: 
clang/test/OpenMP/nvptx_target_parallel_proc_bind_codegen.cpp:110-147
+// Test target codegen - host bc file has to be created first.
+// RUN: %clang_cc1 -DCK2 -verify -fopenmp -fopenmp-version=45 
-fopenmp-cuda-mode -x c++ -triple powerpc64le-unknown-unknown 
-fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm-bc %s -o %t-ppc-host.bc
+// RUN: %clang_cc1 -DCK2 -verify -fopenmp -fopenmp-version=45 
-fopenmp-cuda-mode -x c++ -triple nvptx64-unknown-unknown 
-fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm %s -fopenmp-is-device 
-fopenmp-host-ir-file-path %t-ppc-host.bc -o - | FileCheck %s --check-prefix 
CK2 --check-prefix CK2-64
+// RUN: %clang_cc1 -DCK2 -verify -fopenmp -fopenmp-version=45 
-fopenmp-cuda-mode -x c++ -triple i386-unknown-unknown 
-fopenmp-targets=nvptx-nvidia-cuda -emit-llvm-bc %s -o %t-x86-host.bc
+// RUN: %clang_cc1 -DCK2 -verify -fopenmp -fopenmp-version=45 
-fopenmp-cuda-mode -x c++ -triple nvptx-unknown-unknown 
-fopenmp-targets=nvptx-nvidia-cuda -emit-llvm %s -fopenmp-is-device 
-fopenmp-host-ir-file-path %t-x86-host.bc -o - | FileCheck %s --check-prefix 
CK2 --check-prefix CK2-32
+// RUN: %clang_cc1 -DCK2 -verify -fopenmp -fopenmp-version=45 
-fopenmp-cuda-mode -fexceptions -fcxx-exceptions -x c++ -triple 
nvptx-unknown-unknown -fopenmp-targets=nvptx-nvidia-cuda -emit-llvm %s 
-fopenmp-is-device -fopenmp-host-ir-file-path %t-x86-host.bc -o - | FileCheck 
%s --check-prefix CK2 --check-prefix CK2-32
+

cchen wrote:
> ABataev wrote:
> > Put this part in a separate file, please
> Do you mean I should put all the `primary` tests into a single file and don't 
> do any changes to the existing proc_bind tests?
Yes, keep the original tests and add new ones.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99622

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

[PATCH] D99622: [OpenMP51] Accept `primary` as proc bind affinity policy in Clang

[Chi Chun Chen via Phabricator via cfe-commits]

cchen added inline comments.



Comment at: 
clang/test/OpenMP/nvptx_target_parallel_proc_bind_codegen.cpp:110-147
+// Test target codegen - host bc file has to be created first.
+// RUN: %clang_cc1 -DCK2 -verify -fopenmp -fopenmp-version=45 
-fopenmp-cuda-mode -x c++ -triple powerpc64le-unknown-unknown 
-fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm-bc %s -o %t-ppc-host.bc
+// RUN: %clang_cc1 -DCK2 -verify -fopenmp -fopenmp-version=45 
-fopenmp-cuda-mode -x c++ -triple nvptx64-unknown-unknown 
-fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm %s -fopenmp-is-device 
-fopenmp-host-ir-file-path %t-ppc-host.bc -o - | FileCheck %s --check-prefix 
CK2 --check-prefix CK2-64
+// RUN: %clang_cc1 -DCK2 -verify -fopenmp -fopenmp-version=45 
-fopenmp-cuda-mode -x c++ -triple i386-unknown-unknown 
-fopenmp-targets=nvptx-nvidia-cuda -emit-llvm-bc %s -o %t-x86-host.bc
+// RUN: %clang_cc1 -DCK2 -verify -fopenmp -fopenmp-version=45 
-fopenmp-cuda-mode -x c++ -triple nvptx-unknown-unknown 
-fopenmp-targets=nvptx-nvidia-cuda -emit-llvm %s -fopenmp-is-device 
-fopenmp-host-ir-file-path %t-x86-host.bc -o - | FileCheck %s --check-prefix 
CK2 --check-prefix CK2-32
+// RUN: %clang_cc1 -DCK2 -verify -fopenmp -fopenmp-version=45 
-fopenmp-cuda-mode -fexceptions -fcxx-exceptions -x c++ -triple 
nvptx-unknown-unknown -fopenmp-targets=nvptx-nvidia-cuda -emit-llvm %s 
-fopenmp-is-device -fopenmp-host-ir-file-path %t-x86-host.bc -o - | FileCheck 
%s --check-prefix CK2 --check-prefix CK2-32
+

ABataev wrote:
> Put this part in a separate file, please
Do you mean I should put all the `primary` tests into a single file and don't 
do any changes to the existing proc_bind tests?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99622

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

[PATCH] D88452: [Driver] Move detectLibcxxIncludePath to ToolChain

[Petr Hosek via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGfcf680050686: [Driver] Move detectLibcxxIncludePath to 
ToolChain (authored by phosek).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88452

Files:
  clang/include/clang/Driver/ToolChain.h
  clang/lib/Driver/ToolChain.cpp
  clang/lib/Driver/ToolChains/Fuchsia.cpp
  clang/lib/Driver/ToolChains/Gnu.cpp
  clang/test/Driver/Inputs/basic_fuchsia_tree/include/c++/v1/.keep

Index: clang/lib/Driver/ToolChains/Gnu.cpp
===
--- clang/lib/Driver/ToolChains/Gnu.cpp
+++ clang/lib/Driver/ToolChains/Gnu.cpp
@@ -2892,32 +2892,13 @@
   }
 }
 
-static std::string DetectLibcxxIncludePath(llvm::vfs::FileSystem ,
-   StringRef base) {
-  std::error_code EC;
-  int MaxVersion = 0;
-  std::string MaxVersionString;
-  for (llvm::vfs::directory_iterator LI = vfs.dir_begin(base, EC), LE;
-   !EC && LI != LE; LI = LI.increment(EC)) {
-StringRef VersionText = llvm::sys::path::filename(LI->path());
-int Version;
-if (VersionText[0] == 'v' &&
-!VersionText.slice(1, StringRef::npos).getAsInteger(10, Version)) {
-  if (Version > MaxVersion) {
-MaxVersion = Version;
-MaxVersionString = std::string(VersionText);
-  }
-}
-  }
-  return MaxVersion ? (base + "/" + MaxVersionString).str() : "";
-}
-
 void
 Generic_GCC::addLibCxxIncludePaths(const llvm::opt::ArgList ,
llvm::opt::ArgStringList ) const {
   auto AddIncludePath = [&](std::string Path) {
-std::string IncludePath = DetectLibcxxIncludePath(getVFS(), Path);
-if (IncludePath.empty() || !getVFS().exists(IncludePath))
+std::string Version = detectLibcxxVersion(Path);
+std::string IncludePath = Path + "/c++/" + Version;
+if (Version.empty() || !getVFS().exists(IncludePath))
   return false;
 addSystemInclude(DriverArgs, CC1Args, IncludePath);
 return true;
@@ -2925,15 +2906,15 @@
   // Android never uses the libc++ headers installed alongside the toolchain,
   // which are generally incompatible with the NDK libraries anyway.
   if (!getTriple().isAndroid())
-if (AddIncludePath(getDriver().Dir + "/../include/c++"))
+if (AddIncludePath(getDriver().Dir + "/../include"))
   return;
   // If this is a development, non-installed, clang, libcxx will
   // not be found at ../include/c++ but it likely to be found at
   // one of the following two locations:
   std::string SysRoot = computeSysRoot();
-  if (AddIncludePath(SysRoot + "/usr/local/include/c++"))
+  if (AddIncludePath(SysRoot + "/usr/local/include"))
 return;
-  if (AddIncludePath(SysRoot + "/usr/include/c++"))
+  if (AddIncludePath(SysRoot + "/usr/include"))
 return;
 }
 
Index: clang/lib/Driver/ToolChains/Fuchsia.cpp
===
--- clang/lib/Driver/ToolChains/Fuchsia.cpp
+++ clang/lib/Driver/ToolChains/Fuchsia.cpp
@@ -365,7 +365,9 @@
   switch (GetCXXStdlibType(DriverArgs)) {
   case ToolChain::CST_Libcxx: {
 SmallString<128> P(getDriver().Dir);
-llvm::sys::path::append(P, "..", "include", "c++", "v1");
+llvm::sys::path::append(P, "..", "include");
+std::string Version = detectLibcxxVersion(P);
+llvm::sys::path::append(P, "c++", Version);
 addSystemInclude(DriverArgs, CC1Args, P.str());
 break;
   }
Index: clang/lib/Driver/ToolChain.cpp
===
--- clang/lib/Driver/ToolChain.cpp
+++ clang/lib/Driver/ToolChain.cpp
@@ -898,6 +898,29 @@
   }
 }
 
+std::string ToolChain::detectLibcxxVersion(StringRef IncludePath) const {
+  std::error_code EC;
+  int MaxVersion = 0;
+  std::string MaxVersionString;
+  SmallString<128> Path(IncludePath);
+  llvm::sys::path::append(Path, "c++");
+  for (llvm::vfs::directory_iterator LI = getVFS().dir_begin(Path, EC), LE;
+   !EC && LI != LE; LI = LI.increment(EC)) {
+StringRef VersionText = llvm::sys::path::filename(LI->path());
+int Version;
+if (VersionText[0] == 'v' &&
+!VersionText.slice(1, StringRef::npos).getAsInteger(10, Version)) {
+  if (Version > MaxVersion) {
+MaxVersion = Version;
+MaxVersionString = std::string(VersionText);
+  }
+}
+  }
+  if (!MaxVersion)
+return "";
+  return MaxVersionString;
+}
+
 void ToolChain::AddClangCXXStdlibIncludeArgs(const ArgList ,
  ArgStringList ) const {
   // Header search paths should be handled by each of the subclasses.
Index: clang/include/clang/Driver/ToolChain.h
===
--- clang/include/clang/Driver/ToolChain.h
+++ clang/include/clang/Driver/ToolChain.h
@@ -603,6 +603,9 @@
   // given compilation arguments.
   virtual UnwindLibType 

[clang] fcf6800 - [Driver] Move detectLibcxxIncludePath to ToolChain

[Petr Hosek via cfe-commits]

Author: Petr Hosek
Date: 2021-03-31T10:50:44-07:00
New Revision: fcf6800506862586e2d409aaa03a1cff818edfcc

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

LOG: [Driver] Move detectLibcxxIncludePath to ToolChain

This helper method is useful even outside of Gnu toolchains, so move
it to ToolChain so it can be reused in other toolchains such as Fuchsia.

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

Added: 
clang/test/Driver/Inputs/basic_fuchsia_tree/include/c++/v1/.keep

Modified: 
clang/include/clang/Driver/ToolChain.h
clang/lib/Driver/ToolChain.cpp
clang/lib/Driver/ToolChains/Fuchsia.cpp
clang/lib/Driver/ToolChains/Gnu.cpp

Removed: 




diff  --git a/clang/include/clang/Driver/ToolChain.h 
b/clang/include/clang/Driver/ToolChain.h
index e7e5a1f7a6ad0..e5c6b8104c6f8 100644
--- a/clang/include/clang/Driver/ToolChain.h
+++ b/clang/include/clang/Driver/ToolChain.h
@@ -603,6 +603,9 @@ class ToolChain {
   // given compilation arguments.
   virtual UnwindLibType GetUnwindLibType(const llvm::opt::ArgList ) const;
 
+  // Detect the highest available version of libc++ in include path.
+  virtual std::string detectLibcxxVersion(StringRef IncludePath) const;
+
   /// AddClangCXXStdlibIncludeArgs - Add the clang -cc1 level arguments to set
   /// the include paths to use for the given C++ standard library type.
   virtual void

diff  --git a/clang/lib/Driver/ToolChain.cpp b/clang/lib/Driver/ToolChain.cpp
index 6b747f06439fa..e32bbae99fe89 100644
--- a/clang/lib/Driver/ToolChain.cpp
+++ b/clang/lib/Driver/ToolChain.cpp
@@ -898,6 +898,29 @@ void ToolChain::addExternCSystemIncludeIfExists(const 
ArgList ,
   }
 }
 
+std::string ToolChain::detectLibcxxVersion(StringRef IncludePath) const {
+  std::error_code EC;
+  int MaxVersion = 0;
+  std::string MaxVersionString;
+  SmallString<128> Path(IncludePath);
+  llvm::sys::path::append(Path, "c++");
+  for (llvm::vfs::directory_iterator LI = getVFS().dir_begin(Path, EC), LE;
+   !EC && LI != LE; LI = LI.increment(EC)) {
+StringRef VersionText = llvm::sys::path::filename(LI->path());
+int Version;
+if (VersionText[0] == 'v' &&
+!VersionText.slice(1, StringRef::npos).getAsInteger(10, Version)) {
+  if (Version > MaxVersion) {
+MaxVersion = Version;
+MaxVersionString = std::string(VersionText);
+  }
+}
+  }
+  if (!MaxVersion)
+return "";
+  return MaxVersionString;
+}
+
 void ToolChain::AddClangCXXStdlibIncludeArgs(const ArgList ,
  ArgStringList ) const {
   // Header search paths should be handled by each of the subclasses.

diff  --git a/clang/lib/Driver/ToolChains/Fuchsia.cpp 
b/clang/lib/Driver/ToolChains/Fuchsia.cpp
index 25b7e4ed1d526..17671b37ad1db 100644
--- a/clang/lib/Driver/ToolChains/Fuchsia.cpp
+++ b/clang/lib/Driver/ToolChains/Fuchsia.cpp
@@ -365,7 +365,9 @@ void Fuchsia::AddClangCXXStdlibIncludeArgs(const ArgList 
,
   switch (GetCXXStdlibType(DriverArgs)) {
   case ToolChain::CST_Libcxx: {
 SmallString<128> P(getDriver().Dir);
-llvm::sys::path::append(P, "..", "include", "c++", "v1");
+llvm::sys::path::append(P, "..", "include");
+std::string Version = detectLibcxxVersion(P);
+llvm::sys::path::append(P, "c++", Version);
 addSystemInclude(DriverArgs, CC1Args, P.str());
 break;
   }

diff  --git a/clang/lib/Driver/ToolChains/Gnu.cpp 
b/clang/lib/Driver/ToolChains/Gnu.cpp
index 0fe3916b008e5..2c201a6739c00 100644
--- a/clang/lib/Driver/ToolChains/Gnu.cpp
+++ b/clang/lib/Driver/ToolChains/Gnu.cpp
@@ -2892,32 +2892,13 @@ void Generic_GCC::AddClangCXXStdlibIncludeArgs(const 
ArgList ,
   }
 }
 
-static std::string DetectLibcxxIncludePath(llvm::vfs::FileSystem ,
-   StringRef base) {
-  std::error_code EC;
-  int MaxVersion = 0;
-  std::string MaxVersionString;
-  for (llvm::vfs::directory_iterator LI = vfs.dir_begin(base, EC), LE;
-   !EC && LI != LE; LI = LI.increment(EC)) {
-StringRef VersionText = llvm::sys::path::filename(LI->path());
-int Version;
-if (VersionText[0] == 'v' &&
-!VersionText.slice(1, StringRef::npos).getAsInteger(10, Version)) {
-  if (Version > MaxVersion) {
-MaxVersion = Version;
-MaxVersionString = std::string(VersionText);
-  }
-}
-  }
-  return MaxVersion ? (base + "/" + MaxVersionString).str() : "";
-}
-
 void
 Generic_GCC::addLibCxxIncludePaths(const llvm::opt::ArgList ,
llvm::opt::ArgStringList ) const {
   auto AddIncludePath = [&](std::string Path) {
-std::string IncludePath = DetectLibcxxIncludePath(getVFS(), Path);
-if (IncludePath.empty() || !getVFS().exists(IncludePath))
+std::string Version = 

[PATCH] D93095: Introduce -Wreserved-identifier

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

rsmith added inline comments.



Comment at: clang/lib/AST/Decl.cpp:1097
+  // ignored values) that we don't warn on it.
+  if (Name.size() <= 1)
+return ReservedIdentifierStatus::NotReserved;

serge-sans-paille wrote:
> rsmith wrote:
> > Would it make sense to move the rest of this function to a member on 
> > `IdentifierInfo`? That is, the rest of this function would become:
> > 
> > ```
> > ReservedIdentifierStatus Status = II->isReserved(LangOpts);
> > if (Status == ReservedIdentifierStatus::StartsWithUnderscoreAtGlobalScope &&
> > isa(this) || isTemplateParameter() ||
> > !getDeclContext()->getRedeclContext()->isTranslationUnit())
> >   return ReservedIdentifierStatus::NotReserved;
> > return Status;
> > ```
> > 
> > That way, we should be able to reuse the same implementation to detect 
> > reserved macros too.
> I did the `II->isReserved(LangOpts)` part, but the updated condition 
> `!getDeclContext()->getRedeclContext()->isTranslationUnit()` fails the 
> validation. I did already spend a lot of time getting one that catches the 
> behavior we wanted, so 'm not super-eager to investigate why this change 
> would not work ;-)
The current lexical context check does not look correct -- the lexical context 
is not relevant here, because the language rule is constrained by the semantic 
context. What test cases does the new condition fail?

Please also add something like the testcases from my other comment; I can't 
find any tests for friends or for local extern declarations in the current set 
of tests, and that's the kind of corner case that would be affected by this.


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

https://reviews.llvm.org/D93095

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

[PATCH] D99623: [WebAssembly] Implement i64x2 comparisons

[Thomas Lively 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 rG45783d0e8a36: [WebAssembly] Implement i64x2 comparisons 
(authored by tlively).

Changed prior to commit:
  https://reviews.llvm.org/D99623?vs=334280=334485#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99623

Files:
  clang/include/clang/Basic/BuiltinsWebAssembly.def
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/builtins-wasm.c
  llvm/include/llvm/IR/IntrinsicsWebAssembly.td
  llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp
  llvm/lib/Target/WebAssembly/WebAssemblyInstrSIMD.td
  llvm/test/CodeGen/WebAssembly/simd-comparisons.ll
  llvm/test/CodeGen/WebAssembly/simd-intrinsics.ll
  llvm/test/CodeGen/WebAssembly/simd-select.ll
  llvm/test/MC/WebAssembly/simd-encodings.s

Index: llvm/test/MC/WebAssembly/simd-encodings.s
===
--- llvm/test/MC/WebAssembly/simd-encodings.s
+++ llvm/test/MC/WebAssembly/simd-encodings.s
@@ -653,17 +653,23 @@
 # CHECK: i64x2.mul # encoding: [0xfd,0xd5,0x01]
 i64x2.mul
 
-# TODO: i64x2.eq # encoding: [0xfd,0xd6,0x01]
+# CHECK: i64x2.eq # encoding: [0xfd,0xd6,0x01]
+i64x2.eq
 
-# TODO: i64x2.ne # encoding: [0xfd,0xd7,0x01]
+# CHECK: i64x2.ne # encoding: [0xfd,0xd7,0x01]
+i64x2.ne
 
-# TODO: i64x2.lt_s # encoding: [0xfd,0xd8,0x01]
+# CHECK: i64x2.lt_s # encoding: [0xfd,0xd8,0x01]
+i64x2.lt_s
 
-# TODO: i64x2.gt_s # encoding: [0xfd,0xd9,0x01]
+# CHECK: i64x2.gt_s # encoding: [0xfd,0xd9,0x01]
+i64x2.gt_s
 
-# TODO: i64x2.le_s # encoding: [0xfd,0xda,0x01]
+# CHECK: i64x2.le_s # encoding: [0xfd,0xda,0x01]
+i64x2.le_s
 
-# TODO: i64x2.ge_s # encoding: [0xfd,0xdb,0x01]
+# CHECK: i64x2.ge_s # encoding: [0xfd,0xdb,0x01]
+i64x2.ge_s
 
 # CHECK: i64x2.extmul_low_i32x4_s # encoding: [0xfd,0xdc,0x01]
 i64x2.extmul_low_i32x4_s
Index: llvm/test/CodeGen/WebAssembly/simd-select.ll
===
--- llvm/test/CodeGen/WebAssembly/simd-select.ll
+++ llvm/test/CodeGen/WebAssembly/simd-select.ll
@@ -299,33 +299,17 @@
   ret <2 x i64> %res
 }
 
-define <2 x i64> @vselect_cmp_v2i64(<2 x i64> %a, <2 x i64> %b,
+define <2 x i64> @vselect_cmp_v2i64(<2 x i64> %a, <2 x i64> %b, <2 x i64> %x, <2 x i64> %y) {
 ; CHECK-LABEL: vselect_cmp_v2i64:
 ; CHECK: .functype vselect_cmp_v2i64 (v128, v128, v128, v128) -> (v128)
 ; CHECK-NEXT:  # %bb.0:
 ; CHECK-NEXT:local.get 2
 ; CHECK-NEXT:local.get 3
-; CHECK-NEXT:i64.const -1
-; CHECK-NEXT:i64.const 0
 ; CHECK-NEXT:local.get 0
-; CHECK-NEXT:i64x2.extract_lane 0
 ; CHECK-NEXT:local.get 1
-; CHECK-NEXT:i64x2.extract_lane 0
-; CHECK-NEXT:i64.lt_s
-; CHECK-NEXT:i64.select
-; CHECK-NEXT:i64x2.splat
-; CHECK-NEXT:i64.const -1
-; CHECK-NEXT:i64.const 0
-; CHECK-NEXT:local.get 0
-; CHECK-NEXT:i64x2.extract_lane 1
-; CHECK-NEXT:local.get 1
-; CHECK-NEXT:i64x2.extract_lane 1
-; CHECK-NEXT:i64.lt_s
-; CHECK-NEXT:i64.select
-; CHECK-NEXT:i64x2.replace_lane 1
+; CHECK-NEXT:i64x2.lt_s
 ; CHECK-NEXT:v128.bitselect
 ; CHECK-NEXT:# fallthrough-return
-<2 x i64> %x, <2 x i64> %y) {
   %c = icmp slt <2 x i64> %a, %b
   %res = select <2 x i1> %c, <2 x i64> %x, <2 x i64> %y
   ret <2 x i64> %res
Index: llvm/test/CodeGen/WebAssembly/simd-intrinsics.ll
===
--- llvm/test/CodeGen/WebAssembly/simd-intrinsics.ll
+++ llvm/test/CodeGen/WebAssembly/simd-intrinsics.ll
@@ -553,16 +553,6 @@
 ; ==
 ; 2 x i64
 ; ==
-; CHECK-LABEL: eq_v2i64:
-; CHECK-NEXT: .functype eq_v2i64 (v128, v128) -> (v128){{$}}
-; CHECK-NEXT: i64x2.eq $push[[R:[0-9]+]]=, $0, $1{{$}}
-; CHECK-NEXT: return $pop[[R]]{{$}}
-declare <2 x i64> @llvm.wasm.eq(<2 x i64>, <2 x i64>)
-define <2 x i64> @eq_v2i64(<2 x i64> %x, <2 x i64> %y) {
-  %a = call <2 x i64> @llvm.wasm.eq(<2 x i64> %x, <2 x i64> %y)
-  ret <2 x i64> %a
-}
-
 ; CHECK-LABEL: extend_low_s_v2i64:
 ; CHECK-NEXT: .functype extend_low_s_v2i64 (v128) -> (v128){{$}}
 ; CHECK-NEXT: i64x2.extend_low_i32x4_s $push[[R:[0-9]+]]=, $0{{$}}
Index: llvm/test/CodeGen/WebAssembly/simd-comparisons.ll
===
--- llvm/test/CodeGen/WebAssembly/simd-comparisons.ll
+++ llvm/test/CodeGen/WebAssembly/simd-comparisons.ll
@@ -637,14 +637,20 @@
 }
 
 ; CHECK-LABEL: compare_eq_v2i64:
+; NO-SIMD128-NOT: i64x2
 ; SIMD128-NEXT: .functype compare_eq_v2i64 (v128, v128) -> (v128){{$}}
+; SIMD128-NEXT: i64x2.eq $push[[R:[0-9]+]]=, $0, $1{{$}}
+; 

[clang] 45783d0 - [WebAssembly] Implement i64x2 comparisons

[Thomas Lively via cfe-commits]

Author: Thomas Lively
Date: 2021-03-31T10:46:17-07:00
New Revision: 45783d0e8a3632b7c1f5b0cdd258bfba1f8583e7

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

LOG: [WebAssembly] Implement i64x2 comparisons

Removes the prototype builtin and intrinsic for i64x2.eq and implements that
instruction as well as the other i64x2 comparison instructions in the final SIMD
spec. Unsigned comparisons were not included in the final spec, so they still
need to be scalarized via a custom lowering.

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

Added: 


Modified: 
clang/include/clang/Basic/BuiltinsWebAssembly.def
clang/lib/CodeGen/CGBuiltin.cpp
clang/test/CodeGen/builtins-wasm.c
llvm/include/llvm/IR/IntrinsicsWebAssembly.td
llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp
llvm/lib/Target/WebAssembly/WebAssemblyInstrSIMD.td
llvm/test/CodeGen/WebAssembly/simd-comparisons.ll
llvm/test/CodeGen/WebAssembly/simd-intrinsics.ll
llvm/test/CodeGen/WebAssembly/simd-select.ll
llvm/test/MC/WebAssembly/simd-encodings.s

Removed: 




diff  --git a/clang/include/clang/Basic/BuiltinsWebAssembly.def 
b/clang/include/clang/Basic/BuiltinsWebAssembly.def
index 6ea59026cd02a..3f8b050aabfd1 100644
--- a/clang/include/clang/Basic/BuiltinsWebAssembly.def
+++ b/clang/include/clang/Basic/BuiltinsWebAssembly.def
@@ -215,7 +215,5 @@ TARGET_BUILTIN(__builtin_wasm_store16_lane, "vs*V8sIi", 
"n", "simd128")
 TARGET_BUILTIN(__builtin_wasm_store32_lane, "vi*V4iIi", "n", "simd128")
 TARGET_BUILTIN(__builtin_wasm_store64_lane, "vLLi*V2LLiIi", "n", "simd128")
 
-TARGET_BUILTIN(__builtin_wasm_eq_i64x2, "V2LLiV2LLiV2LLi", "nc", "simd128")
-
 #undef BUILTIN
 #undef TARGET_BUILTIN

diff  --git a/clang/lib/CodeGen/CGBuiltin.cpp b/clang/lib/CodeGen/CGBuiltin.cpp
index 7d24b6a9342e4..86ea4ac28ae86 100644
--- a/clang/lib/CodeGen/CGBuiltin.cpp
+++ b/clang/lib/CodeGen/CGBuiltin.cpp
@@ -17400,12 +17400,6 @@ Value 
*CodeGenFunction::EmitWebAssemblyBuiltinExpr(unsigned BuiltinID,
 Function *Callee = CGM.getIntrinsic(Intrinsic::wasm_popcnt);
 return Builder.CreateCall(Callee, {Vec});
   }
-  case WebAssembly::BI__builtin_wasm_eq_i64x2: {
-Value *LHS = EmitScalarExpr(E->getArg(0));
-Value *RHS = EmitScalarExpr(E->getArg(1));
-Function *Callee = CGM.getIntrinsic(Intrinsic::wasm_eq);
-return Builder.CreateCall(Callee, {LHS, RHS});
-  }
   case WebAssembly::BI__builtin_wasm_any_true_i8x16:
   case WebAssembly::BI__builtin_wasm_any_true_i16x8:
   case WebAssembly::BI__builtin_wasm_any_true_i32x4:

diff  --git a/clang/test/CodeGen/builtins-wasm.c 
b/clang/test/CodeGen/builtins-wasm.c
index f635e68258963..c27be6d909c08 100644
--- a/clang/test/CodeGen/builtins-wasm.c
+++ b/clang/test/CodeGen/builtins-wasm.c
@@ -650,12 +650,6 @@ i8x16 popcnt(i8x16 x) {
   // WEBASSEMBLY-NEXT: ret
 }
 
-i64x2 eq_i64x2(i64x2 x, i64x2 y) {
-  return __builtin_wasm_eq_i64x2(x, y);
-  // WEBASSEMBLY: call <2 x i64> @llvm.wasm.eq(<2 x i64> %x, <2 x i64> %y)
-  // WEBASSEMBLY-NEXT: ret
-}
-
 int any_true_i8x16(i8x16 x) {
   return __builtin_wasm_any_true_i8x16(x);
   // WEBASSEMBLY: call i32 @llvm.wasm.anytrue.v16i8(<16 x i8> %x)

diff  --git a/llvm/include/llvm/IR/IntrinsicsWebAssembly.td 
b/llvm/include/llvm/IR/IntrinsicsWebAssembly.td
index 7e7d151d22fef..a57080d1d95b4 100644
--- a/llvm/include/llvm/IR/IntrinsicsWebAssembly.td
+++ b/llvm/include/llvm/IR/IntrinsicsWebAssembly.td
@@ -294,13 +294,6 @@ def int_wasm_extadd_pairwise_unsigned :
 [LLVMSubdivide2VectorType<0>],
 [IntrNoMem, IntrSpeculatable]>;
 
-// TODO: Remove this intrinsic and the associated builtin if i64x2.eq gets
-// merged to the proposal.
-def int_wasm_eq :
-  Intrinsic<[llvm_v2i64_ty],
-[llvm_v2i64_ty, llvm_v2i64_ty],
-[IntrNoMem, IntrSpeculatable]>;
-
 // TODO: Remove these if possible if they are merged to the spec.
 def int_wasm_convert_low_signed :
   Intrinsic<[llvm_v2f64_ty], [llvm_v4i32_ty],

diff  --git a/llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp 
b/llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp
index 85d2d2f60a53d..4c12c5f2a3d97 100644
--- a/llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp
+++ b/llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp
@@ -186,9 +186,9 @@ WebAssemblyTargetLowering::WebAssemblyTargetLowering(
   for (auto T : {MVT::v4f32, MVT::v2f64})
 setOperationAction(Op, T, Expand);
 
-// Expand operations not supported for i64x2 vectors
-for (unsigned CC = 0; CC < ISD::SETCC_INVALID; ++CC)
-  setCondCodeAction(static_cast(CC), MVT::v2i64, Custom);
+// Unsigned comparison operations are unavailable for i64x2 vectors.
+for (auto CC : {ISD::SETUGT, ISD::SETUGE, ISD::SETULT, ISD::SETULE})
+  

[PATCH] D99622: [OpenMP51] Accept `primary` as proc bind affinity policy in Clang

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added inline comments.



Comment at: 
clang/test/OpenMP/distribute_parallel_for_proc_bind_codegen.cpp:108-135
+#ifdef CK2
+
+typedef __INTPTR_TYPE__ intptr_t;
+
+// CK2-DAG: [[IDENT_T_TY:%.+]] = type { i32, i32, i32, i32, i8* }
+// CK2-DAG: [[STR:@.+]] = private unnamed_addr constant [23 x i8] 
c";unknown;unknown;0;0;;\00"
+// CK2-DAG: [[DEF_LOC_2:@.+]] = private unnamed_addr constant [[IDENT_T_TY]] { 
i32 0, i32 2, i32 0, i32 0, i8* getelementptr inbounds ([23 x i8], [23 x i8]* 
[[STR]], i32 0, i32 0) }

Same, could you move it to a different file?



Comment at: 
clang/test/OpenMP/nvptx_target_parallel_proc_bind_codegen.cpp:110-147
+// Test target codegen - host bc file has to be created first.
+// RUN: %clang_cc1 -DCK2 -verify -fopenmp -fopenmp-version=45 
-fopenmp-cuda-mode -x c++ -triple powerpc64le-unknown-unknown 
-fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm-bc %s -o %t-ppc-host.bc
+// RUN: %clang_cc1 -DCK2 -verify -fopenmp -fopenmp-version=45 
-fopenmp-cuda-mode -x c++ -triple nvptx64-unknown-unknown 
-fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm %s -fopenmp-is-device 
-fopenmp-host-ir-file-path %t-ppc-host.bc -o - | FileCheck %s --check-prefix 
CK2 --check-prefix CK2-64
+// RUN: %clang_cc1 -DCK2 -verify -fopenmp -fopenmp-version=45 
-fopenmp-cuda-mode -x c++ -triple i386-unknown-unknown 
-fopenmp-targets=nvptx-nvidia-cuda -emit-llvm-bc %s -o %t-x86-host.bc
+// RUN: %clang_cc1 -DCK2 -verify -fopenmp -fopenmp-version=45 
-fopenmp-cuda-mode -x c++ -triple nvptx-unknown-unknown 
-fopenmp-targets=nvptx-nvidia-cuda -emit-llvm %s -fopenmp-is-device 
-fopenmp-host-ir-file-path %t-x86-host.bc -o - | FileCheck %s --check-prefix 
CK2 --check-prefix CK2-32
+// RUN: %clang_cc1 -DCK2 -verify -fopenmp -fopenmp-version=45 
-fopenmp-cuda-mode -fexceptions -fcxx-exceptions -x c++ -triple 
nvptx-unknown-unknown -fopenmp-targets=nvptx-nvidia-cuda -emit-llvm %s 
-fopenmp-is-device -fopenmp-host-ir-file-path %t-x86-host.bc -o - | FileCheck 
%s --check-prefix CK2 --check-prefix CK2-32
+

Put this part in a separate file, please


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99622

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

[PATCH] D99484: Use `GNUInstallDirs` to support custom installation dirs.

[John Ericson via Phabricator via cfe-commits]

Ericson2314 added inline comments.



Comment at: clang/cmake/modules/AddClang.cmake:127
+  LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}${LLVM_LIBDIR_SUFFIX}
+  ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}${LLVM_LIBDIR_SUFFIX}
+  RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR})

compnerd wrote:
> Ericson2314 wrote:
> > compnerd wrote:
> > > For the initial change, Id leave this off.  `CMAKE_INSTALL_LIBDIR` 
> > > sometimes already deals with the bit suffix, so you can end up with two 
> > > instances of `32` or `64`.  I think that cleaning that up separately, 
> > > while focusing on the details of cleaning up how to handle 
> > > `LLVM_LIBDIR_SUFFIX` is the right thing to do.  The same applies to the 
> > > rest of the patch.
> > https://gitlab.kitware.com/cmake/cmake/-/blob/master/Modules/GNUInstallDirs.cmake#L257
> >  Hmm I see what you mean. So you are saying `s/${ 
> > CMAKE_INSTALL_LIBDIR}${LLVM_LIBDIR_SUFFIX}/${ CMAKE_INSTALL_LIBDIR}/` 
> > everywhere?
> Yes, that is what I was referring to.  I'm suggesting that you do *not* make 
> that change instead.  That needs a much more involved change to clean up the 
> use of `${LLVM_LIBDIR_SUFFIX}`.  I think that this change is already 
> extremely large as is, and folding more into it is not going to help.
So you are saying II should back all of these out into 
`lib${LLVM_LIBDIR_SUFFIX}` as they were before, for now?

Yes I don't want to make this bigger either, and would rather be on the hook 
for follow-up work than have this one be too massive to get over the finish 
line.



Comment at: compiler-rt/cmake/Modules/CompilerRTUtils.cmake:389
 get_compiler_rt_target(${arch} target)
-set(${install_dir} ${COMPILER_RT_INSTALL_PATH}/lib/${target} PARENT_SCOPE)
+set(${install_dir} 
${COMPILER_RT_INSTALL_PATH}/${CMAKE_INSTALL_FULL_LIBDIR}/${target} PARENT_SCOPE)
   else()

ldionne wrote:
> lebedev.ri wrote:
> > This looks suspect
> Yeah, I don't understand why this isn't just `CMAKE_INSTALL_LIBDIR` like 
> elsewhere.
See the non-line comment I responded to @lebidev.ri with. In sort if

```
${COMPILER_RT_INSTALL_PATH}/${CMAKE_INSTALL_LIBDIR}/${target}
```

is a relative path, then we end up with

```
${CMAKE_INSTALL_PREFIX}/${COMPILER_RT_INSTALL_PATH}/${CMAKE_INSTALL_LIBDIR}/${target}
```

instead of 

```
${COMPILER_RT_INSTALL_PATH}/${CMAKE_INSTALL_PREFIX}/${CMAKE_INSTALL_LIBDIR}/${target}
```

as we do with the other per-package prefixes. Also if `CMAKE_INSTALL_LIBDIR` is 
already an absolute path, then
```
${COMPILER_RT_INSTALL_PATH}/${CMAKE_INSTALL_FULL_LIBDIR}/${target}
```
is the same thing, and closer to the second than the first.



Comment at: compiler-rt/cmake/base-config-ix.cmake:72
+  set(COMPILER_RT_INSTALL_PATH "" CACHE PATH
+"Prefix where built compiler-rt artifacts should be installed, comes 
before CMAKE_INSTALL_PREFIX.")
   option(COMPILER_RT_INCLUDE_TESTS "Generate and build compiler-rt unit 
tests." OFF)

compnerd wrote:
> Ericson2314 wrote:
> > compnerd wrote:
> > > Please don't change the descriptions of the options as part of the 
> > > `GNUInstallDirs` handling.  The change to `COMPILER_RT_INSTALL_PATH` 
> > > looks incorrect.  Can you explain this change please?
> > I tried explain this https://reviews.llvm.org/D99484#2655885 and the 
> > original description about prefixes. The GNU install dir variables are 
> > allowed to be absolute paths (and not necessary with the installation 
> > prefix) (and I needed that for the NixOS patch), so always prepending 
> > `COMPILER_RT_INSTALL_PATH` as is done doesn't work if that is 
> > `CMAKE_INSTALL_PREFIX` by default.
> > 
> > If you do `git grep '_PREFIX ""'` and also `git grep GRPC_INSTALL_PATH` you 
> > will see that many similar variables also were already empty by default. I 
> > agree this thing is a bit ugly, but by that argument I am not doing a new 
> > hack for `GNUInstallDIrs` but rather applying an existing ideom 
> > consistently in all packages.
> Sure, but the *descriptions* of the options are needed to changed for 
> changing the value.
> 
> That said, I'm not convinced that this change is okay.  It changes the way 
> that compiler-rt can be built and used when building a toolchain image.  The 
> handling of the install prefix in compiler-rt is significantly different from 
> the other parts of LLVM, and so, I think that it may need to be done as a 
> separate larger effort.
So just skip everything compile-rt related for now?



Comment at: libcxx/CMakeLists.txt:32
+
+include(GNUInstallDirs)
 

compnerd wrote:
> Ericson2314 wrote:
> > compnerd wrote:
> > > Does this need to come here?  Why not push this to after the if block 
> > > completes?  The same applies through out the rest of the patch.
> > It might be fine here. But I was worried that in some of these cases code 
> > included in those blocks might refer to the 

[PATCH] D99623: [WebAssembly] Implement i64x2 comparisons

[Thomas Lively via Phabricator via cfe-commits]

tlively added inline comments.



Comment at: llvm/test/CodeGen/WebAssembly/simd-select.ll:313
 ; CHECK-NEXT:# fallthrough-return
 <2 x i64> %x, <2 x i64> %y) {
   %c = icmp slt <2 x i64> %a, %b

tlively wrote:
> dschuff wrote:
> > pre-existing, but is there a reason why the CHECKs here are in the middle 
> > of the IR function signature?
> Wow, I hadn't noticed that. Will investigate.
Aha, it's likely because the regex in update_llc_test_checks.py does not know 
how to recognize when the parameter list is continued on the next line. It only 
recognizes the first line of the function as the declaration line and places 
the checks immediately after it.

I'll fix this before I land the patch. Better to have a long parameter 
declaration line than a split up parameter declaration line!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99623

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

[PATCH] D99622: [OpenMP51] Accept `primary` as proc bind affinity policy in Clang

[Chi Chun Chen via Phabricator via cfe-commits]

cchen updated this revision to Diff 334482.
cchen added a comment.

Add some codegen tests


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99622

Files:
  clang/lib/Sema/SemaOpenMP.cpp
  clang/test/OpenMP/distribute_parallel_for_proc_bind_codegen.cpp
  clang/test/OpenMP/nvptx_target_parallel_proc_bind_codegen.cpp
  clang/test/OpenMP/parallel_ast_print.cpp
  clang/test/OpenMP/parallel_master_codegen.cpp
  clang/test/OpenMP/parallel_proc_bind_codegen.cpp
  clang/test/OpenMP/parallel_proc_bind_messages.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_proc_bind_codegen.cpp
  
clang/test/OpenMP/target_teams_distribute_parallel_for_simd_proc_bind_codegen.cpp
  clang/test/OpenMP/teams_distribute_parallel_for_proc_bind_codegen.cpp
  clang/test/OpenMP/teams_distribute_parallel_for_simd_proc_bind_codegen.cpp
  llvm/include/llvm/Frontend/OpenMP/OMP.td
  llvm/include/llvm/Frontend/OpenMP/OMPKinds.def

Index: llvm/include/llvm/Frontend/OpenMP/OMPKinds.def
===
--- llvm/include/llvm/Frontend/OpenMP/OMPKinds.def
+++ llvm/include/llvm/Frontend/OpenMP/OMPKinds.def
@@ -967,6 +967,7 @@
 __OMP_PROC_BIND_KIND(master, 2)
 __OMP_PROC_BIND_KIND(close, 3)
 __OMP_PROC_BIND_KIND(spread, 4)
+__OMP_PROC_BIND_KIND(primary, 5)
 __OMP_PROC_BIND_KIND(default, 6)
 __OMP_PROC_BIND_KIND(unknown, 7)
 
Index: llvm/include/llvm/Frontend/OpenMP/OMP.td
===
--- llvm/include/llvm/Frontend/OpenMP/OMP.td
+++ llvm/include/llvm/Frontend/OpenMP/OMP.td
@@ -103,13 +103,15 @@
 def OMP_PROC_BIND_master : ClauseVal<"master",2,1> {}
 def OMP_PROC_BIND_close : ClauseVal<"close",3,1> {}
 def OMP_PROC_BIND_spread : ClauseVal<"spread",4,1> {}
-def OMP_PROC_BIND_default : ClauseVal<"default",5,0> {}
-def OMP_PROC_BIND_unknown : ClauseVal<"unknown",6,0> { let isDefault = true; }
+def OMP_PROC_BIND_primary : ClauseVal<"primary",5,1> {}
+def OMP_PROC_BIND_default : ClauseVal<"default",6,0> {}
+def OMP_PROC_BIND_unknown : ClauseVal<"unknown",7,0> { let isDefault = true; }
 def OMPC_ProcBind : Clause<"proc_bind"> {
   let clangClass = "OMPProcBindClause";
   let flangClass = "OmpProcBindClause";
   let enumClauseValue = "ProcBindKind";
   let allowedClauseValues = [
+OMP_PROC_BIND_primary,
 OMP_PROC_BIND_master,
 OMP_PROC_BIND_close,
 OMP_PROC_BIND_spread,
Index: clang/test/OpenMP/teams_distribute_parallel_for_simd_proc_bind_codegen.cpp
===
--- clang/test/OpenMP/teams_distribute_parallel_for_simd_proc_bind_codegen.cpp
+++ clang/test/OpenMP/teams_distribute_parallel_for_simd_proc_bind_codegen.cpp
@@ -1,22 +1,23 @@
 // add -fopenmp-targets
-
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-version=45 -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -fopenmp-targets=powerpc64le-ibm-linux-gnu -emit-llvm %s -o - | FileCheck %s
-// RUN: %clang_cc1 -fopenmp -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -fopenmp-targets=powerpc64le-ibm-linux-gnu -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -fopenmp-targets=powerpc64le-ibm-linux-gnu -include-pch %t -verify %s -emit-llvm -o - | FileCheck %s
-
-// RUN: %clang_cc1 -verify -fopenmp-simd -fopenmp-version=45 -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -fopenmp-targets=powerpc64le-ibm-linux-gnu -emit-llvm %s -o - | FileCheck --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -fopenmp-simd -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -fopenmp-targets=powerpc64le-ibm-linux-gnu -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp-simd -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -fopenmp-targets=powerpc64le-ibm-linux-gnu -include-pch %t -verify %s -emit-llvm -o - | FileCheck --check-prefix SIMD-ONLY0 %s
-// SIMD-ONLY0-NOT: {{__kmpc|__tgt}}
 // expected-no-diagnostics
 #ifndef HEADER
 #define HEADER
 
+// RUN: %clang_cc1 -DCK1 -verify -fopenmp -fopenmp-version=45 -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -fopenmp-targets=powerpc64le-ibm-linux-gnu -emit-llvm %s -o - | FileCheck %s --check-prefix CK1
+// RUN: %clang_cc1 -DCK1 -fopenmp -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -fopenmp-targets=powerpc64le-ibm-linux-gnu -emit-pch -o %t %s
+// RUN: %clang_cc1 -DCK1 -fopenmp -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -fopenmp-targets=powerpc64le-ibm-linux-gnu -include-pch %t -verify %s -emit-llvm -o - | FileCheck %s --check-prefix CK1
+
+// RUN: %clang_cc1 -DCK1 -verify -fopenmp-simd -fopenmp-version=45 -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -fopenmp-targets=powerpc64le-ibm-linux-gnu -emit-llvm %s -o - | FileCheck --check-prefix SIMD-ONLY0 %s
+// RUN: %clang_cc1 -DCK1 -fopenmp-simd -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -fopenmp-targets=powerpc64le-ibm-linux-gnu -emit-pch -o %t %s
+// RUN: 

[PATCH] D99433: [Matrix] Including __builtin_matrix_multiply_add for the matrix type extension.

[Everton Constantino via Phabricator via cfe-commits]

everton.constantino added a comment.

@fhahn Ok I see what you mean now, this sounds like a doable path and might be 
able to cover architectures with specialized matrix multiplication instructions 
as well .

Just to see if I understand correctly I can add a matrix_add intrinsic, do a 
travesal looking for matrix_multiply and fuse both changing  
`LowerMatrixMultiplyFused` to support pre-loading the accumulator. Is that 
correct?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99433

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

[PATCH] D99623: [WebAssembly] Implement i64x2 comparisons

[Thomas Lively via Phabricator via cfe-commits]

tlively added inline comments.



Comment at: clang/include/clang/Basic/BuiltinsWebAssembly.def:218
 
-TARGET_BUILTIN(__builtin_wasm_eq_i64x2, "V2LLiV2LLiV2LLi", "nc", "simd128")
-

dschuff wrote:
> Is the builtin/intrinsic wrong now? Or just not necessary because we can use 
> builtin operators?
Just not necessary any more. That was only there to make sure no one could use 
the prototype instruction by accident.



Comment at: llvm/test/CodeGen/WebAssembly/simd-select.ll:313
 ; CHECK-NEXT:# fallthrough-return
 <2 x i64> %x, <2 x i64> %y) {
   %c = icmp slt <2 x i64> %a, %b

dschuff wrote:
> pre-existing, but is there a reason why the CHECKs here are in the middle of 
> the IR function signature?
Wow, I hadn't noticed that. Will investigate.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99623

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

[PATCH] D99659: [analyzer][taint] Extent of heap regions should get taint sometimes

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

steakhal updated this revision to Diff 334474.
steakhal added a comment.

Add a FIXME about placing a NoteTag describing why the extent was getting 
tainted.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99659

Files:
  clang/lib/StaticAnalyzer/Checkers/MallocChecker.cpp
  clang/test/Analysis/malloc.c


Index: clang/test/Analysis/malloc.c
===
--- clang/test/Analysis/malloc.c
+++ clang/test/Analysis/malloc.c
@@ -3,11 +3,14 @@
 // RUN:   -analyzer-checker=alpha.deadcode.UnreachableCode \
 // RUN:   -analyzer-checker=alpha.core.CastSize \
 // RUN:   -analyzer-checker=unix \
+// RUN:   -analyzer-checker=alpha.security.taint \
 // RUN:   -analyzer-checker=debug.ExprInspection
 
 #include "Inputs/system-header-simulator.h"
 
 void clang_analyzer_eval(int);
+size_t clang_analyzer_getExtent(void *);
+void clang_analyzer_isTainted(int);
 
 // Without -fms-compatibility, wchar_t isn't a builtin type. MSVC defines
 // _WCHAR_T_DEFINED if wchar_t is available. Microsoft recommends that you use
@@ -36,6 +39,7 @@
 wchar_t *wcsdup(const wchar_t *s);
 char *strndup(const char *s, size_t n);
 int memcmp(const void *s1, const void *s2, size_t n);
+int getchar(void);
 
 // Windows variants
 char *_strdup(const char *strSource);
@@ -1883,3 +1887,36 @@
   s->memP = malloc(sizeof(int));
   free(s);
 } // FIXME: should warn here
+
+void extentGetsTainted(int conj) {
+  int tainted = getchar();
+  {
+int *p = (int *)malloc(conj);
+clang_analyzer_isTainted(clang_analyzer_getExtent(p)); // expected-warning 
{{NO}}
+free(p);
+  }
+  {
+int *p = (int *)malloc(tainted);
+// expected-warning@-1 {{Untrusted data is used to specify the buffer size 
\
+(CERT/STR31-C. Guarantee that storage for strings has sufficient space for \
+character data and the null terminator)}}
+clang_analyzer_isTainted(clang_analyzer_getExtent(p)); // expected-warning 
{{YES}}
+free(p);
+  }
+  {
+int *p = (int *)malloc(5 + tainted);
+// expected-warning@-1 {{Untrusted data is used to specify the buffer size 
\
+(CERT/STR31-C. Guarantee that storage for strings has sufficient space for \
+character data and the null terminator)}}
+clang_analyzer_isTainted(clang_analyzer_getExtent(p)); // expected-warning 
{{YES}}
+free(p);
+  }
+  {
+int *p = (int *)malloc(conj + tainted);
+// expected-warning@-1 {{Untrusted data is used to specify the buffer size 
\
+(CERT/STR31-C. Guarantee that storage for strings has sufficient space for \
+character data and the null terminator)}}
+clang_analyzer_isTainted(clang_analyzer_getExtent(p)); // expected-warning 
{{YES}}
+free(p);
+  }
+}
Index: clang/lib/StaticAnalyzer/Checkers/MallocChecker.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/MallocChecker.cpp
+++ clang/lib/StaticAnalyzer/Checkers/MallocChecker.cpp
@@ -46,6 +46,7 @@
 
 #include "AllocationState.h"
 #include "InterCheckerAPI.h"
+#include "Taint.h"
 #include "clang/AST/Attr.h"
 #include "clang/AST/DeclCXX.h"
 #include "clang/AST/Expr.h"
@@ -1601,6 +1602,12 @@
 svalBuilder.evalEQ(State, DynSize, *DefinedSize);
 
 State = State->assume(DynSizeMatchesSize, true);
+
+// If the size of the allocation is tainted, the associated extent should 
be
+// also tainted.
+// FIXME: Add a NoteTag to describe why the extent become tainted.
+if (taint::isTainted(State, Size))
+  State = taint::addTaint(State, DynSize);
 assert(State);
   }
 


Index: clang/test/Analysis/malloc.c
===
--- clang/test/Analysis/malloc.c
+++ clang/test/Analysis/malloc.c
@@ -3,11 +3,14 @@
 // RUN:   -analyzer-checker=alpha.deadcode.UnreachableCode \
 // RUN:   -analyzer-checker=alpha.core.CastSize \
 // RUN:   -analyzer-checker=unix \
+// RUN:   -analyzer-checker=alpha.security.taint \
 // RUN:   -analyzer-checker=debug.ExprInspection
 
 #include "Inputs/system-header-simulator.h"
 
 void clang_analyzer_eval(int);
+size_t clang_analyzer_getExtent(void *);
+void clang_analyzer_isTainted(int);
 
 // Without -fms-compatibility, wchar_t isn't a builtin type. MSVC defines
 // _WCHAR_T_DEFINED if wchar_t is available. Microsoft recommends that you use
@@ -36,6 +39,7 @@
 wchar_t *wcsdup(const wchar_t *s);
 char *strndup(const char *s, size_t n);
 int memcmp(const void *s1, const void *s2, size_t n);
+int getchar(void);
 
 // Windows variants
 char *_strdup(const char *strSource);
@@ -1883,3 +1887,36 @@
   s->memP = malloc(sizeof(int));
   free(s);
 } // FIXME: should warn here
+
+void extentGetsTainted(int conj) {
+  int tainted = getchar();
+  {
+int *p = (int *)malloc(conj);
+clang_analyzer_isTainted(clang_analyzer_getExtent(p)); // expected-warning {{NO}}
+free(p);
+  }
+  {
+int *p = (int *)malloc(tainted);
+// 

[PATCH] D83660: [analyzer] Fix a crash for dereferencing an empty llvm::Optional variable in SMTConstraintManager.h.

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

steakhal added a comment.

In D83660#2661646 , @OikawaKirie wrote:

> Can we automatically enable all test cases requiring z3 if clang is built 
> with z3? I do not think the patch D83677  
> really make the problem fixed.

Z3 constraint manager is unsupported, thus no test runs those parts. And yea, 
crashes more often than not.

The primary goal of D83677  is to run the 
analyzer with the dummy range-based constraint manager, but with Z3 bugreport 
refutation. This scenario is monitored and maintained currently by us, 
Ericsson. We put effort into fixing crashes relating to this, thus it would be 
nice to state a test requirement that it `// REQUIRES: z3`, but only for 
refutation - which is really fast, has negligible overhead.
The main concern with the Z3 constraint manager is that it's really slow, 
beyond comfortable for tight CI loops.
So, `// REQUIRES: z3` means a little bit different than it supposed. 
`z3-solver` would be closer to reality.


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

https://reviews.llvm.org/D83660

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

[PATCH] D99658: [analyzer] Fix clang_analyzer_getExtent for heap regions

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

steakhal updated this revision to Diff 334470.
steakhal marked 3 inline comments as done.
steakhal added a comment.
This revision is now accepted and ready to land.

Fix comments.
I could not manage to create an `unknown` extent, where the behavior would 
diverge.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99658

Files:
  clang/lib/StaticAnalyzer/Checkers/ExprInspectionChecker.cpp
  clang/test/Analysis/explain-svals.cpp


Index: clang/test/Analysis/explain-svals.cpp
===
--- clang/test/Analysis/explain-svals.cpp
+++ clang/test/Analysis/explain-svals.cpp
@@ -53,8 +53,8 @@
   clang_analyzer_explain(clang_analyzer_getExtent(ptr)); // 
expected-warning-re^extent of pointee of argument 'ptr'$
   int *x = new int[ext];
   clang_analyzer_explain(x); // expected-warning-re^pointer to element of 
type 'int' with index 0 of heap segment that starts at symbol of type 'int \*' 
conjured at statement 'new int \[ext\]'$
-  // Sic! What gets computed is the extent of the element-region.
-  clang_analyzer_explain(clang_analyzer_getExtent(x)); // 
expected-warning-re^signed 32-bit integer '4'$
+  clang_analyzer_explain(clang_analyzer_getExtent(x)); // 
expected-warning-re^extent of heap segment that starts at symbol of type 
'int \*' conjured at statement 'new int \[ext\]'$
+  clang_analyzer_explain(clang_analyzer_getExtent(x + 2)); // 
expected-warning-re^\(extent of heap segment that starts at symbol of type 
'int \*' conjured at statement 'new int \[ext\]'\) - 8$
   delete[] x;
 }
 
Index: clang/lib/StaticAnalyzer/Checkers/ExprInspectionChecker.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/ExprInspectionChecker.cpp
+++ clang/lib/StaticAnalyzer/Checkers/ExprInspectionChecker.cpp
@@ -254,8 +254,7 @@
   }
 
   ProgramStateRef State = C.getState();
-  DefinedOrUnknownSVal Size = getDynamicSize(State, MR, C.getSValBuilder());
-
+  SVal Size = getDynamicSizeWithOffset(State, C.getSVal(CE->getArg(0)));
   State = State->BindExpr(CE, C.getLocationContext(), Size);
   C.addTransition(State);
 }


Index: clang/test/Analysis/explain-svals.cpp
===
--- clang/test/Analysis/explain-svals.cpp
+++ clang/test/Analysis/explain-svals.cpp
@@ -53,8 +53,8 @@
   clang_analyzer_explain(clang_analyzer_getExtent(ptr)); // expected-warning-re^extent of pointee of argument 'ptr'$
   int *x = new int[ext];
   clang_analyzer_explain(x); // expected-warning-re^pointer to element of type 'int' with index 0 of heap segment that starts at symbol of type 'int \*' conjured at statement 'new int \[ext\]'$
-  // Sic! What gets computed is the extent of the element-region.
-  clang_analyzer_explain(clang_analyzer_getExtent(x)); // expected-warning-re^signed 32-bit integer '4'$
+  clang_analyzer_explain(clang_analyzer_getExtent(x)); // expected-warning-re^extent of heap segment that starts at symbol of type 'int \*' conjured at statement 'new int \[ext\]'$
+  clang_analyzer_explain(clang_analyzer_getExtent(x + 2)); // expected-warning-re^\(extent of heap segment that starts at symbol of type 'int \*' conjured at statement 'new int \[ext\]'\) - 8$
   delete[] x;
 }
 
Index: clang/lib/StaticAnalyzer/Checkers/ExprInspectionChecker.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/ExprInspectionChecker.cpp
+++ clang/lib/StaticAnalyzer/Checkers/ExprInspectionChecker.cpp
@@ -254,8 +254,7 @@
   }
 
   ProgramStateRef State = C.getState();
-  DefinedOrUnknownSVal Size = getDynamicSize(State, MR, C.getSValBuilder());
-
+  SVal Size = getDynamicSizeWithOffset(State, C.getSVal(CE->getArg(0)));
   State = State->BindExpr(CE, C.getLocationContext(), Size);
   C.addTransition(State);
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D99669: [RISCV][Clang] Add more RVV Floating-Point intrinsic functions.

[Zakk Chen via Phabricator via cfe-commits]

khchen created this revision.
khchen added reviewers: craig.topper, rogfer01, HsiangKai, evandro, liaolucy, 
jrtc27.
Herald added subscribers: vkmr, frasercrmck, dexonsmith, luismarques, apazos, 
sameer.abuasal, s.egerton, Jim, benna, psnobl, jocewei, PkmX, the_o, 
brucehoult, MartinMosbeck, edward-jones, zzheng, shiva0217, kito-cheng, niosHD, 
sabuasal, simoncook, johnrusso, rbar, asb.
khchen requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay.
Herald added a project: clang.

Support below instructions.

1. Vector Widening Floating-Point Add/Subtract Instructions
2. Vector Widening Floating-Point Multiply
3. Vector Single-Width Floating-Point Fused Multiply-Add Instructions
4. Vector Widening Floating-Point Fused Multiply-Add Instructions
5. Vector Floating-Point Compare Instructions


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D99669

Files:
  clang/include/clang/Basic/riscv_vector.td
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfmacc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfmadd.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfmsac.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfmsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfnmacc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfnmadd.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfnmsac.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfnmsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfwadd.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfwmacc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfwmsac.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfwmul.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfwnmacc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfwnmsac.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfwsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vmfeq.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vmfge.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vmfgt.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vmfle.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vmflt.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vmfne.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfmacc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfmadd.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfmsac.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfmsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfnmacc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfnmadd.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfnmsac.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfnmsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfwadd.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfwmacc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfwmsac.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfwmul.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfwnmacc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfwnmsac.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfwsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vmfeq.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vmfge.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vmfgt.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vmfle.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vmflt.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vmfne.c

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

[PATCH] D99668: [RISCV][Clang] Add some RVV Floating-Point intrinsic functions.

[Zakk Chen via Phabricator via cfe-commits]

khchen created this revision.
khchen added reviewers: craig.topper, rogfer01, HsiangKai, evandro, liaolucy, 
jrtc27.
Herald added subscribers: vkmr, frasercrmck, dexonsmith, luismarques, apazos, 
sameer.abuasal, s.egerton, Jim, benna, psnobl, jocewei, PkmX, the_o, 
brucehoult, MartinMosbeck, edward-jones, zzheng, shiva0217, kito-cheng, niosHD, 
sabuasal, simoncook, johnrusso, rbar, asb.
khchen requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay.
Herald added a project: clang.

Support the following instructions which have the same class.

1. Vector Single-Width Floating-Point Subtract Instructions
2. Vector Single-Width Floating-Point Multiply/Divide Instructions
3. Vector Floating-Point MIN/MAX Instructions
4. Vector Floating-Point Sign-Injection Instructions


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D99668

Files:
  clang/include/clang/Basic/riscv_vector.td
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfdiv.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfmax.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfmin.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfmul.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfrdiv.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfrsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfsgnj.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfdiv.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfmax.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfmin.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfmul.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfrdiv.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfrsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfsgnj.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfsub.c

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

[PATCH] D99456: [C++2b] Support size_t literals

[Arthur O'Dwyer via Phabricator via cfe-commits]

Quuxplusone added inline comments.



Comment at: clang/lib/Frontend/InitPreprocessor.cpp:593-594
+  // C++2b features.
+  if (LangOpts.CPlusPlus2b)
+Builder.defineMacro("__cpp_size_t_suffix", "202011L");
   if (LangOpts.Char8)

AntonBikineev wrote:
> AntonBikineev wrote:
> > Quuxplusone wrote:
> > > aaron.ballman wrote:
> > > > AntonBikineev wrote:
> > > > > aaron.ballman wrote:
> > > > > > Because we allow this as an extension in all C++ modes, should this 
> > > > > > be enabled always rather than gated on C++2b?
> > > > > I was also wondering about this. I've checked that we also do the 
> > > > > same for other feature macros, such as __cpp_binary_literals, which 
> > > > > is defined for -std>=c++14 while at the same time is allowed as an 
> > > > > extension before C++14. Therefore I decided to mimic the behaviour.
> > > > Thanks for checking on that! I think that seems defensible enough. :-)
> > > Btw, thus far libc++ has tended to make the opposite choice: for example, 
> > > libc++ defines `__cpp_lib_variant == 202102` in all modes, because the 
> > > programmer conceivably might be depending on that macro to make some 
> > > decision, so we want to make sure it reflects the specific semantics that 
> > > we implement.  (For `__cpp_binary_literals` specifically, I agree it 
> > > doesn't really matter because nobody's going to be making decisions based 
> > > on the value of this macro.)
> > > 
> > > See https://reviews.llvm.org/D99290#inline-934563 (D96385, D97394) for 
> > > previous discussions on the libc++ side.
> > Thanks for pointing this out, Arthur.
> > 
> > I wish there was some consistency, however, I'm not sure if this is easily 
> > feasible. I guess the strategy of defining `__cpp_size_t_literals` on all 
> > modes would be problematic, since if the user code depends on 
> > `__cpp_size_t_literals`, it could suddenly receive the extension warning 
> > (when compiled with -std<2++2b), which is enabled by default.
> > Btw, thus far libc++ has tended to make the opposite choice: for example, 
> > libc++ defines `__cpp_lib_variant == 202102` in all modes, because the 
> > programmer conceivably might be depending on that macro to make some 
> > decision, so we want to make sure it reflects the specific semantics that 
> > we implement.  (For `__cpp_binary_literals` specifically, I agree it 
> > doesn't really matter because nobody's going to be making decisions based 
> > on the value of this macro.)
> > 
> > See https://reviews.llvm.org/D99290#inline-934563 (D96385, D97394) for 
> > previous discussions on the libc++ side.
> 
> 
> I guess the strategy of defining `__cpp_size_t_literals` in all modes would 
> be problematic, since if the [pre-C++2b] user code depends on 
> `__cpp_size_t_literals`, it could suddenly receive the extension warning...

Ah, yes. Orthogonally to everything I said above, I think it's fair to say that
- in modes where `42uz` produces a fatal error, it's definitely "not supported"
- in modes where it's accepted without complaint, it's definitely "supported" 
(*)
- in modes where it produces a non-fatal warning, you can plausibly argue it 
either way
(*) - with a bonus exception that if the user passes `-Wno-blah` or `-w`, that 
doesn't magically make things be supported
libc++'s situation seems more black-and-white; e.g. `variant` behaves one way 
or the other. There's no libc++ equivalent of "you get the new behavior but 
with a warning." :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99456

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

[PATCH] D99484: Use `GNUInstallDirs` to support custom installation dirs.

[Saleem Abdulrasool via Phabricator via cfe-commits]

compnerd added inline comments.



Comment at: clang/cmake/modules/AddClang.cmake:127
+  LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}${LLVM_LIBDIR_SUFFIX}
+  ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}${LLVM_LIBDIR_SUFFIX}
+  RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR})

Ericson2314 wrote:
> compnerd wrote:
> > For the initial change, Id leave this off.  `CMAKE_INSTALL_LIBDIR` 
> > sometimes already deals with the bit suffix, so you can end up with two 
> > instances of `32` or `64`.  I think that cleaning that up separately, while 
> > focusing on the details of cleaning up how to handle `LLVM_LIBDIR_SUFFIX` 
> > is the right thing to do.  The same applies to the rest of the patch.
> https://gitlab.kitware.com/cmake/cmake/-/blob/master/Modules/GNUInstallDirs.cmake#L257
>  Hmm I see what you mean. So you are saying `s/${ 
> CMAKE_INSTALL_LIBDIR}${LLVM_LIBDIR_SUFFIX}/${ CMAKE_INSTALL_LIBDIR}/` 
> everywhere?
Yes, that is what I was referring to.  I'm suggesting that you do *not* make 
that change instead.  That needs a much more involved change to clean up the 
use of `${LLVM_LIBDIR_SUFFIX}`.  I think that this change is already extremely 
large as is, and folding more into it is not going to help.



Comment at: compiler-rt/cmake/base-config-ix.cmake:72
+  set(COMPILER_RT_INSTALL_PATH "" CACHE PATH
+"Prefix where built compiler-rt artifacts should be installed, comes 
before CMAKE_INSTALL_PREFIX.")
   option(COMPILER_RT_INCLUDE_TESTS "Generate and build compiler-rt unit 
tests." OFF)

Ericson2314 wrote:
> compnerd wrote:
> > Please don't change the descriptions of the options as part of the 
> > `GNUInstallDirs` handling.  The change to `COMPILER_RT_INSTALL_PATH` looks 
> > incorrect.  Can you explain this change please?
> I tried explain this https://reviews.llvm.org/D99484#2655885 and the original 
> description about prefixes. The GNU install dir variables are allowed to be 
> absolute paths (and not necessary with the installation prefix) (and I needed 
> that for the NixOS patch), so always prepending `COMPILER_RT_INSTALL_PATH` as 
> is done doesn't work if that is `CMAKE_INSTALL_PREFIX` by default.
> 
> If you do `git grep '_PREFIX ""'` and also `git grep GRPC_INSTALL_PATH` you 
> will see that many similar variables also were already empty by default. I 
> agree this thing is a bit ugly, but by that argument I am not doing a new 
> hack for `GNUInstallDIrs` but rather applying an existing ideom consistently 
> in all packages.
Sure, but the *descriptions* of the options are needed to changed for changing 
the value.

That said, I'm not convinced that this change is okay.  It changes the way that 
compiler-rt can be built and used when building a toolchain image.  The 
handling of the install prefix in compiler-rt is significantly different from 
the other parts of LLVM, and so, I think that it may need to be done as a 
separate larger effort.



Comment at: libcxx/CMakeLists.txt:32
+
+include(GNUInstallDirs)
 

Ericson2314 wrote:
> compnerd wrote:
> > Does this need to come here?  Why not push this to after the if block 
> > completes?  The same applies through out the rest of the patch.
> It might be fine here. But I was worried that in some of these cases code 
> included in those blocks might refer to the `GNUInstallDirs` variables.
> 
> Originally I had `GNUInstallDirs` only included in the conditional block 
> after `project(...)`, but then the combined build test failed because nothing 
> including `GnuInstallDirs` in that case. If there is an "entrypoint" 
> CMakeLists boilerplate that combined builds should always use, I think the 
> best thing would be to change it back and then additionally put 
> `GNUInstallDirs` there.
Unified builds always use `llvm/CMakeLists.txt`.  However, both should continue 
to work, and so you will need to add this in the subprojects as well.



Comment at: libcxx/cmake/Modules/HandleLibCXXABI.cmake:66
   install(FILES "${LIBCXX_BINARY_INCLUDE_DIR}/${fpath}"
-DESTINATION ${LIBCXX_INSTALL_HEADER_PREFIX}include/c++/v1/${dstdir}
+DESTINATION 
${LIBCXX_INSTALL_HEADER_PREFIX}${CMAKE_INSTALL_INCLUDEDIR}/c++/v1/${dstdir}
 COMPONENT cxx-headers

Ericson2314 wrote:
> compnerd wrote:
> > @ldionne - how is the `LIBCXX_INSTALL_HEADER_PREFIX` used?  Can altering 
> > the value of `CMAKE_INSTALL_INCLUDEDIR` serve the purpose?
> It is sometimes modified to be per target when multiple targets are being 
> used at once. All things `CMAKE_INSTALL_*` are globally scoped so in general 
> the combination builds are quite awkward.
> 
> (Having worked on Meson, I am really missing 
> https://mesonbuild.com/Subprojects.html which is exactly what's needed to do 
> this without these bespoke idioms that never work well enough . Alas...)
I don't think that bringing up other build systems is 

[PATCH] D99484: Use `GNUInstallDirs` to support custom installation dirs.

[Louis Dionne via Phabricator via cfe-commits]

ldionne added a subscriber: phosek.
ldionne added a comment.

I am generally OK with the libcxx and libcxxabi changes.




Comment at: compiler-rt/cmake/Modules/CompilerRTUtils.cmake:389
 get_compiler_rt_target(${arch} target)
-set(${install_dir} ${COMPILER_RT_INSTALL_PATH}/lib/${target} PARENT_SCOPE)
+set(${install_dir} 
${COMPILER_RT_INSTALL_PATH}/${CMAKE_INSTALL_FULL_LIBDIR}/${target} PARENT_SCOPE)
   else()

lebedev.ri wrote:
> This looks suspect
Yeah, I don't understand why this isn't just `CMAKE_INSTALL_LIBDIR` like 
elsewhere.



Comment at: libcxx/cmake/Modules/HandleLibCXXABI.cmake:66
   install(FILES "${LIBCXX_BINARY_INCLUDE_DIR}/${fpath}"
-DESTINATION ${LIBCXX_INSTALL_HEADER_PREFIX}include/c++/v1/${dstdir}
+DESTINATION 
${LIBCXX_INSTALL_HEADER_PREFIX}${CMAKE_INSTALL_INCLUDEDIR}/c++/v1/${dstdir}
 COMPONENT cxx-headers

compnerd wrote:
> Ericson2314 wrote:
> > compnerd wrote:
> > > @ldionne - how is the `LIBCXX_INSTALL_HEADER_PREFIX` used?  Can altering 
> > > the value of `CMAKE_INSTALL_INCLUDEDIR` serve the purpose?
> > It is sometimes modified to be per target when multiple targets are being 
> > used at once. All things `CMAKE_INSTALL_*` are globally scoped so in 
> > general the combination builds are quite awkward.
> > 
> > (Having worked on Meson, I am really missing 
> > https://mesonbuild.com/Subprojects.html which is exactly what's needed to 
> > do this without these bespoke idioms that never work well enough . Alas...)
> I don't think that bringing up other build systems is particularly helpful.
> 
> I do expect it to be modified, and I suspect that this is used specifically 
> for builds that @ldionne supports.
Actually, I've never used it myself, but @phosek seems to be using it for the 
Runtimes build to output one set of headers for each target, as mentioned above.

It seems to me that tweaking `CMAKE_INSTALL_PREFIX` globally when driving the 
libc++ build from the runtimes build would be more in-line with the CMake way 
of doing things (one configuration == one build), but I'm curious to hear what 
@phosek has to say about that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99484

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

[PATCH] D99320: [RISCV] [1/2] Add intrinsic for Zbb extension

[Craig Topper via Phabricator via cfe-commits]

craig.topper added a comment.

In D99320#2661285 , @asb wrote:

> Can I just check the reasoning on the naming? I see that the bitmanip 0.93 
> spec proposes `_{rv,rv32,rv64}_{opname}` intrinsics. Does the 
> `__builtin__{riscv,riscv32,riscv64}_opname` format match what GCC are doing / 
> planning to do here? Precedent for RVV, for other archs, or something else?
>
> Just trying to determine to what these names are an open item of discussion 
> vs matching something else.
>
> EDIT: I see Craig commented on this point in 
> https://reviews.llvm.org/D99009#2660456

Yeah the big open for naming is the name of the intrinsic header. Whether it 
should be rvintrin.h or riscv_intrinsic.h.

The builtins in this patch are

__builtin_riscv_orc_b_32
__builtin_riscv_orc_b_64

I've update the description summary to reflect this since it change during 
development.

The Zbr patch uses the following without a 32/64 suffix.
__builtin_riscv_crc32_b/w/d/q

There's a difference because orc.b needs to be available for 32-bit on RV32 and 
RV64 per the spec so we have two builtins. crc32.b intrinsics in the spec are 
defined only for xlen so we have a single builtin.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99320

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

[PATCH] D99577: [RFC][OpenCL][PoC] Testing TableGen with diffing

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia added a comment.

This approach is really great because the testing is so quick! While it is not 
providing the coverage for invocation through clang, it can still be very 
valuable in various forms to enhance the testing and improve the coverage at 
very little cost. Thanks for working on this!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99577

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

[PATCH] D99646: [clang-tidy] misc-std-stream-objects-outside-main: a new check

[Nathan James via Phabricator via cfe-commits]

njames93 added a comment.

Is it not wise to also check the c standard library.
So check for function refs to these names in the global or std namespace.
`printf`, `vprintf`, `puts`, `putchar`, `scanf`, `scanf`, `getchar` and `gets`
It may be a bit of a pain checking for usages of `stdin` and  `stdout` due to 
them being defined as macros.

If you make this change the name of the check would likely need updating as 
they aren't stream objects.

Going on a tangent here, but on POSIX platforms you can redirect `stdin`, 
`stdout`, and `stderr` using `dup` and `dup2` (Windows is `_dup` and `_dup2` 
respectively), gtest uses this functionality.




Comment at: 
clang-tools-extra/clang-tidy/misc/StdStreamObjectsOutsideMainCheck.cpp:42
+
+bool StdStreamObjectsOutsideMainCheck::isInsideMainFunction(
+const MatchFinder::MatchResult , const DynTypedNode ) {

This all seems unnecessary, you can add `unless(forFunction(isMain()))` to your 
declRefExpr matcher instead.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/misc-std-stream-objects-outside-main.cpp:1
+// RUN: %check_clang_tidy -std=c++14-or-later %s 
misc-std-stream-objects-outside-main %t
+

Why won't this work in c++11 mode?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99646

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

[PATCH] D83660: [analyzer] Fix a crash for dereferencing an empty llvm::Optional variable in SMTConstraintManager.h.

[Ella Ma via Phabricator via cfe-commits]

OikawaKirie added a comment.

In D83660#2661369 , @martong wrote:

>> BTW, I was obstructed by the z3 requirement in the regression test case when 
>> I tried to understand your test case. Even though I set the variables 
>> LLVM_Z3_INSTALL_DIR and LLVM_ENABLE_Z3_SOLVER during CMake, and the CSA can 
>> be correctly compiled with Z3, I still cannot make the test case run during 
>> make check-all. Therefore, this case was manually executed with llvm-lit 
>> -DUSE_Z3_SOLVER=1. Could you please tell me how to enable Z3 during llvm-lit.
>
> I am a bit unhappy that we cannot run the test automatically, but maybe in 
> the future.
> @steakhal, https://reviews.llvm.org/D83677 seems to be related, should we 
> push that?

I am just reporting this phenomenon and I am not sure whether it is caused by 
my bad configurations.
Under my configurations, the last step of `make check-all` will execute 
`llvm-lit` with argument `--param USE_Z3_SOLVER=0`, which will make all test 
cases requiring z3 skipped.
Although, clang is built with z3 under this configuration.

Can we automatically enable all test cases requiring z3 if clang is built with 
z3? I do not think the patch D83677  really 
make the problem fixed.


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

https://reviews.llvm.org/D83660

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

[PATCH] D99663: [clang-cl] [Sema] Do not prefer integral conversion over floating-to-integral for MS compatibility 19.28 and higher.

[Marek Kurdej via Phabricator via cfe-commits]

curdeius created this revision.
curdeius added reviewers: mstorsjo, thakis, phosek.
Herald added a subscriber: dexonsmith.
curdeius requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

As of MSVC 19.28 (2019 Update 8), integral conversion is no longer preferred 
over floating-to-integral, and so MSVC is more standard conformant and will 
generate a compiler error on ambiguous call.
Cf. https://godbolt.org/z/E8xsdqKsb.
Initially found during the review of D99641 .


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D99663

Files:
  clang/include/clang/Basic/LangOptions.h
  clang/lib/Sema/SemaOverload.cpp
  clang/test/SemaCXX/MicrosoftCompatibility.cpp


Index: clang/test/SemaCXX/MicrosoftCompatibility.cpp
===
--- clang/test/SemaCXX/MicrosoftCompatibility.cpp
+++ clang/test/SemaCXX/MicrosoftCompatibility.cpp
@@ -1,3 +1,5 @@
+// RUN: %clang_cc1 %s -triple i686-pc-win32 -fsyntax-only -std=c++11 
-Wmicrosoft -verify -fms-compatibility -fexceptions -fcxx-exceptions 
-fms-compatibility-version=19.28
+// RUN: %clang_cc1 %s -triple i686-pc-win32 -fsyntax-only -std=c++11 
-Wmicrosoft -verify -fms-compatibility -fexceptions -fcxx-exceptions 
-fms-compatibility-version=19.27
 // RUN: %clang_cc1 %s -triple i686-pc-win32 -fsyntax-only -std=c++11 
-Wmicrosoft -verify -fms-compatibility -fexceptions -fcxx-exceptions 
-fms-compatibility-version=19.00
 // RUN: %clang_cc1 %s -triple i686-pc-win32 -fsyntax-only -std=c++11 
-Wmicrosoft -verify -fms-compatibility -fexceptions -fcxx-exceptions 
-fms-compatibility-version=18.00
 
@@ -28,12 +30,20 @@
 
 void f(float a);
 void f(int a);
+#if _MSC_VER >= 1928
+// expected-note@-3 2 {{candidate function}}
+// expected-note@-3 2 {{candidate function}}
+#endif
 
 void test()
 {
 long a = 0;
 f((long)0);
-   f(a);
+f(a);
+#if _MSC_VER >= 1928
+// expected-error@-3 {{call to 'f' is ambiguous}}
+// expected-error@-3 {{call to 'f' is ambiguous}}
+#endif
 }
 
 }
Index: clang/lib/Sema/SemaOverload.cpp
===
--- clang/lib/Sema/SemaOverload.cpp
+++ clang/lib/Sema/SemaOverload.cpp
@@ -4106,7 +4106,7 @@
 }
   }
 
-  // In Microsoft mode, prefer an integral conversion to a
+  // In Microsoft mode (below 19.28), prefer an integral conversion to a
   // floating-to-integral conversion if the integral conversion
   // is between types of the same size.
   // For example:
@@ -4118,7 +4118,9 @@
   // }
   // Here, MSVC will call f(int) instead of generating a compile error
   // as clang will do in standard mode.
-  if (S.getLangOpts().MSVCCompat && SCS1.Second == ICK_Integral_Conversion &&
+  if (S.getLangOpts().MSVCCompat &&
+  !S.getLangOpts().isCompatibleWithMSVC(LangOptions::MSVC2019_8) &&
+  SCS1.Second == ICK_Integral_Conversion &&
   SCS2.Second == ICK_Floating_Integral &&
   S.Context.getTypeSize(SCS1.getFromType()) ==
   S.Context.getTypeSize(SCS1.getToType(2)))
Index: clang/include/clang/Basic/LangOptions.h
===
--- clang/include/clang/Basic/LangOptions.h
+++ clang/include/clang/Basic/LangOptions.h
@@ -124,6 +124,7 @@
 MSVC2017_5 = 1912,
 MSVC2017_7 = 1914,
 MSVC2019 = 1920,
+MSVC2019_8 = 1928,
   };
 
   enum SYCLMajorVersion {


Index: clang/test/SemaCXX/MicrosoftCompatibility.cpp
===
--- clang/test/SemaCXX/MicrosoftCompatibility.cpp
+++ clang/test/SemaCXX/MicrosoftCompatibility.cpp
@@ -1,3 +1,5 @@
+// RUN: %clang_cc1 %s -triple i686-pc-win32 -fsyntax-only -std=c++11 -Wmicrosoft -verify -fms-compatibility -fexceptions -fcxx-exceptions -fms-compatibility-version=19.28
+// RUN: %clang_cc1 %s -triple i686-pc-win32 -fsyntax-only -std=c++11 -Wmicrosoft -verify -fms-compatibility -fexceptions -fcxx-exceptions -fms-compatibility-version=19.27
 // RUN: %clang_cc1 %s -triple i686-pc-win32 -fsyntax-only -std=c++11 -Wmicrosoft -verify -fms-compatibility -fexceptions -fcxx-exceptions -fms-compatibility-version=19.00
 // RUN: %clang_cc1 %s -triple i686-pc-win32 -fsyntax-only -std=c++11 -Wmicrosoft -verify -fms-compatibility -fexceptions -fcxx-exceptions -fms-compatibility-version=18.00
 
@@ -28,12 +30,20 @@
 
 void f(float a);
 void f(int a);
+#if _MSC_VER >= 1928
+// expected-note@-3 2 {{candidate function}}
+// expected-note@-3 2 {{candidate function}}
+#endif
 
 void test()
 {
 long a = 0;
 f((long)0);
-	f(a);
+f(a);
+#if _MSC_VER >= 1928
+// expected-error@-3 {{call to 'f' is ambiguous}}
+// expected-error@-3 {{call to 'f' is ambiguous}}
+#endif
 }
 
 }
Index: clang/lib/Sema/SemaOverload.cpp
===
--- clang/lib/Sema/SemaOverload.cpp
+++ clang/lib/Sema/SemaOverload.cpp
@@ -4106,7 +4106,7 @@
 }
   }
 
-  // In 

[PATCH] D93095: Introduce -Wreserved-identifier

[serge via Phabricator via cfe-commits]

serge-sans-paille added inline comments.



Comment at: clang/lib/AST/Decl.cpp:1097
+  // ignored values) that we don't warn on it.
+  if (Name.size() <= 1)
+return ReservedIdentifierStatus::NotReserved;

rsmith wrote:
> Would it make sense to move the rest of this function to a member on 
> `IdentifierInfo`? That is, the rest of this function would become:
> 
> ```
> ReservedIdentifierStatus Status = II->isReserved(LangOpts);
> if (Status == ReservedIdentifierStatus::StartsWithUnderscoreAtGlobalScope &&
> isa(this) || isTemplateParameter() ||
> !getDeclContext()->getRedeclContext()->isTranslationUnit())
>   return ReservedIdentifierStatus::NotReserved;
> return Status;
> ```
> 
> That way, we should be able to reuse the same implementation to detect 
> reserved macros too.
I did the `II->isReserved(LangOpts)` part, but the updated condition 
`!getDeclContext()->getRedeclContext()->isTranslationUnit()` fails the 
validation. I did already spend a lot of time getting one that catches the 
behavior we wanted, so 'm not super-eager to investigate why this change would 
not work ;-)


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

https://reviews.llvm.org/D93095

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

[PATCH] D93095: Introduce -Wreserved-identifier

[serge via Phabricator via cfe-commits]

serge-sans-paille updated this revision to Diff 334445.
serge-sans-paille added a comment.
Herald added a subscriber: dexonsmith.

Another round of review :-) I addressed both the scattering of 
`warnOnReservedIdentifier` and the code split between `Decl.cpp` and 
`IdentifierInfo.cpp`.


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

https://reviews.llvm.org/D93095

Files:
  clang/include/clang/AST/Decl.h
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/IdentifierTable.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/Decl.cpp
  clang/lib/Basic/IdentifierTable.cpp
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/lib/Sema/SemaCodeComplete.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaStmt.cpp
  clang/lib/Sema/SemaTemplate.cpp
  clang/test/Sema/reserved-identifier.c
  clang/test/Sema/reserved-identifier.cpp

Index: clang/test/Sema/reserved-identifier.cpp
===
--- /dev/null
+++ clang/test/Sema/reserved-identifier.cpp
@@ -0,0 +1,87 @@
+// RUN: %clang_cc1 -fsyntax-only -std=c++20 -verify -Wreserved-identifier %s
+
+int foo__bar() { return 0; }// expected-warning {{identifier 'foo__bar' is reserved because it contains '__'}}
+static int _bar() { return 0; } // expected-warning {{identifier '_bar' is reserved because it starts with '_' at global scope}}
+static int _Bar() { return 0; } // expected-warning {{identifier '_Bar' is reserved because it starts with '_' followed by a capital letter}}
+int _barbouille() { return 0; } // expected-warning {{identifier '_barbouille' is reserved because it starts with '_' at global scope}}
+
+void foo(unsigned int _Reserved) { // expected-warning {{identifier '_Reserved' is reserved because it starts with '_' followed by a capital letter}}
+  unsigned int __1 =   // expected-warning {{identifier '__1' is reserved because it starts with '__'}}
+  _Reserved;   // no-warning
+}
+
+// This one is explicitly skipped by -Wreserved-identifier
+void *_; // no-warning
+
+template  constexpr bool __toucan = true; // expected-warning {{identifier '__toucan' is reserved because it starts with '__'}}
+
+template 
+concept _Barbotine = __toucan; // expected-warning {{identifier '_Barbotine' is reserved because it starts with '_' followed by a capital letter}}
+
+template  // expected-warning {{'__' is reserved because it starts with '__'}}
+struct BarbeNoire {};
+
+template  // no-warning
+struct BarbeJaune {};
+
+template  // expected-warning {{'__' is reserved because it starts with '__'}}
+void BarbeRousse() {}
+
+namespace _Barbidur { // expected-warning {{identifier '_Barbidur' is reserved because it starts with '_' followed by a capital letter}}
+
+struct __barbidou {}; // expected-warning {{identifier '__barbidou' is reserved because it starts with '__'}}
+struct _barbidou {};  // no-warning
+
+int __barbouille; // expected-warning {{identifier '__barbouille' is reserved because it starts with '__'}}
+int _barbouille;  // no-warning
+
+int __babar() { return 0; } // expected-warning {{identifier '__babar' is reserved because it starts with '__'}}
+int _babar() { return 0; }  // no-warning
+
+} // namespace _Barbidur
+
+class __barbapapa { // expected-warning {{identifier '__barbapapa' is reserved because it starts with '__'}}
+  void _barbabelle() {} // no-warning
+  int _Barbalala;   // expected-warning {{identifier '_Barbalala' is reserved because it starts with '_' followed by a capital letter}}
+};
+
+enum class __menu { // expected-warning {{identifier '__menu' is reserved because it starts with '__'}}
+  __some,   // expected-warning {{identifier '__some' is reserved because it starts with '__'}}
+  _Other,   // expected-warning {{identifier '_Other' is reserved because it starts with '_' followed by a capital letter}}
+  _other// no-warning
+};
+
+enum _Menu { // expected-warning {{identifier '_Menu' is reserved because it starts with '_' followed by a capital letter}}
+  _OtheR_,   // expected-warning {{identifier '_OtheR_' is reserved because it starts with '_' followed by a capital letter}}
+  _other_// expected-warning {{identifier '_other_' is reserved because it starts with '_' at global scope}}
+};
+
+enum {
+  __some, // expected-warning {{identifier '__some' is reserved because it starts with '__'}}
+  _Other, // expected-warning {{identifier '_Other' is reserved because it starts with '_' followed by a capital letter}}
+  _other  // expected-warning {{identifier '_other' is reserved because it starts with '_' at global scope}}
+};
+
+static union {
+  int _barbeFleurie; // no-warning
+};
+
+using _Barbamama = __barbapapa; // expected-warning {{identifier '_Barbamama' is reserved because it starts with '_' followed by a capital letter}}
+
+int foobar() {
+  return foo__bar(); // no-warning
+}
+

[PATCH] D83660: [analyzer] Fix a crash for dereferencing an empty llvm::Optional variable in SMTConstraintManager.h.

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

steakhal added a comment.

In D83660#2661369 , @martong wrote:

> I went through the change and it looks good, seems like this is indeed a copy 
> paste error from line 132.
> I checked the related conversation, and thanks for all the effort spent with 
> the test.
>
>> BTW, I was obstructed by the z3 requirement in the regression test case when 
>> I tried to understand your test case. Even though I set the variables 
>> LLVM_Z3_INSTALL_DIR and LLVM_ENABLE_Z3_SOLVER during CMake, and the CSA can 
>> be correctly compiled with Z3, I still cannot make the test case run during 
>> make check-all. Therefore, this case was manually executed with llvm-lit 
>> -DUSE_Z3_SOLVER=1. Could you please tell me how to enable Z3 during llvm-lit.
>
> I am a bit unhappy that we cannot run the test automatically, but maybe in 
> the future.
> @steakhal, https://reviews.llvm.org/D83677 seems to be related, should we 
> push that?

I wouldn't mind fixing that yes, but right now I'm busy with other things.
Let's come back to it later.


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

https://reviews.llvm.org/D83660

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

[PATCH] D98237: [clang-format] Option for empty lines after an access modifier.

[Marek Kurdej via Phabricator via cfe-commits]

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

LGTM, but please clean up the comments before landing.




Comment at: clang/docs/ClangFormatStyleOptions.rst:2132
+**EmptyLineAfterAccessModifier** (``EmptyLineAfterAccessModifierStyle``)
+  Defines in which cases to put empty line after access modifiers.
+  ``EmptyLineBeforeAccessModifier`` configuration handles the number of

Please apply this when landing.



Comment at: clang/unittests/Format/FormatTest.cpp:9289
+
+  // Check if MaxEmptyLinesToKeep is adhered
+  EXPECT_EQ("struct foo {\n"

Nit. Here and elsewhere.



Comment at: clang/unittests/Format/FormatTest.cpp:9546
+
+  Style.MaxEmptyLinesToKeep = 10u; // Both remove all new lines
+  Style.EmptyLineBeforeAccessModifier = FormatStyle::ELBAMS_Never;

Please rephrase/move the comment to be clear that it concerns ELBAMS/ELAAMS.



Comment at: clang/unittests/Format/FormatTest.cpp:9598
+   "};\n",
+   Style)); // Based on new lines in orignal document and not 
on
+// the setting

Nit.



Comment at: clang/unittests/Format/FormatTest.cpp:9605
+  // Newlines are keept if they are greater than zero,
+  // test::messUp removes all new lines which changes the logic
+  EXPECT_EQ("struct foo {\n"

Please end comments with full stops. Here and elsewhere.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98237

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