date:20221004

[PATCH] D134699: [clang][Interp] Implement This pointer passing to methods

2022-10-04 Thread Timm Bäder via Phabricator via cfe-commits

tbaeder added a comment.

Ping


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

https://reviews.llvm.org/D134699

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

[clang-tools-extra] 6d9eb53 - [clang-tidy] Add checker 'bugprone-suspicious-realloc-usage'.

2022-10-04 Thread Balázs Kéri via cfe-commits


Author: Balázs Kéri
Date: 2022-10-04T09:14:46+02:00
New Revision: 6d9eb533291377979882ac9674431eddd1248445

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

LOG: [clang-tidy] Add checker 'bugprone-suspicious-realloc-usage'.

Add a check to detect usages of `realloc` where the result is assigned
to the same variable (or field) as passed to the first argument.

Reviewed By: steakhal, martong

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

Added: 
clang-tools-extra/clang-tidy/bugprone/SuspiciousReallocUsageCheck.cpp
clang-tools-extra/clang-tidy/bugprone/SuspiciousReallocUsageCheck.h

clang-tools-extra/docs/clang-tidy/checks/bugprone/suspicious-realloc-usage.rst

clang-tools-extra/test/clang-tidy/checkers/bugprone/suspicious-realloc-usage.cpp

Modified: 
clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp
clang-tools-extra/clang-tidy/bugprone/CMakeLists.txt
clang-tools-extra/docs/ReleaseNotes.rst
clang-tools-extra/docs/clang-tidy/checks/list.rst

Removed: 




diff  --git a/clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp 
b/clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp
index 961480a23f8f1..34386a0cb0154 100644
--- a/clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp
+++ b/clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp
@@ -58,6 +58,7 @@
 #include "SuspiciousMemoryComparisonCheck.h"
 #include "SuspiciousMemsetUsageCheck.h"
 #include "SuspiciousMissingCommaCheck.h"
+#include "SuspiciousReallocUsageCheck.h"
 #include "SuspiciousSemicolonCheck.h"
 #include "SuspiciousStringCompareCheck.h"
 #include "SwappedArgumentsCheck.h"
@@ -173,6 +174,8 @@ class BugproneModule : public ClangTidyModule {
 "bugprone-suspicious-memset-usage");
 CheckFactories.registerCheck(
 "bugprone-suspicious-missing-comma");
