[PATCH] D122248: [clang][CodeGen]Fix clang crash and add bitfield support in __builtin_dump_struct

2022-03-23 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D122248#3403143 , @yihanaa wrote:

> 1. Support zero-width bitfield, named bitfield and unnamed bitfield.
> 2. Add a release notes.
>
> The builtin function __builtin_dump_struct behaves for zero-width bitfield 
> and unnamed bitfield as follows
>
>   int printf(const char *fmt, ...);
>   
>   void foo(void) {
> struct Bar {
>   unsigned c : 1;
>   unsigned : 3;
>   unsigned : 0;
>   unsigned b;
> };
>   
> struct Bar a = {
>   .c = 1,
>   .b = 2022,
> };
>   
> __builtin_dump_struct(, );
>   }
>   
>   int main() {
> foo();
> return 0;
>   }
>
> Output:
>
>   struct Bar {
>   unsigned int c : 1
>   unsigned int  : 0
>   unsigned int b : 2022
>   }

Thank you for the release note and additional test coverage. I'm wondering why 
we handle the zero-width bit-field differently from the anonymous one (e.g., 
why do we not have `unsigned int : 3` before the `unsigned int : 0`? It seems a 
bit odd to drop that from the output.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122248

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


[clang] f833aab - [clang][extract-api] Enable processing of multiple headers

2022-03-23 Thread Daniel Grumberg via cfe-commits

Author: Daniel Grumberg
Date: 2022-03-23T19:05:19Z
New Revision: f833aab0d0bf1bd9e9903a1398e429f431532f5f

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

LOG: [clang][extract-api] Enable processing of multiple headers

Before actually executing the ExtractAPIAction, clear the
CompilationInstance's input list and replace it with a single
synthesized file that just includes (or imports in ObjC) all the inputs.

Depends on D122141

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

Added: 
clang/test/ExtractAPI/global_record_multifile.c

Modified: 
clang/include/clang/ExtractAPI/FrontendActions.h
clang/lib/ExtractAPI/ExtractAPIConsumer.cpp

Removed: 




diff  --git a/clang/include/clang/ExtractAPI/FrontendActions.h 
b/clang/include/clang/ExtractAPI/FrontendActions.h
index e43b6cf9212d6..4c9449fe73a92 100644
--- a/clang/include/clang/ExtractAPI/FrontendActions.h
+++ b/clang/include/clang/ExtractAPI/FrontendActions.h
@@ -24,9 +24,22 @@ class ExtractAPIAction : public ASTFrontendAction {
   std::unique_ptr CreateASTConsumer(CompilerInstance ,
  StringRef InFile) override;
 
+private:
+  /// The synthesized input buffer that contains all the provided input header
+  /// files.
+  std::unique_ptr Buffer;
+
 public:
+  /// Prepare to execute the action on the given CompilerInstance.
+  ///
+  /// This is called before executing the action on any inputs. This generates 
a
+  /// single header that includes all of CI's inputs and replaces CI's input
+  /// list with it before actually executing the action.
+  bool PrepareToExecuteAction(CompilerInstance ) override;
+
   static std::unique_ptr
   CreateOutputFile(CompilerInstance , StringRef InFile);
+  static StringRef getInputBufferName() { return ""; }
 };
 
 } // namespace clang

diff  --git a/clang/lib/ExtractAPI/ExtractAPIConsumer.cpp 
b/clang/lib/ExtractAPI/ExtractAPIConsumer.cpp
index 7007d08e839be..0636e6de7cc26 100644
--- a/clang/lib/ExtractAPI/ExtractAPIConsumer.cpp
+++ b/clang/lib/ExtractAPI/ExtractAPIConsumer.cpp
@@ -27,6 +27,9 @@
 #include "clang/ExtractAPI/Serialization/SymbolGraphSerializer.h"
 #include "clang/Frontend/ASTConsumers.h"
 #include "clang/Frontend/CompilerInstance.h"
+#include "clang/Frontend/FrontendOptions.h"
+#include "llvm/ADT/SmallVector.h"
+#include "llvm/Support/MemoryBuffer.h"
 #include "llvm/Support/raw_ostream.h"
 
 using namespace clang;
@@ -339,6 +342,35 @@ ExtractAPIAction::CreateASTConsumer(CompilerInstance , 
StringRef InFile) {
   std::move(OS));
 }
 
+bool ExtractAPIAction::PrepareToExecuteAction(CompilerInstance ) {
+  auto  = CI.getFrontendOpts().Inputs;
+  if (Inputs.empty())
+return true;
+
+  auto Kind = Inputs[0].getKind();
+
+  // Convert the header file inputs into a single input buffer.
+  SmallString<256> HeaderContents;
+  for (const FrontendInputFile  : Inputs) {
+if (Kind.isObjectiveC())
+  HeaderContents += "#import";
+else
+  HeaderContents += "#include";
+HeaderContents += " \"";
+HeaderContents += FIF.getFile();
+HeaderContents += "\"\n";
+  }
+
+  Buffer = llvm::MemoryBuffer::getMemBufferCopy(HeaderContents,
+getInputBufferName());
+
+  // Set that buffer up as our "real" input in the CompilerInstance.
+  Inputs.clear();
+  Inputs.emplace_back(Buffer->getMemBufferRef(), Kind, /*IsSystem*/ false);
+
+  return true;
+}
+
 std::unique_ptr
 ExtractAPIAction::CreateOutputFile(CompilerInstance , StringRef InFile) {
   std::unique_ptr OS =

diff  --git a/clang/test/ExtractAPI/global_record_multifile.c 
b/clang/test/ExtractAPI/global_record_multifile.c
new file mode 100644
index 0..cc5448e838298
--- /dev/null
+++ b/clang/test/ExtractAPI/global_record_multifile.c
@@ -0,0 +1,371 @@
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+// RUN: sed -e "s@INPUT_DIR@%/t@g" %t/reference.output.json.in >> \
+// RUN: %t/reference.output.json
+// RUN: %clang -extract-api --product-name=GlobalRecord -target 
arm64-apple-macosx \
+// RUN: %t/input1.h %t/input2.h %t/input3.h -o %t/output.json | FileCheck 
-allow-empty %s
+
+// Generator version is not consistent across test runs, normalize it.
+// RUN: sed -e "s@\"generator\": \".*\"@\"generator\": \"?\"@g" \
+// RUN: %t/output.json >> %t/output-normalized.json
+// RUN: 
diff  %t/reference.output.json %t/output-normalized.json
+
+// CHECK-NOT: error:
+// CHECK-NOT: warning:
+
+//--- input1.h
+int num;
+
+//--- input2.h
+/**
+ * \brief Add two numbers.
+ * \param [in]  x   A number.
+ * \param [in]  y   Another number.
+ * \param [out] res The result of x + y.
+ */
+void add(const int x, const int y, int *res);
+
+//--- input3.h
+char unavailable __attribute__((unavailable));
+
+//--- 

[PATCH] D119493: Fixing surplus assert condition in EvaluateTemporary

2022-03-23 Thread Eli Friedman via Phabricator via cfe-commits
efriedma added a comment.

I'm not sure this is the right fix. If we were handling the pseudo-destructor 
correctly, I would expect the following to compile successfully:

  typedef bool Var;
  constexpr bool foobool() {
return (bool().Var::~Var(), false); 
  }


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

https://reviews.llvm.org/D119493

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


[PATCH] D121927: [Clang] Work with multiple pragmas weak before definition

2022-03-23 Thread Hubert Tong via Phabricator via cfe-commits
hubert.reinterpretcast updated this revision to Diff 417666.
hubert.reinterpretcast marked an inline comment as done.
hubert.reinterpretcast added a comment.

- Address review comments: Return `const` from getAlias()


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121927

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Sema/Sema.h
  clang/include/clang/Sema/Weak.h
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/test/CodeGen/pragma-weak.c
  clang/test/PCH/pragma-weak-functional.c
  clang/test/PCH/pragma-weak-functional.h

Index: clang/test/PCH/pragma-weak-functional.h
===
--- /dev/null
+++ clang/test/PCH/pragma-weak-functional.h
@@ -0,0 +1,6 @@
+// Header for PCH test pragma-weak-functional.c
+
+#pragma weak undecfunc_alias2 = undecfunc
+#pragma weak undecfunc_alias4 = undecfunc_alias1
+#pragma weak undecfunc_alias3 = undecfunc_alias1
+#pragma weak undecfunc_alias1 = undecfunc
Index: clang/test/PCH/pragma-weak-functional.c
===
--- /dev/null
+++ clang/test/PCH/pragma-weak-functional.c
@@ -0,0 +1,17 @@
+// Test this without pch.
+// RUN: %clang_cc1 -include %S/pragma-weak-functional.h %s -verify -emit-llvm -o - | FileCheck %s
+
+// Test with pch.
+// RUN: %clang_cc1 -x c-header -emit-pch -o %t %S/pragma-weak-functional.h
+// RUN: %clang_cc1 -include-pch %t %s -verify -emit-llvm -o - | FileCheck %s
+
+// CHECK-DAG: @undecfunc_alias1 = weak{{.*}} alias void (), void ()* @undecfunc
+// CHECK-DAG: @undecfunc_alias2 = weak{{.*}} alias void (), void ()* @undecfunc
+// CHECK-DAG: @undecfunc_alias3 = weak{{.*}} alias void (), void ()* @undecfunc
+// CHECK-DAG: @undecfunc_alias4 = weak{{.*}} alias void (), void ()* @undecfunc
+
+/ PR28611: Try multiple aliases of same undeclared symbol or alias
+void undecfunc_alias1(void);
+void undecfunc(void) { }
+// expected-warning@pragma-weak-functional.h:4 {{alias will always resolve to undecfunc}}
+// expected-warning@pragma-weak-functional.h:5 {{alias will always resolve to undecfunc}}
Index: clang/test/CodeGen/pragma-weak.c
===
--- clang/test/CodeGen/pragma-weak.c
+++ clang/test/CodeGen/pragma-weak.c
@@ -17,6 +17,10 @@
 // CHECK-DAG: @mix2 = weak{{.*}} alias void (), void ()* @__mix2
 // CHECK-DAG: @a1 = weak{{.*}} alias void (), void ()* @__a1
 // CHECK-DAG: @xxx = weak{{.*}} alias void (), void ()* @__xxx
+// CHECK-DAG: @undecfunc_alias1 = weak{{.*}} alias void (), void ()* @undecfunc
+// CHECK-DAG: @undecfunc_alias2 = weak{{.*}} alias void (), void ()* @undecfunc
+// CHECK-DAG: @undecfunc_alias3 = weak{{.*}} alias void (), void ()* @undecfunc
+// CHECK-DAG: @undecfunc_alias4 = weak{{.*}} alias void (), void ()* @undecfunc
 
 
 
@@ -136,6 +140,15 @@
 __attribute((pure,noinline,const)) void __xxx(void) { }
 // CHECK: void @__xxx() [[RN:#[0-9]+]]
 
+/ PR28611: Try multiple aliases of same undeclared symbol or alias
+#pragma weak undecfunc_alias1 = undecfunc
+#pragma weak undecfunc_alias1 = undecfunc // Try specifying same alias/target pair a second time.
+#pragma weak undecfunc_alias3 = undecfunc_alias2 // expected-warning {{alias will always resolve to undecfunc}}
+#pragma weak undecfunc_alias4 = undecfunc_alias2 // expected-warning {{alias will always resolve to undecfunc}}
+#pragma weak undecfunc_alias2 = undecfunc
+void undecfunc_alias2(void);
+void undecfunc(void) { }
+
 / PR10878: Make sure we can call a weak alias
 void SHA512Pad(void *context) {}
 #pragma weak SHA384Pad = SHA512Pad
Index: clang/lib/Serialization/ASTWriter.cpp
===
--- clang/lib/Serialization/ASTWriter.cpp
+++ clang/lib/Serialization/ASTWriter.cpp
@@ -4559,13 +4559,14 @@
   // entire table, since later PCH files in a PCH chain are only interested in
   // the results at the end of the chain.
   RecordData WeakUndeclaredIdentifiers;
-  for (auto  : SemaRef.WeakUndeclaredIdentifiers) {
-IdentifierInfo *II = WeakUndeclaredIdentifier.first;
-WeakInfo  = WeakUndeclaredIdentifier.second;
-AddIdentifierRef(II, WeakUndeclaredIdentifiers);
-AddIdentifierRef(WI.getAlias(), WeakUndeclaredIdentifiers);
-AddSourceLocation(WI.getLocation(), WeakUndeclaredIdentifiers);
-WeakUndeclaredIdentifiers.push_back(WI.getUsed());
+  for (const auto  :
+   SemaRef.WeakUndeclaredIdentifiers) {
+const IdentifierInfo *const II = WeakUndeclaredIdentifierList.first;
+for (const auto  : WeakUndeclaredIdentifierList.second) {
+  AddIdentifierRef(II, WeakUndeclaredIdentifiers);
+  AddIdentifierRef(WI.getAlias(), WeakUndeclaredIdentifiers);
+  AddSourceLocation(WI.getLocation(), 

[PATCH] D121873: [clang][extract-api] Add enum support

2022-03-23 Thread Daniel Grumberg via Phabricator via cfe-commits
dang accepted this revision.
dang added a comment.
This revision is now accepted and ready to land.

LGTM!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121873

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


[PATCH] D122202: [clang][extract-api] Add struct support

2022-03-23 Thread Daniel Grumberg via Phabricator via cfe-commits
dang accepted this revision.
dang added a comment.
This revision is now accepted and ready to land.

LGTM!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122202

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


[PATCH] D121927: [Clang] Work with multiple pragmas weak before definition

2022-03-23 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman accepted this revision.
aaron.ballman added a comment.

LGTM, thank you for the fix!




Comment at: clang/include/clang/Sema/Weak.h:62
+return false;
+  return LHS.getAlias()->getName() == RHS.getAlias()->getName();
+}

hubert.reinterpretcast wrote:
> aaron.ballman wrote:
> > Previously we cared about the source locations being the same. But... is 
> > there a situation where the aliases are the same but the source locations 
> > are different? I can't think of any, so perhaps that's worth an assert that 
> > the locations match?
> We didn't really case about the source locations being the same. The removed 
> operators were just dead code (featuring such things as 
> compare-by-pointer-value). I have verified that splitting the deletion of 
> them to a separate patch does not cause any build or LIT `check-all` 
> failures. I can commit that part as an NFC patch first if you prefer.
> 
> Also, the aliases //can// be the same with different source locations. The 
> location comes from where the `#pragma weak` is (from the parser by way of 
> `ActOnPragmaWeakAlias`). That duplicates are ignored (meaning we only 
> diagnose one instance) is mentioned in the patch description.
> 
> It is already the status quo that having the same alias specified with 
> different targets (at least those not yet declared) neither produces a 
> diagnostic nor operates by "last one wins". Instead, Clang prefers the first 
> declared target and GCC just emits both and leaves it to the assembler to 
> figure out (https://godbolt.org/z/EasK375j3).
Ah, thank you for the explanation, that makes sense to me.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121927

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


[PATCH] D122331: [clang][extract-api] Stop allocating APIRecords via BumpPtrAllocator

2022-03-23 Thread Daniel Grumberg via Phabricator via cfe-commits
dang created this revision.
dang added reviewers: zixuw, QuietMisdreavus, ributzka.
Herald added a project: All.
dang requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Using a BumpPtrAllocator introduced memory leaks for APIRecords as they
contain a std::vector. This meant that we needed to always keep a
reference to the records in APISet and arrange for their destructor to
get called appropriately. This was further complicated by the need for
records to own sub-records as these subrecords would still need to be
allocated via the BumpPtrAllocator and the owning record would now need
to arrange for the destructor of its subrecords to be called
appropriately.

Since APIRecords contain a std::vector so whenever elements get added to
that there is an associated heap allocation regardless. Since
performance isn't currently our main priority it makes sense to use
regular unique_ptr to keep track of APIRecords, this way we don't need
to arrange for destructors to get called.

The BumpPtrAllocator is still used for strings such as USRs so that we
can easily de-duplicate them as necessary.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D122331

Files:
  clang/include/clang/ExtractAPI/API.h
  clang/lib/ExtractAPI/API.cpp

Index: clang/lib/ExtractAPI/API.cpp
===
--- clang/lib/ExtractAPI/API.cpp
+++ clang/lib/ExtractAPI/API.cpp
@@ -18,6 +18,7 @@
 #include "clang/AST/RawCommentList.h"
 #include "clang/Index/USRGeneration.h"
 #include "llvm/Support/Allocator.h"
+#include 
 
 using namespace clang::extractapi;
 using namespace llvm;
@@ -32,9 +33,9 @@
   auto Result = Globals.insert({Name, nullptr});
   if (Result.second) {
 // Create the record if it does not already exist.
-auto Record = APIRecordUniquePtr(new (Allocator) GlobalRecord{
+auto Record = std::make_unique(
 Kind, Name, USR, Loc, Availability, Linkage, Comment, Fragments,
-SubHeading, Signature});
+SubHeading, Signature);
 Result.first->second = std::move(Record);
   }
   return Result.first->second.get();
@@ -63,9 +64,8 @@
 EnumRecord *Enum, StringRef Name, StringRef USR, PresumedLoc Loc,
 const AvailabilityInfo , const DocComment ,
 DeclarationFragments Declaration, DeclarationFragments SubHeading) {
-  auto Record =
-  APIRecordUniquePtr(new (Allocator) EnumConstantRecord{
-  Name, USR, Loc, Availability, Comment, Declaration, SubHeading});
+  auto Record = std::make_unique(
+  Name, USR, Loc, Availability, Comment, Declaration, SubHeading);
   return Enum->Constants.emplace_back(std::move(Record)).get();
 }
 
@@ -77,8 +77,8 @@
   auto Result = Enums.insert({Name, nullptr});
   if (Result.second) {
 // Create the record if it does not already exist.
-auto Record = APIRecordUniquePtr(new (Allocator) EnumRecord{
-Name, USR, Loc, Availability, Comment, Declaration, SubHeading});
+auto Record = std::make_unique(
+Name, USR, Loc, Availability, Comment, Declaration, SubHeading);
 Result.first->second = std::move(Record);
   }
   return Result.first->second.get();
@@ -90,9 +90,8 @@
   const DocComment ,
   DeclarationFragments Declaration,
   DeclarationFragments SubHeading) {
-  auto Record =
-  APIRecordUniquePtr(new (Allocator) StructFieldRecord{
-  Name, USR, Loc, Availability, Comment, Declaration, SubHeading});
+  auto Record = std::make_unique(
+  Name, USR, Loc, Availability, Comment, Declaration, SubHeading);
   return Struct->Fields.emplace_back(std::move(Record)).get();
 }
 
@@ -104,8 +103,8 @@
   auto Result = Structs.insert({Name, nullptr});
   if (Result.second) {
 // Create the record if it does not already exist.
-auto Record = APIRecordUniquePtr(new (Allocator) StructRecord{
-Name, USR, Loc, Availability, Comment, Declaration, SubHeading});
+auto Record = std::make_unique(
+Name, USR, Loc, Availability, Comment, Declaration, SubHeading);
 Result.first->second = std::move(Record);
   }
   return Result.first->second.get();
Index: clang/include/clang/ExtractAPI/API.h
===
--- clang/include/clang/ExtractAPI/API.h
+++ clang/include/clang/ExtractAPI/API.h
@@ -30,25 +30,6 @@
 #include "llvm/Support/Casting.h"
 #include 
 
-namespace {
-
-/// \brief A custom deleter used for ``std::unique_ptr`` to APIRecords stored
-/// in the BumpPtrAllocator.
-///
-/// \tparam T the exact type of the APIRecord subclass.
-template  struct UniquePtrBumpPtrAllocatorDeleter {
-  void operator()(T *Instance) { Instance->~T(); }
-};
-
-/// A unique pointer to an APIRecord stored in the BumpPtrAllocator.
-///
-/// \tparam T the exact type of the APIRecord subclass.
-template 
-using APIRecordUniquePtr =
-

[PATCH] D122069: [Clang] Add binary format for bundling offloading metadata

2022-03-23 Thread Joseph Huber via Phabricator via cfe-commits
jhuber6 updated this revision to Diff 417685.
jhuber6 added a comment.

Updating to use path instead of generic cmdline, makes it a lot easier to pass 
it. Also just adding a reserved field in case I want to add the cmdline back.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122069

Files:
  clang/include/clang/Basic/CodeGenOptions.h
  clang/include/clang/Basic/Offloading.h
  clang/lib/Basic/CMakeLists.txt
  clang/lib/Basic/Offloading.cpp
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/openmp-offload-gpu.c
  clang/test/Frontend/embed-object.c
  clang/test/Frontend/embed-object.ll
  clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
  llvm/include/llvm/Transforms/Utils/ModuleUtils.h
  llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp
  llvm/lib/Transforms/Utils/ModuleUtils.cpp

Index: llvm/lib/Transforms/Utils/ModuleUtils.cpp
===
--- llvm/lib/Transforms/Utils/ModuleUtils.cpp
+++ llvm/lib/Transforms/Utils/ModuleUtils.cpp
@@ -265,15 +265,15 @@
 }
 
 void llvm::embedBufferInModule(Module , MemoryBufferRef Buf,
-   StringRef SectionName) {
-  // Embed the buffer into the module.
+   StringRef SectionName, Align Alignment) {
+  // Embed the memory buffer into the module.
   Constant *ModuleConstant = ConstantDataArray::get(
   M.getContext(), makeArrayRef(Buf.getBufferStart(), Buf.getBufferSize()));
   GlobalVariable *GV = new GlobalVariable(
-  M, ModuleConstant->getType(), true, GlobalValue::ExternalLinkage,
-  ModuleConstant, SectionName.drop_front());
+  M, ModuleConstant->getType(), true, GlobalValue::PrivateLinkage,
+  ModuleConstant, "llvm.embedded.object");
   GV->setSection(SectionName);
-  GV->setVisibility(GlobalValue::HiddenVisibility);
+  GV->setAlignment(Alignment);
 
   appendToCompilerUsed(M, GV);
 }
Index: llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp
===
--- llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp
+++ llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp
@@ -447,7 +447,7 @@
   Name == getInstrProfSectionName(IPSK_covfun, Triple::ELF,
   /*AddSegmentInfo=*/false) ||
   Name == ".llvmbc" || Name == ".llvmcmd" ||
-  Name.startswith(".llvm.offloading."))
+  Name.startswith(".llvm.offloading"))
 return SectionKind::getMetadata();
 
   if (Name.empty() || Name[0] != '.') return K;
Index: llvm/include/llvm/Transforms/Utils/ModuleUtils.h
===
--- llvm/include/llvm/Transforms/Utils/ModuleUtils.h
+++ llvm/include/llvm/Transforms/Utils/ModuleUtils.h
@@ -14,6 +14,7 @@
 #define LLVM_TRANSFORMS_UTILS_MODULEUTILS_H
 
 #include "llvm/ADT/StringRef.h"
+#include "llvm/Support/Alignment.h"
 #include "llvm/Support/MemoryBufferRef.h"
 #include  // for std::pair
 
@@ -109,7 +110,8 @@
 
 /// Embed the memory buffer \p Buf into the module \p M as a global using the
 /// specified section name.
-void embedBufferInModule(Module , MemoryBufferRef Buf, StringRef SectionName);
+void embedBufferInModule(Module , MemoryBufferRef Buf, StringRef SectionName,
+ Align Alignment = Align(1));
 
 class CallInst;
 namespace VFABI {
Index: clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
===
--- clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
+++ clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
@@ -15,6 +15,7 @@
 //===-===//
 
 #include "OffloadWrapper.h"
+#include "clang/Basic/Offloading.h"
 #include "clang/Basic/Version.h"
 #include "llvm/BinaryFormat/Magic.h"
 #include "llvm/Bitcode/BitcodeWriter.h"
@@ -47,6 +48,7 @@
 #include "llvm/Target/TargetMachine.h"
 
 using namespace llvm;
+using namespace clang;
 using namespace llvm::object;
 
 static cl::opt Help("h", cl::desc("Alias for -help"), cl::Hidden);
@@ -146,9 +148,10 @@
 static codegen::RegisterCodeGenFlags CodeGenFlags;
 
 /// Magic section string that marks the existence of offloading data. The
-/// section string will be formatted as `.llvm.offloading..`.
-#define OFFLOAD_SECTION_MAGIC_STR ".llvm.offloading."
+/// section will contain one or more offloading binaries stored contiguously.
+#define OFFLOAD_SECTION_MAGIC_STR ".llvm.offloading"
 
+// TODO: Replace all uses of DeviceFile with OffloadFile.
 /// Information for a device offloading file extracted from the host.
 struct DeviceFile {
   DeviceFile(StringRef Kind, StringRef TheTriple, StringRef Arch,
@@ -201,16 +204,6 @@
 llvm::errs() << *IC << (std::next(IC) != IE ? " " : "\n");
 }
 
-static StringRef getDeviceFileExtension(StringRef DeviceTriple,
-  

[PATCH] D122248: [clang][CodeGen]Fix clang crash and add bitfield support in __builtin_dump_struct

2022-03-23 Thread Wang Yihan via Phabricator via cfe-commits
yihanaa updated this revision to Diff 417687.
yihanaa added a comment.

1. Support zero-width bitfield.
2. Supported unnamed bitfield.
3. Add a release notes.

The builtin function __builtin_dump_struct behaves for zero-width bitfield and 
unnamed bitfield as follows

  void test8(void) {
struct T8A {
  unsigned c : 1;
  unsigned : 3;
  unsigned : 0;
  unsigned b;
};
  
struct T8A a = {
  .b = 2022,
};
  
__builtin_dump_struct(, );
  }
  
  int main() {
test8();
  }

Output:

  struct T8A {
  unsigned int c : 0
  unsigned int  : 0
  unsigned int b : 2022
  }


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122248

Files:
  clang/docs/ReleaseNotes.rst
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/dump-struct-builtin.c

Index: clang/test/CodeGen/dump-struct-builtin.c
===
--- clang/test/CodeGen/dump-struct-builtin.c
+++ clang/test/CodeGen/dump-struct-builtin.c
@@ -126,7 +126,7 @@
   .a = 12,
   };
   // CHECK: call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([14 x i8], [14 x i8]* [[STRUCT_STR_U1]], i32 0, i32 0))
-  // CHECK: [[RES1:%[0-9]+]] = getelementptr inbounds %struct.U1A, %struct.U1A* %a, i32 0, i32 0
+  // CHECK: [[RES1:%[−a−zA−Z._0-9]+]] = getelementptr inbounds %struct.U1A, %struct.U1A* %a, i32 0, i32 0
   // CHECK: call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([11 x i8], [11 x i8]* [[FIELD_U1]], i32 0, i32 0))
   // CHECK: [[LOAD1:%[0-9]+]] = load i16, i16* [[RES1]],
   // CHECK: call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([5 x i8], [5 x i8]* [[FORMAT_U1]], i32 0, i32 0), i16 [[LOAD1]])
@@ -144,7 +144,7 @@
   };
 
   // CHECK: call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([14 x i8], [14 x i8]* [[STRUCT_STR_U2]], i32 0, i32 0))
-  // CHECK: [[RES1:%[0-9]+]] = getelementptr inbounds %struct.U2A, %struct.U2A* %a, i32 0, i32 0
+  // CHECK: [[RES1:%[−a−zA−Z._0-9]+]] = getelementptr inbounds %struct.U2A, %struct.U2A* %a, i32 0, i32 0
   // CHECK: call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([20 x i8], [20 x i8]* [[FIELD_U2]], i32 0, i32 0))
   // CHECK: [[LOAD1:%[0-9]+]] = load i16, i16* [[RES1]],
   // CHECK: call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([5 x i8], [5 x i8]* [[FORMAT_U2]], i32 0, i32 0), i16 [[LOAD1]])
@@ -162,7 +162,7 @@
   };
 
   // CHECK: call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([14 x i8], [14 x i8]* [[STRUCT_STR_U3]], i32 0, i32 0))
-  // CHECK: [[RES1:%[0-9]+]] = getelementptr inbounds %struct.U3A, %struct.U3A* %a, i32 0, i32 0
+  // CHECK: [[RES1:%[−a−zA−Z._0-9]+]] = getelementptr inbounds %struct.U3A, %struct.U3A* %a, i32 0, i32 0
   // CHECK: call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([9 x i8], [9 x i8]* [[FIELD_U3]], i32 0, i32 0))
   // CHECK: [[LOAD1:%[0-9]+]] = load i32, i32* [[RES1]],
   // CHECK: call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([4 x i8], [4 x i8]* [[FORMAT_U3]], i32 0, i32 0), i32 [[LOAD1]])
@@ -180,7 +180,7 @@
   };
 
   // CHECK: call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([14 x i8], [14 x i8]* [[STRUCT_STR_U4]], i32 0, i32 0))
-  // CHECK: [[RES1:%[0-9]+]] = getelementptr inbounds %struct.U4A, %struct.U4A* %a, i32 0, i32 0
+  // CHECK: [[RES1:%[−a−zA−Z._0-9]+]] = getelementptr inbounds %struct.U4A, %struct.U4A* %a, i32 0, i32 0
   // CHECK: call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([18 x i8], [18 x i8]* [[FIELD_U4]], i32 0, i32 0))
   // CHECK: [[LOAD1:%[0-9]+]] = load i32, i32* [[RES1]],
   // CHECK: call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([4 x i8], [4 x i8]* [[FORMAT_U4]], i32 0, i32 0), i32 [[LOAD1]])
@@ -198,7 +198,7 @@
   };
 
   // CHECK: call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([14 x i8], [14 x i8]* [[STRUCT_STR_U5]], i32 0, i32 0))
-  // CHECK: [[RES1:%[0-9]+]] = getelementptr inbounds %struct.U5A, %struct.U5A* %a, i32 0, i32 0
+  // CHECK: [[RES1:%[−a−zA−Z._0-9]+]] = getelementptr inbounds %struct.U5A, %struct.U5A* %a, i32 0, i32 0
   // CHECK: call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([10 x i8], [10 x i8]* [[FIELD_U5]], i32 0, i32 0))
   // CHECK: [[LOAD1:%[0-9]+]] = load i64, i64* [[RES1]],
   // CHECK: call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([5 x i8], [5 x i8]* [[FORMAT_U5]], i32 0, i32 0), i64 [[LOAD1]])
@@ -216,7 +216,7 @@
   };
 
   // CHECK: call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([14 x i8], [14 x i8]* [[STRUCT_STR_U6]], i32 0, i32 0))
-  // CHECK: [[RES1:%[0-9]+]] = getelementptr inbounds %struct.U6A, %struct.U6A* %a, i32 0, i32 0
+  // CHECK: [[RES1:%[−a−zA−Z._0-9]+]] = getelementptr inbounds %struct.U6A, %struct.U6A* %a, i32 0, i32 0
   // CHECK: call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([19 x i8], [19 x i8]* [[FIELD_U6]], i32 0, i32 0))
   // CHECK: [[LOAD1:%[0-9]+]] = load i64, i64* 

[PATCH] D122087: Add HLSL Language Option and Preprocessor

2022-03-23 Thread Chris Bieneman via Phabricator via cfe-commits
beanz added inline comments.



Comment at: clang/lib/Frontend/InitPreprocessor.cpp:401-403
+uint32_t StageInteger = StageInteger =
+(uint32_t)TI.getTriple().getEnvironment() -
+(uint32_t)llvm::Triple::Pixel;

