[clang-tools-extra] 45659b3 - [include-cleaner] Remove filtering from UsingDecl visit.

2022-12-08 Thread Viktoriia Bakalova via cfe-commits

Author: Viktoriia Bakalova
Date: 2022-12-08T10:23:55Z
New Revision: 45659b3bd98ea3b8ce13516bcf719669b934b9ba

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

LOG: [include-cleaner] Remove filtering from UsingDecl visit.

Removes filtering from the VisitUsingDecl method for implementation files.

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

Added: 


Modified: 
clang-tools-extra/include-cleaner/lib/WalkAST.cpp
clang-tools-extra/include-cleaner/unittests/WalkASTTest.cpp

Removed: 




diff  --git a/clang-tools-extra/include-cleaner/lib/WalkAST.cpp 
b/clang-tools-extra/include-cleaner/lib/WalkAST.cpp
index 3d338cd59b282..7fb3f5697b7ed 100644
--- a/clang-tools-extra/include-cleaner/lib/WalkAST.cpp
+++ b/clang-tools-extra/include-cleaner/lib/WalkAST.cpp
@@ -16,7 +16,6 @@
 #include "clang/AST/Type.h"
 #include "clang/AST/TypeLoc.h"
 #include "clang/Basic/SourceLocation.h"
-#include "clang/Basic/SourceManager.h"
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/Support/Casting.h"
 
@@ -27,10 +26,6 @@ using DeclCallback =
 
 class ASTWalker : public RecursiveASTVisitor {
   DeclCallback Callback;
-  // Whether we're traversing declarations coming from a header file.
-  // This helps figure out whether certain symbols can be assumed as unused
-  // (e.g. overloads brought into an implementation file, but not used).
-  bool IsHeader = false;
 
   bool handleTemplateName(SourceLocation Loc, TemplateName TN) {
 // For using-templates, only mark the alias.
@@ -50,8 +45,7 @@ class ASTWalker : public RecursiveASTVisitor {
   }
 
 public:
-  ASTWalker(DeclCallback Callback, bool IsHeader)
-  : Callback(Callback), IsHeader(IsHeader) {}
+  ASTWalker(DeclCallback Callback) : Callback(Callback) {}
 
   bool VisitDeclRefExpr(DeclRefExpr *DRE) {
 report(DRE->getLocation(), DRE->getFoundDecl());
@@ -82,10 +76,6 @@ class ASTWalker : public RecursiveASTVisitor {
 for (const auto *Shadow : UD->shadows()) {
   auto *TD = Shadow->getTargetDecl();
   auto IsUsed = TD->isUsed() || TD->isReferenced();
-  // We ignore unused overloads inside implementation files, as the ones in
-  // headers might still be used by the dependents of the header.
-  if (!IsUsed && !IsHeader)
-continue;
   report(UD->getLocation(), TD,
  IsUsed ? RefType::Explicit : RefType::Ambiguous);
 }
@@ -151,14 +141,7 @@ class ASTWalker : public RecursiveASTVisitor {
 } // namespace
 
 void walkAST(Decl , DeclCallback Callback) {
-  auto  = Root.getASTContext();
-  auto  = AST.getSourceManager();
-  // If decl isn't written in main file, assume it's coming from an include,
-  // hence written in a header.
-  bool IsRootedAtHeader =
-  AST.getLangOpts().IsHeaderFile ||
-  !SM.isWrittenInMainFile(SM.getSpellingLoc(Root.getLocation()));
-  ASTWalker(Callback, IsRootedAtHeader).TraverseDecl();
+  ASTWalker(Callback).TraverseDecl();
 }
 
 } // namespace clang::include_cleaner

diff  --git a/clang-tools-extra/include-cleaner/unittests/WalkASTTest.cpp 
b/clang-tools-extra/include-cleaner/unittests/WalkASTTest.cpp
index 17d13018d1522..d9cf84dc7abe9 100644
--- a/clang-tools-extra/include-cleaner/unittests/WalkASTTest.cpp
+++ b/clang-tools-extra/include-cleaner/unittests/WalkASTTest.cpp
@@ -26,7 +26,6 @@ namespace clang::include_cleaner {
 namespace {
 
 // Specifies a test of which symbols are referenced by a piece of code.
-// If `// c++-header` is present, treats referencing code as a header file.
 // Target should contain points annotated with the reference kind.
 // Example:
 //   Target:  int $explicit^foo();
@@ -41,8 +40,6 @@ void testWalk(llvm::StringRef TargetCode, llvm::StringRef 
ReferencingCode) {
   Inputs.ExtraArgs.push_back("-include");
   Inputs.ExtraArgs.push_back("target.h");
   Inputs.ExtraArgs.push_back("-std=c++17");
-  if (Referencing.code().contains("// c++-header\n"))
-Inputs.ExtraArgs.push_back("-xc++-header");
   TestAST AST(Inputs);
   const auto  = AST.sourceManager();
 
@@ -88,12 +85,10 @@ void testWalk(llvm::StringRef TargetCode, llvm::StringRef 
ReferencingCode) {
 auto RTStr = llvm::to_string(RT);
 for (auto Expected : Target.points(RTStr))
   if (!llvm::is_contained(ReferencedOffsets[RT], Expected))
-DiagnosePoint("location not marked used with type " + RTStr,
-  Expected);
+DiagnosePoint("location not marked used with type " + RTStr, Expected);
 for (auto Actual : ReferencedOffsets[RT])
   if (!llvm::is_contained(Target.points(RTStr), Actual))
-DiagnosePoint("location unexpectedly used with type " + RTStr,
-  Actual);
+DiagnosePoint("location unexpectedly used with type " + RTStr, Actual);
   }
 
   // If there were any 
diff 

[PATCH] D139544: [clang][dataflow] Add support for structured bindings of tuple-like types.

2022-12-08 Thread Domján Dániel via Phabricator via cfe-commits
isuckatcs added a comment.

> If CFG can be updated so that the
> synthesized variables occur in the block *before* the DeclStmt containing the
> DecompositionDecl, then we can drop the workaround that is included in this
> patch.

I'm not sure that this is possible.

If you look at the AST of the following example

  std::pair p{1, 2};
  
  auto [a, b] = p;

you get

  `-DecompositionDecl 0x55b0ac862428 'std::pair':'std::pair' cinit
|-CXXConstructExpr 
| `-ImplicitCastExpr
|   `-DeclRefExpr  'p' 
|-BindingDecl a
| |-VarDecl a
| | `-CallExpr 
| |   |-ImplicitCastExpr 
| |   | `-DeclRefExpr  'get' 
| |   `-ImplicitCastExpr 
| | `-DeclRefExpr Decomposition 0x55b0ac862428 '' 
| `-DeclRefExpr 'a' 
` ...

Basically `get<>()` is getting the element from the copy of the struct, that's 
being created when the `DecompositionDecl` happens.
The CFG reflects this accordingly.

   7: p
   8: [B1.7] (ImplicitCastExpr, NoOp, const pair)
   9: [B1.8] (CXXConstructExpr, [B1.10], std::pair)
  10: auto = p;
  11: get<0UL>
  12: [B1.11] (ImplicitCastExpr, FunctionToPointerDecay, typename 
tuple_element<0UL, pair >::type &&(*)(pair &&) noexcept)
  13:
  14: [B1.13] (ImplicitCastExpr, NoOp, std::pair)
  15: [B1.12]([B1.14])
  16: std::tuple_element<0, std::pair>::type a = get<0UL>();

Here `13` would be the `DecompositionDecl`. The variable declarations must 
appear after the `DecompositionDecl`, 
otherwhise the tuple, from which the variables are initialized cannot be 
accessed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139544

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


[PATCH] D139608: [Clang][NFC] Add default `getBFloat16Mangling` impl

2022-12-08 Thread Pierre van Houtryve via Phabricator via cfe-commits
Pierre-vh created this revision.
Pierre-vh added reviewers: MaskRay, stuij.
Herald added subscribers: kosarev, mattd, gchakrabarti, asavonic, StephenFan, 
kerbowa, jvesely.
Herald added a project: All.
Pierre-vh requested review of this revision.
Herald added subscribers: cfe-commits, jholewinski.
Herald added a project: clang.

All targets that currently implement `__bf16` use the exact same mangled name.
Reduce code duplication by adding that name to the default implementation, like 
it's done in e.g. `getLongDoubleMangling` and `getFloat128Mangling`

Depends on D139398 


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D139608

Files:
  clang/include/clang/Basic/TargetInfo.h
  clang/lib/Basic/Targets/AArch64.h
  clang/lib/Basic/Targets/AMDGPU.h
  clang/lib/Basic/Targets/ARM.h
  clang/lib/Basic/Targets/NVPTX.h
  clang/lib/Basic/Targets/X86.h


Index: clang/lib/Basic/Targets/X86.h
===
--- clang/lib/Basic/Targets/X86.h
+++ clang/lib/Basic/Targets/X86.h
@@ -415,8 +415,6 @@
   uint64_t getPointerAlignV(LangAS AddrSpace) const override {
 return getPointerWidthV(AddrSpace);
   }
-
-  const char *getBFloat16Mangling() const override { return "u6__bf16"; };
 };
 
 // X86-32 generic target
Index: clang/lib/Basic/Targets/NVPTX.h
===
--- clang/lib/Basic/Targets/NVPTX.h
+++ clang/lib/Basic/Targets/NVPTX.h
@@ -179,7 +179,6 @@
 
   bool hasBitIntType() const override { return true; }
   bool hasBFloat16Type() const override { return true; }
-  const char *getBFloat16Mangling() const override { return "u6__bf16"; };
 };
 } // namespace targets
 } // namespace clang
Index: clang/lib/Basic/Targets/ARM.h
===
--- clang/lib/Basic/Targets/ARM.h
+++ clang/lib/Basic/Targets/ARM.h
@@ -197,8 +197,6 @@
   bool hasSjLjLowering() const override;
 
   bool hasBitIntType() const override { return true; }
-
-  const char *getBFloat16Mangling() const override { return "u6__bf16"; };
 };
 
 class LLVM_LIBRARY_VISIBILITY ARMleTargetInfo : public ARMTargetInfo {
Index: clang/lib/Basic/Targets/AMDGPU.h
===
--- clang/lib/Basic/Targets/AMDGPU.h
+++ clang/lib/Basic/Targets/AMDGPU.h
@@ -116,7 +116,6 @@
   }
 
   bool hasBFloat16Type() const override { return isAMDGCN(getTriple()); }
-  const char *getBFloat16Mangling() const override { return "u6__bf16"; };
 
   const char *getClobbers() const override { return ""; }
 
Index: clang/lib/Basic/Targets/AArch64.h
===
--- clang/lib/Basic/Targets/AArch64.h
+++ clang/lib/Basic/Targets/AArch64.h
@@ -167,7 +167,6 @@
 
   int getEHDataRegisterNumber(unsigned RegNo) const override;
 
-  const char *getBFloat16Mangling() const override { return "u6__bf16"; };
   bool hasInt128Type() const override;
 
   bool hasBitIntType() const override { return true; }
Index: clang/include/clang/Basic/TargetInfo.h
===
--- clang/include/clang/Basic/TargetInfo.h
+++ clang/include/clang/Basic/TargetInfo.h
@@ -758,9 +758,7 @@
   }
 
   /// Return the mangled code of bfloat.
-  virtual const char *getBFloat16Mangling() const {
-llvm_unreachable("bfloat not implemented on this target");
-  }
+  virtual const char *getBFloat16Mangling() const { return "u6__bf16"; }
 
   /// Return the value for the C99 FLT_EVAL_METHOD macro.
   virtual LangOptions::FPEvalMethodKind getFPEvalMethod() const {


Index: clang/lib/Basic/Targets/X86.h
===
--- clang/lib/Basic/Targets/X86.h
+++ clang/lib/Basic/Targets/X86.h
@@ -415,8 +415,6 @@
   uint64_t getPointerAlignV(LangAS AddrSpace) const override {
 return getPointerWidthV(AddrSpace);
   }
-
-  const char *getBFloat16Mangling() const override { return "u6__bf16"; };
 };
 
 // X86-32 generic target
Index: clang/lib/Basic/Targets/NVPTX.h
===
--- clang/lib/Basic/Targets/NVPTX.h
+++ clang/lib/Basic/Targets/NVPTX.h
@@ -179,7 +179,6 @@
 
   bool hasBitIntType() const override { return true; }
   bool hasBFloat16Type() const override { return true; }
-  const char *getBFloat16Mangling() const override { return "u6__bf16"; };
 };
 } // namespace targets
 } // namespace clang
Index: clang/lib/Basic/Targets/ARM.h
===
--- clang/lib/Basic/Targets/ARM.h
+++ clang/lib/Basic/Targets/ARM.h
@@ -197,8 +197,6 @@
   bool hasSjLjLowering() const override;
 
   bool hasBitIntType() const override { return true; }
-
-  const char *getBFloat16Mangling() const override { return "u6__bf16"; };
 };
 
 class LLVM_LIBRARY_VISIBILITY ARMleTargetInfo : public ARMTargetInfo {
Index: 

[PATCH] D127910: [Clang][AArch64] Add SME C intrinsics for load and store

2022-12-08 Thread Bryan Chan via Phabricator via cfe-commits
bryanpkc updated this revision to Diff 481205.
bryanpkc added a comment.

Removed some more unnecessary lines.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127910

Files:
  clang/include/clang/Basic/BuiltinsSME.def
  clang/include/clang/Basic/CMakeLists.txt
  clang/include/clang/Basic/TargetBuiltins.h
  clang/include/clang/Basic/arm_sme.td
  clang/include/clang/Basic/arm_sve.td
  clang/include/clang/Basic/arm_sve_sme_incl.td
  clang/lib/Basic/Targets/AArch64.cpp
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/lib/Headers/CMakeLists.txt
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/CodeGen/aarch64-sme-intrinsics/acle_sme_int_const_expr_error.c
  clang/test/CodeGen/aarch64-sme-intrinsics/acle_sme_ld1.c
  clang/test/CodeGen/aarch64-sme-intrinsics/acle_sme_ld1_vnum.c
  clang/test/CodeGen/aarch64-sme-intrinsics/acle_sme_st1.c
  clang/test/CodeGen/aarch64-sme-intrinsics/acle_sme_st1_vnum.c
  clang/utils/TableGen/SveEmitter.cpp
  clang/utils/TableGen/TableGen.cpp
  clang/utils/TableGen/TableGenBackends.h

Index: clang/utils/TableGen/TableGenBackends.h
===
--- clang/utils/TableGen/TableGenBackends.h
+++ clang/utils/TableGen/TableGenBackends.h
@@ -101,6 +101,12 @@
 void EmitSveTypeFlags(llvm::RecordKeeper , llvm::raw_ostream );
 void EmitSveRangeChecks(llvm::RecordKeeper , llvm::raw_ostream );
 
+void EmitSmeHeader(llvm::RecordKeeper , llvm::raw_ostream );
+void EmitSmeBuiltins(llvm::RecordKeeper , llvm::raw_ostream );
+void EmitSmeBuiltinCG(llvm::RecordKeeper , llvm::raw_ostream );
+void EmitSmeTypeFlags(llvm::RecordKeeper , llvm::raw_ostream );
+void EmitSmeRangeChecks(llvm::RecordKeeper , llvm::raw_ostream );
+
 void EmitMveHeader(llvm::RecordKeeper , llvm::raw_ostream );
 void EmitMveBuiltinDef(llvm::RecordKeeper , llvm::raw_ostream );
 void EmitMveBuiltinSema(llvm::RecordKeeper , llvm::raw_ostream );
Index: clang/utils/TableGen/TableGen.cpp
===
--- clang/utils/TableGen/TableGen.cpp
+++ clang/utils/TableGen/TableGen.cpp
@@ -81,6 +81,11 @@
   GenArmSveBuiltinCG,
   GenArmSveTypeFlags,
   GenArmSveRangeChecks,
+  GenArmSmeHeader,
+  GenArmSmeBuiltins,
+  GenArmSmeBuiltinCG,
+  GenArmSmeTypeFlags,
+  GenArmSmeRangeChecks,
   GenArmCdeHeader,
   GenArmCdeBuiltinDef,
   GenArmCdeBuiltinSema,
@@ -219,6 +224,16 @@
"Generate arm_sve_typeflags.inc for clang"),
 clEnumValN(GenArmSveRangeChecks, "gen-arm-sve-sema-rangechecks",
"Generate arm_sve_sema_rangechecks.inc for clang"),
+clEnumValN(GenArmSmeHeader, "gen-arm-sme-header",
+   "Generate arm_sme.h for clang"),
+clEnumValN(GenArmSmeBuiltins, "gen-arm-sme-builtins",
+   "Generate arm_sme_builtins.inc for clang"),
+clEnumValN(GenArmSmeBuiltinCG, "gen-arm-sme-builtin-codegen",
+   "Generate arm_sme_builtin_cg_map.inc for clang"),
+clEnumValN(GenArmSmeTypeFlags, "gen-arm-sme-typeflags",
+   "Generate arm_sme_typeflags.inc for clang"),
+clEnumValN(GenArmSmeRangeChecks, "gen-arm-sme-sema-rangechecks",
+   "Generate arm_sme_sema_rangechecks.inc for clang"),
 clEnumValN(GenArmMveHeader, "gen-arm-mve-header",
"Generate arm_mve.h for clang"),
 clEnumValN(GenArmMveBuiltinDef, "gen-arm-mve-builtin-def",
@@ -438,6 +453,21 @@
   case GenArmSveRangeChecks:
 EmitSveRangeChecks(Records, OS);
 break;
+  case GenArmSmeHeader:
+EmitSmeHeader(Records, OS);
+break;
+  case GenArmSmeBuiltins:
+EmitSmeBuiltins(Records, OS);
+break;
+  case GenArmSmeBuiltinCG:
+EmitSmeBuiltinCG(Records, OS);
+break;
+  case GenArmSmeTypeFlags:
+EmitSmeTypeFlags(Records, OS);
+break;
+  case GenArmSmeRangeChecks:
+EmitSmeRangeChecks(Records, OS);
+break;
   case GenArmCdeHeader:
 EmitCdeHeader(Records, OS);
 break;
Index: clang/utils/TableGen/SveEmitter.cpp
===
--- clang/utils/TableGen/SveEmitter.cpp
+++ clang/utils/TableGen/SveEmitter.cpp
@@ -228,7 +228,7 @@
   }
 
   /// Emits the intrinsic declaration to the ostream.
-  void emitIntrinsic(raw_ostream ) const;
+  void emitIntrinsic(raw_ostream , SVEEmitter ) const;
 
 private:
   std::string getMergeSuffix() const { return MergeSuffix; }
@@ -346,8 +346,24 @@
   /// Create the SVETypeFlags used in CGBuiltins
   void createTypeFlags(raw_ostream );
 
+  /// Emit arm_sme.h.
+  void createSMEHeader(raw_ostream );
+
+  /// Emit all the SME __builtin prototypes and code needed by Sema.
+  void createSMEBuiltins(raw_ostream );
+
+  /// Emit all the information needed to map builtin -> LLVM IR intrinsic.
+  void createSMECodeGenMap(raw_ostream );
+
+  /// Emit all the range checks for the immediates.
+  

[PATCH] D134859: [clang][Interp] Implement basic support for floating point values

2022-12-08 Thread Timm Bäder via Phabricator via cfe-commits
tbaeder updated this revision to Diff 481190.
tbaeder added a comment.

Remove conversion in `Floating::add()` and tests that relied on it. Compound 
assignment operators can be properly implemented later.


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

https://reviews.llvm.org/D134859

Files:
  clang/lib/AST/CMakeLists.txt
  clang/lib/AST/Interp/Boolean.h
  clang/lib/AST/Interp/ByteCodeExprGen.cpp
  clang/lib/AST/Interp/ByteCodeExprGen.h
  clang/lib/AST/Interp/Context.cpp
  clang/lib/AST/Interp/Descriptor.cpp
  clang/lib/AST/Interp/Floating.cpp
  clang/lib/AST/Interp/Floating.h
  clang/lib/AST/Interp/Integral.h
  clang/lib/AST/Interp/Interp.cpp
  clang/lib/AST/Interp/Interp.h
  clang/lib/AST/Interp/InterpStack.h
  clang/lib/AST/Interp/Opcodes.td
  clang/lib/AST/Interp/PrimType.h
  clang/lib/AST/Interp/Primitives.h
  clang/test/AST/Interp/const-fpfeatures.cpp
  clang/test/AST/Interp/floats.cpp
  clang/test/SemaCXX/rounding-math.cpp

Index: clang/test/SemaCXX/rounding-math.cpp
===
--- clang/test/SemaCXX/rounding-math.cpp
+++ clang/test/SemaCXX/rounding-math.cpp
@@ -1,5 +1,6 @@
 // RUN: %clang_cc1 -triple x86_64-linux -verify=norounding -Wno-unknown-pragmas %s
 // RUN: %clang_cc1 -triple x86_64-linux -verify=rounding %s -frounding-math -Wno-unknown-pragmas
+// RUN: %clang_cc1 -triple x86_64-linux -verify=rounding %s -frounding-math -fexperimental-new-constant-interpreter -Wno-unknown-pragmas
 // rounding-no-diagnostics
 
 #define fold(x) (__builtin_constant_p(x) ? (x) : (x))
Index: clang/test/AST/Interp/floats.cpp
===
--- /dev/null
+++ clang/test/AST/Interp/floats.cpp
@@ -0,0 +1,50 @@
+// RUN: %clang_cc1 -fexperimental-new-constant-interpreter -verify %s
+// RUN: %clang_cc1 -verify=ref %s
+
+constexpr int i = 2;
+constexpr float f = 1.0f;
+static_assert(f == 1.0f, "");
+
+constexpr float f2 = 1u * f;
+static_assert(f2 == 1.0f, "");
+
+constexpr float f3 = 1.5;
+constexpr int i3 = f3;
+static_assert(i3 == 1);
+
+constexpr bool b3 = f3;
+static_assert(b3);
+
+
+static_assert(1.0f + 3u == 4, "");
+static_assert(4.0f / 1.0f == 4, "");
+static_assert(10.0f * false == 0, "");
+
+constexpr float floats[] = {1.0f, 2.0f, 3.0f, 4.0f};
+
+constexpr float m = 5.0f / 0.0f; // ref-error {{must be initialized by a constant expression}} \
+ // ref-note {{division by zero}} \
+ // expected-error {{must be initialized by a constant expression}} \
+ // expected-note {{division by zero}}
+
+static_assert(~2.0f == 3, ""); // ref-error {{invalid argument type 'float' to unary expression}} \
+   // expected-error {{invalid argument type 'float' to unary expression}}
+
+/// Initialized by a double.
+constexpr float df = 0.0;
+/// The other way around.
+constexpr double fd = 0.0f;
+
+static_assert(0.0f == -0.0f, "");
+
+const int k = 3 * (1.0f / 3.0f);
+static_assert(k == 1, "");
+
+constexpr bool b = 1.0;
+static_assert(b, "");
+
+constexpr double db = true;
+static_assert(db == 1.0, "");
+
+constexpr float fa[] = {1.0f, 2.0, 1, false};
+constexpr float da[] = {1.0f, 2.0, 1, false};
Index: clang/test/AST/Interp/const-fpfeatures.cpp
===
--- /dev/null
+++ clang/test/AST/Interp/const-fpfeatures.cpp
@@ -0,0 +1,74 @@
+// RUN: %clang_cc1 -S -emit-llvm -triple i386-linux -std=c++2a -Wno-unknown-pragmas %s -o - | FileCheck %s
+// RUN: %clang_cc1 -S -emit-llvm -triple i386-linux -fexperimental-new-constant-interpreter -std=c++2a -Wno-unknown-pragmas %s -o - | FileCheck %s
+
+
+#pragma STDC FENV_ROUND FE_UPWARD
+
+float F1u = 1.0F + 0x0.02p0F;
+float F2u = 1.0F + 0x0.01p0F;
+float F3u = 0x1.01p0;
+// CHECK: @F1u = {{.*}} float 0x3FF02000
+// CHECK: @F2u = {{.*}} float 0x3FF02000
+// CHECK: @F3u = {{.*}} float 0x3FF02000
+
+float FI1u = 0xU;
+// CHECK: @FI1u = {{.*}} float 0x41F0
+
+#pragma STDC FENV_ROUND FE_DOWNWARD
+
+float F1d = 1.0F + 0x0.02p0F;
+float F2d = 1.0F + 0x0.01p0F;
+float F3d = 0x1.01p0;
+
+// CHECK: @F1d = {{.*}} float 0x3FF02000
+// CHECK: @F2d = {{.*}} float 1.00e+00
+// CHECK: @F3d = {{.*}} float 1.00e+00
+
+
+float FI1d = 0xU;
+// CHECK: @FI1d = {{.*}} float 0x41EFE000
+
+// nextUp(1.F) == 0x1.02p0F
+
+constexpr float add_round_down(float x, float y) {
+  #pragma STDC FENV_ROUND FE_DOWNWARD
+  float res = x;
+  res += y;
+  return res;
+}
+
+constexpr float add_round_up(float x, float y) {
+  #pragma STDC FENV_ROUND FE_UPWARD
+  float res = x;
+  res += y;
+  return res;
+}
+
+float V1 = add_round_down(1.0F, 0x0.01p0F);
+float V2 = add_round_up(1.0F, 0x0.01p0F);
+// CHECK: @V1 = {{.*}} float 1.00e+00
+// CHECK: @V2 = {{.*}} float 0x3FF02000
+
+
+/// FIXME: The 

[PATCH] D138821: [include-cleaner] Remove filtering from UsingDecl visit.

2022-12-08 Thread Haojian Wu via Phabricator via cfe-commits
hokein accepted this revision.
hokein added a comment.
This revision is now accepted and ready to land.

Thanks.

You can add a `Fix: https://github.com/llvm/llvm-project/issues/59147` in the 
commit message, it will automatically close the github issue when you commit 
the patch.




Comment at: clang-tools-extra/include-cleaner/unittests/WalkASTTest.cpp:144
+  class $ambiguous^Y {};
+}
+)cpp",

nit: merge the following line with this line, `})cpp"`



Comment at: clang-tools-extra/include-cleaner/unittests/WalkASTTest.cpp:152
+}
+   using ns::$explicit^Y; 
+)cpp",

nit: fix the alignment  



Comment at: clang-tools-extra/include-cleaner/unittests/WalkASTTest.cpp:153
+   using ns::$explicit^Y; 
+)cpp",
+   "^Y x;");

nit: and here as well.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D138821

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


[PATCH] D136594: [clangd] Add support for semantic token type "operator"

2022-12-08 Thread Nathan Ridge via Phabricator via cfe-commits
nridge added a comment.

In D136594#3973908 , @ckandeler wrote:

> In D136594#3973812 , @sammccall 
> wrote:
>
>> For my part, I still need to understand why we want the 
>> `builtin`/`UserModified` modifier. (The `operator` highlight kind seems 
>> obvious to me).
>
> We make this distinction in our client. The reasoning is explained here: 
> https://codereview.qt-project.org/c/qt-creator/qt-creator/+/220587
> I think Nathan made the same point earlier, i.e. it's helpful to see that an 
> operator is (potentially) overloaded and you could follow the symbol.

Yeah, basically, if I'm looking at `a + b`, and the `+` is actually a 
syntactically disguised function call, I'd like to know about it, i.e. I'd like 
to be able to make my editor color //that// `+` differently than the case where 
`a` and `b` are e.g. `int`s.

I do think that there are two potential routes to get there:

1. Only produce a semantic token in the `UserProvided` case. The `Builtin` case 
doesn't get an `operator` semantic token at all, hence there's no need for a 
modifier. As a user, I configure my editor to color all `operator` tokens 
prominently.
2. Produce a semantic token in both the `Builtin` and `UserProvided` cases, but 
with the modifier to distinguish between them (i.e. the current patch). As a 
user, I configure my editor to color `operator` tokens with the `UserProvided` 
modifier prominently.