+CheckFactories.registerCheck(
+"bugprone-suspicious-realloc-usage");
 CheckFactories.registerCheck(
 "bugprone-suspicious-semicolon");
 CheckFactories.registerCheck(

diff  --git a/clang-tools-extra/clang-tidy/bugprone/CMakeLists.txt 
b/clang-tools-extra/clang-tidy/bugprone/CMakeLists.txt
index 1c7b0c2519f77..34c019357dab5 100644
--- a/clang-tools-extra/clang-tidy/bugprone/CMakeLists.txt
+++ b/clang-tools-extra/clang-tidy/bugprone/CMakeLists.txt
@@ -54,6 +54,7 @@ add_clang_library(clangTidyBugproneModule
   SuspiciousMemoryComparisonCheck.cpp
   SuspiciousMemsetUsageCheck.cpp
   SuspiciousMissingCommaCheck.cpp
+  SuspiciousReallocUsageCheck.cpp
   SuspiciousSemicolonCheck.cpp
   SuspiciousStringCompareCheck.cpp
   SwappedArgumentsCheck.cpp

diff  --git 
a/clang-tools-extra/clang-tidy/bugprone/SuspiciousReallocUsageCheck.cpp 
b/clang-tools-extra/clang-tidy/bugprone/SuspiciousReallocUsageCheck.cpp
new file mode 100644
index 0..bb975bc893d0d
--- /dev/null
+++ b/clang-tools-extra/clang-tidy/bugprone/SuspiciousReallocUsageCheck.cpp
@@ -0,0 +1,163 @@
+//===--- SuspiciousReallocUsageCheck.cpp - 
clang-tidy--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "SuspiciousReallocUsageCheck.h"
+#include "../utils/Aliasing.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/AST/DeclVisitor.h"
+#include "clang/AST/StmtVisitor.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/ASTMatchers/ASTMatchers.h"
+#include "clang/Lex/Lexer.h"
+
+using namespace clang::ast_matchers;
+using namespace clang;
+
+namespace {
+/// Check if two 
diff erent expression nodes denote the same
+/// "pointer expression". The "pointer expression" can consist of member
+/// expressions and declaration references only (like \c a->b->c), otherwise 
the
+/// check is always false.
+class IsSamePtrExpr : public StmtVisitor {
+  /// The other expression to compare against.
+  /// This variable is used to pass the data from a \c check function to any of
+  /// the visit functions. Every visit function starts by converting \c OtherE
+  /// to the current type and store it locally, and do not use \c OtherE later.
+  const Expr *OtherE = nullptr;
+
+public:
+  bool VisitDeclRefExpr(const DeclRefExpr *E1) {
+const auto *E2 = dyn_cast(OtherE);
+if (!E2)
+  return false;
+const Decl *D1 = E1->getDecl()->getCanonicalDecl();
+return isa(D1) &&
+   D1 == E2->getDecl()->getCanonicalDecl();
+  }
+
+  bool VisitMemberExpr(const MemberExpr *E1) {
+const auto *E2 = dyn_cast(OtherE);
+if (!E2)
+  return false;
+if (!check(E1->getBase(), E2->getBase()))
+  ret

[PATCH] D133119: [clang-tidy] Add checker 'bugprone-suspicious-realloc-usage'.

2022-10-04 Thread Balázs Kéri via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rG6d9eb5332913: [clang-tidy] Add checker 
'bugprone-suspicious-realloc-usage'. (authored by balazske).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133119

Files:
  clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp
  clang-tools-extra/clang-tidy/bugprone/CMakeLists.txt
  clang-tools-extra/clang-tidy/bugprone/SuspiciousReallocUsageCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/SuspiciousReallocUsageCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/bugprone/suspicious-realloc-usage.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  
clang-tools-extra/test/clang-tidy/checkers/bugprone/suspicious-realloc-usage.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/bugprone/suspicious-realloc-usage.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone/suspicious-realloc-usage.cpp
@@ -0,0 +1,102 @@
+// RUN: %check_clang_tidy %s bugprone-suspicious-realloc-usage %t
+
+void *realloc(void *, __SIZE_TYPE__);
+
+namespace std {
+  using ::realloc;
+}
+
+namespace n1 {
+  void *p;
+}
+
+namespace n2 {
+  void *p;
+}
+
+struct P {
+  void *p;
+  void *q;
+  P *pp;
+  void *&f();
+};
+
+struct P1 {
+  static void *p;
+  static void *q;
+};
+
+template
+struct P2 {
+  static void *p;
+  static void *q;
+};
+
+template
+void templ(void *p) {
+  A::p = realloc(A::p, 10);
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: 'A::p' may be set to null if 'realloc' fails, which may result in a leak of the original buffer [bugprone-suspicious-realloc-usage]
+  p = realloc(A::p, 10);
+  A::q = realloc(A::p, 10);
+  A::p = realloc(B::p, 10);
+  P2::p = realloc(P2::p, 1);
+  // CHECK-MESSAGES: :[[@LINE-1]]:14: warning: 'P2::p' may be set to null if 'realloc' fails, which may result in a leak of the original buffer [bugprone-suspicious-realloc-usage]
+  P2::p = realloc(P2::p, 1);
+}
+
+void *&getPtr();
+P &getP();
+
+void warn(void *p, P *p1, int *pi) {
+  p = realloc(p, 111);
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: 'p' may be set to null if 'realloc' fails, which may result in a leak of the original buffer [bugprone-suspicious-realloc-usage]
+
+  p = std::realloc(p, sizeof(int));
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: 'p' may be set to null if 'realloc' fails, which may result in a leak of the original buffer [bugprone-suspicious-realloc-usage]
+
+  p1->p = realloc(p1->p, 10);
+  // CHECK-MESSAGES: :[[@LINE-1]]:11: warning: 'p1->p' may be set to null if 'realloc' fails, which may result in a leak of the original buffer [bugprone-suspicious-realloc-usage]
+
+  p1->pp->p = realloc(p1->pp->p, 10);
+  // CHECK-MESSAGES: :[[@LINE-1]]:15: warning: 'p1->pp->p' may be set to null if 'realloc' fails, which may result in a leak of the original buffer [bugprone-suspicious-realloc-usage]
+
+  pi = (int*)realloc(pi, 10);
+  // CHECK-MESSAGES: :[[@LINE-1]]:14: warning: 'pi' may be set to null if 'realloc' fails, which may result in a leak of the original buffer [bugprone-suspicious-realloc-usage]
+
+  templ>(p);
+}
+
+void no_warn(void *p, P *p1, P *p2) {
+  void *q = realloc(p, 10);
+  q = realloc(p, 10);
+  p1->q = realloc(p1->p, 10);
+  p2->p = realloc(p1->p, 20);
+  n1::p = realloc(n2::p, 30);
+  p1->pp->p = realloc(p1->p, 10);
+  getPtr() = realloc(getPtr(), 30);
+  getP().p = realloc(getP().p, 20);
+  p1->f() = realloc(p1->f(), 30);
+}
+
+void no_warn_if_copy_exists_before1(void *p) {
+  void *q = p;
+  p = realloc(p, 111);
+}
+
+void no_warn_if_copy_exists_before2(void *p, void *q) {
+  q = p;
+  p = realloc(p, 111);
+}
+
+void *g_p;
+
+void no_warn_if_copy_exists_before3() {
+  void *q = g_p;
+  g_p = realloc(g_p, 111);
+}
+
+void warn_if_copy_exists_after(void *p) {
+  p = realloc(p, 111);
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: 'p' may be set to null if 'realloc' fails, which may result in a leak of the original buffer [bugprone-suspicious-realloc-usage]
+  void *q = p;
+}
Index: clang-tools-extra/docs/clang-tidy/checks/list.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/list.rst
+++ clang-tools-extra/docs/clang-tidy/checks/list.rst
@@ -124,6 +124,7 @@
`bugprone-suspicious-memory-comparison `_,
`bugprone-suspicious-memset-usage `_, "Yes"
`bugprone-suspicious-missing-comma `_,
+   `bugprone-suspicious-realloc-usage `_,
`bugprone-suspicious-semicolon `_, "Yes"
`bugprone-suspicious-string-compare `_, "Yes"
`bugprone-swapped-arguments `_, "Yes"
Index: clang-tools-extra/docs/clang-tidy/checks/bugprone/suspicious-realloc-usage.rst
===
--- /dev/null
+++ clang-tools-extra/docs/clang-tidy/checks/bugprone/suspicious-realloc-usage.rst
@@ -0,0 +1,44

[PATCH] D135011: Add builtin_elementwise_sin and builtin_elementwise_cos

2022-10-04 Thread Xiang Li via Phabricator via cfe-commits

python3kgae added a comment.

In D135011#3831452 , @craig.topper 
wrote:

> Does these support scalable vector types from ARM SVE or RISC-V? I can't 
> remember what the rest of the __builtin_elementwise do. I ask because the 
> backends will probably crash for them.

checkMathBuiltinElementType should stop scalable vector types in 
Sema::CheckBuiltinFunctionCall.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135011

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

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

2022-10-04 Thread Timm Bäder via Phabricator via cfe-commits

tbaeder added inline comments.



Comment at: clang/lib/AST/Interp/Floating.h:27-29
+  template  struct Repr;
+  template <> struct Repr<32> { using Type = float; };
+  template <> struct Repr<64> { using Type = double; };

jcranmer-intel wrote:
> tbaeder wrote:
> > jcranmer-intel wrote:
> > > aaron.ballman wrote:
> > > > Er, how will this extend to `long double` where the number of bits is 
> > > > rather more difficult?
> > > Or `half` and `bfloat`, which are both 16-bit floating-point types?
> > I have spent some time with this today and tried to simply always use 
> > `APFloat` instead of a primitive type. Unfortunately that doesn't work 
> > because what we put on the stack is not the `Floating` (or `Integral`), but 
> > the underlying primitive type. So even if we do the final math (in `::add`, 
> > etc) via `APFloat`, we need something we can serialize to `char[]` so we 
> > can put it on the stack. Do you think that would work?
> I don't know enough about the structure of the bytecode interpreter here to 
> say for sure, but this smells to me like you're baking in an assumption that 
> every primitive target type has a corresponding primitive type on the host. 
> This assumption just doesn't hold when it comes to floating point (only two 
> of the seven types, `float` and `double`, are generally portable, and even 
> then, there be dragons in some corner cases).
> 
> If you do need to continue down this route, there are two requirements that 
> should be upheld:
> * The representation shouldn't assume that the underlying primitive type 
> exists on host (bfloat16 and float128 are better test cases here).
> * Conversion to/from host primitive types shouldn't be easy to accidentally 
> do.
> 
> (Worth repeating again that bit size is insufficient to distinguish floating 
> point types: `bfloat` and `half` are both 16-bit, PPC `long double` and IEEE 
> 754 quad precision are both 128-bit, and x86 `long double` is 80 bits stored 
> as 96 bits on 32-bit and 128 bits on 64-bit.)
Well, is there a way to convert an APFloat to a char[] that would work instead 
of going to float/double and storing that? The only thing I see in the docs is 
`convertToHexString()` (and the docs don't mention whether the conversion is 
lossy). If not, do you think adding such a conversion to `APFloat` and its 
various implementations is the better way forward?


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

https://reviews.llvm.org/D134859

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

[PATCH] D135012: [clang][Interp] Implement bitwise and operations

2022-10-04 Thread Timm Bäder via Phabricator via cfe-commits

tbaeder updated this revision to Diff 464902.
tbaeder marked 2 inline comments as done.

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

https://reviews.llvm.org/D135012

Files:
  clang/lib/AST/Interp/ByteCodeExprGen.cpp
  clang/lib/AST/Interp/Integral.h
  clang/lib/AST/Interp/Interp.h
  clang/lib/AST/Interp/Opcodes.td
  clang/test/AST/Interp/literals.cpp

Index: clang/test/AST/Interp/literals.cpp
===
--- clang/test/AST/Interp/literals.cpp
+++ clang/test/AST/Interp/literals.cpp
@@ -280,3 +280,11 @@
  // expected-error {{invalid argument type 'float' to unary expression}}
 
 };
+
+namespace band {
+  static_assert((10 & 1) == 0, "");
+  static_assert((10 & 10) == 10, "");
+
+  static_assert((1337 & -1) == 1337, "");
+  static_assert((0 & gimme(12)) == 0, "");
+};
Index: clang/lib/AST/Interp/Opcodes.td
===
--- clang/lib/AST/Interp/Opcodes.td
+++ clang/lib/AST/Interp/Opcodes.td
@@ -109,6 +109,11 @@
   let HasGroup = 1;
 }
 
+class IntegerOpcode : Opcode {
+  let Types = [IntegerTypeClass];
+  let HasGroup = 1;
+}
+
 //===--===//
 // Jump opcodes
 //===--===//
@@ -417,10 +422,8 @@
 def Sub : AluOpcode;
 def Add : AluOpcode;
 def Mul : AluOpcode;
-def Rem : Opcode {
-  let Types = [IntegerTypeClass];
-  let HasGroup = 1;
-}
+def Rem : IntegerOpcode;
+def BitAnd : IntegerOpcode;
 def Div : Opcode {
   let Types = [NumberTypeClass];
   let HasGroup = 1;
Index: clang/lib/AST/Interp/Interp.h
===
--- clang/lib/AST/Interp/Interp.h
+++ clang/lib/AST/Interp/Interp.h
@@ -158,6 +158,23 @@
   return AddSubMulHelper(S, OpPC, Bits, LHS, RHS);
 }
 
+/// 1) Pops the RHS from the stack.
+/// 2) Pops the LHS from the stack.
+/// 3) Pushes 'LHS & RHS' on the stack
+template ::T>
+bool BitAnd(InterpState &S, CodePtr OpPC) {
+  const T &RHS = S.Stk.pop();
+  const T &LHS = S.Stk.pop();
+
+  unsigned Bits = RHS.bitWidth();
+  T Result;
+  if (!T::bitAnd(LHS, RHS, Bits, &Result)) {
+S.Stk.push(Result);
+return true;
+  }
+  return false;
+}
+
 /// 1) Pops the RHS from the stack.
 /// 2) Pops the LHS from the stack.
 /// 3) Pushes 'LHS % RHS' on the stack (the remainder of dividing LHS by RHS).
Index: clang/lib/AST/Interp/Integral.h
===
--- clang/lib/AST/Interp/Integral.h
+++ clang/lib/AST/Interp/Integral.h
@@ -212,6 +212,11 @@
 return false;
   }
 
+  static bool bitAnd(Integral A, Integral B, unsigned OpBits, Integral *R) {
+*R = Integral(A.V & B.V);
+return false;
+  }
+
   static bool neg(Integral A, Integral *R) {
 *R = -A;
 return false;
Index: clang/lib/AST/Interp/ByteCodeExprGen.cpp
===
--- clang/lib/AST/Interp/ByteCodeExprGen.cpp
+++ clang/lib/AST/Interp/ByteCodeExprGen.cpp
@@ -229,6 +229,11 @@
   if (!this->emitStore(*T, BO))
 return false;
   return DiscardResult ? this->emitPopPtr(BO) : true;
+case BO_And:
+  return Discard(this->emitBitAnd(*T, BO));
+case BO_Or:
+case BO_LAnd:
+case BO_LOr:
 default:
   return this->bail(BO);
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D134942: [Lex] Simplify and cleanup the updateConsecutiveMacroArgTokens implementation.

2022-10-04 Thread Haojian Wu via Phabricator via cfe-commits

hokein updated this revision to Diff 464905.
hokein added a comment.

update


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134942

Files:
  clang/lib/Lex/TokenLexer.cpp

Index: clang/lib/Lex/TokenLexer.cpp
===
--- clang/lib/Lex/TokenLexer.cpp
+++ clang/lib/Lex/TokenLexer.cpp
@@ -25,6 +25,7 @@
 #include "clang/Lex/Token.h"
 #include "clang/Lex/VariadicMacroSupport.h"
 #include "llvm/ADT/ArrayRef.h"
+#include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/SmallString.h"
 #include "llvm/ADT/SmallVector.h"
 #include "llvm/ADT/iterator_range.h"
@@ -989,60 +990,56 @@
 Token * end_tokens) {
   assert(begin_tokens < end_tokens);
 
-  SourceLocation FirstLoc = begin_tokens->getLocation();
-  SourceLocation CurLoc = FirstLoc;
-
-  // Compare the source location offset of tokens and group together tokens that
-  // are close, even if their locations point to different FileIDs. e.g.
-  //
-  //  |bar|  foo | cake   |  (3 tokens from 3 consecutive FileIDs)
-  //  ^^
-  //  |bar   foo   cake| (one SLocEntry chunk for all tokens)
-  //
-  // we can perform this "merge" since the token's spelling location depends
-  // on the relative offset.
-
-  Token *NextTok = begin_tokens + 1;
-  for (; NextTok < end_tokens; ++NextTok) {
-SourceLocation NextLoc = NextTok->getLocation();
-if (CurLoc.isFileID() != NextLoc.isFileID())
-  break; // Token from different kind of FileID.
-
-SourceLocation::IntTy RelOffs;
-if (!SM.isInSameSLocAddrSpace(CurLoc, NextLoc, &RelOffs))
-  break; // Token from different local/loaded location.
-// Check that token is not before the previous token or more than 50
-// "characters" away.
-if (RelOffs < 0 || RelOffs > 50)
-  break;
-
-if (CurLoc.isMacroID() && !SM.isWrittenInSameFile(CurLoc, NextLoc))
-  break; // Token from a different macro.
-
-CurLoc = NextLoc;
+  SourceLocation BeginLoc = begin_tokens->getLocation();
+  llvm::MutableArrayRef All(begin_tokens, end_tokens);
+  llvm::MutableArrayRef Partition;
+
+  // Partition the tokens by their FileID.
+  // This is a hot function, and calling getFileID can be expensive, the
+  // implementation is optimized by reducing the number of getFileID.
+  if (BeginLoc.isFileID()) {
+// We can avoid calling getFileID at all for *file* consecutive tokens --
+// for this case it is impossible to switch between files in marco arguments
+// (e.g. we can't use #include in marco arguments, and clang rejects it),
+// therefore these token must point to the same file.
+Partition = All.take_while([&](const Token &T) {
+  return T.getLocation().isFileID();
+});
+assert(
+!Partition.empty() &&
+llvm::all_of(Partition.drop_front(),
+ [&SM, ID = SM.getFileID(Partition.front().getLocation())](
+ const Token &T) {
+   return ID == SM.getFileID(T.getLocation());
+ }) &&
+"Must have the same FIleID!");
+  } else {
+// Call getFileID once to calculate the bounds, and use the cheaper
+// sourcelocation-against-bounds comparison.
+FileID BeginFID = SM.getFileID(BeginLoc);
+SourceLocation Limit =
+SM.getComposedLoc(BeginFID, SM.getFileIDSize(BeginFID));
+Partition = All.take_while([&](const Token &T) {
+  return T.getLocation() >= BeginLoc && T.getLocation() < Limit;
+});
   }
-
   // For the consecutive tokens, find the length of the SLocEntry to contain
   // all of them.
-  Token &LastConsecutiveTok = *(NextTok-1);
-  SourceLocation::IntTy LastRelOffs = 0;
-  SM.isInSameSLocAddrSpace(FirstLoc, LastConsecutiveTok.getLocation(),
-   &LastRelOffs);
   SourceLocation::UIntTy FullLength =
-  LastRelOffs + LastConsecutiveTok.getLength();
-
+  Partition.back().getEndLoc().getRawEncoding() -
+  Partition.begin()->getLocation().getRawEncoding();
   // Create a macro expansion SLocEntry that will "contain" all of the tokens.
   SourceLocation Expansion =
-  SM.createMacroArgExpansionLoc(FirstLoc, InstLoc,FullLength);
+  SM.createMacroArgExpansionLoc(BeginLoc, InstLoc, FullLength);
 
   // Change the location of the tokens from the spelling location to the new
   // expanded location.
-  for (; begin_tokens < NextTok; ++begin_tokens) {
-Token &Tok = *begin_tokens;
-SourceLocation::IntTy RelOffs = 0;
-SM.isInSameSLocAddrSpace(FirstLoc, Tok.getLocation(), &RelOffs);
-Tok.setLocation(Expansion.getLocWithOffset(RelOffs));
+  for (Token& T : Partition) {
+SourceLocation::IntTy RelativeOffset = T.getLocation().getRawEncoding() -
+   BeginLoc.getRawEncoding();
+T.setLocation(Expansion.getLocWithOffset(RelativeOffset));
   }
+  begin_tokens = &Partition.back() + 1;
 }
 
 /// Creat

[PATCH] D134942: [Lex] Simplify and cleanup the updateConsecutiveMacroArgTokens implementation.

2022-10-04 Thread Haojian Wu via Phabricator via cfe-commits

hokein added a comment.

In D134942#3828449 , @nickdesaulniers 
wrote:

> In D134942#3827216 , @hokein wrote:
>
>> Some more perf data on building linux kernel (x86_64)
>>
>> before: getFileID 2.4% (1.10% on `getFileIDSlow`)
>> after: getFileID 2.35% (1.05% on `getFileIDSlow`)
>
> What compiler was used as the bootstrap?
>
> For me bootstrapping w/ clang, I observed:
>
>   Before:
>   +2.11%  clang-15   [.] 
> clang::SourceManager::getFileIDLocal
>   After:
>   +2.01%  clang-15   [.] 
> clang::SourceManager::getFileIDLocal

That's interesting. I also used clang (v14) for bootstrapping.

What's your base revision? I'm using d32b8fdbdb4b99a5cc21604db6211fc506eb1f9b 
, looking 
at your profile (clang-15), I think your base revision is older than mine (my 
profile shows clang-16).




Comment at: clang/lib/Lex/TokenLexer.cpp:1008-1013
+assert(!Partition.empty() &&
+   llvm::all_of(Partition.drop_front(),
+[&SM](const Token &T) {
+  return SM.getFileID((&T - 1)->getLocation()) ==
+ SM.getFileID(T.getLocation());
+}) &&

nickdesaulniers wrote:
> Could you just check that all of the tokens in the partition have the same 
> fileID as the first token?
> 
> ```
> FileID FirstFID = SM.getFileID(Partition[0]->getLocation());
> llvm::all_of(Partition, [&SM, &FirstID](const Token &T) { return 
> SM.getFileID(T.getLocation() == FID; });
> ```
> or move the assertion into the take_while above so we iterate less?
The optimization for this case is that we don't call any `getFileID`, the 
getFileID is only needed in the assert sanity check, so moving the assertion to 
`take_while` doesn't really work.

I adjust the code to save some unnecessary `getFileID` call in assert.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134942

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

[PATCH] D133817: MSVC ABI: Looks like even non-aarch64 uses the MSVC/14 definition for pod/aggregate passing

2022-10-04 Thread Hans Wennborg via Phabricator via cfe-commits

hans added a comment.

> Right, we did have a record layout fuzzer which worked pretty well. I think 
> it only ever ran on a workstation, it relied on custom tools and the like. I 
> think it's lost to the sands of time.

(The code still exists: https://github.com/dberlin/superfuzz I've never run it 
though, so I don't know how much work that would take.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133817

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

[PATCH] D135132: [SourceManager] Improve getFileIDLocal.

2022-10-04 Thread Haojian Wu via Phabricator via cfe-commits

hokein created this revision.
hokein added reviewers: sammccall, nickdesaulniers.
Herald added a project: All.
hokein requested review of this revision.
Herald added a project: clang.

Prune the search space -- If we know offset(LastFileIDLookup) < SearchOffset, we
can prune the initial binary-search range from [0, end) to [LastFileIDlookup, 
end).

It reduces the binary search scan by ~30%.

SemaExpr.cpp:   1393437 -> 1035426
FindTarget.cpp: 1275930 -> 920087

Linux kernel:
getFileIDLocal: 2.45% -> 2.15%


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D135132

Files:
  clang/lib/Basic/SourceManager.cpp


Index: clang/lib/Basic/SourceManager.cpp
===
--- clang/lib/Basic/SourceManager.cpp
+++ clang/lib/Basic/SourceManager.cpp
@@ -790,15 +790,20 @@
 
   // See if this is near the file point - worst case we start scanning from the
   // most newly created FileID.
-  const SrcMgr::SLocEntry *I;
 
-  if (LastFileIDLookup.ID < 0 ||
-  LocalSLocEntryTable[LastFileIDLookup.ID].getOffset() < SLocOffset) {
-// Neither loc prunes our search.
-I = LocalSLocEntryTable.end();
-  } else {
-// Perhaps it is near the file point.
-I = LocalSLocEntryTable.begin()+LastFileIDLookup.ID;
+  // "I" is an iterator that points to a FileID whose offset is known to be
+  // larger than SLocOffset.
+  const SrcMgr::SLocEntry *I = LocalSLocEntryTable.end();
+  // LessIndex - This is the lower bound of the range that we're searching.
+  // We know that the offset corresponding to the FileID is is less than
+  // SLocOffset.
+  unsigned LessIndex = 0;
+  if (LastFileIDLookup.ID >= 0) {
+// Use the LastFileIDLookup to prune the search space.
+if (LocalSLocEntryTable[LastFileIDLookup.ID].getOffset() < SLocOffset)
+  LessIndex = LastFileIDLookup.ID;
+else
+  I = LocalSLocEntryTable.begin() + LastFileIDLookup.ID;
   }
 
   // Find the FileID that contains this.  "I" is an iterator that points to a
@@ -820,10 +825,6 @@
   // Convert "I" back into an index.  We know that it is an entry whose index 
is
   // larger than the offset we are looking for.
   unsigned GreaterIndex = I - LocalSLocEntryTable.begin();
-  // LessIndex - This is the lower bound of the range that we're searching.
-  // We know that the offset corresponding to the FileID is is less than
-  // SLocOffset.
-  unsigned LessIndex = 0;
   NumProbes = 0;
   while (true) {
 unsigned MiddleIndex = (GreaterIndex-LessIndex)/2+LessIndex;


Index: clang/lib/Basic/SourceManager.cpp
===
--- clang/lib/Basic/SourceManager.cpp
+++ clang/lib/Basic/SourceManager.cpp
@@ -790,15 +790,20 @@
 
   // See if this is near the file point - worst case we start scanning from the
   // most newly created FileID.
-  const SrcMgr::SLocEntry *I;
 
-  if (LastFileIDLookup.ID < 0 ||
-  LocalSLocEntryTable[LastFileIDLookup.ID].getOffset() < SLocOffset) {
-// Neither loc prunes our search.
-I = LocalSLocEntryTable.end();
-  } else {
-// Perhaps it is near the file point.
-I = LocalSLocEntryTable.begin()+LastFileIDLookup.ID;
+  // "I" is an iterator that points to a FileID whose offset is known to be
+  // larger than SLocOffset.
+  const SrcMgr::SLocEntry *I = LocalSLocEntryTable.end();
+  // LessIndex - This is the lower bound of the range that we're searching.
+  // We know that the offset corresponding to the FileID is is less than
+  // SLocOffset.
+  unsigned LessIndex = 0;
+  if (LastFileIDLookup.ID >= 0) {
+// Use the LastFileIDLookup to prune the search space.
+if (LocalSLocEntryTable[LastFileIDLookup.ID].getOffset() < SLocOffset)
+  LessIndex = LastFileIDLookup.ID;
+else
+  I = LocalSLocEntryTable.begin() + LastFileIDLookup.ID;
   }
 
   // Find the FileID that contains this.  "I" is an iterator that points to a
@@ -820,10 +825,6 @@
   // Convert "I" back into an index.  We know that it is an entry whose index is
   // larger than the offset we are looking for.
   unsigned GreaterIndex = I - LocalSLocEntryTable.begin();
-  // LessIndex - This is the lower bound of the range that we're searching.
-  // We know that the offset corresponding to the FileID is is less than
-  // SLocOffset.
-  unsigned LessIndex = 0;
   NumProbes = 0;
   while (true) {
 unsigned MiddleIndex = (GreaterIndex-LessIndex)/2+LessIndex;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D135110: [NFC] [HLSL] Move common metadata to LLVMFrontend

2022-10-04 Thread Thorsten via Phabricator via cfe-commits

tschuett added a comment.

The OpenMP frontend is mainly an IRBuilder. It is a different layering than for 
HLSL. Are there plans for an HLSL(IR)Builder?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135110

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

[PATCH] D134788: [ARM64EC][clang-cl] Add arm64EC test; NFC

2022-10-04 Thread chenglin.bi via Phabricator via cfe-commits

bcl5980 updated this revision to Diff 464909.
bcl5980 retitled this revision from "[ARM64EC][clang-cl] Add /arm64EC flag" to 
"[ARM64EC][clang-cl] Add arm64EC test; NFC".

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

https://reviews.llvm.org/D134788

Files:
  clang/test/Driver/cl-options.c


Index: clang/test/Driver/cl-options.c
===
--- clang/test/Driver/cl-options.c
+++ clang/test/Driver/cl-options.c
@@ -782,8 +782,11 @@
 // EXTERNAL_W0: "-Wno-system-headers"
 // EXTERNAL_Wn: "-Wsystem-headers"
 
-// RUN: %clang_cl -vctoolsdir "" /arm64EC /c -### -- %s 2>&1 | FileCheck %s 
--check-prefix ARM64EC
-// ARM64EC: "-triple" "arm64ec-pc-windows-msvc19.20.0"
+// RUN: %clang_cl -vctoolsdir "" /arm64EC /c -### -- %s 2>&1 | FileCheck 
--check-prefix=ARM64EC %s 
 // ARM64EC-NOT: /arm64EC has been overridden by specified target
+// ARM64EC: "-triple" "arm64ec-pc-windows-msvc19.20.0"
+
+// RUN: %clang_cl -vctoolsdir "" /arm64EC /c -target x86_64-pc-windows-msvc  
-### -- %s 2>&1 | FileCheck --check-prefix=ARM64EC_OVERRIDE %s
+// ARM64EC_OVERRIDE: warning: /arm64EC has been overridden by specified 
target: x86_64-pc-windows-msvc; option ignored
 
 void f(void) { }


Index: clang/test/Driver/cl-options.c
===
--- clang/test/Driver/cl-options.c
+++ clang/test/Driver/cl-options.c
@@ -782,8 +782,11 @@
 // EXTERNAL_W0: "-Wno-system-headers"
 // EXTERNAL_Wn: "-Wsystem-headers"
 
-// RUN: %clang_cl -vctoolsdir "" /arm64EC /c -### -- %s 2>&1 | FileCheck %s --check-prefix ARM64EC
-// ARM64EC: "-triple" "arm64ec-pc-windows-msvc19.20.0"
+// RUN: %clang_cl -vctoolsdir "" /arm64EC /c -### -- %s 2>&1 | FileCheck --check-prefix=ARM64EC %s 
 // ARM64EC-NOT: /arm64EC has been overridden by specified target
+// ARM64EC: "-triple" "arm64ec-pc-windows-msvc19.20.0"
+
+// RUN: %clang_cl -vctoolsdir "" /arm64EC /c -target x86_64-pc-windows-msvc  -### -- %s 2>&1 | FileCheck --check-prefix=ARM64EC_OVERRIDE %s
+// ARM64EC_OVERRIDE: warning: /arm64EC has been overridden by specified target: x86_64-pc-windows-msvc; option ignored
 
 void f(void) { }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D135025: [clang][Interp] Support base class constructors

2022-10-04 Thread Timm Bäder via Phabricator via cfe-commits

tbaeder updated this revision to Diff 464913.

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

https://reviews.llvm.org/D135025

Files:
  clang/lib/AST/Interp/ByteCodeExprGen.cpp
  clang/lib/AST/Interp/ByteCodeStmtGen.cpp
  clang/test/AST/Interp/records.cpp

Index: clang/test/AST/Interp/records.cpp
===
--- clang/test/AST/Interp/records.cpp
+++ clang/test/AST/Interp/records.cpp
@@ -1,9 +1,6 @@
 // RUN: %clang_cc1 -fexperimental-new-constant-interpreter -verify %s
 // RUN: %clang_cc1 -verify=ref %s
 
-// ref-no-diagnostics
-// expected-no-diagnostics
-
 struct BoolPair {
   bool first;
   bool second;
@@ -157,3 +154,57 @@
 static_assert(LT2.v[0].second == false, "");
 static_assert(LT2.v[2].first == true, "");
 static_assert(LT2.v[2].second == false, "");
+
+class Base {
+public:
+  int i;
+  constexpr Base() : i(10) {}
+  constexpr Base(int i) : i(i) {}
+};
+
+class A : public Base {
+public:
+  constexpr A() : Base(100) {}
+  constexpr A(int a) : Base(a) {}
+};
+constexpr A a{};
+static_assert(a.i == 100, "");
+constexpr A a2{12};
+static_assert(a2.i == 12, "");
+static_assert(a2.i == 200, ""); // ref-error {{static assertion failed}} \
+// ref-note {{evaluates to '12 == 200'}} \
+// expected-error {{static assertion failed}} \
+// expected-note {{evaluates to '12 == 200'}}
+
+namespace MI {
+  class A {
+  public:
+int a;
+constexpr A(int a) : a(a) {}
+  };
+
+  class B {
+  public:
+int b;
+constexpr B(int b) : b(b) {}
+  };
+
+  class C : public A, public B {
+  public:
+constexpr C() : A(10), B(20) {}
+  };
+  constexpr C c = {};
+  static_assert(c.a == 10);
+  static_assert(c.b == 20);
+
+
+  class D : private A, private B {
+public:
+constexpr D() : A(20), B(30) {}
+constexpr int getA() const { return a; }
+constexpr int getB() const { return b; }
+  };
+  constexpr D d = {};
+  static_assert(d.getA() == 20);
+  static_assert(d.getB() == 30);
+};
Index: clang/lib/AST/Interp/ByteCodeStmtGen.cpp
===
--- clang/lib/AST/Interp/ByteCodeStmtGen.cpp
+++ clang/lib/AST/Interp/ByteCodeStmtGen.cpp
@@ -100,31 +100,45 @@
 const Record *R = this->getRecord(RD);
 
 for (const auto *Init : Ctor->inits()) {
-  const FieldDecl *Member = Init->getMember();
   const Expr *InitExpr = Init->getInit();
-  const Record::Field *F = R->getField(Member);
-
-  if (Optional T = this->classify(InitExpr->getType())) {
-if (!this->emitThis(InitExpr))
-  return false;
-
-if (!this->visit(InitExpr))
-  return false;
-
-if (!this->emitInitField(*T, F->Offset, InitExpr))
+  if (const FieldDecl *Member = Init->getMember()) {
+const Record::Field *F = R->getField(Member);
+
+if (Optional T = this->classify(InitExpr->getType())) {
+  if (!this->emitThis(InitExpr))
+return false;
+
+  if (!this->visit(InitExpr))
+return false;
+
+  if (!this->emitInitField(*T, F->Offset, InitExpr))
+return false;
+} else {
+  // Non-primitive case. Get a pointer to the field-to-initialize
+  // on the stack and call visitInitialzer() for it.
+  if (!this->emitThis(InitExpr))
+return false;
+
+  if (!this->emitGetPtrField(F->Offset, InitExpr))
+return false;
+
+  if (!this->visitInitializer(InitExpr))
+return false;
+
+  if (!this->emitPopPtr(InitExpr))
+return false;
+}
+  } else if (const Type *Base = Init->getBaseClass()) {
+// Base class initializer.
+// Get This Base and call initializer on it.
+auto *BaseDecl = Base->getAsCXXRecordDecl();
+assert(BaseDecl);
+const Record::Base *B = R->getBase(BaseDecl);
+assert(B);
+if (!this->emitGetPtrThisBase(B->Offset, InitExpr))
   return false;
-  } else {
-// Non-primitive case. Get a pointer to the field-to-initialize
-// on the stack and call visitInitialzer() for it.
-if (!this->emitThis(InitExpr))
-  return false;
-
-if (!this->emitGetPtrField(F->Offset, InitExpr))
-  return false;
-
 if (!this->visitInitializer(InitExpr))
   return false;
-
 if (!this->emitPopPtr(InitExpr))
   return false;
   }
Index: clang/lib/AST/Interp/ByteCodeExprGen.cpp
===
--- clang/lib/AST/Interp/ByteCodeExprGen.cpp
+++ clang/lib/AST/Interp/ByteCodeExprGen.cpp
@@ -107,6 +107,21 @@
 });
   }
 
+  case CK_UncheckedDerivedToBase: {
+if (!this->visit(SubExpr))
+  return false;
+
+const CXXRecordDecl *FromDecl = getRecordDecl(SubExpr);
+assert(FromDecl);
+const CXXRecor

[PATCH] D135025: [clang][Interp] Support base class constructors

2022-10-04 Thread Timm Bäder via Phabricator via cfe-commits

tbaeder updated this revision to Diff 464915.

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

https://reviews.llvm.org/D135025

Files:
  clang/lib/AST/Interp/ByteCodeExprGen.cpp
  clang/lib/AST/Interp/ByteCodeExprGen.h
  clang/lib/AST/Interp/ByteCodeStmtGen.cpp
  clang/test/AST/Interp/records.cpp

Index: clang/test/AST/Interp/records.cpp
===
--- clang/test/AST/Interp/records.cpp
+++ clang/test/AST/Interp/records.cpp
@@ -1,9 +1,6 @@
 // RUN: %clang_cc1 -fexperimental-new-constant-interpreter -verify %s
 // RUN: %clang_cc1 -verify=ref %s
 
-// ref-no-diagnostics
-// expected-no-diagnostics
-
 struct BoolPair {
   bool first;
   bool second;
@@ -157,3 +154,57 @@
 static_assert(LT2.v[0].second == false, "");
 static_assert(LT2.v[2].first == true, "");
 static_assert(LT2.v[2].second == false, "");
+
+class Base {
+public:
+  int i;
+  constexpr Base() : i(10) {}
+  constexpr Base(int i) : i(i) {}
+};
+
+class A : public Base {
+public:
+  constexpr A() : Base(100) {}
+  constexpr A(int a) : Base(a) {}
+};
+constexpr A a{};
+static_assert(a.i == 100, "");
+constexpr A a2{12};
+static_assert(a2.i == 12, "");
+static_assert(a2.i == 200, ""); // ref-error {{static assertion failed}} \
+// ref-note {{evaluates to '12 == 200'}} \
+// expected-error {{static assertion failed}} \
+// expected-note {{evaluates to '12 == 200'}}
+
+namespace MI {
+  class A {
+  public:
+int a;
+constexpr A(int a) : a(a) {}
+  };
+
+  class B {
+  public:
+int b;
+constexpr B(int b) : b(b) {}
+  };
+
+  class C : public A, public B {
+  public:
+constexpr C() : A(10), B(20) {}
+  };
+  constexpr C c = {};
+  static_assert(c.a == 10);
+  static_assert(c.b == 20);
+
+
+  class D : private A, private B {
+public:
+constexpr D() : A(20), B(30) {}
+constexpr int getA() const { return a; }
+constexpr int getB() const { return b; }
+  };
+  constexpr D d = {};
+  static_assert(d.getA() == 20);
+  static_assert(d.getB() == 30);
+};
Index: clang/lib/AST/Interp/ByteCodeStmtGen.cpp
===
--- clang/lib/AST/Interp/ByteCodeStmtGen.cpp
+++ clang/lib/AST/Interp/ByteCodeStmtGen.cpp
@@ -100,31 +100,45 @@
 const Record *R = this->getRecord(RD);
 
 for (const auto *Init : Ctor->inits()) {
-  const FieldDecl *Member = Init->getMember();
   const Expr *InitExpr = Init->getInit();
-  const Record::Field *F = R->getField(Member);
-
-  if (Optional T = this->classify(InitExpr->getType())) {
-if (!this->emitThis(InitExpr))
-  return false;
-
-if (!this->visit(InitExpr))
-  return false;
-
-if (!this->emitInitField(*T, F->Offset, InitExpr))
+  if (const FieldDecl *Member = Init->getMember()) {
+const Record::Field *F = R->getField(Member);
+
+if (Optional T = this->classify(InitExpr->getType())) {
+  if (!this->emitThis(InitExpr))
+return false;
+
+  if (!this->visit(InitExpr))
+return false;
+
+  if (!this->emitInitField(*T, F->Offset, InitExpr))
+return false;
+} else {
+  // Non-primitive case. Get a pointer to the field-to-initialize
+  // on the stack and call visitInitialzer() for it.
+  if (!this->emitThis(InitExpr))
+return false;
+
+  if (!this->emitGetPtrField(F->Offset, InitExpr))
+return false;
+
+  if (!this->visitInitializer(InitExpr))
+return false;
+
+  if (!this->emitPopPtr(InitExpr))
+return false;
+}
+  } else if (const Type *Base = Init->getBaseClass()) {
+// Base class initializer.
+// Get This Base and call initializer on it.
+auto *BaseDecl = Base->getAsCXXRecordDecl();
+assert(BaseDecl);
+const Record::Base *B = R->getBase(BaseDecl);
+assert(B);
+if (!this->emitGetPtrThisBase(B->Offset, InitExpr))
   return false;
-  } else {
-// Non-primitive case. Get a pointer to the field-to-initialize
-// on the stack and call visitInitialzer() for it.
-if (!this->emitThis(InitExpr))
-  return false;
-
-if (!this->emitGetPtrField(F->Offset, InitExpr))
-  return false;
-
 if (!this->visitInitializer(InitExpr))
   return false;
-
 if (!this->emitPopPtr(InitExpr))
   return false;
   }
Index: clang/lib/AST/Interp/ByteCodeExprGen.h
===
--- clang/lib/AST/Interp/ByteCodeExprGen.h
+++ clang/lib/AST/Interp/ByteCodeExprGen.h
@@ -256,6 +256,16 @@
 return (*InitFn)();
   }
 
+  /// Returns the CXXRecordDecl for the type of the given expression,
+  /// or nullptr if no such decl exists.
+  CXXRecordDecl * getRecordDecl(co

[PATCH] D130513: [Flang] Add -fconvert option to swap endianness for unformatted files

2022-10-04 Thread Jean Perier via Phabricator via cfe-commits

jeanPerier accepted this revision.
jeanPerier added a comment.

In D130513#3832241 , @jpenix-quic 
wrote:

> Thank you @jeanPerier for looking over the lowering portion! Regarding moving 
> the header (I'm replying to the comment here since the inline one now opens 
> in a separate revision/window as the file is gone), I moved it to 
> Lower/EnvironmentDefault.h as lowering is where I use it (as you mentioned). 
> Please let me know if this needs further changes!

LGTM, thanks.


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

https://reviews.llvm.org/D130513

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

[PATCH] D133578: [OpenMP][OMPIRBuilder] Add generation of SIMD align assumptions to OMPIRBuilder

2022-10-04 Thread Dominik Adamski via Phabricator via cfe-commits

domada updated this revision to Diff 464924.
domada added a comment.

Add assert to ensure that alignment value is always specified.


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

https://reviews.llvm.org/D133578

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

Index: mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp
===
--- mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp
+++ mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp
@@ -996,7 +996,8 @@
   if (llvm::Optional safelenVar = loop.getSafelen())
 safelen = builder.getInt64(safelenVar.value());
 
-  ompBuilder->applySimd(loopInfo,
+  llvm::DenseMap alignedVars;
+  ompBuilder->applySimd(loopInfo, alignedVars,
 loop.getIfExpr()
 ? moduleTranslation.lookupValue(loop.getIfExpr())
 : nullptr,
Index: llvm/unittests/Frontend/OpenMPIRBuilderTest.cpp
===
--- llvm/unittests/Frontend/OpenMPIRBuilderTest.cpp
+++ llvm/unittests/Frontend/OpenMPIRBuilderTest.cpp
@@ -1767,11 +1767,12 @@
 
 TEST_F(OpenMPIRBuilderTest, ApplySimd) {
   OpenMPIRBuilder OMPBuilder(*M);
-
+  DenseMap AlignedVars;
   CanonicalLoopInfo *CLI = buildSingleLoopFunction(DL, OMPBuilder, 32);
 
   // Simd-ize the loop.
-  OMPBuilder.applySimd(CLI, /* IfCond */ nullptr, /* Simdlen */ nullptr,
+  OMPBuilder.applySimd(CLI, AlignedVars,
+   /* IfCond */ nullptr, /* Simdlen */ nullptr,
/* Safelen */ nullptr);
 
   OMPBuilder.finalize();
@@ -1797,13 +1798,83 @@
   }));
 }
 
-TEST_F(OpenMPIRBuilderTest, ApplySimdlen) {
+TEST_F(OpenMPIRBuilderTest, ApplySimdCustomAligned) {
   OpenMPIRBuilder OMPBuilder(*M);
+  IRBuilder<> Builder(BB);
+  const int AlignmentValue = 32;
+  AllocaInst *Alloc1 =
+  Builder.CreateAlloca(Builder.getInt8PtrTy(), Builder.getInt64(1));
+  AllocaInst *Alloc2 = Builder.CreateAlloca(
+  ArrayType::get(Builder.getInt32Ty(), 10), Builder.getInt64(1));
+  DenseMap AlignedVars;
+  auto Int8Ty = Builder.getInt8Ty();
+  Instruction *MallocInstr = CallInst::CreateMalloc(
+  Alloc2, Builder.getInt64Ty(), Int8Ty, ConstantExpr::getSizeOf(Int8Ty),
+  Builder.getInt64(400), nullptr, "");
+  Builder.CreateStore(MallocInstr, Alloc1);
+
+  AlignedVars.insert({Alloc1, Builder.getInt64(AlignmentValue)});
+  AlignedVars.insert({Alloc2, Builder.getInt64(AlignmentValue)});
 
   CanonicalLoopInfo *CLI = buildSingleLoopFunction(DL, OMPBuilder, 32);
 
   // Simd-ize the loop.
-  OMPBuilder.applySimd(CLI, /* IfCond */ nullptr,
+  OMPBuilder.applySimd(CLI, AlignedVars,
+   /* IfCond */ nullptr, /* Simdlen */ nullptr,
+   /* Safelen */ nullptr);
+
+  OMPBuilder.finalize();
+  EXPECT_FALSE(verifyModule(*M, &errs()));
+
+  PassBuilder PB;
+  FunctionAnalysisManager FAM;
+  PB.registerFunctionAnalyses(FAM);
+  LoopInfo &LI = FAM.getResult(*F);
+
+  const std::vector &TopLvl = LI.getTopLevelLoops();
+  EXPECT_EQ(TopLvl.size(), 1u);
+
+  Loop *L = TopLvl.front();
+  EXPECT_TRUE(findStringMetadataForLoop(L, "llvm.loop.parallel_accesses"));
+  EXPECT_TRUE(getBooleanLoopAttribute(L, "llvm.loop.vectorize.enable"));
+
+  // Check for llvm.access.group metadata attached to the printf
+  // function in the loop body.
+  BasicBlock *LoopBody = CLI->getBody();
+  EXPECT_TRUE(any_of(*LoopBody, [](Instruction &I) {
+return I.getMetadata("llvm.access.group") != nullptr;
+  }));
+
+  // Check if number of assumption instructions is equal to number of aligned
+  // variables
+  BasicBlock *LoopPreheader = CLI->getPreheader();
+  size_t NumAssummptionCallsInPreheader = count_if(
+  *LoopPreheader, [](Instruction &I) { return isa(I); });
+  EXPECT_EQ(NumAssummptionCallsInPreheader, AlignedVars.size());
+
+  // Check if variables are correctly aligned
+  for (auto &Instr : LoopPreheader->getInstList()) {
+if (isa(Instr)) {
+  auto AssumeInstruction = dyn_cast(&Instr);
+  if (AssumeInstruction->getNumTotalBundleOperands()) {
+auto Bundle = AssumeInstruction->getOperandBundleAt(0);
+if (Bundle.getTagName() == "align") {
+  EXPECT_TRUE(isa(Bundle.Inputs[1]));
+  auto ConstIntVal = dyn_cast(Bundle.Inputs[1]);
+  EXPECT_EQ(ConstIntVal->getSExtValue(), AlignmentValue);
+}
+  }
+}
+  }
+}
+TEST_F(OpenMPIRBuilderTest, ApplySimdlen) {
+  OpenMPIRBuilder OMPBuilder(*M);
+  DenseMap AlignedVars;
+  CanonicalLoopInfo *CLI = buildSingleLoopFunction(DL, OMPBuilder, 32);
+
+  // Simd-ize the loop.
+  OMPBuilder.applySimd(CLI, AlignedVars,
+   /* IfCond */ nullptr,

[PATCH] D135136: [analyzer] Make directly bounded LazyCompoundVal as lazily copied

2022-10-04 Thread Balázs Benics via Phabricator via cfe-commits

steakhal created this revision.
steakhal added reviewers: NoQ, martong, xazax.hun.
Herald added subscribers: manas, ASDenysPetrov, dkrupp, donat.nagy, Szelethus, 
mikhail.ramalho, a.sidorin, rnkovacs, szepet, baloghadamsoftware.
Herald added a reviewer: Szelethus.
Herald added a project: All.
steakhal requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Previously, `LazyCompoundVal` bindings to subregions referred by
`LazyCopoundVals`, were not marked as //lazily copied//.

This change returns `LazyCompoundVals` from `getInterestingValues()`,
so their regions can be marked as //lazily copied// in 
`RemoveDeadBindingsWorker::VisitBinding()`.

Depends on D134947 

Authored by: Tomasz Kamiński 


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D135136

Files:
  clang/lib/StaticAnalyzer/Core/RegionStore.cpp
  clang/test/Analysis/trivial-copy-struct.cpp

Index: clang/test/Analysis/trivial-copy-struct.cpp
===
--- clang/test/Analysis/trivial-copy-struct.cpp
+++ clang/test/Analysis/trivial-copy-struct.cpp
@@ -92,9 +92,9 @@
   }
   if (!n->next) {
 if (w->head.next) {
-  // FIXME: Unreachable, w->head is a copy of *n, therefore
+  // Unreachable, w->head is a copy of *n, therefore
   // w->head.next and n->next are equal
-  clang_analyzer_warnIfReached(); // expected-warning {{REACHABLE}}
+  clang_analyzer_warnIfReached(); // unreachable
 }
   }
   delete w;
Index: clang/lib/StaticAnalyzer/Core/RegionStore.cpp
===
--- clang/lib/StaticAnalyzer/Core/RegionStore.cpp
+++ clang/lib/StaticAnalyzer/Core/RegionStore.cpp
@@ -608,6 +608,10 @@
   /// The precise value of "interesting" is determined for the purposes of
   /// RegionStore's internal analysis. It must always contain all regions and
   /// symbols, but may omit constants and other kinds of SVal.
+  ///
+  /// In contrast to compound values, LazyCompoundVals are also added
+  /// to the 'interesting values' list in addition to the child interesting
+  /// values.
   const SValListTy &getInterestingValues(nonloc::LazyCompoundVal LCV);
 
   //===--===//
@@ -1032,12 +1036,11 @@
   if (Optional LCS =
   V.getAs()) {
 
-const RegionStoreManager::SValListTy &Vals = RM.getInterestingValues(*LCS);
-
-for (RegionStoreManager::SValListTy::const_iterator I = Vals.begin(),
-E = Vals.end();
- I != E; ++I)
-  VisitBinding(*I);
+// `getInterestingValues()` returns SVals contained within LazyCompoundVals,
+// so there is no need to visit them.
+for (SVal V : RM.getInterestingValues(*LCS))
+  if (!isa(V))
+VisitBinding(V);
 
 return;
   }
@@ -1290,15 +1293,10 @@
 if (Optional LCS =
 V.getAs()) {
 
-  const SValListTy &Vals = getInterestingValues(*LCS);
-
-  for (SValListTy::const_iterator I = Vals.begin(),
-  E = Vals.end(); I != E; ++I) {
-// Note: the last argument is false here because these are
-// non-top-level regions.
-if (const MemRegion *R = (*I).getAsRegion())
+  for (SVal S : getInterestingValues(*LCS))
+if (const MemRegion *R = S.getAsRegion())
   W.AddToWorkList(R);
-  }
+
   continue;
 }
 
@@ -2283,11 +2281,9 @@
 if (V.isUnknownOrUndef() || V.isConstant())
   continue;
 
-if (Optional InnerLCV =
-V.getAs()) {
+if (auto InnerLCV = V.getAs()) {
   const SValListTy &InnerList = getInterestingValues(*InnerLCV);
   List.insert(List.end(), InnerList.begin(), InnerList.end());
-  continue;
 }
 
 List.push_back(V);
@@ -2829,20 +2825,17 @@
 }
 
 void RemoveDeadBindingsWorker::VisitBinding(SVal V) {
-  // Is it a LazyCompoundVal?  All referenced regions are live as well.
-  if (Optional LCS =
-  V.getAs()) {
-// TODO: Make regions referred to by `lazyCompoundVals` that are bound to
-// subregions of the `LCS.getRegion()` also lazily copied.
-if (const MemRegion *R = LCS->getRegion())
-  SymReaper.markLazilyCopied(R);
-
-const RegionStoreManager::SValListTy &Vals = RM.getInterestingValues(*LCS);
-
-for (RegionStoreManager::SValListTy::const_iterator I = Vals.begin(),
-E = Vals.end();
- I != E; ++I)
-  VisitBinding(*I);
+  // Is it a LazyCompoundVal? All referenced regions are live as well.
+  // The LazyCompoundVal itself is not live but should be readable.
+  if (auto LCS = V.getAs()) {
+SymReaper.markLazilyCopied(LCS->getRegion());
+
+for (SVal V : RM.getInterestingValues(*LCS)) {
+  if (auto DepLCS = V.getAs())
+SymReaper.markLazilyCopied(DepLCS->getRegion());
+  else

[PATCH] D134947: [analyzer] Fix liveness of Symbols for values in regions reffered by LazyCompoundVal

2022-10-04 Thread Balázs Benics via Phabricator via cfe-commits

steakhal added a comment.

First of all, thanks for the feedback!

In D134947#3830995 , @xazax.hun wrote:

> If we end up going with this approach, I wonder if it would be a great time 
> to update some of the docs here: 
> https://clang.llvm.org/docs/analyzer/developer-docs/RegionStore.html
> Usually, we are not doing a great job keeping these documentations up to 
> date. I think the logic to determine which symbols and regions are live and 
> how that logic interacts with the different types of memory regions might be 
> important enough to have some documentation on it.

Yes, I'll post a patch addressing this. Thanks for noting.

---

In D134947#3832130 , @NoQ wrote:

> Wow thanks!!
>
> Yeah this matches my understanding of the problem. I still encourage you to 
> test it on real-world code before committing, and carefully investigate every 
> change in diagnostics, because symbol reaper is very convoluted and filled 
> with insane cornercases.

That's true. We did a careful investigation and the numbers are promising even 
at large scale.
The upside is that even if it broke something, it does not have a significant 
impact. The downside is that we wished for greater improvement/impact by fixing 
this.

> [...] carefully investigate every change in diagnostics, [...]

I investigated multiple cases, out of which I believe all of them were 
intentionally affected, hence improved.
Note that however, I did not investigate all the changes but only a handful of 
a (representative) set due to the nature of collecting, minimizing, and 
understanding the reports is really time-consuming.

I'd like to proceed with this patch as-is. And possibly land further 
incremental step(s) on top of this, such as D135136 
.
Other than D135136  though, we don't plan to 
push this area any further for the time being.




Comment at: clang/lib/StaticAnalyzer/Core/SymbolManager.cpp:461
+bool SymbolReaper::isLazilyCopiedRegion(const MemRegion *MR) const {
+  // TODO: See comment in isLiveRegion.
+  return LazilyCopiedRegionRoots.count(MR->getBaseRegion());

NoQ wrote:
> tomasz-kaminski-sonarsource wrote:
> > martong wrote:
> > > Just out of curiosity, do you have plans to tackle this todo sometime?
> > We do not plan to takle it in near future.
> Could you add a negative/FIXME test for it?
> 
> At a glance I suspect that this TODO is significantly less important for 
> `isLiveRegion()` than it is for your new function, so I encourage you to 
> explore the possibility of dropping `getBaseRegion()`, even if just a little 
> bit and doesn't have to be in this patch.
> 
> If a smaller subregion is truly live, any value inside of the base region can 
> theoretically be accessed through safe pointer arithmetic. It's very 
> difficult to prove that it can't be accessed anymore. Every pointer escape 
> will be a potential access.
> 
> In your case, however, if the superregion is neither live nor lazily copied, 
> the information outside of the lazily copied subregion is truly lost, there's 
> literally nothing the program can do to recover it.
> Could you add a negative/FIXME test for it?
> 
> At a glance I suspect that this TODO is significantly less important for 
> `isLiveRegion()` than it is for your new function, so I encourage you to 
> explore the possibility of dropping `getBaseRegion()`, even if just a little 
> bit and doesn't have to be in this patch.
So far we could not come up with a test case demonstrating this case.
Right now we don't plan to investigate this area either in the foreseeable 
future.



Comment at: clang/test/Analysis/trivial-copy-struct.cpp:98
+  // w->head.next and n->next are equal
+  clang_analyzer_warnIfReached(); // expected-warning {{REACHABLE}}
+}

tomasz-kaminski-sonarsource wrote:
> NoQ wrote:
> > martong wrote:
> > > 
> > Do you know what's causing this to not work? Is this a regression or just 
> > never worked?
> This example never worked. We have an in-progress fix, that we are testing 
> now.
Fixed by D135136.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134947

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

[PATCH] D135136: [analyzer] Make directly bounded LazyCompoundVal as lazily copied

2022-10-04 Thread Balázs Benics via Phabricator via cfe-commits

steakhal added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/RegionStore.cpp:2290
   List.insert(List.end(), InnerList.begin(), InnerList.end());
-  continue;
 }

Here is the `continue` which previously prevented `getInterestingValues()` 
returning a list containing `LazyCompoundVals`. Now, we actually want them to 
be able to mark them as //lazily copied// as described in the summary.
I'm just highlighting this, as when I reviewed this change it did not 
immediately stand out.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135136

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

[PATCH] D132855: [OpenMP] Extend the lit test for uses_allocators in target region

2022-10-04 Thread Animesh Kumar via Phabricator via cfe-commits

animeshk-amd updated this revision to Diff 464932.
animeshk-amd added a comment.

Rebased the patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132855

Files:
  clang/test/OpenMP/target_map_codegen_10.cpp
  clang/test/OpenMP/target_uses_allocators.c

Index: clang/test/OpenMP/target_uses_allocators.c
===
--- clang/test/OpenMP/target_uses_allocators.c
+++ clang/test/OpenMP/target_uses_allocators.c
@@ -1,9 +1,8 @@
 // Test host codegen.
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-version=50  -triple powerpc64le-unknown-unknown -fopenmp-targets=powerpc64le-ibm-linux-gnu -emit-llvm %s -o - | FileCheck %s --check-prefix CHECK --check-prefix CHECK-64
-// RUN: %clang_cc1 -fopenmp -fopenmp-version=50 -x c++ -triple powerpc64le-unknown-unknown -fopenmp-targets=powerpc64le-ibm-linux-gnu -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-version=50 -x c++ -triple powerpc64le-unknown-unknown -fopenmp-targets=powerpc64le-ibm-linux-gnu
+// RUN: %clang_cc1 -verify -fopenmp -fopenmp-version=50  -triple powerpc64le-unknown-unknown -fopenmp-targets=powerpc64le-ibm-linux-gnu -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -fopenmp -fopenmp-version=50 -x c++ -triple powerpc64le-unknown-unknown -fopenmp-targets=powerpc64le-ibm-linux-gnu -verify -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp -fopenmp-version=50 -x c++ -triple powerpc64le-unknown-unknown -fopenmp-targets=powerpc64le-ibm-linux-gnu -include-pch %t %s -emit-llvm -o - | FileCheck %s
 
-// expected-no-diagnostics
 #ifndef HEADER
 #define HEADER
 
@@ -39,6 +38,71 @@
   {}
   #pragma omp target uses_allocators(omp_pteam_mem_alloc) allocate(omp_pteam_mem_alloc: x) firstprivate(x)
   {}
+  #pragma omp target uses_allocators(omp_thread_mem_alloc) allocate(omp_thread_mem_alloc: x) firstprivate(x) // expected-warning {{allocator with the 'thread' trait access has unspecified behavior on 'target' directive}}
+  {}
 }
 
 #endif
+
+// CHECK: %[[#R0:]] = call i32 @__kmpc_global_thread_num(ptr @1)
+// CHECK-NEXT: store i64 %x, ptr %x.addr, align 8
+// CHECK-NEXT: %.x..void.addr = call ptr @__kmpc_alloc(i32 %[[#R0]], i64 4, ptr null)
+// CHECK-NEXT: %[[#R1:]] = load i32, ptr %x.addr, align 4
+// CHECK-NEXT: store i32 %[[#R1]], ptr %.x..void.addr, align 4
+// CHECK-NEXT: call void @__kmpc_free(i32 %[[#R0]], ptr %.x..void.addr, ptr null)
+
+// CHECK: %[[#R0:]] = call i32 @__kmpc_global_thread_num(ptr @1)
+// CHECK-NEXT: store i64 %x, ptr %x.addr, align 8
+// CHECK-NEXT: %.x..void.addr = call ptr @__kmpc_alloc(i32 %[[#R0]], i64 4, ptr inttoptr (i64 1 to ptr))
+// CHECK-NEXT: %[[#R1:]] = load i32, ptr %x.addr, align 4
+// CHECK-NEXT: store i32 %[[#R1]], ptr %.x..void.addr, align 4
+// CHECK-NEXT: call void @__kmpc_free(i32 %[[#R0]], ptr %.x..void.addr, ptr inttoptr (i64 1 to ptr))
+
+// CHECK: %[[#R0:]] = call i32 @__kmpc_global_thread_num(ptr @1)
+// CHECK-NEXT: store i64 %x, ptr %x.addr, align 8
+// CHECK-NEXT: %.x..void.addr = call ptr @__kmpc_alloc(i32 %[[#R0]], i64 4, ptr inttoptr (i64 2 to ptr))
+// CHECK-NEXT: %[[#R1:]] = load i32, ptr %x.addr, align 4
+// CHECK-NEXT: store i32 %[[#R1]], ptr %.x..void.addr, align 4
+// CHECK-NEXT: call void @__kmpc_free(i32 %[[#R0]], ptr %.x..void.addr, ptr inttoptr (i64 2 to ptr))
+
+// CHECK: %[[#R0:]] = call i32 @__kmpc_global_thread_num(ptr @1)
+// CHECK-NEXT: store i64 %x, ptr %x.addr, align 8
+// CHECK-NEXT: %.x..void.addr = call ptr @__kmpc_alloc(i32 %[[#R0]], i64 4, ptr inttoptr (i64 3 to ptr))
+// CHECK-NEXT: %[[#R1:]] = load i32, ptr %x.addr, align 4
+// CHECK-NEXT: store i32 %[[#R1]], ptr %.x..void.addr, align 4
+// CHECK-NEXT: call void @__kmpc_free(i32 %[[#R0]], ptr %.x..void.addr, ptr inttoptr (i64 3 to ptr))
+
+// CHECK: %[[#R0:]] = call i32 @__kmpc_global_thread_num(ptr @1)
+// CHECK-NEXT: store i64 %x, ptr %x.addr, align 8
+// CHECK-NEXT: %.x..void.addr = call ptr @__kmpc_alloc(i32 %[[#R0]], i64 4, ptr inttoptr (i64 4 to ptr))
+// CHECK-NEXT: %[[#R1:]] = load i32, ptr %x.addr, align 4
+// CHECK-NEXT: store i32 %[[#R1]], ptr %.x..void.addr, align 4
+// CHECK-NEXT: call void @__kmpc_free(i32 %[[#R0]], ptr %.x..void.addr, ptr inttoptr (i64 4 to ptr))
+
+// CHECK: %[[#R0:]] = call i32 @__kmpc_global_thread_num(ptr @1)
+// CHECK-NEXT: store i64 %x, ptr %x.addr, align 8
+// CHECK-NEXT: %.x..void.addr = call ptr @__kmpc_alloc(i32 %[[#R0]], i64 4, ptr inttoptr (i64 5 to ptr))
+// CHECK-NEXT: %[[#R1:]] = load i32, ptr %x.addr, align 4
+// CHECK-NEXT: store i32 %[[#R1]], ptr %.x..void.addr, align 4
+// CHECK-NEXT: call void @__kmpc_free(i32 %[[#R0]], ptr %.x..void.addr, ptr inttoptr (i64 5 to ptr))
+
+// CHECK: %[[#R0:]] = call i32 @__kmpc_global_thread_num(ptr @1)
+// CHECK-NEXT: store i64 %x, ptr %x.addr, align 8
+// CHECK-NEXT: %.x..void.addr = call ptr @__kmpc_alloc(i32 %[[#R0]], i64 4, ptr inttoptr (i64 6 to ptr))
+// CHECK-NEXT: %[[#R1:]] = load i32, ptr %x.addr, a

[PATCH] D119130: [clangd] NFC: Move stdlib headers handling to Clang

2022-10-04 Thread Ilya Biryukov via Phabricator via cfe-commits

ilya-biryukov added a comment.

In D119130#3829816 , @thakis wrote:

> This makes clang-format depend on clang's AST library

Oops, definitely an unintended outcome.
Ping @kadircet, in case he missed this. He should know best who can fix this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119130

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

[PATCH] D131858: [clang] Track the templated entity in type substitution.

2022-10-04 Thread Matheus Izvekov via Phabricator via cfe-commits

mizvekov updated this revision to Diff 464937.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131858

Files:
  clang-tools-extra/clang-tidy/hicpp/ExceptionBaseclassCheck.cpp
  clang-tools-extra/clang-tidy/performance/UnnecessaryCopyInitialization.cpp
  clang-tools-extra/clangd/AST.cpp
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/AST/ASTNodeTraverser.h
  clang/include/clang/AST/JSONNodeDumper.h
  clang/include/clang/AST/TextNodeDumper.h
  clang/include/clang/AST/Type.h
  clang/include/clang/AST/TypeProperties.td
  clang/include/clang/Sema/Template.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/ASTImporter.cpp
  clang/lib/AST/ASTStructuralEquivalence.cpp
  clang/lib/AST/JSONNodeDumper.cpp
  clang/lib/AST/ODRHash.cpp
  clang/lib/AST/TextNodeDumper.cpp
  clang/lib/AST/Type.cpp
  clang/lib/AST/TypePrinter.cpp
  clang/lib/Sema/SemaConcept.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/lib/Sema/SemaTemplate.cpp
  clang/lib/Sema/SemaTemplateDeduction.cpp
  clang/lib/Sema/SemaTemplateInstantiate.cpp
  clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
  clang/lib/Sema/SemaTemplateVariadic.cpp
  clang/lib/Sema/TreeTransform.h
  clang/lib/Serialization/ASTReaderDecl.cpp
  clang/lib/Serialization/ASTWriterDecl.cpp
  clang/lib/StaticAnalyzer/Checkers/MismatchedIteratorChecker.cpp
  clang/test/AST/ast-dump-openmp-begin-declare-variant_reference.cpp
  clang/test/AST/ast-dump-template-decls.cpp
  clang/test/AST/deduction-guides.cpp
  clang/test/SemaTemplate/deduction-guide.cpp
  clang/test/SemaTemplate/make_integer_seq.cpp
  clang/test/SemaTemplate/type_pack_element.cpp
  libcxx/DELETE.ME

Index: libcxx/DELETE.ME
===
--- /dev/null
+++ libcxx/DELETE.ME
@@ -0,0 +1 @@
+D131858
Index: clang/test/SemaTemplate/type_pack_element.cpp
===
--- clang/test/SemaTemplate/type_pack_element.cpp
+++ clang/test/SemaTemplate/type_pack_element.cpp
@@ -11,14 +11,13 @@
 // CHECK-NEXT:   | `-IntegerLiteral 0x{{[0-9A-Fa-f]+}}  'int' 0
 // CHECK-NEXT:   |-TemplateArgument type 'int'
 // CHECK-NEXT:   | `-BuiltinType 0x{{[0-9A-Fa-f]+}} 'int'
-// CHECK-NEXT:   `-SubstTemplateTypeParmType 0x{{[0-9A-Fa-f]+}} 'int' sugar pack_index 0
-// CHECK-NEXT: |-TemplateTypeParmType 0x{{[0-9A-Fa-f]+}} 'auto' dependent depth 0 index 1
-// CHECK-NEXT: | `-TemplateTypeParm 0x{{[0-9A-Fa-f]+}} ''
+// CHECK-NEXT:   `-SubstTemplateTypeParmType 0x{{[0-9A-Fa-f]+}} 'int' sugar typename depth 0 index 1 ... pack_index 0
+// CHECK-NEXT: |-BuiltinTemplate 0x{{[0-9A-Fa-f]+}} '__type_pack_element'
 // CHECK-NEXT: `-BuiltinType 0x{{[0-9A-Fa-f]+}} 'int'
 
 template struct A {
   using test2 = __type_pack_element;
-//  CHECK: |-TypeAliasDecl 0x{{[0-9A-Fa-f]+}}  col:9 test2 '__type_pack_element':'__type_pack_element'
+//  CHECK: |-TypeAliasDecl 0x{{[0-9A-Fa-f]+}}  col:9 test2 '__type_pack_element':'__type_pack_element'
 // CHECK-NEXT:   `-ElaboratedType 0x{{[0-9A-Fa-f]+}} '__type_pack_element' sugar dependent
 // CHECK-NEXT: `-TemplateSpecializationType 0x{{[0-9A-Fa-f]+}} '__type_pack_element' sugar dependent alias __type_pack_element
 // CHECK-NEXT:   |-TemplateArgument expr
@@ -38,7 +37,7 @@
 // CHECK-NEXT:   `-TemplateTypeParmType 0x{{[0-9A-Fa-f]+}} 'type-parameter-0-1' dependent contains_unexpanded_pack depth 0 index 1 pack
 
   using test3 = __type_pack_element<0, Ts...>;
-//  CHECK: |-TypeAliasDecl 0x{{[0-9A-Fa-f]+}}  col:9 test3 '__type_pack_element<0, Ts...>':'__type_pack_element<0, type-parameter-0-1...>'
+//  CHECK: |-TypeAliasDecl 0x{{[0-9A-Fa-f]+}}  col:9 test3 '__type_pack_element<0, Ts...>':'__type_pack_element<0, type-parameter-0-1...>'
 // CHECK-NEXT:   `-ElaboratedType 0x{{[0-9A-Fa-f]+}} '__type_pack_element<0, Ts...>' sugar dependent
 // CHECK-NEXT: `-TemplateSpecializationType 0x{{[0-9A-Fa-f]+}} '__type_pack_element<0, Ts...>' sugar dependent alias __type_pack_element
 // CHECK-NEXT:   |-TemplateArgument expr
@@ -58,7 +57,7 @@
 // CHECK-NEXT:   `-TemplateTypeParmType 0x{{[0-9A-Fa-f]+}} 'type-parameter-0-1' dependent contains_unexpanded_pack depth 0 index 1 pack
 
   using test4 = __type_pack_element;
-//  CHECK: `-TypeAliasDecl 0x{{[0-9A-Fa-f]+}}  col:9 test4 '__type_pack_element':'__type_pack_element'
+//  CHECK: `-TypeAliasDecl 0x{{[0-9A-Fa-f]+}}  col:9 test4 '__type_pack_element':'__type_pack_element'
 // CHECK-NEXT:   `-ElaboratedType 0x{{[0-9A-Fa-f]+}} '__type_pack_element' sugar dependent
 // CHECK-NEXT: `-TemplateSpecializationType 0x{{[0-9A-Fa-f]+}} '__type_pack_element' sugar dependent alias __type_pack_element
 // CHECK-NEXT:   |-TemplateArgument expr
Index: clang/test/SemaTemplate/make_integer_seq.cpp
===
--- clang/test/SemaTemplate/make_inte

[PATCH] D135107: [clang][NFC] Use enum for -fstrict-flex-arrays

2022-10-04 Thread Balázs Benics via Phabricator via cfe-commits

steakhal added a comment.

The StaticAnalyzer changes seem to be correct.




Comment at: clang/include/clang/Basic/LangOptions.h:369-376
+/// Any trailing array memeber is a FAM.
+Default = 0,
+/// Any trailing array member of undefined, 0, or 1 size is a FAM.
+OneZeroOrIncomplete = 1,
+/// Any trailing array member of undefined or 0 is a FAM.
+ZeroOrIncomplete = 2,
+/// Any trailing array member of undefined or 0 is a FAM.

serge-sans-paille wrote:
> typo: member
For most cases, I can either see no initializers or only the first entry is 
being initialized.
I believe, by default, the entries would be initialized to `0`, `1`, and `2` 
here anyway.



Comment at: clang/lib/StaticAnalyzer/Core/MemRegion.cpp:799
+const FAMKind StrictFlexArraysLevel =
+  getContext().getLangOpts().getStrictFlexArraysLevel();
+if (StrictFlexArraysLevel == FAMKind::ZeroOrIncomplete ||




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135107

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

[PATCH] D134046: [OpenMP][OMPIRBuilder] Add support for order(concurrent) to OMPIRBuilder for SIMD directive

2022-10-04 Thread Dominik Adamski via Phabricator via cfe-commits

domada updated this revision to Diff 464952.
domada added a comment.

Remove custom enum for mapping `order(concurrent)`


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

https://reviews.llvm.org/D134046

Files:
  clang/lib/CodeGen/CGStmtOpenMP.cpp
  clang/test/OpenMP/irbuilder_safelen_order_concurrent.cpp
  llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h
  llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp
  llvm/unittests/Frontend/OpenMPIRBuilderTest.cpp
  mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp

Index: mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp
===
--- mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp
+++ mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp
@@ -996,11 +996,11 @@
   if (llvm::Optional safelenVar = loop.getSafelen())
 safelen = builder.getInt64(safelenVar.value());
 
-  ompBuilder->applySimd(loopInfo,
-loop.getIfExpr()
-? moduleTranslation.lookupValue(loop.getIfExpr())
-: nullptr,
-simdlen, safelen);
+  ompBuilder->applySimd(
+  loopInfo,
+  loop.getIfExpr() ? moduleTranslation.lookupValue(loop.getIfExpr())
+   : nullptr,
+  llvm::omp::OrderKind::OMP_ORDER_unknown, simdlen, safelen);
 
   builder.restoreIP(afterIP);
   return success();
Index: llvm/unittests/Frontend/OpenMPIRBuilderTest.cpp
===
--- llvm/unittests/Frontend/OpenMPIRBuilderTest.cpp
+++ llvm/unittests/Frontend/OpenMPIRBuilderTest.cpp
@@ -1771,7 +1771,8 @@
   CanonicalLoopInfo *CLI = buildSingleLoopFunction(DL, OMPBuilder, 32);
 
   // Simd-ize the loop.
-  OMPBuilder.applySimd(CLI, /* IfCond */ nullptr, /* Simdlen */ nullptr,
+  OMPBuilder.applySimd(CLI, /* IfCond */ nullptr, OrderKind::OMP_ORDER_unknown,
+   /* Simdlen */ nullptr,
/* Safelen */ nullptr);
 
   OMPBuilder.finalize();
@@ -1803,7 +1804,7 @@
   CanonicalLoopInfo *CLI = buildSingleLoopFunction(DL, OMPBuilder, 32);
 
   // Simd-ize the loop.
-  OMPBuilder.applySimd(CLI, /* IfCond */ nullptr,
+  OMPBuilder.applySimd(CLI, /* IfCond */ nullptr, OrderKind::OMP_ORDER_unknown,
ConstantInt::get(Type::getInt32Ty(Ctx), 3),
/* Safelen */ nullptr);
 
@@ -1831,13 +1832,49 @@
   }));
 }
 
+TEST_F(OpenMPIRBuilderTest, ApplySafelenOrderConcurrent) {
+  OpenMPIRBuilder OMPBuilder(*M);
+
+  CanonicalLoopInfo *CLI = buildSingleLoopFunction(DL, OMPBuilder, 32);
+
+  // Simd-ize the loop.
+  OMPBuilder.applySimd(
+  CLI, /* IfCond */ nullptr, OrderKind::OMP_ORDER_concurrent,
+  /* Simdlen */ nullptr, ConstantInt::get(Type::getInt32Ty(Ctx), 3));
+
+  OMPBuilder.finalize();
+  EXPECT_FALSE(verifyModule(*M, &errs()));
+
+  PassBuilder PB;
+  FunctionAnalysisManager FAM;
+  PB.registerFunctionAnalyses(FAM);
+  LoopInfo &LI = FAM.getResult(*F);
+
+  const std::vector &TopLvl = LI.getTopLevelLoops();
+  EXPECT_EQ(TopLvl.size(), 1u);
+
+  Loop *L = TopLvl.front();
+  // Parallel metadata shoudl be attached because of presence of
+  // the order(concurrent) OpenMP clause
+  EXPECT_TRUE(findStringMetadataForLoop(L, "llvm.loop.parallel_accesses"));
+  EXPECT_TRUE(getBooleanLoopAttribute(L, "llvm.loop.vectorize.enable"));
+  EXPECT_EQ(getIntLoopAttribute(L, "llvm.loop.vectorize.width"), 3);
+
+  // Check for llvm.access.group metadata attached to the printf
+  // function in the loop body.
+  BasicBlock *LoopBody = CLI->getBody();
+  EXPECT_TRUE(any_of(*LoopBody, [](Instruction &I) {
+return I.getMetadata("llvm.access.group") != nullptr;
+  }));
+}
+
 TEST_F(OpenMPIRBuilderTest, ApplySafelen) {
   OpenMPIRBuilder OMPBuilder(*M);
 
   CanonicalLoopInfo *CLI = buildSingleLoopFunction(DL, OMPBuilder, 32);
 
   // Simd-ize the loop.
-  OMPBuilder.applySimd(CLI, /* IfCond */ nullptr,
+  OMPBuilder.applySimd(CLI, /* IfCond */ nullptr, OrderKind::OMP_ORDER_unknown,
/* Simdlen */ nullptr,
ConstantInt::get(Type::getInt32Ty(Ctx), 3));
 
@@ -1871,7 +1908,7 @@
   CanonicalLoopInfo *CLI = buildSingleLoopFunction(DL, OMPBuilder, 32);
 
   // Simd-ize the loop.
-  OMPBuilder.applySimd(CLI, /* IfCond */ nullptr,
+  OMPBuilder.applySimd(CLI, /* IfCond */ nullptr, OrderKind::OMP_ORDER_unknown,
ConstantInt::get(Type::getInt32Ty(Ctx), 2),
ConstantInt::get(Type::getInt32Ty(Ctx), 3));
 
@@ -1916,7 +1953,8 @@
   CanonicalLoopInfo *CLI = buildSingleLoopFunction(DL, OMPBuilder, 32);
 
   // Simd-ize the loop with if condition
-  OMPBuilder.applySimd(CLI, IfCmp, ConstantInt::get(Type::getInt32Ty(Ctx), 3),
+  OMPBuilder.applySimd(CLI, IfCmp, OrderKind::OMP_ORDER_unknown,
+   ConstantInt::get(Type::getInt32Ty(Ctx), 3),
/* Saf

[PATCH] D135142: Use TI.hasBuiltinAtomic() when setting ATOMIC_*_LOCK_FREE values. NFCI

2022-10-04 Thread Alexander Richardson via Phabricator via cfe-commits

arichardson created this revision.
arichardson added reviewers: rprichard, efriedma, hfinkel.
Herald added a project: All.
arichardson requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

I noticed that the values for __{CLANG,GCC}_ATOMIC_POINTER_LOCK_FREE were
incorrectly set to 1 instead of two in downstream CHERI targets because
pointers are handled specially there. While fixing this downstream, I
noticed that the existing code could be refactored to use
TargetInfo::hasBuiltinAtomic instead of repeating the almost identical
logic. In theory there could be a difference here since hasBuiltinAtomic() also
returns true for types less than 1 char in size, but since
InitializePredefinedMacros() never passes such a value this change should
not introduce any functional changes.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D135142

Files:
  clang/lib/Frontend/InitPreprocessor.cpp


Index: clang/lib/Frontend/InitPreprocessor.cpp
===
--- clang/lib/Frontend/InitPreprocessor.cpp
+++ clang/lib/Frontend/InitPreprocessor.cpp
@@ -298,12 +298,12 @@
 
 /// Get the value the ATOMIC_*_LOCK_FREE macro should have for a type with
 /// the specified properties.
-static const char *getLockFreeValue(unsigned TypeWidth, unsigned InlineWidth) {
+static const char *getLockFreeValue(unsigned TypeWidth, const TargetInfo &TI) {
   // Fully-aligned, power-of-2 sizes no larger than the inline
   // width will be inlined as lock-free operations.
   // Note: we do not need to check alignment since _Atomic(T) is always
   // appropriately-aligned in clang.
-  if ((TypeWidth & (TypeWidth - 1)) == 0 && TypeWidth <= InlineWidth)
+  if (TI.hasBuiltinAtomic(TypeWidth, TypeWidth))
 return "2"; // "always lock free"
   // We cannot be certain what operations the lib calls might be
   // able to implement as lock-free on future processors.
@@ -1149,11 +1149,9 @@
 
   auto addLockFreeMacros = [&](const llvm::Twine &Prefix) {
 // Used by libc++ and libstdc++ to implement ATOMIC__LOCK_FREE.
-unsigned InlineWidthBits = TI.getMaxAtomicInlineWidth();
 #define DEFINE_LOCK_FREE_MACRO(TYPE, Type) 
\
   Builder.defineMacro(Prefix + #TYPE "_LOCK_FREE", 
\
-  getLockFreeValue(TI.get##Type##Width(),  
\
-   InlineWidthBits));
+  getLockFreeValue(TI.get##Type##Width(), TI));
 DEFINE_LOCK_FREE_MACRO(BOOL, Bool);
 DEFINE_LOCK_FREE_MACRO(CHAR, Char);
 if (LangOpts.Char8)
@@ -1166,8 +1164,7 @@
 DEFINE_LOCK_FREE_MACRO(LONG, Long);
 DEFINE_LOCK_FREE_MACRO(LLONG, LongLong);
 Builder.defineMacro(Prefix + "POINTER_LOCK_FREE",
-getLockFreeValue(TI.getPointerWidth(0),
- InlineWidthBits));
+getLockFreeValue(TI.getPointerWidth(0), TI));
 #undef DEFINE_LOCK_FREE_MACRO
   };
   addLockFreeMacros("__CLANG_ATOMIC_");


Index: clang/lib/Frontend/InitPreprocessor.cpp
===
--- clang/lib/Frontend/InitPreprocessor.cpp
+++ clang/lib/Frontend/InitPreprocessor.cpp
@@ -298,12 +298,12 @@
 
 /// Get the value the ATOMIC_*_LOCK_FREE macro should have for a type with
 /// the specified properties.
-static const char *getLockFreeValue(unsigned TypeWidth, unsigned InlineWidth) {
+static const char *getLockFreeValue(unsigned TypeWidth, const TargetInfo &TI) {
   // Fully-aligned, power-of-2 sizes no larger than the inline
   // width will be inlined as lock-free operations.
   // Note: we do not need to check alignment since _Atomic(T) is always
   // appropriately-aligned in clang.
-  if ((TypeWidth & (TypeWidth - 1)) == 0 && TypeWidth <= InlineWidth)
+  if (TI.hasBuiltinAtomic(TypeWidth, TypeWidth))
 return "2"; // "always lock free"
   // We cannot be certain what operations the lib calls might be
   // able to implement as lock-free on future processors.
@@ -1149,11 +1149,9 @@
 
   auto addLockFreeMacros = [&](const llvm::Twine &Prefix) {
 // Used by libc++ and libstdc++ to implement ATOMIC__LOCK_FREE.
-unsigned InlineWidthBits = TI.getMaxAtomicInlineWidth();
 #define DEFINE_LOCK_FREE_MACRO(TYPE, Type) \
   Builder.defineMacro(Prefix + #TYPE "_LOCK_FREE", \
-  getLockFreeValue(TI.get##Type##Width(),  \
-   InlineWidthBits));
+  getLockFreeValue(TI.get##Type##Width(), TI));
 DEFINE_LOCK_FREE_MACRO(BOOL, Bool);
 DEFINE_LOCK_FREE_MACRO(CHAR, Char);
 if (LangOpts.Char8)
@@ -1166,8 +1164,7 @@
 DEFINE_LOCK_FREE_MACRO(LONG, Long);
 DEFINE_LOCK_FREE_MACRO(LLONG, LongLong);
 Builder.defineMacro(Prefix + "POINTER_LOCK_FREE",
-

[PATCH] D72282: [clang-tidy] Add `bugprone-unintended-adl`

2022-10-04 Thread François-Xavier Carton via Phabricator via cfe-commits

fx-carton added a comment.

Great check!

Would it be possible to add an option to show the warning if a `using` 
directive is used? As in:

  namespace ns {
  struct s {};
  void func(const s&) {
  }
  }
  
  using ns::s;
  using ns::func; // without this the check is triggered
  
  int main(void) {
  s t;
  func(t);
  return 0;
  }


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

https://reviews.llvm.org/D72282

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

[PATCH] D134947: [analyzer] Fix liveness of Symbols for values in regions reffered by LazyCompoundVal

2022-10-04 Thread Balázs Benics via Phabricator via cfe-commits

steakhal added inline comments.



Comment at: clang/test/Analysis/trivial-copy-struct.cpp:58
+  clang_analyzer_warnIfReached(); // no-warning: Dead code.
+};
+




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134947

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

[PATCH] D135136: [analyzer] Make directly bounded LazyCompoundVal as lazily copied

2022-10-04 Thread Balázs Benics via Phabricator via cfe-commits

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

rebased


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135136

Files:
  clang/lib/StaticAnalyzer/Core/RegionStore.cpp
  clang/test/Analysis/trivial-copy-struct.cpp

Index: clang/test/Analysis/trivial-copy-struct.cpp
===
--- clang/test/Analysis/trivial-copy-struct.cpp
+++ clang/test/Analysis/trivial-copy-struct.cpp
@@ -92,9 +92,9 @@
   }
   if (!n->next) {
 if (w->head.next) {
-  // FIXME: Unreachable, w->head is a copy of *n, therefore
+  // Unreachable, w->head is a copy of *n, therefore
   // w->head.next and n->next are equal
-  clang_analyzer_warnIfReached(); // expected-warning {{REACHABLE}}
+  clang_analyzer_warnIfReached(); // no-warning: unreachable
 }
   }
   delete w;
Index: clang/lib/StaticAnalyzer/Core/RegionStore.cpp
===
--- clang/lib/StaticAnalyzer/Core/RegionStore.cpp
+++ clang/lib/StaticAnalyzer/Core/RegionStore.cpp
@@ -608,6 +608,10 @@
   /// The precise value of "interesting" is determined for the purposes of
   /// RegionStore's internal analysis. It must always contain all regions and
   /// symbols, but may omit constants and other kinds of SVal.
+  ///
+  /// In contrast to compound values, LazyCompoundVals are also added
+  /// to the 'interesting values' list in addition to the child interesting
+  /// values.
   const SValListTy &getInterestingValues(nonloc::LazyCompoundVal LCV);
 
   //===--===//
@@ -1032,12 +1036,11 @@
   if (Optional LCS =
   V.getAs()) {
 
-const RegionStoreManager::SValListTy &Vals = RM.getInterestingValues(*LCS);
-
-for (RegionStoreManager::SValListTy::const_iterator I = Vals.begin(),
-E = Vals.end();
- I != E; ++I)
-  VisitBinding(*I);
+// `getInterestingValues()` returns SVals contained within LazyCompoundVals,
+// so there is no need to visit them.
+for (SVal V : RM.getInterestingValues(*LCS))
+  if (!isa(V))
+VisitBinding(V);
 
 return;
   }
@@ -1290,15 +1293,10 @@
 if (Optional LCS =
 V.getAs()) {
 
-  const SValListTy &Vals = getInterestingValues(*LCS);
-
-  for (SValListTy::const_iterator I = Vals.begin(),
-  E = Vals.end(); I != E; ++I) {
-// Note: the last argument is false here because these are
-// non-top-level regions.
-if (const MemRegion *R = (*I).getAsRegion())
+  for (SVal S : getInterestingValues(*LCS))
+if (const MemRegion *R = S.getAsRegion())
   W.AddToWorkList(R);
-  }
+
   continue;
 }
 
@@ -2283,11 +2281,9 @@
 if (V.isUnknownOrUndef() || V.isConstant())
   continue;
 
-if (Optional InnerLCV =
-V.getAs()) {
+if (auto InnerLCV = V.getAs()) {
   const SValListTy &InnerList = getInterestingValues(*InnerLCV);
   List.insert(List.end(), InnerList.begin(), InnerList.end());
-  continue;
 }
 
 List.push_back(V);
@@ -2835,20 +2831,17 @@
 }
 
 void RemoveDeadBindingsWorker::VisitBinding(SVal V) {
-  // Is it a LazyCompoundVal?  All referenced regions are live as well.
-  if (Optional LCS =
-  V.getAs()) {
-// TODO: Make regions referred to by `lazyCompoundVals` that are bound to
-// subregions of the `LCS.getRegion()` also lazily copied.
-if (const MemRegion *R = LCS->getRegion())
-  SymReaper.markLazilyCopied(R);
-
-const RegionStoreManager::SValListTy &Vals = RM.getInterestingValues(*LCS);
-
-for (RegionStoreManager::SValListTy::const_iterator I = Vals.begin(),
-E = Vals.end();
- I != E; ++I)
-  VisitBinding(*I);
+  // Is it a LazyCompoundVal? All referenced regions are live as well.
+  // The LazyCompoundVal itself is not live but should be readable.
+  if (auto LCS = V.getAs()) {
+SymReaper.markLazilyCopied(LCS->getRegion());
+
+for (SVal V : RM.getInterestingValues(*LCS)) {
+  if (auto DepLCS = V.getAs())
+SymReaper.markLazilyCopied(DepLCS->getRegion());
+  else
+VisitBinding(V);
+}
 
 return;
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D132461: [clang-tidy] Add cppcoreguidelines-avoid-do-while check

2022-10-04 Thread Carlos Galvez via Phabricator via cfe-commits

carlosgalvezp added a comment.

@njames93 Ping


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132461

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

[PATCH] D20401: [Lexer] Don't merge macro args from different macro files

2022-10-04 Thread Haojian Wu via Phabricator via cfe-commits

hokein added a comment.

>> Meanwhile, I think besides evaluating the high level logic in in TokenLexer 
>> and how it might be improved, I think there's potentially an opportunity for 
>> a "AOS vs. SOA" speedup in SourceManager. 
>> SourceManager::LoadedSLocEntryTable is a 
>> llvm::SmallVector. SourceManager::getFileIDLoaded only 
>> really cares about the SLocEntry's Offset. I suspect we could get major 
>> memory locality wins by packing those into a standalone vector so that we 
>> could search them faster.
>
> Ah, great point. SLocEntry is 24 bytes while Offset is only 4.

And SLocEntry costs 4 bytes for padding only, which is bad :(

> SLocEntry is an important public API, but Offset is ~only used in 
> SourceManager, so that refactoring might be doable. I guess we can cheaply 
> prototype by redundantly storing offset *both* in a separate array used for 
> search and in the SLocEntry.

This is an interesting idea. I got a quick prototype of adding an in-parallel 
offset table in SourceManager:

- clang::SourceManager::getFileIDLocal  2.45% -> 1.57% (reduce by 30%+)
- SourceManager memory usage is increased by ~10%:  `SemaExpr.cpp` 12.6MB -> 
14.3MB

The improvement of `getFileIDLocal` seems promising, but the memory 
increasement is a thing (10% is not small, maybe it is ok compared the actual 
AST size).

An alternative is to restructure the SLocEntry and the underlying storage in 
SourceManager, it will give us both performance and memory improvement, but we 
need to make a significant change of the SourceManager.

> A build on a 72+ threaded workstation should only take ~1 minute. Can you 
> please give it a shot and let me know off-thread if you encounter any issues?

Thanks for writing down the instructions, it is useful. It works for me (on an 
intel-based workstation).


Repository:
  rL LLVM

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

https://reviews.llvm.org/D20401

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

[PATCH] D135099: [C2x] Implement support for nullptr and nullptr_t

2022-10-04 Thread Aaron Ballman via Phabricator via cfe-commits

aaron.ballman updated this revision to Diff 464973.
aaron.ballman marked 8 inline comments as done.
aaron.ballman added a comment.

Updated based on review feedback.


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

https://reviews.llvm.org/D135099

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/AST/ExprCXX.h
  clang/include/clang/AST/PrettyPrinter.h
  clang/include/clang/AST/Type.h
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/TokenKinds.def
  clang/lib/AST/Expr.cpp
  clang/lib/AST/Type.cpp
  clang/lib/Headers/stddef.h
  clang/lib/Parse/ParseExpr.cpp
  clang/lib/Sema/SemaCast.cpp
  clang/lib/Sema/SemaCodeComplete.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/test/C/C11/n1330.c
  clang/test/C/C2x/n3042.c
  clang/test/Sema/nullptr-prec2x.c
  clang/test/Sema/nullptr.c
  clang/test/Sema/static-assert.c
  clang/www/c_status.html

Index: clang/www/c_status.html
===
--- clang/www/c_status.html
+++ clang/www/c_status.html
@@ -1204,7 +1204,13 @@
 
   Introduce the nullptr constant
   https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3042.htm";>N3042
-  No
+  
+Partial
+  Parts of the implementation may be incorrect until WG14 has completed NB comment
+  resolution for incompatibilities with C++ that were discovered. The major use cases
+  and usage patterns should work well, though.
+
+  
 
 
   Memory layout of unions
Index: clang/test/Sema/static-assert.c
===
--- clang/test/Sema/static-assert.c
+++ clang/test/Sema/static-assert.c
@@ -1,11 +1,11 @@
-// RUN: %clang_cc1 -std=c11 -fsyntax-only -verify %s
-// RUN: %clang_cc1 -fms-compatibility -DMS -fsyntax-only -verify=expected,ms %s
-// RUN: %clang_cc1 -std=c99 -pedantic -fsyntax-only -verify=expected,ext %s
+// RUN: %clang_cc1 -std=c11 -Wgnu-folding-constant -fsyntax-only -verify %s
+// RUN: %clang_cc1 -fms-compatibility -Wgnu-folding-constant -DMS -fsyntax-only -verify=expected,ms %s
+// RUN: %clang_cc1 -std=c99 -pedantic -Wgnu-folding-constant -fsyntax-only -verify=expected,ext %s
 // RUN: %clang_cc1 -xc++ -std=c++11 -pedantic -fsyntax-only -verify=expected,ext,cxx %s
 
 _Static_assert("foo", "string is nonzero"); // ext-warning {{'_Static_assert' is a C11 extension}}
 #ifndef __cplusplus
-// expected-error@-2 {{static assertion expression is not an integral constant expression}}
+// expected-warning@-2 {{expression is not an integer constant expression; folding it to a constant is a GNU extension}}
 #endif
 
 _Static_assert(1, "1 is nonzero"); // ext-warning {{'_Static_assert' is a C11 extension}}
@@ -85,12 +85,12 @@
 _Static_assert(1.0 != 0, "");  // ext-warning {{'_Static_assert' is a C11 extension}}
 _Static_assert(__builtin_strlen("1"), "");  // ext-warning {{'_Static_assert' is a C11 extension}}
 #ifndef __cplusplus
-// ext-warning@-9 {{expression is not an integer constant expression; folding it to a constant is a GNU extension}}
-// ext-warning@-8 {{expression is not an integer constant expression; folding it to a constant is a GNU extension}}
-// ext-warning@-8 {{expression is not an integer constant expression; folding it to a constant is a GNU extension}}
-// ext-warning@-8 {{expression is not an integer constant expression; folding it to a constant is a GNU extension}}
-// ext-warning@-8 {{expression is not an integer constant expression; folding it to a constant is a GNU extension}}
-// ext-warning@-8 {{expression is not an integer constant expression; folding it to a constant is a GNU extension}}
+// expected-warning@-9 {{expression is not an integer constant expression; folding it to a constant is a GNU extension}}
+// expected-warning@-8 {{expression is not an integer constant expression; folding it to a constant is a GNU extension}}
+// expected-warning@-8 {{expression is not an integer constant expression; folding it to a constant is a GNU extension}}
+// expected-warning@-8 {{expression is not an integer constant expression; folding it to a constant is a GNU extension}}
+// expected-warning@-8 {{expression is not an integer constant expression; folding it to a constant is a GNU extension}}
+// expected-warning@-8 {{expression is not an integer constant expression; folding it to a constant is a GNU extension}}
 // __builtin_strlen(literal) is considered an integer constant expression
 // and doesn't cause a pedantic warning
 #endif
Index: clang/test/Sema/nullptr.c
===
--- /dev/null
+++ clang/test/Sema/nullptr.c
@@ -0,0 +1,107 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c2x -ffreestanding -Wno-null-conversion -Wno-tautological-compare %s
+#include 
+
+typedef typeof(nullptr) nullptr_t;
+
+struct A {};
+
+__attribute__((overloa

[PATCH] D135099: [C2x] Implement support for nullptr and nullptr_t

2022-10-04 Thread Aaron Ballman via Phabricator via cfe-commits

aaron.ballman added inline comments.



Comment at: clang/include/clang/AST/PrettyPrinter.h:68
 SuppressDefaultTemplateArgs(true), Bool(LO.Bool),
-Nullptr(LO.CPlusPlus11), Restrict(LO.C99), Alignof(LO.CPlusPlus11),
+Nullptr(LO.CPlusPlus11), NullptrTypeInNamespace(LO.CPlusPlus),
+Restrict(LO.C99), Alignof(LO.CPlusPlus11),

erichkeane wrote:
> Does Nullptr here not have to change?  Shouldn't we care to use the "nullptr" 
> in C mode instead of '0' now?
Yes it should, but it's an NFC change. The only thing using `Nullptr` is the 
`APValue` pretty printer and I can't find a way to exercise that code path in 
C. That said, once we add support for `constexpr` in C, I believe we will be 
able to get into this path so we might as well handle it now.

If anyone can think of a test case that attempts to print a diagnostic on a 
pointer typed APValue in C, I'm happy to add it.



Comment at: clang/include/clang/AST/PrettyPrinter.h:201
+  /// Whether 'nullptr_t' is in namespace 'std' or not.
+  unsigned NullptrTypeInNamespace;
+

erichkeane wrote:
> Is there a reason this isn't a bitfield as well?
Nope, great catch! Think-o on my part. :-)



Comment at: clang/include/clang/Basic/TokenKinds.def:393
 CXX11_KEYWORD(noexcept  , 0)
-CXX11_KEYWORD(nullptr   , 0)
+CXX11_KEYWORD(nullptr   , KEYC2X)
 CXX11_KEYWORD(static_assert , KEYMSCOMPAT|KEYC2X)

erichkeane wrote:
> Its a shame we have to do this... the CXX11_KEYWORD (and presumably the 
> reverse) is used for 'future' diagnostics IIRC.  So not having this as a 
> C2X_KEYWORD means we lose the 'future keyword' diagnostics, right?
Nope, we do the right thing now after Usman's changes. I'll add a test to 
demonstrate so we have better coverage.



Comment at: clang/lib/Sema/SemaCast.cpp:2999
+  Self.Diag(SrcExpr.get()->getExprLoc(), diag::err_nullptr_cast)
+  << 0 /*nullptr to type*/ << DestType;
+  SrcExpr = ExprError();

shafik wrote:
> Curious why put the comment after? When we use `butprone-argument-comment` 
> for function parameters we put them before. 
No real reason aside from muscle memory. I'll switch it up.



Comment at: clang/lib/Sema/SemaExpr.cpp:8730
+  //   result also has that type.
+  if (LHSTy->isNullPtrType() && Context.hasSameType(LHSTy, RHSTy))
+return ResTy;

shafik wrote:
> erichkeane wrote:
> > what does this do with the GNU ternary-thing?  
> Does this cover if one is a pointer with a null pointer value?
It behaves as expected; I've added additional test coverage to demonstrate 
that, good call!



Comment at: clang/lib/Sema/SemaExpr.cpp:12587
 
-// Comparison of Objective-C pointers and block pointers against nullptr_t.
-// These aren't covered by the composite pointer type rules.
-if (!IsOrdered && RHSType->isNullPtrType() &&
-(LHSType->isObjCObjectPointerType() || LHSType->isBlockPointerType())) 
{
+  // C++ [expr.eq]p4:
+  //   Two operands of type std::nullptr_t or one operand of type

shafik wrote:
> This was in the `if (getLangOpts().CPlusPlus)` block previously, did you mean 
> to move it out?
Yup, moving it out is intentional. This now covers C2x 6.5.9p5 as well.



Comment at: clang/lib/Sema/SemaExpr.cpp:12620
+
+  // Comparison of Objective-C pointers and block pointers against nullptr_t.
+  // These aren't covered by the composite pointer type rules.

shafik wrote:
> This was in the `if (getLangOpts().CPlusPlus)` block previously, did you mean 
> to move it out?
Yes -- this was handling Objective-C++ behavior and now that C has nullptr we 
want it to cover Objective-C as well.


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

https://reviews.llvm.org/D135099

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

[PATCH] D134813: Properly print unnamed TagDecl objects in diagnostics

2022-10-04 Thread Aaron Ballman via Phabricator via cfe-commits

aaron.ballman added a subscriber: mizvekov.
aaron.ballman added a comment.

In D134813#3826991 , @aaron.ballman 
wrote:

> The clangd test failure found by precommit CI is stumping me as to how to 
> resolve it. @sammccall -- can you help me out? The issue is that the test is 
> expecting no name but now we're printing more information, but that 
> information includes a file path which may differ between machines.

Ping @sammccall. FWIW, I found that the failing part of this test was change 
somewhat recently in 
https://github.com/llvm/llvm-project/commit/15f3cd6bfc670ba6106184a903eb04be059e5977
 to add the markings to print the name of this class, so also pinging @mizvekov 
to see if this test coverage is necessary (another way to solve the issue is to 
stop trying to read the name of the unnamed class in the unit test).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134813

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

[PATCH] D132855: [OpenMP] Extend the lit test for uses_allocators in target region

2022-10-04 Thread Johannes Doerfert via Phabricator via cfe-commits

jdoerfert added inline comments.



Comment at: clang/test/OpenMP/target_map_codegen_10.cpp:19
+// RUN: %clang_cc1 -no-opaque-pointers -DCK11 -fopenmp 
-fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple 
i386-unknown-unknown -emit-pch -o %t %s
+// RUN: %clang_cc1 -no-opaque-pointers -fopenmp 
-fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown 
-std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck 
-allow-deprecated-dag-overlap  %s  --check-prefixes CK11,CK11_5
 

What does this test?



Comment at: clang/test/OpenMP/target_uses_allocators.c:42
+  #pragma omp target uses_allocators(omp_thread_mem_alloc) 
allocate(omp_thread_mem_alloc: x) firstprivate(x) // expected-warning 
{{allocator with the 'thread' trait access has unspecified behavior on 'target' 
directive}}
+  {}
 }

This should go into the _messages test case


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132855

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

[PATCH] D133578: [OpenMP][OMPIRBuilder] Add generation of SIMD align assumptions to OMPIRBuilder

2022-10-04 Thread Johannes Doerfert via Phabricator via cfe-commits

jdoerfert added inline comments.



Comment at: llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp:2976
 
+  const int DefaultAlignment = 16;
+

domada wrote:
> jdoerfert wrote:
> > domada wrote:
> > > jdoerfert wrote:
> > > > This doesn't work. Use the data layout for any default values please.
> > > I have used pointer ABI alignment as the default value. Is it ok?
> > > Clang has separate method to calculate OpenMP default alignment defined 
> > > in TargetInfo class ( [[ 
> > > https://clang.llvm.org/doxygen/classclang_1_1TargetInfo.html#af0c75e3288adc13601732329c44db147
> > >  |  link ]])
> > > Unfortunately, there is no simple replacement of this function in 
> > > OMPIRBuilder or in Flang driver. There are some requests to expose 
> > > TargetInfo data in Clang-independent manner: [[ 
> > > https://discourse.llvm.org/t/rfc-targetinfo-library/64342 | RFC1 ]], 
> > > [[https://discourse.llvm.org/t/complex-to-libm-conversion-abi-issues/65131
> > >  |RFC2]] , but this issue is not solved.
> > Let's step back:
> > 1) User tells us the alignment via `aligned(X:64)`. This should populate 
> > the map in Clang, I would assume.
> > 2) User tells us the alignment "implicitly" via `align(Y)`. Again, clang 
> > should populate the map with the default/preferred alignment of the type. 
> > You can use the function you linked, or use the data layout API to get the 
> > preferred alignment.
> > 3) User tells us nothing. We should pick the default or, don't annotate 
> > anything. If we go with defaults, you need to look up the default for the 
> > address space but I don't know why we would annotate anything not provided 
> > by the user.
> > 
> > 
> Ad 1) Agree
> Ad 2) OK, I will add assertion to ensure that the map is correctly populated 
> with the default/preferred alignment if the user specifies only: `align(Y)`.
> 
> I was thinking that OMPIRBuilder should pick the default value if the user 
> specifies `align(Y)`. Thanks for clarification. 
> 
> Ad 3)  I assume that if the user tells us nothing we should not annotate 
> anything. I will expect empty map and no generated annotations. Currently we 
> do not generate any annotations if there is no align clause.
> I was thinking that OMPIRBuilder should pick the default value if the user 
> specifies align(Y). Thanks for clarification.

That works with me, but you need the actual type. So the Value is not 
sufficient, you need `&X and double` to ask DataLayout for the preferred type. 
For now you can use the clang functionality or pass the type and use DL.

> I assume that if the user tells us nothing we should not annotate anything. 

Agreed.


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

https://reviews.llvm.org/D133578

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

[PATCH] D135115: [clang-format] update --files help description

2022-10-04 Thread MyDeveloperDay via Phabricator via cfe-commits

MyDeveloperDay added inline comments.



Comment at: clang/docs/ClangFormat.rst:29
 
   USAGE: clang-format [options] [ ...]
 

if response files are so common place why not say it here 

`clang-format [options] [@file]`

I personally don't believe we need to document how a shell works



Comment at: clang/docs/ClangFormat.rst:72
  Used only with --dry-run or -n
---files=   - Provide a list of files to run 
clang-format
+--files=   - Accept a list of response files 
(Deprecated. Use
+ 'clang-format @file' if possbile).

if you google "response files" you don't get anything that leads to understand 
what they are. I understand what it means but I'm not convinced others who have 
not come across it before will. I don't personally think this change adds 
anything.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135115

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

[PATCH] D133586: [clang] initialize type qualifiers for FunctionNoProtoType

2022-10-04 Thread Aaron Ballman via Phabricator via cfe-commits

aaron.ballman added a comment.

In D133586#3831624 , @rmaz wrote:

> In D133586#3831618 , @vsapsai wrote:
>
>> How correct is it to access `isConst`, `isVolatile`, `isRestrict` for 
>> `FunctionNoProtoType`? Yes, we can provide some default value but I'm 
>> curious if accessing that default value is correct.
>>
>> For the record, I've tried to fix the same problem in 
>> https://reviews.llvm.org/D104963 in a different way.
>
> That was my initial solution as well, but it seemed safer to ensure these 
> methods always returned a consistent value without auditing all the possible 
> call sites. I agree that it doesn't seem right that these methods are on the 
> base class at all if they are only valid in one of the subclasses.

The trouble is -- `FunctionNoProtoType` is pretty rare to encounter and is 
getting more rare by the year now that C has removed the feature entirely, but 
you can't build a prototyped function from an unprototyped one or vice versa 
(their only relationship is that they're both function types with a known 
return type). So if we pushed the methods from `FunctionType` down into 
`FunctionProtoType`, we'd have to run through the casting machinery a lot more 
than we currently do which could potentially regress compile times for very 
little benefit.

Personally, I think the next step is to add a local `assert()` to this function 
to try to find out why we're calling this on functions without a prototype and 
fix up the call sites. I think the intent is that you should not be calling 
this function on an unprototyped function and it'd be good for debug builds to 
yell if we're doing that, but returning a default constructed object is a safe 
recovery for release builds.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133586

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

[PATCH] D134046: [OpenMP][OMPIRBuilder] Add support for order(concurrent) to OMPIRBuilder for SIMD directive

2022-10-04 Thread Johannes Doerfert via Phabricator via cfe-commits

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

LG


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

https://reviews.llvm.org/D134046

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

[PATCH] D128745: [c++] implements DR692, DR1395 and tentatively DR1432, about partial ordering of variadic template partial specialization or function template

2022-10-04 Thread Aaron Ballman via Phabricator via cfe-commits

aaron.ballman added a reviewer: hubert.reinterpretcast.
aaron.ballman added a subscriber: hubert.reinterpretcast.
aaron.ballman added a comment.

In D128745#3832598 , @ychen wrote:

> In D128745#3832432 , @rjmccall 
> wrote:
>
>> Pinging this thread because it has more reviewers who probably have opinions 
>> about this.
>>
>> https://reviews.llvm.org/D134507 is a patch that adds `-fclang-abi-compat` 
>> support around the breaking change here, which basically means that targets 
>> using old `-fclang-abi-compat` settings never get this change.  I've argued 
>> on that patch that that isn't the right way of resolving this issue.  
>> Basically, the DR here is changing the language behavior in a way that you 
>> can imagine having ABI impact, but it's not primarily an ABI change, it's a 
>> language semantics change.  The ABI impact is purely that we potentially 
>> select a different overload in some cases, which can have downstream ODR 
>> impact.  I think the appropriate way to handle language semantics changes 
>> like this which potentially have compatibility impact is to condition them 
>> on language version.  Changing the target language standard is already 
>> broadly understood to have source/semantic compatibility impact, which is 
>> why we allow different target language standards to be specified in the 
>> first place.  This also makes it straightforward to document this potential 
>> break as a consequence of moving to `-std=c++23`, and it removes a potential 
>> rather bizarre portability issue where platforms that embrace stable ABIs 
>> are permanently stuck with a language dialect.
>
> This is very reasonable to me except that I hope, for this particular patch, 
> to key on `-std=c++20` instead of `-std=c++23` since this is needed for P2113 
> , a C++20 change.

There were multiple DRs implemented in this patch.

DR692 was a fix against C++11
DR1395 was a fix against C++17
DR1432 is still open but was opened against C++11

Which DRs do we wish to implement in what language modes?

@rjmccall is correct about us not being required to apply DRs when they're 
disruptive, but at the same time, WG21 DRs are intended to be handled as if the 
original standard they were reported against had always been using the fixed 
form. So *not* applying a DR in order to avoid problems for existing code can 
cause problems for existing and future code in terms of portability between 
compilers (and ABI impacts that stem from the semantic changes). So I think we 
wish to apply the DRs as broadly as we can. The question is: do we think users 
with existing code should not have to change or do we think it's reasonable to 
give them a flag to opt into the old behavior? My personal feeling is -- the 
default compiler mode should be as conforming as we can make it be within 
reason, and since this has some impact but not a massive break (no major OS 
SDKs or third party libraries seem to be impacted as best I can tell), my 
feeling is that we should strongly consider adding a feature flag (other than 
ABI compat, as that does seem like a bit of an odd choice to key on) to opt 
into the older behavior, esp since the break is a loud one and not a silent one.

Adding @hubert.reinterpretcast as C++ conformance code owner in case he's got 
opinions as well.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128745

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

[PATCH] D135115: [clang-format] update --files help description

2022-10-04 Thread Paul Robinson via Phabricator via cfe-commits

probinson added a comment.

The option handling in clang-format itself would need to be updated as well.




Comment at: clang/docs/ClangFormat.rst:29
 
   USAGE: clang-format [options] [ ...]
 

MyDeveloperDay wrote:
> if response files are so common place why not say it here 
> 
> `clang-format [options] [@file]`
> 
> I personally don't believe we need to document how a shell works
Pretty sure it's not the shell doing the expansion here?  Certainly Clang has 
explicit code for deciding between gnu-style and windows-style handling.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135115

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

[PATCH] D128745: [c++] implements DR692, DR1395 and tentatively DR1432, about partial ordering of variadic template partial specialization or function template

2022-10-04 Thread Erich Keane via Phabricator via cfe-commits

erichkeane added a comment.

Is there any ability here to diagnose the difference?  It would probably be 
helpful if at any point (in both directions!) we diagnose that our behavior 
changes.  We did something similar for the reversible operators at one point 
(but WG21 might have fixed it since?).

IMO, if we decide that a DR is 'too breaking' to implement in all language 
modes it applies to, we shouldn't implement it at all, and instead should 
question the standards committee about their breaks.  Flipping it based on 
language version increases the friction (in a silent and really breaking way!) 
to switch language modes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128745

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

[PATCH] D135154: Keep inherited dllimport/export attrs for explicit specialization of template class member functions

2022-10-04 Thread Hans Wennborg via Phabricator via cfe-commits

hans created this revision.
hans added a reviewer: thakis.
Herald added a subscriber: mstorsjo.
Herald added a project: All.
hans requested review of this revision.
Herald added a project: clang.

Previously we were stripping these normally inherited attributes during 
explicit specialization. However for class template member functions (but not 
function templates), MSVC keeps the attribute.

This makes Clang match that behavior, and fixes GitHub issue #54717


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D135154

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaTemplate.cpp
  clang/test/CodeGenCXX/dllexport-members.cpp
  clang/test/CodeGenCXX/dllimport-members.cpp
  clang/test/SemaCXX/dllimport.cpp

Index: clang/test/SemaCXX/dllimport.cpp
===
--- clang/test/SemaCXX/dllimport.cpp
+++ clang/test/SemaCXX/dllimport.cpp
@@ -1300,6 +1300,28 @@
 template __declspec(dllimport) constexpr int CTMR::ConstexprField;
 
 
+// MSVC imports explicit specialization of imported class template member
+// function, and errors on such definitions. MinGW does not treat them as
+// dllimport.
+template  struct ClassTmpl {
+#if !defined(GNU)
+// expected-note@+2{{attribute is here}}
+#endif
+  void __declspec(dllimport) importedNormal();
+#if !defined(GNU)
+// expected-note@+2{{attribute is here}}
+#endif
+  static void __declspec(dllimport) importedStatic();
+};
+#if !defined(GNU)
+// expected-error@+2{{cannot define non-inline dllimport template specialization}}
+#endif
+template<> void ClassTmpl::importedNormal() {}
+#if !defined(GNU)
+// expected-error@+2{{cannot define non-inline dllimport template specialization}}
+#endif
+template<> void ClassTmpl::importedStatic() {}
+
 
 //===--===//
 // Class template member templates
Index: clang/test/CodeGenCXX/dllimport-members.cpp
===
--- clang/test/CodeGenCXX/dllimport-members.cpp
+++ clang/test/CodeGenCXX/dllimport-members.cpp
@@ -875,3 +875,23 @@
 // GNU-DAG: @_ZN10MemVarTmpl9StaticVarI21ExplicitSpec_ImportedEE= external dllimport constant i32
 template<> __declspec(dllimport) const int MemVarTmpl::StaticVar;
 USEMV(MemVarTmpl, StaticVar)
+
+
+//===--===//
+// Class template members
+//===--===//
+
+template  struct ClassTmplMem {
+  void __declspec(dllimport) importedNormal();
+  static void __declspec(dllimport) importedStatic();
+};
+// MSVC imports explicit specialization of imported class template member function; MinGW does not.
+// M32-DAG: declare dllimport x86_thiscallcc void @"?importedNormal@?$ClassTmplMem@H@@QAEXXZ"
+// G32-DAG: declare dso_local x86_thiscallcc void @_ZN12ClassTmplMemIiE14importedNormalEv
+template<> void ClassTmplMem::importedNormal();
+USEMF(ClassTmplMem, importedNormal);
+
+// M32-DAG: declare dllimport void @"?importedStatic@?$ClassTmplMem@H@@SAXXZ"
+// G32-DAG: declare dso_local void @_ZN12ClassTmplMemIiE14importedStaticEv
+template<> void ClassTmplMem::importedStatic();
+USEMF(ClassTmplMem, importedStatic);
Index: clang/test/CodeGenCXX/dllexport-members.cpp
===
--- clang/test/CodeGenCXX/dllexport-members.cpp
+++ clang/test/CodeGenCXX/dllexport-members.cpp
@@ -679,3 +679,21 @@
 // MSC-DAG: @"??$StaticVar@UExplicitSpec_Def_Exported@@@MemVarTmpl@@2HB" = weak_odr dso_local dllexport constant i32 1, comdat, align 4
 // GNU-DAG: @_ZN10MemVarTmpl9StaticVarI25ExplicitSpec_Def_ExportedEE= dso_local dllexport constant i32 1, align 4
 template<> __declspec(dllexport) const int MemVarTmpl::StaticVar = 1;
+
+
+//===--===//
+// Class template members
+//===--===//
+
+template  struct ClassTmplMem {
+  void __declspec(dllexport) exportedNormal();
+  static void __declspec(dllexport) exportedStatic();
+};
+// MSVC exports explicit specialization of exported class template member function; MinGW does not.
+// M32-DAG: define dso_local dllexport x86_thiscallcc void @"?exportedNormal@?$ClassTmplMem@H@@QAEXXZ"
+// G32-DAG: define dso_local   x86_thiscallcc void @_ZN12ClassTmplMemIiE14exportedNormalEv
+template<> void ClassTmplMem::exportedNormal() {}
+
+// M32-DAG: define dso_local dllexport void @"?exportedStatic@?$ClassTmplMem@H@@SAXXZ"
+// G32-DAG: define dso_local   void @_ZN12ClassTmplMemIiE14exportedStaticEv
+template<> void ClassTmplMem::exportedStatic() {}
Index: clang/lib/Sema/SemaTemplate.cpp
===
--- clang/lib/Sema/SemaTemplate.cpp
+++ clang/lib/Sema/SemaTempl

[PATCH] D134369: [Clang] Support constexpr builtin fmax

2022-10-04 Thread Evgeny Shulgin via Phabricator via cfe-commits

Izaron updated this revision to Diff 464990.
Izaron added a comment.

Fix corner case with pos/neg zeroes

Fix tests for pos/neg zeroes with __builtin_copysign

Thanks to @efriedma and @jcranmer-intel!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134369

Files:
  clang/docs/LanguageExtensions.rst
  clang/lib/AST/ExprConstant.cpp
  clang/test/Sema/constant-builtins-fmax.cpp


Index: clang/test/Sema/constant-builtins-fmax.cpp
===
--- /dev/null
+++ clang/test/Sema/constant-builtins-fmax.cpp
@@ -0,0 +1,54 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+// expected-no-diagnostics
+
+constexpr double NaN = __builtin_nan("");
+constexpr double Inf = __builtin_inf();
+constexpr double NegInf = -__builtin_inf();
+
+#define FMAX_TEST_SIMPLE(T, FUNC)   \
+static_assert(T(6.7890) == FUNC(T(1.2345), T(6.7890))); \
+static_assert(T(6.7890) == FUNC(T(6.7890), T(1.2345)));
+
+#define FMAX_TEST_NAN(T, FUNC)  \
+static_assert(Inf == FUNC(NaN, Inf));   \
+static_assert(NegInf == FUNC(NegInf, NaN)); \
+static_assert(0.0 == FUNC(NaN, 0.0));   \
+static_assert(-0.0 == FUNC(-0.0, NaN)); \
+static_assert(T(-1.2345) == FUNC(NaN, T(-1.2345))); \
+static_assert(T(1.2345) == FUNC(T(1.2345), NaN));   \
+static_assert(__builtin_isnan(FUNC(NaN, NaN)));
+
+#define FMAX_TEST_INF(T, FUNC)  \
+static_assert(Inf == FUNC(NegInf, Inf));\
+static_assert(Inf == FUNC(Inf, 0.0));   \
+static_assert(Inf == FUNC(-0.0, Inf));  \
+static_assert(Inf == FUNC(Inf, T(1.2345))); \
+static_assert(Inf == FUNC(T(-1.2345), Inf));
+
+#define FMAX_TEST_NEG_INF(T, FUNC) \
+static_assert(Inf == FUNC(Inf, NegInf));   \
+static_assert(0.0 == FUNC(NegInf, 0.0));   \
+static_assert(-0.0 == FUNC(-0.0, NegInf)); \
+static_assert(T(-1.2345) == FUNC(NegInf, T(-1.2345))); \
+static_assert(T(1.2345) == FUNC(T(1.2345), NegInf));
+
+#define FMAX_TEST_BOTH_ZERO(T, FUNC)   \
+static_assert(__builtin_copysign(1.0, FUNC(0.0, 0.0)) == 1.0);  \
+static_assert(__builtin_copysign(1.0, FUNC(-0.0, 0.0)) == 1.0);  \
+static_assert(__builtin_copysign(1.0, FUNC(0.0, -0.0)) == 1.0);  \
+static_assert(__builtin_copysign(1.0, FUNC(-0.0, -0.0)) == -1.0);
+
+#define LIST_FMAX_TESTS(T, FUNC) \
+FMAX_TEST_SIMPLE(T, FUNC)\
+FMAX_TEST_NAN(T, FUNC)   \
+FMAX_TEST_INF(T, FUNC)   \
+FMAX_TEST_NEG_INF(T, FUNC)   \
+FMAX_TEST_BOTH_ZERO(T, FUNC)
+
+LIST_FMAX_TESTS(double, __builtin_fmax)
+LIST_FMAX_TESTS(float, __builtin_fmaxf)
+LIST_FMAX_TESTS((long double), __builtin_fmaxl)
+LIST_FMAX_TESTS(__fp16, __builtin_fmaxf16)
+#ifdef __FLOAT128__
+LIST_FMAX_TESTS(__float128, __builtin_fmaxf128)
+#endif
Index: clang/lib/AST/ExprConstant.cpp
===
--- clang/lib/AST/ExprConstant.cpp
+++ clang/lib/AST/ExprConstant.cpp
@@ -14021,6 +14021,23 @@
 Result.copySign(RHS);
 return true;
   }
+
+  case Builtin::BI__builtin_fmax:
+  case Builtin::BI__builtin_fmaxf:
+  case Builtin::BI__builtin_fmaxl:
+  case Builtin::BI__builtin_fmaxf16:
+  case Builtin::BI__builtin_fmaxf128: {
+APFloat RHS(0.);
+if (!EvaluateFloat(E->getArg(0), Result, Info) ||
+!EvaluateFloat(E->getArg(1), RHS, Info))
+  return false;
+// when comparing zeroes, return +0.0 if one of the zeroes is positive
+if (Result.isZero() && RHS.isZero() && Result.isNegative())
+  Result = RHS;
+else if (Result.isNaN() || RHS > Result)
+  Result = RHS;
+return true;
+  }
   }
 }
 
Index: clang/docs/LanguageExtensions.rst
===
--- clang/docs/LanguageExtensions.rst
+++ clang/docs/LanguageExtensions.rst
@@ -4660,6 +4660,7 @@
 * ``__builtin_ffs``
 * ``__builtin_ffsl``
 * ``__builtin_ffsll``
+* ``__builtin_fmax``
 * ``__builtin_fpclassify``
 * ``__builtin_inf``
 * ``__builtin_isinf``


Index: clang/test/Sema/constant-builtins-fmax.cpp
===
--- /dev/null
+++ clang/test/Sema/constant-builtins-fmax.cpp
@@ -0,0 +1,54 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+// expected-no-diagnostics
+
+constexpr double NaN = __builtin_nan("");
+constexpr double Inf = __builtin_inf();
+constexpr double NegInf = -__builtin_inf();
+
+#define FMAX_TEST_SIMPLE(T, FUNC)   \
+static_assert(T(6.7890) == FUNC(T(1.2345), T(6.7890))); \
+static_assert(T(6.7890) == FUNC(T(6.7890), T(1.2345)));
+
+#define FMAX_TEST_NAN(T, FUNC)  \
+static_assert(Inf == FUNC(NaN, Inf));   \
+static_assert(NegInf == FUNC(NegInf, NaN)); \
+st

[PATCH] D131858: [clang] Track the templated entity in type substitution.

2022-10-04 Thread Erich Keane via Phabricator via cfe-commits

erichkeane added a comment.

Sorry for the long delay, the size of this makes it tough to review, and I've 
been trying to make sure my concepts patch didn't get reverted.  This generally 
looks good to me, however, I really don't like the number of bits to represent 
'template parameter' being inconsistent between bitfields in general.  I'm 
reasonably OK limiting it, but having 'surprise' limits only when we deal with 
replacements isn't really acceptable.  When we hit these limits, we should fail 
early.

Comment at: clang/include/clang/AST/Type.h:1838
 /// metaprogramming we'd prefer to keep it as large as possible.
-/// At the moment it has been left as a non-bitfield since this type
-/// safely fits in 64 bits as an unsigned, so there is no reason to
-/// introduce the performance impact of a bitfield.
-unsigned NumArgs;
+unsigned NumArgs : 16;
   };

mizvekov wrote:
> davrec wrote:
> > I can't imagine that limiting template arg index to 16 bits from 32 could 
> > be all that limiting, but given the comment in the original have you 
> > tested/confirmed that this is acceptable?
> Not yet, we will begin performance testing soon. But I am not concerned about 
> this one, as it's easy to get around this limitation by not using the 
> bitfields.
Did the testing here result in finding anyone who used this?  I'm sure libcxx 
or some of the boost libraries do a lot of MP on large sizes (though I note 
libcxx seems to have passed pre-commit).

Comment at: clang/include/clang/AST/Type.h:1836
+// The index of the template parameter this substitution represents.
+unsigned Index : 15;
+

Is it a problem for this to be a different number of bits used to represent the 
number of template parameters?  I would expect we would want to make them all 
them the same size (else we have an additional limit on the size of parameters).

Comment at: clang/include/clang/Sema/Template.h:104
 /// Construct a single-level template argument list.
-explicit
-MultiLevelTemplateArgumentList(const TemplateArgumentList &TemplateArgs) {
-  addOuterTemplateArguments(&TemplateArgs);
+explicit MultiLevelTemplateArgumentList(Decl *D, ArgList Args) {
+  addOuterTemplateArguments(D, Args);

2 parameters with no default means this doesn't have to be explicit anymore.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131858

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

[PATCH] D128745: [c++] implements DR692, DR1395 and tentatively DR1432, about partial ordering of variadic template partial specialization or function template

2022-10-04 Thread Roy Jacobson via Phabricator via cfe-commits

royjacobson added a comment.

Is there consensus that applying this DR resolution is distruptive enough that 
it's actually an issue? If clang-abi-compat is not a good way to offer 
backwards compatibility in this case, maybe we should just leave it be.

FWIW, I worry that applying it according to standard version will make it 
harder to write code that works cross version and the benefit here is not clear.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128745

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

[PATCH] D134046: [OpenMP][OMPIRBuilder] Add support for order(concurrent) to OMPIRBuilder for SIMD directive

2022-10-04 Thread Dominik Adamski via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rG6842d3501266: [OpenMP][OMPIRBuilder] Add support for 
order(concurrent) to OMPIRBuilder for… (authored by domada).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134046

Files:
  clang/lib/CodeGen/CGStmtOpenMP.cpp
  clang/test/OpenMP/irbuilder_safelen_order_concurrent.cpp
  llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h
  llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp
  llvm/unittests/Frontend/OpenMPIRBuilderTest.cpp
  mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp

Index: mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp
===
--- mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp
+++ mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp
@@ -996,11 +996,11 @@
   if (llvm::Optional safelenVar = loop.getSafelen())
 safelen = builder.getInt64(safelenVar.value());
 
-  ompBuilder->applySimd(loopInfo,
-loop.getIfExpr()
-? moduleTranslation.lookupValue(loop.getIfExpr())
-: nullptr,
-simdlen, safelen);
+  ompBuilder->applySimd(
+  loopInfo,
+  loop.getIfExpr() ? moduleTranslation.lookupValue(loop.getIfExpr())
+   : nullptr,
+  llvm::omp::OrderKind::OMP_ORDER_unknown, simdlen, safelen);
 
   builder.restoreIP(afterIP);
   return success();
Index: llvm/unittests/Frontend/OpenMPIRBuilderTest.cpp
===
--- llvm/unittests/Frontend/OpenMPIRBuilderTest.cpp
+++ llvm/unittests/Frontend/OpenMPIRBuilderTest.cpp
@@ -1771,7 +1771,8 @@
   CanonicalLoopInfo *CLI = buildSingleLoopFunction(DL, OMPBuilder, 32);
 
   // Simd-ize the loop.
-  OMPBuilder.applySimd(CLI, /* IfCond */ nullptr, /* Simdlen */ nullptr,
+  OMPBuilder.applySimd(CLI, /* IfCond */ nullptr, OrderKind::OMP_ORDER_unknown,
+   /* Simdlen */ nullptr,
/* Safelen */ nullptr);
 
   OMPBuilder.finalize();
@@ -1803,7 +1804,7 @@
   CanonicalLoopInfo *CLI = buildSingleLoopFunction(DL, OMPBuilder, 32);
 
   // Simd-ize the loop.
-  OMPBuilder.applySimd(CLI, /* IfCond */ nullptr,
+  OMPBuilder.applySimd(CLI, /* IfCond */ nullptr, OrderKind::OMP_ORDER_unknown,
ConstantInt::get(Type::getInt32Ty(Ctx), 3),
/* Safelen */ nullptr);
 
@@ -1831,13 +1832,49 @@
   }));
 }
 
+TEST_F(OpenMPIRBuilderTest, ApplySafelenOrderConcurrent) {
+  OpenMPIRBuilder OMPBuilder(*M);
+
+  CanonicalLoopInfo *CLI = buildSingleLoopFunction(DL, OMPBuilder, 32);
+
+  // Simd-ize the loop.
+  OMPBuilder.applySimd(
+  CLI, /* IfCond */ nullptr, OrderKind::OMP_ORDER_concurrent,
+  /* Simdlen */ nullptr, ConstantInt::get(Type::getInt32Ty(Ctx), 3));
+
+  OMPBuilder.finalize();
+  EXPECT_FALSE(verifyModule(*M, &errs()));
+
+  PassBuilder PB;
+  FunctionAnalysisManager FAM;
+  PB.registerFunctionAnalyses(FAM);
+  LoopInfo &LI = FAM.getResult(*F);
+
+  const std::vector &TopLvl = LI.getTopLevelLoops();
+  EXPECT_EQ(TopLvl.size(), 1u);
+
+  Loop *L = TopLvl.front();
+  // Parallel metadata shoudl be attached because of presence of
+  // the order(concurrent) OpenMP clause
+  EXPECT_TRUE(findStringMetadataForLoop(L, "llvm.loop.parallel_accesses"));
+  EXPECT_TRUE(getBooleanLoopAttribute(L, "llvm.loop.vectorize.enable"));
+  EXPECT_EQ(getIntLoopAttribute(L, "llvm.loop.vectorize.width"), 3);
+
+  // Check for llvm.access.group metadata attached to the printf
+  // function in the loop body.
+  BasicBlock *LoopBody = CLI->getBody();
+  EXPECT_TRUE(any_of(*LoopBody, [](Instruction &I) {
+return I.getMetadata("llvm.access.group") != nullptr;
+  }));
+}
+
 TEST_F(OpenMPIRBuilderTest, ApplySafelen) {
   OpenMPIRBuilder OMPBuilder(*M);
 
   CanonicalLoopInfo *CLI = buildSingleLoopFunction(DL, OMPBuilder, 32);
 
   // Simd-ize the loop.
-  OMPBuilder.applySimd(CLI, /* IfCond */ nullptr,
+  OMPBuilder.applySimd(CLI, /* IfCond */ nullptr, OrderKind::OMP_ORDER_unknown,
/* Simdlen */ nullptr,
ConstantInt::get(Type::getInt32Ty(Ctx), 3));
 
@@ -1871,7 +1908,7 @@
   CanonicalLoopInfo *CLI = buildSingleLoopFunction(DL, OMPBuilder, 32);
 
   // Simd-ize the loop.
-  OMPBuilder.applySimd(CLI, /* IfCond */ nullptr,
+  OMPBuilder.applySimd(CLI, /* IfCond */ nullptr, OrderKind::OMP_ORDER_unknown,
ConstantInt::get(Type::getInt32Ty(Ctx), 2),
ConstantInt::get(Type::getInt32Ty(Ctx), 3));
 
@@ -1916,7 +1953,8 @@
   CanonicalLoopInfo *CLI = buildSingleLoopFunction(DL, OMPBuilder, 32);
 
   // Simd-ize the loop with if condition
-  OMPBuilder.applySimd(CLI, IfCmp, ConstantInt::get(Type::getInt32Ty(Ctx), 3),
+  OMPBuilder.applySimd(CLI, IfCmp, Ord

[clang] 6842d35 - [OpenMP][OMPIRBuilder] Add support for order(concurrent) to OMPIRBuilder for SIMD directive

2022-10-04 Thread Dominik Adamski via cfe-commits


Author: Dominik Adamski
Date: 2022-10-04T08:30:00-05:00
New Revision: 6842d35012668d5dc3846fcbde136326e6e09bb3

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

LOG: [OpenMP][OMPIRBuilder] Add support for order(concurrent) to OMPIRBuilder 
for SIMD directive

If 'order(concurrent)' clause is specified, then the iterations of SIMD loop
can be executed concurrently.

This patch adds support for LLVM IR codegen via OMPIRBuilder for SIMD loop
with 'order(concurrent)' clause. The functionality added to OMPIRBuilder is
similar to the functionality implemented in 'CodeGenFunction::EmitOMPSimdInit'.

Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D134046

Signed-off-by: Dominik Adamski 

Added: 
clang/test/OpenMP/irbuilder_safelen_order_concurrent.cpp

Modified: 
clang/lib/CodeGen/CGStmtOpenMP.cpp
llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h
llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp
llvm/unittests/Frontend/OpenMPIRBuilderTest.cpp
mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGStmtOpenMP.cpp 
b/clang/lib/CodeGen/CGStmtOpenMP.cpp
index 1ffee9b94e734..d27e2c32c539a 100644
--- a/clang/lib/CodeGen/CGStmtOpenMP.cpp
+++ b/clang/lib/CodeGen/CGStmtOpenMP.cpp
@@ -2600,8 +2600,9 @@ static void emitOMPSimdRegion(CodeGenFunction &CGF, const 
OMPLoopDirective &S,
 static bool isSupportedByOpenMPIRBuilder(const OMPSimdDirective &S) {
   // Check for unsupported clauses
   for (OMPClause *C : S.clauses()) {
-// Currently only simdlen and safelen clauses are supported
-if (!(isa(C) || isa(C)))
+// Currently only order, simdlen and safelen clauses are supported
+if (!(isa(C) || isa(C) ||
+  isa(C)))
   return false;
   }
 
@@ -2660,9 +2661,15 @@ void CodeGenFunction::EmitOMPSimdDirective(const 
OMPSimdDirective &S) {
   auto *Val = cast(Len.getScalarVal());
   Safelen = Val;
 }
+llvm::omp::OrderKind Order = llvm::omp::OrderKind::OMP_ORDER_unknown;
+if (const auto *C = S.getSingleClause()) {
+  if (C->getKind() == OpenMPOrderClauseKind ::OMPC_ORDER_concurrent) {
+Order = llvm::omp::OrderKind::OMP_ORDER_concurrent;
+  }
+}
 // Add simd metadata to the collapsed loop. Do not generate
 // another loop for if clause. Support for if clause is done earlier.
-OMPBuilder.applySimd(CLI, /*IfCond*/ nullptr, Simdlen, Safelen);
+OMPBuilder.applySimd(CLI, /*IfCond*/ nullptr, Order, Simdlen, Safelen);
 return;
   }
 };

diff  --git a/clang/test/OpenMP/irbuilder_safelen_order_concurrent.cpp 
b/clang/test/OpenMP/irbuilder_safelen_order_concurrent.cpp
new file mode 100644
index 0..35a8d9b60a2fd
--- /dev/null
+++ b/clang/test/OpenMP/irbuilder_safelen_order_concurrent.cpp
@@ -0,0 +1,139 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py 
UTC_ARGS: --check-globals
+// RUN: %clang_cc1 -no-opaque-pointers -fopenmp-enable-irbuilder -verify 
-fopenmp -fopenmp-version=50 -x c++ -triple x86_64-unknown-unknown -emit-llvm 
%s -o - | FileCheck %s
+// expected-no-diagnostics
+
+struct S {
+  int a, b;
+};
+
+struct P {
+  int a, b;
+};
+
+// CHECK-LABEL: @_Z6simplePfS_Pi(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[A_ADDR:%.*]] = alloca float*, align 8
+// CHECK-NEXT:[[B_ADDR:%.*]] = alloca float*, align 8
+// CHECK-NEXT:[[C_ADDR:%.*]] = alloca i32*, align 8
+// CHECK-NEXT:[[S:%.*]] = alloca [[STRUCT_S:%.*]], align 4
+// CHECK-NEXT:[[P:%.*]] = alloca %struct.S*, align 8
+// CHECK-NEXT:[[PP:%.*]] = alloca [[STRUCT_P:%.*]], align 4
+// CHECK-NEXT:[[I:%.*]] = alloca i32, align 4
+// CHECK-NEXT:[[AGG_CAPTURED:%.*]] = alloca [[STRUCT_ANON:%.*]], align 8
+// CHECK-NEXT:[[AGG_CAPTURED1:%.*]] = alloca [[STRUCT_ANON_0:%.*]], align 4
+// CHECK-NEXT:[[DOTCOUNT_ADDR:%.*]] = alloca i32, align 4
+// CHECK-NEXT:[[J:%.*]] = alloca i32, align 4
+// CHECK-NEXT:[[AGG_CAPTURED8:%.*]] = alloca [[STRUCT_ANON_1:%.*]], align 8
+// CHECK-NEXT:[[AGG_CAPTURED9:%.*]] = alloca [[STRUCT_ANON_2:%.*]], align 4
+// CHECK-NEXT:[[DOTCOUNT_ADDR10:%.*]] = alloca i32, align 4
+// CHECK-NEXT:store float* [[A:%.*]], float** [[A_ADDR]], align 8
+// CHECK-NEXT:store float* [[B:%.*]], float** [[B_ADDR]], align 8
+// CHECK-NEXT:store i32* [[C:%.*]], i32** [[C_ADDR]], align 8
+// CHECK-NEXT:store i32 3, i32* [[I]], align 4
+// CHECK-NEXT:[[TMP0:%.*]] = getelementptr inbounds [[STRUCT_ANON]], 
%struct.anon* [[AGG_CAPTURED]], i32 0, i32 0
+// CHECK-NEXT:store i32* [[I]], i32** [[TMP0]], align 8
+// CHECK-NEXT:[[TMP1:%.*]] = getelementptr inbounds [[STRUCT_ANON_0]], 
%struct.anon.0* [[AGG_CAPTURED1

[PATCH] D135090: [Clang] fix -Wvoid-ptr-dereference for gnu89

2022-10-04 Thread Aaron Ballman via Phabricator via cfe-commits

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

LGTM!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135090

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

[PATCH] D135115: [clang-format] update --files help description

2022-10-04 Thread MyDeveloperDay via Phabricator via cfe-commits

MyDeveloperDay added a comment.

Its Is a minor point, but when using --files, the shell will allow me to 
autocomplete..

   clang-format -verbose -n -files ./cla
   clang-format -verbose -n -files ./clang/d
   etc...
  
  all the way to the file
   clang-format -verbose -n -files ./clang/docs/tools/clang-formatted-files.txt

with @ I have to be pixel perfect in my path..  so I'm more likely to go wrong

  clang-format -verbose -n @./cla does nothing.

that feels like a positive for the `--files`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135115

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

[PATCH] D134286: [C2x] implement typeof and typeof_unqual

2022-10-04 Thread Matheus Izvekov via Phabricator via cfe-commits

mizvekov added inline comments.



Comment at: clang/include/clang/AST/Type.h:4564
+  /// Returns true if this is a typeof_unqual type.
+  bool isUnqual() const { return TypeOfBits.IsUnqual; }
+

I only noticed this after rebasing some of my patches, I missed this on the 
original review (same for TypeOfType)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134286

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

[PATCH] D134820: [LTO][clang] Teaching Clang to Pass Plugin Options to the AIX Linker

2022-10-04 Thread Qiongsi Wu via Phabricator via cfe-commits

qiongsiwu1 updated this revision to Diff 464998.
qiongsiwu1 added a comment.

Address review comments. Remove unnecessary `Twine`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134820

Files:
  clang/lib/Driver/ToolChains/AIX.cpp
  clang/lib/Driver/ToolChains/AIX.h
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/lib/Driver/ToolChains/CommonArgs.h
  clang/test/Driver/lto-aix.c

Index: clang/test/Driver/lto-aix.c
===
--- /dev/null
+++ clang/test/Driver/lto-aix.c
@@ -0,0 +1,6 @@
+// Test LTO path, mcpu and opt level options
+// RUN: %clang --target=powerpc-ibm-aix -### %s -flto -fuse-ld=ld -O3 2>&1 \
+// RUN:   | FileCheck -check-prefixes=LTOPATH,MCPUOPTLEVEL %s
+//
+// LTOPATH: "-bplugin:{{.*}}libLTO.{{so|dll|dylib}}"
+// MCPUOPTLEVEL: "-bplugin_opt:-mcpu={{.*}}" "-bplugin_opt:-O3"
Index: clang/lib/Driver/ToolChains/CommonArgs.h
===
--- clang/lib/Driver/ToolChains/CommonArgs.h
+++ clang/lib/Driver/ToolChains/CommonArgs.h
@@ -190,7 +190,8 @@
  Multilib::flags_list &Flags);
 
 void addX86AlignBranchArgs(const Driver &D, const llvm::opt::ArgList &Args,
-   llvm::opt::ArgStringList &CmdArgs, bool IsLTO);
+   llvm::opt::ArgStringList &CmdArgs, bool IsLTO,
+   const StringRef PluginOptPrefix = "");
 
 void checkAMDGPUCodeObjectVersion(const Driver &D,
   const llvm::opt::ArgList &Args);
@@ -203,7 +204,8 @@
 
 void addMachineOutlinerArgs(const Driver &D, const llvm::opt::ArgList &Args,
 llvm::opt::ArgStringList &CmdArgs,
-const llvm::Triple &Triple, bool IsLTO);
+const llvm::Triple &Triple, bool IsLTO,
+const StringRef PluginOptPrefix = "");
 
 void addOpenMPDeviceRTL(const Driver &D, const llvm::opt::ArgList &DriverArgs,
 llvm::opt::ArgStringList &CC1Args,
Index: clang/lib/Driver/ToolChains/CommonArgs.cpp
===
--- clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -65,24 +65,26 @@
 using namespace clang;
 using namespace llvm::opt;
 
-static void renderRpassOptions(const ArgList &Args, ArgStringList &CmdArgs) {
+static void renderRpassOptions(const ArgList &Args, ArgStringList &CmdArgs,
+   const StringRef PluginOptPrefix) {
   if (const Arg *A = Args.getLastArg(options::OPT_Rpass_EQ))
-CmdArgs.push_back(Args.MakeArgString(Twine("-plugin-opt=-pass-remarks=") +
- A->getValue()));
+CmdArgs.push_back(Args.MakeArgString(Twine(PluginOptPrefix) +
+ "-pass-remarks=" + A->getValue()));
 
   if (const Arg *A = Args.getLastArg(options::OPT_Rpass_missed_EQ))
 CmdArgs.push_back(Args.MakeArgString(
-Twine("-plugin-opt=-pass-remarks-missed=") + A->getValue()));
+Twine(PluginOptPrefix) + "-pass-remarks-missed=" + A->getValue()));
 
   if (const Arg *A = Args.getLastArg(options::OPT_Rpass_analysis_EQ))
 CmdArgs.push_back(Args.MakeArgString(
-Twine("-plugin-opt=-pass-remarks-analysis=") + A->getValue()));
+Twine(PluginOptPrefix) + "-pass-remarks-analysis=" + A->getValue()));
 }
 
 static void renderRemarksOptions(const ArgList &Args, ArgStringList &CmdArgs,
  const llvm::Triple &Triple,
  const InputInfo &Input,
- const InputInfo &Output) {
+ const InputInfo &Output,
+ const StringRef PluginOptPrefix) {
   StringRef Format = "yaml";
   if (const Arg *A = Args.getLastArg(options::OPT_fsave_optimization_record_EQ))
 Format = A->getValue();
@@ -96,29 +98,32 @@
 
   assert(!F.empty() && "Cannot determine remarks output name.");
   // Append "opt.ld." to the end of the file name.
-  CmdArgs.push_back(
-  Args.MakeArgString(Twine("-plugin-opt=opt-remarks-filename=") + F +
- Twine(".opt.ld.") + Format));
+  CmdArgs.push_back(Args.MakeArgString(Twine(PluginOptPrefix) +
+   "opt-remarks-filename=" + F +
+   ".opt.ld." + Format));
 
   if (const Arg *A =
   Args.getLastArg(options::OPT_foptimization_record_passes_EQ))
 CmdArgs.push_back(Args.MakeArgString(
-Twine("-plugin-opt=opt-remarks-passes=") + A->getValue()));
+Twine(PluginOptPrefix) + "opt-remarks-passes=" + A->getValue()));
 
-  CmdArgs.push_back(Args.MakeArgString(
-  Twine("-plugin-opt=opt-remarks-format=") + Format.data()));
+  CmdArgs.push_back(Args.MakeArgStri

[PATCH] D134654: [clang] Detect header loops

2022-10-04 Thread Nathan Sidwell via Phabricator via cfe-commits

urnathan updated this revision to Diff 465006.

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

https://reviews.llvm.org/D134654

Files:
  clang/include/clang/Basic/FileEntry.h
  clang/lib/Lex/PPDirectives.cpp
  clang/lib/Lex/PPLexerChange.cpp


Index: clang/lib/Lex/PPLexerChange.cpp
===
--- clang/lib/Lex/PPLexerChange.cpp
+++ clang/lib/Lex/PPLexerChange.cpp
@@ -103,6 +103,10 @@
 }
   }
 
+  if (TheLexer->getPP())
+if (auto *FE = SourceMgr.getFileEntryForID(FID))
+  FE->EnterOrLeave(true);
+
   EnterSourceFileWithLexer(TheLexer, CurDir);
   return false;
 }
@@ -432,6 +436,10 @@
   // lexing the #includer file.
   if (!IncludeMacroStack.empty()) {
 
+if (CurPPLexer)
+  if (auto *FE = SourceMgr.getFileEntryForID(CurPPLexer->getFileID()))
+FE->EnterOrLeave(false);
+
 // If we lexed the code-completion file, act as if we reached EOF.
 if (isCodeCompletionEnabled() && CurPPLexer &&
 SourceMgr.getLocForStartOfFile(CurPPLexer->getFileID()) ==
Index: clang/lib/Lex/PPDirectives.cpp
===
--- clang/lib/Lex/PPDirectives.cpp
+++ clang/lib/Lex/PPDirectives.cpp
@@ -2329,6 +2329,9 @@
 
   bool IsFirstIncludeOfFile = false;
 
+  if (Action == Enter && File && File->getFileEntry().isEntered())
+Diag(FilenameTok.getLocation(), diag::warn_include_cycle);
+
   // Ask HeaderInfo if we should enter this #include file.  If not, #including
   // this file will have no effect.
   if (Action == Enter && File &&
Index: clang/include/clang/Basic/FileEntry.h
===
--- clang/include/clang/Basic/FileEntry.h
+++ clang/include/clang/Basic/FileEntry.h
@@ -359,6 +359,9 @@
   const DirectoryEntry *Dir = nullptr; // Directory file lives in.
   llvm::sys::fs::UniqueID UniqueID;
   unsigned UID = 0; // A unique (small) ID for the file.
+  // Bitfieldiness  v, mutabley?
+  // Maybe the including machinery should use a map??
+  mutable unsigned Includedness = 0; // FIXME:DOCUMENT
   bool IsNamedPipe = false;
 
   /// The open file, if it is owned by the \p FileEntry.
@@ -393,6 +396,12 @@
   /// the native FileManager methods).
   bool isNamedPipe() const { return IsNamedPipe; }
 
+  bool isEntered() const { return Includedness != 0; }
+  void EnterOrLeave(bool Enter) const {
+assert(Enter || Includedness);
+Includedness += Enter ? +1 : -1;
+  }
+
   void closeFile() const;
 };
 


Index: clang/lib/Lex/PPLexerChange.cpp
===
--- clang/lib/Lex/PPLexerChange.cpp
+++ clang/lib/Lex/PPLexerChange.cpp
@@ -103,6 +103,10 @@
 }
   }
 
+  if (TheLexer->getPP())
+if (auto *FE = SourceMgr.getFileEntryForID(FID))
+  FE->EnterOrLeave(true);
+
   EnterSourceFileWithLexer(TheLexer, CurDir);
   return false;
 }
@@ -432,6 +436,10 @@
   // lexing the #includer file.
   if (!IncludeMacroStack.empty()) {
 
+if (CurPPLexer)
+  if (auto *FE = SourceMgr.getFileEntryForID(CurPPLexer->getFileID()))
+FE->EnterOrLeave(false);
+
 // If we lexed the code-completion file, act as if we reached EOF.
 if (isCodeCompletionEnabled() && CurPPLexer &&
 SourceMgr.getLocForStartOfFile(CurPPLexer->getFileID()) ==
Index: clang/lib/Lex/PPDirectives.cpp
===
--- clang/lib/Lex/PPDirectives.cpp
+++ clang/lib/Lex/PPDirectives.cpp
@@ -2329,6 +2329,9 @@
 
   bool IsFirstIncludeOfFile = false;
 
+  if (Action == Enter && File && File->getFileEntry().isEntered())
+Diag(FilenameTok.getLocation(), diag::warn_include_cycle);
+
   // Ask HeaderInfo if we should enter this #include file.  If not, #including
   // this file will have no effect.
   if (Action == Enter && File &&
Index: clang/include/clang/Basic/FileEntry.h
===
--- clang/include/clang/Basic/FileEntry.h
+++ clang/include/clang/Basic/FileEntry.h
@@ -359,6 +359,9 @@
   const DirectoryEntry *Dir = nullptr; // Directory file lives in.
   llvm::sys::fs::UniqueID UniqueID;
   unsigned UID = 0; // A unique (small) ID for the file.
+  // Bitfieldiness  v, mutabley?
+  // Maybe the including machinery should use a map??
+  mutable unsigned Includedness = 0; // FIXME:DOCUMENT
   bool IsNamedPipe = false;
 
   /// The open file, if it is owned by the \p FileEntry.
@@ -393,6 +396,12 @@
   /// the native FileManager methods).
   bool isNamedPipe() const { return IsNamedPipe; }
 
+  bool isEntered() const { return Includedness != 0; }
+  void EnterOrLeave(bool Enter) const {
+assert(Enter || Includedness);
+Includedness += Enter ? +1 : -1;
+  }
+
   void closeFile() const;
 };
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D134654: [clang] Detect header loops

2022-10-04 Thread Nathan Sidwell via Phabricator via cfe-commits

urnathan updated this revision to Diff 465007.
urnathan marked an inline comment as done.

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

https://reviews.llvm.org/D134654

Files:
  clang/include/clang/Basic/DiagnosticLexKinds.td
  clang/include/clang/Lex/Preprocessor.h
  clang/include/clang/Lex/PreprocessorLexer.h
  clang/lib/Lex/PPDirectives.cpp
  clang/lib/Lex/PPLexerChange.cpp
  clang/test/Preprocessor/warn-loop-import-1.h
  clang/test/Preprocessor/warn-loop-macro-1.h
  clang/test/Preprocessor/warn-loop-macro-2.h
  clang/test/Preprocessor/warn-loop-macro-2a.h
  clang/test/Preprocessor/warn-loop-main.c
  clang/test/Preprocessor/warn-loop-pragma-1.h

Index: clang/test/Preprocessor/warn-loop-pragma-1.h
===
--- /dev/null
+++ clang/test/Preprocessor/warn-loop-pragma-1.h
@@ -0,0 +1,3 @@
+#pragma once
+// expected-warning@+1 {{#include cycle}}
+#include "warn-loop-pragma-1.h"
Index: clang/test/Preprocessor/warn-loop-main.c
===
--- /dev/null
+++ clang/test/Preprocessor/warn-loop-main.c
@@ -0,0 +1,7 @@
+// RUN: %clang_cc1 -Winclude-cycle -fsyntax-only -verify %s
+
+#include "warn-loop-macro-1.h"
+#include "warn-loop-macro-2.h"
+#include "warn-loop-macro-1.h"
+#include "warn-loop-import-1.h"
+#include "warn-loop-pragma-1.h"
Index: clang/test/Preprocessor/warn-loop-macro-2a.h
===
--- /dev/null
+++ clang/test/Preprocessor/warn-loop-macro-2a.h
@@ -0,0 +1,5 @@
+#ifndef LOOP_MACRO_2a
+#define LOOP_MACRO_2a
+// expected-warning@+1 {{#include cycle}}
+#include "warn-loop-macro-2.h"
+#endif
Index: clang/test/Preprocessor/warn-loop-macro-2.h
===
--- /dev/null
+++ clang/test/Preprocessor/warn-loop-macro-2.h
@@ -0,0 +1,6 @@
+#ifndef LOOP_MACRO_2
+#define LOOP_MACRO_2
+#include "warn-loop-macro-2a.h"
+// expected-warning@+1 {{#include cycle}}
+#include "warn-loop-macro-2.h"
+#endif
Index: clang/test/Preprocessor/warn-loop-macro-1.h
===
--- /dev/null
+++ clang/test/Preprocessor/warn-loop-macro-1.h
@@ -0,0 +1,5 @@
+#ifndef LOOP_MACRO_1
+#define LOOP_MACRO_1
+// expected-warning@+1 {{#include cycle}}
+#include "warn-loop-macro-1.h"
+#endif
Index: clang/test/Preprocessor/warn-loop-import-1.h
===
--- /dev/null
+++ clang/test/Preprocessor/warn-loop-import-1.h
@@ -0,0 +1,2 @@
+// expected-warning@+1 {{#include cycle}}
+#import "warn-loop-import-1.h"
Index: clang/lib/Lex/PPLexerChange.cpp
===
--- clang/lib/Lex/PPLexerChange.cpp
+++ clang/lib/Lex/PPLexerChange.cpp
@@ -103,6 +103,12 @@
 }
   }
 
+  if (const FileEntry *FE = SourceMgr.getFileEntryForID(FID)) {
+const auto &[I, Added] = ActiveIncludedFiles.insert(FE);
+if (!Added)
+  TheLexer->setCircularInclude();
+  }
+
   EnterSourceFileWithLexer(TheLexer, CurDir);
   return false;
 }
@@ -432,6 +438,11 @@
   // lexing the #includer file.
   if (!IncludeMacroStack.empty()) {
 
+if (CurPPLexer && !CurPPLexer->isCircularInclude())
+  if (const FileEntry *FE =
+  SourceMgr.getFileEntryForID(CurPPLexer->getFileID()))
+ActiveIncludedFiles.erase(FE);
+
 // If we lexed the code-completion file, act as if we reached EOF.
 if (isCodeCompletionEnabled() && CurPPLexer &&
 SourceMgr.getLocForStartOfFile(CurPPLexer->getFileID()) ==
Index: clang/lib/Lex/PPDirectives.cpp
===
--- clang/lib/Lex/PPDirectives.cpp
+++ clang/lib/Lex/PPDirectives.cpp
@@ -2318,6 +2318,13 @@
 FileCharacter = std::max(HeaderInfo.getFileDirFlavor(&File->getFileEntry()),
  FileCharacter);
 
+  // Check if we're considering entering a file that is already active in the
+  // include stack.  Even if File is idempotent, these cycles are problematic
+  // for modularization.
+  if (Action == Enter && File &&
+  ActiveIncludedFiles.contains(&File->getFileEntry()))
+Diag(FilenameTok.getLocation(), diag::warn_include_cycle);
+
   // If this is a '#import' or an import-declaration, don't re-enter the file.
   //
   // FIXME: If we have a suggested module for a '#include', and we've already
Index: clang/include/clang/Lex/PreprocessorLexer.h
===
--- clang/include/clang/Lex/PreprocessorLexer.h
+++ clang/include/clang/Lex/PreprocessorLexer.h
@@ -67,6 +67,9 @@
   /// Note that in raw mode that the PP pointer may be null.
   bool LexingRawMode = false;
 
+  /// Record whether this lexer is for a recursive include.
+  bool IsCircularInclude = false;
+
   /// A state machine that detects the \#ifndef-wrapping a file
   /// idiom for the multiple-include optimiz

[PATCH] D134654: [clang] Detect header loops

2022-10-04 Thread Nathan Sidwell via Phabricator via cfe-commits

urnathan marked 2 inline comments as done.
urnathan added inline comments.



Comment at: clang/include/clang/Basic/DiagnosticLexKinds.td:323
   "whitespace recommended after macro name">;
+def warn_include_cycle : Warning<"#include cycle">,
+   InGroup>, DefaultIgnore;

aaron.ballman wrote:
> This diagnostic doesn't really seem like it's going to help the user to know 
> what's wrong with their code or how to fix it. (Also, the notes @erichkeane 
> was hoping were emitted don't seem to be, at least according to the new test 
> cases.) I think we need to give users a bit more guidance here.
The test infrastructire ignores the 'included from ' chain, which is emitted.  
What do you suggest?



Comment at: clang/include/clang/Basic/DiagnosticLexKinds.td:324
+def warn_include_cycle : Warning<"#include cycle">,
+   InGroup>, DefaultIgnore;
 

aaron.ballman wrote:
> We have a reasonable amount of evidence that off-by-default warnings remain 
> off for basically everyone. Can we do anything to enable this diagnostic by 
> default? e.g., would it make sense to enable it by default when trying to 
> build a module but otherwise silence it?
That's probably a good idea -- I didnt want to put it unconditionally on, 
because it triggers all over the testsuite due to intentional self-inclusion



Comment at: clang/lib/Lex/PPLexerChange.cpp:107
+  if (const FileEntry *FE = SourceMgr.getFileEntryForID(FID)) {
+auto [I, Added] = ActiveIncludedFiles.insert(FE);
+if (!Added)

erichkeane wrote:
> The iterator is somewhat costly (at least 2 pointers?) and since we're not 
> accessing them, copying them into the structured binding object probably 
> isn't valuable?  
I'd be very disappointed it the optimizer can't see through that and elide the 
copies here. (but I had misremembered how  structured bindings are not 
references to the temporary by default anyway)


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

https://reviews.llvm.org/D134654

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

[PATCH] D135159: [clang-tools-extra] [test] Use CLANG_NO_DEFAULT_CONFIG=1

2022-10-04 Thread Michał Górny via Phabricator via cfe-commits

mgorny created this revision.
mgorny added reviewers: sammccall, MaskRay, sepavloff.
Herald added subscribers: StephenFan, kadircet, arphaman.
Herald added a project: All.
mgorny requested review of this revision.
Herald added a project: clang-tools-extra.

Set CLANG_NO_DEFAULT_CONFIG=1 for clang-tools-extra tests to prevent
the system configuration files for clang from affecting the test
results.


https://reviews.llvm.org/D135159

Files:
  clang-tools-extra/clangd/test/lit.cfg.py
  clang-tools-extra/clangd/unittests/lit.cfg.py
  clang-tools-extra/include-cleaner/test/Unit/lit.cfg.py
  clang-tools-extra/include-cleaner/test/lit.cfg.py
  clang-tools-extra/pseudo/test/Unit/lit.cfg.py
  clang-tools-extra/pseudo/test/lit.cfg.py
  clang-tools-extra/test/Unit/lit.cfg.py
  clang-tools-extra/test/lit.cfg.py

Index: clang-tools-extra/test/lit.cfg.py
===
--- clang-tools-extra/test/lit.cfg.py
+++ clang-tools-extra/test/lit.cfg.py
@@ -59,3 +59,8 @@
 # Plugins (loadable modules)
 if config.has_plugins and config.llvm_plugin_ext:
 config.available_features.add('plugins')
+
+# It is not realistically possible to account for all options that could
+# possibly be present in system and user configuration files, so disable
+# default configs for the test runs.
+config.environment["CLANG_NO_DEFAULT_CONFIG"] = "1"
Index: clang-tools-extra/test/Unit/lit.cfg.py
===
--- clang-tools-extra/test/Unit/lit.cfg.py
+++ clang-tools-extra/test/Unit/lit.cfg.py
@@ -35,3 +35,8 @@
 shlibpath = os.path.pathsep.join((config.shlibdir, shlibpath))
 
 config.environment[shlibpath_var] = shlibpath
+
+# It is not realistically possible to account for all options that could
+# possibly be present in system and user configuration files, so disable
+# default configs for the test runs.
+config.environment["CLANG_NO_DEFAULT_CONFIG"] = "1"
Index: clang-tools-extra/pseudo/test/lit.cfg.py
===
--- clang-tools-extra/pseudo/test/lit.cfg.py
+++ clang-tools-extra/pseudo/test/lit.cfg.py
@@ -14,3 +14,8 @@
 config.clang_tools_dir,
 config.llvm_tools_dir,
 config.environment['PATH']))
+
+# It is not realistically possible to account for all options that could
+# possibly be present in system and user configuration files, so disable
+# default configs for the test runs.
+config.environment["CLANG_NO_DEFAULT_CONFIG"] = "1"
Index: clang-tools-extra/pseudo/test/Unit/lit.cfg.py
===
--- clang-tools-extra/pseudo/test/Unit/lit.cfg.py
+++ clang-tools-extra/pseudo/test/Unit/lit.cfg.py
@@ -17,3 +17,7 @@
 "@SHLIBDIR@", "@LLVM_LIBS_DIR@",
 config.environment.get(shlibpath_var,'')))
 
+# It is not realistically possible to account for all options that could
+# possibly be present in system and user configuration files, so disable
+# default configs for the test runs.
+config.environment["CLANG_NO_DEFAULT_CONFIG"] = "1"
Index: clang-tools-extra/include-cleaner/test/lit.cfg.py
===
--- clang-tools-extra/include-cleaner/test/lit.cfg.py
+++ clang-tools-extra/include-cleaner/test/lit.cfg.py
@@ -14,3 +14,8 @@
 config.clang_tools_dir,
 config.llvm_tools_dir,
 config.environment['PATH']))
+
+# It is not realistically possible to account for all options that could
+# possibly be present in system and user configuration files, so disable
+# default configs for the test runs.
+config.environment["CLANG_NO_DEFAULT_CONFIG"] = "1"
Index: clang-tools-extra/include-cleaner/test/Unit/lit.cfg.py
===
--- clang-tools-extra/include-cleaner/test/Unit/lit.cfg.py
+++ clang-tools-extra/include-cleaner/test/Unit/lit.cfg.py
@@ -16,3 +16,8 @@
 config.environment[shlibpath_var] = os.path.pathsep.join((
 "@SHLIBDIR@", "@LLVM_LIBS_DIR@",
 config.environment.get(shlibpath_var,'')))
+
+# It is not realistically possible to account for all options that could
+# possibly be present in system and user configuration files, so disable
+# default configs for the test runs.
+config.environment["CLANG_NO_DEFAULT_CONFIG"] = "1"
Index: clang-tools-extra/clangd/unittests/lit.cfg.py
===
--- clang-tools-extra/clangd/unittests/lit.cfg.py
+++ clang-tools-extra/clangd/unittests/lit.cfg.py
@@ -17,5 +17,7 @@
 "@SHLIBDIR@", "@LLVM_LIBS_DIR@",
 config.environment.get(shlibpath_var,'')))
 
-
-
+# It is not realistically possible to account for all options that could
+# possibly be present in system and user configuration files, so disable
+# default configs for the test runs.
+config.environment["CLANG_NO_DEFAULT_CONFIG"] = "1"
Index: clang-tools-extra/clangd/test/lit.cfg.py
===

[PATCH] D134791: [clang] Unify Sema and CodeGen implementation of isFlexibleArrayMemberExpr

2022-10-04 Thread Aaron Ballman via Phabricator via cfe-commits

aaron.ballman added a comment.

In general, this looks reasonable to me.




Comment at: clang/include/clang/AST/Expr.h:529
+  /// When IgnoreTemplateOrMacroSubstitution is set, it doesn't consider sizes
+  /// resulting from substitution of macro or template as special sizes.
+  bool isFlexibleArrayMemberLike(





Comment at: clang/include/clang/AST/Expr.h:531
+  bool isFlexibleArrayMemberLike(
+  ASTContext &Context, unsigned StrictFlexArraysLevel,
+  bool IgnoreTemplateOrMacroSubstitution = false) const;

Do we want to make the array levels into an enumeration instead of letting the 
user pass arbitrary integers? (Perhaps not as part of this review.)



Comment at: clang/lib/AST/Expr.cpp:244-247
+  if (const auto *FD = dyn_cast(ND)) {
+
+if (FD->getParent()->isUnion())
+  return true;




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

https://reviews.llvm.org/D134791

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

[PATCH] D135012: [clang][Interp] Implement bitwise and operations

2022-10-04 Thread Shafik Yaghmour via Phabricator via cfe-commits

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

LGTM




Comment at: clang/test/AST/Interp/literals.cpp:289
+  static_assert((1337 & -1) == 1337, "");
+  static_assert((0 & gimme(12)) == 0, "");
+};

Why `gimme(12)` and not just `12`?


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

https://reviews.llvm.org/D135012

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

[PATCH] D128745: [c++] implements DR692, DR1395 and tentatively DR1432, about partial ordering of variadic template partial specialization or function template

2022-10-04 Thread Hubert Tong via Phabricator via cfe-commits

hubert.reinterpretcast added a comment.

In D128745#3833291 , @aaron.ballman 
wrote:

> @rjmccall is correct about us not being required to apply DRs when they're 
> disruptive, but at the same time, WG21 DRs are intended to be handled as if 
> the original standard they were reported against had always been using the 
> fixed form. So *not* applying a DR in order to avoid problems for existing 
> code can cause problems for existing and future code in terms of portability 
> between compilers (and ABI impacts that stem from the semantic changes). So I 
> think we wish to apply the DRs as broadly as we can. The question is: do we 
> think users with existing code should not have to change or do we think it's 
> reasonable to give them a flag to opt into the old behavior? My personal 
> feeling is -- the default compiler mode should be as conforming as we can 
> make it be within reason, and since this has some impact but not a massive 
> break (no major OS SDKs or third party libraries seem to be impacted as best 
> I can tell), my feeling is that we should strongly consider adding a feature 
> flag (other than ABI compat, as that does seem like a bit of an odd choice to 
> key on) to opt into the older behavior, esp since the break is a loud one and 
> not a silent one.
>
> Adding @hubert.reinterpretcast as C++ conformance code owner in case he's got 
> opinions as well.

I happen to be on vacation this week ahead of Canadian Thanksgiving (or trying 
as much as I can anyway). I agree that broad application of DRs is generally 
what has been expected in the context of Clang and GCC (except where it is 
believed the DR resolution itself is defective, in which case the committee is 
consulted).

It seems there is a question of whether the DR resolutions are defective/too 
breaking to be advisable. Do we have a useful summary of what led to that 
opinion?

In considering a compatibility flag, I think some thought should be given to 
whether to time-limit it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128745

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

[PATCH] D135025: [clang][Interp] Support base class constructors

2022-10-04 Thread Shafik Yaghmour via Phabricator via cfe-commits

shafik added a comment.

This looks good to me but I would like one other set of eyes on it


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

https://reviews.llvm.org/D135025

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

[PATCH] D135025: [clang][Interp] Support base class constructors

2022-10-04 Thread Erich Keane via Phabricator via cfe-commits

erichkeane added inline comments.



Comment at: clang/lib/AST/Interp/ByteCodeExprGen.h:263
+QualType T = E->getType();
+if (const auto *PT = dyn_cast(T))
+  T = PT->getPointeeType();

We are de-pointering here, why not de-referencing? 

If we are OK with that, we can do this as:

``` if (const auto *RD = T->getPointeeCXXRecordDecl()) 
  return RD;
return T->getAsCXXRecordDecl();
```
and most of the work is done for you.




Comment at: clang/test/AST/Interp/records.cpp:165
+
+class A : public Base {
+public:

shafik wrote:
> How about also testing `private` and `virtual` as well as multiple bases.
I like the idea of testing virtual bases as well.


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

https://reviews.llvm.org/D135025

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

[PATCH] D135161: [clang][Lex] Fix a crash on malformed string literals

2022-10-04 Thread Kadir Cetinkaya via Phabricator via cfe-commits

kadircet created this revision.
kadircet added a reviewer: hokein.
Herald added a project: All.
kadircet requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D135161

Files:
  clang/lib/Lex/LiteralSupport.cpp
  clang/test/Lexer/char-escapes-delimited.c
  clang/unittests/Lex/LexerTest.cpp


Index: clang/unittests/Lex/LexerTest.cpp
===
--- clang/unittests/Lex/LexerTest.cpp
+++ clang/unittests/Lex/LexerTest.cpp
@@ -18,6 +18,7 @@
 #include "clang/Basic/TokenKinds.h"
 #include "clang/Lex/HeaderSearch.h"
 #include "clang/Lex/HeaderSearchOptions.h"
+#include "clang/Lex/LiteralSupport.h"
 #include "clang/Lex/MacroArgs.h"
 #include "clang/Lex/MacroInfo.h"
 #include "clang/Lex/ModuleLoader.h"
@@ -659,4 +660,11 @@
   }
   EXPECT_TRUE(ToksView.empty());
 }
+
+TEST_F(LexerTest, BrokenStringLiteral) {
+  const llvm::StringLiteral Source = R"cpp("\N")cpp";
+  // Make sure this isn't crashing.
+  StringLiteralParser P(Lex(Source), *PP);
+  EXPECT_TRUE(P.hadError);
+}
 } // anonymous namespace
Index: clang/test/Lexer/char-escapes-delimited.c
===
--- clang/test/Lexer/char-escapes-delimited.c
+++ clang/test/Lexer/char-escapes-delimited.c
@@ -94,7 +94,7 @@
 
   unsigned h = U'\N{LOTUS}';  // ext-warning {{extension}} 
cxx2b-warning {{C++2b}}
   unsigned i = u'\N{GREEK CAPITAL LETTER DELTA}'; // ext-warning {{extension}} 
cxx2b-warning {{C++2b}}
-  char j = '\NN'; // expected-error {{expected 
'{' after '\N' escape sequence}}
+  char j = '\NN'; // expected-error {{expected 
'{' after '\N' escape sequence}} expected-warning {{multi-character character 
constant}}
   unsigned k = u'\N{LOTUS';   // expected-error 
{{incomplete universal character name}}
 }
 