rnk wrote:
> This here suggests that the order of the HLSL environments in the triple 
> really, really matter, since we expose them to users. That's really 
> surprising: it means small changes in LLVM affect this pre-processor macro in 
> surprising ways. I see the test for this, but what do you think about adding 
> a static_assert to Triple.cpp to move the check into LLVM? Something like:
>   static_assert(Triple::Compute - Triple::Pixel == 1, "incorrect HLSL env 
> order");
>   static_assert(Triple::Amplification - Triple::Pixel == 2, "incorrect HLSL 
> env order");
> 
> Maybe this is addressed elsewhere, I haven't looked at all patches 
> holistically.
This is more or less verified by the test case checking the preprocessor 
values, but static_asserts would provide a more clear error, so I'll add some.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122087

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


[PATCH] D121927: [Clang] Work with multiple pragmas weak before definition

2022-03-23 Thread Hubert Tong via Phabricator via cfe-commits
hubert.reinterpretcast added inline comments.



Comment at: clang/include/clang/Sema/Weak.h:47
+static unsigned getHashValue(const WeakInfo ) {
+  return W.getAlias() ? DenseMapInfo::getHashValue(W.getAlias()->getName())
+  : DenseMapInfo::getHashValue("");

The fact that `WeakUndeclaredIdentifiers` is keyed by `IdentifierInfo *` must 
mean that it is safe to use pointer comparison. This is further bolstered by 
`IdentifierInfo` having only private or deleted constructors (with 
`IdentifierTable` being a friend class).

I will adjust to make this class simply forward to `DenseMapInfo` with the alias members.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121927

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


[PATCH] D120185: [ASTMatchers] Output currently processing match and nodes on crash

2022-03-23 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D120185#3403230 , @njames93 wrote:

> In D120185#3397508 , @thakis wrote:
>
>> Looks like this breaks tests on Windows: 
>> http://45.33.8.238/win/54785/step_7.txt
>>
>> Please take a look, and revert for now if takes a while to fix.
>
> I can't seem to reproduce the test failure on windows, are you opposed to 
> relanding this with the test disabled on windows?

I'd like to understand what's happening better rather than land with a disabled 
test. Not getting the crash dump in some circumstances could either be specific 
to the machine configuration (which would be pretty tricky for us to solve in a 
unit test) or it could be something functionally wrong with the changes (though 
I would be surprised, tbh).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120185

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


[PATCH] D122335: [clang] Emit crash reproduction as a single tar file

2022-03-23 Thread Alex Brachet via Phabricator via cfe-commits
abrachet added a comment.

In D122335#3403281 , 
@hubert.reinterpretcast wrote:

> For users on Windows, would this cause extra trouble if they wanted to see 
> what was included?

Is `tar(1)` not available on Windows?


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

https://reviews.llvm.org/D122335

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


[PATCH] D122248: [clang][CodeGen]Fix clang crash and add bitfield support in __builtin_dump_struct

2022-03-23 Thread Wang Yihan via Phabricator via cfe-commits
yihanaa added a comment.

In D122248#3402924 , @erichkeane 
wrote:

> Seems reasonable to me.  Obviously needs release notes + the tests that Aaron 
> did, but I think this looks right.

Thank you for reminding,i have add a release notes entry and a test case for 
zero-width bitfield & unnamed bitfield.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122248

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


[PATCH] D121927: [Clang] Work with multiple pragmas weak before definition

2022-03-23 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/include/clang/Sema/Weak.h:47
+static unsigned getHashValue(const WeakInfo ) {
+  return W.getAlias() ? DenseMapInfo::getHashValue(W.getAlias()->getName())
+  : DenseMapInfo::getHashValue("");

hubert.reinterpretcast wrote:
> The fact that `WeakUndeclaredIdentifiers` is keyed by `IdentifierInfo *` must 
> mean that it is safe to use pointer comparison. This is further bolstered by 
> `IdentifierInfo` having only private or deleted constructors (with 
> `IdentifierTable` being a friend class).
> 
> I will adjust to make this class simply forward to `DenseMapInfo IdentifierInfo *>` with the alias members.
SGTM!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121927

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


[PATCH] D122335: [clang] Emit crash reproduction as a single tar file

2022-03-23 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added a comment.

In D122335#3403305 , @aaron.ballman 
wrote:

> In D122335#3403283 , @abrachet 
> wrote:
>
>> In D122335#3403281 , 
>> @hubert.reinterpretcast wrote:
>>
>>> For users on Windows, would this cause extra trouble if they wanted to see 
>>> what was included?
>>
>> Is `tar(1)` not available on Windows?
>
> It's available on Windows 10 and later by default, but otherwise .zip is the 
> native archive format on Windows.

We DO support older versions of Windows (Windows Server 2003 is still quite 
popular!), so presumably this requirement wouldn't be particularly acceptable.


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

https://reviews.llvm.org/D122335

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


[PATCH] D122248: [clang][CodeGen]Fix clang crash and add bitfield support in __builtin_dump_struct

2022-03-23 Thread Wang Yihan via Phabricator via cfe-commits
yihanaa added a comment.

In D122248#3403349 , @erichkeane 
wrote:

> In D122248#3403343 , @yihanaa wrote:
>
>> In D122248#3403315 , 
>> @aaron.ballman wrote:
>>
>>> In D122248#3403143 , @yihanaa 
>>> wrote:
>>>
 1. Support zero-width bitfield, named bitfield and unnamed bitfield.
 2. Add a release notes.

 The builtin function __builtin_dump_struct behaves for zero-width bitfield 
 and unnamed bitfield as follows

   int printf(const char *fmt, ...);
   
   void foo(void) {
 struct Bar {
   unsigned c : 1;
   unsigned : 3;
   unsigned : 0;
   unsigned b;
 };
   
 struct Bar a = {
   .c = 1,
   .b = 2022,
 };
   
 __builtin_dump_struct(, );
   }
   
   int main() {
 foo();
 return 0;
   }

 Output:

   struct Bar {
   unsigned int c : 1
   unsigned int  : 0
   unsigned int b : 2022
   }
>>>
>>> Thank you for the release note and additional test coverage. I'm wondering 
>>> why we handle the zero-width bit-field differently from the anonymous one 
>>> (e.g., why do we not have `unsigned int : 3` before the `unsigned int : 0`? 
>>> It seems a bit odd to drop that from the output.
>>
>> Thanks, I don't know what the value of this zero-width bitfield should 
>> output, can it be a empty value as same as unnamed-bitfield’ she field name?
>>
>> for example:
>>
>>   struct Bar {
>>   unsigned int c : 1
>>   unsigned int  : 0
>>   unsigned int  :
>>   unsigned int b : 2022
>>   }
>
> I would definitely expect this, yes.

I will try to modify it according to this rule.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122248

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


[PATCH] D122175: [clang][extract-api] Enable processing of multiple headers

2022-03-23 Thread Daniel Grumberg via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
dang marked an inline comment as done.
Closed by commit rGf833aab0d0bf: [clang][extract-api] Enable processing of 
multiple headers (authored by dang).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122175

Files:
  clang/include/clang/ExtractAPI/FrontendActions.h
  clang/lib/ExtractAPI/ExtractAPIConsumer.cpp
  clang/test/ExtractAPI/global_record_multifile.c

Index: clang/test/ExtractAPI/global_record_multifile.c
===
--- /dev/null
+++ clang/test/ExtractAPI/global_record_multifile.c
@@ -0,0 +1,371 @@
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+// RUN: sed -e "s@INPUT_DIR@%/t@g" %t/reference.output.json.in >> \
+// RUN: %t/reference.output.json
+// RUN: %clang -extract-api --product-name=GlobalRecord -target arm64-apple-macosx \
+// RUN: %t/input1.h %t/input2.h %t/input3.h -o %t/output.json | FileCheck -allow-empty %s
+
+// Generator version is not consistent across test runs, normalize it.
+// RUN: sed -e "s@\"generator\": \".*\"@\"generator\": \"?\"@g" \
+// RUN: %t/output.json >> %t/output-normalized.json
+// RUN: diff %t/reference.output.json %t/output-normalized.json
+
+// CHECK-NOT: error:
+// CHECK-NOT: warning:
+
+//--- input1.h
+int num;
+
+//--- input2.h
+/**
+ * \brief Add two numbers.
+ * \param [in]  x   A number.
+ * \param [in]  y   Another number.
+ * \param [out] res The result of x + y.
+ */
+void add(const int x, const int y, int *res);
+
+//--- input3.h
+char unavailable __attribute__((unavailable));
+
+//--- reference.output.json.in
+{
+  "metadata": {
+"formatVersion": {
+  "major": 0,
+  "minor": 5,
+  "patch": 3
+},
+"generator": "?"
+  },
+  "module": {
+"name": "GlobalRecord",
+"platform": {
+  "architecture": "arm64",
+  "operatingSystem": {
+"minimumVersion": {
+  "major": 11,
+  "minor": 0,
+  "patch": 0
+},
+"name": "macosx"
+  },
+  "vendor": "apple"
+}
+  },
+  "relationhips": [],
+  "symbols": [
+{
+  "declarationFragments": [
+{
+  "kind": "typeIdentifier",
+  "preciseIdentifier": "c:I",
+  "spelling": "int"
+},
+{
+  "kind": "text",
+  "spelling": " "
+},
+{
+  "kind": "identifier",
+  "spelling": "num"
+}
+  ],
+  "identifier": {
+"interfaceLanguage": "c",
+"precise": "c:@num"
+  },
+  "kind": {
+"displayName": "Global Variable",
+"identifier": "c.var"
+  },
+  "location": {
+"character": 5,
+"line": 1,
+"uri": "file://INPUT_DIR/input1.h"
+  },
+  "names": {
+"subHeading": [
+  {
+"kind": "identifier",
+"spelling": "num"
+  }
+],
+"title": "num"
+  }
+},
+{
+  "declarationFragments": [
+{
+  "kind": "typeIdentifier",
+  "preciseIdentifier": "c:v",
+  "spelling": "void"
+},
+{
+  "kind": "text",
+  "spelling": " "
+},
+{
+  "kind": "identifier",
+  "spelling": "add"
+},
+{
+  "kind": "text",
+  "spelling": "("
+},
+{
+  "kind": "keyword",
+  "spelling": "const"
+},
+{
+  "kind": "text",
+  "spelling": " "
+},
+{
+  "kind": "typeIdentifier",
+  "preciseIdentifier": "c:I",
+  "spelling": "int"
+},
+{
+  "kind": "text",
+  "spelling": " "
+},
+{
+  "kind": "internalParam",
+  "spelling": "x"
+},
+{
+  "kind": "text",
+  "spelling": ", "
+},
+{
+  "kind": "keyword",
+  "spelling": "const"
+},
+{
+  "kind": "text",
+  "spelling": " "
+},
+{
+  "kind": "typeIdentifier",
+  "preciseIdentifier": "c:I",
+  "spelling": "int"
+},
+{
+  "kind": "text",
+  "spelling": " "
+},
+{
+  "kind": "internalParam",
+  "spelling": "y"
+},
+{
+  "kind": "text",
+  "spelling": ", "
+},
+{
+  "kind": "typeIdentifier",
+  "preciseIdentifier": "c:I",
+  "spelling": "int"
+},
+{
+  "kind": "text",
+  "spelling": " *"
+},
+{
+  "kind": "internalParam",
+  "spelling": "res"
+},
+{
+  "kind": "text",
+  "spelling": ")"
+}
+  ],
+  "docComment": {
+"lines": [
+  {
+"range": {
+  "end": {
+

[PATCH] D122089: [CUDA] Add getTargetFeatures for the NVPTX toolchain

2022-03-23 Thread Joseph Huber via Phabricator via cfe-commits
jhuber6 added inline comments.



Comment at: clang/lib/Driver/ToolChains/Cuda.cpp:648
+#define CASE_CUDA_VERSION(CUDA_VER, PTX_VER)   
\
+  case CudaVersion::CUDA_##CUDA_VER:   
\
+PtxFeature = "+ptx" #PTX_VER;  
\

zixuan-wu wrote:
> It's same name as `CudaVersion` variable above, and it cause compile error. 
> @jhuber6 
> Maybe the error depends on host compiler version so that it does not report 
> immediately.
Fixed in rGd91223274145. Thanks for pointing that out, it worked fined locally.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122089

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


[PATCH] D122285: [analyzer] Add path note tags to standard library function summaries.

2022-03-23 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ planned changes to this revision.
NoQ added a comment.

Ok there's actually a huge bug in this patch, namely we can't say "Assuming..." 
if there's no state split (i.e., when we know from the start which branch is 
taken so we don't have to assume). I'll fix.

In D122285#3401754 , @steakhal wrote:

>> The notes are prunable, i.e. they won't bring-in entire stack frames worth 
>> of notes just because they're there, but they will be always visible 
>> regardless of whether the value is of interest to the bug report. I think 
>> this is debatable, the arguably better solution is to make them non-prunable 
>> but conditional to the value being tracked back to the call, which would 
>> probably need a better tracking infrastructure.
>
> I was thinking of passing a lambda and doing the rest there. We could have 
> lambda factories to make it less cumbersome to define - and also reuse code.

Yes sure, that's exactly how note tags are designed to work, but that lambda 
still needs to know whether the value is tracked. I guess I'll take a look at 
how well interestingness performs in these examples, maybe it's worth having 
from the start.


Repository:
  rC Clang

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

https://reviews.llvm.org/D122285

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


[PATCH] D122370: Split up large test files under clang/test/CodeGen/RISCV

2022-03-23 Thread Brandon Wu via Phabricator via cfe-commits
4vtomat added a comment.

In D122370#3404590 , @MaskRay wrote:

> I assume this is to improve test parallelism. Do you have runtime comparison?

actually, this is to prevent single file from timeout due to many test cases, 
such as https://reviews.llvm.org/D122205#3403925


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122370

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


[PATCH] D120397: [C++20] [Modules] Make the linkage consistent for template and its specialization

2022-03-23 Thread Chuanqi Xu via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG847466860887: [C++20] [Modules] Make the linkage consistent 
for template and its (authored by ChuanqiXu).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120397

Files:
  clang/lib/AST/Decl.cpp
  clang/unittests/AST/DeclTest.cpp


Index: clang/unittests/AST/DeclTest.cpp
===
--- clang/unittests/AST/DeclTest.cpp
+++ clang/unittests/AST/DeclTest.cpp
@@ -171,3 +171,26 @@
   selectFirst("f", match(functionDecl().bind("f"), Ctx));
   EXPECT_TRUE(f->isInExportDeclContext());
 }
+
+TEST(Decl, InConsistLinkageForTemplates) {
+  llvm::Annotations Code(R"(
+export module m;
+export template 
+void f() {}
+
+template <>
+void f() {})");
+
+  auto AST =
+  tooling::buildASTFromCodeWithArgs(Code.code(), /*Args=*/{"-std=c++20"});
+  ASTContext  = AST->getASTContext();
+
+  llvm::SmallVector Funcs =
+  match(functionDecl().bind("f"), Ctx);
+
+  EXPECT_EQ(Funcs.size(), 2);
+  const FunctionDecl *TemplateF = Funcs[0].getNodeAs("f");
+  const FunctionDecl *SpecializedF = Funcs[1].getNodeAs("f");
+  EXPECT_EQ(TemplateF->getLinkageInternal(),
+SpecializedF->getLinkageInternal());
+}
Index: clang/lib/AST/Decl.cpp
===
--- clang/lib/AST/Decl.cpp
+++ clang/lib/AST/Decl.cpp
@@ -391,11 +391,18 @@
   bool considerVisibility =
 shouldConsiderTemplateVisibility(fn, specInfo);
 
-  // Merge information from the template parameters.
   FunctionTemplateDecl *temp = specInfo->getTemplate();
-  LinkageInfo tempLV =
-getLVForTemplateParameterList(temp->getTemplateParameters(), computation);
-  LV.mergeMaybeWithVisibility(tempLV, considerVisibility);
+
+  // Merge information from the template declaration.
+  LinkageInfo tempLV = getLVForDecl(temp, computation);
+  // The linkage of the specialization should be consistent with the
+  // template declaration.
+  LV.setLinkage(tempLV.getLinkage());
+
+  // Merge information from the template parameters.
+  LinkageInfo paramsLV =
+  getLVForTemplateParameterList(temp->getTemplateParameters(), 
computation);
+  LV.mergeMaybeWithVisibility(paramsLV, considerVisibility);
 
   // Merge information from the template arguments.
   const TemplateArgumentList  = *specInfo->TemplateArguments;


Index: clang/unittests/AST/DeclTest.cpp
===
--- clang/unittests/AST/DeclTest.cpp
+++ clang/unittests/AST/DeclTest.cpp
@@ -171,3 +171,26 @@
   selectFirst("f", match(functionDecl().bind("f"), Ctx));
   EXPECT_TRUE(f->isInExportDeclContext());
 }
+
+TEST(Decl, InConsistLinkageForTemplates) {
+  llvm::Annotations Code(R"(
+export module m;
+export template 
+void f() {}
+
+template <>
+void f() {})");
+
+  auto AST =
+  tooling::buildASTFromCodeWithArgs(Code.code(), /*Args=*/{"-std=c++20"});
+  ASTContext  = AST->getASTContext();
+
+  llvm::SmallVector Funcs =
+  match(functionDecl().bind("f"), Ctx);
+
+  EXPECT_EQ(Funcs.size(), 2);
+  const FunctionDecl *TemplateF = Funcs[0].getNodeAs("f");
+  const FunctionDecl *SpecializedF = Funcs[1].getNodeAs("f");
+  EXPECT_EQ(TemplateF->getLinkageInternal(),
+SpecializedF->getLinkageInternal());
+}
Index: clang/lib/AST/Decl.cpp
===
--- clang/lib/AST/Decl.cpp
+++ clang/lib/AST/Decl.cpp
@@ -391,11 +391,18 @@
   bool considerVisibility =
 shouldConsiderTemplateVisibility(fn, specInfo);
 
-  // Merge information from the template parameters.
   FunctionTemplateDecl *temp = specInfo->getTemplate();
-  LinkageInfo tempLV =
-getLVForTemplateParameterList(temp->getTemplateParameters(), computation);
-  LV.mergeMaybeWithVisibility(tempLV, considerVisibility);
+
+  // Merge information from the template declaration.
+  LinkageInfo tempLV = getLVForDecl(temp, computation);
+  // The linkage of the specialization should be consistent with the
+  // template declaration.
+  LV.setLinkage(tempLV.getLinkage());
+
+  // Merge information from the template parameters.
+  LinkageInfo paramsLV =
+  getLVForTemplateParameterList(temp->getTemplateParameters(), computation);
+  LV.mergeMaybeWithVisibility(paramsLV, considerVisibility);
 
   // Merge information from the template arguments.
   const TemplateArgumentList  = *specInfo->TemplateArguments;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 8474668 - [C++20] [Modules] Make the linkage consistent for template and its

2022-03-23 Thread Chuanqi Xu via cfe-commits

Author: Chuanqi Xu
Date: 2022-03-24T10:24:14+08:00
New Revision: 84746686088799ec9e3cc5ea0a64df81423da290

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

LOG: [C++20] [Modules] Make the linkage consistent for template and its
specialization

Before the patch, the compiler would crash for the test due to
inconsistent linkage.

This patch tries to avoid it by make the linkage consistent for template
and its specialization. After the patch, the behavior of compiler would
be partially correct for the case.
The correct one is:

```
export template
void f() {}

template<>
void f() {}
```

In this case, the linkage for both declaration should be external (the
wording I get by consulting in WG21 is "the linkage for name f should be
external").

And for the case:
```
template
void f() {}

export template<>
void f() {}
```

Compiler should reject it. This isn't done now. After all, this patch would
stop a crash.

Reviewed By: iains, aaron.ballman, dblaikie

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

Added: 


Modified: 
clang/lib/AST/Decl.cpp
clang/unittests/AST/DeclTest.cpp

Removed: 




diff  --git a/clang/lib/AST/Decl.cpp b/clang/lib/AST/Decl.cpp
index cc5eca86abb19..6b68e511a932b 100644
--- a/clang/lib/AST/Decl.cpp
+++ b/clang/lib/AST/Decl.cpp
@@ -391,11 +391,18 @@ void LinkageComputer::mergeTemplateLV(
   bool considerVisibility =
 shouldConsiderTemplateVisibility(fn, specInfo);
 
-  // Merge information from the template parameters.
   FunctionTemplateDecl *temp = specInfo->getTemplate();
-  LinkageInfo tempLV =
-getLVForTemplateParameterList(temp->getTemplateParameters(), computation);
-  LV.mergeMaybeWithVisibility(tempLV, considerVisibility);
+
+  // Merge information from the template declaration.
+  LinkageInfo tempLV = getLVForDecl(temp, computation);
+  // The linkage of the specialization should be consistent with the
+  // template declaration.
+  LV.setLinkage(tempLV.getLinkage());
+
+  // Merge information from the template parameters.
+  LinkageInfo paramsLV =
+  getLVForTemplateParameterList(temp->getTemplateParameters(), 
computation);
+  LV.mergeMaybeWithVisibility(paramsLV, considerVisibility);
 
   // Merge information from the template arguments.
   const TemplateArgumentList  = *specInfo->TemplateArguments;

diff  --git a/clang/unittests/AST/DeclTest.cpp 
b/clang/unittests/AST/DeclTest.cpp
index a84ebbd9835db..bf2826c7b329f 100644
--- a/clang/unittests/AST/DeclTest.cpp
+++ b/clang/unittests/AST/DeclTest.cpp
@@ -171,3 +171,26 @@ TEST(Decl, IsInExportDeclContext) {
   selectFirst("f", match(functionDecl().bind("f"), Ctx));
   EXPECT_TRUE(f->isInExportDeclContext());
 }
+
+TEST(Decl, InConsistLinkageForTemplates) {
+  llvm::Annotations Code(R"(
+export module m;
+export template 
+void f() {}
+
+template <>
+void f() {})");
+
+  auto AST =
+  tooling::buildASTFromCodeWithArgs(Code.code(), /*Args=*/{"-std=c++20"});
+  ASTContext  = AST->getASTContext();
+
+  llvm::SmallVector Funcs =
+  match(functionDecl().bind("f"), Ctx);
+
+  EXPECT_EQ(Funcs.size(), 2);
+  const FunctionDecl *TemplateF = Funcs[0].getNodeAs("f");
+  const FunctionDecl *SpecializedF = Funcs[1].getNodeAs("f");
+  EXPECT_EQ(TemplateF->getLinkageInternal(),
+SpecializedF->getLinkageInternal());
+}



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


[clang] d912232 - [CUDA][FIX] Fix name conflict in getNVPTXTargetFeatures

2022-03-23 Thread Joseph Huber via cfe-commits

Author: Joseph Huber
Date: 2022-03-23T23:07:51-04:00
New Revision: d91223274145a0c33ab01641902650b249921a43

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

LOG: [CUDA][FIX] Fix name conflict in getNVPTXTargetFeatures

Summary:
There was a naming conflict in the getNVPTXTargetFeatures function that
prevented some compilers from correctly disambiguating between the
enumeration and variable of the same name. Rename the variable to avoid
this.

Added: 


Modified: 
clang/lib/Driver/ToolChains/Cuda.cpp
clang/lib/Driver/ToolChains/Cuda.h

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Cuda.cpp 
b/clang/lib/Driver/ToolChains/Cuda.cpp
index b162cec8a27c3..f8a06a2e09ab7 100644
--- a/clang/lib/Driver/ToolChains/Cuda.cpp
+++ b/clang/lib/Driver/ToolChains/Cuda.cpp
@@ -633,17 +633,17 @@ void NVPTX::OpenMPLinker::ConstructJob(Compilation , 
const JobAction ,
 void NVPTX::getNVPTXTargetFeatures(const Driver , const llvm::Triple ,
const llvm::opt::ArgList ,
std::vector ,
-   Optional CudaVersion) {
-  if (!CudaVersion) {
+   Optional Version) {
+  if (!Version) {
 CudaInstallationDetector CudaInstallation(D, Triple, Args);
-CudaVersion = CudaInstallation.version();
+Version = CudaInstallation.version();
   }
 
   // New CUDA versions often introduce new instructions that are only supported
   // by new PTX version, so we need to raise PTX level to enable them in NVPTX
   // back-end.
   const char *PtxFeature = nullptr;
-  switch (*CudaVersion) {
+  switch (*Version) {
 #define CASE_CUDA_VERSION(CUDA_VER, PTX_VER)   
\
   case CudaVersion::CUDA_##CUDA_VER:   
\
 PtxFeature = "+ptx" #PTX_VER;  
\

diff  --git a/clang/lib/Driver/ToolChains/Cuda.h 
b/clang/lib/Driver/ToolChains/Cuda.h
index f4f924ff8a684..f2517a9b38d1e 100644
--- a/clang/lib/Driver/ToolChains/Cuda.h
+++ b/clang/lib/Driver/ToolChains/Cuda.h
@@ -127,7 +127,7 @@ class LLVM_LIBRARY_VISIBILITY OpenMPLinker : public Tool {
 void getNVPTXTargetFeatures(const Driver , const llvm::Triple ,
 const llvm::opt::ArgList ,
 std::vector ,
-Optional CudaVersion = None);
+Optional Version = None);
 
 } // end namespace NVPTX
 } // end namespace tools



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


[clang] f74413d - [clang-format] Fix invalid code generation with comments in lambda

2022-03-23 Thread via cfe-commits

Author: owenca
Date: 2022-03-23T19:40:24-07:00
New Revision: f74413d16345c8815c7d1e4676d6aaf732517b8d

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

LOG: [clang-format] Fix invalid code generation with comments in lambda

Fixes #51234 and #54496

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

Added: 


Modified: 
clang/lib/Format/TokenAnnotator.cpp
clang/unittests/Format/FormatTest.cpp

Removed: 




diff  --git a/clang/lib/Format/TokenAnnotator.cpp 
b/clang/lib/Format/TokenAnnotator.cpp
index a6ca459a53337..c657d80ba0d5f 100644
--- a/clang/lib/Format/TokenAnnotator.cpp
+++ b/clang/lib/Format/TokenAnnotator.cpp
@@ -2762,12 +2762,16 @@ void 
TokenAnnotator::calculateFormattingInformation(AnnotatedLine ) {
   Current->SpacesRequiredBefore = 1;
 }
 
-Current->MustBreakBefore =
-Current->MustBreakBefore || mustBreakBefore(Line, *Current);
-
-if (!Current->MustBreakBefore && InFunctionDecl &&
-Current->is(TT_FunctionDeclarationName))
-  Current->MustBreakBefore = mustBreakForReturnType(Line);
+const auto  = Prev->Children;
+if (!Children.empty() && Children.back()->Last->is(TT_LineComment)) {
+  Current->MustBreakBefore = true;
+} else {
+  Current->MustBreakBefore =
+  Current->MustBreakBefore || mustBreakBefore(Line, *Current);
+  if (!Current->MustBreakBefore && InFunctionDecl &&
+  Current->is(TT_FunctionDeclarationName))
+Current->MustBreakBefore = mustBreakForReturnType(Line);
+}
 
 Current->CanBreakBefore =
 Current->MustBreakBefore || canBreakBefore(Line, *Current);

diff  --git a/clang/unittests/Format/FormatTest.cpp 
b/clang/unittests/Format/FormatTest.cpp
index e36a267c01f4b..e837dbd566957 100644
--- a/clang/unittests/Format/FormatTest.cpp
+++ b/clang/unittests/Format/FormatTest.cpp
@@ -21934,6 +21934,30 @@ TEST_F(FormatTest, LambdaWithLineComments) {
   "auto k = []() // \n"
   "{ return; }",
   LLVMWithBeforeLambdaBody);
+
+  LLVMWithBeforeLambdaBody.ColumnLimit = 0;
+
+  verifyFormat("foo([]()\n"
+   "{\n"
+   "  bar();//\n"
+   "  return 1; // comment\n"
+   "}());",
+   "foo([]() {\n"
+   "  bar(); //\n"
+   "  return 1; // comment\n"
+   "}());",
+   LLVMWithBeforeLambdaBody);
+  verifyFormat("foo(\n"
+   "1, MACRO {\n"
+   "  baz();\n"
+   "  bar(); // comment\n"
+   "},\n"
+   "[]() {});",
+   "foo(\n"
+   "  1, MACRO { baz(); bar(); // comment\n"
+   "  }, []() {}\n"
+   ");",
+   LLVMWithBeforeLambdaBody);
 }
 
 TEST_F(FormatTest, EmptyLinesInLambdas) {



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


[PATCH] D122301: [clang-format] Fix invalid code generation with comments in lambda

2022-03-23 Thread Owen Pan via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGf74413d16345: [clang-format] Fix invalid code generation 
with comments in lambda (authored by owenpan).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122301

Files:
  clang/lib/Format/TokenAnnotator.cpp
  clang/unittests/Format/FormatTest.cpp


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -21934,6 +21934,30 @@
   "auto k = []() // \n"
   "{ return; }",
   LLVMWithBeforeLambdaBody);
+
+  LLVMWithBeforeLambdaBody.ColumnLimit = 0;
+
+  verifyFormat("foo([]()\n"
+   "{\n"
+   "  bar();//\n"
+   "  return 1; // comment\n"
+   "}());",
+   "foo([]() {\n"
+   "  bar(); //\n"
+   "  return 1; // comment\n"
+   "}());",
+   LLVMWithBeforeLambdaBody);
+  verifyFormat("foo(\n"
+   "1, MACRO {\n"
+   "  baz();\n"
+   "  bar(); // comment\n"
+   "},\n"
+   "[]() {});",
+   "foo(\n"
+   "  1, MACRO { baz(); bar(); // comment\n"
+   "  }, []() {}\n"
+   ");",
+   LLVMWithBeforeLambdaBody);
 }
 
 TEST_F(FormatTest, EmptyLinesInLambdas) {
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -2762,12 +2762,16 @@
   Current->SpacesRequiredBefore = 1;
 }
 
-Current->MustBreakBefore =
-Current->MustBreakBefore || mustBreakBefore(Line, *Current);
-
-if (!Current->MustBreakBefore && InFunctionDecl &&
-Current->is(TT_FunctionDeclarationName))
-  Current->MustBreakBefore = mustBreakForReturnType(Line);
+const auto  = Prev->Children;
+if (!Children.empty() && Children.back()->Last->is(TT_LineComment)) {
+  Current->MustBreakBefore = true;
+} else {
+  Current->MustBreakBefore =
+  Current->MustBreakBefore || mustBreakBefore(Line, *Current);
+  if (!Current->MustBreakBefore && InFunctionDecl &&
+  Current->is(TT_FunctionDeclarationName))
+Current->MustBreakBefore = mustBreakForReturnType(Line);
+}
 
 Current->CanBreakBefore =
 Current->MustBreakBefore || canBreakBefore(Line, *Current);


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -21934,6 +21934,30 @@
   "auto k = []() // \n"
   "{ return; }",
   LLVMWithBeforeLambdaBody);
+
+  LLVMWithBeforeLambdaBody.ColumnLimit = 0;
+
+  verifyFormat("foo([]()\n"
+   "{\n"
+   "  bar();//\n"
+   "  return 1; // comment\n"
+   "}());",
+   "foo([]() {\n"
+   "  bar(); //\n"
+   "  return 1; // comment\n"
+   "}());",
+   LLVMWithBeforeLambdaBody);
+  verifyFormat("foo(\n"
+   "1, MACRO {\n"
+   "  baz();\n"
+   "  bar(); // comment\n"
+   "},\n"
+   "[]() {});",
+   "foo(\n"
+   "  1, MACRO { baz(); bar(); // comment\n"
+   "  }, []() {}\n"
+   ");",
+   LLVMWithBeforeLambdaBody);
 }
 
 TEST_F(FormatTest, EmptyLinesInLambdas) {
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -2762,12 +2762,16 @@
   Current->SpacesRequiredBefore = 1;
 }
 
-Current->MustBreakBefore =
-Current->MustBreakBefore || mustBreakBefore(Line, *Current);
-
-if (!Current->MustBreakBefore && InFunctionDecl &&
-Current->is(TT_FunctionDeclarationName))
-  Current->MustBreakBefore = mustBreakForReturnType(Line);
+const auto  = Prev->Children;
+if (!Children.empty() && Children.back()->Last->is(TT_LineComment)) {
+  Current->MustBreakBefore = true;
+} else {
+  Current->MustBreakBefore =
+  Current->MustBreakBefore || mustBreakBefore(Line, *Current);
+  if (!Current->MustBreakBefore && InFunctionDecl &&
+  Current->is(TT_FunctionDeclarationName))
+Current->MustBreakBefore = mustBreakForReturnType(Line);
+}
 
 Current->CanBreakBefore =
 Current->MustBreakBefore || canBreakBefore(Line, *Current);

[PATCH] D122160: [clang][extract-api] Refactor ExtractAPI and improve docs

2022-03-23 Thread Zixuan Wu via Phabricator via cfe-commits
zixuan-wu added inline comments.



Comment at: clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp:159
+  switch (Language) {
+  case Language::C:
+return "c";

It's same name as `Language` variable above, and it cause compile error. @zixuw 
Maybe the error depends on host compiler version so that it does not report 
immediately.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122160

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


[PATCH] D122089: [CUDA] Add getTargetFeatures for the NVPTX toolchain

2022-03-23 Thread Zixuan Wu via Phabricator via cfe-commits
zixuan-wu added inline comments.



Comment at: clang/lib/Driver/ToolChains/Cuda.cpp:648
+#define CASE_CUDA_VERSION(CUDA_VER, PTX_VER)   
\
+  case CudaVersion::CUDA_##CUDA_VER:   
\
+PtxFeature = "+ptx" #PTX_VER;  
\

jhuber6 wrote:
> zixuan-wu wrote:
> > It's same name as `CudaVersion` variable above, and it cause compile error. 
> > @jhuber6 
> > Maybe the error depends on host compiler version so that it does not report 
> > immediately.
> Fixed in rGd91223274145. Thanks for pointing that out, it worked fined 
> locally.
Thank you for your quick action.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122089

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


[PATCH] D122370: Split up large test files under clang/test/CodeGen/RISCV

2022-03-23 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added a comment.

I assume this is to improve test parallelism. Do you have runtime comparison?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122370

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


[PATCH] D120449: [RISCV][RVV] Add strict vfcvt intrinsics that have side effects for dynamically-set rounding mode

2022-03-23 Thread ShihPo Hung via Phabricator via cfe-commits
arcbbb planned changes to this revision.
arcbbb added a comment.
Herald added a subscriber: StephenFan.

I started a discussion on how RVV clang builtins interact with FENV_ACCESS in 
https://github.com/riscv-non-isa/rvv-intrinsic-doc/issues/147
I would drop this patch if those builtins are going to be independent of FENV.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120449

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


[PATCH] D122370: Split up large test files under clang/test/CodeGen/RISCV

2022-03-23 Thread Brandon Wu via Phabricator via cfe-commits
4vtomat created this revision.
Herald added subscribers: s, VincentWu, luke957, vkmr, frasercrmck, evandro, 
luismarques, apazos, sameer.abuasal, s.egerton, Jim, benna, psnobl, jocewei, 
PkmX, the_o, brucehoult, MartinMosbeck, rogfer01, edward-jones, zzheng, jrtc27, 
kito-cheng, niosHD, sabuasal, simoncook, johnrusso, rbar, asb, arichardson.
Herald added a project: All.
4vtomat requested review of this revision.
Herald added subscribers: cfe-commits, pcwang-thead, eopXD, MaskRay.
Herald added a project: clang.

The llvm pre-merge test got timeout due to large test files, this commit
split up some files based on "element width(EEW)" under clang/test/CodeGen/RISCV
into even smaller ones.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D122370

Files:
  clang/test/CodeGen/RISCV/rvv-intrinsics/vloxei.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vloxei_ei16.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vloxei_ei32.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vloxei_ei64.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vloxei_ei8.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vloxseg.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vloxseg_ei16.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vloxseg_ei32.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vloxseg_ei64.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vloxseg_ei8.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vloxseg_mask.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vloxseg_mask_ei16.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vloxseg_mask_ei32.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vloxseg_mask_ei64.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vloxseg_mask_ei8.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vloxseg_mask_mf.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vloxseg_mask_mf_ei16.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vloxseg_mask_mf_ei32.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vloxseg_mask_mf_ei64.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vloxseg_mask_mf_ei8.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vloxseg_mf.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vloxseg_mf_ei16.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vloxseg_mf_ei32.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vloxseg_mf_ei64.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vloxseg_mf_ei8.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vlseg.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vlseg_e16.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vlseg_e32.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vlseg_e64.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vlseg_e8.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vlseg_mask.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vlseg_mask_e16.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vlseg_mask_e32.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vlseg_mask_e64.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vlseg_mask_e8.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vlsegff.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vlsegff_e16.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vlsegff_e32.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vlsegff_e64.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vlsegff_e8.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vlsegff_mask.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vlsegff_mask_e16.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vlsegff_mask_e32.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vlsegff_mask_e64.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vlsegff_mask_e8.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vlsseg.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vlsseg_e16.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vlsseg_e32.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vlsseg_e64.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vlsseg_e8.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vluxei.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vluxei_ei16.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vluxei_ei32.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vluxei_ei64.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vluxei_ei8.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vluxseg.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vluxseg_ei16.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vluxseg_ei32.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vluxseg_ei64.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vluxseg_ei8.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vluxseg_mask.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vluxseg_mask_ei16.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vluxseg_mask_ei32.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vluxseg_mask_ei64.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vluxseg_mask_ei8.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vluxseg_mask_mf.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vluxseg_mask_mf_ei16.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vluxseg_mask_mf_ei32.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vluxseg_mask_mf_ei64.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vluxseg_mask_mf_ei8.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vluxseg_mf.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vluxseg_mf_ei16.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vluxseg_mf_ei32.c
 

[clang] 86c1d07 - [clang][AVR] Implement standard calling convention for AVR and AVRTiny

2022-03-23 Thread Ben Shi via cfe-commits

Author: Ben Shi
Date: 2022-03-24T03:41:01Z
New Revision: 86c1d075bb32101fe1c403e873ce33945bfa9626

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

LOG: [clang][AVR] Implement standard calling convention for AVR and AVRTiny

This patch implements avr-gcc's calling convention:
https://gcc.gnu.org/wiki/avr-gcc#Calling_Convention

Reviewed By: aykevl

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

Added: 


Modified: 
clang/lib/Basic/Targets/AVR.cpp

Removed: 




diff  --git a/clang/lib/Basic/Targets/AVR.cpp b/clang/lib/Basic/Targets/AVR.cpp
index c60dbfd0eed12..ec021ad29fdf8 100644
--- a/clang/lib/Basic/Targets/AVR.cpp
+++ b/clang/lib/Basic/Targets/AVR.cpp
@@ -30,259 +30,259 @@ struct LLVM_LIBRARY_VISIBILITY MCUInfo {
 
 // NOTE: This list has been synchronized with gcc-avr 5.4.0 and avr-libc 2.0.0.
 static MCUInfo AVRMcus[] = {
-{"at90s1200", "__AVR_AT90S1200__", 0},
-{"attiny11", "__AVR_ATtiny11__", 0},
-{"attiny12", "__AVR_ATtiny12__", 0},
-{"attiny15", "__AVR_ATtiny15__", 0},
-{"attiny28", "__AVR_ATtiny28__", 0},
-{"at90s2313", "__AVR_AT90S2313__", 1},
-{"at90s2323", "__AVR_AT90S2323__", 1},
-{"at90s2333", "__AVR_AT90S2333__", 1},
-{"at90s2343", "__AVR_AT90S2343__", 1},
-{"attiny22", "__AVR_ATtiny22__", 1},
-{"attiny26", "__AVR_ATtiny26__", 1},
-{"at86rf401", "__AVR_AT86RF401__", 1},
-{"at90s4414", "__AVR_AT90S4414__", 1},
-{"at90s4433", "__AVR_AT90S4433__", 1},
-{"at90s4434", "__AVR_AT90S4434__", 1},
-{"at90s8515", "__AVR_AT90S8515__", 1},
-{"at90c8534", "__AVR_AT90c8534__", 1},
-{"at90s8535", "__AVR_AT90S8535__", 1},
-{"ata5272", "__AVR_ATA5272__", 1},
-{"attiny13", "__AVR_ATtiny13__", 1},
-{"attiny13a", "__AVR_ATtiny13A__", 1},
-{"attiny2313", "__AVR_ATtiny2313__", 1},
-{"attiny2313a", "__AVR_ATtiny2313A__", 1},
-{"attiny24", "__AVR_ATtiny24__", 1},
-{"attiny24a", "__AVR_ATtiny24A__", 1},
-{"attiny4313", "__AVR_ATtiny4313__", 1},
-{"attiny44", "__AVR_ATtiny44__", 1},
-{"attiny44a", "__AVR_ATtiny44A__", 1},
-{"attiny84", "__AVR_ATtiny84__", 1},
-{"attiny84a", "__AVR_ATtiny84A__", 1},
-{"attiny25", "__AVR_ATtiny25__", 1},
-{"attiny45", "__AVR_ATtiny45__", 1},
-{"attiny85", "__AVR_ATtiny85__", 1},
-{"attiny261", "__AVR_ATtiny261__", 1},
-{"attiny261a", "__AVR_ATtiny261A__", 1},
-{"attiny441", "__AVR_ATtiny441__", 1},
-{"attiny461", "__AVR_ATtiny461__", 1},
-{"attiny461a", "__AVR_ATtiny461A__", 1},
-{"attiny841", "__AVR_ATtiny841__", 1},
-{"attiny861", "__AVR_ATtiny861__", 1},
-{"attiny861a", "__AVR_ATtiny861A__", 1},
-{"attiny87", "__AVR_ATtiny87__", 1},
-{"attiny43u", "__AVR_ATtiny43U__", 1},
-{"attiny48", "__AVR_ATtiny48__", 1},
-{"attiny88", "__AVR_ATtiny88__", 1},
-{"attiny828", "__AVR_ATtiny828__", 1},
-{"at43usb355", "__AVR_AT43USB355__", 1},
-{"at76c711", "__AVR_AT76C711__", 1},
-{"atmega103", "__AVR_ATmega103__", 1},
-{"at43usb320", "__AVR_AT43USB320__", 1},
-{"attiny167", "__AVR_ATtiny167__", 1},
-{"at90usb82", "__AVR_AT90USB82__", 1},
-{"at90usb162", "__AVR_AT90USB162__", 1},
-{"ata5505", "__AVR_ATA5505__", 1},
-{"ata6617c", "__AVR_ATA6617C__", 1},
-{"ata664251", "__AVR_ATA664251__", 1},
-{"atmega8u2", "__AVR_ATmega8U2__", 1},
-{"atmega16u2", "__AVR_ATmega16U2__", 1},
-{"atmega32u2", "__AVR_ATmega32U2__", 1},
-{"attiny1634", "__AVR_ATtiny1634__", 1},
-{"atmega8", "__AVR_ATmega8__", 1},
-{"ata6289", "__AVR_ATA6289__", 1},
-{"atmega8a", "__AVR_ATmega8A__", 1},
-{"ata6285", "__AVR_ATA6285__", 1},
-{"ata6286", "__AVR_ATA6286__", 1},
-{"ata6612c", "__AVR_ATA6612C__", 1},
-{"atmega48", "__AVR_ATmega48__", 1},
-{"atmega48a", "__AVR_ATmega48A__", 1},
-{"atmega48pa", "__AVR_ATmega48PA__", 1},
-{"atmega48pb", "__AVR_ATmega48PB__", 1},
-{"atmega48p", "__AVR_ATmega48P__", 1},
-{"atmega88", "__AVR_ATmega88__", 1},
-{"atmega88a", "__AVR_ATmega88A__", 1},
-{"atmega88p", "__AVR_ATmega88P__", 1},
-{"atmega88pa", "__AVR_ATmega88PA__", 1},
-{"atmega88pb", "__AVR_ATmega88PB__", 1},
-{"atmega8515", "__AVR_ATmega8515__", 1},
-{"atmega8535", "__AVR_ATmega8535__", 1},
-{"atmega8hva", "__AVR_ATmega8HVA__", 1},
-{"at90pwm1", "__AVR_AT90PWM1__", 1},
-{"at90pwm2", "__AVR_AT90PWM2__", 1},
-{"at90pwm2b", "__AVR_AT90PWM2B__", 1},
-{"at90pwm3", "__AVR_AT90PWM3__", 1},
-{"at90pwm3b", "__AVR_AT90PWM3B__", 1},
-{"at90pwm81", "__AVR_AT90PWM81__", 1},
-{"ata5702m322", "__AVR_ATA5702M322__", 1},
-{"ata5782", "__AVR_ATA5782__", 1},
-{"ata5790", "__AVR_ATA5790__", 1},
-{"ata5790n", "__AVR_ATA5790N__", 1},
-{"ata5791", "__AVR_ATA5791__", 1},

[clang] 51585aa - [clang][AVR] Implement standard calling convention for AVR and AVRTiny

2022-03-23 Thread Ben Shi via cfe-commits

Author: Ben Shi
Date: 2022-03-24T02:08:22Z
New Revision: 51585aa240de6ef07979345de5406483d7393b7b

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

LOG: [clang][AVR] Implement standard calling convention for AVR and AVRTiny

This patch implements avr-gcc's calling convention:
https://gcc.gnu.org/wiki/avr-gcc#Calling_Convention

Reviewed By: aykevl

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

Added: 
clang/test/CodeGen/avr/argument.c

Modified: 
clang/lib/Basic/Targets/AVR.cpp
clang/lib/Basic/Targets/AVR.h
clang/lib/CodeGen/TargetInfo.cpp
clang/test/CodeGen/avr/struct.c

Removed: 




diff  --git a/clang/lib/Basic/Targets/AVR.cpp b/clang/lib/Basic/Targets/AVR.cpp
index dfc98c3d085d9..c60dbfd0eed12 100644
--- a/clang/lib/Basic/Targets/AVR.cpp
+++ b/clang/lib/Basic/Targets/AVR.cpp
@@ -24,7 +24,8 @@ namespace targets {
 struct LLVM_LIBRARY_VISIBILITY MCUInfo {
   const char *Name;
   const char *DefineName;
-  const int NumFlashBanks; // -1 means the device does not support LPM/ELPM.
+  const int NumFlashBanks; // Set to 0 for the devices do not support LPM/ELPM.
+  bool IsTiny; // Set to true for the devices belong to the avrtiny family.
 };
 
 // NOTE: This list has been synchronized with gcc-avr 5.4.0 and avr-libc 2.0.0.
@@ -282,14 +283,14 @@ static MCUInfo AVRMcus[] = {
 {"atxmega128a1", "__AVR_ATxmega128A1__", 2},
 {"atxmega128a1u", "__AVR_ATxmega128A1U__", 2},
 {"atxmega128a4u", "__AVR_ATxmega128A4U__", 2},
-{"attiny4", "__AVR_ATtiny4__", 0},
-{"attiny5", "__AVR_ATtiny5__", 0},
-{"attiny9", "__AVR_ATtiny9__", 0},
-{"attiny10", "__AVR_ATtiny10__", 0},
-{"attiny20", "__AVR_ATtiny20__", 0},
-{"attiny40", "__AVR_ATtiny40__", 0},
-{"attiny102", "__AVR_ATtiny102__", 0},
-{"attiny104", "__AVR_ATtiny104__", 0},
+{"attiny4", "__AVR_ATtiny4__", 0, true},
+{"attiny5", "__AVR_ATtiny5__", 0, true},
+{"attiny9", "__AVR_ATtiny9__", 0, true},
+{"attiny10", "__AVR_ATtiny10__", 0, true},
+{"attiny20", "__AVR_ATtiny20__", 0, true},
+{"attiny40", "__AVR_ATtiny40__", 0, true},
+{"attiny102", "__AVR_ATtiny102__", 0, true},
+{"attiny104", "__AVR_ATtiny104__", 0, true},
 {"attiny202", "__AVR_ATtiny202__", 1},
 {"attiny402", "__AVR_ATtiny402__", 1},
 {"attiny204", "__AVR_ATtiny204__", 1},
@@ -340,6 +341,27 @@ void 
AVRTargetInfo::fillValidCPUList(SmallVectorImpl ) const {
 Values.push_back(Info.Name);
 }
 
+bool AVRTargetInfo::setCPU(const std::string ) {
+  // Set the ABI and CPU fields if parameter Name is a family name.
+  if (llvm::is_contained(ValidFamilyNames, Name)) {
+CPU = Name;
+ABI = Name == "avrtiny" ? "avrtiny" : "avr";
+return true;
+  }
+
+  // Set the ABI field if parameter Name is a device name.
+  auto It = llvm::find_if(
+  AVRMcus, [&](const MCUInfo ) { return Info.Name == Name; });
+  if (It != std::end(AVRMcus)) {
+CPU = Name;
+ABI = It->IsTiny ? "avrtiny" : "avr";
+return true;
+  }
+
+  // Parameter Name is neither valid family name nor valid device name.
+  return false;
+}
+
 void AVRTargetInfo::getTargetDefines(const LangOptions ,
  MacroBuilder ) const {
   Builder.defineMacro("AVR");

diff  --git a/clang/lib/Basic/Targets/AVR.h b/clang/lib/Basic/Targets/AVR.h
index a281e2c2cd744..74b012a0923b7 100644
--- a/clang/lib/Basic/Targets/AVR.h
+++ b/clang/lib/Basic/Targets/AVR.h
@@ -74,8 +74,7 @@ class LLVM_LIBRARY_VISIBILITY AVRTargetInfo : public 
TargetInfo {
 static const char *const GCCRegNames[] = {
 "r0",  "r1",  "r2",  "r3",  "r4",  "r5",  "r6",  "r7",  "r8",  "r9",
 "r10", "r11", "r12", "r13", "r14", "r15", "r16", "r17", "r18", "r19",
-"r20", "r21", "r22", "r23", "r24", "r25", "X",   "Y",   "Z",   "SP"
-};
+"r20", "r21", "r22", "r23", "r24", "r25", "X",   "Y",   "Z",   "SP"};
 return llvm::makeArrayRef(GCCRegNames);
   }
 
@@ -169,15 +168,12 @@ class LLVM_LIBRARY_VISIBILITY AVRTargetInfo : public 
TargetInfo {
 
   bool isValidCPUName(StringRef Name) const override;
   void fillValidCPUList(SmallVectorImpl ) const override;
-  bool setCPU(const std::string ) override {
-bool isValid = isValidCPUName(Name);
-if (isValid)
-  CPU = Name;
-return isValid;
-  }
+  bool setCPU(const std::string ) override;
+  StringRef getABI() const override { return ABI; }
 
 protected:
   std::string CPU;
+  StringRef ABI;
 };
 
 } // namespace targets

diff  --git a/clang/lib/CodeGen/TargetInfo.cpp 
b/clang/lib/CodeGen/TargetInfo.cpp
index 61d1444916150..908f42ad410de 100644
--- a/clang/lib/CodeGen/TargetInfo.cpp
+++ b/clang/lib/CodeGen/TargetInfo.cpp
@@ -19,9 +19,9 @@
 #include "CodeGenFunction.h"
 #include "clang/AST/Attr.h"
 #include 

[PATCH] D122119: [C++20][Modules] Adjust handling of exports of namespaces and using-decls.

2022-03-23 Thread Chuanqi Xu via Phabricator via cfe-commits
ChuanqiXu accepted this revision.
ChuanqiXu added a comment.
This revision is now accepted and ready to land.

In D122119#3402168 , @urnathan wrote:

> In D122119#3401322 , @ChuanqiXu 
> wrote:
>
>> 
>
>
>
>> I think the example is invalid since it violates [[ 
>> http://eel.is/c++draft/module.interface#6 | [module.interface]p6 ]] 
>> explicitly. If this is intended behavior or by design, we should change the 
>> wording.
>
> That wording failed to be updated when the linkage-decl changes went in.  
> I'll add a note to DR 2541. Linkage specifications, module purview, and 
> module attachment

OK, if the wording is not consistent with the design, I have no further 
objections.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122119

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


[PATCH] D122089: [CUDA] Add getTargetFeatures for the NVPTX toolchain

2022-03-23 Thread Zixuan Wu via Phabricator via cfe-commits
zixuan-wu added inline comments.



Comment at: clang/lib/Driver/ToolChains/Cuda.cpp:648
+#define CASE_CUDA_VERSION(CUDA_VER, PTX_VER)   
\
+  case CudaVersion::CUDA_##CUDA_VER:   
\
+PtxFeature = "+ptx" #PTX_VER;  
\

It's same name as `CudaVersion` variable above, and it cause compile error. 
@jhuber6 
Maybe the error depends on host compiler version so that it does not report 
immediately.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122089

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


[PATCH] D120720: [clang][AVR] Implement standard calling convention for AVR and AVRTiny

2022-03-23 Thread Ben Shi via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG51585aa240de: [clang][AVR] Implement standard calling 
convention for AVR and AVRTiny (authored by benshi001).

Changed prior to commit:
  https://reviews.llvm.org/D120720?vs=415734=417811#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120720

Files:
  clang/lib/Basic/Targets/AVR.cpp
  clang/lib/Basic/Targets/AVR.h
  clang/lib/CodeGen/TargetInfo.cpp
  clang/test/CodeGen/avr/argument.c
  clang/test/CodeGen/avr/struct.c

Index: clang/test/CodeGen/avr/struct.c
===
--- clang/test/CodeGen/avr/struct.c
+++ clang/test/CodeGen/avr/struct.c
@@ -1,15 +1,23 @@
-// RUN: %clang_cc1 -triple avr -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -triple avr -target-cpu atmega328 -emit-llvm %s -o - \
+// RUN: | FileCheck %s --check-prefix=AVR
+// RUN: %clang_cc1 -triple avr -target-cpu attiny40 -emit-llvm %s -o - \
+// RUN: | FileCheck %s --check-prefix=TINY
 
 // Structure that is more than 8 bytes.
 struct s10 {
   int a, b, c, d, e;
 };
 
-// Structure that is less than 8 bytes.
+// Structure that is less than 8 bytes but more than 4 bytes.
 struct s06 {
   int a, b, c;
 };
 
+// Structure that is less than 4 bytes.
+struct s04 {
+  int a, b;
+};
+
 struct s10 foo10(int a, int b, int c) {
   struct s10 a0;
   return a0;
@@ -20,7 +28,21 @@
   return a0;
 }
 
-// CHECK: %struct.s10 = type { i16, i16, i16, i16, i16 }
-// CHECK: %struct.s06 = type { i16, i16, i16 }
-// CHECK: define{{.*}} void @foo10(%struct.s10* {{.*}}, i16 noundef %a, i16 noundef %b, i16 noundef %c)
-// CHECK: define{{.*}} %struct.s06 @foo06(i16 noundef %a, i16 noundef %b, i16 noundef %c)
+struct s04 foo04(int a, int b) {
+  struct s04 a0;
+  return a0;
+}
+
+// AVR: %struct.s10 = type { i16, i16, i16, i16, i16 }
+// AVR: %struct.s06 = type { i16, i16, i16 }
+// AVR: %struct.s04 = type { i16, i16 }
+// AVR: define{{.*}} void @foo10(%struct.s10* {{.*}}, i16 noundef %a, i16 noundef %b, i16 noundef %c)
+// AVR: define{{.*}} %struct.s06 @foo06(i16 noundef %a, i16 noundef %b, i16 noundef %c)
+// AVR: define{{.*}} %struct.s04 @foo04(i16 noundef %a, i16 noundef %b)
+
+// TINY: %struct.s10 = type { i16, i16, i16, i16, i16 }
+// TINY: %struct.s06 = type { i16, i16, i16 }
+// TINY: %struct.s04 = type { i16, i16 }
+// TINY: define{{.*}} void @foo10(%struct.s10* {{.*}}, i16 noundef %a, i16 noundef %b, i16 noundef %c)
+// TINY: define{{.*}} void @foo06(%struct.s06* {{.*}}, i16 noundef %a, i16 noundef %b, i16 noundef %c)
+// TINY: define{{.*}} %struct.s04 @foo04(i16 noundef %a, i16 noundef %b)
Index: clang/test/CodeGen/avr/argument.c
===
--- /dev/null
+++ clang/test/CodeGen/avr/argument.c
@@ -0,0 +1,116 @@
+// RUN: %clang_cc1 -triple avr -target-cpu atmega328 -emit-llvm %s -o - \
+// RUN: | FileCheck %s --check-prefix AVR
+// RUN: %clang_cc1 -triple avr -target-cpu attiny40 -emit-llvm %s -o - \
+// RUN: | FileCheck %s --check-prefix TINY
+
+// NOTE: All arguments are passed via the stack for functions with variable arguments.
+// AVR:  define {{.*}} i8 @foo0(i8 {{.*}}, i8 {{.*}}, ...)
+// TINY: define {{.*}} i8 @foo0(i8 {{.*}}, i8 {{.*}}, ...)
+// AVR-NOT:  define {{.*}} i8 @foo0(i8 {{.*}} signext {{.*}}, i8 {{.*}} signext {{.*}}, ...)
+// TINY-NOT: define {{.*}} i8 @foo0(i8 {{.*}} signext {{.*}}, i8 {{.*}} signext {{.*}}, ...)
+char foo0(char a, char b, ...) {
+  return a + b;
+}
+
+// NOTE: All arguments are passed via registers on both avr and avrtiny.
+// AVR:  define {{.*}} i8 @foo1(i32 {{.*}}, i8 {{.*}} signext {{.*}})
+// TINY: define {{.*}} i8 @foo1(i32 {{.*}}, i8 {{.*}} signext {{.*}})
+char foo1(long a, char b) {
+  return a + b;
+}
+
+// NOTE: The argument `char c` is passed via registers on avr, while via the stack on avrtiny.
+//   The argument `char b` costs 2 registers, so there is no vacant register left for
+//   `char c` on avrtiny.
+// AVR:  define {{.*}} i8 @foo2(i32 {{.*}}, i8 {{.*}} signext {{.*}}, i8 {{.*}} signext {{.*}})
+// TINY: define {{.*}} i8 @foo2(i32 {{.*}}, i8 {{.*}} signext {{.*}}, i8 {{.*}})
+// TINY-NOT: define {{.*}} i8 @foo2(i32 {{.*}}, i8 {{.*}} signext {{.*}}, i8 {{.*}} signext {{.*}})
+char foo2(long a, char b, char c) {
+  return a + b + c;
+}
+
+// NOTE: On avr, the argument `a` costs 16 registers and `b` costs 2 registers, so
+//   `c` has to be passed via the stack.
+// AVR:  define {{.*}} i8 @foo3({{.*}}, i8 {{.*}} signext {{.*}}, i8 {{.*}})
+// AVR-NOT:  define {{.*}} i8 @foo3({{.*}}, i8 {{.*}} signext {{.*}}, i8 {{.*}} signext {{.*}})
+// TINY: define {{.*}} i8 @foo3({{.*}}, i8 {{.*}}, i8 {{.*}})
+// TINY-NOT: define {{.*}} i8 @foo3({{.*}}, i8 {{.*}} signext {{.*}}, i8 {{.*}} signext {{.*}})
+struct s15 {
+  char arr[15];
+};
+char foo3(struct s15 a, char b, 

[PATCH] D120874: [C++20] [Modules] Use '-' as the separator of partitions when searching in filesystems

2022-03-23 Thread Chuanqi Xu via Phabricator via cfe-commits
ChuanqiXu added a comment.

@vsapsai @dblaikie I want to make sure if this one would affect clang modules. 
Or simply, would the name of clang modules contain `:`? (`:` is the separator 
of C++20 modules partitions.)


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

https://reviews.llvm.org/D120874

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


[PATCH] D122248: [clang][CodeGen]Fix clang crash and add bitfield support in __builtin_dump_struct

2022-03-23 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D122248#3403478 , @erichkeane 
wrote:

> If it is ok, I think we should probably change the format of the 'dump' for 
> fields.  Using the colon to split up the field from the value is unfortunate, 
> may I suggest replacing it with '=' instead?  As well as printing the size 
> after a colon.  So for:
>
>   void foo(void) {
> struct Bar {
>   unsigned c : 1;
>   unsigned : 3;
>   unsigned : 0;
>   unsigned b;
> };
>   
> struct Bar a = {
>   .c = 1,
>   .b = 2022,
> };
>   
> __builtin_dump_struct(, );
>   }
>
> Output:
>
>   struct Bar {
>   unsigned int c : 1 = 1
>   unsigned int : 3  = 0
>   unsigned int : 0 = 
>   unsigned int b = 2022
>   }
>
> What do you all think?

I think that's a good idea for clarity. For the case where we have no value, I 
wonder if we want to do something like: `unsigned int : 0 = ` 
(or something else to make it exceptionally clear that there's nothing missing 
after the `=`)?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122248

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


[PATCH] D122344: [clang][driver] Disable non-functional --version option for clang -cc1

2022-03-23 Thread Emil Kieri via Phabricator via cfe-commits
ekieri created this revision.
ekieri added reviewers: bruno, v.g.vassilev, thakis, dexonsmith.
Herald added a reviewer: sscalpone.
Herald added a project: All.
ekieri requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This patch removes --version as a clang -cc1 option.

  clang --version

and

  clang --cc1 -version

remain valid. This behaviour is consistent with clang -cc1as.

Previously, clang -cc1 accepted both --version and -version, but
only -version was acted upon. The call

  clang -cc1 --version

stalled without any message: --version was an accepted option but
triggered no action, and the driver waited for standard input.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D122344

Files:
  clang/include/clang/Driver/Options.td
  clang/test/Frontend/unknown-arg.c


Index: clang/test/Frontend/unknown-arg.c
===
--- clang/test/Frontend/unknown-arg.c
+++ clang/test/Frontend/unknown-arg.c
@@ -4,6 +4,9 @@
 // RUN: FileCheck %s --check-prefix=DID-YOU-MEAN
 // RUN: not %clang %s -E -Xclang --hel[ 2>&1 | \
 // RUN: FileCheck %s --check-prefix=DID-YOU-MEAN
+// RUN: not %clang_cc1 --version 2>&1 | \
+// RUN: FileCheck %s --check-prefix=DID-YOU-MEAN-VER
 
 // CHECK: error: unknown argument: '--helium'
 // DID-YOU-MEAN: error: unknown argument '--hel['; did you mean '--help'?
+// DID-YOU-MEAN-VER: error: unknown argument '--version'; did you mean 
'-version'?
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -4200,7 +4200,7 @@
   HelpText<"Serialize compiler diagnostics to a file">;
 // We give --version different semantics from -version.
 def _version : Flag<["--"], "version">,
-  Flags<[CoreOption, CC1Option, FC1Option, FlangOption]>,
+  Flags<[CoreOption, FC1Option, FlangOption]>,
   HelpText<"Print version information">;
 def _signed_char : Flag<["--"], "signed-char">, Alias;
 def _std : Separate<["--"], "std">, Alias;


Index: clang/test/Frontend/unknown-arg.c
===
--- clang/test/Frontend/unknown-arg.c
+++ clang/test/Frontend/unknown-arg.c
@@ -4,6 +4,9 @@
 // RUN: FileCheck %s --check-prefix=DID-YOU-MEAN
 // RUN: not %clang %s -E -Xclang --hel[ 2>&1 | \
 // RUN: FileCheck %s --check-prefix=DID-YOU-MEAN
+// RUN: not %clang_cc1 --version 2>&1 | \
+// RUN: FileCheck %s --check-prefix=DID-YOU-MEAN-VER
 
 // CHECK: error: unknown argument: '--helium'
 // DID-YOU-MEAN: error: unknown argument '--hel['; did you mean '--help'?
+// DID-YOU-MEAN-VER: error: unknown argument '--version'; did you mean '-version'?
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -4200,7 +4200,7 @@
   HelpText<"Serialize compiler diagnostics to a file">;
 // We give --version different semantics from -version.
 def _version : Flag<["--"], "version">,
-  Flags<[CoreOption, CC1Option, FC1Option, FlangOption]>,
+  Flags<[CoreOption, FC1Option, FlangOption]>,
   HelpText<"Print version information">;
 def _signed_char : Flag<["--"], "signed-char">, Alias;
 def _std : Separate<["--"], "std">, Alias;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D122248: [clang][CodeGen]Fix clang crash and add bitfield support in __builtin_dump_struct

2022-03-23 Thread Wang Yihan via Phabricator via cfe-commits
yihanaa added a comment.

In D122248#3403518 , @aaron.ballman 
wrote:

> In D122248#3403478 , @erichkeane 
> wrote:
>
>> If it is ok, I think we should probably change the format of the 'dump' for 
>> fields.  Using the colon to split up the field from the value is 
>> unfortunate, may I suggest replacing it with '=' instead?  As well as 
>> printing the size after a colon.  So for:
>>
>>   void foo(void) {
>> struct Bar {
>>   unsigned c : 1;
>>   unsigned : 3;
>>   unsigned : 0;
>>   unsigned b;
>> };
>>   
>> struct Bar a = {
>>   .c = 1,
>>   .b = 2022,
>> };
>>   
>> __builtin_dump_struct(, );
>>   }
>>
>> Output:
>>
>>   struct Bar {
>>   unsigned int c : 1 = 1
>>   unsigned int : 3  = 0
>>   unsigned int : 0 = 
>>   unsigned int b = 2022
>>   }
>>
>> What do you all think?
>
> I think that's a good idea for clarity. For the case where we have no value, 
> I wonder if we want to do something like: `unsigned int : 0 = 
> ` (or something else to make it exceptionally clear that 
> there's nothing missing after the `=`)?

how

In D122248#3403518 , @aaron.ballman 
wrote:

> In D122248#3403478 , @erichkeane 
> wrote:
>
>> If it is ok, I think we should probably change the format of the 'dump' for 
>> fields.  Using the colon to split up the field from the value is 
>> unfortunate, may I suggest replacing it with '=' instead?  As well as 
>> printing the size after a colon.  So for:
>>
>>   void foo(void) {
>> struct Bar {
>>   unsigned c : 1;
>>   unsigned : 3;
>>   unsigned : 0;
>>   unsigned b;
>> };
>>   
>> struct Bar a = {
>>   .c = 1,
>>   .b = 2022,
>> };
>>   
>> __builtin_dump_struct(, );
>>   }
>>
>> Output:
>>
>>   struct Bar {
>>   unsigned int c : 1 = 1
>>   unsigned int : 3  = 0
>>   unsigned int : 0 = 
>>   unsigned int b = 2022
>>   }
>>
>> What do you all think?
>
> I think that's a good idea for clarity. For the case where we have no value, 
> I wonder if we want to do something like: `unsigned int : 0 = 
> ` (or something else to make it exceptionally clear that 
> there's nothing missing after the `=`)?

How to judge whether this field is initialized? Maybe this memory has been 
initialized by memset


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122248

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


[PATCH] D121873: [clang][extract-api] Add enum support

2022-03-23 Thread Zixu Wang via Phabricator via cfe-commits
zixuw added a comment.

In D121873#3403082 , @mstorsjo wrote:

> This (or some closely related commit?) causes a huge amount of warnings when 
> building with GCC:
>
>   warning: ‘clang::extractapi::EnumRecord’ has a field 
> ‘clang::extractapi::EnumRecord::Constants’ whose type uses the anonymous 
> namespace [-Wsubobject-linkage]
>167 | struct EnumRecord : APIRecord {
>|^~

Hi Martin! Thanks for the update on the warnings on GCC, didn't know about that.
I think the warning is complaining about the use of `APIRecordUniquePtr`, which 
should be removed by D122331 .


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121873

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


[PATCH] D117522: [clang-tidy] Add modernize-macro-to-enum check

2022-03-23 Thread Richard via Phabricator via cfe-commits
LegalizeAdulthood added inline comments.



Comment at: clang-tools-extra/clang-tidy/modernize/MacroToEnumCheck.cpp:47
+CRLF,
+CRLFCR,
+  };

aaron.ballman wrote:
> LegalizeAdulthood wrote:
> > aaron.ballman wrote:
> > > LegalizeAdulthood wrote:
> > > > aaron.ballman wrote:
> > > > > I'm a bit confused by this one as this is not a valid line ending 
> > > > > (it's either three valid line endings or two valid line endings, 
> > > > > depending on how you look at it). Can you explain why this is needed?
> > > > It's a state machine, where the states are named for what we've seen so 
> > > > far and we're looking for //two// consecutive line endings, not just 
> > > > one.  Does it make sense now?
> > > Thanks, I understood it was a state machine, but it's a confused one to 
> > > me. `\r` was the line ending on Mac Classic, I've not seen it used 
> > > outside of that platform (and I've not seen anyone write code for that 
> > > platform in a long time). So, to me, the only valid combinations of line 
> > > endings to worry about are: `LF LF`; `CRLF CRLF`; `CRLF LF`; `LF CRLF`.
> > > 
> > > `LF LF` returns false (Nothing -> LF -> return false)
> > > `CRLF CRLF` returns false (Nothing -> CR -> CRLF -> CRLFCR -> return 
> > > false)
> > > `CRLF LF` returns true (Nothing -> CR -> CRLF -> LF -> finish loop)
> > > `LF CRLF` returns true (Nothing -> LF -> CR -> CRLF -> finish loop)
> > > 
> > > (If you also intend to support Mac Classic line endings for some reason, 
> > > this gets even more complicated.)
> > I was trying to follow "be liberal in what you accept as input and 
> > conservative in what you generate as output" maxim.  I can remove the `CR` 
> > as a line ending case if you think it's too obscure.
> If Clang supports it as a line ending, we probably should too, but... how do 
> we handle CRLF vs "I mixed a CR with an LF by accident" kind of inputs? 
> (Maybe we just treat that as CRLF and if the behavior is bad, the user 
> shouldn't mix their line endings that way; I think that's defensible.) That 
> seems to be similar to the scenario that's confusing me above where the user 
> mixed an LF and CRLF by accident.
Well, as far as Clang is concerned it's all just "whitespace" that gets eaten 
up by the preprocessor.  Actually, that gives me a thought.  A preprocessing 
directive is considered to end at the physical line ending, so I should look to 
see what sort of characters it considers to "end the line".

For the accidental mix-up, I'm not going to worry about that here.  Your input 
files are assumed to be "well formed".  The worst that happens in this check is 
that two blocks of macros that //look// like they are separated by a blank line 
are considered as a single clump by this check.

In other words, the worst that can happen is:
  - Two clumps of macros are considered together.
  - One clump of macros that is discarded because it doesn't follow the 
constraints "taints" an adjacent clump of macros that do follow the constraints.

Either way, nothing harmful happens to your code.  It will still compile and be 
syntactically and semantically equivalent to what was there before.




Comment at: 
clang-tools-extra/test/clang-tidy/checkers/modernize-macro-to-enum.cpp:67-68
+
+// Undefining a macro invalidates adjacent macros
+// from being considered as an enum.
+#define REMOVED1 1

aaron.ballman wrote:
> LegalizeAdulthood wrote:
> > aaron.ballman wrote:
> > > LegalizeAdulthood wrote:
> > > > LegalizeAdulthood wrote:
> > > > > aaron.ballman wrote:
> > > > > > What about an #undef that's not adjacent to any macros? e.g.,
> > > > > > ```
> > > > > > #define FOO 1
> > > > > > #define BAR 2
> > > > > > #define BAZ 3
> > > > > > 
> > > > > > int i = 12;
> > > > > > 
> > > > > > #if defined(FROBBLE)
> > > > > > #undef FOO
> > > > > > #endif
> > > > > > ```
> > > > > > I'm worried that perhaps other code elsewhere will be checking 
> > > > > > `defined(FOO)` perhaps in cases conditionally compiled away, and 
> > > > > > switching `FOO` to be an enum constant will break other 
> > > > > > configurations. To be honest, I'm a bit worried about that for all 
> > > > > > of the transformations here... and I don't know a good way to 
> > > > > > address that aside from "don't use the check". It'd be interesting 
> > > > > > to know what kind of false positive rate we have for the fixes if 
> > > > > > we ran it over a large corpus of code.
> > > > > Yeah, the problem arises whenever you make any changes to a header 
> > > > > file.  Did you also change all translation units that include the 
> > > > > header?  What about conditionally compiled code that was "off" in the 
> > > > > translation unit for the automated change?  Currently, we don't have 
> > > > > a way of analyzing a group of translation units together for a 
> > > > > cohesive change, nor do we have any way of inspecting more deeply 
> > > > > into conditionally compiled 

[PATCH] D122155: Add warning when eval-method is set in the presence of value unsafe floating-point calculations.

2022-03-23 Thread Zahira Ammarguellat via Phabricator via cfe-commits
zahiraam marked 2 inline comments as done.
zahiraam added inline comments.



Comment at: clang/include/clang/Basic/DiagnosticFrontendKinds.td:50-53
+def warn_eval_method_setting_via_option_in_value_unsafe_context : Warning<
+"setting the eval method via '-ffp-eval-method' has not effect when 
numeric "
+"results of floating-point calculations aren't value-safe.">,
+InGroup;

aaron.ballman wrote:
> andrew.w.kaylor wrote:
> > zahiraam wrote:
> > > aaron.ballman wrote:
> > > > Unless you have a strong reason for this to be a warning, this seems 
> > > > like a situation we should diagnose as an error with a much clearer 
> > > > message.
> > > May  be @andrew.w.kaylor would weigh in on this?
> > I was going to say that for the command line option we could just issue a 
> > warning saying that the later option overrides the earlier, but it's a bit 
> > complicated to sort out what that would mean if the eval method follows a 
> > fast-math option and it might not always be what the user intended. So, I 
> > guess I'd agree that it should be an error.
> > 
> > For the case with pragmas, the model I'd follow is the mixing of #pragma 
> > float_control(except, on) with a fast-math mode or #pragma 
> > float_control(precise, off) with a non-ignore exception mode. In both those 
> > cases we issue an error.
> > For the case with pragmas, the model I'd follow is the mixing of #pragma 
> > float_control(except, on) with a fast-math mode or #pragma 
> > float_control(precise, off) with a non-ignore exception mode. In both those 
> > cases we issue an error.
> 
> Good catch, I think that's a good approach as well.
I think i  will have the issue with the order of appearance of the options on 
the command line. 
// RUN: -freciprocal-math -mreassociate   -ffp-eval-method=source 
and
// RUN: -mreassociate -ffp-eval-method=source 

will depend on which order I will test for 
LangOpts.ApproxFunc/AllowFPReasson/AllowRecip being used or not?

The run lines above might give the same diagnostic. Unless I do something 
really complicated to check the order of the options on the command line?


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

https://reviews.llvm.org/D122155

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


[PATCH] D122331: [clang][extract-api] Stop allocating APIRecords via BumpPtrAllocator

2022-03-23 Thread Zixu Wang via Phabricator via cfe-commits
zixuw added a comment.

This is much cleaner now. Thanks Daniel!




Comment at: clang/include/clang/ExtractAPI/API.h:326
+  /// Note: The main use for this is being able to deduplicate strings.
   llvm::BumpPtrAllocator Allocator;
 

Should we just rename the allocator along the lines of `StringAllocator` or 
`StringPool` so that the code is self-explanatory?



Comment at: clang/include/clang/ExtractAPI/API.h:326
+  /// Note: The main use for this is being able to deduplicate strings.
   llvm::BumpPtrAllocator Allocator;
 

zixuw wrote:
> Should we just rename the allocator along the lines of `StringAllocator` or 
> `StringPool` so that the code is self-explanatory?
Also now that the allocator is used exclusively for strings, should we use 
`SpecificBumpPtrAllocator`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122331

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


[PATCH] D122303: [pseudo] Sort nonterminals based on their reduction order.

2022-03-23 Thread Haojian Wu via Phabricator via cfe-commits
hokein updated this revision to Diff 417731.
hokein marked an inline comment as done.
hokein added a comment.

address comments, remove the extraction of TestGrammar.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122303

Files:
  clang-tools-extra/pseudo/include/clang-pseudo/Grammar.h
  clang-tools-extra/pseudo/lib/GrammarBNF.cpp
  clang-tools-extra/pseudo/test/lr-build-basic.test
  clang-tools-extra/pseudo/test/lr-build-conflicts.test
  clang-tools-extra/pseudo/unittests/GrammarTest.cpp

Index: clang-tools-extra/pseudo/unittests/GrammarTest.cpp
===
--- clang-tools-extra/pseudo/unittests/GrammarTest.cpp
+++ clang-tools-extra/pseudo/unittests/GrammarTest.cpp
@@ -44,6 +44,16 @@
 return 0;
   }
 
+  RuleID ruleFor(llvm::StringRef NonterminalName) const {
+auto RuleRange = G->table().Nonterminals[id(NonterminalName)].RuleRange;
+if (RuleRange.End - RuleRange.Start == 1)
+  return G->table().Nonterminals[id(NonterminalName)].RuleRange.Start;
+ADD_FAILURE() << "Expected a single rule for " << NonterminalName
+  << ", but it has " << RuleRange.End - RuleRange.Start
+  << " rule!\n";
+return 0;
+  }
+
 protected:
   std::unique_ptr G;
   std::vector Diags;
@@ -74,6 +84,21 @@
Sequence(id("INT"), id(";";
 }
 
+TEST_F(GrammarTest, RuleIDSorted) {
+  build(R"bnf(
+_ := x
+
+x := y
+y := z
+z := IDENTIFIER
+  )bnf");
+  ASSERT_TRUE(Diags.empty());
+
+  EXPECT_LT(ruleFor("z"), ruleFor("y"));
+  EXPECT_LT(ruleFor("y"), ruleFor("x"));
+  EXPECT_LT(ruleFor("x"), ruleFor("_"));
+}
+
 TEST_F(GrammarTest, Diagnostics) {
   build(R"cpp(
 _ := ,_opt
@@ -82,6 +107,9 @@
 _ := IDENFIFIE # a typo of the terminal IDENFITIER
 
 invalid
+# cycle
+a := b
+b := a
   )cpp");
 
   EXPECT_EQ(G->startSymbol(), id("_"));
@@ -91,7 +119,8 @@
  "No rules for nonterminal: undefined-sym",
  "Failed to parse 'invalid': no separator :=",
  "Token-like name IDENFIFIE is used as a nonterminal",
- "No rules for nonterminal: IDENFIFIE"));
+ "No rules for nonterminal: IDENFIFIE",
+ "The grammar is cyclic, see symbol a"));
 }
 
 TEST_F(GrammarTest, FirstAndFollowSets) {
Index: clang-tools-extra/pseudo/test/lr-build-conflicts.test
===
--- clang-tools-extra/pseudo/test/lr-build-conflicts.test
+++ clang-tools-extra/pseudo/test/lr-build-conflicts.test
@@ -5,8 +5,8 @@
 # RUN: clang-pseudo -grammar %s -print-graph | FileCheck %s --check-prefix=GRAPH
 #  GRAPH: States
 # GRAPH-NEXT: State 0
-# GRAPH-NEXT: _ :=  • expr
 # GRAPH-NEXT: expr :=  • expr - expr
+# GRAPH-NEXT: _ :=  • expr
 # GRAPH-NEXT: expr :=  • IDENTIFIER
 # GRAPH-NEXT: State 1
 # GRAPH-NEXT: _ := expr • 
@@ -42,6 +42,6 @@
 # TABLE-NEXT: 'IDENTIFIER': shift state 2
 # TABLE-NEXT: 'expr': go to state 4
 # TABLE-NEXT: State 4
-# TABLE-NEXT: 'EOF': reduce by rule 2 'expr := expr - expr'
+# TABLE-NEXT: 'EOF': reduce by rule 0 'expr := expr - expr'
 # TABLE-NEXT: '-': shift state 3
-# TABLE-NEXT: '-': reduce by rule 2 'expr := expr - expr'
+# TABLE-NEXT: '-': reduce by rule 0 'expr := expr - expr'
Index: clang-tools-extra/pseudo/test/lr-build-basic.test
===
--- clang-tools-extra/pseudo/test/lr-build-basic.test
+++ clang-tools-extra/pseudo/test/lr-build-basic.test
@@ -26,4 +26,4 @@
 # TABLE-NEXT: State 2
 # TABLE-NEXT: 'EOF': reduce by rule 1 'expr := id'
 # TABLE-NEXT: State 3
-# TABLE-NEXT: 'EOF': reduce by rule 2 'id := IDENTIFIER'
+# TABLE-NEXT: 'EOF': reduce by rule 0 'id := IDENTIFIER'
Index: clang-tools-extra/pseudo/lib/GrammarBNF.cpp
===
--- clang-tools-extra/pseudo/lib/GrammarBNF.cpp
+++ clang-tools-extra/pseudo/lib/GrammarBNF.cpp
@@ -9,6 +9,7 @@
 #include "clang-pseudo/Grammar.h"
 #include "clang/Basic/TokenKinds.h"
 #include "llvm/ADT/DenseSet.h"
+#include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/Support/FormatVariadic.h"
 #include 
@@ -87,23 +88,81 @@
 }
 assert(T->Rules.size() < (1 << RuleBits) &&
"Too many rules to fit in RuleID bits!");
-llvm::sort(T->Rules, [](const Rule , const Rule ) {
-  // Sorted by the Target.
-  return std::tie(Left.Target, Left.Size) <
- std::tie(Right.Target, Right.Size);
-});
-RuleID RulePos = 0;
+const auto  = getTopologicalOrder(T.get());
+llvm::stable_sort(
+T->Rules, [](const Rule , const Rule ) {
+  // Sorted by the topological order of the nonterminal Target.
+   

[PATCH] D122352: [OpenMP] Do not create offloading entries for internal or hidden symbols

2022-03-23 Thread Joseph Huber via Phabricator via cfe-commits
jhuber6 created this revision.
jhuber6 added reviewers: jdoerfert, JonChesterfield, ronlieb, ABataev.
Herald added subscribers: asavonic, guansong, yaxunl.
Herald added a project: All.
jhuber6 requested review of this revision.
Herald added subscribers: cfe-commits, sstefan1.
Herald added a project: clang.

Currently we create offloading entries to register device variables with
the host. When we register a variable we will look up the symbol in the
device image and map the device address to the host address. This is a
problem when the symbol is declared with hidden visibility or internal
linkage. This means the symbol is not accessible externally and we
cannot get its address. We should still allow static variables to be
declared on the device, but ew should not create an offloading entry for
them so they exist independently on the host and device.

Fixes #54309


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D122352

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


Index: clang/test/OpenMP/nvptx_declare_target_var_ctor_dtor_codegen.cpp
===
--- clang/test/OpenMP/nvptx_declare_target_var_ctor_dtor_codegen.cpp
+++ clang/test/OpenMP/nvptx_declare_target_var_ctor_dtor_codegen.cpp
@@ -72,8 +72,6 @@
 // DEVICE-DAG: call void
 // DEVICE-DAG: ret void
 
-// HOST-DAG: @.omp_offloading.entry_name{{.*}} = internal unnamed_addr 
constant [{{[0-9]+}} x i8] c"[[C_ADDR]]\00"
-// HOST-DAG: @.omp_offloading.entry.[[C_ADDR]] = weak{{.*}} constant 
%struct.__tgt_offload_entry { i8* bitcast (i32* @[[C_ADDR]] to i8*), i8* 
getelementptr inbounds ([{{[0-9]+}} x i8], [{{[0-9]+}} x i8]* 
@.omp_offloading.entry_name{{.*}}, i32 0, i32 0), i64 4, i32 0, i32 0 }, 
section "omp_offloading_entries", align 1
 // HOST-DAG: @.omp_offloading.entry_name{{.*}} = internal unnamed_addr 
constant [{{[0-9]+}} x i8] c"[[CD_ADDR]]\00"
 // HOST-DAG: @.omp_offloading.entry.[[CD_ADDR]] = weak{{.*}} constant 
%struct.__tgt_offload_entry { i8* bitcast (%struct.S* @[[CD_ADDR]] to i8*), i8* 
getelementptr inbounds ([{{[0-9]+}} x i8], [{{[0-9]+}} x i8]* 
@.omp_offloading.entry_name{{.*}}, i32 0, i32 0), i64 4, i32 0, i32 0 }, 
section "omp_offloading_entries", align 1
 // HOST-DAG: @.omp_offloading.entry_name{{.*}} = internal unnamed_addr 
constant [{{[0-9]+}} x i8] c"[[C_CTOR]]\00"
Index: clang/lib/CodeGen/CGOpenMPRuntime.cpp
===
--- clang/lib/CodeGen/CGOpenMPRuntime.cpp
+++ clang/lib/CodeGen/CGOpenMPRuntime.cpp
@@ -3323,6 +3323,15 @@
 }
 break;
   }
+
+  // Hidden or internal symbols on the device are not externally visible. 
We
+  // should not attempt to register them by creating an offloading entry.
+  if (auto *GV = dyn_cast(CE->getAddress()))
+if (GV->getLinkage() == llvm::GlobalValue::InternalLinkage ||
+GV->getLinkage() == llvm::GlobalValue::PrivateLinkage ||
+GV->getVisibility() == llvm::GlobalValue::HiddenVisibility)
+  continue;
+
   createOffloadEntry(CE->getAddress(), CE->getAddress(),
  CE->getVarSize().getQuantity(), Flags,
  CE->getLinkage());


Index: clang/test/OpenMP/nvptx_declare_target_var_ctor_dtor_codegen.cpp
===
--- clang/test/OpenMP/nvptx_declare_target_var_ctor_dtor_codegen.cpp
+++ clang/test/OpenMP/nvptx_declare_target_var_ctor_dtor_codegen.cpp
@@ -72,8 +72,6 @@
 // DEVICE-DAG: call void
 // DEVICE-DAG: ret void
 
-// HOST-DAG: @.omp_offloading.entry_name{{.*}} = internal unnamed_addr constant [{{[0-9]+}} x i8] c"[[C_ADDR]]\00"
-// HOST-DAG: @.omp_offloading.entry.[[C_ADDR]] = weak{{.*}} constant %struct.__tgt_offload_entry { i8* bitcast (i32* @[[C_ADDR]] to i8*), i8* getelementptr inbounds ([{{[0-9]+}} x i8], [{{[0-9]+}} x i8]* @.omp_offloading.entry_name{{.*}}, i32 0, i32 0), i64 4, i32 0, i32 0 }, section "omp_offloading_entries", align 1
 // HOST-DAG: @.omp_offloading.entry_name{{.*}} = internal unnamed_addr constant [{{[0-9]+}} x i8] c"[[CD_ADDR]]\00"
 // HOST-DAG: @.omp_offloading.entry.[[CD_ADDR]] = weak{{.*}} constant %struct.__tgt_offload_entry { i8* bitcast (%struct.S* @[[CD_ADDR]] to i8*), i8* getelementptr inbounds ([{{[0-9]+}} x i8], [{{[0-9]+}} x i8]* @.omp_offloading.entry_name{{.*}}, i32 0, i32 0), i64 4, i32 0, i32 0 }, section "omp_offloading_entries", align 1
 // HOST-DAG: @.omp_offloading.entry_name{{.*}} = internal unnamed_addr constant [{{[0-9]+}} x i8] c"[[C_CTOR]]\00"
Index: clang/lib/CodeGen/CGOpenMPRuntime.cpp
===
--- clang/lib/CodeGen/CGOpenMPRuntime.cpp
+++ clang/lib/CodeGen/CGOpenMPRuntime.cpp
@@ -3323,6 +3323,15 @@
 }
 break;
   }
+
+  // Hidden or internal symbols on the device are not externally visible. We
+  

[PATCH] D122179: Serialize PragmaAssumeNonNullLoc to support preambles

2022-03-23 Thread Sam McCall via Phabricator via cfe-commits
sammccall added inline comments.



Comment at: clang/lib/Lex/PPLexerChange.cpp:436
+  if (PragmaAssumeNonNullLoc.isValid() && !this->PPOpts->GeneratePreamble &&
+  !(CurLexer && CurLexer->getFileID() == PredefinesFileID) &&
   !isEndOfMacro && !(CurLexer && CurLexer->Is_PragmaLexer)) {

dgoldman wrote:
> sammccall wrote:
> > sammccall wrote:
> > > dgoldman wrote:
> > > > sammccall wrote:
> > > > > dgoldman wrote:
> > > > > > sammccall wrote:
> > > > > > > what's the PredefinesFileID special case about?
> > > > > > See ExitedFromPredefinesFile below, this is how I check if we're 
> > > > > > falling off the end of the preamble region into the main file (same 
> > > > > > as done for the conditional stack), LMK if there's a better way.
> > > > > I don't understand how this checks if we're falling off the preamble 
> > > > > region, and the code around ExitedFromPredefinesFile doesn't clarify 
> > > > > this for me. Can you explain?
> > > > > 
> > > > > The `if (ExitedFromPredefinesFile)` appears to be handling the 
> > > > > logical *insertion* of preamble PP events when *consuming* a 
> > > > > preamble, which is not what you're trying to do here.
> > > > > 
> > > > > The condition here is of the form "if we have an open pragma, and 
> > > > > we're not generating a preamble, and some other stuff, then 
> > > > > diagnose". So if the baseline case is "diagnose" and the preamble 
> > > > > case is an exception, the "other stuff" clauses don't limit the 
> > > > > preamble exception, they add extra exceptions!
> > > > `!(CurLexer && CurLexer->getFileID() == PredefinesFileID)` makes sure 
> > > > that if we're consuming the preamble, we don't emit the warning. AFAICT 
> > > > this is the way to tell that the preamble is terminated, since the 
> > > > current file ID being processed is the predefines file and the file is 
> > > > now terminated as of this method call (since !isEndOfMacro && 
> > > > !(CurLexer && CurLexer->Is_PragmaLexer)). 
> > > > `!this->PPOpts->GeneratePreamble` makes sure that if we're generating 
> > > > the preamble, we don't emit the warning. We need to special case both 
> > > > cases otherwise we get an error when generating the preamble or when we 
> > > > load the preamble before even processing the rest of the main file.
> > > > 
> > > > Does that makes sense? 
> > > > !(CurLexer && CurLexer->getFileID() == PredefinesFileID) makes sure 
> > > > that if we're consuming the preamble, we don't emit the warning
> > > 
> > > 1) if we're consuming the preamble, what exactly is the sequence of 
> > > events that would otherwise lead us to emit the warning?
> > > 2) what if we're in the predefines file for some other reason instead?
> > > 
> > > I'm hoping you'll explain to me what you think the predefines file is, 
> > > and what its relationship to the preamble is, and so why this condition 
> > > is correct :-)
> > > 
> > > My understanding (which is pretty shaky!) is that the predefines file is 
> > > a kind of catchall used to inject text into the preprocessor that doesn't 
> > > appear in the source file - that it contains definitions of builtin 
> > > integer types, macros defined by `-D` on the command line, and so on. If 
> > > it has any relationship to the preamble, it's something subtle that's to 
> > > do with the relative order in which the preprocessor sees entities like 
> > > the predefines, the preprocesor, and the main file.
> > > So according to my understanding, interpreting "reaching EOF in the 
> > > predefines file" as "consuming a preamble" is either wrong or something 
> > > very subtle requiring a significant comment.
> > > 
> > > The code you refer to below is doing something very different: it's 
> > > saying that if we have a preamble, then reaching the end of the 
> > > predefines file is the *trigger* to inject state from it!
> > > 
> > > > !this->PPOpts->GeneratePreamble makes sure that if we're generating the 
> > > > preamble, we don't emit the warning
> > > 
> > > Sure, but that doesn't sound correct at all! A preamble mostly consists 
> > > of parsing a lot of headers, and if any of those headers have an unpaired 
> > > pragma, we should be warning on that at EOF. It's only if we hit the 
> > > "pretend" EOF from the truncated main file that we want to suppress the 
> > > warning.
> > > the preprocessor sees entities like the predefines, the preprocesor, and 
> > > the main file.
> > Oops... sees the predefines, any injected events from the preamble, and the 
> > main file.
> > 
> I think that definition is correct, but given that there is only one 
> predefines file, when it ends, it must go into the main file, no? And if we 
> have a pragma assume nonnull loc, it shouldn't be from the clang builtins, it 
> should be from the preamble (I'd certainly hope!)
> 
> re: headers, I think there might be a misunderstanding, as soon as an 
> #include is seen the pragma is ended here: 
> 

[PATCH] D122335: [clang] Emit crash reproduction as a single tar file

2022-03-23 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D122335#3403459 , @erichkeane 
wrote:

> In D122335#3403453 , @aaron.ballman 
> wrote:
>
>> In D122335#3403357 , @erichkeane 
>> wrote:
>>
>>> In D122335#3403305 , 
>>> @aaron.ballman wrote:
>>>
 In D122335#3403283 , @abrachet 
 wrote:

> In D122335#3403281 , 
> @hubert.reinterpretcast wrote:
>
>> For users on Windows, would this cause extra trouble if they wanted to 
>> see what was included?
>
> Is `tar(1)` not available on Windows?

 It's available on Windows 10 and later by default, but otherwise .zip is 
 the native archive format on Windows.
>>>
>>> We DO support older versions of Windows (Windows Server 2003 is still quite 
>>> popular!), so presumably this requirement wouldn't be particularly 
>>> acceptable.
>>
>> My feeling is: we have a TAR file writer, we don't have a ZIP file writer. 
>> While it'd be nice for us to produce zip files as those are more widely 
>> supported on all the platforms Clang runs on, it's a pretty heavy lift for 
>> this feature, especially given that newer versions of Windows come with a 
>> sufficiently useful tar program to handle them. So I'm fine with us 
>> producing TAR files -- if we decide to add support for ZIP in the future, we 
>> can allow the user to pick via a command line flag (or we could pick based 
>> on the host platform) and we can set the default behavior of Clang with a 
>> CMake flag.
>
> Ah! I took the tests using 'tar' directly to mean we were offloading this 
> work to 'tar', not that we had our own implementation of 'tar'.  In that 
> case, I am ok with that as well; the burden is only on compiler-engineers to 
> have a copy of 'tar' on their windows machine which is a requirement I'm OK 
> with making.

Yup, I'm okay with that compiler engineer requirement; I think our existing 
requirements on Windows already pull in a useful `tar` program even though it 
doesn't seem like we have any tests relying on it being installed yet.


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

https://reviews.llvm.org/D122335

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


[PATCH] D122248: [clang][CodeGen]Fix clang crash and add bitfield support in __builtin_dump_struct

2022-03-23 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added a comment.

If it is ok, I think we should probably change the format of the 'dump' for 
fields.  Using the colon to split up the field from the value is unfortunate, 
may I suggest replacing it with '=' instead?  As well as printing the size 
after a colon.  So for:

  void foo(void) {
struct Bar {
  unsigned c : 1;
  unsigned : 3;
  unsigned : 0;
  unsigned b;
};
  
struct Bar a = {
  .c = 1,
  .b = 2022,
};
  
__builtin_dump_struct(, );
  }

Output:

  struct Bar {
  unsigned int c : 1 = 1
  unsigned int : 3  = 0
  unsigned int : 0 = 
  unsigned int b = 2022
  }

What do you all think?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122248

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


[PATCH] D122341: Fix a crash with variably-modified parameter types in a naked function

2022-03-23 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman created this revision.
aaron.ballman added reviewers: erichkeane, efriedma, jyknight, rjmccall.
Herald added a project: All.
aaron.ballman requested review of this revision.
Herald added a project: clang.

Naked functions have no prolog, so it's not valid to emit prolog code to 
evaluate the variably-modified type. This fixes Issue 50541.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D122341

Files:
  clang/docs/ReleaseNotes.rst
  clang/lib/CodeGen/CodeGenFunction.cpp
  clang/test/CodeGen/attr-naked.c


Index: clang/test/CodeGen/attr-naked.c
===
--- clang/test/CodeGen/attr-naked.c
+++ clang/test/CodeGen/attr-naked.c
@@ -23,5 +23,14 @@
 // CHECK: unreachable
 }
 
+// Make sure naked functions do not attempt to evaluate parameters with a
+// variably-modified type. Naked functions get no prolog, so this evaluation
+// should not take place.
+__attribute__((naked)) void t4(int len, char x[len]) {
+  // CHECK: define{{.*}} void @t4(i32 noundef %0, i8* noundef %1)
+  // CHECK-NEXT: entry:
+  // CHECK-NEXT: unreachable
+}
+
 // CHECK: attributes [[NAKED_OPTNONE]] = { naked noinline nounwind 
optnone{{.*}} }
 // CHECK: attributes [[NAKED]] = { naked noinline nounwind{{.*}} }
Index: clang/lib/CodeGen/CodeGenFunction.cpp
===
--- clang/lib/CodeGen/CodeGenFunction.cpp
+++ clang/lib/CodeGen/CodeGenFunction.cpp
@@ -1194,27 +1194,29 @@
   }
 
   // If any of the arguments have a variably modified type, make sure to
-  // emit the type size.
-  for (FunctionArgList::const_iterator i = Args.begin(), e = Args.end();
-   i != e; ++i) {
-const VarDecl *VD = *i;
-
-// Dig out the type as written from ParmVarDecls; it's unclear whether
-// the standard (C99 6.9.1p10) requires this, but we're following the
-// precedent set by gcc.
-QualType Ty;
-if (const ParmVarDecl *PVD = dyn_cast(VD))
-  Ty = PVD->getOriginalType();
-else
-  Ty = VD->getType();
+  // emit the type size, but only if the function is not naked. Naked functions
+  // have no prolog to run this evaluation.
+  if (!FD || !FD->hasAttr()) {
+for (FunctionArgList::const_iterator i = Args.begin(), e = Args.end();
+ i != e; ++i) {
+  const VarDecl *VD = *i;
+
+  // Dig out the type as written from ParmVarDecls; it's unclear whether
+  // the standard (C99 6.9.1p10) requires this, but we're following the
+  // precedent set by gcc.
+  QualType Ty;
+  if (const ParmVarDecl *PVD = dyn_cast(VD))
+Ty = PVD->getOriginalType();
+  else
+Ty = VD->getType();
 
-if (Ty->isVariablyModifiedType())
-  EmitVariablyModifiedType(Ty);
+  if (Ty->isVariablyModifiedType())
+EmitVariablyModifiedType(Ty);
+}
   }
   // Emit a location at the end of the prologue.
   if (CGDebugInfo *DI = getDebugInfo())
 DI->EmitLocation(Builder, StartLoc);
-
   // TODO: Do we need to handle this in two places like we do with
   // target-features/target-cpu?
   if (CurFuncDecl)
Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -72,10 +72,12 @@
 - Previously invalid member variables with template parameters would crash 
clang.
   Now fixed by setting identifiers for them.
   This fixes `Issue 28475 (PR28101) 
`_.
-
 - Now allow the `restrict` and `_Atomic` qualifiers to be used in conjunction
   with `__auto_type` to match the behavior in GCC. This fixes
   `Issue 53652 `_.
+- No longer crash when specifying a variably-modified parameter type in a
+  function with the ``naked`` attribute. This fixes
+  `Issue 50541 `_.
 
 
 Improvements to Clang's diagnostics


Index: clang/test/CodeGen/attr-naked.c
===
--- clang/test/CodeGen/attr-naked.c
+++ clang/test/CodeGen/attr-naked.c
@@ -23,5 +23,14 @@
 // CHECK: unreachable
 }
 
+// Make sure naked functions do not attempt to evaluate parameters with a
+// variably-modified type. Naked functions get no prolog, so this evaluation
+// should not take place.
+__attribute__((naked)) void t4(int len, char x[len]) {
+  // CHECK: define{{.*}} void @t4(i32 noundef %0, i8* noundef %1)
+  // CHECK-NEXT: entry:
+  // CHECK-NEXT: unreachable
+}
+
 // CHECK: attributes [[NAKED_OPTNONE]] = { naked noinline nounwind optnone{{.*}} }
 // CHECK: attributes [[NAKED]] = { naked noinline nounwind{{.*}} }
Index: clang/lib/CodeGen/CodeGenFunction.cpp
===
--- clang/lib/CodeGen/CodeGenFunction.cpp
+++ clang/lib/CodeGen/CodeGenFunction.cpp
@@ -1194,27 +1194,29 @@
   }
 
   // If any of the arguments have a variably 

[PATCH] D119788: [AArch64] Add support for -march=native for Apple M1 CPU

2022-03-23 Thread Ahmed Bougacha via Phabricator via cfe-commits
ab accepted this revision.
ab added a comment.
This revision is now accepted and ready to land.

Reading this again, I have a feeling defaulting to newest will come back to 
bite us (or, well, apple folks.)   But we can reevaluate if we get to that.  
So, LGTM, thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119788

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


[PATCH] D122248: [clang][CodeGen]Fix clang crash and add bitfield support in __builtin_dump_struct

2022-03-23 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added a comment.

In D122248#3403636 , @yihanaa wrote:

> In D122248#3403518 , @aaron.ballman 
> wrote:
>
>> In D122248#3403478 , @erichkeane 
>> wrote:
>>
>>> If it is ok, I think we should probably change the format of the 'dump' for 
>>> fields.  Using the colon to split up the field from the value is 
>>> unfortunate, may I suggest replacing it with '=' instead?  As well as 
>>> printing the size after a colon.  So for:
>>>
>>>   void foo(void) {
>>> struct Bar {
>>>   unsigned c : 1;
>>>   unsigned : 3;
>>>   unsigned : 0;
>>>   unsigned b;
>>> };
>>>   
>>> struct Bar a = {
>>>   .c = 1,
>>>   .b = 2022,
>>> };
>>>   
>>> __builtin_dump_struct(, );
>>>   }
>>>
>>> Output:
>>>
>>>   struct Bar {
>>>   unsigned int c : 1 = 1
>>>   unsigned int : 3  = 0
>>>   unsigned int : 0 = 
>>>   unsigned int b = 2022
>>>   }
>>>
>>> What do you all think?
>>
>> I think that's a good idea for clarity. For the case where we have no value, 
>> I wonder if we want to do something like: `unsigned int : 0 = 
>> ` (or something else to make it exceptionally clear that 
>> there's nothing missing after the `=`)?
>
> how
>
> In D122248#3403518 , @aaron.ballman 
> wrote:
>
>> In D122248#3403478 , @erichkeane 
>> wrote:
>>
>>> If it is ok, I think we should probably change the format of the 'dump' for 
>>> fields.  Using the colon to split up the field from the value is 
>>> unfortunate, may I suggest replacing it with '=' instead?  As well as 
>>> printing the size after a colon.  So for:
>>>
>>>   void foo(void) {
>>> struct Bar {
>>>   unsigned c : 1;
>>>   unsigned : 3;
>>>   unsigned : 0;
>>>   unsigned b;
>>> };
>>>   
>>> struct Bar a = {
>>>   .c = 1,
>>>   .b = 2022,
>>> };
>>>   
>>> __builtin_dump_struct(, );
>>>   }
>>>
>>> Output:
>>>
>>>   struct Bar {
>>>   unsigned int c : 1 = 1
>>>   unsigned int : 3  = 0
>>>   unsigned int : 0 = 
>>>   unsigned int b = 2022
>>>   }
>>>
>>> What do you all think?
>>
>> I think that's a good idea for clarity. For the case where we have no value, 
>> I wonder if we want to do something like: `unsigned int : 0 = 
>> ` (or something else to make it exceptionally clear that 
>> there's nothing missing after the `=`)?
>
> How to judge whether this field is initialized? Maybe this memory has been 
> initialized by memset

He means a special-case for the 0-size bitfield, which HAS no value (actually, 
wonder if this is a problem with the no-unique-address types as well?).  I 
might suggest `N/A` instead of `uninitialized`, but am open to bikeshedding.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122248

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


[PATCH] D122077: [InstCombine] Fold (ctpop(X) == 1) | (X == 0) into ctpop(X) < 2

2022-03-23 Thread Hirochika Matsumoto via Phabricator via cfe-commits
hkmatsumoto marked 3 inline comments as done.
hkmatsumoto added inline comments.



Comment at: llvm/lib/Transforms/InstCombine/InstCombineAndOrXor.cpp:921
+  if (IsAnd &&
+  match(Cmp0, m_ICmp(Pred0, m_Intrinsic(m_Value(X)),
+ m_SpecificInt(1))) &&

craig.topper wrote:
> Since the m_ICmp matches are the same for And/Or can we share those and 
> possibly early out from the function if they don't match. Then only use 
> `IsAnd` to check the predicates and control the what we emit?
You are definitely right! Changed accordingly.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122077

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


[PATCH] D122248: [clang][CodeGen]Fix clang crash and add bitfield support in __builtin_dump_struct

2022-03-23 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added a comment.

> I'm sorry I misunderstood what you meant @aaron.ballman.
>
> Can we follow the lead of LLVM IR?it use 'undef'
> for example:
>
>   struct T6A {
>   unsigned a : 1;
>   unsigned  : 0;
>   unsigned c : 1;
>   };
>   
>   @__const.foo.a = private unnamed_addr constant %struct.T6A { i8 1, [3 x i8] 
> undef, i8 1, [3 x i8] undef }, align 4

I misunderstood him too, he told me off line :)

I guess I would be 'ok' with `undef`, though that has a different meaning (it 
means, this has an arbitrary value).  In this case, it has NO value, which is 
somewhat different.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122248

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


[PATCH] D121765: [CUDA][HIP] Fix hostness check with -fopenmp

2022-03-23 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith accepted this revision.
rsmith added inline comments.
This revision is now accepted and ready to land.



Comment at: clang/include/clang/Sema/Sema.h:3325-3330
+  /// getCurFunctionDecl - If parsing a lambda, then return the lambda
+  /// declaration if \p AllowLambda is true, otherwise return the function
+  /// declaration enclosing the lambda. If in 'block' context, return the
+  /// enclosing function or lambda declaration if \p AllowLambda is true,
+  /// otherwise return the enclosing function declaration. For regular
+  /// functions, return the function declarations.

This comment would be clearer if it started with the common case and then 
explains any special cases. We also prefer to not include the function name at 
the start of the comment, so that should be removed when updating a function 
comment. It's also possible for a (member) function to be nested within a 
lambda, so I don't think it's correct that we will return the lambda whenever 
we're parsing one. Also, talking about "parsing" isn't right during template 
instantiation.

Maybe: "Returns a pointer to the innermost enclosing function, or `nullptr` if 
the current context is not inside a function. If \p AllowLambda is true, this 
can return the call operator of an enclosing lambda, otherwise lambdas are 
skipped when looking for an enclosing function."



Comment at: clang/test/CodeGenCUDA/openmp-parallel.cu:10
+// Check foo resolves to the host function.
+// CHECK-LABLE: define {{.*}}@_Z5test1v
+// CHECK: call void @_Z3food(double noundef 1.00e+00)





Comment at: clang/test/CodeGenCUDA/openmp-parallel.cu:19
+// Check foo resolves to the host function.
+// CHECK-LABLE: define {{.*}}@_Z5test2v
+// CHECK: call void @_Z3food(double noundef 1.00e+00)




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

https://reviews.llvm.org/D121765

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


[PATCH] D119788: [AArch64] Add support for -march=native for Apple M1 CPU

2022-03-23 Thread Keith Smiley via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGfcca10c69aaa: [AArch64] Add support for -march=native for 
Apple M1 CPU (authored by keith).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119788

Files:
  clang/lib/Driver/ToolChains/Arch/AArch64.cpp
  llvm/lib/Support/Host.cpp

Index: llvm/lib/Support/Host.cpp
===
--- llvm/lib/Support/Host.cpp
+++ llvm/lib/Support/Host.cpp
@@ -41,6 +41,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #endif
 #ifdef _AIX
 #include 
@@ -1297,32 +1299,45 @@
   bool HaveVectorSupport = CVT[244] & 0x80;
   return getCPUNameFromS390Model(Id, HaveVectorSupport);
 }
-#elif defined(__APPLE__) && defined(__aarch64__)
-StringRef sys::getHostCPUName() {
-  return "cyclone";
-}
-#elif defined(__APPLE__) && defined(__arm__)
-StringRef sys::getHostCPUName() {
-  host_basic_info_data_t hostInfo;
-  mach_msg_type_number_t infoCount;
+#elif defined(__APPLE__) && (defined(__arm__) || defined(__aarch64__))
+#define CPUFAMILY_ARM_SWIFT 0x1e2d6381
+#define CPUFAMILY_ARM_CYCLONE 0x37a09642
+#define CPUFAMILY_ARM_TYPHOON 0x2c91a47e
+#define CPUFAMILY_ARM_TWISTER 0x92fb37c8
+#define CPUFAMILY_ARM_HURRICANE 0x67ceee93
+#define CPUFAMILY_ARM_MONSOON_MISTRAL 0xe81e7ef6
+#define CPUFAMILY_ARM_VORTEX_TEMPEST 0x07d34b9f
+#define CPUFAMILY_ARM_LIGHTNING_THUNDER 0x462504d2
+#define CPUFAMILY_ARM_FIRESTORM_ICESTORM 0x1b588bb3
 
-  infoCount = HOST_BASIC_INFO_COUNT;
-  mach_port_t hostPort = mach_host_self();
-  host_info(hostPort, HOST_BASIC_INFO, (host_info_t),
-);
-  mach_port_deallocate(mach_task_self(), hostPort);
+StringRef sys::getHostCPUName() {
+  uint32_t Family;
+  size_t Length = sizeof(Family);
+  sysctlbyname("hw.cpufamily", , , NULL, 0);
 
-  if (hostInfo.cpu_type != CPU_TYPE_ARM) {
-assert(false && "CPUType not equal to ARM should not be possible on ARM");
-return "generic";
+  switch (Family) {
+  case CPUFAMILY_ARM_SWIFT:
+return "swift";
+  case CPUFAMILY_ARM_CYCLONE:
+return "apple-a7";
+  case CPUFAMILY_ARM_TYPHOON:
+return "apple-a8";
+  case CPUFAMILY_ARM_TWISTER:
+return "apple-a9";
+  case CPUFAMILY_ARM_HURRICANE:
+return "apple-a10";
+  case CPUFAMILY_ARM_MONSOON_MISTRAL:
+return "apple-a11";
+  case CPUFAMILY_ARM_VORTEX_TEMPEST:
+return "apple-a12";
+  case CPUFAMILY_ARM_LIGHTNING_THUNDER:
+return "apple-a13";
+  case CPUFAMILY_ARM_FIRESTORM_ICESTORM:
+return "apple-m1";
+  default:
+// Default to the newest CPU we know about.
+return "apple-m1";
   }
-  switch (hostInfo.cpu_subtype) {
-case CPU_SUBTYPE_ARM_V7S:
-  return "swift";
-default:;
-}
-
-  return "generic";
 }
 #elif defined(_AIX)
 StringRef sys::getHostCPUName() {
@@ -1453,9 +1468,6 @@
 #elif defined(__linux__) && defined(__s390x__)
 int computeHostNumPhysicalCores() { return sysconf(_SC_NPROCESSORS_ONLN); }
 #elif defined(__APPLE__)
-#include 
-#include 
-
 // Gets the number of *physical cores* on the machine.
 int computeHostNumPhysicalCores() {
   uint32_t count;
Index: clang/lib/Driver/ToolChains/Arch/AArch64.cpp
===
--- clang/lib/Driver/ToolChains/Arch/AArch64.cpp
+++ clang/lib/Driver/ToolChains/Arch/AArch64.cpp
@@ -151,6 +151,8 @@
   std::pair Split = StringRef(MarchLowerCase).split("+");
 
   llvm::AArch64::ArchKind ArchKind = llvm::AArch64::parseArch(Split.first);
+  if (Split.first == "native")
+ArchKind = llvm::AArch64::getCPUArchKind(llvm::sys::getHostCPUName().str());
   if (ArchKind == llvm::AArch64::ArchKind::INVALID ||
   !llvm::AArch64::getArchFeatures(ArchKind, Features))
 return false;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] fcca10c - [AArch64] Add support for -march=native for Apple M1 CPU

2022-03-23 Thread Keith Smiley via cfe-commits

Author: Keith Smiley
Date: 2022-03-23T14:06:59-07:00
New Revision: fcca10c69aaab539962d10fcc59a5f074b73b0de

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

LOG: [AArch64] Add support for -march=native for Apple M1 CPU

This improves the getHostCPUName check for Apple M1 CPUs, which
previously would always be considered cyclone instead. This also enables
`-march=native` support when building on M1 CPUs which would previously
fail. This isn't as sophisticated as the X86 CPU feature checking which
consults the CPU via getHostCPUFeatures, but this is still better than
before. This CPU selection could also be invalid if this was run on an
iOS device instead, ideally we can improve those cases as they come up.

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

Added: 


Modified: 
clang/lib/Driver/ToolChains/Arch/AArch64.cpp
llvm/lib/Support/Host.cpp

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Arch/AArch64.cpp 
b/clang/lib/Driver/ToolChains/Arch/AArch64.cpp
index 610c672feb677..a0be30f881e52 100644
--- a/clang/lib/Driver/ToolChains/Arch/AArch64.cpp
+++ b/clang/lib/Driver/ToolChains/Arch/AArch64.cpp
@@ -151,6 +151,8 @@ getAArch64ArchFeaturesFromMarch(const Driver , StringRef 
March,
   std::pair Split = StringRef(MarchLowerCase).split("+");
 
   llvm::AArch64::ArchKind ArchKind = llvm::AArch64::parseArch(Split.first);
+  if (Split.first == "native")
+ArchKind = 
llvm::AArch64::getCPUArchKind(llvm::sys::getHostCPUName().str());
   if (ArchKind == llvm::AArch64::ArchKind::INVALID ||
   !llvm::AArch64::getArchFeatures(ArchKind, Features))
 return false;

diff  --git a/llvm/lib/Support/Host.cpp b/llvm/lib/Support/Host.cpp
index a4a375ee7cfa4..31cc4df1d9250 100644
--- a/llvm/lib/Support/Host.cpp
+++ b/llvm/lib/Support/Host.cpp
@@ -41,6 +41,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #endif
 #ifdef _AIX
 #include 
@@ -1297,32 +1299,45 @@ StringRef sys::getHostCPUName() {
   bool HaveVectorSupport = CVT[244] & 0x80;
   return getCPUNameFromS390Model(Id, HaveVectorSupport);
 }
-#elif defined(__APPLE__) && defined(__aarch64__)
-StringRef sys::getHostCPUName() {
-  return "cyclone";
-}
-#elif defined(__APPLE__) && defined(__arm__)
-StringRef sys::getHostCPUName() {
-  host_basic_info_data_t hostInfo;
-  mach_msg_type_number_t infoCount;
+#elif defined(__APPLE__) && (defined(__arm__) || defined(__aarch64__))
+#define CPUFAMILY_ARM_SWIFT 0x1e2d6381
+#define CPUFAMILY_ARM_CYCLONE 0x37a09642
+#define CPUFAMILY_ARM_TYPHOON 0x2c91a47e
+#define CPUFAMILY_ARM_TWISTER 0x92fb37c8
+#define CPUFAMILY_ARM_HURRICANE 0x67ceee93
+#define CPUFAMILY_ARM_MONSOON_MISTRAL 0xe81e7ef6
+#define CPUFAMILY_ARM_VORTEX_TEMPEST 0x07d34b9f
+#define CPUFAMILY_ARM_LIGHTNING_THUNDER 0x462504d2
+#define CPUFAMILY_ARM_FIRESTORM_ICESTORM 0x1b588bb3
 
-  infoCount = HOST_BASIC_INFO_COUNT;
-  mach_port_t hostPort = mach_host_self();
-  host_info(hostPort, HOST_BASIC_INFO, (host_info_t),
-);
-  mach_port_deallocate(mach_task_self(), hostPort);
+StringRef sys::getHostCPUName() {
+  uint32_t Family;
+  size_t Length = sizeof(Family);
+  sysctlbyname("hw.cpufamily", , , NULL, 0);
 
-  if (hostInfo.cpu_type != CPU_TYPE_ARM) {
-assert(false && "CPUType not equal to ARM should not be possible on ARM");
-return "generic";
+  switch (Family) {
+  case CPUFAMILY_ARM_SWIFT:
+return "swift";
+  case CPUFAMILY_ARM_CYCLONE:
+return "apple-a7";
+  case CPUFAMILY_ARM_TYPHOON:
+return "apple-a8";
+  case CPUFAMILY_ARM_TWISTER:
+return "apple-a9";
+  case CPUFAMILY_ARM_HURRICANE:
+return "apple-a10";
+  case CPUFAMILY_ARM_MONSOON_MISTRAL:
+return "apple-a11";
+  case CPUFAMILY_ARM_VORTEX_TEMPEST:
+return "apple-a12";
+  case CPUFAMILY_ARM_LIGHTNING_THUNDER:
+return "apple-a13";
+  case CPUFAMILY_ARM_FIRESTORM_ICESTORM:
+return "apple-m1";
+  default:
+// Default to the newest CPU we know about.
+return "apple-m1";
   }
-  switch (hostInfo.cpu_subtype) {
-case CPU_SUBTYPE_ARM_V7S:
-  return "swift";
-default:;
-}
-
-  return "generic";
 }
 #elif defined(_AIX)
 StringRef sys::getHostCPUName() {
@@ -1453,9 +1468,6 @@ int computeHostNumPhysicalCores() {
 #elif defined(__linux__) && defined(__s390x__)
 int computeHostNumPhysicalCores() { return sysconf(_SC_NPROCESSORS_ONLN); }
 #elif defined(__APPLE__)
-#include 
-#include 
-
 // Gets the number of *physical cores* on the machine.
 int computeHostNumPhysicalCores() {
   uint32_t count;



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


[PATCH] D122338: [OPENMP] Eliminate extra set of simd variant function attribute.

2022-03-23 Thread Jennifer Yu via Phabricator via cfe-commits
jyu2 updated this revision to Diff 417746.
jyu2 edited the summary of this revision.

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

https://reviews.llvm.org/D122338

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


Index: clang/test/OpenMP/declare_simd_codegen.cpp
===
--- clang/test/OpenMP/declare_simd_codegen.cpp
+++ clang/test/OpenMP/declare_simd_codegen.cpp
@@ -153,6 +153,23 @@
 // CHECK-DAG: "_ZGVdN4v__Z5add_1Pf"
 // CHECK-DAG: "_ZGVeN8v__Z5add_1Pf"
 
+// CHECK-NOT: _ZGVbN2vv__Z5add_1Pf
+// CHECK-NOT: _ZGVcN4vv__Z5add_1Pf
+// CHECK-NOT: _ZGVdN4vv__Z5add_1Pf
+// CHECK-NOT: _ZGVeN8vv__Z5add_1Pf
+// CHECK-NOT: _ZGVbM32vv__Z5add_1Pf
+// CHECK-NOT: _ZGVcM32vv__Z5add_1Pf
+// CHECK-NOT: _ZGVdM32vv__Z5add_1Pf
+// CHECK-NOT: _ZGVeM32vv__Z5add_1Pf
+// CHECK-NOT: _ZGVbN4l32v__Z5add_1Pf
+// CHECK-NOT: _ZGVcN8l32v__Z5add_1Pf
+// CHECK-NOT: _ZGVdN8l32v__Z5add_1Pf
+// CHECK-NOT: _ZGVeN16l32v__Z5add_1Pf
+// CHECK-NOT: _ZGVbM4l32v__Z5add_1Pf
+// CHECK-NOT: _ZGVcM8l32v__Z5add_1Pf
+// CHECK-NOT: _ZGVdM8l32v__Z5add_1Pf
+// CHECK-NOT: _ZGVeM16l32v__Z5add_1Pf
+
 // CHECK-DAG: "_ZGVbM2va16va16vv__Z1hIiEvPT_S1_S1_S1_"
 // CHECK-DAG: "_ZGVbN2va16va16vv__Z1hIiEvPT_S1_S1_S1_"
 // CHECK-DAG: "_ZGVcM4va16va16vv__Z1hIiEvPT_S1_S1_S1_"
Index: clang/lib/CodeGen/CGOpenMPRuntime.cpp
===
--- clang/lib/CodeGen/CGOpenMPRuntime.cpp
+++ clang/lib/CodeGen/CGOpenMPRuntime.cpp
@@ -11968,16 +11968,16 @@
   llvm::Function *Fn) {
   ASTContext  = CGM.getContext();
   FD = FD->getMostRecentDecl();
-  // Map params to their positions in function decl.
-  llvm::DenseMap ParamPositions;
-  if (isa(FD))
-ParamPositions.try_emplace(FD, 0);
-  unsigned ParamPos = ParamPositions.size();
-  for (const ParmVarDecl *P : FD->parameters()) {
-ParamPositions.try_emplace(P->getCanonicalDecl(), ParamPos);
-++ParamPos;
-  }
   while (FD) {
+// Map params to their positions in function decl.
+llvm::DenseMap ParamPositions;
+if (isa(FD))
+  ParamPositions.try_emplace(FD, 0);
+unsigned ParamPos = ParamPositions.size();
+for (const ParmVarDecl *P : FD->parameters()) {
+  ParamPositions.try_emplace(P->getCanonicalDecl(), ParamPos);
+  ++ParamPos;
+}
 for (const auto *Attr : FD->specific_attrs()) {
   llvm::SmallVector ParamAttrs(ParamPositions.size());
   // Mark uniform parameters.


Index: clang/test/OpenMP/declare_simd_codegen.cpp
===
--- clang/test/OpenMP/declare_simd_codegen.cpp
+++ clang/test/OpenMP/declare_simd_codegen.cpp
@@ -153,6 +153,23 @@
 // CHECK-DAG: "_ZGVdN4v__Z5add_1Pf"
 // CHECK-DAG: "_ZGVeN8v__Z5add_1Pf"
 
+// CHECK-NOT: _ZGVbN2vv__Z5add_1Pf
+// CHECK-NOT: _ZGVcN4vv__Z5add_1Pf
+// CHECK-NOT: _ZGVdN4vv__Z5add_1Pf
+// CHECK-NOT: _ZGVeN8vv__Z5add_1Pf
+// CHECK-NOT: _ZGVbM32vv__Z5add_1Pf
+// CHECK-NOT: _ZGVcM32vv__Z5add_1Pf
+// CHECK-NOT: _ZGVdM32vv__Z5add_1Pf
+// CHECK-NOT: _ZGVeM32vv__Z5add_1Pf
+// CHECK-NOT: _ZGVbN4l32v__Z5add_1Pf
+// CHECK-NOT: _ZGVcN8l32v__Z5add_1Pf
+// CHECK-NOT: _ZGVdN8l32v__Z5add_1Pf
+// CHECK-NOT: _ZGVeN16l32v__Z5add_1Pf
+// CHECK-NOT: _ZGVbM4l32v__Z5add_1Pf
+// CHECK-NOT: _ZGVcM8l32v__Z5add_1Pf
+// CHECK-NOT: _ZGVdM8l32v__Z5add_1Pf
+// CHECK-NOT: _ZGVeM16l32v__Z5add_1Pf
+
 // CHECK-DAG: "_ZGVbM2va16va16vv__Z1hIiEvPT_S1_S1_S1_"
 // CHECK-DAG: "_ZGVbN2va16va16vv__Z1hIiEvPT_S1_S1_S1_"
 // CHECK-DAG: "_ZGVcM4va16va16vv__Z1hIiEvPT_S1_S1_S1_"
Index: clang/lib/CodeGen/CGOpenMPRuntime.cpp
===
--- clang/lib/CodeGen/CGOpenMPRuntime.cpp
+++ clang/lib/CodeGen/CGOpenMPRuntime.cpp
@@ -11968,16 +11968,16 @@
   llvm::Function *Fn) {
   ASTContext  = CGM.getContext();
   FD = FD->getMostRecentDecl();
-  // Map params to their positions in function decl.
-  llvm::DenseMap ParamPositions;
-  if (isa(FD))
-ParamPositions.try_emplace(FD, 0);
-  unsigned ParamPos = ParamPositions.size();
-  for (const ParmVarDecl *P : FD->parameters()) {
-ParamPositions.try_emplace(P->getCanonicalDecl(), ParamPos);
-++ParamPos;
-  }
   while (FD) {
+// Map params to their positions in function decl.
+llvm::DenseMap ParamPositions;
+if (isa(FD))
+  ParamPositions.try_emplace(FD, 0);
+unsigned ParamPos = ParamPositions.size();
+for (const ParmVarDecl *P : FD->parameters()) {
+  ParamPositions.try_emplace(P->getCanonicalDecl(), ParamPos);
+  ++ParamPos;
+}
 for (const auto *Attr : FD->specific_attrs()) {
   llvm::SmallVector ParamAttrs(ParamPositions.size());
   // Mark uniform parameters.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] fc3cdd0 - Revert "[AArch64] Add support for -march=native for Apple M1 CPU"

2022-03-23 Thread Keith Smiley via cfe-commits

Author: Keith Smiley
Date: 2022-03-23T14:27:02-07:00
New Revision: fc3cdd0b295a04c38f01b391ae414553963e33b9

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

LOG: Revert "[AArch64] Add support for -march=native for Apple M1 CPU"

This reverts commit fcca10c69aaab539962d10fcc59a5f074b73b0de.

Added: 


Modified: 
clang/lib/Driver/ToolChains/Arch/AArch64.cpp
llvm/lib/Support/Host.cpp

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Arch/AArch64.cpp 
b/clang/lib/Driver/ToolChains/Arch/AArch64.cpp
index a0be30f881e52..610c672feb677 100644
--- a/clang/lib/Driver/ToolChains/Arch/AArch64.cpp
+++ b/clang/lib/Driver/ToolChains/Arch/AArch64.cpp
@@ -151,8 +151,6 @@ getAArch64ArchFeaturesFromMarch(const Driver , StringRef 
March,
   std::pair Split = StringRef(MarchLowerCase).split("+");
 
   llvm::AArch64::ArchKind ArchKind = llvm::AArch64::parseArch(Split.first);
-  if (Split.first == "native")
-ArchKind = 
llvm::AArch64::getCPUArchKind(llvm::sys::getHostCPUName().str());
   if (ArchKind == llvm::AArch64::ArchKind::INVALID ||
   !llvm::AArch64::getArchFeatures(ArchKind, Features))
 return false;

diff  --git a/llvm/lib/Support/Host.cpp b/llvm/lib/Support/Host.cpp
index 31cc4df1d9250..a4a375ee7cfa4 100644
--- a/llvm/lib/Support/Host.cpp
+++ b/llvm/lib/Support/Host.cpp
@@ -41,8 +41,6 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #endif
 #ifdef _AIX
 #include 
@@ -1299,45 +1297,32 @@ StringRef sys::getHostCPUName() {
   bool HaveVectorSupport = CVT[244] & 0x80;
   return getCPUNameFromS390Model(Id, HaveVectorSupport);
 }
-#elif defined(__APPLE__) && (defined(__arm__) || defined(__aarch64__))
-#define CPUFAMILY_ARM_SWIFT 0x1e2d6381
-#define CPUFAMILY_ARM_CYCLONE 0x37a09642
-#define CPUFAMILY_ARM_TYPHOON 0x2c91a47e
-#define CPUFAMILY_ARM_TWISTER 0x92fb37c8
-#define CPUFAMILY_ARM_HURRICANE 0x67ceee93
-#define CPUFAMILY_ARM_MONSOON_MISTRAL 0xe81e7ef6
-#define CPUFAMILY_ARM_VORTEX_TEMPEST 0x07d34b9f
-#define CPUFAMILY_ARM_LIGHTNING_THUNDER 0x462504d2
-#define CPUFAMILY_ARM_FIRESTORM_ICESTORM 0x1b588bb3
-
+#elif defined(__APPLE__) && defined(__aarch64__)
 StringRef sys::getHostCPUName() {
-  uint32_t Family;
-  size_t Length = sizeof(Family);
-  sysctlbyname("hw.cpufamily", , , NULL, 0);
+  return "cyclone";
+}
+#elif defined(__APPLE__) && defined(__arm__)
+StringRef sys::getHostCPUName() {
+  host_basic_info_data_t hostInfo;
+  mach_msg_type_number_t infoCount;
 
-  switch (Family) {
-  case CPUFAMILY_ARM_SWIFT:
-return "swift";
-  case CPUFAMILY_ARM_CYCLONE:
-return "apple-a7";
-  case CPUFAMILY_ARM_TYPHOON:
-return "apple-a8";
-  case CPUFAMILY_ARM_TWISTER:
-return "apple-a9";
-  case CPUFAMILY_ARM_HURRICANE:
-return "apple-a10";
-  case CPUFAMILY_ARM_MONSOON_MISTRAL:
-return "apple-a11";
-  case CPUFAMILY_ARM_VORTEX_TEMPEST:
-return "apple-a12";
-  case CPUFAMILY_ARM_LIGHTNING_THUNDER:
-return "apple-a13";
-  case CPUFAMILY_ARM_FIRESTORM_ICESTORM:
-return "apple-m1";
-  default:
-// Default to the newest CPU we know about.
-return "apple-m1";
+  infoCount = HOST_BASIC_INFO_COUNT;
+  mach_port_t hostPort = mach_host_self();
+  host_info(hostPort, HOST_BASIC_INFO, (host_info_t),
+);
+  mach_port_deallocate(mach_task_self(), hostPort);
+
+  if (hostInfo.cpu_type != CPU_TYPE_ARM) {
+assert(false && "CPUType not equal to ARM should not be possible on ARM");
+return "generic";
   }
+  switch (hostInfo.cpu_subtype) {
+case CPU_SUBTYPE_ARM_V7S:
+  return "swift";
+default:;
+}
+
+  return "generic";
 }
 #elif defined(_AIX)
 StringRef sys::getHostCPUName() {
@@ -1468,6 +1453,9 @@ int computeHostNumPhysicalCores() {
 #elif defined(__linux__) && defined(__s390x__)
 int computeHostNumPhysicalCores() { return sysconf(_SC_NPROCESSORS_ONLN); }
 #elif defined(__APPLE__)
+#include 
+#include 
+
 // Gets the number of *physical cores* on the machine.
 int computeHostNumPhysicalCores() {
   uint32_t count;



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


[PATCH] D122278: [clang] Improve diagnostic for reopened inline namespace

2022-03-23 Thread Fabian Wolff via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG528e6eba2f79: [clang] Improve diagnostic for reopened inline 
namespace (authored by fwolff).

Changed prior to commit:
  https://reviews.llvm.org/D122278?vs=417455=417749#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122278

Files:
  clang/docs/ReleaseNotes.rst
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/test/Parser/cxx2a-inline-nested-namespace-definition.cpp
  clang/test/SemaCXX/warn-inline-namespace-reopened-twice.cpp


Index: clang/test/SemaCXX/warn-inline-namespace-reopened-twice.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/warn-inline-namespace-reopened-twice.cpp
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -fsyntax-only -Wall -verify -std=c++11 %s
+
+// Regression test for #50794.
+
+// expected-note@+1 2 {{previous definition is here}}
+inline namespace X {}
+
+namespace X {} // expected-warning {{inline namespace reopened as a non-inline 
namespace}}
+namespace X {} // expected-warning {{inline namespace reopened as a non-inline 
namespace}}
Index: clang/test/Parser/cxx2a-inline-nested-namespace-definition.cpp
===
--- clang/test/Parser/cxx2a-inline-nested-namespace-definition.cpp
+++ clang/test/Parser/cxx2a-inline-nested-namespace-definition.cpp
@@ -17,7 +17,7 @@
 // expected-warning@+2 {{inline nested namespace definition is incompatible 
with C++ standards before C++20}}
 #endif
 namespace valid1::valid2::inline valid3::inline valid4::valid5 {}
-// expected-note@-1 2 {{previous definition is here}}
+// expected-note@-1 4 {{previous definition is here}}
 
 #if __cplusplus <= 201402L
 // expected-warning@+3 {{nested namespace definition is a C++17 extension; 
define each namespace separately}}
@@ -34,7 +34,6 @@
 // expected-warning@+2 {{inline nested namespace definition is incompatible 
with C++ standards before C++20}}
 #endif
 namespace valid1::valid2::inline valid3::inline valid4::valid5 {}
-// expected-note@-1 2 {{previous definition is here}}
 
 namespace valid1 {
 namespace valid2 {
Index: clang/lib/Sema/SemaDeclCXX.cpp
===
--- clang/lib/Sema/SemaDeclCXX.cpp
+++ clang/lib/Sema/SemaDeclCXX.cpp
@@ -11060,6 +11060,11 @@
 NamespaceDecl *PrevNS) {
   assert(*IsInline != PrevNS->isInline());
 
+  // 'inline' must appear on the original definition, but not necessarily
+  // on all extension definitions, so the note should point to the first
+  // definition to avoid confusion.
+  PrevNS = PrevNS->getFirstDecl();
+
   if (PrevNS->isInline())
 // The user probably just forgot the 'inline', so suggest that it
 // be added back.
Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -83,6 +83,11 @@
 - ``-Wliteral-range`` will warn on floating-point equality comparisons with
   constants that are not representable in a casted value. For example,
   ``(float) f == 0.1`` is always false.
+- ``-Winline-namespace-reopened-noninline`` now takes into account that the
+  ``inline`` keyword must appear on the original but not necessarily all
+  extension definitions of an inline namespace and therefore points its note
+  at the original definition. This fixes `Issue 50794 (PR51452)
+  `_.
 
 Non-comprehensive list of changes in this release
 -


Index: clang/test/SemaCXX/warn-inline-namespace-reopened-twice.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/warn-inline-namespace-reopened-twice.cpp
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -fsyntax-only -Wall -verify -std=c++11 %s
+
+// Regression test for #50794.
+
+// expected-note@+1 2 {{previous definition is here}}
+inline namespace X {}
+
+namespace X {} // expected-warning {{inline namespace reopened as a non-inline namespace}}
+namespace X {} // expected-warning {{inline namespace reopened as a non-inline namespace}}
Index: clang/test/Parser/cxx2a-inline-nested-namespace-definition.cpp
===
--- clang/test/Parser/cxx2a-inline-nested-namespace-definition.cpp
+++ clang/test/Parser/cxx2a-inline-nested-namespace-definition.cpp
@@ -17,7 +17,7 @@
 // expected-warning@+2 {{inline nested namespace definition is incompatible with C++ standards before C++20}}
 #endif
 namespace valid1::valid2::inline valid3::inline valid4::valid5 {}
-// expected-note@-1 2 {{previous definition is here}}
+// expected-note@-1 4 {{previous definition is here}}
 
 #if __cplusplus <= 201402L
 // expected-warning@+3 {{nested namespace definition is a 

[clang] 528e6eb - [clang] Improve diagnostic for reopened inline namespace

2022-03-23 Thread Fabian Wolff via cfe-commits

Author: Fabian Wolff
Date: 2022-03-23T22:30:45+01:00
New Revision: 528e6eba2f7906d974594b1fc50362dfad239609

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

LOG: [clang] Improve diagnostic for reopened inline namespace

Reviewed By: cor3ntin, aaron.ballman

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

Added: 
clang/test/SemaCXX/warn-inline-namespace-reopened-twice.cpp

Modified: 
clang/docs/ReleaseNotes.rst
clang/lib/Sema/SemaDeclCXX.cpp
clang/test/Parser/cxx2a-inline-nested-namespace-definition.cpp

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 83d5dbdda2607..373d4156cd797 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -83,6 +83,11 @@ Improvements to Clang's diagnostics
 - ``-Wliteral-range`` will warn on floating-point equality comparisons with
   constants that are not representable in a casted value. For example,
   ``(float) f == 0.1`` is always false.
+- ``-Winline-namespace-reopened-noninline`` now takes into account that the
+  ``inline`` keyword must appear on the original but not necessarily all
+  extension definitions of an inline namespace and therefore points its note
+  at the original definition. This fixes `Issue 50794 (PR51452)
+  `_.
 
 Non-comprehensive list of changes in this release
 -

diff  --git a/clang/lib/Sema/SemaDeclCXX.cpp b/clang/lib/Sema/SemaDeclCXX.cpp
index 7992e4a349611..0b5440c227d1c 100644
--- a/clang/lib/Sema/SemaDeclCXX.cpp
+++ b/clang/lib/Sema/SemaDeclCXX.cpp
@@ -11060,6 +11060,11 @@ static void DiagnoseNamespaceInlineMismatch(Sema , 
SourceLocation KeywordLoc,
 NamespaceDecl *PrevNS) {
   assert(*IsInline != PrevNS->isInline());
 
+  // 'inline' must appear on the original definition, but not necessarily
+  // on all extension definitions, so the note should point to the first
+  // definition to avoid confusion.
+  PrevNS = PrevNS->getFirstDecl();
+
   if (PrevNS->isInline())
 // The user probably just forgot the 'inline', so suggest that it
 // be added back.

diff  --git a/clang/test/Parser/cxx2a-inline-nested-namespace-definition.cpp 
b/clang/test/Parser/cxx2a-inline-nested-namespace-definition.cpp
index f37dc8c033cec..72a0cbf8da8f1 100644
--- a/clang/test/Parser/cxx2a-inline-nested-namespace-definition.cpp
+++ b/clang/test/Parser/cxx2a-inline-nested-namespace-definition.cpp
@@ -17,7 +17,7 @@ inline namespace foo4::foo5::foo6 { // expected-error 
{{nested namespace definit
 // expected-warning@+2 {{inline nested namespace definition is incompatible 
with C++ standards before C++20}}
 #endif
 namespace valid1::valid2::inline valid3::inline valid4::valid5 {}
-// expected-note@-1 2 {{previous definition is here}}
+// expected-note@-1 4 {{previous definition is here}}
 
 #if __cplusplus <= 201402L
 // expected-warning@+3 {{nested namespace definition is a C++17 extension; 
define each namespace separately}}
@@ -34,7 +34,6 @@ namespace valid1::valid2::valid3::valid4::valid5 {}
 // expected-warning@+2 {{inline nested namespace definition is incompatible 
with C++ standards before C++20}}
 #endif
 namespace valid1::valid2::inline valid3::inline valid4::valid5 {}
-// expected-note@-1 2 {{previous definition is here}}
 
 namespace valid1 {
 namespace valid2 {

diff  --git a/clang/test/SemaCXX/warn-inline-namespace-reopened-twice.cpp 
b/clang/test/SemaCXX/warn-inline-namespace-reopened-twice.cpp
new file mode 100644
index 0..ac22280fdf800
--- /dev/null
+++ b/clang/test/SemaCXX/warn-inline-namespace-reopened-twice.cpp
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -fsyntax-only -Wall -verify -std=c++11 %s
+
+// Regression test for #50794.
+
+// expected-note@+1 2 {{previous definition is here}}
+inline namespace X {}
+
+namespace X {} // expected-warning {{inline namespace reopened as a non-inline 
namespace}}
+namespace X {} // expected-warning {{inline namespace reopened as a non-inline 
namespace}}



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


[PATCH] D121451: [clang-format] Add space to comments starting with '#'.

2022-03-23 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay added a comment.

In D121451#3402167 , @curdeius wrote:

> In D121451#3401947 , 
> @MyDeveloperDay wrote:
>
>> I'm a little uncomfortable with
>>
>>   //#
>>
>> becoming
>>
>>   // #
>>
>> At least without an option for it to not make changes
>
> Don't you think that `//#PPdirective` should be indented the same way as 
> other code?
> E.g. in:
>
>   #include 
>   
>   int something;
>
> You comment the whole block and it becomes (with this patch):
>
>   // #include 
>   //
>   // int something;
>
> whereas it was:
>
>   //#include 
>   //
>   // int something;
>
> which seems inconsistent at least.

That makes sense..


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121451

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


[PATCH] D122248: [clang][CodeGen]Fix clang crash and add bitfield support in __builtin_dump_struct

2022-03-23 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D122248#3403349 , @erichkeane 
wrote:

> In D122248#3403343 , @yihanaa wrote:
>
>> In D122248#3403315 , 
>> @aaron.ballman wrote:
>>
>>> In D122248#3403143 , @yihanaa 
>>> wrote:
>>>
 1. Support zero-width bitfield, named bitfield and unnamed bitfield.
 2. Add a release notes.

 The builtin function __builtin_dump_struct behaves for zero-width bitfield 
 and unnamed bitfield as follows

   int printf(const char *fmt, ...);
   
   void foo(void) {
 struct Bar {
   unsigned c : 1;
   unsigned : 3;
   unsigned : 0;
   unsigned b;
 };
   
 struct Bar a = {
   .c = 1,
   .b = 2022,
 };
   
 __builtin_dump_struct(, );
   }
   
   int main() {
 foo();
 return 0;
   }

 Output:

   struct Bar {
   unsigned int c : 1
   unsigned int  : 0
   unsigned int b : 2022
   }
>>>
>>> Thank you for the release note and additional test coverage. I'm wondering 
>>> why we handle the zero-width bit-field differently from the anonymous one 
>>> (e.g., why do we not have `unsigned int : 3` before the `unsigned int : 0`? 
>>> It seems a bit odd to drop that from the output.
>>
>> Thanks, I don't know what the value of this zero-width bitfield should 
>> output, can it be a empty value as same as unnamed-bitfield’ she field name?
>>
>> for example:
>>
>>   struct Bar {
>>   unsigned int c : 1
>>   unsigned int  : 0
>>   unsigned int  :
>>   unsigned int b : 2022
>>   }
>
> I would definitely expect this, yes.

Oh wow... I was seeing the `:` in the output and thinking that was showing me 
the bit width after the colon (given that we show the type information), not 
the value. I wonder how many other folks are tripped up by that sort of thing? 
In the meantime, now that I understand the printing format better, I would 
expect that output as well.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122248

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


[PATCH] D122248: [clang][CodeGen]Fix clang crash and add bitfield support in __builtin_dump_struct

2022-03-23 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added a comment.

In D122248#3403468 , @aaron.ballman 
wrote:

> In D122248#3403349 , @erichkeane 
> wrote:
>
>> In D122248#3403343 , @yihanaa 
>> wrote:
>>
>>> In D122248#3403315 , 
>>> @aaron.ballman wrote:
>>>
 In D122248#3403143 , @yihanaa 
 wrote:

> 1. Support zero-width bitfield, named bitfield and unnamed bitfield.
> 2. Add a release notes.
>
> The builtin function __builtin_dump_struct behaves for zero-width 
> bitfield and unnamed bitfield as follows
>
>   int printf(const char *fmt, ...);
>   
>   void foo(void) {
> struct Bar {
>   unsigned c : 1;
>   unsigned : 3;
>   unsigned : 0;
>   unsigned b;
> };
>   
> struct Bar a = {
>   .c = 1,
>   .b = 2022,
> };
>   
> __builtin_dump_struct(, );
>   }
>   
>   int main() {
> foo();
> return 0;
>   }
>
> Output:
>
>   struct Bar {
>   unsigned int c : 1
>   unsigned int  : 0
>   unsigned int b : 2022
>   }

 Thank you for the release note and additional test coverage. I'm wondering 
 why we handle the zero-width bit-field differently from the anonymous one 
 (e.g., why do we not have `unsigned int : 3` before the `unsigned int : 
 0`? It seems a bit odd to drop that from the output.
>>>
>>> Thanks, I don't know what the value of this zero-width bitfield should 
>>> output, can it be a empty value as same as unnamed-bitfield’ she field name?
>>>
>>> for example:
>>>
>>>   struct Bar {
>>>   unsigned int c : 1
>>>   unsigned int  : 0
>>>   unsigned int  :
>>>   unsigned int b : 2022
>>>   }
>>
>> I would definitely expect this, yes.
>
> Oh wow... I was seeing the `:` in the output and thinking that was showing me 
> the bit width after the colon (given that we show the type information), not 
> the value. I wonder how many other folks are tripped up by that sort of 
> thing? In the meantime, now that I understand the printing format better, I 
> would expect that output as well.

Now that you mention it: SHOULD we emit the size of the bitfield on that line?  
The 'colon' is quite unfortunate there for exactly that reason (the way you 
misread it).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122248

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


[PATCH] D122341: Fix a crash with variably-modified parameter types in a naked function

2022-03-23 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added a comment.

Other than this 1 thing, LGTM.  I DO find myself wondering how much of the 
CXXMethodDecl bit in the branch above is valid for 'naked' as well.  If it 
ISN'T we might consider  moving this loop AND that to EmitFunctionPrologue.




Comment at: clang/lib/CodeGen/CodeGenFunction.cpp:1200
+  if (!FD || !FD->hasAttr()) {
+for (FunctionArgList::const_iterator i = Args.begin(), e = Args.end();
+ i != e; ++i) {

Since you're touching it... this looks like a 'range-for' loop :D 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122341

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


[PATCH] D122179: Serialize PragmaAssumeNonNullLoc to support preambles

2022-03-23 Thread David Goldman via Phabricator via cfe-commits
dgoldman added inline comments.



Comment at: clang/lib/Lex/PPLexerChange.cpp:436
+  if (PragmaAssumeNonNullLoc.isValid() && !this->PPOpts->GeneratePreamble &&
+  !(CurLexer && CurLexer->getFileID() == PredefinesFileID) &&
   !isEndOfMacro && !(CurLexer && CurLexer->Is_PragmaLexer)) {

sammccall wrote:
> sammccall wrote:
> > dgoldman wrote:
> > > sammccall wrote:
> > > > dgoldman wrote:
> > > > > sammccall wrote:
> > > > > > what's the PredefinesFileID special case about?
> > > > > See ExitedFromPredefinesFile below, this is how I check if we're 
> > > > > falling off the end of the preamble region into the main file (same 
> > > > > as done for the conditional stack), LMK if there's a better way.
> > > > I don't understand how this checks if we're falling off the preamble 
> > > > region, and the code around ExitedFromPredefinesFile doesn't clarify 
> > > > this for me. Can you explain?
> > > > 
> > > > The `if (ExitedFromPredefinesFile)` appears to be handling the logical 
> > > > *insertion* of preamble PP events when *consuming* a preamble, which is 
> > > > not what you're trying to do here.
> > > > 
> > > > The condition here is of the form "if we have an open pragma, and we're 
> > > > not generating a preamble, and some other stuff, then diagnose". So if 
> > > > the baseline case is "diagnose" and the preamble case is an exception, 
> > > > the "other stuff" clauses don't limit the preamble exception, they add 
> > > > extra exceptions!
> > > `!(CurLexer && CurLexer->getFileID() == PredefinesFileID)` makes sure 
> > > that if we're consuming the preamble, we don't emit the warning. AFAICT 
> > > this is the way to tell that the preamble is terminated, since the 
> > > current file ID being processed is the predefines file and the file is 
> > > now terminated as of this method call (since !isEndOfMacro && !(CurLexer 
> > > && CurLexer->Is_PragmaLexer)). `!this->PPOpts->GeneratePreamble` makes 
> > > sure that if we're generating the preamble, we don't emit the warning. We 
> > > need to special case both cases otherwise we get an error when generating 
> > > the preamble or when we load the preamble before even processing the rest 
> > > of the main file.
> > > 
> > > Does that makes sense? 
> > > !(CurLexer && CurLexer->getFileID() == PredefinesFileID) makes sure that 
> > > if we're consuming the preamble, we don't emit the warning
> > 
> > 1) if we're consuming the preamble, what exactly is the sequence of events 
> > that would otherwise lead us to emit the warning?
> > 2) what if we're in the predefines file for some other reason instead?
> > 
> > I'm hoping you'll explain to me what you think the predefines file is, and 
> > what its relationship to the preamble is, and so why this condition is 
> > correct :-)
> > 
> > My understanding (which is pretty shaky!) is that the predefines file is a 
> > kind of catchall used to inject text into the preprocessor that doesn't 
> > appear in the source file - that it contains definitions of builtin integer 
> > types, macros defined by `-D` on the command line, and so on. If it has any 
> > relationship to the preamble, it's something subtle that's to do with the 
> > relative order in which the preprocessor sees entities like the predefines, 
> > the preprocesor, and the main file.
> > So according to my understanding, interpreting "reaching EOF in the 
> > predefines file" as "consuming a preamble" is either wrong or something 
> > very subtle requiring a significant comment.
> > 
> > The code you refer to below is doing something very different: it's saying 
> > that if we have a preamble, then reaching the end of the predefines file is 
> > the *trigger* to inject state from it!
> > 
> > > !this->PPOpts->GeneratePreamble makes sure that if we're generating the 
> > > preamble, we don't emit the warning
> > 
> > Sure, but that doesn't sound correct at all! A preamble mostly consists of 
> > parsing a lot of headers, and if any of those headers have an unpaired 
> > pragma, we should be warning on that at EOF. It's only if we hit the 
> > "pretend" EOF from the truncated main file that we want to suppress the 
> > warning.
> > the preprocessor sees entities like the predefines, the preprocesor, and 
> > the main file.
> Oops... sees the predefines, any injected events from the preamble, and the 
> main file.
> 
I think that definition is correct, but given that there is only one predefines 
file, when it ends, it must go into the main file, no? And if we have a pragma 
assume nonnull loc, it shouldn't be from the clang builtins, it should be from 
the preamble (I'd certainly hope!)

re: headers, I think there might be a misunderstanding, as soon as an #include 
is seen the pragma is ended here: 
https://github.com/llvm/llvm-project/blob/7631c366c8589dda488cb7ff1df26cc134002208/clang/lib/Lex/PPDirectives.cpp#L2006,
 so if PragmaAssumeNonNullLoc is valid here we haven't had any includes since 
the pragma was 

[PATCH] D122248: [clang][CodeGen]Fix clang crash and add bitfield support in __builtin_dump_struct

2022-03-23 Thread Wang Yihan via Phabricator via cfe-commits
yihanaa added a comment.

In D122248#3403478 , @erichkeane 
wrote:

> If it is ok, I think we should probably change the format of the 'dump' for 
> fields.  Using the colon to split up the field from the value is unfortunate, 
> may I suggest replacing it with '=' instead?  As well as printing the size 
> after a colon.  So for:
>
>   void foo(void) {
> struct Bar {
>   unsigned c : 1;
>   unsigned : 3;
>   unsigned : 0;
>   unsigned b;
> };
>   
> struct Bar a = {
>   .c = 1,
>   .b = 2022,
> };
>   
> __builtin_dump_struct(, );
>   }
>
> Output:
>
>   struct Bar {
>   unsigned int c : 1 = 1
>   unsigned int : 3  = 0
>   unsigned int : 0 = 
>   unsigned int b = 2022
>   }
>
> What do you all think?

good idea!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122248

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


[clang] 3fb101a - [NFC] Replace a not-null-check && isa with isa_and_nonnull

2022-03-23 Thread Erich Keane via cfe-commits

Author: Erich Keane
Date: 2022-03-23T13:09:28-07:00
New Revision: 3fb101a6914b6d0e7a46b425eeafc44578d7ff78

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

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

Added: 


Modified: 
clang/lib/CodeGen/CodeGenFunction.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CodeGenFunction.cpp 
b/clang/lib/CodeGen/CodeGenFunction.cpp
index 8dc659afc1968..de717439918d7 100644
--- a/clang/lib/CodeGen/CodeGenFunction.cpp
+++ b/clang/lib/CodeGen/CodeGenFunction.cpp
@@ -1133,7 +1133,8 @@ void CodeGenFunction::StartFunction(GlobalDecl GD, 
QualType RetTy,
 
   EmitFunctionProlog(*CurFnInfo, CurFn, Args);
 
-  if (D && isa(D) && cast(D)->isInstance()) {
+  if (isa_and_nonnull(D) &&
+  cast(D)->isInstance()) {
 CGM.getCXXABI().EmitInstanceFunctionProlog(*this);
 const CXXMethodDecl *MD = cast(D);
 if (MD->getParent()->isLambda() &&



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


[PATCH] D120185: [ASTMatchers] Output currently processing match and nodes on crash

2022-03-23 Thread Nathan James via Phabricator via cfe-commits
njames93 added a comment.

In D120185#3403270 , @aaron.ballman 
wrote:

> I'd like to understand what's happening better rather than land with a 
> disabled test. Not getting the crash dump in some circumstances could either 
> be specific to the machine configuration (which would be pretty tricky for us 
> to solve in a unit test) or it could be something functionally wrong with the 
> changes (though I would be surprised, tbh).

From what it looks like on the buildbot, the testing infrastructure wasn't 
recieving any output from stderr.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120185

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


[PATCH] D122248: [clang][CodeGen]Fix clang crash and add bitfield support in __builtin_dump_struct

2022-03-23 Thread Wang Yihan via Phabricator via cfe-commits
yihanaa added a comment.

In D122248#3403637 , @erichkeane 
wrote:

> In D122248#3403636 , @yihanaa wrote:
>
>> In D122248#3403518 , 
>> @aaron.ballman wrote:
>>
>>> In D122248#3403478 , @erichkeane 
>>> wrote:
>>>
 If it is ok, I think we should probably change the format of the 'dump' 
 for fields.  Using the colon to split up the field from the value is 
 unfortunate, may I suggest replacing it with '=' instead?  As well as 
 printing the size after a colon.  So for:

   void foo(void) {
 struct Bar {
   unsigned c : 1;
   unsigned : 3;
   unsigned : 0;
   unsigned b;
 };
   
 struct Bar a = {
   .c = 1,
   .b = 2022,
 };
   
 __builtin_dump_struct(, );
   }

 Output:

   struct Bar {
   unsigned int c : 1 = 1
   unsigned int : 3  = 0
   unsigned int : 0 = 
   unsigned int b = 2022
   }

 What do you all think?
>>>
>>> I think that's a good idea for clarity. For the case where we have no 
>>> value, I wonder if we want to do something like: `unsigned int : 0 = 
>>> ` (or something else to make it exceptionally clear that 
>>> there's nothing missing after the `=`)?
>>
>> how
>>
>> In D122248#3403518 , 
>> @aaron.ballman wrote:
>>
>>> In D122248#3403478 , @erichkeane 
>>> wrote:
>>>
 If it is ok, I think we should probably change the format of the 'dump' 
 for fields.  Using the colon to split up the field from the value is 
 unfortunate, may I suggest replacing it with '=' instead?  As well as 
 printing the size after a colon.  So for:

   void foo(void) {
 struct Bar {
   unsigned c : 1;
   unsigned : 3;
   unsigned : 0;
   unsigned b;
 };
   
 struct Bar a = {
   .c = 1,
   .b = 2022,
 };
   
 __builtin_dump_struct(, );
   }

 Output:

   struct Bar {
   unsigned int c : 1 = 1
   unsigned int : 3  = 0
   unsigned int : 0 = 
   unsigned int b = 2022
   }

 What do you all think?
>>>
>>> I think that's a good idea for clarity. For the case where we have no 
>>> value, I wonder if we want to do something like: `unsigned int : 0 = 
>>> ` (or something else to make it exceptionally clear that 
>>> there's nothing missing after the `=`)?
>>
>> How to judge whether this field is initialized? Maybe this memory has been 
>> initialized by memset
>
> He means a special-case for the 0-size bitfield, which HAS no value 
> (actually, wonder if this is a problem with the no-unique-address types as 
> well?).  I might suggest `N/A` instead of `uninitialized`, but am open to 
> bikeshedding.

I'm sorry, I misunderstood @aaron.ballman.

In D122248#3403637 , @erichkeane 
wrote:

> In D122248#3403636 , @yihanaa wrote:
>
>> In D122248#3403518 , 
>> @aaron.ballman wrote:
>>
>>> In D122248#3403478 , @erichkeane 
>>> wrote:
>>>
 If it is ok, I think we should probably change the format of the 'dump' 
 for fields.  Using the colon to split up the field from the value is 
 unfortunate, may I suggest replacing it with '=' instead?  As well as 
 printing the size after a colon.  So for:

   void foo(void) {
 struct Bar {
   unsigned c : 1;
   unsigned : 3;
   unsigned : 0;
   unsigned b;
 };
   
 struct Bar a = {
   .c = 1,
   .b = 2022,
 };
   
 __builtin_dump_struct(, );
   }

 Output:

   struct Bar {
   unsigned int c : 1 = 1
   unsigned int : 3  = 0
   unsigned int : 0 = 
   unsigned int b = 2022
   }

 What do you all think?
>>>
>>> I think that's a good idea for clarity. For the case where we have no 
>>> value, I wonder if we want to do something like: `unsigned int : 0 = 
>>> ` (or something else to make it exceptionally clear that 
>>> there's nothing missing after the `=`)?
>>
>> how
>>
>> In D122248#3403518 , 
>> @aaron.ballman wrote:
>>
>>> In D122248#3403478 , @erichkeane 
>>> wrote:
>>>
 If it is ok, I think we should probably change the format of the 'dump' 
 for fields.  Using the colon to split up the field from the value is 
 unfortunate, may I suggest replacing it with '=' instead?  As well as 
 printing the size after a colon.  So for:

   void foo(void) {
 struct Bar {
   

[PATCH] D122248: [clang][CodeGen]Fix clang crash and add bitfield support in __builtin_dump_struct

2022-03-23 Thread Wang Yihan via Phabricator via cfe-commits
yihanaa added a comment.

In D122248#3403698 , @erichkeane 
wrote:

>> I'm sorry I misunderstood what you meant @aaron.ballman.
>>
>> Can we follow the lead of LLVM IR?it use 'undef'
>> for example:
>>
>>   struct T6A {
>>   unsigned a : 1;
>>   unsigned  : 0;
>>   unsigned c : 1;
>>   };
>>   
>>   @__const.foo.a = private unnamed_addr constant %struct.T6A { i8 1, [3 x 
>> i8] undef, i8 1, [3 x i8] undef }, align 4
>
> I misunderstood him too, he told me off line :)
>
> I guess I would be 'ok' with `undef`, though that has a different meaning (it 
> means, this has an arbitrary value).  In this case, it has NO value, which is 
> somewhat different.

What if we don't emit '=' for zero-width bitfield, like this:

  struct Bar {
  unsigned c : 1;
  unsigned : 3;
  unsigned : 0;
  unsigned b;
  };
  
  struct Bar {
  unsigned int c : 1 = 0
  unsigned int   : 3 = 0
  unsigned int   : 0
  unsigned int b = 0
  }


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122248

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


[PATCH] D122303: [pseudo] Sort nonterminals based on their reduction order.

2022-03-23 Thread Haojian Wu via Phabricator via cfe-commits
hokein added a comment.

In D122303#3402375 , @sammccall wrote:

> The extraction of TestGrammar seems unrelated to the rest of the patch and it 
> *isn't* actually shared between tests yet, which makes it a bit hard to 
> review.

It is used in our previous Forest patch (not landed yet), but you're probably 
right. I have removed the extraction code in this patch, will send out a 
followup patch for the extraction afterwards.




Comment at: clang-tools-extra/pseudo/lib/GrammarBNF.cpp:55
 };
 for (const auto  : Specs) {
   Consider(Spec.Target);

sammccall wrote:
> You could identify dependencies here, and then use them to sort the 
> uniquenonterminals before  allocating SymbolIDs
not sure I get the your point -- we could move the topological sort here, but 
it doesn't seem to be significantly better compared with the current solution.



Comment at: clang-tools-extra/pseudo/lib/GrammarBNF.cpp:135
+};
+std::vector VisitStates(T->Nonterminals.size(), NotVisited);
+std::function DFS = [&](SymbolID SID) -> void {

sammccall wrote:
> (is a vector of symbol id, or of states?)
oops, it should be the enum State


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122303

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


[clang] 460fc44 - [Clang] -Wunused-but-set-variable warning - handle also pre/post unary operators

2022-03-23 Thread Dávid Bolvanský via cfe-commits

Author: Dávid Bolvanský
Date: 2022-03-23T22:05:36+01:00
New Revision: 460fc440ad8d41ca2e3882987512989b1c188fbe

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

LOG: [Clang] -Wunused-but-set-variable warning - handle also pre/post unary 
operators

Clang fails to diagnose:
```
void test() {
int j = 0;
for (int i = 0; i < 1000; i++)
j++;
return;
}
```

Reason: Missing support for UnaryOperator.

We should not warn with volatile variables... so add check for it.

Reviewed By: efriedma

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

Added: 


Modified: 
clang/lib/Sema/SemaExprCXX.cpp
clang/test/Sema/warn-unused-but-set-variables.c
clang/test/SemaCXX/warn-unused-but-set-variables-cpp.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaExprCXX.cpp b/clang/lib/Sema/SemaExprCXX.cpp
index 8873731cd3d3e..f360dc6e1a236 100644
--- a/clang/lib/Sema/SemaExprCXX.cpp
+++ b/clang/lib/Sema/SemaExprCXX.cpp
@@ -7921,6 +7921,7 @@ static void MaybeDecrementCount(
 Expr *E, llvm::DenseMap ) {
   DeclRefExpr *LHS = nullptr;
   bool IsCompoundAssign = false;
+  bool isIncrementDecrementUnaryOp = false;
   if (BinaryOperator *BO = dyn_cast(E)) {
 if (BO->getLHS()->getType()->isDependentType() ||
 BO->getRHS()->getType()->isDependentType()) {
@@ -7935,6 +7936,11 @@ static void MaybeDecrementCount(
 if (COCE->getOperator() != OO_Equal)
   return;
 LHS = dyn_cast(COCE->getArg(0));
+  } else if (UnaryOperator *UO = dyn_cast(E)) {
+if (!UO->isIncrementDecrementOp())
+  return;
+isIncrementDecrementUnaryOp = true;
+LHS = dyn_cast(UO->getSubExpr());
   }
   if (!LHS)
 return;
@@ -7942,8 +7948,10 @@ static void MaybeDecrementCount(
   if (!VD)
 return;
   // Don't decrement RefsMinusAssignments if volatile variable with compound
-  // assignment (+=, ...) to avoid potential unused-but-set-variable warning.
-  if (IsCompoundAssign && VD->getType().isVolatileQualified())
+  // assignment (+=, ...) or increment/decrement unary operator to avoid
+  // potential unused-but-set-variable warning.
+  if ((IsCompoundAssign || isIncrementDecrementUnaryOp) &&
+  VD->getType().isVolatileQualified())
 return;
   auto iter = RefsMinusAssignments.find(VD);
   if (iter == RefsMinusAssignments.end())

diff  --git a/clang/test/Sema/warn-unused-but-set-variables.c 
b/clang/test/Sema/warn-unused-but-set-variables.c
index 6e5b7d671711b..58104d198084c 100644
--- a/clang/test/Sema/warn-unused-but-set-variables.c
+++ b/clang/test/Sema/warn-unused-but-set-variables.c
@@ -73,3 +73,20 @@ void f3(void) {
   __attribute__((__cleanup__(for_cleanup))) int x;
   x = 5;
 }
+
+void f4(void) {
+  int x1 = 0; // expected-warning{{variable 'x1' set but not used}}
+  x1++;
+  int x2 = 0; // expected-warning{{variable 'x2' set but not used}}
+  x2--;
+  int x3 = 0; // expected-warning{{variable 'x3' set but not used}}
+  ++x3;
+  int x4 = 0; // expected-warning{{variable 'x4' set but not used}}
+  --x4;
+
+  volatile int v1 = 0;
+  ++v1;
+  typedef volatile int volint;
+  volint v2 = 0;
+  v2++;
+}

diff  --git a/clang/test/SemaCXX/warn-unused-but-set-variables-cpp.cpp 
b/clang/test/SemaCXX/warn-unused-but-set-variables-cpp.cpp
index 400e9d7681b31..418baa78aa964 100644
--- a/clang/test/SemaCXX/warn-unused-but-set-variables-cpp.cpp
+++ b/clang/test/SemaCXX/warn-unused-but-set-variables-cpp.cpp
@@ -7,6 +7,7 @@ struct S {
 struct __attribute__((warn_unused)) SWarnUnused {
   int j;
   void operator +=(int);
+  void operator ++();
 };
 
 int f0() {
@@ -62,3 +63,9 @@ template void f4(T n) {
   SWarnUnused swu;
   swu += n;
 }
+
+template  void f5() {
+  // Don't warn for overloaded pre/post operators in template code.
+  SWarnUnused swu;
+  ++swu;
+}



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


[PATCH] D122271: [Clang] -Wunused-but-set-variable warning - handle also pre/post unary operators

2022-03-23 Thread Dávid Bolvanský via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG460fc440ad8d: [Clang] -Wunused-but-set-variable warning - 
handle also pre/post unary operators (authored by xbolva00).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122271

Files:
  clang/lib/Sema/SemaExprCXX.cpp
  clang/test/Sema/warn-unused-but-set-variables.c
  clang/test/SemaCXX/warn-unused-but-set-variables-cpp.cpp


Index: clang/test/SemaCXX/warn-unused-but-set-variables-cpp.cpp
===
--- clang/test/SemaCXX/warn-unused-but-set-variables-cpp.cpp
+++ clang/test/SemaCXX/warn-unused-but-set-variables-cpp.cpp
@@ -7,6 +7,7 @@
 struct __attribute__((warn_unused)) SWarnUnused {
   int j;
   void operator +=(int);
+  void operator ++();
 };
 
 int f0() {
@@ -62,3 +63,9 @@
   SWarnUnused swu;
   swu += n;
 }
+
+template  void f5() {
+  // Don't warn for overloaded pre/post operators in template code.
+  SWarnUnused swu;
+  ++swu;
+}
Index: clang/test/Sema/warn-unused-but-set-variables.c
===
--- clang/test/Sema/warn-unused-but-set-variables.c
+++ clang/test/Sema/warn-unused-but-set-variables.c
@@ -73,3 +73,20 @@
   __attribute__((__cleanup__(for_cleanup))) int x;
   x = 5;
 }
+
+void f4(void) {
+  int x1 = 0; // expected-warning{{variable 'x1' set but not used}}
+  x1++;
+  int x2 = 0; // expected-warning{{variable 'x2' set but not used}}
+  x2--;
+  int x3 = 0; // expected-warning{{variable 'x3' set but not used}}
+  ++x3;
+  int x4 = 0; // expected-warning{{variable 'x4' set but not used}}
+  --x4;
+
+  volatile int v1 = 0;
+  ++v1;
+  typedef volatile int volint;
+  volint v2 = 0;
+  v2++;
+}
Index: clang/lib/Sema/SemaExprCXX.cpp
===
--- clang/lib/Sema/SemaExprCXX.cpp
+++ clang/lib/Sema/SemaExprCXX.cpp
@@ -7921,6 +7921,7 @@
 Expr *E, llvm::DenseMap ) {
   DeclRefExpr *LHS = nullptr;
   bool IsCompoundAssign = false;
+  bool isIncrementDecrementUnaryOp = false;
   if (BinaryOperator *BO = dyn_cast(E)) {
 if (BO->getLHS()->getType()->isDependentType() ||
 BO->getRHS()->getType()->isDependentType()) {
@@ -7935,6 +7936,11 @@
 if (COCE->getOperator() != OO_Equal)
   return;
 LHS = dyn_cast(COCE->getArg(0));
+  } else if (UnaryOperator *UO = dyn_cast(E)) {
+if (!UO->isIncrementDecrementOp())
+  return;
+isIncrementDecrementUnaryOp = true;
+LHS = dyn_cast(UO->getSubExpr());
   }
   if (!LHS)
 return;
@@ -7942,8 +7948,10 @@
   if (!VD)
 return;
   // Don't decrement RefsMinusAssignments if volatile variable with compound
-  // assignment (+=, ...) to avoid potential unused-but-set-variable warning.
-  if (IsCompoundAssign && VD->getType().isVolatileQualified())
+  // assignment (+=, ...) or increment/decrement unary operator to avoid
+  // potential unused-but-set-variable warning.
+  if ((IsCompoundAssign || isIncrementDecrementUnaryOp) &&
+  VD->getType().isVolatileQualified())
 return;
   auto iter = RefsMinusAssignments.find(VD);
   if (iter == RefsMinusAssignments.end())


Index: clang/test/SemaCXX/warn-unused-but-set-variables-cpp.cpp
===
--- clang/test/SemaCXX/warn-unused-but-set-variables-cpp.cpp
+++ clang/test/SemaCXX/warn-unused-but-set-variables-cpp.cpp
@@ -7,6 +7,7 @@
 struct __attribute__((warn_unused)) SWarnUnused {
   int j;
   void operator +=(int);
+  void operator ++();
 };
 
 int f0() {
@@ -62,3 +63,9 @@
   SWarnUnused swu;
   swu += n;
 }
+
+template  void f5() {
+  // Don't warn for overloaded pre/post operators in template code.
+  SWarnUnused swu;
+  ++swu;
+}
Index: clang/test/Sema/warn-unused-but-set-variables.c
===
--- clang/test/Sema/warn-unused-but-set-variables.c
+++ clang/test/Sema/warn-unused-but-set-variables.c
@@ -73,3 +73,20 @@
   __attribute__((__cleanup__(for_cleanup))) int x;
   x = 5;
 }
+
+void f4(void) {
+  int x1 = 0; // expected-warning{{variable 'x1' set but not used}}
+  x1++;
+  int x2 = 0; // expected-warning{{variable 'x2' set but not used}}
+  x2--;
+  int x3 = 0; // expected-warning{{variable 'x3' set but not used}}
+  ++x3;
+  int x4 = 0; // expected-warning{{variable 'x4' set but not used}}
+  --x4;
+
+  volatile int v1 = 0;
+  ++v1;
+  typedef volatile int volint;
+  volint v2 = 0;
+  v2++;
+}
Index: clang/lib/Sema/SemaExprCXX.cpp
===
--- clang/lib/Sema/SemaExprCXX.cpp
+++ clang/lib/Sema/SemaExprCXX.cpp
@@ -7921,6 +7921,7 @@
 Expr *E, llvm::DenseMap ) {
   DeclRefExpr *LHS = nullptr;
   bool IsCompoundAssign = false;
+  bool isIncrementDecrementUnaryOp = false;
   if (BinaryOperator *BO = dyn_cast(E)) {
 if 

[clang] d90a3fc - [Clang] Added testcases for -Wunused-but-set-parameter

2022-03-23 Thread Dávid Bolvanský via cfe-commits

Author: Dávid Bolvanský
Date: 2022-03-23T22:14:38+01:00
New Revision: d90a3fcacda7257b26ac32350353410f79be6d2b

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

LOG: [Clang] Added testcases for -Wunused-but-set-parameter

Clang now emits warnings for them after D122271 (shared logic with 
-Wunused-but-set-variable)

Added: 


Modified: 
clang/test/Sema/warn-unused-but-set-parameters.c

Removed: 




diff  --git a/clang/test/Sema/warn-unused-but-set-parameters.c 
b/clang/test/Sema/warn-unused-but-set-parameters.c
index 4da4822090f3d..f1563ab50c1fb 100644
--- a/clang/test/Sema/warn-unused-but-set-parameters.c
+++ b/clang/test/Sema/warn-unused-but-set-parameters.c
@@ -24,3 +24,11 @@ void f3(struct S s) { // expected-warning{{parameter 's' set 
but not used}}
   struct S t;
   s = t;
 }
+
+void f4(int j) { // expected-warning{{parameter 'j' set but not used}}
+j++;
+}
+
+void f5(int k) { // expected-warning{{parameter 'k' set but not used}}
+--k;
+}



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


[PATCH] D122338: [OPENMP] Eliminate extra set of simd variant function attribute.

2022-03-23 Thread Jennifer Yu via Phabricator via cfe-commits
jyu2 added a comment.

In D122338#3403414 , @ABataev wrote:

> If ParamPositions grows, it means that the item is not found. Is it correct 
> behavior if the compiler inserts new item in the ParamPositions map?

I see.  Thanks!  Then it seems ParamPositions need to be set for each function 
decl otherwise PVD can not find.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122338

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


[PATCH] D122352: [OpenMP] Do not create offloading entries for internal or hidden symbols

2022-03-23 Thread Joseph Huber via Phabricator via cfe-commits
jhuber6 updated this revision to Diff 417751.
jhuber6 added a comment.

Adding new test


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122352

Files:
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/test/OpenMP/declare_target_visibility_codegen.cpp
  clang/test/OpenMP/nvptx_declare_target_var_ctor_dtor_codegen.cpp


Index: clang/test/OpenMP/nvptx_declare_target_var_ctor_dtor_codegen.cpp
===
--- clang/test/OpenMP/nvptx_declare_target_var_ctor_dtor_codegen.cpp
+++ clang/test/OpenMP/nvptx_declare_target_var_ctor_dtor_codegen.cpp
@@ -72,8 +72,6 @@
 // DEVICE-DAG: call void
 // DEVICE-DAG: ret void
 
-// HOST-DAG: @.omp_offloading.entry_name{{.*}} = internal unnamed_addr 
constant [{{[0-9]+}} x i8] c"[[C_ADDR]]\00"
-// HOST-DAG: @.omp_offloading.entry.[[C_ADDR]] = weak{{.*}} constant 
%struct.__tgt_offload_entry { i8* bitcast (i32* @[[C_ADDR]] to i8*), i8* 
getelementptr inbounds ([{{[0-9]+}} x i8], [{{[0-9]+}} x i8]* 
@.omp_offloading.entry_name{{.*}}, i32 0, i32 0), i64 4, i32 0, i32 0 }, 
section "omp_offloading_entries", align 1
 // HOST-DAG: @.omp_offloading.entry_name{{.*}} = internal unnamed_addr 
constant [{{[0-9]+}} x i8] c"[[CD_ADDR]]\00"
 // HOST-DAG: @.omp_offloading.entry.[[CD_ADDR]] = weak{{.*}} constant 
%struct.__tgt_offload_entry { i8* bitcast (%struct.S* @[[CD_ADDR]] to i8*), i8* 
getelementptr inbounds ([{{[0-9]+}} x i8], [{{[0-9]+}} x i8]* 
@.omp_offloading.entry_name{{.*}}, i32 0, i32 0), i64 4, i32 0, i32 0 }, 
section "omp_offloading_entries", align 1
 // HOST-DAG: @.omp_offloading.entry_name{{.*}} = internal unnamed_addr 
constant [{{[0-9]+}} x i8] c"[[C_CTOR]]\00"
Index: clang/test/OpenMP/declare_target_visibility_codegen.cpp
===
--- /dev/null
+++ clang/test/OpenMP/declare_target_visibility_codegen.cpp
@@ -0,0 +1,30 @@
+// RUN: %clang_cc1 -verify -fopenmp -fopenmp-version=45 
-fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple 
x86_64-unknown-unknown -emit-llvm %s -o - | FileCheck %s --check-prefix=HOST
+
+// expected-no-diagnostics
+class C {
+public:
+//.
+// HOST: @[[C:.+]] = internal global %class.C zeroinitializer, align 4
+// HOST: @[[X:.+]] = internal global i32 0, align 4
+// HOST: @y = hidden global i32 0
+// HOST: @z = global i32 0
+// HOST-NOT: @.omp_offloading.entry.c
+// HOST-NOT: @.omp_offloading.entry.x
+// HOST-NOT: @.omp_offloading.entry.y
+// HOST: @.omp_offloading.entry.z
+  C() : x(0) {}
+
+  int x;
+};
+
+static C c;
+#pragma omp declare target(c)
+
+static int x;
+#pragma omp declare target(x)
+
+int __attribute__((visibility("hidden"))) y;
+#pragma omp declare target(y)
+
+int z;
+#pragma omp declare target(z)
Index: clang/lib/CodeGen/CGOpenMPRuntime.cpp
===
--- clang/lib/CodeGen/CGOpenMPRuntime.cpp
+++ clang/lib/CodeGen/CGOpenMPRuntime.cpp
@@ -3323,6 +3323,13 @@
 }
 break;
   }
+
+  // Hidden or internal symbols on the device are not externally visible. 
We
+  // should not attempt to register them by creating an offloading entry.
+  if (auto *GV = dyn_cast(CE->getAddress()))
+if (GV->hasLocalLinkage() || GV->hasHiddenVisibility())
+  continue;
+
   createOffloadEntry(CE->getAddress(), CE->getAddress(),
  CE->getVarSize().getQuantity(), Flags,
  CE->getLinkage());


Index: clang/test/OpenMP/nvptx_declare_target_var_ctor_dtor_codegen.cpp
===
--- clang/test/OpenMP/nvptx_declare_target_var_ctor_dtor_codegen.cpp
+++ clang/test/OpenMP/nvptx_declare_target_var_ctor_dtor_codegen.cpp
@@ -72,8 +72,6 @@
 // DEVICE-DAG: call void
 // DEVICE-DAG: ret void
 
-// HOST-DAG: @.omp_offloading.entry_name{{.*}} = internal unnamed_addr constant [{{[0-9]+}} x i8] c"[[C_ADDR]]\00"
-// HOST-DAG: @.omp_offloading.entry.[[C_ADDR]] = weak{{.*}} constant %struct.__tgt_offload_entry { i8* bitcast (i32* @[[C_ADDR]] to i8*), i8* getelementptr inbounds ([{{[0-9]+}} x i8], [{{[0-9]+}} x i8]* @.omp_offloading.entry_name{{.*}}, i32 0, i32 0), i64 4, i32 0, i32 0 }, section "omp_offloading_entries", align 1
 // HOST-DAG: @.omp_offloading.entry_name{{.*}} = internal unnamed_addr constant [{{[0-9]+}} x i8] c"[[CD_ADDR]]\00"
 // HOST-DAG: @.omp_offloading.entry.[[CD_ADDR]] = weak{{.*}} constant %struct.__tgt_offload_entry { i8* bitcast (%struct.S* @[[CD_ADDR]] to i8*), i8* getelementptr inbounds ([{{[0-9]+}} x i8], [{{[0-9]+}} x i8]* @.omp_offloading.entry_name{{.*}}, i32 0, i32 0), i64 4, i32 0, i32 0 }, section "omp_offloading_entries", align 1
 // HOST-DAG: @.omp_offloading.entry_name{{.*}} = internal unnamed_addr constant [{{[0-9]+}} x i8] c"[[C_CTOR]]\00"
Index: clang/test/OpenMP/declare_target_visibility_codegen.cpp

[PATCH] D121733: Clean pathnames in FileManager.

2022-03-23 Thread Duncan P. N. Exon Smith via Phabricator via cfe-commits
dexonsmith added a comment.

In D121733#3403995 , @rnk wrote:

> Ignoring the ".." path components for the moment, is this patch good to go as 
> is? It doesn't affect that behavior.

Besides the test failure, the other thing is considering what to do with 
`getDirectoryRef()`, which might make sense to update in the same patch to 
avoid inconsistency. See 1st/2nd bullets of 
https://reviews.llvm.org/D121733#3393732.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121733

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


[PATCH] D118052: [X86] Fix CodeGen Module Flag for -mibt-seal

2022-03-23 Thread Xiang Zhang via Phabricator via cfe-commits
xiangzhangllvm added inline comments.



Comment at: clang/test/CodeGen/X86/x86-cf-protection.c:4
 // RUN: %clang -target i386-unknown-unknown -x c -E -dM -o - 
-fcf-protection=full %s   | FileCheck %s --check-prefix=FULL
+// RUN: %clang -target i386-unknown-unknown -o - -emit-llvm -S 
-fcf-protection=branch -mibt-seal -flto %s | FileCheck %s --check-prefix=IBTSEAL
 

joaomoreira wrote:
> pengfei wrote:
> > Is `-flto` is required?
> Yes, we can only suppress ENDBR if we are sure the given function is not 
> address taken in all other translation units.
Sorry, let me make sure here. what is the "translation units" here mean? Does 
it means another binary file (e.g. *.so , *.a)?
Using -flto seems here want more compile units (source files) to be one 
"translation units"?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118052

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


[clang] 64902d3 - Reland "Lower `@llvm.global_dtors` using `__cxa_atexit` on MachO"

2022-03-23 Thread Julian Lettner via cfe-commits

Author: Julian Lettner
Date: 2022-03-23T18:36:55-07:00
New Revision: 64902d335c2126e24a9d84b7410924148959e4a9

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

LOG: Reland "Lower `@llvm.global_dtors` using `__cxa_atexit` on MachO"

For MachO, lower `@llvm.global_dtors` into `@llvm_global_ctors` with
`__cxa_atexit` calls to avoid emitting the deprecated `__mod_term_func`.

Reuse the existing `WebAssemblyLowerGlobalDtors.cpp` to accomplish this.

Enable fallback to the old behavior via Clang driver flag
(`-fregister-global-dtors-with-atexit`) or llc / code generation flag
(`-lower-global-dtors-via-cxa-atexit`).  This escape hatch will be
removed in the future.

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

Added: 
llvm/include/llvm/Transforms/Utils/LowerGlobalDtors.h
llvm/lib/Transforms/Utils/LowerGlobalDtors.cpp

llvm/test/Transforms/LowerGlobalDestructors/lower-global-dtors-existing-dos_handle.ll
llvm/test/Transforms/LowerGlobalDestructors/lower-global-dtors.ll

Modified: 
clang/lib/CodeGen/BackendUtil.cpp
llvm/docs/Passes.rst
llvm/include/llvm/CodeGen/CommandFlags.h
llvm/include/llvm/CodeGen/TargetLoweringObjectFileImpl.h
llvm/include/llvm/InitializePasses.h
llvm/include/llvm/LinkAllPasses.h
llvm/include/llvm/Target/TargetOptions.h
llvm/include/llvm/Transforms/Instrumentation/AddressSanitizerOptions.h
llvm/include/llvm/Transforms/Utils.h
llvm/lib/CodeGen/CodeGen.cpp
llvm/lib/CodeGen/CommandFlags.cpp
llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp
llvm/lib/CodeGen/TargetPassConfig.cpp
llvm/lib/Passes/PassBuilder.cpp
llvm/lib/Passes/PassRegistry.def
llvm/lib/Target/WebAssembly/CMakeLists.txt
llvm/lib/Target/WebAssembly/WebAssembly.h
llvm/lib/Target/WebAssembly/WebAssemblyTargetMachine.cpp
llvm/lib/Transforms/Utils/CMakeLists.txt
llvm/lib/Transforms/Utils/Utils.cpp
llvm/test/CodeGen/ARM/ctors_dtors.ll
llvm/test/CodeGen/X86/2011-08-29-InitOrder.ll

Removed: 
llvm/lib/Target/WebAssembly/WebAssemblyLowerGlobalDtors.cpp



diff  --git a/clang/lib/CodeGen/BackendUtil.cpp 
b/clang/lib/CodeGen/BackendUtil.cpp
index 0cffc34a02cc4..eaf34eedcb2bb 100644
--- a/clang/lib/CodeGen/BackendUtil.cpp
+++ b/clang/lib/CodeGen/BackendUtil.cpp
@@ -546,6 +546,8 @@ static bool initTargetOptions(DiagnosticsEngine ,
   Options.BinutilsVersion =
   llvm::TargetMachine::parseBinutilsVersion(CodeGenOpts.BinutilsVersion);
   Options.UseInitArray = CodeGenOpts.UseInitArray;
+  Options.LowerGlobalDtorsViaCxaAtExit =
+  CodeGenOpts.RegisterGlobalDtorsWithAtExit;
   Options.DisableIntegratedAS = CodeGenOpts.DisableIntegratedAS;
   Options.CompressDebugSections = CodeGenOpts.getCompressDebugSections();
   Options.RelaxELFRelocations = CodeGenOpts.RelaxELFRelocations;

diff  --git a/llvm/docs/Passes.rst b/llvm/docs/Passes.rst
index 92f06496b4ef9..7c0666992e8f5 100644
--- a/llvm/docs/Passes.rst
+++ b/llvm/docs/Passes.rst
@@ -876,6 +876,14 @@ This pass expects :ref:`LICM ` to be run 
before it to hoist
 invariant conditions out of the loop, to make the unswitching opportunity
 obvious.
 
+``-lower-global-dtors``: Lower global destructors
+
+
+This pass lowers global module destructors (``llvm.global_dtors``) by creating
+wrapper functions that are registered as global constructors in
+``llvm.global_ctors`` and which contain a call to ``__cxa_atexit`` to register
+their destructor functions.
+
 ``-loweratomic``: Lower atomic intrinsics to non-atomic form
 
 

diff  --git a/llvm/include/llvm/CodeGen/CommandFlags.h 
b/llvm/include/llvm/CodeGen/CommandFlags.h
index feb5de5415269..9281ed723854c 100644
--- a/llvm/include/llvm/CodeGen/CommandFlags.h
+++ b/llvm/include/llvm/CodeGen/CommandFlags.h
@@ -93,6 +93,8 @@ std::string getTrapFuncName();
 
 bool getUseCtors();
 
+bool getLowerGlobalDtorsViaCxaAtExit();
+
 bool getRelaxELFRelocations();
 
 bool getDataSections();

diff  --git a/llvm/include/llvm/CodeGen/TargetLoweringObjectFileImpl.h 
b/llvm/include/llvm/CodeGen/TargetLoweringObjectFileImpl.h
index 2a35987507446..26bda8d5d239d 100644
--- a/llvm/include/llvm/CodeGen/TargetLoweringObjectFileImpl.h
+++ b/llvm/include/llvm/CodeGen/TargetLoweringObjectFileImpl.h
@@ -119,6 +119,9 @@ class TargetLoweringObjectFileMachO : public 
TargetLoweringObjectFile {
 
   void Initialize(MCContext , const TargetMachine ) override;
 
+  MCSection *getStaticDtorSection(unsigned Priority,
+  const MCSymbol *KeySym) const override;
+
   /// Emit the module flags that specify the garbage collection information.
   void emitModuleMetadata(MCStreamer , Module ) const override;
 


[PATCH] D122335: [clang] Emit crash reproduction as a single tar file

2022-03-23 Thread Jessica Clarke via Phabricator via cfe-commits
jrtc27 added a comment.

As a developer who often deals with crashes locally this is more annoying; 
currently I can just point tools at the shell script and C file in /tmp and let 
them go to work reducing, but now I have to also extract the files


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

https://reviews.llvm.org/D122335

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


[PATCH] D120886: [Inline asm][1/3] Fix mangle problem when variable used in inline asm (Revert 2 history bugfix patch)

2022-03-23 Thread Xiang Zhang 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 rG8a6b644c7923: [Inline asm] Fix mangle problem when variable 
used in inline asm. (authored by xiangzhangllvm).
Herald added subscribers: cfe-commits, StephenFan.
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120886

Files:
  clang/test/CodeGen/X86/ms_fmul.c
  clang/test/CodeGen/ms-inline-asm-static-variable.c
  clang/test/CodeGen/ms-inline-asm-variables.c
  llvm/include/llvm/MC/MCParser/MCParsedAsmOperand.h
  llvm/lib/MC/MCParser/AsmParser.cpp
  llvm/lib/Target/X86/AsmParser/X86AsmParser.cpp
  llvm/lib/Target/X86/AsmParser/X86Operand.h
  llvm/test/CodeGen/X86/ms-inline-asm-array.ll

Index: llvm/test/CodeGen/X86/ms-inline-asm-array.ll
===
--- llvm/test/CodeGen/X86/ms-inline-asm-array.ll
+++ llvm/test/CodeGen/X86/ms-inline-asm-array.ll
@@ -5,7 +5,7 @@
 ; CHECK: movl%edx, arr(,%rdx,4)
 define dso_local i32 @main() #0 {
 entry:
-  call void asm sideeffect inteldialect "mov dword ptr arr[rdx * $$4],edx", "=*m,~{dirflag},~{fpsr},~{flags}"([10 x i32]* elementtype([10 x i32]) @arr) #1, !srcloc !4
+  call void asm sideeffect inteldialect "mov dword ptr $0[rdx * $$4],edx", "=*m,~{dirflag},~{fpsr},~{flags}"([10 x i32]* elementtype([10 x i32]) @arr) #1, !srcloc !4
   ret i32 0
 }
 
Index: llvm/lib/Target/X86/AsmParser/X86Operand.h
===
--- llvm/lib/Target/X86/AsmParser/X86Operand.h
+++ llvm/lib/Target/X86/AsmParser/X86Operand.h
@@ -287,12 +287,6 @@
 
   bool isOffsetOfLocal() const override { return isImm() && Imm.LocalRef; }
 
-  bool isMemPlaceholder(const MCInstrDesc ) const override {
-// Only MS InlineAsm uses global variables with registers rather than
-// rip/eip.
-return isMem() && !Mem.DefaultBaseReg && Mem.FrontendSize;
-  }
-
   bool needAddressOf() const override { return AddressOf; }
 
   bool isMem() const override { return Kind == Memory; }
Index: llvm/lib/Target/X86/AsmParser/X86AsmParser.cpp
===
--- llvm/lib/Target/X86/AsmParser/X86AsmParser.cpp
+++ llvm/lib/Target/X86/AsmParser/X86AsmParser.cpp
@@ -1759,8 +1759,7 @@
   // registers in a mmory expression, and though unaccessible via rip/eip.
   if (IsGlobalLV && (BaseReg || IndexReg)) {
 Operands.push_back(X86Operand::CreateMem(getPointerWidth(), Disp, Start,
- End, Size, Identifier, Decl,
- FrontendSize));
+ End, Size, Identifier, Decl));
 return false;
   }
   // Otherwise, we set the base register to a non-zero value
@@ -2552,6 +2551,8 @@
   StringRef ErrMsg;
   unsigned BaseReg = SM.getBaseReg();
   unsigned IndexReg = SM.getIndexReg();
+  if (IndexReg && BaseReg == X86::RIP)
+BaseReg = 0;
   unsigned Scale = SM.getScale();
   if (!PtrInOperand)
 Size = SM.getElementSize() << 3;
Index: llvm/lib/MC/MCParser/AsmParser.cpp
===
--- llvm/lib/MC/MCParser/AsmParser.cpp
+++ llvm/lib/MC/MCParser/AsmParser.cpp
@@ -6022,13 +6022,12 @@
 
   bool isOutput = (i == 1) && Desc.mayStore();
   SMLoc Start = SMLoc::getFromPointer(SymName.data());
-  int64_t Size = Operand.isMemPlaceholder(Desc) ? 0 : SymName.size();
   if (isOutput) {
 ++InputIdx;
 OutputDecls.push_back(OpDecl);
 OutputDeclsAddressOf.push_back(Operand.needAddressOf());
 OutputConstraints.push_back(("=" + Constraint).str());
-AsmStrRewrites.emplace_back(AOK_Output, Start, Size);
+AsmStrRewrites.emplace_back(AOK_Output, Start, SymName.size());
   } else {
 InputDecls.push_back(OpDecl);
 InputDeclsAddressOf.push_back(Operand.needAddressOf());
@@ -6036,7 +6035,7 @@
 if (Desc.OpInfo[i - 1].isBranchTarget())
   AsmStrRewrites.emplace_back(AOK_CallInput, Start, SymName.size());
 else
-  AsmStrRewrites.emplace_back(AOK_Input, Start, Size);
+  AsmStrRewrites.emplace_back(AOK_Input, Start, SymName.size());
   }
 }
 
@@ -6151,17 +6150,13 @@
   OS << Ctx.getAsmInfo()->getPrivateLabelPrefix() << AR.Label;
   break;
 case AOK_Input:
-  if (AR.Len)
-OS << '$' << InputIdx;
-  ++InputIdx;
+  OS << '$' << InputIdx++;
   break;
 case AOK_CallInput:
   OS << "${" << InputIdx++ << ":P}";
   break;
 case AOK_Output:
-  if (AR.Len)
-OS << '$' << OutputIdx;
-  ++OutputIdx;
+  OS << '$' << OutputIdx++;
   break;
 case AOK_SizeDirective:
   switch (AR.Val) {
Index: llvm/include/llvm/MC/MCParser/MCParsedAsmOperand.h

[clang] 287dad1 - [InlineAsm] Fix mangle problem when global variable used in inline asm

2022-03-23 Thread Xiang1 Zhang via cfe-commits

Author: Xiang1 Zhang
Date: 2022-03-24T09:41:23+08:00
New Revision: 287dad13abba934db5f4a62a968263eea2693b4f

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

LOG: [InlineAsm] Fix mangle problem when global variable used in inline asm
(Add modifier P for ARR[BaseReg+IndexReg+..])

Reviewed By: skan

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

Added: 


Modified: 
clang/test/CodeGen/ms-inline-asm-variables.c
llvm/include/llvm/MC/MCParser/MCParsedAsmOperand.h
llvm/include/llvm/MC/MCParser/MCTargetAsmParser.h
llvm/lib/MC/MCParser/AsmParser.cpp
llvm/lib/Target/X86/AsmParser/X86AsmParser.cpp
llvm/lib/Target/X86/AsmParser/X86Operand.h

Removed: 




diff  --git a/clang/test/CodeGen/ms-inline-asm-variables.c 
b/clang/test/CodeGen/ms-inline-asm-variables.c
index 6a50b2cf35f8a..a830e21b1f75b 100644
--- a/clang/test/CodeGen/ms-inline-asm-variables.c
+++ b/clang/test/CodeGen/ms-inline-asm-variables.c
@@ -11,11 +11,11 @@ void t1() {
   __asm add ebx, dword ptr gVar[271 - 82 + 81 + ebx]
   // CHECK: add dword ptr ${{[0-9]}}[ebx + $$828], ebx
   __asm add dword ptr [ebx + gVar + 828], ebx
-  // CHECK: add ecx, dword ptr ${{[0-9]}}[ecx + ecx * $$4 + $$4590]
+  // CHECK: add ecx, dword ptr ${{{[0-9]}}:P}[ecx + ecx * $$4 + $$4590]
   __asm add ecx, dword ptr gVar[4590 + ecx + ecx*4]
-  // CHECK: add dword ptr ${{[0-9]}}[ecx + ecx * $$8 + $$73], ecx
+  // CHECK: add dword ptr ${{{[0-9]}}:P}[ecx + ecx * $$8 + $$73], ecx
   __asm add dword ptr [gVar + ecx + 45 + 23 - 53 + 60 - 2 + ecx*8], ecx
-  // CHECK: add ${{[0-9]}}[ecx + ebx + $$7], eax
+  // CHECK: add ${{{[0-9]}}:P}[ecx + ebx + $$7], eax
   __asm add 1 + 1 + 2 + 3[gVar + ecx + ebx], eax
 }
 

diff  --git a/llvm/include/llvm/MC/MCParser/MCParsedAsmOperand.h 
b/llvm/include/llvm/MC/MCParser/MCParsedAsmOperand.h
index abb95628c2a98..22f66a011ece5 100644
--- a/llvm/include/llvm/MC/MCParser/MCParsedAsmOperand.h
+++ b/llvm/include/llvm/MC/MCParser/MCParsedAsmOperand.h
@@ -62,6 +62,13 @@ class MCParsedAsmOperand {
   /// isMem - Is this a memory operand?
   virtual bool isMem() const = 0;
 
+  /// isMemUseUpRegs - Is memory operand use up regs, for example, intel MS
+  /// inline asm may use ARR[baseReg + IndexReg + ...] which may use up regs
+  /// in [...] expr, so ARR[baseReg + IndexReg + ...] can not use extra reg
+  /// for ARR. For example, calculating ARR address to a reg or use another
+  /// base reg in PIC model.
+  virtual bool isMemUseUpRegs() const { return false; }
+
   /// getStartLoc - Get the location of the first token of this operand.
   virtual SMLoc getStartLoc() const = 0;
   /// getEndLoc - Get the location of the last token of this operand.

diff  --git a/llvm/include/llvm/MC/MCParser/MCTargetAsmParser.h 
b/llvm/include/llvm/MC/MCParser/MCTargetAsmParser.h
index d0cb3d160cc10..1d380c6a00b7c 100644
--- a/llvm/include/llvm/MC/MCParser/MCTargetAsmParser.h
+++ b/llvm/include/llvm/MC/MCParser/MCTargetAsmParser.h
@@ -101,10 +101,14 @@ struct AsmRewrite {
   int64_t Val;
   StringRef Label;
   IntelExpr IntelExp;
+  bool IntelExpRestricted;
 
 public:
-  AsmRewrite(AsmRewriteKind kind, SMLoc loc, unsigned len = 0, int64_t val = 0)
-: Kind(kind), Loc(loc), Len(len), Done(false), Val(val) {}
+  AsmRewrite(AsmRewriteKind kind, SMLoc loc, unsigned len = 0, int64_t val = 0,
+ bool Restricted = false)
+  : Kind(kind), Loc(loc), Len(len), Done(false), Val(val) {
+IntelExpRestricted = Restricted;
+  }
   AsmRewrite(AsmRewriteKind kind, SMLoc loc, unsigned len, StringRef label)
 : AsmRewrite(kind, loc, len) { Label = label; }
   AsmRewrite(SMLoc loc, unsigned len, IntelExpr exp)

diff  --git a/llvm/lib/MC/MCParser/AsmParser.cpp 
b/llvm/lib/MC/MCParser/AsmParser.cpp
index f28eeabb5cefa..fda9b1f8be265 100644
--- a/llvm/lib/MC/MCParser/AsmParser.cpp
+++ b/llvm/lib/MC/MCParser/AsmParser.cpp
@@ -6021,21 +6021,25 @@ bool AsmParser::parseMSInlineAsm(
   }
 
   bool isOutput = (i == 1) && Desc.mayStore();
+  bool Restricted = Operand.isMemUseUpRegs();
   SMLoc Start = SMLoc::getFromPointer(SymName.data());
   if (isOutput) {
 ++InputIdx;
 OutputDecls.push_back(OpDecl);
 OutputDeclsAddressOf.push_back(Operand.needAddressOf());
 OutputConstraints.push_back(("=" + Constraint).str());
-AsmStrRewrites.emplace_back(AOK_Output, Start, SymName.size());
+AsmStrRewrites.emplace_back(AOK_Output, Start, SymName.size(), 0,
+Restricted);
   } else {
 InputDecls.push_back(OpDecl);
 InputDeclsAddressOf.push_back(Operand.needAddressOf());
 InputConstraints.push_back(Constraint.str());
 if (Desc.OpInfo[i - 1].isBranchTarget())
-  

[clang] 8a6b644 - [Inline asm] Fix mangle problem when variable used in inline asm.

2022-03-23 Thread Xiang1 Zhang via cfe-commits

Author: Xiang1 Zhang
Date: 2022-03-24T09:41:22+08:00
New Revision: 8a6b644c79234a276fbdc840f7091d490a8cc0d7

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

LOG: [Inline asm] Fix mangle problem when variable used in inline asm.
(Connect InlineAsm Memory Operand with its real value not just name)
Revert 2 history bugfix patch:

Revert "[X86][MS-InlineAsm] Make the constraint *m to be simple place holder"
This patch revert https://reviews.llvm.org/D115225 which mainly
fix problems intrduced by https://reviews.llvm.org/D113096

This reverts commit d7c07f60b35f901f5bd9153b11807124a9bdde60.

Revert "Reland "[X86][MS-InlineAsm] Use exact conditions to recognize MS global 
variables""
This patch revert https://reviews.llvm.org/D116090 which fix problem
intrduced by https://reviews.llvm.org/D115225

This reverts commit 24c68ea1eb4fc0d0e782424ddb02da9e8c53ddf5.

Reviewed By: skan

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

Added: 


Modified: 
clang/test/CodeGen/X86/ms_fmul.c
clang/test/CodeGen/ms-inline-asm-static-variable.c
clang/test/CodeGen/ms-inline-asm-variables.c
llvm/include/llvm/MC/MCParser/MCParsedAsmOperand.h
llvm/lib/MC/MCParser/AsmParser.cpp
llvm/lib/Target/X86/AsmParser/X86AsmParser.cpp
llvm/lib/Target/X86/AsmParser/X86Operand.h
llvm/test/CodeGen/X86/ms-inline-asm-array.ll

Removed: 




diff  --git a/clang/test/CodeGen/X86/ms_fmul.c 
b/clang/test/CodeGen/X86/ms_fmul.c
index a0a1be9e217c5..d1cfcef814625 100644
--- a/clang/test/CodeGen/X86/ms_fmul.c
+++ b/clang/test/CodeGen/X86/ms_fmul.c
@@ -18,4 +18,4 @@ void __attribute__ ((naked)) foo(void)
 }}
 
 // CHECK-LABEL: foo
-// CHECK: call void asm sideeffect inteldialect "fmul qword ptr 
static_const_table[edx + $$240]\0A\09ret"
+// CHECK: call void asm sideeffect inteldialect "fmul qword ptr $0[edx + 
$$240]\0A\09ret"

diff  --git a/clang/test/CodeGen/ms-inline-asm-static-variable.c 
b/clang/test/CodeGen/ms-inline-asm-static-variable.c
index 46b5201c9e290..10fb74fb7de2b 100644
--- a/clang/test/CodeGen/ms-inline-asm-static-variable.c
+++ b/clang/test/CodeGen/ms-inline-asm-static-variable.c
@@ -5,6 +5,6 @@
 static int arr[10];
 void t1(void) {
   // CHECK: @arr = internal global [10 x i32]
-  // CHECK: call void asm sideeffect inteldialect "mov dword ptr arr[edx * 
$$4],edx", "=*m,{{.*}}([10 x i32]* elementtype([10 x i32]) @arr)
+  // CHECK: call void asm sideeffect inteldialect "mov dword ptr $0[edx * 
$$4],edx", "=*m,{{.*}}([10 x i32]* elementtype([10 x i32]) @arr)
   __asm mov  dword ptr arr[edx*4],edx
 }

diff  --git a/clang/test/CodeGen/ms-inline-asm-variables.c 
b/clang/test/CodeGen/ms-inline-asm-variables.c
index c5e56b3349d64..6a50b2cf35f8a 100644
--- a/clang/test/CodeGen/ms-inline-asm-variables.c
+++ b/clang/test/CodeGen/ms-inline-asm-variables.c
@@ -2,20 +2,20 @@
 // RUN: %clang_cc1 %s -fasm-blocks -triple i386-apple-darwin10 -emit-llvm -o - 
| FileCheck %s
 
 int gVar;
-void t1(void) {
-  // CHECK: add eax, dword ptr gVar[eax]
+void t1() {
+  // CHECK: add eax, dword ptr ${{[0-9]}}[eax]
   __asm add eax, dword ptr gVar[eax]
-  // CHECK: add dword ptr gVar[eax], eax
+  // CHECK: add dword ptr ${{[0-9]}}[eax], eax
   __asm add dword ptr [eax+gVar], eax
-  // CHECK: add ebx, dword ptr gVar[ebx + $$270]
+  // CHECK: add ebx, dword ptr ${{[0-9]}}[ebx + $$270]
   __asm add ebx, dword ptr gVar[271 - 82 + 81 + ebx]
-  // CHECK: add dword ptr gVar[ebx + $$828], ebx
+  // CHECK: add dword ptr ${{[0-9]}}[ebx + $$828], ebx
   __asm add dword ptr [ebx + gVar + 828], ebx
-  // CHECK: add ecx, dword ptr gVar[ecx + ecx * $$4 + $$4590]
+  // CHECK: add ecx, dword ptr ${{[0-9]}}[ecx + ecx * $$4 + $$4590]
   __asm add ecx, dword ptr gVar[4590 + ecx + ecx*4]
-  // CHECK: add dword ptr gVar[ecx + ecx * $$8 + $$73], ecx
+  // CHECK: add dword ptr ${{[0-9]}}[ecx + ecx * $$8 + $$73], ecx
   __asm add dword ptr [gVar + ecx + 45 + 23 - 53 + 60 - 2 + ecx*8], ecx
-  // CHECK: add gVar[ecx + ebx + $$7], eax
+  // CHECK: add ${{[0-9]}}[ecx + ebx + $$7], eax
   __asm add 1 + 1 + 2 + 3[gVar + ecx + ebx], eax
 }
 

diff  --git a/llvm/include/llvm/MC/MCParser/MCParsedAsmOperand.h 
b/llvm/include/llvm/MC/MCParser/MCParsedAsmOperand.h
index faf0a4474c8a4..abb95628c2a98 100644
--- a/llvm/include/llvm/MC/MCParser/MCParsedAsmOperand.h
+++ b/llvm/include/llvm/MC/MCParser/MCParsedAsmOperand.h
@@ -10,7 +10,6 @@
 #define LLVM_MC_MCPARSER_MCPARSEDASMOPERAND_H
 
 #include "llvm/ADT/StringRef.h"
-#include "llvm/MC/MCInstrDesc.h"
 #include "llvm/Support/SMLoc.h"
 #include 
 
@@ -77,10 +76,6 @@ class MCParsedAsmOperand {
   /// assembly.
   virtual bool isOffsetOfLocal() const { return false; }
 
-  /// isMemPlaceholder - Do we need to ignore the constraint, rather than emit
-  /// code? Only valid when parsing MS-style 

[PATCH] D120887: The [2/3] Fix mangle problem when variable used in inline asm (Add modifier P for ARR[BaseReg+IndexReg+..])

2022-03-23 Thread Xiang Zhang 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 rG287dad13abba: [InlineAsm] Fix mangle problem when global 
variable used in inline asm (authored by xiangzhangllvm).
Herald added subscribers: cfe-commits, StephenFan.
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120887

Files:
  clang/test/CodeGen/ms-inline-asm-variables.c
  llvm/include/llvm/MC/MCParser/MCParsedAsmOperand.h
  llvm/include/llvm/MC/MCParser/MCTargetAsmParser.h
  llvm/lib/MC/MCParser/AsmParser.cpp
  llvm/lib/Target/X86/AsmParser/X86AsmParser.cpp
  llvm/lib/Target/X86/AsmParser/X86Operand.h

Index: llvm/lib/Target/X86/AsmParser/X86Operand.h
===
--- llvm/lib/Target/X86/AsmParser/X86Operand.h
+++ llvm/lib/Target/X86/AsmParser/X86Operand.h
@@ -68,6 +68,10 @@
 /// If the memory operand is unsized and there are multiple instruction
 /// matches, prefer the one with this size.
 unsigned FrontendSize;
+
+/// This used for inline asm which may specify base reg and index reg for
+/// MemOp. e.g. ARR[eax + ecx*4], so no extra reg can be used for MemOp.
+bool UseUpRegs;
   };
 
   union {
@@ -380,6 +384,10 @@
 return isAbsMem() && Mem.ModeSize == 16;
   }
 
+  bool isMemUseUpRegs() const {
+return Mem.UseUpRegs;
+  }
+
   bool isSrcIdx() const {
 return !getMemIndexReg() && getMemScale() == 1 &&
   (getMemBaseReg() == X86::RSI || getMemBaseReg() == X86::ESI ||
@@ -665,7 +673,8 @@
   static std::unique_ptr
   CreateMem(unsigned ModeSize, const MCExpr *Disp, SMLoc StartLoc, SMLoc EndLoc,
 unsigned Size = 0, StringRef SymName = StringRef(),
-void *OpDecl = nullptr, unsigned FrontendSize = 0) {
+void *OpDecl = nullptr, unsigned FrontendSize = 0,
+bool UseUpRegs = false) {
 auto Res = std::make_unique(Memory, StartLoc, EndLoc);
 Res->Mem.SegReg   = 0;
 Res->Mem.Disp = Disp;
@@ -676,6 +685,7 @@
 Res->Mem.Size = Size;
 Res->Mem.ModeSize = ModeSize;
 Res->Mem.FrontendSize = FrontendSize;
+Res->Mem.UseUpRegs = UseUpRegs;
 Res->SymName  = SymName;
 Res->OpDecl   = OpDecl;
 Res->AddressOf= false;
@@ -689,7 +699,7 @@
 SMLoc EndLoc, unsigned Size = 0,
 unsigned DefaultBaseReg = X86::NoRegister,
 StringRef SymName = StringRef(), void *OpDecl = nullptr,
-unsigned FrontendSize = 0) {
+unsigned FrontendSize = 0, bool UseUpRegs = false) {
 // We should never just have a displacement, that should be parsed as an
 // absolute memory operand.
 assert((SegReg || BaseReg || IndexReg || DefaultBaseReg) &&
@@ -708,6 +718,7 @@
 Res->Mem.Size = Size;
 Res->Mem.ModeSize = ModeSize;
 Res->Mem.FrontendSize = FrontendSize;
+Res->Mem.UseUpRegs = UseUpRegs;
 Res->SymName  = SymName;
 Res->OpDecl   = OpDecl;
 Res->AddressOf= false;
Index: llvm/lib/Target/X86/AsmParser/X86AsmParser.cpp
===
--- llvm/lib/Target/X86/AsmParser/X86AsmParser.cpp
+++ llvm/lib/Target/X86/AsmParser/X86AsmParser.cpp
@@ -1759,7 +1759,8 @@
   // registers in a mmory expression, and though unaccessible via rip/eip.
   if (IsGlobalLV && (BaseReg || IndexReg)) {
 Operands.push_back(X86Operand::CreateMem(getPointerWidth(), Disp, Start,
- End, Size, Identifier, Decl));
+ End, Size, Identifier, Decl, 0,
+ BaseReg && IndexReg));
 return false;
   }
   // Otherwise, we set the base register to a non-zero value
Index: llvm/lib/MC/MCParser/AsmParser.cpp
===
--- llvm/lib/MC/MCParser/AsmParser.cpp
+++ llvm/lib/MC/MCParser/AsmParser.cpp
@@ -6021,21 +6021,25 @@
   }
 
   bool isOutput = (i == 1) && Desc.mayStore();
+  bool Restricted = Operand.isMemUseUpRegs();
   SMLoc Start = SMLoc::getFromPointer(SymName.data());
   if (isOutput) {
 ++InputIdx;
 OutputDecls.push_back(OpDecl);
 OutputDeclsAddressOf.push_back(Operand.needAddressOf());
 OutputConstraints.push_back(("=" + Constraint).str());
-AsmStrRewrites.emplace_back(AOK_Output, Start, SymName.size());
+AsmStrRewrites.emplace_back(AOK_Output, Start, SymName.size(), 0,
+Restricted);
   } else {
 InputDecls.push_back(OpDecl);
 InputDeclsAddressOf.push_back(Operand.needAddressOf());
 InputConstraints.push_back(Constraint.str());
 if (Desc.OpInfo[i - 1].isBranchTarget())
-  AsmStrRewrites.emplace_back(AOK_CallInput, Start, 

[PATCH] D121736: Lower `@llvm.global_dtors` using `__cxa_atexit` on MachO

2022-03-23 Thread Julian Lettner via Phabricator via cfe-commits
yln added a comment.

Thank you @zequanwu, for providing the minimized reproducer! It really made 
fixing this much easier!  :)

I've re-landed the change and added a test specifically for this issue: 
`lower-global-dtors-existing-dos_handle.ll`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121736

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


[PATCH] D122335: [clang] Emit crash reproduction as a single tar file

2022-03-23 Thread Alex Brachet via Phabricator via cfe-commits
abrachet updated this revision to Diff 417754.
abrachet added a comment.
Herald added a subscriber: arphaman.

Fix test failures outside of Driver/


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

https://reviews.llvm.org/D122335

Files:
  clang/docs/ReleaseNotes.rst
  clang/lib/Driver/Driver.cpp
  clang/test/Driver/crash-diagnostics-dir.c
  clang/test/Driver/crash-report-clang-cl.cpp
  clang/test/Driver/crash-report-header.h
  clang/test/Driver/crash-report-modules.m
  clang/test/Driver/crash-report-spaces.c
  clang/test/Driver/crash-report-with-asserts.c
  clang/test/Driver/crash-report.cpp
  clang/test/Driver/rewrite-map-in-diagnostics.c
  clang/test/Index/create-libclang-completion-reproducer.c
  clang/test/Index/create-libclang-parsing-reproducer.c
  clang/test/Modules/crash-vfs-path-emptydir-entries.m
  clang/test/Modules/crash-vfs-path-symlink-component.m
  clang/test/Modules/crash-vfs-path-symlink-topheader.m
  clang/test/Modules/crash-vfs-path-traversal.m
  clang/test/Modules/crash-vfs-relative-overlay.m
  clang/test/Modules/crash-vfs-umbrella-frameworks.m

Index: clang/test/Modules/crash-vfs-umbrella-frameworks.m
===
--- clang/test/Modules/crash-vfs-umbrella-frameworks.m
+++ clang/test/Modules/crash-vfs-umbrella-frameworks.m
@@ -14,14 +14,12 @@
 // RUN: -F %/t/i/Frameworks -fmodules \
 // RUN: -fmodules-cache-path=%t/m/ 2>&1 | FileCheck %s
 
-// RUN: FileCheck --check-prefix=CHECKYAML %s -input-file \
-// RUN: %t/crash-vfs-*.cache/vfs/vfs.yaml
-// RUN: find %t/crash-vfs-*.cache/vfs | \
-// RUN:   grep "B.framework/Headers/B.h" | count 1
+// RUN: tar xOf %t/*.tar --wildcards "*/tmp/vfs/vfs.yaml" \
+// RUN:  | FileCheck --check-prefix=CHECKYAML %s
+// RUN: tar tf %t/*.tar | FileCheck --check-prefix=CHECKTAR %s
 
 // CHECK: Preprocessed source(s) and associated run script(s) are located at:
-// CHECK-NEXT: note: diagnostic msg: {{.*}}.m
-// CHECK-NEXT: note: diagnostic msg: {{.*}}.cache
+// CHECK-NEXT: note: diagnostic msg: {{.*}}.tar
 
 // CHECKYAML:  'type': 'directory',
 // CHECKYAML:  'name': "/[[PATH:.*]]/i/Frameworks/A.framework/Frameworks/B.framework/Headers",
@@ -39,6 +37,8 @@
 // CHECKYAML-NEXT:  'name': "B.h",
 // CHECKYAML-NEXT:  'external-contents': "/[[PATH]]/i/Frameworks/B.framework/Headers/B.h"
 
+// CHECKTAR: B.framework/Headers/B.h
+
 @import I;
 
 // Run the reproducer script - regular exit code is enough to test it works. The
@@ -51,5 +51,6 @@
 // RUN: cd %t
 // RUN: rm -rf i
 // RUN: rm -rf crash-vfs-umbrella-*.cache/modules/*
-// RUN: chmod 755 crash-vfs-*.sh
-// RUN: ./crash-vfs-*.sh
+// RUN: tar xOf %t/*.tar --wildcards "*/repro.sh" > repro.sh
+// RUN: chmod 755 repro.sh
+// RUN: ./repro.sh
Index: clang/test/Modules/crash-vfs-relative-overlay.m
===
--- clang/test/Modules/crash-vfs-relative-overlay.m
+++ clang/test/Modules/crash-vfs-relative-overlay.m
@@ -11,18 +11,18 @@
 // RUN: -I %S/Inputs/crash-recovery/usr/include -isysroot %/t/i/ \
 // RUN: -fmodules -fmodules-cache-path=%t/m/ 2>&1 | FileCheck %s
 
-// RUN: FileCheck --check-prefix=CHECKSRC %s -input-file %t/crash-vfs-*.m
-// RUN: FileCheck --check-prefix=CHECKSH %s -input-file %t/crash-vfs-*.sh
-// RUN: FileCheck --check-prefix=CHECKYAML %s -input-file \
-// RUN: %t/crash-vfs-*.cache/vfs/vfs.yaml
-// RUN: find %t/crash-vfs-*.cache/vfs | \
-// RUN:   grep "Inputs/crash-recovery/usr/include/stdio.h" | count 1
+// RUN: tar xOf %t/*.tar --wildcards "*/tmp/crash-vfs-*.m"  \
+// RUN:  | FileCheck --check-prefix=CHECKSRC %s
+// RUN: tar xOf %t/*.tar --wildcards "*/repro.sh"   \
+// RUN:  | FileCheck --check-prefix=CHECKSH %s
+// RUN: tar xOf %t/*.tar --wildcards "*/tmp/vfs/vfs.yaml"   \
+// RUN:  | FileCheck --check-prefix=CHECKYAML %s
+// RUN: tar tf %t/*.tar | FileCheck --check-prefix=CHECKTAR %s
 
 #include 
 
 // CHECK: Preprocessed source(s) and associated run script(s) are located at:
-// CHECK-NEXT: note: diagnostic msg: {{.*}}.m
-// CHECK-NEXT: note: diagnostic msg: {{.*}}.cache
+// CHECK-NEXT: note: diagnostic msg: {{.*}}.tar
 
 // CHECKSRC: #pragma clang module import cstd.stdio
 
@@ -49,6 +49,8 @@
 // CHECKYAML-NEXT: 'external-contents': "/[[PATH]]/Inputs/crash-recovery/usr/include/module.map"
 // CHECKYAML-NEXT:   },
 
+// CHECKTAR: Inputs/crash-recovery/usr/include/stdio.h
+
 // Test that reading the YAML file will yield the correct path after
 // the overlay dir is prefixed to access headers in .cache/vfs directory.
 
Index: clang/test/Modules/crash-vfs-path-traversal.m
===
--- clang/test/Modules/crash-vfs-path-traversal.m
+++ clang/test/Modules/crash-vfs-path-traversal.m
@@ -13,18 +13,18 @@
 // RUN: not %clang -fsyntax-only %s -I %S/Inputs/crash-recovery -isysroot %/t/i/ \
 // RUN: -fmodules -fmodules-cache-path=%t/m/ 2>&1 | 

[PATCH] D121532: [Clang][WIP] Fix Unevaluated Lambdas

2022-03-23 Thread Corentin Jabot via Phabricator via cfe-commits
cor3ntin updated this revision to Diff 417761.
cor3ntin added a comment.

- Added a couple of tests in ASTImporterTest.cpp
- Rename elements of LambdaDependencyKind
- Fix ActOnStartOfLambdaDefinition to not use a boolean for

LambdaDependencyKind.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121532

Files:
  clang/include/clang/AST/DeclCXX.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/ASTImporter.cpp
  clang/lib/AST/DeclBase.cpp
  clang/lib/AST/DeclCXX.cpp
  clang/lib/Sema/SemaLambda.cpp
  clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
  clang/lib/Sema/TreeTransform.h
  clang/lib/Serialization/ASTReaderDecl.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/test/SemaCXX/lambda-unevaluated.cpp
  clang/unittests/AST/ASTImporterTest.cpp

Index: clang/unittests/AST/ASTImporterTest.cpp
===
--- clang/unittests/AST/ASTImporterTest.cpp
+++ clang/unittests/AST/ASTImporterTest.cpp
@@ -5824,6 +5824,7 @@
   std::distance(FromL->decls().begin(), FromL->decls().end());
   EXPECT_NE(ToLSize, 0u);
   EXPECT_EQ(ToLSize, FromLSize);
+  EXPECT_FALSE(FromL->isDependentLambda());
 }
 
 TEST_P(ASTImporterOptionSpecificTestBase, LambdaInFunctionParam) {
@@ -5843,6 +5844,7 @@
   std::distance(FromL->decls().begin(), FromL->decls().end());
   EXPECT_NE(ToLSize, 0u);
   EXPECT_EQ(ToLSize, FromLSize);
+  EXPECT_TRUE(FromL->isDependentLambda());
 }
 
 TEST_P(ASTImporterOptionSpecificTestBase, LambdaInGlobalScope) {
Index: clang/test/SemaCXX/lambda-unevaluated.cpp
===
--- clang/test/SemaCXX/lambda-unevaluated.cpp
+++ clang/test/SemaCXX/lambda-unevaluated.cpp
@@ -30,6 +30,27 @@
 auto e = g(0); // expected-error{{no matching function for call}}
 // expected-note@-2 {{substitution failure}}
 
+template 
+auto foo(decltype([] {
+  return [] { return T(); }();
+})) {}
+
+void test() {
+  foo({});
+}
+
+template 
+struct C {
+  template 
+  auto foo(decltype([] {
+return [] { return T(); }();
+  })) {}
+};
+
+void test2() {
+  C{}.foo({});
+}
+
 namespace PR52073 {
 // OK, these are distinct functions not redefinitions.
 template void f(decltype([]{})) {} // expected-note {{candidate}}
@@ -40,6 +61,62 @@
 template void g(const char (*)[([]{ return N; })()]) {} // expected-note {{candidate}}
 template void g(const char (*)[([]{ return N; })()]) {} // expected-note {{candidate}}
 // FIXME: We instantiate the lambdas into the context of the function template,
-// so we think they're dependent and can't evaluate a call to them.
+//  so we think they're dependent and can't evaluate a call to them.
 void use_g() { g<6>(&"hello"); } // expected-error {{no matching function}}
 }
+
+namespace GH51416 {
+
+template 
+struct A {
+  void spam(decltype([] {}));
+};
+
+template 
+void A::spam(decltype([] {})) // expected-error{{out-of-line definition of 'spam' does not match}}
+{}
+
+struct B {
+  template 
+  void spam(decltype([] {}));
+};
+
+template 
+void B::spam(decltype([] {})) {} // expected-error{{out-of-line definition of 'spam' does not match}}
+
+} // namespace GH51416
+
+namespace GH50376 {
+
+template 
+struct foo_t {// expected-note 2{{candidate constructor}}
+  foo_t(T ptr) {} // expected-note{{candidate constructor}}
+};
+
+template 
+using alias = foo_t;
+
+template 
+auto fun(T const ) -> alias {
+  return alias{t}; // expected-error{{no viable conversion from returned value of type 'alias<...>'}}
+}
+
+void f() {
+  int i;
+  auto const error = fun(i); // expected-note{{in instantiation}}
+}
+
+} // namespace GH50376
+
+namespace GH51414 {
+template  void spam(decltype([] {}) (*s)[sizeof(T)] = nullptr) {}
+void foo() {
+  spam();
+}
+} // namespace GH51414
+
+namespace GH51641 {
+template 
+void foo(decltype(+[](T) {}) lambda, T param);
+static_assert(!__is_same(decltype(foo), void));
+} // namespace GH51641
Index: clang/lib/Serialization/ASTWriter.cpp
===
--- clang/lib/Serialization/ASTWriter.cpp
+++ clang/lib/Serialization/ASTWriter.cpp
@@ -5727,7 +5727,7 @@
   // Add lambda-specific data.
   if (Data.IsLambda) {
 auto  = D->getLambdaData();
-Record->push_back(Lambda.Dependent);
+Record->push_back(Lambda.DependencyKind);
 Record->push_back(Lambda.IsGenericLambda);
 Record->push_back(Lambda.CaptureDefault);
 Record->push_back(Lambda.NumCaptures);
Index: clang/lib/Serialization/ASTReaderDecl.cpp
===
--- clang/lib/Serialization/ASTReaderDecl.cpp
+++ clang/lib/Serialization/ASTReaderDecl.cpp
@@ -1801,7 +1801,7 @@
 using Capture = LambdaCapture;
 
 auto  = static_cast(Data);
-Lambda.Dependent = Record.readInt();
+Lambda.DependencyKind = Record.readInt();
 Lambda.IsGenericLambda = Record.readInt();
 Lambda.CaptureDefault = 

[clang] 0d16c23 - [OpenMP] Do not create offloading entries for internal or hidden symbols

2022-03-23 Thread Joseph Huber via cfe-commits

Author: Joseph Huber
Date: 2022-03-23T18:27:16-04:00
New Revision: 0d16c23af1da2e7c83c84cf64f8b76947f038044

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

LOG: [OpenMP] Do not create offloading entries for internal or hidden symbols

Currently we create offloading entries to register device variables with
the host. When we register a variable we will look up the symbol in the
device image and map the device address to the host address. This is a
problem when the symbol is declared with hidden visibility or internal
linkage. This means the symbol is not accessible externally and we
cannot get its address. We should still allow static variables to be
declared on the device, but ew should not create an offloading entry for
them so they exist independently on the host and device.

Fixes #54309

Reviewed By: jdoerfert

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

Added: 
clang/test/OpenMP/declare_target_visibility_codegen.cpp

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

Removed: 




diff  --git a/clang/lib/CodeGen/CGOpenMPRuntime.cpp 
b/clang/lib/CodeGen/CGOpenMPRuntime.cpp
index a1986c2f8796b..cd58a1b67a166 100644
--- a/clang/lib/CodeGen/CGOpenMPRuntime.cpp
+++ b/clang/lib/CodeGen/CGOpenMPRuntime.cpp
@@ -3325,6 +3325,13 @@ void 
CGOpenMPRuntime::createOffloadEntriesAndInfoMetadata() {
 }
 break;
   }
+
+  // Hidden or internal symbols on the device are not externally visible. 
We
+  // should not attempt to register them by creating an offloading entry.
+  if (auto *GV = dyn_cast(CE->getAddress()))
+if (GV->hasLocalLinkage() || GV->hasHiddenVisibility())
+  continue;
+
   createOffloadEntry(CE->getAddress(), CE->getAddress(),
  CE->getVarSize().getQuantity(), Flags,
  CE->getLinkage());

diff  --git a/clang/test/OpenMP/declare_target_visibility_codegen.cpp 
b/clang/test/OpenMP/declare_target_visibility_codegen.cpp
new file mode 100644
index 0..6518bac50623a
--- /dev/null
+++ b/clang/test/OpenMP/declare_target_visibility_codegen.cpp
@@ -0,0 +1,30 @@
+// RUN: %clang_cc1 -verify -fopenmp -fopenmp-version=45 
-fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple 
x86_64-unknown-unknown -emit-llvm %s -o - | FileCheck %s --check-prefix=HOST
+
+// expected-no-diagnostics
+class C {
+public:
+//.
+// HOST: @[[C:.+]] = internal global %class.C zeroinitializer, align 4
+// HOST: @[[X:.+]] = internal global i32 0, align 4
+// HOST: @y = hidden global i32 0
+// HOST: @z = global i32 0
+// HOST-NOT: @.omp_offloading.entry.c
+// HOST-NOT: @.omp_offloading.entry.x
+// HOST-NOT: @.omp_offloading.entry.y
+// HOST: @.omp_offloading.entry.z
+  C() : x(0) {}
+
+  int x;
+};
+
+static C c;
+#pragma omp declare target(c)
+
+static int x;
+#pragma omp declare target(x)
+
+int __attribute__((visibility("hidden"))) y;
+#pragma omp declare target(y)
+
+int z;
+#pragma omp declare target(z)

diff  --git a/clang/test/OpenMP/nvptx_declare_target_var_ctor_dtor_codegen.cpp 
b/clang/test/OpenMP/nvptx_declare_target_var_ctor_dtor_codegen.cpp
index 0b8c17f1d3279..45b8372bf64ec 100644
--- a/clang/test/OpenMP/nvptx_declare_target_var_ctor_dtor_codegen.cpp
+++ b/clang/test/OpenMP/nvptx_declare_target_var_ctor_dtor_codegen.cpp
@@ -72,8 +72,6 @@ S cd = doo() + car() + caz() + baz();
 // DEVICE-DAG: call void
 // DEVICE-DAG: ret void
 
-// HOST-DAG: @.omp_offloading.entry_name{{.*}} = internal unnamed_addr 
constant [{{[0-9]+}} x i8] c"[[C_ADDR]]\00"
-// HOST-DAG: @.omp_offloading.entry.[[C_ADDR]] = weak{{.*}} constant 
%struct.__tgt_offload_entry { i8* bitcast (i32* @[[C_ADDR]] to i8*), i8* 
getelementptr inbounds ([{{[0-9]+}} x i8], [{{[0-9]+}} x i8]* 
@.omp_offloading.entry_name{{.*}}, i32 0, i32 0), i64 4, i32 0, i32 0 }, 
section "omp_offloading_entries", align 1
 // HOST-DAG: @.omp_offloading.entry_name{{.*}} = internal unnamed_addr 
constant [{{[0-9]+}} x i8] c"[[CD_ADDR]]\00"
 // HOST-DAG: @.omp_offloading.entry.[[CD_ADDR]] = weak{{.*}} constant 
%struct.__tgt_offload_entry { i8* bitcast (%struct.S* @[[CD_ADDR]] to i8*), i8* 
getelementptr inbounds ([{{[0-9]+}} x i8], [{{[0-9]+}} x i8]* 
@.omp_offloading.entry_name{{.*}}, i32 0, i32 0), i64 4, i32 0, i32 0 }, 
section "omp_offloading_entries", align 1
 // HOST-DAG: @.omp_offloading.entry_name{{.*}} = internal unnamed_addr 
constant [{{[0-9]+}} x i8] c"[[C_CTOR]]\00"



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


[PATCH] D122352: [OpenMP] Do not create offloading entries for internal or hidden symbols

2022-03-23 Thread Joseph Huber via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG0d16c23af1da: [OpenMP] Do not create offloading entries for 
internal or hidden symbols (authored by jhuber6).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122352

Files:
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/test/OpenMP/declare_target_visibility_codegen.cpp
  clang/test/OpenMP/nvptx_declare_target_var_ctor_dtor_codegen.cpp


Index: clang/test/OpenMP/nvptx_declare_target_var_ctor_dtor_codegen.cpp
===
--- clang/test/OpenMP/nvptx_declare_target_var_ctor_dtor_codegen.cpp
+++ clang/test/OpenMP/nvptx_declare_target_var_ctor_dtor_codegen.cpp
@@ -72,8 +72,6 @@
 // DEVICE-DAG: call void
 // DEVICE-DAG: ret void
 
-// HOST-DAG: @.omp_offloading.entry_name{{.*}} = internal unnamed_addr 
constant [{{[0-9]+}} x i8] c"[[C_ADDR]]\00"
-// HOST-DAG: @.omp_offloading.entry.[[C_ADDR]] = weak{{.*}} constant 
%struct.__tgt_offload_entry { i8* bitcast (i32* @[[C_ADDR]] to i8*), i8* 
getelementptr inbounds ([{{[0-9]+}} x i8], [{{[0-9]+}} x i8]* 
@.omp_offloading.entry_name{{.*}}, i32 0, i32 0), i64 4, i32 0, i32 0 }, 
section "omp_offloading_entries", align 1
 // HOST-DAG: @.omp_offloading.entry_name{{.*}} = internal unnamed_addr 
constant [{{[0-9]+}} x i8] c"[[CD_ADDR]]\00"
 // HOST-DAG: @.omp_offloading.entry.[[CD_ADDR]] = weak{{.*}} constant 
%struct.__tgt_offload_entry { i8* bitcast (%struct.S* @[[CD_ADDR]] to i8*), i8* 
getelementptr inbounds ([{{[0-9]+}} x i8], [{{[0-9]+}} x i8]* 
@.omp_offloading.entry_name{{.*}}, i32 0, i32 0), i64 4, i32 0, i32 0 }, 
section "omp_offloading_entries", align 1
 // HOST-DAG: @.omp_offloading.entry_name{{.*}} = internal unnamed_addr 
constant [{{[0-9]+}} x i8] c"[[C_CTOR]]\00"
Index: clang/test/OpenMP/declare_target_visibility_codegen.cpp
===
--- /dev/null
+++ clang/test/OpenMP/declare_target_visibility_codegen.cpp
@@ -0,0 +1,30 @@
+// RUN: %clang_cc1 -verify -fopenmp -fopenmp-version=45 
-fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple 
x86_64-unknown-unknown -emit-llvm %s -o - | FileCheck %s --check-prefix=HOST
+
+// expected-no-diagnostics
+class C {
+public:
+//.
+// HOST: @[[C:.+]] = internal global %class.C zeroinitializer, align 4
+// HOST: @[[X:.+]] = internal global i32 0, align 4
+// HOST: @y = hidden global i32 0
+// HOST: @z = global i32 0
+// HOST-NOT: @.omp_offloading.entry.c
+// HOST-NOT: @.omp_offloading.entry.x
+// HOST-NOT: @.omp_offloading.entry.y
+// HOST: @.omp_offloading.entry.z
+  C() : x(0) {}
+
+  int x;
+};
+
+static C c;
+#pragma omp declare target(c)
+
+static int x;
+#pragma omp declare target(x)
+
+int __attribute__((visibility("hidden"))) y;
+#pragma omp declare target(y)
+
+int z;
+#pragma omp declare target(z)
Index: clang/lib/CodeGen/CGOpenMPRuntime.cpp
===
--- clang/lib/CodeGen/CGOpenMPRuntime.cpp
+++ clang/lib/CodeGen/CGOpenMPRuntime.cpp
@@ -3325,6 +3325,13 @@
 }
 break;
   }
+
+  // Hidden or internal symbols on the device are not externally visible. 
We
+  // should not attempt to register them by creating an offloading entry.
+  if (auto *GV = dyn_cast(CE->getAddress()))
+if (GV->hasLocalLinkage() || GV->hasHiddenVisibility())
+  continue;
+
   createOffloadEntry(CE->getAddress(), CE->getAddress(),
  CE->getVarSize().getQuantity(), Flags,
  CE->getLinkage());


Index: clang/test/OpenMP/nvptx_declare_target_var_ctor_dtor_codegen.cpp
===
--- clang/test/OpenMP/nvptx_declare_target_var_ctor_dtor_codegen.cpp
+++ clang/test/OpenMP/nvptx_declare_target_var_ctor_dtor_codegen.cpp
@@ -72,8 +72,6 @@
 // DEVICE-DAG: call void
 // DEVICE-DAG: ret void
 
-// HOST-DAG: @.omp_offloading.entry_name{{.*}} = internal unnamed_addr constant [{{[0-9]+}} x i8] c"[[C_ADDR]]\00"
-// HOST-DAG: @.omp_offloading.entry.[[C_ADDR]] = weak{{.*}} constant %struct.__tgt_offload_entry { i8* bitcast (i32* @[[C_ADDR]] to i8*), i8* getelementptr inbounds ([{{[0-9]+}} x i8], [{{[0-9]+}} x i8]* @.omp_offloading.entry_name{{.*}}, i32 0, i32 0), i64 4, i32 0, i32 0 }, section "omp_offloading_entries", align 1
 // HOST-DAG: @.omp_offloading.entry_name{{.*}} = internal unnamed_addr constant [{{[0-9]+}} x i8] c"[[CD_ADDR]]\00"
 // HOST-DAG: @.omp_offloading.entry.[[CD_ADDR]] = weak{{.*}} constant %struct.__tgt_offload_entry { i8* bitcast (%struct.S* @[[CD_ADDR]] to i8*), i8* getelementptr inbounds ([{{[0-9]+}} x i8], [{{[0-9]+}} x i8]* @.omp_offloading.entry_name{{.*}}, i32 0, i32 0), i64 4, i32 0, i32 0 }, section "omp_offloading_entries", align 1
 // HOST-DAG: @.omp_offloading.entry_name{{.*}} = internal unnamed_addr constant [{{[0-9]+}} x i8] 

[PATCH] D121812: [clang][deps] NFC: De-duplicate clang-cl tests

2022-03-23 Thread Gulfem Savrun Yeniceri via Phabricator via cfe-commits
gulfem added a comment.

Newly added tests `ClangScanDeps/cl-output.c` and `ClangScanDeps/cl-xclang.c` 
started failing in our Mac toolchain builds:
https://luci-milo.appspot.com/ui/p/fuchsia/builders/toolchain.ci/clang-mac-x64/b881168677577537/overview
Here's the link to the log:
https://logs.chromium.org/logs/fuchsia/buildbucket/cr-buildbucket/881168677577537/+/u/clang/test/stdout

The failure is as the following:

  FAIL: Clang :: ClangScanDeps/cl-xclang.c (2170 of 30232)
   TEST 'Clang :: ClangScanDeps/cl-xclang.c' FAILED 

  Script:
  --
  : 'RUN: at line 4';   rm -rf 
/opt/s/w/ir/x/w/staging/llvm_build/tools/clang/test/ClangScanDeps/Output/cl-xclang.c.tmp
  : 'RUN: at line 5';   split-file 
/opt/s/w/ir/x/w/llvm-llvm-project/clang/test/ClangScanDeps/cl-xclang.c 
/opt/s/w/ir/x/w/staging/llvm_build/tools/clang/test/ClangScanDeps/Output/cl-xclang.c.tmp
  : 'RUN: at line 16';   sed -e 
"s|DIR|/opt/s/w/ir/x/w/staging/llvm_build/tools/clang/test/ClangScanDeps/Output/cl-xclang.c.tmp|g"
 
/opt/s/w/ir/x/w/staging/llvm_build/tools/clang/test/ClangScanDeps/Output/cl-xclang.c.tmp/cdb.json.template
 > 
/opt/s/w/ir/x/w/staging/llvm_build/tools/clang/test/ClangScanDeps/Output/cl-xclang.c.tmp/cdb.json
  : 'RUN: at line 17';   /opt/s/w/ir/x/w/staging/llvm_build/bin/clang-scan-deps 
-compilation-database 
/opt/s/w/ir/x/w/staging/llvm_build/tools/clang/test/ClangScanDeps/Output/cl-xclang.c.tmp/cdb.json
 > 
/opt/s/w/ir/x/w/staging/llvm_build/tools/clang/test/ClangScanDeps/Output/cl-xclang.c.tmp/result.d
  : 'RUN: at line 18';   cat 
/opt/s/w/ir/x/w/staging/llvm_build/tools/clang/test/ClangScanDeps/Output/cl-xclang.c.tmp/result.d
 | sed 's:\?:/:g' | /opt/s/w/ir/x/w/staging/llvm_build/bin/FileCheck 
/opt/s/w/ir/x/w/llvm-llvm-project/clang/test/ClangScanDeps/cl-xclang.c 
-DPREFIX=/opt/s/w/ir/x/w/staging/llvm_build/tools/clang/test/ClangScanDeps/Output/cl-xclang.c.tmp
  --
  Exit Code: 1
  
  Command Output (stderr):
  --
  /opt/s/w/ir/x/w/llvm-llvm-project/clang/test/ClangScanDeps/cl-xclang.c:19:11: 
error: CHECK: expected string not found in input
  // CHECK: [[PREFIX]]/test.o:
^
  :1:1: note: scanning from here
  
pt/s/w/ir/x/w/staging/llvm_build/tools/clang/test/ClangScanDeps/Output/cl-xclang.c.tmp/test.o:
 \
  ^
  :1:1: note: with "PREFIX" equal to 
"/opt/s/w/ir/x/w/staging/llvm_build/tools/clang/test/ClangScanDeps/Output/cl-xclang\\.c\\.tmp"
  
pt/s/w/ir/x/w/staging/llvm_build/tools/clang/test/ClangScanDeps/Output/cl-xclang.c.tmp/test.o:
 \
  ^
  :1:86: note: possible intended match here
  
pt/s/w/ir/x/w/staging/llvm_build/tools/clang/test/ClangScanDeps/Output/cl-xclang.c.tmp/test.o:
 \

   ^
  
  Input file: 
  Check file: 
/opt/s/w/ir/x/w/llvm-llvm-project/clang/test/ClangScanDeps/cl-xclang.c
  
  -dump-input=help explains the following input dump.
  
  Input was:
  <<
  1: 
pt/s/w/ir/x/w/staging/llvm_build/tools/clang/test/ClangScanDeps/Output/cl-xclang.c.tmp/test.o:
 \ 
  check:19'0 
X
 error: no match found
  check:19'1
   with "PREFIX" equal to 
"/opt/s/w/ir/x/w/staging/llvm_build/tools/clang/test/ClangScanDeps/Output/cl-xclang\\.c\\.tmp"
  check:19'2
  ?possible intended match
  2:  
/opt/s/w/ir/x/w/staging/llvm_build/tools/clang/test/ClangScanDeps/Output/cl-xclang.c.tmp/test.c
 
  check:19'0 
~
  >>
  
  --
  
  


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121812

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


[PATCH] D122303: [pseudo] Sort nonterminals based on their reduction order.

2022-03-23 Thread Sam McCall via Phabricator via cfe-commits
sammccall accepted this revision.
sammccall added a comment.
This revision is now accepted and ready to land.

Nice!




Comment at: clang-tools-extra/pseudo/lib/GrammarBNF.cpp:55
 };
 for (const auto  : Specs) {
   Consider(Spec.Target);

hokein wrote:
> sammccall wrote:
> > You could identify dependencies here, and then use them to sort the 
> > uniquenonterminals before  allocating SymbolIDs
> not sure I get the your point -- we could move the topological sort here, but 
> it doesn't seem to be significantly better compared with the current solution.
(This related to the suggestion of sorting *symbols*, in which case you want to 
do it based on the specs, before assigning symbol IDs. It's obsolete now)



Comment at: clang-tools-extra/pseudo/lib/GrammarBNF.cpp:91
"Too many rules to fit in RuleID bits!");
-llvm::sort(T->Rules, [](const Rule , const Rule ) {
-  // Sorted by the Target.
-  return std::tie(Left.Target, Left.Size) <
- std::tie(Right.Target, Right.Size);
-});
-RuleID RulePos = 0;
+const auto  = getTopologicalOrder(T.get());
+llvm::stable_sort(

I'd call the variable SymbolOrder - once we've computed the order and decided 
to use it for symbols, it's no longer locally relevant that it's topological



Comment at: clang-tools-extra/pseudo/lib/GrammarBNF.cpp:104
+  while (End < T->Rules.size() &&
+ TopologicalOrder[T->Rules[End].Target] == TopologicalOrder[SID])
+++End;

You don't need TopologicalOrder[] wrapping both, just compare symbol IDs?



Comment at: clang-tools-extra/pseudo/lib/GrammarBNF.cpp:119
+  //
+  // It returns a "lookup" vector where the index is SymbolID, and the value is
+  // the index of the SymbolID in the topological-orderred array.

This explanation is a bit confusing, because it refers to a second array 
doesn't exist and never will.

Maybe "This function returns the sort key for each symbol, the array is indexed 
by SymbolID."

(I think we're actually returning the inverse of the chosen permutation, but 
that's not a helpful explanation :-)



Comment at: clang-tools-extra/pseudo/lib/GrammarBNF.cpp:142
+Diagnostics.push_back(
+llvm::formatv("The grammar is cyclic, see symbol {0}",
+  T->Nonterminals[SID].Name));

The grammar contains a cycle involving symbol {0}?



Comment at: clang-tools-extra/pseudo/lib/GrammarBNF.cpp:147
+  VisitStates[SID] = Visiting;
+  auto It = llvm::partition_point(
+  Dependencies, [](const std::pair ) {

this is more tersely `llvm::lower_bound(Dependencies, {SID, 0})`, making use of 
the fact that `std::less` will do what we want

And with the inline lambda is gone, it seems more idiomatic as a for loop:
```
for (auto It = llvm::lower_bound(...); It != Dependencies.end() && It->first == 
SID; ++It)
  DFS(It->second);
```



Comment at: clang-tools-extra/pseudo/lib/GrammarBNF.cpp:156
+  VisitStates[SID] = Visited;
+  Order.push_back(SID);
+};

Instead of building up the permutation array and then inverting it afterwards, 
maybe directly `Result[SID] = NextKey++;` here?

(Having pre-sized the vector)



Comment at: clang-tools-extra/pseudo/unittests/GrammarTest.cpp:51
+  return G->table().Nonterminals[id(NonterminalName)].RuleRange.Start;
+ADD_FAILURE() << "Expected a single rule for " << NonterminalName
+  << ", but it has " << RuleRange.End - RuleRange.Start

nit: maybe "ruleFor() expected a single rule..." to make it clear this isn't a 
real grammar requirement



Comment at: clang-tools-extra/pseudo/unittests/GrammarTest.cpp:53
+  << ", but it has " << RuleRange.End - RuleRange.Start
+  << " rule!\n";
+return 0;

nit: rule -> rules


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122303

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


[clang] 581dc3c - Revert "Lower `@llvm.global_dtors` using `__cxa_atexit` on MachO"

2022-03-23 Thread Zequan Wu via cfe-commits

Author: Zequan Wu
Date: 2022-03-23T16:11:54-07:00
New Revision: 581dc3c729c619fe636325a79279fabb2acdc1ce

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

LOG: Revert "Lower `@llvm.global_dtors` using `__cxa_atexit` on MachO"

This reverts commit 22570bac694396514fff18dec926558951643fa6.

Added: 
llvm/lib/Target/WebAssembly/WebAssemblyLowerGlobalDtors.cpp

Modified: 
clang/lib/CodeGen/BackendUtil.cpp
llvm/docs/Passes.rst
llvm/include/llvm/CodeGen/CommandFlags.h
llvm/include/llvm/CodeGen/TargetLoweringObjectFileImpl.h
llvm/include/llvm/InitializePasses.h
llvm/include/llvm/LinkAllPasses.h
llvm/include/llvm/Target/TargetOptions.h
llvm/include/llvm/Transforms/Instrumentation/AddressSanitizerOptions.h
llvm/include/llvm/Transforms/Utils.h
llvm/lib/CodeGen/CodeGen.cpp
llvm/lib/CodeGen/CommandFlags.cpp
llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp
llvm/lib/CodeGen/TargetPassConfig.cpp
llvm/lib/Passes/PassBuilder.cpp
llvm/lib/Passes/PassRegistry.def
llvm/lib/Target/WebAssembly/CMakeLists.txt
llvm/lib/Target/WebAssembly/WebAssembly.h
llvm/lib/Target/WebAssembly/WebAssemblyTargetMachine.cpp
llvm/lib/Transforms/Utils/CMakeLists.txt
llvm/lib/Transforms/Utils/Utils.cpp
llvm/test/CodeGen/ARM/ctors_dtors.ll
llvm/test/CodeGen/X86/2011-08-29-InitOrder.ll

Removed: 
llvm/include/llvm/Transforms/Utils/LowerGlobalDtors.h
llvm/lib/Transforms/Utils/LowerGlobalDtors.cpp
llvm/test/Transforms/LowerGlobalDestructors/lower-global-dtors.ll



diff  --git a/clang/lib/CodeGen/BackendUtil.cpp 
b/clang/lib/CodeGen/BackendUtil.cpp
index eaf34eedcb2bb..0cffc34a02cc4 100644
--- a/clang/lib/CodeGen/BackendUtil.cpp
+++ b/clang/lib/CodeGen/BackendUtil.cpp
@@ -546,8 +546,6 @@ static bool initTargetOptions(DiagnosticsEngine ,
   Options.BinutilsVersion =
   llvm::TargetMachine::parseBinutilsVersion(CodeGenOpts.BinutilsVersion);
   Options.UseInitArray = CodeGenOpts.UseInitArray;
-  Options.LowerGlobalDtorsViaCxaAtExit =
-  CodeGenOpts.RegisterGlobalDtorsWithAtExit;
   Options.DisableIntegratedAS = CodeGenOpts.DisableIntegratedAS;
   Options.CompressDebugSections = CodeGenOpts.getCompressDebugSections();
   Options.RelaxELFRelocations = CodeGenOpts.RelaxELFRelocations;

diff  --git a/llvm/docs/Passes.rst b/llvm/docs/Passes.rst
index 7c0666992e8f5..92f06496b4ef9 100644
--- a/llvm/docs/Passes.rst
+++ b/llvm/docs/Passes.rst
@@ -876,14 +876,6 @@ This pass expects :ref:`LICM ` to be run 
before it to hoist
 invariant conditions out of the loop, to make the unswitching opportunity
 obvious.
 
-``-lower-global-dtors``: Lower global destructors
-
-
-This pass lowers global module destructors (``llvm.global_dtors``) by creating
-wrapper functions that are registered as global constructors in
-``llvm.global_ctors`` and which contain a call to ``__cxa_atexit`` to register
-their destructor functions.
-
 ``-loweratomic``: Lower atomic intrinsics to non-atomic form
 
 

diff  --git a/llvm/include/llvm/CodeGen/CommandFlags.h 
b/llvm/include/llvm/CodeGen/CommandFlags.h
index 9281ed723854c..feb5de5415269 100644
--- a/llvm/include/llvm/CodeGen/CommandFlags.h
+++ b/llvm/include/llvm/CodeGen/CommandFlags.h
@@ -93,8 +93,6 @@ std::string getTrapFuncName();
 
 bool getUseCtors();
 
-bool getLowerGlobalDtorsViaCxaAtExit();
-
 bool getRelaxELFRelocations();
 
 bool getDataSections();

diff  --git a/llvm/include/llvm/CodeGen/TargetLoweringObjectFileImpl.h 
b/llvm/include/llvm/CodeGen/TargetLoweringObjectFileImpl.h
index 26bda8d5d239d..2a35987507446 100644
--- a/llvm/include/llvm/CodeGen/TargetLoweringObjectFileImpl.h
+++ b/llvm/include/llvm/CodeGen/TargetLoweringObjectFileImpl.h
@@ -119,9 +119,6 @@ class TargetLoweringObjectFileMachO : public 
TargetLoweringObjectFile {
 
   void Initialize(MCContext , const TargetMachine ) override;
 
-  MCSection *getStaticDtorSection(unsigned Priority,
-  const MCSymbol *KeySym) const override;
-
   /// Emit the module flags that specify the garbage collection information.
   void emitModuleMetadata(MCStreamer , Module ) const override;
 

diff  --git a/llvm/include/llvm/InitializePasses.h 
b/llvm/include/llvm/InitializePasses.h
index 82aafe2744184..3a98bacef81d0 100644
--- a/llvm/include/llvm/InitializePasses.h
+++ b/llvm/include/llvm/InitializePasses.h
@@ -274,7 +274,6 @@ void initializeLowerAtomicLegacyPassPass(PassRegistry&);
 void initializeLowerConstantIntrinsicsPass(PassRegistry&);
 void initializeLowerEmuTLSPass(PassRegistry&);
 void initializeLowerExpectIntrinsicPass(PassRegistry&);
-void initializeLowerGlobalDtorsLegacyPassPass(PassRegistry &);
 

[PATCH] D121736: Lower `@llvm.global_dtors` using `__cxa_atexit` on MachO

2022-03-23 Thread Zequan Wu via Phabricator via cfe-commits
zequanwu added a comment.
Herald added a subscriber: pmatos.

Hi, this causes crash on Mac building bot.
Here is the reduced repro:

`opt -lower-global-dtors /tmp/reduced.ll -o /dev/null `

  $ cat /tmp/reduced.ll
  %struct.mach_header = type { i32, i32, i32, i32, i32, i32, i32 }
  
  @__dso_handle = external global %struct.mach_header
  @llvm.global_dtors = appending global [1 x { i32, void ()*, i8* }] [{ i32, 
void ()*, i8* } { i32 1, void ()* undef, i8* null }]


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121736

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


[PATCH] D122352: [OpenMP] Do not create offloading entries for internal or hidden symbols

2022-03-23 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert accepted this revision.
jdoerfert added a comment.
This revision is now accepted and ready to land.

LG


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122352

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


[PATCH] D122335: [clang] Emit crash reproduction as a single tar file

2022-03-23 Thread Alex Brachet via Phabricator via cfe-commits
abrachet added a comment.

In D122335#3403474 , @aaron.ballman 
wrote:

> Yup, I'm okay with that compiler engineer requirement; I think our existing 
> requirements on Windows already pull in a useful `tar` program even though it 
> doesn't seem like we have any tests relying on it being installed yet.

There are actually a couple tests in lld that use `tar` 
https://github.com/llvm/llvm-project/blob/main/lld/test/ELF/reproduce-backslash.s#L8

Looks like there are some test failures on Windows my guess is their `tar` 
doesn't support the `--wildcards` flag. I'd rather not make these `UNSUPORTED: 
windows`, but am unsure how to move forward otherwise.


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

https://reviews.llvm.org/D122335

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


[PATCH] D122335: [clang] Emit crash reproduction as a single tar file

2022-03-23 Thread Alex Brachet via Phabricator via cfe-commits
abrachet updated this revision to Diff 417756.
abrachet added a comment.

Rebase


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

https://reviews.llvm.org/D122335

Files:
  clang/docs/ReleaseNotes.rst
  clang/lib/Driver/Driver.cpp
  clang/test/Driver/crash-diagnostics-dir.c
  clang/test/Driver/crash-report-clang-cl.cpp
  clang/test/Driver/crash-report-header.h
  clang/test/Driver/crash-report-modules.m
  clang/test/Driver/crash-report-spaces.c
  clang/test/Driver/crash-report-with-asserts.c
  clang/test/Driver/crash-report.cpp
  clang/test/Driver/rewrite-map-in-diagnostics.c
  clang/test/Index/create-libclang-completion-reproducer.c
  clang/test/Index/create-libclang-parsing-reproducer.c
  clang/test/Modules/crash-vfs-path-emptydir-entries.m
  clang/test/Modules/crash-vfs-path-symlink-component.m
  clang/test/Modules/crash-vfs-path-symlink-topheader.m
  clang/test/Modules/crash-vfs-path-traversal.m
  clang/test/Modules/crash-vfs-relative-overlay.m
  clang/test/Modules/crash-vfs-umbrella-frameworks.m

Index: clang/test/Modules/crash-vfs-umbrella-frameworks.m
===
--- clang/test/Modules/crash-vfs-umbrella-frameworks.m
+++ clang/test/Modules/crash-vfs-umbrella-frameworks.m
@@ -14,14 +14,12 @@
 // RUN: -F %/t/i/Frameworks -fmodules \
 // RUN: -fmodules-cache-path=%t/m/ 2>&1 | FileCheck %s
 
-// RUN: FileCheck --check-prefix=CHECKYAML %s -input-file \
-// RUN: %t/crash-vfs-*.cache/vfs/vfs.yaml
-// RUN: find %t/crash-vfs-*.cache/vfs | \
-// RUN:   grep "B.framework/Headers/B.h" | count 1
+// RUN: tar xOf %t/*.tar --wildcards "*/tmp/vfs/vfs.yaml" \
+// RUN:  | FileCheck --check-prefix=CHECKYAML %s
+// RUN: tar tf %t/*.tar | FileCheck --check-prefix=CHECKTAR %s
 
 // CHECK: Preprocessed source(s) and associated run script(s) are located at:
-// CHECK-NEXT: note: diagnostic msg: {{.*}}.m
-// CHECK-NEXT: note: diagnostic msg: {{.*}}.cache
+// CHECK-NEXT: note: diagnostic msg: {{.*}}.tar
 
 // CHECKYAML:  'type': 'directory',
 // CHECKYAML:  'name': "/[[PATH:.*]]/i/Frameworks/A.framework/Frameworks/B.framework/Headers",
@@ -39,6 +37,8 @@
 // CHECKYAML-NEXT:  'name': "B.h",
 // CHECKYAML-NEXT:  'external-contents': "/[[PATH]]/i/Frameworks/B.framework/Headers/B.h"
 
+// CHECKTAR: B.framework/Headers/B.h
+
 @import I;
 
 // Run the reproducer script - regular exit code is enough to test it works. The
@@ -51,5 +51,6 @@
 // RUN: cd %t
 // RUN: rm -rf i
 // RUN: rm -rf crash-vfs-umbrella-*.cache/modules/*
-// RUN: chmod 755 crash-vfs-*.sh
-// RUN: ./crash-vfs-*.sh
+// RUN: tar xOf %t/*.tar --wildcards "*/repro.sh" > repro.sh
+// RUN: chmod 755 repro.sh
+// RUN: ./repro.sh
Index: clang/test/Modules/crash-vfs-relative-overlay.m
===
--- clang/test/Modules/crash-vfs-relative-overlay.m
+++ clang/test/Modules/crash-vfs-relative-overlay.m
@@ -11,18 +11,18 @@
 // RUN: -I %S/Inputs/crash-recovery/usr/include -isysroot %/t/i/ \
 // RUN: -fmodules -fmodules-cache-path=%t/m/ 2>&1 | FileCheck %s
 
-// RUN: FileCheck --check-prefix=CHECKSRC %s -input-file %t/crash-vfs-*.m
-// RUN: FileCheck --check-prefix=CHECKSH %s -input-file %t/crash-vfs-*.sh
-// RUN: FileCheck --check-prefix=CHECKYAML %s -input-file \
-// RUN: %t/crash-vfs-*.cache/vfs/vfs.yaml
-// RUN: find %t/crash-vfs-*.cache/vfs | \
-// RUN:   grep "Inputs/crash-recovery/usr/include/stdio.h" | count 1
+// RUN: tar xOf %t/*.tar --wildcards "*/tmp/crash-vfs-*.m"  \
+// RUN:  | FileCheck --check-prefix=CHECKSRC %s
+// RUN: tar xOf %t/*.tar --wildcards "*/repro.sh"   \
+// RUN:  | FileCheck --check-prefix=CHECKSH %s
+// RUN: tar xOf %t/*.tar --wildcards "*/tmp/vfs/vfs.yaml"   \
+// RUN:  | FileCheck --check-prefix=CHECKYAML %s
+// RUN: tar tf %t/*.tar | FileCheck --check-prefix=CHECKTAR %s
 
 #include 
 
 // CHECK: Preprocessed source(s) and associated run script(s) are located at:
-// CHECK-NEXT: note: diagnostic msg: {{.*}}.m
-// CHECK-NEXT: note: diagnostic msg: {{.*}}.cache
+// CHECK-NEXT: note: diagnostic msg: {{.*}}.tar
 
 // CHECKSRC: #pragma clang module import cstd.stdio
 
@@ -49,6 +49,8 @@
 // CHECKYAML-NEXT: 'external-contents': "/[[PATH]]/Inputs/crash-recovery/usr/include/module.map"
 // CHECKYAML-NEXT:   },
 
+// CHECKTAR: Inputs/crash-recovery/usr/include/stdio.h
+
 // Test that reading the YAML file will yield the correct path after
 // the overlay dir is prefixed to access headers in .cache/vfs directory.
 
Index: clang/test/Modules/crash-vfs-path-traversal.m
===
--- clang/test/Modules/crash-vfs-path-traversal.m
+++ clang/test/Modules/crash-vfs-path-traversal.m
@@ -13,18 +13,18 @@
 // RUN: not %clang -fsyntax-only %s -I %S/Inputs/crash-recovery -isysroot %/t/i/ \
 // RUN: -fmodules -fmodules-cache-path=%t/m/ 2>&1 | FileCheck %s
 
-// RUN: FileCheck --check-prefix=CHECKSRC %s -input-file 

[PATCH] D121927: [Clang] Work with multiple pragmas weak before definition

2022-03-23 Thread Hubert Tong via Phabricator via cfe-commits
hubert.reinterpretcast updated this revision to Diff 417755.
hubert.reinterpretcast added a comment.

- Adjust per observation: Use DenseMapInfo for the alias pointer value


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121927

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Sema/Sema.h
  clang/include/clang/Sema/Weak.h
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/test/CodeGen/pragma-weak.c
  clang/test/PCH/pragma-weak-functional.c
  clang/test/PCH/pragma-weak-functional.h

Index: clang/test/PCH/pragma-weak-functional.h
===
--- /dev/null
+++ clang/test/PCH/pragma-weak-functional.h
@@ -0,0 +1,6 @@
+// Header for PCH test pragma-weak-functional.c
+
+#pragma weak undecfunc_alias2 = undecfunc
+#pragma weak undecfunc_alias4 = undecfunc_alias1
+#pragma weak undecfunc_alias3 = undecfunc_alias1
+#pragma weak undecfunc_alias1 = undecfunc
Index: clang/test/PCH/pragma-weak-functional.c
===
--- /dev/null
+++ clang/test/PCH/pragma-weak-functional.c
@@ -0,0 +1,17 @@
+// Test this without pch.
+// RUN: %clang_cc1 -include %S/pragma-weak-functional.h %s -verify -emit-llvm -o - | FileCheck %s
+
+// Test with pch.
+// RUN: %clang_cc1 -x c-header -emit-pch -o %t %S/pragma-weak-functional.h
+// RUN: %clang_cc1 -include-pch %t %s -verify -emit-llvm -o - | FileCheck %s
+
+// CHECK-DAG: @undecfunc_alias1 = weak{{.*}} alias void (), void ()* @undecfunc
+// CHECK-DAG: @undecfunc_alias2 = weak{{.*}} alias void (), void ()* @undecfunc
+// CHECK-DAG: @undecfunc_alias3 = weak{{.*}} alias void (), void ()* @undecfunc
+// CHECK-DAG: @undecfunc_alias4 = weak{{.*}} alias void (), void ()* @undecfunc
+
+/ PR28611: Try multiple aliases of same undeclared symbol or alias
+void undecfunc_alias1(void);
+void undecfunc(void) { }
+// expected-warning@pragma-weak-functional.h:4 {{alias will always resolve to undecfunc}}
+// expected-warning@pragma-weak-functional.h:5 {{alias will always resolve to undecfunc}}
Index: clang/test/CodeGen/pragma-weak.c
===
--- clang/test/CodeGen/pragma-weak.c
+++ clang/test/CodeGen/pragma-weak.c
@@ -17,6 +17,10 @@
 // CHECK-DAG: @mix2 = weak{{.*}} alias void (), void ()* @__mix2
 // CHECK-DAG: @a1 = weak{{.*}} alias void (), void ()* @__a1
 // CHECK-DAG: @xxx = weak{{.*}} alias void (), void ()* @__xxx
+// CHECK-DAG: @undecfunc_alias1 = weak{{.*}} alias void (), void ()* @undecfunc
+// CHECK-DAG: @undecfunc_alias2 = weak{{.*}} alias void (), void ()* @undecfunc
+// CHECK-DAG: @undecfunc_alias3 = weak{{.*}} alias void (), void ()* @undecfunc
+// CHECK-DAG: @undecfunc_alias4 = weak{{.*}} alias void (), void ()* @undecfunc
 
 
 
@@ -136,6 +140,15 @@
 __attribute((pure,noinline,const)) void __xxx(void) { }
 // CHECK: void @__xxx() [[RN:#[0-9]+]]
 
+/ PR28611: Try multiple aliases of same undeclared symbol or alias
+#pragma weak undecfunc_alias1 = undecfunc
+#pragma weak undecfunc_alias1 = undecfunc // Try specifying same alias/target pair a second time.
+#pragma weak undecfunc_alias3 = undecfunc_alias2 // expected-warning {{alias will always resolve to undecfunc}}
+#pragma weak undecfunc_alias4 = undecfunc_alias2 // expected-warning {{alias will always resolve to undecfunc}}
+#pragma weak undecfunc_alias2 = undecfunc
+void undecfunc_alias2(void);
+void undecfunc(void) { }
+
 / PR10878: Make sure we can call a weak alias
 void SHA512Pad(void *context) {}
 #pragma weak SHA384Pad = SHA512Pad
Index: clang/lib/Serialization/ASTWriter.cpp
===
--- clang/lib/Serialization/ASTWriter.cpp
+++ clang/lib/Serialization/ASTWriter.cpp
@@ -4559,13 +4559,14 @@
   // entire table, since later PCH files in a PCH chain are only interested in
   // the results at the end of the chain.
   RecordData WeakUndeclaredIdentifiers;
-  for (auto  : SemaRef.WeakUndeclaredIdentifiers) {
-IdentifierInfo *II = WeakUndeclaredIdentifier.first;
-WeakInfo  = WeakUndeclaredIdentifier.second;
-AddIdentifierRef(II, WeakUndeclaredIdentifiers);
-AddIdentifierRef(WI.getAlias(), WeakUndeclaredIdentifiers);
-AddSourceLocation(WI.getLocation(), WeakUndeclaredIdentifiers);
-WeakUndeclaredIdentifiers.push_back(WI.getUsed());
+  for (const auto  :
+   SemaRef.WeakUndeclaredIdentifiers) {
+const IdentifierInfo *const II = WeakUndeclaredIdentifierList.first;
+for (const auto  : WeakUndeclaredIdentifierList.second) {
+  AddIdentifierRef(II, WeakUndeclaredIdentifiers);
+  AddIdentifierRef(WI.getAlias(), WeakUndeclaredIdentifiers);
+  AddSourceLocation(WI.getLocation(), WeakUndeclaredIdentifiers);
+}
   }
 
   

[PATCH] D122352: [OpenMP] Do not create offloading entries for internal or hidden symbols

2022-03-23 Thread Jon Chesterfield via Phabricator via cfe-commits
JonChesterfield added a comment.

Sounds good to me too, thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122352

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


<    1   2   3   4   >