The advantage of (2) over (1) is that built-in operators get a semantic token 
to distinguish them from declarators (i.e. what Sam brought up in this comment 
 starting at "An (IMO) useful 
distinction that can't be found by the lexer ...").

The advantage of (1) over (2) is that the primary intended effect (overloaded 
operators are highlighted prominently) can be achieved with less configuration 
(no custom modifier).

If we care more about how things look out of the box (i.e. with a theme that 
provides colors only for the operators/modifiers in the LSP spec), perhaps we 
should prefer (1) over (2), in spite of the declarator/operator issue?

I don't have a strong preference between these options. (But I do have a strong 
preference for being able to make overloaded operators look different from 
built-in operators, whether that difference is modifier vs. no modifier, or 
semantic token vs. no semantic token at all.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136594

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


[PATCH] D139507: [Intrinsic] Add get.rounding as alias to flt.rounds and rename related DAG nodes

2022-12-08 Thread Nikita Popov via Phabricator via cfe-commits
nikic requested changes to this revision.
nikic added a comment.
This revision now requires changes to proceed.

In D139507#3980555 , @qiucf wrote:

> In D139507#3978449 , @sepavloff 
> wrote:
>
>> Thank you for working on this!
>>
>> Is there any reason why we should keep the old intrinsic?
>
> In case any user outside of clang references it (although I believe no), we 
> can deprecate it and remove after a few releases.

This is not how intrinsic changes work. You need to add AutoUpgrade support.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139507

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


[PATCH] D139612: [Clang][LoongArch] Add intrinsic for iocsrrd and iocsrwr

2022-12-08 Thread Gong LingQin via Phabricator via cfe-commits
gonglingqin created this revision.
gonglingqin added reviewers: xen0n, xry111, SixWeining, wangleiat, MaskRay, 
XiaodongLoong.
Herald added subscribers: StephenFan, hiraditya.
Herald added a project: All.
gonglingqin requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

These intrinsics are required by Linux [1].

[1]: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/loongarch/include/asm/loongarch.h#n240


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D139612

Files:
  clang/include/clang/Basic/BuiltinsLoongArch.def
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Headers/larchintrin.h
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/LoongArch/intrinsic-la32-error.c
  clang/test/CodeGen/LoongArch/intrinsic-la32.c
  clang/test/CodeGen/LoongArch/intrinsic-la64.c
  llvm/include/llvm/IR/IntrinsicsLoongArch.td
  llvm/lib/Target/LoongArch/LoongArchISelLowering.cpp
  llvm/lib/Target/LoongArch/LoongArchISelLowering.h
  llvm/lib/Target/LoongArch/LoongArchInstrInfo.td
  llvm/test/CodeGen/LoongArch/intrinsic-la32-error.ll
  llvm/test/CodeGen/LoongArch/intrinsic-la64.ll
  llvm/test/CodeGen/LoongArch/intrinsic.ll

Index: llvm/test/CodeGen/LoongArch/intrinsic.ll
===
--- llvm/test/CodeGen/LoongArch/intrinsic.ll
+++ llvm/test/CodeGen/LoongArch/intrinsic.ll
@@ -9,6 +9,12 @@
 declare i32 @llvm.loongarch.csrrd.w(i32 immarg)
 declare i32 @llvm.loongarch.csrwr.w(i32, i32 immarg)
 declare i32 @llvm.loongarch.csrxchg.w(i32, i32, i32 immarg)
+declare i32 @llvm.loongarch.iocsrrd.b(i32)
+declare i32 @llvm.loongarch.iocsrrd.h(i32)
+declare i32 @llvm.loongarch.iocsrrd.w(i32)
+declare void @llvm.loongarch.iocsrwr.b(i32, i32)
+declare void @llvm.loongarch.iocsrwr.h(i32, i32)
+declare void @llvm.loongarch.iocsrwr.w(i32, i32)
 
 define void @foo() nounwind {
 ; CHECK-LABEL: foo:
@@ -79,3 +85,63 @@
   %0 = tail call i32 @llvm.loongarch.csrxchg.w(i32 %a, i32 %b, i32 1)
   ret i32 %0
 }
+
+define i32 @iocsrrd_b(i32 %a) {
+; CHECK-LABEL: iocsrrd_b:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:iocsrrd.b $a0, $a0
+; CHECK-NEXT:ret
+entry:
+  %0 = tail call i32 @llvm.loongarch.iocsrrd.b(i32 %a)
+  ret i32 %0
+}
+
+define i32 @iocsrrd_h(i32 %a) {
+; CHECK-LABEL: iocsrrd_h:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:iocsrrd.h $a0, $a0
+; CHECK-NEXT:ret
+entry:
+  %0 = tail call i32 @llvm.loongarch.iocsrrd.h(i32 %a)
+  ret i32 %0
+}
+
+define i32 @iocsrrd_w(i32 %a) {
+; CHECK-LABEL: iocsrrd_w:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:iocsrrd.w $a0, $a0
+; CHECK-NEXT:ret
+entry:
+  %0 = tail call i32 @llvm.loongarch.iocsrrd.w(i32 %a)
+  ret i32 %0
+}
+
+define void @iocsrwr_b(i32 %a, i32 %b) {
+; CHECK-LABEL: iocsrwr_b:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:iocsrwr.b $a0, $a1
+; CHECK-NEXT:ret
+entry:
+  tail call void @llvm.loongarch.iocsrwr.b(i32 %a, i32 %b)
+  ret void
+}
+
+define void @iocsrwr_h(i32 %a, i32 %b) {
+; CHECK-LABEL: iocsrwr_h:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:iocsrwr.h $a0, $a1
+; CHECK-NEXT:ret
+entry:
+  tail call void @llvm.loongarch.iocsrwr.h(i32 %a, i32 %b)
+  ret void
+}
+
+define void @iocsrwr_w(i32 %a, i32 %b) {
+; CHECK-LABEL: iocsrwr_w:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:iocsrwr.w $a0, $a1
+; CHECK-NEXT:ret
+entry:
+  tail call void @llvm.loongarch.iocsrwr.w(i32 %a, i32 %b)
+  ret void
+}
Index: llvm/test/CodeGen/LoongArch/intrinsic-la64.ll
===
--- llvm/test/CodeGen/LoongArch/intrinsic-la64.ll
+++ llvm/test/CodeGen/LoongArch/intrinsic-la64.ll
@@ -12,6 +12,8 @@
 declare i64 @llvm.loongarch.csrrd.d(i32 immarg)
 declare i64 @llvm.loongarch.csrwr.d(i64, i32 immarg)
 declare i64 @llvm.loongarch.csrxchg.d(i64, i64, i32 immarg)
+declare i64 @llvm.loongarch.iocsrrd.d(i32)
+declare void @llvm.loongarch.iocsrwr.d(i64, i32)
 
 define i32 @crc_w_b_w(i32 %a, i32 %b) nounwind {
 ; CHECK-LABEL: crc_w_b_w:
@@ -114,3 +116,23 @@
   %0 = tail call i64 @llvm.loongarch.csrxchg.d(i64 %a, i64 %b, i32 1)
   ret i64 %0
 }
+
+define i64 @iocsrrd_d(i32 %a) {
+; CHECK-LABEL: iocsrrd_d:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:iocsrrd.d $a0, $a0
+; CHECK-NEXT:ret
+entry:
+  %0 = tail call i64 @llvm.loongarch.iocsrrd.d(i32 %a)
+  ret i64 %0
+}
+
+define void @iocsrwr_d(i64 %a, i32 signext %b) {
+; CHECK-LABEL: iocsrwr_d:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:iocsrwr.d $a0, $a1
+; CHECK-NEXT:ret
+entry:
+  tail call void @llvm.loongarch.iocsrwr.d(i64 %a, i32 %b)
+  ret void
+}
Index: llvm/test/CodeGen/LoongArch/intrinsic-la32-error.ll
===
--- llvm/test/CodeGen/LoongArch/intrinsic-la32-error.ll
+++ llvm/test/CodeGen/LoongArch/intrinsic-la32-error.ll
@@ -11,6 +11,8 @@
 declare i64 @llvm.loongarch.csrrd.d(i32 

[PATCH] D139398: [AMDGPU] Add bf16 storage support

2022-12-08 Thread Pierre van Houtryve via Phabricator via cfe-commits
Pierre-vh added inline comments.



Comment at: clang/lib/Basic/Targets/AMDGPU.h:119
+  bool hasBFloat16Type() const override { return isAMDGCN(getTriple()); }
+  const char *getBFloat16Mangling() const override { return "u6__bf16"; };
+

arsenm wrote:
> Pierre-vh wrote:
> > Pierre-vh wrote:
> > > arsenm wrote:
> > > > Don't understand this mangling. What is u6?
> > > Not sure; for that one I just copy-pasted the implementation of other 
> > > targets. All other targets use that mangling scheme
> > Ah I remember now, it's just C++ mangling. I don't quite understand the 
> > lowercase "u" but a quick search in Clang tells me it's vendor-extended 
> > types.
> > So it's just u6 -> vendor extended type, 6 characters following + __bf16 
> > (name of the type).
> Do we really need an override for this? I'd expect a reasonable default. Plus 
> I think a virtual function for something that's only a parameterless, static 
> string is a bit ridiculous
Default impl asserts if not implemented. I think it's to make sure targets are 
all aware of what it takes to support bfloat and they don't end up partially 
implementing it?
```
  /// Return the mangled code of bfloat.
  virtual const char *getBFloat16Mangling() const {
llvm_unreachable("bfloat not implemented on this target");
  }
```

 I'd say let's stick to the current pattern in this diff; I created D139608 to 
change it



Comment at: llvm/lib/Target/AMDGPU/AMDGPUCallingConv.td:49
+  CCIfType<[bf16], CCBitConvertToType>,
+  CCIfType<[v2bf16], CCBitConvertToType>,
   CCIfNotInReg Without being added to a register class, all the tablegen changes should not 
> do anything
bf16 ones seem to not be needed but if I don't have the v2bf16 ones I get 
"cannot allocate arguments" in "test_arg_store_v2bf16"


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139398

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


[clang] 579f3f0 - [LoongArch] Rename the test file and separate the tests on LA32 and LA64. NFC.

2022-12-08 Thread via cfe-commits

Author: gonglingqin
Date: 2022-12-08T16:24:45+08:00
New Revision: 579f3f0606c351e9a939e1265d61cb9ace2adac8

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

LOG: [LoongArch] Rename the test file and separate the tests on LA32 and LA64. 
NFC.

Use intrinsic-la32*.c to test the intrinsics of loongarch32.
Use intrinsic-la64*.c to test the intrinsics of loongarch64.

Added: 
clang/test/CodeGen/LoongArch/intrinsic-la32-error.c
clang/test/CodeGen/LoongArch/intrinsic-la32.c
clang/test/CodeGen/LoongArch/intrinsic-la64-error.c

Modified: 
clang/test/CodeGen/LoongArch/intrinsic-la64.c

Removed: 
clang/test/CodeGen/LoongArch/intrinsic-error-la64.c
clang/test/CodeGen/LoongArch/intrinsic-error.c
clang/test/CodeGen/LoongArch/intrinsic.c



diff  --git a/clang/test/CodeGen/LoongArch/intrinsic-error.c 
b/clang/test/CodeGen/LoongArch/intrinsic-la32-error.c
similarity index 100%
rename from clang/test/CodeGen/LoongArch/intrinsic-error.c
rename to clang/test/CodeGen/LoongArch/intrinsic-la32-error.c

diff  --git a/clang/test/CodeGen/LoongArch/intrinsic.c 
b/clang/test/CodeGen/LoongArch/intrinsic-la32.c
similarity index 56%
rename from clang/test/CodeGen/LoongArch/intrinsic.c
rename to clang/test/CodeGen/LoongArch/intrinsic-la32.c
index 5dc788abdbb0e..ec74a3da7e3f4 100644
--- a/clang/test/CodeGen/LoongArch/intrinsic.c
+++ b/clang/test/CodeGen/LoongArch/intrinsic-la32.c
@@ -1,8 +1,6 @@
 // NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
 // RUN: %clang_cc1 -triple loongarch32 -emit-llvm %s -o - \
 // RUN: | FileCheck %s -check-prefix=LA32
-// RUN: %clang_cc1 -triple loongarch64 -emit-llvm %s -o - \
-// RUN: | FileCheck %s -check-prefix=LA64
 
 #include 
 
@@ -11,11 +9,6 @@
 // LA32-NEXT:call void @llvm.loongarch.dbar(i32 0)
 // LA32-NEXT:ret void
 //
-// LA64-LABEL: @dbar(
-// LA64-NEXT:  entry:
-// LA64-NEXT:call void @llvm.loongarch.dbar(i32 0)
-// LA64-NEXT:ret void
-//
 void dbar() {
   return __builtin_loongarch_dbar(0);
 }
@@ -25,11 +18,6 @@ void dbar() {
 // LA32-NEXT:call void @llvm.loongarch.ibar(i32 0)
 // LA32-NEXT:ret void
 //
-// LA64-LABEL: @ibar(
-// LA64-NEXT:  entry:
-// LA64-NEXT:call void @llvm.loongarch.ibar(i32 0)
-// LA64-NEXT:ret void
-//
 void ibar() {
   return __builtin_loongarch_ibar(0);
 }
@@ -39,11 +27,6 @@ void ibar() {
 // LA32-NEXT:call void @llvm.loongarch.break(i32 1)
 // LA32-NEXT:ret void
 //
-// LA64-LABEL: @loongarch_break(
-// LA64-NEXT:  entry:
-// LA64-NEXT:call void @llvm.loongarch.break(i32 1)
-// LA64-NEXT:ret void
-//
 void loongarch_break() {
   __builtin_loongarch_break(1);
 }
@@ -53,11 +36,6 @@ void loongarch_break() {
 // LA32-NEXT:call void @llvm.loongarch.syscall(i32 1)
 // LA32-NEXT:ret void
 //
-// LA64-LABEL: @syscall(
-// LA64-NEXT:  entry:
-// LA64-NEXT:call void @llvm.loongarch.syscall(i32 1)
-// LA64-NEXT:ret void
-//
 void syscall() {
   __builtin_loongarch_syscall(1);
 }
@@ -72,16 +50,6 @@ void syscall() {
 // LA32-NEXT:store i32 [[TMP1]], ptr [[B]], align 4
 // LA32-NEXT:ret i32 0
 //
-// LA64-LABEL: @csrrd_w(
-// LA64-NEXT:  entry:
-// LA64-NEXT:[[A:%.*]] = alloca i32, align 4
-// LA64-NEXT:[[B:%.*]] = alloca i32, align 4
-// LA64-NEXT:[[TMP0:%.*]] = call i32 @llvm.loongarch.csrrd.w(i32 1)
-// LA64-NEXT:store i32 [[TMP0]], ptr [[A]], align 4
-// LA64-NEXT:[[TMP1:%.*]] = call i32 @llvm.loongarch.csrrd.w(i32 1)
-// LA64-NEXT:store i32 [[TMP1]], ptr [[B]], align 4
-// LA64-NEXT:ret i32 0
-//
 unsigned int csrrd_w() {
   unsigned int a = __csrrd_w(1);
   unsigned int b = __builtin_loongarch_csrrd_w(1);
@@ -102,20 +70,6 @@ unsigned int csrrd_w() {
 // LA32-NEXT:store i32 [[TMP3]], ptr [[C]], align 4
 // LA32-NEXT:ret i32 0
 //
-// LA64-LABEL: @csrwr_w(
-// LA64-NEXT:  entry:
-// LA64-NEXT:[[A_ADDR:%.*]] = alloca i32, align 4
-// LA64-NEXT:[[B:%.*]] = alloca i32, align 4
-// LA64-NEXT:[[C:%.*]] = alloca i32, align 4
-// LA64-NEXT:store i32 [[A:%.*]], ptr [[A_ADDR]], align 4
-// LA64-NEXT:[[TMP0:%.*]] = load i32, ptr [[A_ADDR]], align 4
-// LA64-NEXT:[[TMP1:%.*]] = call i32 @llvm.loongarch.csrwr.w(i32 [[TMP0]], 
i32 1)
-// LA64-NEXT:store i32 [[TMP1]], ptr [[B]], align 4
-// LA64-NEXT:[[TMP2:%.*]] = load i32, ptr [[A_ADDR]], align 4
-// LA64-NEXT:[[TMP3:%.*]] = call i32 @llvm.loongarch.csrwr.w(i32 [[TMP2]], 
i32 1)
-// LA64-NEXT:store i32 [[TMP3]], ptr [[C]], align 4
-// LA64-NEXT:ret i32 0
-//
 unsigned int csrwr_w(unsigned int a) {
   unsigned int b = __csrwr_w(a, 1);
   unsigned int c = __builtin_loongarch_csrwr_w(a, 1);
@@ -140,24 +94,6 @@ unsigned int csrwr_w(unsigned int a) {
 // LA32-NEXT:store i32 [[TMP5]], ptr [[D]], align 4
 // 

[PATCH] D139087: [include-cleaner] Handle base class member access from derived class.

2022-12-08 Thread Haojian Wu via Phabricator via cfe-commits
hokein accepted this revision.
hokein added a comment.
This revision is now accepted and ready to land.

Thanks, looks good.

Add a `Fix ` in the commit message.




Comment at: clang-tools-extra/include-cleaner/lib/WalkAST.cpp:67
 
   bool VisitMemberExpr(MemberExpr *E) {
+// A member expr implies a usage of the class type

while reading it again, I realize that there is another case (operator 
overloading) we probably want to handle it as well. It is a more tricky case, 
no need to worry about it in this patch. 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139087

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


[PATCH] D139507: [Intrinsic] Add get.rounding as alias to flt.rounds and rename related DAG nodes

2022-12-08 Thread Serge Pavlov via Phabricator via cfe-commits
sepavloff added a comment.

LGTM.

In D139507#3980555 , @qiucf wrote:

> In D139507#3978449 , @sepavloff 
> wrote:
>
>> Thank you for working on this!
>>
>> Is there any reason why we should keep the old intrinsic?
>
> In case any user outside of clang references it (although I believe no), we 
> can deprecate it and remove after a few releases.

Yes, this could be a good solution.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139507

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


[clang] a96a6ed - Implement CWG2631

2022-12-08 Thread Corentin Jabot via cfe-commits

Author: Corentin Jabot
Date: 2022-12-08T10:32:54+01:00
New Revision: a96a6ed83230265f3eab09a94f0e9525d05f8a74

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

LOG: Implement CWG2631

Implement https://cplusplus.github.io/CWG/issues/2631.html.

Immediate calls in default arguments and defaults members
are not evaluated.

Instead, we evaluate them when constructing a
`CXXDefaultArgExpr`/`BuildCXXDefaultInitExpr`.

The immediate calls are executed by doing a
transform on the initializing expression.

Note that lambdas are not considering subexpressions so
we do not need to transform them.

As a result of this patch, unused default member
initializers are not considered odr-used, and
errors about members binding to local variables
in an outer scope only surface at the point
where a constructor is defined.

Reviewed By: aaron.ballman, #clang-language-wg

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

Added: 
clang/test/CodeGenCXX/default-arguments-with-immediate.cpp
clang/test/CodeGenCXX/meminit-initializers-odr.cpp
clang/test/PCH/default-argument-with-immediate-calls.cpp
clang/test/SemaCXX/cxx2a-consteval-default-params.cpp

Modified: 
clang/docs/ReleaseNotes.rst
clang/include/clang/AST/ExprCXX.h
clang/include/clang/AST/Stmt.h
clang/include/clang/Basic/DiagnosticSemaKinds.td
clang/include/clang/Sema/Sema.h
clang/lib/AST/ASTImporter.cpp
clang/lib/AST/Decl.cpp
clang/lib/AST/ExprCXX.cpp
clang/lib/Parse/ParseCXXInlineMethods.cpp
clang/lib/Parse/ParseDeclCXX.cpp
clang/lib/Sema/SemaDeclCXX.cpp
clang/lib/Sema/SemaExpr.cpp
clang/lib/Sema/SemaTemplateInstantiate.cpp
clang/lib/Sema/TreeTransform.h
clang/lib/Sema/UsedDeclVisitor.h
clang/lib/Serialization/ASTReaderStmt.cpp
clang/lib/Serialization/ASTWriterStmt.cpp
clang/test/CXX/class/class.local/p1-0x.cpp
clang/test/CXX/drs/dr26xx.cpp
clang/test/CodeGenCXX/builtin-source-location.cpp
clang/test/SemaCXX/cxx11-default-member-initializers.cpp
clang/test/SemaCXX/source_location.cpp
clang/www/cxx_dr_status.html

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index e3a395481b8c3..99782d74b165b 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -628,6 +628,11 @@ C++ Language Changes in Clang
 - Implemented DR2358 allowing init captures in lambdas in default arguments.
 - implemented `DR2654 `_ which undeprecates
   all compound assignements operations on volatile qualified variables.
+- Implemented DR2631. Invalid ``consteval`` calls in default arguments and 
default
+  member initializers are diagnosed when and if the default is used.
+  This Fixes `Issue 56379 `_
+  and changes the value of ``std::source_location::current()``
+  used in default parameters calls compared to previous versions of Clang.
 
 C++20 Feature Support
 ^

diff  --git a/clang/include/clang/AST/ExprCXX.h 
b/clang/include/clang/AST/ExprCXX.h
index 81267ff568c5b..9d3fd98f65e29 100644
--- a/clang/include/clang/AST/ExprCXX.h
+++ b/clang/include/clang/AST/ExprCXX.h
@@ -1245,8 +1245,12 @@ class CXXThrowExpr : public Expr {
 /// This wraps up a function call argument that was created from the
 /// corresponding parameter's default argument, when the call did not
 /// explicitly supply arguments for all of the parameters.
-class CXXDefaultArgExpr final : public Expr {
+class CXXDefaultArgExpr final
+: public Expr,
+  private llvm::TrailingObjects {
   friend class ASTStmtReader;
+  friend class ASTReader;
+  friend TrailingObjects;
 
   /// The parameter whose default is being used.
   ParmVarDecl *Param;
@@ -1255,7 +1259,7 @@ class CXXDefaultArgExpr final : public Expr {
   DeclContext *UsedContext;
 
   CXXDefaultArgExpr(StmtClass SC, SourceLocation Loc, ParmVarDecl *Param,
-DeclContext *UsedContext)
+Expr *RewrittenExpr, DeclContext *UsedContext)
   : Expr(SC,
  Param->hasUnparsedDefaultArg()
  ? Param->getType().getNonReferenceType()
@@ -1264,28 +1268,58 @@ class CXXDefaultArgExpr final : public Expr {
  Param->getDefaultArg()->getObjectKind()),
 Param(Param), UsedContext(UsedContext) {
 CXXDefaultArgExprBits.Loc = Loc;
+CXXDefaultArgExprBits.HasRewrittenInit = RewrittenExpr != nullptr;
+if (RewrittenExpr)
+  *getTrailingObjects() = RewrittenExpr;
 setDependence(computeDependence(this));
   }
 
+  CXXDefaultArgExpr(EmptyShell Empty, bool HasRewrittenInit)
+  : Expr(CXXDefaultArgExprClass, Empty) {
+CXXDefaultArgExprBits.HasRewrittenInit = HasRewrittenInit;
+  }
+
+  size_t 

[PATCH] D136554: Implement CWG2631

2022-12-08 Thread Corentin Jabot via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGa96a6ed83230: Implement CWG2631 (authored by cor3ntin).

Changed prior to commit:
  https://reviews.llvm.org/D136554?vs=479395=481194#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136554

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/AST/ExprCXX.h
  clang/include/clang/AST/Stmt.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/ASTImporter.cpp
  clang/lib/AST/Decl.cpp
  clang/lib/AST/ExprCXX.cpp
  clang/lib/Parse/ParseCXXInlineMethods.cpp
  clang/lib/Parse/ParseDeclCXX.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaTemplateInstantiate.cpp
  clang/lib/Sema/TreeTransform.h
  clang/lib/Sema/UsedDeclVisitor.h
  clang/lib/Serialization/ASTReaderStmt.cpp
  clang/lib/Serialization/ASTWriterStmt.cpp
  clang/test/CXX/class/class.local/p1-0x.cpp
  clang/test/CXX/drs/dr26xx.cpp
  clang/test/CodeGenCXX/builtin-source-location.cpp
  clang/test/CodeGenCXX/default-arguments-with-immediate.cpp
  clang/test/CodeGenCXX/meminit-initializers-odr.cpp
  clang/test/PCH/default-argument-with-immediate-calls.cpp
  clang/test/SemaCXX/cxx11-default-member-initializers.cpp
  clang/test/SemaCXX/cxx2a-consteval-default-params.cpp
  clang/test/SemaCXX/source_location.cpp
  clang/www/cxx_dr_status.html

Index: clang/www/cxx_dr_status.html
===
--- clang/www/cxx_dr_status.html
+++ clang/www/cxx_dr_status.html
@@ -15593,7 +15593,7 @@
 https://wg21.link/cwg2631;>2631
 DR
 Immediate function evaluations in default arguments
-Unknown
+Clang 16
   
   
 https://wg21.link/cwg2632;>2632
Index: clang/test/SemaCXX/source_location.cpp
===
--- clang/test/SemaCXX/source_location.cpp
+++ clang/test/SemaCXX/source_location.cpp
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 -std=c++1z -fcxx-exceptions -fexceptions -verify %s
+// RUN: %clang_cc1 -std=c++2a -fcxx-exceptions -DUSE_CONSTEVAL -fexceptions -verify %s
 // expected-no-diagnostics
 
 #define assert(...) ((__VA_ARGS__) ? ((void)0) : throw 42)
@@ -8,15 +9,22 @@
 template 
 struct Printer;
 
+#ifdef USE_CONSTEVAL
+#define SOURCE_LOC_EVAL_KIND consteval
+#else
+#define SOURCE_LOC_EVAL_KIND constexpr
+#endif
+
 namespace std {
 class source_location {
   struct __impl;
 
 public:
-  static constexpr source_location current(const __impl *__p = __builtin_source_location()) noexcept {
-source_location __loc;
-__loc.__m_impl = __p;
-return __loc;
+  static SOURCE_LOC_EVAL_KIND source_location
+current(const __impl *__p = __builtin_source_location()) noexcept {
+  source_location __loc;
+  __loc.__m_impl = __p;
+  return __loc;
   }
   constexpr source_location() = default;
   constexpr source_location(source_location const &) = default;
@@ -593,3 +601,51 @@
   }
   static_assert(test());
 }
+
+namespace Lambda {
+#line 8000 "TestLambda.cpp"
+constexpr int nested_lambda(int l = []{
+  return SL::current().line();
+}()) {
+  return l;
+}
+static_assert(nested_lambda() == __LINE__ - 4);
+
+constexpr int lambda_param(int l = [](int l = SL::current().line()) {
+  return l;
+}()) {
+  return l;
+}
+static_assert(lambda_param() == __LINE__);
+
+
+}
+
+constexpr int compound_literal_fun(int a =
+  (int){ SL::current().line() }
+) { return a ;}
+static_assert(compound_literal_fun() == __LINE__);
+
+struct CompoundLiteral {
+  int a = (int){ SL::current().line() };
+};
+static_assert(CompoundLiteral{}.a == __LINE__);
+
+
+// FIXME
+// Init captures are subexpressions of the lambda expression
+// so according to the standard immediate invocations in init captures
+// should be evaluated at the call site.
+// However Clang does not yet implement this as it would introduce
+// a fair bit of complexity.
+// We intend to implement that functionality once we find real world
+// use cases that require it.
+constexpr int test_init_capture(int a =
+[b = SL::current().line()] { return b; }()) {
+  return a;
+}
+#ifdef USE_CONSTEVAL
+static_assert(test_init_capture() == __LINE__ - 4);
+#else
+static_assert(test_init_capture() == __LINE__ );
+#endif
Index: clang/test/SemaCXX/cxx2a-consteval-default-params.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/cxx2a-consteval-default-params.cpp
@@ -0,0 +1,81 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c++20 %s
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c++2b %s
+
+consteval int undefined();  // expected-note 4 {{declared here}}
+
+void check_lambdas_unused(
+int a = []
+{
+// The body of a lambda is not a subexpression of the lambda
+// so this is immediately evaluated even if the parameter
+// is 

[PATCH] D138821: [include-cleaner] Remove filtering from UsingDecl visit.

2022-12-08 Thread Viktoriia Bakalova via Phabricator via cfe-commits
VitaNuo updated this revision to Diff 481213.
VitaNuo marked 4 inline comments as done.
VitaNuo added a comment.

Formatting fixes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D138821

Files:
  clang-tools-extra/include-cleaner/lib/WalkAST.cpp
  clang-tools-extra/include-cleaner/unittests/WalkASTTest.cpp

Index: clang-tools-extra/include-cleaner/unittests/WalkASTTest.cpp
===
--- clang-tools-extra/include-cleaner/unittests/WalkASTTest.cpp
+++ clang-tools-extra/include-cleaner/unittests/WalkASTTest.cpp
@@ -26,7 +26,6 @@
 namespace {
 
 // Specifies a test of which symbols are referenced by a piece of code.
-// If `// c++-header` is present, treats referencing code as a header file.
 // Target should contain points annotated with the reference kind.
 // Example:
 //   Target:  int $explicit^foo();
@@ -41,8 +40,6 @@
   Inputs.ExtraArgs.push_back("-include");
   Inputs.ExtraArgs.push_back("target.h");
   Inputs.ExtraArgs.push_back("-std=c++17");
-  if (Referencing.code().contains("// c++-header\n"))
-Inputs.ExtraArgs.push_back("-xc++-header");
   TestAST AST(Inputs);
   const auto  = AST.sourceManager();
 
@@ -88,12 +85,10 @@
 auto RTStr = llvm::to_string(RT);
 for (auto Expected : Target.points(RTStr))
   if (!llvm::is_contained(ReferencedOffsets[RT], Expected))
-DiagnosePoint("location not marked used with type " + RTStr,
-  Expected);
+DiagnosePoint("location not marked used with type " + RTStr, Expected);
 for (auto Actual : ReferencedOffsets[RT])
   if (!llvm::is_contained(Target.points(RTStr), Actual))
-DiagnosePoint("location unexpectedly used with type " + RTStr,
-  Actual);
+DiagnosePoint("location unexpectedly used with type " + RTStr, Actual);
   }
 
   // If there were any differences, we print the entire referencing code once.
@@ -129,19 +124,32 @@
 }
 
 TEST(WalkAST, Using) {
-  // Make sure we ignore unused overloads.
+  // We should report unused overloads as ambiguous.
   testWalk(R"cpp(
 namespace ns {
-  void $explicit^x(); void x(int); void x(char);
+  void $explicit^x(); void $ambiguous^x(int); void $ambiguous^x(char);
 })cpp",
"using ns::^x; void foo() { x(); }");
-  // We should report unused overloads if main file is a header.
   testWalk(R"cpp(
 namespace ns {
   void $ambiguous^x(); void $ambiguous^x(int); void $ambiguous^x(char);
 })cpp",
-   "// c++-header\n using ns::^x;");
+   "using ns::^x;");
   testWalk("namespace ns { struct S; } using ns::$explicit^S;", "^S *s;");
+
+  testWalk(R"cpp(
+namespace ns {
+  template
+  class $ambiguous^Y {};
+})cpp",
+   "using ns::^Y;");
+  testWalk(R"cpp(
+namespace ns {
+  template
+  class Y {};
+}
+using ns::$explicit^Y;)cpp",
+   "^Y x;");
 }
 
 TEST(WalkAST, Namespaces) {
Index: clang-tools-extra/include-cleaner/lib/WalkAST.cpp
===
--- clang-tools-extra/include-cleaner/lib/WalkAST.cpp
+++ clang-tools-extra/include-cleaner/lib/WalkAST.cpp
@@ -16,7 +16,6 @@
 #include "clang/AST/Type.h"
 #include "clang/AST/TypeLoc.h"
 #include "clang/Basic/SourceLocation.h"
-#include "clang/Basic/SourceManager.h"
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/Support/Casting.h"
 
@@ -27,10 +26,6 @@
 
 class ASTWalker : public RecursiveASTVisitor {
   DeclCallback Callback;
-  // Whether we're traversing declarations coming from a header file.
-  // This helps figure out whether certain symbols can be assumed as unused
-  // (e.g. overloads brought into an implementation file, but not used).
-  bool IsHeader = false;
 
   bool handleTemplateName(SourceLocation Loc, TemplateName TN) {
 // For using-templates, only mark the alias.
@@ -50,8 +45,7 @@
   }
 
 public:
-  ASTWalker(DeclCallback Callback, bool IsHeader)
-  : Callback(Callback), IsHeader(IsHeader) {}
+  ASTWalker(DeclCallback Callback) : Callback(Callback) {}
 
   bool VisitDeclRefExpr(DeclRefExpr *DRE) {
 report(DRE->getLocation(), DRE->getFoundDecl());
@@ -82,10 +76,6 @@
 for (const auto *Shadow : UD->shadows()) {
   auto *TD = Shadow->getTargetDecl();
   auto IsUsed = TD->isUsed() || TD->isReferenced();
-  // We ignore unused overloads inside implementation files, as the ones in
-  // headers might still be used by the dependents of the header.
-  if (!IsUsed && !IsHeader)
-continue;
   report(UD->getLocation(), TD,
  IsUsed ? RefType::Explicit : RefType::Ambiguous);
 }
@@ -151,14 +141,7 @@
 } // namespace
 
 void walkAST(Decl , DeclCallback Callback) {
-  auto  = Root.getASTContext();
-  auto  = AST.getSourceManager();
-  // If decl isn't written in main file, assume it's coming from an include,
-  // hence written 

[PATCH] D138821: [include-cleaner] Remove filtering from UsingDecl visit.

2022-12-08 Thread Viktoriia Bakalova 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 rG45659b3bd98e: [include-cleaner] Remove filtering from 
UsingDecl visit. (authored by VitaNuo).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D138821

Files:
  clang-tools-extra/include-cleaner/lib/WalkAST.cpp
  clang-tools-extra/include-cleaner/unittests/WalkASTTest.cpp

Index: clang-tools-extra/include-cleaner/unittests/WalkASTTest.cpp
===
--- clang-tools-extra/include-cleaner/unittests/WalkASTTest.cpp
+++ clang-tools-extra/include-cleaner/unittests/WalkASTTest.cpp
@@ -26,7 +26,6 @@
 namespace {
 
 // Specifies a test of which symbols are referenced by a piece of code.
-// If `// c++-header` is present, treats referencing code as a header file.
 // Target should contain points annotated with the reference kind.
 // Example:
 //   Target:  int $explicit^foo();
@@ -41,8 +40,6 @@
   Inputs.ExtraArgs.push_back("-include");
   Inputs.ExtraArgs.push_back("target.h");
   Inputs.ExtraArgs.push_back("-std=c++17");
-  if (Referencing.code().contains("// c++-header\n"))
-Inputs.ExtraArgs.push_back("-xc++-header");
   TestAST AST(Inputs);
   const auto  = AST.sourceManager();
 
@@ -88,12 +85,10 @@
 auto RTStr = llvm::to_string(RT);
 for (auto Expected : Target.points(RTStr))
   if (!llvm::is_contained(ReferencedOffsets[RT], Expected))
-DiagnosePoint("location not marked used with type " + RTStr,
-  Expected);
+DiagnosePoint("location not marked used with type " + RTStr, Expected);
 for (auto Actual : ReferencedOffsets[RT])
   if (!llvm::is_contained(Target.points(RTStr), Actual))
-DiagnosePoint("location unexpectedly used with type " + RTStr,
-  Actual);
+DiagnosePoint("location unexpectedly used with type " + RTStr, Actual);
   }
 
   // If there were any differences, we print the entire referencing code once.
@@ -129,19 +124,32 @@
 }
 
 TEST(WalkAST, Using) {
-  // Make sure we ignore unused overloads.
+  // We should report unused overloads as ambiguous.
   testWalk(R"cpp(
 namespace ns {
-  void $explicit^x(); void x(int); void x(char);
+  void $explicit^x(); void $ambiguous^x(int); void $ambiguous^x(char);
 })cpp",
"using ns::^x; void foo() { x(); }");
-  // We should report unused overloads if main file is a header.
   testWalk(R"cpp(
 namespace ns {
   void $ambiguous^x(); void $ambiguous^x(int); void $ambiguous^x(char);
 })cpp",
-   "// c++-header\n using ns::^x;");
+   "using ns::^x;");
   testWalk("namespace ns { struct S; } using ns::$explicit^S;", "^S *s;");
+
+  testWalk(R"cpp(
+namespace ns {
+  template
+  class $ambiguous^Y {};
+})cpp",
+   "using ns::^Y;");
+  testWalk(R"cpp(
+namespace ns {
+  template
+  class Y {};
+}
+using ns::$explicit^Y;)cpp",
+   "^Y x;");
 }
 
 TEST(WalkAST, Namespaces) {
Index: clang-tools-extra/include-cleaner/lib/WalkAST.cpp
===
--- clang-tools-extra/include-cleaner/lib/WalkAST.cpp
+++ clang-tools-extra/include-cleaner/lib/WalkAST.cpp
@@ -16,7 +16,6 @@
 #include "clang/AST/Type.h"
 #include "clang/AST/TypeLoc.h"
 #include "clang/Basic/SourceLocation.h"
-#include "clang/Basic/SourceManager.h"
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/Support/Casting.h"
 
@@ -27,10 +26,6 @@
 
 class ASTWalker : public RecursiveASTVisitor {
   DeclCallback Callback;
-  // Whether we're traversing declarations coming from a header file.
-  // This helps figure out whether certain symbols can be assumed as unused
-  // (e.g. overloads brought into an implementation file, but not used).
-  bool IsHeader = false;
 
   bool handleTemplateName(SourceLocation Loc, TemplateName TN) {
 // For using-templates, only mark the alias.
@@ -50,8 +45,7 @@
   }
 
 public:
-  ASTWalker(DeclCallback Callback, bool IsHeader)
-  : Callback(Callback), IsHeader(IsHeader) {}
+  ASTWalker(DeclCallback Callback) : Callback(Callback) {}
 
   bool VisitDeclRefExpr(DeclRefExpr *DRE) {
 report(DRE->getLocation(), DRE->getFoundDecl());
@@ -82,10 +76,6 @@
 for (const auto *Shadow : UD->shadows()) {
   auto *TD = Shadow->getTargetDecl();
   auto IsUsed = TD->isUsed() || TD->isReferenced();
-  // We ignore unused overloads inside implementation files, as the ones in
-  // headers might still be used by the dependents of the header.
-  if (!IsUsed && !IsHeader)
-continue;
   report(UD->getLocation(), TD,
  IsUsed ? RefType::Explicit : RefType::Ambiguous);
 }
@@ -151,14 +141,7 @@
 } // namespace
 
 void walkAST(Decl , DeclCallback Callback) {
-  auto  = Root.getASTContext();
-  auto  = 

[clang-tools-extra] 7fd8387 - [clang-tidy] Do not warn about redundant static in misc-use-anonymous-namespace

2022-12-08 Thread Carlos Galvez via cfe-commits

Author: Carlos Galvez
Date: 2022-12-08T11:40:50Z
New Revision: 7fd8387917167d9cb4bab14a8548f0f78b0eaa79

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

LOG: [clang-tidy] Do not warn about redundant static in 
misc-use-anonymous-namespace

The same functionality is already implemented in the
readability-static-definition-in-anonymous-namespace
check, including automatic fixes.

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

Added: 


Modified: 
clang-tools-extra/clang-tidy/misc/UseAnonymousNamespaceCheck.cpp
clang-tools-extra/clang-tidy/misc/UseAnonymousNamespaceCheck.h
clang-tools-extra/docs/clang-tidy/checks/misc/use-anonymous-namespace.rst
clang-tools-extra/test/clang-tidy/checkers/misc/use-anonymous-namespace.cpp

Removed: 




diff  --git a/clang-tools-extra/clang-tidy/misc/UseAnonymousNamespaceCheck.cpp 
b/clang-tools-extra/clang-tidy/misc/UseAnonymousNamespaceCheck.cpp
index 5632347f99948..878cba31eb2ab 100644
--- a/clang-tools-extra/clang-tidy/misc/UseAnonymousNamespaceCheck.cpp
+++ b/clang-tools-extra/clang-tidy/misc/UseAnonymousNamespaceCheck.cpp
@@ -25,36 +25,29 @@ AST_MATCHER(FunctionDecl, isMemberFunction) {
   return llvm::isa();
 }
 AST_MATCHER(VarDecl, isStaticDataMember) { return Node.isStaticDataMember(); }
-} // namespace
 
-static bool isInAnonymousNamespace(const Decl *Decl) {
-  const DeclContext *DC = Decl->getDeclContext();
-  if (DC && DC->isNamespace()) {
-const auto *ND = llvm::cast(DC);
-if (ND && ND->isAnonymousNamespace())
-  return true;
-  }
-  return false;
+AST_MATCHER(Decl, isInAnonymousNamespace) {
+  return Node.isInAnonymousNamespace();
 }
+} // namespace
 
 template 
 void UseAnonymousNamespaceCheck::processMatch(const T *MatchedDecl) {
   StringRef Type = llvm::isa(MatchedDecl) ? "variable" : "function";
-  if (isInAnonymousNamespace(MatchedDecl))
-diag(MatchedDecl->getLocation(), "%0 %1 declared 'static' in "
- "anonymous namespace, remove 'static'")
-<< Type << MatchedDecl;
-  else
-diag(MatchedDecl->getLocation(),
- "%0 %1 declared 'static', move to anonymous namespace instead")
-<< Type << MatchedDecl;
+  diag(MatchedDecl->getLocation(),
+   "%0 %1 declared 'static', move to anonymous namespace instead")
+  << Type << MatchedDecl;
 }
 
 void UseAnonymousNamespaceCheck::registerMatchers(MatchFinder *Finder) {
   Finder->addMatcher(
-  functionDecl(isStatic(), unless(isMemberFunction())).bind("func"), this);
+  functionDecl(isStatic(),
+   unless(anyOf(isInAnonymousNamespace(), isMemberFunction(
+  .bind("func"),
+  this);
   Finder->addMatcher(
-  varDecl(isStatic(), unless(anyOf(isStaticLocal(), isStaticDataMember(
+  varDecl(isStatic(), unless(anyOf(isInAnonymousNamespace(),
+   isStaticLocal(), isStaticDataMember(
   .bind("var"),
   this);
 }

diff  --git a/clang-tools-extra/clang-tidy/misc/UseAnonymousNamespaceCheck.h 
b/clang-tools-extra/clang-tidy/misc/UseAnonymousNamespaceCheck.h
index 8e934080592e0..59c48029711e0 100644
--- a/clang-tools-extra/clang-tidy/misc/UseAnonymousNamespaceCheck.h
+++ b/clang-tools-extra/clang-tidy/misc/UseAnonymousNamespaceCheck.h
@@ -16,8 +16,7 @@ namespace tidy {
 namespace misc {
 
 /// Warns when using 'static' functions or variables at global scope, and
-/// suggests moving them to an anonymous namespace. It also suggests removing
-/// 'static' if they are already inside an anonymous namespace.
+/// suggests moving them to an anonymous namespace.
 ///
 /// For the user-facing documentation see:
 /// 
http://clang.llvm.org/extra/clang-tidy/checks/modernize/use-anonymous-namespace.html

diff  --git 
a/clang-tools-extra/docs/clang-tidy/checks/misc/use-anonymous-namespace.rst 
b/clang-tools-extra/docs/clang-tidy/checks/misc/use-anonymous-namespace.rst
index 5b6790b1e1b81..c116bfbdd3325 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/misc/use-anonymous-namespace.rst
+++ b/clang-tools-extra/docs/clang-tidy/checks/misc/use-anonymous-namespace.rst
@@ -4,9 +4,7 @@ misc-use-anonymous-namespace
 
 
 Finds instances of ``static`` functions or variables declared at global scope
-that could instead be moved into an anonymous namespace. It also detects
-instances moved to an anonymous namespace that still keep the redundant
-``static``.
+that could instead be moved into an anonymous namespace.
 
 Anonymous namespaces are the "superior alternative" according to the C++
 Standard. ``static`` was proposed for deprecation, but later un-deprecated to
@@ -27,18 +25,4 @@ Examples:
 int x;
   } // namespace
 
-.. code-block:: c++
-
-  // Bad
-  namespace {
-static 

[PATCH] D139197: [clang-tidy] Do not warn about redundant static in misc-use-anonymous-namespace

2022-12-08 Thread Carlos Galvez via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG7fd838791716: [clang-tidy] Do not warn about redundant 
static in misc-use-anonymous-namespace (authored by carlosgalvezp).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139197

Files:
  clang-tools-extra/clang-tidy/misc/UseAnonymousNamespaceCheck.cpp
  clang-tools-extra/clang-tidy/misc/UseAnonymousNamespaceCheck.h
  clang-tools-extra/docs/clang-tidy/checks/misc/use-anonymous-namespace.rst
  clang-tools-extra/test/clang-tidy/checkers/misc/use-anonymous-namespace.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/misc/use-anonymous-namespace.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/misc/use-anonymous-namespace.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/misc/use-anonymous-namespace.cpp
@@ -5,13 +5,6 @@
 static int v1;
 // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: variable 'v1' declared 'static', move to anonymous namespace instead
 
-namespace {
-  static void f2();
-  // CHECK-MESSAGES: :[[@LINE-1]]:15: warning: function 'f2' declared 'static' in anonymous namespace, remove 'static'
-  static int v2;
-  // CHECK-MESSAGES: :[[@LINE-1]]:14: warning: variable 'v2' declared 'static' in anonymous namespace, remove 'static'
-}
-
 namespace a {
   static void f3();
   // CHECK-MESSAGES: :[[@LINE-1]]:15: warning: function 'f3' declared 'static', move to anonymous namespace instead
@@ -19,15 +12,6 @@
   // CHECK-MESSAGES: :[[@LINE-1]]:14: warning: variable 'v3' declared 'static', move to anonymous namespace instead
 }
 
-namespace a {
-namespace {
-  static void f4();
-  // CHECK-MESSAGES: :[[@LINE-1]]:15: warning: function 'f4' declared 'static' in anonymous namespace, remove 'static'
-  static int v4;
-  // CHECK-MESSAGES: :[[@LINE-1]]:14: warning: variable 'v4' declared 'static' in anonymous namespace, remove 'static'
-}
-}
-
 // OK
 void f5();
 int v5;
Index: clang-tools-extra/docs/clang-tidy/checks/misc/use-anonymous-namespace.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/misc/use-anonymous-namespace.rst
+++ clang-tools-extra/docs/clang-tidy/checks/misc/use-anonymous-namespace.rst
@@ -4,9 +4,7 @@
 
 
 Finds instances of ``static`` functions or variables declared at global scope
-that could instead be moved into an anonymous namespace. It also detects
-instances moved to an anonymous namespace that still keep the redundant
-``static``.
+that could instead be moved into an anonymous namespace.
 
 Anonymous namespaces are the "superior alternative" according to the C++
 Standard. ``static`` was proposed for deprecation, but later un-deprecated to
@@ -27,18 +25,4 @@
 int x;
   } // namespace
 
-.. code-block:: c++
-
-  // Bad
-  namespace {
-static void foo();
-static int x;
-  }
-
-  // Good
-  namespace {
-void foo();
-int x;
-  }  // namespace
-
 [1] `Undeprecating static `_
Index: clang-tools-extra/clang-tidy/misc/UseAnonymousNamespaceCheck.h
===
--- clang-tools-extra/clang-tidy/misc/UseAnonymousNamespaceCheck.h
+++ clang-tools-extra/clang-tidy/misc/UseAnonymousNamespaceCheck.h
@@ -16,8 +16,7 @@
 namespace misc {
 
 /// Warns when using 'static' functions or variables at global scope, and
-/// suggests moving them to an anonymous namespace. It also suggests removing
-/// 'static' if they are already inside an anonymous namespace.
+/// suggests moving them to an anonymous namespace.
 ///
 /// For the user-facing documentation see:
 /// http://clang.llvm.org/extra/clang-tidy/checks/modernize/use-anonymous-namespace.html
Index: clang-tools-extra/clang-tidy/misc/UseAnonymousNamespaceCheck.cpp
===
--- clang-tools-extra/clang-tidy/misc/UseAnonymousNamespaceCheck.cpp
+++ clang-tools-extra/clang-tidy/misc/UseAnonymousNamespaceCheck.cpp
@@ -25,36 +25,29 @@
   return llvm::isa();
 }
 AST_MATCHER(VarDecl, isStaticDataMember) { return Node.isStaticDataMember(); }
-} // namespace
 
-static bool isInAnonymousNamespace(const Decl *Decl) {
-  const DeclContext *DC = Decl->getDeclContext();
-  if (DC && DC->isNamespace()) {
-const auto *ND = llvm::cast(DC);
-if (ND && ND->isAnonymousNamespace())
-  return true;
-  }
-  return false;
+AST_MATCHER(Decl, isInAnonymousNamespace) {
+  return Node.isInAnonymousNamespace();
 }
+} // namespace
 
 template 
 void UseAnonymousNamespaceCheck::processMatch(const T *MatchedDecl) {
   StringRef Type = llvm::isa(MatchedDecl) ? "variable" : "function";
-  if (isInAnonymousNamespace(MatchedDecl))
-diag(MatchedDecl->getLocation(), "%0 %1 declared 'static' in "
- 

[clang] e321c53 - [C2x] Relaxing requirements for va_start

2022-12-08 Thread Aaron Ballman via cfe-commits

Author: Aaron Ballman
Date: 2022-12-08T07:36:07-05:00
New Revision: e321c53f7bb8d61f64b33e8b1f6a97eb32eaaa69

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

LOG: [C2x] Relaxing requirements for va_start

This implements WG14 N2975 relaxing requirements for va_start
(https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2975.pdf), which
does two things:

1) Allows the declaration of a variadic function without any named
arguments. e.g., void f(...) is now valid, as in C++.
2) Modified the signature of the va_start macro to be a variadic macro
that accepts one or more arguments; the second (and later) arguments
are not expanded or evaluated.

I followed the GCC implementation in terms of not modifying the
behavior of `__builtin_va_start` (it still requires exactly two
arguments), but this approach has led to several QoI issues that I've
documented with FIXME comments in the test. Specifically, the
requirement that we do not evaluate *or expand* the second and later
arguments means it's no longer possible to issue diagnostics for
compatibility with older C versions and C++. I am reaching out to
folks in WG14 to see if we can get an NB comment to address these
concerns (the US comment period has already closed, so I cannot file
the comment myself), so the diagnostic behavior may change in the
future.

I took this opportunity to add some documentation for all the related
builtins in this area, since there was no documentation for them yet.

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

Added: 
clang/test/C/C2x/n2975.c

Modified: 
clang/docs/LanguageExtensions.rst
clang/docs/ReleaseNotes.rst
clang/include/clang/Basic/DiagnosticSemaKinds.td
clang/lib/Headers/stdarg.h
clang/lib/Sema/SemaChecking.cpp
clang/lib/Sema/SemaType.cpp
clang/www/c_status.html

Removed: 




diff  --git a/clang/docs/LanguageExtensions.rst 
b/clang/docs/LanguageExtensions.rst
index 2adf7ee421f4d..ad6e10cf9c6c2 100644
--- a/clang/docs/LanguageExtensions.rst
+++ b/clang/docs/LanguageExtensions.rst
@@ -3229,6 +3229,52 @@ despite these functions accepting an argument of type 
``const void*``.
 Support for constant expression evaluation for the above builtins can be 
detected
 with ``__has_feature(cxx_constexpr_string_builtins)``.
 
+Variadic function builtins
+--
+
+Clang provides several builtins for working with variadic functions from the C
+standard library  header:
+
+* ``__builtin_va_list``
+
+A predefined typedef for the target-specific ``va_list`` type.
+
+* ``void __builtin_va_start(__builtin_va_list list, )``
+
+A builtin function for the target-specific ``va_start`` function-like macro.
+The ``parameter-name`` argument is the name of the parameter preceding the
+ellipsis (``...``) in the function signature. Alternatively, in C2x mode or
+later, it may be the integer literal ``0`` if there is no parameter preceding
+the ellipsis. This function initializes the given ``__builtin_va_list`` object.
+It is undefined behavior to call this function on an already initialized
+``__builin_va_list`` object.
+
+* ``void __builtin_va_end(__builtin_va_list list)``
+
+A builtin function for the target-specific ``va_end`` function-like macro. This
+function finalizes the given ``__builtin_va_list`` object such that it is no
+longer usable unless re-initialized with a call to ``__builtin_va_start`` or
+``__builtin_va_copy``. It is undefined behavior to call this function with a
+``list`` that has not been initialized by either ``__builtin_va_start`` or
+``__builtin_va_copy``.
+
+* `` __builtin_va_arg(__builtin_va_list list, )``
+
+A builtin function for the target-specific ``va_arg`` function-like macro. This
+function returns the value of the next variadic argument to the call. It is
+undefined behavior to call this builtin when there is no next varadic argument
+to retrieve or if the next variadic argument does not have a type compatible
+with the given ``type-name``. The return type of the function is the
+``type-name`` given as the second argument. It is undefined behavior to call
+this function with a ``list`` that has not been initialized by either
+``__builtin_va_start`` or ``__builtin_va_copy``.
+
+* ``void __builtin_va_copy(__builtin_va_list dest, __builtin_va_list src)``
+
+A builtin function for the target-specific ``va_copy`` function-like macro.
+This function initializes ``dest`` as a copy of ``src``. It is undefined
+behavior to call this function with an already initialized ``dest`` argument.
+
 Memory builtins
 ---
 

diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 99782d74b165b..6bd038fbdc16f 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -614,6 +614,20 @@ C2x Feature 

[PATCH] D139436: [C2x] Relaxing requirements for va_start

2022-12-08 Thread Aaron Ballman via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGe321c53f7bb8: [C2x] Relaxing requirements for va_start 
(authored by aaron.ballman).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139436

Files:
  clang/docs/LanguageExtensions.rst
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Headers/stdarg.h
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/C/C2x/n2975.c
  clang/www/c_status.html

Index: clang/www/c_status.html
===
--- clang/www/c_status.html
+++ clang/www/c_status.html
@@ -1162,7 +1162,7 @@
 
   Relax requirements for va_start
   https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2975.pdf;>N2975
-  No
+  Clang 16
 
 
   Enhanced enumerations
Index: clang/test/C/C2x/n2975.c
===
--- /dev/null
+++ clang/test/C/C2x/n2975.c
@@ -0,0 +1,66 @@
+// RUN: %clang_cc1 -verify -ffreestanding -Wpre-c2x-compat -std=c2x %s
+
+/* WG14 N2975: partial
+ * Relax requirements for va_start
+ */
+
+#include 
+
+#define DERP this is an error
+
+void func(...) { // expected-warning {{'...' as the only parameter of a function is incompatible with C standards before C2x}}
+  // Show that va_start doesn't require the second argument in C2x mode.
+  va_list list;
+  va_start(list); // FIXME: it would be nice to issue a portability warning to C17 and earlier here.
+  va_end(list);
+
+  // Show that va_start doesn't expand or evaluate the second argument.
+  va_start(list, DERP);
+  va_end(list);
+
+  // FIXME: it would be kinder to diagnose this instead of silently accepting it.
+  va_start(list, 1, 2);
+  va_end(list);
+
+  // We didn't change the behavior of __builtin_va_start (and neither did GCC).
+  __builtin_va_start(list); // expected-error {{too few arguments to function call, expected 2, have 1}}
+
+  // Verify that the return type of a call to va_start is 'void'.
+  _Static_assert(__builtin_types_compatible_p(__typeof__(va_start(list)), void), "");
+  _Static_assert(__builtin_types_compatible_p(__typeof__(__builtin_va_start(list, 0)), void), "");
+}
+
+// Show that function pointer types also don't need an argument before the
+// ellipsis.
+typedef void (*fp)(...); // expected-warning {{'...' as the only parameter of a function is incompatible with C standards before C2x}}
+
+// Passing something other than the argument before the ... is still not valid.
+void diag(int a, int b, ...) {
+  va_list list;
+  // FIXME: the call to va_start should also diagnose the same way as the call
+  // to __builtin_va_start. However, because va_start is not allowed to expand
+  // or evaluate the second argument, we can't pass it along to
+  // __builtin_va_start to get that diagnostic. So in C17 and earlier, we will
+  // diagnose this use through the macro, but in C2x and later we've lost the
+  // diagnostic entirely. GCC has the same issue currently.
+  va_start(list, a);
+  // However, the builtin itself is under no such constraints regarding
+  // expanding or evaluating the second argument, so it can still diagnose.
+  __builtin_va_start(list, a); // expected-warning {{second argument to 'va_start' is not the last named parameter}}
+  va_end(list);
+}
+
+void foo(int a...); // expected-error {{C requires a comma prior to the ellipsis in a variadic function type}}
+
+void use(void) {
+  // Demonstrate that we can actually call the variadic function when it has no
+  // formal parameters.
+  func(1, '2', 3.0, "4");
+  func();
+
+  // And that assignment still works as expected.
+  fp local = func;
+
+  // ...including conversion errors.
+  fp other_local = diag; // expected-error {{incompatible function pointer types initializing 'fp' (aka 'void (*)(...)') with an expression of type 'void (int, int, ...)'}}
+}
Index: clang/lib/Sema/SemaType.cpp
===
--- clang/lib/Sema/SemaType.cpp
+++ clang/lib/Sema/SemaType.cpp
@@ -5371,14 +5371,19 @@
   } else {
 // We allow a zero-parameter variadic function in C if the
 // function is marked with the "overloadable" attribute. Scan
-// for this attribute now.
-if (!FTI.NumParams && FTI.isVariadic && !LangOpts.CPlusPlus)
-  if (!D.getDeclarationAttributes().hasAttribute(
-  ParsedAttr::AT_Overloadable) &&
-  !D.getAttributes().hasAttribute(ParsedAttr::AT_Overloadable) &&
-  !D.getDeclSpec().getAttributes().hasAttribute(
-  ParsedAttr::AT_Overloadable))
+// for this attribute now. We also allow it in C2x per WG14 N2975.
+if (!FTI.NumParams && FTI.isVariadic && !LangOpts.CPlusPlus) {
+  if (LangOpts.C2x)
+S.Diag(FTI.getEllipsisLoc(),
+   

[PATCH] D137051: [Clang] Allow additional mathematical symbols in identifiers.

2022-12-08 Thread Corentin Jabot via Phabricator via cfe-commits
cor3ntin added a comment.

@tahonermann Gentle ping :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137051

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


[PATCH] D138861: [Clang] Implement CWG2640 Allow more characters in an n-char sequence

2022-12-08 Thread Corentin Jabot via Phabricator via cfe-commits
cor3ntin added a comment.

@tahonermann Do you want to take a look at this?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D138861

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


[PATCH] D139087: [include-cleaner] Handle base class member access from derived class.

2022-12-08 Thread Viktoriia Bakalova via Phabricator via cfe-commits
VitaNuo added inline comments.



Comment at: clang-tools-extra/include-cleaner/lib/WalkAST.cpp:67
 
   bool VisitMemberExpr(MemberExpr *E) {
+// A member expr implies a usage of the class type

hokein wrote:
> while reading it again, I realize that there is another case (operator 
> overloading) we probably want to handle it as well. It is a more tricky case, 
> no need to worry about it in this patch. 
> 
Thank you. If you'd like me to take care of it, please file an issue with an 
example that needs to be taken care of :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139087

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


[clang] 67b72a2 - [tooling] use std::optional in tooling StandardLibrary.h/.cpp, NFC

2022-12-08 Thread Haojian Wu via cfe-commits

Author: Haojian Wu
Date: 2022-12-08T13:49:09+01:00
New Revision: 67b72a28903734372972740adb4a9ccc7626cb35

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

LOG: [tooling] use std::optional in tooling StandardLibrary.h/.cpp, NFC

Added: 


Modified: 
clang/include/clang/Tooling/Inclusions/StandardLibrary.h
clang/lib/Tooling/Inclusions/Stdlib/StandardLibrary.cpp

Removed: 




diff  --git a/clang/include/clang/Tooling/Inclusions/StandardLibrary.h 
b/clang/include/clang/Tooling/Inclusions/StandardLibrary.h
index 4b5ddbb704e37..5c657b40f10d9 100644
--- a/clang/include/clang/Tooling/Inclusions/StandardLibrary.h
+++ b/clang/include/clang/Tooling/Inclusions/StandardLibrary.h
@@ -16,9 +16,9 @@
 #define LLVM_CLANG_TOOLING_INCLUSIONS_STANDARDLIBRARY_H
 
 #include "llvm/ADT/DenseMap.h"
-#include "llvm/ADT/Optional.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/Support/raw_ostream.h"
+#include 
 #include 
 
 namespace clang {
@@ -37,7 +37,7 @@ class Symbol;
 class Header {
 public:
   // Name should contain the angle brackets, e.g. "".
-  static llvm::Optional named(llvm::StringRef Name);
+  static std::optional named(llvm::StringRef Name);
 
   friend llvm::raw_ostream <<(llvm::raw_ostream , const Header ) 
{
 return OS << H.name();
@@ -64,7 +64,7 @@ class Symbol {
 public:
   /// \p Scope should have the trailing "::", for example:
   /// named("std::chrono::", "system_clock")
-  static llvm::Optional named(llvm::StringRef Scope,
+  static std::optional named(llvm::StringRef Scope,
   llvm::StringRef Name);
 
   friend llvm::raw_ostream <<(llvm::raw_ostream , const Symbol ) 
{
@@ -94,7 +94,7 @@ class Symbol {
 class Recognizer {
 public:
   Recognizer();
-  llvm::Optional operator()(const Decl *D);
+  std::optional operator()(const Decl *D);
 
 private:
   using NSSymbolMap = llvm::DenseMap;

diff  --git a/clang/lib/Tooling/Inclusions/Stdlib/StandardLibrary.cpp 
b/clang/lib/Tooling/Inclusions/Stdlib/StandardLibrary.cpp
index 87276f531ce8d..9e5e421fdebcd 100644
--- a/clang/lib/Tooling/Inclusions/Stdlib/StandardLibrary.cpp
+++ b/clang/lib/Tooling/Inclusions/Stdlib/StandardLibrary.cpp
@@ -8,7 +8,6 @@
 
 #include "clang/Tooling/Inclusions/StandardLibrary.h"
 #include "clang/AST/Decl.h"
-#include "llvm/ADT/Optional.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/Support/Casting.h"
 
@@ -77,7 +76,7 @@ static void ensureInitialized() {
   (void)Dummy;
 }
 
-llvm::Optional Header::named(llvm::StringRef Name) {
+std::optional Header::named(llvm::StringRef Name) {
   ensureInitialized();
   auto It = HeaderIDs->find(Name);
   if (It == HeaderIDs->end())
@@ -87,7 +86,7 @@ llvm::Optional Header::named(llvm::StringRef Name) {
 llvm::StringRef Header::name() const { return HeaderNames[ID]; }
 llvm::StringRef Symbol::scope() const { return SymbolNames[ID].first; }
 llvm::StringRef Symbol::name() const { return SymbolNames[ID].second; }
-llvm::Optional Symbol::named(llvm::StringRef Scope,
+std::optional Symbol::named(llvm::StringRef Scope,
  llvm::StringRef Name) {
   ensureInitialized();
   if (NSSymbolMap *NSSymbols = NamespaceSymbols->lookup(Scope)) {
@@ -124,7 +123,7 @@ NSSymbolMap *Recognizer::namespaceSymbols(const 
NamespaceDecl *D) {
   return Result;
 }
 
-llvm::Optional Recognizer::operator()(const Decl *D) {
+std::optional Recognizer::operator()(const Decl *D) {
   // If D is std::vector::iterator, `vector` is the outer symbol to look up.
   // We keep all the candidate DCs as some may turn out to be anon enums.
   // Do this resolution lazily as we may turn out not to have a std namespace.



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


[PATCH] D139113: [clang-tidy] Fix a couple additional cases in misc-use-anonymous-namespace

2022-12-08 Thread Carlos Galvez via Phabricator via cfe-commits
carlosgalvezp updated this revision to Diff 481257.
carlosgalvezp added a comment.

Rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139113

Files:
  clang-tools-extra/clang-tidy/misc/UseAnonymousNamespaceCheck.cpp
  clang-tools-extra/clang-tidy/misc/UseAnonymousNamespaceCheck.h
  clang-tools-extra/docs/clang-tidy/checks/misc/use-anonymous-namespace.rst
  
clang-tools-extra/test/clang-tidy/checkers/misc/Inputs/use-anonymous-namespace.h
  clang-tools-extra/test/clang-tidy/checkers/misc/use-anonymous-namespace.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/misc/use-anonymous-namespace.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/misc/use-anonymous-namespace.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/misc/use-anonymous-namespace.cpp
@@ -1,4 +1,5 @@
-// RUN: %check_clang_tidy %s misc-use-anonymous-namespace %t
+// RUN: %check_clang_tidy %s misc-use-anonymous-namespace %t -- -header-filter=.* -- -I%S/Inputs
+#include "use-anonymous-namespace.h"
 
 static void f1();
 // CHECK-MESSAGES: :[[@LINE-1]]:13: warning: function 'f1' declared 'static', move to anonymous namespace instead [misc-use-anonymous-namespace]
@@ -41,3 +42,7 @@
 {
   static int x;
 }
+
+// OK
+static const int v8{123};
+static constexpr int v9{123};
Index: clang-tools-extra/test/clang-tidy/checkers/misc/Inputs/use-anonymous-namespace.h
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/misc/Inputs/use-anonymous-namespace.h
@@ -0,0 +1,3 @@
+// Should not warn here, do not require anonymous namespaces in headers
+static int gv{123};
+static void gf(){}
Index: clang-tools-extra/docs/clang-tidy/checks/misc/use-anonymous-namespace.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/misc/use-anonymous-namespace.rst
+++ clang-tools-extra/docs/clang-tidy/checks/misc/use-anonymous-namespace.rst
@@ -11,6 +11,14 @@
 keep C compatibility [1]. ``static`` is an overloaded term with different meanings in
 different contexts, so it can create confusion.
 
+The following uses of ``static`` will *not* be diagnosed:
+
+* Functions or variables in header files, since anonymous namespaces in headers
+  is considered an antipattern. Allowed header file extensions can be configured
+  via the `HeaderFileExtensions` option (see below).
+* ``const`` or ``constexpr`` variables, since they already have implicit internal
+  linkage in C++.
+
 Examples:
 
 .. code-block:: c++
@@ -25,4 +33,14 @@
 int x;
   } // namespace
 
+Options
+---
+
+.. option:: HeaderFileExtensions
+
+   A semicolon-separated list of filename extensions of header files (the filename
+   extensions should not include "." prefix). Default is ";h;hh;hpp;hxx".
+   For extension-less header files, using an empty string or leaving an
+   empty string between ";" if there are other filename extensions.
+
 [1] `Undeprecating static `_
Index: clang-tools-extra/clang-tidy/misc/UseAnonymousNamespaceCheck.h
===
--- clang-tools-extra/clang-tidy/misc/UseAnonymousNamespaceCheck.h
+++ clang-tools-extra/clang-tidy/misc/UseAnonymousNamespaceCheck.h
@@ -10,6 +10,7 @@
 #define LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_MISC_USEANONYMOUSNAMESPACECHECK_H
 
 #include "../ClangTidyCheck.h"
+#include "../utils/FileExtensionsUtils.h"
 
 namespace clang {
 namespace tidy {
@@ -18,19 +19,29 @@
 /// Warns when using 'static' functions or variables at global scope, and
 /// suggests moving them to an anonymous namespace.
 ///
+/// The check supports these options:
+///   - `HeaderFileExtensions`: a semicolon-separated list of filename
+/// extensions of header files (The filename extension should not contain
+/// "." prefix). ";h;hh;hpp;hxx" by default.
+///
+/// For extension-less header files, using an empty string or leaving an
+/// empty string between ";" if there are other filename extensions.
+///
 /// For the user-facing documentation see:
 /// http://clang.llvm.org/extra/clang-tidy/checks/modernize/use-anonymous-namespace.html
 class UseAnonymousNamespaceCheck : public ClangTidyCheck {
 public:
-  UseAnonymousNamespaceCheck(StringRef Name, ClangTidyContext *Context)
-  : ClangTidyCheck(Name, Context) {}
+  UseAnonymousNamespaceCheck(StringRef Name, ClangTidyContext *Context);
   bool isLanguageVersionSupported(const LangOptions ) const override {
 return LangOpts.CPlusPlus;
   }
+  void storeOptions(ClangTidyOptions::OptionMap ) override;
   void registerMatchers(ast_matchers::MatchFinder *Finder) override;
   void check(const ast_matchers::MatchFinder::MatchResult ) override;
 
 private:
+  const StringRef RawStringHeaderFileExtensions;
+  

[clang] cebc348 - Fix MSVC "not all control paths return a value" warning. NFC.

2022-12-08 Thread Simon Pilgrim via cfe-commits

Author: Simon Pilgrim
Date: 2022-12-08T11:44:18Z
New Revision: cebc348f6735b1fb5607e408dfe2e4d34abe0002

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

LOG: Fix MSVC "not all control paths return a value" warning. NFC.

Added: 


Modified: 
clang/include/clang/Basic/HeaderInclude.h

Removed: 




diff  --git a/clang/include/clang/Basic/HeaderInclude.h 
b/clang/include/clang/Basic/HeaderInclude.h
index 7a1a08ba617af..83c26543bbd3b 100644
--- a/clang/include/clang/Basic/HeaderInclude.h
+++ b/clang/include/clang/Basic/HeaderInclude.h
@@ -54,6 +54,7 @@ inline const char 
*headerIncludeFormatKindToString(HeaderIncludeFormatKind K) {
   case HIFMT_JSON:
 return "json";
   }
+  llvm_unreachable("Unknown HeaderIncludeFormatKind enum");
 }
 
 inline const char *
@@ -64,6 +65,7 @@ headerIncludeFilteringKindToString(HeaderIncludeFilteringKind 
K) {
   case HIFIL_Only_Direct_System:
 return "only-direct-system";
   }
+  llvm_unreachable("Unknown HeaderIncludeFilteringKind enum");
 }
 
 } // end namespace clang



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


[clang-tools-extra] 71a014f - [clangd] Add a newline-eof to the system-include-extractor.test

2022-12-08 Thread Haojian Wu via cfe-commits

Author: Haojian Wu
Date: 2022-12-08T12:48:05+01:00
New Revision: 71a014fe9e92db40279f3901c9f03a048ec4da3f

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

LOG: [clangd] Add a newline-eof to the system-include-extractor.test

This test is executed with config enabled, and it fails if there is an
extra (-Wnewline-eof) compile flag from the user config.

Added: 


Modified: 
clang-tools-extra/clangd/test/system-include-extractor.test

Removed: 




diff  --git a/clang-tools-extra/clangd/test/system-include-extractor.test 
b/clang-tools-extra/clangd/test/system-include-extractor.test
index cb894623a3b68..49bb8a6101338 100644
--- a/clang-tools-extra/clangd/test/system-include-extractor.test
+++ b/clang-tools-extra/clangd/test/system-include-extractor.test
@@ -53,7 +53,7 @@
   "uri": "file://INPUT_DIR/the-file.cpp",
   "languageId":"cpp",
   "version":1,
-  "text":"#include \n#include \n#if !defined(__ARM_ARCH) || 
!defined(__gnu_linux__)\n#error \"Invalid target\"\n#endif"
+  "text":"#include \n#include \n#if !defined(__ARM_ARCH) || 
!defined(__gnu_linux__)\n#error \"Invalid target\"\n#endif\n"
 }
   }
 }



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


[PATCH] D139006: [UpdateTestChecks] Match define for labels

2022-12-08 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added a subscriber: nikic.
lebedev.ri added a comment.

In D139006#3981326 , @sebastian-ne 
wrote:

> I guess this is fine to merge. I’ll leave it for a day in case someone has 
> more comments.

I guess, we could be pedantic and post an RFC to disscuss.
But this really is a bug, and the alternative solutions would only hide it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139006

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


[clang-tools-extra] d03e9f8 - [include-cleaner] Handle base class member access from derived class.

2022-12-08 Thread Viktoriia Bakalova via cfe-commits

Author: Viktoriia Bakalova
Date: 2022-12-08T10:39:18Z
New Revision: d03e9f8fb0741a510308be09b29a13d0a66a6e41

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

LOG: [include-cleaner] Handle base class member access from derived class.

Fix: https://github.com/llvm/llvm-project/issues/59251
Differential Revision: https://reviews.llvm.org/D139087

Added: 


Modified: 
clang-tools-extra/include-cleaner/lib/WalkAST.cpp
clang-tools-extra/include-cleaner/unittests/WalkASTTest.cpp

Removed: 




diff  --git a/clang-tools-extra/include-cleaner/lib/WalkAST.cpp 
b/clang-tools-extra/include-cleaner/lib/WalkAST.cpp
index 7fb3f5697b7e..ff15e62efdfd 100644
--- a/clang-tools-extra/include-cleaner/lib/WalkAST.cpp
+++ b/clang-tools-extra/include-cleaner/lib/WalkAST.cpp
@@ -44,6 +44,12 @@ class ASTWalker : public RecursiveASTVisitor {
 Callback(Loc, *cast(ND->getCanonicalDecl()), RT);
   }
 
+  NamedDecl *resolveType(QualType Type) {
+if (Type->isPointerType())
+  Type = Type->getPointeeType();
+return Type->getAsRecordDecl();
+  }
+
 public:
   ASTWalker(DeclCallback Callback) : Callback(Callback) {}
 
@@ -53,7 +59,12 @@ class ASTWalker : public RecursiveASTVisitor {
   }
 
   bool VisitMemberExpr(MemberExpr *E) {
-report(E->getMemberLoc(), E->getFoundDecl().getDecl());
+// A member expr implies a usage of the class type
+// (e.g., to prevent inserting a header of base class when using base
+// members from a derived object).
+// FIXME: support dependent types, e.g., "std::vector().size()".
+QualType Type = E->getBase()->IgnoreImpCasts()->getType();
+report(E->getMemberLoc(), resolveType(Type));
 return true;
   }
 

diff  --git a/clang-tools-extra/include-cleaner/unittests/WalkASTTest.cpp 
b/clang-tools-extra/include-cleaner/unittests/WalkASTTest.cpp
index d9cf84dc7abe..551eb66bcdef 100644
--- a/clang-tools-extra/include-cleaner/unittests/WalkASTTest.cpp
+++ b/clang-tools-extra/include-cleaner/unittests/WalkASTTest.cpp
@@ -180,10 +180,22 @@ TEST(WalkAST, TemplateNames) {
 }
 
 TEST(WalkAST, MemberExprs) {
-  testWalk("struct S { void $explicit^foo(); };", "void foo() { S{}.^foo(); 
}");
+  testWalk("struct $explicit^S { void foo(); };", "void foo() { S{}.^foo(); 
}");
   testWalk(
-  "struct S { void foo(); }; struct X : S { using S::$explicit^foo; };",
+  "struct S { void foo(); }; struct $explicit^X : S { using S::foo; };",
   "void foo() { X{}.^foo(); }");
+  testWalk("struct Base { int a; }; struct $explicit^Derived : public Base 
{};",
+   "void fun(Derived d) { d.^a; }");
+  testWalk("struct Base { int a; }; struct $explicit^Derived : public Base 
{};",
+   "void fun(Derived* d) { d->^a; }");
+  testWalk("struct Base { int a; }; struct $explicit^Derived : public Base 
{};",
+   "void fun(Derived& d) { d.^a; }");
+  testWalk("struct Base { int a; }; struct $explicit^Derived : public Base 
{};",
+   "void fun() { Derived().^a; }");
+  testWalk("struct Base { int a; }; struct $explicit^Derived : public Base 
{};",
+   "Derived foo(); void fun() { foo().^a; }");
+  testWalk("struct Base { int a; }; struct $explicit^Derived : public Base 
{};",
+   "Derived& foo(); void fun() { foo().^a; }");
 }
 
 TEST(WalkAST, ConstructExprs) {



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


[PATCH] D139087: [include-cleaner] Handle base class member access from derived class.

2022-12-08 Thread Viktoriia Bakalova via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGd03e9f8fb074: [include-cleaner] Handle base class member 
access from derived class. (authored by VitaNuo).

Changed prior to commit:
  https://reviews.llvm.org/D139087?vs=480422=481217#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139087

Files:
  clang-tools-extra/include-cleaner/lib/WalkAST.cpp
  clang-tools-extra/include-cleaner/unittests/WalkASTTest.cpp


Index: clang-tools-extra/include-cleaner/unittests/WalkASTTest.cpp
===
--- clang-tools-extra/include-cleaner/unittests/WalkASTTest.cpp
+++ clang-tools-extra/include-cleaner/unittests/WalkASTTest.cpp
@@ -180,10 +180,22 @@
 }
 
 TEST(WalkAST, MemberExprs) {
-  testWalk("struct S { void $explicit^foo(); };", "void foo() { S{}.^foo(); 
}");
+  testWalk("struct $explicit^S { void foo(); };", "void foo() { S{}.^foo(); 
}");
   testWalk(
-  "struct S { void foo(); }; struct X : S { using S::$explicit^foo; };",
+  "struct S { void foo(); }; struct $explicit^X : S { using S::foo; };",
   "void foo() { X{}.^foo(); }");
+  testWalk("struct Base { int a; }; struct $explicit^Derived : public Base 
{};",
+   "void fun(Derived d) { d.^a; }");
+  testWalk("struct Base { int a; }; struct $explicit^Derived : public Base 
{};",
+   "void fun(Derived* d) { d->^a; }");
+  testWalk("struct Base { int a; }; struct $explicit^Derived : public Base 
{};",
+   "void fun(Derived& d) { d.^a; }");
+  testWalk("struct Base { int a; }; struct $explicit^Derived : public Base 
{};",
+   "void fun() { Derived().^a; }");
+  testWalk("struct Base { int a; }; struct $explicit^Derived : public Base 
{};",
+   "Derived foo(); void fun() { foo().^a; }");
+  testWalk("struct Base { int a; }; struct $explicit^Derived : public Base 
{};",
+   "Derived& foo(); void fun() { foo().^a; }");
 }
 
 TEST(WalkAST, ConstructExprs) {
Index: clang-tools-extra/include-cleaner/lib/WalkAST.cpp
===
--- clang-tools-extra/include-cleaner/lib/WalkAST.cpp
+++ clang-tools-extra/include-cleaner/lib/WalkAST.cpp
@@ -44,6 +44,12 @@
 Callback(Loc, *cast(ND->getCanonicalDecl()), RT);
   }
 
+  NamedDecl *resolveType(QualType Type) {
+if (Type->isPointerType())
+  Type = Type->getPointeeType();
+return Type->getAsRecordDecl();
+  }
+
 public:
   ASTWalker(DeclCallback Callback) : Callback(Callback) {}
 
@@ -53,7 +59,12 @@
   }
 
   bool VisitMemberExpr(MemberExpr *E) {
-report(E->getMemberLoc(), E->getFoundDecl().getDecl());
+// A member expr implies a usage of the class type
+// (e.g., to prevent inserting a header of base class when using base
+// members from a derived object).
+// FIXME: support dependent types, e.g., "std::vector().size()".
+QualType Type = E->getBase()->IgnoreImpCasts()->getType();
+report(E->getMemberLoc(), resolveType(Type));
 return true;
   }
 


Index: clang-tools-extra/include-cleaner/unittests/WalkASTTest.cpp
===
--- clang-tools-extra/include-cleaner/unittests/WalkASTTest.cpp
+++ clang-tools-extra/include-cleaner/unittests/WalkASTTest.cpp
@@ -180,10 +180,22 @@
 }
 
 TEST(WalkAST, MemberExprs) {
-  testWalk("struct S { void $explicit^foo(); };", "void foo() { S{}.^foo(); }");
+  testWalk("struct $explicit^S { void foo(); };", "void foo() { S{}.^foo(); }");
   testWalk(
-  "struct S { void foo(); }; struct X : S { using S::$explicit^foo; };",
+  "struct S { void foo(); }; struct $explicit^X : S { using S::foo; };",
   "void foo() { X{}.^foo(); }");
+  testWalk("struct Base { int a; }; struct $explicit^Derived : public Base {};",
+   "void fun(Derived d) { d.^a; }");
+  testWalk("struct Base { int a; }; struct $explicit^Derived : public Base {};",
+   "void fun(Derived* d) { d->^a; }");
+  testWalk("struct Base { int a; }; struct $explicit^Derived : public Base {};",
+   "void fun(Derived& d) { d.^a; }");
+  testWalk("struct Base { int a; }; struct $explicit^Derived : public Base {};",
+   "void fun() { Derived().^a; }");
+  testWalk("struct Base { int a; }; struct $explicit^Derived : public Base {};",
+   "Derived foo(); void fun() { foo().^a; }");
+  testWalk("struct Base { int a; }; struct $explicit^Derived : public Base {};",
+   "Derived& foo(); void fun() { foo().^a; }");
 }
 
 TEST(WalkAST, ConstructExprs) {
Index: clang-tools-extra/include-cleaner/lib/WalkAST.cpp
===
--- clang-tools-extra/include-cleaner/lib/WalkAST.cpp
+++ clang-tools-extra/include-cleaner/lib/WalkAST.cpp
@@ -44,6 +44,12 @@
 Callback(Loc, *cast(ND->getCanonicalDecl()), RT);
   }
 
+  NamedDecl *resolveType(QualType 

[PATCH] D139570: Add -Wreturn-local-addr, GCC alias for -Wreturn-stack-address

2022-12-08 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

LGTM as far as the functional changes go, but this should have a release note 
and a test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139570

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


[PATCH] D139006: [UpdateTestChecks] Match define for labels

2022-12-08 Thread Sebastian Neubauer via Phabricator via cfe-commits
sebastian-ne added a comment.

I guess this is fine to merge. I’ll leave it for a day in case someone has more 
comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139006

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


[PATCH] D105584: [MLIR][OpenMP] Distribute Construct Operation

2022-12-08 Thread Kiran Chandramohan via Phabricator via cfe-commits
kiranchandramohan requested changes to this revision.
kiranchandramohan added a comment.
This revision now requires changes to proceed.

@abidmalikwaterloo It seems you missed a few of the previous comments. Please 
fix these so that we can approve.




Comment at: mlir/include/mlir/Dialect/OpenMP/OpenMPOps.td:449
  ParentOneOf<["WsLoopOp", "ReductionDeclareOp", 
- "AtomicUpdateOp", "SimdLoopOp"]>]> {
+ "AtomicUpdateOp", "SimdLoopOp","DistributeOp"]>]> {
   let summary = "loop yield and termination operation";

clementval wrote:
> abidmalikwaterloo wrote:
> > clementval wrote:
> > > 
> > What's the problem here? It seems fine to me.
> syntax doesn't match the existing code. Change is highlighted.
Nit: Please fix this (adding a space before `"DistributeOp"`).



Comment at: mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp:211
+//===-===//
+// Verifier for Dristribute Op
+//===-===//

kiranchandramohan wrote:
> 
Nit: Please make this change.



Comment at: mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp:220
+return emitOpError() << "empty upperbound for distribute loop operation";
+  
+  return success();

kiranchandramohan wrote:
> Nit: Check that their sizes are equal as well. And also if step is present 
> then its size matches lowerbound/upperbound.
Nit: Please make this change as well.



Comment at: mlir/test/Dialect/OpenMP/ops.mlir:124
 
+// CHECK-LABEL: omp_DistributeOp
+func.func @omp_DistributeOp(%lb : index, %ub : index, %step : index, %data_var 
: memref, %chunk_var : i32) -> () {

kiranchandramohan wrote:
> Add a pretty-print test as well.
Nit: please add a pretty-print test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105584

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


[PATCH] D135360: [clang][analyzer] Add some more functions to StreamChecker and StdLibraryFunctionsChecker.

2022-12-08 Thread Balázs Kéri via Phabricator via cfe-commits
balazske added a comment.

My current approach is that the POSIX is more strict than the C standard (POSIX 
allows a subset of what C allows). I do not see (errno related) contradiction 
between these standards (except initialization to zero of errno missing from 
POSIX, and possible negative value in errno in POSIX). The checker currently 
works only in POSIX mode for every function, the **ModelPOSIX** setting 
controls only if additional functions are added (all with POSIX rules) (these 
functions could be added with C rules too). One problem exists now, that 
`errno` is set to a non-zero (but not positive only) value at error. Probably 
we should change this to be always positive at error, according to the C 
standard `errno` is positive only, and POSIX does not tell that errno can be 
negative.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135360

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


[PATCH] D139627: clang/X86: Don't emit "min-legal-vector-width"="0"

2022-12-08 Thread Phoebe Wang via Phabricator via cfe-commits
pengfei requested changes to this revision.
pengfei added a comment.
This revision now requires changes to proceed.

The use of `min-legal-vector-width` doesn't look great to me either. I'm more 
than glad if we can remove it totally without any user perceivable affects.
I cannot agree with this change because it neither eliminates the clutter (but 
makes it even worse [1]) nor is NFC to end user.
I think we used `UINT32_MAX` just to be compatible with BCs that generated 
before introduing the attribute. This change definitely breaks the 
compatibility.
Placing a `"min-legal-vector-width" = "512"` doesn't make any sense either. For 
one thing, we cannot place the attribute in pre-built BC files, for another 
`512` is the current max vector suppoted on X86, we cannot guarantee no `1024`, 
`2048` etc. in future and we cannot change it too once compiled into BC files.


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

https://reviews.llvm.org/D139627

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


[PATCH] D137944: [ObjC][ARC] Teach the OptimizeSequences step of ObjCARCOpts about WinEH funclet tokens

2022-12-08 Thread Stefan Gränitz via Phabricator via cfe-commits
sgraenitz added a comment.

This is ready to land and I'd appreciate feedback from one of the authors. 
Anyone else I should add for review?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137944

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


[PATCH] D139398: [AMDGPU] Add bf16 storage support

2022-12-08 Thread Matt Arsenault via Phabricator via cfe-commits
arsenm added inline comments.



Comment at: llvm/lib/Target/AMDGPU/AMDGPUCallingConv.td:49
+  CCIfType<[bf16], CCBitConvertToType>,
+  CCIfType<[v2bf16], CCBitConvertToType>,
   CCIfNotInReg arsenm wrote:
> > Without being added to a register class, all the tablegen changes should 
> > not do anything
> bf16 ones seem to not be needed but if I don't have the v2bf16 ones I get 
> "cannot allocate arguments" in "test_arg_store_v2bf16"
Sounds like a type legality logic bug which I don't want to spend time fighting



Comment at: llvm/lib/Target/AMDGPU/SIISelLowering.cpp:913
+  else
+RegisterVT = (ScalarVT == MVT::bf16 ? MVT::v2bf16 : MVT::v2f16);
   IntermediateVT = RegisterVT;

If you wanted the promote to i32, you could have done it here instead of in the 
tablegen cc handling



Comment at: llvm/lib/Target/AMDGPU/SIISelLowering.cpp:5558
+  // This lowers them into (i16 (bitconvert (f32 (fptrunc x
+  if (Op->getValueType(0) != MVT::i16)
+return SDValue();

Op.getValueType()



Comment at: llvm/lib/Target/AMDGPU/SIISelLowering.cpp:5563
+  return DAG.getNode(ISD::BITCAST, SL, MVT::i16,
+ DAG.getFPExtendOrRound(Op->getOperand(0), SL, MVT::f16));
+}

Should be specific cast, not FPExtOrRound. I don't think the FP_ROUND case 
would be correct



Comment at: llvm/lib/Target/AMDGPU/SIISelLowering.cpp:5569
+  // (bitconvert x
+  if (!Op->getValueType(0).isFloatingPoint() ||
+  Op->getOperand(0).getValueType() != MVT::i16)

Should use Op.getValueType() instead of Op->getValueType(0)



Comment at: llvm/lib/Target/AMDGPU/SIISelLowering.cpp:5573-5576
+  SDLoc SL(Op);
+  return DAG.getNode(
+  ISD::FP_EXTEND, SL, MVT::f32,
+  DAG.getNode(ISD::BITCAST, SL, MVT::f16, Op->getOperand(0)));

ExpandNode covers lowering BF16_TO_FP. It also has a shift by 16-bits into the 
high bits. Is this correct?



Comment at: llvm/lib/Target/AMDGPU/SIISelLowering.cpp:4819-4831
+// When we don't have 16 bit instructions, bf16 is illegal and gets
+// softened to i16 for storage, with float being used for arithmetic.
+//
+// After softening, some i16 -> fp32 bf16_to_fp operations can be left 
over.
+// Lower those to (f32 (fp_extend (f16 (bitconvert x
+if (!Op->getValueType(0).isFloatingPoint() ||
+Op->getOperand(0).getValueType() != MVT::i16)

Pierre-vh wrote:
> arsenm wrote:
> > Pierre-vh wrote:
> > > arsenm wrote:
> > > > Pierre-vh wrote:
> > > > > arsenm wrote:
> > > > > > The generic legalizer should have handled this?
> > > > > It looks like those operations are not implemented in the generic 
> > > > > legalizer, e.g. I get 
> > > > > ``` 
> > > > > Do not know how to promote this operator's operand!
> > > > > ```
> > > > Right, this is the code that would go there
> > > Do I just copy/paste this code in that PromoteInt function, and keep a 
> > > copy here too in LowerOperation? (not really a fan of copy-pasting code 
> > > in different files, I'd rather keep it all here)
> > > We need to have the lowering too AFAIK, it didn't go well when I tried to 
> > > remove it
> > I'm not following why you need to handle it here
> IIRC:
>  - I need to handle FP_TO_BF16 in ReplaceNodeResult because that's what the 
> Integer Legalizer calls (through CustomLowerNode)
>  - I need to handle both opcodes in LowerOperation because otherwise they'll 
> fail selection. They can be left over from expanding/legalizing other 
> operations.
But why are they custom? We don't have to handle FP16_TO_FP or FP_TO_FP16 
there, and they aren't custom lowered. They have the same basic properties. We 
have this:


```
setOperationAction(ISD::FP16_TO_FP, MVT::i16, Promote);
AddPromotedToType(ISD::FP16_TO_FP, MVT::i16, MVT::i32);
setOperationAction(ISD::FP_TO_FP16, MVT::i16, Promote);
AddPromotedToType(ISD::FP_TO_FP16, MVT::i16, MVT::i32);
```

I'd expect the same basic pattern


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139398

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


[PATCH] D139544: [clang][dataflow] Add support for structured bindings of tuple-like types.

2022-12-08 Thread Domján Dániel via Phabricator via cfe-commits
isuckatcs added a comment.

> I'm particularly interested in the case of tuple-like containers, which is a 
> little different (though I think the same point holds)

`std::pair<>` is actually tuple-like if that's what you meant. Only tuple-like 
types have holding vars inside a `DecompositionDecl`.

> Here, both lines 7 and 13 are blank but seem to be the underlying tuple 
> that's being deconstructed. Are these different instances of the 
> DecompositionDecl or are they (unprinted) references back to line 4?

Those lines are what you see as `DeclRefExpr Decomposition ''` in the AST. 
Which are indeed references back to line 4 as you mentioned.

> I'm still bothered that this seems to violate the design/philosophy of the 
> CFG, which I take as ensuring that elements proceed in the order of operation.

I think in this case the elements do proceed in order of operation. When you 
create a structured binding by value to a tuple like type, the copy constructor 
of the type is invoked first.

Let's assume that you have a tuple-like `std::pair p{1, 2};` and you 
create the structured binding `auto [a, b] = p;`.

1. The copy constructor of `p` is invoked first and a copy get's created. Let's 
call this copy `tmp`. Note that if the copy constructor has side effects, they 
will also be visible.
2. A new variable for each element in the tuple is created and is initialized 
by `get(tmp);`. It is important that the initialization happens from the 
copy, `tmp` and not from the original tuple `p`.

The CFG resembles this behaviour. If you look at both of the example CFGs in 
this discussion, you can see that both of them begin with the constructor 
invocation.

   7: p
   8: [B1.7] (ImplicitCastExpr, NoOp, const pair)
   9: [B1.8] (CXXConstructExpr, [B1.10], std::pair)
  10: auto = p;

  1: mk
  2: [B1.1] (ImplicitCastExpr, FunctionToPointerDecay, std::tuple<_Bool, int> 
(*)(void))
  3: [B1.2]() (CXXRecordTypedCall, [B1.4])
  4: auto = mk();

Points `4` and `10` are a bit weird, but that's where the copy is created, 
however the copy is unnamed. This unnamed copy is what I refered to as `tmp`.

Note that when you do a regular copy-constructor invocation like

  std::tuple mk;
  std::tuple mk2 = mk;

you would get

  3: mk
  4: [B1.3] (ImplicitCastExpr, NoOp, const class std::tuple<_Bool, int>)
  5: [B1.4] (CXXConstructExpr, [B1.6], std::tuple<_Bool, int>)
  6: std::tuple mk2 = mk;
   ^^^This is the name that's missing from the CFGs 
above.

After this the `get<>()` calls simply use this unnamed copy to initialize the 
elements from first to last, so everything seems to proceed in order in the CFG.

> Finally, a nit: why doesn't line 13 in your example, and lines 7 and 13 in my 
> example, print? Is that something that I could add to the CFG printer?

If I remember correctly (and my intuition is correct based on the examples) a 
`DeclRefExpr` in the CFG is the name of the variable being referenced. 
So for example `DeclRefExpr 'p'`  is simply `p` in the CFG.

If you look at the AST in my example, you can see that the `DeclRefExpr` to the 
decomposition is `DeclRefExpr Decomposition ''`, where  `''` 
is supposed to be the name of the variable. So I think the empty line comes 
from here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139544

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


[clang-tools-extra] 4a68bab - [clang-doc] Add template support.

2022-12-08 Thread Brett Wilson via cfe-commits

Author: Brett Wilson
Date: 2022-12-08T08:02:02-08:00
New Revision: 4a68babd9973f043fd3e40f159fbb990880606a6

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

LOG: [clang-doc] Add template support.

Reads template information from the AST and adds template parameters and
specialization information to the corresponding clang-doc structures.

Add a "QualName" to the Reference struct which includes the full
qualified type name. The Reference object represents a link in the
HTML/MD generators so is based on the unqualified name. But this does
not encode C-V qualifiers or template information that decorate the
name. The new QualName member encodes all of this information and also
makes it easier for the generators or downsteam YAML consumers to
generate the full name (before they had to process the "Path").

In test code that was changed, remove made-up paths to built-in types
like "int". In addition to slightnly cleaning up the code, these types
do not have paths in real execution, and generating incorrect references
to nonexistant data may complicate future changes in the generators.

Convert llvm::Optional to std::optional (YAML library requires this for
the new usage, and this makes everything consistent according to the
llvm::Optional -> std::optional transition).

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

Added: 
clang-tools-extra/test/clang-doc/templates.cpp

Modified: 
clang-tools-extra/clang-doc/BitcodeReader.cpp
clang-tools-extra/clang-doc/BitcodeWriter.cpp
clang-tools-extra/clang-doc/BitcodeWriter.h
clang-tools-extra/clang-doc/Representation.cpp
clang-tools-extra/clang-doc/Representation.h
clang-tools-extra/clang-doc/Serialize.cpp
clang-tools-extra/clang-doc/YAMLGenerator.cpp
clang-tools-extra/test/clang-doc/single-file-public.cpp
clang-tools-extra/test/clang-doc/single-file.cpp
clang-tools-extra/unittests/clang-doc/HTMLGeneratorTest.cpp
clang-tools-extra/unittests/clang-doc/SerializeTest.cpp
clang-tools-extra/unittests/clang-doc/YAMLGeneratorTest.cpp

Removed: 




diff  --git a/clang-tools-extra/clang-doc/BitcodeReader.cpp 
b/clang-tools-extra/clang-doc/BitcodeReader.cpp
index c6928f60f3970..9ac60fa73a782 100644
--- a/clang-tools-extra/clang-doc/BitcodeReader.cpp
+++ b/clang-tools-extra/clang-doc/BitcodeReader.cpp
@@ -350,6 +350,8 @@ llvm::Error parseRecord(const Record , unsigned ID, 
llvm::StringRef Blob,
 return decodeRecord(R, I->USR, Blob);
   case REFERENCE_NAME:
 return decodeRecord(R, I->Name, Blob);
+  case REFERENCE_QUAL_NAME:
+return decodeRecord(R, I->QualName, Blob);
   case REFERENCE_TYPE:
 return decodeRecord(R, I->RefType, Blob);
   case REFERENCE_PATH:
@@ -362,6 +364,29 @@ llvm::Error parseRecord(const Record , unsigned ID, 
llvm::StringRef Blob,
   }
 }
 
+llvm::Error parseRecord(const Record , unsigned ID, llvm::StringRef Blob,
+TemplateInfo *I) {
+  // Currently there are no child records of TemplateInfo (only child blocks).
+  return llvm::createStringError(llvm::inconvertibleErrorCode(),
+ "invalid field for TemplateParamInfo");
+}
+
+llvm::Error parseRecord(const Record , unsigned ID, llvm::StringRef Blob,
+TemplateSpecializationInfo *I) {
+  if (ID == TEMPLATE_SPECIALIZATION_OF)
+return decodeRecord(R, I->SpecializationOf, Blob);
+  return llvm::createStringError(llvm::inconvertibleErrorCode(),
+ "invalid field for TemplateParamInfo");
+}
+
+llvm::Error parseRecord(const Record , unsigned ID, llvm::StringRef Blob,
+TemplateParamInfo *I) {
+  if (ID == TEMPLATE_PARAM_CONTENTS)
+return decodeRecord(R, I->Contents, Blob);
+  return llvm::createStringError(llvm::inconvertibleErrorCode(),
+ "invalid field for TemplateParamInfo");
+}
+
 template  llvm::Expected getCommentInfo(T I) {
   return llvm::createStringError(llvm::inconvertibleErrorCode(),
  "invalid type cannot contain CommentInfo");
@@ -594,6 +619,45 @@ template <> void addChild(BaseRecordInfo *I, FunctionInfo 
&) {
   I->Children.Functions.emplace_back(std::move(R));
 }
 
+// TemplateParam children. These go into either a TemplateInfo (for template
+// parameters) or TemplateSpecializationInfo (for the specialization's
+// parameters).
+template  void addTemplateParam(T I, TemplateParamInfo &) {
+  llvm::errs() << "invalid container for template parameter";
+  exit(1);
+}
+template <> void addTemplateParam(TemplateInfo *I, TemplateParamInfo &) {
+  I->Params.emplace_back(std::move(P));
+}
+template <>
+void addTemplateParam(TemplateSpecializationInfo *I, TemplateParamInfo &) {
+  

[PATCH] D139154: [clang-doc] Add template support

2022-12-08 Thread Brett Wilson via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG4a68babd9973: [clang-doc] Add template support. (authored by 
brettw).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139154

Files:
  clang-tools-extra/clang-doc/BitcodeReader.cpp
  clang-tools-extra/clang-doc/BitcodeWriter.cpp
  clang-tools-extra/clang-doc/BitcodeWriter.h
  clang-tools-extra/clang-doc/Representation.cpp
  clang-tools-extra/clang-doc/Representation.h
  clang-tools-extra/clang-doc/Serialize.cpp
  clang-tools-extra/clang-doc/YAMLGenerator.cpp
  clang-tools-extra/test/clang-doc/single-file-public.cpp
  clang-tools-extra/test/clang-doc/single-file.cpp
  clang-tools-extra/test/clang-doc/templates.cpp
  clang-tools-extra/unittests/clang-doc/HTMLGeneratorTest.cpp
  clang-tools-extra/unittests/clang-doc/SerializeTest.cpp
  clang-tools-extra/unittests/clang-doc/YAMLGeneratorTest.cpp

Index: clang-tools-extra/unittests/clang-doc/YAMLGeneratorTest.cpp
===
--- clang-tools-extra/unittests/clang-doc/YAMLGeneratorTest.cpp
+++ clang-tools-extra/unittests/clang-doc/YAMLGeneratorTest.cpp
@@ -28,10 +28,11 @@
   I.Path = "path/to/A";
   I.Namespace.emplace_back(EmptySID, "A", InfoType::IT_namespace);
 
-  I.Children.Namespaces.emplace_back(EmptySID, "ChildNamespace",
- InfoType::IT_namespace,
- "path/to/A/Namespace");
+  I.Children.Namespaces.emplace_back(
+  EmptySID, "ChildNamespace", InfoType::IT_namespace,
+  "path::to::A::Namespace::ChildNamespace", "path/to/A/Namespace");
   I.Children.Records.emplace_back(EmptySID, "ChildStruct", InfoType::IT_record,
+  "path::to::A::Namespace::ChildStruct",
   "path/to/A/Namespace");
   I.Children.Functions.emplace_back();
   I.Children.Functions.back().Name = "OneFunction";
@@ -53,13 +54,16 @@
 Namespace:
   - Type:Namespace
 Name:'A'
+QualName:'A'
 ChildNamespaces:
   - Type:Namespace
 Name:'ChildNamespace'
+QualName:'path::to::A::Namespace::ChildNamespace'
 Path:'path/to/A/Namespace'
 ChildRecords:
   - Type:Record
 Name:'ChildStruct'
+QualName:'path::to::A::Namespace::ChildStruct'
 Path:'path/to/A/Namespace'
 ChildFunctions:
   - USR: ''
@@ -83,8 +87,7 @@
   I.DefLoc = Location(10, llvm::SmallString<16>{"test.cpp"});
   I.Loc.emplace_back(12, llvm::SmallString<16>{"test.cpp"});
 
-  I.Members.emplace_back(TypeInfo("int", "path/to/int"), "X",
- AccessSpecifier::AS_private);
+  I.Members.emplace_back(TypeInfo("int"), "X", AccessSpecifier::AS_private);
 
   // Member documentation.
   CommentInfo TopComment;
@@ -103,15 +106,15 @@
AccessSpecifier::AS_public, true);
   I.Bases.back().Children.Functions.emplace_back();
   I.Bases.back().Children.Functions.back().Name = "InheritedFunctionOne";
-  I.Bases.back().Members.emplace_back(TypeInfo("int", "path/to/int"), "N",
+  I.Bases.back().Members.emplace_back(TypeInfo("int"), "N",
   AccessSpecifier::AS_private);
   // F is in the global namespace
   I.Parents.emplace_back(EmptySID, "F", InfoType::IT_record, "");
   I.VirtualParents.emplace_back(EmptySID, "G", InfoType::IT_record,
-"path/to/G");
+"path::to::G::G", "path/to/G");
 
   I.Children.Records.emplace_back(EmptySID, "ChildStruct", InfoType::IT_record,
-  "path/to/A/r");
+  "path::to::A::r::ChildStruct", "path/to/A/r");
   I.Children.Functions.emplace_back();
   I.Children.Functions.back().Name = "OneFunction";
   I.Children.Enums.emplace_back();
@@ -131,6 +134,7 @@
 Namespace:
   - Type:Namespace
 Name:'A'
+QualName:'A'
 DefLocation:
   LineNumber:  10
   Filename:'test.cpp'
@@ -142,7 +146,7 @@
 Members:
   - Type:
   Name:'int'
-  Path:'path/to/int'
+  QualName:'int'
 Name:'X'
 Access:  Private
 Description:
@@ -161,7 +165,7 @@
 Members:
   - Type:
   Name:'int'
-  Path:'path/to/int'
+  QualName:'int'
 Name:'N'
 Access:  Private
 ChildFunctions:
@@ -178,10 +182,12 @@
 VirtualParents:
   - Type:Record
 Name:'G'
+QualName:'path::to::G::G'
 Path:'path/to/G'
 ChildRecords:
   - Type:Record
 Name:'ChildStruct'
+QualName:'path::to::A::r::ChildStruct'
 

[PATCH] D139632: [clang-cl] Ignore #pragma managed / #pragma unmanaged

2022-12-08 Thread Tobias Hieta via Phabricator via cfe-commits
thieta added inline comments.



Comment at: clang/lib/Lex/Pragma.cpp:1960
 
+/// "\#pragma managed"
+/// "\#pragma managed(...)"

I don't see the other comments in this file having `"\#` I think you can drop 
that. Also two `/` for the comments, not three.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139632

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


[PATCH] D139450: Warn about unsupported ibmlongdouble

2022-12-08 Thread Tulio Magno Quites Machado Filho via Phabricator via cfe-commits
tuliom added a comment.

In D139450#3981486 , @qiucf wrote:

> Thanks for the patch! But does libc++ support to be built with 
> `-mabi=ieeelongdouble` now?

@qiucf libc++ can be built with `-mabi=ieeelongdouble`, but it supports only a 
single long double format, i.e. if it's built with `-mabi=ieeelongdouble`, it 
won't support IBM double-double and vice versa.
This is already being used in Fedora Rawhide at the moment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139450

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


[PATCH] D139547: [NFC] Correct argument comment typo

2022-12-08 Thread Alf via Phabricator via cfe-commits
gAlfonso-bit added a comment.

@MaskRay How may I get commit permissions if I may ask?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139547

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


[PATCH] D139166: [OPENMP51] Codegen support for error directive.

2022-12-08 Thread Jennifer Yu via Phabricator via cfe-commits
jyu2 updated this revision to Diff 481319.
jyu2 added a comment.

Rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139166

Files:
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/lib/CodeGen/CGOpenMPRuntime.h
  clang/lib/CodeGen/CGStmtOpenMP.cpp
  clang/test/OpenMP/error_codegen.cpp
  llvm/include/llvm/Frontend/OpenMP/OMPKinds.def

Index: llvm/include/llvm/Frontend/OpenMP/OMPKinds.def
===
--- llvm/include/llvm/Frontend/OpenMP/OMPKinds.def
+++ llvm/include/llvm/Frontend/OpenMP/OMPKinds.def
@@ -198,6 +198,7 @@
 __OMP_RTL(__kmpc_barrier, false, Void, IdentPtr, Int32)
 __OMP_RTL(__kmpc_cancel, false, Int32, IdentPtr, Int32, Int32)
 __OMP_RTL(__kmpc_cancel_barrier, false, Int32, IdentPtr, Int32)
+__OMP_RTL(__kmpc_error, false, Void, IdentPtr, Int32, Int8Ptr)
 __OMP_RTL(__kmpc_flush, false, Void, IdentPtr)
 __OMP_RTL(__kmpc_global_thread_num, false, Int32, IdentPtr)
 __OMP_RTL(__kmpc_get_hardware_thread_id_in_block, false, Int32, )
Index: clang/test/OpenMP/error_codegen.cpp
===
--- /dev/null
+++ clang/test/OpenMP/error_codegen.cpp
@@ -0,0 +1,67 @@
+// RUN: %clang_cc1 -std=c++11 -fopenmp -fopenmp-version=51 -triple x86_64 \
+// RUN:   -emit-llvm -o - %s | FileCheck %s
+
+// RUN: %clang_cc1 -std=c++11 -fopenmp-simd -fopenmp-version=51 \
+// RUN:  -debug-info-kind=limited -triple x86_64 -emit-llvm -o - %s |  \
+// RUN:  FileCheck  --check-prefix SIMD %s
+
+//CHECK: @.str = private unnamed_addr constant [23 x i8] c"GPU compiler required.\00", align 1
+//CHECK: @0 = private unnamed_addr constant {{.*}}error_codegen.cpp;main;52;1;;\00", align 1
+//CHECK: @1 = private unnamed_addr constant %struct.ident_t { i32 0, i32 2, i32 0, i32 {{.*}}, ptr @0 }, align 8
+//CHECK: @.str.1 = private unnamed_addr constant [27 x i8] c"Note this is functioncall.\00", align 1
+//CHECK: @2 = private unnamed_addr constant {{.*}}error_codegen.cpp;main;54;1;;\00", align 1
+//CHECK: @3 = private unnamed_addr constant %struct.ident_t { i32 0, i32 2, i32 0, i32 {{.*}}, ptr @2 }, align 8
+//CHECK: @.str.2 = private unnamed_addr constant [23 x i8] c"GNU compiler required.\00", align 1
+//CHECK: @4 = private unnamed_addr constant {{.*}}error_codegen.cpp;tmain;29;1;;\00", align 1
+//CHECK: @5 = private unnamed_addr constant %struct.ident_t { i32 0, i32 2, i32 0, i32 {{.*}}, ptr @4 }, align 8
+//CHECK: @.str.3 = private unnamed_addr constant [22 x i8] c"Notice: add for loop.\00", align 1
+//CHECK: @6 = private unnamed_addr constant {{.*}}error_codegen.cpp;tmain;32;1;;\00", align 1
+//CHECK: @7 = private unnamed_addr constant %struct.ident_t { i32 0, i32 2, i32 0, i32 {{.*}}, ptr @6 }, align 8
+//CHECK: @8 = private unnamed_addr constant {{.*}}error_codegen.cpp;tmain;38;1;;\00", align 1
+//CHECK: @9 = private unnamed_addr constant %struct.ident_t { i32 0, i32 2, i32 0, i32 {{.*}}, ptr @8 }, align 8
+
+void foo() {}
+
+template 
+int tmain(T argc, char **argv) {
+  T b = argc, c, d, e, f, g;
+  static int a;
+#pragma omp error at(execution) severity(fatal) message("GNU compiler required.")
+  a = argv[0][0];
+  ++a;
+#pragma omp error at(execution) severity(warning) message("Notice: add for loop.")
+  {
+int b = 10;
+T c = 100;
+a = b + c;
+  }
+#pragma omp  error at(execution) severity(fatal) message("GPU compiler required.")
+  foo();
+return N;
+}
+// CHECK-LABEL: @main(
+// SIMD-LABEL: @main(
+// CHECK:call void @__kmpc_error(ptr @1, i32 2, ptr @.str)
+// SIMD-NOT:call void @__kmpc_error(ptr @1, i32 2, ptr @.str)
+// CHECK:call void @__kmpc_error(ptr @3, i32 1, ptr @.str.1)
+// SIMD-NOT:call void @__kmpc_error(ptr @3, i32 1, ptr @.str.1)
+//
+int main (int argc, char **argv) {
+  int b = argc, c, d, e, f, g;
+  static int a;
+#pragma omp error at(execution) severity(fatal) message("GPU compiler required.")
+   a=2;
+#pragma omp error at(execution) severity(warning) message("Note this is functioncall.")
+  foo();
+  tmain(argc, argv);
+}
+
+//CHECK-LABEL: @_Z5tmainIiLi10EEiT_PPc(
+//SIMD-LABEL: @_Z5tmainIiLi10EEiT_PPc(
+//CHECK: call void @__kmpc_error(ptr @5, i32 2, ptr @.str.2)
+//CHECK: call void @__kmpc_error(ptr @7, i32 1, ptr @.str.3)
+//CHECK: call void @__kmpc_error(ptr @9, i32 2, ptr @.str)
+//SIMD-NOT: call void @__kmpc_error(ptr @5, i32 2, ptr @.str.2)
+//SIMD-NOT: call void @__kmpc_error(ptr @7, i32 1, ptr @.str.3)
+//SIMD-NOT: call void @__kmpc_error(ptr @9, i32 2, ptr @.str)
+//CHECK: ret i32 10
Index: clang/lib/CodeGen/CGStmtOpenMP.cpp
===
--- clang/lib/CodeGen/CGStmtOpenMP.cpp
+++ clang/lib/CodeGen/CGStmtOpenMP.cpp
@@ -5246,7 +5246,13 @@
 }
 
 void CodeGenFunction::EmitOMPErrorDirective(const OMPErrorDirective ) {
-  llvm_unreachable("CodeGen for 'omp error' is not supported yet.");
+  const OMPMessageClause *MC = 

[PATCH] D138597: DebugInfo: Add/support new DW_LANG codes for recent C and C++ versions

2022-12-08 Thread David Blaikie via Phabricator via cfe-commits
dblaikie reopened this revision.
dblaikie added a comment.
This revision is now accepted and ready to land.

(just a side note I discovered while looking into this: seems someone else had 
this idea before & came to similar conclusions: 
https://reviews.llvm.org/D104118#2840490 )


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D138597

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


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

2022-12-08 Thread Kevin P. Neal via Phabricator via cfe-commits
kpn added a comment.

It looks like clang does have at least one test that checks for the strictfp 
attribute on function definitions. We also have a number that test for the 
strictfp attribute on function calls. So I think our test coverage is in good 
shape.

LGTM.


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

https://reviews.llvm.org/D139629

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


[PATCH] D139302: [RISCV] Add Syntacore SCR1 CPU model

2022-12-08 Thread Craig Topper via Phabricator via cfe-commits
craig.topper added a comment.

Should the names be prefixed with "syntacore-". I assume there could be an 
SCR2, etc. in the future?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139302

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


[PATCH] D139400: [clang] Show error when a local variables is passed as default template parameter

2022-12-08 Thread Jens Massberg via Phabricator via cfe-commits
massberg updated this revision to Diff 481264.
massberg added a comment.

Use isLocalVarDecl to check if we have a local variable.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139400

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaTemplate.cpp
  clang/test/SemaTemplate/default-template-arguments.cpp


Index: clang/test/SemaTemplate/default-template-arguments.cpp
===
--- /dev/null
+++ clang/test/SemaTemplate/default-template-arguments.cpp
@@ -0,0 +1,14 @@
+// RUN: %clang_cc1 -fsyntax-only -std=c++20 -verify %s
+
+namespace GH48755 {
+constexpr auto z = 2;
+
+auto f() {
+  const auto x = 1;
+
+  auto lambda1 = []  {}; // expected-error {{local variable 'x' 
may not be used as default parameter}}
+  auto lambda2 = []  {};
+  auto lambda3 = []  {};
+  auto lambda4 = []  {};
+}
+}
Index: clang/lib/Sema/SemaTemplate.cpp
===
--- clang/lib/Sema/SemaTemplate.cpp
+++ clang/lib/Sema/SemaTemplate.cpp
@@ -8,6 +8,7 @@
 //  This file implements semantic analysis for C++ templates.
 
//===--===//
 
+#include 
 #include "TreeTransform.h"
 #include "clang/AST/ASTConsumer.h"
 #include "clang/AST/ASTContext.h"
@@ -1587,6 +1588,17 @@
 
   // Check the well-formedness of the default template argument, if provided.
   if (Default) {
+// Local variables may not be used as default template arguments.
+if (auto *DRE = dyn_cast(Default)) {
+  if (VarDecl *VD = dyn_cast(DRE->getDecl())) {
+if (VD->isLocalVarDecl()) {
+  Diag(DRE->getLocation(),
+   diag::err_local_variable_as_default_in_template)
+  << VD->getNameAsString();
+}
+  }
+}
+
 // Check for unexpanded parameter packs.
 if (DiagnoseUnexpandedParameterPack(Default, UPPC_DefaultArgument))
   return Param;
Index: clang/include/clang/Basic/DiagnosticSemaKinds.td
===
--- clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -7900,6 +7900,9 @@
   def warn_cxx17_compat_lambda_def_ctor_assign : Warning<
 "%select{default construction|assignment}0 of lambda is incompatible with "
 "C++ standards before C++20">, InGroup, DefaultIgnore;
+
+  def err_local_variable_as_default_in_template : Error<
+  "local variable '%0' may not be used as default parameter">;
 }
 
 def err_return_in_captured_stmt : Error<


Index: clang/test/SemaTemplate/default-template-arguments.cpp
===
--- /dev/null
+++ clang/test/SemaTemplate/default-template-arguments.cpp
@@ -0,0 +1,14 @@
+// RUN: %clang_cc1 -fsyntax-only -std=c++20 -verify %s
+
+namespace GH48755 {
+constexpr auto z = 2;
+
+auto f() {
+  const auto x = 1;
+
+  auto lambda1 = []  {}; // expected-error {{local variable 'x' may not be used as default parameter}}
+  auto lambda2 = []  {};
+  auto lambda3 = []  {};
+  auto lambda4 = []  {};
+}
+}
Index: clang/lib/Sema/SemaTemplate.cpp
===
--- clang/lib/Sema/SemaTemplate.cpp
+++ clang/lib/Sema/SemaTemplate.cpp
@@ -8,6 +8,7 @@
 //  This file implements semantic analysis for C++ templates.
 //===--===//
 
+#include 
 #include "TreeTransform.h"
 #include "clang/AST/ASTConsumer.h"
 #include "clang/AST/ASTContext.h"
@@ -1587,6 +1588,17 @@
 
   // Check the well-formedness of the default template argument, if provided.
   if (Default) {
+// Local variables may not be used as default template arguments.
+if (auto *DRE = dyn_cast(Default)) {
+  if (VarDecl *VD = dyn_cast(DRE->getDecl())) {
+if (VD->isLocalVarDecl()) {
+  Diag(DRE->getLocation(),
+   diag::err_local_variable_as_default_in_template)
+  << VD->getNameAsString();
+}
+  }
+}
+
 // Check for unexpanded parameter packs.
 if (DiagnoseUnexpandedParameterPack(Default, UPPC_DefaultArgument))
   return Param;
Index: clang/include/clang/Basic/DiagnosticSemaKinds.td
===
--- clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -7900,6 +7900,9 @@
   def warn_cxx17_compat_lambda_def_ctor_assign : Warning<
 "%select{default construction|assignment}0 of lambda is incompatible with "
 "C++ standards before C++20">, InGroup, DefaultIgnore;
+
+  def err_local_variable_as_default_in_template : Error<
+  "local variable '%0' may not be used as default parameter">;
 }
 
 def err_return_in_captured_stmt : Error<
___

[PATCH] D137107: Allow MS extension: support of constexpr with __declspec(dllimport).

2022-12-08 Thread Zahira Ammarguellat via Phabricator via cfe-commits
zahiraam updated this revision to Diff 481271.

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

https://reviews.llvm.org/D137107

Files:
  clang/include/clang/Basic/DiagnosticCommonKinds.td
  clang/lib/AST/ExprConstant.cpp
  clang/lib/CodeGen/CGDeclCXX.cpp
  clang/lib/CodeGen/CGExprConstant.cpp
  clang/test/CodeGenCXX/dllimport.cpp
  clang/test/SemaCXX/PR19955.cpp
  clang/test/SemaCXX/constant-expression-cxx11.cpp
  clang/test/SemaCXX/dllimport-constexpr.cpp

Index: clang/test/SemaCXX/dllimport-constexpr.cpp
===
--- clang/test/SemaCXX/dllimport-constexpr.cpp
+++ clang/test/SemaCXX/dllimport-constexpr.cpp
@@ -40,7 +40,6 @@
 // constexpr initialization doesn't work for dllimport things.
 // expected-error@+1{{must be initialized by a constant expression}}
 constexpr void (*constexpr_import_func)() = _func;
-// expected-error@+1{{must be initialized by a constant expression}}
 constexpr int *constexpr_import_int = _int;
 // expected-error@+1{{must be initialized by a constant expression}}
 constexpr void (Foo::*constexpr_memptr)() = ::imported_method;
@@ -60,3 +59,11 @@
   // expected-note@+1 {{requested here}}
   StaticConstexpr::g_fp();
 }
+
+extern int __declspec(dllimport) val;
+constexpr int& val_ref = val;
+
+void assigndllimporttoconst () {
+  extern int _declspec(dllimport) val;
+  constexpr int& val_ref = val;
+}
Index: clang/test/SemaCXX/constant-expression-cxx11.cpp
===
--- clang/test/SemaCXX/constant-expression-cxx11.cpp
+++ clang/test/SemaCXX/constant-expression-cxx11.cpp
@@ -1595,7 +1595,7 @@
   void f(int k) { // expected-note {{here}}
 int arr[k]; // expected-warning {{C99}} expected-note {{function parameter 'k'}}
 constexpr int n = 1 +
-sizeof(arr) // expected-error {{constant expression}}
+sizeof(arr) // expected-error{{constexpr variable 'n' must be initialized by a constant expression}}
 * 3;
   }
 }
Index: clang/test/SemaCXX/PR19955.cpp
===
--- clang/test/SemaCXX/PR19955.cpp
+++ clang/test/SemaCXX/PR19955.cpp
@@ -2,7 +2,7 @@
 // RUN: %clang_cc1 -triple i686-mingw32 -verify -std=c++11 %s
 
 extern int __attribute__((dllimport)) var;
-constexpr int *varp =  // expected-error {{must be initialized by a constant expression}}
+constexpr int *varp = 
 
 extern __attribute__((dllimport)) void fun();
 constexpr void (*funp)(void) =  // expected-error {{must be initialized by a constant expression}}
Index: clang/test/CodeGenCXX/dllimport.cpp
===
--- clang/test/CodeGenCXX/dllimport.cpp
+++ clang/test/CodeGenCXX/dllimport.cpp
@@ -1,5 +1,5 @@
-// RUN: %clang_cc1 -no-enable-noundef-analysis -triple i686-windows-msvc   -fno-rtti -fno-threadsafe-statics -fms-extensions -emit-llvm -std=c++1y -O0 -o - %s -DMSABI -w | FileCheck --check-prefix=MSC --check-prefix=M32 %s
-// RUN: %clang_cc1 -no-enable-noundef-analysis -triple x86_64-windows-msvc -fno-rtti -fno-threadsafe-statics -fms-extensions -emit-llvm -std=c++1y -O0 -o - %s -DMSABI -w | FileCheck --check-prefix=MSC --check-prefix=M64 %s
+// RUN: %clang_cc1 -no-enable-noundef-analysis -triple i686-windows-msvc   -fno-rtti -fno-threadsafe-statics -fms-extensions -emit-llvm -std=c++1y -O0 -o - %s -DMSABI -w | FileCheck --check-prefix=MSC --check-prefix=M32 --check-prefix=GL32 %s
+// RUN: %clang_cc1 -no-enable-noundef-analysis -triple x86_64-windows-msvc -fno-rtti -fno-threadsafe-statics -fms-extensions -emit-llvm -std=c++1y -O0 -o - %s -DMSABI -w | FileCheck --check-prefix=MSC --check-prefix=M64 --check-prefix=GL64 %s
 // RUN: %clang_cc1 -no-enable-noundef-analysis -triple i686-windows-gnu-fno-rtti -fno-threadsafe-statics -fms-extensions -emit-llvm -std=c++1y -O0 -o - %s -w | FileCheck --check-prefix=GNU --check-prefix=G32 %s
 // RUN: %clang_cc1 -no-enable-noundef-analysis -triple x86_64-windows-gnu  -fno-rtti -fno-threadsafe-statics -fms-extensions -emit-llvm -std=c++1y -O0 -o - %s -w | FileCheck --check-prefix=GNU %s
 // RUN: %clang_cc1 -no-enable-noundef-analysis -triple i686-windows-msvc   -fno-rtti -fno-threadsafe-statics -fms-extensions -fms-compatibility-version=18.00 -emit-llvm -std=c++1y -O1 -disable-llvm-passes -o - %s -DMSABI -w | FileCheck --check-prefix=MO1 --check-prefix=M18 %s
@@ -737,8 +737,6 @@
 
 namespace PR19933 {
 // Don't dynamically initialize dllimport vars.
-// MSC2-NOT: @llvm.global_ctors
-// GNU2-NOT: @llvm.global_ctors
 
   struct NonPOD { NonPOD(); };
   template  struct A { static NonPOD x; };
@@ -856,6 +854,12 @@
 USEMEMFUNC(PR23770BaseTemplate, f);
 // M32-DAG: declare dllimport x86_thiscallcc void @"?f@?$PR23770BaseTemplate@H@@QAEXXZ"
 
+// MSC-DAG: @"?val@@3HA" = external dllimport global i32
+// GL32-DAG: @"?x@@3PAHA" = dso_local global ptr null
+// GL64-DAG: @"?x@@3PEAHEA" = dso_local global ptr null

[clang] 23e1078 - Add distinguished content to the empty test headers.

2022-12-08 Thread Haojian Wu via cfe-commits

Author: Haojian Wu
Date: 2022-12-08T16:27:04+01:00
New Revision: 23e1078a2fee686e54f1da93de20afc01c47f25d

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

LOG: Add distinguished content to the empty test headers.

To make the lit test print-header-json.c passed on a file-content-hash
file system.

Added: 


Modified: 
clang/test/Preprocessor/Inputs/print-header-json/header1.h
clang/test/Preprocessor/Inputs/print-header-json/header2.h
clang/test/Preprocessor/Inputs/print-header-json/system/system1.h
clang/test/Preprocessor/Inputs/print-header-json/system/system2.h
clang/test/Preprocessor/Inputs/print-header-json/system/system3.h

Removed: 




diff  --git a/clang/test/Preprocessor/Inputs/print-header-json/header1.h 
b/clang/test/Preprocessor/Inputs/print-header-json/header1.h
index e69de29bb2d1d..586f24a26b2e3 100644
--- a/clang/test/Preprocessor/Inputs/print-header-json/header1.h
+++ b/clang/test/Preprocessor/Inputs/print-header-json/header1.h
@@ -0,0 +1 @@
+// header1.h

diff  --git a/clang/test/Preprocessor/Inputs/print-header-json/header2.h 
b/clang/test/Preprocessor/Inputs/print-header-json/header2.h
index e69de29bb2d1d..46be4681fc24c 100644
--- a/clang/test/Preprocessor/Inputs/print-header-json/header2.h
+++ b/clang/test/Preprocessor/Inputs/print-header-json/header2.h
@@ -0,0 +1 @@
+// header2.h

diff  --git a/clang/test/Preprocessor/Inputs/print-header-json/system/system1.h 
b/clang/test/Preprocessor/Inputs/print-header-json/system/system1.h
index e69de29bb2d1d..b386f34e745a5 100644
--- a/clang/test/Preprocessor/Inputs/print-header-json/system/system1.h
+++ b/clang/test/Preprocessor/Inputs/print-header-json/system/system1.h
@@ -0,0 +1 @@
+// system1.h

diff  --git a/clang/test/Preprocessor/Inputs/print-header-json/system/system2.h 
b/clang/test/Preprocessor/Inputs/print-header-json/system/system2.h
index e69de29bb2d1d..7f3f7bf90ee6f 100644
--- a/clang/test/Preprocessor/Inputs/print-header-json/system/system2.h
+++ b/clang/test/Preprocessor/Inputs/print-header-json/system/system2.h
@@ -0,0 +1 @@
+// system2.h

diff  --git a/clang/test/Preprocessor/Inputs/print-header-json/system/system3.h 
b/clang/test/Preprocessor/Inputs/print-header-json/system/system3.h
index e69de29bb2d1d..1d83f7a531ee8 100644
--- a/clang/test/Preprocessor/Inputs/print-header-json/system/system3.h
+++ b/clang/test/Preprocessor/Inputs/print-header-json/system/system3.h
@@ -0,0 +1 @@
+// system3.h



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


[PATCH] D139450: Warn about unsupported ibmlongdouble

2022-12-08 Thread Qiu Chaofan via Phabricator via cfe-commits
qiucf added a comment.

Thanks for the patch! But does libc++ support to be built with 
`-mabi=ieeelongdouble` now? (like libstdc++, if it works correctly, it should 
co-exist and be linked with different long double ABIs)




Comment at: clang/lib/Driver/ToolChains/PPCLinux.cpp:96
   bool HasUnsupportedCXXLib =
-  StdLib == CST_Libcxx ||
+  (StdLib == CST_Libcxx && !defaultToIEEELongDouble()) ||
   (StdLib == CST_Libstdcxx &&

`SupportIEEEFloat128` checks the library version:

* If using libstdc++, then libstdc++ (GCC) >= 12.1.0 is okay.
* If using libc++, then sorry, no libc++ supports `-mabi=ieeelongdouble` now.
* Glibc should >= 2.32

If the assumptions are still right, this changes its meaning (and 
`supportIBMLongDouble` has different meaning from it).



Comment at: clang/test/Driver/lit.local.cfg:26
+if config.ppc_linux_default_ieeelongdouble == "ON":
+  config.available_features.add('ppc_linux_default_ieeelongdouble')

Can we assume if we are compiling with `-mabi=ieeelongdouble`, then libc++ 
'must' be built with the same long double ABI? If I understand correctly, 
they're unrelated.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139450

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


[PATCH] D139632: [clang-cl] Ignore #pragma managed / #pragma unmanaged

2022-12-08 Thread Sylvain Audi via Phabricator via cfe-commits
saudi created this revision.
saudi added reviewers: thakis, rnk, thieta.
saudi added a project: clang.
Herald added a project: All.
saudi requested review of this revision.
Herald added a subscriber: cfe-commits.

Those 2 pragmas are ignored by MSVC when not compiling with `/CLR`, which clang 
doesn't support.
Ignore them in clang `-fms-extensions`, to avoid `-Wunknown-pragma` warnings.

See 
https://learn.microsoft.com/en-us/cpp/preprocessor/managed-unmanaged?view=msvc-170


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D139632

Files:
  clang/lib/Lex/Pragma.cpp
  clang/test/Preprocessor/pragma_microsoft.c


Index: clang/test/Preprocessor/pragma_microsoft.c
===
--- clang/test/Preprocessor/pragma_microsoft.c
+++ clang/test/Preprocessor/pragma_microsoft.c
@@ -235,6 +235,12 @@
 #pragma optimize("", on) // expected-error {{'#pragma optimize' can only 
appear at file scope}}
 }
 
+#pragma managed// no-warning
+#pragma unmanaged  // no-warning
+#pragma managed(push, on)  // no-warning
+#pragma managed(pop)   // no-warning
+#pragma managed2   // expected-warning{{unknown pragma ignored}}
+
 #pragma execution_character_set // expected-warning {{expected 
'('}}
 #pragma execution_character_set(// expected-warning {{expected 
'push' or 'pop'}}
 #pragma execution_character_set()   // expected-warning {{expected 
'push' or 'pop'}}
Index: clang/lib/Lex/Pragma.cpp
===
--- clang/lib/Lex/Pragma.cpp
+++ clang/lib/Lex/Pragma.cpp
@@ -1957,6 +1957,15 @@
   }
 };
 
+/// "\#pragma managed"
+/// "\#pragma managed(...)"
+/// "\#pragma unmanaged"
+/// MSVC ignores this pragma when not compiling using /clr, which clang doesn't
+/// support. We parse it and ignore it to avoid -Wunknown-pragma warnings.
+struct PragmaManagedHandler : public EmptyPragmaHandler {
+  PragmaManagedHandler(const char *pragma) : EmptyPragmaHandler(pragma) {}
+};
+
 /// This handles parsing pragmas that take a macro name and optional message
 static IdentifierInfo *HandleMacroAnnotationPragma(Preprocessor , Token 
,
const char *Pragma,
@@ -2129,6 +2138,8 @@
 AddPragmaHandler(new PragmaIncludeAliasHandler());
 AddPragmaHandler(new PragmaHdrstopHandler());
 AddPragmaHandler(new PragmaSystemHeaderHandler());
+AddPragmaHandler(new PragmaManagedHandler("managed"));
+AddPragmaHandler(new PragmaManagedHandler("unmanaged"));
   }
 
   // Pragmas added by plugins


Index: clang/test/Preprocessor/pragma_microsoft.c
===
--- clang/test/Preprocessor/pragma_microsoft.c
+++ clang/test/Preprocessor/pragma_microsoft.c
@@ -235,6 +235,12 @@
 #pragma optimize("", on) // expected-error {{'#pragma optimize' can only appear at file scope}}
 }
 
+#pragma managed// no-warning
+#pragma unmanaged  // no-warning
+#pragma managed(push, on)  // no-warning
+#pragma managed(pop)   // no-warning
+#pragma managed2   // expected-warning{{unknown pragma ignored}}
+
 #pragma execution_character_set // expected-warning {{expected '('}}
 #pragma execution_character_set(// expected-warning {{expected 'push' or 'pop'}}
 #pragma execution_character_set()   // expected-warning {{expected 'push' or 'pop'}}
Index: clang/lib/Lex/Pragma.cpp
===
--- clang/lib/Lex/Pragma.cpp
+++ clang/lib/Lex/Pragma.cpp
@@ -1957,6 +1957,15 @@
   }
 };
 
+/// "\#pragma managed"
+/// "\#pragma managed(...)"
+/// "\#pragma unmanaged"
+/// MSVC ignores this pragma when not compiling using /clr, which clang doesn't
+/// support. We parse it and ignore it to avoid -Wunknown-pragma warnings.
+struct PragmaManagedHandler : public EmptyPragmaHandler {
+  PragmaManagedHandler(const char *pragma) : EmptyPragmaHandler(pragma) {}
+};
+
 /// This handles parsing pragmas that take a macro name and optional message
 static IdentifierInfo *HandleMacroAnnotationPragma(Preprocessor , Token ,
const char *Pragma,
@@ -2129,6 +2138,8 @@
 AddPragmaHandler(new PragmaIncludeAliasHandler());
 AddPragmaHandler(new PragmaHdrstopHandler());
 AddPragmaHandler(new PragmaSystemHeaderHandler());
+AddPragmaHandler(new PragmaManagedHandler("managed"));
+AddPragmaHandler(new PragmaManagedHandler("unmanaged"));
   }
 
   // Pragmas added by plugins
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D135269: [AMDGPU] Disable bool range metadata to workaround backend issue

2022-12-08 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl added a subscriber: jrbyrnes.
yaxunl added a comment.

In D135269#3981561 , @nikic wrote:

> Checking back here again on whether there is any progress on finding the root 
> cause of the issue. If no progress is expected in the near future, I'd ask 
> for this patch to be reverted.

@jrbyrnes is working on the root cause of this issue. Any updates? Thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135269

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


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

2022-12-08 Thread Matt Arsenault via Phabricator via cfe-commits
arsenm created this revision.
arsenm added reviewers: mibintc, john.brawn, kpn, jcranmer-intel, sepavloff, 
zahiraam.
Herald added a project: All.
arsenm requested review of this revision.
Herald added a subscriber: wdng.

The attribute is a proper enum attribute, strictfp. We were getting
strictfp and "strictfp" set on every function with
-fexperimental-strict-floating-point.


https://reviews.llvm.org/D139629

Files:
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/test/CodeGen/fp-floatcontrol-stack.cpp


Index: clang/test/CodeGen/fp-floatcontrol-stack.cpp
===
--- clang/test/CodeGen/fp-floatcontrol-stack.cpp
+++ clang/test/CodeGen/fp-floatcontrol-stack.cpp
@@ -284,3 +284,6 @@
 // CHECK-FAST: Function Attrs: noinline nounwind{{$$}}
 // CHECK-NOHONOR: Function Attrs: noinline nounwind{{$$}}
 // CHECK-LABEL: define{{.*}} @_GLOBAL__sub_I_fp_floatcontrol_stack
+
+// CHECK-DEBSTRICT: {{[ ]}}strictfp{{[ ]}}
+// CHECK-DEBSTRICT-NOT: "strictfp"
Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -2128,15 +2128,6 @@
   }
 }
 
-void CodeGenModule::setLLVMFunctionFEnvAttributes(const FunctionDecl *D,
-  llvm::Function *F) {
-  if (D->hasAttr()) {
-llvm::AttrBuilder FuncAttrs(F->getContext());
-FuncAttrs.addAttribute("strictfp");
-F->addFnAttrs(FuncAttrs);
-  }
-}
-
 void CodeGenModule::SetCommonAttributes(GlobalDecl GD, llvm::GlobalValue *GV) {
   const Decl *D = GD.getDecl();
   if (isa_and_nonnull(D))
@@ -5330,9 +5321,6 @@
 
   maybeSetTrivialComdat(*D, *Fn);
 
-  // Set CodeGen attributes that represent floating point environment.
-  setLLVMFunctionFEnvAttributes(D, Fn);
-
   CodeGenFunction(*this).GenerateCode(GD, Fn, FI);
 
   setNonAliasAttributes(GD, Fn);


Index: clang/test/CodeGen/fp-floatcontrol-stack.cpp
===
--- clang/test/CodeGen/fp-floatcontrol-stack.cpp
+++ clang/test/CodeGen/fp-floatcontrol-stack.cpp
@@ -284,3 +284,6 @@
 // CHECK-FAST: Function Attrs: noinline nounwind{{$$}}
 // CHECK-NOHONOR: Function Attrs: noinline nounwind{{$$}}
 // CHECK-LABEL: define{{.*}} @_GLOBAL__sub_I_fp_floatcontrol_stack
+
+// CHECK-DEBSTRICT: {{[ ]}}strictfp{{[ ]}}
+// CHECK-DEBSTRICT-NOT: "strictfp"
Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -2128,15 +2128,6 @@
   }
 }
 
-void CodeGenModule::setLLVMFunctionFEnvAttributes(const FunctionDecl *D,
-  llvm::Function *F) {
-  if (D->hasAttr()) {
-llvm::AttrBuilder FuncAttrs(F->getContext());
-FuncAttrs.addAttribute("strictfp");
-F->addFnAttrs(FuncAttrs);
-  }
-}
-
 void CodeGenModule::SetCommonAttributes(GlobalDecl GD, llvm::GlobalValue *GV) {
   const Decl *D = GD.getDecl();
   if (isa_and_nonnull(D))
@@ -5330,9 +5321,6 @@
 
   maybeSetTrivialComdat(*D, *Fn);
 
-  // Set CodeGen attributes that represent floating point environment.
-  setLLVMFunctionFEnvAttributes(D, Fn);
-
   CodeGenFunction(*this).GenerateCode(GD, Fn, FI);
 
   setNonAliasAttributes(GD, Fn);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D135360: [clang][analyzer] Add some more functions to StreamChecker and StdLibraryFunctionsChecker.

2022-12-08 Thread Kristóf Umann via Phabricator via cfe-commits
Szelethus added a comment.

In D135360#3862260 , @martong wrote:

> In D135360#3839890 , @balazske 
> wrote:
>
>> I found some anomalies during development:
>>
>> - If the checker **StdCLibraryFunctions** is added as dependency for 
>> **alpha.unix.Stream** in //checkers.td// I get some "unexplainable" test 
>> failures.
>
> Could you please elaborate? I don't see how to help you with it without 
> seeing more details.

Mind that dependencies also establish the order of callbacks (dependent 
checkers are called after their dependencies).

> When it is ambiguous then I'd check the latest standards of both POSIX and C. 
> If it is still doubtful then I'd vote for the C standard and would report a 
> defect towards the POSIX community.



In D135360#3888632 , @balazske wrote:

> About the "ftell" problem: The POSIX rules are really an extension of the C 
> standard rules. At `ftell` according to C standard `errno` should be set to a 
> positive value if error occurs. The POSIX rules extend this: `errno` is not 
> changed if no error occurs. [...] It may be best to use the POSIX rules for 
> the checker, because the C standard does not say much and may need to require 
> setting of `errno` to 0 before a standard function call.

Interesting pair of perspectives, I think a reasonable checker should be a 
little more conservative, more akin to what POSIX seems to specify.

In D135360#3885556 , @martong wrote:

> In D135360#3885494 , @balazske 
> wrote:
>
>> [...] Probably this should be a discourse question?
>
> Okay then, I think it is worth to have a discourse question. But you could 
> ask the wider "Clang" community, so I would not post the question as 
> something that is related strictly to the static analyzer.

Did this thread ever materialize? I admit I didn't follow :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135360

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


[PATCH] D135269: [AMDGPU] Disable bool range metadata to workaround backend issue

2022-12-08 Thread Nikita Popov via Phabricator via cfe-commits
nikic added a comment.

Checking back here again on whether there is any progress on finding the root 
cause of the issue. If no progress is expected in the near future, I'd ask for 
this patch to be reverted.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135269

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


[PATCH] D139627: clang/X86: Don't emit "min-legal-vector-width"="0"

2022-12-08 Thread Craig Topper via Phabricator via cfe-commits
craig.topper added a comment.

The attribute is supposed to tell the backend if there were any vectors used in 
the C source code and how big they were. A value of 0 means the code didn't 
contain any vectors.

The backend assumes lack of the attributes means the IR didn't come from clang 
and can't be trusted to have been audited. That's why the backend uses 
UINT32_MAX.

If the attribute is present and less than 512, avx512 is enabled, and we're 
targeting certain CPUs with a avx512 frequency penalty, the backend type 
legalizer in X86 will not have 512 bit vectors as legal types. This will cause 
any vectors larger than 512 to be split.  Such vectors were likely emitted by 
the loop or SLP vectorizer which isn't bound to the legal vector width.

If the C source used a 512 bit vector explicitly, either via target specific 
intrinsic, function argument or return, or inline assembly, etc. We need to 
have the backend treat the type as legal. If we don't do that, splitting the 
type could be incorrect. It could cause an ABI break across translation units. 
Or cause the backend legalizer to need to split something it isn't capable of 
splitting like a target specific intrinsic.

I admit the naming is unfortunate. I think I called the attribute 
min-legal-vector-width because it is the "minimum vector width the backend 
needs to consider legal", still subject to what subtarget features actually 
provide.

The clang code uses Max because it is calculated by maxing a bunch of things.


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

https://reviews.llvm.org/D139627

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


[PATCH] D139302: [RISCV] Add Syntacore SCR1 CPU model

2022-12-08 Thread Jessica Clarke via Phabricator via cfe-commits
jrtc27 added inline comments.



Comment at: llvm/include/llvm/Support/RISCVTargetParser.def:22
 PROC(SIFIVE_U74, {"sifive-u74"}, FK_64BIT, {"rv64gc"})
+PROC(SCR1_BASE, {"scr1-base"}, FK_NONE, {"rv32ic"})
+PROC(SCR1_MAX, {"scr1-max"}, FK_NONE, {"rv32imc"})

Alphabetise (with the exception of INVALID)?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139302

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


[PATCH] D133289: [C2X] N3007 Type inference for object definitions

2022-12-08 Thread Guillot Tony via Phabricator via cfe-commits
to268 updated this revision to Diff 481339.
to268 added a comment.

Removed compound literal diagnostic in ParseExpr


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133289

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/DeclSpec.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/C/C2x/n3007.c
  clang/test/CodeGen/auto.c
  clang/test/Parser/c2x-auto.c
  clang/test/Sema/c2x-auto.c
  clang/www/c_status.html

Index: clang/www/c_status.html
===
--- clang/www/c_status.html
+++ clang/www/c_status.html
@@ -1192,7 +1192,7 @@
 
   Type inference for object declarations
   https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3007.htm;>N3007
-  No
+  Clang 16
 
 
   constexpr for object definitions
Index: clang/test/Sema/c2x-auto.c
===
--- /dev/null
+++ clang/test/Sema/c2x-auto.c
@@ -0,0 +1,75 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c2x %s
+
+void test_basic_types(void) {
+  auto undefined; // expected-error {{declaration of variable 'undefined' with deduced type 'auto' requires an initializer}}
+  auto auto_int = 4;
+  auto auto_long = 4UL;
+}
+
+void test_sizeof_typeof(void) {
+  auto auto_size = sizeof(auto);  // expected-error {{expected expression}}
+  typeof(auto) tpof = 4;  // expected-error {{expected expression}}
+}
+
+void test_casts(void) {
+  auto int_cast = (int)(4 + 3);
+  auto double_cast = (double)(1 / 3);
+  auto long_cast = (long)(4UL + 3UL);
+  auto auto_cast = (auto)(4 + 3); // expected-error {{expected expression}}
+}
+
+void test_compound_literral(void) {
+  auto int_cl = (int){13};
+  auto double_cl = (double){2.5};
+  auto array[] = { 1, 2, 3 }; // expected-error {{'array' declared as array of 'auto'}}
+
+  // FIXME: This should be accepted per C2x 6.5.2.5p4
+  auto auto_cl = (auto){13};  // expected-error {{expected expression}}
+}
+
+void test_array_pointers(void) {
+  double array[3] = { 0 };
+  auto a = array;
+  auto b = 
+}
+
+void test_qualifiers(const int y) {
+  const auto a = 12;
+  auto b = y;
+  static auto c = 1UL;
+  int* pa =  // expected-warning {{initializing 'int *' with an expression of type 'const int *' discards qualifiers}}
+  const int* pb = 
+  int* pc =  // expected-warning {{incompatible pointer types initializing 'int *' with an expression of type 'unsigned long *'}}
+
+}
+
+void test_strings(void) {
+  auto str = "this is a string";
+  // FIXME: This should work for char*
+  auto str2[] = "this is a string"; // expected-error {{str2' declared as array of 'auto'}}
+  auto (str3) = "this is a string";
+  auto (((str4))) = "this is a string";
+}
+
+// FIXME: All these statements should fails (cannot declare a variable as a auto*)
+void test_pointers(void) {
+  auto a = 12;
+  auto *ptr =  // expected-error {{cannot declare 'ptr' as an explcit 'auto*' in C2x}}
+  auto *str = "this is a string"; // expected-error {{cannot declare 'str' as an explcit 'auto*' in C2x}}
+  const auto *str2 = "this is a string";  // expected-error {{cannot declare 'str2' as an explcit 'auto*' in C2x}}
+  auto *b =// expected-error {{cannot declare 'b' as an explcit 'auto*' in C2x}}
+  *b = 
+}
+
+void test_scopes(void) {
+  double a = 7;
+  double b = 9;
+  {
+auto a = a * a; // expected-error {{variable 'a' declared with deduced type 'auto' cannot appear in its own initializer}} \
+   expected-error {{variable 'a' declared with deduced type 'auto' cannot appear in its own initializer}}
+  }
+  {
+auto b = a * a;
+auto a = b;
+  }
+}
Index: clang/test/Parser/c2x-auto.c
===
--- /dev/null
+++ clang/test/Parser/c2x-auto.c
@@ -0,0 +1,123 @@
+// RUN: %clang_cc1 -fsyntax-only -verify=expected,c2x -std=c2x %s
+// RUN: %clang_cc1 -fsyntax-only -verify=expected,c17 -std=c17 %s
+
+#define AUTO_MACRO(_NAME, ARG, ARG2, ARG3) \
+  auto _NAME = ARG + (ARG2 / ARG3);
+
+struct S {
+int a;
+auto b;   // c2x-error {{'auto' not allowed in struct member}} \
+ c17-error {{type name does not allow storage class to be specified}} \
+ c17-error {{type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int}}
+union {
+  char c;
+  auto smth;  // c2x-error {{'auto' not allowed in union member}} \
+ c17-error {{type name does not allow storage class to be specified}} \
+ c17-error {{type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int}}
+} u;
+};
+
+enum E : auto { // c2x-error {{'auto' not allowed here}} \
+   c17-error {{expected a type}} \
+   c17-error {{type name 

[PATCH] D139544: [clang][dataflow] Add support for structured bindings of tuple-like types.

2022-12-08 Thread Yitzhak Mandelbaum via Phabricator via cfe-commits
ymandel added a comment.

Thanks for clarifying the issues here.  A few thoughts:

1. Thanks for clarifying about the blank lines. I was wondering how to read 
that and I think that fills in an important missing detail for me.

2. I'm particularly interested in the case of tuple-like containers, which is a 
little different (though I think the same point holds):

Example: https://godbolt.org/z/qcWMdG33T

  #include 
  std::tuple mk();
  
  void f() {
auto [b, i] = mk();
(void)i;
  }

CFG:

  void f()
   [B2 (ENTRY)]
 Succs (1): B1
  
   [B1]
 1: mk
 2: [B1.1] (ImplicitCastExpr, FunctionToPointerDecay, std::tuple<_Bool, 
int> (*)(void))
 3: [B1.2]() (CXXRecordTypedCall, [B1.4])
 4: auto = mk();
 5: get<0UL>
 6: [B1.5] (ImplicitCastExpr, FunctionToPointerDecay, typename 
tuple_element<0UL, tuple<_Bool, int> >::type &&(*)(tuple<_Bool, int> &&) 
noexcept)
 7: 
 8: [B1.7] (ImplicitCastExpr, NoOp, std::tuple<_Bool, int>)
 9: [B1.6]([B1.8])
10: std::tuple_element<0, std::tuple>::type b = get<0UL>();
11: get<1UL>
12: [B1.11] (ImplicitCastExpr, FunctionToPointerDecay, typename 
tuple_element<1UL, tuple<_Bool, int> >::type &&(*)(tuple<_Bool, int> &&) 
noexcept)
13: 
14: [B1.13] (ImplicitCastExpr, NoOp, std::tuple<_Bool, int>)
15: [B1.12]([B1.14])
16: std::tuple_element<1, std::tuple>::type i = get<1UL>();
17: i
18: (void)[B1.17] (CStyleCastExpr, ToVoid, void)
 Preds (1): B2
 Succs (1): B0
  
   [B0 (EXIT)]
 Preds (1): B1

Here, both lines 7 and 13 are blank but seem to be the underlying tuple that's 
being deconstructed.  Are these different instances of the DecompositionDecl or 
are they (unprinted) references back to line 4?

3. I'm still bothered that this seems to violate the design/philosophy of the 
CFG, which I take as ensuring that elements proceed in the order of operation. 
I see the problem here -- that the AST includes backedge, but can we solve it 
by adding another synthesized element for the object being deconstructed? Or, 
perhaps we could add new CFG kind that marks the appearance of the 
DecompositionDecl an extra time? That is, first time is so that the 
DecompositionDecl can be referenced as it is now, but second time is so that 
the statement can be evaluated in the proper order (after all of its 
constituent elements)?

Finally, a nit: why doesn't line 13 in your example, and lines 7 and 13 in my 
example, print? Is that something that I could add to the CFG printer?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139544

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


[PATCH] D139450: Warn about unsupported ibmlongdouble

2022-12-08 Thread Nikita Popov via Phabricator via cfe-commits
nikic added inline comments.



Comment at: clang/lib/Driver/ToolChains/PPCLinux.cpp:74
+const Driver ,
+const llvm::opt::ArgList ) const {
+  if (Args.hasArg(options::OPT_nostdlib, options::OPT_nostdlibxx))

I don't think this formatting is right. You may find 
clang/tools/clang-format/clang-format-diff.py helpful.

I use this script locally:
```
#!/bin/sh
git diff -U ${1:-HEAD} | clang/tools/clang-format/clang-format-diff.py -p1
```
And then do something like `./clang_format_diff.sh | patch -p0` after checking 
that it did not reformat too much.



Comment at: clang/test/Driver/lit.local.cfg:25
+
+if config.ppc_linux_default_ieeelongdouble == "ON":
+  config.available_features.add('ppc_linux_default_ieeelongdouble')

I believe this isn't robust, because ON is not the only possible value. 
Instead, you'll want to canonicalize the variable: 
https://github.com/llvm/llvm-project/blob/03e6d9d9d1d48e43f3efc35eb75369b90d4510d5/clang/test/CMakeLists.txt#L4


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139450

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


[PATCH] D112932: [WIP] Use llvm.is_fpclass to implement FP classification functions

2022-12-08 Thread Qiu Chaofan via Phabricator via cfe-commits
qiucf added a comment.
Herald added a project: All.

This patch looks good and `llvm.is.fpclass` will by default be expanded (except 
SystemZ which has their own lowering). Is there any blocker for this?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112932

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


[PATCH] D139544: [clang][dataflow] Add support for structured bindings of tuple-like types.

2022-12-08 Thread Yitzhak Mandelbaum via Phabricator via cfe-commits
ymandel added a comment.

Gabor -- An alternative solution to this problem, assuming the current 
structure of the CFG, is to add a map to the `Environment` of type `VarDecl` -> 
`BindingDecl` that registers `BindingDecl`s in need of initialization. Then, I 
could modify the `DeclStmt` interpretation to check this map for each VarDecl 
it processes, processing the corresponding BindingDecl if there is one.  This 
solution, while a bit more complicated, has the mild advantage of incurring 
less cost (on average) since VarDecls are less common than DeclRefExpr. Also, 
it's eager instead of lazy, which seems somewhat easier to reason about.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139544

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


[PATCH] D139400: [clang] Show error when a local variables is passed as default template parameter

2022-12-08 Thread Jens Massberg via Phabricator via cfe-commits
massberg updated this revision to Diff 481295.
massberg added a comment.

Reuse existing error message.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139400

Files:
  clang/lib/Sema/SemaTemplate.cpp
  clang/test/SemaTemplate/default-template-arguments.cpp


Index: clang/test/SemaTemplate/default-template-arguments.cpp
===
--- /dev/null
+++ clang/test/SemaTemplate/default-template-arguments.cpp
@@ -0,0 +1,14 @@
+// RUN: %clang_cc1 -fsyntax-only -std=c++20 -verify %s
+
+namespace GH48755 {
+constexpr auto z = 2;
+
+auto f() {
+  const auto x = 1;
+
+  auto lambda1 = []  {}; // expected-error {{default argument 
references local variable x of enclosing function}}
+  auto lambda2 = []  {};
+  auto lambda3 = []  {};
+  auto lambda4 = []  {};
+}
+}
Index: clang/lib/Sema/SemaTemplate.cpp
===
--- clang/lib/Sema/SemaTemplate.cpp
+++ clang/lib/Sema/SemaTemplate.cpp
@@ -8,6 +8,7 @@
 //  This file implements semantic analysis for C++ templates.
 
//===--===//
 
+#include  // massberg
 #include "TreeTransform.h"
 #include "clang/AST/ASTConsumer.h"
 #include "clang/AST/ASTContext.h"
@@ -1587,6 +1588,17 @@
 
   // Check the well-formedness of the default template argument, if provided.
   if (Default) {
+// Local variables may not be used as default template arguments.
+if (auto *DRE = dyn_cast(Default)) {
+  if (VarDecl *VD = dyn_cast(DRE->getDecl())) {
+if (VD->isLocalVarDecl()) {
+  Diag(DRE->getLocation(),
+   diag::err_param_default_argument_references_local)
+  << VD->getNameAsString();
+}
+  }
+}
+
 // Check for unexpanded parameter packs.
 if (DiagnoseUnexpandedParameterPack(Default, UPPC_DefaultArgument))
   return Param;


Index: clang/test/SemaTemplate/default-template-arguments.cpp
===
--- /dev/null
+++ clang/test/SemaTemplate/default-template-arguments.cpp
@@ -0,0 +1,14 @@
+// RUN: %clang_cc1 -fsyntax-only -std=c++20 -verify %s
+
+namespace GH48755 {
+constexpr auto z = 2;
+
+auto f() {
+  const auto x = 1;
+
+  auto lambda1 = []  {}; // expected-error {{default argument references local variable x of enclosing function}}
+  auto lambda2 = []  {};
+  auto lambda3 = []  {};
+  auto lambda4 = []  {};
+}
+}
Index: clang/lib/Sema/SemaTemplate.cpp
===
--- clang/lib/Sema/SemaTemplate.cpp
+++ clang/lib/Sema/SemaTemplate.cpp
@@ -8,6 +8,7 @@
 //  This file implements semantic analysis for C++ templates.
 //===--===//
 
+#include  // massberg
 #include "TreeTransform.h"
 #include "clang/AST/ASTConsumer.h"
 #include "clang/AST/ASTContext.h"
@@ -1587,6 +1588,17 @@
 
   // Check the well-formedness of the default template argument, if provided.
   if (Default) {
+// Local variables may not be used as default template arguments.
+if (auto *DRE = dyn_cast(Default)) {
+  if (VarDecl *VD = dyn_cast(DRE->getDecl())) {
+if (VD->isLocalVarDecl()) {
+  Diag(DRE->getLocation(),
+   diag::err_param_default_argument_references_local)
+  << VD->getNameAsString();
+}
+  }
+}
+
 // Check for unexpanded parameter packs.
 if (DiagnoseUnexpandedParameterPack(Default, UPPC_DefaultArgument))
   return Param;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D139640: clang: Add __builtin_elementwise canonicalize and copysign

2022-12-08 Thread Matt Arsenault via Phabricator via cfe-commits
arsenm created this revision.
arsenm added reviewers: fhahn, scanon.
Herald added a project: All.
arsenm requested review of this revision.
Herald added a subscriber: wdng.

Just copy paste from the other functions. I also need fma, but
the current code seems to assume 1 or 2 arguments.


https://reviews.llvm.org/D139640

Files:
  clang/docs/LanguageExtensions.rst
  clang/include/clang/Basic/Builtins.def
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/builtins-elementwise-math.c
  clang/test/Sema/builtins-elementwise-math.c

Index: clang/test/Sema/builtins-elementwise-math.c
===
--- clang/test/Sema/builtins-elementwise-math.c
+++ clang/test/Sema/builtins-elementwise-math.c
@@ -384,3 +384,79 @@
   uv = __builtin_elementwise_trunc(uv);
   // expected-error@-1 {{1st argument must be a floating point type (was 'unsigned4' (vector of 4 'unsigned int' values))}}
 }
+
+void test_builtin_elementwise_canonicalize(int i, float f, double d, float4 v, int3 iv, unsigned u, unsigned4 uv) {
+
+  struct Foo s = __builtin_elementwise_canonicalize(f);
+  // expected-error@-1 {{initializing 'struct Foo' with an expression of incompatible type 'float'}}
+
+  i = __builtin_elementwise_canonicalize();
+  // expected-error@-1 {{too few arguments to function call, expected 1, have 0}}
+
+  i = __builtin_elementwise_canonicalize(i);
+  // expected-error@-1 {{1st argument must be a floating point type (was 'int')}}
+
+  i = __builtin_elementwise_canonicalize(f, f);
+  // expected-error@-1 {{too many arguments to function call, expected 1, have 2}}
+
+  u = __builtin_elementwise_canonicalize(u);
+  // expected-error@-1 {{1st argument must be a floating point type (was 'unsigned int')}}
+
+  uv = __builtin_elementwise_canonicalize(uv);
+  // expected-error@-1 {{1st argument must be a floating point type (was 'unsigned4' (vector of 4 'unsigned int' values))}}
+}
+
+void test_builtin_elementwise_copysign(int i, short s, double d, float4 v, int3 iv, unsigned3 uv, int *p) {
+  i = __builtin_elementwise_copysign(p, d);
+  // expected-error@-1 {{arguments are of different types ('int *' vs 'double')}}
+
+  struct Foo foo = __builtin_elementwise_copysign(i, i);
+  // expected-error@-1 {{initializing 'struct Foo' with an expression of incompatible type 'int'}}
+
+  i = __builtin_elementwise_copysign(i);
+  // expected-error@-1 {{too few arguments to function call, expected 2, have 1}}
+
+  i = __builtin_elementwise_copysign();
+  // expected-error@-1 {{too few arguments to function call, expected 2, have 0}}
+
+  i = __builtin_elementwise_copysign(i, i, i);
+  // expected-error@-1 {{too many arguments to function call, expected 2, have 3}}
+
+  i = __builtin_elementwise_copysign(v, iv);
+  // expected-error@-1 {{arguments are of different types ('float4' (vector of 4 'float' values) vs 'int3' (vector of 3 'int' values))}}
+
+  i = __builtin_elementwise_copysign(uv, iv);
+  // expected-error@-1 {{arguments are of different types ('unsigned3' (vector of 3 'unsigned int' values) vs 'int3' (vector of 3 'int' values))}}
+
+  s = __builtin_elementwise_copysign(i, s);
+
+  enum e { one,
+   two };
+  i = __builtin_elementwise_copysign(one, two);
+
+  enum f { three };
+  enum f x = __builtin_elementwise_copysign(one, three);
+
+  _BitInt(32) ext; // expected-warning {{'_BitInt' in C17 and earlier is a Clang extension}}
+  ext = __builtin_elementwise_copysign(ext, ext);
+
+  const int ci;
+  i = __builtin_elementwise_copysign(ci, i);
+  i = __builtin_elementwise_copysign(i, ci);
+  i = __builtin_elementwise_copysign(ci, ci);
+
+  i = __builtin_elementwise_copysign(i, int_as_one); // ok (attributes don't match)?
+  i = __builtin_elementwise_copysign(i, b);  // ok (sugar doesn't match)?
+
+  int A[10];
+  A = __builtin_elementwise_copysign(A, A);
+  // expected-error@-1 {{1st argument must be a vector, integer or floating point type (was 'int *')}}
+
+  int(ii);
+  int j;
+  j = __builtin_elementwise_copysign(i, j);
+
+  _Complex float c1, c2;
+  c1 = __builtin_elementwise_copysign(c1, c2);
+  // expected-error@-1 {{1st argument must be a vector, integer or floating point type (was '_Complex float')}}
+}
Index: clang/test/CodeGen/builtins-elementwise-math.c
===
--- clang/test/CodeGen/builtins-elementwise-math.c
+++ clang/test/CodeGen/builtins-elementwise-math.c
@@ -3,6 +3,8 @@
 typedef float float4 __attribute__((ext_vector_type(4)));
 typedef short int si8 __attribute__((ext_vector_type(8)));
 typedef unsigned int u4 __attribute__((ext_vector_type(4)));
+typedef double double2 __attribute__((ext_vector_type(2)));
+typedef double double3 __attribute__((ext_vector_type(3)));
 
 __attribute__((address_space(1))) int int_as_one;
 typedef int bar;
@@ -412,3 +414,53 @@
   // CHECK-NEXT: call <4 x float> @llvm.trunc.v4f32(<4 x float> [[VF1]])
   vf2 = 

[PATCH] D139400: [clang] Show error when a local variables is passed as default template parameter

2022-12-08 Thread Jens Massberg via Phabricator via cfe-commits
massberg added a comment.

In D139400#3974624 , @shafik wrote:

> It looks like we have an existing message for the regular function case

Thanks! We can indeed reuse this error message.

In D139400#3974654 , @shafik wrote:

> It looks like the existing diagnostic is issued by 
> `CheckDefaultArgumentVisitor`. I think you can reuse it here but not 100% on 
> that.

Thanks for the pointer! `CheckDefaultArgumentVisitor` is for default arguments 
of functions. As it does many additional checks we cannot reuse it for testing 
default  arguments of templates.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139400

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


[PATCH] D139052: [NFC][Profile] Access profile through VirtualFileSystem

2022-12-08 Thread Steven Wu via Phabricator via cfe-commits
steven_wu added inline comments.



Comment at: clang/lib/Frontend/CompilerInvocation.cpp:1729
+  if (!Opts.ProfileInstrumentUsePath.empty()) {
+auto FS = llvm::vfs::getRealFileSystem();
+setPGOUseInstrumentor(Opts, Opts.ProfileInstrumentUsePath, *FS, Diags);

akyrtzi wrote:
> steven_wu wrote:
> > akyrtzi wrote:
> > > Could we propagate the VFS that the `CompilerInvocation` is going to 
> > > create here? Otherwise this seems like a hidden "landmine" that someone 
> > > is bound to trip on later on.
> > Currently, Profile look up doesn't go through any VFS, so vfs overlay has 
> > no effect on profiles. Putting through VFS is changing behavior, even I 
> > think it is for good.
> > 
> > It also has the potential to make code harder to read because creating VFS 
> > relies on a compiler invocation which we are creating here.
> > 
> > Let me add a fixme here first. 
> > Currently, Profile look up doesn't go through any VFS, so vfs overlay has 
> > no effect on profiles. Putting through VFS is changing behavior, even I 
> > think it is for good.
> 
> Your patch is already changing behavior; CodeGen will load profiles using 
> clang's VFS, so vfs overlay will affect how profiles are loaded. The mismatch 
> is that CodeGen will load the path using clang's VFS but 
> `setPGOUseInstrumentor` will load it directly from real file-system, so they 
> can be out-of-sync.
> 
> On second look, `setPGOUseInstrumentor` seems to create a throw-away 
> `IndexedInstrProfReader` just for reading a couple of settings to set some 
> flags. This seems redundant, could we move the determination of these flags 
> at the point where `CodeGenModule` is creating its own 
> `IndexedInstrProfReader` and remove `setPGOUseInstrumentor` from 
> `CompilerInvocation::ParseCodeGenArgs` entirely?
I will take a look. The current implementation is not very good as it just read 
it to determine the type of the profile to set the action. I agree the 
disconnect between two reads is bad.



Comment at: llvm/include/llvm/Support/PGOOptions.h:18
 #include "llvm/Support/Error.h"
+#include "llvm/Support/VirtualFileSystem.h"
 

akyrtzi wrote:
> akyrtzi wrote:
> > I'd suggest to consider moving the `PGOOptions` constructor out-of-line, 
> > along with
> > ```
> >   PGOOptions =(const PGOOptions );
> >   PGOOptions(const PGOOptions&);
> >   ~PGOOptions();
> > ```
> >  in order to forward-declare here and avoid including the header, avoiding 
> > the additional include dependencies for many cpp files.
> > The default parameter needs to instantiate here and pretty much all 
> > references to `PGOOptions` has `Optional` which requires 
> > including VFS. I will leave this one since `PGOOptions.h` is a rare header 
> > to include.
> 
> `PGOOptions.h` is transitively included by many files, if I touch that 
> header, and then compile `clang`, there are 225 files that need to be 
> re-compiled.
> 
> I thought that moving the `PGOOptions` members I mentioned out-of-line would 
> be enough to avoid the need to include `VirtualFileSystem.h`, is this not the 
> case?
I see. It is included in two different headers in the backend, both of them has 
`Optional`. During my experiment, to instantiate 
`Optional`, it needs full declaration for PGOOptions, thus 
FileSystem. I could be wrong but I don't see a way around that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139052

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


[PATCH] D137107: Allow MS extension: support of constexpr with __declspec(dllimport).

2022-12-08 Thread Eli Friedman via Phabricator via cfe-commits
efriedma added inline comments.



Comment at: clang/lib/CodeGen/CGDeclCXX.cpp:572
 PrioritizedCXXGlobalInits.push_back(std::make_pair(Key, Fn));
+  } else if (D->hasConstantInitialization() && !(D->hasAttr())) 
{
+OrderGlobalInitsOrStermFinalizers Key(201,

zahiraam wrote:
> efriedma wrote:
> > zahiraam wrote:
> > > efriedma wrote:
> > > > zahiraam wrote:
> > > > > efriedma wrote:
> > > > > > zahiraam wrote:
> > > > > > > efriedma wrote:
> > > > > > > > How is ConstInitAttr relevant here?
> > > > > > > This change made (without the !(D->hasAttr()) made 
> > > > > > > the LIT behavior of aix-static-init.cpp. The IR generated for 
> > > > > > > namespace test3 {
> > > > > > >   struct Test3 {
> > > > > > > constexpr Test3() {};
> > > > > > > ~Test3() {};
> > > > > > >   };
> > > > > > > 
> > > > > > >   constinit Test3 t;
> > > > > > > } // namespace test3
> > > > > > > 
> > > > > > > was different. I would have thought that the change we made for 
> > > > > > > constexpr wouldn't affter constinit? 
> > > > > > I think the significant bit there isn't the use of constinit; it's 
> > > > > > the non-trivial destructor.  I think the priority modification 
> > > > > > should only affect constructors, not destructors.  (Not sure how to 
> > > > > > make that work, at first glance.)
> > > > > Let's see if this is an acceptable solution.
> > > > To fake constant initialization, we need to initialize the variable 
> > > > before anything else runs.  But the rearranged prioritization isn't 
> > > > supposed to affect the destructor.  From [basic.start.term]: "If an 
> > > > object is initialized statically, the object is destroyed in the same 
> > > > order as if the object was dynamically initialized."
> > > > 
> > > > What you're doing here isn't exactly implementing that.  What you're 
> > > > doing here is delaying both the initialization and the destruction if 
> > > > the variable has a non-trivial destructor.  We need to separate the two 
> > > > to get the behavior we want.
> > > Could we consider adding a field to EvaluatedStmt called 
> > > "HasTrivialDestrutor" and only perform the prioritization change when 
> > > !D->HasTrivialDesctructor?  Instead of using the test for 
> > > D->hasConstantInitialization(). This seems to be englobing to many cases.
> > > 
> > > I considered returning null for HasConstantInitialization in case of var 
> > > has a non-trivial destructor but that doesn't seem to work.
> > Once you separate out the initialization from the destruction, the rest 
> > should come together naturally, I think? I'm not sure what other cases 
> > could be caught by hasConstantInitialization().
> Does this change accomplish this? Thanks.
When a global variable is dynamically initialized, there are two parts to the 
initialization:

- Constructing the variable (calling the constructor, or equivalent)
- Registering the destructor with the runtime (atexit on Windows)

If an object is initialized statically, the two parts are separated: the 
variable is emitted already initialized by the compiler.  But we still register 
the destructor at the same time, in the same way.

If a dllimport object is initialized statically, we need to make it appear to 
user code that the same thing happened.  So we need to initialize the object 
early, but we need to register the destructor at the same time we would have 
otherwise registered it.  To make this work, we need two separate initializer 
functions with different priorities.


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

https://reviews.llvm.org/D137107

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


[PATCH] D139653: [clang] Set ShowInSystemHeader for module-build and module-import remarks

2022-12-08 Thread Dave Lee via Phabricator via cfe-commits
kastiglione added a comment.

> Also, do you think this should be configurable on the command line?

Do you have a flag in mind? I have worked around the current behavior with 
`-Wno-system-header`, but there are two problems with that: first, it's not 
obvious that it's needed (I had to debug clang to figure out why diagnostics 
were missing, most people wouldn't do that), and second it can result in many 
many warnings, which – if you are only interested in module remarks, represents 
a bunch of noise.

> I'm thinking about users that are trying to debug their own modular code, but 
> don't really care what happens in the SDK.

My first question is how many of those users are there? It seems to me that the 
module remarks are more for tooling developers than end users. Speaking as 
someone working on tools, I think I would always want all module-build remarks, 
since – correct me if I'm wrong – they're relevant only to performance, and for 
performance I want to see all the builds.

For module-import remarks, I could see it being more interesting to developers, 
but I don't know how many developers know about and use `-Rmodule-import`. If 
we want to proactively support those users, maybe the solution is two flags, 
say `-Rmodule-import` and `-Rmodule-import-all` (I can't think of a better 
spelling).

For relevant comparisons, the only thing I can think about is the `-H` flag, 
which shows all header includes, it does not exclude system headers. Speaking 
of which, an equivalent for modules might be helpful.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139653

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


[PATCH] D139627: clang/X86: Don't emit "min-legal-vector-width"="0"

2022-12-08 Thread Matt Arsenault via Phabricator via cfe-commits
arsenm added a comment.

In D139627#3982385 , @arsenm wrote:

>> [1] `"min-legal-vector-width" = "0"` was clear to indicate there are only 
>> scalar operations.
>
> It's not remotely clear what this means

It also doesn't mean that, because the IR doesn't have to be consistent with 
the attribute. The IR exists independent of the attribute, and the attribute 
can only provide performance hints.


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

https://reviews.llvm.org/D139627

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


[PATCH] D139608: [Clang][NFC] Add default `getBFloat16Mangling` impl

2022-12-08 Thread Joshua Cranmer via Phabricator via cfe-commits
jcranmer-intel added a comment.

I don't normally handle name mangling, so I can't comment too much here, but I 
will note that Itanium ABI is planning on using DF16b for `std::bfloat16_t`: 
https://github.com/itanium-cxx-abi/cxx-abi/pull/147


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139608

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


[PATCH] D139544: [clang][dataflow] Add support for structured bindings of tuple-like types.

2022-12-08 Thread Yitzhak Mandelbaum via Phabricator via cfe-commits
ymandel added a comment.

Domján -- thanks for the detailed explanations -- this has been really helpful.

> After this the get<>() calls simply use this unnamed copy to initialize the 
> elements from first to last, so everything seems to proceed in order in the 
> CFG.

Agreed -- it definitely should appear before, but I think it would be good to 
appear _after_ as well. That is, I think there's a catch-22: the temporary's 
construction should appear before, but the binding decls, which use the 
synthetic variables, should appear after.

What do you think of duplicating it in the CFG, possibly with a new (statement) 
element kind (to mark it as a special)?  There are other workarounds that we 
could do on our end, but the duplication would avoid the need for such -- for 
us and any other clients.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139544

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


[PATCH] D136554: Implement CWG2631

2022-12-08 Thread Corentin Jabot via Phabricator via cfe-commits
cor3ntin reopened this revision.
cor3ntin added a comment.
This revision is now accepted and ready to land.

In D136554#3982161 , @aeubanks wrote:

> the following now produces a link error:
>
>   $ cat /tmp/a.cc
>   #include 
>   #include 
>   
>   struct S {
>   std::map a;
>   };
>   
>   using T = std::array;
>   
>   class C {
>   T t{};
>   };
>   
>   int main() {
>   C c;
>   }
>   $ ./build/rel/bin/clang++ -o /dev/null /tmp/a.cc -stdlib=libc++ -fuse-ld=lld
>   ld.lld: error: undefined hidden symbol: std::__2::map std::__2::less, std::__2::allocator int>>>::map[abi:v16]()
>   >>> referenced by a.cc
>   >>>   /tmp/a-042a0e.o:(C::C())
>   clang: error: linker command failed with exit code 1 (use -v to see 
> invocation)
>
> using a ToT libc++
>
> is this expected?




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136554

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


[PATCH] D136554: Implement CWG2631

2022-12-08 Thread Corentin Jabot via Phabricator via cfe-commits
cor3ntin updated this revision to Diff 481411.
cor3ntin added a comment.

Correctly visit array filer when marking 
default member init as ODR-used


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136554

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/AST/ExprCXX.h
  clang/include/clang/AST/Stmt.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/ASTImporter.cpp
  clang/lib/AST/Decl.cpp
  clang/lib/AST/ExprCXX.cpp
  clang/lib/Parse/ParseCXXInlineMethods.cpp
  clang/lib/Parse/ParseDeclCXX.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaTemplateInstantiate.cpp
  clang/lib/Sema/TreeTransform.h
  clang/lib/Sema/UsedDeclVisitor.h
  clang/lib/Serialization/ASTReaderStmt.cpp
  clang/lib/Serialization/ASTWriterStmt.cpp
  clang/test/CXX/class/class.local/p1-0x.cpp
  clang/test/CXX/drs/dr26xx.cpp
  clang/test/CodeGenCXX/builtin-source-location.cpp
  clang/test/CodeGenCXX/default-arguments-with-immediate.cpp
  clang/test/CodeGenCXX/meminit-initializers-odr.cpp
  clang/test/PCH/default-argument-with-immediate-calls.cpp
  clang/test/SemaCXX/cxx11-default-member-initializers.cpp
  clang/test/SemaCXX/cxx2a-consteval-default-params.cpp
  clang/test/SemaCXX/source_location.cpp
  clang/www/cxx_dr_status.html

Index: clang/www/cxx_dr_status.html
===
--- clang/www/cxx_dr_status.html
+++ clang/www/cxx_dr_status.html
@@ -15593,7 +15593,7 @@
 https://wg21.link/cwg2631;>2631
 DR
 Immediate function evaluations in default arguments
-Unknown
+Clang 16
   
   
 https://wg21.link/cwg2632;>2632
Index: clang/test/SemaCXX/source_location.cpp
===
--- clang/test/SemaCXX/source_location.cpp
+++ clang/test/SemaCXX/source_location.cpp
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 -std=c++1z -fcxx-exceptions -fexceptions -verify %s
+// RUN: %clang_cc1 -std=c++2a -fcxx-exceptions -DUSE_CONSTEVAL -fexceptions -verify %s
 // expected-no-diagnostics
 
 #define assert(...) ((__VA_ARGS__) ? ((void)0) : throw 42)
@@ -8,15 +9,22 @@
 template 
 struct Printer;
 
+#ifdef USE_CONSTEVAL
+#define SOURCE_LOC_EVAL_KIND consteval
+#else
+#define SOURCE_LOC_EVAL_KIND constexpr
+#endif
+
 namespace std {
 class source_location {
   struct __impl;
 
 public:
-  static constexpr source_location current(const __impl *__p = __builtin_source_location()) noexcept {
-source_location __loc;
-__loc.__m_impl = __p;
-return __loc;
+  static SOURCE_LOC_EVAL_KIND source_location
+current(const __impl *__p = __builtin_source_location()) noexcept {
+  source_location __loc;
+  __loc.__m_impl = __p;
+  return __loc;
   }
   constexpr source_location() = default;
   constexpr source_location(source_location const &) = default;
@@ -593,3 +601,51 @@
   }
   static_assert(test());
 }
+
+namespace Lambda {
+#line 8000 "TestLambda.cpp"
+constexpr int nested_lambda(int l = []{
+  return SL::current().line();
+}()) {
+  return l;
+}
+static_assert(nested_lambda() == __LINE__ - 4);
+
+constexpr int lambda_param(int l = [](int l = SL::current().line()) {
+  return l;
+}()) {
+  return l;
+}
+static_assert(lambda_param() == __LINE__);
+
+
+}
+
+constexpr int compound_literal_fun(int a =
+  (int){ SL::current().line() }
+) { return a ;}
+static_assert(compound_literal_fun() == __LINE__);
+
+struct CompoundLiteral {
+  int a = (int){ SL::current().line() };
+};
+static_assert(CompoundLiteral{}.a == __LINE__);
+
+
+// FIXME
+// Init captures are subexpressions of the lambda expression
+// so according to the standard immediate invocations in init captures
+// should be evaluated at the call site.
+// However Clang does not yet implement this as it would introduce
+// a fair bit of complexity.
+// We intend to implement that functionality once we find real world
+// use cases that require it.
+constexpr int test_init_capture(int a =
+[b = SL::current().line()] { return b; }()) {
+  return a;
+}
+#ifdef USE_CONSTEVAL
+static_assert(test_init_capture() == __LINE__ - 4);
+#else
+static_assert(test_init_capture() == __LINE__ );
+#endif
Index: clang/test/SemaCXX/cxx2a-consteval-default-params.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/cxx2a-consteval-default-params.cpp
@@ -0,0 +1,81 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c++20 %s
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c++2b %s
+
+consteval int undefined();  // expected-note 4 {{declared here}}
+
+void check_lambdas_unused(
+int a = []
+{
+// The body of a lambda is not a subexpression of the lambda
+// so this is immediately evaluated even if the parameter
+// is never used.
+return undefined();  // expected-error {{not a constant 

[PATCH] D139444: [ZOS] Convert tests to check 'target={{.*}}-zos'

2022-12-08 Thread Paul Robinson via Phabricator via cfe-commits
probinson updated this revision to Diff 481421.
probinson added a comment.

Add trailing '{{.*}}' as requested.
Have not changed the encoding.ll test, waiting on @uweigand about correct value 
to test in Python.


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

https://reviews.llvm.org/D139444

Files:
  clang/test/Analysis/cfref_PR2519.c
  clang/test/CodeGen/cfstring2.c
  clang/test/Driver/as-version.s
  clang/test/Import/forward-declared-objc-class/test.m
  clang/test/Import/objc-arc/test-cleanup-object.m
  clang/test/Import/objc-autoreleasepool/test.m
  clang/test/Import/objc-definitions-in-expression/test.m
  clang/test/Import/objc-method/test.m
  clang/test/Import/objc-param-decl/test.m
  clang/test/Import/objc-try-catch/test.m
  clang/test/Modules/DebugInfoNamespace.cpp
  clang/test/Modules/DebugInfoTransitiveImport.m
  clang/test/Modules/ExtDebugInfo.cpp
  clang/test/Modules/ExtDebugInfo.m
  clang/test/Modules/ModuleDebugInfo.cpp
  clang/test/Modules/ModuleDebugInfo.m
  clang/test/Modules/ModuleDebugInfoDwoId.cpp
  clang/test/Modules/ModuleModuleDebugInfo.cpp
  clang/test/Modules/autolink.m
  clang/test/Modules/autolinkTBD.m
  clang/test/Modules/builtins.m
  clang/test/Modules/clang_module_file_info.m
  clang/test/Modules/cxx-irgen.cpp
  clang/test/Modules/debug-info-moduleimport-in-module.m
  clang/test/Modules/debug-info-moduleimport.m
  clang/test/Modules/direct-module-import.m
  clang/test/Modules/merge-anon-record-definition-in-objc.m
  clang/test/Modules/merge-extension-ivars.m
  clang/test/Modules/merge-objc-interface-visibility.m
  clang/test/Modules/merge-objc-interface.m
  clang/test/Modules/merge-record-definition-nonmodular.m
  clang/test/Modules/merge-record-definition-visibility.m
  clang/test/Modules/merge-record-definition.m
  clang/test/Modules/module-debuginfo-prefix.m
  clang/test/Modules/module-file-home-is-cwd.m
  clang/test/Modules/module_file_info.m
  clang/test/Modules/objc-initializer.m
  clang/test/Modules/pch-used.m
  clang/test/Modules/redecl-ivars.m
  clang/test/Modules/use-exportas-for-link.m
  clang/test/PCH/externally-retained.m
  clang/test/PCH/irgen-rdar13114142.mm
  clang/test/PCH/objc_container.m
  clang/test/PCH/objc_literals.m
  clang/test/PCH/objc_literals.mm
  clang/test/PCH/objcxx-ivar-class.mm
  clang/test/PCH/pending-ids.m
  llvm/test/MC/AsmParser/debug-no-source.s
  llvm/test/Support/encoding.ll
  llvm/test/tools/llvm-mc/no_warnings.test

Index: llvm/test/tools/llvm-mc/no_warnings.test
===
--- llvm/test/tools/llvm-mc/no_warnings.test
+++ llvm/test/tools/llvm-mc/no_warnings.test
@@ -1,4 +1,4 @@
-# UNSUPPORTED: -zos
+# UNSUPPORTED: target={{.*}}-zos{{.*}}
 # RUN: llvm-mc --no-warn %s 2>&1 | FileCheck %s
 
 # CHECK-NOT: warning:
Index: llvm/test/Support/encoding.ll
===
--- llvm/test/Support/encoding.ll
+++ llvm/test/Support/encoding.ll
@@ -1,7 +1,7 @@
 ; Checks if llc can deal with different char encodings.
 ; This is only required for z/OS.
 ;
-; UNSUPPORTED: !s390x-none-zos
+; REQUIRES: target=s390x-none-zos
 ;
 ; RUN: cat %s >%t && chtag -tc ISO8859-1 %t && llc %t -o - >/dev/null
 ; RUN: iconv -f ISO8859-1 -t IBM-1047 <%s >%t && chtag -tc IBM-1047 %t && llc %t -o - >/dev/null
Index: llvm/test/MC/AsmParser/debug-no-source.s
===
--- llvm/test/MC/AsmParser/debug-no-source.s
+++ llvm/test/MC/AsmParser/debug-no-source.s
@@ -1,4 +1,4 @@
-// UNSUPPORTED: -zos
+// UNSUPPORTED: target={{.*}}-zos{{.*}}
 // REQUIRES: object-emission
 // RUN: llvm-mc %s | FileCheck %s
 
Index: clang/test/PCH/pending-ids.m
===
--- clang/test/PCH/pending-ids.m
+++ clang/test/PCH/pending-ids.m
@@ -1,4 +1,4 @@
-// UNSUPPORTED: -zos, target={{.*}}-aix{{.*}}
+// UNSUPPORTED: target={{.*}}-zos{{.*}}, target={{.*}}-aix{{.*}}
 // Test for rdar://10278815
 
 // Without PCH
Index: clang/test/PCH/objcxx-ivar-class.mm
===
--- clang/test/PCH/objcxx-ivar-class.mm
+++ clang/test/PCH/objcxx-ivar-class.mm
@@ -1,4 +1,4 @@
-// UNSUPPORTED: -zos, target={{.*}}-aix{{.*}}
+// UNSUPPORTED: target={{.*}}-zos{{.*}}, target={{.*}}-aix{{.*}}
 // Test this without pch.
 // RUN: %clang_cc1 -no-opaque-pointers -include %S/objcxx-ivar-class.h -triple %itanium_abi_triple %s -emit-llvm -o - | FileCheck %s
 
Index: clang/test/PCH/objc_literals.mm
===
--- clang/test/PCH/objc_literals.mm
+++ clang/test/PCH/objc_literals.mm
@@ -1,4 +1,4 @@
-// UNSUPPORTED: -zos, target={{.*}}-aix{{.*}}
+// UNSUPPORTED: target={{.*}}-zos{{.*}}, target={{.*}}-aix{{.*}}
 // RUN: %clang_cc1 -triple %itanium_abi_triple -emit-pch -x objective-c++ -std=c++0x -o %t %s
 // RUN: %clang_cc1 -triple %itanium_abi_triple -include-pch %t -x objective-c++ 

[PATCH] D139400: [clang] Show error when a local variables is passed as default template parameter

2022-12-08 Thread Shafik Yaghmour via Phabricator via cfe-commits
shafik added inline comments.



Comment at: clang/lib/Sema/SemaTemplate.cpp:11
 
+#include  // massberg
 #include "TreeTransform.h"

Please remove.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139400

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


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

2022-12-08 Thread Zahira Ammarguellat via Phabricator via cfe-commits
zahiraam added a comment.

Can you please be more verbose in your summary? This change is related to the 
use of -ffp-exception-behavior=strict right? 
This attribute is set here 
https://github.com/llvm/llvm-project/blob/main/clang/lib/CodeGen/CodeGenFunction.cpp#L987
 but under a condition. Is that condition always satisfied when the attribute 
needs to be set?


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

https://reviews.llvm.org/D139629

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


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

2022-12-08 Thread Matt Arsenault via Phabricator via cfe-commits
arsenm added a comment.

In D139629#3981991 , @zahiraam wrote:

> Can you please be more verbose in your summary? This change is related to the 
> use of -ffp-exception-behavior=strict right? 
> This attribute is set here 
> https://github.com/llvm/llvm-project/blob/main/clang/lib/CodeGen/CodeGenFunction.cpp#L987
>  but under a condition. Is that condition always satisfied when the attribute 
> needs to be set?

I don't know if there are other cases that misses; if so it's broken anyway. 
Nothing reads this string formed version


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

https://reviews.llvm.org/D139629

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


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

2022-12-08 Thread Matt Arsenault via Phabricator via cfe-commits
arsenm added a comment.

In D139629#3982052 , @arsenm wrote:

> In D139629#3981991 , @zahiraam 
> wrote:
>
>> Can you please be more verbose in your summary? This change is related to 
>> the use of -ffp-exception-behavior=strict right? 
>> This attribute is set here 
>> https://github.com/llvm/llvm-project/blob/main/clang/lib/CodeGen/CodeGenFunction.cpp#L987
>>  but under a condition. Is that condition always satisfied when the 
>> attribute needs to be set?
>
> I don't know if there are other cases that misses; if so it's broken anyway. 
> Nothing reads this string formed version

It's coming from the FunctionDecl and the other case is broader. Only question 
would be of reachability


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

https://reviews.llvm.org/D139629

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


[PATCH] D139652: Add the thread sanitizer support for X86_64 WatchOS simulators

2022-12-08 Thread Yifan Yang via Phabricator via cfe-commits
yfyang created this revision.
yfyang added a reviewer: jyknight.
Herald added a subscriber: pengfei.
Herald added a project: All.
yfyang requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay.
Herald added a project: clang.

Thread sanitizer for x86_64 architecutre is supported currently for TVOS and 
iOS simulators.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D139652

Files:
  clang/lib/Driver/ToolChains/Darwin.cpp
  clang/test/Driver/fsanitize.c


Index: clang/test/Driver/fsanitize.c
===
--- clang/test/Driver/fsanitize.c
+++ clang/test/Driver/fsanitize.c
@@ -463,6 +463,9 @@
 // RUN: %clang --target=x86_64-apple-ios-simulator -fsanitize=thread %s -### 
2>&1 | FileCheck %s --check-prefix=CHECK-TSAN-X86-64-IOSSIMULATOR
 // CHECK-TSAN-X86-64-IOSSIMULATOR-NOT: unsupported option
 
+// RUN: %clang --target=x86_64-apple-watchos-simulator -fsanitize=thread %s 
-### 2>&1 | FileCheck %s --check-prefix=CHECK-TSAN-X86-64-WATCHOSSIMULATOR
+// CHECK-TSAN-X86-64-WATCHOSSIMULATOR-NOT: unsupported option
+
 // RUN: %clang --target=x86_64-apple-tvos-simulator -fsanitize=thread %s -### 
2>&1 | FileCheck %s --check-prefix=CHECK-TSAN-X86-64-TVOSSIMULATOR
 // CHECK-TSAN-X86-64-TVOSSIMULATOR-NOT: unsupported option
 
Index: clang/lib/Driver/ToolChains/Darwin.cpp
===
--- clang/lib/Driver/ToolChains/Darwin.cpp
+++ clang/lib/Driver/ToolChains/Darwin.cpp
@@ -3279,7 +3279,8 @@
 
   if ((IsX86_64 || IsAArch64) && isTargetMacOSBased()) {
 Res |= SanitizerKind::Thread;
-  } else if (isTargetIOSSimulator() || isTargetTvOSSimulator()) {
+  } else if (isTargetIOSSimulator() || isTargetTvOSSimulator() ||
+ isTargetWatchOSSimulator()) {
 if (IsX86_64)
   Res |= SanitizerKind::Thread;
   }


Index: clang/test/Driver/fsanitize.c
===
--- clang/test/Driver/fsanitize.c
+++ clang/test/Driver/fsanitize.c
@@ -463,6 +463,9 @@
 // RUN: %clang --target=x86_64-apple-ios-simulator -fsanitize=thread %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-TSAN-X86-64-IOSSIMULATOR
 // CHECK-TSAN-X86-64-IOSSIMULATOR-NOT: unsupported option
 
+// RUN: %clang --target=x86_64-apple-watchos-simulator -fsanitize=thread %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-TSAN-X86-64-WATCHOSSIMULATOR
+// CHECK-TSAN-X86-64-WATCHOSSIMULATOR-NOT: unsupported option
+
 // RUN: %clang --target=x86_64-apple-tvos-simulator -fsanitize=thread %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-TSAN-X86-64-TVOSSIMULATOR
 // CHECK-TSAN-X86-64-TVOSSIMULATOR-NOT: unsupported option
 
Index: clang/lib/Driver/ToolChains/Darwin.cpp
===
--- clang/lib/Driver/ToolChains/Darwin.cpp
+++ clang/lib/Driver/ToolChains/Darwin.cpp
@@ -3279,7 +3279,8 @@
 
   if ((IsX86_64 || IsAArch64) && isTargetMacOSBased()) {
 Res |= SanitizerKind::Thread;
-  } else if (isTargetIOSSimulator() || isTargetTvOSSimulator()) {
+  } else if (isTargetIOSSimulator() || isTargetTvOSSimulator() ||
+ isTargetWatchOSSimulator()) {
 if (IsX86_64)
   Res |= SanitizerKind::Thread;
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D139653: [clang] Set ShowInSystemHeader for module-build and module-import remarks

2022-12-08 Thread Dave Lee via Phabricator via cfe-commits
kastiglione created this revision.
kastiglione added a reviewer: jansvoboda11.
Herald added a project: All.
kastiglione requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Without this change, the use of `-Rmodule-build` and `-Rmodule-import` only 
produces diagnostics for modules built or imported by non-system code.

For example, if a project source file requires the Foundation module to be 
built, then `-Rmodule-build` will show a single diagnostic for Foundation, but 
not in turn for any of Foundation's (direct or indirect) dependencies. This is 
because the locations of those transitive module builds are initiated from 
system headers, which are ignored by default. When wanting to observe module 
building/importing, the system modules can represent a significant amount of 
module diagnostics, and I think should be shown by default when 
`-Rmodule-build` and `-Rmodule-import` are specified.

I noticed some other remarks use `ShowInSystemHeader`.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D139653

Files:
  clang/include/clang/Basic/DiagnosticFrontendKinds.td
  clang/include/clang/Basic/DiagnosticSerializationKinds.td


Index: clang/include/clang/Basic/DiagnosticSerializationKinds.td
===
--- clang/include/clang/Basic/DiagnosticSerializationKinds.td
+++ clang/include/clang/Basic/DiagnosticSerializationKinds.td
@@ -75,6 +75,7 @@
 
 def remark_module_import : Remark<
   "importing module '%0'%select{| into '%3'}2 from '%1'">,
+  ShowInSystemHeader,
   InGroup;
 
 def err_imported_module_not_found : Error<
Index: clang/include/clang/Basic/DiagnosticFrontendKinds.td
===
--- clang/include/clang/Basic/DiagnosticFrontendKinds.td
+++ clang/include/clang/Basic/DiagnosticFrontendKinds.td
@@ -241,6 +241,7 @@
 def note_module_def_undef_here : Note<
   "macro was %select{defined|#undef'd}0 here">;
 def remark_module_build : Remark<"building module '%0' as '%1'">,
+  ShowInSystemHeader,
   InGroup;
 def remark_module_build_done : Remark<"finished building module '%0'">,
   InGroup;


Index: clang/include/clang/Basic/DiagnosticSerializationKinds.td
===
--- clang/include/clang/Basic/DiagnosticSerializationKinds.td
+++ clang/include/clang/Basic/DiagnosticSerializationKinds.td
@@ -75,6 +75,7 @@
 
 def remark_module_import : Remark<
   "importing module '%0'%select{| into '%3'}2 from '%1'">,
+  ShowInSystemHeader,
   InGroup;
 
 def err_imported_module_not_found : Error<
Index: clang/include/clang/Basic/DiagnosticFrontendKinds.td
===
--- clang/include/clang/Basic/DiagnosticFrontendKinds.td
+++ clang/include/clang/Basic/DiagnosticFrontendKinds.td
@@ -241,6 +241,7 @@
 def note_module_def_undef_here : Note<
   "macro was %select{defined|#undef'd}0 here">;
 def remark_module_build : Remark<"building module '%0' as '%1'">,
+  ShowInSystemHeader,
   InGroup;
 def remark_module_build_done : Remark<"finished building module '%0'">,
   InGroup;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D139166: [OPENMP51] Codegen support for error directive.

2022-12-08 Thread Jennifer Yu via Phabricator via cfe-commits
jyu2 added inline comments.



Comment at: clang/lib/CodeGen/CGOpenMPRuntime.h:334
   llvm::Value *emitUpdateLocation(CodeGenFunction , SourceLocation Loc,
-  unsigned Flags = 0);
+  unsigned Flags = 0, bool EmitLoc = false);
 

ABataev wrote:
> Why do you need this location? To output it for the user in the runtime 
> library call?
Thanks Alexey!
Yes.  When run time emit error, the location will be presented like:

OMP: Warning #283: test_error_directive.cpp:6:1: Encountered user-directed 
warning: 2 or more procs required..

...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139166

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


[PATCH] D139166: [OPENMP51] Codegen support for error directive.

2022-12-08 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev accepted this revision.
ABataev 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/D139166/new/

https://reviews.llvm.org/D139166

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


[PATCH] D139429: [clang] Add test for CWG418

2022-12-08 Thread Vlad Serebrennikov via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG90d4cbb87ce2: [clang] Add test for CWG418 (authored by 
Endill).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139429

Files:
  clang/test/CXX/drs/dr4xx.cpp
  clang/www/cxx_dr_status.html


Index: clang/www/cxx_dr_status.html
===
--- clang/www/cxx_dr_status.html
+++ clang/www/cxx_dr_status.html
@@ -2547,7 +2547,7 @@
 https://wg21.link/cwg418;>418
 CD6
 Imperfect wording on error on multiple default arguments on a called 
function
-Unknown
+No
   
   
 https://wg21.link/cwg419;>419
Index: clang/test/CXX/drs/dr4xx.cpp
===
--- clang/test/CXX/drs/dr4xx.cpp
+++ clang/test/CXX/drs/dr4xx.cpp
@@ -315,6 +315,50 @@
   }
 }
 
+namespace dr418 { // dr418: no
+namespace example1 {
+void f1(int, int = 0);
+void f1(int = 0, int);
+
+void g() { f1(); }
+} // namespace example1
+
+namespace example2 {
+namespace A {
+void f2(int); // #dr418-f2-decl
+}
+namespace B {
+using A::f2;
+}
+namespace A {
+void f2(int = 3);
+}
+void g2() {
+  using B::f2;
+  f2(); // expected-error {{no matching function}}
+  // expected-note@#dr418-f2-decl {{requires 1 argument}}
+}
+} // namespace example2
+
+// example from [over.match.best]/4
+namespace example3 {
+namespace A {
+extern "C" void f(int = 5);
+}
+namespace B {
+extern "C" void f(int = 5);
+}
+
+using A::f;
+using B::f;
+
+void use() {
+  f(3);
+  f(); // FIXME: this should fail
+}
+} // namespace example3
+} // namespace dr418
+
 namespace dr420 { // dr420: yes
   template struct ptr {
 T *operator->() const;


Index: clang/www/cxx_dr_status.html
===
--- clang/www/cxx_dr_status.html
+++ clang/www/cxx_dr_status.html
@@ -2547,7 +2547,7 @@
 https://wg21.link/cwg418;>418
 CD6
 Imperfect wording on error on multiple default arguments on a called function
-Unknown
+No
   
   
 https://wg21.link/cwg419;>419
Index: clang/test/CXX/drs/dr4xx.cpp
===
--- clang/test/CXX/drs/dr4xx.cpp
+++ clang/test/CXX/drs/dr4xx.cpp
@@ -315,6 +315,50 @@
   }
 }
 
+namespace dr418 { // dr418: no
+namespace example1 {
+void f1(int, int = 0);
+void f1(int = 0, int);
+
+void g() { f1(); }
+} // namespace example1
+
+namespace example2 {
+namespace A {
+void f2(int); // #dr418-f2-decl
+}
+namespace B {
+using A::f2;
+}
+namespace A {
+void f2(int = 3);
+}
+void g2() {
+  using B::f2;
+  f2(); // expected-error {{no matching function}}
+  // expected-note@#dr418-f2-decl {{requires 1 argument}}
+}
+} // namespace example2
+
+// example from [over.match.best]/4
+namespace example3 {
+namespace A {
+extern "C" void f(int = 5);
+}
+namespace B {
+extern "C" void f(int = 5);
+}
+
+using A::f;
+using B::f;
+
+void use() {
+  f(3);
+  f(); // FIXME: this should fail
+}
+} // namespace example3
+} // namespace dr418
+
 namespace dr420 { // dr420: yes
   template struct ptr {
 T *operator->() const;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 90d4cbb - [clang] Add test for CWG418

2022-12-08 Thread Vlad Serebrennikov via cfe-commits

Author: Vlad Serebrennikov
Date: 2022-12-08T21:57:07+03:00
New Revision: 90d4cbb87ce297d93159d39528767f5f46aa4da4

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

LOG: [clang] Add test for CWG418

P1787: //[[ https://cplusplus.github.io/CWG/issues/418.html | CWG418 ]] is 
resolved by trivial rephrasing along with that necessary for the new 
using-declaration interpretation.//
Wording: see changes to [dcl.fct.default]/9 and [over.match.best]/4.

[over.match.best]/4 includes [[ 
https://eel.is/c++draft/over.match.best#general-example-8 | an example ]] that 
is not properly diagnosed by Clang.

Reviewed By: #clang-language-wg, shafik

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

Added: 


Modified: 
clang/test/CXX/drs/dr4xx.cpp
clang/www/cxx_dr_status.html

Removed: 




diff  --git a/clang/test/CXX/drs/dr4xx.cpp b/clang/test/CXX/drs/dr4xx.cpp
index 1814f5ac32185..3617af8b683c0 100644
--- a/clang/test/CXX/drs/dr4xx.cpp
+++ b/clang/test/CXX/drs/dr4xx.cpp
@@ -315,6 +315,50 @@ namespace dr417 { // dr417: no
   }
 }
 
+namespace dr418 { // dr418: no
+namespace example1 {
+void f1(int, int = 0);
+void f1(int = 0, int);
+
+void g() { f1(); }
+} // namespace example1
+
+namespace example2 {
+namespace A {
+void f2(int); // #dr418-f2-decl
+}
+namespace B {
+using A::f2;
+}
+namespace A {
+void f2(int = 3);
+}
+void g2() {
+  using B::f2;
+  f2(); // expected-error {{no matching function}}
+  // expected-note@#dr418-f2-decl {{requires 1 argument}}
+}
+} // namespace example2
+
+// example from [over.match.best]/4
+namespace example3 {
+namespace A {
+extern "C" void f(int = 5);
+}
+namespace B {
+extern "C" void f(int = 5);
+}
+
+using A::f;
+using B::f;
+
+void use() {
+  f(3);
+  f(); // FIXME: this should fail
+}
+} // namespace example3
+} // namespace dr418
+
 namespace dr420 { // dr420: yes
   template struct ptr {
 T *operator->() const;

diff  --git a/clang/www/cxx_dr_status.html b/clang/www/cxx_dr_status.html
index e8cb4318addfc..1c880bab52957 100755
--- a/clang/www/cxx_dr_status.html
+++ b/clang/www/cxx_dr_status.html
@@ -2547,7 +2547,7 @@ C++ defect report implementation 
status
 https://wg21.link/cwg418;>418
 CD6
 Imperfect wording on error on multiple default arguments on a called 
function
-Unknown
+No
   
   
 https://wg21.link/cwg419;>419



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


[PATCH] D139444: [ZOS] Convert tests to check 'target={{.*}}-zos'

2022-12-08 Thread Paul Robinson via Phabricator via cfe-commits
probinson added a comment.

In D139444#3978189 , @uweigand wrote:

> In D139444#3975182 , @probinson 
> wrote:
>
>> The changes in this patch assume that there aren't any possible suffixes 
>> after the `-zos` part of the triple (no version numbers, like you might find 
>> with darwin or macos, and nothing like `-elf` or `-eabi` like some targets 
>> have).  If there are suffixes, I'll happily revise to put `{{.*}}` after 
>> everything.
>
> I think for consistency with other targets, and to be safe for future 
> extensions of the target triple, it would be better to add the `{{.*}}`

Okay.

> [for encoding.ll] To express that restriction on the *host* system, you 
> should be using a `REQUIRES: system-zos` line.   However, it looks like this 
> capability is not actually currently implemented - you'll have to add it to 
> the code in `utils/lit/lit/llvm/config.py` here:
>
>   [...]
>   elif platform.system() == 'NetBSD':
>   features.add('system-netbsd')
>   elif platform.system() == 'AIX':
>   features.add('system-aix')
>   elif platform.system() == 'SunOS':
>   features.add('system-solaris')
>
> (Note that you probably still should add the `-mtriple` because the test case 
> requires *both* running on a z/OS host *and* compiling for the z/OS target.)

If you can tell me the `platform.system()` value to look for to detect z/OS, I 
can do that.  Probably as a separate patch, as it would be going beyond the 
mechanical replacement that I'm doing for everything else.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139444

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


[PATCH] D139627: clang/X86: Don't emit "min-legal-vector-width"="0"

2022-12-08 Thread Matt Arsenault via Phabricator via cfe-commits
arsenm added a comment.

In D139627#3981475 , @pengfei wrote:

> The use of `min-legal-vector-width` doesn't look great to me either. I'm more 
> than glad if we can remove it totally without any user perceivable affects.
> I cannot agree with this change because it neither eliminates the clutter 
> (but makes it even worse [1]) nor is NFC to end user.
> I think we used `UINT32_MAX` just to be compatible with BCs that generated 
> before introduing the attribute. This change definitely breaks the 
> compatibility.

What I'm getting is this is only a performance hint, and definitively doesn't 
matter for ABI purposes. Bitcode backwards performance compatibility is not 
important. That would also be recovered by having a proper attribute 
propagation done as an optimization.

I think all of clang's handling of this should be purged, except for the part 
where it's passing through the user attribute.

> Placing a `"min-legal-vector-width" = "512"` doesn't make any sense either. 
> For one thing, we cannot place the attribute in pre-built BC files, for 
> another `512` is the current max vector suppoted on X86, we cannot guarantee 
> no `1024`, `2048` etc. in future and we cannot change it too once compiled 
> into BC files.

It's a test for specific behavior, with a specific configuration that exists 
today. It doesn't matter what this would be in the future for larger testcases

> [1] `"min-legal-vector-width" = "0"` was clear to indicate there are only 
> scalar operations.

It's not remotely clear what this means


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

https://reviews.llvm.org/D139627

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


[clang] 100dfe7 - [OpenMP] Clang Support for taskwait nowait clause

2022-12-08 Thread Alexey Bataev via cfe-commits

Author: Sunil K
Date: 2022-12-08T12:40:44-08:00
New Revision: 100dfe7a8ad3789a98df623482b88d9a3a02e176

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

LOG: [OpenMP] Clang Support for taskwait nowait clause

Support for taskwait nowait clause with placeholder for runtime changes.

Reviewed By: ABataev

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

Added: 
clang/test/OpenMP/taskwait_depend_nowait_codegen.cpp
clang/test/OpenMP/taskwait_nowait_codegen.cpp

Modified: 
clang/lib/CodeGen/CGOpenMPRuntime.cpp
clang/lib/CodeGen/CGOpenMPRuntime.h
clang/lib/CodeGen/CGStmtOpenMP.cpp
clang/test/OpenMP/target_depend_codegen.cpp
clang/test/OpenMP/target_enter_data_depend_codegen.cpp
clang/test/OpenMP/target_exit_data_depend_codegen.cpp
clang/test/OpenMP/target_parallel_depend_codegen.cpp
clang/test/OpenMP/target_parallel_for_depend_codegen.cpp
clang/test/OpenMP/target_parallel_for_simd_depend_codegen.cpp
clang/test/OpenMP/target_simd_depend_codegen.cpp
clang/test/OpenMP/target_teams_depend_codegen.cpp
clang/test/OpenMP/target_teams_distribute_depend_codegen.cpp
clang/test/OpenMP/target_teams_distribute_parallel_for_depend_codegen.cpp

clang/test/OpenMP/target_teams_distribute_parallel_for_simd_depend_codegen.cpp
clang/test/OpenMP/target_teams_distribute_simd_depend_codegen.cpp
clang/test/OpenMP/target_update_depend_codegen.cpp
clang/test/OpenMP/task_codegen.cpp
clang/test/OpenMP/task_if_codegen.cpp
clang/test/OpenMP/taskwait_ast_print.cpp
clang/test/OpenMP/taskwait_codegen.cpp
clang/test/OpenMP/taskwait_depend_codegen.cpp
llvm/include/llvm/Frontend/OpenMP/OMP.td
llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h
llvm/include/llvm/Frontend/OpenMP/OMPKinds.def
llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp
mlir/test/Target/LLVMIR/openmp-llvm.mlir
openmp/runtime/src/dllexports
openmp/runtime/src/kmp.h
openmp/runtime/src/kmp_taskdeps.cpp
openmp/runtime/src/kmp_tasking.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGOpenMPRuntime.cpp 
b/clang/lib/CodeGen/CGOpenMPRuntime.cpp
index 51f364fac8d1b..10c88964da0ed 100644
--- a/clang/lib/CodeGen/CGOpenMPRuntime.cpp
+++ b/clang/lib/CodeGen/CGOpenMPRuntime.cpp
@@ -4739,7 +4739,7 @@ void CGOpenMPRuntime::emitTaskCall(CodeGenFunction , 
SourceLocation Loc,
   Region->emitUntiedSwitch(CGF);
   };
 
-  llvm::Value *DepWaitTaskArgs[6];
+  llvm::Value *DepWaitTaskArgs[7];
   if (!Data.Dependences.empty()) {
 DepWaitTaskArgs[0] = UpLoc;
 DepWaitTaskArgs[1] = ThreadID;
@@ -4747,6 +4747,8 @@ void CGOpenMPRuntime::emitTaskCall(CodeGenFunction , 
SourceLocation Loc,
 DepWaitTaskArgs[3] = DependenciesArray.getPointer();
 DepWaitTaskArgs[4] = CGF.Builder.getInt32(0);
 DepWaitTaskArgs[5] = llvm::ConstantPointerNull::get(CGF.VoidPtrTy);
+DepWaitTaskArgs[6] =
+llvm::ConstantInt::get(CGF.Int32Ty, Data.HasNowaitClause);
   }
   auto  = CGM.getModule();
   auto & = [this, , , ThreadID, NewTaskNewTaskTTy,
@@ -4758,9 +4760,9 @@ void CGOpenMPRuntime::emitTaskCall(CodeGenFunction , 
SourceLocation Loc,
 // ndeps_noalias, kmp_depend_info_t *noalias_dep_list); if dependence info
 // is specified.
 if (!Data.Dependences.empty())
-  CGF.EmitRuntimeCall(
-  OMPBuilder.getOrCreateRuntimeFunction(M, 
OMPRTL___kmpc_omp_wait_deps),
-  DepWaitTaskArgs);
+  CGF.EmitRuntimeCall(OMPBuilder.getOrCreateRuntimeFunction(
+  M, OMPRTL___kmpc_omp_taskwait_deps_51),
+  DepWaitTaskArgs);
 // Call proxy_task_entry(gtid, new_task);
 auto & = [TaskEntry, ThreadID, NewTaskNewTaskTTy,
   Loc](CodeGenFunction , PrePostActionTy ) {
@@ -5799,7 +5801,7 @@ void CGOpenMPRuntime::emitTaskwaitCall(CodeGenFunction 
, SourceLocation Loc,
 
   if (CGF.CGM.getLangOpts().OpenMPIRBuilder && Data.Dependences.empty()) {
 // TODO: Need to support taskwait with dependences in the OpenMPIRBuilder.
-OMPBuilder.createTaskwait(CGF.Builder);
+OMPBuilder.createTaskwait(CGF.Builder, Data.HasNowaitClause);
   } else {
 llvm::Value *ThreadID = getThreadID(CGF, Loc);
 llvm::Value *UpLoc = emitUpdateLocation(CGF, Loc);
@@ -5808,34 +5810,38 @@ void CGOpenMPRuntime::emitTaskwaitCall(CodeGenFunction 
, SourceLocation Loc,
 llvm::Value *NumOfElements;
 std::tie(NumOfElements, DependenciesArray) =
 emitDependClause(CGF, Data.Dependences, Loc);
-llvm::Value *DepWaitTaskArgs[6];
 if (!Data.Dependences.empty()) {
+  llvm::Value *DepWaitTaskArgs[7];
   DepWaitTaskArgs[0] = UpLoc;
   DepWaitTaskArgs[1] = ThreadID;
   DepWaitTaskArgs[2] = NumOfElements;
   DepWaitTaskArgs[3] = 

[PATCH] D131830: [OpenMP] Clang Support for taskwait nowait clause

2022-12-08 Thread Alexey Bataev 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 rG100dfe7a8ad3: [OpenMP] Clang Support for taskwait nowait 
clause (authored by koops, committed by ABataev).
Herald added projects: clang, OpenMP.
Herald added subscribers: openmp-commits, cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131830

Files:
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/lib/CodeGen/CGOpenMPRuntime.h
  clang/lib/CodeGen/CGStmtOpenMP.cpp
  clang/test/OpenMP/target_depend_codegen.cpp
  clang/test/OpenMP/target_enter_data_depend_codegen.cpp
  clang/test/OpenMP/target_exit_data_depend_codegen.cpp
  clang/test/OpenMP/target_parallel_depend_codegen.cpp
  clang/test/OpenMP/target_parallel_for_depend_codegen.cpp
  clang/test/OpenMP/target_parallel_for_simd_depend_codegen.cpp
  clang/test/OpenMP/target_simd_depend_codegen.cpp
  clang/test/OpenMP/target_teams_depend_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_depend_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_depend_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_simd_depend_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_simd_depend_codegen.cpp
  clang/test/OpenMP/target_update_depend_codegen.cpp
  clang/test/OpenMP/task_codegen.cpp
  clang/test/OpenMP/task_if_codegen.cpp
  clang/test/OpenMP/taskwait_ast_print.cpp
  clang/test/OpenMP/taskwait_codegen.cpp
  clang/test/OpenMP/taskwait_depend_codegen.cpp
  clang/test/OpenMP/taskwait_depend_nowait_codegen.cpp
  clang/test/OpenMP/taskwait_nowait_codegen.cpp
  llvm/include/llvm/Frontend/OpenMP/OMP.td
  llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h
  llvm/include/llvm/Frontend/OpenMP/OMPKinds.def
  llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp
  mlir/test/Target/LLVMIR/openmp-llvm.mlir
  openmp/runtime/src/dllexports
  openmp/runtime/src/kmp.h
  openmp/runtime/src/kmp_taskdeps.cpp
  openmp/runtime/src/kmp_tasking.cpp

Index: openmp/runtime/src/kmp_tasking.cpp
===
--- openmp/runtime/src/kmp_tasking.cpp
+++ openmp/runtime/src/kmp_tasking.cpp
@@ -2049,7 +2049,8 @@
 template 
 static kmp_int32 __kmpc_omp_taskwait_template(ident_t *loc_ref, kmp_int32 gtid,
   void *frame_address,
-  void *return_address) {
+  void *return_address,
+  kmp_int32 has_no_wait) {
   kmp_taskdata_t *taskdata = nullptr;
   kmp_info_t *thread;
   int thread_finished = FALSE;
@@ -2162,23 +2163,34 @@
 OMPT_NOINLINE
 static kmp_int32 __kmpc_omp_taskwait_ompt(ident_t *loc_ref, kmp_int32 gtid,
   void *frame_address,
-  void *return_address) {
+  void *return_address,
+  kmp_int32 has_no_wait) {
   return __kmpc_omp_taskwait_template(loc_ref, gtid, frame_address,
-return_address);
+return_address, has_no_wait);
 }
 #endif // OMPT_SUPPORT && OMPT_OPTIONAL
 
 // __kmpc_omp_taskwait: Wait until all tasks generated by the current task are
 // complete
 kmp_int32 __kmpc_omp_taskwait(ident_t *loc_ref, kmp_int32 gtid) {
+  return __kmpc_omp_taskwait_51(loc_ref, gtid, false);
+}
+
+/* __kmpc_omp_taskwait_51 : Function for OpenMP 5.1 nowait clause.
+ *  Placeholder for taskwait with nowait clause.
+ *  The code is a copy of __kmpc_omp_taskwait.*/
+kmp_int32 __kmpc_omp_taskwait_51(ident_t *loc_ref, kmp_int32 gtid,
+ kmp_int32 has_no_wait) {
 #if OMPT_SUPPORT && OMPT_OPTIONAL
   if (UNLIKELY(ompt_enabled.enabled)) {
 OMPT_STORE_RETURN_ADDRESS(gtid);
 return __kmpc_omp_taskwait_ompt(loc_ref, gtid, OMPT_GET_FRAME_ADDRESS(0),
-OMPT_LOAD_RETURN_ADDRESS(gtid));
+OMPT_LOAD_RETURN_ADDRESS(gtid),
+has_no_wait);
   }
 #endif
-  return __kmpc_omp_taskwait_template(loc_ref, gtid, NULL, NULL);
+  return __kmpc_omp_taskwait_template(loc_ref, gtid, NULL, NULL,
+ has_no_wait);
 }
 
 // __kmpc_omp_taskyield: switch to a different task
Index: openmp/runtime/src/kmp_taskdeps.cpp
===
--- openmp/runtime/src/kmp_taskdeps.cpp
+++ openmp/runtime/src/kmp_taskdeps.cpp
@@ -744,10 +744,24 @@
 void __kmpc_omp_wait_deps(ident_t *loc_ref, kmp_int32 gtid, kmp_int32 ndeps,
   kmp_depend_info_t *dep_list, kmp_int32 ndeps_noalias,
   

[PATCH] D139647: [opt] Disincentivize new tests from using old pass syntax

2022-12-08 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added a comment.

@aeubanks Thank you for the review!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139647

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


[PATCH] D139166: [OPENMP51] Codegen support for error directive.

2022-12-08 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev added inline comments.



Comment at: clang/lib/CodeGen/CGOpenMPRuntime.h:334
   llvm::Value *emitUpdateLocation(CodeGenFunction , SourceLocation Loc,
-  unsigned Flags = 0);
+  unsigned Flags = 0, bool EmitLoc = false);
 

Why do you need this location? To output it for the user in the runtime library 
call?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139166

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


[clang] d694e24 - Update the status of a few more C DRs

2022-12-08 Thread Aaron Ballman via cfe-commits

Author: Aaron Ballman
Date: 2022-12-08T13:19:29-05:00
New Revision: d694e2490af8b2e92c79b2c1b543bcc4bb3981d1

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

LOG: Update the status of a few more C DRs

This includes tests for DR085 and DR259.

Added: 
clang/test/C/drs/dr259.c

Modified: 
clang/test/C/drs/dr0xx.c
clang/www/c_dr_status.html

Removed: 




diff  --git a/clang/test/C/drs/dr0xx.c b/clang/test/C/drs/dr0xx.c
index 942e83bef886c..6a3717f0729b6 100644
--- a/clang/test/C/drs/dr0xx.c
+++ b/clang/test/C/drs/dr0xx.c
@@ -70,6 +70,9 @@
  * WG14 DR080: yes
  * Merging of string constants
  *
+ * WG14 DR085: yes
+ * Returning from main
+ *
  * WG14 DR086: yes
  * Object-like macros in system headers
  *

diff  --git a/clang/test/C/drs/dr259.c b/clang/test/C/drs/dr259.c
new file mode 100644
index 0..0bd039e04bef5
--- /dev/null
+++ b/clang/test/C/drs/dr259.c
@@ -0,0 +1,21 @@
+/* RUN: %clang_cc1 -std=c89 -E -verify %s | FileCheck %s
+   RUN: %clang_cc1 -std=c99 -E -verify %s | FileCheck %s
+   RUN: %clang_cc1 -std=c11 -E -verify %s | FileCheck %s
+   RUN: %clang_cc1 -std=c17 -E -verify %s | FileCheck %s
+   RUN: %clang_cc1 -std=c2x -E -verify %s | FileCheck %s
+ */
+
+/* expected-no-diagnostics */
+
+/* WG14 DR259: yes
+ * Macro invocations with no arguments
+ */
+#define m0() replacement
+#define m1(x) begin x end
+
+m0() m1()
+
+/*
+CHECK: replacement begin end
+*/
+

diff  --git a/clang/www/c_dr_status.html b/clang/www/c_dr_status.html
index ea38597717363..15e92c5eb2ccb 100644
--- a/clang/www/c_dr_status.html
+++ b/clang/www/c_dr_status.html
@@ -565,7 +565,7 @@ C defect report implementation status
 https://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_085.html;>85
 C89
 Returning from main
-Unknown
+Yes
   
   
 https://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_086.html;>86
@@ -1488,7 +1488,7 @@ C defect report implementation status
 https://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_259.htm;>259
 NAD
 Macro invocations with no arguments
-Unknown
+Yes
   
   
 https://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_260.htm;>260



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


[PATCH] D139652: Add the thread sanitizer support for X86_64 WatchOS simulators

2022-12-08 Thread James Y Knight via Phabricator via cfe-commits
jyknight accepted this revision.
jyknight added a comment.
This revision is now accepted and ready to land.

Thanks for the change.

The description is a bit misleading, this would be better:

  Allow TSan in clang driver for X86_64 WatchOS simulator.
  
  It was already functional, and Apple's downstream fork of clang allows it, 
but that change had not made it upstream yet.

cc+=yln FYI, though this change seems obvious enough I'm comfortable to approve 
it directly.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139652

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


[PATCH] D135269: [AMDGPU] Disable bool range metadata to workaround backend issue

2022-12-08 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl added a comment.

In D135269#3982103 , @jrbyrnes wrote:

> In D135269#3981856 , @yaxunl wrote:
>
>> In D135269#3981561 , @nikic wrote:
>>
>>> Checking back here again on whether there is any progress on finding the 
>>> root cause of the issue. If no progress is expected in the near future, I'd 
>>> ask for this patch to be reverted.
>>
>> @jrbyrnes is working on the root cause of this issue. Any updates? Thanks.
>
> Thanks for the ping. I would also like to see this reverted as it enables 
> some optimizations. I do not have a definitive answer at the moment (w.r.t 
> reverting this), but hope to provide one soon
>
> As for now, the issue we are seeing from 
> (https://github.com/llvm/llvm-project/commit/8018d6be3459780e81a5da128a9915eb27909902)
>  seems most likely to be a source code issue (first document of issue 
> https://github.com/pytorch/pytorch/issues/54789 . upstream PyTorch currently 
> skips problematic test 
> https://github.com/pytorch/pytorch/blob/b738da8c8e4d9142ad38a1bd8c35d0bfef4b5e3c/torch/testing/_internal/common_methods_invocations.py#L14891)
>  . I will provide a better update soon.

I will revert this patch. Thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135269

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


[PATCH] D139115: [clang][ExtractAPI] Add support for single symbol SGF

2022-12-08 Thread Ben Langmuir via Phabricator via cfe-commits
benlangmuir added subscribers: akyrtzi, benlangmuir.
benlangmuir added inline comments.



Comment at: clang/include/clang-c/Documentation.h:549
 
+typedef struct CXAPISetImpl *CXAPISet;
+

@dang please document what this type represents.

@akyrtzi what's the preferred implementation type name for opaque typedef 
types? I see we have a mix right now:
* `void *`
* `CXOpaqueFoo *`
* `CXFooImpl *`



Comment at: clang/include/clang-c/Documentation.h:551
+
+CINDEX_LINKAGE enum CXErrorCode clang_createAPISet(CXTranslationUnit tu,
+   CXAPISet *out_api);

Please add documentation comments to all the new functions. For this one, we 
should explicitly include
* That the user needs to call `clang_disposeAPISet` for the output
* Whether `out_api` is modified on failure -- e.g. is it null?



Comment at: clang/include/clang-c/Documentation.h:556
+
+CINDEX_LINKAGE CXString clang_getSingleSymbolSGFForUSR(const char *usr,
+   CXAPISet api);

Does SGF stand for "Symbol Graph Fragment"?  How well-known is this 
abbreviation?  And how commonly-used do you expect these functions to be?  My 
gut reaction would be to use the full name here.

We should document the null return value for unknown symbols.  Are there other 
ways this could fail?  Is it ever interesting to know why this failed, or is 
success/fail always good enough?   Same applies to the function below.



Comment at: clang/tools/libclang/CXExtractAPI.cpp:40
+
+void WalkupFromMostDerivedType(ExtractAPIVisitor , Decl *D);
+

Nit: we use `static` for global functions and only use anon namespaces for 
types.  Same for the below.



Comment at: clang/tools/libclang/CXExtractAPI.cpp:73
+enum CXErrorCode clang_createAPISet(CXTranslationUnit tu, CXAPISet *out_api) {
+  ASTUnit *Unit = cxtu::getASTUnit(tu);
+

```
  if (isNotUsableTU(tu) || !out_api)
return CXError_InvalidArguments;
```



Comment at: clang/tools/libclang/CXExtractAPI.cpp:92
+
+CINDEX_LINKAGE CXString clang_getSingleSymbolSGFForUSR(const char *usr,
+   CXAPISet api) {

We don't want `CINDEX_LINKAGE` in the implementation, only the header needs it. 
 Same for the other functions



Comment at: clang/tools/libclang/CXExtractAPI.cpp:97
+  if (auto SGF = SymbolGraphSerializer::serializeSingleSymbolSGF(usr, *API)) {
+std::string BackingString;
+llvm::raw_string_ostream OS(BackingString);

Nit: maybe `SmallString` and `raw_svector_ostream`?



Comment at: clang/tools/libclang/CXExtractAPI.cpp:108
+CINDEX_LINKAGE CXString clang_getSingleSymbolSGF(CXCursor cursor) {
+  const CXCursorKind  = clang_getCursorKind(cursor);
+  if (clang_isDeclaration(Kind)) {

This is binding a temporary; you probably want `CXCursorKind` by value.



Comment at: clang/tools/libclang/CXExtractAPI.cpp:129
+SmallString<128> USR;
+index::generateUSRForDecl(D, USR);
+

Probably should check the return value here


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139115

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


[PATCH] D137337: Replace LLVM_LIBDIR_SUFFIX by CMAKE_INSTALL_LIBDIR

2022-12-08 Thread Saleem Abdulrasool via Phabricator via cfe-commits
compnerd added inline comments.



Comment at: bolt/lib/RuntimeLibs/RuntimeLibrary.cpp:32
   SmallString<128> LibPath = llvm::sys::path::parent_path(Dir);
-  llvm::sys::path::append(LibPath, "lib" LLVM_LIBDIR_SUFFIX);
+  llvm::sys::path::append(LibPath, CMAKE_INSTALL_LIBDIR);
   if (!llvm::sys::fs::exists(LibPath)) {

serge-sans-paille wrote:
> Ericson2314 wrote:
> > mgorny wrote:
> > > Well, one thing I immediately notice is that technically 
> > > `CMAKE_INSTALL_LIBDIR` can be an absolute path, while in many locations 
> > > you are assuming it will always be relative. Not saying that's a blocker 
> > > but I think you should add checks for that into `CMakeLists.txt`.
> > Yes I was working on this, and I intend to use `CMAKE_INSTALL_LIBDIR` with 
> > an absolute path.
> > 
> > OK if this isn't supported initially but we should ovoid regressing where 
> > possible.
> Turns out LLVM_LIBDIR_SUFFIX is used in several situations: (a) for the 
> library install dir or (b) for the location where build artifact as stored in 
> CMAKE_BINARY_DIR. (a) could accept a path but not (b), unless we derive it 
> from (a) but I can see a lot of complication there for the testing step. 
> Would that be ok to choke on CMAKE_INSTALL_LIBDIR being a path and not a 
> directory component?
> 
I think that is absolutely reasonable.  There is the 
`CMAKE_INSTALL_FULL_LIBDIR` which should be the relatively absolute path (it is 
relative to `DESTDIR`).  The `CMAKE_INSTALL_LIBDIR` should be the relative 
component which is added to `CMAKE_INSTALL_PREFIX`.


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

https://reviews.llvm.org/D137337

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


[clang] 4a1ccfe - When merging lambdas, keep track of the capture lists from each version.

2022-12-08 Thread Richard Smith via cfe-commits

Author: Richard Smith
Date: 2022-12-08T11:37:00-08:00
New Revision: 4a1ccfe8a3cfd4569bc962a38b6117a9a2b8ad21

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

LOG: When merging lambdas, keep track of the capture lists from each version.

Different versions of a lambda will in general refer to different
enclosing variable declarations, because we do not merge most
block-scope declarations, such as local variables. Keep track of all the
declarations that correspond to a lambda's capture fields so that we can
rewrite the name of any of those variables to the lambda capture,
regardless of which copy of the body of `operator()` we look at.

Added: 
clang/test/Modules/lambda-merge.cpp

Modified: 
clang/include/clang/AST/DeclCXX.h
clang/lib/AST/DeclCXX.cpp
clang/lib/AST/ExprCXX.cpp
clang/lib/Serialization/ASTReaderDecl.cpp
clang/lib/Serialization/ASTWriter.cpp

Removed: 




diff  --git a/clang/include/clang/AST/DeclCXX.h 
b/clang/include/clang/AST/DeclCXX.h
index feee56017da5..3836a2faaaf2 100644
--- a/clang/include/clang/AST/DeclCXX.h
+++ b/clang/include/clang/AST/DeclCXX.h
@@ -410,9 +410,11 @@ class CXXRecordDecl : public RecordDecl {
 /// or within a data member initializer.
 LazyDeclPtr ContextDecl;
 
-/// The list of captures, both explicit and implicit, for this
-/// lambda.
-Capture *Captures = nullptr;
+/// The lists of captures, both explicit and implicit, for this
+/// lambda. One list is provided for each merged copy of the lambda.
+/// The first list corresponds to the canonical definition.
+/// The destructor is registered by AddCaptureList when necessary.
+llvm::TinyPtrVector Captures;
 
 /// The type of the call method.
 TypeSourceInfo *MethodTyInfo;
@@ -430,6 +432,9 @@ class CXXRecordDecl : public RecordDecl {
   Aggregate = false;
   PlainOldData = false;
 }
+
+// Add a list of captures.
+void AddCaptureList(ASTContext , Capture *CaptureList);
   };
 
   struct DefinitionData *dataPtr() const {
@@ -1058,6 +1063,11 @@ class CXXRecordDecl : public RecordDecl {
   ///
   /// \note No entries will be added for init-captures, as they do not capture
   /// variables.
+  ///
+  /// \note If multiple versions of the lambda are merged together, they may
+  /// have 
diff erent variable declarations corresponding to the same capture.
+  /// In that case, all of those variable declarations will be added to the
+  /// Captures list, so it may have more than one variable listed per field.
   void
   getCaptureFields(llvm::DenseMap ,
FieldDecl *) const;
@@ -1070,7 +1080,9 @@ class CXXRecordDecl : public RecordDecl {
   }
 
   capture_const_iterator captures_begin() const {
-return isLambda() ? getLambdaData().Captures : nullptr;
+if (!isLambda()) return nullptr;
+LambdaDefinitionData  = getLambdaData();
+return LambdaData.Captures.empty() ? nullptr : LambdaData.Captures.front();
   }
 
   capture_const_iterator captures_end() const {

diff  --git a/clang/lib/AST/DeclCXX.cpp b/clang/lib/AST/DeclCXX.cpp
index 603075702a83..812cbabc00b8 100644
--- a/clang/lib/AST/DeclCXX.cpp
+++ b/clang/lib/AST/DeclCXX.cpp
@@ -1462,6 +1462,15 @@ void 
CXXRecordDecl::finishedDefaultedOrDeletedMember(CXXMethodDecl *D) {
   }
 }
 
+void CXXRecordDecl::LambdaDefinitionData::AddCaptureList(ASTContext ,
+ Capture *CaptureList) 
{
+  Captures.push_back(CaptureList);
+  if (Captures.size() == 2) {
+// The TinyPtrVector member now needs destruction.
+Ctx.addDestruction();
+  }
+}
+
 void CXXRecordDecl::setCaptures(ASTContext ,
 ArrayRef Captures) {
   CXXRecordDecl::LambdaDefinitionData  = getLambdaData();
@@ -1469,9 +1478,9 @@ void CXXRecordDecl::setCaptures(ASTContext ,
   // Copy captures.
   Data.NumCaptures = Captures.size();
   Data.NumExplicitCaptures = 0;
-  Data.Captures = (LambdaCapture *)Context.Allocate(sizeof(LambdaCapture) *
-Captures.size());
-  LambdaCapture *ToCapture = Data.Captures;
+  auto *ToCapture = (LambdaCapture *)Context.Allocate(sizeof(LambdaCapture) *
+  Captures.size());
+  Data.AddCaptureList(Context, ToCapture);
   for (unsigned I = 0, N = Captures.size(); I != N; ++I) {
 if (Captures[I].isExplicit())
   ++Data.NumExplicitCaptures;
@@ -1595,15 +1604,17 @@ void CXXRecordDecl::getCaptureFields(
   ThisCapture = nullptr;
 
   LambdaDefinitionData  = getLambdaData();
-  RecordDecl::field_iterator Field = field_begin();
-  for (const LambdaCapture *C = Lambda.Captures, *CEnd = C + 
Lambda.NumCaptures;
-   C != CEnd; ++C, ++Field) {
-if 

[PATCH] D139627: clang/X86: Don't emit "min-legal-vector-width"="0"

2022-12-08 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert added a comment.

Isn't this (inherently) X86 specific?


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

https://reviews.llvm.org/D139627

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


[PATCH] D139627: clang/X86: Don't emit "min-legal-vector-width"="0"

2022-12-08 Thread Craig Topper via Phabricator via cfe-commits
craig.topper added a comment.

In D139627#3982349 , @jdoerfert wrote:

> Isn't this (inherently) X86 specific?

Yes it is. We could qualify the attribute emission with the targeting being X86?


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

https://reviews.llvm.org/D139627

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


  1   2   >