Index: clang/lib/Lex/LiteralSupport.cpp
===
--- clang/lib/Lex/LiteralSupport.cpp
+++ clang/lib/Lex/LiteralSupport.cpp
@@ -545,7 +545,6 @@
diag::err_delimited_escape_missing_brace)
   << StringRef(&ThisTokBuf[-1], 1);
 }
-ThisTokBuf++;
 return false;
   }
   ThisTokBuf++;


Index: clang/unittests/Lex/LexerTest.cpp
===
--- clang/unittests/Lex/LexerTest.cpp
+++ clang/unittests/Lex/LexerTest.cpp
@@ -18,6 +18,7 @@
 #include "clang/Basic/TokenKinds.h"
 #include "clang/Lex/HeaderSearch.h"
 #include "clang/Lex/HeaderSearchOptions.h"
+#include "clang/Lex/LiteralSupport.h"
 #include "clang/Lex/MacroArgs.h"
 #include "clang/Lex/MacroInfo.h"
 #include "clang/Lex/ModuleLoader.h"
@@ -659,4 +660,11 @@
   }
   EXPECT_TRUE(ToksView.empty());
 }
+
+TEST_F(LexerTest, BrokenStringLiteral) {
+  const llvm::StringLiteral Source = R"cpp("\N")cpp";
+  // Make sure this isn't crashing.
+  StringLiteralParser P(Lex(Source), *PP);
+  EXPECT_TRUE(P.hadError);
+}
 } // anonymous namespace
Index: clang/test/Lexer/char-escapes-delimited.c
===
--- clang/test/Lexer/char-escapes-delimited.c
+++ clang/test/Lexer/char-escapes-delimited.c
@@ -94,7 +94,7 @@
 
   unsigned h = U'\N{LOTUS}';  // ext-warning {{extension}} cxx2b-warning {{C++2b}}
   unsigned i = u'\N{GREEK CAPITAL LETTER DELTA}'; // ext-warning {{extension}} cxx2b-warning {{C++2b}}
-  char j = '\NN'; // expected-error {{expected '{' after '\N' escape sequence}}
+  char j = '\NN'; // expected-error {{expected '{' after '\N' escape sequence}} expected-warning {{multi-character character constant}}
   unsigned k = u'\N{LOTUS';   // expected-error {{incomplete universal character name}}
 }
 
Index: clang/lib/Lex/LiteralSupport.cpp
===
--- clang/lib/Lex/LiteralSupport.cpp
+++ clang/lib/Lex/LiteralSupport.cpp
@@ -545,7 +545,6 @@
diag::err_delimited_escape_missing_brace)
   << StringRef(&ThisTokBuf[-1], 1);
 }
-ThisTokBuf++;
 return false;
   }
   ThisTokBuf++;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D135012: [clang][Interp] Implement bitwise and operations

2022-10-04 Thread Timm Bäder via Phabricator via cfe-commits

tbaeder added inline comments.



Comment at: clang/test/AST/Interp/literals.cpp:289
+  static_assert((1337 & -1) == 1337, "");
+  static_assert((0 & gimme(12)) == 0, "");
+};

shafik wrote:
> Why `gimme(12)` and not just `12`?
I just thought it might be useful to test something that's not a literal.


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

https://reviews.llvm.org/D135012

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

[PATCH] D135115: [clang-format] update --files help description

2022-10-04 Thread Paul Robinson via Phabricator via cfe-commits

probinson added inline comments.



Comment at: clang/docs/ClangFormat.rst:72-73
  Used only with --dry-run or -n
---files=   - Provide a list of files to run 
clang-format
+--files=   - Accept a list of response files 
(Deprecated. Use
+ 'clang-format @file' if possbile).
 -i - Inplace edit s, if specified.

MyDeveloperDay wrote:
> if you google "response files" you don't get anything that leads to 
> understand what they are. I understand what it means but I'm not convinced 
> others who have not come across it before will. I don't personally think this 
> change adds anything.
I was thinking something like this.  In particular, call the argument a 
"filename" and then say what it should look like.  The old description with a 
"string" argument reads like it might want to be 
`--files=file1,file2,file3` 
or something like that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135115

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

[PATCH] D135161: [clang][Lex] Fix a crash on malformed string literals

2022-10-04 Thread Tom Honermann via Phabricator via cfe-commits

tahonermann added subscribers: cor3ntin, tahonermann.
tahonermann added a reviewer: cor3ntin.
tahonermann added a comment.

I think this looks right, but it would be good for @cor3ntin to take a look.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135161

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

[PATCH] D135025: [clang][Interp] Support base class constructors

2022-10-04 Thread Timm Bäder via Phabricator via cfe-commits

tbaeder marked an inline comment as done.
tbaeder added inline comments.



Comment at: clang/lib/AST/Interp/ByteCodeExprGen.h:263
+QualType T = E->getType();
+if (const auto *PT = dyn_cast(T))
+  T = PT->getPointeeType();

erichkeane wrote:
> We are de-pointering here, why not de-referencing? 
> 
> If we are OK with that, we can do this as:
> 
> ``` if (const auto *RD = T->getPointeeCXXRecordDecl()) 
>   return RD;
> return T->getAsCXXRecordDecl();
> ```
> and most of the work is done for you.
> 
No reason, as usual I just didn't know this was a thing. Thanks!



Comment at: clang/test/AST/Interp/records.cpp:165
+
+class A : public Base {
+public:

erichkeane wrote:
> shafik wrote:
> > How about also testing `private` and `virtual` as well as multiple bases.
> I like the idea of testing virtual bases as well.
How would that work in a constexpr context? I get:

```
array.cpp:48:15: error: constexpr constructor not allowed in class with virtual 
base class
constexpr D() : A(17) {}
  ^
array.cpp:45:13: note: virtual base class declared here
  class B : public virtual A {};
^~~~
1 error generated.
```



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

https://reviews.llvm.org/D135025

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

[PATCH] D135161: [clang][Lex] Fix a crash on malformed string literals

2022-10-04 Thread Corentin Jabot via Phabricator via cfe-commits

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

Yes, this looks reasonable. The additional warning is somewhat unfortunate, and 
we could avoid it, but at the same time i don't expect it would bother anyone 
given how unlikely the scenario is to begin with.

Thanks for fixing that!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135161

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

[PATCH] D135025: [clang][Interp] Support base class constructors

2022-10-04 Thread Erich Keane via Phabricator via cfe-commits

erichkeane added inline comments.



Comment at: clang/test/AST/Interp/records.cpp:165
+
+class A : public Base {
+public:

tbaeder wrote:
> erichkeane wrote:
> > shafik wrote:
> > > How about also testing `private` and `virtual` as well as multiple bases.
> > I like the idea of testing virtual bases as well.
> How would that work in a constexpr context? I get:
> 
> ```
> array.cpp:48:15: error: constexpr constructor not allowed in class with 
> virtual base class
> constexpr D() : A(17) {}
>   ^
> array.cpp:45:13: note: virtual base class declared here
>   class B : public virtual A {};
> ^~~~
> 1 error generated.
> ```
> 
Ah! TIL, thanks!


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

https://reviews.llvm.org/D135025

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

[PATCH] D135025: [clang][Interp] Support base class constructors

2022-10-04 Thread Timm Bäder via Phabricator via cfe-commits

tbaeder marked an inline comment as done.
tbaeder added inline comments.



Comment at: clang/test/AST/Interp/records.cpp:165
+
+class A : public Base {
+public:

erichkeane wrote:
> tbaeder wrote:
> > erichkeane wrote:
> > > shafik wrote:
> > > > How about also testing `private` and `virtual` as well as multiple 
> > > > bases.
> > > I like the idea of testing virtual bases as well.
> > How would that work in a constexpr context? I get:
> > 
> > ```
> > array.cpp:48:15: error: constexpr constructor not allowed in class with 
> > virtual base class
> > constexpr D() : A(17) {}
> >   ^
> > array.cpp:45:13: note: virtual base class declared here
> >   class B : public virtual A {};
> > ^~~~
> > 1 error generated.
> > ```
> > 
> Ah! TIL, thanks!
Ah, this works: https://godbolt.org/z/ern3Yje9q


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

https://reviews.llvm.org/D135025

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

[PATCH] D135169: [LLDB] Fix printing a static bool struct member when using "image lookup -t"

2022-10-04 Thread David Spickett via Phabricator via cfe-commits

DavidSpickett created this revision.
Herald added a reviewer: shafik.
Herald added a project: All.
DavidSpickett requested review of this revision.
Herald added projects: clang, LLDB.
Herald added subscribers: lldb-commits, cfe-commits.

Fixes #58135

Somehow lldb was able to print the member on its own but when we try
to print the whole type found by "image lookup -t" lldb would crash.

This is because we'd encoded the initial value of the member as an integer.
Which isn't the end of the world because bool is integral for C++.
However, clang has a special AST node to handle literal bool and it
expected us to use that instead.

This adds a new codepath to handle static bool which uses cxxBoolLiteralExpr
and we get the member printed as you'd expect.

For testing I added a struct with just the bool because trying to print
all of "A" crashes as well. Presumably because one of the other member's
types isn't handled properly either.

So for now I just added the bool case, we can merge it with A later.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D135169

Files:
  clang/include/clang/AST/ExprCXX.h
  lldb/include/lldb/Symbol/CompilerType.h
  lldb/include/lldb/Symbol/TypeSystem.h
  lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
  lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
  lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h
  lldb/source/Symbol/CompilerType.cpp
  
lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py
  lldb/test/API/lang/cpp/const_static_integral_member/main.cpp

Index: lldb/test/API/lang/cpp/const_static_integral_member/main.cpp
===
--- lldb/test/API/lang/cpp/const_static_integral_member/main.cpp
+++ lldb/test/API/lang/cpp/const_static_integral_member/main.cpp
@@ -79,8 +79,13 @@
   ScopedEnum::scoped_enum_case1;
 };
 
+struct StaticBoolStruct {
+  static const bool value = false;
+};
+
 int main() {
   A a;
+  StaticBoolStruct sbs;
 
   auto char_max = A::char_max;
   auto uchar_max = A::uchar_max;
Index: lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py
===
--- lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py
+++ lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py
@@ -32,6 +32,11 @@
 # Test a bool member.
 self.expect_expr("A::bool_val", result_value="true")
 
+# Test a bool member when printing the struct it is a member of.
+# TODO: replace this with printing struct A, once doing so doesn't crash lldb.
+self.expect("image lookup -t StaticBoolStruct",
+substrs=["static const bool value = false;"])
+
 # Test that minimum and maximum values for each data type are right.
 self.expect_expr("A::char_max == char_max", result_value="true")
 self.expect_expr("A::uchar_max == uchar_max", result_value="true")
Index: lldb/source/Symbol/CompilerType.cpp
===
--- lldb/source/Symbol/CompilerType.cpp
+++ lldb/source/Symbol/CompilerType.cpp
@@ -154,6 +154,12 @@
   return IsIntegerType(is_signed) || IsEnumerationType(is_signed);
 }
 
+bool CompilerType::IsBooleanType() const {
+  if (IsValid())
+return m_type_system->IsBooleanType(m_type);
+  return false;
+}
+
 bool CompilerType::IsPointerType(CompilerType *pointee_type) const {
   if (IsValid()) {
 return m_type_system->IsPointerType(m_type, pointee_type);
Index: lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h
===
--- lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h
+++ lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h
@@ -592,6 +592,8 @@
   bool IsEnumerationType(lldb::opaque_compiler_type_t type,
  bool &is_signed) override;
 
+  bool IsBooleanType(lldb::opaque_compiler_type_t type) override;
+
   bool IsScopedEnumerationType(lldb::opaque_compiler_type_t type) override;
 
   static bool IsObjCClassType(const CompilerType &type);
@@ -860,6 +862,8 @@
   static void SetIntegerInitializerForVariable(clang::VarDecl *var,
const llvm::APInt &init_value);
 
+  static void SetBoolInitializerForVariable(clang::VarDecl *var, bool value);
+
   /// Initializes a variable with a floating point value.
   /// \param var The variable to initialize. Must not already have an
   ///initializer and must have a floating point type.
Index: lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
===
--- lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
+++ lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
@@ -3224,6 +3224,20 @@
   return false;
 }
 
+bool TypeSystemClang::Is

[PATCH] D135170: [LLDB] Fix crash when printing a struct with a static signed char member

2022-10-04 Thread David Spickett via Phabricator via cfe-commits

DavidSpickett created this revision.
Herald added a project: All.
DavidSpickett requested review of this revision.
Herald added projects: clang, LLDB.
Herald added subscribers: lldb-commits, cfe-commits.

As with static bool for whatever reason printing them on their own
worked fine but wasn't handled when you printed the whole type.

I don't see a good way to test this from clang's side so our existing
tests will have to do.

We can now print all of the struct "A", so there's no need for a separate
one for static bool testing. I've not checked the output, just that it
succeeds. This saves us having to handle different min/max between systems.

Depends on D135169 


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D135170

Files:
  clang/lib/AST/StmtPrinter.cpp
  
lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py
  lldb/test/API/lang/cpp/const_static_integral_member/main.cpp


Index: lldb/test/API/lang/cpp/const_static_integral_member/main.cpp
===
--- lldb/test/API/lang/cpp/const_static_integral_member/main.cpp
+++ lldb/test/API/lang/cpp/const_static_integral_member/main.cpp
@@ -79,13 +79,8 @@
   ScopedEnum::scoped_enum_case1;
 };
 
-struct StaticBoolStruct {
-  static const bool value = false;
-};
-
 int main() {
   A a;
-  StaticBoolStruct sbs;
 
   auto char_max = A::char_max;
   auto uchar_max = A::uchar_max;
Index: 
lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py
===
--- 
lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py
+++ 
lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py
@@ -32,11 +32,6 @@
 # Test a bool member.
 self.expect_expr("A::bool_val", result_value="true")
 
-# Test a bool member when printing the struct it is a member of.
-# TODO: replace this with printing struct A, once doing so doesn't 
crash lldb.
-self.expect("image lookup -t StaticBoolStruct",
-substrs=["static const bool value = false;"])
-
 # Test that minimum and maximum values for each data type are right.
 self.expect_expr("A::char_max == char_max", result_value="true")
 self.expect_expr("A::uchar_max == uchar_max", result_value="true")
@@ -88,6 +83,10 @@
 self.expect_expr("const int *i = &A::int_val_with_address; *i",
  result_value="2")
 
+# Printing the whole type takes a slightly different code path. Check 
that
+# it does not crash.
+self.expect("image lookup -t A")
+
 # dsymutil strips the debug info for classes that only have const static
 # data members without a definition namespace scope.
 @expectedFailureAll(debug_info=["dsym"])
Index: clang/lib/AST/StmtPrinter.cpp
===
--- clang/lib/AST/StmtPrinter.cpp
+++ clang/lib/AST/StmtPrinter.cpp
@@ -1280,6 +1280,7 @@
   case BuiltinType::Char_S:
   case BuiltinType::Char_U:OS << "i8"; break;
   case BuiltinType::UChar: OS << "Ui8"; break;
+  case BuiltinType::SChar: OS << "i8"; break;
   case BuiltinType::Short: OS << "i16"; break;
   case BuiltinType::UShort:OS << "Ui16"; break;
   case BuiltinType::Int:   break; // no suffix.


Index: lldb/test/API/lang/cpp/const_static_integral_member/main.cpp
===
--- lldb/test/API/lang/cpp/const_static_integral_member/main.cpp
+++ lldb/test/API/lang/cpp/const_static_integral_member/main.cpp
@@ -79,13 +79,8 @@
   ScopedEnum::scoped_enum_case1;
 };
 
-struct StaticBoolStruct {
-  static const bool value = false;
-};
-
 int main() {
   A a;
-  StaticBoolStruct sbs;
 
   auto char_max = A::char_max;
   auto uchar_max = A::uchar_max;
Index: lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py
===
--- lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py
+++ lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py
@@ -32,11 +32,6 @@
 # Test a bool member.
 self.expect_expr("A::bool_val", result_value="true")
 
-# Test a bool member when printing the struct it is a member of.
-# TODO: replace this with printing struct A, once doing so doesn't crash lldb.
-self.expect("image lookup -t StaticBoolStruct",
-substrs=["static const bool value = false;"])
-
 # Test that minimum and maximum values for each data type are right.
 self.expect_expr("A::char_max == char_max", result_value="true")
 self.expect_expr("A::uchar_max == uchar_max", result_value="true")
@@ -88,6 +83,10 @@
 self.expect_ex

[PATCH] D135169: [LLDB] Fix printing a static bool struct member when using "image lookup -t"

2022-10-04 Thread David Spickett via Phabricator via cfe-commits

DavidSpickett added a comment.
Herald added a subscriber: JDevlieghere.

For https://github.com/llvm/llvm-project/issues/58135.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135169

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

[PATCH] D135171: FreeBSD: enable __float128 on x86

2022-10-04 Thread Brooks Davis via Phabricator via cfe-commits

brooks created this revision.
brooks added reviewers: arichardson, emaste, dim.
Herald added a subscriber: krytarowski.
Herald added a project: All.
brooks requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This is a prerequisite for proper runtime support on FreeBSD as it will
allow such a runtime to be compiled.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D135171

Files:
  clang/lib/Basic/Targets/OSTargets.h


Index: clang/lib/Basic/Targets/OSTargets.h
===
--- clang/lib/Basic/Targets/OSTargets.h
+++ clang/lib/Basic/Targets/OSTargets.h
@@ -232,15 +232,20 @@
 // setting this to 1 is conforming even if all the basic source
 // character literals have the same encoding as char and wchar_t.
 Builder.defineMacro("__STDC_MB_MIGHT_NEQ_WC__", "1");
+
+if (this->HasFloat128)
+  Builder.defineMacro("__FLOAT128__");
   }
 
 public:
   FreeBSDTargetInfo(const llvm::Triple &Triple, const TargetOptions &Opts)
   : OSTargetInfo(Triple, Opts) {
 switch (Triple.getArch()) {
-default:
 case llvm::Triple::x86:
 case llvm::Triple::x86_64:
+  this->HasFloat128 = true;
+  [[fallthrough]];
+default:
   this->MCountName = ".mcount";
   break;
 case llvm::Triple::mips:


Index: clang/lib/Basic/Targets/OSTargets.h
===
--- clang/lib/Basic/Targets/OSTargets.h
+++ clang/lib/Basic/Targets/OSTargets.h
@@ -232,15 +232,20 @@
 // setting this to 1 is conforming even if all the basic source
 // character literals have the same encoding as char and wchar_t.
 Builder.defineMacro("__STDC_MB_MIGHT_NEQ_WC__", "1");
+
+if (this->HasFloat128)
+  Builder.defineMacro("__FLOAT128__");
   }
 
 public:
   FreeBSDTargetInfo(const llvm::Triple &Triple, const TargetOptions &Opts)
   : OSTargetInfo(Triple, Opts) {
 switch (Triple.getArch()) {
-default:
 case llvm::Triple::x86:
 case llvm::Triple::x86_64:
+  this->HasFloat128 = true;
+  [[fallthrough]];
+default:
   this->MCountName = ".mcount";
   break;
 case llvm::Triple::mips:
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D134654: [clang] Detect header loops

2022-10-04 Thread Aaron Ballman via Phabricator via cfe-commits

aaron.ballman added inline comments.

Comment at: clang/include/clang/Basic/DiagnosticLexKinds.td:323
   "whitespace recommended after macro name">;
+def warn_include_cycle : Warning<"#include cycle">,
+   InGroup>, DefaultIgnore;

urnathan wrote:
> aaron.ballman wrote:
> > This diagnostic doesn't really seem like it's going to help the user to 
> > know what's wrong with their code or how to fix it. (Also, the notes 
> > @erichkeane was hoping were emitted don't seem to be, at least according to 
> > the new test cases.) I think we need to give users a bit more guidance here.
> The test infrastructire ignores the 'included from ' chain, which is emitted. 
>  What do you suggest?
Even posting the "included from" doesn't help clarify what's wrong with the 
code though, if I'm understanding the tests properly. My concern is with code 
like:
```
// self.h
#ifndef GUARD
#define GUARD

#include "self.h" // expected-warning {{#include cycle}}
#endif
```
(This is effectively the same test as `warn-loop-macro-1.h`.) There is no 
include *cycle* ("a series of events that are regularly repeated in the same 
order.") in this code -- the header is included for the first time, `GUARD` is 
not defined, then `GUARD` is defined and the header is included for the second 
time. This time `GUARD` is defined and no further cycles into `self.h` occurs.

But I think I'm seeing now what you're trying to get at (correct me if I'm 
wrong): when processing an include stack, opening the same header file twice is 
a problem (regardless of the contents of the header or how you got into the 
same file twice)? If that's accurate, would it make more sense to diagnose this 
as:

`including the same header (%0) more than once in an include stack causes 
%select{incorrect behavior of Clang modules|the header to not be a C++ module 
header unit}1`

or something along those lines? Basically, I'd like to avoid saying "cycle" 
because that starts to sound like "you have potentially infinite recursion in 
the include stack" and I'd like to add information about what's actually wrong 
instead of pointing out what the code does and hoping the user knows why that's 
bad.

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

https://reviews.llvm.org/D134654

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

[PATCH] D133500: [clang] Correct handling of lambdas in lambda default arguments in dependent contexts.

2022-10-04 Thread Tom Honermann via Phabricator via cfe-commits

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
tahonermann marked an inline comment as done.
Closed by commit rG4409a83c2935: [clang] Correct handling of lambdas in lambda 
default arguments in dependent… (authored by tahonermann).

Changed prior to commit:
  https://reviews.llvm.org/D133500?vs=464489&id=465040#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133500

Files:
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/DeclBase.cpp
  clang/lib/Sema/SemaTemplateInstantiate.cpp
  clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
  clang/test/CXX/expr/expr.prim/expr.prim.lambda/default-arguments.cpp
  clang/test/CodeGenCXX/mangle-lambdas-cxx14.cpp
  clang/test/CodeGenCXX/mangle-lambdas-cxx20.cpp
  clang/test/CodeGenCXX/mangle-lambdas.cpp
  clang/test/SemaCXX/vartemplate-lambda.cpp
  clang/test/SemaTemplate/default-arguments.cpp
  clang/test/SemaTemplate/instantiate-local-class.cpp

Index: clang/test/SemaTemplate/instantiate-local-class.cpp
===
--- clang/test/SemaTemplate/instantiate-local-class.cpp
+++ clang/test/SemaTemplate/instantiate-local-class.cpp
@@ -401,7 +401,8 @@
 namespace PR21332 {
   template void f1() {
 struct S {  // expected-note{{in instantiation of member class 'S' requested here}}
-  void g1(int n = T::error);  // expected-error{{type 'int' cannot be used prior to '::' because it has no members}}
+  void g1(int n = T::error);  // expected-error{{type 'int' cannot be used prior to '::' because it has no members}} \
+  // expected-note {{in instantiation of default function argument expression for 'g1' required here}}
 };
   }
   template void f1();  // expected-note{{in instantiation of function template specialization 'PR21332::f1' requested here}}
@@ -438,7 +439,8 @@
 class S {  // expected-note {{in instantiation of member function 'PR21332::f6()::S::get' requested here}}
   void get() {
 class S2 {  // expected-note {{in instantiation of member class 'S2' requested here}}
-  void g1(int n = T::error);  // expected-error {{type 'int' cannot be used prior to '::' because it has no members}}
+  void g1(int n = T::error);  // expected-error {{type 'int' cannot be used prior to '::' because it has no members}} \
+  // expected-note  {{in instantiation of default function argument expression for 'g1' required here}}
 };
   }
 };
@@ -460,16 +462,18 @@
 
   template  void foo() {
 struct Inner { // expected-note {{in instantiation}}
-  void operator()(T a = "") {} // expected-error {{conversion function from 'const char[1]' to 'rdar23721638::A' invokes a deleted function}}
-  // expected-note@-1 {{passing argument to parameter 'a' here}}
+  void operator()(T a = "") {} // expected-error {{conversion function from 'const char[1]' to 'rdar23721638::A' invokes a deleted function}} \
+   // expected-note  {{in instantiation of default function argument expression for 'operator()' required here}} \
+   // expected-note  {{passing argument to parameter 'a' here}}
 };
-Inner()(); // expected-error {{type 'Inner' does not provide a call operator}}
+Inner()();
   }
-  template void foo(); // expected-note 2 {{in instantiation}}
+  template void foo(); // expected-note {{in instantiation}}
 
   template  void bar() {
-auto lambda = [](T a = "") {}; // expected-error {{conversion function from 'const char[1]' to 'rdar23721638::A' invokes a deleted function}}
-  // expected-note@-1 {{passing argument to parameter 'a' here}}
+auto lambda = [](T a = "") {}; // expected-error {{conversion function from 'const char[1]' to 'rdar23721638::A' invokes a deleted function}} \
+   // expected-note  {{in instantiation of default function argument expression for 'operator()' required here}} \
+   // expected-note  {{passing argument to parameter 'a' here}}
 lambda();
   }
   template void bar(); // expected-note {{in instantiation}}
@@ -490,7 +494,8 @@
   template 
   void f(int x = [](T x = nullptr) -> int { return x; }());
   // expected-error@-1 {{cannot initialize a parameter of type 'int' with an rvalue of type 'std::nullptr_t'}}
-  // expected-note@-2 {{passing argument to parameter 'x' here}}
+  // expected-note@-2  {{in instantiation of default function argument expression for 'operator()' required here}}
+  // expected-note@-3  {{passing argument to parameter 'x' here}}
 
   void g() { f(); }
   // expected-note@-1 {{in instantiation of default function argument expression for 'f' required here}}
Index: clang/test/SemaTemplate/default-arguments.cpp

[clang] 4409a83 - [clang] Correct handling of lambdas in lambda default arguments in dependent contexts.

2022-10-04 Thread Tom Honermann via cfe-commits


Author: Tom Honermann
Date: 2022-10-04T09:04:54-07:00
New Revision: 4409a83c293537e22da046b54e9f69454cdd3dca

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

LOG: [clang] Correct handling of lambdas in lambda default arguments in 
dependent contexts.

Previously, a lambda expression in a dependent context with a default argument
containing an immediately invoked lambda expression would produce a closure
class object that, if invoked such that the default argument was used, resulted
in a compiler crash or one of the following assertion failures during code
generation. The failures occurred regardless of whether the lambda expressions
were dependent.

  clang/lib/CodeGen/CGCall.cpp:
  Assertion `(isGenericMethod || Ty->isVariablyModifiedType() || 
Ty.getNonReferenceType()->isObjCRetainableType() || getContext() 
.getCanonicalType(Ty.getNonReferenceType()) .getTypePtr() == 
getContext().getCanonicalType((*Arg)->getType()).getTypePtr()) && "type 
mismatch in call argument!"' failed.

  clang/lib/AST/Decl.cpp:
  Assertion `!Init->isValueDependent()' failed.

Default arguments in declarations in local context are instantiated along with
their enclosing function or variable template (since such declarations can't
be explicitly specialized). Previously, such instantiations were performed at
the same time that their associated parameters were instantiated. However, that
approach fails in cases like the following in which the context for the inner
lambda is the outer lambda, but construction of the outer lambda is dependent
on the parameters of the inner lambda. This change resolves this dependency by
delyaing instantiation of default arguments in local contexts until after
construction of the enclosing context.
  template 
  auto f() {
return [](T = []{ return T{}; }()) { return 0; };
  }

Refactoring included with this change results in the same code now being used
to instantiate default arguments that appear in local context and those that
are only instantiated when used at a call site; previously, such code was
duplicated and out of sync.

Fixes https://github.com/llvm/llvm-project/issues/49178

Reviewed By: erichkeane

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

Added: 
clang/test/CodeGenCXX/mangle-lambdas-cxx14.cpp
clang/test/CodeGenCXX/mangle-lambdas-cxx20.cpp

Modified: 
clang/include/clang/Sema/Sema.h
clang/lib/AST/DeclBase.cpp
clang/lib/Sema/SemaTemplateInstantiate.cpp
clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
clang/test/CXX/expr/expr.prim/expr.prim.lambda/default-arguments.cpp
clang/test/CodeGenCXX/mangle-lambdas.cpp
clang/test/SemaCXX/vartemplate-lambda.cpp
clang/test/SemaTemplate/default-arguments.cpp
clang/test/SemaTemplate/instantiate-local-class.cpp

Removed: 




diff  --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
index 74735fb8d07c1..ce6f67ad19af6 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -9782,6 +9782,9 @@ class Sema final {
   SmallVectorImpl &ParamTypes,
   SmallVectorImpl *OutParams,
   ExtParameterInfoBuilder &ParamInfos);
+  bool SubstDefaultArgument(SourceLocation Loc, ParmVarDecl *Param,
+const MultiLevelTemplateArgumentList &TemplateArgs,
+bool ForCallExpr = false);
   ExprResult SubstExpr(Expr *E,
const MultiLevelTemplateArgumentList &TemplateArgs);
 

diff  --git a/clang/lib/AST/DeclBase.cpp b/clang/lib/AST/DeclBase.cpp
index a9ac441092be0..763fc1d9f17fb 100644
--- a/clang/lib/AST/DeclBase.cpp
+++ b/clang/lib/AST/DeclBase.cpp
@@ -261,12 +261,12 @@ const TemplateParameterList 
*Decl::getDescribedTemplateParams() const {
 
 bool Decl::isTemplated() const {
   // A declaration is templated if it is a template or a template pattern, or
-  // is within (lexcially for a friend, semantically otherwise) a dependent
-  // context.
-  // FIXME: Should local extern declarations be treated like friends?
+  // is within (lexcially for a friend or local function declaration,
+  // semantically otherwise) a dependent context.
   if (auto *AsDC = dyn_cast(this))
 return AsDC->isDependentContext();
-  auto *DC = getFriendObjectKind() ? getLexicalDeclContext() : 
getDeclContext();
+  auto *DC = getFriendObjectKind() || isLocalExternDecl()
+  ? getLexicalDeclContext() : getDeclContext();
   return DC->isDependentContext() || isTemplateDecl() ||
  getDescribedTemplateParams();
 }

diff  --git a/clang/lib/Sema/SemaTemplateInstantiate.cpp 
b/clang/lib/Sema/SemaTemplateInstantiate.cpp
index c6eb034e43708..21b141f96a695 100644
--- a/clang/lib/Sema/SemaTemplateInstantiate.cpp
+++ b/clang/lib/Sema/SemaT

[PATCH] D134549: [clang] Add fix-it note to defaulted-function-deleted warning

2022-10-04 Thread Nathan James via Phabricator via cfe-commits

njames93 updated this revision to Diff 465042.
njames93 added a comment.

Address @martong's comment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134549

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/AST/Decl.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/ASTImporter.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Serialization/ASTReaderDecl.cpp
  clang/lib/Serialization/ASTWriterDecl.cpp
  clang/test/CXX/class.derived/class.abstract/p16.cpp
  clang/test/CXX/class/class.compare/class.compare.default/p1.cpp
  clang/test/CXX/class/class.compare/class.compare.default/p2.cpp
  clang/test/CXX/class/class.compare/class.compare.secondary/p2.cpp
  clang/test/CXX/class/class.compare/class.eq/p2.cpp
  clang/test/CXX/class/class.compare/class.rel/p2.cpp
  clang/test/CXX/class/class.compare/class.spaceship/p1.cpp
  clang/test/CXX/class/class.compare/class.spaceship/p2.cpp
  clang/test/CXX/drs/dr6xx.cpp
  clang/test/SemaCXX/cxx0x-deleted-default-ctor.cpp
  clang/test/SemaCXX/dr1301.cpp
  clang/test/SemaCXX/explicitly-defaulted.cpp
  clang/test/SemaCXX/microsoft-dtor-lookup-cxx11.cpp
  clang/test/SemaObjCXX/arc-0x.mm

Index: clang/test/SemaObjCXX/arc-0x.mm
===
--- clang/test/SemaObjCXX/arc-0x.mm
+++ clang/test/SemaObjCXX/arc-0x.mm
@@ -121,12 +121,12 @@
 
   union U1 {
 __weak id f0; // expected-note 12 {{'U1' is implicitly deleted because variant field 'f0' is an ObjC pointer}}
-U1() = default; // expected-warning {{explicitly defaulted default constructor is implicitly deleted}} expected-note {{explicitly defaulted function was implicitly deleted here}}
-~U1() = default; // expected-warning {{explicitly defaulted destructor is implicitly deleted}} expected-note {{explicitly defaulted function was implicitly deleted here}}
-U1(const U1 &) = default; // expected-warning {{explicitly defaulted copy constructor is implicitly deleted}} expected-note 2 {{explicitly defaulted function was implicitly deleted here}}
-U1(U1 &&) = default; // expected-warning {{explicitly defaulted move constructor is implicitly deleted}}
-U1 & operator=(const U1 &) = default; // expected-warning {{explicitly defaulted copy assignment operator is implicitly deleted}} expected-note 2 {{explicitly defaulted function was implicitly deleted here}}
-U1 & operator=(U1 &&) = default; // expected-warning {{explicitly defaulted move assignment operator is implicitly deleted}}
+U1() = default; // expected-warning {{explicitly defaulted default constructor is implicitly deleted}} expected-note {{explicitly defaulted function was implicitly deleted here}} expected-note{{replace 'default'}}
+~U1() = default; // expected-warning {{explicitly defaulted destructor is implicitly deleted}} expected-note {{explicitly defaulted function was implicitly deleted here}} expected-note{{replace 'default'}}
+U1(const U1 &) = default; // expected-warning {{explicitly defaulted copy constructor is implicitly deleted}} expected-note 2 {{explicitly defaulted function was implicitly deleted here}} expected-note{{replace 'default'}}
+U1(U1 &&) = default; // expected-warning {{explicitly defaulted move constructor is implicitly deleted}} expected-note{{replace 'default'}}
+U1 & operator=(const U1 &) = default; // expected-warning {{explicitly defaulted copy assignment operator is implicitly deleted}} expected-note 2 {{explicitly defaulted function was implicitly deleted here}} expected-note{{replace 'default'}}
+U1 & operator=(U1 &&) = default; // expected-warning {{explicitly defaulted move assignment operator is implicitly deleted}} expected-note{{replace 'default'}}
   };
 
   id getStrong();
Index: clang/test/SemaCXX/microsoft-dtor-lookup-cxx11.cpp
===
--- clang/test/SemaCXX/microsoft-dtor-lookup-cxx11.cpp
+++ clang/test/SemaCXX/microsoft-dtor-lookup-cxx11.cpp
@@ -7,7 +7,7 @@
 } s; // expected-error {{attempt to use a deleted function}}
 
 struct T { // expected-note 2{{virtual destructor requires an unambiguous, accessible 'operator delete'}}
-  virtual ~T() = default; // expected-note {{explicitly defaulted function was implicitly deleted here}} expected-warning {{implicitly deleted}}
+  virtual ~T() = default; // expected-note {{explicitly defaulted function was implicitly deleted here}} expected-warning {{implicitly deleted}} expected-note{{replace 'default'}}
   void operator delete(void*, int);
   void operator delete(void*, double);
 } t; // expected-error {{attempt to use a deleted function}}
Index: clang/test/SemaCXX/explicitly-defaulted.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/explicitly-defaulted.cpp
@@ -0,0 +1,38 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c

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

2022-10-04 Thread Aaron Ballman via Phabricator via cfe-commits

aaron.ballman added inline comments.



Comment at: clang/lib/AST/Interp/Floating.h:27-29
+  template  struct Repr;
+  template <> struct Repr<32> { using Type = float; };
+  template <> struct Repr<64> { using Type = double; };

tbaeder wrote:
> jcranmer-intel wrote:
> > tbaeder wrote:
> > > jcranmer-intel wrote:
> > > > aaron.ballman wrote:
> > > > > Er, how will this extend to `long double` where the number of bits is 
> > > > > rather more difficult?
> > > > Or `half` and `bfloat`, which are both 16-bit floating-point types?
> > > I have spent some time with this today and tried to simply always use 
> > > `APFloat` instead of a primitive type. Unfortunately that doesn't work 
> > > because what we put on the stack is not the `Floating` (or `Integral`), 
> > > but the underlying primitive type. So even if we do the final math (in 
> > > `::add`, etc) via `APFloat`, we need something we can serialize to 
> > > `char[]` so we can put it on the stack. Do you think that would work?
> > I don't know enough about the structure of the bytecode interpreter here to 
> > say for sure, but this smells to me like you're baking in an assumption 
> > that every primitive target type has a corresponding primitive type on the 
> > host. This assumption just doesn't hold when it comes to floating point 
> > (only two of the seven types, `float` and `double`, are generally portable, 
> > and even then, there be dragons in some corner cases).
> > 
> > If you do need to continue down this route, there are two requirements that 
> > should be upheld:
> > * The representation shouldn't assume that the underlying primitive type 
> > exists on host (bfloat16 and float128 are better test cases here).
> > * Conversion to/from host primitive types shouldn't be easy to accidentally 
> > do.
> > 
> > (Worth repeating again that bit size is insufficient to distinguish 
> > floating point types: `bfloat` and `half` are both 16-bit, PPC `long 
> > double` and IEEE 754 quad precision are both 128-bit, and x86 `long double` 
> > is 80 bits stored as 96 bits on 32-bit and 128 bits on 64-bit.)
> Well, is there a way to convert an APFloat to a char[] that would work 
> instead of going to float/double and storing that? The only thing I see in 
> the docs is `convertToHexString()` (and the docs don't mention whether the 
> conversion is lossy). If not, do you think adding such a conversion to 
> `APFloat` and its various implementations is the better way forward?
Let's avoid serializing the floats to strings so that we can parse the string 
to turn it back into a float later; that's going to have poor performance even 
if we do get all the corner cases correct regarding things like rounding, etc.

`APFloat` does not have any sort of serialization functionality beyond through 
strings representing the value. I think you'd have to invent such an interface.


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

https://reviews.llvm.org/D134859

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

[PATCH] D135171: FreeBSD: enable __float128 on x86

2022-10-04 Thread Dimitry Andric via Phabricator via cfe-commits

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

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135171

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

[clang] 42ad305 - Modify the qualified/unqualified getter for TypeOfType; NFC

2022-10-04 Thread Aaron Ballman via cfe-commits


Author: Aaron Ballman
Date: 2022-10-04T12:14:38-04:00
New Revision: 42ad305bdbb87d567d4d365ec5ede8be4d2a4210

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

LOG: Modify the qualified/unqualified getter for TypeOfType; NFC

Post-commit feedback observed that returning the TypeOfKind from the
type instead of a Boolean cleans up code using that interface.

Added: 


Modified: 
clang/include/clang/AST/Type.h
clang/include/clang/AST/TypeProperties.td
clang/lib/AST/ASTContext.cpp
clang/lib/AST/ASTImporter.cpp
clang/lib/AST/Type.cpp
clang/lib/AST/TypePrinter.cpp
clang/lib/Sema/TreeTransform.h

Removed: 




diff  --git a/clang/include/clang/AST/Type.h b/clang/include/clang/AST/Type.h
index b7ef891f97d81..fbf65e588fb51 100644
--- a/clang/include/clang/AST/Type.h
+++ b/clang/include/clang/AST/Type.h
@@ -4608,8 +4608,11 @@ class TypeOfExprType : public Type {
 public:
   Expr *getUnderlyingExpr() const { return TOExpr; }
 
-  /// Returns true if this is a typeof_unqual type.
-  bool isUnqual() const { return TypeOfBits.IsUnqual; }
+  /// Returns the kind of 'typeof' type this is.
+  TypeOfKind getKind() const {
+return TypeOfBits.IsUnqual ? TypeOfKind::Unqualified
+   : TypeOfKind::Qualified;
+  }
 
   /// Remove a single level of sugar.
   QualType desugar() const;
@@ -4635,7 +4638,8 @@ class DependentTypeOfExprType
   : TypeOfExprType(E, Kind), Context(Context) {}
 
   void Profile(llvm::FoldingSetNodeID &ID) {
-Profile(ID, Context, getUnderlyingExpr(), isUnqual());
+Profile(ID, Context, getUnderlyingExpr(),
+getKind() == TypeOfKind::Unqualified);
   }
 
   static void Profile(llvm::FoldingSetNodeID &ID, const ASTContext &Context,
@@ -4664,14 +4668,17 @@ class TypeOfType : public Type {
   /// Remove a single level of sugar.
   QualType desugar() const {
 QualType QT = getUnmodifiedType();
-return isUnqual() ? QT.getAtomicUnqualifiedType() : QT;
+return TypeOfBits.IsUnqual ? QT.getAtomicUnqualifiedType() : QT;
   }
 
   /// Returns whether this type directly provides sugar.
   bool isSugared() const { return true; }
 
-  /// Returns true if this is a typeof_unqual type.
-  bool isUnqual() const { return TypeOfBits.IsUnqual; }
+  /// Returns the kind of 'typeof' type this is.
+  TypeOfKind getKind() const {
+return TypeOfBits.IsUnqual ? TypeOfKind::Unqualified
+   : TypeOfKind::Qualified;
+  }
 
   static bool classof(const Type *T) { return T->getTypeClass() == TypeOf; }
 };

diff  --git a/clang/include/clang/AST/TypeProperties.td 
b/clang/include/clang/AST/TypeProperties.td
index 9634d2b961b18..ef7ed6eda3143 100644
--- a/clang/include/clang/AST/TypeProperties.td
+++ b/clang/include/clang/AST/TypeProperties.td
@@ -394,8 +394,7 @@ let Class = TypeOfExprType in {
   }
 
   def : Property<"kind", TypeOfKind> {
-let Read = [{ node->isUnqual() ? TypeOfKind::Unqualified
-   : TypeOfKind::Qualified }];
+let Read = [{ node->getKind() }];
   }
 
   def : Creator<[{
@@ -409,8 +408,7 @@ let Class = TypeOfType in {
   }
 
   def : Property<"kind", TypeOfKind> {
-let Read = [{ node->isUnqual() ? TypeOfKind::Unqualified
-   : TypeOfKind::Qualified }];
+let Read = [{ node->getKind() }];
   }
 
   def : Creator<[{

diff  --git a/clang/lib/AST/ASTContext.cpp b/clang/lib/AST/ASTContext.cpp
index fa7d5269e3f9e..d609fe8cbed09 100644
--- a/clang/lib/AST/ASTContext.cpp
+++ b/clang/lib/AST/ASTContext.cpp
@@ -12963,16 +12963,17 @@ static QualType getCommonSugarTypeNode(ASTContext 
&Ctx, const Type *X,
   return QualType();
 return Ctx.getTypedefType(CD, Ctx.getQualifiedType(Underlying));
   }
-  case Type::TypeOf:
+  case Type::TypeOf: {
 // The common sugar between two typeof expressions, where one is
 // potentially a typeof_unqual and the other is not, we unify to the
 // qualified type as that retains the most information along with the type.
 // We only return a typeof_unqual type when both types are unqual types.
-return Ctx.getTypeOfType(Ctx.getQualifiedType(Underlying),
- cast(X)->isUnqual() &&
- cast(Y)->isUnqual()
- ? TypeOfKind::Unqualified
- : TypeOfKind::Qualified);
+TypeOfKind Kind = TypeOfKind::Qualified;
+if (cast(X)->getKind() == cast(Y)->getKind() &&
+cast(X)->getKind() == TypeOfKind::Unqualified)
+  Kind = TypeOfKind::Unqualified;
+return Ctx.getTypeOfType(Ctx.getQualifiedType(Underlying), Kind);
+  }
   case Type::TypeOfExpr:
 return QualType();
 

diff  --git a/clang/lib/AST/ASTImporter.cpp b/clang/lib/AST

[PATCH] D134286: [C2x] implement typeof and typeof_unqual

2022-10-04 Thread Aaron Ballman via Phabricator via cfe-commits

aaron.ballman added inline comments.



Comment at: clang/include/clang/AST/Type.h:4564
+  /// Returns true if this is a typeof_unqual type.
+  bool isUnqual() const { return TypeOfBits.IsUnqual; }
+

mizvekov wrote:
> I only noticed this after rebasing some of my patches, I missed this on the 
> original review (same for TypeOfType)
Sure, on the whole I think this makes the code cleaner. I've updated in 
42ad305bdbb87d567d4d365ec5ede8be4d2a4210, thank you for the suggestion!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134286

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

[PATCH] D134549: [clang] Add fix-it note to defaulted-function-deleted warning

2022-10-04 Thread Nathan James via Phabricator via cfe-commits

njames93 updated this revision to Diff 465045.
njames93 added a comment.

Rebase to trunk


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134549

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/AST/Decl.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/ASTImporter.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Serialization/ASTReaderDecl.cpp
  clang/lib/Serialization/ASTWriterDecl.cpp
  clang/test/CXX/class.derived/class.abstract/p16.cpp
  clang/test/CXX/class/class.compare/class.compare.default/p1.cpp
  clang/test/CXX/class/class.compare/class.compare.default/p2.cpp
  clang/test/CXX/class/class.compare/class.compare.secondary/p2.cpp
  clang/test/CXX/class/class.compare/class.eq/p2.cpp
  clang/test/CXX/class/class.compare/class.rel/p2.cpp
  clang/test/CXX/class/class.compare/class.spaceship/p1.cpp
  clang/test/CXX/class/class.compare/class.spaceship/p2.cpp
  clang/test/CXX/drs/dr6xx.cpp
  clang/test/SemaCXX/cxx0x-deleted-default-ctor.cpp
  clang/test/SemaCXX/dr1301.cpp
  clang/test/SemaCXX/explicitly-defaulted.cpp
  clang/test/SemaCXX/microsoft-dtor-lookup-cxx11.cpp
  clang/test/SemaObjCXX/arc-0x.mm

Index: clang/test/SemaObjCXX/arc-0x.mm
===
--- clang/test/SemaObjCXX/arc-0x.mm
+++ clang/test/SemaObjCXX/arc-0x.mm
@@ -121,12 +121,12 @@
 
   union U1 {
 __weak id f0; // expected-note 12 {{'U1' is implicitly deleted because variant field 'f0' is an ObjC pointer}}
-U1() = default; // expected-warning {{explicitly defaulted default constructor is implicitly deleted}} expected-note {{explicitly defaulted function was implicitly deleted here}}
-~U1() = default; // expected-warning {{explicitly defaulted destructor is implicitly deleted}} expected-note {{explicitly defaulted function was implicitly deleted here}}
-U1(const U1 &) = default; // expected-warning {{explicitly defaulted copy constructor is implicitly deleted}} expected-note 2 {{explicitly defaulted function was implicitly deleted here}}
-U1(U1 &&) = default; // expected-warning {{explicitly defaulted move constructor is implicitly deleted}}
-U1 & operator=(const U1 &) = default; // expected-warning {{explicitly defaulted copy assignment operator is implicitly deleted}} expected-note 2 {{explicitly defaulted function was implicitly deleted here}}
-U1 & operator=(U1 &&) = default; // expected-warning {{explicitly defaulted move assignment operator is implicitly deleted}}
+U1() = default; // expected-warning {{explicitly defaulted default constructor is implicitly deleted}} expected-note {{explicitly defaulted function was implicitly deleted here}} expected-note{{replace 'default'}}
+~U1() = default; // expected-warning {{explicitly defaulted destructor is implicitly deleted}} expected-note {{explicitly defaulted function was implicitly deleted here}} expected-note{{replace 'default'}}
+U1(const U1 &) = default; // expected-warning {{explicitly defaulted copy constructor is implicitly deleted}} expected-note 2 {{explicitly defaulted function was implicitly deleted here}} expected-note{{replace 'default'}}
+U1(U1 &&) = default; // expected-warning {{explicitly defaulted move constructor is implicitly deleted}} expected-note{{replace 'default'}}
+U1 & operator=(const U1 &) = default; // expected-warning {{explicitly defaulted copy assignment operator is implicitly deleted}} expected-note 2 {{explicitly defaulted function was implicitly deleted here}} expected-note{{replace 'default'}}
+U1 & operator=(U1 &&) = default; // expected-warning {{explicitly defaulted move assignment operator is implicitly deleted}} expected-note{{replace 'default'}}
   };
 
   id getStrong();
Index: clang/test/SemaCXX/microsoft-dtor-lookup-cxx11.cpp
===
--- clang/test/SemaCXX/microsoft-dtor-lookup-cxx11.cpp
+++ clang/test/SemaCXX/microsoft-dtor-lookup-cxx11.cpp
@@ -7,7 +7,7 @@
 } s; // expected-error {{attempt to use a deleted function}}
 
 struct T { // expected-note 2{{virtual destructor requires an unambiguous, accessible 'operator delete'}}
-  virtual ~T() = default; // expected-note {{explicitly defaulted function was implicitly deleted here}} expected-warning {{implicitly deleted}}
+  virtual ~T() = default; // expected-note {{explicitly defaulted function was implicitly deleted here}} expected-warning {{implicitly deleted}} expected-note{{replace 'default'}}
   void operator delete(void*, int);
   void operator delete(void*, double);
 } t; // expected-error {{attempt to use a deleted function}}
Index: clang/test/SemaCXX/explicitly-defaulted.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/explicitly-defaulted.cpp
@@ -0,0 +1,38 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c++11 %s
+
+s

[PATCH] D134286: [C2x] implement typeof and typeof_unqual

2022-10-04 Thread Matheus Izvekov via Phabricator via cfe-commits

mizvekov added inline comments.



Comment at: clang/include/clang/AST/Type.h:4564
+  /// Returns true if this is a typeof_unqual type.
+  bool isUnqual() const { return TypeOfBits.IsUnqual; }
+

aaron.ballman wrote:
> mizvekov wrote:
> > I only noticed this after rebasing some of my patches, I missed this on the 
> > original review (same for TypeOfType)
> Sure, on the whole I think this makes the code cleaner. I've updated in 
> 42ad305bdbb87d567d4d365ec5ede8be4d2a4210, thank you for the suggestion!
Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134286

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

[PATCH] D116280: [clang] adds unary type trait checks as compiler built-ins

2022-10-04 Thread Christopher Di Bella via Phabricator via cfe-commits

cjdb added a comment.

This commit is suffering from feature creep, which has a whole host of problems 
associated with it. I'm going to dump everything that I've got related to the 
patch here for archival purposes, abandon it, and then spin out tiny CLs, some 
of which are hopefully trivial to review thanks to being early additions to 
this one.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116280

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

[PATCH] D135171: FreeBSD: enable __float128 on x86

2022-10-04 Thread Alexander Richardson via Phabricator via cfe-commits

arichardson accepted this revision.
arichardson added a comment.

Could you add a RUN: line to `clang/test/CodeGenCXX/float128-declarations.cpp? 
Code LGTM.

  // RUN: %clang_cc1 -no-opaque-pointers -emit-llvm -triple 
x86_64-unknown-freebsd -std=c++11 \
  // RUN:   %s -o - | FileCheck %s -check-prefix=CHECK-X86


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135171

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

[PATCH] D135175: [clang] adds `__is_bounded_array` and `__is_unbounded_array` as builtins

2022-10-04 Thread Christopher Di Bella via Phabricator via cfe-commits

cjdb created this revision.
cjdb added a reviewer: aaron.ballman.
Herald added a project: All.
cjdb requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This is information that the compiler already has, and should be exposed
so that the library doesn't need to reimplement the exact same
functionality.

This was originally a part of D116280 .


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D135175

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/TokenKinds.def
  clang/lib/Parse/ParseExpr.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/SemaCXX/type-traits.cpp

Index: clang/test/SemaCXX/type-traits.cpp
===
--- clang/test/SemaCXX/type-traits.cpp
+++ clang/test/SemaCXX/type-traits.cpp
@@ -702,6 +702,70 @@
   int t31[F(__is_array(cvoid*))];
 }
 
+void is_bounded_array(int n) {
+  int t01[T(__is_bounded_array(IntAr))];
+  int t02[F(__is_bounded_array(IntArNB))];
+  int t03[T(__is_bounded_array(UnionAr))];
+
+  int t10[F(__is_bounded_array(void))];
+  int t11[F(__is_bounded_array(cvoid))];
+  int t12[F(__is_bounded_array(float))];
+  int t13[F(__is_bounded_array(double))];
+  int t14[F(__is_bounded_array(long double))];
+  int t15[F(__is_bounded_array(bool))];
+  int t16[F(__is_bounded_array(char))];
+  int t17[F(__is_bounded_array(signed char))];
+  int t18[F(__is_bounded_array(unsigned char))];
+  int t19[F(__is_bounded_array(wchar_t))];
+  int t20[F(__is_bounded_array(short))];
+  int t21[F(__is_bounded_array(unsigned short))];
+  int t22[F(__is_bounded_array(int))];
+  int t23[F(__is_bounded_array(unsigned int))];
+  int t24[F(__is_bounded_array(long))];
+  int t25[F(__is_bounded_array(unsigned long))];
+  int t26[F(__is_bounded_array(Union))];
+  int t27[F(__is_bounded_array(Derives))];
+  int t28[F(__is_bounded_array(ClassType))];
+  int t29[F(__is_bounded_array(Enum))];
+  int t30[F(__is_bounded_array(void *))];
+  int t31[F(__is_bounded_array(cvoid *))];
+
+  int t32[n];
+  (void)__is_bounded_array(decltype(t32)); // expected-error{{variable length arrays are not supported for '__is_bounded_array'}}
+}
+
+void is_unbounded_array(int n) {
+  int t01[F(__is_unbounded_array(IntAr))];
+  int t02[T(__is_unbounded_array(IntArNB))];
+  int t03[F(__is_unbounded_array(UnionAr))];
+
+  int t10[F(__is_unbounded_array(void))];
+  int t11[F(__is_unbounded_array(cvoid))];
+  int t12[F(__is_unbounded_array(float))];
+  int t13[F(__is_unbounded_array(double))];
+  int t14[F(__is_unbounded_array(long double))];
+  int t15[F(__is_unbounded_array(bool))];
+  int t16[F(__is_unbounded_array(char))];
+  int t17[F(__is_unbounded_array(signed char))];
+  int t18[F(__is_unbounded_array(unsigned char))];
+  int t19[F(__is_unbounded_array(wchar_t))];
+  int t20[F(__is_unbounded_array(short))];
+  int t21[F(__is_unbounded_array(unsigned short))];
+  int t22[F(__is_unbounded_array(int))];
+  int t23[F(__is_unbounded_array(unsigned int))];
+  int t24[F(__is_unbounded_array(long))];
+  int t25[F(__is_unbounded_array(unsigned long))];
+  int t26[F(__is_unbounded_array(Union))];
+  int t27[F(__is_unbounded_array(Derives))];
+  int t28[F(__is_unbounded_array(ClassType))];
+  int t29[F(__is_unbounded_array(Enum))];
+  int t30[F(__is_unbounded_array(void *))];
+  int t31[F(__is_unbounded_array(cvoid *))];
+
+  int t32[n];
+  (void)__is_unbounded_array(decltype(t32)); // expected-error{{variable length arrays are not supported for '__is_unbounded_array'}}
+}
+
 template  void tmpl_func(T&) {}
 
 template  struct type_wrapper {
Index: clang/lib/Sema/SemaType.cpp
===
--- clang/lib/Sema/SemaType.cpp
+++ clang/lib/Sema/SemaType.cpp
@@ -2627,12 +2627,10 @@
 
   if (T->isVariableArrayType() && !Context.getTargetInfo().isVLASupported()) {
 // CUDA device code and some other targets don't support VLAs.
-targetDiag(Loc, (getLangOpts().CUDA && getLangOpts().CUDAIsDevice)
-? diag::err_cuda_vla
-: diag::err_vla_unsupported)
-<< ((getLangOpts().CUDA && getLangOpts().CUDAIsDevice)
-? CurrentCUDATarget()
-: CFT_InvalidTarget);
+bool IsCUDADevice = (getLangOpts().CUDA && getLangOpts().CUDAIsDevice);
+targetDiag(Loc,
+   IsCUDADevice ? diag::err_cuda_vla : diag::err_vla_unsupported)
+<< (IsCUDADevice ? CurrentCUDATarget() : 0);
   }
 
   // If this is not C99, diagnose array size modifiers on non-VLAs.
Index: clang/lib/Sema/SemaExprCXX.cpp
===
--- clang/lib/Sema/SemaExprCXX.cpp
+++ clang/lib/Sema/SemaExprCXX.cpp
@@ -21,11 +21,13 @@
 #include "clang/AST/ExprCXX.h"
 #include "clang/AST/ExprObjC.h"
 #include "clang/AST/RecursiveASTVisitor.h"
+#include "clang/AST/Type.h"
 #includ

[PATCH] D116280: [clang] adds unary type trait checks as compiler built-ins

2022-10-04 Thread Christopher Di Bella via Phabricator via cfe-commits

cjdb updated this revision to Diff 465048.
cjdb added a comment.

uploading for archival purposes, will abandon the review in a moment


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116280

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/TokenKinds.def
  clang/lib/Lex/PPMacroExpansion.cpp
  clang/lib/Parse/ParseDeclCXX.cpp
  clang/lib/Parse/ParseExpr.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/SemaCXX/deprecated-builtins.cpp
  clang/test/SemaCXX/type-traits.cpp

Index: clang/test/SemaCXX/type-traits.cpp
===
--- clang/test/SemaCXX/type-traits.cpp
+++ clang/test/SemaCXX/type-traits.cpp
@@ -345,11 +345,19 @@
 }
 
 typedef Enum EnumType;
+typedef EnumClass EnumClassType;
 
 void is_enum()
 {
   { int arr[T(__is_enum(Enum))]; }
   { int arr[T(__is_enum(EnumType))]; }
+  { int arr[T(__is_enum(SignedEnum))]; }
+  { int arr[T(__is_enum(UnsignedEnum))]; }
+
+  { int arr[T(__is_enum(EnumClass))]; }
+  { int arr[T(__is_enum(EnumClassType))]; }
+  { int arr[T(__is_enum(SignedEnumClass))]; }
+  { int arr[T(__is_enum(UnsignedEnumClass))]; }
 
   { int arr[F(__is_enum(int))]; }
   { int arr[F(__is_enum(Union))]; }
@@ -363,6 +371,29 @@
   { int arr[F(__is_enum(HasAnonymousUnion))]; }
 }
 
+void is_scoped_enum() {
+  { int arr[F(__is_scoped_enum(Enum))]; }
+  { int arr[F(__is_scoped_enum(EnumType))]; }
+  { int arr[F(__is_scoped_enum(SignedEnum))]; }
+  { int arr[F(__is_scoped_enum(UnsignedEnum))]; }
+
+  { int arr[T(__is_scoped_enum(EnumClass))]; }
+  { int arr[T(__is_scoped_enum(EnumClassType))]; }
+  { int arr[T(__is_scoped_enum(SignedEnumClass))]; }
+  { int arr[T(__is_scoped_enum(UnsignedEnumClass))]; }
+
+  { int arr[F(__is_scoped_enum(int))]; }
+  { int arr[F(__is_scoped_enum(Union))]; }
+  { int arr[F(__is_scoped_enum(Int))]; }
+  { int arr[F(__is_scoped_enum(IntAr))]; }
+  { int arr[F(__is_scoped_enum(UnionAr))]; }
+  { int arr[F(__is_scoped_enum(Derives))]; }
+  { int arr[F(__is_scoped_enum(ClassType))]; }
+  { int arr[F(__is_scoped_enum(cvoid))]; }
+  { int arr[F(__is_scoped_enum(IntArNB))]; }
+  { int arr[F(__is_scoped_enum(HasAnonymousUnion))]; }
+}
+
 struct FinalClass final {
 };
 
@@ -702,6 +733,106 @@
   int t31[F(__is_array(cvoid*))];
 }
 
+void is_bounded_array(int n) {
+  int t01[T(__is_bounded_array(IntAr))];
+  int t02[F(__is_bounded_array(IntArNB))];
+  int t03[T(__is_bounded_array(UnionAr))];
+
+  int t10[F(__is_bounded_array(void))];
+  int t11[F(__is_bounded_array(cvoid))];
+  int t12[F(__is_bounded_array(float))];
+  int t13[F(__is_bounded_array(double))];
+  int t14[F(__is_bounded_array(long double))];
+  int t15[F(__is_bounded_array(bool))];
+  int t16[F(__is_bounded_array(char))];
+  int t17[F(__is_bounded_array(signed char))];
+  int t18[F(__is_bounded_array(unsigned char))];
+  int t19[F(__is_bounded_array(wchar_t))];
+  int t20[F(__is_bounded_array(short))];
+  int t21[F(__is_bounded_array(unsigned short))];
+  int t22[F(__is_bounded_array(int))];
+  int t23[F(__is_bounded_array(unsigned int))];
+  int t24[F(__is_bounded_array(long))];
+  int t25[F(__is_bounded_array(unsigned long))];
+  int t26[F(__is_bounded_array(Union))];
+  int t27[F(__is_bounded_array(Derives))];
+  int t28[F(__is_bounded_array(ClassType))];
+  int t29[F(__is_bounded_array(Enum))];
+  int t30[F(__is_bounded_array(void *))];
+  int t31[F(__is_bounded_array(cvoid *))];
+
+  int t32[n];
+  (void)__is_bounded_array(decltype(t32)); // expected-error{{variable length arrays are not supported for '__is_bounded_array'}}
+}
+
+void is_unbounded_array(int n) {
+  int t01[F(__is_unbounded_array(IntAr))];
+  int t02[T(__is_unbounded_array(IntArNB))];
+  int t03[F(__is_unbounded_array(UnionAr))];
+
+  int t10[F(__is_unbounded_array(void))];
+  int t11[F(__is_unbounded_array(cvoid))];
+  int t12[F(__is_unbounded_array(float))];
+  int t13[F(__is_unbounded_array(double))];
+  int t14[F(__is_unbounded_array(long double))];
+  int t15[F(__is_unbounded_array(bool))];
+  int t16[F(__is_unbounded_array(char))];
+  int t17[F(__is_unbounded_array(signed char))];
+  int t18[F(__is_unbounded_array(unsigned char))];
+  int t19[F(__is_unbounded_array(wchar_t))];
+  int t20[F(__is_unbounded_array(short))];
+  int t21[F(__is_unbounded_array(unsigned short))];
+  int t22[F(__is_unbounded_array(int))];
+  int t23[F(__is_unbounded_array(unsigned int))];
+  int t24[F(__is_unbounded_array(long))];
+  int t25[F(__is_unbounded_array(unsigned long))];
+  int t26[F(__is_unbounded_array(Union))];
+  int t27[F(__is_unbounded_array(Derives))];
+  int t28[F(__is_unbounded_array(ClassType))];
+  int t29[F(__is_unbounded_array(Enum))];
+  int t30[F(__is_unbounded_array(void *))];
+  int t31[F(__is_unbounded_array(cvoid *))];
+
+  int t32[n];
+  (void)__is_unbounded_array(decltype(t32)); // expected-error{{variable length arrays are not sup

[PATCH] D135169: [LLDB] Fix printing a static bool struct member when using "image lookup -t"

2022-10-04 Thread Shafik Yaghmour via Phabricator via cfe-commits

shafik added inline comments.



Comment at: clang/include/clang/AST/ExprCXX.h:733
 
+  static CXXBoolLiteralExpr *Create(const ASTContext &C, bool Val, QualType Ty,
+SourceLocation Loc) {

I think this makes sense but if we are going to do this refactor then we should 
clean up all the locations we are currently doing `new (Context) 
CXXBoolLiteralExpr()` as well.

Maybe that should be the initial PR and then this change would be a follow-up.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135169

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

[PATCH] D134654: [clang] Detect header loops

2022-10-04 Thread Nikolas Klauser via Phabricator via cfe-commits

philnik added inline comments.



Comment at: clang/include/clang/Basic/DiagnosticLexKinds.td:323
   "whitespace recommended after macro name">;
+def warn_include_cycle : Warning<"#include cycle">,
+   InGroup>, DefaultIgnore;

aaron.ballman wrote:
> urnathan wrote:
> > aaron.ballman wrote:
> > > This diagnostic doesn't really seem like it's going to help the user to 
> > > know what's wrong with their code or how to fix it. (Also, the notes 
> > > @erichkeane was hoping were emitted don't seem to be, at least according 
> > > to the new test cases.) I think we need to give users a bit more guidance 
> > > here.
> > The test infrastructire ignores the 'included from ' chain, which is 
> > emitted.  What do you suggest?
> Even posting the "included from" doesn't help clarify what's wrong with the 
> code though, if I'm understanding the tests properly. My concern is with code 
> like:
> ```
> // self.h
> #ifndef GUARD
> #define GUARD
> 
> #include "self.h" // expected-warning {{#include cycle}}
> #endif
> ```
> (This is effectively the same test as `warn-loop-macro-1.h`.) There is no 
> include *cycle* ("a series of events that are regularly repeated in the same 
> order.") in this code -- the header is included for the first time, `GUARD` 
> is not defined, then `GUARD` is defined and the header is included for the 
> second time. This time `GUARD` is defined and no further cycles into `self.h` 
> occurs.
> 
> But I think I'm seeing now what you're trying to get at (correct me if I'm 
> wrong): when processing an include stack, opening the same header file twice 
> is a problem (regardless of the contents of the header or how you got into 
> the same file twice)? If that's accurate, would it make more sense to 
> diagnose this as:
> 
> `including the same header (%0) more than once in an include stack causes 
> %select{incorrect behavior of Clang modules|the header to not be a C++ module 
> header unit}1`
> 
> or something along those lines? Basically, I'd like to avoid saying "cycle" 
> because that starts to sound like "you have potentially infinite recursion in 
> the include stack" and I'd like to add information about what's actually 
> wrong instead of pointing out what the code does and hoping the user knows 
> why that's bad.
FWIW in libc++ we have a script to check that we don't include the header more 
than once in a stack and also call it a cycle, so there is some precedent of 
calling it an include cycle, even thought it's technically not a cycle.


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

https://reviews.llvm.org/D134654

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

[PATCH] D135118: [clang/Sema] Fix non-deterministic order for certain kind of diagnostics

2022-10-04 Thread Steven Wu via Phabricator via cfe-commits

steven_wu accepted this revision.
steven_wu added a comment.

LGTM.

`RemoveDecl` does become more expensive but I don't have better solution. I am 
also wondering if as follow up we should add an option to 
`VerifyDiagnosticConsumer` to be location aware (so the diagnostics from a file 
is emitted in order) to prevent more problem like this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135118

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

[PATCH] D134791: [clang] Unify Sema and CodeGen implementation of isFlexibleArrayMemberExpr

2022-10-04 Thread serge via Phabricator via cfe-commits

serge-sans-paille updated this revision to Diff 465053.
serge-sans-paille marked 3 inline comments as done.
serge-sans-paille added a comment.
Herald added a reviewer: rafauler.
Herald added subscribers: yota9, ayermolo.
Herald added a reviewer: Amir.
Herald added a reviewer: maksfb.

Address reviewers comment.


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

https://reviews.llvm.org/D134791

Files:
  bolt/lib/RuntimeLibs/RuntimeLibrary.cpp
  clang/include/clang/AST/Expr.h
  clang/lib/AST/Expr.cpp
  clang/lib/CodeGen/CGExpr.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/test/SemaObjC/flexible-array-bounds.m

Index: clang/test/SemaObjC/flexible-array-bounds.m
===
--- /dev/null
+++ clang/test/SemaObjC/flexible-array-bounds.m
@@ -0,0 +1,27 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+// expected-no-diagnostics
+//
+// RUN: %clang_cc1 -fsyntax-only -fstrict-flex-arrays=2 -verify=warn %s
+
+@interface Flexible {
+@public
+  char flexible[];
+}
+@end
+
+@interface Flexible0 {
+@public
+  char flexible[0];
+}
+@end
+
+@interface Flexible1 {
+@public
+  char flexible[1];
+}
+@end
+
+char readit(Flexible *p) { return p->flexible[2]; }
+char readit0(Flexible0 *p) { return p->flexible[2]; }
+char readit1(Flexible1 *p) { return p->flexible[2]; } // warn-warning {{array index 2 is past the end of the array (which contains 1 element)}}
+
Index: clang/lib/Sema/SemaChecking.cpp
===
--- clang/lib/Sema/SemaChecking.cpp
+++ clang/lib/Sema/SemaChecking.cpp
@@ -15898,72 +15898,6 @@
 << TRange << Op->getSourceRange();
 }
 
-/// Check whether this array fits the idiom of a flexible array member,
-/// depending on the value of -fstrict-flex-array.
-///
-/// We avoid emitting out-of-bounds access warnings for such arrays.
-static bool isFlexibleArrayMemberExpr(Sema &S, const Expr *E,
-  const NamedDecl *ND,
-  unsigned StrictFlexArraysLevel) {
-
-  if (!ND)
-return false;
-
-  const ConstantArrayType *ArrayTy =
-  S.Context.getAsConstantArrayType(E->getType());
-  llvm::APInt Size = ArrayTy->getSize();
-
-  if (Size == 0)
-return true;
-
-  // FIXME: While the default -fstrict-flex-arrays=0 permits Size>1 trailing
-  // arrays to be treated as flexible-array-members, we still emit diagnostics
-  // as if they are not. Pending further discussion...
-  if (StrictFlexArraysLevel >= 2 || Size.uge(2))
-return false;
-
-  const FieldDecl *FD = dyn_cast(ND);
-  if (!FD)
-return false;
-
-  // Don't consider sizes resulting from macro expansions or template argument
-  // substitution to form C89 tail-padded arrays.
-
-  TypeSourceInfo *TInfo = FD->getTypeSourceInfo();
-  while (TInfo) {
-TypeLoc TL = TInfo->getTypeLoc();
-// Look through typedefs.
-if (TypedefTypeLoc TTL = TL.getAsAdjusted()) {
-  const TypedefNameDecl *TDL = TTL.getTypedefNameDecl();
-  TInfo = TDL->getTypeSourceInfo();
-  continue;
-}
-if (ConstantArrayTypeLoc CTL = TL.getAs()) {
-  const Expr *SizeExpr = dyn_cast(CTL.getSizeExpr());
-  if (!SizeExpr || SizeExpr->getExprLoc().isMacroID())
-return false;
-}
-break;
-  }
-
-  const RecordDecl *RD = dyn_cast(FD->getDeclContext());
-  if (!RD)
-return false;
-  if (RD->isUnion())
-return false;
-  if (const CXXRecordDecl *CRD = dyn_cast(RD)) {
-if (!CRD->isStandardLayout())
-  return false;
-  }
-
-  // See if this is the last field decl in the record.
-  const Decl *D = FD;
-  while ((D = D->getNextDeclInContext()))
-if (isa(D))
-  return false;
-  return true;
-}
-
 void Sema::CheckArrayAccess(const Expr *BaseExpr, const Expr *IndexExpr,
 const ArraySubscriptExpr *ASE,
 bool AllowOnePastEnd, bool IndexNegated) {
@@ -15983,17 +15917,12 @@
 
   unsigned StrictFlexArraysLevel = getLangOpts().StrictFlexArrays;
 
-  const NamedDecl *ND = nullptr;
-  if (const auto *DRE = dyn_cast(BaseExpr))
-ND = DRE->getDecl();
-  else if (const auto *ME = dyn_cast(BaseExpr))
-ND = ME->getMemberDecl();
-
   const Type *BaseType =
   ArrayTy == nullptr ? nullptr : ArrayTy->getElementType().getTypePtr();
   bool IsUnboundedArray =
-  BaseType == nullptr ||
-  isFlexibleArrayMemberExpr(*this, BaseExpr, ND, StrictFlexArraysLevel);
+  BaseType == nullptr || BaseExpr->isFlexibleArrayMemberLike(
+ Context, StrictFlexArraysLevel,
+ /*IgnoreTemplateOrMacroSubstitution=*/true);
   if (EffectiveType->isDependentType() ||
   (!IsUnboundedArray && BaseType->isDependentType()))
 return;
@@ -16061,15 +15990,14 @@
   << (unsigned)MaxElems.getLimitedValue(~0U)
   << IndexExpr->getSourceRange());
 
-  if (!ND) {
-// Try ha

[PATCH] D134791: [clang] Unify Sema and CodeGen implementation of isFlexibleArrayMemberExpr

2022-10-04 Thread serge via Phabricator via cfe-commits

serge-sans-paille added inline comments.



Comment at: clang/include/clang/AST/Expr.h:531
+  bool isFlexibleArrayMemberLike(
+  ASTContext &Context, unsigned StrictFlexArraysLevel,
+  bool IgnoreTemplateOrMacroSubstitution = false) const;

aaron.ballman wrote:
> Do we want to make the array levels into an enumeration instead of letting 
> the user pass arbitrary integers? (Perhaps not as part of this review.)
Something along https://reviews.llvm.org/D135107 :-) ?


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

https://reviews.llvm.org/D134791

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

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

2022-10-04 Thread Timm Bäder via Phabricator via cfe-commits

tbaeder added inline comments.



Comment at: clang/lib/AST/Interp/Floating.h:27-29
+  template  struct Repr;
+  template <> struct Repr<32> { using Type = float; };
+  template <> struct Repr<64> { using Type = double; };

aaron.ballman wrote:
> tbaeder wrote:
> > jcranmer-intel wrote:
> > > tbaeder wrote:
> > > > jcranmer-intel wrote:
> > > > > aaron.ballman wrote:
> > > > > > Er, how will this extend to `long double` where the number of bits 
> > > > > > is rather more difficult?
> > > > > Or `half` and `bfloat`, which are both 16-bit floating-point types?
> > > > I have spent some time with this today and tried to simply always use 
> > > > `APFloat` instead of a primitive type. Unfortunately that doesn't work 
> > > > because what we put on the stack is not the `Floating` (or `Integral`), 
> > > > but the underlying primitive type. So even if we do the final math (in 
> > > > `::add`, etc) via `APFloat`, we need something we can serialize to 
> > > > `char[]` so we can put it on the stack. Do you think that would work?
> > > I don't know enough about the structure of the bytecode interpreter here 
> > > to say for sure, but this smells to me like you're baking in an 
> > > assumption that every primitive target type has a corresponding primitive 
> > > type on the host. This assumption just doesn't hold when it comes to 
> > > floating point (only two of the seven types, `float` and `double`, are 
> > > generally portable, and even then, there be dragons in some corner cases).
> > > 
> > > If you do need to continue down this route, there are two requirements 
> > > that should be upheld:
> > > * The representation shouldn't assume that the underlying primitive type 
> > > exists on host (bfloat16 and float128 are better test cases here).
> > > * Conversion to/from host primitive types shouldn't be easy to 
> > > accidentally do.
> > > 
> > > (Worth repeating again that bit size is insufficient to distinguish 
> > > floating point types: `bfloat` and `half` are both 16-bit, PPC `long 
> > > double` and IEEE 754 quad precision are both 128-bit, and x86 `long 
> > > double` is 80 bits stored as 96 bits on 32-bit and 128 bits on 64-bit.)
> > Well, is there a way to convert an APFloat to a char[] that would work 
> > instead of going to float/double and storing that? The only thing I see in 
> > the docs is `convertToHexString()` (and the docs don't mention whether the 
> > conversion is lossy). If not, do you think adding such a conversion to 
> > `APFloat` and its various implementations is the better way forward?
> Let's avoid serializing the floats to strings so that we can parse the string 
> to turn it back into a float later; that's going to have poor performance 
> even if we do get all the corner cases correct regarding things like 
> rounding, etc.
> 
> `APFloat` does not have any sort of serialization functionality beyond 
> through strings representing the value. I think you'd have to invent such an 
> interface.
Do you know who I might talk to regrading such an interface, both the 
implementation as well as general feasibility?


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

https://reviews.llvm.org/D134859

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

[PATCH] D135110: [NFC] [HLSL] Move common metadata to LLVMFrontend

2022-10-04 Thread Chris Bieneman via Phabricator via cfe-commits

beanz added a comment.

In D135110#3832728 , @tschuett wrote:

> The OpenMP frontend is mainly an IRBuilder. It is a different layering than 
> for HLSL. Are there plans for an HLSL(IR)Builder?

HLSL and OpenMP are different in a lot of ways. HLSL's code generation is 
fairly consistent with C/C++. There will be some areas where we have special IR 
generation mechanics (like around copy-in/copy-out function parameters), which 
I expect we'll create some sort of reusable API for. I'm unsure if we have 
enough unique cases to make a full builder worth it.

Similar to OpenCL we also have a lot of metadata that needs to get passed from 
the frontend to the backend. That's really where this patch is starting. Having 
shared utilities for reading and writing metadata.

Comment at: llvm/include/llvm/Frontend/HLSL/HLSLResource.h:35
+  GlobalVariable *getGlobalVariable();
+  StringRef getSourceType();
+  Constant *getID();

python3kgae wrote:
> Could we save things like shape and component type instead of a StringRef 
> which needs to be parsed later?
This change is an NFC refactoring to move code around and start sharing between 
the front-end and backend. We have a separate issue tracking extending the 
frontend attribute support to capture more metadata 
(https://github.com/llvm/llvm-project/issues/57991). That will be a separate 
change.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135110

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

[PATCH] D135025: [clang][Interp] Support base class constructors

2022-10-04 Thread Timm Bäder via Phabricator via cfe-commits

tbaeder added inline comments.



Comment at: clang/test/AST/Interp/records.cpp:165
+
+class A : public Base {
+public:

tbaeder wrote:
> erichkeane wrote:
> > tbaeder wrote:
> > > erichkeane wrote:
> > > > shafik wrote:
> > > > > How about also testing `private` and `virtual` as well as multiple 
> > > > > bases.
> > > > I like the idea of testing virtual bases as well.
> > > How would that work in a constexpr context? I get:
> > > 
> > > ```
> > > array.cpp:48:15: error: constexpr constructor not allowed in class with 
> > > virtual base class
> > > constexpr D() : A(17) {}
> > >   ^
> > > array.cpp:45:13: note: virtual base class declared here
> > >   class B : public virtual A {};
> > > ^~~~
> > > 1 error generated.
> > > ```
> > > 
> > Ah! TIL, thanks!
> Ah, this works: https://godbolt.org/z/ern3Yje9q
Checking this example, I should've tested a lot more non-constexpr stuff I 
guess.


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

https://reviews.llvm.org/D135025

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

[PATCH] D134791: [clang] Unify Sema and CodeGen implementation of isFlexibleArrayMemberExpr

2022-10-04 Thread Aaron Ballman via Phabricator via cfe-commits

aaron.ballman added inline comments.



Comment at: bolt/lib/RuntimeLibs/RuntimeLibrary.cpp:31-36
+  llvm::sys::path::append(LibPath, "lib64");
   if (!llvm::sys::fs::exists(LibPath)) {
 // In some cases we install bolt binary into one level deeper in bin/,
 // we need to go back one more level to find lib directory.
 LibPath = llvm::sys::path::parent_path(llvm::sys::path::parent_path(Dir));
+llvm::sys::path::append(LibPath, "lib64");

These changes seem unrelated?



Comment at: clang/include/clang/AST/Expr.h:531
+  bool isFlexibleArrayMemberLike(
+  ASTContext &Context, unsigned StrictFlexArraysLevel,
+  bool IgnoreTemplateOrMacroSubstitution = false) const;

serge-sans-paille wrote:
> aaron.ballman wrote:
> > Do we want to make the array levels into an enumeration instead of letting 
> > the user pass arbitrary integers? (Perhaps not as part of this review.)
> Something along https://reviews.llvm.org/D135107 :-) ?
LOL and that's why my suggestion seemed so familiar. :-D


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

https://reviews.llvm.org/D134791

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

[PATCH] D135175: [clang] adds `__is_bounded_array` and `__is_unbounded_array` as builtins

2022-10-04 Thread Christopher Di Bella via Phabricator via cfe-commits

cjdb updated this revision to Diff 465057.
cjdb added a comment.

adds missing property


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135175

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/TokenKinds.def
  clang/lib/Parse/ParseDeclCXX.cpp
  clang/lib/Parse/ParseExpr.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/SemaCXX/type-traits.cpp

Index: clang/test/SemaCXX/type-traits.cpp
===
--- clang/test/SemaCXX/type-traits.cpp
+++ clang/test/SemaCXX/type-traits.cpp
@@ -702,6 +702,70 @@
   int t31[F(__is_array(cvoid*))];
 }
 
+void is_bounded_array(int n) {
+  int t01[T(__is_bounded_array(IntAr))];
+  int t02[F(__is_bounded_array(IntArNB))];
+  int t03[T(__is_bounded_array(UnionAr))];
+
+  int t10[F(__is_bounded_array(void))];
+  int t11[F(__is_bounded_array(cvoid))];
+  int t12[F(__is_bounded_array(float))];
+  int t13[F(__is_bounded_array(double))];
+  int t14[F(__is_bounded_array(long double))];
+  int t15[F(__is_bounded_array(bool))];
+  int t16[F(__is_bounded_array(char))];
+  int t17[F(__is_bounded_array(signed char))];
+  int t18[F(__is_bounded_array(unsigned char))];
+  int t19[F(__is_bounded_array(wchar_t))];
+  int t20[F(__is_bounded_array(short))];
+  int t21[F(__is_bounded_array(unsigned short))];
+  int t22[F(__is_bounded_array(int))];
+  int t23[F(__is_bounded_array(unsigned int))];
+  int t24[F(__is_bounded_array(long))];
+  int t25[F(__is_bounded_array(unsigned long))];
+  int t26[F(__is_bounded_array(Union))];
+  int t27[F(__is_bounded_array(Derives))];
+  int t28[F(__is_bounded_array(ClassType))];
+  int t29[F(__is_bounded_array(Enum))];
+  int t30[F(__is_bounded_array(void *))];
+  int t31[F(__is_bounded_array(cvoid *))];
+
+  int t32[n];
+  (void)__is_bounded_array(decltype(t32)); // expected-error{{variable length arrays are not supported for '__is_bounded_array'}}
+}
+
+void is_unbounded_array(int n) {
+  int t01[F(__is_unbounded_array(IntAr))];
+  int t02[T(__is_unbounded_array(IntArNB))];
+  int t03[F(__is_unbounded_array(UnionAr))];
+
+  int t10[F(__is_unbounded_array(void))];
+  int t11[F(__is_unbounded_array(cvoid))];
+  int t12[F(__is_unbounded_array(float))];
+  int t13[F(__is_unbounded_array(double))];
+  int t14[F(__is_unbounded_array(long double))];
+  int t15[F(__is_unbounded_array(bool))];
+  int t16[F(__is_unbounded_array(char))];
+  int t17[F(__is_unbounded_array(signed char))];
+  int t18[F(__is_unbounded_array(unsigned char))];
+  int t19[F(__is_unbounded_array(wchar_t))];
+  int t20[F(__is_unbounded_array(short))];
+  int t21[F(__is_unbounded_array(unsigned short))];
+  int t22[F(__is_unbounded_array(int))];
+  int t23[F(__is_unbounded_array(unsigned int))];
+  int t24[F(__is_unbounded_array(long))];
+  int t25[F(__is_unbounded_array(unsigned long))];
+  int t26[F(__is_unbounded_array(Union))];
+  int t27[F(__is_unbounded_array(Derives))];
+  int t28[F(__is_unbounded_array(ClassType))];
+  int t29[F(__is_unbounded_array(Enum))];
+  int t30[F(__is_unbounded_array(void *))];
+  int t31[F(__is_unbounded_array(cvoid *))];
+
+  int t32[n];
+  (void)__is_unbounded_array(decltype(t32)); // expected-error{{variable length arrays are not supported for '__is_unbounded_array'}}
+}
+
 template  void tmpl_func(T&) {}
 
 template  struct type_wrapper {
Index: clang/lib/Sema/SemaType.cpp
===
--- clang/lib/Sema/SemaType.cpp
+++ clang/lib/Sema/SemaType.cpp
@@ -2627,12 +2627,10 @@
 
   if (T->isVariableArrayType() && !Context.getTargetInfo().isVLASupported()) {
 // CUDA device code and some other targets don't support VLAs.
-targetDiag(Loc, (getLangOpts().CUDA && getLangOpts().CUDAIsDevice)
-? diag::err_cuda_vla
-: diag::err_vla_unsupported)
-<< ((getLangOpts().CUDA && getLangOpts().CUDAIsDevice)
-? CurrentCUDATarget()
-: CFT_InvalidTarget);
+bool IsCUDADevice = (getLangOpts().CUDA && getLangOpts().CUDAIsDevice);
+targetDiag(Loc,
+   IsCUDADevice ? diag::err_cuda_vla : diag::err_vla_unsupported)
+<< (IsCUDADevice ? CurrentCUDATarget() : 0);
   }
 
   // If this is not C99, diagnose array size modifiers on non-VLAs.
Index: clang/lib/Sema/SemaExprCXX.cpp
===
--- clang/lib/Sema/SemaExprCXX.cpp
+++ clang/lib/Sema/SemaExprCXX.cpp
@@ -21,11 +21,13 @@
 #include "clang/AST/ExprCXX.h"
 #include "clang/AST/ExprObjC.h"
 #include "clang/AST/RecursiveASTVisitor.h"
+#include "clang/AST/Type.h"
 #include "clang/AST/TypeLoc.h"
 #include "clang/Basic/AlignedAllocation.h"
 #include "clang/Basic/DiagnosticSema.h"
 #include "clang/Basic/PartialDiagnostic.h"
 #include "clang/Basic/TargetInfo.h"
+#include "clang/Basic/TokenKinds.h"
 #include "clang

[PATCH] D135177: [clang] adds `__is_scoped_enum`, `__is_nullptr`, and `__is_referenceable`

2022-10-04 Thread Christopher Di Bella via Phabricator via cfe-commits

cjdb created this revision.
cjdb added a reviewer: aaron.ballman.
Herald added a project: All.
cjdb requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

... as builtins.

This is information that the compiler already has, and should be exposed
so that the library doesn't need to reimplement the exact same
functionality.

This was originally a part of D116280 .


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D135177

Files:
  clang/include/clang/Basic/TokenKinds.def
  clang/lib/Parse/ParseDeclCXX.cpp
  clang/lib/Parse/ParseExpr.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/test/SemaCXX/type-traits.cpp

Index: clang/test/SemaCXX/type-traits.cpp
===
--- clang/test/SemaCXX/type-traits.cpp
+++ clang/test/SemaCXX/type-traits.cpp
@@ -345,11 +345,19 @@
 }
 
 typedef Enum EnumType;
+typedef EnumClass EnumClassType;
 
 void is_enum()
 {
   { int arr[T(__is_enum(Enum))]; }
   { int arr[T(__is_enum(EnumType))]; }
+  { int arr[T(__is_enum(SignedEnum))]; }
+  { int arr[T(__is_enum(UnsignedEnum))]; }
+
+  { int arr[T(__is_enum(EnumClass))]; }
+  { int arr[T(__is_enum(EnumClassType))]; }
+  { int arr[T(__is_enum(SignedEnumClass))]; }
+  { int arr[T(__is_enum(UnsignedEnumClass))]; }
 
   { int arr[F(__is_enum(int))]; }
   { int arr[F(__is_enum(Union))]; }
@@ -363,6 +371,29 @@
   { int arr[F(__is_enum(HasAnonymousUnion))]; }
 }
 
+void is_scoped_enum() {
+  { int arr[F(__is_scoped_enum(Enum))]; }
+  { int arr[F(__is_scoped_enum(EnumType))]; }
+  { int arr[F(__is_scoped_enum(SignedEnum))]; }
+  { int arr[F(__is_scoped_enum(UnsignedEnum))]; }
+
+  { int arr[T(__is_scoped_enum(EnumClass))]; }
+  { int arr[T(__is_scoped_enum(EnumClassType))]; }
+  { int arr[T(__is_scoped_enum(SignedEnumClass))]; }
+  { int arr[T(__is_scoped_enum(UnsignedEnumClass))]; }
+
+  { int arr[F(__is_scoped_enum(int))]; }
+  { int arr[F(__is_scoped_enum(Union))]; }
+  { int arr[F(__is_scoped_enum(Int))]; }
+  { int arr[F(__is_scoped_enum(IntAr))]; }
+  { int arr[F(__is_scoped_enum(UnionAr))]; }
+  { int arr[F(__is_scoped_enum(Derives))]; }
+  { int arr[F(__is_scoped_enum(ClassType))]; }
+  { int arr[F(__is_scoped_enum(cvoid))]; }
+  { int arr[F(__is_scoped_enum(IntArNB))]; }
+  { int arr[F(__is_scoped_enum(HasAnonymousUnion))]; }
+}
+
 struct FinalClass final {
 };
 
@@ -766,6 +797,42 @@
   (void)__is_unbounded_array(decltype(t32)); // expected-error{{variable length arrays are not supported for '__is_unbounded_array'}}
 }
 
+void is_referenceable() {
+  { int a[T(__is_referenceable(int))]; }
+  { int a[T(__is_referenceable(const int))]; }
+  { int a[T(__is_referenceable(volatile int))]; }
+  { int a[T(__is_referenceable(const volatile int))]; }
+  { int a[T(__is_referenceable(int *))]; }
+  { int a[T(__is_referenceable(int &))]; }
+  { int a[T(__is_referenceable(int &&))]; }
+  { int a[T(__is_referenceable(int (*)()))]; }
+  { int a[T(__is_referenceable(int (&)()))]; }
+  { int a[T(__is_referenceable(int(&&)()))]; }
+  { int a[T(__is_referenceable(IntAr))]; }
+  { int a[T(__is_referenceable(IntArNB))]; }
+  { int a[T(__is_referenceable(decltype(nullptr)))]; }
+  { int a[T(__is_referenceable(Empty))]; }
+  { int a[T(__is_referenceable(Union))]; }
+  { int a[T(__is_referenceable(Derives))]; }
+  { int a[T(__is_referenceable(Enum))]; }
+  { int a[T(__is_referenceable(EnumClass))]; }
+  { int a[T(__is_referenceable(int Empty::*))]; }
+  { int a[T(__is_referenceable(int(Empty::*)()))]; }
+  { int a[T(__is_referenceable(int(Empty::*)() const))]; }
+  { int a[T(__is_referenceable(int(Empty::*)() volatile))]; }
+  { int a[T(__is_referenceable(int(Empty::*)() const volatile))]; }
+  { int a[T(__is_referenceable(int(Empty::*)() &))]; }
+  { int a[T(__is_referenceable(int(Empty::*)() const &))]; }
+  { int a[T(__is_referenceable(int(Empty::*)() volatile &))]; }
+  { int a[T(__is_referenceable(int(Empty::*)() const volatile &))]; }
+  { int a[T(__is_referenceable(int(Empty::*)() &&))]; }
+  { int a[T(__is_referenceable(int(Empty::*)() const &&))]; }
+  { int a[T(__is_referenceable(int(Empty::*)() volatile &&))]; }
+  { int a[T(__is_referenceable(int(Empty::*)() const volatile &&))]; }
+
+  { int a[F(__is_referenceable(void))]; }
+}
+
 template  void tmpl_func(T&) {}
 
 template  struct type_wrapper {
@@ -998,6 +1065,42 @@
   int t34[F(__is_pointer(void (StructWithMembers::*) ()))];
 }
 
+void is_null_pointer() {
+  StructWithMembers x;
+
+  int t00[T(__is_nullptr(decltype(nullptr)))];
+  int t01[F(__is_nullptr(void *))];
+  int t02[F(__is_nullptr(cvoid *))];
+  int t03[F(__is_nullptr(cvoid *))];
+  int t04[F(__is_nullptr(char *))];
+  int t05[F(__is_nullptr(int *))];
+  int t06[F(__is_nullptr(int **))];
+  int t07[F(__is_nullptr(ClassType *))];
+  int t08[F(__is_nullptr(Derives *))];
+  int t09[F(__is_nullptr(Enum *))];
+  int t10[F(__is_nullptr(IntArNB *))];
+  int t11[F(__is_nullptr(Union *))];
+

[PATCH] D134797: [X86][vectorcall] Make floating-type passed by value to match with MSVC

2022-10-04 Thread Reid Kleckner via Phabricator via cfe-commits

rnk added inline comments.



Comment at: clang/lib/CodeGen/TargetInfo.cpp:1858-1859
 }
-return getIndirectResult(Ty, /*ByVal=*/false, State);
+bool ByVal = IsVectorCall && Ty->isFloatingType();
+return getIndirectResult(Ty, ByVal, State);
   }

pengfei wrote:
> rnk wrote:
> > I would try to refactor this so that the vectorcall HFA that can't be 
> > passed in SSE regs falls through to the following logic. I suspect that it 
> > correctly handles each case that we care about:
> > - double: direct
> > - vector: indirect for alignment
> > - aggregate: indirect for alignment, any HFA will presumably be aligned to 
> > more than 32bits
> > 
> Not sure if I understand it correctly, the HFA is not a floating type, so it 
> won't be affected. Add a test case for it.
> MSVC passes it indirectly too. https://gcc.godbolt.org/z/3qf4dTYfv
Thanks, I see what you mean. I thought the code for handling overaligned 
aggregates would trigger, passing any HFA indirectly, but it does not for plain 
FP HFAs. You can observe the difference by replacing `double` in HFA2 with 
`__int64`, and see that HFA2 is passed underaligned on the stack:
https://gcc.godbolt.org/z/jqx4xcnjq

I still think this code would benefit from separating the regcall and 
vectorcall cases, something like:
  bool IsInReg = State.FreeSSERegs >= NumElts;
  if (IsInReg)
State.FreeSSERegs -= NumElts;
  if (IsRegCall) {
// handle regcall
if (IsInReg)
   ...
  } else {
// handle vectorcall
if (IsInReg)
  ...
  }

They seem to have pretty different rules both when SSE regs are available and 
when not.



Comment at: clang/test/CodeGen/vectorcall.c:157
+// X86-SAME: <4 x float> inreg noundef %xmm5,
+// X86-SAME: double* noundef byval(double) align 4 %0)
 #endif

pengfei wrote:
> rnk wrote:
> > Why not pass the double directly? That should be ABI compatible:
> > https://gcc.godbolt.org/z/W4rjn63b5
> Sorry, I'm not sure what's your mean here. Do you mean I should use your 
> example as the test case? Here the case mocked `vectorcall_indirect_vec`, 
> which I think is intended to check if the type, `inreg` and `byval` etc. are 
> generated correctly.
I mean that these two LLVM prototypes are ABI compatible at the binary level 
for i686, but the second is much easier to optimize:
  double @byval(double* byval(double) %p) {
%v = load double, double* %p
ret double %v
  }
  double @direct(double %v) {
ret double %v
  }
https://gcc.godbolt.org/z/MjEvdEKbT

Clang should generate the prototype.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134797

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

[PATCH] D135118: [clang/Sema] Fix non-deterministic order for certain kind of diagnostics

2022-10-04 Thread Ben Langmuir via Phabricator via cfe-commits

benlangmuir added inline comments.



Comment at: clang/include/clang/AST/DeclObjC.h:1091
   virtual void collectPropertiesToImplement(PropertyMap &PM,
 PropertyDeclOrder &PO) const {}
 

Can we use the existing `PropertyDeclOrder` instead of changing the map type? 
Or else get rid of the `PO` parameter to functions using `PropertyMap` if we 
keep the MapVector?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135118

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

[PATCH] D119130: [clangd] NFC: Move stdlib headers handling to Clang

2022-10-04 Thread Kadir Cetinkaya via Phabricator via cfe-commits

kadircet added a comment.

yeah sorry for the mess here. i agree that we should move StandardLibrary to 
its own library. i'll try to take a stab at this tomorrow, if no one does it 
before then.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119130

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

1 2 3 >

1 - 100 of 254 matches

Mail list logo